Tworzenie środowiska ASE przy użyciu szablonu usługi Azure Resource Manager

  • Artykuł

Omówienie

Ważne

Ten artykuł dotyczy środowiska App Service Environment w wersji 2, który jest używany z planami izolowanej usługi App Service. Środowisko App Service Environment w wersji 2 zostanie wycofane 31 sierpnia 2024 r. Jest dostępna nowa wersja środowiska App Service Environment, która jest łatwiejsza do użycia i działa w bardziej wydajnej infrastrukturze. Aby dowiedzieć się więcej o nowej wersji, zacznij od wprowadzenia do środowiska App Service Environment. Jeśli obecnie używasz środowiska App Service Environment w wersji 2, wykonaj kroki opisane w tym artykule , aby przeprowadzić migrację do nowej wersji.

Od 29 stycznia 2024 r. nie można już tworzyć nowych zasobów środowiska App Service Environment w wersji 2 przy użyciu dowolnej z dostępnych metod, w tym szablonów usługi ARM/Bicep, witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST. Aby zapobiec usunięciu zasobów i utracie danych, musisz przeprowadzić migrację do środowiska App Service Environment w wersji 3 przed 31 sierpnia 2024 r.

aplikacja systemu Azure środowiska usługi (ASE) można utworzyć za pomocą punktu końcowego dostępnego z Internetu lub punktu końcowego na wewnętrznym adresie w usłudze Azure Virtual Network. Po utworzeniu przy użyciu wewnętrznego punktu końcowego ten punkt końcowy jest dostarczany przez składnik platformy Azure nazywany wewnętrznym modułem równoważenia obciążenia (ILB). Środowisko ASE na wewnętrznym adresie IP jest nazywane środowiskom ASE wewnętrznego modułu równoważenia obciążenia. Środowiska ASE z publicznym punktem końcowym są nazywane zewnętrznym ase.

Środowiska ASE można utworzyć przy użyciu witryny Azure Portal lub szablonu usługi Azure Resource Manager. W tym artykule opisano kroki i składnię, które należy utworzyć zewnętrzne środowiska ASE lub środowiska ASE z wewnętrznym modułem równoważenia obciążenia przy użyciu szablonów usługi Resource Manager. Aby dowiedzieć się, jak utworzyć asev2 w witrynie Azure Portal, zobacz [Make an External ASE][MakeExternalASE] lub Make an ILB ASE (Tworzenie środowiska ASE z wewnętrznym modułem równoważenia obciążenia).

Podczas tworzenia środowiska ASE w witrynie Azure Portal możesz utworzyć sieć wirtualną w tym samym czasie lub wybrać wcześniej istniejącą sieć wirtualną do wdrożenia.

Podczas tworzenia środowiska ASE na podstawie szablonu należy zacząć od:

  • Sieć wirtualna platformy Azure.
  • Podsieć w tej sieci wirtualnej. Zalecamy rozmiar podsieci środowiska ASE z /24 256 adresami, aby uwzględnić przyszłe potrzeby wzrostu i skalowania. Po utworzeniu środowiska ASE nie można zmienić rozmiaru.
  • Subskrypcja, do której chcesz się wdrożyć.
  • Lokalizacja, w której chcesz przeprowadzić wdrożenie.

Aby zautomatyzować tworzenie środowiska ASE, postępuj zgodnie z wytycznymi w poniższych sekcjach. Jeśli tworzysz asev2 wewnętrznego modułu równoważenia obciążenia z niestandardowym systemem dnsSuffix (na przykład internal.contoso.com), istnieje kilka innych czynności do wykonania.

  1. Po utworzeniu środowiska ASE z wewnętrznym modułem równoważenia obciążenia z niestandardowym systemem dnsSuffix należy przekazać certyfikat TLS/SSL zgodny z domeną środowiska ASE wewnętrznego modułu równoważenia obciążenia.

  2. Przekazany certyfikat TLS/SSL jest przypisywany do środowiska ASE z wewnętrznym modułem równoważenia obciążenia jako "domyślny" certyfikat TLS/SSL. Ten certyfikat jest używany na potrzeby ruchu TLS/SSL do aplikacji w środowiskach ASE z wewnętrznym modułem równoważenia obciążenia, gdy używają wspólnej domeny głównej przypisanej do środowiska ASE (na przykład https://someapp.internal.contoso.com).

Tworzenie środowiska ASE

Szablon usługi Resource Manager, który tworzy środowisko ASE i skojarzony z nim plik parametrów, jest dostępny w usłudze GitHub dla środowiska ASEv2.

Jeśli chcesz utworzyć usługę ASE, użyj tego przykładu asev2 szablonu usługi Resource Manager. Większość parametrów w pliku azuredeploy.parameters.json jest powszechna w przypadku tworzenia środowiska ASE z wewnętrznym modułem równoważenia obciążenia i zewnętrznego środowiska ASE. Poniższa lista wywołuje parametry specjalnej notatki lub jest to unikatowe podczas tworzenia środowiska ASE z wewnętrznym modułem równoważenia obciążenia z istniejącą podsiecią.

Parametry

  • aseName: ten parametr definiuje unikatową nazwę środowiska ASE.
  • location: ten parametr definiuje lokalizację środowiska App Service Environment.
  • existingVirtualNetworkName: ten parametr definiuje nazwę sieci wirtualnej istniejącej sieci wirtualnej i podsieci, w której będzie znajdować się środowisko ASE.
  • existingVirtualNetworkResourceGroup: jego parametr definiuje nazwę grupy zasobów istniejącej sieci wirtualnej i podsieci, w której będzie znajdować się środowisko ASE.
  • subnetName: ten parametr definiuje nazwę podsieci istniejącej sieci wirtualnej i podsieci, w której będzie znajdować się środowisko ASE.
  • internalLoadBalancingMode: W większości przypadków ustaw wartość 3, co oznacza, że ruch HTTP/HTTPS na portach 80/443, a porty kanału sterowania/danych nasłuchiwane przez usługę FTP w środowisku ASE będą powiązane z wewnętrznym adresem sieci wirtualnej przydzielonej przez moduł równoważenia obciążenia. Jeśli ta właściwość jest ustawiona na 2, tylko porty związane z usługą FTP (zarówno kontrolka, jak i kanały danych) są powiązane z adresem wewnętrznym modułu równoważenia obciążenia. Jeśli ta właściwość ma wartość 0, ruch HTTP/HTTPS pozostaje na publicznym adresie VIP.
  • dnsSuffix: ten parametr definiuje domyślną domenę główną przypisaną do środowiska ASE. W publicznej odmianie usługi aplikacja systemu Azure domyślną domeną główną dla wszystkich aplikacji internetowych jest azurewebsites.net. Ponieważ środowisko ASE z wewnętrznym modułem równoważenia obciążenia jest wewnętrzne dla sieci wirtualnej klienta, nie ma sensu używać domyślnej domeny głównej usługi publicznej. Zamiast tego środowisko ASE z wewnętrznym modułem równoważenia obciążenia powinno mieć domyślną domenę główną, która ma sens do użycia w wewnętrznej sieci wirtualnej firmy. Na przykład firma Contoso Corporation może używać domyślnej domeny głównej internal.contoso.com dla aplikacji, które mają być rozpoznawalne i dostępne tylko w sieci wirtualnej firmy Contoso. Aby określić niestandardową domenę główną, należy użyć wersji 2018-11-01 interfejsu API lub wcześniejszych wersji.
  • ipSslAddressCount: ten parametr automatycznie domyślnie ma wartość 0 w pliku azuredeploy.json , ponieważ środowiska ASE z wewnętrznym modułem równoważenia obciążenia mają tylko jeden adres wewnętrznym modułu równoważenia obciążenia. Nie ma jawnych adresów IP SSL dla środowiska ASE z wewnętrznym modułem równoważenia obciążenia. W związku z tym pula adresów IP SSL dla środowiska ASE z wewnętrznym modułem równoważenia obciążenia musi być ustawiona na zero. W przeciwnym razie wystąpi błąd aprowizacji.

Po wypełnieniu pliku azuredeploy.parameters.json utwórz program ASE przy użyciu fragmentu kodu programu PowerShell. Zmień ścieżki plików, aby pasować do lokalizacji pliku szablonu usługi Resource Manager na maszynie. Pamiętaj, aby podać własne wartości dla nazwy wdrożenia usługi Resource Manager i nazwy grupy zasobów:

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

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

Utworzenie środowiska ASE trwa około dwóch godzin. Następnie środowiska ASE są wyświetlane w portalu na liście ase dla subskrypcji, która wyzwoliła wdrożenie.

Przekazywanie i konfigurowanie "domyślnego" certyfikatu TLS/SSL

Certyfikat TLS/SSL musi być skojarzony ze środowiskaMI ASE jako "domyślny" certyfikat TLS/SSL używany do nawiązywania połączeń TLS z aplikacjami. Jeśli domyślny sufiks DNS środowiska ASE jest internal.contoso.com, połączenie https://some-random-app.internal.contoso.com wymaga certyfikatu TLS/SSL, który jest ważny dla *.internal.contoso.com.

Uzyskaj prawidłowy certyfikat TLS/SSL przy użyciu wewnętrznych urzędów certyfikacji, zakupu certyfikatu od zewnętrznego wystawcy lub certyfikatu z podpisem własnym. Niezależnie od źródła certyfikatu TLS/SSL należy prawidłowo skonfigurować następujące atrybuty certyfikatu:

  • Temat: ten atrybut musi być ustawiony na *.your-root-domain-here.com.
  • Alternatywna nazwa podmiotu: ten atrybut musi zawierać zarówno *.your-root-domain-here.com, jak i *.scm.your-root-domain-here.com. Połączenia TLS z witryną SCM/Kudu skojarzona z każdą aplikacją używają adresu your-app-name.scm.your-root-domain-here.com formularza.

W przypadku prawidłowego certyfikatu TLS/SSL potrzebne są jeszcze dwa kroki przygotowawcze. Przekonwertuj/zapisz certyfikat TLS/SSL jako plik pfx. Należy pamiętać, że plik PFX musi zawierać wszystkie certyfikaty pośrednie i główne. Zabezpiecz go przy użyciu hasła.

Plik PFX musi zostać przekonwertowany na ciąg base64, ponieważ certyfikat TLS/SSL jest przekazywany przy użyciu szablonu usługi Resource Manager. Ponieważ szablony usługi Resource Manager to pliki tekstowe, plik PFX musi zostać przekonwertowany na ciąg base64. W ten sposób można go dołączyć jako parametr szablonu.

Użyj następującego fragmentu kodu programu PowerShell, aby:

  • Wygeneruj certyfikat z podpisem własnym.
  • Wyeksportuj certyfikat jako plik pfx.
  • Przekonwertuj plik PFX na ciąg zakodowany w formacie base64.
  • Zapisz ciąg zakodowany w formacie base64 w osobnym pliku.

Ten kod programu PowerShell do kodowania base64 został dostosowany z poziomu bloga skryptów programu PowerShell:

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

Po pomyślnym wygenerowaniu i przekonwertowaniu certyfikatu TLS/SSL na ciąg zakodowany w formacie base64 użyj przykładowego szablonu usługi Resource Manager Konfigurowanie domyślnego certyfikatu SSL w usłudze GitHub.

Parametry w pliku azuredeploy.parameters.json są wymienione tutaj:

  • appServiceEnvironmentName: nazwa konfigurowanego środowiska ASE wewnętrznego modułu równoważenia obciążenia.
  • existingAseLocation: ciąg tekstowy zawierający region świadczenia usługi Azure, w którym wdrożono środowiska ASE z wewnętrznym modułem równoważenia obciążenia. Na przykład: "Południowo-środkowe stany USA".
  • pfxBlobString: ciąg zakodowany na podstawie64 reprezentujący plik pfx. Użyj pokazanego wcześniej fragmentu kodu i skopiuj ciąg zawarty w pliku "exportedcert.pfx.b64". Wklej go jako wartość atrybutu pfxBlobString .
  • hasło: hasło używane do zabezpieczania pliku pfx.
  • certificateThumbprint: odcisk palca certyfikatu. Jeśli pobierasz tę wartość z programu PowerShell (na przykład $certificate.Thumbprint z wcześniejszego fragmentu kodu), możesz użyć wartości w taki sposób, jak to. Jeśli skopiujesz wartość z okna dialogowego certyfikatu systemu Windows, pamiętaj, aby usunąć dodatkowe spacje. Element certificateThumbprint powinien wyglądać mniej więcej tak, jak AF3143EB61D43F6727842115BB7F17BBCECAECAE.
  • certificateName: przyjazny identyfikator ciągu używany do tożsamości certyfikatu. Nazwa jest używana jako część unikatowego identyfikatora usługi Resource Manager dla jednostki Microsoft.Web/certificates , która reprezentuje certyfikat TLS/SSL. Nazwa musi kończyć się następującym sufiksem: _yourASENameHere_InternalLoadBalancingASE. Witryna Azure Portal używa tego sufiksu jako wskaźnika, że certyfikat jest używany do zabezpieczania środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia.

Poniżej przedstawiono skrócony przykład 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"
    }
  }
}

