„Cloudové nativní“ nebo jednoduše „cloudové“ aplikace jsou vytvořeny speciálně pro práci v cloudových infrastrukturách. Obvykle jsou sestaveny jako sada volně propojených mikroslužeb zabalených v kontejnerech, které jsou zase spravovány cloudovou platformou. Takové aplikace jsou standardně připraveny na selhání, což znamená, že fungují spolehlivě a rozšiřují se i v případě vážných poruch na úrovni infrastruktury. Druhou stranou mince jsou sady omezení (smluv), které cloudová platforma uvaluje na kontejnerové aplikace, aby je mohla automaticky spravovat.
Mnoho organizací si je plně vědomo potřeby a důležitosti přechodu na cloudové aplikace, ale stále neví, kde začít. V tomto příspěvku se podíváme na řadu principů, které vám při dodržení při vývoji kontejnerových aplikací umožní využít potenciál cloudových platforem a dosáhnout spolehlivého provozu a škálování aplikací i v případě vážných výpadků na IT infrastruktuře. úroveň. Konečným cílem zde uvedených principů je naučit se vytvářet aplikace, které lze automaticky spravovat cloudovými platformami, jako je Kubernetes.
Principy návrhu softwaru
Ve světě programování se principy vztahují k poměrně obecným pravidlům, která je třeba dodržovat při vývoji softwaru. Lze je použít při práci s jakýmkoli programovacím jazykem. Každý princip má své vlastní cíle, jejichž nástrojem k dosažení jsou obvykle šablony a postupy. Existuje také řada zásadních principů pro tvorbu kvalitního softwaru, od kterého se odvíjí všechny ostatní. Zde je několik příkladů základních principů:
- (Keep it simple, stupid) – nekomplikujte to;
- (Neopakuj se) - neopakuj se;
- (Nebudete to potřebovat) - nevytvářejte něco, co není okamžitě potřeba;
- Rozdělení starostí – sdílení odpovědnosti.
Jak je vidět, tyto principy nestanovují žádná konkrétní pravidla, ale patří do kategorie tzv. úvah zdravého rozumu založených na praktických zkušenostech, které sdílí mnoho vývojářů a na které se pravidelně odvolávají.
Kromě toho existuje – Soubor prvních pěti principů objektově orientovaného programování a designu, formulovaný Robertem Martinem. SOLID zahrnuje široké, otevřené, vzájemně se doplňující principy, které – když jsou aplikovány společně – pomáhají vytvářet lepší softwarové systémy a lépe je dlouhodobě udržovat.
Principy SOLID patří do oblasti OOP a jsou formulovány v jazyce takových konceptů a konceptů, jako jsou třídy, rozhraní a dědičnost. Analogicky lze vývojové principy formulovat i pro cloudové aplikace, pouze základním prvkem zde nebude třída, ale kontejner. Dodržováním těchto principů můžete vytvářet kontejnerizované aplikace, které lépe splňují cíle a cíle cloudových platforem, jako je Kubernetes.
Cloud-native kontejnery: přístup Red Hat
Do kontejnerů lze dnes poměrně snadno zabalit téměř jakoukoli aplikaci. Aby však byly aplikace efektivně automatizovány a organizovány v rámci cloudové platformy, jako je Kubernetes, je zapotřebí další úsilí.
Základem níže uvedených myšlenek byla metodika a mnoho dalších prací o různých aspektech vytváření webových aplikací, od správy zdrojového kódu po modely škálování. Popsané principy platí pouze pro vývoj kontejnerových aplikací, které jsou postaveny na mikroslužbách a jsou určeny pro cloudové platformy, jako je Kubernetes. Základním prvkem v naší diskusi je obrázek kontejneru a cílovým prostředím kontejneru je platforma pro orchestraci kontejnerů. Cílem navrhovaných principů je vytvořit kontejnery, pro které lze automatizovat úlohy plánování, škálování a monitorování na většině orchestračních platforem. Principy nejsou uvedeny v žádném konkrétním pořadí.
Princip jednoho zájmu (SCP)
Tento princip je v mnoha ohledech podobný Principu jednotné odpovědnosti. ), která je součástí sady SOLID a uvádí, že každý objekt musí mít jednu odpovědnost a tato odpovědnost musí být zcela zapouzdřena do třídy. Smyslem SRP je, že každá odpovědnost je důvodem ke změně a třída musí mít jediný důvod ke změně.
V SCP používáme slovo „zájem“ místo slova „odpovědnost“ k označení vyšší úrovně abstrakce a širšího účelu kontejneru ve srovnání s třídou OOP. A pokud je cílem SRP mít pouze jeden důvod ke změně, pak za SCP stojí touha rozšířit možnosti opětovného použití a výměny kontejnerů. Dodržováním SRP a vytvářením kontejneru, který řeší jeden problém a dělá to funkčně kompletním způsobem, zvyšujete šance na opětovné použití tohoto obrazu kontejneru v různých aplikačních kontextech.
Princip SCP říká, že každý kontejner by měl vyřešit jeden jediný problém a udělat ho dobře. Navíc je SCP ve světě kontejnerů snadněji dosažitelné než SRP ve světě OOP, protože kontejnery obvykle provozují jeden jediný proces a tento proces většinou řeší jeden jediný úkol.
Pokud musí kontejnerová mikroslužba vyřešit několik problémů najednou, lze ji rozdělit do jednoúlohových kontejnerů a spojit v rámci jednoho modulu (jednotka nasazení kontejnerové platformy) pomocí šablon postranních vozíků a init kontejnerů. SCP navíc usnadňuje výměnu starého kontejneru (jako je webový server nebo zprostředkovatele zpráv) za nový, který řeší stejný problém, ale má rozšířenou funkčnost nebo se lépe škáluje.
Princip vysoké pozorovatelnosti (HOP)
Když se kontejnery používají jako jednotný způsob balení a spouštění aplikací, jsou samotné aplikace považovány za černou skříňku. Pokud se však jedná o cloudové kontejnery, pak musí běhovému prostředí poskytnout speciální rozhraní API pro sledování stavu kontejnerů a v případě potřeby podniknout příslušné kroky. Bez toho nebude možné sjednotit automatizaci aktualizace kontejnerů a správu jejich životního cyklu, což ve svém důsledku zhorší stabilitu a použitelnost softwarového systému.
V praxi by kontejnerizovaná aplikace měla mít minimálně API pro různé typy zdravotních kontrol: testy živosti a testy připravenosti. Pokud aplikace tvrdí, že dělá více, musí poskytnout jiné prostředky ke sledování jejího stavu. Například protokolování důležitých událostí přes STDERR a STDOUT pro agregaci protokolů pomocí Fluentd, Logstash a dalších podobných nástrojů. Stejně jako integrace s knihovnami pro sledování a kolekce metrik, jako je OpenTracing, Prometheus atd.
Obecně lze s aplikací stále zacházet jako s černou skříňkou, ale musí být vybavena všemi API, která platforma potřebuje, aby ji mohla co nejlépe monitorovat a spravovat.
Princip shody životního cyklu (LCP)
LCP je opakem HOP. Zatímco HOP uvádí, že kontejner musí platformě vystavit rozhraní API pro čtení, LCP vyžaduje, aby aplikace byla schopna přijímat informace z platformy. Navíc kontejner musí události nejen přijímat, ale také se přizpůsobovat, jinými slovy reagovat na ně. Odtud pochází název principu, který lze považovat za požadavek poskytnout platformě psací API.
Platformy mají různé typy událostí, které pomáhají řídit životní cyklus kontejneru. Je ale na samotné aplikaci, které z nich bude vnímat a jak reagovat.
Je jasné, že některé události jsou důležitější než jiné. Pokud například aplikace dobře netoleruje pády, musí přijímat zprávy signál: ukončení (SIGTERM) a zahájit svou ukončovací rutinu co nejrychleji, aby zachytila signál: zabití (SIGKILL), který přichází po SIGTERM.
Navíc události jako PostStart a PreStop mohou být důležité pro životní cyklus aplikace. Například po spuštění aplikace může vyžadovat určitou dobu zahřívání, než bude moci reagovat na požadavky. Nebo musí aplikace při vypínání uvolnit prostředky nějakým speciálním způsobem.
Princip neměnnosti obrazu (IIP)
Obecně se uznává, že kontejnerizované aplikace by měly po sestavení zůstat nezměněny, i když jsou provozovány v různých prostředích. To vyžaduje nutnost externalizovat ukládání dat za běhu (jinými slovy k tomu používat externí nástroje) a spoléhat se na externí konfigurace specifické pro běhové prostředí, spíše než upravovat nebo vytvářet jedinečné kontejnery pro každé prostředí. Po jakýchkoli změnách v aplikaci je nutné bitovou kopii kontejneru znovu sestavit a nasadit do všech používaných prostředí. Mimochodem, při správě IT systémů se používá podobný princip, známý jako princip neměnnosti serverů a infrastruktury.
Cílem IIP je zabránit vytváření samostatných obrazů kontejnerů pro různá běhová prostředí a všude používat stejný obraz spolu s vhodnou konfigurací specifickou pro dané prostředí. Dodržování tohoto principu umožňuje implementovat tak důležité postupy z pohledu automatizace cloudových systémů, jako je roll-back a roll-forward aktualizací aplikací.
Princip procesní disponibility (PDP)
Jednou z nejdůležitějších vlastností kontejneru je jeho pomíjivost: instance kontejneru lze snadno vytvořit a snadno zničit, takže ji lze kdykoli snadno nahradit jinou instancí. Důvodů pro takové nahrazení může být mnoho: selhání testu provozuschopnosti, škálování aplikace, přenos na jiného hostitele, vyčerpání zdrojů platformy nebo jiné situace.
V důsledku toho musí kontejnerizované aplikace udržovat svůj stav pomocí některých externích prostředků nebo k tomu používat interní distribuovaná schémata s redundancí. Aplikace se navíc musí rychle spouštět a rychle vypínat a být připravena na náhlé fatální selhání hardwaru.
Jedna praxe, která pomáhá implementovat tento princip, je udržovat nádoby malé. Cloudová prostředí mohou automaticky vybrat hostitele, na kterém spustí instanci kontejneru, takže čím menší kontejner, tím rychleji se spustí – jednoduše se rychleji zkopíruje do cílového hostitele přes síť.
Princip sebekontroly (S-CP)
Podle tohoto principu jsou ve fázi montáže všechny potřebné komponenty obsaženy v kontejneru. Kontejner by měl být postaven na předpokladu, že systém má pouze čisté linuxové jádro, takže všechny potřebné dodatečné knihovny by měly být umístěny v kontejneru samotném. Měl by také obsahovat věci, jako je runtime pro odpovídající programovací jazyk, aplikační platformu (je-li to nutné) a další závislosti, které budou vyžadovány při běhu kontejnerové aplikace.
Výjimky se udělují pro konfigurace, které se liší prostředí od prostředí a musí být poskytovány za běhu, například prostřednictvím Kubernetes ConfigMap.
Aplikace může obsahovat několik kontejnerových komponent, například samostatný DBMS kontejner v kontejnerizované webové aplikaci. Podle principu S-CP by se tyto kontejnery neměly spojovat do jednoho, ale měly by být provedeny tak, aby kontejner DBMS obsahoval vše potřebné pro provoz databáze a kontejner webové aplikace vše potřebné pro provoz webu. aplikace, stejný webový server. Výsledkem je, že za běhu bude kontejner webové aplikace záviset na kontejneru DBMS a bude k němu přistupovat podle potřeby.
Runtime Confinement Principle (RCP)
Princip S-CP definuje, jak by měl být kontejner postaven a co by měl binární obraz obsahovat. Kontejner však není jen „černá skříňka“, která má pouze jednu vlastnost – velikost souboru. Během provádění nabývá kontejner další dimenze: množství použité paměti, čas CPU a další systémové prostředky.
A zde přichází vhod princip RCP, podle kterého musí kontejner dekapitovat své požadavky na systémové prostředky a přenést je na platformu. S profily prostředků každého kontejneru (kolik prostředků CPU, paměti, sítě a disku potřebuje) může platforma optimálně provádět plánování a automatické škálování, spravovat kapacitu IT a udržovat úrovně SLA pro kontejnery.
Kromě splnění požadavků kontejneru na zdroje je také důležité, aby aplikace nepřekračovala své vlastní hranice. V opačném případě, když dojde k nedostatku prostředků, je pravděpodobnější, že je platforma zařadí do seznamu aplikací, které je třeba ukončit nebo migrovat.
Když mluvíme o cloud-first, mluvíme o způsobu, jakým pracujeme.
Výše jsme formulovali řadu obecných principů, které stanoví metodický základ pro vytváření vysoce kvalitních kontejnerových aplikací pro cloudová prostředí.
Všimněte si, že kromě těchto obecných principů budete potřebovat také další pokročilé metody a techniky pro práci s kontejnery. Kromě toho máme několik krátkých doporučení, která jsou konkrétnější a měla by být aplikována (nebo nepoužita) v závislosti na situaci:
- Pokuste se zmenšit velikost obrázků: odstraňte dočasné soubory a neinstalujte nepotřebné balíčky – čím menší je velikost kontejneru, tím rychleji se sestaví a zkopíruje do cílového hostitele přes síť.
- Zaměřte se na libovolná User-ID: ke spouštění kontejnerů nepoužívejte příkaz sudo ani žádné speciální ID uživatele.
- Označení důležitých portů: Čísla portů můžete nastavit za běhu, ale je lepší je specifikovat pomocí příkazu EXPOSE – usnadní to ostatním lidem a programům používání vašich obrázků.
- Ukládání trvalých dat na svazky: Data, která by měla zůstat po zničení kontejneru, by měla být zapsána na svazky.
- Napište metadata obrázků: tagy, štítky a anotace usnadňují používání obrázků – ostatní vývojáři vám poděkují.
- Synchronizace hostitele a obrázků: Některé kontejnerizované aplikace vyžadují, aby se kontejner synchronizoval s hostitelem při určitých atributech, jako je čas nebo ID stroje.
- Na závěr sdílíme šablony a osvědčené postupy, které vám pomohou efektivněji implementovat výše uvedené zásady:
11. června v 11.00:XNUMX
Co se naučíte:
- Neměnný Red Hat Enterprise Linux CoreOS
- Síť služeb OpenShift
- Operátorský rámec
- Knativní rámec
Zdroj: www.habr.com