Qu’est-ce que l’infrastructure en tant que code (IaC) ?

L’IaC considère l’infrastructure comme un logiciel. Les équipes utilisent l’IaC pour versionner, tester et déployer l’infrastructure en utilisant les mêmes pratiques que celles qu’elles utilisent pour le code des applications. 

Cette approche permet aux équipes de contourner la configuration manuelle traditionnelle, qui peut être fastidieuse et source d’erreurs. La configuration manuelle implique souvent l’installation de serveurs individuels, la gestion basée sur la console et les modifications non documentées.

Au lieu de cela, les équipes définissent les exigences en matière d’infrastructure dans les fichiers de configuration qui spécifient les ressources nécessaires (serveurs, réseaux, bases de données, politiques de sécurité) et comment les configurer. Ces fichiers sont ensuite intégrés dans des systèmes de contrôle de version, qui offrent des fonctions de suivi, de révision et de restauration.

L’IaC est un élément important de la pratique de l’automatisation de l’infrastructure dans son ensemble, qui utilise le code et l’automatisation pour gérer l’infrastructure informatique tout au long de son cycle de vie. Avec l’IaC, les développeurs n’ont plus besoin de provisionner manuellement les composants de l’infrastructure chaque fois qu’ils développent, testent ou déploient des applications. Cette automatisation aide les entreprises à contrôler les coûts, à réduire les risques et à répondre rapidement à de nouvelles opportunités commerciales.

À mesure que les organisations adoptent des architectures cloud natives, l’IaC, elle, devient de plus en plus essentielle. Les environnements informatiques s’étendent désormais sur plusieurs clouds, des milliers de conteneurs et de microservices distribués. Les processus manuels qui étaient autrefois gérés par quelques serveurs ne peuvent plus gérer ces architectures, dans lesquelles les équipes déploient fréquemment des centaines d’applications par jour et provisionnent, mettent à l’échelle et mettent hors service en permanence l’infrastructure.

L’IaC permet de gérer ces environnements complexes de trois manières critiques :

• Opérer à l’échelle : configurer et maintenir des milliers de serveurs, de conteneurs et de ressources cloud dans plusieurs environnements.
  
  
• Accélérer les cycles de déploiement : elle met instantanément à l’échelle l’infrastructure pour répondre à la demande sans configuration manuelle fastidieuse.
  
  
• Assurer la cohérence : elle élimine les erreurs humaines et les dérives de configuration qui peuvent entraîner des vulnérabilités de sécurité, des violations de conformité et des interruptions de service.

Par exemple, une entreprise de vente au détail qui se prépare au Black Friday pourrait avoir besoin de dimensionner 100 à 1 000 serveurs en quelques heures. Avec l’IaC, cette mise à l’échelle se fait automatiquement sur l’infrastructure sur site et dans le cloud, sur la base de modèles prédéfinis. Cette capacité à dimensionner permet de garantir que chaque nouveau serveur dispose de configurations de sécurité et de conformité identiques.

Selon l’IBM Institute for Business Value,  65 % des dirigeants déclarent que les technologies d’automatisation telles que l’IaC améliorent la productivité de leurs équipes informatiques.

L’IaC combine un workflow reproductible avec des outils automatisés. Le workflow, à savoir écrire, versionner, provisionner et déployer, définit comment les équipes passent des exigences d’infrastructure aux ressources déployées. Les outils, à savoir les fichiers de configuration, les systèmes de contrôle des versions et les moteurs d’automatisation, fournissent les mécanismes permettant de définir, de suivre et de créer une infrastructure.

Ensemble, ces éléments transforment la gestion de l’infrastructure d’un processus manuel et susceptible de contenir des erreurs, en une fonction automatisée et reproductible. Les équipes écrivent l’infrastructure en tant que code, avec des versions uniques comme dans le cas des logiciels, puis déploient des environnements identiques à la demande.

Le workflow d’IaC suit quatre étapes :

Les développeurs créent des scripts d’IaC en utilisant des langages tels que HCL, YAML ou JSON, de la même manière qu’ils écrivent du code d’application en Java™ ou Python. Les équipes rédigent des définitions d’infrastructure qui indiquent les ressources dont elles ont besoin et la manière de les configurer. Elles écrivent souvent ces fichiers dans des environnements de développement intégrés (IDE), qui fournissent des fonctionnalités de vérification des erreurs et d’autocomplétion.

Le code est stocké dans des systèmes de contrôle de version, également appelés contrôle des sources ou code source, tels que Git ou GitHub. Le contrôle des versions suit les modifications, conserve les versions alternatives et permet aux équipes de revenir aux versions antérieures en cas de problème.

Un moteur d’automatisation lit les fichiers de configuration et met à disposition les ressources d’infrastructure spécifiées. Cette étape transforme le code en infrastructure réelle en créant des machines virtuelles (VM), en configurant des réseaux, en mettant en place des bases de données et en établissant des groupes de sécurité. Le processus de provisionnement est dépendant, ce qui signifie qu’il peut être exécuté plusieurs fois sans créer de ressources en double.

Les équipes exécutent des scripts pour déployer une infrastructure dans divers environnements, tandis que l’IaC permet d’assurer des configurations cohérentes entre les environnements. La cohérence des scripts est particulièrement utile lors du déploiement continu, où les modifications logicielles apportées à une application sont automatiquement publiées dans l’environnement de production. 

Les outils automatisés fournissent des mécanismes permettant de définir, de suivre et de créer une infrastructure basée sur le code.

Les fichiers de configuration définissent l’infrastructure. Ils peuvent être écrits dans des langages HCL, JSON, YAML ou spécifiques à un domaine. Ces fichiers sont des schémas directeurs qui décrivent exactement l’infrastructure dont vous avez besoin, comme le nombre de serveurs, leur taille et les paramètres réseau, dans un format que les outils d’automatisation peuvent lire et exécuter.

Ces fichiers deviennent la source d’information unique pour les équipes, garantissant la cohérence dans plusieurs environnements. Ils peuvent être mis à jour, réutilisés ou modifiés pour les nouvelles installations à mesure que les équipes ajoutent d’autres actifs. 

Les systèmes de contrôle des versions stockent l’historique de chaque fichier. Ils suivent le code original et toutes ses modifications, y compris ce qui a été modifié, par qui et quand. Ce suivi permet aux équipes de comprendre les modifications, de récupérer les suppressions et de revenir en arrière en cas de problème.

Le contrôle des versions permet aux entreprises de diviser l’infrastructure en modules qui se combinent grâce à l’automatisation. Cette approche modulaire permet de créer, de mettre à jour et de gérer les versions d’environnements complexes tout en réduisant les doublons et en facilitant le test et la réutilisation des scripts.

Les moteurs d’automatisation automatisent le provisionnement et la configuration à l’aide d’un code prédéfini. Ils exécutent les définitions d’infrastructure dans les fichiers de configuration, transformant ainsi le code en ressources informatiques réelles comme des serveurs, des réseaux et des bases de données.

Certains moteurs sont spécifiques au cloud, comme AWS CloudFormation, Azure Resource Manager ou Google Cloud Deployment Manager. D’autres fonctionnent sur tous les clouds, comme Terraform, OpenTofu (un fork open source de Terraform) ou Pulumi (qui utilise des langages de programmation généralistes tels que Python).

Ces moteurs d’automatisation sont souvent associés à des outils d’orchestration, tels que Kubernetes, pour coordonner les ressources et les workloads à l’échelle.

Les outils d’IaC s’intègrent souvent aux plateformes cloud via des interfaces de programmation d’application (API). Ces connexions API permettent aux outils d’IaC de communiquer directement avec les services cloud, de créer et de gérer des ressources par programmation plutôt que par le biais d’interactions manuelles sur console.

L’IaC intègre également des pratiques standard de développement de logiciels pour garantir la fiabilité. Les tests automatisés peuvent aider à vérifier les configurations de l’infrastructure avant le déploiement, en identifiant les erreurs qui pourraient autrement entraîner des pannes ou des vulnérabilités de sécurité. Certains systèmes de contrôle de version peuvent déclencher ces tests automatiquement lorsque des modifications de code sont apportées, afin de s’assurer que chaque modification est validée avant d’entrer en production.

Lors de la mise en œuvre de l’IaC, les entreprises font deux choix principaux : comment définir une infrastructure (déclarative ou impérative) et si une infrastructure peut être modifiée après le déploiement (muable ou immuable).

Les approches déclaratives et impératives diffèrent selon la manière dont vous écrivez votre code d’infrastructure.

L’approche déclarative, également connue sous le nom d’approche fonctionnelle ou IaC déclarative, est la méthode la plus courante. L’utilisateur décrit l’état souhaité, « J’ai besoin de 3 serveurs avec ces spécifications », puis l’IaC gère la mise en œuvre. Elle crée les ressources, installe les logiciels nécessaires, résout les interdépendances et gère automatiquement les versions.

