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

Description du IaC

L’infrastructure as code (IaC), c’est la gestion de son infrastructure (réseaux, machines virtuelles, load balancer, etc…) via un modèle descriptif, le code. Plusieurs outils permettent de décrire son infrastructure avec du code. Ces outils peuvent être regroupés en plusieurs catégories :

• Outils d’approvisionnement : ces outils permettent de construire les ressources chez notre provider de cloud. ARM et Terraform sont dans cette catégorie.

• Outils de template de serveur : ces outils vont décrire ce qu’il y dans notre serveur et ce qui devra y être installé. Par exemple Packer et Docker sont des outils de templating de serveur.

• Scriptes Ad-Hoc : Bash, Python ou encore PowerShell rentrent dans cette catégorie. Ces outils étaient très populaires avant l’arrivée des systèmes comme ARM pour le déploiement des infrastructures. Mais ils restent toujours extrêmement utiles pour d’autres tâches. Ils peuvent être couplés à du Terraform pour effectuer des opérations sur les serveurs créés via un outil d’approvisionnement par exemple. Leur principale faiblesse est que pour le déploiement de ressource ils vont fonctionner de manière impérative (je dois décrire ce que je veux et comment je le fais) au contraire d’outils comme Terraform qui vont fonctionner sur un mode déclaratif (je décris ce que je veux et non pas comment le faire).

• Outils de gestion de configuration : Dans cette catégorie rentrent les outils destinés à configurer un serveur après son déploiement, comme l’installation et la configuration d’un serveur Apache par exemple. Ansible, Puppet et consort rentrent dans cette catégorie. Ils viennent en complément des outils d’approvisionnement pour finaliser la configuration de nos environnements.

Ces outils nous permettent d’utiliser les mêmes concepts que pour stocker du code source mais afin de versionner et d’historiser son infrastructure.

On voit tout de suite un des intérêts majeurs du IaC c’est que notre infrastructure va pouvoir être gérée exactement pareil que notre code source et donc évoluer en parallèle de celui-ci. Que le code de notre infra soit stocké dans le même repo ou pas chaque version du code source déployé est associée à une version de notre IaC.

Une des utilités majeures du IaC c’est que l’on peut décliner nos environnements sans effort et avec la garantie qu’ils seront strictement identiques. Dans un mode classique ou l’infra est déployée à la main plus le projet avance et évolue plus l’infrastructure se complexifie. Il devient donc de plus en plus compliqué de redéployer un environnement sans faire d’erreur de configuration. Le concept clé du IaC est l’idempotence, en effet un script de déploiement configure toujours l’environnement de la même façon peu importe l’état de départ de l’environnement. Cela nous permet d’être sûr que le résultat du déploiement sera toujours identique ce qui n’est bien évidemment pas le cas avec des déploiement « manuel ».

L’autre avantage du IaC, vu que c’est du code, c’est qu’il peut être industrialisé de la même façon que notre code, dans Azure Dev Ops par exemple, nous verrons cela en fin d’article.

Présentation de Terraform

Terraform est un outil permettant de faire du IaC pour quasiment tous les providers de Cloud du marché. Mais attention il ne faut pas se laisser berner par l’intitulé de certains articles qui décrivent Terraform comme un outil agnostique de la plateforme de cloud.

Il est vrai que l’on peut déployer pour différents fournisseurs de cloud mais nous devrons réécrire le script si l’on veut déployer la même infra dans Azure et ensuite dans AWS. Par contre il permet de déployer des infrastructures hybrides qui reposent sur plusieurs fournisseurs de Cloud différents en utilisant le même outil.

Terraform repose sur le langage HCL (HashiCorp Configuration Language) qui est un langage de configuration qui a pour philosophie d’être lisible par les humains mais aussi facilement interprétable par la machine.

Le gros point fort de ce langage est donc ça lisibilité, comparé à du JSON qui est très souvent le langage prédominant pour faire du IaC (ARM repose sur la syntaxe JSON).

Ci-dessous déclaration d’une ressource identique en HCL puis en JSON, on voit tout de suite qu’en HCL on est beaucoup plus succins.

variable "ami" {
    description = "the AMI to use"
}

Ex. HCL

{
  "variable": {
      "ami": {
          "description": "the AMI to use"
        }
    }
}

Ex. JSON

