APRENDER. PRATICAR. EVOLUIR.O stage final precisa de um contrato de execução
Um COPY entre stages transfere os caminhos escolhidos. Não garante que bibliotecas, CAs, configuração e permissões necessárias ao programa existam no destino. Na oficina fictícia, a API arranca mas falha a consulta HTTPS porque a CA aprovada ficou no stage anterior. Define o contrato com as equipas de desenvolvimento e RUN: utilizador, caminhos de escrita, dependências, integrações e critérios funcionais. Corrige a imagem mantida e repete o percurso. Uma alteração manual apenas na instância de teste separa o resultado observado do artefacto que será promovido.
Âmbito dos argumentos e plataforma desejada
Um ARG global não fica automaticamente disponível em cada stage. Quando necessário, consome-o nesse âmbito e confirma onde influencia a construção. Se o builder corre numa arquitetura e o destino noutra, distingue BUILDPLATFORM de TARGETPLATFORM e passa as opções corretas ao compilador. O suporte depende do programa, ferramentas e dependências; mudar uma etiqueta não converte instruções de máquina. Na ficha de release, regista como o binário foi produzido e que plataforma foi ensaiada. A declaração de uma intenção de destino não substitui a observação do resultado real.
Índice e variante são identidades diferentes
Um índice OCI pode referenciar vários manifests com descritores de plataforma. Na ficha fictícia, o índice I contém filhos A e B, respetivamente amd64 e arm64. Testar B num portátil não comprova A no cluster. Mantém a ligação entre índice, manifesto selecionado, plataforma e resultados de aceitação. Digests distintos destes objetos são esperados e não provam por si só adulteração. A tarefa do responsável pela mudança é explicar qual objeto foi testado, qual será usado e que evidência falta, de forma que negócio e RUN compreendam a decisão de prontidão.
Proveniência informa a revisão de mudança
Uma attestation pode descrever materiais e parâmetros de construção. A sua presença não é autorização do sponsor, ensaio funcional ou garantia de ausência de vulnerabilidades. Revê o objeto a que se refere, a origem da evidência e os critérios aplicáveis. Em mode=max, valores de build arguments podem ser expostos; o desenho deve evitar credenciais nesse mecanismo. Se existiu exposição, avalia os artefactos já publicados, além de corrigir a próxima build. Na passagem de turno, distingue evidência disponível, confiança nessa evidência e validações ainda necessárias para o serviço.
A promoção deve conservar a ligação à aprovação
No exercício, a etiqueta release-42 foi movida depois da aprovação. Compara a identidade resolvida com o digest registado e trata a divergência antes de distribuir. Outra ficha descreve uma cópia entre registries que mudou o digest e não preservou a attestation esperada. Investiga representação, exportação e suporte aos objetos necessários, sem concluir equivalência pelo nome nem adulteração só pela diferença. Se a transformação é legítima, documenta a correspondência e aplica os critérios de reavaliação. O objetivo é uma cadeia compreensível entre conteúdo, teste, aprovação e destino operacional.
Oficina de prontidão e passagem em inglês
Prepara uma reunião fictícia de mudança com três decisões: CA ausente no runtime, variante amd64 sem ensaio e divergência de digest no registry de destino. Para cada uma, apresenta impacto, evidência, responsável e próximo passo. A janela próxima não transforma uma lacuna num resultado positivo. Usa uma passagem curta: “The approved index is pinned, but the production variant has not passed the functional journey.” Regista também dependências operacionais e plano de reversão. Estes casos são originais; os ensaios de build e runtime continuam por executar num ambiente isolado adequado.
Ficha fictícia: índice I → A (amd64), B (arm64); só B foi ensaiado. Produção seleciona A. Fixar I conserva identidade, mas a prontidão de A exige evidência própria.
Armadilhas comuns
Aprovar pela etiqueta; confundir índice com manifesto filho; tratar proveniência como teste ou autorização; corrigir só a instância ensaiada; desativar TLS para cumprir a janela.
Tópicos relacionados: Build e distribuição · Compose e privilégios · Dados, persistência e recuperação validada
A promoção liga um artefacto identificado ao destino e à evidência de aceitação. Se conteúdo, variante ou dependências mudarem, torna a diferença explícita antes da decisão.
Referência: OCI Image Index Specification v1.1.1 · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped