Amolith
/
secluded
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
secluded/content/posts/lxd-containers-for-human-be...

4.4 KiB
Raw Blame History

title subtitle date categories tags draft rss_only cover
LXD: Containers for Human Beings Docker's great and all, but I prefer the workflow of interacting with VMs 2023-08-11T16:30:00-04:00
Technology
Sysadmin
Containers
VMs
Docker
LXD
true false ./cover.png

This is a blog post version of a talk I presented at both Ubuntu Summit 2022 and SouthEast LinuxFest 2023. The first was not recorded, but the second was and is on SELF's PeerTube instance. I apologise for the terrible audio, but there's unfortunately nothing I can do about that.

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

Note: Canonical has decided to pull LXD out from under the Linux Containers entity and instead continue development under the Canonical brand. The majority of the LXD creators and developers have congregated around Incus. I'll be keeping a close eye on the project and intend to migrate as soon as there's an installable release.

{{< /adm >}}

The benefits of VMs and containers

  • Isolation: we don't want an attacker to get into our webserver and be able to gain access to our email server
  • Flexibility: VMs and containers only use the resources they've been given. If you tell the VM it has 200 MBs of RAM, it's going to make do with 200 MBs of RAM and the kernel's OOM killer is going to have a fun time 🤠
  • Portability: once set up and configured, VMs and containers can mostly be treated as black boxes; as long as the surrounding environment is similar to the previous in terms of communication, they can just be picked up and dropped to various machines and hosts as necessary.
  • Density: applications are usually much lighter than the systems they're running on, so it makes sense to run many applications on one system. VMs and containers facilitate that without sacrificing security.
  • Cleanliness: VMs and containers are black boxes. When you're done with it, you can just throw the box in the trash (delete it) and everything related to that application is gone.

Virtual machines

title: |md
  # Virtual machines
| { near: top-center }

direction: up

k1: Guest kernel
k2: Guest kernel
k3: Guest kernel
os1: Guest OS
os2: Guest OS
os3: Guest OS
app1: Many apps
app2: Many apps
app3: Many apps

Host kernel -> Hypervisor
Hypervisor -> k1 -> os1 -> app1
Hypervisor -> k2 -> os2 -> app2
Hypervisor -> k3 -> os3 -> app3

Containers

title: |md
  # Application containers
| { near: top-center }

direction: up

app1: App
app2: App
app3: App

Host kernel -> Hypervisor
Hypervisor -> app1
Hypervisor -> app2
Hypervisor -> app3

title: |md
  # System containers
| { near: top-center }

direction: up

os1: Guest OS
os2: Guest OS
os3: Guest OS
app1: Many apps
app2: Many apps
app3: Many apps

Host kernel -> os1 -> app1
Host kernel -> os2 -> app2
Host kernel -> os3 -> app3

When to use which

Virtual machines

  • Virtualising esoteric hardware
  • Virtualising non-Linux operating systems (Windows, macOS)
  • Completely isolating processes from one another with a decades-old, battle-tested technique

{{< adm type="note" >}} See Drew DeVault's blog post In praise of qemu for a great use of VMs {{< /adm >}}

Application containers

  • Microservices
  • Extremely reproducible builds
    • (NixOS.org would likely be a better fit though)
  • Dead-set on using cloud platforms with extreme scaling capabilities (AWS, GCP, etc.)
  • When the app you want to run is only distributed as a Docker container and the maintainers adamantly refuse to support any other deployment method
    • (Docker does run in LXD 😉)

System containers

  • Anything not listed above 👍

Crash course to LXD

  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
  4. lxc image copy images:debian/11 local: --alias deb-11
  5. lxc launch deb-11 container-name
  6. lxc shell container-name