Добавят ли поддержку S3 от Contabo? Или кто-то уже нашёл обходной путь, чтобы это заработало?
2 лайка
Мы, разработчики Discourse, поддерживаем только AWS S3. Указанные здесь провайдеры были протестированы либо нами, либо сообществом, чтобы проверить, реализуют ли они достаточную часть API S3 для совместимости с Discourse.
Согласно первоначальному сообщению, @tuxed протестировал Contabo и обнаружил, что он не соответствует требованиям. Это задача Contabo — доработать свою реализацию для соответствия S3, если они считают это целесообразным с точки зрения своих бизнес-интересов, а не наша.
4 лайка
Это всё ещё работает с ошибками? Почему CDN DigitalOcean не хорош?
1 лайк
Вы перешли по ссылкам?
Похоже, что CDN не знает о метаданных. Но вы можете попробовать и посмотреть, будет ли это работать! Дайте нам знать, если попробуете. Я думал, что это исправили всего пару дней назад. Судя по документации, я сам не собираюсь пробовать это в ближайшее время.
2 лайка
Я ищу простой способ добавить поддержку CDN к моему форуму на DigitalOcean. Если S3 проще, я выберу этот вариант.
Не хочу рисковать с настройкой, которая ранее работала некорректно.
2 лайка
Рекомендуемое решение — просто не использовать их CDN. Вы можете использовать Spaces, если следуете инструкциям выше, и такому сервису, как bunny.net, в качестве CDN. Это недорого и просто.
Aws S3 — это то, что использует cdck, поэтому он немного лучше протестирован и поддерживается, но если вы уже не знакомы с aws, то бакет Spaces — хорошее решение. Просто не используйте CDN от Digital Ocean.
2 лайка
Я только что прошел через это — настройка CDN, пока хранение изображений локально — сначала с Fastly, затем с какой-то другой, название которой не помню. Остановился на bunny.net. Настроить очень просто. У них есть инструкции специально для Discourse. Мы работаем на собственном хостинге в DO с более чем 100 ГБ изображений. Попадание в кэш составляет 65% и продолжает расти.
2 лайка
Настройка политики tombstone для S3 работает только на AWS?
1 лайк
Нет. Проблема возникает только в Backblaze.
2 лайка
3 сообщения были перенесены в новую тему: Поиск решений проблем с загрузкой аватара профиля пользователя
Фух, с чего мне начать? Итак, я использую Cloudflare для кэширования и DNS, а Backblaze B2 — для хранения. Мне удалось заставить это работать, но лишь частично. Во время выполнения команды ./launcher rebuild app я увидел, что происходит загрузка ассетов, и очень обрадовался, так как всё казалось рабочим. Однако после успешного завершения пересборки я не смог получить доступ к сайту. Просто появляются движущиеся точки в центре страницы.
На основе статьи Backblaze Раздача публичного контента Backblaze B2 через CDN Cloudflare я настроил проксируемый CNAME-запись, указывающую на исходный URL f000.backblazeb2.com, названный gtech-cdn.
CNAME gtech-cdn → f000.backblazeb2.com
В статье также упоминаются Page Rules; я пробовал включать и выключать их, но безрезультатно.
Вот соответствующие элементы конфигурации:
DISCOURSE_HOSTNAME: mmhmm.com
DISCOURSE_CDN_URL: https://mmhmm.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-west-000
DISCOURSE_S3_ENDPOINT: https://s3.us-west-000.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: <secret>
DISCOURSE_S3_SECRET_ACCESS_KEY: <secret>
DISCOURSE_S3_CDN_URL: https://gtech-cdn.mmhmm.com
DISCOURSE_S3_BUCKET: gtech-uploads
DISCOURSE_S3_BACKUP_BUCKET: gtech-uploads/backups
DISCOURSE_BACKUP_LOCATION: s3
В разделе **hooks:**...
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
- sudo -E -u discourse bundle exec rake s3:expire_missing_assets
Один из моментов, который меня сбивает с толку, — это то, что именно указывать в двух переменных: DISCOURSE_S3_CDN_URL и DISCOURSE_CDN_URL. Правильно ли я их настроил, исходя из предоставленной мной информации?
Просматривая консоль инструментов разработчика в браузере, я вижу ошибки 404 для .js-скриптов. Похоже, URL формируется неправильно. Разве там не должно быть /file/<bucketname> перед /assets? Если я вручную добавлю это для создания правильного URL, всё работает:
https://gtech-cdn.mmhmm.com/file/gtech-uploads/assets/google-universal-analytics-v4-e154af4adb3c483a3aba7f9a7229b8881cdc5cf369290923d965a2ad30163ae8.br.js
Спасибо за любую помощь, я очень ценю её!!!
1 лайк
https://gtech-cdn.mmhmm.com не разрешается, поэтому это первое, что нужно исправить.
Не уверен, что можно использовать Cloudflare как CDN таким образом, но, возможно, я ошибаюсь.
1 лайк
Извините, я должен был упомянуть, что mmhmm.com — это поддельный домен. Он действительно отвечает на ping.
Что касается невозможности использования Cloudflare в качестве CDN, я, кажется, не до конца понимаю. Статья, на которую я сослался, явно описывает использование её в качестве CDN. Если это не так, то какие значения следует использовать для двух переменных DISCOURSE_S3_CDN_URL и DISCOURSE_CDN_URL?
С уважением,
Если вы предоставляете поддельные URL-адреса, вы можете получить только поддельные ответы.
Предоставляет ли URL-адрес ожидаемые данные? Можете ли вы получить их по URL-адресу форума?
Я думаю, что S3 CDN должен работать. Он использует URL-адрес форума для CDN форума, но я не уверен насчет этого.
Обычный CDN — это другой URL-адрес, чем у форума, и CDN может рассчитывать на то, что данные статичны, а не на то, что ему придется угадывать, что является динамическим.
1 лайк
Я стараюсь не распространять свою информацию по различным форумам, поэтому прошу простить мою скрытность в этом вопросе.
Форум находится по адресу “https://mmhmm.com”, что является записью DNS Cloudflare, проксируемой (кэшируемой). До настройки Discourse для использования Backblaze всё работало корректно.
“https://gtech-cdn.mmhmm.com”, как уже упоминалось, разрешается и отвечает на ping. Целевой адрес записи CNAME, f000.backblazeb2.com, также разрешается. Именно этот URL-источник B2 Friendly, согласно статье, следует использовать. Однако проблема не в этом. Проблема заключается в том, что Discourse выдает URL-адреса для .js-файлов с некорректным URL, который никогда не сработает, так как в нём отсутствует часть пути “/file/gtech-cdn”. Если взять один из таких неполных URL-адресов .js и вручную добавить недостающую информацию, текст .js-файла загрузится без проблем.
Конечно, я всё ещё пытаюсь понять, как именно всё это должно работать с учётом этих двух переменных. Я больше визуальный learner и мне очень нужна схема или что-то подобное, чтобы понять, как должны взаимодействовать Cloudflare CDN, Discourse и Backblaze B2.
Спасибо за вашу помощь.
Кстати, я постараюсь ответить на ваше последнее предложение о обычном CDN…
В статье от Backblaze предлагается создать два правила для каждой корзины (в моём случае используется одна корзина), что, если я правильно понимаю, работает примерно как правило брандмауэра.
Правило 1 гласит, что для адресов вида https://gtech-cdn.mmhmm.com/file/*/* следует использовать стандартное кэширование (которое в Cloudflare установлено на 1 месяц в другом месте).
Правило 2 перенаправляет (302 — временное перенаправление) всё, что не соответствует шаблону Правила 1.
Таким образом, не всё будет кэшироваться при обращении к mmhmm.com… по крайней мере, так я это понимаю.
РЕДАКТИРОВАНИЕ: Это не сработало.
Посвятив этому немного больше времени, я по очевидным причинам решил использовать URL S3 в качестве цели CNAME вместо дружелюбного URL, который предлагался в статье Backblaze. Сейчас я просто жду истечения TTL DNS-записи.
Касательно этого хука:
Я не вижу ничего связанного с S3 в выводе rake --tasks. Это всё ещё актуально, или я упускаю какой-то плагин?
Также вижу это при ручном запуске:
uploads:migrate_to_s3
rake aborted!
FileStore::ToS3MigrationError: Некоторые загрузки не удалось перенести на новую схему. Вам нужно исправить это вручную. (FileStore::ToS3MigrationError)
/var/www/discourse/lib/file_store/to_s3_migration.rb:156:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:126:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:106:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management.rb:21:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:104:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:100:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3
(Полный трассировочный вывод можно получить, запустив задачу с флагом --trace)
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse#
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse# rake uploads:migrate_to_s3
Обратите внимание, что миграция на S3 в настоящее время необратима!
6 сообщений были перенесены в новую тему: Cloudflare R2: Настройка и устранение ошибок конфигурации
Похоже, Cloudflare теперь работает:
Смотрите Cloudflare R2: Navigating Setup and Handling Configuration Errors - #13 by pfaffman
2 лайка