Policy groups : promouvoir une révision de dev vers la production

Les Policyfiles verrouillent une révision reproductible. Les policy groups en font une chaîne de promotion : la révision validée en dev est exactement celle qui part en production, sans reconstruction ni recompilation. Ce module monte cette chaîne sur un serveur, prouve qu'un groupe n'entraîne pas l'autre, et promeut une révision de bout en bout. Public visé : avancés disposant d'un serveur CINC.

Ce que vous allez apprendre

• Pousser une révision de policy dans un groupe.
• Promouvoir la même révision vers un autre groupe.
• Vérifier quel groupe tourne quelle révision.
• Rattacher un nœud à un groupe.

Prérequis

• Un serveur CINC avec un nœud enrôlé.
• Les Policyfiles et le verrouillage des dépendances.

Le problème : « c'est la même chose qu'en dev »

La phrase que tout le monde a prononcée, et que personne ne peut prouver. Entre la validation en recette et le déploiement en production, un cookbook a pu être modifié, une dépendance a pu bouger, une résolution a pu produire un résultat légèrement différent.

Les policy groups suppriment cette incertitude. Une révision de policy est identifiée par une empreinte (revision_id) calculée sur tout son contenu : cookbooks, versions, attributs. Promouvoir consiste à associer cette empreinte à un autre groupe. Rien n'est reconstruit, rien n'est recalculé. Ce qui part en production est bit pour bit ce qui a été validé.

Pousser une première révision

On part d'un Policyfile.rb qui pointe vers le serveur comme source, puis on le verrouille :

Policyfile.rb

name 'web'
default_source :chef_server, 'https://cinc-server.local/organizations/lab'
run_list 'webstack::default'
cookbook 'webstack', path: '../cookbooks/webstack'
default['webstack']['message'] = 'version dev'

chef install

Lockfile written to Policyfile.lock.json
Policy revision id: 1f90927c206911a29b139536a13ef3c8d7438c27845d2fbe82e063537a917a76

Cette empreinte est l'identité de la révision. On la pousse dans le groupe dev :

chef push dev Policyfile.lock.json

Uploading policy web (1f90927c20) to policy group dev
Uploaded webstack 1.0.0 (1d1accdf)

Le groupe n'existe pas à créer : il naît de ce premier push.

Promouvoir, c'est associer, pas reconstruire

Une fois la révision validée en dev, la promotion vers la production consiste à pousser le même fichier de verrouillage dans un autre groupe :

chef push prod Policyfile.lock.json

Uploading policy web (1f90927c20) to policy group prod

Regardez l'empreinte : 1f90927c20, la même. Aucune résolution de dépendances n'a été refaite, aucun cookbook n'a été recompilé. C'est la définition même d'une promotion sûre.

La promotion se fait par le lock, pas par le Policyfile

On ne promeut jamais en relançant chef install sur l'environnement cible : cela recalculerait une révision, potentiellement différente. On promeut le Policyfile.lock.json déjà validé. C'est le fichier de verrouillage qui voyage, pas la recette de fabrication.

Prouver que les groupes sont indépendants

C'est le test qui compte. Faisons évoluer la policy, et vérifions que la production ne bouge pas.

chef install ne recalcule pas une révision existante

Piège classique : après avoir modifié le Policyfile.rb, un chef install réutilise le lock existant et vous repousserez la même révision sans vous en apercevoir. C'est chef update qui re-résout et produit une nouvelle empreinte.

chef update

Policy revision id: 53b0ef64d6e95451c8a94868dbcdd47bbb4e659b8896a737563356978b2fd2d1

Nouvelle empreinte. On la pousse uniquement dans dev :

chef push dev Policyfile.lock.json
chef show-policy

* prod:  1f90927c20
* dev:   53b0ef64d6

Voilà l'image que vous voulez pouvoir produire à tout moment : dev a avancé, prod est resté. chef show-policy répond à la question « qui tourne quoi ? », et c'est précisément ce que le local mode ne saura jamais dire.

Rattacher un nœud à un groupe

Un nœud ne choisit pas sa révision : il choisit son groupe. Cela se déclare dans sa configuration :

# /etc/cinc/client.rb sur le nœud
policy_name  'web'
policy_group 'prod'

À la convergence, le nœud annonce explicitement la révision qu'il applique :

sudo cinc-client

Using Policyfile 'web' at revision '1f90927c206911a29b139536a13ef3c8d7438c27845...'

C'est bien l'ancienne révision, celle de prod, alors que dev en est déjà à une plus récente. Le nœud de production est protégé de ce qui se passe en recette : rien ne peut lui parvenir tant que personne ne l'a décidé.

Promouvoir en production

La décision se prend, et la promotion s'exécute en une commande :

chef push prod Policyfile.lock.json
chef show-policy

* prod:  53b0ef64d6
* dev:   53b0ef64d6

Les deux groupes portent désormais la même révision. À sa prochaine convergence, le nœud de production bascule, sans que personne ne s'y connecte :

Using Policyfile 'web' at revision '53b0ef64d6e95451c8a94868dbcdd47bbb4e659b...'

La boucle est fermée : on construit une fois, on valide en dev, on promeut la même empreinte, et les nœuds suivent leur groupe.

Un rollback est une promotion à l'envers

Comme les révisions restent sur le serveur, revenir en arrière consiste simplement à repousser l'ancienne empreinte dans le groupe. Un rollback n'est pas une reconstruction en urgence, c'est la même opération, dans l'autre sens.

Dépannage

La promotion échoue rarement bruyamment : le plus dangereux est qu'elle semble fonctionner. Voici les symptômes à surveiller.

Symptôme	Cause probable	Solution
La révision poussée est identique après modification	chef install réutilise le lock	Utiliser chef update pour re-résoudre
Le nœud n'applique pas la bonne révision	Il n'est pas dans le bon groupe	Vérifier policy_group dans /etc/cinc/client.rb
La prod a bougé sans qu'on l'ait voulu	Un chef push prod involontaire	La promotion doit être une décision, pas un réflexe
chef show-policy ne montre rien	Aucune policy poussée sur ce serveur	chef push <groupe> Policyfile.lock.json
La prod n'est pas identique à la recette	Reconstruction au lieu de promotion	Promouvoir le lock, jamais relancer chef install

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. Une révision de policy est une empreinte de tout son contenu : cookbooks, versions, attributs.
2. Promouvoir, c'est associer cette empreinte à un autre groupe : rien n'est reconstruit, donc rien ne peut diverger.
3. On promeut le Policyfile.lock.json, jamais en relançant chef install sur la cible.
4. chef update produit une nouvelle révision ; chef install réutilise le lock existant.
5. chef show-policy répond à « qui tourne quoi » : dev peut avancer pendant que prod reste.
6. Un nœud choisit un groupe (policy_group), pas une révision : il suit ensuite les décisions de promotion.
7. Un rollback est une promotion à l'envers : on repousse l'ancienne empreinte.

Pour aller plus loin

• Panorama des outils de gestion de configuration : comparer ce modèle de promotion aux environnements de Salt ou Puppet.

×

📖 Voir la documentation →