Implantação do DevOps para aplicativos lógicos Standard em Aplicativos Lógicos do Azure com locatário único
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 implantação contínua (CI/CD) para fluxos de trabalho de aplicativos lógicos Standard em Aplicativos Lógicos do Azure com locatário único.
Locatário único versus multilocatários
Nos Aplicativos Lógicos do Azure multilocatário, a implantação do recurso se baseia em modelos do Azure Resource Manager (modelos do ARM), que combinam e se encarregam do provisionamento de recursos tanto para seus recursos quanto para a infraestrutura de Consumo de aplicativos lógicos. Nos Aplicativos Lógicos do Azure com locatário único, a implantação é facilitada porque você pode separar o provisionamento de recursos entre os recursos e a infraestrutura de aplicativos lógicos Standard.
Quando você cria um recurso de aplicativo lógico Standard, os fluxos de trabalho são alimentados pelo runtime reprojetado dos Aplicativos Lógicos do Azure com 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 design oferece portabilidade, flexibilidade e mais desempenho aos aplicativos lógicos Standard, além de outras funcionalidades e recursos herdados da plataforma Azure Functions e do ecossistema do Serviço de Aplicativo do Azure.
Por exemplo, você pode empacotar o runtime e os fluxos de trabalho conteinerizados reprojetados em conjunto como parte do seu aplicativo lógico Standard. Você pode usar tarefas ou etapas genéricas que criam, montam e compactam os recursos do aplicativo lógico em artefatos prontos para implantação. Para implantar os aplicativos lógicos Standard, copie os artefatos para o ambiente de host e, em seguida, inicie seus aplicativos para executar seus fluxos de trabalho. Ou integre os artefatos em pipelines de implantação usando as ferramentas e os processos que você já conhece e usa. Por exemplo, se o seu cenário requer contêineres, você poderá conteinerizar seus aplicativos lógicos Standard e integrá-los aos seus 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 (Standard), você pode desenvolver, criar e executar fluxos de trabalho de aplicativo lógico de locatário Standard no 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 lhe oferece a funcionalidade de distribuir as preocupações entre o seu aplicativo lógico 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.
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 mais de 1.000 conectores gerenciados pela Microsoft e hospedados pelo Azure e operações integradas como parte de uma coleção em constante crescimento, que você pode usar nos Aplicativos Lógicos do Azure com locatário único. A maneira como a Microsoft mantém os conectores gerenciados permanece praticamente a mesma, tanto nos Aplicativos Lógicos do Azure com locatário único quanto nos Aplicativos Lógicos do Azure multilocatário.
A melhoria mais significativa é que o serviço com locatário único disponibiliza os conectores gerenciados mais populares também na forma de operações integradas. Por exemplo, você pode usar operações integradas para o Barramento de Serviço do Azure, Hubs de Eventos do Azure, SQL e vários 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 integradas baseadas no Serviço do Azure são chamadas de conexões integradas, ou conexões baseadas no provedor de serviços. As operações internas e as respectivas conexões são executadas localmente no mesmo processo que executa os fluxos de trabalho. Ambas são hospedadas no runtime reprojetado dos Aplicativos Lógicos do Azure. 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 nos seus fluxos de trabalho, o mecanismo de Aplicativos Lógicos do Azure com locatário único gera automaticamente todos os metadados de conexão necessários no 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.
No seu projeto de aplicativo lógico Standard, cada fluxo de trabalho tem um arquivo workflow.json que contém a definição JSON subjacente ao fluxo de trabalho. A seguir, essa definição de fluxo de trabalho menciona as cadeias de conexão necessárias no arquivo connections.json do seu projeto.
O exemplo a seguir mostra como a conexão do provedor de serviços para uma operação integrada do Barramento de Serviço do Azure 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 seu fluxo de trabalho usando o designer, o mecanismo de Aplicativos Lógicos do Azure com locatário único cria automaticamente no Azure os recursos necessários para os conectores gerenciados 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 o 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 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, use a operação integrada 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 parecem diferentes:
"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
Nos Aplicativos Lógicos do Azure com locatário único, o modelo de hospedagem para fluxos de trabalho de aplicativo lógico é um único locatário no Microsoft Entra, em que suas cargas de trabalho se beneficiam 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 de authentication que especifica o tipo de autenticação que o seu aplicativo lógico pode usar para autenticar a conexão gerenciada em questão.
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 de authentication que especifica ManagedServiceIdentity como o 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 de authentication que especifica a seguinte informação de autenticação:
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}