Infra-as-Code : pourquoi et comment coder son infrastructure ?

Infrastructure as code, de quoi parlons-nous ?

Historiquement, les serveurs peuvent être répartis en deux catégories : serveurs physiques et machines virtuelles.

Tous deux étaient installés manuellement, en démarrant sur une image d’installation. Il était ensuite possible de créer des snapshots, images instantanées de disques de machines virtuelles existantes, afin de les utiliser comme base pour ne pas réinstaller encore et toujours la même chose. Cependant ces images, ou templates, montrent vite leurs limites. Dès qu’il est nécessaire d’y apporter une modification, celle-ci se fait manuellement… posant des problèmes en termes de traçabilité, de répétition (recréation du template en cas de perte) ou tout simplement de connaissance : il est nécessaire de documenter ce qui est pré-installé sur ces images, de tenir la documentation à jour, et autres tâches fastidieuses et sources d’erreur.

Et si nous décidions de raisonner dans le sens inverse ? Écrire la documentation, puis avoir des outils en mesure de la comprendre pour configurer nos serveurs, générer nos images, et autres tâches qui n’ont aucune valeur ajoutée à être faites manuellement ?

Parlons donc d’infrastructure-as-code.

Que représente de l’infrastructure « comme du code » ?

Commençons tout d’abord par voir ce qu’est du code aujourd’hui :

• Le code n’est, au final, qu’un descriptif textuel d’instructions dans un langage donné.
• Cette description textuelle est comprise et transformée en actions concrètes, soit par un interpréteur soit via un compilateur.

Cette description textuelle peut (et doit) être versionnée : que ce soit via git, SVN, Mercurial ou autre.

Ce versionnement apporte un certain nombre de bénéfices. En effet, dans bien des cas, il existe toujours un point centralisant la base de code et permettant aux développeurs de regrouper et synchroniser leurs contributions au projet, typiquement Github ou Gitlab pour un projet versionné via git (qui est pourtant un système de versionnement distribué). Ce point central devient alors le point névralgique des actions découlant de la contribution de code : build, test, voire déploiement du code. Cette centralisation apporte également une certaine traçabilité : en effet, on possède un historique des modifications, qui sont datées et associées à un auteur, voire potentiellement signées cryptographiquement. Par ailleurs, on s’efforcera de ne jamais modifier l’histoire passée une fois celle-ci centralisée (git rebase puis git push –force par exemple), assurant ainsi l’intégrité de cet historique. Par ailleurs, « la doc, c’est le code » est un credo qui revient de plus en plus fréquemment, notament via le mouvement Craftsmanship.

L’infrastructure-as-code va donc consister à décrire l’infrastructure voulue textuellement, comme du code, et à versionner ce code, bénéficiant ainsi d’avantages notables tels qu’un point central pour l’automatisation de la gestion de notre infrastructure, la traçabilité de l’historique des évolutions, l’approbation de modifications ou encore une certaine forme de documentation.

En revanche, une fois cette description textuelle écrite, qu’en fait-on ?

Revenons sur notre comparaison avec le code : une fois écrit, du code est soit interprété, soit compilé. Il y a donc des outils en mesure de comprendre cette description textuelle d’instructions pour en tirer des actions / exécutions concrètes. Dans le cas d’un langage interprété tel que Python il s’agira de l’interpréteur Python lui-même, et dans le cas de langages compilés tels que le C il s’agira d’un compilateur tel que GCC ou Clang.

Pour notre infrastructure, c’est la même chose : une fois cette description textuelle écrite, il est nécessaire de posséder des outils en mesure de comprendre cette description pour les transformer en actions concrètes, sans quoi il ne s’agirait que de simple documentation.

Nous allons donc voir dans cet article quels sont ces outils, les paradigmes associés, les grands mouvements de l’infrastructure-as-code, ou encore le résultat que l’on peut aujourd’hui, en 2018, espérer atteindre avec de telles pratiques.

…et pour découvrir le reste, c’est par ici !

Afin de découvrir le dossier complet, téléchargez-le ici.

Pour continuer de parler Infrastructure, Conteneur, DevOps et Orchestration : rendez-vous au Paris Container Day

Après le succès de l’édition 2017, le 26 juin prochain aura lieu la 3ème édition du Paris Container Day au New Cap Event Center.

En 2017, nous vous parlions de la mise en production, cette année le thème de la conférence sera “Vivre avec l’Orchestration”.

Petite nouveauté cette année, les participants auront la possibilité de construire leur programme de la journée parmi 3 types de présentations (Conférences, Retours d’expériences et Fast Tracks) avec un niveau de difficulté technique dédié (Débutant, Intermédiaire et Avancé).

Le programme de la journée est disponible sur le site de l’événement.

Et n’oubliez pas nos TechTrends associés : Les Architectures Micro-services, Les Conteneurs et le Mouvement DevOps.

Tous les TechTrends et livres blancs de Xebia sont disponibles en téléchargement gratuit sur http://blog.engineering.publicissapient.fr/publications/.

Bonne lecture et rendez-vous au Paris Container Day !