La structure de la syntaxe HCL est extrêmement simple, elle se compose d’un élément, d’un type (en Terraform ce sera le type de ressource à déployer comme un « App Service » ou un serveur SQL par exemple) et d’un nom. L’identifiant de notre bloc est la composition de son type et de son nom. Cela nous permet d’avoir plusieurs blocs avec le même nom à partir du moment où ils ont un type différent.

En Terraform cela nous permettra de nommer de manière identique des ressources liées, par exemple pour monter une BDD SQL on doit monter un serveur SQL puis créer la base en elle-même. Dans ce cas on pourra créer ces 2 ressources avec le même nom car elles sont de type différent cela rends le script plus lisible. A noter qu’ARM nous permet de faire la même chose.

Terraform repose sur un système de providers, ce sont des plugins qui étendent les possibilités de l’outil pour interagir avec les fournisseurs de cloud de différentes manières.

Terraform propose un certain nombre de providers clé en main. Ce sont ces providers qui nous permettent d’utiliser de multiples fournisseurs de Cloud et si notre fournisseur de Cloud préféré n’a pas de provider alors il est possible d’en créer, à condition de savoir coder en Go.

En résumé un provider c’est une façade aux API de Déploiement/Management des fournisseurs de Cloud.

Les deux providers Azure suivants sont fournis par Terraform et permettent d’effectuer quasiment toutes les opérations de déploiement dans le cloud de Microsoft :

• AzureAD : Ce provider permet de gérer tout ce qui se passe dans l’AD comme la création de Groupe, service principal et autres ressources liées à l’AD.

• AzureRM : Ce provider permet de gérer toutes les autres ressources Azure comme les App Services, les serveurs SQL et tout ce qui n’est pas lié à l’Active Directory.

Si des services Azure n’ont pas encore de ressource associée dans Terraform il y a toujours la possibilité de la créer en utilisant un template ARM. Le provider AzureRM nous expose une ressource azurerm_template_deployment qui prends en charge le déploiement de template ARM.

Terraform VS ARM

Là vous vous dites peut-être mais pourquoi utiliser Terraform plutôt qu’Azure Ressource Manager (ARM) si on déploie toute notre infrastructure dans Azure. Mais contrairement à ARM Terraform va nous fournir des outils pour (en plus de ceux pour le déploiement) :

• Valider les déploiements avant d’appliquer les changements
• Détruire les ressources d’un déploiement antérieur

Le premier point est que Terraform va nous offrir la possibilité de changer notre fournisseur de Cloud assez simplement, on doit simplement récrire notre infra avec des providers différents, et surtout sans avoir à apprendre et maitriser un nouveau langage « propriétaire », en effet ARM ne permet que de déployer dans Azure.

Un autre point positif est son intégration dans les éditeurs de code, notamment VS Code, qui nous met à disposition des plugin-in pour de la coloration syntaxique, de l’auto-complétion, et j’en passe. Sur ce point ARM est au même niveau et on retrouve le même genre d’outils dans VS Code.

Le dernier point est plus subjectif mais la syntaxe HCL est quand même, je trouve, beaucoup plus simple à lire et à écrire. Du coup ça pèse forcément un peu dans la balance quand on doit choisir un outil. De plus vu que l’on n’est pas sur du JSON on va pouvoir ajouter des commentaires, plutôt pratique quand on commence à avoir une infrastructure très complexe. Mais si vous êtes un vrai fan du JSON Terraform est aussi compatible avec la syntaxe JSON !

ARM n’est absolument pas un mauvais choix si l’on reste sur Azure dans la mesure où il permet de déployer TOUS les types de ressources Azure contrairement à Terraform, même si ce point est à tempérer dans la mesure ou Terraform nous met à disposition un provider pour les templates ARM. ARM a quand même quelques défauts par exemple nous n’avons pas la possibilité d’alimenter un secret dans un KeyVault directement on est obligé de passer par un scripte. Je mets un point d’attention particulier sur ce sujet car maintenant dans n’importe quel infrastructure un minimum sécurisé dans Azure on a un KeyVault derrière qui va protéger toutes les variables de configuration sensibles.

Terraform nous apporte plus de flexibilité, car Terraform nous permet d’écrire des conditions ou de faire des boucles, ce qui va nous aider dans le cadre d’infra de grande envergure, le tout avec une syntaxe plus intuitive et compréhensible.

