Napjainkban számos telepítési stratégia közül lehet választani, és idővel még több lesz. Azt viszont mondhatjuk, hogy a ma a legnagyobb vállalatok által aktívan használt két leggyakoribb telepítési stratégia a Canary és a Blue-green telepítési stratégia.
A Blue-Green deployment és a Canary összehasonlításakor nem csak a sebesség vagy az egyszerűség számít. Az egyik legfontosabb szempont az üzemszünet hossza, amelyet figyelembe kell venni a stratégia kiválasztásakor.
Az üzemszünet minimalizálása és a frissítések vagy módosítások üzembe helyezésekor való zökkenőmentes átmenet biztosítása érdekében kritikus fontosságú a Canary deployment vs. Blue-Green közül a megfelelőbb lehetőség kiválasztása.
Nézzük meg, mit kínál az egyes stratégia, beleértve a Blue-Green deployment vs. Canary közvetlen összehasonlítását és a saját tapasztalatainkat a Canary deployment vs. Blue-Green deployment terén.
Mi a Blue-Green Deployment, és mit kínál?
A Blue-Green deployment stratégiánál az alkalmazás új verziója azonnal üzembe helyezhető, miután tesztelték és validálták. Ez két azonos környezetnek köszönhető: a kék és zöld környezetnek, amely a Blue-Green deployment nevet adja.
Ez azért működik, mert az egyik környezet aktív, a másik pedig inaktív. Az alkalmazás új verziója az inaktív környezetbe helyezhető (mondjuk a zöldbe). Mivel ez a két környezet teljesen azonos az erőforrások, infrastruktúra és konfigurációk tekintetében, a frissítésben felmerülő problémák megoldhatók a teljes üzembe helyezés előtt.
Miután a frissítést tesztelték és a fejlesztők biztosak benne, hogy működik, az élő forgalom erre az inaktív környezetre vált. Ezáltal az inaktív környezet (a zöld) aktívvá válik, az előzőleg aktív környezet (a kék) pedig inaktívvá.
Az inaktív kék környezet mostantól tartalék lesz, és felhasználható az újabb frissítések tesztelésére, míg a zöld környezet aktív marad és az újonnan üzembe helyezett frissítést futtatja. Így gyakorlatilag nincs üzemszünet, mivel a forgalom azonnal az inaktív környezetre vált.
Emellett, ha a frissítésnek vannak problémái, egy rollback funkció lehetővé teszi az alkalmazás régebbi verziójára való visszaváltást. Azonban ha problémák adódnak, amikor a fejlesztők már egy új frissítésen dolgoznak az inaktív környezetben, az erre a környezetre való visszaváltás már nem lehetséges, mivel az older verzió már nem érhető el ebben a környezetben sem.
Bár sok cég és szervezet ezt a stratégiát alkalmazza, ennek a stratégiának egy jó példája a Spotify. Mivel a Spotify szolgáltatásainak 24/7 elérhetőnek kell lenniük, mindig rendelkezik egy készenléti, inaktív környezettel az új frissítések kiadásakor.
Mi a Canary Deployment, és mit kínál?
A Canary deployment vs. Blue-Green közötti fő különbség az, hogy ahelyett, hogy két környezet lenne, ahol a frissítéseket egyszerre telepítik az összes felhasználó számára, a Canary deployment stratégiában a frissítéseket először egy kis felhasználói csoport kapja meg.
Ha a frissítésnek vannak problémái, csak a felhasználók egy kis része tapasztalja meg, és visszajelzést adhat. Miután a problémákat megoldották, a frissítés a felhasználók nagyobb csoportjára kerül, akik visszajelzést adnak a fejlesztőknek, ha problémákat tapasztalnak.
Ez a ciklus ismétlődik az egyre nagyobb felhasználói csoportokkal, és a frissítés összes problémáját megoldják, amíg a frissítés el nem jut a 100%-os felhasználói bázishoz. Például először csak a 2%-hoz kerülne a frissítés, majd a 25%-hoz, aztán a 75%-hoz, végül pedig a 100%-hoz.
A Canary deployment vs. Blue-Green esetén ez a fokozatos kiadás egy kontrolláltabb és rugalmasabb kibocsátást kínál, lehetővé téve a fejlesztőknek a funkciók és frissítések tesztelését egy irányított környezetben, ahol csak kevesen tapasztalnak potenciális problémákat.
Végül, a Canary hasonló rollback funkcióval is rendelkezik; azonban mivel a deployment fokozatosan és szakaszokra történik, a Canary-ban végzett rollback is fokozatosan és szakaszokra történik, amíg egy stabil verzióra nem érünk.
Ennek a deployment stratégiának jól ismert példája a Netflix, amely a Canary-t a Chaos Monkey nevű eszközzel használja, amely szándékosan hibákat vezet be a rendszerükbe. Ha egy hiba érinti a canary környezetet, a Netflix csapat elemezni tudja, hogyan reagál a rendszer, és ennek megfelelően módosíthat. Így a Netflix ellenőrizheti, hogy a frissítés stabil és rugalmas marad még kedvezőtlen körülmények között is.
Blue-Green Deployment vs. Canary
Mindkét deployment stratégia saját egyedi előnyöket kínál; azonban korlátaik is vannak. Ezért fontos a Blue-Green development vs. Canary előnyeit és hátrányait mérlegelni a döntés meghozatala előtt.
Ha továbbra sem vagy biztos, melyiket válaszd, a cikkben végén szerepel a saját tapasztalatunk ezzel a két stratégiával, és amit ebből tanultunk.
Leállási idő csökkentése
Ennek a cikknek a fő témája a Blue-Green és a Canary deployment üzemeltetési idejének csökkentésének összehasonlítása. A Blue-Green deployment nagy előnye a sebessége: az alkalmazás frissítéseit vagy új funkcióit azonnal telepítheti a két környezet kihasználásával.
A Canary viszont fokozatos telepítésével minimális leállási időt ér el, mivel csak felhasználók egy kis csoportja szembesül a problémákkal, és mivel minden szakaszban van visszajelzés, a hibaelhárítás gyorsabb és üzemeltetési idő nélkül történhet.
Mindkét megoldás kínál visszaállítási funkciókat, de a Blue-Green deployment azonnali visszaállítást biztosít, ami megbízható biztonsági másolatot jelent nagyobb hibák esetén. Ez azonban azzal a kockázattal jár, hogy ha az inaktív környezetben újabb verzión dolgoznak, a korábbi verzió nem lesz elérhető.
A Canary visszaállítása csak fokozatos lehet, ugyanúgy, mint a telepítése. Ennek viszont az az előnye, hogy mindig elérhető, mivel az aktuális, stabil verzió nem függ attól, hogy melyik környezetben tesztelik és fejlesztik az új frissítéseket.
A Canary és a Blue-Green deployment összehasonlításában a Canary jobb a kockázat- és a szemcsés vezérlés terén, azonban ha pusztán az üzemeltetési idő csökkentésére gondolunk, akkor a Blue-Green előnyösebb, mivel az átváltás azonnali.
Azonban a Blue-Green és a Canary deployment összehasonlításakor az üzemeltetési idő mellett más tényezőket is figyelembe kell venni.
Alkalmazás típusa
Az alkalmazásokat általában tranzakcióintenzívekre vagy tartalomvezéreltekre oszthatjuk. Tranzakcióintenzív alkalmazások esetén a Blue-Green deployment sokkal jobb megoldás, mivel a magas szolgáltatási rendelkezésre állás és a minimális leállási idő prioritás, és éppen ezért a Blue-Green azonnali átváltása és visszaállítása előnyt jelent a Canaryval szemben.
A tartalomvezérelt alkalmazások viszont nem függnek valós idejű tranzakciók. Mivel ezeket az alkalmazásokat jellemzően közösségi média platformok és felhasználókövetkeztetési szolgáltatások használják, a Canary sokkal jobb stratégia, mivel fokozatosan можете kiadni a frissítéseket, és minden szakaszban folyamatosan kapnak visszajelzéseket.
Infrastruktúra költségek
Egy másik fontos szempont a Blue-Green és a Canary deployment választásakor a költségvetés. Értelemszerűen a Blue-Green deployment költségei magasabbak, mivel két külön környezetet kell fenntartani.
Ezért a Canary egyetlen termelési környezete sokkal költségkímélőbb megoldás, ami ideálisabb a kisebb csapatok vagy kevesebb erőforrást igénylő alkalmazások számára.
Skálázhatóság és hosszú távú karbantartás
Végül, a Blue-Green deployment ugyan skálázható, de nagy méretű alkalmazások esetén két teljes környezet fenntartása erőforrás-igényes és bonyolult lehet. Az idő múlásával az ismétlődő környezetek kezelése és fenntartása jelentős terhet adhat, különösen olyan alkalmazások esetén, amelyeknek összetett infrastruktúrájuk van.
Ez a Canary és a Blue-Green deployment összehasonlítását a méretezhetőség és a karbantartás terén viszonylag egyértelművé teszi. A Canary deployment esetén a méretezhetőség gyakran egyszerűbb és költséghatékonyabb, mivel nem igényli az ismétlődő környezeteket.
Helyette az elsődleges környezetben történő méretezésre összpontosít, fokozatosan bővítve azoknak a felhasználóknak a körét, akik az új változásoknak vannak kitéve. Ez a beállítás hosszú távon sokkal könnyebben kezelhető, mivel csökkenti az infrastruktúra összetettségét és egyszerűsíti a karbantartást.
Az Cloudzy tapasztalata a Blue-Green Deployment vs. Canary Deployment terén
A DevOps-szolgáltatások ügyfeleknek történő nyújtásakor tudjuk, hogy az ügyfélelégedettség, a magas rendelkezésre állás és a minimális üzemeltetési idő kritikus fontosságú a vállalat sikeréhez. Egy konkrét esetben egy ügyfél megkeresett bennünket egy nagy infrastruktúra-frissítésben való segítségért. A csapatnak a Blue-Green deployment és a Canary deployment közül kellett választania.
Hosszú megfontolás után úgy döntöttünk, hogy először a Blue-Green deploymentet próbáljuk ki, mivel ez gyakorlatilag nulla üzemeltetési időt kínál. Létrehoztunk egy azonos zöld környezetet, és felkészültünk a frissítés kiadására. Sok nyomás nehezedett ránk, mivel egy gombnyomásra az összes forgalom a zöld környezetbe kerülne, és ahogy a fejlesztők tudják, nem számít, mennyire alaposan tesztelik meg ezeket, mindig van valami bizonytalan a kimenetelben.
Szerencsére minden jól sült el. Az átmenet olyan sima volt, mint a vaj, és szinte nem voltak problémáink. Az idő múlásával az ügyfél szolgáltatásai és felhasználói száma nőtt, és új funkciókat kellett kiadni, így a Blue-Green vs. Canary vita ismét felmerült.
Ez azonban már nem volt igazi vita. Ezek viszonylag kisebb funkciók voltak, semmiképpen nem az infrastruktúra-frissítés méretéből. Ezért természetesen a Canary mellett döntöttünk, mivel az ügyfél felhasználóbázisának kis részének kiadhatjuk a funkciókat, és a visszajelzések alapján megoldhatjuk a felmerülő problémákat.
Ez valóban a helyes döntés volt, mert bár nem voltak nagyobb problémák, néhány kisebb hiba felbukkant, amelyeket az ügyfél felhasználóbázisának az 5%-a jelentett, akiknek a funkcióhoz hozzáférésük volt.
Az Cloudzy-nél hiszünk a személyre szabott megoldások erejében. Legyen szó a Blue-Green deployment megbízhatóságáról vagy a Canary deployment rugalmasságáról, a DevOps csapatunk rendelkezik azzal a tapasztalattal és ismerettel, hogy a legjobb stratégiát valósítsa meg az infrastruktúrájához. Vegyenek fel velünk kapcsolatot itt és megtudhatják, hogyan optimalizálhatjuk a telepítési folyamatot és tarthatjuk az üzemeltetést simán.
Az VPS-ről szólva, az VPS iparágban a legalacsonyabb díjak közé tartozunk, olyan funkciókat kínálva, mint több mint 12 hely a világszerte, dedikált internetkapcsolatok akár 10 Gbps-ig, vállalati NVMe SSD tárhelykapacitás, hatékony 3.23 GHz turbo sebességű AMD EPYC processzorok és 99.95%-os rendelkezésre állás. Nézze meg VPS árképzés további részletekért.
Végső gondolatok
Végül is, a Canary és a Blue-Green deployment összehasonlításakor nem lehet azt mondani, hogy az egyik jobban teljesít az másikon egyoldalúan. Ez pusztán az alkalmazási módokról szól, és arról, hogy melyik illik a leginkább az Ön konkrét igényeihez.
Gyakran Ismételt Kérdések
Mi a fő különbség a blue-green és canary deployment-ek között?
A Blue-Green és a Canary deployment stratégiák közötti fő különbség a frissítések kiadásának módjában rejlik. A Blue-Green deployment két azonos környezetet használ, a frissítéseket az inaktívba alkalmazza, lehetővé téve az azonnali átváltást gyakorlatilag nulla üzemeltetési idővel. Ezzel szemben a Canary deployment fokozatosan adja ki a frissítéseket a felhasználók egy kis csoportjának, monitorozza a problémákat, majd fokozatosan a teljes felhasználóbázisnak adja ki.
Melyik jobb az üzemszünet csökkentésére: a Blue-Green deployment vagy a canary deployment?
A Blue-Green deployment általában jobb az üzemeltetési idő csökkentésében, mivel azonnali átváltást tesz lehetővé a környezetek között. Ez minimalizálja a lehetséges zavaróhatásokat. Bár a Canary deployment szintén az üzemeltetési idő csökkentésére törekszik, ezt fokozatos kiadáson keresztül éri el, amely kisebb, lokalizált problémákat okozhat csak felhasználók egy kis csoportjánál.
Milyen költségvetési szempontok vannak a blue-green vs. canary deployment-ek esetén?
A kék-zöld telepítés jellemzően drágább, mivel két teljes környezet karbantartása szükséges. A kanaritelepítés ezzel szemben költséghatékonyabb, mert nem igényel duplikált infrastruktúrát - a frissítések az elsődleges környezetben történnek, ami kisebb csapatoknál vagy kevésbé erőforrásigényes alkalmazásoknál ideálisabb választás.
