Live data from Hacker News

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

dl.acm.org

121–130 of 184 posts

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

#121
post #96
post #80

Docker has a big community, lots of guides, and ready-to-use containers. It became pretty much a de facto standard for self-hosting things. You also have a very high chance of getting a piece of software to work out of the box as intended with Doker. The only way this or some other way of running stuff will overtake Doker is if it will match the Docker in these aspects. As much as I'd love to try this lightweight VM…

Maybe try out kraft.cloud: we take Dockerfiles as input and automatically convert to lightweight VMs/unikernels when deploying (disclaimer: I'm one of the paper's authors and one of the people behind KraftCloud).

I thought that’s what fly.io is, although I’m not familiar with it, am I missing something?

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

#122
post #97

Earlier quoted context omitted.

I tell people "An OCI container is a way to turn any random runtime into a statically linked binary." It is very useful for managing dependency hell, or at least moving it into "API dependencies" not "Library dependencies", it is handy for pickling a CI/CD release engineering infrastructure. It's not a security boundary. (I'm 100% agreeing with parent, in case I sound contentious)

> It's not a security boundary. It is a security boundary, just not necessarily the best one.

It's an incidental security boundary because CGroups happen to isolate the process fairly well.

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

#123
post #112

OS: I provide isolation where needed, handle safely interacting with outside world, and abstract away all the pesky stuff so programmers can just get stuff done. Container / VM: I provide isolation where needed, handle safely interacting with outside world, and abstract away all the pesky stuff so programmers can just get stuff done. I get that a dev machine (OS) isn't usually suitable for deployment or shared develo…

I guess this came to be due to the poor original security model of classic OSs, which led to prolification of viruses and complex management of shared resources. Users, groups and access flags are not enough to manage security of a system.

Linux tried to fix that with namespaces and it turned out to be more or less successful, but Linux is not an OS, it's just a kernel, and it's up to real OSs built atop Linux to use namespaces as an implementation detail for real application isolation.

One way to do that is OCI-containers, the other way is Flatpak. Neither of those is not a proper OS yet, but you could call Kubernetes an operating system which uses containers as means for application and resource isolation. Naturally that means Kubernetes is a complex beast, but that's what it takes to provide what users expect from an OS.

Android also comes to mind, they managed to isolate applications between each other quite safely.

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

#124
post #93
post #59

Earlier quoted context omitted.

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.

I'm struggling a little bit to grasp all the concepts when we start talking about unikernels, wasm and so on. Hopefully that's just a sign of the maturity of it, and not a sign of my mental decline. But on paper (as I understand it) it looks /so cool/.

Agree with epr's definition of a unikernel (and no, no mental decline on your part, this isn't always well defined).

First off, a unikernel is a virtual machine, albeit a pretty specialized one. They're are often based on modular operating systems (e.g., Unikraft), in order to be able to easily pick the OS modules needed for each application, at compile time. You can think of it as a VM that has a say NGINX-specific distro, all the way down to the OS kernel modules.

VMs provide what's called hardware-level isolation, running on top of a hypervisor like KVM, Xen or Hyper-V. Wasm runs higher up the stack, in user-space, and provides what's called language-level isolation (i.e., you could even create a wasm unikernel, that is, a specialized VM that inside runs wasm (eg, see https://docs.kraft.cloud/guides/wazero/). Generally speaking, the higher you go up the stack, the more code you're running and the higher the chances of a vulnerability.

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

#125
post #112

OS: I provide isolation where needed, handle safely interacting with outside world, and abstract away all the pesky stuff so programmers can just get stuff done. Container / VM: I provide isolation where needed, handle safely interacting with outside world, and abstract away all the pesky stuff so programmers can just get stuff done. I get that a dev machine (OS) isn't usually suitable for deployment or shared develo…

Containers are an OS feature, though. The OS is fulfilling the promise of environment isolation with containers.

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

#126
post #4

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

Why weren't containers rootless from the start anyway? What did they need that user space doesn't provide? Wine, emulators and VMs didn't require it either (with the exception of some VMs needing a kernel module for performance reasons like memory management, which I also find stupid, the OS should provide all the performance in user space).

As I mentioned in another comment, the linux kernel feature (user namespaces) that enables "rootless" containers was released in February 2013, and Docker was released soon after in March of that year. For whatever reason, they haven't made it a priority to make rootless the default, although it is technically doable. If you are annoyed by this, I'd suggest checking out podman, which has done a lot of work to be basically a drop in replacement with a similar workflow to docker.

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

#127

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…

I am looking at the examples. They all have a Docker file. If that just for local development on my laptop? Using the deploy command line tool is the Docker file used to determine dependencies for the hosted VM? What if a developer is using an unusual programming language, like Common Lisp. Is that doable?

A Dockerfile is just a file with a bunch of commands to execute and get a working "computer". https://github.com/combust-labs/firebuild is fairly aged translation of the Dockerfile to a VM rootfs.

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

#128
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…

Memory de-dup is computationally expensive, and KSM hitrate is generally much worse than people tend to expect - not to mention that it comes with its own security issues. I agree that the security tradeoffs need to be taken seriously but the realworld performance/efficiency considerations are definitely not negligeable at scale.

There are also significant operational concerns. With containers you can just have your CI/CD system spit out a new signed image every N days and do fairly seamless A/B rollouts. With VMs that's a lot harder. You may be able to emulate some of this by building some sort of static microvm, but there's a LOT of complexity you'll need to handle (e.g. networking config, OS updates, debugging access) that is going to be some combination of flaky and hard to manage.

I by no means disagree with the security points but people are overstating the case for replacing containers with VMs in these replies.

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

#129
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.

The main advantage in my use case is in fact isolation (network and volumes) and a well defined API enabling management of those containers in production (not k8s, a tiny subnet of that perhaps).

The isolation could be achieved using namespaces directly. But the API, tooling and registry add a lot of value that would otherwise require a lot of development.

Also last time I looked hypervisors aren't possible on all cloud vendors, unless you have a bare metal server. This matters in my case. Maybe it has changed in the past 3 years.

When docker fits it's great. Same can be said of k8s, where there are a whole bunch of additional benefits.

Swings and roundabouts.

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

#130
post #89
post #80

Docker has a big community, lots of guides, and ready-to-use containers. It became pretty much a de facto standard for self-hosting things. You also have a very high chance of getting a piece of software to work out of the box as intended with Doker. The only way this or some other way of running stuff will overtake Doker is if it will match the Docker in these aspects. As much as I'd love to try this lightweight VM…

The ready-to-use is only true for the most popular software like PostgreSQL. Anything else is often broken and/or unmaintained.

In web development I had never experienced an issue with the commonly used softwares
Post reply on HN