Does anyone know if there is a way to access a volume directly(to transfer files to it)? I saw this thread, but that seems to rely on there already being a VM active to SSH into.
2 Likes
As in, spin up volumes but not attach it to a VM and then be able to S/FTP to it…?
The closest one can get to such a setup is with volumes attached to on-demand VMs (viz. Apps v2 / Fly Machines). These Machines / VMs only spin up when there’s a request to be served (fly ssh console, for example) and then it is left up to the Machine’s / VM’s entrypoint process to determine when it must quit (docs).
Ok, that’s not insurmountable, but it is pretty annoying. My app is a standard VM that requires the files to be available to it to start. I can deploy a temporary version of it that allows me to bootstrap it, but it is just a tad irritating that I’m not able to generate them locally and them transfer them directly(without any extra VMs).
How big is your docker image, currently? If the files aren’t anything too huge (think 4GB or less) you can consider bundling them up in the docker image itself; ref: Read-only database: Docker vs Volume - #2 by ignoramous
Otherwise, you’ll need to download the files from elsewhere, like S3 or some such.
The files are config-related, so I was hoping that I would be able to not have to bundle them directly into the image(and to be honest, I’m not 100% sure that they are read-only), but that is an idea.
1 Like
On the other side, you get config-as-code if you do bundle it with the docker image…
Gotcha. You could opt to store in an external store like DynamoDB or Workers KV. Fly does have a KV store in Fly-managed Uptash Redis, and your usecase may be covered by its free tier. Lastly, it isn’t a KV store, but another Fly-specific alternative would be deploy (and maintain) LifeFS (docs).
Experimental Consul support is also available to Fly apps that one may (ab)use to store configs… (though I haven’t see any one recommend it on here).