»Izvorne v oblaku« ali preprosto »oblačne« aplikacije so ustvarjene posebej za delo v infrastrukturah v oblaku. Običajno so zgrajene kot nabor ohlapno povezanih mikrostoritev, pakiranih v vsebnike, ki jih nato upravlja platforma v oblaku. Takšne aplikacije so privzeto pripravljene na okvare, kar pomeni, da delujejo zanesljivo in se prilagajajo tudi v primeru resnih okvar na ravni infrastrukture. Druga plat medalje so nizi omejitev (pogodb), ki jih oblačna platforma nalaga kontejnerskim aplikacijam, da jih lahko samodejno upravlja.
Čeprav se mnoge organizacije popolnoma zavedajo potrebe in pomena prehoda na aplikacije v oblaku, še vedno ne vedo, kje začeti. V tem prispevku si bomo ogledali številna načela, ki vam bodo, če jih boste upoštevali pri razvoju kontejnerskih aplikacij, omogočila uresničitev potenciala platform v oblaku ter doseganje zanesljivega delovanja in skaliranja aplikacij tudi v primeru resnih okvar IT infrastrukture. raven. Končni cilj tukaj opisanih načel je naučiti se graditi aplikacije, ki jih lahko samodejno upravljajo platforme v oblaku, kot je Kubernetes.
Načela oblikovanja programske opreme
V svetu programiranja se načela nanašajo na precej splošna pravila, ki jih je treba upoštevati pri razvoju programske opreme. Uporabljajo se lahko pri delu s katerim koli programskim jezikom. Vsako načelo ima svoje cilje, orodja za doseganje katerih so običajno predloge in prakse. Obstajajo tudi številna temeljna načela za ustvarjanje visokokakovostne programske opreme, iz katerih izhajajo vsa druga. Tu je nekaj primerov temeljnih načel:
- (Keep it simple, stupid) – ne kompliciraj;
- (Ne ponavljaj se) - ne ponavljaj se;
- (Ne boste ga potrebovali) - ne ustvarjajte nečesa, kar ni takoj potrebno;
- Ločitev skrbi – delite odgovornosti.
Kot lahko vidite, ta načela ne določajo nobenih posebnih pravil, ampak spadajo v kategorijo tako imenovanih zdravorazumskih premislekov, ki temeljijo na praktičnih izkušnjah, ki jih delijo številni razvijalci in na katere se redno sklicujejo.
Poleg tega obstaja – Niz prvih petih načel objektno usmerjenega programiranja in oblikovanja, ki jih je oblikoval Robert Martin. SOLID vključuje široka, odprta, dopolnjujoča se načela, ki – če jih uporabimo skupaj – pomagajo ustvarjati boljše sisteme programske opreme in jih bolje vzdrževati na dolgi rok.
Načela SOLID spadajo na področje OOP in so oblikovana v jeziku konceptov in konceptov, kot so razredi, vmesniki in dedovanje. Po analogiji lahko načela razvoja oblikujemo tudi za aplikacije v oblaku, le da osnovni element tukaj ne bo razred, temveč vsebnik. Z upoštevanjem teh načel lahko ustvarite kontejnerske aplikacije, ki bolje izpolnjujejo cilje platform v oblaku, kot je Kubernetes.
Vsebniki v oblaku: pristop Red Hat
Danes je skoraj vsako aplikacijo relativno enostavno zapakirati v zabojnike. Da pa bi bile aplikacije učinkovito avtomatizirane in orkestrirane znotraj platforme v oblaku, kot je Kubernetes, so potrebni dodatni napori.
Osnova za spodaj opisane zamisli je bila metodologija in mnoga druga dela o različnih vidikih gradnje spletnih aplikacij, od upravljanja izvorne kode do modelov skaliranja. Opisana načela veljajo samo za razvoj kontejnerskih aplikacij, ki so zgrajene na vrhu mikrostoritev in zasnovane za platforme v oblaku, kot je Kubernetes. Osnovni element v naši razpravi je slika vsebnika, ciljno izvajalno okolje vsebnika pa je platforma za orkestracijo vsebnika. Cilj predlaganih načel je ustvariti vsebnike, za katere je mogoče naloge razporejanja, skaliranja in spremljanja avtomatizirati na večini platform za orkestracijo. Načela so predstavljena brez posebnega vrstnega reda.
Načelo ene zadeve (SCP)
To načelo je v mnogih pogledih podobno načelu enotne odgovornosti. ), ki je del nabora SOLID in navaja, da mora imeti vsak objekt eno odgovornost, ta odgovornost pa mora biti popolnoma zaprta v razredu. Bistvo SRP je, da je vsaka odgovornost razlog za spremembo, razred pa mora imeti en in samo en razlog za spremembo.
V SCP uporabljamo besedo »zaskrbljenost« namesto besede »odgovornost«, da označimo višjo raven abstrakcije in širši namen vsebnika v primerjavi z razredom OOP. In če je cilj SRP le en razlog za spremembo, potem je za SCP želja po razširitvi možnosti ponovne uporabe in zamenjave vsebnikov. Z upoštevanjem SRP in ustvarjanjem vsebnika, ki rešuje en sam problem in to na funkcionalno popoln način, povečate možnosti za ponovno uporabo te slike vsebnika v različnih aplikacijskih kontekstih.
Načelo SCP navaja, da mora vsak vsebnik rešiti en sam problem in to dobro. Poleg tega je SCP v svetu vsebnikov lažje doseči kot SRP v svetu OOP, saj vsebniki običajno izvajajo en sam proces in večino časa ta proces rešuje eno samo nalogo.
Če mora vsebniška mikrostoritev rešiti več problemov hkrati, jo je mogoče razdeliti na enoopravilne vsebnike in združiti znotraj enega poda (enota razmestitve vsebniške platforme) z uporabo stranske prikolice in predlog vsebnika init. Poleg tega SCP olajša zamenjavo starega vsebnika (kot je spletni strežnik ali posrednik sporočil) z novim, ki rešuje isto težavo, vendar ima razširjeno funkcionalnost ali se bolje prilagaja.
Načelo visoke opaznosti (HOP)
Ko se vsebniki uporabljajo kot enoten način pakiranja in izvajanja aplikacij, se same aplikacije obravnavajo kot črna škatla. Če pa so to vsebniki v oblaku, morajo izvajalnemu okolju zagotoviti posebne API-je za spremljanje stanja vsebnikov in po potrebi ustrezno ukrepati. Brez tega ne bo mogoče poenotiti avtomatizacije posodabljanja vsebnikov in upravljanja njihovega življenjskega cikla, kar bo posledično poslabšalo stabilnost in uporabnost programskega sistema.
V praksi bi morala vsebniška aplikacija imeti vsaj API za različne vrste pregledov zdravja: teste življenjske dobe in teste pripravljenosti. Če aplikacija trdi, da naredi več, mora zagotoviti druge načine spremljanja svojega stanja. Na primer beleženje pomembnih dogodkov prek STDERR in STDOUT za združevanje dnevnikov z uporabo Fluentd, Logstash in drugih podobnih orodij. Kot tudi integracija s knjižnicami za sledenje in zbiranje meritev, kot so OpenTracing, Prometheus itd.
Na splošno lahko aplikacijo še vedno obravnavamo kot črno skrinjico, vendar mora biti opremljena z vsemi API-ji, ki jih platforma potrebuje, da jo lahko spremlja in upravlja na najboljši možni način.
Načelo skladnosti življenjskega cikla (LCP)
LCP je antiteza HOP. Medtem ko HOP navaja, da mora vsebnik platformi izpostaviti API-je za branje, LCP zahteva, da aplikacija lahko sprejme informacije s platforme. Poleg tega mora vsebnik ne samo sprejemati dogodke, ampak se tudi prilagajati, z drugimi besedami, odzivati nanje. Od tod tudi ime načela, ki ga je mogoče obravnavati kot zahtevo za zagotavljanje platforme s pisanjem API-jev.
Platforme imajo različne vrste dogodkov za pomoč pri upravljanju življenjskega cikla vsebnika. Toda aplikacija sama se odloči, katere od njih bo zaznala in kako se odzvala.
Jasno je, da so nekateri dogodki pomembnejši od drugih. Na primer, če aplikacija ne prenaša dobro zrušitev, mora sprejeti sporočila signal: prekini (SIGTERM) in začeti svojo prekinitveno rutino čim hitreje, da ujame signal: ukini (SIGKILL), ki pride za SIGTERM.
Poleg tega so dogodki, kot sta PostStart in PreStop, lahko pomembni za življenjski cikel aplikacije. Na primer, po zagonu aplikacije bo morda potrebno nekaj časa za ogrevanje, preden bo lahko odgovorila na zahteve. Ali pa mora aplikacija ob zaustavitvi sprostiti sredstva na nek poseben način.
Načelo nespremenljivosti slike (IIP)
Splošno sprejeto je, da morajo vsebniške aplikacije po izgradnji ostati nespremenjene, tudi če se izvajajo v različnih okoljih. To zahteva eksternalizacijo shranjevanja podatkov v času izvajanja (z drugimi besedami, uporabo zunanjih orodij za to) in zanašanje na zunanje konfiguracije, specifične za čas izvajanja, namesto spreminjanja ali ustvarjanja edinstvenih vsebnikov za vsako okolje. Po kakršnih koli spremembah v aplikaciji je treba sliko vsebnika znova zgraditi in razmestiti v vsa uporabljena okolja. Mimogrede, pri upravljanju IT sistemov se uporablja podoben princip, znan kot princip nespremenljivosti strežnikov in infrastrukture.
Cilj IIP je preprečiti ustvarjanje ločenih slik vsebnika za različna izvajalna okolja in povsod uporabiti isto sliko skupaj z ustrezno konfiguracijo, specifično za okolje. Upoštevanje tega načela vam omogoča izvajanje tako pomembnih praks z vidika avtomatizacije sistemov v oblaku, kot sta roll-back in roll-forward posodobitev aplikacij.
Načelo enkratnosti postopka (PDP)
Ena najpomembnejših lastnosti vsebnika je njegova minljivost: primerek vsebnika je enostavno ustvariti in enostavno uničiti, zato ga je mogoče kadar koli enostavno zamenjati z drugim primerkom. Razlogov za takšno zamenjavo je lahko veliko: neuspešen test uporabnosti, skaliranje aplikacije, prenos na drugega gostitelja, izčrpanost virov platforme ali druge situacije.
Posledično morajo vsebniške aplikacije vzdrževati svoje stanje z uporabo nekaterih zunanjih sredstev ali za to uporabljati notranje porazdeljene sheme z redundanco. Poleg tega se mora aplikacija hitro zagnati in hitro zaustaviti ter biti pripravljena na nenadno usodno odpoved strojne opreme.
Ena od praks, ki pomaga izvajati to načelo, je, da so vsebniki majhni. Oblačna okolja lahko samodejno izberejo gostitelja za zagon primerka vsebnika, tako da manjši ko je vsebnik, hitreje se bo zagnal – preprosto se bo hitreje kopiral na ciljnega gostitelja prek omrežja.
Načelo samozadrževanja (S-CP)
V skladu s tem načelom so v fazi montaže vse potrebne komponente vključene v posodo. Vsebnik mora biti zgrajen ob predpostavki, da ima sistem samo čisto jedro Linuxa, zato je treba vse potrebne dodatne knjižnice postaviti v sam vsebnik. Vsebovati mora tudi stvari, kot je čas izvajanja za ustrezen programski jezik, platformo aplikacije (če je potrebno) in druge odvisnosti, ki bodo potrebne med izvajanjem aplikacije vsebnika.
Izjeme so za konfiguracije, ki se razlikujejo od okolja do okolja in jih je treba zagotoviti med izvajanjem, na primer prek Kubernetes ConfigMap.
Aplikacija lahko vključuje več kontejnerskih komponent, na primer ločen vsebnik DBMS znotraj kontejnerske spletne aplikacije. Po principu S-CP ti vsebniki ne smejo biti združeni v enega, ampak morajo biti narejeni tako, da bo vsebnik DBMS vseboval vse, kar je potrebno za delovanje baze, vsebnik spletne aplikacije pa vse, kar je potrebno za delovanje spleta. aplikacija, isti spletni strežnik. Posledično bo med izvajanjem vsebnik spletne aplikacije odvisen od vsebnika DBMS in bo do njega dostopal po potrebi.
Runtime Confinement Principle (RCP)
Načelo S-CP določa, kako naj bo zgrajen vsebnik in kaj naj vsebuje dvojiška slika. Vsebnik pa ni samo "črna škatla", ki ima samo eno lastnost - velikost datoteke. Med izvajanjem vsebnik prevzame druge dimenzije: količino porabljenega pomnilnika, čas procesorja in druge sistemske vire.
In tu pride prav princip RCP, po katerem mora kontejner obezglaviti svoje zahteve po sistemskih virih in jih prenesti na platformo. S profili virov vsakega vsebnika (koliko virov CPE, pomnilnika, omrežja in diska potrebuje) lahko platforma optimalno izvaja razporejanje in samodejno skaliranje, upravlja zmogljivost IT in vzdržuje ravni SLA za vsebnike.
Poleg izpolnjevanja zahtev vsebnika glede virov je za aplikacijo pomembno tudi, da ne preseže svojih meja. V nasprotnem primeru, ko pride do pomanjkanja virov, je večja verjetnost, da ga bo platforma vključila na seznam aplikacij, ki jih je treba ukiniti ali preseliti.
Ko govorimo o tem, da smo na prvem mestu v oblaku, govorimo o našem načinu dela.
Zgoraj smo oblikovali številna splošna načela, ki postavljajo metodološke temelje za gradnjo visokokakovostnih vsebniških aplikacij za okolja v oblaku.
Upoštevajte, da boste poleg teh splošnih načel potrebovali tudi dodatne napredne metode in tehnike za delo z vsebniki. Poleg tega imamo nekaj kratkih priporočil, ki so bolj specifična in jih je treba uporabiti (ali ne uporabiti) glede na situacijo:
- Poskusite zmanjšati velikost slik: izbrišite začasne datoteke in ne nameščajte nepotrebnih paketov - manjša kot je velikost vsebnika, hitreje se sestavi in prekopira na ciljnega gostitelja prek omrežja.
- Osredotočite se na poljubne ID-je uporabnikov: ne uporabljajte ukaza sudo ali katerega koli posebnega ID-ja uporabnika za zagon svojih vsebnikov.
- Označi pomembna vrata: Številke vrat lahko nastavite med izvajanjem, vendar je bolje, da jih določite z ukazom EXPOSE - tako bodo drugi ljudje in programi lažje uporabljali vaše slike.
- Shranite trajne podatke na nosilce: podatke, ki bi morali ostati po uničenju vsebnika, je treba zapisati na nosilce.
- Zapišite metapodatke o slikah: oznake, nalepke in opombe olajšajo uporabo slik – drugi razvijalci vam bodo hvaležni.
- Sinhronizirajte gostitelja in slike: Nekatere kontejnerske aplikacije zahtevajo, da se vsebnik sinhronizira z gostiteljem glede določenih atributov, kot je čas ali ID naprave.
- Na koncu delimo predloge in najboljše prakse, ki vam bodo pomagale učinkoviteje izvajati zgoraj navedena načela:
11. junija ob 11.00
Kaj se boste naučili:
- Nespremenljivi Red Hat Enterprise Linux CoreOS
- Storitvena mreža OpenShift
- Ogrodje operaterja
- Knativni okvir
Vir: www.habr.com