Live data from Hacker News

Ignite – Use Firecracker VMs with Docker images

github.com

51–60 of 84 posts

Re: Ignite – Use Firecracker VMs with Docker images

#51
post #7

For me, this is the deal breaker, but this is still exciting to me: > Note: At the moment ignite and ignited need root privileges on the host to operate due to certain operations (e.g. mount). This will change in the future. I’d love it if this ends up getting changed. It’s a hard line to walk, but this would make Docker containers feasible on multi-user systems. (Without using Singularity, which has its own downside…

Found the HPC guy. I was so excited for this until I got to that line. I'll still be following this closely though, the potential is huge.

Re: Ignite – Use Firecracker VMs with Docker images

#52
post #6

Earlier quoted context omitted.

Why would you want to migrate a firecracker vm? They are supposed to be for small, short lived processes. Or in this case, Docker containers (which are likely to be controlled by some kind of orchestration). If you want to be able to migrate a running VM, do you still really need it to start super fast? It’s going to be a long lived service (otherwise you wouldn’t migrate it), so a longer spin up time should be accep…

> If you want to be able to migrate a running VM, do you still really need it to start super fast? Yes. "You" is two different people in this sentence. The person doing the migration is often not the person who owns whatever service is running in the VM. They have uncorrelated needs. As a platform operator, I want to migrate VMs to be able to balance load and evacuate dying hardware. As a service operator on that pla…

Just spawn a new VM on a hypervisor and delete the old VM on the hypervisor that is dying. You can also balance load this way.

Re: Ignite – Use Firecracker VMs with Docker images

#53
post #39

Earlier quoted context omitted.

> microVMs for running containers are definitely a great idea I think my greybeard must be getting too long... This sounds like insanity to me. Why not just make a base image and some simple setup scripts? If you need to get super fancy, these guys have it figured out [1]. They can clone a running vm in under two seconds. [1] https://codesandbox.io/post/how-we-clone-a-running-vm-in-2-s...

General advice: when smart people are investing time and energy into a solution, and your alternative solution involves the word "just", it's usually a code smell that you're not giving the people doing the work enough credit.

Being smart doesn't mean that whatever you're doing is.

Re: Ignite – Use Firecracker VMs with Docker images

#55
Does this work for anybody? I've just tried it in a KVM Debian 11 VM on proxmox. Deploying from yml manifest does not like my `ssh: true', removing existing /etc/firecracker/manifest/*.yml file segfaults the daemon. Trying to `ignite run ubuntu:latest` or `ignite run alpine:latest` dies on trying to run init ... where's the benefit of leveraging existing containers?

Looks abandoned for a year at least ...

Re: Ignite – Use Firecracker VMs with Docker images

#56
post #10

Damn, this is going to eat the world. Docker but with full host isolation making it suitable for untrusted workloads, hot damn. This could for real make fully managed multi-tenant completely serverless k8s possible once it gets to the point where it can be used as a containerd and CRI implementation.

Been doing that by running kubernetes inside SmartOS zones via bhyve VMs on multi-tenant systems. Works pretty well, although they are slightly more resource hungry VMs than the ones in this article.

Re: Ignite – Use Firecracker VMs with Docker images

#57
post #39

Earlier quoted context omitted.

General advice: when smart people are investing time and energy into a solution, and your alternative solution involves the word "just", it's usually a code smell that you're not giving the people doing the work enough credit.

OTOH, smart people seem to constantly try to reinvent existing products or over-engineer tools to set themselves apart and create a new business. See the endless stream of new JS frameworks popping up every day. Or the myriad ways that people try to create clouds on top of clouds (Yo dawg! I heard you like clouds!). Or new databases (although I confess I follow these). Or reinventing static HTML page delivery. ... an…

> See the endless stream of new JS frameworks popping up every day

Citation needed. E.g.

2010: AngularJS, Backbone

2011: EmberJS, ReactJS

2012: MeteorJS

2013: HexoJS

2014: CycleJS, VueJS

2015: MithrilJS, PolymerJS, Serverless Framework

2016: Angular2, AureliaJS, NextJS, Svelte

Those are a lot of the most popular ones, and some not very popular. Do you really consider this an endless stream of new JS frameworks popping up every day?

Re: Ignite – Use Firecracker VMs with Docker images

#58
post #49

Earlier quoted context omitted.

Wow, what OS are you booting? I used to run a “bare metal servers as a service” product, and we could provision most images to a bare metal server in under 5 minutes. If I had a VM take more than 60 seconds to come up today I’d suspect something was wrong.

15 minutes is on the high end, but 5-10 minutes is typical for Windows. You can’t deploy a ready image, usually, you have to deploy one that is sysprepped so Windows can do device discovery on first boot. You can deploy them with the devices already set up, but sometimes (literally sometimes, it’s hard to tell when it happens) Windows gets really upset if any of the hardware changes. I think Windows 10/11 (and Server…

There's your problem. I can boot a tinyconfig Linux kernel that's 600K in QEMU using the microvm machine type in milliseconds. A basic Windows install is tens of gigabytes, and doesn't have the capability of being stripped down to the barebones essentials.

Re: Ignite – Use Firecracker VMs with Docker images

#59

Earlier quoted context omitted.

What I want to know is how I read all these posts about starting VMs in … could be I'm stuck in Azure, but I feel like I get comparable times in GCP, too.

Wow, what OS are you booting? I used to run a “bare metal servers as a service” product, and we could provision most images to a bare metal server in under 5 minutes. If I had a VM take more than 60 seconds to come up today I’d suspect something was wrong.

Ubuntu. It's not the OS.

(Granted it's Arch, but my home laptop boots to a graphical desktop in ~13s. … our servers don't have to worry about X.)

Re: Ignite – Use Firecracker VMs with Docker images

#60
post #52

Earlier quoted context omitted.

> If you want to be able to migrate a running VM, do you still really need it to start super fast? Yes. "You" is two different people in this sentence. The person doing the migration is often not the person who owns whatever service is running in the VM. They have uncorrelated needs. As a platform operator, I want to migrate VMs to be able to balance load and evacuate dying hardware. As a service operator on that pla…

Just spawn a new VM on a hypervisor and delete the old VM on the hypervisor that is dying. You can also balance load this way.

Assume any suggestion starting with "just" is equally obvious to the operators as it is to you.

In this case, it would be helpful to start from the observation that live migration is non-negotiable, which immediately rules out any form of "turn it on then off again."

Post reply on HN