docker swarm

Tutoriel Docker Swarm

Mis à jours 18 avril 2022

Le système d’orchestration de conteneur est l’emplacement sur lequel la prochaine action est susceptible d’être en mouvement vers la construction → l’Expédition →l’Exécution des conteneurs à l’échelle. La liste des logiciels qui fournissent actuellement une solution pour cela sont Kubernetes, Docker Swarm, Apache Mesos et autres.

Ce tutoriel va parcourir le nouveau mode Docker Swarm, sur lequel le support d’orchestration de conteneur a été intégré dans le jeu d’outils Docker lui-même.

Cet article représente des apprentissages personnels et explore le mode Docker Swarm.

Pourquoi vouloir un système d’orchestration de conteneur ?

Pour faire simple, imaginez que vous deviez exécuter des centaines de conteneurs. Vous pouvez facilement voir que s’ils s’exécutent dans un mode distribué, il existe plusieurs fonctionnalités dont vous aurez besoin d’un point de vue de la gestion afin de vous assurer que le cluster est opérationnel, sain et plus.

La plupart de ces fonctionnalités indispensables comprennent :

  • Les bilans de santé sur les conteneurs
  • Le lancement d’un ensemble fixe de conteneurs pour une image Docker particulière
  • La mise à l’échelle du nombre de conteneurs de haut en bas en fonction du chargement
  • L’exécution de la mise à jour continue du logiciel à travers les conteneurs
  • et plus…

Vous découvrirez comment faire la plupart de ces tâches en utilisant Docker Swarm. La documentation de Docker et le tutoriel pour essayer le mode Swarm ont été excellents.

Les conditions pré-requises :

  • Vous devez connaitre les commandes Docker de base
  • Vous devez avoir Docker Toolbox installé sur votre système
  • Vous devez avoir au moins la version Docker 1.12

Créer des machines Docker

Créer des machines Docker

La première étape consiste à créer un ensemble de machines Docker qui serviront de nœuds dans votre Docker Swarm. Vous allez créer 6 Docker Machines, où l’un d’entre eux agira en tant que manager (Leader) et les autres seront des nœuds de travail. Vous pouvez créer moins de machines selon vos besoins.

On utilise la commande standard pour créer une Machine Docker nommé manager1 comme indiqué ci-dessous :

docker-machine create --driver hyperv manager1

Gardez à l’esprit que c’est fait sur Windows 10, qui utilise le manager Hyper-V natif, c’est pourquoi on utilise ce pilote. Si vous utilisez la boîte à outils Docker avec Virtual Box, cela ressemblerait à ceci :

docker-machine create --driver virtualbox manager1

De même, créez les autres nœuds de mots. Dans ce cas-ci, comme mentionné, il faut créer 5 autres nœuds de travail.

Après la création, il est conseillé de lancer la commande docker-machine ls pour vérifier l’état de toutes les machines Docker (sans oublier le PILOTE.)

NAME            DRIVER URL                         STATE
manager1        hyperv tcp://192.168.1.8:2376     Running
worker1         hyperv tcp://192.168.1.9:2376     Running
worker2         hyperv tcp://192.168.1.10:2376    Running
worker3         hyperv tcp://192.168.1.11:2376    Running
worker4         hyperv tcp://192.168.1.12:2376    Running
worker5         hyperv tcp://192.168.1.13:2376    Running

Notez l’adresse IP du manager1, puisque vous en aurez besoin. Vous pouvez l’appeler MANAGER_IP plus tard dans le texte.

La méthode pour obtenir l’adresse IP de la machine manager1 est la suivante :

$docker-machine ip manager1
192.168.1.8

Vous devriez être à l’aise pour faire un SSH dans l’une des machines Docker. Vous en aurez besoin car vous exécuterez principalement les commandes du docker depuis la session SSH vers cette machine.

Gardez à l’esprit qu’en utilisant l’utilitaire de la machine docker, vous pouvez utiliser SSH sur l’une des machines comme suit :

docker-machine ssh <nom-machine>

À titre d’exemple, voici mon SSH dans la machine docker manager1 :

$ docker-machine ssh manager1
                        ##         .
                  ## ## ##        ==
               ## ## ## ## ##    ===
           /"""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ /  ===- ~~~
           \______ o           __/
             \    \         __/
              \____\_______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.12.1, build HEAD : ef7d0b4 - Thu Aug 18 21:18:06 UTC 2016
Docker version 1.12.1, build 23cf638
docker@manager1:~$

Votre cluster Swarm

cluster swarm

Maintenant que vos machines sont configurées, vous allez procéder à la configuration de Swarm.

La première chose à faire c’est d’initialiser Swarm. Vous allez faire un SSH dans la machine manager1 et initialiser Swarm là-dedans.

$ docker-machine ssh manager1

Cela va initialiser la session SSH et vous devriez être à l’invite comme indiqué ci-dessous :

$ docker-machine ssh manager1
                        ##         .
                  ## ## ##        ==
               ## ## ## ## ##    ===
           /"""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ /  ===- ~~~
           \______ o           __/
             \    \         __/
              \____\_______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.12.1, build HEAD : ef7d0b4 - Thu Aug 18 21:18:06 UTC 2016
Docker version 1.12.1, build 23cf638
docker@manager1:~$

Effectuez les étapes suivantes :

$ docker swarm init --advertise-addr MANAGER_IP

Au niveau de la machine, ça ressemble à ceci :

docker@manager1:~$ docker swarm init — advertise-addr 192.168.1.8
Swarm initialized: current node (5oof62fetd4gry7o09jd9e0kf) is now a manager.

Pour ajouter un travailleur à cet swarm, exécutez la commande suivante :

docker swarm join \
 — token SWMTKN-1–5mgyf6ehuc5pfbmar00njd3oxv8nmjhteejaald3yzbef7osl1-ad7b1k8k3bl3aa3k3q13zivqd \
 192.168.1.8:2377

Pour ajouter un manager à ce swarm, lancez :

docker swarm join-token manager

Suivez les instructions.

docker@manager1:~$

Génial !

Vous remarquerez également que la sortie mentionne la commande de jointure docker swarm à utiliser dans le cas où vous souhaitez qu’un autre nœud se joigne en tant que travailleur.

Gardez à l’esprit que vous pouvez joindre un nœud en tant que travailleur ou en tant que manager. À tout moment, il n’y a qu’un seul LEADER et les autres nœuds du manager seront utilisés en tant que sauvegarde au cas où le LEADER actuel se désengagerait.

À ce stade, vous pouvez voir le statut de votre Swarm en entrant la commande suivante, comme indiqué ci-dessous :

docker@manager1:~$ docker node ls
ID              HOSTNAME STATUS AVAILABILITY MANAGER STATUS
5oof62fetd..*   manager1 Ready  Active       Leader

Cela montre qu’il n’existe qu’un seul nœud maintenant, c’est-à-dire manager1 et qu’il a la valeur de Leader pour la colonne MANAGER.

Restez dans la même session SSH pour manager1.

Rejoindre en tant que travailleur de Node

Pour savoir quelle commande docker swarm doit être utilisée pour se connecter en tant que nœud, vous devez utiliser la commande jeton de jointure <rôle>.

Pour connaître la commande de jointure d’un travailleur, exécutez la commande suivante :

docker@manager1:~$ docker swarm join-token worker

Pour ajouter un travailleur à ce swarm, exécutez la commande suivante :

docker swarm join \
 — token SWMTKN-1–5mgyf6ehuc5pfbmar00njd3oxv8nmjhteejaald3yzbef7osl1-ad7b1k8k3bl3aa3k3q13zivqd \
 192.168.1.8:2377
docker@manager1:~$

Rejoindre en tant que manager de Node

Pour connaître la commande de jointure d’un manager, exécutez la commande suivante :

docker swarm join \
 — token SWMTKN-1–5mgyf6ehuc5pfbmar00njd3oxv8nmjhteejaald3yzbef7osl1-ad7b1k8k3bl3aa3k3q13zivqd \
 192.168.1.8:2377
docker@manager1:~$

Notez dans les deux cas ci-dessus que vous avez reçu un jeton et qu’il rejoint le nœud manager (vous pourrez identifier que l’adresse IP est identique à l’adresse MANAGER_IP).

Gardez-le SSH sur manager1 ouvert. Lancez d’autres terminaux de commande pour travailler avec d’autres machines dockers.

Ajoutez des nœuds de travail à votre Swarm

Ajoutez des nœuds de travail à votre Swarm

Maintenant que vous savez comment vérifier la commande pour rejoindre en tant que Worker, vous pouvez l’utiliser pour faire un SSH dans chacune des machines Docker, puis déclencher la commande de jointure correspondante.

Dans ce cas-ci, il y a 5 machines Worker (Worker1/2/3/4/5). Pour la première machine Docker Worker1, on fait ce qui suit :

  • SSH dans la machine Worker1, c’est-à-dire docker-machine ssh Worker1
  • Ensuite, lancez la commande correspondante que vous avez obtenu en tant que travailleur. Dans ce cas-ci, la sortie est indiquée ci-dessous :
docker@worker1:~$ docker swarm join \
 — token SWMTKN-1–5mgyf6ehuc5pfbmar00njd3oxv8nmjhteejaald3yzbef7osl1-ad7b1k8k3bl3aa3k3q13zivqd \
 192.168.1.8:2377
Ce noeud a rejoint un swarm en tant que travailleur.
docker@worker1:~$

Faites la même chose en lançant des sessions SSH pour worker2/3/4/5 et en collant la même commande puisque l’on veut que tous soient des nœuds de travail.

Après avoir fait que tous les nœuds de travail rejoignent Swarm, retournez à votre session SSH worker1 et lancez la commande suivante pour vérifier l’état de votre Swarm, c’est-à-dire voir les nœuds qui y participent :

docker@manager1:~$ docker node ls
ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
1ndqsslh7fpquc7fi35leig54    worker4   Ready   Active
1qh4aat24nts5izo3cgsboy77    worker5   Ready   Active
25nwmw5eg7a5ms4ch93aw0k03    worker3   Ready   Active
5oof62fetd4gry7o09jd9e0kf *  manager1  Ready   Active        Leader
5pm9f2pzr8ndijqkkblkgqbsf    worker2   Ready   Active
9yq4lcmfg0382p39euk8lj9p4    worker1   Ready   Active
docker@manager1:~$

Comme prévu, vous pouvez voir qu’il y a  6 nœuds, un en tant que manager (manager1) et les 5 autres en tant que Worker. Vous pouvez également exécuter la commande standard docker info ici et zoomer dans la section Swarm pour vérifier les détails de votre Swarm.

Swarm: active
 NodeID: 5oof62fetd4gry7o09jd9e0kf
 Is Manager: true
 ClusterID: 6z3sqr1aqank2uimyzijzapz3
 Managers: 1
 Nodes: 6
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: 192.168.1.8

Notez quelques-unes des propriétés :

  • Swarm est marqué comme actif. Il a 6 nœuds au total et 1 manager parmi eux.
  • Lorsque vous exécutez la commande docker info sur le manager1 lui-même, cela montre que Is Manager comme true.
  • La section Raft est l’algorithme de consensus Raft utilisé. Consultez les détails ici.

Créer un service

Créer un service

Maintenant que votre swarm est opérationnel, il est temps de planifier vos conteneurs. C’est toute la beauté de la couche d’orchestration. Vous allez vous concentrer sur l’application et ne pas vous soucier de l’endroit où l’application va s’exécuter.

Tout ce que vous allez faire est de dire au manager de faire fonctionner les conteneurs pour vous et il prendra soin de programmer les conteneurs, d’envoyer les commandes aux nœuds et de les distribuer.

