The developers of Flocker have started building a service that tackles the complex problem of making containers truly portable, data and all. Moving containers is one thing. But moving the containers with the data is a different matter. Flocker is ClusterHQ’s attempt to make Docker a production ready service for an entirely different class of apps that contain multiple types of images. In this scenario, a developer could run databases, queues and key-value stores in Docker and move them around as easily as the rest of their app.
“Containers can’t cope with data,” said Mike Ferranti, vice president of marketing for ClusterHQ, the company that is developing Flocker.
Many actions like upgrading a database from one version to another, disaster recovery for databases and moving an app require users to bring down their app, he said. The result is that people only end up running API servers and Web front ends in containers like Docker, he said. That can force developers to use different data services across test, development and production, introducing the potential for problems when getting to that stage.
Flocker’s remedy is a command line tool and a configuration language that deploys Docker-based applications onto one or more hosts. Once deployed, the applications will have access to the volumes configured for them. Those volumes will follow containers when used to move them between different hosts in the Flocker cluster.
Colin Humphreys, CEO of CloudCredo, a company that helps with Cloud Foundry deployments, told ClusterHQ that data issues are indeed holding back container usage. “Solving the data problem such that databases and other data-backed services can be run inside containers will unleash a massive amount of pent up demand for containers and PaaS,” he said.
ClusterHQ is developing an open source system that essentially maps the various components in a Docker container, making it easy for users to specify where to move them if they are, for instance, shifting an app into production.
Flocker has a feature it calls an app manifest. With the manifest, a developer defines which Docker images make up the application. For example, that may be a MongoDB Docker image and an Nginx Docker image. It also has a deployment manifest that specifies where to deploy the container, such as which servers and which data centers. To migrate something like a database from one server to another, the user updates the deployment manifest and runs the “flocker-deploy” command.
ClusterHQ is releasing a very early version of the software in hopes of attracting interest and input from developers. But its creators admit that it’s currently got a pretty big drawback.
Currently, when a Flocker user moves a data container, there’s downtime while the data is replicated to the new node. The larger the amount of data, the longer the downtime. This defeats the purpose since Flocker is meant to eliminate the down time associated with making changes to databases when using containers.
“While we are not announcing the availability of a solution to this issue in the 0.1 release, we fully understand that this downtime is unacceptable for production applications. Our FreeBSD-based platform on which Flocker is modeled included a system of continuous replication that made migrating very large databases possible in only a few seconds. Users can expect a similar feature to be included in Flocker prior to our general availability launch,” ClusterHQ said in a statement.
Until that capability is added, Flocker won’t be very useful. However, part of the reason ClusterHQ said it is making an announcement about the early version of the software is to try to drum up interest in the concept. Since it’s an open source project, developers who think the overall concept has merit can help iron out the wrinkles.
For more about Flocker’s live migration capabilities, here’s a talk posted by Cloudsoft from the Docker meeting in Edinburgh last month by ClusterHQ Co-Founder and CEO Luke Marsden:
Cloudsoft is a sponsor of The New Stack.
Feature image via Flickr Creative Commons