Formation Chef avec CINC : du premier cookbook au déploiement

Logo Chef

Chef est un outil de gestion de configuration qui décrit l'état voulu de vos serveurs dans du code Ruby, puis le fait converger de façon idempotente. Cette formation l'aborde par sa distribution 100 % libre CINC, sans aucune licence propriétaire ni compte à créer, avec des labs reproductibles qui tournent en quelques secondes dans des conteneurs. Public visé : sysadmins et DevOps curieux de Chef, débutants acceptés, à l'aise avec la ligne de commande Linux et les conteneurs.

Ce que vous allez apprendre

Installer un poste de travail Chef libre avec CINC Workstation.
Écrire un premier cookbook et le converger dans un conteneur jetable avec Test Kitchen.
Comprendre les briques de base : ressources, recettes, attributs, idempotence.
Structurer, tester et linter un cookbook pour le rendre maintenable.
Déployer sur une vraie VM sans serveur, puis monter jusqu'au serveur CINC quand il se justifie.
Industrialiser : secrets, CI/CD, conformité continue, cookbooks tiers.

Qu'est-ce que Chef, et pourquoi CINC

Chef décrit la configuration comme un état désiré : « ce paquet installé, ce service démarré, ce fichier présent avec ce contenu ». À chaque exécution, Chef compare l'état réel à l'état voulu et n'applique que les écarts. C'est le principe d'idempotence : rejouer le même code deux fois ne change rien la seconde fois.

Contrairement à Ansible qui est sans agent, Chef est agent-based : un client cinc-client s'exécute sur chaque nœud pour appliquer la configuration. Pour apprendre vite, la formation démarre dans un conteneur avec Test Kitchen et son driver dokken : rien à installer sur une cible, un cycle complet en secondes. Mais on ne s'y arrête pas : on passe ensuite sur de vraies VM, puis sur un serveur CINC, comme détaillé plus bas.

Le point qui change tout pour apprendre sereinement : CINC. C'est un rebuild libre et gratuit de Chef, bit pour bit, sans les restrictions de licence de l'édition commerciale. Vous obtenez le même outil, le même langage, le même écosystème, mais 100 % open source. Toute la formation s'appuie sur CINC Workstation et l'image cincproject/cinc.

Trois terrains d'exécution, une montée en puissance

C'est la colonne vertébrale de cette formation, et il vaut mieux la comprendre tout de suite : vous allez travailler sur trois terrains successifs. Ce n'est pas de l'hésitation, c'est une progression. Chaque terrain enseigne quelque chose, puis montre sa limite, et cette limite justifie le suivant.

Terrain	Ce qu'il apporte	Sa limite, qui pousse au suivant
Conteneur Docker (Test Kitchen + dokken)	Un cycle complet en secondes, rien à installer, machine jetable	Pas de vrai `systemd` : un service ne se comporte pas comme en production
Vraie VM sans serveur (knife-zero)	Une machine réaliste, l'agent poussé en SSH, aucun service central à exploiter	Le poste ne sait pas quelles machines existent, ni lesquelles portent tel rôle
Serveur CINC	Inventaire centralisé, recherche sur le parc, secrets par nœud	Un service permanent à installer, patcher et sauvegarder

Le conteneur est le bac à sable de l'apprentissage. Vous écrivez un cookbook, vous le convergez, vous voyez le résultat, le tout en quelques secondes. Mais un conteneur n'a pas de vrai gestionnaire de services : le jour où vous voulez qu'un service démarre vraiment, il faut une machine complète.

La vraie VM avec knife-zero est le mode par défaut de cette formation dès le premier déploiement sérieux. On pousse le cookbook en SSH, l'agent s'installe, la machine converge. C'est proche d'Ansible dans l'usage, et surtout aucun serveur n'est à exploiter. Ce mode vous mène très loin, plus loin que ce que la plupart des gens imaginent : la leçon Chef sans serveur va jusqu'à la convergence planifiée et la correction de dérive automatique, sans jamais installer de service central.

Le serveur CINC ne devient nécessaire que lorsqu'une question sans réponse apparaît : « quelles machines existent ? », « lesquelles portent cette recette ? », « comment révoquer l'accès d'un nœud à un secret sans toucher aux autres ? ». Le local mode ne saura jamais y répondre. Le serveur, oui, et c'est là qu'il justifie son coût d'exploitation.

Le programme en 4 volets

