Rocket: First steps

Rocket is a container runtime for CoreOS. In this post we will do some basic tasks with Rocket: installing it, creating an ACI, publishing that ACI to OpenStack Swift, and pulling it down.

wget https://github.com/coreos/rocket/releases/download/v0.3.1/rocket-v0.3.1.tar.gz
tar xzvf rocket-v0.3.1.tar.gz
cd rocket-v0.3.1
./rkt help

I moved 'rkt' and 'stage1.aci' to ~/bin for ease of use.

We also need actool:

derp@myrkt:~$ git clone https://github.com/appc/spec.git
Cloning into 'spec'...
remote: Counting objects: 1604, done.
remote: Compressing objects: 100% (20/20), done.
Receiving objects: 100% (1604/1604), 614.19 KiB | 0 bytes/s, done.
remote: Total 1604 (delta 7), reused 1 (delta 0)
Resolving deltas: 100% (924/924), done.
Checking connectivity... done.
derp@myrkt:~$ cd spec/
derp@myrkt:~/spec$ ls
ace  aci  actool  build  CONTRIBUTING.md  DCO  discovery  examples  Godeps  LICENSE  pkg  README.md  schema  SPEC.md  test  VERSION
derp@myrkt:~/spec$ ./build 
Building actool...
go linux/amd64 not bootstrapped, not building ACE validator
derp@myrkt:~/spec$ ls bin/actool 
bin/actool
derp@myrkt:~/spec$ ./bin/actool -h
Usage of actool:
  -debug=false: Print verbose (debug) output
  -help=false: Print usage information and exit 

Now we need a simple go application:

package main

import (
    "log"
    "net/http"
)

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

And a manifest.json file:

 {
    "acKind": "ImageManifest",
    "acVersion": "0.2.0",
    "name": "nializer/daemon",
    "labels": [
        {
            "name": "version",
            "value": "1.0.0"
        },
        {
            "name": "arch",
            "value": "amd64"
        },
        {
            "name": "os",
            "value": "linux"
        }
    ],
    "app": {
        "user": "root",
        "group": "root",
        "exec": [
            "/bin/daemon"
        ],
        "ports": [
        {
            "name": "www",
            "protocol": "tcp",
            "port": 5000
        }
        ]
    },
    "annotations": [
        {
        "name": "authors",
        "value": "Kelsey Hightower , Spencer Krum "
        },
        {
            "name": "created",
            "value": "2014-10-27T19:32:27.67021798Z"
        }
    ]
}

And a file structure:

root@myrkt:~/app# find daemon-layout/
daemon-layout/
daemon-layout/rootfs
daemon-layout/rootfs/bin
daemon-layout/rootfs/bin/daemon
daemon-layout/manifest

Then we can build(and verify) this image:

root@myrkt:~/app# find daemon-layout/
daemon-layout/
daemon-layout/rootfs
daemon-layout/rootfs/bin
daemon-layout/rootfs/bin/daemon
daemon-layout/manifest
root@myrkt:~/app# actool build daemon-layout/ daemon-static.aci
root@myrkt:~/app# actool --debug validate daemon-static.aci 
daemon-static.aci: valid app container image 

