CI/CD des cookbooks Chef : lint, tests et pipeline durci

Sur votre poste, vous pensez à lancer Cookstyle et ChefSpec. En équipe, un jour, quelqu'un oubliera, et le cookbook fautif partira en production. Ce module transforme ces contrôles en barrière automatique : un pipeline GitHub Actions qui lint et teste chaque modification, et bloque la fusion en cas d'échec. Vous durcirez aussi le pipeline lui-même, car un workflow mal écrit est une porte d'entrée dans votre chaîne de livraison. Public visé : intermédiaires ayant pratiqué Cookstyle et ChefSpec.

Ce que vous allez apprendre

• Faire tourner Cookstyle et ChefSpec en intégration continue.
• Bloquer la fusion quand un contrôle échoue.
• Durcir le pipeline lui-même.
• Situer les tests d'intégration dans la chaîne.

Prérequis

• Un cookbook avec ses tests (Cookstyle et ChefSpec).
• Des notions de GitHub Actions.

Ce qu'un pipeline doit attraper

Un contrôle automatique n'a d'intérêt que s'il échoue quand il le doit. Vérifions d'abord que nos deux outils bloquent vraiment.

Cookstyle ne se contente pas de compter les espaces : il détecte aussi les dépréciations. Sur un cookbook non nettoyé, il sort avec un code d'erreur :

cookstyle .
echo "code de sortie : $?"

10 files inspected, 34 offenses detected, 34 offenses autocorrectable
code de sortie : 1

Parmi ces remontées, une vraie faute de fond :

spec/spec_helper.rb:7:1: W: Chef/Deprecations/ChefSpecCoverageReport:
Don't use the deprecated ChefSpec coverage report functionality in your specs.

C'est exactement ce qu'on attend d'une CI : elle attrape ce que l'oeil laisse passer. La correction automatique règle le gros du lot :

cookstyle -a .
cookstyle .

10 files inspected, 35 offenses detected, 35 offenses corrected
10 files inspected, no offenses detected

Code 0 : le pipeline peut passer au vert. ChefSpec, lui, valide la logique des recettes en une fraction de seconde, sans machine :

webstack::install
  met a jour le cache apt
  installe le paquet nginx

Finished in 0.12 seconds
8 examples, 0 failures

Le pipeline

Le workflow tient en deux jobs indépendants : le lint et les tests unitaires. Tous deux tournent dans l'image CINC Workstation, qui embarque déjà cookstyle et chef exec rspec : rien à installer, et l'environnement de CI est identique à celui du poste.

.github/workflows/cookbook.yml

name: Cookbook

on:
  push:
    branches: [main]
  pull_request:

permissions: {}

jobs:
  lint:
    name: Cookstyle
    runs-on: ubuntu-latest
    container:
      image: cincproject/workstation@sha256:aefb66a55c5651ae8e1aae4ed21c8c8416a880d0b2e8d9b0deb5695d0bd0f6ad
    steps:
      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
        with:
          persist-credentials: false
      - name: Analyser le style et les depreciations
        run: cookstyle .

  unit:
    name: ChefSpec
    runs-on: ubuntu-latest
    container:
      image: cincproject/workstation@sha256:aefb66a55c5651ae8e1aae4ed21c8c8416a880d0b2e8d9b0deb5695d0bd0f6ad
    steps:
      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
        with:
          persist-credentials: false
      - name: Tests unitaires des recettes
        run: chef exec rspec --format documentation

Chaque outil sortant en code non nul quand il échoue, aucune configuration supplémentaire n'est nécessaire : GitHub marque le job en rouge, et la règle de protection de branche empêche alors la fusion. La barrière est là.

Durcir le pipeline lui-même

Un pipeline exécute du code avec des droits sur votre dépôt. C'est une cible. Quatre décisions, visibles dans le workflow ci-dessus, le rendent difficile à détourner.

permissions: {} retire tous les droits par défaut du jeton, et on ne réaccorde ensuite que le strict nécessaire. Un workflow compromis ne peut alors rien écrire.

Les actions sont épinglées par SHA de commit, pas par tag. Un tag comme v7 peut être redéplacé par son auteur ou un attaquant : le SHA, lui, désigne un contenu immuable. Le commentaire # v7.0.0 garde la lisibilité.

persist-credentials: false empêche checkout de laisser le jeton Git sur le disque du runner, où une dépendance malveillante pourrait le récupérer.

