rkt v0.3.0 Release Notes
-
๐ This is largely a momentum release but it does introduce a few new user-facing ๐ features and some important changes under the hood which will be of interest to developers and distributors.
First, the 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 isrkt trust --prefix coreos.com/etcd
. See the commit for other examples.rkt list
is an extremely simple tool to list the containers on the system
๐ As mentioned, v0.3.0 includes two significant changes to the Rocket build process:
- 0๏ธโฃ Instead of embedding the (default) stage1 using go-bindata, Rocket now
consumes a stage1 in the form of an actual ACI, containing a rootfs and
stage1 init/exec binaries. By default, Rocket will look for a
stage1.aci
in the same directory as the location of the binary itself, but the stage1 can be explicitly specified with the new-stage1-image
flag (which deprecates-stage1-init
and-stage1-rootfs
). This makes it much more straightforward to use alternative stage1 images with rkt and facilitates packing it for different distributions like Fedora. - Rocket now vendors a copy of the appc/spec instead of depending on HEAD. This means that Rocket 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 a particular release of Rocket is compiled.
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
๐ will build 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.