Plugins are now the recommended way to extend the capabilities of Docker. In fact, certification requires it. This post sheds light on what plugins are, the problems they solve and the most common mistake to avoid.

1) Plugins are containers, but not Docker Containers:

Docker documentation specifies plugins as out-of-process because they do not operate under the umbrella of Docker Engine. Why? Plugins are containers that are run natively via containerd, the low level component that implements container execution and provides process management.

Plugins operate in isolation from Docker Engine. They are invisible to familiar tools including docker ps. And, plugins do not have access to many of Docker’s value added features including secrets management. For some, this is a cause for concern. We particularly enjoy the comedy of this tweet:

“docker plugins is the most infuriating feature I’ve seen yet. It is wrong on so many levels. it’s a parallel universe for containers.” – Darren Shepherd (Rancher) [link]

To be honest, there is some truth to his statement. Plugins do represent a parallel universe for containers, from a management perspective. However, after several years of working with Docker volumes, including solutions that pre-date plugins and even the volume API, we can say that the pros outweighs the cons.

Here’s what’s really great about Plugins:

Boot order dependencies for plugins improve overall reliability of Docker volumes. Now, Docker containers that depend on volume drivers should no longer fail due to startup races with the associated volume driver. The pre-plugin solution to this problem required a messy interaction of timed retries… which was truly a poor solution in our book.

Docker can now gracefully shutdown when containers have external volume dependencies. Termination ordering ensures that volume plugins will not be stopped before the containers that depend on them.

Plugins operate in isolation. This prevents users from accidentally deleting or stopping volume drivers: out of sight, out of mind!

2) Plugins operate in isolation and have dedicated tools

As described above, plugins are native containerd containers. You administer them using a special purpose tool. docker plugin provides one-stop shopping for installing, enabling, disabling, enumerating and upgrading plugins (special thanks to Docker folks for hearing our plea for the need to include upgrade support).

One notable consequence of the plugin architecture, which is also listed as a benefit above, is plugin isolation. You cannot docker exec into a plugin container. This presents challenges for accessing extended management functions offered by full-featured plugins. The Blockbridge Volume Plugin solves this by exposing an API endpoint which can be accessed using a containerized management tool (i.e., volume control). In the end, we think this delivers the best of both worlds: the plugin operates in isolation while extended management controls are available via standard docker container. See, sometimes change is a good thing.

3) Pitfall: plugin names are binding

There is a subtle detail of the current implementation of volume plugins that is sure to cause some pain. When a volume is provisioned, it is associated with the name of the driver that created it. By default, the driver name is the full plugin name as specified by the image format (ie., user/repo:tag). A consequence of this design is that it effectively binds a volume to a specific version of a plugin (i.e., tag). BE ADVISED: the failure mode is unforgiving. If the volume plugin version changes due to upgrade or is deprecated by the vendor, you lose the ability to enumerate, manage and access those volumes through Docker.

So what’s the solution? ALWAYS specify an --alias when installing a volume plugin. Choose a unique, descriptive, name to refer to your plugin. And, if you are operating in a Swarm, be sure to --alias your plugins consistently.