Recommended way to install Discourse?

There are two:

I usually just go with the simple method (1), and just have a container (app1, app2, app3 etc) for each forum. But I am considering going with the second option - although currently I am only running one Discourse forum.

  • Are there any other benefits to going with option 2? What does ‘powerful’ mean exactly - more performant?
  • Is it easy enough to set up? (Are there any sample ‘step-by-step’ guides that go through the set-up process?)
  • If I have a relatively busy forum, which option is preferred? (1 has served us well up to this point)

The forum is not ‘huge’ but fairly busy, we get about a thousand posts a week and serve over half a million page views a month. Which would you recommend for us? Shall we continue to use (1) for now and then move to (2) as our needs grow? (Currently moving to a new server hence considering this now.)

2 Likes

“Powerful” primarily means flexible. If you have needs which the basic install does not meet, then you can re-arrange components how you like. That benefit, however, comes with significantly more complexity. It sounds dismissive, but if you have to ask then the advanced techniques are probably too advanced.

The basic install is exactly what we recommend for most sites because it works with minimal attention. Do you want to interact with your community or play with servers? Only look into “advanced” techniques if you’re having actual problems with the basic method - and many problems can be solved by simply using larger instances to run it.

12 Likes

Thanks for the reply :slight_smile:

The current set up has not given us any major problems. Sometimes users say they get a Corrupted content error (which seems to be more of a DNS issue) and sometimes some users say the site is inaccessible on first visit - meaning they have to refresh the page to get onto the forum (I’ve never experienced this myself but then I always have the forum open in a tab).

What settings would you recommend for a forum of our size? The server, while does serve non-docker sites as well, has 64GB of RAM so I think we can up unicorn workers etc:

params:
  db_default_text_search_config: "pg_catalog.english"

  ## Set db_shared_buffers to a max of 25% of the total memory.
  ##
  ## On 1GB installs set to 128MB (to leave room for other processes)
  ## on a 4GB instance you may raise to 1GB
  #db_shared_buffers: "256MB"
  #
  ## Set higher on large instances it defaults to 10MB, for a 3GB install 40MB is a good default
  ## this improves sorting performance, but adds memory usage per-connection
  #db_work_mem: "40MB"
  #
  ## Which Git revision should this container use? (default: tests-passed)
  #version: tests-passed

env:
  LANG: en_US.UTF-8
  # DISCOURSE_DEFAULT_LOCALE: en

  ## TODO: How many concurrent web requests are supported?
  ## With 2GB we recommend 3-4 workers, with 1GB only 2
  UNICORN_WORKERS: 3

Any recommendations for these Andrew?

Running ./discourse-setup should configure that for you automatically.

1 Like

Ah nice that looks new! I usually just do:

	mkdir discourse
	git clone https://github.com/discourse/discourse_docker.git discourse
	cd discourse
	cp samples/standalone.yml containers/app.yml
	vim containers/app.yml   #Edit contents to reflect old config
	./launcher bootstrap app
	./launcher start app

When I run ./discourse-setup is it possible to give it a name, eg, app1 (so that’s where it puts its output) - I think on this server I am not going to have any named ‘app’, so that I don’t accidentally copy and paste a command and accidentally alter the wrong instance (this will also mean you can run this for multiple forums without it overwriting the original app).

A post was split to a new topic: Error when rebuilding with Discourse Solved

Unfortunately, no. That script will create container/app.yml from your answers (or reconfigure it if it already exists.) So you would have to rename it by hand afterwards.

2 Likes

Nice - it worked out a quarter of the ram and added 8 unicorns workers :smiley:

Quick question, in this section:

## The Docker container is stateless; all data is stored in /shared
volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

If I am going to be running more than one container (app1.yml, app2.yml, app3.yml etc) is it ok to leave the shared directories as they are (this one: /var/discourse/shared/standalone and this one: /var/discourse/shared/standalone/log/var-log) , or should these also be named to reflect the different app.yml’s? So app1 will have shared1, app2 will have shared2 etc.

I’m guessing leaving it to shared for all containers would be fine - but just want to double check…

Nope, you’ll need to use separate directories for each instance, otherwise they’ll all try using the same PostgreSQL data directory, which will end… badly.

1 Like

Thanks Matt. That’s what I did previously. However I left

      guest: /shared

(line 5) as that, and my previous installs worked fine. Should I change that per container too?

That leaves:

guest: /var/log

Which I left the same too, should this be changed per container as well? (eg /var/log1, /var/log2, etc)

Sorry for all the questions :relaxed:

No, the container-side paths should stay the same, otherwise the processes running in the container won’t be writing to the volumes.

1 Like

Thanks Matt.

So just to confirm (and for the benefit of anyone following this thread in the future) the only changes you need to make per app is on lines 4 and 7, where shared should be shared1 for app1.yml etc

1 ## The Docker container is stateless; all data is stored in /shared
2 volumes:
3  - volume:
4      host: /var/discourse/shared/standalone
5      guest: /shared
6  - volume:
7      host: /var/discourse/shared/standalone/log/var-log
8      guest: /var/log
``
2 Likes