CI/CD mikroszolgáltatási architektúrákhoz

Azure

A gyorsabb kiadási ciklusok a mikroszolgáltatás-architektúrák egyik fő előnye. Jó CI/CD-folyamat nélkül azonban nem éri el a mikroszolgáltatások által ígért rugalmasságot. Ez a cikk ismerteti a kihívásokat, és a probléma néhány megközelítését javasolja.

Mi az a CI/CD?

Amikor a CI/CD-ről beszélünk, valójában több kapcsolódó folyamatról beszélünk: folyamatos integrációról, folyamatos teljesítésről és folyamatos üzembe helyezésről.

  • Folyamatos integráció. A kódmódosítások gyakran egyesülnek a főágban. Az automatizált buildelési és tesztelési folyamatok biztosítják, hogy a főágban lévő kód mindig éles minőségű legyen.

  • folyamatos szállítás. Az olyan kódmódosítások, amelyek átmennek a CI-folyamaton, automatikusan közzétéve lesznek egy éles környezethez hasonló környezetbe. Az élő környezetben való üzembe helyezés manuális jóváhagyást igényelhet, de máskülönben automatizált. A cél az, hogy a kód mindig legyen készen üzembe helyezésre az éles környezetben.

  • folyamatos üzembe helyezési. Az előző két lépésen átmenő kódmódosítások automatikusan éles környezetbe kerülnek.

Íme néhány cél egy robusztus CI/CD-folyamathoz egy mikroszolgáltatás-architektúra esetében:

  • Minden csapat önállóan építheti ki és helyezheti üzembe a tulajdonában lévő szolgáltatásokat anélkül, hogy más csapatokat érintenének vagy zavarnák.

  • Mielőtt üzembe helyeznénk egy szolgáltatás új verzióját az éles környezetben, üzembe kell helyezni a fejlesztési/tesztelési/minőségbiztosítási környezetekben ellenőrzés céljából. A minőségi kapukat minden szakaszban alkalmazzuk.

  • A szolgáltatás új verziója az előző verzió mellett helyezhető üzembe.

  • Megfelelő hozzáférés-vezérlési szabályzatok vannak érvényben.

  • Tárolóalapú számítási feladatok esetén megbízhat az éles környezetben üzembe helyezett tárolórendszerképekben.

Miért fontos egy robusztus CI/CD-pipeline?

Egy hagyományos monolitikus alkalmazásban egyetlen build folyamat létezik, amelynek kimenete az alkalmazás futtatható fájlja. Minden fejlesztési munka ebbe a folyamatba kerül. Ha magas prioritású hibát talál, a javítást integrálva, tesztelve és közzétéve kell tenni, ami késleltetheti az új funkciók kiadását. Ezeket a problémákat úgy háríthatja el, hogy megfelelően faktorált modulokkal és szolgáltatáságakkal minimalizálja a kódmódosítások hatását. Ahogyan az alkalmazás egyre összetettebbé válik, és további funkciókkal bővül, a monolit kiadási folyamata egyre törékenyebbé és instabillá válik.

A mikroszolgáltatások filozófiáját követve soha nem lehet hosszú kiadási folyamat, amelyben minden csapatnak sorba kell állnia. Az "A" szolgáltatást összeállító csapat a választásukkor kiadhat egy frissítést anélkül, hogy várnia kellene a "B" szolgáltatás módosításainak egyesítése, tesztelése és üzembe helyezése nélkül.

A CI/CD monolit diagramja

A nagy kiadási sebesség eléréséhez a kiadási folyamatnak automatizáltnak és megbízhatónak kell lennie a kockázat minimalizálása érdekében. Ha naponta egy vagy több alkalommal bocsát ki éles környezetben, a regresszióknak vagy a szolgáltatáskimaradásoknak ritkáknak kell lenniük. Ugyanakkor, ha egy hibás frissítés üzembe helyezésre kerül, megbízható módon kell tudni gyorsan visszatérni vagy továbblépni egy szolgáltatás egy korábbi verziójára.

