Live data from Hacker News

My VM is lighter (and safer) than your container (2017)

dl.acm.org

51–60 of 184 posts

Re: My VM is lighter (and safer) than your container (2017)

#52
post #13
post #9

I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.

But if you can get isolation, security AND reproducible environments using a VM, specially one that's nearly as fast as a OS process, the case for using containers instead pretty much disappears. I don't know this LiteVM thing but I will definitely investigate that, specially given that on my Mac I need to use a VM anyway to run containers!

At the time of publication of the article the tool used to create the minimalistic VM Tinyx was not released and as far as I can see was never released.

Re: My VM is lighter (and safer) than your container (2017)

#53
post #13
post #9

I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.

But if you can get isolation, security AND reproducible environments using a VM, specially one that's nearly as fast as a OS process, the case for using containers instead pretty much disappears. I don't know this LiteVM thing but I will definitely investigate that, specially given that on my Mac I need to use a VM anyway to run containers!

Check out kraft.cloud and the accompanying LF OSS project www.unikraft.org :) (disclaimer: I'm one of the authors of the paper and one of the people behind that cloud offering). On KraftCloud we use Dockerfiles so users can conveniently specify the app/filesystem, and then at deploy time transparently convert that to a unikernel (specialized VMs). With this in place, NGINX cold starts in 20 millis, and even heavier apps/frameworks like Spring Boot in < 300 millis (and we have a number of tech to bring these numbers even further down).

Re: My VM is lighter (and safer) than your container (2017)

#54

Stupid question but forgive me: Whats the difference between a container and a VM?

high level, a vm is an entire virtual machine with its own kernel/operating system/filesystem/etc. a container is a process (and associated files/archived filesystem) with a (more or less) isolated view of the world (network/filesystem/etc.) running on top of the same kernel/os as other processes on the same machine.

examples: a) vm - an entire windows install running in a window on my linux workstation so i can use tax software once a year. two kernels running at the same time. (N+1 for N VMs) b) container - a small python service, its dependencies, and various filesystem bits from alpine-minimal packaged into a file that docker/containerd/whatever can turn into the service running in a little isolated portion of my machine. no matter how many i run, one kernel. the various processes just don't see the host or other procs' files/memory/etc. via namespace trickery (unless there's a security problem, lol)

Re: My VM is lighter (and safer) than your container (2017)

#55
post #9

I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.

While reproducible build envs are a nice feature of using containers, they aren't the primary benefit.

The primary benefit is resource usage and orchestration.

Rather than duplicating entire aspects of an OS stack (which might ne considered wasteful) they allow for workloads to share aspects of the system they run on while maintaining a kind of logical isolation.

This allows for more densely packed workloads and more effective use of resources. This is a reason why the tech was developed and pushed by google and adopted by hyperscalers.

Re: My VM is lighter (and safer) than your container (2017)

#56
post #32
post #13

Earlier quoted context omitted.

But if you can get isolation, security AND reproducible environments using a VM, specially one that's nearly as fast as a OS process, the case for using containers instead pretty much disappears. I don't know this LiteVM thing but I will definitely investigate that, specially given that on my Mac I need to use a VM anyway to run containers!

But then also monitoring gets harder. With containers you could see (and monitor) all those processes running in container easy on the host. With VMs? You now need a way to get data from within the VM which in most lightweight VM implementations just not possible.

On kraft.cloud we have unikernels (specialized VMs) with Prometheus exporters that can be scraped, and other monitoring facilities.

Re: My VM is lighter (and safer) than your container (2017)

#57

Earlier quoted context omitted.

Containers are perfect for build environments and for creating the root filesystem. The issue is that the kernel these days are super bulky and are intended for multi-user, multi-process environments. Running a container runtime on top just makes it worse when you're looking for "isolation". This paper argues that when you build a extremely minimal kernel (i.e. ditch Linux entirely) and link your application against…

> build a extremely minimal kernel (i.e. ditch Linux entirely) and link your application against necessary bits of code It would be nice, but this is really hard to do when modern software has so many layers of crud. Good luck getting say, a PyTorch app, to work doing this without some serious time investment.

Most of that effort should be sharable. if you know you will only have one python process you can get rid of a lot of cruft. If you know you will be running in a VM then you only need the driver for the network interface the VM provides not every network interface every designed (often including ones that your hardware doesn't even physically support). So while there is serious time investment it isn't nearly as much as it would be to write a competitor to linux.

Re: My VM is lighter (and safer) than your container (2017)

#58
post #9

I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.

Containers have their place, if you’re racking and running your own gear life gets a lot better than screwing around with IPMI.

But reproducible infrastructure as code is just orthogonal to that: everything from Salt to Nix is credible in that role.

Containerizing on top of a Xen hypervisor never made sense to me.

Re: My VM is lighter (and safer) than your container (2017)

#59
post #44
post #4

From 2017, before rootless containers caught on I think. The conclusions on safety might be due for re-evaluating.

I don't really see how rootless containers change anything at all. You're still "just" one kernel privilege escalation away from breaking out. The level of isolation is much better in virtual machines, and the performance penalty is comparable these days. The virtual machine images are a bit heavier, since you need a kernel and whatnot, but it's negligible at best. The memory footprint of virtual machines with memory…

And these overheads are even smaller if you use unikernels as per the paper. Eg, cold starts of a few milliseconds depending on the app/size of the image.

Re: My VM is lighter (and safer) than your container (2017)

#60
post #9

I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.

There is no such thing as a reproducible build environment anymore. You can get a temporary reproducible build environment, but any sane security policy will have certificates that expire and that in turn means that in a couple years your build environment won't be reproducible anymore.
Post reply on HN