أعلم أن هذا ليس بالأمر السهل. لكن الغرض من الحاويات هو توفير حالة متناسقة وقابلة للنقل. لذا، إذا تم استخدام الحاويات كما ينبغي، وهي تعمل معك، فهناك فرصة جيدة جدًا أن تعمل مع كل من يستخدم تلك الحاوية.
إذا تم نقل عملية التمهيد (bootstrap) نفسها داخل الحاوية بدلاً من استضافتها على المضيف (host)، فستكون قد قطعت شوطًا طويلاً في جعلها قابلة للنقل. يمكنني إلقاء نظرة بعد أن أنهي مشاريعي الأخرى. لست خبيرًا في الحاويات أيضًا، لكنني قمت ببناء بعض منها. ومع ذلك، فإن العيب هو عدم وجود وثائق تثبيت متاحة، أليس كذلك؟ الأمر ببساطة: ها هو، فقط شغل هذا السكربت. يمكنني محاولة تكرار ما يفعله السكربت، لكن ذلك لا يترك مجالًا كبيرًا لاقتراحات التحسين.
لذا، إذا كان المجتمع، وخاصة الأشخاص المتورطون بشكل وثيق والذين يمتلكون معلومات داخلية حول كيفية عمل التثبيت، مستعدين لتقديم النصيحة أو المساعدة، فأنا مستعد لبدء هذه المبادرة. وإلا فلن تكون الجودة كما تريد رؤيتها.
ستكون الأهداف تقريبًا كما يلي:
- ملف Dockerfile يحتوي على بناء ذري للإعداد (بدون تمهيد محلي خارج الحاوية)
- عدم الحاجة لتشغيل الحاوية بصلاحيات الجذر (root)، والأفضل استخدام fakeroot وإضافة الميزات (capabilities) (هذه هي وسيطات سطر الأوامر، ويمكن للأشخاص اختيار تشغيل الحاوية بصلاحيات الجذر…)
- إنشاء سكربت نقطة الدخول (entrypoint) الذي يمكن التأثير عليه عبر متغيرات البيئة، والتي يجب توثيقها بوضوح
- يمكن استخدام
podman-generate-systemdأو ما شابه لإنشاء وحدة systemd لـ (إعادة) تشغيل الحاوية، أو تشغيل الحاوية عند بدء التشغيل (ميزة Podman، ربما يكون لدي Docker شيء مشابه، لكنه يركز أكثر على دمج هذه الوظيفة)
هذا سيكون للإعداد الأساسي. أما بالنسبة للحل القابل للتوسع، فهناك حاجة إلى حل docker-compose وحل Kubernetes. وأنا بصراحة لا أرى أن ذلك من مسؤولية مجتمع Discourse إيجاد حل واحد يناسب الجميع. لأن هذه الأمور يمكن تكييفها بدقة شديدة، خاصة على Kubernetes. لذا، أعتقد أن حل Compose أساسي سيكون كافيًا لإشراك الناس في البداية.
سيوفر هذا حلًا قابلًا للنقل وأكثر أمانًا، مما سيزيد من الاعتماد والجودة بشكل عام. وفي الوقت نفسه، سأرى ما إذا كان Discourse حقًا ما أحتاجه لمجتمعي. إذا كان كذلك، فسأستخدم نظام Ubuntu LTS حاليًا. وبمجرد أن أجد وقتًا أكثر، سأستثمر الوقت في إعداد مثل هذا النظام.