# Kādi ir labākie Docker rīki? Pārskats

Plašā Docker ekosistēma piedāvā izstrādātājiem virkni iespēju lietojumprogrammu izvietošanai, konteineru koordinēšanai un citām darbībām. Mēs apskatīsim svarīgākos Docker rīkus un sniegsim pārskatu par populārākajiem trešo pušu projektiem, kas izstrādā atvērtā koda Docker rīkus.

## Kādi ir galvenie Docker rīki un komponenti?

Mūsdienās Docker ir daudz vairāk nekā tikai sarežģīta platforma programmatūras konteineru pārvaldībai. Izstrādātāji ir radījuši **virkni dažādu Docker rīku**, lai lietojumprogrammu ieviešanu izkliedētā infrastruktūrā un mākoņvidē padarītu vienkāršāku, ātrāku un elastīgāku. Papildus rīkiem klasterizācijai un orķestrēšanai ir pieejams arī centrālais lietojumprogrammu tirgus un rīks mākoņresursu pārvaldībai.

### Docker dzinējs

Kad programmētāji runā par „Docker”, viņi parasti domā atvērtā koda **klientu-servera lietojumprogrammu, kas**veido konteineru platformas pamatu. Šo lietojumprogrammu sauc par Docker Engine. Docker Engine galvenās sastāvdaļas ir **Docker dēmons**, REST API un **CLI (komandrindas interfeiss)**, kas kalpo kā lietotāja interfeiss.

Pateicoties šai uzbūvei, jūs varat sazināties ar Docker Engine, izmantojot komandrindas komandas, un ērti pārvaldīt Docker attēlus, Docker failus un Docker konteinerus no termināļa.

[![Image: Schematic representation of the Docker engine](https://www.ionos.com/lv-lv/digitalguide/fileadmin/_processed_/b/1/csm_schematic-representation-of-the-docker-engine_b1d06acafa.webp "Schematic representation of the Docker engine")](https://www.ionos.com/lv-lv/digitalguide/fileadmin/DigitalGuide/Schaubilder/schematic-representation-of-the-docker-engine.png) The main components 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ā iesācējiem** [„Docker pamācība: instalēšana un pirmie soļi](https://www.ionos.com/lv-lv/digitalguide/serveris/konfiguracija/docker-pamaciba-instalesana-un-pirmie-soli/)“.

### Docker Hub

Docker Hub nodrošina lietotājiem **mākonī bāzētu reģistru**, kas ļauj lejupielādēt Docker attēlus, tos centralizēti pārvaldīt un dalīties ar citiem Docker lietotājiem. Reģistrētie lietotāji var glabāt Docker attēlus publiskos vai privātos repozitorijos. Publiska attēla lejupielādei (Docker terminoloģijā saukta par *„pulling“* ) nav nepieciešams lietotāja konts. Integrētais tagu mehānisms ļauj veikt attēlu versiju pārvaldību.

Papildus citu Docker lietotāju publiskajiem repozitorijiem Docker Hub **oficiālajos repozitorijos** ir pieejami arī daudzi resursi no Docker izstrādātāju komandas un pazīstamiem atvērtā koda projektiem. Populārākie Docker attēli ietver NGINX tīmekļa serveri, Redis atmiņas datubāzi, BusyBox Unix rīku komplektu un Ubuntu Linux distributīvu.

[![Image: Official repositories in the Docker node](https://www.ionos.com/lv-lv/digitalguide/fileadmin/_processed_/1/7/csm_docker-hub-repositories_857d775687.webp "Official repositories in the Docker node")](https://www.ionos.com/lv-lv/digitalguide/fileadmin/DigitalGuide/Screenshots_2023/docker-hub-repositories.png) You can find more than 100,000 free images in the official Docker repositories. **Organizācijas** ir vēl viena svarīga Docker Hub funkcija, kas ļauj Docker lietotājiem izveidot privātus repozitorijus, kuri ir pieejami tikai izvēlētai cilvēku grupai. Piekļuves tiesības organizācijā tiek pārvaldītas, izmantojot **komandas un dalību grupās**.

### Docker Swarm

Docker Engine ietver iebūvētu funkciju, kas ļauj lietotājiem **pārvaldīt Docker hostus klasteros, kurus** sauc par swarms. Docker Engine iebūvētās klasteru pārvaldības un koordinācijas iespējas balstās uz [Swarmkit rīku kopumu](https://github.com/docker/swarmkit "Swarmkit toolbox on github.com"). Ja izmantojat vecāku konteineru platformas versiju, Docker rīks ir **pieejams kā atsevišķa lietojumprogramma**.

Tip Klasteri sastāv no jebkura skaita Docker serveru un tiek izvietoti ārēja IaaS pakalpojumu sniedzēja infrastruktūrā vai pašu datu centrā.

Kā **Docker klāsterizācijas 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ā. Izmantojot Docker Engine CLI, lietotāji var izveidot swarmus, izvietot lietojumprogrammas klāsterī un pārvaldīt swarma darbību **, neizmantojot papildu orķestrācijas programmatūru**.

Docker dzinēji, kas apvienoti klasteros, darbojas **swarm režīmā**. Izvēlieties šo opciju, ja vēlaties izveidot jaunu klasteri vai pievienot Docker resursu esošajam swarm. Atsevišķ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ņbalstīta arhitektūra, kurā atsevišķie Docker swarm mezgli ir izkliedēti pa dažādām sistēmām un infrastruktūrām.

Programmatūra balstās uz „master-worker“ arhitektūru. Kad uzdevumi ir jāsadala „Swarm“ vidē, lietotāji nosūta pakalpojumu vadības mezglam. Vadības mezgls pēc tam atbild par **konteineru plānošanu klasterī** un kalpo kā galvenā lietotāja saskarne, lai piekļūtu „Swarm“ resursiem.

Pārvaldnieka mezgls nosūta atsevišķas vienības, ko sauc par uzdevumiem, darba mezgliem.

- **Pakalpojumi:** pakalpojumi ir Docker klasteru centrālās struktūras. Pakalpojums definē uzdevumu, kas jāizpilda Docker klasterī. Pakalpojums attiecas uz konteineru grupu, kas balstās uz vienu un to pašu attēlu. Izveidojot pakalpojumu, lietotājs norāda, kurš attēls un kādas komandas tiek izmantotas. Turklāt pakalpojumi piedāvā iespēju mērogot lietojumprogrammas. Docker platformas lietotāji vienkārši nosaka, cik daudz konteineru jāpalaiž konkrētajam pakalpojumam.
- **Uzdevumi**: lai izplatītu pakalpojumus klasterī, pārvaldnieka mezgls tos sadala atsevišķās darba vienībās (uzdevumos). Katrs uzdevums ietver Docker konteineru, kā arī komandas, kas tajā tiek izpildītas.

Papildus klastera pārvaldībai un konteineru koordinēšanai pārvaldības mezgli pēc noklusējuma var pildīt arī darba mezglu funkcijas – ja vien jūs šo mezglu uzdevumus neierobežojat tikai ar pārvaldību.

Katrā darba mezglā darbojas **aģenta programma**. Tā pieņem uzdevumus un nosūta attiecīgajam galvenajam mezglam statusa ziņojumus par nodotā uzdevuma izpildes gaitu. Turpmākajā attēlā redzams Docker Swarm shematisks attēlojums:

[![Image: Schematic representation of a Docker Swarm](https://www.ionos.com/lv-lv/digitalguide/fileadmin/_processed_/5/8/csm_schematic-representation-of-a-docker-swarm_35226c9b62.webp "Schematic representation of a Docker Swarm")](https://www.ionos.com/lv-lv/digitalguide/fileadmin/DigitalGuide/Schaubilder/schematic-representation-of-a-docker-swarm.png) The manager-worker architecture 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 konteinerus** un tos palaist ar vienu komandu. Compose pamatelements ir centrālais konfigurācijas fails, kas balstās uz atzīto YAML valodu. Šī Compose faila sintakse ir līdzīga atvērtā koda programmatūras Vagrant sintaksei, ko izmanto virtuālo mašīnu izveidei un konfigurēšanai.

Failā *`docker-compose.yml`* var definēt neierobežotu skaitu programmatūras konteineru, ieskaitot visas atkarības, kā arī to savstarpējās saistības. Šādas daudzkonteineru lietojumprogrammas tiek pārvaldītas pēc tā paša principa kā atsevišķi programmatūras konteineri. Lai pārvaldītu lietojumprogrammas pilnu dzīves ciklu, izmantojiet **komandu*`docker-compose`*\*\* kopā ar vajadzīgo apakškommandu.

Šo Docker rīku var viegli integrēt **klasterī, kas balstās uz Swarm**. Tādējādi ar Compose izveidotas daudzkontaineru lietojumprogrammas varat palaist izkliedē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ērogošanas mehānisms**. Izmantojot šo koordinēšanas rīku, varat ērti izmantot komandrindas programmu, lai noteiktu, cik daudz konteineru vēlaties palaist konkrētajam pakalpojumam.

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

Papildus Docker Inc. iekšēji izstrādātajiem risinājumiem pastāv dažādi **ārējo piegādātāju programmatūras rīki un platformas**, kas nodrošina saskarnes ar Docker Engine vai ir speciāli izstrādātas šai populārajai konteineru platformai. Docker ekosistēmā **populārākie atvērtā koda projekti** ir orķestrācijas rīks Kubernetes, klastera pārvaldības rīks Shipyard, daudzkontaineru pārvadājumu risinājums Panamax, nepārtrauktas integrācijas platforma Drone, mākonis balstīta operētājsistēma OpenStack un datu centra operētājsistēma D2iQ DC/OS, kas balstās uz klastera pārvaldnieku Mesos.

### Kubernetes

Docker ne vienmēr spēj piedāvāt savus **orķestrācijas 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 pielāgotus rīkus, kas paredzēti konteineru platformas darbības atvieglošanai lielās, izkliedētās infrastruktūrās. Viens no populārākajiem šāda veida risinājumiem ir atvērtā koda projekts Kubernetes.

Kubernetes ir **klastera pārvaldnieks konteineru bāzētām lietojumprogrammām**. Kubernetes mērķis ir automatizēt lietojumprogrammu darbību klasterī. Lai to panāktu, šis koordinācijas rīks kā vadības saskarnes izmanto REST-API, komandrindas programmu un **grafisko tīmekļa saskarni**. Izmantojot šīs saskarnes, var uzsākt automatizācijas procesus un pieprasīt statusa ziņojumus. Kubernetes var izmantot, lai:

- izpildīt konteineru bāzētas programmas klasterī,
- instalēt un pārvaldīt lietojumprogrammas izkliedētās sistēmās,
- mērogu pielāgot lietojumprogrammām un
- izmantot aparatūru pēc iespējas efektīvāk.

Šim nolūkam Kubernetes apvieno konteinerus loģiskās vienībās, kuras sauc par podiem. Podi ir klastera pārvaldnieka pamatvienības, kuras, izmantojot plānošanu, var izvietot klasterī.

Tāpat kā Docker Swarm, arī Kubernetes balstās uz **„master-worker“ arhitektūru**. Klasteris sastāv no Kubernetes galvenā servera un dažādiem darba serveriem, kurus sauc arī par Kubernetes mezgliem (vai minioniem). Kubernetes galvenais serveris darbojas kā centrālā vadības platforma klasterī un sastāv no četriem pamata komponentiem, kas nodrošina tiešu komunikāciju klasterī un uzdevumu sadali. Kubernetes galvenais serveris sastāv no API servera, konfigurācijas atmiņas etcd, plānotāja un kontrolieru pārvaldnieka.

- **API serveris:** visas automatizācijas darbības Kubernetes klasterī tiek uzsāktas, izmantojot REST-API caur API serveri. Tas darbojas kā centrālā administrēšanas saskarne klasterī.
- **etcd:** atvērtā koda konfigurācijas atmiņu *etcd* var uzskatīt par Kubernetes klastera atmiņu. Key Value Store, ko CoreOS izstrādāja īpaši izkliedētām sistēmām, uzglabā konfigurācijas datus un padara tos pieejamus katram klastera mezglam. Klastera pašreizējo stāvokli var pārvaldīt jebkurā brīdī, izmantojot *etcd*.
- **Plānotājs:** plānotājs ir atbildīgs par konteineru grupu (pod) sadali klasterī. Tas nosaka poda resursu prasības un pēc tam tās saskaņo ar pieejamajiem resursiem atsevišķos klastera mezglos.
- **Controller manager:** controller manager ir Kubernetes master pakalpojums, kas kontrolē orķestrēšanu, regulējot klastera stāvokli un veicot rutīnas uzdevumus. Controller manager galvenais uzdevums ir nodrošināt, ka klastera stāvoklis atbilst definētajam mērķa stāvoklim.

Kubernetes galvenā servera visus komponentus var izvietot vienā serverī vai sadalīt pa vairākiem galvenajiem serveriem augstas pieejamības klasterī.

Lai gan Kubernetes galvenais mezgls atbild par koordinēšanu, klasterī izvietotie podi darbojas uz resursu serveriem — Kubernetes mezgliem, kas ir pakļauti galvenajam mezglam. Lai to nodrošinātu, katrā Kubernetes mezglā ir jādarbojas konteineru dzinējam. Lai gan Docker ir de facto standarts, Kubernetes **nav obligāti jāizmanto konkrēts konteineru dzinējs**.

Papildus konteineru dzinējam Kubernetes mezgli ietver šādus komponentus:

- **kubelet:** *kubelet* ir aģents, kas darbojas katrā Kubernetes mezglā un tiek izmantots mezgla kontrolei un pārvaldībai. Kā katra mezgla galvenais saskarnes punkts, *kubelet* ir savienots ar Kubernetes galveno serveri un nodrošina informācijas nosūtīšanu uz vadības līmeni un saņemšanu no tā.
- **kube-proxy:** papildus tam katrā Kubernetes mezglā darbojas starpniekserviss *kube-proxy*. Tas nodrošina, ka pieprasījumi no ārpuses tiek pārsūtīti uz attiecīgajiem konteineriem, un sniedz pakalpojumus konteineru bāzētu lietojumprogrammu lietotājiem. *Kube-proxy* piedāvā arī pamata līmeņa [slodzes izlīdzināšanu](https://www.ionos.com/lv-lv/digitalguide/serveris/prasmes-un-zinasanas/slodzes-izlidzinataji-serveru-slodzes-sadale/).

Šajā attēlā ir parādīts galvenā mezgla arhitektūras shematisks attēlojums, uz kura balstās orķestrācijas platforma Kubernetes:

[![Image: Schematic representation of the Kubernetes architecture](https://www.ionos.com/lv-lv/digitalguide/fileadmin/_processed_/4/b/csm_schematic-representation-of-the-kubernetes-architecture_b06c1dc6c7.webp "Schematic representation of the Kubernetes architecture")](https://www.ionos.com/lv-lv/digitalguide/fileadmin/DigitalGuide/Schaubilder/schematic-representation-of-the-kubernetes-architecture.png) The master-node architecture of the orchestration platform Kubernetes Papildus galvenajam Kubernetes projektam ir pieejami arī **daudzi rīki un paplašinājumi**, kas ļauj paplašināt šīs orķestrācijas platformas funkcionalitāti. Populārākie no tiem ir uzraudzības un kļūdu diagnostikas rīki [Prometheus](https://prometheus.io/ "Prometheus – Monitoring system & time series database"), [Weave Scope](https://www.weave.works/oss/scope/ "Weave Scope website") un [sysdig](https://www.sysdig.com/ "sysdig – Container Troubleshooting and Linux Visibility"), kā arī pakotņu pārvaldnieks [Helm](http://localhost/ "Helm – The Kubernetes Package Manager"). Ir pieejami arī spraudņi [Apache Maven](https://maven.apache.org/ "Apache Maven Project website") un [Gradle](https://gradle.org/ "Gradle website"), kā arī Java API, kas ļauj attālināti vadīt Kubernetes.

### Kuģu būvētava

Shipyard ir kopienas izstrādāts **pārvaldības risinājums, kas balstās uz Swarm** un ļauj lietotājiem uzturēt Docker resursus, piemēram, konteinerus, attēlus, hostus un privātos reģistrus, izmantojot grafisko lietotāja saskarni. Tas ir pieejams kā tīmekļa lietojumprogramma, ko **var** izmantot ar pārlūku. Papildus **klastera pārvaldības funkcijām, kas ir pieejamas caur centrālo tīmekļa saskarni**, Shipyard piedāvā arī lietotāju autentifikāciju un uz lomām balstītu piekļuves kontroli.

Programmatū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 notikumiem. Programmatūra balstās uz klastera pārvaldības rīku kopumu Citadel un sastāv no trim galvenajām sastāvdaļām: kontrolieris, API un lietotāja saskarne.

- **Shipyard kontrolieris:** kontrolieris ir pārvaldības rīka Shipyard galvenā sastāvdaļa. Shipyard kontrolieris mijiedarbojas ar RethinkDB, lai uzglabātu datus, un ļauj adresēt atsevišķus hostus Docker klasterī, kā arī kontrolēt notikumus.
- **Shipyard API:** Shipyard API ir balstīts uz REST. Visas pārvaldības rīka funkcijas tiek kontrolētas ar Shipyard API starpniecību.
- **Shipyard lietotāja saskarne (UI):** Shipyard UI ir AngularJS lietotne, kas lietotājiem piedāvā grafisko lietotāja saskarni Docker klasteru pārvaldībai tīmekļa pārlūkprogrammā. Visas mijiedarbības lietotāja saskarnē notiek, izmantojot Shipyard API.

Papildu informācija par šo atvērtā koda projektu ir pieejama [Shipyard oficiālajā tīmekļa vietnē](https://shipyard-project.com/ "Shipyard project website").

### Panamax

Atvērtā koda programmatūras projekta [„Panamax“](https://github.com/CenturyLinkLabs/panamax-ui/wiki "Panamax page on GitHub") izstrādātāju mērķis ir vienkāršot **daudzkontaineru lietotņu ieviešanu**. Šis bezmaksas rīks piedāvā lietotājiem grafisko lietotāja saskarni, kas ļauj ērti izstrādāt, ieviest un izplatīt sarežģītas lietotnes, kas balstās uz Docker konteineriem, izmantojot „vilk un nomet“ funkciju.

Panamax ļauj saglabāt sarežģītas daudzkonteineru lietojumprogrammas kā lietojumprogrammu veidnes un izplatīt tās klastera arhitektūrās ar vienu klikšķi. Izmantojot integrētu **lietojumprogrammu veikalu**, kas atrodas GitHub vietnē, pašizveidoto lietojumprogrammu veidnes var saglabāt Git repozitorijos un darīt tās pieejamas citiem lietotājiem.

**Panamax arhitektūras galvenās sastāvdaļas** var iedalīt divās grupās: Panamax vietējais klients un jebkurš skaits attālo izvietošanas mērķu.

**Panamax vietējais klients** ir šī Docker rīka galvenā sastāvdaļa. Tas darbojas vietējā sistēmā un ļauj izveidot sarežģītas konteineru bāzētas lietojumprogrammas. Vietējais klients sastāv no šādām sastāvdaļām:

- **CoreOS:** Panamax vietējā klienta instalēšanai kā uzņēmējai sistēmai ir nepieciešama Linux distribūcija CoreOS, kas ir īpaši izstrādāta programmatūras konteineriem. Pēc tam Panamax klients tiek palaists kā Docker konteiners CoreOS vidē. Papildus Docker funkcijām lietotājiem ir pieejamas dažādas CoreOS funkcijas. Starp tām ir, piemēram, Fleet un Journalctl:
- **Fleet:** tā vietā, lai integrētos tieši ar Docker, Panamax klients izmanto klastera pārvaldnieku Fleet, lai koordinētu savus konteinerus. Fleet ir klastera pārvaldnieks, kas kontrolē Linux dēmonu *systemd* datoru klasteros.
- **Journalctl:** Panamax klients izmanto Journalctl, lai pieprasītu žurnāla ziņojumus no Linux sistēmas pārvaldnieka *systemd*.
- **Vietējā klienta instalētājs:** vietējā klienta instalētājs satur visas sastāvdaļas, kas nepieciešamas, lai instalētu Panamax klientu vietējā sistēmā.
- **Panamax vietējais aģents:** vietējā klienta centrālā sastāvdaļa ir vietējais aģents. Tas ir saistīts ar dažādām citām sastāvdaļām un atkarībām, izmantojot Panamax API. Tās ietver vietējo Docker hostu, Panamax lietotāja saskarni, ārējos reģistrus un izvietojuma mērķu attālos aģentus klasterī. Vietējais aģents mijiedarbojas ar šādām programmu saskarnēm vietējā sistēmā, izmantojot Panamax API, lai apmainītos ar informāciju par darbojošām lietojumprogrammām:
- **Docker attālais API:** Panamax meklē attēlus vietējā sistēmā, izmantojot Docker attālo API, un iegūst informāciju par darbojošajiem konteineriem.
- **etcd API:** faili tiek nosūtīti CoreOS Fleet dēmonam, izmantojot *etcd* API.
- **systemd-journal-gatewayd.services:** Panamax iegūst darbojošos pakalpojumu žurnāla izvadi, izmantojot *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, izmantojot Docker reģistra API.
- **GitHub API:** Panamax ielādē veidnes no GitHub repozitorija, izmantojot GitHub API.
- **KissMetrics API:** KissMetrics 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 lietotājiem vadīt Docker rīku, izmantojot grafisko saskarni. Lietotāja ievadītā informācija tiek tieši nosūtīta vietējam aģentam, izmantojot Panamax API. Panamax lietotāja saskarne ir balstīta uz CTL Base UI Kit, kas ir CenturyLink izstrādāta UI komponentu bibliotēka tīmekļa projektiem.

Panamax terminoloģijā katrs Docker klastera mezgls, kuram nav uzturēšanas uzdevumu, tiek saukts par **attālo izvietošanas mērķi**. Izvietošanas mērķi sastāv no Docker uzņēmējdatora, kas ir konfigurēts, lai izvietotu Panamax veidnes, izmantojot šādus komponentus:

- **Ieviešanas mērķa instalētājs:** ieviešanas mērķa instalētājs palaista Docker uzņēmējdatoru, kurā jau ir instalēts Panamax attālais aģents un orķestrācijas adapteris.
- **Panamax attālais aģents:** ja ir instalēts Panamax attālais aģents, lietojumprogrammas var izplatīt caur vietējo Panamax klientu uz jebkuru vēlamo galapunktu klasterī. Panamax attālais aģents darbojas kā Docker konteiners katrā izvietošanas mērķī klasterī.
- **Panamax orķestrācijas adapteris:** orķestrācijas adapterī programmas loģika tiek nodrošināta katram Panamax pieejamam orķestrācijas rīkam neatkarīgā adaptera slānī. Tādēļ lietotājiem ir iespēja vienmēr izvēlēties tieši to orķestrācijas tehnoloģiju, ko atbalsta viņu mērķa vide. Iepriekš konfigurētie adapteri ietver Kubernetes un Fleet:
- **Panamax Kubernetes adapteris:** kopā ar Panamax attālo aģentu Panamax Kubernetes adapteris ļauj izplatīt Panamax veidnes Kubernetes 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ārvaldnieka palīdzību.

Šajā attēlā parādīta atsevišķo Panamax komponentu mijiedarbība Docker klasterī:

[![Image: Schematic representation of the software architecture for the Panamax container management tool](https://www.ionos.com/lv-lv/digitalguide/fileadmin/_processed_/6/8/csm_schematic-representation-of-the-software-architecture-for-the-panamax-container-management-tool_8b61ba12b4.webp "Schematic representation of the software architecture for the Panamax container management tool")](https://www.ionos.com/lv-lv/digitalguide/fileadmin/DigitalGuide/Schaubilder/schematic-representation-of-the-software-architecture-for-the-panamax-container-management-tool.PNG) The software architecture of the Panamax container management tool Uz CoreOS balstītais konteineru pārvaldības rīks „Panamax“ lietotājiem grafiskās lietotāja saskarnes vidē piedāvā dažādas standarta konteineru koordinēšanas tehnoloģijas, kā arī iespēju ērti pārvaldīt sarežģītas daudzkonteineru lietojumprogrammas klastera arhitektūrās, izmantojot jebkuru sistēmu (piemēram, savu portatīvo datoru).

Izmantojot [„Panamax“ publisko veidņu krātuvi](https://github.com/CenturyLinkLabs/panamax-public-templates "Panamax public template repository on GitHub"), „Panamax“ lietotājiem caur GitHub ir pieejama publiska veidņu bibliotēka ar dažādiem resursiem.

### Dronis

[Drone](https://github.com/drone "Drone on GitHub") ir vienkārša **nepārtrauktas integrācijas platforma** ar minimālām prasībām. Ar šo Docker rīku varat automātiski lejupielādēt savu jaunāko kompilāciju no Git repozitorija, piemēram, GitHub, un to testēt izolētos Docker konteineros. Varat **palaist jebkuru testu kopumu** un nosūtīt atskaites un statusa ziņojumus pa e-pastu. Katram programmatūras testam tiek izveidots jauns konteiners, 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 testēšanai.

Tip Nepārtraukta integrācija (CI) ir programmatūras izstrādes process, kurā nesen izstrādātās programmatūras sastāvdaļas — kompilācijas — tiek apvienotas un regulāri palaistas testa vidēs. CI ir stratēģija, kas ļauj efektīvi atklāt un novērst integrācijas kļūdas, kas var rasties, dažādiem izstrādātājiem strādājot kopā.

Drone ir integrēts Docker vidē un to atbalsta dažādas programmēšanas valodas, piemēram, PHP, Node.js, Ruby, Go un [Python](https://www.ionos.co.uk/help/hosting/python/what-is-python/ "What is Python?"). Vienīgā patiesa atkarība ir konteineru platforma. Ar Drone jūs varat izveidot savu personīgo nepārtrauktas integrācijas platformu jebkurā sistēmā, kurā var instalēt Docker. Drone **atbalsta dažādus versiju kontroles repozitorijus**, un pamācību standarta instalācijai ar GitHub integrāciju varat atrast atvērtā koda projekta tīmekļa vietnē [readme.drone.io](http://readme.drone.io/ "Documentation for the Continuous Integration platform Drone").

Nepārtrauktas integrācijas platformas pārvaldība notiek, izmantojot **tīmekļa saskarni**. Šeit varat ielādēt programmatūras versijas no jebkura Git repozitorija, apvienot tās ar lietojumprogrammām un palaist rezultātu iepriekš definētā testēšanas vidē. Lai to izdarītu, tiek definēts *.drone.yml* fails, kurā norādīts, kā izveidot un palaist lietojumprogrammu katram programmatūras testam.

Dronu lietotājiem tiek piedāvāts atvērtā koda CI risinājums, kas apvieno tādu alternatīvo produktu kā [„Travis“](https://travis-ci.org/ "Travis CI – Test and Deploy Your Code with Confidence") un [„Jenkins“](https://jenkins.io/index.html "Jenkins io homepage") priekšrocības vienā lietotājam draudzīgā lietojumprogrammā.

### OpenStack

Runājot par atvērtā koda mākoņstruktūru izveidi un ekspluatāciju, atvērtā koda **mākoņoperētājsistēma** OpenStack ir vispiemērotākais programmatūras risinājums.

Izmantojot OpenStack, varat pārvaldīt datoru, datu uzglabāšanas un tīkla resursus no centrālās vadības paneļa un nodrošināt to pieejamību galalietotājiem, izmantojot tīmekļa saskarni.

Mākoņdatošanas operētājsistēma balstās uz **modulāru arhitektūru**, kas sastāv no vairākiem komponentiem:

- **Zun (konteineru pakalpojums):** Zun ir OpenStack konteineru pakalpojums, kas nodrošina vienkāršu konteinerizētu lietojumprogrammu izvietošanu un pārvaldību OpenStack mākonī. Zun mērķis ir ļaut lietotājiem pārvaldīt konteinerus, izmantojot REST API, bez nepieciešamības pārvaldīt serverus vai klasterus. Lai darbotos Zun, jums būs nepieciešami trīs citi OpenStack pakalpojumi, kas ir Keystone, Neutron un kryr-libnetwork. Zun funkcionalitāti var paplašināt arī ar papildu OpenStack pakalpojumiem, piemēram, Cinder un Glance.
- **Neutron (tīkla komponente):** Neutron (formāli Quantum) ir pārnesama, mērogojama API atbalstīta sistēmas komponente, ko izmanto tīkla kontrolei. Modulis nodrošina saskarni sarežģītām tīkla topoloģijām un atbalsta dažādus spraudņus, ar kuru palīdzību var integrēt paplašinātas tīkla funkcijas.
- **kuryr-libnetwork (Docker draiveris)**: kuryr-libnetwork ir draiveris, kas darbojas kā saskarnes starp Docker un Neutron.
- **Cinder (bloku uzglabāšana):** Cinder ir OpenStack arhitektūras komponenta nosaukums, kas nodrošina pastāvīgu bloku uzglabāšanu virtuālo mašīnu darbībai. Modulis nodrošina virtuālo uzglabāšanu, izmantojot pašapkalpošanās API. Tādējādi gala lietotāji var izmantot uzglabāšanas resursus, nezinot, kura ierīce nodrošina uzglabāšanu.
- **Keystone (identitātes pakalpojums):** Keystone nodrošina OpenStack lietotājiem centralizētu identitātes pakalpojumu. Modulis darbojas kā autentifikācijas un atļauju sistēma starp atsevišķām OpenStack sastāvdaļām. Piekļuvi projektiem mākonī regulē nomnieki. Katrs nomnieks pārstāv lietotāju, un var definēt vairākus lietotāju piekļuves ar atšķirīgām tiesībām.
- **Glance (attēlu pakalpojums):** ar Glance moduli OpenStack nodrošina pakalpojumu, kas ļauj uzglabāt un izgūt virtuālo mašīnu attēlus.

Vairāk informācijas par OpenStack komponentiem un pakalpojumiem varat atrast mūsu rakstā par OpenStack.

Papildus iepriekš minētajām sastāvdaļām OpenStack arhitektūru var paplašināt, izmantojot dažādus moduļus. Par dažādiem papildu moduļiem varat lasīt [OpenStack tīmekļa](https://www.openstack.org/software/project-navigator/openstack-components "OpenStack Services") vietnē.

### D2iQ DC/OS

DC/OS (Distributed Cloud Operating System) ir atvērtā koda **programmatūra izkliedētu sistēmu darbībai, ko** izstrādājusi D2iQ Inc. (iepriekš Mesosphere). Projekts balstās uz atvērtā koda klastera pārvaldnieku Apache Mesos un ir **operētājsistēma datu centriem**. Avota kods lietotājiem ir pieejams saskaņā ar Apache licences 2. versiju [DC/OS repozitorijos GitHub vietnē](https://github.com/dcos "DC/OS repositories on github.com"). Programmatūras **uzņēmumu versija** ir pieejama arī vietnē [d2iq.com](https://d2iq.com "D2iQ website"). Plaša projekta dokumentācija ir atrodama vietnē [dcos.io](https://dcos.io/ "DC/OS – The Definitive Platform for Modern Apps").

DC/OS var uzskatīt par Mesos distribūciju, kas nodrošina visas klastera pārvaldnieka funkcijas (izmantojot centrālo lietotāja saskarni) un ievērojami paplašina Mesos iespējas.

DC/OS izmanto **Mesos platformas izkliedē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.

Šī programmatūra vienkāršo **izkliedētu lietojumprogrammu** instalēšanu un **pārvaldību**, kā arī automatizē tādas darbības kā resursu pārvaldība, plānošana un procesu savstarpējā saziņa. Uz D2iQ DC/OS balstīta klastera pārvaldība, kā arī tajā iekļauto pakalpojumu pārvaldība notiek, izmantojot centrālo komandrindas programmu (CLI) vai tīmekļa saskarni (GUI).

DC/OS izolē klastera resursus un nodrošina koplietošanas pakalpojumus, piemēram, pakalpojumu atklāšanu vai pakotņu pārvaldību. Programmatūras galvenās sastāvdaļas darbojas aizsargātā vidē – kodola vidē. Tajā ietilpst Mesos platformas galvenā programma un aģentu programmas, 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 (abstrakcijas darba vienības), kas tiek izpildīti aģenta mezglā. Lai to paveiktu, Mesos galvenais mezgls sadala resursus reģistrētajiem DC/OS pakalpojumiem 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ī pieejamajiem resursiem Mesos galvenajam procesam. Mesos galvenais process tos pārsūta plānotā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ā konteinerā.

Visas pārējās sistēmas sastāvdaļas, kā arī lietojumprogrammas, kuras Mesos aģenti palaist ar izpildītāja palīdzību, darbojas **lietotāja vidē**. Standarta DC/OS instalācijas pamatelementi ir administratora maršrutētājs, Mesos DNS, izkliedētais DNS starpniekserveris, slodzes izlīdzinātājs Minuteman, plānotājs Marathon, Apache ZooKeeper un Exhibitor.

- **Administratora maršrutētājs:** administratora maršrutētājs ir īpaši konfigurēts tīmekļa serveris, kas balstās uz NGINX un nodrošina DC/OS pakalpojumus, kā arī centrālās autentifikācijas un starpniekservera funkcijas.
- **Mesos DNS:** sistēmas komponents Mesos DNS nodrošina pakalpojumu atklāšanas funkcijas, kas ļauj atsevišķiem pakalpojumiem un lietojumprogrammām klasterī identificēt viens otru, izmantojot centrālo domēna vārdu sistēmu (DNS).
- **Distributed DNS proxy:** izkliedētais DNS starpniekserveris ir iekšējais DNS dispečers.
- **Minuteman:** sistēmas komponents Minuteman darbojas kā iekšējais slodzes balansētājs, kas strādā OSI atsauces modeļa transporta slānī (4. slānis).
- **DC/OS Marathon:** Marathon ir Mesos platformas centrālā sastāvdaļa, kas D2iQ DC/OS darbojas kā init sistēma (līdzīgi kā *systemd*). Marathon uzsāk un uzrauga DC/OS pakalpojumus un lietojumprogrammas klastera vidēs. Turklāt programmatūra nodrošina augstas pieejamības funkcijas, pakalpojumu atklāšanu, slodzes izlīdzināšanu, darbības pārbaudes un grafisko tīmekļa saskarni.
- **Apache ZooKeeper:** Apache ZooKeeper ir atvērtā koda programmatūras komponents, kas nodrošina koordinācijas funkcijas lietojumprogrammu darbībai un kontrolei izkliedētās sistēmās. ZooKeeper tiek izmantots D2iQ DC/OS, lai koordinētu visus instalētos sistēmas pakalpojumus.
- **Exhibitor:** Exhibitor ir sistēmas komponents, kas tiek automātiski instalēts un konfigurēts kopā ar ZooKeeper katrā galvenajā mezglā. Exhibitor nodrošina arī grafisko lietotāja saskarni ZooKeeper lietotājiem.

Ar DC/OS apvienotajos klastera resursos vienlaikus var izpildīt dažādas darba slodzes. Tas, piemēram, ļauj paralēli darboties liela apjoma datu sistēmām, mikroservisiem vai konteineru platformām, piemēram, Hadoop, Spark un Docker, klastera operētājsistēmā.

D2iQ Universe vidē DC/OS lietotā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 noklikšķinot uz grafiskās lietotāja saskarnes.

## Kādi Docker rīki ir pieejami drošības nodrošināšanai?

Lai gan konteineros darbojošies izolētie procesi izmanto vienu un to pašu kodolu, Docker izmanto vairākas **metodes, lai** tos savstarpēji **izolētu**. Parasti šim nolūkam tiek izmantotas Linux kodola pamatfunkcijas, piemēram, Cgroups un Namespaces.

Tomēr konteineri joprojām **nenodrošina tādu pašu izolācijas līmeni,** kādu var panākt, izmantojot virtuālās mašīnas. Neskatoties uz izolācijas paņēmienu izmantošanu, caur konteineriem ir iespējams piekļūt svarīgām pamatapakšsistēmām, piemēram, Cgroups, kā arī kodola saskarnēm */sys* un */proc* direktorijās.

Docker izstrādes komanda ir atzinusi, ka šīs drošības bažas ir šķērslis konteineru tehnoloģijas ieviešanai ražošanas sistēmās. Papildus Linux kodola pamata izolācijas paņēmieniem jaunākās Docker Engine versijas atbalsta arī AppArmor, SELinux un Seccomp sistēmas, kas darbojas kā sava veida ugunsmūris galvenajiem resursiem.

- **AppArmor:** ar AppArmor tiek regulētas konteineru piekļuves tiesības failu sistēmām.
- **SELinux:** SELinux nodrošina sarežģītu regulēšanas sistēmu, kurā var īstenot piekļuves kontroli galvenajiem resursiem.
- **Seccomp:** Seccomp (Secure Computing Mode) uzrauga sistēmas izsaukumu izpildi.

Papildus šiem Docker rīkiem Docker izmanto arī **Linux iespējas**, lai ierobežotu root tiesības, ar kurām Docker Engine palaista konteinerus.

Pastāv arī citas drošības bažas saistībā ar programmatūras ievainojamībām lietojumprogrammu komponentē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 **, lejupielādējot attēlu,** jūsu sistēmā var tikt ievadīts **ļaunprātīgs kods**. Pirms lietojumprogrammas ieviešanas Docker lietotājiem jāpārliecinās, ka viss attēlā iekļautais kods konteineru izpildei nāk no uzticama avota.

Docker piedāvā [verifikācijas programmu](https://docs.docker.com/trusted-content/dvp-program/ "Docker Verified Publisher Program"), ko programmatūras izstrādātāji var izmantot, lai pārbaudītu un verificētu savus Docker attēlus. Ar šo verifikācijas programmu Docker vēlas atvieglot izstrādātājiem **drošu programmatūras piegādes ķēžu** izveidi saviem projektiem. Papildus lietotāju drošības uzlabošanai programma ir paredzēta, lai programmatūras izstrādātājiem sniegtu iespēju atšķirt savus projektus no daudzajiem citiem pieejamajiem resursiem. Verificētie attēli tiek atzīmēti ar *Verified Publisher* zīmi un, papildus citām priekšrocībām, saņem augstāku vietu Docker Hub meklēšanas rezultātos.


This is a markdown version of: [https://www.ionos.com/lv-lv/digitalguide/serveris/prasmes-un-zinasanas/docker-riki-konteineru-platformas-ekosistema/](https://www.ionos.com/lv-lv/digitalguide/serveris/prasmes-un-zinasanas/docker-riki-konteineru-platformas-ekosistema/) for AI/LLM consumption.