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."