Criar um ASE com um modelo do Azure Resource Manager

Descrição Geral

Nota

Este artigo é sobre o App Service Environment v2 e App Service Environment v3 que são usados com planos de Serviço de Aplicações Isolados

Os ambientes do Azure App Service (ASEs) podem ser criados com um ponto final acessível à Internet ou um ponto final num endereço interno numa Rede Virtual Azure. Quando criado com um ponto final interno, este ponto final é fornecido por um componente Azure chamado equilibrador de carga interno (ILB). O ASE num endereço IP interno é chamado de ILB ASE. O ASE com um ponto final público é chamado de ASE Externo.

Um ASE pode ser criado utilizando o portal Azure ou um modelo de Gestor de Recursos Azure. Este artigo percorre os passos e sintaxe que precisa para criar um ASE Externo ou ILB ASE com modelos de Gestor de Recursos. Para aprender a criar um ASEv2 no portal Azure, consulte Fazer um ASE Externo ou Fazer um ASE ILB. Para aprender a criar um ASEv3 no portal Azure, consulte Create ASEv3.

Quando criar um ASE no portal Azure, pode criar a sua rede virtual ao mesmo tempo ou escolher uma rede virtual pré-existente para implementar.

Quando criar um ASE a partir de um modelo, deve começar por:

  • Uma rede virtual Azure.
  • Uma sub-rede naquela rede virtual. Recomendamos um tamanho de sub-rede ASE com /24 256 endereços para acomodar necessidades futuras de crescimento e escala. Depois da criação do ASE, não se pode alterar o tamanho.
  • Ao criar um ASE na rede virtual pré-existente e na sub-rede, é necessário o nome do grupo de recursos existente, o nome da rede virtual e o nome da sub-rede.
  • A subscrição em que pretende implementar.
  • O local onde quer instalar.

