Docker Tools

Das um­fas­sen­de Docker-Ökosystem bietet Ent­wick­le­rin­nen und Ent­wick­lern viele Mög­lich­kei­ten, ihre An­wen­dun­gen zu deployen, Container zu or­ches­trie­ren und mehr. Wir stellen Ihnen die wich­tigs­ten Docker-Tools vor und bieten einen Überblick über die be­lieb­tes­ten Dritt­an­bie­ter-Projekte, in denen Docker-Tools auf Open-Source-Basis ent­wi­ckelt werden.

Die es­sen­zi­ells­ten Docker-Tools und -Kom­po­nen­ten

Docker ist heute weit mehr als eine schlanke Plattform für den Betrieb von Software-Con­tai­nern. Um das De­ploy­ment von An­wen­dun­gen über verteilte In­fra­struk­tu­ren und Cloud-Um­ge­bun­gen einfacher, schneller und flexibler zu gestalten, hat das Ent­wick­lungs­team der Kern-Software diverse Docker-Tools an die Seite gestellt. Diese bieten An­wen­de­rin­nen und Anwendern neben Cluster- und Or­ches­trie­rungs­funk­tio­nen einen zentralen App-Markt­platz sowie ein Tool zur Ver­wal­tung von Cloud-Res­sour­cen.

Docker-Engine

Wenn An­wen­den­de von „Docker“ sprechen, ist in der Regel die quell­of­fe­ne Client-Server-Anwendung gemeint, die der Container-Plattform zugrunde liegt. Diese wird in der Docker-Ter­mi­no­lo­gie „Docker-Engine“ genannt. Zentrale Be­stand­tei­le der Docker-Engine sind der Docker-Daemon, eine REST-API und ein CLI (Command Line Interface) als Be­nut­zer­schnitt­stel­le. Dieser Aufbau er­mög­licht es Ihnen, die Docker-Engine über Kom­man­do­zei­len­be­feh­le an­zu­spre­chen und Images, Do­cker­files und Container bequem aus dem Terminal heraus zu verwalten. Eventuell können sich Client und Daemon auf un­ter­schied­li­chen Systemen befinden. Eine Übersicht der wich­tigs­ten Docker-Befehle finden Sie in unserem wei­ter­füh­ren­den Artikel.

Docker-Hub

Mit dem Docker-Hub stellt das Open-Source-Projekt An­wen­de­rin­nen und Anwendern eine cloud­ba­sier­te Registry zur Verfügung, über die sich Docker-Images her­un­ter­la­den, zentral verwalten und mit anderen Docker-Nutzenden teilen lassen. Re­gis­trier­te Nutzende haben die Mög­lich­keit, Docker-Images öf­fent­lich oder in privaten Re­po­si­to­rys abzulegen. Ein in­te­grier­ter Tag-Me­cha­nis­mus er­mög­licht die Ver­sio­nie­rung von Images.

Neben öf­fent­li­chen Re­po­si­to­rys anderer Docker-Nutzender finden Sie im Hub zahl­rei­che Res­sour­cen, die in of­fi­zi­el­len Image-Archiven vom Docker-Ent­wick­lungs­team und bekannten Open-Source-Projekten zur Verfügung gestellt werden. Zu den meist­ge­la­de­nen Docker-Images zählen der schlanke Webserver NGINX, die In-Memory-Datenbank Redis, das Unix-Tool-Kit BusyBox und die Linux-Dis­tri­bu­ti­on Ubuntu.

Ein weiteres Feature des Docker-Hubs sind so­ge­nann­te Or­ga­niza­ti­ons, Ar­beits­grup­pen, die es Nutzenden der Container-Plattform er­mög­li­chen, private Re­po­si­to­rys nur be­stimm­ten Per­so­nen­krei­sen zur Verfügung zu stellen. Zu­gangs­be­rech­ti­gun­gen werden innerhalb einer Or­ga­ni­sa­ti­on über Teams und Grup­pen­zu­ge­hö­rig­kei­ten verwaltet.

Docker Swarm

Die Docker-Engine be­inhal­tet native Funk­tio­nen, die An­wen­den­den das Ma­nage­ment von Docker-Hosts in Clustern, so­ge­nann­ten Schwärmen (Swarms), er­mög­licht. Die in die Docker-Engine in­te­grier­ten Cluster-Ma­nage­ment- und Or­ches­trie­rungs-Funk­tio­nen basieren auf der Toolbox Swarmkit.

Das native Docker-Clus­te­ring-Tool Swarm fasst einen Pool von Docker-Hosts zu einem einzelnen vir­tu­el­len Host zusammen und bedient die Docker-REST-API. Somit kann jedes Docker-Tool, das mit dem Docker-Daemon in Ver­bin­dung steht, auf Swarm zugreifen und über eine beliebige Anzahl von Docker-Hosts skaliert werden. An­wen­den­de nutzen das Docker-Engine-CLI, um Schwärme zu erzeugen, An­wen­dun­gen im Cluster zu verteilen und das Verhalten des Schwarms zu steuern. Eine zu­sätz­li­che Or­ches­trie­rungs-Software ist nicht notwendig.

Docker-Engines, die zu Clustern zu­sam­men­ge­schlos­sen wurden, laufen im Swarm-Mode. Ak­ti­vie­ren Sie diesen, wenn Sie ein neues Cluster erstellen oder einen Docker-Host einem be­stehen­den Schwarm hin­zu­fü­gen möchten. Einzelne Docker-Hosts in einem Cluster werden als „Knoten“ be­zeich­net. Die Knoten eines Clusters können als virtuelle Hosts auf demselben lokalen System laufen, häufiger an­zu­tref­fen ist jedoch ein cloud­ba­sier­ter Aufbau, bei dem die einzelnen Knoten des Docker-Schwarms über ver­schie­de­ne Systeme und In­fra­struk­tu­ren verteilt werden.

Der Software liegt eine Master-Slave-Ar­chi­tek­tur zugrunde. Sollen Aufgaben im Schwarm verteilt werden, übergeben An­wen­den­de einen so­ge­nann­ten Service an den Manager-Node, der als Master des Clusters fungiert. Dieser Master ist für das Sche­du­ling von Con­tai­nern im Cluster zuständig und dient als primäre Be­nut­zer­schnitt­stel­le, um auf Schwarm-Res­sour­cen zu­zu­grei­fen.

Der Manager-Node versendet einzelne Ar­beits­ein­hei­ten, so­ge­nann­te Tasks, an un­ter­ge­ord­ne­te Slaves, die in der Docker-Ter­mi­no­lo­gie „Worker-Nodes“ genannt werden.

• Services: Services sind zentrale Struk­tu­ren in Docker-Clustern. Bei einem Service handelt es sich um eine Gruppe von Con­tai­nern, die auf demselben Image basieren. Ein Service definiert die Tasks, die im Cluster aus­ge­führt werden. An­wen­den­de, die Services erstellen, spe­zi­fi­zie­ren in diesen, welche Images verwendet werden sollen und welche Befehle zur Anwendung kommen. Zudem bieten Services die Mög­lich­keit, An­wen­dun­gen zu skalieren. Nutzende der Docker-Plattform de­fi­nie­ren dazu einfach, wie viele Container für einen Service gestartet werden sollen.
• Tasks: Um Services im Cluster verteilen zu können, werden diese vom Manager-Node in einzelne Ar­beits­ein­hei­ten (Tasks) zerlegt. Jeder Task umfasst einen Docker-Container sowie die Befehle, die in diesem aus­ge­führt werden.

Neben Funk­tio­nen zur Steuerung des Clusters und zur Or­ches­trie­rung von Con­tai­nern bieten Manager-Nodes in der Stan­dard­ein­stel­lung auch Worker-Node-Funk­tio­na­li­tä­ten – es sei denn, Sie be­schrän­ken die Aufgaben eines solchen Mas­ter­kno­tens auf Ma­nage­ment-Tasks.

Auf jedem Worker-Node läuft ein Agent-Programm. Dieses nimmt Tasks entgegen und liefert dem je­wei­li­gen Master-Node Sta­tus­be­rich­te zum Fort­schritt der über­tra­ge­nen Aufgabe. Folgende Grafik zeigt eine sche­ma­ti­sche Dar­stel­lung eines Docker-Schwarms:

Bei der Im­ple­men­tie­rung eines Docker-Schwarms greifen Nut­ze­rin­nen und Nutzer in der Regel auf die Docker-Machine zurück.

Docker Compose

Docker Compose er­mög­licht Ihnen, mehrere Container zu ver­knüp­fen und mit einem einzigen Befehl aus­zu­füh­ren. Das Grund­ele­ment von Compose ist die zentrale Kon­troll­da­tei auf Basis der Aus­zeich­nungs­spra­che YAML. Die Syntax dieses Compose-Files ähnelt der der Open-Source-Software Vagrant, die beim Erstellen und Pro­vi­sio­nie­ren vir­tu­el­ler Maschinen zum Einsatz kommt.

In der Datei docker-compose.yml de­fi­nie­ren Sie beliebig viele Software-Container inklusive aller Ab­hän­gig­kei­ten sowie deren Be­zie­hun­gen zu­ein­an­der. Gesteuert werden solche Multi-Container-Ap­pli­ka­tio­nen nach demselben Schema wie einzelne Software-Container. Nutzen Sie den Befehl docker-compose in Kom­bi­na­ti­on mit dem ge­wünsch­ten Un­ter­be­fehl, um den gesamten Le­bens­zy­klus der Anwendung zu managen.

Das Docker-Tool lässt sich mühelos in ein Cluster auf Basis von Swarm in­te­grie­ren. Auf diese Weise führen Sie mit Compose erstellte Multi-Container-An­wen­dun­gen genauso bequem auf ver­teil­ten Systemen aus wie auf einem einzelnen Docker-Host.

Ein weiteres Feature von Docker Compose ist ein in­te­grier­ter Ska­lie­rungs­me­cha­nis­mus. Mit dem Or­ches­trie­rungs­werk­zeug de­fi­nie­ren Sie bequem über das Kom­man­do­zei­len­pro­gramm, wie viele Container Sie für einen be­stimm­ten Service starten möchten.

Docker-Tools externer Anbieter

Neben den Ei­gen­ent­wick­lun­gen der Docker Inc. finden sich diverse Software-Tools und Platt­for­men externer Anbieter, die Schnitt­stel­len zur Docker-Engine be­reit­stel­len oder speziell für die beliebte Container-Plattform ent­wi­ckelt wurden. Zu den be­kann­tes­ten Open-Source-Projekten des Docker-Öko­sys­tems zählen das Or­ches­trie­rungs­werk­zeug Ku­ber­netes, das Cluster-Ma­nage­ment-Tool Shipyard, die Multi-Container-Shipping-Lösung Panamax, die Con­ti­nuous-In­te­gra­ti­on-Plattform Drone, das Cloud-Be­triebs­sys­tem OpenStack und das auf dem Cluster-Manager Mesos ba­sie­ren­de Da­ten­cen­ter-Be­triebs­sys­tem D2iQ DC/OS.

Ku­ber­netes

Nicht immer konnte Docker mit haus­ei­ge­nen Or­ches­trie­rungs­werk­zeu­gen wie Swarm und Compose aufwarten. Zahl­rei­che Un­ter­neh­men in­ves­tie­ren daher schon seit Jahren eigene Ent­wick­lungs­ar­beit in maß­ge­schnei­der­te Tools, die den Betrieb der Container-Plattform in großen, ver­teil­ten In­fra­struk­tu­ren er­leich­tern sollen. Zu den be­kann­tes­ten Lösungen dieser Art zählt das Open-Source-Projekt Ku­ber­netes.

Bei Ku­ber­netes handelt es sich um einen Cluster-Manager für con­tai­ner­ba­sier­te An­wen­dun­gen. Ziel von Ku­ber­netes ist es, An­wen­dun­gen im Cluster zu au­to­ma­ti­sie­ren. Das Or­ches­trie­rungs­werk­zeug nutzt dazu eine REST-API, das Kom­man­do­zei­len­pro­gramm und eine grafische Web­ober­flä­che als Steu­er­schnitt­stel­len, über die Au­to­ma­tis­men an­ge­sto­ßen und Sta­tus­be­rich­te abgefragt werden können. An­wen­den­de nutzen Ku­ber­netes, um:

• con­tai­ner­ba­sier­te An­wen­dun­gen auf einem Cluster aus­zu­füh­ren,
• An­wen­dun­gen in ver­teil­ten Systemen ein­zu­rich­ten und zu verwalten,
• An­wen­dun­gen zu skalieren und
• die zur Verfügung stehende Hardware best­mög­lich aus­zu­nut­zen.

Dazu fasst Ku­ber­netes Container in logische Teile – so­ge­nann­te Pods – zusammen. Pods stellen die Ba­sis­ein­hei­ten des Cluster-Managers dar, die via Sche­du­ling im Cluster verteilt werden können.

Wie Dockers Swarm liegt auch Ku­ber­netes eine Master-Slave-Ar­chi­tek­tur zugrunde. Ein Cluster setzt sich aus einem Ku­ber­netes-Master sowie einer Vielzahl von Slaves, so­ge­nann­ter Ku­ber­netes-Nodes (auch -Worker oder -Minions) zusammen. Der Ku­ber­netes-Master fungiert als zentrale Kon­trol­l­ebe­ne (Control Plane) im Cluster und besteht aus vier Grund­kom­po­nen­ten, die es er­mög­li­chen, die Kom­mu­ni­ka­ti­on im Cluster zu steuern und Aufgaben zu verteilen. Ein Ku­ber­netes-Master besteht aus einem API-Server, dem Kon­fi­gu­ra­ti­ons­spei­cher etcd, einem Scheduler und einem Con­trol­ler-Manager.

• API-Server: Alle Au­to­ma­tis­men im Ku­ber­netes-Cluster werden per REST-API über einen API-Server an­ge­sto­ßen. Dieser fungiert als zentrale Ad­mi­nis­tra­ti­ons­schnitt­stel­le im Cluster.
• etcd: Den quell­of­fe­nen Kon­fi­gu­ra­ti­ons­spei­cher etcd können Sie sich als Ge­dächt­nis eines Ku­ber­netes-Clusters vor­stel­len. Der von CoreOS speziell für verteilte Systeme ent­wi­ckel­te Key-Value-Store speichert Kon­fi­gu­ra­ti­ons­da­ten und stellt diese jedem Knoten im Cluster zur Verfügung. Über etcd lässt sich somit jederzeit der aktuelle Zustand des Clusters verwalten.
• Scheduler: Der Scheduler ist dafür zuständig, Container-Gruppen (Pods) im Cluster zu verteilen. Dazu ermittelt dieser den Res­sour­cen­be­darf eines Pods und gleicht diesen mit den ver­füg­ba­ren Res­sour­cen der einzelnen Knoten im Cluster ab.
• Con­trol­ler-Manager: Beim Con­trol­ler-Manager handelt es sich um einen Service des Ku­ber­netes-Masters, der den Zustand des Clusters regelt, Rou­ti­ne­auf­ga­ben ausführt und somit die Or­ches­trie­rung steuert. Haupt­auf­ga­be des Con­trol­ler-Managers ist es, dafür zu sorgen, dass der Zustand des Clusters dem de­fi­nier­ten Ziel­zu­stand ent­spricht.

Sämtliche Kom­po­nen­ten des Ku­ber­netes-Masters können sich auf ein und demselben Host befinden oder im Rahmen eines Hoch­ver­füg­bar­keits-Clusters über mehrere Master-Hosts verteilt werden.

Während der Ku­ber­netes-Master für die Or­ches­trie­rung zuständig ist, werden die im Cluster ver­teil­ten Pods auf den dem Master un­ter­stell­ten Hosts, den Ku­ber­netes-Nodes, aus­ge­führt. Dazu muss auf jedem Ku­ber­netes-Node eine Container-Engine laufen. Den De-facto-Standard stellt Docker dar. Ku­ber­netes ist prin­zi­pi­ell jedoch auf keine bestimmte Container-Engine fest­ge­legt.

Neben der Container-Engine umfassen Ku­ber­netes-Nodes zudem folgende Kom­po­nen­ten:

• kubelet: Bei kubelet handelt es sich um einen Agent, der auf jedem Ku­ber­netes-Node aus­ge­führt wird und der Steuerung und Ver­wal­tung des Knotens dient. Als zentraler Kon­takt­punkt eines jeden Knotens steht kubelet mit dem Ku­ber­netes-Master in Ver­bin­dung und sorgt dafür, dass In­for­ma­tio­nen zur Kon­trol­l­ebe­ne wei­ter­ge­lei­tet und von dieser empfangen werden.
• kube-proxy: Zudem läuft auf jedem Ku­ber­netes-Node der Proxy-Service kube-proxy. Dieser sorgt dafür, dass Anfragen von außen zu den je­wei­li­gen Con­tai­nern wei­ter­ge­lei­tet werden, und stellt An­wen­den­den Services con­tai­ner­ba­sier­ter An­wen­dun­gen zur Verfügung. Darüber hinaus bietet der kube-proxy ein ru­di­men­tä­res Load-Balancing.

Folgende Grafik zeigt eine sche­ma­ti­sche Dar­stel­lung der Master-Slave-Ar­chi­tek­tur, die der Or­ches­trie­rungs-Plattform Ku­ber­netes zugrunde liegt:

Neben dem Kern­pro­jekt Ku­ber­netes finden sich zahl­rei­che Werkzeuge und Er­wei­te­run­gen, die es er­mög­li­chen, die Or­ches­trie­rungs­platt­form mit Zu­satz­funk­tio­nen zu versehen. Zu den be­kann­tes­ten gehören die Mo­ni­to­ring- und Feh­ler­dia­gno­se-Tools Pro­me­theus, Weave Scope und sysdig sowie der Paket-Manager Helm. Zudem exis­tie­ren Plug-ins für Apache Maven und Gradle sowie eine Java-API zur Fern­steue­rung von Ku­ber­netes.

Shipyard

Shipyard ist eine von der Docker-Benutzer-Community ent­wi­ckel­te Ma­nage­ment-Lösung auf Basis von Swarm, die es An­wen­den­den er­mög­licht, Docker-Res­sour­cen wie Container, Images, Hosts und private Registrys über eine grafische Be­nut­zer­ober­flä­che zu verwalten. Diese steht als Web­an­wen­dung über den Browser zur Verfügung.

Die Software ist zu 100 Prozent mit der Docker-Remote-API kom­pa­ti­bel und nutzt die quell­of­fe­ne NoSQL-Datenbank RethinkDB als Da­ten­spei­cher für Be­nut­zer­ac­counts, Adressen und Er­eig­nis­se.

Neben Cluster-Ma­nage­ment-Funk­tio­nen über eine zentrale Web­ober­flä­che stellt Shipyard eine Be­nut­zer­au­then­ti­fi­zie­rung sowie eine rol­len­ba­sier­te Zu­gangs­kon­trol­le zur Verfügung.

Die Software basiert auf dem Cluster-Ma­nage­ment-Toolkit Citadel und besteht im We­sent­li­chen aus drei Grund­kom­po­nen­ten: Con­trol­ler, API und UI.

• Shipyard-Con­trol­ler: Der Con­trol­ler ist die Kern­kom­po­nen­te des Ma­nage­ment-Tools Shipyard. Der Shipyard-Con­trol­ler in­ter­agiert mit der RethinkDB im Rahmen der Da­ten­spei­che­rung und er­mög­licht es, einzelne Hosts in einem Docker-Cluster an­zu­spre­chen und Er­eig­nis­se zu steuern.
• Shipyard-API: Bei der Shipyard-API handelt es sich um eine API auf Basis von REST. Alle Funk­tio­nen des Ma­nage­ment-Tools werden über die Shipyard-API gesteuert.
• Shipyard-User-Interface (UI): Die Shipyard-UI ist eine AngularJS-App, die An­wen­den­den eine grafische Be­nut­zer­ober­flä­che zur Ver­wal­tung von Docker-Clustern im Web­brow­ser zur Verfügung stellt. Alle In­ter­ak­tio­nen im User-Interface erfolgen über die Shipyard-API.

Weitere In­for­ma­tio­nen zu Shipyard finden Sie auf der of­fi­zi­el­len Website des Open-Source-Projekts.

Panamax

Das Ent­wick­lungs­team des quell­of­fe­nen Docker-Tools Panamax hat sich das Ziel gesetzt, die Be­reit­stel­lung von Multi-Container-Apps zu ver­ein­fa­chen. Das kos­ten­lo­se Tool bietet Nutzenden eine grafische Be­nut­zer­ober­flä­che, über die sich komplexe An­wen­dun­gen auf Basis von Docker-Con­tai­nern bequem per Drag-and-Drop ent­wi­ckeln, be­reit­stel­len und verteilen lassen.

Panamax er­mög­licht es, komplexe Multi-Container-An­wen­dun­gen als so­ge­nann­te Ap­pli­ca­ti­on-Templates zu speichern und so mit nur einem Klick in Cluster-Ar­chi­tek­tu­ren zu verteilen. Über einen in­te­grier­ten, auf GitHub ge­hos­te­ten App-Markt­platz lassen sich Templates selbst­er­stell­ter An­wen­dun­gen in Git-Re­po­si­to­rys speichern und anderen Nutzenden zur Verfügung stellen. Die Grund­kom­po­nen­ten der Panamax-Ar­chi­tek­tur lassen sich in zwei Gruppen un­ter­tei­len: Man un­ter­schei­det den Panamax-Local-Client und eine beliebige Anzahl so­ge­nann­ter Remote-De­ploy­ment-Targets.

Der Panamax-Local-Client ist die Kern­kom­po­nen­te des Docker-Tools. Dieser wird auf dem lokalen System aus­ge­führt und er­mög­licht es, komplexe An­wen­dun­gen auf Con­tai­ner­ba­sis zu erstellen. Der Local-Client besteht aus folgenden Kom­po­nen­ten:

• CoreOS: Die In­stal­la­ti­on des Panamax-Local-Clients setzt die speziell auf Software-Container aus­ge­rich­te­te Linux-Dis­tri­bu­ti­on CoreOS als Host-System voraus. Der Panamax-Client wird als Docker-Container in CoreOS aus­ge­führt. An­wen­den­den stehen mit Panamax neben den Docker-Features somit diverse CoreOS-Funk­tio­nen zur Verfügung. Zu diesen zählen u. a. Fleet und Jour­nalctl:
  • Fleet: Statt direkt mit Docker zu in­ter­agie­ren, nutzt der Panamax-Client den Cluster-Manager Fleet, um Container zu or­ches­trie­ren. Bei Fleet handelt es sich um einen Cluster-Manager, der den Linux-Daemon systemd in Computer-Clustern steuert.
  • Jour­nalctl: Der Panamax-Client nutzt Jour­nalctl, um Log-Meldungen des Linux-System-Managers systemd aus dem so­ge­nann­ten Journal ab­zu­fra­gen.
• Local Client Installer: Der Local-Client-Installer be­inhal­tet alle Kom­po­nen­ten, die benötigt werden, um den Panamax-Client auf einem lokalen System zu in­stal­lie­ren.
• Panamax-Local-Agent: Die zentrale Kom­po­nen­te des Local Clients ist der Local Agent. Dieser steht über die Panamax-API mit diversen anderen Kom­po­nen­ten und Ab­hän­gig­kei­ten in Ver­bin­dung. Dazu zählen u. a. der lokale Docker-Host, die Panamax-UI, externe Registrys sowie die Remote-Agents auf den De­ploy­ment-Targets im Cluster. Der Local Agent in­ter­agiert über die Panamax-API mit folgenden Pro­gram­mier­schnitt­stel­len auf dem lokalen System, um In­for­ma­tio­nen zu laufenden An­wen­dun­gen aus­zu­tau­schen:
  • Docker-Remote-API: Über die Docker-Remote-API sucht Panamax nach Images auf dem lokalen System und ruft Status-In­for­ma­tio­nen zu laufenden Con­tai­nern ab.
