Konfigurowanie środowisk przejściowych w usłudze Azure App Service


Tworzenie aplikacji internetowej

New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]

Tworzenie miejsca

New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]

Inicjowanie zamiany za pomocą wersji zapoznawczej (zamiana wielofazowa) i stosowanie konfiguracji miejsca docelowego do miejsca źródłowego

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01

Anulowanie oczekującej zamiany (zamiana z przeglądem) i przywracanie konfiguracji miejsca źródłowego

Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01

Zamiana miejsc wdrożenia

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01

Monitorowanie zdarzeń zamiany w dzienniku aktywności

Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor  

Usuwanie miejsca

Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01

Automatyzacja przy użyciu Resource Manager szablonów

Azure Resource Manager to deklaratywne pliki JSON służące do automatyzowania wdrażania i konfigurowania zasobów platformy Azure. Aby zamienić miejsca przy użyciu Resource Manager szablonów, ustawisz dwie właściwości w zasobach Microsoft.Web/sites/slots i Microsoft.Web/sites:

  • buildVersion: jest to właściwość ciągu reprezentująca bieżącą wersję aplikacji wdrożonej w miejscu. Na przykład: "v1", "1.0.0.1" lub "2019-09-20T11:53:25.2887393-07:00".
  • targetBuildVersion: jest to właściwość ciągu określająca, buildVersion co powinno mieć miejsce. Jeśli targetBuildVersion nie jest równa bieżącej wartości , spowoduje to wyzwolenie operacji zamiany przez znalezienie miejsca o buildVersion określonej wartości buildVersion .

Przykładowy Resource Manager szablonu

Poniższy Resource Manager zaktualizuje obiekt miejsca przejściowego i buildVersion ustawi obiekt targetBuildVersion w miejscu produkcyjnym. Spowoduje to zamianę dwóch miejsc. W szablonie przyjęto założenie, że masz już utworzoną aplikacji internetowej z miejscem o nazwie "staging".

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "my_site_name": {
            "defaultValue": "SwapAPIDemo",
            "type": "String"
        },
        "sites_buildVersion": {
            "defaultValue": "v1",
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Web/sites/slots",
            "apiVersion": "2018-02-01",
            "name": "[concat(parameters('my_site_name'), '/staging')]",
            "location": "East US",
            "kind": "app",
            "properties": {
                "buildVersion": "[parameters('sites_buildVersion')]"
            }
        },
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('my_site_name')]",
            "location": "East US",
            "kind": "app",
            "dependsOn": [
                "[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
            ],
            "properties": {
                "targetBuildVersion": "[parameters('sites_buildVersion')]"
            }
        }        
    ]
}

Ten Resource Manager jest idempotentny, co oznacza, że może być wykonywany wielokrotnie i tworzyć ten sam stan miejsc. Po pierwszym wykonaniu wartość targetBuildVersion będzie odpowiadać bieżącej , buildVersion więc zamiana nie zostanie wyzwolona.

Automatyzacja przy użyciu interfejsu wiersza polecenia

Aby uzyskać polecenia interfejsu wiersza polecenia platformy Azure dla miejsc wdrożenia, zobacz az webapp deployment slot.

Rozwiązywanie problemów z zamianami

Jeśli podczas zamiany miejsca wystąpi jakikolwiek błąd,zostanie onD:\home\LogFiles\eventlog.xml. Jest on również rejestrowany w dzienniku błędów specyficznym dla aplikacji.

