-
I hope this doesn't affect LXC negatively.
LXC and LXD share plenty of contributors.
https://github.com/lxc/lxc/graphs/contributors
https://github.com/canonical/lxd/graphs/contributors
I use an "unprivileged LXC container" setup on several Debian bullseye hosts. It works fantastic, and each LXC container feels like a real server.
Compare that to Docker's "one-container-one-process" philosophy, reinventing the wheel by awkwardly composing multiple containers.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I hope this doesn't affect LXC negatively.
LXC and LXD share plenty of contributors.
https://github.com/lxc/lxc/graphs/contributors
https://github.com/canonical/lxd/graphs/contributors
I use an "unprivileged LXC container" setup on several Debian bullseye hosts. It works fantastic, and each LXC container feels like a real server.
Compare that to Docker's "one-container-one-process" philosophy, reinventing the wheel by awkwardly composing multiple containers.
-
"easily" is a matter of opinion. It did take me a little effort to get it nailed down. Here's the markdown shell script I use to create new LXC containers: https://github.com/robsheldon/biphrost-shell/blob/biphrost/l... -- it should be easy enough to modify for other environments.
It's been a while since I looked into it, but IIRC there was a "migration" or "adoption" step. I think you're generally right that LXD worked like an extension of or administrative layer for LXC, but also: http://web.archive.org/web/20230605025133/https://linuxconta... (the documentation is no longer available on linuxcontainers.org now that Canonical has taken over the project).