كيف تتعامل مع التكوين والأسرار في Docker؟

Question

Accepted Answer

يجب أن تكون التطبيقات المحتواة **قابلة للتكوين** دون إعادة بناء الصورة — باستخدام **متغيرات البيئة** وملفات التكوين و**إدارة الأسرار** الصحيحة. التعامل الصحيح مع التكوين والأسرار مهم للأمان وللتشغيل في نفس الصورة عبر البيئات المختلفة.

## التكوين عبر متغيرات البيئة (12-factor)

```bash
# pass config at RUNTIME via environment variables (not baked into the image)
docker run -e DATABASE_URL=postgres://... -e NODE_ENV=production myapp
docker run --env-file .env myapp        # load many from a file
```

```yaml
# in docker-compose.yml
services:
  app:
    image: myapp
    environment:
      - DATABASE_URL=postgres://db:5432/app
    env_file: .env
```

باتباع مبادئ **twelve-factor**، يأتي التكوين من **البيئة** (متغيرات env) في وقت التشغيل — لذا تعمل **نفس الصورة** في التطوير والاختبار والإنتاج مع تكوين مختلف، دون إعادة بناء لكل بيئة.

## الأسرار: لا تدرجها في الصور

```text
⚠️ NEVER put secrets (passwords, API keys, tokens) in the Dockerfile or image layers:
  → image layers are inspectable → secrets can be EXTRACTED (even if "removed" later,
    they remain in earlier layers)
  → anyone with the image gets the secrets
→ This is a serious, common security mistake.
```

## التعامل الصحيح مع الأسرار

```text
✓ RUNTIME environment variables (better than image, but visible in inspect/env)
✓ DOCKER SECRETS (Swarm) / Kubernetes Secrets — mounted securely at runtime
✓ Secrets MANAGERS — HashiCorp Vault, AWS Secrets Manager, etc. (fetch at runtime)
✓ BuildKit build secrets (--secret) — for build-time secrets without baking into layers
✓ Keep .env files OUT of version control (.gitignore) and out of the image (.dockerignore)
```

## لماذا هذا مهم

التعامل الصحيح مع التكوين والأسرار في Docker مهم لكل من **الأمان** و**المرونة التشغيلية**، لذا فهو معرفة عملية قيمة.

مبدأ التكوين — توفير التكوين عبر **متغيرات البيئة في وقت التشغيل** بدلاً من إدراجه في الصورة (باتباع مبادئ twelve-factor) — مهم لأنه يسمح **بتشغيل نفس الصورة عبر جميع البيئات** (التطوير والاختبار والإنتاج) مع تكوين مختلف، دون إعادة بناء لكل بيئة، وهذا أساسي للنشر القابل للتكرار والمحمول وممارسة جوهرية للحاويات.

ما هو أكثر أهمية، إدارة **الأسرار** تثير مخاوف أمنية جادة: القاعدة الرئيسية — **لا تدرج الأسرار (كلمات المرور ومفاتيح API والرموز) في الصور** — ضرورية لأن طبقات الصورة قابلة للفحص والأسرار المدرجة فيها يمكن **استخراجها** (وتبقى في الطبقات السابقة حتى لو تمت "إزالتها" لاحقاً)، لذا أي شخص لديه الصورة يحصل على الأسرار؛ هذا خطأ شائع وخطير يسبب تسرب بيانات الاعتماد الفعلي.

فهم **إدارة الأسرار الصحيحة** — متغيرات البيئة في وقت التشغيل (أفضل، لكن مرئية في الفحص)، آليات الأسرار المخصصة (أسرار Docker/Kubernetes المثبتة بأمان، مديرو الأسرار مثل Vault أو AWS Secrets Manager التي تُجلب في وقت التشغيل، أسرار BuildKit لاحتياجات وقت البناء)، والحفاظ على ملفات `.env` خارج التحكم في الإصدار والصور — ضروري لإدارة الأسرار بأمان.

بما أن تشغيل نفس الصورة عبر البيئات (عبر التكوين القائم على env) وحماية الأسرار (عدم إدراجها في الصور) مهمان كلاهما للنشر الآمن والمرن للحاويات، وبما أن سوء التعامل مع الأسرار هو فشل أمني جاد وشائع، فإن فهم التكوين والأسرار في Docker — التكوين القائم على البيئة وإدارة الأسرار الصحيحة — معرفة عملية قيمة لنشر الحاويات بأمان ومرونة، حيث يكون جانب الأسرار بشكل خاص معرفة أمنية حرجة تمنع التعرض الفعلي لبيانات الاعتماد.