Megosztás a következőn keresztül:

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ós. 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 kézbesítési. A CI-folyamatot átadó kódmódosítások automatikusan közzé lesznek téve egy éles környezetbe. Az éles éles 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 üzembe kerülnek az éles.

Í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 érvényesítjük.

  • 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-folyamat?

A hagyományos monolitikus alkalmazásokban egyetlen buildfolyamat létezik, amelynek kimenete az alkalmazás végrehajtható. 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. De ahogy az alkalmazás egyre összetettebbé válik, és további funkciókkal bővül, a monolith kiadási folyamata egyre törékenyebbé válik, és valószínűleg megszakad.

A mikroszolgáltatások filozófiáját követve soha nem lehet hosszú kiadású vonat, ahol minden csapatnak sorba kell szállnia. Az "A" szolgáltatást összeállító csapat bármikor 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.

CI/CD monolith 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ése nem történik meg, megbízható módon kell gyorsan visszatérnie vagy egy szolgáltatás egy korábbi verziójára visszatérnie.

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 vészhelyreállítási forgatókönyvben, ha gyorsan üzembe kell helyeznie egy új fürtöt?

    kockázatcsökkentési: 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éstesztelési. 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. A teljes éles fürt futtatása ráadásul költséges is 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.

    kockázatcsökkentési: Minél inkább automatizált és megbízható a CI/CD-folyamat, annál kevésbé lesz 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. Lásd az alábbi Szolgáltatások frissítése.

Monorepo vs. több adattár

A CI/CD-munkafolyamat létrehozása előtt tudnia kell, hogyan lesz strukturálva és felügyelve a kódbázis.

  • 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 előnyre tett szert, de mindkettőnek vannak előnyei és hátrányai.

  Monorepo Több adattár
Előnyök Kódmegosztás
Egyszerűbben szabványosíthatja a kódokat és az eszközöket
Kód egyszerűbb újrabontása
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ázisra kell skálázniuk
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ások 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.

Működés közbeni frissítések

Egy folyamatban lévő frissítésben új szolgáltatáspéldányokat helyez üzembe, é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 működés közbeni frissítések az alapértelmezett viselkedést képezik az Üzembe helyezésipod-specifikációjának frissítésekor. Az üzembehelyezési vezérlő létrehoz egy új ReplicaSetet a frissített podokhoz. Ezután vertikálisan felskálázza az új ReplicaSetet, miközben a régit skálázza, 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 Service Fabric alapértelmezés szerint a működés közbeni frissítési stratégiát használja. Ez a stratégia a szolgáltatás egy verziójának új funkciókkal történő üzembe helyezéséhez ideális, a meglévő API-k módosítása nélkül. A Service Fabric úgy indítja el a frissítés üzembe helyezését, hogy az alkalmazástípust a csomópontok vagy egy frissítési tartomány egy részhalmazára frissíti. Ezután a következő frissítési tartományba kerül, amíg az összes tartományt nem frissíti. Ha egy frissítési tartomány frissítése sikertelen, az alkalmazástípus az összes tartomány előző verziójára vált. Vegye figyelembe, hogy egy több szolgáltatást tartalmazó alkalmazástípus (és ha az összes szolgáltatás egy frissítési üzembe helyezés részeként frissül) meghibásodásra hajlamos. Ha egy szolgáltatás nem frissül, a teljes alkalmazás vissza lesz állítva az előző verzióra, a többi szolgáltatás pedig nem frissül.

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 környezetben 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 üzembe helyezési erőforrást egy új podspektekkel és egy másik 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 sok 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 egy frissített verziót fog létrehozni egy kis számú ügyfél számára. 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 lehetővé teszi a lassú bevezetést szabályozott módon, valós adatok megfigyelése és problémák észlelésében, mielőtt az összes ügyfél érintett lesz.

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

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