- الرئيسية
- حاوية التطوير
- التطوير المحلي
التطوير المحلي
هذه الصفحة مخصصة للمطورين الذين يرغبون في استنساخ المستودع أو بناء الصورة محلياً أو تخصيص ملف Dockerfile. إذا كنت ترغب فقط في استخدام الحاوية المُنشأة مسبقاً، راجع البدء.
استنساخ المستودع
Section titled “استنساخ المستودع”git clone https://github.com/f5-sales-demo/devcontainer.gitcd 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:):
docker compose configقارن مع تكوين البناء الصريح:
docker compose -f docker-compose.yml -f docker-compose.build.yml configيمكنك التحقق من أن أمر podman-compose up العادي يستخدم فقط الصورة المُنشأة مسبقاً (بدون سياق build:):
podman-compose configقارن مع تكوين البناء الصريح:
podman-compose -f docker-compose.yml -f docker-compose.build.yml configالبناء محلياً
Section titled “البناء محلياً”docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --buildpodman-compose -f docker-compose.yml -f docker-compose.build.yml up -d --buildيقوم هذا بدمج ملف البناء مع ملف compose الأساسي، ويبني الصورة من ملف Dockerfile المحلي، ويشغّل الحاوية. تفرض علامة --build إعادة البناء حتى لو كانت هناك صورة مخزنة مؤقتاً.
بنية البناء ذات المرحلتين
Section titled “بنية البناء ذات المرحلتين”يستخدم ملف Dockerfile بناءً من مرحلتين مُحسّناً للتخزين المؤقت لطبقات Docker:
المرحلة 1: deps (الأسس المستقرة، ~4.5 جيجابايت)
Section titled “المرحلة 1: deps (الأسس المستقرة، ~4.5 جيجابايت)”تُعاد بناء هذه الطبقات فقط عند تحديث إصدار 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، الإعدادات المحلية |
| 2ب. حزم APT الأمنية | تحليل الشبكات، ماسحات الويب، أدوات كلمات المرور، الهندسة العكسية، الطب الشرعي الرقمي (~80 حزمة) |
| 3. تهيئة Python | الروابط الرمزية + pip عبر get-pip.py |
| 4. Go | أرشيف رسمي (أحدث إصدار مستقر، يُحدد وقت البناء) |
| 5. Rust | rustup (على مستوى النظام، أحدث إصدار مستقر) |
| 6. Maven + Gradle | تنزيلات ثنائية إلى /opt |
| 7. حزمة VNC | Xvfb، x11vnc، noVNC، fluxbox — عرض عن بُعد عبر المتصفح |
| 8. خطوط Nerd | JetBrainsMono، Hack، FiraCode (أحدث الإصدارات) |
المرحلة 2: final (الأدوات المتغيرة + إعداد المستخدم، ~1.5 جيجابايت)
Section titled “المرحلة 2: final (الأدوات المتغيرة + إعداد المستخدم، ~1.5 جيجابايت)”تتغير هذه الطبقات بشكل أكثر تكراراً (تحديثات npm/pip، تغييرات التكوين) لكنها تُعاد بناؤها بسرعة لأن مرحلة deps الثقيلة مخزنة مؤقتاً.
| القسم | المحتويات |
|---|---|
| 9. AWS CLI v2 | المُثبّت الرسمي |
| 10. أدوات ثنائية | kubectl، helm، tflint، terraform-docs، act، actionlint، yt-dlp، uv |
| 10ب. ثنائيات إضافية | VS Code CLI، oc، yq، terragrunt، ibmcloud، fzf، hadolint، codex |
| 10ج. ثنائيات Super-linter | shfmt، gitleaks، editorconfig-checker، trivy، clj-kondo، dotenv-linter، golangci-lint، goreleaser، kubeconform، protolint، scalafmt، ktlint |
| 10د. أدوات Java JAR | checkstyle، google-java-format (سكربتات تغليف) |
| 10هـ. أدوات فحص PHP | phpcs، phpstan، psalm (تنزيلات PHAR) |
| 10و. وحدات PowerShell | PSScriptAnalyzer، arm-ttk |
| 10ز. ثنائيات أمنية | nuclei، subfinder، httpx، ffuf، gobuster، feroxbuster، dalfox، amass، trufflehog، grype، syft، bettercap (amd64) |
| 10ح. OWASP ZAP | ماسح تطبيقات ويب قائم على Java |
| 10ط. Ghidra | إطار عمل الهندسة العكسية |
| 10ي. 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 |
| 12ج. أدوات فحص Ruby | rubocop + إضافات |
| 12هـ. وحدات فحص Perl | إضافات Perl::Critic |
| 12و. أداة فحص Lua | luacheck |
| 12ز. أداة فحص R | lintr |
| 12ح. جواهر Ruby الأمنية | wpscan، evil-winrm |
| 12ط. أدوات أمنية مستنسخة من Git | testssl.sh، exploitdb (searchsploit)، SecLists، docker-bench-security، recon-ng، spiderfoot |
| 13. متصفحات Playwright | Chromium + تبعيات النظام عبر playwright install --with-deps |
| 13ب. Chrome DevTools MCP | رابط رمزي لـ Chrome + تخزين مسبق لـ MCP + تصحيح الوضع بدون واجهة |
| 14. Homebrew | Linuxbrew (تبعيات مساعد الذكاء الاصطناعي + أدوات التنسيق) |
| 15. إضافات ZSH | إضافات oh-my-zsh المخصصة |
| 16. تهيئة Shell | npm-global، tfenv، compinit |
| 17. تكوين Claude Code + Codex | ذاكرة التعرف على الأدوات، السياسة المُدارة، سكربت الاختبار الذاتي، تكوين Codex |
| 18. نقطة الدخول | سكربت بدء تشغيل الحاوية (آخر COPY على الإطلاق) |
إضافة الأدوات
Section titled “إضافة الأدوات”حرّر ملف Dockerfile وأضف أداتك إلى القسم المناسب. أعد البناء بعد الإضافة:
docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --buildpodman-compose -f docker-compose.yml -f docker-compose.build.yml up -d --buildأو في VS Code: Dev Containers → إعادة بناء الحاوية.
حزم APT
Section titled “حزم 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
Section titled “أدوات npm”أضف إلى كتلة npm install -g في القسم 11:
RUN npm install -g \ your-npm-toolأدوات pip
Section titled “أدوات pip”أضف إلى كتلة pip install في القسم 12:
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 التخزين المؤقت القائم على السجل — تُخزّن طبقات البناء في GHCR (ghcr.io/f5-sales-demo/devcontainer:cache-*) بدلاً من ذاكرة التخزين المؤقت لـ GitHub Actions. هذا يتجنب حد ذاكرة التخزين المؤقت لـ GHA البالغ 10 جيجابايت والذي كان يتسبب في إعادة بناء كاملة متكررة لهذه الصورة متعددة البنيات بحجم ~6 جيجابايت.
تعمل بنية المرحلتين مع ذاكرة التخزين المؤقت للسجل بحيث:
- تحديثات إصدارات الأدوات (npm، pip، أدوات ثنائية) — إعادة بناء مرحلة
finalفقط (~5 دقائق) - تغييرات ملفات التكوين (
claude-config/،entrypoint.sh) — إعادة بناء الطبقات الأخيرة فقط (~دقيقة واحدة) - تغييرات الأسس (حزم APT، إصدارات Go/Rust/Java) — إعادة بناء كاملة لكلتا المرحلتين (~30 دقيقة)