Victor Ricardo

O que acontece depois de executarmos o último comando (docker run hello-world) do post anterior? Melhor dizendo, qual será a ordem entre os principais elementos listados? Você se lembra deles? Não?! Tudo bem! 😉 Refrescando a memória, são eles: containers, dockerfile, images, engine, hub … Mas voltando a nossa pergunta, quem chama o quê primeiro?

Vamos então a resposta! Me acompanhe por favor. Observem a captura de tela logo abaixo:

A primeira mensagem que chama atenção é, por coincidência, também a primeira linha “unable to find image 'hello-world: latest' locally“. Em tradução livre seria algo como impossível encontrar a imagem ‘olá-mundo’ localmente … Com isso, deduzimos que o primeiro passo é sempre um valor booleano para informar se a imagem está presente ou não. Em caso de negativa, a próxima etapa é baixá-la da biblioteca oficial, o Docker Hub Na prática, refere-se as linhas “latest: pulling from“,”id: pull complete“,”status: downloaded"

Mas tenha cuidado e muita atenção!!! Pois haverá casos que as negativas não necessariamente significam ausência da imagem. Talvez você apenas tenha digitado o nome errado, ou o repositório que contém a imagem não existe.

Certo Victor, acho que estou começando a entender MAS … O que encontrarei nesse tal Docker Hub? Elementar, deveras elementar, meu caro e minha cara 😀 Além das famosas imagens, você poderá acessar as receitas utilizadas para construí-las. Hein?! Como assim? Explico, uma imagem é criada a partir de um script legível. O nome técnico para isso é Dockerfile Com ele você consegue repassar instruções ao Docker que ditam como será sua imagem, e consequentemente, todo e qualquer container baseado nela. Então quando você está buscando em repositórios por um nome específico, na verdade você está procurando por serviços, aplicações ou até mesmo sistemas operacionais que foram portados (convertidos) e otimizados para ambientes containerizados. Entendeu agora? 🙂

Por exemplo, pesquise por ‘nginx‘ e serão exibidos alguns itens e detalhes interessantes para tomarmos nota. Veja a seguir:

Reparem que temos três tipos de origem aqui, são elas:

• imagem oficial – solução de código aberto que recebe periodicamente curadoria por parte da Docker.
• editor confiável – entidades que mantem e ofertam seus produtos diretamente ao usuário final, muitas vezes de forma comercial e paga.
• projeto patrocinado – serviços/apps/sistemas que são patrocinados pela própria Docker via programa e iniciativa open source.

E já que há pouco mencionamos sistemas operacionais, vamos a outro exemplo. Agora pesquise por ‘debian‘:

Escolha qualquer um de sua preferência, e em seguida dê um clique simples para mais informações:

Perceba o comando listado no canto superior direito para já copiá-lo. Depois siga para o terminal e cole o mesmoExatamente! A principal diferença entre o run e o pull é que o primeiro baixa e executa, enquanto que o segundo apenas baixa. Observe:

Vá em frente, e tente executá-lo. E aí? Qual foi o resultado? 😐 Um belo, completo e absoluto NADA Victor … Muito obrigado!!! 🙁 Calma jovem, devagar e sempre! Na verdade, o que houve foi justamente o esperado para um container. Por não haver nada, nenhum tipo de evento, “travando” a sua existência, o mesmo simplesmente executa e se “autodescarta” em seguida. Pois essa é a sua natureza e missão: efêmera e servir

Caso queira algo mais “explícito”, ou até mesmo interativo, você precisa sim expressar de alguma forma o que realmente deseja para o(s) container(s) em questão. Por exemplo:

docker run debian sleep 5m

Para corroborar o nosso experimento, abra um novo terminal e execute o seguinte:

docker ps

O comando anterior exibe somente os containers ativos (em execução). Para uma listagem completa, entre todos, incluindo os inativos:

docker ps -a

Viram só? 🙂 hehehe … Antes de encerrarmos por hoje, tenho algumas observações a fazer. A primeira coluna diz respeito ao ID do container, e você pode referenciá-lo assim. Já a segunda especifica o nome da imagem utilizada como base. Terceira abrange o comando interno e que foi executado durante a “vida” do container. Na quarta visualizamos há quanto tempo aquele container foi criado. Quinta traz o estado atual do mesmo, podendo ser UP indicando sua execução ou EXITED que significa o seu término. A sexta indica quais portas do container estão “ouvindo” requisições (essa cobriremos mais tarde, em outro momento). E finalmente, a sétima informa o namespace usado para diferenciá-lo dos demais.

Dúvidas? Comenta aqui embaixo