Comment utiliser les politiques de redémarrage de Docker pour maintenir les conteneurs en cours d'exécution

Docker vous offre plusieurs options pour gérer le cycle de vie de votre conteneur. Les conteneurs ne redémarrent normalement pas automatiquement après leur arrêt. Grâce aux règles de redémarrage, vous pouvez contrôler les cycles de vie des conteneurs individuels.

Les stratégies de redémarrage seront utilisées chaque fois qu'un conteneur s'arrête. Docker examine également les politiques de redémarrage au démarrage du démon. Vous pouvez utiliser ce mécanisme pour mettre en place des conteneurs avec votre hôte après le redémarrage.

Règles disponibles

Il existe actuellement quatre politiques de redémarrage différentes :

• no – Cette stratégie ne démarrera jamais automatiquement un conteneur. Il s'agit de la politique par défaut pour tous les conteneurs créés avec docker run .
• always – Docker s'assurera que le conteneur est toujours en cours d'exécution. Si le conteneur s'arrête, il sera immédiatement redémarré. Vous pouvez toujours arrêter manuellement le conteneur avec docker stop mais Docker le réactivera au prochain redémarrage du démon.
• on-failure – Le conteneur sera redémarré s'il s'arrête à cause d'une erreur. Docker n'affichera pas le conteneur après le redémarrage du démon.
• unless-stopped - Cela fonctionne de la même manière que always . La différence est que Docker ne redémarrera jamais le conteneur s'il a été arrêté manuellement.

Vous utiliserez généralement l'une des trois dernières options pour les charges de travail de production. Comme les conteneurs Docker sont souvent utilisés pour les services d'arrière-plan de longue durée, vous souhaitez généralement qu'ils redémarrent en cas de problème. Le no politique est la mieux adaptée à l'utilisation du développement local. Il est également utile pour les conteneurs d'utilitaires qui exécutent un seul exécutable puis se terminent.

Il peut être difficile de décider quelle stratégie de redémarrage utiliser. always est souvent le choix le plus naturel, mais le comportement de redémarrage du démon peut facilement être négligé. Si vous souhaitez que les conteneurs restent arrêtés de manière fiable après avoir exécuté docker stop , vous devez utiliser unless-stopped .

Docker détecte les erreurs en fonction du code de sortie émis par le processus de premier plan du conteneur. Un code de sortie de 1 ou supérieur est interprété comme une erreur. Cela correspond à la gestion Unix des codes de sortie, où seul 0 représente une exécution réussie.

Lorsque Docker redémarre votre conteneur, cela équivaut à exécuter docker run de nouveau. Cela signifie que le ENTRYPOINT de l'image script sera invoqué. Les systèmes Bootstrap doivent toujours être résilients aux appels multiples.

Appliquer une politique de redémarrage

Vous pouvez démarrer un conteneur avec une politique de redémarrage spécifique en passant le --restart indicateur pour docker run :

docker run --name httpd --restart always httpd:latest

Si vous utilisez Docker Compose, ajoutez le restart champ à votre docker-compose.yml :

services:
  httpd:
    image: httpd:latest
    restart: always

Vous pouvez modifier la politique de redémarrage d'un conteneur existant à l'aide de docker update . Transmettez le nom du conteneur à la commande. Vous pouvez trouver des noms de conteneurs en exécutant docker ps -a .

docker update --restart-policy unless-stopped httpd

Vous pouvez utiliser la docker update avec des conteneurs en cours d'exécution ou arrêtés.

Redémarrer les boucles

Docker inclut quelques protections contre les boucles de redémarrage perpétuelles. Le premier est un délai obligatoire avant l'activation des politiques de redémarrage. Docker ne commencera pas à surveiller les redémarrages tant qu'un conteneur n'aura pas été exécuté pendant au moins 10 secondes. Cela empêche un conteneur défaillant de redémarrer continuellement.

L'autre comportement spécialisé concerne le docker stop commande. Docker respectera toujours l'utilisation de docker stop , afin que le conteneur ne redémarre pas immédiatement après l'exécution de la commande. Si vous souhaitez réellement redémarrer le conteneur, utilisez docker restart à la place.

Limiter les tentatives de redémarrage

Le on-failure la stratégie de redémarrage vous permet de spécifier le nombre de tentatives à effectuer. Docker abandonnera et laissera le conteneur dans un état arrêté s'il ne démarre pas plusieurs fois de suite.

docker run httpd:latest --restart on-failure:5

Dans cet exemple, Docker essaiera de redémarrer le conteneur cinq fois après un échec (code de sortie différent de zéro). Si le conteneur ne démarre pas à la cinquième tentative, aucune nouvelle tentative ne sera tentée. Cette option est utile pour les conteneurs où une erreur de démarrage persistante a peu de chances d'être résolue sans intervention manuelle.

Enquêter pourquoi les conteneurs se sont arrêtés

Si vous avez besoin de savoir pourquoi un conteneur s'est arrêté, exécutez docker ps -a . Cela affichera les détails de tous vos conteneurs, qu'ils soient arrêtés ou en cours d'exécution. Trouvez le conteneur cible et regardez dans sa colonne "Statut". Pour les conteneurs arrêtés, le code de sortie sera indiqué entre parenthèses. Si le code est supérieur à zéro, le conteneur s'est terminé en raison d'une erreur.

Vous devez vous référer à la documentation du processus en cours d'exécution dans le conteneur pour déterminer la signification des codes d'erreur individuels. Cependant, vous pouvez souvent obtenir des informations sur la cause d'un plantage en récupérant les journaux du conteneur. Les journaux restent disponibles après l'arrêt d'un conteneur.

docker logs my-container

Le flux de journal agrège les flux de sortie standard et d'erreur standard du conteneur. Si l'erreur a été consignée, vous devriez vous attendre à la voir dans les dernières lignes de sortie.

Résumé

Les politiques de redémarrage permettent de garantir que vos conteneurs Docker sont là lorsque vous en avez besoin. Le no par défaut La stratégie n'est pas adaptée à la plupart des charges de travail de production. Vous ne voulez pas que vos conteneurs restent arrêtés s'ils plantent !

L'utilisation de l'une des trois stratégies capables de redémarrer rend vos conteneurs plus résistants aux redémarrages matériels et aux arrêts inattendus. Docker maintiendra la disponibilité du service en cas de plantage du conteneur.