Raspberry Cluster – S01E04 – La PiTeam et Swarm

Nous avons installé Docker sur tous les Raspberry Pi, maintenant nous allons pouvoir utiliser son orchestrateur natif « Swarm » pour pouvoir gérer le Raspberry Cluster.

Parlons orchestrateur

C’est quoi un orchestrateur ?

La PiTeam forme notre Raspberry Cluster, ce cluster est une « grappe » de ressources, ici des Raspberry Pi qui sont actuellement indépendants. Nous avons la possibilité de faire tourner individuellement sur chaque Raspberry Pi des applications au travers de conteneurs Docker, mais nous ne pouvons pas garantir une haute disponibilité de ces applications en cas de panne machine par exemple. Nous ne pouvons pas non plus maîtriser une montée en charge avec une seule machine, car elle peut vite réduire ses performances, voir devenir indisponible.

Afin de pouvoir gérer ce cluster de serveurs Docker, l’orchestrateur Swarm est né, il permet de gérer la PiTeam de notre Raspberry Cluster comme une seule et unique machine Docker.

Définition Wikipédia de l’Orchestration informatique :

L’orchestration décrit le processus automatique d’organisation, de coordination, et de gestion de systèmes informatiques complexes, de middleware et de services.

Pourquoi utiliser un orchestrateur ?

L’orchestrateur va nous permettre de gérer correctement notre infrastructure et les services qui vont tourner dessus, la rendre plus stable et disponible.

• Gérer son infrastructure de machines, manager ses ressources facilement (avec Swarm on les appelle les nœuds).
• Rendre son infrastructure et ses services stables et hautement disponibles.
• Avoir la capacité de monter en charge, on parlera de scalabilité (augmenter le nombre d’instances de nos services).
• Pouvoir répartir/distribuer la charge entre les différents nœuds, appelée aussi « load balancer« .
• Faire du déploiement continu.
• Faciliter la maintenance.
• Etre plus agile et efficace en facilitant le rollback (retour à une version antérieure) par exemple.

Il fait quoi Swarm dans tout ça ?

Swarm a évolué depuis ses débuts, il était au départ un logiciel compliqué à installer qui s’appelait Docker Swarm, depuis la version 1.12 de Docker il se fait appeler le mode Swarm !

Pour nous faciliter la lecture et désigner la dernière version utilisée « Swarm mode for Docker » (le nom officiel dans la documentation Docker), nous utiliserons « Swarm« , « Mode Swarm » ou « Docker Swarm« .

Voici une liste non-exhaustive (en fonction de ses mises à jour régulières) des fonctionnalités de Swarm :

• Il ordonnance « Schedule » et place les instances des applications sur les nœuds.
• Il déploie l’application une fois ses instances placées (en fonction de l’état souhaité).
• Il gère les règles de placement et les contraintes désirées (je peux souhaiter déployer un service sur un nœud spécifique par exemple pour une base de données).
• Il répartie la charge entre les différents nœuds automatiquement « Load Balancing« .
• Il fait des mises à jour sans interruption de service « Rolling Update« .
• Il se repart automatiquement »Self-Healing« , si un nœud s’arrête brutalement, il est capable sans interruption de service de relancer une instance de l’application sur un autre nœud.
• Il gère le trafic dans le réseau sans avoir besoin de connaître pour l’utilisateur sur quel nœud et à quelle adresse IP les instances de l’application se trouvent.
• Il sécurise et crypte les flux de données dans le réseau.
• Il gère des secrets des conteneurs (on peut mettre par exemple des mots de passes dans des fichiers non persistants, intégrés dans les conteneurs et cryptés par Swarm).
• Il s’occupe de maintenir l’état cible désirée de notre application (si l’on décrit vouloir 3 instances d’une application, qu’une devient KO, alors il va en recréer une autre sur un nœud).
• Il effectue un retour arrière « Rollback » sur un service avec une simple commande.

La PiTeam et Swarm

Nous avons suffisamment de compréhension pour commencer la mise en place de Swarm afin de gérer la PiTeam.

Swarm pour créer une architecture scallable et résiliente, mettons en place 2 types de nœuds : les Masters et les Workers.

2 Masters font leur apparition