• etcd-API: Über die etcd-API werden Daten an den CoreOS-Fleet-Daemon über­mit­telt.
  • systemd-journal-gatewayd.services: Über systemd-journal-gatewayd.services ruft Panamax den Journal-Output zu laufenden Diensten ab.

Darüber hinaus er­mög­licht die Panamax-API die In­ter­ak­tio­nen mit diversen externen APIs.

• Docker-Registry-API: Über die Docker Registry-API ruft Panamax Image-Tags aus der Docker-Registry ab.
• GitHub-API: Über die GitHub-API lassen sich Panamax-Templates in GitHub-Re­po­si­to­rys laden.
• Kiss­Me­trics-API: Die Kiss­Me­trics-API sammelt Daten über Templates, die User ausführen.
• Panamax-UI: Die Panamax-UI fungiert als Be­nut­zer­schnitt­stel­le auf dem lokalen System und er­mög­licht es An­wen­den­den, das Docker-Tool über eine grafische Ober­flä­che zu steuern. Über die Panamax-API werden Be­nut­zer­ein­ga­ben direkt an den Local Agent wei­ter­ge­lei­tet. Die Panamax-UI basiert auf dem CTL-Base-UI-Kit, einer Bi­blio­thek mit UI-Kom­po­nen­ten für Web­pro­jek­te von Cen­tu­ry­Link.

Jeder Knoten in einem Docker-Cluster ohne Ma­nage­ment-Aufgaben wird in der Panamax-Ter­mi­no­lo­gie Remote-De­ploy­ment-Targets genannt. De­ploy­ment-Targets bestehen aus einem Docker-Host, der mithilfe folgender Kom­po­nen­ten für ein De­ploy­ment von Panamax-Templates kon­fi­gu­riert werden:

• De­ploy­ment-Target-Installer: Der De­ploy­ment-Target-Installer startet einen Docker-Host inklusive Panamax-Remote-Agent und Or­chestra­ti­on-Adapter.
• Panamax-Remote-Agent: Wurde der Panamax-Remote-Agent in­stal­liert, können An­wen­dun­gen über den lokalen Panamax-Client an jeden be­lie­bi­gen Endpunkt im Cluster verteilt werden. Der Panamax-Remote-Agent wird als Docker-Container auf jedem De­ploy­ment-Target im Cluster aus­ge­führt.
• Panamax-Or­chestra­ti­on-Adapter: Im Or­chestra­ti­on-Adapter wird die Pro­gramm­lo­gik eines jeden Or­ches­trie­rungs­werk­zeugs, das für Panamax zur Verfügung steht, in einer un­ab­hän­gi­gen Ad­ap­ter­schicht be­reit­ge­stellt. So hat man die Mög­lich­keit, immer genau die Or­ches­trie­rungs­tech­no­lo­gie aus­zu­wäh­len, die von der je­wei­li­gen Ziel­um­ge­bung un­ter­stützt wird. Bereits vor­kon­fi­gu­rier­te Adapter umfassen Ku­ber­netes und Fleet:
  • Panamax-Ku­ber­netes-Adapter: In Kom­bi­na­ti­on mit dem Panamax-Remote-Agent er­mög­licht der Panamax-Ku­ber­netes-Adapter, Panamax-Templates in Ku­ber­netes-Clustern zu verteilen.
  • Panamax-Fleet-Adapter: In Kom­bi­na­ti­on mit dem Panamax-Remote-Agent er­mög­licht der Panamax-Fleet-Adapter, Panamax-Templates in Clustern zu verteilen, die mithilfe des Cluster-Managers Fleet kon­trol­liert werden.

Folgende Grafik zeigt das Zu­sam­men­spiel der einzelnen Panamax-Kom­po­nen­ten in einem Docker-Cluster:

Das auf CoreOS auf­bau­en­de Container-Ma­nage­ment-Tool Panamax bietet An­wen­den­den diverse Standard-Tech­no­lo­gien zur Container-Or­ches­trie­rung über eine grafische Be­nut­zer­ober­flä­che sowie eine kom­for­ta­ble Mög­lich­keit, komplexe Multi-Container-An­wen­dun­gen in Cluster-Ar­chi­tek­tu­ren über ein be­lie­bi­ges System (z. B. den eigenen Laptop) zu verwalten.

Mit dem Public-Template-Re­po­si­to­ry stellt Panamax Nut­ze­rin­nen und Nutzern via GitHub zudem eine öf­fent­li­che Template-Bi­blio­thek mit diversen Res­sour­cen zur Verfügung.

Drone

Drone ist eine schlanke Con­ti­nuous-In­te­gra­ti­on-Plattform mit minimalen An­for­de­run­gen. Mit dem Docker-Tool können Sie au­to­ma­tisch aus einer Git-Re­po­si­to­ry wie GitHub das neuste Build laden und zu Test­zwe­cken in iso­lier­ten Docker-Container laufen lassen. Sie haben die Mög­lich­keit, jede beliebige Test-Suite aus­zu­füh­ren und sich Reports und Sta­tus­mel­dun­gen via E-Mail zu­schi­cken zu lassen. Für jeden Software-Test wird ein neuer Container auf Basis eines Images aus der öf­fent­li­chen Docker-Registry erstellt. Somit kann jedes öf­fent­lich zu­gäng­li­che Docker-Image als Umgebung für den zu testenden Code zum Einsatz kommen.

