Docker

2025/01 Update https://github.com/NetBSDfr/smolBSD/tree/main/k8s

I had to do it.
So here’s how to run a NetBSD micro-vm as… a Kubernetes pod.

First thing is to modify the start script from the previous article in order to add Docker-style networking, i.e. port forwarding from the host to the micro-vm. This is done using the hostfwd flag in qemu’s -netdev parameter

#!/bin/sh

kernel=$1

img=${2:-"root.img"}

[ -n "$3" ] && drive2="-drive file=${3},if=virtio"

qemu-system-x86_64 -enable-kvm -m 256 \
        -kernel $kernel -append "console=com root=ld0a" \
        -serial mon:stdio -display none \
        -drive file=${img},if=virtio $drive2 \
        -netdev user,id=net0,hostfwd=tcp::8080-:80 -device virtio-net,netdev=net0

In the previous experience we mapped the kernel and the root image from the host using Docker’s -v parameter, and while it’s possible to map files from the host using a Kubernetes volume, we will bundle NetBSD these files into the Docker image to make things easier.
Please refer to mksmolnb documentation to learn how to produce a minimal nginx micro-vm.

I have this little toy project for quite a while now, and I have this idea of handling a fleet of NetBSD micro-vms with Kubernetes since I started my new job in which I am caring a k8s cluster.

I came to realize that starting a smolBSD micro-vm with Docker was not so difficult after all. Using mksmolnb’s startnb.sh I came up with this very simple Dockerfile:

FROM alpine:latest

RUN apk add --quiet --no-cache qemu-system-x86_64 iproute2 bridge-utils

COPY startnb.sh ./
COPY qemu/qemu-ifup qemu/qemu-ifdown /etc/

CMD /startnb.sh /netbsd-SMOL ${IMG} ${DISK}

qemu-ifup being a simple copy of Debian’s /etc/qemu-ifup.

As a password-store user, GPG is particularly important and sensitive, I use it for pretty much everything authentication / encryption related. Also, about a year ago I got myself a pair of Yubikeys, and they are now involved in all of the mentioned workflows.

Now on the topic, as my keys are a crucial part of my online life, I wanted to make sure I had those backuped safely, and moreover, that this backup is usable in an empty environment by simply importing the public and private keys. Among the various possibilities, I thought firing up a basic docker container with an interactive shell would be my fastest bet. How wrong I was.

With all the noise around those topics I would have imagined this one had been covered thousands of time, yet I did not find a single complete resource on this subject which I found to be a basic building block: pushing docker images from GitLab CI to the Docker Hub registry.

There’s actually an opened issue on Docker GitHub’s that’s sitting there for 3 years, and it really feels more like a political / strategic / commercial issue than a technical one. Point being, there’s no straightforward integration between GitLab.com and Docker Hub.

No, I’m not following the hype, only I like to test things plus I feel there will be a growing demand for docker at ${DAYWORK}. I read here and there that CoreOS was the Linux distribution of choice to play with docker, so while at it, I picked up this one to dive into the container world. Finally, I’ve been willing to put my hands on bhyve for quite a while, so I took this opportunity to learn all those new (to me) technologies at once.