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
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
(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).
(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.
(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
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 .