Policyfiles Chef : verrouiller et déployer un cookbook

Un cookbook qui converge chez vous mais pas en production, c'est presque toujours une histoire de versions non figées. Les Policyfiles sont la réponse moderne de Chef : un seul fichier décrit le run-list et les sources, chef install verrouille les versions exactes de tous les cookbooks dans un Policyfile.lock.json, et vous déployez ce verrou à l'identique partout. Ce guide montre l'anatomie d'un Policyfile, la génération du verrou et le déploiement sur une vraie VM sans serveur Chef. Public visé : lecteur ayant écrit et structuré un cookbook. Testé avec CINC Workstation 26.1.0 et une VM Debian 13.

Ce que vous allez apprendre

• Comprendre ce que les Policyfiles remplacent (roles, environments, Berkshelf).
• Lire l'anatomie d'un Policyfile.rb.
• Verrouiller les versions avec chef install.
• Déployer une policy en chef-zero, puis vérifier son idempotence.

Prérequis

• Votre premier cookbook réussi.
• Savoir structurer un cookbook.
• Une VM joignable en SSH avec l'agent CINC, comme dans Déployer sur une VM avec knife-zero.

Le problème que les Policyfiles règlent

L'ancien modèle Chef éparpillait la configuration dans trois mécanismes distincts : les roles (regrouper des run-lists), les environments (contraindre les versions par environnement) et Berkshelf (résoudre les dépendances). Résultat : la version de cookbook réellement appliquée dépendait de la combinaison de ces trois sources, difficile à reproduire et à auditer.

Les Policyfiles fusionnent tout cela dans un seul artefact versionné. Un Policyfile.rb décrit l'intention ; chef install la fige dans un Policyfile.lock.json qui épingle chaque cookbook à un identifiant précis. Ce verrou est ce que vous déployez, à l'octet près, du poste au serveur de prod.

	Ancien modèle	Policyfiles
Run-list	roles	run_list du Policyfile
Contrainte de versions	environments	Policyfile.lock.json
Résolution de dépendances	Berkshelf	chef install
Reproductibilité	Trois sources à croiser	Un seul verrou

Glissez pour voir

Anatomie d'un Policyfile.rb

Le Policyfile.rb tient en quelques lignes. Il nomme la policy, déclare où trouver les cookbooks, fixe le run-list, et peut pointer un cookbook vers une source locale en cours de développement.

Policyfile.rb

name 'monparc'

# Où chercher les cookbooks externes :
default_source :supermarket

# run_list : les recettes appliquées, dans l'ordre.
run_list 'monparc::default'

# Source personnalisée pour un cookbook précis (ici, le dépôt courant) :
cookbook 'monparc', path: '.'

default_source :supermarket va chercher les dépendances sur le Supermarket public ; cookbook 'monparc', path: '.' dit d'utiliser le code local pour le cookbook en cours, pratique tant qu'il n'est pas publié.

Verrouiller les versions avec chef install

C'est l'étape clé. chef install résout toutes les dépendances déclarées et écrit un Policyfile.lock.json qui fige l'ensemble.

chef install

Building policy monparc
Expanded run list: recipe[monparc::default]
Caching Cookbooks...
Installing monparc 0.1.0
Lockfile written to Policyfile.lock.json
Policy revision id: 77bac843ae84248f...

Le verrou n'est pas un simple numéro de version : il contient un identifiant de contenu par cookbook et un revision_id global. Deux chef install du même code produisent le même verrou ; le moindre changement de cookbook change l'identifiant. C'est ce qui rend un déploiement reproductible et auditable.

{
  "revision_id": "77bac843ae84248f...",
  "name": "monparc",
  "run_list": ["recipe[monparc::default]"],
  "cookbook_locks": {
    "monparc": {
      "version": "0.1.0",
      "identifier": "0ce567644532..."
    }
  }
}

Versionnez le lock, pas seulement le Policyfile

