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!
