Proces releasowania oprogramowania jest chyba jednym z ważniejszych wyzwać w czasach oprogramowania bazującego na usługach. 20 lat temu, oprogramowanie zwykle było sprzedawane na nośnikach danych i częstotliwość wydawania nowych wersji była bardzo niska (np. dwie aktualizacje na rok).
Myślę, że 5-10 lat temu, standardem stało się releasowanie co iterację, np. raz na dwa tygodnie. Od kilku lat jednak, wiele firm wdraża zmiany kilkakrotnie dziennie i taki proces można dopiero nazwać “continuous deployment”.
Temat bardzo szeroki, ale dzisiaj chciałbym przyjrzeć się tylko wzorcowi blue-green. Wiemy, że wdrożenie nowego kodu jest bardzo ryzykowne, nawet gdy mamy dobre pokrycie testami. W praktyce, istnieje wiele innych problemów takich jak konfiguracja zapory ogniowej czy odpowiednie uprawnienia. Skoro chcemy wdrażać często, nie jesteśmy w stanie sobie pozwolić na jakąkolwiek przerwę w działaniu systemu.
Wzorzec blue-green zakłada, że mamy do dyspozycji przynajmniej dwa serwery: blue oraz green. W dowolnym momencie tylko jeden z nich jest aktywny oraz posiada najnowszą wersję. Ponadto do dyspozycji powinniśmy mieć load balancer albo router, który będzie przełączał przekierowania do serwera blue albo green. Na początku oczywiście, przy pierwszym wdrożeniu nie ma znaczenia, który z serwerów wybierzemy. Sytuacja zatem może wyglądać następująco:
Blue zawiera pierwszą wersje kodu. Nie ma tu nic specjalnego. Załóżmy jednak, że mamy nową wersję (v2) i chcemy w bezpieczny sposób ją wdrożyć. Do dyspozycji mamy zapasowy serwer – w tym przypadku green. Umieszczamy tam zatem nową wersję:
Mamy teraz dwie wersje systemu, ale użytkownicy wciąż są przekierowani do v1. Mamy teraz czas na sprawdzenie czy nowy kod nie powoduje żadnych problemów. Oba węzły to serwery produkcyjne, zatem mają dostęp do tych samych zasobów. Jeśli jesteśmy pewni, że wszystko działa, zmieniamy konfigurację balancera, aby przekierowywał ruch do serwera zielonego:
Jeśli stwierdzimy, że nie wszystko jednak działa tak jak należy i np. musimy dokonać rollback’u, wtedy sewer niebieski wciąż zawiera poprzednią wersję. Wystarczy ponownie zmienić przekierowanie na balancerze i ruch będzie przekierowywany do V1.
Kolejne wdrożenia polegają na tej samej zasadzie. Wersja v3 będzie zainstalowana na serwerze z poprzednią wersją, czyli serwerze niebieskim w tym przypadku:
Innymi słowy, po każdym wdrożeniu, balancer będzie zmieniany tak, aby na drugi węzeł wskazywać. W dowolnym momencie, jeden z serwerów będzie zawierał aktualną wersję, a drugi poprzednią. W przypadku wdrażania nowego kodu, serwer z poprzednią wersją można określić jako staging albo preprod. Jak widać, nie ma znaczenia, który serwer to “blue”, a który “green”. Powyższy wzorzec ma wiele nazw i myślę, że nazwa może być trochę myląca – “green” nie znaczy, że jest to zawsze aktywny serwer. Aktywny serwera, co każde wdrożenie jest przełączany między niebieskim, a zielonym węzłem.
Podsumowując dzięki blue\green deployment zyskujemy:
- zero downtime deployment – aplikacja zawsze będzie dostępna dla użytkowników.
- Rollback – wrócenie do poprzedniej wersji sprowadza się wyłącznie do zmiany konfiguracji routera\balancera.
- Bezpieczne i bezstresowe wdrożenia.