Comment Puppet, Cfengine ou Chef peuvent aider études et production

Pour faire suite à l’article d’introduction sur le mouvement des DevOps, nous pressentons que, dans leur lourde tâche, nos héros vont devoir s’appuyer sur un certain outillage leur permettant de fluidifier la phase de Mise En Production ; qui dit fluidification dit appli déployée plus vite et le business traduit ça par : « la fonctionnalité va arriver bien plus vite au client ». Et le business aime ça.

L’utilisation du shell est une solution, mais qui montre ses limites. Il est temps de faire appel à d’autres outils. Voici un rapide tour d’horizon de quelques instruments de déploiement automatisé et de leurs principes.

Principes

Les outils de type Cfengine, Puppet ou Chef reposent sur un certain nombre de concepts communs. Précisons à toutes fins utiles que le cœur de cible de ces outils est le monde des serveurs dits « ouverts » et qu’ils vont manipuler des terminologies proches d’UNIX (systèmes de fichiers, points de montage, paquets, cron, permissions UNIX…). À noter que la version payante de Cfengine permet notamment de gérer les machines Windows.

Ces outils tendent à définir un état de configuration (système, applicative) dans lequel on souhaite voir nos machines. On est donc assez proche de la gestion de parc mais pas très loin du déploiement automatisé. Les agents déployés sur les machines cibles vont prendre une configuration de référence sur un dépôt central et opérer les tâches d’administration pour atteindre cette cible. Cfengine, dans sa version 3, parle par exemple de promesse pour définir les actions qu’il va entreprendre (il s’engage à ce qu’un fichier soit présent, et avec les bons droits, à ce qu’un paquet soit installé…).

Les agents vont donc avoir l’incessante mission de rendre une machine conforme à une cible. Malheur à l’édition manuelle d’un fichier localement sur une machine, le prochain déclenchement de l’agent ira consciencieusement l’écraser par la version de référence, si elle a été définie. Au contraire, si une machine n’a pas été modifiée depuis le dernier lancement de l’agent, celui-ci ne fera strictement rien.

La notion de référence, de dépôt central des configurations est un principe essentiel. Même si les outils n’imposent pas l’utilisation d’un gestionnaire de version, l’automatisme qu’ont les développeurs depuis plusieurs années doit devenir systématique dans le monde de la prod : qui dit « dépôt de configuration », dit « gestion de version ». Bien entendu, pour améliorer la convergence des équipes de dev et de prod, on va préférer (ré-)utiliser un outil de gestion de version déjà maîtrisé par les équipes de dev, y appliquer les mêmes bonnes pratiques et standards en matière de gestion de branches, d’étiquetage.

Si c’est en prod’, c’est dans le gestionnaire de serveurs [Puppet, Cfengine, Chef] (rayez les mentions inutiles). Si c’est dans le gestionnaire de serveur, c’est géré en version dans [CSV, SVN, Git, Mecurial] (rayez les mentions inutiles).

Les actions possibles

Un grand nombre d’actions sont ainsi possibles avec les outils de déploiement de configuration :

  • Installer un paquet système (RPM, Deb, pkg…)
  • Installer un fichier à partir du référentiel, en utilisant éventuellement un système de gabarits pour y placer des données dépendantes de chaque machine (exemple : l’adresse IP d’écoute du service)
  • Mettre en place ou modifier une tâche planifiée
  • Créer un répertoire
  • Supprimer un répertoire/fichier
  • Tirer un lien symbolique
  • S’assurer que tel ou tel fichier/répertoire dispose de droits prévus
  • Changer le montage d’un système de fichiers (local ou réseau)
  • Et finalement, le saint Graal : lancer une commande quelconque. On comprend bien qu’il est simplement possible de faire tout et n’importe quoi
    • Reboot de la machine
    • Redémarrage d’un service
    • Déploiement d’un artefact
    • Initialisation d’une base
    • Import de données
    • Remise en marche d’une réplication

Exemples

Les outils utilisent généralement une syntaxe particulière pour les fichiers de configuration. Là où Cfengine a redéfini un format de fichiers spécifiques, Puppet et chef héritent du langage dans lequel ils ont été écrits (Ruby) pour utiliser une syntaxe déjà existante.