Poniżej podano niektóre typowe błędy zamiany:

  • Uchyliliśmy czas żądania HTTP do katalogu głównego aplikacji. Operacja zamiany czeka 90 sekund dla każdego żądania HTTP, a ponowna próba jest 5 razy. Jeśli zostanie użytą wartość dla wszystkich ponownych prób, operacja zamiany zostanie zatrzymana.

  • Inicjowanie lokalnej pamięci podręcznej może się nie powieść, gdy zawartość aplikacji przekroczy limit przydziału dysku lokalnego określony dla lokalnej pamięci podręcznej. Aby uzyskać więcej informacji, zobacz Omówienie lokalnej pamięci podręcznej.

  • Podczas niestandardowej rozgrzewkiżądania HTTP są dokonywane wewnętrznie (bez użycia zewnętrznego adresu URL). Mogą one nie powieść się z pewnymi regułami ponownego pisali adresy URL w Web.config. Na przykład reguły przekierowywania nazw domen lub wymuszania protokołu HTTPS mogą uniemożliwić dotarcie żądań rozgrzewki do kodu aplikacji. Aby ominąc ten problem, zmodyfikuj reguły ponownego pisu, dodając następujące dwa warunki:

    <conditions>
      <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
      ...
    </conditions>
    
  • Bez niestandardowej rozgrzewki reguły ponownego pisali adresy URL nadal mogą blokować żądania HTTP. Aby ominąc ten problem, zmodyfikuj reguły ponownego pisu, dodając następujący warunek:

    <conditions>
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
      ...
    </conditions>
    
  • Po zamianie miejsca aplikacja może doświadczyć nieoczekiwanych ponownego uruchomienia. Dzieje się tak, ponieważ po zamianie konfiguracja powiązania nazwy hosta nie jest zsynchronizowana, co samo w sobie nie powoduje ponownego uruchomienia. Jednak niektóre podstawowe zdarzenia magazynu (takie jak trybu failover woluminu magazynu) mogą wykryć te rozbieżności i wymusić ponowne uruchomienie wszystkich procesów roboczych. Aby zminimalizować tego rodzaju ponowne uruchomienia, ustaw ustawienie aplikacji we wszystkich gniazdach. To ustawienie aplikacji nie działa jednak z Windows Communication Foundation (WCF).

Następne kroki

Blokowanie dostępu do miejsc nieprodukcji

Podczas wdrażaniaaplikacji internetowej, aplikacji internetowej w systemie Linux, aplikacji mobilnej lub aplikacji interfejsu API do usługi Azure App Service można użyć oddzielnego miejsca wdrożenia zamiast domyślnego miejsca produkcyjnego w przypadku uruchamiania w warstwie planu standardowego, Premiumlub izolowanego App Service. Miejsca wdrożenia to aplikacje na żywo z własnymi nazwami hostów. Zawartość aplikacji i elementy konfiguracji można zamienić między dwoma miejscami wdrożenia, w tym z miejsca produkcyjnego.

Wdrażanie aplikacji w miejscu nieprodukcyjną ma następujące korzyści:

  • Możesz zweryfikować zmiany aplikacji w przejściowym miejscu wdrożenia przed zamianą jej na miejsce produkcyjne.
  • Wdrażanie aplikacji najpierw w miejscu wdrożenia i zamiana go na środowisko produkcyjne daje pewność, że wszystkie wystąpienia miejsc wdrożenia są rozgrzane przed zamianą na środowisko produkcyjne. Eliminuje to przestoje podczas wdrażania aplikacji. Przekierowywanie ruchu jest bezproblemowe i żadne żądania nie są porzucane z powodu operacji wymiany. Ten cały przepływ pracy można zautomatyzować, konfigurując zamianę automatyczną, gdy weryfikacja przed zamianą nie jest potrzebna.
  • Po zamianie miejsce z wcześniej przejechaną aplikacją ma teraz poprzednią aplikację produkcyjną. Jeśli zmiany zamienione w miejscu produkcyjnym nie są zgodnie z oczekiwaniami, możesz wykonać tę samą zamianę natychmiast, aby odzyskać "ostatnią znaną dobrą witrynę".

Każda App Service planu wdrożenia obsługuje inną liczbę miejsc wdrożenia. Za korzystanie z miejsc wdrożenia nie są naliczane dodatkowe opłaty. Aby dowiedzieć się, jaka jest liczba miejsc, które obsługuje warstwa aplikacji, zobacz limity App Service aplikacji.

