Udostępnij za pośrednictwem

Jak utworzyć protokół ASEv1 z wewnętrznym modułem równoważenia obciążenia przy użyciu szablonów usługi Azure Resource Manager

  • Artykuł

Ważne

Ten artykuł dotyczy środowiska App Service Environment w wersji 1. Środowisko App Service Environment w wersji 1 i v2 jest wycofyzowane od 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 1, wykonaj kroki opisane w tym artykule , aby przeprowadzić migrację do nowej wersji.

Od 31 sierpnia 2024 r. umowa dotycząca poziomu usług (SLA) i środki na usługi nie mają już zastosowania do obciążeń środowiska App Service Environment w wersji 1 i w wersji 2, które nadal znajdują się w środowisku produkcyjnym, ponieważ są wycofane produkty. Rozpoczęto likwidowanie sprzętu środowiska App Service Environment w wersji 1 i 2. Może to mieć wpływ na dostępność i wydajność aplikacji i danych.

Musisz natychmiast ukończyć migrację do środowiska App Service Environment w wersji 3 lub usunąć aplikacje i zasoby. Podejmiemy próbę automatycznej migracji wszystkich pozostałych środowisk App Service Environment w wersji 1 i 2 w oparciu o najlepsze rozwiązanie przy użyciu funkcji migracji w miejscu, ale firma Microsoft nie udziela żadnych oświadczeń ani gwarancji dotyczących dostępności aplikacji po migracji automatycznej. Może być konieczne wykonanie ręcznej konfiguracji w celu ukończenia migracji i zoptymalizowania wybranej jednostki SKU planu usługi App Service w celu spełnienia Twoich potrzeb. Jeśli automatyczna migracja nie jest wykonalna, zasoby i skojarzone dane aplikacji zostaną usunięte. Zdecydowanie zachęcamy do podjęcia działań, aby uniknąć jednego z tych ekstremalnych scenariuszy.

Jeśli potrzebujesz dodatkowego czasu, możemy zaoferować jednorazowy 30-dniowy okres prolongaty umożliwiający ukończenie migracji. Aby uzyskać więcej informacji i zażądać tego okresu prolongaty, zapoznaj się z omówieniem okresu prolongaty, a następnie przejdź do witryny Azure Portal i odwiedź blok Migracja dla każdego środowiska App Service Environment.

Aby uzyskać najbardziej aktualne informacje na temat wycofania środowiska App Service Environment w wersji 1/2, zobacz aktualizację wycofania środowiska App Service Environment w wersji 1 i 2.

Omówienie

Środowiska App Service Environment można utworzyć przy użyciu wewnętrznego adresu sieci wirtualnej zamiast publicznego adresu VIP. Ten adres wewnętrzny jest dostarczany przez składnik platformy Azure nazywany wewnętrznym modułem równoważenia obciążenia (ILB). Środowiska ASE z wewnętrznym modułem równoważenia obciążenia można utworzyć przy użyciu witryny Azure Portal. Można go również utworzyć przy użyciu automatyzacji za pomocą szablonów usługi Azure Resource Manager. W tym artykule przedstawiono kroki i składnię wymaganą do utworzenia środowiska ASE z wewnętrznym modułem równoważenia obciążenia przy użyciu szablonów usługi Azure Resource Manager.

Istnieją trzy kroki związane z automatyzacją tworzenia środowiska ASE z wewnętrznym modułem równoważenia obciążenia:

  1. Najpierw podstawowy środowisko ASE jest tworzone w sieci wirtualnej przy użyciu wewnętrznego adresu modułu równoważenia obciążenia zamiast publicznego adresu VIP. W ramach tego kroku do środowiska ASE z wewnętrznym modułem równoważenia obciążenia jest przypisywana nazwa domeny głównej.
  2. Po utworzeniu środowiska ASE z wewnętrznym modułem równoważenia obciążenia zostanie przekazany certyfikat TLS/SSL.
  3. Przekazany certyfikat TLS/SSL jest jawnie przypisany do środowiska ASE z wewnętrznym modułem równoważenia obciążenia jako "domyślny" certyfikat TLS/SSL. Ten certyfikat TLS/SSL będzie używany do ruchu TLS do aplikacji w ase z wewnętrznym modułem równoważenia obciążenia, gdy aplikacje są adresowane przy użyciu wspólnej domeny głównej przypisanej do środowiska ASE (na przykład https://someapp.mycustomrootcomain.com)

Tworzenie podstawowego środowiska ASE z wewnętrznym modułem równoważenia obciążenia

Przykładowy szablon usługi Azure Resource Manager i skojarzony z nim plik parametrów są dostępne tutaj.

Większość parametrów w pliku azuredeploy.parameters.json jest powszechna w przypadku tworzenia zarówno środowiska ASE z wewnętrznym modułem równoważenia obciążenia, jak i środowiska ASE powiązanych z publicznym adresem VIP. Poniższa lista wywołuje parametry specjalnej notatki lub są unikatowe podczas tworzenia środowiska ASE z wewnętrznym modułem równoważenia obciążenia:

  • internalLoadBalancingMode: określa sposób uwidaczniania portów kontroli i danych.
    • 3 oznacza, że ruch HTTP/HTTPS na portach 80/443, a porty sterowania/kanału danych nasłuchiwane przez usługę FTP w asE zostaną powiązane z przydzielonym adresem wewnętrznym sieci wirtualnej z wewnętrznym modułem równoważenia obciążenia.
    • 2 oznacza, że tylko porty powiązane z usługą FTP (zarówno kontrolka, jak i kanały danych) będą powiązane z adresem ILB, podczas gdy ruch HTTP/HTTPS pozostanie na publicznym adresie VIP.
    • 0 oznacza, że cały ruch jest powiązany z publicznym adresem VIP, który sprawia, że środowiska ASE są zewnętrzne.
  • dnsSuffix: ten parametr definiuje domyślną domenę główną, która zostanie przypisana do środowiska ASE. W publicznej odmianie usługi aplikacja systemu Azure domyślną domeną główną dla wszystkich aplikacji internetowych jest azurewebsites.net. Jednak 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 hipotetyczna 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.
  • ipSslAddressCount: ten parametr jest automatycznie domyślnie domyślnie ustawiony na 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 i dlatego 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 dla środowiska ASE z wewnętrznym modułem równoważenia obciążenia można utworzyć środowiska ASE z wewnętrznym modułem równoważenia obciążenia przy użyciu następującego fragmentu kodu programu PowerShell. Zmień ścieżki plików tak, aby odpowiadały miejscu, w którym znajdują się pliki szablonów usługi Azure Resource Manager na maszynie. Pamiętaj również, aby podać własne wartości dla nazwy wdrożenia usługi Azure 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

Po przesłaniu szablonu usługi Azure Resource Manager utworzenie środowiska ASE z wewnętrznym modułem równoważenia obciążenia potrwa kilka godzin. Po zakończeniu tworzenia środowisko ASE z wewnętrznym modułem równoważenia obciążenia zostanie wyświetlone w środowisku użytkownika portalu na liście środowisk App Service Environment dla subskrypcji, która wyzwoliła wdrożenie.

Przekazywanie i konfigurowanie domyślnego certyfikatu TLS/SSL

Po utworzeniu środowiska ASE z wewnętrznym modułem równoważenia obciążenia certyfikat TLS/SSL powinien być skojarzony ze środowiskaMI ASE jako "domyślny" certyfikat TLS/SSL używany do ustanawiania połączeń TLS/SSL z aplikacjami. Kontynuując hipotetyczny przykład contoso Corporation, 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.

Istnieją różne sposoby uzyskiwania prawidłowego certyfikatu TLS/SSL, w tym wewnętrzne urzędy certyfikacji, kupowanie certyfikatu od zewnętrznego wystawcy i używanie 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*. Przyczyną drugiego wpisu jest to, że połączenia TLS z witryną SCM/Kudu skojarzone z każdą aplikacją będą używane przy użyciu adresu formularza your-app-name.scm.your-root-domain-here.com.

W przypadku prawidłowego certyfikatu TLS/SSL potrzebne są dwa dodatkowe kroki przygotowawcze. Certyfikat TLS/SSL musi zostać przekonwertowany/zapisany jako plik pfx. Należy pamiętać, że plik PFX musi zawierać wszystkie certyfikaty pośrednie i główne, a także musi być zabezpieczony hasłem.

Następnie wynikowy plik pfx musi zostać przekonwertowany na ciąg base64, ponieważ certyfikat TLS/SSL zostanie przekazany przy użyciu szablonu usługi Azure Resource Manager. Ponieważ szablony usługi Azure Resource Manager to pliki tekstowe, plik PFX musi zostać przekonwertowany na ciąg base64, aby można go było dołączyć jako parametr szablonu.

Poniższy fragment kodu programu PowerShell przedstawia przykład generowania certyfikatu z podpisem własnym, eksportowania certyfikatu jako pliku pfx, konwertowania pliku pfx na ciąg zakodowany w formacie base64, a następnie zapisywania zakodowanego ciągu base64 w osobnym pliku. Kod programu PowerShell do kodowania base64 został dostosowany z 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 można użyć przykładowego szablonu usługi Azure Resource Manager do konfigurowania domyślnego certyfikatu TLS/SSL.

Poniżej wymieniono parametry w pliku azuredeploy.parameters.json :

  • 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: zakodowana na podstawie64 reprezentacja ciągu pliku pfx. Korzystając z przedstawionego wcześniej fragmentu kodu, skopiujesz ciąg zawarty w pliku "exportedcert.pfx.b64" i 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 $certThumbprint z wcześniejszego fragmentu kodu), możesz użyć wartości w takiej postaci, jak to jest. Jeśli jednak skopiujesz wartość z okna dialogowego certyfikatu systemu Windows, pamiętaj, aby usunąć dodatkowe spacje. Element certificateThumbprint powinien wyglądać mniej więcej tak: AF3143EB61D43F6727842115BB7F17BBCECAECAE
  • certificateName: przyjazny identyfikator ciągu używany do tożsamości certyfikatu. Nazwa jest używana jako część unikatowego identyfikatora usługi Azure Resource Manager dla jednostki Microsoft.Web/certificates reprezentującej certyfikat TLS/SSL. Nazwa musi kończyć się następującym sufiksem: _yourASENameHere_InternalLoadBalancingASE. Ten sufiks jest używany przez portal jako wskaźnik, ż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 można skonfigurować domyślny certyfikat TLS/SSL przy użyciu następującego fragmentu kodu programu PowerShell. Zmień ścieżki plików tak, aby odpowiadały miejscu, w którym znajdują się pliki szablonów usługi Azure Resource Manager na maszynie. Pamiętaj również, aby podać własne wartości dla nazwy wdrożenia usługi Azure 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

Po przesłaniu szablonu usługi Azure Resource Manager zastosowanie zmiany potrwa około 40 minut na fronton środowiska ASE. Na przykład w przypadku domyślnego rozmiaru środowiska ASE z dwoma frontonami ukończenie szablonu potrwa około 1 godziny i 20 minut. Gdy szablon jest uruchomiony, nie będzie można skalować środowiska ASE.

Po zakończeniu pracy szablonu aplikacje w ase z wewnętrznym modułem równoważenia obciążenia mogą być dostępne za pośrednictwem protokołu HTTPS, a połączenia będą zabezpieczone przy użyciu domyślnego certyfikatu TLS/SSL. Domyślny certyfikat TLS/SSL będzie używany, gdy aplikacje w środowiskach ASE z wewnętrznym modułem równoważenia obciążenia zostaną rozwiązane przy użyciu kombinacji nazwy aplikacji oraz domyślnej nazwy hosta. Na przykład https://mycustomapp.internal.contoso.com użyje domyślnego certyfikatu TLS/SSL dla *.internal.contoso.com.

Jednak podobnie jak aplikacje działające w publicznej usłudze wielodostępnej, deweloperzy mogą również skonfigurować niestandardowe nazwy hostów dla poszczególnych aplikacji, a następnie skonfigurować unikatowe powiązania certyfikatów TLS/SSL SNI dla poszczególnych aplikacji.

Wprowadzenie

Aby rozpocząć pracę ze środowiskami App Service Environment, zobacz Wprowadzenie do środowiska App Service Environment

Uwaga

Jeśli chcesz rozpocząć pracę z usługą Azure App Service przed utworzeniem nowego konta Azure, przejdź do strony Wypróbuj usługę App Service, na której możesz od razu utworzyć startową tymczasową aplikację internetową przy użyciu usługi App Service. Bez kart kredytowych i bez zobowiązań.