I am setting a new discourse installation on a dedicated server running CentOS 7. When I run ./launcher bootstrap app to launch the new server I get the following error:
which: no docker.io in (/sbin:/bin:/usr/sbin:/usr/bin)
Your Docker installation is not using a supported storage driver. If we were to proceed you may have a broken install.
aufs is the recommended storage driver, although zfs/btrfs/overlay and overlay2 may work as well.
Other storage drivers are known to be problematic.
You can tell what filesystem you are using by running "docker info" and looking at the 'Storage Driver' line.
If you wish to continue anyway using your existing unsupported storage driver,
read the source code of launcher and figure out how to bypass this check.
I have executed both systemctl start docker and systemctl enable docker and I donât get any errors. When I try to run docker info | grep Storage Driver the system returns an error Cannot connect to the Docker daemon. Is the docker daemon running on this host?
AUFS is not supported on CentOS. You have to use overlayfs if you would like to stick with CentOS 7. I have a post in that same topic you linked, read that carefully.
I managed to get Docker to boot after full uninstalling Docker and then running the following command:
wget -qO- https://get.docker.com/ | sh
This set us up with the most recent version of Docker, 17.04.0-ce.
I had to let Docker recreate /var/lib/docker because with the existing folder in place from previous installations of Docker, the service kept using the devicemapper storage driver:
Thatâs great news. Does centos have itâs bad docker installed by default? Discourse-setup runs that docker install script. Should it just work or should it uninstall docker and then run get.docker.Com?
The version of Docker that is currently installed via yum install docker is Docker v1.12.6 from back in early January 2017. We followed an installation guide from a year or so ago that had us install Docker via yum so we just assumed at first that it was fine. Strangely enough it didnât mention anything about configuring Docker to use the overlay storage driver so maybe Docker back then used it instead of drivemapper that we kept seeing with 1.12.6.
You mentioned something called âdiscourse-setupâ - is there a new command-line tool for installing Discourse?
Yes. It mostly helps walk new users through configuring their app.yml without actually opening it. There may a few more checks (like for swap, unicorns, etc) or they could be in bootstrap (which is run by setup) Iâm not sure where they are.
Hello. I am new to discourse and I am not even sure if I should post here or start a new topic. I inherited a Discourse installation (have no idea how it was installed) and I wanted to upgrade it (on Ubuntu 14). In the upgrade page of Discourse, it is requested to upgrade from 1.8.0 to 1.9.0 and first I am requested to upgrade the docker. So after upgrading docker from the web page, it returns a page with the message âYou are running an old version of the Discourse image.â and instructions to pull the discourse_docker from git and rebuild it. On rebuilding, it says âYour Docker installation is not using a supported storage driverâŚâ. After reading this topic (since I had almost no idea what a docker is and how to manage it), I run docker info and it says the storage driver is devicemapper. I saw in another post that I should edit â/etc/sysconfig/docker-storageâ to set the storage driver, but I am afraid of not losing the discourse data (and database). Is it safe to change the storage driver? Beside this, I would like to know if there is a safer way of updating discourse_docker (maibe from a release) since the sources on git are continuously changing. Thank you for any response.
Where is this install hosted? If on something like DO, it may be quicker to make a new droplet, install Discourse, and restore Discourse. Youâll just have to deal with DNS.
@mpalmer should be able to confirm, but I do believe they said in the past it was non-destructive for data.
Yes, changing the storage driver will cause a rebuild to be needed, but it shouldnât (absent non-standard changes to configuration that we canât account for) cause any data loss, because the database, uploads etc are all kept on volumes that are outside of Dockerâs direct remit and control.
Ok, thank you, I will try to change the driver (I will also make a discourse backup so I hope it will be fine - it is a production machine so this is the reason why I am so carefull)