As someone that doesn't use Linux, this title was very confusing. Coffins. They're called coffins.
Or womb if your still compiling
Good summary.. had a quick read and I use containers the same way (mostly proxmox these days because it makes them so easy, but it's just lxc under the hood).
I share your dislike of docker-only apps. Lemmy is a good example.. the 'from scratch' install didn't work at all for me and the ansible script just creates docker images..
I work around it by nesting docker in an lxc container for such apps. Keeps them contained in one place.. easier to manage. I have a proxmox template with docker installed (& my base network setup) so it only takes a couple of minutes to spin up.
I'm new to the container world, but everything I've seen and read about so far makes me dislike Docker. I really don't get why it's so popular - except for the cross-platform compatibility I guess?
In a word: convenience.
It was in the right place at the right time with easy UX. A big audience were developers not so familiar with sysadmin in the commercial software world. It provided an easy way to get a kind of executable package. Devs could throw in all their Python/Ruby/JS dependencies and not worry about it. "works on my machine" was basically good enough because you just ship the whole damn thing over.
Docker then supervised the process for you, too. The whole Docker package took care of a lot of things
PS: for those really interested in containers, I always recommend looking into Plan 9: the OS from the original UNIX team intended as a successor to UNIX. Every process has its own namespace and the whole OS is built around that concept (plus a few other core things.. too much to go into here). see also https://pdos.csail.mit.edu/~rsc/plan9.html
The benefit of docker is portability. You can run software anywhere. Rather than going through all this pain of installing and managing systemd services, you can just run a docker container, often in only one command. Docker also handles things like setting environment variables, which are sometimes used by apps as a an alternative for, or even replacement for settings filed, like in the lemmy docker example: https://github.com/LemmyNet/lemmy/blob/main/docker/docker-compose.yml
Docker succeeds where java failed, but in a language agnostic way.
And I disagree with the author's point about disliking docker-only apps, for two main reasons. One, it isn't the developers responsibility to package things for every system, and two, docker containers are mostly self documenting, being very close to simply a shell script. I almost always look at dockerfiles, and I have only seen one or two that are not simple to extract to make them run outside docker.
For example, the lemmy docker image: https://github.com/LemmyNet/lemmy/blob/main/docker/Dockerfile
The author acts like it's some advanced witchcraft or something, but it's just using rust to compile stuff on an debian based system. Every command used to build lemmy is right there. Then, you can look at the environment variables set in the docker compose, and set them in a systemd service or something.
How do I tag people on lemmy?
u/tony
I suggest anyone considering LXD also give nspawn a look. May or may not suit your needs better.
LXD can manage VMs and can manage clusters with live migration for both containers and VMs. I don't know if nspawn can.
No software is capable of doing live migration/high availability for pet type containers and virtual machines except lxd.
But nspawn isn't really a management software like lxd is, it's more of a container runtime like lxc is.
Ninja edit: Did some googling and I'm technically wrong. Hashicorp's nomad supports lxc as a driver, but according to the doc it only supports host networking...
https://developer.hashicorp.com/nomad/plugins/drivers/community/lxc#networking
But nomad also supports managing nspawn containers which is interesting.
Using NixOS, I've come to really like nspawn containers.
They are not immutable. Might as well use a chroot at that point
Neither are Docker(-like) containers, at least by default. They are just not intended to keep their filesystem state outside of volumes or mounts
True but you can just blow away everything and start from scratch when something goes wrong. It also makes updates way easier
[This comment has been deleted by an automated system]
