Aventures avec Ansible : défis, solutions et... Subversion ?

Dans l'environnement informatique actuel, les applications d'entreprise peuvent être complexes, évolutives, distribuées, basées sur des composants et, souvent, essentielles à l'activité. Elles peuvent être déployées sur une grande variété de plateformes dans des clouds privés, publics ou hybrides. Elles peuvent accéder à des données sensibles et être soumises à des réglementations et des politiques de sécurité exigeantes. Elles doivent pourtant rester aussi faciles à utiliser que possible. Pour faire court, les applications sont synonymes de grande complexité. Dans cet article, nous verrons qu'il est possible de concilier toutes ces considérations en utilisant des outils d'automatisation tels qu'Ansible.

Dans mon article précédent, intitulé Aventures avec Ansible : les leçons tirées des déploiements en situations réelles, j'ai passé en revue les aspects techniques pour utiliser efficacement Ansible dans un environnement. Dans cet article, j'approfondirai ce que je considère comme étant les meilleures pratiques, tirées de mon expérience en matière de déploiements en situations réelles.

Pour concevoir et développer des applications d'entreprise, il faut satisfaire un grand nombre d'exigences individuelles. De plus, les décisions prises au cours du développement pour satisfaire une exigence peuvent avoir des conséquences difficiles à comprendre et à prévoir sur d'autres exigences. Une exigence non satisfaite peut par conséquent entraîner l'échec du projet. Voici quelques exemples d'applications d'entreprise utilisées de nos jours :

• Systèmes de facturation automatisés

• Systèmes de traitement des paiements

• Systèmes d'emailing

• Systèmes de gestion de contenu

• Systèmes de centre d'appels et d'assistance client

• Systèmes de gestion de la relation client

• Systèmes de planification des ressources d'entreprise

• Systèmes d'informatique décisionnelle

• Systèmes de planification de continuité des activités

• Systèmes de gestion des ressources humaines

• Systèmes d'intégration d'applications d'entreprise

• Systèmes de messagerie et de collaboration

Parce que la complexité de ces applications est bien réelle, de nombreuses entreprises n'envisagent pas leur automatisation. Pour expliquer ce fait, elles m'ont donné diverses raisons. Voici les arguments que j'ai pu entendre :

• Il n'est pas possible de l'automatiser !

• Elle n'a pas été conçue pour être automatisée.

• Son automatisation est trop complexe et coûteuse.

• On utilise déjà des scripts shell ainsi que d'autres outils et astuces pour l'automatiser.

• Notre fonctionnement actuel ne nous pose aucun problème.

• Notre talentueux informaticien peut résoudre n'importe quel problème lié à un produit d'entreprise.

Ces entreprises sont peut-être effrayées par le fait que l'automatisation dépasse le simple défi technique. Soyons honnêtes, l'automatisation n'est pas qu'une question de technologie : c'est une autre façon de penser, qui demande un véritable changement de culture.

Lorsque je travaillais en Allemagne dans le cadre d'un contrat avec un client, je dirigeais une équipe chargée de l'automatisation du déploiement de piles logicielles dans 10 environnements différents, avec Ansible, Jenkins et Vagrant. Jusqu'alors, les ingénieurs déployaient des applications en production tous les trois mois, ce qui engendrait de longs temps d'arrêts, des problèmes imprévus pendant le déploiement et bien d'autres difficultés. Dans le monde informatique actuel, cela n'avait plus aucun sens de mettre la pression sur une équipe de 10 spécialistes sur site pour livrer une version à minuit.

C'est pourquoi ils souhaitaient adopter une solution automatisée. Ils voulaient réduire les coûts, améliorer la fiabilité, standardiser leurs environnements, éliminer les tâches manuelles répétitives, permettre aux équipes de consacrer plus de temps à l'amélioration des systèmes plutôt qu'à leur gestion, et ainsi de suite.

Globalement, ce projet a été couronné de succès. Tout n'a cependant pas été simple. Voici comment cela s'est passé...

Les problèmes

Commençons par décrire certains des problèmes qui sont apparus...

Déploiements manuels

Tous les déploiements étaient effectués manuellement, ce qui engendrait les difficultés suivantes :

• Les déploiements en production étaient effectués tous les trois mois et pouvaient demander jusqu'à 8 heures de travail. Ils étaient effectués au milieu de la nuit et nécessitaient l'intervention de 5 à 10 spécialistes différents.

