🥇5 mõistlikku põhimõtet pilvepõhiste rakenduste loomiseks

„Pilvepõhised“ (cloud native) või lihtsalt „pilve“ rakendused on loodud spetsiaalselt töötamiseks pilveinfrastruktuurides. Need ehitatakse tavaliselt kui nõrkade seostega mikroteenuste kogumid, mis on pakitud konteineritesse, mida omakorda haldab pilveplatvorm. Sellised rakendused on eeldusena valmis ebaõnnestumisteks, mis tähendab, et nad töötavad ja skaleeruvad usaldusväärselt isegi tõsiste infrastruktuuri taseme rike korral. Tagaküljeks on piirangute kogum (lepingud), mida pilveplatvorm kehtestab konteinerirakendustele, et neid automaatselt hallata.

Teades väga hästi pilverakenduste ülemineku vajadust ja tähtsust, on paljud organisatsioonid endiselt teadmatuses, kust alustada. Selles postituses vaatleme mitmeid põhimõtteid, mille järgimine konteinerirakenduste arendamisel võimaldab maksimeerida pilveplatvormide potentsiaali ning saavutada rakenduste usaldusväärne töö ja skaleerimine isegi tõsiste IT-infrastruktuuri taseme rikke korral. Siin esitatud põhimõtete lõppeesmärk on õppida looma rakendusi, mida pilveplatvormid, nagu Kubernetes, saavad automaatselt hallata.

Tarkvaraarenduse projekteerimise põhimõtted

Programmeerimise maailmas mõistetakse põhimõtete all üsna üldiseid reegleid, mida tuleb järgida tarkvara arendamisel. Neid saab rakendada igasuguste programmeerimiskeelte töös. Igal põhimõttel on oma eesmärgid, mille saavutamise vahenditena toimivad tavaliselt malli- ja praktikad. Samuti on olemas rida alusmõtteid kvaliteetse tarkvara loomisel, millest tulenevad kõik teised. Toome välja mõned alusreeglid:

KISS (Keep it simple, stupid) – mitte keeruliseks muuta;
DRY (Don’t repeat yourself) – mitte korduda;
YAGNI (You aren’t gonna need it) – mitte luua seda, mille järele ei ole vahetut vajadust;
SoC (Separation of concerns) – jagada vastutusi.

Nagu näha, ei sea need põhimõtted mingeid konkreetseid reegleid, vaid kuuluvad nn tervet mõistust silmas pidavate kaalutluste klassi, mida jagavad paljud arendajad ning millele nad regulaarselt viitavad.
Lisaks on olemas SOLID – komplekt esimestest viiest objekti-orienteeritud programmeerimise ja disaini põhiprintsiibist, mis on formuleeritud Robert Martin'i poolt. SOLID hõlmab üldisi ja avatud tõlgendusele vastavaid vastastikku toetavaid põhimõtteid, mis – kui neid rakendada koos – aitavad luua kvaliteetsemaid tarkvarasüsteeme ja paremini neid pikaajaliselt hooldada.

SOLID printsiibid kuuluvad OOP valdkonda ja on formuleeritud selliste mõistete ja kontseptsioonide keeles nagu klassid, liidesed ja pärimine. Samamoodi saab pilvepõhiste rakenduste jaoks formuleerida arendusprintsiibid, kusjuures baasüksuseks pole klass, vaid konteiner. Nende põhimõtete järgimine võimaldab luua konteinerirakendusi, mis vastavad paremini pilveplatvormide nagu Kubernetes eesmärkidele ja ülesannetele.

Pilvepõhised konteinerid: Red Hati lähenemine

Tänapäeval on konteineritesse suhteliselt lihtne pakendada praktiliselt iga rakendus. Kuid rakenduste tõhusaks automatiseerimiseks ja orkestreerimiseks selliste pilveplatvormide nagu Kubernetes raames on vajalik täiendav pingutus.
Allpool esitatud ideede aluseks on metodoloogia The Twelve-Factor App ja paljud muud tööd erinevate veebiäride loomise aspektide kohta, alates lähtekoodi haldusest kuni skaleerimismudeliteni. Kirjeldatud põhimõtted kehtivad ainult konteinerirakenduste arendamise kohta, mis on ehitatud mikroteenuste alusel ja mõeldud pilveplatvormidele nagu Kubernetes. Meie arutluste baasüksuseks on konteineri pilt, ja konteinerite sihtkeskkonnana mõistetakse konteinerite orkestreerimisplatvormi. Pakutud põhimõtete eesmärk on luua konteinerid, mille puhul enamikus orkestreerimisplatvormides on võimalik automatiseerida sõidukite jaotamist (scheduling – hosti valimine konteineriexemplari käivitamiseks), skaleerimist ja jälgimist. Põhimõtted esitatakse suvalises järjekorras.

Ühe vastutuse printsiip (Single Concern Principle, SCP)

See printsiip on paljuski sarnane ühe vastutuse printsiibiga (Single Responsibility Principle, SRP), mis on SOLIDi osa ja ütleb, et igal objektil peaks olema üks vastutus, mis peab olema täielikult kapseldatud klassis. SRP olemus seisneb selles, et iga vastutus on muutuste põhjus ja klassil peaks olema vaid üks muudetav põhjus.

SCP puhul kasutame sõna „mure” (concern) juhtumite tähistamiseks, et viidata kõrgemale abstraktsiooni tasemele ja laiemale container'ite määratlemisele võrreldes OOP-kliendiga. Ja kui SRP eesmärk on omada vaid ühte muutuste põhjust, siis SCP taga on soov suurendada container'ite taaskasutusvõimet ja asendatavust. Järgides SRP-d ja luues container'i, mis lahendab ühe ja ainukese ülesande ning teeb seda funktsionaalselt lõpeva viisina, suurendate võimalusi selle container'i kujutise taaskasutamiseks erinevates rakenduse kontekstides.

SCP printsiip ütleb, et iga container peab lahendama ainult ühe ülesande ja tegema seda hästi. SCP container'ite maailmas saavutatakse kergemini kui SRP OOP maailmas, kuna container'id täidavad tavaliselt ühte protsessi ja suure osa ajast lahendab see ühe ja ainukese ülesande.

Kui mõni container mikroteenus peab lahendama korraga mitu ülesannet, siis saab selle jagada ühekordseteks container'iteks ja kokku liita ühe pod'i (container platvormi juurutamise üksus) raames sidecar'i ja init-container'ite mallide abil. Lisaks lihtsustab SCP vanade container'ite (nt veebiserveri või sõnumite vahetaja) asendamist uuega, mis lahendab sama ülesande, kuid omab laiemat funktsionaalsust või paremat skaleeritavust.

Kõrge jälgitavuse printsiip (High Observability Principle, HOP)

Konteinerite kasutamisel kui ühtsete rakenduste pakendamise ja käivitamise viiside puhul käsitletakse rakendusi endid kui "mustade kaste". Siiski, kui need on pilvepõhised konteinerid, peavad nad pakkuma käitamise keskkonnale erilise API, et kontrollida konteinerite töökindlust ja vajadusel võtta vastavaid meetmeid. Ilma selleta pole võimalik automatiseerida konteinerite uuendamist ja nende elutsükli haldamist, mis omakorda halvendab tarkvarasüsteemi usaldusväärsust ja kasutusmugavust.

Praktikas peaks konteinerirakendus vähemalt omama API-d erinevate töökindluse kontrollide jaoks: aktiivsuse testid (liveness) ja valmisoleku testid (readiness). Kui rakendus väidab end olevat rohkem, peaks see pakkuma ka teisi vahendeid oma oleku kontrollimiseks. Näiteks oluliste sündmuste logimise kaudu STDERR ja STDOUT, et koguda logisid nagu Fluentd, Logstash ja teised sarnased tööriistad. Samuti tuleks integreerida jälgimis- ja mõõtmisraamatukogud, nagu OpenTracing, Prometheus jne.

Üldiselt võib rakendust endiselt käsitleda kui "must kaste", kuid samas tuleb seda varustada kõikide API-dega, mis on vajalikud platvormi jaoks, et jälgida ja hallata seda parimal võimalikult viisil.

Elutsükli kohandamise põhimõte (Life-cycle Conformance Principle, LCP)

