Konfigurowanie środowisk przejściowych w usłudze Azure App Service
Uwaga
Od 1 czerwca 2024 r. nowo utworzone aplikacje usługi App Service mogą wygenerować unikatową domyślną nazwę hosta, która używa konwencji <app-name>-<random-hash>.<region>.azurewebsites.netnazewnictwa . Istniejące nazwy aplikacji pozostają niezmienione. Na przykład:
myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Aby uzyskać więcej informacji, zobacz Unikatowa domyślna nazwa hosta zasobu usługi App Service.
Podczas wdrażania aplikacji internetowej, aplikacji internetowej w systemie Linux, zapleczu mobilnym lub aplikacji interfejsu API w usłudze aplikacja systemu Azure można użyć oddzielnego miejsca wdrożenia zamiast domyślnego miejsca produkcyjnego. Takie podejście jest dostępne w przypadku uruchamiania w warstwie Plan usługi App Service w warstwie Standardowa, Premium lub Izolowana . Miejsca wdrożenia to aplikacje na żywo z własnymi nazwami hostów. Zawartość aplikacji oraz elementy konfiguracji można wymieniać między 2 miejscami wdrożenia, w tym także miejscem produkcyjnym.
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.
- Najpierw wdrożenie aplikacji w miejscu i zamiana jej w środowisku produkcyjnym gwarantuje, że wszystkie wystąpienia miejsca są rozgrzane przed zamianą jej na środowisko produkcyjne. Takie podejście eliminuje przestoje podczas wdrażania aplikacji. Przekierowywanie ruchu jest bezproblemowe. Żadne żądania nie są usuwane z powodu operacji zamiany. Cały przepływ pracy można zautomatyzować, konfigurując zamianę automatyczną, gdy walidacja przed zamianą nie jest wymagana.
- 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 przywrócić ostatnią znaną dobrą witrynę .
Każda warstwa planu usługi 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 Limity usługi App Service.
Aby skalować aplikację do innej warstwy, upewnij się, że warstwa docelowa obsługuje już liczbę miejsc używanych przez aplikację. Jeśli na przykład aplikacja ma więcej niż pięć miejsc, nie można skalować jej w dół do warstwy Standardowa . Warstwa Standardowa obsługuje tylko pięć miejsc wdrożenia.
W tym filmie wideo pokazano, jak skonfigurować środowiska przejściowe w usłudze aplikacja systemu Azure Service.
Kroki opisane w filmie wideo zostały również opisane w poniższych sekcjach.
Wymagania wstępne
- Aby uzyskać informacje na temat uprawnień potrzebnych do wykonania żądanej operacji miejsca, zobacz Operacje dostawcy zasobów. Wyszukaj na przykład miejsce.
Dodawanie miejsca
Aby można było włączyć wiele miejsc wdrożenia, aplikacja musi być uruchomiona w warstwie Standardowa, Premium lub Izolowana .
W witrynie Azure Portal przejdź do strony zarządzania aplikacją.
W okienku po lewej stronie wybierz pozycję Miejsca wdrożenia>>Dodaj.
Uwaga
Jeśli aplikacja nie znajduje się jeszcze w warstwie Standardowa, Premium lub Izolowana , wybierz pozycję Uaktualnij. Przed kontynuowaniem przejdź do karty Skalowanie aplikacji.
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ę protokołu HTTP i bitness platformy.
Uwaga
Obecnie prywatny punkt końcowy nie jest klonowany między miejscami.
Po wprowadzeniu ustawień 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 podobnie jak każda inna aplikacja usługi App Service. Możesz zmienić konfigurację miejsca. Aby przypomnieć, że wyświetlasz miejsce wdrożenia, nazwa aplikacji jest wyświetlana jako nazwa aplikacji/<nazwa-miejsca>.>< Typ aplikacji to App Service (miejsce). Miejsce można również zobaczyć 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 aplikacja systemu Azure Ograniczenia adresów IP usługi.
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. Możesz wdrożyć w miejscu z innej gałęzi repozytorium lub innego repozytorium. Pobieranie profilu publikowania z usługi aplikacja systemu Azure może dostarczyć wymagane informacje do wdrożenia w miejscu. Program Visual Studio może zaimportować profil, aby wdrożyć zawartość w miejscu.
Adres URL miejsca ma format http://sitename-slotname.azurewebsites.net. Aby zachować długość adresu URL w ramach niezbędnych limitów DNS, nazwa witryny jest obcięta na 40 znaków. Nazwa połączonej witryny i nazwa miejsca muszą mieć mniej niż 59 znaków.
Co się dzieje podczas zamiany
Kroki operacji zamiany
Podczas zamiany dwóch miejsc usługa 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 miejsca produkcyjnego) 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 są włączone.
- Ustawienia uwierzytelniania usługi App Service, jeśli są włączone.
Po zastosowaniu dowolnego z ustawień do miejsca źródłowego zmiana wyzwala wszystkie wystąpienia w miejscu źródłowym w celu ponownego uruchomienia. Podczas zamiany z podglądem ta akcja oznacza koniec pierwszej fazy. Operacja zamiany jest wstrzymana. Możesz 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 nie można ponownie uruchomić jakiegokolwiek wystąpienia, operacja zamiany przywraca wszystkie zmiany w miejscu źródłowym i zatrzymuje operację.
Jeśli lokalna pamięć podręczna jest włączona, 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. Poczekaj, 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 automatyczna zamiana jest włączona z niestandardowym rozgrzewkiem, wyzwól niestandardową inicjację aplikacji w każdym wystąpieniu miejsca źródłowego.
Jeśli
applicationInitializationnie 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 zamiany wszystkie prace inicjowania zamienione aplikacje odbywają się w miejscu źródłowym. Miejsce docelowe pozostaje w trybie online, gdy miejsce źródłowe jest przygotowywane i rozgrzewane, niezależnie od tego, czy zamiana zakończy się powodzeniem, czy 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
Poprzednie wystąpienia produkcyjne są zamieniane na przejściowe po wykonaniu tej operacji zamiany. Te wystąpienia są przetwarzane w ostatnim kroku procesu wymiany. W przypadku, gdy masz długotrwałe operacje w aplikacji, są one porzucone, gdy procesy robocze są odzyskiwane. Ten fakt dotyczy 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). 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:
- Stos językowy i wersja, 32/64-bitowa
- Ustawienia aplikacji (można skonfigurować tak, aby trzymały się miejsca)
- Parametry połączenia (można skonfigurować do trzymania się gniazda)
- Zainstalowane konta magazynu (można skonfigurować tak, aby trzymały się miejsca)
- Mapowania programu obsługi
- Certyfikaty publiczne
- Zawartość zadań WebJob
- Połączenia hybrydowe *
- Punkty końcowe usługi *
- Azure Content Delivery Network *
- Mapowania ścieżki
Funkcje oznaczone gwiazdką (*) mają zostać rozpakowane.
Ustawienia, które nie są zamieniane:
- Ustawienia ogólne, które nie zostały wymienione w ustawieniach, które są zamieniane
- Publikowanie punktów końcowych
- Niestandardowe nazwy domen
- Certyfikaty niepublicowe i ustawienia protokołu TLS/SSL
- Ustawienia skalowania
- Harmonogramy zadań WebJob
- Ograniczenia adresów IP
- Stały dostęp do usługi
- Ustawienia diagnostyczne
- Współużytkowanie zasobów między źródłami (CORS)
- Integracja sieci wirtualnej
- Tożsamości zarządzane i powiązane ustawienia
- Ustawienia kończące się sufiksem _EXTENSION_VERSION
- Ustawienia utworzone przez łącznik usługi
Uwaga
Aby zmienić 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. To ustawienie przesłaniania aplikacji nie ma wpływu na te ustawienia.
Niektóre ustawienia aplikacji, które mają zastosowanie do niezmapowanych 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 trzymać się określonego miejsca, które nie zostało zamienione, przejdź do strony Ustawienia>Zmienne środowiskowe dla tego miejsca. Dodaj lub edytuj ustawienie, a następnie wybierz pozycję Ustawienie miejsca wdrożenia. Wybranie tej opcji informuje usługę App Service, że ustawienie nie jest możliwe do zamiany.
Zamiana dwóch miejsc
Miejsca wdrożenia można zamienić na stronie Miejsca wdrożenia aplikacji i na stronie Przegląd. Aby uzyskać więcej informacji na temat zamiany miejsca, 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 je mieć w środowisku produkcyjnym.
Aby zamienić miejsca wdrożenia:
Przejdź do strony Miejsca wdrożenia aplikacji i wybierz pozycję Zamień.
W oknie dialogowym Zamiana są wyświetlane ustawienia w wybranym źródle i miejscach docelowych, które mają zostać zmienione.
Wybierz żądane miejsca źródła i miejsca docelowe . Zazwyczaj miejscem docelowym jest miejsce produkcyjne. Ponadto wybierz kartę 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ń.
Aby zobaczyć, jak będzie działać miejsce docelowe z nowymi ustawieniami przed rzeczywistym wykonaniem zamiany, nie wybieraj opcji Zamień, ale postępuj zgodnie z instrukcjami w obszarze Zamiana z podglądem.
Po zakończeniu wybierz pozycję Zamknij , aby zamknąć okno dialogowe.
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 sprawdź, czy aplikacja działa z zamienione ustawieniami. Miejsce źródłowe jest również rozgrzewane przed zakończeniem zamiany, co jest pożądane w przypadku aplikacji o krytycznym znaczeniu.
Podczas zamiany za pomocą wersji zapoznawczej usługa 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.
W przypadku anulowania zamiany usługa App Service ponownie zbiera elementy konfiguracji do miejsca źródłowego.
Uwaga
Zamiana z podglądem nie może być używana, gdy jeden z miejsc ma włączone uwierzytelnianie lokacji.
Aby zamienić wersję zapoznawcza:
Wykonaj kroki opisane w temacie Zamiana miejsc wdrożenia, ale wybierz pozycję Wykonaj zamianę z wersją zapoznawcza.
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 zostanie wyświetlone okno dialogowe z powiadomieniem. Wyświetl podgląd zamiany w miejscu źródłowym, przechodząc do .
https://<app_name>-<source-slot-name>.azurewebsites.netGdy wszystko będzie gotowe do ukończenia oczekującej zamiany, wybierz pozycję Ukończ zamianę w akcji Zamień i wybierz pozycję Ukończ zamianę.
Aby anulować oczekującą zamianę, wybierz pozycję Anuluj zamianę , a następnie wybierz pozycję Anuluj zamianę u dołu.
Po zakończeniu wybierz pozycję Zamknij , aby zamknąć okno dialogowe.
Jeśli masz jakiekolwiek problemy, zobacz Rozwiązywanie problemów z zamianami.
Wycofywanie zamiany
Jeśli jakiekolwiek błędy wystąpią w miejscu docelowym (na przykład w miejscu produkcyjnym) po zamianie miejsca, przywróć miejsca do 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ę z zerowym uruchamianiem zimnym i zerowym przestojem dla klientów aplikacji. Po włączeniu zamiany automatycznej z miejsca na środowisko produkcyjne za każdym razem, gdy wypchniesz zmiany kodu do tego miejsca, usługa 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. Wybierz pozycję Miejsca wdrożenia><>wybrane miejsce> źródłowe.
W okienku po lewej stronie wybierz pozycję Ustawienia>Ustawienia>Ogólne ustawienia.
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ń.
Uruchom wypchnięcie kodu do miejsca źródłowego. Zamiana automatyczna odbywa się po krótkim czasie. Aktualizacja jest odzwierciedlana pod adresem URL miejsca docelowego.
Jeśli masz jakiekolwiek problemy, zobacz Rozwiązywanie problemów z zamianami.
Określ niestandardową rozgrzewkę
Niektóre aplikacje mogą wymagać niestandardowych akcji rozgrzewki przed zamianą. Element applicationInitialization konfiguracji w pliku 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 pliku 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 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ę od ukośnika jako wartości. Może to być na przykład/statuscheck. Domyślna wartość 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. Może to być na przykład200,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 ponownie uruchomiona (nie tylko podczas zamian miejsca). Przykładowe wartości to/statuschecklub ścieżka główna,/.
Uwaga
Element <applicationInitialization> konfiguracji jest częścią każdego uruchamiania aplikacji, podczas gdy ustawienia aplikacji rozgrzewki mają zastosowanie tylko do zamian 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 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 ją rozwinąć i wybrać jedną z podoperacji lub błędów, aby wyświetlić szczegóły.
Automatyczne kierowanie ruchu produkcyjnego
Domyślnie wszystkie żądania klientów do adresu URL produkcyjnego 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.
Aby automatycznie kierować ruch produkcyjny:
Przejdź do strony zasobu aplikacji internetowej i wybierz pozycję Miejsca wdrożenia.
W kolumnie Traffic % miejsca, do którego chcesz kierować, określ wartość procentową (od 0 do 100), która będzie reprezentować łą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 zostanie automatycznie przekierowany do określonego miejsca, zostanie przypięty do tego miejsca przez jedną godzinę lub do momentu usunięcia plików cookie. W przeglądarce klienta możesz zobaczyć, do którego miejsca sesji jest przypięta, 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.
Ręczne kierowanie ruchu produkcyjnego
Oprócz automatycznego routingu ruchu usługa App Service może kierować żądania do określonego miejsca. Ta opcja jest przydatna, 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 zezwolić użytkownikom na 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>
x-ms-routing-name=self Ciąg określa miejsce produkcyjne. Gdy przeglądarka kliencka uzyskuje dostęp do linku, nastąpi przekierowanie 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 elementu 0%, wyświetlaną 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. Nie będą one automatycznie kierowane do miejsca, ponieważ wartość procentowa routingu jest ustawiona na 0. Ta konfiguracja jest zaawansowanym scenariuszem, w którym można ukryć miejsce przejściowe publicznie, 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 miejsca upewnij się, że zatrzymasz miejsce i ustaw ruch w miejscu na zero. Wybierz pozycję Usuń na pasku poleceń.
Automatyzowanie za pomocą szablonów usługi Resource Manager
Szablony usługi Azure Resource Manager to deklaratywne pliki JSON używane do automatyzowania wdrażania i konfigurowania zasobów platformy Azure. Aby zamienić miejsca przy użyciu szablonów usługi Resource Manager, należy ustawić dwie właściwości w zasobach Microsoft.Web/sites/slots i Microsoft.Web/sites :
-
buildVersion: właściwość ciągu reprezentująca bieżącą wersję aplikacji wdrożonej w miejscu. Na przykład:v1,1.0.0.1lub2019-09-20T11:53:25.2887393-07:00. -
targetBuildVersion: właściwość ciągu określająca, jakiebuildVersionmiejsce powinno mieć miejsce. Jeśli parametrtargetBuildVersionnie jest równy bieżącemubuildVersion, wyzwala operację zamiany, wyszukując miejsce z określonymbuildVersion.
Przykładowy szablon usługi Resource Manager
Poniższy szablon usługi Resource Manager zamienia dwa miejsca, aktualizując buildVersionstaging miejsce i ustawiając targetBuildVersion wartość w miejscu produkcyjnym. Musisz mieć miejsce 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 szablon usługi Resource Manager jest idempotentny. Można uruchomić go wielokrotnie i utworzyć ten sam stan gniazd. Bez żadnych zmian w szablonie kolejne uruchomienia tego samego szablonu nie wyzwalają zamiany miejsca, ponieważ miejsca są już w żądanym stanie.
Rozwiązywanie problemów z zamianami
Jeśli wystąpi jakikolwiek błąd podczas zamiany miejsca, błąd pojawia się w folderze D:\home\LogFiles\eventlog.xml. Jest on również rejestrowany 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 90 sekund dla każdego żądania HTTP i ponawia próbę maksymalnie pięć razy. Jeśli wszystkie ponawianie prób zostanie przekroczone, 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 operacji aktualizacji lokacji może wystąpić następujący błąd Nie można zmienić miejsca, ponieważ jego ustawienia konfiguracji zostały przygotowane do zamiany. Ten błąd może wystąpić, jeśli zamiana z podglądem (zamiana wielofazowa) faza 1 zakończy się, ale faza 2 nie została jeszcze wykonana. Może również wystąpić, jeśli zamiana nie powiodła się. Istnieją dwa sposoby rozwiązania tego problemu:
- Anuluj operację zamiany, która resetuje lokację z powrotem do starego stanu
- Ukończ operację zamiany, która aktualizuje lokację do żądanego nowego stanu
Aby dowiedzieć się, jak anulować lub ukończyć operację zamiany, zobacz zamiana z podglądem (zamiana wielofazowa).
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 pliku 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 rozgrzewania. 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 niestandardowego 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. Ponowne uruchomienia są wykonywane, ponieważ po zamianie konfiguracja powiązania nazwy hosta nie jest zsynchronizowana. Taka sytuacja sama 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=1ustawienie aplikacji na wszystkich miejscach. Jednak to ustawienie aplikacji nie działa z aplikacjami programu Windows Communication Foundation (WCF).