Créer son cluster Swarm
Activation
Swarm n’est pas actif par defaut dans Docker.
Essayer la commande suivante:
$ docker node lsLe premier noeud d’un cluster Swarm est initialisé avec docker swarm init
Ne pas executer docker swarm init sur tous les noeuds !
Vous auriez plusieurs clusters différents.
Pour commencer il faut bien nommer ses machines.
Vérifier que les VMs ont bien 3 noms distincts, sinon renommer les !
$ sudo hostnamectl set-hostname node1
$ sudo hostnamectl set-hostname node2
$ sudo hostnamectl set-hostname node3Puis vérifier qu’ils sont bien synchronisé à un serveur de temps
Raft est très sensible sur les timing
$ sudo timedatectl set-timezone Europe/Paris
$ sudo timedatectl set-ntp trueMaintenant allons créer notre cluster sur le node1
$ docker swarm initIl est possible de choisir son interface de control(–advertise-addr/–listen-addr) et de data(–data-path-addr)
Le control plane est utilisé par Swarm pour les communications manager/worker, election Raft,…
Le data plane est utilisé pour les communications entre les conteneurs.
Les tokens
Docker à générer deux tokens pour notre cluster, un pour joindre les managers et l’autre pour joindre les workers.
Vous en avez aperçu un juste après l’initialisation.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-29jzjk0kmcunwcxlweugx75jhe0iqgokj2hdfkrad2ebrv640t-dsup5h5kmp5o7fndkk05zprkm 10.59.72.14:2377Verifier que nous avons bien activé Swarm
$ docker info
[...]
Swarm: active
[...]Ressayons la commande de tout a l’heure
$ docker node lsAjouter un noeud
Un cluster avec noeud c’est pas fun.
Ajoutons node2 à notre cluster en tant que worker.
Sur le node1
// Afficher le token des worker
$ docker swarm join-token worker Puis executer la commande affichée en sortie sur node2
$ ssh node2
$ docker swarm join ...Restons un peu sur ce node2
Verifions que la commande à bien activé Swarm
$ docker info | grep SwarmCependant, les commandes Swarm ne fonctionneront pas
$ docker node lsNous sommes sur node2, un worker, seuls les managers peuvent recevoir les commandes de cluster.
Retournons sur node1 et voyons a quoi ressemble notre cluster maintenant.
$ docker node lsLes tokens sont générés à l’initialisation du cluster, ce sont des certificats signés par le CA du cluster.
On peut les regénérer avec docker swarm join-token --rotate <worker|manager> si ils sont compromis.
Le control plance est crypté, les clefs sont regénérés toutes les 12h.
Les certificats eux sont valable 90 jours par défaut.
Le data plane, lui, n’est pas crypté par défaut mais peut être activé pas réseau.
Ajouter un autre manager
Nous avons donc un manager node1 et un worker node2.
Si on perd node1, on perd le quorum du Raft et c’est mal.
Les services continueront de fonctionner, mais plus aucune commande cluster ne sera accepté.
Si le manager ne revient pas, il va falloir faire une réparation manuelle, personne ne veut ça.
Allons ajouter le node3 en tant que manager.
// Sur un manager
$ docker docker swarm join-token manager
// Sur notre node3
$ docker swarm join --token ...Essayer la commande docker node ls sur le node3
L’étoile (*) à coté de l’ID du neud correspond au manager auquel nous sommes connectés.
Il est possible de changer le rôle d’un noeud via un manager.
Essayer de passer node2 en tant que manager
$ docker node promote node2Combien de manager a-t-on besoin ?
2N+1 noeuds peuvent tolérer N pannes.
1 manager = Pas de panne
3 managers = 1 panne
5 managers = 2 pannes (Ca nous donne le droit à l’erreur en cas de maintenance)
I ne faut pas mettre trop de manager, en règle générale 5 est suffisant pour un cluster, même très gros.
Plus on ajoute de managers, plus la réplication Raft mettra de temps.
La replication Raft doit essayer de rester sous les 10ms entre les managers.