# Official "cloud native" docker image from discourse
**URL:** https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568
**Category:** Feature
**Created:** [May 31, 2022, 9:29am UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568 "2022-05-31T09:29:08Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@wzrdtales](https://meta.discourse.org/u/wzrdtales)
#### Post date: [May 31, 2022, 9:29am UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/1 "2022-05-31T09:29:08Z")
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 [https://github.com/bitnami/bitnami-docker-discourse/issues/177](https://github.com/bitnami/bitnami-docker-discourse/issues/177). 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](https://github.com/discourse/discourse/pull/16323).
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)
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [May 31, 2022, 11:19am UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/2 "2022-05-31T11:19:18Z")
I think this has been discussed pretty extensively here:
> [@Can Discourse ship frequent Docker images that do not need to be bootstrapped?](https://meta.discourse.org/t/can-discourse-ship-frequent-docker-images-that-do-not-need-to-be-bootstrapped/33205):
>
> There is this [open issue](https://github.com/discourse/discourse_docker/issues/186) (which I just closed) on Discourse Docker repo asking Discourse should behave like a standard docker image a docker user excepts to be able to run discourse without a special launcher. to define multiple containers (redis, postgres, discourse,..), links and volumes, docker-compose should be used instead. [Docker Compose | Docker Docs](https://docs.docker.com/compose/) The question is somewhat misguided, but I would like to address a broader one of Can Discourse ship frequent Docker images that do …
---
### Author:  [@wzrdtales](https://meta.discourse.org/u/wzrdtales)
#### Post date: [May 31, 2022, 4:45pm UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/3 "2022-05-31T16:45:47Z")
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.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [May 31, 2022, 6:08pm UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/4 "2022-05-31T18:08:44Z")
> [@wzrdtales](#):
>
> One example is the need of a shared NFS storage.
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.
---
### Author:  [@wzrdtales](https://meta.discourse.org/u/wzrdtales)
#### Post date: [May 31, 2022, 6:54pm UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/5 "2022-05-31T18:54:36Z")
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.
---
### Author:  [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [May 31, 2022, 7:02pm UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/6 "2022-05-31T19:02:51Z")
> [@wzrdtales](#):
>
> 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.
Can you please elaborate on this? I don’t see how plugins require shared NFS storage.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [June 1, 2022, 5:41am UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/7 "2022-06-01T05:41:43Z")
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:
> [@Can Discourse ship frequent Docker images that do not need to be bootstrapped?](https://meta.discourse.org/t/can-discourse-ship-frequent-docker-images-that-do-not-need-to-be-bootstrapped/33205):
>
> There is this [open issue](https://github.com/discourse/discourse_docker/issues/186) (which I just closed) on Discourse Docker repo asking Discourse should behave like a standard docker image a docker user excepts to be able to run discourse without a special launcher. to define multiple containers (redis, postgres, discourse,..), links and volumes, docker-compose should be used instead. [Docker Compose | Docker Docs](https://docs.docker.com/compose/) The question is somewhat misguided, but I would like to address a broader one of Can Discourse ship frequent Docker images that do …
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [June 1, 2022, 5:41am UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8 "2022-06-01T05:41:47Z")