„Das klappt schon wieder nicht auf der Produktionsplattform, was haben die da nur programmiert?“ So oder ähnlich lautet eine häufige Aussage des Operation-Teams, wenn ein neues Release eingespielt wird. Die Developer entwickeln in ihrer Umgebung eine Software bzw. ein Feature. Ob diese Software auch in der Produktivumgebung funktioniert, ist ungewiss. Leider sind Entwicklung und Produktion nicht immer so einfach austauschbar. Hier kann es mit dem neuen Hype-Thema Docker Abhilfe geben.

Wie funktioniert dieses Docker denn?

Hier wird nicht mit virtuellen Maschinen gearbeitet, sondern es werden Prozesse isoliert ausgeführt. Diese Isolationen nennt man Container. In diesem Container startet kein Hypervisor ein Gast-Betriebssystem, welches dann die Prozesse ausführt, wie es in der Virtualisierung normalerweise der Fall wäre.

Bei Docker wird ein Root-Filesystem isoliert auf dem Host gebootet. Diesem sogenannten Container liegen Images zu Grunde, die portabel sind. In einem solchen Image liegt dann z. B. ein produktiv konfigurierter Tomcat-Server bereit, der nur darauf wartet, gestartet zu werden. Der Entwickler bekommt also statt einer virtuellen Maschine einen sogenannten Container, der die gleiche Konfiguration wie die Produktion besitzt. Er kann seinen Code nun testen und ist sich sicher, dass seine Entwicklung in der Produktiv-Konfiguration inklusive aller Bibliotheken auch funktioniert. Dank dieses Ansatzes braucht der Entwickler sich keine Gedanken zu machen, wie er sein System umkonfigurieren muss. Soll die Umgebung entfernt werden, wird einfach der Container gelöscht.

Ob das alles wirklich so einfach geht, nehmen wir im nächsten Abschnitt einmal genauer unter die Lupe:

Entwickler und ihre Bibliotheken – Docker kommt zu Hilfe!

Wer schon einmal versucht hat, Python 2.7 und 3.x auf dem gleichen System auszuführen, weiß, dass es quasi unmöglich ist. Die Webentwickler kennen die Problematik mit verschiedenen Versionen von node.js. Hier werden oft Workarounds wie z. B. nvm genutzt. Doch eleganter wird es mit Docker. Durch das Nutzen verschiedener Python-Images können auf einem Server mehrere isolierte Python-Umgebungen gestartet werden. Dabei entfällt, wie bereits geschrieben, der Ballast von virtuellen Maschinen. Nachdem der Docker auf dem Server installiert ist, reicht ein Bezug der beiden Basis-Images per

Nun können damit Container, also isolierte Laufzeitumgebungen, erzeugt werden. Das ist „eigentlich“ nur das Starten der beiden Python-Prozesse auf dem Host – aber eben in isolierten Bereichen. Ein Instanzieren eines Containers geht ganz bequem mit

oder

Nach jedem dieser Aufrufe bekommen Sie eine interaktive Bash, in der Sie die jeweilige Python-Version mit

abfragen können. Das Verlassen des Containers ist mit dem Befehl exit möglich. Damit wird der Container dann aber auch gleich gestoppt. Das Gute ist nun, dass Sie beide Versionen parallel ausführen können. Ein weiterer Vorteil ist auch, dass Sie dabei keinerlei Dateien wie Bibliotheken etc. auf Ihrem Server installiert haben. Es wurden einfach Container gestartet, die ihr notwendiges Filesystem aus einem Image bekommen haben. Wenn Sie nun diese Basis-Images nach Ihren Vorstellungen anpassen, kann ein Entwickler mit der gleichen Python-Umgebung testen, wie sie auch Ihr Produktiv-Server hat.

Das eigene Image und Sicherheit

Um diesen Trick zu leisten, gibt es die sogenannten Dockerfiles. Dateien, die das Bauen eines eigenen Images mit Anpassungen unterstützen. Damit lassen sich Systeme bauen, die nicht nur Ihren speziellen Wünschen zur Konfiguration genügen, sondern auch der Sicherheit. Was in einem Container nicht installiert ist, kann auch nicht gehackt werden. Bei einer vollständigen Installation eines Debian kann per Metasploit getestet werden, welche Einfallstore die PHP-Bibliothek zum Bashzugriff bietet.

Was aber, wenn einfach kein Bash im Container vorhanden ist, da ja nur ein Webserver laufen muss?

Ein Container kann überall laufen

Softwarecontainern ist es egal, auf welchem Docker-Host sie laufen. Das heißt konkret, ein Docker-Host läuft unter RedHat – obwohl die Container mit Debian gebaut wurden. Docker und der Container benötigen allerdings eine Gemeinsamkeit – der Kernel muss passen! Also nicht ein 2.2 Kernel auf dem Host und ein 4.4 in den Images. Diesem Umstand wird allerdings schon durch die Installationsvoraussetzungen der Docker-Software auf dem Host Rechnung getragen. Aber es gehört halt in die „Gewusst wie“-Schublade. Docker führt in einem Container ein Root-Filesystem aus, daher klappt der Trick mit den verschiedenen Unixen. Allerdings – wer führt das Root-Filesystem aus? Der Kernel! Auch interessant, wie Container plötzlich auf andere Docker-Hosts geschoben werden können. Solche Ideen kommen natürlich nur, wenn eigene Experimente in einer geeigneten Umgebung gegeben sind.