Plašā Docker eko­sis­tē­ma piedāvā iz­strā­dā­tā­jiem virkni iespēju lie­to­jum­prog­ram­mu iz­vie­to­ša­nai, kon­tei­ne­ru koor­di­nē­ša­nai un citām darbībām. Mēs ap­ska­tī­sim sva­rī­gā­kos Docker rīkus un sniegsim pārskatu par po­pu­lā­rā­ka­jiem trešo pušu pro­jek­tiem, kas izstrādā atvērtā koda Docker rīkus.

Kādi ir galvenie Docker rīki un kom­po­nen­ti?

Mūsdienās Docker ir daudz vairāk nekā tikai sarežģīta platforma prog­ram­ma­tū­ras kon­tei­ne­ru pār­val­dī­bai. Iz­strā­dā­tā­ji ir radījuši virkni dažādu Docker rīku, lai lie­to­jum­prog­ram­mu ieviešanu iz­klie­dē­tā in­fras­truk­tū­rā un mākoņvidē padarītu vien­kār­šā­ku, ātrāku un elas­tī­gā­ku. Papildus rīkiem klas­te­ri­zā­ci­jai un or­ķes­trē­ša­nai ir pieejams arī cen­trā­lais lie­to­jum­prog­ram­mu tirgus un rīks mā­koņ­re­sur­su pār­val­dī­bai.

Docker dzinējs

Kad prog­ram­mē­tā­ji runā par „Docker”, viņi parasti domā atvērtā koda klientu-servera lie­to­jum­prog­ram­mu, kasveido kon­tei­ne­ru plat­for­mas pamatu. Šo lie­to­jum­prog­ram­mu sauc par Docker Engine. Docker Engine galvenās sa­stāv­da­ļas ir Docker dēmons, REST API un CLI (ko­man­drin­das in­ter­feiss), kas kalpo kā lietotāja in­ter­feiss.

Pa­tei­co­ties šai uzbūvei, jūs varat sa­zi­nā­ties ar Docker Engine, iz­man­to­jot ko­man­drin­das komandas, un ērti pārvaldīt Docker attēlus, Docker failus un Docker kon­tei­ne­rus no termināļa.

Image: Schematic representation of the Docker engine
The main com­po­nents of the Docker engine: the Docker daemon, REST API and Docker CLI

Sīkāku aprakstu par Docker Engine vari atrast mūsu Docker pamācībā ie­sā­cē­jiem „Docker pamācība: in­sta­lē­ša­na un pirmie soļi“.

Docker Hub

Docker Hub nodrošina lie­to­tā­jiem mākonī bāzētu reģistru, kas ļauj le­ju­pie­lā­dēt Docker attēlus, tos cen­tra­li­zē­ti pārvaldīt un dalīties ar citiem Docker lie­to­tā­jiem. Re­ģis­trē­tie lietotāji var glabāt Docker attēlus publiskos vai privātos re­po­zi­to­ri­jos. Publiska attēla le­ju­pie­lā­dei (Docker ter­mi­no­lo­ģi­jā saukta par „pulling“ ) nav ne­pie­cie­šams lietotāja konts. In­teg­rē­tais tagu mehānisms ļauj veikt attēlu versiju pār­val­dī­bu.

Papildus citu Docker lietotāju pub­lis­ka­jiem re­po­zi­to­ri­jiem Docker Hub ofi­ciā­la­jos re­po­zi­to­ri­jos ir pieejami arī daudzi resursi no Docker iz­strā­dā­tā­ju komandas un pa­zīs­ta­miem atvērtā koda pro­jek­tiem. Po­pu­lā­rā­kie Docker attēli ietver NGINX tīmekļa serveri, Redis atmiņas datubāzi, BusyBox Unix rīku komplektu un Ubuntu Linux dis­tri­bu­tī­vu.

Image: Official repositories in the Docker node
You can find more than 100,000 free images in the official Docker re­po­si­to­ries.

Or­ga­ni­zā­ci­jas ir vēl viena svarīga Docker Hub funkcija, kas ļauj Docker lie­to­tā­jiem izveidot privātus re­po­zi­to­ri­jus, kuri ir pieejami tikai izvēlētai cilvēku grupai. Piekļuves tiesības or­ga­ni­zā­ci­jā tiek pār­val­dī­tas, iz­man­to­jot komandas un dalību grupās.

Docker Swarm

Docker Engine ietver iebūvētu funkciju, kas ļauj lie­to­tā­jiem pārvaldīt Docker hostus klasteros, kurus sauc par swarms. Docker Engine iebūvētās klasteru pār­val­dī­bas un koor­di­nā­ci­jas iespējas balstās uz Swarmkit rīku kopumu. Ja iz­man­to­jat vecāku kon­tei­ne­ru plat­for­mas versiju, Docker rīks ir pieejams kā atsevišķa lie­to­jum­prog­ram­ma.

Docker klās­te­ri­zā­ci­jas rīks, kas ir integrēts Docker vidē, Swarm apvieno Docker resursu kopumu vienā virtuālā resursā un nodrošina Docker REST API. Jebkurš ar Docker dēmonu saistīts rīks var piekļūt Swarm un tikt mērogots jebkurā Docker resursu skaitā. Iz­man­to­jot Docker Engine CLI, lietotāji var izveidot swarmus, izvietot lie­to­jum­prog­ram­mas klāsterī un pārvaldīt swarma darbību , ne­iz­man­to­jot papildu or­ķes­trā­ci­jas prog­ram­ma­tū­ru.

Docker dzinēji, kas apvienoti klasteros, darbojas swarm režīmā. Iz­vē­lie­ties šo opciju, ja vēlaties izveidot jaunu klasteri vai pievienot Docker resursu esošajam swarm. At­se­viš­ķus Docker resursus klasterī sauc par „mezgliem”. Klastera mezgli var darboties kā virtuāli resursi vienā un tajā pašā lokālajā sistēmā, taču biežāk tiek izmantota mā­koņbal­stī­ta ar­hi­tek­tū­ra, kurā at­se­viš­ķie Docker swarm mezgli ir iz­klie­dē­ti pa dažādām sistēmām un in­fras­truk­tū­rām.

