hastur is a tool for launching systemd-nspawn containers without the need for manual configuration.

It will setup networking, a base root FS and even an overlay FS for containers automatically.

The primary usecase for hastur is supporting testcases for distributed systems and running a local set of trusted containers.

systemd-nspawn is useful tool, which can create and run lightweight containers without any additional software, because it's available out-of-the-box systemd.

However, it requires some configuration to run a working container, such as managing the network configuration, and downloading and extracting packages.

hastur offers all this configuration automatically, which makes it possible to run fully-configured systemd-nspawn containers in seconds.

hastur is available for Arch Linux (for now, only) through the AUR:

https://aur4.archlinux.org/packages/hastur/

hastur is also go-gettable:

go get github.com/seletskiy/hastur

The most simple usage is testing hastur out-of-the-box: you can tell it to create an ephemeral container with a basic set of packages:

sudo hastur -S

After invoking that command, you will end up in Cthulhu's void in the bash shell.

This test container will be deleted after you exit its shell.

Passing the -k flag will tell hastur to keep the container after exit:

sudo hastur -kS

If you don't like the fantastical autogenerated names, you can pass the flag -n:

sudo hastur -Sn my-cool-name

Note that ephemeral containers are only the ones that both have autogenerated names and were not started with the -k flag.

hastur will take care of setting up the networking by creating a bridge and setting up a shared network. By default, hastur will automatically generate IP addresses, and you can see a container's address either in its starting message or by running the query command:

sudo hastur -Q

You can specify your own IP address by passing the -a flag, like this:

sudo hastur -S -a 10.0.0.2/8

hastur uses package-based container configurations and will happily populate your container with the packages that you want. You can use the -p flag for this:

sudo hastur -S -p nginx

That will create a container with the nginx package pre-installed. In actuality, hastur uses overlays to keep base dirs separate from container data. The base dirs, or, if you like, images, are just prepared root filesystems, which have pre-installed packages. You can query the cached base dirs by running hastur with the -Qi flag:

sudo hastur -Qi

In fact, from hastur's standpoint, a container is just a data dir, which gets overlayed on top of a root filesystem and then given network capability, so it will not remember what IP address a container has or what set of packages it has installed if you forget to specify the correct options.

For example:

sudo hastur -Sn test -p git -- /bin/git --version

Will output:

git version 2.5.3

But running this container the next time without -p git will tell you that git is not installed:

sudo hastur -Sn test -- /bin/git --version

This outputs:

No such file or directory

However, this test container will have a separate FS and all data files will persist across the two runs.

hastur can operate over several root directories and keep container instances separately from each other. The -r flag is used for this:

sudo hastur -r solar-system -Sn earth
sudo hastur -r solar-system -Sn moon
sudo hastur -r alpha-centauri -Sn a
sudo hastur -r alpha-centauri -Sn b
sudo hastur -r alpha-centauri -Sn c

The output will be different for these two commands:

sudo hastur -r solar-system -Q
sudo hastur -r alpha-centauri -Q

The first one will list only the earth and moon containers, and the second will only list the a, b and c containers.

MIT.