1.
Retomando: de imagens a containers em execução Na primeira parte desta série vimos o que é o Docker, o problema que ele resolve e os três conceitos fundamentais — imagens, containers e registries.
Agora que a base teórica está posta, o foco deste artigo é prático: os comandos que efetivamente viram hábito no uso diário — , , , , — aplicados a containers reais, não só ao .
- além do básico O artigo anterior já usou para subir um Nginx.
Vale conhecer as flags que aparecem o tempo todo: combina (interativo, mantém STDIN aberto) com (aloca um pseudo-terminal) — é o par de flags para "entrar" em um container e usar um shell como se fosse uma máquina normal. evita acumular containers parados no disco depois de testes rápidos e descartáveis — sem ela, cada deixa um container parado para trás até ser removido manualmente. define variáveis de ambiente; imagens oficiais como a do Postgres costumam documentar quais variáveis elas esperam (usuário, senha, nome do banco inicial).
3.
Inspecionando o que está rodando O comando mais usado para ter uma visão geral do que o Docker está gerenciando na máquina: Para investigar um container específico mais a fundo: é particularmente útil para detectar um container consumindo memória ou CPU muito acima do esperado, sem precisar entrar nele.
4.
Logs: a primeira ferramenta de debug Containers geralmente não têm um arquivo de log tradicional acessível de fora — a convenção do Docker é que a aplicação escreva na saída padrão (stdout/stderr), e o Docker captura isso automaticamente: Na prática, costuma ser o primeiro comando rodado ao investigar um container que não está se comportando como esperado — antes até de entrar nele. - : entrando em um container já rodando Diferente de (que cria um novo container), executa um comando dentro de um container que já está rodando: Esse é o comando do dia a dia para depurar um container em produção (ou em homologação) sem reiniciá-lo: verificar se um arquivo de configuração chegou certo, olhar o conteúdo de um diretório, testar conectividade de rede com de dentro do container, etc.
- : da aplicação à imagem Todos os exemplos até aqui usaram imagens prontas do Docker Hub.
Para empacotar uma aplicação própria, o ponto de partida é um (o Artigo 3 desta série é inteiramente dedicado a escrevê-los bem) — por agora, um exemplo mínimo para uma aplicação Python: Construir a imagem a partir desse arquivo: — dá um nome () e uma tag () à imagem resultante.
Sem tag explícita, o Docker usa por padrão — algo a evitar em ambientes reais, porque não diz nada sobre qual versão do código está de fato empacotada ali. — o contexto de build: o diretório cujo conteúdo fica disponível para os comandos / do Dockerfile.
Tudo dentro dele é enviado ao Docker daemon antes do build começar, então diretórios grandes e irrelevantes (como , ) devem ser excluídos com um arquivo .
Depois de construída, a imagem já pode ser rodada como qualquer outra:
7.
Limpando o ambiente Containers parados, imagens não usadas e volumes órfãos se acumulam rápido durante o desenvolvimento.
Comandos úteis de limpeza: Vale rodar antes, para ter uma ideia de quanto espaço em disco está sendo ocupado por cada categoria (imagens, containers, volumes, cache de build) antes de decidir o que limpar.
8.
Conclusão e próximos passos Com , , , e , já é possível cobrir o ciclo completo do dia a dia: subir containers, inspecionar o que está rodando, depurar problemas e empacotar uma aplicação própria em imagem.
No próximo artigo, o foco entra a fundo no : como as camadas funcionam, como aproveitar o cache de build para acelerar builds repetidos, e boas práticas para escrever um Dockerfile enxuto e eficiente.
Imagem de capa: Logo oficial do Docker — Wikimedia Commons, fonte: docker.com/company/newsroom/media-resources Referências: Docker CLI Reference Docker Documentation — Dockerfile Reference