Deployment slots – dodatkowe środowiska dla aplikacji

Podczas pracy w większym projekcie spotkasz się z ideą wprowadzenia wielu środowisk dla jednej aplikacji.  Czy taka redundancja zasobów pociąga za sobą jakieś korzyści, czy jedna instancja nie byłaby wystarczająca?

Staging deployment?

Dobra załóżmy, że dysponujemy tymi kilkoma środowiskami. Jedno z nich może być przeznaczone tylko i wyłącznie dla programistów. Wykorzystywaliby je jako miejsce do wrzucania nowo zaimplementowanych funkcjonalności – choćby po to, żeby sprawdzić działanie aplikacji na środowisku produkcyjnym – czy wszystko w chmurze wygląda tak samo, jak miało to miejsce lokalnie. Kolejną instancję można przekazać zespołowi QA, odpowiedzialnemu za weryfikację działania aplikacji oraz testowanie nowych funkcjonalności. Jeśli aplikacja ma już być wdrożona na produkcję i być udostępniona użytkownikom końcowym, dobrym pomysłem jest wykorzystanie kolejnej instancji przechowującej wersję demo dla klienta – production.

Dzięki temu rozwiązaniu każda z grup użytkowników ma swoją własną wersję aplikacji. Stworzyliśmy trzy środowiska: developerskie, testowe oraz produkcyjne (live). Testerzy mogą spokojnie weryfikować czy w aplikacji wszystko działa poprawnie. Programiści wprowadzają nowe funkcje bez obaw, że jak coś się zepsuje to powędruje to od razu do klienta, a aplikacja znajdująca się na środowisku produkcyjnym jest w pełni zabezpieczona przed każdym „nieprzemyślanym” commitem 🙂 Warto również zauważyć, że środowiska te są od siebie odseparowane (developer raczej niczego testerowi w aplikacji nie zepsuje).

Staging deployment web aplikacji
Staging deployment web aplikacji

Do stworzenia kilku instancji tego samego projektu, znajdującego się wewnątrz Azure, wykorzystuje się deployment slots.

Deployment slots – limity i konfiguracje

W ramach Standardowego App Service Planu masz do dyspozycji 5 deployment slotów (w przypadku Premium jest ich 20) – w planach poniżej standardowego nie są dostępne. Kiedy dodasz do aplikacji jakiekolwiek sloty, możliwość zmiany typu App Service Planu na gorszy zostanie zablokowana. Deployment slots mogą być wykorzystywane w ramach aplikacji webowych, mobilnych oraz REST API. Każdy z slotów posiada swoją własną konfigurację. Warto zaznaczyć, że część ustawień może być współdzielona pomiędzy różnymi instancjami np.:

  • ustawienia ogólne (general settings) – jaka wersja .NET’a czy Python’a jest wykorzystywana, platforma 32 czy 64 bitowa,  czy WebSockety mają być włączone itp.,
  • ustawienia aplikacji (application settings) wraz z parametrami połączeń (connection strings), które nie zostały oznaczone jako „ustawienie miejsca” (slot setting),
  • samodzielnie wgrane preprocesory (np. dla PHP) oraz WebJoby.

Istnieje pewna grupa ustawień, która pozostaje unikalna dla każdego slotu:

  • źródło deploymentu,
  • ustawienia aplikacji oraz parametry połączeń oznaczone jako slot setting,
  • certyfikaty SSL oraz niestandardowe domeny DNS,
  • ustawienia dotyczące skalowania i monitorowania aplikacji,
  • harmonogramy WebJobs (WebJobs schedulers).

Skalowanie dostępne jest tylko w ramach głównej aplikacji. Sama aplikacja pełni rolę deploymentu slotu o nazwie production.

Obsługa deployment slots z pomocą portalu

Ok przejdźmy do stworzenia kilku slotów dla aplikacji. Po kliknięciu na WebApp’ę wybierz opcję Miejsca wdrożenia (Deployment slots). Następnie Dodaj miejsce (Add slot). Stwórz dwa sloty np. development oraz testing. Zwróć uwagę na dropdown z etykietą Źródło konfiguracji (Configuration source), z której można skopiować istniejące już ustawienia dla nowego slotu.

Klikając w dowolny slot zobaczysz panel, zbliżony wyglądem do tego jakbyś nawigował po web aplikacji. Rzuć okiem na nazwę i url. Są one generowane według następującego wzorca:

