Comment by josteink
2 days ago
OCI is for running prepackaged software in black boxes from the internet, where you have no interest or ownership of the container internals.
Most of my containers are not like that. Well, actually none are.
systemd-nspawn is for running your own containers, with a VM-like usage pattern (ie not immutable), deployed as part of your overall systemd based infrastructure for when the thing you need to manage is "too big" to be deployed as its own systemd-service unit, but you still want to be able "to systemd" it.
This fits my use-case perfectly.
This distinction is a more useful one that the article made. I love dockerfiles and immutability, but there are good cases for mutable containers, too.
You can also do some neat things with "--ephemeral" and "--volatile" to basically overlay the image (or a subset) with tmpfs; any changes to those overlays will be lost when the container is brought down. The specific mount points can be controlled in greater detail via "--tmpfs" and "--overlay".
https://0pointer.net/blog/running-an-container-off-the-host-...
I'm not sure how easy that is to customize in Podman.
Containers already are mutable on all popular runtimes. “Immutability” comes from destroying and recreating them from their image, but there’s nothing forcing you to delete/recreate them, and indeed that’s not even the default behavior.
I think you’re conflating packaging and runtime. OCI images are a packaging format while systemd-nspawn is a runtime. Runtimes and package formats are orthogonal.
> systemd-nspawn is for running your own containers, with a VM-like usage pattern (ie not immutable)
Containers aren’t immutable (OCI or otherwise). Again, I think you’re conflating images (the package formats are orthogonal) with their runtime instantiation, the container. OCI images like VM images are immutable, but containers and VMs are mutable.
My main objection to systemd-nspawn (at least as described in the article) is that it lacks a complementary package manager (or rather, that there’s no remotely convenient way to run software packages with it) and so you have to create your containers with manual changes and dodgy bash scripts. Regardless of what runtime you use, that seems like a not-very-maintainable way to manage software.