Wat zijn de beste Docker-tools? Een overzicht

Het uit­ge­brei­de Docker-eco­sys­teem biedt ont­wik­ke­laars een aantal mo­ge­lijk­he­den om ap­pli­ca­ties te im­ple­men­te­ren, con­tai­ners te or­ke­stre­ren en meer. We bespreken de be­lang­rijk­ste Docker-tools en geven u een overzicht van de po­pu­lair­ste projecten van derden die open-source Docker-tools ont­wik­ke­len.

Wat zijn de es­sen­ti­ë­le Docker-tools/com­po­nen­ten?

Te­gen­woor­dig is Docker veel meer dan alleen een ge­a­van­ceerd platform voor het beheer van soft­wa­re­con­tai­ners. Ont­wik­ke­laars hebben een reeks diverse Docker-tools gecreëerd om het im­ple­men­te­ren van ap­pli­ca­ties via ge­dis­tri­bu­eer­de in­fra­struc­tuur en cloudom­ge­vin­gen een­vou­di­ger, sneller en flexi­be­ler te maken. Naast tools voor clus­te­ring en or­kestra­tie is er ook een centrale app-markt­plaats en een tool voor het beheer van cloud­re­sour­ces.

Docker-engine

Wanneer ont­wik­ke­laars het over ‘Docker’ hebben, bedoelen ze meestal de open-source client-ser­ver­ap­pli­ca­tie diede basis vormt van het con­tai­ner­plat­form. Deze ap­pli­ca­tie wordt Docker Engine genoemd. Centrale on­der­de­len van Docker Engine zijn de Docker-daemon, een REST API en een CLI (command line interface) die als ge­brui­kers­in­ter­fa­ce fungeert.

Met dit ontwerp kunt u via op­dracht­re­ge­lop­drach­ten com­mu­ni­ce­ren met Docker Engine en Docker-images, Docker-bestanden en Docker-con­tai­ners ge­mak­ke­lijk beheren vanaf de terminal.

Een ge­de­tail­leer­de be­schrij­ving van Docker Engine vindt u in onze Docker-hand­lei­ding voor beginners : Docker-hand­lei­ding: in­stal­la­tie en eerste stappen.

Docker Hub

Docker Hub biedt ge­brui­kers een cloud­ge­ba­seerd register waarmee Docker-images kunnen worden ge­down­load, centraal beheerd en gedeeld met andere Docker-ge­brui­kers. Ge­re­gi­streer­de ge­brui­kers kunnen Docker-images openbaar of in privé-re­po­si­to­ries opslaan. Voor het down­lo­a­den van een openbaar image (in Docker-ter­mi­no­lo­gie ‘pulling’ genoemd) is geen ge­brui­kers­ac­count vereist. Een ge­ïn­te­greerd tag­me­cha­nis­me maakt het mogelijk om versies van images bij te houden.

Naast de openbare re­po­si­to­ries van andere Docker-ge­brui­kers zijn er ook veel bronnen van het Docker-ont­wik­ke­laars­team en bekende open-sour­ce­pro­jec­ten te vinden in de officiële re­po­si­to­ries in Docker Hub. De po­pu­lair­ste Docker-images zijn onder andere de NGINX-webserver, de Redis-in-memory-database, de BusyBox Unix-toolkit en de Ubuntu Linux-dis­tri­bu­tie.

Or­ga­ni­sa­ties zijn een andere be­lang­rij­ke functie van Docker Hub, waarmee Docker-ge­brui­kers privé-re­po­si­to­ries kunnen aanmaken die uit­slui­tend be­schik­baar zijn voor een selecte groep mensen. Toe­gangs­rech­ten worden binnen een or­ga­ni­sa­tie beheerd met behulp van teams en groeps­lid­maat­schap­pen.

Docker Swarm

Docker Engine bevat een native functie waarmee ge­brui­kers Docker-hosts kunnen beheren in clusters die swarms worden genoemd. De clus­ter­be­heer- en or­ches­tra­ti­on­mo­ge­lijk­he­den die in de Docker-engine zijn ingebouwd, zijn gebaseerd op de Swarmkit-toolbox. Als u een oudere versie van het con­tai­ner­plat­form gebruikt, is de Docker-tool be­schik­baar als zelf­stan­di­ge ap­pli­ca­tie.

Als native Docker-clus­te­ring­tool verzamelt Swarm een pool van Docker-hosts in één virtuele host en bedient het de Docker REST API. Elke Docker-tool die is gekoppeld aan de Docker-daemon heeft toegang tot Swarm en kan worden geschaald over een wil­le­keu­rig aantal Docker-hosts. Met de Docker Engine CLI kunnen ge­brui­kers swarms maken, ap­pli­ca­ties in het cluster dis­tri­bu­e­ren en het gedrag van de swarm beheren zonder dat daarvoor aan­vul­len­de or­ches­tra­ti­on-software nodig is.

Docker-engines die zijn sa­men­ge­voegd tot clusters, draaien in swarm-modus. Selecteer deze optie als u een nieuw cluster wilt maken of een Docker-host wilt toevoegen aan een bestaande swarm. Af­zon­der­lij­ke Docker-hosts in een cluster worden ‘knoop­pun­ten’ genoemd. De knoop­pun­ten van een cluster kunnen als virtuele hosts op hetzelfde lokale systeem draaien, maar vaker wordt een cloud­ge­ba­seerd ontwerp gebruikt, waarbij de af­zon­der­lij­ke knoop­pun­ten van de Docker-swarm zijn verdeeld over ver­schil­len­de systemen en in­fra­struc­tu­ren.

De software is gebaseerd op een master-worker-ar­chi­tec­tuur. Wanneer taken in de swarm moeten worden verdeeld, geven ge­brui­kers een service door aan het ma­na­ger­knoop­punt. De manager is ver­vol­gens ver­ant­woor­de­lijk voor het plannen van con­tai­ners in het cluster en fungeert als primaire ge­brui­kers­in­ter­fa­ce voor toegang tot swarm-bronnen.

De manager-node stuurt in­di­vi­du­e­le eenheden, ook wel taken genoemd, naar worker-nodes.

• Services: services zijn centrale struc­tu­ren in Docker-clusters. Een service de­fi­ni­eert een taak die in een Docker-cluster moet worden uit­ge­voerd. Een service heeft be­trek­king op een groep con­tai­ners die op dezelfde image zijn gebaseerd. Bij het aanmaken van een service geeft de gebruiker aan welke image en commando’s worden gebruikt. Daarnaast bieden services de mo­ge­lijk­heid om ap­pli­ca­ties te schalen. Ge­brui­kers van het Docker-platform de­fi­ni­ë­ren eenvoudig hoeveel con­tai­ners er voor een service moeten worden gestart.
• Taken: om services in het cluster te verdelen, worden ze door het be­heer­knoop­punt opgedeeld in af­zon­der­lij­ke werk­een­he­den (taken). Elke taak omvat een Docker-container en de commando’s die daarin worden uit­ge­voerd.

Naast het beheer van clus­ter­con­tro­le en de co­ör­di­na­tie van con­tai­ners, kunnen manager-knoop­pun­ten standaard ook worker-knoop­punt­func­ties uitvoeren, tenzij u de taken van deze knoop­pun­ten strikt beperkt tot beheer.

Op elke worker node draait een agent­pro­gram­ma. Dit programma ac­cep­teert taken en verstrekt de res­pec­tie­ve principal node sta­tus­rap­por­ten over de voortgang van de over­ge­dra­gen taak. De volgende af­beel­ding toont een sche­ma­ti­sche weergave van een Docker Swarm:

Bij het im­ple­men­te­ren van een Docker Swarm ver­trou­wen ge­brui­kers over het algemeen op de Docker-machine.

Docker Compose

Met Docker Compose is het mogelijk om meerdere con­tai­ners samen te voegen en met één enkele opdracht uit te voeren. Het ba­sis­ele­ment van Compose is het centrale be­stu­rings­be­stand op basis van de bekroonde taal YAML. De syntaxis van dit compose-bestand is ver­ge­lijk­baar met die van de open-source software Vagrant, die wordt gebruikt bij het maken en inrichten van virtuele machines.

In het bestand docker-compose.yml kunt u een wil­le­keu­rig aantal soft­wa­re­con­tai­ners de­fi­ni­ë­ren, inclusief alle af­han­ke­lijk­he­den, evenals hun on­der­lin­ge relaties. Der­ge­lij­ke multi-con­tai­ne­rap­pli­ca­ties worden volgens hetzelfde patroon beheerd als in­di­vi­du­e­le soft­wa­re­con­tai­ners. Gebruik het commandodocker-compose in com­bi­na­tie met het gewenste sub­com­man­do om de volledige le­vens­cy­clus van de ap­pli­ca­tie te beheren.

Deze Docker-tool kan eenvoudig worden ge­ïn­te­greerd in een cluster op basis van Swarm. Op deze manier kunt u multi-container ap­pli­ca­ties die zijn gemaakt met Compose net zo eenvoudig uitvoeren op ge­dis­tri­bu­eer­de systemen als op een enkele Docker-host.

Een ander kenmerk van Docker Compose is een ge­ïn­te­greerd schaal­baar­heids­me­cha­nis­me. Met de or­ches­tra­ti­on tool kunt u eenvoudig via het command-line programma instellen hoeveel con­tai­ners u voor een bepaalde service wilt starten.

Welke Docker-tools van derden zijn er?

Naast de interne ont­wik­ke­ling van Docker Inc. zijn er ver­schil­len­de soft­wa­ret­ools en platforms van externe aan­bie­ders die in­ter­fa­ces voor de Docker Engine bieden of speciaal zijn ont­wik­keld voor het populaire con­tai­ner­plat­form. Binnen het Docker-eco­sys­teem behoren tot de po­pu­lair­ste open-sour­ce­pro­jec­ten de or­ches­tra­ti­on-tool Ku­ber­ne­tes, de clus­ter­ma­na­ge­ment­tool Shipyard, de multi-container shipping-oplossing Panamax, het con­ti­nuous in­te­gra­ti­on-platform Drone, het cloud­ge­ba­seer­de be­stu­rings­sys­teem OpenStack en het D2iQ DC/OS-da­ta­cen­ter­be­stu­rings­sys­teem, dat is gebaseerd op de clus­ter­ma­na­ger Mesos.

Ku­ber­ne­tes

Het is niet altijd mogelijk voor Docker om eigen or­ches­tra­ti­on tools zoals Swarm en Compose te ont­wik­ke­len. Om deze reden in­ves­te­ren ver­schil­len­de bedrijven al jaren in eigen ont­wik­ke­lings­werk om op maat gemaakte tools te creëren die zijn ontworpen om de werking van het con­tai­ner­plat­form in grote, ge­dis­tri­bu­eer­de in­fra­struc­tu­ren te ver­ge­mak­ke­lij­ken. Een van de po­pu­lair­ste op­los­sin­gen van dit type is het open-sour­ce­pro­ject Ku­ber­ne­tes.

Ku­ber­ne­tes is een clus­ter­ma­na­ger voor con­tainer­ge­ba­seer­de ap­pli­ca­ties. Het doel van Ku­ber­ne­tes is om ap­pli­ca­ties in een cluster te au­to­ma­ti­se­ren. Hiervoor maakt de or­ches­tra­ti­on tool gebruik van een REST-API, een command line programma en een grafische we­bin­ter­fa­ce als be­stu­rings­in­ter­fa­ces. Met deze in­ter­fa­ces kunnen au­to­ma­ti­se­rin­gen worden gestart en sta­tus­rap­por­ten worden op­ge­vraagd. Je kunt Ku­ber­ne­tes gebruiken om:

• con­tainer­ge­ba­seer­de foto’s uitvoeren op een cluster,
• ap­pli­ca­ties in­stal­le­ren en beheren in ge­dis­tri­bu­eer­de systemen,
• ap­pli­ca­ties schalen, en
• hardware zo goed mogelijk gebruiken.

Daartoe com­bi­neert Ku­ber­ne­tes con­tai­ners tot logische delen, die pods worden genoemd. Pods vormen de ba­sis­een­he­den van de clus­ter­ma­na­ger, die door middel van planning in de cluster kunnen worden verdeeld.

Net als Docker’s Swarm is Ku­ber­ne­tes ook gebaseerd op een master-worker-ar­chi­tec­tuur. Een cluster bestaat uit een Ku­ber­ne­tes-master en ver­schil­len­de workers, ook wel Ku­ber­ne­tes-knoop­pun­ten (of minions) genoemd. De Ku­ber­ne­tes-master fungeert als een centraal be­stu­rings­vlak in het cluster en bestaat uit vier ba­sis­com­po­nen­ten, waardoor directe com­mu­ni­ca­tie in het cluster en taak­ver­de­ling mogelijk zijn. Een Ku­ber­ne­tes-master bestaat uit een API-server, het con­fi­gu­ra­tie­ge­heu­gen etcd, een planner en een con­trol­ler­be­heer­der.

• API-server: alle au­to­ma­ti­se­rin­gen in het Ku­ber­ne­tes-cluster worden ge­ï­ni­ti­eerd met REST-API via een API-server. Deze fungeert als de centrale be­heer­in­ter­fa­ce in het cluster.
• etcd: je kunt het open-source con­fi­gu­ra­tie­ge­heu­gen etcd zien als het geheugen van een Ku­ber­ne­tes-cluster. De Key Value Store, die CoreOS speciaal voor ge­dis­tri­bu­eer­de systemen heeft ont­wik­keld, slaat con­fi­gu­ra­tie­ge­ge­vens op en maakt deze be­schik­baar voor elk knooppunt in het cluster. De huidige status van een cluster kan op elk moment worden beheerd via etcd.
• Scheduler: de scheduler is ver­ant­woor­de­lijk voor de dis­tri­bu­tie van con­tainer­groe­pen (pods) in het cluster. Hij bepaalt de re­sour­ce­be­hoef­ten van een pod en koppelt deze ver­vol­gens aan de be­schik­ba­re resources van de af­zon­der­lij­ke knoop­pun­ten in het cluster.
• Con­trol­ler manager: de con­trol­ler manager is een service van de Ku­ber­ne­tes-master en regelt de or­kestra­tie door de status van het cluster te reguleren en rou­ti­ne­ta­ken uit te voeren. De be­lang­rijk­ste taak van de con­trol­ler manager is ervoor te zorgen dat de status van het cluster over­een­komt met de ge­de­fi­ni­eer­de doel­sta­tus.

De algemene com­po­nen­ten van de Ku­ber­ne­tes-master kunnen zich op dezelfde host bevinden of verdeeld zijn over meerdere mas­ter­hosts binnen een cluster met hoge be­schik­baar­heid.

Terwijl de Ku­ber­ne­tes-master ver­ant­woor­de­lijk is voor de or­kestra­tie, worden de pods die in het cluster zijn verdeeld, uit­ge­voerd op hosts, Ku­ber­ne­tes-knoop­pun­ten, die on­der­ge­schikt zijn aan de master. Hiervoor moet op elk Ku­ber­ne­tes-knooppunt een container-engine worden uit­ge­voerd. Hoewel Docker de de facto standaard is, hoeft Ku­ber­ne­tes geen spe­ci­fie­ke container-engine te gebruiken.

Naast de container-engine omvatten Ku­ber­ne­tes-knoop­pun­ten de volgende com­po­nen­ten:

• kubelet: kubelet is een agent die op elke Ku­ber­ne­tes-node draait en wordt gebruikt om de node te besturen en te beheren. Als centraal con­tact­punt van elke node is kubelet verbonden met de Ku­ber­ne­tes-master en zorgt ervoor dat in­for­ma­tie wordt door­ge­ge­ven aan en ontvangen van het be­stu­rings­vlak.
• kube-proxy: daarnaast draait de proxy­ser­vi­ce kube-proxy op elke Ku­ber­ne­tes-node. Deze zorgt ervoor dat verzoeken van buitenaf worden door­ge­stuurd naar de be­tref­fen­de con­tai­ners en levert diensten aan ge­brui­kers van con­tainer­ge­ba­seer­de ap­pli­ca­ties. De kube-proxy biedt ook ru­di­men­tai­re load balancing.

De volgende af­beel­ding toont een sche­ma­ti­sche weergave van de master-node-ar­chi­tec­tuur waarop het or­ches­tra­ti­on­plat­form Ku­ber­ne­tes is gebaseerd:

Naast het kern­pro­ject Ku­ber­ne­tes zijn er ook tal van tools en uit­brei­din­gen waarmee je meer func­ti­o­na­li­teit aan het or­ches­tra­ti­on­plat­form kunt toevoegen. De po­pu­lair­ste zijn de mo­ni­to­ring- en fout­dia­gno­setools Pro­me­theus, Weave Scope en sysdig, evenals de pak­ket­be­heer­der Helm. Er zijn ook plug-ins voor Apache Maven en Gradle, evenals een Java API, waarmee je Ku­ber­ne­tes op afstand kunt bedienen.

Scheeps­werf

Shipyard is een door de ge­meen­schap ont­wik­kel­de be­heer­op­los­sing op basis van Swarm waarmee ge­brui­kers Docker-bronnen zoals con­tai­ners, images, hosts en pri­vé­re­gis­ters kunnen beheren via een grafische ge­brui­kers­in­ter­fa­ce. Het is be­schik­baar als we­bap­pli­ca­tie via de browser. Naast de clus­ter­be­heer­func­ties die toe­gan­ke­lijk zijn via een centrale we­bin­ter­fa­ce, biedt Shipyard ook ge­brui­kers­au­then­ti­ca­tie en op rollen ge­ba­seer­de toe­gangs­con­tro­le.

De software is 100% com­pa­ti­bel met de Docker remote API en maakt gebruik van de open-source NoSQL-database RethinkDB om gegevens voor ge­brui­kers­ac­counts, adressen en ge­beur­te­nis­sen op te slaan. De software is gebaseerd op de clus­ter­ma­na­ge­ment-toolkit Citadel en bestaat uit drie hoofd­com­po­nen­ten: con­trol­ler, API en UI.

• Shipyard-con­trol­ler: de con­trol­ler is het kern­on­der­deel van de be­heer­tool Shipyard. De Shipyard-con­trol­ler com­mu­ni­ceert met RethinkDB om gegevens op te slaan en maakt het mogelijk om in­di­vi­du­e­le hosts in een Docker-cluster aan te spreken en ge­beur­te­nis­sen te beheren.
• Shipyard API: de Shipyard API is gebaseerd op REST. Alle functies van de ma­na­ge­ment­tool worden aan­ge­stuurd via de Shipyard API.
• Shipyard-ge­brui­kers­in­ter­fa­ce (UI): de Shipyard-UI is een AngularJS-app die ge­brui­kers een grafische ge­brui­kers­in­ter­fa­ce biedt voor het beheer van Docker-clusters in de web­brow­ser. Alle in­ter­ac­ties in de ge­brui­kers­in­ter­fa­ce vinden plaats via de Shipyard API.

Meer in­for­ma­tie over het open-sour­ce­pro­ject is te vinden op de officiële website van Shipyard.

Panamax

De ont­wik­ke­laars van het open-source soft­wa­re­pro­ject Panamax willen de im­ple­men­ta­tie van multi-container apps ver­een­vou­di­gen. De gratis tool biedt ge­brui­kers een grafische ge­brui­kers­in­ter­fa­ce waarmee complexe ap­pli­ca­ties op basis van Docker-con­tai­ners ge­mak­ke­lijk kunnen worden ont­wik­keld, ge­ïm­ple­men­teerd en ge­dis­tri­bu­eerd met behulp van drag-and-drop.

Panamax maakt het mogelijk om complexe multi-container ap­pli­ca­ties op te slaan als ap­pli­ca­tie­sja­blo­nen en deze met slechts één klik te dis­tri­bu­e­ren in clus­ter­ar­chi­tec­tu­ren. Met behulp van een ge­ïn­te­greer­de app-markt­plaats die wordt gehost op GitHub, kunnen sjablonen voor zelf­ge­maak­te ap­pli­ca­ties worden op­ge­sla­gen in Git-re­po­si­to­ries en be­schik­baar worden gesteld aan andere ge­brui­kers.

De ba­sis­com­po­nen­ten van de Panamax-ar­chi­tec­tuur kunnen worden on­der­ver­deeld in twee groepen: de Panamax Local Client en een wil­le­keu­rig aantal externe im­ple­men­ta­tie­doe­len.

De lokale Panamax-client is het kern­on­der­deel van deze Docker-tool. Deze wordt uit­ge­voerd op het lokale systeem en maakt het mogelijk om complexe con­tainer­ge­ba­seer­de ap­pli­ca­ties te creëren. De lokale client bestaat uit de volgende on­der­de­len:

