LXD isn't an alternative to podman. Podman is meant to run 'application containers', where each container has just one running process. LXD is meant to run 'system containers' where each container is a full Linux distribution with an init system and (possibly) multiple daemons. LXD containers are like light-weight VMs. Unlike VMs, LXD containers share the host kernel.
You could run podman or other OCI containers inside LXD. I use LXD to test multi node K8s (K3s) on my desktop system.
I briefly used LXD once when I needed a full system inside a container.
But podman also supports systemd inside a container and along with macvlan networking you can pretty much build an "independent" container acting almost as a VM.
Would LXD provide any other advantages/differences to that?
There's a bit of a Turing Tarpit here because they're both ultimately just namespaces under the hood so you can with effort get them to do equivalent things.
The original idea behind LXD was to build packages in a system equivalent to your real system but without spamming your dpkg database and filesystem with all the required -dev files. The idea behind Docker (which podman is a better implementation of and extension to) was to be able to have three different versions of Apache ephemerally on your system to match the versions used by three different projects today.
Ultimately you can do both with either (and I generally use podman to build packages, as an example) but if you do that you aren't playing to the project's strengths.
Toolbox and distrobox are sort of middle grounds that do both of them well enough to be tolerable.
LXD use case is totally different from podman, k8$ , docker.
It is like building your own digital ocean , for containers (and vms) . It can be used as a container host for docker/podman containers, virtual machine manager for qemu, it is like having your own VPS to put your servers in.
If you use LXD you don't need Podman, the main difference between LXD and Podman is LXD runs System Containers while Podman runs Application containers.
One advantage of having a system container is you can use a package manager to update your applications. With Podman, you have to replace the entire container, with LXD you can just "PATCH" the container. This results in much faster upgrade / lifecycle management.
goku12|2 years ago
You could run podman or other OCI containers inside LXD. I use LXD to test multi node K8s (K3s) on my desktop system.
gulikoza|2 years ago
But podman also supports systemd inside a container and along with macvlan networking you can pretty much build an "independent" container acting almost as a VM.
Would LXD provide any other advantages/differences to that?
sureglymop|2 years ago
v3ss0n|2 years ago
btreecat|2 years ago
bandrami|2 years ago
The original idea behind LXD was to build packages in a system equivalent to your real system but without spamming your dpkg database and filesystem with all the required -dev files. The idea behind Docker (which podman is a better implementation of and extension to) was to be able to have three different versions of Apache ephemerally on your system to match the versions used by three different projects today.
Ultimately you can do both with either (and I generally use podman to build packages, as an example) but if you do that you aren't playing to the project's strengths.
Toolbox and distrobox are sort of middle grounds that do both of them well enough to be tolerable.
v3ss0n|2 years ago
zacksiri|2 years ago
One advantage of having a system container is you can use a package manager to update your applications. With Podman, you have to replace the entire container, with LXD you can just "PATCH" the container. This results in much faster upgrade / lifecycle management.
You can read about this on my blog post. https://zacksiri.dev/posts/why-i-created-pakman