Infrastructure en tant que code

2025-05-26

L’infrastructure en tant que code (IaC) est une pratique clé de DevOps qui implique la gestion de l’infrastructure, comme les réseaux, les services de calcul, les bases de données, les stockages et la topologie de connexion, dans un modèle descriptif. IaC permet aux équipes de développer et de publier des modifications plus rapidement et avec une plus grande confiance. Les avantages de l’IaC sont les suivants :

Confiance accrue dans les déploiements
Possibilité de gérer plusieurs environnements
Meilleure compréhension de l’état de l’infrastructure

Pour plus d’informations sur les avantages de l’utilisation de l’infrastructure en tant que code, consultez l’infrastructure reproductible.

Outillage

Il existe deux approches que vous pouvez prendre lors de l’implémentation de l’infrastructure en tant que code.

L’infrastructure impérative en tant que code implique l’écriture de scripts dans des langages tels que Bash ou PowerShell. Vous indiquez explicitement les commandes exécutées pour produire un résultat souhaité. Lorsque vous utilisez des déploiements impératifs, il vous appartient de gérer la séquence de dépendances, de contrôle d’erreurs et de mises à jour des ressources.
L’infrastructure déclarative en tant que code implique l’écriture d’une définition qui définit la façon dont votre environnement doit ressembler. Dans cette définition, vous spécifiez un résultat souhaité plutôt que la façon dont vous souhaitez qu’elle soit accomplie. Les outils déterminent comment faire en sorte que le résultat se produise en inspectant votre état actuel, en le comparant à votre état cible, puis en appliquant les différences.

Modèles ARM

Passez en revue les informations sur les modèles Azure Resource Manager (modèles ARM).

Biceps

Bicep est un langage spécifique à un domaine (DSL) qui utilise la syntaxe déclarative pour déployer des ressources Azure. Dans les fichiers Bicep, vous définissez l’infrastructure que vous envisagez de déployer et de ses propriétés. Par rapport aux modèles ARM, les fichiers Bicep sont plus faciles à lire et à écrire pour un public non développeur, car ils utilisent une syntaxe concise.

Cet exemple de code Bicep déploie un compte de stockage Azure dans la région du groupe de ressources. Il applique une redondance de type Standard_LRS et le type StorageV2. Le niveau d’accès est défini sur « Chaud » pour l’accès fréquent aux données.

param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Terraformation

Passez en revue les informations sur Terraform.

Azure CLI (Interface de ligne de commande Azure)

Passez en revue les informations sur Azure CLI.

Infrastructure en tant que modules de code

L’un des objectifs de l’utilisation du code pour déployer l’infrastructure consiste à éviter de dupliquer le travail ou à créer plusieurs modèles à des fins identiques ou similaires. Les modules d’infrastructure doivent être réutilisables et flexibles et doivent avoir un objectif clair.

Les modules sont des fichiers indépendants, qui contiennent généralement un ensemble de ressources destinées à être déployées ensemble. Les modules vous permettent de décomposer les modèles complexes en ensembles de code plus petits et plus gérables. Vous pouvez vous assurer que chaque module se concentre sur une tâche spécifique et que tous les modules sont réutilisables pour plusieurs déploiements et charges de travail.

Modules Bicep

Bicep vous permet de créer et d’appeler des modules. Une fois les modules créés, ils peuvent être consommés à partir de tout autre modèle Bicep. Un module Bicep de haute qualité doit définir plusieurs ressources associées. Par exemple, lorsque vous définissez une fonction Azure, vous déployez généralement une application particulière, un plan d’hébergement pour cette application et un compte de stockage pour les métadonnées de cette application. Ces composants sont définis séparément, mais forment un regroupement logique de ressources. Vous devez donc envisager de les définir ensemble en tant que module.

Les modules Bicep utilisent couramment :

Paramètres permettant d’accepter des valeurs à partir d’un module appelant.
Valeurs de sortie pour retourner les résultats à un module appelant.
Ressources permettant de définir un ou plusieurs objets d’infrastructure pour qu’un module soit géré.

Publier des modules Bicep

Vous avez plusieurs options pour publier et partager des modules Bicep.

Registre public : Le registre de modules publics est hébergé dans un registre de conteneurs Microsoft (MCR). Son code source et les modules qu’il contient sont stockés dans GitHub.
Registre privé : Vous pouvez utiliser Azure Container Registry pour publier des modules dans un registre privé. Pour plus d’informations sur la publication de modules dans un registre dans un pipeline CI/CD, consultez Bicep et GitHub Actions, ou si vous préférez, Bicep et Azure Pipelines.
Spécification du modèle : Vous pouvez utiliser des spécifications de modèle pour publier des modules Bicep. Les spécifications de modèle sont destinées à être des modèles complets, mais Bicep vous permet d’utiliser des spécifications de modèle pour déployer des modules.
Système de contrôle de version : Vous pouvez charger des modules directement à partir d’outils de contrôle de version tels que GitHub ou Azure DevOps.

Modules Terraform

Terraform vous permet de créer et d’appeler des modules. Chaque configuration Terraform a au moins un module, appelé module racine, composé de ressources définies dans .tf des fichiers dans votre répertoire de travail principal. Chaque module peut appeler d’autres modules, ce qui vous permet d’inclure des modules enfants dans votre fichier de configuration principal. Les modules peuvent également être appelés plusieurs fois dans la même configuration ou à partir de différentes configurations.

Les modules sont définis avec tous les mêmes concepts de langage de configuration. Ils utilisent généralement :

Variables d’entrée pour accepter les valeurs d’un module appelant.
Valeurs de sortie pour retourner les résultats à un module appelant.
Ressources permettant de définir un ou plusieurs objets d’infrastructure pour qu’un module soit géré.

Publication de modules Terraform

Vous avez plusieurs options pour publier et partager des modules Terraform :

Registre public : HashiCorp possède son propre Registre de modules Terraform qui permet aux utilisateurs de générer des modules Terraform partageables. Il existe actuellement plusieurs modules Azure publiés dans le Registre des modules Terraform.
Registre privé : Vous pouvez publier en toute transparence des modules Terraform dans un référentiel privé tel que Terraform Cloud Private Registry ou Azure Container Registry.
Système de contrôle de version : Vous pouvez charger des modules privés directement à partir d’outils de contrôle de version tels que GitHub. Pour plus d’informations sur les sources prises en charge, consultez les sources de module Terraform.

Considérations relatives à la conception

Envisagez d’utiliser IaC lors du déploiement de ressources de zone d’atterrissage sur Azure. IaC réalise entièrement l’optimisation du déploiement, réduit l’effort de configuration et automatise les déploiements de l’environnement entier.
Déterminez si vous devez adopter une approche IaC impérative ou déclarative.
- En adoptant une approche impérative, énoncez explicitement les commandes à exécuter qui produiront le résultat souhaité.
- Si vous effectuez une approche déclarative, spécifiez le résultat souhaité plutôt que la façon dont vous le souhaitez.
Envisagez les étendues de déploiement. Avoir une bonne compréhension des niveaux de gestion et de la hiérarchie Azure. Chaque déploiement IaC doit connaître l’étendue à laquelle les ressources Azure sont déployées.
Déterminez si vous devez utiliser un outil IaC natif Ou Azure non natif. Éléments à prendre en considération :
- Les outils natifs Azure tels qu’Azure CLI, les modèles ARM et Bicep sont entièrement pris en charge par Microsoft, ce qui permet à leurs nouvelles fonctionnalités d’être intégrées plus rapidement.
- Les outils non natifs comme Terraform vous permettent de gérer l’infrastructure en tant que code sur plusieurs fournisseurs de cloud comme AWS ou GCP. Toutefois, les nouvelles fonctionnalités Azure peuvent prendre un certain temps pour être incluses dans les fonctionnalités non natives. Si votre organisation utilise une approche multicloud ou que votre organisation utilise déjà et est bien familière avec Terraform, envisagez d'utiliser Terraform pour déployer des zones de réception Azure.
Étant donné que les modules vous permettent de décomposer des modèles complexes en jeux de code plus petits, envisagez d’utiliser des modules IaC pour les ressources couramment déployées ensemble. Vous pouvez vous assurer que chaque module se concentre sur une tâche spécifique et est réutilisable pour plusieurs déploiements et charges de travail.
Envisagez d’adopter une stratégie de publication pour les modules IaC en choisissant entre les registres publics, les registres privés ou un système de contrôle de version comme un dépôt Git.
Envisagez d’utiliser un pipeline CI/CD pour les déploiements IaC. Un pipeline applique le processus réutilisable que vous avez défini pour garantir la qualité de vos déploiements et de votre environnement Azure.

Recommandations en matière de conception

Adoptez une approche IaC pour déployer, gérer, régir et prendre en charge les déploiements de zones d’atterrissage Azure.
Utilisez les outils natifs Azure pour IaC dans les scénarios suivants :
- Vous souhaitez utiliser uniquement les outils natifs Azure. Votre organisation peut avoir une expérience de déploiement de modèle ARM ou Bicep antérieure.
- Votre organisation souhaite prendre en charge immédiatement toutes les versions en préversion et en disponibilité générale des services Azure.
Utilisez des outils non natifs pour IaC dans les scénarios suivants :
- Votre organisation utilise actuellement Terraform pour déployer l’infrastructure sur d’autres clouds comme AWS ou GCP.
- Votre organisation n’a pas besoin de prendre en charge immédiatement toutes les versions en préversion et en disponibilité générale des services Azure.
Utilisez des modules IaC réutilisables pour éviter le travail répétitif. Vous pouvez partager des modules au sein de votre organisation pour déployer plusieurs projets ou charges de travail et gérer du code moins complexe.
Publiez et utilisez des modules IaC à partir de registres publics dans les scénarios suivants :
- Vous souhaitez utiliser des modules pour Azure Landing Zone déjà publiés dans les registres publics. Pour plus d’informations, consultez le module Terraform des zones d’atterrissage Azure.
- Vous souhaitez utiliser des modules gérés, mis à jour et pris en charge par Microsoft, Terraform ou d’autres fournisseurs de modules.
  - Vérifiez que vous vérifiez l’instruction de support de n’importe quel fournisseur de module que vous évaluez.
Publiez et utilisez des modules IaC à partir de registres privés ou de systèmes de contrôle de version dans les scénarios suivants :
- Vous souhaitez créer vos propres modules en fonction des besoins de votre organisation.
- Vous souhaitez avoir un contrôle total de toutes les fonctionnalités et gérer, mettre à jour et publier de nouvelles versions de modules.
Utilisez un pipeline CI/CD pour déployer des artefacts IaC et garantir la qualité de votre déploiement et de vos environnements Azure.