Das Docker-Ökosystem: Die beliebtesten Docker-Tools im Überblick
Binnen weniger Jahre hat sich der Name „Docker“ zum Quasi-Synonym für die Container-Technologie im Software-Bereich entwickelt. Dem Unternehmen ist es gelungen, grundlegende Linux-Kernel-Funktionen zur Virtualisierung auf Betriebssystemebene wiederzubeleben und mithilfe eines selbstentwickelten Standards plattformübergreifend als Alternative zur hypervisorgestützten Hardware-Virtualisierung zu etablieren.
Wir stellen Ihnen die wichtigsten Erweiterungen für die Container-Plattform vor und bieten einen Überblick über die beliebtesten Drittanbieter-Projekte, in denen Docker-Tools auf Open-Source-Basis entwickelt werden.
Docker-Erweiterungen und Onlinedienste
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 Entwicklerteam der Kern-Software diverse Erweiterungen und Onlinedienste an die Seite gestellt. Diese bieten Anwendern neben Cluster- und Orchestrierungsfunktionen einen zentralen App-Marktplatz sowie ein Tool zur Verwaltung von Cloud-Ressourcen.
Docker-Engine
Wenn Anwender 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.
Eine detaillierte Beschreibung der Docker-Engine finden Sie in unserem Docker-Tutorial für Einsteiger.
Docker-Hub
Mit dem Docker-Hub stellt das Open-Source-Projekt Anwendern eine cloudbasierte Registry zur Verfügung, über die sich Docker-Images herunterladen, zentral verwalten und mit anderen Docker-Nutzern teilen lassen. Registrierte Nutzer haben die Möglichkeit, Docker-Images öffentlich oder in privaten Repositorys abzulegen. Der Download eines öffentlichen Images – in der Docker-Terminologie pull genannt – erfordert keinen Nutzer-Account. Ein integrierter Tag-Mechanismus ermöglicht die Versionierung von Images.
Neben öffentlichen Repositorys anderer Docker-Nutzer finden Sie im Hub zahlreiche Ressourcen, die in offiziellen Image-Archiven vom Docker-Entwicklerteam 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 Nutzern der Container-Plattform ermöglichen, private Repositorys nur bestimmten Personenkreisen zur Verfügung zu stellen. Zugangsberichtigungen werden innerhalb einer Organisation über Teams und Gruppenzugehörigkeiten verwaltet.
Docker-Machine
Die Docker-Machine ermöglicht es, Docker-Hosts auf nahezu jeder Infrastruktur bereitzustellen und zu verwalten. Das Tool automatisiert die Implementierung von Docker und vereinfacht die Bereitstellung von Docker-Hosts so maßgeblich.
Als „Docker-Host“ oder „Dockerized Host“ bezeichnet das Entwicklerteam einen virtuellen Host, auf dem die Docker-Engine läuft. Während sich diese schon immer nativ auf allen Linux-Distributionen ausführen ließ, erforderte der Einsatz von Docker auf macOS- oder Windows-Systemen früher eine abstrahierende Schicht in Form von Docker-Machine. Dies hat sich mit dem Release v1.12 grundlegend geändert. Heute steht Docker plattformübergreifend als auch für Mac und Windows zur Verfügung. Das zentrale Anwendungsfeld der Docker-Machine hat sich damit auf Remote-Szenarien und das Management von Docker-Hosts in Cloud-Umgebungen verlagert.
Soll eine große Anzahl von Docker-Knoten in einem Netzwerk oder auf Cloud-Infrastrukturen wie Amazon Web Services (AWS) oder DigitalOcean betrieben werden, kommen Anwender früher oder später auf die Docker-Machine zurück. Das Tool reduziert den Aufwand bei der Erstellung neuer Docker-Hosts auf einen simplen Kommandozeilenbefehl (docker-machine create) und ermöglicht die Steuerung mehrerer Docker-Knoten aus dem Terminal heraus. Die Docker-Machine übernimmt die Erstellung einer SSL-PKI sowie die Verteilung der für die Nutzerauthentifizierung benötigten Zertifikate. In Kombination mit Docker Swarm dient die Software der Bereitstellung von Docker-Clustern.
Die Docker-Machine kommt in der Regel auf dem lokalen System zum Einsatz. Das Docker-Tool erstellt automatisch neue Hosts, installiert die Docker-Engine und konfiguriert das lokal installierte Kommandozeilenprogramm für den Fernzugriff. Dies ermöglicht Ihnen, Hosts in der Cloud über das Terminal des lokalen Systems anzusprechen, um auf diesen Docker-Befehle per Remote auszuführen.
Docker Swarm
Ab Version 1.12 beinhaltet die Docker-Engine native Funktionen, die Anwendern 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. Älteren Versionen der Container-Plattform steht das Docker-Tool Swarm als Standalone-Anwendung zur Verfügung.
Bei einem Cluster handelt es sich um einen Verbund beliebig vieler Docker-Hosts, die auf der Infrastruktur eines externen IaaS-Providers oder im eigenen Rechenzentrum gehostet werden.
Das native Clustering-Werkzeug 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. Anwender 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 Anwender 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. Ein Anwender, der einen Service erstellt, spezifiziert in diesem, welche Images verwendet werden sollen und welche Befehle zur Anwendung kommen. Zudem bieten Services die Möglichkeit, Anwendungen zu skalieren. Nutzer 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 Anwender in der Regel auf die Docker-Machine zurück.
Docker Compose
Compose ist Dockers Lösung für Multi-Container-Applikationen. Ursprünglich als fig vom Software-Unternehmen Orchard entwickelt, erweitert das schlanke Orchestrierungswerkzeug heute das Docker-Portfolio.
Docker Compose ermöglicht Ihnen, mehrere Container zu verknüpfen und mit einem einzigen Befehl auszuführen. Das quelloffene Tool ist in der Skriptsprache Python implementiert. 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 zu 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-Cloud (ehemals Tutum)
Ende 2015 hat Docker den Container-Deployment- und Verwaltungsdienst Tutum übernommen und zur Docker-Cloud umgebaut. Während das Docker-Hub als zentrale Speicherplattform für Images dient, stellt Ihnen die Docker-Cloud eine webbasierte Plattform zur Verfügung, mit der Sie Docker-Container in diversen Infrastrukturen erstellen, testen, überwachen und verteilen können.
Die Docker-Cloud bietet eine native Integration mit allen Docker-Diensten und zeichnet sich durch eine Unterstützung diverser Cloud-Anbieter wie Microsoft Azure, Amazon Web Services, DigitalOcean, IBM Softlayer, Packet.net oder Google Container Engine aus. Darüber hinaus haben Anwender die Möglichkeit, die Docker-Cloud mit der eigenen Infrastruktur zu verknüpfen.
Zu beachten ist: Die Docker-Cloud stellt keine Hosting-Dienste zur Verfügung. Alle Ressourcen für Knoten, Services und Stacks, die Sie über die Deployment-Plattform erstellen, müssen durch externe Anbieter oder das eigene Rechenzentrum bereitgestellt werden.
Bei einem Stack handelt es sich um einen Verbund mehrerer Docker-Services, die zusammen eine Anwendung ergeben.
Die native Anbindung an etablierte Infrastructure-as-a-Service-Provider (IaaS) bietet Ihnen die Möglichkeit, Anwendungen über verschiedene Hosting-Plattformen zu verteilen oder in Kombination mit lokalen Knoten Hybrid-Architekturen zu realisieren. Die Verwaltung von Docker-Knoten über verschiedene Infrastrukturen hinweg erfolgt zentral über eine grafische Benutzeroberfläche, das Docker-Cloud-Dashboard. Über dieses verbinden Sie sich per Klick mit Ihrem Rechenzentrum oder einem externen Hosting-Anbieter und erstellen nach Bedarf einzelne Docker-Knoten (Nodes) oder ganze Node-Cluster.
Node-Cluster über verschiedene externe Anbieter hinweg lassen sich in der Docker-Cloud nicht realisieren.
Neben der plattformübergreifenden Bereitstellung und Skalierung von Anwendungen in der Cloud bietet die Deployment-Plattform Schnittstellen zu diversen Registrys wie dem Docker-Hub sowie automatisierte Build- und Test-Funktionen. Einen Überblick über die Kernfunktionalitäten und Anwendungsmöglichkeiten der Docker-Cloud bietet folgendes Video des Entwicklerteams:
Die Docker-Toolbox
Seit dem Release v1.12 steht Docker für neuere macOS- und Windows-Rechner auch als native Desktop-Anwendung zur Verfügung. Nutzer älterer Systeme hingegen müssen auf die Docker-Toolbox zurückgreifen, um die Container-Plattform installieren zu können.
Bei der Docker-Toolbox handelt es sich um einen Installer, der die Einrichtung einer Docker-Umgebenen auf älteren Windows und macOS-System automatisiert. Die Software beinhaltet folgende Komponenten:
- Docker-Engine
- Docker-Machine
- Docker Compose
- Oracle VirtualBox
- die Docker-GUI Kitematic sowie
- eine für Docker konfigurierte Kommandozeilenoberfläche
Kern der Docker-Toolbox ist die Open-Source-Software Kitematic. Diese integriert sich in die Docker-Machine, um für die Installation der Container-Plattform auf Windows und Mac eine virtuelle Maschine auf Basis der Oracle VirtualBox bereitzustellen. Für die Arbeit mit Docker steht Nutzern eine grafische Benutzeroberfläche zur Verfügung, über die sich Container per Mausklick erstellen, starten und stoppen lassen. Eine Schnittstelle zum Docker-Hub ermöglicht es zudem, die Registry direkt aus der Desktop-App heraus zu durchsuchen und Images herunterzuladen.
Neben der GUI steht eine vorkonfigurierte Kommandozeilenoberfläche zur Verfügung. Sämtliche Änderungen, die Anwender über den einen Eingabeweg vornehmen, werden auch für den anderen Modus übernommen. Nutzer haben somit die Möglichkeit, nahtlos zwischen GUI und CLI zu wechseln, um Container auszuführen und zu steuern. Des Weiteren bietet Kitematic Funktionen, mit denen sich Ports automatisch zuordnen, Umgebungsvariablen definieren und Laufwerke (Volumes) konfigurieren lassen.
Auch wenn die Docker-Toolbox in der Docker-Dokumentation als veraltet (legacy) markiert ist, wird die Software nach wie vor unterstützt. Das Entwicklerteam empfiehlt jedoch den Einsatz der nativen Desktop-Apps Docker for Windows oder Docker for Mac, sofern deren Systemvoraussetzungen erfüllt werden.
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 Mesosphere 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 neben Spotifys quelloffener Orchestrierungs-Plattform Helios das Open-Source-Projekt Kubernetes.
Bei Kubernetes handelt es sich um einen Cluster-Manager für containerbasierte Anwendungen, der zum Großteil von Google entwickelt wurde und heute unter der Schirmherrschaft der Cloud Native Computing Foundation (CNCF) steht.
Bei der Cloud Native Computing Foundation (CNCF) handelt es sich um eine Suborganisation der Linux Foundation (LF). Ausschlaggebend für die Gründung der Organisation im Jahr 2015 war eine Kooperation der Linux Foundation mit dem Software-Unternehmen Google, bei der das Google-Projekt Kubernetes als Spende an die CNCF überging. Ziel der Organisation ist es, die Container-Technologie in Open-Source-Projekten voranzutreiben. Weitere Mitglieder neben Google sind Docker, Twitter, Huawei, Intel, Cisco, IBM, Univa und VMware.
Kubernetes 1.0 ist seit Mitte 2015 für den Einsatz in Produktivsystemen freigegeben und kommt beispielsweise im Rahmen der Google-Container-Engine (GKE) zum Einsatz.
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. Anwender 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 jedes Knotens steht kubelet mit dem Kubernetes-Master in Verbindung und sorgt dafür, dass Informationen zur Kontrollebene weitergeleitet und von dieser empfangen werden. Der Agent nimmt Befehle und Aufträge vom Kubernetes-Master entgegen und überwacht die Ausführung auf dem jeweiligen Knoten.
- kube-proxy: Neben der Container-Engine und dem Agent kubelet 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 Anwendern 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 Anwendern 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 und unterscheidet sich damit von der Desktop-App Kitematic.
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 Anwendern 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
Die Entwickler des quelloffenen Software-Projekts Panamax haben sich das Ziel gesetzt, die Bereitstellung von Multi-Container-Apps zu vereinfachen. Das kostenlose Tool bietet Nutzern 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 Nutzern zur Verfügung stellen. Folgende Animation demonstriert das Panamax-Konzept unter dem Motto „Docker Management for Humans“:
Panamax wird von CenturyLink als Open-Source-Software unter Apache-2-Lizenz angeboten. 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. Das Entwicklerteam empfiehlt Anwendern, CoreOS via Vagrant und Oracle Vitualbox auf dem lokalen System zu installieren. Der klassische Software-Aufbau einer Panamax-Installation auf dem lokalen System setzt sich folgendermaßen zusammen: Die Basis stellt ein lokaler Rechner mit beliebigem Betriebssystem dar. Auf diesem installieren Anwender CoreOS mithilfe der Virtualisierungs-Software VirtualBox. Anschließend wird der Panamax-Client als Docker-Container in CoreOS ausgeführt. Die Software wurde als Docker-Client speziell für die schlanke Linux-Distribution entwickelt. Anwendern 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 Anwender ausführen.
- Panamax-UI: Die Panamax-UI fungiert als Benutzerschnittstelle auf dem lokalen System und ermöglicht es Anwendern, 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 haben Anwender 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 Anwendern 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 Anwendern via GitHub zudem eine öffentliche Template-Bibliothek mit diversen Ressourcen zur Verfügung.
Drone
Drone ist eine schlanke Continuous-Integration-Plattform mit minimalen Anforderungen. Nutzen Sie das in Go geschriebene Tool, um Builds (einzelne Entwicklungsstufen einer neuen Software) automatisch aus Git-Repositorys wie GitHub, GitLab oder Bitbucket zu laden und zu Testzwecken in isolierten Docker-Containern laufen zu 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.
Als „Continuous Integration“ (CI, „kontinuierliche Integration“) bezeichnet man einen Prozess in der Software-Entwicklung, bei dem neu entwickelte Software-Komponenten – sogenannte Builds (to build = „bauen“) – in regelmäßigen Abständen (in der Regel mindestens einmal am Tag) zusammengefügt und in Testumgebungen ausgeführt werden. Komplexe Anwendungen werden oft in großen Teams entwickelt. Continuous Integration ist eine Strategie, Integrationsfehler, die bei der Zusammenarbeit verschiedener Entwickler auftreten können, frühzeitig zu erkennen und zu beseitigen. Drone bietet Software-Entwicklern die Möglichkeit, verschiedene Testumgebungen mithilfe von Docker-Containern zu realisieren.
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.
In folgendem Video gibt Drone-Mitentwicker Brad Rydzewski einen Einblick in die quelloffene Continuous-Integration-Plattform:
OpenStack
Wenn es um den Aufbau und Betrieb Open-Source-basierter Cloud-Strukturen geht, ist OpenStack die Software-Lösung der Wahl. Das quelloffene Cloud-Betriebssystem ging im Jahr 2010 aus einer Kooperation des US-amerikanischen Webhosters Rackspace mit der Raumfahrtbehörde NASA hervor. Unterstützung findet das freie Software-Projekt unter Apache-Lizenz u. a. durch Firmen wie AT&T, SUSE, Canonical, HP, Intel Red Hat und IBM.
Mit OpenStack lassen sich Rechen-, Speicher- und Netzwerk-Ressourcen in einem Rechenzentrum über ein zentrales Dashboard managen und Endnutzern über ein Web-Interface zur Verfügung stellen.
Das Cloud-Betriebssystem basiert auf einer modularen Architektur, die sich aus sechs Kernkomponenten zusammensetzt:
- Nova (zentrale Rechenkomponente): Die zentrale Rechenkomponente (Compute) von OpenStack hört auf den Spitznamen „Nova“ und stellt quasi das Gehirn der Software-Architektur dar. Nova ist für die Steuerung aller Recheninstanzen des Systems zuständig und ermöglicht es Anwendern, virtuelle Maschinen (VMs) auf Basis von Images zu starten, in Cloud-Umgebungen bereitzustellen und in Clustern zu verwalten. VMs lassen sich dabei über beliebig viele Knoten verteilen. Als Cloud-Computing-Fabric-Controller (Steuereinheit für Computernetzwerke) ist Nova die Grundkomponente für IaaS-Dienste auf Basis von OpenStack. Nova unterstützt diverse Hypervisor- und Virtualisierungstechnologien sowie Bare-Metal-Architekturen, bei denen VMs direkt auf der Hardware aufsetzen. In der Regel kommen KVM, VMware, Xen, Hyper-V oder die Linux-Container-Technology LXC zum Einsatz.
- 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 Plug-ins, über die sich erweiterte Netzwerkfunktionen einbinden lassen.
- Cinder (Block-Speicher): Cinder ist der Spitzname einer Komponente der OpenStack-Architektur, die persistenten Block-Speicher für den Betrieb virtueller Maschinen bereithält. Das Modul stellt virtuellen Speicher über eine Self-Service-API zur Verfügung. Über diese können Endnutzer Speicherressourcen in Anspruch nehmen, ohne dass für sie ersichtlich wird, auf welchem Gerät der Speicher bereitgestellt wird.
- Keystone (Identity-Service): Mit Keystone steht OpenStack-Nutzern 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.
- Glance (Image-Service): Mit dem Modul Glance steht OpenStack ein Dienst zur Verfügung, über den sich Images virtueller Maschinen speichern und abrufen lassen. Die Rechenkomponente Nova nutzt die von Glance bereitgestellten Images als Vorlage, um Instanzen virtueller Maschinen zu erzeugen.
- Swift (Objektspeicher): Das OpenStack-Modul Swift wird von der Rechenkomponente Nova genutzt, um unstrukturierte Datenobjekte zu speichern und über eine REST-API abzurufen. Swift zeichnet sich durch eine redundante, skalierbare Architektur und eine hohe Fehlertoleranz aus.
Seit dem Havanna-Release im Jahr 2013 bietet die Kernkomponente Nova einen Hypervisor-Treiber für die Docker-Engine. Dieser bettet einen HTTP-Client in die OpenStack-Architektur ein, mit dem sich die interne Docker-API über einen Unix-Socket ansprechen lässt.
Der Docker-Treiber für Nova ermöglicht es, Images aus dem Image-Service Glance abzurufen und diese direkt ins Docker-Dateisystem zu laden. Zudem lassen sich Images über den Docker-Standardbefehl (docker save) aus der Container-Plattform exportieren und in Glance ablegen. Eine Schritt-für-Schritt-Anleitung, wie Sie Docker in eine bestehende OpenStack-Architektur integrieren, wird im OpenStack-Wiki bereitgestellt.
Darüber hinaus bietet die OpenStack-Foundation einen 90-minütigen Workshop zur Docker-Integration via YouTube an:
Über die sechs Kernkomponenten hinaus lässt sich die OpenStack-Architektur um diverse optionale Module erweitern:
- Horizon (Dashboard): Das OpenStack-Dashboard trägt den Spitznamen „Horizon“ und bietet Anwendern eine webbasierte, grafische Benutzeroberfläche, über die sich andere Komponenten wie Nova oder Neutron steuern lassen.
- Heat (Orchestrierung): Das optionale Modul Heat stellt einen Service bereit, über den sich aus mehreren Komponenten bestehende Cloud-Anwendungen via Templates orchestrieren lassen. Heat bietet dafür eine native REST-API und das Template-Format HOT. Alternativ wird das Template-Format AWS-Cloud-Formation sowie eine entsprechende Query-API unterstützt.
- Ceilometer (Telemetrie-Service): Mit Ceilometer seht für OpenStack ein zentraler Telemetrie-Service zur Verfügung, mit dem sich Daten für statistische Erhebungen im Rahmen der Abrechnung oder des Benchmarkings zusammentragen lassen.
- Trove (Database-as-a-Service): Bei Trove handelt es sich um eine Database-as-a-Service-Komponente, mit der sich relationale und nicht-relationale Datenbanken bereitstellen lassen.
- Zagar (Messaging): Das optionale Modul Zaqar (ehemals Marconi) erweitert OpenStack um einen Multi-Mandanten-Cloud-Messaging-Service für Webentwickler. Die Software bietet eine REST-API, über die Entwickler Nachrichten zwischen verschiedenen Komponenten einer SaaS- oder Mobile-App versenden können.
- Designate (DNS-Service): Designate bietet DNS-as-a-Service für OpenStack. Das Management von Domain-Records erfolgt über eine REST-API. Das Modul ist multi-mandantenfähig und nutzt Authentifizierungsfunktionen über eine Keystone-Integration.
- Barbican (Schlüsselmanagement): Das Modul Barbican stellt OpenStack eine REST-API zur Verfügung, über die sich Passwörter, Schlüssel und Zertifikate sicher speichern, verwalten und bereitstellen lassen.
- Sahara (Elastic Map Reduce): Die optionale Komponente Sahara ermöglicht es Anwendern, Hadoop-Cluster auf Basis von OpenStack zu erstellen und zu verwalten.
- Ironic (Bare-Metal-Treiber): Das Zusatzmodul Ironic ist ein Fork des baremetal-Treibers der Rechenkomponente Nova und bietet Nutzern von OpenStack die Möglichkeit, Bare-Metal-Machines statt virtuellen Maschinen bereitzustellen.
- Murano (Applikationskatalog): Murano bietet Entwicklern und Cloud-Administratoren die Möglichkeit, Anwendungen in einem durchsuchbaren, nach Kategorien sortierten Katalog bereitzustellen.
- Manila (Shared-File-System): Manila ist ein Zusatzmodul für OpenStack, das die Architektur des Cloud-Betriebssystems um ein gemeinsames und verteiltes Dateisystemen erweitert.
- Magnum (Container-API-Service): Eine wichtige Zusatzkomponente ist der API-Service Magnum, der Container-Orchestrierungs-Tools wie Docker Swarm, Kubernetes oder Apache Mesos als OpenStack-Komponenten verfügbar macht.
Aufgrund der modularen Erweiterbarkeit hat sich OpenStack als eines der führenden Betriebssysteme für den Aufbau und Betrieb Open-Source-basierter Cloud-Strukturen etabliert. Für Docker-Nutzer stellt OpenStack durch den Docker-Treiber für Nova eine leistungsstarke Plattform dar, mit der sich Container professionell in komplexen, verteilten Systemen ausführen und verwalten lassen.
Mesosphere DC/OS
DC/OS (Data Center Operating System) ist eine von Mesosphere Inc. 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 Anwendern unter der Apache-Lizenz Version 2 auf GitHub zur Verfügung. Zudem vermarkten die Entwickler eine Enterprise-Version der Software unter mesosphere.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 durch diverse Komponenten um eine umfangreiche Infrastruktur erweitert, die den Betrieb von Anwendungen auf verteilten Systemen, in der Cloud oder in On-Premises-Umgebungen deutlich erleichtert. Folgendes Video des Entwicklerteams beinhaltet eine kurze Demonstration der DC/OS-Grundfunktionen:
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 Mesosphere 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. Um einen Task auszuführen, startet der Mesos-Agent einen sogenannten Executor-Prozess, der isoliert in einem Container ausgeführt und verwaltet wird. Die Trennung der Prozesse erfolgt wahlweise über die Mesos Universal Container Runtime oder die Docker-Container-Plattform.
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 Mesosphere 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 Mesosphere 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-Anwender 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 Mesosphere 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-Container als Bestandteil einer Digital Infrastructure Platform
Docker ist es gelungen, die IT-Branche von Grund auf umzukrempeln. Betrachtet man die Statistiken des Open-Source-Projekts, fällt es schwer zu glauben, dass der erste Release der Container-Plattform am 13. März 2013 erst vier Jahre zurückliegt.
Mehr als 8 Milliarden Container-Images haben Docker-Nutzer seitdem heruntergeladen, rund eine halbe Million unterschiedliche Docker-Apps stehen Anwendern in der Registry zur Verfügung. Das Projekt stützt sich auf eine Entwickler-Community von rund 3.000 Mitwirkenden. Und schon heute umfasst das Docker-Ökosystem eine schier unüberschaubare Anzahl an Tools, Erweiterungen und Software-Plattformen, die die Arbeit mit Docker-Containern noch effizienter gestalten. Nach eigenen Angaben ist die von Docker entwickelte Container-Technologie derzeit in mehr als 100.000 Drittanbieter-Projekte eingebunden. Doch worauf gründet sich der Erfolg der Docker-Plattform und ihrer Nebenprojekte?
In Zeiten, in denen es immer mehr Software-Anwender in die Cloud zieht, steigt der Wert einer Anwendung mit ihrem Vernetzungs- und Verbreitungsgrad. Dieser Trend spiegelt sich auch in der Art und Weise, wie Software heute entwickelt, getestet und ausgeführt wird. Für Unternehmen bieten Cloud-Infrastrukturen eine attraktive Möglichkeit, IT-Ressourcen zentral zu verwalten und für einen ortsunabhängigen Zugriff bereitzustellen. Konzepte wie Infrastructure-as-a-Service (IaaS) machen Unternehmensprozesse unabhängig von den Hardware-Ressourcen der eigenen Serverräume und bieten durch bedarfsbezogene Abrechnungsmodelle ein Maximum an Flexibilität und Skalierbarkeit.
Darüber hinaus bieten professionell betriebene Rechenzentren großer Hosting-Anbieter Strategien zur Ausfallsicherheit, Hochverfügbarkeit und Business-Kontinuität, die kleine und mittlere Unternehmen in den eigenen Räumlichkeiten so nur selten umsetzen können. Vor diesem Hintergrund trifft eine leichtgewichtige Virtualisierungstechnik, die es ermöglicht, Anwendungen mit minimalem Overhead in ein portables, plattformunabhängiges Format zu übertragen und mit einem einzigen Kommandozeilenbefehl in Cloud-Infrastrukturen und Hybrid-Umgebungen zu verteilen, den Nerv der Zeit.
Wie kaum eine andere Technologie bedient Docker den Trend zur „Digital Infrastructure Platform“, der Infrastruktur als cloudbasierter Dienstleistung. Das Docker-Ökosystem ermöglicht es, komplexe Anwendungen in sogenannte Microservices aufzubrechen, die sich via APIs verknüpft über verschiedene Knoten eines Cluster verteilen lassen. Unternehmen sichern sich so nicht nur ein Mehr an Agilität und Flexibilität, sondern auch an Stabilität. Multi-Container-Apps, deren Prozesse auf unterschiedlichen Hosts eines verteilten Systems laufen, lassen sich horizontal skalieren und durch Redundanzen ausfallsicher betreiben. Die weitgehende Unabhängigkeit in Containern gekapselter Microservices sorgt zudem dafür, dass sich Updates und Patches lediglich auf einzelne Teile einer Anwendung beiziehen und niemals die gesamte Applikation beeinträchtigen. Software-Fehler lassen sich so mit deutlich geringerem Aufwand beseitigen.
Auch beim Umstieg von traditionellen Infrastrukturen auf eine Digital Infrastructure Platform kann der Container-Technologie wesentliche Funktionen zukommen: Vor allem die Möglichkeit, Anwendungen inklusive aller Abhängigkeiten in portierbare Container zu verpacken und plattformübergreifend zu verteilen (Deployment), hilft Administratoren dabei, Altsysteme (z. B. Legacy-Applications) von der Static IT in die Dynamic IT zu überführen.
IT-Umgebungen lassen sich im Hinblick auf die steigende Beliebtheit cloudbasierter Infrastrukturen in zwei grundlegende Bereiche unterteilen: Die Static IT (statische IT) umfasst Enterprise- und Backend-Anwendungen, die auf klassischen Infrastrukturen in On-Premises-Umgebungen oder auf einer Private Cloud betrieben werden. Schaffen Unternehmen neue Anwendungen und Systeme an, werden diese jedoch immer öfter direkt auf Public-Cloud-Infrastrukturplattformen implementiert, um eine größtmögliche Skalierbarkeit, Flexibilität und Ortsunabhängigkeit zu gewährleisten. Für diesen Bereich hat sich die Bezeichnung Dynamic IT (dynamische IT) etabliert.
Darüber hinaus bietet der Einsatz einer Container-Plattform wie Docker die Chance, Anwendungen hinsichtlich der Punkte Geschwindigkeit, Performance und Change-Management zu optimieren. Bedenken bleiben jedoch in Bezug auf die Sicherheit der Container-Technologie.
Deployment
Die Installation der Container-Engine vorausgesetzt, lassen sich containerbasierte Anwendungen auf jedem beliebigen System ausführen. Container beinhalten neben dem Code der eigentlichen Anwendung auch sämtliche Binärdateien und Bibliotheken, die für die Laufzeit der Anwendung benötigt werden. Dies vereinfacht vor allem das Deployment, die Verteilung von Software auf verschiedenen Systemen – und das nicht nur für neu entwickelte Anwendungen. Die Container-Technologie lässt sich auch effektiv einsetzen, wenn es darum geht, Legacy-Applications – also veraltete Anwendungen, die für das Tagesgeschäft nach wie vor unverzichtbar sind – in die Cloud zu überführen.
Ältere Software-Komponenten lassen sich aufgrund von Abhängigkeiten zu bestimmten Betriebssystemen, Frameworks oder Klassen oft nur schwer in Cloud-Infrastrukturen integrieren. Hier kann eine schlanke Container-Engine wie Docker eine Abstraktionsschicht bieten, die Code-Abhängigkeiten kompensiert, ohne dass Administratoren den Overhead eines virtuellen Betriebssystems in Kauf nehmen müssen.
Geschwindigkeit und Performance
Vergleicht man die Container-Technologie, die der Docker-Plattform zugrunde liegt, mit einer klassischen Hardware-Virtualisierung via VM, zeigen sich deutliche Unterschiede in Bezug auf Geschwindigkeit und Performance.
Da in Containern gekapselte Anwendungen direkt auf den Kernel des Hostsystems zugreifen, muss bei dieser Art der Virtualisierung kein separates Gastsystem gestartet werden. Statt eines Hypervisors kommt bei Docker eine leichtgewichtige Container-Engine zum Einsatz. Es entfällt somit nicht nur die Zeit für den Boot-Prozess einer virtuellen Maschine, sondern auch der Ressourcenverbrauch für das zusätzliche Betriebssystem. Container-Apps lassen sich somit schneller und ressourcensparender bereitstellen als Anwendungen auf Basis virtueller Maschinen. Dies ermöglicht es der Administration, deutlich mehr Container auf einem Hostsystem zu starten, als Gastsysteme auf einer vergleichbaren Hardware-Plattform unterzubringen wären. Kann ein Server beispielsweise 10 bis 100 virtuelle Maschinen beherbergen, ließen sich alternativ bis zu 1.000 Container bereitstellen.
Hinzu kommt, dass Container, die neben dem Anwendungscode lediglich Binärdateien und Bibliotheken beinhalten, deutlicher weniger Speicherplatz benötigen als eine virtuelle Maschine inklusive Anwendung und Betriebssystem.
DevOps und Change-Management
Die Digitalisierung und der Trend zur mobilen Internetnutzung haben den Lebenszyklus von Anwendungen deutlich beschleunigt. Nicht nur Updates, Patches und Bugfixes müssen möglichst unmittelbar bereitgestellt werden. Auch Releases neuer Software-Versionen folgen in immer kürzeren Abständen aufeinander.
Das Deployment von Aktualisierungen jedoch stellt Entwickler und Administratoren vor Herausforderungen. Während Software-Hersteller ihren Kunden neue Funktionen einer Anwendung möglich schnell zur Verfügung stellen möchten, graut es Administrationen vor dem Ausfallrisiko, das jede Veränderung an der IT-Infrastruktur und den darauf aufsetzenden Software-Komponenten mit sich bringt. Lösungsstrategien für Schwierigkeiten dieser Art werden unter dem Schlagwort DevOps entwickelt. Den Anstoß dazu gaben die DevOpsDays im Jahr 2009, in denen Prozessverbesserungsansätze zur Zusammenarbeit von Entwicklung (Development) und IT-Betrieb (Operations) zum ersten Mal im Rahmen einer internationalen Konferenz erörtert wurden.
Ziel von DevOps ist es, die Qualität neuer Software-Versionen zu verbessern sowie Entwicklung, Auslieferung und Implementierung durch eine effektivere Zusammenarbeit aller Beteiligten und eine weitgehende Automatisierung zu beschleunigen. Zu automatisierbaren DevOps-Aufgaben zählen Build-Prozesse aus dem Repository, statische und dynamische Codeanalysen sowie Modul-, Integrations-, System- und Performance-Tests. Im Mittelpunkt des DevOps-Ansatzes stehen bis heute Überlegungen zu Continuous Integration (CI) und Continuous Delivery (CD) – zwei zentrale Anwendungsfelder der Docker-Plattform.
Bei Continuous Delivery („kontinuierliche Auslieferung“) handelt es sich um einen Ansatz, der Software-Auslieferungen mithilfe verschiedener Techniken, Prozesse und Werkzeuge per Kopfdruck optimieren soll. Im Mittelpunkt steht dabei eine Automatisierung der sogenannten Deployment-Pipeline.
Docker bietet Integrationsmöglichkeiten für etablierte CI/CD-Tools wie Jenkins, Travis oder Drone und ermöglicht es, Code automatisch aus dem Docker-Hub oder Versionskontroll-Repositorys wie GitHub, GitLab oder Bitbucket zu laden. Damit stellt die Container-Plattform eine Basis für DevOps-Workflows dar, bei denen Entwickler neue Anwendungskomponenten gemeinsam erstellen und in beliebigen Test-Umgebungen ausführen können.
Darüber hinaus unterstützt Docker On-Premises-, Cloud- und virtuelle Umgebungen sowie diverse Betriebssysteme und Distributionen. Zu den zentralen Vorteilen einer Docker-basierten CI/CD-Architektur gehört daher, dass Unternehmen nicht länger durch Inkonsistenzen verschiedener IT-Umgebungen ausgebremst werden.
Sicherheit
Auch wenn in Containern gekapselte Prozesse auf demselben Kernel laufen, nutzt Docker eine Reihe von Isolationstechniken, um diese voneinander abzuschirmen. Im Fokus stehen dabei Kernfunktionen des Linux-Kernels wie Cgroups und Namespaces. Jeder Container bekommt einen eigenen Hostnamen, eigene Prozess-IDs und eine eigene Netzwerkschnittstelle. Darüber hinaus sieht jeder Container nur den ihm zugeordneten Ausschnitt des Dateisystems. Die Aufteilung der Systemressourcen wie Speicher, CPU und Netzbandbreite erfolgt über einen Cgroup-Mechanismus. Dieser sorgt dafür, dass jeder Container lediglich das ihm zugeschriebene Kontingent in Anspruch nehmen kann.
Dennoch bieten Container nicht denselben Isolationsgrad, der sich mithilfe virtueller Maschinen realisieren lässt. Kapert ein Angreifer eine virtuelle Maschine, hat dieser kaum Möglichkeiten, mit dem Kernel des zugrundeliegenden Hostsystems zu interagieren. Container als gekapselte Instanzen eines gemeinsamen Host-Kernels hingegen bieten Angreifern deutlich mehr Freiheiten.
Trotz der beschriebenen Isolationstechniken lassen sich aus Containern heraus wichtige Kernel-Subsysteme wie Cgroups sowie Kernelschnittstellen in den Verzeichnissen /sys und /proc erreichen. Diese bieten Angreifern die Möglichkeit, Sicherheitsfunktionen des Hosts zu umgehen. Zudem laufen alle Container auf einem Host-System im selben User-Namespace. Dies hat zur Folge, dass ein Container, der Root-Rechte zugesprochen bekommt, diese auch bei der Interaktion mit dem Host-Kernel behält. Administratoren sollten daher darauf achten, dass Container ausschließlich mit eingeschränkten Rechten starten.
Über Root-Rechte verfügt zudem der Docker-Daemon, der für die Verwaltung der Container auf dem Host-System zuständig ist. Ein Nutzer, der Zugriff auf den Docker-Daemon hat, erhält automatisch Zugriff auf alle Verzeichnisse, auf die der Daemon zugreifen kann, sowie die Möglichkeit, über eine REST-API via HTTP zu kommunizieren. Die Docker-Dokumentation empfiehlt daher, nur vertrauenswürdigen Nutzern Zugriff auf den Daemon zu gewähren.
Auch das Docker-Entwicklungsteam hat die genannten 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.
Darüber 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-Nutzer 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-Entwickler, 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 Anwender sollen Docker-Zertifikate Software-Entwicklern eine Möglichkeit bieten, sich mit ihren Projekten von der Vielzahl der zur Verfügung stehenden Ressourcen abzuheben.
Fazit: Wie zukunftssicher ist Docker?
Die Container-Technologie ist auch in Deutschland kein Nischenthema mehr. Schon heute stellen marktführende Unternehmen wie Zalando, Otto oder Sixt Teile Ihrer IT auf Container-Systeme um. Die Technologie ist eine ressourcensparende Alternative zur klassischen Hardware-Virtualisierung und bietet sich damit vor allem für Unternehmen an, die interaktive Webanwendungen bereitstellen oder ein großes Datenaufkommen bewältigen müssen. Eine steigende Nachfrage wird in den kommenden Jahren vor allem im Bereich des E-Commerce erwartet. Bei Global Playern wie eBay und Amazon gehören Container bereits zur Standardtechnologie. Kleinere Onlinehändler werden nachziehen.
Derzeit hat sich das noch junge Software-Unternehmen Docker dank Open-Source-Konzept und Bemühungen zur Standardisierung binnen weniger Jahre einen Platz als technologischer Marktführer im Bereich Operating-System-Level-Virtualisierung errungen. Doch die Konkurrenz in der Container-Branche schläft nicht. Hier werden Anwender von der Innovationsgeschwindigkeit profitieren, die der verschärfte Wettbewerb unter den Anbietern von Container-Lösungen und Administrationstools mit sich bringt.
Bremsend haben sich in der Vergangenheit vor allem Sicherheitsbedenken auf die Verbreitung der Container-Technologie ausgewirkt. Die zentrale Herausforderung für Entwickler containerbasierter Virtualisierungstechniken ist eine Verbesserung der Prozessisolation im Linux-Kernel – ein Bereich, in dem in der Vergangenheit durch Projekte wie SELinux, AppArmor oder Seccomp bereits Fortschritte erzielt wurden.
Betrachtet man die hohe Annahmequote für Container, ist davon auszugehen, dass sich die Operation-System-Level-Virtualisierung auch langfristig als Alternative zu virtuellen Maschinen etablieren wird. Speziell das Docker-Projekt und sein rasant wachsendes Ökosystem bieten Unternehmen eine zukunftssichere Basis für den Betrieb von Software-Containern in der Entwicklung und im operativen Geschäft.