Partilhar via

Implantação de DevOps para aplicativos lógicos padrão em aplicativos lógicos do Azure de locatário único

Aplica-se a: Aplicativos Lógicos do Azure (Padrão)

Com a tendência para aplicativos de nuvem distribuídos e nativos, as organizações estão lidando com mais componentes distribuídos em mais ambientes. Para manter o controle e a consistência, você pode automatizar seus ambientes e implantar mais componentes com mais rapidez e confiança usando ferramentas e processos de DevOps.

Este artigo fornece uma introdução e uma visão geral sobre a experiência atual de integração contínua e implantação contínua (CI/CD) para fluxos de trabalho de aplicativos lógicos padrão em Aplicativos Lógicos do Azure de locatário único.

Inquilino único versus multilocatário

Nos Aplicativos Lógicos do Azure multilocatário, a implantação de recursos é baseada em modelos do Azure Resource Manager (modelos ARM), que combinam e manipulam o provisionamento de recursos tanto para os recursos de aplicativo lógico de Consumo quanto para a infraestrutura. Nos Azure Logic Apps de alojamento único, a implementação torna-se mais fácil porque pode separar o provisionamento de recursos entre os recursos do Logic Apps Standard e a infraestrutura.

Quando se cria um recurso de aplicação lógica Padrão, os fluxos de trabalho são impulsionados pelo tempo de execução redesenhado de um único inquilino dos Azure Logic Apps. Esse tempo de execução usa o modelo de extensibilidade do Azure Functions e é hospedado como uma extensão no tempo de execução do Azure Functions. Esse design fornece portabilidade, flexibilidade e mais desempenho para aplicativos lógicos padrão, além de outros recursos e benefícios herdados da plataforma Azure Functions e do ecossistema do Serviço de Aplicativo do Azure.

Por exemplo, você pode empacotar o tempo de execução em contêiner redesenhado e fluxos de trabalho juntos como parte de seu aplicativo lógico padrão. Você pode usar etapas ou tarefas genéricas que criam, montam e compactam os recursos do aplicativo lógico em artefatos prontos para implantação. Para implantar aplicativos lógicos padrão, copie os artefatos para o ambiente host e inicie seus aplicativos para executar seus fluxos de trabalho. Ou integre os seus artefactos nas linhas de implantação utilizando as ferramentas e os processos que já conhece e usa. Por exemplo, se seu cenário exigir contêineres, você poderá colocar em contêineres aplicativos lógicos padrão e integrá-los aos pipelines existentes.

Para configurar e implantar seus recursos de infraestrutura, como redes virtuais e conectividade, você pode continuar usando modelos ARM e provisionar separadamente esses recursos junto com outros processos e pipelines que você usa para esses fins.

Usando opções padrão de compilação e implantação, você pode se concentrar no desenvolvimento de aplicativos separadamente da implantação de infraestrutura. Como resultado, você obtém um modelo de projeto mais genérico onde pode aplicar muitas opções de implantação semelhantes ou iguais que você usa para um aplicativo genérico. Você também se beneficia de uma experiência mais consistente para criar pipelines de implantação em torno de seus projetos de aplicativo e para executar os testes e validações necessários antes de publicar na produção. Não importa qual pilha de tecnologia você use, você pode implantar aplicativos lógicos usando suas próprias ferramentas escolhidas.

Recursos de implantação de DevOps

Os Azure Logic Apps isolados herdam muitos recursos e benefícios da plataforma Azure Functions e do ecossistema da Azure App Service. Essas atualizações incluem um modelo de implantação totalmente novo e mais maneiras de usar o DevOps para seus fluxos de trabalho de aplicativos lógicos.

Desenvolvimento local e testes

Ao usar o Visual Studio Code com a extensão Aplicativos Lógicos do Azure (Padrão), você pode desenvolver, criar e executar localmente fluxos de trabalho de aplicativos lógicos padrão em seu ambiente de desenvolvimento sem precisar implantar no Azure. Se o seu cenário exigir contentores, poderá criar e implantar por meio dos Aplicativos Lógicos habilitados para Azure Arc.

Esse recurso é uma grande melhoria e fornece um benefício substancial em comparação com o modelo multilocatário, que exige que você desenvolva em relação a um recurso existente e em execução no Azure.

Preocupações separadas

