Some notes on Raspberry Pi

Some notes on Raspberry Pi

May 4, 2017 (849 words)

Having access to relatively cheap and high performance computer hardware is the foundation of having a new generation of enthusiasts. Raspberry Pi kind of fills that role, but many other alternative exists as well with the access of cheap ARM based CPUs and SoC.

The big downfall of these machines though are that they all seem to embrace Linux. Don’t get me wrong, Linux is great. For servers. For educational machines, perhaps not so much. I wish there were alternatives that essentially performed what I had on my C64 – instant computing and programming with a touch of a hardware power button.

In the absence of that, for now, I’ll collect some of my thoughts and notes on how to setup and configure Raspberry Pis at home. Mostly, since I forget myself every time I do that.

Hardware

Make sure that you get a proper, high performance SD card that does a good amount of IOPS, which really translates into good random 4k operations. Which you happen to incur a lot if you just have programmers use fopen() with the default buffer size.

Looking at the comparison made here of different cards, it seems like the best bet is to pick up a Samsung Evo+ 32Gb card ($20), or the 64Gb version ($29).

It’s super important to get a high performance card, otherwise the RPI will feel slow and useless.

If you really feel adventurous and have cattle raspberries then you could try to also overclock the SD card reader to boots the 4k read performance a little.

Installing Raspberry Pi Debian

  • Flash the image to an SD card
  • rpi-config, fix the SD card size, localization and enable ssh.
  • Change the root/pi passwords
  • reboot
  • apt-get install rpi-update
  • rpi-update
  • apt-get update && apt-get upgrade

Installing and configuring docker

Issue the following command:

curl -sSL https://get.docker.com | bash

After that the docker version (it’s also displayed at the end of this script) should show something like this:

Client:
 Version:      17.04.0-ce
 API version:  1.28
 Go version:   go1.7.5
 Git commit:   4845c56
 Built:        Mon Apr  3 18:22:23 2017
 OS/Arch:      linux/arm

Server:
 Version:      17.04.0-ce
 API version:  1.28 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   4845c56
 Built:        Mon Apr  3 18:22:23 2017
 OS/Arch:      linux/arm
 Experimental: false

Installing docker-compose

There is a ARM version of docker compose here, but the short story is that you can also just install docker-compose through pip.

apt install python-pip libyaml-cpp-dev
pip install docker-compose

The above on ARM seems to install though a python version of docker compose. Which in turns seems to bork some of the python integration to docker. So not an ideal situation. Probably at some point need to figure out how to install the go statically compiled version of docker compose on ARM as well.

Bringing up some UI

At this point you could login as root on the machine and edit ~/docker-compose.yaml and stick the following in it:

version: '2'

services:
  info:
    image: portainer/portainer:arm
    restart: always
    ports:
       - 9000:9000
    volumes:
       - /var/run/docker.sock:/var/run/docker.sock

Then you can issue the following in the home directory of the root user:

docker-compose up -d && docker-compose logs -f

At this time you can point your browser at your IP, e.g. http://raspberrypi.local:9000 and see something like an UI where you can inspect and see what is going on under docker on your machine.

And if you need to get access (unencrypted) to remote instances through the above UI, you also need to make the docker daemon listen to a TCP socket, see below:

$ cat /etc/systemd/system/docker.service.d/overlay.conf
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --storage-driver overlay -H fd:// -H tcp://0.0.0.0:2375
$ systemctl daemon-reload && /etc/init.d/docker restart

Building docker images

Seems to be two main repositories:

https://hub.docker.com/u/armhf/

https://hub.docker.com/u/hypriot/

Seems like the hypriot images are more likley to have source code for them.

In closing

In the end, RPI seems to have a couple of downsides:

  • In reality too slow for Mame emulation. Fine for NES, but most of the fun gems seems to be in the proper arcade version for MAME.
  • Distributing docker containers and load is fine, but you are stepping out of the trodden path. You now have a huge investment in fixing links (e.g. rancher doesn’t work out of the box etc) and the whole point of docker where things “just work” is broken. For cheap academic work perhaps this is fine.

My little cluster of RPI machines are actually not doing that much now. One is the SSH gateway. It runs a key authentication only scheme and so I can remotely access my home network if I need to.

The others really just are there for some experimentation. The fact that I’ve got them all in Ansible makes it pretty easy to wipe them again if I mess something up.

The final analysis is that I bought an Intel NUC just to be able to do a “docker pull” on most containers and just have them run, e.g. I wanted to have a local jenkins instance etc. Even though these are technically written in Java, they are still tied to x64!

References

https://medium.com/@bossjones/how-i-setup-a-raspberry-pi-3-cluster-using-the-new-docker-swarm-mode-in-29-minutes-aa0e4f3b1768

http://www.codesheppard.com/setting-up-a-local-rancher-cluster-with-raspberry-pi-s-and-an-old-laptop/

https://blog.linuxniche.net/2016/08/rancher-true-multi-arch-environment/

https://blog.hypriot.com/post/install-docker-on-chip-computer/