Rails launch improvements (dockerfile-rails@1.6.7 w/ flyctl@0.2.22)

  • Add support for thruster.

    While fly.io already has HTTP/2 support, SSL certificate management,
    and HTTP caching of public assests, there may be value in the
    X-Sendfile support and compression that thruster provides.

    This support is automatically enabled if the thruster gem is
    detected in your Gemfile. It also can be selected as an option
    when generating a dockerfile:

    bin/rails generate dockerfile --thruster
    

    Thruster is scheduled to be included by default in Rails 8, but there is no need to wait, you can use it now.

  • No longer defaults to PostgreSQL for applications that
    have Dockerfiles unless the Dockerfile installs the necessary
    support.

    The problem solved here is we won’t update the Dockerfile
    unless you ask for it, so the initial deploy will fail if
    we include PostgreSQL. So with the change the default for
    Rails applications is Sqlite3, and we will allocate a volume
    and place the database there.

    If you want PostgreSQL, you can update your Dockerfile with the following
    command:

    bin/rails generate dockerfile --postgresql
    
  • When file permissions prohibit installing a new gem, proceed without installing the dockerfile generator or configuring fly.toml if a Dockerfile exists.

    This change enables fly launch to degrade gracefully rather than
    failing. In such cases it is recommended that the dockerfile
    generator is installed manually and run. You can do this using
    the following commands:

    bundle add dockerfile-rails --optimistic --group development
    bin/rails generate dockerfile
    
2 Likes

I can’t get thruster to work. I updated the ports in fly.toml to 80, but then I get this:

2024-09-27T09:05:07Z app[4d89626bee5128] fra [info] INFO Preparing to run: `/rails/bin/docker-entrypoint ./bin/thrust ./bin/rails server` as 1000
2024-09-27T09:05:07Z app[4d89626bee5128] fra [info] INFO [fly api proxy] listening at /.fly/api
2024-09-27T09:05:07Z app[4d89626bee5128] fra [info]2024/09/27 09:05:07 INFO SSH listening listen_address=[fdaa:0:c61d:a7b:cbb7:64a0:b6ee:2]:22 dns_server=[fdaa::3]:53
2024-09-27T09:05:07Z runner[4d89626bee5128] fra [info]Machine created and started in 3.633s
2024-09-27T09:05:08Z app[4d89626bee5128] fra [info]{"time":"2024-09-27T09:05:08.635895771Z","level":"DEBUG","msg":"No custom 502 page found","path":"./public/502.html"}
2024-09-27T09:05:08Z app[4d89626bee5128] fra [info]{"time":"2024-09-27T09:05:08.636404222Z","level":"INFO","msg":"Server started","http":":80"}
2024-09-27T09:05:08Z health[4d89626bee5128] fra [error]Health check on port 80 has failed. Your app is not responding properly.
2024-09-27T09:05:11Z app[4d89626bee5128] fra [info]=> Booting Puma
2024-09-27T09:05:11Z app[4d89626bee5128] fra [info]=> Rails 8.0.0.beta1 application starting in production
2024-09-27T09:05:11Z app[4d89626bee5128] fra [info]=> Run `bin/rails server --help` for more startup options
2024-09-27T09:05:15Z app[4d89626bee5128] fra [info]Puma starting in single mode...
2024-09-27T09:05:15Z app[4d89626bee5128] fra [info]* Puma version: 6.4.3 (ruby 3.3.5-p100) ("The Eagle of Durango")
2024-09-27T09:05:15Z app[4d89626bee5128] fra [info]*  Min threads: 3
2024-09-27T09:05:15Z app[4d89626bee5128] fra [info]*  Max threads: 3
2024-09-27T09:05:15Z app[4d89626bee5128] fra [info]*  Environment: production
2024-09-27T09:05:15Z app[4d89626bee5128] fra [info]*          PID: 333
2024-09-27T09:05:15Z app[4d89626bee5128] fra [info]* Listening on http://0.0.0.0:3000
2024-09-27T09:05:15Z app[4d89626bee5128] fra [info]Use Ctrl-C to stop
error.message="instance refused connection. is your app listening on 0.0.0.0:80? make sure it is not only listening on 127.0.0.1 (hint: look at your startup logs, servers often print the address they are listening on)" 2024-09-27T09:05:24Z proxy[4d89626bee5128] fra [error]request.method="GET" request.id="01J8SBMM89XMN07HPF7R08A5QH-iad"
2024-09-27T09:05:54Z proxy[4d89626bee5128] fra [error][PC01] instance refused connection. is your app listening on 0.0.0.0:80? make sure it is not only listening on 127.0.0.1 (hint: look at your startup logs, servers often print the address they are listening on)

Should they remain on 3000? Will thruster even be involved then? :thinking:

Good catch! I missed that.

I suspect what is going on is that Thruster is trying to listen to port 80 despite not running on root. Changing the port fixes this:

[env]
  HTTP_PORT = 8080

[http_service]
  internal_port = 8080
1 Like

Yup, that seemed to do the trick!

Thanks, @rubys! :smiling_face_with_three_hearts: