Aller au contenu

Quiz du chapitre 12 : Swarm : stacks et exploitation

Consignes

Autoévaluation : 10 questions, environ 10 minutes. Chaque question a une seule bonne réponse. Répondez d'abord de mémoire, puis cliquez sur « Réponse » pour vérifier. En cas d'erreur, relisez la section indiquée du cours.

Question 1. Deux services d'une même stack s'exécutent sur des nœuds différents. Comment le premier joint-il le second ?

  • A. Par l'adresse IP de l'hôte du second nœud, qu'il faut écrire dans le fichier
  • B. Par le nom du service, grâce au DNS du réseau overlay
  • C. Par un port publié obligatoirement sur chaque service
  • D. Ce n'est pas possible : les services doivent être sur le même nœud
Réponse

B. Un réseau overlay s'étend sur les nœuds du cluster et dispose d'un DNS intégré : le nom du service est résolu vers une adresse virtuelle qui répartit les connexions entre les tâches, où qu'elles soient (section 2.2).

Question 2. Que représente l'adresse obtenue en résolvant le nom app d'un service répliqué sur un réseau overlay ?

  • A. L'adresse de la première tâche du service
  • B. L'adresse du nœud manager
  • C. Une adresse virtuelle stable, qui répartit les connexions entre les tâches
  • D. L'adresse de l'hôte Docker du client
Réponse

C. Le nom du service donne une adresse virtuelle (VIP) qui reste stable quand les tâches changent. Le nom tasks.app donne, lui, les adresses des tâches (section 2.2).

Question 3. Pourquoi la clé build d'un fichier de stack est-elle ignorée par docker stack deploy ?

  • A. Parce que chaque nœud télécharge lui-même l'image : elle doit être publiée dans un registre accessible à tous
  • B. Parce que docker stack deploy ne sait pas lire un Dockerfile
  • C. Parce que la construction n'est possible que sur le manager
  • D. Parce que Swarm interdit les images construites localement
Réponse

A. Une tâche peut être placée sur n'importe quel nœud, qui doit pouvoir obtenir l'image : on construit et publie l'image avant de déployer la stack (section 3.3).

Question 4. Vous lancez deux fois la même commande docker stack deploy -c compose.yaml tp, après avoir modifié le nombre de répliques d'un service dans le fichier. Que se passe-t-il ?

  • A. La seconde commande est refusée car la stack existe déjà
  • B. Une deuxième stack tp_2 est créée
  • C. La stack est supprimée puis recréée entièrement
  • D. La même commande met à jour la stack existante pour la rendre conforme au fichier
Réponse

D. docker stack deploy crée la stack si elle n'existe pas, et la met à jour sinon : seuls les services dont la description a changé sont modifiés (section 3.1).

Question 5. Un secret Swarm est monté dans une tâche. Où l'application le trouve-t-elle ?

  • A. Dans une variable d'environnement du conteneur
  • B. Dans un fichier sous /run/secrets/, monté en mémoire
  • C. Dans les journaux du service
  • D. Dans la sortie de docker secret inspect
Réponse

B. Le secret est un fichier monté en mémoire sous /run/secrets/<nom>. docker secret inspect n'affiche jamais la valeur (section 4).

Question 6. Vous devez changer la valeur d'un secret utilisé par un service. Que faites-vous ?

  • A. docker secret update avec la nouvelle valeur
  • B. Vous modifiez directement le fichier sous /run/secrets/ dans le conteneur
  • C. Vous créez un nouveau secret, mettez le service à jour pour l'utiliser, puis supprimez l'ancien
  • D. Vous supprimez le secret : le service le recrée avec une valeur vide
Réponse

C. Secrets et configs sont immuables : on remplace l'objet par un nouvel objet, on met le service à jour, puis on supprime l'ancien. Un secret utilisé ne peut pas être supprimé (section 4).

Question 7. Quelle contrainte de placement limite un service aux nœuds workers ?

  • A. node.role == worker
  • B. node.type == worker
  • C. placement.workers == true
  • D. node.hostname == worker
Réponse

A. On exprime la contrainte dans deploy.placement.constraints, par exemple node.role == worker. D'autres critères existent : nom d'hôte, étiquettes posées avec docker node update --label-add (section 5).

Question 8. Un service db utilise un volume nommé. Le nœud qui héberge sa tâche tombe en panne. Que se passe-t-il ?

  • A. Swarm déplace aussi le volume vers un autre nœud
  • B. Swarm attend le retour du nœud avant de recréer la tâche
  • C. Le volume est répliqué automatiquement sur tous les nœuds
  • D. Swarm recrée la tâche sur un autre nœud, où le volume nommé est vide : les données restent sur le nœud en panne
Réponse

D. Un volume nommé est local à un nœud. Pour un service avec données, il faut le fixer à un nœud, utiliser un stockage partagé ou une base hors du cluster (section 5.1).

Question 9. Quel est l'effet de order: start-first dans update_config ?

  • A. Les tâches sont mises à jour dans l'ordre alphabétique
  • B. La nouvelle tâche est démarrée avant l'arrêt de l'ancienne, ce qui évite de réduire la capacité du service pendant la mise à jour
  • C. Toutes les tâches sont remplacées en même temps
  • D. La mise à jour commence par le manager
Réponse

B. Avec start-first, le service ne descend pas sous sa capacité ; il faut que l'application supporte la coexistence de deux versions (section 6.2).

Question 10. Vous voulez qu'une mise à jour qui échoue soit annulée sans intervention. Quel réglage utilisez-vous ?

  • A. restart_policy.condition: none
  • B. update_config.parallelism: 0
  • C. update_config.failure_action: rollback
  • D. placement.constraints: rollback
Réponse

C. Avec failure_action: rollback, Swarm revient automatiquement à la version précédente si la mise à jour échoue. Sans lui, la mise à jour se met en pause. On peut aussi revenir en arrière à la main avec docker service rollback (section 6).

Pour aller plus loin

Si plusieurs réponses sont fausses, refaites le Lab 12.1 (stacks, configs, placement) ou le Lab 12.2 (mises à jour, secrets, panne d'un nœud).