Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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 można zastosować w warstwie Standardowej, Premium lub Izolowanej planu usługi 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 miejscem produkcyjnym.
Wdrażanie aplikacji w miejscu nieprodukcyjnym ma następujące korzyści:
Zmiany aplikacji można zweryfikować przed zamianą miejsca na środowisko produkcyjne.
Przed zamianą do środowiska produkcyjnego można upewnić się, że wszystkie instancje gniazda są rozgrzane. Takie podejście eliminuje przestoje podczas wdrażania aplikacji. Przekierowywanie ruchu jest bezproblemowe. Żadne żądania nie są odrzucane 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 wprowadzone do środowiska produkcyjnego nie są zgodne z oczekiwaniami, możesz natychmiast wykonać te same przełączenie, aby przywrócić ostatnią znaną dobrą wersję witryny.
Za korzystanie z miejsc wdrożenia nie są naliczane dodatkowe opłaty. Każda warstwa planu usługi App Service obsługuje inną liczbę miejsc wdrożenia. Aby dowiedzieć się, ile miejsc obsługuje warstwa aplikacji, zobacz Limity usługi App Service.
Aby przeskalować aplikację do innej warstwy, upewnij się, że warstwa docelowa obsługuje liczbę miejsc, których aplikacja już używa. 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.
Poniższy film wideo uzupełnia kroki opisane w tym artykule, ilustrując sposób konfigurowania środowisk przejściowych w usłudze Azure App Service.
Wymagania wstępne
- Uprawnienia do wykonania operacji slotu, którą chcesz przeprowadzić. Aby uzyskać informacje na temat wymaganych uprawnień, zobacz Operacje dostawcy zasobów. Wyszukaj na przykład miejsce.
Dodawanie miejsca
Aby 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 menu po lewej stronie wybierz pozycję Miejsca wdrożenia wdrożenia>. Następnie wybierz pozycję 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 gniazda. Ustawienia, które można sklonować, obejmują ustawienia aplikacji, ciągi połączeń, wersje struktury językowej, gniazda internetowe, wersję protokołu HTTP i architekturę bitową platformy.
Uwaga
Obecnie prywatny punkt końcowy nie jest klonowany przez sloty.
Po wprowadzeniu ustawień wybierz pozycję Zamknij , aby zamknąć okno dialogowe. Nowe miejsce jest teraz wyświetlane na stronie Miejsca wdrożenia . Domyślnie ruch % jest ustawiony na 0 dla nowego slotu, a cały ruch klientów jest kierowany do slotu produkcyjnego.
Wybierz nowe miejsce wdrożenia, aby otworzyć stronę swojego zasobu.
Slot przejściowy ma panel zarządzania podobnie jak każda inna aplikacja usługi App Service. Możesz zmienić konfigurację gniazda. Aby przypomnieć, że wyświetlasz gniazdo wdrożeniowe, nazwa aplikacji i nazwa gniazda są wyświetlane w adresie URL. Typ aplikacji to App Service (Slot). Slot można również zobaczyć jako oddzielną aplikację w grupie zasobów z tymi samymi oznaczeniami.
Na stronie zasobu miejsca wybierz adres URL aplikacji. Miejsce wdrożenia ma własną nazwę hosta i jest również aktywną aplikacją. Aby ograniczyć publiczny dostęp do miejsca wdrożenia, zobacz Konfigurowanie ograniczeń dostępu do usługi Azure App Service.
Nowe miejsce wdrożenia nie ma zawartości, nawet jeśli sklonujesz ustawienia z innego miejsca. Na przykład możesz opublikować do tego slotu za pomocą Git. Możesz wdrożyć w miejscu przeznaczenia z innej gałęzi repozytorium lub innego repozytorium. Artykuł Uzyskaj profil publikowania z usługi Azure App Service może dostarczyć wymagane informacje dotyczące wdrażania do slotu. Program Visual Studio może zaimportować profil, aby wdrożyć zawartość w miejscu.
Adres URL slotu 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.
Informacje o tym, 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 przedziału docelowego (na przykład przedziału produkcyjnego) w odniesieniu do wszystkich wystąpień przedziału ź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 powoduje automatyczne ponowne uruchomienie wszystkich wystąpień w miejscu źródłowym. Podczas zamiany z podglądem ta akcja oznacza koniec pierwszej fazy. Operacja zamiany jest wstrzymana. Możesz zweryfikować, że gniazdo źródłowe działa prawidłowo z ustawieniami gniazda 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 do slotu źródłowego i zatrzymuje operację.
Jeśli lokalna pamięć podręczna jest włączona, zainicjuj jej inicjalizację, wysyłając żądanie HTTP do katalogu głównego aplikacji (
/) na każdym wystąpieniu slotu ź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 zamiana automatyczna jest włączona z niestandardowym rozgrzewaniem, wyzwól niestandardowe inicjowanie aplikacji na każdym wystąpieniu miejsca źródłowego.
Jeśli
applicationInitializationnie zostanie określony, wyzwól żądanie HTTP do katalogu głównego aplikacji w lokalizacji źródłowej w każdej instancji.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. 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 zawiera aplikację, która była wcześniej w miejscu docelowym przed zamianą, wykonaj tę samą operację, stosując wszystkie ustawienia i ponownie uruchom wystąpienia.
W dowolnym momencie operacji zamiany wszystkie prace związane z inicjowaniem zamienianych aplikacji odbywają się w slocie ź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ć slot przejściowy z slotem produkcyjnym, upewnij się, że slot produkcyjny jest zawsze slotem docelowym. W ten sposób operacja zamiany nie ma wpływu na aplikację produkcyjną.
Uwaga
Wcześniejsze instancje produkcyjne są zamieniane na przejściowe po tej operacji. Te wystąpienia są przetwarzane w ostatnim kroku procesu wymiany. Jeśli masz jakiekolwiek długotrwałe operacje w aplikacji, są one porzucone, gdy restartują się procesy robocze. Fakt ten dotyczy również aplikacji funkcjonalnych. Upewnij się, że kod aplikacji jest napisany w sposób odporny na uszkodzenia.
Kroki, aby uczynić gniazdo niewymienialnym
Podczas klonowania konfiguracji z innego miejsca wdrożenia sklonowana konfiguracja jest edytowalna. Niektóre elementy konfiguracji są zgodne z zawartością zamiany (nie są one specyficzne dla miejsca). Inne elementy konfiguracji pozostają w tym samym gnieździe po zamianie (są specyficzne dla gniazda).
Podczas zamiany miejsc te ustawienia są zamieniane:
- Stos języka i wersja, 32-bitowa i 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ń WebJobs
- Połączenia hybrydowe (obecnie)
- Punkty końcowe usługi (obecnie)
- Azure Content Delivery Network (obecnie)
- Mapowania ścieżki
- Integracja sieci wirtualnej
Podczas zamiany miejsc te ustawienia nie są zamieniane:
- Ustawienia ogólne, o których nie wspomniano na poprzedniej liście
- 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
- Zawsze włączony
- Ustawienia diagnostyczne
- Współużytkowanie zasobów między źródłami (CORS)
- 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. Ustaw jego wartość na 0 lub false. Te ustawienia są możliwe do zamiany lub wszystkie nie można zamienić. Nie można zmienić tylko niektórych ustawień, a nie innych. Tożsamości zarządzane nigdy nie są zamieniane. To ustawienie nadpisywania aplikacji nie ma na nie wpływu.
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, aby trzymać się określonego miejsca, które nie zostało zamienione:
Przejdź do Ustawienia>Zmienna środowiskowa dla tego przedziału.
Dodaj lub edytuj ustawienie, a następnie wybierz Ustawienie miejsca wdrożenia. Zaznaczenie tego pola wyboru informuje usługę App Service, że ustawienie nie jest możliwe do zamiany.
Wybierz i zastosuj.
Zamienianie miejsc wdrożenia
Miejsca wdrożenia można zamienić na stronie Miejsca wdrożenia aplikacji i na stronie Przegląd.
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.
Przejdź do strony Miejsca wdrożenia aplikacji i wybierz 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 karty Zmiany slotów źródłowych oraz Zmiany slotów docelowych i sprawdź, czy zmiany konfiguracji są oczekiwane. Po zakończeniu możesz natychmiast zamienić miejsca, wybierając pozycję Rozpocznij zamianę.
Aby zobaczyć, jak zostanie uruchomione miejsce docelowe z nowymi ustawieniami przed rozpoczęciem zamiany, nie wybieraj opcji Rozpocznij zamianę. Postępuj zgodnie z instrukcjami w sekcji Zamiana z wersją zapoznawczą w dalszej części artykułu.
Wybierz pozycję Zamknij , aby zamknąć okno dialogowe.
Jeśli masz jakiekolwiek problemy, zobacz Rozwiązywanie problemów z zamianami w dalszej części tego artykułu.
Zamiana z podglądem (zamiana wielokrotna)
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 stosuje elementy konfiguracji do slotu źródłowego.
Uwaga
Nie można używać zamiany z podglądem, gdy w jednym ze slotów włączone jest uwierzytelnianie witryny.
Wykonaj kroki opisane w sekcji Zamiana miejsc wdrożenia, ale wybierz Wykonaj zamianę z podglądem.
W oknie dialogowym pokazano, jak konfiguracja w miejscu źródłowym zmienia się w pierwszej fazie oraz jak zmienia się miejsce źródłowe i docelowe w drugiej fazie.
Gdy wszystko będzie gotowe do rozpoczęcia zamiany, wybierz pozycję Rozpocznij zamianę.
Po zakończeniu pierwszej fazy zostanie wyświetlone okno dialogowe z powiadomieniem.
Gdy będziesz gotowy do ukończenia oczekującej zamiany, wybierz Ukończ zamianę w Akcji Zamiany, a następnie wybierz przycisk Ukończ zamianę.
Aby anulować oczekującą zamianę, wybierz pozycję Anuluj zamianę , a następnie wybierz przycisk Anuluj zamianę .
Po zakończeniu wybierz pozycję Zamknij , aby zamknąć okno dialogowe.
Jeśli masz jakiekolwiek problemy, zobacz Rozwiązywanie problemów z zamianami w dalszej części tego artykułu.
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
Zamiana automatyczna usprawnia scenariusze w Azure DevOps, w których chcesz stale wdrażać aplikację, eliminując całkowicie czas rozruchu i przestoje, zapewniając klientom nieprzerwane działanie aplikacji. Po włączeniu automatycznej zamiany ze slotu na środowisko produkcyjne, za każdym razem, gdy przesyłasz zmiany kodu do tego slotu, usługa App Service automatycznie przełącza aplikację do środowiska produkcyjnego po przygotowaniu jej w slotcie źródłowym.
Uwaga
Zamiana automatyczna nie jest obsługiwana w aplikacjach internetowych w systemie Linux i w usłudze Web App for Containers.
Przed skonfigurowaniem automatycznej zamiany dla przedziału produkcyjnego rozważ przetestowanie jej w nieprodukcyjnym przedziale docelowym.
Przejdź do strony zasobów aplikacji. Wybierz Wdrożenie>Sloty wdrożeń, a następnie wybierz odpowiedni slot źródłowy.
W menu po lewej stronie wybierz pozycję Ustawienia>Ustawienia>Ogólne ustawienia.
Aby Włączono zamianę automatyczną, wybierz Włącz. W polu Automatyczna zamiana slotu wdrożeniowego wybierz slot docelowy. Następnie wybierz pozycję Zapisz na pasku poleceń.
Uruchom przesłanie kodu do przedziału ź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 w dalszej części tego artykułu.
Określ niestandardową rozgrzewkę
Niektóre aplikacje mogą wymagać niestandardowych działań rozgrzewki przed zmianą. Te akcje niestandardowe można określić przy użyciu applicationInitialization elementu konfiguracji w pliku Web.config.
Operacja zamiany czeka na zakończenie tej niestandardowej rozgrzewki przed zamianą z miejscem docelowym. 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 applicationInitialization elementu, zobacz wpis w blogu Najpopularniejsze błędy zamiany miejsca wdrożenia i jak je naprawić.
Można również dostosować sposób działania rozgrzewki, korzystając z następujących ustawień aplikacji:
-
WEBSITE_SWAP_WARMUP_PING_PATH: ścieżka do pingowania za pośrednictwem protokołu HTTP w celu przygotowania witryny. Dodaj to ustawienie aplikacji, określając ścieżkę niestandardową rozpoczynającą się od ukośnika jako jej wartość. 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 rozruchu i przełączania zostaną zatrzymane. Domyślnie wszystkie kody odpowiedzi są prawidłowe. -
WEBSITE_WARMUP_PATH: Ścieżka względna w witrynie, która powinna być pingowana kiedy witryna zostanie ponownie uruchomiona (nie tylko podczas zamiany slotów). Przykładowe wartości to/statuschecklub ścieżka główna,/.
Element <applicationInitialization> konfiguracji jest częścią każdego uruchamiania aplikacji, natomiast ustawienia aplikacji dotyczące zachowania rozgrzewki mają zastosowanie tylko do zamian miejsc.
Jeśli masz jakiekolwiek problemy, zobacz Rozwiązywanie problemów z zamianami w dalszej części tego artykułu.
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 menu po lewej stronie wybierz pozycję Dziennik aktywności.
Operacja zamiany jest wyświetlana w zapytaniu dziennika jako
Swap Web App Slots. Aby wyświetlić szczegóły, możesz ją rozwinąć i wybrać jedną z podoperacji lub błędów.
Automatyczne kierowanie ruchu produkcyjnego
Domyślnie wszystkie żądania klientów do adresu URL produkcyjnego aplikacji są kierowane do miejsca produkcyjnego. Można skierować część ruchu do innego slotu. Ta funkcja jest przydatna, jeśli potrzebujesz opinii użytkowników o nowej aktualizacji, ale nie jesteś gotowy do wydania jej w środowisku produkcyjnym.
Przejdź do strony zasobów swojej aplikacji internetowej i wybierz Wdrożenia>Miejsca wdrożeń.
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ć. Następnie wybierz opcję Zapisz.
Po zapisaniu ustawienia określony procent klientów jest losowo kierowany do slotu 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 slotu produkcyjnego zawiera 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 znaków określa slot produkcyjny. 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łę routingu typu 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ą automatycznie kierowane do miejsca, ponieważ procent routingu jest ustawiony na 0. Ta konfiguracja jest zaawansowanym scenariuszem, w którym można ukryć miejsce wdrożeniowe przed publicznością, umożliwiając jednocześnie zespołom wewnętrznym testowanie zmian w tym miejscu.
Usuń slot
Wyszukaj i wybierz aplikację.
Wybierzpozycję Miejsce>> aby usunąć >przegląd. Typ aplikacji jest wyświetlany jako App Service (Slot), aby przypomnieć, że wyświetlasz slot wdrożeniowy.
Zatrzymaj slot i ustaw ruch w slocie na zero.
Na pasku poleceń wybierz Usuń.
Automatyzowanie za pomocą szablonów usługi Resource Manager
Szablony usługi Azure Resource Manager to deklaratywne pliki JSON służące do automatyzowania wdrażania i konfiguracji 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: parametr tekstowy, który reprezentuje bieżącą wersję aplikacji wdrożonej w slocie. Na przykład:v1,1.0.0.1lub2019-09-20T11:53:25.2887393-07:00. -
targetBuildVersion: właściwość ciągu określająca, jaką wartość ma mieć gniazdobuildVersion. Jeśli wartośćtargetBuildVersionnie jest równa bieżącej wartościbuildVersion, rozpoczyna operację zamiany, wyszukując miejsce z określoną wartościąbuildVersion.
Przykładowy szablon usługi Resource Manager
Poniższy szablon usługi Resource Manager zamienia dwa miejsca, aktualizując wartość buildVersion w miejscu staging i ustawiając wartość targetBuildVersion 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 Resource Manager jest idempotentny. Można uruchomić go wielokrotnie i osiągnąć ten sam stan slotów. 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 wymianami
Jeśli wystąpi jakikolwiek błąd podczas zamiany miejsca, błąd pojawia się w pliku 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:
Mierzy się czas żądania HTTP do katalogu głównego aplikacji. Operacja zamiany czeka na 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 usługi Azure App Service.
Podczas operacji aktualizacji witryny może wystąpić następujący błąd: "Nie można zmienić gniazda, ponieważ jego ustawienia konfiguracji zostały przygotowane do zamiany". Ten błąd może wystąpić, jeśli pierwsza faza zamiany wielofazowej zakończy się, ale druga faza nie została 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ć działanie zamiany, zobacz Zamiana z podglądem (wielofazowa zamiana) wcześniej w tym artykule.
Podczas niestandardowego rozgrzewania żądania HTTP są wykonywane wewnętrznie bez przechodzenia przez zewnętrzny adres URL. Mogą one zawieść w przypadku niektórych reguł przepisywania adresów URL w
Web.config. Na przykład reguły przekierowywania nazw domen lub wymuszania HTTPS mogą uniemożliwić docieranie żądań rozgrzewających do kodu aplikacji. 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 rozgrzewania, reguły przepisania 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 zamianach miejsc w gniazdach aplikacja może doświadczyć nieoczekiwanych ponownych uruchomień. 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 związane z magazynowaniem, takie jak przełączenie awaryjne 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 we wszystkich slotach. Jednak to ustawienie aplikacji nie działa z aplikacjami programu Windows Communication Foundation (WCF).