Docker Compose Profiles: كيف تدير بيئات عمل متعددة (تطوير، إنتاج) في ملف واحد

هل تبحث عن طريقة لإدارة بيئات Docker المتعددة (تطوير، إنتاج، اختبار) بدون تكرار الملفات؟ Docker Compose Profiles هي الحل — تتيح لك تشغيل خدمات محددة حسب البيئة داخل ملف docker-compose.yml واحد فقط.

ما هي Docker Compose Profiles؟

Docker Compose Profiles هي ميزة مضمنة في Docker Compose تسمح لك بتجميع الخدمات (Services) داخل نفس الملف، بحيث يمكنك التحكم في أي منها يُشغَّل عند بدء التشغيل — دون الحاجة إلى ملفات منفصلة لكل بيئة.

بدلًا من هذا:

docker-compose.yml
docker-compose.dev.yml
docker-compose.prod.yml
docker-compose.test.yml

تصبح بهذا:

docker-compose.yml   ← ملف واحد يدير الكل

الفكرة بسيطة: الخدمة التي تحتوي على profiles: تُشغَّل فقط عند طلبها، أما الخدمات بدون profiles: فتُشغَّل دائمًا.

services:
  app:
    image: myapp:latest           # تشتغل دائمًا

  adminer:
    image: adminer
    profiles:
      - dev                       # تشتغل فقط مع --profile dev

  pgadmin:
    image: dpage/pgadmin4
    profiles:
      - admin                     # تشتغل فقط مع --profile admin

الفرق بين Profiles وملفات Compose المنفصلة

المعيار	Profiles (ملف واحد)	ملفات منفصلة
عدد الملفات	ملف docker-compose.yml واحد فقط	2-4 ملفات
سهولة الصيانة	ممتازة — تعديل واحد ينعكس على الكل	متوسطة — تحتاج تعديل كل ملف
تكرار التكوين	لا يوجد — الخدمات الأساسية مشتركة	يوجد — غالبًا تكرر db و app
الوضوح مع المشاريع الكبيرة	قد يصبح معقدًا مع 30+ خدمة	أوضح لكل بيئة على حدة
منحنى التعلم	سهل بعد فهم الفكرة	سهل جدًا للبداية

الخلاصة: إذا كان مشروعك متوسطًا أو صغيرًا — Profiles هي الخيار الأفضل. للمشاريع الضخمة جدًا، قد تظل الملفات المنفصلة أكثر وضوحًا.

كيف تعمل Profiles؟

تعريف Profile واحد لخدمة

services:
  mailhog:
    image: mailhog/mailhog
    profiles:
      - dev

تعريف أكثر من Profile لنفس الخدمة

services:
  mailhog:
    image: mailhog/mailhog
    profiles:
      - dev
      - staging

خدمات بدون Profile (افتراضية)

أي خدمة بدون خاصية profiles: تُشغَّل في كل الحالات.

services:
  app:        # تشتغل دائمًا
    image: myapp
  db:         # تشتغل دائمًا
    image: postgres:16
  adminer:    # تشتغل فقط مع dev
    profiles: ["dev"]
    image: adminer

تشغيل Profiles

# خدمات التطوير فقط
docker compose --profile dev up -d

# خدمات الإنتاج (بدون Profile)
docker compose up -d

# دمج أكثر من Profile
docker compose --profile dev --profile admin up -d

ملاحظة مهمة: عند تشغيل docker compose up بدون --profile، تشتغل فقط الخدمات التي لا تحتوي على profiles:. لا تنسَ هذا!

مثال عملي 1: تطبيق ويب مع قواعد بيانات

هذا مثال حقيقي لتطبيق Node.js أو Python مع PostgreSQL وأدوات مساعدة لكل بيئة:

version: "3"

services:

  # ─── خدمات أساسية (تشغّل في كل البيئات) ───
  app:
    image: myapp:${TAG:-latest}
    ports:
      - "${PORT:-3000}:3000"
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD:-secret}
    volumes:
      - pg_data:/var/lib/postgresql/data

  # ─── أدوات التطوير (dev فقط) ───
  mailhog:
    profiles: ["dev"]
    image: mailhog/mailhog
    ports:
      - "8025:8025"

  adminer:
    profiles: ["dev"]
    image: adminer
    ports:
      - "8080:8080"

  # ─── أدوات الإدارة (admin فقط) ───
  pgadmin:
    profiles: ["admin"]
    image: dpage/pgadmin4
    ports:
      - "5050:80"
    environment:
      PGADMIN_DEFAULT_EMAIL: [email protected]
      PGADMIN_DEFAULT_PASSWORD: admin

  # ─── بيئة الاختبارات (ci فقط) ───
  test-runner:
    profiles: ["ci"]
    build:
      context: .
      dockerfile: Dockerfile.test

volumes:
  pg_data:

كيف تستخدمه في كل بيئة؟

البيئة	الأمر	الخدمات التي تشتغل
الإنتاج	docker compose up -d	app + db فقط
التطوير	docker compose --profile dev up -d	app + db + mailhog + adminer
الإدارة	docker compose --profile admin up -d	app + db + pgadmin
CI/CD	docker compose --profile ci up -d	app + db + test-runner

مثال عملي 2: WordPress مع MySQL

version: "3"

services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: root
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp_data:/var/www/html

  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: wordpress
    volumes:
      - db_data:/var/lib/mysql

  # ── أدوات التطوير ──
  phpmyadmin:
    profiles: ["dev"]
    image: phpmyadmin
    ports:
      - "8081:80"
    environment:
      PMA_HOST: db

  mailhog:
    profiles: ["dev"]
    image: mailhog/mailhog
    ports:
      - "8025:8025"

  # ── أدوات الإنتاج ──
  redis:
    profiles: ["prod"]
    image: redis:7

  backup:
    profiles: ["prod"]
    image: alpine
    volumes:
      - db_data:/db
      - wp_data:/wp
    command: >
      sh -c "tar czf /backup/backup-$$(date +%Y%m%d).tar.gz /db /wp"

volumes:
  wp_data:
  db_data:

تشغيل التطوير:

docker compose --profile dev up -d

تشغيل الإنتاج:

docker compose --profile prod up -d

تلميح: يمكنك دمج --profile dev مع --profile prod إذا احتجت البيئتين معًا، لكن هذا غير شائع في التطبيقات الحقيقية.

تكامل Profiles مع المتغيرات البيئية (Environment Variables)

لزيادة المرونة، استخدم ملف .env مع Profiles:

services:
  app:
    image: myapp:${TAG:-latest}
    ports:
      - "${APP_PORT:-3000}:3000"
    environment:
      - APP_ENV=${PROFILE:-production}

  log-viewer:
    profiles: ["dev"]
    image: amir20/dozzle
    ports:
      - "${LOG_PORT:-9999}:80"

ملف .env:

TAG=latest
APP_PORT=3000
LOG_PORT=9999

ثم شغّل:

# تطوير
PROFILE=development docker compose --profile dev up -d

# إنتاج
docker compose up -d

أفضل الممارسات (Best Practices)

1. استخدم أسماء Profiles معيارية

الاسم	متى تستخدمه
dev	أدوات التطوير المحلي (Mailhog, Adminer, PhpMyAdmin)
prod	خدمات إضافية للإنتاج (Redis, Backup, monitoring)
admin	أدوات إدارة نادرة الاستخدام (PgAdmin, Portainer)
ci	خدمات الاختبار المؤتمت (Test runners, linters)
debug	أدوات تصحيح الأخطاء (Log viewers, debuggers)
monitoring	مراقبة الأداء (Prometheus, Grafana)

2. الخدمات الأساسية تبقى بدون Profile

القاعدة الذهبية: app و db و redis و cache — كلها بدون Profile. الـ Profile للأدوات الإضافية فقط.

3. لا تضع الإنتاج تحت Profile

خطأ شائع:

# ❌ خطأ — app لن تشتغل إلا مع --profile prod
services:
  app:
    profiles: ["prod"]

الصواب:

# ✅ app تشتغل دائمًا
services:
  app:
    image: myapp

  redis:  # إضافي للإنتاج
    profiles: ["prod"]
    image: redis:7

4. استخدم .env مع Profiles

اجمع بين .env و --profile للتحكم الكامل:

docker compose --profile dev --env-file .env.dev up -d

5. وثّق الـ Profiles في README

أضف جدولًا بسيطًا يوضح أي Profile يشغل أي خدمات:

البيئة	الأمر
Dev	docker compose --profile dev up -d
Prod	docker compose up -d
CI	docker compose --profile ci up -d

الأخطاء الشائعة وكيف تتجنبها

الخطأ 1: وضع الخدمة الأساسية تحت Profile

النتيجة: الخدمة لا تشتغل في البيئة الافتراضية.

الحل: اترك app و db دائمًا بدون Profile.

الخطأ 2: نسيان تمرير --profile

النتيجة: تشتغل الخدمات الأساسية فقط بدون أي أدوات مساعدة.

الحل: أضف أمر التشغيل إلى README أو Makefile.

الخطأ 3: افتراض أن Profiles تتوارث

# ✅ هذا يستهدف dev و staging معًا
profiles: ["dev", "staging"]

الخطأ 4: تكرار Profiles في Compose (v2 vs v3)

في Docker Compose v2، تعمل Profiles بشكل افتراضي. لا حاجة لتحديد version: في الملف.

الأسئلة الشائعة (FAQ)

هل يمكن تشغيل أكثر من Profile في نفس الوقت؟

نعم. استخدم --profile عدة مرات:

docker compose --profile dev --profile admin up -d

ماذا يحدث إذا لم أحدد أي Profile؟

تشغّل فقط الخدمات التي لا تحتوي على profiles:.

هل يعمل docker compose down مع Profiles؟

نعم. لإيقاف خدمات Profile معين:

docker compose --profile dev down

كيف أعرف الخدمات التي تنتنظر إلى Profile معين؟

docker compose --profile dev config --services

هل Profiles مدعومة في Docker Swarm؟

نعم، Docker Compose Profiles مدعومة في Docker Compose v2 وفي Docker Swarm mode.

الفرق بين Profiles و extends؟

extends يسمح بإعادة استخدام تكوين خدمة في ملف آخر. profiles تتحكم في أي الخدمات تشتغل وليس في تكرار التكوين. يمكن استخدامهما معًا.

الخاتمة

Docker Compose Profiles هي واحدة من أقوى ميزات Docker Compose وأقلها استخدامًا. ببساطة، تسمح لك بإدارة بيئات التطوير والإنتاج والاختبار في ملف واحد منظم وواضح.

الميزات التي كسبتها باستخدام Profiles:

• ملف واحد بدلًا من 4
• صيانة أسهل
• تكوين أقل تكرارًا
• مرونة كاملة في التشغيل

جرّبها الآن: ابدأ بإضافة Profile dev إلى مشروعك الحالي، وانقل إليه أدوات التطوير مثل Adminer أو Mailhog. ستلاحظ الفرق فورًا.

روابط ذات صلة

• Docker Volumes: شرح مبسط لحفظ بيانات الحاويات بشكل دائم