Test Kitchen : boucler avec verify, et ce que le conteneur ne peut pas prouver

Depuis votre premier cookbook, le fichier kitchen.yml contient une ligne verifier: inspec... que vous n'avez jamais utilisée. Vous avez convergé sans jamais vérifier ce que la machine est réellement devenue. Ce module ferme la boucle avec kitchen verify et kitchen test. Il vous réserve surtout une surprise instructive : le conteneur va échouer sur un contrôle, et cet échec est la meilleure démonstration de la limite du terrain 1. Public visé : débutants ayant convergé leur premier cookbook.

Ce que vous allez apprendre

• Lancer kitchen verify sur un cookbook convergé.
• Enchaîner le cycle complet avec kitchen test.
• Comprendre ce qu'un conteneur ne peut pas valider.
• Répartir les tests entre conteneur et VM.

Prérequis

• Le cookbook de votre premier cookbook, convergé avec dokken.
• Les bases d'InSpec.

Converger n'est pas vérifier

kitchen converge applique le cookbook, et vous affiche une conclusion rassurante : « 3/4 resources updated ». Mais cette phrase ne dit qu'une seule chose : Chef a exécuté ce qu'il avait à faire. Elle ne dit rien de l'état réel de la machine ensuite.

C'est le rôle de kitchen verify : il lance les tests InSpec du cookbook contre la machine convergée, et vous répond sur ce qu'elle est, pas sur ce que Chef a cru faire.

Le générateur a d'ailleurs créé un fichier de test, mais il est inerte : ses deux contrôles portent un :skip.

# test/integration/default/default_test.rb (généré)
describe user('root'), :skip do
  it { should exist }
end

Remplaçons-le par de vrais contrôles, qui décrivent ce que la recette promet :

describe package('nginx') do
  it { should be_installed }
end

describe file('/var/www/html/index.html') do
  it { should exist }
  its('mode') { should cmp '0644' }
  its('content') { should match(/Bonjour depuis Chef via CINC/) }
end

describe service('nginx') do
  it { should be_enabled }
  it { should be_running }
end

L'échec qui vous apprend quelque chose

kitchen verify default-ubuntu-2404

  System Package nginx
     ✔  is expected to be installed
  File /var/www/html/index.html
     ✔  is expected to exist
     ✔  mode is expected to cmp == "0644"
     ✔  content is expected to match /Bonjour depuis Chef via CINC/
  Service nginx
     ×  is expected to be enabled
     ×  is expected to be running

Test Summary: 4 successful, 2 failures, 0 skipped

Deux échecs. Le paquet est installé, le fichier est parfait, mais le service n'est ni activé ni démarré. Pourtant, la convergence s'était terminée sans la moindre erreur.

Votre premier réflexe sera de chercher un bug dans la recette. Il n'y en a pas. Regardons dans le conteneur :

docker exec <conteneur> ps -p 1 -o comm=
docker exec <conteneur> test -d /run/systemd/system && echo systemd || echo "pas de systemd"
docker exec <conteneur> pgrep nginx >/dev/null && echo "processus nginx présent"

sh
pas de systemd
processus nginx présent

Tout s'éclaire. PID 1 est un simple sh, il n'y a aucun gestionnaire de services. Le processus nginx existe bel et bien, mais systemd ne le connaît pas, puisqu'il n'existe pas. InSpec, qui interroge systemd pour répondre à « ce service tourne-t-il ? », répond donc non.

Personne ne ment. Chef a fait ce qu'il pouvait, InSpec a dit la vérité, et le conteneur n'a tout simplement pas d'init.

C'est exactement la limite du terrain 1

Voilà, démontrée et non plus affirmée, la raison pour laquelle cette formation quitte le conteneur dès le premier déploiement sérieux. Un conteneur dokken valide très bien la partie déclarative (le paquet est-il là, le fichier a-t-il le bon contenu et le bon mode ?), mais il est structurellement incapable de valider le comportement d'un service.

Un cookbook « vert » dans un conteneur peut donc parfaitement échouer en production sur la seule chose qui compte : le service tourne-t-il vraiment ?

La preuve par la vraie VM

