Docker Tools

Das umfassende Docker-Ökosystem bietet Entwicklerinnen und Entwicklern viele Möglichkeiten, ihre Anwendungen zu deployen, Container zu orchestrieren und mehr. Wir stellen Ihnen die wichtigsten Docker-Tools vor und bieten einen Überblick über die beliebtesten Drittanbieter-Projekte, in denen Docker-Tools auf Open-Source-Basis entwickelt werden.

Die essenziellsten Docker-Tools und -Komponenten

Docker ist heute weit mehr als eine schlanke Plattform für den Betrieb von Software-Containern. Um das Deployment von Anwendungen über verteilte Infrastrukturen und Cloud-Umgebungen einfacher, schneller und flexibler zu gestalten, hat das Entwicklungsteam der Kern-Software diverse Docker-Tools an die Seite gestellt. Diese bieten Anwenderinnen und Anwendern neben Cluster- und Orchestrierungsfunktionen einen zentralen App-Marktplatz sowie ein Tool zur Verwaltung von Cloud-Ressourcen.

Docker-Engine

Wenn Anwendende von „Docker“ sprechen, ist in der Regel die quelloffene Client-Server-Anwendung gemeint, die der Container-Plattform zugrunde liegt. Diese wird in der Docker-Terminologie „Docker-Engine“ genannt. Zentrale Bestandteile der Docker-Engine sind der Docker-Daemon, eine REST-API und ein CLI (Command Line Interface) als Benutzerschnittstelle. Dieser Aufbau ermöglicht es Ihnen, die Docker-Engine über Kommandozeilenbefehle anzusprechen und Images, Dockerfiles und Container bequem aus dem Terminal heraus zu verwalten. Eventuell können sich Client und Daemon auf unterschiedlichen Systemen befinden. Eine Übersicht der wichtigsten Docker-Befehle finden Sie in unserem weiterführenden Artikel.

Docker-Hub

Mit dem Docker-Hub stellt das Open-Source-Projekt Anwenderinnen und Anwendern eine cloudbasierte Registry zur Verfügung, über die sich Docker-Images herunterladen, zentral verwalten und mit anderen Docker-Nutzenden teilen lassen. Registrierte Nutzende haben die Möglichkeit, Docker-Images öffentlich oder in privaten Repositorys abzulegen. Ein integrierter Tag-Mechanismus ermöglicht die Versionierung von Images.

Neben öffentlichen Repositorys anderer Docker-Nutzender finden Sie im Hub zahlreiche Ressourcen, die in offiziellen Image-Archiven vom Docker-Entwicklungsteam und bekannten Open-Source-Projekten zur Verfügung gestellt werden. Zu den meistgeladenen Docker-Images zählen der schlanke Webserver NGINX, die In-Memory-Datenbank Redis, das Unix-Tool-Kit BusyBox und die Linux-Distribution Ubuntu.

Ein weiteres Feature des Docker-Hubs sind sogenannte Organizations, Arbeitsgruppen, die es Nutzenden der Container-Plattform ermöglichen, private Repositorys nur bestimmten Personenkreisen zur Verfügung zu stellen. Zugangsberechtigungen werden innerhalb einer Organisation über Teams und Gruppenzugehörigkeiten verwaltet.

Docker Swarm

Die Docker-Engine beinhaltet native Funktionen, die Anwendenden das Management von Docker-Hosts in Clustern, sogenannten Schwärmen (Swarms), ermöglicht. Die in die Docker-Engine integrierten Cluster-Management- und Orchestrierungs-Funktionen basieren auf der Toolbox Swarmkit.

Das native Docker-Clustering-Tool Swarm fasst einen Pool von Docker-Hosts zu einem einzelnen virtuellen Host zusammen und bedient die Docker-REST-API. Somit kann jedes Docker-Tool, das mit dem Docker-Daemon in Verbindung steht, auf Swarm zugreifen und über eine beliebige Anzahl von Docker-Hosts skaliert werden. Anwendende nutzen das Docker-Engine-CLI, um Schwärme zu erzeugen, Anwendungen im Cluster zu verteilen und das Verhalten des Schwarms zu steuern. Eine zusätzliche Orchestrierungs-Software ist nicht notwendig.

Docker-Engines, die zu Clustern zusammengeschlossen wurden, laufen im Swarm-Mode. Aktivieren Sie diesen, wenn Sie ein neues Cluster erstellen oder einen Docker-Host einem bestehenden Schwarm hinzufügen möchten. Einzelne Docker-Hosts in einem Cluster werden als „Knoten“ bezeichnet. Die Knoten eines Clusters können als virtuelle Hosts auf demselben lokalen System laufen, häufiger anzutreffen ist jedoch ein cloudbasierter Aufbau, bei dem die einzelnen Knoten des Docker-Schwarms über verschiedene Systeme und Infrastrukturen verteilt werden.

Der Software liegt eine Master-Slave-Architektur zugrunde. Sollen Aufgaben im Schwarm verteilt werden, übergeben Anwendende einen sogenannten Service an den Manager-Node, der als Master des Clusters fungiert. Dieser Master ist für das Scheduling von Containern im Cluster zuständig und dient als primäre Benutzerschnittstelle, um auf Schwarm-Ressourcen zuzugreifen.

Der Manager-Node versendet einzelne Arbeitseinheiten, sogenannte Tasks, an untergeordnete Slaves, die in der Docker-Terminologie „Worker-Nodes“ genannt werden.

• Services: Services sind zentrale Strukturen in Docker-Clustern. Bei einem Service handelt es sich um eine Gruppe von Containern, die auf demselben Image basieren. Ein Service definiert die Tasks, die im Cluster ausgeführt werden. Anwendende, die Services erstellen, spezifizieren in diesen, welche Images verwendet werden sollen und welche Befehle zur Anwendung kommen. Zudem bieten Services die Möglichkeit, Anwendungen zu skalieren. Nutzende der Docker-Plattform definieren 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 Arbeitseinheiten (Tasks) zerlegt. Jeder Task umfasst einen Docker-Container sowie die Befehle, die in diesem ausgeführt werden.

Neben Funktionen zur Steuerung des Clusters und zur Orchestrierung von Containern bieten Manager-Nodes in der Standardeinstellung auch Worker-Node-Funktionalitäten – es sei denn, Sie beschränken die Aufgaben eines solchen Masterknotens auf Management-Tasks.

Auf jedem Worker-Node läuft ein Agent-Programm. Dieses nimmt Tasks entgegen und liefert dem jeweiligen Master-Node Statusberichte zum Fortschritt der übertragenen Aufgabe. Folgende Grafik zeigt eine schematische Darstellung eines Docker-Schwarms:

Bei der Implementierung eines Docker-Schwarms greifen Nutzerinnen und Nutzer in der Regel auf die Docker-Machine zurück.

Docker Compose

Docker Compose ermöglicht Ihnen, mehrere Container zu verknüpfen und mit einem einzigen Befehl auszuführen. Das Grundelement von Compose ist die zentrale Kontrolldatei auf Basis der Auszeichnungssprache YAML. Die Syntax dieses Compose-Files ähnelt der der Open-Source-Software Vagrant, die beim Erstellen und Provisionieren virtueller Maschinen zum Einsatz kommt.

In der Datei docker-compose.yml definieren Sie beliebig viele Software-Container inklusive aller Abhängigkeiten sowie deren Beziehungen zueinander. Gesteuert werden solche Multi-Container-Applikationen nach demselben Schema wie einzelne Software-Container. Nutzen Sie den Befehl docker-compose in Kombination mit dem gewünschten Unterbefehl, um den gesamten Lebenszyklus der Anwendung zu managen.

Das Docker-Tool lässt sich mühelos in ein Cluster auf Basis von Swarm integrieren. Auf diese Weise führen Sie mit Compose erstellte Multi-Container-Anwendungen genauso bequem auf verteilten Systemen aus wie auf einem einzelnen Docker-Host.

Ein weiteres Feature von Docker Compose ist ein integrierter Skalierungsmechanismus. Mit dem Orchestrierungswerkzeug definieren Sie bequem über das Kommandozeilenprogramm, wie viele Container Sie für einen bestimmten Service starten möchten.

Docker-Tools externer Anbieter

Neben den Eigenentwicklungen der Docker Inc. finden sich diverse Software-Tools und Plattformen externer Anbieter, die Schnittstellen zur Docker-Engine bereitstellen oder speziell für die beliebte Container-Plattform entwickelt wurden. Zu den bekanntesten Open-Source-Projekten des Docker-Ökosystems zählen das Orchestrierungswerkzeug Kubernetes, das Cluster-Management-Tool Shipyard, die Multi-Container-Shipping-Lösung Panamax, die Continuous-Integration-Plattform Drone, das Cloud-Betriebssystem OpenStack und das auf dem Cluster-Manager Mesos basierende Datencenter-Betriebssystem D2iQ DC/OS.

Kubernetes

Nicht immer konnte Docker mit hauseigenen Orchestrierungswerkzeugen wie Swarm und Compose aufwarten. Zahlreiche Unternehmen investieren daher schon seit Jahren eigene Entwicklungsarbeit in maßgeschneiderte Tools, die den Betrieb der Container-Plattform in großen, verteilten Infrastrukturen erleichtern sollen. Zu den bekanntesten Lösungen dieser Art zählt das Open-Source-Projekt Kubernetes.

Bei Kubernetes handelt es sich um einen Cluster-Manager für containerbasierte Anwendungen. Ziel von Kubernetes ist es, Anwendungen im Cluster zu automatisieren. Das Orchestrierungswerkzeug nutzt dazu eine REST-API, das Kommandozeilenprogramm und eine grafische Weboberfläche als Steuerschnittstellen, über die Automatismen angestoßen und Statusberichte abgefragt werden können. Anwendende nutzen Kubernetes, um:

• containerbasierte Anwendungen auf einem Cluster auszuführen,
• Anwendungen in verteilten Systemen einzurichten und zu verwalten,
• Anwendungen zu skalieren und
• die zur Verfügung stehende Hardware bestmöglich auszunutzen.

Dazu fasst Kubernetes Container in logische Teile – sogenannte Pods – zusammen. Pods stellen die Basiseinheiten des Cluster-Managers dar, die via Scheduling im Cluster verteilt werden können.

Wie Dockers Swarm liegt auch Kubernetes eine Master-Slave-Architektur zugrunde. Ein Cluster setzt sich aus einem Kubernetes-Master sowie einer Vielzahl von Slaves, sogenannter Kubernetes-Nodes (auch -Worker oder -Minions) zusammen. Der Kubernetes-Master fungiert als zentrale Kontrollebene (Control Plane) im Cluster und besteht aus vier Grundkomponenten, die es ermöglichen, die Kommunikation im Cluster zu steuern und Aufgaben zu verteilen. Ein Kubernetes-Master besteht aus einem API-Server, dem Konfigurationsspeicher etcd, einem Scheduler und einem Controller-Manager.

• API-Server: Alle Automatismen im Kubernetes-Cluster werden per REST-API über einen API-Server angestoßen. Dieser fungiert als zentrale Administrationsschnittstelle im Cluster.
• etcd: Den quelloffenen Konfigurationsspeicher etcd können Sie sich als Gedächtnis eines Kubernetes-Clusters vorstellen. Der von CoreOS speziell für verteilte Systeme entwickelte Key-Value-Store speichert Konfigurationsdaten 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 Ressourcenbedarf eines Pods und gleicht diesen mit den verfügbaren Ressourcen der einzelnen Knoten im Cluster ab.
• Controller-Manager: Beim Controller-Manager handelt es sich um einen Service des Kubernetes-Masters, der den Zustand des Clusters regelt, Routineaufgaben ausführt und somit die Orchestrierung steuert. Hauptaufgabe des Controller-Managers ist es, dafür zu sorgen, dass der Zustand des Clusters dem definierten Zielzustand entspricht.

Sämtliche Komponenten des Kubernetes-Masters können sich auf ein und demselben Host befinden oder im Rahmen eines Hochverfügbarkeits-Clusters über mehrere Master-Hosts verteilt werden.

Während der Kubernetes-Master für die Orchestrierung zuständig ist, werden die im Cluster verteilten Pods auf den dem Master unterstellten Hosts, den Kubernetes-Nodes, ausgeführt. Dazu muss auf jedem Kubernetes-Node eine Container-Engine laufen. Den De-facto-Standard stellt Docker dar. Kubernetes ist prinzipiell jedoch auf keine bestimmte Container-Engine festgelegt.

Neben der Container-Engine umfassen Kubernetes-Nodes zudem folgende Komponenten:

• kubelet: Bei kubelet handelt es sich um einen Agent, der auf jedem Kubernetes-Node ausgeführt wird und der Steuerung und Verwaltung des Knotens dient. Als zentraler Kontaktpunkt eines jeden Knotens steht kubelet mit dem Kubernetes-Master in Verbindung und sorgt dafür, dass Informationen zur Kontrollebene weitergeleitet und von dieser empfangen werden.
• kube-proxy: Zudem läuft auf jedem Kubernetes-Node der Proxy-Service kube-proxy. Dieser sorgt dafür, dass Anfragen von außen zu den jeweiligen Containern weitergeleitet werden, und stellt Anwendenden Services containerbasierter Anwendungen zur Verfügung. Darüber hinaus bietet der kube-proxy ein rudimentäres Load-Balancing.

Folgende Grafik zeigt eine schematische Darstellung der Master-Slave-Architektur, die der Orchestrierungs-Plattform Kubernetes zugrunde liegt:

Neben dem Kernprojekt Kubernetes finden sich zahlreiche Werkzeuge und Erweiterungen, die es ermöglichen, die Orchestrierungsplattform mit Zusatzfunktionen zu versehen. Zu den bekanntesten gehören die Monitoring- und Fehlerdiagnose-Tools Prometheus, Weave Scope und sysdig sowie der Paket-Manager Helm. Zudem existieren Plug-ins für Apache Maven und Gradle sowie eine Java-API zur Fernsteuerung von Kubernetes.

Shipyard

Shipyard ist eine von der Docker-Benutzer-Community entwickelte Management-Lösung auf Basis von Swarm, die es Anwendenden ermöglicht, Docker-Ressourcen wie Container, Images, Hosts und private Registrys über eine grafische Benutzeroberfläche zu verwalten. Diese steht als Webanwendung über den Browser zur Verfügung.

Die Software ist zu 100 Prozent mit der Docker-Remote-API kompatibel und nutzt die quelloffene NoSQL-Datenbank RethinkDB als Datenspeicher für Benutzeraccounts, Adressen und Ereignisse.

Neben Cluster-Management-Funktionen über eine zentrale Weboberfläche stellt Shipyard eine Benutzerauthentifizierung sowie eine rollenbasierte Zugangskontrolle zur Verfügung.

Die Software basiert auf dem Cluster-Management-Toolkit Citadel und besteht im Wesentlichen aus drei Grundkomponenten: Controller, API und UI.

• Shipyard-Controller: Der Controller ist die Kernkomponente des Management-Tools Shipyard. Der Shipyard-Controller interagiert mit der RethinkDB im Rahmen der Datenspeicherung und ermöglicht es, einzelne Hosts in einem Docker-Cluster anzusprechen und Ereignisse zu steuern.
• Shipyard-API: Bei der Shipyard-API handelt es sich um eine API auf Basis von REST. Alle Funktionen des Management-Tools werden über die Shipyard-API gesteuert.
• Shipyard-User-Interface (UI): Die Shipyard-UI ist eine AngularJS-App, die Anwendenden eine grafische Benutzeroberfläche zur Verwaltung von Docker-Clustern im Webbrowser zur Verfügung stellt. Alle Interaktionen im User-Interface erfolgen über die Shipyard-API.

Weitere Informationen zu Shipyard finden Sie auf der offiziellen Website des Open-Source-Projekts.

Panamax

Das Entwicklungsteam des quelloffenen Docker-Tools Panamax hat sich das Ziel gesetzt, die Bereitstellung von Multi-Container-Apps zu vereinfachen. Das kostenlose Tool bietet Nutzenden eine grafische Benutzeroberfläche, über die sich komplexe Anwendungen auf Basis von Docker-Containern bequem per Drag-and-Drop entwickeln, bereitstellen und verteilen lassen.

Panamax ermöglicht es, komplexe Multi-Container-Anwendungen als sogenannte Application-Templates zu speichern und so mit nur einem Klick in Cluster-Architekturen zu verteilen. Über einen integrierten, auf GitHub gehosteten App-Marktplatz lassen sich Templates selbsterstellter Anwendungen in Git-Repositorys speichern und anderen Nutzenden zur Verfügung stellen. Die Grundkomponenten der Panamax-Architektur lassen sich in zwei Gruppen unterteilen: Man unterscheidet den Panamax-Local-Client und eine beliebige Anzahl sogenannter Remote-Deployment-Targets.

Der Panamax-Local-Client ist die Kernkomponente des Docker-Tools. Dieser wird auf dem lokalen System ausgeführt und ermöglicht es, komplexe Anwendungen auf Containerbasis zu erstellen. Der Local-Client besteht aus folgenden Komponenten:

• CoreOS: Die Installation des Panamax-Local-Clients setzt die speziell auf Software-Container ausgerichtete Linux-Distribution CoreOS als Host-System voraus. Der Panamax-Client wird als Docker-Container in CoreOS ausgeführt. Anwendenden stehen mit Panamax neben den Docker-Features somit diverse CoreOS-Funktionen zur Verfügung. Zu diesen zählen u. a. Fleet und Journalctl:
  • Fleet: Statt direkt mit Docker zu interagieren, nutzt der Panamax-Client den Cluster-Manager Fleet, um Container zu orchestrieren. Bei Fleet handelt es sich um einen Cluster-Manager, der den Linux-Daemon systemd in Computer-Clustern steuert.
  • Journalctl: Der Panamax-Client nutzt Journalctl, um Log-Meldungen des Linux-System-Managers systemd aus dem sogenannten Journal abzufragen.
• Local Client Installer: Der Local-Client-Installer beinhaltet alle Komponenten, die benötigt werden, um den Panamax-Client auf einem lokalen System zu installieren.
• Panamax-Local-Agent: Die zentrale Komponente des Local Clients ist der Local Agent. Dieser steht über die Panamax-API mit diversen anderen Komponenten und Abhängigkeiten in Verbindung. Dazu zählen u. a. der lokale Docker-Host, die Panamax-UI, externe Registrys sowie die Remote-Agents auf den Deployment-Targets im Cluster. Der Local Agent interagiert über die Panamax-API mit folgenden Programmierschnittstellen auf dem lokalen System, um Informationen zu laufenden Anwendungen auszutauschen:
  • Docker-Remote-API: Über die Docker-Remote-API sucht Panamax nach Images auf dem lokalen System und ruft Status-Informationen zu laufenden Containern ab.