O modelo de locatário único oferece a capacidade de separar as preocupações entre seu aplicativo lógico e a infraestrutura subjacente. Por exemplo, você pode desenvolver, criar, compactar e implantar seu aplicativo separadamente como um artefato imutável em diferentes ambientes. Os fluxos de trabalho de aplicativos lógicos geralmente têm "código de aplicativo" que você atualiza com mais frequência do que a infraestrutura subjacente. Ao separar essas camadas, você pode se concentrar mais na criação do fluxo de trabalho do seu aplicativo lógico e gastar menos em seu esforço para implantar os recursos necessários em vários ambientes.

Diagrama conceitual mostrando pipelines de implantação separados para aplicativos e infraestrutura.

Estrutura de recursos do aplicativo lógico

No modelo multilocatário de Aplicativos Lógicos do Azure, a estrutura de recursos do aplicativo lógico de consumo pode incluir apenas um único fluxo de trabalho. Devido a essa relação um-para-um, o aplicativo lógico e o fluxo de trabalho são frequentemente considerados e referenciados como sinônimos. No entanto, no modelo de Aplicativos Lógicos do Azure de locatário único, a estrutura de recursos do aplicativo lógico padrão pode incluir vários fluxos de trabalho. Essa relação um-para-muitos significa que, no mesmo aplicativo lógico, os fluxos de trabalho podem compartilhar e reutilizar outros recursos. Os fluxos de trabalho no mesmo aplicativo lógico e no mesmo locatário também oferecem melhor desempenho devido a essa locação compartilhada e à proximidade entre si. Essa estrutura de recursos parece e funciona de forma semelhante ao Azure Functions, onde um aplicativo de função pode hospedar muitas funções.

Para obter mais informações e práticas recomendadas sobre como organizar fluxos de trabalho, desempenho e dimensionamento em seu aplicativo lógico, revise as diretrizes semelhantes para o Azure Functions que você geralmente pode aplicar aos Aplicativos Lógicos do Azure de locatário único.

Estrutura do projeto da aplicação lógica

No Visual Studio Code, seu projeto de aplicativo lógico tem um dos seguintes tipos:

  • Baseado em pacote de extensão (Node.js), que é o tipo padrão
  • Baseado no pacote NuGet (.NET), que pode ser convertido a partir do tipo padrão

Com base nesses tipos, seu projeto pode incluir pastas ou arquivos ligeiramente diferentes. Por exemplo, um projeto baseado em pacote Nuget tem uma pasta .bin que contém pacotes e outros arquivos de biblioteca. Um projeto baseado em pacote de extensão não inclui essa pasta .bin .

Alguns cenários exigem um projeto baseado em pacote NuGet para que seu aplicativo seja executado, por exemplo, quando você deseja desenvolver e executar operações internas personalizadas. Para mais informações sobre como converter o seu projeto para usar o NuGet, consulte Ativar a autoria de conectores integrados.

O projeto baseado em pacote de extensão padrão tem uma estrutura de pasta e arquivo semelhante ao exemplo a seguir:

MyWorkspaceName
| MyBundleBasedLogicAppProjectName
  || .vscode
  || Artifacts
     ||| Maps 
         |||| MapName1
         |||| ...
     ||| Rules
     ||| Schemas
         |||| SchemaName1
         |||| ...
  || lib
     ||| builtinOperationSdks
         |||| JAR
         |||| net472
     ||| custom
  || WorkflowName1
     ||| workflow.json
     ||| ...
  || WorkflowName2
     ||| workflow.json
     ||| ...
  || workflow-designtime
     ||| host.json
     ||| local.settings.json
  || .funcignore
  || connections.json
  || host.json
  || local.settings.json

No nível raiz do seu projeto, você pode encontrar as seguintes pastas e arquivos, juntamente com outros itens:

Nome Pasta ou ficheiro Descrição
.vscode Pasta Contém arquivos de configurações relacionados ao Visual Studio Code, como arquivos extensions.json, launch.json, settings.json e tasks.json .
Artefactos Pasta Contém artefatos de conta de integração que você define e usa em fluxos de trabalho que oferecem suporte a cenários B2B (business-to-business).

Por exemplo, a estrutura de exemplo inclui as seguintes pastas:

- Mapas: contém mapas a serem usados para operações de transformação XML.

- Esquemas: contém esquemas a serem usados para operações de validação XML.

- Regras: Artefatos para regras de negócios em projetos de mecanismos baseados em regras.
Lib Pasta Contém assemblies suportados que a sua aplicação lógica pode usar ou referenciar. Você pode carregar esses assemblies para seu projeto no Visual Studio Code, mas você deve adicioná-los a pastas específicas em seu projeto.

Por exemplo, esta pasta inclui as seguintes pastas:

- builtinOperationSdks: Contém as pastas JAR e net472 para assemblies Java e .NET Framework, respectivamente.

- custom: contém assemblies personalizados do .NET Framework.

Para obter mais informações sobre os tipos de assembly suportados e onde colocá-los em seu projeto, consulte Adicionar assemblies ao seu projeto.
< Nome do fluxo de trabalho> Pasta Para cada fluxo de trabalho, a <> inclui um arquivo workflow.json, que contém a definição JSON subjacente desse fluxo de trabalho.
workflow-designtime Pasta Contém arquivos de configurações relacionadas ao ambiente de desenvolvimento.
.funcignore Ficheiro Contém informações relacionadas às Ferramentas Principais do Azure Functions instaladas.
connections.json Ficheiro Contém os metadados, pontos de extremidade e chaves para quaisquer conexões geridas e funções do Azure que os seus fluxos de trabalho usam.

Importante: Para usar conexões e funções diferentes para cada ambiente, certifique-se de parametrizar esse arquivo de connections.json e atualizar os pontos de extremidade.
host.json Ficheiro Contém configurações e valores específicos do ambiente de execução, por exemplo, os limites padrão para a plataforma Azure Logic Apps monotenant, aplicações lógicas, fluxos de trabalho, ações e gatilhos. No nível raiz do seu projeto de aplicativo lógico, o arquivo de metadados host.json contém as definições de configuração e os valores padrão que todos os fluxos de trabalho no mesmo aplicativo lógico usam durante a execução, seja localmente ou no Azure. Para obter informações de referência, consulte Editar configurações do aplicativo e configurações do host.

Nota: Quando você cria seu aplicativo lógico, o Visual Studio Code cria um arquivo host.snapshot.*.json de backup em seu contêiner de armazenamento. Se você excluir seu aplicativo lógico, esse arquivo de backup não será excluído. Se você criar outro aplicativo lógico com o mesmo nome, outro arquivo de instantâneo será criado. Você pode ter apenas até 10 instantâneos para o mesmo aplicativo lógico. Se você exceder esse limite, você receberá o seguinte erro:

Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))

Para resolver esse erro, exclua os arquivos de instantâneo extras do contêiner de armazenamento.
local.settings.json Ficheiro Contém configurações de aplicativos, cadeias de conexão e outras configurações que seus fluxos de trabalho usam durante a execução local. Essas configurações e valores se aplicam somente quando você executa seus projetos em seu ambiente de desenvolvimento local. Durante a implantação no Azure, o arquivo e as configurações são ignorados e não são incluídos na sua implantação.

Esse arquivo armazena configurações e valores como variáveis de ambiente local que suas ferramentas de desenvolvimento local usam para os appSettings valores. Você pode chamar e fazer referência a essas variáveis de ambiente em tempo de execução e de implantação usando as configurações e os parâmetros do aplicativo.

Importante: O arquivo local.settings.json pode conter segredos, portanto, certifique-se de excluir esse arquivo do controle do código-fonte do projeto. Esse arquivo também contém as configurações do aplicativo que seu aplicativo lógico precisa para funcionar corretamente. Para obter informações de referência, consulte Editar configurações do aplicativo e configurações do host.

Desdobramento de contentores

Os Aplicativos Lógicos do Azure de locatário único dão suporte à implantação em contêineres, o que significa que você pode conteinerizar seus fluxos de trabalho de aplicativos lógicos e executá-los onde os contêineres podem ser executados. Depois de colocar seu aplicativo em contêineres, a implantação funciona basicamente da mesma forma que qualquer outro contêiner que você implanta e gerencia.

Para obter exemplos que incluem o Azure DevOps, revise CI/CD para contêineres.

Configurações e parâmetros do aplicativo

Nos Aplicativos Lógicos do Azure multilocatário, os modelos ARM representam um desafio quando você precisa manter variáveis de ambiente para aplicativos lógicos em vários ambientes de desenvolvimento, teste e produção. Tudo em um modelo ARM é definido na implantação. Se você precisar alterar apenas uma única variável, terá que reimplantar tudo.

Nos Aplicativos Lógicos do Azure de locatário único, você pode chamar e referenciar suas variáveis de ambiente em tempo de execução usando configurações e parâmetros do aplicativo, para que não seja necessário reimplantar com tanta frequência.

Conectores gerenciados e operações integradas

O ecossistema de Aplicativos Lógicos do Azure fornece mais de 1.000 conectores gerenciados pela Microsoft e hospedados pelo Azure e operações internas como parte de uma coleção em constante crescimento que você pode usar em Aplicativos Lógicos do Azure de locatário único. A maneira como a Microsoft mantém conectores gerenciados permanece basicamente a mesma nos Aplicativos Lógicos do Azure de locatário único e nos Aplicativos Lógicos do Azure multilocatário.

