BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News CoreOS Release Rocket and App Container Specification v0.3.1.

CoreOS Release Rocket and App Container Specification v0.3.1.

CoreOS have released v0.3.1. of the Rocket container runtime and associated App Container (appc) specification, which includes new user-facing features and several important implementation changes that contribute to the stated goals of security and composability.

This latest release of the Rocket container runtime adds two new commands to the ‘rkt’ command line interface (CLI), ‘rkt trust’ and ‘rkt list’. These new commands build on the existing collection of operations that allow application container images (ACI) to be downloaded, run and maintained:

  • rkt fetch - downloads an ACI from a local or remote registry
  • rkt run - launches a container from an ACI
  • rkt enter - enters the namespace of an app within a container
  • rkt status - allows the status of a container and applications within it to be checked
  • rkt gc - enables garbage collection of old containers no longer in use

The new command ‘rkt trust’ can be used to add keys to the public keystore for ACI signatures, and the command supports retrieving keys directly from a URL or using discovery to locate public keys. Currently when retrieving an image during ‘rkt fetch’ or ‘rkt run’, Rocket will verify the image signature by default. The implementation of the public keystore and automatic ACI signature validation was introduced in v0.2.0., and Kelsey Hightower, a developer and advocate at CoreOS, has written up an overview guide explaining this functionality.

The new ‘rkt list’ command is a simple tool to list the containers on the system. It leverages the same file-based locking as ‘rkt status’ and ‘rkt gc’ to ensure safety during concurrent invocations of the CLI tool. The CoreOS team have stated that these lifecycle-related commands have been implemented in a manner that respects the project’s core goals:

In keeping with Rocket's goals of being simple and composable, we've taken care to implement these lifecycle-related subcommands without introducing additional daemons or databases. Rocket achieves this by taking advantage of existing file-system and kernel semantics like advisory file-locking, atomic renames, and implicit closing (and unlocking) of open files at process exit.

Rocket is designed to be modular and pluggable by default, and as such is implemented with the concept of "stages" of execution of the container. The first step of the process, stage 0, is the actual rkt binary itself, which bootstraps the container. Stage 1 is a binary that the user trusts to set up cgroups, execute processes, and other operations as root. The final stage, stage 2, executes the actual application.

Rocket v0.3.1. includes two significant changes to how the application is built internally. Instead of embedding the (default) stage1 using go-bindata, Rocket now consumes a stage 1 in the form of an actual ACI, containing a rootfs and stage1 init/enter binaries, via the '--stage1-image flag'. This CoreOS blog states that this enables easier use of alternative stage 1 images with Rocket, and facilitates packaging for other distributions like Fedora.

Rocket v0.3.1. also now maintains a copy of appc/spec instead of depending on the file located at the Github project repository HEAD. This means that Rocket can be built in a self-contained and reproducible way, and that the Github master branch will no longer break in response to changes to the appc spec. It also makes explicit the specific version of the spec against which particular release of Rocket is compiled.

The CoreOS blog states that as a consequence of these two changes, it is now possible to use the standard Go workflow to build the Rocket CLI e.g. 'go get github.com/coreos/rocket/rkt'. However, this workflow does not implicitly build a stage 1, and accordingly this must be done using the included ./build script, or another custom mechanism, by developers wanting to use a different stage 1.

CoreOS have also added experimental support for App Container Images to Quay.io, their hosted container registry, and stated that several tools for building ACIs have been recently released by independent developers, including docker2aci and goaci.

The docker2aci tool and library takes an existing Docker image and generates an equivalent ACI. This means the container may now be run in any implementation of the appc spec. The docker2aci tool is an early release, and the project’s Github repository includes a number of open issues including a current limitation which prevents a custom port being specified in a Docker registry location.

A new experimental goaci tool has also been released via Github, and this provides a simple command line tool to build Go projects into ACIs which conform to the appc specification. The CoreOS blog states that it is possible to build a minimal golang ACI without the need of any additional build environment, however the project’s primary executable goaci.go code includes a number comments that describe open issues.

The CoreOS Rocket blog has also announced that a number of new projects have emerged over the past several weeks that implement the application container spec, including libappc, Nose Cone and Jetpack.

libappc is a C++ library for creating and managing app containers. The goal of the library is to provide a flexible toolkit for manifest parsing and creation, pluggable discovery, image creation/extraction/caching, and thin-provisioned file systems. Nose Cone is an appc runtime that is built on top of the libappc C++ library. This application makes no use of Rocket, but does implement the App Container specification. Jetpack is an implementation of the App Container Specification for FreeBSD. It uses jails as an isolation mechanism, and ZFS for layered storage.

The CoreOS Rocket v0.3.1 announcment blog post concludes by stating that the developments reported above are an example of innovation that can be driven by open standards:

While these tools are very young, they are an important milestone towards our goals with appc. We are on a path to being able to create images with multiple, independent tools (from Docker conversion to native language tools), and have multiple ways to run them (with runtimes like Rocket and Nose Cone). This is just the beginning, but a great early example of the power of open standards.

Source code and further details of Rocket and the appc app container specification can be found within their respective Github project repositories, and installation instructions for Rocket are included in the project’s README.md. CoreOS is encouraging developers to contribute, and there is a ‘help wanted’ label on the Github project issue list for both Rocket and the appc spec.

Rate this Article

Adoption
Style

BT