• Chaque spécialiste utilisait ses propres scripts pour effectuer les diverses tâches nécessaires au bon fonctionnement de chaque version, dans chaque environnement.

• Il s'agissait d'un défi organisationnel de taille, et chaque déploiement générait des problèmes uniques.

Déploiements complexes

• Fiabilité : parfois, les applications ne démarraient pas (à cause d'une séquence d'arrêt incorrecte). Chacun avait ses méthodes personnelles pour les redémarrer. Certaines applications n'étaient pas configurées de la même manière dans chaque environnement, ce qui réduisait encore la fiabilité.

• Interaction humaine : les déploiements exigeaient souvent une interaction humaine, pour effectuer une action sur le site web qui permettait le bon déploiement de l'application.

Environnements incohérents (autrement dit, le facteur humain)

À cette époque, nos environnements n'étaient tout simplement pas cohérents. Nous réalisions les déploiements manuellement, et d'une manière ou d'une autre, nous les réussissions toujours. Certaines personnes avaient créé des scripts ou des dossiers spécifiques sur des serveurs cibles, etc. Des erreurs apparaissaient en production alors qu'elles n'étaient pas présentes dans les environnements précédents. Lorsqu'un environnement de production doit s'arrêter pendant une période plus longue que prévue, cela devient vite un problème pénible et coûteux.

Voilà ce qu'était le « facteur humain ».

La culture « en cascade »

Avant l'automatisation, notre méthode consistait à utiliser des techniques en cascade. Les déploiements effectués dans notre environnement de production étaient très rares.

Tout a commencé avec les méthodes agiles et le développement d'équipes « Scrum ». Nous avons ensuite créé une équipe d'automatisation au sein de notre service d'exploitation pour diriger l'automatisation de nos déploiements et réduire leur complexité et leur incohérence. Cette transition vers les méthodes agiles a nécessité plus de 2 ans, et il reste encore aujourd'hui du travail à faire. Le processus s'appuie sur une amélioration et des changements continus, et c'est le principe même de l'approche agile.

La solution

Nous avons mis en œuvre une meilleure méthode.

Les logiciels d'automatisation, les méthodes agiles, les équipes Scrum pour les services de développement et d'exploitation, une équipe d'automatisation chargée de fournir les outils automatisés, ainsi que la transition au quotidien de notre culture d'entreprise vers une nouvelle façon de penser : voilà tous les éléments nécessaires pour fournir une solution élégante et réduire considérablement la pénibilité des déploiements.

Tout cela a demandé beaucoup de temps et de travail de la part de chacune des personnes impliquées.

Voici un aperçu de certains des outils utilisés pour l'automatisation de notre environnement :

Nexus

Avant tout, nous avions besoin d'un référentiel centralisé pour nos artefacts. Votre équipe de développement en utilise sûrement déjà un pour stocker tous les artefacts binaires qu'elle crée.

Jenkins

Jenkins est notre outil d'automatisation des pipelines de CI/CD. Votre équipe de développement utilise sûrement déjà Jenkins ou un outil similaire pour la création automatisée des versions. Cependant, nous souhaitions gérer les pare-feux différemment pour l'automatisation des déploiements. Nous avons donc décidé de créer une instance séparée de Jenkins.

Des pipelines ont été créés pour orchestrer les phases de notre processus de déploiement : préparation, arrêt, déploiement et démarrage. Nous avons créé nos pipelines à l'aide du langage Groovy (classes, fonctions orientées objets, etc.), afin de nous permettre non seulement de standardiser le développement (code réutilisable), mais également de pouvoir recréer une version rapidement en utilisant notre code, en cas de défaillance de Jenkins ou de plantage général.

Et comme même les outils d'automatisation peuvent être automatisés, nous avons automatisé l'installation de Jenkins. Nous avons également installé une version simplifiée de Jenkins sur notre nœud de contrôle, afin de tester les pipelines localement avant d'archiver le code Groovy ou Ansible. Nous l'avons installée avec les mêmes versions du plug-in Jenkins qui étaient exécutées dans notre cluster Jenkins de production.

Ansible

Ansible était au cœur de tout ce que nous faisions.

Nous avons déplacé toute notre configuration vers un inventaire Ansible à l'aide d'une structure d'inventaire à plusieurs niveaux (gestion de Dev1, Dev2, Dev3, Test1, Test2, Test3, etc.) et de variables partagées, ainsi que de group_vars. La migration de la configuration de l'application, qui résidait à l'origine dans les artefacts créés par l'équipe de développement avec leur instance de Jenkins, a pris beaucoup de temps. Les identifiants ont été stockés dans Ansible Vault.

Les déploiements logiciels se découpaient en quatre phases : préparation, arrêt, déploiement et démarrage. Nous avons donc développé nos rôles Ansible avec le point d'entrée tasks/main.yml pour gérer ces phases à l'aide de balises, comme dans l'exemple ci-dessous. Cela nous a permis d'utiliser un pipeline Jenkins pour exécuter tous nos rôles Ansible et effectuer uniquement l'étape de préparation, qui permet d'envoyer le nouvel artefact aux serveurs cibles, sans affecter les services en cours d'exécution. Nous avons ainsi pu économiser beaucoup de temps de préparation, qui ne nécessite aucun temps d'arrêt.

--- - name: Prepare artifact  import_tasks: prepare.yml  tags: prepare - name: Shutdown services  import_tasks: shutdown.yml  tags: shutdown … 

Vagrant

Nous utilisons Vagrant et Virtualbox pour approvisionner un nœud de contrôle, qui dispose d'une installation allégée similaire à notre serveur Jenkins, à partir duquel nos playbooks Ansible sont exécutés. C'est un point important, puisqu'il nous fallait un moyen de tester et corriger les problèmes d'automatisation.

La boîte Vagrant locale a été approvisionnée avec les mêmes versions d'Ansible et de Jenkins, les mêmes plug-ins Jenkins, les mêmes paquets de système d'exploitation et les mêmes noms de volume que pour notre principal nœud maître Jenkins. Elle a été évidemment allégée pour fonctionner avec 1 Go de mémoire et 1 processeur virtuel, une configuration suffisante pour effectuer des tests. De plus, Vagrant a été configuré avec des boîtes qui émulent notre pile de production. Cela nous a permis d'exécuter nos playbooks à partir du nœud de contrôle pour approvisionner et déployer un ou plusieurs hôtes cibles (serveurs web, serveurs d'applications, etc.).

Subversion

L'entreprise utilisait Subversion comme système de contrôle de versions. Nous avons d'abord cherché à le remplacer, mais il était utilisé dans toute l'entreprise. Le changement aurait été trop perturbant. L'utilisation de Git par notre équipe uniquement aurait impliqué la création d'un nouveau silo de données et l'ajout d'une couche supplémentaire à la pile. Je préfère la simplicité avant tout, et nous n'avions jamais rencontré de problème justifiant de passer de Subversion à Git. Il faut parfois savoir choisir quand remplacer et quand conserver une technologie, même s'il ne s'agit pas du dernier outil à la mode.

JIRA

Que serait une méthode agile et une équipe Scrum sans Jira ? Le logiciel de suivi performant développé par Atlassian permet de planifier, suivre et publier un logiciel. L'un des plus grands défis de notre transition vers l'automatisation était de définir les « Users Stories » dans JIRA et de comprendre le produit minimum viable.

Difficultés

Aucun changement ne se fait sans difficultés, et des difficultés, nous en avons rencontré dans tous les domaines possibles.

Technique

Les applications étaient alors dépendantes d'Internet Explorer et utilisaient la technologie ActiveX. Pour contourner ce problème, nous avons utilisé PhantomJS, un navigateur sans interface graphique, pour l'automatisation.

Politique

Le modèle DevOps intéressait les équipes de développement et d'exploitation, mais il était difficile d'harmoniser les priorités définies par ces deux services par rapport au mouvement DevOps. Les deux services avaient des responsables différents, avec des objectifs différents.

Personnel

Certains membres de l'équipe ne s'intéressaient pas du tout à l'automatisation. Du moins, au départ. Pour eux, tout était déjà automatisé. Il était donc important que notre équipe s'accorde sur une définition de l'automatisation. De nombreuses personnes considéraient l'automatisation comme un nouveau langage à apprendre. Avec un peu de patience, le temps de faire germer l'idée et de présenter quelques modèles de réussite, nous les avons convaincues de l'intérêt de l'automatisation avec Ansible.

Résultats

