I had to make a few tweaks in order to run the Discourse base Docker image. First, I got the following very clear error:
discourse docker this version of runc doesn't work on cgroups v2: unknown
I had to switch from cgroupv2 to cgroup
grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
At which point I was at least able to run through the configuration. This yielded an access denied error attempting to create /shared/postgres:
Configuration file at updated successfully! Updates successful. Rebuilding in 5 seconds. Building app Ensuring launcher is up to date Fetching origin Launcher is up-to-date cd /pups && git pull && /pups/bin/pups --stdin Already up to date. I, [2020-08-11T18:15:03.664400 #1] INFO -- : Loading --stdin I, [2020-08-11T18:15:03.672609 #1] INFO -- : > locale-gen $LANG && update-locale I, [2020-08-11T18:15:03.746912 #1] INFO -- : Generating locales (this might take a while)... Generation complete. I, [2020-08-11T18:15:03.747838 #1] INFO -- : > mkdir -p /shared/postgres_run mkdir: cannot create directory ‘/shared/postgres_run’: Permission denied I, [2020-08-11T18:15:03.754890 #1] INFO -- : FAILED -------------------- Pups::ExecError: mkdir -p /shared/postgres_run failed with return #<Process::Status: pid 21 exit 1> Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn' exec failed with the params "mkdir -p /shared/postgres_run" d98ee8471413ad77ab27ed3506f12c5c94a2b6902622faf4d88d5dbb51a10f63 ** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one. ./discourse-doctor may help diagnose the problem.
Gut was that I encountered an SELinux problem. Turns out I was right. There’s a lot of reading you can do about SELinux and Docker — this, for one — but the quick and simple solution is to run the docker container in privileged mode (note: this may not be a good idea in your specific scenario. understand what privileged mode is and the risks it entails). To do so, edit the launcher script (/var/discourse/launcher in my case) and add “–privileged” to user_args:
And finally (and this may well be a RTFM thing) — you’ve got to have your public DNS set up & whatever firewall rules to get traffic to the http:// website you are trying to build in order to use the LetsEncrypt SSL cert and configure HTTPS. It uses the file-based verification (i.e. create a file named xyz in /path/to/xyz.whatever on your web server, lets encrypt grabs the file and verifies it exists) which fails quite spectacularly when the Internet at large cannot access your about-to-be-a-discourse-server.