DEV Community: Istvan

Misusing Ninja

Istvan — Tue, 21 Feb 2023 16:04:55 +0000

Originally posted on: https://dev.l1x.be/posts/2023/02/21/misusing-ninja/

Abstract

In the world of software development, build systems are essential tools for compiling and linking source code into executables. While there are many build systems available (make, cmake), one of the most popular and powerful is the Ninja build system.

Developed by Evan Martin while working on the Chromium project at Google, Ninja is a fast, scalable, and cross-platform build system that has gained widespread adoption in the software development community. In this blog post, we'll take a closer look at the Ninja build system and its key features.

How Ninja Works

At its core, Ninja is a simple, low-level build system that aims to be fast and efficient. Ninja works by generating a graph of dependencies between input files and output files and then executing a series of build commands to transform the input files into the output files.

The input files are typically source code files written in a programming language such as C++, Rust, or in our case Python. The output files are the compiled object files, libraries, and executables that result from the build process. And this is where it gets interesting. You can safely ignore this part of Ninja and just use it as a dag orchestrator that executes commands in a certain order.

Ninja uses a file format called "build.ninja" to define the build graph and specify the build commands. The build.ninja file is a text file that describes the dependencies between the input and output files or in our case the build steps.

Key Features of Ninja

One of the main advantages of Ninja is its speed. Because Ninja generates a build graph that only includes the necessary build steps, it can execute builds quickly and efficiently. Additionally, Ninja can scale to handle large projects with many dependencies, making it a popular choice for building complex software applications. For our use case, it is not that much use but in case you are using it for a C++ project it is pretty good.

Another key feature of Ninja is its cross-platform support. Ninja is designed to work on multiple operating systems, including Windows, macOS, and Linux, which makes it easy to use in a variety of development environments. This is true if you have a way of making sure that the tools that are used in the build are present and have the same CLI on all systems you run your builds on.

Getting Started with Ninja

I usually learn by example and there aren't many examples around. I have read the original documentation and tried a few things out but finally, I understand how all things hang together.

There are 3 things that you need to know about a ninja build file:

rule
build
dependency

A rule is a description and a command that gets executed when the rule is invoked.

A build step is just calling a rule (or potentially multiple rules using dependencies).

A dependency is a concept of describing a relationship between rules.

Let's have a look at a basic example.

rule ok
  command = echo "ok"

build ok: ok

Invoking it:

❯ ninja ok
[1/1] echo "ok"
ok

Let's add a build that has two steps (sometimes called stages or targets).

rule one
  command = echo "one"

rule two
  command = echo "two"

build one: one
build two: two || one

With two pipe characters, we can express dependency between the build stages.

Invoking the build:

❯ ninja one
[1/1] echo "one"
one

❯ ninja two
[1/2] echo "one"
one
[2/2] echo "two"
two

This means we cannot forget to execute the first step when executing the second.

Using Ninja for building and deploying to the cloud

There is no point in writing an article without Docker in it so let's put Docker into Ninja.

version   = 0.6.0
aws_account_id = 11111111111


rule login-to-ecr
  command = aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin ${aws_account_id}.dkr.ecr.eu-west-1.amazonaws.com
  description = Logging in to ECR

rule init
  command = env | egrep AWS_PROFILE
  description = Displaying AWS_PROFILE


rule build-image
  command = docker build . -t depoxy:backend-api-${version} --file Dockerfile
  description = Building depoxy:backend-api-${version}

rule tag-image
  command = docker tag depoxy:backend-api-${version} ${aws_account_id}.dkr.ecr.eu-west-1.amazonaws.com/depoxy:backend-api-${version}
  description = Tagging depoxy:backend-api-${version}

rule upload-image
  command = docker push ${aws_account_id}.dkr.ecr.eu-west-1.amazonaws.com/depoxy:backend-api-${version}
  description = Push depoxy:backend-api-${version}



build login-to-ecr: login-to-ecr
build init: init || login-to-ecr
build build-image: build-image || init
build tag-image: tag-image || build-image
build upload-image: upload-image || tag-image

default login-to-ecr init build-image tag-image upload-image

There goes, a simple docker workflow implemented in Ninja. We use similar workflows to upload files to AWS and deploy with Terraform too. This unified our different build efforts mostly using YAML for CI/CD and made sure we do not forget anything while not needing to write a tonne of YAML.

The reduction from the YAML-based workflows is pretty significant:

+229 −1,633

To get started with Ninja

To get started with Ninja, you'll need to install the Ninja build system on your development machine. Ninja can be installed from package managers on the most popular operating systems, or you can download the source code and build it manually.

Once you have Ninja installed, you'll need to create a build.ninja file that describes your project's build process. You can create this file manually, or you can use a build system generator such as gn or Meson to generate it automatically.

Finally, you can run the Ninja build command to execute the build process and create the output files. Ninja will automatically track changes to input files and re-execute the build commands as needed, ensuring that your output files are always up-to-date.

Conclusion

The Ninja build system is a powerful and efficient tool for building software applications. With its speed, scalability, and cross-platform support, Ninja is a great choice for developers working on a wide range of projects. Whether you're building a small utility or a large, complex application, Ninja can help you streamline your build process and get your software up and running quickly. It helped us to move from YAML to a much better alternative while reducing the complexity of the CI/CD workflows. The next is to find a CI/CD platform that supports Ninja files or maybe to create a project that does exactly that.

Diving into Firecracker with Alpine

Istvan — Sun, 13 Dec 2020 22:23:03 +0000

Article series

Originally posted on:

Intro

Last time in the 1st article I briefly introduced Firecracker as a lightweight virtualization/containerization solution for extreme-scale (like AWS Lambda functions). This time around I am going to dig a bit deeper into the API and the management of microVMs. I am going to install Alpine on RPI, install Rust and Python, Docker, get the Linux kernel source and compile a new kernel with minimal config, compile our own Firecracker and then create a new rootfs to be able to boot up a guest. Most of these steps are optional, you can use the stock kernel the Firecracker team provides or download Firecracker release from Github.

Setup Alpine

If you do not care about Alpine on RPI you can jump to the Firecracker section.

I would like to keep going with Raspberry Pi 4B 8GB or Raspberry Pi 4B 4GB for many reasons. It is a small system that you can easily hack on without any change on your desktop. It is also an ARM64 (ARM Cortex-A72) system that has great performance even without active cooling. I usually use it with a alu case that provides the best heat dispersion and a cool CPU. It has enough CPU power and memory to compile any software including Firecracker, the Linux kernel, and more. Since this project is a side project I don't care how long it takes to finish a new kernel, usually finishes within 2 hours (I might get exact timing later).

