secluded/content/posts/crash-course-to-lxd.md

title	subtitle	date	categories	tags	draft	toc	rss_only	cover
Crash Course to LXD	Quick instructions for installing LXD and setting up your first application.	2023-09-19T14:27:00-04:00	Technology	Sysadmin Containers VMs Docker LXD	false	true	false	./cover.png

If you're wondering why I like system containers, see the previous post, [LXD: Containers for Human Beings.][lxd]

[lxd]: {{< ref "lxd-containers-for-human-beings" >}}

Installation

{{< adm type="note" >}}

Note: the instructions below say to install LXD using Snap. I personally dislike Snap, but LXD is a Canonical product and they're doing their best to promote it as much as possible. Incus is a fork of LXD by the primary creators and maintainers and one of the first things they did was rip out Snap support, so it will eventually be installable as a proper native package.

{{< /adm >}}

1. Install snap following Canonical's tutorial
   • LXD is natively packaged for Arch and Alpine, but configuration can be a massive headache.
2. sudo snap install lxd
3. lxd init
   • Defaults are fine for the most part; you may want to increase the size of the storage pool.
4. lxc launch images:debian/12 container-name
5. lxc shell container-name

Usage

As an example of how to use LXD in a real situation, we'll set up my URL shortener. You'll need a VPS with LXD installed and a (sub)domain pointed to the VPS.

Run lxc launch images:debian/12 earl followed by lxc shell earl and apt install curl. Also apt install a text editor, like vim or nano depending on what you're comfortable with. Head to the Installation section of earl's SourceHut page and expand the List of latest binaries. Copy the link to the binary appropriate for your platform, head back to your terminal, type curl -LO, and paste the link you copied. This will download the binary to your system. Run mv <filename> earl to rename it, chmod +x earl to make it executable, then ./earl to execute it. It will create a file called config.yaml that you need to edit before proceeding. Change the accessToken to something else and replace the listen value, 127.0.0.1, with 0.0.0.0. This exposes the application to the host system so we can reverse proxy it.

The next step is daemonising it so it runs as soon as the system boots. Edit the file located at /etc/systemd/system/earl.service and paste the following code snippet into it.

[Unit]
Description=personal link shortener
After=network.target

[Service]
User=root
Group=root
WorkingDirectory=/root/
ExecStart=/root/earl -c config.yaml

[Install]
WantedBy=multi-user.target

Save, then run systemctl daemon-reload followed by systemctl enable --now earl. You should be able to curl localhost:8275 and see some HTML.

Now we need a reverse proxy on the host. Exit the container with exit or Ctrl+D, and if you have a preferred webserver, install it. If you don't have a preferred webserver yet, I recommend installing Caddy. All that's left is running lxc list, making note of the earl container's IPv4 address, and reverse proxying it. If you're using Caddy, edit /etc/caddy/Caddyfile and replace everything that's there with the following.

<(sub)domain> {
	encode zstd gzip
	reverse_proxy <container IP address>:1313
}

Run systemctl restart caddy and head to whatever domain or subdomain you entered. You should see the home page with just the text earl on it. If you go to /login, you'll be able to enter whatever access token you set earlier and log in.

Further tips

One of the things you might want to do post-installation is mess around with profiles. There's a default profile in LXD that you can show with lxc profile show default.

$ lxc profile show default
config: {}
description: Default LXD profile
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: default
used_by: []

Not all config options are listed here though; you'll need to read the documentation for a full enumeration.

I've seen some people say that executing a fork bomb from inside a container is equivalent to executing it on the host. The fork bomb will blow up the whole system and render every application and container you're running inoperable. That's partially true because LXD by default doesn't put a limit on how many processes a particular container can spawn. You can limit that number yourself by running

lxc profile set default limits.processes <num-processes>

Any container you create under the default profile will have a total process limit of <num-processes>. I can't tell you what a good process limit is though; you'll need to do some testing and experimentation on your own.

As stated in [the containers section][pp] of the previous post, this doesn't save you from fork bombs. It just helps prevent a fork bomb from affecting the host OS or other containers.

[pp]: {{< ref "lxd-containers-for-human-beings#containers" >}}