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

Artykuł
02/03/2023
Czas czytania: 17 min

Podczas wdrażania aplikacji internetowej, aplikacji internetowej w systemie Linux, zapleczu dla urządzeń przenośnych lub aplikacji interfejsu API w celu Azure App Service można użyć oddzielnego miejsca wdrożenia zamiast domyślnego miejsca produkcyjnego w warstwie Standardowa, Premium lub Izolowanej App Service planu. Miejsca wdrożenia to aplikacje na żywo z własnymi nazwami hostów. Zawartość aplikacji i elementy konfiguracji można zamienić między dwa miejsca wdrożenia, w tym miejsce produkcyjne.

Wdrażanie aplikacji w miejscu nieprodukcyjnym 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ą usuwane z powodu operacji wymiany. Cały przepływ pracy można zautomatyzować, konfigurując zamianę automatyczną , gdy walidacja przed zamianą nie jest potrzebna.
Po zamianie miejsce z wcześniej przygotowanymi aplikacjami ma teraz poprzednią aplikację produkcyjną. Jeśli zmiany zamienione na miejsce produkcyjne nie są zgodnie z oczekiwaniami, możesz wykonać tę samą zamianę natychmiast, aby odzyskać "ostatnią znaną dobrą witrynę".

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

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 skalować jej w dół do warstwy Standardowa , ponieważ warstwa Standardowa obsługuje tylko pięć miejsc wdrożenia.

Dodawanie miejsca

Aplikacja musi być uruchomiona w warstwie Standardowa, Premium lub Izolowana , aby umożliwić włączenie wielu miejsc wdrożenia.

w Azure Portal wyszukaj i wybierz pozycję App Services, a następnie wybierz aplikację.
W okienku po lewej stronie wybierz pozycję Miejsca> wdrożeniaDodaj miejsce.

Uwaga

Jeśli aplikacja nie znajduje się jeszcze w warstwie Standardowa, Premium lub Izolowana , zostanie wyświetlony komunikat wskazujący obsługiwane warstwy umożliwiające publikowanie etapowe. Na tym etapie możesz wybrać pozycję Uaktualnij i przejść do karty Skalowanie aplikacji przed kontynuowaniem.
W oknie dialogowym Dodawanie miejsca podaj nazwę miejsca i wybierz, czy sklonować konfigurację aplikacji z innego miejsca wdrożenia. Wybierz pozycję Dodaj , aby kontynuować.

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ę HTTP i bitness platformy.

Uwaga

Obecnie prywatny punkt końcowy nie jest klonowany między miejscami.

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 klienta kierowany do miejsca produkcyjnego.
Wybierz nowe miejsce wdrożenia, aby otworzyć stronę zasobu tego miejsca.

Miejsce przejściowe ma stronę zarządzania tak samo jak każda inna aplikacja App Service. Konfigurację miejsca można zmienić. Aby przypomnieć, że wyświetlasz miejsce wdrożenia, nazwa aplikacji jest wyświetlana jako <nazwa> aplikacji/<nazwa-miejsca>, a typ aplikacji to App Service (miejsce). Możesz również zobaczyć miejsce jako oddzielną aplikację w grupie zasobów z tymi samymi oznaczeniami.
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ć publiczny dostęp do miejsca wdrożenia, zobacz Azure App Service ograniczenia adresów IP.

Nowe miejsce wdrożenia nie ma zawartości, nawet jeśli sklonujesz ustawienia z innego miejsca. Na przykład możesz opublikować je w tym miejscu za pomocą usługi Git. Wdrożenie w miejscu można wdrożyć z innej gałęzi repozytorium lub innego repozytorium. Pobieranie profilu publikowania z Azure App Service może dostarczyć wymagane informacje do wdrożenia w miejscu. Profil można zaimportować przez program Visual Studio, aby wdrożyć zawartość w miejscu.

