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 opérationnel. 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 qu'il est infaillible. Vous pourriez toujours rencontrer un plantage qui met le démon hors 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'indisponibilité. Idéalement, ces situations pourraient être résolues sans aucun impact sur vos charges de travail. Comme le démon ne fait que gérer conteneurs, implémentant des commandes telles que docker run et docker rm , il n'est pas nécessaire qu'il reste pendant toute la période intermédiaire du cycle de vie d'un conteneur.
Restauration dynamique 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 de manière ponctuelle en exécutant dockerd avec le drapeau --live-restore flag :
sudo dockerd --live-restore
Pour activer en permanence la restauration en direct, ajoutez-la à votre fichier de configuration du démon Docker. Cela se trouve généralement dans /etc/docker/daemon.json . Vous devrez créer le fichier s'il n'existe pas déjà.
{
"live-restore": true
} 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 sera supprimée, mais les conteneurs continueront de fonctionner et conserveront leurs connexions réseau.
Docker détectera automatiquement les conteneurs existants lors de son 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 de démon active ne devrait pas avoir de conséquences graves, même sur une période prolongée. Cependant, vous constaterez que les journaux commencent à se perdre lors d'une panne prolongée du démon.
Les conteneurs Docker envoient leurs journaux dans un tampon premier entré, premier sorti (FIFO). 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é tant que le démon n'a pas terminé le vidage du tampon. Vous pouvez augmenter la taille du tampon en modifiant la valeur de /proc/sys/fs/pipe-max-size .
Mises en garde concernant la restauration en direct
La restauration en direct devrait couvrir la plupart des scénarios dans lesquels le démon Docker s'arrête et récupère ultérieurement. Cela inclut les mises à jour de Docker, mais uniquement entre les versions de correctifs mineurs. Si vous installez une nouvelle version majeure de Docker (telle que 19.03 au 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 au redémarrage du démon. 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 non planifiées. Si vous devez modifier les paramètres du démon, essayez plutôt de planifier des temps d'arrêt. Vous pouvez également utiliser systemctl reload docker pour recharger les fichiers de configuration sans redémarrer complètement le démon.
Il n'y a pas encore de Live Restore pour les conteneurs Windows. Vous pouvez utiliser Live Restore sur Windows avec des conteneurs basés sur Linux. Il est intégré à Docker Desktop et est activé via Préférences> Daemon> 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 plantage surprise, vos charges de travail doivent rester opérationnelles pendant le redémarrage du démon.
L'activation de Live Restore est une bonne pratique lors de l'exécution de Docker en production. Les outils d'analyse de la 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. Utiliser 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é.