15%

15% auf alle Hosting-Dienste sparen

Teste deine Fähigkeiten und erhalte Rabatt auf jeden Hosting-Plan

Benutze den Code:

Skills
Anfangen
08.10.2024

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:

PaketRolle
`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:

TreiberAnwendungsfall
`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:

MerkmalBenanntes VolumeBind Mount
Von Docker verwaltetJaNein
Host-Pfad erforderlichNeinJa
Portabel zwischen HostsJa (mit Volume-Treibern)Nein
Am besten geeignet fürDatenbankdaten, AnwendungszustandEntwicklungscode, 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

MerkmalDocker EnginePodmanLXC/LXDcontainerd (standalone)
Daemon-ArchitekturZentralisierter DaemonDaemonlosDaemon-basiertDaemon-basiert
Rootless-UnterstützungJa (v20+)NativEingeschränktJa
Docker Compose-UnterstützungNativÜber `podman-compose`NeinNein
OCI-KonformitätJaJaNein (LXC-Format)Ja
Kubernetes-IntegrationÜber CRI-dockerd-ShimNatives CRINeinNatives CRI
Windows/macOS-UnterstützungDocker DesktopEingeschränktNeinNein
Am besten geeignet fürAllgemeine Entwicklung und ProduktionSicherheitsorientiert, rootlessSystem-Container, VMsKubernetes-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.

15%

15% auf alle Hosting-Dienste sparen

Teste deine Fähigkeiten und erhalte Rabatt auf jeden Hosting-Plan

Benutze den Code:

Skills
Anfangen