Melyek a legjobb Docker eszközök? Áttekintés

A átfogó Docker ökoszisztéma számos lehetőséget kínál a fejlesztőknek alkalmazások telepítésére, konténerek összehangolására és egyebekre. Áttekintjük a legfontosabb Docker eszközöket, és bemutatjuk a legnépszerűbb harmadik féltől származó projekteket, amelyek nyílt forráskódú Docker eszközöket fejlesztenek.

Melyek a legfontosabb Docker eszközök/összetevők?

Ma a Docker már sokkal több, mint egy kifinomult platform a szoftverkonténerek kezeléséhez. A fejlesztők számos különböző Docker-eszközt hoztak létre, hogy az alkalmazások telepítése elosztott infrastruktúrán és felhőalapú környezetekben könnyebb, gyorsabb és rugalmasabb legyen. A klaszterezéshez és a koordináláshoz szükséges eszközök mellett létezik egy központi alkalmazás-piactér és egy eszköz a felhőalapú erőforrások kezeléséhez is.

Docker motor

Amikor a fejlesztők „Docker”-ről beszélnek, általában a konténerplatform alapját képező nyílt forráskódú kliens-szerver alkalmazásrautalnak. Ezt az alkalmazást Docker Engine-nek nevezik. A Docker Engine központi elemei a Docker démon, egy REST API és egy CLI (parancssori interfész), amely felhasználói felületként szolgál.

Ezzel a kialakítással parancssori parancsok segítségével kommunikálhat a Docker Engine-nel, és kényelmesen kezelheti a Docker-képeket, Docker-fájlokat és Docker-konténereket a terminálról.

A Docker Engine részletes leírását megtalálja a kezdőknek szóló Docker bemutatóban : Docker bemutató: telepítés és első lépések.

Docker Hub

A Docker Hub egy felhőalapú nyilvántartást biztosít a felhasználók számára, amely lehetővé teszi a Docker-képek letöltését, központi kezelését és más Docker-felhasználókkal való megosztását. A regisztrált felhasználók a Docker-képeket nyilvánosan vagy privát adattárakban tárolhatják. A nyilvános képek letöltéséhez (a Docker terminológiában „pulling” néven ismert) nem szükséges felhasználói fiók. Az integrált címkézési mechanizmus lehetővé teszi a képek verziókezelését.

A többi Docker-felhasználó nyilvános tárolói mellett számos forrás található a Docker fejlesztői csapatától és jól ismert nyílt forráskódú projektekből, amelyek a Docker Hub hivatalos tárolóiban találhatók. A legnépszerűbb Docker-képek között szerepel az NGINX webszerver, a Redis memóriában tárolt adatbázis, a BusyBox Unix eszközkészlet és az Ubuntu Linux disztribúció.

A szervezetek egy másik fontos Docker Hub funkció, amely lehetővé teszi a Docker felhasználók számára, hogy olyan privát tárolókat hozzanak létre, amelyek kizárólag egy kiválasztott csoport számára elérhetők. A hozzáférési jogokat a szervezeten belül csapatok és csoporttagságok segítségével kezelik.

Docker Swarm

A Docker Engine tartalmaz egy natív funkciót, amely lehetővé teszi a felhasználók számára, hogy a Docker-gépeket klaszterekben, úgynevezett swarmok ban kezeljék. A Docker Engine-be beépített klaszterkezelési és koordinációs funkciók a Swarmkit eszközkészleten alapulnak. Ha a konténerplatform régebbi verzióját használja, a Docker eszköz önálló alkalmazásként is elérhető.

A Swarm, mint natív Docker klaszterező eszköz, egy Docker-gazdákból álló csoportot egyetlen virtuális gazdába gyűjt össze, és kiszolgálja a Docker REST API-t. Bármely, a Docker démonhoz kapcsolódó Docker-eszköz hozzáférhet a Swarmhoz, és tetszőleges számú Docker-gazda között skálázható. A Docker Engine CLI segítségével a felhasználók swarmokat hozhatnak létre, alkalmazásokat oszthatnak el a klaszteren belül, és kezelhetik a swarm viselkedését anélkül, hogy további koordinációs szoftvert kellene használniuk.

A klaszterekbe összevont Docker motorok swarm módban futnak. Válassza ezt, ha új klasztert szeretne létrehozni, vagy Docker gazdagépet szeretne hozzáadni egy meglévő swarmhoz. A klaszterben található egyes Docker gazdagépeket „csomópontoknak” nevezzük. A klaszter csomópontjai ugyanazon a helyi rendszeren virtuális gazdagépekként futhatnak, de gyakrabban használnak felhőalapú kialakítást, ahol a Docker swarm egyes csomópontjai különböző rendszerekre és infrastruktúrákra vannak elosztva.

A szoftver master-worker architektúrán alapul. Amikor a feladatokat el kell osztani a swarmban, a felhasználók átadnak egy szolgáltatást a menedzser csomópontnak. A menedzser ezután felelős a konténerek ütemezéséért a klaszterben, és elsődleges felhasználói felületként szolgál a swarm erőforrások eléréséhez.

A menedzser csomópont egyedi egységeket, úgynevezett feladatokat küld a munkás csomópontoknak.

• Szolgáltatások: a szolgáltatások a Docker klaszterek központi struktúrái. A szolgáltatás meghatározza a Docker klaszterben végrehajtandó feladatot. A szolgáltatás ugyanazon kép alapján létrehozott konténerek csoportjához tartozik. A szolgáltatás létrehozásakor a felhasználó meghatározza, hogy melyik kép és parancsok kerülnek felhasználásra. Ezenkívül a szolgáltatások lehetőséget nyújtanak az alkalmazások méretezésére. A Docker platform felhasználói egyszerűen meghatározzák, hogy hány konténert kell elindítani egy szolgáltatáshoz.
• Feladatok: a szolgáltatások klaszteren belüli elosztása érdekében a menedzser csomópont egyedi munkameghatározásokra (feladatokra) osztja őket. Minden feladat tartalmaz egy Docker konténert, valamint a benne végrehajtandó parancsokat.

A klasztervezérlés és a konténerek összehangolásának kezelése mellett a menedzsercsomópontok alapértelmezés szerint a munkáscsomópontok funkcióit is ellátják – kivéve, ha ezeknek a csomópontoknak a feladatait szigorúan a kezelésre korlátozza.

Minden munkáscsomóponton fut egy ügynökprogram. Ez fogadja a feladatokat és biztosítja a megfelelő főcsomópont állapotjelentéseit az átvitt feladat előrehaladásáról. Az alábbi ábra egy Docker Swarm sematikus ábrázolását mutatja:

A Docker Swarm megvalósításakor a felhasználók általában a Docker gépre támaszkodnak.

Docker Compose

A Docker Compose lehetővé teszi több konténer egyesítését és egyetlen parancs segítségével történő végrehajtását. A Compose alapeleme a díjnyertes YAML nyelven alapuló központi vezérlőfájl. A compose fájl szintaxisa hasonló a virtuális gépek létrehozásához és provisioningjához használt nyílt forráskódú Vagrant szoftveréhez.

A docker-compose.yml fájlban tetszőleges számú szoftverkonténert definiálhat, beleértve az összes függőséget, valamint azok egymáshoz fűződő kapcsolatait. Az ilyen többkonténeres alkalmazások ugyanazon a mintán alapulnak, mint az egyedi szoftverkonténerek. A docker-compose parancsot a kívánt alparanccsal kombinálva használja az alkalmazás teljes életciklusának kezeléséhez.

Ez a Docker eszköz könnyen integrálható a Swarm alapú klaszterbe. Így a Compose-szal létrehozott többkonténeres alkalmazásokat ugyanolyan egyszerűen futtathatja elosztott rendszereken, mint egyetlen Docker-gépeken.

A Docker Compose másik jellemzője az integrált méretezési mechanizmus. Az orchestration eszközzel kényelmesen használhatja a parancssori programot, hogy meghatározza, hány konténert szeretne elindítani egy adott szolgáltatáshoz.

Milyen harmadik féltől származó Docker eszközök léteznek?

A Docker Inc. saját fejlesztései mellett számos külső szolgáltató kínál olyan szoftvereszközöket és platformokat, amelyek interfészeket biztosítanak a Docker Engine számára, vagy kifejezetten a népszerű konténerplatformhoz lettek kifejlesztve. A Docker ökoszisztémán belül a legnépszerűbb nyílt forráskódú projektek közé tartozik a Kubernetes orchestration eszköz, a Shipyard klaszterkezelő eszköz, a Panamax többkonténeres szállítási megoldás, a Drone folyamatos integrációs platform, az OpenStack felhőalapú operációs rendszer és a D2iQ DC/OS adatközponti operációs rendszer, amely a Mesos klaszterkezelőn alapul.

Kubernetes

A Docker nem mindig képes saját orchestration eszközöket kifejleszteni, mint például a Swarm és a Compose. Ezért különböző cégek évek óta saját fejlesztési munkába fektetnek, hogy olyan testreszabott eszközöket hozzanak létre, amelyek megkönnyítik a konténerplatform működését nagy, elosztott infrastruktúrákban. Az ilyen típusú megoldások közül az egyik legnépszerűbb az open source projekt, a Kubernetes.

A Kubernetes egy konténeralapú alkalmazásokhoz készült klaszterkezelő. A Kubernetes célja a klaszterben található alkalmazások automatizálása. Ehhez az orchestration eszköz egy REST-API-t, egy parancssori programot és egy grafikus webes felületet használ vezérlő felületként. Ezekkel a felületekkel automatizálások indíthatók el és állapotjelentések kérhetők. A Kubernetes a következőkre használható:

• konténeralapú fotók végrehajtása egy klaszteren,
• alkalmazások telepítése és kezelése elosztott rendszerekben,
• alkalmazások méretezése, és
• a hardver lehető legjobb kihasználása.

Ennek érdekében a Kubernetes a konténereket logikai részekké, úgynevezett podokká egyesíti. A podok a klaszterkezelő alapegységei, amelyek ütemezéssel eloszthatók a klaszteren belül.

A Docker Swarm-hoz hasonlóan a Kubernetes is master-worker architektúrán alapul. A klaszter egy Kubernetes masterből és különböző munkásokból áll, amelyeket Kubernetes csomópontoknak (vagy minionoknak) is neveznek. A Kubernetes master a klaszter központi vezérlő síkjaként működik, és négy alapvető komponensből áll, amelyek lehetővé teszik a klaszteren belüli közvetlen kommunikációt és a feladatok elosztását. A Kubernetes master egy API szerverből, az etcd konfigurációs memóriából, egy ütemezőből és egy vezérlő menedzserből áll.

• API szerver: a Kubernetes klaszterben minden automatizálás REST-API-val, API szerveren keresztül indul. Ez a klaszter központi adminisztrációs felületeként működik.
• etcd: az open source konfigurációs memória etcd a Kubernetes klaszter memóriájának tekinthető. A CoreOS által kifejezetten elosztott rendszerekhez kifejlesztett Key Value Store tárolja a konfigurációs adatokat, és elérhetővé teszi azokat a klaszter minden csomópontja számára. A klaszter aktuális állapota bármikor kezelhető az etcd segítségével.
• Scheduler: a scheduler feladata a konténercsoportok (podok) elosztása a klaszteren belül. Meghatározza a pod erőforrásigényét, majd ezt összehangolja a klaszter egyes csomópontjainak rendelkezésre álló erőforrásaival.
• Controller manager: a controller manager a Kubernetes master egyik szolgáltatása, amely a klaszter állapotának szabályozásával és rutin feladatok elvégzésével irányítja az összehangolást. A controller manager fő feladata annak biztosítása, hogy a klaszter állapota megfeleljen a meghatározott célállapotnak.

A Kubernetes master összes összetevője ugyanazon a gazdagépen helyezkedhet el, vagy elosztható több master gazdagépen egy nagy rendelkezésre állású klaszteren belül.

Míg a Kubernetes master felelős a koordinációért, a klaszterben elosztott podok a masternek alárendelt hostokon, Kubernetes csomópontokon futnak. Ehhez minden Kubernetes csomóponton egy konténermotor futtatására van szükség. Bár a Docker a de facto szabvány, a Kubernetesnek nem kötelező egy adott konténermotort használnia.

A konténermotor mellett a Kubernetes csomópontok a következő összetevőket fedik le:

• kubelet: a kubelet egy ügynök, amely minden Kubernetes csomóponton fut, és a csomópont vezérlésére és kezelésére szolgál. Minden csomópont központi kapcsolattartó pontjaként a kubelet csatlakozik a Kubernetes masterhez, és biztosítja, hogy az információk továbbításra kerüljenek a vezérlő síkhoz, és onnan is beérkezzenek.
• kube-proxy: emellett a kube-proxy proxy szolgáltatás minden Kubernetes csomóponton fut. Ez biztosítja, hogy a külső kérések továbbításra kerüljenek a megfelelő konténerekhez, és szolgáltatásokat nyújtson a konténeralapú alkalmazások felhasználóinak. A kube-proxy alapvető terheléselosztást is kínál.

Az alábbi ábra a Kubernetes koordinációs platform alapját képező master-node architektúra sematikus ábrázolását mutatja:

A Kubernetes alapvető projektje mellett számos eszköz és kiterjesztés is rendelkezésre áll, amelyekkel további funkciók adhatók hozzá az orchestration platformhoz. A legnépszerűbbek a Prometheus, Weave Scope és sysdig felügyeleti és hibadiagnosztikai eszközök, valamint a Helm csomagkezelő. Pluginek is léteznek az Apache Maven és a Gradle számára, valamint egy Java API, amely lehetővé teszi a Kubernetes távoli vezérlését.

Hajógyár

A Shipyard egy közösség által fejlesztett, Swarm alapú felügyeleti megoldás, amely lehetővé teszi a felhasználók számára, hogy grafikus felhasználói felületen keresztül kezeljék a Docker-erőforrásokat, például konténereket, képeket, gazdagépeket és privát nyilvántartásokat. Böngészőn keresztül, webalkalmazásként érhető el. A központi webes felületen keresztül elérhető klaszterkezelési funkciók mellett a Shipyard felhasználói hitelesítést és szerepköralapú hozzáférés-vezérlést is kínál.

A szoftver 100%-ban kompatibilis a Docker távoli API-val, és a nyílt forráskódú NoSQL adatbázis RethinkDB-t használja a felhasználói fiókok, címek és események adatainak tárolására. A szoftver a Citadel klaszterkezelő eszközkészleten alapul, és három fő komponensből áll: vezérlő, API és felhasználói felület.

• Shipyard vezérlő: a vezérlő a Shipyard menedzsment eszköz központi eleme. A Shipyard vezérlő a RethinkDB-vel együttműködve tárolja az adatokat, és lehetővé teszi a Docker klaszterben található egyes gazdagépek címzését és az események vezérlését.
• Shipyard API: a Shipyard API a REST-en alapul. A menedzsment eszköz összes funkciója a Shipyard API-n keresztül vezérelhető.
• Shipyard felhasználói felület (UI): a Shipyard UI egy AngularJS alkalmazás, amely a felhasználóknak grafikus felhasználói felületet biztosít a Docker klaszterek web böngészőben történő kezeléséhez. A felhasználói felületen minden interakció a Shipyard API-n keresztül történik.

További információk az open source projektről a Shipyard hivatalos weboldalán találhatók.

Panamax

A Panamax nyílt forráskódú szoftverprojekt fejlesztői célja a több konténeres alkalmazások telepítésének egyszerűsítése. Az ingyenes eszköz grafikus felhasználói felületet kínál a felhasználóknak, amely lehetővé teszi a Docker konténereken alapuló komplex alkalmazások kényelmes fejlesztését, telepítését és terjesztését drag-and-drop segítségével.

A Panamax lehetővé teszi komplex, több konténeres alkalmazások mentését alkalmazássablonként, és azok egyetlen kattintással történő terjesztését klaszterarchitektúrákban. A GitHubon tárolt integrált alkalmazáspiac segítségével a saját készítésű alkalmazások sablonjai Git-tárolókban tárolhatók és más felhasználók számára is elérhetővé tehetők.

A Panamax architektúra alapvető összetevői két csoportra oszthatók: a Panamax Local Client és tetszőleges számú távoli telepítési célpont.

A Panamax helyi kliens a Docker eszköz központi eleme. A helyi rendszeren fut, és komplex konténeralapú alkalmazások létrehozását teszi lehetővé. A helyi kliens a következő elemekből áll:

• CoreOS: a Panamax helyi kliens telepítéséhez a Linux CoreOS disztribúcióra van szükség, amely kifejezetten szoftverkonténerekhez lett kifejlesztve. A Panamax kliens ezután Docker konténerként fut a CoreOS-ban. A Docker funkciók mellett a felhasználók különböző CoreOS funkciókhoz is hozzáférhetnek. Ezek közé tartozik többek között a Fleet és a Journalctl:
• Fleet: a Panamax kliens a Dockerrel való közvetlen integráció helyett a Fleet klaszterkezelőt használja konténereinek összehangolásához. A Fleet egy klaszterkezelő, amely a számítógépes klaszterekben a Linux daemon systemd rendszert vezérli.
• Journalctl: a Panamax kliens a Journalctl-t használja a naplóüzenetek lekérésére a Linux rendszerkezelő systemd- től a naplóból.
• Helyi kliens telepítő: a helyi kliens telepítő tartalmazza az összes komponenst, amely a Panamax kliens helyi rendszerre történő telepítéséhez szükséges.
• Panamax helyi ügynök: a helyi kliens központi komponense a helyi ügynök. Ez a Panamax API-n keresztül kapcsolódik számos más komponenshez és függőséghez. Ezek közé tartozik a helyi Docker-gazdagép, a Panamax felhasználói felület, külső nyilvántartások és a klaszterben található telepítési célok távoli ügynökei. A helyi ügynök a Panamax API-n keresztül a következő programinterfészekkel kommunikál a helyi rendszeren, hogy információt cseréljen a futó alkalmazásokról:
• Docker távoli API: a Panamax a Docker távoli API-n keresztül keres képeket a helyi rendszeren, és információkat szerez a futó konténerekről.
• etcd API: a fájlok az etcd API-n keresztül kerülnek továbbításra a CoreOS Fleet démonhoz.
• systemd-journal-gatewayd.services: A Panamax a systemd-journal-gatewayd.services segítségével szerzi be a futó szolgáltatások naplókimenetét.

Ezenkívül a Panamax API lehetővé teszi a különböző külső API-kkal való interakciót is.

• Docker registry API: A Panamax a Docker registry API-n keresztül szerez be képcímkéket a Docker registry-ből.
• GitHub API: A Panamax a GitHub API-n keresztül tölti be a sablonokat a GitHub-tárházból.
• KissMetrics API: a KissMetrics API adatokat gyűjt a felhasználók által futtatott sablonokról.
• Panamax UI: a Panamax UI a helyi rendszer felhasználói felületeként működik, és lehetővé teszi a felhasználók számára, hogy grafikus felületen keresztül vezéreljék a Docker eszközt. A felhasználói beviteleket a Panamax API közvetlenül továbbítja a helyi ügynöknek. A Panamax UI a CTL Base UI Kit-en alapul, amely a CenturyLink webes projektekhez készült UI-komponensek könyvtára.

A Panamax terminológiában a Docker klaszter minden olyan csomópontját, amely nem végez felügyeleti feladatokat, távoli telepítési célpontnak nevezik. A telepítési célpontok egy Docker-gépből állnak, amely a következő összetevők segítségével van konfigurálva a Panamax-sablonok telepítésére:

• Telepítési cél telepítő: a telepítési cél telepítő elindít egy Docker gazdagépet, amely tartalmaz egy Panamax távoli ügynököt és egy koordinációs adaptert.
• Panamax távoli ügynök: ha Panamax távoli ügynök van telepítve, az alkalmazások a helyi Panamax kliensen keresztül a klaszter bármely kívánt végpontjára eloszthatók. A Panamax távoli ügynök Docker konténerként fut a klaszter minden telepítési célpontján.
• Panamax orchestration adapter: az orchestration adapterben a program logikája minden, a Panamax számára elérhető orchestration eszköz számára egy független adapter rétegben biztosított. Ennek köszönhetően a felhasználóknak lehetőségük van mindig pontosan azt az orchestration technológiát választani, amelyet a célkörnyezetük támogat. Az előre konfigurált adapterek között megtalálható a Kubernetes és a Fleet:
• Panamax Kubernetes adapter: a Panamax távoli ügynökkel kombinálva a Panamax Kubernetes adapter lehetővé teszi a Panamax sablonok terjesztését a Kubernetes klaszterekben.
• Panamax Fleet adapter: a Panamax távoli ügynökkel kombinálva a Panamax Fleet adapter lehetővé teszi a Panamax sablonok terjesztését a Fleet klaszterkezelő segítségével vezérelt klaszterekben.

Az alábbi ábra a Docker klaszterben található egyes Panamax komponensek közötti kölcsönhatást mutatja be:

A CoreOS-alapú Panamax konténerkezelő eszköz grafikus felhasználói felületen keresztül számos szabványos konténerkoordinációs technológiát kínál a felhasználóknak, valamint lehetőséget biztosít komplex, több konténerből álló alkalmazások kényelmes kezelésére klaszterarchitektúrákban bármilyen rendszer (pl. a saját laptop) használatával.

A Panamax nyilvános sablon-tárházával a Panamax felhasználók a GitHubon keresztül hozzáférhetnek egy nyilvános sablonkönyvtárhoz, amely különböző erőforrásokat tartalmaz.

Drón

A Drone egy karcsú, folyamatos integrációs platform, minimális követelményekkel. Ezzel a Docker eszközzel automatikusan betöltheti a legújabb buildjét egy GitHub-hoz hasonló Git-repozitóriumból, és izolált Docker-konténerekben tesztelheti. Bármilyen tesztcsomagot futtathat, és e-mailben küldhet jelentéseket és állapotüzeneteket. Minden szoftverteszthez egy új konténer jön létre, amely a nyilvános Docker-nyilvántartás képein alapul. Ez azt jelenti, hogy bármely nyilvánosan elérhető Docker-kép felhasználható a kód tesztelésének környezeteként.

