Créer l’IaC (Infrastructure as code)

6 minutes

Azure Developer CLI (azd) peut provisionner des ressources dans Azure en utilisant des fichiers IaC (Infrastructure as code) écrits en Bicep ou Terraform. Une infrastructure en tant que code vous permet de définir des ressources et des configurations d’infrastructure dans des fichiers de définition déclaratifs, qui génèrent de façon fiable les mêmes environnements chaque fois qu’ils sont déployés. azd exécute ces fichiers pour créer les ressources Azure nécessaires à l’hébergement de votre application. Vous pouvez en savoir plus sur l’infrastructure en tant que code dans la documentation Qu’est-ce que l’infrastructure en tant que code ?.

Dans cette unité, vous allez ajouter du code Bicep à votre modèle pour provisionner les ressources nécessaires à votre application. Une connaissance préalable de Bicep n’est pas nécessaire pour suivre ce module. Toutefois, si vous prévoyez de beaucoup utiliser les modèles azd, il est judicieux de vous familiariser avec au moins les bases de Bicep ou de Terraform. Apprenez-en davantage sur Bicep dans le parcours d’apprentissage Bicep - Principes de base.

Les fichiers Bicep ou Terraform de votre modèle sont dans le dossier infra. Le modèle de démarrage Bicep que vous avez sélectionné a généré trois fichiers comme point de départ :

main.bicep- Fait office de point d’entrée principal pour exécuter Bicep et est utilisé pour définir les ressources qui seront provisionnées dans Azure. Le fichier main.bicep peut également référencer d’autres modules Bicep (fichiers) qui vous permettent d’extraire des définitions de ressources dans des fichiers réutilisables plus précis.
abbreviations.json - Fichier JSON qui fournit de nombreuses abréviations de nom utiles. Ce fichier est chargé dans le fichier main.bicep pendant l’exécution et fournit un ensemble de préfixes logiques et cohérents pour différentes ressources Azure.
main.parameters.json - Fichier JSON qui définit les valeurs par défaut pour les paramètres de modèle importants, tels que la localisation Azure par défaut ou le nom de l’environnement.

Vous pouvez définir et provisionner les ressources Azure requises pour votre application en mettant à jour le fichier main.bicep et en créant d’autres fichiers Bicep. Main.bicep orchestre généralement l’exécution d’autres modules Bicep en passant les paramètres entre eux. Pour cet exemple, vous allez créer un autre module Bicep pour définir l’instance Azure App Service qui hébergera votre application.

Dans le dossier infra de votre modèle, créez un fichier appelé app.bicep.

Ouvrez le fichier app.bicep et collez-y l’extrait de code suivant. Les commentaires de code décrivent l’objectif de chaque section du code.

// Define parameters that can be passed into the module
// Parameters allow a module to be reusable
@description('The location of where to deploy resources')
param location string

@description('The name of the App Service Plan')
param appServicePlanName string

@description('The name of the App Service')
param appServiceName string

// Define the App Service Plan to manage compute resources
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: appServicePlanName
  location: location
  properties: {
    reserved: true
  }
  sku: {
    name: 'F1'
  }
  kind: 'linux'
}

// Define the App Service to host the application
resource appService 'Microsoft.Web/sites@2022-03-01' = {
  name: appServiceName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      linuxFxVersion: 'DOTNETCORE|6.0'
    }
  }
    // Tag used to reference the service in the Azure.yaml file
    tags: { 'azd-service-name': 'web' }
}

Cet extrait de code accomplit les tâches suivantes :

Définit un ensemble de paramètres qui peuvent être transmis au module pour le rendre réutilisable et configurable. Vous pouvez choisir de paramétrer davantage de valeurs dans les définitions de ressources pour rendre le module plus flexible.
Définit un plan App Service afin de gérer les ressources de calcul pour les instances App Service.
Définit l’instance App Service pour héberger l’application déployée.

Remarque

Une étiquette azd-service-name est incluse dans la définition Bicep App Service qui sera utilisée ultérieurement par le fichier de configuration Azure.yaml pour associer le code source de votre application à l’instance App Service.

Le nouveau module Bicep crée une instance App Service pour votre modèle, mais vous devez quand même mettre à jour main.bicep pour l’utiliser. Recherchez le dossier infra dans votre éditeur et ouvrez le fichier main.bicep.

Le fichier main.bicep généré par le modèle de démarrage comprend des configurations d’installation qui vous seront utiles. Par exemple, le fichier définit des paramètres essentiels, comme environmentName et location. Par défaut, ces paramètres sont renseignés à partir de main.parameters.json s’ils sont inclus dans ce fichier, mais vous pouvez également les remplacer. Le code de démarrage se charge également dans le fichier abbreviations.json afin de pouvoir l’utiliser, crée des étiquettes et des jetons utiles pour nommer les services, et comprend des commentaires utiles avec des conseils qui vous aideront à commencer.
Vers le bas du fichier main.bicep, recherchez le commentaire qui ressemble à ce qui suit :
```
// Add resources to be provisioned below.
// A full example that leverages azd bicep modules can be seen in the todo-python-mongo template:
// https://github.com/Azure-Samples/todo-python-mongo/tree/main/infra
```
Ce commentaire d’espace réservé met en évidence à quel endroit inclure les ressources supplémentaires que vous voulez provisionner. Nous voulons inclure le module Bicep que vous créez pour l’instance App Service, donc collons l’extrait de code suivant directement après le commentaire :
```
module web 'app.bicep' = {
  name: '${deployment().name}-app'
  scope: rg
  params: {
    location: location
    appServiceName: '${abbrs.webSitesAppService}${resourceToken}'
    appServicePlanName: '${abbrs.webServerFarms}${resourceToken}'
  }
}
```
Cet extrait de code accomplit les tâches suivantes :
- Définit un module Bicep qui pointe vers le fichier que vous avez créé à l’étape précédente.
- Attribue un nom au jeu de déploiement Azure et le délimite au groupe de ressources créé dans main.bicep.
- Transmet les paramètres au module en utilisant les valeurs abbreviations.json pour faciliter l’attribution de noms.

Les fichiers d’infrastructure du code source de l’application font maintenant partie de votre modèle. Dans la prochaine unité, vous allez ajouter des configurations qui décrivent la relation entre ces éléments pour le processus de déploiement d’azd.

Créer l’IaC (Infrastructure as code)

Commentaires