Comment maintenir les conteneurs Docker en cours d'exécution lorsque le démon s'arrête - CloudSavvy IT
Agence web » Actualités du digital » Comment maintenir les conteneurs Docker en cours d’exécution lorsque le démon s’arrête –

Comment maintenir les conteneurs Docker en cours d’exécution lorsque le démon s’arrête –

Lorsque Docker se termine, tous vos conteneurs sont arrêtés. L’installation par défaut ne permet pas aux conteneurs de s’exécuter à moins que le démon ne soit également actif. Voici comment minimiser les temps d’arrêt de la charge de travail en maintenant les conteneurs actifs pendant une panne de démon.

Pourquoi est-ce important ?

Docker s’est avéré être un système fiable capable de prendre en charge des solutions en production. Cela ne veut pas dire que c’est infaillible. Vous pouvez toujours rencontrer un plantage qui met le démon hors de service, mettant vos conteneurs hors ligne.

Dans un autre scénario, le gestionnaire de packages de votre système d’exploitation peut mettre à jour automatiquement Docker, provoquant un redémarrage du démon et une brève période d’arrêt. Idéalement, ces situations pourraient être résolues sans aucun impact sur vos charges de travail. Comme le démon seulement gère conteneurs, implémentant des commandes telles que docker run et docker rm, il n’est pas nécessaire qu’il persiste pendant la période intermédiaire du cycle de vie d’un conteneur.

Restauration en direct du conteneur

Docker prend en charge un système appelé « restauration en direct » qui rend cela possible. Au lieu de mettre fin aux conteneurs lors de l’arrêt du démon, Docker les maintiendra en cours d’exécution. Il reprendra là où il s’était arrêté une fois redémarré.

La restauration en direct doit être activée manuellement. Vous pouvez l’utiliser ponctuellement en exécutant dockerd avec le --live-restore flag:

sudo dockerd --live-restore

Pour activer de manière permanente la restauration en direct, ajoutez-la à votre fichier de configuration du démon Docker. Celui-ci se trouve généralement à /etc/docker/daemon.json. Vous devrez créer le fichier s’il n’existe pas déjà.

Ensuite, vous devez demander à Docker de recharger sa configuration. Un rechargement n’aura pas d’impact sur vos conteneurs, contrairement à un redémarrage complet du démon.

sudo systemctl reload docker

La restauration en direct devrait maintenant être activée. Vous pouvez le tester en arrêtant le démon Docker.

sudo systemctl stop docker

Tous les conteneurs en cours d’exécution doivent rester actifs, même si le démon est arrêté. Vous ne pourrez pas utiliser docker commandes, car la connexion au démon disparaîtra, mais les conteneurs continueront à fonctionner et conserveront leurs connexions réseau.

Docker détectera automatiquement les conteneurs existants au redémarrage. Vous pourrez continuer là où vous vous étiez arrêté, sans avoir à subir de temps d’arrêt.

Gestion de l’exécution soutenue sans démon

L’exécution de conteneurs sans connexion démon active ne devrait pas avoir de conséquences graves, même sur une période de temps prolongée. Cependant, vous constaterez que les journaux commencent à se perdre lors d’une panne prolongée du démon.

Les conteneurs Docker acheminent leurs journaux dans un tampon FIFO (premier entré, premier sorti). Le démon Docker lit le contenu du tampon pour créer les fichiers journaux persistants que vous affichez avec docker logs.

La taille de la mémoire tampon par défaut n’est que de 64 Ko, elle peut donc être épuisée si le démon ne lit pas activement son contenu. Lorsque le tampon se remplit, plus aucun journal ne peut être traité jusqu’à ce que le démon termine un vidage du tampon. Vous pouvez augmenter la taille du tampon en modifiant la valeur de /proc/sys/fs/pipe-max-size.

Mises en garde sur la restauration en direct

Live Restore devrait couvrir la plupart des scénarios dans lesquels le démon Docker s’arrête et récupère plus tard. Cela inclut les mises à jour Docker, mais uniquement entre les versions de correctifs mineures. Si vous installez une nouvelle version majeure de Docker (telle que 19.03 à 20.10), Live Restore ne sera pas utilisé et le démon Docker sera toujours redémarré.

Vous devez vous méfier de l’utilisation de Live Restore comme moyen de modifier les paramètres du démon Docker à la volée. La modification de certaines options, telles que les adresses IP de pont, empêchera les conteneurs de se restaurer correctement lorsque le démon redémarre. Si cela se produit, vous devrez arrêter manuellement tous les conteneurs concernés et les remplacer par de nouveaux. Cette situation peut également se produire si votre système d’exploitation attribue une configuration réseau différente après un redémarrage.

Live Restore est destiné à être utilisé lors des mises à jour de Docker et des pannes de démon imprévues. Si vous devez modifier les paramètres du démon, essayez plutôt de planifier les temps d’arrêt. Vous pouvez aussi utiliser systemctl reload docker pour recharger les fichiers de configuration sans redémarrer complètement le démon.

Il n’y a pas encore Live Restore pour les conteneurs Windows. Toi pouvez utiliser la restauration en direct au Windows avec des conteneurs basés sur Linux. Il est intégré à Docker Desktop et est activé via Préférences > Démon > Avancé.

Conclusion

Live Restore vous permet de minimiser les temps d’arrêt perturbateurs en maintenant les conteneurs en cours d’exécution en l’absence du démon Docker. Si vous devez installer une mise à jour urgente de Docker ou si vous rencontrez un crash surprise, vos charges de travail doivent rester opérationnelles pendant le redémarrage du démon.

L’activation de Live Restore est une étape de bonne pratique lors de l’exécution de Docker en production. Les outils d’analyse de configuration peuvent signaler les installations qui ne l’ont pas activé.

Au-delà de l’utilisation de Live Restore, vous devez également vous assurer que vos conteneurs disposent de politiques de redémarrage appropriées. Utilisant restart: always fera revenir les conteneurs individuels après un redémarrage du système d’exploitation ou tout autre lancement de démon où Live Restore ne pourrait pas être utilisé.

★★★★★