E2E Lift & Shift Multi-tier Web Application to AWS

E2E Lift & Shift Multi-tier Web Application to AWS

Lift & Shift Strategy | Git | Maven | S3 | Route53 | ELB | Tomcat | MySQL | RabbitMQ | Memcached

Table of contents

Project Overview & Architecture

  • In this project, we'll be hosting a Multi-tier Java Based social media web application called VProfile on AWS for production using Lift & Shift Strategy.

  • The users will access the website using an URL and that URL will be pointing to an endpoint which will be an entry mentioned in GoDaddy DNS.

  • This end-point from the user's browser will be connecting to the ELB(Elastic Load Balancer) by using HTTPS. This load balancer will be in a Security Group which only allows HTTPS requests.

  • The Certificate for HTTPS encryption will be mentioned in ACM(Amazon Certificate Manager).

  • Then our application load balancer will route the application traffic to the Tomcat server(EC2 instance where Tomcat is set up) because our application will be hosted on the Tomcat server only. The tomcat servers will be managed by Autoscaling Group which can automatically scale in and scale out depending on the user load.

  • S3 Bucket will be connected to the Tomcat server where our project artifacts will be stored.

  • As we know our application needs certain backend services support such as SQL DB, RabbitMQ, and Memcached. These necessary services will be installed and set up in 3 different EC2 instances. The Tomcat server needs the support of these servers altogether to make the application fully functional. The information about the backend services will be mentioned in a Route53 private DNS zone. The tomcat service will access the backend server with a name mentioned in Route53 private DNS where the Private IP addresses of our backend servers will be mentioned. These backend services will be attached to a separate security group.

NB: Earlier I had set up this project stack on my local system:

Click here to see the Local Setup and Deployment of this project

AWS Services to be Implemented

  • EC2 Instances: VM for Tomcat, RabbitMQ, Memcached, and MySQL

  • ELB(Elastic Load Balancers): Nginx Replacement

  • Autoscaling: Automation for VM Scaling

  • S3/EFS Storage: Shared Storage

  • Route53: For private DNS service

  • ACM(Amazon Certificate Manager)

  • IAM: User and authentication management

  • EBS: Elastic block storage

The flow of Project Execution

  1. Login to AWS Account

  2. Create Key-Pairs

  3. Create Security Groups

  4. Lunch Instances with User Data Bash script

  5. Update IP to Name Mapping in Route53

  6. Build Application from source code in Local system

  7. Upload artifacts to the S3 bucket

  8. Download Artifacts to the Tomcat EC2 instance

  9. Setup ELB with HTTPS[Certificate from Amazon Certificate Manager)

  10. Mapping ELB Endpoint to the website name in Godaddy DNS(I have purchased DNS from GoDaddy).

  11. Verify services are connected properly

  12. Creating Autoscaling Group for Tomcat Instances.

Step-1(Creating Security Groups)

A security group acts as a firewall that controls the traffic allowed to and from the resources in your virtual private cloud (VPC). You can choose the ports and protocols to allow for inbound traffic and outbound traffic.

NB: For now we are just creating the security group for all the EC2 instances(Servers). We'll attach these security groups while lunching the instances and configuring them.

Step-1.0(Creating a Security Group for ELB)

As you can see in the above project architecture, we need a load balancer for routing the request to our application. For that, we need to specify certain security rules that will define the kind of requests that are allowed to be routed or to access our application.

Login to AWS console--> click on EC2--> Click on Security Group--> Create a security group

Initially, you will see only default security groups as below:

SG Name: VProfile-ELB-SG

Editing in-bound rules:

In the Inbound rule section, we define the IP address range from which our application will be accessible. So our inbound rule for this load balancer will look like the below:

As our load balancer will encounter access from normal users, we have given access to HTTP and HTTPS ports.

Step-1.1(Creating Security Group for Tomcat Server)

SG Name: VProfile-app-SG

Editing in-bound rules:

The Tomcat server runs on port 8080 hence, we are opening port 8080 below.

For the Tomcat server, the request will only come from our ELB hence, we just need to allow access to our ELB by attaching the Security Group of the ELB as the Source. So that, when ELB redirects the request to the Tomcat instance, it'll validate from its security group.

