Dela via

Skapa en ILB ASEv1 med Hjälp av Azure Resource Manager-mallar

  • Artikel

Viktigt!

Den här artikeln handlar om App Service-miljön v1. 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.

Översikt

App Service-miljön kan skapas med en intern adress för virtuellt nätverk i stället för en offentlig VIP. Den här interna adressen tillhandahålls av en Azure-komponent som kallas intern lastbalanserare (ILB). En ILB ASE kan skapas med hjälp av Azure Portal. Den kan också skapas med hjälp av automatisering via Azure Resource Manager-mallar. Den här artikeln går igenom de steg och syntax som krävs för att skapa en ILB ASE med Azure Resource Manager-mallar.

Det finns tre steg för att automatisera skapandet av en ILB ASE:

  1. Först skapas bas-ASE i ett virtuellt nätverk med hjälp av en intern lastbalanserares adress i stället för en offentlig VIP. Som en del av det här steget tilldelas ett rotdomännamn till ILB ASE.
  2. När ILB ASE har skapats laddas ett TLS/SSL-certifikat upp.
  3. Det uppladdade TLS/SSL-certifikatet tilldelas uttryckligen till ILB ASE som sitt "standard" TLS/SSL-certifikat. Det här TLS/SSL-certifikatet används för TLS-trafik till appar i ILB ASE när apparna adresseras med hjälp av den vanliga rotdomänen som tilldelats TILL ASE (till exempel https://someapp.mycustomrootcomain.com)

Skapa bas-ILB ASE

Ett exempel på en Azure Resource Manager-mall och dess associerade parameterfil finns här.

De flesta parametrarna i filen azuredeploy.parameters.json är gemensamma för att skapa både ILB ASE:er och ASE:er som är bundna till en offentlig VIP. Listan nedan visar parametrar för särskild anteckning, eller som är unika, när du skapar en ILB ASE:

  • internalLoadBalancingMode: Avgör hur kontroll- och dataportar exponeras.
    • 3 innebär att både HTTP/HTTPS-trafik på portarna 80/443 och de kontroll-/datakanalportar som ftp-tjänsten lyssnar på i ASE kommer att vara bundna till en intern adress för ILB-allokerat virtuellt nätverk.
    • 2 innebär att endast FTP-tjänstrelaterade portar (både kontroll- och datakanaler) kommer att bindas till en ILB-adress, medan HTTP/HTTPS-trafiken förblir på den offentliga VIP-adressen.
    • 0 innebär att all trafik är bunden till den offentliga VIP som gör ASE externt.
  • dnsSuffix: Den här parametern definierar standardrotdomänen som ska tilldelas till ASE. I den offentliga varianten av Azure App Service är standardrotdomänen för alla webbappar azurewebsites.net. Men 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. Ett hypotetiskt Contoso Corporation kan till exempel använda en standardrotdomän för internal.contoso.com för appar som endast är avsedda att matchas och vara tillgängliga i Contosos virtuella nätverk.
  • ipSslAddressCount: Den här parametern är automatiskt standardvä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, så IP-SSL-adresspoolen för en ILB ASE måste vara inställd på noll, annars uppstår ett etableringsfel.

När azuredeploy.parameters.json filen har fyllts i för en ILB ASE kan ILB ASE sedan skapas med hjälp av följande PowerShell-kodfragment. Ändra filsökvägarna så att de matchar var Azure Resource Manager-mallfilerna finns på datorn. Kom också ihåg att ange dina egna värden för Azure 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

När Azure Resource Manager-mallen har skickats tar det några timmar innan ILB ASE skapas. När skapandet är klart visas ILB ASE i portalens UX i listan över App Service-miljön för prenumerationen som utlöste distributionen.

Ladda upp och konfigurera TLS/SSL-standardcertifikatet

När ILB ASE har skapats ska ett TLS/SSL-certifikat associeras med ASE som "standard" TLS/SSL-certifikatanvändning för att upprätta TLS/SSL-anslutningar till appar. Om du fortsätter med det hypotetiska Contoso Corporation-exemplet, 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.

Det finns olika sätt att hämta ett giltigt TLS/SSL-certifikat, inklusive interna certifikatutfärdare, inköp av ett certifikat från en extern utfärdare och användning av 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*. Anledningen till den andra posten är att TLS-anslutningar till SCM/Kudu-webbplatsen som är associerad med varje app görs med hjälp av 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. TLS/SSL-certifikatet måste konverteras/sparas som en .pfx-fil. Kom ihåg att .pfx-filen måste innehålla alla mellanliggande certifikat och rotcertifikat och även måste skyddas med ett lösenord.

Sedan måste den resulterande .pfx-filen konverteras till en base64-sträng eftersom TLS/SSL-certifikatet laddas upp med en Azure Resource Manager-mall. Eftersom Azure Resource Manager-mallar är textfiler måste .pfx-filen konverteras till en base64-sträng så att den kan inkluderas som en parameter för mallen.

PowerShell-kodfragmentet nedan visar ett exempel på hur du genererar ett självsignerat certifikat, exporterar certifikatet som en .pfx-fil, konverterar .pfx-filen till en base64-kodad sträng och sparar sedan den base64-kodade strängen till en separat fil. 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 kan du använda azure Resource Manager-exempelmallen för att konfigurera standard-TLS/SSL-certifikatet .

Parametrarna i azuredeploy.parameters.json-filen visas nedan:

  • 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. Med hjälp av kodfragmentet som visades tidigare kopierar du strängen som finns i "exportedcert.pfx.b64" och klistrar in den som värdet för attributet pfxBlobString .
  • 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 $certThumbprint från det tidigare kodfragmentet) kan du använda värdet som det är. Men om du kopierar värdet från Windows-certifikatdialogrutan, kom ihåg att ta bort de överflödiga blankstegen. CertifikatetThumbprint bör se ut ungefär så här: AF3143EB61D43F6727842115BB7F17BBCECAECAE
  • certificateName: En egen egen strängidentifierare som används för att identifiera certifikatet. Namnet används som en del av den unika Azure Resource Manager-identifieraren för entiteten Microsoft.Web/certificates som representerar TLS/SSL-certifikatet. Namnet måste sluta med följande suffix: _yourASENameHere_InternalLoadBalancingASE. Det här suffixet används av portalen 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 nedan:

{
    "$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 kan standardcertifikatet för TLS/SSL konfigureras med hjälp av följande PowerShell-kodfragment. Ändra filsökvägarna så att de matchar var Azure Resource Manager-mallfilerna finns på datorn. Kom också ihåg att ange dina egna värden för Azure 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

När Azure Resource Manager-mallen har skickats tar det ungefär 40 minuter per ASE-klientdel att tillämpa ändringen. Till exempel, med en standardstorlek ase med två klientdelar, kommer mallen att ta cirka 1 timme och 20 minuter att slutföra. Även om mallen kör ASE kan den inte skalas.

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

Precis som appar som körs på den offentliga tjänsten för flera innehavare kan utvecklare också konfigurera anpassade värdnamn för enskilda appar och sedan konfigurera unika SNI TLS/SSL-certifikatbindningar för enskilda appar.

Komma igång

Information om hur du kommer igång med App Service-miljön finns i Introduktion till App Service-miljön

Kommentar

Om du vill komma igång med Azure App Service innan du registrerar dig för ett Azure-konto kan du gå till Prova App Service. Där kan du direkt skapa en tillfällig startwebbapp i App Service. Inga kreditkort krävs. Inga åtaganden.