Docker Volume plugin for Nutanix on AOS 4.7

I already briefly mentioned that a feature appeared in Nutanix in July, which we called Acropolis Container Services, and its first use - Docker infrastructure support on the Nutanix cluster, in our own free hypervisor AHV (Acropolis Hypervisor, fork and deep modification of KVM ).

I will not talk about what is a Docker, there is a good article on Habré. And why Nutanix took up container virtualization better than a thousand words will say one picture, which I, while writing this article, did in Google Trends.







But why do we need to cut special support for containers and data volumes and integration with Docker? This is clear to those who have already tried to implement Docker in production.

')

The fact is that after a couple of days of experiments and showdowns it works for Test / Dev, it is extremely capricious when transferred to serious production. And above all, this is a problem with stateless data containers.



Beginners who are familiar with Docker, and who are thinking about the practical use of container virtualization "in battle", immediately have a whole bunch of questions for Docker (and the Docker guru):

• How to ensure data persistence when using containers?
• Where to write logs of all my containers?
• How to deploy Docker image on hundreds of machines?
• How to quickly roll back if the next push on these machines was unsuccessful?
• What with automatic builds and tests in containers?
• How to provide interaction between containers?
• How to collect application metrics in containers?

... and many, many other questions .

But one of the most important is the persistence of storing data in containers.



In contrast to the already familiar to most "virtual machines", containers are transient objects, as well as storage related to them. When you restart the Docker container, you lose all the data that was changed in the previously running container.

Why this is so is related to how the Docker architecture is designed. It is based on the so-called “12-factor” , a development pattern that originally appeared in Heroku, which was one of the first PaaS providers. This scheme declares that the state of the application must be separate from the application itself, in a separate repository. This works great for front-end applications that do not have a problem losing their state, since they are stateless by nature, but for the rest there is a serious difficulty. How to deal with application logs, web server cache or SSH keys?

How to share data between different containers, or between a host and containers?



Usually in all such cases, it is common practice to use third-party disk-mounted disk volumes located on the host. But in this case, the containers become dependent on the operation of the host, and Single Point of Failure is potentially created, since the loss of the host automatically means the loss of data in the volume mounted on this host for all applications using it in containers. Containers restart is not a problem, but the volume with the data on the host will be lost.



It should also be remembered that the disk I / O performance in the container is rather low, so Docker itself recommends using Volumes for high-performance applications.

By default, containers use UnionFS to implement copy-on-write behavior for data, something that allows us to use git-like behavior for our changes to the container. However, if we need to get maximum disk I / O performance for applications, and storage persistence, regardless of the container, you need to use Docker Volume.



Starting with version 1.8 of Docker, the concept of a volume plugin has appeared, with which you can interact between the Docker and the repository API. This was the first attempt to organize the integration between Docker and the repository, but everything was implemented extremely spartan. Starting with version 1.9, so-called named volumes have appeared, with which it has become possible to interact with volumes as separate named entities, instead of managing them from within the container.



Using these new features, Nutanix has written tools that make it more convenient to use Nutanix systems as a platform for Docker infrastructure and “container virtualization” in general in production.



For this were created:



The Docker Machine Driver is a provisioning tool that allows you to create Docker hosts on your local computer, from a cloud provider, or inside your own data center. He creates servers, installs the Docker Engine on them and configures the Docker client to work with them. Docker Machine Support for Docker Machine for Docker Engine for VMs with docker-machine cli commands.



Docker Volume Plugin - allows Docker Engine deployment tools to integrate with external storage and create persistent volumes for application data.



Well, now that we mention it below and use it:

Docker Datacenter (UCP) is a Docker control solution that allows volume plugin users to use Nutanix DSF as Persistent Storage.

In the Acropolis OS 4.7 version, container management is implemented only through the CLI, but in the Asterix release (4.8) it will be integrated into the Prism GUI.



Now we have the opportunity to provide highly accessible, conveniently mounted storage for containers, which are located separately from the containers and docker hosts.



Starting with Acrpolis OS 4.7 in DSF (Distributed Storage Fabric, our distributed cluster file system, we called it NDFS earlier), support for these Docker mechanisms listed above has appeared.



Nutanix Acropolis DSF Volume driver is written in Go, and works as a Docker Volume extension. It acts as an intermediate sidekick-container. The Nutanix Acropolis DSF Volume plugin forwards a link to the DSF via the iSCSI Volume Groups mechanism, which provides access from the container in DSF bypassing the hypervisor and eliminating access overheads.







The consequence of this is that even losing a container or host, you do not lose access to the volume data. Moreover, since we follow the principle of data locality, when you move a container, after it will move through the Nutanix cluster and its data.

All of the above is a completely native implementation on our platform that does not require third-party solutions.



Using the Nutanix platform with the Acropolis DSF Volume plugin for Docker and the Docker Machine Driver to deploy the Docker infrastructure, you get the native integration of the Nutanix platform with the Docker API, you can take full advantage of data storage in the Nutanix storage, such as transparency, deduplication, compression, snapshots for data replication, both synchronous and asynchronous. You get the highest disk I / O performance for your applications.

Last but not least, all this is installed and working quickly and easily, including the support by our forces of online technical support.



Here is how it works in the form of a small ten-minute screencast (do not forget to enable HD in the Youtube settings!):







By the way, it is possible that you can try it live already on Nutanix CE.