Prog­ram­ma­tū­ra balstās uz „master-worker“ ar­hi­tek­tū­ru. Kad uzdevumi ir jāsadala „Swarm“ vidē, lietotāji nosūta pa­kal­po­ju­mu vadības mezglam. Vadības mezgls pēc tam atbild par kon­tei­ne­ru plānošanu klasterī un kalpo kā galvenā lietotāja saskarne, lai piekļūtu „Swarm“ resursiem.

Pār­val­dnie­ka mezgls nosūta at­se­viš­ķas vienības, ko sauc par uz­de­vu­miem, darba mezgliem.

  • Pa­kal­po­ju­mi: pa­kal­po­ju­mi ir Docker klasteru centrālās struk­tū­ras. Pa­kal­po­jums definē uzdevumu, kas jāizpilda Docker klasterī. Pa­kal­po­jums attiecas uz kon­tei­ne­ru grupu, kas balstās uz vienu un to pašu attēlu. Iz­vei­do­jot pa­kal­po­ju­mu, lietotājs norāda, kurš attēls un kādas komandas tiek iz­man­to­tas. Turklāt pa­kal­po­ju­mi piedāvā iespēju mērogot lie­to­jum­prog­ram­mas. Docker plat­for­mas lietotāji vienkārši nosaka, cik daudz kon­tei­ne­ru jāpalaiž kon­krē­ta­jam pa­kal­po­ju­mam.
  • Uzdevumi: lai izplatītu pa­kal­po­ju­mus klasterī, pār­val­dnie­ka mezgls tos sadala at­se­viš­ķās darba vienībās (uzdevumos). Katrs uzdevums ietver Docker kon­tei­ne­ru, kā arī komandas, kas tajā tiek iz­pil­dī­tas.

Papildus klastera pār­val­dī­bai un kon­tei­ne­ru koor­di­nē­ša­nai pār­val­dī­bas mezgli pēc no­klu­sē­ju­ma var pildīt arī darba mezglu funkcijas – ja vien jūs šo mezglu uzdevumus ne­ie­ro­be­žo­jat tikai ar pār­val­dī­bu.

Katrā darba mezglā darbojas aģenta programma. Tā pieņem uzdevumus un nosūta at­tie­cī­ga­jam gal­ve­na­jam mezglam statusa ziņojumus par nodotā uzdevuma izpildes gaitu. Turp­mā­ka­jā attēlā redzams Docker Swarm she­ma­tisks at­tē­lo­jums:

Image: Schematic representation of a Docker Swarm
The manager-worker archi­tectu­re of a Docker Swarm

Ieviešot Docker Swarm, lietotāji parasti paļaujas uz Docker mašīnu.

Docker Compose

Docker Compose ļauj apvienot vairākus kon­tei­ne­rus un tos palaist ar vienu komandu. Compose pa­ma­te­le­ments ir cen­trā­lais kon­fi­gu­rā­ci­jas fails, kas balstās uz atzīto YAML valodu. Šī Compose faila sintakse ir līdzīga atvērtā koda prog­ram­ma­tū­ras Vagrant sintaksei, ko izmanto virtuālo mašīnu izveidei un kon­fi­gu­rē­ša­nai.

Failā docker-compose.yml var definēt ne­ie­ro­be­žo­tu skaitu prog­ram­ma­tū­ras kon­tei­ne­ru, ieskaitot visas atkarības, kā arī to sav­star­pē­jās saistības. Šādas daudzkon­tei­ne­ru lie­to­jum­prog­ram­mas tiek pār­val­dī­tas pēc tā paša principa kā atsevišķi prog­ram­ma­tū­ras kon­tei­ne­ri. Lai pār­val­dī­tu lie­to­jum­prog­ram­mas pilnu dzīves ciklu, iz­man­to­jiet komandudocker-compose** kopā ar vajadzīgo ap­akš­komman­du.

Šo Docker rīku var viegli integrēt klasterī, kas balstās uz Swarm. Tādējādi ar Compose iz­vei­do­tas daudzkon­tai­ne­ru lie­to­jum­prog­ram­mas varat palaist iz­klie­dē­tās sistēmās tikpat viegli, kā to darītu uz viena Docker servera.

Vēl viena Docker Compose funkcija ir integrēts mē­ro­go­ša­nas mehānisms. Iz­man­to­jot šo koor­di­nē­ša­nas rīku, varat ērti izmantot ko­man­drin­das programmu, lai noteiktu, cik daudz kon­tei­ne­ru vēlaties palaist kon­krē­ta­jam pa­kal­po­ju­mam.

Kādi ir trešo pušu Docker rīki?

Papildus Docker Inc. iekšēji iz­strā­dā­ta­jiem ri­si­nā­ju­miem pastāv dažādi ārējo pie­gā­dā­tā­ju prog­ram­ma­tū­ras rīki un plat­for­mas, kas nodrošina saskarnes ar Docker Engine vai ir speciāli iz­strā­dā­tas šai po­pu­lā­ra­jai kon­tei­ne­ru plat­for­mai. Docker eko­sis­tē­mā po­pu­lā­rā­kie atvērtā koda projekti ir or­ķes­trā­ci­jas rīks Ku­ber­ne­tes, klastera pār­val­dī­bas rīks Shipyard, daudzkon­tai­ne­ru pār­va­dā­ju­mu ri­si­nā­jums Panamax, ne­pār­trauk­tas in­teg­rā­ci­jas platforma Drone, mākonis balstīta ope­rē­tājsis­tē­ma OpenStack un datu centra ope­rē­tājsis­tē­ma D2iQ DC/OS, kas balstās uz klastera pār­val­dnie­ku Mesos.

Ku­ber­ne­tes

Docker ne vienmēr spēj piedāvāt savus or­ķes­trā­ci­jas rīkus, piemēram, Swarm un Compose. Tāpēc dažādi uzņēmumi jau gadiem ilgi investē savos izstrādes darbos, lai radītu īpaši pie­lā­go­tus rīkus, kas paredzēti kon­tei­ne­ru plat­for­mas darbības at­vieg­lo­ša­nai lielās, iz­klie­dē­tās in­fras­truk­tū­rās. Viens no po­pu­lā­rā­ka­jiem šāda veida ri­si­nā­ju­miem ir atvērtā koda projekts Ku­ber­ne­tes.

Ku­ber­ne­tes ir klastera pār­vald­nieks kon­tei­ne­ru bāzētām lie­to­jum­prog­ram­mām. Ku­ber­ne­tes mērķis ir au­to­ma­ti­zēt lie­to­jum­prog­ram­mu darbību klasterī. Lai to panāktu, šis koor­di­nā­ci­jas rīks kā vadības saskarnes izmanto REST-API, ko­man­drin­das programmu un grafisko tīmekļa saskarni. Iz­man­to­jot šīs saskarnes, var uzsākt au­to­ma­ti­zā­ci­jas procesus un pieprasīt statusa ziņojumus. Ku­ber­ne­tes var izmantot, lai:

  • izpildīt kon­tei­ne­ru bāzētas prog­ram­mas klasterī,
  • instalēt un pārvaldīt lie­to­jum­prog­ram­mas iz­klie­dē­tās sistēmās,
  • mērogu pielāgot lie­to­jum­prog­ram­mām un
  • izmantot aparatūru pēc iespējas efektīvāk.

Šim nolūkam Ku­ber­ne­tes apvieno kon­tei­ne­rus loģiskās vienībās, kuras sauc par podiem. Podi ir klastera pār­val­dnie­ka pa­mat­vie­nī­bas, kuras, iz­man­to­jot plānošanu, var izvietot klasterī.

Tāpat kā Docker Swarm, arī Ku­ber­ne­tes balstās uz „master-worker“ ar­hi­tek­tū­ru. Klasteris sastāv no Ku­ber­ne­tes galvenā servera un dažādiem darba serveriem, kurus sauc arī par Ku­ber­ne­tes mezgliem (vai minioniem). Ku­ber­ne­tes galvenais serveris darbojas kā centrālā vadības platforma klasterī un sastāv no četriem pamata kom­po­nen­tiem, kas nodrošina tiešu ko­mu­ni­kā­ci­ju klasterī un uzdevumu sadali. Ku­ber­ne­tes galvenais serveris sastāv no API servera, kon­fi­gu­rā­ci­jas atmiņas etcd, plānotāja un kon­tro­lie­ru pār­val­dnie­ka.

  • API serveris: visas au­to­ma­ti­zā­ci­jas darbības Ku­ber­ne­tes klasterī tiek uzsāktas, iz­man­to­jot REST-API caur API serveri. Tas darbojas kā centrālā ad­mi­nis­trē­ša­nas saskarne klasterī.
  • etcd: atvērtā koda kon­fi­gu­rā­ci­jas atmiņu etcd var uzskatīt par Ku­ber­ne­tes klastera atmiņu. Key Value Store, ko CoreOS iz­strā­dā­ja īpaši iz­klie­dē­tām sistēmām, uzglabā kon­fi­gu­rā­ci­jas datus un padara tos pieejamus katram klastera mezglam. Klastera pa­šrei­zē­jo stāvokli var pārvaldīt jebkurā brīdī, iz­man­to­jot etcd.
  • Plānotājs: plānotājs ir atbildīgs par kon­tei­ne­ru grupu (pod) sadali klasterī. Tas nosaka poda resursu prasības un pēc tam tās saskaņo ar pie­eja­ma­jiem resursiem at­se­viš­ķos klastera mezglos.
  • Con­trol­ler manager: con­trol­ler manager ir Ku­ber­ne­tes master pa­kal­po­jums, kas kontrolē or­ķes­trē­ša­nu, regulējot klastera stāvokli un veicot rutīnas uzdevumus. Con­trol­ler manager galvenais uzdevums ir no­dro­ši­nāt, ka klastera stāvoklis atbilst de­fi­nē­ta­jam mērķa stāvoklim.

Ku­ber­ne­tes galvenā servera visus kom­po­nen­tus var izvietot vienā serverī vai sadalīt pa vairākiem gal­ve­na­jiem serveriem augstas pie­eja­mī­bas klasterī.

Lai gan Ku­ber­ne­tes galvenais mezgls atbild par koor­di­nē­ša­nu, klasterī iz­vie­to­tie podi darbojas uz resursu serveriem — Ku­ber­ne­tes mezgliem, kas ir pakļauti gal­ve­na­jam mezglam. Lai to no­dro­ši­nā­tu, katrā Ku­ber­ne­tes mezglā ir jā­dar­bo­jas kon­tei­ne­ru dzinējam. Lai gan Docker ir de facto standarts, Ku­ber­ne­tes nav obligāti jāizmanto konkrēts kon­tei­ne­ru dzinējs.

Papildus kon­tei­ne­ru dzinējam Ku­ber­ne­tes mezgli ietver šādus kom­po­nen­tus:

  • kubelet: kubelet ir aģents, kas darbojas katrā Ku­ber­ne­tes mezglā un tiek izmantots mezgla kontrolei un pār­val­dī­bai. Kā katra mezgla galvenais saskarnes punkts, kubelet ir savienots ar Ku­ber­ne­tes galveno serveri un nodrošina in­for­mā­ci­jas no­sū­tī­ša­nu uz vadības līmeni un saņemšanu no tā.
  • kube-proxy: papildus tam katrā Ku­ber­ne­tes mezglā darbojas star­pniek­ser­viss kube-proxy. Tas nodrošina, ka pie­pra­sī­ju­mi no ārpuses tiek pārsūtīti uz at­tie­cī­ga­jiem kon­tei­ne­riem, un sniedz pa­kal­po­ju­mus kon­tei­ne­ru bāzētu lie­to­jum­prog­ram­mu lie­to­tā­jiem. Kube-proxy piedāvā arī pamata līmeņa slodzes iz­lī­dzi­nā­ša­nu.

Šajā attēlā ir parādīts galvenā mezgla ar­hi­tek­tū­ras she­ma­tisks at­tē­lo­jums, uz kura balstās or­ķes­trā­ci­jas platforma Ku­ber­ne­tes:

Image: Schematic representation of the Kubernetes architecture
The master-node archi­tectu­re of the orches­tra­tion platform Ku­ber­ne­tes

Papildus gal­ve­na­jam Ku­ber­ne­tes projektam ir pieejami arī daudzi rīki un pa­pla­ši­nā­ju­mi, kas ļauj pa­pla­ši­nāt šīs or­ķes­trā­ci­jas plat­for­mas fun­kcio­na­li­tā­ti. Po­pu­lā­rā­kie no tiem ir uz­rau­dzī­bas un kļūdu diag­nos­ti­kas rīki Pro­metheus, Weave Scope un sysdig, kā arī pakotņu pār­vald­nieks Helm. Ir pieejami arī spraudņi Apache Maven un Gradle, kā arī Java API, kas ļauj at­tā­li­nā­ti vadīt Ku­ber­ne­tes.

Kuģu būvētava

Shipyard ir kopienas iz­strā­dāts pār­val­dī­bas ri­si­nā­jums, kas balstās uz Swarm un ļauj lie­to­tā­jiem uzturēt Docker resursus, piemēram, kon­tei­ne­rus, attēlus, hostus un privātos reģistrus, iz­man­to­jot grafisko lietotāja saskarni. Tas ir pieejams kā tīmekļa lie­to­jum­prog­ram­ma, ko var izmantot ar pārlūku. Papildus klastera pār­val­dī­bas funkcijām, kas ir pieejamas caur centrālo tīmekļa saskarni, Shipyard piedāvā arī lietotāju au­ten­ti­fi­kā­ci­ju un uz lomām balstītu piekļuves kontroli.

Prog­ram­ma­tū­ra ir 100 % saderīga ar Docker attālo API un izmanto atvērtā koda NoSQL datubāzi RethinkDB, lai uzglabātu datus par lietotāju kontiem, adresēm un no­ti­ku­miem. Prog­ram­ma­tū­ra balstās uz klastera pār­val­dī­bas rīku kopumu Citadel un sastāv no trim gal­ve­na­jām sa­stāv­da­ļām: kon­tro­lie­ris, API un lietotāja saskarne.

  • Shipyard kon­tro­lie­ris: kon­tro­lie­ris ir pār­val­dī­bas rīka Shipyard galvenā sa­stāv­da­ļa. Shipyard kon­tro­lie­ris mi­jie­dar­bo­jas ar RethinkDB, lai uzglabātu datus, un ļauj adresēt at­se­viš­ķus hostus Docker klasterī, kā arī kontrolēt notikumus.
  • Shipyard API: Shipyard API ir balstīts uz REST. Visas pār­val­dī­bas rīka funkcijas tiek kon­tro­lē­tas ar Shipyard API star­pnie­cī­bu.
  • Shipyard lietotāja saskarne (UI): Shipyard UI ir AngularJS lietotne, kas lie­to­tā­jiem piedāvā grafisko lietotāja saskarni Docker klasteru pār­val­dī­bai tīmekļa pār­lūkprog­ram­mā. Visas mi­jie­dar­bī­bas lietotāja saskarnē notiek, iz­man­to­jot Shipyard API.

Papildu in­for­mā­ci­ja par šo atvērtā koda projektu ir pieejama Shipyard ofi­ciā­la­jā tīmekļa vietnē.

Panamax

Atvērtā koda prog­ram­ma­tū­ras projekta „Panamax“ iz­strā­dā­tā­ju mērķis ir vien­kār­šot daudzkon­tai­ne­ru lietotņu ieviešanu. Šis bezmaksas rīks piedāvā lie­to­tā­jiem grafisko lietotāja saskarni, kas ļauj ērti izstrādāt, ieviest un izplatīt sa­rež­ģī­tas lietotnes, kas balstās uz Docker kon­tei­ne­riem, iz­man­to­jot „vilk un nomet“ funkciju.

Panamax ļauj saglabāt sa­rež­ģī­tas daudzkon­tei­ne­ru lie­to­jum­prog­ram­mas kā lie­to­jum­prog­ram­mu veidnes un izplatīt tās klastera ar­hi­tek­tū­rās ar vienu klikšķi. Iz­man­to­jot integrētu lie­to­jum­prog­ram­mu veikalu, kas atrodas GitHub vietnē, pa­šiz­vei­do­to lie­to­jum­prog­ram­mu veidnes var saglabāt Git re­po­zi­to­ri­jos un darīt tās pieejamas citiem lie­to­tā­jiem.

Panamax ar­hi­tek­tū­ras galvenās sa­stāv­da­ļas var iedalīt divās grupās: Panamax vietējais klients un jebkurš skaits attālo iz­vie­to­ša­nas mērķu.

Panamax vietējais klients ir šī Docker rīka galvenā sa­stāv­da­ļa. Tas darbojas vietējā sistēmā un ļauj izveidot sa­rež­ģī­tas kon­tei­ne­ru bāzētas lie­to­jum­prog­ram­mas. Vietējais klients sastāv no šādām sa­stāv­da­ļām:

  • CoreOS: Panamax vietējā klienta in­sta­lē­ša­nai kā uzņēmējai sistēmai ir ne­pie­cie­ša­ma Linux dis­tri­bū­ci­ja CoreOS, kas ir īpaši iz­strā­dā­ta prog­ram­ma­tū­ras kon­tei­ne­riem. Pēc tam Panamax klients tiek palaists kā Docker kon­tei­ners CoreOS vidē. Papildus Docker funkcijām lie­to­tā­jiem ir pieejamas dažādas CoreOS funkcijas. Starp tām ir, piemēram, Fleet un Jour­nalctl:
  • Fleet: tā vietā, lai in­teg­rē­tos tieši ar Docker, Panamax klients izmanto klastera pār­val­dnie­ku Fleet, lai koor­di­nē­tu savus kon­tei­ne­rus. Fleet ir klastera pār­vald­nieks, kas kontrolē Linux dēmonu systemd datoru klasteros.
  • Jour­nalctl: Panamax klients izmanto Jour­nalctl, lai pie­pra­sī­tu žurnāla ziņojumus no Linux sistēmas pār­val­dnie­ka systemd.
  • Vietējā klienta in­sta­lē­tājs: vietējā klienta in­sta­lē­tājs satur visas sa­stāv­da­ļas, kas ne­pie­cie­ša­mas, lai instalētu Panamax klientu vietējā sistēmā.
  • Panamax vietējais aģents: vietējā klienta centrālā sa­stāv­da­ļa ir vietējais aģents. Tas ir saistīts ar dažādām citām sa­stāv­da­ļām un atkarībām, iz­man­to­jot Panamax API. Tās ietver vietējo Docker hostu, Panamax lietotāja saskarni, ārējos reģistrus un iz­vie­to­ju­ma mērķu attālos aģentus klasterī. Vietējais aģents mi­jie­dar­bo­jas ar šādām programmu saskarnēm vietējā sistēmā, iz­man­to­jot Panamax API, lai ap­mai­nī­tos ar in­for­mā­ci­ju par dar­bo­jo­šām lie­to­jum­prog­ram­mām:
  • Docker attālais API: Panamax meklē attēlus vietējā sistēmā, iz­man­to­jot Docker attālo API, un iegūst in­for­mā­ci­ju par dar­bo­jo­ša­jiem kon­tei­ne­riem.
  • etcd API: faili tiek nosūtīti CoreOS Fleet dēmonam, iz­man­to­jot etcd API.
  • systemd-journal-gatewayd.services: Panamax iegūst dar­bo­jo­šos pa­kal­po­ju­mu žurnāla izvadi, iz­man­to­jot systemd-journal-gatewayd.services.

Turklāt Panamax API nodrošina arī saziņu ar dažādām ārējām API.

  • Docker reģistra API: Panamax iegūst attēlu tagus no Docker reģistra, iz­man­to­jot Docker reģistra API.
  • GitHub API: Panamax ielādē veidnes no GitHub re­po­zi­to­ri­ja, iz­man­to­jot GitHub API.
  • KissMet­rics API: KissMet­rics API vāc datus par veidnēm, kuras izmanto lietotāji.
  • Panamax lietotāja saskarne: Panamax lietotāja saskarne darbojas kā lietotāja saskarne vietējā sistēmā un ļauj lie­to­tā­jiem vadīt Docker rīku, iz­man­to­jot grafisko saskarni. Lietotāja ievadītā in­for­mā­ci­ja tiek tieši nosūtīta vietējam aģentam, iz­man­to­jot Panamax API. Panamax lietotāja saskarne ir balstīta uz CTL Base UI Kit, kas ir Cen­turyLink iz­strā­dā­ta UI kom­po­nen­tu bib­lio­tē­ka tīmekļa pro­jek­tiem.

Panamax ter­mi­no­lo­ģi­jā katrs Docker klastera mezgls, kuram nav uz­tu­rē­ša­nas uzdevumu, tiek saukts par attālo iz­vie­to­ša­nas mērķi. Iz­vie­to­ša­nas mērķi sastāv no Docker uz­ņē­mēj­da­to­ra, kas ir kon­fi­gu­rēts, lai izvietotu Panamax veidnes, iz­man­to­jot šādus kom­po­nen­tus:

  • Ie­vie­ša­nas mērķa in­sta­lē­tājs: ie­vie­ša­nas mērķa in­sta­lē­tājs palaista Docker uz­ņē­mēj­da­to­ru, kurā jau ir instalēts Panamax attālais aģents un or­ķes­trā­ci­jas adapteris.
  • Panamax attālais aģents: ja ir instalēts Panamax attālais aģents, lie­to­jum­prog­ram­mas var izplatīt caur vietējo Panamax klientu uz jebkuru vēlamo ga­la­pun­ktu klasterī. Panamax attālais aģents darbojas kā Docker kon­tei­ners katrā iz­vie­to­ša­nas mērķī klasterī.
  • Panamax or­ķes­trā­ci­jas adapteris: or­ķes­trā­ci­jas adapterī prog­ram­mas loģika tiek no­dro­ši­nā­ta katram Panamax pieejamam or­ķes­trā­ci­jas rīkam ne­at­ka­rī­gā adaptera slānī. Tādēļ lie­to­tā­jiem ir iespēja vienmēr iz­vē­lē­ties tieši to or­ķes­trā­ci­jas teh­no­lo­ģi­ju, ko atbalsta viņu mērķa vide. Iepriekš kon­fi­gu­rē­tie adapteri ietver Ku­ber­ne­tes un Fleet:
  • Panamax Ku­ber­ne­tes adapteris: kopā ar Panamax attālo aģentu Panamax Ku­ber­ne­tes adapteris ļauj izplatīt Panamax veidnes Ku­ber­ne­tes klasteros.
  • Panamax Fleet adapteris: kopā ar Panamax attālo aģentu Panamax Fleet adapteris ļauj izplatīt Panamax veidnes klasteros, kurus pārvalda ar Fleet klasteru pār­val­dnie­ka palīdzību.

Šajā attēlā parādīta atsevišķo Panamax kom­po­nen­tu mi­jie­dar­bī­ba Docker klasterī:

Image: Schematic representation of the software architecture for the Panamax container management tool
The software archi­tectu­re of the Panamax container ma­nage­ment tool

Uz CoreOS bal­stī­tais kon­tei­ne­ru pār­val­dī­bas rīks „Panamax“ lie­to­tā­jiem grafiskās lietotāja saskarnes vidē piedāvā dažādas standarta kon­tei­ne­ru koor­di­nē­ša­nas teh­no­lo­ģi­jas, kā arī iespēju ērti pārvaldīt sa­rež­ģī­tas daudzkon­tei­ne­ru lie­to­jum­prog­ram­mas klastera ar­hi­tek­tū­rās, iz­man­to­jot jebkuru sistēmu (piemēram, savu portatīvo datoru).

Iz­man­to­jot „Panamax“ publisko veidņu krātuvi, „Panamax“ lie­to­tā­jiem caur GitHub ir pieejama publiska veidņu bib­lio­tē­ka ar dažādiem resursiem.

Dronis

Drone ir vienkārša ne­pār­trauk­tas in­teg­rā­ci­jas platforma ar minimālām prasībām. Ar šo Docker rīku varat au­to­mā­tis­ki le­ju­pie­lā­dēt savu jaunāko kom­pi­lā­ci­ju no Git re­po­zi­to­ri­ja, piemēram, GitHub, un to testēt izolētos Docker kon­tei­ne­ros. Varat palaist jebkuru testu kopumu un nosūtīt atskaites un statusa ziņojumus pa e-pastu. Katram prog­ram­ma­tū­ras testam tiek izveidots jauns kon­tei­ners, kas balstās uz attēliem no publiskā Docker reģistra. Tas nozīmē, ka jebkuru publiski pieejamu Docker attēlu var izmantot kā vidi koda tes­tē­ša­nai.

Drone ir integrēts Docker vidē un to atbalsta dažādas prog­ram­mē­ša­nas valodas, piemēram, PHP, Node.js, Ruby, Go un Python. Vienīgā patiesa atkarība ir kon­tei­ne­ru platforma. Ar Drone jūs varat izveidot savu personīgo ne­pār­trauk­tas in­teg­rā­ci­jas platformu jebkurā sistēmā, kurā var instalēt Docker. Drone atbalsta dažādus versiju kontroles re­po­zi­to­ri­jus, un pamācību standarta in­sta­lā­ci­jai ar GitHub in­teg­rā­ci­ju varat atrast atvērtā koda projekta tīmekļa vietnē readme.drone.io.

Ne­pār­trauk­tas in­teg­rā­ci­jas plat­for­mas pār­val­dī­ba notiek, iz­man­to­jot tīmekļa saskarni. Šeit varat ielādēt prog­ram­ma­tū­ras versijas no jebkura Git re­po­zi­to­ri­ja, apvienot tās ar lie­to­jum­prog­ram­mām un palaist rezultātu iepriekš definētā tes­tē­ša­nas vidē. Lai to izdarītu, tiek definēts .drone.yml fails, kurā norādīts, kā izveidot un palaist lie­to­jum­prog­ram­mu katram prog­ram­ma­tū­ras testam.

Dronu lie­to­tā­jiem tiek piedāvāts atvērtā koda CI ri­si­nā­jums, kas apvieno tādu al­ter­na­tī­vo produktu kā „Travis“ un „Jenkins“ priekš­ro­cī­bas vienā lie­to­tā­jam draudzīgā lie­to­jum­prog­ram­mā.

OpenStack

Runājot par atvērtā koda mā­koņstruk­tū­ru izveidi un eks­plua­tā­ci­ju, atvērtā koda mā­ko­ņo­pe­rē­tājsis­tē­ma OpenStack ir vis­pie­mē­ro­tā­kais prog­ram­ma­tū­ras ri­si­nā­jums.

Iz­man­to­jot OpenStack, varat pārvaldīt datoru, datu uz­gla­bā­ša­nas un tīkla resursus no centrālās vadības paneļa un no­dro­ši­nāt to pie­eja­mī­bu ga­la­lie­to­tā­jiem, iz­man­to­jot tīmekļa saskarni.

Mā­koņ­da­to­ša­nas ope­rē­tājsis­tē­ma balstās uz modulāru ar­hi­tek­tū­ru, kas sastāv no vairākiem kom­po­nen­tiem:

  • Zun (kon­tei­ne­ru pa­kal­po­jums): Zun ir OpenStack kon­tei­ne­ru pa­kal­po­jums, kas nodrošina vienkāršu kon­tei­ne­ri­zē­tu lie­to­jum­prog­ram­mu iz­vie­to­ša­nu un pār­val­dī­bu OpenStack mākonī. Zun mērķis ir ļaut lie­to­tā­jiem pārvaldīt kon­tei­ne­rus, iz­man­to­jot REST API, bez ne­pie­cie­ša­mī­bas pārvaldīt serverus vai klasterus. Lai darbotos Zun, jums būs ne­pie­cie­ša­mi trīs citi OpenStack pa­kal­po­ju­mi, kas ir Keystone, Neutron un kryr-libnetwork. Zun fun­kcio­na­li­tā­ti var pa­pla­ši­nāt arī ar papildu OpenStack pa­kal­po­ju­miem, piemēram, Cinder un Glance.
  • Neutron (tīkla kom­po­nen­te): Neutron (formāli Quantum) ir pārnesama, mē­ro­go­ja­ma API at­bal­stī­ta sistēmas kom­po­nen­te, ko izmanto tīkla kontrolei. Modulis nodrošina saskarni sa­rež­ģī­tām tīkla to­po­lo­ģi­jām un atbalsta dažādus spraudņus, ar kuru palīdzību var integrēt pa­pla­ši­nā­tas tīkla funkcijas.
  • kuryr-libnetwork (Docker draiveris): kuryr-libnetwork ir draiveris, kas darbojas kā saskarnes starp Docker un Neutron.
  • Cinder (bloku uz­gla­bā­ša­na): Cinder ir OpenStack ar­hi­tek­tū­ras kom­po­nen­ta nosaukums, kas nodrošina pastāvīgu bloku uz­gla­bā­ša­nu virtuālo mašīnu darbībai. Modulis nodrošina virtuālo uz­gla­bā­ša­nu, iz­man­to­jot pa­šap­kal­po­ša­nās API. Tādējādi gala lietotāji var izmantot uz­gla­bā­ša­nas resursus, nezinot, kura ierīce nodrošina uz­gla­bā­ša­nu.
  • Keystone (iden­ti­tā­tes pa­kal­po­jums): Keystone nodrošina OpenStack lie­to­tā­jiem cen­tra­li­zē­tu iden­ti­tā­tes pa­kal­po­ju­mu. Modulis darbojas kā au­ten­ti­fi­kā­ci­jas un atļauju sistēma starp at­se­viš­ķām OpenStack sa­stāv­da­ļām. Piekļuvi pro­jek­tiem mākonī regulē nomnieki. Katrs nomnieks pārstāv lietotāju, un var definēt vairākus lietotāju piekļuves ar at­šķi­rī­gām tiesībām.
  • Glance (attēlu pa­kal­po­jums): ar Glance moduli OpenStack nodrošina pa­kal­po­ju­mu, kas ļauj uzglabāt un izgūt virtuālo mašīnu attēlus.

