We currently only support the following for schedule, "monthly", "weekly", "daily", "hourly". This is calculated from the time of machine creation, so the machine will not start at a specific time i.e. on the hour, every wednesday etc
A scheduled machine can be monitored via the UI and the by running fly machine status. Do note, that a schedule machine when created will start in a stopped state and move to a started state at every scheduled interval.
I’d like to try this out! I’ve got a deployed machine (currently stopped, I can start it manually) whose status I can interrogate using fly machine status [machine id]. However when I run fly machine run —schedule=daily [image from status command] I get an auth error: Error Authentication required to access image "docker.io/library/[name:deployment...]". What am I doing wrong? I should add that I’m using an image built using a local Dockerfile.
# (typing these from memory...)
# for machines, I use:
flyctl deploy --local-only --dockerfile <path/to/file> --config <path/to/machines.toml>
# or, build the img and push it to Fly without deploying
flyctl deploy --local-only --build-only --push --dockerfile <path/to/file> -a <app-name>
# create a machine with the img
flyctl m run <registry.fly.io/app-name:img-tag> --schedule=daily --region <r> --name <uniq-name>
Ahh, yep the second option worked – looks like I’ve got a new machine using the pushed image, and the --schedule switch was accepted, so I’ll find out if it runs sometime tomorrow.
So what’s the best approach to deploying updated images? It seems like you can’t / aren’t supposed to update machines with new images – just stopping it if necessary and removing it and creating a new one is preferred? How does that integrate with e.g. Github actions? If I understand correctly, I’d want to:
push the new image
deploy a new machine using the new ID
destroy the existing machine if the deploy is successful.
However for step 2 you’d need the image ID you just created, and for step 3 you’d need the current machine ID.
The best practice is to use the GraphQL APIs which are more mature (even if as inconsistent) over flyctl m commands.
I prefer flyctl and I have requested that Fly engs pls:
Fix the existing flyctl m update <existing-machine-id> --dockerfile </path/to/file> --config </path/to/machines.toml> command.
Support the --image switch like so, flyctl m update <existing-machine-id> --image <img> --config </path/to/machines.toml>.
It’d also be neat if flyctl m run <img> --name <existing-machine-name> --config </path/to/machines.toml> could deploy to an existing machine. But it doesn’t.
You could destroy machines and create new ones, if that’s what you prefer, or flyctl deploy --image <img> --now --strategy immediate --config </path/to/machines.toml> to deploy the img to all machine VMs of the app (as defined in machines.toml).
It is just your regular fly.toml but within limits (as Machines don’t yet support all configurations options that a regular App does). While flyctl m commands have limitations of their own, as it’s pretty raw and new.
I may have confused matters yesterday (or maybe some changes happened at the backend)? In any case: when a new app image is deployed using flyctl deploy --remote-only, that new image is assigned to any running machines, but their env and schedule entries are wiped.
You should be able to repro this by running fly m status [id] -d before and after a deploy. The image assigned to the machines is the same as you see if you run fly image show. Creating a new machine with fly machine run --env=… --schedule=… registry.fly.io/[image_id] --region=… shows the expected env and schedule entries when running fly m status [id] -d, and I can confirm that the scheduler is working.
It is totally possible that flyctl deploy wipes off schedule; I haven’t see if wipe off envs though (I set them in the dockerfile with the ENV directive and in the [env] section of the .toml file and these have been re-applied across deploys and runs, just fine): Bug : During Development of Machine Manager - #9 by tvdfly
For scheduled machines, it could very well be that only flyctl m run is supported. And so you were right: One would have to remove the existing machine and run a new one just to update the docker-image (iff using flyctl), since flyctl m update is broken.
If this PR is merged flyctl m update <machine-id> --image <new-image> -a <machine-app> ... should carry forward the existingschedule unless overriden with the --schedule switch (which, per my reading of the code, flyctl m update already supports).
Thank you for this feature. I’m currently migrating a few Heroku apps to fly that require this. Can you provide an example on how to run a single Rake task with a schedule machine? I’m not sure I totally understand how to set it up.
Would it be possible to update the documentation at Machines · Fly Docs or add a new document for this kind of stuff, especially with some basic examples (both docker & non-docker)? I had to look at multiple forum posts and the above documentation to get even a basic machine working.
Is there a way I can view my machine’s schedule status? I updated an existing machine to be scheduled hourly, but I can’t see anything in the dashboard to suggest that it will actually execute hourly, and is in state “stopped”. Logs are cleared each time I re-visit the monitor page, so I don’t know how to view it except keeping the monitor page open for an hour. I am supposed to start the machine again after setting a schedule?
$ dotenv -- bash -c 'fly machines update $MACHINE_ID --schedule=hourly -a $MACHINES_APP_ID'
Update available 0.0.424 -> v0.0.431.
Run "flyctl version update" to upgrade.
Machine 73d8d347b13789 was found and is currently in a stopped state, attempting to update...
Searching for image 'registry.fly.io/lightsats-scheduler:deployment-01GHZVBM4562H5W7D5BXA373BC' remotely...
image found: img_19gm46eq92kvx0jk
Image size: 150 MB
Machine 73d8d347b13789 has been updated
Instance ID has been updated:
01GHZVEDNBTKTKXGPNE5J0DV1R -> 01GHZVFBKKKQ5ETFXZ3Q3ZAJYT
Monitor machine status here:
Done in 4.30s.