• etcd-API: Über die etcd-API werden Daten an den CoreOS-Fleet-Daemon übermittelt.
  • systemd-journal-gatewayd.services: Über systemd-journal-gatewayd.services ruft Panamax den Journal-Output zu laufenden Diensten ab.

Darüber hinaus ermöglicht die Panamax-API die Interaktionen 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-Repositorys laden.
• KissMetrics-API: Die KissMetrics-API sammelt Daten über Templates, die User ausführen.
• Panamax-UI: Die Panamax-UI fungiert als Benutzerschnittstelle auf dem lokalen System und ermöglicht es Anwendenden, das Docker-Tool über eine grafische Oberfläche zu steuern. Über die Panamax-API werden Benutzereingaben direkt an den Local Agent weitergeleitet. Die Panamax-UI basiert auf dem CTL-Base-UI-Kit, einer Bibliothek mit UI-Komponenten für Webprojekte von CenturyLink.

Jeder Knoten in einem Docker-Cluster ohne Management-Aufgaben wird in der Panamax-Terminologie Remote-Deployment-Targets genannt. Deployment-Targets bestehen aus einem Docker-Host, der mithilfe folgender Komponenten für ein Deployment von Panamax-Templates konfiguriert werden:

• Deployment-Target-Installer: Der Deployment-Target-Installer startet einen Docker-Host inklusive Panamax-Remote-Agent und Orchestration-Adapter.
• Panamax-Remote-Agent: Wurde der Panamax-Remote-Agent installiert, können Anwendungen über den lokalen Panamax-Client an jeden beliebigen Endpunkt im Cluster verteilt werden. Der Panamax-Remote-Agent wird als Docker-Container auf jedem Deployment-Target im Cluster ausgeführt.
• Panamax-Orchestration-Adapter: Im Orchestration-Adapter wird die Programmlogik eines jeden Orchestrierungswerkzeugs, das für Panamax zur Verfügung steht, in einer unabhängigen Adapterschicht bereitgestellt. So hat man die Möglichkeit, immer genau die Orchestrierungstechnologie auszuwählen, die von der jeweiligen Zielumgebung unterstützt wird. Bereits vorkonfigurierte Adapter umfassen Kubernetes und Fleet:
  • Panamax-Kubernetes-Adapter: In Kombination mit dem Panamax-Remote-Agent ermöglicht der Panamax-Kubernetes-Adapter, Panamax-Templates in Kubernetes-Clustern zu verteilen.
  • Panamax-Fleet-Adapter: In Kombination mit dem Panamax-Remote-Agent ermöglicht der Panamax-Fleet-Adapter, Panamax-Templates in Clustern zu verteilen, die mithilfe des Cluster-Managers Fleet kontrolliert werden.

Folgende Grafik zeigt das Zusammenspiel der einzelnen Panamax-Komponenten in einem Docker-Cluster:

Das auf CoreOS aufbauende Container-Management-Tool Panamax bietet Anwendenden diverse Standard-Technologien zur Container-Orchestrierung über eine grafische Benutzeroberfläche sowie eine komfortable Möglichkeit, komplexe Multi-Container-Anwendungen in Cluster-Architekturen über ein beliebiges System (z. B. den eigenen Laptop) zu verwalten.

Mit dem Public-Template-Repository stellt Panamax Nutzerinnen und Nutzern via GitHub zudem eine öffentliche Template-Bibliothek mit diversen Ressourcen zur Verfügung.

Drone

Drone ist eine schlanke Continuous-Integration-Plattform mit minimalen Anforderungen. Mit dem Docker-Tool können Sie automatisch aus einer Git-Repository wie GitHub das neuste Build laden und zu Testzwecken in isolierten Docker-Container laufen lassen. Sie haben die Möglichkeit, jede beliebige Test-Suite auszuführen und sich Reports und Statusmeldungen via E-Mail zuschicken zu lassen. Für jeden Software-Test wird ein neuer Container auf Basis eines Images aus der öffentlichen Docker-Registry erstellt. Somit kann jedes öffentlich zugängliche Docker-Image als Umgebung für den zu testenden Code zum Einsatz kommen.

