3 ms·
If you a cloud host, you need a way to sandbox hostile code. Firecracker allows you to do that (it is a configuration of the traditional KVM virtualization syst
by melony 5y ago
If you a cloud host, you need a way to sandbox hostile code. Firecracker allows you to do that (it is a configuration of the traditional KVM virtualization system except lighter and faster, instead of booting a VPS which can take minutes, you can now spawn one in under a second).
- FooBarWidget 5y agoNot just sandboxing, but just ensuring that each test runs in a clean environment, without interference from files/processes left behind by a previous or even concurrent test.
- wyldfire 5y agoTo clarify my post: I see the reason for Firecracker to exist in general, it's great. But does "e2e tests" include untrusted code? I think it really shouldn't. So why use firecracker here? Invoking your tests in a bare VM or container is great for making sure that you are controlling the environment and enumerating your system dependencies. But this post proposes discarding those things and instead using some saved state as the entry point into your Firecracker. So now you are booting from Your Image instead of a { Official Distro Image + Dependency Recipe }. It seems like a step backward.
- chrisseaton 5y ago> But does "e2e tests" include untrusted code? What other possible way could CI work?
- wyldfire 5y agoContinuous integration can -- and does -- happen with local development teams using their own equipment. In general, those are typically pretty trusting environments where Firecracker style isolation is not as critical.
- melony 5y agoThe company that wrote the article is a e2e testing cloud hosting company that runs your code in their cloud.
- wyldfire 5y agoAh, then that's actually a pretty compelling use case. Not a "here's how you can do it" so much as a "here's how we did it (and kept you customers safe from the baddies)".
- colinchartier 5y agoAuthor here! I think there's always been a push/pull of "fat base images" versus "install everything every time" - It's obviously subjective, but I think it's more important to run the tests on every commit than it is to start the environment from scratch. It's also not necessarily mutually exclusive, you could have a "staging branch" where you make something that looks a lot like production and then re-run end-to-end tests there, while running the per-branch tests with this method to avoid slowing down developers.