Introduction
Dans ce laboratoire (lab), nous allons explorer comment gérer les rôles des nœuds (nodes) au sein d'un Docker Swarm. Plus précisément, nous allons nous concentrer sur l'utilisation de la commande docker node demote pour changer le rôle d'un nœud manager en celui d'un worker.
Le laboratoire vous guidera tout au long du processus d'initialisation d'un Docker Swarm, d'identification des nœuds manager actuels, d'exécution de la commande de déclassement (demotion), et enfin de vérification du nouveau rôle du nœud pour confirmer le déclassement réussi. Cette expérience pratique vous fournira des connaissances concrètes sur la gestion des nœuds Docker Swarm.
Initialiser un Docker Swarm
Dans cette étape, nous allons initialiser un Docker Swarm. Un Docker Swarm est un groupe de machines exécutant Docker et réunies en un cluster. Après avoir rejoint un Swarm, vous pouvez continuer à exécuter les commandes Docker auxquelles vous êtes habitué, mais elles sont désormais exécutées par un gestionnaire (manager) de Swarm. Les machines dans un Swarm peuvent être des gestionnaires (managers) ou des travailleurs (workers). Les gestionnaires gèrent les tâches de gestion du cluster, tandis que les travailleurs exécutent les services.
Avant d'initialiser le Swarm, vérifions la version actuelle de Docker.
docker version
Vous devriez voir une sortie similaire à celle-ci, indiquant la version de Docker installée sur la machine virtuelle (VM) LabEx :
Client: Docker Engine - Community
Version: 20.10.21
API version: 1.41
Go version: go1.16.20
Git commit: baeda1f
Built: Tue Oct 25 18:01:18 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.21
API version: 1.41 (minimum version 1.12)
Go version: go1.16.20
Git commit: 363bd3c
Built: Tue Oct 25 17:59:50 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.10
GitCommit: b4bd5d2b3d85c5e9b15588d67616e19a2a3a495d
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Maintenant, initialisons le Docker Swarm sur cette machine. Comme il s'agit du premier nœud (node) du Swarm, il deviendra automatiquement un nœud gestionnaire (manager). Nous allons utiliser la commande docker swarm init.
docker swarm init
Vous devriez voir une sortie indiquant que le Swarm a été initialisé et fournissant une commande pour rejoindre d'autres nœuds en tant que travailleurs (workers). La sortie ressemblera à ceci :
Swarm initialized: current node (xxxxxxxxxxxx) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 172.17.0.2:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
La sortie confirme que le Swarm est initialisé et que le nœud actuel est un gestionnaire (manager). Les xxxxxxxxxxxx seront remplacés par l'identifiant réel du nœud.
Lister les nœuds (nodes) du Swarm pour identifier les gestionnaires (managers)
Dans cette étape, nous allons lister les nœuds (nodes) du Docker Swarm pour identifier quels nœuds sont des gestionnaires (managers) et quels sont des travailleurs (workers). Étant donné que nous venons d'initialiser le Swarm avec un seul nœud, nous nous attendons à ne voir qu'un seul nœud dans la liste, et son rôle devrait être "Manager".
Pour lister les nœuds du Swarm, nous utilisons la commande docker node ls.
docker node ls
Vous devriez voir une sortie similaire à celle-ci :
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
xxxxxxxxxxxx * labex-vm Ready Active Leader 20.10.21
Décortiquons la sortie :
ID: L'identifiant unique du nœud. L'astérisque (*) à côté de l'ID indique le nœud actuel sur lequel vous exécutez la commande.HOSTNAME: Le nom d'hôte du nœud. Dans ce cas, c'estlabex-vm.STATUS: Le statut du nœud.Readysignifie que le nœud est en bonne santé et prêt à accepter des tâches.AVAILABILITY: Indique si le nœud est disponible pour planifier des tâches.Activesignifie qu'il est disponible.MANAGER STATUS: Montre le rôle du nœud dans le Swarm.Leaderindique que ce nœud est le gestionnaire principal (primary manager) dans le Swarm. S'il y avait d'autres gestionnaires, ils afficheraientReachable. Les nœuds travailleurs (worker nodes) auraient ce champ vide.ENGINE VERSION: La version du moteur Docker (Docker Engine) exécutée sur le nœud.
Comme prévu, nous voyons notre seul nœud dans la liste, et son MANAGER STATUS est Leader, confirmant qu'il s'agit d'un nœud gestionnaire (manager node).
Rétrograder un nœud gestionnaire (manager node)
Dans cette étape, nous allons rétrograder le nœud gestionnaire (manager node) actuel en nœud travailleur (worker node). Rétrograder un nœud gestionnaire signifie changer son rôle de gestion du Swarm à l'exécution simple de tâches en tant que travailleur. Cela est utile dans les scénarios où vous avez besoin de réduire le nombre de gestionnaires ou de changer le rôle d'un nœud spécifique.
Pour rétrograder un nœud gestionnaire, nous utilisons la commande docker node demote suivie de l'identifiant du nœud (node ID) ou du nom d'hôte (hostname). À partir de l'étape précédente, nous savons que le nom d'hôte est labex-vm.
docker node demote labex-vm
Vous devriez voir une sortie confirmant la rétrogradation :
Node labex-vm was demoted from a manager to a worker.
Cette sortie indique que le nœud labex-vm a été rétrogradé avec succès d'un rôle de gestionnaire à un rôle de travailleur au sein du Swarm.
Vérifier le rôle du nœud (node) après la rétrogradation
Dans cette étape finale, nous allons vérifier que le rôle du nœud a été modifié avec succès de gestionnaire (manager) à travailleur (worker) après l'opération de rétrogradation. Nous allons de nouveau utiliser la commande docker node ls pour lister les nœuds (nodes) du Swarm et vérifier la colonne MANAGER STATUS pour notre nœud.
docker node ls
Après avoir exécuté la commande, vous devriez voir une sortie similaire à celle-ci :
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
xxxxxxxxxxxx labex-vm Ready Active 20.10.21
Notez que la colonne MANAGER STATUS pour le nœud labex-vm est maintenant vide. Cela indique que le nœud n'est plus un gestionnaire et agit maintenant comme un nœud travailleur (worker node) dans le Swarm. L'astérisque (*) est toujours à côté de l'identifiant car c'est le nœud sur lequel vous exécutez la commande, mais son rôle a changé.
Cela confirme que la rétrogradation a été un succès.
Résumé
Dans ce laboratoire (lab), nous avons appris à gérer les nœuds (nodes) Docker Swarm en initialisant un Swarm et en identifiant les nœuds gestionnaires (manager nodes). Nous avons ensuite pratiqué l'utilisation de la commande docker node demote pour changer le rôle d'un nœud gestionnaire en nœud travailleur (worker node). Enfin, nous avons vérifié la réussite de la rétrogradation en listant les nœuds du Swarm et en observant le rôle mis à jour.
