Uma imagem Docker não é um arquivo monolítico que precisa ser recriado do zero a cada alteração. Ela é formada por camadas empilhadas, e essa escolha explica boa parte da velocidade, do tamanho e do comportamento do cache durante um build. Entender o mecanismo ajuda tanto quem está começando com containers quanto quem já mantém pipelines de entrega contínua.
A documentação oficial do Docker trata cada instrução relevante do Dockerfile como uma mudança que pode gerar uma camada. O resultado final é uma imagem composta por partes reutilizáveis. Quando uma etapa não mudou, o Docker pode reaproveitar o que já foi construído em vez de baixar dependências e executar todos os comandos novamente. Fonte principal: https://docs.docker.com/get-started/docker-concepts/building-images/understanding-image-layers.
O que é uma camada de imagem
Imagine uma sequência de alterações sobre uma base. A imagem começa com uma camada inicial, normalmente escolhida por uma instrução FROM. Depois, comandos como RUN, COPY e ADD acrescentam mudanças ao sistema de arquivos. Essas mudanças não significam necessariamente que cada camada contenha uma cópia completa de tudo. O motor combina as camadas para apresentar ao container uma visão final única.
As camadas são tratadas como partes imutáveis depois de criadas. Um container em execução recebe uma camada gravável por cima delas, conhecida como camada de escrita do container. Por isso, modificar arquivos enquanto o processo está rodando não altera automaticamente a imagem original. Se a alteração precisa sobreviver à remoção do container, o fluxo correto é produzir uma nova imagem ou usar volumes conforme o caso.
Como o cache acelera o build
O ganho mais visível aparece quando o Docker encontra uma etapa igual a uma etapa já construída. Em vez de repetir o trabalho, ele recupera a camada existente. Essa regra torna a ordem das instruções importante. Um Dockerfile que copia todo o código antes de instalar dependências pode invalidar o cache de instalação sempre que um arquivo da aplicação mudar.
Uma organização mais previsível separa arquivos que mudam pouco dos arquivos que mudam com frequência. Em um projeto Python, por exemplo, faz sentido copiar primeiro o arquivo de dependências, instalar os pacotes e só depois copiar o código da aplicação. Em um projeto Node.js, package.json e o arquivo de lock podem vir antes do restante do diretório. O detalhe exato depende da ferramenta, mas o princípio é o mesmo: coloque cedo o que é estável e deixe para depois o que muda a cada edição.
O cache não é uma garantia de que qualquer comando será reaproveitado. Alterar uma instrução, o conteúdo copiado ou uma etapa anterior pode fazer as etapas seguintes serem reconstruídas. A leitura do log do build é importante para confirmar quando o cache foi usado e quando uma etapa realmente executou de novo.
Tamanho, segurança e manutenção
Camadas também influenciam a manutenção. Remover um arquivo em uma instrução posterior não apaga necessariamente os bytes que foram incluídos em uma camada anterior. Se um segredo foi copiado para a imagem, apagar o arquivo em seguida não deve ser tratado como correção suficiente. O segredo pode continuar presente no histórico das camadas e precisa ser revogado.
O mesmo raciocínio vale para arquivos temporários, caches de gerenciadores de pacotes e ferramentas que só são necessárias durante a compilação. Uma imagem menor tende a ter menos superfície para atualizar e transportar, mas tamanho não é o único critério. A equipe também precisa escolher uma base mantida, aplicar atualizações e verificar o conteúdo produzido.
Builds reproduzíveis exigem atenção a versões, fontes de pacotes e contexto enviado ao daemon ou ao BuildKit. Um .dockerignore bem configurado evita mandar para o build diretórios que não fazem parte do artefato, como caches locais, repositórios Git e arquivos com credenciais. Isso reduz transferência e diminui a chance de copiar material indevido para uma camada.
Um roteiro prático para revisar o Dockerfile
Comece listando as instruções que mudam com frequência e as que representam a base do ambiente. Depois, observe quais comandos produzem arquivos temporários que poderiam ser descartados no mesmo estágio. Confira se dependências são fixadas de maneira compatível com o projeto e se a imagem final contém apenas o que é necessário para executar o serviço.
Em seguida, faça um build sem presumir que o cache está correto. Compare o tempo e o tamanho com uma execução posterior, leia as etapas reaproveitadas e identifique o primeiro ponto em que uma mudança invalida as demais. Essa observação costuma revelar cópias amplas demais, comandos acoplados e dependências que foram instaladas antes da hora.
Quando houver compilação, considere separar o ambiente de construção da imagem final em um multi-stage build. A etapa de build pode conter compiladores e ferramentas, enquanto a etapa final recebe somente os artefatos necessários. Essa técnica não altera o fato de que as camadas existem; ela ajuda a escolher quais camadas chegam ao resultado que será distribuído.
Por fim, inspecione a imagem gerada, documente a base escolhida e automatize verificações de vulnerabilidade dentro do nível de rigor adequado ao projeto. O objetivo não é transformar cada Dockerfile em uma obra de engenharia, mas tornar suas decisões visíveis e repetíveis.
Conclusão
Camadas são o modelo que permite ao Docker compor imagens, reaproveitar trabalho e manter containers separados da imagem que os originou. A ordem do Dockerfile, o contexto enviado, o tratamento de temporários e a proteção de segredos determinam se esse modelo será uma vantagem ou uma fonte de surpresas.
Para quem está aprendendo, a melhor experiência é alterar uma instrução por vez e observar o build. Para quem opera produção, o caminho é combinar cache bem planejado com bases atualizadas, builds reproduzíveis, imagens mínimas e inspeção contínua. A explicação completa e atualizada está na documentação oficial do Docker: Understanding the image layers.
