APRENDER. PRATICAR. EVOLUIR.O override pode acrescentar em vez de substituir
A base do laboratório declara publicação em 18080 e o override acrescenta 19090, ambos para o target 8080 e ligados a loopback. O modelo conserva duas entradas. Uma revisão apenas do override poderia concluir erradamente que a porta anterior desapareceu. Num caso fictício com uma publicação ampla na base, acrescentar loopback não restringe essa entrada herdada. O executor usado suporta !override, que permitiu conservar só a nova lista, e !reset, que a esvaziou. Confirma compatibilidade e resultado efetivo antes da aplicação; não deduzas exposição real sem observar a rede.
Comandos e mounts têm regras próprias
O mesmo ensaio substitui command e healthcheck.test sem concatenar argumentos. Para volumes, as entradas com target /work são combinadas pela identidade desse destino e fica um único bind, com a origem substituta e read_only=true. Evita uma regra mental única para todas as listas YAML. Lê o modelo e confirma o que desapareceu, o que permaneceu e o que mudou. Uma alteração ao healthcheck pode mudar a evidência necessária para o estado saudável. Um mount apenas de leitura também não demonstra que a origem contém os dados certos.
O caminho da base orienta os overrides
Com base/compose.yaml primeiro e overlays/merge.yaml depois, ./replacement-data resolve para base/replacement-data. O ensaio não altera project-directory e não usa include; observa a junção por -f. A origem não é relativa à pasta do override neste contexto. Num serviço fictício que lê ficheiros de fecho, esse erro pode selecionar dados ausentes ou de outro âmbito. Suspende a aplicação enquanto revês origem, conteúdo e permissões. O laboratório apenas resolveu o caminho e não criou mounts nem copiou os ficheiros que um consumidor real iria ler.
Perfis selecionam serviços, não concedem autorização
O modelo sem perfis contém api e db. Ativar diagnostics acrescenta debug e trace. A observação demonstra seleção na configuração, sem execução de qualquer diagnóstico. A documentação distingue ainda visar um serviço explicitamente de ativar todo o perfil: outros serviços associados não arrancam apenas por partilharem esse perfil. Esta segunda afirmação é documental, não um teste de arranque do laboratório. Revê alvos e dependências antes de uma operação e mantém controlo de acesso próprio. Um serviço com perfil continua a precisar de autorização, âmbito e critérios de utilização adequados.
Nomes de projeto e identidade dos dados
Os projetos lab-one e lab-two produzem nomes diferentes para o volume gerido: lab-one_managed e lab-two_managed. O volume externo com name=dr-shared-fixture mantém o mesmo nome nos dois modelos. O prefixo do projeto não basta para concluir isolamento desse recurso explicitamente nomeado. Antes de um ensaio de migração, verifica destino efetivo, propriedade e conjunto de dados autorizado. O resultado local não prova que o volume existe, que contém dados partilhados ou que foi montado. Mostra uma referência comum que precisa de ser resolvida antes de permitir escritas.
Dependências declaradas e recuperação real
O modelo final exige db saudável e migration concluída com sucesso. Inclui restart=true na dependência de db e restart=on-failure no serviço, campos com funções diferentes. O laboratório apenas analisa essas declarações. Numa release real, observa o que o healthcheck mede, o resultado da migração e o percurso do consumidor. Se a aplicação produziu dados que a imagem anterior não lê, trocar a imagem não resolve sozinho a recuperação. Prepara uma passagem com estado por serviço, dados afetados, decisões pendentes e responsáveis, sem chamar sucesso global à saída zero de config.
Merge normal: portas 18080 e 19090. !override: só 19090. Dois projetos: volumes geridos diferentes, mas a mesma referência externa dr-shared-fixture. Nenhum recurso foi criado.
Armadilhas comuns
Supor que a última lista substitui todas as anteriores; resolver caminhos a partir do override; tratar perfil como segurança; presumir isolamento de um volume externo; confundir rollback de imagem com recuperação de dados.
Tópicos relacionados: Build e distribuição · Dados e mounts · Diagnóstico e recuperação
Revê o modelo completo e a identidade dos recursos. A aceitação exige evidência do serviço e dos dados, além de configuração válida e gates de dependência declarados.
Referência: Merge Compose files: reference · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped