Rails on Fly.io Machines - looking for feedback

1

Current options:

  • Getting Started shows how you can get a Rails app up and running using fly launch and fly deploy.
  • Machine API shows how you can get the same app up and running using bundle add fly.io-rails and bin/rails deploy.
  • Terraform shows how you can get the same app up and running using bundle add fly.io-rails, bin/rails generate fly:terraform, and bin/rails deploy.

Key differences:

  • The first is on Nomad, the other two are on Machines.
  • The first handles Postgres. The other two handle Postgres, Redis, and
    Sqlite3.
  • The first and third allow you to specify a name, organization, and a
    region.
  • The first two have a number of scaling options, the third can handle
    arbitrary, heterogenous arrangements.

Not yet on the site is a third option:

bundle add fly.io-rails
bin/rails generate fly:app
bin/rails deploy

Key features:

  • --name, --org, and --region are optional parameters on the
    fly:app generator.
  • Setting secrets and adjusting the configuration can be done prior
    to the first deployment.

There also is a new file generated, config/fly.rb. Sample contents:

machine do
  cpus 1
  cpu_kind 'shared'
  memory_mb 256
end

sqlite3 do
  size 3
end

redis do
  plan "Free"
end

The first block is straightforward. These values will be used for subsequent deploys.

The next two blocks are currently only used for initial allocation, and effectively is currently moot as this is now being done by the fly:app generator.

Doing this earlier allows fly deploy to be used nearly interchangeably with bin/rails fly deploy. The most significant difference is that the former will ignore config/fly.rb, and the latter will revert the results of any fly scale calls.

Perhaps config/fly.rb isn’t needed at all. Or perhaps it could be extended to cover more complex configurations. If it doesn’t go away, perhaps this information can be folded into fly.toml instead.

Briefly mentioned above, but all of the options involving the fly.io-rails gem do considerably more tailoring of configuration files automatically when compared to flyctl launch. Ruby being a scripting language, particularly when coupled with ERB and Thor, makes running commands, invoking web APIs, and generating/customizing configuration files easy.

Everything currently being done by terraform could be done by Ruby. And everything Ruby can be done by flyctl/go. For now, the Ruby implementation enables rapid exploration.

I’m looking people to try these options with real applications and provide feedback.

2 Likes