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.