Docker: Was Container sind und wie du sie auf dem Server nutzt

Was Docker ist

Docker ist eine Software, die Anwendungen in Container verpackt und ausführt. Ein Container ist ein isolierter Prozess auf dem Betriebssystem: Er hat sein eigenes Dateisystem, seine eigenen Netzwerkeinstellungen und sieht von den anderen Containern nichts.

Technisch nutzt Docker dafür Funktionen, die der Linux-Kernel schon vorher hatte — Namespaces für die Isolation, cgroups für die Ressourcenbegrenzung. Die Leistung von Docker liegt weniger in diesen Bausteinen als darin, sie bedienbar gemacht zu haben. Vor Docker war Containerisierung möglich, aber unbequem.

Der Unterschied zum klassischen Vorgehen:

Ohne Container installierst du auf dem Server eine Datenbank, einen Webserver und deine Anwendung. Alle teilen sich dieselben Bibliotheken. Braucht eine Anwendung eine andere Version als die andere, hast du ein Problem.

Mit Containern läuft jede Komponente in ihrem eigenen Paket, mit ihren eigenen Abhängigkeiten. Zwei Anwendungen mit unterschiedlichen PHP-Versionen auf demselben Server sind kein Konflikt mehr, sondern zwei Container.

Container vs. virtuelle Maschine

Das ist der Punkt, an dem das Verständnis meist entsteht oder scheitert.

Eine virtuelle Maschine emuliert einen kompletten Rechner. Sie hat ein eigenes Betriebssystem mit eigenem Kernel, eigenem Bootvorgang, eigenem Speicherbedarf. Auf einem Host laufen mehrere komplette Betriebssysteme parallel.

Ein Container teilt den Kernel des Hostsystems. Er bringt nur mit, was oberhalb des Kernels nötig ist: Bibliotheken, Laufzeitumgebung, die Anwendung selbst. Kein zweites Betriebssystem, kein Bootvorgang.

Die Konsequenz für die Praxis: Auf einem Server, auf dem drei virtuelle Maschinen liefen, laufen problemlos dreißig Container. Dafür ist die Isolation schwächer — dazu mehr im Abschnitt zu den Grenzen.

Beides schließt sich nicht aus. Ein verbreitetes Muster ist ein virtueller Server, auf dem Docker läuft: die VM liefert die saubere Trennung zum Nachbarn, Docker die effiziente Aufteilung darin.

Die drei Begriffe: Image, Container, Registry

An dieser Stelle scheitern Einsteiger am häufigsten, weil die Begriffe eng verwandt sind.

Image — die unveränderliche Vorlage. Ein Image enthält das Dateisystem und die Anweisung, was beim Start passieren soll. Images sind schichtweise aufgebaut: Eine Basisschicht mit dem Betriebssystem-Unterbau, darüber Schichten für installierte Pakete, darüber die Anwendung. Diese Schichten werden zwischen Images geteilt, was Speicherplatz spart.

Container — eine laufende Instanz eines Images. Aus einem Image lassen sich beliebig viele Container starten. Der Container ist flüchtig: Wird er gelöscht, sind Änderungen in seinem Dateisystem weg.

Registry — der Ort, an dem Images liegen. Docker Hub ist die bekannteste öffentliche Registry; für praktisch jede verbreitete Software existiert dort ein fertiges Image. Firmen betreiben oft eigene, private Registries.

Der Vergleich, der hilft: Das Image ist das Kochrezept, der Container das gekochte Gericht, die Registry das Kochbuch.

Ein Punkt, der in der Praxis wichtig wird: Weil Container flüchtig sind, brauchen Daten, die überleben sollen, ein Volume — einen Speicherbereich außerhalb des Containers. Eine Datenbank ohne Volume verliert beim Neustart des Containers alles. Das ist der häufigste Anfängerfehler.

Docker Compose: mehrere Container zusammen

Eine echte Anwendung besteht selten aus einem Container. Ein typisches Setup hat einen Webserver, eine Anwendung und eine Datenbank — drei Container, die miteinander sprechen müssen.

Docker Compose beschreibt dieses Zusammenspiel in einer einzigen Textdatei: welche Container laufen, welche Images sie nutzen, welche Ports offen sind, welche Volumes eingebunden werden, welcher Container von welchem abhängt. Ein Befehl startet das gesamte Gebilde.

Der praktische Wert liegt in der Reproduzierbarkeit. Die Compose-Datei ist Text und lässt sich versionieren. Wer sie hat, kann dieselbe Umgebung auf einem anderen Server in Minuten aufbauen — ohne Installationsdokumentation, ohne Rätselraten, welche Konfiguration vergessen wurde.

Für so gut wie jede Anleitung, die du zu selbst gehosteten Anwendungen findest, ist Compose inzwischen der Standardweg.

Wofür Docker in der Praxis taugt

Selbst gehostete Anwendungen betreiben. Der verbreitetste Einsatz auf eigenen Servern. Cloud-Speicher, Automatisierung, Mailserver, Chat, Lernplattformen, Shops — für praktisch jede dieser Kategorien gibt es fertige Images, und die Installation reduziert sich auf eine Compose-Datei statt einer Seite Installationsschritte.

Mehrere Versionen parallel. Zwei Projekte brauchen unterschiedliche PHP- oder Node-Versionen? Zwei Container, kein Konflikt.

Testen ohne Rückstände. Eine Software ausprobieren, ohne den Server zuzumüllen. Container löschen, Server ist wieder sauber.

Entwicklung und Produktion angleichen. Dasselbe Image lokal und auf dem Server bedeutet, dass „läuft bei mir" seltener zum Problem wird.

Umzüge vereinfachen. Compose-Datei und Volumes mitnehmen, auf dem neuen Server starten. Deutlich weniger fehleranfällig als eine Neuinstallation nachzubauen.

Docker auf einem eigenen Server

Docker braucht Root-Zugriff auf das System. Das schließt klassisches Shared Webhosting aus — dort hast du keinen Zugriff auf die Ebene, auf der Docker arbeitet.

Praktikabel ist Docker auf einem virtuellen Server (vServer/VPS) oder einem dedizierten Server. Dort hast du volle Kontrolle über das Betriebssystem und kannst Docker installieren wie jede andere Software.

Was du dafür brauchst:

• Root-Zugriff per SSH
• Ein Linux-System — Ubuntu und Debian sind die verbreitetsten Grundlagen und in den meisten Anleitungen vorausgesetzt
• Ausreichend RAM — der Bedarf hängt an den Containern, nicht an Docker selbst. Ein einzelner Reverse Proxy kommt mit wenig aus, eine Datenbank plus Anwendung braucht deutlich mehr.
• Speicherplatz für Images und Volumes. Images summieren sich schneller als erwartet; ein regelmäßiges Aufräumen ungenutzter Images gehört zur Wartung.

Der Reverse Proxy ist der Baustein, der fast immer dazukommt. Laufen mehrere Container mit Webdiensten auf einem Server, braucht es eine Instanz davor, die Anfragen anhand der Domain auf den richtigen Container verteilt und TLS-Zertifikate verwaltet. Ohne das kann nur ein Dienst auf Port 443 hören.

Was Docker nicht löst

Vier Punkte, die in Einführungen regelmäßig fehlen:

Container sind keine Sicherheitsgrenze wie eine VM. Sie teilen den Kernel des Hosts. Eine Lücke im Kernel oder eine zu großzügig konfigurierte Berechtigung kann die Isolation durchbrechen. Für die Trennung zwischen verschiedenen Kunden oder Sicherheitszonen ist eine virtuelle Maschine die passendere Grenze.

Ein Image ist nur so vertrauenswürdig wie seine Quelle. Aus einer öffentlichen Registry lädst du fremden Code. Offizielle und verifizierte Images sind die sichere Wahl; bei unbekannten Anbietern lohnt ein Blick darauf, wer das Image pflegt und wann es zuletzt aktualisiert wurde. Veraltete Images bringen veraltete Bibliotheken mit — samt bekannter Lücken.

Docker ersetzt keine Backups. Container sind flüchtig, das ist Absicht. Die Daten liegen in Volumes, und die brauchen eine eigene Sicherungsstrategie. Wer nur die Compose-Datei sichert, hat die Struktur, aber keine Inhalte.

Updates bleiben Arbeit. Ein Container, der seit einem Jahr läuft, läuft mit der Software von vor einem Jahr. Images müssen aktualisiert und Container neu gestartet werden. Automatisierte Update-Werkzeuge helfen, nehmen die Verantwortung aber nicht weg.

Dazu eine Einordnung: Docker ist für einen einzelnen Server oder eine Handvoll Container das richtige Werkzeug. Wer Dutzende Container über mehrere Server verteilt betreiben und automatisch ausfallsicher halten will, landet bei einer Orchestrierung wie Kubernetes. Für die meisten Website- und Anwendungsfälle auf einem eigenen Server ist das deutlich mehr Komplexität als nötig.

Häufige Fragen

Was ist Docker einfach erklärt?

Docker verpackt eine Anwendung mit allem, was sie zum Laufen braucht, in ein Paket — einen Container. Dieses Paket verhält sich auf jedem System gleich. Damit entfällt das Problem, dass Software auf einem Rechner läuft und auf einem anderen nicht.

Was ist der Unterschied zwischen Docker und einer virtuellen Maschine?

Eine virtuelle Maschine bringt ein komplettes eigenes Betriebssystem mit. Ein Container teilt den Kernel des Hostsystems und enthält nur die Anwendung samt Abhängigkeiten. Container starten deshalb schneller und brauchen weniger Ressourcen, bieten dafür eine schwächere Isolation.

Was ist der Unterschied zwischen Docker und Kubernetes?

Docker führt Container aus. Kubernetes verwaltet viele Container über mehrere Server hinweg — Verteilung, Ausfallsicherheit, Skalierung. Für einen einzelnen Server ist Docker allein in der Regel ausreichend.

Brauche ich Docker als Website-Betreiber?

Bei einer normalen Website auf Webhosting nein. Relevant wird Docker, sobald du eigene Anwendungen auf einem eigenen Server betreiben willst — etwa Cloud-Speicher, Automatisierungswerkzeuge oder einen Mailserver.

Läuft Docker auf Webhosting?

Nein. Docker braucht Root-Zugriff auf das Betriebssystem, den klassisches Shared Hosting nicht bietet. Nötig ist ein virtueller oder dedizierter Server.

Gehen Daten verloren, wenn ein Container gelöscht wird?

Alles, was im Container selbst gespeichert wurde, ja. Deshalb werden dauerhafte Daten in Volumes ausgelagert — Speicherbereiche außerhalb des Containers, die den Neustart oder das Löschen überleben. Das rechtzeitig einzurichten ist der häufigste Anfängerfehler.

Fazit

Docker ist im Kern eine Antwort auf die Frage, wie Software überall gleich läuft. Der Nutzen zeigt sich am deutlichsten dort, wo mehrere Anwendungen auf einem Server koexistieren müssen — ohne sich in die Abhängigkeiten zu geraten.

Für den Einstieg reicht ein virtueller Server mit Root-Zugriff und eine Compose-Datei. Die konzeptionelle Hürde liegt nicht bei den Befehlen, sondern bei drei Begriffen: Image als Vorlage, Container als laufende Instanz, Volume für alles, was überleben soll. Wer die auseinanderhält, hat den schwierigsten Teil hinter sich.