Pourquoi sortir Ansible du poste de l'administrateur
Un playbook exécuté depuis un poste personnel pose quatre problèmes que l'on découvre tous un jour.
Personne ne sait ce qui a été exécuté, ni quand. La version du dépôt utilisée est celle du poste, éventuellement pas à jour. Les identifiants d'accès à la production vivent sur une machine qui sert aussi à lire des courriels. Et si cette personne est absente, plus rien ne se déploie.
L'exécution centralisée règle les quatre d'un coup.
Ce qu'une chaîne d'intégration doit vérifier
Quatre contrôles, dans l'ordre du coût croissant. Les trois premiers prennent quelques secondes.
La syntaxe : ansible-playbook --syntax-check. Attrape la faute de frappe qui aurait échoué à la trentième machine.
Le style : ansible-lint. Signale les motifs connus pour poser problème, notamment les commandes brutes sans garde d'idempotence.
Les secrets en clair : un outil de détection de secrets sur le dépôt. C'est la vérification qui rapporte le plus par rapport à son coût.
L'exécution sur un environnement de test, puis le double passage vérifiant l'idempotence.
L'exécution automatique, avec prudence
Deux niveaux, et le choix est une décision d'équipe, pas une question technique.
Automatique sur les environnements de test : à chaque fusion, sans intervention. Le risque est faible et le retour rapide.
Manuelle en production, déclenchée par une personne, sur une version explicitement désignée. Le déclenchement est tracé : qui, quand, quelle version.
Le déploiement automatique en production existe, il demande une couverture de tests et une capacité de retour arrière que peu de PME ont. Ne le prenez pas comme un objectif par défaut.
Où vivent les secrets dans la chaîne
Jamais dans le dépôt, jamais dans la définition du pipeline. Dans le magasin de secrets de l'outil d'intégration, injectés au moment de l'exécution.
Deux précautions supplémentaires : le compte utilisé par la chaîne a les droits minimaux nécessaires, et il est distinct des comptes nominatifs, pour que ses actions soient identifiables dans les journaux des serveurs.
La relecture
Le bénéfice le plus sous-estimé du passage par un dépôt.
Une modification de playbook passe par une demande de fusion, et quelqu'un la lit. Trois questions suffisent au relecteur : sur quelles machines cela s'applique-t-il, qu'est-ce qui est modifié, et que se passe-t-il si la tâche échoue à mi-parcours.
Ces trois questions attrapent l'essentiel des incidents évitables, et elles ne demandent aucune expertise particulière.
À retenir
Sortez l'exécution des postes personnels : traçabilité, version connue, secrets isolés, personne indispensable. Vérifiez syntaxe, style, secrets et idempotence. Automatique en test, déclenché et tracé en production. Et faites relire, trois questions suffisent.