4.4.1 Tehnologija vsebnikov – Docker
Številne raziskave na področju računalništva temeljijo na rezultatih, ki so bili pridobljeni z zahtevnimi izračuni v pravilno nastavljenem izvajalnem oko-lju. Ponovljivost rezultatov je za druge raziskovalce otežena [116, 117, 118].
Orodje Docker se v tem kontekstu izkaže kot zelo uporabno, saj lahko v Docker sliki pripravimo izvajalno okolje, ki vsebuje vse potrebne knjižnice, okoljske spremenljivke, točno določene različice programske opreme in para-metre za zagon programa.
Docker je množica orodij, ki uporabljajo virtualizacijo na nivoju ope-racijskega sistema za dostavo programske opreme v obliki vsebnikov (angl.
container). Vsebniki so med seboj izolirani in lahko vsebujejo popolnoma
4.4. TEHNOLOGIJA VSEBNIKOV, NAMESTITEV IN
ORKESTRACIJA 47
Slika 4.5: Pojavno okno razširitve MetaMask, ki uporabniku omogoča po-trditev ali zavrnitev transakcije, ki bo poslana na pametno pogodbo.
različne programe, knjižnice in konfiguracijske datoteke. Med seboj lahko komunicirajo le po omejenih kanalih. Delijo si vire istega jedra operacijskega sistema, kar znatno zmanjša porabo virov v primerjavi z navideznimi stroji (angl. virtual machine). Docker ahitektura je prikazana na sliki 4.6.
Docker lahko samodejno zgradi sliko na podlagi ukazov, ki so navedeni v datoteki Dockerfile. Omogoča izvajanje ukazov, ki bi jih uporabnik lahko izvedel tudi v ukazni vrstici, le da je z uporabo te datoteke postopek
avtoma-docker build
docker pull
docker run
odjemalec strežnik register
vsebniki slike
Docker prikriti proces
Slika 4.6: Docker arhitektura z odjemalcem, strežnikom in registrom.
tiziran in poenostavljen. Z ukazom docker build lahko uporabnik ustvari sliko na podlagi ukazov v datotekiDockerfile, ki se izvedejo zaporedno in v kontekstu, ki ga podamo ob klicu. V spodnjem izseku je primerDockerfile datoteke za izgradnjo slike ASP.NET Core aplikacije.
# začni novo fazo izgradnje in nastavi osnovno sliko
# za nadaljnje ukaze
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env
# nastavi delovni imenik za ukaze RUN, CMD, ENTRYPOINT,
# COPY in ADD WORKDIR /app
# kopiraj *.csproj datoteke in poženi ukaz "dotnet restore"
COPY *.csproj ./
RUN dotnet restore
# kopiraj preostanek datotek in prevedi aplikacijo COPY ../engine/examples ./
RUN dotnet publish -c Release -o out
4.4. TEHNOLOGIJA VSEBNIKOV, NAMESTITEV IN
ORKESTRACIJA 49
# izgradi sliko z izvajalnim okoljem FROM mcr.microsoft.com/dotnet/aspnet:6.0 WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
4.4.2 Samodejna namestitev – GitHub Actions
Zvezni pristopi (integracija, dostava in postavitev) omogočajo organizaci-jam pogosto in zanesljivo izdajanje novih funkcionalnosti in produktov [119].
Prednosti zveznih pristopov so:
1. Pridobitev hitre povratne informacije od strank.
2. Bolj pogoste in zanesljive različice pripomorejo k večjemu zadovoljstvu strank in k večji kakovosti produkta.
3. Zvezna dostava okrepi povezavo med razvojno in operacijsko ekipo.
Zmanjša se število nalog, ki zahtevajo ročno delo [120].
Zvezna integracija je široko uveljavljena razvojna praksa v industriji razvoja programske opreme [121], kjer člani ekipe pogosto integrirajo in zdru-žujejo programsko kodo, običajno večkrat dnevno [122]. Zvezna integracija omogoča krajše in bolj pogoste cikle izdaj, poveča produktivnost ekip [123]
in izboljša kvaliteto programske opreme. Vključuje samodejno gradnjo in te-stiranje. Zvezna dostava zagotavlja, da je aplikacija po vsakem zagonu av-tomatiziranih testov pripravljena za namestitev v produkcijsko okolje [120].
Vključuje množico korakov, ki dostavijo novo različico v pre-produkcijsko okolje [124]. Uporaba zvezne dostave zmanjša tveganje za napake pri na-mestitvi, zmanjša stroške in pripomore k hitrejšemu povratnemu mnenju strank. Predpogoj za uvedbo zvezne dostave je zvezna integracija. Zvezna postavitev je nadgradnja že predstavljenih konceptov. Samodejno in zve-zno namesti aplikacijo v produkcijsko okolje. Od zvezne dostave se razlikuje
v okolju, kamor se aplikacija namesti. V primeru zvezne dostave se name-sti v pre-produkcijsko okolje, namename-stitev v produkcijsko okolje pa moramo sprožiti ročno. Zvezna postavitev pa avtomatizira tudi proces namestitve v produkcijsko okolje, ki ga uporabljajo stranke. Širša arhitektura zvezne inte-gracije, dostave in postavitve, vključujoč razvijalce, repozitorij izvorne kode in strežnik za zvezno integracijo, je predstavljena na sliki 4.7.
razvijalci repozitorij
izvorne kode strežnik za zvezno integracijo
gradnja
testiranje
zvezna integracija test
sprejemljivosti produkcijsko
Slika 4.7: Relacije med zvezno integracijo, dostavo in postavitvijo.
GitHub repozitorije lahko povežemo z že obstoječimi orodji za CI/CD, kot so Jenkins, Azure DevOps, CircleCI in TeamCity. Z uporabo zunanjih orodij se zavežemo še na eno odvisnost, ki jo moramo tekom razvoja pro-gramske opreme vzdrževati. GitGub Actions ponuja CI/CD platformo zno-traj GitHub ekosistema. Akcije omogočajo gradnjo in namestitev program-ske opreme kar iz GitHub repozitorija. Uporabimo lahko že razvite delovne tokove (angl. workflow) ali pa razvijemo svoje, ki so prilagojeni našemu pri-meru uporabe. Zaporedje ukazov je navedeno v YAML datoteki, ki mora biti shranjena v korenskem imeniku repozitorija v mapi.github/workflows/. V kontekstu GitHub Actions se srečamo z naslednjimi pojmi [125]:
1. Akcije. So najmanjši gradnik delovnega toka. Lahko jih združujemo in tako ustvarimo nalogo. Tržnica ponuja že veliko število obstoječih akcij, npr. priprava Node.js okolja ali namestitev na AWS EC2 strežnik.
2. Artefaktiso datoteke, ki nastanejo ob gradnji ali testiranju program-ske opreme. Običajno so to binarni paketi, ki so potrebni za delovanje
4.4. TEHNOLOGIJA VSEBNIKOV, NAMESTITEV IN
ORKESTRACIJA 51
aplikacije. Artefakte lahko ustvarimo v eni nalogi in jih uporabimo v drugih.
3. Dogodek (angl. event) sproži delovni tok. Primeri dogodkov so sprememba izvorne kode, združitev vej razvoja ali zahteva za združitev (angl. pull request).
4. Naloga (angl. job)je množica korakov, ki jih izvede en agent (navide-zni stroj). Lahko se izvajajo paralelno, nastavimo lahko tudi odvisnosti na druge naloge, s čimer zagotovimo njihovo zaporedno izvajanje.
5. Korak (angl. step) predstavlja nalogo, ki je akcija ali ukaz. Vsi koraki v nalogi se izvajajo na istem agentu.
6. Delovni tok je definiran v YAML datoteki. Vključuje navodila za gradnjo, testiranje, pakiranje in namestitev programske kode.
GitHub Actions je uporaben za zvezno nameščanje programske opreme v različna izvajalna okolja. Običajno nove funkcionalnosti razvijamo v ločeni razvoji veji, imenovani dev. Ob vsaki spremembi programske kode v tej veji se sproži GitHub Actions delovni proces, ki najnovejšo različico namesti v testno okolje, ki je večinoma nestabilna različica z znanimi pomankljivostmi ali nedokončanimi funkcionalnostmi. Ko smo zadovoljni s trenutno različico, združimo vejo dev v glavno vejo main. Tudi ob tem se požene GitHub Ac-tions, ki sproži gradnjo, testiranje in namestitev programa v produkcijsko okolje, kjer je na voljo končnim strankam.
4.4.3 Orkestracija – Kubernetes in knjižnica fabric8
Kubernetes je ogromen odprtokodni projekt, ki podpira velik nabor funkci-onalnosti s fokusom na orkestraciji vsebnikov [126]. To pomeni skrb za to, da se ustrezno zaženejo vsebniki, ki lahko opravljajo povsem neodvisne na-loge (npr. vsebnika za podatkovno bazo in analizo videotoka). Kubernetes nadzoruje življenjski cikel vseh vsebnikov in zamenja tiste, ki so ugasnjeni,
neodzivni ali na kakršen koli drug način nezdravi. Njihovo stanje pridobi s t.i. preverjanjem vitalnosti (angl. health check).
Kubernetes vključuje veliko število gradnikov. Gručaje zbirka pomnilni-ških in omrežnih virov gostiteljev, ki jih Kubernetes uporablja za izvajanje različnih delovnih procesov. Vozlišče je sinonim za enega gostitelja, ki je lahko fizični ali navidezni. Njegova naloga je, da poganja stroke (angl. pod).
Vsako vozlišče poganja številne komponente, kot stakubeletinkube proxy.
Upravlja jih nadzorno vozlišče (angl. master). So nosilci dela v celotni arhi-tekturi. Nadzorno vozliščevsebuje API strežnik in časovni razporejevalnik (angl. scheduler). Zadolženo je za globalno upravljanje s stroki in odzivanje na dogodke. Običajno so vsi nadzorni strežniki nameščeni na istem gostite-lju. Strok je enota dela v Kubernetesu. Vsak strok vsebuje enega ali več vsebnikov, ki imajo enak IP naslov in vrata. Med seboj lahko komunici-rajo preko gostitelja (angl. localhost) ali z znotraj-procesno komunikacijo.
Vsebniki znotraj stroka imajo dostop do deljenega pomnilnika na vozlišču.
Storitev (angl. service) je abstrakcija, ki izpostavi večje število replik stroka. Izpostavljajo funkcionalnost uporabnikom ali drugim storitvam. Re-plikacijski niz (angl. replica set) in replikacijski nadzornik (angl.
replication controller)zagotavljata, da v nekem času teče zahtevano šte-vilo replik stroka. Shematska predstavitev Kubernetesovih komponent je predstavljena na sliki 4.8.
Za upravljanje s Kubernetesom obstajajo številne knjižnice za popularne programske jezike. Za programski jezik Java se največ uporabljata uradna, ki jo razvija in vzdržuje Kubernetes organizacija in odprtokodna fabric8, ki jo razvija uporabniška skupnost, vendar je trenutno že v fazi opuščanja. Ku-bernetes ponuja REST API, ki omogoča upravljanje s stroki, storitvami in drugimi Kubernetesovimi entitetami. Knjižnice razvijalcem poenostavljajo in abstrahirajo dostop do končnih točk, poleg tega pa ponujajo bogat do-mensko specifičen jezik (angl. Domain Specific Language, DSL), možnost testiranja z navideznim strežnikom in mnoge pomožne funkcije. Knjižnica fabric8 je na voljo kot Maven vtičnik. Spodnji izsek kode v levem stolpcu
4.4. TEHNOLOGIJA VSEBNIKOV, NAMESTITEV IN
Slika 4.8: Shematska predstavitev odjemalca, porazdeljevalca obremenitve, storitev, vsebnikov, strokov in replikacijskih nizov v kontekstu Kubernetesa.
predstavlja Java kodo, ki uporablja fabric8 knjižnico, da definira Kubernete-sovo namestitev z oznakami (angl. label), številom replik, ukazi za vsebnik in osnovno Docker sliko. Na desni strani je prikazana ekvivalentna YAML datoteka, ki jo knjižnica ustvari v ozadju in jo posreduje Kubernetesu.
new DeploymentBuilder()
.withNewSpec() .addNewContainer()
.withName("busybox") .withImage("busybox")
.withCommand("sleep","36000") .endContainer()
.endSpec() .endTemplate() .withNewSelector()
.addToMatchLabels("app","httpd") .endSelector()
.endSpec() .build();
template:
metadata:
labels:
app: httpd spec:
containers:
– command:
– sleep – ’36000’
image: busybox name: busybox
Poglavje 5
Arhitektura rešitve
Implementiran sistem uporablja veliko število komponent, ki se morajo med seboj integrirati v smiselno celoto. Za delovanje sistema in optimalno uporab-niško izkušnjo je potrebno njihovo usklajeno delovanje. Vsaka od komponent opravlja določeno nalogo. V tem poglavju natančno predstavimo podrobnosti vsake od njih in njihovo vlogo v celotnem sistemu.