Down the rabbit hole

10th August 2018 1 By Jonny

What’s next for the cluster?

Having successfully installed a k8s cluster, the obvious question to ask is ‘what’s next?’ or ‘what do I do with this?’. There are plenty of options available here – basically anything that can run on a Raspberry Pi can be containerised and deployed as an application on k8s.

Starting with something simple, it’s the good old reliable web server deployment. In this case, it will unsurprisingly be, nginx. A not very exciting start, and it is launched with the simple command line below:

kubectl run nginx --image=nginx

The above command instructs k8s to launch a pod named nginx using an image named nginx. What this actually does is pull the nginx image from hub.docker.com as this is the default image repository configured when docker was installed at the outset. The nginx image is the ‘official’ nginx image in this repository. Browsing to this image, it becomes apparent that there are multiple versions available all with different tags. It would have been equally valid to launch an nginx pod as follows:

kubectl run nginx --image=nginx:alpine

This will actually run the nginx web server in a pod using Alpine Linux as the container image. Alpine Linux is, according to it’s web-site, a security-oriented, lightweight Linux distribution based on musl libc and busybox. This would seem to make it a perfect match for a Pi-based k8s cluster.

What’s in that image, and can I trust it?

This method pulls the image from hub.docker.com, which is fine in this instance – it’s taking the officially provided nginx image, and as such it is reasonable to expect this image to ‘just work’, which indeed it does. However, this may not always be the case, and it may well be that a future application takes an image from a non-official source. Ultimately, the hub.docker.com image repository can be a bit of a free-for-all in that anyone can create a Dockerfile and have an image built and therefore made available. With no control over what’s actually in the image …

The advantages of using the hub.docker.com repository are:

  • Lots of content
  • Pretty much always available (docker installations always point to it)
  • Free to use
  • Easy front end and hooks into Github, Bitbucket, and others

The disadvantages to using hub.docker.com are (as I see it anyway):

  • Free for anyone and everyone to use – do you trust these people?
  • No container image validation – you can be pretty sure ‘official’ images are safe, but what about the others?
  • Are images kept up to date, or are there a lot of ‘abandoned’ images?

Mainly, my concern comes down to whether I can trust the images hosted and whether I think they’re kept up to date. I also have to be happy with the method used to create the image in the Dockerfile by the container image author. The hub.docker.com registry does make it easy to view the Dockerfile used to build an image. It is therefore relatively straightforward to build your own version of the image, and to inspect what exactly is being included in the image.

There are other public image registries available, such as Google Container Repository (gcr.io) and Quay (quay.io), but hub.docker.com is undoubtedly the market leader. I have noted, though, that docker are now pushing store.docker.com as the ‘marketplace’ – it would appear that docker are perhaps trying to monetise their position?

Taking the nginx:alpine Dockerfile as an example, I can see that it’s actually created from a parent image:

FROM alpine:3.7

This nginx image is being built on top of the alpine:3.7 container image, whose Dockerfile looks like this:

FROM scratch
ADD rootfs.tar.gz /
# ensure UTC instead of the default GMT
COPY UTC /etc/localtime
CMD ["/bin/sh"]

An imaging service

It turns out anyone can create this image easily enough – in fact, I’m not even going to mess about with emulating the Pi ARM architecture on an x86_64 system, I’m just going to create my own image directly on a spare Pi system I have lying about.

I did say earlier that I like using Raspberry Pi systems for projects, and as such I have a few spare boards knocking around.

However, Alpine Linux 3.8 has recently been released, so I have built both a 3.7 and 3.8 base image. My Dockerfile for 3.8 looks as follows:

FROM scratch
LABEL architecture="ARM32v7/armhf" alpineversion="3.8.0" build="09082018"

ADD alpine-minirootfs-3.8.0-armhf.tar.gz /
CMD ["/bin/sh"]

Very simple and straightforward. The next step in the process is to make sure this image I’ve created is available to my k8s cluster nodes. That means I need my own container registry service set up, or I could host this Dockerfile and content on Github or Bitbucket and link to hub.docker.com. I prefer to keep everything local rather than point back to the Internet. Fortunately, setting up a container registry is a relatively simple task … which I’ll cover off next time.