CloudFoundry? Docker? rkt & CoreOS!

This February, CoreOS announced that their rkt container runtime had graduated to version 1.0. rkt has come a long way since its initial announcement in December 2014, so now’s a good time to take a closer look and consider how it fits into the rapidly changing container ecosystem.

This article is intended for people who are new to rkt but have some experience with Linux containers, e.g., with Docker. Throughout this post, I’ll be assuming you’re using rkt with systemd on Linux.

You will learn:

• History and context
• How to build ACI images with acbuild for running with rkt
• Starting and stopping containers with rkt and systemd
• How image discovery works, in contrast to Docker’s registry
• pods and rkt
• cgroups and rkt

History

CoreOS started building rkt because they felt that Docker was no longer “the simple composable building block [they] had envisioned.”

rkt was announced alongside the appc set of specifications, which focused on composability, security, image distribution, and openness of containers. Docker’s daemon and monolithic CLI tool make composability a problem — of processes in the case of the daemon and of tools in that of the CLI. The fact that Weave and Flocker had to resort to wrapping the Docker CLI tool was evidence of the latter (before plug-ins were introduced).

The rkt announcement blog post appeared to be successful in shaking things up enough to get Docker to commit to open standards. The Open Container Project (later renamed to the Open Container Initiative), with appc and CoreOS founders Alex Polvi and Brandon Philips as founding members, was launched on June 22, 2015.

Since then, we’ve not seen the kind of progress on standards from the OCI that will enable true interoperability of container discovery, distribution, and runtime environment between Docker, rkt, and others. Docker is clearly going all-in on building a platform, whilst rkt appears to be firmly aimed at platform builders. A smart move by CoreOS, considering signs suggesting that wholesale adoption of Docker’s platform could lead to vendor lock-in.

rkt Features

rkt boasts the following features:

• Modularity – rkt is architected in stages (image fetching, cgroup and networking setup, and execution) that can have different implementations, providing separation of privileges as well as concerns.
• Composability – rkt is not a daemon, is not the parent process of all your containers (and therefore can be updated without affecting running containers), and is composable with other tools. Natively runs appc images built with acbuild.
• Security – It has Intel Clear Container, SELinux and TPM support, as well as image signature validation.
• It can run Docker images.

The new 1.0 release includes some notable fixes and improvements:

• Bash autocompletion for rkt commands
• rkt fly — a new rkt stage1 that allows containers to be run with reduced isolation and extra privileges. This is useful for running software such as cluster management controllers.