Deployment strategies: po co w ogóle są
- data
- kategoria
- CI/CD
- także w
- Reliability Engineering
- czytanie
- 1 min / 240 słów
Najprostszy deployment wyglądał kiedyś tak:
zatrzymaj starą wersję
wrzuć nową wersję
uruchom
To działa, jeśli aplikacja może zniknąć na chwilę.
Przestaje działać, kiedy system obsługuje ruch cały czas, ma kilka instancji, kolejki, bazę danych, klientów mobilnych i użytkowników, którzy nie wiedzą, że właśnie trwa "okno wdrożeniowe".
Strategie deploymentu powstały z jednego powodu:
zmiana wersji jest ryzykiem
Różne strategie kontrolują inny rodzaj tego ryzyka.
Build, release i deploy to nie to samo
Warto rozdzielić trzy słowa.
build
powstaje artefakt
deploy
artefakt trafia do środowiska
release
użytkownik dostaje nowe zachowanie
W prostym świecie te trzy rzeczy dzieją się razem.
W większym systemie ich rozdzielenie daje kontrolę.
Można wdrożyć kod bez włączenia funkcji.
Można puścić nową wersję tylko do części ruchu.
Można mieć gotowe dwa środowiska i przełączyć routing.
Można skopiować ruch do nowej wersji, ale nie pokazać jej odpowiedzi użytkownikowi.
Co będzie w tej serii
Ta seria nie zaczyna od Argo Rollouts, Flaggera ani konkretnego dostawcy.
Najpierw trzeba umieć nazwać mechanizmy.
Rolling update wymienia instancje po kawałku.
Blue-green trzyma dwie wersje i przełącza ruch.
Canary daje nowej wersji mały procent prawdziwego ruchu.
Targeted rollout wybiera konkretnych użytkowników, ringi albo segmenty.
Feature flags rozdzielają deploy od release.
Shadow traffic pozwala sprawdzić nową wersję na kopii ruchu.
Każdy tekst będzie miał ten sam układ:
po co to powstało
co naprawdę oznacza
minimalny przykład
gdzie działa
gdzie kłamie nazwa
Minimalny stack
Przykłady będą możliwie proste.
Podstawą jest Kubernetes:
Deployment
Service
readinessProbe
Gateway API HTTPRoute
ConfigMap albo env var
Nie dlatego, że każda organizacja musi wdrażać tak samo.
Dlatego, że na tych prymitywach dobrze widać mechanizm.
Jeżeli rozumiesz mechanizm, narzędzie jest tylko implementacją.
Jeżeli nie rozumiesz mechanizmu, narzędzie daje ładniejszy panel do tej samej pomyłki.
Zaczynamy od strategii, którą Kubernetes daje domyślnie: rolling update.