La formation compte 31 leçons réparties en quatre volets, du plus simple au plus exigeant. Le volet 1 (Fondamentaux) installe l'outillage, écrit un premier cookbook dans un conteneur et couvre ressources, recettes, attributs, templates et idempotence, jusqu'au déploiement sur une vraie VM. Le volet 2 (Cookbooks structurés) apprend à organiser un cookbook maintenable. Le volet 3 (Tester) ajoute ChefSpec et InSpec. Le volet 4 (Industrialiser) couvre les Policyfiles, les secrets, la CI/CD, la conformité continue, les cookbooks communautaires et enfin le serveur CINC.

Le mieux est de suivre les leçons dans l'ordre, chacune s'appuyant sur la précédente. Le programme détaillé, avec suivi de progression, se trouve sur la page dédiée.

Mon parcours Chef Le programme complet des 4 volets et 31 leçons, avec suivi de progression à cocher.

Installer CINC Workstation Le poste de travail Chef libre, prêt à écrire et converger des cookbooks.

Votre premier cookbook Terrain 1 : converger un cookbook dans un conteneur Docker jetable, en secondes.

Déployer sur une vraie VM Terrain 2 : pousser le cookbook en SSH avec knife-zero, sans aucun serveur.

Local mode ou serveur ? La question de décision : ce que le serveur apporte, et quand il se justifie.

Installer un serveur CINC Terrain 3 : inventaire centralisé, recherche sur le parc et secrets par nœud.

Chef ou Ansible : lequel apprendre

Les deux résolvent le même problème, avec des philosophies opposées. Ansible est agentless et pilote les machines par SSH avec du YAML : idéal pour l'orchestration et la prise en main rapide. Chef est agent-based et décrit la configuration en Ruby : plus verbeux au départ, mais très puissant pour gérer un parc important avec une logique riche, des ressources personnalisées et des tests systématiques.

Apprendre Chef reste pertinent en 2026 : de nombreuses organisations exploitent un socle Chef existant, et la logique état désiré + idempotence + tests est transférable partout. Un point mérite toutefois d'être connu avant de s'engager : Progress retire le serveur Chef open source fin 2026 au profit d'une plateforme commerciale. Le client et le langage restent Apache 2.0 et bien vivants, et la voie sans serveur défendue ici n'est pas concernée, mais le sujet est traité sans détour dans Quel avenir pour Chef et CINC. Si vous découvrez la gestion de configuration, vous pouvez aussi comparer avec la formation Ansible pour choisir en connaissance de cause.

Mon retour d'expérience, pour ceux qui veulent comprendre

Ce qui suit engage un point de vue. Il vient des labs qui sous-tendent cette formation, où j'ai cassé des machines exprès pour voir ce que Chef en faisait.

Le pari CINC, et pourquoi il tient

Soyons directs sur l'éléphant dans la pièce : Progress retire le serveur Chef open source fin 2026. Beaucoup en concluront que Chef est mort. C'est faux, et la nuance est décisive.

Le client et le langage restent Apache 2.0 et activement maintenus : recettes, cookbooks, attributs, tests, tout ce qui fait Chef continue de vivre. Ce qui se referme, c'est le serveur, c'est-à-dire précisément le composant que cette formation vous conseille de n'adopter que sur besoin avéré. La décision de l'éditeur ne démolit pas notre ligne, elle la valide.

Mieux : j'ai vérifié en lab que la convergence planifiée, la correction de dérive et la promotion en production fonctionnent sans serveur. Une machine que j'ai sabotée volontairement s'est réparée seule en 112 secondes, alors qu'aucun serveur n'existait. La voie sans serveur n'est donc pas un repli : c'est la voie pérenne, et elle est détaillée de bout en bout dans Chef sans serveur.

Ce que cette formation défend

Le second passage est non négociable. Une convergence qui « a marché » ne prouve rien. Rejouez-la : si elle change encore quelque chose, votre cookbook a une dérive, et vous ne le sauriez pas.
Un conteneur ne valide pas un service. Je l'ai vu de mes yeux : kitchen verify échoue sur le service, parce qu'un conteneur n'a pas d'init. Un cookbook « vert » en conteneur peut échouer en production sur la seule chose qui compte. Validez les services sur une VM.
Ne montez pas un serveur « au cas où ». C'est un service à installer, patcher, sauvegarder et superviser. Montez-le le jour où une question sans réponse apparaît (« quelles machines existent ? »), pas avant.
Le nom du paquet est une donnée, pas du code. package 'apache2' marche chez Debian et explose chez Red Hat. Le jour où quelqu'un déploie sur Rocky, il cherchera le bug partout sauf au bon endroit.

