Accélérer le déploiement de logiciels - Un tutoriel Docker Swarm

À moins que vous n'ayez vécu à l'intérieur d'un conteneur maritime, vous avez probablement entendu parler de conteneurs. L'industrie s'est nettement éloignée des infrastructures persistantes vers les infrastructures éphémères, et les conteneurs sont au milieu de ce mouvement. La raison est assez simple : bien que les conteneurs aident certainement les équipes de développement à être rapidement opérationnels, ils ont encore plus de potentiel pour changer complètement le visage des opérations.

Mais à quoi cela ressemble-t-il exactement ? Que se passe-t-il lorsque vous êtes prêt à abandonner l'exécution de conteneurs localement ou manuellement sur quelques serveurs ? Dans un monde idéal, vous voulez simplement lancer votre application sur un cluster de serveurs et dire « lancez-la !

Heureusement, c'est là où nous en sommes aujourd'hui.

Dans cet article, nous allons explorer ce qu'est Docker Swarm, ainsi que certaines des fonctionnalités intéressantes qu'il a à offrir. Ensuite, nous verrons à quoi ressemblent réellement l'utilisation du mode Swarm et le déploiement dans un essaim, et nous terminerons avec quelques exemples de ce à quoi ressemblent les opérations quotidiennes avec un essaim déployé. Une connaissance de base de Docker et des conteneurs est certainement recommandée, mais vous pouvez d'abord consulter cet excellent article de blog si vous débutez avec les conteneurs.

Qu'est-ce que Docker Swarm ?

Avant de plonger dans la création et le déploiement de notre premier essaim, il est utile d'avoir une idée de ce qu'est Docker Swarm. Docker lui-même existe depuis des années, et la plupart des gens le considèrent aujourd'hui comme un environnement d'exécution de conteneur. En réalité cependant, Docker est composé de nombreuses pièces différentes, toutes travaillant ensemble. Par exemple, cette partie d'exécution du conteneur est gérée par deux composants plus petits, appelés runC et containerd. Au fur et à mesure que Docker a évolué et rendu à la communauté, ils ont découvert que la création de ces composants plus petits était le meilleur moyen de se développer et d'ajouter rapidement des fonctionnalités. En tant que tel, nous avons maintenant SwarmKit et le mode Swarm, qui est intégré directement dans Docker.

Docker Swarm est un moteur d'orchestration de conteneurs. À un niveau élevé, plusieurs moteurs Docker s'exécutent sur différents hôtes et vous permettent de les utiliser ensemble. L'utilisation est simple : déclarez vos applications en tant que piles de services et laissez Docker gérer le reste. Les services peuvent être n'importe quoi, des instances d'application aux bases de données, ou des utilitaires comme Redis ou RabbitMQ. Cela devrait vous sembler familier si vous avez déjà travaillé avec docker-compose en développement, car c'est exactement le même concept. En fait, une déclaration de pile n'est littéralement qu'un fichier docker-compose.yml avec la syntaxe de la version 3.1. Cela signifie que vous pouvez utiliser une configuration de composition similaire (et dans de nombreux cas identique) pour le développement et le déploiement en essaim, mais je m'avance un peu ici. Que se passe-t-il lorsque vous avez des instances de Docker en mode Swarm ?

Ne tombez pas du radeau

Nous avons deux types de nœuds (serveurs) dans le monde Swarm : les gestionnaires et les travailleurs. Il est important de garder à l'esprit que les managers sont aussi des travailleurs, ils ont juste la responsabilité supplémentaire de faire fonctionner les choses. Chaque essaim commence avec un nœud de gestionnaire désigné comme leader. À partir de là, il suffit d'exécuter une commande pour ajouter en toute sécurité des nœuds à l'essaim.

Swarm est hautement disponible grâce à son implémentation de l'algorithme Raft. Je n'entrerai pas trop dans les détails sur Raft car il existe déjà un excellent tutoriel sur son fonctionnement, mais voici l'idée générale : le nœud leader se connecte constamment avec ses collègues nœuds gestionnaires et synchronise leurs états. Pour qu'un changement d'état soit "accepté", les nœuds gestionnaires parviennent à un consensus, ce qui se produit lorsqu'une majorité des nœuds reconnaissent le changement d'état.