• CoreOS: voor de in­stal­la­tie van de lokale Panamax-client is de Linux-dis­tri­bu­tie CoreOS als host­sys­teem vereist, dat speciaal is ontworpen voor soft­wa­re­con­tai­ners. De Panamax-client wordt ver­vol­gens als Docker-container in CoreOS uit­ge­voerd. Naast de Docker-functies hebben ge­brui­kers toegang tot ver­schil­len­de CoreOS-functies. Deze omvatten onder andere Fleet en Jour­nalctl:
• Fleet: in plaats van recht­streeks te in­te­gre­ren met Docker, gebruikt de Panamax-client de clus­ter­ma­na­ger Fleet om zijn con­tai­ners te or­ke­stre­ren. Fleet is een clus­ter­ma­na­ger die het Linux-dae­mon­sys­teem systemd in com­pu­ter­clus­ters aanstuurt.
• Jour­nalctl: de Panamax-client gebruikt Jour­nalctl om log­be­rich­ten op te vragen uit het journaal van de Linux-sys­teem­be­heer­der systemd.
• Lokale client-in­stal­la­tie­pro­gram­ma: het lokale client-in­stal­la­tie­pro­gram­ma bevat alle com­po­nen­ten die nodig zijn om de Panamax-client op een lokaal systeem te in­stal­le­ren.
• Lokale Panamax-agent: de centrale component van de lokale client is de lokale agent. Deze is via de Panamax API gekoppeld aan ver­schil­len­de andere com­po­nen­ten en af­han­ke­lijk­he­den. Deze omvatten de lokale Docker-host, de Panamax UI, externe registers en de externe agents van de im­ple­men­ta­tie­doe­len in het cluster. De lokale agent com­mu­ni­ceert via de Panamax API met de volgende programma-in­ter­fa­ces op het lokale systeem om in­for­ma­tie over actieve ap­pli­ca­ties uit te wisselen:
• Docker remote API: Panamax zoekt via de Docker remote API naar images op het lokale systeem en verkrijgt in­for­ma­tie over actieve con­tai­ners.
• etcd API: bestanden worden via de etcd API naar de CoreOS Fleet-daemon verzonden.
• systemd-journal-gatewayd.services: Panamax verkrijgt de jour­naal­uit­voer van actieve services via systemd-journal-gatewayd.services.

Daarnaast maakt de Panamax API ook in­ter­ac­ties met ver­schil­len­de externe API’s mogelijk.

• Docker-register-API: Panamax haalt imagetags op uit het Docker-register via de Docker-register-API.
• GitHub API: Panamax laadt sjablonen uit de GitHub-re­po­si­to­ry met behulp van de GitHub API.
• Kis­sMe­trics API: de Kis­sMe­trics API verzamelt gegevens over sjablonen die ge­brui­kers uitvoeren.
• Panamax UI: de Panamax UI fungeert als een ge­brui­kers­in­ter­fa­ce op het lokale systeem en stelt ge­brui­kers in staat om de Docker-tool te bedienen via een grafische interface. Ge­brui­ker­sin­put wordt recht­streeks door­ge­stuurd naar de lokale agent via de Panamax API. De Panamax UI is gebaseerd op de CTL Base UI Kit, een bi­bli­o­theek met UI-com­po­nen­ten voor web­pro­jec­ten van Cen­tu­ry­Link.

In Panamax-ter­mi­no­lo­gie wordt elk knooppunt in een Docker-cluster zonder be­heer­ta­ken een remote de­ploy­ment target genoemd. De­ploy­ment targets bestaan uit een Docker-host, die is ge­con­fi­gu­reerd om Panamax-sjablonen te im­ple­men­te­ren met behulp van de volgende com­po­nen­ten:

• In­stal­la­tie­pro­gram­ma voor im­ple­men­ta­tie­doel: het in­stal­la­tie­pro­gram­ma voor im­ple­men­ta­tie­doel start een Docker-host, compleet met een Panamax-remote agent en or­ches­tra­ti­on adapter.
• Panamax-agent op afstand: als een Panamax-agent op afstand is ge­ïn­stal­leerd, kunnen ap­pli­ca­ties via de lokale Panamax-client worden ge­dis­tri­bu­eerd naar elk gewenst eindpunt in het cluster. De Panamax-agent op afstand draait als een Docker-container op elk im­ple­men­ta­tie­doel in het cluster.
• Panamax-or­kestra­tie­a­dap­ter: in de or­kestra­tie­a­dap­ter wordt de pro­gram­ma­lo­gi­ca voor elke or­kestra­tie­tool die be­schik­baar is voor Panamax in een on­af­han­ke­lij­ke adap­ter­laag aan­ge­bo­den. Hierdoor hebben ge­brui­kers altijd de mo­ge­lijk­heid om precies die or­kestra­tie­tech­no­lo­gie te kiezen die door hun doe­lom­ge­ving wordt on­der­steund. Vooraf ge­con­fi­gu­reer­de adapters zijn onder andere Ku­ber­ne­tes en Fleet:
• Panamax Ku­ber­ne­tes-adapter: in com­bi­na­tie met de Panamax Remote Agent maakt de Panamax Ku­ber­ne­tes-adapter de dis­tri­bu­tie van Panamax-sjablonen in Ku­ber­ne­tes-clusters mogelijk.
• Panamax Fleet-adapter: in com­bi­na­tie met de Panamax remote agent maakt de Panamax Fleet-adapter de dis­tri­bu­tie van Panamax-sjablonen mogelijk in clusters die worden beheerd met behulp van de Fleet-clus­ter­ma­na­ger.

De volgende af­beel­ding toont de in­ter­ac­tie tussen de af­zon­der­lij­ke Panamax-com­po­nen­ten in een Docker-cluster:

De op CoreOS ge­ba­seer­de Panamax-con­tai­ner­be­heer­tool biedt ge­brui­kers via een grafische ge­brui­kers­in­ter­fa­ce een ver­schei­den­heid aan stan­daard­tech­no­lo­gie­ën voor con­tai­ner­or­kestra­tie, evenals de mo­ge­lijk­heid om complexe multi-con­tai­ne­rap­pli­ca­ties in clus­ter­ar­chi­tec­tu­ren ge­mak­ke­lijk te beheren met behulp van elk systeem (bij­voor­beeld uw eigen laptop).

Met de openbare sja­bloon­bi­bli­o­theek van Panamax hebben Panamax-ge­brui­kers via GitHub toegang tot een openbare sja­bloon­bi­bli­o­theek met ver­schil­len­de bronnen.

Drone

Drone is een slank continu in­te­gra­tie­plat­form met minimale vereisten. Met deze Docker-tool kunt u au­to­ma­tisch uw nieuwste build laden vanuit een Git-re­po­si­to­ry zoals GitHub en deze testen in ge­ï­so­leer­de Docker-con­tai­ners. U kunt elke testsuite uitvoeren en rapporten en sta­tus­be­rich­ten via e-mail verzenden. Voor elke soft­wa­re­test wordt een nieuwe container gemaakt op basis van af­beel­din­gen uit het openbare Docker-register. Dit betekent dat elke openbaar be­schik­ba­re Docker-af­beel­ding kan worden gebruikt als omgeving voor het testen van de code.

Drone is ge­ïn­te­greerd in Docker en wordt on­der­steund door ver­schil­len­de pro­gram­meer­ta­len, zoals PHP, Node.js, Ruby, Go en Python. Het con­tai­ner­plat­form is de enige echte af­han­ke­lijk­heid. U kunt uw eigen per­soon­lij­ke continue in­te­gra­tie­plat­form met Drone creëren op elk systeem waarop Docker kan worden ge­ïn­stal­leerd. Drone on­der­steunt ver­schil­len­de ver­sie­be­heer­re­po­si­to­ries en u kunt een hand­lei­ding voor de stan­daard­in­stal­la­tie met GitHub-in­te­gra­tie vinden op de website van het open source-project onder readme.drone.io.

Het beheer van het continue in­te­gra­tie­plat­form gebeurt via een we­bin­ter­fa­ce. Hier kunt u soft­wa­re­builds vanuit elke Git-re­po­si­to­ry laden, deze sa­men­voe­gen tot ap­pli­ca­ties en het resultaat uitvoeren in een vooraf ge­de­fi­ni­eer­de testom­ge­ving. Hiervoor wordt een .drone.yml-bestand ge­de­fi­ni­eerd dat aangeeft hoe de ap­pli­ca­tie voor elke soft­wa­re­test moet worden gemaakt en uit­ge­voerd.

Drone-ge­brui­kers krijgen een open-source CI-oplossing die de sterke punten van al­ter­na­tie­ve producten zoals Travis en Jenkins com­bi­neert in een ge­bruiks­vrien­de­lij­ke ap­pli­ca­tie.

OpenStack

Als het gaat om het bouwen en ex­ploi­te­ren van open-source cloud­struc­tu­ren, is het open-source cloud­be­stu­rings­sys­teem OpenStack de soft­wa­reo­p­los­sing bij uitstek.

Met OpenStack kunt u computer-, opslag- en net­werk­bron­nen beheren vanuit een centraal dashboard en deze via een we­bin­ter­fa­ce be­schik­baar stellen aan eind­ge­brui­kers.

Het cloud­be­stu­rings­sys­teem is gebaseerd op een modulaire ar­chi­tec­tuur die uit meerdere com­po­nen­ten bestaat:

• Zun (con­tai­ner­ser­vi­ce): Zun is de con­tai­ner­ser­vi­ce van OpenStack en maakt het eenvoudig om ge­con­tai­ne­ri­seer­de ap­pli­ca­ties in de OpenStack-cloud te im­ple­men­te­ren en te beheren. Het doel van Zun is om ge­brui­kers in staat te stellen con­tai­ners te beheren via een REST API zonder dat ze servers of clusters hoeven te beheren. Om Zun te kunnen gebruiken, hebt u drie andere OpenStack-services nodig, namelijk Keystone, Neutorn en kryr-lib­net­work. De func­ti­o­na­li­teit van Zun kan ook worden uit­ge­breid met aan­vul­len­de OpenStack-services zoals Cinder en Glance.
• Neutron (net­werk­com­po­nent): Neutron (voorheen Quantum) is een draagbare, schaal­ba­re API-on­der­steun­de sys­teem­com­po­nent die wordt gebruikt voor net­werk­be­heer. De module biedt een interface voor complexe net­werk­t­o­po­lo­gie­ën en on­der­steunt ver­schil­len­de plug-ins waarmee uit­ge­brei­de net­werk­func­ties kunnen worden ge­ïn­te­greerd.
• kuryr-lib­net­work (Docker-driver): kuryr-lib­net­work is een driver die fungeert als interface tussen Docker en Neutron.
• Cinder (blok­op­slag): Cinder is de bijnaam van een component in de OpenStack-ar­chi­tec­tuur die per­ma­nen­te blok­op­slag biedt voor de werking van VM’s. De module biedt virtuele opslag via een self­ser­vi­ce-API. Hierdoor kunnen eind­ge­brui­kers ge­bruik­ma­ken van op­slag­bron­nen zonder te weten welk apparaat de opslag levert.
• Keystone (iden­ti­teits­ser­vi­ce): Keystone biedt OpenStack-ge­brui­kers een centrale iden­ti­teits­ser­vi­ce. De module func­ti­o­neert als een au­then­ti­ca­tie- en mach­ti­gings­sys­teem tussen de af­zon­der­lij­ke OpenStack-com­po­nen­ten. De toegang tot projecten in de cloud wordt geregeld door tenants. Elke tenant ver­te­gen­woor­digt een gebruiker en er kunnen meerdere ge­brui­ker­stoe­gan­gen met ver­schil­len­de rechten worden ge­de­fi­ni­eerd.
• Glance (beeld­ser­vi­ce): met de Glance-module biedt OpenStack een service waarmee af­beel­din­gen van VM’s kunnen worden op­ge­sla­gen en opgehaald.