Aby skalować aplikację do innej warstwy, upewnij się, że warstwa docelowa obsługuje liczbę miejsc, z których aplikacja już korzysta. Jeśli na przykład aplikacja ma więcej niż pięć miejsc, nie można jej skalować w dół do warstwy Standardowa, ponieważ warstwa Standardowa obsługuje tylko pięć miejsc wdrożenia.

Dodawanie miejsca

Aby można było włączyć wiele miejsc wdrożenia, aplikacja musi działać w warstwie Standardowa,Premiumlub Izolowana.

  1. Na stronie Azure Portalwyszukaj i wybierz App Services i wybierz aplikację.

    Wyszukaj App Services

  2. W okienku po lewej stronie wybierz pozycję Miejsca wdrożenia Dodajmiejsce.

    Dodawanie nowego miejsca wdrożenia

    Uwaga

    Jeśli aplikacja nie znajduje się jeszcze w warstwie Standardowa, Premiumlub Izolowana, zostanie wyświetlony komunikat informujący o obsługiwanych warstwach umożliwiających publikowanie etapowe. W tym momencie możesz wybrać pozycję Uaktualnij i przejść do karty Skala aplikacji przed kontynuowaniem.

  3. W oknie dialogowym Dodawanie miejsca podaj nazwę miejsca i wybierz, czy sklonować konfigurację aplikacji z innego miejsca wdrożenia. Wybierz pozycję Dodaj, aby kontynuować.

    Źródło konfiguracji

    Konfigurację można sklonować z dowolnego istniejącego miejsca. Ustawienia, które można sklonować, obejmują ustawienia aplikacji, parametry połączenia, wersje platformy językowej, gniazda internetowe, wersję PROTOKOŁU HTTP i bitowość platformy.

  4. Po dodaniu miejsca wybierz pozycję Zamknij, aby zamknąć okno dialogowe. Nowe miejsce jest teraz wyświetlane na stronie Miejsca wdrożenia. Domyślnie wartość % ruchu jest ustawiona na 0 dla nowego miejsca, a cały ruch klientów jest przekierowyny do miejsca produkcyjnego.

  5. Wybierz nowe miejsce wdrożenia, aby otworzyć stronę zasobów tego miejsca.

    Tytuł miejsca wdrożenia

    Miejsce przejściowe zawiera stronę zarządzania, podobnie jak każda inna App Service aplikacji. Możesz zmienić konfigurację miejsca. Aby przypominać, że przeglądasz miejsce wdrożenia, nazwa aplikacji jest wyświetlana jako nazwa > aplikacji/ <>nazwa miejsca , a typ aplikacji to > Możesz również zobaczyć miejsce jako oddzielną aplikację w grupie zasobów z tym samym oznaczeniem.

  6. Wybierz adres URL aplikacji na stronie zasobu miejsca. Miejsce wdrożenia ma własną nazwę hosta i jest również aplikacją na żywo. Aby ograniczyć dostęp publiczny do miejsca wdrożenia, zobacz Azure App Service ograniczenia adresów IP.

Nowe miejsce wdrożenia nie ma zawartości, nawet jeśli sklonuje się ustawienia z innego miejsca. Na przykład możesz opublikować w tym miejscu za pomocą narzędzia Git. Możesz wdrożyć w miejscu z innej gałęzi repozytorium lub innego repozytorium.

Adres URL miejsca będzie miał format http://sitename-slotname.azurewebsites.net . Aby zachować długość adresu URL w ramach niezbędnych limitów DNS, nazwa witryny zostanie obcięta z 40 znakami, nazwa miejsca zostanie obcięta z 19 znakami, a dodatkowe 4 losowe znaki zostaną dołączone, aby zapewnić unikatowość wynikowej nazwy domeny.

Co się dzieje podczas zamiany

Kroki operacji zamiany

W przypadku zamiany dwóch miejsc (zazwyczaj z miejsca przejściowego do miejsca produkcyjnego) program App Service, aby upewnić się, że w miejscu docelowym nie wystąpi przestój:

  1. Zastosuj następujące ustawienia z miejsca docelowego (na przykład miejsca produkcyjnego) do wszystkich wystąpień miejsca źródłowego:

    Każdy z tych przypadków wyzwala ponowne uruchomienie wszystkich wystąpień w miejscu źródłowym. Podczas zamiany z podglądemoznacza to koniec pierwszej fazy. Operacja zamiany jest wstrzymana i można sprawdzić, czy miejsce źródłowe działa prawidłowo z ustawieniami miejsca docelowego.

  2. Poczekaj na zakończenie ponownego uruchamiania każdego wystąpienia w miejscu źródłowym. Jeśli ponowne uruchomienie jakiegokolwiek wystąpienia nie powiedzie się, operacja zamiany przywraca wszystkie zmiany do miejsca źródłowego i zatrzymuje operację.

  3. Jeśli lokalna pamięć podręczna jest włączona, wyzwolij inicjowanie lokalnej pamięci podręcznej, wywołując żądanie HTTP do katalogu głównego aplikacji ("/") w każdym wystąpieniu miejsca źródłowego. Poczekaj, aż każde wystąpienie zwróci dowolną odpowiedź HTTP. Inicjalizacja lokalnej pamięci podręcznej powoduje ponowne uruchomienie każdego wystąpienia.

  4. Jeśli zamiana automatyczna jest włączona z niestandardową rozgrzewą, wyzwolij inicjację aplikacji, wywołując żądanie HTTP do katalogu głównego aplikacji ("/") w każdym wystąpieniu miejsca źródłowego.

    Jeśli applicationInitialization nie zostanie określony, wyzwolij żądanie HTTP do katalogu głównego aplikacji w miejscu źródłowym w każdym wystąpieniu.

    Jeśli wystąpienie zwraca dowolną odpowiedź HTTP, uważa się, że jest rozgrzewka.

  5. Jeśli wszystkie wystąpienia w miejscu źródłowym zostaną rozgrowane pomyślnie, zamień te dwa miejsca, przełączając reguły rozsyłania dla dwóch miejsc. Po tym kroku miejsce docelowe (na przykład miejsce produkcyjne) ma aplikację, która została wcześniej rozgrzana w miejscu źródłowym.

  6. Teraz, gdy miejsce źródłowe zawiera aplikację przed zamianą wcześniej w miejscu docelowym, wykonaj tę samą operację, stosując wszystkie ustawienia i ponownie uruchamiając wystąpienia.

W dowolnym momencie operacji zamiany wszystkie prace nad zainicjowaniem zamienione aplikacje będą odbywać się w miejscu źródłowym. Miejsce docelowe pozostaje w trybie online podczas przygotowania i rozgrzewki miejsca źródłowego, niezależnie od tego, gdzie zamiana zakończy się powodzeniem lub niepowodzeniem. Aby zamienić miejsce przejściowe na miejsce produkcyjne, upewnij się, że miejsce produkcyjne jest zawsze miejscem docelowym. W ten sposób operacja zamiany nie ma wpływu na aplikację produkcyjną.

Uwaga

Wystąpienia w byłych wystąpieniach produkcyjnych (te, które zostaną zamienione na przejściowe po tej operacji zamiany) zostaną szybko odzyskane w ostatnim kroku procesu zamiany. W przypadku długotrwałych operacji w aplikacji zostaną one porzucone podczas odtwarzania przez pracowników. Dotyczy to również aplikacji funkcji. W związku z tym kod aplikacji powinien być napisany w sposób nieo odporności na uszkodzenia.

Które ustawienia są zamieniane?

W przypadku klonowania konfiguracji z innego miejsca wdrożenia sklonowana konfiguracja jest edytowalna. Niektóre elementy konfiguracji śledzą zawartość w ramach zamiany (nie są specyficzne dla miejsca), podczas gdy inne elementy konfiguracji pozostają w tym samym miejscu po zamianie (specyficzne dla miejsca). Na poniższych listach przedstawiono ustawienia, które zmieniają się podczas zamiany miejsc.

Ustawienia, które są zamieniane:

  • Ustawienia ogólne, takie jak wersja struktury, 32/64-bitowe gniazda internetowe
  • Ustawienia aplikacji (można skonfigurować tak, aby nie było miejsca)
  • Parametry połączenia (można je skonfigurować tak, aby przywierały do miejsca)
  • Mapowania programu obsługi
  • Certyfikaty publiczne
  • Zawartość usługi WebJobs
  • Połączenia hybrydowe *
  • Punkty końcowe usługi *
  • Azure Content Delivery Network *
  • Mapowania ścieżek

Funkcje oznaczone gwiazdką (*) mają być niezamapowane.

Ustawienia, które nie są zamieniane:

  • Publikowanie punktów końcowych
  • Niestandardowe nazwy domen
  • Niepublicznie dostępne certyfikaty i ustawienia protokołu TLS/SSL
  • Ustawienia skalowania
  • Harmonogramy zadań WebJob
  • Ograniczenia adresów IP
  • Zawsze włączone
  • Ustawienia diagnostyczne
  • Współużytkowanie zasobów między źródłami (CORS)
  • Integracja sieci wirtualnej
  • Tożsamości zarządzane
  • Ustawienia kończy się sufiksem _EXTENSION_VERSION

Uwaga

Aby można było zamienić wyżej wymienione ustawienia, dodaj ustawienie aplikacji w każdym miejscu aplikacji i ustaw WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS jego wartość na lub 0false . Te ustawienia można zamienić lub w ogóle ich nie wymieniać. Nie można zamienić tylko niektórych ustawień, a nie innych. To ustawienie przesłaniania aplikacji nigdy nie powoduje zamiany tożsamości zarządzanych i nie ma na nie wpływu.

Niektóre ustawienia aplikacji, które mają zastosowanie do niezapiętych ustawień, również nie są zamieniane. Na przykład ponieważ ustawienia diagnostyczne nie są zamieniane, powiązane ustawienia aplikacji, takie jak i , również nie są zamieniane, nawet jeśli nie są wyświetlane WEBSITE_HTTPLOGGING_RETENTION_DAYSDIAGNOSTICS_AZUREBLOBRETENTIONDAYS jako ustawienia miejsca.

Aby skonfigurować ustawienie aplikacji lub parametrów połączenia do określonego miejsca (bez zamiany), przejdź do strony Konfiguracja dla tego miejsca. Dodaj lub edytuj ustawienie, a następnie wybierz ustawienie miejsca wdrożenia. Zaznaczenie tego pola wyboru App Service, że nie można zamienić ustawienia.

Ustawienie miejsca

Zamiana dwóch miejsc

Miejsca wdrożenia można zamienić na stronie Miejsca wdrożenia aplikacji i na stronie Przegląd. Aby uzyskać szczegółowe informacje techniczne dotyczące zamiany miejsca, zobacz Co się dzieje podczas zamiany.

Ważne

Przed zamianą aplikacji z miejsca wdrożenia na produkcyjne upewnij się, że miejsce docelowe jest produkcyjne i że wszystkie ustawienia w miejscu źródłowym są skonfigurowane dokładnie tak, jak chcesz, aby były w środowisku produkcyjnym.

Aby zamienić miejsca wdrożenia:

  1. Przejdź do strony Miejsca wdrożenia aplikacji i wybierz pozycję Zamień.

    Przycisk Zamień

    W oknie dialogowym Zamiana są wyświetlane ustawienia w wybranych gniazdach źródłowych i docelowych, które zostaną zmienione.

  2. Wybierz żądane miejsca źródłowei docelowe. Zazwyczaj obiektem docelowym jest miejsce produkcyjne. Ponadto wybierz karty Zmiany źródła i Zmiany docelowe i sprawdź, czy zmiany konfiguracji są oczekiwane. Po zakończeniu możesz natychmiast zamienić miejsca, wybierając pozycję Zamień.

    Kończenie zamiany

    Aby zobaczyć, jak miejsce docelowe zostanie uruchomione z nowymi ustawieniami przed rozpoczęciem zamiany, nie wybieraj opcji Zamień ,ale postępuj zgodnie z instrukcjami w temacie Zamiana z podglądem.

  3. Po zakończeniu zamknij okno dialogowe, wybierając pozycję Zamknij.

