Commandes de l'interface CLI Bicep

Article
01/11/2025

Cet article décrit les commandes que vous pouvez utiliser dans l'interface CLI Bicep. Vous pouvez exécuter ces commandes à l’aide d’Azure CLI ou en appelant directement des commandes Bicep CLI. Chaque méthode nécessite un processus d’installation distinct. Pour plus d’informations sur les installations, consultez Azure CLI et Azure PowerShell.

Ce guide montre comment exécuter les commandes dans Azure CLI. Lors de l’exécution de commandes dans Azure CLI, démarrez-les avec az. Si vous n’utilisez pas Azure CLI, exécutez les commandes sans az démarrer chacune d’elles. Par exemple, az bicep build devient bicep build et az bicep version devient bicep --version.

build

La build commande convertit un fichier Bicep en modèle AZURE Resource Manager JSON (modèle ARM). En général, vous n'avez pas besoin d'exécuter cette commande car elle s'exécute automatiquement lorsque vous déployez un fichier Bicep. Exécutez-le manuellement lorsque vous souhaitez voir le modèle ARM JSON créé à partir de votre fichier Bicep.

L’utilisation de l’une des fonctionnalités Bicep suivantes active automatiquement la génération de code version 2.0 du langage :

L'exemple suivant convertit un fichier Bicep nommé main.bicep en modèle ARM nommé main.json. Le nouveau fichier est créé dans le même répertoire que le fichier Bicep :

az bicep build --file main.bicep

L’exemple suivant enregistre main.json dans un autre répertoire :

az bicep build --file main.bicep --outdir c:\jsontemplates

L’exemple suivant spécifie le nom et l’emplacement du fichier à créer :

az bicep build --file main.bicep --outfile c:\jsontemplates\azuredeploy.json

Pour imprimer le fichier sur stdout, utilisez :

az bicep build --file main.bicep --stdout

Si votre fichier Bicep inclut un module qui fait référence à un registre externe, la build commande appelle restoreautomatiquement . La restore commande obtient le fichier à partir du Registre et le stocke dans le cache local.

Remarque

La restore commande n’actualise pas le cache. Pour plus d’informations, consultez restore.

Pour ne pas appeler la commande restore automatiquement, utilisez le commutateur --no-restore :

az bicep build --no-restore <bicep-file>

Le processus de génération avec le commutateur --no-restore échoue si l’un des modules externes n’est pas déjà mis en cache :

The module with reference "br:exampleregistry.azurecr.io/bicep/modules/storage:v1" hasn't been restored.

Lorsque vous obtenez cette erreur, exécutez la build commande sans le --no-restore commutateur, ou exécutez d’abord bicep restore .

Pour utiliser le --no-restore commutateur, vous devez disposer de l’interface CLI Bicep version 0.4.X ou ultérieure.

build-params

La build-params commande génère un .bicepparam fichier dans un fichier de paramètres JSON :

az bicep build-params --file params.bicepparam

Cette commande convertit un fichier de paramètres params.bicepparam en fichier de paramètres params.json JSON.

decompile

La decompile commande convertit un modèle ARM JSON en fichier Bicep :

az bicep decompile --file main.json

Cette commande crée un fichier nommé main.bicep dans le même répertoire que main.json. Si main.bicep existe dans le même répertoire, utilisez le commutateur --force pour remplacer le fichier Bicep existant.

Pour plus d’informations sur l’utilisation de cette commande, consultez Le modèle ARM JSON décompilé sur Bicep.

decompile-params

La decompile-params commande décompile un fichier de paramètres JSON dans un .bicepparam fichier de paramètres.

az bicep decompile-params --file azuredeploy.parameters.json --bicep-file ./dir/main.bicep

Cette commande décompile un fichier de paramètres azuredeploy.parameters.json dans un fichier azuredeploy.parameters.bicepparam . --bicep-file spécifie le chemin d’accès au fichier Bicep (relatif au .bicepparam fichier) référencé dans la using déclaration.

format

La format commande met en forme un fichier Bicep. Il s’agit de la même fonction que le raccourci SHIFT+ALT+F dans Visual Studio Code.

az bicep format --file main.bicep

generate-params

La commande generate-params génère un fichier de paramètres à partir du fichier Bicep donné ou effectue une mise à jour si un fichier de paramètres existe.

az bicep generate-params --file main.bicep --output-format bicepparam --include-params all

Cette commande crée un fichier de paramètres Bicep nommé main.bicepparam. Le fichier de paramètres contient tous les paramètres du fichier Bicep, qu’ils soient configurés avec des valeurs par défaut ou non.

az bicep generate-params --file main.bicep --outfile main.parameters.json

