Personalizar seus fluxos de trabalho da CLI do Desenvolvedor do Azure usando ganchos de comando e evento

Artigo
10/23/2023

A CLI do Desenvolvedor do Azure oferece suporte a vários pontos de extensão para personalizar seus fluxos de trabalho e implantações. O middleware hooks permite que você execute scripts personalizados antes e depois azd de comandos e eventos do ciclo de vida do serviço. Os ganchos seguem uma convenção de nomenclatura usando prefixos Pre e Post no comando correspondente azd ou no nome do evento de serviço.

Por exemplo, convém executar um script personalizado nos seguintes cenários:

Use o gancho de pré-restauração para personalizar o gerenciamento de dependências.
Use o gancho de pré-implantação para verificar se dependências externas ou configurações personalizadas estão em vigor antes de implantar seu aplicativo.
Use o gancho de postagem no final de um fluxo de trabalho ou pipeline para executar limpeza ou registro em log personalizados.

Ganchos disponíveis

Os seguintes azd ganchos de comando estão disponíveis:

prerestore e : Executar antes e postrestoredepois que as dependências do pacote forem restauradas.
preprovision e : Executar antes e postprovisiondepois da criação dos recursos do Azure.
predeploy e : Executar antes e postdeploydepois que o código do aplicativo é implantado no Azure.
preup e : Executar antes e postupdepois do pipeline de implantação combinado. Up é um comando abreviado que executa restore, provisione deploy sequencialmente.
predown e : Executar antes e postdowndepois que os recursos são removidos.

Os seguintes ganchos de eventos do ciclo de vida do serviço estão disponíveis:

prerestore e : Executar antes e depois que os pacotes de serviço e postrestoredependências são restaurados.
prepackage e : Executar antes e postpackagedepois que o aplicativo for empacotado para implantação.
predeploy e : Executar antes e postdeploydepois que o código de serviço é implantado no Azure.

Configuração do gancho

Os ganchos podem ser registrados em seu azure.yaml arquivo na raiz ou dentro de uma configuração de serviço específica. Todos os tipos de ganchos suportam as seguintes opções de configuração:

shell: sh | pwsh (inferido automaticamente da execução se não especificado).
- Observação: o PowerShell 7 é necessário para pwsho .
run: Defina um script embutido ou um caminho para um arquivo.
continueOnError: Quando definido continuará a ser executado mesmo após um erro de script durante um gancho de comando (false padrão).
interactive: Quando definido ligará o script em execução ao console stdin, stdout & stderr (false padrão).
windows: Especifica que as configurações aninhadas só serão aplicadas no sistema operacional Windows. Se essa opção de configuração for excluída, o gancho será executado em todas as plataformas.
posix: Especifica que as configurações aninhadas só se aplicarão a sistemas operacionais baseados em POSIX (Linux & MaxOS). Se essa opção de configuração for excluída, o gancho será executado em todas as plataformas.

Exemplos de ganchos

Os exemplos a seguir demonstram diferentes tipos de registros e configurações de gancho.

Registro de comando raiz

Os ganchos podem ser configurados para serem executados para comandos específicos azd na raiz do azure.yaml arquivo.

O diretório do projeto (onde o arquivo está localizado) é o azure.yaml diretório de trabalho atual padrão (cwd) para ganchos de comando.

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

Registro do serviço

Os ganchos também podem ser configurados para serem executados somente para serviços específicos definidos no arquivo .yaml .

O diretório de serviço (mesmo caminho definido na project propriedade da configuração do serviço no azure.yaml arquivo) é o padrão cwd para ganchos de serviço.

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

Ganchos específicos do SO

Opcionalmente, os ganchos também podem ser configurados para serem executados no Windows ou no Posix (Linux & MaxOS). Por padrão, se as configurações do Windows ou Posix forem excluídas, o gancho será executado em todas as plataformas.

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

Usar variáveis de ambiente com ganchos

Os ganchos podem obter e definir variáveis de ambiente no .env arquivo usando os azd env get-values comandos e azd set <key> <value> . Os ganchos também podem recuperar variáveis de ambiente do ambiente local usando a ${YOUR_ENVIRONMENT VARIABLE} sintaxe. azd define automaticamente determinadas variáveis de .env ambiente no arquivo quando comandos são executados, como AZURE_ENV_NAME e AZURE_LOCATION. Os parâmetros de saída do main.bicep arquivo também são definidos no .env arquivo. A página gerenciar variáveis de ambiente inclui mais informações sobre fluxos de trabalho de variáveis de ambiente.

Os ganchos podem obter e definir variáveis de ambiente embutidas ou por meio de scripts referenciados, conforme demonstrado no exemplo a seguir:

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}

O referenciado: script: 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

Solicitar ajuda

Para obter informações sobre como registrar um bug, solicitar ajuda ou propor um novo recurso para a CLI do Desenvolvedor do Azure, visite a página de solução de problemas e suporte .

Share via