Esquema azure.yaml da CLI do Desenvolvedor do Azure

azd modelos são repositórios de blueprint que incluem código de aplicativo de prova de conceito, configurações de editor/IDE e código de infraestrutura escrito em Bicep ou Terraform. Esses modelos devem ser modificados e adaptados para seus requisitos de aplicativo específicos e, em seguida, usados para obter seu aplicativo no Azure usando a CLI do Desenvolvedor do Azure (azd). O esquema azure.yaml define e descreve os aplicativos e tipos de recursos do Azure incluídos nesses modelos.

Amostra

Veja a seguir um exemplo genérico de um azure.yaml modelo necessário.azd

name: yourApp
metadata:
  template: yourApp@0.0.1-beta
services:
  web:
    project: ./src/web # path to your web project
    dist: build # relative path to service deployment artifacts
    language: js # one of the supported languages
    host: appservice # one of the supported Azure services

Compare com o azure.yaml de nosso modelo ToDo NodeJs Mongo:

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

Descrições de propriedade

propriedades de metadata

propriedades de infra

Exemplo de provedor Terraform como IaC

name: yourApp-terraform
metadata:
  template: yourApp-terraform@0.0.1-beta
services:
  web:
    project: ./src/web
    dist: build
    language: js
    host: appservice
  api:
    project: ./src/api
      language: js
      host: appservice
infra:
  provider: terraform

propriedades de services

Exemplo de opções do Docker

No exemplo a seguir, declaramos as opções do Docker para um aplicativo de contêiner.

name: yourApp-aca
metadata:
    template: yourApp-aca@0.0.1-beta
services:
  api:
    project: ./src/api
    language: js
    host: containerapp
    docker:
      path: ./Dockerfile
      context: ../
  web:
    project: ./src/web
    language: js
    host: containerapp
    docker:
      remoteBuild: true

Propriedades de deployment do AKS

Propriedades de service do AKS

Propriedades de ingress do AKS

Exemplo do AKS com ganchos de nível de serviço

metadata:
  template: todo-nodejs-mongo-aks@0.0.1-beta
services:
  web:
    project: ./src/web
    dist: build
    language: js
    host: aks
    hooks:
      postdeploy:
        shell: sh
        run: azd env set REACT_APP_WEB_BASE_URL ${SERVICE_WEB_ENDPOINT_URL}
  api:
    project: ./src/api
    language: js
    host: aks
    k8s:
      ingress:
        relativePath: api
    hooks:
      postdeploy:
        shell: sh
        run: azd env set REACT_APP_API_BASE_URL ${SERVICE_API_ENDPOINT_URL}

propriedades de pipeline

Azure Pipelines (AzDo) como um exemplo de pipeline de CI/CD

name: yourApp
services:  
  web:    
    project: src/web
    dist: build
    language: js
    host: appservice
pipeline: 
  provider: azdo

propriedades de workflows

propriedades de up

propriedades de steps

Fluxo de trabalho de exemplo

O arquivo azure.yaml a seguir altera o comportamento padrão de azd up para mover a etapa azd package após a etapa azd provision usando um fluxo de trabalho. Este exemplo pode ser usado em cenários em que você precisa saber as URLs dos recursos durante o processo de build ou empacotamento.

name: todo-nodejs-mongo
metadata:
  template: todo-nodejs-mongo@0.0.1-beta
workflows:
  up: 
    steps:
      - azd: provision
      - azd: deploy --all

Solicitar ajuda

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

Próximas etapas

• Saiba mais sobre a CLI do Desenvolvedor do Azure
• Introdução ao azd init e ao azd up