Comment traduire votre infrastructure en modèle IaC

Le Connecteur de services aide les utilisateurs à connecter leurs services de calcul à des services de sauvegarde cible en seulement quelques clics ou commandes. Lors du passage d’une phase de démarrage à une phase de production, les utilisateurs doivent également effectuer la transition entre l’utilisation de configurations manuelles et l’utilisation de modèles d’Infrastructure as Code (IaC) dans leurs pipelines CI/CD. Dans ce guide, nous montrons comment traduire vos services Azure connectés en modèles IaC.

Prérequis

• Ce guide part du principe que vous connaissez les limitations du Connecteur de services IaC.

Vue d’ensemble de la solution

La traduction de l’infrastructure en modèles IaC implique généralement deux parties principales : la logique d’approvisionnement des services source et cible, et la logique pour établir des connexions. Pour implémenter la logique d’approvisionnement des services source et cible, il existe deux options :

• Création du modèle à partir de zéro
• Exportation du modèle à partir d’Azure et peaufinage

Pour implémenter la logique de génération de connexions, il existe trois options :

• Utilisation du Connecteur de services et stocker la configuration dans App Configuration
• Utilisation du Connecteur de services dans le modèle
• Utilisation de la logique de modèle pour configurer directement les services source et cible

Les combinaisons de ces différentes options peuvent produire différentes solutions. En raison de limitations iaC dans le Connecteur de services, nous vous recommandons d’implémenter les solutions suivantes dans l’ordre présenté ci-dessous. Pour appliquer ces solutions, vous devez comprendre les outils IaC et la grammaire de création de modèle.

Solution	Approvisionner la source et la cible	Créer une connexion	Scénario applicable	Avantages	Inconvénients
1	Création à partir de zéro	Utiliser le Connecteur de services et stocker la configuration dans App Configuration	Vérifie la durée de vie sur les ressources cloud avant d’autoriser le trafic en direct	- Le modèle est simple et lisible - Le Connecteur de services apporte une valeur supplémentaire - Aucun problème IaC n’est introduit par le Connecteur de services	- Besoin d’une dépendance supplémentaire pour lire la configuration à partir d’App Configuration - Coût de vérification de la durée de vie des ressources cloud
2	Création à partir de zéro	Utiliser le Connecteur de services	Vérifie la durée de vie sur les ressources cloud avant d’autoriser le trafic en direct	- Le modèle est simple et lisible - Le Connecteur de services apporte une valeur supplémentaire	- Coût de vérification de la durée de vie des ressources cloud
3	Création à partir de zéro	Configurer les services source et cible directement dans le modèle	Aucune vérification dynamique sur les ressources cloud	- Le modèle est simple et lisible	- Les fonctionnalités du Connecteur de services ne sont pas disponibles
4	Exporter et peaufiner	Utiliser le Connecteur de services et stocker la configuration dans App Configuration	Vérifie la durée de vie sur les ressources cloud avant d’autoriser le trafic en direct	- Les ressources sont exactement les mêmes que dans le cloud - Le Connecteur de services apporte une valeur supplémentaire - Aucun problème IaC n’est introduit par le Connecteur de services	- Besoin d’une dépendance supplémentaire pour lire la configuration à partir d’App Configuration - Coût de vérification de la durée de vie des ressources cloud - Prend en charge uniquement les modèles ARM - Efforts nécessaires pour comprendre et polir le modèle
5	Exporter et peaufiner	Utiliser le Connecteur de services	Vérifie la durée de vie sur les ressources cloud avant d’autoriser le trafic en direct	- Les ressources sont exactement les mêmes que dans le cloud - Le Connecteur de services apporte une valeur supplémentaire	- Coût de vérification de la durée de vie des ressources cloud - Prend en charge uniquement les modèles ARM - Efforts nécessaires pour comprendre et polir le modèle
6	Exporter et peaufiner	Configurer les services source et cible directement dans le modèle	Aucune vérification dynamique sur les ressources cloud	- Les ressources sont exactement les mêmes que dans le cloud	- Prendre en charge uniquement le modèle ARM - Efforts nécessaires pour comprendre et peaufiner le modèle - Les fonctionnalités du Connecteur de services ne sont pas disponibles

Création de modèles Azure Resource Manager

Les sections suivantes montrent comment créer une application web et un compte de stockage, et les connecter à une identité affectée par le système à l’aide de Bicep. Cela montre comment faire cela à la fois en utilisant le Connecteur de services et en utilisant la logique des modèles.

Approvisionner des services source et cible

Création à partir de zéro

La création du modèle à partir de zéro est la méthode préférée et recommandée pour provisionner les services source et cible, car cela est facile pour démarrer et rend le modèle simple et lisible. Voici un exemple, en utilisant un ensemble minimal de paramètres pour créer une application web et un compte de stockage.

// This template creates a webapp and a storage account.
// In order to make it more readable, we use only the mininal set of parameters to create the resources.

param location string = resourceGroup().location
// App Service plan parameters
param planName string = 'plan_${uniqueString(resourceGroup().id)}'
param kind string = 'linux'
param reserved bool = true
param sku string = 'B1'
// Webapp parameters
param webAppName string = 'webapp-${uniqueString(resourceGroup().id)}'
param linuxFxVersion string = 'PYTHON|3.8'
param identityType string = 'SystemAssigned'
param appSettings array = []
// Storage account parameters
param storageAccountName string = 'account${uniqueString(resourceGroup().id)}'


// Create an app service plan 
resource appServicePlan 'Microsoft.Web/serverfarms@2022-09-01' = {
  name: planName
  location: location
  kind: kind
  sku: {
    name: sku
  }
  properties: {
    reserved: reserved
  }
}


// Create a web app
resource appService 'Microsoft.Web/sites@2022-09-01' = {
  name: webAppName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      linuxFxVersion: linuxFxVersion
      appSettings: appSettings
    }
  }
  identity: {
    type: identityType
  }
}


// Create a storage account
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

Exporter et peaufiner

Si les ressources que vous approvisionnez sont exactement les mêmes que celles que vous avez dans le cloud, l’exportation du modèle à partir d’Azure peut être une autre option. Les deux prémisses de cette approche sont : les ressources existent dans Azure et vous utilisez des modèles ARM pour votre IaC. Le bouton Export template se trouve généralement en bas de la barre latérale sur le portail Azure. Le modèle ARM exporté reflète les états actuels de la ressource, y compris les paramètres configurés par le Connecteur de services. Vous devez généralement connaître les propriétés de ressource pour peaufiner le modèle exporté.

Créer une logique de connexion

Utilisation du Connecteur de services et stockage de la configuration dans App Configuration

L’utilisation d’App Configuration pour stocker la configuration prend naturellement en charge les scénarios IaC. Nous vous recommandons donc d’utiliser cette méthode pour générer votre modèle IaC si possible.

Pour obtenir des instructions simples sur le portail, vous pouvez consulter ce tutoriel App Configuration. Pour ajouter cette fonctionnalité dans un fichier Bicep, ajoutez l’ID App Configuration dans la charge utile du Connecteur de services.

resource webApp 'Microsoft.Web/sites@2022-09-01' existing = {
  name: webAppName
}

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' existing = {
  name: storageAccountName
}

resource appConfiguration 'Microsoft.AppConfiguration/configurationStores@2023-03-01' existing = {
  name: appConfigurationName
}

resource serviceConnector 'Microsoft.ServiceLinker/linkers@2022-05-01' = {
  name: connectorName
  scope: webApp
  properties: {
    clientType: 'python'
    targetService: {
      type: 'AzureResource'
      id: storageAccount.id
    }
    authInfo: {
      authType: 'systemAssignedIdentity'
    }
    configurationInfo: {
      configurationStore: {
        appConfigurationId: appConfiguration.id
      }
    }
  }
}

Utilisation du Connecteur de services

La création de connexions entre le service source et cible à l’aide du Connecteur de services est la méthode préférée et recommandée si la limitation IaCdu Connecteur de services n’a pas d’importance pour votre scénario. Le Connecteur de services simplifie le modèle et fournit également des éléments supplémentaires, tels que la validation de l’intégrité de la connexion, que vous n’aurez pas si vous créez des connexions directement via la logique de modèle.

// The template builds a connection between a webapp and a storage account 
// with a system-assigned identity using Service Connector

param webAppName string = 'webapp-${uniqueString(resourceGroup().id)}'
param storageAccountName string = 'account${uniqueString(resourceGroup().id)}'
param connectorName string = 'connector_${uniqueString(resourceGroup().id)}'

