لقد كنت أقوم بتشغيل Discourse في مجموعة Kubernetes لفترة من الوقت باستخدام صورة Bitnami غير المدعومة. الآن بعد أن قامت Bitnami بإيقاف الصورة وأصبحت خلف جدار دفع، أتطلع إلى ترحيل خادمنا إلى حل مستضاف ذاتيًا على AWS.
لدي بعض الأسئلة التي سأكون ممتنًا لو تمكن المجتمع من المساعدة فيها:
نستخدم بالفعل قاعدة بيانات Postgres خارجية للتثبيت، لذا ستبقى هذه في مكانها. ومع ذلك، قمنا بتحديث بعض الإعدادات عبر واجهة المستخدم وكذلك باستخدام متغيرات البيئة التي تقوم نصوص تثبيت Bitnami بتعيينها إلى Discourse، على سبيل المثال DISCOURSE_S3_BACKUP_BUCKET يتم تعيينها إلى S3_BACKUP_BUCKET.
هل يكفي تعيين إعدادات Discourse في ملفات yaml المطلوبة أم يجب أن نستمر في استخدام متغيرات البيئة؟
إذا قمنا بعمل نسخة احتياطية من واجهة المستخدم، فما الذي سيتم استعادته فعليًا - هل يقوم بتحديث قاعدة البيانات؟
هل من الأفضل إنشاء قاعدة بيانات جديدة تمامًا بتثبيت جديد ثم إجراء نسخة احتياطية/استعادة؟
إذا كان التثبيت الجديد إصدارًا أحدث من Discourse، فهل سيسبب ذلك مشكلة إذا تم محاولة الاستعادة؟
دليل التثبيت القياسي يستخدم Docker - كيف تراقب الحاويات في بيئة إنتاجية حيث يبدو أن التثبيت القياسي هو جهاز افتراضي واحد مع Docker.
هل هناك أي مستندات تفصل عملية الترحيل وأي مشاكل محتملة؟
أنا متأكد من أن لدي المزيد من الأسئلة مع تقدم عملية الترحيل، ولكن أي نصيحة/مساعدة يمكن تقديمها ستكون موضع تقدير كبير.
إذا لم يكن هذا هو خطتك بالفعل، فسأنتقل إلى قاعدة بيانات جديدة (على نفس الخادم) للترحيل حتى لا تكسر موقعك الحالي.
لا يمكنني تحديد ما تعتقده Bitnami بالضبط، ولكن الشيء الذي تريده في متغيرات البيئة الخاصة بك هو DISCOURSE_S3_BACKUP_BUCKET. انظر تكوين موفر تخزين كائنات متوافق مع S3 لتحميل الملفات لمعرفة كيفية تعيين متغيرات S3 هذه بشكل صحيح في ملف app.yml الخاص بك.
إذا كنت تقصد بـ “أفضل” “هل هذا يعني أنني لن أكسر موقعنا الحالي وأتركه في حالة لن تعمل فيها مرة أخرى؟”، فالإجابة هي نعم.
هذا ما تريده. يجب أن يكون المكان الذي تستعيد منه بنفس إصدار النسخة الاحتياطية أو أحدث. سيقوم بترحيل قاعدة البيانات بعد استعادتها.
قد يكون هذا كل ما تحتاج إلى معرفته، ويسعدنا المساعدة هنا مجانًا. إذا كنت ترغب في الحصول على اهتمام عملي خاص بإعداداتك، يمكنك الاتصال بي أو طلب المساعدة في Marketplace.
أيضًا، خيار آخر هو بناء صور وتشغيلها في k8s. لقد فعلت ذلك عدة مرات واستخدمت github لبناء الصور.
تجربتي تؤكد ذلك. لقد رأيت العديد من الأعطال الغريبة الصغيرة على مر السنين لدرجة أنني دائمًا ما أحافظ على نسخ احتياطية كاملة بحيث يمكنني البدء من الصفر واستعادة الموقع. الاعتماد على إصلاح المشاكل في مكانها سيفشل بك في النهاية.
مثلك تمامًا، تركت في مأزق عندما توقفت Bitnami عن تقديم صور ورسوم بيانية مجانية. اضطررت إلى تكييف وترحيل العديد من عمليات النشر. كان أحدها نشر Discourse الخاص بي. إذا كان مفيدًا لك، هذا رابط إلى مخطط Helm البديل الذي أنشأته في وقت قصير جدًا (مما يعني أنه يعمل ولكنه بعيد عن التصميم المثالي). إنه محاولة لاستخدام “طريقة التثبيت الرسمية” نظرًا لأنني لم أر مخطط Helm “قياسي مجتمعي” يظهر بعد كل هذه السنوات. (أفترض أن مخطط Bitnami كان هو المعيار الفعلي، لأن قلة منا توقعت هذا التغيير المفاجئ.) على أي حال، هذا المخطط الجديد الذي أقوم بتشغيله لأحد مجتمعاتي البحثية هو في الأساس مجرد pod مع حاويتين: حاوية Docker الرسمية داخل Docker وحاوية مخصصة تستند إلى python:3، وتثبيت Docker ثم استخدام تثبيت Discourse الرسمي. نظرًا لأن جميع المكونات (خادم Discourse، Redis، PostgreSQL) تعمل في الصندوق الأسود للصورة المبنية محليًا بواسطة برنامج التشغيل النصي، فلا توجد قابلية للتوسع أو دعم للتوافر العالي. تمكنت من تقليل وقت التوقف عن العمل بسبب إعادة تشغيل الـ pod على عقدة أخرى (على سبيل المثال، عند تصريف عقدة لتحديثات نظام التشغيل أو تعطل عقدة) عن طريق استخدام docker save لـ تخزين الصورة المبنية على وحدة التخزين الدائمة، ثم تحميلها إذا لم يتم العثور على local_discourse/app:latest.
ولكن للإجابة على سؤالك، لا أعرف كيف أراقب أي شيء في هذا النشر الجديد. أنا أعمل “في الإنتاج” ولكن مجتمعي صغير بما يكفي والاستخدام معتدل بما يكفي بحيث إذا توقف المنتدى عن العمل لفترة، فلا يعد ذلك مشكلة كبيرة. حتى مع ذلك، أنا قريب جدًا من التخلي عن الاستضافة الذاتية والترحيل إلى خدمة مثل Communiteq أو Discourse.org.
