5 mõistlikku põhimõtet cloud-native rakenduste loomiseks

„Pilvemaandatud“ (cloud native) või lihtsalt „pilve“ rakendused luuakse spetsiaalselt toimima pilvplatvormides. Need on tavaliselt üles ehitatud nõrkade sidemetega mikroteenustest, mis on pakitud konteineritesse, mida haldab pilveplatvorm. Sellised rakendused on vaikimisi häirekindlad, mistõttu toimivad ja skaleeruvad nad usaldusväärselt ka tõsiste infrastruktuuri rikete korral. Teiselt poolt on piirangute kogum (lepingud), mida pilveplatvorm rakendustele rakendab, et suuta neid automaatrežiimis hallata.

Mõistes hästi ülemineku tähtsust ja vajalikkust pilve rakendustele, ei tea paljud organisatsioonid siiski, kust alustada. Selles postituses vaatame mitmeid põhimõtteid, mille järgimine konteinerirakenduste arendamisel võimaldab täielikult ära kasutada pilveteenuseid ning saavutada rakenduste usaldusväärne toimimine ja skaleerimine isegi tõsiste IT-infrastruktuuri tõrgete korral. Siin esitatud põhimõtete lõppeesmärk on õppida looma rakendusi, mida saavad automaatselt hallata pilveplatvormid nagu Kubernetes.

Tarkvaraarenduse põhimõtted

Programmeermise maailmas mõistetakse põhimõtete all üsna üldiseid reegleid, mida tuleb järgida tarkvara arendamisel. Neid saab rakendada igas programmeerimiskeeles. Igal põhimõttel on oma eesmärgid, mille saavutamiseks kasutatakse tavaliselt malle ja praktikaid. Samuti on rida põhieesmärke kvaliteetse tarkvara loomise põhimõtteid, millest kõik teised põhimõtted tulenevad. Toome välja mõned põhieesmärkide näited:

• KISS (Keep it simple, stupid) – mitte keeruliseks muuta;
• DRY (Don’t repeat yourself) – ära korduma;
• YAGNI (You aren’t gonna need it) – ära loo seda, mida sul hetkel ei ole vaja;
• SoC (Separation of concerns) – lahenda mured eraldi.

Nagu näha, need printsiibid ei sea mingit konkreetset reeglistikku, vaid kuuluvad “terve mõistuse” kategooriasse, mis tugineb praktilisele kogemusele ja mida jagavad paljud arendajad ning millele nad regulaarselt viitavad.
Lisaks on olemas SOLID – viis esimest objekti-orienteeritud programmeerimise ja projekteerimise printsiipi, mille sõnastas Robert Martin. SOLID hõlmab üldistatud ja tõlgendatavates vastastikku täiustavaid printsiiple, mis – kui neid kokku rakendada – aitavad luua kvaliteetsemaid tarkvarasüsteeme ja paremini neid pikaajaliselt hooldada.

SOLID põhimõtted kuuluvad OOP valdkonda ja on formuleeritud selliste mõistete ja kontseptide keeles nagu klassid, liidesed ja pärimine. Analoogiliselt on ka pilvepõhiste rakenduste jaoks võimalik sõnastada arenduse põhimõtted, kus põhielemendiks ei ole klass, vaid konteiner. Nende põhimõtete järgimine võimaldab luua konteineripõhiseid rakendusi, mis vastavad paremini pilveteenuste, nagu Kubernetes, eesmärkidele ja ülesannetele.

Pilvepõhised konteinerid: Red Hat'i lähenemine

Tänapäeval on konteineritesse suhteliselt lihtne panna praktiliselt igasuguseid rakendusi. Kuid et rakendusi oleks tõhusalt automatiseeritud ja orkestreeritud pilveplatvormil nagu Kubernetes, on vajalik teha lisapingutusi.
Allpool esitatud ideede aluseks on metodoloogia Kaksteistfaktoriline rakendus ja palju teisi töid, mis käsitlevad veebirakenduste loomise erinevaid aspekte, alates allika juhtimisest kuni skaleerimisemudelite jaotamiseni. Kirjeldatud põhimõtted kehtivad ainult konteineripõhiste rakenduste arendamiseks, mis on loodud mikroteenuste alusel ja mõeldud pilveplatvormidele, nagu Kubernetes. Meie arutluse aluseks on konteineri pilt, ning sihtkeskkonnana mõistetakse konteinerite orkestreerimise platvormi. Pakutud põhimõtete eesmärk on luua konteinerid, mille jaoks enamikul orkestreerimisplatvormidel on võimalik automatiseerida ülesannete ajastamist (scheduling – hosti valimine konteineri eksemplari käivitamiseks), skaleerimist ja jälgimist. Põhimõtted esitatakse vabakujuliselt.

Ühe mure põhimõte (Single Concern Principle, SCP)

See põhimõte on paljuski sarnane ühe vastutuse põhimõttega (Single Responsibility Principle, SRP), mis on SOLID'i osa ja ütleb, et igal objektidel peab olema üks vastutus, ja see vastutus peab olema täielikult kapseldatud klassis. SRP olemus seisneb selles, et iga vastutus on muutuste põhjus, ning klassil peab olema üks ja ainult üks muutuste põhjus.

SCP puhul kasutame sõna "vastutus" (responsibility) asemel sõna "ülesanne" (concern), et viidata kõrgemale abstraktsioonitasemele ja laiemale konteineri määratlemisele võrreldes OOP-klassi. Ja kui SRP eesmärk on omada ainult ühte muutuste põhjust, siis SCP taga on soov suurendada konteinerite uuesti kasutamise ja asendamise võimalusi. Järgides SRP-d ja luues konteineri, mis lahendab ainult ühe ülesande ja teeb seda funktsionaalselt täiendavalt, suurendate tõenäosust, et selle konteineri mudelit saab kasutada erinevates rakenduse kontekstides.

SCP põhimõte ütleb, et iga konteiner peab lahendama ühe kindla ülesande ja tegema seda hästi. SCP saavutamine konteinerite maailmas on lihtsam kui SRP OOP-is, kuna konteinerid täidavad tavaliselt ühte protsessi, mis enamiku ajast tegeleb ühe ja ainulaadse ülesandega.

Kui mingisugune konteineripõhine mikroteenus peab lahendama korraga mitmeid ülesandeid, saab selle jagada ühekordseteks konteineriteks ja koostada need ühe podi (konteineripakettide levitamiseks mõeldud üksus) alla, kasutades sidecar ja init-konteineri mudeleid. Lisaks lihtsustab SCP vana konteineri (nt veebiserveri või sõnumi vahendi) asendamist uuega, mis lahendab sama ülesande, kuid omab laiendatud funktsionaalsust või paremat skaleeritavust.

Kõrge jälgitavuse põhimõte (High Observability Principle, HOP)

Konteinerite kasutamine rakenduste standardiseeritud pakkimise ja käivitamise viisina tähendab, et rakendused ise käsitletakse kui „must kasti“. Siiski, kui need on pilve-konteinerid, peavad nad pakkuma käituskeskkonnale spetsiifilisi API-liideseid, et kontrollida konteinerite seisukorda ja vajadusel võtta vastavad meetmed. Ilma selleta ei ole võimalik standardiseerida konteinerite uuendamise automatiseerimist ja nende elutsükli haldamist, mis omakorda halvendab tarkvarasüsteemi töökindlust ja kasutusmugavust.

Praktikas peaks konteinerirakendusel olema vähemalt API erinevate staatuse kontrollide jaoks: aktiivsuse (liveness) ja valmisoleku (readiness) testide jaoks. Kui rakendus nõuab rohkem, peaks see pakkuma ka muid vahendeid oma seisundi kontrollimiseks. Näiteks oluliste sündmuste logimist STDERR ja STDOUT kaudu, et logisid koguda selliste tööriistade abil nagu Fluentd, Logstash ja teised sarnased. Samuti integreerimine jälgimise ja mõõtmiste kogumise teekidega, nagu OpenTracing, Prometheus jne.

Üldiselt võib rakendust endiselt käsitleda kui 'must kaste', kuid seda tuleb varustada kõigi API-dega, mis on vajalikud platvormile, et seda parimal viisil jälgida ja juhtida.

Elutsükli vastavuse printsiip (Life-cycle Conformance Principle, LCP)

LCP on HOP-i vastand. Kui HOP ütleb, et konteiner peab platvormile pakkuma API-liideseid lugemiseks, siis LCP nõuab rakenduselt võimet vastu võtta teavet platvormilt. Samuti peab konteiner mitte ainult sündmusi saama, vaid ka nendel reageerima. Seega on see printsiip, mida saab käsitleda nõudena pakkuda platvormile API-liideseid kirjutamiseks.

Platvormidel on erinevat liiki sündmusi, mis aitavad hallata konteineri elutsüklit. Kuid otsustada, milliseid neist tajuda ja kuidas reageerida, peab rakendus ise.

On selge, et mõned sündmused on olulisemad kui teised. Näiteks, kui rakendus ei talu ootamatut sulgemist, peab see aktsepteerima signaale signal: terminate (SIGTERM) ja käivitama oma sulgemisprotseduuri nii kiiresti kui võimalik, et jõuda signaalini signal: kill (SIGKILL), mis järgneb SIGTERM-le.

Lisaks võivad rakenduse elutsükli jaoks olla olulised sellised sündmused nagu PostStart ja PreStop. Näiteks pärast käivitamist võib rakendusel olla vaja teatud aega „üles soojendamiseks”, enne kui see suudab päringutele vastata. Või peab rakendus teatud viisil vabastama ressursid, kui see lõpetab töötamise.

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

On üldiselt arvatud, et konteinerirakendused peavad pärast kokkupanekut jääma muutmatuks, isegi kui neid käivitatakse erinevates keskkondades. Seega tuleneb vajadus andmete salvestamine käitamise ajal eksternaliseerida (teisisõnu, kasutada selleks välist vahendit) ning toetuda välistelt, konkreetse käituskeskkonna jaoks seadistatud konfiguratsioonidelt, selle asemel et modifitseerida või luua unikaalseid konteinerid igaks keskkonnaks. Pärast rakenduses tehtud muudatusi tuleb konteineri kujundus uuesti kokku panna ja rakendada kõikides kasutatavates keskkondades. Muide, IT-süsteemide haldamisel kasutatakse sarnast põhimõtet, mida tuntakse serverite ja infrastruktuuri muutumatuse printsiibina.

IIP eesmärk on vältida eraldi konteineripiltide loomist erinevate käituskeskkondade jaoks ja kasutada igal pool sama pilti koos konkreetse keskkonna jaoks sobiva konfiguratsiooniga. Selle põhimõtte järgimine võimaldab rakendada olulisi pilvesüsteemide automatiseerimise praktikaid, nagu rakenduse uuenduste tagasivõtmine (roll-back) ja edasi viimine (roll-forward).

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

Üks konteineri olulisemaid omadusi on selle efemeersus: konteineri koopia on lihtsalt loodav ja hävitatav, seega võib selle igal hetkel hõlpsasti asendada teise koopia vastu. Asendamiseks võib olla palju põhjuseid: tõrge, rakenduse skaleerimine, teisaldamine teisele serverile, ressursiotsing või muud olukorrad.

Seetõttu peavad konteinerirakendused salvestama oma oleku mingite välistest vahenditest või kasutama selleks sisemisi jaotatud skeeme koos üleliiga. Lisaks peab rakendus kiiresti käivituma ja kiiresti lõpetama ning olema valmis äkilisteks seadme riketeks.

Üks praktika, mis aitab seda põhimõtet ellu viia, on väikeste konteinerite loomine. Pilveteenused saavad automaatselt valida hosti konteineri koopia käivitamiseks, seega, mida väiksem on konteineri suurus, seda kiiremini see käivitatakse – see lihtsalt kopeeritakse kiiremini sihtserverile üle võrgu.

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

Selle põhimõtte kohaselt sisaldab konteiner koostamise etapis kõiki vajalikke komponente. Konteinerit tuleb ehitada eeldusel, et süsteemis on ainult puhas Linuxi tuum, seega peavad kõik vajalikud täiendavad teegid olema konteineris. Seal peavad olema ka sellised asjad nagu vastava programmeerimiskeele tööelu keskkond, rakenduste platvorm (vajadusel) ja muud sõltuvused, mis on vajalikud konteinerirakenduse töötamiseks.

