Partager via

Infrastructure en tant que code

  • Article

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 comprennent 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.

Outils

Vous pouvez adopter deux approches 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 comme 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 des erreurs et de mise à jour des ressources.
  • L’infrastructure déclarative en tant que code implique l’écriture d’une définition qui définit ce à quoi 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’il soit accompli. 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).

Bicep

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 souhaitez déployer et 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.

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'
  }
}

Terraform

Passez en revue les informations sur Terraform.

Azure CLI

Passez en revue les informations sur Azure CLI.

Modules Infrastructure en tant que code (IaC)

L’un des objectifs de l’utilisation de 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 des modèles complexes en ensembles de code plus petits et plus gérables. Vous pouvez axer chaque module sur une tâche spécifique et les réutiliser 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 d’un 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 ils forment un regroupement logique de ressources. Vous devez donc envisager de les définir ensemble en tant que module.

Les modules Bicep utilisent couramment des :

  • 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 un module à gérer.

Publier des modules Bicep

Vous disposez de 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 le registre de conteneurs Azure 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 specs 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 specs 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 comme 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, constitué de ressources définies dans les fichiers .tf de 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 les mêmes concepts de langage de configuration. Ils utilisent généralement des :

  • 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 un module à gérer.

Publication de modules Terraform

Vous disposez de 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 de modules Terraform.
  • Registre privé : Vous pouvez publier en toute transparence des modules Terraform dans un référentiel privé comme 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 comme GitHub. Pour plus d’informations sur les sources prises en charge, consultez Sources de modules Terraform.

Remarques relatives à la conception

  • Envisagez d’utiliser l’IaC lors du déploiement de ressources de zone d’atterrissage sur Azure. L’IaC réalise entièrement l’optimisation du déploiement, réduit l’effort de configuration et automatise l’ensemble des déploiements de l’environnement.

  • Déterminez si vous devez adopter une approche IaC impérative ou déclarative.

    • Si vous adoptez une approche impérative, indiquez explicitement les commandes à exécuter qui produisent le résultat souhaité.

    • Si vous adoptez une approche déclarative, spécifiez le résultat souhaité plutôt que la façon dont vous souhaitez l’obtenir.

  • Envisagez les étendues de déploiement. Ayez une bonne compréhension des niveaux et de la hiérarchie de gestion Azure. Chaque déploiement IaC doit connaître l’étendue sur laquelle les ressources Azure sont déployées.

  • Déterminez si vous devez utiliser un outil IaC natif ou non natif Azure. Éléments à prendre en considération :

    • Les outils natifs Azure comme 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 solutions non natives. Si votre organisation est multicloud ou si votre organisation utilise déjà Terraform et est bien formée, envisagez d’utiliser Terraform pour déployer des zones d’atterrissage Azure.

  • Étant donné que les modules vous permettent de décomposer des modèles complexes en ensembles 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 sur une tâche spécifique 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 référentiel Git.

  • Envisagez d’utiliser un pipeline CI/CD pour les déploiements IaC. Le pipeline applique le processus réutilisable que vous définissez pour garantir la qualité de vos déploiements et de l’environnement Azure.

Recommandations de conception

  • Adoptez une approche IaC pour déployer, gérer, régir et prendre en charge les déploiements de zone d’atterrissage Azure.

  • Utilisez les outils natifs Azure pour IaC dans les scénarios suivants :

    • Vous souhaitez utiliser uniquement des outils natifs Azure. Votre organisation a peut-être déjà fait un déploiement de modèle ARM ou Bicep.

    • 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 une zone d’atterrissage Azure déjà publiée dans les registres publics. Pour plus d’informations, consultez Module Terraform pour les 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.

      • N’oubliez pas de lire la déclaration de support du 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 de vos besoins organisationnels.

    • 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.