With Docker setting the techsphere alight, it’s inevitable that others are going to try and grab some of that container glory. Perhaps the most prominent challenger to date is CoreOS, who unveiled container runtime prototype ‘rkt’ (pronounced ‘rocket’) at the end of last year.
CoreOS founder and CEO Alex Polvi’s beef with Docker stems from his belief that it has deviated from its origins as a “simple composable building block” to become an “unwieldy” juggernaut of a platform.
With rkt, CoreOS are aiming to create something closer to Docker’s original manifesto for what a standard container should be – with a few tweaks and improvements. CoreOS has also critiqued Docker’s security model, and questioned the close enmeshment between Docker’s tools and technologies.
CoreOS, whose signature offering is a lightweight Linux distro for hyper-scale cloud deployments, were early adopters of Docker. However, as the project evolved, the team fell out of love with the technology they had come to rely on – prompting them to strike out in a new community- led direction.
To this end, rkt is founded on principles outlined in CoreOS’ official App Container spec (appc), which the aims to provide “a definition on how to build and run containerized applications.” In particular, appc emphasises “application container security execution, portability and modularity.”
Roll on five months, and Google have rallied behind rkt and the appc, becoming official members of the rkt open source project and incorporating the technology into its Kubernetes container orchestration software. The Chocolate Factory comment that this is “an important milestone” for the project.
Significantly, with this new Kubernetes collaboration, you’ll be able to power up Linux containers without having to rely on Docker (although you still can, if you happen to be one of its many, many aficionados).
Speaking to the Register at CoreOS Fest event in San Francisco yesterday, Polvi commented that, “The integration allows Kubernetes to invoke rkt to actually run the container as part of what Kubernetes does…The net result is that the Kubernetes containers now launch rkt containers instead of Docker containers.”
Whilst Docker is being effectively displaced in this instance, CoreOS have claimed that they certainly aren’t trying to destroy Docker with rkt, which is fortunate for them, given the huge groundswell of support behind the technology.
It’s more about giving developers a choice, and ensuring that there’s a container standard that’s not led by one sole company. Craig McLuckie echoes this sentiment in a Kubernetes blog post, writing that, “Container based runtimes (like Docker or rkt)…are a legitimate disruption to the way that developers build and run their applications.
While the supporting technologies are relatively nascent, they do offer the promise of some very powerful new ways to assemble, deploy, update, debug and extend solutions….With that in mind it makes sense for several projects to emerge with different properties and different purposes.”