Po wypełnieniu pliku azuredeploy.parameters.json skonfiguruj domyślny certyfikat TLS/SSL przy użyciu fragmentu kodu programu PowerShell. Zmień ścieżki plików tak, aby odpowiadały miejscu, w którym znajdują się pliki szablonu usługi Resource Manager na maszynie. Pamiętaj, aby podać własne wartości dla nazwy wdrożenia usługi Resource Manager i nazwy grupy zasobów:

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

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

Zastosowanie zmiany trwa około 40 minut na fronton środowiska ASE. Na przykład w przypadku środowiska ASE o domyślnym rozmiarze, który używa dwóch frontonów, ukończenie szablonu trwa około 1 godziny i 20 minut. Gdy szablon jest uruchomiony, nie można skalować środowiska ASE.

Po zakończeniu szablonu dostęp do aplikacji w ase z wewnętrznym modułem równoważenia obciążenia można uzyskać za pośrednictwem protokołu HTTPS. Połączenia są zabezpieczone przy użyciu domyślnego certyfikatu TLS/SSL. Domyślny certyfikat TLS/SSL jest używany, gdy aplikacje w środowiskach ASE z wewnętrznym modułem równoważenia obciążenia są adresowane przy użyciu kombinacji nazwy aplikacji oraz domyślnej nazwy hosta. Na przykład https://mycustomapp.internal.contoso.com używa domyślnego certyfikatu TLS/SSL dla *.internal.contoso.com.

Jednak podobnie jak aplikacje uruchamiane w publicznej usłudze wielodostępne, deweloperzy mogą konfigurować niestandardowe nazwy hostów dla poszczególnych aplikacji. Mogą również konfigurować unikatowe powiązania certyfikatów TLS/SSL SNI dla poszczególnych aplikacji.