‫De opdracht Docker Health Check. Het was een nieuwe functie toegevoegd in 1. 12, die medio 2016 uitkwam, op hetzelfde
‫moment dat Swarm Kit en Swarm Mode beschikbaar waren in Docker. Het is echt toegevoegd als onderdeel van die
‫toolkit, maar het werkt nog steeds in alle verschillende bestanden zoals het Dockerfile, het Compose-bestand, het docker-run-commando gebruikt
‫het, de Stack-bestanden ondersteunen het, de service-update en de service create-opdracht ondersteunen het
‫.
‫Het is overal.
‫Ik raad u ten zeerste aan om, wanneer u gaat produceren, de testopties voor deze statuscontroleopdracht uit
‫te voeren.
‫Het gaat direct uit de doos werken met een exec.
‫Het gaat die opdracht in de container uitvoeren, net alsof je je eigen exec-opdracht
‫uitvoert.
‫Het voert het dus niet van buiten de container uit; het draait het gewoon naar binnen,
‫wat betekent dat zelfs eenvoudige werkers die geen blootgestelde poorten hebben, je een eenvoudig commando erin kunt uitvoeren om te valideren
‫of ze goede gegevens retourneren of wat dan ook.
‫Het is een simpele uitvoering van een commando, wat betekent dat het een simpele return krijgt. Hij verwacht een 0 of een 1.
‫In Linux en Windows heb je exit-codes van opdrachten en een 0 is een goede zaak.
‫Het betekent dat alles goed was.
‫Iets anders dan een 0 zal in de meeste toepassingen een fout zijn.
‫Maar in Docker hebben we die applicatie nodig om specifiek een 1 af te sluiten. We laten je zo zien hoe je
‫dat doet.
‫Er zijn slechts drie staten voor een gezondheidscheck in Docker. Het begint met starten. Het starten is standaard de
‫eerste 30 seconden waarin het nog geen healthcheck-opdracht heeft uitgevoerd.
‫Dan gaat het er een draaien.
‫Als dat een 0 oplevert, begint het met de gezonde. Het verandert in de gezonde optie.
‫Het zal dat commando nemen en het zal het standaard elke 30 seconden opnieuw uitvoeren. Als het ooit een ongezond rendement ontvangt,
‫zoals een exit 1, markeert het het als een ongezonde container.
‫We hebben opties om dit allemaal te regelen, inclusief nieuwe pogingen.
‫Dat zullen we zo zien.
‫Dit is een veel betere optie dan we in het verleden hebben gehad, omdat Docker er tot nu toe alleen maar voor zorgde
‫dat de applicatie nog steeds actief was.
‫Het had geen inzicht of die applicatie deed wat hij moest doen.
‫Nu kunnen we dat doen in de Docker-container zelf.
‫Maar dit is geen vervanging voor uw monitoringoplossing van derden.
‫Dit geeft u geen grafieken, of status in de loop van de tijd, of enige vorm van tooling van derden die u
‫van een monitoringoplossing zou verwachten.
‫Dit gaat over Docker-begrip als de container zelf een basisniveau van gezond heeft.
‫Dus in een Nginx kan het een localhost van het rootindexbestand retourneren. Een rendement van 200 of 300 is prima en geeft het een exit-code
‫van 0, en het beschouwt het als gezond.
‫Dat is geen super geavanceerde, uh, je weet wel, monitoring tool.
‫Maar als het een 404- of 500-fout zou retourneren, zou het het als ongezond beschouwen en daar kunnen we
‫iets aan doen.
‫Waar gaan we deze Docker-healthcheck in de GUI zien?
‫De eerste plaats is in container ls.
‫Het zal het gewoon zien als deze nieuwe optie.
‫Het is in het midden. We zullen zo zien waar het ons een van de drie staten zal
‫laten zien als de gezondheidscontrole wordt uitgevoerd, en zo weten we dat er een gezondheidscheck is.
‫Dat is in ieder geval de gemakkelijkste manier om het te weten. We zullen de geschiedenis zien, de laatste vijf
‫van die gezondheidscheck, verschijnen in de inspectie van die container. En we kunnen daar in de loop van de tijd een basistrend zien.
‫Maar de opdracht docker run onderneemt geen actie op een ongezonde container.
‫Zodra de healthcheck een container als ongezond beschouwt, geeft docker run dat alleen aan in de opdracht ls en
‫in de inspect, maar er wordt geen actie ondernomen.
‫Daar verwachten we dat de Swarm Services actie ondernemen.
‫Dus de stacks en services zullen die container daadwerkelijk vervangen door een nieuwe taak, mogelijk op een nieuwe host,
‫afhankelijk van de planner.
‫Zelfs in het update-commando zien we een kleine extra bonus door de healthchecks te gebruiken, omdat de
‫updates de healthcheck beschouwen als een onderdeel van de gereedheid voor die container voordat deze gaat en de
‫volgende verandert.
‫Als er een container verschijnt, maar deze niet door de statuscontrole komt, gaat de
‫service-update niet naar de volgende. Of het onderneemt actie op basis van de wijzigingen die u het geeft.
‫Laten we een paar voorbeelden bekijken voordat we naar de opdrachtregel gaan.
‫Dit is er een die we gebruiken tijdens docker-run.
‫Hierdoor kunnen we een bestaande afbeelding gebruiken die geen statuscontrole bevat, en we voegen
‫de statuscontrole tijdens runtime toe.
‫In dit geval gebruiken we de Elasticsearch-afbeelding. U kunt zien dat de opdracht een cURL localhost
‫9200 is, de poort waarop Elasticsearch wordt uitgevoerd in de container, niet in de gepubliceerde poort, maar
‫in de container. Voor Elasticsearch
‫is er een daadwerkelijke gezondheids-URL.
‫Dus dat kunnen we hier gebruiken.
‫U ziet de twee pijpen met de false aan het einde van dat commando.
‫En dat zal vrij gebruikelijk
‫zijn als je iets als cURL of een andere tool gebruikt die een foutcode verzendt die anders is dan 1.
‫Weet je nog dat ik dat een tijdje geleden noemde? We hebben het nodig om af te sluiten met 1 als er een probleem is. Want dat is de
‫enige foutcode waar Docker iets aan gaat doen.
‫We moeten ervoor zorgen dat in dit geval een shell altijd de valse 1 exit-code retourneert als er
‫iets anders uit dat commando komt dan 0.
‫Het is een leuke manier om dat probleem te omzeilen.
‫Het is gewoon zo met cURL, cURL geeft andere mogelijke foutcodes en we willen niet dat het
‫dat doet.
‫In de eigenlijke Docker-bestanden kunnen we dezelfde opdracht toevoegen. Het formaat is een beetje anders. Maar je ziet
‫dat we deze opties hier hebben. We hebben het interval, de time-out, de startperiode (die nieuw is) en nieuwe pogingen.
‫Het interval is wat je zou denken dat het is. Het is standaard elke 30 seconden.
‫Hoe vaak het deze gezondheidscontrole gaat uitvoeren. De time-out is hoe lang het duurt voordat er een fout
‫optreedt en een slechte code wordt geretourneerd, als de app misschien traag is. De startperiode is een nieuwe functie
‫waarmee we nu in 17. 09 en nieuwer, om een langere wachttijd te geven dan de eerste 30 seconden van de duur. Vroeger wachtte het altijd
‫zo lang... de intervaltijd voordat de healthcheck begon.
‫Maar misschien heb je een Java-app, of database, of iets dat veel langer duurt om op te starten.
‫Misschien duurt het vijf minuten.
‫Je zou die startperiode daar kunnen toevoegen. Het zal nog steeds gezondheidschecks doen. Maar wat het zal
‫doen, is dat het niet alarmeert bij een ongezonde controle totdat die tijd is verstreken.
‫Dus als je er twee minuten in zet, ook al wordt er elke 30 seconden een gezondheidscheck uitgevoerd, dan zal het het pas
‫als ongezond beschouwen als het voorbij die twee minuten is. De laatste daar, retry's, betekent dat we
‫deze health check x aantal keer gaan proberen voordat we het als ongezond beschouwen.
‫Dat geeft misschien een potentieel onstabiele app een kans om terug te komen met een gezonde en zichzelf
‫te herstellen voordat we dit als een echt ongezonde container beschouwen.
‫Het basiscommando voor de gezondheidscontrole dat u in een
‫Dockerfile zou gebruiken, heet HEALTHCHECK, alle hoofdletters daar. Hetzelfde formaat bestaat als we gewoon een simpele cURL van de localhost doen, omdat
‫het misschien een PHP-app is of zoiets. We kunnen dat doen.
‫Dit is hoe je al die opties aan een Dockerfile zou toevoegen, zodat je zou
‫zien hoe ik het time-outinterval en de nieuwe pogingen vóór de opdracht zelf toevoeg.
‫De eerste daar voor het basiscommando, merk op dat ik geen CMD hoef in te voeren als ik het
‫alleen het commando geef om uit te voeren. Maar als ik opties wil tonen, als ik
‫het standaard aangepaste opties wil geven met de time-out enzovoort, dan moet ik specificeren welke de opdracht is.
‫Dit zijn geen twee verschillende lijnen.
‫Let op de schuine streep naar achteren aan het einde van de eerste regel daar.
‫Verwar dat dus niet.
‫Hier hebben we een eenvoudig voorbeeld van hoe het zou zijn als je een statische applicatie op
‫een Nginx-server had draaien.
‫Je zou het interval en de time-out van je Dockerfile kunnen instellen, en je zou het
‫gewoon een cURL-opdracht op de localhost laten doen.
‫Als het een 200 of 300 retourneert, beschouwt het dat als een boete. Als het een 4 of 5 of iets anders retourneert, beschouwt het dat
‫als een fout.
‫Je merkt hier dat ik een uitgang 1 heb, wat hetzelfde is als een valse.
‫Ik deed dat alleen maar om je te laten zien dat bepaalde voorbeelden op internet een valse zullen hebben. Bepaalde voorbeelden hebben een
‫uitgang 1.
‫Ze doen allebei hetzelfde.
‫Hier is een iets geavanceerder voorbeeld.
‫In dit geval gebruiken we een PHP-app die is gecombineerd met Nginx.
‫Wat ik heb gedaan, is dat je in de bronnen een link naar dit PHP-voorbeeld vindt. Ik heb een aangepast
‫Nginx-configuratiebestand toegevoegd dat Nginx- en PHP-FPM-status-URL's gebruikt.
‫Beide applicaties hebben hun eigen statuspagina en een soort healthcheck ping-URL.
‫Die kun je in je apps gebruiken als je PHP of Nginx gebruikt. Er zijn twee verschillende URL's, maar
‫u kunt ze allebei binnen dezelfde healthcheck gebruiken.
‫In dit geval gebruiken we er slechts één en voegen we de localhost/ping
‫toe, wat eigenlijk
‫een PHP-FPM-statuscommando is, maar je moet dat inschakelen in je PHP-FPM. Nogmaals, in de bronnen van deze lezing is er een
‫link naar een PHP Docker Good Defaults.
‫Je kunt dat gaan bekijken op een GitHub waar ik in dit voorbeeld wat meer in detail heb laten zien.
‫Vervolgens hebben we een Postgres-voorbeeld, dus in de Dockerfile kan ik een andere URL gebruiken.
‫Hier hebben we een Postgres-toepassing waarbij ik in het healthcheck-commando een commando van pg gebruik isready.
‫Nu, met verschillende apps, zijn er verschillende tools. Met Postgres wordt het geleverd met een ingebouwde
‫tool, dat is een heel eenvoudige test van een verbinding met een Postgres-server.
‫Het valideert niet dat u goede gegevens hebt of dat uw database correct is gemount. Het gaat eenvoudigweg zeggen: 'Staat deze
‫databaseserver verbindingen toe? Ja of nee? ' Dat is een
‫nette die je uit de doos kunt doen.
‫Dit is hoe het eruit zou zien in een componist/stack-bestand.
‫Zeer vergelijkbaar.
‫U zult merken dat de startperiode daar een andere versie vereist.
‫Sinds de opdracht healthcheck uitkwam in 1. 12, werd het daadwerkelijk ondersteund in 2. 1 van dit Compose-bestand.
‫Maar als u de startperiode gaat gebruiken, betekent dit dat u uw Compose-bestand moet
‫bijwerken naar versie 3. 4 om dat te ondersteunen. Omdat de startperiode ruim een
‫jaar later uitkwam nadat het commando healthcheck dat deed.
‫Laten we beginnen met enkele eenvoudige run-commando's.
‫Wat we hier gaan doen, is dat we een Postgres-databaseserver starten zonder de healthcheck, omdat
‫deze er standaard niet met is.
‫Dan gaan we het opnieuw uitvoeren met een handmatige healthcheck-opdracht
‫die wordt toegevoegd aan de opdrachtregel, en we zullen het verschil zien.
‫Hier gaan we de eerste gewoon p1 noemen. We laten het los van de officiële
‫Postgres-afbeelding.
‫Als ik een docker-container ls doe, zul je zien dat er hier niets is dat wijst op een healthcheck.
‫Als we hetzelfde commando opnieuw doen, en het deze keer p2 noemen, gaan we een gezondheidscommando toevoegen.
‫Deze keer gaan we de pg isready gebruiken, waar we het eerder over hadden, om te
‫testen of de verbindingen beschikbaar zijn op deze Postgres-server. We gaan het vertellen dat de gebruiker die we
‫nodig hebben de postgres-gebruiker is. We hoeven het eigenlijk geen wachtwoord te geven. Hij gaat niet
‫proberen in te loggen. Het gaat gewoon proberen te valideren. We gebruiken de Postgres-afbeelding.
‫Als we nu een docker-container ls doen, en ik zoom een beetje uit, dan zie je dat er staat: 'Up 4 seconds health
‫begint. ' Nu
‫krijgen we deze extra functie in onze status van ons ls-commando. Het blijft in de startstatus gedurende de
‫standaard 30 seconden
‫totdat het de healthcheck-opdracht voor de eerste keer uitvoert.
‫Nu we meer dan 30 seconden hebben gewacht, zult u zien dat deze is gewijzigd in de status gezond.
‫Als we een havencontainer inspecteren op die p2, zullen we helemaal bovenaan zien dat we deze
‫nieuwe gezondheidsstatusoptie hadden. In dit geval heb ik het maar twee keer kunnen uitvoeren.
‫Je kunt de uitvoer daar zien, dat het laat zien dat het verbindingen accepteert.
‫Oke. Laten we in diezelfde test-gezondheidscontrole wat service-aanmaakopdrachten doen voor diezelfde database.
‫Wat we hier zullen zien als we dit doen, is dat er drie verschillende toestanden zijn die een service doormaakt
‫bij het opstarten.
‫Het is zich aan het voorbereiden, wat meestal betekent dat het de afbeelding aan het downloaden is. Het begint, wat betekent dat het de container uitvoert
‫en naar voren brengt. Dan loopt het.
‫Zonder het healthcheck-commando gaat het starten en draaien erg snel. Ze zijn bijna ogenblikkelijk.
‫We zullen zien dat hier met een docker-service naam p1 postgres wordt gemaakt.
‫Als het klaar is met voorbereiden door de afbeelding te downloaden, zul je zien dat het meteen van
‫starten naar draaien gaat, omdat er geen gezondheidscontrole is. Het heeft niets anders te doen dan de container te starten en
‫te zeggen: 'Ja. Het binaire bestand wordt uitgevoerd. ' Maar
‫als we hetzelfde commando doen, docker-service maken, en het p2 noemen zoals eerder, en hetzelfde gezondheidscommando
‫geven.
‫We starten deze service met het ingebouwde healthcheck-commando.
‫Wat we zullen zien, is dat het van voorbereiding naar starten gaat en dat het gedurende de standaard
‫30 seconden in de startstatus blijft totdat de eerste gezondheidscheck wordt uitgevoerd.
‫Dit is nu de Docker-service die een gezonde status verwacht voordat deze deze
‫service volledig actief acht. Nadat de 30 seconden voorbij zijn, schakelt het over naar de actieve status. Dan krijgen we daar de laatste kleine verificatie, om
‫er zeker van te zijn dat het als stabiel wordt beschouwd, en dan zijn we klaar.
‫Je kunt al direct zien dat we met services, evenals
‫service-updates, deze extra bonus van gezondheidsconcept krijgen als we deze commando's gebruiken wanneer we maar kunnen.