3.5 · استكشاف أخطاء كومبوز وإصلاحها : إعادة التشغيل والمجلدات اليتيمة

المستوى 3 · دوكر كومبوز (Docker Compose)

3.5استكشاف أخطاء كومبوز وإصلاحها : إعادة التشغيل والمجلدات اليتيمة

الهدف: إصلاح أعطال كومبوز الثلاثة الأكثر شيوعا دون كسر كل شيء.
الوقت المقدّر: 11 دقيقة · قراءة ذاتية · إذا كان لديك 5 دقائق فقط: اقرأ «الأساسي في 30 ثانية» + المخطط.

الأساسي في 30 ثانية

  • « Restarting » : اقرأوا قبل إعادة الإنشاء : compose ps يرصد المريض، وسجلات الخدمة تتهمه — نصحح الملف، ثم يعيد up -d إنشاء ما تغير فقط.
  • منفذ محتل : نحرك الأيسر : 8080 already in use = محتل على المضيف — نغير منفذ المضيف (الأيسر)، ولا الداخلي أبدا ؛ ويكشف docker ps الشامل.
  • بناءات قديمة ومجلدات يتيمة : الاستهداف : up -d --build بعد تعديل الكود، وvolume ls لليتامى — ولا يمس down -v سوى هذا المشروع، وبحذر.

حالة مصغرة مسلسلة — إدير والمنفذ الشبح

يطلق إدير، ديفوبس مبتدئ في الجزائر، ستاكه يوم اثنين : فالواجهة تدور في Restarting، و« المنفذ محتل already allocated ». وبدل نسف كل شيء، يشخص : يرصد compose ps الواجهة، وتتهمها compose logs بالمنفذ، ويكشف docker ps الشامل run يدويا قديما منسيا على 8080. يغير منفذ المضيف إلى 8082 في كومبوز، و up -d — فيبدأ الستاك، والبيانات سليمة. ويُنظَّف الشبح اليدوي بعد ذلك، جراحيا. ومنذئذ، يقرأ إدير قبل إعادة الإنشاء.

هذه الحالة نفسها تعود في الدرس والمخطط والنص الجاهز وتحدي 48 ساعة.

1. Restarting والمنفذ المحتل : ps يرصد و logs تتهم

خدمة في « Restarting » : نقرأ قبل إعادة الإنشاء. فيرصد docker compose ps المريض، وتتهمه سجلات اسم-الخدمة — متغير مفقود، أو مجلد في مسار خطأ، أو منفذ محتل. نصحح الملف، ثم up -d : فلا يعيد كومبوز إنشاء سوى ما تغير، والباقي يواصل الدوران. فالتصريحي جراحي بالطبيعة : نداوي الوصف، لا الحاويات.

المنفذ المستعمل (8080 already in use) : فخدمة أخرى — أو run قديم خارج كومبوز — تحتل منفذ المضيف. والحل : تغيير منفذ المضيف (الأيسر، "8082:80")، ولا منفذ الحاوية أبدا ؛ ويكشف docker ps الشامل المحتل. وستاكان يختلطان، فغالبا الاسم نفسه للمشروع (المجلد) أو منافذ المضيف نفسها : اعزلوا مع -p ومنافذ متميزة.

2. البناءات القديمة والمجلدات اليتيمة : الاستهداف لا النسف

لا يتحدث الكود بعد up ؟ فلم تُعَد الصورة بناؤها : up -d --build، لا حذف غاضب. وتُنشئ إعادة تسمية خدمة أو مشروع مجلدات يتيمة (بيانات قديمة نائمة) : يُظهرها docker volume ls، ولا يمس compose down -v سوى هذا المشروع — وبحذر، لأنه يمحو مجلداته. فالتنظيف هو التحديد أولا.

ومنعكسات طبيب الستاك الثلاثة : تسمية المشاريع (-p) عند التكرار، وقراءة سجلات الخدمة (لا كل الستاك)، وتصحيح الملف ثم إعادة الإطلاق. والممنوع المطلق : down -v مذعورا — فلا ننسف أبدا للتشخيص. وقد ألصق إدير التسلسل على الجدار : ps ← logs ← التصحيح ← up -d.

