コンテンツにスキップ
開発コンテナ

ローカル開発

このページは、リポジトリをクローンし、イメージをローカルでビルドしたり、Dockerfileをカスタマイズしたい開発者向けです。ビルド済みコンテナを使用するだけの場合は、はじめにを参照してください。

リポジトリのクローン

Section titled “リポジトリのクローン”
Terminal window
git clone https://github.com/f5-sales-demo/devcontainer.git
cd devcontainer

プロジェクト構造

Section titled “プロジェクト構造”
.
├── Dockerfile                  # Multi-stage image build
├── docker-compose.yml          # Base compose — pulls pre-built image
├── docker-compose.build.yml    # Build override — use explicitly with -f
├── .devcontainer/              # VS Code Dev Container config
│   └── devcontainer.json
├── entrypoint.sh               # Container startup script
├── .env.example                # Example environment variables
├── docs/                       # Documentation site (Starlight)
├── claude-config/              # Claude Code configuration files
├── codex-config/               # Codex configuration
├── pi-config/                  # Pi configuration
└── omp-config/                 # Oh-My-Pi (omp) configuration

ビルドファイル

Section titled “ビルドファイル”

docker-compose.build.yml ファイルはローカルビルドサポートを追加します。これは自動マージされません — -f フラグで明示的に渡す必要があります。つまり、docker compose up -d（または podman-compose up -d）は、リポジトリをクローンしたかどうかに関わらず、常にGHCRからビルド済みイメージをプルします。

プレーンな docker compose up がビルド済みイメージのみを使用する（build: コンテキストなし）ことを確認できます：

Terminal window
docker compose config

明示的なビルド設定と比較してください：

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

ローカルビルド

Section titled “ローカルビルド”
Terminal window
docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

これにより、ビルドファイルがベースのcomposeファイルとマージされ、ローカルの Dockerfile からイメージがビルドされ、コンテナが起動します。--build フラグは、キャッシュされたイメージが存在する場合でも強制的にリビルドします。

2ステージビルドアーキテクチャ

Section titled “2ステージビルドアーキテクチャ”

DockerfileはDockerレイヤーキャッシュに最適化された2ステージビルドを使用します：

ステージ 1: deps（安定した基盤、約4.5 GB）

Section titled “ステージ 1: deps（安定した基盤、約4.5 GB）”

これらのレイヤーは、バージョンARGが更新されるかAPTパッケージが変更された場合にのみリビルドされます。一般的なツールのみの変更では、BuildKitはこのステージ全体をスキップします。

セクション内容
1. APTリポジトリNodeSource、deadsnakes、HashiCorp、GitHub、Docker、Microsoft、Google Cloud、Dart SDK
2. APTパッケージシステムツール、Node.js、Python、Java、Terraform、GitHub CLI、Dockerエンジン、Azure CLI、PowerShell、ロケール
2b. セキュリティAPTパッケージネットワーク分析、Webスキャナー、パスワードツール、リバースエンジニアリング、フォレンジック（約80パッケージ）
3. Pythonブートストラップシンボリックリンク + get-pip.pyによるpip
4. Go公式tarball（ビルド時に解決される最新安定版）
5. Rustrustup（システム全体、最新安定版）
6. Maven + Gradle/opt へのバイナリダウンロード
7. VNCスタックXvfb、x11vnc、noVNC、fluxbox — ブラウザ経由のリモートディスプレイ
8. NerdフォントJetBrainsMono、Hack、FiraCode（最新リリース）

ステージ 2: final（頻繁に変更されるツール + ユーザー設定、約1.5 GB）

Section titled “ステージ 2: final（頻繁に変更されるツール + ユーザー設定、約1.5 GB）”

これらのレイヤーはより頻繁に変更されますが（npm/pipの更新、設定変更）、重い deps ステージがキャッシュされているため、素早くリビルドできます。

セクション内容
9. AWS CLI v2公式インストーラー
10. バイナリツールkubectl、helm、tflint、terraform-docs、act、actionlint、yt-dlp、uv
10b. 追加バイナリVS Code CLI、oc、yq、terragrunt、ibmcloud、fzf、hadolint、codex
10c. Super-linterバイナリshfmt、gitleaks、editorconfig-checker、trivy、clj-kondo、dotenv-linter、golangci-lint、goreleaser、kubeconform、protolint、scalafmt、ktlint
10d. Java JARツールcheckstyle、google-java-format（ラッパースクリプト）
10e. PHPリンターphpcs、phpstan、psalm（PHARダウンロード）
10f. PowerShellモジュールPSScriptAnalyzer、arm-ttk
10g. セキュリティバイナリnuclei、subfinder、httpx、ffuf、gobuster、feroxbuster、dalfox、amass、trufflehog、grype、syft、bettercap（amd64）
10h. OWASP ZAPJavaベースのウェブアプリケーションスキャナー
10i. Ghidraリバースエンジニアリングフレームワーク
10j. Metasploitエクスプロイトフレームワーク（amd64のみ）
11. npmグローバルツールclaude-code、prettier、markdownlint-cli2、devcontainers-cli、playwright、pi-coding-agent、oh-my-pi
12. pipツールpre-commit、ansible、black、pylint、yamllint、playwright
12c. Rubyリンターrubocop + 拡張機能
12e. PerlリンターモジュールPerl::Critic拡張機能
12f. Luaリンターluacheck
12g. Rリンターlintr
12h. セキュリティRuby gemswpscan、evil-winrm
12i. Gitクローンされたセキュリティツールtestssl.sh、exploitdb（searchsploit）、SecLists、docker-bench-security、recon-ng、spiderfoot
13. PlaywrightブラウザChromium + playwright install --with-deps によるシステム依存関係
13b. Chrome DevTools MCPChromeシンボリックリンク + MCPプリキャッシュ + ヘッドレスパッチ
14. HomebrewLinuxbrew（AIアシスタント依存関係 + フォーマッター）
15. ZSHプラグインoh-my-zshカスタムプラグイン
16. シェルブートストラップnpm-global、tfenv、compinit
17. Claude Code + Codex設定ツール認識メモリ、管理ポリシー、セルフテストスクリプト、Codex設定
18. エントリポイントコンテナ起動スクリプト（最後のCOPY）

ツールの追加

Section titled “ツールの追加”

Dockerfile を編集し、適切なセクションにツールを追加します。追加後にリビルドしてください：

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

またはVS Codeで：Dev Containers → Rebuild Container。

APTパッケージ

Section titled “APTパッケージ”

セクション2の apt-get install ブロックに追加します：

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

npmツール

Section titled “npmツール”

セクション11の npm install -g ブロックに追加します：

RUN npm install -g \
    your-npm-tool

pipツール

Section titled “pipツール”

セクション12の pip install ブロックに追加します：

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

バイナリダウンロード

Section titled “バイナリダウンロード”

セクション10に追加するか、アーキテクチャ検出を含む新しい RUN レイヤーを作成します：

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

ビルドキャッシュ

Section titled “ビルドキャッシュ”

CIはレジストリベースのキャッシュを使用します — ビルドレイヤーはGitHub Actionsキャッシュではなく、GHCR（ghcr.io/f5-sales-demo/devcontainer:cache-*）に保存されます。これにより、この約6 GBのマルチアーキテクチャイメージで頻繁なフルリビルドを引き起こしていた10 GBのGHAキャッシュ制限を回避できます。

2ステージアーキテクチャはレジストリキャッシュと連携して以下のように動作します：

  • ツールバージョンの更新（npm、pip、バイナリツール）— final ステージのみリビルド（約5分）
  • 設定ファイルの変更（claude-config/、entrypoint.sh）— 最後の数レイヤーのみリビルド（約1分）
  • 基盤の変更（APTパッケージ、Go/Rust/Javaバージョン）— 両ステージのフルリビルド（約30分）