3 ms·

This 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

This 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 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.

claytongulick 4y ago
> 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-seconds https://codesandbox.io/post/how-we-clone-a-running-vm-in-2-s...
- sofixa 4y ago
  > Why not just make a base image and some simple setup scripts? That makes it possible for you to create an image (VM or container?, good start. But what Firecracker and containers solve is isolation and ease of distribution.
  - pjmlp 4y ago
    Just like VM repos used to be used....
    - solarkraft 4y ago
      Yup, but with good tooling. Maybe I'm missing something, but all traditional approaches I've seen for VM management treat them as pets, not cattle.
- imiric 4y ago
  > Why not just make a base image and some simple setup scripts? Two major reasons: - Reusing the vast availability of prebuilt OCI images. I don't need to create scripts at all if I find a good image someone already created a Dockerfile for. Dockerfiles are scripts anyway, especially tailored for provisioning. - Docker's main benefit is a friendly UI over low-level Linux primitives. In this case, Ignite offers a similarly familiar UI over Firecracker/KVM, which is also cumbersome to use directly.
- sneak 4y ago
  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.
  - withinboredom 4y ago
    So, wait. You’re saying the people who developed that squeeze juice thing or the drop of blood thing shouldn’t be criticized because it is obviously a stupid idea from the get-go? C’mon man, some of us have critical thinking skills and some of us will tell you when an idea is stupid or over-engineered. Containers as VMs is usually peak over-engineering. It’s unnecessary most of the time. In fact, there’s only a few use-cases where it’s desired to have that isolation: - different clock rates in the container than outside (deliberate skew) - high security applications - require certain kernel modules that you don’t want installed in all containers Isolation can already be guaranteed by the kernel (excepting some bugs), so I don’t think that is a valid use-case, but I could be wrong.
    - mbreese 4y ago
      Multi-tenant systems are also a use-case (and a pretty major one).
      - withinboredom 4y ago
        The kernel already guarantees isolation. Unless I missed the point of cgroups.
        detaro 4y ago
        "guarantees". cgroups are indeed designed for isolation, but they are a feature that's been added on over time and still exposes the entire kernel as attack surface. It's considered way less trustworthy than VMs, especially minimal-surface ones like Firecracker.

claytongulick 4y ago

> 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-seconds https://codesandbox.io/post/how-we-clone-a-running-vm-in-2-s...

sofixa 4y ago
> Why not just make a base image and some simple setup scripts? That makes it possible for you to create an image (VM or container?, good start. But what Firecracker and containers solve is isolation and ease of distribution.
- pjmlp 4y ago
  Just like VM repos used to be used....
  - solarkraft 4y ago
    Yup, but with good tooling. Maybe I'm missing something, but all traditional approaches I've seen for VM management treat them as pets, not cattle.
imiric 4y ago
> Why not just make a base image and some simple setup scripts? Two major reasons: - Reusing the vast availability of prebuilt OCI images. I don't need to create scripts at all if I find a good image someone already created a Dockerfile for. Dockerfiles are scripts anyway, especially tailored for provisioning. - Docker's main benefit is a friendly UI over low-level Linux primitives. In this case, Ignite offers a similarly familiar UI over Firecracker/KVM, which is also cumbersome to use directly.
sneak 4y ago
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.
- withinboredom 4y ago
  So, wait. You’re saying the people who developed that squeeze juice thing or the drop of blood thing shouldn’t be criticized because it is obviously a stupid idea from the get-go? C’mon man, some of us have critical thinking skills and some of us will tell you when an idea is stupid or over-engineered. Containers as VMs is usually peak over-engineering. It’s unnecessary most of the time. In fact, there’s only a few use-cases where it’s desired to have that isolation: - different clock rates in the container than outside (deliberate skew) - high security applications - require certain kernel modules that you don’t want installed in all containers Isolation can already be guaranteed by the kernel (excepting some bugs), so I don’t think that is a valid use-case, but I could be wrong.
  - mbreese 4y ago
    Multi-tenant systems are also a use-case (and a pretty major one).
    - withinboredom 4y ago
      The kernel already guarantees isolation. Unless I missed the point of cgroups.
      - detaro 4y ago
        "guarantees". cgroups are indeed designed for isolation, but they are a feature that's been added on over time and still exposes the entire kernel as attack surface. It's considered way less trustworthy than VMs, especially minimal-surface ones like Firecracker.