Meer in­for­ma­tie over OpenStack-com­po­nen­ten en -services vindt u in ons artikel over OpenStack.

Naast de hierboven genoemde com­po­nen­ten kan de OpenStack-ar­chi­tec­tuur worden uit­ge­breid met ver­schil­len­de modules. Op de website van OpenStack vindt u meer in­for­ma­tie over de ver­schil­len­de optionele modules.

D2iQ DC/OS

DC/OS (Dis­tri­bu­ted Cloud Operating System) is open-source software voor het beheer van ge­dis­tri­bu­eer­de systemen, ont­wik­keld door D2iQ Inc. (voorheen Me­sosp­he­re). Het project is gebaseerd op de open-source clus­ter­ma­na­ger Apache Mesos en is een be­stu­rings­sys­teem voor da­ta­cen­ters. De broncode is voor ge­brui­kers be­schik­baar onder de Apache-licentie versie 2 in de DC/OS-re­po­si­to­ries op GitHub. Een en­ter­pri­se-versie van de software is ook be­schik­baar op d2iq.com. Uit­ge­brei­de pro­ject­do­cu­men­ta­tie is te vinden op dcos.io.

Je kunt DC/OS zien als een Mesos-dis­tri­bu­tie die je alle functies van de clus­ter­ma­na­ger biedt (via een centrale ge­brui­kers­in­ter­fa­ce) en Mesos aan­zien­lijk uitbreidt.

DC/OS maakt gebruik van de ge­dis­tri­bu­eer­de sys­teem­kern van het Mesos-platform. Hierdoor is het mogelijk om de resources van een volledig da­ta­cen­ter te bundelen en te beheren in de vorm van een ge­ag­gre­geerd systeem, zoals een enkele logische server. Op deze manier kunt u volledige clusters van fysieke of virtuele machines net zo eenvoudig beheren als een enkele computer.

De software ver­een­vou­digt de in­stal­la­tie en het beheer van ge­dis­tri­bu­eer­de ap­pli­ca­ties en au­to­ma­ti­seert taken zoals re­sour­ce­be­heer, planning en com­mu­ni­ca­tie tussen processen. Het beheer van een cluster op basis van D2iQ DC/OS en de bij­be­ho­ren­de services vindt plaats via een centraal command line-programma (CLI) of een we­bin­ter­fa­ce (GUI).

DC/OS isoleert de resources van het cluster en biedt gedeelde diensten, zoals service discovery of pak­ket­be­heer. De kern­com­po­nen­ten van de software draaien in een beschermd gebied: de kern­ker­nel. Deze omvat de master- en agent­pro­gram­ma’s van het Mesos-platform, die ver­ant­woor­de­lijk zijn voor re­sour­ce­al­lo­ca­tie, pro­ces­iso­la­tie en be­vei­li­gings­func­ties.

• Mesos-master: de Mesos-master is een mas­ter­pro­ces dat op een mas­ter­knoop­punt draait. Het doel van de Mesos-master is om het re­sour­ce­be­heer te con­tro­le­ren en taken (abstracte werk­een­he­den) te co­ör­di­ne­ren die op een agent­knoop­punt worden uit­ge­voerd. Hiervoor verdeelt de Mesos-master resources over ge­re­gi­streer­de DC/OS-services en ac­cep­teert hij re­sour­ce­rap­por­ten van Mesos-agents.
• Mesos-agents: Mesos-agents zijn processen die op agentac­counts draaien en ver­ant­woor­de­lijk zijn voor het uitvoeren van de taken die door de master worden verdeeld. Mesos-agents leveren re­gel­ma­tig rapporten over de be­schik­ba­re resources in het cluster aan de Mesos-master. Deze worden door de Mesos-master door­ge­stuurd naar een planner (d.w.z. Marathon, Chronos of Cassandra). Deze bepaalt welke taak op welk knooppunt moet worden uit­ge­voerd. De taken worden ver­vol­gens op een ge­ï­so­leer­de manier uit­ge­voerd in een container.

Alle andere sys­teem­com­po­nen­ten en ap­pli­ca­ties die door de Mesos-agents via executor worden uit­ge­voerd, draaien in de ge­brui­kers­ruim­te. De ba­sis­com­po­nen­ten van een standaard DC/OS-in­stal­la­tie zijn de admin router, de Mesos DNS, een ge­dis­tri­bu­eer­de DNS-proxy, de load balancer Minuteman, de scheduler Marathon, Apache ZooKeeper en Exhibitor.

