Hacker News Reader

Comment by ausjke | Hacker News Reader

thought Canonical is doing its own "docker", e.g. SNAP, lxd etc that are not totally identical but very similar to docker, what's going on here.

View on HN

There's more than one type of container. Docker, and docker flavors (runc, rkt, etc). LXD is a machine container, it's the same technology that Docker was first built off of, but it's a hypervisor for really dense machines that are as light as process containers.

Snaps is a package format that gives you a cross (linux) platform distribution, atomic updates, security, and isolation. It's not really like docker as it's not a density story, there's no unique TCP/IP stack, etc.

like xen? I sat on a 10 minute presentation during openstack meetup, Ubuntu dude presented LXD...then I asked myself...xen does all this...then again choice is always welcomed

Sure, Xen is a hypervisor - just like KVM and a whole host of others, but Xen is /very/ heavy from a resource utilization. Xen doesn't produce lightweight VMs, they're traditional virtulation. You can produce 13 times more density with no performance trade off. No virtio, no paravirtualization, using native kernel primitives to get you machines that feel like "docker" containers, but are actual full machines.

The VM experience ("guests") without the VM overhead. A virtual machine like Xen or KVM or ESX lets you run a guest kernel of a different OS, like WIndows. LXD avoids the overhead of hardware virtualisation and the guest OS, which means it only supports Linux guests, but they run at native speeds.

> without the VM overhead

or the VM security

LXD does at least (unlike docker) default to unprivileged containers

Any local kernel vulnerability will let you attack other containers on the same machine. This is a much bigger attack surface than Xen or KVM. It's nice in that it gives the same experience as "traditional" hypervisors (at least the basic features), but it's only applicable if you trust that the application inside the container will not be compromised.

LXD supports using different id maps per container, which mitigates some of that.

I get that containers will always have a larger attack surface than Xen/KVM. Just thought it was worth mentioning that some container approaches are thinking about security more than others.

Nope. If you get to the kernel it's game over.

On the same vein, there are plenty of Xen machines that are vulnerable despite the host OS being updated (which, honestly, I don't thing happens as quickly as it should considering it requires a restart for new kernel params). With things like live-patching, updating the kernel once, while running, makes sure all guests are also updated as well.

It's a trade off, but one that seems to trend towards more secure despite potentially a few quirks.

On the flip side, when there is a kernel vulnerability, there's only 1 kernel to update! If you're running the Canonical Livepatch Service, for instance, critical security vulnerabilities are patch in real time, without reboot, and all containers running immediately benefit from the patch. Conversely, if you're running 50 Linux Xen or KVM machines, you have 51 kernels to update. So yeah, do think about what "attack surface" actually means, when comparing LXD and Full Virtualization.

If you manage so many hosts you had better use Ansible, or Satellite or whatever so that updating 1 or 50 or 500 hosts is the same effort.

Calling rkt and runc docker flavors is a bit misleading. Runc is an OCI standard container runtime which docker itself also uses. Although rkt can consume docker images it is an entirely different container runtime with several distinct execution stages. For instance, you can run rkt containers with an LKVM stage1 instead of systemd-nspawn.

Similar in foundation, different in goals.

Reply on news.ycombinator.com