Итак, я настроил бакет Amazon S3 для хранения ресурсов форума, привязал к нему пользовательский домен и настроил CDN CloudFlare для кэширования контента.
Всё работает корректно. Если я добавлю изображение в корневую папку бакета, я смогу получить его по моему пользовательскому URL, то есть http://forum-storage.com/test.jpg вернёт изображение с заголовками CloudFlare.
Три простых вопроса…
#1
Теперь мне нужно указать Discourse использовать этот новый URL как мой бакет S3. Что мне нужно ввести в эти три поля?
В настоящее время в моих сообщениях на форуме есть изображения, хранящиеся в другом бакете S3, а также изображения, хранящиеся локально. (Мои URL-адреса изображений разбросаны повсюду.)
После внесения правильных изменений (описанных выше) всё новое медиа, добавляемое на мой форум, будет помещаться в новый бакет, но существующие изображения перемещены не будут и продолжат загружаться оттуда, где они находятся сейчас, верно?
#3
Теперь, когда всё работает для всех новых изображений, как я могу попросить Discourse ПЕРЕМЕСТИТЬ все старые изображения, которых нет в этом новом бакете, в новый бакет (и при необходимости пересобрать сообщения)?
Цель — собрать всё в одном бакете, в этом новом, за CDN.
Создайте новый бакет, в названии которого нет точки. Если вы продолжите, вас ждут бесконечные страдания из-за того, как работают SSL-сертификаты для поддоменов.
Верно. Я думаю, мы на одной волне? Чтобы прояснить ситуацию: насколько я понимаю, существует три способа подключения Discourse к S3:
Прямое использование облака S3 со стороны Discourse. Плюс: очень простая настройка. Минус: быстро становится дорого.
Использование облака S3 через пользовательский домен (например, forum-storage.com), чтобы можно было применять CDN. Плюсы: очень простая настройка с S3, если имя бакета точно совпадает с пользовательским доменом (т. е. forum-storage.com.s3-amazon-aws.com). Минусы: проблемы с SSL.
Использование облака S3 через пользовательский домен (снова для возможности применения CDN), но с настройкой бакета S3 так, чтобы в его имени не было лишней точки (т. е. forum-storage-com.s3-amazon-aws.com). Плюсы: SSL работает корректно. Минусы: настройка с Amazon S3 не такая простая.
Итак… Я использовал вариант №1, пока не получил счёт Затем узнал, что есть вариант №2, настроил его, создал эту тему и тут же выяснил, что вариант №2 на самом деле не совсем подходит.
Теперь я работаю над вариантом №3. Похоже, мне придётся использовать DNS-сервис Amazon “Route 53” или что-то подобное. Пока ещё разбираюсь. Всё, что я нашёл через Google, касается реализации варианта №2, но никто, похоже, не написал чётких инструкций для варианта №3.
Пожалуйста, поправьте меня, если я ошибаюсь или что-то неправильно понял…
@BryanV, как вы указали https://discourse-uploads.bokeh.org на свой бакет S3? Я добавил запись CNAME, указывающую на URL <длинный id>.cloudfront.net для распределения CDN Cloudfront в нашу конфигурацию 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 требует манипуляции заголовком origin в запросах. Эта функция доступна только в корпоративном тарифе Cloudflare, поэтому использование любого другого CDN может оказаться проще.
Разве наличие точки в имени бакета не неважно, если изображения всё равно будут кэшироваться через CDN? Единственное, что имеет значение, — это наличие хорошего сертификата, покрывающего изображения, предоставляемые через Cloudflare.
Думаю, ему стоит сосредоточиться на серверах Cloudflare, DNS и сертификате, который покрывает эту инфраструктуру. Я не думаю, что пользователь или браузер когда-либо узнают, что источником этих изображений является бакет S3. Cloudflare будет кэшировать и проксировать само изображение, верно?
@riking Похоже, от Discourse требуется только имя бакета, верно? Загрузка и управление могут осуществляться через URL-адреса AWS с их сертификатами, если вообще требуется HTTPS. Пока что есть ли какая-либо причина обсуждать сертификаты безопасности?
Далее, OP отдельно может рассмотреть, что ему нужно сделать, чтобы его CDN или решение кэширования могло получать изображения из S3. Безопасно это или нет — не имеет значения, если у OP или CDN нет специальных требований, верно? Заботится ли Discourse о его настройке между S3 и CDN?
Наконец, OP должен убедиться, что изображения предоставляются через CDN с действительным сертификатом. Имеет ли это какое-либо отношение к Discourse, кроме того, что OP указывает базовый URL, по которому в итоге будут размещаться изображения? Как только его CDN или кэш загрузят изображения из S3, AWS, бакеты и прочее полностью выходят из уравнения.
Я понимаю, что существуют проблемы с точкой в именах бакетов S3, если вы планируете предоставлять изображения оттуда, но OP этого НЕ делает. Таким образом, всё сводится к тому, чтобы OP выбрал любое имя бакета, которое примет Discourse, при условии, что оно не будет конфликтовать с его настройками CDN.
Хотя технически возможно избежать использования URL-адресов в формате «bucket-в-домене», на практике это не происходит из-за особенностей использования AWS S3 SDK и сложности его настройки.
Повторим: эти операции обходят CDN, и исправить их можно только в исходном коде Discourse. Исправление возможно, но пока не реализовано. Многие из этих проблем не возникают на критическом пути и проявляются лишь позже. Поэтому, пока ситуация не изменится, не используйте имена бакетов, содержащие точки.
Итак, чтобы свести всё к предельной простоте… Вопрос, который задал OP, заключался в том, что именно нужно указать в трёх настройках для конфигурации:
(1) ИМЯ ВЕДРА (BUCKET NAME) — значит, точки не рекомендуются? или они вообще запрещены? Я подозреваю, что для OP это возможно не станет проблемой. (Ему просто нужно отдельно найти способ, чтобы его CDN кэшировал и отдавал изображения.) Так что мы все на одной волне, верно?
(2) КОНЕЧНАЯ ТОЧКА S3 (S3 ENDPOINT) — оставить пустым, ничего не нужно, если он использует AWS; в противном случае он может заполнить это поле для другого провайдера?
(3) CDN URL S3 — это просто базовый URL, который Discourse будет добавлять к пути изображения? Если да, то это просто и понятно: OP может настроить свой CDN и указать здесь этот базовый URL.
Я не вижу, как здесь играют роль SSL-сертификаты с подстановочными знаками. OPу сказали, что точка в конфигурации Discourse — это плохо, потому что это сломает его сертификат. Но если он использует CDN или кэш, то имя ведра может оказаться совершенно не связанным с сертификатом, верно? Если это сломает Discourse каким-то другим образом, об этом полезно знать.
Не уверен, что слежу за всем этим достаточно внимательно, но если немного отойти от деталей, возможно, этот простой набор требований поможет:
Цели:
Не хранить изображения Discourse на сервере Discourse.
Иметь бакет S3 для хранения изображений (обязательно S3, так как именно это поддерживает Discourse).
Избегать высоких расходов на S3.
CDN не обязателен, но будет приятным бонусом, так как может помочь снизить (или даже полностью устранить) дорогие расходы на S3, а также обеспечить лучшую доступность по всему миру, создать резервную копию на случай сбоя основного сервера и т. д.
Поправьте меня, если я ошибаюсь в чём-либо из вышеперечисленного
Ограничения/требования:
Внешнее хранилище изображений должно поддерживать протокол S3 (поскольку именно с ним работает Discourse), но, строго говоря, не обязательно должно быть S3 от Amazon.
Discourse требует, чтобы имя бакета S3 не содержало точек.
Источник изображений (S3 или CDN) должен предоставлять контент по HTTPS, так как браузер выдаст ошибку, если страница загружена по HTTPS, а изображения — нет.
Поправьте меня, если я ошибаюсь в чём-либо из вышеперечисленного
Решения:
Ранее я обслуживал изображения напрямую из Amazon S3. Всё работало отлично, за исключением того, что плата Amazon за передачу данных наружу (DataTransfer-Out-Bytes) оказалась чрезмерно высокой. Это приводило к большим ежемесячным счетам от Amazon! Поэтому я вернулся к обслуживанию с основного сервера. Два возможных решения этой проблемы: разместить CDN перед бакетом Amazon S3, чтобы CDN обрабатывал всю передачу данных, и/или перейти к другому провайдеру S3.
Я пытался настроить CDN CloudFlare поверх бакета Amazon S3, но очень быстро столкнулся с множеством проблем, которые не смог решить.
Для справки: за последние 30 дней я обслуживал около 300 ГБ данных из S3. Часть из этого — резервные копии сайта, значительная часть — статические изображения. Мне очень трудно разобраться, как измерять эти показатели в Amazon… их интерфейс отчётности по биллингу, как и всё остальное в Amazon AWS, действительно запутан для администрирования.
Я считаю, что самым простым решением является связка AWS и KeyCDN в соответствии с рекомендациями в статье Использование объектного хранилища для загрузки файлов (S3 и аналоги). Если ваши пользователи находятся не в Южной Америке, KeyCDN является довольно доступным и простым в настройке вариантом.
Возможно, более дешёвым решением может стать настройка BackBlaze S3 с BunnyCDN. В моих первоначальных тестах для резервного копирования Backblaze показал себя хорошо, но я ещё не пробовал его для загрузки файлов.
Мы совершенно зря отвлеклись на точку в имени бакета и сертификаты браузера, но я считаю, что все эти обсуждения совершенно неуместны. ЛЮБОЙ CDN позволит настроить HTTPS, поэтому ПРОБЛЕМ НЕТ НИКАКИХ с «проблемой wildcard-сертификата» и с точкой или без неё в имени бакета, ЕСЛИ ГОВОРИТЬ О СЕРТИФИКАТЕ БРАУЗЕРА КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ. Потому что, повторюсь, ЛЮБОЙ CDN, безусловно, это позволит.
Так что автор темы может просто…
(1) выбрать решение для хранения, совместимое с S3 и CDN, и настроить конечную точку и имя бакета в настройках Discourse.
(2) Настроить CDN для загрузки изображений из S3. Безопасно или небезопасно. Мне кажется, автору темы это не важно, главное, чтобы CDN доставлял контент пользователю через HTTPS.
Кто-нибудь, пожалуйста, поправьте меня, если я что-то упускаю. Я думаю, что проблема с сертификатом браузера конечного пользователя и точкой в имени бакета возникает ТОЛЬКО если вы собираетесь отдавать изображения НАПРЯМУЮ из бакета. Это не имеет отношения к отдаче через CDN.
P.S. Эта тема, на которую @pfaffman любезно указал выше, отмечает, что CDN продукта «Spaces» (аналог S3) от Digital Ocean «очень сломана». Configure an S3 compatible object storage provider for uploads Я также вижу, что для других провайдеров S3 необходимо корректировать различные настройки. Это говорит мне о следующем: — Настройки будут различаться от провайдера к провайдеру, даже если все они заявляют о соблюдении протокола «S3».
ПРЕКРАТИТЕ СЕЙЧАС 
Спасибо за предупреждение, 
Затем узнал, что есть вариант №2, настроил его, создал эту тему и тут же выяснил, что вариант №2 на самом деле не совсем подходит.
НЕ используйте точку (точку с запятой) в имени вашего бакета