شرح Docker Compose: إدارة الخدمات بملف واحد
شرح Docker Compose يدور حول وصف تطبيق متعدد الخدمات في ملف واحد بدل تكرار أوامر تشغيل طويلة. تحدد الصور والمنافذ والتخزين والإعدادات، ثم تستخدم أوامر واضحة لإنشاء الخدمات وفحصها وإيقافها. Compose مناسب أيضًا لتطبيق من خدمة واحدة عندما تريد حفظ إعداداته ضمن المشروع.
سنشغّل Nginx وRedis كخدمتين مستقلتين داخل مشروع تدريب. لا يتصل Nginx بقاعدة Redis في هذا المثال؛ الهدف تعلّم الإدارة المشتركة، لا الادعاء بأننا بنينا تطبيقًا يستخدم التخزين المؤقت. راجع الدرس الأول في Docker عند الحاجة. لم تُنفّذ الأوامر أثناء إعداد المقال.
ماذا يضيف Docker Compose إلى docker run؟
يحفظ Compose إعدادات الخدمات في ملف YAML يمكن قراءته ومراجعته وإعادة استخدامه. ويجمع موارد المشروع، مثل الشبكة ووحدات التخزين، ضمن أسماء مرتبطة بالمشروع عادةً.
لا يلغي Compose المحرك ولا يحوّل التطبيق تلقائيًا إلى نظام عالي التوافر. إنه ينظم إنشاء الخدمات وإدارتها، بينما تبقى مراقبة التطبيق والنسخ الاحتياطي وحماية النشر مهام تحتاج إعدادًا مستقلًا.
تحقق من وجود الأمر الحديث:
docker compose version
نستخدم docker compose بمسافة. الأمر القديم docker-compose يشير إلى توزيع سابق في بيئات كثيرة. لا تبدأ بإضافة حقل version قديم إلى الملف؛ صيغة Compose الحالية لا تحتاجه للمثال.
جهّز ملف compose.yaml
أنشئ مجلدًا مستقلًا باسم g4a-compose، ثم ضع فيه هذا الملف:
name: g4a-compose-learning
services:
web:
image: nginx:stable-alpine
ports:
- "127.0.0.1:8088:80"
cache:
image: redis:7-alpine
command: ["redis-server", "--appendonly", "yes"]
volumes:
- cache_data:/data
volumes:
cache_data:
الخدمة web تنشر منفذًا محليًا للمتصفح. والخدمة cache تستخدم وحدة مسماة لحفظ ملفات Redis مع تفعيل AOF في هذا المثال. لم ننشر منفذ Redis للمضيف، إذ سنختبره داخل المشروع.
المسافات جزء من بنية YAML. استخدم مسافات عادية ولا تستخدم Tab للمحاذاة. وتذكر أن تعريف وحدة باسم cache_data داخل الخدمة يحتاج تعريف المورد في قسم volumes العلوي كما فعلنا.
كيف تفحص الملف وتشغّل المشروع؟
افتح الطرفية في المجلد الذي يحتوي الملف، ثم افحص التكوين قبل الإنشاء:
docker compose config --quiet
docker compose up -d
docker compose ps
إذا نجح config –quiet فلن يعرض عادةً التكوين كاملًا؛ وهذا مناسب لتجنب طباعة قيم قد تصبح حساسة في مشاريع أخرى. أما up -d فيجهّز الموارد ويبدأ الخدمات في الخلفية.
افتح http://localhost:8088 لاختبار Nginx. ثم اختبر Redis عبر أداته داخل الحاوية:
docker compose exec cache redis-cli ping
المتوقع ظهور PONG إذا كانت الخدمة جاهزة. لا تستخدم curl إلى منفذ Redis باعتباره خدمة HTTP؛ لكل خدمة بروتوكولها وأداة اختبارها المناسبة.
كيف تتواصل الخدمات؟
ينشئ Compose شبكة افتراضية للمشروع عادةً، ويمكن للخدمات الوصول إلى بعضها باسم الخدمة. لو كان لديك تطبيق يستخدم Redis، فاسم المضيف هنا cache والمنفذ الداخلي 6379.
لا تحتاج إلى حفظ IP للحاوية أو كتابة container_name لكل خدمة. الأسماء الثابتة الصريحة قد تصعّب تشغيل نسختين من المشروع أو توسيع خدمة. ابدأ بأسماء الخدمات التي يوفّرها Compose، واجعل عناوين التطبيق مرتبطة بها.
جرّب استمرار البيانات
اكتب قيمة تدريبية ثم اقرأها:
docker compose exec cache redis-cli SET g4a:lesson compose
docker compose exec cache redis-cli GET g4a:lesson
أوقف المشروع واحذف حاوياته وشبكته المعتادة، ثم أعد إنشاءه بالاسم نفسه:
docker compose down
docker compose up -d
docker compose exec cache redis-cli GET g4a:lesson
المتوقع بقاء القيمة لأن الوحدة المسماة لم تُحذف ولأن إعداد الاستمرار مستخدم. هذه تجربة وظيفية صغيرة، وليست اختبارًا للنسخ الاحتياطي أو مقاومة انقطاع الكهرباء. لا تستخدم بيانات مهمة في مختبر التعلم.
ما الفرق بين stop وdown وrestart؟
stop يوقف الحاويات مع إبقائها. وdown يزيل حاويات المشروع وشبكاته التي يديرها، مع الاحتفاظ بالوحدات المسماة افتراضيًا. وrestart يعيد بدء الحاويات الحالية، لكنه لا يطبّق تغييرات تكوين تتطلب إعادة الإنشاء.
| المطلوب | الأمر |
|---|---|
| عرض الحالة | docker compose ps |
| آخر السجلات | docker compose logs –tail 50 |
| إيقاف دون إزالة | docker compose stop |
| إنشاء أو تحديث الخدمات | docker compose up -d |
| إزالة الحاويات والشبكة | docker compose down |
الخيار down -v يغيّر أثر العملية على وحدات التخزين. لا تستخدمه إذا أردت الاحتفاظ بالبيانات. الوحدات الخارجية لها قواعد مختلفة؛ اقرأ إعداد المشروع بدل افتراض أن جميع أنواع التخزين تتعامل بالطريقة نفسها.
هل depends_on يعني أن الخدمة جاهزة؟
الصيغة البسيطة من depends_on تحدد ترتيب البدء، ولا تثبت أن قاعدة البيانات جاهزة لقبول اتصال التطبيق. يمكنك إضافة healthcheck واستخدام شرط service_healthy عندما تحتاج انتظار الجاهزية الأولية.
حتى بعد اجتياز الفحص، قد تتعطل الخدمة لاحقًا. يجب أن يتعامل التطبيق مع فشل الاتصال وإعادة المحاولة بطريقة مناسبة. لا تجعل ترتيب الإنشاء بديلًا عن منطق تعافٍ داخل التطبيق.
كيف تطبّق تغييرًا على المشروع؟
إذا غيّرت المنفذ في الملف، نفّذ up -d ليطبق Compose التكوين الجديد على الخدمة المتأثرة. وإذا كانت الخدمة تعتمد على build وتغيرت ملفات البناء، استخدم up -d –build لتطلب البناء أيضًا.
لا يكفي تعديل الملف وحده، كما لا يكفي restart لكل أنواع التغيير. افحص ps وlogs بعد التنفيذ. ولتحديث الصور وفق الوسوم المستخدمة يمكنك سحبها ثم إعادة الإنشاء، مع مراجعة أثر الإصدار الجديد على بيانات التطبيق.
تمرين بعد شرح Docker Compose
غيّر المنفذ المحلي إلى 8089، وطبّق التغيير، ثم تحقق من العنوان الجديد. راجع بقاء قيمة Redis بعد down ثم up، وسجّل الفرق بين موارد التطبيق وبياناته. بهذا تصبح قادرًا على قراءة ملف Compose بدل التعامل معه كنص طويل لا تعرف وظيفة أقسامه.
أسئلة شائعة
هل Compose يحتاج عدة حاويات دائمًا؟
لا. يمكن استخدامه لخدمة واحدة لحفظ تكوينها داخل المشروع.
هل down يحذف البيانات دائمًا؟
لا يحذف الوحدات المسماة افتراضيًا. خيارات مثل -v وإعدادات الموارد تحدد نطاق الحذف.
هل restart يطبق تغيير المنفذ؟
لا يغيّر إعدادات إنشاء الحاوية. استخدم up -d لتطبيق التكوين الجديد.
هل depends_on يكفي لقاعدة البيانات؟
ليس بصيغته البسيطة. استخدم فحص جاهزية مناسبًا وشرط service_healthy مع قدرة التطبيق على إعادة الاتصال.
المصادر والمراجعة التقنية
استُلهم ترتيب موضوعات السلسلة من ملاحظات Narayan Prasad (@code.withnarayan). الشرح العربي والأمثلة والرسوم هنا إعداد مستقل، مع الرجوع إلى الوثائق الرسمية لتصحيح وتوسيع المفاهيم.
مقالات ومعرفة تقنية باللغة العربية.
