Implantação de pilha completa com a CLI do Desenvolvedor do Azure

Aplicativos full-stack que combinam serviços front-end e back-end são um padrão comum no desenvolvimento web moderno. A CLI do Desenvolvedor do Azure (azd) suporta a implantação de aplicativos full stack, onde o front-end e o back-end são hospedados como serviços separados. Este artigo explica como implantar aplicações full-stack usando azd e destaca estratégias e benefícios para uma implantação eficaz.

O que é uma implantação full stack?

Uma implantação de pilha completa com azd normalmente consiste em:

• Serviço front-end: um aplicativo Web voltado para o usuário, geralmente criado com estruturas como React, Angular, Vue ou Blazor. O front-end pode ser hospedado como um site estático ou como um aplicativo em contêineres.
• Serviço de back-end: uma API ou uma camada de serviço que lida com lógica de negócios, acesso a dados e integrações. O back-end normalmente é hospedado em contêineres ou como funções sem servidor.
• Recursos compartilhados: bancos de dados, contas de armazenamento, cofres de chaves e outros recursos do Azure que ambos os serviços podem usar.

Ao usar azd, você pode definir ambos os serviços em um único azure.yaml arquivo e provisioná-los juntos usando a infraestrutura como código (Bicep ou Terraform).

Ciclo de vida da CLI do Desenvolvedor do Azure

A CLI do Desenvolvedor do Azure segue um fluxo de trabalho estruturado com eventos distintos do ciclo de vida:

1. Pacote: crie o código-fonte do aplicativo e prepare artefatos para implantação.
2. Provisionar: Criar ou atualizar recursos de infraestrutura do Azure usando Bicep ou Terraform.
3. Implantar: implante o código do aplicativo empacotado na infraestrutura provisionada.

O azd up comando executa todas as três fases sequencialmente. Você também pode executar cada fase de forma independente usando azd package, azd provisione azd deploy para um controle mais granular. Entender esse ciclo de vida é essencial para gerenciar dependências entre serviços, especialmente em implantações full-stack nas quais o tempo e a ordem são importantes.

Para mais informações sobre o azd ciclo de vida e a personalização do fluxo de trabalho, veja Como funciona o fluxo de trabalho azd up.

Considerações de design de infraestrutura

Ao criar um aplicativo de pilha completa com azd, escolha os serviços de hospedagem apropriados do Azure para seu front-end e back-end:

Tipo de serviço	Opções de hospedagem	Caso de uso
Front-end	Aplicativos Web Estáticos do Azure, Serviço de Aplicativo do Azure, Aplicativos de Contêiner do Azure	Sites estáticos, SPAs, aplicativos renderizados pelo servidor
Parte de retaguarda	Aplicativos de Contêiner do Azure, Serviço de Aplicativo do Azure, Azure Functions, Serviço de Kubernetes do Azure	APIs, microsserviços, funções sem servidor

Saiba mais sobre como hospedar aplicativos no Azure.

Entender a interdependência entre aplicativos front-end e back-end

As implantações de pilha completa frequentemente encontram problemas de dependência circular, nos quais cada serviço precisa de informações sobre o outro antes que este possa ser totalmente configurado. Entender essas interdependências ajuda você a criar fluxos de trabalho de implantação eficazes.

O front-end precisa da URL do back-end: seu aplicativo front-end normalmente precisa saber a URL do ponto de extremidade da API de back-end no tempo de compilação ou no tempo de execução. No entanto, o serviço de back-end não tem uma URL até ser implantado no Azure.

O back-end precisa de URL de front-end: seu serviço de back-end pode precisar da URL de front-end para configurar as políticas do CORS, mas o front-end não tem uma URL até que seja implantada.

Dependências de recursos compartilhados: ambos os serviços podem depender de recursos compartilhados, como bancos de dados, cofres de chaves ou contas de armazenamento. Esses recursos devem ser provisionados antes que qualquer serviço possa ser configurado para usá-los.

Configuração específica do ambiente: ambientes diferentes (desenvolvimento, preparo, produção) exigem urls e configurações de ponto de extremidade diferentes, mas esses valores não são conhecidos até que o provisionamento seja concluído.

Entender estratégias de configuração

A CLI do Desenvolvedor do Azure lida com essas interdependências por meio de duas abordagens:

• Configuração de tempo de implantação: resolver dependências durante o provisionamento e a implantação
• Configuração de runtime: adiar a configuração de dependência para quando o aplicativo for executado

Essas abordagens representam decisões de design que você toma ao criar seu aplicativo. Você pode usar uma estratégia exclusivamente ou combinar ambas, dependendo da arquitetura e dos requisitos.

Configuração de tempo de implantação

A configuração em tempo de implantação significa que as conexões e configurações de serviço são determinadas e bloqueadas durante as fases de azd provision e azd deploy. Usando essa abordagem, você configura serviços com URLs de ponto de extremidade específicas, cadeias de conexão e outras informações de dependência antes que eles comecem a ser executados. Essa configuração se torna parte do ambiente do serviço implantado, seja como variáveis de ambiente ou em arquivos de configuração empacotados com a implantação.

