EXPLOITATION

Clusters et mise à l’échelle

Réunissez des serveurs en cluster, exécutez plusieurs répliques d’une application, et survivez à la panne d’un nœud.

Partout ailleurs, DockBoard place une application sur un seul hôte Docker. Un cluster répartit une même application sur plusieurs de vos serveurs, sur un réseau overlay, Docker se chargeant de planifier les tâches. C’est optionnel, application par application — toutes vos applications existantes restent sur le chemin compose, inchangées.

Former un cluster

Cluster → Créer un cluster, puis choisissez le serveur manager.

Le manager doit être un serveur distant — pas l’hôte DockBoard, qui fait tourner le plan de contrôle.
Ajouter un nœud rattache un autre serveur ONLINE comme worker. Un serveur n’appartient qu’à un cluster à la fois.
Retirer un nœud le fait quitter le Swarm. Supprimer un serveur encore dans un cluster est refusé tant qu’il n’est pas sorti.

Ports entre les nœuds

Les nœuds ont besoin de ces ports ouverts entre eux. Un rattachement qui reste bloqué, c’est presque toujours l’un d’eux :

Port	Ce qu’il transporte
`2377/tcp`	Gestion du cluster
`7946/tcp` + `7946/udp`	Découverte des nœuds
`4789/udp`	Trafic overlay

Le registre

Swarm ne construit pas d’images — chaque nœud doit *tirer* la même. Provisionner le registre déploie pour cela un registry:2 privé sur le manager, avec TLS et mot de passe. L’autorité de certification est transmise à chaque nœud au moment où il rejoint le cluster : les workers tirent l’image sans que personne ne touche à daemon.json.

Tant que le registre n’affiche pas Prêt, déployer une stack est refusé. Sans lui, les tâches planifiées sur les autres nœuds échoueraient au pull et ne démarreraient jamais.

Faire tourner une application sur le cluster

Sur la page de l’application : Cible de déploiement → Cluster Docker Swarm → choisissez le cluster → Appliquer. L’application doit être :

Basée sur Git: L’image est construite depuis le dépôt puis poussée dans le registre.
Compose piloté par DockBoard: Un docker-compose.yml commité fait foi et n’est jamais réécrit : il ne peut donc pas être converti en stack.
Sans état: Pas de volumes, pas de base embarquée. Une tâche peut être replanifiée sur un autre nœud à tout moment, et un volume local ne la suit pas.

Le déploiement clone, construit, pousse <registre>/<app>:<sha>, convertit le fichier compose en stack — build, container_name et depends_on retirés, image épinglée, ports republiés sur le maillage ingress, réseaux transformés en overlays, limites mémoire et CPU replacées sous deploy.resources — puis attend la convergence des services.

Ce qui change au quotidien

Action	Application compose	Application cluster
Arrêter	Conteneur arrêté	Ramené à 0 réplique
Démarrer	Conteneur démarré	Répliques remontées
Redémarrer	Conteneur redémarré	`service update --force` en roulement
Mettre à l’échelle	N conteneurs, un seul hôte	N tâches réparties sur le cluster, appliquées à chaud
Revenir en arrière	Build précédent restauré	`service rollback` vers la spec précédente
URL	Hôte du serveur + port publié	Chaque nœud répond sur le port de la stack

C’est cette dernière ligne qui compte. Le maillage de routage de Docker fait que n’importe quel nœud peut servir l’application : le reverse proxy reçoit donc tous les nœuds ONLINE comme upstreams. Perdez un nœud, le trafic continue de passer.

Refusé volontairement

Les applications avec volumes ou base embarquée — voir ci-dessus.
Déplacer une application cluster vers un serveur unique. Son placement *est* le cluster ; changez de cluster, ou repassez-la d’abord en compose. Voir déplacer un projet.
En faire une sauvegarde. Une stack n’a ni fichiers ni volumes sur un serveur donné : l’archive serait vide. Le refus est explicite plutôt que silencieux — voir sauvegardes.