Każdą z aplikacji możesz podejrzeć odwiedzając jej url. W ramach każdego środowiska należy skonfigurować metodę deploymentu – w przypadku systemów kontroli wersji można posłużyć się różnymi branch’ami na repozytorium, bądź różnymi repozytoriami (co kto woli). Zachęcam do sprawdzenia czy odpowiednia aplikacja znajduje się na właściwym deployment  slot’cie. Teraz kliknij w swoją aplikację na portalu. Na górnym pasku znajduje się przycik Zamień (Swap). Operacja ta wykorzystywana jest do zmiany slot’a, który aktualnie będzie znajdował się na produkcji. Podczas zamiany możesz określić które dwa deployment slot’y zostaną zamienione:

Zamiana deployment slots za pomocą portalu
Zamiana deployment slots za pomocą portalu

Zamiana z podglądem (Swap with preview) pozwala na dodatkowy krok weryfikacyjny, sprawdzający czy wszystko działa jak należy, zanim dojdzie do zamiany. Wersja deweloperska aplikacji powinna zamienić się z wersją testerską i vice versa – sprawdź url’e po podmianie 🙂 Podczas podmiany slotów źródła aplikacji nie są ani kopiowane, ani przenoszone pomiędzy środowiskami. Ruch zostaje przekierowany na nowy slot, to wszystko.

Przygotowanie aplikacji do podmiany oraz automatyczna wymiana

Deployment slots mogą być wykorzystywane do „rozgrzania aplikacji” (Warm up). Każda niedawno wdrożona aplikacja potrzebuje trochę czasu do startu – jest to tzw. downtime. Deployment slot przygotowuje aplikację przed podmianą. Gdy dochodzi już do samej podmiany slotów, staje się ona niezauważalna – click i już mamy nową wersję 🙂 Jeśli okazałoby się, że aplikacja nie została wystarczająco dobrze przetestowana, a użytkownicy zaczynają zgłaszać błędy, można szybko wykonać roll back do poprzedniego stanu – w ten sam sposób co robiłeś swapa’a. Warto jeszcze mieć na uwadze, że wszystkie instancje działają w ramach tej samej maszyny wirtualnej oraz tego samego App Service Plan’u. Dość częste żonglowanie slotami może mieć negatywny wpływ na wydajność aplikacji.

W przypadku gdy masz dosyć tego żmudnego wchodzenia na portal, tylko po to żeby kliknąć swap polecam zainteresować się opcją automatycznej wymiany (auto swap) – znajdziesz ją w ustawieniach każdego slotu poza production. Staje się ona przydatna w przypadku gdy chcemy całkowicie pozbyć się problemu wolnego startu – można dodać kolejny slot na „rozruch”, a potem automatyczną podmianę na środowisko developerskie.

Testy A/B

Deployment slots mogą stanowić całkiem niezłe narzędzie dla testów A/B. Pozwalają na określenie jaki procent użytkowników zostanie przekierowany na środowisko produkcyjne, a pozostały na jakiś inny slot demonstracyjny (production traffic). Np. 85% użytkowników będzie korzystać z dotychczasowej wersji aplikacji, natomiast pozostałe 15% zostanie udostępniona wersja beta.

Podział ruchu użytkowników na dwie aplikacje produkcyjne
Podział ruchu użytkowników na dwie aplikacje produkcyjne

 

Wyłapywanie błędów ograniczone będzie do niewielkiego grona użytkowników, co sprowadza się do szybkiego podejmowanie decyzji związanych z niedawno wprowadzonymi zmianami – czy aby na pewno był to dobry pomysł, jak użytkownicy zareagowali na ostatnio wprowadzone zmiany itp. Jeśli stwierdzimy, że jesteśmy usatysfakcjonowani z naszych zmian 🙂 można dokona pełnego swapa – ewentualnie jeszcze zwiększyć production traffic, aby przebadać większą grupę użytkowników. Aby ustawić wspomniany powyżej parametr z menu aplikacji wybierz opcję Testowanie w środowisku produkcyjnym (Testing in production):

Konfiguracja przekierowywania ruchu na środowisku produkcyjnym

Alternatywne metody zarządzania slot’ami

Deployment slotami możemy zarządzać nie tylko z Azure’owego poralu:

Visual Studio

Proces ten jest identyczny jak w przypadku opisanego w poprzednim artykule deploymentu aplikacji. Zamiast wrzucać zawartość projektu na serwer z web aplikacją przerzucamy ją na odpowiedni deployment slot.

PowerShell

Azure CLI

C#