Compartir a través de

Creación de una instancia de ASEv1 de ILB mediante plantillas de Azure Resource Manager

  • Artículo

Importante

Este artículo trata sobre App Service Environment v1. App Service Environment v1 y v2 se retiran a partir del 31 de agosto de 2024. Hay una nueva versión de App Service Environment que resulta más fácil de usar y se ejecuta en una infraestructura más eficaz. Para aprender más sobre la nueva versión, empiece por consultar la Introducción a App Service Environment. Si actualmente usa App Service Environment v1, siga los pasos descritos en este artículo para migrar a la nueva versión.

A partir del 31 de agosto de 2024, el Acuerdo de Nivel de Servicio (SLA) y los créditos de servicio ya no se aplican a las cargas de trabajo de App Service Environment v1 y v2 que siguen en producción, ya que son productos retirados. Se ha iniciado la retirada del hardware de App Service Environment v1 y v2, lo que puede afectar a la disponibilidad y el rendimiento de las aplicaciones y los datos.

Debe completar la migración a App Service Environment v3 inmediatamente o las aplicaciones y los recursos podrían ser eliminados. Intentaremos migrar automáticamente cualquier instancia restante de App Service Environment v1 y v2 en la medida de lo posible mediante la característica de migración local, pero Microsoft no ofrece ninguna garantía sobre la disponibilidad de la aplicación después de la migración automática. Es posible que tenga que realizar la configuración manual para completar la migración y optimizar la opción de SKU del plan de App Service para satisfacer sus necesidades. Si la migración automática no es factible, se eliminarán los recursos y los datos de la aplicación asociados. Le instamos encarecidamente a que actúe ahora para evitar cualquiera de estos escenarios extremos.

Si necesita más tiempo, podemos ofrecerle un único periodo de gracia de 30 días para que complete la migración. Para obtener más información y solicitar este período de gracia, revise la información general del período de gracia y, a continuación, vaya a Azure Portal y visite la hoja Migración para cada uno de los entornos de App Service.

Para obtener la información más actualizada sobre la retirada de App Service Environment v1/v2, consulte la Actualización de retirada de App Service Environment v1 y v2.

Información general

Los entornos de App Service pueden crearse con una dirección de red virtual interna, en lugar de una VIP pública. Esta dirección interna la proporciona un componente de Azure denominado equilibrador de carga interno (ILB). Un ASE del ILB se puede crear con el Portal de Azure. También se puede crear de forma automática por medio de las plantillas de Azure Resource Manager. Este artículo le guía por los pasos y la sintaxis necesarios para crear un ASE de ILB con plantillas de Azure Resource Manager.