Prenons exactement les mêmes contrôles, et lançons-les contre la machine convergée avec knife-zero, qui a un systemd complet :

cinc-auditor exec profil -t ssh://ubuntu@<ip-de-la-vm> --sudo

     ✔  is expected to be installed
     ✔  is expected to be enabled
     ✔  is expected to be running

Test Summary: 3 successful, 0 failures, 0 skipped

Mêmes contrôles, résultat inverse. Sur la vraie VM, le service est activé et démarré, et InSpec le confirme. La différence ne vient pas de votre cookbook, elle vient du terrain.

Répartir les tests intelligemment

La conclusion pratique est simple : testez dans le conteneur ce que le conteneur sait valider, et réservez à la VM ce qui exige une vraie machine.

À valider	Terrain
Paquet installé	Conteneur (rapide)
Fichier, contenu, mode, propriétaire	Conteneur
Template rendu correctement	Conteneur
Service activé et démarré	VM
Port en écoute, réponse HTTP	VM

Glissez pour voir

En retirant le contrôle de service du profil du conteneur, la boucle redevient verte, et elle reste utile :

Test Summary: 4 successful, 0 failures, 0 skipped

Le cycle complet : kitchen test

kitchen test enchaîne tout : il détruit l'ancienne instance, en crée une neuve, converge, vérifie, puis détruit. C'est la commande à lancer avant de pousser votre code, car elle garantit que le cookbook fonctionne depuis zéro, et pas seulement sur une machine déjà à moitié configurée.

kitchen test default-ubuntu-2404

Test Summary: 4 successful, 0 failures, 0 skipped
Finished verifying <default-ubuntu-2404> (0m1.08s).
Finished destroying <default-ubuntu-2404> (0m10.33s).
Finished testing <default-ubuntu-2404> (0m32.59s).

32 secondes pour un cycle complet, machine jetable comprise. C'est ce qui rend le conteneur si précieux malgré sa limite : à ce prix-là, vous pouvez le lancer à chaque modification.

converge pendant qu'on développe, test avant de pousser

Pendant que vous écrivez, kitchen converge réutilise l'instance existante : c'est rapide. Mais il conserve aussi l'état accumulé des convergences précédentes, ce qui peut masquer un cookbook qui ne fonctionne pas sur une machine neuve. Avant de pousser, lancez kitchen test : il repart d'une machine vierge.

Dépannage

Les échecs de kitchen verify sont utiles, à condition de savoir les lire : beaucoup n'indiquent pas un bug de recette, mais une limite du terrain.

Symptôme	Cause probable	Solution
Le contrôle de service échoue en conteneur	Aucun systemd dans dokken	Attendu : valider le service sur une VM
Les tests sont tous « skipped »	Le fichier généré porte des :skip	Écrire de vrais contrôles
kitchen converge passe, verify échoue	Converger n'est pas vérifier	Lire l'échec : il dit ce que la machine est
Le cookbook marche en converge mais pas en test	L'instance gardait un état accumulé	C'est le but de kitchen test : repartir de zéro
Verify failed on instance	Au moins un contrôle a échoué	Le détail est au-dessus du message d'exception

Glissez pour voir

À retenir

1. kitchen converge dit ce que Chef a fait ; kitchen verify dit ce que la machine est. Ce n'est pas la même chose.
2. Le fichier de test généré est inerte (des :skip) : il faut écrire de vrais contrôles.
3. Dans un conteneur dokken, PID 1 est un sh et il n'y a pas de systemd : le contrôle de service échoue, et c'est normal.
4. Le processus peut exister sans que systemd le connaisse : Chef ne ment pas, InSpec non plus, il n'y a simplement pas d'init.
5. Mêmes contrôles sur une vraie VM : tout passe. La différence vient du terrain, pas du cookbook.
6. Validez le déclaratif (paquet, fichier, mode, contenu) en conteneur ; les services et les ports sur une VM.
7. kitchen test enchaîne le cycle complet depuis une machine vierge : c'est la commande à lancer avant de pousser.

Pour aller plus loin

• Panorama des outils de gestion de configuration : comment les autres outils traitent la question du test.

×

📖 Voir la documentation →