Put Your App Online With Heroku
Created by Terence Lee, @hone02
Follow steps 1 through 3 of the quickstart guide to sign up, install the toolbelt, and login.
COACH: Talk about the benefits of deploying to Heroku vs traditional servers.
Preparing your app
Version Control Systems
We need to add our code to version control. You can do this by running the following in the terminal:
git init echo "public/uploads" >> .gitignore echo "tmp" >> .gitignore echo "logs" >> .gitignore git add . git commit -m "initial commit"
COACH: This would be a good time to talk about version control systems and git, also explain the
.gitignore and why we don’t want these files included.
Updating our database
First, we need to get our database to work on Heroku, which uses a different database. Please change the following in the Gemfile:
group :development do gem 'sqlite3' end group :production do gem 'pg' end
bundle install --without production to setup your dependencies.
COACH: You can talk about RDBMS and the different ones out there, plus include some details on Heroku’s dependency on PostgreSQL.
Next, we need to add
rails_12factor entry into our Gemfile to make our app available on Heroku.
Please change the following in the Gemfile:
group :production do gem 'pg' end
group :production do gem 'pg' gem 'rails_12factor' end
After this run
bundle, then commit the changes to Gemfile.lock to your repository:
git commit -a -m "Added rails_12factor gem and updated Gemfile.lock"
COACH: You can talk about logging on Heroku, as well as its other quirks.
Deploying your app
We need to create our Heroku app by typing
heroku create in the terminal and see something like this:
Creating sheltered-refuge-6377... done, stack is cedar http://sheltered-refuge-6377.herokuapp.com/ | firstname.lastname@example.org:sheltered-refuge-6377.git Git remote heroku added
In this case “sheltered-refuge-6377” is your app name.
Pushing the code
Next we need to push our code to heroku by typing
git push heroku master. You’ll see push output like the following:
Initializing repository, done. Counting objects: 101, done. Delta compression using up to 2 threads. Compressing objects: 100% (91/91), done. Writing objects: 100% (101/101), 22.68 KiB | 0 bytes/s, done. Total 101 (delta 6), reused 0 (delta 0) -----> Ruby app detected -----> Compiling Ruby/Rails -----> Using Ruby version: ruby-2.0.0 -----> Installing dependencies using 1.6.3 Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment Fetching gem metadata from https://rubygems.org/.......... ... -----> Launching... done, v6 http://sheltered-refuge-6377.herokuapp.com/ deployed to Heroku
You’ll know the app is done being pushed, when you see the “Launching…” text like above.
Next we need to migrate our database like we did locally during the workshop:
heroku run rake db:migrate.
When that command is finished being run, you can hit the app based on the url. For this example app, you can go to http://sheltered-refuge-6377.herokuapp.com/. You can also type
heroku open in the terminal to visit the page.
Heroku’s platform is not without its quirks. Applications run on Heroku live within an ephermeral environment — this means that (except for information stored in your database) any files created by your application will disappear if it restarts (for example, when you push a new version).
Each dyno gets its own ephemeral filesystem, with a fresh copy of the most recently deployed code. During the dyno’s lifetime its running processes can use the filesystem as a temporary scratchpad, but no files that are written are visible to processes in any other dyno and any files written will be discarded the moment the dyno is stopped or restarted.
In the App tutorial the ability to attach a file to the Idea record is added, which results in new files being written to your applications
public/uploads folder. The ephemeral storage in Heroku can be seen with the following steps:
- Launch the app with
- Add a new Idea with an image
- Restart the application by running
- Go back to your Idea and reload the page - the image should no longer be visible
Working around Ephemeral Storage
Obviously this doesn’t seem to be useful if you were running a real life application, but there are ways to work around this which is commonly used by a lot of popular websites.
The most common method is to use an external asset host such as Amazon S3 (Simple Storage Service) or Rackspace CloudFiles. These services provide (for a low cost - usually less then $0.10 per GB) storage ‘in the cloud’ (meaning the files could potentially be hosted anywhere) which your application can use as persistent storage.
While this functionality is a bit out of scope for this tutorial there are some resources available which you can use to find your way:
As always if you require any more information or assistance your coaches will be able to assist.