لماذا يعود التطبيق المُشغَّل داخل حاوية إلى التوقيت العالمي المنسق (UTC) فقط بعد تحديث الصورة؟
يمكن لتطبيق يعمل داخل حاوية أن يعود إلى التوقيت العالمي المنسق UTC بعد تحديث، عندما تحذف الصورة الجديدة بيانات المنطقة الزمنية، أو تتجاهل TZ، أو تتوقف عن استخدام تحميل المنطقة الزمنية من المضيف.
قد تظل ساعة المضيف صحيحة، بينما ينسّق التطبيق التواريخ بالتوقيت العالمي المنسق UTC، لأن الحاويات تشترك عادةً في ساعة نواة المضيف، لكنها تحمل ملفات المنطقة الزمنية وبيئتها وبيانات وقت التشغيل اللغوية الخاصة بها. وقد يؤدي تحديث الصورة إلى تبديل التوزيعات الأساسية، أو إزالة tzdata، أو غيّر مستخدم التطبيق، أو استبدل نقطة الدخول، أو توقّف عن احترام إعداد خاص بالمورّد TZ المتغير. قارن الصورة القديمة بالجديدة قبل تغيير المنطقة الزمنية للمضيف.
افصل بين وقت ساعة النظام وتنسيق المنطقة الزمنية
سجّل التوقيت العالمي المنسق، والوقت المحلي المنسّق، واسم المنطقة الزمنية، والإزاحة الرقمية، والوقت الذي يعرضه التطبيق نفسه داخل الحاويتين القديمة والجديدة.
توضح مكتبة GNU C أن متغير TZ يتحكم في تحويل الوقت المحلي، بينما تظل ساعة النظام الأساسية مصدرًا للوقت المطلق.
إذا تطابق وقت العصر، لكن تغيّرت المنطقة المنسّقة، فالمشكلة تتعلق بإعدادات المنطقة الزمنية لا بانجراف الساعة أو بروتوكول NTP.
تحقّق مما إذا كانت الصورة الجديدة لا تزال تحتوي على tzdata
قارن الحزم المثبّتة، /usr/share/zoneinfo, /etc/localtime، و /etc/timezone بين وسمَي الصورة السابق والحالي.
توفر حزمة tzdata في Debian تعريفات المناطق الزمنية التي تستخدمها التطبيقات لتحويل التوقيت العالمي المنسق UTC إلى التوقيت المحلي الإقليمي.
قد تتعمد صورة بديلة مصغّرة حذف هذه الحزمة. ثبّتها في صورة مشتقة أو استخدم آلية المنطقة الزمنية التي يدعمها التطبيق بدلًا من تعديل حاوية قيد التشغيل يدويًا.
تحقّق من كيفية تطبيق التوزيعة الأساسية للمنطقة الزمنية
حدّد ما إذا كانت الصورة مبنية على Debian أو Ubuntu أو Alpine أو distroless أو أساس آخر. لا تفترض ذلك TZ له التأثير نفسه في كل صورة.
توضّح وثائق Alpine Linux إعداد المنطقة الزمنية عبر tzdata وzoneinfo.
إذا غيّر التحديث الصورة الأساسية، فأعد إعداد المنطقة الزمنية باستخدام الطريقة المدعومة في ذلك التوزيع. قد يؤدي نسخ ملف واحد من الحاوية القديمة إلى ترك قواعد التوقيت الصيفي قديمة.
افحص عملية ربط localtime من المضيف
قارن عمليات الربط في الحاوية قيد التشغيل قبل إعادة الإنشاء وبعدها. تحقّق مما إذا كان /etc/localtime أو لا يزال ملف zoneinfo مربوطًا للقراءة فقط.
تربط عمليات الربط من Docker ملفًا أو دليلًا محددًا من المضيف داخل الحاوية. توضّح إرشادات الربط الرسمية سبب عودة الحاوية الجديدة إلى الإعداد الافتراضي للصورة عند إزالة عملية ربط من Compose أو تغيير مسار المصدر.
لا تربط نظام الملفات الكامل للمضيف /etc الدليل. استخدم الملف المدعوم المحدد أو إعداد المنطقة الزمنية الصريح الذي يتطلبه التطبيق.
تحقّق من قاعدة بيانات المناطق الزمنية الخاصة ببيئة تشغيل التطبيق
حدّد ما إذا كان التطبيق يستخدم قاعدة بيانات zoneinfo الخاصة بنظام التشغيل أو يضمّن بيانات المنطقة الزمنية داخل Python أو Java أو PHP أو Node.js أو بيئة تشغيل أخرى.
تبحث وحدة zoneinfo في Python عن بيانات النظام أو عن حزمة tzdata.
لذلك قد يعرض التطبيق التوقيت العالمي المنسق حتى عندما تُظهر أوامر الصدفة المنطقة الزمنية الصحيحة. قارن سلوك التطبيق أثناء التشغيل بشكل منفصل عن صدفة الحاوية.
تحقّق من أولوية متغيرات بيئة Compose بعد إعادة الإنشاء
افحص البيئة النهائية للحاوية المُعاد إنشاؤها وقارنها بعملية استيفاء Compose، البيئة, env_fileوعلى الإعدادات الافتراضية للصور.
تشير وثائق الحاويات من Red Hat إلى أن إعدادات التشغيل قد تتجاوز بيئة الصورة، ولذلك قد تنتج صورة محدّثة وملف نشر قديم قيمة نهائية مختلفة عما هو متوقع.
اقرأ البيئة الفعلية للحاوية بدلًا من الاكتفاء بملف Compose. قد تكون واجهة مكدس قديمة أو ملف بيئة بديل قد أعاد إنشاء الخدمة من دون متغير المنطقة الزمنية المقصود.
ثبّت الإعدادات واختبر عبر تحديث آخر
اختر طريقة واحدة مدعومة للمنطقة الزمنية، وثبّتها في إعدادات النشر الخاضعة للتحكم في الإصدارات، وأعد إنشاء الحاوية، ثم تحقّق من تواريخ الشتاء والتوقيت الصيفي حيثما ينطبق.
توفّر مقالة ZimaSpace حول وقت مهام الحاوية والبيئة حدودًا تشخيصية ذات صلة بالجداول التي تتغير عند تغيير إعدادات وقت الحاوية.
تُحل المشكلة عندما يستخدم التطبيق والصدفة والسجلات والمهام المجدولة المنطقة الزمنية المقصودة بعد إعادة التشغيل، ثم إعادة إنشاء الصورة بطريقة محكومة مرة أخرى.
الأسئلة الشائعة
هل للحاويات ساعة عتادية خاصة بها؟
لا. عادةً ما تتشارك الحاويات ساعة نواة المضيف، لكنها قد تنسّق ذلك الوقت باستخدام بيانات مناطق زمنية وإعدادات بيئية مختلفة.
هل يكفي ضبط TZ دائمًا؟
لا. يجب أن تدعم الصورة والتطبيق المتغير، وأن يتوفّر لهما الوصول إلى قواعد بيانات المناطق الزمنية. تستخدم بعض بيئات التشغيل قاعدة بيانات مضمّنة منفصلة.
هل ينبغي أن أغيّر المنطقة الزمنية لمضيف NAS لإصلاح حاوية واحدة؟
لا. صحّح أولًا إعدادات الحاوية أو التطبيق؛ فقد يؤثر تغيير المضيف في السجلات والجداول الزمنية وكل خدمة أخرى.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
لماذا تؤدي استعادة وحدة تخزين Docker إلى إعادة إنشاء محتويات الملفات مع فقدان السمات الموسّعة؟
تشخيص لاستعادة وحدة تخزين يغطي جرد السمات الموسَّعة (xattr)، وخيارات tar وRsync، ومساحات الأسماء، ودعم الوجهة، والامتيازات، والتسميات، والبيانات الوصفية للتطبيق، والاختبارات.
لماذا يحتفظ الحاوي قيد التشغيل بحد الذاكرة القديم بعد تغيير ملف Compose؟
تشخيص لحدود الذاكرة يغطي مجموعات cgroups النشطة، وإعادة التشغيل مقابل إعادة الإنشاء، وحقول Compose، والحدود الصارمة والمرنة، والنطاقات الأصلية، وذاكرة التبديل، وأكوام الذاكرة في...
لماذا يؤدي إعادة تشغيل وكيل عكسي إلى إبطال كل جلسة في تطبيق مستضاف ذاتيًا واحد؟
تشخيص لفقدان الجلسة يشمل نطاق إعادة التشغيل، وملكية ملفات تعريف الارتباط، وتدوير الأسرار، والجلسات المدعومة بالتخزين المؤقت، والتوجيه الثابت، وبوابات المصادقة، والاسترداد.