Drone ist in Docker in­te­griert und un­ter­stützt diverse Pro­gram­mier­spra­chen wie PHP, Node.js, Ruby, Go oder Python. Die Container-Plattform wird als einzige Ab­hän­gig­keit vor­aus­ge­setzt. Ihre per­sön­li­che Con­ti­nuous-In­te­gra­ti­on-Plattform erstellen Sie mit Drone somit auf jedem be­lie­bi­gen System, auf dem sich Docker in­stal­lie­ren lässt. Drone un­ter­stützt diverse Version-Control-Re­po­si­to­rys. Eine Anleitung zur Stan­dard­in­stal­la­ti­on mit GitHub-In­te­gra­ti­on findet sich in der Do­ku­men­ta­ti­on des Open-Source-Projekts unter readme.drone.io.

Die Steuerung der Con­ti­nuous-In­te­gra­ti­on-Plattform erfolgt über ein Web-Interface. Über dieses laden Sie Software-Builds aus einem be­lie­bi­gen Git-Re­po­si­to­ry, fügen sie zu An­wen­dun­gen zusammen und lassen das Ergebnis in einer zuvor de­fi­nier­ten Test­um­ge­bung laufen. Dazu wird für jeden Software-Test eine .drone.yml-Datei definiert, in der Sie festlegen, wie die Anwendung erstellt und aus­ge­führt werden soll.

Es steht An­wen­de­rin­nen und Anwendern mit Drone eine quell­of­fe­ne CI-Lösung zur Verfügung, die die Stärken al­ter­na­ti­ver Produkte wie Travis und Jenkins in einer be­nut­zer­freund­li­chen Anwendung vereint.

OpenStack

Wenn es um den Aufbau und Betrieb Open-Source-basierter Cloud-Struk­tu­ren geht, ist das quell­of­fe­ne Cloud-Be­triebs­sys­tem OpenStack die Software-Lösung der Wahl. Mit OpenStack lassen sich Rechen-, Speicher- und Netzwerk-Res­sour­cen in einem Re­chen­zen­trum über ein zentrales Dashboard managen und End­nut­zen­den über ein Web-Interface zur Verfügung stellen.

Das Cloud-Be­triebs­sys­tem basiert auf einer modularen Ar­chi­tek­tur, die sich aus mehreren Kom­po­nen­ten zu­sam­men­setzt:

• Zun (Container-Service): Zun ist der Container-Service von OpenStack, der die einfache Be­reit­stel­lung und Ver­wal­tung con­tai­ne­ri­sier­ter An­wen­dun­gen in der OpenStack-Cloud er­mög­licht. Ziel von Zun ist es, Nutzenden die Ver­wal­tung von Con­tai­nern über eine REST-API zu er­mög­li­chen, ohne dass sie Server oder Cluster verwalten müssen. Zun benötigt drei weitere OpenStack-Services, um zu laufen: Keystone, Neutron und kuryr-lib­net­work. Optional kann die Funk­tio­na­li­tät von Zun durch weitere OpenStack-Services wie Cinder und Glance erweitert werden.
• Neutron (Netz­werk­kom­po­nen­te): Neutron (ehemals Quantum) ist eine por­tier­ba­re, ska­lier­ba­re und API-gestützte Sys­tem­kom­po­nen­te, die der Netz­werk­steue­rung dient. Das Modul stellt eine Schnitt­stel­le für komplexe Netzwerk-To­po­lo­gien zur Verfügung und un­ter­stützt diverse Plugins, über die sich er­wei­ter­te Netz­werk­funk­tio­nen einbinden lassen.
• kuryr-lib­net­work (Docker-Treiber): kuryr-lib­net­work ist ein Treiber für Docker, der als Schnitt­stel­le zwischen Docker und Neutron fungiert.
• Keystone (Identity-Service): Mit Keystone steht OpenStack-Nutzenden ein zentraler Identity-Service zur Verfügung. Das Modul fungiert als Au­then­ti­fi­zie­rungs- und Rech­te­sys­tem zwischen den einzelnen OpenStack-Kom­po­nen­ten. Zugriffe auf Projekte in der Cloud werden über so­ge­nann­te Tenants (Mandanten) geregelt. Jeder Mandant stellt eine Nut­zer­ein­heit dar. Pro Nut­zer­ein­heit lassen sich mehrere Be­nut­zer­zu­gän­ge mit un­ter­schied­li­chen Rechten de­fi­nie­ren.
• Cinder (Block-Speicher): Cinder ist der Spitzname einer Kom­po­nen­te der OpenStack-Ar­chi­tek­tur, die per­sis­ten­ten Block-Speicher für den Betrieb von VMs be­reit­hält. Das Modul stellt vir­tu­el­len Speicher über eine Self-Service-API zur Verfügung. Über diese können End­nut­zen­de Spei­cher­res­sour­cen in Anspruch nehmen, ohne dass für sie er­sicht­lich wird, auf welchem Gerät der Speicher be­reit­ge­stellt wird.
• Glance (Image-Service): Mit dem Modul Glance steht OpenStack ein Dienst zur Verfügung, über den sich Images von VMs speichern und abrufen lassen.

Weitere In­for­ma­tio­nen zu OpenStack-Kom­po­nen­ten bzw. -Services finden Sie in unserem wei­ter­füh­ren­den Artikel zu OpenStack. Über diese Kom­po­nen­ten hinaus lässt sich die OpenStack-Ar­chi­tek­tur um diverse optionale Module erweitern. Näheres dazu finden Sie auf der OpenStack-Webseite.

D2iQ DC/OS

DC/OS (Dis­tri­bu­ted Cloud Operating System) ist eine von D2iQ Inc. (früher Me­so­sphe­re) ent­wi­ckel­te Open-Source-Software für den Betrieb ver­teil­ter Systeme. Das Projekt baut auf dem quell­of­fe­nen Cluster-Manager Apache Mesos auf und versteht sich als Be­triebs­sys­tem für Re­chen­zen­tren. Der Quellcode steht An­wen­den­den unter der Apache-Lizenz Version 2 auf GitHub zur Verfügung. Zudem ver­mark­ten die Ent­wi­ckeln­den eine En­ter­pri­se-Version der Software unter d2iq.com. Eine aus­führ­li­che Projekt-Do­ku­men­ta­ti­on findet sich unter dcos.io. Be­trach­ten Sie DC/OS als eine Art Mesos-Dis­tri­bu­ti­on, die Ihnen alle Funk­tio­nen des Cluster-Managers über eine zentrale Be­dien­ober­flä­che be­reit­stellt und Mesos um einiges erweitert.

