Ruby Video
RailsConf 2015
Deploy and Manage Ruby on Rails Apps on AWS
Alex Wood
@awood45
Trevor Rowe
@trevorrowe
1 more speaker
See all speakers

Deploy and Manage Ruby on Rails Apps on AWS

by Alex Wood, Trevor Rowe, and Loren Segal

In the video titled "Deploy and Manage Ruby on Rails Apps on AWS," presented by Trevor Rowe, Alex Wood, and Loren Segal at RailsConf 2015, the speakers guide attendees through the deployment of Ruby on Rails applications on Amazon Web Services (AWS). The hands-on lab begins with an introduction to the trio, who all work on the AWS SDKs and Tools team, followed by a brief overview of what participants will achieve during the session. The main focus is on deploying a sample Rails application using AWS OpsWorks and integrating various AWS services to enhance functionality.

Key Points Discussed:

  • Introduction and Setup:

    • The speakers introduce themselves and encourage participants to ask questions throughout the lab.
    • Attendees are required to have an AWS account and are provided with $50 credits to facilitate experimentation.

  • Application Deployment with AWS OpsWorks:

    • The lab involves creating a two-layer web application consisting of an app server layer (Rails) and a database layer (MySQL).
    • OpsWorks offers a balanced approach between convenience and control for resource configuration.
    • The importance of IAM roles and employing best practices for security are emphasized.

  • Step-by-Step Deployment Process:

    • Participants are guided through creating an OpsWorks stack, database layers, and configuring application settings.
    • Specific changes to the Gemfile to support production deployment (i.e., using the Unicorn gem) and the use of Chef hooks are discussed.
    • Discussions on selecting appropriate instance types, with recommendations for cost-effectiveness.

  • Email Functionality with Amazon SES:

    • After deploying the application, attendees learn to configure email functionalities using the Amazon Simple Email Service (SES).
    • Steps include verifying email addresses and setting the appropriate IAM permissions to send emails correctly.

  • Asset Management with Amazon CloudFront:

    • The bonus exercise involves configuring the Rails asset pipeline with Amazon CloudFront to serve static assets efficiently and improve performance.

Conclusions and Takeaways:

  • The lab provides practical knowledge for attendees to continue building and producing scalable Rails applications using AWS.
  • Participants are encouraged to explore further resources and keep in contact with the speakers for ongoing learning and support.
  • Overall, the session equips developers with the foundational skills and tools needed to leverage AWS in their Ruby on Rails projects.
00:00:12.400 Thank you all for coming out to learn how to deploy and manage Ruby on Rails applications on Amazon Web Services.
00:00:18.880 Let's start with a quick introduction to who we are.
00:00:25.359 All three of us work on the AWS SDKs and Tools team. I'm Alex Wood. You can find me on Twitter and GitHub. In the back, we have Trevor Rowe and Loren Segal, who you can also find on Twitter and GitHub.
00:00:38.559 If you have any questions during the lab, feel free to raise your hand, and Trevor and Loren will come to help you out.
00:00:49.840 During the parts where we're working on exercises, you can ask questions with me up here as well.
00:00:57.680 So what are we doing today? We have a Ruby on Rails sample application linked inside the instruction document. You don't need to download or clone it, but it's there for you to look around and see how we did the integrations. You can also play around with it further after the lab is done.
00:01:10.640 We are going to deploy that sample application to Amazon Web Services using AWS OpsWorks. After that, we will use Amazon's Simple Email Service to send Action Mailer messages using the new AWS SDK Rails gem. We may run over time for the last part, but all the instructions are there.
00:01:23.119 We will show you how to cache the Rails asset pipeline using Amazon CloudFront. Here's a quick show of hands: if you do not have an AWS account yet, could you raise your hand?
00:01:35.600 For this lab, you will need an AWS account. With the credit handouts that we're giving out, you can create an account straight from there. Could you raise your hand if you don't have AWS credits yet? Trevor and Lauren will be by in a second with a credit for you.
00:02:01.759 Let's take a couple of minutes here to make sure everything is set up. So please log in to your AWS account or create one if you don’t have one yet. Apply your credits, which you shouldn't need for the lab, but it's $50. I'd encourage everyone to take it and experiment afterwards.
00:02:15.440 There's also a TinyURL link to the instructions page for the lab. If anyone can't get to that page, let me know as well. We'll take about one more minute for this, and during these pauses, feel free to shoot a question at me if you have one at any time.
00:03:23.120 Just to double-check: is there anyone who does not have their AWS credits in their hand and applied yet? Raise your hand so Trevor and Lauren can find you.
00:03:39.599 If you have an account, you can still apply the credits to it. For the lab, we're using the smallest instance types, and we're cleaning everything up afterwards. If you're in the AWS Free Tier, that should cover some of the costs as well. Definitely take a credit anyway and keep playing around. We'll talk a little bit about what you can do at the end of the lab as well, and we'll be hanging around afterwards if anyone wants to ask more questions or try more stuff out.
00:04:14.080 Now, let's talk about what we're building. We're creating a two-layer web application with AWS OpsWorks. We'll start by creating an OpsWorks stack, which you can think of as a container for all the other resources that our application deployment is going to have.
00:04:39.680 As mentioned, we'll have two layers: a Rails app server layer, which will contain any instances running Ruby on Rails, and a MySQL layer running a single EC2 instance with MySQL on it. From the app layer, we'll send out emails to user accounts using Amazon SES and the AWS SDK Rails gem.
00:04:52.560 We will also cache the Rails asset pipeline using Amazon CloudFront. So why use OpsWorks? This is a question I've heard several times during the conference when discussing the lab.
00:05:06.800 I wanted to strike a balance between convenience and control. OpsWorks provides a lot of fine-grained control over how your instances are configured, how you scale them, and where they live. In contrast, other options like AWS CodeDeploy, CloudFormation, or manually using instances offer more control, whereas choices like Amazon EC2 Container Service and Elastic Beanstalk provide more convenience.
00:05:43.600 We're happy to discuss other options afterwards, but this is a nice middle ground for the lab we're doing today.
00:06:01.199 We've talked about these elements, but let's review some key concepts. AWS OpsWorks uses Chef to manage and configure your AWS instances. There are concepts of a stack, a layer, and an app, which contains all the configuration needed to deploy your application onto your instances.
00:06:37.120 We're also using the new AWS SDK Rails Ruby gem. Raise your hand if you've tried that gem out before. Great! A few of you have seen that. This gem builds on top of the AWS SDK for Ruby V2 that we released last year. We’ll cover some aspects of AWS Identity and Access Management as well, discussing how to manage credentials safely and best follow the principle of least privilege, including IAM Roles for Amazon EC2 which the AWS SDK Rails gem can use.
00:07:16.720 Let’s move on to deploying the Rails application to AWS OpsWorks. Here is the diff we're going to work with. It’s a change to the Gemfile where we specify that in production we'll use the Unicorn gem and the MySQL2 database adapter. We create a file called 'before_symlink' in the deploy folder in our Rails application, which essentially pre-compiles our static assets during the deployment phase.
00:08:01.600 So, who here is familiar with Chef hooks? This is already provided for you in the repository we're deploying, so we don’t have to make these changes. This is just a review of the changes you'd need to make to take a Rails application you have and get it functioning on AWS via OpsWorks.
00:08:36.160 Now we will begin the first exercise. We will take our sample application and deploy it to AWS using OpsWorks. To start, we'll create a stack, followed by the application and database layers. The first exercise in the instruction sheet contains a link that allows you to jump between the different exercises, so let’s take a few minutes to create an OpsWorks stack.
00:09:01.600 If you have any questions, feel free to let me know at any time.
00:09:19.600 This is tinyurl.com/railsconf2015-aws. And if you're watching this on video, I'm going to keep that link up after the conference. If the link is not up for any reason, feel free to get in touch and I can remedy that. Raise your hand if you don’t have the instruction sheet open yet.
00:10:26.320 Let me give you guys a minute to check if you have the instruction page open.
00:10:54.320 If you do not have a default VPC option available, please raise your hand so Trevor and Lauren can help you out.
00:11:11.600 If you do not have a default VPC, the recommendation is to use US East 1, as it’s easier because it avoids an EPC for that region.
00:11:28.240 VPC stands for Virtual Private Cloud. Inside a VPC, you have control over what inbound and outbound traffic is allowed. This means you can set up various subnets. For example, as you expand this app, you might decide that your app and database instances should not be accessible from the public internet, only through a load balancer instance or SSH traffic through a Bastion Server.
00:12:11.279 For the purposes of this lab, we will deploy in a permissive manner whereby the instances will be publicly accessible. We'll have a discussion at the end about how you could productionize the application as you iterate on it.
00:13:46.079 Additionally, while you’re creating this stack, you will notice the instruction sheet has an instruction to make an SSH key. Strictly speaking, this is not necessary, but it’s definitely recommended. In case something goes wrong, we will be able to SSH onto the instances and check the logs. If you have an existing SSH key, you can import it or reuse it when creating the stack.
00:14:14.680 A frequently asked question has been about naming your key pair. You can name it anything you’d like; I named mine 'railsconf.' The key should be known to you on your machine, as that will allow you to SSH into your instances.
00:14:54.320 In this lab, we will use a database layer that OpsWorks provides. In the appendix section of the instructions, I’ve shown how to use Amazon RDS for either Postgres, Microsoft SQL Server, Oracle, or even MySQL with failover. There are further instructions about how you could do that and follow along after the lab.
00:15:31.920 OpsWorks will wire up the connection to the database, so if you want to use a different type of database instance, you could configure that in your Rails application, and Rails would just connect to it.
00:16:11.600 Let’s see a show of hands for who has their stack created. We will leave a few more minutes for that. You don't have to create everything; just having created the stack is sufficient for now. The next exercise is about creating the layers.
00:16:39.279 If you haven’t made the layers yet, that's okay; that's the next exercise. Raise your hand if you need help getting that set up.
00:16:51.999 If you created your stack, you can move on to the next exercise. The exercise to add the stack form will take the longest, especially with all the initial setup.
00:17:01.600 Most fields in the add stack form will use defaults, but if you check the exercise instruction, you will see a few that you’ll want to change. One important change is to create new IAM roles, because we're going to edit them. If you don’t create a new role, changes could inadvertently apply to all stacks. It’s a best practice to create a new role anytime you're creating a new stack.
00:17:27.600 In this lab, we are not creating an Elastic Load Balancer for time purposes. Best practices dictate that you should have a load balancer, but for the sake of simplicity, we'll be directly connecting to your application server. We’ll discuss at the end how this design could be improved as you iterate.
00:18:06.480 The next step is exercise 1B on the instruction sheet, which involves creating the OpsWorks layers and launching instances within them. Make sure to refer to the non-default options listed in your instruction sheet; there’s also a screenshot for comparison.
00:18:17.120 An additional question about using instance storage versus EBS-backed storage for this lab: there is no difference. The distinction will be more relevant if your database runs on instance storage; in that case, if the instance goes down, you lose all data unless you have backups and snapshots.
00:18:45.200 Alternatively, with EBS-backed instances, if the instance fails, you retain the EBS volume with your data and can attach it to a new instance. For this lab, the recommended default is an EBS-backed instance.
00:19:00.320 As we are creating MySQL OpsWorks layers and not RDS layers, it can save time in this lab. However, instructions for switching to RDS can be found in the instruction sheet or through a linked blog post.
00:19:23.120 I recommend keeping an eye on the instance size you select. The default is a c3.large instance, which is more expensive than a t2 or t1 micro, but the smallest instance types are more than adequate to run our sample application. Once both layers are created and instances are spinning up, you're done with this exercise.
00:19:52.560 You can continue working on the next steps while the instances set up. The instruction sheet indicates that you should create instances within the VPC based on your stack settings, and whichever VPC you assign to your stack is the VPC your instances will launch into.
00:20:08.839 You might be able to choose the subnet the instances go into; the default subnet will be fine for this lab. The configuration of layers within Chef defines what types of recipes run on any instances within that layer, which you can customize as needed.
00:20:37.600 Next, we will move on to exercise 1C, which involves creating and deploying the OpsWorks application. Quickly, when creating the app, the secret key base environment variable should not concern you overly; normally, you'd run 'rake secret' in your Rails repo. For the purposes of deployment, however, any string comprised of letters and numbers that isn't solely numbers will work for this exercise.
00:21:05.920 Make the secret key a protected value, as once it’s set, you want to keep it confidential. Keep in mind that we are not enabling SSL for ease of this lab; in a production setting, you absolutely want to have SSL set up to secure sensitive information.
00:21:41.680 Once the application is created, expect to see both instances online and running. After successful deployment, you should click through to the app server’s hostname. If your instance boots properly, you will see your application up and running.
00:22:01.760 At this point, you’re done with exercise one. If you have a few minutes, play around, register an account, and make a few tasks. If you use an email you genuinely own, it will be beneficial for future tasks, although remember that this does not do email verification.
00:22:34.120 It’s worth noting that at this step, if you attempt to subscribe to a task update and send an email, it won’t work yet because we haven’t configured it. You should see if you haven’t gotten to the running application page and if you are still waiting for your instances to boot.
00:23:14.760 The next exercise is about sending emails using Amazon SES and the new AWS SDK Rails gem. The first steps will involve configuring the AWS SDK Rails gem, verifying your email, and setting up the OpsWorks IAM instance role profile so that the SDK has permissions to deliver your mail.
00:23:37.920 When changing your application to use the AWS SDK Rails gem, ensure that you have the dependency locked to version 1.0. That's all you need in terms of code. The configuration will be handled by the SDK, but you need to provide an environment variable for the AWS region you want to deploy in.
00:24:02.560 When you reach exercise 2A in your instruction sheet, remember that you don't have to remove the existing AWS SDK gem in the Gemfile if you’re using an SDK version 2, as it will work without any further adjustments.
00:24:26.080 If you are on version 1, you may not need to remove it, as both can coexist in the same project. Be sure to pay attention to the AWS region environment variable; in the US West 2 region, enter it as 'us-west-2' without any additional identifiers.
00:25:01.640 Exercise 2B will entail setting up your email for testing with Amazon SES. Unless you have an existing production account, you need to validate every email address that you send to or from. Set your sending email address to one that is validated and owned by you.
00:25:38.720 Once you send an email, request verification of your email address in the SES console following the related instructions. Once you have verified your sender email, configure the environment variable for the Action Mailer to know from what email to send.
00:25:54.560 Make sure to set the 'from_email' variable to the verified email address you own. Once this is done, you will need to redeploy your application for this variable to take effect.
00:26:34.960 Let's recap: using sandbox access means that by default, you need to verify every single email address you send from or to. You'll need to set your email address as the sender in SES for it to work correctly.
00:27:12.120 In this lab, you’ll see how the identity and access management step plays a part. By default, your instance profile won’t have permissions to make SES API calls; you'll need to change that to enable email functionality.
00:27:55.360 The next step is to give the OpsWorks IAM instance role permissions to use Amazon SES. This is necessary because your stack, when created, will have attached IAM roles that dictate permissions for each instance.
00:28:24.280 Add the Amazon SES full access policy; it takes effect immediately without a redeploy. After doing this, you should be able to send emails as configured, provided you're using the correct verified email addresses.
00:28:58.679 After signing up for task updates and changing a task state, you should see the email notifications working. If you encounter problems, raise your hand so someone can assist you with identifying the issue.
00:29:36.640 Once everything is set up correctly, you’ll confirm that emails have successfully sent, checking the console and your verified emails. Next, we’ll look into Rails Action Mailer configuration.
00:30:16.240 To configure the Action Mailer delivery method using the AWS SDK Rails gem, simply ensure that you require the gem and utilize the AWS SDK delivery method. This will allow Action Mailer to work with Amazon SES via the configured environment.
00:30:57.280 Additionally, there’s a bonus exercise about configuring the Ruby on Rails asset pipeline to use Amazon CloudFront as a CDN. This is straightforward: adjust the asset host environment variable to the domain of the CloudFront distribution you created.
00:31:32.640 With a cloudfront distribution set up and the asset host adjusted, static assets will be pulled from your CDN, significantly improving load times and reducing server strain.
00:32:00.640 In closing, we discussed many things and what we built gives you the knowledge to continue iterating on your application to create production-ready systems using AWS and Ruby on Rails.
00:32:27.600 Stay in touch with us; we’d love to hear your questions. We also have a Ruby Developer blog where we would love to hear your ideas for coverage topics. Thank you very much for your participation!
Edit