Drone ist in Docker integriert und unterstützt diverse Programmiersprachen wie PHP, Node.js, Ruby, Go oder Python. Die Container-Plattform wird als einzige Abhängigkeit vorausgesetzt. Ihre persönliche Continuous-Integration-Plattform erstellen Sie mit Drone somit auf jedem beliebigen System, auf dem sich Docker installieren lässt. Drone unterstützt diverse Version-Control-Repositorys. Eine Anleitung zur Standardinstallation mit GitHub-Integration findet sich in der Dokumentation des Open-Source-Projekts unter readme.drone.io.

Die Steuerung der Continuous-Integration-Plattform erfolgt über ein Web-Interface. Über dieses laden Sie Software-Builds aus einem beliebigen Git-Repository, fügen sie zu Anwendungen zusammen und lassen das Ergebnis in einer zuvor definierten Testumgebung laufen. Dazu wird für jeden Software-Test eine .drone.yml-Datei definiert, in der Sie festlegen, wie die Anwendung erstellt und ausgeführt werden soll.

Es steht Anwenderinnen und Anwendern mit Drone eine quelloffene CI-Lösung zur Verfügung, die die Stärken alternativer Produkte wie Travis und Jenkins in einer benutzerfreundlichen Anwendung vereint.

OpenStack

Wenn es um den Aufbau und Betrieb Open-Source-basierter Cloud-Strukturen geht, ist das quelloffene Cloud-Betriebssystem OpenStack die Software-Lösung der Wahl. Mit OpenStack lassen sich Rechen-, Speicher- und Netzwerk-Ressourcen in einem Rechenzentrum über ein zentrales Dashboard managen und Endnutzenden über ein Web-Interface zur Verfügung stellen.

Das Cloud-Betriebssystem basiert auf einer modularen Architektur, die sich aus mehreren Komponenten zusammensetzt:

• Zun (Container-Service): Zun ist der Container-Service von OpenStack, der die einfache Bereitstellung und Verwaltung containerisierter Anwendungen in der OpenStack-Cloud ermöglicht. Ziel von Zun ist es, Nutzenden die Verwaltung von Containern über eine REST-API zu ermöglichen, ohne dass sie Server oder Cluster verwalten müssen. Zun benötigt drei weitere OpenStack-Services, um zu laufen: Keystone, Neutron und kuryr-libnetwork. Optional kann die Funktionalität von Zun durch weitere OpenStack-Services wie Cinder und Glance erweitert werden.
• Neutron (Netzwerkkomponente): Neutron (ehemals Quantum) ist eine portierbare, skalierbare und API-gestützte Systemkomponente, die der Netzwerksteuerung dient. Das Modul stellt eine Schnittstelle für komplexe Netzwerk-Topologien zur Verfügung und unterstützt diverse Plugins, über die sich erweiterte Netzwerkfunktionen einbinden lassen.
• kuryr-libnetwork (Docker-Treiber): kuryr-libnetwork ist ein Treiber für Docker, der als Schnittstelle zwischen Docker und Neutron fungiert.
• Keystone (Identity-Service): Mit Keystone steht OpenStack-Nutzenden ein zentraler Identity-Service zur Verfügung. Das Modul fungiert als Authentifizierungs- und Rechtesystem zwischen den einzelnen OpenStack-Komponenten. Zugriffe auf Projekte in der Cloud werden über sogenannte Tenants (Mandanten) geregelt. Jeder Mandant stellt eine Nutzereinheit dar. Pro Nutzereinheit lassen sich mehrere Benutzerzugänge mit unterschiedlichen Rechten definieren.
• Cinder (Block-Speicher): Cinder ist der Spitzname einer Komponente der OpenStack-Architektur, die persistenten Block-Speicher für den Betrieb von VMs bereithält. Das Modul stellt virtuellen Speicher über eine Self-Service-API zur Verfügung. Über diese können Endnutzende Speicherressourcen in Anspruch nehmen, ohne dass für sie ersichtlich wird, auf welchem Gerät der Speicher bereitgestellt 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 Informationen zu OpenStack-Komponenten bzw. -Services finden Sie in unserem weiterführenden Artikel zu OpenStack. Über diese Komponenten hinaus lässt sich die OpenStack-Architektur um diverse optionale Module erweitern. Näheres dazu finden Sie auf der OpenStack-Webseite.

D2iQ DC/OS

DC/OS (Distributed Cloud Operating System) ist eine von D2iQ Inc. (früher Mesosphere) entwickelte Open-Source-Software für den Betrieb verteilter Systeme. Das Projekt baut auf dem quelloffenen Cluster-Manager Apache Mesos auf und versteht sich als Betriebssystem für Rechenzentren. Der Quellcode steht Anwendenden unter der Apache-Lizenz Version 2 auf GitHub zur Verfügung. Zudem vermarkten die Entwickelnden eine Enterprise-Version der Software unter d2iq.com. Eine ausführliche Projekt-Dokumentation findet sich unter dcos.io. Betrachten Sie DC/OS als eine Art Mesos-Distribution, die Ihnen alle Funktionen des Cluster-Managers über eine zentrale Bedienoberfläche bereitstellt und Mesos um einiges erweitert.

DC/OS nutzt den verteilten System-Kernel der Mesos-Plattform. Dies ermöglicht es, die Ressourcen eines ganzen Rechenzentrums zu bündeln und in Form eines aggregierten Systems wie einen einzigen logischen Server zu verwalten. So steuern Sie ganze Cluster physischer oder virtueller Maschinen mit der gleichen Leichtigkeit, mit der Sie einen einzelnen Rechner bedienen.

Die Software vereinfacht die Installation und Verwaltung verteilter Anwendungen und automatisiert Aufgaben wie Ressourcenmanagement, Scheduling und Inter-Prozess-Kommunikation. Die Verwaltung eines Clusters auf Basis von D2iQ DC/OS sowie aller darauf ausgeführten Dienste erfolgt zentral über ein Kommandozeilenprogramm (CLI) oder ein Webinterface (GUI).

DC/OS abstrahiert die Ressourcen des Clusters und stellt gemeinsame Dienste wie Service-Discovery oder Paket-Management zur Verfügung. Die Kernkomponenten der Software laufen in einem geschützten Bereich – dem Kernel-Space. Zu diesem gehören Master- und Agent-Programme der Mesos-Plattform, die für Ressourcenzuordnung, Prozessisolation und Sicherheitsfunktionen 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 Ressourcen-Management zu steuern und Tasks (abstrakte Arbeitseinheiten) zu orchestrieren, die auf einem Agent-Knoten ausgeführt werden. Dazu verteilt der Mesos-Master Ressourcen an registrierte DC/OS-Dienste und nimmt Ressourcenberichte von Mesos-Agents entgegen.
• Mesos-Agents: Bei Mesos-Agents handelt es sich um Slave-Prozesse, die auf Agent-Konten laufen und für die Ausführung der vom Master verteilten Tasks zuständig sind. Mesos-Agents liefern dem Mesos-Master regelmäßige Berichte über die im Cluster zur Verfügung stehenden Ressourcen. Diese werden vom Mesos-Master an einen Scheduler (z. B. Marathon, Chronos oder Cassandra) weitergeleitet. Dieser entscheidet, welcher Task auf welchem Knoten ausgeführt wird. Die Tasks werden isoliert in einem Container ausgeführt.

Alle anderen Systemkomponenten sowie Anwendungen, die von Mesos-Agents via Executor ausgeführt werden, laufen im User-Space. Zu den Grundkomponenten einer Standard-DC/OS-Installation gehören der Admin-Router, das Mesos-DNS, ein Distributed DNS-Proxy, der Load-Balancer Minuteman, der Scheduler Marathon, Apache ZooKeeper sowie Exhibitor.

• Admin-Router: Der Admin-Router ist ein speziell konfigurierter Webserver auf NGINX-Basis, der DC/OS-Dienste sowie zentrale Authentifizierungs- und Proxy-Funktionen zur Verfügung stellt.
• Mesos-DNS: Die Systemkomponente Mesos-DNS bietet Service-Discovery-Funktionen, die es den einzelnen Services und Anwendungen im Cluster ermöglichen, sich gegenseitig über ein zentrales Domain-Name-System (DNS) zu identifizieren.
• Distributed DNS-Proxy: Beim Distributed DNS-Proxy handelt es sich um einen internen DNS-Dispatcher (Verteiler).
• Minuteman: Die Systemkomponente Minuteman fungiert als interner Load-Balancer, der auf der Transport-Ebene des OSI-Referenzmodells (Layer 4) arbeitet.
• DC/OS Marathon: Marathon ist eine zentrale Komponente der Mesos-Plattform, die in D2iQ DC/OS als init-System (ähnlich wie systemd) fungiert. Marathon startet und überwacht DC/OS-Dienste und Anwendungen in Cluster-Umgebungen. Darüber hinaus bietet die Software Hochverfügbarkeitsfunktionen, Service-Discovery, Load-Balancing, Health-Checks und eine grafische Weboberfläche.
• Apache ZooKeeper: Bei Apache ZooKeeper handelt es sich um eine quelloffene Software-Komponente, die Koordinationsfunktionen für den Betrieb und die Steuerung von Anwendungen in verteilten Systemen zur Verfügung stellt. Im Rahmen von D2iQ DC/OS kommt ZooKeeper bei der Koordination aller installierten System-Dienste zur Anwendung.
• Exhibitor: Exhibitor ist eine Systemkomponente, mit der sich ZooKeeper auf jedem Master-Knoten im Cluster automatisch installieren und konfigurieren lässt. Darüber hinaus hält Exhibitor eine grafische Benutzeroberfläche für ZooKeeper-Anwendende bereit.

Auf Cluster-Ressourcen, die via DC/OS aggregiert wurden, lassen sich diverse Workloads gleichzeitig ausführen. So ermöglicht das Cluster-Betriebssystem beispielsweise einen parallelen Betrieb von Big-Data-Systemen, Microservices oder Container-Plattformen wie Hadoop, Spark und Docker.

Mit D2iQ Universe steht für DC/OS ein öffentlicher App-Katalog zur Verfügung. Über diesen installieren Sie Anwendungen wie Spark, Cassandra, Chronos, Jenkins oder Kafka bequem mit einem Klick über die grafische Benutzeroberfläche.

Docker-Tools für Sicherheit

Auch wenn in Containern gekapselte Prozesse auf demselben Kernel laufen, nutzt Docker eine Reihe von Isolationstechniken, um diese voneinander abzuschirmen. Vor allem werden Kernfunktionen des Linux-Kernels wie Cgroups und Namespaces eingesetzt.

Dennoch bieten Container nicht denselben Isolationsgrad, der sich mithilfe virtueller Maschinen realisieren lässt. Trotz der beschriebenen Isolationstechniken lassen sich beispielsweise aus Containern heraus wichtige Kernel-Subsysteme wie Cgroups sowie Kernelschnittstellen in den Verzeichnissen /sys und /proc erreichen. Auch das Docker-Entwicklungsteam hat die Sicherheitsbedenken als Bremse für die Etablierung der Container-Technologie auf Produktivsystemen erkannt. Neben den grundlegenden Isolationstechniken des Linux-Kernels unterstützen neuere Versionen der Docker-Engine daher die Frameworks AppArmor, SELinux und Seccomp, die als eine Art Firewall für Kernel-Ressourcen fungieren.

• AppArmor: Mit AppArmor lassen sich Zugriffsrechte von Containern auf das Dateisystem reglementieren.
• SELinux: SELinux bietet ein komplexes Regelsystem, mit dem Zugriffskontrollen auf Kernel-Ressourcen implementiert werden können.
• Seccomp: Mit Seccomp (Secure Computing Mode) wird der Aufruf von Systemcalls überwacht.

Über diese Docker-Tools hinaus nutzt Docker sogenannte Linux-Capabilities, über die sich die Root-Rechte einschränken lassen, mit denen die Docker-Engine Container startet.

Weitere Sicherheitsbedenken bestehen zudem in Bezug auf Software-Schwachstellen innerhalb von Anwendungskomponenten, die über die Docker-Registry verbreitet werden. Da prinzipiell jeder Docker-Images erstellen und für die Community öffentlich zugänglich im Docker-Hub ablegen kann, besteht die Gefahr, schädlichen Code im Rahmen eines Image-Downloads ins eigene System einzuführen. Docker-Nutzende sollten daher vor dem Deployment einer Anwendung sicherstellen, dass der gesamte Code, der in einem Image zur Ausführung von Containern bereitgestellt wird, aus einer vertrauenswürdigen Quelle stammt. Docker bietet dafür im Rahmen der Enterprise-Edition (EE) der Container-Plattform seit Anfang 2017 ein Zertifizierungsprogramm an, über das Infrastruktur-, Container- und Plug-in-Anbieter Ihre Software prüfen und auszeichnen lassen können. Um ein Zertifikat zu erhalten, müssen folgende Voraussetzungen erfüllt sein:

• Infrastruktur-Zertifizierung: Software-Entwickelnden, die zertifizierte Infrastruktur-Komponenten für das Docker-Ökosystem bereitstellen möchten, müssen mithilfe entsprechender Tests nachweisen, dass ihr Produkt für eine Zusammenarbeit mit der Docker-Plattform optimiert wurde.
• Container-Zertifizierung: Ein Container wird nur dann mit dem offiziellen Docker-Zertifikat ausgezeichnet, wenn dieser gemäß Best Practices erstellt wurde und sämtliche Software-Tests, Schwachstellen-Checks und Sicherheitsüberprüfungen bestanden hat.
• Plug-ins: Ein Plug-in für Docker EE darf sich mit dem Docker-Zertifikat schmücken, wenn es gemäß Best Practices entwickelt wurde und sämtliche API-Compliance-Tests und Schwachstellen-Checks bestanden hat.

Neben einem Zugewinn an Sicherheit für Anwendende sollen Docker-Zertifikate Software-Entwickelnden eine Möglichkeit bieten, sich mit ihren Projekten von der Vielzahl der zur Verfügung stehenden Ressourcen abzuheben.