Infrastructure as code

Les systèmes natifs cloud adoptent les microservices, les conteneurs et la conception moderne du système pour atteindre la vitesse et l’agilité. Ils fournissent des phases de génération et de mise en production automatisées pour garantir un code cohérent et de qualité. Mais ce n’est qu’une partie de l’histoire. Comment provisionner les environnements cloud sur lesquels ces systèmes s’exécutent ?

Les applications cloud-natives modernes adoptent la pratique largement acceptée de l’infrastructure en tant que code, ou IaC. Avec IaC, vous automatisez l’approvisionnement de plateforme. Vous appliquez essentiellement des pratiques d’ingénierie logicielle telles que le test et le contrôle de version à vos pratiques DevOps. Votre infrastructure et vos déploiements sont automatisés, cohérents et reproductibles. Tout comme la livraison continue automatisée, le modèle traditionnel de déploiements manuels, l’infrastructure en tant que code (IaC) évolue de la façon dont les environnements d’application sont gérés.

Les outils tels qu’Azure Resource Manager (ARM), Terraform et l’interface de ligne de commande Azure (CLI) vous permettent de scripter de manière déclarative l’infrastructure cloud dont vous avez besoin.

Modèles Microsoft Azure Resource Manager

ARM signifie Azure Resource Manager. Il s’agit d’un moteur de provisionnement d’API intégré à Azure et exposé en tant que service d’API. ARM vous permet de déployer, de mettre à jour, de supprimer et de gérer les ressources contenues dans un groupe de ressources Azure dans une seule opération coordonnée. Vous fournissez au moteur un modèle JSON qui spécifie les ressources dont vous avez besoin et leur configuration. ARM orchestre automatiquement le déploiement dans le bon ordre en respectant les dépendances. Le moteur garantit l’idempotence. Si une ressource souhaitée existe déjà avec la même configuration, le provisionnement est ignoré.

Les modèles Azure Resource Manager sont un langage JSON permettant de définir différentes ressources dans Azure. Le schéma de base ressemble à la figure 10-14.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "",
  "apiProfile": "",
  "parameters": {  },
  "variables": {  },
  "functions": [  ],
  "resources": [  ],
  "outputs": {  }
}

Figure 10-14 : schéma d’un modèle Resource Manager

Dans ce modèle, vous pouvez définir un conteneur de stockage à l’intérieur de la section ressources comme suit :

"resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "[variables('storageAccountName')]",
      "location": "[parameters('location')]",
      "apiVersion": "2018-07-01",
      "sku": {
        "name": "[parameters('storageAccountType')]"
      },
      "kind": "StorageV2",
      "properties": {}
    }
  ],

Figure 10-15 : exemple de compte de stockage défini dans un modèle Resource Manager

Un modèle ARM peut être paramétré avec des informations de configuration et d’environnement dynamique. Cela permet de le réutiliser pour définir différents environnements, tels que le développement, l’assurance qualité ou la production. Normalement, le modèle crée toutes les ressources au sein d’un seul groupe de ressources Azure. Il est possible de définir plusieurs groupes de ressources dans un modèle Resource Manager unique, si nécessaire. Vous pouvez supprimer toutes les ressources d’un environnement en supprimant le groupe de ressources lui-même. L’analyse des coûts peut également être exécutée au niveau du groupe de ressources, ce qui permet de prendre rapidement en compte le coût de chaque environnement.

Il existe de nombreux exemples de modèles ARM disponibles dans le projet Modèles de démarrage rapide Azure sur GitHub. Ils peuvent accélérer la création d’un modèle ou la modification d’un modèle existant.

Les modèles Resource Manager peuvent être exécutés de plusieurs façons. La façon la plus simple est peut-être de les coller simplement dans le portail Azure. Pour les déploiements expérimentaux, cette méthode peut être rapide. Ils peuvent également être exécutés dans le cadre d’un processus de génération ou de mise en production dans Azure DevOps. Il existe des tâches qui tireront parti des connexions à Azure pour exécuter les modèles. Les modifications apportées aux modèles Resource Manager sont appliquées de manière incrémentielle, ce qui signifie que pour ajouter une nouvelle ressource, il suffit de l’ajouter au modèle. Les outils rapprochent les différences entre les ressources actuelles et celles définies dans le modèle. Les ressources seront ensuite créées ou modifiées afin qu’elles correspondent à ce qui est défini dans le modèle.

