Rolling Update

Stopniowa aktualizacja aplikacji instancja po instancji, bez przestojów. Stare wersje są zastępowane nowymi po kolei, utrzymując ciągłą dostępność usługi.

Rolling update to strategia wdrażania nowej wersji aplikacji, w której stare instancje są wymieniane na nowe stopniowo, partia po partii, a nie wszystkie naraz. Dzięki temu w trakcie aktualizacji część instancji nadal obsługuje ruch użytkowników, więc usługa jest cały czas dostępna i nie potrzebujesz okna serwisowego ani komunikatu „przepraszamy, trwają prace techniczne”.

Mechanizm jest prosty: orkiestrator (np. Kubernetes) uruchamia jedną lub kilka nowych instancji z nową wersją, czeka aż przejdą health check i zaczną przyjmować ruch, a dopiero potem wyłącza odpowiadającą im liczbę starych. Powtarza to w pętli, aż wszystkie pody będą na nowej wersji. Sterujesz tym dwoma parametrami: maxUnavailable (ile instancji może być chwilowo niedostępnych) i maxSurge (ile dodatkowych można odpalić ponad docelowy stan). Im ostrożniej je ustawisz, tym wolniejszy, ale bezpieczniejszy rollout.

Przykład z Kubernetes

W Kubernetes Deployment domyślnie używa właśnie strategii RollingUpdate. Gdy podmienisz obraz kontenera:

kubectl set image deployment/api api=myregistry/api:v2

Kubernetes zaczyna wymieniać pody po kolei. Możesz podejrzeć postęp przez kubectl rollout status deployment/api, a jeśli nowa wersja okaże się wadliwa, cofniesz ją jedną komendą: kubectl rollout undo deployment/api. To ostatnie ratuje tyłek częściej, niż chciałbyś przyznać.

Na co uważać

  • Health checki muszą być sensowne. Jeśli readinessProbe zwraca „OK”, zanim aplikacja faktycznie jest gotowa, ruch trafi do instancji, która jeszcze się nie rozgrzała, i posypią się błędy.
  • Kompatybilność wersji. Przez chwilę stara i nowa wersja działają jednocześnie. Twój kod i baza danych muszą to przeżyć, więc migracje schematu rób tak, żeby były wstecznie kompatybilne (najpierw dodaj kolumnę, dopiero potem przestań używać starej).
  • To nie jest atomowy przełącznik. Rollback też idzie stopniowo, więc wycofanie wadliwej wersji nie jest natychmiastowe.
  • Mit „zero ryzyka”. Brak przestoju nie znaczy brak bugów. Jeśli nowa wersja jest zepsuta, rolling update spokojnie rozjedzie ten błąd na całą flotę.

Pojęcia powiązane: blue-green deployment (dwa równoległe środowiska i przełączenie ruchu naraz), canary deployment (nowa wersja najpierw dla małego procenta użytkowników), readiness i liveness probe, oraz rollback. Rolling update to złoty środek: prostszy niż blue-green, mniej ostrożny niż canary, i domyślny wybór w większości klastrów Kubernetes.