Survivre dans un parc Chef legacy : roles, environments, Berkshelf

Vous n'apprendrez pas Chef pour démarrer un projet neuf : dans neuf cas sur dix, vous héritez d'un parc existant. Et ce parc n'est pas écrit avec des Policyfiles : il utilise des roles, des environments et Berkshelf, trois mécanismes que les tutoriels modernes ne mentionnent même plus. Ce module vous apprend à les lire, à éviter leurs pièges (dont celui qui fait perdre une après-midi à tout le monde), et à décider s'il faut migrer ou cohabiter. Public visé : intermédiaires qui reprennent un dépôt Chef existant.

Ce que vous allez apprendre

• Lire un role et un environment.
• Comprendre pourquoi une nouvelle version ne part pas.
• Situer Berkshelf face aux Policyfiles.
• Choisir entre migrer et cohabiter.

Ce que vous allez trouver dans le dépôt

Avant les Policyfiles, Chef répartissait la configuration entre trois mécanismes, et un dépôt historique les mélange tous.

Mécanisme	Ce qu'il porte	Son remplaçant moderne
role	Un run-list et des attributs, par fonction de machine	Le run_list du Policyfile
environment	Des contraintes de version de cookbooks, par étape	Le policy group
Berkshelf	La résolution des dépendances de cookbooks	chef install et le lock

Glissez pour voir

Tout ce que faisaient ces trois mécanismes, le Policyfile le fait aujourd'hui seul, dans un fichier et un verrou. Mais tant que le parc n'est pas migré, il faut savoir les lire.

Le role : un run-list nommé

Un role décrit une fonction de machine : « un serveur web, c'est ce run-list et ces attributs ». Il vit dans un JSON.

{
  "name": "web",
  "chef_type": "role",
  "run_list": ["recipe[webstack::default]"],
  "default_attributes": {
    "webstack": { "message": "posé par le rôle web" }
  }
}

On le publie, puis on l'assigne à un nœud :

knife role from file roles/web.json
knife node run_list set db-srv1 'role[web]'

Le nœud ne porte alors plus une recette, mais un rôle :

Run List:    role[web]

À la convergence, Chef déplie le rôle. Regardez la première ligne, c'est elle qui explique tout :

Resolving cookbooks for run list: ["webstack::default"]

Le role[web] a disparu : il s'est transformé en la recette qu'il contenait. Un rôle n'est donc rien d'autre qu'un alias vers un run-list, plus des attributs.

Un rôle peut en contenir un autre

Dans un vrai dépôt, vous trouverez des rôles qui incluent d'autres rôles (run_list: ["role[base]", "recipe[nginx]"]). Chef les déplie récursivement. C'est pratique, et c'est aussi la raison pour laquelle il devient vite impossible de savoir ce qu'une machine exécute sans dérouler l'arbre à la main.

C'est précisément ce que les Policyfiles ont voulu supprimer : un fichier, un run-list explicite, un verrou.

L'environment : le piège qui coûte une après-midi

Un environment porte les contraintes de version des cookbooks pour une étape donnée (recette, production).

{
  "name": "production",
  "chef_type": "environment",
  "cookbook_versions": {
    "webstack": "= 1.0.0"
  }
}

Voici maintenant le scénario qui piège tout le monde. Vous corrigez un cookbook, vous le publiez, vous convergez... et rien ne change.

knife cookbook upload webstack
knife cookbook list

webstack:      1.1.0

Le serveur a bien la 1.1.0. Pourtant, sur le nœud :

Synchronizing cookbooks:
  - webstack (1.0.0)

Il continue d'appliquer la 1.0.0. Aucune erreur, aucun avertissement. Vous allez relire votre cookbook, vider des caches, douter de votre santé mentale.

La coupable est l'environment, qui épingle la version en silence :

knife environment show production

cookbook_versions:
  webstack: = 1.0.0

Une contrainte d'environment est un verrou silencieux

C'est le piège du modèle historique. knife cookbook upload réussit, la nouvelle version est bel et bien sur le serveur, mais aucun nœud ne la recevra tant que l'environment l'interdit. Et rien ne vous le dit.

Le réflexe à acquérir : devant un « j'ai publié et il ne se passe rien », regardez l'environment du nœud avant tout le reste.

La sortie de secours consiste à desserrer la contrainte :

"cookbook_versions": { "webstack": "~> 1.1" }

knife environment from file environments/production.json

À la convergence suivante, le nœud reçoit enfin la nouvelle version :

