Docker
Docker verpackt Software samt allen Abhängigkeiten in Container — so läuft sie auf jedem Host exakt gleich.
Das ist der Aufbau: ein Dockerfile als Bauplan, die Docker-Engine, eine Registry und ein zweiter Host.
In 30 Sekunden
Docker ist eine Software, die Anwendungen in Container verpackt. Ein Container enthält die Applikation samt allem, was sie zum Laufen braucht — Laufzeitumgebung, Bibliotheken, Einstellungen. Gebaut wird er aus einem Image, einer unveränderlichen Vorlage, die über eine Registry (einen zentralen Ablageort) verteilt wird. Weil der Container den Betriebssystem-Kern des Hosts mitbenutzt, startet er in Sekunden und braucht viel weniger Ressourcen als eine virtuelle Maschine. Deshalb ist Docker heute der Standard, um Server-Dienste auszuliefern und zu betreiben.
Docker funktioniert wie der Schiffscontainer im Welthandel: Was drin ist, spielt für den Transport keine Rolle — Hauptsache, der Container hat das genormte Format. Kran, Schiff und Lastwagen müssen nichts über den Inhalt wissen. Genauso ist es egal, ob im Docker-Container ein Webshop, eine Datenbank oder ein MQTT-Broker steckt: Jeder Host, auf dem Docker läuft, kann ihn starten — immer mit demselben Handgriff.
Wo trifft man Docker an?
Server-Dienste und Web-Anwendungen
Der häufigste Fall: Webserver, Datenbanken, Shops oder Schnittstellen laufen als Container auf einem Server. Beispiel: Ein Blog samt Datenbank wird mit einem einzigen Befehl gestartet — und läuft nach einem Server-Wechsel anderswo exakt gleich weiter.
IoT und Edge (z. B. Raspberry Pi, Industrie-Gateway)
Auf kleinen Geräten am Netzwerkrand zählt jedes Megabyte, und Container sind viel leichter als virtuelle Maschinen. Beispiel: Node-RED und ein MQTT-Broker wie Mosquitto laufen als zwei getrennte Container auf einem Raspberry Pi.
Entwicklungsumgebungen
Jedes Teammitglied bekommt mit einem Befehl dieselbe Umgebung — gleiche Datenbank-Version, gleiche Werkzeuge. Beispiel: Ein neuer Entwickler ist am ersten Tag arbeitsfähig, statt tagelang Software zu installieren.
Selbst-Hosting und Homelab
Wer Dienste wie Nextcloud, Home Assistant oder Pi-hole selbst betreibt, installiert sie fast immer als Container. Beispiel: Zehn verschiedene Dienste laufen sauber getrennt auf einem einzigen Heimserver, ohne sich in die Quere zu kommen.
Automatisierte Builds und Tests (CI/CD)
Build-Server bauen und testen Software in frischen Containern — jeder Lauf startet in einer sauberen, identischen Umgebung. Beispiel: Nach jeder Code-Änderung baut die Pipeline das Image neu und testet es automatisch, bevor es live geht.
Microservices-Architekturen
Grosse Anwendungen werden in viele kleine Dienste zerlegt, jeder in seinem eigenen Container — einzeln aktualisierbar und skalierbar. Beispiel: Warenkorb, Bezahlung und Suche eines Online-Shops laufen als getrennte Container.
Gut geeignet für
- Für reproduzierbare Installationen, weil ein Image auf jedem Host mit Docker exakt gleich läuft — das «läuft bei mir»-Problem verschwindet.
- Für viele Dienste auf einem Server, weil Container sauber voneinander getrennt sind und sich nicht gegenseitig die Abhängigkeiten kaputt machen.
- Für knappe Hardware wie Edge-Geräte, weil Container den Betriebssystem-Kern des Hosts teilen und darum viel weniger Speicher und Rechenleistung brauchen als virtuelle Maschinen.
- Für schnelles Ausprobieren, weil ein fertiges Image in Sekunden gestartet und rückstandsfrei wieder entfernt ist.
- Für den Weg in die Automatisierung, weil sich Images in Pipelines automatisch bauen, testen und ausrollen lassen.
Weniger geeignet für
- Für Anwendungen, die ein anderes Betriebssystem oder eigene Kernel-Module brauchen, weil Container den Kernel des Hosts mitbenutzen; besser eine virtuelle Maschine (z. B. Proxmox/KVM oder Hyper-V).
- Für klassische Desktop-Programme mit grafischer Oberfläche, weil Docker auf Server-Dienste ausgelegt ist; besser die normale Installation oder eine VM.
- Für strikt getrennte Mandanten mit hohem Schutzbedarf, weil die Isolation eines Containers schwächer ist als die einer VM; besser virtuelle Maschinen oder getrennte Hardware.
- Für grosse Flotten mit Dutzenden Servern und Hunderten Containern, weil Docker allein keine Orchestrierung über viele Hosts bietet; besser Kubernetes (oder für kleinere Setups Docker Swarm).
Fakten
- Container-Plattform (Software, kein Protokoll)
- 2013 (Docker, Inc.; Open-Source-Kern: Moby)
- Linux-Kernel-Funktionen: Namespaces (Isolation) und cgroups (Ressourcen-Limits)
- OCI-Standard (Open Container Initiative), herstellerübergreifend
- docker build, docker push, docker pull, docker run
- docker compose beschreibt ganze Stacks in einer einzigen Textdatei
- Registries wie Docker Hub oder eine eigene, private Registry
- Docker Engine Open Source (Apache 2.0); Docker Desktop für grössere Firmen kostenpflichtig
Im Detail
Image und Container — der entscheidende Unterschied
Das Image ist die unveränderliche Vorlage: ein Stapel schreibgeschützter Schichten mit Basis-System, Laufzeitumgebung und Applikation. Der Container ist die laufende Instanz dieses Images — er bekommt lediglich eine dünne, beschreibbare Schicht obendrauf. Stoppt man ihn und startet das Image neu, beginnt alles wieder im definierten Ausgangszustand. Genau diese Unveränderlichkeit macht Installationen reproduzierbar.
Schichten sparen Zeit und Speicherplatz
Images bestehen aus Schichten, die mehrfach verwendet werden: Nutzen zehn Images dasselbe Basis-System, liegt diese Schicht nur einmal auf der Festplatte. Beim Aktualisieren lädt Docker nur die geänderten Schichten nach. Darum sind Updates oft in Sekunden erledigt — auch über langsame Leitungen, etwa zu einem Gateway im Feld.
Ein Container ist keine virtuelle Maschine
Eine virtuelle Maschine bringt ein komplettes eigenes Betriebssystem mit und wird von einem Hypervisor (der Verwaltungsschicht für VMs) betrieben. Ein Container dagegen ist nur ein besonders gut abgeschotteter Prozess, der den Kernel des Hosts mitbenutzt. Das macht ihn klein und schnell — bedeutet aber auch: Alle Container auf einem Host hängen am selben Kernel.
Sicherheit: gut abgeschottet, aber kein Tresor
Die Isolation eines Containers ist schwächer als die einer virtuellen Maschine — eine Schwachstelle im Kernel betrifft potenziell alle Container auf dem Host. Wichtig ist deshalb: Images nur aus vertrauenswürdigen Quellen beziehen (offizielle Images oder eigene Builds), regelmässig aktualisieren und Container nicht unnötig mit Root-Rechten oder erweiterten Privilegien laufen lassen. Wer diese Grundregeln einhält, betreibt mit Docker sehr solide Systeme.
Vom einzelnen Container zum ganzen Stack
In der Praxis besteht ein Dienst selten aus einem einzigen Container — meist gehören Datenbank, Applikation und vielleicht ein Reverse Proxy zusammen. Mit docker compose beschreibt man diesen Verbund in einer einzigen Textdatei und startet ihn mit einem Befehl. Erst wenn viele Server und sehr viele Container im Spiel sind, lohnt sich der Schritt zu einem Orchestrierer wie Kubernetes.
Für den praktischen Einstieg — von der Installation über die ersten Container bis zu docker compose — gibt es auf iotueli.ch passende Schritt-für-Schritt-Anleitungen aus der Praxis.