A Drone integrálva van a Dockerbe, és számos programozási nyelv támogatja, például PHP, Node.js, Ruby, Go és Python. Az egyetlen valódi függőség a konténerplatform. A Drone segítségével bármely olyan rendszeren létrehozhatja saját folyamatos integrációs platformját, amelyre a Docker telepíthető. A Drone számos verziókezelő tárolót támogat, és a GitHub-integrációval történő standard telepítésről szóló útmutatót az open source projekt weboldalán, a readme.drone.io címen találja.

A folyamatos integrációs platform kezelése webes felületen történik. Itt bármely Git-tárházból betölthetők a szoftververziók, összevonhatók alkalmazásokká, és az eredmény előre meghatározott tesztkörnyezetben futtatható. Ehhez egy .drone.yml fájl van definiálva, amely meghatározza, hogyan kell létrehozni és futtatni az alkalmazást az egyes szoftvertesztekhez.

A drónhasználók egy nyílt forráskódú CI-megoldást kapnak, amely olyan alternatív termékek erősségeit ötvözi, mint a Travis és a Jenkins, egy felhasználóbarát alkalmazásban.

OpenStack

A nyílt forráskódú felhőszerkezetek építése és üzemeltetése terén az OpenStack nyílt forráskódú felhőoperációs rendszer a legmegfelelőbb szoftvermegoldás.

Az OpenStack segítségével központi irányítópultról kezelheti a számítógépes, tárolási és hálózati erőforrásokat, és webes felületen keresztül elérhetővé teheti azokat a végfelhasználók számára.

A felhőalapú operációs rendszer moduláris architektúrán alapul, amely több komponensből áll:

• Zun (konténer szolgáltatás): A Zun az OpenStack konténer szolgáltatása, amely lehetővé teszi a konténeres alkalmazások egyszerű telepítését és kezelését az OpenStack felhőben. A Zun célja, hogy a felhasználók REST API-n keresztül kezelhessék a konténereket anélkül, hogy szervereket vagy klasztereket kellene kezelniük. A Zun működtetéséhez három további OpenStack szolgáltatásra van szükség: Keystone, Neutorn és kryr-libnetwork. A Zun funkcionalitása további OpenStack szolgáltatásokkal, például Cinder és Glance segítségével is bővíthető.
• Neutron (hálózati komponens): A Neutron (korábban Quantum) egy hordozható, skálázható, API-támogatott rendszerkomponens, amelyet hálózati vezérlésre használnak. A modul interfészt biztosít komplex hálózati topológiákhoz, és támogatja a különböző bővítményeket, amelyekkel kiterjesztett hálózati funkciók integrálhatók.
• kuryr-libnetwork (Docker illesztőprogram): A kuryr-libnetwork egy illesztőprogram, amely a Docker és a Neutron közötti interfészként működik.
• Cinder (blokktároló): A Cinder az OpenStack architektúra egyik komponensének beceneve, amely állandó blokktárolót biztosít a virtuális gépek működéséhez. A modul önkiszolgáló API-n keresztül biztosít virtuális tárolót. Ezáltal a végfelhasználók tárolási erőforrásokat vehetnek igénybe anélkül, hogy tudnák, melyik eszköz biztosítja a tárolást.
• Keystone (azonosítási szolgáltatás): A Keystone központi azonosítási szolgáltatást nyújt az OpenStack felhasználóknak. A modul hitelesítési és jogosultsági rendszerként működik az egyes OpenStack komponensek között. A felhőben található projektekhez való hozzáférést a bérlők szabályozzák. Minden bérlő egy felhasználót képvisel, és több, különböző jogokkal rendelkező felhasználói hozzáférés is meghatározható.
• Glance (képszolgáltatás): a Glance modullal az OpenStack olyan szolgáltatást nyújt, amely lehetővé teszi a virtuális gépek képeinek tárolását és visszakeresését.

Az OpenStack komponensekről és szolgáltatásokról további információkat találhat az OpenStackről szóló cikkünkben.

A fent említett komponenseken kívül az OpenStack architektúra különböző modulokkal bővíthető. A különböző opcionális modulokról az OpenStack weboldalán olvashat.

D2iQ DC/OS

