Sloty wdrażania i zamiana

Sloty wdrożeniowe to aktywne, odseparowane środowiska dla aplikacji internetowej App Service, z których każde ma własną nazwę hosta (np. myapp-staging.azurewebsites.net). Sloty współdzielą ten sam plan App Service i zasoby ze slotem produkcyjnym, ale działają niezależnie. Umożliwiają wdrożenia blue-green — nową wersję można sprawdzić w slocie staging, a następnie przełączyć ją do środowiska produkcyjnego bez przestoju. Sloty są dostępne od warstwy Standard wzwyż.

Dodaj nowy slot wdrożeniowy do aplikacji internetowej za pomocą witryny Azure Portal lub interfejsu CLI. Każdy slot otrzymuje własny adres URL, ustawienia aplikacji i parametry połączeń. W warstwie Standard można utworzyć maksymalnie 5 slotów, a w warstwie Premium — maksymalnie 20 slotów. Typowe nazwy slotów to staging, canary, hotfix i integration, odzwierciedlające różne etapy potoku wydawania.

Przed przełączeniem bardzo ważne jest, aby rozgrzać slot staging, dzięki czemu nowa wersja zostanie w pełni zainicjowana. Zimna instancja App Service obsługuje pierwsze żądania wolniej, gdy inicjalizuje środowisko uruchomieniowe, co jest niedopuszczalne w środowisku produkcyjnym. Włącz funkcję Auto Swap albo ręcznie wysyłaj żądania HTTP rozgrzewające do slotu staging. App Service obsługuje również konfigurację applicationInitialization, która pozwala zdefiniować ścieżki rozgrzewania, muszące zwrócić kod 200, zanim slot zostanie uznany za gotowy.

Przełączenie atomowo zamienia slot staging ze slotem produkcyjnym. Podczas przełączania App Service najpierw kieruje ruch do instancji staging z nowym kodem, czeka na ich inicjalizację, a następnie przekierowuje cały ruch produkcyjny do nowych instancji; stare instancje produkcyjne stają się nowym slotem staging. Dzięki temu wycofanie zmiany jest proste — wystarczy ponownie wykonać przełączenie.

Ustawienia aplikacji można oznaczyć jako przypisane do slotu (specyficzne dla slotu) lub nieprzypisane do slotu (podlegające zamianie). Ustawienia nieprzypisane do slotu przemieszczają się wraz ze slotem wdrożeniowym podczas przełączania — dlatego parametry połączenia z bazą danych staging trafiają wraz z kodem do środowiska produkcyjnego. Ustawienia przypisane do slotu pozostają w nim niezależnie od przełączeń — środowisko produkcyjne zawsze zachowuje parametry połączenia ze swoją produkcyjną bazą danych. Oznacz ustawienia jako przypisane do slotu za pomocą pola wyboru „deployment slot setting” lub interfejsu CLI.

App Service obsługuje dzielenie ruchu — kierowanie określonego procentu ruchu produkcyjnego do slotu nieprodukcyjnego bez wykonywania pełnego przełączenia. Umożliwia to wydania canary, w których stopniowo zwiększa się udział ruchu z 5% do 10%, a następnie do 50%, w miarę nabierania pewności co do nowej wersji i monitorowania współczynników błędów na każdym etapie. Użytkownicy trafiający do slotu canary otrzymują trwały plik cookie, który utrzymuje ich przy tej samej wersji i zapewnia spójność sesji.

Auto Swap automatycznie przełącza slot staging do środowiska produkcyjnego za każdym razem, gdy zostanie w nim wdrożony nowy kod. Funkcja ta jest idealna dla potoków CI/CD, w których każde pomyślne wdrożenie ma od razu trafić do środowiska produkcyjnego. Auto Swap czeka, aż żądania HTTP slotu staging będą zwracać kod 200, zanim zakończy przełączanie. Włącz tę funkcję dla wybranego slotu w portalu lub interfejsie CLI — zachowaj jednak ostrożność, ponieważ między wdrożeniem a publikacją w środowisku produkcyjnym nie ma etapu ręcznego zatwierdzania.

Przestrzegaj następujących najlepszych praktyk dotyczących slotów wdrożeniowych: zawsze sprawdzaj wersję w środowisku staging przed przełączeniem jej do środowiska produkcyjnego, używaj ustawień przypisanych do slotu, aby odseparować produkcyjne połączenia z bazą danych od środowiska staging, uruchamiaj testy dymne pod adresem URL slotu staging po wdrożeniu, konfiguruj ścieżki kontroli kondycji, aby App Service nie kończył przełączania, jeśli nowa wersja jest niesprawna, oraz oznaczaj wdrożenia, aby można było ustalić, który commit jest aktywny w każdym slocie.

W typowym potoku CI/CD etap kompilacji kompiluje i testuje kod, etap wdrażania przesyła artefakt do slotu staging, etap testów integracyjnych uruchamia automatyczne testy pod adresem URL środowiska staging, a etap przełączania przełącza slot staging do środowiska produkcyjnego — opcjonalnie po uzyskaniu ręcznej akceptacji. Ten wzorzec jest natywnie obsługiwany zarówno w Azure Pipelines, jak i w GitHub Actions za pomocą akcji wdrażania App Service.

Podczas przełączania slotów i po jego zakończeniu monitoruj kluczowe metryki w usłudze Azure Monitor, aby potwierdzić poprawne działanie nowej wersji. Obserwuj skoki liczby błędów HTTP 5xx, średniego czasu odpowiedzi oraz wykorzystania procesora i pamięci. Skonfiguruj alerty dotyczące metryk, które będą uruchamiane po przekroczeniu przez współczynniki błędów określonego progu — otrzymasz w ten sposób sygnał umożliwiający szybkie przełączenie z powrotem. Funkcja smart detection usługi Application Insights może automatycznie powiadamiać o anomaliach po wdrożeniu.

Sloty wdrożeniowe są lepszym rozwiązaniem niż utrzymywanie całkowicie oddzielnych aplikacji App Service dla środowisk staging i produkcyjnego, ponieważ współdzielą ten sam plan (bez dodatkowych kosztów), umożliwiają przełączenie jednym kliknięciem wraz z wycofaniem zmiany, obsługują dzielenie ruchu i są zarządzane w ramach tego samego zasobu App Service. Oddzielnych aplikacji należy używać tylko wtedy, gdy środowisko staging wymaga zasadniczo innych jednostek SKU planu, izolacji lub całkowicie oddzielnego rozliczania.

Sprawdź swoją wiedzę na temat zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznano następujące zagadnienia: sloty wdrożeniowe zapewniają odizolowane środowiska umożliwiające wdrożenia blue-green, ustawienia przypisane do slotu wiążą konfigurację specyficzną dla środowiska (np. adresy URL baz danych) ze slotem, a nie z kodem, natomiast dzielenie ruchu umożliwia wydania canary poprzez kierowanie określonego procentu ruchu produkcyjnego do nowej wersji. W następnej części omówimy automatyczne skalowanie i domeny niestandardowe.