لقد قمت بتوفير نقطة النهاية المذكورة أعلاه في ملف database.yml.
لقد نشرت Discourse على ECS باستخدام Docker. عند محاولة الوصول إلى التطبيق، يقوم متصفح الشبكة بجلب الموارد من الروابط أدناه بدلاً من https://discuss-stage.tllms.com/
أراهن على أن المشكلة في إعدادات CDN غير صحيحة.
هل يمكنك مشاركة ملف config/discourse.conf؟
كما يُرجى البحث في إعدادات موقعك عن c0fbtc لمعرفة ما إذا كانت هناك نتائج مطابقة.
يبدو ذلك غير صحيح. لو كنت مكانك، لفحصت ما إذا كانت قاعدة البيانات محلية بالفعل ولها اسم غريب.
أعتقد أنه يجب أن يبدو هكذا:
# عنوان المضيف لخادم قاعدة البيانات
# تم تعيينه فارغًا ليحاول استخدام المنافذ (sockets) أولاً
db_host = discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com
# اسم قاعدة البيانات التي يعمل عليها discourse
db_name = default
(يجب أن أحذرك من محاولة إعادة اختراع عجلة تعمل بشكل مثالي. كما أن بعض الأشخاص هنا لن يكونوا متحمسين لدعمك لأن ذلك لا يفيد المجتمع).
بغض النظر عن ما تفعله، يجب في النهاية التأكد من أن هذه القيم تنتهي بشكل صحيح في ملف discourse.conf. إذا قمت بتعديله يدويًا، فيجب على الأقل وضع اسم مضيف AWS في db_host وترك db_name على القيمة الافتراضية default.
أنا في نفس الفريق مع فيجا. حالة الاستخدام المحددة التي نسعى لمعالجتها هنا هي نسخ مستودع Discourse ووضعه في حساب GitHub الخاص بشركتنا. من هناك، سنبني وننشر على AWS. السبب وراء رغبتنا في وجوده في GitHub الخاص بنا هو الحفاظ على المرونة في إجراء التغييرات وفقًا لمتطلباتنا. نود المساهمة مرة أخرى حيثما كان ذلك ممكنًا. نظرًا لأننا لم نجد ملف Docker في المستودع العام لـ Discourse، فقد انتهينا بإنشاء ملفنا الخاص لبناء صورة Docker. علاوة على ذلك، نستخدم GitHub Actions لنشر Docker إلى خدمة AWS ECS.
بالنظر إلى متطلباتنا، هل تعتقد أنه كان بإمكاننا اتباع نهج آخر؟
نعم. توصيتي هي استخدام مستودعات discourse و discourse_docker الرسمية وتنفيذ جميع التغييرات كإضافات.
سيحميك استخدام مستودع discourse_docker الرسمي من مشاكل مثل تلك المذكورة في هذا الموضوع، كما أن عدم إنشاء نسخة منقحة من Discourse والاحتفاظ بجميع تعديلاتك في إضافات منفصلة سيمنعك عن الابتعاد عن الفرع الرئيسي ويوفر عليك بذل الكثير من الجهد لنقل جميع التغييرات من المصدر إلى نسختك المنقحة.
منحنى التعلم لتطوير الإضافات سيوازن الجهد المبذول في دمج التحديثات من المصدر خلال بضعة أسابيع، ومن ثم يصبح الأمر أكثر كفاءة فقط.
عند استخدام مستودع Discourse الرسمي، يمكنك أيضًا التفكير في الاستضافة المدارة، وسيكون الناس أكثر حماسًا (أو أقل تكلفة) عند الحاجة لمساعدتك.
في نهج الإضافات، هل هناك احتمال أن نواجه اختناقًا في بعض المتطلبات التي قد لا يمكن تحقيقها عبر الإضافات؟ على سبيل المثال، إدارة أدوار المستخدمين بطريقة مخصصة للغاية؟
كيف سيبدو خط الأنابيب من البداية إلى النهاية إذا اعتمدنا على discourse_docker ونشرناه في حساب AWS الخاص بنا على ECS؟ كما ذكرت، نستخدم حاليًا GitHub Actions للنشر على ECS في حساب AWS الخاص بنا. ما هي استراتيجية النشر التي يمكننا استخدامها من المستودع العام مع الحفاظ على أمان بيانات اعتماد AWS؟
ابدأ دائمًا بنسخة من مستودع discourse_docker. أنشئ ملف app.yml بداخله.
استخدم أمر التمهيد (bootstrap subcommand) في سكربت launcher في نسختك العاملة من discourse_docker لإنشاء صورة Docker. ارفع صورة Docker إلى مستودع Docker. انشر صورة Docker هذه في أي مكان تفضله.
اكتب الإضافات إذا كنت بحاجة إليها. قم بسرد الإضافات المخصصة الخاصة بك في ملف app.yml مثل الإضافات الأخرى.
@ashish_rawat@Vijay_Vantipalli كيف قمت بإعداد Discourse باستخدام Docker في ECS؟ عندما أجرب ذلك على خادم EC2، يعمل Discourse بشكل جيد. لكن عندما أدفع صورة Docker الخاصة بـ Discourse إلى مستودع ECR، وأُنشئ مهمة من هذه الصورة، لا يتم تشغيل الحاوية — أحصل فقط على كود الخروج 1. عالق في هذه المشكلة منذ أكثر من أسبوع. سأكون سعيدًا جدًا لو سمعت نصيحتكم. شكرًا لكم!
تم إنشاء مثيل RDS منفصل وعنقود ElastiCache لـ Redis لهذا الغرض.
