Zero downtime deployment (nasazení bez výpadku)

Příklady z praxe

1. 01

   Rolling update v Kubernetes

   Tým nasazuje novou verzi webového API do Kubernetes. Nastavení nedovolí, aby během výměny zmizela dostupná replika, a nová replika začne dostávat provoz až po úspěšném readiness checku. Pokud obraz neprojde startem nebo endpoint /ready hlásí chybu, rollout se zastaví dřív, než provoz dopadne na rozbitou verzi.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web
   spec:
     replicas: 4
     strategy:
       type: RollingUpdate
       rollingUpdate:
         maxUnavailable: 0
         maxSurge: 1
     template:
       spec:
         containers:
           - name: web
             image: example/web:2.4.0
             readinessProbe:
               httpGet:
                 path: /ready
                 port: 8080

2. 02

   Databázová migrace bez rozbití staré verze

   Aplikace má přejít ze dvou sloupců first_name a last_name na jeden sloupec full_name. První migrace jen přidá nový sloupec a doplní data, takže stará i nová verze aplikace mohou krátce fungovat současně. Odstranění starých sloupců přijde až v dalším nasazení, po ověření, že žádná běžící verze už staré sloupce nepotřebuje.

   ALTER TABLE customers ADD COLUMN full_name text;
   
   UPDATE customers
   SET full_name = first_name || ' ' || last_name
   WHERE full_name IS NULL;
   
   -- Po nasazení nové verze a ověření provozu:
   -- ALTER TABLE customers DROP COLUMN first_name;
   -- ALTER TABLE customers DROP COLUMN last_name;

Časté omyly

MýtusZero downtime deployment znamená, že stačí rychle restartovat aplikaci.

Ve skutečnostiRychlý restart může snížit délku výpadku, ale sám o sobě výpadek neodstraňuje. Bezvýpadkové nasazení potřebuje směrování provozu na zdravé instance a kontrolu, že nová verze je připravená.

MýtusKdyž máme Kubernetes, máme zero downtime deployment automaticky.

Ve skutečnostiKubernetes umí řídit rolling update, ale aplikace musí mít správné readiness checky, dost replik a kompatibilní změny. Chybně navržená migrace databáze nebo endpoint, který hlásí připravenost příliš brzy, může způsobit výpadek i v Kubernetes.

Časté dotazy

Zaručuje zero downtime deployment, že uživatelé nepoznají žádnou chybu?

Zero downtime deployment neznamená, že každé nasazení je automaticky bezpečné pro uživatele. Bezvýpadkový průběh chrání dostupnost služby, ale nová verze může stále obsahovat chybu v logice, špatné oprávnění nebo pomalý dotaz. Kvalitní proces proto kombinuje postupné směrování provozu, automatické testy, monitoring, alerty a připravený rollback.

Které změny nejčastěji brání nasazení bez výpadku?

Zero downtime deployment je nejtěžší u změn, které nejsou zpětně kompatibilní. Typickým příkladem je databázové schéma, formát zpráv ve frontě, veřejné API nebo změna session úložiště. Bezpečný postup rozdělí změnu do několika kroků, aby stará i nová verze uměly po přechodnou dobu pracovat se stejnými daty.

Stačí pro zero downtime deployment jeden server?

Zero downtime deployment obvykle vyžaduje více než jeden server nebo více běžících instancí služby. Samostatný proces na jednom stroji lze někdy restartovat velmi rychle, ale po dobu restartu nemusí přijímat požadavky. Skutečné bezvýpadkové nasazení potřebuje mechanismus, který udrží dostupnou starou instanci, dokud nová instance není připravená.

Jaké health checky jsou důležité pro zero downtime deployment?

Zero downtime deployment potřebuje health checky, které měří skutečnou připravenost aplikace. Kontrola otevřeného portu nestačí, protože aplikace může běžet, ale nemít připojení k databázi, načtenou konfiguraci nebo dokončené migrace. Readiness check má rozhodnout, zda může instance dostávat provoz, zatímco liveness check řeší restart zaseknutého procesu.

Zdroje

1. Deployments(otevře se v novém okně)Kubernetes
2. Application deployment and testing strategies(otevře se v novém okně)Google Cloud
3. Ensuring rollback safety during deployments(otevře se v novém okně)Amazon Web Services
4. ALTER TABLE(otevře se v novém okně)PostgreSQL

Související pojmy

• CI/CDCI/CD je sada postupů a automatizací, které průběžně integrují změny kódu, ověřují je testy a připravují nebo provádějí nasazení aplikace. Cílem je zkrátit cestu od commitu k bezpečnému vydání, snížit ruční práci a rychle odhalit chyby v build procesu, konfiguraci nebo samotném kódu.
• 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.
• Blue-green deploymentBlue-green deployment je způsob nasazování aplikací, při kterém běží dvě identická produkční prostředí: jedno obsluhuje provoz, druhé přijímá novou verzi. Po ověření nové verze se provoz přepne najednou, obvykle na úrovni load balanceru nebo DNS. Staré prostředí zůstává nedotčené, takže návrat k předchozí verzi je otázkou vteřin.
• Migrace databázeMigrace databáze je řízená změna struktury, obsahu nebo umístění databáze tak, aby aplikace dál pracovala se správnými daty. V praxi zahrnuje skripty pro úpravu schématu, přesun a čištění dat, testování, zálohy, nasazení ve správném pořadí a plán návratu při selhání.
• 3D model3D model je digitální reprezentace objektu nebo prostoru ve třech rozměrech, složená z geometrie, materiálů a často i textur, animací či fyzikálních vlastností. Používá se v hrách, filmech, průmyslovém návrhu, architektuře, e-commerce i simulacích, kde software z modelu počítá zobrazení nebo další data.
• 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.