ترحيل إلى حل مستضاف ذاتيًا من Kubernetes

تجربتي تؤكد ذلك. لقد رأيت العديد من الأعطال الغريبة الصغيرة على مر السنين لدرجة أنني دائمًا ما أحافظ على نسخ احتياطية كاملة بحيث يمكنني البدء من الصفر واستعادة الموقع. الاعتماد على إصلاح المشاكل في مكانها سيفشل بك في النهاية.

مثلك تمامًا، تركت في مأزق عندما توقفت 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.

إعجابَين (2)