Como criar um ILB ASEv1 usando modelos do Azure Resource Manager

Artigo
07/17/2024

Importante

Este artigo é sobre o Ambiente do Serviço de Aplicativo v1. O Ambiente do Serviço de Aplicativo v1 será desativado em 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 29 de janeiro de 2024, você não poderá mais criar novos recursos do Ambiente do Serviço de Aplicativo v1 usando qualquer um dos métodos disponíveis, incluindo modelos ARM/Bicep, Portal do Azure, CLI do Azure ou API REST. Você deve migrar para o Ambiente do Serviço de Aplicativo v3 antes de 31 de agosto de 2024 para evitar a exclusão de recursos e a perda de dados.

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.

Descrição geral

Os Ambientes do Serviço de Aplicativo podem ser criados com um endereço interno de rede virtual em vez de um VIP público. Esse endereço interno é fornecido por um componente do Azure chamado ILB (balanceador de carga interno). Um ILB ASE pode ser criado usando o portal do Azure. Ele também pode ser criado usando automação por meio de modelos do Azure Resource Manager. Este artigo apresenta as etapas e a sintaxe necessárias para criar um ILB ASE com modelos do Azure Resource Manager.

Há três etapas envolvidas na automatização da criação de um ILB ASE:

Primeiro, o ASE base é criado em uma rede virtual usando um endereço de balanceador de carga interno em vez de um VIP público. Como parte desta etapa, um nome de domínio raiz é atribuído ao ILB ASE.
Depois que o ILB ASE é criado, um certificado TLS/SSL é carregado.
O certificado TLS/SSL carregado é explicitamente atribuído ao ILB ASE como seu certificado TLS/SSL "padrão". Este certificado TLS/SSL será usado para tráfego TLS para aplicativos no ILB ASE quando os aplicativos forem endereçados usando o domínio raiz comum atribuído ao ASE (por exemplo https://someapp.mycustomrootcomain.com)

Criação da Base ILB ASE

Um exemplo de modelo do Azure Resource Manager e seu arquivo de parâmetros associado estão disponíveis aqui.

A maioria dos parâmetros no arquivo azuredeploy.parameters.json são comuns à criação de ASEs ILB e ASEs vinculados a um VIP público. A lista abaixo chama a atenção para parâmetros de nota especial, ou que são exclusivos, ao criar um ILB ASE:

internalLoadBalancingMode: Determina como as portas de controle e de dados são expostas.
- 3 significa que tanto o tráfego HTTP/HTTPS nas portas 80/443, quanto as portas de canal de controle/dados ouvidas pelo serviço FTP no ASE, serão vinculados a um endereço interno de rede virtual alocado pelo ILB.
- 2 significa que apenas as portas relacionadas ao serviço FTP (canais de controle e de dados) serão vinculadas a um endereço ILB, enquanto o tráfego HTTP/HTTPS permanecerá no VIP público.
- 0 significa que todo o tráfego está vinculado ao VIP público, tornando o ASE externo.
dnsSuffix: Este parâmetro define o domínio raiz padrão que será atribuído ao ASE. Na variação pública do Serviço de Aplicativo do Azure, o domínio raiz padrão para todos os aplicativos Web é azurewebsites.net. No entanto, como um ASE ILB é interno à rede virtual de um cliente, não faz sentido usar o domínio raiz padrão do serviço público. Em vez disso, um ILB ASE deve ter um domínio raiz padrão que faça sentido para uso dentro da rede virtual interna de uma empresa. Por exemplo, uma hipotética Contoso Corporation pode usar um domínio raiz padrão de internal.contoso.com para aplicativos que se destinam a ser resolvidos e acessíveis apenas na rede virtual da Contoso.
ipSslAddressCount: Este parâmetro é automaticamente padronizado para um valor de 0 no arquivo de azuredeploy.json porque os ASEs ILB têm apenas um único endereço ILB. Não há endereços IP-SSL explícitos para um ILB ASE e, portanto, o pool de endereços IP-SSL para um ILB ASE deve ser definido como zero, caso contrário, ocorrerá um erro de provisionamento.

Depois que o arquivo de azuredeploy.parameters.json tiver sido preenchido para um ILB ASE, o ILB ASE poderá ser criado usando o seguinte trecho de código do PowerShell. Altere os caminhos de arquivo para corresponder ao local onde os arquivos de modelo do Azure Resource Manager estão localizados em sua máquina. Lembre-se também de fornecer seus próprios valores para o nome de implantação do Azure Resource Manager e o nome do grupo de recursos.

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

Depois que o modelo do Azure Resource Manager for enviado, levará algumas horas para que o ILB ASE seja criado. Quando a criação for concluída, o ILB ASE aparecerá no portal UX na lista de Ambientes do Serviço de Aplicativo para a assinatura que disparou a implantação.

Carregando e configurando o certificado TLS/SSL "padrão"

Depois que o ILB ASE é criado, um certificado TLS/SSL deve ser associado ao ASE como o uso "padrão" do certificado TLS/SSL para estabelecer conexões TLS/SSL com aplicativos. Continuando com o exemplo hipotético da Contoso Corporation, se o sufixo DNS padrão do ASE for internal.contoso.com, uma conexão com exigirá https://some-random-app.internal.contoso.com um certificado TLS/SSL válido para *.internal.contoso.com.

Há diferentes maneiras de obter um certificado TLS/SSL válido, incluindo CAs internas, compra de um certificado de um emissor externo e uso de um certificado autoassinado. Independentemente da origem do certificado TLS/SSL, os seguintes atributos de certificado precisam ser configurados corretamente:

Assunto: Este atributo deve ser definido como *.your-root-domain-here.com
Nome alternativo do assunto: Este atributo deve incluir *.your-root-domain-here.com e *.scm.your-root-domain-here.com. A razão para a segunda entrada é que as conexões TLS com o site SCM/Kudu associado a cada aplicativo serão feitas usando um endereço do formulário your-app-name.scm.your-root-domain-here.com.

Com um certificado TLS/SSL válido em mãos, duas etapas preparatórias adicionais são necessárias. O certificado TLS/SSL precisa ser convertido/salvo como um arquivo .pfx. Lembre-se de que o arquivo .pfx precisa incluir todos os certificados intermediários e raiz, e também precisa ser protegido com uma senha.

Em seguida, o arquivo .pfx resultante precisa ser convertido em uma cadeia de caracteres base64 porque o certificado TLS/SSL será carregado usando um modelo do Azure Resource Manager. Como os modelos do Azure Resource Manager são arquivos de texto, o arquivo .pfx precisa ser convertido em uma cadeia de caracteres base64 para que possa ser incluído como um parâmetro do modelo.

O trecho de código do PowerShell abaixo mostra um exemplo de geração de um certificado autoassinado, exportação do certificado como um arquivo .pfx, conversão do arquivo .pfx em uma cadeia de caracteres codificada em base64 e, em seguida, salvando a cadeia de caracteres codificada em base64 em um arquivo separado. O código do PowerShell para codificação base64 foi adaptado do Blog de Scripts do PowerShell.

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password     

$fileContentBytes = get-content -encoding byte $fileName
$fileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
$fileContentEncoded | set-content ($fileName + ".b64")

Depois que o certificado TLS/SSL tiver sido gerado com êxito e convertido em uma cadeia de caracteres codificada em base64, o modelo de exemplo do Azure Resource Manager para configurar o certificado TLS/SSL padrão poderá ser usado.

Os parâmetros no arquivo azuredeploy.parameters.json estão listados abaixo:

appServiceEnvironmentName: O nome do ASE ILB que está sendo configurado.
existingAseLocation: Cadeia de caracteres de texto que contém a região do Azure onde o ILB ASE foi implantado. Por exemplo: "Centro-Sul dos EUA".
pfxBlobString: A representação de cadeia de caracteres codificada based64 do arquivo .pfx. Usando o trecho de código mostrado anteriormente, você copiaria a cadeia de caracteres contida em "exportedcert.pfx.b64" e a colaria como o valor do atributo pfxBlobString .
password: A senha usada para proteger o arquivo .pfx.
certificateThumbprint: A impressão digital do certificado. Se você recuperar esse valor do PowerShell (por exemplo , $certThumbprint do trecho de código anterior), poderá usar o valor no estado em que se encontra. No entanto, se você copiar o valor da caixa de diálogo de certificado do Windows, lembre-se de remover os espaços estranhos. O certificadoImpressão digital deve ter a seguinte aparência: AF3143EB61D43F6727842115BB7F17BBCECAECAE
certificateName: um identificador de cadeia de caracteres amigável de sua própria escolha usado para identificar o certificado. O nome é usado como parte do identificador exclusivo do Azure Resource Manager para a entidade Microsoft.Web/certificates que representa o certificado TLS/SSL. O nome deve terminar com o seguinte sufixo: _yourASENameHere_InternalLoadBalancingASE. Esse sufixo é usado pelo portal como um indicador de que o certificado é usado para proteger um ASE habilitado para ILB.

Um exemplo abreviado de azuredeploy.parameters.json é mostrado abaixo:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "appServiceEnvironmentName": {
            "value": "yourASENameHere"
        },
        "existingAseLocation": {
            "value": "East US 2"
        },
        "pfxBlobString": {
            "value": "MIIKcAIBAz...snip...snip...pkCAgfQ"
        },
        "password": {
            "value": "PASSWORDGOESHERE"
        },
        "certificateThumbprint": {
            "value": "AF3143EB61D43F6727842115BB7F17BBCECAECAE"
        },
        "certificateName": {
            "value": "DefaultCertificateFor_yourASENameHere_InternalLoadBalancingASE"
        }
    }
}

