Feedback/requests from a Rails perspective: apps grouped with a shared deployment story, one-off apps/machines, and pipelines

[Brad]

I started working at Fly a few weeks ago with the initial goal of making Fly as easy (hopefully easier) than Heroku

@abe

The first is basically Heroku’s deployment strategy with Procfiles. With the Procfile, you can define your web worker which gets instrumented with the HTTP health checks, and background workers like sidekiq and a job drain (which don’t have these health checks), and they automatically share the same container image, and same environment variables. They essentially only vary on the ENTRYPOINT/CMD and the health checks.

Yeah, I love this about Heroku. Fly does it a bit differently with the processes directive in the fly.toml file and it’s kind of buried in the documentation. I recently documented it for Sidekiq at Sidekiq Background Workers · Fly Docs and Fly Launch configuration (fly.toml) · Fly Docs. There’s a few bugs that were just fixed with respect to multi-region scaling, so I’m going to update those docs.

@abe

I’d really like to mimic the Heroku experience of getting a live Rails console for an existing Rails app via something akin to heroku run rails console or heroku run bash.

Me too! I wrote some one-liners at Running Tasks & Consoles · Fly Docs, but I agree, it doesn’t feel as clean as running a console from a machine that’s not serving up traffic. I’m pushing for something like fly exec rails console internally, but I’m not sure yet where that will lead. I should probably open an issue for that on Github and get more community responses for the proposal.

@abe

I’ve seen the new Machines API mentioned on this forum as well as on HN as a potential solution to this, but after reading the blog post announcement, I’m not connecting the dots on how it does so (perhaps it will reveal itself to me in good time).

Machines is new and there’s going to be a LOT more use cases it opens up for everybody, including streamlining the ephemeral machine workflow.

@abe

The last nice-to-have would be something like Heroku Pipelines. What that is, to me, is basically a way to have separate environments, with different env vars, but that share the same container image.

I haven’t gotten this far yet, but I’m aware of Heroku’s Pipelines and want to write a guide on multiple environments on Fly. If this workflow is working for you pretty well, I may use it as the basis for this docs.

@abe

This is where I’m at now after having put a few solid days into using Fly. Please do let me know if I’ve made errors in my conclusions, and forgive me if some of this stuff is already mentioned elsewhere, but I wanted to provide a coherent narrative from my own POV as well.

Thank you for doing this! Your feedback is really helpful and will make Fly much better for future Rails developers. I never blame users, so if there’s anybody that needs to be forgiven its me for not having coherent docs for you (and others) to follow.

@abe

hopefully Fly can continue to improve its ergonomics and become a happy home for Rails developers

It will! Next week we’ll have two people working full-time on making Rails work great on Fly with an awesome Dev UX. You can expect a “more heroku like” experience over the next few months