Exemple ici avec le positionnement de droits particuliers à un fichier.

À la Puppet :

file { "/etc/plop":
    owner => root,
    group => root,
    mode  => 644,
}

À la CFEngine :

[...]
files:
"/tmp/patapouf"
create    => "true",
perms   => m_u_g("644", "root", "root"); 

body perms m_u_g(m,u,g)
{
mode            =>      "$(m)";
owners          =>      { "$(u)" };
groups          =>      { "$(g)" };
}

À la Chef :

file "/tmp/something" do
 owner "root"
 group "root"
 mode "644"
 action :create
end

Utilisation

Cela ne fait pas franchement de différence que l’on travaille au niveau d’une machine physique ou d’une machine virtuelle. Dans les deux cas, on pilote, on administre l’engin. Seul le cycle de vie peut différer, en effet pour créer une nouvelle VM, on aura tendance à cloner une VM de base, alors que pour des machines physiques, il faut souvent effectuer des manipulations plus compliquées, à grand coup d’installation, de ghost, de boot PXE, j’en passe et des meilleures.

Les agents qui appliquent des modifications sur les machines ont beaucoup de droits. C’est normal, ils doivent pouvoir installer des paquets, changer des fichiers de configuration du système, redémarrer un service voire toute la machine. Il est important qu’une confiance se mette en place entre le serveur central et l’agent. On a souvent recours à de la cryptographie asymétrique (X.509,  RSA…) pour s’assurer mutuellement de l’identité de l’autre.

Les agents peuvent être invoqués sur tout ou partie du parc, soit manuellement à la demande, soit automatiquement à une fréquence configurable. Certains de ces outils vont apporter du contrôle d’accès de manière par exemple à ce que les déploiements sur un environnement de développement soient possibles pour tous, alors que les changements de configuration de production seront mieux contrôlés ou réservés à une certaine population.

Modélisation de la configuration

Une fois que l’on a vu le panel d’actions possibles sur nos systèmes, voyons comment les appliquer sélectivement sur nos machine.

Pour faire simple disons que l’on va être capable de filtrer des actions à des groupes/profiles/rôles/tags (j’emploierai par la suite le terme groupe uniquement pour des questions de simplicité). Exemple : installer Apache uniquement sur les systèmes identifiés comme des serveurs Web.

# extrait d'un fichier de configuration cfengine v2
# déclaration des groupes
groups:
    sql_servers = (db1 db2 dev1) # 3 machines dans ce groupe
    web_servers = (www1 www2 dev1) # idem, dev1 est dans les deux groupes
    san_users = ( ReturnsZero(/bin/grep -qi san /etc/mtab) ) # groupe dynamique

# installation automatique de paquets
packages:
    any::
        # tous les systèmes ont systématiquement NTP et SNMP installés
        openntpd       action=install
        snmpd          action=install

    web_servers::
        apache2        action=install
    san_users::
        san_diag_package action=install

En fonction de l’organisation, on va donc travailler à définir des groupes qui ont du sens, qui parlent aux gens, qu’ils soient des études ou de la prod’, car au final, tous vont s’y référer. Cette étape est essentielle dans la modélisation d’un outil de déploiement automatisé.

On se rend compte que l’on va généralement superposer au moins trois type de groupes aux machines:

  • Des groupes techniques d’infrastructure ou de sécurité (Linux, DMZ, NoSAN, VLAN_203, DataRoom_01) => couche IaaS
  • Des groupes techniques de socle applicatifs (JBoss, Tomcat, PHP, MySQL, rails) => couche PaaS
  • Des groupes fonctionnels applicatifs (MaBanque, MaBanque_2_0, FrontOffice) => couche SaaS

Et pour les DevOps, hmm ?

Les outils de déploiement automatisé dans une approche DevOps peuvent représenter une très bonne interface entre les dev et les infreux. Les deux équipes sont finalement amenées à contribuer à remplir les fichiers de configuration d’un même outil.

Dans cette vision, les ops sont avant tout vue comme une équipe qui met en place les bases de l’outil et définit les actions techniques associées aux groupes, principalement de bas-niveau. En déclarant ces actions à leur convenance, elle s’assure que tous les systèmes seront installés à l’identique et conformément à ses us et coutumes (supervision, sauvegarde, journalisation…), bref aux petits oignons.

