Rails and the Amazonian Beanstalk

Yo, Christian here .. One of the ways in which I try and keep in touch with the development community is by of course developing software. For those playing along at home that wouldn’t have come as much of a surprise, you can see a few previous posts tagged with ruby, and especially our interest in developing software that may help either secure your apps, or secure your processes (watch this space!).

Anyway, in addition to my interest in development, I’m also interested in operating these applications, especially leveraging the power of ‘the cloud’. Some of these principles may be referred to by some people as Development Operations .. or some such. Heroku is one of the more popular Platform-as-a-Service operators, their model is pretty slick. Sign up, git commit your code, and then just git push it and away you go. During my experiments with them I was also interested in leveraging Amazon’s CDN platform, CloudFront, which, with the help of the asset_sync gem was relatively simple. At a high level the steps are:

  1. 1) Code up your app
  2. 2) Git commit your code
  3. 3) Git push your code to heroku
  4. 4) During its deployment your static assets would be compiled, compressed, mashed-together
  5. 5) Asset_sync would then push these up to your nominated Amazon S3 bucket
  6. 6) Which in turn was published through the CDN (CloudFront)

Somewhere along the line though this stopped playing friendly, and after a few rounds of frustration, I decided to jump ship. Heroku, whilst offering some great benefits and simplicity to the whole continuous delivery process, also potentially encapsulated a lot of the gritty details away from you. Heroku, of course, leverage’s Amazon’s EC2. So why not go straight to the source?

Amazon’s approach to Platform-as-a-Service, also known as their Elastic Beanstalk (EB), was always a little bit daunting, and when I first heard about it, and its lack of support for Ruby(/Rails) I wasn’t all that interested. Well, those days are over, their model now supports Ruby 1.9.3, and of course Rails on top of that. Simply put, EB wraps up a fairly automatic approach to managing applications on top of their other services, namely:

  1. 1) EC2 – Elastic Cloud Computing – scalable web app servers for the controllers and view handling
  2. 2) RDS – Relational Database Service – for the backend model handling
  3. 3) S3 – Storage – for handling code distribution and log file management (so you don’t have to interact directly with your EC2s or RDSs)
  4. 4) SNS – Simple Notification Service – for handling email alerting, health checks etc
  5. 5) CloudWatch – for monitoring the health of your app, and automatically scaling those EC2 automatically
  6. 6) ELB – Elastic Load Balancing – to present a single DNS entry, which encapsulates those EC2 nodes away

The (I believe) official blog from AWS on their Elastic Beanstalk stuff offers a lot of interesting insight into how to run up these environments, but, I thought I should quickly dump out a few things that were causing me issues.

Firstly, the command line tools for starting, stopping, initialising your EB workload has a few problems. I don’t believe they’re hosted on GH, so I can’t send them a push request. One problem that was causing me a bit of grief was the functionality to automatically add the application-local ‘.elasticbeanstalk’ folder to your ‘.gitignore’ file. This functionality occurs on ‘eb init’, ‘eb start’, in fact, many of the eb functions. Firstly, the wrong entry was being added (at least on my OSX with Python 2.7 setup), and secondly, it wasn’t being added correctly so it would get incorrectly added every single time I ran any of these commands, which obviously didn’t work. My fix was simple.

In “AWS-ElasticBeanstalk-CLI-2.2/eb/macosx/python2.7/scli/constants.py”, change line 466 – 467 from:


    Name = Path + u'/'
    NameRe = Path + u'/'

To:


    Name = u'/' + Path
    NameRe = u'/' + Path

This ensures that the correct entry is searched for in the .gitignore file, and added as well.

Then, in “AWS-ElasticBeanstalk-CLI-2.2/eb/macosx/python2.7/scli/config_file.py”, change line 152 from:


    f.write(u'{0}'.format(name))

To:


    f.write(u'\n{0}'.format(name))

This ensured that the entries are added as new lines to the bottom of the .gitignore file properly.

The other thing I found helped during testing was jumping directly onto the EC2 nodes and tailing various log files. By default, your EB deployed EC2s don’t have SSH pub keys set, nor does the security group permit SSHing to them. Setting up your SSH keys is simple, make sure you’ve got some already created for the region where your app is, then either re-run ‘eb init’ and specify the keypair, or, edit your ‘.elasticbeanstalk/optionsettings’ file and update the ‘EC2KeyName=’ setting to the name of your keypair. After that’s done and you’ve re-started your environment (‘eb stop; eb start’) you will then have to jump into your EC2 console and modify the security group to permit SSH.

Voila! You can now SSH directly onto your EC2 nodes, and tail some interesting log files, I found the following of particular interest:

  1. 1) /var/log/eb-tools.log – shows you activity when you push new code, asset compilation, bundler runs etc
  2. 2) /var/app/support/logs/production.log – this is the actual rails log – see web requests etc

All in all, I’m really enjoying what I’m seeing. Sure, it may cost a bit more than running a single Dyno on Heroku, but, it certainly gives you a lot more control and visibility into exactly what’s happening, plus, it’s simple enough to jump straight into the deep end and see exactly what your servers are doing.

Devise Google Authenticator 0.3.3

A couple of weeks back, whilst working on some building some internal management apps, I finally got around to implementing the Devise Google Authenticator gem into a rails app outside of its own testing app. During this process I realised that I hadn’t correctly updated some of the extension’s code to properly work with the Devise 2.0 release, in particular the changes to the migration schema. A few amendments, a push or two and version 0.3.3 was now available.

Looking back over the process I’ve certainly learned a lot about Ruby, Rails and Devise, plus the whole Ruby Gems eco-system. What’s surprising though, is the number of people out there who appear to be using the gem. At a high level the breakdown is as follows:

So far though, we’ve only had a few queries come in. But, to try and capture them in a more appropriate place I’ve started a Google Groups which, if you wish, you can sign up to and post queries. Or, if it’s easier, just hit us up on twitter: @xntrik or @asteriskinfosec.

Cheers!

Integrating Google’s 2nd Factor Authentication with your Rails App

Asterisk is happy to announce the release of their first (beta) Ruby Gem. The “devise_google_authenticator” gem is a Devise Extension that integrates Google’s 2nd Factor Authenticator into Devise’s authentication scheme. It’s not designed to replace the existing password scheme (database_authenticatable), but it’s ideal to provide a second factor authentication mechanism from your smart phone (Android, Blackberry, iOS).

If you are doing any Rails development and have a need for user authentication/authorisation then you should certainly be checking out Devise. From their site:

Devise is a flexible authentication solution for Rails based on Warden. It:

  • Is Rack based;
  • Is a complete MVC solution based on Rails engines;
  • Allows you to have multiple roles (or models/scopes) signed in at the same time;
  • Is based on a modularity concept: use just what you really need.

Lets put together a really simple application.. (I’m assuming you have Ruby 1.9.2, but no other gems available. Also, most of this is following the Rails Guide and the Devise installation process)

Install rails:
$ gem install rails -v 3.2.0 –no-rdoc –no-ri

Create your vanilla app:
$ rails new myapp

Change into your new app:
$ cd myapp

Edit your Gemfile with the following two lines (after gem ‘sqlite3’):
gem ‘devise’, ‘~> 1.5.3’
gem ‘devise_google_authenticator’, ‘0.3.1’

Update your bundle:
$ bundle install

Create some data for your app
$ rails generate scaffold post title body:text

Install Devise:
$ rails generate devise:install

Install Devise Google Authenticator:
$ rails generate devise_google_authenticator:install

Create your user model:
$ rails generate devise User

Add the Devise Google Authenticator scheme:
$ rails generate devise_google_authenticator User

Migrate your database changes:
$ rake db:migrate

Remove the static index page:
$ rm public/index.html

Change the root page (edit your config/routes.rb and add the following below resource :posts):
root :to => ‘posts#index’

Edit your main application controller to require user authentication for all pages (edit app/controllers/application_controller.rb add just after protect_from_forgery) with the following:
before_filter :authenticate_user!

Now start up your app and visit localhost:3000:
$ rails server

After you register your user (after clicking Sign Up), you should be displayed with a QR Code. Simply add this to your Google Authenticator app on your phone, enable the authenticator, close down your browser (to clear your session), revisit the website and after you sign in, you’ll be prompted for your one time password.

Voila!