The context is that fly.io’s approach of every framework uses a Dockerfile and a toml file is great for system administrators, polyglots, and Rails developers who are comfortable with Dockerfiles, or at least Debian. 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 these people would prefer to use buildpacks or some other method than Dockerfiles, and when they have problems with those approaches instead of reporting the problems to the maintainers of the buildpack they report the problem to us.
I’d prefer an 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.
In order to run this make sure you have flyctl version v0.0.433 or later as I added a flag to allow dockerignore files to be provided at deploy time.
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.
Edit app/controllers/visitors_controller.rb
:
# 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.
Replace app/views/visitors/index.html.erb
with:
<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:
Edit config/routes.rb
:
# 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'
Initial deployment:
bundle add fly.io-rails
bin/rails generate fly:app
bin/rails deploy
Note that a volume is created. That's to store the sqlite3 database. Making that work actually takes multiple steps: create the volume, mount the volume, 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 fly open
.
Edit config/database.yml
:
production:
adapter: postgresql
Deploy your change:
bin/rails deploy
At this point, a pg
gem is installed, a postgres
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.
bin/rails generate channel counter
Add turbo_stream_from
and render the counter in a partial.
For this to work, make a partial that puts the counter into a turbo frame.
Create app/views/visitors/_counter.html.erb
:
<%= turbo_frame_tag(dom_id visitor) do %>
<%= visitor.counter.to_i %>
<% end %>
Update the view to add turbo_stream_from
and render the partial.
Update app/views/visitors/index.html.erb
:
<%= 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>
Add broadcast_replace_later
to the controller:
Edit app/controllers/visitors_controller.rb
:
# 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:
bin/rails deploy
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.
We've tried out two different databases. Let's use an alternate cable implementation.
Modify config/cable.yml
:
production:
adapter: any_cable
Deploy your change:
bin/rails deploy
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 mess, but you don't have to worry about them.
Run the following command to see what files were modified
git status
In addition to the config
and app
files that you modified you should see two files:
config/fly.rb
fly.toml
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 tradeoff is this
is accomplished by creating a Dockerfile
and various other artifacts.