Wydawanie oprogramowania oznaczało kiedyś okno konserwacyjne i trzymane kciuki. Nowoczesne zespoły stosują strategie, które sprawiają, że wydawanie wersji jest rutynowe, a wybór niebiesko-zielonego vs wdrożenie kanarkowe jest jednym z pierwszych, z którymi się spotkasz. Obydwa zmniejszają ryzyko, ale robią to w przeciwny sposób: jeden przygotowuje pełny zamiennik, a drugi po trochu testuje z prawdziwymi użytkownikami.

W tym przewodniku wyjaśniono, jak działa każdy z nich i ile kosztuje w praktyce. Uruchomiliśmy małe przykłady routingu użytkowników i wycofywania zmian w Pythonie 3.13, a dane wyjściowe pochodzą z tego uruchomienia. Przykłady Kubernetes mają charakter ilustracyjny i nie uruchomiliśmy ich. Potraktuj wartości procentowe i progi jako przykłady wyjściowe do dostosowania.

Krótka odpowiedź

W przypadku wdrożenia niebiesko-zielonego uruchamiasz dwa identyczne środowiska produkcyjne. Jeden obsługuje użytkowników podczas wdrażania i testowania nowej wersji, drugi zaś umożliwia przełączenie całego ruchu w jednym ruchu.

W przypadku wdrożenia canary nowa wersja działa obok starej. Wysyłasz do niego niewielki procent rzeczywistego ruchu, porównujesz wyniki i krok po kroku zwiększasz udział, aż obsłuży wszystkich. Nazwa pochodzi od górników, którzy kiedyś używali kanarków jako wczesnego ostrzegania przed niebezpieczeństwem.

Niebiesko-zielony kontra kanarek obok siebie

Jak działa wdrożenie niebiesko-zielone

1. Niebieski jest aktywny i obsługuje cały ruch.
2. Wdróż nową wersję w green, który nie będzie odbierał ruchu użytkowników.
3. Dokładnie przetestuj ekologię w rzeczywistym środowisku produkcyjnym, korzystając z testów dymnych i użytkowników wewnętrznych.
4. Zmień router, moduł równoważenia obciążenia lub DNS, aby skierować ruch na zielony.
5. Obserwuj uważnie, niebieski wciąż działa i jest gotowy.
6. Jeśli coś jest nie tak, przełącz się z powrotem. Jeśli wszystko jest w porządku, kolejnym bezczynnym środowiskiem będzie kolor niebieski.

W Kubernetes możesz dokonać zmiany, zmieniając selektor usługi, tak aby ruch był przenoszony do podów o różnych etykietach:

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

Mocne strony: Koncepcyjnie jest to proste, możesz przetestować dokładną konfigurację produkcyjną, zanim użytkownicy ją zobaczą, a wycofanie jest niemal natychmiastowe. Słabe strony: Zduplikowana infrastruktura może być kosztowna, błąd, który prześlizgnie się przez testy, dotrze do wszystkich na raz, a otwarte sesje i praca w locie wymagają ostrożności podczas zmiany. Jeśli używasz DNS do przełącznika, rekordy w pamięci podręcznej mogą to opóźnić. Nowy w koncepcjach? Zobacz nasz samouczek Kubernetes dla początkujących.

Jak działa wdrożenie kanarek

1. Wdróż nową wersję obok wersji stabilnej.
2. Skieruj niewielką część ruchu, na przykład 5%, na kanarek.
3. Porównaj liczbę błędów, opóźnienia i wskaźniki biznesowe z wersją stabilną.
4. Jeśli jesteś zdrowy, zwiększ do 25%, następnie 50%, a następnie 100%.
5. Jeśli coś ulegnie pogorszeniu, prześlij cały ruch z powrotem do wersji stabilnej.

Wiele zespołów zaczyna od „kanarka” z personelem wewnętrznym, następnie od regionu niskiego ryzyka, a dopiero potem od szerszej publiczności.

Mocne strony: Zła wersja wpływa tylko na małą grupę, a z prawdziwego ruchu można się dowiedzieć, że żadne środowisko testowe nie jest w stanie w pełni odtworzyć. Słabe strony: Potrzebujesz routingu opartego na procentach i wskaźników według wersji, wdrażanie trwa dłużej, a dwie wersje działają razem przez jakiś czas. Mały kanarek może być również zbyt cichy, aby dać znaczący sygnał, szczególnie w godzinach małego ruchu.

Stabilne routing użytkowników

Losowe wybieranie wersji na każde żądanie powoduje, że użytkownicy mogą czuć się mylący, ponieważ mogą przełączać się między starą a nową. Typowym rozwiązaniem jest zaszyfrowanie stabilnego identyfikatora użytkownika w zasobniku, dzięki czemu każdy użytkownik zawsze otrzyma tę samą odpowiedź:

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

Rzeczywisty udział był zbliżony do docelowego. Ta metoda ma jeszcze dwie przydatne właściwości, a nasz test potwierdził obie. Ten sam użytkownik zawsze otrzymywał tę samą wersję. Wszyscy w grupie 5% byli nadal uwzględnieni w 25%, więc nikt, kto miał już nową wersję, nie został przeniesiony z powrotem w miarę wzrostu wdrożenia.

