"Hodeiko jatorrizko" edo, besterik gabe, "hodeiko" aplikazioak hodeiko azpiegituretan lan egiteko bereziki sortzen dira. Normalean, edukiontzietan ontziratutako mikrozerbitzu baxuen multzo gisa eraikitzen dira, hodeiko plataforma batek kudeatzen dituena. Horrelako aplikazioak hutsegiteetarako prestatuta daude lehenespenez, hau da, fidagarritasunez funtzionatzen dute eta eskalatzen dute azpiegitura mailako akats larriak izan arren. Txanponaren beste aldea hodeiko plataformak edukiontzien aplikazioei ezartzen dizkien murrizketa (kontratu) multzoak dira, automatikoki kudeatu ahal izateko.
Hodeian oinarritutako aplikazioetara pasatzearen beharraz eta garrantziaz guztiz jabetuta dauden arren, erakunde askok oraindik ez dakite nondik hasi. Argitalpen honetan, edukiontzidun aplikazioak garatzerakoan jarraituz gero, hodeiko plataformen potentzialaz jabetzeko eta aplikazioen funtzionamendu eta eskalatze fidagarria lortzeko aukera emango dizuten printzipio batzuk aztertuko ditugu, nahiz eta IT azpiegituretan hutsegite larriak izan. maila. Hemen azaltzen diren printzipioen azken helburua Kubernetes bezalako hodeiko plataformek automatikoki kudeatu ditzaketen aplikazioak nola eraikitzen ikastea da.
Softwarearen diseinuaren printzipioak
Programazioaren munduan, printzipioek softwarea garatzerakoan bete beharreko arau nahiko orokorrak aipatzen dituzte. Edozein programazio-lengoaiarekin lan egiteko erabil daitezke. Printzipio bakoitzak bere helburuak ditu, lortzeko tresnak normalean txantiloiak eta praktikak izan ohi direnak. Kalitate handiko softwarea sortzeko oinarrizko printzipio batzuk ere badaude, eta bertatik ateratzen dira beste guztiak. Hona hemen oinarrizko printzipioen adibide batzuk:
- (Keep it simple, stupid) - ez zaildu;
- (Ez errepikatu zeure burua) - ez errepikatu;
- (Ez duzu behar izango) - ez sortu berehala behar ez den zerbait;
- Kezkak bereiztea - erantzukizunak partekatu.
Ikus dezakezunez, printzipio hauek ez dute arau zehatzik ezartzen, baina esperientzia praktikoan oinarritutako zentzu komuneko gogoeten kategoriakoak dira, garatzaile askok partekatzen dituztenak eta aldian-aldian aipatzen dituztenak.
Horrez gain, badago β Objektuetara zuzendutako programazioaren eta diseinuaren lehen bost printzipioen multzoa, Robert Martinek formulatua. SOLIDek printzipio zabal, irekiak eta osagarriak biltzen ditu, elkarrekin aplikatzen direnean, software-sistema hobeak sortzen eta epe luzera hobeto mantentzen laguntzen dutenak.
SOLID printzipioak OOPren eremukoak dira eta klaseak, interfazeak eta herentzia bezalako kontzeptu eta kontzeptuen hizkuntzan formulatzen dira. Analogiaz, garapen-printzipioak hodeiko aplikazioetarako ere formula daitezke, hemen oinarrizko elementua ez da klase bat izango, edukiontzi bat baizik. Printzipio hauek jarraituz, Kubernetes bezalako hodeiko plataformen helburuak eta helburuak hobeto betetzen dituzten edukiontzidun aplikazioak sor ditzakezu.
Hodeiko jatorrizko edukiontziak: Red Hat ikuspegia
Gaur egun, ia edozein aplikazio nahiko erraz ontziratu daitezke ontzietan. Baina aplikazioak Kubernetes bezalako hodeiko plataforma batean modu eraginkorrean automatizatu eta orkestratzeko, ahalegin gehigarria behar da.
Jarraian azaltzen diren ideien oinarria metodologia izan zen eta beste hainbat lan web aplikazioak eraikitzeko hainbat alderdiri buruz, iturburu-kodearen kudeaketatik hasi eta eskalatze-ereduetaraino. Deskribatutako printzipioak mikrozerbitzuen gainean eraikitako eta Kubernetes bezalako hodeiko plataformetarako diseinatutako edukiontzidun aplikazioen garapenean soilik aplikatzen dira. Gure eztabaidaren oinarrizko elementua edukiontziaren irudia da, eta helburuko edukiontziaren exekuzio-denbora edukiontziaren orkestrazio plataforma da. Proposatutako printzipioen helburua orkestrazio-plataforma gehienetan programazio, eskalatze eta jarraipena egiteko lanak automatizatzeko edukiontziak sortzea da. Printzipioak ez dira ordena berezirik aurkezten.
Kezka bakarraren printzipioa (SCP)
Printzipio hau Erantzukizun bakarraren Printzipioaren antzekoa da zentzu askotan. ), SOLID multzoaren parte dena eta objektu bakoitzak erantzukizun bat izan behar duela dio, eta erantzukizun hori klase batean erabat barneratu behar dela. SRPren helburua da erantzukizun oro aldaketarako arrazoi bat dela, eta klase batek aldaketarako arrazoi bakarra eta bakarra izan behar duela.
SCP-n, "kezka" hitza erabiltzen dugu "erantzukizuna" hitzaren ordez, edukiontzi baten abstrakzio maila altuagoa eta helburu zabalagoa OOP klase batekin alderatuta adierazteko. Eta SRPren helburua aldaketarako arrazoi bakarra izatea bada, SCPren atzean edukiontziak berrerabiltzeko eta ordezkatzeko gaitasuna zabaltzeko nahia dago. SRP jarraituz eta arazo bakarra konpontzen duen eta modu funtzionalki oso batean egiten duen edukiontzi bat sortuz, edukiontziaren irudi hori aplikazio-testuinguru ezberdinetan berrerabiltzeko aukerak areagotzen dituzu.
SCP printzipioak dio edukiontzi bakoitzak arazo bakarra konpondu eta ondo egin behar duela. Gainera, edukiontzien munduan SCP errazago lortzen da OOP munduan SRP baino, edukiontziek normalean prozesu bakarra exekutatzen baitute, eta gehienetan prozesu honek zeregin bakarra ebazten du.
Edukiontzi-mikrozerbitzu batek hainbat arazo aldi berean konpondu behar baditu, zeregin bakarreko edukiontzietan zatitu eta pod (edukiontzi-plataformaren inplementazio-unitatea) batera konbina daiteke sidecar eta init edukiontzi txantiloiak erabiliz. Gainera, SCP-k edukiontzi zahar bat (adibidez, web zerbitzaria edo mezu-artekaria) arazo bera konpontzen duen baina funtzionaltasuna zabaldu edo hobeto eskalatzen duen berri batekin ordezkatzea errazten du.
Behagarritasun handiko printzipioa (HOP)
Ontziak aplikazioak paketatzeko eta exekutatzeko modu bateratu gisa erabiltzen direnean, aplikazioak berak kutxa beltz gisa hartzen dira. Hala ere, hodeiko edukiontziak badira, orduan API bereziak eman behar dizkiote exekuzio-denborari, edukiontzien osasuna kontrolatzeko eta, behar izanez gero, neurri egokiak hartzeko. Hori gabe, ezin izango da bateratu edukiontziak eguneratzeko eta haien bizi-zikloa kudeatzeko automatizazioa, eta horrek, aldi berean, software-sistemaren egonkortasuna eta erabilgarritasuna okerrera egingo du.
Praktikan, edukiontzidun aplikazio batek, gutxienez, API bat izan beharko luke hainbat osasun-kontroletarako: bizitasun-probak eta prest-probak. Aplikazio batek gehiago egiten duela esaten badu, bere egoera kontrolatzeko beste bide batzuk eman behar ditu. Adibidez, STDERR eta STDOUT bidez gertaera garrantzitsuak erregistratzea erregistroak gehitzeko Fluentd, Logstash eta antzeko beste tresna batzuk erabiliz. Baita trazadura eta metrika bildumako liburutegiekin ere, hala nola OpenTracing, Prometheus, etab.
Oro har, aplikazioa kutxa beltz gisa trata daiteke oraindik, baina plataformak behar dituen API guztiak hornitu behar ditu, ahalik eta modurik onenean kontrolatu eta kudeatu ahal izateko.
Bizi-zikloaren adostasun-printzipioa (LCP)
LCP HOParen antitesia da. HOPek dioen arren edukiontziak irakurritako APIak plataformara erakutsi behar dituela, LCPk aplikazioak plataformako informazioa onartu ahal izateko eskatzen du. Gainera, edukiontziak gertaerak jaso ez ezik, egokitu behar ditu, hau da, horiei erreakzionatu. Hortik dator printzipioaren izena, plataformari idazteko APIak emateko baldintzatzat har daitekeena.
Plataformek gertaera mota desberdinak dituzte edukiontzi baten bizi-zikloa kudeatzen laguntzeko. Baina aplikazioari berari dagokio haietako zein hautematen eta nola erreakzionatu erabakitzea.
Argi dago gertaera batzuk besteak baino garrantzitsuagoak direla. Adibidez, aplikazio batek ez baditu ondo jasaten kraskadurak, seinalea: amaitu (SIGTERM) mezuak onartu behar ditu eta bere amaiera-errutina hasi ahalik eta azkarren SIGTERMren ondoren datorren seinalea harrapatzeko: hil (SIGKILL).
Gainera, PostStart eta PreStop bezalako gertaerak garrantzitsuak izan daitezke aplikazio baten bizi-zikloan. Adibidez, aplikazio bat abiarazi ondoren, baliteke beroketa-denbora bat behar izatea eskaerei erantzun ahal izateko. Edo aplikazioak baliabideak modu berezi batean askatu behar ditu itzaltzean.
Irudiaren aldaezintasun printzipioa (IIP)
Orokorrean onartzen da edukiontzidun aplikazioak aldatu gabe mantendu behar direla eraiki ondoren, ingurune ezberdinetan exekutatzen badira ere. Horrek eskatzen du exekuzioan datu biltegiratzea kanporatu beharra (hau da, horretarako kanpoko tresnak erabiltzea) eta kanpoko exekuzio-denborarako berariazko konfigurazioetan oinarritzea, ingurune bakoitzerako edukiontzi bakarrak aldatu edo sortu beharrean. Aplikazioan edozein aldaketa egin ondoren, edukiontziaren irudia berreraiki eta erabilitako ingurune guztietan zabaldu behar da. Bide batez, informatika sistemak kudeatzeko orduan, antzeko printzipio bat erabiltzen da, zerbitzarien eta azpiegituren aldaezintasunaren printzipioa deritzona.
IIPren helburua da exekuzio-ingurune desberdinetarako edukiontzi-irudi bereiziak sortzea saihestea eta irudi bera nonahi erabiltzea inguruneari dagokion konfigurazio zehatzarekin batera. Printzipio honi jarraitzeak hodeiko sistemen automatizazioaren ikuspegitik praktika garrantzitsuak ezartzeko aukera ematen du, aplikazioen eguneraketak atzera eta aurrera egiteko.
Prozesua erabiltzeko printzipioa (PDP)
Edukiontzi baten ezaugarri garrantzitsuenetako bat bere iragankortasuna da: edukiontzi baten instantzia bat erraz sortzen da eta erraza da suntsitzen, beraz, edozein unetan erraz ordezkatu daiteke beste instantzia batekin. Ordezkapen hori egiteko arrazoi asko egon daitezke: zerbitzu-probaren huts egitea, aplikazioaren eskalatzea, beste ostalari batera transferitzea, plataformaren baliabideak agortzea edo beste egoera batzuk.
Ondorioz, edukiontzidun aplikazioek beren egoera mantendu behar dute kanpoko bitarteko batzuk erabiliz, edo horretarako erredundantzia duten barne-eskema banatuak erabili. Horrez gain, aplikazioa azkar hasi eta azkar itxi behar da, eta bat-bateko hardware akatsetarako prestatuta egon behar du.
Printzipio hau ezartzen laguntzen duen praktika bat ontziak txikiak mantentzea da. Hodei-inguruneek automatikoki hauta dezakete edukiontzi-instantzia bat abiarazteko ostalari bat; beraz, zenbat eta txikiagoa izan edukiontzia, orduan eta azkarrago hasiko da - sarean helburuko ostalarira bizkorrago kopiatuko da.
Auto-euste printzipioa (S-CP)
Printzipio horren arabera, muntaketa fasean, beharrezko osagai guztiak ontzian sartzen dira. Edukiontzia sistemak Linux kernel hutsa baino ez duela kontuan hartuta eraiki behar da, beraz, beharrezko liburutegi osagarri guztiak edukiontzian bertan jarri behar dira. Dagokion programazio-lengoaiaren exekuzio-denbora, aplikazio-plataforma (beharrezkoa bada) eta edukiontzi-aplikazioa exekutatzen ari den bitartean beharrezkoak diren beste mendekotasun batzuk ere eduki behar ditu.
Ingurune batetik bestera aldatzen diren eta exekuzioan eman behar diren konfigurazioetarako salbuespenak egiten dira, adibidez Kubernetes ConfigMap baten bidez.
Aplikazio batek edukiontzidun hainbat osagai izan ditzake, adibidez, DBMS edukiontzi bereizi bat edukiontzidun web aplikazio baten barruan. S-CP printzipioaren arabera, edukiontzi hauek ez dira batean konbinatu behar, baizik eta DBMS edukiontziak datu-basearen funtzionamendurako beharrezkoa den guztia eduki dezan, eta web aplikazioaren edukiontziak webaren funtzionamendurako beharrezkoa den guztia izan dezan. aplikazioa, web zerbitzari bera. Ondorioz, exekuzioan web aplikazioaren edukiontzia DBMS edukiontziaren araberakoa izango da eta behar den moduan sartuko da.
Runtime Confinement printzipioa (RCP)
S-CP printzipioak edukiontzia nola eraiki behar den eta irudi bitarrak zer eduki behar duen definitzen du. Baina edukiontzi bat ez da ezaugarri bakarra duen "kutxa beltza" soilik: fitxategiaren tamaina. Exekuzioan, edukiontziak beste dimentsio batzuk hartzen ditu: erabilitako memoria kopurua, CPU denbora eta sistemaren beste baliabide batzuk.
Eta hemen RCP printzipioa ondo dator, eta, horren arabera, edukiontziak sistemaren baliabideen eskakizunak kendu eta plataformara transferitu behar ditu. Edukiontzi bakoitzaren baliabide-profilekin (zenbat CPU, memoria, sare eta disko-baliabide behar dituen), plataformak modu ezin hobean egin ditzake programazioa eta eskala automatikoa, IT gaitasuna kudeatu eta edukiontzien SLA mailak mantendu.
Edukiontziaren baliabide-eskakizunak betetzeaz gain, garrantzitsua da aplikazioak bere mugetatik kanpo ez joatea. Bestela, baliabide eskasia gertatzen denean, plataformak litekeena da amaitu edo migratu behar diren aplikazioen zerrendan sartzea.
Hodeiaren lehena izateaz hitz egiten dugunean, lan egiteko moduaz ari gara.
Goian, hodeiko inguruneetarako kalitate handiko edukiontzien aplikazioak eraikitzeko oinarri metodologikoak ezartzen dituzten printzipio orokor batzuk formulatu ditugu.
Kontuan izan printzipio orokor horiez gain, ontziekin lan egiteko metodo eta teknika aurreratu osagarriak ere beharko dituzula. Horrez gain, gomendio labur batzuk ditugu, zehatzagoak direnak eta egoeraren arabera aplikatu beharrekoak (edo aplikatu gabeak):
- Saiatu irudien tamaina murrizten: ezabatu aldi baterako fitxategiak eta ez instalatu alferrikako paketeak - zenbat eta txikiagoa izan edukiontziaren tamaina, orduan eta azkarrago muntatu eta sarearen bidez helburuko ostalarira kopiatzen da.
- Erabiltzaile-ID arbitrarioetan zentratu: ez erabili sudo komandoa edo erabiltzaile-id berezirik zure edukiontziak abiarazteko.
- Markatu ataka garrantzitsuak: exekuzioan ataka-zenbakiak ezar ditzakezu, baina hobe da EXPOSE komandoa erabiliz zehaztea; beste pertsona eta programek zure irudiak erabiltzea erraztuko dute.
- Gorde datu iraunkorrak bolumenetan: edukiontzia suntsitu ondoren geratu beharko liratekeen datuak bolumenetan idatzi behar dira.
- Idatzi irudien metadatuak: etiketak, etiketak eta oharrak irudiak erabiltzeko errazago egiten dute - beste garatzaile batzuek eskertuko dizute.
- Ostalaria eta irudiak sinkronizatu: edukiontzidun aplikazio batzuek edukiontzia ostalariarekin sinkronizatzea eskatzen dute zenbait atribututan, hala nola denbora edo makinaren IDa.
- Amaitzeko, goian aipatutako printzipioak modu eraginkorragoan ezartzen lagunduko dizuten txantiloiak eta praktika onak partekatzen ditugu:
Ekainaren 11an, 11.00:XNUMXetan
Zer ikasiko duzu:
- Red Hat Enterprise Linux CoreOS aldaezina
- OpenShift zerbitzu-sarea
- Eragile-esparrua
- Knative esparrua
Iturria: www.habr.com