You don’t. (And you don’t want to use aufs.) Just use devicemapper. But set it up for real instead of these testing-grade loopback files. – Michael Hampton
I haven’t changed anything with docker or anything else on the server - is there any reason why this warning is appearing now?
Should I change to Aufs?
Will it affect the rest of the server? (There are other sites including non-docker ones on the server).
The reason why we have historically been so completely and utterly down on devicemapper as a storage driver is because it has, historically, been appallingly bad. So many support requests from people saying their sites were slow, blew up, or what-have-you. It is entirely likely that many of those problems are gone now, on the latest versions of various distros, but here’s the thing: we don’t know that, we don’t have the time or inclination to find out, and even if we did, there’s still puh-lenty of people out there running the older, buggy distros that will blow up if they use devicemapper. So, we don’t want to take the risk of saying “yep, devicemapper is now fine and dandy” because it’ll end up being a near-guaranteed pain in our rumps.
If you are a suitably advanced user, who is capable of dealing with making sure that devicemapper works fine in your specific environment (and potentially dealing with the fallout if it doesn’t), neutering the storage driver check in launcher should be easy peasy lemon squeezy. For everyone else, there’s mastercardaufs, which we know works (it’s what we use for all our hosting).
Unfortunately Ubuntu is not really an option - the server is running CentOS with a number of sites on it (non-docker). I’m also used to it as I’ve used it for over a decade and I love how rock solid it has been for us. Changing a whole OS just to use Discourse/Docker seems a bit drastic tbh particularly one that is known for being extremely reliable.
With regards to this warning, if I ignore it, will Discourse just run as it always have? (Which has been fine to date - apart from once when uploaded images to a thread just disappeared - would this have been related?)
Is there anything else I can do to make it ‘less-bad’? Such as update other packages etc?
Well I don’t know that’s why I am asking (I thought I read somewhere that the warning is only showing now because the check for it wasn’t properly working before).
If it is a no-go then I guess this means I am locked in to my current version for the foreseeable future (unless I can use an alternative to devicemapper without it creating issues for everything else on the server/not requiring a reinstall of OS etc).
Consider me confused… I thought aufs was the driver inside the docker container? Why does it matter what OS the docker container is running in to switch the container storage driver?
If you haven’t had problems so far, then you’ll probably be fine – although the issues with devicemapper have, in the past, tended to be of the “delayed fusing” variety, so you maybe have just been lucky to date. It all depends on whether the version of CentOS you’re running is sufficiently “fixed” or not.
Oh, and to answer your original question:
That’s because the check was buggy (so it never actually showed up for anyone), and I fixed it.
Note that staying on an old version of Discourse won’t help you – the problem with devicemapper is not a specific incompatibility with the latest version of Discourse, but an unspecific “when you use it, things tend to go wrong eventually”.
Staying on an old version will only get you into more trouble because of unfixed security issues.
I’m not sure Sam - I am currently on CentOS 7 with the 3.10 kernel, and it looks like I need to upgrade the kernel to 3.18 for overlayfs.
However what’s a more pressing concern is whether I can do this and just ‘switch’ as is without having to reformat the whole machine and reinstall everything. Would you know the implications of changing the storage driver with this regard in a server already in production?
Switching is easy from our perspective. We keep zero critical data in docker containers, your database and images all live outside the container on the local filesystem.
Switching storage engines will nuke every container and image you currently have, but a ./launcher rebuild app will bring Discourse back just fine. Depends if you are using docker for anything else except for Discourse.
particularly one that is known for being extremely reliable.
(unless I can use an alternative to devicemapper without it creating issues for everything else on the server/not requiring a reinstall of OS etc).