A DC/OS (Distributed Cloud Operating System) egy nyílt forráskódú szoftver elosztott rendszerek működtetéséhez, amelyet a D2iQ Inc. (korábban Mesosphere) fejlesztett ki. A projekt az Apache Mesos nyílt forráskódú klaszterkezelőn alapul, és egy adatközpontok számára készült operációs rendszer. A forráskód az Apache licenc 2. verziója alapján elérhető a felhasználók számára a GitHub DC/OS-tárolóiban. A szoftver vállalati verziója a d2iq.com oldalon is elérhető. A projekt kiterjedt dokumentációja a dcos.io oldalon található.

A DC/OS-t úgy lehet elképzelni, mint egy Mesos disztribúciót, amely a klaszterkezelő összes funkcióját biztosítja (egy központi felhasználói felületen keresztül), és jelentősen kibővíti a Mesos funkcióit.

A DC/OS a Mesos platform elosztott rendszermagját használja. Ez lehetővé teszi egy teljes adatközpont erőforrásainak összevonását és azok egyetlen logikai szerverként működő, összesített rendszer formájában történő kezelését. Így a fizikai vagy virtuális gépek teljes klasztereit ugyanolyan egyszerűen vezérelheti, mintha egyetlen számítógépet működtetne.

A szoftver egyszerűsíti az elosztott alkalmazások telepítését és kezelését, valamint automatizálja az erőforrás-kezelés, az ütemezés és a folyamatok közötti kommunikáció feladatait. A D2iQ DC/OS alapú klaszter és a hozzá tartozó szolgáltatások kezelése egy központi parancssori program (CLI) vagy webes felület (GUI) segítségével történik.

A DC/OS elkülöníti a klaszter erőforrásait és megosztott szolgáltatásokat nyújt, például szolgáltatásfelismerést vagy csomagkezelést. A szoftver alapvető összetevői egy védett területen, az alapvető rendszermagban futnak. Ide tartoznak a Mesos platform master és agent programjai, amelyek az erőforrás-elosztásért, a folyamatok elkülönítéséért és a biztonsági funkciókért felelősek.

• Mesos master: a Mesos master egy master folyamat, amely egy master csomóponton fut. A Mesos master célja az erőforrások kezelésének irányítása és az agent csomóponton végrehajtott feladatok (absztrakt munkameghatározások) összehangolása. Ehhez a Mesos master elosztja az erőforrásokat a regisztrált DC/OS szolgáltatások között, és fogadja a Mesos agentek erőforrás-jelentéseit.
• Mesos ügynökök: A Mesos ügynökök olyan folyamatok, amelyek ügynöki fiókokon futnak, és a master által elosztott feladatok végrehajtásáért felelősek. A Mesos ügynökök rendszeresen jelentéseket küldenek a klaszterben rendelkezésre álló erőforrásokról a Mesos masternek. Ezeket a Mesos master továbbítja egy ütemezőnek (pl. Marathon, Chronos vagy Cassandra). Ez dönti el, hogy melyik feladatot melyik csomóponton futtatja. A feladatok ezután izolált módon, konténerben kerülnek végrehajtásra.

Az összes többi rendszerkomponens, valamint a Mesos ügynökök által végrehajtóprogramon keresztül futtatott alkalmazások a felhasználói térben futnak. A standard DC/OS telepítés alapvető komponensei az admin router, a Mesos DNS, egy elosztott DNS-proxy, a terheléselosztó Minuteman, az ütemező Marathon, az Apache ZooKeeper és az Exhibitor.

• Admin router: az admin router egy speciálisan konfigurált, NGINX alapú webszerver, amely DC/OS szolgáltatásokat, valamint központi hitelesítési és proxy funkciókat biztosít.
• Mesos DNS: a Mesos DNS rendszerkomponens szolgáltatásfelismerési funkciókat biztosít, amelyek lehetővé teszik a klaszterben található egyes szolgáltatások és alkalmazások számára, hogy egy központi domainnévrendszeren (DNS) keresztül azonosítsák egymást.
• Elosztott DNS-proxy: az elosztott DNS-proxy egy belső DNS-diszpécser.
• Minuteman: a Minuteman rendszerkomponens belső terheléselosztóként működik, amely az OSI referencia modell transport rétegén (4. réteg) működik.
• DC/OS Marathon: A Marathon a Mesos platform központi komponense, amely a D2iQ DC/OS-ben init rendszerként (hasonlóan a systemd-hez) működik. A Marathon elindítja és felügyeli a DC/OS szolgáltatásokat és alkalmazásokat a klaszterkörnyezetekben. Ezenkívül a szoftver magas rendelkezésre állási funkciókat, szolgáltatásfelismerést, terheléselosztást, állapotellenőrzést és grafikus webes felületet biztosít.
• Apache ZooKeeper: Az Apache ZooKeeper egy nyílt forráskódú szoftverkomponens, amely koordinációs funkciókat biztosít az elosztott rendszerekben futó alkalmazások működéséhez és vezérléséhez. A ZooKeeper a D2iQ DC/OS-ben az összes telepített rendszerszolgáltatás koordinálására szolgál.
• Exhibitor: Az Exhibitor egy rendszerkomponens, amelyet a ZooKeeper automatikusan telepít és konfigurál minden master csomóponton. Az Exhibitor grafikus felhasználói felületet is biztosít a ZooKeeper felhasználók számára.

