Exploiter Chef sans serveur : l'architecture pérenne

Le Chef Infra Server open source est en fin de vie fin 2026. La question devient donc concrète : que perd-on vraiment sans lui ? La réponse surprend. La convergence planifiée, la correction automatique de dérive et la promotion d'une version en production ne dépendent pas du serveur. Ce module monte l'architecture sans serveur de bout en bout et la prouve : une machine sabotée se répare seule en 112 secondes, sans qu'aucun serveur n'existe. Vous verrez aussi, sans détour, ce qui n'est pas remplaçable. Public visé : avancés qui veulent une base pérenne.

Ce que vous allez apprendre

• Exporter une policy en archive autonome.
• Distribuer la policy par un dépôt d'artefacts.
• Corriger la dérive sans serveur.
• Promouvoir une version sans serveur.

Prérequis

• Maîtriser les Policyfiles.
• Avoir lu Quel avenir pour Chef et CINC.

Ce que le serveur apportait, et ce qui le remplace

Commençons par le tri, car beaucoup de monde croit le serveur indispensable là où il ne l'est pas.

Capacité du serveur	Remplaçable sans serveur ?
Distribuer les cookbooks	Oui : archive autonome sur un dépôt d'artefacts
Convergence planifiée	Oui : un timer systemd sur le nœud
Corriger la dérive	Oui : c'est la convergence planifiée qui le fait
Promouvoir une version	Oui : on publie une nouvelle archive
Rechercher dans le parc (search)	Non : exige un index des nœuds
Inventaire centralisé	Non : exige un collecteur
chef-vault (secrets par nœud)	Non : exige les clés publiques des nœuds

Glissez pour voir

Quatre capacités sur sept se passent du serveur, et ce sont précisément celles dont on se sert tous les jours. Les trois autres ont des substituts que nous verrons à la fin.

Le nœud tire, le serveur ne pousse jamais

Dissipons une confusion tenace. Même avec un serveur, ce n'est jamais lui qui déclenche la convergence : c'est l'agent, sur le nœud, qui se réveille et qui tire sa configuration. Le serveur est passif, il répond. C'est exactement pour cela qu'on peut le remplacer : il suffit que l'agent trouve sa configuration ailleurs.

Exporter la policy en archive autonome

La commande chef export est la pièce maîtresse, et elle est étonnamment peu connue. Elle transforme une policy verrouillée en une archive complète et autoportante : les cookbooks, leurs dépendances, le verrouillage, et même la configuration client nécessaire.

chef install               # verrouille la policy
chef export Policyfile.rb export

Le résultat pèse quelques centaines de kilo-octets et contient tout :

export/
├── .cinc/config.rb          ← la configuration client, générée
├── cookbook_artifacts/      ← les cookbooks, verrouillés par empreinte
├── policies/
├── policy_groups/
└── Policyfile.lock.json

L'archive porte même son mode d'emploi : cd export && cinc-client -z. Le drapeau -z (local mode) démarre un serveur Chef éphémère en mémoire, le temps de la convergence. Le nœud n'a rien à contacter.

La configuration générée est explicite sur le mécanisme :

policy_name  'web'
policy_group 'local'
use_policyfile true

Distribuer par un dépôt d'artefacts

Reste à faire arriver cette archive sur les nœuds. C'est exactement le problème que résolvent les dépôts d'artefacts, et vous en avez sûrement déjà un.

Le principe est celui de n'importe quelle livraison logicielle : la CI construit l'archive, la publie sous un numéro de version, et un pointeur désigne ce qui est en production.

policies/
├── web-1.0.0.tgz
├── web-1.1.0.tgz
└── web-prod.tgz  →  web-1.1.0.tgz

Un Nexus, un bucket S3, ou même un dépôt Git font parfaitement l'affaire. L'archive est immuable et versionnée : vous savez exactement ce qui tourne, et vous pouvez revenir en arrière en republiant l'ancienne.

Le nœud tire et converge

Sur le nœud, un petit script fait le travail du serveur : il récupère l'archive publiée, ne la redéploie que si elle a changé (comparaison d'empreinte), puis converge.

#!/bin/sh
set -e
URL="https://artefacts.exemple.fr/policies/web-prod.tgz"
DEST=/var/chef-policy

tmp=$(mktemp -d)
curl -fsSL "$URL" -o "$tmp/policy.tgz"

# On ne redéploie que si l'archive a changé
new=$(sha256sum "$tmp/policy.tgz" | cut -d' ' -f1)
old=$(cat /var/lib/chef-policy.sha 2>/dev/null || echo none)

if [ "$new" != "$old" ]; then
  rm -rf "$DEST" && mkdir -p "$DEST"
  tar xzf "$tmp/policy.tgz" -C "$DEST"
  echo "$new" > /var/lib/chef-policy.sha
fi
rm -rf "$tmp"

cd "$DEST" && exec /usr/bin/cinc-client -z

La comparaison d'empreinte n'est pas un détail : elle évite de réécrire l'arborescence à chaque passage, et elle vous dit quand la policy a changé.

Un timer systemd l'exécute périodiquement :

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

[Unit]
Description=Convergence locale planifiée

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

[Install]
WantedBy=timers.target

RandomizedDelaySec évite l'effet troupeau

Sans RandomizedDelaySec, tous vos nœuds tapent le dépôt d'artefacts à la même seconde. Le délai aléatoire les étale. En production, une périodicité de 15 à 30 minutes est un choix courant ; les 2 minutes utilisées ici servent à observer vite.

Prouver la correction de dérive, sans serveur

