Les exigences concernant les applications et les logiciels sont de plus en plus élevés afin de réponde aux besoins du marché. Désormais, il est vital de raccourcir les étapes du développement tout en recherchant des moyens permettant d’améliorer en permanence le produit, sans en perturber l’utilisation. D’où la nécessité de l’Infrastructure as Code ou infrastructure programmable.
Selon Wikipédia, l’Infrastructure as Code est « un ensemble de mécanismes permettant de gérer, par des fichiers descripteurs ou des scripts (code informatique) une infrastructure informatique virtuelle ». Il s’agit d’une configuration permettant aux développeurs (Dev) et techniciens de l’exploitation (Ops) de gérer une infrastructure informatique et de déployer du code de manière automatisée. Pouvant être appliquée sur plusieurs domaines informatiques, l’Infrastructure as Code est pratiquement incontournable pour le Cloud Computing. Elle est essentielle pour appliquer et tester des codes dans les processus DevOps qui nécessitent une certaine agilité et une bonne dose d’automatisme.
L’Infrastructure as Code simplifie l’administration de l’infrastructure IT
Les avantages de l’IaC sont multiples. Tout d’abord, elle permet de s’affranchir des configurations manuelles qui sont souvent source d’erreurs déviant le programme du standard à atteindre. Les tâches manuelles répétitives, aussi simples soient-elles, réduisent la fiabilité du produit.
Cet ensemble de mécanismes réduit donc les coûts d’exploitation en offrant la possibilité d’administrer du code testé, pratiquement sans intervention humaine. Ce qui implique également des économies de temps. Dans ce sens, le rendement des équipes IT bonifie l’image de l’entreprise qui est alors en mesure de satisfaire ses clients grâce un service de qualité et rapide. Autre avantage non négligeable : l’Infrastructure as Code contribue à la sécurisation informatique de l’entreprise et à la réduction des risques liés à la cybersécurité, notamment en limitant le Shadow IT. Pour rappel, le Shadow IT est l’utilisation d’outils informatiques ou d’applicatifs sans l’accord de l’entreprise, avec des pratiques potentiellement dangereuses.
Par ailleurs, l’IaC offre la possibilité d’intervenir assez rapidement pour rectifier un bug ou une anomalie. Ce type d’intervention prend généralement du temps pour une infrastructure traditionnelle.
L’infrastructure as Code a le vent en poupe
Pour le mettre en œuvre, notamment dans le cadre d’une démarche DevOps, les développeurs et les administrateurs IT ont le choix parmi quelques solutions qui ont fait leurs preuves. Parmi les plus plébiscitées, l’open source Terraform de HashiCorp, qui a levé 175 M$ fin mars 2020, ainsi que les outils IaC conçus par Amazon Web Services Cloud Formation et par Microsoft Azure ARM Templates sont en odeur de sainteté pour le domaine du Cloud Computing. Google Cloud Deployment Manager est surtout utilisé par ceux qui tirent leurs ressources de l’IaaS de Google. Plus généralement, Chef Infra et Puppet sont considérées comme deux alternatives parmi les plus pertinentes. Le premier facilite la collaboration des équipes DevOps et confère plus d’agilité dans les différents processus. Le second permet de mettre en place de nouvelles infrastructures rapidement pour répondre aux besoins spécifiques des clients. Bien qu’il n’ait pas été conçu spécialement pour les configurations IaC, l’outil open source Red Hat Ansible Tower permet également de gérer et de configurer des infrastructures efficacement. Avec son code en YAML, Ansible est compatible avec SSH pour Linux et WinRM sur Windows.
Il existe trois types d’infrastructures en tant que code.
D’abord, l’IaC impératif pour laquelle les ressources sont déclarées dans le respect d’un ordre précis d’instructions.
Ensuite, l’IaC fonctionnel qui accorde peu d’importance à l’ordre dans laquelle ces ressources sont déclarées.
Enfin, l’IaC basé sur l’environnement, qui nécessite une déclaration de ressources en phase avec l’environnement dans lequel elles sont exploitées. Cette dernière version est la plus évoluée et la plus utilisée de nos jours. L’Infrastructure as Code se marie parfaitement aux pratiques DevOps dans la mesure où les applications déployées le sont de manière automatisée entre les couches logicielle et d’infrastructure.
Quels sont les risques liés à l’Infrastructure as Code ?
Côté risque inhérent à l’IaC, le principal reste celui de la réplication d’erreur. Les potentielles erreurs humaines dans le code source, même mineures, peuvent ne produire un impact qu’à plus ou moins long terme et donc être répliquées sur les machines créées automatiquement durant ce laps de temps.
Autre risque, celui d’écart de configuration, lié à une quelconque intervention humaine sur une machine créée via un workflow IaC, avec à la clé des non-conformités, voire des pannes. Attention à la qualité du code !
Finalement, citons le plus rare, mais le plus lourd : le risque de destruction incontrôlée. Vu que certains outils utilisés dans le cadre de l’IaC ont la capacité de « détruire » de façon autonome des ressources si tant est qu’ils aient été codés pour le faire, il convient de mettre des gardes-fous.
Une fois plus, les risques sont surtout liés à l’intervention humaine, que ce soit au niveau du code initial, dans la configuration des outils ou dans un excès d’autonomie qui leur serait accordé. Qualité et délivrabilité vont de paire ;)
