Partilhar via

Criar um ASE com um modelo do Azure Resource Manager

  • Artigo

Descrição geral

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.

Os ambientes do Serviço de Aplicativo do Azure (ASEs) 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 ILB ASE. O ASE com um ponto de extremidade público é chamado de ASE externo.

Um ASE pode ser criado usando o portal do Azure ou um modelo do Azure Resource Manager. Este artigo descreve as etapas e a sintaxe necessárias para criar um ASE externo ou ILB ASE com modelos do Gerenciador de Recursos. Para saber como criar um ASEv2 no portal do Azure, consulte [Criar um ASE externo][MakeExternalASE] ou Criar 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 para implantar.

Ao criar um ASE a partir de 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 com 256 endereços para acomodar as necessidades futuras de /24 crescimento e escala. Depois que o ASE é criado, não é possível alterar o tamanho.
  • A assinatura na qual você deseja implantar.
  • O local em que você deseja implantar.

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

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

  2. O certificado TLS/SSL carregado é atribuído ao ILB ASE como seu certificado TLS/SSL "padrão". Esse certificado é usado para tráfego TLS/SSL para aplicativos no ASE ILB quando eles usam 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 ASEv2.

Se você quiser criar um ASE, use este exemplo de modelo ASEv2 do Resource Manager. A maioria dos parâmetros no arquivo azuredeploy.parameters.json são comuns à criação de ASEs ILB e ASEs externos. A lista a seguir chama parâmetros de nota especial, ou que são exclusivos, quando você cria um ILB ASE com uma sub-rede existente.

Parâmetros

  • aseName: Este parâmetro define um nome ASE exclusivo.
  • location: este parâmetro define o local do Ambiente do Serviço de Aplicativo.
  • existingVirtualNetworkName: Este parâmetro define o nome da rede virtual da rede virtual existente e da sub-rede onde o ASE residirá.
  • existingVirtualNetworkResourceGroup: seu parâmetro define o nome do grupo de recursos da rede virtual existente e da sub-rede onde o ASE residirá.
  • subnetName: Este parâmetro define o nome da sub-rede da rede virtual existente e da sub-rede onde o ASE residirá.
  • internalLoadBalancingMode: Na maioria dos casos, defina isso como 3, o que 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 por ILB. Se essa propriedade for definida como 2, somente as portas relacionadas ao serviço FTP (canais de controle e de dados) serão vinculadas a um endereço ILB. Se essa propriedade for definida como 0, o tráfego HTTP/HTTPS permanecerá no VIP público.
  • dnsSuffix: Este parâmetro define o domínio raiz padrão 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. 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, a Contoso Corporation pode usar um domínio raiz padrão de internal.contoso.com para aplicativos que se destinam a ser resolúveis 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 assume automaticamente como padrão um valor 0 no arquivo azuredeploy.json porque os ASEs ILB têm apenas um único endereço ILB. Não existem endereços IP-SSL explícitos para um ILB ASE. Assim, 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 azuredeploy.parameters.json for preenchido, crie o ASE usando o trecho de código do PowerShell. Altere os caminhos de arquivo para corresponder aos locais de arquivo de modelo do Resource Manager em sua máquina. Lembre-se de fornecer seus próprios valores para o nome de implantação do Gerenciador de Recursos 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

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

Carregue e configure o certificado TLS/SSL "padrão"

Um certificado TLS/SSL deve ser associado ao ASE como o certificado TLS/SSL "padrão" usado para estabelecer conexões TLS com aplicativos. 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.

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 devem 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*. As conexões TLS com o site SCM/Kudu associado a cada aplicativo usam 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. Converta/salve o certificado TLS/SSL como um arquivo .pfx. Lembre-se de que o arquivo .pfx deve incluir todos os certificados intermediários e raiz. Proteja-o com uma palavra-passe.

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

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

  • Gere um certificado autoassinado.
  • Exporte o certificado como um arquivo .pfx.
  • Converta o arquivo .pfx em uma cadeia de caracteres codificada em base64.
  • Salve a cadeia de caracteres codificada em base64 em um arquivo separado.

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

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

  • 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 com base64 do arquivo .pfx. Use o trecho de código mostrado anteriormente e copie a cadeia de caracteres contida em "exportedcert.pfx.b64". Cole 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, do trecho de código anterior), $certificate.Thumbprint poderá usá-lo como está. Se você copiar o valor da caixa de diálogo Certificado do Windows, lembre-se de remover os espaços estranhos. O certificadoImpressão digital deve ser algo parecido com 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 Gerenciador de Recursos 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 para 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"
    }
  }
}

Depois que o arquivo azuredeploy.parameters.json for preenchido, configure o certificado TLS/SSL padrão usando o trecho de código do PowerShell. Altere os caminhos de arquivo para corresponder onde os arquivos de modelo do Gerenciador de Recursos estão localizados em sua máquina. Lembre-se de fornecer seus próprios valores para o nome de implantação do Gerenciador de Recursos 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

A aplicação da alteração demora cerca de 40 minutos por front-end ASE. Por exemplo, para um ASE de tamanho padrão que usa dois front-ends, o modelo leva cerca de 1 hora e 20 minutos para ser concluído. Enquanto o modelo está em execução, o ASE não pode ser dimensionado.

Após a conclusão do modelo, os aplicativos no ILB ASE podem ser acessados por HTTPS. As conexões são protegidas usando o certificado TLS/SSL padrão. O certificado TLS/SSL padrão é usado quando os aplicativos no ILB ASE são endereçados usando uma combinação do nome do aplicativo mais o nome do 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 executados no serviço multilocatário público, os desenvolvedores podem configurar nomes de host personalizados para aplicativos individuais. Eles também podem configurar ligações de certificado SNI TLS/SSL exclusivas para aplicativos individuais.