Criar e usar um ambiente interno do Serviço de Aplicativo do Balanceador de Carga

Artigo
08/17/2024

Importante

Este artigo é sobre o Ambiente do Serviço de Aplicativo v2, que é usado com os planos do Serviço de Aplicativo Isolado. O Ambiente do Serviço de Aplicativo v1 e v2 foi desativado a partir de 31 de agosto de 2024. Há uma nova versão do Ambiente do Serviço de Aplicativo que é mais fácil de usar e é executada em uma infraestrutura mais poderosa. Para saber mais sobre a nova versão, comece com a Introdução ao Ambiente do Serviço de Aplicativo. Se você estiver usando o Ambiente do Serviço de Aplicativo v1, siga as etapas neste artigo para migrar para a nova versão.

A partir de 31 de agosto de 2024, o Contrato de Nível de Serviço (SLA) e os Créditos de Serviço não se aplicam mais às cargas de trabalho do Ambiente do Serviço de Aplicativo v1 e v2 que continuam em produção, pois são produtos desativados. A desativação do hardware do Ambiente do Serviço de Aplicativo v1 e v2 começou, e isso pode afetar a disponibilidade e o desempenho de seus aplicativos e dados.

Você deve concluir a migração para o Ambiente do Serviço de Aplicativo v3 imediatamente ou seus aplicativos e recursos podem ser excluídos. Tentaremos migrar automaticamente qualquer Ambiente do Serviço de Aplicativo restante v1 e v2 com base no melhor esforço usando o recurso de migração in-loco, mas a Microsoft não faz nenhuma reivindicação ou garantia sobre a disponibilidade do aplicativo após a migração automática. Talvez seja necessário executar a configuração manual para concluir a migração e otimizar a escolha de SKU do plano do Serviço de Aplicativo para atender às suas necessidades. Se a migração automática não for viável, seus recursos e dados de aplicativos associados serão excluídos. Exortamo-lo vivamente a agir agora para evitar qualquer um destes cenários extremos.

Se você precisar de tempo adicional, podemos oferecer um período de carência único de 30 dias para que você conclua sua migração. Para obter mais informações e solicitar esse período de carência, revise a visão geral do período de carência e vá para o portal do Azure e visite a folha Migração para cada um dos seus Ambientes do Serviço de Aplicativo.

Para obter as informações mais atualizadas sobre a desativação do Ambiente do Serviço de Aplicativo v1/v2, consulte a atualização de desativação do Ambiente do Serviço de Aplicativo v1 e v2.

O Ambiente do Serviço de Aplicativo do Azure é uma implantação do Serviço de Aplicativo do Azure em uma sub-rede em uma rede virtual (VNet) do Azure. Existem duas formas de implementar um Ambiente de Serviço de Aplicações (ASE):

Com um VIP num endereço IP externo, muitas vezes chamado ASE Externo.
Com um VIP num endereço IP interno, muitas vezes chamado ASE de ILB porque o ponto final interno é um balanceador de carga interno (ILB).

Este artigo mostra como criar um ASE de ILB. Para obter uma descrição geral sobre o ASE, veja Introdução aos Ambientes de Serviço de Aplicações. Para saber como criar um ASE externo, consulte [Criar um ASE externo][MakeExternalASE].

Descrição geral

Pode implementar um ASE com um ponto final acessível pela Internet ou com um endereço IP na sua VNet. Para definir o endereço IP para um endereço VNet, o ASE tem de ser implementado com um ILB. Ao implantar seu ASE com um ILB, você deve fornecer o nome do seu ASE. O nome do ASE é usado no sufixo de domínio para os aplicativos no ASE. O sufixo de domínio para o seu ILB ASE é <ASE name.appserviceenvironment.net>. As aplicações criadas num ASE do ILB não são colocadas no DNS público.

As versões anteriores do ILB ASE exigiam que você fornecesse um sufixo de domínio e um certificado padrão para conexões HTTPS. O sufixo de domínio não é mais coletado na criação do ILB ASE e um certificado padrão também não é mais coletado. Quando você cria um ILB ASE agora, o certificado padrão é fornecido pela Microsoft e é confiável pelo navegador. Ainda pode definir nomes de domínio personalizados em aplicações no ASE e definir certificados nesses nomes de domínio personalizados.