La beauté de cela est que les nœuds de gestion peuvent tomber sporadiquement sans compromettre le consensus de l'essaim. Si un changement d'état atteint un consensus, nous savons qu'il est garanti d'exister sur la majorité des nœuds de gestionnaire et qu'il persistera même si le leader actuel échoue.

Disons que nous avons trois nœuds de gestion nommés A, B et C. Bien sûr, A est notre leader intrépide. Eh bien, un jour, une erreur de réseau transitoire met A hors ligne, laissant B et C seuls. N'ayant pas eu de nouvelles de A depuis longtemps (quelques centaines de millisecondes), B et C attendent un laps de temps généré aléatoirement avant de se présenter à l'élection et de notifier l'autre. Bien sûr, le premier à se présenter aux élections, dans ce cas, sera élu. Dans cet exemple, B devient le nouveau leader et un quorum est rétabli. Mais alors, retournement de situation : que se passe-t-il lorsque A revient en ligne ? Il pensera que c'est toujours le leader, n'est-ce pas ? Chaque élection est associée à un terme, donc A a été élu au terme 1. Dès que A revient en ligne et commence à ordonner B et C, ils lui feront savoir que B est le leader du terme 2, et A démissionnera.

Ce même processus fonctionne à une échelle beaucoup plus grande, bien sûr. Vous pouvez avoir bien plus de trois nœuds de gestionnaire. Je vais cependant ajouter une autre note rapide. Chaque essaim ne peut subir qu'un nombre spécifique de pertes de manager. Un essaim de n nœuds de gestionnaire peut perdre (n-1)/2 gestionnaires sans perdre le quorum. Cela signifie que pour un essaim de trois managers, vous pouvez en perdre un, pour cinq, vous pouvez en perdre deux, etc.

Planification des tâches et rapprochement

Jusqu'à présent, nous avons établi que nos managers sont vraiment doués pour rester synchronisés. Génial! Mais que font-ils réellement ? Vous souvenez-vous que j'ai dit que vous déployiez une pile de services sur Swarm ? Lorsque vous déclarez vos services, vous fournissez à Swarm des informations importantes sur la manière dont vous souhaitez réellement que vos services soient exécutés. Cela inclut des paramètres tels que le nombre de répliques souhaitées pour chaque service, la manière dont les répliques doivent être distribuées, si elles ne doivent être exécutées que sur certains nœuds, etc.

Une fois qu'un service est déployé, il incombe aux gestionnaires de s'assurer que toutes les exigences de déploiement que vous définissez continuent d'être satisfaites. Supposons que vous déployiez un service Nginx et spécifiiez qu'il devrait y avoir trois répliques. Les gestionnaires verront qu'aucun conteneur n'est en cours d'exécution et répartiront uniformément les trois conteneurs sur les nœuds disponibles.

Ce qui est encore plus cool, cependant, c'est que si un conteneur devait échouer (ou si un nœud entier devait se déconnecter), le Swarm créera automatiquement des conteneurs sur les nœuds restants pour compenser la différence. Si vous dites que vous voulez que trois conteneurs fonctionnent, vous aurez trois conteneurs en cours d'exécution, tandis que Swarm gère tous les détails les plus élémentaires. De plus, et c'est un gros plus, la mise à l'échelle vers le haut ou vers le bas est aussi simple que de donner à Swarm un nouveau paramètre de réplication.

Découverte de services et équilibrage de charge

Je tiens à souligner un détail important mais subtil de ce dernier exemple : si Swarm démarre intelligemment des conteneurs sur les nœuds de son choix, nous ne savons pas nécessairement où ces conteneurs vont s'exécuter. Cela peut sembler effrayant au début, mais c'est en fait l'une des fonctionnalités les plus puissantes de Swarm.

Poursuivant le même exemple Nginx, imaginez que nous avons dit à Docker que ces conteneurs doivent exposer le port 80. Si vous pointez votre navigateur vers un nœud exécutant ce conteneur sur le port 80, vous verrez le contenu de ce conteneur. Il n'y a là aucune surprise. Ce qui peut être surprenant cependant, c'est que si vous envoyez votre requête à un nœud qui n'exécute pas ce conteneur, vous verrez toujours le même contenu ! Qu'est-ce qu'il se passe ici?

Swarm utilise en fait un réseau d'entrée pour envoyer votre demande à un nœud disponible exécutant ce conteneur, et il équilibre la charge en même temps. Donc, si vous faites trois requêtes au même nœud, vous allez probablement toucher les trois conteneurs différents. Tant que vous connaissez l'adresse IP d'un seul nœud de l'essaim, vous pouvez accéder à tout ce qui s'y exécute. Inversement, cela vous permet de pointer un équilibreur de charge (tel qu'un ELB) sur tous les nœuds de l'essaim sans avoir à vous soucier de ce qui s'exécute où.

Cela ne s'arrête pas aux connexions externes. Les services exécutés sur la même pile disposent d'un réseau superposé qui leur permet de communiquer entre eux. Au lieu de coder en dur les adresses IP dans votre code, vous pouvez simplement utiliser le nom du service comme nom d'hôte auquel vous souhaitez vous connecter. Par exemple, si votre application doit communiquer avec un service Redis nommé « redis », elle peut simplement utiliser « redis » comme nom d'hôte et Swarm acheminera sa demande vers le conteneur approprié. Et parce que cela fonctionne de manière transparente en développement avec docker-compose et en production avec Docker Swarm, c'est une chose de moins à craindre lors du déploiement de votre application.

Mises à jour continues

Si vous êtes dans les opérations, vous avez probablement subi une attaque de panique lorsqu'une mise à jour de production tourne terriblement mal. Il peut s'agir d'une mauvaise mise à jour du code, ou même simplement d'une erreur de configuration, mais soudain la production est arrêtée ! Il y a de fortes chances que le patron ne s'en soucie pas de toute façon. Ils vont juste savoir que c'est ta faute. Eh bien, ne vous inquiétez pas, Swarm a aussi votre dos sur celui-ci.

Lors de la mise à jour d'un service, vous pouvez définir le nombre de conteneurs à mettre à jour à la fois et ce qui doit se passer si les nouveaux conteneurs commencent à échouer. Après un certain seuil, Swarm peut soit arrêter la mise à jour, soit (à partir de Docker 17.04) restaurer les conteneurs à l'image et aux paramètres précédents. Ne vous inquiétez pas d'avoir à apporter un café à votre patron demain matin.

Sécurité

Dernier point, mais loin d'être le moindre, Docker Swarm est livré avec d'excellentes fonctionnalités de sécurité prêtes à l'emploi. Lorsqu'un nœud rejoint l'essaim, il utilise un jeton qui non seulement se vérifie lui-même, mais vérifie également qu'il rejoint l'essaim que vous pensez qu'il est. À partir de ce moment, toutes les communications entre les nœuds s'effectuent à l'aide d'un cryptage TLS mutuel. Ce cryptage est entièrement provisionné et géré automatiquement par le Swarm, vous n'avez donc jamais à vous soucier du renouvellement des certificats et des autres problèmes de sécurité typiques. Et bien sûr, si vous voulez forcer une rotation de clé, il y a une commande pour ça.

La dernière version de Docker Swarm est également livrée avec une gestion intégrée des secrets. Cela vous permet de déployer en toute sécurité des secrets tels que des clés et des mots de passe vers les services qui en ont besoin, et uniquement les services qui en ont besoin. Lorsque vous fournissez un secret à un service, les conteneurs de ce service auront un fichier spécial monté dans leur système de fichiers qui inclut la valeur du secret. Cela va sans dire, mais c'est beaucoup plus sûr que d'utiliser des variables d'environnement, qui étaient l'approche traditionnelle.

Plonger dans l'Essaim

Si vous êtes comme moi, vous avez hâte de vous lancer et d'essayer toutes ces fonctionnalités ! Alors sans plus tarder, plongeons-y !

Exemple d'application Docker Swarm

J'ai créé une application Flask très rudimentaire pour démontrer la puissance et la facilité d'utilisation de Docker Swarm. L'application Web affiche simplement une page qui vous indique quel conteneur a servi votre demande, combien de demandes au total ont été servies et quel est le mot de passe "secret" de la base de données.

Il est divisé en trois services : l'application Flask proprement dite, un proxy inverse Nginx et un keystore Redis. À chaque demande, l'application incrémente la clé num_requests dans Redis, donc quelle que soit l'instance Flask que vous utilisez, vous verrez le nombre correct de demandes reflétées.

Tout le code source est disponible sur GitHub si vous voulez « vérifier » ce qui se passe.

Jouez avec Docker !

N'hésitez pas à utiliser vos propres serveurs au cours de ce didacticiel, mais je vous recommande fortement d'utiliser play-with-docker.com si vous souhaitez simplement vous lancer. C'est un site géré par quelques développeurs Docker qui vous permet de créer plusieurs réseaux en réseau. nœuds sur lesquels Docker est préinstallé. Ils seront arrêtés après quatre heures, mais c'est beaucoup pour cet exemple !

Création d'un essaim

Bon, on y va ! Allez-y et créez trois instances dans PWD (play-with-docker) ou faites tourner trois serveurs dans votre service VPS (serveur privé virtuel) préféré et installez le moteur Docker sur chacun d'eux. Gardez à l'esprit que vous pouvez toujours créer une image et la réutiliser lors de l'ajout de nœuds à l'avenir. Il n'y a pas de différence logicielle entre un nœud de gestionnaire et un nœud de travail, vous n'avez donc pas besoin de gérer deux images différentes.

Toujours en train de tourner ? Ne vous inquiétez pas, j'attendrai. D'accord, nous allons maintenant créer notre premier nœud de gestionnaire et de leader. Sur votre première instance, initialisez un essaim :

 docker swarm init --advertise-addr <node ip here>

Remplacez <node_ip_here> par l'adresse IP de votre nœud. Sur PWD, l'adresse IP est affichée en haut, et si vous utilisez votre propre VPS, n'hésitez pas à utiliser l'adresse IP privée de votre serveur tant qu'elle est accessible depuis les autres nœuds de votre réseau.

Vous avez maintenant un essaim ! C'est un essaim assez ennuyeux, car il n'a qu'un seul nœud. Continuons et ajoutons les autres nœuds. Vous remarquerez que lorsque vous avez exécuté init , il a affiché un long message expliquant comment utiliser le jeton de jointure. Nous n'allons pas utiliser celui-là car cela ferait des autres nœuds des travailleurs, et nous voulons qu'ils soient des gestionnaires. Obtenons le jeton de jointure pour un gestionnaire en exécutant ceci sur le premier nœud :

 docker swarm join-token manager

Copiez la commande résultante et exécutez-la sur vos deuxième et troisième nœuds. Voici, un essaim à trois nœuds ! Vérifions que tous nos nœuds existent vraiment. La commande docker node ls tous les nœuds de notre essaim. Vous devriez voir quelque chose comme ceci :

 $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS su1bgh1uxqsikf1129tjhg5r8 * node1 Ready Active Leader t1tgnq38wb0cehsry2pdku10h node3 Ready Active Reachable wxie5wf65akdug7sfr9uuleui node2 Ready Active Reachable

Remarquez comment notre premier nœud a un astérisque à côté de l'ID. Cela nous dit simplement que c'est le nœud auquel nous sommes actuellement connectés. Nous pouvons également voir que ce nœud est actuellement le leader et que les autres nœuds sont accessibles si quelque chose devait lui arriver.

Prenez un moment pour apprécier à quel point c'était facile et déployons notre première application !

Expédier!

À peine arrivée, l'équipe de développement commercial a promis à un client que sa nouvelle application serait déployée et prête dans l'heure ! Typique, je sais. Mais n'ayez crainte, nous n'aurons pas besoin de beaucoup de temps, car il a été construit avec Docker ! Les développeurs ont eu la gentillesse de nous prêter leur fichier docker-compose :

 version: '3.1' services: web: image: lsapan/docker-swarm-demo-web command: gunicorn --bind 0.0.0.0:5000 wsgi:app deploy: replicas: 2 secrets: - db_password nginx: image: lsapan/docker-swarm-demo-nginx ports: - 8000:80 deploy: mode: global redis: image: redis deploy: replicas: 1 secrets: db_password: external: true

Nous allons le décomposer dans un instant, mais nous n'avons pas encore le temps. Déployons-le ! Allez-y et créez un fichier sur votre premier nœud appelé docker-compose.yml et remplissez-le avec la configuration ci-dessus. Vous pouvez le faire facilement avec echo "<pasted contents here>" > docker-compose.yml .

Normalement, nous pourrions simplement déployer ceci, mais notre configuration mentionne que nous utilisons un secret appelé db_password , alors créons rapidement ce secret :

 echo "supersecretpassword" | docker secret create db_password -

Génial! Il ne nous reste plus qu'à dire à Docker d'utiliser notre configuration :

 docker stack deploy -c docker-compose.yml demo

