I would rather say "goodbye docker", period. Having used it a bit, I have concluded that it is just not a very good or mature tool. Once you scratch under the surface, things cease to be easy or stop working at all. It makes you wonder how it's been this long and nobody stumbled upon an issue that you uncover 30 minutes into tool's use.<p>Docker does have it's uses, but in the majority of cases you are better off using native OS package and dependency management (RPM/YUM in the case on Redhat-based distros). One very obvious thing is that package managers usually track versions and dependencies and allow for install actions to happen based on the versions delta. With Docker you just replace the whole environment, which is fine, unless some of the data context is outside of Docker.<p>I think the majority of Docker uses are of a class "I can't figure out how to manage dependencies for a given OS, so I am going to skirt the issue by using Docker".
By default, Docker will use the AUFS storage backend if available, and then fall back to devicemapper on loopback.<p>RHEL, CentOS, and Fedora do not ship the AUFS kernel module because it is not part of the mainline Linux kernel and is unlikely to be included in future, and these distros have an "upstream first, no out-of-tree bits" policy. Instead, they recommend using devicemapper on LVM [1][2].<p>The same advice is provided in the official Docker documentation [3]:<p>> Docker hosts running the devicemapper storage driver default to a configuration mode known as loop-lvm... The mode is designed to work out-of-the-box with no additional configuration. However, production deployments should not run under loop-lvm mode... The preferred configuration for production deployments is direct lvm.<p>You might consider using CentOS Atomic Host, which comes preconfigured with LVM thin pools.<p>OverlayFS is also an alternative, but it can be problematic. It only implements a subset of the POSIX standard [4], which can cause some programs to fail.<p>[1] <a href="http://www.projectatomic.io/blog/2015/06/notes-on-fedora-centos-and-docker-storage-drivers/" rel="nofollow">http://www.projectatomic.io/blog/2015/06/notes-on-fedora-cen...</a>
[2] <a href="https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/getting-started-with-containers/#managing_storage_with_docker_formatted_containers" rel="nofollow">https://access.redhat.com/documentation/en/red-hat-enterpris...</a>
[3] <a href="https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/" rel="nofollow">https://docs.docker.com/engine/userguide/storagedriver/devic...</a>
[4] <a href="https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/" rel="nofollow">https://docs.docker.com/engine/userguide/storagedriver/overl...</a>
You can find some notes on tuning devicemapper here:<p><a href="https://jpetazzo.github.io/assets/2015-03-03-not-so-deep-dive-into-docker-storage-drivers.html#44" rel="nofollow">https://jpetazzo.github.io/assets/2015-03-03-not-so-deep-div...</a><p>If you've got a new enough kernel though (i.e. 3.18+), you're best off using Overlay for your storage driver. It's fast and doesn't require a lot of tuning.
I strongly DO <i></i>NOT<i></i> recommend using devicemapper as storage in Docker. Every time we have tried, and every customer who has tried, has failed medium to long term, in bad ways. It became so painful that we literally blacklist devicemapper as a supported filesystem in the Discourse installer.<p>We waited a year for this to "stabilize" but it never did.
I haven't used AUFS or overlay(fs), only devicemapper (thin provisioning) and Btrfs. Btrfs is faster than devicemapper, but even creating and removing containers seems slower than it ought to be considering how little delta there is. The create/remove time with 'btrfs sub crea/del' is much faster than docker create or remove (container), so I'm not really sure where the delays are.
Never had performance issues with the Docker device-mapper graph driver on Fedora 23. No tweaking was necessary. I imagine CentOS is similar although it may not use the latest and greatest features.<p>There is not enough information in this blog post to say exactly what the problem is, but switching distros may be overkill here.
For some background: <a href="https://developerblog.redhat.com/2014/09/30/overview-storage-scalability-docker/" rel="nofollow">https://developerblog.redhat.com/2014/09/30/overview-storage...</a><p>Overlay(fs) is likely going to be the way forward.
From the op:
"I enjoyed its minimal install to create a light environment, intuitive installation process, and it’s package manager."<p>CentOS is neither minimal nor light. Ubuntu also isn't either of these things. Both of these distributions are more targeted towards convenience and ease of use, which means a lot of features/services that are generally unnecessary are enabled by default. The main reasons to use CentOS is compatibility with proprietary software made for RHEL, Ubuntu for people already familiar with its desktop version, or if needing to buy enterprise support for either.<p>If the op is primarily looking for minimal and light, he should look at pretty much any other major popular Linux distribution like Debian proper, Slackware, or Gentoo before CentOS or Ubuntu.
I've had different trouble with Docker on CentOS 7. Last November, I created a POC Kubernetes cluster on top of the shipping CentOS 7 Docker infrastructure (1.8 at the time), and then beat the hell out of it. After a week or so, I lost a node to XFS file system corruption in the Docker image tree. The only solution I could find that worked was uninstalling Docker, wiping the Docker image tree in /var, and then reinstalling Docker. Kubernetes would then resume distributing containers to the node. Every node died in this manner at least once during the POC. With Kubernetes managing the containers, it wasn't a disaster - just really annoying.