Tag Archives: docker

Build Docker Client for ARMv8

The other day, after successfully building Docker-ce 17.06.0-dev for Odroid C2 which has ARMv8 CPU, i couldn’t find Docker client. Maybe it was just me not building the Docker engine correctly.

Anyway, after some more times, I also managed building the Docker client for the Odroid C2. It turned out, like many things, it wasn’t that  hard after you figured it out. It’s worth to note too that the build instruction on https://github.com/docker/cli is to use Docker container. It didn’t work for me, and I decided to just build the Docker cli locally on the Odroid C2 instead.

First clone the repository:

$ go get github.com/docker/cli
can't load package: package github.com/docker/cli: no Go files in /home/kenno/dev/gowork/src/github.com/docker/cli

So what just happened? Instead of running git clone https://github.com/docker/cli, I use go get command to pull the code from the repo to a path in $GOPATH, since I’m going to build it using go anyway.

Next we can just build it:

$ cd $GOPATH/src/github.com/docker/cli/cmd/docker
go build

When it’s finished, we can run the Docker cli:

Notice that we the Version, “Git commit”, and “Built” fields are set to unknown.

 Version:      unknown-version
 Git commit:   unknown-commit
 Built:        unknown-buildtime

Is there something we can do about? Yes, we can!

$ cd $GOPATH/src/github.com/docker/cli
$ source $GOPATH/src/github.com/docker/cli/scripts/build/.variables
$ go build -o "${TARGET}" --ldflags "${LDFLAGS}" "${SOURCE}"

After the compilation, the Docker cli binary file can be found in ./build directory.

Let’s run it again:

The Version field is still “unknown-version”. This makes sense as we build the code from the master branch.

Losing ZFS storage for Docker

I use ZFS as a storage driver for docker engine running on my machine. Today after my machine rebooted from a crash, yes Linux system crashes too, I notice that all my docker images and containers disappeared.

~ ❯❯❯ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
~ ❯❯❯ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

First thing came to my mind was “did I accidentally destroy docker zfs data set last night?”

# zfs list
NAME                                                                                USED  AVAIL  REFER  MOUNTPOINT
tank                                                                               1.52T   239G   120K  /tank
tank/docker                                                                         999M   239G  73.9M  /var/lib/docker

It’s still there. At that point I suspected that Docker might no longer use ZFS as its data storage.

~ ❯❯❯ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.1
Storage Driver: devicemapper
 Pool Name: docker-253:0-2753561-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 11.8 MB
 Data Space Total: 107.4 GB
 Data Space Available: 31.79 GB
 Metadata Space Used: 581.6 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
...

The output information from docker info command confirmed my suspicion. But how do we change the storage back to ZFS instead of devicemapper? According to ZFS storage in practice the only prerequisite to have ZFS as the data storage is having /var/lib/docker as a ZFS dataset.

I was under the impression that tank/docker was mounted to /var/lib/docker. Actually /var/lib/docker directory lived on my local LVM file system (hence devicemapper was the storage driver).

To fix this, I stopped docker service, cleared out /var/lib/docker, and re-mounted the tank/docker dataset.

# systemctl stop docker
# rm -rf /var/lib/docker/*
# mount tank/docker
# systemctl start docker

Let’s see if it’s working again.

docker info
Containers: 6
 Running: 0
 Paused: 0
 Stopped: 6
Images: 18
Server Version: 1.12.1
Storage Driver: zfs
 Zpool: tank
 Zpool Health: ONLINE
 Parent Dataset: tank/docker
 Space Used By Parent: 1047826432
 Space Available: 263167705088
 Parent Quota: no
 Compression: off

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
abiosoft/caddy      latest              af55a59400be        2 days ago          40.69 MB
...

Everything seemed to back to normal. I’m still not sure why tank/docker wasn’t mounted on boot, but I’ll leave it for another day. As for now, I’m quite happy.

Docker with OverlayFS on Ubuntu 15.10

As of today, the default storage for Docker on (K)Ubuntu 15.10 is AUFS. I want to switch it to OverlayFS. Personally, I’m still new to Docker, but I did hear that OverlayFS is better than AUFS. You can read more about OverlayFS here.

Anyway, the purpose of this post is how to switch OverlayFS and avoid head-scratching.

On Ubuntu 15.10 (wily), one can start/stop services either using Upstart or systemd. Since I want to get more accustomed to using systemd, I’ve been trying to use it anywhere possible. For example, here’s the command to start docker:

$ sudo systemctl start docker

To verify what storage driver used:

$ docker info 
Containers: 0
Images: 0
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 0
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-19-generic
Operating System: Ubuntu 15.10
CPUs: 4
Total Memory: 7.663 GiB
Name: f9470m

Okay, let’s begin to change the storage driver from AUFS to OverlayFS.

Lots of tutorials online including this one and this one, suggest to provide an option in /etc/default/docker.

DOCKER_OPTS="-s overlay"

or

DOCKER_OPTS="--storage-driver=overlay"

Unfortunately, it didn’t work for me. But when I started docker using upstart command as the following:

$ sudo service docker start

the storage driver has changed to “overlay” correctly!

$ docker info | grep -i driver
WARNING: No swap limit support
Storage Driver: overlay

It took me awhile to figure out that the option provided to /etc/default/docker is only for Upstart.

Well, now I at least know which direction; or questions I should ask Google. Docker has an article explaining how to control docker with systemd. With that, I was able to adapt it to pass an option to systemd docker.service to use OverlayFS.

Here’s how I did it.

First, I ensure that docker is not running.

$ sudo systemctl stop docker

If docker was started with Upstart use ($ sudo service docker stop instead.)

In my case, since I just started running Docker on this machine, I didn’t have any images or useful files. So I took an extra step to remove old AUFS files. You may need to think twice before running the following command. You might lose your important data!

If you’re unsure, don’t run it. You’ve been warned!

$ sudo rm /var/lib/docker -rf

Then create a directory, if not yet exist, /etc/systemd/system/docker.service.d. Create a file, call it whatever you like. I named it overlay.conf with the content:

[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// --storage-driver overlay

Now, start docker service with systemd again:

$ sudo systemctl start docker

We can verify it by running ‘docker info’:

$ docker info
Containers: 0
Images: 0
Server Version: 1.9.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-19-generic
Operating System: Ubuntu 15.10
CPUs: 4
Total Memory: 7.663 GiB
Name: f9470m

It’s working! Oh, if you’re wondering why I can just run docker command without prefix with sudo; it’s because my user account is docker group.

Happy dockering!