Mode pull : convergence planifiée et découverte du parc

Jusqu'ici, vous déclenchiez la convergence. C'est le mode push, et il a une faille : entre deux exécutions, un collègue se connecte, modifie un fichier « juste pour tester », et la machine dérive sans que personne ne le sache. Ce module active le mode pull : l'agent se réveille tout seul, compare, et corrige. Vous verrez ensuite la seconde promesse du serveur, celle qu'on ne peut pas tenir sans lui : une recette qui découvre les autres machines par recherche, au lieu de coder leur adresse en dur. Public visé : avancés disposant d'un serveur CINC.

Ce que vous allez apprendre

• Planifier la convergence de l'agent.
• Prouver la correction automatique d'une dérive.
• Découvrir un nœud depuis une recette avec search.
• Éviter les pièges du DSL et des policy groups.

Prérequis

• Un serveur CINC avec au moins deux nœuds enrôlés.

Push, pull, et la dérive silencieuse

Le mode push est celui de knife zero converge : vous lancez la convergence, elle s'exécute, elle s'arrête. Entre deux lancements, la machine est livrée à elle-même. Quelqu'un arrête un service pendant un incident, supprime un fichier de configuration « temporairement », et plus rien ne le corrige. Au prochain redémarrage, ou au prochain incident, la surprise est mauvaise.

Le mode pull inverse la responsabilité : l'agent se réveille sur une planification, récupère sa configuration, et réapplique tout ce qui a dérivé. La machine ne peut plus s'éloigner longtemps de ce que vous avez décrit.

Le pull n'exige pas un serveur

Précision importante, car la confusion est fréquente : ce n'est jamais le serveur qui déclenche la convergence, c'est l'agent qui tire sa configuration. Le serveur est passif. On peut donc obtenir exactement la même correction de dérive sans serveur, en faisant trouver la configuration ailleurs à l'agent, comme le montre Exploiter Chef sans serveur.

Ce qui exige réellement le serveur, dans ce module, c'est la recherche (search), qui a besoin d'un index des nœuds.

Planifier la convergence

Sur une machine moderne, un timer systemd fait très bien l'affaire. Deux unités suffisent : un service qui lance l'agent une fois, et un timer qui le déclenche périodiquement.

/etc/systemd/system/cinc-client.service

[Unit]
Description=Convergence Chef (cinc-client)
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cinc-client

/etc/systemd/system/cinc-client.timer

[Unit]
Description=Convergence Chef planifiée

[Timer]
OnBootSec=1min
OnUnitActiveSec=2min
RandomizedDelaySec=15s

[Install]
WantedBy=timers.target

sudo systemctl enable --now cinc-client.timer

Trois réglages méritent un mot. OnBootSec laisse la machine finir son démarrage avant la première convergence. OnUnitActiveSec fixe la périodicité : ici 2 minutes, valeur de lab pour observer vite ; en production, 15 à 30 minutes est un choix courant.

RandomizedDelaySec évite l'effet troupeau

Sans RandomizedDelaySec, tous vos nœuds convergent à la même seconde et frappent le serveur ensemble. Sur un parc de plusieurs centaines de machines, c'est un pic de charge parfaitement évitable. Le délai aléatoire les étale.

Prouver la correction de dérive

Une planification qui tourne ne prouve rien. Ce qui prouve, c'est de casser la machine et de ne plus rien faire.

Partons d'un nœud conforme : nginx actif, sa configuration en place. Provoquons maintenant une vraie dérive, comme le ferait un collègue pressé :

sudo systemctl stop nginx
sudo rm -f /etc/nginx/conf.d/webstack.conf

inactive
conf SUPPRIMÉE

Le service est arrêté, le fichier a disparu. On ne touche plus à rien. Deux minutes plus tard, le timer se déclenche :

Jul 14 12:12:03 cinc-client[12315]:   * service[nginx] action start
Jul 14 12:12:03 cinc-client[12315]:     - start service service[nginx]
Jul 14 12:12:03 cinc-client[12315]: Infra Phase complete, 5/14 resources updated in 01 seconds

systemctl is-active nginx
ls /etc/nginx/conf.d/webstack.conf

active
/etc/nginx/conf.d/webstack.conf

La machine s'est réparée seule en 122 secondes, sans qu'aucune commande n'ait été tapée dessus. C'est ça, la valeur du mode pull : la dérive a une durée de vie maximale, et vous la choisissez.

Le pull ne remplace pas la discipline