A melhoria mais significativa é que o serviço de locatário único disponibiliza os conectores geridos mais populares como operações incorporadas. Por exemplo, pode-se usar operações integradas para o Barramento de Serviço do Azure, Hubs de Eventos do Azure, SQL e muitos outros. Enquanto isso, as versões dos conectores geridos ainda estão disponíveis e continuam a funcionar.

As conexões que você cria usando operações internas baseadas no Serviço do Azure são chamadas de conexões internas ou conexões baseadas no provedor de serviços. As operações internas e suas conexões são executadas localmente no mesmo processo que executa seus fluxos de trabalho. Ambos são hospedados no tempo de execução redesenhado das Aplicações Lógicas do Azure. Por outro lado, as conexões gerenciadas, ou conexões de API, são criadas e executadas separadamente como recursos do Azure, que você implanta usando modelos ARM. Como resultado, as operações integradas e suas conexões fornecem um melhor desempenho devido à sua proximidade com seus fluxos de trabalho. Este projeto também funciona bem com fluxos de implantação, porque as conexões do provedor de serviços estão incluídas no mesmo artefacto de compilação.

No Visual Studio Code, quando se usa o designer para desenvolver ou fazer alterações nos fluxos de trabalho, o motor de Aplicações Lógicas do Azure single-tenant gera automaticamente todos os metadados de conexão necessários no ficheiro connections.json do projeto. As seções a seguir descrevem os três tipos de conexões que você pode criar em seus fluxos de trabalho. Cada tipo de conexão tem uma estrutura JSON diferente, o que é importante entender porque os pontos de extremidade mudam quando você se move entre ambientes.

Conexões do provedor de serviços

Ao usar uma operação incorporada para um serviço como o Barramento de Serviço do Azure ou os Hubs de Eventos do Azure em Aplicativos Lógicos do Azure de único locatário, você cria uma conexão de provedor de serviços que é executada no mesmo processo que seu fluxo de trabalho. Essa infraestrutura de conexão é hospedada e gerenciada como parte do recurso do aplicativo lógico, e as configurações do aplicativo armazenam as cadeias de conexão para qualquer operação interna baseada em provedor de serviços usada pelos fluxos de trabalho.

Importante

Quando você tiver informações confidenciais, como cadeias de conexão que incluem nomes de usuário e senhas, certifique-se de usar o fluxo de autenticação mais seguro disponível. Por exemplo, a Microsoft recomenda que você autentique o acesso aos recursos do Azure com uma identidade gerenciada quando o suporte estiver disponível e atribua uma função que tenha o menor privilégio necessário.

Se esse recurso não estiver disponível, certifique-se de proteger as cadeias de conexão por meio de outras medidas, como o Cofre da Chave do Azure, que você pode usar com as configurações do aplicativo. Em seguida, você pode fazer referência direta a cadeias de caracteres seguras, como cadeias de conexão e chaves. Semelhante aos modelos ARM, onde você pode definir variáveis de ambiente no momento da implantação, você pode definir as configurações do aplicativo dentro da definição do fluxo de trabalho do aplicativo lógico. Em seguida, você pode capturar valores de infraestrutura gerados dinamicamente, como pontos de extremidade de conexão, cadeias de caracteres de armazenamento e muito mais. Para obter mais informações, consulte Tipos de aplicativo para a plataforma de identidade da Microsoft.

Em seu projeto de aplicativo lógico padrão, cada fluxo de trabalho tem um arquivo de workflow.json que contém a definição JSON subjacente do fluxo de trabalho. Essa definição de fluxo de trabalho faz referência às strings de conexão necessárias no arquivo connections.json do projeto.

O exemplo a seguir mostra como a conexão do fornecedor de serviços para uma operação incorporada do Azure Service Bus aparece no ficheiro connections.json do seu projeto.

"serviceProviderConnections": {
   "{service-bus-connection-name}": {
      "parameterValues": {
         "connectionString": "@appsetting('servicebus_connectionString')"
      },
      "serviceProvider": {
         "id": "/serviceProviders/serviceBus"
      },
      "displayName": "{service-bus-connection-name}"
   },
   <...>
}

Conexões gerenciadas

Ao usar um conector gerenciado pela primeira vez em seu fluxo de trabalho, você será solicitado a criar uma conexão de API gerenciada para o serviço ou sistema de destino e autenticar sua identidade. Esses conectores são gerenciados pelo ecossistema de conectores compartilhados no Azure. As conexões de API existem e são executadas como recursos separados no Azure.

