Oh man that’s tragic. So sorry to hear 
7 Likes
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam and this topic make it clear, this will never be solved although bitnami just did it…
At least we got an answer to our question which is no.
What about avoiding to use root in the first place? Using fakeroot shows that the main stopper are the hard coded paths (such as /var). Otherwise, except the various bugs and issues the current setup has, it could work.
It is a pity to see such a great software having such a badly designed mandatory setup procedure, based on common misunderstanding of containerization. It is clear to me that it has been done with the best intentions; still, the result is something that cannot be deployed anywhere outside a hobbyist environment.
1 Like
Our image run as discourse user, and I think the official one as well.
But anyway, it is great that the “corporate” world is interested, because it has a lot more time/money than the hobbyist one 
I’m sure the community will appreciate your contribution to improve the ecosystem!
1 Like
This is certainly not correct, we deploy our image using nomad across fleets of machines, there are upwards of 10000 discourse containers running in aws and metal this very second
3 Likes
The tools require root to run, and they need to have access to the host /var.
I often cooperate with opensource communities and companies to improve their container setup. I would be glad to help and/or to consider funding to have a more reasonable containerized setup.
It’s not mandatory. It’s just that if you need hand holding to get it set up, that’s the way to do it. I’ve helped clients using gke, eks, ecs, for example. You’re welcome to contact me if you need help with your particular requirements.
/var isn’t hard coded; I worked with someone recently who had it in /var/www/discourse (which seemed like a very bad idea, as it runs the risk of serving secret data to the web, but it was a “policy”.
It’s not badly designed, it’s badly designed if you were to design it today rather than a decade ago. It was a good design then, and it still works to run their infrastructure and even for many people who know nothing about system administration.
2 Likes
I guess you are not relying on the official tooling such as discourse-setup, which requires root to be executed, and it is probably meant for a local setup.
Take a look at the discourse-setup source. If you’re familiar with configuring and performance tuning Discourse then it’s not mandatory.
Launcher does all the heavy lifting to build the image from the resultant yml.
2 Likes
Everything can be done, but it looks an unnecessary effort to me.
- Use
fakerootbefore every command - /var can be changed by editing the yaml file:
sed -i "s;host: /var/discourse;host: $PWD/discourse;g" containers/*.yml -
--skip-connection-test(found by looking at the code, because the script is not able to check the connection if there is a reverse proxy) - I see something related with certbot I know already I would need to figure out how to disable since SSL offloading is usually done externally
- containers/app.yml ports can be changed so that >= 1024 ports are used, but it does not seem enough:
Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
I do not want to be mean, but having multiple services running in a single container has always been a bad design, since it means having little o no way to know what is happening to the individual services, having to set up a custom log parser mechanism outside of Docker, no useful healthchecks, cannot easily rely on an external database, etc… It can be done if that is the only service you run in your business, but if every other service starts to do that, most of the benefits of using containers are just gone.
I would be happy to send some PR and documentation to make Discourse work on a Docker-compatible environment without root access, but decoupling the services and have a standard setup would be a big task with no assurance that it would get mainlined.
If you disagree with fundamental aspects of how Discourse is built have you considered using a different product?
1 Like
Ok, I understand better.
Discourse has a strong opinion on the tooling to self host. It allows them to provide efficient support to most not so experienced admin that want to deploy discourse. You can agree or not, I was also a bit sad in the past, but now I understand better 
If you have a different need than a quick up and running like most people do, then you are mostly on your own. Once you know it, that’s fine
We have the same need for a standalone discourse docker image. We run it on kubernetes with minio, it was a bit of a pain to make it running, and it is still a lot of effort. We got some nice help from discourse as well to make it so.
Our work is available here:
(it is not enough documented, nor tested, nor maintained or updated in time, or automated, and probably a bit custom, it is what it is)
If people are interested to improve it, don’t hesitate to come and PR, or chat here: https://matrix.to/#/#libresh:liiib.re
But yeah, discourse team has a strong opinion about the discourse community version. You can agree or not, but they provide most of the support to the people, and the little I saw, it is an amazing support, so I think it was a good decision
6 Likes
These are fundamental aspects of how Discourse is packaged, more than Discourse itself, which is a great software, but you are right, I should consider different solutions.
2 Likes
You’re welcome to remove the templates for postgres and redis (as well as ssl and let’s encrypt) and use your own.
2 Likes
Thanks for sharing. I also found GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar and images from bitnami. The main problem is that these solutions are not officially supported. I wonder if it could be an idea to have community-supported alternative Docker setup, instead of having various custom repository, as it would not be efficient to do spread the effort over multiple places.
1 Like
You are right, the settings can be changed indeed. If I get it running without a big effort, I will try sending some PR to improve the existing tooling or documentation, such as running it without root. That should be compatible with the opinions of the development team, while bringing some relief to some more demanding sysadmins.
9 years later, it seems like idiomatic docker is covered by bitnami’s discourse?
But elsewhere in this forum there are claims that it’s a ram hog and is unsupported. I was surprised to see how much friction there still is in the canonical setup when trying to get it running in the cloud.
A lot of services these days like redis, postgres and s3-compatible storage are easy to setup and move between different hosts like digitalocean, supabase, aws, etc, so the back end is portable. The vm running discourse seems like it should also be easy to scale/swap with deterministic builds. It’s a shame that it’s so close to this ideal but held back.
Like another user said, this is surprising:
The logic alluded to earlier in the thread that making this easier might hinder commercial opportunities is a strange one. Commercial interests will have staff to deal with the complex builds, so this is hitting solo devs more than anyone. My personal use case is that I run a very large (no profit) community. So it doesn’t fall under hobbyist by scale or commercial by revenue.
1 Like