Katera so najboljša orodja za Docker? Pregled

Obsežen ekosistem Dockerja raz­vi­jal­cem ponuja številne možnosti za uvajanje aplikacij, upra­vlja­nje kon­tej­ner­jev in še več. Pred­sta­vi­li vam bomo naj­po­memb­nej­ša orodja Dockerja ter vam ponudili pregled najbolj pri­lju­blje­nih projektov tretjih po­nu­dni­kov, ki razvijajo od­pr­to­ko­dna orodja za Docker.

Katera so naj­po­memb­nej­ša orodja/kom­po­nen­te Dockerja?

Danes je Docker veliko več kot le napredna platforma za upra­vlja­nje pro­gram­skih kon­tej­ner­jev. Raz­vi­jal­ci so ustvarili vrsto ra­zno­vr­stnih orodij za Docker, ki omogočajo lažje, hitrejše in prožnejše uvajanje aplikacij prek razpršene in­fra­struk­tu­re in oblačnih okolij. Poleg orodij za zdru­že­va­nje v grozde in uskla­je­va­nje obstaja tudi osrednja tržnica aplikacij ter orodje za upra­vlja­nje oblačnih virov.

Docker Engine

Ko raz­vi­jal­ci omenijo »Docker«, običajno mislijo na od­pr­to­ko­dno apli­ka­ci­jo tipa odjemalec-strežnik, kipred­sta­vlja osnovo platforme za kon­tej­ner­je. Ta apli­ka­ci­ja se imenuje Docker Engine. Osrednje kom­po­nen­te Docker Engine so Dockerjev demon, REST API in CLI (vmesnik ukazne vrstice), ki služi kot upo­rab­ni­ški vmesnik.

S to zasnovo lahko ko­mu­ni­ci­raš z Docker Engine prek ukazov v ukazni vrstici ter udobno upravljaš s slikami Docker, da­to­te­ka­mi Docker in kon­tej­ner­ji Docker iz terminala.

Podroben opis Docker Engine najdete v našem Doc­ker­je­vem vodniku za začetnike : Dockerjev vodnik: na­me­sti­tev in prvi koraki.

Docker Hub

Docker Hub upo­rab­ni­kom ponuja re­gi­stri­ra­no zbirko v oblaku, ki omogoča pre­na­ša­nje, centralno upra­vlja­nje in izmenjavo Doc­ker­je­vih slik z drugimi upo­rab­ni­ki Dockerja. Re­gi­stri­ra­ni upo­rab­ni­ki lahko Doc­ker­je­ve slike shra­nju­je­jo v javnih ali zasebnih re­po­zi­to­ri­jih. Za prenos javne slike (v Doc­ker­je­vi ter­mi­no­lo­gi­ji znan kot »pulling« ) ni potreben upo­rab­ni­ški račun. Vgrajen mehanizem oznak omogoča raz­vr­šča­nje slik po raz­li­či­cah.

Poleg javnih re­po­zi­to­ri­jev drugih upo­rab­ni­kov Dockerja je v uradnih re­po­zi­to­ri­jih na Docker Hubu na voljo tudi veliko virov, ki jih ponuja razvojna ekipa Dockerja ter znani od­pr­to­ko­dni projekti. Med najbolj pri­lju­blje­ni­mi Doc­ker­je­vi­mi slikami so spletni strežnik NGINX, po­dat­kov­na baza v po­mnil­ni­ku Redis, zbirka Unix orodij BusyBox in di­s­tri­bu­ci­ja Ubuntu Linux.

Or­ga­ni­za­ci­je so še ena pomembna funkcija Docker Huba, ki upo­rab­ni­kom Dockerja omogoča ustvar­ja­nje zasebnih re­po­zi­to­ri­jev, dostopnih izključno izbrani skupini ljudi. Dostopne pravice se znotraj or­ga­ni­za­ci­je upra­vlja­jo prek ekip in članstva v skupinah.

Docker Swarm

Docker Engine vsebuje vgrajeno funkcijo, ki upo­rab­ni­kom omogoča upra­vlja­nje go­sti­te­ljev Dockerja v grozdih, ime­no­va­nih swarms. Zmožnosti upra­vlja­nja grozdov in uskla­je­va­nja, vgrajene v Docker Engine, temeljijo na orodju Swarmkit. Če upo­ra­blja­te starejšo različico platforme za kon­tej­ner­je, je orodje Docker na voljo kot sa­mo­stoj­na apli­ka­ci­ja.

Swarm je orodje za zdru­že­va­nje v grozde, ki je del jedra Dockerja; združuje skupino go­sti­te­ljev Dockerja v en sam virtualni gostitelj in omogoča dostop do REST API-ja Dockerja. Vsako orodje Dockerja, povezano z demonom Dockerja, lahko dostopa do Swarma in se prilagaja številu go­sti­te­ljev Dockerja. Z upo­rab­ni­škim vmesnikom Docker Engine CLI lahko upo­rab­ni­ki ustvar­ja­jo grozde, raz­po­re­ja­jo apli­ka­ci­je znotraj grozda in upra­vlja­jo z de­lo­va­njem grozda, ne da bi morali upo­ra­blja­ti dodatno pro­gram­sko opremo za uskla­je­va­nje.

Docker-jevi motorji, združeni v grozde, delujejo v načinu swarm. To možnost izberite, če želite ustvariti nov grozd ali dodati Docker-jev gostitelj v obstoječi swarm. Posamezni Docker-jevi go­sti­te­lji v grozdu se imenujejo »vozlišča«. Vozlišča grozda lahko delujejo kot virtualni go­sti­te­lji na istem lokalnem sistemu, vendar se pogosteje uporablja oblačna ar­hi­tek­tu­ra, pri kateri so posamezna vozlišča Docker-jevega swarma raz­po­re­je­na po različnih sistemih in in­fra­struk­tu­rah.

Pro­gram­ska oprema temelji na ar­hi­tek­tu­ri »master-worker«. Ko je treba naloge raz­po­re­di­ti v roju, upo­rab­ni­ki po­sre­du­je­jo storitev upra­vi­telj­ske­mu vozlišču. Upra­vi­telj je nato odgovoren za raz­po­re­ja­nje kon­tej­ner­jev v gruči in deluje kot glavni upo­rab­ni­ški vmesnik za dostop do virov roja.

Vodstveno vozlišče pošilja posamezne enote, imenovane naloge, delovnim vozliščem.

• Storitve: storitve so osrednje strukture v Doc­ker­je­vih grozdih. Storitve opre­de­lju­je­jo nalogo, ki se izvede v Doc­ker­je­vem grozdu. Storitve se nanašajo na skupino kon­tej­ner­jev, ki temeljijo na isti podobi. Pri ustvar­ja­nju storitve uporabnik določi, katera podoba in kateri ukazi se uporabijo. Poleg tega storitve omogočajo pri­la­ga­ja­nje obsega aplikacij. Upo­rab­ni­ki platforme Docker preprosto določijo, koliko kon­tej­ner­jev naj se za določeno storitev zažene.
• Naloge: za raz­po­re­di­tev storitev v grozdu jih upra­vi­telj­ski vozlišče razdeli na posamezne delovne enote (naloge). Vsaka naloga vključuje Dockerjev kontejner ter ukaze, ki se v njem izvajajo.

Poleg upra­vlja­nja nadzora grozda in uskla­je­va­nja kon­tej­ner­jev lahko upra­vlja­vska vozlišča privzeto opra­vlja­jo tudi naloge delovnih vozlišč – razen če naloge teh vozlišč strogo omejite na upra­vlja­nje.

Na vsakem delovnem vozlišču teče program agenta. Ta sprejema naloge in zadevnemu glavnemu vozlišču posreduje poročila o stanju glede napredka prenesene naloge. Naslednja slika prikazuje shematski prikaz Docker Swarm:

Pri uvajanju Docker Swarm se upo­rab­ni­ki običajno zanašajo na Docker stroj.

Docker Compose

Docker Compose omogoča zdru­že­va­nje več kon­tej­ner­jev in njihovo izvajanje z enim samim ukazom. Osnovni element Compose je osrednja kon­fi­gu­ra­cij­ska datoteka, ki temelji na na­gra­je­nem jeziku YAML. Sintaksa te datoteke Compose je podobna sintaksi od­pr­to­ko­dne pro­gram­ske opreme Vagrant, ki se uporablja pri ustvar­ja­nju in kon­fi­gu­ra­ci­ji vir­tu­al­nih strojev.

V datoteki docker-compose.yml lahko opre­de­li­te poljubno število pro­gram­skih kon­tej­ner­jev, vključno z vsemi od­vi­snost­mi, ter njihove med­se­boj­ne povezave. Takšne apli­ka­ci­je z več kon­tej­ner­ji se upra­vlja­jo po istem vzorcu kot posamezni pro­gram­ski kon­tej­ner­ji. Za upra­vlja­nje celotnega ži­vljenj­ske­ga cikla apli­ka­ci­je uporabite ukazdocker-compose v kom­bi­na­ci­ji z želenim podukazom.

To orodje Docker se lahko enostavno vključi v grozd, ki temelji na Swarmu. Na ta način lahko apli­ka­ci­je z več kon­tej­ner­ji, ustvar­je­ne s Compose, izvajate na po­raz­de­lje­nih sistemih prav tako enostavno, kot bi jih na enem samem go­sti­te­lju Docker.

Še ena zna­čil­nost Docker Compose je vgrajen mehanizem za pri­la­ga­ja­nje zmo­glji­vo­sti. S tem orodjem za uskla­je­va­nje lahko prek ukazne vrstice enostavno določite, koliko kon­tej­ner­jev želite zagnati za določeno storitev.

Katera orodja za Docker drugih po­nu­dni­kov so na voljo?

Poleg lastnih razvojnih dosežkov podjetja Docker Inc. obstajajo tudi različna pro­gram­ska orodja in platforme zunanjih po­nu­dni­kov, ki ponujajo vmesnike za Docker Engine ali so bila posebej razvita za to pri­lju­blje­no platformo za kon­tej­ner­je. V eko­si­s­te­mu Dockerja so med najbolj pri­lju­blje­ni­mi od­pr­to­ko­dni­mi projekti orodje za or­ke­stra­ci­jo Ku­ber­ne­tes, orodje za upra­vlja­nje grozdov Shipyard, rešitev za po­ši­lja­nje več kon­tej­ner­jev Panamax, platforma za ne­pre­ki­nje­no in­te­gra­ci­jo Drone, ope­ra­cij­ski sistem v oblaku OpenStack in ope­ra­cij­ski sistem za po­dat­kov­ne centre D2iQ DC/OS, ki temelji na upra­vi­te­lju grozdov Mesos.

Ku­ber­ne­tes

Dockerju ni vedno mogoče razviti lastnih orodij za or­ke­stra­ci­jo, kot sta Swarm in Compose. Zato različna podjetja že leta vlagajo v lastni razvoj orodij, pri­la­go­je­nih potrebam strank, ki so namenjena lažjemu upra­vlja­nju kon­tej­ner­ske platforme v velikih, raz­pr­še­nih in­fra­struk­tu­rah. Med najbolj pri­lju­blje­ni­mi rešitvami te vrste je od­pr­to­ko­dni projekt Ku­ber­ne­tes.

Ku­ber­ne­tes je upra­vi­telj grozdov za apli­ka­ci­je, ki temeljijo na kon­tej­ner­jih. Cilj Ku­ber­ne­te­sa je av­to­ma­ti­za­ci­ja aplikacij v grozdu. Za to orodje za uskla­je­va­nje uporablja kot vmesnike za upra­vlja­nje REST-API, program za ukazno vrstico in grafični spletni vmesnik. Prek teh vmesnikov je mogoče sprožiti av­to­ma­ti­za­ci­je in zahtevati poročila o stanju. Ku­ber­ne­tes lahko uporabite za:

• izvajanje fo­to­gra­fij na podlagi kon­tej­ner­jev v grozdu,
• namestiti in upra­vlja­ti apli­ka­ci­je v po­raz­de­lje­nih sistemih,
• skalirati apli­ka­ci­je ter
• čim bolje iz­ko­ri­sti­ti strojno opremo.

V ta namen Ku­ber­ne­tes združuje kon­tej­ner­je v logične enote, imenovane podi. Podi pred­sta­vlja­jo osnovne enote upra­vi­te­lja grozda, ki jih je mogoče v grozdu raz­po­re­di­ti z na­čr­to­va­njem.

Podobno kot Docker Swarm tudi Ku­ber­ne­tes temelji na ar­hi­tek­tu­ri »master-worker«. Skupina je se­sta­vlje­na iz glavnega strežnika Ku­ber­ne­tes in različnih delavcev, ki se imenujejo tudi vozlišča Ku­ber­ne­tes (ali minioni). Glavni strežnik Ku­ber­ne­tes deluje kot osrednja nadzorna ploskev v skupini in je se­sta­vljen iz štirih osnovnih komponent, ki omogočajo ne­po­sre­dno ko­mu­ni­ka­ci­jo v skupini in raz­po­re­di­tev nalog. Glavni strežnik Ku­ber­ne­tes se­sta­vlja­jo strežnik API, kon­fi­gu­ra­cij­ski pomnilnik etcd, raz­po­re­je­val­nik in upra­vi­telj krmilnika.

• API strežnik: vse av­to­ma­ti­za­ci­je v Ku­ber­ne­te­so­vem klastru se sprožijo prek REST-API-ja z uporabo API strežnika. Ta deluje kot osrednji vmesnik za upra­vlja­nje v klastru.
• etcd: od­pr­to­ko­dni kon­fi­gu­ra­cij­ski pomnilnik etcd si lahko pred­sta­vlja­te kot pomnilnik Ku­ber­ne­te­so­ve­ga klastra. Key Value Store, ki ga je CoreOS razvil posebej za po­raz­de­lje­ne sisteme, shranjuje kon­fi­gu­ra­cij­ske podatke in jih naredi dostopne vsakemu vozlišču v klastru. Trenutno stanje klastra je mogoče kadarkoli upra­vlja­ti prek etcd.
• Scheduler: scheduler je odgovoren za raz­po­re­di­tev skupin kon­tej­ner­jev (podov) v klastru. Določi zahteve po virih za pod in jih nato uskladi z raz­po­lo­žlji­vi­mi viri po­sa­me­znih vozlišč v klastru.
• Upra­vi­telj krmilnika: upra­vi­telj krmilnika je storitev glavnega strežnika Ku­ber­ne­tes in nadzira uskla­je­va­nje z urav­na­va­njem stanja klastra in iz­va­ja­njem rutinskih nalog. Glavna naloga upra­vi­te­lja krmilnika je za­go­to­vi­ti, da stanje klastra ustreza opre­de­lje­ne­mu ciljnemu stanju.

Vse kom­po­nen­te glavnega strežnika Ku­ber­ne­tes se lahko nahajajo na istem go­sti­te­lju ali pa so raz­po­re­je­ne po več glavnih go­sti­te­ljih znotraj grozda z visoko raz­po­lo­žlji­vo­stjo.

Medtem ko je glavni strežnik Ku­ber­ne­tes odgovoren za uskla­je­va­nje, se podi, raz­po­re­je­ni v gruči, izvajajo na go­sti­te­ljih, tj. vozliščih Ku­ber­ne­tes, ki so podrejeni glavnemu strežniku. Za to mora na vsakem vozlišču Ku­ber­ne­tes teči pogon za kon­tej­ner­je. Čeprav je Docker dejanski standard, Ku­ber­ne­tes ni omejen na uporabo do­lo­če­ne­ga pogona za kon­tej­ner­je.

Poleg kon­tej­ner­ske­ga motorja vozlišča Ku­ber­ne­tes vklju­ču­je­jo naslednje kom­po­nen­te:

• kubelet: kubelet je agent, ki teče na vsakem vozlišču Ku­ber­ne­te­sa in se uporablja za nadzor in upra­vlja­nje vozlišča. Kot osrednja kontaktna točka vsakega vozlišča je kubelet povezan z glavnim stre­žni­kom Ku­ber­ne­te­sa in za­go­ta­vlja prenos in­for­ma­cij do nadzorne ravni ter njihov sprejem iz nje.
• kube-proxy: poleg tega na vsakem vozlišču Ku­ber­ne­te­sa teče proxy storitev kube-proxy. Ta za­go­ta­vlja, da se zahtevki iz zunanjega okolja po­sre­du­je­jo ustreznim kon­tej­ner­jem, ter za­go­ta­vlja storitve upo­rab­ni­kom aplikacij, ki temeljijo na kon­tej­ner­jih. Kube-proxy ponuja tudi osnovno po­raz­de­li­tev obre­me­ni­tve.

Naslednja slika prikazuje shematski prikaz ar­hi­tek­tu­re glavnega vozlišča, na kateri temelji platforma za or­ke­stra­ci­jo Ku­ber­ne­tes:

Poleg osre­dnje­ga projekta Ku­ber­ne­tes obstajajo tudi številna orodja in raz­ši­ri­tve, ki omogočajo dodajanje dodatnih funk­ci­o­nal­no­sti platformi za or­ke­stra­ci­jo. Najbolj pri­lju­blje­na so orodja za spre­mlja­nje in di­a­gno­sti­ko napak, kot so Pro­me­the­us, Weave Scope in sysdig, ter upra­vi­telj paketov Helm. Na voljo so tudi vtičniki za Apache Maven in Gradle ter Java API, ki omogoča daljinsko upra­vlja­nje Ku­ber­ne­te­sa.

Lad­je­del­ni­ca

Shipyard je sku­pno­stno razvita rešitev za upra­vlja­nje, ki temelji na platformi Swarm in upo­rab­ni­kom omogoča upra­vlja­nje virov Dockerja, kot so kon­tej­ner­ji, slike, go­sti­te­lji in zasebni registri, prek gra­fič­ne­ga upo­rab­ni­ške­ga vmesnika. Na voljo je kot spletna apli­ka­ci­ja, dostopna prek br­skal­ni­ka. Poleg funkcij za upra­vlja­nje grozdov, do katerih je mogoče dostopati prek cen­tral­ne­ga spletnega vmesnika, Shipyard ponuja tudi av­ten­ti­fi­ka­ci­jo upo­rab­ni­kov in nadzor dostopa na podlagi vlog.

Pro­gram­ska oprema je 100-odstotno zdru­žlji­va z od­da­lje­nim API-jem Dockerja in za shra­nje­va­nje podatkov o upo­rab­ni­ških računih, naslovih in dogodkih uporablja od­pr­to­ko­dno NoSQL-bazo podatkov RethinkDB. Pro­gram­ska oprema temelji na orodju za upra­vlja­nje grozdov Citadel in je se­sta­vlje­na iz treh glavnih komponent: krmilnika, API-ja in upo­rab­ni­ške­ga vmesnika.

• Shipyard Con­trol­ler: Shipyard Con­trol­ler je osrednji del orodja za upra­vlja­nje Shipyard. Shipyard Con­trol­ler ko­mu­ni­ci­ra z RethinkDB za shra­nje­va­nje podatkov ter omogoča na­sla­vlja­nje po­sa­me­znih go­sti­te­ljev v Doc­ker­je­vem klastru in upra­vlja­nje dogodkov.
• Shipyard API: Shipyard API temelji na REST. Vse funkcije orodja za upra­vlja­nje se nad­zo­ru­je­jo prek Shipyard API.
• Upo­rab­ni­ški vmesnik (UI) Shipyard: UI Shipyard je apli­ka­ci­ja AngularJS, ki upo­rab­ni­kom v spletnem br­skal­ni­ku ponuja grafični upo­rab­ni­ški vmesnik za upra­vlja­nje Doc­ker­je­vih grozdov. Vse in­te­rak­ci­je v upo­rab­ni­škem vmesniku potekajo prek API-ja Shipyard.

Več in­for­ma­cij o od­pr­to­ko­dnem projektu najdete na uradni spletni strani Shipyard.

Panamax

Raz­vi­jal­ci od­pr­to­ko­dne­ga projekta Panamax si pri­za­de­va­jo po­e­no­sta­vi­ti uvajanje aplikacij z več kon­tej­ner­ji. To brez­plač­no orodje upo­rab­ni­kom ponuja grafični upo­rab­ni­ški vmesnik, ki omogoča enostavno raz­vi­ja­nje, uvajanje in di­s­tri­bu­ci­jo kom­ple­ksnih aplikacij, te­me­lje­čih na Doc­ker­je­vih kon­tej­ner­jih, s pomočjo funkcije »povleci in spusti«.

Panamax omogoča shra­nje­va­nje kom­ple­ksnih aplikacij z več kon­tej­ner­ji kot predloge aplikacij ter njihovo raz­šir­ja­nje v gručastih ar­hi­tek­tu­rah z enim samim klikom. Z uporabo in­te­gri­ra­ne tržnice aplikacij, ki je gostovana na GitHubu, je mogoče predloge za lastne apli­ka­ci­je shraniti v Git-re­po­zi­to­ri­jih in jih dati na voljo drugim upo­rab­ni­kom.

Osnovne kom­po­nen­te ar­hi­tek­tu­re Panamax lahko razdelimo v dve skupini: lokalnega odjemalca Panamax in poljubno število od­da­lje­nih ciljnih sistemov.

Lokalni odjemalec Panamax je osrednja kom­po­nen­ta tega orodja Docker. Deluje na lokalnem sistemu in omogoča ustvar­ja­nje kom­ple­ksnih aplikacij, ki temeljijo na kon­tej­ner­jih. Lokalni odjemalec se­sta­vlja­jo naslednje kom­po­nen­te:

• CoreOS: za na­me­sti­tev lokalnega odjemalca Panamax je kot go­sti­telj­ski sistem potrebna di­s­tri­bu­ci­ja Linuxa CoreOS, ki je bila posebej zasnovana za pro­gram­ske kon­tej­ner­je. Odjemalec Panamax nato deluje kot Dockerjev kontejner v sistemu CoreOS. Poleg funkcij Dockerja imajo upo­rab­ni­ki dostop do različnih funkcij CoreOS-a. Mednje sodijo med drugim Fleet in Jo­ur­nalc­tl:
• Fleet: namesto ne­po­sre­dne in­te­gra­ci­je z Dockerjem odjemalec Panamax za uskla­je­va­nje svojih kon­tej­ner­jev uporablja upra­vi­te­lja grozdov Fleet. Fleet je upra­vi­telj grozdov, ki v ra­ču­nal­ni­ških grozdih nadzira Li­nu­xo­ve­ga demon systemd.
• Jo­ur­nalc­tl: odjemalec Panamax uporablja Jo­ur­nalc­tl za zah­te­va­nje dnev­ni­ških sporočil iz dnevnika Li­nu­xo­ve­ga sis­tem­ske­ga upra­vi­te­lja systemd.
• Na­me­sti­tve­ni program lokalnega odjemalca: na­me­sti­tve­ni program lokalnega odjemalca vsebuje vse kom­po­nen­te, potrebne za na­me­sti­tev odjemalca Panamax na lokalnem sistemu.
• Lokalni agent Panamax: osrednja kom­po­nen­ta lokalnega odjemalca je lokalni agent. Ta je prek API-ja Panamax povezan z raz­lič­ni­mi drugimi kom­po­nen­ta­mi in od­vi­snost­mi. Mednje spadajo lokalni gostitelj Docker, upo­rab­ni­ški vmesnik Panamax, zunanji registri in oddaljeni agenti ciljev raz­po­re­di­tve v gruči. Lokalni agent prek API-ja Panamax ko­mu­ni­ci­ra z na­sle­dnji­mi pro­gram­ski­mi vmesniki na lokalnem sistemu, da izmenjuje in­for­ma­ci­je o zagnanih apli­ka­ci­jah:
• Oddaljeni API Docker: Panamax prek od­da­lje­ne­ga API-ja Docker išče slike na lokalnem sistemu in pridobiva in­for­ma­ci­je o zagnanih kon­tej­ner­jih.
• API etcd: datoteke se prenesejo v demon CoreOS Fleet prek API-ja etcd.
• systemd-journal-gatewayd.services: Panamax pridobi izhod dnevnika zagnanih storitev prek systemd-journal-gatewayd.services.

Poleg tega vmesnik API Panamax omogoča tudi po­ve­zo­va­nje z raz­lič­ni­mi zunanjimi vmesniki API.

• API registra Docker: Panamax pridobi oznake slik iz registra Docker prek API-ja registra Docker.
• GitHub API: Panamax naloži predloge iz re­po­zi­to­ri­ja GitHub z uporabo API-ja GitHub.
• API Kis­sMe­trics: API Kis­sMe­trics zbira podatke o predlogah, ki jih upo­rab­ni­ki izvajajo.
• Upo­rab­ni­ški vmesnik Panamax: upo­rab­ni­ški vmesnik Panamax deluje kot upo­rab­ni­ški vmesnik v lokalnem sistemu in omogoča upo­rab­ni­kom nadzor nad orodjem Docker prek gra­fič­ne­ga vmesnika. Upo­rab­ni­ški vnosi se prek API-ja Panamax ne­po­sre­dno po­sre­du­je­jo lokalnemu agentu. Upo­rab­ni­ški vmesnik Panamax temelji na CTL Base UI Kit, knjižnici komponent upo­rab­ni­ške­ga vmesnika za spletne projekte podjetja Cen­tu­ry­Link.

V ter­mi­no­lo­gi­ji Panamax se vsak vozlišče v Doc­ker­je­vem klastru, ki ne opravlja upra­vlja­vskih nalog, imenuje oddaljeni cilj raz­po­re­di­tve. Cilji raz­po­re­di­tve so se­sta­vlje­ni iz Doc­ker­je­ve­ga go­sti­te­lja, ki je na­sta­vljen za raz­po­re­di­tev predlog Panamax s pomočjo na­sle­dnjih komponent:

• Na­me­sti­tve­ni program za ciljno okolje: na­me­sti­tve­ni program za ciljno okolje zažene gostitelj Docker, opremljen z od­da­lje­nim agentom Panamax in adap­ter­jem za or­ke­stra­ci­jo.
• Oddaljeni agent Panamax: če je nameščen oddaljeni agent Panamax, se apli­ka­ci­je lahko di­s­tri­bu­i­ra­jo prek lokalnega odjemalca Panamax na katero koli želeno končno točko v gruči. Oddaljeni agent Panamax teče kot Docker-kontejner na vsakem cilju raz­po­re­di­tve v gruči.
• Panamaxov adapter za or­ke­stra­ci­jo: v adapterju za or­ke­stra­ci­jo je pro­gram­ska logika za vsako orodje za or­ke­stra­ci­jo, ki je na voljo za Panamax, za­go­to­vlje­na v neodvisni plasti adapterja. Zaradi tega imajo upo­rab­ni­ki možnost, da vedno izberejo natančno teh­no­lo­gi­jo or­ke­stra­ci­je, ki jo podpira njihovo ciljno okolje. Vnaprej kon­fi­gu­ri­ra­ni adapterji vklju­ču­je­jo Ku­ber­ne­tes in Fleet:
• Panamaxov adapter za Ku­ber­ne­tes: v kom­bi­na­ci­ji z od­da­lje­nim agentom Panamax omogoča adapter za Ku­ber­ne­tes di­s­tri­bu­ci­jo predlog Panamax v grozdih Ku­ber­ne­tes.
• Panamaxov adapter Fleet: v kom­bi­na­ci­ji z od­da­lje­nim agentom Panamax adapter Fleet omogoča di­s­tri­bu­ci­jo predlog Panamax v grozdih, ki se upra­vlja­jo s pomočjo upra­vi­te­lja grozdov Fleet.

Naslednja slika prikazuje med­se­boj­no delovanje po­sa­me­znih komponent Panamax v Doc­ker­je­vem klastru:

Orodje za upra­vlja­nje kon­tej­ner­jev Panamax, ki temelji na CoreOS, upo­rab­ni­kom prek gra­fič­ne­ga upo­rab­ni­ške­ga vmesnika ponuja vrsto stan­dar­dnih teh­no­lo­gij za uskla­je­va­nje kon­tej­ner­jev, pa tudi možnost eno­stav­ne­ga upra­vlja­nja za­ple­te­nih aplikacij z več kon­tej­ner­ji v gručnih ar­hi­tek­tu­rah s pomočjo katerega koli sistema (npr. lastnega pre­no­sne­ga ra­ču­nal­ni­ka).