De plus il existe énormément de ressources sur Terraform (compilation d’articles sur Terraform) quel que soit le provider utilisé là où j’ai trouvé moins de ressources intéressantes sur ARM (même si la doc Microsoft est assez complète sur le sujet). A savoir que Microsoft soutient Terraform et a très souvent promu cet outil, en atteste les pages de documentation officielle écrite par Microsoft. Il est aussi pré-installé dans l’Azure Cloud Shell.

Si l’on devait trouver des points négatifs sur Terraform ce serait sans doute le fait qu’il y ait beaucoup de bugs ouverts dans GitHub et le fait qu’il soit non transactionnel donc si j’ai 9 ressources sur 10 qui ont été créées mon plan est en échec mais il n’a pas rollback la création des 9 ressources. Mais c’est un faux problème dans la mesure où Terraform garde l’état de notre infra et dans ce cas il suffirait de relancer le plan une deuxième fois et il ne lancera que la création de la ressource qui a échouée précédemment.

Pourquoi mettre en place Terraform ?

Avant on avait des équipes d’opérationnels dédiées au déploiement de nos applicatifs dans la mesure où il fallait souvent déployer un serveur, le configurer, le connecter au réseau puis ensuite seulement on passait au déploiement de notre applicatif à proprement parlé. Mais maintenant de plus en plus d’entreprise migre leur SI dans le cloud afin de réduire ces coûts de déploiement et de gestion des serveurs. Dans ce contexte là les opérationnels ne manipule plus les machines directement mais passent donc par les outils du fournisseur de cloud pour les gérer. Dorénavant beaucoup d’opérationnels se retrouvent donc à écrire du code pour construire leur infrastructure. Et c’est là que Terraform intervient et va apporter toute sa puissance et sa flexibilité, comme c’est du code tous les avantages qui vont s’appliquer pour la gestion de code source va s’appliquer pour notre IaC :

• Version Control : notre infrastructure va donc être historisé et l’on pourra suivre son évolution simplement. Et puis chaque changement dans l’infra sera identifié par un commit donc on pourra facilement identifier une erreur de configuration et revenir à un état fonctionnel de notre infrastructure.

• Validation : des codes review peuvent être mise en place afin de réduire au maximum les petites erreurs de configuration. On peut lancer des outils de validation sur le code pour s’assurer du bon fonctionnement de notre infra.

• Réutilisation : on peut packager notre infrastructure en module réutilisable afin de partager des descriptions d’infrastructure entre nos différents applicatifs.

• Industrialisation : notre infra peut donc maintenant être industrialisée notamment avec des outils comme Azure Dev Ops. Le déploiement de notre infrastructure pourra donc être entièrement automatisé !

D’un point de vue organisationnel les avantages d’utiliser des process DevOps, comme le IaC, sont assez flagrants selon le rapport « 2017 State of DevOps Report » les entreprises qui mettent en pratique le DevOps réduisent de 5 fois leur taux d’échec après un changement tandis que le « Mean time to recover » (MTTR) est 96 fois supérieur à une entreprise qui n’a pas mise en place la philosophie DevOps. Ces chiffres ne sont pas à attribuer uniquement à l’adoption du IaC (qui n’est qu’une partie des process DevOps) mais il y contribue très fortement. Le IaC va aussi nous permettre de faire évoluer notre infra beaucoup plus vite, il nous suffit d’écrire ce dont on a besoin et ce sera automatiquement appliqué au prochain déploiement (à condition d’avoir industrialisé cela) plus besoin de faire des demandes au service Infra pour monter telle machine ou augmenter la taille de la BDD cela simplifie et fluidifie l’évolution continue de notre Infrastructure, si la philosophie Dev Ops est clairement adoptée par l’organisation, afin de toujours répondre aux besoins de notre produit et de nos clients/utilisateurs.

Du point de vue d’un développeur le IaC a aussi beaucoup d’avantages, il peut être utilisé pour créer des environnements disposables pour des démos ou encore de fournir des logiciels en mode Black Box on déploie l’infra et l’application directement depuis le code on n’a pas besoin de se préoccuper de comment l’héberger tout est décrit dans notre IaC.

La suite

Nous avons vu ensemble ce qu’était l’Infrastructure As Code. Nous verrons dans un prochain article comment mettre en pratique Terraform en créant et déployant une infrastructure dans Azure.

Partie 1 : C’est quoi l’Infrastructure As Code (IaC)
Partie 2 : Création d’un plan Terraform pour Azure
Partie 3 : Industrialisation d’un plan Terraform dans Azure Dev Ops