lxc-ramdisk

Create ramdisks for use in LXC containers for instant startup and destroy. Running mkvm.sh bullseye lsblk (for testing purposes) takes 1.3s on RAM running at 800MHz.

The scripts create two different ramdisks when running ramdisk.sh start (or when the systemd service is started):

• /ramdisk/sys/ for the base images of supported operating systems
• /ramdisk/tmp/ for rootfs of the actual containers

When a container is started, it's rootfs is an overlay of /ramdisk/tmp/VM_NAME (read-write) over /ramdisk/sys/VM_TYPE (read-only). This setup allows to start many containers with the same base system without copying it over and over again.

The contents of /ramdisk/sys are copied from /ramdisk/persist when the service is started.

The following systems are supported:

• bullseye: Debian 11 Bullseye
• archlinux: Archlinux
• gitlab-runner: based on Archlinux

Setup

The provided files are provided for Debian bullseye. They can be adpated to another system easily... mostly the LXC templates should be different in the lxc.include line. The size of the ramdisk is also hardcoded to 32GB for the base systems, and 32GB for the temporary systems. This can be adapted by editing bin/ramdisk.sh.

Network setup

Your containers may need to access the network. To give them access to your entire network, we recommend to create a bridged interface to your physical interface, then use a 'veth' interface in the LXC containers. Your /etc/network/interfaces would look like this :

auto lxcbr0
iface lxcbr0 inet dhcp
	bridge_ports eno1
	bridge_fd 1
	bridge_maxwait 0

This operation is not performed automatically by setup.sh because it has implications in regards to your current network configuration and to the devices exposed on your LAN. You should think it through.

Main setup

Run setup.sh to setup everything else:

• ensuring LXC is setup via APT
• symlinking bin/*.sh to /usr/sbin/
• symlinking ramdisk.service to /etc/systemd/system
• symlinking templates/*.template to /var/lib/lxc/

Setup other systems

By default, the setup.sh script will generate an image for your own system. If you'd like to generate an image for another system, you'll likely need to have that system running.

To create an Archlinux rootfs to later run on Debian, you'll have to supply your own Archlinux rootfs in the /ramdisk/persist/archlinux folder. Such rootfs can be created from an Archlinux system using:

mkdir /ramdisk/persist/archlinux
pacstrap /ramdisk/persist/archlinux base base-devel

To create a Debian rootfs to later run on Archlinux, you'll have to supply your own rootfs in the /ramdisk/persist/bullseye folder. Such rootfs can be created from a Debian system using:

mkdir /ramdisk/persist/bullseye
deboostrap bullseye /ramdisk/persist/bullseye http://deb.debian.org/debian

Usage

The mkvm.sh script takes the type of container to run as first argument. That type must be supported by a template (currently, archlinux and bullseye). If another argument is provided, it's the command run in the container, after which the container is stopped. Otherwise, the container is stopped when the container shell is exited.

Unless the --keep argument is passed, the container is also destroyed after running.

Edit the template filesystem

If you need to change a template's rootfs, for running updates or adding packages, you can use the editvm.sh script:

editvm.sh archlinux bash

This will fail if the ramdisk service is still running, so first stop all your containers, stop the ramdisk service, and try again. Don't forget to restart the ramdisk service after you're done.

If the LXC you want to use does not use a rootfs with its own name in the /ramdisk/persist/ folder, the script will also error out.

Run a gitlab-runner for CI

Once you have the archlinux rootfs configured, you can use the gitlab-runner template for running a CI/CD runner. It is strongly recommended to only use it for CI and not CD, or to run it only on approved input, as the LXC configuration disables many security features. If you use it to run arbitrary code from random users, kittens may fall from the sky.

A helper script gitlab-runner.sh is provided, to which you must give a gitlab-runner/config.toml as first argument. For example:

gitlab-runner.sh /root/ci.toml

This will bootstrap a container with gitlab-runner with the provided config file. If you'd like it to run on boot, create a systemd service for that purpose. We may provide a service for that in the future.

Note that the config file needs to be bootstrapped first in order for that to work. You can bootstrap it with an archlinux container, like this:

mkvm.sh archlinux bash
while ! ping -c 1 google.com; do
	echo "Waiting for network..."
done
pacman -Sy
pacman -S gitlab-runner
gitlab-runner register
# Answer the questions, selecting "docker" as runner backend
cat /etc/gitlab-runner/config.toml
# Copy this file to the host

License

GNU aGPL v3