Vairāk in­for­mā­ci­jas par OpenStack kom­po­nen­tiem un pa­kal­po­ju­miem varat atrast mūsu rakstā par OpenStack.

Papildus iepriekš minētajām sa­stāv­da­ļām OpenStack ar­hi­tek­tū­ru var pa­pla­ši­nāt, iz­man­to­jot dažādus moduļus. Par dažādiem papildu moduļiem varat lasīt OpenStack tīmekļa vietnē.

D2iQ DC/OS

DC/OS (Dis­tri­bu­ted Cloud Operating System) ir atvērtā koda prog­ram­ma­tū­ra iz­klie­dē­tu sistēmu darbībai, ko iz­strā­dā­ju­si D2iQ Inc. (iepriekš Me­sosphe­re). Projekts balstās uz atvērtā koda klastera pār­val­dnie­ku Apache Mesos un ir ope­rē­tājsis­tē­ma datu centriem. Avota kods lie­to­tā­jiem ir pieejams saskaņā ar Apache licences 2. versiju DC/OS re­po­zi­to­ri­jos GitHub vietnē. Prog­ram­ma­tū­ras uzņēmumu versija ir pieejama arī vietnē d2iq.com. Plaša projekta do­ku­men­tā­ci­ja ir atrodama vietnē dcos.io.

DC/OS var uzskatīt par Mesos dis­tri­bū­ci­ju, kas nodrošina visas klastera pār­val­dnie­ka funkcijas (iz­man­to­jot centrālo lietotāja saskarni) un ie­vē­ro­ja­mi paplašina Mesos iespējas.

DC/OS izmanto Mesos plat­for­mas iz­klie­dē­to sistēmu kodolu. Tas ļauj apvienot visa datu centra resursus un pārvaldīt tos kā vienotu sistēmu, piemēram, vienu loģisko serveri. Tādējādi jūs varat vadīt veselas fizisko vai virtuālo mašīnu kopas tikpat viegli, kā jūs darītu ar vienu datoru.

Šī prog­ram­ma­tū­ra vienkāršo iz­klie­dē­tu lie­to­jum­prog­ram­mu in­sta­lē­ša­nu un pār­val­dī­bu, kā arī au­to­ma­ti­zē tādas darbības kā resursu pār­val­dī­ba, plānošana un procesu sav­star­pē­jā saziņa. Uz D2iQ DC/OS balstīta klastera pār­val­dī­ba, kā arī tajā iekļauto pa­kal­po­ju­mu pār­val­dī­ba notiek, iz­man­to­jot centrālo ko­man­drin­das programmu (CLI) vai tīmekļa saskarni (GUI).

DC/OS izolē klastera resursus un nodrošina kop­lie­to­ša­nas pa­kal­po­ju­mus, piemēram, pa­kal­po­ju­mu atklāšanu vai pakotņu pār­val­dī­bu. Prog­ram­ma­tū­ras galvenās sa­stāv­da­ļas darbojas aiz­sar­gā­tā vidē – kodola vidē. Tajā ietilpst Mesos plat­for­mas galvenā programma un aģentu prog­ram­mas, kas atbild par resursu sadali, procesu izolāciju un drošības funkcijām.

  • Mesos galvenais mezgls: Mesos galvenais mezgls ir galvenais process, kas darbojas galvenajā mezglā. Mesos galvenā mezgla uzdevums ir pārvaldīt resursus un koordinēt uzdevumus (abs­trak­ci­jas darba vienības), kas tiek izpildīti aģenta mezglā. Lai to paveiktu, Mesos galvenais mezgls sadala resursus re­ģis­trē­ta­jiem DC/OS pa­kal­po­ju­miem un pieņem resursu atskaites no Mesos aģentiem.
  • Mesos aģenti: Mesos aģenti ir procesi, kas darbojas aģentu kontos un ir atbildīgi par galvenā procesa sadalīto uzdevumu izpildi. Mesos aģenti regulāri nosūta ziņojumus par klasterī pie­eja­ma­jiem resursiem Mesos gal­ve­na­jam procesam. Mesos galvenais process tos pārsūta plā­no­tā­jam (piemēram, Marathon, Chronos vai Cassandra). Tas izlemj, kurš uzdevums jāizpilda uz kura mezgla. Pēc tam uzdevumi tiek izpildīti izolētā veidā kon­tei­ne­rā.

Visas pārējās sistēmas sa­stāv­da­ļas, kā arī lie­to­jum­prog­ram­mas, kuras Mesos aģenti palaist ar iz­pil­dī­tā­ja palīdzību, darbojas lietotāja vidē. Standarta DC/OS in­sta­lā­ci­jas pa­ma­te­le­men­ti ir ad­mi­nis­tra­to­ra mar­šru­tē­tājs, Mesos DNS, iz­klie­dē­tais DNS star­pniek­ser­ve­ris, slodzes iz­lī­dzi­nā­tājs Minuteman, plānotājs Marathon, Apache ZooKeeper un Exhibitor.

  • Ad­mi­nis­tra­to­ra mar­šru­tē­tājs: ad­mi­nis­tra­to­ra mar­šru­tē­tājs ir īpaši kon­fi­gu­rēts tīmekļa serveris, kas balstās uz NGINX un nodrošina DC/OS pa­kal­po­ju­mus, kā arī centrālās au­ten­ti­fi­kā­ci­jas un star­pniek­ser­ve­ra funkcijas.
  • Mesos DNS: sistēmas kom­po­nents Mesos DNS nodrošina pa­kal­po­ju­mu at­klā­ša­nas funkcijas, kas ļauj at­se­viš­ķiem pa­kal­po­ju­miem un lie­to­jum­prog­ram­mām klasterī iden­ti­fi­cēt viens otru, iz­man­to­jot centrālo domēna vārdu sistēmu (DNS).
  • Dis­tri­bu­ted DNS proxy: iz­klie­dē­tais DNS star­pniek­ser­ve­ris ir iekšējais DNS dispečers.
  • Minuteman: sistēmas kom­po­nents Minuteman darbojas kā iekšējais slodzes ba­lan­sē­tājs, kas strādā OSI atsauces modeļa trans­por­ta slānī (4. slānis).
  • DC/OS Marathon: Marathon ir Mesos plat­for­mas centrālā sa­stāv­da­ļa, kas D2iQ DC/OS darbojas kā init sistēma (līdzīgi kā systemd). Marathon uzsāk un uzrauga DC/OS pa­kal­po­ju­mus un lie­to­jum­prog­ram­mas klastera vidēs. Turklāt prog­ram­ma­tū­ra nodrošina augstas pie­eja­mī­bas funkcijas, pa­kal­po­ju­mu atklāšanu, slodzes iz­lī­dzi­nā­ša­nu, darbības pārbaudes un grafisko tīmekļa saskarni.
  • Apache ZooKeeper: Apache ZooKeeper ir atvērtā koda prog­ram­ma­tū­ras kom­po­nents, kas nodrošina koor­di­nā­ci­jas funkcijas lie­to­jum­prog­ram­mu darbībai un kontrolei iz­klie­dē­tās sistēmās. ZooKeeper tiek izmantots D2iQ DC/OS, lai koor­di­nē­tu visus in­sta­lē­tos sistēmas pa­kal­po­ju­mus.
  • Exhibitor: Exhibitor ir sistēmas kom­po­nents, kas tiek au­to­mā­tis­ki instalēts un kon­fi­gu­rēts kopā ar ZooKeeper katrā galvenajā mezglā. Exhibitor nodrošina arī grafisko lietotāja saskarni ZooKeeper lie­to­tā­jiem.