// Get an existing webapp
resource webApp 'Microsoft.Web/sites@2022-09-01' existing = {
  name: webAppName
}

// Get an existig storage
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' existing = {
  name: storageAccountName
}

// Create a Service Connector resource for the webapp 
// to connect to a storage account using system identity
resource serviceConnector 'Microsoft.ServiceLinker/linkers@2022-05-01' = {
  name: connectorName
  scope: webApp
  properties: {
    clientType: 'python'
    targetService: {
      type: 'AzureResource'
      id: storageAccount.id
    }
    authInfo: {
      authType: 'systemAssignedIdentity'
    }
  }
}

Pour connaître les formats de propriétés et de valeurs nécessaires lors de la création d’une ressource du Connecteur de services, consultez comment fournir des paramètres corrects. Vous pouvez également afficher un aperçu et télécharger un modèle ARM pour référence lors de la création d’une ressource du Connecteur de services dans le portail Azure.

Utilisation de la logique de modèle

Pour les scénarios où la limitation IaC du Connecteur de services importe, envisagez de créer des connexions directement à l’aide de la logique de modèle. Le modèle suivant montre comment connecter un compte de stockage à une application web à l’aide d’une identité affectée par le système.

// The template builds a connection between a webapp and a storage account 
// with a system-assigned identity without using Service Connector

param webAppName string = 'webapp-${uniqueString(resourceGroup().id)}'
param storageAccountName string = 'account${uniqueString(resourceGroup().id)}'
param storageBlobDataContributorRole string  = 'ba92f5b4-2d11-453d-a403-e96b0029c9fe'

// Get an existing webapp
resource webApp 'Microsoft.Web/sites@2022-09-01' existing = {
  name: webAppName
}

// Get an existing storage account
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' existing = {
  name: storageAccountName
}

// Operation: Enable system-assigned identity on the source service
// No action needed as this is enabled when creating the webapp

// Operation: Configure the target service's endpoint on the source service's app settings
resource appSettings 'Microsoft.Web/sites/config@2022-09-01' = {
  name: 'appsettings'
  parent: webApp
  properties: {
    AZURE_STORAGEBLOB_RESOURCEENDPOINT: storageAccount.properties.primaryEndpoints.blob
  }
}

// Operation: Configure firewall on the target service to allow the source service's outbound IPs
// No action needed as storage account allows all IPs by default

// Operation: Create role assignment for the source service's identity on the target service
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  scope: storageAccount
  name: guid(resourceGroup().id, storageBlobDataContributorRole)
  properties: {
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', storageBlobDataContributorRole)
    principalId: webApp.identity.principalId
  }
}

Lors de la création de connexions à l’aide d’une logique de modèles directement, il est essentiel de comprendre ce que le Connecteur de services fait pour chaque type d'authentification, car la logique des modèles est équivalente aux opérations en coulisses du Connecteur de services. Le tableau suivant présente les détails de l’opération que vous devez traduire en logique de modèle pour chaque type d’authentification.

Type d’authentification	Opérations du Connecteur de services
Secret / Chaîne de connexion	- Configurer la chaîne de connexion du service cible sur les paramètres d’application du service source - Configurer le pare-feu sur le service cible pour autoriser les adresses IP sortantes du service source
Identité managée affectée par le système	- Configurer le point de terminaison du service cible sur les paramètres d’application du service source - Configurer le pare-feu sur le service cible pour autoriser les adresses IP sortantes du service source - Activer l’identité affectée par le système sur le service source - Créer une attribution de rôle pour l’identité du service source sur le service cible
Identité managée affectée par l’utilisateur	- Configurer le point de terminaison du service cible sur les paramètres d’application du service source - Configurer le pare-feu sur le service cible pour autoriser les adresses IP sortantes du service source - Lier l’identité affectée par l’utilisateur au service source - Créer une attribution de rôle pour l’identité affectée par l’utilisateur sur le service cible
Principal du service	- Configurer le point de terminaison du service cible sur les paramètres d’application du service source - Configurer l’appId et le secret du principal de service sur les paramètres d’application du service source - Configurer le pare-feu sur le service cible pour autoriser les adresses IP sortantes du service source - Créer une attribution de rôle pour le principal de service sur le service cible