Step-1.2(Creating Security Group for Backend Services)

SG Name: VProfile-BackendServics

Our backend services include MySQL, Memcached, and RabbitMQ all together.

These services will interact with each other as well as with the Tomcat Server.

So, in this Security Group, we have added 4 Inbound Rules. 3 for different ports such as 5672, 11211, and 3306 for RabbitMQ, Memcached, and MySQL respectively. The highlighted one allows all traffic that enables internal routing/communication among all these 3 backend services hence its source is this security group itself.

Editing outbound rules:

Outbound rules define the requests that can go out from our servers. And our servers should be able to route traffic everywhere and should be able to send responses to all IP addresses hence, the outbound rules remain unchanged to All Traffic:

Step-2(Creating Login Key Pair)

Click on Key Pairs--> Create Key Pair--> Fill in the configuration--> Click on Create Key Pair at the bottom

Here I have chosen .pem type as the Key format as I'll be connecting to the instance through GitBash. If you are connecting with Putty you can go with .ppk.

Step-3(Lunching EC2 Instances)

After creating the Security Key, we'll lunch our required EC2 instances for our respective services such as Tomcat, RabbitMQ, MySQL, etc.

While launching the instances we'll use User Data and we'll provide the Shell Script we prepared previously for each service while doing manual provisioning.

User Data: it is an advanced way of launching EC2 instances that will automate the dependency installation, service installation, etc through the shell script provided and will give us a fully prepared server for our use. This user data eliminates the effort for manual provisioning or setup of services after launching the instance.

Step-3.1(Lunching Instance for MySQL-DB)

Instance OS: CentOS 7

For MySQL we require CentOS 7 hence, we are selecting the same from AWS Market Place.

Instance Type: t2.micro

Our instance type should be t2.micro which provides the below configuration and it's a free tire.

Instance Name and tags: VProfile-DB01, Project: VProfile

Key Pair: VProfile-Prod-Key

Every time we lunch any instance we need a Key Pair and for our instances, we have already created a Key-Pair which is VProfile-Prod-Key hence, we are just using that instead of creating a new pair.

Security Group: VProfile-BackendServices-SG

Whenever any instance is launched, it requires a Firewall(Security Group) to be attached to it to control the traffic. We have already prepared the Security Group configuration in Step-1.2 for Backend Services. As MySQL is one of the Backend Services it will be attached to the respective Security Group.

Advanced Details-> User Data:

In this section, we have defined the shell script for Service installation and configuration. And the script is also written below.

#!/bin/bash
DATABASE_PASS='admin123'
sudo yum update -y
sudo yum install epel-release -y
sudo yum install git zip unzip -y
sudo yum install mariadb-server -y


# starting & enabling mariadb-server
sudo systemctl start mariadb
sudo systemctl enable mariadb
cd /tmp/
git clone -b vp-rem https://github.com/devopshydclub/vprofile-repo.git
#restore the dump file for the application
sudo mysqladmin -u root password "$DATABASE_PASS"
sudo mysql -u root -p"$DATABASE_PASS" -e "UPDATE mysql.user SET Password=PASSWORD('$DATABASE_PASS') WHERE User='root'"
sudo mysql -u root -p"$DATABASE_PASS" -e "DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1', '::1')"
sudo mysql -u root -p"$DATABASE_PASS" -e "DELETE FROM mysql.user WHERE User=''"
sudo mysql -u root -p"$DATABASE_PASS" -e "DELETE FROM mysql.db WHERE Db='test' OR Db='test\_%'"
sudo mysql -u root -p"$DATABASE_PASS" -e "FLUSH PRIVILEGES"
sudo mysql -u root -p"$DATABASE_PASS" -e "create database accounts"
sudo mysql -u root -p"$DATABASE_PASS" -e "grant all privileges on accounts.* TO 'admin'@'localhost' identified by 'admin123'"
sudo mysql -u root -p"$DATABASE_PASS" -e "grant all privileges on accounts.* TO 'admin'@'%' identified by 'admin123'"
sudo mysql -u root -p"$DATABASE_PASS" accounts < /tmp/vprofile-repo/src/main/resources/db_backup.sql
sudo mysql -u root -p"$DATABASE_PASS" -e "FLUSH PRIVILEGES"

# Restart mariadb-server
sudo systemctl restart mariadb


#starting the firewall and allowing the mariadb to access from port no. 3306
sudo systemctl start firewalld
sudo systemctl enable firewalld
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-port=3306/tcp --permanent
sudo firewall-cmd --reload
sudo systemctl restart mariadb

Lunch Instance:

Finally, the instance for MySQL DB is up and running. It will take some time to configure and be stable as it will be executing the above shell script for setting up the entire Database.

SSH Connection to DB Instance:

So, to connect to the DB instance through SSH we have to Open SSH port 22 in the security Group and the Source should only be My IP as it should only allow me to access the server.

Then move into the directory where the Security Key is downloaded and make an SSH request with the command: $ ssh -i directoryName/VProfile-Prod-Key.pem centos@publicIPOfInstance

Checking the process completion: ef -ps

DB Setup has been completed.

Checking DB Status: systemctl status mariadb

Logging into the DB: mysql -u root -p

Finally, we have completed our MySQL provision.

Step-3.2(Lunching Instance for Memcache)

Instance OS: CentOS 7

For Memcached we require CentOS 7 hence, we are selecting the same from AWS Market Place.

Instance Type: t2.micro

Our instance type should be t2.micro which provides the below configuration and it's a free tire.

Instance Name and tags: VProfile-Memcache01, Project: VProfile

Key Pair: VProfile-Prod-Key

Every time we lunch any instance we need a Key Pair and for our instances, we have already created a Key-Pair which is VProfile-Prod-Key hence, we are just using that instead of creating a new pair.

Security Group: VProfile-BackendServices-SG

Whenever any instance is launched, it requires a Firewall(Security Group) to be attached to it to control the traffic. We have already prepared the Security Group configuration in Step-1.2 for Backend Services. As Memcache is one of the Backend Services it will be attached to the respective Security Group.

Advanced Details-> User Data:

In this section, we have defined the shell script for Service installation and configuration. And the script is also written below.

#!/bin/bash
sudo yum install epel-release -y
sudo yum install memcached -y
sudo systemctl start memcached
sudo systemctl enable memcached
sudo systemctl status memcached
sudo memcached -p 11211 -U 11111 -u memcached -d

Lunch Instance:

Finally, the instance for MySQL DB is up and running. It will take some time to configure and be stable as it will be executing the above shell script for setting up the entire Memcached service.

SSH to Memcache

The same steps will be followed to connect through SSH.

$ ssh -i directoryName/VProfile-Prod-Key.pem centos@publicIPOfInstance

Memcached has been successfully set up.

Step-3.3(Lunching Instance for RabbitMQ)

Instance OS: CentOS 7

For RabbitMQ we require CentOS 7 hence, we are selecting the same from AWS Market Place.

Instance Type: t2.micro

Our instance type should be t2.micro which provides the below configuration and it's a free tire.

Instance Name and tags: VProfile-RabbitMQ01, Project: VProfile

Key Pair: VProfile-Prod-Key

Every time we lunch any instance we need a Key Pair and for our instances, we have already created a Key-Pair which is VProfile-Prod-Key hence, we are just using that instead of creating a new pair.

Security Group: VProfile-BackendServices-SG

Whenever any instance is launched, it requires a Firewall(Security Group) to be attached to it to control the traffic. We have already prepared the Security Group configuration in Step-1.2 for Backend Services. As RabbitMQ is one of the Backend Services it will be attached to the respective Security Group.

Advanced Details-> User Data:

In this section, we have defined the shell script for Service installation and configuration. And the script is also written below.

#!/bin/bash
sudo yum install epel-release -y
sudo yum update -y
sudo yum install wget -y
cd /tmp/
wget http://packages.erlang-solutions.com/erlang-solutions-2.0-1.noarch.rpm
sudo rpm -Uvh erlang-solutions-2.0-1.noarch.rpm
sudo yum -y install erlang socat
curl -s https://packagecloud.io/install/repositories/rabbitmq/rabbitmq-server/script.rpm.sh | sudo bash
sudo yum install rabbitmq-server -y
sudo systemctl start rabbitmq-server
sudo systemctl enable rabbitmq-server
sudo systemctl status rabbitmq-server
sudo sh -c 'echo "[{rabbit, [{loopback_users, []}]}]." > /etc/rabbitmq/rabbitmq.config'
sudo rabbitmqctl add_user test test
sudo rabbitmqctl set_user_tags test administrator
sudo systemctl restart rabbitmq-server

Lunch RabbitMQ

SSH to RabbitMQ

The same steps will be followed to connect through SSH.

$ ssh -i directoryName/VProfile-Prod-Key.pem centos@publicIPOfInstance

Step-3.4(Lunching Instance for Tomcat)

Instance OS: Ubuntu 20

For RabbitMQ we'll use Ubuntu hence, we are selecting the same from AWS Market Place.

Instance Type: t2.micro

Our instance type should be t2.micro which provides the below configuration and it's a free tire.

Instance Name and tags: VProfile-RabbitMQ01, Project: VProfile

Key Pair: VProfile-Prod-Key

Every time we lunch any instance we need a Key Pair and for our instances, we have already created a Key-Pair which is VProfile-Prod-Key hence, we are just using that instead of creating a new pair.

Security Group: VProfile-app-SG

Whenever any instance is launched, it requires a Firewall(Security Group) to be attached to it to control the traffic. We have already prepared the Security Group configuration in Step-1.1 for Tomcat Service. As Tomcat is a service where our app will be hosted hence it has a separate configuration of Security Group.

Advanced Details-> User Data:

#!/bin/bash
sudo apt update
sudo apt upgrade -y
sudo apt install openjdk-8-jdk -y
sudo apt install tomcat9 tomcat9-admin tomcat9-docs tomcat9-common git -y

We have taken Ubuntu here just because the Tomcat installation is much simpler in Ubuntu than in CentOS.

Lunch Tomcat

Accessing tomcat

Step-4(Updating Route53 Private DNS Zone)

This will be the hosted zone for VProfile backend services. A private hosted zone only responds to queries coming from within the associated VPC and it is not used for hosting a website that needs to be publicly accessed. So, this will enable our backend services such as MySQL, RabbitMQ, and Memcached to interact with each other and the Tomcat server through a given domain name instead of its IP address directly.

Move to Route53 Dashboard:

Step-4.1(Creating a hosted zone)

Here we are creating a Private hosted zone for our backend services. On the above image you can see, the domain name for the hosted zone is Vprofile.in.

As the type is chosen as Private Hosted Zone, this will route traffic within a defined VPC. It is not accessible on Open Internet

The region is N. Virginia and the VPC is a default VPC.

Step-4.2(Creating Records)

In the hosted zone vprofile.in we'll create records of our backend services.

We'll be creating 3 records for MySQL(DB01), Memcached(mc01), and RabbitMQ(rmq01) respectively:

In all the above 3 records are simple A records. we have defined the name, record type, and value as the Private IP address of the respective server.

Finally, you can see all highlighted private IP address values are assigned against a record name e.g MySQL server is assigned to a name db01.vprofile.in

Now, we can use db01.vprofile.in instead of directly using the IP address as 172.31.22.44

Step-5(Building Artifact from Source Code)

Here we'll build the project that will create the artifacts(a deployable .war file) and then we'll deploy the application as a .war file to the Tomcat server.

To do so:

  • We'll first build the project in our Local System and create the artifacts(.war file)

  • Then we'll upload the artifact to S3 Bucket

  • From the S3 Bucket, Tomcat will fetch the artifact and it will be deployed in the Tomcat server.

Step-5.1(Git clone the project)

Clone the project to the local system :

git clone https://github.com/rkn1999/vprofile-project.git

Checkout to the branch: git checkout aws-LiftAndShift

move to the project directory vprofile-project/src/main/resources where the application.properties file is present

Step-5.2(Configuring application.properties )

