3 ms·
The build executes untrusted code and temporarily authenticates with your fly.io and Heroku accounts, so we need a sandbox for isolation. Our Elixir app launche
by michaeldwan 5y ago
The build executes untrusted code and temporarily authenticates with your fly.io and Heroku accounts, so we need a sandbox for isolation. Our Elixir app launches ephemeral VMs using our Machines API so it can offload that can of worms.
- mwcampbell 5y agoAh, makes sense. Have you folks considered open-sourcing that Elixir app? It would be instructive as an example of how to start a potentially long-running one-off task with the Machines API and monitor its progress. Edit: Also, I'm just generally curious about the Machines API; it doesn't seem to be documented (yet). The blog post mentioned that launching the VM takes about 2 seconds. Is this startup time proportional to the size of the container image?
- michaeldwan 5y agoIt's unlikely we'll open source the Elixir app, most of it isn't that interesting. But extracting the machine code into an example app is a good idea! Until then, here's a prototype go proxy that launches suspended machines when requests come in: https://github.com/superfly/machine-proxy https://github.com/superfly/machine-proxy We'll be baking that into our proxy soon so we can handle lambda-type workloads. Image size impacts the cold startup time since it gets fetched and converted into a rootfs before launching. Caching speeds up subsequent launches. Once a machines is created, it can be stopped and resumed, which is _much_ faster. I don't remember the numbers, but it's in the several hundred ms range. We'll have more to share soon.