© istockphoto.com/Alex_Doubovitsky
Teil 1: Erstellung der Containerarchitektur

Alles nur Containersache


Hätte mir jemand vor zwei Jahren erzählt, dass er alle Services seiner Webseite auf verschiedene virtualisierte Images verteilen möchte, dann hätte ich ihn vermutlich für verrückt erklärt. Man würde praktisch mittels Virtualisierungslösungen wie VirtualBox, QEMU, VMware oder Zen Images bauen, die nur dem Zweck dienen, einen spezifischen Service für eine Webseite anzubieten – inklusive eines vollumfänglichen Betriebssystems und den dafür zu reservierenden Ressourcen wie Hauptspeicher und Festplattenplatz. Vor zwei Jahren sicherlich undenkbar, heute dank Technologien wie Docker und LXC durchaus machbar. In dieser Artikelserie wird beschrieben, wie eine komplette Webseite inklusive RESTful-API und Datenbank mittels verschiedener Docker-Container realisiert wird.

Ganz oben rechts im Buzzword-Quadranten finden wir neben Docker [1] auch immer wieder den Begriff „Microservices“. Das Konzept hinter diesen Services ist, sie so weit zu kapseln, dass sie nur einem bestimmten Einsatzzweck dienen und demnach autark operieren können. Das erhöht die Flexibilität, indem jeder Service ohne großen Aufwand durch einen anderen ersetzt und die für das bestimmte Szenario am besten geeignete Technologie genutzt werden kann. Da jeder Container dafür verantwortlich ist, einen bestimmten Zweck zu erfüllen, kann man genau dieses Konzept mit einer Containervirtualisierung auf einem höheren Level umsetzen (Loose Coupling).

Ganz genau lässt sich der Ansatz natürlich nicht übertragen, denn eine Grundvoraussetzung für einen Microservice ist, dass er über standardisierte Schnittstellen kommuniziert (z. B. über HTTP). Demnach steht ein Container, der mit einer Datenbank kommunizieren muss, in gewisser Abhängigkeit zum Datenbankcontainer, da der Datenbanktreiber der Applikation schließlich wissen muss, wie er mit einer Datenbank (z. B. MongoDB oder Oracle-SQL-Server) sprechen kann – es sei denn, sie ist über ein REST-API und ohne Treiber ansprechbar. Allerdings ist es dem Container egal, ob unter der Datenbank ein Ubuntu-, ein CentOS- oder ein Debian-Betriebssystem läuft, denn je nach Einsatzzweck hat jedes OS seine Vor- und Nachteile. Für Cloud-Dienste spielt diese Möglichkeit eine zentrale Rolle, um einzelne Applikationen als SaaS (Software as a Service) anzubieten. Für Administratoren bietet diese Architektur, neben dem zentralen Management der Container, die Möglichkeit, alle Container auf eine andere Hardware umzuziehen und wieder zu starten, denn die Konfigurationen der Server und Applikationen sind Bestandteil der portierbaren Images, beziehungsweise Teil des Docker-Hosts.

Ein weiterer wichtiger Aspekt bei der Aufteilung von Services in Container ist die Sicherheit. Denn schafft es ein Angreifer, über eine Schwachstelle in der Implementierung oder einen der genutzten Services, in das System zu gelangen, ist er vorerst im kompromittierten Container gefangen, sodass alle weiteren Services davon nicht betroffen sind.

Virtualisierung mittels VMware und Co.

Gehen wir davon aus, dass wir für eine neue Webseite fünf verschiedene Bestandteile brauchen: einen nginx-Webserver [2] als Reverse Proxy für die Verteilung aller eingehenden Requests; einen weiteren nginx-Server, der die statischen Dateien für die Webseite ausspielt; einen io.js-JavaScript-Application-Server [3], der ein RESTful-API zur Verfügung stellt; und schließlich eine Datenbank, die es erlaubt, Daten zu persistieren und auch wieder (über das RESTful-API) zur Verfügung zu stellen.

Würde man diese Bestandteile mit einer Virtualisierungslösung wie VMware bauen und davon ausgehen, dass jedes Image aufgrund der Integration eines kompletten Betriebssystems mit einer Größe von 10 Gigabyte zu Buche schlägt, bräuchte man circa 50 Gigabyte (5 x 10 Gigabyte) an Festplattenplatz auf dem Webserver. Eine schlanke Lösung wäre hier von Vorteil.

Containerization mit Docker

Docker basiert komplett auf LXC (Linux-Container [4]) – einem Verfahren, das es auf Linux-Betriebssystemen schon lange gibt und das für die Isolation von Prozessen und Prozessgruppen auf Kernelebene zuständig ist. Die Verwendung von LXC ist relativ komplex, weshalb Docker sich das Ziel gesetzt hat, die Verwendung dieser Technologie zu vereinfachen, sodass eine verwaltbare Containerarchitektur erstellt werden kann. Die Abhängigkeit zu LXC bedeutet, dass alles, was Docker technisch kann, auch LXC zur Verfügung stellen muss. Durch die gegebene Isolationsmöglichkeit ist es demnach möglich, neben kompletten Linux-Distributionen auch einzelne Applikationen auf einem Host zu virtualisieren, und das, ohne komplette und vollumfängliche virtuelle Maschinen zu erstellen. Das bedeutet, dass die Größe der Images, die auf demselben Base-Image aufsetzen, nur noch davon abhängt, welchen Speicherplatz die darin zusätzlich installierten Dateien benötigen (Zwiebelprinzip, Abb. 1). Das Erstellen mehrerer Instanzen eines Images skaliert dadurch deutlich besser und sorgt dafür, dass man nicht ansatzweise an die vorher genannten 50 Gigabyte Festplattenplatz herankommt.

sambale_docker_1.tif_fmt1.jpgAbb. 1: Funktionsweise des Docker-Dateisystems – das Zwiebelprinzip (© Docker, Inc.)

Docker setzt aufgrund der Abhängigkeit zu LXC einen Kernel ab Version 3.10 voraus und läuft nativ nur auf 64-Bit-Linux-Betriebssystemen [5]. Wer Docker auf einem Windows- oder OS-X-Betriebssystem betreiben möchte, muss zu boot2docker [6] greifen. Das erlaubt es, eine leichtgewichtige VirtualBox mit einer Tiny-Core-Linux-Distribution [7] zu starten, die weniger als 30 Megabyte groß ist, in ungefähr fünf Sekunden startet und schon für die Verwendung als Docker-Host vorbereitet ist – so kommt man auch unter Nicht-Linux-Systemen in den Genuss, einen Docker-Host zu betreiben. Für einen Produktiveinsatz ist allerdings ein reines 64-Bit-Linux-System mit dem aktuellsten Kernel strengstens empfohlen.

Die Docker-Grundbegriffe

Wir wollen nicht zu tief in die Architektur und Funktionsweise von LXC und Docker abtauchen, aber um ein gewisses Grundverständnis für die nachfolgenden Schritte zu bekommen, ist es wichtig, dass ein paar grundlegende Begriffe geklärt sind:

Docker-Host: Der Docker-Host ist das System, auf dem der Docker-Daemon und der Doc...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang