5 veselā saprāta principi mākoņlietotņu izveidei

ā€œMākoņa vietējāsā€ vai vienkārÅ”i ā€œmākonisā€ lietojumprogrammas ir Ä«paÅ”i izveidotas darbam mākoņa infrastruktÅ«rās. Tie parasti tiek veidoti kā brÄ«vi saistÄ«tu mikropakalpojumu kopums, kas iesaiņots konteineros, kurus savukārt pārvalda mākoņa platforma. Šādas lietojumprogrammas pēc noklusējuma ir sagatavotas kļūmēm, kas nozÄ«mē, ka tās darbojas uzticami un mērogojas pat nopietnu infrastruktÅ«ras lÄ«meņa traucējumu gadÄ«jumā. Otra medaļas puse ir ierobežojumu (lÄ«gumu) kopas, ko mākoņa platforma uzliek konteineru lietojumprogrammām, lai tās varētu pārvaldÄ«t automātiski.

5 veselā saprāta principi mākoņlietotņu izveidei

Lai gan daudzas organizācijas pilnÄ«bā apzinās nepiecieÅ”amÄ«bu un nozÄ«mi pāriet uz mākoņa lietojumprogrammām, daudzas organizācijas joprojām nezina, ar ko sākt. Å ajā ierakstā apskatÄ«sim vairākus principus, kas, ja tiek ievēroti, izstrādājot konteinerizētās lietojumprogrammas, ļaus realizēt mākoņu platformu potenciālu un panākt droÅ”u aplikāciju darbÄ«bu un mērogoÅ”anu pat nopietnu IT infrastruktÅ«ras kļūmju gadÄ«jumā. lÄ«menÄ«. Å eit izklāstÄ«to principu galvenais mērÄ·is ir iemācÄ«ties izveidot lietojumprogrammas, kuras var automātiski pārvaldÄ«t mākoņa platformas, piemēram, Kubernetes.

Programmatūras projektēŔanas principi

ProgrammÄ“Å”anas pasaulē principi attiecas uz diezgan vispārÄ«giem noteikumiem, kas jāievēro, izstrādājot programmatÅ«ru. Tos var izmantot, strādājot ar jebkuru programmÄ“Å”anas valodu. Katram principam ir savi mērÄ·i, kuru sasniegÅ”anas instrumenti parasti ir veidnes un prakse. Ir arÄ« vairāki pamatprincipi augstas kvalitātes programmatÅ«ras izveidei, no kuriem izriet visas pārējās. Å eit ir daži pamatprincipu piemēri:

  • KISS (Keep it simple, stupid) ā€“ nesarežģī;
  • DRY (Neatkārtojiet sevi) - neatkārtojiet sevi;
  • YAGNI (Jums tas nebÅ«s vajadzÄ«gs) - neradiet kaut ko, kas nav uzreiz vajadzÄ«gs;
  • SoC RÅ«pju noŔķirÅ”ana ā€“ dalÄ«t atbildÄ«bu.

Kā redzat, Å”ie principi nenosaka nekādus Ä«paÅ”us noteikumus, bet pieder pie tā saukto veselā saprāta apsvērumu kategorijas, kas balstÄ«tas uz praktisko pieredzi, ar kurām dalās daudzi izstrādātāji un uz ko viņi regulāri atsaucas.
Turklāt ir SOLID ā€“ Pirmo piecu objektu orientētās programmÄ“Å”anas un dizaina principu kopums, ko formulējis Roberts Mārtins. SOLID ietver plaÅ”us, beztermiņa, papildinoÅ”us principus, kas, ja tos piemēro kopā, palÄ«dz izveidot labākas programmatÅ«ras sistēmas un labāk uzturēt tās ilgtermiņā.

SOLID principi pieder pie OOP jomas un ir formulēti tādu jēdzienu un jēdzienu valodā kā klases, saskarnes un mantojums. Pēc analoÄ£ijas izstrādes principus var formulēt arÄ« mākoņa lietojumprogrammām, tikai pamatelements Å”eit nebÅ«s klase, bet konteiners. Ievērojot Å”os principus, varat izveidot konteinerizētas lietojumprogrammas, kas labāk atbilst mākoņa platformu, piemēram, Kubernetes, mērÄ·iem un uzdevumiem.

