Dela via

Skapa en ASE med hjälp av en Azure Resource Manager-mall

  • Artikel

Översikt

Viktigt!

Den här artikeln handlar om App Service-miljön v2, som används med isolerade App Service-planer. App Service-miljön v1 och v2 dras tillbaka från och med den 31 augusti 2024. Det finns en ny version av App Service-miljön som är enklare att använda och köra på kraftfullare infrastruktur. Om du vill veta mer om den nya versionen börjar du med Introduktion till App Service-miljön. Om du för närvarande använder App Service-miljön v1 följer du stegen i den här artikeln för att migrera till den nya versionen.

Från och med den 31 augusti 2024 gäller serviceavtal (SLA) och tjänstkrediter inte längre för App Service-miljön v1- och v2-arbetsbelastningar som fortsätter att vara i produktion eftersom de är tillbakadragna produkter. Avvecklingen av maskinvaran App Service-miljön v1 och v2 har påbörjats, vilket kan påverka tillgängligheten och prestandan för dina appar och data.

Du måste slutföra migreringen till App Service-miljön v3 omedelbart eller så kan dina appar och resurser tas bort. Vi försöker automatiskt migrera eventuella återstående App Service-miljön v1 och v2 på bästa sätt med hjälp av migreringsfunktionen på plats, men Microsoft gör inga anspråk eller garantier om programtillgänglighet efter automatisk migrering. Du kan behöva utföra manuell konfiguration för att slutföra migreringen och optimera ditt SKU-val för App Service-plan för att uppfylla dina behov. Om automatisk migrering inte är möjlig tas dina resurser och associerade appdata bort. Vi uppmanar dig starkt att agera nu för att undvika något av dessa extrema scenarier.

Om du behöver ytterligare tid kan vi erbjuda en respitperiod på 30 dagar för att slutföra migreringen. Mer information och för att begära den här respitperioden finns i översikten över respitperioden och gå sedan till Azure Portal och gå till migreringsbladet för var och en av dina App Service-miljön.

Den senaste informationen om App Service-miljön v1/v2-tillbakadragning finns i App Service-miljön v1- och v2-pensionsuppdateringen.

Azure App Service-miljöer (ASE) kan skapas med en internettillgänglig slutpunkt eller en slutpunkt på en intern adress i ett virtuellt Azure-nätverk. När den skapas med en intern slutpunkt tillhandahålls slutpunkten av en Azure-komponent som kallas intern lastbalanserare (ILB). ASE på en intern IP-adress kallas för en ILB ASE. ASE med en offentlig slutpunkt kallas för extern ASE.

En ASE kan skapas med hjälp av Azure Portal eller en Azure Resource Manager-mall. Den här artikeln går igenom de steg och syntax du behöver för att skapa en extern ASE- eller ILB ASE med Resource Manager-mallar. Information om hur du skapar en ASEv2 i Azure Portal finns i [Skapa en extern ASE][MakeExternalASE] eller Skapa en ILB ASE.

När du skapar en ASE i Azure Portal kan du skapa ditt virtuella nätverk samtidigt eller välja ett befintligt virtuellt nätverk att distribuera till.

När du skapar en ASE från en mall måste du börja med:

  • Ett virtuellt Azure-nätverk.
  • Ett undernät i det virtuella nätverket. Vi rekommenderar en ASE-undernätsstorlek på /24 med 256 adresser för framtida tillväxt- och skalningsbehov. När ASE har skapats kan du inte ändra storleken.
  • Den prenumeration som du vill distribuera till.
  • Den plats som du vill distribuera till.

Följ riktlinjerna i följande avsnitt för att automatisera skapandet av ASE. Om du skapar en ILB ASEv2 med anpassat dnsSuffix (till exempel internal.contoso.com), finns det några saker att göra.

  1. När din ILB ASE med anpassat dnsSuffix har skapats ska ett TLS/SSL-certifikat som matchar din ILB ASE-domän laddas upp.

  2. Det uppladdade TLS/SSL-certifikatet tilldelas till ILB ASE som sitt "standard" TLS/SSL-certifikat. Det här certifikatet används för TLS/SSL-trafik till appar på ILB ASE när de använder den vanliga rotdomänen som har tilldelats TILL ASE (till exempel https://someapp.internal.contoso.com).

Skapa ASE

En Resource Manager-mall som skapar en ASE och dess associerade parameterfil finns på GitHub för ASEv2.

Om du vill skapa en ASE använder du det här Resource Manager-mallexemplet ASEv2 . De flesta parametrarna i filen azuredeploy.parameters.json är gemensamma för skapandet av ILB ASE:er och externa ASE:er. I följande lista visas parametrar för särskild anteckning, eller som är unika, när du skapar en ILB ASE med ett befintligt undernät.

Parametrar

  • aseName: Den här parametern definierar ett unikt ASE-namn.
  • plats: Den här parametern definierar platsen för App Service-miljön.
  • existingVirtualNetworkName: Den här parametern definierar namnet på det virtuella nätverket för det befintliga virtuella nätverket och undernätet där ASE ska finnas.
  • existingVirtualNetworkResourceGroup: parametern definierar resursgruppens namn på det befintliga virtuella nätverket och undernätet där ASE ska finnas.
  • subnetName: Den här parametern definierar undernätsnamnet för det befintliga virtuella nätverket och undernätet där ASE ska finnas.
  • internalLoadBalancingMode: I de flesta fall anger du detta till 3, vilket innebär att både HTTP/HTTPS-trafik på portarna 80/443 och de kontroll-/datakanalportar som lyssnas på av FTP-tjänsten i ASE är bundna till en intern ILB-allokerad intern adress för virtuellt nätverk. Om den här egenskapen är inställd på 2 är endast FTP-tjänstrelaterade portar (både kontroll- och datakanaler) bundna till en ILB-adress. Om den här egenskapen är inställd på 0 förblir HTTP/HTTPS-trafiken på den offentliga VIP:en.
  • dnsSuffix: Den här parametern definierar standardrotdomänen som är tilldelad till ASE. I den offentliga varianten av Azure App Service är standardrotdomänen för alla webbappar azurewebsites.net. Eftersom en ILB ASE är intern för en kunds virtuella nätverk är det inte meningsfullt att använda den offentliga tjänstens standardrotdomän. I stället bör en ILB ASE ha en standardrotdomän som är lämplig för användning i ett företags interna virtuella nätverk. Contoso Corporation kan till exempel använda en standardrotdomän för internal.contoso.com för appar som är avsedda att vara matchbara och endast tillgängliga i Contosos virtuella nätverk. Om du vill ange en anpassad rotdomän måste du använda api-versionen 2018-11-01 eller tidigare versioner.
  • ipSslAddressCount: Den här parametern har automatiskt värdet 0 i filen azuredeploy.json eftersom ILB ASEs bara har en enda ILB-adress. Det finns inga explicita IP-SSL-adresser för en ILB ASE. Ip-SSL-adresspoolen för en ILB ASE måste därför vara inställd på noll. Annars uppstår ett etableringsfel.

När azuredeploy.parameters.json filen har fyllts i skapar du ASE med hjälp av PowerShell-kodfragmentet. Ändra filsökvägarna så att de matchar resource manager-mallfilplatserna på datorn. Kom ihåg att ange dina egna värden för Resource Manager-distributionsnamnet och resursgruppens namn:

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

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

Det tar ungefär två timmar innan ASE skapas. Sedan visas ASE i portalen i listan över ASE:er för prenumerationen som utlöste distributionen.

Ladda upp och konfigurera TLS/SSL-standardcertifikatet

Ett TLS/SSL-certifikat måste associeras med ASE som det "standard" TLS/SSL-certifikat som används för att upprätta TLS-anslutningar till appar. Om ASE:s standard-DNS-suffix är internal.contoso.com kräver en anslutning till https://some-random-app.internal.contoso.com ett TLS/SSL-certifikat som är giltigt för *.internal.contoso.com.

Skaffa ett giltigt TLS/SSL-certifikat genom att använda interna certifikatutfärdare, köpa ett certifikat från en extern utfärdare eller använda ett självsignerat certifikat. Oavsett källan till TLS/SSL-certifikatet måste följande certifikatattribut konfigureras korrekt:

  • Ämne: Det här attributet måste anges till *.your-root-domain-here.com.
  • Alternativt namn på ämne: Det här attributet måste innehålla både .your-root-domain-here.com och*.scm.your-root-domain-here.com*. TLS-anslutningar till SCM/Kudu-webbplatsen som är associerad med varje app använder en adress för formuläret your-app-name.scm.your-root-domain-here.com.

Med ett giltigt TLS/SSL-certifikat behövs ytterligare två förberedande steg. Konvertera/spara TLS/SSL-certifikatet som en .pfx-fil. Kom ihåg att PFX-filen måste innehålla alla mellanliggande certifikat och rotcertifikat. Skydda den med ett lösenord.

Pfx-filen måste konverteras till en base64-sträng eftersom TLS/SSL-certifikatet laddas upp med hjälp av en Resource Manager-mall. Eftersom Resource Manager-mallar är textfiler måste .pfx-filen konverteras till en base64-sträng. På så sätt kan den inkluderas som en parameter för mallen.

Använd följande PowerShell-kodfragment för att:

  • Skapa ett självsignerat certifikat.
  • Exportera certifikatet som en .pfx-fil.
  • Konvertera PFX-filen till en base64-kodad sträng.
  • Spara den base64-kodade strängen i en separat fil.

Den här PowerShell-koden för base64-kodning har anpassats från PowerShell-skriptbloggen:

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

När TLS/SSL-certifikatet har genererats och konverterats till en base64-kodad sträng använder du exempelmallen Resource Manager Konfigurera standard-SSL-certifikatet på GitHub.

Parametrarna i azuredeploy.parameters.json-filen visas här:

  • appServiceEnvironmentName: Namnet på den ILB ASE som konfigureras.
  • existingAseLocation: Textsträng som innehåller Azure-regionen där ILB ASE distribuerades. Exempel: "USA, södra centrala".
  • pfxBlobString: Den based64-kodade strängrepresentationen av .pfx-filen. Använd kodfragmentet som visades tidigare och kopiera strängen i "exportedcert.pfx.b64". Klistra in det som värdet för pfxBlobString-attributet .
  • lösenord: Lösenordet som används för att skydda .pfx-filen.
  • certificateThumbprint: Certifikatets tumavtryck. Om du hämtar det här värdet från PowerShell (till exempel $certificate.Thumbprint från det tidigare kodfragmentet) kan du använda värdet som det är. Om du kopierar värdet från dialogrutan Windows-certifikat ska du komma ihåg att ta bort de överflödiga blankstegen. CertifikatetThumbprint bör se ut ungefär som AF3143EB61D43F6727842115BB7F17BBCECAECAE.
  • certificateName: En egen egen strängidentifierare som används för att identifiera certifikatet. Namnet används som en del av den unika Resource Manager-identifieraren för entiteten Microsoft.Web/certificates som representerar TLS/SSL-certifikatet. Namnet måste sluta med följande suffix: _yourASENameHere_InternalLoadBalancingASE. Azure Portal använder det här suffixet som en indikator på att certifikatet används för att skydda en ILB-aktiverad ASE.

Ett förkortat exempel på azuredeploy.parameters.json visas här:

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

När azuredeploy.parameters.json filen har fyllts i konfigurerar du standardcertifikatet för TLS/SSL med hjälp av PowerShell-kodfragmentet. Ändra filsökvägarna så att de matchar var Resource Manager-mallfilerna finns på datorn. Kom ihåg att ange dina egna värden för Resource Manager-distributionsnamnet och resursgruppens namn:

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

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

Det tar ungefär 40 minuter per ASE-klientdel att tillämpa ändringen. För en ASE i standardstorlek som använder två klientdelar tar mallen cirka 1 timme och 20 minuter att slutföra. När mallen körs kan ASE inte skalas.

När mallen är klar kan appar på ILB ASE nås via HTTPS. Anslutningarna skyddas med hjälp av standard-TLS/SSL-certifikatet. Standardcertifikatet för TLS/SSL används när appar i ILB ASE hanteras med hjälp av en kombination av programnamnet plus standardvärdens namn. Till exempel https://mycustomapp.internal.contoso.com använder standard-TLS/SSL-certifikatet för *.internal.contoso.com.

Men precis som appar som körs på den offentliga multitenanttjänsten kan utvecklare konfigurera anpassade värdnamn för enskilda appar. De kan också konfigurera unika SNI TLS/SSL-certifikatbindningar för enskilda appar.