Compartilhar via

Criar um ASE usando um modelo do Azure Resource Manager

  • Artigo

Visão geral

Importante

Este artigo aborda o Ambiente do Serviço de Aplicativo v2, que é usado com planos do Serviço de Aplicativo Isolado. As versões v1 e v2 do Ambiente do Serviço de Aplicativo foram desativadas 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 31 de agosto de 2024, o SLA (Contrato de Nível de Serviço) e os Créditos de Serviço deixaram de se aplicar às cargas de trabalho do Ambiente do Serviço de Aplicativo v1 e v2 que continuam em produção, já que 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 aplicativos e dados.

Você precisa executar a migração para o Ambiente do Serviço de Aplicativo v3 imediatamente. Caso contrário, 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, os recursos e dados de aplicativos 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 a realização da migração. Para saber mais e solicitar o período de carência, confira a visão geral do período de carência, acesse o portal do Azure e visite a lâmina Migração para cada um dos 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.

Os ASEs (Ambientes do Serviço de Aplicativo) do Azure podem ser criados com um ponto de extremidade acessível pela Internet ou um ponto de extremidade em um endereço interno em uma Rede Virtual do Azure. Quando criado com um ponto de extremidade interno, esse ponto de extremidade é fornecido por um componente do Azure chamado ILB (balanceador de carga interno). O ASE em um endereço IP interno é chamado de um ASE ILB. O ASE com um ponto de extremidade público é chamado de um ASE externo.

Um ASE pode ser criado usando o portal do Azure ou um modelo do Azure Resource Manager. Este artigo explica as etapas e a sintaxe que você precisa para criar um ASE Externo ou um ASE ILB com modelos do Resource Manager. Para saber como criar um ASEv2 no portal do Azure, consulte [Fazer um ASE externo][FazerASEerterno] ou Fazer um ASE ILB.

Ao criar um ASE no portal do Azure, você pode criar sua rede virtual ao mesmo tempo ou escolher uma rede virtual pré-existente na qual implantar.

Ao criar um ASE com base em um modelo, você deve começar com:

  • Uma Rede Virtual do Azure.
  • Uma sub-rede nessa rede virtual. Recomendamos um tamanho de sub-rede ASE de /24 com 256 endereços para acomodar necessidades futuras de crescimento e dimensionamento. Depois que o ASE é criado, você não pode alterar o tamanho.
  • A assinatura na qual você deseja implantar.
  • O local no qual você deseja implantar.