Adres URL miejsca będzie mieć format http://sitename-slotname.azurewebsites.net. Aby zachować długość adresu URL w ramach niezbędnych limitów DNS, nazwa witryny zostanie obcięta na 40 znaków, nazwa miejsca zostanie obcięta na 19 znaków, a dodatkowe 4 losowe znaki zostaną dołączone, aby upewnić się, że wynikowa nazwa domeny jest unikatowa.

Co się dzieje podczas zamiany

Kroki operacji zamiany

W przypadku zamiany dwóch miejsc (zwykle z miejsca przejściowego do miejsca produkcyjnego) App Service wykonuje następujące czynności, aby upewnić się, że miejsce docelowe nie ma przestoju:

Zastosuj następujące ustawienia z miejsca docelowego (na przykład miejsce produkcyjne) do wszystkich wystąpień miejsca źródłowego:
- Ustawienia aplikacji specyficzne dla miejsca i parametry połączenia, jeśli ma to zastosowanie.
- Ustawienia ciągłego wdrażania , jeśli jest włączone.
- App Service ustawienia uwierzytelniania, jeśli jest włączone.
Każdy z tych przypadków wyzwala wszystkie wystąpienia w miejscu źródłowym w celu ponownego uruchomienia. Podczas zamiany z podglądem oznacza 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.
Poczekaj na ukończenie ponownego uruchomienia każdego wystąpienia w miejscu źródłowym. Jeśli jakiekolwiek wystąpienie nie powiedzie się ponownie, operacja zamiany przywraca wszystkie zmiany w miejscu źródłowym i zatrzymuje operację.
Jeśli włączono lokalną pamięć podręczną , wyzwól inicjowanie lokalnej pamięci podręcznej, wysyłając żądanie HTTP do katalogu głównego aplikacji ("/") w każdym wystąpieniu miejsca źródłowego. Zaczekaj, aż każde wystąpienie zwróci dowolną odpowiedź HTTP. Inicjowanie lokalnej pamięci podręcznej powoduje ponowne uruchomienie każdego wystąpienia.
Jeśli zamiana automatyczna jest włączona z niestandardowym rozgrzewkiem, wyzwalaj inicjowanie aplikacji , wysyłając żądanie HTTP do katalogu głównego aplikacji ("/") w każdym wystąpieniu miejsca źródłowego.

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

Jeśli wystąpienie zwraca dowolną odpowiedź HTTP, uważa się, że jest rozgrzane.
Jeśli wszystkie wystąpienia w miejscu źródłowym zostaną pomyślnie rozgrzane, zamień dwa miejsca, przełączając reguły routingu dla dwóch miejsc. Po wykonaniu tego kroku miejsce docelowe (na przykład miejsce produkcyjne) zawiera aplikację, która została wcześniej rozgrzana w miejscu źródłowym.
Teraz, gdy miejsce źródłowe ma 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 wymiany wszystkie prace inicjowania zamienione aplikacje odbywają się w miejscu źródłowym. Miejsce docelowe pozostaje w trybie online, gdy miejsce źródłowe jest przygotowane i rozgrzane, niezależnie od tego, gdzie wymiana się powiedzie lub zakończy się niepowodzeniem. Aby zamienić miejsce przejściowe z miejscem produkcyjnym, 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 poprzednich wystąpieniach produkcyjnych (te, które zostaną zamienione na przejściowe po tej operacji zamiany) zostaną szybko poddane recyklingu w ostatnim kroku procesu wymiany. W przypadku, gdy masz długotrwałe operacje w aplikacji, zostaną one porzucone, gdy pracownicy będą odzyskiwane. Dotyczy to również aplikacji funkcji. W związku z tym kod aplikacji powinien być napisany w sposób odporny na uszkodzenia.

Które ustawienia są zamieniane?

Podczas klonowania konfiguracji z innego miejsca wdrożenia sklonowana konfiguracja jest edytowalna. Niektóre elementy konfiguracji są zgodne z zawartością zamiany (nie 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 zamienione:

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

Funkcje oznaczone gwiazdką (*) są planowane jako niezamapowane.

Ustawienia, które nie są zamieniane:

Publikowanie punktów końcowych
Niestandardowe nazwy domen
Certyfikaty inne niż publiczne 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ńczące się sufiksem _EXTENSION_VERSION

Uwaga

Aby zmienić wyżej wymienione ustawienia, dodaj ustawienie WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS aplikacji w każdym miejscu aplikacji i ustaw jej wartość na 0 lub false. Te ustawienia są możliwe do zamiany lub w ogóle nie. Nie można zmienić tylko niektórych ustawień, a nie innych. Tożsamości zarządzane nigdy nie są zamieniane i nie mają wpływu na to ustawienie zastępowania aplikacji.

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

Aby skonfigurować ustawienie aplikacji lub parametry połączenia, aby trzymać się określonego miejsca (nie zamienione), przejdź do strony Konfiguracja dla tego miejsca. Dodaj lub edytuj ustawienie, a następnie wybierz ustawienie miejsca wdrożenia. Zaznaczenie tego pola wyboru informuje App Service, że ustawienie nie jest możliwe do zamiany.

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 miejsc, zobacz Co się dzieje podczas zamiany.

Ważne

Przed zamianą aplikacji z miejsca wdrożenia do środowiska produkcyjnego upewnij się, że środowisko produkcyjne jest miejscem docelowym i że wszystkie ustawienia w miejscu źródłowym są skonfigurowane dokładnie tak, jak chcesz, aby miały je w środowisku produkcyjnym.

Aby zamienić miejsca wdrożenia:

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

Okno dialogowe Zamiana zawiera ustawienia w wybranych miejscach źródłowych i docelowych, które zostaną zmienione.
Wybierz żądane miejsca źródłowe i docelowe . Zazwyczaj miejscem docelowym jest miejsce produkcyjne. Ponadto wybierz karty Zmiany źródłowe i Zmiany docelowe i sprawdź, czy zmiany konfiguracji są oczekiwane. Po zakończeniu możesz natychmiast zamienić miejsca, wybierając pozycję Zamień.

Aby zobaczyć, jak zostanie uruchomione miejsce docelowe z nowymi ustawieniami przed rzeczywistym wykonaniem zamiany, nie wybieraj opcji Zamień, ale postępuj zgodnie z instrukcjami w sekcji Zamiana z podglądem.
Po zakończeniu zamknij okno dialogowe, wybierając pozycję Zamknij.

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

Zamiana z podglądem (zamiana wielofazowa)

Przed zamianą na środowisko produkcyjne jako miejsce docelowe zweryfikuj, czy aplikacja działa z zamienionymi ustawieniami. Gniazdo źródłowe jest również rozgrzane przed zakończeniem zamiany, co jest pożądane w przypadku aplikacji o znaczeniu krytycznym.

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

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

Uwaga

Zamiany z podglądem nie można używać, gdy jeden z miejsc ma włączone uwierzytelnianie witryny.

Aby zamienić podgląd:

Wykonaj kroki opisane w temacie Zamiana miejsc wdrożenia , ale wybierz pozycję Wykonaj zamianę przy użyciu wersji zapoznawczej.

W oknie dialogowym pokazano, jak konfiguracja w miejscu źródłowym zmienia się w fazie 1 oraz jak zmienia się miejsce źródłowe i docelowe w fazie 2.
Gdy wszystko będzie gotowe do rozpoczęcia zamiany, wybierz pozycję Rozpocznij zamianę.

Po zakończeniu fazy 1 otrzymasz powiadomienie w oknie dialogowym. Wyświetl podgląd zamiany w miejscu źródłowym, przechodząc do .https://<app_name>-<source-slot-name>.azurewebsites.net
Gdy wszystko będzie gotowe do ukończenia oczekującej zamiany, wybierz pozycję Ukończ zamianę w akcji Zamiana i wybierz pozycję Zakończ zamianę.

Aby anulować oczekującą zamianę, wybierz pozycję Anuluj zamianę .
Po zakończeniu zamknij okno dialogowe, wybierając pozycję Zamknij.

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

Aby zautomatyzować zamianę wielofazową, zobacz Automatyzowanie za pomocą programu PowerShell.

Wycofywanie zamiany

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

Konfigurowanie zamiany automatycznej

Uwaga

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

Zamiana automatyczna usprawnia scenariusze usługi Azure DevOps, w których chcesz stale wdrażać aplikację przy zerowych zimnych startach i zerowym przestoju dla klientów aplikacji. Gdy zamiana automatyczna jest włączona z miejsca do środowiska produkcyjnego, za każdym razem, gdy wypchniesz zmiany kodu do tego miejsca, App Service automatycznie zamienia aplikację w środowisko produkcyjne po rozgrzaniu w miejscu źródłowym.

Uwaga

Przed skonfigurowaniem zamiany automatycznej dla miejsca produkcyjnego rozważ przetestowanie zamiany automatycznej na miejscu docelowym nieprodukcyjnym.

Aby skonfigurować zamianę automatyczną:

Przejdź do strony zasobów aplikacji. Wybierzpozycję Ustawienia ogólne konfiguracji miejsc wdrożenia<żądanego miejsca>>> źródłowego.>
W obszarze Włączono zamianę automatyczną wybierz pozycję Włączone. Następnie wybierz odpowiednie miejsce docelowe dla miejsca wdrożenia zamiany automatycznej, a następnie wybierz pozycję Zapisz na pasku poleceń.
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 rozgrzewania przed zamianą. Element applicationInitialization konfiguracji w programie web.config umożliwia określenie niestandardowych akcji inicjowania. Operacja zamiany czeka na zakończenie tej niestandardowej rozgrzewki przed zamianą z miejscem docelowym. Oto przykładowy fragment web.config.

<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 applicationInitialization elementu, zobacz Najczęstsze błędy zamiany miejsca wdrożenia i sposoby ich naprawiania.

Możesz 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 rozgrzania witryny. Dodaj to ustawienie aplikacji, określając ścieżkę niestandardową rozpoczynającą się ukośnikiem 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. Przykładem jest .200,202 Jeśli zwrócony kod stanu nie znajduje się na liście, operacje rozgrzewki i zamiany 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 każdym razem, gdy lokacja zostanie uruchomiona ponownie (nie tylko podczas zamiany miejsca). Przykładowe wartości to /statuscheck lub ścieżka główna . /

Uwaga

Element <applicationInitialization> konfiguracji jest częścią uruchamiania każdej aplikacji, podczas gdy dwa ustawienia aplikacji zachowania rozgrzewki mają zastosowanie tylko do zamiany miejsc.

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

Monitorowanie zamiany

Jeśli operacja zamiany trwa długo, możesz uzyskać informacje na temat operacji zamiany w dzienniku aktywności.

Na stronie zasobu 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 ją rozwinąć i wybrać jedną z podoperacji lub błędów, aby wyświetlić szczegóły.

Kierowanie ruchu

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

Kierowanie ruchu produkcyjnego automatycznie

Aby automatycznie kierować ruch produkcyjny:

Przejdź do strony zasobu aplikacji i wybierz pozycję Miejsca wdrożenia.
W kolumnie Traffic % miejsca, do którego chcesz kierować, określ wartość procentową (od 0 do 100) reprezentującą łączną liczbę ruchu, do którego chcesz kierować. Wybierz pozycję Zapisz.

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

Gdy klient jest automatycznie kierowany do określonego miejsca, jest "przypięty" do tego miejsca przez jedną godzinę lub do momentu usunięcia plików cookie. W przeglądarce klienta możesz zobaczyć miejsce przypięte do sesji, przeglądając x-ms-routing-name plik cookie w nagłówkach HTTP. Żądanie kierowane do miejsca przejściowego zawiera plik cookie x-ms-routing-name=staging. Żądanie kierowane do miejsca produkcyjnego zawiera plik cookie x-ms-routing-name=self.

Uwaga

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

Ręczne kierowanie ruchu produkcyjnego

Oprócz automatycznego routingu ruchu App Service może kierować żądania do określonego miejsca. Jest to przydatne, gdy chcesz, aby użytkownicy mogli wyrazić zgodę na korzystanie z aplikacji beta lub zrezygnować z tej aplikacji. Aby ręcznie kierować ruch produkcyjny, należy użyć parametru x-ms-routing-name zapytania.

Aby umożliwić użytkownikom rezygnację z aplikacji beta, możesz na przykład 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 x-ms-routing-name=self określa miejsce produkcyjne. Gdy przeglądarka kliencka uzyskuje dostęp do linku, zostanie przekierowana do miejsca produkcyjnego. Każde kolejne żądanie zawiera x-ms-routing-name=self plik cookie, który przypina sesję do miejsca produkcyjnego.

Aby zezwolić użytkownikom na korzystanie z aplikacji beta, ustaw ten sam parametr zapytania na nazwę miejsca nieprodukcyjnego. Oto przykład:

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

Domyślnie nowe miejsca mają regułę rozsyłania , 0%która jest wyświetlana w kolorze szarym. Po jawnym ustawieniu tej wartości na 0% (pokazanej w czarnym tekście) użytkownicy będą mogli ręcznie uzyskać dostęp do miejsca przejściowego przy użyciu parametru x-ms-routing-name zapytania. Ale nie będą one kierowane do miejsca automatycznie, ponieważ wartość procentowa routingu jest ustawiona na 0. Jest to zaawansowany scenariusz, w którym można "ukryć" miejsce przejściowe od społeczeństwa, umożliwiając zespołom wewnętrznym testowanie zmian w miejscu.

Usuwanie miejsca

Wyszukaj i wybierz aplikację. Wybierz pozycję Miejsce miejsc><wdrożenia, aby usunąć>>przegląd. Typ aplikacji jest wyświetlany jako App Service (miejsce), aby przypomnieć, że wyświetlasz miejsce wdrożenia. Przed usunięciem gniazda upewnij się, że zatrzymaj miejsce i ustaw ruch w miejscu na zero. Wybierz pozycję Usuń na pasku poleceń.

Usuwanie miejsca wdrożenia

Automatyzacja przy użyciu programu PowerShell

Uwaga

Zalecamy korzystanie z modułu Azure Az programu PowerShell do interakcji z platformą Azure. Zobacz Instalowanie programu Azure PowerShell, aby rozpocząć. 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 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 Azure PowerShell przy użyciu subskrypcji platformy Azure, zobacz Jak zainstalować i skonfigurować Microsoft Azure PowerShell.

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ą podglądu (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 zamiany oczekującej (zamiana z recenzją) 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ń wymiany 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

Aby przeprowadzić zamianę miejsca z miejsca produkcyjnego, tożsamość wymaga uprawnień (co najmniej) do wykonania Microsoft.Web/sites/slotsswap/Action operacji. Aby uzyskać więcej informacji, zobacz Operacje dostawcy zasobów

Automatyzowanie za pomocą szablonów Resource Manager

Szablony usługi Azure Resource Manager to deklaratywne pliki JSON używane do automatyzowania wdrażania i konfiguracji zasobów platformy Azure. Aby zamienić miejsca przy użyciu szablonów Resource Manager, należy ustawić 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, jakie buildVersion miejsce powinno mieć miejsce. Jeśli element targetBuildVersion nie jest równy bieżącemu buildVersion, spowoduje to wyzwolenie operacji zamiany przez znalezienie miejsca, które ma określony buildVersionelement .

Przykładowy szablon Resource Manager

Poniższy szablon Resource Manager zaktualizuje buildVersion miejsce przejściowe i ustawi targetBuildVersion element w miejscu produkcyjnym. Spowoduje to zamianę dwóch miejsc. Szablon zakłada, że masz już aplikację internetową utworzoną z miejscem o nazwie "przejściowe".

{
    "$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 szablon Resource Manager jest idempotentny, co oznacza, że można go wykonać wielokrotnie i utworzyć ten sam stan miejsc. Po pierwszym wykonaniu targetBuildVersion będzie zgodna z bieżącym buildVersionelementem , więc zamiana nie zostanie wyzwolona.

Automatyzowanie za pomocą interfejsu wiersza polecenia

W przypadku poleceń 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, jest on zalogowany D:\home\LogFiles\eventlog.xml. Jest on również zalogowany w dzienniku błędów specyficznym dla aplikacji.

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

Czas żądania HTTP do katalogu głównego aplikacji. Operacja zamiany czeka na 90 sekund dla każdego żądania HTTP i ponawia próbę do 5 razy. Jeśli upłynął limit czasu wszystkich ponownych prób, operacja zamiany zostanie zatrzymana.
Inicjowanie lokalnej pamięci podręcznej może zakończyć się niepowodzeniem, gdy zawartość aplikacji przekroczy limit przydziału dysku lokalnego określonego dla lokalnej pamięci podręcznej. Aby uzyskać więcej informacji, zobacz Omówienie lokalnej pamięci podręcznej.
Podczas niestandardowego rozgrzewania żądania HTTP są wykonywane wewnętrznie (bez przechodzenia przez zewnętrzny adres URL). Mogą one zakończyć się niepowodzeniem z pewnymi regułami ponownego zapisywania adresów URL w Web.config. Na przykład reguły przekierowywania nazw domen lub wymuszania protokołu HTTPS mogą uniemożliwić uzyskiwanie dostępu do kodu aplikacji przez żądania rozgrzewki. Aby obejść ten problem, zmodyfikuj reguły ponownego zapisywania, 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 zapisywania adresów URL mogą nadal blokować żądania HTTP. Aby obejść ten problem, zmodyfikuj reguły ponownego zapisywania, dodając następujący warunek:
```
<conditions>
  <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  ...
</conditions>
```
Po zamianie miejsca aplikacja może napotkać nieoczekiwane ponowne uruchomienie. Dzieje się tak dlatego, że po zamianie konfiguracja powiązania nazwy hosta nie zostanie zsynchronizowana, co samo w sobie nie powoduje ponownego uruchomienia. Jednak niektóre podstawowe zdarzenia magazynu (takie jak tryb failover woluminu magazynu) mogą wykryć te rozbieżności i wymusić ponowne uruchomienie wszystkich procesów roboczych. Aby zminimalizować te typy ponownych uruchomień, ustaw WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 ustawienie aplikacji na wszystkich miejscach. Jednak to ustawienie aplikacji nie działa z aplikacjami windows Communication Foundation (WCF).

Następne kroki

Blokuj dostęp do miejsc nieprodukcyjnych

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

Dodawanie miejsca

Co się dzieje podczas zamiany

Kroki operacji zamiany

Które ustawienia są zamieniane?

Zamiana dwóch miejsc

Zamiana z podglądem (zamiana wielofazowa)

Wycofywanie zamiany

Konfigurowanie zamiany automatycznej

Określanie niestandardowej rozgrzewki

Monitorowanie zamiany

Kierowanie ruchu

Kierowanie ruchu produkcyjnego automatycznie

Ręczne kierowanie ruchu produkcyjnego

Usuwanie miejsca

Automatyzacja przy użyciu programu PowerShell

Tworzenie aplikacji internetowej

Tworzenie miejsca

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

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

Zamiana miejsc wdrożenia

Monitorowanie zdarzeń wymiany w dzienniku aktywności

Usuwanie miejsca

Automatyzowanie za pomocą szablonów Resource Manager

Przykładowy szablon Resource Manager

Automatyzowanie za pomocą interfejsu wiersza polecenia

Rozwiązywanie problemów z zamianami

Następne kroki

Dodatkowe zasoby

Dodatkowe zasoby