تحتاج إلى إعداد Discourse رسميًا على مجموعة Kubernetes باستخدام Helm. يبدو أن النشر الرسمي الحالي لـ Discourse يتم على جهاز EC2.
إعجاب واحد (1)
K8s غير مدعوم، وبالنسبة لمعظم الناس، فهو معقد بشكل غير ضروري. تحتاج إلى استخدام المشغل (launcher) لبناء صورة، ودفعها إلى دوكر (docker)، ثم جعل k8s يستخدم تلك الصورة. هناك مجموعة من إعدادات البيئة التي تحتاجها. تحتاج أيضًا إلى تجميع الأصول مسبقًا ودفعها إلى S3.
انظر هل يمكن لـ Discourse شحن صور Docker متكررة لا تحتاج إلى تهيئة؟.
إعجابَين (2)
أنا لا أتفق بطريقة ما على أن K8s تجعل الأمور معقدة. إنها أكثر تعقيدًا لإدارة نشر يعتمد على EC2 مقارنة بنشر يعتمد على K8s. سيصبح تصحيح EC2 معقدًا للغاية. في سيناريو حيث تكون جميع التطبيقات الأخرى على K8s، فإن الحفاظ على الخطاب على منصة مختلفة وإدارة التكامل يصبح عبئًا على فريق العمليات. لست متأكدًا من التعقيدات/القيود التي تبقي فريق الخطاب بعيدًا عن K8s خاصة عندما يكون نشر الخطاب المستند إلى EC2 أيضًا نشرًا يعتمد على الحاويات فقط.
إعجاب واحد (1)
يناقش الرابط الذي قدمته العديد من التعقيدات. لقد طوروا “مشغل” بناء الحاوية الخاص بهم قبل أن يكون docker compose مستقرًا، لذلك ستحتاج إلى استخدامه لبناء صورتك.
تحتاج أيضًا إلى ترحيل قاعدة البيانات على خطوتين عند إجراء ترقية، وهو ما لم أرَ كيف يمكن القيام به بسهولة في k8s. لقد قمت ببضع عمليات نشر k8s على GCP وساعدت في عملية أخرى على eks مدارة باستخدام terraform.
بالنسبة لشخص لا يعرف شيئًا عن إدارة الأنظمة، فإن جهازًا افتراضيًا واحدًا وحاوية واحدة سهلة الصيانة وهي الجمهور المستهدف للمستضيفين الذاتيين. إنها طريقة التثبيت الوحيدة المدعومة هنا.
توجد صورة Bitnami. إنها غير مدعومة هنا ولكنها قد تعمل معك إذا كنت لا تمانع في كونها قديمة وعدم تثبيت الإضافات. يمكنك الحصول على المساعدة بشأنها من Bitnami.
3 إعجابات