#JDBC Configutation for Database Connection
jdbc.driverClassName=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://db01.vprofile.in:3306/accounts?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull
jdbc.username=admin
jdbc.password=admin123

#Memcached Configuration For Active and StandBy Host
#For Active Host
memcached.active.host=mc01.vprofile.in
memcached.active.port=11211
#For StandBy Host
memcached.standBy.host=127.0.0.2
memcached.standBy.port=11211

#RabbitMq Configuration
rabbitmq.address=rmq01.vprofile.in
rabbitmq.port=5672
rabbitmq.username=test
rabbitmq.password=test

#Elasticesearch Configuration
elasticsearch.host =192.168.1.85
elasticsearch.port =9300
elasticsearch.cluster=vprofile
elasticsearch.node=vprofilenode

In the above configuration, you can see that we have used the Private DNS from route53 for MySQL, RabbitMQ, and Memcached services instead of using direct IP addresses.

Step-5.3(Building Artifact in Local System)

To build the project and generate the artifact we'll use the Maven build tool.

So, now move back to the project root directory where the pom.xml file is present, This pom.xml file will help us to build and generate the artifact.

Now, start the build simply use: mvn install and it will download the dependency, compile the Java code and generate the artifact in our local system as shown below:

Now, the build has been successful:

Now, a target directory has been created additionally after the build is successful;

Inside the target directory, we have our vprofile-v2.war file which we'll upload to the S3 Bucket currently it's present in our local system:

Step-6(Uploading Artifact to S3)

As we have generated the .war file in the Build section, now we'll upload this artifact vprofile-v2.war to a S3 Bucket. To do so:

  • We have to connect to the AWS console via an IAM user through AWS CLI

  • Configure AWS CLI and create an S3 bucket through AWS CLI

  • The IAM user should have the permission of AmazonS3FullAccess to access the S3 bucket

Create an access key for the particular user to access AWS CLI

Step-6.1(Configuring AWS CLI)

AWS S3 Commands

Use the command: aws configure

It will further prompt for the access key, secret access key, region and output format as below:

AWS CLI configuration is done.

Step-6.2(Creating S3 Bucket through AWS CLI)

Once the configuration is done with the AWS CLI through the IAM access key and secret key, we need to create an S3 Bucket where our Artifact will be uploaded. To do so below is the syntax:

aws s3 mb s3://bucket-name

NB: the bucket name should be unique around the world.

Command: aws s3 mb s3://vprofile-artifact-repo-ritesh100

Finally, the bucket has been created with the name: vprofile-artifact-repo-ritesh100

Step-6.3(Uploading Artifacts to S3 Bucket)

Now, we'll simply upload the vprofile-v2.war to our bucket vprofile-artifact-repo-ritesh100 .

The Syntax: aws s3 cp filename.txt s3://bucket-name

Copying:

aws s3 cp vprofile-v2.war s3://vprofile-artifact-repo-ritesh100/vprofile-v2.war

aws s3 ls s3://vprofile-artifact-repo-ritesh100 : verifying from the CLI

Now the upload from CLI has been completed. Let's verify from S3 console:

Hence, we conclude the artifact upload. !!

Step-7(Downloading Artifact to Tomcat Instance from S3)

Our next goal is to download this artifact to the Tomcat EC2 instance. As we have uploaded the artifact to the S3 bucket now, we'll download the artifact to the EC2 Instance where the Tomcat server is up and running. To do so, we have to follow below steps:

  • Create a new role that has S3 access and attach this role to the Tomcat EC2 instance

  • Open the SSH connection port for the Tomcat instance

Step-7.1(Creating Role S3 access role for Tomcat Instance)

Here firstly, we'll create a Role with the permission of S3 AllAccess that will enable our Tomcat Server to access the S3 bucket and download the artifact.

To do so: IAM --> Roles --> Create Role

Keep the configuration as below as we are creating this role for the EC2 instance --> click Next

In the permission section choose AmazonS3FullAccess as shown below:

And create the role accordingly.

Step-7.2(Attaching S3 access Role to Tomcat Instance)