LCP on HOPi vastand. Kui HOP ütleb, et konteiner peab pakkuma platvormile API-d lugemiseks, siis LCP nõuab rakendustelt võimet vastu võtta teavet platvormilt. Samuti peab konteiner mitte ainult saama sündmusi, vaid ka neile kohanduma, ehk reageerima. Seetõttu on selle põhimõtte nimetus, mida võib pidada nõudmiseks, et platvormile tuleks pakkuda API-d kirjutamiseks.

Platvormidel on erinevat tüüpi sündmused, mis aitavad konteineri elutsüklit hallata. Kuid see, milliseid neist vastu võtta ja kuidas reageerida, peaks otsustama rakendus ise.

On selge, et mõned sündmused on olulisemad kui teised. Näiteks, kui rakendus talub halvasti ootamatut sulgemist, peab see vastu võtma signaale signal: terminate (SIGTERM) ja võimalikult kiiresti algatama sulgemisprotseduuri, et jõuda enne signaali signal: kill (SIGKILL), mis tuleb pärast SIGTERM-i.

Lisaks võivad rakenduse elutsükli jaoks olla olulised sellised sündmused nagu PostStart ja PreStop. Näiteks võib rakendusel pärast käivitamist olla vajalik teatud aeg 'soojendamiseks', enne kui see suudab vastata päringutele. Või peab rakendus erilisel viisil vabastama ressursse, kui see lõpetab töö.

Konteineripildi muutumatuse põhimõte (Image Immutability Principle, IIP)

Üldiselt arvatakse, et konteenirakendused peavad pärast ehitamist jääma muutumatuks, isegi kui need käivitatakse erinevates keskkondades. Seetõttu tuleneb vajadus eksterneerida andmete salvestamine toimimise etapis (teisisõnu, kasutada selleks väliseid vahendeid) ja toetuda välistele, konkreetse täitmisreegliga kohandatud seadistustele, selle asemel et modifitseerida või luua ainulaadseid konteinereid iga keskkonna jaoks. Pärast rakenduses tehtud muudatusi tuleb konteineripilt uuesti 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 ära hoida eraldi konteineripiltide loomist erinevate täitmisreeglite jaoks ja kasutada ühesugust pilti koos vastava seadistusega konkreetsele keskkonnale. Selle põhimõtte järgimine võimaldab rakendada selliseid olulisi automaatika praktikaid pilvesüsteemide jaoks nagu rakenduse uuenduste tagasivõtmine (roll-back) ja edasi veeretamine (roll-forward).

Protsesside ühekordsuse põhimõte (Process Disposability Principle, PDP)

Üks konteineri olulisemaid omadusi on selle efemeersus: konteineri eksemplari loomine on lihtne ja sama lihtne on see hävitada, seega saab selle igal ajal lihtsalt asendada teise eksemplariga. Selliseks asendamiseks võib olla palju põhjuseid: edukuse testi läbikukkumine, rakenduse skaleerimine, üle viimine teisele hostile, platvormi ressursside ammendumine või muud olukorrad.

Seetõttu peavad konteinerirakendused oma olekut säilitama mingi välise vahendi kaudu või kasutama selleks sisemisi jaotatud skeeme koos varundamisega. Lisaks peab rakendus kiiresti käivituma ja kiiresti lõpetama ning olema valmis ootamatuks kriitiliseks riistvara tõrkeks.

Üks praktika, mis aitab seda põhimõtet rakendada, on luua väikese suurusega konteinerid. Pilvemahud saavad automaatselt valida hosti, et käivitada konteinerimudelit, seega mida väiksem on konteineri suurus, seda kiiremini see käivitub – see kopeeritakse lihtsalt kiiremini sihthostile võrgu kaudu.

Iseseisvuse põhimõte (Self-containment Principle, S-CP)

Selle põhimõtte kohaselt sisaldab konteiner oma ehitusetapis kõiki vajalikke komponente. Konteinerit tuleb ehitada eeldusel, et süsteemis on vaid puhas Linuxi kerneli, seega kõik vajalikud lisaraamatukogud tuleb paigutada konteinerisse. Seal peaksid olema ka sellised asjad nagu vastava programmeerimiskeele töötlemisvõime, rakenduste platvorm (vajadusel) ja muud sõltuvused, mis on vajalikud konteinerirakenduse tööks.

