At the London Microservice User Group July meetup, Kai Davenport presented a live demonstration of ClusterHQ’s Flocker v1.0 container data volume manager tool migrating a Docker storage volume between multiple containers running within a Docker Swarm.
Davenport, developer evangelist at ClusterHQ, began the talk by contrasting the monolithic and microservice approaches to software design and deployment. Davenport stated that there is ‘no one-size fits all’ approach to architecture, but care must be taken when developing a monolith, as it is all too easy to add many disparate features into a single application:
...the idea of pouring loads of different features [into a monolith] - it’s like a Black and Decker workbench, and what you really want is a hammer and a chisel and some nails, and you can combine those as you want...
Davenport argued that container technology, such as Docker, is disrupting application deployment. The benefits of low resource overhead (compared to a VM), fast startup time, and the realisation of ‘immutable infrastructure’ are revolutionising infrastructure provisioning and deployment - particularly for microservice-based applications.
There are many solutions to container orchestration emerging, including Docker Swarm, Kubernetes, Mesos/Marathon and CloudFoundry. However, the handling of state within containers, and the mobility of storage volume data across the associated host machines within a cluster is often a forgotten problem. Davenport suggested that this is where the open source ‘Flocker’ container data volume manager for Docker can provide a solution.
In addition to providing mobility of container state across a cluster, Flocker can also act as an abstraction layer for Docker volumes. Flocker currently supports multiple block-based shared storage implementations, such as Amazon Web Service's EBS, OpenStack Cinder, EMC ScaleIO and XtremIO, and local storage using an experimental ZFS storage backend (the Flocker documentation contains a detailed storage comparison matrix). Davenport suggested that using Flocker data volumes will reduce the need for additional work if a developer or operator decides to swap to a different storage device, or change cloud platform vendor.
Flocker also has planned integrations with major orchestration tools. Davenport demonstrated the use of Flocker with Docker Swarm live at the meetup, and instructions to replicate the demonstration can be found on the ClusterHQ Github account. Mesosphere’s Marathon Apache Mesos scheduler works ‘out of the box’ with Flocker, and Kubernetes requires a (currently unreleased) patch in order to integrate with Flocker. The prototype Flocker volumes GUI was also demonstrated, and this showed the location and status of the container volume before and after the host migration.
Responding to questions from the meetup audience, Davenport stated that additional work is planned in order to make Flocker fully highly available, as currently only a single ‘Flocker Control Service’ is deployed into a cluster. In response to a question about Docker volume performance, Davenport suggested that this will primarily depend on the associated Docker storage driver, and there will be minimal overhead added to the volume management process when using Flocker, as Flocker is primarily involved only when a container and volume are being initialised or migrated.
The ClusterHQ blog contains details of the v1.0 release of Flocker, and further information of the supporting experimental Docker plugin system can be found in an existing InfoQ news item. The video recording of Kai Davenport’s “Orchestrating storage for a Docker microservices stack” London Microservice User Group meetup can be found on the Skillsmatter website.