Using Clocker and Apache Brooklyn to build a Docker cloud | Opensource.com
Using Clocker and Apache Brooklyn to build a Docker cloud
With the growing potential of Docker, it's becoming clear that the future of at least some of the data center is going to be containerized. But there are still challenges in getting containerized applications deployed and managed across real and virtual hardware.
To learn more about one of the available options for performing this management and deployment, yesterday I attended a Google Hangout which was part of the OpenStack Online Meetup series. This month's topic was centered around providing information and a walk-through of a new open source project called Clocker. Much as the name might suggest, Clocker is a tool designed for spinning up a cloud out of Docker containers.
Clocker makes use of Apache Brooklyn, which is an incubated project under the Apache Software Foundation. Brooklyn, in turn, is a framework "modeling, monitoring, and managing applications through autonomic blueprints." Think of it as an attempt to build a complete application management tool; a single location for performing deployment, monitoring various metrics, managing dependencies, and applying policies to your applications.
Clocker adds a layer which allows containerized applications to be deployed to a Docker host. By using Clocker, you can launch on a cloud of your choice, either using a public cloud provider, a private cloud, or something in between. The tool is rather agnostic to which cloud is being under the wraps, so it works just as well on an OpenStack deployment as it does on a non-free alternative. It gains this technology through the use of Apache jclouds, a library which allows a common API to be used to perform functions on a variety of types of cloud providers.
One exciting part about using Clocker is that it exposes to you a number of methods for intelligently choosing where to deploy your Docker containers to based on criteria of your choosing. You could, for example, choose to fill up your hosts (which are likely virtual machines) one at a time, in a depth-first strategy. Or you could spread them more evenly across multiple hosts in a breadth-first strategy, depending on which technique would offer the best trade-off for your specific application. You can also implement a number of affinity rules, to keep containers needing fast communication together on the same machine, or perhaps intentionally separating them for resiliency reasons.
Needless to say, there's more to learn than we've covered here. For more information, and to see a live walkthrough of an application deployment, I highly recommend watching the video from the Hangout, available below. Alternatively, Andrew Kennedy, presenter of the session yesterday, has also written up an excellent introductory piece on Clocker which includes a tutorial for getting started.