W rzeczywistych systemach takim routingiem zajmuje się zazwyczaj siatka usług, moduł równoważenia obciążenia lub narzędzie takie jak Argo Rollouts czy Flagger, więc nie trzeba tego pisać samodzielnie. Nadal pomocne jest zrozumienie, co robią.

Automatyzacja decyzji

Kanarek działa tylko wtedy, gdy ktoś faktycznie porównuje wersje. Automatyczne kontrole są bardziej wiarygodne niż osoba oglądająca wykresy. Oto podstawowa idea, porównując poziom błędów Canary z wersją stabilną:

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

Zwróć uwagę na pierwszy przypadek. Poziom błędów wydaje się wysoki, ale przy zaledwie 100 żądaniach nie jest to jeszcze wystarczający dowód. Prawdziwe narzędzia stosują dokładniejsze statystyki i analizują kilka sygnałów łącznie:

Problem z bazą danych

Kod aplikacji można zamienić w ciągu kilku sekund, ale danych nie. Obie strategie zwykle korzystają z jednej bazy danych, więc podczas wdrażania i po wycofaniu stara i nowa wersja muszą działać z tym samym schematem.

Standardową odpowiedzią jest wzorzec rozwiń i zwiń. Załóżmy, że chcesz zmienić nazwę name na full_name:

1. Rozwiń: dodaj nową kolumnę. Stary kod pozostaje nienaruszony.
2. Migracja: wydanie kodu, który zapisuje dane w obu kolumnach i wypełnia stare wiersze.
3. Przełącz: kod wydania odczytywany z nowej kolumny.
4. Umowa: gdy już nic nie będzie używać starej kolumny, usuń ją w późniejszej wersji.

Wymaga to kilku zwolnień, ale każdy krok można bezpiecznie wycofać. Uruchomienie RENAME COLUMN za jednym razem zepsułoby wersję, która oczekiwała innej nazwy. Zachowaj ostrożność również w przypadku długotrwałych zmian schematu, ponieważ mogą one powodować blokady. Więcej informacji na ten temat znajdziesz w transakcjach SQL.

Rolling i inne strategie

Wdrożenie Kubernetes domyślnie wykonuje aktualizację ciągłą, co pasuje do wielu usług. Aktualizacja krocząca również zmienia się stopniowo, ale jej udział jest powiązany z liczbą wystąpień i sama w sobie nie analizuje wyników ani nie wstrzymuje się od złych wskaźników.

A co z flagami funkcji?

Wdrożenie umieszcza kod na serwerach, a wersja udostępnia użytkownikom funkcję. Flagi funkcji oddzielają je, umożliwiając włączenie funkcji dla wybranych użytkowników bez konieczności wdrażania czegokolwiek. Działają bardzo dobrze w przypadku obu strategii: wdrażaj z wyłączoną flagą, a następnie włączaj ją stopniowo. Nie zastępują one tych strategii, ponieważ flaga nie może chronić Cię przed wersją, która ulega awarii podczas uruchamiania. Pamiętaj, aby usunąć stare flagi, ponieważ narastają jako dług techniczny.

Jak wybrać

Można je również łączyć. Niektóre zespoły wdrażają zielone środowisko, a następnie stopniowo przenoszą do niego ruch, uzyskując czyste środowisko i ograniczony promień wybuchu. Cokolwiek wybierzesz, zautomatyzuj to za pomocą potoku CI/CD, jak wyjaśnia nasz przewodnik po działaniach GitHub.

Typowe błędy

• Wprowadzanie istotnych zmian w schemacie. Przywracanie zmian nie pomaga, jeśli stary kod nie może odczytać danych.
• Brak kryteriów wycofywania. Zdecyduj, co oznacza „zły” przed rozpoczęciem wydania, a nie w trakcie incydentu.
• Pozwól, aby otoczenie dryfowało. Jeśli kolor zielony różni się od niebieskiego, Twoje testy wykażą mniejszą skuteczność. Zdefiniuj oba za pomocą infrastruktury jako kodu.
• Pomiar wyłącznie wskaźników technicznych. Wersja może być wolna od błędów i mimo to przerywać proces płatności.
• Nigdy nie ćwicz wycofywania się. Ćwicz to, aby zadziałało, gdy jesteś pod presją.
• Zapominanie o zadaniach w tle. Pracownicy i zaplanowane zadania również potrzebują planu podczas zmiany.

Podsumowanie

Niebiesko-zielony zapewnia czystą i szybką zmianę. Canary zapewnia małą, zmierzoną ekspozycję. Jeśli Twoje monitorowanie jest nadal proste, zacznij od aktualizacji ciągłych lub niebiesko-zielonych i zainwestuj w wskaźniki poszczególnych wersji, zanim wypróbujesz kanarkowe aktualizacje. Następnie przećwicz wycofanie w następnej wersji, łącznie z bazą danych. To pojedyncze ćwiczenie zwykle ujawnia, co naprawdę wymaga naprawy.

Najczęstsze pytania

Ucz się dalej