هل يمكن لأي شخص تقديم المشورة بشأن بناء صورة Docker لـ Discourse تحتوي على عدد من المكونات الإضافية مدمجة بدلاً من تثبيتها عبر واجهة المستخدم؟
الخلفية - نريد الاستفادة من أحدث إصدار من Discourse أي discourse:stable ومما قرأته في دليل التثبيت والوثائق الأخرى هو أنه يمكننا أخذ هذه الصورة كصورة أساسية في ملف Dockerfile الخاص بنا ثم القيام بشيء مثل:
RUN cd /var/www/discourse/plugins && \
git clone https://github.com/discourse/discourse-chat-integration.git
سيؤدي هذا إلى إضافة المكون الإضافي discourse-chat-integration إلى البناء. ثم في وقت التشغيل يمكننا تمرير جميع متغيرات البيئة المطلوبة، أي DISCOURSE_HOSTNAME و DISCOURSE_SMTP_DOMAIN و DISCOURSE_DB_HOST وما إلى ذلك بدلاً من ترميزها في ملف app.yml.
إذا كان بإمكان أي شخص تقديم المشورة بشأن ما سبق فسيكون ذلك محل تقدير كبير.
لا يمكنك تثبيت الإضافات من واجهة المستخدم. أنت تثبتها من ملف YML. إذا كنت تستخدم حاوية غير مدعومة بعد لم تقم ببنائها بنفسك باستخدام المشغّل (launcher)، فستفعل شيئًا مثل ما تقترحه.
لكن هذه الإضافة موجودة في النواة (core) (ولكن ربما ليست في الإصدار المستقر (stable) بعد؟).
إنها ليست مبرمجة بشكل ثابت حقًا في ملف YML. يُستخدم ملف YML لبناء وتشغيل الحاوية. يمكنك بناؤها ثم تشغيلها بنفسك، بأي طريقة تريد. يمكنك استخدام ./launcher start-cmd container-name (أو شيء من هذا القبيل، يمكنك البحث في المشغّل لترى ما إذا كنت قد أخطأت).
لذا، أعتقد أن ما تريد القيام به هو الاستمرار في استخدام المشغّل، وإضافة الإضافة، وتشغيل ./launcher bootstrap app للحاوية، ثم تشغيلها بالطريقة التي تريدها. يمكنك حتى دفعها إلى مستودع (repo) حيث يمكنك تشغيلها من جهاز آخر.
نعم، أعتقد أنه ربما لم يعد هناك إصدار مستقر، على الأقل ليس لفترة أطول. انظر RFC: A new versioning strategy for Discourse
إذًا، ما نتطلع إلى القيام به هو تشغيل Discourse في مجموعة Kubernetes الخاصة بنا ونرغب في أن نكون قادرين على بناء الصورة في سير عمل CI/CD الخاص بنا، ومن هنا جاء ملف Dockerfile المخصص. يتم بعد ذلك توفير جميع متغيرات البيئة إلى الـ pod قيد التشغيل في ConfigMap و/أو Secret. أنا أعلم أن هذا ليس تثبيتًا مدعومًا، ولكني أحاول على الأقل استخدام الطريقة المدعومة لبناء صورة Discourse لإصدار معين من Discourse حتى نتمكن من التحكم في وقت التحديث.
بالنظر إلى السكربت launcher الحالي و samples/web_only.yml، أعتقد أنه يمكنني التعليق على أقسام volumes و links حيث سيتم ذلك في Kubernetes باستخدام وحدة تخزين دائمة (Persistent Volume) وتثبيت (mount). بعد ذلك، سنضيف قيم البيئة الثابتة في web_only.yml، ونبني الحاوية باستخدام أمر التمهيد (bootstrap command)، ثم ننسخ الصورة الناتجة إلى المستودع الخاص بنا.
بالنسبة لإصدار Discourse، يمكننا مراقبة متى يتوفر إصدار جديد في Docker Hub، ثم نعدل قيمة base_image في ملف web.template.yml.
ربما، ولكن الحاوية تحتاج إلى التحدث إلى قاعدة بيانات ما لبناء الحاوية، عادةً. لا تحتاج إلى أن تكون قاعدة البيانات الفعلية (ولكن بعد ذلك تحتاج إلى ترحيل قاعدة البيانات وتجميع الأصول مسبقًا في مسار العمل الخاص بك).
قد تكون تخلط بين مسألة ترقيات Discourse وتحديثات الموارد في الحاوية الأساسية.
لقد تمكنت من بناء الحاوية بنجاح بدون خطاف db:migrate - لست متأكدًا مما إذا كانت ستعمل لأنني لم أختبرها بعد - إنها على قائمة المهام
بالنسبة لقيمة base_image - أفترض أن هذا يتغير عند إصدار صورة دوكر جديدة، لذلك أعتقد أنني سآخذ ما هو موجود في الفرع الرئيسي لأنه هو ما يتم استدعاؤه في البرنامج النصي للمُشغِّل.
شكرًا جاي. تمكنت أخيرًا من تشغيل البناء الخاص بي، حسنًا، بدأت الحاوية الصغيرة (pod) لقد قمت بتغيير عملية بناء CI/CD الخاصة بي لتشمل db:migrate باستخدام قاعدة بيانات مؤقتة.
هل تحتاج db:migrate دائمًا إلى التنفيذ عند بدء التشغيل لأن بناء الصورة سيكون مقابل قاعدة بيانات وهمية/redis؟ نهجي الحالي هو أنه سيتم إجراء db:migrate والتجميع المسبق في حاوية تهيئة (initContainer) في الحاوية الصغيرة الخاصة بي.
ستكون صورة discourse/discourse مثالية للاستخدام إذا أصبحت جاهزة للإنتاج قريبًا.
إذا كنت مهتمًا بالترقيات التي لا تتسبب في توقف الخدمة (zero-downtime upgrades)، فيجب عليك استخدام SKIP_POST_DEPLOYMENT_MIGRATIONS وبعد موت الـ pods القديمة، قم بتنفيذ الترحيل مرة أخرى باستخدام شيء مثل rake db:ensure_post_migrations db:migrate
في الوقت الحالي، أقوم بتعيين العديد من متغيرات البيئة (env vars) في النشر الخاص بنا، مثل DISCOURSE_BACKUP_LOCATION=s3، وفهمي هو أن ديسكورس سيستخدم تلك القيمة بدلاً مما تم تعيينه عبر واجهة المستخدم وبالتالي تخزينه في جدول site_settings - هل هذا صحيح؟ إذا كان الأمر كذلك، فهل تتوفر أي أدوات/نصوص برمجية تسمح لي بالتحقق من متغيرات البيئة المعينة وتحديد ما يعادلها في إعدادات الموقع؟
السبب - أنا أتطلع إلى ترحيل نسخة ديسكورس قيد التشغيل وللمساعدة في تقليل المخاطر، أردت عدم تعيين متغيرات البيئة في الوقت الحالي تحسباً لأنني قد أغفل أياً منها في النسخة الجديدة ويكون لها تأثير سلبي على النسخة الجديدة. كانت فكرتي هي أنه يمكنني التحقق مما هو معين في النسخة الحالية، وإنشاء الإعدادات ذات الصلة في الجدول، والنسخ الاحتياطي/الاستعادة إلى النسخة الجديدة، ثم إزالة متغيرات البيئة واحدة تلو الأخرى.
منطقي - ربما لا، ولكن اعتقدت أن هذا سيكون النهج الأكثر منطقية تحسباً لأن متغير بيئة في النسخة قيد التشغيل يختلف/غير مدعوم في النسخة الجديدة (قيد التشغيل = إصدار ديسكورس قديم، جديد = أحدث إصدار ديسكورس).
