Comprendre la structure et la syntaxe des fichiers Bicep

Effectué

Azure Bicep est fourni avec sa propre syntaxe. Celle-ci est facile à suivre et à comprendre. Nous n’allons pas approfondir la syntaxe et la structure, mais nous allons passer en revue les principaux concepts à l’aide d’un exemple.

Exemple de fichier Bicep (.bicep)

@minLength(3)
@maxLength(11)
param storagePrefix string

param storageSKU string = 'Standard_LRS'
param location string = resourceGroup().location

var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'

resource stg 'Microsoft.Storage/storageAccounts@2019-04-01' = {
    name: uniqueStorageName
    location: location
    sku: {
        name: storageSKU
    }
    kind: 'StorageV2'
    properties: {
        supportsHttpsTrafficOnly: true
    }

    resource service 'fileServices' = {
        name: 'default'

        resource share 'shares' = {
            name: 'exampleshare'
        }
    }
}

module webModule './webApp.bicep' = {
    name: 'webDeploy'
    params: {
        skuName: 'S1'
        location: location
    }
}

output storageEndpoint object = stg.properties.primaryEndpoints

Étendue

Par défaut, l’étendue cible de tous les modèles est définie pour resourceGroup. Toutefois, vous pouvez la personnaliser en la définissant explicitement. Il en va de même pour les autres valeurs autorisées : subscription, managementGroup et tenant.

Paramètres

Vous avez déjà utilisé les paramètres dans l’unité précédente. Ils vous permettent de personnaliser votre déploiement de modèle au moment de l’exécution en fournissant des valeurs potentielles pour les noms, l’emplacement, les préfixes, etc.

Les paramètres ont également des types que les éditeurs peuvent valider et peuvent avoir des valeurs par défaut pour les rendre facultatifs au moment du déploiement. De plus, vous pouvez voir qu’ils peuvent avoir des règles de validation pour rendre le déploiement plus fiable en empêchant toute valeur non valide directement à partir de la création. Pour plus d’informations, consultez Paramètres dans Bicep.

Variables

Semblables aux paramètres, les variables jouent un rôle dans la création d’un modèle plus robuste et lisible. Toute expression complexe peut être stockée dans une variable et utilisée dans tout le modèle. Quand vous définissez une variable, le type est déduit de la valeur.

Dans l’exemple ci-dessus, uniqueStorageName est utilisé pour simplifier la définition de la ressource. Pour plus d’informations, consultez Variables dans Bicep.

Ressources

Le mot clé resource est utilisé lorsque vous devez déclarer une ressource dans vos modèles. La déclaration de ressource a un nom symbolique pour la ressource qui peut être utilisé pour référencer cette ressource ultérieurement : soit pour définir une sous-ressource, soit pour utiliser ses propriétés pour une dépendance implicite comme une relation parent-enfant.

Certaines propriétés sont communes à toutes les ressources, comme location, name et properties. Il existe des propriétés spécifiques aux ressources qui peuvent être utilisées pour personnaliser le niveau tarifaire des ressources, SKU, etc.

Vous pouvez définir des sous-ressources au sein d’une ressource ou en dehors en référençant le parent. Dans l’exemple ci-dessus, un partage de fichiers est défini dans la ressource du compte de stockage. Si l’intention était de définir la ressource en dehors de celle-ci, vous devez modifier votre modèle :

resource storage 'Microsoft.Storage/storageAccounts@2021-02-01' = {
    name: 'examplestorage'
    location: resourceGroup().location
    kind: 'StorageV2'
    sku: {
        name: 'Standard_LRS'
    }
}

resource service 'Microsoft.Storage/storageAccounts/fileServices@2021-02-01' = {
    name: 'default'
    parent: storage
}

resource share 'Microsoft.Storage/storageAccounts/fileServices/shares@2021-02-01' = {
    name: 'exampleshare'
    parent: service
}

Pour plus d’informations, consultez Déclaration de ressource dans Bicep.

Modules

Si vous souhaitez des modèles véritablement réutilisables, vous devez utiliser un module. Les modules vous permettent de réutiliser un fichier Bicep dans d’autres fichiers Bicep. Dans un module, vous définissez ce que vous devez déployer et tous les paramètres nécessaires. Pour le réutiliser dans un autre fichier, il vous suffit de référencer le fichier et de fournir les paramètres. Le reste est pris en charge par Azure Bicep.

Dans l’exemple ci-dessus, vous utilisez un module qui déploie probablement un App Service. Pour plus d’informations, consultez Utilisation de modules dans Bicep.

Sorties

Vous pouvez utiliser des sorties pour passer des valeurs de votre déploiement au monde extérieur, que ce soit dans un pipeline CI/CD, un terminal local ou Cloud Shell. Cela vous permet d’accéder à une valeur telle qu’un point de terminaison de stockage ou une URL d’application une fois le déploiement terminé.

Tout ce dont vous avez besoin est le mot-clé output et la propriété à laquelle vous souhaitez accéder :

output storageEndpoint endpoints = stg.properties.primaryEndpoints

Pour plus d’informations, consultez Sorties dans Bicep.

Autres fonctionnalités

De nombreuses autres fonctionnalités sont disponibles dans un fichier Bicep, comme les boucles, le déploiement conditionnel, les chaînes multilignes, le référencement d’une ressource cloud existante, etc. En fait, toute fonction valide dans un modèle ARM est également valide dans un fichier Bicep.

Étapes suivantes

Dans l’unité suivante, vous allez apprendre à utiliser Bicep dans un pipeline Azure.