Hello - I have a workload that needs to run twice a day on a schedule. The machines api seems to be a good fit for this as it supports schedules. I have used machines for one other service and my experience so far has left me feeling like i am doing it wrong. Here is my flow:
Create the app with fly apps create --machines
Create/run the machine with fly machine run
Update the machine with fly machine update
I realize machines or v2 apps is still in early phases but the above has been somewhat awkward. Running separate run/update commands is not great and i have to look up the machine id every time i want to update. Also I am not using a config file so i am basically just keeping track of the run/updates commands as i go. Again, not great.
I guess what i am looking for is more of a fly apps v1 experience. A single deploy command that creates/updates and an infrastructure-as-code style config file like fly.toml. Just poking around it seems like this might be possible and i am just being dumb. For example, the fly machine commands do accept a config arg but its not quite clear to me what this config is. is it just a machine flavored fly.toml? Also, fly deploy has a --force-machines arg which, again, makes it seem like i could use this to deploy machines somehow.
Hi @joelsbrown1, it looks to me like you’re doing it right, for what you want to accomplish. The machines commands give you direct control; one step simpler than using the Machines API. I don’t think we’re at the point where you can feed fly machines run a config through a file.
You can test out v2 apps to deploy and manage Machines much in the same way as for v1 apps:
Here’s a fun possibility. Right now you can’t schedule machines in an app straight from the config file.
But you can launch a v2 app from a config file with fly launch --force-machines, then do fly machine update just to add the schedule to the machine.
Once the app’s launched, subsequent fly deploy commands will update all machines according to the config in your TOML config file. It sounds like this would save you your fly m runs and some work on fly m updates.
After each fly deploy you’d (I think) have to run fly machine update to add back the schedule.
You can also use process groups to add a machine to a v2 app just for a periodic or background job. The Apps v2 doc for this is in flux because fly deploy has become smarter about populating process groups with machines.
@catflydotio Right on. Thank you for the response. I will mess around with this and see what i can come up with. Do i still need to install the pre-release version of flyctl for any of this?
No need for a prerelease anymore, latest release works. I should mention that, at least for the first deployment, you need to use --force-machines with fly deploy as well as fly launch, to establish the app as a v2 one.
@joelsbrown1 FYI, we just released flyctl v0.0.496, which adds a --select flag to machines commands that operate on machine IDs. It lets you choose the machine(s) you want interactively from a list rather than copy-and-pasting the IDs. Might make some of what you’re doing a little easier!
Firstly, what i ended up doing was creating a v2 app and then internally running a cron job in the app to execute my workload twice a day. Not really exciting and could have been done with a v1 app as well. In the end the added complexity of maintaining the schedule via the fly machine api was not worth the couple bucks this would have saved me.
More importantly though, I believe this whole exercise helped me put together better mental model of the fly.io ecosystem. The important takeways for me is that machines can be orchestrated (to some extent) at the app level, and imo, this is the most straightforward approach for deploying services. If you need more fine grained control only then drop down to doing things with fly machines or the machines REST API.