Personnaliser vos flux de travail Azure Developer CLI à l’aide de hooks de commande et d’événements

Article
10/23/2023

Azure Developer CLI prend en charge différents points d’extension pour personnaliser vos flux de travail et vos déploiements. L’intergiciel hooks vous permet d’exécuter des scripts personnalisés avant et après azd les commandes et les événements de cycle de vie du service. les hooks suivent une convention d’affectation de noms à l’aide de préfixes pré et post sur le nom d’événement de service ou de commande correspondant azd .

Par exemple, vous pouvez exécuter un script personnalisé dans les scénarios suivants :

Utilisez le hook de prérestore pour personnaliser la gestion des dépendances.
Utilisez le hook de prédéploiement pour vérifier que les dépendances externes ou les configurations personnalisées sont en place avant de déployer votre application.
Utilisez le hook de publication à la fin d’un flux de travail ou d’un pipeline pour effectuer une propre personnalisée ou une journalisation.

Crochets disponibles

Les hooks de commande suivants azd sont disponibles :

prerestore et postrestore: Exécuter avant et après la restauration des dépendances de package.
preprovision et postprovision: Exécuter avant et après la création des ressources Azure.
predeploy et postdeploy: Exécutez avant et après le déploiement du code de l’application sur Azure.
preup et postup: Exécutez avant et après le pipeline de déploiement combiné. Up est une commande abrégée qui s’exécute restore, provisionet deploy séquentiellement.
predown et postdown: Exécuter avant et après la suppression des ressources.

Les hooks d’événements de cycle de vie de service suivants sont disponibles :

prerestore et postrestore: Exécutez avant et après la restauration des packages et dépendances de service.
prepackage et postpackage: Exécutez avant et après l’application pour le déploiement.
predeploy et postdeploy: Exécutez avant et après le déploiement du code de service sur Azure.

Configuration de hook

Les hooks peuvent être inscrits dans votre azure.yaml fichier à la racine ou dans une configuration de service spécifique. Tous les types de hooks prennent en charge les options de configuration suivantes :

shell: sh | pwsh (déduit automatiquement de l’exécution s’il n’est pas spécifié).
- Remarque : PowerShell 7 est requis pour pwsh.
run: définissez un script inline ou un chemin d’accès à un fichier.
continueOnError: lorsque l’ensemble continue à s’exécuter même après qu’une erreur de script s’est produite lors d’un hook de commande (valeur false par défaut).
interactive: quand la définition lie le script en cours d’exécution à la console stdin, stdout & stderr (valeur false par défaut).
windows: spécifie que les configurations imbriquées s’appliquent uniquement au système d’exploitation Windows. Si cette option de configuration est exclue, le hook s’exécute sur toutes les plateformes.
posix: spécifie que les configurations imbriquées s’appliquent uniquement aux systèmes d’exploitation basés sur POSIX (Linux &MaxOS). Si cette option de configuration est exclue, le hook s’exécute sur toutes les plateformes.

Exemples de crochets

Les exemples suivants illustrent différents types d’inscriptions et de configurations de hook.

Inscription de commande racine

Les hooks peuvent être configurés pour s’exécuter pour des commandes spécifiques azd à la racine de votre azure.yaml fichier.

Le répertoire du projet (où se trouve le azure.yaml fichier) est le répertoire de travail actif par défaut (cwd) pour les hooks de commande.

name: todo-nodejs-mongo
metadata:
  template: todo-nodejs-mongo@0.0.1-beta
hooks:
  prerestore: # Example of an inline script. (shell is required for inline scripts)
    shell: sh
    run: echo 'Hello'
  preprovision: # Example of external script (Relative path from project root)
    run: ./hooks/preprovision.sh
services:
  web:
    project: ./src/web
    dist: build
    language: js
    host: appservice
  api:
    project: ./src/api
    language: js
    host: appservice

Inscription du service

Les hooks peuvent également être configurés pour s’exécuter uniquement pour des services spécifiques définis dans votre .yaml fichier.

Le répertoire de service (même chemin que défini dans la project propriété de la configuration du service dans le azure.yaml fichier) est la valeur par défaut cwd pour les hooks de service.

name: todo-nodejs-mongo
metadata:
  template: todo-nodejs-mongo@0.0.1-beta
