Wyjaśnienie niebiesko-zielonego wdrożenia i jego roli w DevOps

Photo of author

By maciekx

Tradycyjne metody wdrażania oprogramowania, oparte na jednorazowym „wielkim wybuchu”, nie sprawdzają się w obliczu dzisiejszych wymagań. Konieczność zapewnienia elastyczności, zwinności i ciągłego wdrażania w środowiskach chmurowych oraz w podejściu DevOps wymaga zupełnie nowego podejścia.

Samo przygotowanie listy kroków do manualnego wykonania przy wdrażaniu nowej wersji do środowiska produkcyjnego to za mało. Takie podejście nie czyni cię zwinnym, ani nie świadczy o poprawnym stosowaniu praktyk DevOps.

Wdrożenie niebiesko-zielone: istota

Wdrożenie niebiesko-zielone to technika implementacji oprogramowania, której celem jest redukcja przestojów i ograniczenie ryzyka związanego z wprowadzaniem nowej wersji. Wykorzystuje się w tym celu dwa identyczne środowiska: aktywne (niebieskie) i nieaktywne (zielone).

Środowisko aktywne jest miejscem, gdzie aktualnie działa oprogramowanie, a użytkownicy korzystają z niego w ramach normalnego ruchu produkcyjnego. Środowisko nieaktywne służy do wdrażania i testowania nowej wersji aplikacji.

Po przeprowadzeniu testów i weryfikacji nowej wersji, ruch produkcyjny zostaje przekierowany ze środowiska aktywnego do nieaktywnego, które staje się nowym środowiskiem aktywnym. Proces ten można powtarzać w zależności od potrzeb.

Źródło: docs.aws.amazon.com

Kontekst DevOps

Metoda wdrożenia niebiesko-zielonego idealnie wpisuje się w filozofię i procesy DevOps. Wspiera ciągłe dostarczanie i wdrażanie oprogramowania, minimalizując jednocześnie niedogodności dla użytkowników i eliminując ryzyko związane z wypuszczeniem produkcyjnej wersji, która mogłaby okazać się wadliwa.

Posiadanie dwóch identycznych środowisk umożliwia testowanie nowych wersji bez wpływu na aktualnie działającą aplikację. To pozwala na częstsze i szybsze wypuszczanie kolejnych wersji, co jest kluczowym aspektem DevOps.

Dodatkowo, możliwość szybkiego przełączania ruchu pomiędzy środowiskami jest niezbędna do sprawnego wycofywania zmian w przypadku wystąpienia problemów, co również jest istotne w metodyce DevOps.

Kluczowe zasady wdrażania niebiesko-zielonego

# 1. Dwa identyczne środowiska

Wdrożenie niebiesko-zielone wymaga istnienia dwóch identycznych środowisk. Identycznych pod względem danych i procesów. Jedno z nich jest aktywne (niebieskie), a drugie nieaktywne (zielone).

Środowisko niebieskie to miejsce, gdzie użytkownicy wykonują swoje codzienne zadania. Środowisko zielone jest stale synchronizowane z niebieskim, ale to na nim testerzy przeprowadzają swoje testy. Mimo, że nie jest to środowisko produkcyjne, testy przeprowadzane są w warunkach bardzo zbliżonych do produkcyjnych.

#2. Przełączenie ruchu

Po testach i przygotowaniu nowej wersji oprogramowania, ruch produkcyjny jest przekierowywany ze środowiska aktywnego do nieaktywnego, czyniąc to drugie nowym środowiskiem aktywnym.

Przełączenie jest natychmiastowe. Fazy wdrażania przechodzą do historii. Nie występuje żaden przestój. Użytkownicy nie muszą podejmować żadnych działań, aby móc pracować w nowym środowisku. Zostają oni przekierowani automatycznie i w tym samym momencie.

Źródło: aws.amazon.com

#3. Szybkie wycofanie

Możliwość szybkiego przełączania ruchu pomiędzy środowiskami oznacza również możliwość szybkiego wycofania zmian w przypadku wystąpienia problemów. Dzięki temu aplikacja pozostaje dostępna, a przestoje są minimalne.

Jeśli z zielonym środowiskiem wystąpią problemy, wszyscy użytkownicy są automatycznie przekierowywani z powrotem do stabilnego, oryginalnego środowiska niebieskiego bez żadnych zakłóceń.

#4. Automatyczne testowanie

