การพัฒนาในเครื่อง

หน้านี้สำหรับนักพัฒนาที่ต้องการโคลนรีโพซิทอรี บิลด์ image ในเครื่อง หรือปรับแต่ง Dockerfile หากคุณต้องการใช้คอนเทนเนอร์ที่บิลด์ไว้แล้วเท่านั้น ดูที่ เริ่มต้นใช้งาน

โคลนรีโพซิทอรี

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

โครงสร้างโปรเจกต์

.
├── 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

ไฟล์บิลด์

ไฟล์ docker-compose.build.yml เพิ่มการรองรับการบิลด์ในเครื่อง ไฟล์นี้ไม่ถูกรวมอัตโนมัติ — คุณต้องระบุอย่างชัดเจนด้วยแฟล็ก -f ซึ่งหมายความว่า docker compose up -d (หรือ podman-compose up -d) จะดึง image ที่บิลด์ไว้แล้วจาก GHCR เสมอ ไม่ว่าคุณจะโคลนรีโพหรือไม่ก็ตาม

Docker

คุณสามารถตรวจสอบว่าคำสั่ง docker compose up ธรรมดาใช้เฉพาะ image ที่บิลด์ไว้แล้วเท่านั้น (ไม่มี build: context):

docker compose config

เปรียบเทียบกับการกำหนดค่าบิลด์แบบระบุชัดเจน:

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

Podman

คุณสามารถตรวจสอบว่าคำสั่ง podman-compose up ธรรมดาใช้เฉพาะ image ที่บิลด์ไว้แล้วเท่านั้น (ไม่มี build: context):

podman-compose config

เปรียบเทียบกับการกำหนดค่าบิลด์แบบระบุชัดเจน:

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

การบิลด์ในเครื่อง

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

คำสั่งนี้จะรวมไฟล์บิลด์เข้ากับไฟล์ compose หลัก บิลด์ image จาก Dockerfile ในเครื่อง และเริ่มต้นคอนเทนเนอร์ แฟล็ก --build บังคับให้บิลด์ใหม่แม้ว่าจะมี image ที่แคชไว้อยู่แล้ว

สถาปัตยกรรมบิลด์แบบสองขั้นตอน

Dockerfile ใช้การบิลด์แบบสองขั้นตอนที่ปรับให้เหมาะสมกับ Docker layer caching:

ขั้นตอนที่ 1: deps (รากฐานที่เสถียร, ~4.5 GB)

เลเยอร์เหล่านี้จะบิลด์ใหม่เฉพาะเมื่อมีการเปลี่ยนเวอร์ชัน ARG หรือแพ็กเกจ APT เปลี่ยนแปลงเท่านั้น เมื่อมีการเปลี่ยนแปลงเครื่องมือทั่วไป BuildKit จะข้ามขั้นตอนนี้ทั้งหมด

ส่วน	เนื้อหา
1. APT repos	NodeSource, deadsnakes, HashiCorp, GitHub, Docker, Microsoft, Google Cloud, Dart SDK
2. APT packages	เครื่องมือระบบ, Node.js, Python, Java, Terraform, GitHub CLI, Docker engine, Azure CLI, PowerShell, locales
2b. Security APT packages	การวิเคราะห์เครือข่าย, เว็บสแกนเนอร์, เครื่องมือรหัสผ่าน, วิศวกรรมย้อนกลับ, นิติวิทยาศาสตร์ดิจิทัล (~80 แพ็กเกจ)
3. Python bootstrap	Symlinks + pip ผ่าน get-pip.py
4. Go	Official tarball (เวอร์ชันเสถียรล่าสุด, ระบุตอนบิลด์)
5. Rust	rustup (ทั้งระบบ, เวอร์ชันเสถียรล่าสุด)
6. Maven + Gradle	ดาวน์โหลดไบนารีไปที่ /opt
7. VNC stack	Xvfb, x11vnc, noVNC, fluxbox — แสดงผลระยะไกลผ่านเบราว์เซอร์
8. Nerd Fonts	JetBrainsMono, Hack, FiraCode (รุ่นล่าสุด)

ขั้นตอนที่ 2: final (เครื่องมือที่เปลี่ยนบ่อย + การตั้งค่าผู้ใช้, ~1.5 GB)

เลเยอร์เหล่านี้เปลี่ยนแปลงบ่อยกว่า (อัปเดต npm/pip, เปลี่ยนแปลงการกำหนดค่า) แต่บิลด์ใหม่ได้รวดเร็วเพราะขั้นตอน deps ที่หนักถูกแคชไว้แล้ว

ส่วน	เนื้อหา
9. AWS CLI v2	ตัวติดตั้งอย่างเป็นทางการ
10. Binary tools	kubectl, helm, tflint, terraform-docs, act, actionlint, yt-dlp, uv
10b. Additional binaries	VS Code CLI, oc, yq, terragrunt, ibmcloud, fzf, hadolint, codex
10c. Super-linter binaries	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 scripts)
10e. PHP linters	phpcs, phpstan, psalm (PHAR downloads)
10f. PowerShell modules	PSScriptAnalyzer, arm-ttk
10g. Security binaries	nuclei, subfinder, httpx, ffuf, gobuster, feroxbuster, dalfox, amass, trufflehog, grype, syft, bettercap (amd64)
10h. OWASP ZAP	เว็บแอปพลิเคชันสแกนเนอร์ที่ใช้ Java
10i. Ghidra	เฟรมเวิร์กวิศวกรรมย้อนกลับ
10j. Metasploit	เฟรมเวิร์กการโจมตี (amd64 เท่านั้น)
11. npm global 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 linters	rubocop + ส่วนขยาย
12e. Perl linter modules	ส่วนขยาย Perl::Critic
12f. Lua linter	luacheck
12g. R linter	lintr
12h. Security Ruby gems	wpscan, evil-winrm
12i. Git-cloned security tools	testssl.sh, exploitdb (searchsploit), SecLists, docker-bench-security, recon-ng, spiderfoot
13. Playwright browsers	Chromium + system deps ผ่าน playwright install --with-deps
13b. Chrome DevTools MCP	Chrome symlink + MCP pre-cache + headless patch
14. Homebrew	Linuxbrew (AI assistant deps + formatters)
15. ZSH plugins	oh-my-zsh custom plugins
16. Shell bootstrap	npm-global, tfenv, compinit
17. Claude Code + Codex config	Tool awareness memory, managed policy, self-test script, Codex config
18. Entrypoint	สคริปต์เริ่มต้นคอนเทนเนอร์ (COPY ลำดับสุดท้าย)

การเพิ่มเครื่องมือ

แก้ไข Dockerfile และเพิ่มเครื่องมือของคุณในส่วนที่เหมาะสม บิลด์ใหม่หลังจากเพิ่มเสร็จ:

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

หรือใน VS Code: Dev Containers → Rebuild Container

แพ็กเกจ APT

เพิ่มในบล็อก apt-get install ส่วนที่ 2:

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

เครื่องมือ npm

เพิ่มในบล็อก npm install -g ส่วนที่ 11:

RUN npm install -g \
    your-npm-tool

เครื่องมือ pip

เพิ่มในบล็อก pip install ส่วนที่ 12:

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

การดาวน์โหลดไบนารี

เพิ่มในส่วนที่ 10 หรือสร้างเลเยอร์ RUN ใหม่พร้อมการตรวจจับสถาปัตยกรรม:

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

แคชการบิลด์

CI ใช้ registry-based caching — เลเยอร์การบิลด์ถูกเก็บใน GHCR (ghcr.io/f5-sales-demo/devcontainer:cache-*) แทนที่จะเป็นแคชของ GitHub Actions ซึ่งช่วยหลีกเลี่ยงขีดจำกัดแคช GHA 10 GB ที่ทำให้เกิดการบิลด์ใหม่ทั้งหมดบ่อยครั้งสำหรับ image แบบ multi-architecture ขนาด ~6 GB นี้

สถาปัตยกรรมแบบสองขั้นตอนทำงานร่วมกับ registry cache ดังนี้:

• การอัปเดตเวอร์ชันเครื่องมือ (npm, pip, binary tools) — บิลด์ใหม่เฉพาะขั้นตอน final (~5 นาที)
• การเปลี่ยนแปลงไฟล์กำหนดค่า (claude-config/, entrypoint.sh) — บิลด์ใหม่เฉพาะเลเยอร์สุดท้ายไม่กี่เลเยอร์ (~1 นาที)
• การเปลี่ยนแปลงรากฐาน (แพ็กเกจ APT, เวอร์ชัน Go/Rust/Java) — บิลด์ใหม่ทั้งหมดทั้งสองขั้นตอน (~30 นาที)