Les dev vont avoir avant tout un rôle de contributeur au sens éditorial : ils déclarent des objets, leur attribuent des profils en piochant dans les groupes techniques fournis par l’infra. Un vrai self-service. Ils contribuent également à améliorer les socles applicatifs

Dans le cas d’une infrastructure 100% virtualisée sur un socle déjà provisionné/dimensionné, une équipe de dev bien épaulé par ses ops est donc potentiellement capable de déployer automatiquement de nouveaux services (au sens fonctionnel), de l’OS à l’application, en production, avec toutes les briques d’infrastructure nécessaires à leur exploitation, à des vitesses impressionnantes.

Conclusion

Les outils de déploiement automatisé apportent une très forte capacité à fluidifier et industrialiser des mises en production. C’est une brique qui se justifie souvent pour des tailles de parcs serveurs conséquentes et pour laquelle un ticket d’entrée est toujours à évaluer (en terme de temps et de compétences à acquérir).

Par rapport à l’utilisation du shell, qui restait à l’initiative de l’exploit’ et éventuellement à disposition des dev – et finit par former un véritable serpent de mer au fur et à mesure de l’ajout de fonctionnalités et de spécificités – nous avons ici de véritables outils communs pour le déploiement des applications. Par ailleurs, tout comme le shell, ces outils Open Source ont les défauts et qualités inhérents à leur écosystème : rapides à mettre en œuvre, légers, mais un peu spartiates dans l’utilisation ; et principalement cantonnés aux *nix.

Comme bien souvent, c’est l’organisation à laquelle l’outil participe qui fera le succès d’une mise en prod et non l’outil en lui même. Le mariage entre l’approche organisationnelle DevOps et ces socles techniques semblent très prometteur.

4 commentaires sur “Comment Puppet, Cfengine ou Chef peuvent aider études et production”

  • Salut, Merci pour cet article. J'ai cependant quelques questions : - Comment faire pour déployer une application web (peut importe la techno) qui est dans Git / Svn / Nexus avec un tel outil ? Est ce adapté ? Est ce qu'on peut le faire mais ce n'est pas fait pour çà ? Comment est ce qu'on s'y prends ? - Sur une plateforme qui comporte plusieurs machines, lors du déploiement d'une nouvelle configuration, peut t on s'assurer de la synchronisation des mises à jour sur toutes les machines ? - Est ce que ces outils sont capable de gérer des règles implicites du genre : dans la config précédente, j'avais déployé un cron, mais là il n'y en a plus besoin donc il faut donc supprimer le fichier du /etc/cron.d ? Ou : ce virtual host apache n'a rien à faire ici, poubelle. Merci !
  • De bien bonnes questions ... Des réponses plus précises seront apportées dans des articles traitant spécifiquement des outils (Chef, cfengine, ... ) mais vu d'ici : - Ces outils ne semblent pas adaptés au déploiement des applis, a fortiori web. Ca peut le faire mais ... c'est pas idéal. - Ca dépend de la précision que vous demandez. Si c'est de l'ordre de la seconde, ça peut être compliqué. Si vous admettez que les conf ne soient pas synchro pendant plusieurs dizaines de minutes ou plusieurs heures, ça ira. Mais tout dépend de l'outils. - A partir du moment où vous dites que la conf cible n'a plus ladite cron, si le système se met dans cette conf, le problème est réglé :)
  • très bon article, les amis, j adore puppet et je le mets quasiment partout en ce moment. Néanmoins, il souffre d' un petit défaut, on ne peut pas réaliser des rollbacks de manière immédiate comme sur des outils propios tels que BMC bladelogic,á moins de créer des "anticlasses" pour chaque classe créee.... Par ailleurs, je trouve ça plus propre d'utiliser le même outil de deploiement sur infra virtualisé/physique ou hybride, á savoir PXE+DHCPD+TFTP+KICKSTART ou cobbler pour avoir tout en un, utiliser des templates revient souvent á les administrer... bye
  • Bonjour , je dois faire une étudecomparative de puppet chef et spacewalk. Pouvez-vous m'aider ? Nous avons besoin de la meilleur solution pour les Vms Bladelogic. Aussi, je suis dans un environnement RHEL
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha