Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dl.acm.org

Post reply on HN
Print view View original

31–40 of 184 posts

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

#31

Post by nailer »

andix wrote: 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.

> If there is some additional isolation required, just run the container in a VM.

No. Running a container in a VM gets you no additional isolation. Containers share kernel space and as such have limited isolation to VMs, which have isolated kennels. In exchange for this Lack of additional isolation, you’ve added a Bunch of extra Complexity.

Pardon the extra caps I am using iOS voice dictation.

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

#32

Post by tpetry »

brabel wrote: post #13
andix wrote: 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!

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.

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

#33

Post by akdev1l »

codedokode wrote: post #30
Cthulhu_ wrote: post #20

Earlier quoted context omitted.

Isolated, but are they isolated enough? The article states that containers offer weaker isolation than VMs. (it doesn't quantify it though and I don't know this kind of thing offhand)

Processes run in a userspace and cannot do anything without OS approval.

The kernel can be attacked and exploited.

Container escape exploits are more common than VM escape exploits.

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

#34

Post by indymike »

dailykoder wrote: post #25
dweekly wrote: post #15

Earlier quoted context omitted.

If this were true, then wouldn't folks just need an application binary that statically links all of its required libraries and resources into a giant, say, ELF? Why even bother with a container?

Because static libraries ain't a big thing anymore. Maybe they will become popular again. This would make it easier to have reproduceable build without a container. But I think containers are the new static libs now

Interpreted languages and their associated dependencies are more of an issue than static linking with compiled languages.

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

#35

Post by TDiblik »

dweekly wrote: post #15
andix wrote: 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.

If this were true, then wouldn't folks just need an application binary that statically links all of its required libraries and resources into a giant, say, ELF? Why even bother with a container?

First thing that comes to mind is the need to link against libraries across platforms. Imagine that my app depends on opencv, if I wanted to statically link everything on my Windows machine, I need to compile opencv for Linux on my windows machine (or use pre-compiled binaries). Also, if you link against libraries dynamicaly, it's likely you can compile them on the host machine (or in a container) with more optimizations enabled. And the last thing is probably the ability to "freeze" the whole "system" environment (like folders, permissions, versions of system libraries).

Personally, I use containers to quickly spin-up different database servers for development or as an easy way of deployment to a cloud service...

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

#36

Post by jcelerier »

dweekly wrote: post #15
andix wrote: 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.

If this were true, then wouldn't folks just need an application binary that statically links all of its required libraries and resources into a giant, say, ELF? Why even bother with a container?

Well yes, but try turning some random python, java or ruby service into a single binary .. now do that 12 times. Or try with a native app that leverages both the GPU and libLLVM, and enjoy finding out the kind of precautions you have to take for LLVM to not blow up on a computer where your GPU driver was built with a different LLVM version.

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

#37

Post by tpetry »

throwaway482945 wrote: post #28
iamstan23 wrote: post #11

Earlier quoted context omitted.

fly.io uses Firecracker. Firecracker is Open Sourced with an Apache 2 license. It's faster than LightVM mentioned in the post. Firecracker also has containerd support ( https://github.com/firecracker-microvm/firecracker-container... ). There are a few ways to run Kubernetes with Firecracker, including FireKube.

Is it really faster? I thought firecracker boot times were something like 100ms. LightVM claims 2.3ms?

LightVM is stating a VM creation of 2.3ms while Firecracker states 125ms of time from VM creation to a working user space. So this comparing apples and oranges.

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

#38

Post by kevincox »

nailer wrote: post #31
andix wrote: 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.

> If there is some additional isolation required, just run the container in a VM. No. Running a container in a VM gets you no additional isolation. Containers share kernel space and as such have limited isolation to VMs, which have isolated kennels. In exchange for this Lack of additional isolation, you’ve added a Bunch of extra Complexity. Pardon the extra caps I am using iOS voice dictation.

I think they mean run a VM with one container inside. So you do get strong isolation.

This is similar to how managed container IaaS works. They launch a VM and run your container in it.

It is extra complexity but has a few advantages. 1. People already have a convenient workflow for building container images. 2. The base OS can manage hardware, networking and whatever other low-level needs so that the container doesn't need to have these configurations. 3. If you want to trade of isolation for efficiency you can do this. For example running two instances of a container in the same VM. The container doesn't need any changes to support this setup.

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

#40

Post by akdev1l »

nashashmi wrote: post #17

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

A VM is a virtualized instance with virtual hardware and can therefore run its own operating system with its own kernel to interface with the virtual hardware.

A container is basically a process restricted by multiple kernel namespace isolation mechanisms. It shares the same kernel with the host and does not present any “virtual hardware”.

Post reply on HN