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).

$ docker plugin --help

Usage:	docker plugin COMMAND

Manage plugins

Options:
      --help   Print usage

Commands:
  create      Create a plugin from a rootfs and configuration.
  disable     Disable a plugin
  enable      Enable a plugin
  inspect     Display detailed information on one or more plugins
  install     Install a plugin
  ls          List plugins
  push        Push a plugin to a registry
  rm          Remove one or more plugins
  set         Change settings for a plugin
  upgrade     Upgrade an existing plugin

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.

$ docker plugin install --help

Usage:	docker plugin install [OPTIONS] PLUGIN [KEY=VALUE...]

Install a plugin

Options:
      --alias string            Local name for plugin
      --disable                 Do not enable the plugin on install
      --disable-content-trust   Skip image verification (default true)
      --grant-all-permissions   Grant all permissions necessary to run the plugin
      --help                    Print usage

Want to become an expert?

Try it for yourself or check out these tutorials.