APRENDER. PRATICAR. EVOLUIR.Começar pelas entradas efetivas
Na oficina fictícia, a pipeline corre na raiz do repositório e seleciona deploy/Dockerfile com -f. O argumento final continua a definir o contexto. Antes de alterar COPY, identifica essa raiz e as exclusões realmente usadas. Um ficheiro específico do Dockerfile pode ter precedência sobre .dockerignore da raiz. Prepara um inventário com origem do código, Dockerfile, contexto, argumentos não confidenciais e artefacto esperado. Este inventário ajuda a explicar por que duas builds aparentemente iguais podem receber ficheiros diferentes, sem recorrer a conteúdo ou credenciais reais de produção.
Uma build rápida pode reutilizar um resultado antigo
No exercício de fecho, a equipa observa uma execução rápida e conclui que as regras foram novamente descarregadas. Pede primeiro evidência de quais passos correram e quais foram reutilizados. Cache não confirma atualização do servidor remoto. Uma instalação reutilizada pode conservar componentes anteriores; alterar apenas mtime de uma entrada também não é uma estratégia de invalidação de COPY. Define o requisito de frescura, as versões esperadas e o âmbito de reconstrução necessário. O relatório deve distinguir sucesso do processo, identidade do resultado e cumprimento do requisito que motivou a mudança.
Organizar dependências sem esconder entradas
Quando manifesto e lockfile mudam raramente, copia essas entradas antes de instalar dependências e coloca depois o código que muda com frequência. Confirma, porém, se a instalação também usa scripts ou configuração que ficaram de fora. Uma otimização que omite entradas reais pode reutilizar resultados indevidos. Um cache mount serve para acelerar trabalho repetido, não para distribuir o único executável. O resultado necessário deve ser produzido fora desse mount. Aplica a mesma revisão aos bind mounts de build: permissões de escrita não tornam permanentes as alterações feitas no conteúdo montado.
Rotação de segredo exige uma decisão própria
O valor de um segredo pode mudar sem invalidar o passo em cache. No caso fictício, isso deixa duas perguntas: o acesso com a credencial nova funciona e as regras correspondem à versão aprovada? Valida-as separadamente quando necessário. Usa um mecanismo de entrada temporário adequado e revê o comando consumidor: imprimir ou copiar o valor para um ficheiro de saída pode expô-lo apesar do mount. Não coloques o segredo num ARG para forçar repetição. Regista a identidade autorizada do mecanismo, sem guardar o valor confidencial na ficha de mudança.
Laboratório real: o que o parser conseguiu observar
O laboratório usa o módulo oficial BuildKit v0.33.1 e oito Dockerfiles originais. O parser e instructions.Parse aceitaram cinco e rejeitaram três entradas inválidas. Foi aplicada expansão identidade aos campos literais dos mounts RUN, sem resolver variáveis de ambiente. A experiência observou stages, COPY entre stages, formas shell e exec, mounts declarados e conteúdo inline. No exemplo, a referência ${BASE_IMAGE} permaneceu sem resolução. Nenhuma imagem foi descarregada ou construída. Esta diferença permite usar os resultados para rever a declaração sem confundir leitura de instruções com funcionamento de uma aplicação.
Oficina: decidir que evidência ainda falta
Preenche uma ficha para a rotação do token das regras de fecho. Identifica contexto e exclusões, passos reutilizados, versão do ficheiro produzido e o resultado esperado pelo consumidor. Se o parser aceita a declaração, assinala apenas essa verificação. Planeia depois a execução isolada e autorizada necessária para confirmar acesso, construção e comportamento, conservando a identidade dos resultados. Na passagem de turno, usa uma frase precisa: “The Dockerfile was parsed; credential access and artifact freshness still need validation.” Evita apresentar uma hipótese de cache como diagnóstico comprovado sem observar a execução relevante.
Observação real: oito fixtures, cinco aceites e três rejeitadas. O parser identificou build e runtime, mantendo ${BASE_IMAGE} e $BUILDPLATFORM por resolver. Não executou RUN.
Armadilhas comuns
Tomar cache por atualização; usar mtime como controlo de reconstrução; deixar o executável num mount temporário; expor segredos em ARG; declarar runtime validado após parsing.
Tópicos relacionados: Build e distribuição · Compose e privilégios · Dados, persistência e recuperação validada
Revê as entradas e o destino de cada saída. O parser ajuda a ler a intenção; execução controlada e evidência do artefacto continuam necessárias para aceitar a build.
Referência: Build context · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped