L'infrastructure en tant que code (IaC) est un processus qui automatise l'approvisionnement et la gestion des ressources cloud. Le logiciel IaC prend des scripts d'entrée décrivant l'état souhaité et communique ensuite avec le(s) fournisseur(s) cloud, généralement par le biais d'API, pour faire en sorte que la réalité corresponde à cet état souhaité.
Cet article aborde les aspects importants de l'IaC, en commençant par sa genèse (c'est-à-dire les problèmes qu'il a permis de résoudre), puis ses avantages, et enfin la manière d'intégrer l'IaC dans votre organisation.
Il fut un temps où lorsqu'une entreprise souhaitait utiliser un logiciel, sa seule option était de commander un équipement physique et un accès à l'internet auprès d'un fournisseur de réseau. Il s'agissait de centres de données sur site, où les entreprises devaient commander des serveurs et des équipements de réseau des semaines, voire des mois à l'avance, en fonction du trafic prévu, puis les approvisionner manuellement sur place. Cela nécessitait un site physique avec des systèmes de refroidissement et d'innombrables heures pour effectuer les installations et les opérations de maintenance.
C'est alors qu'est apparu le centre public de données, capable de gérer les serveurs d'autres entreprises.
L'exploitation d'un centre de données est devenue une activité viable en soi, avec de grands avantages pour les clients :
L'avènement de la virtualisation a entraîné une autre évolution : le site cloud. Dans un site public (ou privé) cloud, l'équipement physique se trouve dans le centre de données du fournisseur cloud, ce qui nécessite toujours une manipulation manuelle. Les serveurs virtuels sont devenus accessibles aux entreprises par le biais d'interfaces web, leur permettant de provisionner des serveurs et d'autres ressources en quelques secondes (ou minutes pour les ressources les plus importantes). À ce stade, bien que la virtualisation permette un approvisionnement très rapide, la plupart des opérations étaient encore manuelles.
Un dernier développement est intervenu avec l'avènement des concepts et des outils de l'IaC. Une fois le site cloud accessible par le biais d'une API, l'approvisionnement et la gestion des ressources peuvent être gérés par des scripts et des outils automatisés plutôt que par des humains. Ainsi, une fois l'équipement physique installé et connecté (opérations encore manuelles), tout le reste peut être automatisé, y compris l'approvisionnement de toutes les ressources matérielles virtuelles.
La possibilité d'accéder de manière programmatique au nuage public a permis l'essor de l'IaC. Avant l'avènement de l'IaC, les ingénieurs système devaient passer manuellement par des interfaces web pour approvisionner et configurer les ressources. Avec l'IaC, le provisionnement et la configuration des ressources sont décrits dans des scripts, qui sont lus par des outils qui communiquent avec l'API publique cloud pour s'assurer que la réalité correspond à l'état souhaité.
Comme indiqué plus haut, les outils d'IaC utilisent des données provenant de scripts ; ces scripts sont rédigés par des humains et décrivent un état souhaité pour les ressources cloud données. Les outils communiquent avec le fournisseur cloud via ses API pour créer, mettre à jour ou supprimer des ressources afin que la réalité corresponde à l'état souhaité décrit dans les scripts d'entrée. Par rapport au provisionnement et à la configuration manuels, l'IaC offre une source unique de vérité (les scripts d'entrée), éliminant ainsi la plupart des erreurs humaines.
L'exécution d'un script IaC est une opération répétable, qui produira exactement le même résultat à chaque fois. Cela peut s'avérer utile à bien des égards, par exemple pour :
Les scripts IaC peuvent être sauvegardés dans un dépôt git, ce qui vous permet d'avoir un historique de votre infrastructure. En outre, comme les scripts ne sont que du texte, il est possible de comparer les versions pour voir ce qui a été ajouté, modifié ou supprimé.
Un autre avantage est que l'IaC permet à un administrateur système junior ou à une personne non technique de créer une charge de travail complète sans connaissances techniques. Si vous configurez correctement votre compte cloud, vous pouvez même permettre à un utilisateur disposant d'autorisations limitées de créer une telle charge de travail via les outils IaC, même si l'utilisateur n'a pas les droits de créer les ressources directement. Vous pouvez également tirer parti d'outils et de modèles supplémentaires pour veiller à ce que les politiques de sécurité soient mises en œuvre plus tôt afin de limiter les risques de fuites de sécurité et de mauvaises configurations par quiconque instancie la pile IaC.
Outre la répétabilité exacte, l'un des principaux avantages de l'IaC par rapport aux opérations manuelles est qu'il est évolutif. En effet, il vous suffit d'écrire les scripts IaC une seule fois, et les charges de travail peuvent ensuite être instanciées autant de fois que vous le souhaitez, presque instantanément. Enfin, en consacrant plus de temps à l'élaboration des bonnes autorisations dans vos scripts IaC, vous éviterez les inconvénients typiques d'un travail manuel consistant à accorder trop d'autorisations aux rôles et aux ressources.
En règle générale, vous souhaitez automatiser certaines opérations que vous effectuez actuellement manuellement. La première étape consiste donc à documenter les étapes manuelles nécessaires à la mise en place de l'infrastructure requise pour votre charge de travail. Ce sont les étapes que vous allez automatiser grâce à l'IaC.
Vous devez ensuite choisir un logiciel IaC. Le choix ne devrait pas être difficile, car il n'y en a que quelques-uns, et les trois principaux fournisseurs cloud ont le leur : Amazon Web Services propose CloudFormation, Microsoft Azure propose Azure Resource Manager et Google cloud Platform propose Google cloud déploiement Manager. L'option la plus connue qui est indépendante des fournisseurs est Terraform, qui prend en charge non seulement les trois fournisseurs de cloud mentionnés ci-dessus, mais aussi beaucoup d'autres.
Ensuite, vous devrez écrire quelques scripts pour l'outil IaC de votre choix afin de reproduire les étapes manuelles que vous avez documentées. Il est généralement judicieux de les tester au fur et à mesure. En d'autres termes : Écrivez un bout de code IaC, déployez-le, testez-le et, lorsque vous êtes satisfait de son aspect, passez au bout de code suivant. Si vous écrivez tout en une seule fois, des failles importantes peuvent apparaître dans votre code, que vous ne découvrirez qu'après de nombreuses heures de travail, ce qui signifie que vous devrez peut-être réécrire une partie importante de vos scripts.
En outre, le thème du "Shift Left" reste d'actualité. Cela signifie essentiellement que vous commencez à tester le plus tôt possible et que vous vous concentrez sur la prévention des problèmes (par opposition à la détection et à la résolution des problèmes une fois qu'ils se sont produits). L'idée est que la qualité et la sécurité globales s'en trouveront améliorées.
Idéalement, ce Shift Left devrait tirer parti de l'automatisation autant que possible. En effet, il existe plusieurs outils permettant d'automatiser certains aspects de l'écriture des scripts IaC, comme la sécurité et la conformité. Ces outils analyseraient le code avant tout déploiement afin de réduire l'incidence de problèmes tels que les mauvaises configurations, les paramètres trop permissifs et les vulnérabilités connues. Vous trouverez ici quelques cas d'utilisation à cet égard.
Pour utiliser correctement l'IaC, la personne qui rédige les scripts de l'IaC doit avoir une connaissance approfondie de la plateforme cloud utilisée. Par conséquent, il est conseillé de s'assurer que les parties les plus critiques de votre travail d'IaC sont effectuées par des ingénieurs DevOps seniors.
Il est généralement judicieux d'avoir une équipe d'ingénieurs DevOps seniors (ou au moins un) chargée de diriger votre effort d'IaC. Cette équipe pourra se concentrer sur les meilleures pratiques et la sécurité et fournira ainsi un modèle à suivre pour les ingénieurs plus juniors. Il sera également en mesure d'écrire des modules génériques qui pourront être réutilisés dans les scripts IaC au sein de votre organisation, fournissant ainsi des blocs de construction pré-vérifiés facilement accessibles aux ingénieurs plus juniors.
Si la sécurité est importante, et elle l'est très probablement, cette équipe peut être chargée d'examiner les modules et les logiciels accessibles au public. Il est assez facile de trouver des modules IaC en ligne ; Terraform dispose même d'un dépôt officiel de ces modules. Toutefois, ces modules accessibles au public peuvent ne pas être conformes aux normes de sécurité appliquées au sein de votre organisation ou de votre projet. Il est donc important de veiller à ce que seuls des modules approuvés soient utilisés par votre équipe IaC.
En outre, il serait judicieux que votre équipe SecOps travaille aux côtés de votre équipe DevOps. Cette coopération permettra d'optimiser les processus DevOps en termes de sécurité dès le début du projet. Les erreurs détectées après un déploiement en production peuvent être très coûteuses, notamment en termes de relations avec les clients. Garantir une qualité élevée dès le début du processus permettra d'éviter un tel désastre.
Bien qu'il s'agisse d'un développement assez récent, l'IaC devrait aujourd'hui faire partie intégrante de la stratégie d'approvisionnement de toute organisation nécessitant des ressources cloud et devrait au minimum être évalué en vue de son inclusion dans vos équipes. Quelle que soit la taille de votre organisation, vous souhaitez très probablement que l'IaC gère au moins une partie de vos charges de travail.