L’approche impérative, également connue sous le nom d’approche procédurale, exige que l’utilisateur rédige des instructions étape par étape pour le provisionnement de l’infrastructure. Les commandes exactes sont spécifiées dans un ordre précis : « Créer d’abord un serveur, puis installer ce logiciel et configurer ces paramètres. » Cette approche nécessite plus d’expertise et peut rendre plus difficile le maintien de la cohérence.

L’infrastructure muable peut être modifiée après le provisionnement, tandis que l’infrastructure immuable ne peut pas l’être après le provisionnement.

L’infrastructure muable offre une certaine souplesse pour les changements ad hoc, comme pour répondre à des exigences d’application spécifiques ou pour appliquer des correctifs de sécurité d’urgence. Cependant, cette flexibilité peut compromettre la cohérence et compliquer le suivi des versions.

La plupart des entreprises choisissent une infrastructure immuable. Pour modifier un serveur ou une configuration, les équipes doivent remplacer l’ensemble de l’infrastructure par de nouvelles ressources.

Bien que cela puisse sembler prohibitif, c’est en réalité bénéfique pour plusieurs raisons. Tout d’abord, l’infrastructure immuable élimine les écarts de configuration. La dérive est un problème courant de l’infrastructure muable, où les modifications manuelles s’accumulent au fil du temps, compliquant le maintien de la cohérence entre les environnements.

Deuxièmement, l’infrastructure immuable offre des capacités fiables de suivi et d’annulation des versions, car chaque modification crée une nouvelle instance versionnée. Les équipes peuvent ainsi instantanément revenir à n’importe quelle configuration précédente.

Enfin, avec l’IaC basée sur le cloud, la nouvelle infrastructure peut être provisionnée rapidement, souvent en quelques minutes, de sorte que le reprovisionnement de toutes les ressources d’infrastructure est beaucoup plus pratique qu’il n’y paraissait au départ.

En automatisant la gestion de l’infrastructure qui utilise du code, l’IaC offre plusieurs avantages :

L’IaC est essentielle aux pratiques DevOps, car elle permet à l’infrastructure de se déplacer à la vitesse du développement logiciel.

Sans IaC, le provisionnement de l’infrastructure peut devenir un goulot d’étranglement. Alors que le code se déploie en quelques minutes, la configuration de l’infrastructure peut prendre des heures, voire des jours. Par exemple, l’ajout d’une nouvelle base de données peut nécessiter l’ouverture d’un ticket auprès de l’équipe chargée des infrastructures et des jours d’attente.

L’IaC élimine ce problème en appliquant une intégration continue et une livraison continue (CI/CD) aux déploiements d’infrastructure. L’infrastructure et le code d’application peuvent être testés, validés et déployés ensemble en parallèle, plutôt qu’en tant que processus disparates.

En pratique, le code d’infrastructure évolue souvent aux côtés du code d’application dans le contrôle de version. Lorsque les développeurs valident des modifications, le pipeline CI/CD peut provisionner l’infrastructure de test à l’aide de modèles IaC, exécuter des tests automatisés et utiliser les mêmes modèles pour les déployer en production. Cela permet de s’assurer que chaque environnement (développement, test, transfert, production) dispose des mêmes configurations d’infrastructure.

Le principal avantage est la cohérence. Sans IaC, des dérives environnementales peuvent se produire lorsque les environnements de test ne correspondent pas à la production, ce qui entraîne des échecs de déploiement. L’IaC permet de s’assurer que ce qui fonctionne dans les tests fonctionne également en production, car les deux utilisent les mêmes définitions d’infrastructure. Les équipes peuvent examiner les modifications de l’infrastructure par le biais de requêtes d’extraction, suivre les modifications et annuler les opérations en cas de besoin, en traitant l’infrastructure avec la même rigueur que pour le code de l’application.

Les outils d’IaC se répartissent en deux catégories : les outils de provisionnement qui créent et déploient une infrastructure, et les outils de gestion de la configuration qui maintiennent l’infrastructure après le déploiement.

Certains outils s’exécutent sur tous les clouds (provenant de plusieurs fournisseurs), tandis que d’autres sont spécifiques à une plateforme.

Les entreprises combinent généralement des outils des deux catégories pour créer des pipelines d’IaC complets.

Les outils de provisionnement créent et déploient des ressources d’infrastructure : serveurs, réseaux et systèmes de stockage. Ils se concentrent sur l’installation et la configuration initiales des composants de l’infrastructure, transformant ainsi les exigences de l’infrastructure en ressources fonctionnelles. 

