After numerous issues over the past few months with Docker, I decided to look into other options for crash-and-burn environments, and for “software as a function” invocations.
I was pleasantly surprised to see that systemd and Arch Linux provide everything that I need already.
# Install pacstrap sudo pacman -S arch-install-scripts # Create subvolume for container (you could just use a normal directory instead) sudo btrfs subvol create /opt/gcc295 # Install the base system and a few other packages sudo pacstrap -icd /opt/gcc295 base wget curl vim ed make git patch bash perl --ignore linux # Enable and start networking echo 'nameserver 8.8.4.4' | sudo tee /opt/gcc295/etc/resolv.conf sudo systemctl enable systemd-networkd sudo systemctl start systemd-networkd # Set the root password for the container sudo passwd -R /opt/gcc295 # Boot into the container for the first time, log in as root sudo systemd-nspawn -bnD /opt/gcc295 # Start networking in the container systemctl start systemd-networkd # Do what you need to within the container to prepare it for its intended purpose wget ... tar xaf ... cd ... ./configure ... make ... make install ... # Ctrl+] three times to stop and exit the container # Fork the container to test some idea or develop another container based on this one sudo systemd-nspawn -bnD /opt/gcc3 --template =/opt/gcc295 # Do what you need to within that container in order to prepare it for usage, then ^]^]^] as before to exit the container # Run a container using a temporary snapshot, so any changes to the container state are not preserved (i.e. changes are deleted/destroyed/lost). sudo systemd-nspawn -bnxD /opt/gcc3 # Optionally, create read-only BTRFS snapshots of prepared containers, then use those snapshots, to ensure that you don't modify them accidentally. btrfs subvol snapshot -r ... # You can pass the --read-only option to systemd-nspawn, to force the root file-system to be read-only, if you know that your container shouldn't need to modify it at all. This may be faster, but contained software which stores/mutates state information in the file system will fail. sudo systemd-nspawn -bnD --read-only /opt/gcc3 # Execute a program from a container, with arguments, and with a host path (~/arm-kernel-2.6) bound into the container (at /kernel) sudo systemd-nspawn -xanD /opt/gcc3 --bind=~/arm-kernel-2.6:/kernel make -C /kernel # Wrapped in a script for ease of use. Uses -q switch to suppress output from nspawn. #!/bin/bash set -e sudo systemd-nspawn -qxanD /opt/gcc295 --bind="${src}":/src make -C /src "$@"
I use BTRFS subvolumes for containers, to allow easy version-control of them. You could just install to a normal folder though, subvolumes/BTRFS aren’t required.
Use pacstrap to install the base system and any extra packages that you might want.
To fork the container (as in Git, not the POSIX variety), use the –template argument to systemd-nspawn. This works best if the container folder is a BTRFS subvolume, as BTRFS’ COW snapshot mechanism will be used for forking.
To launch a temporary container based on your template, use the -x option to systemd-nspawn. This works best if the container folder is a BTRFS subvolume, for the same reason as for forking.
Of course, if you do use BTRFS subvolumes, then you can make backups and incremental patches for container development using btrfs send/receive. For complete backups, you can also use TAR or CPIO regardless of whether you’re using BTRFS subvolumes or not.