Discourse Farm


(jon richter) #1

Continuing the discussion from unMonastery:

As far as I understand it, he is not opposed to experiment with running the original allmende.io discourse farm plus further sites.

Continuing the discussion from an email thread with questions from

  • James

Could you expand one layer on that please - e.g. how does a ‘discourse farm’ work?

A Discourse Farm is a frontend web server which directs requests depending on their Host Headers to respective data storage and database locations.

  • Thomas

I’ve just learned how to use docker etc, so I can not add much experience.

Doing a single instance docker installation was straightforward using the above link.

Pitfalls for me where configuration of google sign in, for which I had to set proxy_set_header Host $http_host; in nginx proxy rules.

  • How should the layout of a multisite docker installation look like?
  • Which services should be shared ?

Following https://github.com/discourse/discourse_docker/tree/master/samples this could be

  • data layer (postgres)
  • cache layer (redis)
  • web layer (ruby, nginx)

But, is it wise to have these layers installed in one vm ?
As I understand, if you want to separate things, making installs independent:
use one vm for a standalone install of a single discourse

Everybody is of course free to run their own instances. What we want to offer is a Discourse farm to minimize maintenance efforts.
As unMonastery and OSCED are already keen on using Discourse, plus TransforMap and its sisters already depend on it, running a single farm is just a subjective preference.

If one wants to increase performance, would one install docker directly to the main machine(s) and install the different layers there ?

I believe we are not yet optimizing performance issues. But it makes sense to think about it. We could easily separate a front end web server from databases.
The configuration should then somehow resemble a set of docker database containers which are linked to the web instance. I believe, as long as we are not using/offering an S3 compatible storage layer, data-only volumes for assets would also make sense.

  • James

Thanks for the info. Just to be clear - can I understand what the ’discourse farm’ is right now? Is it just a collection of several discourse hosts, or do you currently have some infrastructure that is shared across discourse instances?

Right now the Discourse farm is a VM in Denver/US which holds a couple of PostgreSQL databases, static asset directories and the frontend web servers.
All these would be decoupled within a migration to a Docker based farm.

FYI I’m trying to get the unMonastery discourse running in the next day or so, then after that’s up and running will try to see if we can move towards the ‘farm’ idea together.

Let’s continue this conversation here.


Open Source Circular Economy Days
(Thomas Kalka) #2

I still do not understand the idea of a discourse farm. As far as I understand, the “easy way” to go is to have one VM per discourse.

Why do we have to have something more complicated ?


(jon richter) #3

I wouldn’t call a Docker container a Virtual Machine. And I would try to avoid running only one Docker container per Docker host. Then we at Ecobytes, indirectly by me, are already running five Discourse instances, which can be centrally upgraded.

If we changed this to seperate containers, each one would have to be upgraded independently. From the hosting perspective, we can easily argue there may be more than these five Discourses anytime soon. Therefore it is in our interest to reduce maintenance effort and bundle upgrade paths.

Do you disagree?


(Thomas Kalka) #4

If the docker host is itself a virtual machine, then I do not see benefits in running multiple docker containers inside one host. By using one virtual machine per docker container you get total separation of instances.

If the docker host is a real machine, than it would be better not to have separated docker containers but share infrastructure.

Currently I want to focus myself only on running infrastructure for transformap. An own virtual machine for one docker container seems to be the easiest solution.


(jon richter) #5

@pierreozoux @pierre_ozoux (Which one to use?)

Discourse happily supports CoreOS! In combination with btrfs a killer.


(Pierre Ozoux) #6

Yeah, sorry for the mess, I just created an other account :confused: The current one is @pierreozoux.

Yes, I run discourse on CoreOS and it is totally fine!

But CoreOS removed btrfs, it was a mess.