If there is a machine running in the “ams” region, and I switch to “nrt”, if i do fly deploy..., then the old machine in “ams” will still exist. I have to manually kill the ams machine, the relaunch fly deploy for the new machine in the new region to come alive.
Is this normal? Do i need to do something as part of my CI/CD pipeline such as shutting down machines? I would think it strange.
The Fly.io platform uses a mixture of declarative and imperative styles, and the outcomes of operations depend on config files, sequences of procedural flyctl commands, and heuristics based on the set of Machines that you already do have deployed. There isn’t a “one stop shop” where every aspect of your app gets declared, although many people do expect it to tend more in that direction (when starting out).
In a certain sense: it seems that users who hold strong opinions about how updates and scaling should occur in detail gravitate toward designing and assembling an orchestrator of their own—via the Machines API,. It’s not as daunting as it looks at first!
Short of that, I personally prefer fly m clone, fly m update, fly m destroy, etc., instead of trying to nudge the quasi-declarative parts into following my specific intent.