Provisionamento primeiro da infraestrutura: quando você executa azd up ou azd provision, a infraestrutura é criada primeiro. Essa etapa gera as URLs e as cadeias de conexão necessárias antes do início da implantação, garantindo que os serviços dependentes tenham as informações necessárias.

Variáveis de saída: o Bicep e o Terraform podem gerar valores, como URLs e cadeias de conexão, após o provisionamento. Essas saídas ficam disponíveis como variáveis de ambiente durante a fase de implantação, para que você possa configurar serviços com os pontos de extremidade corretos antes de serem iniciados.

Implantação sequencial: para cenários complexos, talvez seja necessário implantar serviços em uma ordem específica. Use azdganchos para controlar a sequência de implantação, garantindo que os serviços necessários estejam em execução antes que os serviços dependentes sejam implantados.

Padrão upsert de contêiner: os Módulos Verificados do Azure (AVM) oferecem padrões de aplicativos de contêiner, como container-app-upsert que funcionam perfeitamente com o fluxo de trabalho de duas fases do azd. Durante o provisionamento, a infraestrutura e o contêiner inicial são criados. Durante a implantação, azd aumenta a imagem de contêiner com variáveis de ambiente atualizadas que incluem valores gerados durante o provisionamento, como cadeias de conexão de banco de dados ou URLs de serviço. Esse padrão resolve o problema de frango e ovo, permitindo que a infraestrutura exista primeiro e, em seguida, atualizando a configuração do contêiner com todas as informações de dependência necessárias.

Exemplo de fluxo de trabalho para um front-end do React com um back-end da API de contêiner:

1. Execute azd up, que executa as fases de pacote, provisionamento e implantação sequencialmente.
2. Durante o provisionamento, o Bicep cria a infraestrutura de Aplicativos de Contêiner do Azure usando módulos AVM container-app-upsert e gera a URL da API de back-end.
3. Durante a implantação, azd atualiza ou insere automaticamente os dois contêineres com as variáveis de ambiente corretas, incluindo a URL da API para o front-end.
4. Ambos os serviços começam com a configuração correta. Execuções futuras de azd up ou azd deploy atualizam os contêineres com novos valores de configuração.

Configuração de runtime

A configuração de runtime permite que os aplicativos carreguem a configuração quando o aplicativo é executado em vez de durante a implantação. Essa abordagem fornece flexibilidade para atualizar pontos de extremidade de serviço, cadeias de conexão e políticas sem reimplantar seu aplicativo.

Fontes de configuração: os aplicativos podem carregar a configuração de runtime de duas fontes primárias:

• Arquivos de configuração locais: implante um arquivo de configuração, como config.json, ao lado do aplicativo. O aplicativo carrega esse arquivo na inicialização para obter URLs de ponto de extremidade atuais, configurações de autenticação e outros valores de configuração. Essa abordagem funciona bem para estruturas do lado do cliente, como React, Angular, Vue e Blazor WebAssembly, que podem buscar a configuração quando o aplicativo é iniciado no navegador.

• Serviços de configuração de nuvem: use a Configuração de Aplicativos do Azure ou serviços semelhantes para gerenciar centralmente a configuração em todos os ambientes. Os aplicativos consultam o serviço de configuração na inicialização ou sob demanda para recuperar os valores atuais. Essa abordagem é útil para arquiteturas de microsserviços em que vários serviços precisam de atualizações de configuração coordenadas.

Benefícios: com qualquer abordagem, as alterações de configuração ficam disponíveis imediatamente sem reimplantação. Atualize o arquivo de configuração por meio do pipeline de implantação ou altere os valores na Configuração de Aplicativos do Azure por meio do portal do Azure. Quando o aplicativo reinicia ou atualiza sua configuração, ele capta os novos valores. Esse padrão é especialmente útil para:

• Aplicativos front-end que precisam descobrir URLs de API de back-end, endereços de autenticação e localizações de microsserviços
• Serviços de back-end que precisam atualizar as políticas do CORS à medida que as URLs de front-end são alteradas
• Serviços que precisam de configuração diferente em ambientes de desenvolvimento, preparo e produção

Exemplo de fluxo de trabalho para um front-end do React descobrindo uma API de back-end:

1. Execute azd up para provisionar a infraestrutura e implantar ambos os serviços.
2. Um gancho pós-implantação gera um arquivo config.json contendo a URL do back-end e o carrega para o local de armazenamento do front-end.
3. O aplicativo React busca config.json na inicialização para descobrir o ponto de extremidade da API.
4. Para atualizar o ponto de extremidade mais tarde, modifique config.json sem reimplantar o front-end.

Essa abordagem não funciona para sites gerados estaticamente em que todo o conteúdo é pré-renderizado no momento do build.

