„Cloud native“ eða einfaldlega „ský“ forrit eru búin til sérstaklega til að vinna í skýjainnviðum. Þær eru venjulega byggðar sem sett af lauslega samtengdum örþjónustu sem er pakkað í gáma, sem aftur er stjórnað af skýjapalli. Slík forrit eru sjálfgefið undirbúin fyrir bilanir, sem þýðir að þau virka á áreiðanlegan hátt og stækka jafnvel ef um alvarlegar bilanir á innviðastigi er að ræða. Hin hliðin á peningnum er sett af takmörkunum (samningum) sem skýjapallurinn setur á gámaforrit til að geta stjórnað þeim sjálfkrafa.
Þótt þau séu fullkomlega meðvituð um þörfina og mikilvægi þess að færa sig yfir í skýjaforrit, vita mörg samtök ekki hvar þau eiga að byrja. Í þessari færslu munum við skoða nokkrar meginreglur sem, ef þeim er fylgt við þróun gámaforrita, munu gera þér kleift að átta sig á möguleikum skýjapalla og ná áreiðanlegum rekstri og stærðarstærð forrita, jafnvel ef alvarlegar bilanir verða í upplýsingatækniinnviðum. stigi. Endanlegt markmið meginreglnanna sem lýst er hér er að læra hvernig á að smíða forrit sem hægt er að stjórna sjálfkrafa af skýjapöllum eins og Kubernetes.
Hugbúnaðarhönnunarreglur
Í forritunarheiminum vísa meginreglur til nokkuð almennra reglna sem fylgja þarf við þróun hugbúnaðar. Hægt er að nota þau þegar unnið er með hvaða forritunarmál sem er. Hver meginregla hefur sín eigin markmið, verkfærin til að ná sem eru venjulega sniðmát og venjur. Það eru líka ýmsar grundvallarreglur til að búa til hágæða hugbúnað, sem allir aðrir renna úr. Hér eru nokkur dæmi um grundvallarreglur:
- (Hafðu það einfalt, heimskulegt) - ekki flækja það;
- (Ekki endurtaka sjálfan þig) - ekki endurtaka þig;
- (Þú munt ekki þurfa þess) - ekki búa til eitthvað sem er ekki strax þörf;
- Aðskilnaður áhyggjuefna – deildu ábyrgð.
Eins og þú sérð setja þessar meginreglur engar sérstakar reglur, heldur tilheyra þeim flokki svokallaðra skynsemissjónarmiða sem byggjast á hagnýtri reynslu, sem margir hönnuðir deila og vísa reglulega til.
Að auki er það – Setja af fyrstu fimm meginreglum hlutbundinnar forritunar og hönnunar, mótuð af Robert Martin. SOLID inniheldur víðtækar, opnar, viðbótarreglur sem – þegar þær eru notaðar saman – hjálpa til við að búa til betri hugbúnaðarkerfi og viðhalda þeim betur til lengri tíma litið.
SOLID meginreglurnar tilheyra sviði OOP og eru mótaðar á tungumáli hugtaka og hugtaka eins og flokka, viðmóta og erfða. Með hliðstæðum hætti er einnig hægt að móta þróunarreglur fyrir skýjaforrit, aðeins grunnþátturinn hér verður ekki flokkur, heldur ílát. Með því að fylgja þessum meginreglum geturðu búið til gámaforrit sem uppfylla betur markmið og markmið skýjapalla eins og Kubernetes.
Skýjagámar: Red Hat nálgunin
Í dag er hægt að pakka næstum hvaða forriti sem er tiltölulega auðveldlega í ílát. En til að forrit geti verið sjálfvirk og skipulögð á skilvirkan hátt innan skýjapalls eins og Kubernetes, þarf aukna áreynslu.
Grunnurinn að hugmyndunum sem lýst er hér að neðan var aðferðafræðin og mörg önnur verk um ýmsa þætti í smíði vefforrita, allt frá frumkóðastjórnun til stærðarlíkana. Reglurnar sem lýst er eiga aðeins við um þróun gámaforrita sem eru byggð ofan á örþjónustu og hönnuð fyrir skýjapalla eins og Kubernetes. Grunnþátturinn í umræðunni okkar er gámamyndin og keyrslutími miðgáma er gámaskipunarvettvangurinn. Markmið fyrirhugaðra meginreglna er að búa til gáma sem hægt er að gera sjálfvirkan tímasetningu, stærðarstærð og eftirlitsverkefni á flestum hljómsveitarpöllum. Meginreglurnar eru settar fram í engri sérstakri röð.
Einstök umhyggja (SCP)
Þessi regla er að mörgu leyti svipuð meginreglunni um eina ábyrgð. ), sem er hluti af SOLID settinu og segir að sérhver hlutur verði að hafa eina ábyrgð og sú ábyrgð verður að vera algjörlega umlukin í flokki. Aðalatriðið með SRP er að sérhver ábyrgð er ástæða fyrir breytingum og flokkur verður að hafa eina og eina ástæðu fyrir breytingum.
Í SCP notum við orðið „áhyggjur“ í stað orðsins „ábyrgð“ til að gefa til kynna hærra útdráttarstig og víðtækari tilgang íláts samanborið við OOP flokk. Og ef markmið SRP er að hafa aðeins eina ástæðu fyrir breytingum, þá er á bak við SCP löngunin til að auka getu til að endurnýta og skipta um ílát. Með því að fylgja SRP og búa til gám sem leysir eitt vandamál og gerir það á fullkominn hátt, eykur þú líkurnar á að endurnýta þá gámamynd í mismunandi forritasamhengi.
SCP meginreglan segir að hver gámur eigi að leysa eitt vandamál og gera það vel. Þar að auki er auðveldara að ná SCP í gámaheiminum en SRP í OOP heiminum, þar sem gámar keyra venjulega eitt ferli og oftast leysir þetta ferli eitt verkefni.
Ef gámaörþjónusta verður að leysa nokkur vandamál í einu, þá er hægt að skipta henni í staka gáma og sameina hana í einn belg (einingu fyrir dreifingu gámapalls) með hliðarvagni og init gámasniðmátum. Að auki gerir SCP það auðvelt að skipta út gömlum gámum (svo sem vefþjóni eða skilaboðamiðlara) fyrir nýjan sem leysir sama vandamál en hefur aukið virkni eða skalar betur.
High Observability Principle (HOP)
Þegar gámar eru notaðir sem sameinuð leið til að pakka og keyra forrit er farið með forritin sjálf sem svartan kassa. Hins vegar, ef þetta eru skýjagámar, þá verða þeir að útvega sérstök API fyrir keyrslutímann til að fylgjast með heilsu ílátanna og, ef nauðsyn krefur, grípa til viðeigandi aðgerða. Án þess verður ekki hægt að sameina sjálfvirkni við uppfærslu gáma og stjórnun lífsferils þeirra, sem aftur mun versna stöðugleika og notagildi hugbúnaðarkerfisins.
Í reynd ætti gámaforrit að lágmarki að vera með API fyrir ýmsar gerðir heilsuprófa: lífleikapróf og viðbúnaðarpróf. Ef umsókn segist gera meira, verður hún að veita aðrar leiðir til að fylgjast með ástandi hennar. Til dæmis að skrá mikilvæga atburði í gegnum STDERR og STDOUT til að safna skrám með því að nota Fluentd, Logstash og önnur svipuð verkfæri. Sem og samþættingu við rakningar- og mælingasafnsöfn, svo sem OpenTracing, Prometheus o.s.frv.
Almennt séð er samt hægt að meðhöndla forritið sem svartan kassa, en það verður að hafa öll þau API sem vettvangurinn þarf til að fylgjast með og stjórna því á sem bestan hátt.
Lífsferilssamræmisregla (LCP)
LCP er andstæða HOP. Þó að HOP segi að gámurinn verði að útvega læsileg API fyrir pallinn, þá krefst LCP að forritið geti tekið við upplýsingum frá pallinum. Þar að auki verður gámurinn ekki aðeins að taka á móti atburðum heldur einnig aðlagast, með öðrum orðum, bregðast við þeim. Þess vegna heiti meginreglunnar, sem hægt er að líta á sem kröfu til að útvega pallinum ritunar-API.
Pallar hafa mismunandi gerðir af atburðum til að hjálpa til við að stjórna líftíma gáms. En það er undir umsókninni sjálfri komið að ákveða hver þeirra á að skynja og hvernig á að bregðast við.
Það er ljóst að sumir atburðir eru mikilvægari en aðrir. Til dæmis, ef forrit þolir ekki hrun vel, verður það að samþykkja merki: terminate (SIGTERM) skilaboð og hefja uppsagnarrútínu sína eins fljótt og auðið er til að ná merkinu: drepa (SIGKILL) sem kemur á eftir SIGTERM.
Að auki geta atburðir eins og PostStart og PreStop verið mikilvægir fyrir líftíma forrits. Til dæmis, eftir að forrit hefur verið opnað, gæti það þurft nokkurn upphitunartíma áður en það getur svarað beiðnum. Eða forritið verður að losa auðlindir á einhvern sérstakan hátt þegar það er lokað.
The Image Immutability Principle (IIP)
Almennt er viðurkennt að gámaforrit eigi að haldast óbreytt eftir að hafa verið smíðuð, jafnvel þótt þau séu keyrð í mismunandi umhverfi. Þetta kallar á nauðsyn þess að ytra gagnageymslu á keyrslutíma (með öðrum orðum að nota utanaðkomandi verkfæri fyrir þetta) og að treysta á ytri, keyrslutíma-sértækar stillingar, frekar en að breyta eða búa til einstaka ílát fyrir hvert umhverfi. Eftir allar breytingar á forritinu verður að endurbyggja gámamyndina og dreifa henni í öll umhverfi sem notuð eru. Við the vegur, þegar stjórnað er upplýsingatæknikerfum, er svipuð regla notuð, þekkt sem meginreglan um óbreytanleika netþjóna og innviða.
Markmið IIP er að koma í veg fyrir að aðskildar gámamyndir séu búnar til fyrir mismunandi keyrsluumhverfi og að nota sömu myndina alls staðar ásamt viðeigandi umhverfissértæku uppsetningu. Að fylgja þessari meginreglu gerir þér kleift að innleiða svo mikilvægar venjur frá sjónarhóli sjálfvirkni skýjakerfa eins og afturköllun og framsveiflu forritauppfærslu.
Meginregla um einnota aðferð (PDP)
Einn mikilvægasti eiginleiki íláts er hverfulleiki þess: Auðvelt er að búa til tilvik af íláti og auðvelt að eyða því, svo það er auðvelt að skipta því út fyrir annað tilvik hvenær sem er. Það geta verið margar ástæður fyrir slíkri endurnýjun: bilun í nothæfisprófi, stærðarstærð forritsins, flutningur yfir á annan hýsil, tæmingu á auðlindum vettvangs eða aðrar aðstæður.
Þar af leiðandi verða gámaforrit að viðhalda ástandi sínu með einhverjum ytri aðferðum, eða nota innri dreifð kerfi með offramboði fyrir þetta. Að auki verður forritið að byrja hratt og slökkva fljótt og vera viðbúið fyrir skyndilega banvæna vélbúnaðarbilun.
Ein aðferð sem hjálpar til við að innleiða þessa meginreglu er að halda ílátunum litlum. Skýumhverfi geta sjálfkrafa valið hýsil til að ræsa gámatilvik á, þannig að því minni sem gámurinn er, því hraðar mun hann byrja - hann mun einfaldlega afrita til markhýsilsins yfir netið hraðar.
Sjálfsinnihaldsregla (S-CP)
Samkvæmt þessari meginreglu, á samsetningarstigi, eru allir nauðsynlegir íhlutir innifaldir í ílátinu. Gámurinn ætti að vera byggður á þeirri forsendu að kerfið hafi aðeins hreinan Linux kjarna, þannig að öll nauðsynleg viðbótarsöfn ættu að vera sett í ílátið sjálft. Það ætti einnig að innihalda hluti eins og keyrslutíma fyrir samsvarandi forritunarmál, forritavettvanginn (ef nauðsyn krefur) og önnur ósjálfstæði sem þarf á meðan gámaforritið er í gangi.
Undantekningar eru gerðar fyrir stillingar sem eru breytilegar eftir umhverfi og verða að vera til staðar á keyrslutíma, til dæmis í gegnum Kubernetes ConfigMap.
Forrit getur innihaldið nokkra gámahluta, til dæmis sérstakt DBMS gám innan gámaforrits. Samkvæmt S-CP meginreglunni á ekki að sameina þessa gáma í einn heldur þannig að DBMS gámurinn innihaldi allt sem nauðsynlegt er fyrir rekstur gagnagrunnsins og vefforritsgámurinn inniheldur allt sem nauðsynlegt er fyrir rekstur vefsins. forrit, sami vefþjónn . Þar af leiðandi mun vefforritsílátið á keyrslutíma ráðast af DBMS ílátinu og fá aðgang að því eftir þörfum.
Runtime Confinement Principle (RCP)
S-CP meginreglan skilgreinir hvernig gámurinn á að vera byggður og hvað tvöfaldur myndarinnar ætti að innihalda. En ílát er ekki bara „svartur kassi“ sem hefur aðeins eitt einkenni - skráarstærð. Við framkvæmd tekur ílátið á sig aðrar víddir: magn minnis sem notað er, CPU tími og önnur kerfisauðlindir.
Og hér kemur RCP meginreglan að góðum notum, samkvæmt henni þarf gámurinn að hausa kröfur sínar um kerfisauðlindir og flytja þær yfir á pallinn. Með tilföngum hvers gáms (hversu mikið örgjörva, minni, netkerfi og diskatilföng það þarf), getur pallurinn framkvæmt tímasetningu og sjálfvirka stærðarstærð sem best, stjórnað upplýsingatæknigetu og viðhaldið SLA stigum fyrir gáma.
Auk þess að uppfylla auðlindaþörf ílátsins er einnig mikilvægt að umsóknin fari ekki út fyrir eigin mörk. Annars, þegar auðlindaskortur kemur upp, er líklegra að pallurinn taki það með á listanum yfir forrit sem þarf að loka eða flytja.
Þegar við tölum um að vera fyrst í skýinu erum við að tala um hvernig við vinnum.
Hér að ofan mótuðum við nokkrar almennar meginreglur sem setja aðferðafræðilegan grunn að því að byggja upp hágæða gámaforrit fyrir skýjaumhverfi.
Athugaðu að til viðbótar við þessar almennu meginreglur þarftu einnig frekari háþróaðar aðferðir og tækni til að vinna með ílát. Að auki höfum við nokkrar stuttar ráðleggingar sem eru nákvæmari og ætti að beita (eða ekki beita) eftir aðstæðum:
- Reyndu að minnka stærð mynda: Eyddu tímabundnum skrám og settu ekki upp óþarfa pakka - því minni sem gámurinn er, því hraðar er hann settur saman og afritaður á miðhýsilinn yfir netið.
- Einbeittu þér að handahófskenndum notendaauðkennum: ekki nota sudo skipunina eða neitt sérstakt notendanafn til að ræsa ílátin þín.
- Merktu mikilvægar gáttir: Þú getur stillt gáttanúmer á keyrslutíma, en það er betra að tilgreina þau með EXPOSE skipuninni - það mun auðvelda öðru fólki og forritum að nota myndirnar þínar.
- Geymdu viðvarandi gögn um bindi: Gögn sem ættu að vera eftir eftir að ílátinu er eytt ætti að skrifa í bindi.
- Skrifaðu lýsigögn mynd: merki, merki og athugasemdir gera myndir auðveldari í notkun - aðrir verktaki munu þakka þér.
- Samstilla hýsil og myndir: Sum gámaforrit krefjast þess að gámurinn samstillist við hýsilinn á ákveðnum eiginleikum, svo sem tíma- eða vélakenni.
- Að lokum deilum við sniðmátum og bestu starfsvenjum sem hjálpa þér að innleiða meginreglurnar sem taldar eru upp hér að ofan á skilvirkari hátt:
11. júní kl 11.00
Hvað munt þú læra:
- Óbreytanleg Red Hat Enterprise Linux CoreOS
- OpenShift þjónustunet
- Rekstrarrammi
- Knative ramma
Heimild: www.habr.com