Rychlejší cykly vydávání verzí jsou jednou z hlavních výhod architektur 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, mluvíme ve skutečnosti o několika souvisejících procesech: kontinuální integrace, 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í, že kód v hlavní větvi bude vždy v produkční kvalitě.
Průběžné doručování. Všechny změny kódu, které projdou procesem CI, se automaticky publikují do produkčního prostředí. Nasazení do živého produkčního prostředí může vyžadovat ruční schválení, ale jinak je automatizované. Cílem je, aby váš kód byl vždy připravený k nasazení do produkčního prostředí.
Průběžné nasazování. Změny kódu, které prošly předchozími dvěma kroky, se automaticky nasadí do produkčního prostředí.
Tady jsou některé cíle robustního procesu CI/CD pro architekturu mikroslužeb:
Každý tým může nezávisle vytvářet a nasazovat služby, které vlastní, aniž by to ovlivnilo nebo naruš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í a kontrolu kvality za účelem ověření. V každé fázi se vynucují brány kvality.
Novou verzi služby je možné nasadit souběžně s předchozí verzí.
Jsou zavedeny dostatečné zásady řízení přístupu.
U kontejnerizovaných úloh můžete důvěřovat imagím kontejnerů nasazených v produkčním 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é práce se do tohoto kanálu zasílají. Pokud se najde chyba s vysokou prioritou, musí být integrována, testována a publikována oprava, což může zpozdit vydání nových funkcí. Tyto problémy můžete zmírnit tím, že budete mít dobře zachycené moduly a pomocí větví funkcí minimalizujete dopad změn kódu. Ale s tím, jak se aplikace zvětšuje a přidávají se další funkce, proces vydávání monolitů má tendenci být více křehký a je pravděpodobné, že se přeruší.
V souladu s filozofií mikroslužeb by nikdy nemělo existovat dlouhé vydávání verzí, ve kterém by se každý tým měl dostat do řady. Tým, který sestavuje službu "A", může kdykoli vydat aktualizaci, aniž by čekal na sloučení, testování a nasazení změn ve službě B.
Aby bylo možné dosáhnout vysoké rychlosti vydávání verzí, 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ě, regrese nebo přerušení služeb musí být vzácné. Zároveň platí, že pokud se špatná aktualizace nasadí, musíte mít spolehlivý způsob, jak rychle vrátit zpět nebo přejít na předchozí verzi služby.
Výzvy
Mnoho malých nezávislých základů kódu. Každý tým zodpovídá za vytváření vlastní služby s vlastním kanálem sestavení. 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 sestavit systém, rozloží mezi týmy a nikdo v organizaci neví, jak nasadit celou aplikaci. Například co se stane ve scénáři zotavení po havárii, pokud potřebujete rychle nasadit do nového clusteru?
Zmírnění rizik: Mít jednotný a automatizovaný kanál pro sestavování a nasazování služeb, aby tyto znalosti nebyly "skryté" v rámci každého týmu.
Více jazyků a architektur. Když každý tým používá vlastní kombinaci technologií, může být obtížné vytvořit jeden proces sestavení, který bude fungovat v celé organizaci. Proces sestavení musí být dostatečně flexibilní, aby si ho každý tým mohl přizpůsobit podle svého výběru jazyka nebo architektury.
Zmírnění rizik: Kontejnerizujte proces sestavení pro každou službu. Systém sestavení tak musí být schopen spouštět kontejnery.
Integrace a zátěžové testování. Díky tomu, že týmy vydávají aktualizace vlastním tempem, může být náročné navrhnout robustní kompletní testování, zejména pokud mají služby závislosti na jiných službách. Kromě toho může být provoz celé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ích škálách, jen pro účely testování.
Správa verzí. Každý tým by měl mít možnost nasadit aktualizaci do produkčního prostředí. To neznamená, že k tomu má oprávnění každý člen týmu. Centralizovaná role Správce vydaných verzí 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í aktualizací hlavních funkcí a menší opravy chyb. Decentralizace neznamená nulové zásady správného řízení.
Aktualizace služeb. Když aktualizujete službu na novou verzi, nemělo by to narušit ostatní služby, které na ní závisejí.
Zmírnění rizik: Pro nezlomné změny používejte techniky nasazení, jako je modrozelená nebo kanárová verze. V případě zásadních změn rozhraní API nasaďte novou verzi souběžně s předchozí verzí. Tímto způsobem je možné aktualizovat a otestovat služby, které využívají předchozí rozhraní API pro nové rozhraní API. Viz Aktualizace služeb níže.
Monorepo vs. multi-úložiště
Před vytvořením pracovního postupu CI/CD musíte vědět, jak bude základ kódu strukturován a spravován.
- Pracují týmy v samostatných úložištích nebo v monorecu (jedno úložiště)?
- Jaká je vaše strategie větvení?
- Kdo může nasdílit kód do produkčního prostředí? Existuje role správce verzí?
Monorepo přístup si získává přízeň, ale má pro oba výhody a nevýhody.
| Monorepo | Více úložišť | |
|---|---|---|
| Výhody | Sdílení kódu Snadnější standardizace kódu a nástrojů Snadnější refaktoring kódu Zjistitelnost – jedno 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. |
| Problémy | Změny sdíleného kódu můžou ovlivnit více mikroslužeb Větší potenciál konfliktů při slučování Nástroje se musí škálovat na velký základ kódu. Řízení přístupu Složitější proces nasazení |
Obtížnější sdílení kódu Obtížnější vynucování standardů kódování Správa závislostí Difuzní základ kódu, špatná zjistitelnost Nedostatek sdílené infrastruktury |
Aktualizace služeb
Existují různé strategie aktualizace služby, která už je v produkčním prostředí. Tady probereme tři běžné možnosti: aktualizace se zajištěním provozu, modrozelené nasazení a kanárské vydání.
Aktualizace se zajištěním provozu
Při postupné 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 aktualizace se zajištěním provozu výchozím chováním při aktualizaci specifikace podu pro nasazení. Kontroler nasazení vytvoří novou sadu ReplicaSet pro aktualizované pody. Pak vertikálně navyšuje kapacitu nové sady ReplicaSet a zároveň vertikálně snižuje kapacitu původní, aby se zachoval požadovaný počet replik. Staré pody se neodstraní, dokud nebudou připravené nové. Kubernetes uchovává historii aktualizace, takže v případě potřeby můžete aktualizaci vrátit zpět.
Příklad: Azure Service Fabric ve výchozím nastavení používá strategii průběžných aktualizací. 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 zahájí nasazení upgradu aktualizací typu aplikace na podmnožinu uzlů nebo aktualizační doménu. Pak se vrátí do další aktualizační domény, dokud se neupgradují všechny domény. Pokud se upgrade domény nepodaří aktualizovat, vrátí se typ aplikace zpět na 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 jedné službě nepodaří aktualizovat, celá aplikace se vrátí zpět k předchozí verzi a ostatní služby se neaktualizují.
Jedním z výzev při postupném aktualizaci je, že během procesu aktualizace je spuštěná kombinace starých a nových verzí a přijímá provoz. Během této doby může být jakýkoli požadavek směrován na některou z těchto dvou verzí.
U zásadních změn rozhraní API je vhodné podporovat obě verze vedle sebe, dokud nebudou aktualizováni všichni klienti předchozí verze. Viz Správa verzí rozhraní API.
Modrozelené nasazení
V modrozelené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í můžete aplikaci monitorovat, jestli nedochází k problémům. Pokud se něco nepovede, můžete přepnout zpět na starou verzi. Za předpokladu, že nedošlo k žádným problémům, můžete starou verzi odstranit.
U tradičnější monolitické nebo n-vrstvé aplikace znamenalo nasazení modrozelené obecně zřízení dvou identických prostředí. Novou verzi nasadíte do přípravného prostředí a pak přesměrujete provoz klienta do přípravného prostředí – například prohozením VIRTUÁLNÍch adres. V architektuře mikroslužeb probíhají aktualizace na úrovni mikroslužeb, takže byste ji obvykle nasadili do stejného prostředí a k prohození použili mechanismus zjišťování služeb.
Příklad: V Kubernetes nemusíte zřizovat samostatný cluster, abyste mohli provádět modrozelené nasazení. 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 změnili službu, která na něj 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 modrozelené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 dočasně škálovat cluster, abyste zvládli spotřebu prostředků.
Kanárková verze
V kanárské verzi zavádět aktualizovanou verzi pro malý počet klientů. Pak budete sledovat chování nové služby před jejím zavedením pro všechny klienty. To vám umožní provádět pomalé zavádění řízeným způsobem, sledovat skutečná data a odhalit problémy dříve, než budou ovlivněni všichni zákazníci.
Správa kanárské verze je složitější než modrozelená nebo průběžná aktualizace, protože požadavky musíte dynamicky směrovat do různých verzí služby.
Příklad: V Kubernetes můžete službu nakonfigurovat tak , aby pokrývá dvě sady replik (jednu pro každou verzi) a ručně upravit počty replik. Tento přístup je ale poměrně hrubě odstupňovaný, protože kubernetes vyrovnává zatížení mezi pody. Pokud máte například celkem 10 replik, můžete provoz přesunout pouze po 10 % přírůstcích. Pokud používáte síť služeb, můžete pomocí pravidel směrování sítě služeb implementovat sofistikovanější strategii vydávání kanárů.
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č při sestavování aplikací používat přístup k mikroslužbám