Alternative to Fuxi

By the way: If you don't like Fuxi, you can turn to the alternative cinder-docker-driver [1]. In principle, it works much like Fuxi: A daemon plays the translator between Cinder and Docker on the Docker host, and the corresponding Docker plugin consumes the output. This solution, also based on Go, is not quite as complex as Fuxi and comes without Kubernetes support.

Containers in VMs

Recently, it has become increasingly fashionable to run Docker containers in VMs that in turn run on OpenStack. This nested virtualization might seem strange at first glance, but there are good reasons to do it this way: You do not have to provide your own metal for your Docker containers but can directly use the infrastructure available in a cloud. The performance on a VM is not automatically worse than on real hardware. However, with regard to Docker, you should note one important point in this scenario: Because the available memory is usually managed by OpenStack, but Docker runs in a VM, it cannot directly access the Cinder memory, so it is not necessary to attach volume plugins to Docker.

All storage management is done in OpenStack in this case. For Cinder, it is only relevant that it sees the storage device attached to its host VM. With the normal volume driver, it can then be integrated into containers. You do not get a high-availability problem in this scenario either: If the container data for Docker is on a Cinder volume, it is already implicitly redundant if the underlying memory offers this function. If the original VM with the Docker container fails, you can restart it on another host with the same data and the service works as usual.

VMware Cloud Alternative

VMware has been active in the virtualization market for decades, so it's no wonder the software is so widespread. vSphere as a comprehensive solution for virtualization is particularly common in larger companies. However, the challenge that vendors face with respect to Docker volumes in VMware is no different from OpenStack: Much like OpenStack, vSphere comes with its own storage management, vSphere Storage, that mounts storage in the background so that it can be used seamlessly in vSphere. A provider that now wants to supply Docker containers with persistent storage has the choice of two options: Build separate Docker storage based on Ceph or connect Docker to the existing VMware storage.

To make this work, VMware provides a service named vSphere Docker Volume Service (vDVS) comprising two parts: The ESX code running directly in VMware and the Docker plugin, which is officially certified by Docker, so you can purchase it online directly from the Docker store. The ESX part is available as a download, so it can be integrated into ESX with just a few clicks. The GitHub page for the plugin [2] contains all the relevant information.

If you want to use the service, you need at least ESXi 6.0 or higher and Docker v1.12 or later. VMware recommends version 1.13, or 17.03 if you want to use the "managed plugin" – the variant from the Docker store. If this is the case, the plugin installation is simple after installing the VIB package in ESXi:

$ docker plugin install --grant-all-permissions --alias vsphere vmware/ docker-volume-vsphere:latest

To then create a volume in vSphere storage, simply use the command:

$ docker volume create --driver=vsphere --name=it-admin-test -o size=10gb

The volume can then be connected to a Docker container from the command line as usual.