Step 1 - Setup VPC: Deploying a Rails Application to Elastic Beanstalk

View All Posts

read

Want to keep up to date with the latest posts and videos? Subscribe to the newsletter

· · · · · Posts · Videos · Tags · Support

« Raspberry Pi BTLE Device

Step 2 - Setup Elastic Beanstalk: Deploying a Rails Application to Elastic Beanstalk »

HELP SUPPORT MY WORK: If you're feeling flush then please stop by Patreon Or you can make a one off donation via ko-fi

#AWS #DEPLOYMENT #ELASTIC BEANSTALK #RAILS #VIRTUAL PRIVATE CLOUD

This is the first 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 this post we will setup a new VPC to host our Elastic Beanstalk application and Database servers.

This involves the creating the following objects:

A new VPC
Public and Private subnets in each availability zone
An Internet Gateway and routing table entries for the public subnets
A NAT gateway and routing table entries for the private subnets
Security groups for a Bastion server, Web servers and Database servers

At the end of this we will have something that looks like the diagram below:

VPC Setup With Public and Private Subnets

You can download this image for your own use as a PDF, SVG, PNG, Sketch.

The video embedded below walks you through this process:

VPC setup

To configure a VPC you need to select a range of private IP addresses. Valid ranges for these are:

Start	End
10.0.0.0	10.255.255.255
172.16.0.0	172.31.255.255
192.168.0.0	192.168.255.255

When you setup a VPC you configure the address space using CIDR format. The minimum number of mask bits that you can use is 16. This gives you a maximum number of ip addresses in a VPC of 65534. We’ll divide this address space up among the subnets that we will create in our VPC.

For the example in this blog post and associated video I’ve used 10.0.0.0/16. You can use this handy CIDR calculator for working out address ranges.

Create VPC

For the tennancy make sure this is set to default. If you change this to dedicated then every instance you launch in your VPC will use dedicated hosting (even if you specify a different setting when you create the instance).

Subnet Setup

To support failover between availability zones you need to have a subnet in each availability zone. As we are creating a public and private set of subnets we will need 2 subnets in each zone.

To make distinguishing public and private subnets easier I use the convention of starting my public subnets at 10.0.0.0 and my private subnets at 10.0.100.0.

Zone	Subnet CIDR	Subnet Name
A	10.0.0.0/24	Public Subnet A
B	10.0.0.0/24	Public Subnet B
C	10.0.0.0/24	Public Subnet C
A	10.0.0.0/24	Private Subnet A
B	10.0.0.0/24	Private Subnet B
C	10.0.0.0/24	Private Subnet C

Create a subnet

Depending on the AWS region you are creating, you may have more availability zones. You should create additional subnets to cover all the zones in your region.

Public and Private subnets in each availability zone

Internet Gateway

To comminicate from our public subnet to the internet and for the internet to be able to see machines running inside our public subnet we need to add an internet gateway. We also need to add routing tables so that our VPC router knows how to route traffic to our internet gateway.

We create an internet gateway:

Create an internet gateway

Attach it to our VPC:

Attach Internet Gateway to our VPC

To setup the routing for out inernet gateway we create a new routing table in our VPC:

This new routing table is associated with our Public Subnets:

And we add a new route with a destination of 0.0.0.0/0 with a target of our internet gateway.

This means that instances in our public subnet can communicate to the internet and that the internet can now see instances in our public subnet.

NAT Gateway

For our private subnets we don’t want our instances to be visible from the internet, but we do want the instances to be able to access the internet. For this we will create a NAT gateway.

Associate it with our Private Subnets and create a route with a destination of 0.0.0.0/0 and target of our new NAT gateway.

Security Groups

We will need the following security groups configured for our VPC:

Bastion Servers
Web Servers
Database Servers

For our bastion server we want a much security as possible. Ideally we should only open port 22 for ssh and only allow connections from our own IP address.

For added security you should add 2 factor authentication to your bastion server and only have it running when you need to use it. The rest of the time you should turn off the instance that is running your bastion server.

The web server security group can be setup with no incoming ports. We should not need to ssh onto our web servers as any configuration should be taken care of by our Elastic Beanstalk environment. Access to HTTP(S) ports is added automatically by the Elastic Load Balancer.

For our Database Servers, we need to open a port for our database (for Postgresql this is 5432) and allow access from our Web Server security group and also from our Bastion Server security group. You may only want to add access from the Bastion Server group on an as needed basis.

All done!

That concludes configuring our VPC. We’ve setup public and private subnets in our availability zones, create Internet and NAT gateways along with the necessary routing tables, and we’ve created a set of security groups for controlling access to the instances we deploy to our VPC.

In the next post we’ll deploy an Elastic Beanstalk application in our VPC.

#AWS #DEPLOYMENT #ELASTIC BEANSTALK #RAILS #VIRTUAL PRIVATE CLOUD

Step 2 - Setup Elastic Beanstalk: Deploying a Rails Application to Elastic Beanstalk - In this post, I describe how to set up, configure and deploy an Elastic Beanstalk application on a VPC in Amazon AWS, using Rails 5 and Ruby, using Puma for deployment and configuration of Public and Private subnets in Elastic Load Balancer. I also cover the details of network card settings, the selection process for subnets and security groups for Load Balancer and Instances, and finally shared the result of deploying the sample application on Elastic Beanstalk.

Step 4: Deploy Rails App To Elastic Beanstalk from Command Line - This post guides you through the essential steps of creating and deploying a Rails application into Elastic Beanstalk environment. Topics include creating an AWS user, configuring AWS CLI for deployment, and setting up the environment variables for your app. Also, it provides you the valuable knowledge of connecting your Rails app to RDS instance and ensuring it successfully connects with the dev database.

Step 5: Use CircleCI to Deploy To Elastic Beanstalk - In this blog post, we're going to set up an automated deployment pipeline using CircleCI, GitHub, and AWS Elastic Beanstalk. We'll begin by creating a GitHub repository for our Rails application. Next, we're going to help CircleCI understand our build environment by creating a `circle.yml` file to install the AWS EB CLI tools and to define commands for deploying our application. Lastly, we'll set up the required AWS credentials in CircleCI. Once completed, any changes pushed to the develop or master branch in GitHub will trigger a deployment to the respective environment in Elastic Beanstalk.

Step 3 - Configure RDS: Deploying a Rails Application to Elastic Beanstalk - We're moving on and tightening our database security in step 3. We're running our database in private subnets within a created RDS instance on our VPC, making sure our data isn't accidentally left in the open. After setting up our network and security settings, we'll dive into creating our databases manually via our secure Bastion server. With a few commands, we set up our dev and prod databases, don them with strong passwords and grant them access to our master username. Voila, our RDS instance is ready to go! Stay tuned for step 4, where we unveil the real deal, deploying a Rails app.

Step 6: Add a Custom Domain and SSL to Elastic Beanstalk - In this post, we successfully set up a custom domain name for our Elastic Beanstalk environment and secured it using SSL. By creating a CNAME or an ALIAS pointing at our environment URL (found on the dashboard screen), we made our app accessible via the new domain name. We then used AWS Certificate Manager to add SSL to our environment for access over HTTPS, which was confirmed by visiting the secured site. Now we have a Rails application that can not only be deployed by a CI server, but is also SSL secured with a custom domain.