Hay tres pasos implicados en la automatización de la creación de un ASE de ILB:

  1. En primer lugar, el ASE base se crea en una red virtual con una dirección de equilibrador de carga interno, en lugar de una VIP pública. Como parte de este paso, se asigna un nombre de dominio raíz al ASE de ILB.
  2. Una vez creado el ASE de ILB, se carga un certificado TLS/SSL.
  3. El certificado TLS/SSL cargado se asigna explícitamente al ASE con ILB como certificado TLS/SSL "predeterminado". Este certificado TLS/SSL se usará con el tráfico TLS a las aplicaciones de ASE de ILB cuando estas se direccionen mediante el dominio raíz común asignado al ASE (por ejemplo, https://someapp.mycustomrootcomain.com).

Creación del ASE de ILB base

Puede encontrar un ejemplo de plantilla de Azure Resource Manager y su archivo de parámetros asociado aquí.

La mayoría de los parámetros del archivo azuredeploy.parameters.json son comunes a la creación de los ASE de ILB y los ASE enlazados a una IP virtual pública. La lista siguiente llama a los parámetros especiales o únicos al crear un ASE de ILB:

  • internalLoadBalancingMode: determina cómo se exponen los puertos de datos y de control.
    • 3 significa que tanto el tráfico HTTP/HTTPS de los puertos 80 y 443 como el de los puertos de los canales de control o de datos a los que escucha el servicio FTP en el ASE estarán enlazados a una dirección interna de red virtual asignada al ILB.
    • 2 significa que solo los puertos relacionados con el servicio FTP (los canales de control y de datos) estarán enlazados a una dirección de ILB, mientras que el tráfico HTTP/HTTPS permanecerá en la IP virtual pública.
    • 0 significa que todo el tráfico está enlazado a la dirección IP virtual pública, lo que hace que el ASE sea externo.
  • dnsSuffix: este parámetro define el dominio raíz predeterminado que se asignará al ASE. En la variación pública de Azure App Service, el dominio raíz predeterminado de todas las aplicaciones web es azurewebsites.net. Sin embargo, dado que un ASE de ILB está dentro de la red virtual de un cliente, no tiene sentido utilizar el dominio raíz predeterminado del servicio público. En su lugar, un ASE de ILB debe tener un dominio raíz predeterminado que tenga sentido usar en la red virtual interna de una compañía. Por ejemplo, una empresa hipotética, Contoso Corporation, puede usar el dominio raíz predeterminado internal.contoso.com para las aplicaciones diseñadas para que se resuelvan solo en la red virtual de Contoso, y a las que se pueda acceder solo desde ella.
  • ipSslAddressCount: automáticamente, el valor predeterminado de este parámetro es 0 en el archivo azuredeploy.json, ya que los ASE de ILB solo tienen una dirección de ILB individual. No hay direcciones IP-SSL explícitas para un ASE de ILB y, por consiguiente, el grupo de direcciones IP-SSL de un ASE de ILB debe establecerse en cero, ya que, de lo contrario, se producirá un error de aprovisionamiento.

Una vez que se haya rellenado el archivo azuredeploy.parameters.json de un ASE de ILB, este se puede crear mediante el siguiente fragmento de código de PowerShell. Cambie las rutas de acceso de archivo para que coincidan con los archivos de plantilla de Azure Resource Manager del equipo. Recuerde también especificar sus propios valores para el nombre de implementación y el nombre del grupo de recursos de Azure Resource Manager.

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

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

Después que se envíe la plantilla de Azure Resource Manager el ASE de ILB tardará unas horas en crearse. Una vez completada la creación, el ASE de ILB se mostrará en el portal, en la lista de entornos de App Service de la suscripción que desencadenó la implementación.

Carga y configuración del certificado TLS/SSL "predeterminado"

Una vez que se crea el ASE de ILB, es preciso asociarle un certificado TLS/SSL "predeterminado" que se use para establecer conexiones TLS/SSL con las aplicaciones. Continuando con el ejemplo hipotético de Contoso Corporation, si el sufijo DNS predeterminado del ASE es internal.contoso.com, una conexión a https://some-random-app.internal.contoso.com requiere un certificado TLS/SSL que sea válido para *.internal.contoso.com.

Hay diferentes maneras de obtener un certificado TLS/SSL válido, entre las que se incluyen las CA internas, la adquisición de un certificado de un emisor externo y el uso de un certificado autofirmado. Independientemente del origen del certificado TLS/SSL, es preciso configurar correctamente los siguientes atributos del certificado:

  • Subject: el valor de este atributo debe ser *.your-root-domain-here.com.
  • Nombre alternativo del firmante: este atributo debe incluir .your-root-domain-here.com y *.scm.your-root-domain-here.com*. El motivo de la segunda entrada es que las conexiones TLS con el sitio de SCM/Kudu asociadas a cada aplicación se realizarán mediante una dirección, cuyo formato será your-app-name.scm.your-root-domain-here.com.

Con un certificado TLS/SSL válido, se necesitan dos pasos preparatorios adicionales. El certificado TLS/SSL se debe guardar en formato .pfx, o bien convertirse a dicho formato. Recuerde que es preciso que el archivo .pfx incluya todos los certificados raíz e intermedios, y también debe protegerse con una contraseña.

A continuación, el archivo .pfx resultante debe convertirse en una cadena base64, ya que el certificado TLS/SSL se cargará mediante una plantilla de Azure Resource Manager. Dado que las plantillas de Azure Resource Manager son archivos de texto, el archivo .pfx debe convertirse en una cadena base64 para que puede incluirse como parámetro de la plantilla.

En el fragmento de código de PowerShell siguiente se muestra un ejemplo de cómo generar un certificado autofirmado, exportarlo como un archivo .pfx, convertir el archivo .pfx en una cadena codificada en base64 y, después, guardarla en otro archivo. El código de PowerShell para la codificación en base64 se ha adaptado del blog PowerShell Scripts.

$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")

Una vez que el certificado TLS/SSL se ha generado y convertido correctamente en una cadena con codificación en base64, se puede usar la plantilla de Azure Resource Manager de ejemplo para configurar el certificado TLS/SSL predeterminado.

Los parámetros del archivo azuredeploy.parameters.json se enumeran a continuación:

  • appServiceEnvironmentName: el nombre del ASE de ILB que se configura.
  • existingAseLocation: cadena de texto que contiene la región de Azure en que se implementó el ASE de ILB. Por ejemplo: "Centro-sur de EE. UU."
  • pfxBlobString: la representación de la cadena base64 codificada del archivo pfx. Mediante el fragmento de código que se ha mostrado anteriormente, se copiaría la cadena de "exportedcert.pfx.b64" y se pegaría como el valor del atributo pfxBlobString .
  • password: la contraseña que se usa para proteger el archivo pfx.
  • certificateThumbprint: la huella digital del certificado. Si este valor se recupera de PowerShell (por ejemplo, $certThumbprint del fragmento de código anterior), se puede usar tal cual. Sin embargo, si copia el valor del cuadro de diálogo del certificado de Windows, no olvide eliminar los espacios superfluos. certificateThumbprint debería ser similar a: AF3143EB61D43F6727842115BB7F17BBCECAECAE
  • certificateName: es el identificador de cadena fácil de usar que elija y que se usa para identificar el certificado. El nombre se utiliza como parte del identificador único de Azure Resource Manager para la entidad Microsoft.Web/certificates que representa el certificado TLS/SSL. El nombre debe terminar con el sufijo siguiente: _yourASENameHere_InternalLoadBalancingASE. El portal utiliza este sufijo como un indicador de que el certificado se usa para asegurar un ASE habilitado para ILB.

A continuación se muestra un ejemplo abreviado de azuredeploy.parameters.json :

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

Una vez que se ha rellenado el archivo azuredeploy.parameters.json, se puede configurar el certificado TLS/SSL predeterminado mediante el fragmento de código de PowerShell siguiente. Cambie las rutas de acceso de archivo para que coincidan con los archivos de plantilla de Azure Resource Manager del equipo. Recuerde también especificar sus propios valores para el nombre de implementación y el nombre del grupo de recursos de Azure Resource Manager.

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

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

Una vez que se envía la plantilla de Azure Resource Manager, se tarda unos 40 minutos en aplicar el cambio por cada front-end de ASE. Por ejemplo, con un ASE de un tamaño predeterminado que usa dos front-ends, la plantilla tardará aproximadamente una hora y veinte minutos en completarse. Mientras la plantilla ejecute el ASE no se podrá escalar.

Una vez que se completa la plantilla, se puede acceder a las aplicaciones del ASE de ILB a través de HTTPS y las conexiones se protegerán mediante el certificado TLS/SSL predeterminado. El certificado TLS/SSL predeterminado se usará cuando las direcciones de las aplicaciones del ASE de ILB sean una combinación del nombre de la aplicación y el nombre de host predeterminado. Por ejemplo, https://mycustomapp.internal.contoso.com usaría el certificado TLS/SSL predeterminado para *.internal.contoso.com.

Sin embargo, al igual que las aplicaciones que se ejecutan en el servicio multiinquilino público, los desarrolladores también pueden configurar nombres de host personalizados para las aplicaciones individuales y luego configurar enlaces de certificados TLS/SSL SNI únicos para aplicaciones individuales.

Introducción

Para empezar a trabajar con los entornos de App Service, consulte Introducción al entorno de App Service

Nota

Si desea empezar a trabajar con Azure App Service antes de inscribirse para abrir una cuenta de Azure, vaya a Prueba de App Service, donde podrá crear inmediatamente una aplicación web de inicio de corta duración en App Service. No es necesario proporcionar ninguna tarjeta de crédito ni asumir ningún compromiso.