Solid Bodies

Connecting OpenStack and Docker

OpenStack is currently the marketing star when it comes to open source solutions in the public cloud: Anyone who starts building an OpenStack cloud today knows what they are getting into with this project, especially since OpenStack components are no longer only used as part of a complete OpenStack installation. In particular, the OpenStack network service Neutron and the storage service Cinder (Figure 1) have stepped out of the shadow of their parent project and become meaningful without a complete OpenStack, although that's not the rule: If you run these services, you will usually also deploy the rest of OpenStack to sell public cloud services to customers.

Figure 1: OpenStack comes with its own image management in the form of Cinder, to which Docker can be connected via Fuxi.

Companies that operate OpenStack as part of a public cloud installation also want to offer their customers Docker containers on a regular basis. OpenStack and Docker do not harmonize very well: Many OpenStack and Docker design approaches clash, and the use of a Docker driver for the Nova virtualization component is now orphaned. Nevertheless, OpenStack and Docker can be combined: It is not absolutely necessary that Nova manage Docker containers, but if you already have a public cloud with OpenStack and storage management, you can connect Docker directly to Cinder. This elegant solution saves you the need to build a second storage repository explicitly for Docker.

Kuryr Supports Containers

For some time the OpenStack project has been developing a collection of tools under the name Kuryr that better maps the storage and network model of Docker. The "Fuxi" sub-project, which is responsible for storage in Kuryr, is a separate service that implements the Docker volume API and thus acts directly as a rival for Docker at the command line.

Basically, Fuxi acts as a translator: It translates the incoming command of the Docker command-line client into an API call for child processes, evaluates the return value, and connects the running container to the appropriate volume. For this to work, Fuxi consists of two components: The API described above is part of the package, as is the Fuxi plugin in Docker itself.

The Fuxi API service must run on every host on which containers with Docker are to run, because the Fuxi plugin always connects to the API on its own server. If you don't use Docker directly, but still use Kubernetes for Docker management, you can still use Fuxi. In addition to the Fuxi API and the Fuxi driver for Docker, a third module is needed: the integration layer between Kubernetes and Fuxi. If this is missing, Docker can create volumes with Fuxi, but Kubernetes will not know anything about this storage.

Using Fuxi

Once the OpenStack admin has rolled out Fuxi to the Docker node (Figure 2) and provided it with an appropriate configuration (the tool's documentation provides valuable clues), corresponding volumes can be created on the command line:

$ docker volume create --driver fuxi --name it-admin-test --opt size=1 --opt fstype=ext4 --opt multiattach=true --opt volume_provider=cinder

Figure 2: Fuxi must run on every Docker server; the configuration file is clear compared with other OpenStack services.

The last parameter is especially important: In addition to Cinder, Fuxi also can create volumes with the OpenStack NFS service Manila. If you omit this parameter, the Fuxi driver for Docker simply denies the service.