This is the second post in a series of blog posts that describe how to deploy a Rails application to Elastic Beanstalk in a Virtual Private Cloud (VPC) on Amazon AWS.
In the previous post we configured a new VPC with public and private subnets along with security groups for our servers.
In this post we’ll setup a new Elastic Beanstalk application and deploy it in our VPC.
We’ll be setting up a Rails application for this example and initially we’ll just deploy the sample application.
The first thing we’ll do is create the Elastic Beanstalk application and pick Ruby as our platform:
We then click the “Configure More Options” button so we can control the setup in more detail. The first thing that we want to configure is platform configuration:
I going to be deploying a Rails 5 application that uses Puma - so I want to make sure Elastic Beanstalk matches my local configuration:
We want to use an Elastic Load Balancer to expose our Application to the internet - a quick way to get the basics for this configured is to select the “High Availability” radio box and then customise the defaults that gives you.
The main settings we will need to change are on the “Network” card. On this card we pick the VPC that we want to deploy our application to and set our Load Balancer to publicly visible:
We can then select the subnets that we want our Load Balancer to run in. For our deployment this should be the public subnets we created in step 1.
For our instances, we want these placed in our private subnets and we don’t want to assign a public IP address to them. All access to our instances will be via the Load Balancer so these machines definitely don’t need to be publicly accessible.
Finally we want to set the security group for our instances. In our case this will be the “Web Server” security group. This security group does not actually open any ports on our instances. What it does provide is access to our database security group. Under the hood, when instances are added to our load balancer an additional security group is added automatically that allows access to ports 80/443 from the load balancer.
For the database card - we leave this blank so that we can create a database instance independently from our elastic beanstalk environment. This gives us a bit more flexibility on the lifetimes of our Elastic Beanstalk and our RDS instances (you may want to terminate an Elastic Beanstalk application but re-use your RDS instance).
Assuming all goes well, once the environment has launched you should see the sample application up and running on Elastic Beanstalk.