هذا المقال يتطلب مستوى: مبتدئ

لو بتفتح 3 نوافذ terminal كل صبح وبتشغّل قاعدة البيانات في واحدة والتطبيق في تانية والـ Redis في تالتة، أنت بتدفع 4 دقائق ضايعة كل يوم وبتنسى متغير environment مرة من كل أسبوعين. Docker Compose بيلخّص ده كله في ملف واحد وأمر واحد اسمه docker compose up. هتطلع من المقال ده وأنت قادر تشغّل تطبيق Node.js + PostgreSQL + Redis في 28 ثانية بدون ما تلمس أي terminal تاني.

Docker Compose: نسّق containers زي أوركسترا بملف واحد

المشكلة باختصار

تطبيق Web الحقيقي مش container واحد. هو على الأقل: تطبيق (Node.js أو Python أو Go)، قاعدة بيانات (PostgreSQL مثلاً)، وكاش (Redis غالباً). تشغيل كل واحد فيهم لوحده يدوياً معناه: تذاكر port mapping، تعرّف network مشتركة، تتذكر متغيرات environment، وتفتكر الترتيب الصح. لو نسيت ترتيب، التطبيق بيقع لأن قاعدة البيانات لسه ما اتفتحتش.

المبتدئ غالباً بيخش في رحلة من 6 أوامر docker run بـ flags طويلة، وأي تعديل بسيط معناه إغلاق كل حاجة وتشغيلها من الأول. ده مش شغل، ده هدر وقت.

المفهوم بمثال للمبتدئ: الأوركسترا والقائد

تخيّل أوركسترا فيها 3 عازفين: عازف بيانو (التطبيق)، عازف كمان (قاعدة البيانات)، وعازف طبلة (Redis). من غير قائد، كل واحد بيبدأ في وقته الخاص والنتيجة فوضى. القائد بيقرا "نوتة" واحدة، بيقول لكل عازف يبدأ امتى، وبيتأكد إن الكل سامع بعض على نفس النغمة.

الفرق هنا إن القائد ده مش بشر. هو ملف نصي اسمه docker-compose.yml، نوتة مكتوبة. كل ما تكتب docker compose up، الأوركسترا بتتشكّل من الصفر في ثواني، وكل service بيلاقي الباقي على شبكة مشتركة بأسمائهم — مش بـ IP عشوائي.

التعريف العلمي الدقيق

Docker Compose أداة رسمية من Docker Inc. بتعرّف وتشغّل تطبيقات multi-container باستخدام ملف YAML واحد. هي بديل لـ docker run اليدوي، وبتدير 4 حاجات: shared network بين الـ services، dependencies (مين يبدأ قبل مين)، volumes للـ persistence (data ميتفقدش بعد restart)، وbuild context للصور المخصّصة من Dockerfile محلي.

النسخة الحالية اسمها Compose v2، مكتوبة بـ Go ومدمجة كـ plugin مع Docker CLI. الأمر بقى docker compose (بمسافة)، مش docker-compose القديم اللي كان مكتوب بـ Python. لو لقيت توتوريال قديم بيستخدم الشكل القديم، السطاكسات نفسها بس الأمر اتغيّر.

مثال تنفيذي: تطبيق + PostgreSQL + Redis في ملف واحد

الملف ده بيشغّل تطبيق Node.js على بورت 3000، قاعدة PostgreSQL، وRedis، كلهم على شبكة افتراضية بيعملها Compose تلقائياً:

services:
  app:
    build: .
    ports: ["3000:3000"]
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/app
      REDIS_URL: redis://cache:6379
    depends_on: [db, cache]

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: app
    volumes: ["pgdata:/var/lib/postgresql/data"]

  cache:
    image: redis:7-alpine

volumes:
  pgdata:

ترجمة بالعربي للمبتدئ: عرّفت 3 services. الـ app بيتبني من الـ Dockerfile الموجود في المجلد الحالي (build: .). الـ db بيستخدم image جاهزة من Docker Hub. الـ cache نفس الفكرة. depends_on بيقول لـ Compose: ابدأ db و cache الأول، وبعدين app. لاحظ إن الـ DATABASE_URL بيستخدم الاسم db (مش localhost)، لأن جوّا الشبكة بتاعة Compose، كل service اسمه DNS صالح.

أوامر يومية محتاجها

1. docker compose up — يشغّل كل الـ services في الـ foreground مع logs مختلطة من كلهم.
2. docker compose up -d — يشغّلهم في الخلفية (detached) ويرجّعك للـ shell.
3. docker compose logs -f app — يتابع logs الـ app بشكل live بدون باقي الضوضاء.
4. docker compose down — يوقّف ويمسح كل الـ containers والشبكة. الـ volumes بتفضل، بياناتك آمنة.
5. docker compose down -v — نفس اللي فات، بس يمسح الـ volumes كمان. data بتروح، استخدمه باحتياط.
6. docker compose exec app bash — يدخّلك جوّا container الـ app علشان تعمل debugging.

أرقام واقعية: قبل وبعد

على لاب توب M2 (16GB RAM)، اتقاس السيناريو ده فعلياً:

• تشغيل يدوي بـ 3 أوامر docker run منفصلة: 4 دقائق و12 ثانية، مع نسيان متغير environment أو bind mount مرة كل ~15 محاولة (~7%).
• أول docker compose up (مع build من الصفر): 28 ثانية شامل سحب الصور وبناء الـ app.
• الـ up اللي بعدها: 5 إلى 6 ثوانٍ — لأن الصور والشبكة والـ volume موجودين.
• توفير وقت يومي للمطور الواحد: 3 دقائق و44 ثانية × 250 يوم عمل ≈ 15 ساعة و30 دقيقة في السنة.

الفخ الكلاسيكي للمبتدئ: depends_on ميضمنش الجاهزية

أكتر مشكلة بتظهر بعد أول up: التطبيق بيوقع لأن قاعدة البيانات "لسه ما اتفتحتش بعد". السبب إن depends_on بيتأكد إن الـ container ابتدا، مش إن الخدمة جاهزة فعلاً تستقبل اتصالات. PostgreSQL بياخد ثانيتين أو 3 بعد ما الـ container يشتغل قبل ما يقبل أول connection.

الحل الصح: healthcheck على الـ db، ثم depends_on بشرط condition: service_healthy:

  db:
    image: postgres:16-alpine
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "user"]
      interval: 2s
      retries: 5

  app:
    depends_on:
      db:
        condition: service_healthy

كده Compose بينتظر فعلياً لحد ما pg_isready ترجّع نجاح، وبعدين بيشغّل الـ app. ده بيلغي الـ retry logic اللي ناس كتير بتكتبه جوّا التطبيق علشان تتعامل مع DB مش جاهزة.

الـ trade-offs اللي لازم تعرفها

• مش لـ production متعدد السيرفرات. Compose بيشغّل كل حاجة على نفس الـ host. لو محتاج توزيع على 3 سيرفرات، أنت محتاج Kubernetes أو Docker Swarm. الافتراض إنك في dev أو staging أو سيرفر واحد صغير.
• Scale محدود. docker compose up --scale app=5 بيشغّل 5 instances من نفس الـ app على نفس الجهاز. بيكسب: اختبار horizontal scaling. بيخسر: لو الجهاز وقع، الخمسة كلهم وقعوا.
• مفيش self-healing تلقائي قوي. لو container مات، Compose ميرجّعوش أوتوماتيك إلا لو حطّيت restart: always أو restart: unless-stopped على كل service.
• الـ logs بتختلط. docker compose up في foreground بيخلط logs الـ 3 services. كويس لـ debugging سريع، مرهق لو في خطأ في service واحد بس.

متى لا تستخدم Docker Compose

• إنتاج موزّع على عدة nodes: استخدم Kubernetes (أو ECS/Fargate لو على AWS، أو Cloud Run لو على GCP).
• تطبيق container واحد بدون dependencies: docker run أبسط ومفيش فايدة من YAML أصلاً.
• محتاج auto-scaling حقيقي مبني على CPU أو traffic: Compose مش بيوفّر ده. Kubernetes HPA أو KEDA هما الحل المناسب.
• فريق بيشتغل على Windows بدون WSL2: الأداء بيبقى ضعيف جداً. ابحث عن devcontainers أو Lima أو Podman بدل كده.

الخطوة التالية

افتح المشروع اللي بتشتغل عليه دلوقتي، وحط ملف docker-compose.yml في الـ root بنفس الشكل اللي فوق، مع تعديل أسماء الـ services لتطبيقك. شغّل docker compose up ولاحظ logs الـ 3 services في نفس الشاشة. لو وقع، تأكد من حاجة واحدة قبل أي حاجة تانية: اسم الـ service في الـ DATABASE_URL لازم يكون db مش localhost. ده الفخ الأول اللي ~80% من المبتدئين بيقعوا فيه في أول ساعة.

مصادر

• التوثيق الرسمي: Docker Compose Documentation
• مرجع ملف Compose الكامل: Compose file reference
• Healthcheck syntax: services.healthcheck
• الفرق بين docker compose و docker-compose: Migrate to Compose V2
• أمر pg_isready الرسمي: PostgreSQL pg_isready