Another item on my to-do list is to get Alpine Linux as both the host and the guest system. For those who do not know Alpine is a small Linux distribution designed for security, simplicity, and resource efficiency. It comes with sane defaults and Musl as its C standard library. Alpine uses its own package management system, apk-tools, providing super-fast package installation. Alpine allows a very small system with minimal installation being around 130 MB. The init system is the lightweight OpenRC, Alpine does not use systemd. This was the primary reason I wanted to get into Alpine.

Installing Alpine on RPI 4

This is the most complicated part of the setup because RPI has a special boot procedure that uses a FAT partition and the GPU. When installing Alpine first you need to create a FAT partition at the beginning of the SD card with MBR. I am using MacOS this time. I am pretty sure it is easy to translate this to Linux (not sure about Windows.)

Creating the partition

My microSD card is /dev/disk6. I create a partition with the name ALP (1024MB), then activate it with fdisk.

diskutil list
diskutil partitionDisk /dev/disk6 MBR "FAT32" ALP 1024MB "Free Space" SYS R
sudo fdisk -e /dev/disk6
> f 1
> w
> exit

After this command runs successfully MacOS mounts the newly created partition in /Volumes/ALP.

Downloading Alpine and writing it to the SD card

You can initiate the download anywhere, make sure the previously created partition is mounted.

wget http://dl-cdn.alpinelinux.org/alpine/v3.12/releases/aarch64/alpine-rpi-3.12.1-aarch64.tar.gz
tar xzvf alpine-rpi-3.12.1-aarch64.tar.gz -C /Volumes/ALP/

Configuring RPI boot

This part is optional, you can disable audio, wifi, Bluetooth, etc and enable UART, configure GPU mem. The full documentation is here:

https://www.raspberrypi.org/documentation/configuration/config-txt/

cd /Volumes/ALP/
echo 'dtparam=audio=off'          >> usercfg.txt
echo 'dtoverlay=pi3-disable-wifi' >> usercfg.txt
echo 'enable_uart=1'              >> usercfg.txt
echo 'gpu_mem=64'                 >> usercfg.txt
echo 'disable_overscan=1'         >> usercfg.txt

You are ready to remove the SD card.

cd
diskutil eject /dev/disk6

Booting and configuring Alpine

After inserting the SD card into the RPI you can boot it up. I am using a special converter that converts the mini HDMI to a normal HDMI converter that makes it easy to connect a TV or a monitor to the PI. I usually connect the device to the network with an ethernet cable and plug in a wired USB keyboard.

Once the device is booting up you can login with root (no password).

Alpine has a neat tool to configure a new system. It asks a few questions about keyboard layout and timezone, also makes you create a root password.

setup-alpine

Once setup-alpine is done you need to change a few things around because up to this moment you operated on the FAT partition. After updating the system and adding cfdisk you can create a new partition and use the remaining space on the SD card to have a proper system. In cfdisk, select “Free space” and the option “New”. It suggests using the entire available space, just press enter, then select the option “primary”, followed by “Write”. Type “yes” to write the partition table to disk, then select “Quit”.

apk update
apk upgrade
apk add cfdisk e2fsprogs
cfdisk /dev/mmcblk0

Once our new partition is ready you need to create a filesystem on it and install a basic Alpine system with setup-disk. In "sys" mode, it's an installer, it permanently installs Alpine on the disk. Ignore the errors, there might be some while executing setup-disk.

mkfs.ext4 /dev/mmcblk0p2
mount /dev/mmcblk0p2 /mnt
setup-disk -m sys /mnt
mount -o remount,rw /media/mmcblk0p1

This section is what I found on the Alpine wiki and it works. There might be an easier way.

