One Software Container To Enclose Them All
May 8, 2015 Timothy Prickett Morgan
Two years ago, the CoreOS distribution of Linux was created by two guys literally working out of a garage who wanted to make software containers the key feature, rather than an add-on, to a Linux distribution for servers. Today, the company’s appc container format and rkt implementation of that container, which was only announced in December 2014, is fast becoming an alternative to the Docker container format and runtime. So much so that Google, Red Hat, VMware, and others are stepping up to support appc with their key virtualization technologies and, importantly, committing programmers to the effort started by CoreOS.
CoreOS embedded Docker containers and its runtime into the heart of its Linux distribution from the get-go, and the idea was that applications should be propped up and kept away from the underlying Linux so that operating system could be updated and maintained without worrying about wrecking compatibility with the operating system. As CoreOS CEO and co-founder Alex Polvi put it to The Next Platform, CoreOS Linux is for people who fundamentally do not want to care about operating systems any more.
Last month, CoreOS rolled out Tectonic, which is an amalgam of CoreOS Linux and a set of management tools that the company created to manage containerized applications with the Kubernetes container management system created by search engine giant Google. Kubernetes takes its inspiration from the Borg and Omega job scheduling programs created by Google to run its own applications and clusters, and it is one of the few open source programs released by Google. The company tends to help the IT industry along by putting out papers describing its innovations, not by releasing software into the wild. Kubernetes and software containers are exceptions to this rule. Google was an early innovator for Linux-based software containers and much of the work that was done to foster Linux containers (LXC) in commercial Linux operating systems is the result of the work that Google did in creating control groups (cgroups) and namespaces for the Linux kernel starting nearly a decade ago.
Just as CoreOS was realizing that companies didn’t want to care about operating systems any more (or at least updating them), Google figured out that it could use Docker containers as a way of differentiating its Cloud Platform infrastructure cloud from rivals Amazon Web Services and Microsoft Azure. And so Google took the lessons it learned from its Borg and Omega schedulers, which are container aware, and created an analog to them. This Kubernetes software allows for multiple Docker containers running snippets of applications called microservices (or whole monolithic applications if you want to do it that way) to be aggregated and managed as a group rather than individually. Google could have waited for someone else to come up with such a tool – Mesosphere was taking some lessons from Borg and Omega to create its Mesos job scheduler and workload manager – but the company evidently decided that speed was of the essence here and created Kubernetes rather than waiting for Mesos, Docker, CoreOS, or another tool to get the functionality that Google itself saw as necessary for containers to take off.
The interesting bit of news coming out of the first annual CoreOS Fest thing week in San Francisco is that Google has come around and is now supporting the appc container specification and its rkt implementation as created by CoreOS with Kubernetes alongside of the Docker container format that was already supported by Kubernetes.
The appc spec is not a container, but rather a definition that outlines how to maintain the security, modularity, and portability of a container. There are other container runtimes that are compatible with appc, including Kurma, which was created by Apcera for its Hybrid Cloud Operating System. (Apcera, which is now owned by telecom equipment maker Ericsson, was founded by Derek Collison, who was the chief architect at messaging software maker TIBCO, did a few years at Google, and created the Cloud Foundry platform cloud while at VMware.) JetPack is another App Container runtime, in this case for FreeBSD Unix operating systems. And of course, rkt containers from CoreOS are compatible with the App Container format.
Back when Tectonic was launched in early April, there was some confusion as to whether or not this system – which gives enterprises Google-like functionality for using and controlling containerized software – would support both Docker and rkt containers. We were told that Docker was still supported by Tectonic, and wrote as much. But it depends on what the definition of support is. It turns out that Docker itself is not being supported in the CoreOS that underpins Tectonic. Rather, as Polvi clarified, the rkt runtime will download a Docker container image and convert it to the App Container Image (ACI) format. The container format is so lightweight compared to a virtual machine running on a full-blown hypervisor that this is not technically possible, but practically feasible. “We will always be Docker compatible,” says Polvi referring to this conversion process. “It is not pretty, but we can make it work.” And ideally, Docker, the company, would support the App Container spec with its Docker format and conversion would no longer be possible.
Instead, everyone seems to not only be spoiling for a fight between containers and more established virtual machine hypervisors and between CoreOS and Docker over software container formats. (The IT industry likes competition between products, and it also likes to have alternatives.)
“I think that it is easy for people to talk about this as some sort of fight, and that is just not the case. We all want a standard container. We all want for applications to be interoperable between environments. That is why we all signed up for containers in the first place. We have not seen yet is being able to take a standard container and run it in Docker itself. And if you are a company building your own platform, you might just have different technical opinions about how things should be built. And if you want to invest in your own stuff, you should be able to. But the standard container is what we all want, so we get the same experience with HTML5, where you can choose different runtimes for it. I hope that this just ‘ends’ with Docker being part of the standard and that we can all just work together on this. There is no technical reason why this can’t happen, either.”
Polvi says that he believes that standards prevail over time, and with Google, Red Hat, VMware, and others backing both rkt and Docker, it is possible that the industry does, in fact, pick a single software container format.
Such a development, where an entire industry lined up behind a single standard, would be the exception and certainly not the rule.
There are so many examples of a standard not being endorsed when one should have been. With virtual machines, we got incompatible hypervisors and VM formats on the same physical iron. With blade servers, the telecom industry had an existing blade form factor and standard that would have worked in the datacenter (with some difficulties relating to different rack and enclosure form factors that would have had to be dealt with ), but every vendor created its own blade and chassis. If you go back to the Unix era, we didn’t get one Unix but rather something that more accurately could be called Multix. (Unixes shared APIs and commands, but were very different from each other and certainly not compatible.) But again, the whole point of software containers, like the shipping containers that they take inspiration from, is that they are the same the world over so the transportation industry can all use the same equipment and processes to handle them and thereby grease the wheels of commerce.
Also announced this week at CoreOS Fest, to help get Tectonic up and running a bit easier, CoreOS is working with Intel to come up with reference architectures for Tectonic infrastructure packages and Supermicro and Redapt are cooking up hardware stacks that customers can buy based on those reference architectures. The specs are for full rack systems, and they are not quite finished yet.
CoreOS has not yet set up an independent foundation to steer appc and rkt (and neither has Docker), but Polvi says that this could happen in the future to encourage more enterprise participation in the development of what it hopes will be the container standard. Right now, Polvi and CoreOS co-founder Brandon Philips have asked Charles Aylward of Twitter, Vincent Batts of Red Hat, and Tim Hockins of Google – all of whom are already working on App Container – to be community code maintainers and help steer the project along with CoreOS.