Blue-green i canary rozwiązują ten sam problem — wypuszczenie nowej wersji bez okna serwisowego — i robią to za różną cenę. Blue-green płaci duplikacją środowiska i kupuje natychmiastowe wycofanie, a canary płaci wymaganą obserwowalnością i kupuje mniejszy promień rażenia. Ten artykuł porównuje oba koszty na konkretach, razem z tym, czego wybór strategii nie rozstrzyga.
Na skróty
Czego dowiesz się z artykułu:
- Czym dokładnie różnią się blue-green i canary w przebiegu wydania
- Jaki koszt stały przyjmuje każde z podejść i czego w zamian nie wymaga
- Dlaczego canary bez obserwowalności jest wdrożeniem na ślepo
- Czego wybór strategii nie rozstrzyga — i co trzeba rozstrzygnąć osobno
Dla kogo jest ten artykuł:
- Inżynierowie DevOps i osoby utrzymujące pipeline’y wdrożeniowe
- Liderzy zespołów decydujący o sposobie wypuszczania wydań
- Właściciele usług odpowiadający za dostępność po wdrożeniu
Czas czytania: 7 minut
Oba podejścia i moment decyzji
Opracowanie cloud.google.com o strategiach wdrażania i testowania opisuje blue-green jako utrzymywanie dwóch identycznych środowisk, z których tylko jedno przyjmuje ruch produkcyjny: nowa wersja wchodzi na środowisko nieaktywne, zostaje sprawdzona, a potem ruch przełącza się na nie w całości. Canary przeciwnie — nowa wersja działa obok starej i otrzymuje początkowo niewielki udział ruchu, który rośnie etapami, jeśli wskaźniki się nie pogarszają.
Różnica jest w momencie decyzji. W blue-green decyzja jest pojedyncza i podejmowana przed wpuszczeniem ruchu: albo przełączamy, albo nie. W canary decyzji jest tyle, ile etapów zwiększania ruchu, i każda opiera się na pomiarze z produkcji. Dlatego blue-green wymaga dobrego środowiska testowego, a canary wymaga dobrych metryk — i te wymagania nie są wymienne.
Trzecie podejście warto nazwać, bo bywa mylone z canary: aktualizacja krocząca wymienia instancje po kolei, bez rozdziału ruchu po wersjach. Jest tania i wbudowana w orkiestratory, ale nie daje punktu, w którym wersja jest oceniana — podmienia wszystko, tylko wolniej.
Blue-green: za co płacisz duplikacją
Koszt stały blue-green to drugie środowisko o pojemności produkcyjnej. W zamian dostajesz wycofanie, które jest przełączeniem ruchu z powrotem, więc czas powrotu do stanu sprawnego nie zależy od czasu budowania ani wdrażania poprzedniej wersji. To jest cała wartość tego podejścia i w usługach, w których minuta niedostępności jest kosztowna, uzasadnia duplikację sama.
Pułapki są przewidywalne. Pierwsza: środowisko nieaktywne z czasem przestaje być identyczne, bo poprawki trafiają tylko na to aktywne. Druga: sesje użytkowników przypięte do starej wersji, jeśli stan sesji żyje w pamięci instancji, a nie w magazynie współdzielonym. Trzecia, najkosztowniejsza: migracje schematu bazy danych, które po przełączeniu uniemożliwiają powrót, bo stara wersja nie potrafi czytać nowego schematu.
Tę trzecią rozstrzyga się nie strategią wdrożeniową, a dyscypliną zmian w bazie: zmiany kompatybilne wstecz wchodzą jako osobne wydanie przed zmianą kodu, a usunięcie starej kolumny jest kolejnym wydaniem po tym, jak nowa wersja działa stabilnie. Bez tej dyscypliny wycofanie blue-green istnieje w dokumentacji, a nie w praktyce.
Canary: za co płacisz obserwowalnością
Rozdział o wydaniach kanarkowych w sre.google nazywa rzecz, którą najłatwiej pominąć: ocena wydania kanarkowego wymaga porównania populacji obsługiwanej nową wersją z populacją obsługiwaną starą, a to porównanie ma sens tylko wtedy, gdy obie są statystycznie podobne i gdy czas obserwacji wystarcza, by błąd się ujawnił. Canary nie jest więc „wypuszczeniem dla paru użytkowników”, a eksperymentem z grupą kontrolną.
Stąd wynika wymóg, który bywa odkrywany za późno: metryki muszą rozróżniać wersje. Jeśli wskaźnik błędów jest zbiorczy dla usługi, nowa wersja generująca błędy na swoim udziale ruchu rozmyje się w szumie i próg alarmowy nie zadziała. Etykietowanie metryk wersją jest warunkiem wstępnym canary, nie jego usprawnieniem.
Udział ruchu zwiększa się etapami, a wartości progów bierze się z własnego pomiaru ruchu, nie z cudzego przykładu: pierwszy etap ma być na tyle mały, żeby błąd nie dotknął wielu użytkowników, i na tyle duży, żeby w oknie obserwacji dał mierzalną liczbę żądań. Usługa o małym ruchu nie spełni tego warunku i dla niej canary jest złym wyborem — nie z powodu narzędzi, a z powodu arytmetyki.
Czego wybór strategii nie rozstrzyga
Metryki DORA opisane w dora.dev dzielą się dziś na dwie grupy i mają nazwy, które warto cytować dokładnie. Przepustowość dostarczania opisują: czas realizacji zmiany (od zatwierdzenia w systemie kontroli wersji do wdrożenia), częstotliwość wdrożeń oraz czas przywrócenia po nieudanym wdrożeniu. Niestabilność opisują: udział zmian nieudanych oraz udział wdrożeń przerobowych, czyli nieplanowanych i wynikających z incydentu na produkcji. Strategia wdrożeniowa wpływa na wskaźniki niestabilności i na czas przywrócenia, a na czas realizacji zmiany i częstotliwość wdrożeń nie wpływa prawie wcale — te zależą od wielkości zmian i przepustowości pipeline’u. Zespół, który wprowadza canary, żeby wdrażać częściej, naprawia nie ten element.
Wybór strategii nie rozstrzyga też o oddzieleniu wdrożenia od udostępnienia funkcji. Przełączniki funkcji pozwalają wysłać kod na produkcję wyłączony i włączyć go osobną decyzją; to jest inna osłona niż rozdział ruchu po wersjach i żadna nie zastępuje drugiej. W praktyce oba mechanizmy bywają łączone: kod wchodzi kroczące, funkcja włącza się przełącznikiem, a pomiar dotyczy funkcji — to obserwacja z wdrożeń, nie wniosek z cytowanych źródeł.
Nie rozstrzyga wreszcie o bezpieczeństwie samego pipeline’u. Lista owasp.org ryzyk bezpieczeństwa CI/CD porządkuje klasy, które nie zależą od sposobu wypuszczania wersji — nadmiarowe uprawnienia zadań potoku, niedostateczna kontrola dostępu do systemu kontroli wersji, zależności pochodzące z niezaufanych źródeł. Każda strategia wdrożeniowa wdraża dokładnie to, co dostała z potoku.
Czytaj także
- Automatyzacja wdrażania oprogramowania CI/CD — przewodnik — potok, z którego wychodzi wydanie
- Budowa pipeline CI/CD od podstaw — jak zbudować potok, który te strategie obsłuży
- Observability — logi, metryki i trace’y w praktyce — skąd bierze się sygnał, po którym canary się promuje albo wycofuje: logi, metryki i ślady żądań
Rozwijaj kompetencje
Temat rozwijają szkolenia Argo CD — ciągłe wdrażanie dla Kubernetes oraz Fundamenty DevOps — kultura, praktyki i narzędzia. Pierwsze pracuje na narzędziu GitOps, z którego te strategie prowadzi się w klastrze — program obejmuje progressive delivery z Argo Rollouts — drugie porządkuje praktyki, bez których strategia wdrożeniowa nie ma oparcia. Skontaktuj się z nami, żeby dopasować zakres do Waszego potoku.
Najczęściej zadawane pytania (FAQ)
Które podejście wybrać dla usługi o niewielkim ruchu?
Blue-green, bo canary potrzebuje liczby żądań wystarczającej do oceny etapu w rozsądnym czasie. Przy małym ruchu pierwszy etap canary albo trwa zbyt długo, albo jest zbyt duży, żeby nazwać go kanarkowym. Blue-green nie ma tego warunku — decyzja opiera się na testach na środowisku nieaktywnym, a nie na pomiarze z produkcji.
Czy canary wymaga osobnego środowiska jak blue-green?
Nie, obie wersje działają w tym samym środowisku i dzielą ruch. Koszt leży po stronie pomiaru: metryki muszą być etykietowane wersją, a reguły alarmowania działać na tej etykiecie. To jest praca w warstwie obserwowalności, nie w infrastrukturze, i dlatego canary bywa tańszy infrastrukturalnie, a droższy wdrożeniowo.
Jak wycofać wydanie, gdy zmieniliśmy schemat bazy danych?
Przez dyscyplinę zmian, nie przez strategię wdrożeniową. Zmiana schematu wchodzi jako osobne wydanie w postaci kompatybilnej wstecz, kod korzystający z niej w następnym, a usunięcie nieużywanych już elementów schematu w kolejnym. Wycofanie kodu jest wtedy możliwe, bo stara wersja nadal czyta schemat, który zostawiłeś czytelnym dla obu.
Czy przełączniki funkcji zastępują blue-green i canary?
Nie, rozstrzygają o innym pytaniu. Rozdział ruchu po wersjach chroni przed wadą w nowym kodzie jako całości; przełącznik funkcji pozwala udostępniać funkcję niezależnie od wdrożenia kodu. Zespoły używające obu mają osłonę na obu poziomach, a zespoły używające samych przełączników nadal wdrażają cały kod naraz.