Criar e usar um Ambiente do Serviço de Aplicativo de Balanceador de Carga Interno
Importante
Este artigo aborda o Ambiente do Serviço de Aplicativo v2, que é usado com planos do Serviço de Aplicativo Isolado. O Ambiente do Serviço de Aplicativo v1 e v2 foi desativado em 31 de agosto de 2024. Há uma nova versão do Ambiente de Serviço de Aplicativo que é mais fácil de usar e é executado na infraestrutura mais avançada. Para saber mais sobre a nova versão, comece com 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 aplicarão mais às cargas de trabalho do Ambiente do Serviço de Aplicativo v1 e v2 que continuarem em produção, pois são produtos desativados. A desativação do hardware do Ambiente do Serviço de Aplicativo v1 e v2 foi iniciada, o que poderá 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 poderão ser excluídos. Tentaremos migrar automaticamente qualquer Ambiente do Serviço de Aplicativo v1 e v2 restantes com base no melhor esforço usando o recurso de migração in-loco. No enanto, a Microsoft não afirma ou garante a disponibilidade do aplicativo após a migração automática. Talvez seja necessário realizar 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 aplicativo associados serão excluídos. Recomendamos fortemente que você tome uma atitude agora para evitar esses cenários extremos.
Se você precisar de mais tempo, podemos oferecer um período de carência único de 30 dias para concluir sua migração. Para mais informações e para solicitar este período de carência, consulte a visão geral sobre o período de carência e, em seguida, acesse 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 de uma VNet (rede virtual) do Azure. Há duas maneiras de implantar um ASE (ambiente do serviço de aplicativo):
- Com um VIP em um endereço IP externo, geralmente chamado de ASE externo.
- Com um VIP em um endereço IP interno, geralmente chamado de ASE ILB devido ao ponto de extremidade interno ser um balanceador de carga interno (ILB).
Este artigo mostra como criar um ASE ILB. Para obter uma visão geral do ASE, confira Introdução aos ambientes do Serviço de Aplicativo. Para saber como criar um ASE externo, consulte [Criar um ASE externo][MakeExternalASE].
Visão geral
Um ASE pode ser implantado com um ponto de extremidade acessível pela Internet ou com um endereço IP em sua VNet. Para definir o endereço IP como um endereço de VNet, o ASE deve ser implantado com um ILB. Quando você implanta o 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 em seu ASE. O sufixo de domínio do seu ILB ASE é <ASE name>.appserviceenvironment.net. Aplicativos feitos em um ILB ASE não são colocados no DNS público.
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. Agora, quando você cria um ILB ASE, o certificado padrão é fornecido pela Microsoft e é de confiança do navegador. Ainda é possível definir nomes de domínio personalizados em aplicativos em seu ASE e definir certificados nesses nomes de domínio personalizados.
Com um ILB ASE, você pode fazer coisas como:
- hospedar aplicativos de intranet com segurança na nuvem, que são acessados site a site ou por ExpressRoute.
- Proteger aplicativos com um dispositivo WAF
- Hospedar aplicativos na nuvem que não estão listados em servidores DNS públicos.
- Criar aplicativos back-end isolados da Internet, que podem ser integrados com seus aplicativos front-end com segurança.
Funcionalidade desabilitada
Há algumas coisas que você não pode fazer ao usar um ASE ILB:
- Use a associação TLS/SSL baseada em IP.
- Atribuir endereços IP a aplicativos específicos.
- Comprar e usar um certificado com um aplicativo por meio do portal do Azure. Você pode obter certificados diretamente de uma autoridade de certificação e usá-los com seus aplicativos. Não é possível obtê-los por meio do portal do Azure.
Criar um ASE ILB
Para criar um ASE ILB, consulte Criar um ASE usando um modelo do Azure Resource Manager.
Observação
O nome do Ambiente do Serviço de Aplicativo deve ter, no máximo, 36 caracteres.
Como criar um aplicativo em uma ASE ILB
Você pode criar um aplicativo em uma ASE ILB da mesma maneira que você cria um aplicativo em um ASE.
No portal do Azure, selecione Criar um recurso>Web>Aplicativo Web.
Digite o nome do aplicativo.
Selecione a assinatura.
Selecione ou crie um grupo de recursos.
Selecione a Publicação, Pilha de Runtime e Sistema Operacional.
Selecione um local que seja um ILB ASE existente.
Selecione ou crie um plano do Serviço de Aplicativo.
Selecione Revisar e Criar e selecione Criar quando tudo estiver pronto.
Trabalhos da Web, Funções e o ILB ASE
As Funções e os trabalhos da Web são suportados em um ILB ASE, mas para que o portal funcione com eles, você deve ter acesso de rede ao site SCM. Isso significa que seu navegador deve estar em um host que esteja na rede virtual ou conectado a ela. Se o ILB ASE tiver um nome de domínio que não terminam em appserviceenvironment.net, você precisará fazer seu navegador confiar no certificado HTTPS que está sendo usado por seu site do scm.
Configuração de DNS
Quando você usa um ASE Externo, os aplicativos criados no ASE são registrados com o DNS do Azure. Não há etapas adicionais em um ASE Externo para os aplicativos fiquem disponíveis publicamente. Com um ASE do ILB, você precisa gerenciar seu DNS. Você pode fazer isso em seu servidor DNS ou em Zonas Privadas do DNS do Azure.
Para configurar o DNS em seu servidor DNS com o ASE do ILB:
- crie uma zona para <nome do ASE>.appserviceenvironment.net
- crie um registro A nessa zona que aponte * para o endereço IP do ILB
- crie um registro A nessa zona que aponte @ para o endereço IP do ILB
- crie uma zona em <nome do ASE>.appserviceenvironment.net chamada scm
- crie um registro A na zona scm que aponte * para o endereço IP do ILB
Para configurar o DNS em Zonas Privadas do DNS do Azure:
- crie uma zona privada de DNS do Azure chamada <ASE name>.appserviceenvironment.net
- crie um registro A nessa zona que aponte * para o endereço IP do ILB
- crie um registro A nessa zona que aponte @ para o endereço IP do ILB
- crie um registro A nessa zona que aponte *.scm para o endereço IP do ILB
As configurações de DNS do sufixo de domínio padrão do ASE não restringem seus aplicativos a serem acessados apenas por esses nomes. Você pode definir um nome de domínio personalizado sem nenhuma validação em seus aplicativos em um ASE do ILB. Se quiser criar uma zona chamada contoso.net, você poderá fazer isso e apontá-la para o endereço IP do 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 chamada .<asename>.appserviceenvironment.net é globalmente exclusiva. Antes de maio de 2019, os usuários podiam especificar o sufixo de domínio do ASE do ILB. Se quisesse usar .contoso.com como sufixo de domínio, você poderia fazer isso e o site do scm seria incluído. Havia desafios com esse modelo, incluindo o gerenciamento do certificado TLS/SSL padrão, a falta de logon único com o site do SCM e a necessidade de usar um certificado curinga. O processo de atualização de certificado padrão do ASE do ILB também era problemático e causava a reinicialização do aplicativo. Para resolver esses problemas, o comportamento do ASE do ILB foi alterado de maneira a passar a 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 ASE do ILB afeta apenas o ASEs do ILB criados após maio de 2019. ASEs do ILB preexistente ainda precisam gerenciar o certificado padrão do ASE e sua configuração de DNS.
Publicação com um ASE ILB
Para cada aplicativo criado, há dois pontos de extremidade. Em um ILB ASE, você tem <nome do aplicativo>.<Domínio ILB ASE> e <nome do aplicativo>.scm.<Domínio ILB ASE> .
O nome do site SCM leva você para o console do Kudu, que é chamado de Portal avançado no portal do Azure. O console do Kudu lhe permite visualizar as variáveis de ambiente, explorar o disco, usar um console e muito mais. Para obter mais informações, confira Console do Kudu para o Serviço de Aplicativo do Azure.
Sistemas CI baseados na internet, como o GitHub e o Azure DevOps ainda funcionam com uma ASE ILB se o agente de build for acessível pela internet e na mesma rede como ASE ILB. Dessa forma, no caso do Azure DevOps, se o agente de build for criado na mesma VNET como ILB ASE (sub-rede diferente é adequada), poderá extrair o código do git do Azure DevOps e implantar ao ASE ILB. Se você não quiser criar seu próprio agente de build, você precisa usar um sistema de CI que usa um modelo de pull, como o Dropbox.
Os pontos de extremidade de publicação para aplicativos em um ASE ILB usam o domínio com o qual o ASE ILB foi criado. Este domínio é exibido no perfil de publicação do aplicativo e na folha do portal do aplicativo (Visão geral>Essentials e também Propriedades). Se você tiver um ILB ASE com o sufixo de domínio <nome do ASE>.appserviceenvironment.net e um aplicativo chamado mytest, use mytest.<nome do ASE>.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 (firewall do aplicativo Web) com seu ILB ASE para expor para a internet somente os aplicativos que você quiser e manter o restante acessível apenas na VNet. Isso permite que você crie aplicativos seguros de várias camadas, entre outras coisas.
Para saber mais sobre como configurar o ASE do ILB com um dispositivo WAF, confira Configurar um firewall do aplicativo Web com o Ambiente do Serviço de Aplicativo. Este artigo mostra como usar uma solução de virtualização Barracuda com o seu ASE. Outra opção é usar o gateway de aplicativo do Azure. O gateway de aplicativo usa as regras básicas do OWASP para proteger os aplicativos colocados atrás dele. Para obter mais informações sobre o Gateway de Aplicativo do Azure, confira Introdução ao firewall de aplicativo Web do Azure.
ILB ASEs criados antes de maio de 2019
ILB ASEs criados antes de maio de 2019 exigiam a definição do sufixo de domínio durante a criação do ASE. Também exigiam o upload de um certificado padrão baseado nesse sufixo de domínio. Além disso, com um ILB ASE mais antigos, você não pode executar logon único no console do Kudu com aplicativos no ILB ASE. Ao configurar o DNS para um ILB ASE mais antigo, você precisa definir o registro A de caractere curinga em uma zona que corresponda ao seu sufixo de domínio. Criar ou alterar o ASE do ILB com sufixo de domínio personalizado exige que você use modelos do Azure Resource Manager e uma versão de API anterior a 2019. A última versão suportada da API é 2018-11-01
.
Introdução
- Para começar a usar ASEs, confira Introdução aos ambientes do Serviço de Aplicativo.