VM Snapshot vs Volume Snapshot

Questions / Help
1

I’ve been porting applications over to fly, but I’ve been finding it more difficult to move non dockerized apps over.

I’m thinking of just spinning up a base image fly server and setting these non dockerized apps myself. But then I’m worried I won’t be able to scale these apps, and I could easily lose server config.

Is there a workflow for saving a snapshot of a VM and then spinning up a new VM from a snapshot? That would make me feel a lot less nervous about “manually” configuring servers.

Apologies if I missed this, but when I search for snapshots and restoring it seems to always focus on volume snapshots and DB restores. But I am just interested in general VM snapshots.

2

Also just wanted to bump this Different statics paths for different domains? - Questions / Help - Fly.io

3

We don’t have any VM snapshot features yet. Hopefully sometime this year! The first hack is going to make it very fast to resume a machine, though. Creating entirely new machines from snapshots is more complicated. We may never ship that (we’ll see!)

For what you’re doing, I think you may be better off with Docker tooling. If I understand right, you want to start with an image, shell into it, then run a bunch of commands to make it work like a non-dockerized system.

The docker commit command will create an image from a container. Which means you can start from scratch with something like this:

docker run --name my-custom-image debian:stable-slim /bin/bash

Then run all the commands you want. Then exit. Then you can run:

docker stop my-custom-image
flyctl auth docker
docker commit my-custom-image registry.fly.io/my-app:build-1234
docker push registry.fly.io/my-app:build-1234

Does that do what you need?

The caveat here is that you need to be running x86 Docker. If you’re running Docker on an m1 Mac, this won’t produce a Docker image you can run on Fly.

5 Likes
4

That’s a great solution!

5

Hi, @kurt! You wrote that 8 months ago. Do you think that’s still feasible for some time in the next 4 months, or have other priorities bumped it since then?

Also, do you have a sense for what the API for this will be? Currently, the way a machine stops is by the Docker entrypoint process exiting. In the case of a pause/resume feature, will that also be the case, or is the idea that that process keeps running and there’ll be some other way for the machine to signal when it would like to be paused? For what it’s worth, I think the best developer experience would be if fly.toml could specify an idle timeout and if Fly itself then paused the machine (basically, an autoscale to 0 feature for apps v2).