Certaines sociétés veulent leur DevOps lab. Un bien grand mot pour caractériser une plate-forme de travail dédiée aux outils DevOps. A l’instar de tout bac-à-sable, ce lab est un excellent moyen de se les approprier, d’apprendre à les administrer, à les maitriser. Non seulement des sociétés mettent les moyens pour une telle mise en place, mais parfois des individus à titre personnel veulent eux aussi se parfaire voire acquérir de nouvelles compétences. Et donc les uns ou les autres commencent à installer ces fameux outils DevOps.
Comment ça « installer » ? Vous voulez dire apt-get install etc. ? En somme, installer à la main !? Ce qui me parait assez hallucinant quand on parle de DevOps, de configuration et de déploiement automatique, avec toute la batterie d’automatisation et de scripting sous-jacente ! A mon sens, pour un DevOps Lab, il faut le constituer dans un esprit DevOps ou plus exactement en Infra-as-code. Et moi de lancer le projet G10B, le numéronyme pour Get your lab!
Voyons plus avant le concept de ce projet permettant d’obtenir ex-nihilo un DevOps lab sans les mains.
La réflexion initiale est assez simple. Toute mon infrastructure sera configurée par un outil dit de Configuration Management. Un tel outil configure, paramètre l’ensemble d’un système d’informations, et dans le cas du projet G10B il configurera les machines provisionnées, et installera et configurera les outils et applications installés. Et pour cela j’ai choisi Puppet de chez Puppet Labs. Cet outil configurera tout le DevOps lab. Et quand je dis tout, ça implique l’outil Puppet lui-même.
Donc que Puppet s’auto-configure semble aller de soi. Une fois que tout est en route, c’est aisé. Mais comment amorcer la pompe ? Comment installe-t-on et paramètre-t-on un puppet ex-nihilo ? Sans rentrer ici dans les détails techniques, la stratégie coule de sources (geek joke inside). Il suffit d’abord de faire installer un puppet, et je dis « faire installer » parce qu’il est hors de question pour moi d’opérer à quelque opération manuelle. Puis de faire alimenter cette coquille vide de Puppet avec l’ensemble des informations nécessaires à la configuration du DevOps lab dont le Puppet et sa propre machine. Enfin, Puppet applique cette configuration et donc s’applique lui-même sa propre configuration.
D’aucuns diront que c’est très bien tout ça mais si Puppet n’est pas installé à la main, qui l’installera ? Encore une idée simple : l’étape précédente en terme conceptuelle. Kézako ? Pour faire simple, on provisionne, on installe, on configure. Quelle étape précède celle de la configuration ? La provision.
C’est donc lors de la provision que la primo-installation se fera, pour les anglophones je parle ici de bootstrap.
Pour les deux du fond, je reprends le cours chronologique des choses, le provisionnement va bootstraper l’installation de Puppet et de sa configuration, puis Puppet va s’autoconfigurer.
De même j’utilise un bootstrap lors du provisionnement pour installer les agents Puppet qui solliciteront le Puppet-Master pour se voir configurer comme il se doit.
Le résultat actuel en V0.3 est qu’en enchainant un git clone
et un vagrant up
, j’obtiens après quelques tasses de café, une infrastructure de VMs, avec Puppet, Jenkins, Gitlab, et Rundeck prêts à l’emploi.
Et avec tout ça je fais ce que je veux, en mode goret, sans prendre aucune précaution particulière. Pourquoi donc ? Tout simplement parce qu’avec un git clone
et un vagrant up
, je reviens à un DevOps lab tout propre, prêt à l’emploi.
Ton OS hôte c’est Debian et t’as juste besoin de vagrant et git ? Tout le reste se fait tout seul ?
Je suis passé sur Ubuntu 14.04 pour cause de prise en charge de la carte WiFi Intel 7260 non prise en charge par Debian.
Mais l’esprit reste le même dans le sens où effectivement, j’ai juste besoin de vagrant, git et virtualbox. Tout le reste se fait tout seul.