Сначала я попытался запустить Discourse с настройками, близкими к стандартным, и всё работало вполне нормально: я мог загружать файлы и выполнять другие действия.
Затем я понял, что путь в app.yml указан как /var/discourse, и изменил его на /var/www/discourse. Я остановил и уничтожил контейнер, полностью удалив предыдущую папку. Теперь всё снова запущено и работает… но я заметил, что больше не могу загружать файлы.
Какие права доступа нужны для папки uploads? Я могу внести изменения вручную, но хотел бы знать точно, что именно нужно сделать, и является ли это нормальным (разве запускатель не должен сам настраивать правильные права доступа, особенно при запуске с нуля?)
У меня на этом сервере много других проектов, и все они удобно размещены в моей папке /var/www, поэтому я предпочитаю оставить всё как есть Меня не волнует, как это устроено внутри контейнера.
Но я же его обновил? В разделе mounts или где ещё это должно быть указано?
Именно в этом и суть. Раз ваш обратный прокси nginx не находится в этом пути, почему же контейнер Docker должен быть? Но контейнер живет своей собственной жизнью, и путь к контейнеру не должен влиять на то, что делает его Nginx. Вы что-то еще меняли?
Ладно, ничего не сработало, поэтому я в итоге изменил права доступа к папке uploads на 755, и теперь всё в порядке. После перестройки выяснилось, что сами загрузки были в порядке (со стороны движка), однако nginx не мог их прочитать.
Я не до конца понимаю, зачем вы делаете всё это. Выбор разместить контейнер в пути, который станет видимым во всём мире при малейшей ошибке, — это ваше решение, и это ваш выбор. Но всё остальное… зачем?
Использование обратного прокси перед Discourse — это действительно просто, и в противном случае ваша установка была бы стандартной, без всех этих хлопот. Конечно, если вы хотите поэкспериментировать и это ваше хобби, но довольно скоро кто-нибудь заявит, что поддержка предоставляется только для стандартной установки, а главная проблема в том, что никто на самом деле не знает, что вы сделали. Или почему.
Вы исправляете проблему, возникшую, когда вы начали делать что-то другое, что требуется в стандартной ситуации. Даже с обратным прокси.
Вот почему вы довольно далеко от стандарта Потому что есть два варианта:
у вас в руках баг, которого ни у кого другого нет
вы сделали что-то необычное
Возможно, это баг. И вы подтвердили это, выполнив стандартную установку безопасным (во многих отношениях) способом и одновременно правильно настроив обратный прокси. Потому что если проблема всё ещё сохраняется, я могу поспорить, что она связана с виртуальным хостом и/или портами. Но если всё работает… то мы возвращаемся к варианту «необычное» — где никто не знает, что именно вы сделали.
Вы видите проблему здесь?
В любом случае — использование обратного прокси означает отсутствие поддержки… такова наша политика. Однако другие пользователи могут и довольно часто помогают,
Меня не волнует, как это устроено внутри контейнера.
Ситуация такая же с контейнером Docker.
