What’s the recommended way to update an app with new configs?
Context: I’m experimenting with writing a terraform provider for fly based on the GraphQL API and now I’m trying to figure out how “updates” to a fly app should be plumbed through.
You have three places you can change configs with our API:
Secrets
Environment variables
The image itself
Depending on what you’re trying to update, secrets and env vars can do a lot! Changes to these restart VMs. You could go as far as having settings URL in the env vars that gets pulled down at boot time.
Updating images is also very powerful though. If Terraform is consuming flyctl, you can make in place file modifications and build + deploy the image. Repeated builds should cache layers and be very fast.
If you really want to go bonkers, you can connect to running VMs with SSH and do stuff that way. Maybe fun, probably not super userful.
Oh I see what you’re asking! @jerome or @michael can pop in here with better options than I have, ultimately we’d like you to be able to run all those mutations as one “transaction”.
Right now, you can do image/config/secrets with deployImage and it’s reasonably transactional.
The others are individual, isolated calls.
What you’re doing is important and we might be able to expose one mutation to update all of that in one go. We have a “launch” mutation that’ll take most of that for initial app create, we could apply some of those rules to updates as well.
Yes, I just got the create (and delete) bit working via launchApp (and deleteApp).
I’m over in this issue trying to improve the debugging experience for GraphQL + Terraform.
In the meantime I’ll take a closer look at deployImage. At first glance it looks like I need services and/or definition. Can I just pass in the JSON version of my fly.toml to definition?
deployImage is what you want now. The config json goes into definition, services is deprecated in favor of services in the config.
I’ve also wanted a single mutation, like deploy, that takes image, config, secrets, counts, size, etc and applies everything in a single deployment. Volumes should use the existing volume mutations since they are individually addressable objects off the app rather than a point-in-time configuration linked to a deployment. Same for certificates and IP addresses.
I can hack this together for you, but it’ll probably be next week.
Following up on my adventure here, it seems that setSecrets does not like to be invoked if there are no secrets to change. It will return an error. This is perhaps reasonable, but means it is a bad fit for use with this terraform kludge I’m assembling.
Some context… a new mutation that accepts declarative configuration is more involved than I thought because of the way we create releases. Right now, changing the image, config, secrets, regions, vm size, etc each individually alter the app spec and deploy. Merging those into one operation technically works, but breaks release commands in the process. Good news is we’re revamping the release code and app config in order to support multiple process types per app, like web and worker. The new mutation I mentioned is how we’ll deploy all apps going forward once launched. We’re currently working on this and should have an update in a few weeks.
I’ve been trying to get this working by hand with the existing graphql API and I’m doing something very wrong. I keep wedging the entire application beyond repair. I probably need to rethink my entire approach. This set of changes isn’t almost ready is it?
It’s not. Don’t tell, because this isn’t public yet, but we’re working to replace Nomad (we’re very far out of Nomad’s sweet spot these days). We opted to wait on some of these things because we don’t want to build them twice.
Please do post your GraphQL adventures in another topic, though, we can absolutely help you get them working.