Définir des ressources

  • 5 minutes

Les modèles Bicep sont les fichiers que vous créez pour définir les ressources Azure à déployer.

Votre entreprise de jouets a besoin que vous créiez un modèle Bicep réutilisable pour les lancements de produits. Le modèle doit déployer un compte de stockage Azure et des ressources Azure App Service qui seront utilisés pour la commercialisation de chaque nouveau produit lors de son lancement.

Dans cette unité, vous allez découvrir comment définir une ressource dans un modèle Bicep, ainsi que le fonctionnement des noms de ressources et comment créer des ressources liées les unes aux autres.

Notes

Les commandes de cette unité sont présentées pour illustrer les concepts. N’exécutez pas encore les commandes. Vous allez bientôt mettre en pratique ce que vous apprenez ici.

Définir une ressource

Définir vos ressources Azure est ce que vous faites principalement avec les modèles Bicep. Voici un exemple typique de définition de ressource dans Bicep. Cet exemple crée un compte de stockage nommé toylaunchstorage.

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'toylaunchstorage'
  location: 'westus3'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Examinons en détail certaines parties clés de cette définition de ressource :

  • Le mot clé resource au début indique à Bicep que vous allez définir une ressource.

  • Ensuite, vous donnez à la ressource un nom symbolique. Dans cet exemple, le nom symbolique de la ressource est storageAccount. Les noms symboliques sont utilisés dans Bicep pour faire référence à la ressource, mais ils ne s’affichent jamais dans Azure.

  • Microsoft.Storage/storageAccounts@2022-09-01 correspond au type de ressource et à la version d’API de la ressource. Microsoft.Storage/storageAccounts indique à Bicep que vous déclarez un compte de stockage Azure. La date 2022-09-01 est la version de l’API de Stockage Azure utilisée par Bicep lors de la création de la ressource.

    Conseil

    L’extension Bicep pour Visual Studio Code vous permet de trouver les types de ressources et les versions d’API pour les ressources que vous créez. Si vous êtes familiarisé avec les modèles ARM, notez que la version de l’API correspond à la version que vous utiliseriez dans Resource Manager.

  • Vous devez déclarer un nom de ressource qui est le nom attribué au compte de stockage dans Azure. Vous allez définir un nom de ressource en utilisant le mot clé name.

    Important

    Les noms symboliques sont utilisés uniquement dans le modèle Bicep et n’apparaissent pas dans Azure. Les noms de ressource en revanche apparaissent dans Azure.

  • Vous définissez ensuite d’autres détails de la ressource, comme son emplacement, sa référence SKU (niveau tarifaire) et son type. Vous pouvez aussi définir d’autres propriétés qui sont différentes pour chaque type de ressource. Les différentes versions des API peuvent aussi introduire des propriétés différentes. Dans cet exemple, nous définissons le niveau d’accès du compte de stockage sur Hot.

Conseil

Les noms des ressources obéissent souvent à des règles que vous devez respecter, comme des longueurs maximales, des caractères autorisés et une unicité dans Azure. Les exigences pour les noms de ressources sont différentes pour chaque type de ressource Azure. Veillez à bien comprendre les restrictions et les exigences d’attribution de noms avant de les ajouter à votre modèle.

Que se passe-t-il quand des ressources dépendent les unes des autres ?

Un modèle Bicep comprend généralement plusieurs ressources. Il est souvent nécessaire qu’une ressource dépende d’une autre ressource. Vous devrez peut-être extraire des informations d’une ressource pour pouvoir en définir une autre. Si vous déployez une application web, vous devez créer l’infrastructure de serveur avant de pouvoir y ajouter une application. Ces relations sont appelées dépendances.

Vous devez déployer une application App Service pour le modèle qui aidera à lancer le produit de type jouet, mais pour créer une application App Service, vous devez d’abord créer un plan App Service. Le plan App Service représente les ressources hébergeant le serveur et il est déclaré comme dans cet exemple :

resource appServicePlan 'Microsoft.Web/serverFarms@2023-12-01' = {
  name: 'toy-product-launch-plan'
  location: 'westus3'
  sku: {
    name: 'F1'
  }
}

Cette définition de ressource indique à Bicep que vous voulez déployer un plan App Service qui a le type de ressource Microsoft.Web/serverFarms. La ressource de plan se nomme toy-product-launch-plan et est déployée dans la région USA Ouest 3. Il utilise une référence SKU de tarification F1, ce qui correspond au niveau gratuit d’App Service.

Maintenant que vous avez déclaré le plan App Service, l’étape suivante consiste à déclarer l’application :

resource appServiceApp 'Microsoft.Web/sites@2023-12-01' = {
  name: 'toy-product-launch-1'
  location: 'westus3'
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

Ce modèle indique à Azure d’héberger l’application sur le plan que vous avez créé. Notez que la définition du plan comprend le nom symbolique du plan App Service sur cette ligne : serverFarmId: appServicePlan.id. Cette ligne signifie que Bicep obtient l’ID de ressource du plan App Service en utilisant la propriété id. Ceci revient à dire : L’ID de la batterie de serveurs de cette application est l’ID du plan App Service défini précédemment.

Conseil

Dans Azure, l’ID de la ressource est un identificateur unique pour chaque ressource. L’ID de la ressource comprend l’ID d’abonnement Azure, le nom du groupe de ressources et le nom de la ressource, ainsi que d’autres informations.

En déclarant la ressource d’application avec une propriété qui référence le nom symbolique du plan, Azure comprend la dépendance implicite entre l’application App Service et le plan. Quand les ressources sont déployées, Azure s’assure de déployer entièrement le plan avant de commencer à déployer l’application.