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 para os recursos e a infraestrutura do aplicativo lógico de consumo. Nos Aplicativos Lógicos do Azure de locatário único, a implantação se torna mais fácil porque você pode separar o provisionamento de recursos entre os recursos do aplicativo lógico padrão e a infraestrutura.
Quando você cria um recurso de aplicativo lógico Padrão, os fluxos de trabalho são alimentados pelo tempo de execução redesenhado dos Aplicativos Lógicos do Azure de locatário único. Esse tempo de execução usa a extensibilidade do 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 seus artefatos em pipelines de implantação usando as ferramentas e os processos que você 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 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 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 contêineres, você 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.
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 do 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 do tipo padrão
Com base nesses tipos, seu projeto inclui 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 seu aplicativo seja executado, por exemplo, quando você deseja desenvolver e executar operações internas personalizadas. Para obter mais informações sobre como converter seu projeto para usar o NuGet, consulte Habilitar a criação de conector interno.
Para o projeto baseado em pacote padrão, seu projeto tem uma estrutura de pasta e arquivo semelhante ao exemplo a seguir:
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 seu projeto, você pode encontrar os seguintes arquivos e pastas com outros itens:
Implementação em contentor
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 conectores gerenciados mais populares como operações internas. Por exemplo, você pode usar operações internas para o Barramento de Serviço do Azure, Hubs de Eventos do Azure, SQL e muitos outros. Enquanto isso, as versões do conector gerenciado 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 dos Aplicativos Lógicos 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. Esse design também funciona bem com pipelines de implantação porque as conexões do provedor de serviços 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 seus fluxos de trabalho, o mecanismo de Aplicativos Lógicos do Azure de locatário único gera automaticamente todos os metadados de conexão necessários no arquivo de connections.json do seu 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 interna para um serviço como o Barramento de Serviço do Azure ou Hubs de Eventos do Azure em Aplicativos Lógicos do Azure de locatário único, 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 cadeias de conexão necessárias no arquivo connections.json do projeto.
O exemplo a seguir mostra como a conexão do provedor de serviços para uma operação interna do Barramento de Serviço do Azure aparece no arquivo de 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, enquanto você continua a criar e desenvolver seu fluxo de trabalho usando o designer, o mecanismo de Aplicativos Lógicos do Azure de locatário único cria automaticamente os recursos necessários no Azure para os conectores gerenciados em 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, 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 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
Nos Aplicativos Lógicos do Azure de locatário único, o modelo de hospedagem para fluxos de trabalho de aplicativos lógicos é um único locatário do Microsoft Entra em que 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 gerenciada atribuída ao sistema habilitada 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"
}
Raw
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')"
}