„Cloudové natívne“ alebo jednoducho „cloudové“ aplikácie sú vytvorené špeciálne na prácu v cloudových infraštruktúrach. Zvyčajne sú zostavené ako súbor voľne prepojených mikroslužieb zabalených v kontajneroch, ktoré sú zase spravované cloudovou platformou. Takéto aplikácie sú štandardne pripravené na zlyhania, čo znamená, že fungujú spoľahlivo a škálujú sa aj v prípade vážnych porúch na úrovni infraštruktúry. Druhou stranou mince sú sady obmedzení (zmluvy), ktoré cloudová platforma ukladá kontajnerovým aplikáciám, aby ich mohla automaticky spravovať.
Aj keď si plne uvedomujeme potrebu a dôležitosť prechodu na cloudové aplikácie, mnohé organizácie stále nevedia, kde začať. V tomto príspevku sa pozrieme na množstvo princípov, ktoré vám pri dodržaní pri vývoji kontajnerových aplikácií umožnia využiť potenciál cloudových platforiem a dosiahnuť spoľahlivú prevádzku a škálovanie aplikácií aj v prípade vážnych výpadkov na IT infraštruktúre. úrovni. Konečným cieľom tu načrtnutých princípov je naučiť sa vytvárať aplikácie, ktoré môžu byť automaticky spravované cloudovými platformami, ako je Kubernetes.
Princípy návrhu softvéru
Vo svete programovania sa princípy odvolávajú na pomerne všeobecné pravidlá, ktoré sa musia dodržiavať pri vývoji softvéru. Môžu byť použité pri práci s akýmkoľvek programovacím jazykom. Každý princíp má svoje vlastné ciele, nástrojmi na ich dosiahnutie sú zvyčajne šablóny a postupy. Existuje tiež niekoľko základných princípov vytvárania kvalitného softvéru, z ktorého sa odvíjajú všetky ostatné. Tu je niekoľko príkladov základných princípov:
- (Buďte jednoduché, hlúpe) – nekomplikujte to;
- (Neopakuj sa) - neopakuj sa;
- (Nebudete to potrebovať) - nevytvárajte niečo, čo nie je okamžite potrebné;
- Oddelenie starostí – zdieľanie zodpovednosti.
Ako vidíte, tieto princípy nestanovujú žiadne konkrétne pravidlá, ale patria do kategórie takzvaných úvah zdravého rozumu založených na praktických skúsenostiach, ktoré zdieľajú mnohí vývojári a na ktoré sa pravidelne odvolávajú.
Okrem toho existuje – Súbor prvých piatich princípov objektovo orientovaného programovania a dizajnu, ktoré sformuloval Robert Martin. SOLID zahŕňa široké, otvorené, doplnkové princípy, ktoré – keď sa aplikujú spoločne – pomáhajú vytvárať lepšie softvérové systémy a lepšie ich dlhodobo udržiavať.
Princípy SOLID patria do oblasti OOP a sú formulované v jazyku takých konceptov a konceptov, ako sú triedy, rozhrania a dedičnosť. Analogicky možno princípy vývoja formulovať aj pre cloudové aplikácie, len základným prvkom tu nebude trieda, ale kontajner. Dodržiavaním týchto princípov môžete vytvárať kontajnerové aplikácie, ktoré lepšie spĺňajú ciele a ciele cloudových platforiem, ako je Kubernetes.
Cloud-native kontajnery: prístup Red Hat
Dnes sa dá do kontajnerov pomerne jednoducho zabaliť takmer každá aplikácia. Aby však boli aplikácie efektívne automatizované a organizované v rámci cloudovej platformy, ako je Kubernetes, je potrebné ďalšie úsilie.
Základom pre myšlienky uvedené nižšie bola metodológia a mnoho ďalších prác o rôznych aspektoch vytvárania webových aplikácií, od správy zdrojového kódu až po modely škálovania. Popísané princípy sa vzťahujú iba na vývoj kontajnerových aplikácií, ktoré sú postavené na mikroslužbách a sú navrhnuté pre cloudové platformy, ako je Kubernetes. Základným prvkom v našej diskusii je obrázok kontajnera a cieľovým prostredím kontajnera je platforma na orchestráciu kontajnerov. Cieľom navrhovaných princípov je vytvoriť kontajnery, pre ktoré je možné automatizovať úlohy plánovania, škálovania a monitorovania na väčšine orchestračných platforiem. Zásady nie sú prezentované v určitom poradí.
Princíp jedného záujmu (SCP)
Tento princíp je v mnohom podobný princípu jednotnej zodpovednosti. ), ktorý je súčasťou sady SOLID a uvádza, že každý objekt musí mať jednu zodpovednosť a táto zodpovednosť musí byť úplne zapuzdrená v triede. Pointou SRP je, že každá zodpovednosť je dôvodom na zmenu a trieda musí mať jeden a len jeden dôvod na zmenu.
V SCP používame slovo „starosť“ namiesto slova „zodpovednosť“ na označenie vyššej úrovne abstrakcie a širšieho účelu kontajnera v porovnaní s triedou OOP. A ak je cieľom SRP mať iba jeden dôvod na zmenu, potom za SCP stojí túžba rozšíriť možnosti opätovného použitia a výmeny kontajnerov. Dodržiavaním SRP a vytvorením kontajnera, ktorý rieši jeden problém a robí to funkčne kompletným spôsobom, zvýšite šance na opätovné použitie tohto obrazu kontajnera v rôznych kontextoch aplikácie.
Princíp SCP hovorí, že každý kontajner by mal vyriešiť jeden jediný problém a urobiť ho dobre. Navyše, SCP vo svete kontajnerov je ľahšie dosiahnuteľné ako SRP vo svete OOP, pretože kontajnery zvyčajne bežia jeden proces a tento proces väčšinou rieši jednu jedinú úlohu.
Ak nejaká kontajnerová mikroslužba musí vyriešiť niekoľko problémov naraz, potom ju možno rozdeliť na jednoúlohové kontajnery a spojiť v rámci jedného modulu (jednotka nasadenia kontajnerovej platformy) pomocou šablón postranných vozíkov a init kontajnerov. Okrem toho SCP uľahčuje výmenu starého kontajnera (napríklad webového servera alebo sprostredkovateľa správ) za nový, ktorý rieši rovnaký problém, ale má rozšírenú funkčnosť alebo sa lepšie škáluje.
Princíp vysokej pozorovateľnosti (HOP)
Keď sa kontajnery používajú ako jednotný spôsob balenia a spúšťania aplikácií, samotné aplikácie sa považujú za čiernu skrinku. Ak však ide o cloudové kontajnery, potom musia poskytnúť špeciálne API pre runtime na monitorovanie stavu kontajnerov a v prípade potreby vykonať príslušné opatrenia. Bez toho nebude možné zjednotiť automatizáciu aktualizácie kontajnerov a riadenia ich životného cyklu, čo následne zhorší stabilitu a použiteľnosť softvérového systému.
V praxi by kontajnerová aplikácia mala mať minimálne API pre rôzne typy zdravotných kontrol: testy živosti a testy pripravenosti. Ak aplikácia tvrdí, že robí viac, musí poskytnúť iné prostriedky na monitorovanie jej stavu. Napríklad protokolovanie dôležitých udalostí cez STDERR a STDOUT na agregáciu protokolov pomocou Fluentd, Logstash a iných podobných nástrojov. Rovnako ako integrácia s knižnicami sledovania a kolekcií metrík, ako sú OpenTracing, Prometheus atď.
Vo všeobecnosti možno s aplikáciou stále zaobchádzať ako s čiernou skrinkou, ale musí byť vybavená všetkými rozhraniami API, ktoré platforma potrebuje, aby ju mohla čo najlepšie monitorovať a spravovať.
Princíp zhody životného cyklu (LCP)
LCP je opakom HOP. Zatiaľ čo HOP uvádza, že kontajner musí platforme vystaviť čítacie API, LCP vyžaduje, aby aplikácia bola schopná prijímať informácie z platformy. Navyše, kontajner musí udalosti nielen prijímať, ale sa aj prispôsobovať, inými slovami, reagovať na ne. Odtiaľ pochádza názov princípu, ktorý možno považovať za požiadavku poskytnúť platforme písanie API.
Platformy majú rôzne typy udalostí, ktoré pomáhajú riadiť životný cyklus kontajnera. Je ale na samotnej aplikácii, ktoré z nich bude vnímať a ako zareaguje.
Je jasné, že niektoré udalosti sú dôležitejšie ako iné. Napríklad, ak aplikácia dobre netoleruje pády, musí akceptovať správy signál: ukončiť (SIGTERM) a čo najrýchlejšie spustiť rutinu ukončenia, aby zachytila signál: zabiť (SIGKILL), ktorý nasleduje po SIGTERM.
Okrem toho udalosti ako PostStart a PreStop môžu byť dôležité pre životný cyklus aplikácie. Napríklad po spustení aplikácie môže vyžadovať určitý čas na zahriatie, kým bude môcť reagovať na požiadavky. Alebo aplikácia musí uvoľniť prostriedky nejakým špeciálnym spôsobom pri vypínaní.
Princíp nezmeniteľnosti obrazu (IIP)
Všeobecne sa uznáva, že kontajnerové aplikácie by mali po vytvorení zostať nezmenené, aj keď sú spustené v rôznych prostrediach. To si vyžaduje potrebu externalizovať ukladanie údajov za behu (inými slovami, používať na to externé nástroje) a spoliehať sa na externé konfigurácie špecifické pre beh, a nie na úpravu alebo vytváranie jedinečných kontajnerov pre každé prostredie. Po akýchkoľvek zmenách v aplikácii sa musí obrázok kontajnera prebudovať a nasadiť do všetkých používaných prostredí. Mimochodom, pri správe IT systémov sa používa podobný princíp, známy ako princíp nemennosti serverov a infraštruktúry.
Cieľom IIP je zabrániť vytváraniu samostatných obrazov kontajnerov pre rôzne runtime prostredia a všade používať rovnaký obraz spolu s vhodnou konfiguráciou špecifickou pre dané prostredie. Dodržiavanie tohto princípu vám umožňuje implementovať také dôležité postupy z pohľadu automatizácie cloudových systémov, ako je roll-back a roll-forward aktualizácií aplikácií.
Proces jednorazového princípu (PDP)
Jednou z najdôležitejších vlastností kontajnera je jeho pominuteľnosť: inštanciu kontajnera je ľahké vytvoriť a ľahko zničiť, takže ju možno kedykoľvek ľahko nahradiť inou inštanciou. Dôvodov na takúto výmenu môže byť veľa: zlyhanie testu prevádzkyschopnosti, škálovanie aplikácie, prenos na iného hostiteľa, vyčerpanie zdrojov platformy alebo iné situácie.
V dôsledku toho si kontajnerové aplikácie musia udržiavať svoj stav pomocou niektorých externých prostriedkov alebo na to musia používať interné distribuované schémy s redundanciou. Aplikácia sa navyše musí rýchlo spustiť a rýchlo vypínať a pripraviť sa na náhle fatálne zlyhanie hardvéru.
Jedna prax, ktorá pomáha implementovať tento princíp, je udržiavať malé nádoby. Cloudové prostredia môžu automaticky vybrať hostiteľa, na ktorom spustí inštanciu kontajnera, takže čím je kontajner menší, tým rýchlejšie sa spustí – jednoducho sa rýchlejšie skopíruje do cieľového hostiteľa cez sieť.
Princíp sebakontroly (S-CP)
Podľa tohto princípu sú v štádiu montáže všetky potrebné komponenty zahrnuté v kontajneri. Kontajner by mal byť postavený na predpoklade, že systém má iba čisté jadro Linuxu, takže všetky potrebné dodatočné knižnice by mali byť umiestnené v kontajneri samotnom. Mal by tiež obsahovať veci ako runtime pre príslušný programovací jazyk, aplikačnú platformu (ak je to potrebné) a ďalšie závislosti, ktoré sa budú vyžadovať počas spustenia kontajnerovej aplikácie.
Výnimky sú určené pre konfigurácie, ktoré sa líšia od prostredia k prostrediu a musia byť poskytnuté za behu, napríklad prostredníctvom Kubernetes ConfigMap.
Aplikácia môže obsahovať niekoľko kontajnerových komponentov, napríklad samostatný DBMS kontajner v kontajnerizovanej webovej aplikácii. Podľa princípu S-CP by sa tieto kontajnery nemali spájať do jedného, ale mali by byť vyrobené tak, aby kontajner DBMS obsahoval všetko potrebné pre chod databázy a kontajner webovej aplikácie všetko potrebné pre chod webu. aplikácia, rovnaký webový server. Výsledkom je, že za behu bude kontajner webovej aplikácie závisieť od kontajnera DBMS a bude k nemu pristupovať podľa potreby.
Runtime Confinement Principle (RCP)
Princíp S-CP definuje, ako by mal byť kontajner zostavený a čo by mal obsahovať binárny obrázok. Kontajner však nie je len „čierna skrinka“, ktorá má len jednu vlastnosť – veľkosť súboru. Počas vykonávania nadobudne kontajner ďalšie rozmery: množstvo použitej pamäte, čas procesora a ďalšie systémové prostriedky.
A tu prichádza vhod princíp RCP, podľa ktorého musí kontajner dekapitovať svoje požiadavky na systémové zdroje a preniesť ich na platformu. S profilmi prostriedkov každého kontajnera (koľko CPU, pamäte, siete a diskových prostriedkov potrebuje) môže platforma optimálne vykonávať plánovanie a automatické škálovanie, spravovať kapacitu IT a udržiavať úrovne SLA pre kontajnery.
Okrem splnenia zdrojových požiadaviek kontajnera je tiež dôležité, aby aplikácia neprekročila svoje vlastné hranice. V opačnom prípade, keď dôjde k nedostatku zdrojov, platforma ho s väčšou pravdepodobnosťou zaradí do zoznamu aplikácií, ktoré je potrebné ukončiť alebo migrovať.
Keď hovoríme o cloud-first, hovoríme o spôsobe, akým pracujeme.
Vyššie sme sformulovali niekoľko všeobecných princípov, ktoré stanovujú metodický základ pre budovanie vysokokvalitných kontajnerových aplikácií pre cloudové prostredia.
Všimnite si, že okrem týchto všeobecných princípov budete potrebovať aj ďalšie pokročilé metódy a techniky na prácu s kontajnermi. Okrem toho máme niekoľko krátkych odporúčaní, ktoré sú konkrétnejšie a mali by sa uplatniť (alebo neuplatniť) v závislosti od situácie:
- Pokúste sa zmenšiť veľkosť obrázkov: odstráňte dočasné súbory a neinštalujte nepotrebné balíky – čím menšia je veľkosť kontajnera, tým rýchlejšie sa zostaví a skopíruje do cieľového hostiteľa cez sieť.
- Zamerajte sa na ľubovoľné ID používateľa: na spustenie kontajnerov nepoužívajte príkaz sudo ani žiadne špeciálne ID používateľa.
- Označenie dôležitých portov: Čísla portov môžete nastaviť za behu, ale je lepšie ich špecifikovať pomocou príkazu EXPOSE – uľahčí to ostatným ľuďom a programom používanie vašich obrázkov.
- Uchovávanie trvalých údajov na zväzkoch: Údaje, ktoré by mali zostať po zničení kontajnera, by sa mali zapísať do zväzkov.
- Napíšte metadáta obrázkov: značky, štítky a anotácie uľahčujú používanie obrázkov – ostatní vývojári vám budú vďační.
- Synchronizácia hostiteľa a obrázkov: Niektoré kontajnerizované aplikácie vyžadujú, aby sa kontajner synchronizoval s hostiteľom pri určitých atribútoch, ako je čas alebo ID stroja.
- Na záver zdieľame šablóny a osvedčené postupy, ktoré vám pomôžu efektívnejšie implementovať vyššie uvedené zásady:
11. júna o 11.00 hod
Čo sa naučíte:
- Immutable Red Hat Enterprise Linux CoreOS
- Sieť služieb OpenShift
- Operátorský rámec
- Natívny rámec
Zdroj: hab.com