Lorsque vous exécutez cette commande, vous verrez Docker créer les trois services que nous avons définis : web , nginx et redis . Cependant, comme nous avons nommé notre pile démo, nos services sont en fait nommés demo_web , demo_nginx et demo_redis . Nous pouvons examiner nos services en cours d'exécution en exécutant la commande docker service ls , qui devrait afficher quelque chose comme ceci :

 $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS cih6u1t88vx7 demo_web replicated 2/2 lsapan/docker-swarm-demo-web:latest u0p1gd6tykvu demo_nginx global 3/3 lsapan/docker-swarm-demo-nginx:latest *:8000->80/ tcp wa1gz80ker2g demo_redis replicated 1/1 redis:latest

Voila ! Docker a téléchargé nos images sur les nœuds appropriés et créé des conteneurs pour nos services. Si vos répliques ne sont pas encore à pleine capacité, attendez un moment et vérifiez à nouveau. Docker est probablement encore en train de télécharger les images.

Voir c'est croire

Ne me croyez pas sur parole (ou sur la parole de Docker). Essayons de nous connecter à notre application. Notre configuration de service indique à Docker d'exposer NGINX sur le port 8000. Si vous êtes sur PWD, il devrait y avoir un lien bleu en haut de la page indiquant « 8000 ». PWD a en fait détecté automatiquement qu'un service s'exécute sur ce port ! Cliquez dessus et il vous dirigera vers le nœud sélectionné sur le port 8000. Si vous avez déployé vos propres serveurs, accédez simplement à l'une des adresses IP de vos serveurs sur le port 8000.

Vous serez accueilli avec un écran magnifiquement stylé vous donnant quelques informations de base :

Notez le conteneur qui a servi votre demande, puis actualisez la page. Il y a de fortes chances que cela ait changé. Mais pourquoi? Eh bien, nous avons dit à Docker de créer deux répliques de notre application Flask, et il distribue les requêtes à ces deux instances. Vous venez de toucher l'autre conteneur la deuxième fois. Vous remarquerez également que le nombre de requêtes a augmenté car les deux conteneurs Flask communiquent avec la seule instance Redis que nous avons spécifiée.

N'hésitez pas à essayer d'atteindre le port 8000 à partir de n'importe quel nœud. Vous serez toujours correctement dirigé vers l'application.

Démystifier la magie

À ce stade, tout fonctionne et, espérons-le, vous avez trouvé le processus indolore ! Examinons de plus près ce fichier docker-compose.yml et voyons ce que nous avons réellement dit à Docker. À un niveau élevé, nous voyons que nous avons défini trois services : web , nginx et redis . Tout comme un fichier de composition normal, nous avons fourni à Docker une image à utiliser pour chaque service, ainsi qu'une commande à exécuter. Dans le cas de nginx , nous avons également spécifié que le port 8000 sur l'hôte doit correspondre au port 80 dans le conteneur. Tout cela est une syntaxe de composition standard jusqu'à présent.

Ce qui est nouveau ici, ce sont les clés de déploiement et secrètes. Ces clés sont ignorées par docker-compose , elles n'affectent donc pas votre environnement de développement, mais sont utilisées par docker stack . Regardons le service Web. Assez simple, nous disons à Docker que nous aimerions exécuter deux répliques de notre application Flask. Nous informons également Docker que le service Web nécessite le secret db_password . C'est ce qui garantit que le conteneur aura un fichier nommé /run/secrets/db_password contenant la valeur du secret.

En descendant vers Nginx, nous pouvons voir que le mode de déploiement est défini sur global . La valeur par défaut (qui est implicitement utilisée dans web) est replicated , ce qui signifie que nous spécifierons le nombre de répliques que nous voulons. Lorsque nous spécifions global , cela indique à Docker que chaque nœud de l'essaim doit exécuter exactement une instance du service. Exécutez à nouveau le docker service ls , vous remarquerez que nginx a trois répliques, une pour chaque nœud de notre essaim.

Enfin, nous avons demandé à Docker d'exécuter une seule instance de Redis quelque part dans l'essaim. Peu importe où, car nos conteneurs Web y sont automatiquement acheminés lorsqu'ils demandent l'hôte Redis.

Utiliser Swarm au jour le jour

Félicitations pour le déploiement de votre première application sur un Docker Swarm ! Prenons un moment pour passer en revue quelques commandes courantes que vous utiliserez.

Inspecter votre essaim