Erandid tehakse vaid konfigureerimisele, mis varieeruvad keskkondade vahel ja tuleb esitada käitamise etapis, näiteks Kubernetes ConfigMapi kaudu.

Rakendus võib sisaldada mitmeid konteineriseeritud komponente, näiteks eraldi andmebaasi konteinerit konteineriseeritud veebirakenduse osana. S-CP põhimõtte kohaselt ei tohiks neid kokku liita, vaid peab tagama, et andmebaasi konteiner sisaldab kõike vajalikku andmebaasi tööks ja veebirakenduse konteiner – kõike vajalikku veebirakenduse töötamiseks, sealhulgas veebiserver. Seetõttu sõltub veebirakenduse konteiner andmebaasi konteinerist ja pöördub selle poole vastavalt vajadusele.

Käitusaja piirangu põhimõte (Runtime Confinement Principle, RCP)

S-CP põhimõte määrab, kuidas konteinerit koguda ja mida binäärfail pilt peaks sisaldama. Kuid konteiner ei ole lihtsalt 'must kast', millel on ainult üks omadus – failisuurus. Käitamise ajal omandab konteiner ka teisi mõõtmeid: kasutatava mälu maht, CPU aeg ja teised süsteemiressursid.

Siin tuleb appi RCP printsiip, mille kohaselt peab konteiner dekodeerima oma nõudmised süsteemiressurssidele ja edastama need platvormile. Omades iga konteineri ressursiprofiile (kui palju tal on vaja protsessorivõimet, mälu, võrgu ja salvestusruumi), saab platvorm optimaalselt teostada haldamise ja automaatse skaaleerimise, hallata IT-võimekusi ja tagada SLA tasemed konteinerite jaoks.

Lisaks konteineri ressursinõuete rahuldamisele on rakendusele samuti oluline mitte ületada enda määratud piire. Vastupidisel juhul, ressursi puudujäägi korral, on platvorm palju tõenäolisem, et lisab selle rakenduste nimekirja, mida tuleb katkestada või migreerida.

Rääkides pilve-fookusest, mõistame me eelkõige tööviisi.
Oleme ülalpool sõnastanud mitmeid üldpõhimõtteid, mis loovad metoodilise aluse kvaliteetsete konteinerirakenduste ehitamiseks pilveskeskkondades.

Oluline on märkida, et lisaks nendele üldistele põhimõtetele vajate ka täiendavaid edasijõudnud meetodeid ja tehnikate kasutamiseks konteinerite haldamisel. Samuti oleme koostanud mõned lühikesed soovitused, millel on spetsiifilisem sisu ja mida tuleb rakendada (või mitte rakendada) vastavalt olukorrale:

• Püüdke vähendada kujutiste suurust: kustutage ajutised failid ja vältige tarbetute pakettide installimist – mida väiksem on konteiner, seda kiiremini see ehitatakse ja kopeeritakse sihthostile üle võrgu.
• Seadke oma kasutajapalve juhuslikele User-ID-dele: ärge kasutage sudo käsku ega mingeid erilisi userid'e oma konteinerite käitamiseks.
• Märgistage olulised pordid: pordinumme saab määrata ka käitamise ajal, kuid parem on need määrata EXPOSE käsu abil – teistel inimestel ja programmidel on teie kujutiste kasutamine lihtsam.
• Salvestage püsivad andmed mahtudele: andmed, mis peavad jääma pärast konteineri kustutamist, tuleks salvestada mahtudele.
• Kirjutage kujutise metaandmed: sildid, märgid ja annotatsioonid lihtsustavad kujutiste kasutamist – teised arendajad on teile tänulikud.
• Sünkroniseerige host ja pildid: teatud konteinerirakenduste jaoks on vaja sünkroniseerida konteiner hostiga teatud atribuutide, näiteks aja või masina ID kaudu.
• Lõpetuseks jagame malle ja parimaid praktikaid, mis aitavad tõhusamalt rakendada eespool loetletud printsiipe:
  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

Veebiseminar uue versiooni OpenShift Container Platform – 4
11. juuni kell 11.00

Mida te õppida saate:

• Immutable Red Hat Enterprise Linux CoreOS
• OpenShift teenusevahetus
• Operator raamistik
• Knative raamistik

Allikas: habr.com