Automatyczne testowanie to kluczowy aspekt wdrożenia niebiesko-zielonego. Daje pewność, że nowa wersja oprogramowania jest gruntownie przetestowana zanim zostanie wdrożona w środowisku produkcyjnym.

Jeśli systemy nie zawierają wystarczającej liczby automatycznych testów (przynajmniej testów jednostkowych, funkcjonalnych i regresji), wdrożenie niebiesko-zielone nie ma większego sensu.

Brak automatycznych testów znacznie spowalnia proces. Czas potrzebny na przetestowanie nowego (zielonego) środowiska będzie na tyle długi, że zanim będzie można przejść na nie, będzie już ono „przeterminowane” pod względem cyklu życia oprogramowania.

#5. Ciągłe dostarczanie

Wdrożenie niebiesko-zielone jest elementem potoku ciągłego dostarczania, co w rezultacie oznacza szybsze i częstsze wypuszczanie oprogramowania na produkcję.

Zmian można dokonać natychmiast po przygotowaniu nowej wersji do testowania w środowisku zielonym. Samo przełączenie ruchu jest na tyle szybkie, że proces ten można powtarzać codziennie, pod warunkiem, że testowanie również przebiega sprawnie.

Typowy cykl życia

Platforma, na której działa wdrożenie niebiesko-zielone ma swój własny cykl życia, obejmujący szereg kroków. Oto jego typowa struktura:

  • Zbudowanie nowej wersji oprogramowania. Obejmuje to kompilację kodu, uruchomienie automatycznych testów i przygotowanie artefaktu gotowego do wdrożenia.
  • Kolejnym etapem jest wdrożenie nowej wersji w środowisku nieaktywnym (zielonym). Obejmuje to konfigurację środowiska, wdrożenie artefaktu oraz konfigurację niezbędnych ustawień.
  • Po wdrożeniu nowej wersji w środowisku zielonym uruchamiane są automatyczne testy, aby upewnić się, że nowa wersja działa poprawnie. Obejmuje to testy funkcjonalne, testy regresji, testy integracyjne, a nawet, w bardziej zaawansowanych przypadkach, testy wydajności.
  • Następuje przełączenie ruchu ze środowiska aktywnego (niebieskiego) na nieaktywne (zielone). Proces ten obejmuje aktualizację systemu równoważenia obciążenia lub ustawień DNS w celu przekierowania ruchu do środowiska zielonego. Naturalnie proces ten powinien być zautomatyzowany.
  • Po przełączeniu ruchu następuje monitorowanie aplikacji, aby upewnić się, że działa prawidłowo. Monitorowane są błędy, problemy z wydajnością oraz inne potencjalne nieprawidłowości.
  • Ten krok jest opcjonalny i nie powinien być wykonywany zbyt często. W przypadku wykrycia istotnych problemów, ruch jest przekierowywany z powrotem do środowiska niebieskiego, aby wykonać natychmiastowe wycofanie zmian. Ponownie, proces ten odbywa się bez przestojów i zakłóceń dla użytkowników. Aktualizowany jest jedynie system równoważenia obciążenia lub ustawienia DNS.
  • Po rozwiązaniu problemów i przygotowaniu nowej wersji, ruch jest ponownie przekierowywany na środowisko zielone. Ponownie aktualizowany jest system równoważenia obciążenia lub ustawienia DNS.
  • W ostatnim etapie, po upewnieniu się, że nowa wersja oprogramowania jest stabilna, stara wersja działająca w środowisku niebieskim jest wycofywana. Będzie ona potrzebna do budowy kolejnej, nowej wersji.

Wdrażanie potoków CI/CD

Wdrożenie niebiesko-zielone w potoku DevOps CI/CD powinno być naturalnym procesem.

Podstawowym warunkiem jest posiadanie dwóch identycznych środowisk. Ponieważ będzie to proces zautomatyzowany, można wykorzystać infrastrukturę jako kod, np. AWS CloudFormation lub niezależne od chmury narzędzie Terraform. Narzędzia te służą do tworzenia/odtworzenia/aktualizacji środowisk w ramach automatycznych potoków.

Po spełnieniu tego warunku, stworzenie w pełni zautomatyzowanego procesu wdrożenia jest stosunkowo proste. Wystarczy ponownie wykorzystać istniejące potoki do tworzenia środowisk niebieskiego i zielonego. W tym przypadku należy w potoku uwzględnić również procesy testowe.

