Chef en local mode ou avec un serveur ?

Faut-il un serveur Chef ? La plupart du temps, non. Chef sait converger une machine sans aucune infrastructure centrale grâce au local mode (chef-zero) : un serveur Chef éphémère, en mémoire, le temps d'une exécution. Un serveur permanent n'apporte de la valeur qu'à partir d'une certaine échelle : inventaire centralisé, recherche sur le parc, promotion de policies, RBAC. Ce guide vous aide à choisir entre les deux et à savoir quand migrer. Public visé : lecteur qui a déjà convergé un cookbook et se demande comment structurer son parc.

Ce que vous allez apprendre

• Comprendre le local mode (chef-zero) et comment il fonctionne.
• Situer ce qu'un serveur Chef ajoute réellement.
• Choisir selon la taille du parc et l'équipe.
• Anticiper une migration du local mode vers un serveur.

Recommandation rapide

Avant les détails, la réponse dans la plupart des cas :

Votre situation	Architecture conseillée
Homelab, quelques machines, workflow Git	Local mode (chef-zero / knife-zero)
CI/CD qui converge des images ou des VM	Local mode
Dizaines de serveurs, une équipe outillée Git	Local mode, souvent suffisant
Centaines de nœuds, plusieurs équipes	Serveur (inventaire, RBAC, reporting)
Besoin de recherche sur le parc, conformité centralisée	Serveur

Glissez pour voir

En clair : commencez en local mode, passez au serveur seulement quand un besoin précis l'exige. On ne monte pas un serveur « au cas où ».

Le local mode : chef-zero

Le local mode démarre un chef-zero : un serveur Chef complet mais en mémoire, lancé le temps de la convergence, puis détruit. L'agent applique le run-list ou la policy en parlant à ce serveur temporaire, sans aucun service permanent à exploiter.

cinc-client -z -o 'recipe[webserver]'

Infra Phase starting
Converging 2 resources
Infra Phase complete, 0/2 resources updated in 00 seconds

Toutes les données vivent dans votre dépôt : cookbooks, policies, et le dossier nodes/ où chaque machine gérée est enregistrée. C'est un modèle proche du GitOps : votre Git est la source de vérité, versionnée et auditable.

Pour piloter des machines distantes sans serveur, on utilise knife-zero, qui pousse la convergence en SSH (bootstrap puis converge). C'est le mode par défaut de cette formation, détaillé dans Déployer sur une VM avec knife-zero. Combiné aux Policyfiles, il donne une chaîne reproductible et sans serveur.

Local mode ne veut pas dire « local à la machine »

Le nom prête à confusion : « local mode » désigne le serveur Chef éphémère local au run, pas le fait de ne gérer que la machine courante. Avec knife-zero, vous pilotez des dizaines de serveurs distants en SSH, toujours sans serveur permanent.

Ce qu'un serveur Chef ajoute

Un serveur Chef/CINC est un service permanent auquel les nœuds se connectent. Le modèle bascule du push (vous poussez en SSH) vers le pull : l'agent tourne sur une planification et récupère tout seul sa policy depuis le serveur. Ce que cela apporte :

• Inventaire centralisé : le serveur connaît tous les nœuds, leur dernière convergence, leurs attributs. Pas besoin de parcourir un dossier nodes/.
• Recherche sur le parc : knife search 'role:web' interroge la flotte entière, impossible en local mode.
• Data bags servis centralement et policies partagées entre équipes.
• Promotion de policies : les policy groups (dev, staging, prod) et les commandes chef push / chef show-policy tracent quelle révision tourne dans quel environnement.
• RBAC : utilisateurs, organisations et permissions, pour cadrer qui déploie quoi.
• Reporting : couplé à Chef Automate, tableaux de bord de conformité et historique.
• Échelle : conçu pour des milliers de nœuds en convergence planifiée.

Un serveur, c'est de l'exploitation en plus

Le serveur n'est pas gratuit en effort : c'est un service à installer, patcher, sécuriser, sauvegarder et superviser, avec sa propre base de données. Sur un petit parc, ce coût dépasse le bénéfice. Ne l'adoptez que quand l'inventaire, la recherche ou le RBAC deviennent un vrai manque.

Push ou pull : deux philosophies

La différence de fond n'est pas seulement « avec ou sans serveur », c'est le sens du flux :

	Local mode (push)	Serveur (pull)
Déclencheur	Vous lancez la convergence	L'agent tourne sur planification
Source de vérité	Votre dépôt Git	Le serveur Chef
Inventaire du parc	Dossier nodes/ local	Base centralisée, recherchable
Coût d'exploitation	Nul (aucun service)	Un service à maintenir
Convient à	Petits parcs, CI, GitOps	Grands parcs, équipes, conformité

Glissez pour voir

Aucun n'est « meilleur » dans l'absolu : le push (local mode) donne un contrôle explicite et zéro infrastructure ; le pull (serveur) donne l'autonomie des nœuds et la visibilité centrale, au prix d'un service à exploiter.

Migrer du local mode vers un serveur

La bonne nouvelle : vos cookbooks et policies ne changent pas. Le code d'automatisation est identique dans les deux modes. Migrer consiste à ajouter le serveur et à enregistrer les nœuds dessus, puis à basculer la convergence du push SSH vers le pull planifié. Vous capitalisez tout le travail fait en local mode.

Le bon déclencheur de migration n'est pas la taille brute, mais un besoin fonctionnel : « je ne sais plus quelles machines existent » (inventaire), « je dois trouver tous les serveurs web » (recherche), « plusieurs équipes déploient et se marchent dessus » (RBAC), « l'audit veut un rapport de conformité » (reporting). Tant que ces besoins n'apparaissent pas, le local mode reste le bon choix.

À retenir

• Le local mode (chef-zero) est un serveur Chef éphémère en mémoire : convergence sans infrastructure permanente.
• knife-zero pilote des machines distantes en SSH, toujours sans serveur, à la manière d'un flux GitOps.
• Un serveur Chef apporte inventaire, recherche, promotion de policies, RBAC et reporting, en mode pull planifié.
• Le serveur est un service à exploiter : ne l'adoptez que pour un besoin précis, pas par défaut.
• La migration ne touche pas au code : mêmes cookbooks et policies, on ajoute le serveur et on enregistre les nœuds.

×

📖 Voir la documentation →