Was ist Docker?

Jede Anwendung braucht mehr als ihren eigenen Code: eine bestimmte Version einer Programmiersprache, Bibliotheken, Einstellungen, manchmal ein bestimmtes Betriebssystem-Detail. Genau daran scheitern Umzüge seit Jahrzehnten, und der Satz dazu ist berühmt: Auf meinem Rechner läuft es doch. Docker löst das Problem, indem es die Anwendung mit allem, was sie braucht, in ein Paket packt. Dieses Paket, der Container, verhält sich überall gleich, egal auf welchem Rechner es startet.

Docker ist dabei kein Cloud-Anbieter, sondern die Technik darunter. Container laufen bei AWS, in Google Cloud, in Azure, auf einem gemieteten Server in Deutschland und auf dem Laptop der Entwicklung, überall auf dieselbe Weise. Genau das hält euch beweglich: Was heute bei einem Anbieter läuft, läuft morgen woanders, ohne dass die Anwendung umgebaut wird.

Beschrieben wird so ein Container in einer kleinen Textdatei, dem Dockerfile. Sie liest sich wie ein Rezept: Nimm diese Grundlage, kopiere den Code hinein, installiere die Abhängigkeiten, starte das Programm. So sieht das für eine kleine Node.js-Anwendung aus:

Docker unterscheidet zwei Dinge: das Image und den Container. Das Image ist das fertig gepackte Paket, eine Art Schablone, die sich beliebig oft verwenden lässt. Der Container ist ein laufendes Exemplar dieser Schablone. Aus einem Image lassen sich also drei, zehn oder hundert gleiche Container starten, etwa wenn eine Anwendung mehr Last bekommt und weitere Exemplare gebraucht werden.

Der entscheidende Trick: Ein Container bringt kein eigenes Betriebssystem mit, sondern teilt sich den Kern des Systems mit dem Rechner, auf dem er läuft. Er enthält nur die Anwendung und ihre Abhängigkeiten. Deshalb startet er in Sekunden statt in Minuten, und auf einem Server, auf dem drei virtuelle Maschinen laufen, laufen problemlos dreißig Container. Gebaut und gestartet wird mit zwei kurzen Befehlen:

Fertige Images liegen in einer Registry, einem Lager, aus dem sich jeder Server bedienen kann. Die bekannteste ist Docker Hub, dort gibt es geprüfte Grundlagen für fast alles, von Datenbanken bis zu Webservern. Wer viele Container auf vielen Rechnern betreibt, nimmt dazu ein Verwaltungswerkzeug wie Kubernetes, das von Google stammt und mit denselben Paketen arbeitet.

Container sind heute der Normalfall, wenn Anwendungen entwickelt und betrieben werden. Typische Einsatzgebiete sind:

• Webanwendungen und Portale, die auf dem Entwicklungsrechner und dem Server identisch laufen sollen
• Testumgebungen, die sich in Minuten aufbauen und wieder wegwerfen lassen
• Mehrere Anwendungen auf einem Server, sauber getrennt, ohne sich mit ihren Versionen ins Gehege zu kommen
• Interne Werkzeuge, die bisher am Rechner einer einzelnen Person hingen
• Umzüge zwischen Anbietern, weil der Container den Ort nicht festlegt

Bei uns ist Docker Teil der täglichen Arbeit: Wir bauen unsere Projekte in Containern, damit die Testumgebung dieselbe ist wie der spätere Betrieb. Fehler tauchen so dort auf, wo sie billig sind, nämlich vor der Veröffentlichung. Was wir damit umsetzen, steht auf unserer Seite zur Docker-Betreuung und bei den Webanwendungen.

Die Technik hinter Containern gab es in Ansätzen schon lange im Linux-Betriebssystem, aber sie war umständlich zu bedienen. Docker erschien 2013, entwickelt bei einem kleinen Hosting-Unternehmen namens dotCloud, und machte aus der Spezialistentechnik ein Werkzeug für jedermann: ein Befehl zum Bauen, ein Befehl zum Starten. Die Idee traf einen Nerv, und innerhalb weniger Jahre stellte die ganze Branche auf Container um.

