eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
CoreOS released today rkt (pronounced Rock-it) 1.0, providing container users with an alternative runtime to Docker. CoreOS first announced rkt in December 2014 after dissatisfaction arose with the state of the Docker runtime.
While rkt is a competitor to the Docker runtime, users will still be able to run application containers that have been built with Docker tools. The promise of rkt is that of improved performance and security controls, as well as integration with CoreOS’ larger platform effort Tectonic, which provides orchestration.
With the 1.0 release, the runtime is now stable and is production-ready, according to Alex Polvi, CEO of CoreOS. The path to rkt 1.0 involved multiple steps as the container runtime evolved. In February 2015, with the rkt 0.2.0 update, developers added an automatic signature validation feature for application container security. With the rkt 0.8 release in August 2015, support was added for Intel’s Clear Containers technology, providing a hypervisor-enforced layer of isolation and security control.
“Since rkt 0.8, we have put in a lot of work to make rkt work across different distributions and make it much easier to get started with out of the box,” Polvi told eWEEK.
Developers have added an API service that makes rkt easier and more efficient to integrate with other scheduling and orchestration systems such as Nomad and Kubernetes, he said. CoreOS rkt developers have also added greater granularity to the security configuration. Polvi noted that while rkt is designed to be secure by default, users can choose to opt out of security features rather than opt in, and there is now more granular visibility and control for handling the security configuration.
“By marking rkt as 1.0, we are committed to maintain backward compatibility with proper deprecation cycles of all features, user experiences and APIs,” Polvi said.
As a 1.0 release, rkt will also be integrated into CoreOS’ commercial Tectonic platform, which aims to provide a Google-like platform for application deployment and orchestration. For users concerned about migrating from the Docker runtime to the rkt container runtime, Polvi emphasized that rkt will remain compatible with the Docker-specific image format, as well as its own native App Container Image (ACI). That means developers can build containers with Docker and run those containers with rkt. In addition, CoreOS will support the growing ecosystem of tools based around the ACI format.
The ACI format is an effort that was originally started by CoreOS to help define a standardized container image format. Polvi said rkt is the charter implementation of the ACI format.
Another piece of the larger effort to standardize container technology is being discussed at the Linux Foundation’s Open Container Initiative (OCI). One of the OCI’s core efforts is runC, which is a low-level container runtime and an implementation of the Open Container Initiative specification.
“It [runC] is primarily concerned with the container runtime implementation, rather than the container image format,” Polvi said.
RunC exposes and expects a user to understand many low-level details of the host operating system and configuration, Polvi said. He added that runC makes no provision for discovering, downloading or cryptographically verifying container images, and expects higher-level tools to prepare the container filesystem.
“Rkt includes some of the same functionality as runC,” Polvi said. “But, as an App Container implementation, is more concerned with standardizing the container image to drive the packaging and distribution benefits of containers throughout the ecosystem, including alternative implementations and even other container runtimes.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.