Implementação DevOps para Azure Logic Apps de inquilino único

Artigo
01/04/2024

Aplica-se a: Azure Logic Apps (Standard)

Com a tendência para aplicações na cloud distribuídas e nativas, as organizações estão a lidar com componentes mais distribuídos em mais ambientes. Para manter o controlo e a consistência, pode automatizar os seus ambientes e implementar mais componentes de forma mais rápida e segura com as ferramentas e processos do DevOps.

Este artigo fornece uma introdução e descrição geral sobre a experiência atual de integração contínua e implementação contínua (CI/CD) para o Azure Logic Apps de inquilino único.

Inquilino único versus multi-inquilino

No Azure Logic Apps multi-inquilino, a implementação de recursos baseia-se em modelos de Resource Manager do Azure (modelos arm), que combinam e processam o aprovisionamento de recursos para aplicações lógicas e infraestrutura. No Azure Logic Apps de inquilino único, a implementação torna-se mais fácil porque pode separar o aprovisionamento de recursos entre aplicações e infraestrutura.

Quando cria aplicações lógicas com o tipo de recurso da Aplicação Lógica (Standard ), os fluxos de trabalho são alimentados pelo runtime de inquilino único redesenhado do Azure Logic Apps. Este runtime utiliza a extensibilidade do modelo de extensibilidade Funções do Azure e está alojado como uma extensão no Funções do Azure runtime. Este design proporciona portabilidade, flexibilidade e mais desempenho para as suas aplicações lógicas, além de outras capacidades e benefícios herdados da plataforma Funções do Azure e Serviço de Aplicações do Azure ecossistema.

Por exemplo, pode empacotar o runtime em contentores redesenhado e os fluxos de trabalho em conjunto como parte da sua aplicação lógica. Pode utilizar passos genéricos ou tarefas que compilam, montam e zipam os recursos da aplicação lógica em artefactos prontos a implementar. Para implementar as suas aplicações, copie os artefactos para o ambiente anfitrião e, em seguida, inicie as suas aplicações para executar os seus fluxos de trabalho. Em alternativa, integre os artefactos em pipelines de implementação com as ferramentas e processos que já conhece e utiliza. Por exemplo, se o seu cenário exigir contentores, pode contentorizar as suas aplicações lógicas e integrá-las nos pipelines existentes.

Para configurar e implementar os recursos de infraestrutura, como redes virtuais e conectividade, pode continuar a utilizar modelos do ARM e aprovisionar separadamente esses recursos juntamente com outros processos e pipelines que utiliza para esses fins.

Ao utilizar as opções padrão de compilação e implementação, pode concentrar-se no desenvolvimento de aplicações separadamente da implementação da infraestrutura. Como resultado, obtém um modelo de projeto mais genérico onde pode aplicar muitas opções de implementação semelhantes ou as mesmas que utiliza para uma aplicação genérica. Também beneficia de uma experiência mais consistente para criar pipelines de implementação em torno dos seus projetos de aplicação e para executar os testes e validações necessários antes de publicar na produção. Independentemente da pilha de tecnologia que utilizar, pode implementar aplicações lógicas com as suas próprias ferramentas escolhidas.

Capacidades de implementação do DevOps

O Azure Logic Apps de inquilino único herda muitas capacidades e benefícios da plataforma Funções do Azure e Serviço de Aplicações do Azure ecossistema. Estas atualizações incluem um novo modelo de implementação e mais formas de utilizar o DevOps para os fluxos de trabalho da aplicação lógica.

Desenvolvimento e teste locais

Quando utiliza o Visual Studio Code com a extensão do Azure Logic Apps (Standard), pode programar, compilar e executar fluxos de trabalho de aplicações lógicas baseadas em inquilino único no seu ambiente de desenvolvimento sem ter de implementar no Azure. Se o seu cenário necessitar de contentores, pode criar e implementar através do Logic Apps compatível com o Azure Arc.

Esta capacidade é uma grande melhoria e proporciona um benefício substancial em comparação com o modelo multi-inquilino, que requer que se desenvolva com um recurso existente e em execução no Azure.

Preocupações separadas

O modelo de inquilino único dá-lhe a capacidade de separar as preocupações entre a aplicação e a infraestrutura subjacente. Por exemplo, pode desenvolver, criar, zipar e implementar a sua aplicação separadamente como um artefacto imutável em diferentes ambientes. Normalmente, os fluxos de trabalho da aplicação lógica têm "código da aplicação" que atualiza com mais frequência do que a infraestrutura subjacente. Ao separar estas camadas, pode concentrar-se mais na criação do fluxo de trabalho da sua aplicação lógica e gastar menos no seu esforço para implementar os recursos necessários em vários ambientes.

Diagrama conceptual que mostra pipelines de implementação separados para aplicações e infraestrutura.

Estrutura de recursos da aplicação lógica

No modelo do Azure Logic Apps multi-inquilino, a estrutura de recursos da aplicação lógica de consumo só pode incluir um único fluxo de trabalho. Devido a esta relação um-para-um, tanto a aplicação lógica como o fluxo de trabalho são muitas vezes considerados e referenciados como sinónimos. No entanto, no modelo do Azure Logic Apps de inquilino único, a estrutura de recursos da aplicação lógica Padrão pode incluir vários fluxos de trabalho. Esta relação um-para-muitos significa que, na mesma aplicação lógica, os fluxos de trabalho podem partilhar e reutilizar outros recursos. Os fluxos de trabalho na mesma aplicação lógica e inquilino também oferecem um desempenho melhorado devido a este inquilino partilhado e proximidade entre si. Esta estrutura de recursos tem um aspeto semelhante ao Funções do Azure em que uma aplicação de funções pode alojar muitas funções.

Para obter mais informações e melhores práticas sobre como organizar fluxos de trabalho, desempenho e dimensionamento na sua aplicação lógica, reveja as orientações semelhantes para Funções do Azure que geralmente pode aplicar ao Azure Logic Apps de inquilino único.

Estrutura do projeto da aplicação lógica

No Visual Studio Code, o projeto da aplicação lógica tem um dos seguintes tipos:

Baseado em pacotes de extensões (Node.js), que é o tipo predefinido
Baseado em pacotes NuGet (.NET), que pode converter a partir do tipo predefinido

Com base nestes tipos, o projeto inclui pastas e ficheiros ligeiramente diferentes. Um projeto baseado em NuGet inclui uma pasta .bin que contém pacotes e outros ficheiros de biblioteca. Um projeto baseado em pacotes não inclui a pasta .bin e outros ficheiros. Alguns cenários requerem um projeto baseado em NuGet para a sua aplicação ser executada, por exemplo, quando pretende desenvolver e executar operações incorporadas personalizadas. Para obter mais informações sobre como converter o projeto para utilizar o NuGet, veja Ativar a criação de conectores incorporados.

Para o projeto baseado em pacotes predefinido, o projeto tem uma pasta e uma estrutura de ficheiros semelhante ao seguinte exemplo:

MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
  || Maps 
     ||| MapName1
     ||| ...
  || Schemas
     ||| SchemaName1
     ||| ...
| WorkflowName1
  || workflow.json
  || ...
| WorkflowName2
  || workflow.json
  || ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json

Ao nível da raiz do projeto, pode encontrar os seguintes ficheiros e pastas com outros itens:

Name	Pasta ou ficheiro	Description
.vscode	Pasta	Contém ficheiros de definições relacionados com o Visual Studio Code, tais como extensions.json, launch.json, settings.json e ficheiros tasks.json .
Artefactos	Pasta	Contém artefactos de conta de integração que define e utiliza em fluxos de trabalho que suportam cenários empresariais (B2B). Por exemplo, a estrutura de exemplo inclui mapas e esquemas para operações de transformação e validação XML.
*<WorkflowName>*	Pasta	Para cada fluxo de trabalho, a < pasta WorkflowName> inclui um ficheiro workflow.json, que contém a definição JSON subjacente desse fluxo de trabalho.
workflow-designtime	Pasta	Contém ficheiros de definições relacionados com o ambiente de desenvolvimento.
.funcignore	Ficheiro	Contém informações relacionadas com as ferramentas Funções do Azure Core instaladas.
connections.json	Ficheiro	Contém os metadados, pontos finais e chaves para quaisquer ligações geridas e funções do Azure que os seus fluxos de trabalho utilizem. Importante: para utilizar diferentes ligações e funções para cada ambiente, certifique-se de que parametriza este ficheiro connections.json e atualiza os pontos finais.
host.json	Ficheiro	Contém definições e valores de configuração específicos do runtime, por exemplo, os limites predefinidos para a plataforma do Azure Logic Apps de inquilino único, aplicações lógicas, fluxos de trabalho, acionadores e ações. Ao nível da raiz do projeto da aplicação lógica, o ficheiro de metadados host.json contém as definições de configuração e os valores predefinidos que todos os fluxos de trabalho na mesma aplicação lógica utilizam durante a execução, seja localmente ou no Azure. Nota: quando cria a sua aplicação lógica, o Visual Studio Code cria um ficheiro *host.snapshot..json** de cópia de segurança no contentor de armazenamento. Se eliminar a sua aplicação lógica, este ficheiro de cópia de segurança não será eliminado. Se criar outra aplicação lógica com o mesmo nome, é criado outro ficheiro de instantâneo. Só pode ter até 10 instantâneos para a mesma aplicação lógica. Se exceder este limite, obtém o seguinte erro: `Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))` Para resolver este erro, elimine os ficheiros de instantâneo extra do contentor de armazenamento.
local.settings.json	Ficheiro	Contém definições de aplicações, cadeias de ligação e outras definições que os fluxos de trabalho utilizam durante a execução local. Por outras palavras, estas definições e valores aplicam-se apenas quando executa os seus projetos no seu ambiente de desenvolvimento local. Durante a implementação no Azure, o ficheiro e as definições são ignorados e não são incluídos na sua implementação. Este ficheiro armazena definições e valores como variáveis de ambiente local que são utilizadas pelas suas ferramentas de desenvolvimento local como valores `appSettings` . Pode chamar e referenciar estas variáveis de ambiente tanto no tempo de execução como no tempo de implementação através das definições e parâmetros da aplicação. Importante: o ficheiro local.settings.json pode conter segredos, por isso certifique-se de que também exclui este ficheiro do controlo de origem do projeto.

