Deployment oprogramowania metodą Blue-Green

Jedną z ważniejszych czynności w pracy z systemami informatycznymi jest sam release kodu na produkcję, czy aktualizacja oprogramowania. Jeszcze nie tak dawno temu, nowe wersje oprogramowania dostępne były na płytach CD wydawanych kilka razy do roku w formie biuletynów. Wraz z nadejściem zwinnego programowania (ang. agile software development) pojawiły się cykliczne releasy na koniec sprintu (np. raz na dwa tygodnie).

W ostatnim czasie coraz bardziej popularne staje się Continuous Deployment, gdzie nowe wersje możemy mieć wręcz codziennie. Jak sobie z tym poradzić?

Jednym ze wzorców do radzenia sobie z częstymi aktualizacjami jest wzorzec blue-green. Przyda się on w momencie kiedy wdrożenie nowej wersji oprogramowania jest dość ryzykowne. Nawet w przypadku, kiedy posiadamy dobre testy. Pamiętajmy także, że ryzyko składają się również inne czynniki, jak konfiguracja firewalla, uprawnienia, wydajność maszyny itp.

Wspomniany wcześniej wzorzec zakłada, że posiadamy do dyspozycji minimum dwa środowiska: blue oraz green. Mogą to być maszyny wirtualne, serwery fizyczne, dwa wydzielone środowiska w systemie operacyjnym lub konta hostingowe. Ważne jest, aby były zarazem różne, ale jednocześnie identyczne. W dowolnym momencie tylko jedno z nich jest aktywne oraz posiada najnowszą wersję oprogramowania.

Prócz tego potrzebujemy jeszcze posiadać load balancer lub router. Będzie on odpowiedzialny za przekierowanie połączenia do serwera blue lub green. Na początku nie ma znaczenia, który z serwerów zostanie wybrany.

Sytuacja może wyglądać następująco:

1. Na środowisko green wrzucamy pierwsza wersję oprogramowania. Wszystko działa, jak należy. Postanowiliśmy jednak dodać kilka nowych funkcji do kodu i chcemy to bezpiecznie wdrożyć. W tym momencie mamy zapasowe środowisko blue. Wrzucamy tam zatem nasz nowy kod
2. W tym momencie istnieją dwie wersje oprogramowania. Obecnie użytkownicy korzystają z maszyny green. Mamy zatem czas na sprawdzenie, czy nowy kod nie powoduje żadnych problemów. Pamiętajmy, że obydwa środowiska są produkcyjne i wykorzystują te same zasoby.
3. Jeżeli stwierdzimy, że wszystko działa poprawnie, to na routerze lub load balancerze zmieniamy przekierowanie ruchu z serwera green na blue.
4. W tym momencie są dwie możliwości. Po wdrożeniu wszystko działa poprawnie i tak zostawiamy. Jeżeli jednak wynikną jakieś problemy, to cała procedura rollbacku sprowadza się do ponownego przekierowania ruchu na serwer green.
5. Kolejne wdrożenia będą odbywały się na tej samej zasadzie. Obecnie naszym głównym serwerem jest blue. Zatem nowa wersja oprogramowania zostanie zainstalowana na serwerze green. I postępujemy zgodnie z punktami 1 – 4.

Podsumowując, dzięki metodologii blue-green otrzymujemy:

• Wdrożenia bez żadnych przestojów produkcji – aplikacja zawsze będzie dostępna dla użytkowników
• Szybka kopia zapasowa – jesteśmy w stanie w krótkim czasie wrócić do poprzedniej wersji. Sprowadza się to wyłącznie do zmiany konfiguracji routera/balancera.
• Bezpieczne wdrażanie nowego oprogramowania, bez ryzyka poważniejszej awarii