Serwisy w środowisku GAE mogą być wdrażane według wielu różnych schematów, pozwalających zachować ciągłość działania.
Aby je zrozumieć, należy najpierw poznać strukturę samej aplikacji w środowisku Google App Engine.
Projekt GCP może mieć tylko jedną aplikację GAE. Aplikacja jest przypisana do jednego regionu, które nie może być zmieniony. Jeżeli konieczne jest przeniesienie aplikacji do innego regionu, musimy utworzyć nową, w odpowiednio zlokalizowanym projekcie.
W skład aplikacji może wchodzić wiele serwisów, a każdy z nich może występować w wielu wersjach jednocześnie. Ta właściwość jest bardzo cenna i umożliwia na przykład testy A/B.
Wersje serwisów mogą być uruchomione w wielu instancjach. W szczególności, dla środowiska STANDARD, serwis może nie mieć żadnej aktywnej instancji.
Powyższy przykład pokazuje aplikację posiadającą dwa serwisy, których wersje działają na sześciu instancjach.
Niebiesko-zielone Wdrażanie serwisów w środowisku Google App Engine STANDARD (blue-green deployment)
Ten sposób wdrażania, został opisany szczegółowo w artykule Martina Fowlera. Jego podstawowymi założeniami są:
-
posiadanie dwóch, możliwie identycznych środowisk
-
możliwość swobodnego kierowania ruchu na jedno lub drugie środowisko.
Dzięki temu, podczas gdy testujemy nową wersję serwisu na środowisku zielonym (green), klienci korzystają z wersji stabilnej na środowisku niebieskim (blue). Po pozytywnym zakończeniu testów, przełączamy cały ruch na środowisko zielone, które staje się produkcyjne. Środowisko niebieskie natomiast, jest gotowe na wdrożenie kolejnej wersji testowej.
Zaletą tego podejścia, poza widoczną prostotą, jest również łatwość i szybkość powrotu do poprzedniej wersji serwisu. W przypadku gdy okaże się, że testy nie wykryły krytycznego błędu i konieczny jest powrót do starego środowiska, można to zrobić szybko przez proste, powrotne, przełączenie ruchu.
Jak wygląda wdrażanie niebiesko-zielone na środowisku GAE pokazuje poniższy przykład.
Załóżmy, że wdrożyliśmy wersję v1 naszego serwisu service-name, dostępnego pod URLem
https://service-name-dot-project_id.region_id.r.appspot.com
poleceniem
gcloud app deploy --version=v1
W tej chwili cały ruch obsługiwany jest właśnie przez tę wersję serwisu.
Następnie, instalujemy testową wersję serwisu, v2 poleceniem
gcloud app deploy --version=v2 --no-promote
Parametr --no-promote powoduje, że nadal cały ruch dla serwisu
https://service-name-dot-project_id.region_id.r.appspot.com
jest kierowany na wersję v1. Można to sprawdzić poleceniem
gcloud app services describe service-name
Druga wersja serwisu jest dostępna pod adresem
https://v2-dot-service-name-dot-project_id.region_id.r.appspot.com
Tam też powinny być przeprowadzane testy.
Po podjęciu decyzji o przejściu z wersją drugą serwisu „na produkcję” przełączamy ruch następującym poleceniem:
gcloud app services set-traffic service-name --splits=v2=1
Od tej chwili, cały ruch dla naszego serwisu jest kierowany na wersję drugą. Warto zaznaczyć, że pierwsza wersja serwisu jest ciągle dostępna pod adresem
https://v1-dot-service-name-dot-project_id.region_id.r.appspot.com
Można również w każdej chwili przełączyć na nią cały ruch poleceniem
gcloud app services set-traffic service-name --splits=v1=1
Jeżeli chcemy żeby przejście pomiędzy wersjami odbyło się w sposób „bardziej delikatny”, możemy użyć parametru --migrate. Wtedy to, dla każdej nowej instancji tworzonej przez środowisko, zanim rozpocznie obsługę żądań klientów, wywoływany jest url
/_ah/warmup
Pozwala to nam wykonać czasochłonną inicjalizację serwisu przed pojawieniem się właściwego ruchu.
Parametr --migrate działa tylko dla serwisów mających ustawiony w pliku app.yaml parametr
inbound_services: - warmup
Wdrożenie kanarkowe (canary deployment)
Podczas gdy „blue-green deployment” polega na przełączaniu całego ruchu pomiędzy kolejnymi wersjami serwisu, „canary deployment” migruje ruch w sposób stopniowy.
Przećwiczmy to na przykładzie.
Wdrażamy dwie wersje serwisu następującymi poleceniami:
gcloud app deploy --version=v1
gcloud app deploy --version=v2 --no-promoteW tej chwili całość ruchu obsługuje wersja v1.
Następnym krokiem jest podzielenie ruchu pomiędzy dwie wersje serwisu:
gcloud app services set-traffic service-name --splits=v1=0.9,v2=0.1 --split-by=ip
Powyższe polecenie powoduje, że 90% ruchu trawia na pierwszą wersję serwisu, 10% natomiast, na drugą.
Parametr --split-by może przyjmować jedną z trzech wartości:
-
ip - ruch dzielony jest wg adresów IP klientów (domyślnie)
-
cookie - ruch dzielony jest wg kontrolowanego przez aplikację „ciasteczka” GOOGAPPUID
-
random - ruch dzielony jest losowo
Podsumowując
Jak pokazałem na powyższych przykładach, środowisko Google App Engine umożliwia wdrażanie serwisów na wiele sposobów.
Dzielenie ruchu oraz jego migrowanie pomiędzy wersjami jest zrealizowane w wygodny i bezpieczny sposób.