بعد أن ضربت رأسي بالحائط لمدة 3 ساعات محاولاً جعل إعداد AWS S3 الخاص بي يعمل مع Discourse على مثيل AWS Lightsail، لدي اعتقاد راسخ بأن برنامجًا تعليميًا بسيطًا ومباشرًا حول هذا الأمر سيكون لطيفًا. هناك كل أنواع المتاهات التي يمكن أن تسلكها مع هذا. أعني أنه ليس لدي مشكلة في إنشاء حاوية (bucket) يمكنها سحب الملفات عن بُعد باستخدام عنوان URL الخاص بـ AWS S3 المقدم، ولكن بمجرد إحضار شبكة توصيل المحتوى (CDN)، ونقطة نهاية S3 (التي تذكر واجهة المستخدم للإعدادات بوضوح أنه يمكن تركها فارغة ولكن عند محاولة التحميل تعطي رسالة داخلية مفادها “لا يمكن أن تكون نقطة النهاية فارغة”)، والأشياء الأساسية مثل مستوى الأذونات الذي تحتاجه بالفعل إذا كنت تستخدم شبكة توصيل محتوى عبر CloudFront من أمازون.
إنه مجرد الكثير. لقد قمت بتمشيط الإنترنت ولا يوجد شيء قريب من ذلك موجود، وبالتأكيد لا يوجد شيء وجدته كان محدثًا مع Discourse اليوم.
شكرًا على أي إشارات.
أعتقد أن عقبتي الرئيسية في الوقت الحالي هي الأذونات على الأقل من منظور طلب Discourse لـ Key ID و Key Secret. لدي مستخدم في IAM لهذا الغرض ولكن لا يوجد شيء في معلومات حاويات S3 يربط هذا المستخدم بتلك الحاوية، لذا ليس لدي أدنى فكرة عما إذا كان هذا هو الانفصال. بصراحة، لقد استخدمت LightSail و AWS لأكثر من 8 سنوات، لكن منطقة S3 هذه مكتوبة بنوع من أسلوب تجربة المستخدم للمطورين (Dev UX) مع 50 طريقة مختلفة للقيام بالأشياء. ليست بديهية على الإطلاق.
مرحباً جاي. نعم، لقد نظرت في هذا الأمر عدة مرات الآن. بما أنه يعود لعام 2020، فإنه يحتوي على إعدادات مثل DISCOURSE_S3_REGION، ولكن منطقة المسؤول (admin area) لا تحتوي على مثل هذا الإعداد.
أيضاً.. ألن أقوم بـ “rake” لبياناتي القديمة بعد إعداد S3 بشكل صحيح والتحقق من أنه يعمل؟
هذا هو نوع الأشياء التي أتحدث عنها. الإعدادات في Discourse تقدم الكثير من الافتراضات حول معرفة المستخدم بـ AWS و Shell و Discourse كما يعرفها المطور.
لهذا السبب تحتاج إلى اتباع تلك التعليمات وعدم القيام بذلك في واجهة المستخدم (UX).
هذه هي التعليمات التي يجب اتباعها.
ولا تفوّت الجزء الذي تضيفه إلى ملف yml لتحميل الأصول (assets) إلى S3.
أود أن تقوم بذلك على موقع اختبار حتى لا تُفسد موقعك المباشر.
نعم. أضف إعدادات S3 إلى env في ملف yml، وأعد البناء، ثم اختبر أنها تعمل، ثم قم بتشغيل مهمة rake. يجب تعيينها هناك، وليس في قاعدة البيانات. لست متأكدًا من سبب إخفائها عن واجهة المستخدم (UX).
شكرًا لك على تلك الروابط. يحتوي الرابط الأول الذي نشرته على رابط آخر في منطقة AWS (Set up file and image uploads to S3) يعود لعام 2013، لذا أواجه على الفور مشكلة معهم يطلبون مني وضع سياسة دلو (Bucket Policy) معينة (والتي تبدو قديمة) بينما قام AWS CDN عبر Cloudfront بالفعل باستبدال السياسة بسياسة خاصة به. هل أغيرها؟ أتركها؟ هذا هو الهراء الذي أعنيه. آآآه!
ليست إعدادات “املأ الفراغ” في ملف app.yml أو إعدادات المسؤول هي المشكلة حقًا. إنها بالأحرى مزيج من كيفية تفاعل تلك الإعدادات مع الحاوية (bucket) التي تم إنشاؤها أو شبكة توصيل المحتوى (CDN)، وما إلى ذلك. لذا، فإن جانب أمازون (Amazon) هو ما يحتاج إلى بعض التوضيح. أعني أنني أتفهم، هذا ليس ديسكورس (Discourse)، ولكنه سيكون مفيدًا جدًا لمستخدمي ديسكورس (Discourse) لكي يعملوا بشكل فعال عبر S3. آمل أن يكون هذا منطقيًا.
أرى. لم أقم بإعداد دلو (bucket) في AWS منذ فترة. قد يكون هذا الجزء أكثر تعقيدًا، ولكنه ليس ما نشرته حول كيفية قيامك بذلك.
ولكن هذا أيضًا سهل ومباشر، تقوم بلصق الأشياء ثم إذا كانت لديك أخطاء يمكنك معالجتها.
هذه هي المشكلة الوحيدة التي وصفتها.
كيف قمت بإعداد الدلو؟ ما هي الأذونات التي منحتها للمستخدم؟ هل قمت بإنشاء المفاتيح؟ ما هي الأخطاء التي تلقيتها (ولكن اعتقدت أنك قلت أنك أضفت صورة إلى منشور ونجح الأمر؟)
