I’m rebuilding some features since we need to migrate off of Apps v1, and it seems like the best way to do handle updating/changing regions/etc. is to
create new machines
wait for them to start
destroy the old machines
I’m noticing on the dashboard that the machines page for an app lists all of the destroyed machines, which made me wonder if there’s any issue with creating and destroying machines frequenly. Not that I’m expecting to do that much, but if there’s a bug in my app or something is failing, I could see it running through those 3 steps repeatedly.
This isn’t necessarily an issue, but generally you should be updating existing machines instead of deleting/recreating them. There might be a better way to do what you’re trying to do - what is your workflow right now with Apps v1?
Restarting - using the GraphQL API to restart the entire app (restarts all vms for me). I also use it to restart allocations individually in some cases first, before an entire app restart.
Changing image - GraphQL API to deploy a new image, seems to create new vms and then delete the old ones.
Scaling - GraphQL API to change scale, actually is just the same deploy image mutation I use above.
I thought that I read somewhere that an update for machines creates a new machine and destroys the old one under the hood so I thought that might be the same. Generally it’s just easier to wholesale create new and delete the old, rather than managing state with existing machines, but not thaaat much easier.
In Apps v1 (Nomad platform), any change destroys the entire VM state and creates a new one from scratch, including figuring out which node has enough capacity to host your VM (this is a Nomad limitation).
in Apps v2 (Machines platform), running updates recreates the runtime state of the VM (it creates a new machine version), but keeps some underlying internal data, which makes it faster and more reliable.
You can of course keep as many stopped machines as you want, in however many regions, and only start them when you need them. The Apps v2 version of “autoscaling” in fact relies on keeping around a number of machines which automatically get started and stopped as requests go up and down.