Pour démarrer un service, vous devez disposer des éléments suivants :

  • Quelle est l’image Docker que vous souhaitez exécuter ? Dans ce cas-ci, vous exécuterez l’image nginx standard qui est officiellement disponible depuis le Docker hub.
  • Vous exposerez votre service sur le port 80.
  • Vous pouvez spécifier le nombre de conteneurs (ou d’instances) à lancer. Ceci est spécifié via le paramètre des répliques.
  • Vous déciderez du nom de votre service. Et gardez ça à portée de main.

Ce que vous allez faire ensuite est de lancer 5 répliques du conteneur nginx. Pour ce faire, allez à nouveau dans la session SSH pour votre nœud manager1. Et entrez la commande de création de service docker suivante :

docker service create --replicas 5 -p 80:80 --name web nginxctolq1t4h2o859t69j9pptyye

Ce qui s’est passé, c’est que la couche d’orchestration va maintenant fonctionner.

Vous pouvez connaître l’état du service en donnant la commande suivante :

docker@manager1:~$ docker service ls
ID            NAME  REPLICAS  IMAGE  COMMAND
ctolq1t4h2o8  web   0/5       nginx

Cela montre que les répliques ne sont pas encore prêtes. Vous devrez entrer cette commande plusieurs fois.

En attendant, vous pouvez également voir l’état du service et comment il est orchestré pour les différents nœuds en utilisant la commande suivante :

docker@manager1:~$ docker service ps web
ID  NAME   IMAGE  NODE      DESIRED STATE  CURRENT STATE      ERROR
7i*  web.1  nginx  worker3   Running        Preparing 2 minutes ago
17*  web.2  nginx  manager1  Running        Running 22 seconds ago
ey*  web.3  nginx  worker2   Running        Running 2 minutes ago
bd*  web.4  nginx  worker5   Running        Running 45 seconds ago
dw*  web.5  nginx  worker4   Running        Running 2 minutes ago

Cela montre que les nœuds sont en cours d’installation. Cela pourrait prendre un moment.

Mais remarquez quelques petites choses. Dans la liste des nœuds ci-dessus, vous pouvez voir que les 5 conteneurs sont planifiés par la couche d’orchestration sur manager1, worker2, worker3, worker4 et worker5. Aucun conteneur n’est prévu pour le nœud worker1et c’est très bien.

Quelques exécutions du service docker ls montrent les réponses suivantes :

docker@manager1:~$ docker service ls
ID            NAME  REPLICAS  IMAGE  COMMAND
ctolq1t4h2o8  web   3/5       nginx
docker@manager1:~$

et enfin :

docker@manager1:~$ docker service ls
ID              NAME REPLICAS IMAGE COMMAND
ctolq1t4h2o8    web  5/5      nginx
docker@manager1:~$

Si vous regardez les processus de service à ce stade, vous pouvez voir ce qui suit :

docker@manager1:~$ docker service ps web
ID  NAME   IMAGE  NODE      DESIRED STATE  CURRENT STATE      ERROR
7i*  web.1  nginx  worker3   Running        Running 4 minutes ago
17*  web.2  nginx  manager1  Running        Running 7 minutes ago
ey*  web.3  nginx  worker2   Running        Running 9 minutes ago
bd*  web.4  nginx  worker5   Running        Running 8 minutes ago
dw*  web.5  nginx  worker4   Running        Running 9 minutes ago

Si vous faites un docker ps sur le nœud manager1 maintenant, vous constaterez que le démon nginx a été lancé.

docker@manager1:~$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
933309b04630        nginx:latest        "nginx -g 'daemon off"   2 minutes ago       Up 2 minutes        80/tcp, 443/tcp     web.2.17d502y6qjhd1wqjle13nmjvc
docker@manager1:~$

Accéder au service

Accéder au service

Vous pouvez accéder au service en cliquant sur l’un des nœuds du manager ou du travailleur. Cela n’a pas d’importance si le nœud en particulier n’a pas de conteneur planifié dessus. C’est toute l’idée de Swarm.

