Blue-green deployment (blue-green nasazení)

Příklady z praxe

1. 01

   Přepnutí target group na AWS load balanceru

   E-shop běží za aplikačním load balancerem, který směřuje na target group blue. Nová verze se nasadí do target group green, projde kontrolou zdraví a smoke testem objednávky. Změna pravidla listeneru přesměruje veškerý provoz na green během jednotek sekund; blue zůstane běžet ještě hodinu jako pojistka.

   # přepnutí provozu na zelené prostředí
   aws elbv2 modify-listener \
     --listener-arn $LISTENER_ARN \
     --default-actions Type=forward,TargetGroupArn=$GREEN_TG_ARN

2. 02

   Zpětně kompatibilní migrace před přepnutím

   Aplikace potřebuje přejmenovat sloupec full_name na display_name. Místo přejmenování se v první fázi přidá nový sloupec a data se dopíší, takže stará i nová verze fungují nad stejným schématem. Starý sloupec se odstraní až v následujícím nasazení, kdy je jisté, že se k předchozí verzi nikdo nevrátí.

   -- fáze 1: expand (před nasazením green)
   ALTER TABLE users ADD COLUMN display_name text;
   UPDATE users SET display_name = full_name WHERE display_name IS NULL;
   
   -- fáze 2: contract (až po úspěšném přepnutí, další release)
   ALTER TABLE users DROP COLUMN full_name;

Časté omyly

MýtusS blue-green nasazením je rollback vždycky okamžitý.

Ve skutečnostiOkamžité je jen přepnutí provozu zpátky na staré prostředí. Pokud nová verze mezitím zapsala data ve formátu, kterému stará verze nerozumí, nebo provedla destruktivní migraci schématu, rollback aplikace problém nevyřeší a je potřeba oprava dat.

MýtusBlue-green a canary release jsou v podstatě totéž.

Ve skutečnostiBlue-green přepíná celý provoz najednou mezi dvěma kompletními prostředími. Canary release naopak pouští novou verzi jen malé části uživatelů a podíl zvyšuje podle metrik, takže odhalí i problémy, které se projeví až pod reálnou zátěží.

MýtusBlue-green nasazení znamená nulový výpadek za všech okolností.

Ve skutečnostiNulový výpadek platí pro nová spojení. Dlouhotrvající požadavky, WebSocket relace nebo běžící dávkové úlohy na starém prostředí se musí korektně dokončit, jinak uživatelé přerušení pocítí. Bez connection drainingu a ověření session storage bezvýpadkovost nevznikne sama.

Časté dotazy

Jak dlouho nechat staré prostředí běžet po přepnutí?

Staré prostředí se obvykle nechává běžet tak dlouho, aby pokrylo alespoň jeden plný cyklus provozní špičky, tedy typicky od jedné hodiny po jeden pracovní den. Rozhodující je doba, za kterou se projeví chyby viditelné až v produkčních datech: pomalé dotazy, chybné hodnoty v reportech nebo problémy s integracemi třetích stran. Kratší dobu volí týmy s dobrým monitoringem a rychlým alertingem, delší regulované provozy. Po uplynutí okna se prostředí buď zruší, nebo se stane cílem pro příští nasazení.

Zvládne blue-green nasazení aplikace se sdílenou relací uživatele?

Blue-green nasazení funguje s uživatelskými relacemi jen tehdy, když relace nežije v paměti aplikačního serveru. Session je potřeba držet mimo instance, typicky v Redisu, databázi nebo v podepsaném cookie. Jinak přepnutí provozu odhlásí všechny přihlášené uživatele, protože nové prostředí o jejich relacích nic neví. Stejná úvaha platí pro lokální souborovou cache a nahrané soubory uložené na disku instance, které patří do sdíleného objektového úložiště.

Kolik blue-green nasazení stojí navíc oproti rolling update?

Blue-green nasazení vyžaduje dočasně dvojnásobnou kapacitu aplikační vrstvy. V cloudu s účtováním po sekundách jde o náklad za desítky minut, kdy obě prostředí běží současně, tedy zpravidla zanedbatelnou částku vůči celkovému provozu. Na vlastním hardwaru je situace jiná: rezerva musí existovat trvale a znamená polovinu nevyužitého výkonu. Rolling update tuhle režii nemá, protože instance vyměňuje po dávkách, ale výměnou za to nenabízí jediný okamžik přepnutí ani stejně rychlý návrat zpět.

Jak ověřit zelené prostředí dřív, než na něj půjde provoz?

Zelené prostředí se ověřuje přes samostatný testovací vstup, který není veřejně publikovaný: druhý listener na jiném portu, interní hostname nebo hlavička směrující požadavek na konkrétní target group. Přes tenhle vstup projdou health checky, smoke testy hlavních uživatelských cest a kontrola připojení k databázi a externím službám. Automatizovaná sada testů běží v CI/CD pipeline a přepnutí se spustí až po jejím úspěchu. Bez odděleného vstupu se nová verze testuje až po přepnutí, což smysl blue-green nasazení oslabuje.

Zdroje

1. Blue/Green Deployments on AWS(otevře se v novém okně)Amazon Web Services
2. Application deployment and testing strategies(otevře se v novém okně)Google Cloud
3. Deployments(otevře se v novém okně)Kubernetes
4. ALTER TABLE(otevře se v novém okně)PostgreSQL Global Development Group

Související pojmy

• Load balancerLoad balancer je síťová nebo aplikační komponenta, která rozděluje příchozí provoz mezi více serverů nebo služeb. Zvyšuje dostupnost, umožňuje škálování a chrání uživatele před výpadkem jedné instance tím, že směruje požadavky jen na cíle, které podle kontrol zdraví a zvolené strategie dokážou odpovědět.
• RollbackRollback je návrat systému do posledního známého konzistentního stavu poté, co změna selhala nebo způsobila problém. V databázi ruší všechny zápisy rozpracované transakce, v nasazení vrací aplikaci na předchozí verzi. Cílem je odstranit následky neúspěšné operace bez ručního dohledávání toho, co se stihlo změnit.
• Zero downtime deploymentZero downtime deployment je způsob nasazení nové verze aplikace tak, aby uživatelé během změny neviděli výpadek služby. Opírá se o postupné přepínání provozu, kompatibilní databázové migrace, health checky a možnost rychlého návratu, protože stará a nová verze často krátce běží současně.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.
• AI agentAI agent je softwarový systém, který pomocí modelu umělé inteligence vnímá zadaný kontext, plánuje další kroky a samostatně volá nástroje nebo služby k dosažení cíle. Na rozdíl od jednorázového promptu udržuje stav úlohy, vyhodnocuje výsledky akcí a může opakovat postup, dokud nesplní zadání nebo nenarazí na limit.
• AndroidAndroid je operační systém postavený nad linuxovým jádrem, který vyvíjí Google a otevřeně uvolňuje jako projekt AOSP. Android pohání převážnou většinu chytrých telefonů, dále tablety, televize, hodinky i palubní systémy aut. Aplikace se pro něj píší hlavně v Kotlinu nebo Javě a distribuují přes Google Play i alternativní obchody.