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.
Any help here would be much appreciated. thanks.
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:
I don’t know if something like Supercronic in a v2 (or v1) app would suit your needs for scheduling.
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.
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
fly deploy as well as
fly launch, to establish the app as a v2 one.
I flipped my organization to default to Apps v2 because I kept forgetting that flag.
fly orgs apps-v2 default-on <org-slug>
@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!
Ok thank you again to @MatthewIngwersen @rubys @catflydotio. I just wanted to follow up on this for others who might stumble upon this post.
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.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.