No Visual Studio Code, à medida que continua a criar e desenvolver o seu fluxo de trabalho usando o designer, o mecanismo de instância única dos Aplicativos Lógicos do Azure cria automaticamente os recursos necessários no Azure para os conectores geridos no seu fluxo de trabalho. O mecanismo adiciona automaticamente esses recursos de conexão ao grupo de recursos do Azure que você criou para conter seu aplicativo lógico.

O exemplo a seguir mostra como uma conexão de API para o conector gerenciado do Barramento de Serviço do Azure aparece no arquivo de connections.json do seu projeto:

"managedApiConnections": {
   "{service-bus-connection-name}": { 
      "api": {
         "id": "/subscriptions/{subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/servicebus"
      },
      "connection": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/servicebus"
      }, 
      "connectionRuntimeUrl": "{connection-runtime-URL}",
      "authentication": { 
         "type": "Raw",
         "scheme": "Key",
         "parameter": "@appsetting('servicebus_1-connectionKey')"
      },
   },
   <...>
}

Conexões do Azure Functions

Para chamar funções criadas e hospedadas no Azure Functions, utilize a operação incorporada do Azure Functions. Os metadados de conexão para chamadas do Azure Functions são diferentes de outras conexões internas. Esses metadados são armazenados no arquivo de connections.json do seu projeto de aplicativo lógico, mas têm uma aparência diferente:

"functionConnections": {
   "{function-operation-name}": {
      "function": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{function-app-name}/functions/{function-name}"
      },
      "triggerUrl": "{function-url}",
      "authentication": {
        "type": "QueryString",
         "name": "Code",
         "value": "@appsetting('azureFunctionOperation_functionAppKey')"
      }, 
      "displayName": "{functions-connection-display-name}"
   },
   <...>
}

Autenticação

Nas Aplicações Lógicas Azure de locatário único, o modelo de hospedagem para fluxos de trabalho de aplicações lógicas é um único locatário do Microsoft Entra, onde as suas cargas de trabalho se beneficiam de mais isolamento do que no modelo multilocatário. Além disso, o tempo de execução dos Aplicativos Lógicos do Azure de locatário único é portátil, o que significa que você pode executar seus fluxos de trabalho em outros ambientes, por exemplo, localmente no Visual Studio Code. Ainda assim, esse design requer uma maneira de os aplicativos lógicos autenticarem sua identidade para que possam acessar o ecossistema de conector gerenciado no Azure. Seus aplicativos também precisam das permissões corretas para executar operações ao usar conexões gerenciadas.

Por padrão, cada aplicativo lógico baseado em locatário único tem uma identidade gerida pelo sistema atribuída e ativada automaticamente. Essa identidade difere das credenciais de autenticação ou da cadeia de conexão usada para criar uma conexão. No tempo de execução, seu aplicativo lógico usa essa identidade para autenticar suas conexões por meio das políticas de acesso do Azure. Se você desabilitar essa identidade, as conexões não funcionarão em tempo de execução.

As seções a seguir fornecem mais informações sobre os tipos de autenticação que você pode usar para autenticar conexões gerenciadas, com base em onde seu aplicativo lógico é executado. Para cada conexão gerenciada, o arquivo de connections.json do seu projeto de aplicativo lógico tem um authentication objeto que especifica o tipo de autenticação que seu aplicativo lógico pode usar para autenticar essa conexão gerenciada.

Identidade gerida

Para um aplicativo lógico hospedado e executado no Azure, uma identidade gerenciada é o tipo de autenticação padrão e recomendado a ser usado para autenticar conexões gerenciadas hospedadas e executadas no Azure. No arquivo connections.json do seu projeto de aplicativo lógico, a conexão gerenciada tem um authentication objeto que especifica ManagedServiceIdentity como o tipo de autenticação:

"authentication": {
   "type": "ManagedServiceIdentity"
}

Cru

Para aplicativos lógicos executados em seu ambiente de desenvolvimento local usando o Visual Studio Code, as chaves de autenticação bruta são usadas para autenticar conexões gerenciadas hospedadas e executadas no Azure. Essas chaves são projetadas apenas para uso de desenvolvimento, não para produção, e têm uma expiração de 7 dias. No arquivo connections.json do seu projeto de aplicativo lógico, a conexão gerenciada tem um authentication objeto que especifica as seguintes informações de autenticação:

"authentication": {
   "type": "Raw", 
   "scheme": "Key", 
   "parameter": "@appsetting('connectionKey')"
 }

Próximos passos