Conceito e mecanismo
A build combina uma definição, contexto e dependências. O contexto determina quais os ficheiros disponíveis para COPY; o caminho do Dockerfile não alarga automaticamente esse conjunto. Revê .dockerignore para retirar ficheiros que não devem chegar ao builder, incluindo material sensível e saídas locais desnecessárias. Uma imagem é composta por camadas e o seu conteúdo não se modifica quando uma etiqueta é reutilizada. A etiqueta pode passar a apontar para outra imagem. Para relacionar homologação e produção, regista a identidade efetivamente avaliada e a plataforma esperada. Um digest ajuda a fixar conteúdo, mas não demonstra por si só qualidade, autorização ou compatibilidade funcional.
Aplicação guiada
Num exemplo original, o builder ocupa 940 MB e o executável necessário ocupa 38 MB. Uma build multi-stage permite copiar o resultado para uma imagem de execução adequada, sem conservar compiladores apenas por conveniência. Confirma bibliotecas, certificados e utilizador necessários: um binário dinâmico pode falhar numa imagem mínima sem as suas dependências. Se a compilação precisa de acesso a um repositório privado, usa o mecanismo de secret mount do BuildKit com âmbito limitado. ARG ou ENV não são uma forma apropriada de transportar segredos de build. Mesmo um mount temporário pode ser lido pelo comando autorizado; esse comando não deve imprimir nem copiar o segredo para a saída.
A etiqueta aprovada aponta agora para outro digest; a aprovação anterior não identifica a nova imagem.
Armadilhas comuns
Etiqueta como identidade imutável; imagem pequena como completa; secret mount como proteção contra o próprio comando.
Tópicos relacionados: Processos e imagens · Rede e acesso · Dados e mounts
Promove o conteúdo avaliado com os recursos necessários para o executar.
Referência: Selective artifacts across build stages · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped