Setup

Dieser Abschnitt erläutert, welche Schritte notwendig sind, um das Referenzprojekt oder darauf aufbauende Projekte aufzusetzen.

Für die Lauffähigkeit des Referenzprojekts sind die in dieser Guideline beschriebenen Maßnahmen (wie z.B. Projekt- und Konfigurationsstruktur) nicht zwingend erforderlich.

Die SSH- und Git-Mounts sind entsprechend in der compose.yml des Referenzprojekts auskommentiert.

Die Dateien unter .devcontainer/secrets/ enthalten lokale Konfiguration und werden nicht ins Repository eingecheckt. Stattdessen liegen im Repo nur .example-Vorlagen, die beim ersten Setup einmalig kopiert und mit den eigenen Werten befüllt werden müssen:

cp .devcontainer/secrets/github_auth_token.example .devcontainer/secrets/github_auth_token
cp .devcontainer/secrets/.env.app.example .devcontainer/secrets/.env.app

Die echten Secret-Dateien sind über .gitignore von der Versionskontrolle ausgeschlossen.

Einige Verzeichnisse im Projekt werden zur Laufzeit als Named Volumes in die Container gemountet — etwa node_modules für Dependencies oder .next und .turbo für Build-Caches. Diese Verzeichnisse sind über .gitignore von der Versionskontrolle ausgeschlossen und existieren auf einem frisch geklonten Projekt zunächst nicht.

Docker erwartet die Mount-Pfade jedoch bereits beim Container-Start. Existieren sie nicht, bricht der Start mit einem Fehler ab.

Daher müssen die entsprechenden Verzeichnisse einmalig leer auf dem Host-System angelegt werden:

mkdir -p node_modules .vscode .idea
# bei Bedarf zusätzlich z.B.:
# mkdir -p .next .turbo

Das gilt für alle Pfade, die in der compose.yml als Named Volume gemountet werden, beispielsweise:

- root_node_modules:/workspaces/security-oriented-dev-container-project/node_modules
- turbo_cache:/workspaces/security-oriented-dev-container-project/.turbo
- next_cache:/workspaces/security-oriented-dev-container-project/.next

Die Verzeichnisse bleiben nach dem Anlegen leer — befüllt werden sie erst durch die jeweiligen Container (z. B. node_modules durch den deps-Container im nächsten Schritt).

Bei einem neu aufgesetzten Projekt existiert in der Regel noch kein Lockfile (z.B. package-lock.json). Ohne Lockfile kann der reguläre deps-Container nicht arbeiten, da dieser deterministisch aus dem Lockfile installiert (npm ci) und den Workspace nur lesend einbindet.

Stattdessen wird einmalig der deps-update-Container ausgeführt. Dieser arbeitet bewusst mit schreibbarem Workspace und darf sowohl das Lockfile auf dem Host-System erzeugen als auch die node_modules im zugehörigen Named Volume installieren:

docker compose -f .devcontainer/compose.yml run --rm deps-update