rm -f /media/mmcblk0p1/boot/*
cd /mnt
rm boot/boot
mv boot/* /media/mmcblk0p1/boot/
rm -Rf boot
mkdir media/mmcblk0p1
ln -s media/mmcblk0p1/boot boot

There are only two steps left, adjusting fstab and cmdline.txt.

Fstab:

UUID=your-uui-id  /                 ext4  rw,relatime  0 0
/dev/mmcblk0p1    /media/mmcblk0p1  vfat  rw           0 0

Add the following content to etc/fstab (please note no starting /).

vi etc/fstab

Appending the following to the cmdline.txt:

root=/dev/mmcblk0p2

vi /media/mmcblk0p1/cmdline.txt

It looks like this for me:

cat /media/mmcblk0p1/cmdline.txt
modules=loop,squashfs,sd-mod,usb-storage quiet console=tty1 root=/dev/mmcblk0p2

I am not sure if lbu commit is necessary here. When Alpine Linux boots in diskless mode, initially it only loads a few required packages from the boot device by default. But local adjustments in RAM are possible, e.g. by installing a package or adjusting some configuration.

lbu commit -d

You can reboot and log in with root and verify everything is working. Going forward it is best to have a user other than root.

adduser l1x
addgroup l1x wheel

I usually add the following packages and start to use sudo going forward:

sudo apk add tmux fish ninja clang g++ sudo git python3 socat curl vim procps

Make sure that wheel group can use sudo:

%wheel ALL=(ALL) NOPASSWD: ALL

Changing my shell to fish:

l1x:x:1000:1000:Linux User,,,:/home/l1x:/usr/bin/fish

Hopefully, by now you have a working environment. I use a bigger drive for /data where I store all the development folders.

l1x@alpine ~> mount | column -t | egrep '^/dev'
/dev/mmcblk0p2  on  /                 type  ext4        (rw,relatime)
/dev/mmcblk0p1  on  /media/mmcblk0p1  type  vfat        (rw,relatime,fmask=0022,dmask=0022,codepage=437,...)
/dev/sda1       on  /data             type  xfs         (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,...)

Setting up Firecracker dev environment

Once you logged in via SSH to your Alpine system make sure you have the dev tools you are going to need. I usually use the following tools, and some more:

sudo apk add tmux git python3 curl vim

I was trying to figure out how to install Rust on ARM64 linux and the most straightforward way looks like:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

If you want to compile Firecracker yourself you also need Docker. Docker for this version of Alpine lives in the community repo. Simply append the community line to your repositories:

cat /etc/apk/repositories
#/media/mmcblk0p1/apks
http://your.nearest.mirror/mirrors/pub/alpine/v3.12/main
http://your.nearest.mirror/mirrors/pub/alpine/v3.12/community

Installing Docker:

sudo apk add docker
sudo addgroup $USER docker
sudo rc-update add docker boot
sudo service docker start

After Docker is running you can clone the Firecracker repo:

git clone git@github.com:firecracker-microvm/firecracker.git

Before you can compile a release you need to install two more packages:

sudo apk add bash ncurses

Now you can compile the Firecracker binaries:

./tools/devtool build --release --libc musl
[Firecracker devtool] About to pull docker image fcuvm/dev:v24
[Firecracker devtool] Continue? (y/n) y
Digest: sha256:12b8efe9a91d31349a6241b7d81c26d50bf913e369b5845a921be720e5de5796
Status: Downloaded newer image for fcuvm/dev:v24
docker.io/fcuvm/dev:v24
[Firecracker devtool] Starting build (release, musl) ...

There are few binaries generated:

ls build/cargo_target/aarch64-unknown-linux-musl/release/{firecracker,jailer}
 build/cargo_target/aarch64-unknown-linux-musl/release/firecracker*
 build/cargo_target/aarch64-unknown-linux-musl/release/jailer*
file build/cargo_target/aarch64-unknown-linux-musl/release/{firecracker,jailer}
build/cargo_target/aarch64-unknown-linux-musl/release/firecracker:
ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux),
statically linked, BuildID[sha1]=4da58d970ac0c51aad276309866f2b701cc397cd, with debug_info, not stripped
build/cargo_target/aarch64-unknown-linux-musl/release/jailer:
ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux),
statically linked, BuildID[sha1]=3e3c780b4e0fbd74b661c54f11192f9a15b89cba, with debug_info, not stripped

Using these binaries we can create the VMs.

Creating a microVM

Before getting started, there are multiple ways to start a microVM with Firecracker. Here are a few:

starting up the Firecracker binary and through the Unix socket configure it and then start a VM
starting Firecracker with a complete VM config without the Unix socket API
starting Firecracker with Jailer so it uses cgroups to containerize the VM

We are going to check out the first way.

When I started to fiddle with FC I was trying to use the official CLI (Firectl) and because it is written in Go you need to have a Go compiler if you would like to build it yourself. I did not like this option too much so I have created a new CLI called Pattacu written in Python.

Compiling a new kernel

This is optional. You can download the official kernel from Firecracker:

https://github.com/firecracker-microvm/firecracker/blob/master/docs/rootfs-and-kernel-setup.md

If you decided to compile a new Linux kernel there are few things you need to have.

kernel-source
tools to compile

I usually use one of the long term releases:

After extracting the kernel source to a folder you can grab the config I have prepared with some help from an OpenWrt developer:

wget https://raw.githubusercontent.com/l1x/pattacu/main/kernel-config/microvm-kernel-arm64.4.19.config -O .config

There are more tools required for building a new kernel:

sudo apk add bison clang make flex linux-headers openssl-dev perl

With these the kernel can be compiled:

make olddefconfig
time make Image.gz

This is going to take a while. After that, the kernel file we need for the microVM will be arch/arm64/boot/Image.

Creating a new rootfs

This is optional. You can download the official rootfs from Firecracker:

https://github.com/firecracker-microvm/firecracker/blob/master/docs/rootfs-and-kernel-setup.md

There is a project that can be used to create an Alpine rootfs. With a bit of additional shell scripting, we can create a customized rootfs that can boot up in Firecracker.

wget https://raw.githubusercontent.com/alpinelinux/alpine-make-rootfs/v0.5.1/alpine-make-rootfs -O alpine-make-rootfs \
  && echo 'a7159f17b01ad5a06419b83ea3ca9bbe7d3f8c03 alpine-make-rootfs' | sha1sum -c \
  || exit 1
chmod +x alpine-make-rootfs
sudo ./alpine-make-rootfs \
  --branch v3.12 \
  --packages 'openrc util-linux' \
  --timezone 'Europe/Budapest' \
  --script-chroot \
    rootfs-$(date +%Y%m%d).tar.gz - <<'SHELL'
    ln -s agetty /etc/init.d/agetty.ttyS0
    echo ttyS0 > /etc/securetty
    echo 'nameserver 1.1.1.1' > /etc/resolv.conf
    rc-update add agetty.ttyS0 default
    rc-update add devfs boot
    rc-update add procfs boot
    rc-update add sysfs boot
SHELL

dd if=/dev/zero of=alpine.ext4 bs=1 count=1 seek=256M
mkfs.ext4 alpine.ext4
sudo mkdir /tmp/alpine-rootfs
sudo mount alpine.ext4 /tmp/alpine-rootfs
sudo tar xzvf rootfs-$(date +%Y%m%d).tar.gz -C /tmp/alpine-rootfs
sudo umount /tmp/alpine-rootfs

Configuring host networking

If you would like to use networking with Firecracker the host network has to be configured to support this.

First loading the kernel driver, installing iproute2 (the ip command):

modprobe tun
sudo apk add iproute2 acl
sudo ip tuntap add tap0 mode tap

Second, configuring networking and forwarding:

sudo ip addr add 172.16.0.1/24 dev tap0
sudo ip link set tap0 up
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i tap0 -o eth0 -j ACCEPT

Enablig non-root access

I like to run Firecracker as a non-root user and it is easy to achieve:

sudo setfacl -m u:$USER:rw /dev/kvm
sudo setcap cap_net_bind_service=+ep /usr/bin/socat

This gives your user access to /dev/kvm and enabled socat bind to port 80 without root, using the new Linux kernel capabilities.

Booting up the microVM using Pattacu

For running Pattacu the only dependency is Python3 (I have not tested it with Python2).

sudo apk add python3
cd
python3 -m venv venv
# Depending on your shell
. ~/venv/bin/activate.fish
cd /where/you/store/repos
git clone git@github.com:l1x/pattacu.git
cd pattacu
pip install -r requirements.txt
./bin/pattacu -h
./bin/pattacu -h
usage: pattacu [-h] {describe-instance,put-boot-source,put-drives,put-machine-config,put-network-interfaces,put-actions} ...

positional arguments:
  {describe-instance,put-boot-source,put-drives,put-machine-config,put-network-interfaces,put-actions}

optional arguments:
  -h, --help            show this help message and exit
2020-12-13 20:35:01 INFO Quitting...

For starting up a microVM there are few things to be configured:

starting Firecracker
starting socat
configuring which kernel to boot up as the guest
configuring which rootfs to be used by the guest
configuring guest machine config
configuring guest networking

In this order:

Starting Firecracker

export socket_path=/data/fc/firecracker.socket
rm -f "$socket_path"
./firecracker --api-sock "$socket_path" --level Debug --log-path firecracker.log --show-log-origin --id fc-test

Starting socat

socat -v -v TCP-LISTEN:80,reuseaddr,fork UNIX-CLIENT:"$socket_path"

Configuring which kernel to boot up as the guest

./bin/pattacu put-boot-source \
    --boot-args "keep_bootcon console=ttyS0 reboot=k panic=1 pci=off ip=172.16.0.42::172.16.0.1:255.255.255.0::eth0:off" \
    --kernel-image-path /linux/arm64/kernel/4.14.210.image

2020-12-13 20:44:12 INFO ARGS: Namespace(boot_args='keep_bootcon console=ttyS0
reboot=k panic=1 pci=off ip=172.16.0.42::172.16.0.1:255.255.255.0::eth0:off', func='put-boot-source',
initrd_path=None, kernel_image_path='/linux/arm64/kernel/4.14.210.image')
2020-12-13 20:44:12 INFO {"boot_args": "keep_bootcon console=ttyS0 reboot=k
panic=1 pci=off ip=172.16.0.42::172.16.0.1:255.255.255.0::eth0:off",
"kernel_image_path": "/linux/arm64/kernel/4.14.210.image"}
2020-12-13 20:44:12 INFO HTTP Status: 204 HTTP Reason:  HTTP body: ""
2020-12-13 20:44:12 INFO Quitting...

Configuring which rootfs to be used by the guest

./bin/pattacu put-drives \
  --drive-id rootfs \
  --path /data/pattacu/rootfs/example-20201213.tar.gz \
  --read-only false \
  --root-device true
2020-12-13 20:46:30 INFO ARGS: Namespace(drive_id='rootfs',
func='put-drives', path='/data/pattacu/rootfs/example-20201213.tar.gz', read_only=False, root_device=True)
2020-12-13 20:46:30 INFO {"drive_id": "rootfs", "path_on_host":
"/data/pattacu/rootfs/example-20201213.tar.gz", "is_root_device": true, "is_read_only": false}
2020-12-13 20:46:30 INFO HTTP Status: 204 HTTP Reason:  HTTP body: ""
2020-12-13 20:46:30 INFO Quitting...

Configuring guest machine config

./bin/pattacu put-machine-config --mem-size-mib 128 --vcpu-count 2 --ht-enabled false

2020-12-13 20:47:58 INFO ARGS: Namespace(cpu_template=None, func='put-machine-config',
ht_enabled=False, mem_size_mib=128, track_dirty_pages=None, vcpu_count=2)
2020-12-13 20:47:58 INFO {"vcpu_count": 2, "mem_size_mib": 128, "ht_enabled": false}
2020-12-13 20:47:58 INFO HTTP Status: 204 HTTP Reason:  HTTP body: ""
2020-12-13 20:47:58 INFO Quitting...

Configuring guest networking

./bin/pattacu put-network-interfaces --iface-id eth0 --guest-mac "AA:FC:00:00:00:01" --host-dev-name tap0
2020-12-13 20:48:57 INFO ARGS: Namespace(func='put-network-interfaces',
guest_mac='AA:FC:00:00:00:01', host_dev_name='tap0', iface_id='eth0')
2020-12-13 20:48:57 INFO {"iface_id": "eth0",
"guest_mac": "AA:FC:00:00:00:01", "host_dev_name": "tap0"}
2020-12-13 20:48:58 INFO HTTP Status: 204 HTTP Reason:  HTTP body: ""
2020-12-13 20:48:58 INFO Quitting...

Starting up the instance

./bin/pattacu put-actions --action-type InstanceStart
2020-12-13 20:49:19 INFO ARGS: Namespace(action_type='InstanceStart', func='put-actions')
2020-12-13 20:49:19 INFO {"action_type": "InstanceStart"}
2020-12-13 20:49:20 INFO HTTP Status: 204 HTTP Reason:  HTTP body: ""
2020-12-13 20:49:20 INFO Quitting...

You can switch to the other tmux window and see the system booting up.

[    1.739745] random: fast init done                                                                                                                            [27/1844]
 [ ok ]
 * Mounting /sys ... [ ok ]
 * Mounting security filesystem ... [ ok ]
 * Mounting debug filesystem ... [ ok ]
 * Mounting SELinux filesystem ... [ ok ]
 * Mounting persistent storage (pstore) filesystem ... [ ok ]

Welcome to Alpine Linux 3.12
Kernel 4.20.0 on an aarch64 (ttyS0)

172 login: root
Welcome to Alpine!

The Alpine Wiki contains a large number of how-to guides and general
information about administrating Alpine systems.
See <http://wiki.alpinelinux.org/>.

You can set up the system with the command: setup-alpine

You may change this message by editing /etc/motd.

login[840]: root login on 'ttyS0'
172:~# ping hackernews.org
PING hackernews.org (162.255.119.249): 56 data bytes
64 bytes from 162.255.119.249: seq=0 ttl=42 time=180.868 ms

Closing

I think Firecracker has a great potential to be the next platform for containerization especially because of its lean nature. If we could create a reasonable service that hosts FC images that are easy to deploy it could replace Docker easily. I hope it takes off.

172:~# poweroff
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system poweroff
[  202.707132] reboot: Power down
[  202.707132] reboot: Power down

Getting started with Firecracker on Raspberry Pi

Istvan — Sun, 22 Nov 2020 20:20:58 +0000

This was originally was posted:

https://dev.l1x.be/posts/2020/11/22/getting-started-with-firecracker-on-raspberry-pi/

Abstract

Traditionally services were deployed on bare metal and in the last decades we have seen the rise of virtualisation (running additional operating systems in a operating system process) and lately containerisation (running an operating system process in a separate security context from the rest of processes on the same host). Virtualisation and containerisation offers different levels of isolation by moving some operating system functionality to the guest systems.

The following chart illustrates that pretty well:

Source: https://research.cs.wisc.edu/multifacet/papers/vee20_blending.pdf

In this article, I perform a deep dive into Firecracker and how it can be used for deploying services on Raspberry Pi (4B).

Getting started

There are few paths to take here. First I am going to try the easy one, using Ubuntu. Later on we can investigate the use of Alpine Linux which is much more lightweight than Ubuntu, ideal for devices like RPI.

Installing the image on a microSD card

We need a 64 bit Ubuntu image and a microsd card. For the imaging I use Balena Etcher that makes the imaging process super easy.

Getting the pre-installed image:

wget https://cdimage.ubuntu.com/releases/20.04/release/\
ubuntu-20.04.1-preinstalled-server-arm64+raspi.img.xz

Preinstalled means that we get a fully working operating system and there is no need for additional installation steps after booting up. With Balena Etcher it is super easy to write the compressed image file to the sd card and boot the system up once ready. SSHD starts up after the installation and we can log in via ssh if we know the IP address that the DHCP server issues to our device (assuming DHCP server is present in our LAN).

There are few mildly annoying things with Ubuntu (snaps, unattended-upgrades) that I usually remove. I also prefer to use Chrony over the systemd equivalent. Ansible repo for these is available here: https://github.com/l1x/rpi/blob/main/ubuntu.20/ansible/roles/os/tasks/main.yml

Installing Firecracker, Jailer and Firectl

Firecracker: The main component, it is a virtual machine monitor (VMM) that uses the Linux Kernel Virtual Machine (KVM) to create and run microVMs.
Jailer: For starting Firecracker in production mode, applies a cgroup/namespace isolation barrier and then drops privileges. There
Firectl: A command line utility for convenience

Getting Firecracker and Jailer

For the first two it is possible to download the release binaries from Github.

version='v0.23.0'

wget https://github.com/firecracker-microvm/firecracker/\
releases/download/${version}/firecracker-${version}-aarch64
wget https://github.com/firecracker-microvm/firecracker/\
releases/download/${version}/jailer-${version}-aarch64

mv firecracker-${version}-aarch64 firecracker
mv jailer-${version}-aarch64 jailer

chmod +x firecracker jailer

./firecracker --help
./jailer --help

Firectl

Firectl is a bit trickier to install because there is no release binary and it requires Golang 1.14 to compile. We can do these in two steps.

wget https://golang.org/dl/go1.14.12.linux-arm64.tar.gz
tar xzvf go1.14.12.linux-arm64.tar.gz

After getting go we can get the source of firectl and compile it:

git clone https://github.com/firecracker-microvm/firectl.git
cd firectl/
 ~/go/bin/go build -x

Testing Firectl:

./firectl --help

We have all the tools we need for running our first microVM the only thing is missing: something to run.

Downloading our first image

For a microVM there are two things necessary to have:

an uncompressed linux kernel (vmlinux)
a filesystem

Later on we are going to investigate how we could create our own version of these, but for now we are going to use images from

wget https://s3.amazonaws.com/spec.ccfc.min/\
img/aarch64/ubuntu_with_ssh/kernel/vmlinux.bin
wget https://s3.amazonaws.com/spec.ccfc.min/\
img/aarch64/ubuntu_with_ssh/fsfiles/xenial.rootfs.ext4

Configuring network

For the microVM to function properly we need a networking device. For this scenario we are going to use tap and create a device:

sudo ip tuntap add dev tap0 mode tap
sudo ip addr add 172.16.0.1/24 dev tap0
sudo ip link set tap0 up
ip addr show dev tap0

If we want to give access to our VM we have to enable IP forwarding:

DEVICE_NAME=eth0
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
sudo iptables -t nat -A POSTROUTING -o $DEVICE_NAME -j MASQUERADE
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i tap0 -o $DEVICE_NAME -j ACCEPT

Running our first microVM

This is how we can start up our first microVM. I usually start it in screen so I can open a new session easily because it will use the standard input and output for the newly started of console (unless you redirect it).

This is for debug mode, starting with sudo:

sudo ./firectl/firectl \
--firecracker-binary=./firecracker \
--kernel=vmlinux.bin \
--tap-device=tap0/aa:fc:00:00:00:01 \
--kernel-opts="console=ttyS0 reboot=k panic=1 pci=off ip=172.16.0.42::172.16.0.1:255.255.255.0::eth0:off" \
--root-drive=./xenial.rootfs.ext4

If everything went well you can see something like this:

Ubuntu 18.04.2 LTS fadfdd4af58a ttyS0

fadfdd4af58a login:

User and password is root:root.

Testing networking

For this we need to have a bit bigger image.

dd if=/dev/zero bs=1M count=800 >> xenial.rootfs.ext4
resize2fs -f xenial.rootfs.ext4

After starting up the usual way and logging in we need to fix few things:

Adding some working nameserver:

echo 'nameserver 1.1.1.1' >  /etc/resolv.conf

Now trying to update:

root@fadfdd4af58a:~# apt update
Get:1 http://ports.ubuntu.com/ubuntu-ports bionic InRelease [242 kB]
Get:2 http://ports.ubuntu.com/ubuntu-ports bionic-updates InRelease [88.7 kB]
Hit:3 http://ports.ubuntu.com/ubuntu-ports bionic-backports InRelease
Hit:4 http://ports.ubuntu.com/ubuntu-ports bionic-security InRelease
Get:5 http://ports.ubuntu.com/ubuntu-ports bionic/universe arm64 Packages [11.0 MB]
Get:6 http://ports.ubuntu.com/ubuntu-ports bionic/multiverse arm64 Packages [153 kB]
Get:7 http://ports.ubuntu.com/ubuntu-ports bionic/main arm64 Packages [1285 kB]
Get:8 http://ports.ubuntu.com/ubuntu-ports bionic/restricted arm64 Packages [572 B]
Get:9 http://ports.ubuntu.com/ubuntu-ports bionic-updates/universe arm64 Packages [1865 kB]
Get:10 http://ports.ubuntu.com/ubuntu-ports bionic-updates/restricted arm64 Packages [2262 B]
Get:11 http://ports.ubuntu.com/ubuntu-ports bionic-updates/main arm64 Packages [1431 kB]
Get:12 http://ports.ubuntu.com/ubuntu-ports bionic-updates/multiverse arm64 Packages [5758 B]
Fetched 16.1 MB in 6s (2543 kB/s)
Reading package lists... Error!
E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory)
E: Could not open file  - open (2: No such file or directory)
E: Problem opening
E: The package lists or status file could not be parsed or opened.

Fixing the apt issues:

mkdir -p /var/lib/dpkg/{info,alternatives}
touch /var/lib/dpkg/status
apt install apt-utils -y

Enjoy!

Next time we can go through how to compile a new kernel and have a different rootfs (potentially using Alpine).

Why I chose F# for our AWS Lambda project

Istvan — Fri, 08 May 2020 08:34:04 +0000

The dilemma

I wanted to create a simple Lambda function to be able to track how our users use the website and the web application without a 3rd party and a ton of external dependencies, especially avoiding 3rd party Javascript and leaking out data to mass surveillance companies. The easiest way is to use a simple tracking 1x1 pixel or beacon that collects just the right amount of information (strictly non-PII). This gives us enough information for creating basic funnels, that covers most of our needs.

First Option: Python

My default language (regardless of what I am going to work on) is Python. It has many great features and it is easy to prototype in it and the performance is great once you are using a C++ or Rust backed library. This also introduces a few issues when you are trying to deploy to AWS Lambda. I develop mainly on macOS and Lambda runs on Linux. Once you need to compile anything it is hard to get it right because Python does not support compiling to a different platform.

https://stackoverflow.com/questions/44490197/how-to-cross-compile-python-packages-with-pip

I was running into packaging issues because on Mac it is not easy to cross-compile and package Python code, maybe if I would create a proper package but I could not find a simple way without Docket. It would extremely valuable if Python had a way to compile a package that you upload to AWS and it works, 100%. I was running into problems that it was working on my Mac and did not work on AWS. I haven't had enough time to investigate.

Second Option: Rust

Rust became the rising star over the years and I try to use it as much as possible with mixed success. My biggest problem is with Rust the low-level nature and the quirky features, that are hard to reason about. From AWS Lambda examples:

use lambda::handler_fn;
use serde_json::Value;

type Error = Box<dyn std::error::Error + Send + Sync + 'static>;

#[tokio::main]
async fn main() -> Result<(), Error> {
    let func = handler_fn(func);
    lambda::run(func).await?;
    Ok(())
}

async fn func(event: Value) -> Result<Value, Error> {
    Ok(event)
}

Do you think that everybody understands immediately what is going on here? I don't. Even if I do, how am I going to explain this to a junior dev? How long does it take to get productive in Rust? I know that for extreme performance we might need this, but our current application is super happy without Rust, we do not have a performance problem. It is more important that developers are productive and the code is super simple to understand.

And the winner is: Fsharp

Member of the ML family, running on the .NET platform, pretty mature ecosystem. Developers can pick up quickly, especially the way we use it, simple functions will do with small types. The performance is great out of the box, in case you need more you have great tooling around it.

Our handler function:

  let handler(request:APIGatewayProxyRequest) =

    let httpResource =
      match isNull request.Resource with
      | true  -> "None"
      | _     -> request.Resource

    let httpMethod =
      match isNull request.HttpMethod with
      | true  -> "None"
      | _     -> request.HttpMethod

    let httpHeadersAccept =
      match isNull request.Headers with
      | true  -> "None"
      | _     -> getOrDefault request.Headers  "Accept" "None"

    let acceptImage =
      let pattern = @"image/"
      let m = Regex.Match(httpHeadersAccept, pattern)
      m.Success

    let log = String.Format("{0} :: {1} :: {2}", httpResource, httpMethod, httpHeadersAccept)
    LambdaLogger.Log(log)
    match (httpResource, httpMethod, httpHeadersAccept, acceptImage) with
    | ("/trck",         "POST", "application/json", _    ) -> trckPost(request)
    | ("/trck",         "GET",  _,                  true ) -> trckGet(request)
    | ("/trck/{image}", "GET",  _,                  true ) -> trckGet(request)
    | ("/echo",         "GET",  _,                  _    ) -> echoGet(request)
    | (_,               _,      _,                  _    ) -> notFound(request)

Pretty readable code, sure, you have to deal with nulls but Fsharp gives you great tooling around it. It took me probably a couple of days from having zero experience with .NET to deploy the first working API that has all of the functionality we are looking for. I might not have idiomatic Fsharp yet, but I am happy with the results so far. In the last couple of weeks, I have written many small tools in Fsharp, mostly dealing with the AWS APIs, I like it so much that I replaced my Python first approach and I go and try to implement everything in F# first. I can develop at the same pace as with Python but the result is much more solid code and easier on deployments (goodbye pip).

I think Fsharp is exactly in the sweet spot of programming languages, good enough performance, nice enough features, and a ton of great libraries. It does not have the problem that Python suffers, you can create a single zip that will work on all platforms. It also free from exposing the low-level details that I do not want to care about in business domain code, what Rust does.

Matching binary patterns

Istvan — Wed, 29 Apr 2020 18:56:01 +0000

In Erlang, it is easy to construct binaries and bitstrings and matching binary patterns. I was running into Mitchell Perilstein's excellent work on NTP with Erlang and I thought I am going to use this to explain how bitstrings and binaries work in Erlang.

Two concepts:

A bitstring is a sequence of zero or more bits, where the number of bits does not need to be divisible by 8.
A binary is when the number of bits is divisible by 8.

The syntax is as follows:

 <<B1, B2, ... Bn>>

Each element specifies a certain segment of the bitstring. A segment is a set of contiguous bits of the binary (not necessarily on a byte boundary).

A real-life example:

 << 0:2, 4:3, 3:3,  0:(3*8 + 3*32 + 4*64) >>.

Let's unpack a bit of what is going on here. For this, it is worth knowing the whole syntax.

<< Value:Size/TypeSpecifierList, Value:Size/TypeSpecifierList, ...>>

Or alternatively:

Ei = Value |
     Value:Size |
     Value/TypeSpecifierList |
     Value:Size/TypeSpecifierList

This means in the real-life example, we have 0 as the value, 2 is the size (2 bits), four as a value, 3 bits as size, and so on. We did not specify any of the type specifiers.

TypeSpecifierList is a list of type specifiers, in any order, separated by hyphens or dash (-). Default values are used for any omitted type specifier.

The following type specifiers are supported:

Type = integer | float | binary | bytes | bitstring | bits | utf8 | utf16 | utf32

The default is an integer. bytes is a shorthand for binary and bits is a shorthand for bitstring.

Signedness= signed | unsigned

It only matters for matching and when the type is an integer. The default is unsigned.

Endianness= big | little | native

Native-endian means that the endianness is resolved at load time to be either big-endian or little-endian, depending on what is native for the CPU that the Erlang machine is run on. Endianness only matters when the Type is either integer, utf16, utf32, or float. The default is big.

A complete example

One of the simplest protocols out there is NTP. The header file looks like the following:

This is used for both the request and the response. Let's craft the request first.

create_ntp_request() ->
  << 0:2, 4:3, 3:3,  0:(3*8 + 3*32 + 4*64) >>.

Based on the header structure we can see that we have a 2-bit integer (Li), 3-bit integer version number, 3-bit integer mode, 8-bit stratum, 8-bit poll, 8-bit precision, and so on. We only need to set the first 3 values, the rest (376 bits) can be 0.

Let's try this in the wild.

Creating the request

1> Request = << 0:2, 4:3, 3:3,  0:(3*8 + 3*32 + 4*64) >>.
<<35,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,...>>

Sending and receiving

We can use Erlang's built-in functions for this one, gen_udp has a pretty comprehensive low-level UDP implementation, that can do all we want.


% open a local socket, 0 indicates that it will pick a random local port
% active=false means we need to receive ourselves

2> {ok, Socket} = gen_udp:open(0, [binary, {active, false}]),
2> gen_udp:send(Socket, "0.europe.pool.ntp.org", 123, Request),
2> {ok, {_Address, _Port, Resp}} = gen_udp:recv(Socket, 0, 500).
{ok,{{212,59,0,1},
     123,
     <<36,2,0,231,0,0,0,110,0,0,0,25,212,59,3,3,226,84,62,89,
       208,192,202,156,...>>}}

Processing the response, first few bits

The response is just a binary that we need to slice and dice, similarly how we created the request.

3> Resp.
<<36,2,0,231,0,0,0,110,0,0,0,25,212,59,3,3,226,84,62,89,
  208,192,202,156,0,0,0,0,0,...>>

First, we can just get the first few bits.

4> << Li:2, Version:3, Mode:3, _rest/binary >> = Resp.
<<36,2,0,231,0,0,0,110,0,0,0,25,212,59,3,3,226,84,62,89,
  208,192,202,156,0,0,0,0,0,...>>
5> {li, Li, version, Version, mode, Mode}.
{li,0,version,4,mode,4}

It works.

The rest of the header a bit more tricky but with the bitstring syntax, it is easy to manage.

Processing the response, the rest

Finally matching all the mandatory fields.

6>   << LI:2, Version:3, Mode:3, Stratum:8, Poll:8/signed, Precision:8/signed,
6>      RootDel:32, RootDisp:32, R1:8, R2:8, R3:8, R4:8, RtsI:32, RtsF:32,
6>      OtsI:32, OtsF:32,   RcvI:32, RcvF:32, XmtI:32, XmtF:32 >> = Resp.
<<36,2,0,231,0,0,0,110,0,0,0,25,212,59,3,3,226,84,62,89,
  208,192,202,156,0,0,0,0,0,...>>

Making sense of these values requires a bit more legwork. First, we need a utility function for binary fractions.

In Erlang, function arity differentiates functions so we can do the following:

binfrac(Bin) ->
  binfrac(Bin, 2, 0).
binfrac(0, _, Frac) ->
  Frac;
binfrac(Bin, N, Frac) ->
  binfrac(Bin bsr 1, N*2, Frac + (Bin band 1)/N).

With this function, we can implement the one that processes the response and returns the values we are interested in.

% 2208988800 is the offset (1900 to Unix epoch)

process_ntp_response(Ntp_response) ->
  << LI:2, Version:3, Mode:3, Stratum:8, Poll:8/signed, Precision:8/signed,
     RootDel:32, RootDisp:32, R1:8, R2:8, R3:8, R4:8, RtsI:32, RtsF:32,
     OtsI:32, OtsF:32,   RcvI:32, RcvF:32, XmtI:32, XmtF:32 >> = Ntp_response,
  {NowMS, NowS, NowUS} = erlang:timestamp(),
  NowTimestamp = NowMS * 1.0e6 + NowS + NowUS/1000,
  TransmitTimestamp = XmtI - 2208988800 + binfrac(XmtF),
  { {li, LI}, {vn, Version}, {mode, Mode}, {stratum, Stratum}, {poll, Poll}, {precision, Precision},
    {rootDelay, RootDel}, {rootDispersion, RootDisp}, {referenceId, R1, R2, R3, R4},
    {referenceTimestamp, RtsI - 2208988800 + binfrac(RtsF)},
    {originateTimestamp, OtsI - 2208988800 + binfrac(OtsF)},
    {receiveTimestamp,   RcvI - 2208988800 + binfrac(RcvF)},
    {transmitTimestamp,  TransmitTimestamp},
    {clientReceiveTimestamp, NowTimestamp},
    {offset, TransmitTimestamp - NowTimestamp} }.

And wit that we can just process the response.

{{li,0},
 {vn,4},
 {mode,4},
 {stratum,2},
 {poll,3},
 {precision,-24},
 {rootDelay,9},
 {rootDispersion,140},
 {referenceId,85,158,25,75},
 {referenceTimestamp,1588186010.7517557},
 {originateTimestamp,-2208988800},
 {receiveTimestamp,1588186048.3557627},
 {transmitTimestamp,1588186048.8841336},
 {clientReceiveTimestamp,1588186606.531},
 {offset,-557.6468663215637}}

Please note, this is the first step in the NTP workflow and does not implement the complete NTP protocol. We do not take into consideration a bunch of details.

Next time we might look into how to implement a simple server (like DNS) in Erlang.

Michael's original work:

https://github.com/mnp/erlang-ntp

Up to date version and Elixir port:

https://gist.github.com/l1x/b0a7f844b283ac08e3125d1ba6e81eeb

FreeNAS 11.3 upgrade issues

Istvan — Wed, 29 Apr 2020 13:41:02 +0000

I have an interesting experience with the latest upgrade of FreeNAS 11.3-U2.1. Applications that were deployed in the jail were gone. After fiddling with iocage (the tool that FreeNAS provides to manage jails) I could restore a previous state where all seems fine and dandy.

Steps to restore

list of snapshots

iocage snaplist tr -l
+-------------------------------------------------------------------------+-----------------------+-------+-------+
|                                  NAME                                   |        CREATED        | RSIZE | USED  |
+=========================================================================+=======================+=======+=======+
| fux/iocage/jails/tr/root@ioc_plugin_update_2020-04-29                   | Wed Apr 29 14:55 2020 | 799G  | 11.6K |
+-------------------------------------------------------------------------+-----------------------+-------+-------+
| fux/iocage/jails/tr/root@ioc_update_11.3-RELEASE-p8_2020-04-29_14-55-07 | Wed Apr 29 14:55 2020 | 799G  | 575K  |
+-------------------------------------------------------------------------+-----------------------+-------+-------+
| fux/iocage/jails/tr/root@ioc_update_11.3-RELEASE-p8_2020-04-29_14-55-22 | Wed Apr 29 14:55 2020 | 799G  | 11.6K |
+-------------------------------------------------------------------------+-----------------------+-------+-------+
| fux/iocage/jails/tr@ioc_plugin_update_2020-04-29                        | Wed Apr 29 14:55 2020 | 517K  | 81.4K |
+-------------------------------------------------------------------------+-----------------------+-------+-------+
| fux/iocage/jails/tr@ioc_update_11.3-RELEASE-p8_2020-04-29_14-55-07      | Wed Apr 29 14:55 2020 | 517K  | 81.4K |
+-------------------------------------------------------------------------+-----------------------+-------+-------+
| fux/iocage/jails/tr@ioc_update_11.3-RELEASE-p8_2020-04-29_14-55-22      | Wed Apr 29 14:55 2020 | 517K  | 81.4K |
+-------------------------------------------------------------------------+-----------------------+-------+-------+

stop the jail

root@freenas[~]# iocage stop tr
* Stopping tr
  + Executing prestop OK
  + Stopping services OK
  + Tearing down VNET OK
  + Removing devfs_ruleset: 5 OK
  + Removing jail process OK
  + Executing poststop OK

rollback

root@freenas[~]# iocage rollback tr -n ioc_update_11.3-RELEASE-p8_2020-04-29_14-55-07

This will destroy ALL data created including ALL snapshots taken after the snapshot ioc_update_11.3-RELEASE-p8_2020-04-29_14-55-07

Are you sure? [y/N]: y
Rolled back to: fux/iocage/jails/tr

start the jail

root@freenas[~]# iocage start tr
No default gateway found for ipv6.
* Starting tr
  + Started OK
  + Using devfs_ruleset: 5
  + Configuring VNET OK
  + Using IP options: vnet
  + Starting services OK
  + Executing poststart OK
  + DHCP Address: 192.168.1.111/24

And we are back.

My Python environment

Istvan — Tue, 11 Feb 2020 07:26:04 +0000

Virtualenv for the win

After trying to use so many things for this, including conda, Linux in a VM + operating system packages, pyenv and everything else that is out there, for years, I finally settled on venv, requirements.txt and a single virtualenv on my laptop.

Why?

If you have tried to use some of these you might have run into some issues. Conda for example is absolutely nondeterministic, works some times and fails most of the time. I created a ticket about it but the response is to try to turn it off and on again. These developers really like It Crowd.

After wrestling with many of similar issues, finally I decided to go for dead simple approach.

I install Python3 with brew. Create a venv in my home folder and source it.

brew install python3
cd
python3 -m venv venv
. ~/venv/bin/activate.fish

Any time I work with a Python project I only use Python3 (RIP Python2 projects) and install all the packages into that single virtual environment. If there is a conflict I delete the entire directory and install the dependencies of the current project. I usually work on one Python project at a time. This gives me exactly what I need with an easy path to resolve local state issues, dependency problems and only using 1 directory instead of littering around all of my repositories and making backup slower. In production I do the same, I use venv to install the environment and install dependencies there. It does not matter if I use a Docker container or a non-containerized deployment the venv is specific to a single application. This gives my the best of both worlds, developer happiness and optimal environment in production. There are minor problems with this, Python development of AWS Lambda functions is not as easy because the architecture differences between Mac vs AWS Linux. This problem exists in Python which virtual environments have nothing to do with. In that case I usually package up software in a VM + Docker or use something else than Python, something that truly supports multi-platform development: Rust or F# for example.

Small Alpine Linux containers with Java

Istvan — Wed, 24 Apr 2019 20:14:48 +0000

Update

2019.10.21

The original post was about Java 13. Oracle is changing JDK versions quite frequently. The newest version of JDK is 14:

https://download.java.net/java/early_access/alpine/15/binaries/openjdk-14-ea+15_linux-x64-musl_bin.tar.gz

Intro

Quite often I hear a complaint from developers that Java containers are too big and how much smaller this would be with Go or other languages. With this new project called Portola it is possible to make very small (~40MB) containers running Java applications. Alpine Linux became the de facto standard for small containers but until now it was a rather complex process to create a Java environment using it. This is not anymore the case. Let's see how we can leverage Project Portola to create these small containers.

Creating Containers

First, we just create a container that has a new small size JDK.

FROM alpine:latest as build

ADD https://download.java.net/java/early_access/alpine/15/binaries/openjdk-14-ea+15_linux-x64-musl_bin.tar.gz /opt/jdk/
RUN tar -xzvf /opt/jdk/openjdk-14-ea+15_linux-x64-musl_bin.tar.gz -C /opt/jdk/

RUN ["/opt/jdk/jdk-14/bin/jlink", "--compress=2", \
     "--module-path", "/opt/jdk/jdk-14/jmods/", \
     "--add-modules", "java.base", \
     "--output", "/jlinked"]

FROM alpine:latest
COPY --from=build /jlinked /opt/jdk/
CMD ["/opt/jdk/bin/java", "--version"]

The rest of the article is not concerned with JDK version. Output from docker build might reflect earlier version.

We can start to build the container:

[v@alpine-java jdk14_v]$ sudo docker build .
Sending build context to Docker daemon   2.56kB
Step 1/8 : FROM alpine:latest as build
latest: Pulling from library/alpine
bdf0201b3a05: Pull complete
Digest: sha256:28ef97b8686a0b5399129e9b763d5b7e5ff03576aa5580d6f4182a49c5fe1913
Status: Downloaded newer image for alpine:latest
 ---> cdf98d1859c1
Step 2/8 : ADD https://download.java.net/java/early_access/alpine/16/binaries/openjdk-13-ea+16_linux-x64-musl_bin.tar.gz /opt/jdk/
Downloading [==================================================>]  195.2MB/195.2MB
 ---> Using cache
 ---> b1a444e9dde9
Step 3/7 : RUN tar -xzvf /opt/jdk/openjdk-13-ea+16_linux-x64-musl_bin.tar.gz -C /opt/jdk/
 ---> Using cache
 ---> ce2721c75ea0
Step 4/7 : RUN ["/opt/jdk/jdk-13/bin/jlink", "--compress=2",      "--module-path", "/opt/jdk/jdk-13/jmods/",      "--add-modules", "java.base",      "--output", "/jlinked"]
 ---> Using cache
 ---> d7b2793ed509
Step 5/7 : FROM alpine:latest
 ---> cdf98d1859c1
Step 6/7 : COPY --from=build /jlinked /opt/jdk/
 ---> Using cache
 ---> 993fb106f2c2
Step 7/7 : CMD ["/opt/jdk/bin/java", "--version"] - to check JDK version
 ---> Running in 8e1658f5f84d
Removing intermediate container 8e1658f5f84d
 ---> 350dd3a72a7d
Successfully built 350dd3a72a7d

Even though the JDK image is 195MB the build is only 41MB. We can tag the image.

[v@alpine-java jdk13_v]$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
<none>              <none>              350dd3a72a7d        21 seconds ago      41.7MB
<none>              <none>              d7b2793ed509        25 minutes ago      565MB
alpine              latest              cdf98d1859c1        2 weeks ago         5.53MB
[v@alpine-java jdk13_v]$ sudo docker tag 350dd3a72a7d jdk-13-musl/jdk-version:v1
[v@alpine-java jdk13_v]$ sudo docker images
REPOSITORY                TAG                 IMAGE ID            CREATED              SIZE
jdk-13-musl/jdk-version   v1                  350dd3a72a7d        About a minute ago   41.7MB
<none>                    <none>              d7b2793ed509        27 minutes ago       565MB
alpine                    latest              cdf98d1859c1        2 weeks ago          5.53MB

Running the container:

[v@alpine-java jdk13_v]$ sudo docker run jdk-13-musl/jdk-version:v1
openjdk 13-ea 2019-09-17
OpenJDK Runtime Environment (build 13-ea+16)
OpenJDK 64-Bit Server VM (build 13-ea+16, mixed mode)

Building a HelloWorld application

Now we have a base container that we can use to create one with a Java app. Lets use a simple HelloWorld.java.

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello, World");
  }
}

Compile the Java code:

javac HelloWorld.java

Having another Dockerfile for the app container:

FROM jdk-13-musl/jdk-version:v1
ADD HelloWorld.class /
CMD ["/opt/jdk/bin/java", "HelloWorld"]

Building container:

sudo docker build .

After tagging we can run HelloWorld:

sudo docker run jdk-13-musl/hello-world:v1
Hello, World

The entire docker run takes around 600ms. Not bad for Java.