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

161–170 of 184 posts

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

#161

Post by brabel »

fhuici wrote: post #53
brabel wrote: 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!

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 a…

Looks very cool.

For anyone else wondering how heavy this is on a MacOS, I ran the install script and it just delegated to brew... brew listed the following packages being installed:

    ==> Fetching dependencies for unikraft/cli/kraftkit: aarch64-elf-binutils, gmp, mpfr, aarch64-elf-gcc, coreutils, gettext, readline, gawk, gnu-sed, pcre2, grep, make, capstone, dtc, mpdecimal, ca-certificates, openssl@3, sqlite, python@3.12, glib, libunistring, libidn2, p11-kit, libnghttp2, unbound, gnutls, jpeg-turbo, libslirp, libssh, libusb, ncurses, snappy, vde, qemu, socat, wget, x86_64-elf-binutils and x86_64-elf-gcc
Most should already exist on your mac if you do development... it seems to rely on qemu, unsurprisingly... openjdk as well (probably to support Java out-of-the-box?), imagegick etc.

Took a few minutes to finish installing... the CLI seems to be based on the Docker commands (build, clean, run, 'net create', inspect etc.), some package-manager like commands ('pkg info', 'pkg pull', 'pkg list' etc.), a bunch of "cloud" commands (I suppose that's the non-free part) and "compose" commands just like docker-compose. Interesting stuff.

Note for the parent commenter: the Lua link in the landing page is broken: https://github.com/unikraft/catalog/tree/main/examples/http-...

I tried to run the C hello world example... I get an error, it wants to run Docker?!?! I thought the whole point was to avoid Docker (and containers)??

Here's the log:

i creating ephemeral buildkit container W could not connect to BuildKit client '' is BuildKit running? W W By default, KraftKit will look for a native install which W is located at /run/buildkit/buildkit.sock. Alternatively, you W can run BuildKit in a container (recommended for macOS users) W which you can do by running: W W docker run --rm -d --name buildkit --privileged moby/buildkit:latest W export KRAFTKIT_BUILDKIT_HOST=docker-container://buildkit W W For more usage instructions visit: https://unikraft.org/buildkit W E creating buildkit container: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?: failed to create container

PS. running the hello-world pre-built "image" worked:

> kraft run unikraft.org/helloworld:latest

EDIT:

A lot of stuff looks broken on MacOS.

For example, `kraft menu` doesn't work (error "no choices provided", even though the docs show it working fine without "choices"?)...

`kraft run --elfloader loaders.unikraft.org/strace:latest ./my_binary` also doesn't work (the docs show it working). Error: "unknown flag: --elfloader".

Seems like the product is still in alpha?!

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

#162

Post by kevincox »

nailer wrote: post #160
kevincox wrote: post #38

Earlier quoted context omitted.

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…

> So you do get strong isolation. No, you don’t. There is no benefit the container is providing, because The only feature of the container is isolating you from the zero other containers running on the VM.

The isolation I am referencing is from the VM, not the container. Containers don't provide strong isolation, that is why the VM is required in this model.

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

#163

Post by rakoo »

surajrmal wrote: post #155
FridgeSeal wrote: post #140

Earlier quoted context omitted.

Fly: takes your docker image, converts it into a Firecracker VM and runs that: kernel boundaries etc are all the same as before (and the same as running your container locally). Kraft Cloud: takes your docker image, and turns it into a “unikernel”, and runs that. In a unikernel, your application _is_ the kernel. There’s no process boundary, no kernel-space/userspace split there’s a single address-space etc. I believe…

It sounds like consequences of bugs like memory corruption are far more challenging to deal with in the Kraft cloud situation. Sometimes isolation has other benefits.

Isn't that better isolation though ? A memory corruption will at worse break the OS which is the app and nothing else. Push the model further and you can have one unikernel per user and reduce even further the consequences of bugs

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

#164

Post by angra_mainyu »

ledgerdev wrote: post #92
epr wrote: post #29

No mention of user namespaces whatsoever, which is the primary security isolation mechanism for containers on linux. This is what enables "rootless" mode. Of course, this is from 2017, but user namespaces were released with linux 3.8 in February 2013. Docker particularly has always required extra work to run in rootless mode because it was released soon after in March 2013, and for whatever reason it hasn't been a pr…

Thanks for the suggestion, I was unaware of podman and will be trying it out because root has always bothered me.

Podman is fantastic! It can also handle kubernetes and generate systemd units for containers.

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

#165

Post by imtringued »

Aardwolf wrote: post #42
jsheard wrote: 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).

