‫Comanda de control al Docker Health Check. A fost o caracteristică nouă adăugată în 1. 12, care a ieșit la mijlocul anului 2016,
‫în același timp când Kitul Swarm și modul Swarm erau disponibile în Docker. A fost adăugat într-adevăr ca parte a acelui
‫set de instrumente, dar funcționează în continuare în toate fișierele diferite, cum ar fi fișierul Dockerfile, fișierul Compose,
‫comanda docker run îl folosește, fișierele Stack suportă, actualizarea serviciului și comanda create create
‫.
‫Este peste tot.
‫Vă recomandăm foarte mult ca, atunci când veți merge la producție, să vă angajați în opțiunile de testare pentru această comandă de
‫verificare a sănătății.
‫O să meargă imediat din cutie cu un exec.
‫Va executa acea comandă în interiorul containerului, ca și cum ai fi executat propria comandă
‫exec.
‫Deci, nu o rulează din afara containerului; doar o rulați înăuntru ceea ce înseamnă că
‫chiar și lucrătorii simpli care nu au porturi expuse, puteți executa o comandă simplă în ele pentru a valida
‫dacă returnează date bune sau orice altceva.
‫Este o execuție simplă a unei comenzi, ceea ce înseamnă că are o întoarcere simplă. Se așteaptă un 0 sau un 1.
‫În Linux și Windows, aveți coduri de ieșire din comenzi și un 0 este un lucru bun.
‫Înseamnă că totul era bine.
‫Orice altceva decât 0 va fi o eroare în majoritatea aplicațiilor.
‫Dar în Docker, avem nevoie de acea aplicație pentru a ieși dintr-un mod 1 în mod specific. Vom arăta într-un minut cum
‫faceți asta.
‫Există doar trei stări la o verificare de sănătate în Docker. Începe cu începerea. Pornirea este în primele 30 de secunde,
‫în mod implicit, unde încă nu a fost lansată încă o comandă de healthcheck.
‫Atunci o să ruleze una.
‫În cazul în care returnează un 0, va începe cu cel sănătos. Se va schimba la opțiunea sănătoasă.
‫Va lua comanda și va porni din nou la fiecare 30 de secunde. Dacă primește întotdeauna o întoarcere nesănătoasă, ca
‫o ieșire 1, atunci o marchează ca un container nesănătoase.
‫Avem opțiuni pentru a controla toate acestea, inclusiv încercări.
‫Vom vedea asta într-un minut.
‫Aceasta este o opțiune mult mai bună decât cea pe care am avut-o în trecut, deoarece Docker, până acum,
‫se asigura că aplicația încă funcționa.
‫Nu avea nicio perspectivă asupra faptului dacă cererea făcea ceea ce trebuia să facă.
‫Acum putem face asta în interiorul containerului Docker.
‫Dar acest lucru nu reprezintă un înlocuitor pentru soluția de monitorizare a terțelor părți.
‫Acest lucru nu vă va oferi grafice sau starea în timp sau orice fel de instrumente terță parte pe care le-ați
‫aștepta dintr-o soluție de monitorizare.
‫Este vorba de înțelegerea Docker dacă containerul în sine are un nivel de bază de sănătos.
‫Deci, într-un Nginx, s-ar putea să întoarcă o localhost a fișierului cu indexul rădăcină. O întoarcere de 200 sau 300 este bună și îi dă un cod
‫de ieșire de 0 și o consideră sănătoasă.
‫Nu e un instrument de monitorizare super avansat.
‫Dar dacă ar fi revenit o eroare de 404 sau 500, atunci ar considera că este nesănătoasă și putem face ceva
‫în acest sens.
‫Unde vom vedea această verificare de sănătate a Docker-ului în GUI?
‫Primul loc este în recipientul ls.
‫Se va vedea doar ca această nouă opțiune.
‫E în mijloc. Vom vedea într-o secundă unde ne va arăta una dintre cele trei state dacă
‫se va efectua controlul de sănătate și așa știm de fapt că există o verificare a sănătății.
‫E cel mai ușor, cel puțin, să știi. Vom vedea istoria, ultimele cinci din acea
‫verificare a sănătății, să apară în inspecția pentru containerul respectiv. Și putem vedea o tendință de bază în timp acolo.
‫Dar comanda derby-ului nu ia măsuri pentru un container nesănătoase.
‫Odată ce Healthcheck consideră un container nesănătoasă, rularea docker-ului va indica doar că în comanda ls
‫și în inspecție, dar nu va lua măsuri.
‫Aici așteptăm ca Serviciile Swarm să ia măsuri.
‫Astfel, stivele și serviciile vor înlocui containerul cu o nouă sarcină, într-o nouă gazdă, în
‫funcție de programator.
‫Chiar și în comanda de actualizare, vedem un mic bonus suplimentar prin utilizarea controalelor de sănătate, deoarece
‫actualizările vor lua în considerare healthcheck ca parte a pregătirii pentru acel container înainte de a merge și
‫schimbă următorul.
‫Dacă apare un container, dar nu trece verificarea sa de sănătate, atunci actualizarea serviciului
‫nu va trece la următoarea. Sau va lua măsuri bazate pe modificările pe care le dați.
‫Să ne uităm la câteva exemple înainte de a merge la linia de comandă.
‫Aceasta este una pe care o folosim la rularea dockerilor.
‫Acest lucru ne permite să folosim o imagine existentă care nu are o verificare de sănătate în ea și
‫adăugăm verificarea de sănătate în timpul rulării.
‫În acest caz, folosim imaginea Elasticsearch. Puteți vedea comanda cURL localhost 9200, care
‫este portul pe care Elasticsearch rulează în interiorul containerului, nu portul publicat, ci în
‫interiorul containerului. Pentru Elasticsearch, există
‫o adresă URL de sănătate reală.
‫Deci, putem folosi asta aici.
‫Veți observa cele două țevi cu falsul la sfârșitul comenzii respective.
‫Și asta va fi destul
‫de comun dacă folosiți ceva de genul cURL sau alt instrument care va trimite un cod de eroare altul decât 1.
‫Amintiți-vă când am menționat acest lucru în timp ce v-ați ocup Avem nevoie să ieșim cu 1 dacă există o problemă. Pentru că acesta este
‫singurul cod de eroare pe care Docker o va face.
‫Trebuie să ne asigurăm că în acest caz o cochilie va întoarce întotdeauna codul de ieșire false 1 dacă
‫ceva nu iese din acea comandă altul decât 0.
‫Este o modalitate frumoasă de a rezolva problema.
‫Se întâmplă așa cu cURL, cURL va da alte coduri de eroare potențiale și nu vrem să
‫o facă.
‫În fișierele actuale Docker, putem adăuga aceeași comandă. Formatul este puțin diferit. Dar vedeți
‫că avem aceste opțiuni aici. Avem intervalul, timpul de expirare, perioada de început (care este nouă) și încercările.
‫Intervalul este ceea ce credeai că este. Este, în mod implicit, la fiecare 30 de secunde.
‫Cât de des va conduce acest control de sănătate. Timpul de expirare este cât timp va aștepta înainte de
‫erori și va întoarce un cod rău, dacă poate aplicația este lentă. Perioada de start este o caracteristică nouă care
‫ne permite acum la 17 ani. 09 și mai nou, pentru a oferi o perioadă de așteptare mai mare decât primele 30 de secunde ale duratei. Înainte, întotdeauna aștepta mult
‫... intervalul de timp înainte de a începe verificarea de sănătate.
‫Dar poate aveți o aplicație Java sau o bază de date sau ceva care durează mult mai mult pentru a începe.
‫Poate e nevoie de cinci minute.
‫Ai putea adăuga acea perioadă de început acolo. Va mai face verificări de sănătate. Dar ceea ce va face
‫este că nu va alarma pe un control nesănătos până când nu va mai trece timpul.
‫Deci, dacă ați stabilit două minute acolo, chiar dacă este o verificare a sănătății la fiecare 30 de secunde, va fi considerată nesănătoasă
‫doar după ce a trecut de acel punct de două minute. Ultimul dintre acestea, reîncercă, înseamnă că
‫vom încerca acest control de sănătate de câteva ori, înainte de a-l considera nesănătoasă.
‫Aceasta oferă o aplicație potențial instabilă o șansă de a reveni cu o persoană sănătoasă și de a-și reveni
‫singur înainte de a considera acest lucru un container cu adevărat nesănătos.
‫Comanda de bază pentru sănătate pe care ați folosi-o într-un fișier
‫Docker se numește HEALTHCHECK, toate literele mari de acolo. Același format există și în cazul în care dacă facem un simplu cURL al localhost, poate că este
‫vorba de o aplicație PHP sau ceva de genul acesta. Putem face asta.
‫Acesta este modul în care adăugați toate aceste opțiuni într-un fișier Docker, astfel încât
‫să vedeți cum adaug perioada de expirare și încercările înainte de comanda însăși.
‫Primul pentru comandă de bază, nu trebuie să pun un CMD dacă
‫îi dau comanda să ruleze. Dar dacă vreau să afișez opțiuni, dacă vreau să-i
‫ofer opțiuni personalizate din cutie cu timpul de expirare și așa mai departe, atunci trebuie să precizez care este comanda.
‫Acum acestea nu sunt două linii diferite.
‫Observă slash-ul din spate de la capătul primei linii acolo.
‫Așa că nu-ți face confuz.
‫Aici avem un exemplu simplu despre cum ar fi dacă ai avea o aplicație statică care rulează în
‫interiorul unui server Nginx.
‫S-ar putea să setați intervalul și timpul de ieșire din fișierul Docker și ar trebui doar
‫să faceți o comandă cURL pe localhost.
‫Dacă se întoarce un număr de 200 sau 300, consideră că este bine. Dacă returnează un 4, 5 sau altceva, consideră că
‫o eroare.
‫Observi aici că am o ieșire 1, care este același lucru ca un fals.
‫Am făcut asta doar pentru a vă arăta că anumite exemple de pe Internet vor avea un fals. Anumite exemple vor avea o
‫ieșire 1.
‫Amândoi fac același lucru.
‫Iată un exemplu mai mic.
‫În acest caz, folosim o aplicație PHP combinată cu Nginx.
‫Ceea ce am făcut este că, în resurse, veți găsi un link la acest exemplu PHP. Am adăugat într-un fișier personalizat de
‫configurare Nginx care folosește URL-urile de stare Nginx și PHP-FPM.
‫Ambele aplicații au o pagină de stare proprie și un fel de adresă de ping pentru healthcheck.
‫Puteți utiliza cele din aplicațiile dvs. dacă folosiți PHP sau Nginx. Există două adrese URL diferite, dar le puteți
‫utiliza pe ambele în cadrul aceluiași examen de sănătate.
‫În acest caz, folosim doar una dintre ele și aruncăm localhost / ping, care
‫este de fapt
‫o comandă de stare PHP-FPM, dar trebuie să o activați în interiorul PHP-FPM. Din nou, în resursele acestei prelegeri, există o legătură către
‫o valoare prestabilită pentru Docker Good PHP.
‫Puteți verifica acest lucru într-un GitHub unde am arătat în acest exemplu, într-un pic mai detaliat.
‫Apoi avem un exemplu Postgres, astfel încât în ​​Dockerfile pot folosi o altă adresă URL.
‫Aici avem o aplicație Postgres unde în comanda healthcheck folosesc o comandă de pg isready.
‫Acum, cu diferite aplicații, există instrumente diferite. Cu Postgres, vine cu un instrument încorporat,
‫o testare foarte simplă a unei conexiuni la un server Postgres.
‫Nu validează faptul că aveți date bune sau că baza dvs. de date este montată corect. Pur și simplu va spune: "Acest server de baze
‫de date permite conexiuni? Da sau nu? - Asta e un
‫lucru bun pe care îl poți face din cutie.
‫Iată cum ar arăta într-un fișier compozitor / stiva.
‫Foarte asemanator.
‫Veți observa că perioada de început acolo necesită o versiune diferită.
‫De când a ieșit comanda healthcheck în 1. 12, a fost de fapt susținută în 2. 1 din acest fișier
‫Compune.
‫Dar, dacă intenționați să utilizați perioada de început, înseamnă că trebuie să actualizați fișierul
‫Compose la versiunea 3. 4 pentru a susține acest lucru. Deoarece perioada de început a apărut peste
‫un an mai târziu după ce a făcut comanda de sănătate.
‫Să începem cu niște comenzi simple de rulare.
‫Ce vom face aici este că vom începe un server de baze de date Postgres fără a verifica starea de sănătate
‫deoarece, în mod implicit, nu vine cu unul.
‫Apoi o vom rula din nou cu o comandă manuală
‫healthcheck care va adăuga la linia de comandă și vom vedea diferența.
‫Aici, vom numi primul p1. O vom rula detasată de imaginea oficială
‫Postgres.
‫Dacă fac un container de docare, veți vedea că nu există nimic care să indice o verificare a sănătății aici.
‫Dacă facem din nou aceeași comandă și o numim p2 de data aceasta, vom adăuga o comandă de sănătate.
‫De data aceasta vom folosi pg isready, despre care am vorbit mai devreme, pentru a testa
‫că conexiunile sunt disponibile pe acest server Postgres. Vom spune că utilizatorul de care avem
‫nevoie este utilizatorul postgres. Nu avem nevoie de o parolă. Nu va
‫încerca să vă conectați. Va încerca doar să valideze. Vom folosi imaginea Postgres.
‫Acum, dacă facem un container de docare și mă deplasez puțin, veți vedea că se spune: "În sus de 4 secunde începe
‫sănătatea. "Acum obținem
‫această caracteristică suplimentară în statutul nostru de comandă ls. Acesta va rămâne în starea de pornire pentru
‫implicit 30 de
‫secunde până când va executa pentru prima dată comanda healthcheck.
‫Acum că am așteptat peste 30 de secunde, veți vedea că sa schimbat la starea de sănătate.
‫Dacă facem un container de docker să inspecteze pe p2, vom vedea chiar în partea de sus că am avut această nouă
‫opțiune de stare de sănătate. În acest caz, am reușit doar să o execut de două ori.
‫Puteți vedea ieșirea de acolo, că arată că acceptă conexiuni.
‫In regula. Să facem niște comenzi pentru a crea comenzi în aceiași bază de date, în același test de sănătate.
‫Ceea ce vom vedea aici când facem acest lucru este că există trei stări diferite pe care un serviciu
‫trece prin începerea.
‫Se pregătește, ceea ce înseamnă de obicei că descarcă imaginea. Începe, ceea ce înseamnă că execută containerul
‫și îl ridică. Atunci se execută.
‫Fara comanda healthcheck, pornirea si alergarea sunt foarte rapide. Sunt aproape instantanee.
‫Vom vedea că aici, cu un serviciu de docare, creează un nume p1 postgres.
‫Odată ce ați terminat pregătirea prin descărcarea imaginii, veți vedea că aceasta începe imediat să fie difuzată,
‫deoarece nu există nici o verificare a sănătății. Nu are altceva de făcut decât să pornească containerul și să
‫spună: "Da. Binarul rulează. "Dar daca
‫facem aceeasi comanda, serviciul de docare creaza si o numeste p2 ca inainte si da aceleiasi comenzi de
‫sanatate.
‫Începem acest serviciu cu ajutorul comenzii healthcheck încorporată.
‫Ceea ce vom vedea este că va merge de la pregătirea la pornire și va sta la starea de pornire
‫pentru implicit 30 de secunde până când va începe prima verificare a sănătății.
‫Acesta este acum serviciul Docker care așteaptă o stare sănătoasă înainte de a considera că acest
‫serviciu funcționează pe deplin. După 30 de secunde, se va trece la starea de funcționare. Apoi, am obținut ultimul mic verificat acolo,
‫doar pentru a ne asigura că este considerat stabil și apoi am terminat.
‫Puteți vedea deja, din cutie, că, cu servicii, precum și actualizări de servicii,
‫vom obține acest bonus suplimentar de concept de sănătate dacă vom folosi aceste comenzi ori de câte ori putem.