Compartilhar via

Esquema azure.yaml da CLI do Desenvolvedor do Azure

  • Artigo

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 abaixo um exemplo genérico de um azure.yaml necessário para seu modelo de 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

Nome do elemento Necessário Descrição
name Y (cadeia de caracteres) Nome do aplicativo.
resourceGroup N (cadeia de caracteres) Nome do grupo de recursos do Azure. Quando especificado, substituirá o nome do grupo de recursos usado para provisionamento de infraestrutura.
metadata N (objeto) Consulte as propriedades de metadados para obter mais detalhes.
infra N (objeto) Fornece configuração extra para provisionamento de infraestrutura do Azure. Consulte propriedades infra para obter mais detalhes.
services Y (objeto) Definição de serviços que compõem o aplicativo. Consulte propriedades de serviços para obter mais detalhes.
pipeline N (objeto) Definição de pipeline de integração contínua. Consulte propriedades de pipeline para obter mais detalhes.
hooks N Ganchos de nível de comando. Os ganchos devem corresponder azd nomes de comando prefixados com pre ou post dependendo de quando o script deve ser executado. Ao especificar caminhos, eles devem ser relativos ao caminho do projeto. Consulte Personalizar seus fluxos de trabalho da CLI do Desenvolvedor do Azure usando comando e ganchos de evento para obter mais detalhes.
requiredVersions N Uma variedade de versões com suporte de azd para este projeto. Se a versão do azd estiver fora desse intervalo, o projeto falhará ao carregar. Opcional (permite todas as versões, se ausente). Exemplo: >= 0.6.0-beta.3

propriedades de metadata

Nome do elemento Necessário Descrição Exemplo
template N (cadeia de caracteres) Identificador do modelo do qual o aplicativo foi criado. todo-nodejs-mongo@0.0.1-beta

propriedades de infra

Nome do elemento Necessário Descrição Exemplo
provider N (cadeia de caracteres) o provedor de infraestrutura para os recursos do Azure do aplicativo. (Padrão: bicep). Veja o de exemplo do Terraform abaixo. bicep, terraform
path N (cadeia de caracteres) o caminho da pasta relativa para o local que contém modelos de provisionamento do Azure para o provedor especificado. (Padrão: infra).
module N (cadeia de caracteres) O nome do módulo padrão com os modelos de provisionamento do Azure. (Padrão: principal).

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

Nome do elemento Necessário Descrição Exemplo
resourceName N (cadeia de caracteres) Nome do recurso do Azure que implementa o serviço. Se não for especificado, azd procurará um recurso azd-env-name e azd-service-name marcas. Se não for encontrado, ele procurará um nome de recurso construído a partir do nome do ambiente atual, concatenado com o nome do serviço (<environment-name><resource-name>). prodapi
project Y (cadeia de caracteres) Caminho para o diretório do código-fonte do serviço.
host Y (cadeia de caracteres) tipo de recurso do Azure usado para implementação de serviço. Se omitido, o Serviço de Aplicativo será assumido. appservice, containerapp, function, staticwebapp, aks (somente para projetos implantáveis por meio de kubectl apply -f), springapp (quando habilitado – saiba mais sobre recursos alfa)
language Y (cadeia de caracteres) linguagem de implementação do serviço. dotnet, csharp, fsharp, py, python, js, ts, java
module Y (cadeia de caracteres) Caminho do módulo de infraestrutura usado para implantar o serviço em relação à pasta infra raiz. Se omitida, a CLI assumirá que o nome do módulo é o mesmo que o nome do serviço.
dist Y (cadeia de caracteres) caminho relativo para os artefatos de implantação de serviço. A CLI usará arquivos nesse caminho para criar o artefato de implantação (.zip arquivo). Se omitido, todos os arquivos no diretório do projeto de serviço serão incluídos. build
docker N Aplicável somente quando host é containerapp. Não é possível conter propriedades extras. Veja o de exemplo personalizado do Docker abaixo. path (cadeia de caracteres): caminho para o Dockerfile. Padrão: ./Dockerfile; context(cadeia de caracteres): o contexto de build do Docker. Quando especificado, substitui o contexto padrão. Padrão: .; platform(cadeia de caracteres): o destino da plataforma. Padrão: amd64; remoteBuild(booliano): habilita builds remotos do ACR. Padrão: false
k8s N As opções de configuração do AKS (Serviço de Kubernetes do Azure). Veja o de exemplo do AKS abaixo. deploymentPath (cadeia de caracteres): opcional. O caminho relativo do caminho do serviço para os manifestos de implantação k8s. Quando definido, ele substituirá o local de caminho de implantação padrão para manifestos de implantação k8s. Padrão: manifests; namespace(cadeia de caracteres): opcional. O namespace k8s dos recursos implantados. Quando especificado, um novo namespace k8s será criado se ele ainda não existir. Padrão: Project name; deployment(objeto): consulte as propriedades de implantação ; service(objeto): consulte as propriedades do serviço ; ingress(objeto): consulte propriedades de entrada.
hooks N Ganchos de nível de serviço. Os ganchos devem corresponder service nomes de evento prefixados com pre ou post dependendo de quando o script deve ser executado. Ao especificar caminhos, eles devem ser relativos ao caminho do serviço. Consulte Personalizar seus fluxos de trabalho da CLI do Desenvolvedor do Azure usando comando e ganchos de evento para obter mais detalhes.
apiVersion N Especifique um api-version explícito ao implantar serviços hospedados pelos Aplicativos de Contêiner do Azure (ACA). Esse recurso ajuda você a evitar o uso de uma versão incompatível da API e torna a implantação mais flexível para evitar perder dados de configuração personalizados durante o marshaling JSON para uma versão de biblioteca do SDK do Azure codificada. apiVersion: 2024-02-02-preview

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

Nome do elemento Necessário Descrição Exemplo
name N (cadeia de caracteres) Opcional. O nome do recurso de implantação k8s a ser usado durante a implantação. Usado durante a implantação para garantir se a distribuição de implantação k8s foi concluída. Se não estiver definido, procurará um recurso de implantação no mesmo namespace que contém o nome do serviço. Padrão: Service name api

Propriedades de service do AKS

Nome do elemento Necessário Descrição Exemplo
name N (cadeia de caracteres) Opcional. O nome do recurso de serviço k8s a ser usado como o ponto de extremidade de serviço padrão. Usado ao determinar pontos de extremidade para o recurso de serviço padrão. Se não estiver definido, procurará um recurso de implantação no mesmo namespace que contém o nome do serviço. (Padrão: nome do serviço) api

Propriedades de ingress do AKS

Nome do elemento Necessário Descrição Exemplo
name N (cadeia de caracteres) Opcional. O nome do recurso de entrada k8s a ser usado como o ponto de extremidade de serviço padrão. Usado ao determinar pontos de extremidade para o recurso de entrada padrão. Se não estiver definido, procurará um recurso de implantação no mesmo namespace que contém o nome do serviço. Padrão: Service name api
relativePath N (cadeia de caracteres) Opcional. O caminho relativo para o serviço da raiz do controlador de entrada. Quando definido, será acrescentado à raiz do caminho do recurso de entrada.

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

Nome do elemento Necessário Descrição Exemplo
provider N (cadeia de caracteres) o provedor de pipeline a ser usado para integração contínua. (Padrão: github). github, azdo

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

Nome do elemento Tipo Necessário Descrição
em cima objeto Não Quando especificado, substituirá o comportamento padrão para o fluxo de trabalho do azd up.

propriedades de up

Nome do elemento Tipo Necessário Descrição
Passos array Sim As etapas a serem executadas no fluxo de trabalho.

propriedades de steps

Nome do elemento Tipo Necessário Descrição
azd corda Sim O nome e o args do comando azd a ser executado.

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