Contraintes de placement

deploy.placement.constraints limite les nœuds sur lesquels un service peut tourner : par rôle, nom d'hôte, ou étiquettes que tu poses sur les nœuds. C'est ainsi qu'un service avec état reste là où sont ses données.

Comment ça marche

docker node update --label-add pgdata=true worker-1 étiquette un nœud ; node.labels.pgdata == true, node.role == worker ou node.hostname != manager-1 sont des contraintes. Si aucun nœud ne correspond, la tâche reste Pending avec no suitable node. placement.preferences répartit les répliques selon une étiquette (zones, baies) ; max_replicas_per_node les plafonne par nœud.

Ce qui casse

Les volumes sont locaux à un nœud. Une base sans contrainte est replanifiée sur un autre nœud quand le sien tombe, démarre sur un nouveau volume vide, et l'application y écrit comme si de rien n'était : les vraies données sont restées sur le nœud mort. Une contrainte échange cette perte silencieuse contre une indisponibilité visible.

Dans un terminal

docker node update --label-add pgdata=true worker-1

# stack.yaml
#   db:
#     deploy:
#       placement:
#         constraints:
#           - node.labels.pgdata == true

Regarde-le casser, puis répare-le

Écris le Dockerfile ou le fichier compose, tape les commandes docker, et regarde un serveur simulé les exécuter à travers redémarrages, mises à jour et trafic. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable