Implantação do DevOps em Aplicativos Lógicos do Azure com de locatário único

Artigo
01/04/2024

Aplica-se a: Aplicativos Lógicos do Azure (Standard)

Com a tendência apontando para aplicativos de nuvem nativos e distribuídos, as organizações estão tendo que lidar com mais componentes distribuídos ao longo de mais ambientes. Para manter o controle e a consistência, você pode automatizar seus ambientes e implantar mais componentes com maior rapidez e confiabilidade usando ferramentas e processos do DevOps.

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

Locatário único versus multilocatários

Nos Aplicativos Lógicos do Azure de multilocatário, a implantação se baseia em modelos do ARM (modelos do Azure Resource Manager), que combinam e processam o provisionamento de recursos tanto para os aplicativos lógicos, quanto para a infraestrutura. Nos Aplicativos Lógicos do Azure de locatário único, a implantação se torna mais fácil, pois você pode separar o provisionamento de recursos entre os aplicativos e a infraestrutura.

Quando você cria aplicativos lógicos usando o tipo de recurso de Aplicativo Lógico (padrão) , os fluxos de trabalho são alimentados pelo runtime reprojetado dos aplicativos lógicos do Azure de locatário único. O runtime usa o modelo de extensibilidade do Azure Functions, e é hospedado como uma extensão no runtime do Azure Functions. Esse arranjo oferece portabilidade, flexibilidade e melhor desempenho aos aplicativos lógicos, além de outras funcionalidades e recursos herdados da plataforma do Azure Functions e do ecossistema do Serviço de Aplicativo do Azure.

Por exemplo, você pode empacotar o runtime e os fluxos de trabalho em contêineres reprojetados em conjunto como parte do seu aplicativo lógico. Você pode usar etapas genéricas ou tarefas que criem, montem e compactem seus recursos de aplicativo lógico em artefatos prontos para implantação. Para implantar os aplicativos, copie os artefatos para o ambiente de host e, em seguida, inicie os aplicativos para executar os fluxos de trabalho. Ou integre seus artefatos em pipelines de implantação usando as ferramentas e os processos que você já conhece e usa. Por exemplo, se o cenário exigir contêineres, você poderá colocar seus aplicativos lógicos em contêineres e integrá-los aos pipelines existentes.

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

Ao usar 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ê terá um modelo de projeto mais genérico em que poderá aplicar muitas opções de implantação semelhantes ou idênticas às que usa para um aplicativo genérico. Você também usufrui de uma experiência mais consistente ao criar pipelines de implantação em torno dos projetos de aplicativo e ao executar os testes e validações necessários antes de publicar em produção. Qualquer que seja a pilha de tecnologia usada, você pode implantar aplicativos lógicos usando suas próprias ferramentas escolhidas.

Funcionalidades de implantação do DevOps

Os Aplicativos Lógicos do Azure de locatário único herdam muitos recursos e benefícios da plataforma Azure Functions e do ecossistema do Serviço de Aplicativo do Azure. Essas atualizações incluem um novo modelo de implantação e mais maneiras de usar o DevOps nos fluxos de trabalho do aplicativo lógico.

Desenvolvimento e teste locais

Ao usar o Visual Studio Code com a extensão de Aplicativos Lógicos do Azure (Padrão), você pode desenvolver, criar e executar fluxos de trabalho de aplicativo lógico de locatário único em seu ambiente de desenvolvimento sem precisar implantar no Azure. Se seu cenário exigir contêineres, você poderá fazer a criação e implantação por meio dos Aplicativos Lógicos habilitados para o Azure Arc.

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

Preocupações separadas

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

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

Definição de recurso de aplicativo lógico

No modelo multilocatário dos 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 de um-para-um, o aplicativo lógico e o fluxo de trabalho geralmente são considerados e referenciados como sinônimos. No entanto, no modelo de locatário único dos Aplicativos Lógicos do Azure, a estrutura de recursos do aplicativo lógico Standard pode incluir múltiplos fluxos de trabalho. Essa relação de 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 locatário também oferecem desempenho aprimorado devido a essa locação compartilhada e à proximidade entre si. Essa estrutura de recursos tem uma aparência semelhante ao Azure Functions, em que um aplicativo de funções 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 para Azure Functions, que são semelhantes, e geralmente podem ser aplicadas aos Aplicativos Lógicos do Azure de locatário único.

Estrutura do projeto de aplicativo lógico

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 em pacote NuGet (.NET), que você pode converter pelo tipo padrão

Com base nesses tipos, o projeto incluirá pastas e arquivos ligeiramente diferentes. Um projeto baseado em NuGet inclui uma pasta .bin que contém pacotes e outros arquivos de biblioteca. Um projeto baseado em pacote não inclui a pasta .bin e outros arquivos. Alguns cenários exigem um projeto baseado em NuGet para que o aplicativo seja executado, como quando você deseja desenvolver e executar operações personalizadas. Para obter mais informações sobre como converter o projeto para usar o NuGet, confira Habilitar a criação de conector integrado.

Para o projeto padrão baseado em pacote, seu projeto tem uma estrutura de pasta e arquivo 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

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

Nome	Pasta ou arquivo	Descrição
.vscode	Pasta	Contém os arquivos de configurações relacionadas ao Visual Studio Code, como os arquivos extensions.json, launch.json, settings.json e tasks.json.
Artefatos	Pasta	Contém artefatos de conta de integração que você define e usa em fluxos de trabalho que suportam cenários B2B (entre empresas). 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 arquivo workflow.json, que contém a definição JSON subjacente desse fluxo de trabalho.
workflow-designtime	Pasta	Contém arquivos de configurações relacionados ao ambiente de desenvolvimento.
.funcignore	Arquivo	Contém informações relacionadas ao Azure Functions Core Tools instalado.
connections.json	Arquivo	Contém os metadados, pontos de extremidade e chaves para conexões gerenciadas e funções do Azure usados pelos fluxos de trabalho. Importante: para usar diferentes conexões e funções para cada ambiente, certifique-se de parametrizar esse arquivo connections.json e atualizar os pontos de extremidade.
host. JSON	Arquivo	Contém definições e valores de configuração específicos do runtime, como limites padrão para a plataforma de Aplicativos Lógicos do Azure de locatário único, aplicativos lógicos, fluxos de trabalho, gatilhos e ações. No nível raiz do 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. Observação: quando você cria seu aplicativo lógico, o Visual Studio Code cria um arquivo *host.snapshot..json** 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é dez instantâneos para o mesmo aplicativo lógico. Se ultrapassar esse limite, você verá 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 adicionais do seu contêiner de armazenamento.
local.settings.json	Arquivo	Contém configurações de aplicativo, cadeias de conexão e outras configurações usadas pelos fluxos de trabalho ao serem executados localmente. Ou seja, essas configurações e valores se aplicam somente quando você executa seus projetos no ambiente de desenvolvimento local. Durante a implantação para o Azure, o arquivo e as configurações são ignorados e não são incluídos na implantação. Esse arquivo armazena configurações e valores como variáveis de ambiente local que são usadas pelas ferramentas de desenvolvimento local como os valores `appSettings`. Você pode chamar e fazer referência a essas variáveis de ambiente no runtime e durante a implantação usando configurações de aplicativo e parâmetros. Importante: o arquivo local.settings.json pode conter segredos; verifique se você também excluiu esse arquivo do seu controle do código-fonte do projeto.

Implantação de contêiner

Os Aplicativos Lógicos do Azure de locatário único dão suporte à implantação em contêineres, o que significa que é possível colocar os fluxos de trabalho do aplicativo lógico em contêineres e executá-los em instâncias em que os contêineres podem ser executados. Após colocar o aplicativo lógico em contêiner, a implantação funcionará basicamente como qualquer outro contêiner que você implantar e gerenciar.

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

Configurações e parâmetros de aplicativo

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

Em aplicativos lógicos do Azure de locatário único, você pode chamar e referenciar variáveis de ambiente no runtime usando parâmetros e configurações de aplicativo. Com isso, não é necessário reimplantar com tanta frequência.

Conectores gerenciados e operações internas

O ecossistema de aplicativos lógicos do Azure fornece centenas de conectores gerenciados pela Microsoft 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 esses conectores e operações internas permanece a mesma em aplicativos lógicos do Azure de locatário único.

A melhoria mais significativa é que o serviço de locatário único disponibiliza conectores gerenciados mais populares também como operações internas. Por exemplo, você pode usar operações internas no Barramento de Serviço do Azure, nos Hubs de Eventos do Azure, no SQL, entre outros. Enquanto isso, as versões do conector gerenciado ainda estão disponíveis e continuam funcionando.

As conexões que você criar usando operações internas são chamadas de conexões internas ou conexões do provedor de serviços. As operações internas e suas respectivas conexões são executadas localmente no mesmo processo que executa os fluxos de trabalho. Ambas estão hospedadas no runtime dos Aplicativos Lógicos reprojetados. Por outro lado, as conexões gerenciadas ou as conexões de API são criadas e executados separadamente como recursos do Azure que você implanta usando modelos do ARM. Como resultado, as operações internas e suas conexões fornecem melhor desempenho devido à proximidade com os fluxos de trabalho. Esse arranjo também funciona satisfatoriamente com pipelines de implantação, porque as conexões do provedor de serviço são empacotadas no mesmo artefato de compilação.

No Visual Studio Code, quando você usa o designer para desenvolver ou fazer alterações em fluxos de trabalho, o mecanismo de Aplicativos Lógicos gera automaticamente todos os metadados de conexão necessários ao arquivo connections.json do seu projeto. As seções a seguir descrevem os três tipos de conexões que podem ser criadas nos fluxos de trabalho. É importante entender que cada tipo de conexão tem uma estrutura JSON diferente, já que os pontos de extremidade mudam quando você se move entre ambientes.

Conexões do provedor de serviços

Quando você usa uma operação interna em um serviço como o Barramento de Serviço do Azure ou os Hubs de Eventos do Azure em um Aplicativo Lógico do Azure de locatário único, você cria uma conexão de provedor de serviços que é executada no mesmo processo do fluxo de trabalho. Essa infraestrutura de conexão é hospedada e gerenciada como parte do recurso do aplicativo lógico, e as configurações de aplicativo armazenam as cadeias de conexão de operações internas baseadas no provedor de serviços utilizadas pelos fluxos de trabalho.

Importante

Quando houver informações confidenciais, como cadeias de conexão que incluam 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 a recursos do Azure com uma identidade gerenciada quando houver suporte disponível, e atribua uma função que tenha o mínimo de privilégios necessários.

Se essa funcionalidade estiver indisponível, certifique-se de proteger as cadeias de conexão por meio de outras medidas, como o Azure Key Vault, 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. De modo semelhante aos modelos do ARM, em que é possível definir variáveis de ambiente no momento da implantação, você pode definir as configurações de aplicativo na definição de fluxo de trabalho do aplicativo lógico. Em seguida, você pode capturar os valores da infraestrutura gerados dinamicamente, como pontos de extremidade de conexão, cadeias de caracteres de armazenamento, entre outros. Para obter mais informações, confira Tipos de aplicativo para a plataforma de identidade da Microsoft.

Em um projeto de aplicativo lógico, cada fluxo de trabalho tem um arquivo workflow.json que contém a definição JSON subjacente do fluxo de trabalho. Essa definição de fluxo de trabalho referencia, em seguida, as cadeias de conexão necessárias no arquivo connections.json do seu projeto.

O exemplo a seguir demonstra como a conexão do provedor de serviços para uma operação interna do barramento de serviço aparece no arquivo 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 a autenticar sua identidade. Esses conectores são gerenciados pelo ecossistema de conectores compartilhados do Azure. As conexões de API existem e são executadas como recursos separados no Azure.

No Visual Studio Code, enquanto você continua a criar e desenvolver o fluxo de trabalho usando o designer, o mecanismo de aplicativos lógicos cria automaticamente os recursos necessários no Azure para os conectores gerenciados no fluxo de trabalho. O mecanismo adiciona automaticamente esses recursos de conexão ao grupo de recursos do Azure que você criou para conter o aplicativo lógico.

O exemplo a seguir demonstra como uma conexão de API para o conector do barramento de serviço gerenciado aparece no arquivo connections.json de um 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, use a operação interna 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 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

Em aplicativos lógicos do Azure de locatário único, o modelo de hospedagem para fluxos de trabalho de aplicativo lógico é um modelo de locatário único, no qual as cargas de trabalho usufruem de um isolamento maior do que no modelo multilocatário. Além disso, o runtime 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 arranjo requer uma maneira de os aplicativos lógicos autenticarem sua identidade para que possam acessar o ecossistema do conector gerenciado no Azure. Os 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 gerenciada atribuída pelo sistema habilitada automaticamente. Essa identidade difere das credenciais de autenticação ou da cadeia de conexão que você usa ao criar uma conexão. Em runtime, o 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 no runtime.

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 no local onde o aplicativo lógico é executado. Para cada conexão gerenciada, o arquivo connections.json do projeto do seu aplicativo lógico tem um objeto authentication que especifica o tipo de autenticação que o aplicativo lógico pode usar para autenticar a conexão gerenciada.

Identidade gerenciada

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

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

Raw

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

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

Próximas etapas

Configurar a implantação do DevOps para aplicativos lógicos do Azure de locatário único

Compartilhar via