Come identificare quale dipendenza del container sta causando un loop di riavvii

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Identify Which Container Dependency Is Causing a Restart Loop

Identifica la prima dipendenza che diventa non disponibile prima che l’app termini, invece di considerare ogni container in riavvio come la causa principale.

In uno stack Docker Compose, l’applicazione visibile può entrare in loop perché un database è ancora in avvio, Redis è irraggiungibile, il DNS restituisce il servizio sbagliato, manca un bind mount, un secret è cambiato, una migrazione non è riuscita oppure l’app viene terminata per pressione sulla memoria. La diagnosi più rapida acquisisce il primo arresto e il primo errore relativo alla dipendenza, sospende i riavvii automatici, quindi verifica ogni servizio richiesto dalla stessa rete e con le stesse credenziali utilizzate dal container in errore.

Trova il primo container che non riesce ad avviarsi, non quello più rumoroso

Elenca il numero di riavvii, lo stato corrente, lo stato di salute, l’ultimo codice di uscita e l’ora di avvio di ogni servizio nello stack. Ordina la cronologia in modo che il primo errore compaia prima che i container secondari inizino a riconnettersi o a riavviarsi.

La guida di Netdata sui loop di riavvio mostra come i codici di uscita e gli stati distinguano gli arresti per OOM, i segmentation fault, le terminazioni regolari e gli arresti correlati allo stato di salute. Un segnale OOMKilled o del codice di uscita può escludere la necessità di analizzare le dipendenze quando in realtà l’app sta esaurendo la memoria o va in crash internamente.

Se una dipendenza non riesce ad avviarsi per prima, analizza quella prima dell’applicazione. Se l’app si arresta per prima con errori di connessione rifiutata, timeout, autenticazione o file mancante, associa quel messaggio alla dipendenza esatta che ha tentato di utilizzare.

Sospendi la raffica di riavvii e acquisisci un singolo errore pulito

Disabilita temporaneamente o sovrascrivi la policy di riavvio per il servizio interessato ed eseguilo una volta in primo piano, oppure esamina i log completi relativi a un singolo tentativo di avvio. Conserva i timestamp del demone Docker e di ogni dipendenza.

I riavvii automatici ripetuti possono sovrascrivere il primo errore significativo con errori di connessione successivi. Un container che si riavvia ogni pochi secondi può inoltre sovraccaricare il database, il resolver DNS o il volume dei log e creare sintomi secondari.

Non eliminare container, volumi o database durante questa acquisizione. Arresta solo la raffica di riavvii, riproduci il problema una volta e salva l’ambiente, i mount, le connessioni di rete, il comando e lo stato di uscita prima di modificare la configurazione.

Mappa ogni dipendenza necessaria al container per diventare pronto

Annota il database, la cache, la coda di messaggi, l’object store, il resolver DNS, il provider di identità, i file montati, i secret e le API esterne richiesti dall’app. Includi il nome del servizio previsto, la porta, il protocollo, il nome utente, il database e il percorso.

Dash0 spiega che l’ordine di avvio di Compose non significa automaticamente che il processo all’interno di una dipendenza sia pronto; un’app può avviarsi mentre Postgres è ancora in fase di inizializzazione. La soluzione consiste nell’attendere lo stato di salute della dipendenza, anziché limitarsi al suo stato di esecuzione.

Classifica le dipendenze come obbligatorie o facoltative. Un servizio di metriche facoltativo non disponibile non dovrebbe riavviare l’app principale, mentre un database non disponibile può richiedere un’attesa controllata, nuovi tentativi o un arresto.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Testa ogni dipendenza dalla rete del container in errore

Usa un container diagnostico temporaneo collegato alla stessa rete oppure avvia una shell supportata prima che l’app termini. Testa il DNS del nome del servizio, la porta TCP, TLS, l’autenticazione, la query al database e il percorso richiesto, in quest’ordine.

La guida di Last9 sui controlli di salute di Compose osserva che i readiness check impediscono ai servizi dipendenti di avviarsi finché i componenti critici non sono effettivamente in grado di rispondere. Un controllo utile convalida l’operazione del servizio richiesta dai client, invece di confermare soltanto l’esistenza di un processo.

Se il DNS non funziona, controlla l’appartenenza alla rete e gli alias. Se la connessione TCP viene stabilita ma l’autenticazione non riesce, confronta i secret e gli utenti. Se l’accesso funziona ma mancano lo schema, il bucket, la coda o la directory previsti, correggi l’inizializzazione anziché la rete.

Controlla mount, secret e migrazioni come dipendenze

Confronta i bind mount attuali, i volumi denominati, i permessi, la proprietà, i file di ambiente, i file dei secret e la versione dell’applicazione con l’ultima distribuzione funzionante. Un container può raggiungere il database e tuttavia riavviarsi perché un file di configurazione è di sola lettura o una migrazione non può scrivere.

Un caso di studio sull’avvio di un container mostra che l’ordine delle dipendenze basato sullo stato di salute può impedire all’applicazione di andare in crash prima che il database sia pronto. La sequenza di avvio condizionale diventa particolarmente importante durante il primo avvio e le migrazioni.

Esegui le migrazioni una sola volta con i log visibili ed esegui il backup del database prima di riprovare operazioni distruttive. Se la versione dell’app è cambiata, verifica che la versione della dipendenza e il percorso di aggiornamento dello schema siano supportati.

Riabilita i servizi nell’ordine delle dipendenze e convalida la stabilità

Avvia prima la dipendenza di livello più basso, attendi il suo controllo di salute effettivo, quindi avvia il livello successivo e infine l’applicazione. Registra il numero di riavvii e le transizioni dello stato di salute per diversi intervalli di controllo.

La guida di ZimaSpace sui malfunzionamenti del DNS dal container illustra un percorso di dipendenza che può manifestarsi solo all’interno dell’ambiente dell’app.

Il problema è risolto solo quando l’applicazione si avvia una volta, tutte le dipendenze obbligatorie rimangono in salute, le migrazioni vengono completate e un riavvio deliberato della dipendenza attiva un nuovo tentativo o un recupero controllato, invece di un altro loop. Ripristina una policy di riavvio solo dopo che l’errore principale è osservabile e circoscritto.