Proces przełączania ruchu może być zautomatyzowany przy pomocy narzędzi takich jak AWS Elastic Load Balancer lub NGINX. Proces polega na aktualizacji ustawień systemu równoważenia obciążenia lub ustawień DNS tak, aby ruch był przekierowywany do środowiska zielonego po przetestowaniu i przygotowaniu nowej wersji oprogramowania.

Kolejnym elementem jest monitoring. W tym celu można wykorzystać narzędzia takie jak AWS CloudWatch, New Relic lub Datadog.

W ostatnim kroku można ponownie wykorzystać istniejące potoki do likwidacji starego środowiska niebieskiego. Możliwa jest likwidacja wszystkich usług i komponentów przed ich ponownym odtworzeniem, lub aktualizacja skryptów każdej usługi. Zwykle likwidacja i ponowne odtworzenie jest bezpieczniejsze, gdyż w przypadku aktualizacji należy uwzględnić więcej potencjalnych problemów.

Najlepsze praktyki wdrażania niebiesko-zielonego

Chcesz maksymalnie wykorzystać możliwości wdrożenia niebiesko-zielonego? Oto kilka praktycznych wskazówek.

Solidna strategia migracji baz danych

Podczas wdrażania nowej wersji oprogramowania należy upewnić się, że schemat bazy danych jest prawidłowo zaktualizowany. Do zarządzania zmianami w schemacie bazy danych użyj narzędzi takich jak Flyway lub Liquibase.

Narzędzie do analizy kanaryjskiej

Mimo, że wdrożenie kanaryjskie jest podejściem alternatywnym, niektóre jego elementy można wykorzystać do ulepszenia wdrożenia niebiesko-zielonego.

Użyj narzędzi do analizy kanaryjskiej takich jak Kayenta lub Spinnaker, aby przeanalizować wydajność nowej wersji w rzeczywistym środowisku. Polega to na porównaniu wydajności nowej wersji z wydajnością wersji poprzedniej.

Użyj mechanizmów przełączania funkcji (np. za pomocą biblioteki Togglz), aby włączać i wyłączać poszczególne funkcje w nowej wersji. Pozwala to na stopniowe wdrażanie i szybkie wycofywanie w razie potrzeby.

Moduł równoważenia obciążenia z kontrolami stanu

Wykorzystaj system równoważenia obciążenia, np. AWS Elastic Load Balancer lub NGINX, wraz z kontrolami stanu, aby mieć pewność, że ruch jest kierowany jedynie do sprawnych instancji. Zapewnia to ciągłą dostępność aplikacji oraz minimalizację przestojów.

Plan wycofywania z automatycznym wycofaniem

Przygotuj plan wycofania na wypadek problemów i zautomatyzuj ten proces z pomocą narzędzi takich jak AWS CodeDeploy lub Octopus Deploy. Dzięki temu minimalizowane są przestoje, a aplikacja pozostaje wysoce dostępna.

Plan wycofywania dotyczy głównie środowiska zielonego, w przypadku wykrycia poważnego problemu w nowej wersji.

Nie potrzebujesz planu wycofania dla środowiska niebieskiego, ponieważ pozostaje ono niezmienione i można do niego wrócić w dowolnym momencie.

Wyzwania związane z wdrażaniem niebiesko-zielonym

Wdrożenie niebiesko-zielone może stanowić pewne wyzwanie dla zespołów programistycznych. Oto kilka najczęstszych:

  • Konfiguracja i zarządzanie dwoma identycznymi środowiskami może być skomplikowane i czasochłonne. Wymaga specjalistycznej wiedzy z zakresu infrastruktury oraz narzędzi, takich jak Terraform lub CloudFormation. Zespół programistów musi posiadać odpowiednie kompetencje techniczne, aby podołać temu wyzwaniu.
  • Podczas wdrażania nowej wersji oprogramowania trzeba zadbać o prawidłową aktualizację schematu bazy danych. Może to być trudne, szczególnie jeśli schemat jest złożony. Potrzebne są niezawodne procesy wdrażania bazy danych, które automatycznie obsłużą aktualizację schematu.
  • Analiza wydajności nowej wersji w warunkach produkcyjnych może być wyzwaniem. Wymaga to znajomości narzędzi do analizy kanaryjskiej, takich jak Kayenta lub Spinnaker.
  • Implementacja przełączania funkcji może być skomplikowana, szczególnie w przypadku aplikacji o wielu funkcjonalnościach. Wymaga to precyzyjnego planowania i koordynacji pomiędzy zespołami programistów.
  • Testowanie nowej wersji w warunkach produkcyjnych może być trudne, szczególnie w przypadku aplikacji o dużej liczbie użytkowników lub serwerów. Należy maksymalnie zautomatyzować przypadki testowe. Duża koordynacja pomiędzy zespołami testującymi i programistycznymi jest niezbędna.
  • Dobrze skonfigurowany system monitorowania to rzadkość, ale w środowisku DevOps jest koniecznością. Warto zainwestować czas w zbudowanie takiego rozwiązania, bazując na sprawdzonych usługach (AWS CloudWatch, New Relic, Datadog).

