EC2 Exercise 1.5: Run a Rails App Built on an EC2 Instance

(This post is part of the AWS for the Bootcamp Grad series. The series consists of exercises to build familiarity with various aspects of the AWS ecosystem. Again, all of these posts are “exercises” for introductory exposure to AWS — they are NOT represented as best practices.)

Background

In this exercise, you will run a Rails app that you build directly on an EC2 instance. You will utilize AWS RDS (Relational Database Service) for your production database.

Specifically, you will do the following:

• Create an EC2 instance
• Configure the instance to run a Rails app
• Create a Rails app on the instance
• Provision a Postgres database on AWS RDS
• Connect your Rails app to the RDS database

Completing the Exercise

I primarily followed this tutorial on the AWS for Rails Developer site. I don’t believe I can improve on that tutorial in any meaningful way, so I suggest you follow that tutorial for this exercise.

That said, there were a handful of things I had to do differently to complete that tutorial. They were as follows:

Install libpq-dev Package

Install an additional Postgres related package on the EC2 instance with the following command.

sudo apt-get install libpq-dev

I believe you can do this at any point before you create the Rails project.

Create the Rails Project in the Correct Directory

When the tutorial instructs you to run rails new, it does not mention which directory you should be in. I inferred it from a subsequent step where you are instructed to edit the /etc/nginx/sites-available/hello_world file. In that step the root is defined as /var/www/hello_world/public .

Knowing that a Rails app will put all compressed and compiled assets into the /public directory, I ran rails new from the var/www directory.

Uncomment the mini-racer gem in the Gemfile

When you are instructed to uncomment the ruby gem ruby-racer in the Gemfile of the Rails app, you will not find that line in the Gemfile. I uncommented the mini-racer line, as my research suggested that it performed the same function as the ruby-racer gem.

Elevate Your Privileges to Edit Certain Files

There are a variety of files that are edited throughout the tutorial. You will lack write permission on some of those files unless you elevate your privileges by prepending sudo to the command. For example:

sudo vi /etc/nginx/sites-available/default

Don’t Worry if you Don’t See ‘Yay! You’re on Rails’

You may not see the ‘Yay! You’re on Rails’ page. At that point I got a Rails error related to Postgres that I wasn’t overly concerned about since the upcoming steps involved configuring the production database. Further, since the error suggested that it was attempting to render a Rails app, I concluded that the basic plumbing was in place.

Allow Your EC2 Instance to Communicate with your RDS Database

I was unable to create the production database until performing some combination of the following steps (sorry, I don’t know which of these fixed the problem — or if both were necessary):

• Attach an IAM Role to your EC2 instance that allows “full access” to RDS. I created a role with theAdministratorAccess policy. The permissions associated with this policy are more permissive than necessary, but I was troubleshooting at this point. Refer back to Exercise 1.3 to see how you attached an IAM role to an EC2 instance. In this current exercise, your EC2 instance is already created, so you will attach it through the ‘Actions’ button on the instance from the EC2 dashboard (after creating the IAM role).
• Allow inbound TCP traffic to your RDS instance from any source. From the RDS dashboard, select your instance and edit the Security Group rule for inbound traffic. Allow inbound traffic from any source (0.0.0.0/0). In all likelihood, you could allow inbound traffic from the public IP of your EC2 instance (vs. any source), but I was being aggressive for troubleshooting purposes at this point.

Skip the Entire Section Related to Rails Secrets

It seems like Rails 5.1 and Rails 5.2 made substantive changes to how secrets are handled in Rails apps. The process described in the tutorial is not possible in a Rails 5.2 project.

As I researched the alternative process for a 5.2 project, I came across blog posts like this one from Engine Yard. After reading that, I guessed that this entire set of steps may no longer be needed.

Clean Up

Navigate to the instances section of the EC2 dashboard, select your instance, and click on Actions. Select Instance State → Terminate. Confirm that you want to terminate.

Navigate to the instances section of the RDS dashboard, select your instance, and click on Actions → Delete. Follow the rest of the instructions that are meant to save you from unintentionally deleting your database. You do not need to create a final snapshot.

Next: Exercise 1.6: Deploy a Rails App to an EC2 Instance Using Capistrano