‫La commande de vérification de l'état de santé de Docker. C'était une nouvelle fonctionnalité ajoutée dans 1. 12, sorti mi-2016, au moment où
‫Swarm Kit et Swarm Mode étaient disponibles dans Docker. Il a été ajouté en tant que partie intégrante de cette boîte à
‫outils, mais il fonctionne toujours dans tous les fichiers différents, tels que le fichier Dockerfile, le fichier Compose, la commande d'exécution du menu fixe, les fichiers de pile
‫le prennent en charge, la mise à jour du service et la commande de création de service le prenant en charge.
‫.
‫Il y en a partout.
‫Je vous recommande vivement de commencer, lors de la production, les options de test de cette commande de vérification de l'état
‫de santé.
‫Ça va marcher tout de suite avec un exec.
‫Il va exécuter cette commande dans le conteneur comme si vous utilisiez votre propre commande
‫exec.
‫Donc, il ne fonctionne pas de l'extérieur du conteneur; c'est juste le lancer à l'intérieur, ce
‫qui signifie que même les travailleurs simples qui n'ont pas de ports exposés peuvent exécuter une simple commande pour valider s'ils
‫renvoient de bonnes données ou quoi que ce soit.
‫C'est une simple exécution d'une commande, ce qui signifie qu'elle obtient un retour simple. Il attend un 0 ou un 1.
‫Sous Linux et Windows, vous avez les codes de sortie des commandes et un 0 est une bonne chose.
‫Cela signifie que tout allait bien.
‫Tout ce qui est autre qu'un 0 va être une erreur dans la plupart des applications.
‫Mais dans Docker, nous avons besoin de cette application pour sortir un 1 spécifiquement. Nous allons montrer dans une minute comment vous
‫faites cela.
‫Un bilan de santé dans Docker ne contient que trois états. Cela commence par commencer. Le démarrage commence par les 30
‫premières secondes, par défaut, pour lequel il n'a pas encore exécuté de commande healthcheck.
‫Ensuite, il va en courir un.
‫Si cela renvoie un 0, cela commencera avec le sain. Cela changera pour l'option saine.
‫Cette commande sera exécutée et exécutée à nouveau toutes les 30 secondes par défaut. S'il reçoit un retour malsain, comme une
‫sortie 1, il le marque comme un conteneur malsain.
‫Nous avons des options pour contrôler tout cela, y compris les tentatives.
‫Nous verrons cela dans une minute.
‫C'est une bien meilleure option que par le passé, car Docker veillait jusqu'à présent à ce que
‫l'application soit toujours en cours d'exécution.
‫Elle ne savait pas si cette application faisait ce qu'elle était censée faire.
‫Maintenant, nous pouvons le faire dans le conteneur Docker lui-même.
‫Mais cela ne remplace pas votre solution de surveillance tierce.
‫Cela ne vous donnera pas de graphiques, ni de statut dans le temps, ni d’outils tiers que vous pourriez
‫attendre d’une solution de surveillance.
‫Docker doit savoir si le conteneur lui-même a un niveau de base de santé.
‫Ainsi, dans un Nginx, il peut renvoyer un hôte local du fichier d’index racine. Un retour de 200 ou 300 convient, ce qui donne un code de
‫sortie égal à 0 et le considère comme sain.
‫Ce n'est pas un outil de surveillance extrêmement avancé, vous savez.
‫Mais s'il renvoyait une erreur 404 ou 500, il la considérerait alors comme malsaine et nous pouvons faire quelque chose
‫à ce sujet.
‫Où allons-nous voir ce bilan de santé Docker dans l'interface graphique?
‫La première place est dans le conteneur ls.
‫Il ne vous reste plus qu'à le voir comme cette nouvelle option.
‫C'est au milieu. Nous verrons dans une seconde où nous verrons l'un des trois états si le bilan de
‫santé est en cours, et c'est ainsi que nous savons en réalité qu'il existe un bilan de santé.
‫C'est le moyen le plus simple, au moins, de savoir. Nous verrons l'historique, les cinq derniers de
‫ce bilan de santé, apparaître dans l'inspection pour ce conteneur. Et nous pouvons voir une tendance de base au fil du temps là-bas.
‫Mais la commande d'exécution de docker n'agit pas sur un conteneur défectueux.
‫Une fois que le contrôle de santé a considéré qu'un conteneur était malsain, l'exécution du menu fixe indiquera simplement que, dans la
‫commande ls et l'inspection, elle ne passera pas à l'action.
‫C'est là où nous nous attendons à ce que les services Swarm agissent.
‫Les piles et les services remplaceront donc ce conteneur par une nouvelle tâche, éventuellement sur un nouvel hôte, en
‫fonction du planificateur.
‫Même dans la commande update, nous voyons un petit bonus supplémentaire à utiliser les contrôles de santé, car les mises
‫à jour considéreront le contrôle de santé comme une partie de la préparation de ce conteneur avant qu'il ne disparaisse et ne
‫modifie le suivant.
‫Si un conteneur apparaît, mais qu'il ne passe pas sa vérification d'intégrité, la mise à jour du
‫service ne passera pas au suivant. Ou bien il faudra agir en fonction des changements que vous lui apportez.
‫Regardons quelques exemples avant de passer à la ligne de commande.
‫Ceci est celui que nous utilisons sur l'exécution de docker.
‫Cela nous permet d'utiliser une image existante qui ne contient pas de contrôle d'intégrité et nous ajoutons le
‫contrôle d'intégrité au moment de l'exécution.
‫Dans ce cas, nous utilisons l'image Elasticsearch. Vous pouvez voir que la commande est un cURL localhost
‫9200, qui est le port sur lequel Elasticsearch est exécuté à l'intérieur du conteneur, pas le port publié, mais
‫à l'intérieur du conteneur. Pour Elasticsearch, il
‫existe une URL de santé réelle.
‫Donc, nous pouvons utiliser cela ici.
‫Vous remarquerez les deux canaux avec le faux à la fin de cette commande.
‫Et cela va être assez
‫courant si vous utilisez quelque chose comme cURL ou un autre outil qui enverra un code d'erreur autre que 1.
‫Tu te souviens quand j'ai mentionné ça tout à l'heure? Nous en avons besoin pour sortir avec 1 s'il y a un problème. Parce que c'est
‫le seul code d'erreur que Docker va faire.
‫Nous devons nous assurer que dans ce cas, un shell renverra toujours le faux code de sortie 1 s'il y
‫a quelque chose sortant de cette commande autre que 0.
‫C'est un bon moyen de résoudre ce problème.
‫CURL donnera d’autres codes d’erreur potentiels et nous ne voulons pas que cela se
‫produise.
‫Dans les fichiers Docker actuels, nous pouvons ajouter la même commande. Le format est un peu différent. Mais vous voyez
‫que nous avons ces options ici. Nous avons l'intervalle, le délai d'attente, la période de début (qui est nouvelle) et les tentatives.
‫L'intervalle est ce que vous penseriez. C'est, par défaut, toutes les 30 secondes.
‫Combien de fois il va exécuter ce bilan de santé. Le délai d'attente est le temps qu'il faudra attendre avant
‫qu'il ne sorte et renvoie un code erroné, si éventuellement l'application est lente. La période de départ est une nouvelle fonctionnalité qui nous
‫permet maintenant de passer à 17 ans. 09 et plus récent, pour donner une période d'attente plus longue que les 30 premières secondes de la durée. Avant, il fallait toujours attendre
‫longtemps ... l'intervalle de temps avant le début de la vérification de santé.
‫Mais vous avez peut-être une application Java, une base de données ou quelque chose qui prend beaucoup plus de temps à démarrer.
‫Cela prend peut-être cinq minutes.
‫Vous pouvez ajouter cette période de début ici. Ça va encore faire des bilans de santé. Mais ce qu'il va faire,
‫c'est qu'il ne déclenchera pas un contrôle malsain avant que ce temps ne soit écoulé.
‫Donc, si vous définissez deux minutes, même si la vérification de l'état de santé est effectuée toutes les 30 secondes, elle ne sera considérée
‫comme mauvaise pour la santé qu'une fois ces deux minutes écoulées. Le dernier essai, cela signifie que nous
‫allons essayer ce bilan de santé x nombre de fois avant de le considérer comme malsain.
‫Cela donne peut-être à une application potentiellement instable une chance de revenir en bonne santé et de récupérer
‫d'elle-même avant que nous ne considérions cela comme un conteneur vraiment malsain.
‫La commande de contrôle de santé de base que vous utiliseriez dans un
‫fichier Docker s'appelle HEALTHCHECK, toutes les lettres majuscules se trouvant là. Le même format existe où si nous faisons juste un simple curl du localhost parce que
‫c'est peut-être une application PHP ou quelque chose. Nous pouvons faire ça.
‫Voici comment ajouter toutes ces options à un fichier Docker afin de voir comment
‫j'ajoute l'intervalle de délai d'attente et les tentatives avant la commande elle-même.
‫Le premier est la commande de base, notez que je n’ai pas besoin de mettre un CMD si
‫je lui donne simplement la commande à exécuter. Mais si je veux afficher les options, si je
‫veux lui donner des options personnalisées prêtes à l'emploi avec le délai d'expiration, etc., je dois spécifier laquelle est la commande.
‫Maintenant, ce ne sont pas deux lignes différentes.
‫Remarquez la barre oblique à la fin de la première ligne.
‫Donc, ne vous trompez pas.
‫Nous avons ici un exemple simple de ce à quoi cela pourrait ressembler si une application statique était exécutée
‫sur un serveur Nginx.
‫Vous pouvez définir l'intervalle et le délai d'expiration à partir de votre fichier Docker, et le faire
‫simplement exécuter une commande cURL sur l'hôte local.
‫S'il renvoie 200 ou 300, il considère que c'est bien. S'il renvoie 4, 5 ou autre chose, il considère que c'est
‫une erreur.
‫Vous remarquez ici que j'ai une sortie 1, ce qui revient à un faux.
‫Je l'ai fait juste pour vous montrer que certains exemples sur Internet auront un faux. Certains exemples auront une
‫sortie 1.
‫Ils font tous deux la même chose.
‫Voici un exemple un peu plus avancé.
‫Dans ce cas, nous utilisons une application PHP associée à Nginx.
‫Ce que j'ai fait est que, dans les ressources, vous trouverez un lien vers cet exemple PHP. J'ai ajouté un fichier de configuration
‫Nginx personnalisé qui utilise les URL d'état des statuts Nginx et PHP-FPM.
‫Ces deux applications ont leur propre page d’état et une sorte d’URL de contrôle de santé.
‫Vous pouvez les utiliser dans vos applications si vous utilisez PHP ou Nginx. Il existe deux URL différentes, mais vous pouvez
‫les utiliser toutes les deux dans le même état de santé.
‫Dans ce cas, nous en utilisons un seul, et nous ajoutons le paramètre localhost /
‫ping, qui est
‫en fait une commande de statut PHP-FPM, mais vous devez l'activer dans votre PHP-FPM. Encore une fois, dans les ressources de cette conférence, il y
‫a un lien vers un PHP Docker Good Defaults.
‫Vous pouvez aller vérifier cela sur un GitHub où j'ai montré un peu plus en détail cet exemple.
‫Ensuite, nous avons un exemple Postgres afin que, dans le fichier Docker, je puisse utiliser une URL différente.
‫Nous avons ici une application Postgres où, dans la commande healthcheck, j'utilise une commande de pg isready.
‫Maintenant, avec différentes applications, il existe différents outils. Avec Postgres, il est livré avec un outil
‫intégré, c’est un test très simple de la connexion à un serveur Postgres.
‫Cela ne confirme pas que vous avez de bonnes données, ou que votre base de données est montée correctement. Il va simplement dire: «Ce serveur de base de
‫données autorise-t-il les connexions? Oui ou non? 'C'est une idée géniale
‫que vous pouvez faire en dehors de la boîte.
‫Voici à quoi cela ressemblerait dans un fichier composeur / pile.
‫Très similaire.
‫Vous remarquerez que la période de démarrage nécessite une version différente.
‫Depuis que la commande healthcheck est sortie en 1. 12, il a été pris en charge dans 2. 1 de ce fichier de
‫composition.
‫Toutefois, si vous utilisez la période de début, cela signifie que vous devez mettre à jour votre fichier
‫Compose vers la version 3. 4 afin de soutenir cela. Parce que la période de démarrage
‫est arrivée un an plus tard après la commande Healthcheck.
‫Commençons par quelques commandes d'exécution simples.
‫Ce que nous allons faire ici, c'est que nous allons démarrer un serveur de base de données Postgres sans vérification de l'état de santé,
‫car par défaut, il ne vient pas avec un.
‫Ensuite, nous allons l'exécuter à nouveau avec une commande de vérification manuelle de
‫la santé qui sera ajoutée à la ligne de commande et nous verrons la différence.
‫Ici, nous allons appeler le premier p1. Nous allons l'exécuter indépendamment de l'image officielle de
‫Postgres.
‫Si je fais un conteneur docker ls, vous verrez qu'il n'y a rien qui indique une vérification de l'état de santé ici.
‫Si nous répétons la même commande et l'appelons p2 cette fois-ci, nous ajouterons une commande de santé.
‫Cette fois, nous allons utiliser la pg isready, dont nous avons parlé plus tôt, pour vérifier
‫que les connexions sont disponibles sur ce serveur Postgres. Nous allons lui dire que l'utilisateur dont nous
‫avons besoin est l'utilisateur postgres. Nous n'avons pas réellement besoin de lui donner un mot de passe. Il ne va
‫pas essayer de se connecter. Il va juste essayer de valider. Nous allons utiliser l'image Postgres.
‫Maintenant, si nous faisons un conteneur docker ls, et que je fais un zoom arrière, vous verrez qu'il est écrit: «La santé commence dans
‫4 secondes. 'Nous avons
‫maintenant cette fonctionnalité supplémentaire dans l'état de notre commande ls. Il restera dans l'état de démarrage pendant 30 secondes
‫par défaut jusqu'à
‫ce qu'il exécute la commande healthcheck pour la première fois.
‫Maintenant que nous avons attendu plus de 30 secondes, vous constaterez que l'état de la santé a été modifié.
‫Si nous effectuons une inspection de conteneur docker sur cette p2, nous verrons tout en haut que nous avions cette nouvelle
‫option d'état de santé. Dans ce cas, je n'ai pu l'exécuter que deux fois.
‫Vous pouvez voir la sortie à cet endroit, qui montre qu'elle accepte les connexions.
‫D'accord. Faisons quelques commandes de création de service pour cette même base de données, dans le même test de contrôle de la santé.
‫Ce que nous verrons ici quand nous ferons cela, c'est qu'il y a trois états différents par lesquels un service
‫passe au démarrage.
‫C'est se préparer, ce qui signifie généralement qu'il télécharge l'image. Cela commence, ce qui signifie qu'il exécute le
‫conteneur et le remonte. Puis c'est en cours d'exécution.
‫Sans la commande healthcheck, le démarrage et l'exécution sont très rapides. Ils sont presque instantanés.
‫Nous verrons cela ici avec un service de menu fixe créer le nom p1 postgres.
‫Une fois que vous avez terminé en téléchargeant l'image, vous verrez qu'elle passe immédiatement du début à la fin,
‫car il n'y a pas de bilan de santé. Il n'a rien d'autre à faire que de démarrer le conteneur et
‫de dire: 'Oui. Le binaire est en cours d'exécution. 'Mais si nous
‫faisons la même commande, le service Docker crée et appelle-le p2 comme avant et lui donne la même commande
‫d'intégrité.
‫Nous commençons ce service avec la commande healthcheck intégrée.
‫Nous verrons que cela passera de la préparation au démarrage et qu'il restera à l'état de démarrage
‫pendant 30 secondes par défaut jusqu'à la première vérification de santé.
‫C'est maintenant le service Docker qui attend un état en bonne santé avant de considérer ce
‫service comme étant complètement opérationnel. Une fois les 30 secondes écoulées, l'état de fonctionnement est activé. Ensuite, nous obtenons la dernière vérification, juste
‫pour nous assurer que le produit est considéré comme stable, puis nous avons terminé.
‫Vous pouvez déjà voir, dès la livraison, qu'avec les services, ainsi que les mises à jour
‫de services, nous allons obtenir ce bonus supplémentaire de concept de santé si nous utilisons ces commandes chaque fois que nous le pouvons.