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
Login to AWS Account
Create Key-Pairs
Create Security Groups
Lunch Instances with User Data Bash script
Update IP to Name Mapping in Route53
Build Application from source code in Local system
Upload artifacts to the S3 bucket
Download Artifacts to the Tomcat EC2 instance
Setup ELB with HTTPS[Certificate from Amazon Certificate Manager)
Mapping ELB Endpoint to the website name in Godaddy DNS(I have purchased DNS from GoDaddy).
Verify services are connected properly
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.
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
sudo systemctl start mariadb
sudo systemctl enable mariadb
cd /tmp/
git clone -b vp-rem https://github.com/devopshydclub/vprofile-repo.git
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"
sudo systemctl restart mariadb
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.
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.
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.
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.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.active.host=mc01.vprofile.in
memcached.active.port=11211
memcached.standBy.host=127.0.0.2
memcached.standBy.port=11211
rabbitmq.address=rmq01.vprofile.in
rabbitmq.port=5672
rabbitmq.username=test
rabbitmq.password=test
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:
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
