In­fras­truc­ture as Code (IaC) : gestion d’in­fras­truc­ture in­for­ma­tique par Code

En matière d’in­fras­truc­ture in­for­ma­tique, il est aujourd’hui im­pos­sible de faire l’impasse sur un matériel vir­tua­lisé con­trô­lable via un logiciel. Les res­sources de stockage, de serveur et de réseau, voire des centres de calcul complets, peuvent être assemblés avec précision et mis à l’échelle à tout moment sans accès manuel aux machines con­cer­nées. Grâce aux services des four­nis­seurs d’in­fras­truc­ture en tant que service, il est même possible de louer le matériel né­ces­saire et sa gestion par logiciel à un prix avan­ta­geux, ce qui rend com­plè­te­ment superflu de posséder toute in­fras­truc­ture interne.

La gestion des dif­fé­rentes res­sources reste toutefois délicate, notamment en raison des exigences sans cesse crois­santes en matière d’in­fras­truc­ture in­for­ma­tique et du fait qu’on utilise souvent les services de plusieurs four­nis­seurs d’IaaS à la fois. C’est pourquoi le principe d’« In­fras­truc­ture as Code », également connu sous le nom d’« in­fras­truc­ture pro­gram­mable », connaît un véritable essor.

On entend par In­fras­truc­ture as Code, ou IaC, un paradigme in­for­ma­tique qui décrit dans un langage in­for­ma­tique non seulement les logiciels installés sur un système, mais aussi l’in­fras­truc­ture né­ces­saire à leur fonc­tion­ne­ment, comme l’espace de stockage, la puissance de calcul ou les res­sources de réseau. Le principe consiste à pro­gram­mer les struc­tures ma­té­rielles sous forme de code exé­cu­table pouvant être adapté, dupliqué, supprimé et segmenté à tout moment sans dif­fi­culté. Dans ce cadre, le concept d’In­fras­truc­ture as Code repose sur des tech­niques de Cloud modernes telles que la vir­tua­li­sa­tion et une gestion des res­sources définie par logiciel qui permet de gérer le matériel sans accès manuel aux pé­ri­phé­riques sous-jacents.

Au cours de ces dernières années, les exigences en matière de produits logiciels ont ra­pi­de­ment augmenté : cycles de dé­ve­lop­pe­ment de plus en plus courts, recherche d’un maximum de dis­po­ni­bi­lité et de flexi­bi­lité. En dehors de l’op­ti­mi­sa­tion du code, pour obtenir une structure glo­ba­le­ment per­for­mante, stable et surtout com­pé­ti­tive, il est né­ces­saire d’améliorer cons­tam­ment son in­fras­truc­ture ma­té­rielle en lui assurant une main­te­nance intensive. C’est ici qu’in­ter­vient l’In­fras­truc­ture as Code, un concept spé­cia­le­ment développé pour renforcer la qualité et l’ef­fi­ca­cité des in­fras­truc­tures. Parmi les objectifs et les tâches in­con­tour­nables de l’IaC, on trouve notamment :

• L’au­to­ma­ti­sa­tion maximale des processus,
• la sup­pres­sion des fron­tières entre les ap­pli­ca­tions et leur en­vi­ron­ne­ment d’exécution,
• la création d’un workflow flexible sim­pli­fiant la col­la­bo­ra­tion au sein de l’en­tre­prise pour tous les par­ti­ci­pants au processus de dé­ve­lop­pe­ment,
• la trans­pa­rence des mou­ve­ments de contenus et de leurs mo­di­fi­ca­tions, qui doivent être com­pré­hen­sibles à tout moment,
• la « tes­ta­bi­lité » des con­fi­gu­ra­tions ma­té­rielles, dans la même mesure que les logiciels.

Dans un en­vi­ron­ne­ment classique, non vir­tua­lisé, l’ensemble des res­sources est toujours di­rec­te­ment lié au matériel physique, ce qui entraîne non seulement un manque de flexi­bi­lité de l’in­fras­truc­ture, mais aussi la nécessité d’effectuer beaucoup de travail à la main en cas de chan­ge­ment de con­fi­gu­ra­tion.

Grâce à la vir­tua­li­sa­tion des serveurs, des mémoires et des struc­tures de réseau, la situation a con­si­dé­ra­ble­ment évolué : cette technique permet aux four­nis­seurs d’offrir à leurs clients des res­sources con­trô­lables de manière cen­tra­li­sée sans avoir à y allouer de matériel dédié. Cela garantit d’une part une fiabilité nettement plus élevée, puisque le matériel dé­fec­tueux peut par exemple être remplacé im­mé­dia­te­ment. Il est d’autre part nettement plus facile pour les deux parties d’ajouter de nouvelles res­sources ou de réduire les res­sources déjà louées.

