Declarative configuration

I’m still trying to figure this out myself.
I’m definitely not in the camp of yaml trickery (references and includes).

In the k8s world, kustomize is one solution to this problem, but I’m also not convinced it is the “right” one.

There are two things at play:

  1. Having everything about an app included in its configuration
  2. Elegant way of identifying what needs to change across environments

If there is a solution for 1), finding a solution for 2) is less of an immediate concern.

I’m happy with a bunch of hacks for 2) but 1) is something that would have to be solved by you guys (or terraform)

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.

Oooh! That’s interesting.

You have three places you can change configs with our API:

  1. Secrets
  2. Environment variables
  3. 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.

I want to change everything :slight_smile:

Based on the parameters of launchApp that means (in decreasing order of approximate importance):

  • image
  • config
  • secrets (perhaps via setSecrets?)
  • count (perhaps via setVmCount?)
  • vmSize (perhaps via setVmSize?)
  • scheduling
  • regions
  • volumes

I really, really want avoid scenarios where terraform might try to destroy/recreate one of my fly apps.

1 Like

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?

1 Like

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.

We can tweak that mutation. What makes sense to return?

In this case it might make sense to just indicate that:

  • it was/wasn’t a no-op (via some field)
  • created a release (along with some way to see the “current” state the release is trying to converge to)

How’s this looking? Still a “maybe this week” thing?

Yes I’m going to try to get it out tomorrow.

Did this ever get released? Excited to use it!

Not yet, it’s almost done though. I’ll @ you when there’s something to play with.

1 Like

Planning to work more on the terraform provider today. Anything early for me to experiment with?

Not yet unfortunately.

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.

Got it, best of luck with that journey!

Here’s the current thread of me trying to navigate the errors I’m seeing:

:zipper_mouth_face: but I’m dying inside to know what you’re building/using instead :nerd_face: