CoreOS gains on Docker, with support from Google, Red Hat, VMware

When CoreOS introduced its AppC container format as an alternative to Docker, one question jumped out: Would anyone other than CoreOS adopt it?

The short answer appears to be yes. To varying degrees, Google, Red Hat, VMware, and Apcera have joined the list of App Container (AppC) adoptees. But preemptively replacing Docker doesn’t seem to be on the agenda; it’s more about increasing the list of container options available to customers and letting the market decide.

Adding AppC to Kubernetes

Google has added support for Rocket — the runtime for the CoreOS AppC format — to Kubernetes, Google’s container orchestration system. A system that manages containers with Kubernetes can now use CoreOS containers and Docker. Kubernetes has been making inroads nearly everywhere — Microsoft Azure and Mesosphere’s DCOS, to name two — so this provides a general way to manage AppC-based containers at scale.

With VMware, AppC support is provided by Project Photon, a Linux distribution built for running containers on VMware vSphere and vCloud.

Red Hat already made Kubernetes part of its container-management strategy, but its involvement with AppC involves assigning an engineer to help maintain the project.

Apcera — a company founded by ex-Pivotal creator Derek Collison — is introducing its own AppC implementation named Kurma. Few details about Kurma have come forth, but CoreOS says, “Kurma provides a framework that allows containers to be managed and orchestrated beyond itself.” The idea seems reminiscent of many recent maverick approaches to containers, like Joyent Triton or DCOS.

Why AppC is catching on

AppC appeals to third parties, if not as a replacement for Docker than at least as a complement to it. Kelsey Hightower, product manager and chief advocate at CoreOS, described how AppC differs from Docker’s container format by leveraging underlying capabilities in the host OS.

Docker, he explained, was a product of the PaaS world, and as a result it made sense to have its abilities incarnate in a client app that didn’t assume too much about the underlying operating system. With AppC, by contrast, many of the features provided for it are already present in Linux via systemd and other services.

“These things have been providing many of the capabilities that Docker provides,” Hightower said. “They’ve been around a bit longer, they’re a bit more mature and stable, so we don’t need Docker to provide that particular abstraction.”

Process management, he added, is handled by systemd in AppC. (Most major Linux distributions provide systemd, for better or worse, which all but guarantees AppC will work as-is in modern Linux distributions.)

“In a low-level tool like a container runtime engine,” Hightower said, “you really don’t need to specify where those containers live or how you manage that process going forward as they’re launched.”

CoreOS and Docker have locked horns in the past over the interactions between their two container systems. In February, CoreOS made changes to AppC to allow Docker images to work with its format and submitted a pull request to Docker to allow Docker to do the same for AppC.

That request wasn’t received well by Docker’s team, mainly on the grounds that it wouldn’t serve the interests of users. It has since been closed, but another proposal has open, “seeking feedback on whether there are any modifications required to the spec to allow [AppC] to work natively in Docker.”