Infrastructure As Code & Cloud

Basculer l’ensemble de son parc informatique dans le cloud est un chantier massif qui peut être long, si l’industrialisation n’est pas au rendez-vous. On entend beaucoup parler du DevOps et de sa mise en pratique sur le Cloud, et concrètement, c’est là que l’Infrastructure As Code entre en jeu. Le IaC est une nouvelle façon de mettre à disposition des infrastructures de manière industrialisée et rapide en mode DevOps.

C’est quoi l’Infrastructure As Code (IaC) ?

Le IaC permet de gérer et provisionner les ressources chez les Clouders et dans les datacenters.

Grâce au scripting des configurations pour provisionner des ressources physiques ou virtuelles, il est possible de rejouer indéfiniment les procédures d’approvisionnement, et d’obtenir le même résultat à chaque fois. Ce qui est très intéressant dans une démarche DevOps, pour provisionner différents environnements jusqu’à la production, en supprimant les actions humaines, en simplifiant et en accélérant la démarche.

Le IaC a pour objectif de réduire le temps de fournitures de ressources de l’infrastructure réalisé manuellement et surtout de l’automatiser. En effet, lors de la première initialisation, le IaC prend du temps afin de réaliser les scripts d’automatisation de provisionning mais lors des prochains provisionnings, la mise à disposition sera rapide et fiable.

Le IaC est apparu avec les offres Cloud public qui devaient proposer de base quelque chose de nouveau répondant à de nouvelles attentes des métiers vis-à-vis du SI. Cette réponse a été d’offrir des services standardisés et automatisés répondant immédiatement aux demandes des utilisateurs. Tout ceci est associé à des portails APIsables pour intégrer les processus du IaC directement. Par exemple, utilisation de Terraform avec une Cloud Management Plateform.

 

Qui est la cible du IaC ? Dans quel cas l’utiliser ?

Les utilisateurs du IaC sont des entreprises qui ont intégré le DevOps dans les process de leur SI et dans lesquelles l’infrastructure ne doit plus être un frein mais être agile, capable de s’adapter aux nouveaux usages.

La mise en œuvre du IaC dans un SI dépend surtout des besoins du métier. Ainsi, suivant la variabilité et le besoin de réactivité du métier, le IaC sera plus ou moins rentable.

Prenons quelques cas : lors d’une migration massive d’application sur différents clouders, il est intéressant d’avoir une partie “automation” avec du IaC afin de pourvoir faire du “create & destroy” de ressources selon les besoins des développeurs et des évolutions, maintenances sur l’application.

IaC va également de pair avec le provisionnning des infrastructures Cloud.

Quels outillages ?

Le concept général de IaC ainsi que les outils disponibles ont atteint un stade de maturité avancé.

Il existe maintenant un certain nombre d’outils disponibles pour adopter l’Infrastructure As Code qui diffèrent largement par leur utilisation et leurs fonctionnalités. Vous trouverez ci-dessous un aperçu général des outils disponibles pour la construction et la gestion de IaC. Les forums (stackoverflow…) et les pages GitHub abondent d’informations, de documentation. Par conséquent, adopter le IaC est beaucoup plus facile qu’il ne l’était autrefois.

https://landscape.cncf.io/images/landscape.png

Voici un zoom sur quelques outils :

Puppet/Chef

Chef a été développé dans l’optique d’une collaboration rapide entre les membres d’une équipe. Il s’agit donc d’un atout dans le contexte DevOps, tandis que Puppet a évolué en ciblant l’automatisation des processus, ce qui le rend utile pour la création rapide d’une nouvelle infrastructure répondant aux exigences du client.

 

Ansible

Ansible, outil de gestion de configuration Open Source très répandu, dispose de modules nécessaires pour créer une infrastructure chez un grand nombre de Clouders indépendamment de ce dernier.

En effet, Ansible est compatible SSH (linux) ou WinRM (Windows) avec un code écrit en YAML. Ansible a comme objectif principal la création de l’infrastructure et non la gestion de celle-ci.

https://www.ansible.com

