Официальный «cloud native» образ Docker от Discourse

Привет,

команда недавно убрала поддержку отключения long polling через интерфейс. Это нарушило функциональность, необходимую для образа Docker от Bitnami, который использует Passenger и не работает (см. https://github.com/bitnami/bitnami-docker-discourse/issues/177). Образ Bitnami не передаёт параметры окружения напрямую, поэтому проблема остаётся нерешённой до тех пор, пока кто-то не расширит этот образ (см. DEV: Drop `enable_long_polling` and `long_polling_interval` settings by tgxworld · Pull Request #16323 · discourse/discourse · GitHub).

У меня возник вопрос: раз Discourse уже распространяется только в виде Docker-контейнера, есть ли у команды планы по поддержке «облачно-нативного» образа Docker?

Главное различие между образом Bitnami и вашим — это режим работы. Современная инфраструктура предполагает возможность автоматизации установки. Обычно в Kubernetes это делается с помощью Helm, но даже развёртывания через Ansible в более традиционных средах с виртуальными машинами приводят к аналогичному результату. Поэтому то, что действительно сделало бы Discourse наравне с несколько заброшенным образом Bitnami, — это добавление автоматической процедуры установки и, возможно, даже адаптация шаблона Helm.

Раз уж я здесь, позвольте оставить несколько замечаний по самому Discourse и его «облачной готовности»:

В целом, когда мы пытались интегрировать Discourse в воспроизводимую настройку для текущего проекта клиента, очень быстро стало ясно, что Discourse никогда не разрабатывался с учётом требований современной инфраструктуры. Один из примеров — необходимость общего хранилища NFS. Это ни надёжно, ни масштабируемо. К счастью, большую часть этого уже можно перенаправить на S3, но остаются части, связанные с плагинами.

Есть три способа решить проблему с плагинами:

  • Выполняемый код, хранящийся в базе данных (не рекомендуется)
  • Предварительно упакованные sidecar-контейнеры (в терминах Kubernetes это были бы initContainers, записывающие данные в emptyDir), которые пишут в волатильное хранилище (например, tmpfs) до запуска контейнера Discourse (рекомендуется, хотя и не очень удобно)
  • Процедура установки, которая при запуске получает из базы данных информацию о текущих плагинах и их команды установки, а также механизм слежения/прослушивания для установки плагинов во время работы (не рекомендуется, так как это очень медленно и подвержено ошибкам)
3 лайка

Кажется, это уже довольно подробно обсуждалось здесь:

3 лайка

Честно говоря, раз Bitnami уже легко это решила, нет особого смысла так много об этом обсуждать. Сделать лёгкое развёртывание Discourse — это не ракетостроение.

Хочу отметить, что мы разворачиваем множество сайтов Discourse в облачных средах, и при этом не используем хранилище NFS. Активы и загрузки обрабатываются через объектное хранилище (S3), а исходный код (ядро и плагины) сохраняется в образе контейнера, созданного при запуске.

4 лайка

Это уже было отвечено: К счастью, большая часть этого уже может быть перенаправлена на S3, но остались части, которые являются плагинами. Создание контейнера заранее для использования — плохая практика, так как это увеличивает риск неправильного обновления с помощью используемых helm-чартов.

Не могли бы вы подробнее объяснить это? Я не понимаю, почему плагинам требуется общее хранилище NFS.

Мне очень жаль, но у нас уже есть эта эпичная тема для обсуждения.

Я не хочу разделять это обсуждение. Если есть какие-либо идеи, их следует обсудить здесь:

3 лайка