Puppet contre Ansible : le face à face de la gestion des configurations… et de DevOps

Parler le Puppet

Puppet est l'un des pionniers de DevOps et un cadre  de ce mode déclaratif. La société commercialise Puppet Enterprise et dispose à son catalogue de quatre autres produits, plus un en version bêta : Discovery pour l'inventaire en temps réel ; Pipelines pour le CI/CD vers les serveurs, les machines virtuelles et les containers ; Container Registry ; Continuous Delivery for Puppet Enterprise ; et Insights, qui analyse plusieurs métriques type de DevOps – celui-ci n’est pas encore sorti. Ces produits étendent la portée de Puppet à pratiquement tous les aspects de la gestion et du déploiement de la configuration.

Puppet s’adosse à une architecture maître/agent, un  processus agent s'exécutant dans chaque noeud qui héberge les applications. Cet agent donne un contrôle complet du déploiement en temps réel et ce, à un niveau extrêmement granulaire. Puppet est souvent reconnu par les experts comme comme proposant la meilleure gestion de la configuration et du cycle de vie des applications. L'approche agent permet également à l’outil de s'adapter à des déploiements à grande échelle, avec un impact limité sur les performances.

Puppet utilise un langage dédié (DSL – Domain-Specific Language) pour ses déclarations. Ce langage requiert certes de l’expertise, mais Puppet est capable de vérifier la syntaxe. Ce qui réduit la possibilité d’erreurs.

De plus, les tâches de Puppet (Puppet Tasks) dotent l’outil d’une dimension prescriptive, ou de type script, au modèle déclaratif global. Avec Puppet Tasks, les utilisateurs ont la possibilité d’apporter des modifications aux nœuds, de changer la configuration voire même redémarrer, en dehors du cadre déclaratif. Les équipes opérationnelles peuvent garder le contrôle et agir directement, sans essayer de forcer un système déclaratif.

Avec sa richesse fonctionnelle, Puppet peut s'appliquer à presque toutes les tâches de déploiement de logiciels, de test et de gestion du cycle de vie. Pour faciliter les choses, des modules peuvent être versés à Puppet Forge, et apporter une notion de personnalisation. Mais, même avec les modules, la courbe d'apprentissage reste raide.

Passez au sans agent avec Ansible

Ansible est un nouveau venu sur le secteur. La solution n'utilise pas d'agent, ce qui facilite son adoption et son déploiement, mais limite également la gestion des nœuds. Cette limite ne représente pourtant pas un frein technique pour un grand nombre d'utilisateurs. Ils apprécient la simplicité du framework d'Ansible par rapport à d'autres outils.

Agentless Ansible permet de contrôler l’ensemble des nœuds, à condition d’une connexion Secure Shell (SSH) et de Python. Les nœuds peuvent être contrôlés à partir de n'importe quel endroit disposant des clés SSH et d'un accès à l'inventaire et aux outils Ansible. Il n'est pas nécessaire d'avoir un serveur central – même si la plupart des utilisateurs centralisent leur gestion pour éviter les problèmes de contrôle. Ansible Tower administre globalement les tâches d'automatisation et celles liées à l'infrastructure.

Ansible gère l'orchestration via des playbooks, exécutés par un moteur d'automatisation qui contrôle les hôtes et la connectivité réseau. Un playbook est un ensemble d'instructions YAML. Vous pouvez créer des playbooks avec n'importe quel outil conçu pour YAML.

Les tâches du playbook s'exécutent dans les nœuds Ansible en déployant des modules à distance via SSH. Chaque tâche représente des étapes vers l’objectif. Ces tâches s'exécutent à distance, puis Ansible supprime le module ; en effet, les modules sont un processus de transition. Un utilisateur peut également déployer des modules de commande pour avoir un contrôle direct, mais ceux-ci opèrent en dehors du cadre déclaratif.

Les modules proviennent de différentes sources : des utilisateurs ou de la bibliothèque d'Ansible. Et on retrouve certains éléments sur le portail Ansible Galaxy.

Un inventaire cartographie les nœuds Ansible. Ils sont généralement définis par leur mission globale, (un serveur Web par exemple). Vous pouvez également appliquer des rôles à des groupes de modules pour simplifier le processus.

Comment les distinguer

Ansible et Puppet ont des approches différentes, mais toutes deux se concentrent sur les objectifs à atteindre plutôt que sur les étapes nécessaires pour y parvenir.

Puppet a la puissance nécessaire pour cibler nombre d'environnements de déploiement, d'applications et de types de nœuds. L’outil fait office de pionnier et fournit la plus grande bibliothèque d'outils et de composants prédéfinis. Lorsque DevOps est apparu pour la première fois, ses multiples options de déploiement ont séduit les utilisateurs.

Mais cette capacité est aussi ce qui rend Puppet plus difficile à apprendre. Les utilisateurs sont unanimes sur la question : Ansible est plus facile à utiliser que Puppet. Les playbooks et les modules d’Ansible sont lisibles et faciles à comprendre. Avec Ansible, il est possible de diviser les tâches de déploiement, de test et d'exploitation en fonction des exigences  de l’entreprise et des politiques de conformité.

Ansible permet également de provisionner l'infrastructure et de déployer des applications multicomposants complexes. On peut aussi dimensionner l'infrastructure et la déployer en une seule étape.