Planejar seu fluxo de trabalho de implantação

Considere esses fatores ao projetar sua implantação de pilha completa:

1. Identificar dependências: mapeie quais serviços precisam de informações de outros serviços. Para dependências unidirecionais (como uma API dependendo de um banco de dados), a plataforma de provisionamento (Bicep ou Terraform) manipula a ordenação automaticamente. Para dependências circulares (como serviços de front-end e back-end que precisam das URLs uma da outra no início), você deve projetar a coordenação usando estratégias de configuração durante a implantação ou em tempo de execução.
2. Provisionar antes da implantação: verifique se toda a infraestrutura existe antes de implantar o código do aplicativo.
3. Use variáveis de ambiente: passe a configuração entre camadas de infraestrutura e de aplicativo usando variáveis de ambiente do azd.
4. Design para vários ambientes: planeje como a configuração difere entre ambientes de desenvolvimento, preparo e produção.
5. Considere a ordem de implantação: alguns cenários podem exigir a implantação de serviços em uma sequência específica.

O azd up comando manipula a maioria dos cenários de implantação executando automaticamente o provisionamento seguido pela implantação em um único fluxo de trabalho. Para aplicativos únicos padrão, essa abordagem funciona bem e requer uma configuração mínima.

Para implantações mais complicadas, como full stack com dependências circulares:

• Configurar a ordem de serviço: no azure.yaml arquivo, defina os serviços na ordem em que você deseja implantá-los. Enquanto azd implanta serviços em paralelo por padrão, você pode usar ganchos para impor a implantação sequencial quando necessário.

• Personalizar etapas de fluxo de trabalho: substitua o fluxo de trabalho padrão azd up definindo uma propriedade personalizada workflows em seu azure.yaml arquivo. Por exemplo, você pode alterar o comportamento padrão para executar o provisionamento antes de criar o código-fonte do aplicativo:

  name: todo-nodejs-mongo
  metadata:
    template: todo-nodejs-mongo@0.0.1-beta
  workflows:
    up: 
      steps:
        - azd: provision
        - azd: package
        - azd: deploy
  

  Esse padrão é útil quando o processo de build precisa de valores de configuração que só estão disponíveis após a conclusão do provisionamento.

• Provisionar e implantar separados: em vez de usar azd up, execute azd provision e azd deploy como comandos separados. Essa separação é útil quando você precisa verificar a configuração da infraestrutura antes de implantar o código do aplicativo ou ao solucionar problemas de implantação. Você pode provisionar a infraestrutura uma vez e, em seguida, implantar e reimplantar o código do aplicativo várias vezes sem reprovisionar.

• Personalizar com ganchos: adicione ganchos pré e pós no seu arquivo azure.yaml para executar lógica personalizada entre as fases de provisionamento e implantação. Use ganchos para preencher arquivos de configuração, validar o estado do ambiente ou coordenar sequências de implantação complexas.

Práticas recomendadas

Ao criar aplicações full-stack com azd, siga estas práticas recomendadas:

1. Mapear dependências antecipadamente: identifique quais serviços precisam de informações de outros serviços durante a fase de design. Distinga entre dependências unidirecionais que o Bicep ou o Terraform manipulam automaticamente e as dependências circulares que exigem estratégias de configuração de tempo de implementação ou de tempo de execução.
2. Escolha a estratégia de configuração correta: use a configuração de tempo de implantação quando os serviços precisarem de configuração bloqueada na implantação. Use a configuração de runtime quando precisar de flexibilidade para atualizar a configuração sem reimplantação. Combine ambas as estratégias quando apropriado.
3. Utilize Módulos Verificados do Azure (AVM): aproveite os módulos Bicep dos Módulos Verificados do Azure, como container-app-upsert para aplicativos de contêiner. Esses padrões funcionam perfeitamente com azd fluxo de trabalho de duas fases para solucionar dependências circulares.
4. Personalizar fluxos de trabalho quando necessário: para implantações simples, use azd up com configurações padrão. Para cenários complexos com dependências circulares, personalize a propriedade workflows no arquivo azure.yaml para controlar a ordem das etapas de pacote, provisionamento e implantação.
5. Aproveite a configuração de runtime: para obter flexibilidade máxima entre ambientes, use a Configuração de Aplicativo do Azure ou arquivos de configuração locais para gerenciar pontos de extremidade de serviço e configurações que você pode atualizar sem reimplantação.
6. Teste entre ambientes: verifique se sua estratégia de configuração funciona corretamente em ambientes de desenvolvimento, preparo e produção em que as URLs e as configurações de serviço diferem.

Próximas etapas

• Implantar em Aplicativos de Contêiner do Azure usando a CLI do Desenvolvedor do Azure
• Modelos de implantação full-stack
• Visão geral dos modelos da CLI do Desenvolvedor do Azure
• Explorar o fluxo de trabalho do azd up