Now, we'll be attaching the role created for S3 access to our Tomcat Server.

To do so:

Go to the particular EC2 instance and in Actions change go to Security and Modify IAM Role

Inside Modify IAM role attach the role named vprofile-artifact-s3-role and update the IAM role.

Finally, the Role for accessing S3 Bucket has been attached and now our Tomcat server will be able to connect to S3 and access the Artifact.

Step-7.3(Connecting to S3 from Tomcat Instance)

Now we'll connect to the S3 bucket from our Tomcat instance using AWS CLI.

NB: EC2 instances do not have AWS CLI pre-installed. We have to install and configure it.

sudo apt update && sudo apt install awscli -y

let's verify if we can see the .war file in the Tomcat server using AWS CLI

aws s3 ls s3://vprofile-artifact-repo-ritesh100

Step-7.4(Copying Artifact from S3 to Tomcat Server)

Now as we are able to see the war file we can copy it to the Tomcat instance by:

aws s3 cp s3://vprofile-artifact-repo-ritesh100/vprofile-v2.war /tmp/vprofile-v2.war

Using the above command we have copied the vprofile-v2.war artifact from s3://vprofile-artifact-repo-ritesh100 bucket to /tmp/ directory of the Tomcat Instance with the same name.

Finally, we have got the artifact in our Tomcat Instance that we created from our source code in our local system via using S3 Bucket.

Step-8(Application Deployment to Tomcat Service)

As we know the Artifact vprofile-v2.war is currently present in the /tmp directory. We have to deploy this in Tomcat. Before deploying we have to shut down the Tomcat service by the command :systemctl stop tomcat9

Now, we have to move to its web apps directory where Tomcat's default dummy application is present inside the ROOT directory:

cd /var/lib/tomcat9/webapps/

And now we have to replace this ROOT directory with our vprofile-v2.war simply by copying it to the /webapps folder. To do so:

we have to remove the ROOT first: rm -rf ROOT

Now finally, we'll copy our artifact over here using the below command:

cp /tmp/vprofile-v2.war ./ROOT.war

Here we have copied our vprofile-v2.war from /tmp folder to /webapps folder as ROOT.war and . refers to the current directory(/webapps)

Now, let's restart the Tomcat Service:

systemctl start tomcat9 : with this now another ROOT folder has been created where vprofile-v2.war is extracted and stored as a deployable Application.

Now, let's verify if our Application Server(Tomcat) is able to connect to the Backend services(DB, Memcached, RabbitMQ). We can do that by doing telnet to the backend server as below:

telnet db01.vprofile.in 3306 : telneting to DB

telnet mc01.vprofile.in 11211 : telneting to Memcached

telnet rmq01.vprofile.in 5672 : telnetting to RabbitMQ

Step-9(Setting up Load Balancer)

As we have completed the application deployment to the Tomcat server, our next goal is to make it accessible to the Users on the internet. To do so, we need a mediator between our tomcat Server and the public internet. Previously we have used Nginx for this purpose however, now we'll be using AWS ELB(Elastic Load Balancer).

ELB (Elastic Load Balancer) and Nginx are both popular solutions for load balancing in web application architectures.

Step-9.1(Creating a Target Group)

Before creating an Application Load Balancer, we have to create a target group.

In Elastic Load Balancer (ELB), a target group is a logical grouping of instances or services that the load balancer directs traffic to. It acts as a routing mechanism within the load balancer, determining how incoming requests are distributed among the targets.

Now, under EC2 move to Load Balancing, and under Load Balancing there is Target Group. Click on that and create a Target Group.

So, our Target Group name will be VProfile-App-TG , the target group is created for Ec2 Instance(Tomcat Server) so the target type is Instance , the Tomcat service runs on port 8080 so the port is defined as 8080 , VPC remains the default, and the path refers to the URL path that is used for health checks against the registered targets so, here our path for the app is /login .

Now our Target Group is created:

Step-9.2(Registering the Target Group with Tomcat Instance)

After creating the Target Group, we'll have to register it with our targeted EC2 instance which is our Tomcat Instance. To do so, select the target group and in actions click on Register and deregister instance/ IP targets:

And then choose the respective Instance VProfile-Tomcat01 click on Add to registered on port 8080 and then save as below:

Finally, our Target Group has been created and attached to Tomcat Server. Currently, it demands a Load Balancer to be fully functional:

Step-9.3(Creating Load balancer)

here we'll be creating the Load Balancer and this load balancer will further be attached to the Target Group named VProfile-App-TG .

To create the Load Balancer: go to Load Balancer --> click on Create Load Balancer and then choose the first one that says Application Load Balancer

And make the configuration as below:

The name of the ELB is VProfile-prod-ELB .

VPC is set to Default and Mappings can be 2 or more than 2 Availability Zones. Here we have selected all the AZs that will make our application highly available:

Security Group is set to the security group VProfile-ELB-SG that we created especially for Load Balancers at the very beginning as a basic configuration:

Listeners contain the ports to which our ELB will respond. Here we have opened the ports HTTP and HTTPS. It's recommended to only open HTTPS:

And in the Secure Listeners setting we have to attach the SSL/TSL certificate for our website. I have already purchased a domain from GoDaddy and validated it with ACM(Amazon Certificate Manager). Am attaching the Load Balancer to that SSL domain devopswithritesh.in

Now simply click on Create Load Balancer.

And our Load Balancer is now active:

Step-9.4(Registring ELB DNS with the Domain provider GoDaddy)

As we have created the Load Balancer now, we have to create a CNAME record with our domain name DNS in our Domain provider portal(GoDaddy).

To do so:

We have to take the DNS of our Load Balancer VProfile-prod-ELB from the description and create a CNAME record in devopswithritesh.in .

Finally, we have created a CNAME and the website will be referred as:

https://vprofileapp.devopswithritesh.in

When the users hit the above URL, it will point to our Load Balancer VProfile-prod-ELB and the load balancer will further redirect the traffic to the Tomcat Server where our application is situated.

Finally, our app is accessible on the open internet with the above-said URL.

Auto-Scaling

Autoscaling is a technique used in cloud computing to automatically adjust the capacity of a system or application based on the current demand. So, to make our application highly scalable we have to create Autoscaling Group and attach it to our App server.

To do so we have to go to the auto-scaling group section:

Pre-requisite for Autoscaling Group

AMI(Amazon Machine Image) Creation

To create an autoscaling group we need an Image of the Tomcat Instance. This image will further be used while creating the autoscaling group. And the auto scaling group will fire up instances with the same configuration as the existing Tomcat Instance when traffic increases.

To do so: select the tomcat instance and follow the below:

And with the below configuration create the image.

Now the AMI(Amazon Machine Image) is being created:

Creating lunch configuration(Vprofile-app-LunchConfiguration)

A launch configuration specifies various parameters for instances, including the Amazon Machine Image (AMI) to use, instance type, storage options, etc. Launch configurations are often used in conjunction with autoscaling groups, which manage the scaling behavior and policies. Autoscaling groups rely on launch configurations to create and configure instances automatically based on the defined rules and triggers.

While creating the Lunch Configuration make sure all the configuration should be the same as the server whose AMI is being used. Our configuration is as below:

Lunch configuration has been created:

Creating Autoscaling Group(VProfile-app-ASG )

The autoscaling group configuration should be as below:

Now finally, our autoscaling group has been created:

Summary

Finally, we are done with a scalable deployment of a Java-based social media application. Here we have used Lift & Shift strategy.

  • The user will use the URL https://vprofileapp.devopswithritesh.in/login

  • This URL is hosted on my personal domain from GoDaddy.

  • The user request from the URL will be redirected to the ELB(Elastic Load Balancer)

  • The ELB further redirects it to the Tomcat Server where our application is hosted as a .war file. The Tomcat service further interacts with several backend services such as MySQL, RabbitMQ, and Memcached.

  • The Tomcat Service fetched this .war file from the S3 bucket.

  • The .war file was built from the Source code using the Maven build tool in our local system and was uploaded to an S3 Bucket

  • The source code was cloned to our local system from the repository: https://github.com/rkn1999/vprofile-project.git