Konfigurowanie środowisk przejściowych w usłudze Azure App Service
Podczas wdrażania aplikacji internetowej, aplikacji internetowej w systemie Linux, zaplecza mobilnego lub aplikacji interfejsu API w usłudze aplikacja systemu Azure można użyć oddzielnego miejsca wdrożenia zamiast domyślnego miejsca produkcyjnego w warstwie Standardowa, Premium lub Izolowanej usługi App Service. 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.
- 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 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, ponieważ 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 (na przykład wyszukaj 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 miejsce.
Uwaga
Jeśli aplikacja nie znajduje się jeszcze w warstwie Standardowa, Premium lub Izolowana , wybierz pozycję Uaktualnij i przejdź do karty Skala 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ę protokołu 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 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>, a 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. Profil można zaimportować przez program Visual Studio, 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 zostanie obcięta o długości 40 znaków, a nazwa połączonej witryny i nazwy miejsca musi być mniejsza niż 59 znaków.
Co się dzieje podczas zamiany
Kroki operacji zamiany
W przypadku zamiany dwóch miejsc (zwykle z miejsca przejściowego jako źródła do miejsca produkcyjnego jako miejsca docelowego) 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.
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 poprawnie 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 zamiana automatyczna jest włączona przy użyciu niestandardowej rozgrzewki, wyzwól inicjowanie aplikacji, wysyłając żądanie HTTP do katalogu głównego 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, gdzie zamiana się powiedzie lub nie powiedzie się. 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 wykonaniu tej operacji zamiany), zostaną szybko przetworzone w ostatnim kroku procesu zamiany. 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, które są zamieniane:
- Ustawienia ogólne, takie jak wersja platformy, 32/64-bitowe, gniazda internetowe
- Ustawienia aplikacji (można skonfigurować tak, aby trzymały się miejsca)
- ciągi Połączenie ion (można skonfigurować do trzymania się gniazda)
- 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 zostały zamienione:
- 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
- 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, które kończą się sufiksem _EXTENSION_VERSION
- Ustawienia utworzone przez Połączenie or usługi
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 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 (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 usługę App Service, że ustawienie nie jest zamienialne.
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 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 zostaną wyświetlone ustawienia w wybranych miejscach źródłowych i docelowych, które zostaną 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 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 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 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.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 zamknij okno dialogowe, wybierając pozycję Zamknij.
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ę 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 wypchnięcie kodu do miejsca źródłowego. Zamiana automatyczna odbywa się po krótkim czasie, a aktualizacja zostanie odzwierciedlona 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 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ę 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. Przykładem jest200,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 dwa 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 zasobów aplikacji 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.
Po automatycznym skierowaniu klienta do określonego miejsca jest ono "przypięte" 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. 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 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 jednak kierowane automatycznie do miejsca, ponieważ wartość procentowa routingu jest ustawiona na 0. Jest to zaawansowany scenariusz, w którym można "ukryć" miejsce przejściowe przed publicznością, 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: 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, 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. Przyjęto założenie, że utworzono 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, co oznacza, że można go wykonać wielokrotnie i utworzyć ten sam stan miejsc. 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, jest on zalogowany 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 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. Jest to spowodowane tym, że po zamianie konfiguracja powiązania nazwy hosta nie jest zsynchronizowana, co samo w sobie nie powoduje ponownego uruchomienia. Jednak niektóre bazowe 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).