Różnica pomiędzy wdrożeniem niebiesko-zielonym a kanaryjskim

Różnica w porównaniu do tradycyjnych procesów wdrażania jest oczywista (brak dwóch równoległych środowisk z różnymi wersjami oprogramowania), ale różnica w porównaniu z wdrożeniem kanaryjskim może być bardziej interesująca.

Wdrożenie niebiesko-zielone wykorzystuje dwa środowiska (niebieskie i zielone). Środowiska te są stale synchronizowane pod względem danych. Gdy nowa wersja zostanie przetestowana i uznana za gotową, ruch jest przekierowywany ze środowiska aktywnego do nieaktywnego, które staje się nowym środowiskiem aktywnym. Nie traci się czasu na wdrażanie nowego kodu i nie ma przestoju. Wszyscy użytkownicy pracują na aktualnie aktywnym środowisku i nawet nie zauważają zmiany.

Wdrożenie kanaryjskie polega na wdrożeniu nowej wersji dla małej grupy użytkowników, podczas gdy reszta nadal korzysta z wersji aktualnej. Jest to wdrażanie stopniowe, nie pełna zmiana. W tym przypadku testerzy to użytkownicy produkcyjni, stanowiący jednak tylko ich podzbiór. Grupa ta aktywnie testuje nową wersję, a po jej ustabilizowaniu zostaje ona udostępniona wszystkim użytkownikom.

Które podejście jest lepsze?

Odpowiedź „to zależy” w tym przypadku jest jak najbardziej na miejscu.

Jeśli priorytetem jest wysoka dostępność, to wdrożenie niebiesko-zielone jest lepszym wyborem.

Jeśli ważniejsza jest szybsza informacja zwrotna i bardziej kontrolowane (choć wolniejsze) wdrażanie, to wdrożenie kanaryjskie jest lepsze.

Oba podejścia są na tyle elastyczne, że można je uznać za wystarczające do budowy poważnych systemów DevOps.

Studium przypadku

Netflix wykorzystuje wdrożenie niebiesko-zielone do wdrażania nowych wersji swojej usługi. Dzięki temu może wdrażać zmiany bez wpływu na komfort użytkownika. W innych przypadkach Netflix stosuje również wdrożenie kanaryjskie. Różne podejścia do wdrożeń DevOps mogą być stosowane równolegle.

Również Amazon i Etsy wykorzystują wdrożenie niebiesko-zielone do aktualizacji swoich platform e-commerce.

LinkedIn korzysta z tej metody do aktualizacji swojej platformy społecznościowej.

IBM stosuje wdrożenie niebiesko-zielone do wdrażania nowych wersji swojej platformy chmurowej.

Firmy te z powodzeniem wdrożyły niebiesko-zielone wdrażanie w swojej infrastrukturze i mogą służyć za przykład dla innych.

Słowo na koniec

Podobnie jak wdrożenie kanaryjskie, wdrożenie niebiesko-zielone optymalizuje istniejące zwinne procesy i metodologie, aby dostarczać nowe oprogramowanie w sposób niezauważalny dla użytkowników. To jest ostateczny cel tego typu podejść. Dostarczasz często i regularnie, ale nikt tego nie widzi i nikogo to nie obchodzi.

Może to być frustrujące dla programistów, że ich praca nie jest szeroko komentowana. Jednak właśnie to jest najlepszym dowodem dobrze wykonanej roboty. Nikt o tym nie mówi, a wszyscy z tego korzystają każdego dnia.

Zapraszamy do zapoznania się z odpowiedziami na najczęściej zadawane pytania dotyczące rozmowy kwalifikacyjnej z zakresu DevOps.


newsblog.pl