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…
Ignite – Use Firecracker VMs with Docker images
51–60 of 84 posts
Re: Ignite – Use Firecracker VMs with Docker images
#52Earlier 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…
Re: Ignite – Use Firecracker VMs with Docker images
#53Earlier 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.
Re: Ignite – Use Firecracker VMs with Docker images
#54- My app per the Dockerfile
- Container
- Firecracker VM
Or:
- My app per the Dockerfile
- Firecracker VM
Thanks!
Re: Ignite – Use Firecracker VMs with Docker images
#55Looks abandoned for a year at least ...
Re: Ignite – Use Firecracker VMs with Docker images
#56Damn, 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.
Re: Ignite – Use Firecracker VMs with Docker images
#57Earlier 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…
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
#58Earlier 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…
Re: Ignite – Use Firecracker VMs with Docker images
#59Earlier 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.
(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
#60Earlier 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.
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."