Compartilhar via


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

Abaixo está um exemplo genérico de um necessário para o azure.yaml 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.yamlnosso 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 infra properties para obter mais detalhes.
services Y (objeto) Definição dos serviços que compõem o aplicativo. Consulte as propriedades de 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 variedade de versões suportadas do azd para 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 ausente). Exemplo: >= 0.6.0-beta.3

metadata propriedades

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

infra propriedades

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: bíceps). Veja o exemplo do Terraform abaixo. bicep, terraform
path N (cadeia de caracteres) 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 (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

services propriedades

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 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 (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, (somente para projetos implantáveis via kubectl apply -f), springapp (quando habilitado - saiba mais sobre os recursos alfa) aksstaticwebappfunction
language Y (cadeia de caracteres) Linguagem de implementação de 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 (arquivo .zip). 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 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 compilação do docker. Quando especificado, substitui o contexto padrão. Padrão: .; platform(string): O destino da plataforma. Padrão: amd64
k8s N As opções de configuração do Serviço de Kubernetes do Azure (AKS). Veja o exemplo de 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): 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 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 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 Necessário Descrição Exemplo
name N (cadeia de caracteres) Opcional. O nome do recurso de implantação do k8s a ser usado durante a implantação. Usado durante a implantação para garantir que a implantação do k8s tenha sido 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 AKS service

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 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 Necessário Descrição Exemplo
name N (cadeia de caracteres) Opcional. O nome do recurso de entrada k8s a ser usado como 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 a partir da raiz do controlador de entrada. Quando definido, será anexado à raiz do caminho do 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}

pipeline propriedades

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

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 .

Próximas etapas