‫Il comando Controllo stato Docker. Era una nuova funzionalità aggiunta in 1. 12, che è uscito a metà del 2016, nello
‫stesso momento in cui Swarm Kit e Swarm Mode erano disponibili in Docker. È stato aggiunto davvero come parte di quel toolkit, ma
‫funziona ancora in tutti i diversi file come il Dockerfile, il file Compose, il comando di esecuzione docker lo utilizza, i
‫file Stack lo supportano, l'aggiornamento del servizio e il comando di creazione del servizio lo supportano
‫.
‫È ovunque.
‫Consiglio vivamente che quando si va in produzione, si impegnano a testare le opzioni per questo comando di
‫controllo sanitario.
‫Funzionerà immediatamente con un exec.
‫Eseguirà questo comando all'interno del contenitore proprio come se si stesse eseguendo il proprio
‫comando exec.
‫Quindi, non viene eseguito da fuori dal contenitore; è solo eseguirlo dentro il che significa
‫che anche i lavoratori semplici che non hanno porte esposte, è possibile eseguire un semplice comando al loro interno
‫per convalidare se stanno restituendo dati buoni o altro.
‫È una semplice esecuzione di un comando, il che significa che ottiene un semplice ritorno. Si aspetta uno 0 o un 1.
‫In Linux e Windows, hai i codici di uscita dai comandi e uno 0 è una buona cosa.
‫Significa che tutto andava bene.
‫Qualsiasi cosa diversa da uno 0 sarà un errore nella maggior parte delle applicazioni.
‫Ma in Docker, abbiamo bisogno di quell'applicazione per uscire da 1 in particolare. Mostreremo in un minuto come
‫lo fai.
‫Ci sono solo tre stati per un healthcheck in Docker. Inizia con l'avvio. L'avvio è il primo 30 secondi,
‫per impostazione predefinita, in cui non è ancora stato eseguito un comando healthcheck.
‫Quindi ne eseguirà uno.
‫Se quello restituisce uno 0, inizierà con il sano. Cambierà all'opzione sana.
‫Prenderà questo comando e lo eseguirà ogni 30 secondi per impostazione predefinita. Se riceve sempre un ritorno malsano, come
‫un'uscita 1, lo contrassegna come un contenitore malsano.
‫Abbiamo opzioni per controllare tutto questo inclusi i tentativi.
‫Lo vedremo tra un minuto.
‫Questa è un'opzione molto migliore di quella che abbiamo avuto in passato perché Docker, fino ad ora, si stava solo
‫assicurando che l'applicazione fosse ancora in esecuzione.
‫Non aveva alcuna idea se quella applicazione stava facendo quello che doveva.
‫Ora possiamo farlo all'interno del contenitore Docker stesso.
‫Ma questo non è un sostituto per la soluzione di monitoraggio di terze parti.
‫Questo non ti darà grafici, o lo stato nel tempo, o qualsiasi tipo di strumenti di terze parti che ti aspetteresti
‫da una soluzione di monitoraggio.
‫Si tratta della comprensione di Docker se il contenitore stesso ha un livello base di salute.
‫Quindi, in un Nginx, potrebbe restituire un host locale del file indice radice. Un ritorno di 200 o 300 va bene e gli dà un
‫codice di uscita di 0, e lo considera sano.
‫Questo non è uno strumento di monitoraggio molto avanzato, sai.
‫restituisse un errore 404 o 500, lo considererebbe malsano e potremmo fare qualcosa al riguardo.
‫Ma se
‫Dove stiamo andando a vedere questo healthcheck Docker nella GUI?
‫Il primo posto è nel contenitore ls.
‫Lo vedrà solo come questa nuova opzione.
‫È nel mezzo Vedremo in un secondo dove ci mostrerà uno dei tre stati se il controllo dello
‫stato di salute è in esecuzione, ed è così che in realtà sappiamo che c'è un healthcheck.
‫Questo è il modo più semplice, almeno, per sapere. Vedremo la cronologia, gli ultimi cinque di
‫questo healthcheck, mostrati nell'ispezione per quel container. E possiamo vedere alcune tendenze di base nel tempo lì.
‫Ma il comando di esecuzione della finestra mobile non agisce su un contenitore non integro.
‫Una volta che lo healthcheck considera un contenitore non integro, l'esecuzione della finestra mobile indica solo quella
‫nel comando ls e nell'ispezione, ma non agirà.
‫Ecco dove ci aspettiamo che i Servizi Swarm agiscano.
‫Quindi stack e servizi sostituiranno effettivamente quel container con una nuova attività, eventualmente su un nuovo host,
‫a seconda dello scheduler.
‫update, vediamo un po 'di bonus in più usando gli healthcheck perché gli aggiornamenti considereranno lo
‫healthcheck come parte della preparazione per quel container prima che vada e cambi il prossimo.
‫Anche nel comando
‫Se viene visualizzato un contenitore, ma non passa il controllo dello stato, l'aggiornamento del
‫servizio non passerà al successivo. Oppure agirà in base alle modifiche che gli dai.
‫Diamo un'occhiata ad alcuni esempi prima di andare alla riga di comando.
‫Questo è quello che stiamo usando su docker run.
‫Questo ci consente di utilizzare un'immagine esistente che non ha un controllo di integrità, e stiamo aggiungendo il controllo
‫dello stato di salute in fase di esecuzione.
‫In questo caso, stiamo usando l'immagine Elasticsearch. contenitore, non nella porta pubblicata, ma all'interno del contenitore.
‫È possibile vedere che il comando è un localhost 9200 cURL, ovvero la porta su cui è in
‫esecuzione Elasticsearch all'interno del Per Elasticsearch, esiste
‫un URL di salute effettivo.
‫Quindi, possiamo usarlo qui.
‫Noterai le due pipe con il falso alla fine di quel comando.
‫E questo sarà abbastanza comune
‫se si usa qualcosa come cURL o un altro strumento che invierà un codice di errore diverso da 1.
‫Ricordi quando ti ho detto che tempo fa? Ne abbiamo bisogno per uscire con 1 se c'è un problema. cui Docker farà qualcosa.
‫Perché questo è l'unico codice di errore su
‫Dobbiamo assicurarci che in questo caso, una shell restituirà sempre il falso 1 exit code se c'è
‫qualcosa che esce da quel comando diverso da 0.
‫È un bel modo per aggirare questo problema.
‫Accade solo con cURL, cURL darà altri potenziali codici di errore e non vogliamo che
‫lo faccia.
‫Nei file Docker effettivi, possiamo aggiungere lo stesso comando. Il formato è un po 'diverso. Ma vedi che
‫abbiamo queste opzioni qui. Abbiamo l'intervallo, il timeout, il periodo di inizio (che è nuovo) e riproviamo.
‫L'intervallo è ciò che penseresti che sia. È, per impostazione predefinita, ogni 30 secondi.
‫Quante volte eseguirà questo controllo sanitario. Il timeout è il tempo di attesa prima che si verifichi
‫un errore e restituisca un codice errato, se forse l'app è lenta. Il periodo di inizio è una nuova funzionalità l'intervallo di tempo prima che
‫che ci consente ora di 17. 09 e più recenti, per dare un periodo di attesa più lungo rispetto ai primi 30 secondi della durata. Prima, avrebbe sempre dovuto Ma forse hai un'app o un database Java, o qualcosa che richiede molto più tempo per iniziare.
‫aspettare il lungo. iniziasse lo healthcheck. Forse ci vogliono cinque minuti.
‫Potresti aggiungere quel periodo iniziale qui. Farà ancora i controlli. Ma quello che farà è che non allarmerà con un assegno malsano
‫fino a quel momento.
‫volta superato il segno di due minuti.
‫Quindi, se ci metti due minuti, anche se è il controllo della salute ogni 30 secondi, lo considererà solo malsano una L'ultimo lì, tentativi, significa che proveremo questo controllo
‫sanitario x numero di volte prima che consideriamo malsano.
‫Ciò dà forse a un'app potenzialmente instabile la possibilità
‫di tornare in salute e di riprendersi da sola, prima di considerarlo un contenitore davvero malsano.
‫Il comando healthcheck di base che useresti in un Dockerfile
‫si chiama HEALTHCHECK, tutte lettere maiuscole. Lo stesso formato esiste dove se stiamo facendo semplicemente un cURL dell'host
‫locale perché forse è un'app PHP o qualcosa del genere. Possiamo farlo.
‫in modo da vedere come aggiungo l'intervallo di timeout e i tentativi prima del comando stesso.
‫Ecco come aggiungerei tutte queste opzioni a un Dockerfile
‫Il primo lì per il comando di base, si noti che non devo
‫inserire un CMD se gli sto solo dando il comando per l'esecuzione. Ma se voglio mostrare le opzioni, se voglio dargli le opzioni personalizzate fuori
‫dalla scatola con il timeout e così via, allora devo specificare quale è il comando.
‫Ora queste non sono due linee diverse.
‫Notare la barra rovesciata alla fine della prima linea lì.
‫Quindi non confonderlo.
‫potrebbe essere se tu avessi un'applicazione statica in esecuzione all'interno di un server Nginx.
‫Qui abbiamo un semplice esempio di come
‫È possibile impostare l'intervallo e il timeout dal Dockerfile, e si dovrebbe semplicemente fare un
‫comando cURL sul localhost.
‫Se restituisce un 200 o 300, lo ritiene valido. Se restituisce un 4, o 5, o
‫qualcos'altro, considera un errore.
‫Qui noti che ho un'uscita 1, che è la stessa cosa di un falso.
‫L'ho fatto solo per mostrarti che alcuni esempi su Internet avranno un falso. Alcuni
‫esempi avranno un'uscita 1.
‫Entrambi fanno la stessa cosa.
‫Ecco un esempio un po 'più avanzato.
‫In questo caso, stiamo utilizzando un'app PHP combinata con Nginx.
‫Quello che ho fatto è, nelle risorse, troverai un link a questo esempio di PHP. Ho aggiunto un file di configurazione
‫Nginx personalizzato che utilizza gli URL di stato Nginx e PHP-FPM.
‫Entrambe queste applicazioni hanno una propria pagina di stato e una specie di URL ping di healthcheck.
‫Puoi usare quelli nelle tue app se usi PHP o Nginx. Esistono due URL diversi, ma è
‫possibile utilizzarli entrambi nello stesso healthcheck.
‫In questo caso, ne usiamo solo uno
‫e stiamo lanciando localhost / ping, che in
‫realtà è un comando di stato PHP-FPM, ma devi abilitarlo all'interno del tuo PHP-FPM. Ancora una volta, nelle risorse di questa lezione, c'è un collegamento a un buon valore predefinito
‫di Docker di PHP.
‫Puoi andare a dare un'occhiata a un GitHub in cui ho mostrato questo esempio in modo un po 'più dettagliato.
‫Poi abbiamo un esempio di Postgres quindi nel Dockerfile posso usare un URL diverso.
‫Qui abbiamo un'applicazione Postgres in cui nel comando healthcheck, sto usando un comando di pg isready.
‫Ora, con diverse app, ci sono diversi strumenti. molto semplice di una connessione a un server Postgres.
‫Con Postgres, viene fornito con uno strumento integrato, che è un test
‫Non convalida che tu abbia dati buoni o che il tuo database sia montato correttamente. Semplicemente dirà: 'Questo
‫server database consente le connessioni? Si o no? 'Questo è uno che si può
‫fare fuori dalla scatola.
‫Ecco come apparirebbe in un file compositore / stack.
‫Molto simile.
‫Noterai che il periodo di avvio laggiù richiede una versione diversa.
‫Dal momento che il comando healthcheck è uscito in 1. 12, è stato effettivamente supportato in 2. Compose.
‫1 di questo file
‫Ma, se intendi utilizzare il periodo di avvio, significa che devi aggiornare il file
‫Compose alla versione 3. 4 per sostenerlo. Perché il
‫periodo di avvio è uscito più di un anno dopo il comando healthcheck.
‫Iniziamo con alcuni semplici comandi di esecuzione.
‫Quello che faremo qui è che avvieremo un server di database Postgres
‫senza lo healthcheck perché di default non ne viene fornito uno.
‫un comando healthcheck manuale che verrà aggiunto alla riga di comando e vedremo la differenza.
‫Quindi lo eseguiremo di nuovo con
‫Qui, chiameremo il primo p1. Lo eseguiremo staccato
‫dall'immagine ufficiale di Postgres.
‫Se eseguo una finestra mobile container ls, noterai che non c'è nulla che indichi un healthcheck qui.
‫Se eseguiamo di nuovo lo stesso comando e lo chiamiamo p2 questa volta, aggiungeremo un comando di integrità.
‫Questa volta, useremo il pg isready, di cui abbiamo
‫parlato prima, per verificare che le connessioni siano disponibili su questo server Postgres. Diremo che l'utente di cui abbiamo bisogno
‫è l'utente postgres. In realtà non abbiamo bisogno di dargli una password. tenterà di accedere.
‫Non Proverà a convalidare. Useremo l'immagine di Postgres.
‫Ora, se eseguiamo una finestra mobile container ls, e faccio un piccolo
‫zoom indietro, vedrete che dice: "Sta per iniziare una salute di 4 secondi. 'Ora otteniamo
‫questa funzionalità aggiuntiva nel nostro stato del comando ls. Rimarrà nello stato iniziale per i 30 secondi predefiniti fino a quando non viene eseguito
‫il
‫comando healthcheck per la prima volta.
‫Ora che abbiamo atteso più di 30 secondi, vedrai che è cambiato in stato di salute.
‫abbiamo questa nuova opzione sullo stato di salute.
‫Se eseguiamo ispezioni su container p2 su un container docker, in cima a ciò vedremo che In questo caso, sono stato in grado di eseguirlo solo due volte.
‫Puoi vedere l'output lì, che sta mostrando che accetta le connessioni.
‫Tutto ok. Facciamo un po 'di servizio per creare comandi sullo stesso database, nello stesso test di controllo.
‫Quello che vedremo qui quando lo facciamo è che ci sono tre diversi
‫stati che un servizio passa all'avvio.
‫Si sta preparando, il che di solito significa che sta scaricando l'immagine. Sta iniziando, il che significa che sta eseguendo il container e lo sta
‫facendo apparire. Quindi è in esecuzione.
‫Senza il comando healthcheck, l'avvio e l'esecuzione sono molto veloci. Sono quasi istantanei.
‫Vedremo che qui con un servizio docker creare il nome p1 postgres.
‫Una volta terminata la preparazione scaricando
‫l'immagine, vedrai che va immediatamente dall'inizio alla sua esecuzione, perché non esiste alcun healthcheck. Non ha nient'altro da fare se non
‫avviare il contenitore e dire: "Sì. Il file binario è in esecuzione. 'Ma se facciamo lo stesso comando, il servizio docker crea, e lo chiamiamo p2
‫come prima, e gli diamo lo stesso comando
‫di salute.
‫Iniziamo questo servizio con il comando healthcheck integrato.
‫all'esecuzione del primo healthcheck.
‫Quello che vedremo è che andrà dalla preparazione all'avvio, e si posizionerà allo stato iniziale per i 30 secondi predefiniti fino
‫Questo è ora il servizio Docker che si aspetta uno stato
‫integro prima che consideri questo servizio pienamente operativo. Dopo 30 secondi, passerà allo stato di esecuzione. Poi otteniamo l'ultima piccola verifica lì,
‫solo per assicurarci che sia considerato stabile, e quindi abbiamo finito.
‫Puoi già vedere, fuori dagli schemi, che con i servizi, oltre agli
‫aggiornamenti di servizio, otterremo questo extra bonus del concetto di salute se usiamo questi comandi ogni volta che possiamo.
‫