CoreOS has unveiled the 1.0 version of its rkt ("rocket") container runtime, built to one-up Docker in security.
The rkt 1.0 feature set also hits all aspects of CoreOS's plan to offer a credible alternative to the Docker runtime: Provide a compatible feature set, do the same tasks as Docker (but do them better whenever possible), offer capabilities Docker doesn't have at all, and don't force people to forsake the best parts of the existing Docker ecosystem.
Little has changed from the pre-1.0 releases. CoreOS CTO Alex Polvi says version 1.0 establishes solid APIs and interfaces around rkt. "We've spent over a year refining everything that has been going on with rkt," Polvi said in a phone call, "and we're now ready to call it 1.0 and have people start building against it."
CoreOS's insistence on security in rkt focuses on best practices that already exist in the Unix world. This includes basics like signing and validating images -- which Polvi says Docker implements only partway, meaning it isn't fully integrated with platform policy management functions.
Rkt's "daemon-less" behavior gives it an architectural difference from Docker as well. "Any action you take can be invoked as a separate operation," said Polvi, "meaning it can be subject to privilege separation. Things talking to the Internet, for instance, don't have to run as root. That's just basic Unix system programming; you shouldn't have to run everything as root in the server."
Docker, to its credit, has been working on allowing containers to run in a nonroot account, but that feature is slated for only production-ready release in the forthcoming version 1.10.
CoreOS has long wanted to woo existing Docker users. For one, even though CoreOS has put its weight behind the App Container image format standard, existing Docker containers are meant to run as-is with rkt. To aid moving from one format to the other, CoreOS's Quay container registry can convert Docker images "on the fly" and "transparently" according to CoreOS's press notes.
Polvi has noted in the past how useful it would be to have a standard container image format. That way, users could package and sign a container image once, then run it on their choice of runtime, instead of having to rebuild a container for each variety of runtime.
Such a standard would be "for the users, not the tool-builders," as Polvi put it, and while a standard may well be sorted out in time by the Open Container Initiative, CoreOS has elected to support both image formats. (Polvi states this can be done with no significant loss in performance, thanks to rkt's modular architecture.)
Rkt 1.0 also includes support for hardware-level protection via Intel's Clear Containers technology. An experimental version of Docker was created to support Clear Containers, but the mainline version of Docker doesn't use any of its changes yet.
Polvi was also dismissive of Docker's recent foray into unikernel technology. "We're confident unikernels wouldn't be part of any production story going forward," he said. "It's an interesting idea, but the practicality of deploying a unikernel as a production-ready use case doesn't make sense from a systems programming point of view."
He concurred with some of the points made recently by Joyent's Bryan Cantrill in a widely circulated blog post that declared unikernels "unfit for production." For Polvi, a user could obtain far better isolation by using a Linux kernel, per Clear Containers.
"Once you've ported to a unikernel," Polvi said, "you lose all the tools for debugging, for being able to understand what's going on. There might be some performance benefit, but at the cost of all of that, I would not anticipate a large uptake."