Com um ILB ASE, você pode fazer coisas como:

Hospede aplicativos de intranet com segurança na nuvem, que você acessa por meio de um site a site ou ExpressRoute.
Proteja aplicativos com um dispositivo WAF
Alojar aplicações na cloud que não estão listadas em servidores DNS públicos.
Criar aplicações back-end isoladas da Internet, nas quais as suas aplicações front-end podem ser integradas em segurança.

Funcionalidades desativadas

Existem algumas coisas que não é possível fazer quando utiliza um ASE de ILB:

Use a ligação TLS/SSL baseada em IP.
Atribuir endereços IP a aplicações específicas.
Comprar e utilizar um certificado com uma aplicação através do portal do Azure. Pode obter certificados a partir diretamente de uma autoridade de certificação e utilizá-los com as suas aplicações. Não pode obtê-los através do portal do Azure.

Criar um ASE de ILB

Para criar um ASE ILB, consulte Criar um ASE usando um modelo do Azure Resource Manager.

Nota

O nome do Ambiente do Serviço de Aplicativo não deve ter mais de 36 caracteres.

Criar uma aplicação num ASE de ILB

Uma aplicação num ASE de ILB é criada da mesma forma que cria uma aplicação num ASE normalmente.

No portal do Azure, selecione Criar um recurso>Web>App.
Introduza o nome da aplicação.
Selecione uma subscrição.
Selecione ou crie um grupo de recursos.
Selecione sua publicação, pilha de tempo de execução e sistema operacional.
Selecione um local onde o local é um ASE ILB existente.
Selecione ou crie um plano do Serviço de Aplicações.
Selecione Rever e Criar e, em seguida, selecione Criar quando estiver pronto.

WebJobs, Funções e o ASE de ILB

Tanto as Funções como os WebJobs são suportados num ASE de ILB, mas para o portal funcionar com os mesmos, tem de ter acesso de rede ao site SCM. Isto significa que o browser tem de estar num anfitrião que esteja na rede virtual ou ligado à mesma. Se o ASE ILB tiver um nome de domínio que não termina em appserviceenvironment.net, terá de fazer com que o browser confie no certificado HTTPS que está a ser utilizado pelo site scm.

Configuração do DNS

Quando você usa um ASE externo, os aplicativos criados em seu ASE são registrados no DNS do Azure. Não há etapas adicionais em um ASE externo para que seus aplicativos estejam disponíveis publicamente. Com um ASE do ILB, tem de gerir o seu próprio DNS. Você pode fazer isso em seu próprio servidor DNS ou com zonas privadas do DNS do Azure.

Para configurar o DNS em seu próprio servidor DNS com seu ILB ASE:

criar uma zona para <o nome> ASE.appserviceenvironment.net
criar um registro A nessa zona que aponte * para o endereço IP ILB
criar um registro A nessa zona que aponte @ para o endereço IP do ILB
criar uma zona no <nome> ASE.appserviceenvironment.net chamada scm
criar um registro A na zona scm que aponte * para o endereço IP ILB

Para configurar o DNS em zonas privadas do DNS do Azure:

crie uma zona privada do DNS do Azure chamada <nome> ASE.appserviceenvironment.net
criar um registro A nessa zona que aponte * para o endereço IP ILB
criar um registro A nessa zona que aponte @ para o endereço IP do ILB
criar um registro A nessa zona que aponte *.scm para o endereço IP ILB

As configurações de DNS para o sufixo de domínio padrão ASE não restringem seus aplicativos a serem acessíveis apenas por esses nomes. Você pode definir um nome de domínio personalizado sem qualquer validação em seus aplicativos em um ILB ASE. Se você quiser criar uma zona chamada contoso.net, poderá fazê-lo e apontá-la para o endereço IP ILB. O nome de domínio personalizado funciona para solicitações de aplicativo, mas não para o site do scm. O site do scm só está disponível em <appname.scm>.<asename.appserviceenvironment.net>.

