(Re)Installing Discourse with Docker on CentOS 7

Installation
1

Hello,
I’m trying to resurrect Discourse on a CentOS 7 VM. It’s been a couple of days and I’ve learnt a lot but…

I keep coming up against the same problem no matter what I try. I have just cleaned up Docker:

docker kill $(docker ps -q)
docker rm $(docker ps -a -q)
systemctl restart docker
docker rm d509f29962eb
docker rmi $(docker images -q -f dangling=true)
docker rmi $(docker images -q)

I removed /var/discourse and re-cloned it:

git clone https://github.com/discourse/discourse_docker.git discourse

Then ran ./discourse-setup which complained that “DISCOURSE_SMTP_USER_NAME was left blank”

I ran (and get the same result everytime) ./launcher bootstrap app :

Output from bootstrap

Any ideas what I have missed?

Best regards.

1 Like
2

The output from which doesn’t look like an issue, that’s just the launcher looking for the right name to use for docker, but lines 2, 3, and 4 of that look like trouble.

flag provided but not defined: --format
See 'docker info --help'.
stat: cannot read file system information for ‘/var/lib/docker/aufs’: No such file or directory

The version of docker found doesn’t seem to be the one launcher expects. AND you don’t seem to have aufs, which is needed for a working Discourse install.

3 Likes
3

I’m not sure it is aufs. We restored a good backup to another VM and have the service working there. /var/lib/docker/aufs doesn’t exist on that VM. The storage driver on that VM is “devicemapper”. On the copy of the broken production VM (which has other services working on it) I’m trying to setup up Discourse and Docker on a partition with more disk space. That partition was already there and is in use but, I just discovered, is XFS and does not have d_type set. Strangely, without /etc/docker/daemon.json on the working VM the storage driver is devicemapper by default and on the “broken” VM copy it is overlay. I guess this is because docker knows it’s being written to XFS.

I’ll try reformatting tomorrow.

Thanks.

1 Like
4

Devicemapper is extremely unstable and a bag of suffering. You do not want devicemapper. The party line is that it “works” on Red Hat OSes but… we have not found that to be the case.

5

People have gotten devicemapper to work, at least mostly work, but it is not a recommended storage driver and I gather you’ll get mysterious errors.

6

The first lines show that you are using an old Docker version, can you upgrade to latest? Should be 17.05 or 17.06.

Also, the chown command failing indicates a bad file system, which can be devicemapper related.

2 Likes
7

After I submitted my initial post I was pointed to similar ones. As a result I re-formatted the bigger disk for XFS with d_type functionality enabled. And we put:

{
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true"
  ]
}

in /etc/docker/daemon.json from Redirecting…

This allowed us to install the container with the base discourse. After we added the socket template we got an error related to Nginx starting up in the container but quickly fixed that. We then restored the Discourse backup and now know how to resurrect the site in production. Thanks for your help.

1 Like
8

This topic was automatically closed after 2535 days. New replies are no longer allowed.