What’s New in Docker 17.03 Volume Plugin Architecture & Specification?

Docker, Inc announced initial support for volume driver plugins for the first time under Docker 1.8 release. Since then, there has been subtle changes in terms of its volume plugin architecture. With the new Docker 17.03 Volume plugin architecture, writing your own Volume Plugin is quite simplified.

VolPlugin

 

Old Legacy Docker Volume Plugin Specification < 1.12 release

Evolution

Before 17.03 release,  Docker Volume Plugin Specification feature includes the standardization of  API interface. In case Docker daemon is already been running in the system and you write certain extension, the only way Docker daemon talks to extension is based on standardized API. As per Docker official page , you need to write 9 endpoints shown below:

1 2 3 4 5 6 7 8 9

 

New Docker Volume Plugin Specification > 1.12

With Docker 17.03, the new Volume Plugin Spec has been revamped. The new specification extends the standardization and talks about plugin packaging as a Docker Image. What it really mean is now you can now convert your extension/plugin into a Docker image which you can publish on Dockerhub. Interesting, isn’t it? In simple statement, now it is possible to publish Volume plugin in the form of Docker image which anyone can discover, install flawlessly onto their system and easy to configure & manage.New Docker Volume Plugins enable Engine deployments to be integrated with external storage systems such as Amazon EBS, and enable data volumes to persist beyond the lifetime of a single Docker host.

Before we build, store, install and manage the plugin, we need to go deeper in understanding the newer Docker Volume API design.

Understanding Docker Volume API Design:

As per the official Docker Volume Plugin page…

“The new Plugin API is RPC-style JSON over HTTP, much like webhooks.Requests flow from the Docker daemon to the plugin. So the plugin needs to implement an HTTP server and bind this to the UNIX socket mentioned in the “plugin discovery” section. All requests are HTTP POST requests.The API is versioned via an Accept header, which currently is always set to application/vnd.docker.plugins.v1+json.”

How Docker Volume Orchestration Works?

Orches

 

Playing around with RexRay Volume Plugin:

In my previous blog post, I talked about RexRay as a Volume Plugin. Let us look at various CLIs which can be used to play around with this plugin:

  • Listing the RexRay Volume Plugin:

1213

  • Disabling or Enabling the RexRay Volume Plugin:

141516

  • Verify that “Enabled=true” value gets listed once plugin is enabled back:

17

  • If Volume Plugin is in the form of Docker Image, then there should be a way to enter into this container. Right? Yes,it is possible. You can enter into a shell of RexRay Volume Plugin using docker-runc command.

1819

  • Checking the Plugin logs:

log

  • It’s time to use this plugin and create volume for your application:

vol1

 

  • Inspecting the volume:

vol2

 

I hope you found this blog useful.In my future blog post, I will talk further on how Volume Plugin Orchestration works in terms of Swarm Mode cluster.

Leave a Reply

Your email address will not be published. Required fields are marked *