Soon after i published my last blogpost (Raspberry Pi + Docker + RTL-SDR) i received a bunch of feedback, questions and critic.
“Why not just compile the applications directly?” – “I may be missing the point here but why bother with Docker on the Pi?” – “It does nothing to help the Dump1090 program at all.”
So I’d like to adress some of the points in this post and explain my motivation for using Docker.
Let’s start right away with the most controversial question: Why Docker on a Pi?
Well, because it’s possible 🙂 About two weeks ago i stumbled over a blog post from the guys at Hypriot. They not only managed to install Docker on a Raspberry, they also packaged a nice and easy to use SD-Card image which i used for my first experiments. I already have some substantial background in terms of Docker as we’re using this in larger scale in our company. The concept of Containers and Images is a nice fit if you want to build an orchestrated and reproducible toolchain for you RTL-SDR – Build your Image, upload it to the docker hub – the next time you’re reinstalling your Pi (or installing a new one) you just have to run one command and the exact same version, incl. all the dependencies will be downloaded from the hub and ready to use in minutes. So no problems with outdated Howtos, updated libraries, missing git repositories etc.
But is it really worth the overhead? Starting a virtual machine for every application?
Good point – but wrong assumption 🙂 Docker is not a “Virtual Machine” – it is not virtualising anything at all. Docker orchestrates/restricts/isolates the resource of the host system, which also means there is virtually no overhead in terms of cpu and memory consumption.
Hm, what about the disk utilisation? An image can easily reach 50 times the size of the app itself!
Yeah, that’s right and the cause why I prefer to use a Baseimage which are then used by all my subsequent Images. Let me show you the current dependency tree of my images.
6cd883bd7952 Virtual Size: 87.8 MB Tags: resin/rpi-raspbian:wheezy
└─160e0d7fdd4f Virtual Size: 229.2 MB Tags: sysrun/rpi-rtl-sdr-base:0.4, sysrun/rpi-rtl-sdr-base:latest
└─5a7d98f74b77 Virtual Size: 229.8 MB Tags: sysrun/rpi-fr24feed:latest
└─99c005078348 Virtual Size: 248.2 MB Tags: sysrun/rpi-kalibrate:latest
└─382a689e98b6 Virtual Size: 238.2 MB Tags: sysrun/rpi-dump1090:latest, sysrun/rpi-dump1090:tedsluis
└─2fb91b90eee5 Virtual Size: 229.4 MB Tags: sysrun/rpi-acarsx:latest
└─57b3e2ee77fe Virtual Size: 231.4 MB Tags: sysrun/rpi-rtl_433:latest
My sysrun/rpi-rtl-sdr-base base image is derived from resin/rpi-raspbian:wheezy. The Baseimage is ~141MB larger compared to the raspbian image, because the rtl-sdr-baseimage includes several additional packages (git, c++, make etc.) and the RTL-SDR applications and libraries.
Derived from my Baseimage, you see several Childs like rpi-dump1090, rpi-kalibrate and others. These images are just 1 to 10 MB bigger than our Baseimage as they’re just adding the applications on top of the base layer. Now, when i change the Dockerfile for rpi-dump1090 and rebuild the Image, docker will just add a new Layer of ~10MB. The old, unreferenced layer can easyly be removed to save space.
This feature of layers is getting practical when you start to work with the docker hub. I’ll give you a small example:
You want to use your Raspberry as a FlightRadar24 feeder. Just install docker on your system (either by using a prepared sd-card image or by installing it via apt) and run the following commands:
First start dump1090. Docker will now download several layers from the docker hub. The download size is roughly 230MB. After the image is downloaded, it will start dump1090.
# start dump1090
docker run -it --rm --device /dev/bus/usb --name dump1090 \
--quiet --net --modeac
Now open a second ssh session and start fr24feed. This download will be much faster as docker has already downloaded the baseimage while downloading the dump1090 image. So the download size for the fr24feed image is just ~1MB!
# open another ssh session and start fr24feed
docker run -it --rm --name fr24feed --link dump1090:dump1090 \
--fr24key= --receiver=beast-tcp --logmode=0 --host=dump1090:30005
In one of my upcoming blog posts, ill experiment with docker-compose which is optimal for service dependencies like the example above.
If you have questions, just drop me a line via twitter or in the comments 🙂