عارض يفسر من أين جاءت قيمة الحاوية: مشاريع تخرج هندسة البرمجيات

قد يقرأ الفريق ملف Compose ويتوقع أن تعمل الحاوية بقيمة APP_MODE=local، ثم يجد التطبيق يطبع production. السبب أحياناً ترتيب مصادر القيمة لا خطأ غامض داخل البرنامج. هذا المشروع يحول حالات Docker Compose إلى شجرة قرار قابلة للفحص، ويشرح مشاريع تخرج هندسة البرمجيات من أين جاءت كل قيمة نهائية. تنشر وثائق Docker ترتيب الأولوية بين وسيطة docker compose run -e، وenvironment أو env_file المستوفاة، ثم المصادر الأخرى. الفكرة هي فصل متغيرات الاستيفاء عن البيئة التي تدخل الحاوية فعلياً.

افصل مرحلتي الاستيفاء والحقن

أنشئ نموذجاً من مرحلتين. أولاً يحل Compose مراجع مثل ${APP_MODE} داخل YAML باستخدام shell أو ملفات env المناسبة. ثانياً يحدد قيمة البيئة المرسلة إلى الخدمة من مفاتيح environment وenv_file وصورة الحاوية وما يمرر عبر run. توضح وثائق إعداد المتغيرات الفرق بين استخدام .env للاستيفاء وبين التصريح بالقيم داخل الخدمة. اجعل كل مرحلة تبين مدخلها ومخرجها حتى لا يعرض المختبر ترتيباً واحداً يخفي المرحلتين.

Trace لقيمة واحدة

لكل اسم متغير، اجمع المرشحين مع مواقع تعريفهم وقيمهم التجريبية. لا تخزن بيانات اعتماد أو أسرار المستخدم؛ قيم مثل MODE_A وMODE_B تكفي لإظهار التعارض. سجل ترتيب المصادر الذي استخدمته نسخة Compose، ثم ضع علامة على المصدر الفائز وبيّن بقية المرشحين كقيم تم تجاوزها. إذا كانت القيمة غير معرفة، فلا يخترع الشرح قيمة افتراضية. اعرض أيضاً اختلاف الملفات المدمجة إذا احتوى السيناريو أكثر من ملف Compose، لكن ابدأ بنطاق صغير يمكن مراجعته.

مثال من ثلاثة مصادر

ضع APP_MODE=from-env-file في ملف خدمة، وAPP_MODE=from-compose ضمن environment، وAPP_MODE=from-run في أمر تشغيل تجريبي. وفق ترتيب Docker المنشور، يعلو run -e المصادر الأخرى عند تعيينه صراحة. في سيناريو ثان، اجعل environment تستخدم ${APP_MODE} آتية من shell، ثم افصل هذه الحالة عن قيمة مكتوبة مباشرة في Compose. ينبغي أن يرى الطالب أن .env لا تدخل الحاوية تلقائياً لمجرد وجود الملف. الأسماء والقيم توضيحية، ولا تضع بيانات حساسة في التقرير أو لقطة الشاشة.

جدول حالات يثبت التفسير

اكتب fixtures تغطي run -e، قيمة environment مستوفاة من shell، قيمة environment مكتوبة مباشرة، env_file، ENV في Dockerfile، وقيمة غير موجودة. اختبر ملفي env بترتيب مختلف ثم ملف Compose فيه متغير غير معرّف. افصل تحذير الاستيفاء عن القيمة النهائية. يجب أن يذكر التقرير نسخة Compose ونظام التشغيل والدليل الذي اختير كـproject directory، لأن مصدر .env يمكن أن يتغير مع خيارات الأمر. لا تقل إن «الأعلى دائماً هو البيئة»؛ وثائق Compose تحدد ترتيباً أدق بحسب المصدر وطريقة تعريف القيمة.

اختبر التفسير مقابل تشغيل معزول

يمكن تشغيل حاوية صغيرة في بيئة محلية بلا أسرار أو شبكة إنتاج، ثم مقارنة ناتج env بالقيمة التي توقعها العارض. يجب أن تكون المقارنة اختيارية ومحدودة بمتغيرات fixtures المعلومة. اختبر أسماء مكررة وصياغة interpolation غير صالحة، وسجل ما فعله Docker فعلاً بدلاً من فرض نتيجة على الواجهة. لا تجعل المختبر يستدعي Docker على ملفات المستخدم تلقائياً، ولا تقرأ ملفات .env حقيقية؛ استورد أمثلة يكتبها الطالب يدوياً. يحدد Compose Specification سلوك حقول الخدمة، لكن يجب ربط التجربة بإصدار الأداة الفعلي.

مخرجات مناسبة لمشروع التخرج

التسليم يتكون من parser أو trace تمثيلي، مجموعة fixtures، صفحة تظهر المصدر الفائز لكل متغير، وتقرير يربط النتيجة بترتيب Compose المعتمد. يفيد هذا في مراجعة مشروع يعمل عند المطور ويفشل عند زميله بسبب اختلاف الملف أو الأمر. ينتمي العمل إلى مشاريع التخرج في هندسة البرمجيات، ويمكن تنفيذه ضمن تطوير المواقع والأنظمة. العارض لا يدير الأسرار ولا يضمن أن قيمة التطبيق سليمة منطقياً، كما لا يفسر كل إعدادات Docker. إن أضيف دعم لمصادر أخرى، حدد المصدر في الوثائق بدلاً من تعميم سلوك حالة واحدة.

اجعل أداة الشرح تتيح نسخ trace نصي صغير إلى تقرير المشروع، مع حذف القيم والاكتفاء بأسماء المصدر وترتيبه إذا كانت حساسة. في وضع المقارنة، بدّل مصدر واحداً كل مرة حتى يستطيع الطالب تحديد النقطة التي قلبت النتيجة. عند انتقال الخدمة من جهاز لآخر، سجّل أمر Compose نفسه وملف المشروع المستخدم، ولا تختصر البيئة إلى لقطة شاشة لواجهة التطبيق. يختبر ذلك قابلية إعادة التجربة: يستطيع زميل تشغيل fixture والعودة إلى المصدر الفائز نفسه. إذا اختلفت النتيجة بين نسختين من Compose، اعرض الفرق ولا تخفِه باستبدال رقم الإصدار أو تخمين ترتيب جديد.