Because the docker developers hate security. The idea of the docker group is insane, for example. You can mount any directory into a container so being in the docker group is like having a root account.

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

#166

Post by imtringued »

tpetry wrote: post #37
throwaway482945 wrote: post #28

Earlier quoted context omitted.

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.

I know it's cool to talk about these insane numbers, but from what I can tell people have AWS lambdas that boot slower than this to the point where people send warmup calls just to be sure. What exactly warrants the ability to start a VM this quickly?

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

#167

Post by fhuici »

FridgeSeal wrote: post #140
__jonas wrote: post #121

Earlier quoted context omitted.

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

Fly: takes your docker image, converts it into a Firecracker VM and runs that: kernel boundaries etc are all the same as before (and the same as running your container locally). Kraft Cloud: takes your docker image, and turns it into a “unikernel”, and runs that. In a unikernel, your application _is_ the kernel. There’s no process boundary, no kernel-space/userspace split there’s a single address-space etc. I believe…

Hey, author/founder here, thanks for providing that answer, all correct there :) . I would also add that KraftCloud unikernels are built using Unikraft, and that its modularity allow us to tailor/specialize those images to obtain great perf.

Finally, we also had to design and implement a controller from scratch -- nothing out there provided the millisecond semantics and scalability we needed (plus we also did tweaks to network interface creation and a few other things to get the end to end experience to be fast).

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

#168

Post by fhuici »

jve wrote: post #90
zerof1l wrote: 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…

Ahem, this is a research paper. You should look at this stuff as "Innovation" and someone may just consider building a tool or product on the idea... or not.

Author here, we did this, first by continuing the research alongside the creation of the Unikraft LF OSS project -- the result of which was the Eurosys 2021 best paper award (https://dl.acm.org/doi/10.1145/3447786.3456248).

Commercially, we leverage Unikraft on kraft.cloud to provide a cloud platform with millisecond semantics.

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

#169

Post by FridgeSeal »

fhuici wrote: post #167
FridgeSeal wrote: post #140

Earlier quoted context omitted.

Fly: takes your docker image, converts it into a Firecracker VM and runs that: kernel boundaries etc are all the same as before (and the same as running your container locally). Kraft Cloud: takes your docker image, and turns it into a “unikernel”, and runs that. In a unikernel, your application _is_ the kernel. There’s no process boundary, no kernel-space/userspace split there’s a single address-space etc. I believe…

Hey, author/founder here, thanks for providing that answer, all correct there :) . I would also add that KraftCloud unikernels are built using Unikraft, and that its modularity allow us to tailor/specialize those images to obtain great perf. Finally, we also had to design and implement a controller from scratch -- nothing out there provided the millisecond semantics and scalability we needed (plus we also did tweaks…

That sounds amazing! Very keen to give it a try.

My work had a product that was doing builds and hosting for arbitrary client code, you’re doing all that, plus more. I’ve got massive respect for that, because there were some hard problems to solve, even in our pretty vanilla environment- looks like you guys have done a far better job than we did, plus more!

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

#170

Post by benreesman »

oceanplexian wrote: post #107
benreesman wrote: post #58

Earlier quoted context omitted.

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.

All the younger engineers I talk to think you would need to be Albert Einstein to bootstrap a bare metal server. As someone who made a living doing this at scale, where we would build a new datacenter every 2-4 weeks using 100% open source or off the shelf tools, I completely disagree. I think PXE booting some servers and running a binary on them is 90% easier than most container orchestration engines, Kubernetes con…

I’ll urge that we don’t compare Albert Einstein to a k9s expert.

No one will ever be considered for a Nobel over Kubernetes.

Post reply on HN