Visão geral dos modelos do Azure Developer CLI

Os modelos do Azure Developer CLI (azd) são repositórios de código regulares que incluem código de aplicação de exemplo, bem como arquivos de configuração e infraestrutura azd. Os azd templates 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 geralmente enfrentam muitas tarefas demoradas e desafiadoras ao criar aplicativos devidamente projetados e configurados com reconhecimento de ambiente 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 azd reduzem e simplificam essas responsabilidades para ajudar o desenvolvedor em sua jornada do desenvolvimento local até um aplicativo que foi implantado com sucesso 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 azd você pode utilizar modelos de arquitetura existentes para provisionar e implantar a maioria dos recursos para você. 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 usando um azd template existente inclui as seguintes etapas:

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

   azd init --template todo-nodejs-mongo
   

2. Use 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 do modelo no Azure. O comando azd up aproveita os arquivos de configuração e de infraestrutura como código (IaC) 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.

Explorar a estrutura de modelo da CLI do desenvolvedor do Azure

azd os modelos são repositórios de código padrão com alguns ativos adicionais incluídos. Todos os azd modelos compartilham uma estrutura de arquivo semelhante com base em azd convenções:

• Pasta infra – Contém toda a infraestrutura do Bicep ou do Terraform como arquivos de código para o modelo azd. azd executa esses arquivos para criar os recursos do Azure necessários para hospedar seu aplicativo.
• azure.yaml arquivo – arquivo de configuração que mapeia pastas de código-fonte em seu projeto para 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 em pastas separadas e mapeá-los para diferentes recursos do Azure para implantação.
• Pasta .azure – Contém as variáveis de ambiente e as configurações essenciais do Azure, como o local para implantar recursos ou outras informações da assinatura.
• Pasta src – Contém todo o código-fonte do aplicativo implantável. Alguns modelos excluem a pasta e só fornecem recursos de infraestrutura para que você possa adicionar seu próprio código de aplicativo.

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

Captura de tela que mostra uma estrutura de modelo do Azure Developer CLI.

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

• Pasta .github – 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.
• .azdo pasta - Se você decidir usar o Azure Pipelines para CI/CD, defina os arquivos de configuração de fluxo de trabalho nesta pasta.
• Pasta .devcontainer – permite que você configure um ambiente de Contêiner de Desenvolvimento para seu aplicativo.

Começar com um modelo existente ou crie o seu

Há duas abordagens principais para trabalhar com azd templates:

• 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 recursos 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 seguintes azd modelos fornecem pontos de partida para arquiteturas de aplicativos e frameworks comuns.

Criar um novo modelo azd para seu aplicativo

Você também pode converter um aplicativo existente em um modelo 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 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:

• Criar 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