Synchronizing cookbooks:
  - webstack (1.1.0)

Notez le glissement de responsabilité : dans le modèle historique, c'est l'environment qui décide de ce qui part en production. Avec un policy group, c'est une révision entière que l'on promeut, cookbooks compris. Le second est bien plus lisible.

Berkshelf : l'ancêtre du lock

Berkshelf résolvait les dépendances de cookbooks avant que chef install ne le fasse. Vous le reconnaîtrez à son Berksfile :

source 'https://supermarket.chef.io'

cookbook 'logrotate', '= 3.0.30'

berks install

Resolving cookbook dependencies...
Fetching cookbook index from https://supermarket.chef.io...
Installing logrotate (3.0.30)

Il produit un Berksfile.lock, dont la parenté avec le Policyfile.lock.json saute aux yeux :

DEPENDENCIES
  logrotate (= 3.0.30)

GRAPH
  logrotate (3.0.30)

Même idée (résoudre puis verrouiller), même bénéfice. La différence est que le Policyfile verrouille tout en une fois (cookbooks et run-list et attributs) et produit une révision identifiable, là où Berkshelf ne verrouillait que les cookbooks.

Berkshelf fonctionne encore

Ne vous précipitez pas pour le retirer. Berkshelf est toujours livré avec CINC Workstation et fonctionne. Un dépôt qui l'utilise n'est pas cassé : il est simplement d'une autre génération. Vous pouvez le laisser vivre le temps de migrer sereinement.

Migrer, ou cohabiter ?

La tentation du nouveau venu est de tout réécrire en Policyfiles dès la première semaine. C'est presque toujours une mauvaise idée : vous casseriez un parc qui marche, sans bien le comprendre.

La question à trancher est simple : qu'est-ce qui vous fait mal aujourd'hui ?

Si vous ne savez plus ce qu'une machine exécute (arbre de rôles imbriqués), ou si vous vous êtes déjà fait avoir par une contrainte d'environment silencieuse, la migration vers les Policyfiles vous rendra la vie meilleure. C'est exactement ce qu'ils sont venus corriger.

Si le parc tourne et que personne ne s'en plaint, la migration peut attendre. Elle se fait d'ailleurs progressivement : un Policyfile peut coexister avec des nœuds encore pilotés par des rôles, puisque le choix se fait nœud par nœud.

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

Une bonne surprise, et un piège si vous l'ignorez : dès qu'un nœud est rattaché à un policy group, son run-list (et donc ses rôles) est entièrement ignoré. La migration est donc franche : un nœud est soit dans l'ancien modèle, soit dans le nouveau, jamais entre les deux.

C'est une bonne nouvelle pour migrer sans casse, mais cela explique aussi pourquoi un knife node run_list add peut sembler sans effet sur un nœud déjà migré.

Dépannage

Les symptômes du modèle historique sont déroutants parce qu'ils sont silencieux.

Symptôme	Cause probable	Solution
J'ai publié un cookbook, rien ne change	L'environment épingle l'ancienne version	knife environment show <env> avant tout
Impossible de savoir ce qu'une machine exécute	Des rôles imbriqués	Dérouler l'arbre, ou migrer vers un Policyfile
knife node run_list add sans effet	Le nœud est en policy group	Passer par le Policyfile.rb
Un attribut ne vaut pas ce qu'on croit	Un rôle le pose aussi	Chercher dans le rôle et dans le cookbook
berks introuvable	Il est pourtant livré avec CINC Workstation	Vérifier le PATH de l'outillage

Glissez pour voir

À retenir

1. Un parc Chef existant utilise roles, environments et Berkshelf : trois mécanismes que le Policyfile remplace à lui seul.
2. Un role est un alias vers un run-list : Chef le déplie à la convergence (role[web] devient webstack::default).
3. Les rôles imbriqués rendent vite impossible de savoir ce qu'une machine exécute.
4. Une contrainte d'environment est un verrou silencieux : le cookbook est publié, mais aucun nœud ne le reçoit. C'est le piège numéro un.
5. Devant un « j'ai publié et rien ne change », regardez l'environment en premier.
6. Berkshelf est l'ancêtre du lock, il fonctionne toujours : rien ne presse.
7. Migrez parce que quelque chose vous fait mal, pas par principe. Un nœud en policy group ignore ses rôles : la bascule est franche, nœud par nœud.

Pour aller plus loin

• Panorama des outils de gestion de configuration : comment les autres outils ont traité la même dette.

×

📖 Voir la documentation →