----
Get Started with rkt Containers in Three Minutes
// CoreOS Blog
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.
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 export PATH=$PATH:`pwd`/rkt-v1.0.0
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:
# sudo 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:
# sudo 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 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.
----
Shared via my feedly reader
Sent from my iPhone
No comments:
Post a Comment