Blue-green és canary telepítés szolgáltatás

Amit konkrétan beállítunk

Két azonos, párhuzamosan futó környezetet építünk, blue-t és green-t, és a terheléselosztón vagy az ingressen keresztül irányítjuk a forgalmat egyikről a másikra. Az új verziót a green környezetbe telepítjük, ott futtatunk automatizált füstteszteket, majd egy kapcsolással váltunk. Ha bármi hibát mutat, a váltás egyetlen parancsban visszafordítható, a régi környezet pedig addig fut tovább, amíg a mérőszámok stabilnak nem bizonyulnak. Ezt az elvet minden kiadási ciklusnál ugyanígy alkalmazzuk, függetlenül attól, mekkora a változtatás.

• Két azonos, párhuzamosan üzemeltetett éles környezet
• Váltás a terheléselosztó vagy az ingress szintjén, kézi beavatkozás nélkül
• Automatizált füsttesztek a váltás előtt, minden kiadásnál
• Canary lépcsők: kis forgalomarány, majd fokozatos bővítés

Bevált gyakorlatok, amelyeket alkalmazunk

A szünetmentes kiadás nem csak infrastruktúra kérdése, a séma- és adatbázis-kezelés is meghatározza. Ezért ugyanazt a listát alkalmazzuk minden bevezetésnél, és a te dokumentációdban is rögzítjük, a kiadási ablakok mellett. Egy visszafelé nem kompatibilis migráció, amelyet a kóddal egyszerre telepítenek, önmagában is elegendő ahhoz, hogy a blue-green előnyeit teljesen semmissé tegye, ezért ezt kezeljük a legszigorúbban. Minden kiadási tervben külön jelöljük, mely lépés érinti a sémát, és mely a kódot.

• Sémát törő migráció sosem megy egyszerre a kóddal, csak visszafelé kompatibilis lépésekben
• Automatizált füsttesztek minden váltás előtt, kötelező kapuként
• A visszaállás egyetlen parancs, előre begyakorolva
• A régi környezet addig fut, amíg a mérőszámok nem lesznek zöldek
• A kiadási ablakok a te helyi üzleti óráidhoz igazítva

Adatbázis-migráció úgy, hogy visszafelé is működjön

A legtöbb blue-green kudarc nem a kódból, hanem a sémából ered. Az expand-contract mintát alkalmazzuk: először hozzáadjuk az új oszlopot vagy táblát, mindkét verzió kompatibilis marad vele, csak ezután kapcsolunk verziót, és csak a legvégén távolítjuk el a régi mezőt, amikor már biztosan senki nem használja. Így a green környezet egy pillanatig sem fut olyan sémán, amelyet a blue verzió nem ért.

• Bővítő lépés: új mező vagy tábla, mindkét kódverzióval kompatibilisen
• Verzióváltás, csak ezután a szűkítő lépés
• A régi mezők eltávolítása csak akkor, amikor már biztosan nem használja senki

Hogyan illeszkedik az előfizetéshez

A blue-green infrastruktúra kiépítése és minden kiadási ciklus felügyelete a havi órák terhére történik: 1–8 óra a VPS-terveken, csomagtól függően 5–10 óra a dedikált és 10 óra a GPU szervereken. Az ügyfélpanel DevOps szolgáltatások menüpontjából kéred, a javasolt kiadási ablakkal. Az első bevezetés általában egy hónapot vesz igénybe, utána a rendszeres kiadások már a meglévő infrastruktúrán futnak, kisebb havi ráfordítással. A kereten felüli munkát külön, óradíj alapján számlázzuk.

Hogyan dolgozunk

1. Igényled a panelből

   Elmondod, hogyan telepítesz most, milyen gyakran, és mi okozta az utolsó leállást, majd javasolsz egy határidőt a DevOps szolgáltatások menüpontban.

2. Egyeztetjük a kereteket

   Felmérjük az architektúrát, a séma- és adatmigrációs igényeket, és meghatározzuk, milyen mérőszámok döntik el a canary-kapuk átjutását.

3. Megvalósítjuk és tesztkiadást futtatunk

   Felépítjük a két környezetet és a váltási mechanizmust, végigviszünk egy próbakiadást, teszteljük a visszaállást, majd finomítjuk a füstteszteket.

4. Dokumentálva átadjuk

   Megkapod a kiadási eljárást, a visszaállítási parancsot, a migrációs mintát és azt az ellenőrzőlistát, amelyet minden kiadás előtt alkalmazunk.

Felhasználási esetek

Technológiák

• Kubernetes
• Argo Rollouts
• NGINX Ingress
• Prometheus
• Grafana
• Flagger
• GitHub Actions

Gyakori kérdések

• Mi a különbség a blue-green és a canary telepítés között?

  A blue-green két teljes környezet közt vált egyszerre, egy kapcsolással: minden forgalom egyszerre kerül az új verzióra, a visszaállás pedig ugyanolyan gyors. A canary fokozatosan növeli az új verzióra irányított forgalom arányát, mérőszám-kapukkal ellenőrizve minden lépést, mielőtt tovább bővítené.

• Mennyi ideig tart egy visszaállás blue-green telepítésnél?

  Másodpercek, mert a visszaállás csak a terheléselosztó vagy az ingress átirányítását jelenti a korábbi, még futó környezetre, nem újratelepítést. Ez az egyik fő oka annak, hogy sok csapat áttér erre a mintára: a visszaállás nem egy stresszes újraépítés, hanem egy előre begyakorolt parancs.

• Hogyan kezelitek az adatbázis-migrációt blue-green kiadásnál?

  Az expand-contract mintát alkalmazzuk: a séma bővítése mindig megelőzi a kódváltást, és mindkét verzióval kompatibilis marad. A régi mezők eltávolítása csak azután történik, hogy biztosan egyetlen aktív verzió sem használja már őket. Így egyszerre két kódverzió is biztonságosan fut ugyanazon a sémán.

• Mennyibe kerül két teljes környezet fenntartása?

  Nem szükséges, hogy a green környezet állandóan azonos méretű legyen a bluéval: kiadás előtt fel lehet skálázni, utána pedig visszavenni. A havi órák terhére mi állítjuk be ezt az automatizmust, hogy a kettős környezet ne jelentsen kétszeres állandó költséget.

• Szükséges-e Kubernetes a blue-green telepítéshez?

  Nem feltétlenül, de sokkal egyszerűbbé teszi: a natív rollout-mechanizmusok és a szolgáltatás-hálózat jól illeszkednek a mintához. Kisebb rendszereknél két VPS-sel és egy terheléselosztóval is megvalósítható, kevesebb automatizmussal, de ugyanazzal az elvvel.

• Mi a különbség a feature flag és a canary telepítés között?

  A canary a forgalmat irányítja kódverziók között, a feature flag pedig a már telepített kódon belül kapcsol funkciókat be vagy ki, felhasználói csoportonként. A kettőt gyakran együtt használjuk: a canary a biztonságos telepítésre, a feature flag a fokozatos funkcióbevezetésre.