خطأ شائع في الفهم: « عندما يتعثر، ننسف كل شيء (down -v) ونغير منفذ الحاوية ». لا، مرتين. فـ down -v مذعورا يمحو بيانات المشروع : نشخص أولا (ps و logs)، ونصحح الملف، ونعيد الإطلاق — فالنسف ليس تشخيصا أبدا. والنزاع على آلة المضيف : فهو المنفذ الأيسر الذي نحركه (أو المحتل الذي نقتله)، ولا الداخلي المربوط في الصورة أبدا.
الإصلاح دون كسر الرصد والاتهام والتصحيح وإعادة الإطلاق compose ps رصدالخدمة المريضةسجلات الخدمة (+ docker psالشامل) الاتهام : متغير ومسار ومحتلتصحيح الملف منفذ المضيفوالمتغير وإعادة البناءup -d (ما تغير فقط) لايعيد سوى المعدل
الرصد والاتهام والتصحيح وإعادة الإطلاق
نص المخطط (SEO / قارئات الشاشة / الترجمة): 1) الرصد : يرى إدير الواجهة في Restarting في compose ps بدل نسف كل شيء. 2) الاتهام : تُظهر سجلات الخدمة المنفذ المحتل، ويكشف docker ps الشامل الـ run اليدوي الشبح. 3) التصحيح : مُرِّر منفذ المضيف إلى 8082 في الملف، و up -d لا تعيد سوى الواجهة — والبيانات سليمة. الدرس : ps ترصد، و logs تتهم، والملف يصحح.

🔎 مثال ملموس — منفذ يحتله شبح : تشخيص كامل

يبسط إدير التسلسل ps ← logs ← docker ps ← تصحيح الملف.

docker compose ps        # الواجهة api : Restarting ؟
docker compose logs api  # خطأ : المنفذ مستعمل ؟
docker ps                # ‏run‏ يدوي قديم على 8080 ؟
# صححوا منفذ المضيف في compose.yml : "8082:80"
docker compose up -d     # لا يعيد سوى ما تغير

القراءة : فالمحتل كان run يدويا منسيا — كشفه الـ ps الشامل.

الدرس : نغير منفذ المضيف (الأيسر)، ولا الداخلي أبدا ؛ وننظف الشبح بعد ذلك.

مفردات القسم

اليتيم (Orphelin)
مجلد أو مشروع مهجور بعد إعادة تسمية : بيانات قديمة نائمة تُحدَّد قبل أي تنظيف.

مثال بسيط: الـ pgdata القديم الخاص بإدير بعد إعادة تسمية الخدمة.

ما ليس كذلك: مجلد نشط للمشروع الجاري.

رد فعل: أولا volume ls، والحذف عن معرفة.

المحتل (Squatteur)
عملية تحتل منفذ المضيف المستهدف : run يدوي قديم أو ستاك ثان على المنفذ نفسه.

مثال بسيط: الـ run اليدوي المنسي على 8080.

ما ليس كذلك: مشكلة في صورة الخدمة.

رد فعل: docker ps الشامل للكشف.

--build
فرض إعادة بناء الصور عند up : فيؤخَذ الكود المعدل حقا.

مثال بسيط: الـ up -d --build الخاص بإدير بعد كل تغيير واجهة.

ما ليس كذلك: حذف غاضب للحاويات « للفرض ».

رد فعل: كود متغير = --build، منهجيا.

اسم المشروع (Nom de projet)
بادئة تعزل موارد ستاك (-p، والمجلد افتراضيا) : مشروعان وعالمان.

مثال بسيط: يعزل إدير النموذج والمهمل مع -p.

ما ليس كذلك: ستاكان يختلطان على المنافذ نفسها.

رد فعل: سمُّوا عند التكرار على آلة.

إعادة الإنشاء (المستهدفة)
لا يعيد up -d سوى الخدمات المعدلة : جراحة التصريحي، والباقي يدور.

مثال بسيط: وحدها الواجهة أُعيد إنشاؤها بعد تغيير المنفذ.

ما ليس كذلك: نسف كل الستاك « للتأكد ».

رد فعل: صححوا الملف، وأعيدوا الإطلاق، وتحققوا.

في التطبيق — اكسروا ثم أصلحوا، بالمشرط

  1. أحدثوا منفذا محتلا : run يدوي + كومبوز على منفذ المضيف نفسه.
  2. شخصوا : compose ps، و compose logs للخدمة، و docker ps الشامل.
  3. صححوا منفذ المضيف في الملف وأعيدوا الإطلاق (up -d) : وحدها الخدمة تتغير.
  4. نظفوا الشبح اليدوي (rm -f) وتحققوا : ستاك أخضر، وبيانات سليمة.
تصلحون كومبوز بالمشرط — التشخيص وتصحيح الملف وإعادة الإطلاق — دون فقدان بيانات.

نص جاهز للقول — إعلان العطل والعلاج (30 ثانية)

« كانت الواجهة تدور : منفذ مضيف يحتله run يدوي قديم منسي. حركت المنفذ الأيسر إلى 8082 في كومبوز، وأعدت الإطلاق — وحدها الخدمة أُعيد إنشاؤها، والبيانات سليمة، ونُظِّف الشبح بعد ذلك. ولا down -v، ولا فقدان. »

يُقال في اجتماع الفريق ؛ واعرضوا التسلسل ps ← logs ← التصحيح.

نموذج نسخ-لصق — كومبوز بعد تصحيح المنفذ

# بعد التشخيص : نُقِل منفذ المضيف (الأيسر)، والداخلي دون تغيير.
services:
  web:
    image: nginx:1.27
    ports:
      - "8082:80"
    networks:
      - front
  bdd:
    image: postgres:16.4
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - front

volumes:
  pgdata:

networks:
  front:
# التشخيص : compose ps، وسجلات الخدمة، و docker ps الشامل.

مستقل

التسلسل ps ← logs ← التصحيح ← up -d وصباحات الاثنين خاصتكم تعود هادئة.

مقاولة صغيرة في الجزائر

يعرض إدير التسلسل على الجدار : يشخص الفريق قبل النسف.

فريق منتج

امنعوا down -v خارج الستاك المهمل ؛ واطلبوا سجل الخدمة في كل تذكرة عطل.

مبتدئ

هذا الأسبوع : أحدثوا منفذا محتلا على مهمل وأصلحوه بالمشرط.

✓ ممارسات جيدة

  • اقرؤوا سجلات الخدمة الدقيقة، لا كل الستاك جملة.
  • صححوا الملف وأعيدوا الإطلاق : فلا يعيد كومبوز سوى ما تغير.
  • سمُّوا المشاريع (-p) حالما يتشارك ستاكان آلة.

✗ أخطاء شائعة

  • down -v مذعورا : تُمحَى بيانات المشروع.
  • تغيير منفذ الحاوية (الأيمن) بدل منفذ المضيف (الأيسر).
  • نسيان --build بعد تعديل الكود : فالصورة القديمة ما زالت تدور.

النقاط الأساسية

  • PS ترصد و LOGS تتهم والملف يصحح : اقرؤوا قبل إعادة الإنشاء.
  • منفذ محتل ← نحرك منفذ المضيف (الأيسر) أو نقتل المحتل.
  • DOWN -v = إعادة ضبط المشروع، وبحذر — وليست تشخيصا أبدا.
  • --BUILD بعد كل تغيير صورة ؛ و -p لعزل التكرار.

تحدي 48 ساعة — طبّق غدا

أحدثوا عطلا واحدا على مهمل (منفذ محتل) وأصلحوه دون -v، مع تدوين كل خطوة من التشخيص.

قائمة الخروج من القسم
  • أشخص ps ← logs قبل أي فعل.
  • أحرك منفذ المضيف، ولا الداخلي أبدا.
  • لا أنسف أبدا : و -v فقط لإعادة ضبط مُقَرَرة.
تقييم ذاتي 1-5 : هل قرأت السجلات قبل آخر إعادة إنشاء ؟هل أعرف تسمية ما سيدمره كل -v ؟

أسئلة شائعة

لماذا يختلط ستاكان ؟

الاسم نفسه للمشروع (المجلد افتراضيا) أو منافذ المضيف نفسها : فتتداخل الموارد. اعزلوا مع -p اسم-المشروع ومنافذ مضيف متميزة. فيُظهر compose ps لكل مشروع عالمين منفصلين — ويبقى docker ps الشامل الحَكَم عند الشك.

هل نعيد إنشاء كل شيء عندما تتغير خدمة ؟

لا : فلا يعيد up -d سوى الخدمات المعدلة — وتلك كل قيمة التصريحي. صححوا الملف وأعيدوا الإطلاق وتحققوا : فالباقي يواصل الدوران، والمجلدات تبقى. ونسف كل شيء « للتأكد » يدمر ما يحفظه التصريحي.

تحقّق من فهمك

يعرض كومبوز « port already allocated ». ماذا تغيرون ؟

موارد إضافية (اختياري، للتعمّق أكثر)

اختبار المستوى 3أسئلة جديدة وأصعب للتحقق من مكتسباتك