A zona denominada .<asename.appserviceenvironment.net> é globalmente único. Antes de maio de 2019, os clientes podiam especificar o sufixo de domínio do ILB ASE. Se você quisesse usar .contoso.com para o sufixo de domínio, você poderia fazê-lo e isso incluiria o site scm. Havia desafios com esse modelo, incluindo; gerenciando o certificado TLS/SSL padrão, a falta de logon único com o site do scm e o requisito de usar um certificado curinga. O processo de atualização do certificado padrão do ILB ASE também causou interrupções e causou reinicializações de aplicativos. Para resolver esses problemas, o comportamento do ILB ASE foi alterado para usar um sufixo de domínio baseado no nome do ASE e com um sufixo de propriedade da Microsoft. A alteração no comportamento do ILB ASE afeta apenas os ASE ILB feitos após maio de 2019. Os ASEs ILB pré-existentes ainda devem gerenciar o certificado padrão do ASE e sua configuração DNS.

Publicar com um ASE de ILB

Para cada aplicação criada, existem dois pontos finais. Em um ILB ASE, você tem <o nome> do aplicativo.<ILB ASE Domínio> e <nome> do aplicativo.scm.<Domínio> ILB ASE.

O nome do site SCM leva-o para a consola Kudu, denominada Portal avançado, no portal do Azure. A consola Kudu permite-lhe ver as variáveis de ambiente, explorar o disco, utilizar uma consola e muito mais. Para obter mais informações, veja Consola Kudu para o Serviço de Aplicações do Azure.

Os sistemas CI baseados na Internet, como o GitHub e o Azure DevOps, continuarão a funcionar com um ASE de ILB se o agente de compilação for acessível pela Internet e estiver na mesma rede que o ASE de ILB. Por isso, no caso do Azure DevOps, se o agente de compilação for criado na mesma VNET que o ASE de ILB (pode ser outra sub-rede), conseguirá obter o código do git do Azure DevOps e implementar no ASE de ILB. Se não quiser criar o seu próprio agente de compilação, terá de utilizar um sistema CI que utilize um modelo de extração, como o Dropbox.

Os pontos finais de publicação para aplicações num ASE de ILB utilizam o domínio com o qual o ASE de ILB foi criado. Este domínio aparece no perfil de publicação da aplicação e no painel do portal da aplicação (Descrição geral>Informações Básicas e também Propriedades). Se você tiver um ILB ASE com o sufixo <de domínio ASE name.appserviceenvironment.net> e um aplicativo chamado mytest, use mytest.<ASE name.appserviceenvironment.net> para FTP e mytest.scm.contoso.net para implantação do MSDeploy.

Configurar um ILB ASE com um dispositivo WAF

Você pode combinar um dispositivo WAF (Web Application Firewall) com seu ILB ASE para expor apenas os aplicativos desejados à Internet e manter o restante acessível apenas na VNet. Isso permite que você crie aplicativos seguros de várias camadas, entre outras coisas.

Para obter mais informações sobre como configurar o ASE de ILB com um dispositivo WAF, veja Configurar uma firewall de aplicações Web com o seu ambiente de Serviço de Aplicações. Este artigo mostra como utilizar uma aplicação virtual Barracuda com o seu ASE. Outra opção é utilizar o Gateway de Aplicação do Azure. O Gateway de Aplicação utiliza as regras de base da OWASP para proteger todas as aplicações colocadas atrás. Para obter mais informações sobre o Gateway de Aplicação, veja Introdução à firewall de aplicações Web do Azure.

ASE ILB realizadas antes de maio de 2019

Os ASEs ILB criados antes de maio de 2019 exigiam que você definisse o sufixo de domínio durante a criação do ASE. Eles também exigiam que você carregasse um certificado padrão baseado nesse sufixo de domínio. Além disso, com um ILB ASE mais antigo, você não pode executar o logon único no console Kudu com aplicativos nesse ILB ASE. Ao configurar o DNS para um ILB ASE mais antigo, você precisa definir o registro curinga A em uma zona que corresponda ao sufixo do seu domínio. Criar ou alterar o ILB ASE com sufixo de domínio personalizado exige que você use modelos do Azure Resource Manager e uma versão de api anterior a 2019. Última versão da api de suporte é 2018-11-01.

Começar agora

Para começar a utilizar ASEs, veja Introdução aos ambientes de Serviço de Aplicações.

Partilhar via