Architekturansätze

Development Container können auf verschiedene Arten mit unterschiedlichen Ansätzen aufgebaut sein.

In diesem Absatz werden gängige Architekturansätze verglichen, um darauf aufbauend die bevorzugte Architektur für die Entwicklungsumgebung dieser Guideline näher zu erläutern.

Development Container + Service Container

Bei diesem Ansatz wird die Entwicklungsumgebung über Docker Compose als Multi-Container-Umgebung betrieben.

Der Dev Container¹ ist ein normaler Container innerhalb des Compose-Projekts und hat keinen Zugriff auf den Docker-Daemon (/var/run/docker.sock).

Sicherheit: hoch

Kein Zugriff auf den Docker-Daemon → keine impliziten Host-Rechte
Klare Trennung zwischen Entwicklungsumgebung und Orchestrierung
Geringe Angriffsfläche bei kompromittiertem Dev Container

Komfort: hoch

Sehr gut geeignet für Web-Stacks
Nahtlose Integration in VS Code Dev Container

Development Container + Docker outside of Docker

Der Dev Container¹ erhält Zugriff auf den Host-Docker-Daemon, typischerweise über /var/run/docker.sock.

Kann eingesetzt werden, wenn Container-Steuerung aus dem Dev Container wirklich erforderlich ist.

Sicherheit: niedrig bis mittel

Zugriff auf den Docker-Daemon entspricht faktisch Host-Kontrolle
Besonders kritisch, wenn zusätzlich Secrets (SSH, Git, Tokens) im Container liegen
Großer Angriffsvektor bei kompromittierter Entwicklungsumgebung

Komfort: sehr hoch

Direkter Zugriff auf Docker-CLI

Docker in Docker (DinD) im Development Container

Im Dev Container¹ läuft ein eigener Docker-Daemon.

Für klassische Webentwicklung meist nicht sinnvoll.

Sicherheit: mittel

Bessere Trennung vom Host-System als Socket-Mount
In der Praxis oft --privileged erforderlich → reduziert Sicherheitsgewinn
Komplexere Storage- und Netzwerk-Implikationen

Komfort: mittel

Funktioniert für spezielle Use Cases
Höherer Ressourcenverbrauch

Development Container auf Remote-Host per SSH

Der Dev Container¹ läuft auf einer separaten Maschine (VM/Server). Zugriff erfolgt über VS Code Remote-SSH.

Sicherheit: sehr hoch

Starke Trennung vom lokalen Host-System
Kompromittierung betrifft primär die Remote-Maschine
Besonders geeignet für untrusted Tooling (z.B. AI-Agenten)

Komfort: mittel bis hoch

Zusätzlicher Infrastrukturaufwand (VM, Backups, SSH)
Mögliche Latenzen bei Dateisystem/Netzwerk

Rootless Docker / Rootless Podman als Unterbau

Kein eigener Architekturansatz, sondern eine Härtung.

Gute Ergänzung, aber kein Ersatz für eine saubere Architektur.

Sicherheit: besser als klassischer rootful Docker

Daemon und Container laufen ohne Root-Rechte
Reduziert Auswirkungen möglicher Sicherheitslücken