Les en­vi­ron­ne­ments (définis par logiciel) vont plus loin que les in­fras­truc­tures vir­tua­li­sées tra­di­tion­nelles. Ils se dé­mar­quent par le fait que la logique de commande est com­plè­te­ment isolée des dif­fé­rentes com­po­santes ma­té­rielles et mise en œuvre dans un logiciel de contrôle central. Le four­nis­seur et le client peuvent fa­ci­le­ment maîtriser cette unité de contrôle grâce aux in­ter­faces et aux outils prévus à cet effet, assembler de façon en­tiè­re­ment in­di­vi­duelle les struc­tures in­for­ma­tiques et les mettre à l’échelle avec précision. Enfin, les deux parties ont l’avantage de bé­né­fi­cier de per­for­mances accrues du matériel, puisque celui-ci n’assure pas le trai­te­ment des données.

L’In­fras­truc­ture as Code utilise les tech­niques men­tion­nées pré­cé­dem­ment en au­to­ma­ti­sant la gestion commandée par logiciel des res­sources vir­tua­li­sées con­cer­nées afin d’exploiter plei­ne­ment le potentiel du Cloud. Par con­sé­quent, l’IaC ne doit pas être vue comme une al­ter­na­tive, mais comme un com­plé­ment ou une op­ti­mi­sa­tion de l’in­fras­truc­ture définie par logiciel.

L’In­fras­truc­ture as Code contribue de façon dé­ter­mi­nante à la sa­tis­fac­tion des exigences en matière de dé­ve­lop­pe­ment logiciel agile. Les mo­di­fi­ca­tions à apporter à l’in­fras­truc­ture sont réalisées grâce à des scripts pré­con­fi­gu­rés à une vitesse tout sim­ple­ment iné­ga­lable dans le cadre d’une gestion à la main. Dans ce contexte, il importe peu de savoir si les réglages doivent être effectués au milieu de la nuit, le week-end ou un jour férié. Les erreurs de saisie et de frappe étant exclues, le risque d’erreur diminue, en par­ti­cu­lier en ce qui concerne les étapes ad­mi­nis­tra­tives appelées à être fré­quem­ment répétées. En plus d’une vitesse élevée et d’un faible taux d’erreurs, l’In­fras­truc­ture pro­gram­mée présente par rapport à une ad­mi­nis­tra­tion manuelle les avantages suivants :

• Ef­fi­ca­cité élevée : l’IaC offre la pos­si­bi­lité d’au­to­ma­ti­ser la plus grande partie de la gestion des res­sources et contribue ainsi de façon dé­ter­mi­nante à l’op­ti­mi­sa­tion du cycle de dé­ve­lop­pe­ment logiciel.
   
• Réu­ti­li­sa­tion : dès que le code est écrit pour une in­fras­truc­ture, il peut être exécuté à tout moment et aussi souvent que né­ces­saire pour mettre l’in­fras­truc­ture en place. Il en va de même pour les en­vi­ron­ne­ments Sandbox pendant les phases de dé­ve­lop­pe­ment.
   
• Gestion des versions : là où l’on trouve du code, il est également possible d’en gérer les dif­fé­rentes versions. L’In­fras­truc­ture as Code permet ainsi d’assurer la do­cu­men­ta­tion et le suivi de toutes les mo­di­fi­ca­tions apportées à une in­fras­truc­ture. L’un des avantages est la pos­si­bi­lité de restaurer une con­fi­gu­ra­tion an­té­rieure sans dif­fi­culté.
   
• Réduction des coûts/charges : l’au­to­ma­ti­sa­tion de la gestion de l’in­fras­truc­ture permet d’éco­no­mi­ser beaucoup de temps et d’argent pour les réin­ves­tir avan­ta­geu­se­ment dans d’autres domaines.

Ce dernier avantage n’est toutefois pas sans res­tric­tions. En effet, il est réel lorsque l’en­vi­ron­ne­ment d’in­fras­truc­ture en tant que code est bien programmé, mais il ne faut pas négliger l’effort né­ces­saire à sa con­cep­tion et à sa mise en œuvre. Pour de nombreux ad­mi­nis­tra­teurs res­pon­sables, le modèle IaC implique des chan­ge­ments majeurs, car à défaut de com­prendre de manière ex­haus­tive le concept d’ar­chi­tec­ture de Cloud ou de posséder le savoir-faire né­ces­saire en matière de langages de pro­gram­ma­tion (Java, Node.js, Python, etc.) et d’uti­li­sa­tion des API, il est peu réaliste de vouloir passer à une in­fras­truc­ture au­to­ma­ti­sée. Il faut en effet s’attendre à des coûts re­la­ti­ve­ment élevés et à un effort d’in­té­gra­tion important, surtout au début.

