Como criar um ASE ILBv1 usando modelos do Azure Resource Manager

  • Artigo

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 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.

Desde 29 de janeiro de 2024, você não pode mais criar recursos do Ambiente do Serviço de Aplicativo v1 usando um dos métodos disponíveis, incluindo os modelos do ARM/Bicep, o portal do Azure, a CLI do Azure ou a API REST. Você precisará 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.

Visão geral

Ambientes de 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 ASE ILB pode ser criado usando o portal do Azure. Ele também pode ser criado usando a automação por meio de modelos do Azure Resource Manager. Este artigo explica as etapas e a sintaxe necessária para criar um ASE ILB com modelos do Azure Resource Manager.

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

  1. 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 dessa etapa, um nome de domínio raiz é atribuído ao ASE ILB.
  2. Depois que o ASE ILB é criado, um certificado TLS/SSL é carregado.
  3. O certificado TLS/SSL carregado foi atribuído explicitamente à ASE ILB como o certificado TLS/SSL "padrão". Esse certificado TLS/SSL será usado para o tráfego TLS/SSL dos aplicativos no ASE ILB quando eles forem endereçados utilizando o domínio raiz comum atribuído ao ASE (por exemplo, https://someapp.mycustomrootcomain.com)

Criando o ASE ILB base

Um modelo do Azure Resource Manager de exemplo 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 para criar os ASEs ILB, e ASEs associados a um VIP público. A lista abaixo, ao criar um ASE ILB, chama parâmetros de anotação especial ou exclusivos:

  • internalLoadBalancingMode: determina como as portas de controle e de dados são expostas.
    • 3, significa que o tráfego HTTP/HTTPS nas portas 80/443 e as portas do canal de dados/controle atendidas pelo serviço FTP no ASE serão associados a um endereço interno da rede virtual alocada do ILB.
    • 2, significa que somente as portas relacionadas ao serviço FTP (canais de controle e de dados) serão associadas a um endereço ILB, ao passo que 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: esse parâmetro define o domínio de raiz padrão que será atribuído ao ASE. A variação pública do Serviço de Aplicativo do Azure, o domínio de raiz padrão para todos os aplicativos Web, é azurewebsites.net. No entanto, como um ASE ILB é interno na rede virtual do cliente, não faz sentido usar o domínio de raiz padrão do serviço público. Em vez disso, um ASE ILB deve ter um domínio de raiz padrão que faça sentido para uso dentro da rede virtual interna da empresa. Por exemplo, uma hipotética Contoso Corporation pode usar um domínio raiz padrão de internal.contoso.com para aplicativos que devem ser resolvidos e acessíveis apenas na rede virtual da Contoso.
  • ipSslAddressCount: esse parâmetro é automaticamente padronizado para o valor 0 no arquivo azuredeploy.json porque os ASEs do ILB têm apenas um endereço ILB. Não há nenhum endereço IP SSL explícito para um ASE ILB e, portanto, o pool de endereços IP SSL para um ASE ILB deve ser definido como zero. Caso contrário, ocorrerá um erro de provisionamento.

Quando o arquivo azuredeploy.parameters.json for preenchido para um ASE ILB, o ASE ILB poderá ser criado usando o snippet de código do PowerShell a seguir. Altere os caminhos do arquivo para corresponder ao local em que os arquivos do modelo do Azure Resource Manager estão localizados no seu computador. Além disso, lembre-se de fornecer seus próprios valores para o nome de implantação do Azure Resource Manager e para 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 o ASE ILB ser criado. Uma vez concluída a criação, o ASE ILB aparecerá no portal de experiência do usuário na lista de Ambientes de Serviço de Aplicativo para a assinatura que disparou a implantação.

Carregando e configurando o Certificado TLS/SSL "Padrão"

Com o ILB ASE criado, um certificado TLS/SSL deve ser associado ao ASE como o certificado TLS/SSL “padrão” usado 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, então, uma conexão com https://some-random-app.internal.contoso.com exigirá um certificado TLS/SSL válido para *.internal-contoso.com.

Há diferentes maneiras de obter um certificado TLS/SSL válido, incluindo autoridades de certificação internas, comprar um certificado de um emissor externo e usar um certificado autoassinado. Independentemente da origem do certificado TLS/SSL, os seguintes atributos de certificado devem ser configurados corretamente:

  • Entidade: esse atributo precisa ser definido como *.domínio-raiz-aqui.com
  • Nome Alternativo da Entidade: esse atributo precisa incluir *.domínio-raiz-aqui.com e *.scm.domínio-raiz-aqui.com. O motivo 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, são necessárias mais duas etapas preparatórias. O certificado TLS/SSL precisa ser convertido/salvo como um arquivo .pfx. Lembre-se de que o arquivo .pfx deve incluir todos os certificados intermediários e raiz e também precisa ser protegido com uma senha.

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

O snippet de código do PowerShell abaixo mostra um exemplo de como gerar um certificado autoassinado, exportar o certificado como um arquivo .pfx, converter o arquivo .pfx em uma cadeia de caracteres codificada em Base64 e salvar essa cadeia de caracteres em um arquivo separado. O código do PowerShell para a codificação de 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 do Azure Resource Manager de exemplo 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 ASE ILB foi implantado. Por exemplo, "Centro-Sul dos EUA".
  • pfxBlobString: a representação de cadeia de caracteres codificada em based64 do arquivo .pfx. Usando o snippet de código mostrado anteriormente, copie a cadeia de caracteres contida no "exportedcert.pfx.b64" e cole-a como o valor do atributo pfxBlobString.
  • password: A senha usada para proteger o arquivo .pfx.
  • certificateThumbprint: impressão digital do certificado. Se você recuperar esse valor do PowerShell (por exemplo $certThumbprint do snippet de código anterior), poderá usar o valor como estiver. No entanto se você copiar o valor da caixa de diálogo Certificado Windows, lembre-se de retirar os espaços estranhos. O certificateThumbprint deve ser semelhante a: AF3143EB61D43F6727842115BB7F17BBCECAECAE
  • certificateName: um identificador de cadeia de caracteres amigável de sua 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 precisa terminar com o seguinte sufixo: seuNomeASEAqui_ASEdeBalanceamentoDeCargaInterno. Esse sufixo é usado pelo portal como um indicador de que o certificado é usado para proteger um ASE habilitado por 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"
        }
    }
}

Quando o arquivo azuredeploy.parameters.json tiver sido preenchido, o certificado TLS/SSL padrão poderá ser configurado usando o snippet de código do PowerShell a seguir. Altere os caminhos do arquivo para corresponder ao local em que os arquivos do modelo do Azure Resource Manager estão localizados no seu computador. Além disso, lembre-se de fornecer seus próprios valores para o nome de implantação do Azure Resource Manager e para 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 do ASE para aplicar a alteração. Por exemplo, com um ASE padrão dimensionado usando dois front-ends, o modelo levará aproximadamente 1 hora e 20 minutos para concluir. Enquanto o modelo estiver em execução, o ASE não poderá ser dimensionado.

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

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

Introdução

Para se familiarizar com os ambientes de serviço de aplicativo, consulte Introdução ao ambiente do serviço de aplicativo

Observação

Se você deseja começar com o Serviço de Aplicativo do Azure antes de se inscrever em uma conta do Azure, acesse Experimentar o Serviço de Aplicativo, em que você pode criar imediatamente um aplicativo Web inicial de curta duração no Serviço de Aplicativo. Nenhum cartão de crédito é exigido, sem compromissos.