fly.toml is unnecessary for app deployment?

Questions / Help
1

I am trying to wrap my head around working with the Machines API.

It seems that, should I choose to work with the Machines API rather than using flyctl to launch and deploy an app, then fly.toml is no longer needed, because all configuration can happen via API calls.

Is this true? If I go the Machines route, I can safely ignore fly.toml and all this stuff?

2

Hey, that’s correct. flyctl reads your fly.toml and then calls the Machines API with the updates it needs to make (it’s open source!). If you call the Machines API yourself, you don’t need a fly.toml.

2 Likes
3

The same applies if you use the fly.io terraform provider.

1 Like
4

This was REALLY illuminating. (how fly deploy is just an API client for the machines API.)

I feel like I’m just 1 small step from being able to deploy all of my infrastructure on fly w/ terraform.

I think I’m blocked on the need for a pre-existing image to be available in the Machine resource though.

What I need is to be able to provide it a Dockerfile for that first deploy.

The cli offers: fly m run --dockerfile But the provider does not. (And I found: Build images · Issue #24 · fly-apps/terraform-provider-fly · GitHub where @DAlperin feels this is out of scope for the provider)

So perhaps I’m missing another approach, but this is blocking me for these use cases:

  1. I am deploying a grafana instance, but I need to configure it with a config file. So I can’t just deploy grafana/grafana-enterprise, I need a very simple dockerfile that will let me inject the config.

  2. I want to deploy one of my apps to a new environment. That would involve having my code repo available, including it’s dockerfile. so that I can deploy it pointing at the Dockerfile as well.

These use cases are very similar. The only real difference is that for grafana, since it won’t change much, I feel like it wouldn’t be arduous to generate that docker image and host it elsewhere, like hub.docker or something. But for my app, I’d really prefer that my images remain in the fly ecosystem. (Not to mention that I can’t build them on my M1 mac)

The sequence of events I assume I need is:

  1. create the app, or whatever resource also gives me a docker repository
  2. trigger a docker build using the remote builder
  3. deploy that image
5

Hi @belay

You can inject config files (or files from secrets) into machines. More details here - Machine Files

6

for use case 2: you can manually build/push images to our docker registry. login with fly auth docker command, or manually using x as the username and a Fly API token as the password.

if you can’t build the image locally, you can use this command, which also doesn’t need a fly.toml:

fly deploy -a appname --remote-only --build-only --push --image-label whateveryouwant

and then you get an image like registry.fly.io/appname:whateveryouwant.

7

Oh nice! It looks like this is not available in the tf provider for a machine, but I’m sure it’ll get there. very slick!

8

Ahhhh, excellent. Ok, so I can script something out that would terraform the app in one step, build the image using the cli, and then pick up w/ terraform for the rest from there.

And then after that, I can just utilize fly deploy as usual.

Good stuff, and that gets me the path I need. Thanks @lillian

9

I think there is a misunderstanding here, if you set up the app with terraform, you can’t fly deploy on top of it, because flyctl will not have a fly.toml nor will it recognise the existing machines as its own.

10

You can manage the entire app lifecycle via TF, but there are significant limitations:

  • Shared IPv4 need to be provisioned via the GraphQL API (e.g. sullivtr/graphql).
  • If you plan to use kreuzwerker/docker you’ll have to downgrade to 2.25.0 (unless you plan to keep the locally build image).
  • Volumes can no longer be managed via the fly_volume resource due to an API change. You’ll have to use Mastercard/restapi instead and provision via the machines API.
  • Fly_machine is fairly limited. It might make sense to skip it and use the REST API here as well.
  • When destroying a machine there’s a delay of up to a minute until a previously attached volume registers as released. You may need to introduce an artificial delay via hashicorp/time.
  • Terraform does not play well with the pg_tls handler at all, neither when using Postgres as state backend nor when provisioning via cyrilgdn/postgresql.

(We use Fly for multi-app preview environments where we frequently create and tear down apps.)

11

Ahhh, ok. That’ll be a blocker there then. Particularly having just read the post about how you’re intending to bake more and more intelligence into the ctl itself. Good to know, thanks!

12

Ahhh, very interesting. Had to look up those docker refs. Interesting workaround strategy. I think I’ll heed your warning for now though, and only use terraform for simple and largely static aspects of my infrastructure. Thanks for the heads up!

13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.