Aventures avec Ansible : les leçons tirées des déploiements en situations réelles

Ansible est un puissant outil d'automatisation informatique. Comme la plupart des outils puissants, sa maîtrise demande du temps et vous devrez apprendre à vous en servir correctement et en toute sécurité dans votre environnement.

Mon utilisation d'Ansible pour automatiser le déploiement et la gestion des applications d'entreprise m'a permis de tirer un certain nombre de leçons. Je les considère maintenant comme des bonnes pratiques que j'aimerais partager avec vous. Après tout, c'est ainsi que fonctionne le modèle Open Source. Si vous commencez tout juste à découvrir l'outil Ansible, consultez ce guide du débutant.

Je travaille dans le domaine des logiciels d'entreprise depuis longtemps, bien avant l'apparition d'Ansible. Je me souviens de l'époque des déploiements en production trimestriels, qui se déroulaient de nuit et mobilisaient toute une équipe pour assurer le fonctionnement de la version. Ces déploiements étaient coûteux, complexes, incohérents et frustrants à bien des niveaux.

Pour se détacher de cette façon de faire et apprendre à automatiser les déploiements logiciels plus rapidement et régulièrement il faut un changement de culture radicale et beaucoup de travail technique. Je parlerai des aspects culturels dans un autre article. J'aimerais aborder ici quelques-unes des pratiques que j'ai acquises avec Ansible, afin de tirer le meilleur parti de ses fonctionnalités et de sa communauté.

Normes

L'automatisation tourne autour de ces trois points clés :

1. Les normes

2. Les normes

3. Et encore les normes !

Rédiger un petit playbook pour effectuer une tâche administrative particulière peut être simple et amusant, mais le développement de centaines de playbooks/rôles, pour le déploiement automatisé d'une pile logicielle entière, dans de nombreux environnements, peut s'avérer compliqué et demander une configuration avancée. De plus, si vous ne réutilisez pas les rôles ni ne développez de normes, vos playbooks et rôles se multiplieront immanquablement. Ce tutoriel pour les playbooks Ansible peut vous aider à prendre la bonne voie.

Dès le premier jour, cherchez des moyens pour standardiser vos playbooks, vos rôles et autres pratiques avec Ansible, afin que l'équipe puisse les réutiliser autant que possible et comprendre comment les différents composants interagissent.

Une galaxie lointaine, très lointaine

Ansible Galaxy, le référentiel centralisé des rôles de la communauté Ansible a été conçu pour vous aider. Prenez l'habitude de le parcourir pour savoir si quelqu'un n'a pas déjà résolu le problème que vous rencontrez.

Attention toutefois à ce que vous y trouverez. Le contenu de Galaxy peut être réutilisé, mais avant de l'appliquer dans votre environnement, prenez bien le temps de l'étudier et de le comprendre. Vous pourriez causer beaucoup de tort à votre environnement en très peu de temps, en utilisant un rôle qui produit un effet inattendu.

Concevez un inventaire solide

L'outil Ansible peut fonctionner avec les machines de votre infrastructure tout en reposant sur son propre inventaire pour énumérer différents groupes de systèmes et définir des groupes en fonction de leur charge de travail ou d'autres caractéristiques. Il peut même fonctionner avec un système d'inventaire dynamique, pour les environnements dont le nombre d'hôtes varie selon la demande.

L'inventaire Ansible peut très vite devenir complexe si vous gérez des applications d'entreprise avec un grand nombre d'informations de configuration.

Par exemple, nous avions beaucoup de fichiers XML qui contenaient des informations de configuration pour notre middleware. Nous avons alors créé des modèles Jinja et déplacé les éléments de configuration des fichiers XML vers notre inventaire Ansible. Ainsi, nous avons pu générer les fichiers XML plus facilement et les pousser vers les serveurs cibles. En outre, pour gérer nos environnements multiples, nous avons fini par utiliser un plug-in Vars personnalisé en Python, afin de charger uniquement des données de configurations spécifiques dans la structure de dossiers personnalisée de notre inventaire.

Un gestionnaire pour les gérer tous !

Les gestionnaires sont des ensembles de tâches dont l'exécution est déclenchée uniquement par notification et une seule fois par playbook. Par exemple, vous pouvez créer un playbook avec des gestionnaires qui se déclenchent suite à des événements spécifiques, tels que le redémarrage d'un service ou d'une application. Dans un rôle Ansible qui permet de gérer un service particulier, les gestionnaires peuvent être utiles pour créer des tâches claires et compréhensibles dans un fichier « handlers/main.yml », qui peuvent se déclencher à la suite de changements dans le service.

Je n'utilisais pas de gestionnaires lorsque j'ai débuté avec Ansible, je peux donc vous assurer qu'ils m'ont simplifié la vie. Ne les laissez pas de côté !

L'idempotence : à découvrir, appliquer et adopter