Docker ist ein Verpackungswerkzeug, kein Wundermittel. Ein paar Grenzen gehören zur ehrlichen Antwort dazu:

• Es macht eine langsame oder fehlerhafte Anwendung nicht besser: verpackt wird, was da ist, samt seiner Schwächen
• Daten leben nicht im Container, sondern daneben in einem Speicher oder einer Datenbank, und um die muss sich weiterhin jemand kümmern
• Es braucht jemanden, der sich kümmert: ohne Pflege werden Container zur Last statt zur Hilfe
• Für eine einfache Webseite auf normalem Webhosting bringt ein Container nichts und macht die Pflege nur komplizierter

Diese Punkte sprechen nicht gegen Docker, sie ordnen es ein. Der Container ist die Verpackung, nicht der Inhalt, und gute Verpackung ersetzt keinen guten Inhalt.

Vor Docker war die virtuelle Maschine der übliche Weg, mehrere Anwendungen auf einem Server zu trennen. Sie ist ein kompletter Rechner in Software, mit eigenem Betriebssystem, und genau das ist der Unterschied: gründlichere Trennung gegen mehr Gewicht. Eine Orientierung, wann was passt:

• Viele Anwendungen sollen sparsam auf einem Server laufen: Container, denn sie teilen sich das Betriebssystem
• Schnelles Starten, Kopieren und Wegwerfen zählt, etwa für Tests: Container, sie stehen in Sekunden
• Ein anderes Betriebssystem wird gebraucht, etwa Windows auf einem Linux-Server: virtuelle Maschine
• Strikte Trennung aus Sicherheitsgründen, etwa für Systeme verschiedener Kunden: virtuelle Maschine, die Mauer ist dicker
• Alte Software, die sich nicht sauber verpacken lässt: virtuelle Maschine als pragmatische Lösung

In der Praxis ist es oft kein Entweder-oder: Bei den Cloud-Anbietern laufen Container in aller Regel auf gemieteten virtuellen Maschinen, die beiden Techniken stapeln sich also. Für die Frage, wie eure Anwendung betrieben werden soll, zählt am Ende der konkrete Fall, und den rechnen wir in der Beratung durch.

Als Auftraggeber seht ihr Docker nie direkt, aber ihr spürt seine Wirkung an drei Stellen. Erstens bei der Qualität: Wenn Entwicklung und Betrieb dieselbe Umgebung nutzen, verschwinden die Fehler, die früher erst auf dem Server auftauchten. Zweitens bei der Übergabe: Eine Anwendung im Container kann ein neuer Dienstleister starten, ohne wochenlang die Eigenheiten des alten Servers zu erforschen. Das Dockerfile dokumentiert, was die Anwendung braucht.

Drittens bei der Anbieterbindung: Ein Container legt nicht fest, wo er läuft. Wird das Hosting zu teuer oder der Anbieter unzuverlässig, zieht die Anwendung um, ohne umgebaut zu werden. Wer eine Anwendung beauftragt, darf deshalb ruhig fragen, ob sie in Containern entwickelt wird. Die Antwort sagt etwas darüber, wie leicht ihr später den Kurs wechseln könnt, und über den laufenden Betrieb, den wir als Hosting und Wartung übernehmen.

Container sind längst die Gegenwart: Neue Anwendungen werden standardmäßig so entwickelt und betrieben, und alle großen Cloud-Anbieter behandeln sie als Grundeinheit ihrer Dienste. Diese Entwicklung dreht sich nicht mehr um, dafür ist zu viel Infrastruktur darauf aufgebaut.

Beim Werkzeug selbst ist das Bild differenzierter. Das Containerformat ist seit 2015 ein offener Standard, und neben Docker gibt es inzwischen andere Werkzeuge, die damit arbeiten. Für euch als Auftraggeber ist das die eigentliche Sicherheit: Selbst wenn das Unternehmen Docker eines Tages an Bedeutung verlöre, bleiben die Container lauffähig, weil das Format niemandem allein gehört. Eine Investition in Container ist deshalb keine Wette auf eine Firma, sondern auf einen Branchenstandard.