ansible-discourse is an Ansible playbook I created to easily deploy Discourse without Docker. It supports several distributions, including CentOS, Debian, Fedora and Ubuntu. This installation method is completely unsupported so please don’t post issues to meta.discourse.org. Instead, open a topic here.
Testing and feedback are very welcome!
I am planning to test out discourse in coming weeks and came across this and might just be what I am looking for 
also a good time to learn ansible…
Is there any difference in performance between Docker vs No Docker??
Performance will generally be much worse without Docker, as you’ll lack all the special Ruby patches and Linux tuning we do on the Discourse docker image.
You will also likely run into support problems, which you’ll have to handle yourself.
Performance will generally be much worse without Docker, as you’ll lack all the special Ruby patches and Linux tuning we do on the Discourse docker image.
Where can I find the special Ruby patches? As far as I can see in image/base/Dockerfile, Ruby is installed with ruby-build without any additional patches.
I also couldn’t find any specific Linux tuning in image/base/Dockerfile. Should I be looking elsewhere?
There is tons of tuning in the Docker install.
From a very particular way of running unicorn (so it forks out sidekiq) to jemalloc, out-of-band gc and gc tuning.
The Ruby 2.2 image we have (which is enabled on meta) is a custom build of Ruby with method cache patches. Unfortunately, even patched we are struggling to meet the same memory and cpu perf we get on 2.0, hence it is not yet default.
A lot of the tuning is in the templates.
Ah ok, when codinghorror said “Linux tuning” I assumed he meant Linux kernel tuning 
. I agree there is plenty of tuning of other components and my aim was to replicate all of this tuning. (Though in fact, ansible-discourse does some kernel tuning too.)
ansible-discourse should also be doing all of these things. Tuning is done for Ruby/Unicorn (environment variables, jemalloc, workers etc), Redis (kernel tuning), PostgreSQL (shared_buffers, work_mem etc) and NGINX (workers, ratelimiting, spdy etc).
I’ve defaulted to Ruby 2.2 as I was under the impression everything was fine [1] [2]. Perhaps I’ll drop back to Ruby 2.0.
There should be no significant difference in performance. However, I have no benchmarks.
I disagree with @codinghorror . As mentioned above, my aim was to replicate all of the tuning from discourse_docker in ansible-discourse.
As you yourself noted, you were not aware Ruby 2.2 is a big performance regression. Nor did you know about the patches we use for Ruby 2.0. This is all fine, but you’re forking the install, and you will never know as much about Discourse performance as we on the Discourse team do.
Which is why people should stay on the Docker install, which always automatically reflects optimal Discourse settings, unless someone is basically holding a 
and forcing them not to use Docker.
You also lose the one-click web updater, of course.
edit: I don’t mean to sound negative, because I appreciate your hard work, but there is a reason we ask everyone to use the Docker based install, and it’s the only one we can support.
The public Discourse Docker image doesn’t contain any Ruby 2.0 patches as far as I can see.
Very true. But I won’t ever need to know as much because all of the optimizations in the public Discourse Docker image are public and can therefore be replicated.
Sure, for high-traffic sites with a need for guaranteed uptime etc, you need either a lot of in-house experience or to purchase premium support from Discourse. I’ve made it clear that this is unsupported, and I even encourage premium support in the README, so I’m definitely not trying to compete here! I’m really just sharing something that was originally just for private use, because there may be some people that find it useful.
Thanks for this Jamie. It is working well.
So is there any benchmarks that could show this significant difference?
I like the idea of Ansible set up much more than having a Docker container. Shouldn’t you guys work together on incorporating these mysterious patches into both methods instead of being so defensive?
We don’t have the employees or bandwidth to support multiple methods. All our wood goes behind one arrowhead – the Docker install, which we use everywhere, internally and externally, and that’s the only form of install we support.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.