Terraform

Les applications natives cloud sont souvent construites pour être cloud agnostic. Cela signifie que l’application n’est pas étroitement couplée à un fournisseur de cloud particulier et peut être déployée sur n’importe quel cloud public.

Terraform est un outil de création de modèles commerciaux qui peut provisionner des applications natives cloud dans tous les principaux acteurs cloud : Azure, Google Cloud Platform, AWS et AliCloud. Au lieu d’utiliser JSON comme langage de définition de modèle, il utilise le HCL légèrement plus laconique (Hashicorp Configuration Language).

Un exemple de fichier Terraform qui fait la même chose que le modèle Resource Manager précédent (figure 10-15) est illustré dans la figure 10-16 :

provider "azurerm" {
  version = "=1.28.0"
}

resource "azurerm_resource_group" "testrg" {
  name     = "production"
  location = "West US"
}

resource "azurerm_storage_account" "testsa" {
  name                     = "${var.storageAccountName}"
  resource_group_name      = "${azurerm_resource_group.testrg.name}"
  location                 = "${var.region}"
  account_tier             = "${var.tier}"
  account_replication_type = "${var.replicationType}"

}

Figure 10-16 : exemple de modèle Resource Manager

Terraform fournit également des messages d’erreur intuitifs pour les modèles de problèmes. Il existe également une tâche de validation pratique qui peut être utilisée dans la phase de génération pour intercepter les erreurs de modèle au début.

Comme avec les modèles Resource Manager, les outils en ligne de commande sont disponibles pour déployer des modèles Terraform. Il existe également des tâches créées par la communauté dans les Pipelines Azure qui peuvent valider et appliquer des modèles Terraform.

Parfois, les modèles Terraform et ARM génèrent des valeurs significatives, telles qu’une chaîne de connexion à une base de données nouvellement créée. Ces informations peuvent être capturées dans le pipeline de build et utilisées dans les tâches suivantes.

Scripts et tâches Azure CLI

Enfin, vous pouvez tirer parti d’Azure CLI pour scripter de manière déclarative votre infrastructure cloud. Les scripts Azure CLI peuvent être créés, trouvés et partagés pour provisionner et configurer presque n’importe quelle ressource Azure. L’interface CLI est simple à utiliser avec une courbe d’apprentissage douce. Les scripts sont exécutés dans PowerShell ou Bash. Ils sont également simples à déboguer, en particulier par rapport aux modèles ARM.

Les scripts Azure CLI fonctionnent bien quand vous devez supprimer et redéployer votre infrastructure. La mise à jour d’un environnement existant peut être difficile. De nombreuses commandes CLI ne sont pas idempotentes. Cela signifie qu’ils recréent la ressource chaque fois qu’elles sont exécutées, même si la ressource existe déjà. Il est toujours possible d’ajouter du code qui vérifie l’existence de chaque ressource avant de la créer. Mais, ce faisant, votre script peut devenir gonflé et difficile à gérer.

Ces scripts peuvent également être incorporés dans des pipelines Azure DevOps en tant que Azure CLI tasks. L’exécution du pipeline appelle le script.

La figure 10-17 montre un extrait de code YAML qui répertorie la version d’Azure CLI et les détails de l’abonnement. Notez comment les commandes Azure CLI sont incluses dans un script inline.

- task: AzureCLI@2
  displayName: Azure CLI
  inputs:
    azureSubscription: <Name of the Azure Resource Manager service connection>
    scriptType: ps
    scriptLocation: inlineScript
    inlineScript: |
      az --version
      az account show

Figure 10-17 - Script Azure CLI

Dans l’article , Qu’est-ce que l’infrastructure en tant que code, l’auteur Sam Guckenheimer décrit comment « Teams qui implémente IaC peut fournir des environnements stables rapidement et à grande échelle. Teams évite la configuration manuelle des environnements et applique la cohérence en représentant l’état souhaité de leurs environnements via du code. Les déploiements d’infrastructure avec IaC sont reproductibles et empêchent les problèmes d’exécution causés par la dérive de configuration ou les dépendances manquantes. Les équipes DevOps peuvent collaborer avec un ensemble unifié de pratiques et d’outils pour fournir des applications et leur infrastructure de prise en charge rapidement, fiable et à grande échelle.