Terraform de HashiCorp, une société IBM, est un outil IaC qui peut fonctionner sur tous les clouds et qui utilise une configuration déclarative pour gérer l’infrastructure sur plusieurs plateformes.

Les équipes écrivent des définitions d’infrastructure en HCL (HashiCorp Configuration Language) et peuvent déployer le même code sur AWS, Azure, Google Cloud ou dans des centres de données sur site. Cette portabilité permet aux entreprises d’éviter l’enfermement propriétaire et de mélanger les fournisseurs de cloud en fonction de leurs points forts, par exemple en utilisant AWS pour le calcul et Google Cloud pour le machine learning.

Terraform accélère également les déploiements en provisionnant simultanément des ressources sur plusieurs fournisseurs. Il analyse les dépendances entre les ressources et crée des dépendances indépendantes en parallèle. Par exemple, si vous déployez 10 serveurs AWS et 5 bases de données Azure sans dépendance, Terraform crée les 15 ressources à la fois plutôt que de manière séquentielle, ce qui réduit le temps de déploiement.

AWS CloudFormation est la solution IaC native d’Amazon pour l’infrastructure AWS. Les équipes définissent des piles complètes d’applications, des instances EC2 aux bases de données Rational Directory Server, à l’aide de modèles JSON ou YAML. CloudFormation gère automatiquement les dépendances des ressources, les créant dans le bon ordre et les annulant en cas d’erreur.

Bien que limité à AWS, CloudFormation offre une intégration approfondie avec les services AWS et une prise en charge immédiate des nouveaux éléments. Les entreprises qui utilisent AWS pourraient préférer sa performance native et l’accès à des fonctionnalités propriétaires.

Azure Resource Manager (ARM) est l’outil IaC natif de Microsoft pour l’infrastructure Azure. Bien que limité à Azure, il offre une intégration approfondie avec la plateforme.

Les entreprises utilisent des modèles ARM (format JSON) pour définir, déployer et gérer les ressources Azure. ARM fournit des fonctionnalités intégrées, notamment un contrôle d’accès basé sur les rôles pour la sécurité, l’étiquetage des ressources pour l’entreprise, des verrous pour empêcher les suppressions accidentelles et le mappage des dépendances pour garantir que les ressources sont déployées dans le bon ordre. 

Google Cloud Deployment Manager est l’outil IaC natif de Google qui utilise des modèles YAML ou Python pour orchestrer les déploiements cloud. Bien que spécifique à une plateforme, il crée et configure des ressources sur plusieurs services cloud (Cloud Storage pour les données, Compute Engine pour les machines virtuelles et Cloud SQL pour les bases de données) ce qui permet de s’assurer qu’elles fonctionnent ensemble comme une pile complète.

Les outils de gestion de la configuration maintiennent l’infrastructure après le provisionnement, ce qui permet de garantir que les systèmes restent correctement configurés, corrigés et cohérents. 

Ansible est un outil d’automatisation de Red Hat qui gère la configuration sans nécessiter d’agents sur les systèmes cibles. En d’autres termes, Ansible n’a pas besoin d’installer de logiciel particulier sur les serveurs qu’il gère. Il se connecte directement en utilisant le protocole SSH pour exécuter des commandes.

Cette approche sans agent signifie qu’Ansible fonctionne dans les environnements cloud, sur site et hybrides. Les équipes écrivent des protocoles YAML qui définissent les états souhaités, et Ansible veille à ce que les systèmes correspondent à ces états. Elle est souvent utilisée pour gérer les conteneurs Docker et les déploiements Kubernetes.

Puppet utilise une configuration déclarative pour gérer de grandes infrastructures dans des environnements cloud, sur site et de centre de données.

Il vérifie en permanence des milliers de serveurs pour s’assurer qu’ils correspondent aux configurations définies, en corrigeant automatiquement toute dérive. Puppet génère des rapports détaillés montrant ce qui a changé et quand, ce qui le rend efficace pour les déploiements plus importants.

Chef utilise des « livres d’instructions » et des « recettes » pour définir les configurations d’infrastructure dans n’importe quel environnement, qu’il soit cloud, sur site ou hybride.

Les entreprises se tournent fréquemment vers Chef pour son cadre des exigences. Les équipes peuvent vérifier les configurations dans les environnements de test avant de passer en phase de production. Cette approche, qui consiste à découvrir les problèmes à un stade précoce, peut la rendre populaire auprès des entreprises qui ont besoin de mises à jour fréquentes de l’infrastructure et qui doivent mettre en place des cadres des exigences robustes.