By Jonathan Boulle, February 6, 2015
Originally published on the CoreOS blog (archived copy) . Re-published with the authors' permission.
Today we're announcing the next release of Rocket and the App Container (appc) spec, v0.3.1.
This release of rkt includes new user-facing features and some important changes under the hood which further make progress towards our goals of security and composability.
First, the rkt CLI has a couple of new commands:
rkt trust can be used to easily add keys to the public keystore for ACI signatures (introduced in the previous release). This supports retrieving public keys directly from a URL or using discovery to locate public keys - a simple example of the latter is rkt trust --prefix coreos.com/etcd. See the commit for other examples.
rkt list 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 rkt.
As mentioned, v0.3.1 includes two significant changes to how rkt is built internally.
Instead of embedding the (default) stage1 using go-bindata, rkt now consumes a stage1 in the form of an actual ACI, containing a rootfs and stage1 init/enter binaries, via the --stage1-image flag. This makes it much more straightforward to use alternative stage1 image with rkt and facilitates packaging for other distributions like Fedora.
rkt now vendors a copy of appc/spec instead of depending on HEAD. This means that rkt can be built in a self-contained and reproducible way and that master will no longer break in response to changes to the spec. It also makes explicit the specific version of the spec against which particular release of rkt is compiled.
As a consequence of these two changes, it is now possible to use the standard Go workflow to build the rkt CLI (e.g. go get github.com/coreos/rocket/rkt). Note however that this does not implicitly build a stage1, so that will still need to be done using the included ./build script, or some other way for those desiring to use a different stage1.
This week saw a number of interesting projects emerge that implement the App Container Spec. Please note, all of these are very early and actively seeking more contributors.
Nose Cone is an appc runtime that is built on top of the libappc C++ library that was released a few weeks ago. This project is only a few days old but you can find it up on GitHub. It makes no use of rkt, but implements the App Container specification. It is great to see this level of experimentation around the appc spec: having multiple, alternative runtimes with different goals is an important part of building a robust specification.
A few tools have emerged since last week for building App Container Images. All of these are very early and could use your contributions to help get them production ready.
A Dockerfile and the "docker build" command is a very convenient way to build an image, and many people already have existing infrastructure and pipelines around Docker images. To take advantage of this, the docker2aci tool and library takes an existing Docker image and generates an equivalent ACI. This means the container can now be run in any implementation of the appc spec.
$ docker2aci quay.io/lafolle/redis
Downloading layer: 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158
...
Generated ACI(s):
lafolle-redis-latest.aci
$ rkt run lafolle-redis-latest.aci
[3] 04 Feb 03:56:31.186 # Server started, Redis version 2.8.8While a Dockerfile is a very convenient way to build, it should not be the only way to create a container image. With the new experimental goaci tool, it is possible to build a minimal golang ACI without the need of any additional build environment. Example:
$ goaci github.com/coreos/etcd
Wrote etcd.aci
$ actool -debug validate etcd.aci
etcd.aci: valid app container imageFinally, we have added experimental support for App Container Images to Quay.io, our hosted container registry. Test it out by pulling any public image using rkt:
$ rkt trust --prefix quay.io
Prefix: "quay.io"
Key: "https://quay.io/aci-signing-key"
GPG key fingerprint is: BFF3 13CD AA56 0B16 A898 7B8F 72AB F5F6 799D 33BC
Quay.io ACI Converter (ACI conversion signing key) <support@quay.io>
Are you sure you want to trust this key (yes/no)? yes
$ rkt run quay.io/philips/golang-outyet
$ curl 127.0.0.1:8080While 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 rkt and Nose Cone). This is just the beginning, but a great early example of the power of open standards.
Join us on a mission to create a secure, composable, and standards-based container runtime. If you are interested in hacking on rkt or App Container we encourage you to get involved:
There is still much to do - onward!