Deploying my shit to fly.io

I prefer to develop manufacturing tasks and aspect tasks as deployment-driven as doable. Through the years I had tons of tasks on Heroku and I am grateful for the expertise 🙏 But when tons of tasks are to come back once more, I do not see a degree in paying 7$ bucks per side-project.

Fortunately Heroku appears to be developing with a 5$ bucks plan that offers you 1000 hours throughout a number of Dynos, so I will not migrate my present tasks away for now and pay the 5 bucks, no questions requested.

However for my new aspect tasks, I am trying out options trigger after the 1k hours I would wish to pay 7$ per venture month-to-month only for my very own enjoyment…

Enter new venture

So I had a quite simple app arrange domestically in a state that was workable for me as an admin and for my 0.5 customers, it is now on-line right here:

It had 1 public controller, and a couple of sources with admin controllers hidden behind fundamental auth, so simply an app for somebody to handle some knowledge.

It was time to deploy (really it was already fairly late, I might have deployed earlier, however I knew that this is able to be the venture the place I will mess around with another).

I already heard colleagues mentioning fly.io and when deploy was due for my new shiny app I did one other spherical of Reddit analysis. And once more, a lot of fly.io so right here we’re.

Issues I wasn’t certain about initially:

how a lot time will this be?

I bumped into a few points, all in all it took me round an hour. General, it is simply a few instructions for a extremely contemporary Rails app, all configuration is taken care of.

“shit I have to dive into Docker”

$ fly launch units up a Docker file, so no extra digging wanted right here. Undecided if that stays like this within the longterm when your app is rising…

The command creates:

Dockerfile
fly.toml
.dockerignore

So I assume you possibly can configure your personal freestyle from there.

Issues I am nonetheless undecided about:

how free is it actually?

Did not discover it anyplace, however somebody on Reddit talked about a 5$ cap, which must be lots for pastime apps. fly.io says, “you possibly can preserve it free so long as you need”, no matter which means.

automating CI and CD?

For Continous Deployment/Supply: Heroku was constructed with simply that in thoughts, you alter your mainline within the heroku repo, i. e. push your code, which updates the code and the venture bundle in your manufacturing machine mechanically. So candy.

Heroku had additionally “pipelines” for Steady Integration stuff.

For fly.io it will want extra configuration, like configuring GitHub actions with the fly.io CLI (which is very nice to work with by the best way).

monitoring capabilities?

In Heroku, if you wish to know something about your app (aside from logs) you have to Pay for the next plan than the free plan.

The fly.io dashboard has monitoring, metrics, and logging, multi functional place. You may additionally get some superior Grafana metrics out-of-the-box

Points I bumped into with the primary deploy

I believe it is pure for each new PaaS device to have a little bit of a studying curve. Listed below are a few issues I wanted to know to get my latest goo code to fly.

Error 1 – Error Failed attaching db to the Postgres cluster – no such host

When establishing the app, I obtained an error on the finish:

$ fly launch

... a lot of output ...

Error Failed attaching developer-pursuit-db to the Postgres cluster developer-pursuit: Get "http://developer-pursuit-db.inside:5500/instructions/databases/developer_pursuit": dial: lookup developer-pursuit-db.inside. on fdaa:0:c09a::3: no such host.nTry attaching manually with 'fly postgres connect --app developer-pursuit developer-pursuit-db'

This appears to be a transient fly.io situation from what I’ve learn on their discussion board. It may be fastened with the terminal command that is steered within the error message:

$ fly postgres connect --app developer-pursuit developer-pursuit-db

Error 2 – Failed as a consequence of unhealthy allocations

$ fly deploy

... a lot of output ...

--> v1 failed - Failed as a consequence of unhealthy allocations - no steady job model to auto revert to and deploying as v2 

That was a nasty one. There is a little bit of a cryptic error when your app fails after booting.

The fly.io docs first level to PORT points, however checking the env configs, port appeared simply high quality:

$ fly configs

Atmosphere variables
NAME VALUE 
PORT 8080  

After a little bit of despair, I reached for the $ fly logs command and noticed the precise stack hint of the Rails app which pointed to an unset ENV variables that I used to be utilizing for… 🥁 … Fundamental auth 🎉

I’ve set the variables with the $ fly secrets and techniques utility and the app ran simply high quality.

Conclusion

The general expertise is excellent. It sucks to run into cryptic errors while you first attempt issues out, however this was all affordable and solvable with a little bit of considering and analysis.

The command line feels very good and much like heroku to date.

Configs are served for you automagically and you might be in full management of the deploy, however in the event you do not automate it through GitHub actions or comparable, you’ll mess issues up finally. However that is extra work…

I will in all probability stick for my previous tasks with Heroku for the 5$ bucks per 1k hours and usually fallback to fly.io for brand spanking new tasks.

If in case you have any feedback or questions:

Different stuff? Simply tweet it out to me!

Tweet to @RichStoneIO