Dans un précédent article d’opinion sur l’intégration continue, j’avais avancé quelques arguments afin de « Bannir l’Infra As Code ».
Je pensais ne jamais changer d’avis jusqu’au jour où j’ai découvert la vraie Infra as Code. Ainsi que son sens premier.
J’aimerais vous exposer dans ce dossier notre nouveau point de vue sur le sujet !
Mais avant toute chose … Définissons-la en bonne et due forme.
Let’s go!
Définition 📖
TL;DR 🧑🏻🏫
L’infrastructure As Code (IaC) est un système de mise en place d’infrastructures informatiques à partir de code source.
Je m’explique 👨🏻🏫
Comme vous le savez, les applications web ont besoin de machines pour pouvoir fonctionner. Des serveurs, plus précisément. Ces serveurs font partie d’une infrastructure informatique.
Ces serveurs, qu’ils soient On Premises ou dans le Cloud, ont besoin d’être mis en route, configurés, et les logiciels mis en place au bon endroit pour être exécutés.
Traditionnellement, ces tâches furent effectuées dûment par des Ingénieurs de Production, ou Ops.
Lorsqu’on veut lancer une nouvelle application, ces étapes de configuration peuvent s’enchaîner: nouveau serveur, mise en place des logiciels dans le système de fichiers, configuration réseau… Et tout cela à la main bien évidemment.
Faire cela à la main c’est ce qu’on appelle le Click Ops.
L’infra As Code entre en jeu 😎
L’IaC permet de simplifier le travail des Ops et des développeurs.
Avec L’IaC, le développeur écrit un code source spécifique qui, une fois interprété par le moteur de l’IaC, permet de réaliser automatiquement les tâches précédemment évoquées.
Par exemple, elle est capable:
- De créer de nouvelles machines virtuelles dans le cloud
- De configurer les ports sur lequel le load-balancer d’un serveur web écoute
- De configurer un déclencheur entre une nouvelle arrivée dans une queue Kafka et un web-service.
… Et bien plus encore !
Quelques exemples de moteurs d’Infra As Code 🛵
Il en existe bien-évidemment d’autres, mais voici trois exemples bien connus:
- CloudFormation
- Terraform
- Ansible
Tous trois utilisent une syntaxe descriptive (généralement YAML ou JSON) pour la mise en place d’Infra as Code.
Jetons un oeil à cet exemple de code CloudFormation de configuration IaC:
"MyInstance" : {
"Type" : "AWS::EC2::Instance", // un EC2
"Properties" : {
"ImageId" : "ami-0ff8a91507f77f867", // Sous Amazon Linux
"AvailabilityZone" : "eu-west-3", // à Paris
}
}
On peut voir sur ce CloudFormation:
- La mise en place d’un EC2 (un serveur sur AWS), qui s’appelle MyInstance
- Avec un identifiant d’Image AWS (probablement un Amazon Linux)
- En plein Paris (la zone eu-west-3)
Pourquoi c’est bien? 👍🏻
L’Infra As Code est un formidable outil pour le développeur (j’vous avais dit qu’on changerait d’avis !).
Langage descriptif 👩🏻💻
Elle lui permet d’utiliser un langage descriptif. Tout est noté, centralisé au même endroit. S’il y avait ne serait-ce qu’un seul doute, il suffirait de lire le code de l’IaC pour voir ce qui est configuré concrètement.
Les autres moyens qu’il reste pour mettre en place des infrastructures sont assez « manuels »: des outils en ligne de commande compilés dans des scripts, ou bien des interfaces graphiques comme la console Azure ou AWS.
Ces moyens ne sont pas très automatiques, et cela met en lumière un principe sempiternel: Les humains font des erreurs, les machines non.
En effet, un template d’Infrastructure As Code fera toujours exactement ce qu’on lui demande, à moins que l’on change ces mêmes choses qu’on lui demande !
De quoi, finalement, signer la fin du Click Ops.
Une infrastructure versionnée 🧑🏾💻
L’Infra as Code, par sa nature, se prête agréablement bien aux gestionnaires code source comme Git.
Le code lié à l’IaC est généralement mis dans le même repository que le code de l’application.
Ainsi, cela permet de faire évoluer son infrastructure avec quelques lignes de code en plus, et un commit supplémentaire !
Une meilleure division du travail 👨🏼💻
Aussi, cela permet de remettre au développeur plus de responsabilités vis-à-vis de la maintenance de l’infrastructure de sa propre application. Il devient ainsi DevOps.
Dans un monde idéal, les responsabilités de l’Ops (souvenez-vous, l’ingénieur de production) deviendraient différentes.
Ce dernier se chargerait alors de tâches plus ciblées:
- Mise en place de stacks complexes à destination des développeurs (Pool de conteneurs Kubernetes, scope de services….)
- Diverses optimisations de coût
- Sécurisation des échanges inter-processus
- Gestions des tâches liées à la production (disaster recovery)
Conclusion 📺
L’infra As Code a permis aux développeurs de devenir maîtres de leur infrastructure. C’est parce que l’IaC parle le même langage qu’eux (le code).
Les qualités énoncées dans cet article en font un outil à considérer sérieusement pout tout développeur professionnel dans le cloud.
Nous pouvons dire, par ce retour d’expérience, que nous avons (enfin) changé d’avis 😊.
Cependant, l’Infra As Code a aussi des limites, que nous explorerons dans un prochain article !