Besoin de vérifier vos services ? Essayez docker service ls et docker service ps <service name> . Le premier vous montre un aperçu de haut niveau de chaque service, et le second vous donne des informations sur chaque conteneur en cours d'exécution pour le service spécifié. Celui-ci est particulièrement utile lorsque vous souhaitez voir quels nœuds exécutent un service.

Mises à jour continues

Qu'en est-il lorsque vous êtes prêt à mettre à jour une application ? Eh bien, ce qui est cool avec le docker stack deploy , c'est qu'il appliquera également les mises à jour à une pile existante. Supposons que vous ayez poussé une nouvelle image Docker vers votre référentiel. Vous pouvez en fait simplement exécuter la même commande de déploiement que vous avez utilisée la première fois et votre essaim téléchargera et déploiera la nouvelle image.

Bien sûr, vous ne voudrez peut-être pas toujours mettre à jour tous les services de votre pile. Nous pouvons également effectuer des mises à jour au niveau du service. Supposons que j'ai récemment mis à jour l'image de mon service Web. Je peux émettre cette commande pour mettre à jour tous mes conteneurs Web :

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ demo_web

Un avantage supplémentaire de cette commande est qu'elle appliquera une mise à jour continue si vous l'avez spécifié dans votre configuration d'origine. Et même si vous ne l'avez pas fait, vous pouvez passer des drapeaux à update qui lui demanderont de faire une mise à jour continue comme ceci :

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ --update-parallelism 1 --update-delay 30s \ demo_web

Cela mettra à jour un conteneur à la fois, en attendant 30 secondes entre les mises à jour.

Faire évoluer les services vers le haut ou vers le bas

Avoir deux conteneurs Web, c'est bien, mais vous savez ce qui est mieux ? Avoir dix! Faire évoluer les services vers le haut et vers le bas dans un essaim est aussi simple que :

 docker service scale demo_web=10

Exécutez cette commande et vérifiez la sortie du docker service ps demo_web . Vous verrez que nous avons maintenant dix conteneurs, et huit d'entre eux ont été démarrés il y a un instant. Si vous êtes intéressé, vous pouvez également revenir à l'application Web et actualiser la page plusieurs fois pour voir que vous obtenez maintenant plus que les deux ID de conteneur d'origine.

Suppression de piles et de services

Vos piles et services sont déployés et mis à l'échelle, génial ! Mais maintenant, vous voulez les mettre hors ligne. Cela peut être fait avec la commande rm correspondante. Pour supprimer notre pile de démonstration, exécutez la commande :

 docker stack rm demo

Ou, si vous préférez simplement supprimer un seul service, utilisez simplement :

 docker service rm demo_web

Nœuds de drainage

Rappelez-vous quand nous avons exécuté le docker node ls plus tôt pour vérifier les nœuds de notre essaim ? Il a fourni un tas d'informations sur chaque nœud, y compris sa disponibilité . Par défaut, les nœuds sont Active , ce qui signifie qu'ils sont parfaitement adaptés pour exécuter des conteneurs. Cependant, il peut arriver que vous deviez mettre temporairement un nœud hors ligne pour effectuer la maintenance. Bien sûr, vous pourriez simplement l'arrêter et l'essaim se rétablirait, mais c'est bien de donner à Moby (la baleine Docker) un peu de préavis.

C'est là qu'intervient le drainage des nœuds. Lorsque vous marquez un nœud comme Drain , Docker Swarm délèguera tous les conteneurs exécutés dessus à d'autres nœuds, et il ne démarrera aucun conteneur sur le nœud tant que vous ne redéfinissez pas sa disponibilité sur Active .

Disons que nous voulons drainer node1 . Nous pouvons lancer :

 docker node update --availability drain node1

Facile! Lorsque vous êtes prêt à le remettre au travail :

 docker node update --availability active node1

Emballer

Comme nous l'avons vu, Docker couplé au mode Swarm nous permet de déployer des applications de manière plus efficace et plus fiable que jamais. Il convient de mentionner que Docker Swarm n'est en aucun cas le seul moteur d'orchestration de conteneurs. En fait, c'est l'un des plus jeunes. Kubernetes existe depuis plus longtemps et est certainement utilisé dans davantage d'applications de production. Cela dit, Swarm est celui officiellement développé par Docker, et ils travaillent chaque jour à ajouter encore plus de fonctionnalités. Peu importe ce que vous choisissez d'utiliser, continuez à contenir !