Outils CI/CD : Ansible vs XL Deploy

« La première règle avec toute technologie utilisée dans les affaires, c’est que l’automatisation appliquée à un process efficace va augmenter l’efficacité. La seconde règle est que l’automatisation appliquée à un process inefficace va augmenter l’inefficacité. » 

Bill GATES

Avant de détailler davantage deux outils de déploiement continu (Ansible et XL Deploy), revenons aux fondamentaux : l’intégration continue (CI), la livraison continue (CD) et le déploiement continu (CD). Trois étapes clés du DevOps qui sont standardisées tout au long des projets.

• Logiciel libre : Ansible, est gratuit. Son code source est public et modifiable.
• Agentless : il ne requiert pas d’agent sur les hôtes cibles.
• Automatisation des déploiements et configurations : il fournit plus de 1300 modules et plugins prêts à l’utilisation afin de bien gérer les tâches d’installation, de configuration et de déploiements applicatifs. Ces tâches doivent être écrites dans des playbooks qui peuvent être organisés via des rôles. Lors de l’exécution de ces derniers, Ansible utilise un canal sécurisé via SSH afin de communiquer avec les hôtes distants et exécuter toutes les tâches.
• CLI (Command-Line Interface) : elle supporte presque tous les langages de programmations (shell, python, perl, etc.).
• Playbooks : ce sont des fichiers au format YAML qui ne requièrent pas de compétences en développement. Ils présentent des tâches d’installation (plays), de configuration uniforme et des déploiements applicatifs.
• Version UI (User Interface) : Ansible Tower, la version commerciale d’Ansible, est incarnée par le projet AWX (en mode communautaire). Son interface graphique fournit de nombreuses fonctionnalités telles que la gestion des utilisateurs et leurs rôles, des dashboards personnalisés, des APIs REST internes, l’ordonnancement des jobs, la gestion graphique des inventaires, le monitoring en temps réel d’exécution des playbooks et l’intégration du cloud (Amazon EC2, Rackspace, Azure, etc.).

• Pour les architectures techniques complexes et conséquentes, des problématiques de performance et de latence peuvent être observées dans certains cas : timeout du canal SSH, nombre de forks, timeout dans l’appel des APIs, etc…
• La machine de contrôle (master) où Ansible est installé doit forcément être une distribution Linux.
• Ansible utilise du push plutôt que du pull. Par exemple, si on a un ensemble de 1100 hôtes cibles, il va falloir itérer sur chacun des hôtes pour exécuter l’ensemble des tâches.

• Basé sur le modèle UDM (Unified Deployment Model) : il nécessite la présence des packages déployés et complets en entrée, des environnements (On Premise, Cloud) et un ensemble de dictionnaires qui mettent en exergue la configuration à appliquer.
• Génération automatique des plans de déploiement : le plan de déploiement est basé également sur la spécification du package à déployer (deployed, environnement, dictionnaire), sur l’état initial (la version N-1 du package si elle existe) et l’état cible avec l’application des règles déjà définies par le produit XL Deploy. Par ailleurs, l’ensemble des déploiements peut être fait manuellement ou automatiquement par le biais des plugins que le produit possède.
• Facilité d’intégration avec des moteurs d’intégration continue : XL Deploy est intégré et précédé par des outils tels que Jenkins, Bamboo, TFS et XL Release. Il suffit donc d’inclure les plugins XL Deploy dans ces outils.
• Agentless : il ne requiert pas d’agent propriétaire sur les hôtes cibles, il n’est donc pas nécessaire d’en installer et configurer.
• Compatibilité : XL Deploy a la particularité de pouvoir être installé sur des distributions de type Linux et Windows.
• Version UI (User Interface) : XL Deploy fournit de nombreuses fonctionnalités tels que la gestion des utilisateurs et de leurs rôles avec le modèle d’habilitation conçu, des dashboards personnalisés sur les statistiques des déploiements, des APIs REST internes, l’ordonnancement des jobs, la gestion des environnements et d’infrastructures, le monitoring en temps réel des déploiements, etc.
• Plugins XL Deploy : le produit fournit des plugins natifs inclus dans la licence et des plugins payants à la demande. Il est également possible de développer des plugins personnalisés pour des besoins spécifiques. Les plugins sont des packages « .jar » qui contiennent des scripts, un fichier « synthetic.xml » et des propriétés de version.

• Version uniquement commerciale, pas de version communautaire.
• Pour le déploiement et l’installation des packages applicatifs de grande taille, des problématiques de performance et de latence peuvent être observées dans certains cas : timeout au niveau de la JVM, nombre de forks en parallèle ou encore timeout dans l’appel des APIs REST.
• CLI (Command-Line Interface) : l’interface ne supporte que le langage Python.
• XL Deploy utilise du push plutôt que du pull.

La pertinence des équipes Devs et Ops repose sur leur capacité à déployer des applications au même rythme que les besoins des utilisateurs finaux, tout en préservant les composants socle du système d’informations qui les supportent. Ce processus, concrétisé par la mise en place d’outils de CI/CD efficients, permet d’obtenir des avantages concurrentiels accrus et une livraison de meilleure qualité du produit.

L’enjeu majeur de cette efficacité s’appuie sur la capacité à choisir les bons outils, c’est-à-dire, ceux susceptibles de répondre aux aspirations des équipes et qui sont le plus adaptés aux contextes projet. Ansible et XL Deploy présentent chacun des avantages et des inconvénients, comme énoncé précédemment.

XL Deploy est plutôt destiné aux organisations en cours de construction ou en cours d’adoption de stratégie DevOps. Son interface graphique est très ergonomique, les plans de déploiements sont rapidement traçables et sa simplicité d’utilisation incarne complètement le processus CI/CD avec les outils d’intégration continue. Cependant, le coût des licences XL Deploy peut également contraindre certaines organisations à se tourner vers des solutions plus abordables, voire gratuite, c’est notamment le cas dans la plupart des PME.

Il n’existe pas d’outil de déploiement continu parfait pour la mise en place de la culture DevOps. Avant de choisir la solution la plus adaptée à vos besoins, je vous conseille fortement de bien connaitre votre propre organisation, vos besoins projets ainsi que vos processus internes.

Je vous recommande de tester plusieurs outils sur un premier projet, l’objectif étant de s’assurer que les équipes soient assez matures dans leurs réflexions avant de faire le bon choix.

Si l’on suit le précepte de Bill GATES, l’industrialisation de ces bonnes pratiques rendra le cycle de vie du projet plus réactif et mettra en exergue l’amélioration continue de la qualité du code livré.

Mohamed,
Expert technique

Crédit photo © Xebia Labs