But I've never quite understood the appeal. Is it about running untrusted containers with VM-level isolation? Or having a familiar GUI for managing and lifecycling them? Something else?
Fundamentally, I worry that mixing VMs and containers is more likely to end up with the worst of both worlds rather than the best— basically you get the slow bootup of starting the kernel every time, but none of the application-level benefits of sharing base layer storage or mounting the same shared volume to multiple containers at once.
Ah the GUI/container integration is more for homelabs/internal networks type of usage, and I agree that it makes little sense in production. Otherwise you are also right that containers should be managed in a very different way from VMs. Especially when the page you linked boasts about offering a similar experience to deploying VMs for sys admins, which might lead to unoptimal usage for both VMs and containers. (But it at least seems to offer docker container support, not the barely used LXCs. So at least it can be useful)
> the page you linked boasts about offering a similar experience to deploying VMs for sys admins, which might lead to unoptimal usage for both VMs and containers. (But it at least seems to offer docker container support, not the barely used LXCs. So at least it can be useful)
Relatively long-lived, potentially multi-process server things is what LXC is for. It makes more sense to run LXC than Docker in that situation anyway. -_-
But I've never quite understood the appeal. Is it about running untrusted containers with VM-level isolation? Or having a familiar GUI for managing and lifecycling them? Something else?
Fundamentally, I worry that mixing VMs and containers is more likely to end up with the worst of both worlds rather than the best— basically you get the slow bootup of starting the kernel every time, but none of the application-level benefits of sharing base layer storage or mounting the same shared volume to multiple containers at once.