Pourquoi adopter l’Infrastructure as Code (IaC) ?
Editions ENI
🔎 Créateur de contenus de #formation à l’#informatique, livres, vidéos, eformations, certifications, webinaires...📚
Ce mois-ci est sorti mon livre « L’infrastructure as Code avec Terraform - Déployez votre infrastructure sur le Cloud » qui est le fruit de mon expérience d’architecte solutions qui m’a régulièrement amené à développer des plateformes composées de dizaines de modules Terraform. Cette solution propose à mes yeux de nombreux avantages, raison pour laquelle, entre autres, j’ai écrit cet ouvrage.
Mais tout le monde ne connaît sans doute pas l’IaC et ses notions tout comme le chemin de mise en place stratégique de Terraform. Détaillons un peu…
Par 🤘 Julien Wittouck , architecte solution, développeur indépendant et auteur aux Editions ENI
L’Infrastructure as Code est la pratique consistant à créer des ressources informatiques et gérer une infrastructure virtuelle, sur un Cloud public ou privé ou on-premises, à l’aide de code, plutôt qu’avec des procédures manuelles.
Les ressources créées peuvent être de tout type. Parmi les types de ressources courants, on retrouve très souvent des machines virtuelles, bases de données, réseaux, clusters Kubernetes, etc.
En s’appuyant sur les APIs fournies par les différents services Cloud, on retrouve plusieurs types de pratiques autour de l’IaC comme :
Les avantages de l’infrastructure as code
Utiliser l’infrastructure as Code et l’automatisation présente de nombreux avantages pour les entreprises, comme la réduction des erreurs, une implémentation standardisée et donc un respect de la conformité et des règles de sécurité. Cette pratique apporte également de l’agilité à l’entreprise en facilitant les expérimentations et en accélérant la création des environnements.
Réduction des erreurs
L’automatisation de la création de l’infrastructure par du code a pour avantage principal la réduction des erreurs humaines.
Lors de la création ou de la gestion d’une infrastructure à la main, par exemple en utilisant la console web d’un service Cloud et en suivant des procédures documentées, il y a de nombreuses occasions où des erreurs de configuration peuvent survenir : mauvaise configuration d’environnement, oubli d’étapes ou de paramétrages, etc.
Les impacts d’une erreur de configuration peuvent alors être multiples : nécessité de recréer les environnements avec la perte de temps associée, coûts financiers liés à des ressources créées avec une mauvaise configuration ou liés à l’oubli de la suppression d’une ressource, mauvaise implémentation de règles de sécurités pouvant aboutir à l’exposition d’une faille de sécurité.
Développer son infrastructure en la scriptant ou avec Terraform permet de limiter les erreurs liées à une mauvaise configuration, ou à la répétition de manipulation.
Conformité et standardisation
L’utilisation de code pour créer les ressources Cloud permet également de garantir la conformité des environnements.
Les règles de nommage, de dimensionnement, de sauvegarde, de sécurité, sont implémentées directement par le code. La mise en place de modules (pensez scripts partagés ou librairies) réutilisables dans les entreprises permet de déployer les différents environnements en garantissant le respect des règles de conformité et de bonnes pratiques.
La mise en place d’une stratégie d’utilisation de l’IaC, comme l’obligation d’utiliser Terraform pour gérer certaines ressources, permettra donc de s’assurer de la conformité des environnements. Lorsqu’une nouvelle règle doit être mise en place, il est également facile de la propager à tous les environnements existants, via la mise à jour du code des modules.
Collaboration
L’utilisation de l’IaC permet également de faciliter la collaboration entre les équipes.
Le code est alors archivé dans un système de gestion de version comme Git. Les équipes peuvent collaborer facilement. Les modifications du code source sont archivées, ce qui facilite l’audit de l’infrastructure et la bonne compréhension des changements qui lui sont apportés.
Cette collaboration via Git peut également suivre les bonnes pratiques issues du monde du développement : messages de commits clairs, processus de relecture de code par un pair, versionning avec SemVer, publication de versions automatisées avec des pipelines d’intégration continue, etc.
Rapidité d’exécution et agilité
L’automatisation apportée par l’IaC permet également de réduire le temps nécessaire à la création des environnements.
Le surcoût lié au temps passé à l’écriture de code par rapport à une exécution manuelle est très vite amorti lorsque plusieurs environnements identiques doivent être créés comme c’est souvent le cas : développement, staging / testing, pré-production, production, en fonction des règles de nommage.
Une fois le code écrit, des environnements peuvent alors être construits en quelques minutes, ce qui permet des cycles de développement plus rapides. À titre d’information, la création d’une machine virtuelle prend alors environ 1 à 2 minutes en fonction des services Cloud, la création d’une base de données entre 5 à 10 minutes.
Les entreprises peuvent alors gagner en agilité, en pouvant accélérer les déploiements des produits, expérimenter des solutions et répondre plus rapidement aux changements.
La mise à disposition de modules pré-développés, en self-service pour les développeurs et opérateurs des équipes permet également de donner l’autonomie dont les équipes manquent parfois, quand les équipes responsables de l’infrastructure forment un goulet d’étranglement.
IaC et Terraform
Terraform se distingue des autres outils d’infrastructure as code par plusieurs aspects : sa facilité d’installation, l’approche déclarative avec son langage, et son aspect multi-cloud.
Parmi les outils d’infrastructure as code, on retrouve les différents CLI des services Cloud, souvent écrits en Python, qui nécessitent un environnement parfois compliqué à installer (qui n’a jamais souffert d’une cohabitation compliquée entre les version 2 et 3 de Python ?) et sont parfois lents à l’exécution. Terraform se distingue des outils de type CLI par sa facilité d’installation (1 unique binaire), ainsi que sa rapidité d’exécution, étant un binaire compilé.
L’approche déclarative de Terraform est également en opposition aux CLI des services Cloud et aux approches de scripting. Dans les approches de scripting impératives, les Ops développent des scripts qui exécutent les différentes étapes permettant d’atteindre l’état souhaité. En Terraform, on déclare l’état souhaité de l’infrastructure, c’est Terraform qui se charge de déterminer l’ordre de création ou de modifications des ressources en fonction de leurs dépendances.
D’autres outils utilisent également l’approche déclarative, en particulier les outils de provisioning des Clouds américains, comme AWS CloudFormation, GCP Deployment Manager ou Azure Resource Manager. Ces outils utilisent souvent une syntaxe à base de JSON ou de YAML pour la déclaration des ressources à manipuler.
A l’opposé de ces outils, Terraform propose son propre langage, nommé HCL (pour HashiCorp Configuration Language), qui se veut plus lisible et structuré que du JSON ou du YAML. Il permet également l’utilisation de références, fonctions et boucles. Étant un langage propre, il bénéficie à travers le CLI Terraform d’un outil de validation de structure et les différents IDE ont implémenté la coloration syntaxique du langage, ainsi que de la complétion automatique pour faciliter le développement.
Enfin, les CLI des Clouds ou les outils de provisioning des différents Clouds ont un défaut majeur : ils ne peuvent manipuler que des ressources sur leur propre Cloud. Il est rare qu’une entreprise ne consomme des ressources d’un unique service Cloud. Beaucoup d’entreprises ont des zones DNS chez un fournisseur, des ressources sur un Cloud public, des bases de données managées chez un autre fournisseur, etc.
Terraform permet de créer de l’infrastructure sur tout type de fournisseurs Cloud, en utilisant le même langage quel que soit le Cloud cible. Il est possible dans le même code de faire cohabiter des ressources de plusieurs Cloud différents. Contrairement à ce qui est parfois imaginé, le code Terraform n’est pas “portable”. Du code écrit pour provisionner de l’infrastructure sur un Cloud public ne pourra pas être réutilisé tel-quel pour un autre Cloud. Ce serait ignorer les différences qui peuvent exister entre tous les fournisseurs. Néanmoins, avec l’utilisation de Terraform, les processus de développement, langages et pratiques seront identiques lors d’une migration d’un Cloud à un autre, ou lors de l’ajout d’un nouveau service Cloud.
La mise en place de Terraform
Stratégie et Architecture
L’utilisation de Terraform ne dispense pas de connaître le service Cloud que l’on souhaite utiliser. La conception de l’architecture Cloud reste une étape cruciale : règles IAM, construction des réseaux, VM, load-balancers, bases de données, clusters Kubernetes, etc. L’entreprise doit définir sa stratégie d’IaC en déterminant si Terraform sera utilisé pour gérer tout l’environnement, ou seulement certaines parties. Par exemple, l’affectation des droits d’accès des utilisateurs à la plateforme Cloud peut être gérée dans un processus d’enrôlement manuel, le socle du Cloud (parfois appelé Landing Zone ou Fondations) peut aussi parfois être créé manuellement.
À partir de cette stratégie, il sera possible de déterminer quel découpage pourra être effectué au niveau du code Terraform, et quels modules réutilisables devront être implémentés. Les ressources les plus courantes pourront être implémentées dans des modules : VMs, base de données managées, clusters Kubernetes, buckets de stockage objet, etc.
Une fois la stratégie et l’architecture définies, il sera possible de mettre en place le socle de développement Terraform, avec la configuration des providers et des backends.
Configuration des providers et backends
La première étape consiste à installer Terraform sur les postes des développeurs et opérateurs en suivant la documentation officielle ou en utilisant l’outil tfenv.
La configuration des providers est alors le point de départ des développements Terraform. Pour pouvoir appeler les API des Cloud Providers, Terraform aura besoin d’accès via des clés d’API, comptes de services. Ces accès seront souvent associés à un rôle ayant des droits haut-niveau, administrateur, éditeur, etc. en fonction des différents Clouds.
Pour configurer un provider, on peut se référer à la documentation officielle de Terraform. La bonne pratique de configuration des providers consiste à privilégier l’utilisation de variables d’environnement, en évitant de positionner des secrets directement dans le code source.
Voici un exemple de configuration pour le provider Scaleway :
terraform {
required_providers {
scaleway = {
source = "scaleway/scaleway"
}
}
required_version = ">= 1.8"
}
provider "scaleway" {
zone = "fr-par-1"
region = "fr-par"
}
Une fois le ou les providers configurés, l’étape suivante va être de constituer une stratégie de stockage du code Terraform et de son state pour permettre la collaboration. Une bonne pratique consiste à découper le code en projets distincts, par application et par environnement. Pour chacun des projets, un backend devra être configuré pour y stocker le state Terraform (Bucket S3, Azure Blob Storage, Bucket GCS, HCP Terraform, etc.).
Voici un exemple de configuration de backend qui stocke le state Terraform dans un bucket GCS (Google Cloud Storage) :
terraform {
backend "gcs" {
bucket = "terraform-state-bucket"
prefix = "terraform/state"
}
}
L’utilisation d’un backend nécessite également des informations d’authentification qui peuvent être différentes de celles du provider.
Ces configurations devront être faites dans l’ensemble des projets Terraform. Certaines entreprises mettent à disposition des squelettes de code avec cette configuration minimale pour permettre aux équipes de démarrer des nouveaux projets rapidement !
Les premiers modules
Le code Terraform pourra également être organisé en modules réutilisables. Dans ce cas, les modules devront suivre la structure de répertoires standard :
my-module/
├── main.tf
├── variables.tf
├── outputs.tf
├── versions.tf (facultatif)
├── README.md
└── examples/
└── example_usage.tf
Cette structure standardisée est un bon point de départ pour les développements d’un module.
Les modules peuvent alors être développés !
Les modules exposent des entrées et sorties, variables et outputs, dont les valeurs sont utilisées dans le code. Voici à titre d’exemple un extrait du code d’un module qui crée une base de données sur Scaleway (le code complet est disponible sur GitHub) :
variable "instance_type" {
description = "type of the node of the instance"
type = string
default = "DB-DEV-S"
}
resource "scaleway_rdb_instance" "this" {
name = var.instance_name
node_type = var.instance_type
engine = "PostgreSQL-15"
is_ha_cluster = var.activate_ha
disable_backup = var.disable_backup
}
La publication des premiers modules pourra alors être faite sur le registry HashiCorp officiel, dans un repository GitLab, ou bien dans un registry privé sur HCP Terraform ou JFrog Artifactory par exemple.
Une fois les modules mis à disposition des équipes, leur utilisation se fait avec un bloc module :
module "postgresql-instance" {
source = "CodeKaio/postgresql-instance/scaleway"
version = "0.0.2"
instance_name = "my_database"
instance_type = "DB-DEV-S"
activate_ha = false
disable_backup = true
}
Enrichir l’outillage
Une fois Terraform en place et les premiers modules développés et utilisés, il pourra être intéressant d’enrichir l’outillage pour générer automatiquement la documentation des modules, écrire des tests d’intégration, ou intégrer l’exécution de Terraform avec HCP Terraform ou des pipelines d’intégration continue GitHub ou GitLab.
Pour en savoir plus
Toutes ces notions, depuis la structure du langage HCL, en passant par l’écriture de modules, de providers, leur configuration, et l’outillage que les entreprises utilisent pour compléter leur workflow de développement Terraform, sont explorées en détails dans mon livre “L’infrastructure as Code avec Terraform”, déjà disponible aux Editions ENI pour les particuliers !
Et également sur notre plateforme elearning pour les professionnels.
Vous y trouverez tous les éléments dont vous avez besoin pour basculer, si ce n’est déjà fait, dans l’IaC. N’hésitez pas à nous partager vos retours d’expérience !
#IaC #cloud #terraform