L'infrastructure en tant que code, ou IaC (Infrastructure as Code), est un changement fondamental dans l'ingénierie logicielle et dans la façon dont les opérateurs pensent au provisionnement et à la maintenance de l'infrastructure. Bien que l'IaC se soit imposée comme une norme industrielle de facto au cours des dernières années, de nombreuses personnes ne semblent toujours pas d'accord sur sa définition, ses meilleures pratiques et ses limites.

IaC : Impératif ou déclaratif ?

L'une des décisions à prendre pour tirer parti de l'IaC est de savoir s'il faut apporter des modifications à son environnement avec une automatisation impérative ou déclarative. La plupart des IaC sont de nature déclarative. Voici une façon simple de voir les choses : impératif ou déclaratif, c'est la différence entre la façon dont le programme doit fonctionner et ce qu'il doit accomplir.

Pour apporter des modifications d'automatisation impératives à l’ infrastructure, on peut utiliser une interface de ligne de commande (CLI). Elle dirige les changements vers le cloud d'abord au sein d'un conteneur, puis d'une machine virtuelle (VM), et enfin d'un cloud privé virtuel, dans l'ordre, par le biais d'un script. Il s'agit d'une liste de contrôle détaillée, mais si la configuration doit être modifiée après le push vers plusieurs machines, les étapes et le script devront être refaits.

Une approche d'automatisation déclarative nécessite la création d'objectifs. Par exemple, plutôt que d'utiliser le CLI et d'énumérer la configuration exacte, étape par étape, d'une VM, on peut  simplement indiquer qu’on veut une VM avec, par exemple, un domaine attaché, puis laisser l'automatisation prendre le relais. L'approche déclarative permet d'indiquer plus facilement ce qui doit être accompli par les outils d'automatisation.

IaC : Mutable ou immuable ?

La dérive de configuration est un gros problème concernant la configuration de toutes les parties de l'infrastructure. Cela se produit lorsqu'une infrastructure mutable est en place. Mutable signifie qu'elle est susceptible de changer. Lorsqu'une partie de l'infrastructure change, elle devient désynchronisée par rapport au reste. Il est très important pour la sécurité qu'une application cohérente des configurations soit en place dans toute l'infrastructure.

Une infrastructure immuable ne peut pas être modifiée une fois déployée. Des modifications sont toujours possibles, mais elles sont apportées aux déclarations originales. Une fois les modifications prêtes, tous les dispositifs ou configurations similaires sont modifiés de manière cohérente. La cohérence est nécessaire du point de vue de la sécurité, car les pirates n'ont besoin que d'une seule porte ouverte pour entrer. Fermer toutes les portes de la même manière complique les choses pour le pirate.

IaC : DevOps

Le développement, le test et le déploiement d'applications dans un environnement de production obligent souvent les développeurs à attendre la production, ou vice versa. Un déploiement plus fluide et plus rapide est possible lorsque les configurations du réseau et des machines virtuelles sont effectuées via un système contrôlé. Les développeurs peuvent ensuite demander des conteneurs ou des machines virtuelles par le biais d'une demande automatisée avec le même niveau de stabilité que celui appliqué au code. Il en résulte un meilleur versionnage, plus facile à tracer.

Quels sont les avantages de l'infrastructure as code ?

L'infrastructure as code maîtrise la complexité de l'infrastructure en cloud car elle utilise les mêmes principes d'ingénierie logicielle qui ont permis à d'autres systèmes basés sur des logiciels de monter en charge.

Voici quelques-uns des principes que permet l'infrastructure as code :

Contrôle des versions

Lorsque l'infrastructure est décrite en tant que code, elle peut être enregistrée dans le contrôle de la source, être versionnée et faire l'objet d'un examen du code à l'aide des pratiques de génie logiciel existantes. Les modifications apportées à l'infrastructure peuvent être déployées à l'aide des outils CI/CD existants.

Tester

À mesure que la complexité d'un système critique augmente, les gens peuvent commencer à se sentir nerveux à l'idée d'apporter des changements. Avec l'infrastructure en tant que code, les équipes peuvent écrire des tests pour leur infrastructure afin d'en garantir l'exactitude. Elles peuvent coder des politiques afin que toutes les infrastructures provisionnées et leurs configurations soient conformes. Une fois testés, les composants de l'infrastructure peuvent être des éléments de code réutilisables qui reflètent les meilleures pratiques et qui peuvent être partagés entre les équipes.

Utilisation des IDE

La plupart des développeurs ont un IDE qu'ils utilisent en permanence. Lorsque l'infrastructure est du code, on peut profiter de toutes les fonctionnalités offertes par un IDE, comme l'autocomplétion et la possibilité de rechercher des méthodes et leurs paramètres.

DevOps

L'infrastructure en tant que code permet aux équipes d'infrastructure et aux équipes de développement logiciel d'adopter les principes DevOps et de collaborer plus étroitement. Lorsque l'infrastructure est du code et qu'elle est intégrée au cycle de vie des logiciels de l’entreprise, il existe un langage commun et un ensemble de pratiques communes que les parties prenantes comprennent déjà. Cette compréhension commune favorise la collaboration entre les équipes, ce qui est fondamental pour DevOps.

Quelles sont les limites de l'infrastructure as code ?

Logique et conventions

Les développeurs doivent encore comprendre les scripts IaC. Qu'ils soient écrits en langage de configuration HashiCorp (HCL), en Python ou en Ruby, le problème n'est pas tant le langage que la logique et les conventions spécifiques qu'ils doivent être sûrs d'appliquer. Si une partie, même relativement faible, de l’équipe d'ingénieurs n'est pas familiarisée avec l'approche déclarative ou avec d'autres concepts fondamentaux de l'IaC, on risque de se retrouver dans une situation où l'Ops et ceux qui les comprennent deviennent un goulot d'étranglement. Si la configuration exige que chacun comprenne ces scripts pour déployer son code, l'intégration et la mise à l'échelle rapide créeront des problèmes.

Maintenabilité et traçabilité

Bien que l'IaC soit un excellent moyen de suivre les changements apportés à l'infrastructure et de surveiller des éléments tels que la dérive de l'infrastructure, la maintenance de la configuration IaC tend à devenir un problème à partir d'une certaine échelle. Lorsque l'IaC est utilisé de manière intensive dans une organisation avec de multiples équipes, la traçabilité et le versionnage des configurations ne sont pas aussi simples qu'il n'y paraît.