From 47bc405d8a3da57b2d6770630a9bfa07ac20b0a1 Mon Sep 17 00:00:00 2001 From: Amolith Date: Sun, 17 Sep 2023 18:04:50 -0400 Subject: [PATCH] progress on LXD post --- .../posts/lxd-containers-for-human-beings.md | 27 +++++++++++++++---- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/content/posts/lxd-containers-for-human-beings.md b/content/posts/lxd-containers-for-human-beings.md index 5c7cbb0..504d5c5 100644 --- a/content/posts/lxd-containers-for-human-beings.md +++ b/content/posts/lxd-containers-for-human-beings.md @@ -1,7 +1,7 @@ --- title: "LXD: Containers for Human Beings" subtitle: "Docker's great and all, but I prefer the workflow of interacting with VMs" -date: 2023-08-11T16:30:00-04:00 +date: 2023-09-17T18:04:00-04:00 categories: - Technology tags: @@ -186,8 +186,8 @@ The database and webserver might go in _that same_ container. [rocky]: https://rockylinux.org/ You treat each container more like you would a VM, but you get the performance -benefit of _not_ virtualising everything. Containers are _much_ lighter than any -virtual machine. +benefit of _not_ virtualising everything. Containers tend to be _much_ lighter +than most VMs.[^1] ```kroki {type=d2,d2theme=flagship-terrastruct,d2sketch=true} hk: Host kernel @@ -242,7 +242,7 @@ Application containers also tend to be necessary when the application you want to self-host is _only_ distributed as a Docker image and the maintainers adamantly refuse to support any other deployment method. This is a _massive_ pet peeve of mine; yes, Docker can make running self-hosted applications easier for -inexperienced individuals,[^1] but application orchestration system _does not_ +inexperienced individuals,[^2] but application orchestration system _does not_ fit in every single environment. By refusing to provide proper "manual" deployment instructions, maintainers of these projects alienate an entire class of potential users and it pisses me off. @@ -257,7 +257,18 @@ interact with it in a similar way to VMs or even your PC; you shell into it, `apt install` whatever you need, set up the application, expose it over the network (for example, on `0.0.0.0:8080`), proxy it on the container host, and that's it! This process can be trivially automated with shell scripts, Ansible -roles, Chef, Puppet, whatever you like. +roles, Chef, Puppet, whatever you like. Back the system up using [tarsnap] or +[rsync.net] or [Backblaze,][bb] Google Drive, and [restic.][restic] If you use +ZFS for your LXD storage pool, maybe go with [syncoid and sanoid.][ss] + +[tarsnap]: https://www.tarsnap.com/ +[rsync.net]: https://rsync.net/ +[bb]: https://www.backblaze.com/ +[restic]: https://restic.net/ +[ss]: https://github.com/jimsalterjrs/sanoid + +My point is that using system containers doesn't mean throwing out the last few +decades of systems knowledge and wisdom. ## Crash course to LXD @@ -377,5 +388,11 @@ container. If it was set to run at startup, you'll need to recreate the container, restore from a backup, revert to a snapshot, etc. [^1]: + There's a [technical + publication](https://dl.acm.org/doi/10.1145/3132747.3132763) indicating that + specialised VMs with unikernels can be far lighter and more secure than + containers. + +[^2]: Until they need to do _anything_ more complex than pull a newer image. Then it's twice as painful as the "manual" method might have been.