Mākoņvietīgie konteineri: Red Hat pieeja

MÅ«sdienās gandrÄ«z jebkuru lietojumprogrammu var salÄ«dzinoÅ”i viegli iesaiņot konteineros. Taču, lai lietojumprogrammas tiktu efektÄ«vi automatizētas un organizētas mākoņa platformā, piemēram, Kubernetes, ir jāpieliek papildu pÅ«les.
Tālāk izklāstÄ«to ideju pamatā bija metodoloÄ£ija Divpadsmit faktoru lietotne un daudzi citi darbi par dažādiem tÄ«mekļa lietojumprogrammu veidoÅ”anas aspektiem, sākot no pirmkoda pārvaldÄ«bas lÄ«dz mērogoÅ”anas modeļiem. AprakstÄ«tie principi attiecas tikai uz konteinerizētu lietojumprogrammu izstrādi, kas ir veidotas uz mikropakalpojumiem un ir paredzētas mākoņa platformām, piemēram, Kubernetes. MÅ«su diskusijas pamatelements ir konteinera attēls, un mērÄ·a konteinera izpildlaiks ir konteinera orÄ·estrÄ“Å”anas platforma. Piedāvāto principu mērÄ·is ir izveidot konteinerus, kuru plānoÅ”anas, mērogoÅ”anas un uzraudzÄ«bas uzdevumus var automatizēt lielākajā daļā orÄ·estrÄ“Å”anas platformu. Principi nav izklāstÄ«ti noteiktā secÄ«bā.

Vienotās bažas princips (SCP)

Å is princips daudzējādā ziņā ir lÄ«dzÄ«gs vienotas atbildÄ«bas principam. SRP), kas ir daļa no SOLID kopas un nosaka, ka katram objektam ir jābÅ«t vienai atbildÄ«bai, un Å”ai atbildÄ«bai ir jābÅ«t pilnÄ«bā ietvertai klasē. SRP bÅ«tÄ«ba ir tāda, ka katra atbildÄ«ba ir iemesls pārmaiņām, un klasei ir jābÅ«t vienam un tikai vienam iemeslu pārmaiņām.

SCP mēs izmantojam vārdu ā€œbažasā€, nevis vārda ā€œatbildÄ«baā€, lai norādÄ«tu uz konteinera augstāku abstrakcijas lÄ«meni un plaŔāku mērÄ·i salÄ«dzinājumā ar OOP klasi. Un, ja SRP mērÄ·is ir tikai viens iemesls izmaiņām, tad aiz SCP ir vēlme paplaÅ”ināt konteineru atkārtotas izmantoÅ”anas un nomaiņas iespējas. Ievērojot SRP un izveidojot konteineru, kas atrisina vienu problēmu un dara to funkcionāli pilnÄ«gā veidā, jÅ«s palielināsit iespēju atkārtoti izmantot Å”o konteinera attēlu dažādos lietojumprogrammu kontekstos.

SCP princips nosaka, ka katram konteineram ir jāatrisina viena problēma un tas jādara labi. Turklāt SCP konteineru pasaulē ir vieglāk sasniegt nekā SRP OOP pasaulē, jo konteineri parasti veic vienu procesu, un lielāko daļu laika Å”is process atrisina vienu uzdevumu.

Ja kādam konteinera mikropakalpojumam ir jāatrisina vairākas problēmas vienlaikus, tad to var sadalÄ«t viena uzdevuma konteineros un apvienot vienā podā (konteinera platformas izvietoÅ”anas vienÄ«bā), izmantojot blakusvāģa un sākuma konteinera veidnes. Turklāt SCP ļauj viegli nomainÄ«t veco konteineru (piemēram, tÄ«mekļa serveri vai ziņojumu brokeri) ar jaunu, kas atrisina to paÅ”u problēmu, bet kuram ir paplaÅ”ināta funkcionalitāte vai labāka mērogoÅ”ana.

5 veselā saprāta principi mākoņlietotņu izveidei

Augstas novērojamības princips (HOP)

