Fly.io is a great place to run Rails applications, especially if you plan on running them on multiple servers around the world so your users have a fast, snappy, low-latency experience. Give us a whirl and get up and running quickly.
First, let’s talk about why we decided to use OCI container images in the first place. In short, containers are freaking awesome. They allow us to package up our applications and all of their dependencies into a single, self-contained unit that can be easily extracted, deployed, and run on any machine. This makes it super easy for our users to get up and running with Fly.io, without having to worry about all the little details of setting up their environment.
This naturally leads to a baseline approach where every framework uses a Dockerfile and a TOML file. This is great for system administrators, polyglots, and Rails developers who are comfortable with Dockerfiles. What that leaves behind is Rails developers who spend most of their time in an IDE on Macs or Windows; which frankly is most of them. Many of which have been spoiled by Heroku for the past 10 years.
A desire to avoid Dockerfiles has lead many to prefer to use buildpacks, nixpacks or other alternatives, and when they have problems with those approaches instead of reporting the problems to the maintainers of these alternatives they report the problem to us.
Below is a proof of concept of an alternative approach where from a Fly.io platform point of view everything is Dockerfiles and TOML files and from a developer point of view everything is Rails and Ruby, giving us the best of both worlds.
This is not a radical change.
flyctl will already build you an initial Dockerfile that meets many needs. This merely takes that approach further by dynamically generating a custom tailored Dockerfile on every Deploy.
What it does mean is that the Dockerfile needs to be correct and complete every time. No more relying on webpages of instructions. Fortunately Thor and ERB are good at this.
In order to run this make sure you have flyctl version v0.0.433 or later as this is when support was added for dockerignore files to be provided at deploy time.
Part one, a simple visitor counter
Start by creating a simple application and scaffold a visitor counter table:
rails new welcome --css tailwind cd welcome git add . git commit -a -m 'initial commit' bin/rails generate scaffold visitor counter:integer bin/rails db:migrate
Modify the index method in the visitor controller to find the counter and increment it.
# GET /visitors or /visitors.json def index @visitor = Visitor.find_or_create_by(id: 1) @visitor.update!( counter: (@visitor.counter || 0) + 1 ) end
Change the index view to show the fly.io balloon and the counter.
<div class="absolute top-0 left-0 h-screen w-screen mx-auto mb-3 bg-navy px-20 py-14 rounded-[20vh] flex flex-row items-center justify-center" style="background-color:rgb(36 24 91)"> <img src="https://fly.io/static/images/brand/brandmark-light.svg" class="h-[50vh]" style="margin-top: -15px" alt="The monochrome white Fly.io brandmark on a navy background" srcset=""> <div class="text-white" style="font-size: 40vh; padding: 10vh" data-controller="counter"> <%= @visitor.counter.to_i %> </div> </div>
Define the root path to be the visitors index page:
# Defines the root path route ("/") root 'visitors#index'
Save our work so we can see what changed later.
git add . git commit -m 'initial application'
Now let’s do our first deployment. If desired add
—org options to the
generate command below, or let them default:
bundle add fly-rails bin/rails generate fly:app bin/rails fly:deploy
Note that a volume is created. That’s to store the sqlite3 database. Making that work actually takes multiple steps: create a volume, mount the volume, and set an environment variable to cause Rails to put the database on the mounted volume.
All of that is taken care of for you.
To see your app in production, run
Part two: change the database to PostgreSQL
While sqlite3 is more than adequate for this silly example, many applications require something more. Let’s switch to postgresql.
production: adapter: postgresql
Deploy your change:
At this point, a
pg gem is installed, a
PostgreSQL database is created, and a secret is set. Also, there now is a separate release step that will run your database migrations before restarting your server.
Again, all without you having to worry about anything.
Part three: update the counter without requiring a refresh
Sending asynchronous updates requires a WebSocket as well as an ability to process updates in the background. Rails makes this easy.
Start by generating a new Action Cable channel:
bin/rails generate channel counter
Make a partial that puts the counter into a Turbo Frame.
<%= turbo_frame_tag(dom_id visitor) do %> <%= visitor.counter.to_i %> <% end %>
Update the view to add
turbo_stream_from and render the partial.
<%= turbo_stream_from 'counter' %> <div class="absolute top-0 left-0 h-screen w-screen mx-auto mb-3 bg-navy px-20 py-14 rounded-[20vh] flex flex-row items-center justify-center" style="background-color:rgb(36 24 91)"> <img src="https://fly.io/static/images/brand/brandmark-light.svg" class="h-[50vh]" style="margin-top: -15px" alt="The monochrome white Fly.io brandmark on a navy background" srcset=""> <div class="text-white" style="font-size: 40vh; padding: 10vh" data-controller="counter"> <%= render "counter", visitor: @visitor %> </div> </div>
broadcast_replace_later to the controller.
# GET /visitors or /visitors.json def index @visitor = Visitor.find_or_create_by(id: 1) @visitor.update!( counter: (@visitor.counter || 0) + 1 ) @visitor.broadcast_replace_later_to 'counter', partial: 'visitors/counter' end
Deploy your change:
At this point, a
redis gem is installed (if it wasn’t already), an Upstash Redis cluster is created if your organization didn’t already have one (otherwise that cluster is reused), and a secret is set.
Once again, all without you having to worry about anything.
Part four: change your cable adapter to any_cable
We’ve tried out two different databases. Let’s try out AnyCable as an alternate cable implementation.
production: adapter: any_cable
Deploy your change:
Note that this time you are likely to see
502 Bad Gateway. That’s because nginx typically starts faster than Rails and at this point this is just a demo. Don’t worry, Rails will start in a few seconds and things will work once it starts. If you check the logs you will often see a similar problem where anycable go starts faster than anycable rpc, but that also corrects itself.
Once again, gems are installed and this time at runtime multiple processes are run, including one additional process (nginx) to transparently route the websocket to anycable. All on a single 256MB fly machine. The details are messy, but you don’t have to worry about them.
We’ve deployed four different configurations without having to touch anything but Rails files.
Run the following command to see what files were modified:
In addition to the
app files that you modified you should see two files:
Both are relatively small, in fact
fly.toml is only one line. The other file is likely to change dramatically so don’t get too attached to it. What it is meant to describe is the deployment specific information that can’t be gleaned from the configuration files alone, things like machine and volume sizes. The hope is that it will cover replication and geographic placement of machines; conceptually similar to what terraform provides today but expressed at a much higher level and in a familiar Ruby syntax.
If you want to see the configuration files that actually are used, run the following command:
bin/rails generate fly:app --eject
Note: this demo uses fly machines v2, and requires a script (
rails deploy) to build a Dockerfile and run the underlying commands and APIs to create machines, set secrets, etc. It is possible to run with nomad (a.k.a. v1) by passing
--nomad on the
bin/rails generate fly:app command, and while this will allow you to run vanilla
fly deploy the trade off is this is accomplished by creating a
Dockerfile and various other artifacts.
Some examples of things worth exploring
- Not implemented yet, but it should be possible to modify the size of a volume in
config/fly.rband deploy to make a change.
- While the above demo made use of fly’s Postgres offering, you may very well want a managed alternative. Or go the other way and run Debian’s Postgres within the same VM. Or go with a different database entirely. All should be easy as setting some custom credentials.
- Active Storage supports a number of back-ends including Amazon’s S3 and Google’s Cloud. Let’s make that easy too.
- The example above ran AnyCable in the same VM which may not be optimal for scaling reasons. Not to mention that taking AnyCable down every time you deploy a change to your application will drop sessions. We should make it easy to say that I want two of this application running in this region and three of that application running in this other region.
fly deploycan be run as a GitHub action. Extend this work to cover
- Consider adding other
bin/rails fly:tasks that add value. Perhaps one that directly runs
rails consoleon the deployed machine. Perhaps another that simply sets the working directory properly on ssh.
The common theme of all of the above is to look for a higher level abstraction than what is currently provided in Dockerfiles and fly.toml, while retaining the ability to drop down and say things like “also install this Debian package” or “also expose this port”.
Feedback is welcome on community.fly.io.
Oh, and it probably is worth mentioning that the source to the fly-ruby gem is on GitHub and written in Ruby. Pull requests welcome!