Docker auf Ubuntu: Vollständige Installations- und Nutzungsanleitung
Docker ist eine Open-Source-Containerisierungsplattform, die Anwendungen und ihre Abhängigkeiten in isolierte, portable Einheiten namens Container verpackt. Im Gegensatz zu virtuellen Maschinen teilen Container den Kernel des Host-Betriebssystems, was sie deutlich leichter, schneller beim Start und ressourceneffizienter macht — ein entscheidender Unterschied für alle, die Workloads in einer VPS Hosting-Umgebung betreiben, wo Rechenressourcen sich direkt auf Kosten und Leistung auswirken.
Dieser Leitfaden behandelt den vollständigen Docker-Installationsprozess auf Ubuntu 20.04, 22.04 und 24.04 LTS, einschließlich Post-Installations-Härtung, Docker Compose-Workflows und produktionsrelevanter Befehlsmuster, die die meisten Tutorials auslassen.
Voraussetzungen und Systemanforderungen
Bevor Sie einen einzigen Befehl ausführen, überprüfen Sie Folgendes:
- Ubuntu-Version: 20.04 LTS (Focal), 22.04 LTS (Jammy) oder 24.04 LTS (Noble). Der `lsb_release -cs`-Befehl, der beim Repository-Setup verwendet wird, erkennt Ihren Codenamen automatisch.
- Architektur: `amd64`, `arm64` oder `armhf` werden alle vom offiziellen Docker-Repository unterstützt.
- Kernel-Version: Docker erfordert Linux-Kernel 3.10 oder höher. Führen Sie `uname -r` aus, um dies zu bestätigen.
- Benutzerrechte: `sudo` oder Root-Zugriff ist für die Installation und die Daemon-Verwaltung zwingend erforderlich.
- Festplattenspeicher: Mindestens 2 GB freier Speicherplatz auf der Partition, die `/var/lib/docker` hostet, wo Docker Images, Container, Volumes und Build-Cache speichert. Auf Produktionssystemen sollten Sie dieses Verzeichnis auf einer dedizierten Partition oder einem dedizierten Volume einbinden.
Kritischer Schritt vor der Installation: Wenn Sie Docker zuvor aus Ubuntus Standard-`apt`-Repository (das `docker.io`-Paket) installiert haben, entfernen Sie es zuerst, um Konflikte mit den offiziellen Docker CE-Paketen zu vermeiden:
“`bash
sudo apt remove docker docker-engine docker.io containerd runc
“`
Schritt 1: Systempakete aktualisieren
Bringen Sie den Paketindex und die installierten Pakete auf ihre neuesten Versionen, bevor Sie ein neues Repository hinzufügen:
“`bash
sudo apt update
sudo apt upgrade -y
“`
Dies stellt sicher, dass der Abhängigkeits-Resolver von `apt` mit aktuellen Paketmetadaten arbeitet und dass Ihre Basis-Systembibliotheken nicht veraltet sind — eine häufige Quelle subtiler Laufzeitfehler bei containerisierten Anwendungen.
Schritt 2: Docker Engine aus dem offiziellen Repository installieren
Ubuntus Standard-`apt`-Repositories liefern ein Paket namens `docker.io`, das von Canonical gepflegt wird und typischerweise mehrere Versionen hinter Dockers offiziellem Release zurückliegt. Für den Produktionseinsatz installieren Sie immer aus Dockers eigenem Repository.
2.1 Transport- und Verifizierungsabhängigkeiten installieren
“`bash
sudo apt install apt-transport-https ca-certificates curl software-properties-common gnupg lsb-release -y
“`
Warum `gnupg`? Ab Ubuntu 22.04 ist `gpg` nicht immer standardmäßig vorhanden. Die explizite Einbindung verhindert, dass der GPG-Schlüssel-Import lautlos fehlschlägt.
2.2 Offiziellen GPG-Schlüssel von Docker hinzufügen
“`bash
sudo install -m 0755 -d /usr/share/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg –dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
sudo chmod a+r /usr/share/keyrings/docker-archive-keyring.gpg
“`
Der `chmod a+r`-Schritt wird in Tutorials häufig übersprungen, ist aber auf Systemen notwendig, wo `apt` unter einem eingeschränkten Benutzerkontext läuft — ohne ihn kann der Paketmanager den Schlüsselbund nicht lesen und gibt einen `NO_PUBKEY`-Fehler während `apt update` aus.
2.3 Das stabile Docker-Repository hinzufügen
“`bash
echo
"deb [arch=$(dpkg –print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg]
https://download.docker.com/linux/ubuntu
$(lsb_release -cs) stable" |
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
“`
Die `arch=$(dpkg –print-architecture)`-Substitution ist auf ARM-basierten Servern unerlässlich. Das Hardcoding von `amd64` hier ist ein häufiger Fehler, der zu stillen Paketauflösungsfehlern auf ARM-Instanzen führt.
2.4 Docker Engine, CLI und Plugins installieren
“`bash
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
“`
Paketübersicht:
| Paket | Rolle |
|---|
| — | — |
|---|
| `docker-ce` | Docker Engine Daemon (`dockerd`) |
|---|
| `docker-ce-cli` | Client CLI (`docker`-Befehl) |
|---|
| `containerd.io` | Low-Level-Container-Runtime (OCI-konform) |
|---|
| `docker-buildx-plugin` | Erweiterte Build-Funktionen (Multi-Plattform, BuildKit) |
|---|
| `docker-compose-plugin` | Compose V2 integriert als Docker CLI-Plugin |
|---|
Hinweis zu `containerd.io`: Dies ist nicht dasselbe wie das `containerd`-Paket in Ubuntus Standard-Repository. Dockers `containerd.io` ist eine spezifische, getestete Version der containerd-Runtime. Das Mischen beider ist eine bekannte Ursache für Daemon-Startfehler.
Schritt 3: Die Installation überprüfen
Bestätigen Sie, dass der Daemon aktiv ist und beim Booten gestartet wird:
“`bash
sudo systemctl status docker
sudo systemctl enable docker
“`
Überprüfen Sie die installierte Version:
“`bash
sudo docker –version
sudo docker info
“`
`docker info` ist informativer als `–version` allein — es zeigt den verwendeten Storage-Treiber (typischerweise `overlay2`), den cgroup-Treiber (`systemd` vs. `cgroupfs`) sowie die Anzahl der CPUs und den Arbeitsspeicher, auf den Docker zugreifen kann.
Führen Sie den kanonischen Smoke-Test aus:
“`bash
sudo docker run hello-world
“`
Ein erfolgreicher Durchlauf gibt eine „Hello from Docker!”-Meldung aus und bestätigt, dass der Docker-Daemon, das Image-Pulling von Docker Hub und die Container-Ausführung alle korrekt funktionieren.
Schritt 4: Docker für Nicht-Root-Zugriff konfigurieren
Standardmäßig gehört der Docker-Socket (`/var/run/docker.sock`) `root` und der `docker`-Gruppe. Jeder Benutzer, der nicht in der `docker`-Gruppe ist, muss `sudo` für jeden Docker-Befehl verwenden.
“`bash
sudo usermod -aG docker $USER
“`
Wenden Sie die Gruppenmitgliedschaft an, ohne sich abzumelden:
“`bash
newgrp docker
“`
Überprüfen:
“`bash
docker run hello-world
“`
Sicherheitswarnung: Die Mitgliedschaft in der `docker`-Gruppe ist effektiv gleichbedeutend mit passwortlosem `sudo`. Ein Benutzer in der `docker`-Gruppe kann das Host-Dateisystem trivial in einen Container einbinden und alle Dateisystem-Zugriffskontrollen umgehen. Auf Mehrmandanten-Systemen oder gemeinsam genutzten Servern sollten Sie stattdessen rootless Docker verwenden:
“`bash
dockerd-rootless-setuptool.sh install
“`
Der Rootless-Modus führt den Docker-Daemon und Container unter einem nicht privilegierten Benutzer-Namespace aus, was die Angriffsfläche erheblich reduziert. Es ist die empfohlene Konfiguration für jede Umgebung, in der mehrere Benutzer denselben Host teilen.
Schritt 5: Referenz für wichtige Docker-Befehle
Image-Verwaltung
“`bash
Pull a specific image version from Docker Hub
docker pull nginx:1.27-alpine
List locally cached images
docker images
Remove a specific image
docker rmi nginx:1.27-alpine
Remove all dangling (untagged) images to reclaim disk space
docker image prune
Remove all unused images (not just dangling)
docker image prune -a
“`
Produktionstipp: Ziehen Sie in automatisierten oder Produktions-Workflows immer versionierte Tags (z. B. `nginx:1.27-alpine`) anstelle von `latest`. Der `latest`-Tag ist veränderlich — er kann nach einem Registry-Push auf ein anderes Image zeigen und die Reproduzierbarkeit beeinträchtigen.
Container-Lebenszyklus
“`bash
Run a container interactively with a pseudo-TTY
docker run -it ubuntu:22.04 /bin/bash
Run a container in detached mode with port mapping and a name
docker run -d -p 8080:80 –name my-nginx nginx:1.27-alpine
List running containers
docker ps
List all containers (including stopped)
docker ps -a
Stop a running container gracefully (SIGTERM, then SIGKILL after timeout)
docker stop my-nginx
Start a stopped container
docker start my-nginx
Remove a stopped container
docker rm my-nginx
Force-remove a running container (sends SIGKILL immediately)
docker rm -f my-nginx
View real-time logs
docker logs -f my-nginx
Execute a command inside a running container
docker exec -it my-nginx /bin/sh
“`
Ressourcen- und Systeminspektion
“`bash
Display real-time resource usage statistics
docker stats
Inspect detailed container metadata (JSON)
docker inspect my-nginx
Display disk usage by Docker objects
docker system df
Remove all stopped containers, unused networks, dangling images, and build cache
docker system prune
“`
`docker system prune` ist einer der wichtigsten Wartungsbefehle für langlebige Server. Ohne regelmäßige Bereinigung können Dockers Build-Cache und gestoppte Container auf einem aktiven Entwicklungs- oder CI-Host Dutzende von Gigabytes verbrauchen.
Schritt 6: Docker Compose — Orchestrierung von Multi-Container-Anwendungen
Docker Compose V2 (das früher installierte `docker-compose-plugin`) wird als `docker compose` (mit Leerzeichen) aufgerufen, nicht als das veraltete `docker-compose` (mit Bindestrich). Beide Syntaxen funktionieren, wenn Sie das Plugin installiert haben, aber V2 ist der aktuelle Standard.
6.1 Die Compose-Dateistruktur verstehen
Erstellen Sie ein Projektverzeichnis und eine `compose.yml`-Datei (der bevorzugte Dateiname in Compose V2; `docker-compose.yml` wird aus Gründen der Abwärtskompatibilität weiterhin unterstützt):
“`bash
mkdir ~/my-web-app && cd ~/my-web-app
nano compose.yml
“`
Ein produktionsrealistisches Beispiel mit Nginx und einem Backend-Service:
“`yaml
services:
web:
image: nginx:1.27-alpine
ports:
- "8080:80"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
- ./html:/usr/share/nginx/html:ro
depends_on:
- app
restart: unless-stopped
app:
image: node:20-alpine
working_dir: /usr/src/app
volumes:
- ./app:/usr/src/app
command: node server.js
environment:
- NODE_ENV=production
restart: unless-stopped
“`
Wichtige Compose-Direktiven erklärt:
- `restart: unless-stopped` — Der Container startet automatisch nach einem Absturz oder Systemneustart neu, es sei denn, er wurde explizit vom Operator gestoppt. Dies ist die korrekte Richtlinie für langlebige Services; `always` startet auch absichtlich gestoppte Container neu.
- `depends_on` — Steuert die Startreihenfolge, wartet aber nicht darauf, dass der Service *bereit* ist (z. B. eine Datenbank, die Verbindungen akzeptiert). Für Bereitschafts-Gating verwenden Sie `healthcheck` in Kombination mit `condition: service_healthy`.
- `volumes` mit `:ro` — Das Einbinden von Konfigurationsdateien als schreibgeschützt verhindert, dass ein kompromittierter Container-Prozess seine eigene Konfiguration modifiziert.
6.2 Compose-Workflow-Befehle
“`bash
Start all services in detached mode
docker compose up -d
View logs for all services
docker compose logs -f
View logs for a specific service
docker compose logs -f web
List running Compose services
docker compose ps
Scale a specific service to multiple replicas
docker compose up -d –scale app=3
Stop services without removing containers
docker compose stop
Stop and remove containers, networks, and volumes
docker compose down –volumes
Rebuild images before starting (useful after code changes)
docker compose up -d –build
“`
6.3 Den laufenden Service überprüfen
“`bash
curl -I http://localhost:8080
“`
Eine `200 OK`-Antwort bestätigt, dass Nginx korrekt ausliefert. Für Services, die auf einer entfernten VPS Hosting-Instanz laufen, ersetzen Sie `localhost` durch die öffentliche IP-Adresse Ihres Servers und stellen Sie sicher, dass der entsprechende Port in Ihrer Firewall geöffnet ist (`ufw allow 8080/tcp`).
Schritt 7: Docker-Netzwerk-Grundlagen
Das Verständnis des Docker-Netzwerkmodells ist für den Aufbau von Multi-Container-Anwendungen, die sicher kommunizieren, unerlässlich.
Standard-Netzwerktreiber:
| Treiber | Anwendungsfall |
|---|
| — | — |
|---|
| `bridge` | Standard für eigenständige Container; isolierter Netzwerk-Namespace auf dem Host |
|---|
| `host` | Container teilt den Netzwerk-Stack des Hosts; maximale Leistung, keine Isolation |
|---|
| `none` | Kein Netzwerkzugriff; nützlich für Batch-Verarbeitung oder sicherheitssensible Workloads |
|---|
| `overlay` | Multi-Host-Netzwerk für Docker Swarm-Cluster |
|---|
| `macvlan` | Weist dem Container eine MAC-Adresse zu; erscheint als physisches Gerät im Netzwerk |
|---|
Erstellen und Verwenden eines benutzerdefinierten Bridge-Netzwerks:
“`bash
Create an isolated network
docker network create my-app-network
Run containers attached to the custom network
docker run -d –name db –network my-app-network postgres:16-alpine
docker run -d –name api –network my-app-network my-api-image
Containers on the same custom bridge network can resolve each other by name
Inside 'api', you can connect to 'db' using the hostname 'db'
“`
Benutzerdefinierte Bridge-Netzwerke bieten automatische DNS-Auflösung zwischen Containern nach Containername. Das Standard-`bridge`-Netzwerk tut dies nicht — dies ist ein entscheidender Unterschied, der zu Verbindungsfehlern führt, wenn Entwickler annehmen, dass Container im Standard-Netzwerk sich gegenseitig beim Namen erreichen können.
Schritt 8: Persistente Daten mit Docker Volumes
Container sind von Natur aus kurzlebig. Alle Daten, die im Dateisystem eines Containers geschrieben werden, gehen verloren, wenn der Container entfernt wird. Für persistente Speicherung verwenden Sie Volumes oder Bind Mounts.
“`bash
Create a named volume
docker volume create pgdata
Use the volume with a container
docker run -d
–name postgres-db
-e POSTGRES_PASSWORD=securepassword
-v pgdata:/var/lib/postgresql/data
postgres:16-alpine
List volumes
docker volume ls
Inspect a volume (shows mount point on host)
docker volume inspect pgdata
Remove unused volumes
docker volume prune
“`
Volumes vs. Bind Mounts:
| Merkmal | Benanntes Volume | Bind Mount |
|---|
| — | — | — |
|---|
| Von Docker verwaltet | Ja | Nein |
|---|
| Host-Pfad erforderlich | Nein | Ja |
|---|
| Portabel zwischen Hosts | Ja (mit Volume-Treibern) | Nein |
|---|
| Am besten geeignet für | Datenbankdaten, Anwendungszustand | Entwicklungscode, Konfigurationsdateien |
|---|
| Backup-Mechanismus | `docker run –volumes-from` | Standard-Dateisystem-Tools |
|---|
Schritt 9: Docker aktuell halten
Dockers offizielles Repository verwaltet Updates über den Standard-`apt`-Mechanismus:
“`bash
sudo apt update
sudo apt upgrade -y
“`
Um nur Docker-bezogene Pakete zu aktualisieren, ohne das gesamte System zu upgraden:
“`bash
sudo apt install –only-upgrade docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
“`
Überprüfen Sie die Docker-Release-Notes vor größeren Versions-Upgrades, insbesondere bei Änderungen am Storage-Treiber, der cgroup-Versionsbehandlung oder veralteten API-Versionen, die bestehende `compose.yml`-Dateien beeinflussen könnten.
Docker vs. alternative Containerisierungsansätze
| Merkmal | Docker Engine | Podman | LXC/LXD | containerd (standalone) |
|---|
| — | — | — | — | — |
|---|
| Daemon-Architektur | Zentralisierter Daemon | Daemonlos | Daemon-basiert | Daemon-basiert |
|---|
| Rootless-Unterstützung | Ja (v20+) | Nativ | Eingeschränkt | Ja |
|---|
| Docker Compose-Unterstützung | Nativ | Über `podman-compose` | Nein | Nein |
|---|
| OCI-Konformität | Ja | Ja | Nein (LXC-Format) | Ja |
|---|
| Kubernetes-Integration | Über CRI-dockerd-Shim | Natives CRI | Nein | Natives CRI |
|---|
| Windows/macOS-Unterstützung | Docker Desktop | Eingeschränkt | Nein | Nein |
|---|
| Am besten geeignet für | Allgemeine Entwicklung und Produktion | Sicherheitsorientiert, rootless | System-Container, VMs | Kubernetes-Knoten |
|---|
Für Teams, die containerisierte Workloads im großen Maßstab auf Bare Metal betreiben, bietet eine Dedicated Servers-Umgebung volle Kontrolle über Kernel-Parameter, Speicher-I/O-Scheduling und Netzwerkkonfiguration — alles, was sich direkt auf Container-Dichte und Leistung auswirkt.
Checkliste zur Produktionshärtung
Bevor Sie Docker in einer Produktionsumgebung betreiben, gehen Sie Folgendes an:
Daemon-Konfiguration (`/etc/docker/daemon.json`):
“`json
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
},
"storage-driver": "overlay2",
"userns-remap": "default",
"live-restore": true,
"no-new-privileges": true
}
“`
- `log-opts` mit `max-size` und `max-file`: Ohne Log-Rotation füllen Dockers JSON-Log-Dateien Ihre Festplatte. Dies ist eine der häufigsten Ursachen für unerwartete Server-Ausfälle auf containerisierten Hosts.
- `userns-remap: "default"`: Aktiviert das Remapping von Benutzer-Namespaces, sodass Container-Root (UID 0) auf eine nicht privilegierte UID auf dem Host abgebildet wird.
- `live-restore: true`: Ermöglicht es Containern, weiterzulaufen, wenn der Docker-Daemon abstürzt oder während eines Upgrades neu gestartet wird — entscheidend für wartungsfreie Betriebszeiten.
- `no-new-privileges: true`: Verhindert, dass Container-Prozesse zusätzliche Rechte über `setuid`- oder `setgid`-Binärdateien erlangen.
Netzwerk- und Firewall-Überlegungen:
Docker manipuliert `iptables` direkt und umgeht standardmäßig `ufw`-Regeln. Ein Container mit einem veröffentlichten Port (`-p 8080:80`) ist aus dem Internet erreichbar, auch wenn `ufw deny 8080` gesetzt ist. Um `ufw`-Regeln über Dockers `iptables`-Manipulation durchzusetzen, fügen Sie `"iptables": false` zu `daemon.json` hinzu und verwalten Sie das Routing manuell, oder verwenden Sie Dockers `–network host` mit expliziten `ufw`-Regeln.
Für Projekte, die HTTPS-Terminierung erfordern, kombinieren Sie Ihre containerisierte Anwendung mit einem ordnungsgemäß konfigurierten Reverse-Proxy (Nginx oder Traefik) und einem gültigen Zertifikat. SSL Certificates sind eine Voraussetzung für jeden Produktions-Webservice, der hinter einem containerisierten Stack betrieben wird.
Wenn Ihr Workload Machine-Learning-Inferenz, Modell-Serving oder GPU-beschleunigte Datenverarbeitung in Containern umfasst, integriert sich das NVIDIA Container Toolkit direkt mit Docker Engine. GPU Hosting stellt die zugrunde liegende Hardware für diese Workloads bereit.
Für Teams, die mehrere Projekte mit webbasiertem Container-Management verwalten, bietet VPS with cPanel eine verwaltete Control-Panel-Umgebung, die Docker-basierte Deployments für einfachere Anwendungs-Stacks ergänzen kann.
Wichtige technische Erkenntnisse und Entscheidungsmatrix
Wann Docker auf einem VPS vs. einem dedizierten Server verwendet werden sollte:
- Verwenden Sie einen VPS für Entwicklungsumgebungen, Staging und Produktions-Workloads mit niedrigem bis mittlerem Traffic, bei denen die Container-Dichte 10–50 Container beträgt.
- Verwenden Sie einen dedizierten Server, wenn die Container-Dichte 50 Instanzen übersteigt, wenn Sie vorhersehbare I/O-Leistung benötigen (kein Noisy-Neighbor-Effekt) oder wenn Kernel-Parameter-Tuning (`sysctl`) für Ihren Workload erforderlich ist.
Betriebliche Checkliste vor dem Go-Live:
- Log-Rotation in `daemon.json` konfigurieren (`max-size`, `max-file`)
- `live-restore` aktivieren, um Daemon-Neustarts ohne Container-Ausfallzeiten zu überstehen
- Benannte Volumes statt Bind Mounts für zustandsbehaftete Service-Daten verwenden
- Image-Versionen in allen `compose.yml`-Dateien festlegen — niemals `latest` in der Produktion verwenden
- `userns-remap` aktivieren oder rootless Docker auf Mehrmandanten-Hosts betreiben
- `iptables`-Regeln nach der Docker-Installation prüfen, um zu bestätigen, dass die Firewall-Richtlinie nicht umgangen wird
- `restart: unless-stopped` für alle langlebigen Services setzen
- `docker system prune` als geplanten Cron-Job ausführen, um Festplattenerschöpfung zu verhindern
- Benutzerdefinierte Bridge-Netzwerke für die gesamte Inter-Container-Kommunikation verwenden — niemals auf die Standard-Bridge für Service-Discovery vertrauen
FAQ
Verwendet Docker auf Ubuntu standardmäßig `systemd` oder `cgroupfs` als cgroup-Treiber?
Seit Docker Engine 20.10 ist der Standard-cgroup-Treiber auf `systemd`-basierten Systemen (einschließlich aller modernen Ubuntu LTS-Releases) `systemd`. Dies entspricht den Kubernetes-Anforderungen und vermeidet die Instabilität, die durch den gleichzeitigen Betrieb von zwei cgroup-Managern verursacht wird. Sie können dies mit `docker info | grep -i cgroup` überprüfen.
Was ist der Unterschied zwischen `docker compose down` und `docker compose stop`?
`docker compose stop` hält laufende Container an, bewahrt sie aber zusammen mit ihren zugehörigen Netzwerken. `docker compose down` stoppt Container und entfernt sie dann zusammen mit den von Compose erstellten Netzwerken. Das Hinzufügen von `–volumes` zu `down` entfernt auch benannte Volumes, die in der Compose-Datei definiert sind — verwenden Sie dieses Flag in der Produktion mit Vorsicht, da es persistente Daten dauerhaft löscht.
Warum umgeht Docker `ufw`-Firewall-Regeln auf Ubuntu?
Docker fügt seine eigenen `iptables`-Regeln in die `DOCKER`- und `DOCKER-USER`-Chains ein, die vor den `ufw`-`INPUT`-Chain-Regeln ausgewertet werden. Das bedeutet, dass ein mit `-p` veröffentlichter Port unabhängig von der `ufw`-Richtlinie aus dem Internet erreichbar ist. Die korrekte Abhilfe besteht darin, Regeln direkt zur `DOCKER-USER`-Chain hinzuzufügen oder veröffentlichte Ports an eine bestimmte Schnittstelle zu binden (z. B. `-p 127.0.0.1:8080:80`), wenn kein externer Zugriff erforderlich ist.
Wie begrenze ich die CPU und den Arbeitsspeicher, die ein Docker-Container verbrauchen kann?
Verwenden Sie Ressourcenbeschränkungs-Flags zur Laufzeit: `docker run –memory="512m" –cpus="1.5" my-image`. In Compose setzen Sie diese unter dem `deploy.resources`-Schlüssel (Compose V2) oder den übergeordneten `mem_limit`- und `cpus`-Schlüsseln. Ohne Limits kann ein einzelner außer Kontrolle geratener Container Host-Ressourcen erschöpfen und alle anderen Container auf demselben Host zum Absturz bringen.
Kann ich Docker innerhalb eines Docker-Containers ausführen (Docker-in-Docker)?
Ja, aber es wird für den Produktionseinsatz dringend abgeraten. Das gängige Muster für CI-Pipelines besteht darin, den Host-Docker-Socket (`-v /var/run/docker.sock:/var/run/docker.sock`) in den CI-Container einzubinden, was dem Container vollständige Kontrolle über den Docker-Daemon des Hosts gibt — ein erhebliches Sicherheitsrisiko. Eine sicherere Alternative ist die Verwendung des `–allow security.insecure`-Flags von BuildKit oder speziell entwickelter Tools wie Kaniko oder Buildah, die OCI-Images ohne einen Docker-Daemon erstellen.
