What is best docker storage option for production environment

General
1

Hi, We started to use docker on centos 7 and currently we use default settings which comes with default rpm installation of docker and config files.

Can you please suggest me which storage option is good for production docker setup ?

I read on google and some suggest overfs and others are aufs. but not getting any concrete answer on this.

Thanks
Ben

1 Like
2

I think when in doubt see what docker tells their cooperate customers to install

https://www.docker.com/compatibility-maintenance

And the answer is device mapper. I think the key is just to make sure you use direct-lvm in prod and you should be fine. i have seen a lot of flakiness if you don’t do this

1 Like
3

The right storage driver to use really depends on your use case, how much up-front work you’re willing to put into configuring it, how much risk you can afford to take, and how much work you’re willing to put into supervising it and ensuring that nothing wacky happens once implemented.

devicemapper historically has been full of headaches. It can be incredibly flaky and slow, and I don’t think the upstream maintainers really like maintaining it very much. I’d use it only if all of the other options were not possible for you.

By far the most “plug-and-play” solution today is aufs, and this is largely why it is the default in many instances. aufs gets a lot of attention from upstream and any issue you encounter is likely to be run into by someone else first, helping with debugging. However, its negatives include some show-stopping bugs related to permissions which mandate hacky workarounds if you run into them. It will also most likely never land in the kernel directly, and is not as performant as some of the other drivers.

The up-and-coming star is overlay, which is directly in the Linux kernel (versions >=3.18 IIRC), but still has some issues with respect to its Docker integration. In particular, if you use overlay, follow these tips. Actually, you’ll notice in the sidebar that most of the storage drivers have “Foo in Practice” sections that are worth looking over. There have been some known issues with inode exhaustion and other bugs, but overlay is fast/minimal compared to AUFS and well-supported upstream, so this is actually a decent bet for the future.

If you are running a service where you can afford some occasional weirdness / bugs / downtime and also are willing to run overlay in all of the lower environments, I’d say it should be top of your list for investigating.

btrfs seemed quite promising initially but has had some stability issues (I’ve heard horror stories about having to periodically blow away /var/lib/docker completely).

zfs is fairly new in terms of integration with Docker, and has a reputation as “Not Ready For Production” on Linux, but would definitely be worth a look at, and has some pretty desirable characteristics, although I’m not sure if they come into play for using it as a Docker storage driver.

By the way, most of these are available to play with using boot2docker, so if you’re using Docker Machine, you can create using --engine-storage-driver flag to get a particular one on the created VM (or just edit /var/lib/boot2docker/profile directly and run sudo /etc/init.d/docker restart). Have a play!

Hope this helps,

  • N
3 Likes
4

Thanks for your response.

1 Like