Para automatizar a criação do ASE, siga as diretrizes nas seções a seguir. Se você estiver criando um ASEv2 ILB com dnsSuffix personalizado (por exemplo, internal.contoso.com), haverá mais algumas coisas a fazer.

  1. Depois que o ASE ILB com dnsSuffix personalizado for criado, um certificado TLS/SSL correspondente ao domínio do ASE ILB precisa ser carregado.

  2. O certificado TLS/SSL carregado é atribuído ao ASE ILB como o certificado TLS/SSL "padrão". Esse certificado SSL será usado para o tráfego TLS/SSL para os aplicativos no ASE ILB quando eles usarem o domínio raiz comum atribuído ao ASE (por exemplo, https://someapp.internal.contoso.com).

Criar o ASE

Um modelo do Resource Manager que cria um ASE e seu arquivo de parâmetros associado está disponível no GitHub para o ASEv2.

Se você quiser fazer um ASE, use esse exemplo de ASEv2 do modelo do Resource Manager. A maioria dos parâmetros no arquivo azuredeploy.parameters.json é comum à criação de ASEs ILB e ASEs Externos. A lista a seguir identifica parâmetros de anotação especial ou que são exclusivos, quando você cria um ASE ILB com uma sub-rede existente.

Parâmetros

  • aseName: esse parâmetro define um nome de ASE exclusivo.
  • location: esse parâmetro define o local do Ambiente do Serviço de Aplicativo.
  • existingVirtualNetworkName: esse parâmetro define o nome da rede virtual da rede virtual e da sub-rede existentes em que o ASE residirá.
  • existingVirtualNetworkResourceGroup: esse parâmetro define o nome do grupo de recursos da rede virtual e da sub-rede existentes em que o ASE residirá.
  • subnetName: esse parâmetro define o nome da sub-rede da rede virtual e da sub-rede existentes em que o ASE residirá.
  • internalLoadBalancingMode: na maioria dos casos, define como 3, o que 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. Se essa propriedade é definida como 2, somente as portas relacionadas de serviço FTP (canais de controle e de dados) estão associadas a um endereço ILB. Se essa propriedade for definida como 0, o tráfego HTTP/HTTPS permanecerá no VIP público.
  • dnsSuffix: Esse parâmetro define o domínio-raiz padrão que é 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. Como um ASE ILB é interno na rede virtual do cliente, não faz sentido usar o domínio-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, a Contoso Corporation pode usar um domínio raiz padrão de internal.contoso.com para aplicativos que devem ser resolvidos e acessíveis somente na rede virtual da Contoso. Para especificar o domínio raiz personalizado, você precisa usar a versão 2018-11-01 da API ou versões anteriores.
  • ipSslAddressCount: Esse parâmetro padroniza automaticamente para um valor 0 no arquivo azuredeploy.json porque os ASEs ILB têm apenas um único endereço ILB. Não há nenhum endereço IP SSL explícito para um ASE ILB. 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.

Após o arquivo azuredeploy.parameters.json ser preenchido, crie o ASE usando o snippet de código do PowerShell. Altere os caminhos do arquivo para corresponder aos locais do modelo Resource Manager no seu computador. Lembre-se de fornecer seus próprios valores para o nome de implantação do 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

A criação do ASE leva cerca de duas horas. Em seguida, o ASE aparece no portal na lista de ASEs para a assinatura que disparou a implantação.

Carregar e configurar o certificado TLS/SSL "padrão"

Um certificado TLS/SSL precisa ser associado ao ASE como o certificado TLS/SSL "padrão" que é usado para estabelecer conexões TLS com aplicativos. Se o sufixo DNS padrão do ASE for internal.contoso.com, uma conexão com https://some-random-app.internal.contoso.com exigirá um certificado TLS/SSL válido para *.internal.contoso.com.

Obtenha um certificado TLS/SSL válido usando autoridades de certificação internas, comprando um certificado de um emissor externo ou usando um certificado autoassinado. Independentemente da origem do certificado TLS/SSL, os seguintes atributos de certificado precisam ser configurados corretamente:

  • Assunto: Esse atributo deve ser definido para * .domínio-raiz-aqui.com.
  • Nome alternativo da entidade: este atributo deve incluir .your-root-domain-here.com e*.scm.your-root-domain-here.com*. As conexões TLS com o site do SCM/Kudu associadas a cada aplicativo usam um endereço no formato nome-do-aplicativo.scm.domínio-raiz-aqui.com.

Com um certificado TLS/SSL válido em mãos, são necessárias mais duas etapas preparatórias. Converta ou salve o certificado TLS/SSL como um arquivo .pfx. Lembre-se que o arquivo .pfx deve incluir todos os certificados intermediários e raiz. Proteja-o com uma senha.

O arquivo .pfx deve ser convertido em uma cadeia de caracteres base64, porque o certificado TLS/SSL é carregado por meio de um modelo do Resource Manager. Como os modelos do Resource Manager são arquivos de texto, o arquivo. pfx deve ser convertido em uma cadeia de caracteres base64. Dessa forma pode ser incluído como um parâmetro do modelo.

Use o seguinte snippet de código do PowerShell para:

  • Criar um certificado autoassinado.
  • Exportar o certificado como um arquivo. pfx.
  • Converter o arquivo. pfx em uma cadeia de caracteres codificada em base64.
  • Salvar a cadeia de caracteres codificada em base64 em um arquivo separado.

Este 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 for gerado e convertido com êxito em uma cadeia de caracteres codificada em base64, use o modelo de exemplo do Resource Manager Configurar o certificado SSL padrão no GitHub.

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 base 64 do arquivo .pfx. Use o snippet de código mostrado anteriormente e copie a cadeia de caracteres contida em "exportedcert.pfx.b64". Cole-o como o valor de 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, $certificate.Thumbprint do snippet de código anterior), poderá usar o valor como estiver. 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 Resource Manager para a entidade Microsoft.Web/certificates que representa o certificado TLS/SSL. O nome deve terminar com o seguinte sufixo: _yourASENameHere_InternalLoadBalancingASE. O portal do Azure usa esse sufixo como um indicador de que o certificado é usado para proteger um ASE habilitado por ILB.

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

{
  "$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"
    }
  }
}

Após o arquivo azuredeploy.parameters.json ser preenchido, configure o certificado TLS/SSL padrão usando o snippet de código do PowerShell. Altere os caminhos do arquivo para corresponder ao local em que os arquivos do modelo do Resource Manager estão localizados no seu computador. Lembre-se de fornecer seus próprios valores para o nome de implantação do 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

Leva cerca de 40 minutos por front-end ASE para aplicar a alteração. Por exemplo, para um ASE padrão dimensionado que usa dois front-ends, o modelo leva aproximadamente uma hora e 20 minutos para concluir. Enquanto o modelo estiver em execução, o ASE não pode ser dimensionado.

Depois que o modelo for concluído, aplicativos em ASE ILB podem ser acessados via HTTPS. As conexões são protegidas por meio do certificado TLS/SSL padrão. O certificado TLS/SSL padrão será usado quando os aplicativos no ASE ILB forem endereçados com uma combinação de nome do aplicativo com o nome do host padrão. Por exemplo, https://mycustomapp.internal.contoso.comusa o certificado TLS/SSL padrão para *.internal.contoso.com.

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