I have an old ThinkPad R61 with a cracked screen that has been gathering dust ever since Boy #2 inherited my old desktop. The idea of a [not quite] perfectly good computer going unused annoys me for some reason–there are potential CPU cycles that are simply not happening. While the hardware is dated, its Core2 Duo T7300 CPU runnng at 2.00GHz with 4GB of RAM certainly packs a much bigger wallop than my Raspberry Pi. So I decided to set it up as a host for running Docker containers. I then began my search for a suitable operating system.
It seemed to me as though an Atomic Host (http://www.projectatomic.io/) OS was exactly what I needed–an operating system “designed with the sole purpose of running containerized applications.” So I grabbed the CentOS 7 Atomic Host ISO image, burned it to a DVD (it was around 775MB and my CD-R media maxes out at 700MB), put it in the laptop and hit the power button. The install went smoothly and, even though I had an external monitor ready, was actually able to see everything well enough on the cracked screen.
Once in, I ran “sudo atomic host upgrade” to upgrade things (but it seemed like I already had the latest and greatest) and then restarted the machine. I was able to ssh into the the machine and then started running containers–everything worked smoothly. It was fast and easy to go from zero to Docker container on bare metal. I was pleased and ready to try more.
I then checked the docker version and discovered that it was still on a 1.8 version. I use Docker 1.8 and Kubernetes at work and was hoping to expand my horizons. Specifically I want to use 1.9 or later because at home I’m playing with the new networks feature and also the new networking functionality in v2 of Compose. Also, some of the fancy new images on Docker hub are officially supporting only 1.10.1. There didn’t seem to be an obvious way to update Docker to a new version, but I assumed that to be easily solvable with a little kicking and swearing so I put it on the back burner.
Since I could now access the machine remotely, I wanted to get if off my disheveled desk. I knew that thanks to my charging station there were plenty of free outlets, but places to plug in network cables are not as readily available in my home. Since the laptop has all the hardware necessary for wireless goodness, I figured I’d just set that up. Unfortunately, I couldn’t find any mention of configuring wireless networking on Atomic Host or even how to install drivers. I expect that the CentOS packages could be used, but since Atomic Host doesn’t have yum, the install would have to be very different. And so I decided that I wouldn’t use Atomic Host.
I only recently heard of Alpine Linux when I read that Docker Official Images are Moving to Alpine Linux, but I have used other BusyBox based distributions in the past, so I decided to give it a go. Downloading the svelte 86MB ISO was much faster than the Atomic Host image as was the process of burning to a CD (with plenty of room to spare). I put the disc in the laptop and booted it up.
Instead of an installer I got a message reading in part:
Mounting boot media failed. initramfs emergency recovery shell launched. Type 'exit' to continue boot
A little searching revealed the error to be not uncommon when booting from a USB drive, but I could find no mention of the problem occurring with an install from CDROM and the typical solution didn’t seem to quite fit. So I wrote the image to the USB drive, but the first time I tried, it hung while loading the installer. My third attempt had both the CD and the USB drive in the machine and I’m actually not sure which was used (or perhaps both?), but the installer loaded. It was a simple, text based user interface and the actual install process didn’t take too long.
Once installed, I wanted to see if I could succeed with Alpine where I failed with Atomic Host. Because of the lightweight nature of Alpine, wireless isn’t supported out of the box like it is in more robust distributions. However, following the clear instructions on instructions on the Alpine Wiki soon remedied my need for a wireless connection and I was ready to move the laptop off my disheveled desk–or so I thought.
There are a few ssh choices in the installer and I opted for OpenSSH. I tried to connect via ssh, but it would not accept my credentials. At first I thought I had forgotten the password. After panicking I then did some poking around and learned that /etc/ssh/sshd_config contains the directive “PasswordAuthentication no”. Presumably changing the “no” to “yes” would have worked, but I instead opted to use public/private RSA keys for authentication instead. I had no issues setting up the keys and then I could connect via SSH and I moved the laptop into the dining room and put it on a spare chair next to an empty outlet.
Since package managers and distributions often come with older versions, I like to follow these Linux Docker installation instructions. So I installed curl, but when I went to run the script it didn’t work as I’m accustomed to seeing on RHEL or Ubuntu.
alpy:~# curl -fsSL https://get.docker.com/ | sh< Either your platform is not easily detectable, is not supported by this installer script (yet - PRs welcome! [hack/install.sh]), or does not yet have a package for Docker. Please visit the following URL for more detailed installation instructions: https://docs.docker.com/engine/installation/
Once again I found a relevant Alpine Wiki page and once again found the instructions to be clear and easy to follow. I was further pleasantly surprised to see that it installed version 1.10.1 which had been built only four days previously.
Now I wanted to Docker Compose and I like to install it as a container. There were no errors on the install, but when I tried to run it I got:
alpy:~# which docker-compose /usr/local/bin/docker-compose alpy:~# docker-compose version -ash: docker-compose: not found
The fix for that was simply to modify the first line of /usr/local/bin/docker-compose to read “#!/bin/ash” instead of “#!/bin/bash“. After that it seemed happy.
Now I was ready to run some containers. I tried running a Docker Registry and got an error reading:
failed to register layer: ApplyLayer exit status 1 stdout: stderr: chmod /bin/mount: permission denied
The error actually occurred during the pull and I found I could not even pull the image (which is interesting because I had just successfully pulled and ran Compose). Searching revealed other people who had seen the same error on Alpine doing Dockery stuff. I found a blog entry about Installing Docker (Daemon) on Alpine Linux in which the author saw the error when running Docker build and gave a magic incantation to make the problem go away:
sysctl -w kernel.grsecurity.chroot_deny_chmod=0
Whatever that did under the covers, it removed the error. However, I immediately ran into other permission related problems.
alpy:~# docker run -d -p 5000:5000 --name registry registry:2 a8fc19a787c0ad7e5ea9fc17a7283261b68ac8fa4c154f7eea235bbf3978196d alpy:~# docker logs a8fc19a787c0ad7e5ea9fc17a7283261b68ac8fa4c154f7eea235bbf3978 196d /bin/registry: error while loading shared libraries: librados.so.2: cannot enable executable stack as shared object requires: Permission denied
I was able to get some other containers to work including a rest service that I wrote that uses Alpine as a base image, but I was troubled that the registry didn’t want to run. Alpine is not only small, but is also security-oriented. In this case it seems like it is too secure to run everything I need (at least without a lot of extra knowledge). And so I decided that I wouldn’t use Alpine.
The story continues in part 2.