Retour sur le Configuration Management Camp 2016

La 3ème édition du Configuration Management Camp (dont le nom de domaine pourrait concourir sans rougir dans la catégorie “difficilement prononçable sans bafouiller”) a eu lieu les 01 et 02 février 2016.

Mais qu’est-ce donc que la Gestion de la Configuration ?


Dixit wikipedia, la “Gestion de la Configuration consiste à gérer la description technique d’un système (et de ses divers composants), ainsi que l’ensemble des modifications apportées au cours de l’évolution du système”. Dit autrement, c’est la (très bonne) pratique qui consiste à décrire la configuration de ses serveurs et de ses applications de manière à ce qu’elle puisse être automatisée et tracée. Les outils les plus connus de Gestion de la Configuration sont Puppet, Chef, Ansible, SaltStack et CFEngine.

En quoi consiste le Configuration Management Camp ?

Tout simplement en un rassemblement mondial de (barbus) fans d’automatisation de la configuration des serveurs et des applications. Mondial, oui, carrément, car bien que se déroulant à Gand (en Belgique), juste après le FOSDEM, on y parle Anglais en permanence, surtout quand on croise les grands noms du domaine : Mark Burges (en 2014, créateur de CFEngine, et auteur de 2 livres références sur le sujet: In search of certainty et Promise theory), Adam Jacob (en 2014, créateur de Chef), Luke Kanies (en 2014, créateur de Puppet), Mitchel Hashimoto (présent aux 3 éditions, fondateur d’Hashicorp, créateur de Vagrant, Consul, Vault et autres) ou encore Mark Shuttleworth (en 2016, Monsieur Ubuntu et Juju).

Et que raconte tout ce beau monde quand il se croise ?

Le planning des conférences est disponible en ligne, mais je vous propose, pour commencer, un retour sur la keynote d’ouverture, “The Magic of Modelling”, par Mark Shuttleworth, le fondateur de Canonical Ltd., la société derrière Ubuntu et Juju.
Dans sa keynote, Mark commence par expliquer que les temps ont changé. Aux début de la gestion de la configuration (la première version de CFEngine est sortie en 1993, Puppet est arrivé en 2005), les logiciels permettant de la mettre en pratique étaient rares. Mais ce n’est plus le cas désormais, nous sommes dans l’époque du logiciel. Qui ne connaît pas l’expression “Software will eat the world” ?
Mark précise cette idée quant à lui, en utilisant l’expression “the age of big software”.
Maintenant que les logiciels ne sont plus rares, c’est la connaissance qui l’est devenue. Pour l’illustrer, Mark s’est appuyé sur un exemple concret et a demandé à l’audience qui pouvait configurer un serveur httpd ou un nginx sans (trop) regarder la documentation. Une bonne moitié de l’assemblée (d’au moins 300 barbus) a levé la main. Question suivante : qui peut configurer un openstack sans regarder la doc ? 3 personnes ! Et qui peut configurer un kubernetes dans cette instance openstack ? 1 seule personne !

Les logiciels que l’on doit déployer maintenant sont différents ; en terme de scalabilité et de topologie. On ne déploie plus une simple application sur un serveur mais une multitude de services sur plusieurs serveurs. Et les outils actuels de gestion de configuration à notre disposition ne sont pas adaptés pour ce type d’utilisation! Vous pourriez répondre qu’une façon de faire est d’utiliser une platforme SaaS (Software as a Service). La réponse un brin provocante de Mark Shuttleworth : “SaaS is proprietary operations”. Accepteriez-vous réellement de laisser à d’autres le monopole de la connaissance du fonctionnement de la plateforme qui héberge vos services ? D’une rareté des logiciels nous sommes donc passés à une rareté des “ops” (ceux qui savent s’occuper de vos applications complexes en production). La solution serait plutôt de proposer des “ops” réutilisables et open source. Mark Shuttleworth propose alors que les nouveaux outils s’appuient sur l’encapsulation et la réutilisabilité. L’encapsulation doit cependant être modélisée, les interactions entre les services doivent pouvoir s’exprimer sous la forme de contrat d’interface : des “boites” connectées avec d’autres “boites”. Cette réutilisabilité et ces contrats d’interface permettront de remplacer certains composants par d’autres, de manière transparente. Par exemple, remplacer un cluster Mysql par un cluster Galera (qui du point de vue de l’utilisateur final s’utilise de la même façon qu’un cluster Mysql, mais qui propose un mode actif/actif que Mysql ne propose pas nativement). Selon Mark Shuttleworth : Il faut modéliser le logiciel, pas les machines. Il faut modéliser le logiciel, pas les fichiers de configuration.

Comment faire ?

 


La solution mise en avant par Mark Shuttleworth s’appuie (sans surprise) sur Juju qui est l’outil d’orchestration proposé par Canonical Ltd qui utilise déjà ce type de modélisation. L’idée avec Juju est d’externaliser de manière ouverte, de produire de manière participative (“crowdsourcer” en franglais) toutes les étapes de la gestion d’un service au sein d’unités appelés “charms” : l’installation, la configuration, la gestion des connexions, les montées de versions et les mises à jour, les maintenances, les benchmarks, les healthchecks, la supervision. Bref, tout ce que vos « ops » préférés font pour vous sans que peut-être vous en soyez conscients.


Les charms déclarent des interfaces (“xxx fournit telle fonctionnalité”, “yyy consomme telle fonctionalité”). La gestion des événements est gérée par le biais de points d’entrée (“hooks”). Les charms mettent en avant la fameuse réutilisabilité qui permet de simplifier les topologies complexes.
Bref, pour Mark Shuttleworth, au delà de l’automatisation, c’est vers la réutilisabilité et le partage qu’il nous faut aller, et en tant que bon chef d’entreprise, il nous invite à jeter un oeil du coté de Juju et de ses charms.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

%d blogueurs aiment cette page :