A DC/OS-en keresztül összesített klaszter erőforrásokon különböző munkaterhelések futtathatók egyszerre. Ez lehetővé teszi például a nagy adathalmazokat kezelő rendszerek, mikroszolgáltatások vagy konténerplatformok, mint például a Hadoop, a Spark és a Docker klaszter operációs rendszerén történő párhuzamos működést.

A D2iQ Universe-en belül nyilvános alkalmazáskatalógus áll rendelkezésre a DC/OS számára. Ezzel egyszerűen, a grafikus felhasználói felületre kattintva telepítheti az olyan alkalmazásokat, mint a Spark, a Cassandra, a Chronos, a Jenkins vagy a Kafka.

Milyen Docker eszközök állnak rendelkezésre a biztonság érdekében?

Annak ellenére, hogy a konténerekben futó kapszulázott folyamatok ugyanazt a magot használják, a Docker számos technikát alkalmaz , hogy elszigetelje őket egymástól. Ehhez általában a Linux kernel alapvető funkcióit, például a Cgroups és a Namespaces funkciókat használja.

A konténerek azonban még mindig nem kínálnak ugyanolyan szintű elszigeteltséget, mint a virtuális gépek. Az elszigetelési technikák alkalmazása ellenére a konténereken keresztül elérhetők olyan fontos alapvető alrendszerek, mint a Cgroups, valamint a /sys és /proc könyvtárakban található kernel interfészek.

A Docker fejlesztőcsapata elismerte, hogy ezek a biztonsági aggályok akadályozzák a konténertechnológia bevezetését a termelési rendszerekbe. A Linux kernelt alapvető elszigetelési technikáin túl a Docker Engine újabb verziói támogatják az AppArmor, SELinux és Seccomp keretrendszereket is, amelyek egyfajta tűzfalként működnek a központi erőforrások számára.

• AppArmor: az AppArmor segítségével szabályozhatók a konténerek fájlrendszerhez való hozzáférési jogai.
• SELinux: A SELinux egy komplex szabályozó rendszert biztosít, amelyben a központi erőforrásokhoz való hozzáférés szabályozható.
• Seccomp: A Seccomp (Secure Computing Mode) felügyeli a rendszerhívások meghívását.

Ezen Docker eszközök mellett a Docker a Linux képességeit is felhasználja a root jogosultságok korlátozására, amelyekkel a Docker Engine elindítja a konténereket.

A Docker-nyilvántartás által terjesztett alkalmazáskomponensek szoftveres sebezhetőségeivel kapcsolatban egyéb biztonsági aggályok is felmerülnek. Mivel lényegében bárki létrehozhat Docker-képeket, és azokat nyilvánosan hozzáférhetővé teheti a Docker Hub közösség számára, fennáll a kockázata, hogy egy kép letöltésekor rosszindulatú kód kerül a rendszerbe. Az alkalmazás telepítése előtt a Docker-felhasználóknak meg kell győződniük arról, hogy a konténerek futtatásához a képben található összes kód megbízható forrásból származik.

A Docker egy olyan ellenőrzési programot kínál, amelyet a szoftvergyártók felhasználhatnak Docker-képeik ellenőrzésére és hitelesítésére. Ezzel az ellenőrzési programmal a Docker célja, hogy megkönnyítse a fejlesztők számára a projektek hez biztonságos szoftverellátási láncok kiépítését. A program célja, hogy a felhasználók biztonságának növelése mellett a szoftverfejlesztőknek lehetőséget nyújtson arra, hogy projektjeiket megkülönböztessék a rendelkezésre álló számos más erőforrástól. Az ellenőrzött képek „Verified Publisher” (Ellenőrzött kiadó) jelöléssel vannak ellátva, és más előnyök mellett magasabb rangsort kapnak a Docker Hub keresési eredményeiben.