Ох, это трагично. Очень сочувствую 
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam и эта тема ясно показывают, что это никогда не будет решено, хотя Bitnami только что это сделала…
По крайней мере, мы получили ответ на наш вопрос, и он отрицательный.
А как насчёт того, чтобы изначально не использовать root? Использование fakeroot показывает, что основным препятствием являются жёстко заданные пути (например, /var). В остальном, за исключением различных багов и проблем, с которыми сталкивается текущая конфигурация, это могло бы работать.
Жаль видеть, что такое замечательное программное обеспечение имеет столь плохо продуманную обязательную процедуру настройки, основанную на распространённом непонимании контейнеризации. Мне очевидно, что это было сделано с наилучшими намерениями; тем не менее, результат — это решение, которое невозможно развернуть где-либо за пределами любительской среды.
Наш образ запускается от имени пользователя discourse, и, как я полагаю, официальный тоже.
В любом случае, здорово, что “корпоративный” мир проявляет интерес, ведь у него гораздо больше времени и денег, чем у энтузиастов-любителей 
Уверен, сообщество оценит ваш вклад в улучшение экосистемы!
Это, безусловно, неверно. Мы разворачиваем наше изображение с помощью Nomad на множестве машин. Прямо сейчас в AWS и на физических серверах работают более 10 000 контейнеров Discourse.
Инструменты требуют прав root для запуска и нуждаются в доступе к хост-каталогу /var.
Я часто сотрудничаю с сообществами с открытым исходным кодом и компаниями, чтобы улучшить их настройку контейнеров. Буду рад помочь и/или рассмотреть возможность финансирования для создания более разумной контейнеризованной среды.
Это не обязательно. Просто если вам нужна помощь в настройке, то это способ её получить. Я, например, помогал клиентам с gke, eks, ecs. Не стесняйтесь обращаться ко мне, если вам нужна помощь с вашими конкретными требованиями.
/var не прописан жёстко; недавно я работал с человеком, у которого он был в /var/www/discourse (что казалось очень плохой идеей, так как это создаёт риск передачи конфиденциальных данных в веб, но это была «политика».
Это не плохо спроектировано; это плохо спроектировано, если бы вы создавали его сегодня, а не десять лет назад. Тогда это было хорошим решением, и оно до сих пор работает для их инфраструктуры и даже для многих людей, которые ничего не знают о системном администрировании.
Похоже, вы не используете официальные инструменты, такие как discourse-setup, которые требуют прав root для запуска и, вероятно, предназначены для локальной настройки.
Посмотрите исходный код discourse-setup. Если вы знакомы с настройкой и оптимизацией производительности Discourse, это не обязательно.
Launcher берет на себя всю основную работу по созданию образа из полученного файла yml.
Всё можно сделать, но мне это кажется излишним трудом.
- Использовать
fakerootперед каждой командой - Путь
/varможно изменить, отредактировав YAML-файл:sed -i "s;host: /var/discourse;host: $PWD/discourse;g" containers/*.yml - Флаг
--skip-connection-test(найден путём изучения кода, так как скрипт не может проверить соединение при наличии обратного прокси) - Вижу что-то связанное с certbot; я уже знаю, что нужно будет разобраться, как отключить эту часть, поскольку SSL-оффлоадинг обычно осуществляется внешними средствами
- Порты в
containers/app.ymlможно изменить так, чтобы использовались порты >= 1024, но этого, похоже, недостаточно:Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
Я не хочу звучать грубо, но запуск нескольких сервисов в одном контейнере всегда считался плохим дизайном, так как это означает отсутствие или крайне ограниченные возможности отслеживания состояния отдельных сервисов, необходимость настройки кастомного механизма парсинга логов вне Docker, отсутствие полезных проверок работоспособности (healthchecks), невозможность легко использовать внешнюю базу данных и т. д. Это можно реализовать, если вы запускаете только этот сервис в своей инфраструктуре, но если каждый другой сервис начнёт делать то же самое, большинство преимуществ использования контейнеров просто исчезнут.
Я с радостью отправлю некоторые PR и документацию, чтобы заставить Discourse работать в среде, совместимой с Docker, без прав root, но разделение сервисов и создание стандартной конфигурации — это большая задача, без гарантий того, что эти изменения будут приняты в основную ветку.
Если вы не согласны с фундаментальными аспектами того, как построен Discourse, не думали ли вы об использовании другого продукта?
Хорошо, я понял лучше.
У Discourse есть чёткая позиция относительно инструментов для самостоятельного развёртывания. Это позволяет им эффективно оказывать поддержку администраторам с небольшим опытом, которые хотят развернуть Discourse. Вы можете согласиться или нет, раньше я тоже немного расстраивался, но теперь я понимаю лучше 
Если у вас другие потребности, чем быстрое развёртывание, как у большинства, то вы в основном полагаетесь на себя. Как только вы разберётесь, всё будет в порядке
У нас есть аналогичная потребность в отдельном Docker-образе Discourse. Мы запускаем его в Kubernetes с MinIO; заставить это работать было довольно сложно, и это всё ещё требует много усилий. Мы также получили отличную помощь от команды Discourse, чтобы добиться этого.
Наша работа доступна здесь:
https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
(документация недостаточна, тестирование отсутствует, поддержка и своевременное обновление не гарантированы, автоматизация тоже, и решение, вероятно, довольно кастомное — но таковы реалии)
Если кому-то интересно улучшить это, не стесняйтесь присылать PR или общаться здесь: https://matrix.to/#/#libresh:liiib.re
Но да, у команды Discourse есть чёткая позиция по поводу версии Discourse Community. Вы можете согласиться или нет, но они оказывают основную поддержку пользователям, и из того, что я видел, эта поддержка потрясающая, поэтому я считаю, что это было правильное решение
Это фундаментальные аспекты упаковки Discourse, а не самого Discourse, который является отличным программным обеспечением, но вы правы, мне стоит рассмотреть другие решения.
Вы можете удалить шаблоны для postgres и redis (а также ssl и let’s encrypt) и использовать свои собственные.
Спасибо за информацию. Я тоже нашел GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar · GitHub и образы от Bitnami. Основная проблема в том, что эти решения не поддерживаются официально. Интересно, не стоит ли создать альтернативную настройку Docker с поддержкой сообщества, вместо того чтобы иметь различные кастомные репозитории, так как распределение усилий по разным местам было бы неэффективным.
Вы правы, настройки действительно можно изменить. Если мне удастся запустить это без больших усилий, я постараюсь отправить несколько pull-запросов для улучшения существующих инструментов или документации, например, чтобы запускать его без прав root. Это должно соответствовать взглядам команды разработчиков и при этом облегчить жизнь некоторым более требовательным системным администраторам.
9 лет спустя кажется, что идиоматичный Docker теперь покрывается Bitnami Discourse?
Однако в других разделах этого форума утверждается, что он потребляет много оперативной памяти и не поддерживается. Меня удивило, насколько велико трение в канонической настройке при попытке запустить её в облаке.
Многие современные сервисы, такие как Redis, PostgreSQL и хранилища, совместимые с S3, легко настраиваются и переносятся между различными хостами, такими как DigitalOcean, Supabase, AWS и другими, что делает бэкенд портативным. Виртуальная машина, на которой работает Discourse, также должна быть легко масштабируемой и заменяемой благодаря детерминированным сборкам. Жаль, что проект так близок к этой идеальной модели, но сдерживается.
Как отметил другой пользователь, это удивительно:
Логика, упомянутая ранее в теме, о том, что упрощение процесса может помешать коммерческим возможностям, кажется странной. Коммерческие организации имеют штат сотрудников для работы со сложными сборками, поэтому это в первую очередь затрагивает индивидуальных разработчиков. Мой личный случай: я управляю очень крупным (некоммерческим) сообществом. Поэтому это не относится ни к категории хобби по масштабу, ни к коммерческим проектам по выручке.
Э-э… Я раздумываю над созданием форума или сообщества и, конечно же, подумал о Discourse (потому что мне нравится пользовательский опыт), но снова уперся в стену из-за крайне враждебной установки и управления…
За годы я очень привык к тому, чтобы всё запускалось простым файлом docker-compose, добавляя пару дополнительных элементов (база данных, Minio для совместимого с S3 хранилища и так далее), но нет… Discourse по-прежнему крайне неудобен в этом плане.
Извините, но какой-то глупый «лаунчер» для запуска всего этого?
А затем процесс обновления сообщает:
Создайте новый базовый образ вручную, выполнив:
./launcher rebuild my_image
Извините, но вручную пересобирать образ? Что за чёрт… Это как использовать Docker, но на самом деле не использовать его…
Работает ли команда ./launcher rebuild app? Это стандартная команда.
Также, следовали ли вы стандартному руководству по установке?
У меня нет конструктивных комментариев, поэтому прошу вас попробовать обновить сервер Mastodon, Pixelfed, Moodle… Discourse действительно невероятно прост.
Одна ручная команда становится препятствием 