„Savosios debesies“ arba tiesiog „debesų“ programos yra sukurtos specialiai dirbti debesų infrastruktūrose. Paprastai jie yra sukurti kaip laisvai susietų mikropaslaugų rinkinys, supakuotas į konteinerius, kuriuos savo ruožtu valdo debesų platforma. Tokios programos yra paruoštos gedimams pagal nutylėjimą, o tai reiškia, kad jos veikia patikimai ir plečiasi net ir rimtų infrastruktūros lygio gedimų atveju. Kita medalio pusė – apribojimų (sutarčių) rinkiniai, kuriuos debesų platforma nustato konteinerių programoms, kad būtų galima jas valdyti automatiškai.
Nors daugelis organizacijų puikiai žino, kad reikia ir svarbu pereiti prie debesies pagrindu veikiančių programų, daugelis organizacijų vis dar nežino, nuo ko pradėti. Šiame įraše apžvelgsime keletą principų, kurių vadovaudamiesi kuriant konteinerines programas, galėsite suvokti debesų platformų potencialą ir pasiekti patikimą programų veikimą bei mastelį net ir rimtų IT infrastruktūros gedimų atveju. lygiu. Galutinis čia išdėstytų principų tikslas yra išmokti kurti programas, kurias gali automatiškai valdyti debesų platformos, pvz., Kubernetes.
Programinės įrangos projektavimo principai
Programavimo pasaulyje principai reiškia gana bendras taisykles, kurių reikia laikytis kuriant programinę įrangą. Jie gali būti naudojami dirbant su bet kuria programavimo kalba. Kiekvienas principas turi savo tikslus, kurių įgyvendinimo įrankiai dažniausiai yra šablonai ir praktika. Taip pat yra keletas pagrindinių aukštos kokybės programinės įrangos kūrimo principų, iš kurių kyla visa kita. Štai keletas pagrindinių principų pavyzdžių:
- (Keep it simple, stupid) – neapsunkink;
- (Nekartokite savęs) - nekartokite savęs;
- (Jums to nereikės) - nekurkite to, ko nereikia iš karto;
- Rūpesčių atskyrimas – pasidalykite atsakomybe.
Kaip matote, šie principai nenustato jokių konkrečių taisyklių, o priklauso vadinamųjų sveiko proto samprotavimų, pagrįstų praktine patirtimi, kategorijai, kuria dalijasi daugelis kūrėjų ir kuria jie nuolat remiasi.
Be to, yra – Pirmųjų penkių objektinio programavimo ir projektavimo principų rinkinys, suformuluotas Roberto Martino. SOLID apima plačius, neribotus, vienas kitą papildančius principus, kurie, taikomi kartu, padeda sukurti geresnes programinės įrangos sistemas ir geriau jas išlaikyti ilgą laiką.
SOLID principai priklauso OOP sričiai ir yra suformuluoti tokių sąvokų ir sąvokų kaip klasės, sąsajos ir paveldėjimas kalba. Pagal analogiją, kūrimo principus galima suformuluoti ir debesų programoms, tik pagrindinis elementas čia bus ne klasė, o konteineris. Laikydamiesi šių principų galite kurti konteinerines programas, kurios geriau atitiktų debesų platformų, tokių kaip „Kubernetes“, tikslus ir uždavinius.
Vietiniai debesies konteineriai: „Red Hat“ metodas
Šiandien beveik bet kokia programa gali būti gana lengvai supakuota į konteinerius. Tačiau norint, kad programos būtų efektyviai automatizuotos ir sutvarkytos debesų platformoje, pvz., „Kubernetes“, reikia papildomų pastangų.
Toliau išdėstytų idėjų pagrindas buvo metodika ir daug kitų darbų, susijusių su įvairiais žiniatinklio programų kūrimo aspektais, nuo šaltinio kodo valdymo iki mastelio modelių. Aprašyti principai taikomi tik kuriant konteinerines programas, kurios yra sukurtos ant mikro paslaugų ir skirtos debesų platformoms, tokioms kaip Kubernetes. Pagrindinis mūsų diskusijos elementas yra konteinerio vaizdas, o tikslinė sudėtinio rodinio vykdymo laikas yra konteinerio orkestravimo platforma. Siūlomų principų tikslas – sukurti konteinerius, kurių planavimo, mastelio keitimo ir stebėjimo užduotis būtų galima automatizuoti daugelyje orkestravimo platformų. Principai pateikiami jokia tvarka.
Vieno susirūpinimo principas (SCP)
Šis principas daugeliu atžvilgių panašus į bendros atsakomybės principą. ), kuris yra SOLID rinkinio dalis ir teigia, kad kiekvienas objektas turi turėti vieną atsakomybę ir ši atsakomybė turi būti visiškai įtraukta į klasę. SRP esmė ta, kad kiekviena atsakomybė yra pokyčių priežastis, o klasė turi turėti vieną ir vienintelę priežastį pokyčiams.
SCP vietoje žodžio „atsakomybė“ naudojame žodį „koncernas“, kad parodytume aukštesnį abstrakcijos lygį ir platesnę konteinerio paskirtį, palyginti su OOP klase. Ir jei SRP tikslas yra turėti tik vieną priežastį keisti, tai už SCP yra noras išplėsti galimybę pakartotinai naudoti ir pakeisti konteinerius. Vadovaudamiesi SRP ir sukurdami konteinerį, kuris išsprendžia vieną problemą ir atlieka tai funkcionaliai iki galo, padidinate galimybę pakartotinai panaudoti tą konteinerio vaizdą skirtinguose programų kontekstuose.
SCP principas teigia, kad kiekvienas konteineris turi išspręsti vieną problemą ir tai padaryti gerai. Be to, SCP konteinerių pasaulyje yra lengviau pasiekti nei SRP OOP pasaulyje, nes konteineriai paprastai vykdo vieną procesą ir dažniausiai šis procesas išsprendžia vieną užduotį.
Jei konteinerio mikropaslauga turi išspręsti kelias problemas vienu metu, tada ją galima suskirstyti į vienos užduoties konteinerius ir sujungti į vieną bloką (konteinerio platformos diegimo vienetą), naudojant šoninio vežimėlio ir pradinio konteinerio šablonus. Be to, naudojant SCP galima lengvai pakeisti seną konteinerį (pvz., žiniatinklio serverį ar pranešimų tarpininką) nauju, kuris išsprendžia tą pačią problemą, bet turi išplėstą funkcionalumą arba geriau keičiasi.
Aukšto stebėjimo principas (HOP)
Kai konteineriai naudojami kaip vieningas būdas pakuoti ir paleisti programas, pačios programos laikomos juodąja dėže. Tačiau, jei tai yra debesies konteineriai, jie turi pateikti specialias API vykdymo laikui, kad būtų galima stebėti konteinerių būklę ir, jei reikia, imtis atitinkamų veiksmų. Be to nebus įmanoma suvienodinti konteinerių atnaujinimo ir jų gyvavimo ciklo valdymo automatizavimo, o tai savo ruožtu pablogins programinės įrangos sistemos stabilumą ir tinkamumą naudoti.
Praktiškai konteinerinė programa turėtų turėti bent API įvairiems sveikatos patikrinimams: gyvumo ir pasirengimo testams. Jei programoje reikalaujama padaryti daugiau, ji turi pateikti kitas priemones jos būsenai stebėti. Pavyzdžiui, svarbių įvykių registravimas per STDERR ir STDOUT, kad būtų galima kaupti žurnalus naudojant Fluentd, Logstash ir kitus panašius įrankius. Taip pat integracija su sekimo ir metrikos rinkinių bibliotekomis, tokiomis kaip „OpenTracing“, „Prometheus“ ir kt.
Apskritai programa vis tiek gali būti traktuojama kaip juodoji dėžė, tačiau joje turi būti visos platformai reikalingos API, kad ją būtų galima kuo geriau stebėti ir valdyti.
Gyvenimo ciklo atitikties principas (LCP)
LCP yra HOP priešingybė. Nors HOP teigia, kad konteineris turi atskleisti skaitymo API platformai, LCP reikalauja, kad programa galėtų priimti informaciją iš platformos. Be to, konteineris turi ne tik priimti įvykius, bet ir prisitaikyti, kitaip tariant, į juos reaguoti. Iš čia ir kilo principo pavadinimas, kuris gali būti laikomas reikalavimu aprūpinti platformą rašymo API.
Platformose yra įvairių tipų įvykių, padedančių valdyti konteinerio gyvavimo ciklą. Tačiau pati programa turi nuspręsti, kurią iš jų suvokti ir kaip reaguoti.
Akivaizdu, kad vieni įvykiai svarbesni už kitus. Pavyzdžiui, jei programa blogai toleruoja gedimus, ji turi priimti signalo: terminate (SIGTERM) pranešimus ir kuo greičiau inicijuoti nutraukimo rutiną, kad gautų signalą: kill (SIGKILL), kuris ateina po SIGTERM.
Be to, tokie įvykiai kaip PostStart ir PreStop gali būti svarbūs programos gyvavimo ciklui. Pavyzdžiui, paleidus programą, gali prireikti šiek tiek įšilimo laiko, kad ji galėtų atsakyti į užklausas. Arba programa išjungdama turi išleisti išteklius kokiu nors specialiu būdu.
Vaizdo nekintamumo principas (IIP)
Visuotinai pripažįstama, kad konteinerinės programos po sukūrimo turėtų likti nepakitusios, net jei jos naudojamos skirtingose aplinkose. Dėl to reikia paleisti duomenų saugyklą vykdymo metu (kitaip tariant, tam naudoti išorinius įrankius) ir pasikliauti išorinėmis, vykdymo laikui būdingomis konfigūracijomis, o ne keisti ar kurti unikalius konteinerius kiekvienai aplinkai. Po bet kokių programos pakeitimų konteinerio vaizdas turi būti perkurtas ir įdiegtas visose naudojamose aplinkose. Beje, valdant IT sistemas, naudojamas panašus principas, žinomas kaip serverių ir infrastruktūros nekintamumo principas.
IIP tikslas yra neleisti sukurti atskirų konteinerių vaizdų skirtingoms vykdymo aplinkoms ir visur naudoti tą patį vaizdą kartu su atitinkama aplinkai būdinga konfigūracija. Šio principo laikymasis leidžia įgyvendinti tokias svarbias debesų sistemų automatizavimo praktikas kaip programų atnaujinimų atšaukimas ir perkėlimas į priekį.
Proceso disponavimo principas (PDP)
Viena iš svarbiausių konteinerio savybių yra jo trumpalaikiškumas: konteinerio egzempliorių lengva sukurti ir lengva sunaikinti, todėl jį bet kada galima lengvai pakeisti kitu. Tokio pakeitimo priežasčių gali būti daug: tinkamumo naudoti testo gedimas, programos mastelio keitimas, perkėlimas į kitą pagrindinį kompiuterį, platformos išteklių išeikvojimas ar kitos situacijos.
Dėl to konteinerinės programos turi išlaikyti savo būseną naudodami tam tikras išorines priemones arba naudoti vidines paskirstytas schemas su pertekliumi. Be to, programa turi greitai įsijungti ir greitai išsijungti bei būti pasirengusi staigiam mirtinam aparatinės įrangos gedimui.
Viena praktika, padedanti įgyvendinti šį principą, yra konteinerių mažėjimas. Debesų aplinkose galima automatiškai pasirinkti pagrindinį kompiuterį, kuriame bus paleistas konteinerio egzempliorius, todėl kuo mažesnis konteineris, tuo greičiau jis bus paleistas – tiesiog greičiau nukopijuos į tikslinį pagrindinį kompiuterį tinkle.
Savarankiškumo principas (S-CP)
Pagal šį principą surinkimo etape į konteinerį įtraukiami visi reikalingi komponentai. Konteineris turėtų būti kuriamas darant prielaidą, kad sistemoje yra tik grynas Linux branduolys, todėl visos reikalingos papildomos bibliotekos turėtų būti dedamos į patį konteinerį. Jame taip pat turėtų būti tokie dalykai, kaip atitinkamos programavimo kalbos vykdymo laikas, programos platforma (jei reikia) ir kitos priklausomybės, kurių reikės, kai veikia konteinerio programa.
Išimtys taikomos konfigūracijoms, kurios skiriasi priklausomai nuo aplinkos ir turi būti pateiktos vykdymo metu, pavyzdžiui, naudojant Kubernetes ConfigMap.
Programoje gali būti keli sudėtiniai komponentai, pavyzdžiui, atskiras DBVS konteineris talpykloje esančioje žiniatinklio programoje. Pagal S-CP principą šie konteineriai neturėtų būti sujungti į vieną, o padaryti taip, kad DBMS konteineryje būtų viskas, ko reikia duomenų bazės darbui, o žiniatinklio programų konteineryje būtų viskas, ko reikia žiniatinklio veikimui. programa, tas pats žiniatinklio serveris . Todėl vykdymo metu žiniatinklio programos konteineris priklausys nuo DBMS konteinerio ir prireikus prie jo pasieks.
Vykdymo laiko apribojimo principas (RCP)
S-CP principas apibrėžia, kaip konteineris turi būti kuriamas ir kas turi būti dvejetainiame vaizdo faile. Tačiau konteineris nėra tik „juodoji dėžutė“, kuri turi tik vieną savybę - failo dydį. Vykdymo metu konteineris įgauna kitus matmenis: naudojamą atminties kiekį, procesoriaus laiką ir kitus sistemos išteklius.
Ir čia praverčia RCP principas, pagal kurį konteineris turi nukirsti savo reikalavimus sistemos resursams ir perkelti juos į platformą. Turėdama kiekvieno konteinerio išteklių profilius (kiek procesoriaus, atminties, tinklo ir disko išteklių jai reikia), platforma gali optimaliai atlikti planavimą ir automatinį mastelio keitimą, valdyti IT pajėgumus ir išlaikyti konteinerių SLA lygius.
Be to, kad ji atitiktų konteinerio išteklių reikalavimus, taip pat svarbu, kad programa neperžengtų savo ribų. Priešingu atveju, kai pritrūksta išteklių, platforma greičiausiai įtrauks ją į programų, kurias reikia nutraukti arba perkelti, sąrašą.
Kai kalbame apie tai, kad pirmieji debesys, mes kalbame apie tai, kaip dirbame.
Aukščiau suformulavome keletą bendrųjų principų, kurie nustato metodinį pagrindą kuriant aukštos kokybės konteinerių programas debesų aplinkoje.
Atminkite, kad be šių bendrųjų principų jums taip pat reikės papildomų pažangių metodų ir metodų dirbant su konteineriais. Be to, turime keletą trumpų rekomendacijų, kurios yra konkretesnės ir turėtų būti taikomos (arba netaikytinos) atsižvelgiant į situaciją:
- Stenkitės sumažinti vaizdų dydį: ištrinkite laikinus failus ir neįdiekite nereikalingų paketų – kuo mažesnis konteinerio dydis, tuo greičiau jis surenkamas ir nukopijuojamas į tikslinį pagrindinį kompiuterį tinkle.
- Sutelkite dėmesį į savavališkus vartotojo ID: nenaudokite komandos sudo ar jokio specialaus vartotojo ID, kad paleistumėte konteinerius.
- Pažymėkite svarbius prievadus: prievadų numerius galite nustatyti vykdymo metu, tačiau geriau juos nurodyti naudodami komandą EXPOSE – taip kitiems žmonėms ir programoms bus lengviau naudotis jūsų vaizdais.
- Saugokite nuolatinius tomų duomenis: duomenys, kurie turėtų likti sunaikinus konteinerį, turėtų būti įrašyti į tomus.
- Rašykite vaizdo metaduomenis: žymos, etiketės ir komentarai palengvina vaizdų naudojimą – kiti kūrėjai jums padėkos.
- Sinchronizuoti pagrindinį kompiuterį ir vaizdus: kai kurios sudėtinės programos reikalauja, kad sudėtinis rodinys būtų sinchronizuojamas su pagrindiniu kompiuteriu pagal tam tikrus atributus, pvz., laiką arba įrenginio ID.
- Baigdami dalijamės šablonais ir geriausios praktikos pavyzdžiais, kurie padės efektyviau įgyvendinti aukščiau išvardintus principus:
birželio 11 d., 11.00 val
Ką išmoksite:
- Nekintama Red Hat Enterprise Linux CoreOS
- „OpenShift“ paslaugų tinklelis
- Operatoriaus sistema
- Natūralus karkasas
Šaltinis: www.habr.com