L'image du conteneur est épinglée par digest (@sha256:...), et non par latest. Une image latest peut changer sous vos pieds : le digest garantit que la CI d'aujourd'hui exécute exactement ce qu'elle exécutait hier.

Un tag n'est pas une version

C'est le piège le plus répandu. actions/checkout@v7 et cincproject/workstation:latest ne désignent pas un contenu fixe : ce sont des étiquettes mobiles. Le jour où elles pointent ailleurs, votre pipeline exécute du code que vous n'avez jamais relu. Épinglez le SHA et le digest.

Vérifier son pipeline avec des scanners

On ne se relit pas soi-même. Quatre outils analysent un workflow et trouvent ce qu'on ne voit plus. Ils sont complémentaires : chacun attrape ce que les autres laissent passer.

Outil	Ce qu'il vérifie
actionlint	La syntaxe du workflow et des expressions
zizmor	Les failles de sécurité GitHub Actions (injections, droits)
poutine	Les risques de chaîne de livraison (exécution non fiable, secrets)
plumber	La confiance dans les composants tiers : actions et images

Glissez pour voir

actionlint .github/workflows/cookbook.yml
zizmor .github/workflows/cookbook.yml
poutine analyze_local .
plumber analyze

Sur le workflow ci-dessus, les quatre passent, et plumber résume la posture :

Plumber Score : 100 / 100 pts
Critical 0   High 0   Medium 0   Low 0

Ne vous fiez pas à un seul scanner

Chacun a ses angles morts. Sur un pipeline précédent, seul plumber avait vu qu'une image de conteneur n'était pas épinglée par digest : zizmor et poutine étaient passés à côté. Faites tourner les quatre, c'est quelques secondes.

Et les tests d'intégration ?

Il manque une marche, et il faut être honnête sur ce point. ChefSpec valide ce que la recette déclare ; il ne prouve pas que la machine finit dans le bon état. Cette preuve, c'est le rôle d'InSpec, et elle exige une vraie machine convergée.

Deux stratégies s'offrent à vous, selon vos moyens.

La CI peut monter elle-même une machine jetable (Test Kitchen), converger, puis lancer InSpec. C'est la boucle la plus complète, mais elle est lente (des minutes) et suppose un runner capable de lancer des conteneurs ou des VM. On la réserve souvent à une exécution nocturne, pas à chaque commit.

Plus simplement, InSpec s'exécute après le déploiement, contre la machine réellement convergée. Le pipeline valide alors la cohérence du cookbook (rapide, à chaque commit), et le déploiement valide le résultat (une fois, sur la vraie cible).

Retenez la répartition : Cookstyle et ChefSpec en CI, à chaque changement ; InSpec après convergence, là où l'état réel existe.

Dépannage

Un pipeline qui échoue vous apprend quelque chose ; encore faut-il traduire le message. Les cas les plus fréquents :

Symptôme	Cause probable	Solution
La CI est verte mais le cookbook casse en prod	Seul ChefSpec tourne, il ne teste pas l'état réel	Ajouter InSpec après la convergence
cookstyle échoue sur des broutilles de style	Comportement attendu	cookstyle -a corrige automatiquement
Chef/Deprecations/... en CI	Le cookbook utilise une fonctionnalité dépréciée	La retirer : elle disparaîtra dans une version future
Le job ne trouve pas chef ou cookstyle	L'image du conteneur n'est pas CINC Workstation	Vérifier l'image: du job
La CI passe soudain au rouge sans changement du code	Une action ou une image non épinglée a bougé	Épingler par SHA et digest

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. Un contrôle n'est une barrière que s'il échoue : cookstyle sort en code 1, ce qui bloque le job.
2. Cookstyle attrape aussi les dépréciations, pas seulement le style.
3. L'image CINC Workstation donne en CI le même environnement que sur le poste, sans rien installer.
4. permissions: {}, actions épinglées par SHA, persist-credentials: false et image par digest : quatre décisions qui durcissent le pipeline.
5. Un tag (v7, latest) n'est pas une version : il peut être redéplacé.
6. Faites tourner actionlint, zizmor, poutine et plumber : chacun voit ce que les autres ratent.
7. ChefSpec en CI, InSpec après convergence : ils ne répondent pas à la même question.

Pour aller plus loin

• Sécuriser ses workflows GitHub Actions : le durcissement des pipelines au-delà de Chef.

×

📖 Voir la documentation →