Kontejneri (ne oni koji stoje po ulici) deluju kao proprilično jednostavan koncept, pa se verovatno pitate zašto je potrebno da čitate o samoj terminologiji?
Bez njih, mnogobrojne važne svakodnevne operacije ne bi bile moguće u Mintu. Oni nam pomažu da pružimo različite tipove usluga, nadgledamo infrastrukturu, tesitramo nove tehnologije, definišemo razvojna okruženja i izvodimo niz drugih aktivnosti svakoga dana.
Međutim, često i oni koji koriste kontejnere na svakodnevnoj bazi brkaju pojmove koji se za njih vezuju, unoseći nepotrebnu konfuziju. Termini poput kontejnera i slika se obično koriste zajedno iako postoje ozbiljne konceptualne razlike. Repozitorijum (repository) ima kompletno drugačije značenje od tradicionalnog značenja kada se govori iz ugla nekog menadžera paketa poput apt ili yum.
Iskoristite ekskluzivni promokod BLOG10 za 10% popusta na sve Web Hosting pakete, posebno kreiran za naše čitaoce. Upišite promokod BLOG10 na checkout stranici i ne propustite priliku da unapredite svoj online prostor uz pouzdan i siguran hosting!
Malo pozadine
Startovati sa korišćenjem Linux kontejnera je besmisleno jednostavno. Sve što vam je potrebno je par minuta da instalirate neki kontejner endžin poput Docker-a i par dodatnih komandi. Nakon par minuta ćete već biti u procesu pravljenja svoje prve slike kontejnera (container image), a zatim slede već poznati procesi planiranja i razvoja okruženja koje je ekvivalentno onom na produkciji – ceo taj proces deluje toliko prosto i jednostavno da većina nema potrebu da se udubi u terminologiju kako bi bolje razumela tehnologiju i šta se dešava iza zavese.
Poznavanje terminologije će vam omogućiti da bolje shvatite samu tehnologiju i principe na kojima se ona zasniva. Ukoliko radite u timovima, to će vam omogućiti da efikasnije i lakše komunicirate sa drugima, bolje razumete arhitekturu aplikacije i, naravno, postanete još bolji u svom poslu.
Stoga, da bismo razumeli terminologiju, moramo da obratimo pažnju na sledeće termine:
- Container (kontejner)
- Image (slika)
- Container Image (slika kontejnera)
- Image Layer (sloj slike)
- Registry (registar)
- Repository (repozitorijum)
- Tag
- Base Image (izvorna slika)
- Platform Image (platformska slika)
- Layer (sloj),
- Container Engine (kontejner endžin)
Napomena: Prevod u zagradama je izmišljen jer na našem jeziku ne postoje u potpunosti adekvatni prevodi za ove termine, ali ću u tekstu dalje navoditi i engleski i prilagođeni termin kako ne bi dolazilo do zabune.
Šta je kontejner?
Hajde da malo pričamo o osnovama, jer za razumevanje same terminologije moramo da razlučimo šta su tačno kontejneri.
Kontejner ima dvojako svojstvo. Poput normalnog Linux programa, kontejneri imaju dva stanja – stanje mirovanja (rest) i stanje rada (running). Kada je u stanju mirovanja, kontejner je ništa više nego običan fajl (ili skup fajlova) koji se nalaze na disku. Ovi fajlovi se referišu kao Container Image (slika kontejnera) ili Container Repository (repozitorijum).
Kada kucate komande za startovanje kontejnera, endžin kontejnera (Container Engine) vrši raspakivanje neophodnih fajlova i meta podataka, a zatim ih šalje Linux kernelu. Startovanje kontejnera je vrlo slično startovanju bilo kog drugog normalnog Linux procesa i zahteva slanje API poziva na Linux. Ovaj API poziv tipično inicira dodatnu izolaciju i mauntovanje kopije fajlova koji su predstavljali Container Image. Nakon starta, kontejneri su samo Linux procesi i sam proces startovanja procesa, ali i formati slika na disku su deo dobro definisanih standarda.
Postoji nekoliko konkurenata na tržištu Container Image formata (App, LXD, Docker), ali da ne bi došlo do dodatne zabune oko formata – pravila igre su definisana kroz OCI – Open Containers Initiative. OCI uključuje preciznu specifikaciju za Container Image Format , koja definiše format fajlova na disku za slike kontejnera (Container Image), ali i meta podatke (meta-data) koji definišu stvari poput hardverske arhitekture i operativnog sistema (Linux, Windows, itd.).
Zahvaljujući standardizaciji, kontejneri kao tehnologija ubrzano napreduju jer dobro definisana pravila igre nude mogućnost mnogim pojedincima i kompanijama da razvijaju raznorazne alate koji su međusobno kompatibilni. Sa druge strane, mi kao korisnici (tj. oni koji prave arhitekture i aplikacije zasnovane na njima) želimo da postoji kompatibilnost i interoperabilnost između alata koje koristimo za potpisivanje, skeniranje, generisanje, pokretanje, pomeranje i upravljanje slikama kontejenra (Container Images).
Formati nisu jedino mesto gde postoji konkurencija, ona postoji i kod kontejner endžina – Docker, CRI-O, LXC, RKT, Railcar. Container Engine uzima sliku kontejnera (Container Image) i pretvara je u kontejner (tj. aktivni proces). Kako to tačno radi je definisano u okviru OCI specifikacije koja uključuje i specifikaciju za Container Runtime i nešto što se zove RunC – Reference Runtime Implementation. Ono što je najvažnije je da su sve definicije i standardi Open Source.
Alati koji su razvijeni prateći OCI garantuju portabilnost između različitih ekosistema kontejner platformi, kontejner endžina i svih ostalih alata koji su dostupni od strane cloud provajdera. Razumevanje kompletne nomenklature, kontejner standarda i same arhitekture osnovnih gradivnih blokova kontejnera, omogućavaju lakšu komunikaciju sa drugima u industriji, a sve sa ciljem da se što efikasnije izgrade skalabilne aplikacije bazirane na kontejnerima i okruženja koja će moći da ih pogone u nadolazećim godinama.
Cloud VPS serveri idealno su rešenje za razvoj i hosting WordPress sajtova sa velikom količinom saobraćaja. Root pristup. 1 IPV4 javna IP adresa.WORDPRESS U ŠESTOJ BRZINI
CLOUD VPS SERVERI
Osnovni rečnik
Container Image (slika kontejnera)
Pročitajte i o Repository (repozitorijum).
Container image (slika kontejnera) u svojoj najjednostavnijoj definiciji predstavlja fajl koji se preuzima sa Registry servera (registry) , a koji se koristi kao mount point tokom procesa startovanja kontejnera.
LXD, Docker i RKT operišu po principu preuzimanja fajlova sa udaljene lokacije i njihove “egzekucije” u kontejnere. Svaka od ovih tehnologija tretira Container Image (slika kontejnera) na drugačini način. Na primer, LXD vrši preuzimanje jedne slike kontejnera (jedan sloj), dok Docker i RKT koriste slike bazirane na OCI standardu koje se mogu sastojati iz više slojeva.
Tehnički gledano, Container Image je mnogo komplikovaniji od jednog fajla koji se nalazi na Registry serveru. Kada ljudi koriste termin Container Image, obično misle na repozitorijum i referišu se na skup slojeva (Image Layers) kao i na meta podatke koji pružaju dodatne informacije o tim slojevima.
Container Image Format (format slike kontejnera)
Pogledajte i Container Image i uvod.
Pre jasne definicije standarda kroz OCI, svaki kontejner endžin (Container Engine) je koristio svoj format slike. Neki su se sastojali od jednog sloja, dok su drugi preferirali više slojeva u granajućoj (tree) arhitekturi.
Danas, upravo zahvaljujući dobro definisanim standardima, svi veći igrači na polju kontejner endžina koriste format koji je definisan kroz OCI – Open Containers Initiative. Ovaj format definiše slojeve i meta podatke koji se nalaze u okviru svake slike kontejnera (Container Image). U suštini, OCI format definiše sliku sastavljenu od TAR fajlova za svaki sloj uz meta podatke (metadata) koji se nalaze u okviru manifest.json
fajla.
OCI, koji je izvorno bio baziran na Docker V2 verziji formata slika, uspešno je unificirao široki ekosistem koji se sastoji iz različitih kontejner endžina, cloud provajdera i provajdera različitih tipova alata.
Container Engine (endžin kontejnera)
Pročitajte više i o Container Runtime.
Endžin kontejnera je softver koji prihvata zahteve od strane korisnika, uključujući i opcione parametre prosleđene kroz konzolu, vrši preuzimanje slika i, iz perspektive korisnika, zadužen je za pokretanje kontejnera. Postoje mnogobrojni kontejner endžini, poput LXD, CRI-O i Docker-a. Takođe, mnogobrojni Cloud provajderi, Platform as a Service (PaaS) provajderi i kontejner platforme su razvile sopstvene kontejner endžine, mahom bazirane na Docker-u ili uz potpunu usaglašenost sa OCI standardima.
Međutim, većina kontejner endžina u stvari ne vrše pokretanje kontejnera već se oslanjaju na OCI kompatibilan runtime alat poput runc
.
Tipično, ovaj alat je odgovoran za:
- Odgovaranje na zahteve korisnika
- Odgovaranje na zahteve koji se šalju preko API-ja, obično od strane orkestratora kontejnera (Container Orchestrator)
- Raspakivanje i proširivanje slike kontejnera (Container Image) na disku korišćenjem Graph drajvera (block ili fajl u zavinosti od drajvera)
- Pripremu kontejner mount point-a
- Pripremu metapodataka koji će biti prosleđeni odgovarajućem Container Runtime-u kako bi kontejner (Container) bio ispravno startovan (recimo, slika kontejnera već može da poseduje neke instrukcije koje treba da se izvrše ili instrukcije koje su definisane kroz CMD ili ENTRYPOINT ili na neki drugi način (npr. SECCOM pravila))
- Pozivanje Container Runtime-a.
Za više informacija savetujem da pročitate Two Types of People – Those Who Understand Container Standards and Those That Don’t
Container (kontejner)
Kontejneri postoje u okviru operativnih sistema duži vremenski period. Kontejner je, u biti, izvršena instanca slike kontejnera (Container Image).
Kontejner predstavlja standardni Linux proces, koji se obično stvara kroz clone()
sistemski poziv.
Container Host (host kontejnera)
Host kontejnera predstavlja sistem u okviru kojeg se izvršavaju kontejner procesi. To, na primer, može da bude neka instanca na Cloud platformi ili bare metal koji se nalazi u okviru vašeg datacentra.
Kada se slika kontejnera (repository) skine sa Registry servera na host kontejnera ona prelazi u lokalni keš. Ukoliko želite da saznate koji repozitorijumi su sinhronizovani lokalno, to možete obaviti na sledeći način:
igor@Atlas docker images -a REPOSITORY TAG IMAGE ID CREATED SIZE node 8 06f7c071f445 13 days ago 889MB mongo latest 525bd2016729 3 weeks ago 383MB traefik latest d048a102127b 5 weeks ago 68.8MB nats latest 40a6f5ca1594 3 months ago 7.76MB nginx latest 3c5a05123222 5 months ago 109MB mariadb latest 520fc647a087 5 months ago 403MB jonbaldie/beanstalkd latest dcea4172d82e 6 months ago 4.23MB
Registry Server (registar)
Registar iliti Registry Server predstavlja fajl server koji služi za smeštanje i čuvanje Docker repozitorijuma. Tipično, server koji ima ulogu registra je definisan kroz standardno DNS ime i odgovarajući javno dostupni port koji služi za pristup.
Kada Docker demon ne poseduje lokalno keširanu kopiju repozitorijuma, on vrši poziv registru kako bi izvršio skidanje. Ono što je izuzetno važno kod registra je pitanje implicitnog poverenja u isti zbog mogućih sigurnosnih implikacija. Drugim rečima – iako u okviru Docker registra postoji ogroman broj slika kontejnera (Container Image), to ne znači da svima trebate apsolutno verovati i koristiti ih bez prethodne provere.
Container Orchestration (orkestracija kontejnera)
Kao što sam već naveo, start sa kontejnerima je vrlo brz i jednostavan proces koji obično počinje definisanjem kontejner hosta (Container Host), instalacijom nekog od kontejner endžina (Container Engine) i skidanjem jedne ili više slika kontejnera (Container Image).
Vremenom, ukazaće se potreba za definisanjem sopstvenih slika kontejnera i za njihovo slanje na registar (Registry Server) kako biste ih lakše delili sa drugima u vašem timu. Kako to obično biva, biće i potrebe za međusobnom komunikacijom između kontejnera i njihovom provizijom kao jedne celine.
Na kraju, definisanjem odgovarajućeg pajplajna (pipeline) poput Dev/QA/Prod će dodatno zakomplikovati sam proces razvoja i integracije, i upravo je to momenat kada je orkestracija neophodna.
Orkestrator kontejnera je zadužen za dve stvari:
- Dinamičko upravljanje opterećenjem kontejnera u okviru klastera, poznatije kao distribuirano računarstvo (distributed computing)
- Pružanje standardizacije za definisanje aplikacija kroz konfiguracioni fajl (docker compose, kube yaml itd.)
Ove dve stavke pružaju mnogobrojne mogućnosti:
- Omogućavaju nezavisno upravljanje kontejnerima u okviru jedne aplikacije. Ovo je posebno korisno kad:
-
- postoji potreba za iskorišćenjem većeg broja kontejner hostova,
- pad pojedinačnih kontejnera (OOM, zamrznuti procesi),
- desi se gubitak kontejner hosta (problemi sa diskovima, mrežom, restart zbog održavanja),
- desi se pad kontejner endžina,
- postoji potreba za skaliranjem (na gore ili dole) pojedinačnih kontejnera.
- Proces puštanja (deploy) novih instanci aplikacije u nova okruženja je značajno pojednostavljen. Na primer:
-
- na laptop developera koji već poseduje softver za orkestraciju kontejnera,
- na deljeno (interno ili javno) razvojno okruženje ,
- na QA okruženje zarad testiranja,
- na okruženje koje služi za testiranje opterećenja,
- na “gold” okruženje zarad finalnog testiranja kompatibilnosti sa produkcijom,
- na produkciono okruženje,
- na nova produkciona okruženja koja poseduju unapređene kontejner hostove,
- na novo produkciono okruženje koje poseduje iste verzije kontejner hostova, kontejner enžina ali koje se nalazi na drugoj geografskoj lokaciji.
Postoji nekoliko različitih orksetratora kontejnera između kojijh možete da birate. Do skoro, veliku trojku su činili Docker Swarm, Apache Mesos i Kubernetes, ali u međuvremenu su Docker i Mesosphere dodali podršku za Kubernetes, kao i svaki veći Cloud hosting provajder.
Kubernetes je danas defacto standard u orkestraciji kontejnera.
Napredniji rečnik
Container Runtime
Container Runtime predstavlja komponentu niskog nivoa koja se uobičajeno koristi od strane kontejner endžina, ali može i da se koristi za ručno testiranje. Kao i za mnoge druge stvari, i za runtime postoji jasno definisan standard (OCI Runtime Standard) kroz implementaciju runc
alata. runc
je ujedno i najčešće korišćen, ali postoje i neki drugi alati koji su OCI kompatibilni, poput crun, railcar i katacontainers.
Pre nego što je nastao OCI, i sa njim runc
, Docker je koristio LXC kao runtime. Međutim, njihove potrebe su vrlo brzo prevazišle ono što je LXC mogao da ponudi pa su razvili svoj alat pod nazivom libcontainer
. Ova biblioteka je bila razvijena u Golangu i distribuirana je kao sastavni deo Docker endžina.
Nakon nastanka OCI-ja, Docker je bukvalno donirao kopletan kod koji je činio njihovu biblioteku i tako je nastao samostalni alat runc
. Zahvaljujući standardizaciji, ovaj alat pruža apsolutnu konzistentnost u procesu startovanja kontejner procesa, bez obzira na to koji kontejner endžin zapravo koristite.
Čemu služi Container Runtime?
- Za komunikaciju sa kernelom u momentu startovanja kontejner procesa (clone sistemski poziv)
- Podešavanje cgropus
- Podešavanje SELinux polisa
- Podešavanje AppArmor polisa
- Pristup mount pointu koji je definisan od strane endžina kontejnera
- Pristup meta podacima koje nudi endžin kontejnera.
Više informacija o runc
alatu možete pronaći ovde.
Image Layer (sloj slike)
Svaka slika kontejnera (poznatija i kao Repository) se sastoji od jednog ili više slojeva (layers). Slojevi u repozitorijumu su povezani međusobno putem parent-child relacije, a svaki sloj predstavlja izmene koje su nastale u odnosu na sloj iznad (parent layer).
Ovu strukturu i same slojeve moguće je vrlo lako videti zahvaljujući alatima poput Dockviz ili Dive , koji služe za vizuelizaciju slojeva.
Na primer, ovako izgleda izlaz iz Dockvviz alata:
igor@Atlas docker run --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock nate/dockviz images -t ├─<missing> Virtual Size: 116.4 MB │ └─<missing> Virtual Size: 116.4 MB │ └─<missing> Virtual Size: 116.4 MB │ └─<missing> Virtual Size: 116.4 MB │ └─<missing> Virtual Size: 116.4 MB │ └─<missing> Virtual Size: 116.7 MB │ └─<missing> Virtual Size: 123.7 MB │ └─<missing> Virtual Size: 123.7 MB │ └─<missing> Virtual Size: 123.7 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 126.0 MB │ └─<missing> Virtual Size: 382.7 MB │ └─<missing> Virtual Size: 382.7 MB │ └─<missing> Virtual Size: 382.7 MB │ └─<missing> Virtual Size: 382.8 MB │ └─<missing> Virtual Size: 382.8 MB │ └─<missing> Virtual Size: 382.8 MB │ └─525bd2016729 Virtual Size: 382.8 MB Tags: mongo:latest
Pored ova dva alata, Docker takođe nudi mogućnost pregleda slojeva repozitorijuma korišćenjem komande docker history
:
igor@Atlas docker history mongo IMAGE CREATED CREATED BY SIZE COMMENT 525bd2016729 3 weeks ago /bin/sh -c #(nop) CMD ["mongod"] 0B <missing> 3 weeks ago /bin/sh -c #(nop) EXPOSE 27017/tcp 0B <missing> 3 weeks ago /bin/sh -c #(nop) ENTRYPOINT ["docker-entry… 0B <missing> 3 weeks ago /bin/sh -c #(nop) COPY file:60abb511d646e0b8… 10.4kB <missing> 3 weeks ago /bin/sh -c #(nop) VOLUME [/data/db /data/co… 0B <missing> 3 weeks ago /bin/sh -c mkdir -p /data/db /data/configdb … 0B <missing> 3 weeks ago /bin/sh -c set -x && apt-get update && apt… 257MB <missing> 3 weeks ago /bin/sh -c echo "deb http://$MONGO_REPO/apt/… 73B <missing> 3 weeks ago /bin/sh -c #(nop) ENV MONGO_VERSION=4.0.4 0B <missing> 3 weeks ago /bin/sh -c #(nop) ENV MONGO_MAJOR=4.0 0B <missing> 3 weeks ago /bin/sh -c #(nop) ENV MONGO_PACKAGE=mongodb… 0B <missing> 3 weeks ago /bin/sh -c #(nop) ARG MONGO_REPO=repo.mongo… 0B <missing> 3 weeks ago /bin/sh -c #(nop) ARG MONGO_PACKAGE=mongodb… 0B <missing> 3 weeks ago /bin/sh -c set -ex; export GNUPGHOME="$(mkt… 1.16kB <missing> 3 weeks ago /bin/sh -c #(nop) ENV GPG_KEYS=9DA31620334B… 0B <missing> 3 weeks ago /bin/sh -c mkdir /docker-entrypoint-initdb.d 0B <missing> 3 weeks ago /bin/sh -c set -ex; apt-get update; apt-g… 2.28MB <missing> 3 weeks ago /bin/sh -c #(nop) ENV JSYAML_VERSION=3.10.0 0B <missing> 3 weeks ago /bin/sh -c #(nop) ENV GOSU_VERSION=1.10 0B <missing> 3 weeks ago /bin/sh -c apt-get update && apt-get instal… 7.01MB <missing> 3 weeks ago /bin/sh -c groupadd -r mongodb && useradd -r… 330kB <missing> 3 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B <missing> 3 weeks ago /bin/sh -c mkdir -p /run/systemd && echo 'do… 7B <missing> 3 weeks ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B <missing> 3 weeks ago /bin/sh -c set -xe && echo '#!/bin/sh' > /… 745B <missing> 3 weeks ago /bin/sh -c #(nop) ADD file:efec03b785a78c01a… 116MB
Ono što je očigledno, na primer, je da se Mongo repozitorijum sastoji iz jako velikog broja slojeva. Ono što bi takođe trebalo napomenuti je da je moguće iskoristiti bilo koji od ovih slojeva za pokretanje kontejnera, doduše on ne mora nužno ispravno da radi.
Postoje dva osnovna načina na koji se stvaraju novi slojevi u okviru repozitorijuma. Ukoliko ručno pravite svoju sliku, svaki “commit” će dodati jedan sloj. Ukoliko za pravljenje slike koristite Dockerfile, svaka direktiva u okviru tog fajla će stvoriti novi sloj.
Tag
Tagovi se definišu od strane onih koji održavaju repozitorijume i, u suštini, koriste se da označe koji sloj u repozitorijumu se može smatrati dovoljno stabilnim za upotrebu tj. za označavanje stabilnih verzija. Uobičajeno je da se poslednja verzija sloja označi sa tagom latest
.
Tagovi nisu deo bilo kakve OCI standardizacije, već su više neka vrste konvencije, ali mogu da se koriste u različite namene.
Ukoliko ste zainteresovani, vrlo lako možete izlistati sve tagove koji su dostupni u okviru jednog repozitorijuma. Na primer:
igor@Atlas curl -s https://registry.hub.docker.com/v1/repositories/mongo/tags | jq [ { "layer": "", "name": "latest" }, { "layer": "", "name": "2" }, { "layer": "", "name": "2.2" }, { "layer": "", "name": "2.2.7" }, { "layer": "", "name": "2.4" }, { "layer": "", "name": "2.4.10" }, { "layer": "", "name": "2.4.11" } ]
Repozitorijum
Ukoliko, recimo, izvršite komandu docker run mongo
, ono što se koristi je repozitorijum, a ne slika. U konkretnom primeru, mongo je repozitorijum.
Ovo može biti malo zbunjujuće jer u svakodnevnom radu koristimo termin slike (image) ili slike kontejnera (container image). Da stvari budu dodatno zbunjujuće, komanda docker images
u stvari lista lokalno keširane repozitorijume:
igor@Atlas docker images REPOSITORY TAG IMAGE ID CREATED SIZE conduit latest d1512dfadd64 13 days ago 946MB node 8 06f7c071f445 2 weeks ago 889MB mongo latest 525bd2016729 3 weeks ago 383MB traefik latest d048a102127b 6 weeks ago 68.8MB<span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span> nats latest 40a6f5ca1594 3 months ago 7.76MB nginx latest 3c5a05123222 5 months ago 109MB mariadb latest 520fc647a087 5 months ago 403MB
Nakon što definišete repoziturijum kao parametar u okviru komandne linije, endžin kontejnera preuzima tu informaciju i obavlja raznorazne funkcije za vas, poput potrage za repozitorijumom sa tim imenom na deinisanim Registry serverima.
Umesto samog naziva repozitorijuma može i da se koristi pun URL, čija je struktura obično ovakva:
REGISTRY/NAMESPACE/REPOSITORY[:TAG]
Pun URL se sastoji od lokacije registra, imenskog prostora (namespace), naziva repozitorijuma i, opciono, taga. Postoji nekoliko načina na koje se URL može definisati, na primer:
igor@Atlas docker pull registry.hub.docker.com/library/busybox igor@Atlas docker pull registry.hub.docker.com/library/busybox:latest igor@Atlas docker pull busybox
Namespace (imenovani prostor)
Služi za grupisanje repozitorijuma, na primer na DockerHub-u namespace je obično predstavljen kroz korisničko ime vlasnika repozitorijuma ili neko logičko ime (na primer, mintservices ili mongo).
Kernel Namespace
Kernel Namespace nema nikakve veze sa imenovanim prostorom koji se koristi na registrima. Kernel namespacing je verovatno najvažniji aspekt kada se priča o kontejnerima, jer bez njega ne bi bilo ni kontejnera kakve ih poznajemo danas. Kernel namespace omogućava svakom kontejner procesu da poseduje sopstveni mountpoint, mrežne interfejse, procese i sl.
Kada otkucate bilo koju komandu u Bash terminalu i pritisnete enter, Bash vrši poziv ka kernelu kako bi kreirao običan Linux proces korišćenjem exec()
sistemskog poziva. Kontejneri su malo drugačiji jer kada izvršavate komande one se prosleđuju kontejner endžinu poput Dockera, a onda Docker deamon prosleđuje pozive ka kernelu kako bi se kreirao kontejnerizovani proces, ali ovaj put korišćenjem clone()
sistemskog poziva. clone()
je poseban jer instancira proces sa sopstvenim virtuelnim mauntpointima, identifikatorima procesa i korisnika, mrežnim interfejsima i sl.
Graph Driver
Kada krajnji korisnik definiše tag slike kontejnera koji želi da koristi, graph drajver vrši raspakivanje onih slojeva slike koji su označeni kao neophodni od strane definisanog taga. Graph drajver je parče softvera koje je zaduženo za mapiranje slojeva slike u okviru repozitorijuma na nešto što je dostupno u okviru lokalnog storažnog prostora, pa tako slojevi slike kontejnera mogu biti mapirani na direktorijum korišćenjem drajvera poput Overlay2 ili na neki blok storage korišćenjem drajvera kakav je Device Mapper. Drajveri koji postoje su: zfs, overlayfs, devicemapper, btrfs i aufs.
Nakon što se kontejner startuje, slojevi slike su mapirani (mounted) kao read-only u okviru imenovanog prostora (namespace) kernela. Slojevi iz repozitorijuma su uvek mapirani kao read only, ali pored toga se instancira i poseban copy-on-write sloj koji omogućava konterijanizovanim procesima da upisuju podatke u okviru samog kontejnera. Prilikom upisa podataka oni se čuvaju na copy-on-write sloju, u okviru samog kontejner hosta. Postojanje ovog sloja nije obavezno i može se jednostavno isključiti ukoliko se prilikom starta kontejnera prosledi —readonly
parametar.
Docker poseduje sopstveni set Graph drajvera, ali postoje i druge Open Source biblioteke poput containers/storage koji koriste Skopeo i CRI-O.
Ukoliko želite da utvrdite koji graph drajver trenutno koristite, to možete saznati putem info komande
igor@Atlas docker info Containers: 281 Running: 176 Paused: 0 Stopped: 105 Images: 98 Server Version: 18.09.0 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true Logging Driver: json-file
Umesto zaključka
Cilj ovog članka je bio da vas upozna i zainteresuje za kontejnere, način na koji rade i opiše neke od osnovnih termina koji se svakodnevno koriste kada pričamo o kontejnerima.
Kontejneri su izuzetno jednostavni za upotrebu, nudeći veliku dozu fleksibilnosti koja je neophodna prilikom planiranja nekog okruženja. Međutim, ovde nije kraj priče o kontejnerima i tome šta oni mogu – o tome je napisano desetine knjiga i neke od zanimljivih tema će biti obrađene i na našem blogu.
Kao i uvek, nadam se da vam je ovaj članak bio poučan i zanimljiv. Ukoliko imate bilo koje pitanje ili komentar – napišite ga ispod ovog teksta.
Pozdrav Igore,
pre svega želim da ti se zahvalim na izdvojenom vremenu pri sastavljanju ovog članka. Odličan je.
Da li mi možeš preporučiti odakle da krenem sa dokerima? Preciznije, zanima me lepo objašnjen Dockerfile, Docker-compose.yum i docker swarm? Da li možeš da mi preporučiš neku knjigu ili sajt preko koga mogu da produbim svoje znanje na ovu temu?
Unapred zahvalan,
Jovan
Ćao Jovane,
Drago mi je da ti se tekst dopao!
Sa Dockerom je najbolje da kreneš od njihove dokumentacije i preko nekog kursa na Udemy-ju ili Pluralsight-u. Ja baš sada pišem serijal tekstova o Dockeru koji će da pokriju sve što tebe zanima i mnogo više od toga, pa prijavi se našu listu jer će tekstovi uskoro biti objavljeni.