Согласно ссылке выше, изображения и вложения хранятся в более глубокой общей папке установки Discourse, а не внутри Docker-контейнера. Учитывая, что я хочу использовать символическую ссылку на папку с изображениями со второго хранилища, которую я монтирую через NFS на другие серверы. На вторичном сервере я планирую запускать Docker-контейнер Discourse для балансировки нагрузки и обеспечения отказоустойчивости, используя ту же папку с изображениями из NFS-монтирования. У меня уже есть база данных с другого сетевого сервера на всякий случай.
Я только что протестировал эту настройку, но результат оказался неудовлетворительным. Я скопировал все файлы изображений из /var/discourse/shared/standalone/uploads в /var/www/image/uploads.
Затем:
Создал символические ссылки на папку с изображениями, смонтированную через NFS;
Выполнил chmod и chown для папки /uploads с владельцем www-data:www-data и правами 755.
На первичном сервере, где папка с изображениями смонтирована нативно, изображения отображаются, но на вторичном сервере с NFS-монтированием этого не происходит. Изображения отсутствуют, отображается только контейнер с размером.
Кроме того, даже на первичном сервере изображения видны, но скачать их больше невозможно.
Полагаю, проблема в правах доступа к файлам. Хотелось бы узнать идеальную настройку.
Не уверен, связано ли это с «ванильной» установкой или с многочисленными пересборками, но изображения в папке по умолчанию имеют права 755/644 (папка/файл) и принадлежат пользователю main_id:www-data на моём сервере. Я также применил ту же стратегию, но это не помогло. Возможно, проблема связана с символическими ссылками или спецификой NFS, но я больше не могу отследить причину.
Это была моя первая попытка. Внутри Docker я обнаружил, что файловая система для mine была довольно запутанной, как я и заметил ранее. Путь был вложенным: /uploads/uploads/uploads, прежде чем стал виден /default/. Не уверен, что именно произошло, но я скопировал все файлы изнутри на свой смонтированный образ и добавил папку монтирования как том.
Здесь ситуация была не так уж сильно отличается от символической ссылки. Права доступа к файлам действительно создают ту же проблему. После того как я понял, что файлы на самом деле хранятся вне контейнера Docker, я подумал, что символическая ссылка может быть гораздо более простым решением.
В обоих случаях я почти уверен, что дело в правах доступа к файлам, но кастомный CDN, реализованный просто через блок конфигурации Nginx, звучит как гораздо более простое решение, чем том Docker, при условии, что символическая ссылка не сработает.
Я почти уверен, что использование символических ссылок не принесёт ничего хорошего. Одна из проблем заключается в том, что трудно сделать так, чтобы символическая ссылка внутри контейнера и снаружи была одинаковой, и, полагаю, ваша проблема с вложенными загрузками связана именно с этим. Мне встречались рекомендации не использовать символические ссылки, и я думаю, что причина именно в этом.
Поддерживает ли Discourse CDN на основе пользовательских CNAME? Я помню, что видел конфигурацию S3 в разделе администрирования и обсуждение в мета-форуме, посвящённое Fastly, но не могу точно вспомнить конфигурацию для пользовательского CDN.
Нашёл пост. Похоже, мне нужно настроить собственную версию CDN, совместимую с S3. Одного только Nginx в качестве сервера изображений будет недостаточно.