August 18, 2016
When you are building your first Rails application, there are a lot of things to learn, but really, that is just the first step. Once you have managed to get your application into a place where it is working, if you want people to able to use it, you still need to get it onto the internet. But how do you do that?? How do you as someone with limited, or potentially no systems experience get an app onto the internet.
Well with deployment for ruby apps there are a number of options available for getting your application running, however a lot of them involve you having a server setup and runing that you manage, a real head ache, especially when you are starting out. So what's the answer to getting up and running quickly?
The very easiest way to get your ruby application onto the internet and in front of potential users is by deploying it to Heroku. Heroku is a platform as a service very popular amongst ruby developers for running apps.
As a Platform as a service (PaaS), Heroku take the hard part of running your application on the internet and take care of it for you. Think of Heroku as your very own ops team that is there to keep you app up so you can keep working on your application, instead of working on keeping it running.
To get started head over to Heroku and create an account.
After you have created an account we need to choose how you want to deploy your application. Heroku now offers 3 ways to deploy your app, via git, deploy via Github or deploy via Dropbox. Since one of the main attractions of Heroku is that you can use it without anything else, choose Heroku Git and install the Heroku Toolbelt to get started.
You'll want to add the rails_12factor to your application to get some important features running on your application such as static asset serving, ie not having your Rails app do it, and logging. These are pretty important so be sure to add
gem 'rails_12factor', group: :production
to your Gemfile.
Once you have installed the Toolbelt, you will need to login in to Heroku on the command line if you haven't dont this before, and it will lead you through a setup process.
heroku login
Once you are setup then you are ready to add heroku as a git remote and get an application running. Deployment is a simple one command thing,
git push heroku master
This is one of the big draw cards of Heroku, the nice simple single command deployment, and with a fairly simple rails it should build and you'll be up and running with a free web dyno and Postgresql database.
One thing I did run into though, when you are using Heroku, you need to be very particular with how you use your secrets.yml file to manage any secret keys that you have your application. An approach I have been taking when not using Heroku is to not include the secrets.yml in my source code repository and have my deployment process copy a file on the server into place to use as part of the process. This is something you can't do with a service like Heroku and is a practise that I will now reconsider, and move to environment variables to make my application deployment more portable in the future.
When you have some database migrations to be run
git push heroku master
will not run them by default, so just be sure to run
heroku run rake db:migrate
This will get your database up to the version that you expect.
For your application, Heroku is expecting you to set your ruby version in your Gemfile. This is very simple, I am using Ruby 2.2.4 so all I need to add to the bottom of my Gemfile is
source 'https://rubygems.org' ... ruby 2.2.4
Of course there is some more advanced stuff that you can do with Heroku and running your application. First up is you should populate your Procfile. If you don't your app will get started with a default of the free single dyno, but it's good to be explicit about you want and then you can easily move it something else or scale up to more dynos as required. So your starting basic Procfile will look something like:
web: bundle exec rails server -p $PORT
Of course the default webserver isn't the best one you can choose. You could go with something like Puma. Choosing which Ruby application server to go with though is a little beyond the scope of what we're talking about here, so I'm just going to use it as an example.
To get Puma into your app, first add it your Gemfile, in this case I will add it only for production, but only because, again, setting up Puma for development mode is a bit beyond the scope of what we're talking about. In general I would recommend using as close to the exact same stuff in dev and production as you can.
gem 'puma', group: :production
and then bundle install. Of course after you do this you will need to update your Procfile to use Puma
web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}
Commit to your git repo and push to Heroku for it to update.
Of course most modern web applications are not just a web server running these days. They have a whole host of moving parts to them. Luckily Heroku has addons for pretty much anything you might want or need. Some obvious ones that spring to mind would be Redis for running Sidekiq for your background jobs, and Sendgrid for sending your email from your application as well a whole host of addons at your disposal.
So that is the relatively hassle free deployment process that will get your app onto Heroku and running in the simplest way possible. Of course though, as with everything, there are tradeoffs involved here. For your single free dyno application, your web process will go to sleep if it is inactive for 30 minutes. This may or may not be a problem for you, and there are some techniques out there that can help you prevent this.
Another limitation of your heroku run application is that you can't store any files on the filesystem. For long term storage of files this is actually a good thing as you don't want to tie the state of your application to the particular app server that is running it, but can come as a surprise to people, especially when getting started as storing files locally is an easy introduction to using them. If you need to store any files, use Amazon S3.
And now to the potentially biggest sticking point for Heroku. Price. If you have a big application that has lots of moving parts, requiring multiple dynos and background workers as well maybe a hefty database then you could easily be looking at spending several hundred dollars every month, quite easily more. Of course if your application is making money and you don't want to spend time or money doing ops or having an ops team then this very well could be the preferable route for you to take, or you might find yourself using Heroku to get started with getting applications running on the internet and then moving on.
So after all that, should you use Heroku. I would say definitely, at least to start out with. Learning how to write a web application in Rails is a lot to take in, so don't overwhelm yourself with also trying to learn how to build and maintain a server to run it as well, there is plenty of time for you to do that if you wish at a later stage. Your particular application might also not really be hindered by any limitations of Heroku and be a just fine running on it for it's life span. There is also a really good chance that in some point in your career that you could inherit an application that runs on Heroku, and having some knowledge around that will certainly come in handy.