Qu'avons-nous accompli ? Globalement, il s'agit d'une réussite incroyable que je me devais de partager (d'où cet article). Nous sommes partis de zéro et nous avons maintenant une équipe très efficace qui effectue un déploiement en production toutes les deux semaines, à l'aide d'un seul pipeline, pratiquement sans interaction humaine, ni expertise nécessaire pour son fonctionnement.

Parmi les réussites et les résultats obtenus, il faut noter la procédure standardisée pour la préparation, le démarrage, le déploiement et l'arrêt dans 10 environnements. Jusqu'ici, elle s'est avérée fiable et a toujours démarré correctement. Elle a permis de réduire la durée du déploiement, de deux heures à 20 minutes seulement.

En automatisant le pipeline, nous avons supprimé les interventions manuelles nécessaires au déploiement ainsi que les potentielles erreurs humaines. Même avec une documentation solide et un personnel informatique expérimenté, il reste une marge d'erreur relativement élevée lorsque l'on fait appel à des humains pour exécuter manuellement des séries de commandes et d'opérations. Il suffit de rater l'une des étapes ou de ne pas respecter leur ordre pour que toute la procédure tourne rapidement à la catastrophe.

Ce qu'il faut retenir

Nos résultats parlent d'eux-mêmes, mais nous avons également appris quelques leçons utiles.

Il faut être conscient que tout le monde n'est pas forcément favorable à l'automatisation, du moins au début. Vous devrez utiliser un élément non fourni avec Ansible ou tout autre outil d'automatisation : la patience. S'engager dans un projet majeur d'automatisation demande énormément de patience.

Commencez à petite échelle. Démontrez, en réussissant l'automatisation d'un processus, tous les avantages qu'elle offre. L'objectif est d'éliminer une difficulté que l'équipe rencontre. N'essayez toutefois pas de vous attaquer directement au principal problème sans avoir acquis un minimum d'expérience et sans avoir convaincu de la pertinence de l'automatisation. Un raté peut anéantir tous vos efforts d'automatisation et donner l'idée à certains qu'il n'est pas possible d'automatiser leur environnement.

Comme souvent en informatique, 80 % des problèmes que vous rencontrerez peuvent se résoudre assez facilement. Ce sont les 20 % restants qui représenteront un défi lors de l'automatisation : gestion des exceptions, des cas marginaux et d'autres situations imprévues qui peuvent se produire. Si la résolution de ces problèmes peut s'avérer complexe, elle n'est toutefois pas impossible.

Pour les administrateurs systèmes et les spécialistes de l'exploitation aguerris, il est très tentant de résoudre simplement un problème en se connectant à distance à un hôte via le protocole SSH. Ne cédez pas à cette pratique. L'objectif est d'obtenir des systèmes cohérents, prévisibles, standardisés et fiables. Vous devez découvrir comment modifier (ou créer) des playbooks Ansible, pour éviter de vous connecter à la boîte via SSH. Corrigez la source de vos problèmes, pas seulement les symptômes.

Enfin, vous n'aurez terminé qu'une fois que vous aurez automatisé vos outils d'automatisation. Vous devez pouvoir installer et mettre à niveau automatiquement Ansible, Jenkins, les plug-ins Jenkins et tous vos autres outils. Si vous installez ces outils manuellement, vous créerez le même problème que vous cherchiez à régler avec Ansible sur les hôtes cibles. Vous vous retrouveriez avec des environnements incohérents et peu fiables pour vos outils d'automatisation. Tout le contraire d'une base solide !

Conclusion

Tout au long de ma carrière, j'ai toujours essayé d'automatiser tout ce que je pouvais. Je n'aimais pas faire deux fois la même chose manuellement. Le problème provenait des outils inadéquats que j'utilisais.

Réussir à automatiser les logiciels que j'ai installés, configurés, déployés et mis à jour pendant plus de 10 ans a été une expérience incroyable et édifiante. J'ai beaucoup appris en matière de gestion de la configuration, de CI/CD, de pipelines, d'idempotence, etc. Tout cela n'aurait pas été possible sans Ansible.

Alors, ne vous laissez plus impressionner par l'automatisation et commencez à automatiser vos applications d'entreprise sans plus tarder ! Pour découvrir comment les équipes des services Red Hat peuvent vous aider à renforcer l'automatisation au sein de votre entreprise, consultez nos offres de consulting.