Skip to main content

Announcing rkt v0.7.0, featuring a new build system, SELinux and more

Today we are announcing rkt v0.7.0. rkt is an app container runtime built to be efficient, secure and composable for production environments. This release includes new subcommands for a rkt image to manipulate images from the local store, a new build system based on autotools and integration with SELinux. These new capabilities improve the user experience, make it easier to build future features and improve security isolation between containers.

Note on rkt and OCP

As you know, rkt is an implementation of the App Container (appc) spec and rkt is also targeted to be a future implementation of the Open Container Project (OCP) specification. The OCP development is still in its early days. Our plans with rkt are unchanged and the team is committed to the continued development of rkt. This is all a part of the goal to build rkt as a leading container runtime focused on security and composability for the most demanding production requirements.

Now, read on for details on the new features.

New Subcommands for rkt image

In this release all of the subcommands dealing with images in the local store can be found inside rkt image. Apart from the already existing subcommands rkt image list, rkt image rm and rkt image cat-manifest, this release adds three more:

rkt image export

This subcommand exports an ACI from the local store. This comes in handy when you want to copy an image to another machine, file server and so-on.

$ rkt image export etcd.aci
$ tar xvf etcd.aci

Note that this command does not perform any network I/O so the image must be in the local store beforehand. Also, the exported ACI file might be different from the original imported to the store because rkt image export always returns uncompressed ACIs.

rkt image extract

For debugging or inspection you may want to extract an ACI to a directory on disk. You can get the full ACI or just its rootfs:

$ rkt image extract etcd-extracted
$ find etcd-extracted
$ rkt image extract --rootfs-only etcd-rootfs
$ find etcd-rootfs

As with rkt image export no network I/O will be performed.

rkt image render

While the previous command extracts an ACI to a directory, it doesn’t take into account image dependencies or pathWhitelists. To get an image rendered as it would look ready-to-run inside of the rkt stage2 you can run rkt image render:

$ rkt image render --rootfs-only etcd-rendered
$ find etcd-rendered

New Build System

In 0.7.0 we introduce a new build system based on autotools. Previous versions of rkt were built with a combination of shell scripts and ad-hoc Makefiles. As building complexity grew, more and more environment variables were added that made new build options less discoverable and complicated development.

The new build system based on autotools in 0.7.0 has more discoverable options and should make it easier to build future features like cross-compiling or a KVM-based stage1.

This is how you build rkt now:

$ ./
Initialized build system. For a common configuration please run:
./configure --with-stage1=coreos
$ ./configure --help
`configure' configures rkt 0.7.0+git to adapt to many kinds of systems.
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
enable functional tests on make check (linux only,
uses sudo, default: no, use auto to enable if
Optional Packages:
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--with-stage1=type type of stage1 build one of 'src', 'coreos', 'host',
'none', 'kvm' (default: 'coreos')
address to git repository of systemd, used in 'src'
build mode (default: '')
systemd version to build (default:
custom stage1 image path (default:
$ ./configure && make -j4

Note that all the build options are listed with a description text that helps the user know what to write instead of having them read the build scripts to figure out which environmental variables to set.

SELinux Support

We also added support for running containers using SELinux SVirt, improving security isolation between containers. This means every rkt instance will run in a different SELinux context. Processes started in these contexts will be unable to interact with processes or files in any other instance’s context, even though they are running as the same user.

This feature depends on appropriate policy being provided by the underlying Linux distribution. If supported, a file called “lxc_contexts” will be present in the SELinux contexts directory under /etc/selinux. In the absence of appropriate support, SELinux SVirt will automatically be disabled at runtime.

Other Features

  • rkt registers pods with the metadata service by default now. Ensure it is running before running pods (rkt metadata-service) or disable registration with rkt run --mds-register=false.
  • We started improving rkt UX by reducing stage1 verbosity and writing better and more consistent error messages. As we look towards the next rkt releases, we will be focusing more on UX improvements.

Get Involved

Be a part of the development of rkt or join the discussion through the rkt-dev mailing list or GitHub issues. We welcome you to contribute directly to the project.