Kihívások

  • Számos kis független kódbázis. Minden csapat felelős a saját szolgáltatásának kiépítéséért, saját buildelési folyamattal. Egyes szervezetekben a csapatok külön kódtárakat használhatnak. A különálló adattárak olyan helyzethez vezethetnek, amikor a rendszer felépítésének ismerete a csapatok között oszlik meg, és a szervezeten belül senki sem tudja, hogyan kell üzembe helyezni a teljes alkalmazást. Mi történik például egy adatvesztés utáni helyreállítási forgatókönyvben, ha gyorsan üzembe kell helyeznie egy új klasztert?

    Megoldás: Egységes és automatizált folyamattal hozhat létre és helyezhet üzembe szolgáltatásokat, hogy ez a tudás ne legyen "rejtett" az egyes csapatokban.

  • Több nyelv és keretrendszer. Ha minden csapat a saját technológiáit használja, nehéz lehet egyetlen, a szervezet egészében működő buildelési folyamatot létrehozni. A buildelési folyamatnak elég rugalmasnak kell lennie ahhoz, hogy minden csapat hozzá tudja igazítani a választott nyelvhez vagy keretrendszerhez.

    kockázatcsökkentési: Az egyes szolgáltatások buildelési folyamatának tárolóba helyezése. Így a buildrendszernek képesnek kell lennie a tárolók futtatására.

  • Integrációs és terhelési tesztelés. Mivel a csapatok a saját tempójukban bocsátanak ki frissítéseket, nehéz lehet robusztus, végpontok közötti tesztelést tervezni, különösen akkor, ha a szolgáltatások más szolgáltatásoktól függenek. Ráadásul a teljes éles fürt futtatása költséges lehet, ezért nem valószínű, hogy minden csapat saját teljes fürtöt futtat éles skálán, csak tesztelés céljából.

  • Kiadáskezelési. Minden csapatnak képesnek kell lennie arra, hogy üzembe helyezzen egy frissítést az éles környezetben. Ez nem jelenti azt, hogy minden csapattag rendelkezik erre vonatkozó engedélyekkel. A központi Release Manager-szerepkör azonban csökkentheti az üzembe helyezés sebességét.

    Mérséklés: Minél inkább automatizált és megbízható a CI/CD folyamat, annál kevésbé van szükség központi hatóságra. Ennek ellenére előfordulhat, hogy különböző szabályzatokkal rendelkezik a főbb funkciófrissítések kiadásához és az apró hibajavításokhoz. A decentralizáltság nem jelenti a zéró irányítást.

  • szolgáltatásfrissítések. Amikor egy szolgáltatást új verzióra frissít, az nem szakíthatja meg az attól függő egyéb szolgáltatásokat.

    Kárenyhítési: Használjon olyan üzembe helyezési technikákat, mint a kék-zöld vagy a kanári-kiadás a nem kompatibilitástörő változásokhoz. Az API-módosítások feltörése érdekében helyezze üzembe az új verziót az előző verzió mellett. Így az előző API-t használó szolgáltatások frissíthetők és tesztelhetők az új API-hoz. További információért lásd a cikkben található frissítési szolgáltatások szakaszt.

Monorepo vs. több adattár

A CI/CD-munkafolyamat létrehozása előtt ismernie kell a kódbázis felépítését és kezelését.

  • A csapatok külön adattárakban vagy monorepóban (önálló adattárban) működnek?
  • Mi az elágaztatási stratégia?
  • Ki küldhet le kódot az éles környezetbe? Van kiadáskezelői szerepkör?

A monorepó megközelítés egyre népszerűbbé válik, azonban mindkettőnek megvannak a maga előnyei és hátrányai.

  Monorepo Több tároló
Előnyök Kódmegosztás
Egyszerűbben szabványosíthatja a kódokat és az eszközöket
Könnyebb a kód átszervezése
Felderíthetőség – a kód egyetlen nézete
 Tulajdonosi viszony törlése csapatonként
Potenciálisan kevesebb egyesítési ütközés
Segít a mikroszolgáltatások leválasztásának kikényszerítésében
kihívások A megosztott kód módosítása több mikroszolgáltatást is érinthet
Nagyobb az egyesítési ütközések lehetősége
Az eszközöknek nagy kódbázishoz kell alkalmazkodniuk
Hozzáférés-vezérlés
Összetettebb üzembehelyezési folyamat		 Nehezebb megosztani a kódot
Nehezebb kikényszeríteni a kódolási szabványokat
Függőségkezelés
Diffúz kódbázis, gyenge felderíthetőség
A megosztott infrastruktúra hiánya

Szolgáltatások frissítése

A már éles környezetben lévő szolgáltatás frissítésére különböző stratégiák állnak rendelkezésre. Az alábbiakban három gyakori lehetőséget ismertetünk: a gördülő frissítést, a kék zöld üzembe helyezést és a kanári kiadást.

Fokozatos frissítések

Egy gördülő frissítés során üzembe helyezi a szolgáltatás új példányait, és az új példányok azonnal megkezdik a kérések fogadását. Az új példányok előkerülése során a rendszer eltávolítja az előző példányokat.