Ce que je vous déconseille

Croire une convergence sans la vérifier. Chef vous dit ce qu'il a fait, pas ce que la machine est devenue. Ce sont deux questions différentes, et seule la seconde compte en production.
Se fier à why-run comme à une preuve. Il sous-estime : sur une recette testée en lab, il annonçait deux ressources dont une ignorée, la convergence réelle en a modifié deux sur deux. C'est un indicateur, pas un filet.
Tout réécrire en Policyfiles dès la première semaine sur un parc hérité. Vous casseriez ce qui marche sans le comprendre. Migrez parce que quelque chose vous fait mal, pas par principe.
Coder un secret en dur, même « temporairement ». Il partira dans Git, et il y restera bien après que vous l'ayez oublié.

FAQ : questions fréquentes sur Chef

Qu'est-ce qu'un cookbook Chef ?

Un cookbook est l'unité de travail de Chef : un dossier qui regroupe tout ce qui décrit un service. Il contient des recettes (le code qui déclare l'état voulu), des attributs (les valeurs paramétrables), des templates (les fichiers de configuration) et des tests.

Chef est-il gratuit ?

Le code source de Chef Infra est libre (Apache 2.0), mais les binaires distribués par Progress sont soumis à une licence commerciale depuis Chef 15. La distribution CINC reconstruit ces binaires depuis le même code source, sans licence commerciale : c'est gratuit et libre.

Qu'est-ce que Chef en gestion de configuration ?

Chef est un outil de gestion de configuration qui décrit l'état voulu des serveurs en code Ruby, puis le fait converger de façon idempotente. Un agent, le client Chef, s'exécute sur chaque machine, compare l'état réel à l'état décrit et n'applique que les écarts.

Quelle différence entre Chef et CINC ?

CINC est une reconstruction communautaire de Chef à partir du même code source Apache 2.0, sans licence commerciale. Depuis Chef 15, les binaires de l'éditeur sont soumis à un EULA alors que le code reste libre. CINC fournit les mêmes commandes, sans cette restriction.

Chef est-il mort après le retrait du serveur open source ?

Non. Progress retire le Chef Infra Server open source (fin de vie en novembre 2026) au profit de Chef 360, mais le Chef Infra Client et InSpec restent open source sous Apache 2.0 et activement maintenus. Le langage et le moteur ne sont pas concernés, et CINC forke le serveur pour le maintenir.

Faut-il un serveur Chef pour commencer ?

Non, la plupart du temps. Chef converge une machine sans aucune infrastructure centrale grâce au local mode, et knife-zero pousse les cookbooks en SSH sur des machines distantes. Le serveur ne devient utile qu'à partir d'un besoin précis : inventaire du parc, recherche, ou secrets chiffrés par nœud.

Quelle différence entre ChefSpec et InSpec ?

ChefSpec est un test unitaire : il vérifie en mémoire, sans machine, que la recette déclare bien les bonnes ressources. InSpec est un test d'intégration : il vérifie sur la vraie machine convergée que l'état attendu est réellement atteint. Les deux sont complémentaires.

Chef ou Ansible : lequel choisir ?

Ansible est agentless, pilote par SSH en YAML et s'apprend plus vite : c'est le bon choix par défaut. Chef est agent-based et décrit la configuration en Ruby, ce qui donne une logique plus riche et un modèle de tests très mature. Chef s'impose surtout sur un parc existant.

À retenir

Chef décrit un état désiré en Ruby et le fait converger de façon idempotente.
CINC est le rebuild 100 % libre de Chef : même outil, sans licence propriétaire.
La formation traverse trois terrains : le conteneur (rapide, mais sans vrai systemd), la vraie VM en knife-zero (réaliste, sans serveur), et le serveur CINC (inventaire, recherche, secrets par nœud).
Chaque terrain se justifie par la limite du précédent : ne montez d'un cran que lorsqu'une limite vous gêne réellement.
Le parcours va du premier cookbook à l'industrialisation : tests, secrets, CI/CD et conformité continue.
Pas besoin de maîtriser Ruby pour commencer : on apprend le sens du code avant le langage.