Zpět na domů

Blue-Green nasazení na Docker Compose bez výpadku

Článek popisuje realizaci blue-green nasazení na Docker Compose bez použití Kubernetes. Zahrnuje aspekty správy webových služeb a pozadíových workerů, graceful shutdown, kompatibilitu migrací databáze a automatizaci prostřednictvím nasazení-skriptů.

Blue-Green nasazení bez Kubernetes: praxe na Docker Compose
Advertisement 728x90

Blue-green nasazení bez Kubernetes: realizace na Docker Compose s nulovým výpadkem

Implementace blue-green nasazení je možná i bez orchestrátorů jako Kubernetes – stačí Docker Compose, nginx a promyšlená logika graceful shutdown. Tento přístup je obzvláště aktuální pro týmy pracující na dedikovaných serverech nebo virtuálních strojích, kde použití plnohodnotného klastru není výhodné z ekonomických nebo architektonických důvodů. Článek rozebírá technickou realizaci kontinuálního nasazení pro webové služby a pracovníky na pozadí s ohledem na specifika zpracování zpráv a správy stavu.

Architektura blue-green na Docker Compose

V základní konfiguraci je každá aplikace duplikována: existují dva nezávislé instance – blue a green. Oba se spouštějí jako samostatné služby v docker-compose.prod.yml, ale pouze jedna z nich přijímá provoz v daném okamžiku. Pro směrování se používá reverse proxy (v příkladu nginx), který při nasazení přepne upstream adresu. Klíčový princip: nová instance se plně spustí a projde health-check, než se zastaví stará.

Konfigurace vyžaduje explicitní specifikaci portů pro každou instanci:

Google AdInline article slot
web-blue:
  ports:
    - "127.0.0.1:8002:8000"

web-green:
  ports:
    - "127.0.0.1:8003:8000"

To umožňuje nginx oslovit potřebnou instanci přes localhost a konkrétní port. Taková schéma vylučuje kolize a zjednodušuje řízení životního cyklu.

Řízení pracovníků na pozadí

Procesy na pozadí (pracovníci), kteří konzumují zprávy z fronty (např. RabbitMQ), vyžadují speciální přístup. Jednoduché zastavení kontejneru vede k ztrátě zpráv nebo jejich opakovanému zpracování u neidempotentních operací. Řešení spočívá v implementaci graceful shutdown na úrovni aplikace.

Realizuje se to singleton třídou s příznakem is_accepting. Před zpracováním každé úlohy pracovník kontroluje tento příznak:

Google AdInline article slot
  • Pokud is_accepting == True – úloha se provede.
  • Pokud is_accepting == False – zpráva se vrátí do fronty s requeue=True.

Při přijetí signálu SIGTERM se příznak přepne na False, aplikace pak čeká na dokončení všech probíhajících úloh (s rezervou 5–10 sekund) a teprve pak ukončí práci. To zaručuje, že žádná zpráva se neztratí a nedojde k nekonzistenci dat.

Důležité nuancí:

  • U víceprocesních pracovníků (např. ProcessPoolExecutor) musí stav is_accepting být dostupný ve všech dětských procesech. Jinak někteří konzumenti pokračují v přijímání nových úloh.
  • Neidempotentní operace vyžadují dodatečnou ochranu: opakované zpracování může narušit integritu dat.
  • Použití distribuovaného příznaku (např. v Redis) architekturu komplikuje, ale v systémech s vysokou zátěží může být oprávněné.

Skript nasazení: logika krok za krokem

Skript nasazení automatizuje přepínání mezi instancemi. Logika je stejná pro webové služby i pracovníky na pozadí, liší se pouze vstupními body.

Google AdInline article slot

Hlavní fáze:

  • Určení aktivní instance (analýzou konfigurace nginx nebo seznamu běžících kontejnerů).
  • Spuštění neaktivní instance (docker compose up -d).
  • Kontrola připravenosti nové instance health-checkem (až 30 pokusů s intervalem 2 sekundy).
  • Aktualizace konfigurace nginx a provedení nginx -s reload.
  • Čekání na dokončení všech aktivních HTTP požadavků (obvykle 5 sekund).
  • Zastavení staré instance (docker compose stop).

Příklad pro webovou službu:

echo "server 127.0.0.1:${INACTIVE_PORT};" > "$UPSTREAM_CONF"
nginx -t && nginx -s reload
sleep 5
$COMPOSE stop web-${ACTIVE}

Toto pořadí zajišťuje, že provoz nikdy nesměřuje na nepřipravenou službu a stará instance končí až po úplném přepnutí.

Kompatibilita databázového schématu a migrací

Jedna z největších složitostí blue-green nasazení je souběžná práce dvou verzí aplikace se stejnou databází. Aby se předešlo chybám, musí být všechny migrace backward compatible.

Doporučený přístup je dvoufázové aktualizace:

  • První nasazení: v kódu se odstraní použití zastaralého pole/tabulky, ale struktura v databázi zůstane. Nová i stará verze fungují správně.
  • Druhé nasazení (po úplném přepnutí provozu): provede se migrace na odstranění nepoužívaných prvků schématu.

To zvyšuje počet operací, ale eliminuje riziko pádu staré instance kvůli neslučitelnosti schématu.

Co je důležité

  • Blue-green nasazení na Docker Compose je možné bez Kubernetes, ale vyžaduje manuální řízení instancí a proxy.
  • Graceful shutdown pro pracovníky na pozadí je klíčové – bez něj hrozí ztráta nebo duplikace zpráv.
  • Všechny migrace databáze musí být backward compatible; odstranění polí vyžaduje dvoufázový přístup.
  • Health-check nové instance je povinný před přepnutím provozu.
  • Konfigurace nginx se musí aktualizovat atomicky a ověřit přes nginx -t.

— Editorial Team

Advertisement 728x90

Číst dál