I really would like to have an official helm chart for discourse with an official docker image.
I just opened this issue.
I’d like to have the consent of the discourse maintainers to make this happening.
Hope you can help make this happen. All you need to do is to give a yes 
Thanks!
Its hard to give a yes when its unclear what exactly is being proposed and how much extra work it introduces us.
@sam if discourse agree on having an official docker image, we need:
docker repo under discourse organization (or call it official-docker or as you want)pierreozoux and docker-library-bot
And I’ll take care of the rest. You don’t need to get involved except if you want to.
If you want to get even less involved, then just agree on the issue I mentioned. I’ll see with docker to create a repo for the Dockerfile.
Anything official means we 100% own it and are fully responsible for it, so my default answer on these kinds of requests is generally gonna be a hard no.
Can you describe the exact mechanics of what you are proposing here?
You might want to walk before you run. Start by making something unofficial, that works, so everyone can see (a) that it works, and (b) how it works.
This is an official docker image - official here is an adjective for docker. Think of it as a debian package.
In debian, I wouldn’t need your agreement to make a debian package (except if you specifically disagree).
In docker, it is a docker policy, I need an agreement from you, it is better.
This still doesn’t mean you have to support it. We could still state that the official way of installing it is with the laucher and this is not official discourse thing, just a community effort.
Ok, just realized it was the wrong link in the original issue, I pointed to this issue with a bit more background. (will updated the post)
I’m running this docker-compose since 2 years in production.
I host around 5 forums with that, the last one being forum.chatons.org a collective with 58 free software hosters in France.
I already created 4 official docker images (rocket.chat, Nextcloud, piwik…). And also did the official helm chart for rocket.chat.
As a day job, I work as a consultant to help companies to migrate to kubernetes.
During my docker trainings, I actually make people dockerize discourse 
I find it nice as it is a real example!
I developed a docker-compose PaaS called libre.sh and we are rebooting the project with kubernetes. I just think that I’ll migrate first the discourses, that’s why I’m here again to discuss about this topic.
What makes me want so hard this official image is the talk for the freedom box. I want to push my changes upstream to collaborate. Of course, I can maintain my little docker image on my side, but many people are doing the same, and it is so much valuable engineering time lost… it makes me sad.
I hope I managed to convince you, i still have some arguments in my pocket!
This sounds great!
I’m curious, what’s your way around pg major version updates?
Our launcher based image handle everything for the end user automatically, but people using an external image will have to deal with it themselves right?
Looks the community can’t agree in a way forward: https://github.com/docker-library/postgres/issues/37
I never did that (yet - never had to), but I’ll try in the coming weeks, now I’m curious 
(and well, this question, is obviously not part of the discourse docker image)
I really do think you did a great job with this launcher, but we are sys admins, and I think we all love our standardization, and this is not standard. i think it is really perfect for the one that want to quickly get started on a droplet. But yeah, for docker image, people will have to deal with that themself.
And we’ll need to put a big warning about that specific.
I’m very excited about this project 
.
I see that you run sidekiq and unicorn in separate containers, so that mean it will use, at least, double the resources when using this setup. No problem, since this will be only for very advanced setups.
Also, assets / migrations run on every boot.
And, what do you think about plugin support? Today, we use clone those before the bundle install using a launcher hook.
Some additional questions,
How do you handle logging and log rotation considering even a minimal rails install of Discourse with NGINX in a dedicated container would still have, unicorn and production logs.
What I love about standardisation is that there are so many standards to choose from.
It absolutely is - getting that right is pretty much the most complex part of the launcher & build process. (This is partly because it doesn’t run very often, so there’s not very many chances to improve it.)
Last time it happened, if I remember correctly, people had problems for weeks (as the updates filtered in) due to a very long list of reasons the update could fail.
As your docker-compose stands now, you’re relying on either (1) the official postgres image recognizing and performing an upgrade or (2) do it manually.
While (1) would be nice in the case of a skipped upgrade & an upgrader that can’t skip that far - you could use the intermediate images! it’s great!
However, I don’t think the official postgres images will actually do that for you.
Which resources? a docker container is really just a process, so as now, it will use the memory for 2 processes. It will share the docker image, and create a writable layer on top. So the added resource is really just this new layer, but it is really small.
Yes, for that, at first at least, it will be manual.
I really like the documentation and approach from mastodon, and will follow that.
Then, on kubernetes, we can get smarter.
Currently, I clone them on the host, and it works okay-ish. I have still to figure some little quirks.
I’ll try to keep it simple for the docker-compose version, but on kubernetes, again, I think we can be smarter.
But this is outside the scope of the docker image in itself.
Once actually, somebody added that logic in the docker image But I’m not sure I like this logic.
I’m open to propositions of course.
This image will have just rails. NginX will run in a separate container.
About the logs, this is not the responsibility of rails to handle this, rails should log to stdout and docker or whatever container runner will take care of those logs.
Just opened a PR to add the possibility to discourse to log to stdout.
@riking again, the best I can do is to warn the user something like:
/!\ This is not officially supported by discourse, if you don’t know what you are doing, use the launcher instead.
For instance, there is no easy path to upgrade the underlying postgres whereas this is handled gracefully in the launcher.
Use this image at your own risks.
What are the next steps? Can you create the repo that can receive the Dockerfile?
Or what is missing from my side?
Thanks for your help!
The official image forks the Sidekiq workers off the Unicorn processes, so they share some of their memory.
Thanks didn’t know, I’ll implement this I think, as rails is an hungry beast!
I predict you’ll have a lot of these sorts of things. If you diverge from how our image does things, you have to know why, otherwise you’re setting everything up for a horror show.
Don’t exaggerate, I’ve been running this for 5 (little) forums for 2 years now, I’m still sane.
Do you want to keep discussing every little detail, or should we get the repo to start actually working toward this official docker image?
I think all of this has already been discussed, and I really don’t want to go back to this discussion. I want to have the ball rolling to have a community docker image.
If you don’t want, please just let me know, I still have some ideas to convince you, but yeah, let’s try to keep focus.
The concern is that we have a way that works. Introducing another way has the potential to cause a bunch of people trouble. And then they’ll go away with a bad taste for discourse because it didn’t work.
I make a part of my living doing installs (most is from imports).
I’ll be willing to do some testing and see how your setup works. Can I test it out?
Yes, actually, I do want to discuss every little detail, because the details matter. We care very much about the experience of people who decide to self-host Discourse, and invest a lot of time and effort in making that as efficient and straightforward as we possibly can. A lot of hard work has gone into making the current setup work well, and throwing all that out and going back several years just because it doesn’t use this month’s “container orchestration” hawtness does not seem like a good tradeoff. Sure as heck we’re not going to put any sort of “official” stamp, or even tacit endorsement, on a deployment method which is worse in any way than what we have now.