Share via

Esquema azure.yaml da CLI do Azure Developer

  • 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 específicos de aplicativo 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.

Exemplo

Abaixo está um exemplo genérico de um azure.yaml necessário para o seu azd modelo.

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 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ção dos imóveis

Nome do Elemento Obrigatório Description
name Y (string) Nome do pedido.
resourceGroup N (string) 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 dos metadados para obter mais detalhes.
infra N (objeto) Fornece configuração extra para provisionamento de infraestrutura do Azure. Consulte as propriedades infra para obter mais detalhes.
services Y (objeto) Definição dos serviços que compõem a aplicação. Consulte as propriedades dos serviços para obter mais detalhes.
pipeline N (objeto) Definição de pipeline de integração contínua. Consulte as propriedades do pipeline para obter mais detalhes.
hooks N Ganchos de nível de comando. Os ganchos devem corresponder azd a 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 ganchos de comando e evento para obter mais detalhes.
requiredVersions N Uma gama de versões suportadas para azd este projeto. Se a versão do azd estiver fora desse intervalo, o projeto não será carregado. Opcional (permite todas as versões se ausentes). Exemplo: >= 0.6.0-beta.3

Propriedades de metadata

Nome do Elemento Obrigatório Description Exemplo
template N (string) Identificador do modelo a partir do qual o aplicativo foi criado. todo-nodejs-mongo@0.0.1-beta

Propriedades de infra

Nome do Elemento Obrigatório Description Exemplo
provider N (string) O provedor de infraestrutura para os recursos do Azure do aplicativo. (Padrão: bíceps). Veja o exemplo de Terraform abaixo. bicep, terraform
path N (string) O caminho da pasta relativa para o local que contém os modelos de provisionamento do Azure para o provedor especificado. (Padrão: infra).
module N (string) O nome do módulo padrão com os modelos de provisionamento do Azure. (Padrão: principal).

Terraform como amostra de provedor 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 Obrigatório Description Exemplo
resourceName N (string) Nome do recurso do Azure que implementa o serviço. Se não for especificado, azd procurará um recurso por azd-env-name e azd-service-name tags. 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 (string) Caminho para o diretório do código-fonte do serviço.
host Y (string) Tipo de recurso do Azure usado para implementação de serviço. Se omitido, o Serviço de Aplicativo será assumido. appservice, , , , containerappstaticwebappfunction( aks somente para projetos implantáveis via kubectl apply -f), springapp (quando ativado - saiba mais sobre os recursos alfa)
language Y (string) Linguagem de implementação do serviço. dotnet, , , , , , ts, fsharpcsharpjspypythonjava
module Y (string) Caminho do módulo de infraestrutura usado para implantar o serviço relativo à pasta infra raiz. Se omitida, a CLI assumirá que o nome do módulo é o mesmo que o nome do serviço.
dist Y (string) Caminho relativo para os artefatos de implantação de serviço. A CLI usará arquivos sob esse caminho para criar o artefato de implantação (arquivo .zip). Se omitido, todos os arquivos no diretório do projeto de serviço serão incluídos. build
docker N Aplicável apenas quando host é containerapp. Não pode conter propriedades extras. Consulte o exemplo personalizado do Docker abaixo. path(string): Caminho para o Dockerfile. Padrão: ./Dockerfile; context(string): O contexto de construção do docker. Quando especificado, substitui o contexto padrão. Padrão: .; platform(string): O destino da plataforma. Predefinição: amd64
k8s N As opções de configuração do Serviço Kubernetes do Azure (AKS). Veja o exemplo AKS abaixo. deploymentPath(string): Opcional. O caminho relativo do caminho de serviço para os manifestos de implantação do k8s. Quando definido, ele substituirá o local do caminho de implantação padrão para manifestos de implantação do k8s. Padrão: manifests; namespace(string): Opcional. O namespace k8s dos recursos implantados. Quando especificado, um novo namespace k8s será criado se ainda não existir. Padrão: Project name; deployment(objeto): Consulte as propriedades de implantação; service(objeto): Ver propriedades do serviço; ingress(objeto): Consulte as propriedades de ingresso.
hooks N Ganchos de nível de serviço. Os ganchos devem corresponder service a nomes de eventos prefixados com pre ou post dependendo de quando o script deve ser executado. Ao especificar caminhos, eles devem ser relativos ao caminho de serviço. Consulte Personalizar seus fluxos de trabalho da CLI do Desenvolvedor do Azure usando ganchos de comando e evento para obter mais detalhes.

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

Propriedades AKS deployment

Nome do Elemento Obrigatório Description Exemplo
name N (string) Opcional. O nome do recurso de implantação do k8s a ser usado durante a implantação. Usado durante a implementação para garantir que a implementação do 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. Predefinição: Service name api

Propriedades AKS service

Nome do Elemento Obrigatório Description Exemplo
name N (string) 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 AKS ingress

Nome do Elemento Obrigatório Description Exemplo
name N (string) Opcional. O nome do recurso de entrada do 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. Predefinição: Service name api
relativePath N (string) Opcional. O caminho relativo para o serviço a partir da raiz do seu controlador de entrada. Quando definido, será anexado à raiz do seu caminho de recurso de entrada.

Exemplo de 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 Obrigatório Description Exemplo
provider N (string) 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

Pedir 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 de solução de problemas e suporte .

Próximos passos