Implementação de contentores

O Azure Logic Apps de inquilino único suporta a implementação em contentores, o que significa que pode contentorizar os fluxos de trabalho da aplicação lógica e executá-los onde os contentores podem ser executados. Depois de contentorizar a sua aplicação, a implementação funciona principalmente da mesma forma que qualquer outro contentor que implemente e gere.

Para obter exemplos que incluem o Azure DevOps, veja CI/CD para Contentores.

Definições e parâmetros da aplicação

No Azure Logic Apps multi-inquilino, os modelos do ARM representam um desafio quando tem de manter variáveis de ambiente para aplicações lógicas em vários ambientes de desenvolvimento, teste e produção. Tudo num modelo do ARM é definido na implementação. Se precisar de alterar apenas uma única variável, tem de reimplementar tudo.

No Azure Logic Apps de inquilino único, pode chamar e referenciar as variáveis de ambiente no runtime através das definições e parâmetros da aplicação, para que não tenha de reimplementar com tanta frequência.

Conectores geridos e operações incorporadas

O ecossistema do Azure Logic Apps fornece centenas de conectores geridos pela Microsoft e operações incorporadas como parte de uma coleção em constante crescimento que pode utilizar no Azure Logic Apps de inquilino único. A forma como a Microsoft mantém estes conectores e as operações incorporadas permanecem praticamente iguais no Azure Logic Apps de inquilino único.

A melhoria mais significativa é que o serviço de inquilino único torna os conectores geridos mais populares também disponíveis como operações incorporadas. Por exemplo, pode utilizar operações incorporadas para Azure Service Bus, Hubs de Eventos do Azure, SQL e outros. Entretanto, as versões do conector gerido continuam disponíveis e continuam a funcionar.

As ligações que criar com operações incorporadas são denominadas ligações incorporadas ou ligações do fornecedor de serviços. As operações incorporadas e as respetivas ligações são executadas localmente no mesmo processo que executa os fluxos de trabalho. Ambos estão alojados no runtime redesenhado do Logic Apps. Por outro lado, as ligações geridas ou as ligações de API são criadas e executadas separadamente como recursos do Azure, que implementa com modelos do ARM. Como resultado, as operações incorporadas e as respetivas ligações proporcionam um melhor desempenho devido à proximidade dos fluxos de trabalho. Esta estrutura também funciona bem com pipelines de implementação porque as ligações do fornecedor de serviços são empacotadas no mesmo artefacto de compilação.

No Visual Studio Code, quando utiliza o estruturador para desenvolver ou fazer alterações aos seus fluxos de trabalho, o motor do Logic Apps gera automaticamente os metadados de ligação necessários no ficheiro connections.json do seu projeto. As secções seguintes descrevem os três tipos de ligações que pode criar nos seus fluxos de trabalho. Cada tipo de ligação tem uma estrutura JSON diferente, que é importante compreender porque os pontos finais mudam quando se move entre ambientes.

Ligações do fornecedor de serviços

Quando utiliza uma operação incorporada para um serviço como Azure Service Bus ou Hubs de Eventos do Azure no Azure Logic Apps de inquilino único, cria uma ligação de fornecedor de serviços que é executada no mesmo processo que o fluxo de trabalho. Esta infraestrutura de ligação é alojada e gerida como parte do recurso da aplicação lógica e as definições da aplicação armazenam as cadeias de ligação para qualquer operação incorporada baseada no fornecedor de serviços utilizada pelos fluxos de trabalho.

No projeto da aplicação lógica, cada fluxo de trabalho tem um ficheiro workflow.json que contém a definição JSON subjacente do fluxo de trabalho. Em seguida, esta definição de fluxo de trabalho referencia as cadeias de ligação necessárias no ficheiro connections.json do projeto.

O exemplo seguinte mostra como a ligação do fornecedor de serviços para uma operação incorporada do Service Bus aparece no ficheiro connections.json do projeto:

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

Ligações geridas

Quando utiliza um conector gerido pela primeira vez no fluxo de trabalho, é-lhe pedido para criar uma ligação de API gerida para o serviço ou sistema de destino e autenticar a sua identidade. Estes conectores são geridos pelo ecossistema de conectores partilhados no Azure. As ligações de API existem e são executadas como recursos separados no Azure.

No Visual Studio Code, enquanto continua a criar e desenvolver o seu fluxo de trabalho com o estruturador, o motor do Logic Apps cria automaticamente os recursos necessários no Azure para os conectores geridos no seu fluxo de trabalho. O motor adiciona automaticamente estes recursos de ligação ao grupo de recursos do Azure que desenhou para conter a sua aplicação lógica.

O exemplo seguinte mostra como é apresentada uma ligação de API para o conector do Service Bus gerido no ficheiro connections.json do 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')"
      },
   },
   <...>
}

ligações de Funções do Azure

Para chamar funções criadas e alojadas no Funções do Azure, utilize a operação de Funções do Azure incorporada. Os metadados de ligação para Funções do Azure chamadas são diferentes de outras ligações incorporadas. Estes metadados são armazenados no ficheiro connections.json do projeto da aplicação lógica, mas têm um aspeto 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

No Azure Logic Apps de inquilino único, o modelo de alojamento para fluxos de trabalho de aplicações lógicas é um único inquilino em que as cargas de trabalho beneficiam de mais isolamento do que no modelo multi-inquilino. Além disso, o runtime do Azure Logic Apps de inquilino único é portátil, o que significa que pode executar os fluxos de trabalho noutros ambientes, por exemplo, localmente no Visual Studio Code. Ainda assim, este design requer uma forma de as aplicações lógicas autenticarem a respetiva identidade para que possam aceder ao ecossistema do conector gerido no Azure. As suas aplicações também precisam das permissões corretas para executar operações ao utilizar ligações geridas.

Por predefinição, cada aplicação lógica baseada em inquilino único tem uma identidade gerida atribuída pelo sistema automaticamente ativada. Esta identidade difere das credenciais de autenticação ou da cadeia de ligação utilizada para criar uma ligação. No runtime, a aplicação lógica utiliza esta identidade para autenticar as respetivas ligações através de políticas de acesso do Azure. Se desativar esta identidade, as ligações não funcionarão no runtime.

As secções seguintes fornecem mais informações sobre os tipos de autenticação que pode utilizar para autenticar ligações geridas, com base no local onde a aplicação lógica é executada. Para cada ligação gerida, o ficheiro connections.json do projeto da aplicação lógica tem um authentication objeto que especifica o tipo de autenticação que a sua aplicação lógica pode utilizar para autenticar essa ligação gerida.

Identidade gerida

Para uma aplicação lógica alojada e executada no Azure, uma identidade gerida é o tipo de autenticação predefinido e recomendado a utilizar para autenticar ligações geridas alojadas e executadas no Azure. No ficheiro connections.json do projeto da aplicação lógica, a ligação gerida tem um authentication objeto que especifica ManagedServiceIdentity como o tipo de autenticação:

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

Não processado

Para aplicações lógicas que são executadas no seu ambiente de desenvolvimento local com o Visual Studio Code, as chaves de autenticação não processadas são utilizadas para autenticar ligações geridas alojadas e executadas no Azure. Estas chaves foram concebidas apenas para utilização de desenvolvimento, não para produção, e têm uma expiração de 7 dias. No ficheiro connections.json do projeto da aplicação lógica, a ligação gerida tem um authentication objeto que especifica as seguintes informações de autenticação:

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

Passos seguintes

Configurar implementação DevOps para Azure Logic Apps de inquilino único

Partilhar via