Ne lisez pas cette démonstration comme un permis de bricoler les serveurs à la main : la correction automatique efface aussi les modifications légitimes qui n'ont pas été décrites dans un cookbook. C'est voulu, mais cela signifie que tout changement doit passer par le code. Le pull rend la règle inévitable au lieu de la laisser à la bonne volonté de chacun.

Découvrir le parc depuis une recette

Voici la seconde promesse du serveur, et celle qui justifie souvent son adoption à elle seule. Une recette peut interroger le serveur pour savoir quelles autres machines existent, au lieu de coder leur adresse en dur.

La fonction search prend un type d'objet et une requête. Ici : « donne-moi tous les nœuds qui portent la recette dbstack ».

cookbooks/webapp_search/recipes/default.rb

bases = search(:node, 'recipes:dbstack*')

# On construit la liste AVANT le bloc de ressource (voir le piège plus bas)
lignes = bases.map { |n| "  - #{n.name}: #{n['ipaddress']}" }.join("\n")

file '/etc/appdb/backends.yml' do
  owner   'root'
  group   'root'
  mode    '0644'
  content "backends:\n#{lignes}\n"
end

À la convergence, le serveur web découvre la base de données et écrit son adresse, alors que rien ne la lui avait donnée :

# Généré par Chef : aucune adresse codée en dur
backends:
  - db-srv1: 192.168.122.166

Mesurez ce que cela change. Le jour où la base est remplacée par une machine neuve, avec une autre adresse, le serveur web se reconfigure tout seul à sa prochaine convergence. Aucun fichier à éditer, aucune liste à tenir à jour. C'est la découverte dynamique, et c'est impossible en local mode : sans serveur, un nœud ignore l'existence des autres.

Le piège du DSL : ne pas interpoler dans un bloc de ressource

Erreur rencontrée, et son message est déroutant :

NoMethodError: undefined method `ipaddress' for Chef::Resource::File

À l'intérieur d'un bloc de ressource, Chef route les méthodes inconnues vers la ressource elle-même. Une interpolation qui appelle des méthodes sur un objet externe peut donc partir chercher ipaddress sur le fichier, et non sur le nœud. La parade est simple : calculez la valeur avant le bloc, et ne mettez dans le bloc qu'une variable déjà construite.

Un nœud en policy group ignore son run-list

Autre surprise. Si le nœud est rattaché à un policy group, sa configuration est entièrement pilotée par la Policyfile : ajouter une recette au run-list de l'objet nœud (knife node run_list add) ne change rien, et la recette ne s'exécutera jamais. Il faut l'ajouter au Policyfile.rb, puis chef update et chef push. C'est cohérent avec le modèle, mais cela surprend le premier jour.

Dépannage

La convergence planifiée échoue en silence par nature : personne ne regarde. Voici les symptômes à connaître avant qu'ils ne deviennent des incidents.

Symptôme	Cause probable	Solution
La dérive n'est pas corrigée	Le timer n'est pas actif	systemctl list-timers cinc-client.timer
Une modification manuelle disparaît	Comportement attendu du mode pull	Décrire le changement dans un cookbook
La recette ajoutée ne s'exécute pas	Le nœud est en policy group	L'ajouter au Policyfile.rb, puis chef update et chef push
undefined method ... for Chef::Resource::File	Interpolation dans un bloc de ressource	Calculer la valeur avant le bloc
search ne renvoie rien	La requête ne correspond à aucun nœud	Tester avec knife search node '<requête>'
Le serveur sature aux heures rondes	Tous les nœuds convergent ensemble	Ajouter RandomizedDelaySec

Glissez pour voir

À retenir

1. En mode push, la machine est livrée à elle-même entre deux convergences : la dérive s'installe sans bruit.
2. Le mode pull fait converger l'agent sur planification : la dérive a une durée de vie maximale, que vous choisissez.
3. Un timer systemd suffit : un service oneshot et un timer périodique.
4. RandomizedDelaySec évite que tout le parc frappe le serveur à la même seconde.
5. La correction automatique efface aussi les modifications légitimes non décrites : tout changement doit passer par le code.
6. search permet à une recette de découvrir les autres nœuds : plus d'adresse codée en dur, et une reconfiguration automatique quand le parc change.
7. Deux pièges : ne jamais interpoler dans un bloc de ressource, et se rappeler qu'un nœud en policy group ignore son run-list.

Pour aller plus loin

• Panorama des outils de gestion de configuration : comparer ce modèle pull à celui de Puppet, qui en a fait son défaut.

×

📖 Voir la documentation →