nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

CoreOS's Docker-rival Rocket: We drill into new container contender

Can CoreOS achieve liftoff in Linux container space race?

By Neil McAllister, 3 Dec 2014

Analysis CoreOS CEO Alex Polvi certainly got the attention of the Docker community on Monday when he announced Rocket, his company's alternative to the Docker container file format and runtime. But just what is Rocket and what does it offer that Docker doesn't?

Simply put, the answer for now is a resounding "not much." In fact, as deployable software goes, it's safe to say that Rocket doesn't even exist. The code posted to GitHub on Monday is not even of alpha quality and is best described as a prototype.

"Docker killer" probably isn't the most constructive way to think about Rocket, either – despite Polvi's incendiary Monday blog post, in which he described Docker's security as "broken" and its process model as "fundamentally flawed."

During a well-attended CoreOS community meet-up in San Francisco on Monday evening, Polvi backpedaled a bit from his earlier rhetoric, saying he and the CoreOS team merely disagreed with Docker's direction.

"I do not think Docker overall is fundamentally flawed, I just think it's going down a different path than we originally signed up for," Polvi said.

Specifically, that path includes adding new features to the Docker Engine software that will take it from being a simple set of tools to a full-fledged platform – an approach that Polvi said he feels is fundamentally flawed, which is why CoreOS wants to do something different.

Back to container basics

What the CoreOS team likes is the idea of a container as a basic building block of application development, where each container provides a "microservice" that can be combined with other microservices to form distributed applications.

In this development model, Polvi argues, you probably want the software that you use to run your containers to do that and nothing else. Any additional platform services the software provides will be redundant if you're already building on another platform – such as CoreOS, for example, or Amazon Web Services with its recently announced EC2 Container Service.

Adding features to the Docker software also makes it less secure. As its footprint grows and it becomes more complex, the likelihood that the code contains exploitable vulnerabilities increases.

Paring down the process of creating and running containers, then, is Rocket's first goal. As it stands now, the software consists of two components, each of which is a simple, standalone command-line tool.

The first is actool, which handles building containers and container validation and discovery. The second is rkt – so named, according to CoreOS developer advocate Kelsey Hightower, because "all the best Unix commands are three letters" – which takes care of fetching and running container images.

Significantly, and unlike Docker's approach, these tools aren't just a UI for talking to some other server. In the Rocket model, there's no external daemon involved. When you invoke rkt to run a container, it runs that container directly, within its own process tree and cgroup.

And although it's still very early days for Rocket, it probably won't evolve much further beyond that simple idea.

"We're really just focused on that piece of application container deployment, particularly for large scale web infrastructure," Polvi said during Monday's meet-up. "There need to be better tools for building minimal containers."

Toward an open container standard

Perhaps the most interesting part about the CoreOS container scheme, though – and a point that largely got lost in all the Rocket hype – is that Rocket is merely one implementation of the CoreOS container design. There may eventually be others, and in fact, the CoreOS team hopes there will be.

Work on the Rocket tools began around a month ago. But long before the CoreOS coders ever fired up their editors, they spent nearly a year crafting a specification for their new container format, which they call App Container.

Unlike Docker, where the container format specification has largely been defined by the Docker software implementation, the CoreOS developers sought from the very beginning to explicitly separate the spec for how containers are built from the actual runtime.

The company has now offered up the draft App Container spec for public input and comment. It's initially just available on GitHub, but Polvi said on Monday that he expects it will mature into something closer to a formal standard, complete with its own governance model. Eventually, CoreOS plans to "break App Container off into its own thing," he said – although what that will actually look like has yet to be determined.

Having an independent, open specification should make it easier for developers to build tools that work with App Container images – including developing their own container runtimes, if Rocket isn't their bag.

It should also help other projects integrate App Container support into their own software. Mesosphere, for example, has been working closely with CoreOS to develop the App Container spec, and the CoreOS developers have even floated the possibility of integrating support into Docker itself – which, after all, is open source software, just like Rocket.

Who needs this stuff?

So is the writing on the wall, and should container admins start planning for the day when they ditch Docker and move their container infrastructure over to Rocket and App Container? Maybe. And then again, maybe not.

Rocket will never do everything that Docker does, and that's by design. Its extremely lightweight approach to containers is ideally suited for CoreOS, which targets its products at a very specific market: massive Linux deployments, or what it terms "warehouse scale computing." In CoreOS land, minimal is always better.

"The way we use containers is really as a package manager," Polvi explained. "We don't ship apt or yum, we have our own package manager and we use containers for that."

Customers who aren't operating massive scale-out infrastructures, on the other hand, or those who aren't sold on the microserver app dev model, may prefer to stick with Docker. They may even appreciate its new, platform-oriented features, some of which are expected to be on display at the DockerCon Europe conference in Amsterdam this week.

Also, one area of emphasis for Docker is portability. Its developers are committed to making sure it's easy to move containers between various types of infrastructures, ranging from development laptops to large, cloud-based clusters.

The Docker tech may even one day be OS-agnostic – Microsoft is a Docker partner and it has announced that a future version of Windows Server will support running containerized applications based on the Docker protocols – while Rocket is likely to remain Linux-only.

Existing CoreOS customers, however, will want to watch Rocket development closely, as it's being developed to address an itch that CoreOS feels keenly but that Docker may no longer be able to scratch.

"It's not just a lackadaisical side project for us," Polvi said during Monday's meet-up. "It is something that we're going full force into."

Does that mean Docker is doomed? No. But it does mean the honeymoon is over. Just as no single winner emerged in the virtualization market, Docker isn't going to be the only player in the container game – and that's a reality that both Docker and customers will need to confront. ®

The Register - Independent news and views for the tech community. Part of Situation Publishing