progress on LXD post

This commit is contained in:
Amolith 2023-09-17 18:04:50 -04:00
parent ab8936b4d4
commit 47bc405d8a
Signed by: Amolith
GPG Key ID: 8AE30347CE28D101
1 changed files with 22 additions and 5 deletions

View File

@ -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.