DC/OS nutzt den ver­teil­ten System-Kernel der Mesos-Plattform. Dies er­mög­licht es, die Res­sour­cen eines ganzen Re­chen­zen­trums zu bündeln und in Form eines agg­re­gier­ten Systems wie einen einzigen logischen Server zu verwalten. So steuern Sie ganze Cluster phy­si­scher oder vir­tu­el­ler Maschinen mit der gleichen Leich­tig­keit, mit der Sie einen einzelnen Rechner bedienen.

Die Software ver­ein­facht die In­stal­la­ti­on und Ver­wal­tung ver­teil­ter An­wen­dun­gen und au­to­ma­ti­siert Aufgaben wie Res­sour­cen­ma­nage­ment, Sche­du­ling und Inter-Prozess-Kom­mu­ni­ka­ti­on. Die Ver­wal­tung eines Clusters auf Basis von D2iQ DC/OS sowie aller darauf aus­ge­führ­ten Dienste erfolgt zentral über ein Kom­man­do­zei­len­pro­gramm (CLI) oder ein Web­in­ter­face (GUI).

DC/OS abs­tra­hiert die Res­sour­cen des Clusters und stellt ge­mein­sa­me Dienste wie Service-Discovery oder Paket-Ma­nage­ment zur Verfügung. Die Kern­kom­po­nen­ten der Software laufen in einem ge­schütz­ten Bereich – dem Kernel-Space. Zu diesem gehören Master- und Agent-Programme der Mesos-Plattform, die für Res­sour­cen­zu­ord­nung, Pro­zes­s­iso­la­ti­on und Si­cher­heits­funk­tio­nen zuständig sind.

• Mesos-Master: Beim Mesos-Master handelt es sich um einen Master-Prozess, der auf einem Master-Knoten im Cluster läuft. Aufgabe des Mesos-Masters ist es, das Res­sour­cen-Ma­nage­ment zu steuern und Tasks (abstrakte Ar­beits­ein­hei­ten) zu or­ches­trie­ren, die auf einem Agent-Knoten aus­ge­führt werden. Dazu verteilt der Mesos-Master Res­sour­cen an re­gis­trier­te DC/OS-Dienste und nimmt Res­sour­cen­be­rich­te von Mesos-Agents entgegen.
• Mesos-Agents: Bei Mesos-Agents handelt es sich um Slave-Prozesse, die auf Agent-Konten laufen und für die Aus­füh­rung der vom Master ver­teil­ten Tasks zuständig sind. Mesos-Agents liefern dem Mesos-Master re­gel­mä­ßi­ge Berichte über die im Cluster zur Verfügung stehenden Res­sour­cen. Diese werden vom Mesos-Master an einen Scheduler (z. B. Marathon, Chronos oder Cassandra) wei­ter­ge­lei­tet. Dieser ent­schei­det, welcher Task auf welchem Knoten aus­ge­führt wird. Die Tasks werden isoliert in einem Container aus­ge­führt.

Alle anderen Sys­tem­kom­po­nen­ten sowie An­wen­dun­gen, die von Mesos-Agents via Executor aus­ge­führt werden, laufen im User-Space. Zu den Grund­kom­po­nen­ten einer Standard-DC/OS-In­stal­la­ti­on gehören der Admin-Router, das Mesos-DNS, ein Dis­tri­bu­ted DNS-Proxy, der Load-Balancer Minuteman, der Scheduler Marathon, Apache ZooKeeper sowie Exhibitor.

• Admin-Router: Der Admin-Router ist ein speziell kon­fi­gu­rier­ter Webserver auf NGINX-Basis, der DC/OS-Dienste sowie zentrale Au­then­ti­fi­zie­rungs- und Proxy-Funk­tio­nen zur Verfügung stellt.
• Mesos-DNS: Die Sys­tem­kom­po­nen­te Mesos-DNS bietet Service-Discovery-Funk­tio­nen, die es den einzelnen Services und An­wen­dun­gen im Cluster er­mög­li­chen, sich ge­gen­sei­tig über ein zentrales Domain-Name-System (DNS) zu iden­ti­fi­zie­ren.
• Dis­tri­bu­ted DNS-Proxy: Beim Dis­tri­bu­ted DNS-Proxy handelt es sich um einen internen DNS-Dis­patcher (Verteiler).
• Minuteman: Die Sys­tem­kom­po­nen­te Minuteman fungiert als interner Load-Balancer, der auf der Transport-Ebene des OSI-Re­fe­renz­mo­dells (Layer 4) arbeitet.
• DC/OS Marathon: Marathon ist eine zentrale Kom­po­nen­te der Mesos-Plattform, die in D2iQ DC/OS als init-System (ähnlich wie systemd) fungiert. Marathon startet und überwacht DC/OS-Dienste und An­wen­dun­gen in Cluster-Um­ge­bun­gen. Darüber hinaus bietet die Software Hoch­ver­füg­bar­keits­funk­tio­nen, Service-Discovery, Load-Balancing, Health-Checks und eine grafische Web­ober­flä­che.
• Apache ZooKeeper: Bei Apache ZooKeeper handelt es sich um eine quell­of­fe­ne Software-Kom­po­nen­te, die Ko­or­di­na­ti­ons­funk­tio­nen für den Betrieb und die Steuerung von An­wen­dun­gen in ver­teil­ten Systemen zur Verfügung stellt. Im Rahmen von D2iQ DC/OS kommt ZooKeeper bei der Ko­or­di­na­ti­on aller in­stal­lier­ten System-Dienste zur Anwendung.
• Exhibitor: Exhibitor ist eine Sys­tem­kom­po­nen­te, mit der sich ZooKeeper auf jedem Master-Knoten im Cluster au­to­ma­tisch in­stal­lie­ren und kon­fi­gu­rie­ren lässt. Darüber hinaus hält Exhibitor eine grafische Be­nut­zer­ober­flä­che für ZooKeeper-An­wen­den­de bereit.

Auf Cluster-Res­sour­cen, die via DC/OS agg­re­giert wurden, lassen sich diverse Workloads gleich­zei­tig ausführen. So er­mög­licht das Cluster-Be­triebs­sys­tem bei­spiels­wei­se einen par­al­le­len Betrieb von Big-Data-Systemen, Mi­cro­ser­vices oder Container-Platt­for­men wie Hadoop, Spark und Docker.

Mit D2iQ Universe steht für DC/OS ein öf­fent­li­cher App-Katalog zur Verfügung. Über diesen in­stal­lie­ren Sie An­wen­dun­gen wie Spark, Cassandra, Chronos, Jenkins oder Kafka bequem mit einem Klick über die grafische Be­nut­zer­ober­flä­che.

Docker-Tools für Si­cher­heit

Auch wenn in Con­tai­nern ge­kap­sel­te Prozesse auf demselben Kernel laufen, nutzt Docker eine Reihe von Iso­la­ti­ons­tech­ni­ken, um diese von­ein­an­der ab­zu­schir­men. Vor allem werden Kern­funk­tio­nen des Linux-Kernels wie Cgroups und Name­spaces ein­ge­setzt.

Dennoch bieten Container nicht denselben Iso­la­ti­ons­grad, der sich mithilfe vir­tu­el­ler Maschinen rea­li­sie­ren lässt. Trotz der be­schrie­be­nen Iso­la­ti­ons­tech­ni­ken lassen sich bei­spiels­wei­se aus Con­tai­nern heraus wichtige Kernel-Sub­sys­te­me wie Cgroups sowie Ker­nel­schnitt­stel­len in den Ver­zeich­nis­sen /sys und /proc erreichen. Auch das Docker-Ent­wick­lungs­team hat die Si­cher­heits­be­den­ken als Bremse für die Eta­blie­rung der Container-Tech­no­lo­gie auf Pro­duk­tiv­sys­te­men erkannt. Neben den grund­le­gen­den Iso­la­ti­ons­tech­ni­ken des Linux-Kernels un­ter­stüt­zen neuere Versionen der Docker-Engine daher die Frame­works AppArmor, SELinux und Seccomp, die als eine Art Firewall für Kernel-Res­sour­cen fungieren.

• AppArmor: Mit AppArmor lassen sich Zu­griffs­rech­te von Con­tai­nern auf das Da­tei­sys­tem re­gle­men­tie­ren.
• SELinux: SELinux bietet ein komplexes Re­gel­sys­tem, mit dem Zu­griffs­kon­trol­len auf Kernel-Res­sour­cen im­ple­men­tiert werden können.
• Seccomp: Mit Seccomp (Secure Computing Mode) wird der Aufruf von Sys­tem­calls überwacht.

Über diese Docker-Tools hinaus nutzt Docker so­ge­nann­te Linux-Ca­pa­bi­li­ties, über die sich die Root-Rechte ein­schrän­ken lassen, mit denen die Docker-Engine Container startet.

Weitere Si­cher­heits­be­den­ken bestehen zudem in Bezug auf Software-Schwach­stel­len innerhalb von An­wen­dungs­kom­po­nen­ten, die über die Docker-Registry ver­brei­tet werden. Da prin­zi­pi­ell jeder Docker-Images erstellen und für die Community öf­fent­lich zu­gäng­lich im Docker-Hub ablegen kann, besteht die Gefahr, schäd­li­chen Code im Rahmen eines Image-Downloads ins eigene System ein­zu­füh­ren. Docker-Nutzende sollten daher vor dem De­ploy­ment einer Anwendung si­cher­stel­len, dass der gesamte Code, der in einem Image zur Aus­füh­rung von Con­tai­nern be­reit­ge­stellt wird, aus einer ver­trau­ens­wür­di­gen Quelle stammt. Docker bietet dafür im Rahmen der En­ter­pri­se-Edition (EE) der Container-Plattform seit Anfang 2017 ein Zer­ti­fi­zie­rungs­pro­gramm an, über das In­fra­struk­tur-, Container- und Plug-in-Anbieter Ihre Software prüfen und aus­zeich­nen lassen können. Um ein Zer­ti­fi­kat zu erhalten, müssen folgende Vor­aus­set­zun­gen erfüllt sein:

• In­fra­struk­tur-Zer­ti­fi­zie­rung: Software-Ent­wi­ckeln­den, die zer­ti­fi­zier­te In­fra­struk­tur-Kom­po­nen­ten für das Docker-Ökosystem be­reit­stel­len möchten, müssen mithilfe ent­spre­chen­der Tests nach­wei­sen, dass ihr Produkt für eine Zu­sam­men­ar­beit mit der Docker-Plattform optimiert wurde.
• Container-Zer­ti­fi­zie­rung: Ein Container wird nur dann mit dem of­fi­zi­el­len Docker-Zer­ti­fi­kat aus­ge­zeich­net, wenn dieser gemäß Best Practices erstellt wurde und sämtliche Software-Tests, Schwach­stel­len-Checks und Si­cher­heits­über­prü­fun­gen bestanden hat.
• Plug-ins: Ein Plug-in für Docker EE darf sich mit dem Docker-Zer­ti­fi­kat schmücken, wenn es gemäß Best Practices ent­wi­ckelt wurde und sämtliche API-Com­pli­ance-Tests und Schwach­stel­len-Checks bestanden hat.

Neben einem Zugewinn an Si­cher­heit für An­wen­den­de sollen Docker-Zer­ti­fi­ka­te Software-Ent­wi­ckeln­den eine Mög­lich­keit bieten, sich mit ihren Projekten von der Vielzahl der zur Verfügung stehenden Res­sour­cen abzuheben.