• Admin router: de admin router is een speciaal ge­con­fi­gu­reer­de webserver op basis van NGINX die DC/OS-services en centrale au­then­ti­ca­tie- en proxy­func­ties biedt.
• Mesos DNS: de sys­teem­com­po­nent Mesos DNS biedt service discovery-functies waarmee in­di­vi­du­e­le services en ap­pli­ca­ties in het cluster elkaar kunnen iden­ti­fi­ce­ren via een centraal do­mein­naam­sys­teem (DNS).
• Ge­dis­tri­bu­eer­de DNS-proxy: de ge­dis­tri­bu­eer­de DNS-proxy is een interne DNS-dis­pat­cher.
• Minuteman: de sys­teem­com­po­nent Minuteman func­ti­o­neert als een interne load balancer die werkt op de trans­port­laag (laag 4) van het OSI-re­fe­ren­tie­mo­del.
• DC/OS Marathon: Marathon is een centrale component van het Mesos-platform die in D2iQ DC/OS func­ti­o­neert als een init-systeem (ver­ge­lijk­baar met systemd). Marathon start en con­tro­leert DC/OS-services en -toe­pas­sin­gen in clus­ter­om­ge­vin­gen. Daarnaast biedt de software functies voor hoge be­schik­baar­heid, service discovery, load balancing, health checks en een grafische we­bin­ter­fa­ce.
• Apache ZooKeeper: Apache ZooKeeper is een open source soft­wa­re­com­po­nent die co­ör­di­na­tie­func­ties biedt voor de werking en controle van ap­pli­ca­ties in ge­dis­tri­bu­eer­de systemen. ZooKeeper wordt in D2iQ DC/OS gebruikt voor de co­ör­di­na­tie van alle ge­ïn­stal­leer­de sys­teem­ser­vi­ces.
• Exhibitor: Exhibitor is een sys­teem­com­po­nent die au­to­ma­tisch wordt ge­ïn­stal­leerd en ge­con­fi­gu­reerd met ZooKeeper op elke mas­ter­knoop. Exhibitor biedt ook een grafische ge­brui­kers­in­ter­fa­ce voor ZooKeeper-ge­brui­kers.

Diverse workloads kunnen te­ge­lij­ker­tijd worden uit­ge­voerd op clus­ter­re­sour­ces die zijn sa­men­ge­voegd via DC/OS. Dit maakt bij­voor­beeld pa­ral­lel­le werking mogelijk op het clus­ter­be­stu­rings­sys­teem van big data-systemen, mi­cro­ser­vi­ces of con­tai­ner­plat­forms zoals Hadoop, Spark en Docker.

Binnen het D2iQ Universe is een openbare app-catalogus be­schik­baar voor DC/OS. Hiermee kunt u ap­pli­ca­ties zoals Spark, Cassandra, Chronos, Jenkins of Kafka in­stal­le­ren door simpelweg op de grafische ge­brui­kers­in­ter­fa­ce te klikken.

Welke Docker-tools zijn er voor be­vei­li­ging?

Hoewel in­ge­kap­sel­de processen die in con­tai­ners draaien dezelfde kern delen, gebruikt Docker een aantal tech­nie­ken om ze van elkaar te isoleren. Hiervoor worden meestal kern­func­ties van de Linux-kernel gebruikt, zoals Cgroups en Na­mes­pa­ces.

Con­tai­ners bieden echter nog steeds niet dezelfde mate van isolatie als virtuele machines. Ondanks het gebruik van iso­la­tie­tech­nie­ken zijn be­lang­rij­ke kern­sub­sys­te­men zoals Cgroups en ker­ne­lin­ter­fa­ces in de mappen /sys en /proc via con­tai­ners be­reik­baar.

Het ont­wik­ke­lings­team van Docker heeft erkend dat deze vei­lig­heids­pro­ble­men een obstakel vormen voor de im­ple­men­ta­tie van con­tai­ner­tech­no­lo­gie in pro­duc­tie­sys­te­men. Naast de fun­da­men­te­le iso­la­tie­tech­nie­ken van de Linux-kernel on­der­steu­nen nieuwere versies van Docker Engine ook de fra­me­works AppArmor, SELinux en Seccomp, die fungeren als een soort firewall voor kern­bron­nen.

• AppArmor: met AppArmor worden de toe­gangs­rech­ten van con­tai­ners tot de be­stands­sys­te­men ge­re­gu­leerd.
• SELinux: SELinux biedt een complex re­gu­le­rings­sys­teem waarmee toe­gangs­con­tro­le tot kern­bron­nen kan worden ge­ïm­ple­men­teerd.
• Seccomp: Seccomp (Secure Computing Mode) houdt toezicht op het aanroepen van sys­teem­aan­roe­pen.

Naast deze Docker-tools maakt Docker ook gebruik van Linux-mo­ge­lijk­he­den om de root-rechten te beperken waarmee Docker Engine con­tai­ners start.

Er zijn ook andere vei­lig­heids­ri­si­co’s met be­trek­king tot kwets­baar­he­den in software binnen ap­pli­ca­tie­com­po­nen­ten die worden ge­dis­tri­bu­eerd door het Docker-register. Aangezien in principe iedereen Docker-images kan maken en deze openbaar toe­gan­ke­lijk kan maken voor de community in de Docker Hub, bestaat het risico dat er bij het down­lo­a­den van een image kwaad­aar­di­ge code in uw systeem te­recht­komt. Voordat een ap­pli­ca­tie wordt ge­ïm­ple­men­teerd, moeten Docker-ge­brui­kers ervoor zorgen dat alle code in een image voor de uit­voe­ring van con­tai­ners afkomstig is van een be­trouw­ba­re bron.

Docker biedt een ve­ri­fi­ca­tie­pro­gram­ma waarmee soft­wa­re­le­ve­ran­ciers hun Docker-images kunnen laten con­tro­le­ren en ve­ri­fi­ë­ren. Met dit ve­ri­fi­ca­tie­pro­gram­ma wil Docker het voor ont­wik­ke­laars ge­mak­ke­lij­ker maken om veilige soft­wa­re­toe­le­ve­rings­ke­tens voor hun projecten op te zetten. Naast het verhogen van de vei­lig­heid voor ge­brui­kers, wil het programma soft­wa­re­ont­wik­ke­laars een manier bieden om hun projecten te on­der­schei­den van de vele andere be­schik­ba­re bronnen. Ge­ve­ri­fi­eer­de images worden ge­mar­keerd met een Verified Publisher- badge en krijgen, naast andere voordelen, een hogere positie in de zoek­re­sul­ta­ten van Docker Hub.