I am developing an application that results in long running web-socket connections ~30 minutes, and it would be good for those machines to stay running - transferring connections is gonna end up with bad user experience in case the frontend has also been updated. (The binary already stop itself on being idle).
Reading Deploy a Fly App · Fly Docs I am unsure if this fits any of these strategies. Or would some combination of cli commands potentially achieve the same effect ?
I believe your app needs to be able to tell the fly deployment, that it has still a running connection, and it should not deploy. I don’t think that this is possible, and the closest solution would be a bluegreen deployment.
@aravindcc For a bespoke deployment process like this, your best bet is probably to directly use the Machines API.
You could create new machines to mirror the existing ones, but with your new image. You’d need some app-level logic to redirect new incoming connections from the old Machines to the new ones. Then once you’re confident that all websocket connections to your old Machines have been closed, you can destroy the old machines.
If you’re using the Machines API directly, you’re going to have to deal with more stuff from which flyctl would otherwise abstract you (see the warning at the bottom of the linked docs page).
This is quite involved but it is possible!
Ok thanks for directing me to this !
Would the following work ?
fly deploy --build-only --pushfly machine run [new-image-name]fly machine cordon the old running machine idsMy understanding of cordon is it will stop the proxy directing new connections (- and then my app exits anyway once it becomes idle / no new connections) ?
My only concern is how the autoscaling based on concurrent users work - how would the new image be used ?
Yes I think those steps should work!
Only additional thing to mention is that whilst your old machines might go into a stopped state because they’re not receiving new connections, you’ll probably still want to delete them at some point otherwise you’re going to have a lot of stale machines hanging around.
Not quite sure what you mean here. We don’t autoscale apps, by which I mean we don’t create or destroy machines for an app automatically. Scaling in this way is left to the user.
We do have auto_stop_machines, auto_start_machines and min_machines_running (see Automatically stop and start Machines · Fly Docs), but these config options work with the number of machines you setup.
If you want autoscaling logic you’d have to implement that at the app level. There’s some discussion on autoscaling in these threads:
Ahh I see I was getting confused with fly automatically creating new machines when the soft_limit is achieve instead it starts any stopped machines.
Thanks for your help and info !
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.