Dev Containers: devcontainer.json als reproduzierbare Entwicklungsumgebung

Worum es geht

Die Development Container Specification beschreibt sich selbst als offene Spezifikation, um Container mit entwicklungsspezifischen Inhalten und Einstellungen anzureichern. Die Metadaten liegen in .devcontainer/devcontainer.json: ein image oder build.dockerfile (oder dockerComposeFile für Aufbauten mit mehreren Diensten), features (wiederverwendbare Installationsschritte wie eine Sprach-Toolchain oder ein CLI, referenziert über einen Registry-Pfad), forwardPorts, containerEnv und remoteEnv, remoteUser, customizations für editorspezifische Einstellungen sowie Lifecycle-Befehle. Die Referenz dokumentiert deren Reihenfolge: initializeCommand läuft auf dem Host; innerhalb des Containers schliessen onCreateCommand, updateContentCommand und postCreateCommand die Einrichtung ab, wenn der Container erstellt wird; postStartCommand läuft bei jedem Start und postAttachCommand, sobald ein Werkzeug andockt. GitHubs Dokumentation bezeichnet devcontainer.json als die Hauptdatei einer Codespaces-Konfiguration, und die Referenz merkt an, dass Cloud-Dienste die Befehle zum Erstellungszeitpunkt beim Zwischenspeichern oder Vorabbauen eines Containers ausführen können, weshalb diese Befehle typischerweise keinen Zugriff auf nutzerbezogene Secrets haben.

Warum es wichtig ist

„Läuft bei mir“ ist meist ein Problem der Toolchain-Version. Ein Dev Container fixiert Betriebssystem, Laufzeitumgebung und CLI-Werkzeuge in einer Datei, die mit dem Code versioniert wird; eine neu hinzukommende Person, ein gehosteter Workspace und ein Coding-Agent starten alle vom selben Image aus, statt von dem, was der jeweilige Host zufällig bereithält. Da die CI dasselbe Image ausführen kann, driften lokale Umgebung und Pipeline nicht mehr auseinander.

So wird es angewendet

• Von einem bereits vertrauten Dockerfile ausgehen (wo sinnvoll das Produktions-Basisimage) statt von einem grossen Alles-in-einem-Image; Werkzeuge über Features hinzufügen, damit die Liste lesbar bleibt.
• Die Installation von Abhängigkeiten in postCreateCommand legen und günstige, bei jedem Start anfallende Arbeit (einen lokalen Dienst starten, die Portliste ausgeben) in postStartCommand; Befehle zum Erstellungszeitpunkt idempotent halten, da Prebuilds sie vorab ausführen können.
• Nur die Ports weiterleiten, die die Anwendung braucht, und remoteUser auf ein Konto ohne Root-Rechte setzen, damit im bind-gemounteten Workspace erstellte Dateien vernünftige Eigentumsrechte haben.
• customizations minimal halten: den Formatter, empfohlene Erweiterungen, nichts Persönliches.
• Den Container in der CI regelmässig von Grund auf neu bauen, um Drift beim Basisimage zu erkennen und zu belegen, dass die Konfiguration noch baut.

Stolpersteine

Ein Dev Container ersetzt keine Lock-Datei: Das Image fixiert die Toolchain, nicht die Abhängigkeiten des Projekts. Ist der Bind-Mount des Workspace langsam (häufig berichtet für Docker Desktop unter macOS und Windows bei grossen Verzeichnisbäumen), überschreibt die Eigenschaft workspaceMount der Referenz den Standard-Mount, etwa mit einem benannten Volume. Secrets dürfen nicht ins Image oder in containerEnv eingebacken werden; sie sollten beim Andocken bereitgestellt werden. Docker-in-Docker innerhalb des Containers ist ein Feature mit eigenen Abwägungen, kein Standard.