The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Get Started with rkt Containers in Three Minutes

Get Started with rkt Containers in Three Minutes

February 4, 2016 ยท By Derek Gonyeo

This week we're announcing the 1.0 release of rkt, and this guide will help you get up and running with the project, all the way from installing rkt to building and running your own app container image.

Follow along with the steps below while you check out this screencast that illustrates each:

Installing rkt

rkt is packaged for a few Linux distributions, like Arch and Fedora Rawhide. Check your distribution to see if it's available. If not, rkt can easily be fetched from the rkt releases page on GitHub. Simply download the latest release, extract it, and get rkt (and the stage 1 ACIs) into your PATH or set an alias.

wget https://github.com/coreos/rkt/releases/download/v1.0.0/rkt-v1.0.0.tar.gz
tar xfv rkt-v1.0.0.tar.gz
alias rkt="sudo '${PWD}/rkt-v1.0.0/rkt'"

Running A Container

With rkt installed, let's try to run something. Since rkt is an implementation of the appc spec, it runs App Container Images, or ACIs. Quay, by CoreOS, can automatically convert any container image it's hosting to an ACI. Let's use this to run Alpine:

# rkt run --interactive quay.io/coreos/alpine-sh
rkt: using image from local store for image name coreos.com/rkt/stage1-coreos:1.0.0
rkt: searching for app image quay.io/coreos/alpine-sh
rkt: remote fetching from URL "https://quay.io/c1/aci/quay.io/coreos/alpine-sh/latest/aci/linux/amd64/"
prefix: "quay.io/coreos/alpine-sh"
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>
Trusting "https://quay.io/aci-signing-key" for prefix "quay.io/coreos/alpine-sh" without fingerprint review.
Added key for prefix "quay.io/coreos/alpine-sh" at "/etc/rkt/trustedkeys/prefix.d/quay.io/coreos/alpine-sh/bff313cdaa560b16a8987b8f72abf5f6799d33bc"
rkt: downloading signature from https://quay.io/c1/aci/quay.io/coreos/alpine-sh/latest/aci.asc/linux/amd64/
Downloading signature: [=======================================] 473 B/473 B
Downloading ACI: [=============================================] 2.65 MB/2.65 MB
rkt: signature verified:
  Quay.io ACI Converter (ACI conversion signing key) <support@quay.io>
/ #

With that, you've got a prompt inside an Alpine container. When you're done, you can exit out of any rkt container by pressing Ctrl+] three times.

You can also run docker containers from docker-only registries with rkt. When you prefix a container name with docker://, rkt will fetch the docker container, use docker2aci to convert it to an ACI, and then run it. Not all Docker images have signatures to verify, so we simplify this example by specifying the --insecure-options=image option to rkt:

# rkt run --interactive docker://ubuntu --insecure-options=image
rkt: using image from local store for image name coreos.com/rkt/stage1-coreos:0.14.0
rkt: remote fetching from URL "docker://ubuntu"
Downloading sha256:8387d9ff001: [==============================] 65.7 MB/65.7 MB
Downloading sha256:3b52deaaf0e: [==============================] 71.5 KB/71.5 KB
Downloading sha256:4bd501fad6d: [==============================] 681 B/681 B
Downloading sha256:a3ed95caeb0: [==============================] 32 B/32 B
root@rkt-1c7e841c-2696-4b98-bbb1-8b45e09cc4c1:/#

Making Your Own Containers

Building your own ACIs is also fairly straightforward. In this example we're going to make a container that runs a static go binary.

Create A Hello Go Application

Let's say, for example, that you have a simple go application:

package main

import (
        "log"
        "net/http"
)

func main() {
        http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
                log.Printf("request from %v\n", r.RemoteAddr)
                w.Write([]byte("hello\n"))
        })
        log.Fatal(http.ListenAndServe(":5000", nil))
}

Let's statically link the application, so we can ship an ACI with no external dependencies.

With Go 1.4:

$ CGO_ENABLED=0 GOOS=linux go build -o hello -a -installsuffix cgo .

or with Go 1.5:

$ CGO_ENABLED=0 GOOS=linux go build -o hello -a -tags netgo -ldflags '-w' .

Before proceeding, verify that the produced binary is statically linked:

$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
$ ldd hello
        not a dynamic executable

Create The Image

To create the image, we can use acbuild, which can be downloaded via one of the releases in the acbuild repository.

The following commands will create an ACI containing our application and important metadata.

acbuild begin
acbuild set-name example.com/hello
acbuild copy hello /bin/hello
acbuild set-exec /bin/hello
acbuild write hello-latest-linux-amd64.aci
acbuild end

Running The Image

And with that, you can use rkt to run the resulting image:

# rkt run --insecure-options=image --net=host hello-0.0.1-linux-amd64.aci

At this point our hello app is running on port 5000 and ready to handle HTTP requests.

$ curl http://localhost:5000
hello

Note that we used --insecure-options=image again, because we didn't sign the image. See the Signing and Verification Guide for more details about how to sign images for production distribution.

We also used --net=host to make the app run on the host's network stack, otherwise we would've had to get the pod's IP address with rkt list, and curl that.

Onward with rkt

As you see, you can get started with rkt in minutes. With rkt, you get the benefits of a secure, pluggable container runtime developed by CoreOS. Get involved with the continued development of rkt by joining the discussion on the rkt-dev mailing list or on the #rkt-dev Freenode IRC channel, by joining community meetings, by filing GitHub issues, or contributing directly to the project.

Continue reading on coreos.com