Perché il controllo dello stato di salute di un container fallisce mentre l’app continua ad aprirsi?
Un container può continuare a essere utilizzabile anche quando il suo controllo dello stato non va a buon fine, perché la sonda verifica un comando, un indirizzo, un utente o una condizione di disponibilità diversi dal percorso utilizzato dal browser.
Su un home server, l’app può essere accessibile tramite un proxy inverso anche se Docker esegue il comando di controllo dello stato all’interno del container, verificando localhost, un’utilità mancante, la porta errata o una dipendenza temporaneamente non disponibile. Inizia riproducendo la sonda esatta all’interno del container, quindi confronta la destinazione e il risultato atteso con il percorso reale dell’utente prima di aumentare i tentativi o disabilitare il controllo dello stato.
Confronta ciò che verifica il browser con ciò che verifica il controllo dello stato
Annota l’URL e il percorso di rete che consentono di aprire correttamente l’applicazione. Indica se il browser raggiunge un proxy inverso, una porta dell’host pubblicata, un IP locale o direttamente il container.
Docker esegue la sonda configurata all’interno del container, quindi potrebbe verificare un endpoint diverso da quello utilizzato dal browser. Un caso nella community Docker ha mostrato un controllo dello stato non riuscito perché l’immagine non conteneva il comando curl usato dalla sonda, anche se il processo del servizio continuava a funzionare.
Se il percorso funzionante del browser passa attraverso un altro proxy o un’altra porta, non considerare questo risultato una prova che la destinazione della sonda interna sia corretta. Annota entrambi i percorsi e identifica il primo componente che differisce.
Esegui il comando esatto del controllo dello stato all’interno del container
Copia il comando del controllo dello stato esattamente, inclusi la forma shell, l’URL, le opzioni, le credenziali e le variabili d’ambiente. Eseguilo all’interno del container in esecuzione con lo stesso utente e acquisisci il codice di uscita e l’output.
Un container contrassegnato come non integro può comunque avere un processo in esecuzione, perché lo stato di salute riflette il risultato della sonda, non la possibilità per gli utenti di caricare una pagina. Il flusso diagnostico di Netdata distingue il fallimento della sonda dal fallimento del processo prima di modificare il comportamento di riavvio.
Se il comando riesce manualmente, confronta l’utente di esecuzione, la shell, la directory di lavoro, l’ambiente e i tempi utilizzati dal controllo automatico. Se fallisce manualmente, l’errore identifica ora il livello successivo senza dover attendere un altro intervallo di controllo dello stato.
Controlla lo strumento della sonda, la shell, PATH e l’utente
Verifica che ogni eseguibile utilizzato nel comando del controllo dello stato esista nell’immagine corrente e possa essere eseguito dall’utente del container. Le immagini minimali potrebbero non includere curl, wget, bash, gli strumenti DNS o gli archivi dei certificati.
Le sonde in formato shell e in formato exec si comportano in modo diverso. Virgolette, pipe, espansione delle variabili e comandi composti richiedono una shell disponibile, mentre un comando diretto necessita del percorso completo dell’eseguibile quando l’ambiente del controllo dello stato ha un PATH limitato.
Esegui il comando con un percorso assoluto e con l’utente di servizio previsto. Correggi l’immagine o la sonda invece di installare strumenti in modo interattivo, perché una modifica manuale al container scompare alla ricostruzione successiva.
Verifica indirizzo interno, porta e protocollo
Controlla il listener dell’applicazione all’interno del container e confrontalo con l’URL della sonda. Una porta dell’host pubblicata, come 8080:80, non significa che il servizio sia in ascolto sulla porta 8080 all’interno del container.
I controlli dello stato dovrebbero verificare lo stato dell’applicazione controllato dal container. La guida pratica di Dash0 osserva che una sonda può chiamare un endpoint HTTP o ispezionare un processo, ma l’endpoint deve riflettere l’effettivo stato di disponibilità del container, invece di una route disponibile solo tramite un proxy esterno.
Verifica 127.0.0.1, l’indirizzo di ascolto del container e il nome del servizio solo quando ciascuno è appropriato. Se l’applicazione è associata solo a un socket Unix o a un’altra interfaccia, modifica la sonda affinché utilizzi il reale punto di accesso interno.
Distingui un avvio lento da un errore permanente
Misura quanto tempo impiegano l’applicazione, la migrazione del database, il riscaldamento della cache o il caricamento del modello prima che l’endpoint corretto risponda. Confronta questo tempo con start_period, interval, timeout e retries.
Compose può bloccare i servizi dipendenti quando una dipendenza è ancora contrassegnata come non integra, anche se in seguito diventa pronta. Una regressione segnalata in Compose ha mostrato un servizio diventare integro solo dopo che il fallimento della dipendenza aveva già arrestato lo stack, evidenziando una finestra di avvio del controllo dello stato troppo limitata.
Aumenta i tempi solo quando i log dimostrano che l’app sta avanzando normalmente. Più tentativi non devono nascondere una porta errata, una migrazione fallita, un certificato mancante o un database irraggiungibile.
Mantieni la sonda mirata e verifica il ripristino
Stabilisci se il controllo dello stato debba rappresentare la vitalità del processo, la disponibilità dell’applicazione locale o una catena più profonda di dipendenze. Non rendere non integro un container locale solo perché un’API esterna facoltativa non è disponibile.
La guida di ZimaSpace su come trovare la prima dipendenza non riuscita è il passaggio successivo quando l’applicazione non può diventare pronta senza un database, una cache o un servizio di rete.
Il problema è risolto quando la sonda automatica esatta ha esito positivo dopo il normale avvio, il container rimane integro durante i riavvii delle dipendenze e il flusso di lavoro reale dell’app continua a essere disponibile. Mantieni la sonda abbastanza rigorosa da rilevare un servizio guasto, ma sufficientemente mirata da evitare falsi errori causati da sistemi non correlati.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
