What is the purpose of "fly launch" ?

,
1

While we were (and are) working on prepping fly launch for apps V2, the question of what is “fly launch”? was brought to attention in this issue comment.

The text below is an adaptation of the reply to that comment aiming to open the discussion to a wider audience:

What is “fly launch”?

CIting docs:

fly launch is an all-in-one tool that automates as much as possible between writing the code and deploying on Fly.io, setting you up with a running app with good defaults.

What is it good for? (a.k.a. Use cases)

  1. The user wants to deploy a hand crafted app to Fly.io for the first time.

    • has no idea about fly.toml, Dockerfile, or any other resource (ips, volumes) needed to run the app

  2. The user generates an app using a known framework (rails, nextjs, phoenix,…) and wants to deploy to Fly for the first time.

    • Same as previous case in term of non existent fly.toml
    • The framework may have generated a (in)valid Dockerfile
    • To support the Framework, the scanner may run scripts to generate local files (i.e. Phoenix scanner runs mix)

  3. The user found a fly-ready app (i.e. live_beats, wordpress-sqlite) and expects to launch a personal copy of it.

    • “fly-ready” meaning fly.toml and Dockerfile exists
    • Having to install a language development environment (phoenix, elixir, go, rails/ruby, …) is detrimental

Distilling above cases

Is it too simplistic to think in terms of these variables?

  1. Known framework?
  2. fly.toml exists?
  3. Dockerfile exists?
  4. Reusing an existing app?

In that case, and ignoring the point (4) for now, the combinations are:

  • Launch an app for known framework, no fly.toml nor Dockerfile.
  • Launch an app for known framework, no flytoml but existing Dockerfile
  • Launch an app for known framework, fly.toml and Dockerfile exists
  • Launch an app for known framework, fly.toml exists, no Dockerfile (weird case?)
  • Launch an app for unknown framework, no fly.toml, no Dockerfile
  • Launch an app for unknown framework, no fly.toml, Dockerfile exists
  • Launch an app for unknown framework, fly.toml and Dockerfile exists
  • Launch an app for unknown framework, fly.toml exists, no Dockerfile (weird again)

Notes:

  • If fly.toml exists but user decides to ignore it, it is like “no fly.toml” case
  • Rerunning fly launch will likely fall in the “fly.toml and Dockerfile” exists case
  • While I was writing the list realized it could be better expressed as a table.
  • Operations on existing resources (ips, volumes, certs, …) should be idempotent (do case by case analysis?)
  • Framework hooks that require language specific development environments are a problem for “fly-ready” apps.
  • Adding app services like databases (postgres, redis, …) should be an idempotent operation too
6 Likes
2

This post by @jsierles seems relevant https://community.fly.io/t/a-proposals-for-fly-launchers/2849

3

For what it’s worth I found the “launch” wording confusing and unclear how it relates to “deploy” or differs from it.

Maybe there is a better name or it might make sense to split what “launch” does into two (or more) different commands (e.g. for generating necessary config files based on the detected tech stack in the directory?).

(that would make it less of a fit for flashy demos though I guess)

1 Like
4

I got tripped up on this when I first started trying things out on Fly as well. Something like a fly scaffold command that only generates the fly.toml and Dockerfile, and then explaining that fly launch is just doing fly scaffold + fly deploy in one step would have made more sense to me. Everyone’s mental model is different though, so not sure if that would make things clearer for others.

I don’t think that’s a weird case. There are cases where the Dockerfile is not trivial to write or maintain, so having Fly do that for me (assuming it got it right :)) would be awesome, but where I would not find creating my own fly.toml, for example to add mounts/volumes, to be a burden.

1 Like
5

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