Créer son cluster Swarm

Activation

Swarm n’est pas actif par defaut dans Docker.
Essayer la commande suivante:

$ docker node ls

Le premier noeud d’un cluster Swarm est initialisé avec docker swarm init

Information

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 node3

Puis 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 true

Maintenant allons créer notre cluster sur le node1

$ docker swarm init
Information

Il 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:2377

Verifier que nous avons bien activé Swarm

$ docker info
[...]
Swarm: active
[...]

Ressayons la commande de tout a l’heure

$ docker node ls

Ajouter 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 Swarm

Cependant, les commandes Swarm ne fonctionneront pas

$ docker node ls

Nous 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 ls
Astuce

Les 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.

Information

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 ...
Information

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 node2
Astuce

Combien 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.