A la construction du Raspberry Cluster, vous avez pu remarquer que j’ai installé au dernier étage 2 Raspberry Pi Zéro W, ils vont tout simplement me servir de Masters.

Les 2 Raspberry Pi Zéro W vont devenir des masters :

• PiErra-07 >> IP : 192.168.0.107
• PiErre-08 >> IP : 192.168.0.108

Les 6 autres Raspberry Pi 3 seront des Workers (ceux qui travaillent, même si les Masters sont aussi potentiellement des Workers, nous allons les contraindre à ne faire qu’une fonction de Master).

• PiErrik-01 >> IP : 192.168.0.101
• PiLar-02 >> IP : 192.168.0.102
• PiEtro-03 >> IP : 192.168.0.103
• PiMprenelle-04 >> IP : 192.168.0.104
• PiEl-05 >> IP : 192.168.0.105
• PiNa-06 >> IP : 192.168.0.106

Schéma du Raspberry Cluster Swarm

Initialisons le Cluster Swarm

PiErra et PiErre les faux jumeaux ont pris la grosse tête et veulent devenir les Masters du Cluster Swarm, pour se faire nous allons initialiser le projet (n’oubliez pas que tous les Raspberry Pi doivent avoir Docker d’installé).

• Se connecter en SSH à un Manager, ici PiErre-08 >> IP : 192.168.0.108.
• Exécuter la commande d’initialisation de Swarm.

docker swarm init

Vous obtenez la commande incluant le token pour rejoindre le Cluster Swarm.

Swarm initialized: current node (yo03wy5e4lux9qabre3n7fegv) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-41y64xnw2fqa9h6dxj4ueklpc14w5jsklqidkteouamc9a1joo-3vbfif4w6c38443od3406n0o1 192.168.0.108:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

• Se connecter en SSH à tous les autres Raspberry Pi de la PiTeam et exécutez la commande pour rejoindre le Cluster Swarm.

docker swarm join --token SWMTKN-1-41y64xnw2fqa9h6dxj4ueklpc14w5jsklqidkteouamc9a1joo-3vbfif4w6c38443od3406n0o1 192.168.0.108:2377

Vous devez obtenir un résultat positif.

This node joined a swarm as a worker.

Vérifions l’état de notre Cluster Swarm

Pour avoir accès au Cluster Swarm, nous devons simplement nous connecter en SSH au Manager, ici PiErre-08 >> IP : 192.168.0.108.

• Exécutez la commande qui permet de lister tous les nodes du Cluster Swarm.

docker node ls

Vous obtenez la liste de tous les nodes de votre Cluster Swarm !

Ce résultat est assez simple à lire :

• ID : l’id du nœud généré par Swarm (le *, veut dire que ce nœud est le manager).
• HOSTNAME : Le nom de votre Raspberry Pi, on voit bien que nos 8 Raspberry Pi sont présents.
• STATUS : Le statut du nœud, actuellement ils sont tous « Ready« .
• AVAILABILITY :  le nœud peut être « Actif« , en « Pause » ou « Drain« . « Drain » signifie que le nœud ne reçoit plus de nouvelles tâches de la part de Swarm, arrête ses tâches et qu’il est en cours de réplication (mode maintenance planifiée).
• MANAGER STATUS : On peut voir que c’est bien PiErre-08 qui est le Manager « Leader » (car il est actuellement le seul).

Gérer les Managers et Workers

Nous avons donc 1 Manager et 7 Workers, mais ce n’est pas l’architecture que nous voulions, car PiErra-07 doit aussi devenir manager.

• Se connecter en SSH à PiErre-08 >> IP : 192.168.0.108.
• Exécuter la commande permettant de promouvoir un Worker en Manager.

docker node promote sm5mzvn8brs5blzcvk4s5ldhl

Maintenant PiErra-07 obtient le Statut de Manager « Reachable«  (Accessible en français). Nous avons maintenant 2 Managers et 6 Workers !

Installons Docker Swarm Visualizer pour voir ce qu’il se passe !

Les lignes de commandes c’est bien, mais voir ce qu’il se passe en temps réel sur notre Raspberry Cluster, c’est encore mieux. Et pour cela nous allons installer notre premier service « Docker Swarm Visualizer« .

L’installation se fait à partir de l’un de nos Managers.

