При переустановке контейнера во время установки плагина Discourse в командной строке появилось предупреждение о нехватке места на диске. Мне пришлось выполнить несколько команд для удаления старых версий Linux на моем сервере DigitalOcean, но объем занятого места на SSD все еще превышает 50%.
По мере роста моего сайта на Discourse я начал изучать варианты хранения данных. Сейчас я использую сервер DigitalOcean за 5 долларов и читал о блочном хранилище DigitalOcean и Amazon S3. Вижу, что в настройках Discourse есть встроенные параметры для S3, поэтому, думаю, его проще настроить.
Что используете вы для своего сайта? Что обеспечивает более высокую скорость загрузки: S3 или блочное хранилище DigitalOcean? Какой вариант дешевле? Разве бесплатный тариф S3 не делает его дешевле, чем блочное хранилище DigitalOcean? Вы храните и изображения, и резервные копии? Или вы рекомендуете какой-то другой вариант помимо DigitalOcean и Amazon?
Существует множество провайдеров, предлагающих решения для хранения данных, совместимые с S3. Вы можете использовать любой из них. Я пробовал несколько и могу порекомендовать Digital Ocean Spaces — он отлично работает.
Если вы уже размещаете сервис на DO, я бы рекомендовал выбрать Spaces, так как он быстрый и надежный.
Однако есть некоторые вопросы, связанные с их CDN, поэтому вам, возможно, придется рассмотреть возможность использования CDN стороннего провайдера.
Для получения дополнительной информации ознакомьтесь с этой темой:
Будет ли бесплатный тариф Cloudflare работать как CDN перед хранилищем? Я уже использую их для настроек своего домена и бесплатной защиты от DDoS.
Я заметил, что DigitalOcean рекламирует свой сервис Spaces как более дешёвый по сравнению с другими известными провайдерами. Это, безусловно, плюс.
Поскольку CDN, поставляемый с DigitalOcean Spaces, некорректно работает с Discourse, я думаю, что лучше выбрать одного из других провайдеров из вашего списка. Так мне не придётся платить и за DigitalOcean Spaces, и за отдельный сервис CDN.
Отсутствие заголовка content-encoding в реализации CDN от DigitalOcean, безусловно, неприятно, но это происходит только при установке всех параметров S3 внутри app.yml. Если эти параметры заданы в настройках сайта через веб-консоль администратора, то DO использует CDN только для загрузки S3, а ресурсы сайта по-прежнему обслуживаются из источника.
Похоже, что это сделано намеренно, так как переменная окружения DISCOURSE_S3_CDN_URL, если она установлена в app.yml, переопределяет настройку CDN и для ресурсов сайта, тогда как это же значение, указанное только в настройках сайта, не делает этого?
Это немного несогласованно, но позволяет использовать CDN от DigitalOcean только для загрузок S3, не ломая при этом сайт:
Есть два способа сделать это:
указать все настройки S3 только в настройках сайта
rails c
SiteSetting.s3_upload_bucket="<имя_бакета>/<папка_загрузок>"
SiteSetting.s3_backup_bucket="<имя_бакета>/<папка_резервных_копий>"
SiteSetting.enable_s3_uploads=true
SiteSetting.s3_access_key_id="<ключ>"
SiteSetting.s3_secret_access_key="<секретный_ключ>"
SiteSetting.s3_endpoint="https://<sfo2>.digitaloceanspaces.com"
SiteSetting.s3_cdn_url="https://<имя_бакета>.<sfo2>.cdn.digitaloceanspaces.com/<папка_загрузок>"
SiteSetting.backup_location="s3"
продублировать все настройки S3 кромеDISCOURSE_S3_CDN_URL в app.yml и указать CDN от DO в SiteSetting.s3_cdn_url
Все остальные провайдеры, даже AWS, требуют использования CDN. Тот факт, что DO предлагает бесплатный, но неработающий CDN, — это лишь особенность, которую можно игнорировать и воспринимать сервис как стандартное объектное хранилище.
Я не уверен, что деталь реализации, при которой установка S3 CDN URL в файле yml и в настройках сайта приводит к разному поведению, — это то, что мы хотим поощрять, так как это можно исправить в любое время.
Я не тестировал это, но могу гарантировать, что он работает с настоящими CDN-сервисами, такими как KeyCDN, Cloudfront, StackPath и другими.