Forem: Nikhil Wilson

3-Tier Architecture in Azure Cloud: A Comprehensive Deployment Guide

Nikhil Wilson — Mon, 18 Nov 2024 18:01:00 +0000

This project demonstrates a robust and scalable 3-tier architecture deployed in Microsoft Azure, showcasing best practices for cloud infrastructure design. A special thanks to Piyush Sachdeva for hosting the #10weeksofcloudops challenge. This blog represents my take on the second week's challenge.The architecture provides several key benefits:

Improved Security: Network segmentation through subnets and network security groups
High Availability: Utilize VM scale sets and load balancers
Scalability: Automatic scaling based on resource utilization
Performance: Distributed application tiers with efficient traffic routing

The architecture follows a classic 3-tier model:

Web Tier: This is the user interface (UI) of the application. The web tier is responsible for interacting with the users and presenting the data retrieved from the app tier. In this case, it is built using React, a JavaScript library for building dynamic user interfaces.

Application Tier: The application tier handles business logic and data processing. It receives requests from the frontend and communicates with the database to retrieve or modify data.

Database Tier: The database tier is responsible for storing and retrieving the data required by the application. In this project, a MySQL database is used to store user data, application configurations, and other necessary information.

Lets start by creating a Resource Group for provisioning of resources.
Create a Virtual Network for the resource group.
Create Subnets for Web tier, App tier, and DB tier isolating the different tiers networks. Additionaly create subnets for the Bastion Host and ApplicationGateway which we will provision later.
Create Network security groups for the application tier, web tier and Bastion host of our architecture. We do this to add inbound security rules to control the network flow to the various tiers of the application.
For the Bastion Host, we provide access through SSH by allowing traffic through port 22.
Associate the Bastion NSG to the previosuly defined Bastion Subnet.
For the Web network security group, we will add port 80 and port 22 in the inbound rules to allow traffic through web and ssh respectively.
Associate the Web NSG to the Web subnet defined previously.
Now head to the App network security group and add port 22 for ssh access and port 4000 where our application will be listeining.
Associate the App NSG to the App subnet created previously.
For creating the Database server, we create the Azure mysql flexible server. Create a unique name for the Server name option.
Configure the server to choose appropriate sku for the database and also enable geo redundancy. We enable geo redundancy to provision high availability to the DB server in case of regional disruption to the servers.
Provision a standby server by allowing high availability to the DB server.
In the networking tab, select private access and select the vnet and DB subnet created.
Now we create an Application Gateway to allow public access to our web servers and also to load balance the incoming traffic from the web.
In the networking tab, we provide the Application gateway subnet provisioned previously which is a requirement for the application gateway.
For the frontend or the web tier access, let us create a public IP. From the frontend tab, create a new public IP.
In the backends tab, create a backend pool without providing targets for now. We will add the IPs of the Web Virtual machines after we provision them and install the frontend code to the VM.
From the configurations tab, we add a routing rule to the application gateway. Here we provide the Http protocol and port 80 to allow web traffic through the Application Gateway.
In the backend targets, create a backend settings by providing the following values.
Now we create the Bastion Vm, Web VM and App Vm. Select the resource group and provision a Ubuntu image which is available.
Here we create the Bastion VM.
Now in the networking tab, we attach the vnet and Bastion subnet which we created previously.
Create the Web VM and App VM in the same format. Then attach the Web subnet and App subnet to their respective VMs.
Now we connect to the Bastion VM to access the Web VMs and App VMs for secure access. I have used a pair key value for the VMs created and have uploaded it to my azure cli. After that I have moved the key configuration to ~/.ssh/ and run chmod 400 'key_file_name'. After this access the VM by providing the key value with the ssh command.
Now we head to create the app and web tier with our application code. SSH into the AppVM by using the private ip provisioned for the VM. I have forked the github repo by Nishant Singh for the application code, web code, and configuration scripts. https://github.com/thakurnishu/10_Weeks_Of_CloudOps and checkout to week2 branch to get the steps to implement the app backend and web frontend code and also to setup the database
Modify the DBConfig.js with the values respective to your mysql DB server.
We also modify the server parameters to switch off require_secure_transport from the mysql server menu.
Also modify the sql host and add sql admin user name in the AppTier.sh config file before running the AppTier.sh script.
Now we run the AppTier.sh file to create the DB and also test the application. If we get response from the DB as follows, then the script ran successfully.
Now we create an Internal load balancer to balance the traffic from the frontend web-tier to the backend app-tier. From create a resource, name the internal load balancer and select internal as the type of load balancer.
Now for the frontend configuration, we add the web subnet.
Now for the Backend pool, we add the IP configuration of the AppVM for the app-tier part.
Now we add a load balancing rule where we can provide the frontend ip address and the backend pool which we created in the previous steps. We also must provide the ports for the frontend and the backend pool.
Now we log out of the AppVM and connect to the WebVM from the BastionVM.
We fork the same repo as before and checkout week2 branch of the repo.
Vi into the ./webtier.sh script and replace the REPLACE-WITH-INTERNAL-LB-DNS with the ip of the internal load balancer from the overview of load balancer created previously.
Now we run the ./webtier.sh script which will install the necessary applications to run the frontend code and start the frontend code on the WebVM.
Now since the WebVM is up and running, we can go ahead and add the IP address of the WebVM in the ApplicationGatway in the backend pool.
Now from the overview of the application gateway and copy the public IP address provisioned for the application.
Run the application on any web browser by using the public IP provisioned of the application gateway.

We have successfully provisioned a 3 tier architecture with secure access to all the tiers. Now in order to provide high availability to our architecture, we create a VM scale sets for the web-tier and app-tier.

Now since we have the three tiers running, we can move onto create availability sets to make the web tier and app tier highly availiable for high traffic scenarios. For this we need to create VM images of the WebVM and AppVM to create availiability sets. Select the WebVM and select the capture option to create VM image.
Create a compute gallery from the creation menu to store the VM image. Select specialised option so that we can get the image with all the preinstalled application which we created through the previous steps.
Create a VM definition with the details about the VM to save.
Repeat the same steps for AppVM and now we are ready to deploy the VM scale sets for high availiabilty. First, we create VM scale set for Web tier of the architecture. From create a virtual machine scale sets, set the name of the VM and also select multiple zones for high availity features.
Select unifrom option for orchestration and keep the instance count as 2.
Select out previously stored VM image to deploy for the VM scale set. Also configure the scaling to automatic. Set custom scaling options to maximum of 10 instances and increment of 1 instance when CPU threshold crosses 80% for 10 minutes.
In the networking tab set the Subnet to the Web subnet and in the network interface options, edit to change the default subnet to the web subnet.
As discussed previously, configure the scaling options according to a preset threshold criteria.
Now in the Application Gateway option, set the backend pool to now target the Web Virtual machine scale sets instead of the Web VM.
From the Web Virtual machine scales sets, select the instances and upgrade the instances to run with the latest changes by using upgrade option.
Create the App virtual machine scale set using the same steps. Now head to the internal load balancer and select App Virtual machine scale sets IP configuration for the backend pool.
Upgrade the App virtual machine instances to run with the latest changes by using the upgrade option.

That’s it! We have created a web application with a 3 tier architecuture, highly available and highly scalable. We also created network security rules to create secure access to all the application tiers. Many thanks to Nishant Singh for his detail blog which made this project possible. Also a big shoutout to Piyush Sachdeva's 10weeksofcloudops challenge. Please check out his youtube channel for some amazing cloud tech content.

Hosting a Static Website in Azure Storage with CDN and CI/CD Pipeline Integration

Nikhil Wilson — Sat, 16 Nov 2024 08:45:38 +0000

In this blog post, we will explore how to:

Host a static website in an Azure storage container.
Create a CDN endpoint for the static website.
Connect a custom domain to the CDN endpoint.
Utilize Azure DevOps to implement CI/CD pipelines.

A special thanks to Piyush Sachdeva for hosting the #10weeksofcloudops challenge. This blog represents my take on the first week's challenge.

Architecture Overview

Step 1: Create a Resource Group

Search for Resource Group in the "Create a Resource" menu.
Create a resource group under the required subscription.

Step 2: Create a Storage Account

From the "Create a Resource" menu, search for Storage Account.
Create a storage account under the same subscription and select the resource group from the dropdown menu.

Step 3: Enable Static Website Hosting

Navigate to the Overview section of your storage account and click on Static Website under the capabilities section.
Enable the Static Website option and specify the names of your index.html and error.html files.
Upload the required HTML files to the $web container.

Step 4: Create a CDN Profile

Search for Front Door and CDN Profiles in the "Create a Resource" menu.
Select Azure CDN.

Note: Azure CDN is not available for free or student subscriptions. Upgrade to a Pay-As-You-Go subscription or another eligible plan.
Create the CDN profile in the same resource group, keeping the default settings.

Step 5: Create a CDN Endpoint

Navigate to the Endpoint Creation button in your CDN profile.
Create an endpoint, selecting Storage Static Website as the origin type. The static website name will populate automatically.

Step 6: Connect a Custom Domain

If you’ve purchased a custom domain (e.g., from Namecheap.com), log in to your registrar's dashboard.
Under the Advanced DNS tab of your domain, add two CNAME records:
- Type: CNAME
- Host: https and www
- Value: The CDN endpoint name
- TTL: Automatic
Go back to your CDN profile in Azure and add the custom domain. Azure will verify the DNS records.
Enable HTTPS for your custom domain in the CDN settings.

Congratulations! You’ve successfully hosted a static website in Azure and linked it to a custom domain.

Step 7: Implement CI/CD Using Azure DevOps

Create a new project in Azure DevOps.
Navigate to Project Settings > Agent Pools and create a new agent pool.
Download the appropriate agent for your local machine and follow the setup instructions.
Generate a Personal Access Token (PAT) under User Settings with necessary permissions. Use the PAT to configure the agent during setup.
Start the agent using ./run.sh. It will begin listening for jobs.
Create a new Service Connection under Project Settings and link it to your Azure subscription and resource group. Now if your browser disables popups automatically, please disable them for this step because resource group will not be seen until you authenticate again during this step.
Now we need to configure the CI/CD pipelines and we use the following azure-pipeline.yml file to configure it.

trigger:
- main

pool: Default

steps:
- task: AzureCLI@2
  displayName: 'Running Pipeline Script'
  inputs:
    azureSubscription: 'StaticWebsite'
    scriptType: 'bash'
    scriptLocation: 'scriptPath'
    scriptPath: 'pipeline_script.sh'

Here the trigger option refers to the github branch of the static website code repo. pool refers to the agent pool which is running in your machine. The azureSubscription refers to the service connection name which is defined earlier while creating a new service connection. Now this script runs the pipeline_script.sh file which is defined as follows.

#!/bin/bash

AccountName="personalwebsitestorage"
RG="PersonalWebsiteRG"
ProfileName="PersonalWebsiteCDN"
EndPoint="PersonalWebsiteEndpoint"

echo "--------------------------------------------------------"
echo "|   Removing previous content from CDN edge locations  |"
echo "--------------------------------------------------------"

az cdn endpoint purge \
      --name $EndPoint \
      --profile-name $ProfileName \
      --resource-group $RG \
      --content-paths "/*"


echo "--------------------------------------------------------"
echo "|           Uploading to Azure Storage Account         |"
echo "--------------------------------------------------------"

Connection_String=$(az storage account show-connection-string --name $AccountName --resource-group $RG --query connectionString -o tsv)
az storage blob upload-batch \
  -d "\$web" \
  -s "website" \
  --connection-string $Connection_String \
  --overwrite \
  --pattern "*"

Here modify the AccountName to the storage account name where the static website is hosted. In RG section, give the resource group name with which we work with. In the ProfileName section, provide the name of the CDN profile created and for EndPoint, give the name of the CDN endpoint created under the profile.

This script first purges all the cached data on the CDN edge locations and then uploads the new content to the storage account which will modify our static website through the pipeline.

Now let us setup the pipeline in Azure Devops portal. Select the project and head to the pipelines section. Create a new pipeline and select Github option.

Now select the github repo corresponding to the static website and select the existing azure pipeline yaml file option. Review the yaml file
Verify the branch of the github repo and the filename of the pipeline and run the pipeline.

Now the CI/CD pipleine is successfully setup.

That’s it! You’ve successfully set up a static website with Azure Storage, integrated Azure CDN, linked a custom domain, and implemented a CI/CD pipeline with Azure DevOps. A special thanks to Nishant Singh for his detail blog which helped immensely to create this project. Also a big shoutout to Piyush Sachdeva's 10weeksofcloudops challenge. Please check out his youtube channel for some amazing cloud tech content.

Docker fundamentals

Nikhil Wilson — Wed, 18 Sep 2024 08:17:21 +0000

This is Task 1/40 of the Certified Kubernetes Administrator(CKA) 2024 video series by Piyush Sachdeva. Tech Tutorials with Piyush
Video from Day 1 for Docker tutorials for Beginners

Docker is an open-source tool that containerizes an entire application along with its dependencies, codebase, and even the underlying operating system. Users can define a Dockerfile specifying all the necessary build requirements, pass it to the Docker daemon, and create an image of the application. This image can then be shared with others, who can simply run it to obtain a fully operational container. No more hassles with installation, fixing dependencies, or meeting other prerequisites.

Here’s a simple use case:

Imagine you're building a web application using Node.js v16.20.2 and React v16.10.1. You’ve used npm to install all the required dependencies based on the framework. Everything works fine until you share it with a friend for testing. Now your friend needs to set up a virtual machine and install the necessary frameworks and packages, or reinstall Node.js, React, and npm to match your environment. That’s time wasted—time that could be spent testing the application!

Instead, you can create a Dockerfile that handles the installation of dependencies, copies the codebase, and exposes the application’s port. After building the image, you can upload it to a registry like Docker Hub. The tester can then pull the image, run it to create a container, and—just like that—the web application is up and running for testing. This ensures that the development, testing, and production teams are all working with the same image, resolving the infamous "it works on my machine" issue.

Let’s also take a look at Docker's architecture:

The user defines a Dockerfile with all the necessary build requirements.
The Docker daemon (Dockerd) uses the Dockerfile to build an image of the application with the docker build command.
With the docker push command, the image is uploaded to a Docker image registry, such as Docker Hub, where it can be versioned and tracked.
Users can then download the image from the registry using the docker pull command.
Finally, a container is created from the image using the docker run command, and the application is ready to use.

In summary, Docker simplifies the entire process of application development, testing, and deployment by packaging everything into a single image that can be shared and run anywhere. With Docker, you eliminate the frustrating "works on my machine" issue and ensure that all teams—whether in development, testing, or production—are using the same environment.