لماذا تستخدم خدمة Compose ملف البيئة الخاطئ فقط بعد إعادة تشغيل المضيف؟
قد تستخدم خدمة Compose قيماً مختلفة للبيئة بعد إعادة التشغيل عندما يحلّل المشغّل وقت الإقلاع دليلاً آخر للمشروع أو ملف بيئة آخر أو مصدراً مختلفاً للأولوية.
قد يُنفَّذ الأمر اليدوي من المجلد المقصود باستخدام بيئة صدفة معينة، بينما يبدأ systemd أو مجدول NAS أو Portainer ملف Compose نفسه من سياق آخر بعد الإقلاع. وقد يعيد أيضاً تشغيل حاوية موجودة ثُبّتت بيئتها عند إنشائها، بدلاً من إعادة قراءة الملف المعدّل. قارن نموذج Compose المُنشأ وبيئة العملية قيد التشغيل بين المسار اليدوي ومسار الإقلاع قبل تعديل عدة ملفات دفعة واحدة.
قارن البيئة قيد التشغيل بالملف المقصود
سجّل معرّف الحاوية ووقت الإنشاء والصورة وتسميات Compose واسم المشروع والقيم الفعلية الظاهرة داخل العملية الرئيسية. قارنها بملف البيئة المقصود من دون طباعة الأسرار في سجلات مشتركة.
تكشف بيئة العملية في Linux القيم المزوّدة وقت التنفيذ، وهي أدلة أقوى من قراءة ملف بيئة ربما لم تستخدمه الحاوية الحالية مطلقاً.
إذا كانت الحاوية تحتوي على القيم القديمة ويسبق إنشاؤها النشر الذي يحدث وقت إعادة التشغيل، فقد تكون الخدمة قد أعادت تشغيلها فقط. أما إذا كانت الحاوية جديدة، فتابع فحص الأولوية وحلّ المسارات.
طبّق أولوية بيئة Compose بالترتيب الصحيح
احصر كل مصدر لمتغير غير حساس واحد: أعلام CLI وقيم الصدفة وenvironment: وenv_file: و.env الافتراضي أو المحدد صراحةً وENV في الصورة.
يحدد Docker ترتيباً رسمياً لأولوية متغيرات البيئة، لذلك قد يخسر ملف بيئة صحيح أمام قيمة أعلى أولوية يحقنها نظام الإقلاع أو مدير الحزمة.
لا تبحث فقط عن أسماء ملفات مكررة. ابحث عن اسم المتغير في نموذج Compose المُنشأ وملف الوحدة وإعدادات المدير وبيئة الصدفة والقيم الافتراضية للصورة.
تحقق من دليل المشروع ومسارات ملفات البيئة النسبية
قارن دليل العمل المستخدم في الأمر اليدوي بدليل العمل المستخدم في مشغّل الإقلاع، وبوسائط ملفات Compose ودليل المشروع ومرجعيات env_file النسبية.
تحدد مواصفة Compose نموذج التطبيق المستخدم لحل الخدمات والإعدادات، لذا فإن تعريف المشروع المحدد ومساراته مدخلات للنشر، وليست خصائص يعاد اكتشافها من الحاوية قيد التشغيل.
استخدم مسارات مطلقة لملفات البيئة الضرورية للإقلاع عندما تتيح أداة النشر ذلك، أو عيّن دليلاً صريحاً للمشروع ودليل عمل واضحاً حتى تحل عمليات التشغيل اليدية والآلية الملفات نفسها.
افحص دليل العمل وملفات البيئة في systemd
اقرأ الوحدة الفعلية وجميع ملفات التجاوز وWorkingDirectory= وEnvironment= وEnvironmentFile= وExecStart=. قارن الوحدة المحمّلة عند الإقلاع بالأمر المستخدم يدوياً.
تحدد إعدادات تنفيذ systemd دليل عمل الخدمة وملفات البيئة، وهي لا ترث تلقائياً الدليل الحالي أو المتغيرات المُصدّرة من صدفة تسجيل الدخول التفاعلية.
بعد تغيير وحدة أو ملف تجاوز، أعد تحميل مدير systemd وافحص الوحدة الفعلية مرة أخرى. فتعديل قالب أو ملف غير مستخدم لا يغيّر الخدمة التي تبدأ فعلياً.
تحقق من متغيرات مدير الحزم وحالة النشر المخزّنة
إذا كان Portainer أو واجهة NAS يدير الحزمة، فقارن المتغيرات المحفوظة وملف البيئة المُحمّل ومسار النشر من Git وسلوك تحديث webhook ونموذج Compose المعروض.
يميز Portainer بين سلوك .env وstack.env، لذلك قد تختلف القيم المُدخلة في المدير عن ملف عُدّل مباشرة على المضيف.
اختر مصدراً واحداً للحقيقة. فلا ينبغي أن تُدار حزمة من Git أو محرر ويب، ثم تُشغّل يدوياً أيضاً من نسخة محلية أخرى بعد كل إعادة تشغيل.
أعد إنشاء الحاوية بدلاً من إعادة تشغيلها فقط
قارن وقت إنشاء الحاوية بوقت تعديل ملف البيئة. أنشئ إعداد Compose المقصود، ثم نفّذ إعادة إنشاء مضبوطة للخدمة المتأثرة فقط.
توصي إرشادات systemd من Red Hat بفحص الملفات والتجاوزات التي تستخدمها الخدمة فعلياً قبل إعادة تشغيلها، لتجنب أن تعيد وحدة قديمة أو غلاف تشغيل إنشاء الحاوية بقيم قديمة.
لا تعيد إعادة تشغيل الحاوية بناء بيئتها من Compose. أعد إنشاءها فقط بعد حماية البيانات الدائمة والتأكد من أن النموذج المُنشأ يشير إلى وحدات التخزين والأسرار المقصودة.
اجعل التشغيل اليدوي والإقلاع وإعادة النشر تنتج النموذج نفسه
ثبّت ملفات Compose واسم المشروع ودليل المشروع ومسار ملف البيئة والجهة المالكة للحزمة وتبعية الإقلاع. احفظ إعداداً مُنشأً بعد حجب الأسرار وبصمة بيئة غير حساسة.
تقدم مقالة ZimaSpace حول نطاق النسخ الاحتياطي لـ Docker القاعدة المكملة: يجب حفظ ملفات البيئة وتعريفات النشر مع الحالة الدائمة.
تُحل المشكلة عندما تؤدي إعادة إنشاء يدوية وإعادة تشغيل المضيف وتحديث مجدول وإعادة نشر من مدير الحزمة جميعاً إلى إنشاء الخدمة ببصمة البيئة نفسها بعد حجب الأسرار.
الأسئلة الشائعة
ما الفرق بين .env وenv_file؟
يُستخدم ملف .env الخاص بالمشروع عادةً لتوفير قيم الاستبدال إلى Compose، بينما يزوّد env_file الخاص بالخدمة الحاوية بالمتغيرات. ويعتمد تفاعلهما وأولويتهما على نموذج Compose الكامل.
هل تؤدي إعادة تشغيل الحاوية إلى إعادة تحميل ملف بيئة تغيّر؟
لا. تُحدَّد قيم البيئة عند إنشاء الحاوية. ويجب عادةً إعادة إنشاء الخدمة من إعداد Compose المصحح.
لماذا تظهر المشكلة بعد إعادة التشغيل فقط؟
قد يستخدم مسار إعادة التشغيل وحدة systemd أو مجدولاً أو متغيرات مخزّنة في المدير أو دليلاً آخر للعمل أو نسخة Compose أقدم تختلف عن التشغيل اليدوي.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
لماذا تؤدي استعادة وحدة تخزين Docker إلى إعادة إنشاء محتويات الملفات مع فقدان السمات الموسّعة؟
تشخيص لاستعادة وحدة تخزين يغطي جرد السمات الموسَّعة (xattr)، وخيارات tar وRsync، ومساحات الأسماء، ودعم الوجهة، والامتيازات، والتسميات، والبيانات الوصفية للتطبيق، والاختبارات.
لماذا يحتفظ الحاوي قيد التشغيل بحد الذاكرة القديم بعد تغيير ملف Compose؟
تشخيص لحدود الذاكرة يغطي مجموعات cgroups النشطة، وإعادة التشغيل مقابل إعادة الإنشاء، وحقول Compose، والحدود الصارمة والمرنة، والنطاقات الأصلية، وذاكرة التبديل، وأكوام الذاكرة في...
لماذا يؤدي إعادة تشغيل وكيل عكسي إلى إبطال كل جلسة في تطبيق مستضاف ذاتيًا واحد؟
تشخيص لفقدان الجلسة يشمل نطاق إعادة التشغيل، وملكية ملفات تعريف الارتباط، وتدوير الأسرار، والجلسات المدعومة بالتخزين المؤقت، والتوجيه الثابت، وبوابات المصادقة، والاسترداد.
