Comment utiliser les stratégies 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. Avec les stratégies de redémarrage, vous pouvez prendre le contrôle des cycles de vie des conteneurs individuels.

Les stratégies de redémarrage seront utilisées chaque fois qu’un conteneur cesse de fonctionner. Docker examine également les politiques de redémarrage lorsque le démon démarre. Vous pouvez utiliser ce mécanisme pour amener les conteneurs avec votre hôte après les redémarrages.

Politiques disponibles

Il existe actuellement quatre stratégies de redémarrage différentes:

• no – Cette politique ne démarrera jamais automatiquement un conteneur. Il s’agit de la stratégie 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 la prochaine fois que le démon redémarrera.
• on-failure – Le conteneur redémarrera s’il s’arrête en raison d’une erreur. Docker n’ouvrira 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 des services d’arrière-plan de longue durée, vous souhaitez généralement qu’ils redémarrent chaque fois que quelque chose ne va pas. le no la politique est la mieux adaptée à l’utilisation du développement local. Il est également utile pour les conteneurs 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 ignoré. Si vous voulez que les conteneurs restent arrêtés de manière fiable après l’exécution docker stop, Tu devrais 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ù seulement 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 l’image est ENTRYPOINT le script sera appelé. Les systèmes Bootstrap doivent toujours être résilients à plusieurs appels.

Application d’une politique de redémarrage

Vous pouvez démarrer un conteneur avec une stratégie de redémarrage spécifique en passant le --restart drapeau à 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. Passez le nom du conteneur à la commande. Vous pouvez trouver les noms de conteneurs en exécutant docker ps -a.

docker update --restart-policy unless-stopped httpd

Vous pouvez utiliser 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’a pas été en cours d’exécution pendant au moins 10 secondes. Cela empêche un conteneur défaillant de redémarrer continuellement.

L’autre comportement du spécialiste concerne le docker stop commander. Docker respectera toujours l’utilisation de docker stop, de sorte que le conteneur ne redémarrera pas immédiatement après avoir exécuté la commande. Si vous souhaitez réellement redémarrer le conteneur, utilisez docker restart plutôt.

Limitation des tentatives de redémarrage

le on-failure La stratégie de redémarrage vous permet de spécifier le nombre de tentatives à tenter. Docker abandonnera et laissera le conteneur dans un état arrêté s’il ne parvient pas à démarrer 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 autre tentative ne sera tentée. Cette option est utile pour les conteneurs où une erreur de démarrage persistante est peu susceptible d’être résolue sans intervention manuelle.

Enquêter sur les raisons pour lesquelles 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 montrera 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 arrêté 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 les causes d’un crash 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 regroupe les flux de sortie standard et d’erreur standard du conteneur. Si l’erreur a été enregistrée, vous devriez vous attendre à la voir dans les dernières lignes de sortie.

Résumé

Les stratégies de redémarrage permettent de garantir que vos conteneurs Docker sont là lorsque vous en avez besoin. Le défaut no la politique ne convient pas à la plupart des charges de travail de production. Vous ne voulez pas que vos conteneurs restent arrêtés s’ils tombent en panne!

L’utilisation de l’une des trois stratégies de redémarrage 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 panne du conteneur.