Példa. A Kubernetesben a gördülő frissítések jelentik az alapértelmezett viselkedést az üzembe helyezés podspecifikációjának frissítésekor. Az üzembehelyezési vezérlő létrehoz egy új ReplicaSetet a frissített podokhoz. Ezután felskálázza az új ReplicaSetet, miközben lecsökkenti a régit, hogy fenntartsa a kívánt replikaszámot. Nem törli a régi podokat, amíg az újak nem állnak készen. A Kubernetes megőrzi a frissítés előzményeit, így szükség esetén visszaállíthatja a frissítést.

Példa. Az Azure Container Apps változatokkal kezeli a folyamatos frissítéseket. Új változat üzembe helyezésekor a Container Apps a forgalom felosztási szabályaival fokozatosan át tudja helyezni a forgalmat a régi változatról az újra. Ha az új változat problémákat tapasztal, visszairányíthatja a forgalmat az előző változatra. Egyszerre több aktív változatot is konfigurálhat, és szabályozhatja az egyes változatok által kapott forgalom százalékos arányát.

A működés közbeni frissítések egyik kihívása, hogy a frissítési folyamat során a régi és az új verziók vegyesen futnak és fogadják a forgalmat. Ebben az időszakban minden kérés a két verzió valamelyikére irányítható.

A kompatibilitástörő API-módosítások esetében ajánlott mindkét verziót egymás mellett támogatni, amíg az előző verzió összes ügyfele nem frissül. Lásd API verziószámozási.

Kék-zöld üzembe helyezés

Kék-zöld telepítés esetén az új verziót az előző verzió mellett helyezi üzembe. Az új verzió ellenőrzése után az összes forgalmat egyszerre váltja át az előző verzióról az új verzióra. A váltás után az alkalmazás figyeli az esetleges problémákat. Ha valami nem sikerül, visszacserélheti a régi verzióra. Feltéve, hogy nincsenek problémák, törölheti a régi verziót.

A hagyományos monolitikus vagy N szintű alkalmazások esetében a kék-zöld üzembe helyezés általában két azonos környezet kiépítését jelentette. Az új verziót üzembe helyezné egy átmeneti környezetben, majd átirányítaná az ügyfélforgalmat az átmeneti környezetbe – például a VIP-címek felcserélésével. A mikroszolgáltatás-architektúrában a frissítések a mikroszolgáltatás szintjén történnek, ezért általában ugyanabban a környezetben helyezné üzembe a frissítést, és egy szolgáltatásfelderítési mechanizmust használna a felcseréléshez.

példa. A Kubernetesben nem kell külön fürtöt kiépítenie a kék-zöld üzembe helyezéshez. Ehelyett kihasználhatja a választókat. Hozzon létre egy új Deployment erőforrást új pod konfigurációval és egy új címkekészlettel. Hozza létre ezt az üzembe helyezést az előző üzembe helyezés törlése vagy az arra hivatkozó szolgáltatás módosítása nélkül. Miután az új podok futnak, frissítheti a szolgáltatás választóját, hogy megfeleljen az új üzembe helyezésnek.

A kék-zöld üzembe helyezés egyik hátránya, hogy a frissítés során kétszer annyi podot futtat a szolgáltatáshoz (aktuális és következő). Ha a podok jelentős processzor- vagy memóriaerőforrást igényelnek, előfordulhat, hogy ideiglenesen fel kell skáláznia a fürtöt az erőforrás-felhasználás kezeléséhez.

Canary kiadás

Egy kanári kiadásban először üzembe helyez egy frissített verziót az ügyfelek egy kis részhalmazában. Ezután figyelheti az új szolgáltatás viselkedését, mielőtt az összes ügyfél számára üzembe lenne gördülve. Ez a megközelítés lehetővé teszi, hogy fokozatosan, szabályozott módon vezessen be, monitorozza a valós adatokat, és azonosítsa a problémákat, mielőtt azok az összes ügyfelet érintenék.

A kanári kiadás kezelése összetettebb, mint a kék-zöld kiadás vagy a gördülő frissítés, mert a kéréseket dinamikusan kell irányítania a szolgáltatás különböző verzióira.

példa. A Kubernetesben konfigurálhat egy szolgáltatás két replikakészletre (mindegyik verzióhoz egyet), és manuálisan módosíthatja a replikák számát. Ez a megközelítés azonban meglehetősen durva szemcsés, mivel a Kubernetes terheléselosztása a podok között történik. Ha például összesen 10 replikával rendelkezik, a forgalmat csak 10% növekményben helyezheti át. Ha szolgáltatáshálót használ, a szolgáltatásháló útválasztási szabályaival kifinomultabb kanári-kibocsátási stratégiát valósíthat meg.

Következő lépések