docker

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.

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.

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.

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.

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.