Nous l’avons déjà mentionné au début de cet article : dans la plupart des cas, les en­tre­prises font appel aux services de plusieurs four­nis­seurs d’IaaS. Cela implique que les ad­mi­nis­tra­teurs doivent composer avec les par­ti­cu­la­ri­tés et surtout les dif­fé­rentes in­ter­faces des pla­te­formes utilisées. Il est également possible de faire appel à des outils ou des in­fras­truc­tures lo­gi­cielles d’IaC spé­ci­fiques qui proposent leurs propres langages de con­fi­gu­ra­tion pour pouvoir gérer les res­sources quel que soit le four­nis­seur, ce qui rend superflu d’avoir une con­nais­sance précise des API con­cer­nées. Les logiciels suivants font partie des solutions les plus ap­pré­ciées :

• Terraform : dis­po­nible en open source, la version de base de Terraform dé­ve­lop­pée par HashiCrop peut être té­lé­char­gée et utilisée gra­tui­te­ment. Deux éditions payantes proposent des fonc­tion­na­li­tés pour les ins­ti­tu­tions et les or­ga­ni­sa­tions ainsi que pour le travail en équipe.
   
• AWS Cloud­For­ma­tion : Cloud­For­ma­tion est l’outil d’IaC d’Amazon Web Services (AWS), ce qui le rend quasi in­dis­pen­sable quand on travaille avec les produits AWS tels que ELB, S3 ou EFS. Il n’y a pas de frais d’uti­li­sa­tion sup­plé­men­taires, de sorte que les uti­li­sa­teurs paient uni­que­ment pour les res­sources qu’ils réservent.
   
• Google Cloud De­ploy­ment Manager : Cloud­For­ma­tion est à AWS ce que De­ploy­ment Manager est à la pla­te­forme Cloud de Google. Les personnes tirant leurs res­sources d’IaaS de Google peuvent fa­ci­le­ment les gérer à l’aide de cet outil gratuit en utilisant des fichiers de con­fi­gu­ra­tion cen­tra­li­sés dans le langage de balisage YAML.
   
• Chef Infra : Chef Infra est la solution d’IaC de l’en­tre­prise amé­ri­caine Chef. Dis­po­nible depuis avril 2019 sous licence libre Apache 2.0, Chef Infra est notamment utilisé par Facebook. Parmi les pla­te­formes sup­por­tées, on peut citer Google Cloud, Microsoft Azure, Amazon EC2 et OpenStack.
   
• Red Hat Ansible Tower : Depuis 2015, l’outil d’In­fras­truc­ture as Code Ansible fait partie de la gamme de l’éditeur de logiciels Red Hat. Il offre un tableau de bord visuel, une invite de commande propre et une API REST per­for­mante. Les deux packs dis­po­nibles « Standard » et « Premium » sont cependant gratuits.

L’approche par in­fras­truc­ture en tant que code présente un intérêt pour toutes les en­tre­prises qui dé­ve­lop­pent et ex­ploi­tent des ap­pli­ca­tions complexes et dépendent donc d’une in­fras­truc­ture tout aussi complète et per­for­mante. Voici des raisons majeures en faveur de l’uti­li­sa­tion d’une in­fras­truc­ture pro­gram­mée :

• l’uti­li­sa­tion d’une vaste quantité de res­sources d’IaaS,
• l’in­fras­truc­ture est louée par de nombreux four­nis­seurs et de nom­breuses pla­te­formes dif­fé­rents,
• l’in­fras­truc­ture nécessite des adap­ta­tions ré­gu­lières,
• une bonne do­cu­men­ta­tion des mo­di­fi­ca­tions de l’in­fras­truc­ture est demandée,
• une col­la­bo­ra­tion optimale entre les ad­mi­nis­tra­teurs et les dé­ve­lop­peurs est souhaitée.

Les en­tre­prises pour­raient en principe pro­gram­mer leurs propres fichiers de con­fi­gu­ra­tion d’IaC, et certaines le font pro­ba­ble­ment en partie, mais l’uti­li­sa­tion des outils ou des in­fras­truc­tures lo­gi­cielles men­tion­nés plus haut fait partie du quotidien de tous les ad­mi­nis­tra­teurs qui tra­vail­lent avec des IaC. Plutôt que des exemples concrets d’In­fras­truc­ture as Code, les vidéos suivantes vous montrent pour finir comment pro­gram­mer le code de l’in­fras­truc­ture avec des outils d’IaC pratiques (dans le cas présent : AWS Cloud­For­ma­tion et Terraform).