أقوم حاليًا بتشغيل Discourse فوق Clear Linux، لذا فهو ليس نظامًا أساسيًا قياسيًا تمامًا، ولكني رأيت نفس السلوك مع تثبيت Discourse على Debian أيضًا. في النظام الحالي، قمت بتسجيل الدخول باستخدام حساب المستخدم الخاص بي rahim12 وقمت بتشغيل sudo su قبل تثبيت وتكوين كل ما يتعلق بحاوية Discourse. وفي اختباراتي السابقة على Debian، قمت بتسجيل الدخول إلى النظام مباشرة بصفتي root. فهل من الطبيعي أن تعمل بعض العمليات مثل عمال Unicorn تحت حساب المستخدم العادي الخاص بي، وكيف عرفوا استخدامه؟ هل يتم تشغيلها تلقائيًا تحت معرف المستخدم (UID) في لينكس 1000؟
إنها سمة غريبة في طريقة عمل Docker.
المستخدم discourse داخل الحاوية لديه UID 1000، لذلك إذا نظرت إلى قائمة العمليات خارج الحاوية، فستظهر أي مستخدم هو UID 1000.
في حالتي، ستظهرهم باسم claudia لأن هذا هو اسم المستخدم الذي تستخدمه جميع خوادمي لـ UID 1000.
وقد وقعت في هذا الخطأ عدة مرات لأن لدي على أحد خوادم التطوير المحلية الخاصة بي حاوية Docker تحتوي على عمليات تعمل بصلاحيات المستخدم 1001 (اسم المستخدم الداخلي للحاوية هو WebDev) وعلى نظام التشغيل المضيف، يظهر حساب تم تعطيله منذ عام 2019 ولكنه لا يزال بحاجة إلى الوجود لأسباب تاريخية.
شكراً جزيلاً على هذا الشرح، إنها بالفعل ميزة غريبة جداً في Docker. بصفتي مسؤول نظام Linux تقليدي معتاد على تثبيت وتكوين كل مكون في المكدس يدوياً، لست مرتاحاً تماماً لنموذج الحاويات الغامض وسكربتات الإعداد الآلية التي تسحب التبعيات والتكوينات من مليون مصدر مختلف. ولكن من الصعب الاعتراض على سرعة وقابلية تكرار نشر Discourse وخادم البريد المعبأ في حاويات الذي أقوم بتشغيله، لذلك لست متذمراً.
ربما كان ينبغي لي أن أذكر أن هذه سمة خاصة بـ Docker لأنها سمة خاصة بـ حاويات Linux بشكل عام.
في الأساس، هي مشابهة لـ *BSD jails، ولكنها في الواقع أكثر صرامة بكثير في كيفية عزل الأشياء.
شخصيًا، لست من محبيها، لكنني أفهم تمامًا لماذا تستخدم Discourse حاويات Docker. العزل يجعل من الصعب جدًا على تغييرات المضيف التأثير على Discourse. في الواقع، باستثناء تحديث للنواة كسر Docker لفترة وجيزة في الماضي، لم يحدث لي أبدًا أن كسر ترقية المضيف Discourse.
