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
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.
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 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.
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.