Ar DC/OS ap­vie­no­ta­jos klastera resursos vien­lai­kus var izpildīt dažādas darba slodzes. Tas, piemēram, ļauj paralēli darboties liela apjoma datu sistēmām, mik­ro­ser­vi­siem vai kon­tei­ne­ru plat­for­mām, piemēram, Hadoop, Spark un Docker, klastera ope­rē­tājsis­tē­mā.

D2iQ Universe vidē DC/OS lie­to­tā­jiem ir pieejams publisks lietotņu katalogs. Tādējādi jūs varat instalēt tādus rīkus kā Spark, Cassandra, Chronos, Jenkins vai Kafka, vienkārši no­klik­šķi­not uz grafiskās lietotāja saskarnes.

Kādi Docker rīki ir pieejami drošības no­dro­ši­nā­ša­nai?

Lai gan kon­tei­ne­ros dar­bo­jo­šies izolētie procesi izmanto vienu un to pašu kodolu, Docker izmanto vairākas metodes, lai tos sav­star­pē­ji izolētu. Parasti šim nolūkam tiek iz­man­to­tas Linux kodola pa­matfun­kci­jas, piemēram, Cgroups un Na­mes­pa­ces.

Tomēr kon­tei­ne­ri joprojām ne­nod­ro­ši­na tādu pašu iz­olā­ci­jas līmeni, kādu var panākt, iz­man­to­jot virtuālās mašīnas. Ne­ska­to­ties uz iz­olā­ci­jas paņēmienu iz­man­to­ša­nu, caur kon­tei­ne­riem ir iespējams piekļūt svarīgām pa­ma­ta­pakš­sis­tē­mām, piemēram, Cgroups, kā arī kodola saskarnēm /sys un /proc di­rek­to­ri­jās.

Docker izstrādes komanda ir atzinusi, ka šīs drošības bažas ir šķērslis kon­tei­ne­ru teh­no­lo­ģi­jas ie­vie­ša­nai ražošanas sistēmās. Papildus Linux kodola pamata iz­olā­ci­jas pa­ņē­mie­niem jaunākās Docker Engine versijas atbalsta arī AppArmor, SELinux un Seccomp sistēmas, kas darbojas kā sava veida ugunsmū­ris gal­ve­na­jiem resursiem.

  • AppArmor: ar AppArmor tiek regulētas kon­tei­ne­ru piekļuves tiesības failu sistēmām.
  • SELinux: SELinux nodrošina sarežģītu re­gu­lē­ša­nas sistēmu, kurā var īstenot piekļuves kontroli gal­ve­na­jiem resursiem.
  • Seccomp: Seccomp (Secure Computing Mode) uzrauga sistēmas izsaukumu izpildi.

Papildus šiem Docker rīkiem Docker izmanto arī Linux iespējas, lai ie­ro­be­žo­tu root tiesības, ar kurām Docker Engine palaista kon­tei­ne­rus.

Pastāv arī citas drošības bažas saistībā ar prog­ram­ma­tū­ras ie­vai­no­ja­mī­bām lie­to­jum­prog­ram­mu kom­po­nen­tēs, kuras izplata Docker reģistrs. Tā kā būtībā ikviens var izveidot Docker attēlus un padarīt tos publiski pieejamus kopienai Docker Hub vietnē, pastāv risks, ka , le­ju­pie­lā­dē­jot attēlu, jūsu sistēmā var tikt ievadīts ļaun­prā­tīgs kods. Pirms lie­to­jum­prog­ram­mas ie­vie­ša­nas Docker lie­to­tā­jiem jā­pār­lie­ci­nās, ka viss attēlā ie­kļau­tais kods kon­tei­ne­ru izpildei nāk no uzticama avota.

Docker piedāvā ve­ri­fi­kā­ci­jas programmu, ko prog­ram­ma­tū­ras iz­strā­dā­tā­ji var izmantot, lai pār­bau­dī­tu un ve­ri­fi­cē­tu savus Docker attēlus. Ar šo ve­ri­fi­kā­ci­jas programmu Docker vēlas atvieglot iz­strā­dā­tā­jiem drošu prog­ram­ma­tū­ras piegādes ķēžu izveidi saviem pro­jek­tiem. Papildus lietotāju drošības uz­la­bo­ša­nai programma ir paredzēta, lai prog­ram­ma­tū­ras iz­strā­dā­tā­jiem sniegtu iespēju atšķirt savus projektus no dau­dza­jiem citiem pie­eja­ma­jiem resursiem. Ve­ri­fi­cē­tie attēli tiek atzīmēti ar Verified Publisher zīmi un, papildus citām priekš­ro­cī­bām, saņem augstāku vietu Docker Hub mek­lē­ša­nas re­zul­tā­tos.

Go to Main Menu