Infrastructure as Code

Un article de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche

LInfrastructure as Code est un ensemble de mécanismes permettant de gérer, par des fichiers descripteurs ou des scripts, une infrastructure virtuelle[1],[2]. Initialement dédié aux machines virtuelles (également nommées "Instances"), l'évolution des offres dans le domaine de la virtualisation ont permis de pouvoir gérer une infrastructure à part entière, de l'instance au réseau, incluant entre autres la gestion du DNS, du Load-Balancing, des sous-réseaux et des groupes de sécurité[3].

Souvent plébiscité dans le cadre du cloud computing, l'Infrastructure as Code offre aux développeurs la possibilité de pouvoir automatiser leurs déploiements, et ainsi éviter toute configuration manuelle ; tout en évitant de devoir écrire d'eux-mêmes les appels aux interfaces de programmation. Cette technologie est donc une réponse aux besoins des entreprises en termes de passage à l'échelle des applications, mais également pour l'automatisation et la simplification des infrastructures des projets informatiques. Également, l'Infrastructure as Code rentre dans la mouvance plus générale du DevOps.

Historique[modifier | modifier le code]

En 2006, la société Amazon dévoile le concept d'Infrastructure as Code, permettant de provisionner sur Amazon Web Services des instances via du code[4]. Suite à un très bon accueil malgré de fortes limitations, le marché s'est rapidement développé, et les principaux acteurs du domaine (notamment Microsoft Azure et Heroku) ont rapidement proposés des outils similaires pour leurs services respectifs.

En 2010, OpenStack arrive sur le marché du cloud computing, offrant la possibilité de créer son propre cloud privé. Le principe d'avoir un outil dédié à chaque plateforme devient une limite importante, nombre d'entreprises préférant utiliser dés lors un cloud privatif pour les données importantes, et garder un cloud public (comme Amazon AWS ou Microsoft Azure) pour les applicatifs moins critiques. Dés lors, plusieurs outils dédiés à l'Infrastructure as Code apparaissent, tels que Terraform, ou Pulumi. Dans le même temps, notamment poussé par OpenStack, les plateformes de cloud public précédemment évoqués développent de nouveaux services cloud, permettant de gérer des DNS, du Load-Balancing, des sous-réseau, des groupes de sécurité, des routeurs virtuels, des volumes et du stockage objet, permettant de déployer des infrastructures virtuelles complètes, de A à Z, et de ne plus se limiter aux instances[5].

Fonctionnement général[modifier | modifier le code]

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 providers, et ainsi déployer des instances sur plusieurs endroits simultanés.

Avantages vis-à-vis d'une gestion d'infrastructure traditionnelle[modifier | modifier le code]

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.

Infrastructure as Code & Mouvance DevOps[modifier | modifier le code]

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 dit "de tests", 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 réelle 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].


Références[modifier | modifier le code]

  1. +Bastien L, « Infrastructure as Code : qu’est-ce que c’est et à quoi ça sert ? », sur LeBigData.fr, (consulté le 25 octobre 2019)
  2. « Que signifie Infrastructure as a Code? - Definition IT de Whatis.fr », sur LeMagIT (consulté le 25 octobre 2019)
  3. (en) « Infrastructure as Code: From the Iron Age to the Cloud Age », sur ThoughtWorks, (consulté le 25 octobre 2019)
  4. « My Gartner », sur www.gartner.com (consulté le 25 octobre 2019)
  5. « What is OpenStack? », sur OpenStack (consulté le 25 octobre 2019)
  6. a et b (en) « Providers », sur Terraform by HashiCorp (consulté le 25 octobre 2019)
  7. (en-US) Mike Chan, « Infrastructure as Code: 5 Reasons Why You Should Implement IaC Now », sur Thorn Technologies, (consulté le 25 octobre 2019)
  8. (en) « Devops Benefits of Infrastructure as Code », sur Stelligent, (consulté le 25 octobre 2019)
  9. (en) Tim Berry, « Infrastructure as Code… but, why? », sur Medium, (consulté le 25 octobre 2019)
  10. « Ansible, Packer, Terraform, un trio gagnant », sur Le blog des experts WeScale - DevOps, Cloud et passion, (consulté le 25 octobre 2019)
  11. « How to use Ansible with Terraform | There is no magic here », sur alex.dzyoba.com (consulté le 25 octobre 2019)
  12. (en) Ernese Norelus, « Building Repeatable Infrastructure with Terraform and Ansible on AWS », sur Medium, (consulté le 25 octobre 2019)