Infrastructure as code

En 2006, la société Amazon dévoile le concept d'Infrastructure as code permettant le provisionnement d'instances via du code informatique sur Amazon Web Services [4]. Malgré de fortes limitations, cette pratique fut bien accueillie et le marché l'a rapidement adopté. Parmi les principaux acteurs ayant contribué au développement de l'IaC, on peut mentionner Microsoft Azure et Heroku, deux plateformes qui ont rapidement proposé des outils similaires pour leurs services respectifs.

En 2010, OpenStack, un ensemble de logiciels open source permettant de déployer des infrastructures de cloud computing, se positionne sur le marché en offrant la possibilité de créer un cloud privé. Le principe d'avoir un outil dédié à chaque plateforme devient une limitation importante. Dès lors, de nombreuses entreprises préfèrent utiliser un cloud privé pour les données importantes, et garder un cloud public (comme Amazon AWS ou Microsoft Azure) pour les applicatifs moins critiques.

Durant les années 2010, plusieurs outils dédiés à l'Infrastructure as code apparaissent sur le marché, tels Terraform, ou Pulumi. Suivant l'impulsion donnée par OpenStack, les plateformes de cloud public précédemment évoquées développent de nouveaux services cloud, permettant de gérer des DNS, la répartition de charge, des sous-réseaux, des groupes de sécurité, des routeurs virtuels, des volumes ou du stockage objet. Ces services permettent de déployer des infrastructures virtuelles complètes et de ne plus se limiter uniquement aux instances[5].

Il existe trois types d'Infrastructure as code : impératif, fonctionnel et basé sur l'environnement.

• Impératif : les ressources (instances, réseaux, etc.) sont déclarées par une liste formelles d'instructions, suivies dans un ordre précis, pour obtenir le résultat attendu.
• Fonctionnel : les ressources sont déclarées de manière que la configuration finale de celles-ci soit celles attendues. L'ordre en lui-même n'a pas d'importance majeure.
• Basé sur l'environnement : les ressources sont déclarées de manière que leur configuration finale et leur état soit en cohérence avec le reste de l'environnement qui l'entoure. Il s'agit de la version la plus élaborée et celle vers laquelle l'Infrastructure as code tend : la création des ressources n'est pas seulement automatique, elle est intelligente.

Un projet Terraform.

En règle générale, l'Infrastructure as code se compose de fichiers descripteurs, supportant éventuellement la variabilisation, afin de généraliser le code et éviter de devoir le dupliquer pour chaque environnement de déploiement (développement, intégration, préproduction, production, etc). Ces derniers sont lus par un interpréteur approprié, qui va convertir tout le code écrit en appels à des interfaces de programmation[6]. Ces interpréteurs ont besoin de connaître le ou les endroits où vont être déployés les ressources (des providers) ainsi que des identifiants de connexion, pour pouvoir effectuer les appels. L'infrastructure as code est donc soumise au fait que des interfaces de programmation existent, ou qu'un logiciel propriétaire idoine soit fourni.

Outre le déploiement d'infrastructures, certains outils d'Infrastructure as code offrent des interactions avec des logiciels massivement utilisés dans la gestion et le suivi d'infrastructures (Grafana, Prometheus, [...]) pour automatiser d'autres aspects de l'infrastructure, tel que le monitoring; ou la gestion du DNS public[6].

Dans le cas des outils les plus évolués (comme Terraform), il est possible d'utiliser plusieurs fournisseurs, et ainsi déployer des instances sur plusieurs endroits simultanés.

Les avantages principaux de l'Infrastructure as code sont la réduction du coût, la réduction du risque, la rapidité d'exécution, et la collaboration au sein de l'équipe[7] - [8] - [9].

L'infrastructure as code permet en effet un déploiement rapide et transparent vis-à-vis de la finalité du déploiement. De par son automatisation, aucune intervention humaine n'est requise une fois le processus démarré. Outre la meilleure fiabilité apportée par une action automatisée, sans défaillance humaine possible (notamment sur des tâches simples et répétitives telles que le déploiement d'instances), la rapidité d'exécution permet aux équipes de développement de se focaliser non pas sur l'aspect du déploiement de l'application, mais sur le projet en lui-même. Le temps gagné par les équipes est ainsi un élément-clef non négligeable à grande échelle, et le coût associé à un déploiement est bien plus faible. Enfin, l'Infrastructure as code permet de déployer et de détruire à la volée les ressources, et éviter ainsi de laisser des ressources tourner quand il n'y en a pas d'utilité, ce qui représente une économie substantielle sur de vastes projets.

Par ailleurs, l'Infrastructure as code permet de contenir le risque d'un déploiement mal maîtrisé en entreprise : en cas d'une erreur de déploiement, il est possible de revenir en arrière rapidement; le code de l'infrastructure pouvant être versionné comme un autre code logiciel, et le processus de déploiement étant extrêmement rapide. Ainsi, il est possible d'intervenir rapidement en cas de soucis lors d'une montée de version d'un logiciel, ou simplement lors de la correction d'une anomalie détectée. Les défauts logiciels restent donc moins longtemps présents dans le code présent, réduisant les risques associés à ces derniers.

De même, l'Infrastructure as code permet une meilleure collaboration au sein d'une équipe de développement, ou d'une entreprise : l'infrastructure étant du code, il est simple de partager la configuration et de la faire relire ou modifier par un tiers. Ainsi, la charge de l'infrastructure (notamment pour sa phase de conception et choix techniques) ne repose plus sur une seule personne, mais sur un choix collégial de l'équipe, qui peut prendre les décisions de manière commune et intervenir rapidement si besoin en est.

Un dernier point, partiellement lié à la rapidité d'exécution et à la collaboration, concerne la reproductibilité : un même script peut servir, par un simple changement de variables, à déployer tous les environnements pour l'applicatif souhaité (production, qualification, test). Il est donc possible d'avoir des environnements totalement identiques sur le plan technique, et de tester en conditions réelles les applications déployées, sans perte de temps supplémentaire.

L'Infrastructure as code a connu une adoption massive ces dernières années, car ce dernier se combine parfaitement à la mouvance DevOps. En effet, il est possible via l'Infrastructure as code, d'automatiser de manière intégrale le déploiement d'applications, de la couche infrastructure à la couche logicielle. Ainsi, les logiciels d'Infrastructure as code se couplent parfaitement à d'autres outils très connus, tels qu'Ansible, Vault, et Puppet. De plus, la rapidité de mise en place d'environnements dits « de test », totalement déconnectés de la production mais partageant les mêmes spécifications techniques, est un réel plus au sein d'entreprises souhaitant pousser leurs applicatifs en conditions réelles avant une montée en production. Il est donc fréquent de voir de l'infrastructure as code dans les pipelines d'intégration continue et de déploiement continu, pour monter et détruire les ressources dès la mise à jour du code source d'un projet[10] - [11] - [12].