Essayez une boucle sur n’importe quelle adresse IP de la machine Docker (manager1 ou worker/2/3/4/5) ou tapez l’URL (https://<machine-ip>) dans le navigateur. Vous devriez être en mesure d’obtenir la page d’accueil NGINX standard.

nginx connexion

Ou si vous touchez l’adresse IP du worker.

1 9StJpbMTw7mYA yK2dwn5Q

C’est sympa, n’est-ce pas ?

Idéalement, vous devriez mettre le service Docker Swarm derrière un Load Balancer.

Contrôle de l’évolutivité

Ceci est fait via la commande d’évolutivité de service docker. Il y a actuellement 5 conteneurs en cours d’exécution. Augmentez-le jusqu’à 8 comme indiqué ci-dessous en exécutant la commande sur le nœud manager1.

$ docker service scale web=8
web scaled to 8

Maintenant, vous pouvez vérifier l’état du service et les tâches de processus via les mêmes commandes comme indiqué ci-dessous :

docker@manager1:~$ docker service ls
ID           NAME REPLICAS IMAGE COMMAND
ctolq1t4h2o8 web  5/8      nginx

Dans la commande ps web ci-dessous, vous trouverez qu’il a décidé de planifier les nouveaux conteneurs sur travailleur1 (2 d’entre eux) et manager1 (l’un d’entre eux)

ocker@manager1:~$ docker service ps web
ID   NAME   IMAGE  NODE      DESIRED STATE  CURRENT STATE                 ERROR
7i*  web.1  nginx  worker3   Running    Running 14 minutes ago
17*  web.2  nginx  manager1  Running    Running 17 minutes ago
ey*  web.3  nginx  worker2   Running    Running 19 minutes ago
bd*  web.4  nginx  worker5   Running    Running 17 minutes ago
dw*  web.5  nginx  worker4   Running    Running 19 minutes ago
8t*  web.6  nginx  worker1   Running    Starting about a minute ago
b8*  web.7  nginx  manager1  Running    Ready less than a second ago
0k*  web.8  nginx  worker1   Running    Starting about a minute ago

Vous attendez un moment, puis tout va bien, comme indiqué ci-dessous :

docker@manager1:~$ docker service ls
ID           NAME REPLICAS IMAGE COMMAND
ctolq1t4h2o8 web 8/8 nginxdocker@manager1:~$ docker service ps web
ID  NAME  IMAGE NODE     DESIRED STATE CURRENT STATE ERROR
7i* web.1 nginx worker3  Running       Running 16 minutes ago
17* web.2 nginx manager1 Running       Running 19 minutes ago
ey* web.3 nginx worker2  Running       Running 21 minutes ago
bd* web.4 nginx worker5  Running       Running 20 minutes ago
dw* web.5 nginx worker4  Running       Running 21 minutes ago
8t* web.6 nginx worker1  Running       Running 4 minutes ago
b8* web.7 nginx manager1 Running       Running 2 minutes ago
0k* web.8 nginx worker1  Running       Running 3 minutes agodocker@manager1:~$

Inspecter les nœuds

Vous pouvez inspecter les nœuds à tout moment via la commande d’inspection de nœud.

Par exemple, si vous êtes déjà sur le nœud (par exemple manager1) que vous voulez vérifier, vous pouvez utiliser le nom self pour le nœud.

$ docker node inspect self

Ou si vous voulez vérifier sur les autres nœuds, donnez le nom du nœud. Par exemple :

$ docker node inspect worker1

Drainer un nœud

Si le nœud est ACTIF, il est prêt à accepter des tâches provenant du maître, c’est-à-dire le manager. Par exemple vous pouvez voir la liste des nœuds et leur statut en entrant la commande suivante sur le nœud manager1.

docker@manager1:~$ docker node ls
ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
1ndqsslh7fpquc7fi35leig54    worker4   Ready   Active
1qh4aat24nts5izo3cgsboy77    worker5   Ready   Active
25nwmw5eg7a5ms4ch93aw0k03    worker3   Ready   Active
5oof62fetd4gry7o09jd9e0kf *  manager1  Ready   Active        Leader
5pm9f2pzr8ndijqkkblkgqbsf    worker2   Ready   Active
9yq4lcmfg0382p39euk8lj9p4    worker1   Ready   Active
docker@manager1:~$

Vous pouvez voir que leur DISPONIBILITÉ est réglée sur PRET.

Selon la documentation, lorsque le nœud est actif, il peut recevoir de nouvelles tâches :

  • Au cours d’une mise à jour de service pour intensifier
  • Lors d’une mise à jour progressive
  • Lorsque vous définissez un autre nœud pour drainer la disponibilité
  • Lorsqu’une tâche échoue sur un autre nœud actif

Mais parfois, vous devez mettre le nœud pour une raison de maintenance. Cela signifiait en définissant la Disponibilité sur le mode drain. Essayez cela avec l’un de vos nœuds.

Mais d’abord, vérifiez l’état de vos processus pour les services Web et sur les nœuds qu’ils exécutent :

docker@manager1:~$ docker service ps web
ID                         NAME   IMAGE  NODE      DESIRED STATE  CURRENT STATE           ERROR
7i*  web.1  nginx  worker3   Running        Running 54 minutes ago
17*  web.2  nginx  manager1  Running        Running 57 minutes ago
ey*  web.3  nginx  worker2   Running        Running 59 minutes ago
bd*  web.4  nginx  worker5   Running        Running 57 minutes ago
dw*  web.5  nginx  worker4   Running        Running 59 minutes ago
8t*  web.6  nginx  worker1   Running        Running 41 minutes ago
b8*  web.7  nginx  manager1  Running        Running 39 minutes ago
0k*  web.8  nginx  worker1   Running        Running 41 minutes ago

Vous voyez que vous avez 8 répliques de votre service :

  • 2 sur manager1
  • 2 sur worker1
  • 1 chacun sur worker2, worker3. worker4, worker5

Maintenant, utilisez une autre commande pour vérifier ce qui se passe dans le nœud worker1.

docker@manager1:~$ docker node ps worker1
ID   NAME   IMAGE  NODE     DESIRED STATE  CURRENT STATE           8t*  web.6  nginx  worker1  Running        Running 44 minutes ago
0k*  web.8  nginx  worker1  Running        Running 44 minutes agodocker@manager1:~$

Nous pouvons également utiliser la commande docker d’inspection de nœud pour vérifier la disponibilité du nœud et comme prévu, vous trouverez une section dans la sortie comme suit :

$ docker node inspect worker1
….."Spec": {
 "Role": "worker",
 "Availability": "active"
 },
…

Ou

docker@manager1:~$ docker node inspect — pretty worker1
ID: 9yq4lcmfg0382p39euk8lj9p4
Hostname: worker1
Joined at: 2016–09–16 08:32:24.5448505 +0000 utc
Status:
 State: Ready
 Availability: Active
Platform:
 Operating System: linux
 Architecture: x86_64
Resources:
 CPUs: 1
 Memory: 987.2 MiB
Plugins:
 Network: bridge, host, null, overlay
 Volume: local
Engine Version: 1.12.1
Engine Labels:
 — provider = hypervdocker@manager1:~$

Vous pouvez voir qu’il est “Actif” pour son attribut Disponibilité.

Maintenant, définissez la Disponibilité en DRAINER. Lorsque vous entrez cette commande, le manager arrête les tâches s’exécutant sur ce nœud et lance les répliques sur d’autres nœuds avec la disponibilité ACTIVE.

Donc, ce que l’on attend, c’est que le Manager amènera les 2 conteneurs en cours d’exécution sur travailleur1 et les planifie sur les autres nœuds (manager1 ou travailleur2 ou travailleur3 ou travailleur4 ou travailleur5).

Cela se fait en mettant à jour le nœud en définissant sa disponibilité en “drainer”.

docker@manager1:~$ docker node update --availability drain worker1
worker1

Maintenant, si vous faites un état de processus pour le service, vous voyez une sortie intéressante (la sortie a été allégée pour un formatage correct) :

docker@manager1:~$ docker service ps web
ID   NAME       IMAGE  NODE      DESIRED STATE  CURRENT STATE                 
7i*  web.1      nginx  worker3   Running   Running about an hour ago
17*  web.2      nginx  manager1  Running   Running about an hour ago
ey*  web.3      nginx  worker2   Running   Running about an hour ago
bd*  web.4      nginx  worker5   Running   Running about an hour ago
dw*  web.5      nginx  worker4   Running   Running about an hour ago
2u*  web.6      nginx  worker4   Running   Preparing about a min ago
8t*   \_ web.6  nginx  worker1   Shutdown  Shutdown about a min ago
b8*  web.7      nginx  manager1  Running   Running 49 minutes ago
7a*  web.8      nginx  worker3   Running   Preparing about a min ago
0k*   \_ web.8  nginx  worker1   Shutdown  Shutdown about a min agodocker@manager1:~$

Vous pouvez voir que les conteneurs sur le worker1 (que vous avez demandé à être drainé) sont reprogrammés sur d’autres travailleurs. Dans le scénario ci-dessus, ils ont été planifiés respectivement sur worker2 et worker3. Ceci est requis car vous avez demandé que les 8 répliques soient exécutées lors d’un exercice de mise à l’échelle antérieure.

Vous pouvez voir que les deux conteneurs sont toujours à l’état de “Préparation” et après un certain temps si vous exécutez la commande, ils s’exécutent tous comme indiqué ci-dessous :

docker@manager1:~$ docker service ps web
ID  NAME       IMAGE  NODE      DESIRED STATE  CURRENT STATE              
7i*  web.1      nginx  worker3   Running   Running about an hour ago
17*  web.2      nginx  manager1  Running   Running about an hour ago
ey*  web.3      nginx  worker2   Running   Running about an hour ago
bd*  web.4      nginx  worker5   Running   Running about an hour ago
dw*  web.5      nginx  worker4   Running   Running about an hour ago
2u*  web.6      nginx  worker4   Running   Running 8 minutes ago
8t*   \_ web.6  nginx  worker1   Shutdown  Shutdown 8 minutes ago
b8*  web.7      nginx  manager1  Running   Running 56 minutes ago
7a*  web.8      nginx  worker3   Running   Running 8 minutes ago
0k*   \_ web.8  nginx  worker1   Shutdown  Shutdown 8 minutes ago

Cela fait une démo cool, n’est-ce pas ?

Supprimer le service

Vous pouvez simplement utiliser la commande service rm comme indiqué ci-dessous :

docker@manager1:~$ docker service rm web
webdocker@manager1:~$ docker service ls
ID NAME REPLICAS IMAGE COMMANDdocker@manager1:~$ docker service inspect web
[]
Error: no such service: web

Application des mises à jour progressives

C’est simple. Dans le cas où vous avez une image Docker mise à jour à déployer vers les nœuds, tout ce que vous devez faire est de lancer une commande de mise à jour de service.

Par exemple :

$ docker service update --image <imagename>:<version> web

Conclusion

La simplicité de Docker Swarm est définitivement impressionnante. Tout comme les commandes de base fournies avec le jeu d’outils Docker standard, il a été judicieux d’introduire les commandes Swarm dans le même jeu d’outils.

Docker Swarm a beaucoup plus à offrir et vous devriez creuser davantage dans la documentation.

Il est difficile de savoir lequel de Kubernetes ou de Swarm ressortira gagnant, mais il ne fait aucun doute que vous devriez comprendre les deux pour voir quelles sont leurs capacités et ensuite prendre une décision.

Aina Strauss

À découvrir

ThePirateBay

Piratebay: Le Guide Complet

Mis à jours 20 janvier 2021 The Pirate Bay (littéralement “Bateau pirate”) est considéré comme …