Ignite – Use Firecracker VMs with Docker images
1–10 of 84 posts
Re: Ignite – Use Firecracker VMs with Docker images
#2Related, My VM is Lighter (and Safer) than your Container (2017): https://news.ycombinator.com/item?id=32764501
Looks like Ignite could be the best of both worlds, use the network effect of Docker images but have them as a VM instead.
Re: Ignite – Use Firecracker VMs with Docker images
#3Related, My VM is Lighter (and Safer) than your Container (2017) : https://news.ycombinator.com/item?id=32764501 Looks like Ignite could be the best of both worlds, use the network effect of Docker images but have them as a VM instead.
I think lightweight VMs will have a major impact. VMs are powerful and solve legions of problems that arise trying to make containers match them, which is exactly the road currently being paved by so much of Kubernetes.
Firecracker has a number of limitations, however. Firecracker is tailored to the highly vertical 'lambda' use case and too much of the power of the kernel and userspace is stripped away. You can't even live migrate a firecracker VM right now.
So yes, VMs are great and will ultimately resurge to the detriment of 'everything is a container' serverless orchestration, but Firecracker in its current form won't cut it. A gulf exists between giant cloud operators and their lucrative 'serverless' (only) model and everyone else. Everyone else must avoid the insurmountable costs associated with abandoning the immense value that stateful VMs provide and the minute something emerges that delivers a seamless VM orchestration system it will skyrocket.
Re: Ignite – Use Firecracker VMs with Docker images
#4> Ignite makes Firecracker easy to use by adopting its developer experience from containers. With Ignite, you pick an OCI-compliant image (Docker image) that you want to run as a VM, and then just execute ignite run instead of docker run.
Damn, that's quite a sales pitch. Excited to follow along!
Re: Ignite – Use Firecracker VMs with Docker images
#5Related, My VM is Lighter (and Safer) than your Container (2017) : https://news.ycombinator.com/item?id=32764501 Looks like Ignite could be the best of both worlds, use the network effect of Docker images but have them as a VM instead.
I think lightweight VMs will have a major impact. VMs are powerful and solve legions of problems that arise trying to make containers match them, which is exactly the road currently being paved by so much of Kubernetes. Firecracker has a number of limitations, however. Firecracker is tailored to the highly vertical 'lambda' use case and too much of the power of the kernel and userspace is stripped away. You can't eve…
Which kernel powers are you specifically talking about having been stripped away, and how are they relevant to serverside workloads? GPUs are the common one that gets brought up, but I'm not familiar with many others. Firecracker doesn't strip anything out of the guest kernel --- it boots a vanilla Linux kernel, which can be as heavy or light as you compile it to be.
Re: Ignite – Use Firecracker VMs with Docker images
#6Related, My VM is Lighter (and Safer) than your Container (2017) : https://news.ycombinator.com/item?id=32764501 Looks like Ignite could be the best of both worlds, use the network effect of Docker images but have them as a VM instead.
I think lightweight VMs will have a major impact. VMs are powerful and solve legions of problems that arise trying to make containers match them, which is exactly the road currently being paved by so much of Kubernetes. Firecracker has a number of limitations, however. Firecracker is tailored to the highly vertical 'lambda' use case and too much of the power of the kernel and userspace is stripped away. You can't eve…
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 acceptable. If that’s the case, then you can use a different VM tech that supports migration (KVM/Xen/etc).
Re: Ignite – Use Firecracker VMs with Docker images
#7For 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 downsides).
Re: Ignite – Use Firecracker VMs with Docker images
#8This is a great idea and something I would love to use, but it's a lot less docker compatible and user friendly than it may seem.
For instance there is no way to automatically run the image's specified command, effectively leaving you with a dead VM: https://github.com/weaveworks/ignite/issues/874. You also simply can not share directories with the host (out of scope for Firecracker).
microVMs for running containers are definitely a great idea; another project aiming to do it (a little differently) is Kata Containers. It has a lot more industry support, can also run on Firecracker (though QEMU microVMs are just as good) and can (theoretically, I haven't gotten it to work) interact with many container runtimes that are not Docker (the focus appears to be on Kubernetes).
While more powerful, Kata Containers are also much, much more complicated (and honestly under- and misleadingly documented). Ignite could fill the role of something simpler and more easy to get started with. But please, if you aim to attract Docker users, actually make it compatible with Docker principles.
There's still a lot of unused potential in containers as VMs; Kata+Kubernetes probably currently realizes the most of it.
Re: Ignite – Use Firecracker VMs with Docker images
#9Earlier quoted context omitted.
I think lightweight VMs will have a major impact. VMs are powerful and solve legions of problems that arise trying to make containers match them, which is exactly the road currently being paved by so much of Kubernetes. Firecracker has a number of limitations, however. Firecracker is tailored to the highly vertical 'lambda' use case and too much of the power of the kernel and userspace is stripped away. You can't eve…
Which kernel powers are you specifically talking about having been stripped away, and how are they relevant to serverside workloads? GPUs are the common one that gets brought up, but I'm not familiar with many others. Firecracker doesn't strip anything out of the guest kernel --- it boots a vanilla Linux kernel, which can be as heavy or light as you compile it to be.
From https://firecracker-microvm.github.io/:
Firecracker is an alternative to QEMU that is purpose-built for running serverless
functions and containers safely and efficiently, and nothing more. Firecracker is
written in Rust, provides a minimal required device model to the guest operating
system while excluding non-essential functionality (only 5 emulated devices are
available: virtio-net, virtio-block, virtio-vsock, serial console, and a minimal
keyboard controller used only to stop the microVM). This, along with a streamlined
kernel loading process enables a Re: Ignite – Use Firecracker VMs with Docker images
#10Damn, 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.