Une planification qui tourne ne prouve rien. Cassons la machine, et ne faisons plus rien.

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

inactive
conf SUPPRIMÉE

Le service est arrêté, sa configuration a disparu, et aucun serveur n'existe pour s'en apercevoir. On attend.

cassé à 14:17:49
réparé à 14:19:41, soit 112 s plus tard

systemctl is-active nginx

active

112 secondes, sans serveur, sans intervention. La dérive a une durée de vie maximale, et c'est vous qui la fixez, avec OnUnitActiveSec. La machine ne connaît d'ailleurs aucun serveur :

sudo grep chef_server_url /etc/cinc/client.rb

# chef_server_url  "https://CHEF.MYCOMPANY.COM/organizations/MY_CHEF_ORG"

La seule occurrence est une ligne commentée dans la configuration par défaut.

Promouvoir sans serveur

Il reste la promotion. Avec un serveur, on faisait chef push prod. Sans serveur, on publie une nouvelle archive et on déplace le pointeur :

chef update                          # nouvelle révision
chef export Policyfile.rb export
# publication de web-1.1.0.tgz, puis :
ln -sfn web-1.1.0.tgz policies/web-prod.tgz

On ne touche à aucun nœud. À sa prochaine convergence, le nœud détecte que l'empreinte a changé, redéploie, et applique la nouvelle version :

sudo cat /var/www/webstack/index.html

webstack v1.1.0 promue sans serveur

L'empreinte déployée sur le nœud correspond exactement à l'artefact publié :

nœud   : e20981b6325deb379990ea2f17d7dbed68c5b8b3c63715940a6716eee39e980d
artefact : e20981b6325deb379990ea2f17d7dbed68c5b8b3c63715940a6716eee39e980d

Vous retrouvez donc la garantie des policy groups (« la production exécute exactement ce qui a été validé »), portée cette fois par le dépôt d'artefacts au lieu du serveur.

Un rollback est une republication

Comme les archives sont immuables et versionnées, revenir en arrière consiste à repointer web-prod.tgz vers l'ancienne version. Les nœuds reviennent seuls à la convergence suivante. C'est la même opération, dans l'autre sens.

Ce qui n'est pas remplaçable, et par quoi le remplacer

Soyons honnêtes sur les trois capacités qui exigent réellement un service central. Aucune n'est un obstacle, mais chacune demande un complément.

La recherche (search) suppose un index des nœuds. Sans serveur, un nœud ignore l'existence des autres. Le substitut naturel est un annuaire de services : Consul, etcd, ou simplement le DNS interne. En environnement cloud, les métadonnées de l'instance et les étiquettes jouent souvent ce rôle. Une recette peut interroger l'un ou l'autre exactement comme elle interrogeait le serveur.

L'inventaire centralisé (« quelles machines existent, dans quel état ? ») demande un collecteur. Chef sait émettre un rapport de convergence ; il suffit de l'envoyer vers une collecte de logs ou une base. Vous ne perdez pas la donnée, vous changez de destinataire.

Les secrets par nœud (chef-vault) reposent sur les clés publiques que seul un serveur conserve. Le substitut est meilleur que l'original : HashiCorp Vault, qui apporte en prime la rotation et les secrets dynamiques, deux choses que chef-vault ne sait pas faire. À défaut, un data bag chiffré avec une clé distribuée à l'installation reste utilisable.

Ne reconstruisez pas un serveur par accident

La tentation est grande d'ajouter Consul, un collecteur et Vault « pour tout retrouver ». Demandez-vous d'abord si vous en avez réellement besoin. Beaucoup de parcs vivent très bien sans recherche : les rôles sont connus au provisionnement, et une adresse de base de données tient dans un attribut. Le serveur avait aussi ses coûts ; les remplaçants ont les leurs.

Dépannage

L'architecture sans serveur échoue en silence, comme toute exécution planifiée. Voici les symptômes qui doivent vous alerter.

Symptôme	Cause probable	Solution
La dérive n'est pas corrigée	Le timer n'est pas actif	systemctl list-timers puis les journaux de l'unité
Le nœud n'adopte pas la promotion	L'empreinte n'a pas changé	Vérifier que le pointeur prod désigne bien la nouvelle archive
La convergence échoue en local mode	L'archive est incomplète	La régénérer avec chef export (jamais copier cookbooks/ à la main)
Une modification manuelle disparaît	Comportement attendu	Tout changement doit être décrit dans un cookbook
Le dépôt d'artefacts sature	Tous les nœuds tirent en même temps	Ajouter RandomizedDelaySec

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Le serveur ne pousse jamais : c'est l'agent qui tire. On peut donc le remplacer, il suffit que la configuration soit ailleurs.
2. chef export produit une archive autonome : cookbooks, verrouillage et configuration client, prête pour cinc-client -z.
3. Un dépôt d'artefacts (Nexus, S3, Git) remplace la distribution du serveur, avec des versions immuables.
4. Un timer systemd remplace la convergence planifiée : la dérive est corrigée en 112 secondes dans notre lab, sans aucun serveur.
5. La promotion devient une republication : on déplace le pointeur, les nœuds suivent seuls. Le rollback est la même opération.
6. Trois capacités exigent un complément : la recherche (Consul, DNS), l'inventaire (un collecteur), et les secrets par nœud (HashiCorp Vault, meilleur que chef-vault).
7. Cette architecture ne dépend d'aucun composant en fin de vie : c'est la voie la plus pérenne.

Pour aller plus loin

• Nexus Repository : héberger les archives de policy.
• HashiCorp Vault : le remplaçant de chef-vault, avec rotation.

×

📖 Voir la documentation →