services:
  web:
    project: ./src/web
    dist: build
    language: js
    host: appservice
  api:
    project: ./src/api
    language: js
    host: appservice
    hooks:
      prerestore: # Example of an inline script. (shell is required for inline scripts)
        shell: sh
        run: echo 'Restoring API service...'
      prepackage: # Example of external script (Relative path from service path)
        run: ./hooks/prepackage.sh

Raccordements spécifiques au système d’exploitation

Si vous le souhaitez, les hooks peuvent également être configurés pour s’exécuter sur Windows ou Posix (Linux &MaxOS). Par défaut, si les configurations Windows ou Posix sont exclues, le hook s’exécute sur toutes les plateformes.

name: todo-nodejs-mongo
metadata:
  template: todo-nodejs-mongo@0.0.1-beta
hooks:
  prerestore: 
    posix: # Only runs on Posix environments
      shell: sh
      run: echo 'Hello'
   windows: # Only runs on Windows environments
     shell: pwsh
     run: Write-Host "Hello"
services:
  web:
    project: ./src/web
    dist: build
    language: js
    host: appservice
  api:
    project: ./src/api
    language: js
    host: appservice

Utiliser des variables d’environnement avec des hooks

Les hooks peuvent obtenir et définir des variables d’environnement dans le fichier à l’aide .env des commandes et azd set <key> <value> des azd env get-values commandes. Les hooks peuvent également récupérer des variables d’environnement à partir de votre environnement local à l’aide de la ${YOUR_ENVIRONMENT VARIABLE} syntaxe. azd définit automatiquement certaines variables d’environnement dans le .env fichier lorsque les commandes sont exécutées, telles que AZURE_ENV_NAME et AZURE_LOCATION. Les paramètres de sortie du main.bicep fichier sont également définis dans le .env fichier. La page gérer les variables d’environnement inclut plus d’informations sur les flux de travail des variables d’environnement.

Les hooks peuvent obtenir et définir des variables d’environnement inline ou via des scripts référencés, comme illustré dans l’exemple suivant :

name: azure-search-openai-demo
metadata:
  template: azure-search-openai-demo@0.0.2-beta
services:
  backend:
    project: ./app/backend
    language: py
    host: appservice
hooks:
  postprovision:
    windows: # Run referenced script that uses environment variables (script shown below)
      shell: pwsh
      run: ./scripts/prepdocs.ps1
      interactive: true
      continueOnError: false
    posix:
      shell: sh
      run: ./scripts/prepdocs.sh
      interactive: true
      continueOnError: false
  postdeploy: # Pull environment variable inline from local device and set in .env file
      shell: sh
      run: azd env set REACT_APP_WEB_BASE_URL ${SERVICE_WEB_ENDPOINT_URL}

Le script référencé : prepdocs.sh

echo "Loading azd .env file from current environment"

# Use the `get-values` azd command to retrieve environment variables from the `.env` file
while IFS='=' read -r key value; do
    value=$(echo "$value" | sed 's/^"//' | sed 's/"$//')
    export "$key=$value"
done <<EOF
$(azd env get-values) 
EOF

echo 'Creating python virtual environment "scripts/.venv"'
python3 -m venv scripts/.venv

echo 'Installing dependencies from "requirements.txt" into virtual environment'
./scripts/.venv/bin/python -m pip install -r scripts/requirements.txt

echo 'Running "prepdocs.py"'
./scripts/.venv/bin/python ./scripts/prepdocs.py './data/*' 
    --storageaccount "$AZURE_STORAGE_ACCOUNT"
    --container "$AZURE_STORAGE_CONTAINER"
    --searchservice "$AZURE_SEARCH_SERVICE"
    --openaiservice "$AZURE_OPENAI_SERVICE"
    --openaideployment "$AZURE_OPENAI_EMB_DEPLOYMENT"
    --index "$AZURE_SEARCH_INDEX"
    --formrecognizerservice "$AZURE_FORMRECOGNIZER_SERVICE"
    --tenantid "$AZURE_TENANT_ID" -v

Demander de l’aide

Pour plus d’informations sur la façon de déposer un bogue, de demander de l’aide ou de proposer une nouvelle fonctionnalité pour l’interface CLI développeur Azure, visitez la page de dépannage et de support .

Partager via