The New Launch (Preview)

Fresh Produce
1

Hi! We’ve been making a lot of changes lately, but one thing that’s stayed pretty much the same is the fly launch command. As we’ve added more features to our platform, the UX of the launch command has gotten a little bit out of hand with its barrage of questions on the CLI. It’s not a great experience, especially if you’re just trying to learn how to use us.

We’re working on something to fix that.

Screenshot of the terminal output of 'fly launch --ui'. It lists the default config for the app, and asks the user if they would like to change it before continuing.
Screenshot of the terminal output of 'fly launch --ui'. It lists the default config for the app, and asks the user if they would like to change it before continuing.893×322 62.5 KB

The new launch provides nice sensible defaults, tailored to the app you’re launching (for example, if we detect a Rails app, we should default to Postgres unless the MySQL gem is present). Here’s the surprising part: naturally, you’re given the choice to change these defaults. If you do, we open a web browser.

The pile-o-forms we had for launch just isn’t working. In like 99% of cases, a CLI works great for interfacing with fly.io, but this was a bit of information overload, it was impossible to undo, and it’s just not easy to navigate. Instead, we give you a web page with nice inputs for everything, and then you can submit that to return to the CLI. It’s very slick, but far more importantly, it’s much easier to work with.

Screenshot of Fly Launch web UI. there are visible fields for the app name, organization, region, and port
Screenshot of Fly Launch web UI. there are visible fields for the app name, organization, region, and port974×689 56.8 KB

Don’t just take our word for it, though. It’s available right now, as fly launch --ui! This is currently a preview phase - it’s not completely finished (it could use a final layer of UI polish, and provisioning databases & extensions isn’t 100% there yet), but we plan on replacing the existing launch with the new launch soon.

So, please try this out, and let us know if you have any comments or concerns!

14 Likes
2

This is a great start, love this. I really mean it, this would of reduced the intimidation factor a little when starting fly.io, and also looks really splashy.

Once your more use to fly though, I find the fly.toml kinda like cloudformation or other infrastructure as code, except when it’s not.

For example, for a new app, I almost want to skip fly launch and just build out the fly.toml, and have a section that does some inits that let me avoid the the CLI and gives me something that can be checked in, or shared.

Basically, I get the above for new users on fly, or even one off projects. But once you get use too it, I would prefer something like below - as it’s more configuration as code, and would be faster than creating volume, deploying, then setting set vm (wait for restart), memory (wait for restart), clone in same region, clone in other regions.

I know you can pass params to init the initial when deploying, but it does not work well with process groups. And I have to lookup the flags every time, because I can’t commit it to the repo, or another repo like infra as code.

Something like a init section, that only fires on initial deploy when creating the app, or when reset by CLI (fly reset init) with confirmation (y/n) prompt.

[init]
  [[init.volume]]
    # source would be needed if machines can ever have more than 1 volume
    # otherwise can be inferred by [mounts] section
    size =  3
    process = ["app"] # not required unless process group

  [[init.vm]]
    size = "shared-cpu-1x"
    memory = 1024 # optional - defaulted from size
    # or optionally replace size with cpu and kind
    # cpu = 2
    # kind = "shared" or "performance"
    process = ["app"] # not required unless process group

  [[init.scale]]
    process = ["app"] # not required unless process group
    [[init.scale.regions]]
        region = "ord"
        count = 2
    [[init.scale.regions]]
        region = "ewr"
        count = 1
    [[init.scale.regions]]
        region = "lax"
        count = 1

I can see this helping enterprises and startups with pipelines and approval processes. For example, an audit (automated or manual), could be done on the requested count of apps when the file is making its way through CI/CD approval and release approval.

I love the CLI for hobby purposes, and DevOps. But being able to reset the init, and adjust my scaling (horizontal or vertical) with a large deploy would be great without having to make these changes to each active machine. Sometimes you can’t scale down to 1 to make the changes, and then clone back.

2 Likes
3

There are, ultimately, some things that you can’t do initially (such as setting machine scale for different groups). But for 90% of uses, you can have a template fly.toml, and pass any overrides from the defaults on the command line. What specifically gives you trouble when using this workflow?

What can you not commit?
If I were solving what it sounds like your problem is, I’d have a template fly.toml file, and a shell script that I can call with a name parameter to provision my apps for me.
(it’s entirely possible I’ve misunderstood your problem, though)

Alternatively, you could have a shell script that calls fly apps create, then fly m run ... to manually create every machine to an exact specification.
If you specify --metadata fly_platform_version=v2 --metadata fly_process_group=foo, they can even be fly deployed to.
This option is a lot of work, but it gives you total control over everything.

4

You are right, you can put it in a shell script. I think my point is just that other Infra as Code have scale/size and provisioning as part of it, in addition to settings for ports, permissions, acls, etc.

It just seems like a gap that would simplify things.

I didn’t know about the --metadata fly_process_group=foo that is helpful.

I think a shell script with a lot of verbose fly commands can be somewhat hard to follow imho. But it would be a fine workaround.

2 Likes
5

tbh, I can’t recall the last time I upgraded flyctl on my pc… A changelog of breakages and experimental features, so that I can make an informed decision on both the upgrade and individual commands (and their switches) would be nice.

As one example, flyctl recently switched to staggered group deployment for rolling startegy (which previously, deployed one by one) and there was no announcement. I mean, I like it, but if for some reason, if my prod workflow relied on machines restarting one after the other, I’d be in deep pickle.

2 Likes
6

They also broke the option for one by one rolling deploys without warning either.
You could use --strategy-batch false but suddenly that disappeared in 0.1.72 and it wasn’t until 2 days later in 0.1.75 that --max-unavailable become available.

3 Likes
7

@charsleysa and @ignoramous

Sorry to hear about your troubles with the CLI. I’ve bought up your concerns with our team and we’ll keep them in mind moving forward.

If you do decide to upgrade, let us know what you think of the feature. We’re excited for what it might do to help some of our new users get familiar with the platform.

2 Likes
8

Hi! Just wanted to say that we’ve stabilized around max-unavailable being the canonical way to say that you want a true one-by-one deploy, and that you can now specify it in your fly.toml like this:

[deploy]
    strategy = "rolling"
    max_unavailable = 1

I just remembered reading this a while ago, and thought that this change might be helpful for you, this way your deploys succeeding aren’t dependent on CLI flags.

3 Likes