Erandid tehakse vaid konfiguratsioonide jaoks, mis varieeruvad keskkonnast keskkonda ja peavad olema esitatud jooksvalt, näiteks läbi Kubernetes ConfigMap.

Rakendus võib sisaldada mitmeid konteineriseeritud komponente, näiteks eraldi andmebaasi konteiner konteineritest koosneva veebi rakenduse sees. Vastavalt S-CP põhimõttele ei tohi neid konteinerid kokku liita, vaid tuleb teha nii, et andmebaasi konteiner sisaldab kõike vajalikku andmebaasi tööks ning veebi rakenduse konteiner – kõike vajalikku veebi rakenduse tööks, sealhulgas veebiserverit. Selle tulemusena sõltub veebi rakenduse konteiner jooksvalt andmebaasi konteinerist ja pöördub selle poole vajadusel.

Jooksuaegne piirangupõhimõte (Runtime Confinement Principle, RCP)

S-CP põhimõte määratleb, kuidas konteiner peab olema kokku pandud ja mida peab sisaldama binaarfaili pilt. Kuid konteiner ei ole lihtsalt "must kast", millel on ainult üks omadus – faili suurus. Käitamise ajal omandab konteiner ka teisi mõõtmeid: kasutatava mälu maht, protsessori aeg ja muud süsteemiressursid.

Siin tuleb mängu RCP põhimõte, mille kohaselt peab konteiner dekapeerima oma nõudmised süsteemiressursside osas ja edastama need platvormile. Kui igal konteineril on ressursi profiil (kui palju tal on vaja CPU, mälu, võrgu ja salvestussüsteemi ressursse), saab platvorm optimaalselt teostada haldamist ja automaatset skaleerimist, juhtida IT-jõudlust ja toetada SLA tasemeid konteineritele.

Lisaks konteineri ressursinõuete rahuldamisele on rakendusele oluline mitte ületada enda määratud piire. Vastasel juhul, kui ressursse on puudus, on platvormil suurem tõenäosus lisada see rakenduste nimekirja, mida tuleb katkestada või migreerida.

Rääkides pilvenakkuslikust fookusest, mõtleme me kõigepealt töötamise viisi.
Ülalpool oleme töötanud välja mitmeid üldpõhimõtteid, mis määratlevad metodoloogilise aluse kvaliteetsete konteinerite rakenduste loomiseks pilvekeskkondades.

Mainime, et lisaks neile üldpõhimõtetele on teil ka vaja täiendavaid arenenud meetodeid ja tehnikaid konteineritega töötamiseks. Samuti on meil mõned lühikesed soovitused, mis on spetsiifilisemat laadi ja mida tuleb rakendada (või mitte rakendada) olukorrast sõltuvalt:

Püüdke vähendada piltide suurust: kustutage ajutised failid ja ärge installige liigseid pakette – mida väiksem on konteiner, seda kiiremini see koostatakse ja edastatakse sihthostile võrgu kaudu.
Järgige juhuslikke User-ID’sid: ärge kasutage käsku sudo ega mingit erilist userid oma konteinerite käitamiseks.
Märgistage olulised pordid: portaide numbreid saab määrata ka töötamise ajal, kuid parem on need määrata EXPOSE käsu abil – teistel inimestel ja programmide jaoks on lihtsam kasutada teie pilte.
Salvestage püsivaid andmeid mahutites: andmed, mis peavad pärast konteineri hävitamist alles jääma, tuleb salvestada mahutitesse.
Täitke pildi metaandmed: sildid, märgid ja annotatsioonid lihtsustavad piltide kasutamist – teised arendajad aitavad teid tänada.
Sünkroonige host ja pildid: mõned konteinerirakendused vajavad konteineri sünkroonimist hostiga teatud atribuutide, näiteks aja või masina ID järgi.
Kokkuvõtteks jagame malle ja parimaid praktikaid, mis aitavad tõhusamalt rakendada eespool mainitud põhimõtteid:
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