Die Container-Virtualisierung Docker erlebte in den letzten Monaten eine Art Hype, ob auf Vorträgen, Konferenzen, User-Groups oder natürlich auch Zeitschriften – irgendwann war der Zeitpunkt erreicht, an dem Docker genannt wurde. Grundsätzlich setze ich mich gerne mit neuen Technologien und zugegebenermaßen ebenfalls Hypes auseinander, insofern sind die Aktivitäten rund um Docker auch an mir nicht spurlos vorüber gegangen. Dieser Artikel soll keine Einführung in Docker oder dessen zugrunde liegenden Technologien sein, dafür gibt es im Netz inzwischen ausreichend viele Quellen. Vielmehr habe ich mir die Frage gestellt, ob Docker eine für mich sinnvolle und passende Technologie darstellt, um Dienste bzw. Anwendungen bereit zu stellen. Insofern könnte die Überschrift auch lauten – Docker – [ ] ja, [ ] nein, [ ] vielleicht?
Aber von Anfang an – zunächst wären da die Demos und Tutorials. Ich glaube, zum ersten Mal habe ich von Docker von einem Kollegen gehört, danach eine längere Zeit nichts, danach wieder bei einem Vortrag auf einer User-Group im Zusammenhang mit CoreOS. Dabei wurde CoreOS jedoch nur auf der lokalen Maschine gestartet, soweit ich mich erinnere mit Hilfe von Vagrant, was zu Demo-Zwecken zwar nett ist, aber an der Realität meilenweit vorbei geht. Meine Versuche, CoreOS als VMs zu betreiben, waren nach einigen Hürden zwar erfolgreich, aber von einer recht steilen Lernkurve begleitet. Soll heißen – um die Funktionalitäten von etcd, Fleet & Co. auszunutzen, bedarf es durchaus umfangreicher Vorbereitungen. Das wäre noch nicht weiter tragisch, jedoch verspricht CoreOS eine automatische Aktualisierung des Betriebssystems. Genau das hat jedoch in meiner Installation nicht wirklich stabil funktioniert, weshalb ich letztlich die VMs gelöscht habe. Davon abgesehen gibt es sicherlich sinnvolle Einsatzmöglichkeiten für das oft beschworene Beispiel, eine Vielzahl (100, 1000, …) Docker-Container auf einer Maschine starten zu können. Etwa zum Test der Clusterfähigkeit, Ausfallsicherheit oder ähnliches. Doch 100 Nginx-Container aus dem einzigen Zweck zu starten, weil es geht, ist zwar nett, aber aus meiner Perspektive nicht unbedingt notwendig.
Bleiben die Tutorials und Demos, in denen eine simple Web-Anwendung, oder vielmehr eine statische Seite aus einem Nginx- oder Apache-Container präsentiert wird. Ja, das geht, der Aufwand ist überschaubar, aber der Sinn und Zweck ebenso. Und mit Node.js oder ähnlichen wird es auch nicht viel besser.
Eine der Kernfragen, die ich mir bei Docker gestellt habe, ist die der Persistenz. Einen MySQL-Container zu betreiben ist anhand der Vielzahl von Images schnell möglich, aber wo bleiben die Daten? D.h. nicht nur die zu verarbeitenden Datenbanken, sondern ebenso Konfigurationsdateien und Logfiles? Soweit mir bekannt ist – bitte korrigieren, wenn ich falsch liege – ist das Standard-Verfahren unter Docker das Mounten von Volumes, d.h. letztlich eines Verzeichnisses des Host-Systems innerhalb des Docker-Containers. Zugegebenermaßen habe ich mich mit den Data Volume Containern bisher nicht beschäftigt, vielleicht wäre das doch eine gute Idee…
Somit werden die zu persistierenden Daten in einem Verzeichnis des Host-Systems abgelegt, oder im Fall von Konfigurationsdateien umgekehrt in ein Verzeichnis des Containers gebracht, wo die Anwendung darauf zugreifen kann. Das funktioniert soweit prima, nur bietet es keine Antwort auf die Frage des evtl. verteilten Speicherns, Ausfallsicherheit etc.. Denn wenn es schon relativ einfach ist, Docker-Images in ein Repository abzulegen und von dort aus als Container auf beliebigen Systemen zu starten, würde ich mir als nächsten Schritt wünschen, dass dies genauso für die Daten gilt. Beispielsweise bei einem Umzug von Containern auf einen neuen Server. Das Image ist schnell aus dem Repository gezogen. Und die an der alten Stelle befindlichen Daten? Manuell herüber kopieren? Backup und restore? Das erscheint dann letztlich wieder als ein Rückschritt und widerspricht dem Prinzip der Einfachheit. Vielleicht sind die Date Volume Container dafür tatsächlich eine Lösung, immerhin ist diesen in der Docker-Dokumentation auch ein Abschnitt zum Thema Backups gewidmet.
Eine weitere Frage, die sich mir stellte, war die Frage der Aktualisierung. Meine paar privat betriebenen Systeme halte ich sehr gerne aktuell, nicht nur aufgrund von Sicherheits-Updates, sondern auch, um schnell neue Libraries und Funktionen einsetzen zu können. Wie ist es mit den Docker-Images bzw. den laufenden Containern? Irgendwie fühlt es sich immer ein wenig merkwürdig an, wenn mir bekannt ist, dass das zugrunde liegende Betriebssystem-Image schon ein paar Wochen alt ist und keine Security-Updates erfahren hat. Hier ist man – falls man fertige Images aus dem Docker-Repository einsetzt, auf den Autor des Images angewiesen, der hoffentlich das System bald auf eine aktuelle Version bringt. Bei eigenen Images bedeutet es ebenfalls einen gewissen Mehraufwand, die eingesetzten Images zu aktualisieren, dann die Container neu aufzusetzen, anstatt wie „früher“ nur das Host-System zu updaten, auf dem die Anwendung läuft.
Halte ich Docker nun für grundsätzlich schlecht oder nicht geeignet? Nein, absolut nicht. Aber wie so oft gilt – es kommt darauf an! Seit einigen Monaten betreibe ich einen Gitlab-Server in einem Docker-Container. Hinzu kommen PostgreSQL und Redis als Container, die für Gitlab benötigt werden. Dabei verwende ich das Gitlab-Image von Sameer Naik, der dankenswerterweise auch die dazu passenden PostgreSQL- und Redis-Images bereit stellt. Diese Images sind ein sehr gutes, weil positives Beispiel für den Einsatz von Docker. Warum habe ich mich dafür entschieden? Nun, einerseits ist die manuelle Installation von Gitlab – sagen wir mal – eine Herausforderung. Andererseits gefällt mir die empfohlene so genannte „Omnibus“-Installationsvariante nicht besonders, da diese letztlich aus einem Komplettpaket inkl. aller Abhängigkeiten, Binaries, Libraries etc. besteht, die einfach nur in ein Verzeichnis kopiert wird. Nun könnte man behaupten, bei einem Docker-Image passiert dasselbe, und das ist je nach Interpretation auch richtig, aber wenigstens läuft die Anwendung (und damit das System) danach in einem eigenen Namespace. Andererseits sind die Docker-Images von Sameer Naik hervorragend dokumentiert und bieten eine Vielzahl von Konfigurationsoptionen. Somit kann die Installation tatsächlich an die eigenen Bedürfnisse angepasst werden, ob es sich um das SSL-Zertifikat handelt oder die Verwendung eines eigenen Mailservers, Integration von OAuth usw. – alles ist per Environment-Variable einstellbar. Dazu passend bietet der Autor weitere Images an, die ebenfalls von hoher Qualität sind. Und nicht zuletzt sind die Images sehr aktuell, es vergeht nur eine sehr kurze Zeit von Erscheinen einer neuen Gitlab-Version bis zur Verfügbarkeit als Docker-Image. Dabei muss in aller Deutlichkeit erwähnt werden, dass die Docker-Images keine offiziellen Images von Gitlab Inc. sind!
Jedenfalls konnte ich mit den genannten Images tatsächlich sehr schnell einen Gitlab-Server einrichten, in Betrieb nehmen und aktuell halten. Ebenfalls positiv zu bemerken ist, dass das Gitlab-Image auch tatsächlich nur Gitlab mitbringt – und keine Zusammenstellung des kompletten Stacks inkl. Datenbanken etc. darstellt. Einzige Ausnahme ist Nginx, aber na gut…
Wo Licht ist, ist auch Schatten, so sind mir Docker-Images begegnet, die – obwohl teilweise offizielle Images des Herstellers der jeweiligen Software – all die genannten positiven Eigenschaften nicht mitbringen. Da stellt die Basis schon mal ein ziemlich altes Centos dar, von Dokumentaation ist bis auf „docker run xyz…“ nichts zu finden, es werden keine Umgebungsvariablen zur Konfiguration angeboten, von Volumes oder Mountpoints ist auch nichts zu sehen und am Ende birgt das Image sämtliche Dienste in sich, so dass es allenfalls zum Ausprobieren, nicht aber zum Betrieb dient. Wahrscheinlich wurde es eher dazu gebaut mit dem Ziel, die zuvor angebotene vollständige VM zu kopieren und dem Hersteller Download-Traffic zu ersparen. Ich nenne hier bewusst keine Namen… 😉
Weiterhin betreibe ich meinen primären DNS-Server seit kurzer Zeit mit Hilfe eines Docker-Images. Auch hier greife ich auf das Image von Sameer Naik zurück, das sich ebenso problemlos in Betrieb nehmen. Neben dem Bind-Server beinhaltet das Image zur Administration Webmin. Zwar ist damit die Einrichtung und Verwaltung der DNS-Einträge sehr einfach, jedoch wird mit dem Image bereits wieder von dem Konzept, „eine Anwendung pro Container“ abgewichen. Ebenfalls suboptimal empfinde ich, dass Webmin, um genutzt zu werden, nach aussen freigegeben werden muss und somit ein potenzielles Loch für Eindringlinge darstellt. Eine Lösung, zumindest falls sich DNS-Einträge nicht häufiger ändern müssen, ist es, den Container zu stoppen, zu löschen und anschließend neu ohne Weitergabe des Webmin-Ports zu starten. Im Unterschied zur Dokumentation musste ich hingegen zusätzlich den TCP-Port 53 freigeben, damit sich der sekundäre DNS-Server etwaige Updates holen kann. Insgesamt sieht das Start-Kommando somit wie folgt aus:
# mit Webmin sudo docker run --name bind -d --restart=always --env ROOT_PASSWORD=WEBMIN_ROOT_PASSWORT --publish IP_ADRESSE:53:53/udp --publish IP_ADRESSE:53:53/tcp --publish IP_ADRESSE:10000:10000 --volume /srv/docker/bind:/data sameersbn/bind:latest # ohne Webmin: sudo docker run --name bind -d --restart=always --env ROOT_PASSWORD=WEBMIN_ROOT_PASSWORT --publish IP_ADRESSE:53:53/udp --publish IP_ADRESSE:53:53/tcp --volume /srv/docker/bind:/data sameersbn/bind:latest
Insgesamt läuft der DNS unauffällig und problemlos.
Bleibt die Frage nach der Erstellung eigener Images… Hier bin ich noch unentschlossen. Bei meinem aktuellen Brötchengeber könnte ich es mir unter Umständen vorstellen, allerdings ist das Deployment mittels Capistrano nun auch nicht so schlecht, zudem erprobt und es funktioniert. Der Bau eines Docker-Images erscheint hier zumindest momentan nicht notwendig.
Als schwierig empfinde ich mitunter die Wahl eines geeigneten Images. Beispielsweise stehen für populäre Server wie Nginx, Apache2, Postfix usw. eine Vielzahl von Images zur Verfügung. Manche bieten die reine Anwendung, andere kommen mit weiteren Diensten wie Konfigurationstools oder mehr oder minder für einen Anwendungszweck passenden Software. Hier heißt es, entweder mehrere Images bzw. Container zu einem passenden Stack mittels Links zu verknüpfen oder auf eines der Komplettpakete zu vertrauen. Oder auch eigene Images zu erstellen, doch auch der Aufwand sollte nicht unterschätzt werden. Eine genaue Evaluation der Images ist insofern notwendig, insbesondere bzgl. der bereits genannten Eigenschaften wie etwa Möglichkeit, der Konfiguration und Anpassbarkeit, aber auch Aktualität und Wartungsintensität der Systeme. Schließlich möchte man bei Bekanntwerden von Bugs oder sicherheitskritischen Aspekten im besten Fall einfach ein neues Image aufspielen und nicht nach Bekanntwerden zunächst auf den Bugfix und anschließend noch lange auf die Aktualisierung des Images warten.
Fazit
Meine Meinung ist nach wie vor zwiegespalten. Einerseits ist die Technologie definitiv interessant, bietet jedoch noch reichlich Entwicklungspotenzial. Aber die Entwicklung schreitet stetig voran, es mag gut sein, dass einige der Punkte kurze Zeit nach Veröffentlichung dieses Artikels bereits irrelevant geworden sind. Des Weiteren spielen die verfügbaren Images eine entscheidende Rolle, sofern man nicht selbst Images erstellen oder nur mal eben Docker testen möchte. Hier gibt es sehr gute, aber auch eher suboptimale Beispiele. Auf jeden Fall werde ich Docker und die Infrastruktur, die sich inzwischen in diesem Umfeld gebildete hat, weiterhin im Auge behalten und mit Sicherheit auch das eine oder andere Image testen und evtl. auch mal selbst bauen. .