Z javnim re­po­zi­to­ri­jem predlog v okviru Panamaxa imajo upo­rab­ni­ki Panamaxa prek GitHuba dostop do javne knjižnice predlog z raz­lič­ni­mi viri.

Dron

Drone je enostavna platforma za ne­pre­ki­nje­no in­te­gra­ci­jo z mi­ni­mal­ni­mi zahtevami. S tem orodjem Docker lahko samodejno naložite svojo naj­no­vej­šo različico iz re­po­zi­to­ri­ja Git, kot je GitHub, in jo pre­iz­ku­si­te v izo­li­ra­nih kon­tej­ner­jih Docker. Izvajate lahko kateri koli niz testov ter pošiljate poročila in obvestila o stanju prek e-pošte. Za vsak test pro­gram­ske opreme se ustvari nov kontejner, ki temelji na slikah iz javnega registra Docker. To pomeni, da se kot okolje za te­sti­ra­nje kode lahko uporabi ka­te­ra­ko­li javno dostopna slika Docker.

Drone je in­te­gri­ran v Docker in ga podpirajo različni pro­gram­ski jeziki, kot so PHP, Node.js, Ruby, Go in Python. Edina resnična odvisnost je platforma za kon­tej­ner­je. S pomočjo Drone lahko ustvarite svojo osebno platformo za ne­pre­ki­nje­no in­te­gra­ci­jo na katerem koli sistemu, na katerega je mogoče namestiti Docker. Drone podpira različne re­po­zi­to­ri­je za nadzor različic, navodila za stan­dar­dno na­me­sti­tev z in­te­gra­ci­jo GitHub pa najdete na spletni strani od­pr­to­ko­dne­ga projekta na naslovu readme.drone.io.

Upra­vlja­nje platforme za ne­pre­ki­nje­no in­te­gra­ci­jo poteka prek spletnega vmesnika. Tu lahko naložite različice pro­gram­ske opreme iz katerega koli Git-re­po­zi­to­ri­ja, jih združite v apli­ka­ci­je in rezultat izvedete v vnaprej določenem testnem okolju. Za to se opredeli datoteka .drone.yml, ki določa, kako ustvariti in izvesti apli­ka­ci­jo za vsak test pro­gram­ske opreme.

Upo­rab­ni­kom dronov je na voljo od­pr­to­ko­dna rešitev za upra­vlja­nje in­te­gra­cij (CI), ki združuje prednosti al­ter­na­tiv­nih izdelkov, kot sta Travis in Jenkins, v upo­rab­ni­ku prijazno apli­ka­ci­jo.

OpenStack

Ko gre za vzpo­sta­vlja­nje in upra­vlja­nje od­pr­to­ko­dnih oblačnih in­fra­struk­tur, je od­pr­to­ko­dni oblačni ope­ra­cij­ski sistem OpenStack najboljša izbira.

Z Open­Stack­om lahko upra­vlja­te ra­ču­nal­ni­ške, shra­nje­val­ne in omrežne vire prek osrednje nadzorne plošče ter jih končnim upo­rab­ni­kom omogočite prek spletnega vmesnika.

Ope­ra­cij­ski sistem v oblaku temelji na modularni ar­hi­tek­tu­ri, ki jo sestavlja več komponent:

• Zun (storitev za kon­tej­ner­je): Zun je storitev za kon­tej­ner­je v okviru Open­Stac­ka, ki omogoča enostavno uvajanje in upra­vlja­nje aplikacij v kon­tej­ner­jih v oblaku OpenStack. Namen Zuna je omogočiti upo­rab­ni­kom upra­vlja­nje kon­tej­ner­jev prek REST API, ne da bi morali upra­vlja­ti strežnike ali grozde. Za delovanje Zuna po­tre­bu­je­te tri druge storitve OpenStack, in sicer Keystone, Neutron in kryr-lib­ne­twork. Funk­ci­o­nal­nost Zuna je mogoče razširiti tudi z dodatnimi sto­ri­tva­mi OpenStack, kot sta Cinder in Glance.
• Neutron (omrežna kom­po­nen­ta): Neutron (prej Quantum) je pre­no­slji­va, ska­la­bil­na sistemna kom­po­nen­ta, podprta z API, ki se uporablja za nadzor omrežja. Modul za­go­ta­vlja vmesnik za kom­ple­ksne omrežne to­po­lo­gi­je in podpira različne vtičnike, prek katerih je mogoče in­te­gri­ra­ti raz­šir­je­ne omrežne funkcije.
• kuryr-lib­ne­twork (gonilnik Docker): kuryr-lib­ne­twork je gonilnik, ki deluje kot vmesnik med Dockerjem in Neutronom.
• Cinder (blokovno shra­nje­va­nje): Cinder je vzdevek kom­po­nen­te v ar­hi­tek­tu­ri OpenStack, ki za­go­ta­vlja trajno blokovno shra­nje­va­nje za delovanje VM. Modul za­go­ta­vlja virtualno shra­nje­va­nje prek sa­mo­po­stre­žne­ga API-ja. S tem lahko končni upo­rab­ni­ki upo­ra­blja­jo shra­nje­val­ne vire, ne da bi vedeli, katera naprava za­go­ta­vlja shra­nje­va­nje.
• Keystone (storitev iden­ti­te­te): Keystone za­go­ta­vlja upo­rab­ni­kom OpenStack centralno storitev iden­ti­te­te. Modul deluje kot sistem av­ten­ti­fi­ka­ci­je in dovoljenj med po­sa­me­zni­mi kom­po­nen­ta­mi OpenStack. Dostop do projektov v oblaku urejajo najemniki. Vsak najemnik pred­sta­vlja upo­rab­ni­ka, pri čemer je mogoče opre­de­li­ti več upo­rab­ni­ških dostopov z raz­lič­ni­mi pravicami.
• Glance (storitev za slike): z modulom Glance OpenStack za­go­ta­vlja storitev, ki omogoča shra­nje­va­nje in pri­do­bi­va­nje slik VM.

Več in­for­ma­cij o kom­po­nen­tah in storitvah Open­Stac­ka najdete v našem članku o Open­Stacku.

Poleg zgoraj navedenih komponent je mogoče ar­hi­tek­tu­ro OpenStack razširiti z raz­lič­ni­mi moduli. O različnih izbirnih modulih si lahko preberete na spletni strani OpenStack.

D2iQ DC/OS

DC/OS (Di­s­tri­bu­ted Cloud Operating System) je od­pr­to­ko­dna pro­gram­ska oprema za upra­vlja­nje po­raz­de­lje­nih sistemov, ki jo je razvila družba D2iQ Inc. (prej Me­so­sphe­re). Projekt temelji na od­pr­to­ko­dnem upra­vi­te­lju grozdov Apache Mesos in je ope­ra­cij­ski sistem za po­dat­kov­ne centre. Izvorna koda je upo­rab­ni­kom na voljo pod licenco Apache različice 2 v re­po­zi­to­ri­jih DC/OS na GitHubu. Poslovna različica pro­gram­ske opreme je na voljo tudi na d2iq.com. Obsežna do­ku­men­ta­ci­ja projekta je na voljo na dcos.io.

DC/OS si lahko pred­sta­vlja­te kot di­s­tri­bu­ci­jo Mesosa, ki vam ponuja vse funkcije upra­vi­te­lja grozda (prek cen­tral­ne­ga upo­rab­ni­ške­ga vmesnika) in znatno razširja zmo­glji­vo­sti Mesosa.

DC/OS uporablja jedro raz­pr­še­ne­ga sistema platforme Mesos. To omogoča zdru­že­va­nje virov celotnega po­dat­kov­ne­ga centra in njihovo upra­vlja­nje v obliki zdru­že­ne­ga sistema, podobnega enemu samemu logičnemu strežniku. Na ta način lahko celotne skupine fizičnih ali vir­tu­al­nih strojev upra­vlja­te enako enostavno, kot bi upra­vlja­li en sam ra­ču­nal­nik.

Pro­gram­ska oprema po­e­no­sta­vlja na­me­sti­tev in upra­vlja­nje po­raz­de­lje­nih aplikacij ter av­to­ma­ti­zi­ra naloge, kot so upra­vlja­nje virov, na­čr­to­va­nje in ko­mu­ni­ka­ci­ja med procesi. Upra­vlja­nje grozda, ki temelji na sistemu D2iQ DC/OS, ter vklju­če­nih storitev poteka prek cen­tral­ne­ga programa za ukazno vrstico (CLI) ali spletnega vmesnika (GUI).

DC/OS ločuje vire v grozdu in za­go­ta­vlja skupne storitve, kot sta od­kri­va­nje storitev ali upra­vlja­nje paketov. Osnovne kom­po­nen­te pro­gram­ske opreme tečejo v za­šči­te­nem območju – jedru sistema. To vključuje glavni program in programe agentov platforme Mesos, ki so odgovorni za do­de­lje­va­nje virov, ločevanje procesov in varnostne funkcije.

• Mesosov glavni strežnik: Mesosov glavni strežnik je glavni proces, ki teče na glavnem vozlišču. Naloga Me­so­so­ve­ga glavnega strežnika je upra­vlja­nje virov in uskla­je­va­nje nalog (ab­strak­tnih delovnih enot), ki se izvajajo na vozlišču agenta. V ta namen Mesosov glavni strežnik razporeja vire med re­gi­stri­ra­ne storitve DC/OS in sprejema poročila o virih od Mesosovih agentov.
• Mesos agenti: Mesos agenti so procesi, ki tečejo na agentnih računih in so odgovorni za izvajanje nalog, ki jih razporedi glavni proces. Mesos agenti redno pošiljajo poročila o raz­po­lo­žlji­vih virih v gruči glavnemu procesu Mesos. Glavni proces Mesos jih posreduje raz­po­re­je­val­ni­ku (npr. Marathon, Chronos ali Cassandra). Ta odloči, katera naloga se bo izvajala na katerem vozlišču. Naloge se nato izvajajo v kon­tej­ner­ju na izoliran način.

Vse ostale sistemske kom­po­nen­te ter apli­ka­ci­je, ki jih prek izvajalca (executor) izvajajo agenti Mesos, tečejo v upo­rab­ni­škem prostoru. Osnovne kom­po­nen­te stan­dar­dne na­me­sti­tve DC/OS so upra­vi­telj­ski usmer­je­val­nik, Mesos DNS, po­raz­de­lje­ni DNS-proksi, po­raz­de­lje­val­nik obre­me­ni­tve Minuteman, raz­po­re­je­val­nik Marathon, Apache ZooKeeper in Exhibitor.

• Upra­vi­telj­ski usmer­je­val­nik: upra­vi­telj­ski usmer­je­val­nik je posebej kon­fi­gu­ri­ran spletni strežnik na podlagi NGINX, ki za­go­ta­vlja storitve DC/OS ter funkcije cen­tral­ne­ga av­ten­ti­fi­ci­ra­nja in proxyja.
• Mesos DNS: sistemska kom­po­nen­ta Mesos DNS za­go­ta­vlja funkcije od­kri­va­nja storitev, ki omogočajo po­sa­me­znim storitvam in apli­ka­ci­jam v gruči, da se med seboj pre­po­zna­jo prek cen­tral­ne­ga sistema domenskih imen (DNS).
• Di­s­tri­bu­ted DNS proxy: di­s­tri­bu­ted DNS proxy je notranji raz­po­re­je­val­nik DNS.
• Minuteman: sistemski komponent Minuteman deluje kot notranji po­raz­de­lje­val­nik obre­me­ni­tve, ki deluje na tran­spor­tni plasti (plast 4) re­fe­renč­ne­ga modela OSI.
• DC/OS Marathon: Marathon je osrednja kom­po­nen­ta platforme Mesos, ki v D2iQ DC/OS deluje kot sistem init (podobno kot systemd). Marathon zažene in nadzira storitve in apli­ka­ci­je DC/OS v okoljih grozdov. Poleg tega pro­gram­ska oprema za­go­ta­vlja funkcije visoke raz­po­lo­žlji­vo­sti, od­kri­va­nje storitev, po­raz­de­lje­va­nje obre­me­ni­tve, pre­ver­ja­nje delovanja in grafični spletni vmesnik.
• Apache ZooKeeper: Apache ZooKeeper je od­pr­to­ko­dna pro­gram­ska kom­po­nen­ta, ki za­go­ta­vlja ko­or­di­na­cij­ske funkcije za delovanje in nadzor aplikacij v po­raz­de­lje­nih sistemih. ZooKeeper se v D2iQ DC/OS uporablja za ko­or­di­na­ci­jo vseh na­me­šče­nih sis­tem­skih storitev.
• Exhibitor: Exhibitor je sistemska kom­po­nen­ta, ki se samodejno namesti in kon­fi­gu­ri­ra z Zo­o­Kee­per­jem na vsakem glavnem vozlišču. Exhibitor za­go­ta­vlja tudi grafični upo­rab­ni­ški vmesnik za upo­rab­ni­ke Zo­o­Kee­per­ja.

Na virih grozda, združenih prek DC/OS, je mogoče hkrati izvajati različne delovne obre­me­ni­tve. To na primer omogoča vzporedno delovanje sistemov za obdelavo velikih podatkov, mi­kro­sto­ri­tev ali platform za kon­tej­ner­je, kot so Hadoop, Spark in Docker, v okviru ope­ra­cij­ske­ga sistema grozda.

V okviru D2iQ Universe je za DC/OS na voljo javni katalog aplikacij. S pomočjo tega lahko apli­ka­ci­je, kot so Spark, Cassandra, Chronos, Jenkins ali Kafka, namestite s pre­pro­stim klikom v grafičnem upo­rab­ni­škem vmesniku.

Katera orodja Dockerja so na voljo za varnost?

Čeprav si zaprti procesi, ki tečejo v kon­tej­ner­jih, delijo isto jedro, Docker uporablja vrsto tehnik, da jih med seboj loči. Za to se običajno upo­ra­blja­jo osnovne funkcije jedra Linux, kot so Cgroups in Na­me­spa­ces.

Vendar pa kon­tej­ner­ji še vedno ne za­go­ta­vlja­jo enake stopnje izolacije, kot jo je mogoče doseči z vir­tu­al­ni­mi stroji. Kljub uporabi tehnik izolacije je mogoče prek kon­tej­ner­jev dostopati do pomembnih osnovnih pod­si­s­te­mov, kot so Cgroups, ter do vmesnikov jedra v imenikih /sys in /proc.

Razvojna ekipa Dockerja se zaveda, da te varnostne skrbi pred­sta­vlja­jo oviro za uvedbo teh­no­lo­gi­je kon­tej­ner­jev v pro­duk­cij­ske sisteme. Poleg osnovnih tehnik izolacije jedra Linuxa novejše različice Docker Engine podpirajo tudi okvire AppArmor, SELinux in Seccomp, ki delujejo kot nekakšen požarni zid za ključne vire.

• AppArmor: z AppAr­mor­jem se urejajo dostopne pravice kon­tej­ner­jev do da­to­teč­nih sistemov.
• SELinux: SELinux za­go­ta­vlja kom­ple­ksni re­gu­la­tiv­ni sistem, v katerem je mogoče izvajati nadzor dostopa do ključnih virov.
• Seccomp: Seccomp (Secure Computing Mode) nadzoruje izvajanje sis­tem­skih klicev.

Poleg teh orodij Dockerja Docker uporablja tudi funkcije sistema Linux za ome­je­va­nje pravic upo­rab­ni­ka root, s katerimi Docker Engine zažene kon­tej­ner­je.

Obstajajo tudi druge varnostne skrbi v zvezi z ran­lji­vost­mi pro­gram­ske opreme v kom­po­nen­tah aplikacij, ki jih razširja Dockerjev register. Ker lahko v bistvu kdorkoli ustvari Doc­ker­je­ve slike in jih v Docker Hubu naredi javno dostopne skupnosti, obstaja tveganje, da se ob prenosu slike v vaš sistem vnese zlo­na­me­ren kod. Pred na­me­sti­tvi­jo apli­ka­ci­je morajo upo­rab­ni­ki Dockerja poskrbeti, da vsa koda v sliki, namenjena za izvajanje kon­tej­ner­jev, izvira iz za­ne­slji­ve­ga vira.

Docker ponuja program za pre­ver­ja­nje, s katerim lahko ponudniki pro­gram­ske opreme dajo svoje slike Docker v pregled in pre­ver­ja­nje. S tem programom za pre­ver­ja­nje želi Docker raz­vi­jal­cem olajšati vzpo­sta­vlja­nje varnih dobavnih verig pro­gram­ske opreme za njihove projekte. Poleg povečanja varnosti za upo­rab­ni­ke je cilj programa ponuditi raz­vi­jal­cem pro­gram­ske opreme način, kako svoje projekte ločiti od množice drugih raz­po­lo­žlji­vih virov. Pre­ver­je­ne slike so označene z značko »Verified Publisher« in poleg drugih ugodnosti dobijo višjo uvrstitev v re­zul­ta­tih iskanja v Docker Hubu.