Is there an advantage to a Docker installation?

Installation
1

I know the documentation and a lot of threads here suggest that Docker is the only (good) way forward, but I wanted to know the reasoning. I got a $3.50/month Amazon Lightsail Debian box, and had Discourse up and running in 20 minutes. Used rbenv to install Ruby 3.2.2, and the rest was easy. I found Discourse to not follow Rails conventions either such as why is there a ./config/discourse.conf and GlobalSetting over the config/environments/production.rb specifying these values - is this what the Docker images end up creating (also sidekiq.yml not having production env values).

Is there an advantage to running this on Docker? Wondering if I’m missing something…

2

The really short version is that if you aren’t using the standard install we can’t offer you any assistance here. There are too many things that can go wrong if you deviate from that path.

4 Likes
3

Ahh got it, yeah, different OSes and what not. Already have someone asking how I did it - I’ll post here in case.

One needs Ruby 3.2.x (through rbenv, so you aren’t at mercy of the OS), Node v16.19.x/npm 8.19.x, and PostgreSQL (probably any version above 11).

  1. I created a .ruby-version file, which specified the ruby version which I installed (3.2.2).
  2. Did a bundle and all gems build just fine.
  3. Within PostgreSQL itself, had to setup the database:
CREATE DATABASE discourse;
CREATE USER discourse WITH password 'fA....';
GRANT ALL PRIVILEGES ON DATABASE discourse TO discourse;
\c discourse
GRANT ALL ON SCHEMA public TO discourse;

I was surprised the database.yml does not take production vars (this seems very anti-Rails convention). All db settings were in config/discourse.conf, along with the SMTP values. I filled those in.

Then ran the database migrations:

bundle exec rails db:migrate

All worked fine, and migrations were successful.

  1. In config/sidekiq.yml, after the development section, I added:
production:
  :concurrency: 2
  :queues:
    - [critical, 2]
    - [default, 1]
    - [low]
    - [ultra_low]
  1. Then edit lib/tasks/assets.rake, around line 151, add:
harmony: true,

so it looks like:

  uglified, map =
    Uglifier.new(
      comments: :none,
      harmony: true,
      source_map: {
        filename: File.basename(from),
        output_filename: File.basename(to),
      },
    ).comp

And install the following npm packages:

npm install terser
npm install -g uglify-js@"<3"

Then build the assets:

RAILS_ENV=production bundle exec rake assets:precompile

And voila! Now this should work:

 bundle exec sidekiq -e production -C config/sidekiq.yml
 bundle exec puma --config config/puma.rb -e production

This gets sidekiq and thepuma web server going.

(way cheaper, and more control, ie. I have Ruby 3.2.2 going already). Most of the time was working around the quirks (like looking for production values as they were not where they should be). But other than that, was quite quick!

2 Likes
4

That is pretty impressive. The problem as mentioned though if you run into an issue that breaks your site. Your potentially stuck with a very limited number of the community at large that might be able to help you fix things. So tye biggest risk/disadvantage is potential lengthy to catastrophic downtime that may require a complete reinstall.

The longer a site remains down the more loss of reputation and loss of members your site may experience.

If your just experimenting and not really reliant of a stable production site. Then not really risking much save time.

1 Like