Committez Policyfile.lock.json dans Git au même titre que le code. C'est lui, pas le Policyfile.rb, qui garantit qu'un collègue ou un serveur de CI déploie exactement les mêmes versions que vous. Le .rb décrit l'intention, le .lock.json la fige.

Déployer la policy en chef-zero

Pour appliquer un Policyfile sans serveur Chef, on l'exporte en un bundle autonome, puis on le converge sur la cible avec cinc-client -z (le mode local, un serveur Chef éphémère en mémoire). C'est le pendant Policyfile du push knife-zero.

1. Exporter le bundle depuis le dépôt du cookbook :

   chef export /tmp/monparc-export

   To converge this system with the exported policy, run:
     cd /tmp/monparc-export
     cinc-client -z

   Le dossier produit contient les cookbooks verrouillés (cookbook_artifacts/), la policy et son groupe : il est auto-portant, plus besoin du dépôt d'origine.

2. Transférer le bundle sur la VM, puis converger en mode local :

   scp -r /tmp/monparc-export ubuntu@192.168.122.167:/tmp/
   ssh ubuntu@192.168.122.167 'cd /tmp/monparc-export && sudo cinc-client -z'

La convergence applique le run-list de la policy. Ici, le cookbook déploie nginx et deux sites :

Converging 4 resources
  * apt_package[nginx] action install (up to date)
  * monparc_site_web[blog] action create
    * template[/etc/nginx/conf.d/blog.conf] action create
  * monparc_site_web[docs] action create
    * template[/etc/nginx/conf.d/docs.conf] action create
  * service[nginx] action start (up to date)
Infra Phase complete, 8/11 resources updated in 00 seconds

Prouver l'idempotence

Un déploiement correct ne change rien s'il est rejoué sur un système déjà conforme. On relance la même convergence :

ssh ubuntu@192.168.122.167 'cd /tmp/monparc-export && sudo cinc-client -z'

Infra Phase complete, 0/11 resources updated in 00 seconds

8/11 au premier passage, 0/11 au second : la policy est idempotente. La preuve côté machine confirme que les sites répondent :

ssh ubuntu@192.168.122.167 'curl -s localhost:8080'

webstack

chef-zero, pas un serveur permanent

cinc-client -z démarre un chef-zero : un serveur Chef en mémoire, le temps de la convergence, puis il disparaît. Vous obtenez la puissance du modèle Policyfile (verrou, artefacts) sans exploiter de serveur Chef permanent. Pour un vrai parc, un serveur CINC apporte l'inventaire centralisé et la distribution des policies, mais il n'est pas nécessaire pour déployer une policy.

Promouvoir une policy entre environnements

Le même verrou se déploie dans plusieurs policy groups (dev, staging, production) sans réinstaller les cookbooks. On promeut une revision testée en dev vers production en la poussant dans le groupe cible : c'est exactement la revision validée qui avance, pas une nouvelle résolution de versions. Ce mécanisme de promotion entre groupes complète le cycle de vie d'une policy.

Dépannage

Symptôme	Cause probable	Solution
chef install échoue sur une dépendance	Cookbook absent du Supermarket ou mauvaise contrainte	Vérifier default_source et les depends du metadata.rb
La VM converge une ancienne version	Bundle exporté périmé	Refaire chef install puis chef export -f
cinc-client -z ne trouve pas la policy	Lancé hors du dossier exporté	cd dans le bundle avant de converger

Glissez pour voir

À retenir

• Les Policyfiles remplacent roles + environments + Berkshelf par un seul artefact versionné.
• chef install fige les versions dans un Policyfile.lock.json à committer dans Git.
• Le verrou porte un identifiant de contenu par cookbook : deux installs du même code donnent le même verrou.
• chef export produit un bundle autonome, convergé par cinc-client -z (chef-zero, sans serveur permanent).
• 8/11 puis 0/11 : la policy est idempotente, la preuve d'un déploiement fiable.

×

📖 Voir la documentation →