Cette commande crée un fichier de paramètres nommé main.parameters.json. Le fichier de paramètres contient uniquement les paramètres sans valeurs par défaut configurées dans le fichier Bicep.

install

La install commande ajoute l’interface CLI Bicep à votre environnement local, et elle est disponible uniquement via Azure CLI. Pour plus d'informations, consultez Installer les outils Bicep.

Pour installer la version la plus récente, utilisez :

az bicep install

Pour installer une version spécifique :

az bicep install --version v0.3.255

jsonrpc

La jsonrpc commande active l’exécution de l’interface CLI Bicep avec une interface JSON-RPC, ce qui permet une interaction programmatique avec une sortie structurée et évite les retards de démarrage à froid lors de la compilation de plusieurs fichiers. Cette configuration prend également en charge la création de bibliothèques pour interagir avec les fichiers Bicep par programmation dans non-.NET langages.

Le format de câble pour l’envoi et la réception d’entrée/sortie est délimité par l’en-tête, à l’aide de la structure suivante, où \r et \n représentent les caractères de retour chariot et de flux de ligne :

Content-Length: <length>\r\n\r\n<message>\r\n\r\n

<length> est la longueur de la <message> chaîne, y compris la fin \r\n\r\n.
<message> est le message JSON brut.

Par exemple :

Content-Length: 72\r\n\r\n{"jsonrpc": "2.0", "id": 0, "method": "bicep/version", "params": {}}\r\n\r\n

Le message suivant montre un exemple de version de Bicep.

Entrée :

{
  "jsonrpc": "2.0",
  "id": 0,
  "method": "bicep/version",
  "params": {}
}

La sortie est la suivante :

{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "version": "0.24.211"
  }
}

Pour connaître les méthodes disponibles et les corps de requête/réponse, consultez ICliJsonRpcProtocol.cs. Pour obtenir un exemple d’établissement d’une connexion JSONRPC et d’interaction avec des fichiers Bicep par programmation à l’aide de Node, consultez jsonrpc.test.ts.

Utilisation du canal nommé

Utilisez la syntaxe suivante pour vous connecter à un canal nommé existant en tant que client JSONRPC :

bicep jsonrpc --pipe <named_pipe>`

<named_pipe> est un canal nommé existant auquel connecter le client JSONRPC.

Pour vous connecter à un canal nommé sur OSX/Linux :

bicep jsonrpc --pipe /tmp/bicep-81375a8084b474fa2eaedda1702a7aa40e2eaa24b3.sock

Pour vous connecter à un canal nommé sur Windows :

bicep jsonrpc --pipe \\.\pipe\\bicep-81375a8084b474fa2eaedda1702a7aa40e2eaa24b3.sock`

Pour plus d’exemples, consultez C# et node.js.

Utilisation du socket TCP

Utilisez la syntaxe suivante pour vous connecter à un socket TCP existant en tant que client JSONRPC :

bicep jsonrpc --socket <tcp_socket>

<tcp_socket> est le numéro de socket auquel le client JSONRPC se connecte.

Pour vous connecter à un socket TCP :

bicep jsonrpc --socket 12345

Utilisation de stdin et stdout

Utilisez la syntaxe suivante et stdin pour que stdout les messages exécutent l’interface JSONRPC :

bicep jsonrpc --stdio

lint

La lint commande retourne les erreurs et les violations de règle linter d’un fichier Bicep.

az bicep lint --file main.bicep

Si votre fichier Bicep inclut un module qui fait référence à un registre externe, la lint commande appelle restoreautomatiquement . La restore commande obtient le fichier à partir du Registre et le stocke dans le cache local.

Remarque

La restore commande n’actualise pas le cache. Pour plus d’informations, consultez restore.

Pour ne pas appeler la commande restore automatiquement, utilisez le commutateur --no-restore :

az bicep lint --no-restore <bicep-file>

Le processus lint avec le commutateur --no-restore échoue si l’un des modules externes n’est pas déjà mis en cache :

The module with reference "br:exampleregistry.azurecr.io/bicep/modules/storage:v1" has not been restored.

Quand vous recevez cette erreur, vous devez exécuter la commande lint sans le commutateur --no-restore ou exécuter bicep restore en premier.

list-versions

La commande list-versions renvoie toutes les versions disponibles de l'interface CLI Bicep. Utilisez cette commande pour savoir si vous devez mettre à niveau ou installer une nouvelle version. Cette commande est disponible uniquement via Azure CLI.

az bicep list-versions

La commande retourne un tableau de versions disponibles :

[
  "v0.28.1",
  "v0.27.1",
  "v0.26.170",
  "v0.26.54",
  "v0.25.53",
  "v0.25.3",
  "v0.24.24",
  "v0.23.1",
  "v0.22.6",
  "v0.21.1",
  "v0.20.4",
  "v0.19.5",
  "v0.18.4",
  "v0.17.1",
  "v0.16.2",
  "v0.16.1",
  "v0.15.31",
  "v0.14.85",
  "v0.14.46",
  "v0.14.6",
  "v0.13.1",
  "v0.12.40",
  "v0.12.1",
  "v0.11.1",
  "v0.10.61",
  "v0.10.13",
  "v0.9.1",
  "v0.8.9",
  "v0.8.2",
  "v0.7.4"
]

Publier

La commande publish ajoute un module à un registre. Le registre de conteneurs Azure doit exister et le compte qui publie dans le registre doit disposer des autorisations appropriées. Pour plus d’informations sur la configuration d’un registre de modules, consultez Utiliser un registre privé pour les modules Bicep. Pour publier un module, le compte doit disposer du profil et des autorisations appropriés pour accéder au registre. Vous pouvez configurer le profil et les informations d’identification prioritaires pour l’authentification auprès du registre dans le fichier de configuration de Bicep.

Après avoir publié le fichier dans le registre, vous pouvez le référencer dans un module.

Vous devez disposer de Bicep CLI version 0.14.X ou ultérieure pour utiliser la publish commande et le --documentationUri/-d paramètre.

Pour publier un module dans un registre, utilisez :

az bicep publish --file <bicep-file> --target br:<registry-name>.azurecr.io/<module-path>:<tag> --documentationUri <documentation-uri>

Par exemple :

az bicep publish --file storage.bicep --target br:exampleregistry.azurecr.io/bicep/modules/storage:v1 --documentationUri https://www.contoso.com/exampleregistry.html

La publish commande ne reconnaît pas les alias spécifiés dans un fichier bicepconfig.json. Indiquez le chemin d’accès complet au module.

Avertissement

La publication sur la même cible remplace l’ancien module. Nous vous recommandons d’incrémenter la version lors de la mise à jour.

restauration

Lorsque votre fichier Bicep utilise des modules qui sont publiés dans un registre, la commande restore obtient des copies de tous les modules requis à partir du registre. Elle stocke ces copies dans un cache local. Un fichier Bicep ne peut être généré que lorsque les fichiers externes sont disponibles dans le cache local. L’exécution de la commande restore n’est normalement pas nécessaire, car elle est automatiquement déclenchée par le processus de génération.

Pour restaurer des modules externes dans le cache local, le compte doit disposer du profil et des autorisations appropriées pour accéder au registre. Vous pouvez configurer le profil et les informations d’identification prioritaires pour l’authentification auprès du registre dans le fichier de configuration de Bicep.

Pour utiliser la restore commande, vous devez disposer de Bicep CLI version 0.14.X ou ultérieure. Pour l’instant, cette commande est disponible uniquement lors de l’appel de l’interface CLI Bicep directement. Il n’est actuellement pas disponible via Azure CLI.

Pour restaurer manuellement les modules externes d’un fichier, utilisez :

az bicep restore --file <bicep-file> [--force]

Le fichier Bicep que vous fournissez est le fichier que vous souhaitez déployer. Il doit contenir un module qui établit un lien vers un registre. Par exemple, vous pouvez restaurer le fichier suivant :

module stgModule 'br:exampleregistry.azurecr.io/bicep/modules/storage:v1' = {
  name: 'storageDeploy'
  params: {
    storagePrefix: 'examplestg1'
  }
}

Le cache local se trouve sous :

Sur Windows

%USERPROFILE%\.bicep\br\<registry-name>.azurecr.io\<module-path\<tag>

Sur Linux
```
/home/<username>/.bicep
```
Sur Mac
```
~/.bicep
```

La commande restore n’actualise pas le cache si un module est déjà mis en cache. Pour actualiser le cache, vous pouvez supprimer le chemin du module du cache ou utiliser le commutateur avec la --force restore commande.

upgrade

La commande upgrade procède à la mise à jour de la version installée vers la dernière version. Cette commande est disponible uniquement via Azure CLI.

az bicep upgrade

version

La version commande retourne votre version installée :

az bicep version

La commande affiche le numéro de version :

Bicep CLI version 0.22.6 (d62b94db31)

Pour appeler cette commande directement via Bicep CLI, utilisez :

bicep --version

Si l’interface CLI Bicep n’a pas été installée, un message d’erreur s’affiche indiquant que l’interface CLI Bicep n’a pas été trouvée.

Étapes suivantes

Pour en savoir plus sur le déploiement d’un fichier Bicep, consultez :

Partager via