Een ASE maken met behulp van een Azure Resource Manager-sjabloon

  • Artikel

Overzicht

Belangrijk

Dit artikel gaat over App Service Environment v2 die wordt gebruikt met geïsoleerde App Service-plannen. App Service Environment v2 wordt op 31 augustus 2024 buiten gebruik gesteld. Er is een nieuwe versie van App Service Environment die eenvoudiger te gebruiken is en wordt uitgevoerd op een krachtigere infrastructuur. Voor meer informatie over de nieuwe versie begint u met de inleiding tot de App Service-omgeving. Als u momenteel App Service Environment v2 gebruikt, volgt u de stappen in dit artikel om te migreren naar de nieuwe versie.

Vanaf 29 januari 2024 kunt u vanaf 29 januari 2024 geen nieuwe App Service Environment v2-resources meer maken met behulp van een van de beschikbare methoden, waaronder ARM/Bicep-sjablonen, Azure Portal, Azure CLI of REST API. U moet vóór 31 augustus 2024 migreren naar App Service Environment v3 om te voorkomen dat resources worden verwijderd en gegevens verloren gaan.

Azure-app Service-omgevingen (ASE's) kunnen worden gemaakt met een eindpunt dat toegankelijk is voor internet of een eindpunt op een intern adres in een virtueel Azure-netwerk. Wanneer dit is gemaakt met een intern eindpunt, wordt dat eindpunt geleverd door een Azure-onderdeel dat een interne load balancer (ILB) wordt genoemd. De ASE op een intern IP-adres wordt een ILB AS-omgeving genoemd. De ASE met een openbaar eindpunt wordt een externe ASE genoemd.

Een ASE kan worden gemaakt met behulp van Azure Portal of een Azure Resource Manager-sjabloon. In dit artikel worden de stappen en syntaxis beschreven die u nodig hebt om een externe ASE of ILB ASE te maken met Resource Manager-sjablonen. Zie [Make an External ASE][Make an External ASE] or Make an ILB ASE(Een ILB ASE maken) voor meer informatie over het maken van een ASEv2 in Azure Portal.

Wanneer u een ASE maakt in Azure Portal, kunt u uw virtuele netwerk tegelijkertijd maken of een bestaand virtueel netwerk kiezen waarin u wilt implementeren.

Wanneer u een ASE maakt op basis van een sjabloon, moet u beginnen met:

  • Een virtueel Azure-netwerk.
  • Een subnet in dat virtuele netwerk. We raden een ASE-subnetgrootte van /24 256 adressen aan om tegemoet te komen aan toekomstige groei- en schaalbehoeften. Nadat de ASE is gemaakt, kunt u de grootte niet wijzigen.
  • Het abonnement waarop u wilt implementeren.
  • De locatie waarop u wilt implementeren.

Volg de richtlijnen in de volgende secties om het maken van uw ASE te automatiseren. Als u een ILB ASEv2 maakt met aangepast dnsS-achtervoegsel (bijvoorbeeld internal.contoso.com), zijn er nog enkele dingen die u moet doen.

  1. Nadat uw ILB ASE met aangepast dnsSuffix is gemaakt, moet een TLS/SSL-certificaat dat overeenkomt met uw ILB ASE-domein worden geüpload.

  2. Het geüploade TLS/SSL-certificaat wordt als standaard TLS/SSL-certificaat toegewezen aan de ILB ASE. Dit certificaat wordt gebruikt voor TLS/SSL-verkeer naar apps op de ILB ASE wanneer ze het algemene hoofddomein gebruiken dat is toegewezen aan de ASE (bijvoorbeeld https://someapp.internal.contoso.com).

De ASE maken

Een Resource Manager-sjabloon waarmee een ASE en het bijbehorende parameterbestand worden gemaakt, is beschikbaar op GitHub voor ASEv2.

Als u een ASE wilt maken, gebruikt u dit voorbeeld van de Resource Manager-sjabloon ASEv2 . De meeste parameters in het azuredeploy.parameters.json-bestand zijn gebruikelijk voor het maken van ILB AS-omgevingen en externe AS's. In de volgende lijst worden parameters van speciale opmerking genoemd, of dat is uniek wanneer u een ILB AS-omgeving maakt met een bestaand subnet.

Parameters

  • aseName: deze parameter definieert een unieke ASE-naam.
  • locatie: Deze parameter definieert de locatie van de App Service-omgeving.
  • existingVirtualNetworkName: deze parameter definieert de naam van het virtuele netwerk van het bestaande virtuele netwerk en subnet waarin ASE zich bevindt.
  • existingVirtualNetworkResourceGroup: zijn parameter definieert de naam van de resourcegroep van het bestaande virtuele netwerk en subnet waarin ASE zich bevindt.
  • subnetName: deze parameter definieert de subnetnaam van het bestaande virtuele netwerk en subnet waar ASE zich bevindt.
  • internalLoadBalancingMode: In de meeste gevallen stelt u dit in op 3, wat betekent dat zowel HTTP/HTTPS-verkeer op poort 80/443 als de poorten voor het beheer-/gegevenskanaal die door de FTP-service op de ASE worden geluisterd, gebonden zijn aan een intern adres van een virtueel netwerk dat is toegewezen aan een ILB-toegewezen virtueel netwerk. Als deze eigenschap is ingesteld op 2, zijn alleen de FTP-servicepoorten (zowel besturings- als gegevenskanalen) gebonden aan een ILB-adres. Als deze eigenschap is ingesteld op 0, blijft het HTTP/HTTPS-verkeer op het openbare VIP staan.
  • dnsSuffix: deze parameter definieert het standaardhoofddomein dat is toegewezen aan de ASE. In de openbare variatie van Azure-app Service wordt het standaardhoofddomein voor alle web-apps azurewebsites.net. Omdat een ILB ASE intern is voor het virtuele netwerk van een klant, is het niet logisch 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. Contoso Corporation kan bijvoorbeeld een standaardhoofddomein van internal.contoso.com gebruiken voor apps die zijn bedoeld om te worden omgezet en alleen toegankelijk zijn binnen het virtuele netwerk van Contoso. Als u aangepast hoofddomein wilt opgeven, moet u api-versie 2018-11-01 of eerdere versies gebruiken.
  • 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. Daarom moet de IP-SSL-adresgroep voor een ILB AS-omgeving worden ingesteld op nul. Anders treedt er een inrichtingsfout op.

Nadat het azuredeploy.parameters.json-bestand is ingevuld, maakt u de ASE met behulp van het PowerShell-codefragment. Wijzig de bestandspaden zodat deze overeenkomen met de resourcebeheersjabloon-bestandslocaties op uw computer. Vergeet niet om uw eigen waarden op te geven voor de 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

Het duurt ongeveer twee uur voordat de ASE is gemaakt. Vervolgens wordt de ASE weergegeven in de portal in de lijst met AS's voor het abonnement dat de implementatie heeft geactiveerd.

Het 'standaard'-TLS/SSL-certificaat uploaden en configureren

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

Verkrijg een geldig TLS/SSL-certificaat met behulp van interne certificeringsinstanties, aankoop van een certificaat van een externe verlener of met behulp 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. TLS-verbindingen met de SCM/Kudu-site die aan elke app is gekoppeld, gebruiken een adres van het formulier your-app-name.scm.your-root-domain-here.com.

Met een geldig TLS/SSL-certificaat zijn nog twee voorbereidende stappen nodig. Converteer/sla het TLS/SSL-certificaat op als een PFX-bestand. Houd er rekening mee dat het PFX-bestand alle tussenliggende en basiscertificaten moet bevatten. Beveilig het bestand met een wachtwoord.

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

Gebruik het volgende PowerShell-codefragment om:

  • Genereer een zelfondertekend certificaat.
  • Exporteer het certificaat als een PFX-bestand.
  • Converteer het PFX-bestand naar een met base64 gecodeerde tekenreeks.
  • Sla de met base64 gecodeerde tekenreeks op in een afzonderlijk bestand.

Deze PowerShell-code voor base64-codering is aangepast vanuit de 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")

Nadat het TLS/SSL-certificaat is gegenereerd en geconverteerd naar een met base64 gecodeerde tekenreeks, gebruikt u het voorbeeld van de Resource Manager-sjabloon Het standaard-SSL-certificaat configureren op GitHub.

De parameters in het bestand azuredeploy.parameters.json worden hier 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 tekenreeksweergave met based64-codering van het PFX-bestand. Gebruik het eerder weergegeven codefragment en kopieer de tekenreeks in 'exportedcert.pfx.b64'. Plak deze 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 $certificate.Thumbprint uit het eerdere codefragment), kunt u de waarde als zodanig gebruiken. Als u de waarde uit het dialoogvenster Windows-certificaat kopieert, moet u de overbodige spaties verwijderen. Het certificaatThumbprint moet er ongeveer uitzien als 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 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. Azure Portal gebruikt dit achtervoegsel als indicator dat het certificaat wordt gebruikt voor het beveiligen van een AS-omgeving met ILB-functionaliteit.

Hier 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"
    }
  }
}

Nadat het azuredeploy.parameters.json-bestand is ingevuld, configureert u het standaard TLS/SSL-certificaat met behulp van het PowerShell-codefragment. Wijzig de bestandspaden zodat deze overeenkomen met de locatie van de Resource Manager-sjabloonbestanden op uw computer. Vergeet niet om uw eigen waarden op te geven voor de 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

Het duurt ongeveer 40 minuten per ASE-front-end om de wijziging toe te passen. Voor een as-omgeving met standaardformaat die gebruikmaakt van 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.

Nadat de sjabloon is voltooid, kunnen apps op de ILB ASE worden geopend via HTTPS. De verbindingen worden 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. Gebruikt bijvoorbeeld https://mycustomapp.internal.contoso.com het standaard TLS/SSL-certificaat voor *.internal.contoso.com.

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