Accueil > Devops > À la recherche d’un outil de gestion des configurations ? On a testé Puppet, Chef et Ansible !

À la recherche d’un outil de gestion des configurations ? On a testé Puppet, Chef et Ansible !

Dans l’optique d’un projet reposant sur une architecture comportant de nombreux servers, il était nécessaire de faire un état des logiciels de gestion des configurations pour savoir lequel utiliser. Trois des plus connus ont été sélectionnés pour faire partie de cette comparaison : l’incontournable Puppet, le challenger Chef et le petit nouveau Ansible.

À quoi sert un logiciel de gestion des configurations ?

L’objectif de ces logiciels est de maintenir une configuration identique sur différents serveurs/machines virtuelles.

Anciennement les ops géraient à la main les serveurs en assurant les mises à jour, changement de configuration, etc sur l’ensemble du parc informatique mais ce mode de fonctionnement à ses limites :

  • Il est difficile de s’assurer que la configuration de chaque machine soit parfaitement identique, un oubli est vite arrivé.
  • Le temps requis pour gérer les configurations croît de manière linéaire avec le nombre de machines gérées.
  • L’ajout d’une nouvelle machine peut prendre des heures le temps de reprendre la configuration d’une autre machine ayant un rôle similaire. Et c’est une tâche extrêmement fastidieuse/répétitive (augmentant d’autant le risque d’erreur).

Les logiciels de gestion des configurations vont donc s’occuper de ces tâches :

  • Besoin d’un nouveau front web ? On installe uniquement le système d’exploitation de base sans aucune configuration/logiciel puis on déclare cette machine dans notre logiciel de gestion des configurations en indiquant le « rôle » de cette machine. En 2 minutes nous obtenons un serveur parfaitement fonctionnel avec Apache, Tomcat, les modules requis, la configuration faite, etc !
  • Besoin de changer un paramètre sur un groupe de serveur ? Pas besoin de faire un script ssh complexe qui irait se connecter sur les différents serveurs pour effectuer ce paramétrage ! On déclare la modification dans l’outil de gestion des configurations et suivant la programmation de celui-ci, elle sera déployée sur tous les serveurs que vous lui avez indiqués. Et ceci bien sûr avec un reporting détaillé !
  • Une configuration erronée a été déployée sur certains serveurs et vous ne savez pas pourquoi ou quand cela a été fait ? Les gestionnaires de configuration permettent de retracer facilement l’historique des configurations appliquées à l’infrastructure. Plus besoin de tout tracer dans des documents, le fait d’utiliser ce type d’outil a comme bénéfice collatéral cette historisation automatique

Architecture

Puppet, Chef et Ansible reposent sur des architectures et concepts légèrement différents.

Tous peuvent fonctionner en mode autonome (sans serveur centralisé). Mais dans le mode habituel client/serveur, chacun se distingue :

  • Puppet se découpe en 2 composants : le serveur qui centralise la configuration et les agents qui se connectent auprès de ce serveur pour appliquer la configuration qui les concerne (à noter que l’inverse est également réalisable, depuis le serveur pousser la configuration sur les clients). Facter sert d’outil intégré à puppet pour récupérer de manière unifiée les caractéristiques de la machine (OS, distribution, CPU, mémoire, etc).

Architecture puppet en mode agent/master

  • Chef dispose de l’architecture la plus complexe : la partie serveur est découpée en de nombreux logiciels différents tous travaillant de concert, une ou plusieurs workstation pour la gestion des configurations (on n’intervient pas directement sur chef-server mais par l’intermédiaire de workstations) et les nodes où sera appliquée la configuration (ohai~=facter). À noter qu’Opscode (la maison mère de chef) propose d’utiliser leur serveur dans le cloud pour faire office de serveur chef sans avoir à le maintenir chez soi.

Architecture chef avec un chef server

  • Ansible se distingue des 2 premiers sur plusieurs points. Tout d’abord, il n’y a pas d’agent à installer sur les nœuds à gérer. Ansible se connecte par SSH et réalise l’ensemble de ses tâches par ce biais. Cela apporte de nombreux de bénéfices :
    • il n’y a donc pas d’agent qui tourne en continu sur les nœuds. De ce fait, la sécurité de ceux-ci repose sur le serveur SSH (Open SSH dans le monde Linux) qui est fortement audité et dispose d’une excellente réputation.
    • Il n’y a pas besoin de se soucier d’un mécanisme d’authentification par certificat SSL comme pour les autres logiciels. Vous autorisez l’accès (.ssh/authorized_keys) par la clé utilisée par Ansible (ou la vôtre) et c’est tout ce que vous avez à paramétrer pour permettre à Ansible de gérer la configuration d’un nœud. Simplicité extrême !

    Architecture ansible

Simplicité de prise en main

Mon classement se ferait sans conteste dans l’ordre de suivant, du plus simple au plus complexe :

  • Ansible
  • Puppet
  • Chef

Chef est extrêmement modulaire dans son architecture mais souffre de ce fait d’une complexité accrue. Comprendre à quoi servent les différents composants et les gérer est bien plus ardu qu’avec Puppet qui dispose d’une architecture client/serveur plus simple. À noter cependant que Chef repose sur du Ruby pour la gestion des configurations ce qui peut être un très gros avantage pour ceux connaissant bien ce langage.

Ansible, lui, n’a pas d’agent à déployer sur les différents clients et dispose de mécanismes d’authentification qui se basent sur SSH (bien connu et maîtrisé par les ops).

Fonctionnalités

Je n’ai sûrement pas creusé chacun des outils suffisamment pour pouvoir les départager au niveau de leurs fonctionnalités et de leur étendue, néanmoins je n’ai pas vu de cas où l’un se démarquait particulièrement des autres. Tous semblent capables de remplir les tâches qu’on leur demande (avec plus ou moins de facilité). Il s’agit principalement d’une question de méthodologie, d’organisation et de syntaxe qui diffère des uns aux autres.

Chef semble cependant plus ouvert auprès de sa communauté et permet facilement de récupérer des cookbooks/modules directement depuis l’outil de gestion de celui-ci. Tous ces cookbooks sont hébergés sur github avec Opscode qui chapeaute le tout et évite les doublons ou tranche certaines divergences. Il est donc facile de contribuer et de récupérer des contributions externes.

Puppet et Ansible ont aussi leurs communautés github mais elles paraissent un peu moins développées.

Conclusion

Mon coup de cœur est clairement Ansible. Je connaissais déjà Puppet et je me tournais naturellement vers celui-ci lorsque nécessaire.

Ayant pu prendre le temps de tester les alternatives, je me suis tout d’abord dirigé vers Chef qui dispose d’une aura importante et d’une bonne communauté. Mais l’installation fut laborieuse et son architecture reste, je trouve, un peu compliqué même si cela lui confère certains avantages. Il m’a fallu plusieurs heures avant de pouvoir effectuer un déploiement de configurations et avoir le sentiment de maîtriser parfaitement la solution prendra sûrement encore beaucoup plus de temps.

Le nom d’Ansible m’a ensuite été soufflé et je me suis lancé. En 1h j’étais capable de faire mes premières configurations centralisées par Ansible, un bonheur après avoir testé Chef. La simplicité d’Ansible est sa grande force et cette simplicité ne vient pas handicaper sa puissance et il n’a pas à rougir face aux Puppet et Chef qui ont accumulé une expérience plus importante.

Categories: Devops Tags:
  1. Jonathan Clarke
    30/04/2013 à 13:25 | #1

    Intro très sympa, bravo !

    Ansible a clairement un attrait important pour sa simplicité, et ses capacités de configuration déjà bien avancées. Mais n’oublions pas le pendant de ça : la vérification de la conformité. C’est un sujet très à coeur des entreprises, mais je ne vous apprend rien la. Puppet et Chef savent établir ces informations, même si ils ne les centralisent pas très bien, mais pas Ansible (du moins quand j’ai vérifié il y a un mois).

    Pourquoi ne pas regarder également les autres outils du domaine comme Rudder ou CFEngine (disclaimer: je contribue aux deux) ?

  2. 05/03/2016 à 10:47 | #2

    Ne pas oublier SaltStack qui monte qui monte 😉

  1. Pas encore de trackbacks


5 × = dix