Ja konteineri tiek izmantoti kā vienots lietojumprogrammu pakotnes un palaiÅ”anas veids, paÅ”as lietojumprogrammas tiek uzskatÄ«tas par melno kasti. Tomēr, ja tie ir mākoņa konteineri, tiem ir jānodroÅ”ina Ä«paÅ”as API izpildlaikam, lai uzraudzÄ«tu konteineru stāvokli un, ja nepiecieÅ”ams, veiktu attiecÄ«gas darbÄ«bas. Bez tā nebÅ«s iespējams unificēt konteineru atjaunināŔanas un to dzÄ«ves cikla pārvaldÄ«Å”anas automatizāciju, kas savukārt pasliktinās programmatÅ«ras sistēmas stabilitāti un lietojamÄ«bu.

5 veselā saprāta principi mākoņlietotņu izveidei
Praksē konteinerizētai lietojumprogrammai ir jābÅ«t vismaz API dažāda veida veselÄ«bas pārbaudēm: dzÄ«vÄ«guma pārbaudēm un gatavÄ«bas pārbaudēm. Ja lietojumprogramma apgalvo, ka dara vairāk, tai ir jānodroÅ”ina citi lÄ«dzekļi tās stāvokļa pārraudzÄ«bai. Piemēram, svarÄ«gu notikumu reÄ£istrÄ“Å”ana, izmantojot STDERR un STDOUT, žurnālu apkopoÅ”anai, izmantojot Fluentd, Logstash un citus lÄ«dzÄ«gus rÄ«kus. Kā arÄ« integrācija ar izsekoÅ”anas un metrikas kolekcijas bibliotēkām, piemēram, OpenTracing, Prometheus utt.

Kopumā lietojumprogrammu joprojām var uzskatīt par melno kasti, taču tai ir jābūt nodroŔinātai ar visiem platformai nepiecieŔamajiem API, lai to vislabāk uzraudzītu un pārvaldītu.

Dzīves cikla atbilstības princips (LCP)

LCP ir HOP antitēze. Kamēr HOP norāda, ka konteineram platformai ir jāpakļauj lasÄ«Å”anas API, LCP pieprasa, lai lietojumprogramma varētu pieņemt informāciju no platformas. Turklāt konteineram ir ne tikai jāsaņem notikumi, bet arÄ« jāpielāgojas, citiem vārdiem sakot, jāreaģē uz tiem. LÄ«dz ar to principa nosaukums, ko var uzskatÄ«t par prasÄ«bu nodroÅ”ināt platformu ar rakstÄ«Å”anas API.

5 veselā saprāta principi mākoņlietotņu izveidei
Platformās ir dažāda veida notikumi, kas palÄ«dz pārvaldÄ«t konteinera dzÄ«ves ciklu. Taču paÅ”as aplikācijas ziņā ir izlemt, kuru no tiem uztvert un kā reaģēt.

Ir skaidrs, ka daži notikumi ir svarÄ«gāki par citiem. Piemēram, ja lietojumprogramma slikti panes avārijas, tai ir jāpieņem signāls: terminate (SIGTERM) ziņojumi un pēc iespējas ātrāk jāuzsāk pārtraukÅ”anas rutÄ«na, lai uztvertu signālu: kill (SIGKILL), kas nāk pēc SIGTERM.

Turklāt tādi notikumi kā PostStart un PreStop var bÅ«t svarÄ«gi lietojumprogrammas dzÄ«ves ciklam. Piemēram, pēc lietojumprogrammas palaiÅ”anas tai var bÅ«t nepiecieÅ”ams zināms iesildÄ«Å”anās laiks, pirms tā var atbildēt uz pieprasÄ«jumiem. Vai arÄ« lietojumprogrammai, izslēdzot, ir jāatbrÄ«vo resursi kādā Ä«paŔā veidā.

Attēla nemainīguma princips (IIP)

Ir vispāratzÄ«ts, ka konteinerizētajām lietojumprogrammām pēc izveides ir jāpaliek nemainÄ«gām, pat ja tās tiek darbinātas dažādās vidēs. Tas rada nepiecieÅ”amÄ«bu izmantot datu glabāŔanu izpildlaikā (citiem vārdiem sakot, Å”im nolÅ«kam izmantot ārējos rÄ«kus) un paļauties uz ārējām, izpildlaikam specifiskām konfigurācijām, nevis pārveidot vai izveidot unikālus konteinerus katrai videi. Pēc jebkādām izmaiņām lietojumprogrammā konteinera attēls ir jāpārveido un jāizvieto visās izmantotajās vidēs. Starp citu, pārvaldot IT sistēmas, tiek izmantots lÄ«dzÄ«gs princips, kas pazÄ«stams kā serveru un infrastruktÅ«ras nemainÄ«guma princips.

