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.

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 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

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.

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

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.