Text

· · to read

I’m developing a Rails site that uses MySQL and runs on Heroku. I’m using Xeround for the database, which has a free trial. Xeround is a database PaaS (Platform as a Service) that runs on several places, including Amazon Web Services in their U. S. East region, which is where Heroku runs. Running it in the same place where Heroku runs gives it a low latency.

To set up Xeround, sign up for an account and set up a database instance in the AWS U. S. East region. Go to the page for the database instance, and you will see the username and the database URLs.

Rails reads its database configuration from config/database.yml. Heroku overwrites config/database.yml with a file it generates from the DATABASE_URL configuration variable. The configuration variable uses the database driver name as the network scheme (e. g. mysql://). There is more than one mysql driver for Rails; the one suggested in the Rails Guide is mysql2.

To use mysql2 as the database driver with Xeround, use the following for the DATABASE_URL configuration variable:

heroku config:add DATABASE_URL='mysql2://{{username}}:{{password}}@{{hostname}}:{{port}}/{{dbname}}'

The username, hostname, and port number can be seen on the DB Instance Manager page on Xeround. The hostname and port are under one of the three DNS Names; I picked the top one. The password is what was entered for the database password during signup. The database name is the name of the database to be added using PHPMyAdmin.

The driver also needs to be included in the Gemfile. To include it just for production, use:

group :production do
  gem 'mysql2'
end

After adding this, run bundle install, commit your changes, and push to Heroku.

The database still needs to be created. To create the database, click on one of the links under DNS Names on the DB Instance Manager. This brings up PHPMyAdmin. Enter the database password and log in. Then create the database, with the same name used for the DATABASE_URL configuration variable.

Now that the database has been created, the DATABASE_URL is set, and the Gemfile is updated and pushed, you should be able to migrate the database by running heroku run rake db:migrate.

I’m using the latest version of Rails (3.1.1) on Heroku’s cedar stack.

It will be interesting to see how well Xeround works for this project. There are other MySQL hosting options for EC2 if I need them, and migrating is fairly simple.

Text

· · to read

After setting up some Heroku addons I got used to using environment variables to specify add-on settings. I then started using them for non-addon settings, and now I’ve started using them outside of Heroku a bit too.

One area where they work well is for a Heroku-deployable open source app with OmniAuth GitHub OAuth integration. Here is an example initializer (config/initializers/omniauth.rb) from a RailsCast:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :github, 'CLIENT_KEY', 'CLIENT_SECRET'
end

I would replace CLIENT_KEY and CLIENT_SECRET with my own keys, but I can’t commit them to a public repository, or else another person could use them and I could be held responsible. Rather than leave out my client key and secret using a .gitignore and a sample config, I can use an environment variable:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :github, ENV['GITHUB_CLIENT_KEY'], ENV['GITHUB_CLIENT_SECRET']
end

With a note in the README about the environment variables used, this should be easy for developers to set this up on their own private apps.

So far I’ve been typing environment variables into the command line when running apps locally and on my VPS, but that’s about to change. I may specify them in my nginx config, which is backed up to a private git repo. I’m not sure yet. Also I’m going to dump out my Heroku environment variables and back them up too.

Repositoryomniauth
Ownerintridea