IIP mērÄ·is ir novērst atseviŔķu konteinera attēlu izveidi dažādām izpildlaika vidēm un izmantot vienu un to paÅ”u attēlu visur kopā ar atbilstoÅ”u videi raksturÄ«gu konfigurāciju. Å Ä« principa ievēroÅ”ana ļauj Ä«stenot tādas no mākoņsistēmu automatizācijas viedokļa svarÄ«gas prakses kā lietojumprogrammu atjauninājumu atgrieÅ”ana un pārtÄ«Å”ana uz priekÅ”u.

5 veselā saprāta principi mākoņlietotņu izveidei

Procesa vienreizējās lietoÅ”anas princips (PDP)

Viena no svarÄ«gākajām konteinera Ä«paŔībām ir tā Ä«slaicÄ«gums: konteinera instanci ir viegli izveidot un viegli iznÄ«cināt, tāpēc to jebkurā laikā var viegli aizstāt ar citu. Šādai nomaiņai var bÅ«t daudz iemeslu: darbspējas pārbaudes kļūme, lietojumprogrammas mērogoÅ”ana, pārsÅ«tÄ«Å”ana uz citu resursdatoru, platformas resursu izsmelÅ”ana vai citas situācijas.

5 veselā saprāta principi mākoņlietotņu izveidei
Tā rezultātā konteinerizētajām lietojumprogrammām ir jāuztur savs stāvoklis, izmantojot kādus ārējus lÄ«dzekļus, vai Å”im nolÅ«kam jāizmanto iekŔējas sadalÄ«tas shēmas ar dublÄ“Å”anos. Turklāt lietojumprogrammai ir ātri jāstartē un ātri jāizslēdzas, kā arÄ« jābÅ«t gatavai pēkŔņai fatālai aparatÅ«ras kļūmei.

Viena prakse, kas palÄ«dz Ä«stenot Å”o principu, ir saglabāt konteinerus mazos. Mākoņvides var automātiski atlasÄ«t resursdatoru, kurā palaist konteinera instanci, tāpēc, jo mazāks konteiners, jo ātrāk tas tiks palaists ā€” tas vienkārÅ”i ātrāk tiks kopēts uz mērÄ·a resursdatoru tÄ«klā.

PaŔnorobežoŔanās princips (S-CP)

Saskaņā ar Å”o principu montāžas stadijā konteinerā ir iekļautas visas nepiecieÅ”amās sastāvdaļas. Konteiners ir jāveido, pieņemot, ka sistēmai ir tikai tÄ«rs Linux kodols, tāpēc visas nepiecieÅ”amās papildu bibliotēkas ir jāievieto paŔā konteinerā. Tajā jāietver arÄ« tādas lietas kā atbilstoŔās programmÄ“Å”anas valodas izpildlaiks, lietojumprogrammas platforma (ja nepiecieÅ”ams) un citas atkarÄ«bas, kas bÅ«s nepiecieÅ”amas, kamēr darbojas konteinera lietojumprogramma.

5 veselā saprāta principi mākoņlietotņu izveidei

Izņēmumi ir paredzēti konfigurācijām, kas dažādās vidēs atŔķiras un ir jānodroÅ”ina izpildlaikā, piemēram, izmantojot Kubernetes ConfigMap.

Lietojumprogramma var ietvert vairākus konteinerizētus komponentus, piemēram, atseviŔķu DBMS konteineru konteinerizētā tÄ«mekļa lietojumprogrammā. Pēc S-CP principa Å”os konteinerus nevajadzētu apvienot vienā, bet gan veidot tā, lai DBMS konteinerā bÅ«tu viss nepiecieÅ”amais datu bāzes darbÄ«bai, bet tÄ«mekļa aplikāciju konteinerā bÅ«tu viss nepiecieÅ”amais tÄ«mekļa darbÄ«bai. lietojumprogramma, tas pats tÄ«mekļa serveris . Tā rezultātā izpildes laikā tÄ«mekļa lietojumprogrammas konteiners bÅ«s atkarÄ«gs no DBVS konteinera un tam piekļūst pēc vajadzÄ«bas.

