Images und Container: pull, run, stop, rm
Wer mit Docker arbeitet, hantiert ständig mit zwei verwandten, aber grundverschiedenen Konzepten: Images und Containers. Sie werden im Alltag oft verwechselt, weil sie eng zusammengehören – aber wer sie nicht sauber unterscheidet, baut sich verworrene Pipelines und produziert Datenverluste. In dieser Lektion lernst du den Unterschied, den Lebenszyklus eines Containers und die wichtigsten Befehle: pull, run, start, stop, exec, logs, rm, rmi. Das ist das Vokabular jedes DevOps-Alltags.
Die Analogie macht den Unterschied klar: Ein Image ist wie ein Bauplan. Es liegt schreibgeschützt im Schubfach und beschreibt, wie ein Haus aussehen soll – Materialien, Räume, Anschlüsse. Ein Container ist das fertige Haus, das nach diesem Bauplan gebaut wurde. Aus einem Plan kannst du beliebig viele Häuser bauen, jedes mit eigenem Inhalt (Möbel, Bewohner, Müll). Das Image ändert sich dabei nie – wenn du das Haus abreißt, ist der Plan immer noch da.
1) Image vs. Container – der Schlüsselunterschied
Diese Unterscheidung muss man auf Anhieb beherrschen. Sie taucht in jeder IHK-Prüfung zum Thema Container auf:
Image
- Schreibgeschützt – nicht veränderbar
- Statischer Bauplan + alle Dateien
- Versioniert mit Tags (z. B.
nginx:1.25) - Wird aus Layern aufgebaut, geteilt zwischen Images
- Liegt in der Registry
- Befehl:
docker images
Container
- Veränderbar – läuft, hat Zustand
- Laufende Instanz eines Images
- Eigener Name + ID (z. B.
web,a3f8b2c1) - Hat eigenen Lebenszyklus (Created → Running → Stopped)
- Liegt auf dem Host (Daemon verwaltet)
- Befehl:
docker ps
nginx:latest kannst du beliebig viele Webserver-Container starten, jeder mit eigener Konfiguration, eigenem Port-Mapping, eigenen Daten. Sie teilen sich aber alle die Image-Layer im Storage – das spart Speicherplatz.2) Image-Naming und Tags
Images haben einen mehrteiligen Namen, der sich aus Registry, Repository, Image-Name und Tag zusammensetzt:
[registry/]repository/image[:tag]
nginx
Default: Docker Hub, offizielles Repo „library", Tag „latest". Vollständig: docker.io/library/nginx:latest
nginx:1.25
Konkrete Version statt „latest". Empfohlen für Produktion – kein unvorhersehbares Update.
nginx:1.25-alpine
Alpine-Linux-basiert (~7 MB statt ~140 MB). Beliebt für schlanke Images.
bitnami/nginx
Vom Anbieter Bitnami, eigenes Repo auf Docker Hub.
harbor.firma.de/team/app:v2.3
Privater Harbor-Server, Team-Repo, Version-Tag.
ghcr.io/user/repo:sha-abc1234
GitHub Container Registry, Tag aus Git-Commit-SHA – ideal für CI/CD.
:latest. Der Tag zeigt heute auf nginx:1.27, morgen vielleicht auf 1.28 – das kann Verhalten ändern. Stattdessen explizite Versionen wie nginx:1.25.3-alpine oder besser noch SHA-Digests (nginx@sha256:9d0d62fb...) für 100 % Reproduzierbarkeit.3) Der Container-Lebenszyklus
Container haben mehrere Zustände, zwischen denen sie wechseln. Klick einen Zustand, um zu sehen, wie man dorthin kommt und was er bedeutet:
docker run ist ein Composite-Befehl, der intern create + start kombiniert. Das ist der Befehl, den man im Alltag meist nutzt – die Einzelschritte braucht man nur in speziellen Szenarien.4) Die wichtigsten Befehle in der Praxis
Klick einen Befehl, sieh den realistischen Output und lies, was er macht:
docker run: -d (detached, im Hintergrund), -p host:container (Port-Mapping), --name (sprechender Name statt zufälliger ID), -v host:container (Volume), -e KEY=VAL (Umgebungsvariable), --restart unless-stopped (Auto-Restart bei Crashes). Wer diese sieben Optionen flüssig beherrscht, deckt 90 % aller Anwendungsfälle ab.5) Detached vs. Foreground – wann was?
Eine der häufigsten Anfänger-Verwirrungen: docker run nginx blockt das Terminal. Das ist Absicht – Docker zeigt im Vordergrund die Logs an, und mit Strg-C stoppt der Container. Für produktive Container willst du das nicht – sie sollen im Hintergrund laufen. Dafür ist -d (detached) da.
| Befehl | Verhalten | Typischer Einsatz |
|---|---|---|
docker run nginx | Foreground, blockt Terminal | Tests, Logs live mitsehen |
docker run -d nginx | Detached, im Hintergrund | Server, Daemons |
docker run -it ubuntu bash | Interactive + TTY | In den Container reinarbeiten |
docker run --rm ubuntu echo hi | Einmaliger Run, danach Container gelöscht | One-Shot-Befehle, CI-Jobs |
Wichtige Erkenntnis: Wenn der Hauptprozess im Container endet, endet auch der Container. Das ist anders als bei einer VM, die einen permanenten Init-Prozess hat. Ein Container braucht genau einen Hauptprozess (im Dockerfile via CMD oder ENTRYPOINT definiert). Wenn dieser stirbt, ist der Container im Status „Exited". Genau deshalb startet man oft Webserver wie nginx im „Vordergrund-Modus" – sonst würde der Prozess sofort fork-en und beenden, und der Container wäre tot.
6) Image-Layers und Pull-Optimierung
Wenn du ein Image pullst, lädt Docker nicht eine einzelne Datei herunter, sondern mehrere Layer. Jeder Layer ist ein Stück Filesystem-Diff – z. B. „Layer 1: Base Ubuntu" + „Layer 2: nginx installiert" + „Layer 3: Config kopiert". Diese Layer werden vom Daemon einzeln gecached. Konsequenz: Wenn zwei Images denselben Base-Layer haben, wird er nur einmal gespeichert.
Probier es aus mit einem typischen Pull-Ausgabe:
docker pull nginx:latest beim zweiten Mal sofort fertig ist: Docker prüft nur den Digest – sind die Layer schon da, wird nichts geladen. Auch bei Dockerfiles wird dieser Layer-Cache genutzt – die Reihenfolge der Anweisungen entscheidet darüber, ob Builds Sekunden oder Minuten dauern.7) Container „aufräumen" und Diagnose
Container-Hosts sammeln über die Zeit eine Menge Müll an: gestoppte Container, ungenutzte Images, verwaiste Volumes. Das kostet Speicherplatz und macht das Listing unübersichtlich. Die wichtigsten Aufräum-Befehle:
docker container prune– alle gestoppten Container löschendocker image prune– alle „dangling" Images löschen (Images ohne Tag)docker image prune -a– alle ungenutzten Images löschen (nicht von laufenden Containern referenziert)docker volume prune– ungenutzte Volumes löschendocker system prune -a --volumes– die nukleare Option: löscht alles, was nicht aktiv genutzt wird
Für die Diagnose von Problemen sind diese Befehle gold wert:
docker inspect <name>– komplette JSON-Konfiguration des Containersdocker logs --tail 100 <name>– die letzten 100 Log-Zeilendocker stats– Live-Ressourcenverbrauch aller Container (CPU, RAM, Netzwerk)docker top <name>– Prozessliste im Containerdocker events– Live-Stream aller Daemon-Events (Create, Start, Stop, Die …)
Diese Werkzeuge sind die DevOps-Pflicht: Wer einen Incident mit einem Container-basierten Service hat, schaut zuerst in docker logs und docker inspect. In Produktions-Umgebungen werden diese Daten meist in zentrale Log-Aggregatoren gepumpt – Loki, ELK, Datadog – damit man auch in großen Clustern den Überblick behält.
Zusammenfassung
Ein Image ist ein schreibgeschützter Bauplan, ein Container eine laufende Instanz davon – aus einem Image können viele Container entstehen. Image-Naming: [registry/]repository/image[:tag], z. B. nginx:1.25-alpine. Latest-Tag nie in Produktion, immer feste Versionen. Container-Lebenszyklus: Image → Created → Running → (Paused) → Stopped → Removed; docker run = create + start in einem. Wichtigste Befehle: pull/run/ps/logs/exec/stop/rm/rmi. Wichtige Flags: -d (detached), -p (Port-Mapping), --name, -it (interactive), --rm (auto-cleanup), -e (Env-Variable), --restart. Container endet, wenn der Hauptprozess endet – Webserver müssen im Vordergrundmodus laufen. Layer-Mechanik: Images bestehen aus mehreren Layern, die gemeinsam gecached werden – darum sind wiederholte Pulls schnell. Aufräumen mit prune-Befehlen, Diagnose mit inspect, logs, stats, top, events.
Verwandte Lektionen: Docker-Architektur · Dockerfile schreiben · Docker Volumes · und mehrWeitere relevante LektionenContainer vs. VMDocker-NetzwerkeDocker ComposeDocker-SicherheitLinux-GrundkommandosIncident ManagementLog-Analyse