Это указано в блоке примера конфигурации для Vultr в оригинальном посте. Скопируйте и вставьте в ваш app.yml и измените необходимые поля.
2 лайка
Спасибо, я упустил этот момент:
1 лайк
У меня пока не всё идёт гладко, извините за частые ответы.
Если я сделаю всё вышеперечисленное, нужно ли мне игнорировать настройки S3 и резервного копирования в панели администратора?
Или же настройки в панели администратора также должны быть настроены?
1 лайк
Вам просто нужно следовать этому руководству в первом сообщении, и вы получите рабочую конфигурацию объектного хранилища.
3 лайка
Установка этих переменных делает их недоступными в UX. Вы должны установить их, как описано здесь, а не через ux.
2 лайка
Думаю, сейчас это (в основном?) работает, но безопасна ли эта content security policy script src?
Я использую AWS для двух контейнеров S3 (для загрузки и резервных копий) и двух CDN CloudFront (для файлов и ассетов). Когда я использую собственные CNAME для CDN CloudFront, в браузере при загрузке Discourse возникает множество ошибок сети script-src. Ошибки исчезли после добавления этих записей в мой CSP.
1 лайк
Это те же URL, которые вы указали в переменных окружения, описанных в первом посте? И используют ли они HTTPS?
1 лайк
Да, предупреждений script-src нет, когда я добавляю два URL вида d23whatever.cloudfront.net в переменные окружения. Но когда я добавляю свои собственные URL, например community-cdn.mydomain и files-cdn.mydomain, в переменные окружения, тогда появляются эти предупреждения script-src. И, по-видимому, Stripe JS продолжает выдавать это предупреждение, даже несмотря на то, что он указан в моём content security policy script src.
2 лайка
Я настроил S3 Uploads и объектное хранилище, как описано в первом посте (OP), но без CDN.
Для переменной DISCOURSE_S3_CDN_URL у меня указано следующее:
https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com
Всё работает нормально, включая резервные копии, однако в консоли появляется эта ошибка при начале ответа на пост:
URL запроса в ошибке на самом деле представляет собой строку из двух URL-адресов, что, похоже, и является причиной?
https://mydiscourse.com/t/uploads-test-for-s3/79/https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com/assets/markdown-it-bundle-a7328b73d3e7b030770eab70f10bdb0af655b3d8fa929bc49f1ad04c4cdaa198.br.js
2 лайка
Для корректной работы CDN обязателен.
4 лайка
У меня тоже такая ситуация: есть настроенное объектное хранилище (MinIO), но нет CDN. Это сценарий использования, который можно поддержать?
Судя по моим тестам, проблема возникает только с файлом markdown-it-bundle.js, так как он указывает на неверный URL: DISCOURSE_HOSTNAME/DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js.
Похоже, это баг: даже если установить переменную DISCOURSE_CDN_URL, ссылка остаётся неверной в формате DISCOURSE_HOSTNAME/DISCOURSE_CDN_URL/assets/markdown-it-bundle-HASH.br.js.
Она должна указывать на DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js.
Остальные JS-ресурсы ссылаются на правильный URL.
Похоже, исходя из ваших слов, у меня возникнут и другие проблемы, которые я ещё не выявил. Можете ли вы подробнее рассказать, что может пойти не так?
Если я правильно понял, JS-ресурсы находятся в объектном хранилище, а стили должны размещаться на CDN. Если CDN нет, могут ли стили предоставляться приложением как обычно? (Судя по моим наблюдениям, так и происходит.)
Спасибо за помощь.
3 лайка
Это не поддерживаемый сценарий использования, согласно первоначальному сообщению:
1 лайк
Уважаемые коллеги,
Я настроил новый сервер Discourse на Lightsail, используя это руководство по загрузке файлов и изображений в S3 и созданию резервных копий setting-up-file-and-image-uploads-to-s3.
После настройки при загрузке изображения на экране появилась ошибка: «The bucket does not allow ACLs» (Ведро не разрешает ACL).
Вот моя политика для S3:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:GetObjectVersionTagging",
"s3:CreateBucket",
"s3:GetObjectAcl",
"s3:GetBucketObjectLockConfiguration",
"s3:PutLifecycleConfiguration",
"s3:GetObjectVersionAcl",
"s3:PutObjectTagging",
"s3:DeleteObject",
"s3:DeleteObjectTagging",
"s3:GetBucketPolicyStatus",
"s3:GetObjectRetention",
"s3:GetBucketWebsite",
"s3:ListJobs",
"s3:DeleteObjectVersionTagging",
"s3:GetObjectLegalHold",
"s3:GetBucketNotification",
"s3:PutBucketCORS",
"s3:GetReplicationConfiguration",
"s3:ListMultipartUploadParts",
"s3:PutObject",
"s3:GetObject",
"s3:DescribeJob",
"s3:PutObjectVersionAcl",
"s3:GetAnalyticsConfiguration",
"s3:GetObjectVersionForReplication",
"s3:GetLifecycleConfiguration",
"s3:GetAccessPoint",
"s3:GetInventoryConfiguration",
"s3:GetBucketTagging",
"s3:GetBucketLogging",
"s3:ListBucketVersions",
"s3:ReplicateTags",
"s3:ListBucket",
"s3:GetAccelerateConfiguration",
"s3:GetBucketPolicy",
"s3:GetEncryptionConfiguration",
"s3:GetObjectVersionTorrent",
"s3:AbortMultipartUpload",
"s3:PutBucketTagging",
"s3:GetBucketRequestPayment",
"s3:GetAccessPointPolicyStatus",
"s3:GetObjectTagging",
"s3:GetMetricsConfiguration",
"s3:PutObjectAcl",
"s3:GetBucketPublicAccessBlock",
"s3:ListBucketMultipartUploads",
"s3:ListAccessPoints",
"s3:PutObjectVersionTagging",
"s3:GetBucketVersioning",
"s3:GetBucketAcl",
"s3:GetObjectTorrent",
"s3:GetAccountPublicAccessBlock",
"s3:ListAllMyBuckets",
"s3:GetBucketCORS",
"s3:GetBucketLocation",
"s3:GetAccessPointPolicy",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::mybucket-upload",
"arn:aws:s3:::mybucket-upload/*",
"arn:aws:s3:::mybucket-backup",
"arn:aws:s3:::mybucket-backup/*"
]
}
]
}
А вот настройки общего доступа для ведра S3:
Не могли бы вы помочь мне решить эту проблему?
Огромное спасибо.
С уважением,
Куанг
3 лайка
Должен ли мой тестовый сайт использовать то же S3-хранилище, что и мой производственный сайт?
1 лайк
Нет, это было бы очень небезопасно и могло бы привести к удалению файлов, которые должны существовать в другой среде, а также к изменению файлов из другой среды (что может вызвать отсутствие файлов, наличие неверных файлов и так далее).
Как хранилища (buckets), так и учетные данные должны быть разными (причем учетные данные для тестовой среды не должны иметь доступа к хранилищу продуктивной среды, особенно в отношении операций записи и удаления).
Возможно, существует способ использования путей с разными учетными данными для каждого пути, но риск совершить ошибку слишком велик, поэтому я рекомендую использовать отдельные хранилища.
5 лайков
Переменные DISCOURSE_CDN_URL и DISCOURSE_S3_CDN_URL тоже должны быть разделены?
1 лайк
Я так предполагаю, потому что если ваши домены/URL-адреса для тестовой и рабочей сред различаются (а они различаются, верно?), то DISCOURSE_CDN_URL (который в итоге указывает на провайдера CDN, а тот — на домен вашего сайта) должен быть разным для тестовой и рабочей сред. Та же логика применима к DISCOURSE_S3_CDN_URL (поскольку у разных бакетов должны быть разные URL-адреса).
4 лайка
Всем привет! Я довольно новичок в S3, поэтому не совсем уверен, как правильно сформулировать вопрос, но постараюсь. Я только что перешёл на использование S3 для загрузки файлов и резервных копий, и ранее использовал Discourse Connect для входа на других частях моего сайта. Теперь изображения профилей не работают. Я полагаю, что проблема связана с политиками CORS, но не уверен, где именно их нужно настроить. В идеале мне хотелось бы добавить в белый список forum.domain.tld и domain.tld — либо использовать wildcard для всех поддоменов. Нужно ли это настраивать в Discourse или где-то ещё? Я использую объектное хранилище Vultr, если это имеет значение.
1 лайк
Можно ли включить версионирование для S3-бакета files? Является ли AWS Backup рекомендуемым способом резервного копирования S3-бакетов для Discourse?
1 лайк
Да.
Использование версионирования или синхронизация с другим регионом — все это хорошие стратегии.
4 лайка