كل شيء يعمل بشكل صحيح. إذا أضفت صورة إلى المجلد الرئيسي للدلو، يمكنني استرجاعها عبر عنوان URL المخصص الخاص بي، أي أن http://forum-storage.com/test.jpg يعيد الصورة مع رؤوس CloudFlare.
ثلاثة أسئلة بسيطة…
#1
الآن أحتاج إلى إخبار Discourse باستخدام هذا العنوان الجديد كدلو S3 الخاص بي. ماذا أضع في هذه الحقول الثلاثة؟
لدي حاليًا صور في منشورات المنتدى موجودة على دلو S3 آخر، ولدي أيضًا صور مخزنة محليًا. (عناوين URL لصورنا مبعثرة في كل مكان.)
بمجرد إجراء التغييرات الصحيحة (أعلى)، فهذا يعني أن جميع الوسائط الجديدة المضافة إلى المنتدى ستذهب إلى الدلو الجديد، لكن الصور الموجودة لن يتم نقلها، وستستمر في الوصول إليها من حيث توجد حاليًا، صحيح؟
#3
الآن بعد أن يعمل هذا لجميع الصور من هذه النقطة فصاعدًا، كيف يمكنني إخبار Discourse بنقل جميع الصور القديمة التي ليست في هذا الدلو الجديد إلى الدلو الجديد (وإعادة معالجة المنشورات حسب الحاجة)؟
الهدف هو وضع كل شيء في دلو واحد، هذا الدلو الجديد خلف شبكة توصيل المحتوى (CDN).
حسناً، هذا جيد، لكنك ترغب في وجود شبكة توصيل محتوى (CDN) مثل CloudFront أمام الدلو (bucket)، والتي ستستقبل اسم النطاق المخصص (CNAME)، لذا فإن هذه الميزة ليست مفيدة حالياً.
عدم وجود شبكة توصيل محتوى (CDN) سيؤدي إلى نفس الفاتورة الباهظة لنقل البيانات.
حسناً. أعتقد أننا على نفس الصفحة؟ للتوضيح أكثر، كما أفهم الأمر، هناك ثلاثة طرق للربط بين Discourse و S3:
استخدام Discourse لخدمة S3 السحابية مباشرة. الميزة: إعدادها سهل للغاية. العيب: تصبح التكلفة مرتفعة بسرعة.
استخدام Discourse لخدمة S3 السحابية عبر نطاق مخصص (مثل forum-storage.com) لتمكين استخدام شبكة توصيل المحتوى (CDN). المزايا: إعدادها سهل جداً مع S3 إذا تطابق اسم الدلو تماماً مع النطاق المخصص (أي forum-storage.com.s3-amazon-aws.com). العيوب: مشاكل في شهادة SSL.
استخدام Discourse لخدمة S3 السحابية عبر نطاق مخصص (مرة أخرى، لتمكين استخدام CDN)، ولكن إعداد دلو S3 بحيث لا يحتوي على نقطة إضافية في الاسم (أي forum-storage-com.s3-amazon-aws.com). المزايا: شهادة SSL تعمل بشكل صحيح. العيوب: الإعداد مع خدمة Amazon S3 ليس سهلاً.
لذا… كنت أستخدم الخيار رقم 1 حتى وصلتني الفاتورة ثم تعلمت أن الخيار رقم 2 متاح وقمت بإعداده، ثم بدأت هذا الموضوع، وتعلمت فوراً أن الخيار رقم 2 ليس خياراً واقعياً في الحقيقة.
الآن أعمل على الخيار رقم 3. أعتقد أنني مضطر لاستخدام خدمة DNS الخاصة بـ Amazon “Route 53” أو ما شابه. ما زلت أترنح في فهم التفاصيل. كل ما أجده عبر البحث في Google هو معلومات حول كيفية تنفيذ الخيار رقم 2، لكن لا يبدو أن أحداً قد كتب تعليمات واضحة للخيار رقم 3.
أضفت سجل CNAME يشير إلى عنوان URL الخاص بـ <long id>.cloudfront.net لتوزيع شبكة Cloudfront CDN في إعدادات DNS الخاصة بـ bokeh.org (والتي تستضيفها Cloudflare في حالتنا، لكن هذا لا يجب أن يهم).
كمرجع، لا تحتوي سلة S3 الخاصة بنا على أي نقاط في الاسم، لكنني أيضًا لا أتذكر أي مشاكل محددة في إعداد شبكة CDN بسبب ذلك (أو أي مشاكل في إنشاء السلة، فهي تحتاج فقط إلى اسم فريد).
هذا، بلا شك، أكثر شيء محبط على الإطلاق. لا أستطيع، مهما حاولت، أن أفهم كيف أربط بين دلو Amazon S3 (بدون نقطة في اسم الدلو!)، ونطاق مخصص، وCloudFlare لجعلها جميعًا تعمل معًا. لو كان بإمكاني وضع نقطة في اسم الدلو، لما كانت هناك مشكلة. لكن في الوقت الحالي، الأمر محير للغاية. أوه! هل يمكن لأحد المساعدة أو توجيهي نحو طريقة بسيطة لإعداد CloudFlare مع دلو S3 لا يحمل نفس اسم النطاق؟
لقد جربت معلومات StackPath المذكورة أعلاه — أعتقد أنني فعلت شيئًا مشابهًا في CloudFlare، لكنني غير متأكد. لم ينجح الأمر. حاولت قراءة معلومات CloudFlare حول كيفية إضافة CDN إلى دلو Amazon، لكن بالطبع، يريدون أن يكون اسم الدلو مطابقًا لاسم النطاق، وهو ما قيل لي أنه فكرة سيئة جدًا ولا يمكنني فعله.
يبدو أن الأمر كله يختزل في:
إذا كان اسم الدلو مطابقًا لاسم النطاق (مع وجود نقطة)، فإن Amazon S3 سيتولى الأمر كله نيابةً عني، رائع ومذهل، لكنه يتسبب في مشاكل مع SSL، لذا لا يجب أن أفعل ذلك.
إذا لم يتطابق اسم الدلو مع اسم النطاق، فإن كل شيء يصبح أكثر تعقيدًا بشكل هائل، ولا أستطيع حله.
هل يمكن لأحد المساعدة أو تقديم المشورة؟ وفي غضون ذلك، أتلقى فواتير بقيمة 100 دولار أو أكثر كل شهر مقابل تخزين S3 الخاص بي. هذا مزعج للغاية. هل يمكنني دفع 200 دولار الآن لحل كل هذه المشاكل؟ يا له من إزعاج.
هل قرأت هذا بعد؟ لقد واجهت صعوبة في إعداد S3 و Cloudflare أيضًا، لكنني تمكنت من حلها في النهاية. يمكنك ما زال استخدام Cloudflare للحصول على ميزة الأمان، لكنني متأكد تقريبًا من أنك بحاجة إلى خدمة CDN منفصلة أيضًا. فـ Cloudflare ليست مثل شبكة CDN عادية، بل تعمل بشكل مختلف. يجب عليك الانتقال إلى خدمة S3 أرخص، فـ Amazon مكلفة.
استخدام Cloudflare لتخزين مؤقت لـ S3 bucket يتطلب التلاعب برأس المصدر (origin header) في الطلبات. تتوفر هذه الميزة في خطة Enterprise من Cloudflare، لذا قد يكون استخدام CDN آخر أسهل.
أليس وجود نقطة في اسم الدلو غير ذي صلة إذا كان سيتم تخزين الصور مؤقتًا عبر CDN على أي حال؟ الشيء الوحيد المهم هو الحصول على شهادة جيدة تغطي الصورة المقدمة عبر Cloudflare. أعتقد أنه يحتاج إلى التركيز على خوادم Cloudflare و DNS والشهادة لتغطية هذه الأمور. لا أعتقد أن المستخدم أو المتصفح سيعرفان أبدًا أن مصدر هذه الصور هو دلو S3. هل سيقوم Cloudflare بتخزين الصورة مؤقتًا أو代理ها بنفسه؟
@riking كل ما يتطلبه Discourse هو اسم bucket، أليس كذلك؟ يمكن إجراء الرفع والإدارة عبر عناوين URL الخاصة بـ AWS مع شهاداتها، إذا كان HTTPS مطلوبًا حتى. حتى الآن، هل هناك أي سبب يجعلنا نتحدث عن شهادات الأمان؟
يمكن لصاحب المنشور (OP) بعد ذلك أن ينظر بشكل منفصل في ما يحتاجه للسماح لشبكة توصيل المحتوى (CDN) أو حل التخزين المؤقت لديه بجلب الصور من S3. سواء كان ذلك آمنًا أم لا، لا يهم ما لم يكن لصاحب المنشور أو لشبكة CDN متطلبات، أليس كذلك؟ هل يهتم Discourse بإعداداته بين S3 وCDN؟
أخيرًا، يجب على صاحب المنشور التأكد من أن الصور تُقدَّم عبر شبكة CDN بشهادة صالحة. هل لهذا أي علاقة بـ Discourse بخلاف أن صاحب المنشور سيوفر عنوان URL الأساسي للصور التي ستُستضاف في النهاية؟ بمجرد أن تقوم شبكة CDN أو ذاكرة التخزين المؤقت لديه بجلب الصور من S3، فإن AWS وbuckets وما إلى ذلك تختفي تمامًا من الصورة.
أدرك أن هناك مشاكل تتعلق بنقطة في أسماء buckets S3 إذا كنت تنوي تقديم صورك من هناك، لكن صاحب المنشور لا يفعل ذلك. لذا فإن الأمر يقتصر على صاحب المنشور اختيار أي اسم bucket يقبله Discourse، طالما أنه لا يتعارض مع أي إعداد لديه مع شبكة CDN.
على الرغم من إمكانية تجنب عناوين URL التي تحتوي على bucket في النطاق، إلا أنها لا تُتجنب فعليًا بسبب طريقة استخدام مكتبة AWS S3 SDK وصعوبة تكوينها.
مرة أخرى، تتجاوز هذه العمليات شبكة CDN، والطريقة الوحيدة لإصلاحها هي في مصدر Discourse. يمكن إصلاحها، لكنها لم تُصلح حاليًا. كما أن العديد من المشكلات لا تحدث في المسار الحرج، وتظهر فقط لاحقًا. لذا، حتى يتغير هذا الوضع، لا تستخدم أسماء buckets تحتوي على نقاط.
لذا، دعنا نلخص الأمر ببساطة فائقة… كان سؤال الشخص الأصلي (OP) حول ما يجب إدخاله في ثلاثة إعدادات للتكوين:
(1) اسم الدلو (BUCKET NAME) — إذن يُقال إن النقاط غير… موصى بها؟ أم ممنوعة؟ أظن أن هذا قد لا يمثل مشكلة للشخص الأصلي. (فإنه يحتاج فقط إلى إيجاد طريقة منفصلة لجعل شبكة تسليم المحتوى (CDN) لديه تقوم بتخزين الصور وتقديمها). إذن نحن جميعًا على نفس الصفحة، أليس كذلك؟
(2) نقطة نهاية S3 (S3 ENDPOINT) — اتركها فارغة، لا حاجة لأي شيء إذا كان يستخدم AWS، وإلا فيمكنه ملء هذه الخانة لمزود آخر؟
(3) عنوان CDN الخاص بـ S3 (S3 CDN URL) — هل هذا ببساطة هو العنوان الأساسي الذي سيقوم Discourse بإضافته قبل مسار الصورة؟ إذا كان الأمر كذلك، فإن ذلك بسيط ومباشر، ويمكن للشخص الأصلي إعداد شبكة تسليم المحتوى (CDN) الخاصة به وتقديم ذلك العنوان الأساسي هنا.
لا أرى كيف تدخل شهادات SSL الواسعة النطاق (wildcard certificates) في هذا السياق. فقد قيل للشخص الأصلي إن النقطة في إعدادات Discourse سيئة لأنها ستعطل شهادته. ولكن إذا كان يستخدم شبكة تسليم محتوى (CDN) أو ذاكرة تخزين مؤقت، فقد يكون اسم الدلو غير ذي صلة بالشهادة تمامًا، أليس كذلك؟ وإذا كان سيؤدي ذلك إلى تعطيل Discourse بطريقة أخرى، فسيكون من المفيد معرفتها.
لست متأكدًا من أنني أتابع كل هذا عن كثب، لكن ربما يساعدنا التوسع قليلاً في رؤية الصورة الأوسع، وقد تكون هذه المجموعة البسيطة من المتطلبات مفيدة:
الأهداف:
عدم تخزين صور Discourse الخاصة بي على خادم Discourse الخاص بي.
وجود حاوية S3 لتخزين الصور (يجب أن تكون S3 لأن هذا ما يدعمه Discourse).
تجنب تكاليف S3 الباهظة.
لا يُعد وجود شبكة توصيل محتوى (CDN) مطلبًا إلزاميًا، لكنه ميزة إضافية محتملة قد تساعد في تقليل (أو تكون الطريقة الوحيدة للتخلص من) تكاليف S3 الباهظة، كما يوفر توفرًا أفضل على مستوى العالم، ونسخة احتياطية في حال تعطل الخادم الرئيسي، وما إلى ذلك.
يرجى تصحيح أي خطأ قد يكون في ما سبق
القيود/المتطلبات:
يجب أن يدعم مخزن الصور الخارجي بروتوكول S3 (لأن هذا ما يعمل به Discourse)، ولكن من الناحية الدقيقة، لا يشترط أن يكون S3 من أمازون.
يتطلب Discourse أن لا يحتوي اسم حاوية S3 على نقاط.
يجب أن يخدم مصدر الصور (سواء كان S3 أو CDN) عبر https://، لأن المتصفح سيشكو إذا كانت الصفحة مشفرة بـ https بينما الصور ليست كذلك.
يرجى تصحيح أي خطأ قد يكون في ما سبق
الحلول:
في السابق، كنت أقوم بتقديم الصور مباشرة من Amazon S3. كان يعمل بشكل ممتاز، باستثناء أن تكاليف Amazon مقابل DataTransfer-Out-Bytes كانت باهظة للغاية. هذا أدى إلى فواتير شهرية مرتفعة من Amazon! لذا قمت بنقلها مرة أخرى إلى الخادم الرئيسي. هناك حلان محتملان لهذه المشكلة: وضع شبكة توصيل محتوى (CDN) أمام حاوية Amazon S3 بحيث تتولى الشبكة نقل جميع البيانات، و/أو الانتقال إلى مزود S3 آخر.
حاولت وضع شبكة CloudFlare CDN فوق حاوية Amazon S3، لكنني واجهت بسرعة العديد من المشاكل التي لم أستطع حلها.
خيار آخر؟
كنت أبحث للتو في عرض التخزين المتوافق مع S3 من Digital Ocean. يحتوي على CDN مدمج (غير متأكد تمامًا مما يعنيه ذلك بالضبط لكنه يبدو واعدًا)، مع أسعار معقولة. هل سيؤدي هذا العمل مع Discourse؟
كمرجع، قمت بتقديم حوالي 300 جيجابايت من S3 خلال الـ 30 يومًا الماضية. جزء من ذلك هو نسخ احتياطية للموقع، والكثير منه صور ثابتة. من الصعب جدًا عليّ فرز كيفية قياس هذه الأشياء في Amazon… واجهة تقارير الفواتير الخاصة بهم - مثل كل شيء آخر في Amazon AWS - مربكة للغاية للإدارة.
قد يكون الحل الأقل تكلفة هو كيفية إعداد BackBlaze S3 مع BunnyCDN. لقد كنت راضيًا عن BackBlaze في اختباراتي الأولية للنسخ الاحتياطي، لكنني لم أجربه بعد للuploads.
لقد انشغلنا بشكل مفرط بنقطة في اسم الدلو وشهادات المتصفح، لكنني أعتقد أن كل هذا النقاش غير ذي صلة تماماً. أي شبكة توصيل محتوى (CDN) ستسمح بتكوين HTTPS، لذا لا توجد مشكلة على الإطلاق فيما يتعلق بمشكلة “الشهادة الشاملة” (wildcard cert) ووجود نقطة أو عدمها في اسم الدلو من حيث شهادة متصفح المستخدم النهائي. لأن أي شبكة توصيل محتوى ستسمح بذلك بالتأكيد.
لذا يمكن لصاحب المنشور الأصلي ببساطة…
(1) اختيار حل تخزين متوافق مع S3 وشبكة توصيل محتوى (CDN) وتكوين نقطة النهاية واسم الدلو في إعدادات Discourse.
(2) تكوين شبكة توصيل محتوى لجلب الصور من S3. مؤمنة أو غير مؤمنة. لا أعتقد أن صاحب المنشور الأصلي يهتم طالما أن شبكة توصيل المحتوى تخدم المستخدم عبر HTTPS.
يرجى تصحيحي إذا كنت أفتقد شيئاً هنا. أعتقد أن مشكلة شهادة متصفح المستخدم النهائي + النقطة في اسم الدلو هي مشكلة فقط إذا كنت ستقوم بخدمة الصور من الدلو. وهي غير ذات صلة بخدمة الصور من شبكة توصيل المحتوى.
ملاحظة جانبية: هذا الموضوع، الذي ربط به @pfaffman بمساعدة أعلاه، يشير إلى أن خدمة S3 الخاصة بـ Digital Ocean (المُسمّاة “Spaces”) تمتلك شبكة توصيل محتوى (CDN) “معطّلة للغاية”.
وأرى أنه بالنسبة لمزودي S3 الآخرين، هناك إعدادات مختلفة يجب تعديلها.
ما يخبرني به هذا:
ستختلف الإعدادات من مزود لآخر، حتى لو ادّعت جميعها أنها تتبع بروتوكول “S3”.
توقف الآن 
شكراً لك على التنبيه 
ثم تعلمت أن الخيار رقم 2 متاح وقمت بإعداده، ثم بدأت هذا الموضوع، وتعلمت فوراً أن الخيار رقم 2 ليس خياراً واقعياً في الحقيقة.
لا تضع نقطة (.) في اسم الدلو الخاص بك