Official "cloud native" docker image from discourse

feature
1

Hey there,

the team recently dropped support for disabling long polling over the interface. This broke functionality required for the bitnami docker image, which uses passenger and does not work see Enabling Long polling causes requests to queue · Issue #177 · bitnami/bitnami-docker-discourse · GitHub. The bitnami image doesn’t pass through environment parameters directly, so this is broken until someone extends the bitnami image, see DEV: Drop `enable_long_polling` and `long_polling_interval` settings by tgxworld · Pull Request #16323 · discourse/discourse · GitHub.

Of course the question for me came up, since discourse is already only distributed with a docker container: Is there any chance the team will maintain a “cloud native” docker image?

The big difference between the bitnami image and yours is the mode of operation. Modern infrastructure expects that you can automate the installation. Usually in k8s done with helm, but also ansible deployments in rather traditional environments with VMs would result in the same outcome. So what would actually make discourse on par with the rather neglected bitnami image is adding an auto installer routine and maybe even adapting the helm template.

As I am here already, let me leave some feedback about discourse itself and its “cloud readiness”:

In general when we tried tying discourse into a reproducible setup for a current customer project it showed quite fast that discourse was never made under the aspects of modern infrastructure. One example is the need of a shared NFS storage. That is neither reliable, nor scalable. Luckily most of this can be redirected to a S3 already, but there are parts left which are the plugins.

There are three ways to solve the plugin issue:

  • Evaluated code stored in the database (not recommended)
  • Prepackaged sidecar containers (in kubernetes terms that would be used as initContainers writing to an emptyDir) writing to a volatile storage (i.e. tmpfs) pre startup of the discourse container (recommended, even though not super comfortable)
  • An installer routine, getting current plugin information and their install commands from the db on startup and a watcher/listener routine to install plugins at runtime as well (not recommended, b/c super slow and error prone)
3 Likes
2

I think this has been discussed pretty extensively here:

3 Likes
3

Honestly, since bitnami solved it easily, there is not much reason to discuss that much about it. It wouldn’t be rocket science to make discourse easily deployable.

4

Just wanna point that we run many Discourse sites in cloud environments and we don’t use a NFS storage. Assets and uploads are handled via object storage (S3) while source code (core and plugins) are persisted in the bootstrapped container image.

4 Likes
5

Well that was already answered: Luckily most of this can be redirected to a S3 already, but there are parts left which are the plugins. Building a container upfront to use is a bad practice since it increases the risk of not upgrading properly over the used helm charts.

6

Can you please elaborate on this? I don’t see how plugins require shared NFS storage.

7

I am so sorry but we already have this epic topic to discuss this.

I do not want to splinter this off. If there are any ideas they should be discussed at:

3 Likes