Chef qui es-tu ?

Quels sont les ingrédients pour mettre en œuvre et faire vivre un centre de calcul (cloud privé) devant offrir un service à la demande, en tant qu'infrastructure virtualisée dans un 1er temps (c.à.d Cloud de type IaaS) ? Faisons abstraction des problèmes d'installation des locaux d'hébergement, de la fourniture et de la redondance électrique, de la climatisation, ainsi que des ressources matérielles (serveurs, baies de stockage et équipements réseau : switch, routeur, load-balancer, etc.) et imaginons comment procéder pour fournir et maintenir le service offert pour des clients high tech d'une entreprise d'environ 5000 personnes?

A l'aide de la bonne volonté d'une armée de techniciens pour configurer et valider manuellement chaque équipement d'infrastructure en s'appuyant sur des procédures et paramétrages établis, cela ne va pas dans le sens de la qualité de services et de la réduction des coûts. Alors, à l'aide de traitements automatisés permettant  la mise en oeuvre initiale et la gestion opérationnelle (gestion des pannes, ajout et retrait de matériels, etc.).

A ce stade du projet OpenStack, les mises en oeuvre se sont réalisées pour la plupart de façon semi-automatisée. En effet, bien que le logiciel soit packagé à l'aide de fichiers deb depuis Ubuntu 11.04 ou autres rpm pour CentOS, Fedora, etc., il reste plusieurs actions de configuration assez fastidieuses et précises afin d'installer et de configurer tous les composants nécessaires, au minimum, à Nova, Glance et OpenStack Dashboard. La communauté s'est dotée d'acteurs pour réaliser toute cette couche d'automatisation au dessus des composants d'OpenStack. On peut les déployer avec la solution Opscode (plate-forme dédiée pour automatiser les environnements de type Cloud, détail : ici) en s'appuyant sur la solution Open Source Chef. A priori, pour la release Cactus, la solution Chef Cookbooks pour OpenStack (unité de distribution de Chef) supporte qu'une seule machine avec les composants Nova et Glance. Chef est un logiciel Open Source (licence Apache) de gestion et de publication de configuration constitué de codes (Ruby) pour la gestion des ressources, mais aussi des composants logiciels associés aux applications avec un référentiel des configurations (Cookboooks: paquets à installer, configurations associées, démarrage et dépendances des services, etc.). L'architecture de Chef est donnée ci-dessous. Par ailleurs, il existe une IHM Web de gestion d'un environnement Chef. permettant de s'affranchir d'une gestion à l'aide de commandes CLI.

On trouve donc des composants techniques déjà connus (CouchDB et RabbitMQ), mais il faut savoir que lorsque l'on débarque dans cet univers, il y a beaucoup de zones d'ombre, bien que la finalité soit aisément compréhensible. Chef fonctionne en mode Client / Serveur, il est idempotent et utilise des concepts dont les termes (ici) sont des analogies avec ceux de la cuisine (ex: recettes, livres, couteau, etc.).

C'est un monde à part entière dont environ 700 contributeurs et plusieurs entreprises y participent. A l'identique de la découverte des composants OpenStack, il faudra investiguer sur cette solution pour la comprendre, voire à terme la maîtriser, car il est indispensable de disposer d'outils efficaces pour gérer un environnement de type Cloud Computing. Par ailleurs, Dell de son côté réalise la solution logicielle Crowbar, voire l'outil ou l'objet barclamps pour déployer et gérer les composants matériels et logiciels de couche basse de l'infrastructure technique, mais semble aussi s'appuyer sur Chef pour orchestrer le tout. Le code avec les packages de distribution (14Mo) est disponible ce jour en licence Open Source Apache 2 (ici) et couvre la Cactus, ainsi que les incréments Diablo [1-2].

Un seul billet pour traiter de ce volet très important est impossible.En conséquence, le 1er exercice sera de lire le code Chef relatif au déploiement de Cactus sur un seul serveur, voire de le dérouler. Les détails des pré-requis selon l'environnement à déployer sont donnés (ici).