progress on LXD post
This commit is contained in:
parent
ab8936b4d4
commit
47bc405d8a
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue