Hello Andrey,
thanks for getting back to me. The reason for unpriviledged containers
is basically user id separation.
I fancy the idea that each container has its own id (range) and the user
ids are not being shared between containers (and the host).
So it is another level of isolation and administration - in its simplest
form be it just using "ps" where you can tell from the user id what
container (os) the process belongs to.
More into classical os level virtualisation (jails, openvz) than what
is usually associated these days with the term "container".
So there is no respawning, no stacked images, no orchestration, but a
proper (albeit minimal) os installation. Without the overhead of a
hypervisor.
So lxc pretty much is the right tool. Would just be great if one could
use level3 ip-vlan for easier filtering.
Am 04.03.20 um 21:37 schrieb Andrey Repin:
Greetings, Ede Wolf!
So please let me rephrase my question: Is there any alternative to
standard bridging for running unprivileged lxc containers?
Is there a use case for unprivileged LXC containers?
I fail to see one, and I'm using LXC for five-or-so years. If you are using
bare LXC, you are likely spawning new ones infrequently and each have its own
unique purpose. If that's not true, you're better off using
LXD/docker-swarm/etc.
_______________________________________________
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