Jeśli masz problemy, zobacz Rozwiązywanie problemów z zamianami.

Zamiana z podglądem (zamiana wielofazowa)

Przed zamianą w środowisku produkcyjnym jako miejsce docelowe sprawdź, czy aplikacja działa z zamienione ustawienia. Miejsce źródłowe jest również rozgrzewowane przed zakończeniem zamiany, co jest pożądane w przypadku aplikacji o znaczeniu krytycznym.

Podczas zamiany z podglądem program App Service tę samą operację zamiany, ale jest wstrzymywany po pierwszym kroku. Następnie możesz sprawdzić wynik w miejscu przejściowym przed zakończeniem zamiany.

Jeśli anulujesz zamianę, App Service elementy konfiguracji do miejsca źródłowego.

Aby zamienić się z podglądem:

  1. Postępuj zgodnie z instrukcjami z tematu Zamiana miejsc wdrożenia, ale wybierz pozycję Wykonaj zamianę z podglądem.

    Zamiana z podglądem

    W oknie dialogowym pokazano, jak zmienia się konfiguracja w miejscu źródłowym w fazie 1 oraz jak zmienia się miejsce źródłowe i docelowe w fazie 2.

  2. Gdy wszystko będzie gotowe do rozpoczęcia zamiany, wybierz pozycję Rozpocznij zamianę.

    Po zakończeniu fazy 1 zostanie wyświetlone powiadomienie w oknie dialogowym. Wyświetl podgląd zamiany w miejscu źródłowym, przechodząc https://<app_name>-<source-slot-name>.azurewebsites.net do .

  3. Gdy wszystko będzie gotowe do ukończenia oczekującej zamiany, wybierz akcję Ukończ zamianę w zamian i wybierz pozycję Ukończ zamianę.

    Aby anulować oczekującą zamianę, wybierz zamiast tego pozycję Anuluj zamianę.

  4. Po zakończeniu zamknij okno dialogowe, wybierając pozycję Zamknij.

Jeśli masz problemy, zobacz Rozwiązywanie problemów z zamianami.

Aby zautomatyzować zamianę wielofazową, zobacz Automatyzowanie przy użyciu programu PowerShell.

Wycofywanie zamiany

Jeśli w miejscu docelowym (na przykład w miejscu produkcyjnym) wystąpią błędy po zamianie miejsca, przywróć miejsca do ich stanów przed zamianą, natychmiast zamieniając te same dwa miejsca.

Konfigurowanie zamiany automatycznej

Uwaga

Zamiana automatyczna nie jest obsługiwana w aplikacjach internetowych w systemie Linux i Web App for Containers.

Zamiana automatyczna Azure DevOps scenariuszach, w których chcesz stale wdrażać aplikację bez zimnych startów i zerowych przestojów dla klientów aplikacji. Gdy zamiana automatyczna jest włączona z miejsca do produkcji, za każdym razem, gdy wypychasz zmiany kodu do tego miejsca, program App Service automatycznie zamienia aplikację w środowisku produkcyjnym po rozgrzewce w miejscu źródłowym.

Uwaga

Przed skonfigurowaniem zamiany automatycznej dla miejsca produkcyjnego rozważ przetestowanie zamiany automatycznej w miejscu docelowym nieprodukcyjną.

Aby skonfigurować zamianę automatyczną:

  1. Przejdź do strony zasobów aplikacji. Wybierz pozycję Miejsca wdrożenia żądanego miejsca > źródłowego>>>>.

  2. W przypadku opcji Zamiana automatycznawłączona wybierz pozycję Wł.. Następnie wybierz żądane miejsce docelowe dla miejsca wdrożenia zamiany automatyczneji wybierz pozycję Zapisz na pasku poleceń.

    Opcje konfigurowania zamiany automatycznej

  3. Wykonaj wypychanie kodu do miejsca źródłowego. Zamiana automatyczna odbywa się po krótkim czasie, a aktualizacja jest odzwierciedlana pod adresem URL miejsca docelowego.

