Rychlejší cykly vydávání verzí jsou jednou z hlavních výhod architektury mikroslužeb. Bez dobrého procesu CI/CD ale nedosáhnete flexibility, kterou mikroslužby slibují. Tento článek popisuje výzvy a doporučuje některé přístupy k problému.
Co je CI/CD?
Když mluvíme o CI/CD, opravdu hovoříme o několika souvisejících procesech: kontinuální integraci, průběžné doručování a průběžné nasazování.
kontinuální integrace. Změny kódu se často sloučí do hlavní větve. Automatizované procesy sestavení a testování zajišťují, aby kód v hlavní větvi byl vždy v produkční kvalitě.
průběžného doručování. Všechny změny kódu, které předají proces CI, se automaticky publikují do produkčního prostředí. Nasazení do produkčního prostředí za provozu může vyžadovat ruční schválení, ale jinak je automatizované. Cílem je, aby váš kód měl být vždy připravený k nasazení do produkčního prostředí.
průběžného nasazování . Změny kódu, které předávají předchozí dva kroky, se automaticky nasadí do produkčního.
Tady jsou některé cíle robustního procesu CI/CD pro architekturu mikroslužeb:
Každý tým může vytvářet a nasazovat služby, které vlastní nezávisle, aniž by to ovlivnilo nebo nenarušilo jiné týmy.
Před nasazením nové verze služby do produkčního prostředí se nasadí do prostředí pro vývoj/testování/kontrolu kvality pro ověření. V každé fázi se vynucují brány kvality.
Vedle předchozí verze je možné nasadit novou verzi služby.
Jsou zavedeny dostatečné zásady řízení přístupu.
U kontejnerizovaných úloh můžete důvěřovat imagím kontejnerů, které jsou nasazené do produkčního prostředí.
Proč záleží na robustním kanálu CI/CD
V tradiční monolitické aplikaci existuje jeden kanál sestavení, jehož výstupem je spustitelný soubor aplikace. Všechny vývojové pracovní kanály do tohoto kanálu. Pokud se najde chyba s vysokou prioritou, musí být oprava integrovaná, otestovaná a publikovaná, což může zpozdit vydání nových funkcí. Tyto problémy můžete zmírnit díky dobře faktorovaným modulům a používání větví funkcí, abyste minimalizovali dopad změn kódu. S tím, jak aplikace roste složitější a přidají se další funkce, proces vydávání monolitických verzí má tendenci se stát více křehkým a pravděpodobně se přeruší.
Podle filozofie mikroslužeb by nikdy nemělo existovat dlouhý trénink vydávání, kde se každý tým musí dostat do souladu. Tým, který sestavuje službu A, může kdykoli vydat aktualizaci, aniž by čekal na sloučení, otestování a nasazení změn ve službě B.
CI/CD
Aby bylo možné dosáhnout vysoké rychlosti vydávání, musí být kanál verze automatizovaný a vysoce spolehlivý, aby se minimalizovalo riziko. Pokud vydáte do produkčního prostředí jednou nebo vícekrát denně, musí být regrese nebo přerušení služeb vzácné. Pokud se současně nasadí chybná aktualizace, musíte mít spolehlivý způsob, jak rychle vrátit zpět nebo vrátit zpět předchozí verzi služby.
Výzvy
mnoho malých nezávislých základů kódu. Každý tým zodpovídá za vytvoření vlastní služby s vlastním kanálem buildu. V některých organizacích můžou týmy používat samostatná úložiště kódu. Samostatná úložiště můžou vést k situaci, kdy se znalosti o tom, jak vytvořit systém, šíří mezi týmy a nikdo v organizaci neví, jak nasadit celou aplikaci. Co se například stane ve scénáři zotavení po havárii, pokud potřebujete rychle nasadit do nového clusteru?
zmírnění rizik: Máte jednotný a automatizovaný kanál pro sestavování a nasazování služeb, aby tyto znalosti nebyly v každém týmu "skryté".
více jazyků a architektur. S každým týmem, který používá vlastní kombinaci technologií, může být obtížné vytvořit jeden proces sestavení, který funguje v celé organizaci. Proces sestavení musí být dostatečně flexibilní, aby ho každý tým mohl přizpůsobit pro svůj výběr jazyka nebo architektury.
zmírnění: Kontejnerizujte proces sestavení pro každou službu. Tímto způsobem stačí, aby systém sestavení mohl spouštět kontejnery.
integrace a zátěžové testování. Díky týmům, které vydávají aktualizace vlastním tempem, může být náročné navrhnout robustní komplexní testování, zejména pokud mají služby závislosti na jiných službách. Kromě toho může být provoz kompletního produkčního clusteru nákladný, takže je nepravděpodobné, že každý tým bude spouštět svůj vlastní úplný cluster v produkčním měřítku jen pro účely testování.
release management. Každý tým by měl být schopný nasadit aktualizaci do produkčního prostředí. To neznamená, že každý člen týmu má oprávnění k tomu. Centralizovaná role Release Manageru ale může snížit rychlost nasazení.
zmírnění rizik: Čím více je proces CI/CD automatizovaný a spolehlivý, tím méně by mělo být potřeba centrální autority. To znamená, že můžete mít různé zásady pro vydávání hlavních aktualizací funkcí a menší opravy chyb. Decentralizované řízení neznamená nulové zásady správného řízení.
aktualizace služby . Když aktualizujete službu na novou verzi, nemělo by dojít k přerušení jiných služeb, které na ní závisejí.
zmírnění rizik: Použijte techniky nasazení, jako je modrá-zelená nebo kanárná verze, pro nerušné změny. V případě zásadních změn rozhraní API nasaďte novou verzi souběžně s předchozí verzí. Díky tomu je možné aktualizovat a testovat služby, které využívají předchozí rozhraní API. Viz Aktualizace služebníže.
Monorepo vs. multi-repo
Před vytvořením pracovního postupu CI/CD musíte vědět, jak bude základ kódu strukturovaný a spravovaný.
- Pracují týmy v samostatných úložištích nebo v monorepo (jedno úložiště)?
- Jaká je vaše strategie větvení?
- Kdo může odeslat kód do produkčního prostředí? Existuje role správce verzí?
Monorepo přístup získal laskavost, ale existují výhody a nevýhody obojího.
| Monorepo | Více úložišť | |
|---|---|---|
| Výhody | Sdílení kódu Jednodušší standardizace kódu a nástrojů Jednodušší refaktoring kódu Zjistitelnost – jediné zobrazení kódu |
Vymazat vlastnictví na tým Potenciálně méně konfliktů při slučování Pomáhá vynutit oddělení mikroslužeb. |
| výzvy | Změny sdíleného kódu můžou mít vliv na více mikroslužeb. Větší potenciál konfliktů při slučování Nástroje musí být škálovatelné na velký základ kódu. Řízení přístupu Složitější proces nasazení |
Sdílení kódu je obtížnější Obtížnější vynucovat standardy kódování Správa závislostí Základ difuzního kódu, špatná zjistitelnost Nedostatek sdílené infrastruktury |
Aktualizace služeb
Existují různé strategie aktualizace služby, která je již v produkčním prostředí. Tady probereme tři běžné možnosti: postupné aktualizace, modré zelené nasazení a kanárkové vydání.
Postupné aktualizace
V kumulativní aktualizaci nasadíte nové instance služby a nové instance začnou okamžitě přijímat požadavky. Jakmile se objeví nové instance, odeberou se předchozí instance.
Příklad. V Kubernetes jsou kumulativní aktualizace výchozím chováním při aktualizaci specifikace podu pro nasazení. Kontroler nasazení vytvoří novou sadu replik pro aktualizované pody. Potom vertikálně navýšit kapacitu nové sady replik při vertikálním snížení kapacity starého, aby se zachoval požadovaný počet replik. Neodstraní staré pody, dokud nebudou nové. Kubernetes uchovává historii aktualizace, takže v případě potřeby můžete vrátit aktualizaci zpět.
Příklad. Azure Service Fabric ve výchozím nastavení používá strategii postupné aktualizace. Tato strategie je nejvhodnější pro nasazení verze služby s novými funkcemi beze změny stávajících rozhraní API. Service Fabric spustí nasazení upgradu aktualizací typu aplikace na podmnožinu uzlů nebo aktualizační domény. Potom se vrátí do další aktualizační domény, dokud se neupgradují všechny domény. Pokud se upgradovací doméně nepodaří aktualizovat, typ aplikace se vrátí k předchozí verzi napříč všemi doménami. Mějte na paměti, že typ aplikace s více službami (a pokud se všechny služby aktualizují v rámci jednoho nasazení upgradu) je náchylné k selhání. Pokud se jedna služba nepodaří aktualizovat, celá aplikace se vrátí zpět na předchozí verzi a ostatní služby se neaktualizují.
Jednou z výzev kumulativních aktualizací je, že během procesu aktualizace je spuštěná kombinace starých a nových verzí a příjem provozu. Během této doby by se všechny požadavky mohly směrovat do některé ze dvou verzí.
V případě zásadních změn rozhraní API je dobrým postupem podporovat obě verze vedle sebe, dokud nebudou aktualizováni všichni klienti předchozí verze. Viz správy verzí rozhraní API .
Nasazení s modrou zelenou barvou
V modrém nasazení nasadíte novou verzi společně s předchozí verzí. Po ověření nové verze přepnete veškerý provoz najednou z předchozí verze na novou verzi. Po přepnutí monitorujete aplikaci v případě jakýchkoli problémů. Pokud se něco nepovede, můžete se vrátit ke staré verzi. Za předpokladu, že neexistují žádné problémy, můžete starou verzi odstranit.
V případě tradiční monolitické nebo N-vrstvé aplikace obecně nasazení s modrou zelenou barvou znamenalo zřízení dvou identických prostředí. Novou verzi nasadíte do přípravného prostředí a pak přesměrujete klientský provoz do přípravného prostředí – například prohozením virtuálních IP adres. V architektuře mikroslužeb dochází k aktualizacím na úrovni mikroslužby, takže byste aktualizaci obvykle nasadili do stejného prostředí a použili mechanismus zjišťování služeb ke prohození.
příklad. V Kubernetes nemusíte zřizovat samostatný cluster, abyste mohli provádět nasazení s modrou zelenou barvou. Místo toho můžete využít selektory. Vytvořte nový prostředek Nasazení s novou specifikací podu a jinou sadou popisků. Vytvořte toto nasazení, aniž byste odstranili předchozí nasazení nebo upravili službu, která na ni odkazuje. Po spuštění nových podů můžete aktualizovat selektor služby tak, aby odpovídal novému nasazení.
Jednou z nevýhod modrého zeleného nasazení je, že během aktualizace spouštíte dvakrát tolik podů pro službu (aktuální a další). Pokud pody vyžadují velké množství prostředků procesoru nebo paměti, možná budete muset cluster dočasně škálovat, abyste mohli zpracovat spotřebu prostředků.
Kanárské vydání
V kanárské verzi zavedete aktualizovanou verzi pro malý počet klientů. Pak budete monitorovat chování nové služby, než ji zpřístupníte všem klientům. Díky tomu můžete provádět pomalé zavedení řízeným způsobem, sledovat skutečná data a odhalit problémy předtím, než budou ovlivněni všichni zákazníci.
Kanárské vydání je složitější pro správu než modrá-zelená nebo kumulativní aktualizace, protože je nutné dynamicky směrovat požadavky na různé verze služby.
příklad. V Kubernetes můžete nakonfigurovat Service tak, aby přesahovali dvě sady replik (jednu pro každou verzi) a upravte počty replik ručně. Tento přístup je ale poměrně hrubý, protože se vyrovnává zatížení Kubernetes napříč pody. Pokud máte například celkem 10 replik, můžete provoz přesunout pouze v 10% přírůstcích. Pokud používáte síť služeb, můžete použít pravidla směrování sítě služeb k implementaci sofistikovanější kanárské strategie vydávání verzí.
Další kroky
- studijní program : Definování a implementace kontinuální integrace
- Školení: Úvod do průběžného doručování
- architektura mikroslužeb
- Proč používat přístup mikroslužeb k vytváření aplikací