Lokale Entwicklung

Diese Seite richtet sich an Entwickler, die das Repository klonen, das Image lokal bauen oder das Dockerfile anpassen möchten. Wenn Sie lediglich den vorgefertigten Container verwenden möchten, siehe Erste Schritte.

Repository klonen

git clone https://github.com/f5-sales-demo/devcontainer.git
cd devcontainer

Projektstruktur

.
├── Dockerfile                  # Multi-Stage Image-Build
├── docker-compose.yml          # Basis-Compose — bezieht vorgefertigtes Image
├── docker-compose.build.yml    # Build-Override — explizit mit -f verwenden
├── .devcontainer/              # VS Code Dev Container Konfiguration
│   └── devcontainer.json
├── entrypoint.sh               # Container-Startskript
├── .env.example                # Beispiel-Umgebungsvariablen
├── docs/                       # Dokumentationsseite (Starlight)
├── claude-config/              # Claude Code Konfigurationsdateien
├── codex-config/               # Codex-Konfiguration
├── pi-config/                  # Pi-Konfiguration
└── omp-config/                 # Oh-My-Pi (omp) Konfiguration

Build-Datei

Die Datei docker-compose.build.yml fügt lokale Build-Unterstützung hinzu. Sie wird nicht automatisch zusammengeführt — Sie müssen sie explizit mit -f-Flags angeben. Das bedeutet, docker compose up -d (oder podman-compose up -d) bezieht immer das vorgefertigte Image von GHCR, unabhängig davon, ob Sie das Repository geklont haben oder nicht.

Docker

Sie können überprüfen, dass ein einfaches docker compose up nur das vorgefertigte Image verwendet (kein build:-Kontext):

docker compose config

Vergleichen Sie mit der expliziten Build-Konfiguration:

docker compose -f docker-compose.yml -f docker-compose.build.yml config

Podman

Sie können überprüfen, dass ein einfaches podman-compose up nur das vorgefertigte Image verwendet (kein build:-Kontext):

podman-compose config

Vergleichen Sie mit der expliziten Build-Konfiguration:

podman-compose -f docker-compose.yml -f docker-compose.build.yml config

Lokal bauen

Docker

docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Podman

podman-compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Dies führt die Build-Datei mit der Basis-Compose-Datei zusammen, baut das Image aus dem lokalen Dockerfile und startet den Container. Das --build-Flag erzwingt einen Neubau, auch wenn ein zwischengespeichertes Image existiert.

Zweistufige Build-Architektur

Das Dockerfile verwendet einen zweistufigen Build, der für Docker-Layer-Caching optimiert ist:

Stufe 1: deps (stabile Grundlagen, ~4,5 GB)

Diese Layer werden nur neu gebaut, wenn ein Versions-ARG aktualisiert wird oder sich APT-Pakete ändern. Bei typischen Änderungen an Tools überspringt BuildKit diese gesamte Stufe.

Abschnitt	Inhalt
1. APT-Repos	NodeSource, deadsnakes, HashiCorp, GitHub, Docker, Microsoft, Google Cloud, Dart SDK
2. APT-Pakete	Systemwerkzeuge, Node.js, Python, Java, Terraform, GitHub CLI, Docker Engine, Azure CLI, PowerShell, Locales
2b. Sicherheits-APT-Pakete	Netzwerkanalyse, Web-Scanner, Passwort-Tools, Reverse Engineering, Forensik (~80 Pakete)
3. Python-Bootstrap	Symlinks + pip über get-pip.py
4. Go	Offizieller Tarball (neueste stabile Version, zur Build-Zeit aufgelöst)
5. Rust	rustup (systemweit, neueste stabile Version)
6. Maven + Gradle	Binäre Downloads nach /opt
7. VNC-Stack	Xvfb, x11vnc, noVNC, fluxbox — Remote-Anzeige über Browser
8. Nerd Fonts	JetBrainsMono, Hack, FiraCode (neueste Releases)

Stufe 2: final (veränderliche Tools + Benutzereinrichtung, ~1,5 GB)

Diese Layer ändern sich häufiger (npm/pip-Updates, Konfigurationsänderungen), werden aber schnell neu gebaut, da die umfangreiche deps-Stufe zwischengespeichert ist.

Abschnitt	Inhalt
9. AWS CLI v2	Offizieller Installer
10. Binäre Tools	kubectl, helm, tflint, terraform-docs, act, actionlint, yt-dlp, uv
10b. Zusätzliche Binärdateien	VS Code CLI, oc, yq, terragrunt, ibmcloud, fzf, hadolint, codex
10c. Super-Linter-Binärdateien	shfmt, gitleaks, editorconfig-checker, trivy, clj-kondo, dotenv-linter, golangci-lint, goreleaser, kubeconform, protolint, scalafmt, ktlint
10d. Java-JAR-Tools	checkstyle, google-java-format (Wrapper-Skripte)
10e. PHP-Linter	phpcs, phpstan, psalm (PHAR-Downloads)
10f. PowerShell-Module	PSScriptAnalyzer, arm-ttk
10g. Sicherheits-Binärdateien	nuclei, subfinder, httpx, ffuf, gobuster, feroxbuster, dalfox, amass, trufflehog, grype, syft, bettercap (amd64)
10h. OWASP ZAP	Java-basierter Webanwendungs-Scanner
10i. Ghidra	Reverse-Engineering-Framework
10j. Metasploit	Exploitation-Framework (nur amd64)
11. Globale npm-Tools	claude-code, prettier, markdownlint-cli2, devcontainers-cli, playwright, pi-coding-agent, oh-my-pi
12. pip-Tools	pre-commit, ansible, black, pylint, yamllint, playwright
12c. Ruby-Linter	rubocop + Erweiterungen
12e. Perl-Linter-Module	Perl::Critic-Erweiterungen
12f. Lua-Linter	luacheck
12g. R-Linter	lintr
12h. Sicherheits-Ruby-Gems	wpscan, evil-winrm
12i. Git-geklonte Sicherheitstools	testssl.sh, exploitdb (searchsploit), SecLists, docker-bench-security, recon-ng, spiderfoot
13. Playwright-Browser	Chromium + Systemabhängigkeiten über playwright install --with-deps
13b. Chrome DevTools MCP	Chrome-Symlink + MCP-Pre-Cache + Headless-Patch
14. Homebrew	Linuxbrew (KI-Assistenten-Abhängigkeiten + Formatierer)
15. ZSH-Plugins	oh-my-zsh benutzerdefinierte Plugins
16. Shell-Bootstrap	npm-global, tfenv, compinit
17. Claude Code + Codex-Konfiguration	Tool-Awareness-Speicher, verwaltete Richtlinie, Selbsttest-Skript, Codex-Konfiguration
18. Entrypoint	Container-Startskript (absolut letztes COPY)

Tools hinzufügen

Bearbeiten Sie das Dockerfile und fügen Sie Ihr Tool dem entsprechenden Abschnitt hinzu. Bauen Sie nach dem Hinzufügen neu:

Docker

docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Podman

podman-compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Oder in VS Code: Dev Containers → Container neu erstellen.

APT-Pakete

Fügen Sie zum apt-get install-Block in Abschnitt 2 hinzu:

RUN apt-get update && apt-get install -y --no-install-recommends \
    your-package-here \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

npm-Tools

Fügen Sie zum npm install -g-Block in Abschnitt 11 hinzu:

RUN npm install -g \
    your-npm-tool

pip-Tools

Fügen Sie zum pip install-Block in Abschnitt 12 hinzu:

RUN pip install --no-cache-dir --break-system-packages \
    your-python-tool

Binäre Downloads

Fügen Sie zu Abschnitt 10 hinzu oder erstellen Sie einen neuen RUN-Layer mit Architekturerkennung:

RUN ARCH=$(dpkg --print-architecture) \
    && curl -fsSL "https://example.com/tool-linux-${ARCH}.tar.gz" \
       | tar -xz -C /usr/local/bin tool

Build-Cache

CI verwendet Registry-basiertes Caching — Build-Layer werden in GHCR (ghcr.io/f5-sales-demo/devcontainer:cache-*) gespeichert, anstatt im GitHub Actions Cache. Dies vermeidet das 10 GB GHA-Cache-Limit, das bei diesem ~6 GB großen Multi-Architektur-Image häufige vollständige Neubauten verursachte.

Die zweistufige Architektur funktioniert mit dem Registry-Cache folgendermaßen:

• Tool-Versionserhöhungen (npm, pip, binäre Tools) — nur die final-Stufe wird neu gebaut (~5 Min.)
• Konfigurationsdatei-Änderungen (claude-config/, entrypoint.sh) — nur die letzten Layer werden neu gebaut (~1 Min.)
• Grundlagen-Änderungen (APT-Pakete, Go/Rust/Java-Versionen) — vollständiger Neubau beider Stufen (~30 Min.)