Een ILB ASEv1 maken met behulp van Azure Resource Manager-sjablonen

Overzicht

App Service Environments kunnen worden gemaakt met een intern adres van een virtueel netwerk in plaats van een openbaar VIP. Dit interne adres wordt geleverd door een Azure-onderdeel dat de interne load balancer (ILB) wordt genoemd. U kunt een ILB AS-omgeving maken met behulp van Azure Portal. Het kan ook worden gemaakt met behulp van automatisering via Azure Resource Manager-sjablonen. In dit artikel worden de stappen en syntaxis beschreven die nodig zijn voor het maken van een ILB AS-omgeving met Azure Resource Manager-sjablonen.

Er zijn drie stappen betrokken bij het automatiseren van het maken van een ILB AS-omgeving:

1. Eerst wordt de basis-ASE in een virtueel netwerk gemaakt met behulp van een intern load balancer-adres in plaats van een openbaar VIP. Als onderdeel van deze stap wordt een hoofddomeinnaam toegewezen aan de ILB AS-omgeving.
2. Zodra de ILB ASE is gemaakt, wordt een TLS/SSL-certificaat geüpload.
3. Het geüploade TLS/SSL-certificaat wordt expliciet toegewezen aan de ILB ASE als standaard TLS/SSL-certificaat. Dit TLS/SSL-certificaat wordt gebruikt voor TLS-verkeer naar apps op de ILB ASE wanneer de apps worden geadresseerd met behulp van het algemene hoofddomein dat is toegewezen aan de ASE (bijvoorbeeld https://someapp.mycustomrootcomain.com)

De basis-ILB AS-omgeving maken

Hier vindt u een voorbeeld van een Azure Resource Manager-sjabloon en het bijbehorende parameterbestand.

De meeste parameters in het azuredeploy.parameters.json-bestand zijn gebruikelijk voor het maken van zowel ILB AS's als AS's die zijn gebonden aan een openbaar VIP. In de onderstaande lijst worden parameters van speciale opmerking genoemd, of die uniek zijn bij het maken van een ILB AS-omgeving:

• internalLoadBalancingMode: bepaalt hoe controle- en gegevenspoorten beschikbaar worden gesteld.
  • 3 betekent dat zowel HTTP/HTTPS-verkeer op poort 80/443 als de poorten voor het controle-/gegevenskanaal waarnaar door de FTP-service op de ASE wordt geluisterd, gebonden zijn aan een intern ILB-adres van een virtueel netwerk dat is toegewezen.
  • 2 betekent dat alleen de poorten met betrekking tot de FTP-service (zowel besturings- als gegevenskanalen) gebonden zijn aan een ILB-adres, terwijl het HTTP/HTTPS-verkeer op het openbare VIP blijft staan.
  • 0 betekent dat al het verkeer is gebonden aan het openbare VIP dat de ASE extern maakt.
• dnsSuffix: deze parameter definieert het standaardhoofddomein dat wordt toegewezen aan de ASE. In de openbare variatie van Azure-app Service wordt het standaardhoofddomein voor alle web-apps azurewebsites.net. Aangezien een ILB ASE echter intern is voor het virtuele netwerk van een klant, is het niet zinvol om het standaardhoofddomein van de openbare service te gebruiken. In plaats daarvan moet een ILB ASE een standaardhoofddomein hebben dat zinvol is voor gebruik binnen het interne virtuele netwerk van een bedrijf. Een hypothetische Contoso Corporation kan bijvoorbeeld een standaardhoofddomein van internal.contoso.com gebruiken voor apps die alleen kunnen worden omgezet en toegankelijk zijn binnen het virtuele netwerk van Contoso.
• ipSslAddressCount: deze parameter wordt automatisch ingesteld op een waarde van 0 in het azuredeploy.json-bestand , omdat ILB-AS's slechts één ILB-adres hebben. Er zijn geen expliciete IP-SSL-adressen voor een ILB AS-omgeving en daarom moet de IP-SSL-adresgroep voor een ILB AS-omgeving worden ingesteld op nul, anders treedt er een inrichtingsfout op.

Zodra het azuredeploy.parameters.json-bestand is ingevuld voor een ILB ASE, kan de ILB ASE vervolgens worden gemaakt met behulp van het volgende PowerShell-codefragment. Wijzig de bestandspaden zodat deze overeenkomen met waar de Azure Resource Manager-sjabloonbestanden zich op uw computer bevinden. Vergeet ook niet om uw eigen waarden op te geven voor de azure Resource Manager-implementatienaam en de naam van de resourcegroep.

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

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

Nadat de Azure Resource Manager-sjabloon is verzonden, duurt het enkele uren voordat de ILB AS-omgeving is gemaakt. Zodra het maken is voltooid, wordt de ILB ASE weergegeven in de portal-UX in de lijst met App Service Environments voor het abonnement dat de implementatie heeft geactiveerd.

Het STANDAARD-TLS/SSL-certificaat uploaden en configureren

Zodra de ILB ASE is gemaakt, moet er een TLS/SSL-certificaat aan de ASE worden gekoppeld als het 'standaard' TLS/SSL-certificaat dat wordt gebruikt voor het tot stand brengen van TLS/SSL-verbindingen met apps. Als het standaard-DNS-achtervoegsel van de ASE internal.contoso.com is, is voor een verbinding https://some-random-app.internal.contoso.com een TLS/SSL-certificaat vereist dat geldig is voor *.internal.contoso.com.

Er zijn verschillende manieren om een geldig TLS/SSL-certificaat te verkrijgen, waaronder interne CA's, het aanschaffen van een certificaat van een externe verlener en het gebruik van een zelfondertekend certificaat. Ongeacht de bron van het TLS/SSL-certificaat moeten de volgende certificaatkenmerken correct worden geconfigureerd:

• Onderwerp: Dit kenmerk moet worden ingesteld op *.your-root-domain-here.com
• Alternatieve onderwerpnaam: dit kenmerk moet zowel *.your-root-domain-here.com als *.scm.your-root-domain-here.com bevatten. De reden voor de tweede vermelding is dat TLS-verbindingen met de SCM/Kudu-site die aan elke app is gekoppeld, worden gemaakt met behulp van een adres van het formulier your-app-name.scm.your-root-domain-here.com.

Met een geldig TLS/SSL-certificaat zijn twee aanvullende voorbereidende stappen nodig. Het TLS/SSL-certificaat moet worden geconverteerd/opgeslagen als een PFX-bestand. Houd er rekening mee dat het PFX-bestand alle tussenliggende en basiscertificaten moet bevatten en ook moet worden beveiligd met een wachtwoord.

Vervolgens moet het resulterende PFX-bestand worden geconverteerd naar een base64-tekenreeks, omdat het TLS/SSL-certificaat wordt geüpload met behulp van een Azure Resource Manager-sjabloon. Omdat Azure Resource Manager-sjablonen tekstbestanden zijn, moet het PFX-bestand worden geconverteerd naar een base64-tekenreeks, zodat het kan worden opgenomen als een parameter van de sjabloon.

In het onderstaande PowerShell-codefragment ziet u een voorbeeld van het genereren van een zelfondertekend certificaat, het exporteren van het certificaat als een PFX-bestand, het converteren van het PFX-bestand naar een met base64 gecodeerde tekenreeks en het opslaan van de base64-gecodeerde tekenreeks naar een afzonderlijk bestand. De PowerShell-code voor base64-codering is aangepast vanuit het PowerShell-scriptsblog.

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

Zodra het TLS/SSL-certificaat is gegenereerd en geconverteerd naar een met base64 gecodeerde tekenreeks, kan het Azure Resource Manager-voorbeeldsjabloon voor het configureren van het standaard TLS/SSL-certificaat worden gebruikt.

De parameters in het bestand azuredeploy.parameters.json worden hieronder vermeld:

• appServiceEnvironmentName: de naam van de ILB AS-omgeving die wordt geconfigureerd.
• existingAseLocation: Tekenreeks met de Azure-regio waar de ILB ASE is geïmplementeerd. Bijvoorbeeld: 'VS - zuid-centraal'.
• pfxBlobString: De gecodeerde tekenreeksweergave op basis van 64 van het PFX-bestand. Met behulp van het eerder weergegeven codefragment kopieert u de tekenreeks in 'exportedcert.pfx.b64' en plakt u het in als de waarde van het kenmerk pfxBlobString .
• wachtwoord: het wachtwoord dat wordt gebruikt om het PFX-bestand te beveiligen.
• certificateThumbprint: de vingerafdruk van het certificaat. Als u deze waarde ophaalt uit PowerShell (bijvoorbeeld $certThumbprint uit het eerdere codefragment), kunt u de waarde als zodanig gebruiken. Als u echter de waarde uit het dialoogvenster Windows-certificaat kopieert, moet u de overbodige spaties verwijderen. Het certificaatThumbprint moet er ongeveer als volgt uitzien: AF3143EB61D43F6727842115BB7F17BBCECAECAE
• certificateName: een beschrijvende tekenreeks-id van uw eigen keuze die wordt gebruikt om het certificaat te identificeren. De naam wordt gebruikt als onderdeel van de unieke Azure Resource Manager-id voor de entiteit Microsoft.Web/certificates die het TLS/SSL-certificaat vertegenwoordigt. De naam moet eindigen met het volgende achtervoegsel: _yourASENameHere_InternalLoadBalancingASE. Dit achtervoegsel wordt door de portal gebruikt als indicator dat het certificaat wordt gebruikt voor het beveiligen van een AS-omgeving met ILB-functionaliteit.

Hieronder ziet u een verkort voorbeeld van 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"
        }
    }
}

Zodra het azuredeploy.parameters.json-bestand is ingevuld, kan het standaard TLS/SSL-certificaat worden geconfigureerd met behulp van het volgende PowerShell-codefragment. Wijzig de bestandspaden zodat deze overeenkomen met waar de Azure Resource Manager-sjabloonbestanden zich op uw computer bevinden. Vergeet ook niet om uw eigen waarden op te geven voor de azure Resource Manager-implementatienaam en de naam van de resourcegroep.

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

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

Nadat de Azure Resource Manager-sjabloon is verzonden, duurt het ongeveer 40 minuten per ASE-front-end om de wijziging toe te passen. Met een standaard as-omgeving met twee front-ends duurt het ongeveer 1 uur en 20 minuten voordat de sjabloon is voltooid. Terwijl de sjabloon wordt uitgevoerd, kan de ASE niet worden geschaald.

Zodra de sjabloon is voltooid, kunnen apps op de ILB ASE worden geopend via HTTPS en worden de verbindingen beveiligd met behulp van het standaard TLS/SSL-certificaat. Het standaard TLS/SSL-certificaat wordt gebruikt wanneer apps op de ILB ASE worden geadresseerd met behulp van een combinatie van de toepassingsnaam plus de standaardhostnaam. Gebruik bijvoorbeeld https://mycustomapp.internal.contoso.com het standaard TLS/SSL-certificaat voor *.internal.contoso.com.

Net als apps die worden uitgevoerd in de openbare multitenantservice, kunnen ontwikkelaars echter ook aangepaste hostnamen configureren voor afzonderlijke apps en vervolgens unieke SNI TLS/SSL-certificaatbindingen configureren voor afzonderlijke apps.

Aan de slag

Zie Inleiding tot App Service Environment om aan de slag te gaan met App Service Environment