Jeśli masz jakiekolwiek problemy, zobacz Rozwiązywanie problemów z zamianami.

Określanie niestandardowej rozgrzewki

Niektóre aplikacje mogą wymagać niestandardowych akcji rozgrzewki przed zamianą. Element applicationInitialization konfiguracji w web.config umożliwia określenie niestandardowych akcji inicjowania. Operacja zamiany czeka na zakończenie tej niestandardowej rozgrzewki przed zamianą z miejsca docelowego. Oto przykładowy web.config fragment.

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

Aby uzyskać więcej informacji na temat dostosowywania elementu, zobacz Najczęściej spotykane błędy zamiany miejsca wdrożenia applicationInitializationapplicationInitialization

Można również dostosować zachowanie rozgrzewki przy użyciu jednego lub obu następujących ustawień aplikacji:

  • WEBSITE_SWAP_WARMUP_PING_PATH: ścieżka do polecenia ping za pośrednictwem protokołu HTTP w celu rozgrzewki witryny. Dodaj to ustawienie aplikacji, określając ścieżkę niestandardową, która rozpoczyna się od ukośnika jako wartości. Może to być na przykład /statuscheck. Wartość domyślna to /.
  • WEBSITE_SWAP_WARMUP_PING_STATUSES: prawidłowe kody odpowiedzi HTTP dla operacji rozgrzewki. Dodaj to ustawienie aplikacji z rozdzielaną przecinkami listą kodów HTTP. Na przykład: 200,202 . Jeśli zwróconego kodu stanu nie ma na liście, operacje rozgrzewki i wymiany zostaną zatrzymane. Domyślnie wszystkie kody odpowiedzi są prawidłowe.
  • WEBSITE_WARMUP_PATH: ścieżka względna w lokacji, która powinna być wysyłana za pomocą polecenia ping przy każdym ponownym uruchomieniu lokacji (nie tylko podczas zamiany miejsca). Przykładowe wartości /statuscheck to lub ścieżka główna, / .

Uwaga

Element konfiguracji jest częścią każdego uruchamiania aplikacji, natomiast dwa ustawienia aplikacji dotyczące zachowania rozgrzewki dotyczą <applicationInitialization> tylko zamiany miejsca.

Jeśli masz jakiekolwiek problemy, zobacz Rozwiązywanie problemów z zamianami.

Monitorowanie zamiany

Jeśli operacja zamiany zajmuje dużo czasu, możesz uzyskać informacje o operacji zamiany w dzienniku aktywności.

Na stronie zasobów aplikacji w portalu w okienku po lewej stronie wybierz pozycję Dziennik aktywności.

Operacja zamiany jest wyświetlana w zapytaniu dziennika jako Swap Web App Slots . Możesz go rozwinąć i wybrać jedną z podoperacji lub błędów, aby wyświetlić szczegóły.

Przekieruj ruch

Domyślnie wszystkie żądania klientów kierowane do produkcyjnego adresu URL aplikacji ( ) są http://<app_name>.azurewebsites.net kierowane do miejsca produkcyjnego. Część ruchu można przekierowyć do innego miejsca. Ta funkcja jest przydatna, jeśli potrzebujesz opinii użytkowników na temat nowej aktualizacji, ale nie możesz jeszcze jej wydać w środowisku produkcyjnym.

Automatyczne przekieruj ruch produkcyjny

Aby automatycznie rozsyłać ruch produkcyjny:

  1. Przejdź do strony zasobów aplikacji i wybierz pozycję Miejsca wdrożenia.

  2. W kolumnie Procent ruchu w miejscu, do którego chcesz przekierowyć trasę, określ wartość procentową (od 0 do 100) reprezentującą łączną ilość ruchu, który chcesz przekierowyć. Wybierz pozycję Zapisz.

    Ustawianie procentu ruchu