Izpildlaika ierobežojuma princips (RCP)

S-CP princips nosaka, kā konteiners ir jāveido un kam jābÅ«t attēla binārajam failam. Bet konteiners nav tikai ā€œmelnā kasteā€, kurai ir tikai viena Ä«paŔība - faila lielums. Izpildes laikā konteiners iegÅ«st citus izmērus: izmantotās atmiņas apjomu, CPU laiku un citus sistēmas resursus.

5 veselā saprāta principi mākoņlietotņu izveidei
Un Å”eit noder RCP princips, saskaņā ar kuru konteineram ir jāatdala savas prasÄ«bas sistēmas resursiem un jāpārnes uz platformu. Izmantojot katra konteinera resursu profilus (cik daudz CPU, atmiņas, tÄ«kla un diska resursu tai ir nepiecieÅ”ams), platforma var optimāli veikt plānoÅ”anu un automātisko mērogoÅ”anu, pārvaldÄ«t IT jaudu un uzturēt SLA lÄ«meņus konteineriem.

Papildus konteinera resursu prasībām ir svarīgi, lai lietojumprogramma nepārsniegtu savas robežas. Pretējā gadījumā, kad rodas resursu trūkums, platforma, visticamāk, to iekļaus to lietojumprogrammu sarakstā, kuras ir jāpārtrauc vai jāmigrē.

Kad mēs runājam par to, ka mākonis ir pirmais, mēs runājam par veidu, kā mēs strādājam.
IepriekÅ” mēs formulējām vairākus vispārÄ«gus principus, kas nosaka metodisko pamatu augstas kvalitātes konteineru lietojumprogrammu izveidei mākoņa vidēm.

Ņemiet vērā, ka papildus Å”iem vispārÄ«gajiem principiem jums bÅ«s nepiecieÅ”amas arÄ« papildu uzlabotas metodes un paņēmieni darbam ar konteineriem. Turklāt mums ir daži Ä«si ieteikumi, kas ir konkrētāki un bÅ«tu jāpiemēro (vai nepiemēro) atkarÄ«bā no situācijas:

  • Mēģiniet samazināt attēlu lielumu: izdzēsiet pagaidu failus un neinstalējiet nevajadzÄ«gas pakotnes - jo mazāks ir konteinera izmērs, jo ātrāk tas tiek samontēts un pārkopēts uz mērÄ·a resursdatoru tÄ«klā.
  • Koncentrējieties uz patvaļīgiem lietotāju ID: konteineru palaiÅ”anai neizmantojiet komandu sudo vai kādu Ä«paÅ”u lietotāja ID.
  • AtzÄ«mējiet svarÄ«gos portus: portu numurus varat iestatÄ«t izpildes laikā, taču labāk tos norādÄ«t, izmantojot komandu EXPOSE ā€” tas atvieglos jÅ«su attēlu izmantoÅ”anu citiem cilvēkiem un programmām.
  • Saglabājiet pastāvÄ«gus datus par sējumiem: dati, kuriem vajadzētu palikt pēc konteinera iznÄ«cināŔanas, jāieraksta sējumos.
  • Rakstiet attēla metadatus: tagi, etiÄ·etes un anotācijas atvieglo attēlu lietoÅ”anu ā€” citi izstrādātāji jums pateiks paldies.
  • Sinhronizēt saimniekdatoru un attēlus: dažām konteinerizētajām lietojumprogrammām konteineram ir jāsinhronizējas ar resursdatoru, izmantojot noteiktus atribÅ«tus, piemēram, laiku vai maŔīnas ID.
  • Noslēgumā mēs dalāmies ar veidnēm un paraugpraksi, kas palÄ«dzēs efektÄ«vāk Ä«stenot iepriekÅ” minētos principus.
    www.slideshare.net/luebken/container-patterns
    docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
    docs.projectatomic.io/container-best-practices
    docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
    www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
    leanpub.com/k8spatterns
    12factor.net

Vebinārs par OpenShift Container Platform jauno versiju ā€” 4
11.jūnijā plkst.11.00

Ko jūs uzzināsiet:

  • NemainÄ«gs Red Hat Enterprise Linux CoreOS
  • OpenShift pakalpojumu tÄ«kls
  • Operatora ietvars
  • Knative ietvars

Avots: www.habr.com

Pievieno komentāru