Parmi les autres solutions, on peut citer l’outil Open Source Terraform, l’outil IaC d’Amazon Web Services Cloud Formation, ou encore l’implémentation IaC de Microsoft Azure ARM Templates.

Terraform 

Terraform est un outil Open Source, stateful et multi-fournisseurs qui permet de piloter les provisionnements de services cloud via des API à base de fichiers de configuration Terraform afin de permettre aux équipes de créer et de gérer des infrastructures à grande échelle. Terraform est compatible avec le cloud, tout en prenant en charge les fournisseurs proposant des services SaaS ou des outils d’orchestration de container, par exemple : StatusCake et Kubernetes.

https://www.hashicorp.com/products/terraform/multi-cloud-compliance-and-management

Terraform est largement pris en charge par les outils de cloud et DevOps et le référentiel de modules Terraform comprend un grand nombre de modules pré-écrits que vous pouvez simplement remplir avec vos variables d’entrée pour créer et gérer votre infrastructure. Lors de la construction et de la maintenance de l’infrastructure, Terraform nécessite une approbation avant d’appliquer des modifications destructives, ce qui ajoute une sécurité en cas d’erreur de lancement. Lorsque vous quittez un environnement précédemment non IaC, il est possible d’importer vos ressources existantes dans Terraform pour poursuivre la gestion. Il s’agit toutefois d’une tâche très manuelle et fastidieuse, mais néanmoins possible.

https://www.terraform.io

CloudFormation

L’outil d’infrastructure chez Amazon Web Services, écrit en JSON et exécuté via la console AWS ou l’AWS CLI, vous permet de créer et de gérer votre infrastructure sous forme de code dans AWS. AWS fournit un grand nombre de modèles qui peuvent être utilisés pour démarrer CloudFormation, il est donc très facile d’être opérationnel.

https://aws.amazon.com/cloudformation/

 

 

ARM Templates

Les modèles ARM sont l’implémentation de IaC par Microsoft Azure, ils permettent de provisionner des ressources Microsoft Azure à l’aide d’un modèle déclaratif. Non stateful et pas compatible multi-cloud, il permet donc simplement de construire des infrastructures dans Azure et non la gestion.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview

REX d’outils

Chez un de nos grands clients, qui a fait le choix de s’orienter sur une plateforme multi-clouders, tout en conservant un datacenter privé, le choix d’utiliser Terraform a été fait dans l’objectif d’harmoniser les scripts de création d’infrastructures.

En revanche, le couple Terraform et un Cloud Management Plateform (vRealize Orchestrator de VMWare dans notre cas) s’est avéré obligatoire. Fonctionnellement, “les CMP combinent à minima une interface de pilotage en self-service, un système de provisioning, une console de suivi de la consommation des clouds et de la facturation associée, ainsi qu’un moteur pour optimiser les traitements informatiques (ou workloads) et in fine, les coûts”, indique Gartner et c’est effectivement ce que l’on attend d’un CMP !

Terraform apporte une réponse efficace sur le volet scripting, mais l’approche CMP va bien au-delà, et propose un environnement homogène en matière de gestion d’infrastructure cloud. Terraform, Ansible ou Puppet sont des outils qui peuvent venir se connecter en fonction des choix et besoins des clients.

Pour VMware, il existe des fournisseurs pour vSphere, NSX-T et vCloud Director, qui peuvent être utilisés pour gérer de nombreux aspects d’un environnement basé sur VMware. Avec vSphere Provider et Terraform, par exemple, on peut écrire un fichier Terraform décrivant une machine virtuelle, un service PaaS… et appliquer ce fichier Terraform pour créer x machines virtuelles sur le même modèle.

Le CMP peut être utilisée par un public ne connaissant que faiblement les offres des clouders et les infrastructures. L’interface permet de faciliter les demandes de provisionning par les DSI,  les développeurs et les Ops. Alors que la création de scripts Terraform et le lien avec les API du CMP seront réservés aux Ops.

Quelques liens pour approfondir le sujet :

https://learn.hashicorp.com/terraform/getting-started/install.html

https://www.hashicorp.com/blog/using-infrastructure-as-code-to-automate-vmware-deployments

