Porque é que um serviço Compose usa o ficheiro de ambiente errado apenas depois de reiniciar o anfitrião?

Um serviço Compose pode utilizar valores de ambiente diferentes após um reinício quando o iniciador no arranque resolve outro diretório de projeto, ficheiro de ambiente ou fonte de precedência.

Um comando manual pode ser executado na pasta pretendida, com um ambiente de shell, enquanto o systemd, um agendador NAS ou o Portainer inicia o mesmo ficheiro Compose a partir de outro contexto após o arranque. O serviço também pode reiniciar um contentor existente cujo ambiente foi fixado no momento da criação, em vez de reler o ficheiro editado. Compare o modelo Compose renderizado e o ambiente do processo em execução a partir dos percursos manual e de arranque antes de editar vários ficheiros em simultâneo.

Compare o Ambiente em Execução com o Ficheiro Pretendido

Registe o ID do contentor, a hora de criação, a imagem, as etiquetas Compose, o nome do projeto e os valores efetivamente visíveis dentro do processo principal. Compare-os com o ficheiro de ambiente pretendido sem imprimir segredos em registos partilhados.

O ambiente de processo do Linux expõe os valores fornecidos no momento da execução, constituindo uma prova mais forte do que ler um ficheiro de ambiente que o contentor atual pode nunca ter utilizado.

Se o contentor contiver os valores antigos e for anterior à implementação no momento do arranque, o serviço pode simplesmente tê-lo reiniciado. Se o contentor for novo, continue a verificar a precedência e a resolução de caminhos.

Aplique a Precedência de Ambientes do Compose pela Ordem Correta

Liste todas as fontes de uma variável inofensiva: sinalizadores da CLI, valores da shell, environment:, env_file:, .env predefinido ou explícito e ENV da imagem.

O Docker define uma ordem formal de precedência de ambientes, pelo que um ficheiro de ambiente correto pode ainda perder para um valor de prioridade superior injetado pelo serviço de arranque ou pelo gestor da stack.

Não procure apenas nomes de ficheiros duplicados. Procure o nome da variável no modelo Compose renderizado, no ficheiro da unidade, nas definições do gestor, no ambiente da shell e nas predefinições da imagem.

Verifique o Diretório do Projeto e os Caminhos Relativos dos Ficheiros de Ambiente

Compare o diretório de trabalho do comando manual com o diretório de trabalho do iniciador no arranque, os argumentos dos ficheiros Compose, o diretório do projeto e as referências relativas a env_file.

A Especificação Compose define o modelo da aplicação utilizado para resolver serviços e configuração, pelo que a definição de projeto selecionada e os respetivos caminhos são entradas da implementação, não propriedades redescobertas a partir do contentor em execução.

Utilize caminhos absolutos para ficheiros de ambiente essenciais no arranque quando a ferramenta de implementação o permitir, ou defina explicitamente um diretório de projeto e um diretório de trabalho, para que os arranques manuais e automatizados resolvam os mesmos ficheiros.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Inspecione o Diretório de Trabalho e os Ficheiros de Ambiente do systemd

Leia a unidade efetiva, todas as substituições, WorkingDirectory=, Environment=, EnvironmentFile= e ExecStart=. Compare a unidade carregada no arranque com o comando utilizado manualmente.

As definições de execução do systemd definem o diretório de trabalho e os ficheiros de ambiente do serviço, que não herdam automaticamente o diretório atual nem as variáveis exportadas de uma shell de início de sessão interativa.

Depois de alterar uma unidade ou uma substituição, recarregue o gestor do systemd e inspecione novamente a unidade efetiva. Editar um modelo ou ficheiro não utilizado não altera o serviço que é realmente iniciado.

Verifique as Variáveis do Gestor de Stacks e o Estado de Implementação Armazenado

Se o Portainer ou uma interface NAS gerir a stack, compare as variáveis guardadas, o ficheiro de ambiente carregado, o caminho da implementação Git, o comportamento de atualização por webhook e o modelo Compose apresentado.

O Portainer distingue o comportamento de .env e stack.env, pelo que os valores introduzidos no gestor podem diferir dos de um ficheiro editado diretamente no anfitrião.

Escolha uma única fonte de verdade. Uma stack gerida a partir do Git ou de um editor Web não deve também ser iniciada manualmente a partir de outra cópia local após cada reinício.

Recrie o Contentor em vez de Apenas o Reiniciar

Compare a hora de criação do contentor com a hora de edição do ficheiro de ambiente. Renderize a configuração Compose pretendida e, em seguida, faça uma recriação controlada apenas do serviço afetado.

As orientações da Red Hat para o systemd recomendam verificar os ficheiros e as substituições efetivamente utilizados por um serviço antes de o reiniciar, evitando que uma unidade ou um wrapper obsoleto recrie o contentor com valores antigos.

Reiniciar um contentor não reconstrói o seu ambiente a partir do Compose. Recrie-o apenas depois de proteger os dados persistentes e confirmar que o modelo renderizado aponta para os volumes e segredos pretendidos.

Faça com que o Arranque Manual, o Reinício e a Nova Implementação Produzam o Mesmo Modelo

Fixe os ficheiros Compose, o nome do projeto, o diretório do projeto, o caminho do ficheiro de ambiente, o proprietário da stack e a dependência de arranque. Guarde uma configuração renderizada sem segredos e uma impressão digital inofensiva do ambiente.

O artigo da ZimaSpace sobre o âmbito das cópias de segurança do Docker apresenta a regra complementar: os ficheiros de ambiente e as definições de implementação devem ser preservados juntamente com o estado persistente.

O problema está resolvido quando uma recriação manual, um reinício do anfitrião, uma atualização agendada e uma nova implementação pelo gestor da stack criam todos o serviço com a mesma impressão digital de ambiente sem segredos.

Perguntas Frequentes

Qual é a diferença entre .env e env_file?

Um ficheiro .env do projeto fornece normalmente valores de interpolação ao Compose, enquanto um env_file de serviço fornece variáveis ao contentor. A interação e a precedência entre ambos dependem do modelo Compose completo.

Reiniciar um contentor recarrega um ficheiro de ambiente alterado?

Não. Os valores de ambiente são definidos quando o contentor é criado. Normalmente, é necessário recriar o serviço a partir da configuração Compose corrigida.

Porque é que o problema só aparece depois de um reinício?

O percurso de reinício pode utilizar uma unidade systemd, um agendador, variáveis guardadas pelo gestor, outro diretório de trabalho ou uma cópia antiga do Compose, diferente do arranque manual.