Pilvepõhised või lihtsalt pilverakendused on loodud spetsiaalselt pilveinfrastruktuurides töötamiseks. Tavaliselt on need üles ehitatud konteineritesse pakendatud lõdvalt seotud mikroteenuste komplektina, mida omakorda haldab pilveplatvorm. Sellised rakendused on vaikimisi ette valmistatud riketeks, mis tähendab, et need töötavad usaldusväärselt ja mastaapsevad isegi tõsiste infrastruktuuritaseme rikete korral. Mündi teine pool on piirangute (lepingute) komplektid, mida pilveplatvorm konteinerrakendustele seab, et neid automaatselt hallata.
Kuigi paljud organisatsioonid on täiesti teadlikud pilvepõhistele rakendustele ülemineku vajadusest ja tähtsusest, ei tea paljud organisatsioonid ikka veel, kust alustada. Selles postituses vaatleme mitmeid põhimõtteid, mille järgimine konteinerrakenduste arendamisel võimaldab realiseerida pilveplatvormide potentsiaali ning saavutada rakenduste töökindel toimimine ja skaleerimine ka IT infrastruktuuri tõsiste rikete korral. tasemel. Siin kirjeldatud põhimõtete lõppeesmärk on õppida, kuidas luua rakendusi, mida saavad automaatselt hallata pilveplatvormid, nagu Kubernetes.
Tarkvara kujundamise põhimõtted
Programmeerimismaailmas viitavad põhimõtted üsna üldistele reeglitele, mida tuleb tarkvara arendamisel järgida. Neid saab kasutada mis tahes programmeerimiskeelega töötamisel. Igal põhimõttel on oma eesmärgid, mille saavutamiseks on tavaliselt mallid ja tavad. Kvaliteetse tarkvara loomisel on ka mitmeid aluspõhimõtteid, millest kõik muu lähtub. Siin on mõned näited aluspõhimõtetest:
- (Keep it simple, stupid) – ära tee seda keeruliseks;
- (Ära korda ennast) – ära korda ennast;
- (Te ei hakka seda vajama) - ärge looge midagi, mida pole kohe vaja;
- Murede lahusus – jagage vastutust.
Nagu näha, ei sea need põhimõtted mingeid konkreetseid reegleid, vaid kuuluvad praktilisel kogemusel põhinevate nn terve mõistuse kaalutluste kategooriasse, mida jagavad paljud arendajad ja millele nad regulaarselt viitavad.
Lisaks on – Robert Martini sõnastatud objektorienteeritud programmeerimise ja disaini esimese viie põhimõtte kogum. SOLID sisaldab laiaulatuslikke, üksteist täiendavaid põhimõtteid, mis koos rakendades aitavad luua paremaid tarkvarasüsteeme ja neid pikemas perspektiivis paremini hooldada.
SOLID-põhimõtted kuuluvad OOP valdkonda ja on sõnastatud selliste mõistete ja mõistete keeles nagu klassid, liidesed ja pärimine. Analoogiliselt saab arenduspõhimõtteid sõnastada ka pilverakenduste jaoks, ainult et põhielemendiks ei saa siin olema klass, vaid konteiner. Neid põhimõtteid järgides saate luua konteinerrakendusi, mis vastavad paremini pilveplatvormide, nagu Kubernetes, eesmärkidele ja eesmärkidele.
Pilvepõhised konteinerid: Red Hati lähenemisviis
Tänapäeval saab peaaegu iga rakenduse suhteliselt lihtsalt konteineritesse pakkida. Kuid rakenduste tõhusaks automatiseerimiseks ja korraldamiseks pilvplatvormil, nagu Kubernetes, on vaja täiendavaid jõupingutusi.
Allpool välja toodud ideede aluseks oli metoodika ja palju muid töid veebirakenduste loomise erinevate aspektide kohta, alates lähtekoodi haldamisest kuni skaleerimismudeliteni. Kirjeldatud põhimõtted kehtivad ainult selliste konteinerrakenduste arendamisel, mis on üles ehitatud mikroteenustele ja mõeldud pilveplatvormidele nagu Kubernetes. Meie arutelu põhielement on konteineri kujutis ja sihtkonteineri käitusaeg on konteineri orkestreerimisplatvorm. Pakutud põhimõtete eesmärk on luua konteinereid, mille ajakava, skaleerimise ja jälgimise ülesandeid saab enamikul orkestreerimisplatvormidel automatiseerida. Põhimõtted ei ole esitatud kindlas järjekorras.
Ühe mure põhimõte (SCP)
See põhimõte sarnaneb paljuski ühtse vastutuse põhimõttega. ), mis on osa SOLID-komplektist ja ütleb, et igal objektil peab olema üks vastutus ja see vastutus peab olema täielikult kapseldatud klassi. SRP mõte on selles, et iga vastutus on muutuste põhjus ja klassil peab olema muutusteks üks ja ainult üks põhjus.
SCP-s kasutame sõna "vastutus" asemel sõna "mure", et näidata konteineri kõrgemat abstraktsioonitaset ja laiemat eesmärki võrreldes OOP-klassiga. Ja kui SRP eesmärk on muuta vaid üks põhjus, siis SCP taga on soov laiendada konteinerite taaskasutamise ja väljavahetamise võimalusi. Järgides SRP-d ja luues konteineri, mis lahendab ühe probleemi ja teeb seda funktsionaalselt terviklikult, suurendate selle konteineri kujutise taaskasutamise võimalusi erinevates rakenduste kontekstides.
SCP põhimõte ütleb, et iga konteiner peaks lahendama ühe probleemi ja tegema seda hästi. Lisaks on konteinerimaailmas SCP-d lihtsam saavutada kui OOP-maailma SRP-d, kuna konteinerid käitavad tavaliselt ühte protsessi ja enamasti lahendab see protsess üheainsa ülesande.
Kui konteineri mikroteenus peab lahendama mitu probleemi korraga, saab selle külgkorvi ja algkonteineri mallide abil jagada ühe ülesandega konteineriteks ja kombineerida ühte kambrisse (konteineri platvormi juurutamise ühik). Lisaks teeb SCP lihtsaks vana konteineri (näiteks veebiserveri või sõnumimaakleri) asendamise uuega, mis lahendab sama probleemi, kuid millel on laienenud funktsionaalsus või paremini skaleeruv.
Kõrge jälgitavuse põhimõte (HOP)
Kui konteinereid kasutatakse rakenduste pakendamiseks ja käitamiseks ühtse viisina, käsitletakse rakendusi endid musta kastina. Kui tegemist on aga pilvekonteineritega, peavad need pakkuma käitusajale spetsiaalseid API-sid, et jälgida konteinerite seisukorda ja vajadusel võtta kasutusele vastavad toimingud. Ilma selleta ei ole võimalik ühtlustada konteinerite uuendamise ja nende elutsükli haldamise automatiseerimist, mis omakorda halvendab tarkvarasüsteemi stabiilsust ja kasutatavust.
Praktikas peaks konteinerrakendusel olema vähemalt API eri tüüpi tervisekontrollide jaoks: elujõulisuse testid ja valmisoleku testid. Kui rakendus väidab, et teeb rohkem, peab see pakkuma muid vahendeid oma oleku jälgimiseks. Näiteks oluliste sündmuste logimine STDERR-i ja STDOUT-i kaudu logide koondamiseks, kasutades Fluentd, Logstash ja muid sarnaseid tööriistu. Nagu ka integreerimine jälgimis- ja mõõdikute kogumitega, nagu OpenTracing, Prometheus jne.
Üldjuhul võib rakendust siiski käsitleda kui musta kasti, kuid see peab olema varustatud kõigi API-dega, mida platvorm vajab, et seda parimal võimalikul viisil jälgida ja hallata.
Olelusringi vastavuse põhimõte (LCP)
LCP on HOP-i antitees. Kui HOP väidab, et konteiner peab platvormile avaldama lugemise API-sid, siis LCP nõuab, et rakendus oleks võimeline platvormilt teavet vastu võtma. Pealegi ei pea konteiner mitte ainult sündmusi vastu võtma, vaid ka kohanema ehk teisisõnu neile reageerima. Sellest tuleneb ka põhimõtte nimi, mida võib pidada nõudeks varustada platvormi kirjutamisliidestega.
Platvormidel on erinevat tüüpi sündmusi, mis aitavad konteineri elutsüklit hallata. Kuid rakendus ise otsustab, millist neist tajuda ja kuidas reageerida.
On selge, et mõned sündmused on tähtsamad kui teised. Näiteks kui rakendus ei talu krahhe hästi, peab see vastu võtma signaali: terminate (SIGTERM) sõnumid ja algatama võimalikult kiiresti oma lõpetamisrutiini, et tabada signaal: kill (SIGKILL), mis tuleb pärast SIGTERM.
Lisaks võivad sellised sündmused nagu PostStart ja PreStop olla rakenduse elutsükli jaoks olulised. Näiteks võib pärast rakenduse käivitamist kuluda veidi soojenemisaega, enne kui see saab päringutele vastata. Või peab rakendus sulgemisel ressursse mingil erilisel viisil vabastama.
Kujutise muutumatuse põhimõte (IIP)
On üldtunnustatud, et konteinerrakendused peaksid pärast ehitamist muutumatuks jääma, isegi kui neid käitatakse erinevates keskkondades. See tingib vajaduse andmesalvestust käitusajal välistada (teisisõnu kasutada selleks väliseid tööriistu) ja tugineda välistele, käitusaja spetsiifilistele konfiguratsioonidele, selle asemel, et muuta või luua iga keskkonna jaoks ainulaadseid konteinereid. Pärast mis tahes muudatusi rakenduses tuleb konteineri kujutis uuesti üles ehitada ja juurutada kõigis kasutatavates keskkondades. Muide, IT-süsteemide haldamisel kasutatakse sarnast põhimõtet, mida tuntakse serverite ja infrastruktuuri muutumatuse põhimõttena.
IIP eesmärk on takistada erinevate käituskeskkondade jaoks eraldi konteinerpiltide loomist ja kasutada kõikjal sama pilti koos sobiva keskkonnaspetsiifilise konfiguratsiooniga. Selle põhimõtte järgimine võimaldab rakendada selliseid pilvesüsteemide automatiseerimise seisukohalt olulisi praktikaid nagu rakenduste uuenduste tagasi- ja edasikerimine.
Protsessi ühekordse kasutuse põhimõte (PDP)
Konteineri üks olulisemaid omadusi on selle lühiajalisus: konteineri eksemplari on lihtne luua ja seda on lihtne hävitada, seega saab selle igal ajal hõlpsasti teise eksemplariga asendada. Sellise asendamise põhjuseid võib olla palju: töövõime testi ebaõnnestumine, rakenduse skaleerimine, teisele hostile ülekandmine, platvormi ressursside ammendumine või muud olukorrad.
Sellest tulenevalt peavad konteinerrakendused säilitama oma oleku mõne välise vahendi abil või kasutama selleks sisemisi hajutatud skeeme koos liiasusega. Lisaks peab rakendus kiiresti käivituma ja kiiresti välja lülituma ning olema valmis ootamatuks saatuslikuks riistvararikkeks.
Üks praktika, mis aitab seda põhimõtet rakendada, on hoida konteinerid väikestena. Pilvekeskkonnad saavad automaatselt valida hosti, millel konteineri eksemplar käivitada, nii et mida väiksem on konteiner, seda kiiremini see käivitub – see lihtsalt kopeerib kiiremini sihthostisse üle võrgu.
Iseseisvuse põhimõte (S-CP)
Selle põhimõtte kohaselt on monteerimisetapis kõik vajalikud komponendid konteineris. Konteiner tuleks üles ehitada eeldusel, et süsteemil on ainult puhas Linuxi kernel, seega tuleks kõik vajalikud lisateegid paigutada konteinerisse endasse. See peaks sisaldama ka selliseid asju nagu vastava programmeerimiskeele käitusaeg, rakenduse platvorm (vajadusel) ja muud sõltuvused, mida konteinerrakenduse töötamise ajal nõutakse.
Erandiks on konfiguratsioonid, mis erinevad keskkonnati ja need tuleb esitada käitusajal, näiteks Kubernetes ConfigMapi kaudu.
Rakendus võib sisaldada mitut konteineris olevat komponenti, näiteks eraldi DBMS-i konteinerit konteineriseeritud veebirakenduses. Vastavalt S-CP põhimõttele ei tohiks neid konteinereid ühendada üheks, vaid teha nii, et DBMS-i konteiner sisaldab kõike andmebaasi tööks vajalikku ja veebirakenduste konteiner sisaldab kõike veebi toimimiseks vajalikku. rakendus, sama veebiserver . Selle tulemusena sõltub veebirakenduse konteiner käitusajal DBMS-i konteinerist ja pääseb sellele vastavalt vajadusele juurde.
Käitusaja piiramise põhimõte (RCP)
S-CP põhimõte määratleb, kuidas konteiner peaks olema üles ehitatud ja mida peaks pildibinaar sisaldama. Kuid konteiner pole lihtsalt "must kast", millel on ainult üks omadus - faili suurus. Täitmise ajal omandab konteiner teised mõõtmed: kasutatud mälumaht, protsessori aeg ja muud süsteemiressursid.
Ja siin tuleb appi RCP põhimõte, mille kohaselt peab konteiner oma nõuded süsteemiressurssidele dekapiteerima ja need platvormile üle kandma. Iga konteineri ressursiprofiilidega (kui palju protsessori-, mälu-, võrgu- ja kettaressursse see vajab) saab platvorm optimaalselt teostada ajastamist ja automaatset skaleerimist, hallata IT-võimsust ja säilitada konteinerite SLA tasemeid.
Lisaks konteineri ressursinõuete täitmisele on oluline ka see, et rakendus ei väljuks oma piiridest. Vastasel juhul lisab platvorm ressursipuuduse ilmnemisel selle tõenäoliselt lõpetamist või üleviimist vajavate rakenduste loendisse.
Kui me räägime sellest, et me oleme pilves, siis räägime sellest, kuidas me töötame.
Eespool sõnastasime mitmeid üldpõhimõtteid, mis panevad metoodilise aluse kvaliteetsete konteinerrakenduste ehitamiseks pilvekeskkondadesse.
Pange tähele, et lisaks nendele üldpõhimõtetele vajate konteineritega töötamiseks ka täiendavaid täiustatud meetodeid ja tehnikaid. Lisaks on meil mõned lühikesed soovitused, mis on täpsemad ja mida tuleks sõltuvalt olukorrast rakendada (või mitte rakendada):
- Proovige piltide suurust vähendada: kustutage ajutised failid ja ärge installige tarbetuid pakette – mida väiksem on konteineri suurus, seda kiiremini see kokku pannakse ja võrgu kaudu sihthostile kopeeritakse.
- Keskenduge suvalistele kasutaja-ID-dele: ärge kasutage konteinerite käivitamiseks käsku sudo ega ühtegi spetsiaalset kasutajatunnust.
- Märkige olulised pordid: saate pordinumbreid määrata käitusajal, kuid parem on need määrata käsuga EXPOSE – see muudab teie piltide kasutamise teistel inimestel ja programmidel lihtsamaks.
- Salvestage püsivaid andmeid köidete kohta: andmed, mis peaksid alles jääma pärast konteineri hävitamist, tuleks kirjutada köidetesse.
- Kirjutage pildi metaandmeid: sildid, sildid ja märkused muudavad piltide kasutamise lihtsamaks – teised arendajad tänavad teid.
- Hosti ja kujutiste sünkroonimine: mõned konteinerrakendused nõuavad, et konteiner sünkrooniks hostiga teatud atribuutide (nt aja või masina ID) alusel.
- Kokkuvõtteks jagame malle ja parimaid tavasid, mis aitavad teil ülaltoodud põhimõtteid tõhusamalt rakendada:
11. juunil kell 11.00
Mida sa õpid:
- Muutumatu Red Hat Enterprise Linux CoreOS
- OpenShifti teenindusvõrk
- Operaatorraamistik
- Knatiivne raamistik
Allikas: www.habr.com