Magnum is the Name, Docker Container Management is the Game
“the pink dock” by Scott Ellis is licensed under CC BY-SA 2.0.
The people who created OpenStack built it as a means of pooling resources together for consumption by virtual machines. A Docker container is a machine and it is virtual, but it is not a VM as we have come to know it. Docker and OpenStack are two means of operating consumable infrastructures. Neither is under any particular obligation to “embrace” one another.
OpenStack could run Docker containers … kind of. There is a hypervisor driver for Docker containers that enables them to run on OpenStack’s Compute platform, also called Nova. There was hope that Docker and other VMs could run in a complementary fashion on a Nova platform. But because a container is not really a VM, it should not expect to be managed like a VM.
It’s difficult for these two open source systems to know what to do with one another. Like Laurel & Costello, they seem like two halves of a beautiful friendship just waiting to come together — just not with each other.
So on Wednesday morning at the OpenStack Summit in Vancouver, Rackspace Distinguished Architect Adrian Otto and Cisco Principal Software Engineer Steven Dake gave one of the first demonstrations of one possible way their system could proceed: OpenStack’s idea of what Microsoft used to call “embrace and extend.”
It’s called, for whatever reason, Magnum. And besides one very critical strategic addition, it does not make any radical additions to the Docker stack as it has already come to be recognized.
Docking at Magnum Bay
Otto explained that Docker containers have their own requirement:
Containers — because they have a different lifecycle, because they have a different API — need a dedicated service that has an API intended only for the exclusive use of containers.
It is a stack that is new, to coin a phrase, comprised of known elements: OpenStack at the base, using Kubernetes as the orchestrator, the Flannel overlay network for subnets within Kubernetes, and Docker Swarm clustering.
“Magnum is different from other container software that has preceded it,” Otto continued, “and the number one way it is different is, it’s multi-tenant.” Indeed, that revelation illuminates the reason why simply running a hypervisor driver on top of Nova was insufficient: OpenStack data centers are in the cloud business.
If containers are to become part of the true hybrid cloud, then not only do they need to be consumable, they must become consumer goods. This means they need the same thing any other container system requires to be marketable, whether it’s Rubbermaid crates or Ziploc bags: packaging.
That’s Magnum’s key addition to the ecosystem: an extra layer of abstraction between containers (or pods, in a Kubernetes configuration) and the hypervisors on which they run. Magnum calls this component a “bay,” which you can think of as part of a dock that a customer leases.
In the Magnum model, as Otto explained, an instance of Nova is a node. The way he’s thinking about this, a node can be anywhere — theoretically, it can be a virtual machine.
“The bay is the place where the container orchestration system goes,” he said. “You have a Magnum API. As a user, you create a bay. As soon as you have a bay, you can start putting things in the bay. The things you put in there, if you use the Kubernetes bay type, are pods. The things you put in there, if you use the Docker Swarm bay type, are containers.”
A bay has the virtue of being configurable by way of a template, thus enabling end customers to self-configure services without requiring, as a Red Hat software engineer put it during a session a day earlier, a Ph.D. It also enables a kind of customer-centered provisioning which makes Magnum function as a true multi-tenant environment, preventing other users from seeing everything provisioned in one’s bay, even when public cloud resources are being leveraged. And since the bay provisioning functions are handled by way of an asynchronous API, the service requesting those functions receives an HTTP 201 response to that request, rather than having to wait for possibly several minutes.
“We’re integrated with the OpenStack services,” added Otto. “Everything that OpenStack does well, we just want to leverage. We don’t want to reinvent the wheel anywhere.” As examples, he noted that Glance is leveraged as Magnum’s repository instead of Docker Hub, Heat serves as the orchestration engine, Keystone as the identity provider, and Neutron as its networking controller. Either CoreOS or Fedora Atomic may be used as the container’s internal operating system. Across the board, no surprises.
Match as in Marriage, or Match as in Flames?
Otto makes the integration of Docker’s and OpenStack’s mindsets smooth and painless, with the easy language of a dad reading his daughter a bedtime story. While the reality isn’t exactly a nightmare, OpenStack experts elsewhere at this week’s summit seemed to think there were bad dreams just around the corner.
During a Tuesday panel session entitled, “Are Containers a Threat to OpenStack?” Red Hat Senior Consulting Engineer Jan Mark Holzer expressed a measured sense of skepticism. “I think in the long term, containers can be a threat to OpenStack. Because if you envision [that] people really start moving towards microservice-based architectures, where these services themselves are self-sustaining, self-healing, etc., there would be much less need for a complicated, complex underlying infrastructure. … It’s a good point that hopefully gets all of us into gear to address all of the issues around operation of OpenStack environments, lifecycle management, all of those things which are really important, which we all struggle with today.”
During the Magnum session’s Q&A period, the last questioner brought some of that nascent skepticism into the room. He said he’s noticed that engineers affiliated with OpenStack seemed to express more of an affinity for Kubernetes than for Docker, and he wondered whether Otto agreed.
“At the moment, that happens to be the case,” Otto responded, with the partly masked inquisitiveness of a junior high schooler playing Sherlock Holmes.
“Things are moving rather quickly. If you had asked me that same question three months ago,” he continued, “it would have had a different answer. And three months from now, who knows?” He said CoreOS has recently expressed interest in attaching rkt (the system formerly known as Rocket) as a Kubernetes bay type for Magnum, and very likely, a Mesos bay type would follow.
“I think the point here is, when you make a choice as a service provider,” Otto then said, with a sudden interjection of vigor he had refrained from displaying for the entire presentation up to this point, “on what your container strategy is going to be, there is risk in picking a winner right now, because things are moving so quickly. And if you say, ‘Look, I understand OpenStack is going to be part of my equation, and I’m choosing Magnum, and you select which bay type you want today, if you decide later you want to start using different bay types, that’s fine. And you’re going to be able to use them side-by-side … so you’ll have an actual migration strategy for your users.
“Kubernetes happens to be the thing now. It may end up prevailing. Who knows, things might change. We want you to have a plug-ability story, so that you’ll be able to put in whatever your users really want when the time comes.”
No one wanted to ask questions after Otto said that.