Para automatizar a sua criação DEE, siga as diretrizes nas secções abaixo. Se estiver a criar um ILB ASEv2 com dnsS suix personalizado (por exemplo), internal-contoso.comhá mais algumas coisas para fazer.

  1. Após a criação do seu ILB ASE com dnsS suix personalizado, deve ser carregado um certificado TLS/SSL que corresponda ao seu domínio ILB ASE.

  2. O certificado TLS/SSL carregado é atribuído ao ILB ASE como o seu certificado TLS/SSL "predefinido". Este certificado é utilizado para o tráfego TLS/SSL para aplicações no ILB ASE quando utilizam o domínio raiz comum que é atribuído ao ASE (por exemplo, https://someapp.internal-contoso.com).

Criar o ASE

Um modelo de Gestor de Recursos que cria um ficheiro ASE e os seus parâmetros associados está disponível no GitHub para ASEv3 e ASEv2.

Se quiser fazer um ASE, utilize o modelo ASEv3 ou ASEv2 do Gestor de Recursos. Atendem a esse caso de uso. A maioria dos parâmetros no ficheiro azuredeploy.parameters.json são comuns à criação de ASEs ILB e ASEs Externas. A lista a seguir chama parâmetros de nota especial, ou que são únicos, quando se cria um ASE ILB com uma sub-rede existente.

Parâmetros ASEv3

  • nome de ase: Obrigatório. Este parâmetro define um nome ASE único.
  • internaLoadBalancingMode: Necessário. Na maioria dos casos, desa ajuste-o para 3, o que significa tráfego HTTP/HTTPS nas portas 80/443. Se esta propriedade estiver definida para 0, o tráfego HTTP/HTTPS permanece no VIP público.
  • zonaRedundant: Obrigatório. Na maioria dos casos, desloque-o como falso, o que significa que o ASE não será implantado em Zonas de Disponibilidade (AZ). AsES zonais podem ser implantadas em algumas regiões, pode referir-se a isso.
  • dedicadoHostCount: Obrigatório. Na maioria dos casos, desloque-o para 0, o que significa que o ASE será implementado normalmente sem anfitriões dedicados implantados.
  • useExistingVnetandSubnet: Obrigatório. Definir para ser verdadeiro se utilizar uma rede virtual e uma sub-rede existentes.
  • vNetResourceGroupName: Obrigatório se utilizar uma rede virtual e uma sub-rede existentes. Este parâmetro define o nome do grupo de recursos da rede virtual existente e da sub-rede onde a ASE irá residir.
  • virtualNetworkName: Obrigatório se utilizar uma rede virtual e uma sub-rede existentes. Este parâmetro define o nome de rede virtual da rede virtual existente e sub-rede onde a ASE irá residir.
  • sub-nome da rede: Obrigatório se utilizar uma rede virtual e uma sub-rede existentes. Este parâmetro define o nome da rede virtual existente e sub-rede onde a ASE irá residir.
  • createPrivateDNS: set to true if you want to create a private DNS zone after ASEv3 created. Para um ILB ASE, quando definido este parâmetro para verdadeiro, criará uma zona privada de DNS como nome ASE com appserviceenvironment.net sufixo DNS.

Parâmetros ASEv2

  • aseName: Este parâmetro define um nome ASE único.
  • localização: Este parâmetro define a localização do Ambiente de Serviço de Aplicações.
  • Nome de Redevirtual: Este parâmetro define o nome de rede virtual da rede virtual existente e sub-rede onde a ASE irá residir.
  • ExistenteVirtualNetworkResourceGroup: o seu parâmetro define o nome do grupo de recursos da rede virtual existente e da sub-rede onde a ASE irá residir.
  • sub-netName: Este parâmetro define o nome da sub-rede da rede virtual existente e sub-rede onde a ASE irá residir.
  • internaLoadBalancingMode: Na maioria dos casos, desajei-o em 3, o que significa que tanto o tráfego HTTP/HTTPS nas portas 80/443, como as portas de canais de controlo/dados escutadas pelo serviço FTP na ASE, ficarão vinculadas a um endereço interno de rede virtual atribuído pelo ILB. Se esta propriedade estiver definida para 2, apenas as portas relacionadas com o serviço FTP (ambos os canais de controlo e dados) estão ligadas a um endereço ILB. Se esta propriedade estiver definida para 0, o tráfego HTTP/HTTPS permanece no VIP público.
  • dnsS sufixo: Este parâmetro define o domínio padrão da raiz que é atribuído ao ASE. Na variação pública do Azure App Service, o domínio padrão de raiz para todas as aplicações web é azurewebsites.net. Como um ILB ASE é interno na rede virtual de um cliente, não faz sentido usar o domínio de raiz padrão do serviço público. Em vez disso, um ILB ASE deve ter um domínio de raiz padrão que faça sentido para ser usado dentro da rede virtual interna de uma empresa. Por exemplo, a Contoso Corporation poderá utilizar um domínio raiz padrão de internal-contoso.com para apps que se destinam a ser resolvidas e acessíveis apenas dentro da rede virtual da Contoso.
  • ipSslAddressCount: Este parâmetro falha automaticamente num valor de 0 no ficheiro azuredeploy.json porque as ASEs ILB têm apenas um único endereço ILB. Não existem endereços IP-SSL explícitos para um ILB ASE. Por conseguinte, o conjunto de endereços IP-SSL para um ILB ASE deve ser definido para zero. Caso contrário, ocorre um erro de provisionamento.

Depois de preenchido o ficheiro azuredeploy.parameters.json , crie o ASE utilizando o corte de código PowerShell. Altere os caminhos do ficheiro para corresponder às localizações do modelo do Gestor de Recursos na sua máquina. Lembre-se de fornecer os seus próprios valores para o nome de implementação do Gestor 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

Leva cerca de duas horas para a ASE ser criada. Em seguida, o ASE aparece no portal na lista de ASEs para a subscrição que desencadeou a implementação.

Carregar e configurar o certificado TLS/SSL "predefinido"

Um certificado TLS/SSL deve ser associado ao ASE como o certificado TLS/SSL "predefinido" que é utilizado para estabelecer ligações TLS a apps. Se o sufixo DNS padrão da ASE for internal-contoso.com, uma ligação requer https://some-random-app.internal-contoso.com um certificado TLS/SSL válido para *.internal-contoso.com.

Obter um certificado TLS/SSL válido utilizando as autoridades de certificados internos, comprando um certificado a um emitente externo ou utilizando um certificado auto-assinado. Independentemente da origem do certificado TLS/SSL, os seguintes atributos de certificado devem ser devidamente configurados:

  • Objeto: Este atributo deve ser definido como *.your-root-domain-here.com.
  • Nome Alternativo do assunto: Este atributo deve incluir tanto *.your-root-domain-here.com como *.scm.your-root-domain-here.com. As ligações TLS ao site SCM/Kudu associada a cada aplicação utilizam um endereço do formulário your-app-name.scm.your-root-domain-here.com.

Com um certificado TLS/SSL válido na mão, são necessários dois passos preparatórios adicionais. Converter/guardar o certificado TLS/SSL como ficheiro .pfx. Lembre-se que o ficheiro .pfx deve incluir todos os certificados intermédios e de raiz. Proteja-o com uma palavra-passe.

O ficheiro .pfx precisa de ser convertido numa cadeia base64 porque o certificado TLS/SSL é carregado utilizando um modelo de Gestor de Recursos. Como os modelos do Gestor de Recursos são ficheiros de texto, o ficheiro .pfx deve ser convertido numa cadeia base64. Desta forma pode ser incluído como um parâmetro do modelo.

Utilize o seguinte corte de código PowerShell para:

  • Gere um certificado auto-assinado.
  • Exporte o certificado como ficheiro .pfx.
  • Converta o ficheiro .pfx numa cadeia codificada de base64.
  • Guarde a cadeia codificada base64 para um ficheiro separado.

Este código PowerShell para codificação base64 foi adaptado a partir do blog de scripts 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 de o certificado TLS/SSL ser gerado e convertido com sucesso para uma cadeia codificada de base64, utilize o modelo de gestor de recursos de exemplo Configure o certificado SSL predefinido no GitHub.

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

  • appServiceEnvironmentName: O nome do ILB ASE está a ser configurado.
  • Localização existente: Cadeia de texto contendo a região de Azure onde foi implantado o ILB ASE. Por exemplo: "South Central US".
  • pfxBlobString: A representação de cadeia codificada com base em 64 do ficheiro .pfx. Utilize o corte de código mostrado anteriormente e copie a cadeia contida em "exportedcert.pfx.b64". Cole-o como o valor do atributo pfxBlobString .
  • palavra-passe: A palavra-passe utilizada para proteger o ficheiro .pfx.
  • certificaThumbprint: A impressão digital do certificado. Se recuperar este valor da PowerShell (por exemplo, $certificate. Impressão digital do código anterior, pode usar o valor tal como está. Se copiar o valor da caixa de diálogo do certificado Do Windows, lembre-se de retirar os espaços extraérs. O certificadoThumbprint deve parecer-se com AF3143EB61D43F6727842115BB7F17BBCECAEE.
  • certificateName: Um identificador de cordas amigável à sua escolha usado para identificar o certificado. O nome é usado como parte do identificador exclusivo do Gestor de Recursos para a microsoft.Web/certificados que representa o certificado TLS/SSL. O nome deve terminar com o seguinte sufixo: _yourASENameHere_InternalLoadBalancingASE. O portal Azure utiliza este sufixo como um indicador de que o certificado é utilizado para garantir um ASE ativado pelo 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 ficheiro azuredeploy.parameters.json ser preenchido, configurar o certificado TLS/SSL predefinido utilizando o corte de código PowerShell. Altere os caminhos de ficheiro para corresponder onde os ficheiros do modelo do Gestor de Recursos estão localizados na sua máquina. Lembre-se de fornecer os seus próprios valores para o nome de implementação do Gestor 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

Leva cerca de 40 minutos por extremidade frontal ASE para aplicar a mudança. Por exemplo, para um ASE de tamanho predefinido que usa duas extremidades dianteiras, o modelo leva cerca de uma hora e 20 minutos para ser concluído. Enquanto o modelo está em execução, o ASE não consegue escalar.

Após o fim do modelo, as aplicações no ILB ASE podem ser acedidas em HTTPS. As ligações são asseguradas utilizando o certificado TLS/SSL predefinido. O certificado TLS/SSL predefinido é utilizado quando as aplicações no ILB ASE são endereçadas utilizando uma combinação do nome da aplicação mais o nome de anfitrião predefinido. Por exemplo, https://mycustomapp.internal-contoso.com utiliza o certificado TLS/SSL predefinido para *.internal-contoso.com.

No entanto, tal como as aplicações que funcionam no serviço multitenante público, os desenvolvedores podem configurar nomes de anfitriões personalizados para aplicações individuais. Também podem configurar vinculações únicas de certificado SNI TLS/SSL para aplicações individuais.