Depois que o arquivo azuredeploy.parameters.json for preenchido, o certificado TLS/SSL padrão poderá ser configurado usando o seguinte trecho de código do PowerShell. Altere os caminhos de arquivo para corresponder ao local onde os arquivos de modelo do Azure Resource Manager estão localizados em sua máquina. Lembre-se também de fornecer seus próprios valores para o nome de implantação do Azure Resource Manager e o nome do grupo de recursos.

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

Depois que o modelo do Azure Resource Manager for enviado, levará aproximadamente 40 minutos por front-end ASE para aplicar a alteração. Por exemplo, com um ASE de tamanho padrão usando dois front-ends, o modelo levará cerca de 1 hora e 20 minutos para ser concluído. Enquanto o modelo estiver em execução, o ASE não poderá ser dimensionado.

Quando o modelo for concluído, os aplicativos no ILB ASE poderão ser acessados por HTTPS e as conexões serão protegidas usando o certificado TLS/SSL padrão. O certificado TLS/SSL padrão será usado quando os aplicativos no ILB ASE forem endereçados usando uma combinação do nome do aplicativo mais o nome do host padrão. Por exemplo, https://mycustomapp.internal.contoso.com usaria o certificado TLS/SSL padrão para *.internal.contoso.com.

No entanto, assim como os aplicativos executados no serviço multilocatário público, os desenvolvedores também podem configurar nomes de host personalizados para aplicativos individuais e, em seguida, configurar associações de certificado SNI TLS/SSL exclusivas para aplicativos individuais.

Introdução

Para começar a usar os Ambientes do Serviço de Aplicativo, consulte Introdução ao Ambiente do Serviço de Aplicativo

Nota

Se pretender começar a utilizar o App Service do Azure antes de se inscrever numa conta do Azure, aceda a Experimentar o App Service, onde pode criar de imediato uma aplicação Web de arranque de curta duração no App Service. Sem cartões de crédito; sem compromissos.

Partilhar via