Et les tests de IaC ?

Il existe, par exemple, pour les scripts Terraform, développé par Gruntwork partenaire de HashiCorp, Terratest, qui est implémenté sous forme de bibliothèque Go permettant d’écrire et d’automatiser des tests pour le IaC. Terratest fournit une collection de fonctions et de modèles pour les tâches de test d’infrastructure courantes.

Si vous voulez tester l’outils, vous pouvez regarder ici.

Un des risques est d’avoir des ressources conservées après plusieurs tests avortées et donc d’avoir des instances non utilisé parmi celles qui sont vraiment utilisés. Gruntwork propose un outil, Cloud Nuke qui nettoie l’environnement de ces instances non utilisées.

https://github.com/gruntwork-io/terratest

Ce mode de testing est comme du testing de code applicatif où on simule chaque comportement d’infrastructure pour valider les solutions définies. L’avantage du IaC est de pouvoir régénérer indéfiniment des scénarios de tests, dans un cadre de non régression par exemple.

Bénéfices VS Risques

L’Infrastructure as Code apporte plusieurs bénéfices. Le IaC permet de :

  • Réduire le « shadow IT « , à savoir l’utilisation des systèmes informatiques sans l’approbation explicite de l’entreprise notamment par le département IT. La plupart du temps, le shadow IT est dû à l’incapacité du département IT à réagir à temps pour répondre aux besoins des métiers concernant les améliorations des systèmes et de l’infrastructure. Ceci peut poser d’importants risques de sécurité et des coûts imprévisibles pour l’entreprise. Le IaC permet de réagir plus rapidement, et par extension, de réduire les coûts, de renforcer la sécurité, et d’assurer le respect des schémas directeurs IT de l’entreprise,
  • Améliorer la satisfaction client en permettant à l’entreprise de proposer un service de qualité dans un délai court.
  • Réduire les OPEX, puisque l’entreprise est en mesure de déployer une infrastructure entièrement testée et conforme, en quelques minutes, sans intervention humaine. Ceci permet de réaliser des économies importantes en termes de temps de travail et de risques financiers potentiels. De même, le fait qu’un développeur puisse accomplir seul les tâches de plusieurs membres de l’équipes, particulièrement dans un contexte DevOps, permet de réduire les coûts OPEX,
  • Standardiser les infrastructures, le IaC permet de réduire les configurations manuelles non conforme au standard,
  • Portabilité de l’infrastructure avec Terraform.

Malgré ses nombreux avantages, l’Infrastructure as Code présente aussi des risques. On peut évoquer :

  • Le risque d’une mauvaise planification: mettre en place un IaC requiert de définir une infrastructure qui permettra l’implémentation, la configuration et l’exploitation des outils IaC,
  • Le besoin de nouvelles compétences. Une certaine expertise est nécessaire pour maîtriser les outils, qui nécessite du temps d’apprentissage et de formation,
  • La réplication d’erreur. Sachant que le code initial est développé, il y a toujours un risque qu’il contienne des erreurs mineures qui ne produiront un impact qu’après un certain temps. Malheureusement, pendant ce temps, plusieurs machines pourront avoir été créées automatiquement,
  • Un risque de destruction accidentelle puisque certains outils ont la capacité de détruire automatiquement des ressources.

Et le FinOps dans tout ça ?

Comme on a pu le voir, au travers de l’article, le IaC permet de provisionner et détruire de manière automatique les ressources, les infrastructures, mais, comment faire pour s’y retrouver dans les CMDB, et visualiser les coûts engrangés par ses derniers ?

L’étiquetage lors du scripting (par exemple, via Terraform) s’avère donc obligatoire, afin de pouvoir optimiser les coûts, et connaitre le coût de chaque ressource pour pouvoir ensuite refacturer l’utilisation de ressources à une autre entité/service de l’entreprise.

Dans une démarche de create & destroy, le IaC est la solution adéquate qui répond au besoin. Cependant, il faut noter que dans une infrastructure Cloud, un certain nombre de ressources et de coûts associés resteront fixes et ne pourront pas être détruits à la volée.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *