Convoy was the first third-party plugin we looked at in Chapter 3, Volume Plugins. To install it, we launched a Docker host in DigitalOcean as we needed a more complete underlying operating system than is provided by the Boot2Docker operating system, which is favored by Docker Machine.

To install Convoy, we downloaded a release file from GitHub. This tar archive contained the static binaries required to run Convoy on a Linux system, once the static binaries were in place, we created a Docker plugin folder and then added a symbolic link to the socket file that Convoy creates when it is first executed.

We then went on to configure a loopback device that we created on a volume. We then instructed Convoy to use the newly created volume by launching Convoy as a daemon using the Convoy static binary that we downloaded.

As far as Docker is concerned, for each request it gets when the --volume-driver=convoy flag is used to launch a container, it will simply offload anything to do with volume the daemonized Convoy process.

If you review the Convoy section of Chapter 3, Volume Plugins, you will notice that all of our interaction with Convoy is using the convoy command and not the docker one, in fact, the Convoy client is using the same socket file as we symbolically linked to the Docker plugins folder.

Next up, we installed REX-Ray. To do this, we ran a command, which downloaded and executed a bash script from https://dl.bintray.com/emccode/rexray/install.

This script works out the operating system you are running and then downloads and installs either the DEB or RPM file. These packages, as you may have already guessed, install the correct static binaries for your operating system.

REX-Ray goes one step further by also installing init, upstart, or systemd service scripts for the daemon, meaning that you can start and stop it as you would with any other services on your Docker host.

Again, once we have installed REX-Ray, the only interaction we had with the tool is by using the rexray command.

Flocker went one step further, rather than installing an installation script, we used the AWS CloudFormation templates supplied by Cluster HQ to bootstrap the environment for us.

This did the obvious task of launching the Docker host, setting up the security groups, and installing and configuring both Docker and Flocker.

Flocker goes one step further than Convoy and REX-Ray by installing an agent that interacts with the remotely-hosted web API, the volume hub.

Also, as mentioned in this chapter, Flocker existed before the concept of volume plugins existed. So again, a lot of interaction with Flocker is done outside of Docker; in fact, Cluster HQ wrote their own wrapper for Docker so that you could easily create Flocker volumes before the option existed within Docker.

This was the only third-party network plugin we looked at. Like Flocker, Weave existed before Docker launched its plugin functionality.

Weave is slightly different from the other third-party tools that we have looked at. In this, what is downloaded is actually a bash script rather than a static binary.

The script launches and configures the containers with enough permissions to interact with the host machine. The script is also responsible for sending commands via the docker exec command to the running containers and also configure iptables on the host machine.

As you can see, and as you have experienced, all of these plugins have scripts and binaries that are external to Docker itself.

They are also pretty much all written in the same language as Docker:

Majority of the services are written in Go, the only exception is Flocker, which is mostly written in Python: