Perché un servizio Compose usa il file .env sbagliato solo dopo il riavvio dell’host?
Un servizio Compose può utilizzare valori di ambiente diversi dopo il riavvio quando il launcher eseguito all’avvio risolve un’altra directory del progetto, un altro file env o un’altra fonte di precedenza.
Un comando manuale può essere eseguito dalla cartella corretta con un determinato ambiente della shell, mentre systemd, uno scheduler NAS o Portainer avvia lo stesso file Compose da un contesto diverso dopo l’avvio. Il servizio potrebbe anche riavviare un container esistente il cui ambiente è stato fissato al momento della creazione, invece di rileggere il file modificato. Prima di modificare più file contemporaneamente, confronta il modello Compose renderizzato e l’ambiente del processo in esecuzione nei percorsi manuale e di avvio.
Confronta l’ambiente in esecuzione con il file previsto
Annota l’ID del container, l’ora di creazione, l’immagine, le etichette Compose, il nome del progetto e i valori effettivamente visibili nel processo principale. Confrontali con il file env previsto senza stampare i segreti nei log condivisi.
L’ambiente del processo Linux espone i valori forniti al momento dell’esecuzione, offrendo una prova più solida rispetto alla lettura di un file env che il container corrente potrebbe non aver mai utilizzato.
Se il container contiene i vecchi valori ed è stato creato prima della distribuzione eseguita al riavvio, il servizio potrebbe essersi limitato a riavviarlo. Se il container è nuovo, continua verificando la precedenza e la risoluzione dei percorsi.
Applica la precedenza delle variabili d’ambiente Compose nell’ordine corretto
Elenca ogni fonte per una variabile innocua: flag CLI, valori della shell, environment:, env_file:, .env predefinito o esplicito e ENV dell’immagine.
Docker definisce un ordine formale di precedenza delle variabili d’ambiente, quindi un file env corretto può comunque perdere a favore di un valore con priorità maggiore iniettato dal servizio di avvio o dal gestore dello stack.
Non cercare soltanto nomi di file duplicati. Cerca il nome della variabile nel modello Compose renderizzato, nel file dell’unità, nelle impostazioni del gestore, nell’ambiente della shell e nei valori predefiniti dell’immagine.
Controlla la directory del progetto e i percorsi env relativi
Confronta la directory di lavoro del comando manuale con quella del launcher di avvio, gli argomenti dei file Compose, la directory del progetto e i riferimenti relativi a env_file.
La Compose Specification definisce il modello applicativo utilizzato per risolvere servizi e configurazione, quindi la definizione del progetto selezionata e i relativi percorsi sono input della distribuzione, non proprietà riscoperte dal container in esecuzione.
Utilizza percorsi assoluti per i file env essenziali all’avvio quando lo strumento di distribuzione lo consente, oppure imposta esplicitamente la directory del progetto e quella di lavoro, così che gli avvii manuali e automatici risolvano gli stessi file.
Ispeziona la directory di lavoro e i file d’ambiente di systemd
Leggi l’unità effettiva, tutti i drop-in, WorkingDirectory=, Environment=, EnvironmentFile= ed ExecStart=. Confronta l’unità caricata all’avvio con il comando utilizzato manualmente.
Le impostazioni di esecuzione di systemd definiscono la directory di lavoro e i file d’ambiente del servizio, che non ereditano automaticamente la directory corrente o le variabili esportate da una shell interattiva di login.
Dopo aver modificato un’unità o un drop-in, ricarica il gestore systemd e ispeziona nuovamente l’unità effettiva. Modificare un modello o un file inutilizzato non cambia il servizio che viene realmente avviato.
Controlla le variabili del gestore dello stack e lo stato di distribuzione memorizzato
Se Portainer o un’interfaccia NAS gestisce lo stack, confronta le variabili salvate, il file env caricato, il percorso della distribuzione Git, il comportamento di aggiornamento tramite webhook e il modello Compose visualizzato.
Portainer distingue il comportamento di .env e stack.env, quindi i valori inseriti nel gestore possono differire da quelli di un file modificato direttamente sull’host.
Scegli un’unica fonte di verità. Uno stack gestito da Git o da un editor web non dovrebbe essere avviato manualmente anche da un’altra copia locale dopo ogni riavvio.
Ricrea il container invece di limitarti a riavviarlo
Confronta l’ora di creazione del container con quella della modifica del file env. Esegui il rendering della configurazione Compose prevista, quindi ricrea in modo controllato solo il servizio interessato.
Le indicazioni di Red Hat per systemd raccomandano di controllare i file e le sostituzioni effettivamente utilizzati da un servizio prima di riavviarlo, evitando che un’unità obsoleta o un wrapper ricrei il container con i vecchi valori.
Il riavvio di un container non ricostruisce il suo ambiente da Compose. Ricrealo solo dopo aver protetto i dati persistenti e aver verificato che il modello renderizzato punti ai volumi e ai segreti previsti.
Fai in modo che avvio manuale, riavvio e nuova distribuzione producano lo stesso modello
Fissa i file Compose, il nome del progetto, la directory del progetto, il percorso del file env, il proprietario dello stack e la dipendenza dall’avvio. Salva una configurazione renderizzata priva di segreti e un’impronta dell’ambiente innocua.
L’articolo di ZimaSpace sull’ambito del backup Docker fornisce la regola correlata: i file d’ambiente e le definizioni di distribuzione devono essere conservati insieme allo stato persistente.
Il problema è risolto quando una ricreazione manuale, il riavvio dell’host, un aggiornamento pianificato e una nuova distribuzione dal gestore dello stack creano tutti il servizio con la stessa impronta dell’ambiente priva di segreti.
Domande frequenti
Qual è la differenza tra .env ed env_file?
Un file .env del progetto fornisce comunemente valori di interpolazione a Compose, mentre un env_file del servizio fornisce variabili al container. La loro interazione e precedenza dipendono dal modello Compose completo.
Il riavvio di un container ricarica un file env modificato?
No. I valori d’ambiente vengono impostati quando il container viene creato. Normalmente è necessario ricreare il servizio dalla configurazione Compose corretta.
Perché il problema compare solo dopo il riavvio?
Il percorso di riavvio potrebbe utilizzare un’unità systemd, uno scheduler, variabili memorizzate nel gestore, un’altra directory di lavoro o una copia Compose più vecchia, diversa da quella utilizzata per l’avvio manuale.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
