Skip to main content

rkt v0.10.0: With a New API Service and a Better Image Build Tool

rkt v0.10.0 is here and marks another important milestone on our path to creating the most secure and composable container runtime. This release includes an improved user interface and a preview of the rkt service API, making it even easier to experiment with rkt in your microservices architectures.

rkt is an application container runtime for Linux, built to be composable, efficient, and secure for production environments. We encourage you to join the community to test and influence rkt as it advances toward v1.0. To get started with rkt and the new features right away, visit the rkt project on GitHub.

Try rkt easily with acbuild

Until this point, there were limited simple workflows to create images in rkt's native format, ACI (Application Container Image). While ACIs could be manually constructed with tools like actool, or converted from existing projects using goaci or docker2aci (which rkt uses internally to run Docker images), there was no easy workflow to build images from scratch. Now with rkt v0.10.0, we have added an easier way to build ACIs.

The new acbuild implements a simple, controlled build environment while benefitting from the flexibility of the Linux toolchain (e.g. shell scripts, Makefiles). Releases in the acbuild repository are designed to allow detailed control over the image creation process from a reusable and extendable command-line tool. The result is a flexible and easy-to-extend tool that allows complete control over the image build process.

A build with acbuild is explicitly started with begin and finished with end. Information about an ongoing build is stored in the current working directory, instead of being tracked by a long-lived daemon or in a global file. A build can be started either from scratch (an empty ACI) or based on an existing initial ACI.

The following script is a simple example of building an nginx application container. For a more detailed example, check out rkt’s getting started guide.

acbuild begin quay.io/listhub/alpine
acbuild set-name example.com/nginx
acbuild run apk update
acbuild run apk add nginx
acbuild set-exec -- /usr/sbin/nginx -g "daemon off;"
acbuild port add http tcp 80
acbuild mount add html /usr/share/nginx/html
acbuild label add arch amd64
acbuild label add os linux
acbuild write --overwrite nginx-latest-linux-amd64.aci
acbuild end

We're excited to have an easy-to-use, powerful tool for building ACIs, and look forward to seeing how the community uses it.

Mount Arbitrary Volumes

In earlier versions of rkt and the appc specification, mounting a filesystem inside a pod required specifying the source volume and target mountpoint in the ACI manifest. This made it difficult to add volumes at runtime, as an ACI needed advance knowledge of filesystem details at the time of its creation. In rkt v0.10.0, it's now possible to mount arbitrary volumes from the host into pods with the --mount flag.

The --mount flag defines a mapping between volumes (configured with the --volume flag) and a path in the app. This will override any mount points specified in the app's image manifest.

This can be done either at a per-app level or for every app in a pod. In the following example, the --mount option is positioned after the app name; it defines the mount only in that app:

$ rkt run --volume logs,kind=host,source=/srv/logs \
    example.com/app1 --mount volume=logs,target=/var/log \
    example.com/app2 --mount volume=logs,target=/opt/log

In this next example, the --mount option is positioned before the app names. It defines mounts on all apps: both app1 and app2 will have /srv/logs from the host accessible at /var/log in their respective filesystems.

$ rkt run --volume logs,kind=host,source=/srv/logs \
    --mount volume=data,target=/var/log \
    example.com/app1 example.com/app2

Experimental API Service

The previous release of rkt, v0.9.0, introduced an alpha API definition for exposing read-only information about the state of rkt pods and images on a system. Development has continued and rkt v0.10.0 now includes an early, experimental version of a service exposing this API.

The API service monitors pods running on the local machine to deliver a stream of events to third-party applications, using a protocol based on Google Protocol Buffers. Third-party applications can also query the status of pods and applications executed by rkt. This protocol is designed to be extensible, but with the speed of a binary transport.

This API enables better integration between rkt and other projects like Kubernetes and Tectonic. rkt aims to be highly modular and flexibly composable, and the API service advances this goal. The status API is the foundation on which we’re actively developing a series of user-facing features for delivery in future releases.

Better Documentation

This release includes better documentation for users and developers, including a comparison of rkt to other projects, and a more detailed explanation of rkt’s internal architecture.

Wider Availability

Even though rkt is still pre-1.0 and not yet recommended for production use, we are excited to see a number of integrations emerging in the ecosystem. In the last few months, Hashicorp added support for rkt as a container runtime in the latest release of Nomad and Rancher Labs noted rkt can now be used in RancherOS. For added support across more platforms, let us know and notify your provider. We are interested in learning about your environment and project goals, and where you’d like to deploy rkt to run your applications.

Be a part of the rkt Project

Get involved in the rkt community via discussion on the rkt-dev mailing list or on the #rkt-dev Freenode IRC channel, by filing GitHub issues, or contributing directly to the project.