Po zapisaniu ustawienia określona wartość procentowa klientów jest losowo przekierowyowana do miejsca nieprodukcji.

Gdy klient zostanie automatycznie przekierowyowany do określonego miejsca, zostanie "przypięty" do tego miejsca na czas życia tej sesji klienta. W przeglądarce klienta możesz zobaczyć, do którego miejsca jest przypięta sesja, patrząc na x-ms-routing-name plik cookie w nagłówkach HTTP. Żądanie, które jest kierowane do miejsca "przejściowego", ma plik cookie x-ms-routing-name=staging . Żądanie, które jest kierowane do miejsca produkcyjnego, ma plik cookie x-ms-routing-name=self .

Uwaga

Możesz również użyć polecenia w interfejsie wiersza polecenia platformy Azure, aby ustawić wartości procentowe routingu z narzędzi ci/CD, takich jak GitHub Actions, DevOps potoki lub inne az webapp traffic-routing set systemy automatyzacji.

Ręczne przekieruj ruch produkcyjny

Oprócz automatycznego routingu ruchu usługa App Service kierowanie żądań do określonego miejsca. Jest to przydatne, gdy chcesz, aby użytkownicy mogli zrezygnować z aplikacji w wersji beta lub z nich zrezygnować. Aby ręcznie przekierowyć ruch produkcyjny, należy użyć x-ms-routing-name parametru zapytania.

Aby na przykład pozwolić użytkownikom zrezygnować z aplikacji w wersji beta, możesz umieścić ten link na stronie internetowej:

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

Ciąg określa x-ms-routing-name=self miejsce produkcyjne. Gdy przeglądarka klienta uzyskuje dostęp do linku, jest on przekierowywany do miejsca produkcyjnego. Każde kolejne żądanie ma plik cookie, który x-ms-routing-name=self przypina sesję do miejsca produkcyjnego.

Aby pozwolić użytkownikom na zgodę na aplikację w wersji beta, ustaw ten sam parametr zapytania na nazwę miejsca nieprodukcyjną. Oto przykład:

<webappname>.azurewebsites.net/?x-ms-routing-name=staging

Domyślnie nowe gniazda mają regułę rozsyłania o wartości 0% , wyświetlaną na szaro. Gdy jawnie ustawisz tę wartość na (pokazaną w czarnym tekście), użytkownicy mogą ręcznie uzyskać dostęp do miejsca przejściowego przy 0% użyciu x-ms-routing-name parametru zapytania. Nie będą one jednak automatycznie kierowane do miejsca, ponieważ wartość procentowa routingu jest ustawiona na 0. Jest to zaawansowany scenariusz, w którym można "ukryć" miejsce przejściowe przed publicznym, zezwalając zespołom wewnętrznym na testowanie zmian w miejscu.

Usuwanie miejsca

Wyszukaj i wybierz aplikację. Wybierz pozycję Miejsce miejsca wdrożenia, aby usunąć pozycję >>> Typ aplikacji jest wyświetlany jako App Service (miejsce), aby przypominać o wyświetlaniu miejsca wdrożenia. Wybierz pozycję Usuń na pasku poleceń.

Usuwanie miejsca wdrożenia

Automatyzacja przy użyciu programu PowerShell

Uwaga

W tym artykule jest używany moduł Azure Az programu PowerShell, który jest zalecanym modułem programu PowerShell do interakcji z platformą Azure. Aby rozpocząć pracę z modułem Azure PowerShell, zobacz Instalowanie programu Azure PowerShell. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.

Azure PowerShell to moduł, który udostępnia polecenia cmdlet do zarządzania platformą Azure za pośrednictwem usługi Windows PowerShell, w tym obsługę zarządzania miejscami wdrożenia w Azure App Service.

Aby uzyskać informacje na temat instalowania i konfigurowania Azure PowerShell oraz uwierzytelniania użytkowników Azure PowerShell subskrypcji platformy Azure, zobacz Jakzainstalować i skonfigurować Microsoft Azure PowerShell .