• Se connecter en SSH à PiErre-08 >> IP : 192.168.0.108.
• Exécuter la commande créant un nouveau service.

sudo docker service create \
        --name viz \
        --publish 8080:8080/tcp \
        --constraint node.role==manager \
        --mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
        alexellis2/visualizer-arm:latest

Petite explication de la commande ligne par ligne :

• sudo docker service create : commande de docker pour créer un nouveau service.
• –name viz : on veut que ce service s’appelle « viz« .
• –publish 8080:8080/tcp : on veut exposer ce service depuis internet et sur le réseau interne sur port 8080.
• –constraint node.role==manager : on veut contraindre (notion de règle ou contrainte) le service à n’être créé que sur des Managers (on ferra un test par la suite de scalabilité).
• –mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock : pour que les datas soient persistantes, on créait un volume en local.
• alexellis2/visualizer-arm:latest : on récupère la dernière image du Docker Hub de alexellis2/visualizer-arm (version arm pour les Raspberry Pi).

On peut ouvrir une fenêtre sur notre navigateur préféré sur l’une des adresses de notre Cluster (Swarm créant un Cluster unique, toutes les IP sont gérée par Swarm) sur le port 8080.

Alors là, c’est vraiment cool ! Mais dans le but d’avoir cette application hautement disponible, il faudrait que « viz » soit aussi sur PiErra-07 le 2ème Manager (dans le cas ou PiErre-08 aurait un problème).

Pour se faire, nous allons demander à Swarm de « scaler » l’application « viz« , c’est à dire de créer n instance du service ! Et pour voir si la contrainte qu’on a configurée lors de la création du service est bien opérationnelle, nous allons créer 5 instances.

• Se connecter en SSH à PiErre-08 >> IP : 192.168.0.108.
• Exécuter la commande pour « scaler » le service « viz« .

docker service scale viz=5

Lors de l’exécution de la commande, on s’aperçoit comme à la création qu’il y a téléchargement de l’image sur l’une des machines, mais pourquoi et laquelle (on voit aussi qu’une est déjà en « running », c’est celle de départ sur PiErre-08) ?

Et oui, sans surprise, 5 instances du service « viz » ont été créés seulement sur les 2 Managers.

Nous n’avons réellement pas besoin d’autant d’instance (c’est un service admin, donc pas de gros trafic dessus), nous allons redescendre à 2 instances 🙂

• Se connecter en SSH à PiErre-08 >> IP : 192.168.0.108.
• Exécuter la commande pour « scaler » le service « viz« .

docker service scale viz=2

Et HOP instantanément, Swarm a équilibré le placement des instances (2 managers = 1 instance chacun) !

Une application hautement disponible !

Pour  comprendre comment fonctionne Swarm, on va simplement créer un service Nginx sans configuration.

• Se connecter en SSH à PiErre-08 >> IP : 192.168.0.108.
• Exécuter la commande de création d’un service en récupérant l’image Nginx.

docker service create \
  --name nginx \
  nginx:latest

YESSSSS !!! Tout a bien fonctionné !!!

Bah Non ! C’est pas bon, si on y regarde de plus prêt notre application n’a aucun port exposé, donc pas de possibilité de voir le résultat dans un navigateur ! Mais j’ai la solution.

Au passage vous voyez une nouvelle commande qui permet de lister tous les services.

On va simplement utiliser la commande qui permet de mettre à jour les configurations d’un service.

• Exécutez la commande « service update« ,  le « tag » –publish-add avec le port publié et le port cible dans le réseau, sans oublier le nom du service.

docker service update --publish-add published=80,target=80 nginx

Et Hop !!! Maintenant ça marche (sur n’importe quelle IP du Raspberry Cluster)

Allez pour finir on va se faire un petit Kif, on va créer 15 instances de l’application et on va voir comment Swarm les gère.

• Exécuter la commande pour « scaler » le service « nginx« .

docker service scale nginx=15

C’est un petit long car l’image de nginx se télécharge sur tous les Raspeberry Pi, mais le résultat est bluffant.

Cet épisode est maintenant terminé, vous avez touché du doigt la puissance de l’orchestrateur Swarm et de toutes ses possibilités. Dans un prochain épisode, on fera des tests de chaos pour voir comment le Raspberry Cluster se comporte fasse aux pannes.