En automatisation informatique, l'idempotence est un véritable mode de vie. Vous devez la comprendre, puis l'appliquer lorsque vous rédigez vos codes d'automatisation. Alors de quoi s'agit-il au juste ? Pour citer le glossaire d'Ansible, une opération est « idempotente si elle donne exactement le même résultat que vous l'exécutiez une fois ou de manière répétée, sans aucune intervention ».

La conséquence est que vous pouvez exécuter vos playbooks plusieurs fois et que le résultat final devrait rester le même : les serveurs ciblés seront dans leur « état souhaité ». Si votre playbook échoue sur un petit nombre de serveurs, vous pouvez résoudre le problème et l'exécuter à nouveau. Puisque le playbook est idempotent, les serveurs ciblés seront dans leur « état souhaité » et aucun autre changement ne se produira.

De l'importance du nom

Veuillez prendre le temps de nommer toutes vos tâches. Cela peut vous paraître évident, comme si je vous demandais d'ajouter des commentaires à votre code, mais il est très important de donner un nom lisible à vos tâches, pour permettre aux autres utilisateurs de comprendre leur fonction. Suivez ces deux règles simples :

1. N'ajoutez pas de commentaires de programmation traditionnels, comme « # ceci est un commentaire », dans vos playbooks Ansible. Ansible n'est pas un langage de programmation, c'est un outil d'automatisation.

2. Utilisez plutôt le « Nom » pour décrire le script ou la tâche, avec des explications intelligibles. Décrivez vos intentions, sans entrer dans les détails techniques.

Le principal avantage de la propriété « Nom » des scripts ou tâches est que celle-ci s'affiche lors de l'exécution du playbook. Cela peut s'avérer utile pour le diagnostic des playbooks. Les commentaires, quant à eux, ne sont pas affichés dans les résultats de l'exécution.

D'après mon expérience, de nombreuses personnes participent à la rédaction des playbooks/rôles/tâches, en commençant par les équipes de développement et d'exploitation. Il est donc important de savoir quel est l'objectif de chaque tâche.

Désignation et priorité des variables

Soyez prudent lorsque vous nommez vos variables au sein de votre inventaire, de vos playbooks et de vos rôles Ansible. N'oubliez pas qu'Ansible attribue chaque variable à un hôte spécifique (les variables hôtes). Évitez donc les noms génériques pour vos variables, tels que « java_path: /my/path ». Il y a des chances pour qu'une autre application sur le même hôte utilise Java, avec un chemin d'accès différent. Il arrive souvent que plusieurs applications existent sur le même hôte, mais utilisent différentes versions de Java, avec des chemins d'accès différents.

Choisissez des noms distincts et intelligibles pour vos variables, avec pour préfixe le nom de votre entreprise. Par exemple, si l'entreprise ABC veut créer des variables d'inventaire personnalisées pour une application appelée AppOne qui utilise la version 1.8 de Java, elle pourra les nommer ainsi :

abc_appone_java_path: "/opt/appone/java" abc_appone_java_version: "1.1"

Méfiez-vous du « copier-coller »

Permettez-moi de clarifier ce point. Faites les choses correctement et, plutôt que de copier-coller des éléments d'un playbook à un autre, créez des rôles réutilisables. De cette manière, vous ne modifiez le rôle qu'une seule fois et les dépendances utiliseront automatiquement la dernière version. Ainsi, pas besoin de partir à la chasse aux directives obsolètes ou de subir des comportements inattendus en exécutant le playbook un mois plus tard.

Apprivoisez cet environnement

Avec Ansible, vous pouvez choisir votre environnement de développement intégré. Après tout, c'est simplement de la syntaxe YAML. Veillez toutefois à choisir un IDE qui vous simplifie vraiment la vie. Voici quelques fonctionnalités que j'estime essentielles dans un IDE pour la création de rôles et playbooks Ansible :

• La coloration de la syntaxe YAML et la prise en charge de lint

• La coloration de la syntaxe Python et la prise en charge de lint (Ansible est rédigé en Python et, croyez-moi, vous aurez besoin d'examiner le code source parfois)

• Un système de contrôle de versions intégré

• L'intégration JIRA : vous pouvez gérer la modification de plusieurs demandes à la fois

• Une fonction Rechercher et Remplacer efficace : vous aurez souvent besoin de modifier, supprimer ou déplacer une variable Ansible sur plusieurs sources et pour ce faire vous devrez rechercher toutes les références

• La prise en charge du langage Ruby (si vous souhaitez également modifier des fichiers Vagrant)

• La prise en charge du langage Groovy (si vous souhaitez coder vos jobs Jenkins)

En adoptant ces pratiques, vous devriez vous en sortir haut la main et éviter les erreurs que j'ai faites en utilisant Ansible pour le déploiement et l'automatisation des logiciels d'entreprise. Ainsi, vous serez libre de commettre vos propres erreurs et d'en tirer vos propres leçons ! Pour plus d'informations sur les bonnes pratiques avec Ansible, consultez la section des bonnes pratiques dans la documentation d'Ansible, téléchargez la liste d'aide à la décision concernant l'automatisation d'entreprise et gardez également un œil sur le blog de Red Hat et le blog Ansible.