Update fly launch to latest generated files for Rails app

1

We have a rails app that was fly launch a year or so ago, and it seems things have changed a bit since then. We are currently experiencing fly deploy not running migrations.

This made me think, how can I update my fly setup / dockerfile, etc. to the most modern way that the fly launch script would set things up today.

For instance: bin/rails generate dockerfile wont even run.

╰─ bin/rails generate dockerfile
Could not find generator 'dockerfile'.
Run `bin/rails generate --help` for more options.

How can we simply update our fly setups with fly launch without creating a new fly app?

2

Try:

bundle add dockerfile-rails --optimistic --group development

More information here: GitHub - fly-apps/dockerfile-rails: Provides a Rails generator to produce Dockerfiles and related files.

3

Ah, that makes sense. Yes, that worked!

As for the lib/tasks/fly.rake - I noticed a newer fly app no longer has this file, is that needed?

I am just confused to how we can get an existing fly app to the latest fly deploy setup, is there a way that the flyctl will automatically perform this? I would like to basically run the fly launch command as it would run today in the latest release of the flyctl to know that my fly setup is matched to the latest standards.

4

lib/tasks/fly.rake is no longer needed.

If you want to get to the latest deploy setup, remove all lines in your fly.toml that you didn’t personally put in there with the exception of:

app = ...
primary_region = ...

Then add the following:

console_command = '/rails/bin/rails console'

[build]

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
  processes = ['app']

[[vm]]
  memory = '1gb'
  cpu_kind = 'shared'
  cpus = 1

[[statics]]
  guest_path = '/rails/public'
  url_prefix = '/'

And finally, run bin/rails generate dockerfile again. Feel free to adjust the [[vm]] section to match your usage.

5

Got it, so there really isn’t a way to just rely on the flyctl to do an upgrade?

Also, the reason I was confused about the fly.rake file is that its referenced here still:

Thanks @rubys

6

Unfortunately, no. It defaults to trying to preserve the [possibly hand crafted] configuration. An in your case, I assume you wanted to keep the application, ip address, databases, etc; you just wanted to modernize your dockerfile and associated files. dockerfile-rails will do all of this for nearly everything, but it will only add to your fly.toml. Pruning is something you still have to do manually.

Thanks! Fixed.

1 Like
7

I am confused, I was under the impression that the docker-entrypoint file is what runs the rails db:prepare command, but this is saying we should also have this added to the fly.toml file.

@rubys Can you better clarify this?

8

I’ll give a longer explanation here, and then work to get a shorter version into the docs.

The Dockerfile that dockerfile-rails produces closely matches the one that Rails 7.1 and later produce (I contributed heavily to both and try to keep them in sync). The Dockerfile Rails produces does the db:prepare in docker-entrypoint. This is suboptimal if you are using a database like Postgres (which runs in a separate machine or set of machines) and your app has multiple machines (highly recommended for availability reasons, and it is fine if you have them set to auto stop).

The reason this is suboptimal is that it will run each time one of your machine starts, and delay that machine’s processing of requests. If you have two or more machines, it will run on each machine even though it only needs to run once. Even if you have only one machine, if that machine is set to auto stop it will run every time that machine is restarted, even though nothing has changed in the schema.

Rails’s choice is arguably the right one for Rails. Even if suboptimal, providing something that will work for everybody as a starting point is a good strategy. Optimize later.

For many cloud platforms (including fly.io) and a database like Postgres, there is a better choice. With two lines in your fly.toml you can have the migration run exactly once per deployment: Fly Launch configuration (fly.toml) · Fly Docs .

dockerfile-rails supports this with a --no-prepare option: GitHub - fly-apps/dockerfile-rails: Provides a Rails generator to produce Dockerfiles and related files. . dockerfile-rails also remembers what options you specified so that it can be re-run later when your application changes (example: you update to a new version of Ruby) and will reapply your choices.

1 Like
9

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