Then we can run the image (this doesn't work):

root@myrkt:~/app# rkt run daemon-static.aci
/etc/localtime is not a symlink, not updating container timezone.
Error: Unable to open "/lib64/ld-linux-x86-64.so.2": No such file or directory
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Unmounting file systems.
Unmounting /proc/sys/kernel/random/boot_id.
All filesystems unmounted.
Halting system. 

The issue is that our go binary is not statically compiled:

root@myrkt:~/app# ldd daemon
        linux-vdso.so.1 =>  (0x00007fff2d2cd000)
        libgo.so.5 => /usr/lib/x86_64-linux-gnu/libgo.so.5 (0x00007ff809e45000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff809c2f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff809868000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff80aca3000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff80964a000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff809344000) 

But this is okay because we can just add these files (plus a few more) to our ACI:

root@myrkt:~/app# find daemon-layout/
daemon-layout/
daemon-layout/rootfs
daemon-layout/rootfs/lib64
daemon-layout/rootfs/lib64/libc.so.6
daemon-layout/rootfs/lib64/ld-linux-x86-64.so.2
daemon-layout/rootfs/bin
daemon-layout/rootfs/bin/daemon
daemon-layout/rootfs/usr
daemon-layout/rootfs/usr/lib
daemon-layout/rootfs/usr/lib/x86_64-linux-gnu
daemon-layout/rootfs/usr/lib/x86_64-linux-gnu/libgo.so.5
daemon-layout/rootfs/lib
daemon-layout/rootfs/lib/x86_64-linux-gnu
daemon-layout/rootfs/lib/x86_64-linux-gnu/libpthread.so.0
daemon-layout/rootfs/lib/x86_64-linux-gnu/libc.so.6
daemon-layout/rootfs/lib/x86_64-linux-gnu/libgcc_s.so.1
daemon-layout/rootfs/lib/x86_64-linux-gnu/libm.so.6
daemon-layout/manifest 

Now we can re-build, verify, run:

root@myrkt:~/app# actool build --overwrite  daemon-layout/ daemon.aci                                                                                          
root@myrkt:~/app# actool --debug validate daemon.aci                                                                                                           
daemon.aci: valid app container image
root@myrkt:~/app# du -sh daemon.aci
5.6M    daemon.aci
root@myrkt:~/app# rkt run daemon.aci
/etc/localtime is not a symlink, not updating container timezone.
2015/02/11 13:32:58 OHAIDER: request from 127.0.0.1:55024

This means everything is working. You can exit by pressing ^] three times.

We can then post the daemon file to swift, using the tempurl system from a previous post. Then using a tiny url service, we can run the aci from the network:

root@myrkt:~/app# rkt fetch http://l.pdx.cat/nibz_daemon.aci
rkt: fetching image from http://l.pdx.cat/nibz_daemon.aci
Downloading aci: [============================================ ] 5.81 MB/5.84 MB
Downloading signature from http://l.pdx.cat/nibz_daemon.sig
EOF
root@myrkt:~/app# rkt run nibz_daemon
rkt only supports http or https URLs (nibz_daemon)
root@myrkt:~/app# rkt run http://l.pdx.cat/nibz_daemon.aci
rkt: fetching image from http://l.pdx.cat/nibz_daemon.aci
Downloading aci: [=====================================        ] 4.89 MB/5.84 MB
Downloading signature from http://l.pdx.cat/nibz_daemon.sig
EOF 

Okay, so that didn't work. Maybe later on I will figure that part out. I am particularly excited to use the swfit meta tags to add the security meta tags used by rocket for collecting signatures.

OpenStack Swift on HP Cloud

OpenStack Swift is the Object Storage component of OpenStack. It is roughly analogous to Amazon S3. HP Cloud (full disclaimer: I work at hp and get cloud resources for free) has an Object Storage component. This post will be about getting basic functionality out of it.

A very long document on HP's object storage can be found here. Reading as much of it as I have has permanently damaged my soul, so I am posting here to share my story, hopefully you won't have to spend so much time kicking it.

Usually when doing things on HP Cloud's OpenStack services I just poke around the command line utility's until I am happy. Let's look at basic tooling with the python-swiftclient tool:

Check deps:

$: pip install -U python-swiftclient
Requirement already up-to-date: python-swiftclient in /disk/blob/nibz/corepip/lib/python2.7/site-packages
Requirement already up-to-date: six>=1.5.2 in /disk/blob/nibz/corepip/lib/python2.7/site-packages (from python-swiftclient)
Requirement already up-to-date: futures>=2.1.3 in /disk/blob/nibz/corepip/lib/python2.7/site-packages (from python-swiftclient)
Requirement already up-to-date: requests>=1.1 in /disk/blob/nibz/corepip/lib/python2.7/site-packages (from python-swiftclient)
Requirement already up-to-date: simplejson>=2.0.9 in /disk/blob/nibz/corepip/lib/python2.7/site-packages (from python-swiftclient)  

Check creds:

$: [ -z $OS_PASSWORD ] && echo set password
$: [ -z $OS_TENANT_NAME ] && echo set tenant name
$: echo $OS_AUTH_URL
https://region-b.geo-1.identity.hpcloudsvc.com:35357/v2.0/

With that set, we can use the swift command line client to upload, list, download, and delete files. All swift objects are put in containers, the equivalent of s3 buckets.

$: swift list craigslist
x220t.jpg
$: swift upload craigslist r61e.jpg
r61e.jpg
$: swift download craigslist x200t.jpg
Object 'craigslist/x200t.jpg' not found
$: swift list craigslist
r61e.jpg
x220t.jpg
$: time swift list craigslist
r61e.jpg
x220t.jpg

real    0m1.913s
user    0m0.283s
sys    0m0.051s
$: swift download craigslist x220t.jpg
x220t.jpg [auth 6.971s, headers 13.029s, total 13.314s, 0.002 MB/s]
$: swift delete craigslist r61e.jpg
r61e.jpg
$: time swift list craigslist
x220t.jpg

real    0m2.330s
user    0m0.299s
sys    0m0.059s


As you can see from the timing information, some of the operations are fast and some are slow. Swift download provides it's own timing information, which is nice. All upload/download operations above are authenticated through keystone. To provide a 'fake cdn' service like amazon s3, swift uses tempurls. This is how tempurls are typically used:

$: swift tempurl GET 3600 /v1/10724706841504/craigslist/x220t.jpg
Usage: swift tempurl <method> <seconds> <path> <key>
Generates a temporary URL for a Swift object.

Positions arguments:
  [method]              An HTTP method to allow for this temporary URL.
                        Usually 'GET' or 'PUT'.
  [seconds]             The amount of time in seconds the temporary URL will
                        be valid for.
  [path]                The full path to the Swift object. Example:
                        /v1/AUTH_account/c/o.
  [key]                 The secret temporary URL key set on the Swift cluster.
                        To set a key, run 'swift post -m
                        "Temp-URL-Key:b3968d0207b54ece87cccc06515a89d4"'
$: swift tempurl GET 3600 /v1/10724706841504/craigslist/x220t.jpg supersecret
/v1/10724706841504/craigslist/x220t.jpg?temp_url_sig=7388703d11f6a3362dff1008a2f5dd3b2fd31293&temp_url_expires=1423453300

Then, given this information you prepend the root url of the swift service and curl at it (don't forget single quotes!):

$: swift tempurl GET 3600 /v1/10724706841504/craigslist/x220t.jpg supersecret
/v1/10724706841504/craigslist/x220t.jpg?temp_url_sig=7388703d11f6a3362dff1008a2f5dd3b2fd31293&temp_url_expires=1423453300
$: keystone catalog | grep -i object
Service: object-store
|  publicURL  | https://region-b.geo-1.objects.hpcloudsvc.com/v1/10724706841504 |
| versionInfo |        https://region-b.geo-1.objects.hpcloudsvc.com/v1/        |
| versionList |          https://region-b.geo-1.objects.hpcloudsvc.com          |
$: curl 'https://region-b.geo-1.objects.hpcloudsvc.com/v1/10724706841504/craigslist/x220t.jpg?temp_url_sig=7388703d11f6a3362dff1008a2f5dd3b2fd31293&temp_url_expires=1423453300'
401 Unauthorized: Temp URL invalid


After poking this for some time I found this tibit buried in the HP Cloud docs on swift, er excuse me, Object Storage:

2.7.5.2 Differences Between Object Storage and OpenStack Swift TempURL Signature Generation

There are two differences between Object Storage and OpenStack Swift TempURL signature generation:

• OpenStack Swift Temporary URLs (TempURL) required the X-Account-Meta-Temp-URL-Key header be set on the Swift account. In Object Storage you do not need to do this. Instead we use Access Keys to provide similar functionality.
• Object Storage Temporary URLs require the user's Project ID and Access Key ID to be prepended to the signature. OpenStack Swift does not.

So this basically means you can't use the python-swiftclient tool with hpcloud object storage. At least nearby they provide a code snipit. I've created my own script.


$: python hpcloud_swift.py GET 3600 /v1/10724706841504/craigslist/x220t.jpg $OS_ACCESS_KEY_SECRET https://region-b.geo-1.objects.hpcloudsvc.com/v1/10724706841504/craigslist/x220t.jpg?temp_url_sig=10724706841504:KAPYAYFHCH51B3ZCCB4W:044cefcdf58d4bccea7da3a4836145488a7c8496&temp_url_expires=1423453940 


This depends on setting OS_ACCESS_KEY_ID and OS_ACCESS_KEY_SECRET in your environment. These are nonstandard environment variables. Once this is set, anyone will be able to prepend the object storage root url to the front of the url output by hpcloud_swift.py and make their own janky-cdn.

The script to perform the hpcloud fakery can be found here.