Visão geral dos modelos do Azure Developer CLI

Os modelos do Azure Developer CLI (azd) são repositórios de código padrão que incluem códigos de aplicativos de exemplo, bem como azd arquivos de configuração e infraestrutura. Os modelos do azd permitem que você provisione recursos do Azure, implante seu aplicativo, configure pipelines de CI/CD e muito mais. Você pode criar seus próprios modelos ou começar a usar um modelo existente de um repositório de modelos, como o Awesome AZD. Neste artigo, você conhecerá melhor os seguintes conceitos:

• Como os modelos do azd permitem provisionar e implantar recursos de aplicativos
• Como os modelos do azd são estruturados
• Como decidir se você quer usar um modelo existente ou criar um
• Explore os modelos para iniciantes da azd

Por que usar modelos do Azure Developer CLI?

Os desenvolvedores frequentemente enfrentam muitas tarefas demoradas e desafiadoras ao criar aplicativos de ambiente devidamente arquitetados e configurados para a nuvem. As equipes precisam considerar muitas preocupações diferentes nesses ambientes, como a criação de recursos, a aplicação de configurações, a configuração de monitoramento e de logs, a criação de pipelines de CI/CD e outras tarefas. Os modelos do azd reduzem e simplificam essas responsabilidades para ajudar o desenvolvedor em sua jornada do desenvolvimento local a um aplicativo implantado com êxito no Azure.

Por exemplo, imagine que você trabalha em uma empresa que opera uma plataforma de gerenciamento de tíquetes e comunicação com clientes, que requer os seguintes recursos do Azure:

• Duas instâncias de Serviços de Aplicativos e um Plano de Serviço de Aplicativo para hospedar um aplicativo Web de front-end e uma API de back-end
• Uma instância do Key Vault para armazenar segredos seguros do aplicativo
• Um banco de dados Cosmos DB para armazenar permanentemente os dados do aplicativo
• Recursos do Azure Monitor, como painéis do Application Insights
• Um Barramento de Serviço para gerenciar as mensagens escalonáveis
• Pipelines de CI/CD para garantir que as alterações sejam implantadas de maneira confiável por meio de um processo automatizado.

Em vez de começar do zero, com o azd você pode utilizar modelos de arquitetura existentes para provisionar e implantar a maioria dos recursos. A equipe de desenvolvimento pode se concentrar na criação do aplicativo e em fazer ajustes menores na arquitetura do modelo.

Como funcionam os modelos do Azure Developer CLI

Os modelos do Azure Developer CLI são criados para funcionar com azd comandos como azd init e azd up. Os modelos incluem arquivos de configuração e IaC (infraestrutura como código) que são usados pelos comandos para realizar tarefas como provisionar recursos do Azure e implantar o código do aplicativo neles.

Por exemplo, um fluxo de trabalho típico do azd que usa um modelo existente inclui as seguintes etapas:

1. Execute o comando azd init com o parâmetro --template para clonar um modelo existente do GitHub.

   azd init --template todo-nodejs-mongo
   

2. Execute o comando azd auth login para autenticar sua assinatura do Azure.

   azd auth login
   

3. Execute o comando azd up para provisionar e implantar os recursos de modelos no Azure. O comando azd up utiliza os arquivos de configuração e IaC (infraestrutura como código) em seu modelo para provisionar recursos do Azure e implantar seu aplicativo nesses recursos.

   azd up
   

4. Depois que o ambiente for configurado no Azure, você poderá modificar localmente os recursos do aplicativo ou os modelos de recursos do Azure e, em seguida, executar azd up novamente para provisionar as alterações.

Entender a estrutura do modelo do Azure Developer CLI

Todos os modelos do azd compartilham uma estrutura de arquivo semelhante com base em convenções do azd. Os ativos mínimos exigidos geralmente incluem o seguinte:

• infra pasta - Contém toda a infraestrutura do Bicep ou do Terraform como arquivos de código para o modelo do azd. Esses arquivos são executados pelo azd para criar os recursos do Azure necessários para hospedar seu aplicativo.

• azure.yaml Arquivo: um arquivo de configuração que define um ou mais serviços no seu projeto e os mapeia para os recursos do Azure definidos na pasta infra para implantação. Por exemplo, você pode definir um serviço de API e um serviço de front-end da Web e mapeá-los para diferentes recursos do Azure para implantação.

• .azure Pasta - Contém configurações essenciais do Azure e variáveis de ambiente, como o local para implantar recursos ou outras informações da assinatura.

• src Pasta: contém todo o código-fonte do aplicativo implantável. Alguns modelos do azd excluem a pasta src e só fornecem recursos de infraestrutura para que você possa adicionar seu próprio código de aplicativo.

  Observação

  Os modelos que excluem a pasta src geralmente são criados como modelos de infraestrutura para iniciantes.

Opcionalmente, os modelos do azd incluem uma ou mais destas pastas:

• .github Pasta: contém os arquivos de fluxo de trabalho de CI/CD para o GitHub Actions, que é o provedor de CI/CD padrão do azd.
• .azdoPasta - Se você decidir usar o Azure Pipelines para CI/CD, defina os arquivos de configuração de fluxo de trabalho nessa pasta.
• .devcontainer Pasta: permite que você configure um ambiente de Contêiner de Desenvolvimento para seu aplicativo.

Por exemplo, um modelo comum do azd pode corresponder à seguinte estrutura de pastas:

Começar com um modelo existente ou crie o seu

Há duas abordagens principais para trabalhar com os modelos do azd:

• Comece com um azd modelo existente.
  • Essa é uma boa opção se você está apenas começando a usar o azd ou se está procurando um modelo para criar um novo aplicativo com arquitetura e estruturas semelhantes.
• Converta um projeto existente em um azd modelo.
  • Essa é uma boa opção quando você já tem um aplicativo existente, mas deseja torná-lo compatível com os recurso do azd.

As seções a seguir fornecem mais informações sobre essas duas opções.

Começar com um modelo existente

Há uma ampla seleção de modelos do azd disponíveis na galeria de modelos do awesome-azd. Esses modelos fornecem infraestrutura e código de aplicativo para diversos cenários de desenvolvimento, estruturas de linguagem e serviços do Azure. Se você encontrar um modelo que se alinhe à sua pilha de aplicativos local ou à arquitetura desejada, poderá estender e substituir o código do modelo pelo seu próprio código

Por exemplo, os modelos do azd a seguir são pontos de partida para arquiteturas e estruturas de aplicativos comuns:

Criar um modelo do azd para seu aplicativo

Você também pode converter um aplicativo existente em um modelo do azd para aprimorar o repositório com recursos de provisionamento e implantação. Essa abordagem permite o maior controle e produz uma solução reutilizável para futuros trabalhos de desenvolvimento no aplicativo. As etapas de alto nível para criar seu modelo são as seguintes:

• Inicialize o modelo de projeto com o azd init.
• Crie a infraestrutura do Bicep ou do Terraform como arquivos de código na pasta infra.
• Atualize o arquivo azure.yaml para vincular os serviços de aplicativo aos recursos do Azure.
• Provisione e implemente com azd up.

Os recursos a seguir fornecem mais informações sobre como criar seus próprios modelos:

• Crie seu primeiro modelo do Azure Developer CLI
• Tornar seu projeto compatível com o guia do azd

Diretrizes para o uso de modelos do azd

Cada modelo que você usa com o Azure Developer CLI é licenciado pelo seu respectivo proprietário (que pode ou não ser a Microsoft) de acordo com o contrato que acompanha o modelo. É sua responsabilidade determinar qual licença se aplica a qualquer modelo que você escolher usar.

A Microsoft não é responsável por nenhum modelo que não seja da Microsoft e não analisa esses modelos quanto a problemas de segurança, privacidade, compatibilidade ou desempenho. Os modelos que você usa com o Azure Developer CLI, incluindo aqueles fornecidos pela Microsoft, não são compatíveis com nenhum programa ou serviço de suporte da Microsoft. Todos os modelos fornecidos pela Microsoft são fornecidos NO ESTADO EM QUE SE ENCONTRAM, sem garantia de nenhum tipo.

Próximas etapas