Author's company should hire a proper devops person and then docker, magically —from the devs pov— will start working.
AUFS on production? Seriously? Create a BTRFS partition.
Docker isn't a shortcut to learning a linux based OS, it is a useful tool in the hands of people who know what they are doing.
If your company lost thousands of man-hours on a tool and has nothing more to show than a blog article with half the facts coming out of the author's head and the other half boasting about bad production practices, would you prefer me to sugar coat it?
A hire that knew linux and docker, would solve the problem.
I work with docker since 2013. I came to a team with devs that already used docker. I didn't know anything about it at the time. They gave me a docker image with a JVM based app, that had a two years old JDK, ran as root and the container was ran with privileges enabled.
Did I have to know docker to tell them that this was nuts? Nope, I had to know ops. For the same reason I knew AUFS before I learned about docker and I knew very well that I would trust AUFS on my NAS for media storage but not as storage for a production database.
Did I ever tell the devs how to write java? No. It isn't on my job description for a reason.
A linux guru will know that AUFS is unstable... but the problem is mentioned nowhere and Docker still uses it as the default filesystem for [most of] all cases.
The linux guru will know to avoid AUFS... but the replacement [overlay2] was rolled out very recently and it's only available in the latest OS and systems.
AUFS isn't included in the default setup of many Linux distributions. CoreOS, CentOS, RHEL do not have it. If I recall correctly, CentOS and RHEL will use the device-mapper driver by default and CoreOS the btrfs. I would speculate that the docker team gave so much attention to AUFS to lower the barrier to entry but it isn't the only option.
My choice is btrfs and it has been rock solid for me since the start. Of course one has to know a bit about btrfs and always leave a healthy percentage (I'd say 10% or more) of the filesystem free.
I think AUFS and overlay2 do have an advantage of their own though (apart the works-out-of-the-box). Due to the way they work, you can have shared memory between containers. Thus if I had to run many containers with a JVM app, I would give them a try to lower the tax on RAM.
> If I recall correctly, CentOS and RHEL will use the device-mapper driver by default and CoreOS the btrfs
CentOS & RHEL uses device-mapper with loopback device by default (and logs "Usage of loopback devices is strongly discouraged for production use. Either use --storage-opt dm.thinpooldev or use --storage-opt dm.no_warn_on_loop_devices=true to suppress this warning". Also related article [1]
CoreOS uses overlayfs by default now from a while [2]
> A hire that knew linux and docker, would solve the problem.
I'd pick a hire who also knew a platform. I like Cloud Foundry because I work on it, Red Hat folk would prefer OpenShift, there's also Deis and Convox and others I am cruelly neglecting.
Containers are a building block. An important one, they make new architectures practicable. But past a certain point, rolling a custom PaaS that you will have to maintain at your own expense, with no commercial or opensource support whatsoever, forever, doesn't make much sense.
AUFS on production? Seriously? Create a BTRFS partition. Docker isn't a shortcut to learning a linux based OS, it is a useful tool in the hands of people who know what they are doing.