Introduction

When it comes to deploying stateful applications like databases in Kubernetes, the primary focus shifts to data persistence and ensuring consistency as pods scale up or down. This is where Persistent Volumes (PVs) come into play allowing data to persist beyond the ephemeral lifecycle of pods.

In Azure Kubernetes Service (AKS), this persistence is powered by Azure Disks, a managed storage solution that offers high durability, reliability, and availability with an SLA of over 99%. Azure Disks simplify storage management while ensuring that your critical application data remains safe and accessible.

In this article, we’ll explore how AKS leverages persistent volumes by deploying a MySQL database along with a web application. We’ll also dive into how internal and user-facing networking components work together to make the application fully functional within a Kubernetes environment.

Storage Class in AKS

In Kubernetes, a Storage Class defines how persistent storage, such as disks or volume is provisioned dynamically for your pods. It works as a blueprint for storage that tells Kubernetes what type of storage to create when the app asks for it. A StorageClass automates the creation of PersistentVolumes (PVs) so you don’t need to manually create PVs each time an app needs storage.

When your app says:

“I need some space to save my data!”

Kubernetes looks at the StorageClass to decide:

• What kind of disk to use (fast or cheap),

• where to create it (Azure, AWS, etc.), and

• How to manage it (Whether delete it post usage or retain it post the pod is deleted or storage is not in use).

So, think of it as a "blueprint" for storage that tells Kubernetes what type of storage to create and how when a PersistentVolumeClaim (PVC) requests it.

When we create AKS cluster, Azure automatically provisions a few default storage classes as shown below

• default (default) → Uses Azure Managed Disk (Standard or Premium)

• managed, managed-premium → Azure Disk with different tiers

• azurefile, azurefile-premium → Azure File shares for persistent network storage

These are predefined by AKS to save you the effort of creating them manually.
So, you can start provisioning volumes immediately without writing a StorageClass manifest.

Custom Storage Class

We only write a custom StorageClass when we need something different from the defaults.

For example:

• You want a different disk type (StandardSSD_LRS instead of Premium_LRS)

• You need a specific reclaim policy (e.g., Retain instead of Delete)

• You need custom parameters like encryption type, zone, or SKU

• You want to control binding behavior (Immediate vs WaitForFirstConsumer)

• You’re working in multi-cloud or hybrid setups where the default provisioner doesn’t apply

Storage Class vs Persistent Volume vs Persistent Volume Claim

1. StorageClass: The Blueprint

Think of it as a recipe or menu option for how storage should be created.
It defines what kind of storage (SSD/HDD), where (Azure Disk, Azure File), and rules (delete or keep after use).

Example:

"Whenever someone asks for storage, give them a 10 GB Premium SSD disk from Azure."

2. PersistentVolume (PV): The Actual Disk

This is the real storage resource created in your cluster — a piece of Azure Disk or File share.
You can create it manually or Kubernetes can make it automatically using the StorageClass.

Example:

"Here’s a 10 GB Premium SSD disk created in Azure — ready to use!"

3. PersistentVolumeClaim (PVC): The Request

This is what your app (Pod) creates when it needs storage.
It says:

"I need 10 GB of storage from a Premium disk!"

Kubernetes then looks for a matching PV or uses the StorageClass to create one automatically.

PVC  →  asks for storage
        ↓
StorageClass  →  tells Kubernetes what kind of storage to create
        ↓
PV  →  actual storage created (disk or file share)

Understanding Storage Class Attributes

There are five important attributes when it comes to storage class that are necessary to understand while creating a custom storage class.

1. NAME

   This is the name of the StorageClass. We use this name in PersistentVolumeClaim (PVC) to tell Kubernetes which kind of storage you want.

2. PROVISIONER

   It defines which system or plugin is responsible for creating the storage. In our case, it will be Azure(disk.csi.azure.com and file.csi.azure.com).

3. RECLAIMPOLICY

   This tells Kubernetes what to do with the volume after the PVC is deleted (i.e., when your app no longer needs it).

   | Policy | Meaning | | --- | --- | | Delete (Default in AKS) | Deletes the underlying disk or file share automatically. | | Retain | Keeps the disk even after PVC is deleted (you can reuse or inspect it). |

4. VOLUMEBINDINGMODE

   This controls when and where the volume is created and bound. In AKS, we mostly use WaitForFirstConsumer

   | Mode | Meaning | | --- | --- | | Immediate | Volume is created as soon as the PVC is created, regardless of where the Pod runs. | | WaitForFirstConsumer | Volume is created only when a Pod is scheduled — ensures the disk is created in the same zone/node where the Pod will run (avoids mismatch issues). |

5. ALLOWVOLUMEEXPANSION

   This indicates whether you can increase the size of the volume later by simply editing the PVC.

   | Setting | Meaning | | --- | --- | | true (Default in AKS) | You can increase storage size (resize volume). | | false | Size is fixed — cannot be expanded. |

Writing Storage Class Manifest for Custom Storage Class

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain-sc
provisioner: kubernetes.io/azure-disk
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer   # it will wait for a pod(MySQL pod in our case) to be scheduled before binding the PV
allowVolumeExpansion: true
parameters:
  skuname: Premium_LRS
  kind: managed

# There is no spec attribute defined in this StorageClass resource.
# This StorageClass uses Azure Premium SSD managed disks with a Retain reclaim policy.
# The volume binding mode is set to WaitForFirstConsumer to optimize scheduling.
# Volume expansion is enabled to allow resizing of persistent volumes.

Post applying the above Storage Class manifest, you can see the custom Storage Class has been created

Understanding PVC(Persistent Volume Claim)

A Persistent Volume Claim (PVC) is essentially a request for storage made by your application pod. As the name suggests, it acts as a “claim” to Kubernetes for a specific amount and type of storage rather than creating or managing the storage directly.

Once this claim is raised, Kubernetes checks the associated Storage Class to understand how the storage should be provisioned. It then creates a Persistent Volume (PV) that fulfills the claim and binds it to the PVC, allowing the pod to mount and use the storage as needed.

Application Pod → Persistent Volume Claim (PVC) → Persistent Volume (PV) → Storage Class → Cloud Storage (Azure Disk)

Access Modes in PVC

Access Modes define how a pod can access (read and write) data on a Persistent Volume (PV). It is like permissions regarding whether one Pod or multiple Pods can use it, and how. There are three access modes as follows

ReadWriteOnce - RWO

Only one Pod can mount the volume for read & write at a time (on one node).

Appropriate for databases like MySQL, MongoDB, and PostgreSQL.

Azure Disk is suitable for ReadWriteOnce since each disk can be mounted by one node at a time.

ReadOnlyMany - ROX

Volume can be read by many Pods, but no one can write.

Appropriate for Shared configs, static data, and logs.

ReadWriteMany - RWX

Volume can be read and written by many Pods at once (even across nodes).

Appropriate for shared file storage, web apps needing shared uploads.

Azure File is suitable for ReadWriteMany since a File share can be mounted by multiple Pods/nodes. So, if you need multiple Pods to access the same data, use Azure File, not Azure Disk.

Summary

Writing PVC(Persistent Volume Claim) Manifest

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disks-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: managed-premium-retain-sc
  resources:
    requests:
      storage: 5Gi # Requesting 5 GiB of storage
# This PersistentVolumeClaim requests a 5 GiB volume using the 'managed-premium-retain-sc' StorageClass.

After applying the above PVC, the PVC has been created as shown below; however, it is in the pending state because in the storage class manifest, volumeBindingMode is set to waitForFirstConsumer . In this mode, the actual volume provisioning is delayed until a pod that uses this PVC is scheduled, ensuring that the storage is created in the same zone as the consuming pod.

If the volumeBindingMode had it been set to Immediate, the requested 5 GB of storage would have been provisioned right away, regardless of whether any pod was scheduled or not.

Understanding ConfigMap and its Usecase

ConfgMap is a Kubernetes object that lets you store non-secret configuration data like environment variables, config files, or scripts separately from your application code. In short, it allows you to externalize your non-secretive data so your containers remain clean and reusable.

In the context of deploying a stateful application, i.e., MySQL, in our project, we are going to use a ConfigMap to store the .sql script inside a ConfigMap that will be used for creating a basic schema when MySQL is deployed in a pod.

Writing ConfigMap Manifest

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: usermanagement-dbcreation-script
data:
  mysql_usermgmt_db_init_script.sql: |
    DROP DATABASE IF EXISTS webappdb;
    CREATE DATABASE webappdb;

This ConfigMap stores a SQL initialization script that will be used by your MySQL Pod to create the database webappdb.

It first drops any existing database with that name (to start clean) and then creates it again.

Usage of ConfigMap

ConfigMaps can be used in two main ways

1. As an Environment Variable

   Inject the data directly into the container environment.

    envFrom:
      - configMapRef:
          name: usermanagement-dbcreation-script
   

As Mounted Volume

Mount the ConfigMap as a file or directory inside the container.

volumeMounts:
  - name: config-volume
    mountPath: /docker-entrypoint-initdb.d
volumes:
  - name: config-volume
    configMap:
      name: usermanagement-dbcreation-script

Overall Execution Flow

1. You created a PVC → requests storage for MySQL data.

2. You create a ConfigMap → holds your SQL schema file.

3. You’ll create a MySQL Deployment →

   • mounts the PVC for persistent data

   • mounts the ConfigMap for initial schema setup

When the Pod starts, MySQL runs the .sql file and creates your database automatically

Understanding MySQL Deployment

Deployment is a top-level Kubernetes controller that manages Pods and instructs Kubernetes on what to run, the number of replicas, and how to maintain their health.

A Deployment ensures your app (Pod) is always running the desired number of instances, with the correct configuration.

Deployment in the context of MySQL(a Stateful application)

For a MySQL database, the Deployment does these things:

1. Runs a MySQL container

2. Mounts storage (PVC) to persist data

3. Mounts ConfigMap (your .sql file) to initialize schema

4. Defines environment variables like MYSQL_ROOT_PASSWORD, MYSQL_DATABASE

5. Ensures MySQL restarts automatically if the Pod crashes

Writing Deployment Manifest for MySQL

When this Deployment runs, Kubernetes will:

1. Create a Pod with MySQL 5.6

2. Mount your Azure-managed disk (PVC)

3. Run the .sql script from the ConfigMap to create webappdb

4. Keep the Pod alive and recreate it if it crashes, while preserving data

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  strategy:       # strategy for deployment, can be RollingUpdate or Recreate. Since it is a database, we use Recreate to avoid conflicts.
    type: Recreate
  template:     # pod template
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql-container
          image: mysql:5.6
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: dbpass123!
          ports:
            - containerPort: 3306
              name: mysql
          volumeMounts:       # Mounting volumes to the container
            - name: mysql-persistent-storage
              mountPath: /var/lib/mysql
              subPath: mysql-data
            - name: usermanagement-dbcreation-script
              mountPath: /docker-entrypoint-initdb.d  # Mounting the ConfigMap to initialize the database. MySQL will execute any .sql files in this directory on startup.

      volumes:
        - name: mysql-persistent-storage      # Mounting the PersistentVolumeClaim as a volume
          persistentVolumeClaim:
            claimName: azure-managed-disks-pvc

        - name: usermanagement-dbcreation-script        # Mounting the ConfigMap as a volume
          configMap:
            name: usermanagement-dbcreation-script

The diagram below depicts a holistic view of how everything is put together in the Deployment:

Understanding the Role of ClusterIP & Headless Service

A Service in Kubernetes is a resource that is responsible for exposing pods to the network, both internally and externally.

Exposing a pod’s network internally means allowing the pod to communicate inside the Cluster with other resources, whereas exposing externally means allowing the pod to be accessible to the public internet.

Since pods are ephemeral (can restart, move, or change IP) service provides a stable endpoint(DNS name or IP) for accessing them.

Think of it as a constant address that points to your Pod, even if the Pod itself keeps changing. !

A ClusterIP is the default Service type in Kubernetes. It exposes your application inside the cluster using a stable internal IP address. Whenever Pods are recreated (and their IPs change), the ClusterIP remains the same, allowing other Pods or services to connect to it reliably.

If your web application runs multiple Pods, a ClusterIP service ensures load-balanced internal access; any backend Pod can talk to it consistently, even if Pods restart or change IPs.

Headless Service & Its Importance for Stateful Application(MySQL)

A Headless Service is a special type of Service that does not have its own Cluster IP. Which means Kubernetes does not assign a virtual IP to the service; instead, DNS resolves directly to the Pod’s IP. So the application (like your web app) connects directly to the Pod, not through a proxy or virtual IP.

Headless service is required for MySQL because:

• We have only one MySQL Pod.

• We want your web application to connect directly to that Pod’s IP.

• It ensures lower latency and avoids load-balancing overhead (unnecessary for a single database instance).

• Even if you had multiple database replicas (like in a StatefulSet), a headless service would also help clients resolve to individual Pod IPs (e.g., mysql-0, mysql-1).

Writing Service Manifest for MySQL

---
apiVersion: v1
kind: Service
metadata:
  name: mysql-svc
spec:
  selector:
    app: mysql
  ports:
    - port: 3306
  clusterIP: None     #Pod IP will be used instead of assigning a clusterIP(this is called headless service)

This manifest creates a Headless Service named mysql-svc for your MySQL Pod.
Instead of assigning a virtual ClusterIP, it allows other Pods (like your web application) to connect directly to the Pod’s IP.

Summary

Output

This confirms that the StorageClass → PVC → PV → Pod chain is working flawlessly.

Database Setup Conclusion

With all the manifests applied, our MySQL database is now fully deployed and functional inside AKS. The StorageClass dynamically provisioned an Azure-managed disk, which our PersistentVolumeClaim (PVC) successfully bound to ensure data persistence. The ConfigMap initialized the database automatically with our predefined schema, while the Deployment maintained the MySQL Pod lifecycle with persistent storage attached. We then exposed the Pod using a Headless Service, allowing other Pods (like our web application) to connect directly using the Pod IP instead of a ClusterIP. Finally, by accessing the MySQL Pod through a client, we confirmed that the webappdb schema was created successfully, validating that our entire configuration chain, from storage provisioning to application-level database initialization, works seamlessly within the AKS environment.

Deploying WebApp

Deploy a User Management Web App that connects to your existing MySQL database (webappdb).
This app will act as the frontend interface and provide APIs for:

• Creating users

• Listing users

• Deleting users

Key Kubernetes Concepts

Understanding the Deployment Manifest for WebApp

This Deployment creates and manages the User Management Web Application, which serves as the frontend for interacting with the MySQL database hosted within the AKS cluster. It exposes APIs to perform operations such as creating, listing, and deleting users from the webappdb schema in MySQL.

WebApp (LoadBalancer Service) → WebApp Pod → MySQL (Headless Service) → Azure Disk (Persistent Storage)

At a high level, this Deployment performs three main functions: database readiness check, application startup, and environment configuration.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: usermgmt-webpp-deployment
  labels:
    app: usermgmt-webapp

spec:
  replicas: 1
  selector:
    matchLabels:
      app: usermgmt-webapp
  template:
    metadata:
      labels:
        app: usermgmt-webapp
    spec:
      initContainers:       # this init container ensures that database is up and running before this webapp pod is deployed
        - name: init-db
          image: busybox:1.31
          command: ['sh', '-c', 'echo -e "Checking for the availability of MySQL Server deployment"; while ! nc -z mysql 3306; do sleep 1; printf "-"; done; echo -e "  >> MySQL DB Server has started";']

      containers:
        - name: usermgmt-webapp-container
          image: stacksimplify/kube-usermgmt-webapp:1.0.0-MySQLDB
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
          env:
            - name: DB_HOSTNAME
              value: "mysql"      # Hostname should be same as the name specified in MySQL cluster IP service metadata.name

            - name: DB_PORT
              value: "3306"

            - name: DB_NAME
              value: "webappdb"

            - name: DB_USERNAME
              value: "root"

            - name: DB_PASSWORD
              value: dbpass123!

Understanding Init Container

Before the main web application container starts, an Init Container named init-db runs a simple shell command that continuously checks if the MySQL service is reachable on port 3306.
It uses a lightweight BusyBox image with the nc (netcat) utility to poll the MySQL service.

This ensures that:

• The web app Pod will only start after the MySQL Pod is fully up and accepting connections.

• Application startup failures due to database unavailability are prevented.

Below is the extracted init container part from the main manifest written above:

      initContainers:       # this init container ensures that database is up and running before this webapp pod is deployed
        - name: init-db
          image: busybox:1.31
          command: ['sh', '-c', 'echo -e "Checking for the availability of MySQL Server deployment"; while ! nc -z mysql 3306; do sleep 1; printf "-"; done; echo -e "  >> MySQL DB Server has started";']

Understanding Environment Variables

The environment variables section passes database connection details directly into the container:

Loadbalancer Service for WebApp

This Kubernetes Service exposes the User Management Web Application externally so users can access it through a public IP assigned by Azure. Since the application serves as a frontend/API layer, it needs to be reachable from outside of the cluster, and for that, AKS provides the LoadBalancer Service type.

At a high level, this Service performs two core functions:
(1) Exposes the web application to the internet, and
(2) Routes traffic to the correct Pod inside the cluster.

Writing the LoadBalancer Service Manifest

---
apiVersion: v1
kind: Service
metadata:
  name: usermgmt-LB-service
  labels:
    app: usermgmt-webapp

spec:
  type: LoadBalancer
  selector:     # to which pod it needs to send the trafic
    app: usermgmt-webapp
  ports:
    - port: 80
      targetPort: 8080

Output

Once all manifests were applied, both the MySQL Pod and the User Management WebApp Pod were successfully created and transitioned into the Running state. The LoadBalancer Service also provisioned an external public IP, allowing us to access the application directly from the browser.

Below is the command-line output showing:

• The MySQL Pod is up and running

• The WebApp Pod is in Running/Ready state

• The LoadBalancer Service with an external IP assigned

This confirms that all Kubernetes components have been deployed correctly and the application is fully functional.

Following that is the screenshot of the User Management Web Application, accessible using the LoadBalancer’s external IP. The UI loading successfully in the browser validates that the frontend is reachable and actively communicating with the backend MySQL database.

Conclusion & Architecture

In this section, we successfully deployed a complete User Management Web Application on Azure Kubernetes Service (AKS) backed by a fully functional MySQL database. Through a combination of Kubernetes core concepts, including StorageClass, PersistentVolumeClaim, ConfigMap, Deployment, and Services, we built a production-ready setup capable of running a stateful backend and a stateless frontend together.

The MySQL Pod is provisioned with durable Azure Disk storage, initialized automatically using a ConfigMap-based schema, and exposed internally through a Headless Service for direct Pod-to-Pod communication. The WebApp Pod uses an init container to ensure the database is available before startup, and is exposed externally using an Azure LoadBalancer, enabling seamless user access from outside the cluster.

The command-line outputs confirm the successful creation of all Pods and Services, while the working web interface accessed through the LoadBalancer’s external IP validates both the deployment and the backend integration.

                         ┌────────────────────────┐
                         │   Azure Load Balancer  │
                         │  (Public External IP)  │
                         └─────────────┬──────────┘
                                       │
                                       │
                           Exposes WebApp on Port 80
                                       │
                                       ▼
                          ┌──────────────────────────┐
                          │     WebApp Deployment     │
                          │   (UserMgmt WebApp Pod)   │
                          │  Container Port : 8080    │
                          └───────┬─────────┬────────┘
                                  │         │
                                  │         │
                                  │     Reads DB Config
                                  │         │
                                  ▼         ▼
                       ┌──────────────────────────┐
                       │        ConfigMap          │
                       │  (DB env variables etc.)  │
                       └───────────────────────────┘
                                  │
                                  │ Headless Service (clusterIP=None)
                                  ▼
                         ┌────────────────────────┐
                         │      MySQL Pod         │
                         │  Port : 3306           │
                         │  Schema : webappdb     │
                         └───────────┬────────────┘
                                     │
                                     │ PVC Bind
                                     ▼
                         ┌────────────────────────┐
                         │ Persistent Volume (PV) │
                         │ Azure Managed Disk     │
                         └────────────────────────┘

Computer Vision is a branch of Artificial Intelligence that allows machines to see, analyze, and understand images and videos. Azure AI Vision provides pre-built models through simple APIs, enabling developers to integrate features like object detection, OCR, tagging, and caption generation into their applications.

In this blog, we’ll walk through how to implement Azure AI Vision using Python, showcasing its major features with practical code examples.

Azure AI Vision & Use Cases

Instead of spending time training deep learning models from scratch, Azure AI Vision provides ready-to-use models that can:

• Detect objects in images

• Extract text using OCR

• Automatically generate tags

• Create human-like captions describing images

This makes it extremely useful for building real-world AI solutions quickly and at scale.

How It Helps LLMs

When combined with Large Language Models (LLMs), these visual capabilities make AI systems multimodal:

• LLMs can reason not just on text, but also on what’s inside an image.

• Example: Azure Vision extracts text from an invoice (OCR) → LLM interprets and summarizes it → business system updates automatically.

Real-World Use Case

Imagine a retail company managing thousands of product images:

• Azure Vision tags and captions products for search and cataloging.

• OCR extracts text from product labels.

• LLMs use this extracted data to auto-generate product descriptions for e-commerce.

This saves time, improves accuracy, and makes systems more intelligent.

Python Implementation

1- Analyzing an Image with Azure AI Vision in Python (Image Tagging)

from azure.ai.vision.imageanalysis import ImageAnalysisClient
from azure.ai.vision.imageanalysis.models import VisualFeatures
from azure.core.credentials import AzureKeyCredential
import os
import json
from dotenv import load_dotenv

load_dotenv("env.env")

endpoint="https://az-computer-vision1.cognitiveservices.azure.com/"
key=os.getenv("AI_VISION_KEY")

client = ImageAnalysisClient(endpoint=endpoint, credential=AzureKeyCredential(key))
with open("ai_vision_test.jpg", "rb") as image:
    image_details=image.read()

response=client.analyze(
    image_data=image_details,
    visual_features=[VisualFeatures.TAGS, VisualFeatures.CAPTION]

)

print(json.dumps(response.as_dict(), indent=4))

Code Walkthrough

1. Importing Required Libraries

   • azure.ai.vision.imageanalysis provides the ImageAnalysisClient to interact with the Azure AI Vision service.

   • VisualFeatures defines which features (Tags, Captions, OCR, etc.) we want to extract.

   • AzureKeyCredential securely passes our API key to the client.

   • dotenv is used to safely load credentials stored in an .env file.

2. Setting Up Authentication

   • The endpoint is the URL of your Azure AI Vision resource.

   • The key is stored in an environment file (env.env) for security, instead of hardcoding it into the script.

3. Creating the Client

   • The ImageAnalysisClient connects to Azure’s AI Vision service using the endpoint and API key.

4. Reading the Image

   • The image (ai_vision_test.jpg) is read in binary format because the API expects raw bytes of the image.

5. Analyzing the Image

   • We call the analyze() method and pass two visual features:

     • VisualFeatures.TAGS → Returns a list of keywords that describe the image.

     • VisualFeatures.CAPTION → Generates a human-readable caption summarizing the image.

6. Printing Results

   • The response is converted into a dictionary and printed in a nicely formatted JSON output using json.dumps().

   • This makes it easy to see what Azure Vision has detected in the image.

2- Object Detection with Azure AI Vision in Python

Another powerful feature of Azure AI Vision is object detection. It not only identifies what objects are present in an image but also returns their locations using bounding boxes. This is especially useful in applications like surveillance, manufacturing defect detection, and retail product recognition.

from azure.ai.vision.imageanalysis import ImageAnalysisClient
from azure.ai.vision.imageanalysis.models import VisualFeatures
from azure.core.credentials import AzureKeyCredential
import os
import json
from dotenv import load_dotenv

load_dotenv("env.env")

endpoint="https://az-computer-vision1.cognitiveservices.azure.com/"
key=os.getenv("AI_VISION_KEY")

client = ImageAnalysisClient(endpoint=endpoint, credential=AzureKeyCredential(key))
with open("fruit_bucket.png", "rb") as image:
    image_details=image.read()

response=client.analyze(
    image_data=image_details,
    visual_features=[VisualFeatures.OBJECTS]    # detects objects in the image with bounding boxes

)

print(json.dumps(response.as_dict(), indent=4))

Code Walkthrough

1. Importing Libraries
   We bring in the same core classes (ImageAnalysisClient, VisualFeatures, and AzureKeyCredential) used earlier for tagging and captions.

2. Authentication

   • The endpoint points to your Azure AI Vision resource.

   • The key is securely loaded from an .env file.

3. Image Input

   • We load the image fruit_bucket.png in binary format so it can be sent to the API.

4. Object Detection Request

   • VisualFeatures.OBJECTS tells Azure Vision to detect all visible objects in the image.

   • The API responds with a list of objects, their confidence scores, and bounding box coordinates.

5. Readable Output

   • The response.as_dict() method returns the structured result as a dictionary.

   • json.dumps() formats it neatly so we can see exactly what was detected.

3- Extracting Text from Images with Azure AI Vision (OCR)

Azure AI Vision provides powerful OCR (Optical Character Recognition) capabilities. With this feature, we can detect both printed and handwritten text from images and documents. This is especially useful in scenarios like digitizing scanned documents, extracting text from receipts, or reading quotes from images.

from azure.ai.vision.imageanalysis import ImageAnalysisClient
from azure.ai.vision.imageanalysis.models import VisualFeatures
from azure.core.credentials import AzureKeyCredential
import os
import json
from dotenv import load_dotenv

load_dotenv("env.env")

endpoint="https://az-computer-vision1.cognitiveservices.azure.com/"
key=os.getenv("AI_VISION_KEY")

client = ImageAnalysisClient(endpoint=endpoint, credential=AzureKeyCredential(key))
with open("quote.jpg", "rb") as image:
    image_details=image.read()

response=client.analyze(
    image_data=image_details,
    visual_features=[VisualFeatures.READ]    # detects text in the image using Optical Character Recognition (OCR)

)

for line in response.read.blocks[0].lines:
    print(line. Text)

Code Walkthrough

1. Authentication

   • The endpoint and key are loaded from the .env file to keep secrets secure.

   • ImageAnalysisClient is initialized to interact with Azure AI Vision.

2. Reading the Image

   • The file quote.jpg is loaded in binary mode before sending it to the API.

3. Performing OCR

   • The VisualFeatures.READ option tells Azure Vision to run OCR.

   • The response contains detected text blocks, lines, and even word-level details if needed.

4. Extracting Results

   • We loop through response.read.blocks[0].lines and print each line of detected text.

Retrieval-Augmented Generation (RAG) pairs a Large Language Model (LLM) with external knowledge sources—such as databases, blob/object stores, file shares, and document repositories—to ground its responses in real data. Rather than relying solely on its pretraining, the LLM first retrieves relevant context from these connected sources and then generates an answer that blends that up-to-date evidence with its language capabilities. This approach improves factual accuracy, reduces hallucinations, and lets applications incorporate private or domain-specific knowledge without retraining the model.

Sources for Retrieval Augmented Generation in Azure

In Azure, you can connect multiple enterprise data sources to power RAG with current, organization-specific knowledge. Common sources include:

• Azure Blob Storage: documents, PDFs, text files, and other unstructured content

• SharePoint: internal company docs, policies, and knowledge-base articles

• File shares: content from network drives and on-prem servers • Databases: SQL databases, Azure Cosmos DB, and more

• Web and APIs: company intranet, public sites, and custom REST endpoints

• OneDrive: Office documents such as Word, Excel, and PowerPoint

These sources can be ingested and indexed in Azure AI Search, which then serves as the retrieval layer for Retrieval-Augmented Generation—grounding your LLM with authoritative, up-to-date enterprise data.

Internal flow of RAG with Azure

1. User query: Example: “What is our company’s travel reimbursement policy?”

2. Route to search: The LLM forwards the query to Azure AI Search (formerly Cognitive Search) rather than guessing from pretraining alone.

3. Retrieve from enterprise index: Azure AI Search scans its index built from enterprise sources (Blob Storage, SharePoint, file shares, databases, websites/APIs, OneDrive).

4. Vector and semantic retrieval: It fetches the most relevant chunks using vector search and semantic ranking (beyond simple keyword matching).

5. Ground the model: The retrieved passages are passed back to the LLM as context (grounding data).

6. Generate the answer: The LLM composes a final, natural-language response that cites and synthesizes the retrieved context with its reasoning.

Result: Answers are accurate, current, and aligned with company policy—while minimizing hallucinations and avoiding retraining.

RAG implementation in Python with Azure services

What you’ll build

A Retrieval-Augmented Generation (RAG) app where an LLM (GPT‑4) answers questions grounded in your enterprise content indexed by Azure AI Search and stored in Azure Blob Storage.

Resources required on Azure

1. LLM: GPT‑4 deployment in Azure AI Foundry (Azure OpenAI)

2. Retrieval: Azure AI Search with vector search enabled

3. Content store: Azure Blob Storage (one container with your documents: PDFs, DOCX, TXT, etc.)

4. App runtime: Python (requests/openai/azure-openai SDKs) and a .env file for secrets

High-level architecture

1. Documents live in Azure Blob Storage.

2. Azure AI Search ingests and indexes them (including embeddings for vector search).

3. Your Python app sends a user query to GPT‑4 and passes RAG config that points to the AI Search index.

4. Azure AI Search returns the most relevant chunks (vector + semantic retrieval).

5. GPT‑4 generates an answer grounded in those chunks.

Setup checklist

• Create a Blob Storage account and container; upload sample docs.

• Provision Azure AI Search; enable vector search; create index (schema with content, metadata, vector fields).

• Connect the blob container to AI Search (data source + indexer) so content is ingested and chunked.

• In Azure AI Foundry, deploy a GPT‑4 model and note the endpoint, API version, and key.

• Capture keys/URLs in env.env: AZURE_OPENAI_API_KEY, AZURE_SEARCH_API_KEY, Azure OpenAI endpoint, Azure AI Search endpoint, Index name

• In Python, load env.env, initialize the Azure OpenAI client, and attach the AI Search data source via extra_body (as shown in the snippet).

Code Snippet

import os
import json
from openai import AzureOpenAI
from dotenv import load_dotenv # Load environment variables from .env file

load_dotenv("env.env")  # Load environment variables from the specified .env file

subscription_key = os.getenv("AZURE_OPENAI_API_KEY")
client = AzureOpenAI(
    api_version="2024-12-01-preview",
    azure_endpoint="https://ai-foundary-demo.cognitiveservices.azure.com/",
    api_key=subscription_key,
)

rag_parameters = {
    "data_sources": [
        {
            "type": "azure_search",
            "parameters": {
                "endpoint": "https://aisearch20251999.search.windows.net",
                "index_name": "index",
                "authentication": {
                    "type": "api_key",
                    "key": os.getenv("AZURE_SEARCH_API_KEY"),
                }

            }
        }
    ],

}

response = client.chat.completions.create(
    messages=[
        {
            "role": "system",
            "content": "You are a helpful assistant that helps student learn Python Basics."
        },
        {"role": "user",
         "content": "What is Python?"

         }
    ],
    temperature=0.7,
    top_p=0.9,
    model="gpt-4.1",
    extra_body=rag_parameters
)

model_dump_response=response.model_dump()

print(response.choices[0].message.content)  # Print the response in a readable format

1. How to initialize Git locally?

   Ans: We can initialize git using the git init command**.** Once git is initialized, a .git directory will be created which is responsible for handling all git operations.

2. What is a Pre-Commit Hook?

   Ans: A pre-commit hook is a script that executes before a commit is made. These hooks are part of git’s native hook framework and are located in the .git/hooks directory.

   Pre-commit hooks are extremely helpful in preventing sensitive information like passwords, secrets, access tokens, etc, from being committed to git. When a user runs git commit, the pre-commit is triggered before the commit is finalized, and if the hook fails, then the commit is aborted.

3. Which command is used to compare the changes in your working directory with the last committed version in the repository?

   Ans: git diff command is used to compare changes in your working directory with the last committed version in the repository. It also allows you to see the difference between two commits.

   E.g.: git diff <commit_id1> <commit_id2>

4. What is git fork?

   Ans: git fork is used to create a copy of the repository to your account, where you can modify it and create your own version of the repository.

5. Can you explain the usage of git cherry-pick?

   Ans: git cherry-pick is the command that is used to pick a particular commit and merge it into the main. It is useful when you want to pick up a specific commit only. You have to be on the main branch before cherry-picking.

   E.g.: git cherry-pick <commitid>

6. What is the difference between git merge and git rebase?

   Ans: Both git merge and git rebase serve the same purpose, that is, merging your code from a feature branch to the main branch, but in 2 different ways as follows:

   When you use git rebase, you get a linear commit history, but when you use git merge, it creates a commit at the top, disturbing the sequence.

7. What is the difference between git pull and git fetch?

   Ans: git fetch command only informs you about the changes that are there on the remote but not available on your local working copy, but it does not bring the changes to your local code base, whereas git pull directly updates your local code base with the new changes from the remote repository.

   git pull == git fetch + git merge

8. What are pre-commit hooks and post-commit hooks?

   Ans: A hook is something that you want to run before and after the occurrence of an action. So, pre-commit hooks are actions taken before you do the commit:

   Example*:* when you have a public key, private key, or password that you do not wish to be pushed to git then you can configure a pre-commit hook to execute a script that checks a certain pattern that will scan the code before every commit you make.

   Similarly, post-commit hooks are nothing but actions configured to be run post a commit is made:

   Example*:* running static analysis tools, linters, or code formatters to ensure committed code adheres to defined quality standards.

9. What is git stash, and what are its use cases?

   Ans: git stash is the command that is used to temporarily save the changes made to your working copy.

   Use-Case:

   • Temporarily saving the work: When you need to switch branches to work on something urgent but don’t want to commit the incomplete changes, then you can do git stash —> git checkout another_branch —> work on the other branch —> git checkout original_branch —> git stash pop.

   • Pulling Updates without losing the work: if you need to pull the latest changes from the remote repository, but you have some uncommitted changes, then you can do git stash —> git pull —> git stash pop.

   • Resolving merge conflicts: if merge or rebase fails due to uncommitted changes, then you can do git stash —> git merge target_branch —> resolve the conflicts—> git stash pop

10. How to amend a commit in git?

    Ans: When you have made a commit with some mistake and pushed it to the remote repository, and now you want to rectify that particular commit, then you can use git commit --amend, It allows you to modify the most recent commit

11. How do you revert a commit that has already been pushed and made public?

    Ans: You can undo the changes by making another commit using the command git revert <commit_id>

12. What is the difference between git stash apply and git stash pop?

    Ans: The key difference between git stash pop and git stash apply lies in how they handle the stash after applying the changes in your working directory:

    • git stash pop Applies the stash and removes it from the stash stack permanently. After running git stash pop, the stashed changes are restored to your working directory and stash id is deleted from the stash stack. It should be used when you are sure that you do not need that stash after applying it because once your working copy is restored, the stash will be removed.

    • git stash apply Applies the stash but keeps it in the stash stack. After running the git stash apply, the stashed changes are restored to your working directory but the stash remains in the stack for future use. It is useful when you want to keep the stash for future use.

13. How to find a list of files that are changed during a commit?

    Ans: git diff-tree -r <commit_id>

14. How to check whether a branch has already been merged to the master or not?

    Ans: git branch –merged gives the list of merged branches, and git branch –not-merged gives the list of unmerged branches.

15. How to remove a file from your git without removing it from your local filesystem?

    Ans: using git reset <filename> which is exactly opposite to the git add command.

16. What is the difference between git revert and git reset?

    Ans: git reset is used to return the entire working tree to the last committed state; it also resets the file from the staging area, whereas the git revert command adds a new history to the project and it does not modify the existing history.

17. What is git bisect, and how do you use it to determine the source of a bug?

    Ans: git bisect is used to find a commit that introduced a bug by using a binary search algorithm. You can use it by giving it a bad commit ID, which you think could be a potential reason for the bug being introduced, and a good commit up to which everything was working fine. Then this command picks the commits between these 2 endpoints and asks you whether the selected commit is good or bad. It keeps narrowing down the commits until it finds the buggy commit.

18. What is git reflog?

    Ans: It keeps track of every change made in a repository's reference. It shows deleted, renamed, and all other actions when executed.

Docker Questions

1. What is Docker?

   Ans: Docker is an open-source containerization platform. It enables developers to package applications into containers. We have used Docker to build Docker images out of Docker files for lightweight application packaging.

2. How are containers different from Virtual Machines?

   Ans: Containers are very lightweight as they do not have a complete OS and its utilities. Containers have very minimal OS functionality and only require dependencies.

   Docker provides process-level isolation, whereas Virtual Machines provide stronger isolation.

3. What is Docker Lifecycle?

   Ans: The general flow of the Docker lifecycle is as follows:

   • Step 1: Create a Dockerfile with a set of instructions

   • Step 2: Building the Docker image from the Docker file

   • Step 3: Push the image to image registry like Docker Hub, ACR, and ECR

   • Step 4: Create the container out of the Docker image.

A Docker image acts as a set of instructions to build a container, and it can be compared to a Snapshot in a VM.

4. What are the different Docker components?

   Ans: Docker consists of several key components, such as:

   • Docker Engine which includes the Docker daemon for managing resources and the Docker CLI for user interaction.

   • Docker Images serve as a blueprint for containers.

   • Docker Containers are lightweight and portable instances for images.

   • Docker Registry for storing images and sharing them.

   • Docker Volume enables data persistence.

   • Docker Network provides connectivity and isolation for containers.

   • Docker Compose simplifies the management of multiple containers.

5. What is the difference between Docker COPY and ADD?

   Ans: docker ADD can copy files from a URL unlike Docker COPY can only copy files from host system into the container.

6. What is the difference between CMD and Entrypoint in Docker?

Ans:

We mostly use ENTRYPOINT and CMD together for better flexibility.

7. What is the default networking in Docker, and explain networking types?

   Ans: Docker supports several networking types; however bridge network is the default networking in Docker. The following is a list of networking types that Docker supports:

   • Bridge Network (Default):

     A private network where containers can communicate with each other through their IP addresses. It is ideal for standalone containers needing limited communication with the host or external network. Here, containers get a private IP address, and you can use -p or —publish to expose their services.

     docker network ls Can show you the available networks

   • Host Network:

     A host network removes the network’s isolation between the container and the host. The container directly uses the host’s network stack. It is ideal for performance-sensitive applications where networking overhead needs to be minimized. No additional port mapping required, anyone having access to the host IP can access the application with hostip:port .

     docker run —network host my-container The command can be used to run a container with the host network.

   • Overlay Network:

     It allows communication between containers across multiple Docker hosts in a swarm or K8S cluster. It is ideal for distributed systems or multi-host environments.

     docker network create -d overlay my-overlay-network Command is used to create an overlay network.

   • MacVLAN Network:

     It assigns containers their own MAC address and allows them to appear as physical devices on the network. It is ideal for a legacy application requiring direct access to the physical network.

     docker network create -d macvlan —subnet=192.168.10/24 my-macvlan-network This command can be used to create a MacVLAN network.

   • Custom-Bridge Network:

     Similar to the default bridge network, but allows user-defined configuration for better control. Containers on the same custom bridge network can resolve each other by container names.

     docker network create my-bridgenetwork This command can be used to create a custom network.

   • None-Network:

     It disables networking for the container completely and is useful for security purposes or a container that doesn't require networking

     docker run —network none mycontainer

8. Can you explain how to isolate networking between containers?

   Ans: By default, all the containers get deployed on the bridge network, which is Docker eth0. To isolate and secure a container, you can create a customer bridge network and assign it to the targeted container.

9. What is a multistage build in Docker?

   Ans: Multistage build in Docker allows you to build your Docker container in multiple stages, allowing you to copy only necessary artifacts from one stage to another. The major advantage is that it helps build lightweight containers.

   A multistage build contains multiple FORM instructions in a single Docker file, for example: you can compile the application in one of the stages (development stage) and copy only the compiled binary to a lightweight runtime image in the final stage. This reduces image size, improves security, and simplifies the build process.

10. What are distro-less images in Docker?

    Ans: Distro-less images are minimalist Docker images that include only the application and it required runtime by excluding the OS package managers, shell, and other unnecessary utilities.

    They offer smaller image sizes, enhance security by reducing attack surface, and ensure consistency in the production environment.

    NOTE: Since distro-less images lack system native tools and utilities, the debugging should be done at the application or build pipeline level.

    #Stage1: build the java application
    FROM maven:3.8.7-openjdk-17 as Builder
    WORKDIR /app
    COPY pom.xml
    COPY src ./src
    RUN mvn package
    #Stage2: Use distro-less for runtime
    FROM gcr.io/distroless/java:17
    WORKDIR /app
    COPY --form=builder /app/target/myapp.jar
    CMD ["myapp.jar"]
    

11. What are some real-time challenges with Docker?

    Ans: Some challenges and disadvantages of Docker are stated as follows:

    • Docker is a single daemon process, which can cause a single point of failure. In case the Docker daemon goes down, then all the applications will face downtime.

    • Docker daemon runs as the root user, which is a security threat. Any process running with root privileges can have an adverse effect when it is compromised, as it can affect other applications and containers on the host.

    • If you are running too many containers on a single host, then you may experience issues with resource constraints. This can result in slow performance or crashes.

12. What step would you take to secure containers?

    Ans: We can take the following safety measures to secure containers:

    • Use distro-less images so there are fewer chances of CVE or security issues

    • Ensure that the networking is configured properly. This is one of the common reasons for security issues. If required, configure a custom bridge network and assign it to isolate containers.

    • Use utilities like Docker Scout to scan your container images.

13. You have noticed many stopped containers and unused networks taking up space. Describe how you would clean up these resources effectively.

    Ans: The docker prune command can be used to remove unused resources.

    • docker image prune: to remove unused images

    • docker container prune: to remove containers

    • docker volume prune: to remove volumes

    • docker network prune: to remove networks

Running docker system prune combines all the above commands and cleans up all resources that are not associated with any running containers.

14. You are working on a project that requires Docker containers to persistently store data. How would you handle persistent storage in Docker?

    Ans: Storing data persistently means saving, accessing and reusing the data post the containers are destroyed. This can be achieved in the following 2 ways

    Docker Volume:

    Docker volume can be used for persistent storage. They are managed by Docker and can be attached to one or more containers. Docker volumes are more reliable and efficient for persisting data across the container lifecycle. These are easy to back up and can be maintained independently, even if a container is stopped or removed.

    Example: in a production environment, you might create a named volume to persist database data like this

    —> Create Docker Volume: docker volume create db_data

    —> Attach the volume to the container whose data needs to be persisted: docker run -d —name MySQL -v db_data: /var/lib/mysql mysql:latest

    This ensures the database data remains intact even if the container is stopped.

    Bind Mounts:

    In some cases, we can use bind mounts where a directory of the host machine is mapped directly to a directory in the container. It is useful in a development environment where you need immediate synchronization between host changes and containers.

15. A company wants to run thousands of containers. Is there any limit on how many containers you can run in Docker?

    Ans: There is no limit when it comes to running containers. The only limit is the hardware or machine limit. If the machine does not have enough CPU, it will not be able to launch the containers.

16. You are managing a Docker environment and need to ensure that each container operates within defined CPU and memory limits. How do you limit the CPU and memory of a Docker container?

    Ans: Docker allows you to limit the CPU and memory usage for a container using resource constraints. You can set the CPU limit using the --CPU and --memory options when running the container using the docker run command.

    Example: docker run --cpu 2 --memory 1g mycontainer

17. Can you define the resource limit in the Docker file? Or are there any other ways you can limit resource usage?

    Ans: Resource constraints, such as limiting memory and CPU, cannot be defined directly in a Docker file. A Docker file is meant for defining build instructions of the image, not runtime behaviors. Instead, the constraints can be applied in the configuration file of orchestrators like Docker Compose and Kubernetes.

    docker run --cpu=”15” --memory=”512m” my image

    Alternatively, using a K8S pod definition, can set a limit like below:

    resources:
        limit:
            memory: "512m"
            cpu: "1500m"
    

18. What is the difference between a Docker container and a Kubernetes pod?

    Ans: A docker container is a lightweight and single instance of an application. It is managed by docker and provides process level isolation.

    On the other hand, a Kubernetes pod is a high-level abstraction that can contain one or more Docker containers(or other container runtimes).

19. How would you debug issues in a Docker container?

    Ans: There are several techniques to debug issues in a Docker container:

    • Logging: Docker captures the standard output and error logs of a container making it easy to inspect using the docker logs command. So initially, we’ll check the logs of the container.

    • Shell Access: We can access a running container’s shell using the docker exec command, which allows you to investigate and troubleshoot issues interactively.

    • Image Inspection: You can inspect the Docker image content and configuration using docker image inspect to check if there is any misconfiguration.

    • Health Check: Docker supports defining health checks for containers, allowing you to monitor health status and automatically restart or take actions using pre-defined conditions.

    • Tools: Additionally, if containers are configured with ELK or Prometheus, then we can make use of these tools to troubleshoot better.

20. Can you describe a situation where you optimized a Dockerfile for faster build times or smaller image size?

    Ans: Optimizing Dockerfile could involve various stages like using smaller base images (Alpine images or distro-less images), reducing the number of layers by combining commands, or using multistage builds to exclude unnecessary files from the final image.

21. How do you create a multi-stage build in Docker?

    Ans: Multi-stage Docker builds allow you to create optimized images by leveraging multiple build stages. To create a multi-stage build, you define multiple FORM instructions in the Docker file, each representing a different build stage and the subsequent stage copies only required artifacts from the previous build using COPY --from the instruction. This technique reduces image size by excluding build tools and dependencies from the final image. Each stage can use a different base image.

22. How do you create a custom Docker network?

    Ans: To create a custom Docker network, you can use docker network create command.

23. An update needs to be applied without any data loss. How would you update a Docker container without losing data?

    Ans: Steps to update Docker container without losing data are as follows:

    • Check where the application stores the data (i.e.,/var/lib/mysql)

    • use docker inspect <container_name> to identify mounted volumes or bind mounts. Look for the mount section in the output to locate the data directory.

    • If it is a bind-mount method, then use the docker cp command to copy data from the container to the host machine docker cp <container name>:<path in container> <path on host> .

    • If it is the Docker volume method, then you can create a tarball for the volume contents by running a temporary container to access the volume and then tar it.

    • For databases, we can use application-specific backup tools like mysql dump for mysql or pgdump for PostgreSQL.

    • Then, stop the container using the docker stop command.

    • Pull the latest version of the container using docker pull.

    • Start a new container with the latest image, making sure to map any volumes or bind mounts and make sure the container is working fine.

24. How do you secure Docker containers?

    Ans: A Few ways to secure containers are as follows:

    • Use distro-less images having fewer packages and dependencies.

    • Use custom networking instead of the default bridge network.

    • Use image scanning tools like Docker Scout.

25. Have you ever used Docker in combination with CI/CD?

    Ans: Yes, in all the projects we use Docker with Azure DevOps CI/CD. For example, in the current project, we have integrated Docker with Azure DevOps in the build stage. We have used Docker@2 task in a build job in Azure DevOps and push it to ACR.

    We have further made it pull to AKS for deployment. We have also configured Azure App services with the container.

26. How do you monitor Docker containers?

    Ans: There are various ways to monitor containers, such as:

    • Using Docker built-in commands such as docker stats and docker container stats

    • In our project set Docker container monitoring is primarily handled by a dedicated monitoring team using the ELK stack.

    • For instance, I ensured all containers had proper log routing to the monitoring teams’ ELK stack by configuring log drivers and standardizing log formats

    • The monitoring team created Kibana to visualize container performance, and I ensured that each container is configured properly for logging by setting up log drivers or editing the /etc/docker.daemon.json configuration to make it effective globally. This configuration was performed via Ansible during host VM configuration.

    • I also work closely with the monitoring team to define relevant metrics such as resource usage, errors, and access logs.

Terraform Questions

1. What is Terraform, and how does it work?

   Ans: Terraform is an IAC(Infrastructure as Code) tool that lets you write code to define and manage your cloud and on-prem infrastructure. With Terraform, you describe the desired state of your infrastructure using Terraform manifests, and Terraform figures out how to achieve that state, and then it interacts with cloud providers to achieve this state. As part of this, Terraform also generates a state file.

2. A DevOps Engineer manually created infrastructure on Azure, and there is a requirement to manage that resource using Terraform. How would you import it into Terraform code?

   Ans: This situation is called configuration drift, and yes, we can manage manually created resources via Terraform following the steps below:

   • Write the Terraform configuration code for each resource you want to import.

   • Run the terraform import command for each resource, specifying the resource type and its unique identifier.

     terraform import azurerm_resource_group.example /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-dev-apps .

   • Verify the import using terraform show command will show the latest state.

   • Run terraform plan to see if there are any discrepancies between the imported state and your configuration.

3. You have multiple environments, such as dev, qa, staging, and prod, for your application, and you want to use the same code for all these environments. How would you do that?

   Ans: There are multiple ways we can achieve this, and a few of them will be discussed here:

   • Using different .tfvars files: You can define a separate .tfvars file for each environment containing environment-specific variables, and during the terraform apply time you can refer to the respective variable file with the following command:

     terraform apply -var-file=”dev.tfvars”

     terraform apply -var-file=”qa.tfvars”

   • Using Workspace: The Terraform workspace allows you to manage state files within the same configuration. Each workspace represents a separate environment with its respective state file. We can create workspaces using terraform workspace new <workspacename> the command and switch to each workspace using terraform workspace select <workspacename>. And we can use terraform. workspace it as a variable like terraform. Workspace this in the Terraform manifest for referring to the environments.

   • Using a dedicated directory structure for each environment: we can create different directory structures for each environment, such as dev, qa, and uat, which will have their own manifests file, but we do not mostly use this as it might be redundant and require more maintenance.

4. What is a Terraform state file, and why is it important?

   Ans: Terraform state file is a JSON or binary file that stores the current state of the managed infrastructure. It is the heart of Terraform. It is like a blueprint that stores information about the infrastructure you manage.

   It is crucial because it helps Terraform to understand what is already set up and what changes need to be made to the existing infrastructure by comparing the current state and desired state.

5. A DevOps Engineer accidentally deleted the state file. What step should be taken to resolve this?

   Ans: The following steps can be taken to resolve this issue:

   • Recover Backup: If available, restore the state file from the recent backup. When the terraform state is managed locally, a terraform.tfstate.backup file is created every time someone performs terraform apply. You can simply rename terraform.tfstate.backup to terraform.tfstate The latest state file has been recovered this way.

   • Recreate the State file: If no backup is available, then we have to manually reconstruct the stateful by inspecting existing infrastructure and using terraform import for each missing resource. This is not the ideal way.

6. What are the best practices for managing the Terraform state file?

   Ans: The following are some best practices that we can follow while managing the Terraform state file:

   • Remote State Store: stores the state file remotely, which uses Azure Blob store and AWS S3 with Dynamo DB.

   • State Locking: Enable state locking so that the state file will remain intact when multiple people try to make changes simultaneously.

   • Backup: Enable automated backup for state file safety in case of accidental deletion.

   • Access Control: Limit access to the state file to authorize users and services.

   • Distinguished Environments: Finally, create a separate state file for each environment for better management and isolation.

Your team is adopting a multi-cloud strategy, and you need to manage resources on both AWS and Azure using Terraform. How do you structure Terraform code to handle this?

Ans: Terraform is cloud agnostic, which means it supports multi-cloud setups.

1. Use Separate Provider Blocks:

Define providers for both clouds in your root main.tf or relevant modules:

# Azure provider
provider "azurerm" {
  alias   = "azure"
  features {}
}

# AWS provider
provider "aws" {
  alias  = "aws"
  region = "us-east-1"
}
Isolate State Files Per Cloud

2. Keep separate backend configurations (e.g., S3 for AWS, Azure Blob for Azure):

terraform {
  backend "azurerm" {
    # for Azure
  }
}

For AWS setup:

terraform {
  backend "s3" {
    # for AWS
  }
}

You can also use workspaces or separate pipelines to manage them.

3. Use Workspaces or CI/CD to Manage Environments:

For dev, qa, prod across clouds, use:

• Named workspaces

• Separate *.tfvars per environment

• Environment-specific modules

4. Separate Azure and AWS infrastructure into modules:

terraform/
├── main.tf
├── providers.tf
├── aws/
│   └── ec2-instance/
│       └── main.tf
├── azure/
│   └── storage-account/
│       └── main.tf
├── variables.tf
└── terraform.tfvars

Then call them like this in the root module:

module "azure_storage" {
  source   = "./azure/storage-account"
  providers = {
    azurerm = azurerm.azure
  }
  # pass variables
}

module "aws_ec2" {
  source   = "./aws/ec2-instance"
  providers = {
    aws = aws.aws
  }
  # pass variables
}

7. You want to run some shell scripts after creating your resources with Terraform, so how would you achieve this?

   Ans: You can achieve this using provisioners. There are 3 types of provisions in Terraform:

   • Local Exec Provisioners: This provisioner executes commands and scripts locally on your local machine.

   • Remote Exec Provisioners: It executes commands and scripts on a provisioned remote machine.

   • File Provisioners: It moves files to the provisioned resources.

In this given scenario, we can use File Provisioners and Remote Exec Provisioners combined, which will copy the script file to the remote server and execute the same, respectively.

8. Your company is looking to enable High Availability. How can you perform blue-green deployment using Terraform?

   Ans: To implement a blue-green deployment using Terraform, you can provision two identical environments—commonly referred to as blue and green—using infrastructure components like Virtual Machine Scale Sets (VMSS) in Azure or Auto Scaling Groups (ASG) in AWS.

   Once the new (green) environment is deployed and thoroughly tested, you can switch traffic from the existing (blue) environment to the green one by updating the Load Balancer backend pool or modifying DNS records. This approach minimizes downtime and allows easy rollback if issues are detected.

9. Your company wants to automate Terraform through CI/CD pipeline. How can you integrate Terraform with CI/CD pipelines?

Ans: Integrating Terraform with a CI/CD pipeline involves setting up an automated workflow that handles infrastructure provisioning and management consistently. Here's a step-by-step guide to achieve this:

Step 1: Store Terraform Code in a Version Control System (VCS):

• Push your Terraform configuration files (.tf files) to a source code repository such as GitHub, Azure Repos, or GitLab.

• Follow a branching strategy (e.g., feature, staging, production branches) to manage infrastructure changes.

  Step 2: Set Up Remote Backend for State Management:

• Use a remote backend like Azure Storage Account, AWS S3 with DynamoDB, or Terraform Cloud to manage the Terraform state file securely and support collaboration.

  Step 3: Define CI/CD Pipeline Configuration:

• Create a pipeline file (e.g., azure-pipelines.yml, .gitlab-ci.yml, or GitHub Actions workflow) with Terraform stages like:

  • Terraform Init

  • Terraform Validate

  • Terraform Plan

  • Terraform Apply (manual approval for production)

Step 4: Configure Pipeline Agent and Environment:

• Use a self-hosted agent or cloud-hosted agent with Terraform installed.

• Set up environment variables or secrets to securely pass cloud provider credentials (e.g., Azure service principal, AWS access keys).

Step 5: Implement Pipeline Steps:

Typical pipeline stages:

1. Terraform Init – Initialize the working directory.

2. Terraform Validate – Check for syntax or configuration errors.

3. Terraform Plan – Show the execution plan of proposed changes.

4. Terraform Apply – Apply the changes (with manual approval if needed).

5. (Optional) Terraform Destroy – Clean up resources after testing.

Step 6: Add Approval Gates and Environment Controls:

• Use manual approvals or release gates to control changes to production.

• Configure role-based access to ensure only authorized personnel can approve or apply changes.

Step 7: Monitor and Audit:

• Enable logging and notification integrations (e.g., Slack, Microsoft Teams).

• Track infrastructure changes via version control and pipeline run history.

10. Describe how you can use Terraform with configuration management tools like Ansible.

    Ans: Terraform and Ansible complement each other in infrastructure automation workflows. While Terraform is used for provisioning infrastructure, Ansible is used for configuring the provisioned resources.

    In our project, we use Terraform to provision virtual machines (VMs) and other infrastructure components. Once the VMs are up and running, Ansible takes over to configure these servers—installing and setting up various applications and agents such as ELK Stack, Rapid7, Arctic Wolf, and others.

    This integration allows us to:

    • Automate end-to-end provisioning and configuration.

    • Maintain separation of concerns—Terraform manages infrastructure, Ansible manages software.

    • Achieve faster and more consistent deployments across environments.

11. Your infrastructure contains database passwords and other sensitive information. How can you manage secrets and sensitive data in Terraform?

Ans: Managing sensitive data securely is crucial when using Terraform. Below are best practices and methods we follow to handle secrets:

Use Azure Key Vault (or other Secret Managers):

• We primarily use Azure Key Vault to store and retrieve secrets like database passwords, API keys, and certificates securely.

• Terraform can be configured to fetch secrets from Key Vault dynamically during execution.

Use Terraform Input Variables with sensitive = true :

• Marking variables as sensitive prevents Terraform from displaying them in logs or plan outputs.

• Avoid hardcoding values directly into the .tf files.

Use Environment Variables for Sensitive Inputs:

• Environment variables (e.g., TF_VAR_db_password) can be used to pass sensitive data securely to Terraform at runtime.

Never Hardcode Secrets in Terraform Files:

• Always use variables or external secret sources instead of embedding secrets directly in .tf manifests.

Protect Sensitive Files with .gitignore :

• Add files containing secrets (like *.pem, .env, SSH keys) to your .gitignore to ensure they are not committed to version control.

Implement Linters and Pre-Commit Hooks:

• Use tools like tflint, tfsec, or pre-commit hooks to detect and prevent accidental inclusion of sensitive data in code.

12. How can you specify dependencies between resources in Terraform?

    Ans: In Terraform, dependencies between resources are typically handled automatically through implicit dependencies based on references. However, when more control is needed, you can define explicit dependencies. Here’s how both methods work:

    • Implicit Dependencies (Recommended):

      Terraform automatically understands the dependency graph when one resource references another.

      Example: A Virtual Machine that depends on a Network Interface, which in turn depends on a Subnet and Virtual Network.

        resource "azurerm_virtual_network" "vnet" {
          name                = "my-vnet"
          address_space       = ["10.0.0.0/16"]
          location            = "East US"
          resource_group_name = azurerm_resource_group.rg.name
        }
      
        resource "azurerm_subnet" "subnet" {
          name                 = "my-subnet"
          resource_group_name  = azurerm_resource_group.rg.name
          virtual_network_name = azurerm_virtual_network.vnet.name
          address_prefixes     = ["10.0.1.0/24"]
        }
      
        resource "azurerm_network_interface" "nic" {
          name                = "my-nic"
          location            = "East US"
          resource_group_name = azurerm_resource_group.rg.name
      
          ip_configuration {
            name                          = "internal"
            subnet_id                     = azurerm_subnet.subnet.id
            private_ip_address_allocation = "Dynamic"
          }
        }
      
        resource "azurerm_linux_virtual_machine" "vm" {
          name                  = "my-vm"
          resource_group_name   = azurerm_resource_group.rg.name
          location              = "East US"
          size                  = "Standard_B1s"
          admin_username        = "azureuser"
          network_interface_ids = [azurerm_network_interface.nic.id]
          # other configuration...
        }
      

      Terraform knows the VM depends on the NIC, which depends on the subnet and VNet — all handled implicitly

    • Explicit Dependencies (Using depends_on):

      If there’s no direct reference but a dependency still exists, use the depends_on argument.

      Example: You want a Public IP to be created only after a Network Security Group (NSG), even though there’s no direct reference:

        resource "azurerm_network_security_group" "nsg" {
          name                = "my-nsg"
          location            = "East US"
          resource_group_name = azurerm_resource_group.rg.name
          # rules...
        }
      
        resource "azurerm_public_ip" "public_ip" {
          name                = "my-public-ip"
          location            = "East US"
          resource_group_name = azurerm_resource_group.rg.name
          allocation_method   = "Static"
      
          depends_on = [azurerm_network_security_group.nsg]
        }
      

    • Module-Level Dependencies:

      If using modules (e.g., separate modules for networking, compute, storage), use depends_on at the module level to control the order.

        module "network" {
          source = "./modules/network"
          # outputs a subnet ID
        }
      
        module "vm" {
          source     = "./modules/compute"
          subnet_id  = module.network.subnet_id
          depends_on = [module.network]
        }
      

      • Use references (like resource IDs or names) for implicit dependencies.

      • Use depends_on When there’s no direct reference, but a logical dependency exists.

      • Manage module dependencies carefully using depends_on and output values.

13. You have 20 resources created through Terraform, but you want to delete only one of them. Is it possible to destroy a single resource out of multiple resources using Terraform?

    Ans: Yes, Terraform allows you to destroy a specific resource without affecting the rest of your infrastructure. You can use the following command to destroy a single resource:

    terraform destroy -target=<resource_type.resource_name>

    Example: If you want to destroy a specific Azure Virtual Machine: terraform destroy -target=azurerm_linux_virtual_machine.my_vm

14. How can you create a particular type of resource multiple times without duplicating the code?

    Ans: You can use count or for_each in Terraform to create multiple instances of the same resource dynamically, without duplicating code.

    • Using count (Index-based iteration):

      Use count when you want to create a fixed number of identical or similar resources.

      Example: Create 3 Azure Storage Accounts

        resource "azurerm_storage_account" "storage" {
          count                    = 3
          name                     = "mystorage${count.index}"
          resource_group_name      = azurerm_resource_group.rg.name
          location                 = azurerm_resource_group.rg.location
          account_tier             = "Standard"
          account_replication_type = "LRS"
        }
      

    • Using for_each (Key-based iteration):

      Use for_each When creating named resources or when working with maps and sets.

      Example: Create Storage Accounts using a map

        variable "storage_accounts" {
          default = {
            sa1 = "eastus"
            sa2 = "westus"
          }
        }
      
        resource "azurerm_storage_account" "storage" {
          for_each                 = var.storage_accounts
          name                     = each.key
          location                 = each.value
          resource_group_name      = azurerm_resource_group.rg.name
          account_tier             = "Standard"
          account_replication_type = "LRS"
        }
      

15. What is the Terraform module registry?

    Ans: The Terraform Module Registry is a centralized repository of reusable Terraform modules maintained by HashiCorp and the Terraform community. It provides a collection of pre-built, versioned, and well-documented modules that help you automate infrastructure provisioning without writing everything from scratch.

Here we’ll use all the Azure managed services such as:

• Azure Repos for version control

• ACR (Azure Container Registry) for strong docker images

• AKS (Azure Kubernetes Services) for deployment of the application to the K8S cluster

Setting up Azure Repo

As a very first step we’ll import the publicly available code to Azure Repos inside our project and to do so below are the steps

Import Code from the public GitHub repository to the Private Azure Repo

Verify the build branch is configured to the Main branch

The main branch will have the latest code changes and our target build branch will be the main form where code will be checked out

Create ACR (Container Registry)

Here we’ll create the resources using Azure CLI for faster deployment of resources.

• Login to Azure CLI using

  az login

• Create Resource Group

  az group create --name votingapp-deploy --location uksouth

• Create the container registry

  az acr create --resource-group votingapp-deploy --name votingappacr001 --sku standard --location uksouth

Build Pipeline Creation (Continuous Integration)

In this project we have 3 microservices below is the architecture:

• Vote: this component is created using Python

• Worker: this component is created using .Net Core

• Result: this is created using NodeJS

• DB: Postgres db is used for storing data

• Caching**: Redis** is used as in-memory caching

Using this architecture, we will develop three separate build pipelines for each microservice. This approach will allow for the independent construction of applications, which aligns with the primary goal of microservice architecture.

1. Pipeline for Result Microservice

In the pipeline section, we’ll first connect the pipeline with Azure Repos Git followed by selecting the repository i.e. voting-application followed by the configure section where we can select a template for our application to get started with. Our application is a containerized application that needs to be integrated with the container registry, we’ll select the below template:

# Docker
# Build and push an image to Azure Container Registry
# https://docs.microsoft.com/azure/devops/pipelines/languages/docker

trigger:
  paths:
    include:
      - result/*

resources:
- repo: self

variables:
  # Container registry service connection established during pipeline creation
  dockerRegistryServiceConnection: 'XXXXXX-XXXXX-XXXXXXX'
  imageRepository: 'resultapp'                # only for result app
  containerRegistry: 'votingappacr001.azurecr.io'
  dockerfilePath: '$(Build.SourcesDirectory)/result/Dockerfile'   # Docker file path for result app
  tag: '$(Build.BuildId)'

  # Agent VM image name
pool:
  name: azureagent

stages:
- stage: ImageBuild
  displayName: Build Result Image
  jobs:
  - job: Build
    displayName: Build
    steps:
    - task: Docker@2
      displayName: Build Image
      inputs:
        containerRegistry: '$(dockerRegistryServiceConnection)'
        repository: '$(imageRepository)'
        command: 'build'
        Dockerfile: 'result/Dockerfile'
        tags: '$(tag)'
- stage: ImagePush
  displayName: Push Result Image
  jobs:
    - job: Push
      displayName: Push Image
      steps:
      - task: Docker@2
        displayName: Push Image
        inputs:
          containerRegistry: '$(dockerRegistryServiceConnection)'
          repository: '$(imageRepository)'
          command: 'push'
          Dockerfile: 'result/Dockerfile'
          tags: '$(tag)'

2. Pipeline for Vote Microservice

   With this pipeline, we’ll follow a similar approach for building and pushing the vote microservice docker image to ACR. Here we have implemented a path filter for triggering the pipeline which means, the pipeline will trigger whenever there are any changes made to the vote microservice directory. The same approach has been implemented for the result microservice above as well

# Docker
# Build and push an image to Azure Container Registry
# https://docs.microsoft.com/azure/devops/pipelines/languages/docker

trigger:
  paths:
    include:
      - vote/*

resources:
- repo: self

variables:
  # Container registry service connection established during pipeline creation
  dockerRegistryServiceConnection: 'XXXXXX-XXXXXXXX-XXXXXXXXXX'
  imageRepository: 'votingapplication'
  containerRegistry: 'votingappacr002.azurecr.io'
  dockerfilePath: '$(Build.SourcesDirectory)/vote/Dockerfile'
  tag: '$(Build.BuildId)'

  # Agent VM image name
pool:
  name: azureagent  # Self-hosted agent

stages:
- stage: ImageBuild
  displayName: Build Vote Image
  jobs:
  - job: Build
    displayName: Build
    steps:
    - task: Docker@2
      displayName: Build 
      inputs:
        containerRegistry: '$(dockerRegistryServiceConnection)'
        repository: '$(imageRepository)'
        command: 'build'
        Dockerfile: 'vote/Dockerfile'
        tags: '$(tag)'
- stage: ImagePush
  displayName: Push Vote Image
  jobs:
    - job: Push
      displayName: Push Image
      steps:
        - task: Docker@2
          inputs:
            containerRegistry: '$(dockerRegistryServiceConnection)'
            repository: '$(imageRepository)'
            command: 'push'
            Dockerfile: 'vote/Dockerfile'
            tags: '$(tag)'

3. Pipeline for Worker Microservice

# Docker
# Build and push an image to Azure Container Registry
# https://docs.microsoft.com/azure/devops/pipelines/languages/docker

trigger:
  paths:
    include:
      - worker/*

resources:
- repo: self

variables:
  # Container registry service connection established during pipeline creation
  dockerRegistryServiceConnection: 'XXXXXXX-XXXXXXXXXXXXXXX-XXXXXXXX'
  imageRepository: 'workerapplication'
  containerRegistry: 'votingappacr003.azurecr.io'
  dockerfilePath: '$(Build.SourcesDirectory)/worker/Dockerfile'
  tag: '$(Build.BuildId)'

  # Self-hosted agent
pool:
  name: azureagent

stages:
- stage: Build
  displayName: Build Worker Image
  jobs:
  - job: Build
    displayName: Build Docker Image
    steps:
    - task: Docker@2
      displayName: Build Image
      inputs:
        containerRegistry: '$(dockerRegistryServiceConnection)'
        repository: '$(imageRepository)'
        command: 'build'
        Dockerfile: 'worker/Dockerfile'
        tags: '$(tag)'

- stage: Push
  displayName: Push Worker Image
  jobs:
  - job: Push
    displayName: Push Docker Image
    steps:
    - task: Docker@2
      displayName: Push Image
      inputs:
        containerRegistry: '$(dockerRegistryServiceConnection)'
        repository: '$(imageRepository)'
        command: 'push'
        tags: '$(tag)'

Docker files for Microservices

NOTE: These docker files are provided by the developer of the application, we have just used them here for building the application and demonstrating CI/CD.

Docker file for Result Service

The result application is developed on NodeJS so the following will be the docker file based on the node-18 image

FROM node:18-slim

# add curl for healthcheck
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl tini && \
    rm -rf /var/lib/apt/lists/*

WORKDIR /usr/local/app

# have nodemon available for local dev use (file watching)
RUN npm install -g nodemon

COPY package*.json ./

RUN npm ci && \
 npm cache clean --force && \
 mv /usr/local/app/node_modules /node_modules

COPY . .

ENV PORT=80
EXPOSE 80

ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["node", "server.js"]

Docker file for Vote Service

The voting service is based on Python so the base image is Python 3.11

# base defines a base stage that uses the official python runtime base image
FROM python:3.11-slim AS base

# Add curl for healthcheck
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl && \
    rm -rf /var/lib/apt/lists/*

# Set the application directory
WORKDIR /usr/local/app

# Install our requirements.txt
COPY requirements.txt ./requirements.txt
RUN pip install --no-cache-dir -r requirements.txt

# dev defines a stage for development, where it'll watch for filesystem changes
FROM base AS dev
RUN pip install watchdog
ENV FLASK_ENV=development
CMD ["python", "app.py"]

# final defines the stage that will bundle the application for production
FROM base AS final

# Copy our code from the current folder to the working directory inside the container
COPY . .

# Make port 80 available for links and/or publish
EXPOSE 80

# Define our command to be run when launching the container
CMD ["gunicorn", "app:app", "-b", "0.0.0.0:80", "--log-file", "-", "--access-logfile", "-", "--workers", "4", "--keep-alive", "0"]

Docker file for Worker Service

The worker service is based on .NET so the .NET SDK has been taken as base image from Microsoft for this application

# because of dotnet, we always build on amd64, and target platforms in cli
# dotnet doesn't support QEMU for building or running. 
# (errors common in arm/v7 32bit) https://github.com/dotnet/dotnet-docker/issues/1537
# https://hub.docker.com/_/microsoft-dotnet
# hadolint ignore=DL3029
# to build for a different platform than your host, use --platform=<platform>
# for example, if you were on Intel (amd64) and wanted to build for ARM, you would use:
# docker buildx build --platform "linux/arm64/v8" .

# build compiles the program for the builder's local platform
FROM --platform=linux mcr.microsoft.com/dotnet/sdk:7.0 AS build
ARG TARGETPLATFORM
ARG TARGETARCH
ARG BUILDPLATFORM
RUN echo "I am running on $BUILDPLATFORM, building for $TARGETPLATFORM"

WORKDIR /source
COPY *.csproj .
RUN dotnet restore

COPY . .
RUN dotnet publish -c release -o /app --self-contained false --no-restore

# app image
FROM mcr.microsoft.com/dotnet/runtime:7.0
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "Worker.dll"]

With this, the build process is concluded and the image is stored in ACR as shown below

Continuous Delivery (GitOps)

The continuous delivery part will be taken care of by the tool called ArgoCD which will continuously look for the changes in Kubernetes manifests. Once any changes are found, it will deploy the new build to AKS.

NOTE: In the project, we have deployment files, service files, DB deployment, and DB. service files, which will be updated with the latest docker image using a shell script. This shell script will be part of our CI pipeline in Azure DevOps, which will be executed after the push stage. It will fetch the image details and append them to the Kubernetes manifest files.

Why GitOps

GitOps takes care of continuous reconciliation, which keeps tracking the changes between the K8S cluster and K8S manifest files. We can put all the K8S-related files in GitOps and let them be monitored by GitOps so that we’ll have flawless cluster management. It also makes sure manifest drifts are automatically detected and fixed.

To achieve this entire delivery process we have to follow the following points:

• Create the AKS cluster and log into it

• Install ArgoCD side AKS cluster

• Configure ArgoCD within the K8S cluster

• Prepare the shell script to update the repository with the latest image pushed to ACR

1. AKS Cluster Creation and login

The cluster has been created:

2. Log into the cluster

    az aks get-credentials --resource-group <resource-group-name> --name <aks-cluster-name>
   

   We can use the above command to log into the cluster and get access via CLI. Once done, the aks cluster will be now merged with our local machine and we can manage the cluster from local machine itself

   

3. ArgoCD Installation in AKS Cluster

   Installing ArgoCD is pretty straight forward just got to their official documentation or just run the below commands

   kubectl create namespace argocd

   kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Configure ArgoCD

You can post installation the argocd pods are now running.

Now to configure argocd we have to take the following steps:

• Login to argoc:

  To login to argocd, first get the secret values with following commands

  kubectl get secrets -n argocd

  

  kubectl edit secret argocd-initial-admin-secret -n argocd

  when kubectl edit command is executed it will open the secrets as follows which will be in a base64 encoded format

  

  And to decode this you can use the following command

  echo <secret values> | base64 -d

  

  Now we have the admin secret value which will allow us to access the ArgoCD UI

• Access ArgoCD on Browser

  Now, to access ArgoCD on the browser, we need to expose the ArgoCD in LoadBalancer mode.

  Get the service details:

  kubectl get svc -n argocd and below is the argocd server that we need to expose with LoadBalancer which is currently in Cluster mode

  

  Now to get it exposed on NodePort we have to edit the service file and change the service type from ClusterIP to LoadBalancer

  

  The above type is now modified to LoadBalancer

  

  Now you can see it is changed to LoadBalancer and we can you external IP to directly access ArgoCD

  

  Now we are able to access the ArgoCD

  

  We can log in with the username as admin and password as the decoded secret.

Connecting ArgoCD to Azure Repo

ArgoCD needs to have access to the Azure Repos where the K8S manifests files are present then only, it will be able to access the manifests. To establish the connection we need to get the access token with only Read Permission as the ArgoCD only needs to read the manifests and I already have an access token ready with me that I can reuse.

Once the token is ready, move to Settings —> Repository in ArgoCD and click on Connect Repo

Fill in the necessary repository details to clone the repository. Here I have replaced Azure DevOps Organization Name with the Access Token

And now, ArgoCD is connected to my Azure Repo

Adding Manifests to ArgoCD

Now to let the ArgoCD know where to pick the deployment and service manifests click on Applications —> Create Application and follow the pages

Below is the important section where we are letting argoCD know to which directory to look for changes inside the repository in our case it’s K8S Specification as shown below and click on Create.

Now finally ArgoCD is configured successfully and it is has synced the deployment files

From now on, if there are any changes made to K8S Specification directory, ArgoCD will detect the changes and update the K8S cluster.

Establish Connectivity between Deployment manifests and ACR

This step is necessary because K8S deployment should be able to fetch the image from our Private Registry. Below is a kubectl command which will create a secret in Kubernetes that we can refer to in you deployment manifests

kubectl create secret docker-registry <secret name> \
    --namespace default \
    --docker-server=<RegistryName>.azurecr.io \
    --docker-username=<User name> \
    --docker-password=<Registry Password>

Below is how the secret is referred to in deployment manifests

    spec:
      containers:
      - image: votingappacr001/votingapplication:89
        name: vote
        ports:
        - containerPort: 80
          name: vote
      ImagePullSecrets:
        - name: acrsecret # this is the secret name which is created above

Integrating Azure DevOps for Auto-updating K8S Manifests

We’ll be adding another stage to the Azure CI Pipeline to achieve this which will execute a shell script to further update the deployment files. This stage will be created in all 3 pipelines for respective services

- stage: Update
  displayName: Update vote app Deployment Manifests
  jobs:
    - job: Update
      displayName: Update vote app Deployment Manifests
      steps:
      - task: ShellScript@2
        inputs:
          scriptPath: 'scripts/updatek8manifests.sh'
          args: 'vote $(imageRepository) $(tag)'
        displayName: Update vote app Deployment Manifests

K8S Deployment Manifest update Script

#!/bin/bash

set -x

# Set the repository URL
REPO_URL="https://azuredevopsprep@dev.azure.com/az-devops-prep/voting-application/_git/voting-application"

# Clone the git repository into the /tmp directory
git clone "$REPO_URL" /tmp/temp_repo

# Navigate into the cloned repository directory
cd /tmp/temp_repo

# Make changes to the Kubernetes manifest file(s)
# For example, let's say you want to change the image tag in a deployment.yaml file
sed -i "s|image:.*|image: votingappacr001.azurecr.io/$2:$3|g" k8s-specifications/$1-deployment.yaml

# Add the modified files
git add .

# Commit the changes
git commit -m "Update Kubernetes manifest"

# Push the changes back to the repository
git push

# Cleanup: remove the temporary directory
rm -rf /tmp/temp_repo

Here $1, $2, and $3 represent the arguments passed in the Update stage in the pipeline i.e. args: 'vote $(imageRepository) $(tag)' respectively.

This script will update the deployment manifests with the latest image tags after the image is pushed to ACR and when the change is detected by ArgoCD, it will re-deploy the pods to containers with the latest image.

Conclusion

With this, we have implemented Continuous Integration and Continuous Delivery for 3 microservices along with GitOps implementation via ArgoCD

Creating Service Connection

This build and release pipeline will plan and apply Terraform manifests, as part of which it will generate the state files and create resources that are on Azure. To enable this communication between the pipeline and Azure Cloud, we need to establish a Service Connection which can be done using the following steps.

CI-Build Pipeline

Task 1

In this step, the Terraform manifests, which are essential for infrastructure provisioning, are copied from the system's default directory to the build artifact directory. This ensures that the configuration files are organized and accessible for downstream pipeline stages.

The Continuous Integration (CI) pipeline is a critical part of the DevOps lifecycle, enabling seamless integration and testing of code changes. In this pipeline, we handle the preparation of Terraform manifests for deployment and ensure they are readily available for subsequent release pipelines.

# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml

trigger:
- main

pool: Default
  #vmImage: ubuntu-latest
stages:
  - stage: GetTerraformManifests
    displayName: Build Stage
    jobs:
      - job: FetchTerraformManifests
        steps:
          - bash: echo "contents in working directoy"; ls -lrth $(System.DefaultWorkingDirectory)

          - task: CopyFiles@2
            inputs:          #/home/ubuntu/myagent/_work/1/s/16-Azure-IAC-DevOps/terraform-manifests
              SourceFolder: '$(System.DefaultWorkingDirectory)/16-Azure-IAC-DevOps/'
              Contents: '**'
              TargetFolder: '$(System.DefaultWorkingDirectory)'

          - bash: echo "contents in working directoy"; ls -lrth $(System.DefaultWorkingDirectory)
            displayName: List Contents post copying

          # Copy Terraform files to the Artifact Staging Directory
          - task: CopyFiles@2
            displayName: Copy Terraform Manifests to Staging Directory
            inputs:
              SourceFolder: '$(System.DefaultWorkingDirectory)/terraform-manifests'
              Contents: '**/*'  # Copy all files and subdirectories
              TargetFolder: '$(Build.ArtifactStagingDirectory)'

          - task: PublishBuildArtifacts@1
            displayName: Publish Manifests to Release pipeline
            inputs:
              PathtoPublish: '$(Build.ArtifactStagingDirectory)'
              ArtifactName: 'terraform-manifests'
              publishLocation: 'Container'

This pipeline is a foundational example that demonstrates how to fetch, process, and publish Terraform manifests for use in subsequent stages like deployment. Below is a detailed breakdown of each section of the YAML pipeline.

Trigger Section

trigger:
- main

• Purpose:
  The pipeline is configured to trigger automatically whenever there is a commit to the main branch.

Pool Section

pool: Default

• Purpose:
  The pipeline runs on the default agent pool. I have added my self-hosted agent to the default pool.

Stages

The pipeline contains a single stage, GetTerraformManifests, designed to build and prepare Terraform manifests.

Stage: GetTerraformManifests

stages:
  - stage: GetTerraformManifests
    displayName: Build Stage

• Purpose:
  The primary stage to gather and publish Terraform manifests required for deployment.

Job: FetchTerraformManifests

jobs:
  - job: FetchTerraformManifests

• Purpose:
  A single job under the stage that defines the steps to fetch and publish the Terraform manifests.

Steps Breakdown

1. List Initial Directory Contents

    - bash: echo "contents in working directory"; ls -lrth $(System.DefaultWorkingDirectory)
   

   • Explanation:
     Outputs the contents of the working directory before any processing. This helps to verify the initial state and debug potential issues.

2. Copy Terraform Manifests from Source to Working Directory

    - task: CopyFiles@2
      inputs:
        SourceFolder: '$(System.DefaultWorkingDirectory)/16-Azure-IAC-DevOps/'
        Contents: '**'
        TargetFolder: '$(System.DefaultWorkingDirectory)'
   

   • Purpose:

     • Copies all files from the specified source folder (16-Azure-IAC-DevOps) to the working directory.

     • Ensures Terraform files are available for further processing.

3. List Directory Contents Post-Copying

    - bash: echo "contents in working directory"; ls -lrth $(System.DefaultWorkingDirectory)
      displayName: List Contents post copying
   

   • Purpose:
     Outputs the contents of the directory after copying to verify the successful transfer of files.

4. Copy Terraform Files to Staging Directory

    - task: CopyFiles@2
      displayName: Copy Terraform Manifests to Staging Directory
      inputs:
        SourceFolder: '$(System.DefaultWorkingDirectory)/terraform-manifests'
        Contents: '**/*'  # Copy all files and subdirectories
        TargetFolder: '$(Build.ArtifactStagingDirectory)'
   

   • Purpose:

     • Moves all Terraform manifests to the Artifact Staging Directory.

     • Prepares the files for publishing as build artifacts.

5. Publish Terraform Manifests as Build Artifacts

    - task: PublishBuildArtifacts@1
      displayName: Publish Manifests to Release pipeline
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'terraform-manifests'
        publishLocation: 'Container'
   

   • Purpose:

     • Publishes the Terraform manifests from the staging directory as build artifacts.

     • The artifact is named terraform-manifests and is made available in the container.

     • These artifacts can be used in subsequent Release Pipelines for deploying infrastructure.

Key Benefits of This Pipeline

1. Streamlined Artifact Management:
   Automates the process of gathering and preparing Terraform manifests for deployment.

2. Modularity:
   Artifacts published here can be reused across multiple release pipelines, enabling consistent and efficient deployment workflows.

3. Traceability:
   Each step is logged and auditable, ensuring that the process is transparent and easy to troubleshoot.

4. Scalability:
   Provides a base pipeline that can be extended to include additional stages, such as testing or multi-environment deployments.

This pipeline is a crucial first step in integrating Terraform workflows into your CI/CD processes, ensuring that the infrastructure-as-code artifacts are always ready for deployment.

Release Pipeline

The release pipeline leverages the artifacts created during the CI process to deploy identical resources in multiple environments—Dev, QA, Staging, and Production. Each environment is isolated and configured with unique settings to reflect the appropriate stage of the application lifecycle.

NOTE: by default, the creation of a Release Pipeline is disabled as it is considered as legacy. To create the release pipeline you have to

1. Go to your Project Settings.

2. Under the Pipelines section, select Settings.

3. Scroll down to the Classic Release Pipelines option and enable it.

Configure Artifact Source

In the release pipeline, we have first to configure the source of artifacts i.e. from our build pipeline

Then enable the continuous deployment trigger as shown below

Dev Environment

Release Pipeline for Dev

1. Configure the agent job where you define the pool and other configurations

2. Terraform Installation Task where you define the supported terraform version that needs to be installed in your server and perform the execution

   

3. Terraform Init task

   

   Here we configure the backend which eliminates the need to explicitly define details in the terraform configuration ( versions.tf ) file.

   

4. Terraform Validate Task

   This task will validate the terraform configuration present inside the path given in the configuration directory

   

5. Terraform Plan Task

   This task will run the terraform plan command and display the resource creation plan for the same dev environment. Here along with terraform plan, we are providing an additional argument as -var-file=dev.tfvars which will utilize the variables dedicated to the dev environment for resource creation

   

Terraform Apply Task

This task will run the terraform apply command and perform the resource creation in the dev environment. Here along with terraform apply, we are providing an additional argument as -var-file=dev.tfvars & -auto-approve which will utilize the variables dedicated to the dev environment for resource creation without asking for manual intervention

Dev Environment Completion

With this the dev deployment has been completed

Terraform manifest Modification for Dev Environment

The Dev environment serves as the first stage for deploying and testing infrastructure. The configuration (tfvars) for the Dev environment includes:

• Virtual Network (VNet): 10.1.0.0/16

• Subnets:

  • Web Subnet: 10.1.1.0/24

  • App Subnet: 10.1.11.0/24

  • DB Subnet: 10.1.21.0/24

  • Bastion Subnet: 10.1.100.0/24

This environment is automatically deployed without manual intervention.

tfvars for Dev environment

environment = "dev"
vnet_address_space = ["10.1.0.0/16"]

web_subnet_name    = "websubnet"
web_subnet_address = ["10.1.1.0/24"]

app_subnet_name    = "appsubnet"
app_subnet_address = ["10.1.11.0/24"]

db_subnet_name    = "dbsubnet"
db_subnet_address = ["10.1.21.0/24"]

bastion_subnet_name    = "bastionsubnet"
bastion_subnet_address = ["10.1.100.0/24"]

QA Environment

Release Pipeline for QA Environment with Pre-Deployment Approval

The QA environment introduces Pre-Deployment Approvals, ensuring changes are reviewed before deployment. This step adds an extra layer of validation to maintain infrastructure consistency.

Most of the pipeline configuration will remain same with minor modifications, moving forward we’ll highlight only modified configurations for QA environment here. As most of the configuration will remain unchanged we can directly clone the dev stage by clicking on the clone has highlighteded below and then make the necessary modification to it.

Once cloned we can make the necessary modifications as shown

1. Configure Pre-Deployment Approver

   Here in QA deployment, we are required to verify the deployment before proceeding for which setting up the deployment approval is necessary and that can be configured as shown below

   

2. Terraform Init Task - QA

   In the QA environment, the terraform init command must be configured with a backend block pointing to the QA-specific container key.

   

3. Terraform Plan Task - QA

   There will be no change to the validation task. At the plan task the terraform plan command has to proceed with dev.tfvars file which requires the following change and then only the command will act as terraform plan -var-file=qa.tfvars

   

4. Terraform Apply Task - QA

   Similarly, for the terraform apply task the qa.tfvars var file has to be picked up as shown below

   

QA Environment Completion

As per the configuration, the QA deployment is now pending approval and once it is approved, it will deploy the identical environment.

Once approved it has now started the deployment

QA Deployment is now completed with all respective resources

Terraform Manifest Modification for QA Environment

Configuration for QA includes:

• Virtual Network (VNet): 10.2.0.0/16

• Subnets:

  • Web Subnet: 10.2.1.0/24

  • App Subnet: 10.2.11.0/24

  • DB Subnet: 10.2.21.0/24

  • Bastion Subnet: 10.2.100.0/24

tfvars for QA environment

environment = "qa"

vnet_address_space = ["10.2.0.0/16"]

web_subnet_name    = "websubnet"
web_subnet_address = ["10.2.1.0/24"]

app_subnet_name    = "appsubnet"
app_subnet_address = ["10.2.11.0/24"]

db_subnet_name    = "dbsubnet"
db_subnet_address = ["10.2.21.0/24"]

bastion_subnet_name    = "bastionsubnet"
bastion_subnet_address = ["10.2.100.0/24"]

Staging Environment with Pre & Post Deployment Approval

Just like the QA environment similar modification to each task also has to be done

Staging Environment Completion

For staging as well the deployment is completed post approval

The Staging environment represents a near-production setup and includes both Pre-Deployment and Post-Deployment Approvals. Pre-deployment approval ensures changes are authorized before execution, while post-deployment approval validates successful deployment and functionality.

Configuration for Staging includes:

• Virtual Network (VNet): 10.3.0.0/16

• Subnets:

  • Web Subnet: 10.3.1.0/24

  • App Subnet: 10.3.11.0/24

  • DB Subnet: 10.3.21.0/24

  • Bastion Subnet: 10.3.100.0/24

tfvars for Staging environment

environment = "staging"

vnet_address_space = ["10.3.0.0/16"]

web_subnet_name    = "websubnet"
web_subnet_address = ["10.3.1.0/24"]

app_subnet_name    = "appsubnet"
app_subnet_address = ["10.3.11.0/24"]

db_subnet_name    = "dbsubnet"
db_subnet_address = ["10.3.21.0/24"]

bastion_subnet_name    = "bastionsubnet"
bastion_subnet_address = ["10.3.100.0/24"]

Prod Environment with Pre-Deployment Approval

Like the Stage environment, similar changes must also be made for Prod.

Prod Deployment Completion

The Production (Prod) environment is the final deployment stage, ensuring the infrastructure is ready for live traffic. This environment requires Pre-Deployment Approvals to prevent unintended changes and maintain high reliability.

Configuration for Prod includes:

• Virtual Network (VNet): 10.4.0.0/16

• Subnets:

  • Web Subnet: 10.4.1.0/24

  • App Subnet: 10.4.11.0/24

  • DB Subnet: 10.4.21.0/24

  • Bastion Subnet: 10.4.100.0/24

tfvars for Prod Environment

environment = "prod"

vnet_address_space = ["10.4.0.0/16"]

web_subnet_name    = "websubnet"
web_subnet_address = ["10.4.1.0/24"]

app_subnet_name    = "appsubnet"
app_subnet_address = ["10.4.11.0/24"]

db_subnet_name    = "dbsubnet"
db_subnet_address = ["10.4.21.0/24"]

bastion_subnet_name    = "bastionsubnet"
bastion_subnet_address = ["10.4.100.0/24"]

Remote Backend

To ensure environment-specific isolation and consistency in Terraform state management, we configure a separate state storage container for each environment. This approach allows for safe, concurrent deployments while avoiding conflicts in state files. Here's how the Terraform settings are structured:

terraform {
  required_version = "~>1.5.6" # Minor version upgrades are allowed
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~>4.3.0"
    }

    random = {
      source  = "hashicorp/random"
      version = ">=3.6.0"
    }
  }
  # Nothing should be configured here in backend block as the detils will be passed via Azure DevOps pipeline
  backend "azurerm" {

  }

}

provider "azurerm" {
  features {}
  subscription_id = "XXXXXX-9342-XXXXXXX-XXXXXXXX"
}

Terraform Block

The terraform block defines the required Terraform version, providers, and the backend configuration:

• Required Version: Locked to ~>1.5.6 allowing minor upgrades.

• Providers:

  • azurerm: Azure Resource Manager provider, pinned to ~>4.3.0 for stability.

  • random: Used for generating random values, with a flexible version constraint of >=3.6.0.

• Backend Block:
  The backend block is intentionally left blank as the configuration will be dynamically provided through the Azure DevOps pipeline, ensuring secure and consistent handling of state files across environments.

Provider Configuration

The provider block configures the Azure Resource Manager (AzureRM) provider. It includes:

• Features Block: Enables additional provider features.

• Subscription ID: Specifies the Azure subscription for provisioning resources.

This setup ensures that the Terraform backend remains decoupled from the static code and is dynamically configured during pipeline execution. It allows for:

1. Environment-specific state management.

2. Enhanced security by avoiding hardcoding backend credentials.

3. Flexibility in scaling across multiple environments.

Dependency Lock File

The .terraform.lock.hcl file ensures consistency and reproducibility of Terraform runs by locking provider dependencies to specific versions. When multiple team members or CI/CD pipelines work on the same Terraform configuration, this file ensures that all environments use the exact same provider versions. Provider updates may introduce breaking changes or unexpected behaviors. Locking versions prevents Terraform from automatically upgrading to potentially incompatible versions.

You can use the below command to generate a platform-independent lock file which will support all types of operating systems.

terraform providers lock -platform=windows_amd64 -platform=darwin_amd64 -platform=linux_amd64

Use-Case

1. Hosting Multi-Tier Applications
   Route requests to different services within your application based on the URL path.
   Example: /auth routes to the authentication service, while /orders routes to the order management system.

2. Protecting Applications with WAF
   Use the WAF feature to secure your applications against web vulnerabilities, especially when hosting sensitive data or user-facing applications.

3. Serving Multiple Applications on a Single Gateway
   Host multiple websites or applications using different domain names or subdomains with a single Application Gateway instance.

4. Modernizing Legacy Applications
   Implement SSL offloading and URL-based routing to improve the performance of legacy systems that lack such capabilities.

5. Scaling Secure Web Applications
   Use autoscaling and load balancing to ensure availability and performance for applications experiencing variable or high traffic loads.

6. Global Applications with Centralized Security
   Centralize security policies for globally distributed applications using a single WAF-enabled Application Gateway.

Project Overview

In this project, we are extending our network architecture by introducing a dedicated Application Gateway Subnet, similar to the previously configured App Subnet and DB Subnet.

Key Configurations for Azure Application Gateway:

1️⃣ Application Gateway Backend Pool:

• Associate the pool with the Web VMSS (Virtual Machine Scale Set) for handling application traffic.

2️⃣ Frontend IP Configuration:

• Link the Frontend IP object with a public IP to enable external access.

3️⃣ Listeners Configuration:

• Configure listeners to monitor incoming requests on port 80.

4️⃣ Backend HTTP Settings:

• Define settings to connect the backend pool (Web VMSS) with appropriate HTTP configurations.

5️⃣ Routing Rules:

• Establish routing rules to associate listeners with backend pools and HTTP settings.

6️⃣ Health Probe Configuration:

• Enable health probes to monitor and ensure the availability of backend instances.

By the end of this project, the Azure Application Gateway will efficiently route and manage application traffic, ensuring optimal performance and availability.

Provision Application Gateway Subnet

This Terraform code configures the Application Gateway Subnet (AG Subnet), associates it with a Network Security Group (NSG), and creates inbound rules to allow traffic essential for the Application Gateway.

This setup ensures that the Application Gateway operates securely within its dedicated subnet while allowing only essential traffic. The NSG rules allow HTTP (80), HTTPS (443), and required ephemeral ports (65200-65535), ensuring proper communication and functionality.

# Create AG Subnet
resource "azurerm_subnet" "ag_subnet" {
  name                 = "${azurerm_virtual_network.vnet.name}-${var.ag_subnet_name}"
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = var.ag_subnet_address
  resource_group_name  = azurerm_resource_group.rg.name

}

# Create NSG for Subnet
resource "azurerm_network_security_group" "ag_snet_nsg" {

  name                = "${azurerm_subnet.ag_subnet.name}-nsg"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

}

# Associate ag_subnet with ag_snet_nsg

resource "azurerm_subnet_network_security_group_association" "associate_agnet_agnsg" {
  depends_on                = [azurerm_network_security_rule.application_gtw_nsg_rules_inbound]
  subnet_id                 = azurerm_subnet.ag_subnet.id
  network_security_group_id = azurerm_network_security_group.ag_snet_nsg.id

}

# Locals block for security rules
locals {
  ag_inbound_port_map = {
    # priority:port
    "100" : "80"
    "110" : "443"
    "130" : "65200-65535"
  }
}

# Create NSG Rules using azurerm_network_security_rule resource

resource "azurerm_network_security_rule" "application_gtw_nsg_rules_inbound" {
  for_each = local.ag_inbound_port_map

  name                        = "Rule_Port_${each.value}"
  access                      = "Allow"
  direction                   = "Inbound"
  network_security_group_name = azurerm_network_security_group.ag_snet_nsg.name
  priority                    = each.key
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = each.value
  source_address_prefix       = "*"
  destination_address_prefix  = "*"
  resource_group_name         = azurerm_resource_group.rg.name

}

1. Create an Application Gateway Subnet

The azurerm_subnet resource creates a subnet dedicated to the Application Gateway.

• Key Attributes:

  • address_prefixes: Specifies the address range for the subnet.

  • virtual_network_name: Associates the subnet with the existing Virtual Network.

  • resource_group_name: Links the subnet to the resource group.

2. Create Network Security Group (NSG)

The azurerm_network_security_group resource sets up an NSG for securing the Application Gateway Subnet.

• Key Attributes:

  • location: Specifies the region of the NSG.

  • resource_group_name: Associates the NSG with the same resource group as the subnet.

3. Associate NSG with the Subnet

The azurerm_subnet_network_security_group_association resource links the Application Gateway Subnet with its NSG.

• Key Attributes:

  • subnet_id: Identifies the Application Gateway Subnet.

  • network_security_group_id: Associates the NSG with the subnet.

• Dependency: This association is dependent on the creation of NSG rules to ensure proper configuration.

4. Define Local Map for Port Rules

The locals block contains a map of inbound ports with their respective priorities for the Application Gateway.

• Example:

  • Port 80 for HTTP (priority 100).

  • Port 443 for HTTPS (priority 110).

  • Ports 65200–65535 for internal communication (priority 130).

5. Create NSG Rules

The azurerm_network_security_rule resource dynamically generates inbound security rules using the for_each loop based on the port map defined in the locals block.

• Key Attributes:

  • priority: Ensures the order of rule evaluation.

  • destination_port_range: Specifies the target port(s) allowed.

  • protocol: Restricts to TCP traffic.

  • direction: Allows only inbound traffic.

  • access: Permits traffic matching the rule.

Ephemeral Ports

Ephemeral ports, also known as dynamic ports, are short-lived ports automatically allocated by the operating system to facilitate communication between a client and a server. These ports are used as the source ports for outbound traffic in a TCP/IP connection and are released once the communication is complete.

Why Are Ephemeral Ports Used in Application Gateway?

For Azure Application Gateway, ephemeral ports are crucial for managing backend connections. Here's why:

1. Backend Pool Communication: When the Application Gateway forwards client requests to backend servers (e.g., VMs or VMSS), it uses ephemeral ports for each session to establish a secure connection.

2. Load Balancing: Helps maintain multiple simultaneous connections to different backend servers, improving performance.

3. Avoiding Port Conflicts: Using a large range of dynamic ports reduces the risk of port conflicts between connections.

In Context of the NSG Rules

In the provided Terraform configuration, the rule to allow ephemeral ports (65200–65535) ensures:

1. Communication Between App Gateway and Backend Pool: This range allows the Application Gateway to connect to resources in its backend pool, such as VMs or VMSS.

2. Smooth Functioning of HTTP/HTTPS Traffic: Without this rule, the Application Gateway might fail to establish connections with backend instances.

Provision Application Gateway

Provisioning the application gateway has multiple sub-components which will be explained below

1. Create a Public IP for the Application Gateway

This public IP will be used for front-end communication.

# Required Resource: Azure Application Gateway Public IP
resource "azurerm_public_ip" "web_application_gateway_publicip" {
    name                = "${local.resource_name_prefix}-web-ag-publicip"
    allocation_method   = "Static"
    resource_group_name = azurerm_resource_group.rg.name
    location            = azurerm_resource_group.rg.location
    sku                 = "Standard"
}

2. Define Local Variables

These variables simplify naming conventions and support multiple applications with context-path-based routing.

# Azure AG Locals Block
locals {
  # Generic Configuration
  frontend_port_name               = "${azurerm_virtual_network.vnet.name}-feport"
  frontend_ip_configuration_name   = "${azurerm_virtual_network.vnet.name}-feipconfig"
  listener_name                    = "${azurerm_virtual_network.vnet.name}-httplistener"
  request_routing_rule1_name       = "${azurerm_virtual_network.vnet.name}-requestrouting1"

  # Application-Specific Configuration (App1)
  backend_address_pool_name_app1   = "${azurerm_virtual_network.vnet.name}-bepap_app1"
  http_setting_name_app1           = "${azurerm_virtual_network.vnet.name}-behttpsettung_app1"
  probe_name_app1                  = "${azurerm_virtual_network.vnet.name}-beprobe_app1"
}

3. Provision the Application Gateway

This block provisions the gateway with a Standard_v2 SKU and configures autoscaling, frontend IP, listeners, backend pools, and routing rules.

# Resource: Azure Application Gateway
resource "azurerm_application_gateway" "web_application_gateway" {
    name                = "${local.resource_name_prefix}-web_application_gateway"
    location            = azurerm_resource_group.rg.location
    resource_group_name = azurerm_resource_group.rg.name

    # Gateway SKU and Autoscaling
    sku {
      name = "Standard_v2"
      tier = "Standard_v2"
    }
    autoscale_configuration {
      min_capacity = 0
      max_capacity = 10 # Max 125 for Standard_v2 SKU
    }

    # Gateway IP Configuration
    gateway_ip_configuration {
      name     = "ag_ip_config"
      subnet_id = azurerm_subnet.ag_subnet.id
    }

    # Frontend Configuration
    frontend_port {
      name = local.frontend_port_name
      port = 80
    }
    frontend_ip_configuration {
      name                 = local.frontend_ip_configuration_name
      public_ip_address_id = azurerm_public_ip.web_application_gateway_publicip.id
      subnet_id            = azurerm_subnet.ag_subnet.id
    }

    # HTTP Listener
    http_listener {
      name                         = local.listener_name
      frontend_ip_configuration_name = local.frontend_ip_configuration_name
      frontend_port_name           = local.frontend_port_name
      protocol                     = "Http"
    }

    # Backend Configuration for App1
    backend_address_pool {
      name = local.backend_address_pool_name_app1
    }
    backend_http_settings {
      name                  = local.http_setting_name_app1
      cookie_based_affinity = "Disabled"
      port                  = 80
      protocol              = "Http"
      request_timeout       = 60
      probe_name            = local.probe_name_app1
    }

    # Health Probe for App1
    probe {
      name                 = local.probe_name_app1
      host                 = "127.0.0.1"
      interval             = 30
      timeout              = 30
      unhealthy_threshold  = 3
      protocol             = "Http"
      port                 = 80
      path                 = "/app1/status.html"
      match {
        body         = "App1"
        status_code  = ["200"]
      }
    }

    # Request Routing Rule
    request_routing_rule {
      name                        = local.request_routing_rule1_name
      rule_type                   = "Basic"
      http_listener_name          = local.listener_name
      backend_address_pool_name   = local.backend_address_pool_name_app1
      backend_http_settings_name  = local.http_setting_name_app1
    }
}

4. Key Features of the Configuration

1. Public IP:

   • Allocated statically and linked to the Application Gateway.

2. Autoscaling:

   • The gateway dynamically scales between 0 to 10 instances (configurable up to 125).

3. Context-Path-Based Routing:

   • Routes traffic based on the URL path (/app1 goes to App1 VMSS).

4. Health Probes:

   • Ensures backend VMSS health with custom probes targeting http://127.0.0.1/app1/status.html.

5. Listener and Rule Configuration:

   • Listens on port 80 and applies a request-routing rule to backend pools.

5. Attach the Application Gateway with VMSS Backend

Previously, the Virtual Machine Scale Set (VMSS) was configured with a standard load balancer for traffic distribution. In this setup, we have transitioned the VMSS to utilize the Application Gateway's backend address pool.

How It Works

1. A public IP is provisioned for external communication.

2. The Application Gateway is deployed in a dedicated subnet.

3. Frontend configuration is set up for HTTP traffic.

4. A listener receives incoming requests.

5. Backend pools and routing rules direct traffic to the appropriate VMSS based on the URL path.

6. Health probes ensure backend availability.

This Terraform configuration enables a scalable and efficient Azure Application Gateway setup with context-path-based routing and dynamic scaling that is suitable for modern applications.

By integrating Azure Traffic Manager with your Terraform Infrastructure as Code (IaC) setup, you can automate the deployment and management of traffic routing policies, enhancing both the performance and resilience of your applications. This approach not only simplifies the configuration process but also ensures consistency and repeatability across your infrastructure deployments.

Terraform Remote State Datasource

Terraform remote state data source retrieves the output values of the root module from some other terraform configuration using the latest state snapshot from the remote backend.

Use Case: Terraform Remote State Data Source in Azure Traffic Manager Setup

In this project, we are deploying web servers and app servers in two different Azure regions, each fronted by its own Load Balancer with a publicly exposed IP address. To ensure seamless load balancing across these regions, we will use Azure Traffic Manager, which will reside in a separate Terraform project.

How Remote State Data Source is Used

1. Regional Load Balancers: Each region’s Load Balancer is provisioned within its respective Terraform configuration.

2. Azure Traffic Manager Configuration: Azure Traffic Manager, in a separate Terraform configuration, retrieves the public IPs of these Load Balancers using the Terraform Remote State Data Source.

3. Traffic Balancing: Azure Traffic Manager distributes traffic between the regions based on its configured traffic-routing method (e.g., performance, priority, or geographic).

Key Benefits of this Approach

• Seamless Integration: The remote state data source eliminates manual intervention by dynamically fetching the required values.

• Decoupled Configurations: Load Balancers and Azure Traffic Manager are managed in separate configurations, enhancing modularity and maintainability.

• Efficient Failover and Load Balancing: With Azure Traffic Manager, traffic is intelligently routed to the most suitable region based on configuration, improving application availability and performance.

we manage two distinct Terraform projects, each responsible for deploying infrastructure in a separate Azure region. These projects generate independent state files to represent the deployed resources in their respective regions i.e. eastus2 and westus2

As we have provisioned 2 identical infrastructures in their respective regions. Now the Remote State Datastore will refer to both the state files present in the storage container when and wherever required.

Configure Remote State Datasource

The Remote State Data Source enables seamless integration across multiple Terraform projects. In this case, it will be used while creating the Azure Traffic Manager to establish connectivity between servers deployed in two different regions.

Project-1 Data Source (EASTUS2)

• Retrieves the Terraform state for resources deployed in the EASTUS2 region.

• Key configuration parameters include the storage account, resource group, and state file path.

# Project-1 Datasource(EASTUS2)
data "terraform_remote_state" "project1_eastus" {
    backend = "azurerm"
    config = {
        storage_account_name = "terraformstatestore0"
        resource_group_name = "terraform-storageAcc-rg"
        container_name = "tfstatefiles"
        key = "project-1-eastus2-terraform.tfstate"
        subscription_id = "xxxxxxx-xxxxxxxx-xxxxx"
    }

}

# Project-2 Datasource(WESTUS)
data "terraform_remote_state" "project2_westus" {
    backend = "azurerm"
    config = {
        storage_account_name = "terraformstatestore0"
        resource_group_name = "terraform-storageAcc-rg"
        container_name = "tfstatefiles"
        key = "project-2-westus2-terraform.tfstate"
        subscription_id = "xxxx-xxxxxxxxxxx-xxxxxxx"
    }

}

Project-2 Data Source (WESTUS)

• Retrieves the Terraform state for resources deployed in the WESTUS region.

• Similar parameters are defined to connect to the remote backend.

These data sources allow the Azure Traffic Manager to fetch public IPs from regional Load Balancers dynamically. Projects are managed separately, reducing complexity and enhancing modularity.

Important Consideration Before Implementing Azure Traffic Manager

Before implementing Azure Traffic Manager with the azurerm_traffic_manager_azure_endpoint resource, ensure that the domain_name_label attribute is defined in the Load Balancer Public IP. This is a necessary step for creating the Fully Qualified Domain Name (FQDN). Without this, Traffic Manager will not be able to resolve the FQDN correctly.

If the domain_name_label is not set or cannot be used, you will need to proceed with the azurerm_traffic_manager_external_endpoint resource, which allows you to use external endpoints with direct IP addresses instead of relying on the FQDN.

Provision Azure Traffic Manager

For provisioning Azure Traffic Manager via Terraform we will require the following terraform resource, respective input variable, and most importantly above defined Data Sources.

• azurerm_traffic_manager_profile

• azurerm_traffic_manager_azure_endpoint

# Resorce1: Traffic Manager Profile
resource "azurerm_traffic_manager_profile" "tm_profile" {
    name = "tmprofile-${random_string.random_name.id}"   # Name has to be unique across azure cloud
    resource_group_name = azurerm_resource_group.rg.name
    traffic_routing_method = "Weighted"
    dns_config {
      relative_name = "tmprofile-${random_string.random_name.id}"
      ttl = 100
    }
    monitor_config {
      protocol = "http"
      port = 80
      path = "/"
      interval_in_seconds = 30
      timeout_in_seconds = 9
      tolerated_number_of_failures = 3
    }

    tags = local.common_tags

}


# Traffic Manager Endpoint - Project-1-EastUs2

resource "azurerm_traffic_manager_azure_endpoint" "tm_endoint_project1_eastus2" {
    name = "tm-project1-eastus2"
    profile_id = azurerm_traffic_manager_profile.tm_profile.id
    weight = 50
    target_resource_id = data.terraform_remote_state.project1_eastus.outputs.web_lb_public_ip_id  # This is being refered from Remote datasource
}

# Traffic Manager Endpoint - Project-2-WestUs2
resource "azurerm_traffic_manager_azure_endpoint" "tm_endoint_project1_westus2" {
    name = "tm-project1-westus2"
    profile_id = azurerm_traffic_manager_profile.tm_profile.id
    weight = 50
    target_resource_id = data.terraform_remote_state.project2_westus.outputs.web_lb_public_ip_id  # This is being refered from Remote datasource
}

1. Traffic Manager Profile

The azurerm_traffic_manager_profile resource defines the Traffic Manager instance. The profile manages traffic routing across regions using the Weighted Routing method, which distributes traffic based on assigned weights.

• Key Configurations:

  • Name: A unique name for the profile (uses random_string to ensure uniqueness globally).

  • Traffic Routing Method: Defines the logic for routing traffic; in this case, Weighted is used to balance traffic based on specified weights.

  • DNS Config: Sets up the DNS entry for Traffic Manager with a time-to-live (TTL) value of 100 seconds.

  • Monitor Config: Configures health monitoring for endpoints, including the HTTP protocol, port, health check path, and failure tolerances.

2. Traffic Manager Endpoints

The endpoints in Traffic Manager represent the target resources (e.g., Load Balancers) that handle traffic in specific regions. Terraform’s azurerm_traffic_manager_azure_endpoint resource creates these connections.

Endpoint for Project-1 (EastUS2)

• Represents the Load Balancer in the EastUS2 region.

• Uses Terraform’s Remote State Datasource to retrieve the public IP of the Load Balancer (web_lb_public_ip_id) dynamically from the state file of the respective project.

• Assigned a weight of 50, which defines the proportion of traffic routed to this endpoint.

Endpoint for Project-2 (WestUS)

• Represents the Load Balancer in the WestUS region.

• Similarly, uses Remote State Datasource to fetch the public IP (web_lb_public_ip_id) from the state file of Project-2.

• Assigned an equal weight of 50 for traffic distribution.

How It Works

1. Traffic Manager Profile:

   • Acts as a global entry point for incoming traffic.

   • DNS configuration ensures that the Traffic Manager routes requests efficiently based on health and weight.

2. Remote State Integration:

   • Fetches real-time public IPs of Load Balancers deployed in different projects (EastUS2 and WestUS).

   • Enables seamless integration of regional resources without hardcoding IP addresses.

3. Load Balancing Logic:

   • The Weighted Routing method splits traffic evenly (50:50) between the two regions, ensuring high availability.

   • Health monitoring ensures only healthy endpoints receive traffic.

Traffic Manager Deployment Verification

The Azure Traffic Manager has been successfully deployed, and its Fully Qualified Domain Name (FQDN) is now available. The FQDN of the Traffic Manager profile can be accessed as shown below:

Additionally, we have verified the accessibility of the Traffic Manager's FQDN, confirming that traffic is being routed properly across the configured endpoints. The successful access test is shown below:

This verifies that the Traffic Manager is working as expected, balancing the traffic between the specified endpoints based on the configuration.

Verification on Azure Portal

Internal Load Balancer

An Internal Load Balancer (ILB) is restricted to a Virtual Network (VNet) or a subset of subnets within the VNet. It is accessible only within private IP ranges and doesn’t have a public endpoint.

In App Subnets, the ILB handles traffic between internal services, such as between the application layer and the database layer, without exposing the services to the internet. By keeping this traffic internal, ILBs add an extra layer of security, ensuring that sensitive data and application communications stay within the network boundaries.

It limits exposure of critical resources by keeping inter-service traffic within private IP ranges as well as reduces the attack surface since resources do not need to be publicly accessible and helps enforce strict network segmentation, ensuring that only internal resources can interact with each other within controlled boundaries.

External Load Balancer

An External Load Balancer (ELB), or public load balancer, has a public IP address and is accessible over the internet.

In Web Subnets, an ELB distributes incoming internet traffic across the frontend or web servers in the subnet, typically hosted in a DMZ (Demilitarized Zone) within the VNet. It handles user traffic and ensures users have uninterrupted access to web services or applications, even during high-demand periods.

Controls the flow of incoming requests to the web servers, acting as a buffer to prevent direct access to backend or database layers. Integrates with security features such as NSGs (Network Security Groups), DDoS protection, and web application firewalls (WAF) to further protect against common web threats.

ILB & ELB Complement Each Other

Both ILBs and ELBs play essential roles in securing network traffic in a layered architecture:

• Internal Isolation: ILBs ensure that backend services are isolated and can only communicate internally, reducing the chance of unauthorized access from external sources.

• Traffic Control: ELBs manage all incoming traffic from the internet, filtering it before reaching any critical application layers.

• Enhanced Security Posture: Together, they create a layered security approach where only necessary traffic flows between layers, reducing exposure and ensuring tighter security across the entire VNet.

How They Complement Each Other

In a typical web application architecture:

• The External Load Balancer manages internet-facing traffic for the web layer in the Web Subnet.

• The Internal Load Balancer facilitates secure communication between the web layer and the App Subnet, and similarly from the App Subnet to other layers (e.g., database subnet).

Required Azure Resources for Internal LB

To provision an internal load balancer in the app subnet, several Azure resources are needed to ensure secure and efficient network traffic management without exposing the application to the public internet. The setup includes resources for NAT gateway configuration, internal load balancing, and storage for necessary configuration files. Each resource plays a role in directing internal traffic, enhancing security, and maintaining seamless communication within the application architecture.

This setup leverages key resources such as NAT Gateway with associated public IPs for secure internet access, Load Balancer components (backend pools, health probes, load balancing rules), and Storage Account resources for configuration file management within VMs. Together, these components provide a robust foundation for internal network traffic management within the application subnet.

1) Storage Account Setup

To support file operations required for our deployment, a storage account and blob storage are essential. These will enable secure storage and retrieval of configuration files and scripts needed for the virtual machines managed by the Azure VM Scale Set.

Primary resources include:

• azurerm_storage_account: Creates the storage account to store files and configuration data.

• azurerm_storage_container: Organizes and contains the blob files within the storage account.

• azurerm_storage_blob: Manages individual files to be stored and accessed for configurations.

This setup ensures that necessary files are accessible to VM instances, enhancing automation and configuration management across the scale set.

2) NAT Gateway Resource

Since the Internal Load Balancer (ILB) will reside in the app subnet without a public IP, a NAT gateway is necessary to enable outbound internet connectivity for resources in this subnet. The NAT gateway will route public internet traffic through a designated public IP, ensuring secure and controlled access.

Key resources include:

• azurerm_public_ip: Provides the public IP address for the NAT gateway.

• azurerm_nat_gateway: Sets up the NAT gateway instance to manage outbound traffic.

• azurerm_nat_gateway_public_ip_association: Links the NAT gateway with the public IP.

• azurerm_subnet_nat_gateway_association: Associates the NAT gateway with the app subnet.

This configuration ensures that resources behind the ILB can securely access the internet while maintaining the private, internal-only accessibility for incoming traffic.

3) Internal Load Balancer Resource

We've previously utilized resources to configure an external load balancer within the web subnet. Now, we’ll proceed by setting up the internal load balancer (ILB) in the app subnet, enhancing traffic control and security within our network.

Key resources in use include:

• azurerm_lb: Defines the load balancer instance.

• azurerm_lb_backend_address_pool: Configures backend pools for VM traffic distribution.

• azurerm_lb_probe: Sets up health probes to monitor VM health.

• azurerm_lb_rule: Manages the load balancing rules for specific traffic handling.

• azurerm_network_interface_backend_address_pool_association: Links VM NICs to the backend address pool.

This setup will enable efficient traffic routing and help in isolating internal applications, ensuring enhanced security and optimized performance across the application tier.

Storage Account & Blob Container

Before provisioning the load balancer, it’s essential to set up a storage account to store configuration files that will be utilized by the virtual machines provisioned through Azure Virtual Machine Scale Sets (VMSS). This process involves first creating a storage account and then establishing a storage container to securely store and organize these configuration files for seamless access during VM initialization.

Storage Account Input Variables

variable "storage_account_name" {
    description = "Name of the storage accoun"
    type = string

}
variable "storage_account_tier" {
    description = "Storage account tier"
    type = string

}
variable "storage_account_replication_type" {
    description = "Storage Account Replication Type"
    type = string

}
variable "storage_account_kind" {
    description = "Storage account kind"
    type = string

}
variable "static_websit_index_document" {
    description = "static website index document"
    type = string

}
variable "static_website_error_404_document" {
    description = "static website error 404"
    type = string

}

Storage Account Resource

resource "azurerm_storage_account" "storage_account_lb" {
    name = "${var.storage_account_name}${random_string.random_name.id}"
    account_replication_type = var.storage_account_replication_type
    resource_group_name = azurerm_resource_group.rg.name
    location = azurerm_resource_group.rg.location
    access_tier = var.storage_account_tier
    account_kind = var.storage_account_kind
    account_tier = var.storage_account_tier

    static_website {
      index_document = var.static_websit_index_document
      error_404_document = var.static_website_error_404_document
    }

}

resource "azurerm_storage_container" "storage_container" {
    name = "${local.resource_name_prefix}-httpd-files-container"
    storage_account_name = azurerm_storage_account.storage_account_lb.name
    container_access_type = "private"

}
locals {
  httpd_files = ["app1.conf"]
}

# Resource to upload file to the container
resource "azurerm_storage_blob" "storage_container_blob" {
    for_each = local.httpd_files
    name = "upload_${each.value}_file"
    storage_account_name = azurerm_storage_account.storage_account_lb.name
    storage_container_name = azurerm_storage_container.storage_container.name
    type = "Block"
    source = "${path.module}/app-scripts/${each. Value}"

}

• Storage Account (azurerm_storage_account):

  • Configured with a unique name using random_string, this storage account supports replication and access tier based on provided variables.

  • The static_website block enables static website hosting, specifying the index and error documents.

• Storage Container (azurerm_storage_container):

  • A private container named with a resource prefix is created within the storage account to securely store files required by the application.

• Storage Blob (azurerm_storage_blob):

  • Files listed in httpd_files are uploaded as blobs to the storage container. Each file is sourced from the local module path, allowing application-specific configurations (e.g., app1.conf) to be accessible within the VMSS environment.

Storage Account Outputs

output "storage_account_primary_access_key" {
    value = azurerm_storage_account.storage_account_lb.primary_access_key
    sensitive = true

}
output "storage_account_primary_web_endpoint" {
    value = azurerm_storage_account.storage_account_lb.primary_web_endpoint

}
output "storage_account_primary_web_host" {
    value = azurerm_storage_account.storage_account_lb.primary_web_host

}
output "storage_account_name" {
    value = azurerm_storage_account.storage_account_lb.name

}

NAT Gateway & Association with App Subnet

In the next steps, we’ll configure a NAT Gateway to manage secure inbound traffic for the application subnet. This involves:

1. Creating a Public IP Resource: A public IP will be created specifically for the NAT Gateway, ensuring controlled public access.

2. Deploying the NAT Gateway: This gateway will route incoming traffic securely through an internal load balancer, keeping the app subnet isolated from direct public access.

3. Associating NAT Gateway with Resources: Finally, we’ll link the NAT Gateway to the created public IP and associate it with the App subnet, directing traffic through the designated internal load balancer for secure connectivity.

#Create Public IP for Nat Gateway
resource "azurerm_public_ip" "nat_gateway_publicip" {
    name = "${local.resource_name_prefix}-natgtw_publicip"
    allocation_method = "Static"
    location = azurerm_resource_group.rg.location
    resource_group_name = azurerm_resource_group.rg.name
    sku = "Standard"

}
# Create NAT Gateway
resource "azurerm_nat_gateway" "nat_gateway_appsnet" {
    name = "${local.resource_name_prefix}-app-svc-nat-gateway"
    resource_group_name = azurerm_resource_group.rg.name
    location = azurerm_resource_group.rg.location
}

# Associate NAT gateway and public ip
resource "azurerm_nat_gateway_public_ip_association" "associate_natgtw_publicip" {
    nat_gateway_id = azurerm_nat_gateway.nat_gateway_appsnet.id
    public_ip_address_id = azurerm_public_ip.nat_gateway_publicip.id

}
# Associate App Subnet and Azure NAT Gateway
resource "azurerm_subnet_nat_gateway_association" "associate_natgtw_app_snet"{
    subnet_id = azurerm_subnet.app_subnet.id
    nat_gateway_id = azurerm_nat_gateway.nat_gateway_appsnet.id

}

App VMSS & NSG

In this section, we’ll set up the App Virtual Machine Scale Set (VMSS) similarly to the Web VMSS configuration. This App VMSS will be equipped with a dedicated Network Security Group (NSG) to define precise inbound and outbound traffic rules, enhancing network security for application resources.

The App VMSS will then be fronted by an internal load balancer, ensuring that internal traffic is efficiently managed. Additionally, it will be supported by a NAT Gateway to handle secure public connections, while still restricting direct access to the application subnet.

NSG Resource

# Create NSG using Terraform Dynamic Block
resource "azurerm_network_security_group" "app_vmss_nsg" {
  name = "${local.resource_name_prefix}-app-vmss-nsg"
  location = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  dynamic "security_rule" {
    for_each = var.app_vmss_nsg_inbound_ports
    content {
      name = "inbound-rule-${security_rule.key}"
      description = "Inbound-rule-${security_rule.key}"
      priority = sum([100,security_rule.key])
      direction = "Inbound"
      access = "Allow"
      protocol = "Tcp"
      source_port_range = "*"
      destination_port_range = security_rule.value
      source_address_prefix = "*"
      destination_address_prefix = "*"
    }

  }
}

• NSG Resource:

  • The azurerm_network_security_group resource creates the NSG, named based on a specified prefix and applied to the App VMSS. It is located in the same resource group and region as defined in the configuration.

• Dynamic Inbound Rules:

  • The dynamic "security_rule" block generates multiple inbound rules by iterating over var.app_vmss_nsg_inbound_ports.

  • Each rule allows TCP traffic on specific ports defined in app_vmss_nsg_inbound_ports.

  • The rule configuration includes:

    • Name and Description: Generated dynamically with a unique identifier for each rule.

    • Priority: Calculated based on the rule's index, ensuring proper order without conflicts.

    • Access: All rules are set to “Allow.”

    • Source/Destination Port and Address Ranges: Allows traffic from any source to any destination on the specified ports.

App VMSS Resource

# Resource VMSS(Virtual machine scale sets)

resource "azurerm_linux_virtual_machine_scale_set" "app_vmss" {
  name                 = "${local.resource_name_prefix}-app-vmss"
  admin_username       = var.linux_admin_username
  computer_name_prefix = "vmss-app"
  location             = azurerm_resource_group.rg.location
  sku                  = "Standard_DS1_v2"
  resource_group_name  = azurerm_resource_group.rg.name

  instances = 2 # Manually defining the number of instances. Hence, it is called manual scaling

  upgrade_mode = "Automatic" # VMs will be auto upgraded after associated with LB

  admin_ssh_key {
    username   = var.linux_admin_username
    public_key = file("${path.module}/ssh-keys/terraform-azure.pub")

  }
  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }
  source_image_reference {
    publisher = "RedHat"
    offer     = "RHEL"
    sku       = "83-gen2"
    version   = "latest"
  }
  network_interface {
    name                      = "vmss-nic"
    primary                   = true
    network_security_group_id = azurerm_network_security_group.app_vmss_nsg.id

    ip_configuration {
      name      = "internal"
      primary   = true
      subnet_id = azurerm_subnet.app_subnet.id
      # here the VMSS is now associated with Internal LoadBalancer.
      load_balancer_backend_address_pool_ids = [azurerm_lb_backend_address_pool.app_internal_lb_address_pool.id]
    }

  }
  custom_data = filebase64("${path.module}/app-script/appvm-script.sh") # One way of passing custom script


}

• VMSS Configuration:

  • Creates a VM scale set named after a defined prefix for application VMs.

  • Sets a specific SKU (Standard_DS1_v2) and deploys 2 VM instances (manual scaling).

  • Configures automatic upgrade mode, allowing VMs to update automatically when changes are applied.

• Admin Configuration:

  • Sets the administrator username and SSH key for secure access. The public key is read from the specified path for the VMSS.

• OS Disk and Image:

  • Configures the OS disk with Standard_LRS storage and sets caching to ReadWrite.

  • Uses the Red Hat Enterprise Linux (RHEL) image, specifying the publisher, offer, SKU, and version.

• Network Configuration:

  • Attaches each VM to the App subnet and associates it with an Internal Load Balancer for internal traffic handling.

  • Associates the NSG (Network Security Group) for controlled inbound and outbound traffic to the application layer.

• Custom Data:

  • Uses the custom_data field to pass initialization scripts to each VM instance, which can be used to configure applications or services during the VM setup.

Auto-Scaling Profile

Configuring an autoscaling profile is essential for managing load and ensuring optimal performance in Virtual Machine Scale Sets (VMSS). The following Terraform code creates an autoscaling profile for VMSS, targeting both CPU and memory usage as scaling triggers

resource "azurerm_monitor_autoscale_setting" "app_vmss_autoscale" {
  name                = "${local.resource_name_prefix}-app-vmss-autoscale-profiles"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  target_resource_id  = azurerm_linux_virtual_machine_scale_set.app_vmss.id

  profile {
    name = "default"
    # Capacity Block
    capacity {
      default = 2
      minimum = 2
      maximum = 6
    }
    ###########  START: Percentage CPU Metric Rules  ###########    
    ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }
      metric_trigger {
        metric_name        = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.app_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 75
      }
    }

    ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }
      metric_trigger {
        metric_name        = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.app_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 25
      }
    }
    ###########  END: Percentage CPU Metric Rules   ###########    

    ###########  START: Available Memory Bytes Metric Rules  ###########    
    ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.app_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 1073741824 # Increase 1 VM when Memory In Bytes is less than 1GB
      }
    }

    ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.app_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 2147483648 # Decrease 1 VM when Memory In Bytes is Greater than 2GB
      }
    }
    ###########  END: Available Memory Bytes Metric Rules  ###########  
  } # End of Profile-1
}

• Resource Definition:

  • Resource: azurerm_monitor_autoscale_setting

  • Name: Configured with a prefix for easy identification as app-vmss-autoscale-profiles

  • Target Resource: Associates with the VMSS for the application layer using target_resource_id

• Profile Specifications:

  • Capacity Block:

    • Default: 2 instances

    • Minimum: 2 instances

    • Maximum: 6 instances (allowing the VMSS to scale between these limits)

• Metric-Based Scaling Rules:

  • CPU Usage (Percentage CPU):

    • Scale-Out: Adds one instance when the average CPU exceeds 75% over a 5-minute window.

    • Scale-In: Removes one instance when the average CPU falls below 25% over a 5-minute window.

  • Memory Usage (Available Memory Bytes):

    • Scale-Out: Adds one instance when available memory is below 1GB.

    • Scale-In: Removes one instance when available memory exceeds 2GB.

Provision of Internal Load Balancer

This section covers the setup of an internal load balancer for the Application Virtual Machine Scale Set (App VMSS). By routing traffic through the App Subnet and fronting it with a NAT gateway, this configuration enhances the security and management of internal network traffic.

resource "azurerm_lb" "app_internal_lb" {
  name                = "${local.resource_name_prefix}-app-internal-lb"
  location            = azurerm_resource_group.rg.location
  sku                 = "Standard"
  resource_group_name = azurerm_resource_group.rg.name
  frontend_ip_configuration {
    name                          = "app-lb-privateip-1"
    subnet_id                     = azurerm_subnet.app_subnet.id
    private_ip_address_allocation = "Static"
    private_ip_address            = "10.1.11.241"
    private_ip_address_version    = "IPv4"

  }

}
# Create backen pool
resource "azurerm_lb_backend_address_pool" "app_internal_lb_address_pool" {
  name            = "app-backend"
  loadbalancer_id = azurerm_lb.app_internal_lb.id

}
# Create LB Probe
resource "azurerm_lb_probe" "app_internal_lb_probe" {
  name            = "tcp-probe"
  protocol        = "Tcp"
  port            = 80
  loadbalancer_id = azurerm_lb.app_internal_lb.id

}
# Create LB Rule
resource "azurerm_lb_rule" "app_internal_lb_rule" {
  name                           = "app-app1-rule"
  protocol                       = "Tcp"
  backend_port                   = 80
  frontend_port                  = 80
  frontend_ip_configuration_name = azurerm_lb.app_internal_lb.frontend_ip_configuration[0].name
  backend_address_pool_ids       = azurerm_lb_backend_address_pool.app_internal_lb_address_pool.id
  probe_id                       = azurerm_lb_probe.app_internal_lb_probe.id
  loadbalancer_id                = azurerm_lb.app_internal_lb.id

}

Resource Breakdown:

1. Internal Load Balancer:

   • Resource: azurerm_lb

   • Configuration:

     • Name: Specifies a unique identifier with a custom prefix.

     • Frontend IP: Sets up a private static IP within the App Subnet for internal-only access.

2. Backend Pool:

   • Resource: azurerm_lb_backend_address_pool

   • Configuration:

     • Connects the App VMSS instances to the load balancer.

3. Health Probe:

   • Resource: azurerm_lb_probe

   • Configuration:

     • Protocol: TCP

     • Port: 80, enabling traffic health checks for connected instances.

4. Load Balancer Rule:

   • Resource: azurerm_lb_rule

   • Configuration:

     • Routes traffic on TCP port 80, forwarding it from the frontend IP to the backend pool with health checks provided by the probe.

Resource Verification on Azure Portal

Storage Account

The designated storage account has been successfully provisioned with a blob container that includes the app.conf file, which has been correctly uploaded as expected.

NAT Gateway

The NAT Gateway has been deployed and is now associated with the application subnet.

Additionally, the outbound IP configuration has been set up with the specified public IP, enabling external communication for resources within the App subnet.

APP VMSS

The App VMSS has been successfully deployed within the application subnet, as highlighted in the configuration.

A scaling policy has been applied to manage resources efficiently based on demand.

Custom networking for the App VMSS has also been configured to support secure inbound and outbound traffic, layered on top of the default Network Security Group (NSG) settings for the App subnet.

Load Balancers

An internal load balancer has been provisioned, with backend pools configured and associated for optimal load distribution.

The frontend IP has been sourced directly from the App subnet, ensuring seamless connectivity and traffic routing within the internal network.

We’ll explore the deployment of VMSS in a web-tier environment using Terraform, configuring both manual and autoscaling options to illustrate the flexibility and control VMSS brings to cloud applications.

Manual Scaling vs Auto-Scaling

• Manual Scaling: With manual scaling, you set a predefined instance count for the scale set. VMSS will then deploy that specific number of VMs, which is ideal for consistent, predictable workloads. This allows for precise resource planning and control over your deployment size.

• Autoscaling: In autoscaling, VMSS dynamically adjusts the number of VM instances based on specific metrics such as CPU utilization, memory usage, or custom metrics defined by the application. This enables you to optimize costs by only using the resources you need when demand is high, then automatically scaling down during low-demand periods.

Manual Scaling - VMSS

In this section, we’ll dive into manual scaling with Azure Virtual Machine Scale Set (VMSS), where you explicitly define the number of virtual machines (VMs) the scale set should deploy. Here, instead of provisioning individual Linux VMs for our web tier, we will create a VMSS configured to spin up two VMs.

Once the VMSS is deployed, it will be paired with an Azure Standard Load Balancer, which will direct incoming traffic to the backend pool associated with the VM instances. This setup ensures that traffic is evenly distributed across the VMs in the scale set, optimizing availability and reliability for web applications.

By defining the VM count in advance, we take full advantage of VMSS to manage scalability without the need to manage individual VM resources.

# Resource VMSS(Virtual machine scale sets)

resource "azurerm_linux_virtual_machine_scale_set" "web_vmss" {
  name     = "${local.resource_name_prefix}-web-vmss"
  admin_username = var.linux_admin_username
  computer_name_prefix = "vmss-web"
  location = azurerm_resource_group.rg.location
  sku = "Standard_DS1_v2"
  resource_group_name = azurerm_resource_group.rg.name

  instances = 2 # Manually defining the number of instances. Hence, it is called manual scaling

  upgrade_mode = "Automatic"  # VMs will be auto upgraded after associated with LB

  admin_ssh_key {
    username   = var.linux_admin_username
    public_key = file("${path.module}/ssh-keys/terraform-azure.pub")

  }
  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }
  source_image_reference {
    publisher = "RedHat"
    offer     = "RHEL"
    sku       = "83-gen2"
    version   = "latest"
  }
  network_interface {
    name = "vmss-nic"
    primary = true
    network_security_group_id = azurerm_network_security_group.web_vmss_nsg.id

    ip_configuration {
      name = "internal"
      primary = true
      subnet_id = azurerm_subnet.web_subnet.id
      # here the VMSS is now associated with LoadBalancer.
      load_balancer_backend_address_pool_ids = [azurerm_lb_backend_address_pool.lb_backend_address_pool.id]
    }

  }
  custom_data = filebase64("${path.module}/app-script/webvm.sh") # One way of passing custom script


}

This Terraform configuration creates a Virtual Machine Scale Set (VMSS) on Azure for the web tier, with key settings for instance scaling, network configuration, and custom automation.

1. VM Scale Set Basics:

   • A VMSS named web_vmss is defined, set to manually scale to two instances. Each instance uses a Linux OS and a specified SKU (Standard_DS1_v2) for consistent performance.

2. Auto-Upgrade & OS Settings:

   • The VMSS is configured to automatically upgrade instances, so any changes apply without manual intervention.

   • The OS is Red Hat Enterprise Linux (RHEL), with settings for disk caching and storage.

3. Network Configuration:

   • Each VM in the scale set connects to an existing subnet and is secured by a Network Security Group (NSG).

   • It also associates with an Azure Load Balancer backend pool, distributing traffic across VMs for better reliability and load management.

4. Custom Initialization Script:

   • A custom script (webvm.sh) initializes each VM instance with the required settings or software. The script is encoded in base64 for direct use in Terraform.

This setup creates a flexible and scalable backend for applications, allowing easy scaling, security, and traffic distribution across multiple instances in the web tier.

Resource Verification on Azure Portal post Apply

After applying the Terraform configuration, the Virtual Machine Scale Set (VMSS) reached the desired state, with two virtual machines successfully up and running.

As discussed, manual scaling has been implemented here, where the number of instances is explicitly defined to maintain consistency and control over resources.

Additionally, the VMSS is linked to the Azure Load Balancer, effectively distributing traffic between the instances. This setup enables access to the VMs through the Load Balancer's public IP, enhancing availability and reliability for end-users.

Finally, here is the content served by the two VMs managed by the VMSS, showcasing the setup's functionality and the seamless distribution across instances.

Auto-Scaling in Azure VMSS

Auto scaling in Azure is a feature that dynamically adjusts the number of resources—such as virtual machines (VMs) in a scale set or App Service instances—based on real-time demand and pre-defined criteria. Auto scaling helps optimize costs and ensures application availability by automatically scaling out to handle high loads or scaling in to reduce resources during low demand periods.

Auto-scaling is a stand-alone resource in Azure that can be attached to VMSS or even to app services and other resources. Here in this section, we’ll implement Auto-Scaling with VMSS

Auto-Scaling Profiles

There are 3 auto-scaling profiles available in Azure

• Auto-Scaling Default Profile

  This profile allows you to configure automatic scaling based on performance metrics. It adjusts the number of instances in response to real-time resource usage, ensuring that your application can handle fluctuating traffic without manual intervention.

• Auto-Scaling Recurrence Profile

  With this profile, you can set up a schedule for scaling your resources at specific times. This is particularly useful for applications that experience predictable traffic patterns, allowing you to allocate resources efficiently during peak hours and scale down during off-peak times.

• Auto-Scaling Fixed Profile

  This profile enables you to define a static number of instances for your application. It provides a consistent level of resources, making it ideal for workloads that require steady performance without the need for scaling based on demand.

Auto-Scaling Rules Metrics

Below are the metric rules we can create while setting up profiles in Autoscaling.

1. Percentage CPU Metric Rules
    1. Scale-Up Rule: Increase VMs by 1 when CPU usage is greater than 75%
    2. Scale-In Rule: Decrease VMs by 1when CPU usage is lower than 25%
2. Available Memory Bytes Metric Rules
    1. Scale-Up Rule: Increase VMs by 1 when Available Memory Bytes is less than 1GB in bytes
    2. Scale-In Rule: Decrease VMs by 1 when Available Memory Bytes is greater than 2GB in bytes
3. LB SYN Count Metric Rules (JUST FOR firing Scale-Up and Scale-In Events for Testing and also knowing in addition to current VMSS Resource, we can also create Autoscaling rules for VMSS based on other Resource usage like Load Balancer)
    1. Scale-Up Rule: Increase VMs by 1 when LB SYN Count is greater than 10 Connections (Average)
    2. Scale-Up Rule: Decrease VMs by 1 when LB SYN Count is less than 10 Connections (Average)

Auto-Scaling Profile Creation

By leveraging the azurerm_monitor_autoscale_setting resource, we will establish a flexible scaling strategy based on several key metrics. Here we will create all 3 types of profiles as discussed above one by one.

Profile-1: Default Profile

• Introduction to VMSS Auto-Scaling: An overview of Azure auto-scaling as a means to dynamically adjust the number of virtual machines (VMs) based on real-time resource utilization, traffic patterns, and specific performance thresholds.

• Creating the Auto-Scale Resource:

  • Notification Block: Setting up automatic email notifications for subscription administrators and co-administrators to keep them informed of scale actions.

• Defining the Default Scaling Profile:

  • Manual Scaling Capacity: Initializing with a default of 2 instances and setting bounds for minimum (2) and maximum (6) instances, providing flexibility as demand changes.

  • CPU Usage-Based Scaling Rules: Configuring scale-in and scale-out actions based on CPU utilization:

    • Scale-out is triggered if CPU usage exceeds 75% (adds 1 instance).

    • Scale-in occurs when CPU usage drops below 25% (removes 1 instance).

• Memory Availability-Based Scaling Rules:

  • Scale-out adds an instance if available memory is under 1GB.

  • Scale-in removes an instance when available memory exceeds 2GB.

• Load Balancer SYN Count Rules:

  • Testing scale actions by monitoring SYN requests to the Load Balancer.

  • Scaling actions are triggered based on incoming requests, demonstrating how demand-based metrics can trigger VMSS scaling.

resource "azurerm_monitor_autoscale_setting" "web_vmss_autoscale" {
    name = "${local.resource_name_prefix}-web-vmss-autoscale-profiles"
    resource_group_name = azurerm_resource_group.rg.name
    location = azurerm_resource_group.rg.location
    target_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id

    #### Notification Block#####
    notification {
      email {
        send_to_subscription_administrator = true
        send_to_subscription_co_administrator = true

      }
    }
    #### Profile-1( Default Profile Block ) #####
    profile {
      name = "Default Profile"
      capacity {
        default = 2
        minimum = 2
        maximum = 6
      }

    ### Percentage CPU Metric Rule Begins #####
    ### Scale-Out Rule  ####
    rule {
    scale_action {
        direction = "Increase" # Scale-out means always increase
        type = "ChangeCount"
        value = 1
        cooldown = "PT5M"
    }
    metric_trigger {
        metric_name = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace = "microsoft.compute/virtualmachinescalesets"
        time_grain = "PT1M"
        statistic = "Average"
        time_window = "PT5M"
        time_aggregation = "Average"
        operator = "GreaterThan"
        threshold = 75
        }
    }

    ### Scale-In Rule ####
    rule {
      scale_action {
        direction = "Decrease"
        type = "ChangeCount"
        value = 1
        cooldown = "PT5M"
      }
      metric_trigger {
        metric_name = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace = "microsoft.compute/virtualmachinescalesets"
        time_grain = "PT1M"
        statistic = "Average"
        time_window = "PT5M"
        time_aggregation = "Average"
        operator = "LessThan"
        threshold = 25
      }
    }

    ### END OF Percentage CPU Metric Rule ###

  ###########  START: Available Memory Bytes Metric Rules  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }            
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 1073741824 # Increase 1 VM when Memory In Bytes is less than 1GB
      }
    }
    ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }        
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 2147483648 # Decrease 1 VM when Memory In Bytes is Greater than 2GB
      }
    }
    ###########  END: Available Memory Bytes Metric Rules  ###########  

  ###########  START: LB SYN Count Metric Rules - Just to Test scale-in, scale-out  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }      
      metric_trigger {
        metric_name        = "SYNCount"
        metric_resource_id = azurerm_lb.web_lb.id 
        metric_namespace   = "Microsoft.Network/loadBalancers"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 10 # 10 requests to an LB
      }
    }
    ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }      
      metric_trigger {
        metric_name        = "SYNCount"
        metric_resource_id = azurerm_lb.web_lb.id
        metric_namespace   = "Microsoft.Network/loadBalancers"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 10
      }
    }
    ###########  END: LB SYN Count Metric Rules  ###########    

    }   # End of Default Profile Block -1


}

Verifying Profile-1 on Azure Portal

Now after applying, the custom auto-scale has been chosen

The respective rules have been added to the profile as follows

Profile-2: Recurrence Profile

A recurrence profile for auto-scaling with settings specific to weekdays (Monday to Friday) and CPU, memory, and load balancer metrics for scaling actions.

  ##### Profile-2: Recurrence Profile - Week Days
  profile {
    name = "profile-2-weekdays"
  # Capacity Block     
    capacity {
      default = 4
      minimum = 4
      maximum = 20
    }
  # Recurrence Block for Week Days (5 days)
    recurrence {
      timezone = "India Standard Time"
      days = ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]
      hours = [0]
      minutes = [0]      
    }    
###########  START: Percentage CPU Metric Rules  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }            
      metric_trigger {
        metric_name        = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 75
      }
    }

  ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }        
      metric_trigger {
        metric_name        = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 25
      }
    }
###########  END: Percentage CPU Metric Rules   ###########    

###########  START: Available Memory Bytes Metric Rules  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }            
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 1073741824 # Increase 1 VM when Memory In Bytes is less than 1GB
      }
    }

  ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }        
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 2147483648 # Decrease 1 VM when Memory In Bytes is Greater than 2GB
      }
    }
###########  END: Available Memory Bytes Metric Rules  ###########  


###########  START: LB SYN Count Metric Rules - Just to Test scale-in, scale-out  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }      
      metric_trigger {
        metric_name        = "SYNCount"
        metric_resource_id = azurerm_lb.web_lb.id 
        metric_namespace   = "Microsoft.Network/loadBalancers"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 10 # 10 requests to an LB
      }
    }
  ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }      
      metric_trigger {
        metric_name        = "SYNCount"
        metric_resource_id = azurerm_lb.web_lb.id
        metric_namespace   = "Microsoft.Network/loadBalancers"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 10
      }
    }
###########  END: LB SYN Count Metric Rules  ###########    
  } 
  ##### End of Profile-2

1. Profile-2 Overview:

   • Name: Profile-2 is designated as the "profile-2-weekdays."

   • Capacity Constraints: Configures the scale set to maintain a minimum of 4 VMs, a maximum of 20, and a default of 4 VMs, adjusting dynamically within these boundaries.

2. Recurrence Block:

   • Sets the auto-scaling action to apply from Monday through Friday at 00:00 hours in India Standard Time.

   • Ensures scaling actions only trigger during specified weekday hours, optimizing resource allocation based on anticipated load patterns.

3. Scaling Rules for CPU Usage (Percentage CPU Metric Rules):

   • Scale-Out Rule: Increases the instance count by 1 if average CPU usage exceeds 75%.

   • Scale-In Rule: Decreases the instance count by 1 if average CPU usage falls below 25%.

   • Each rule has a 5-minute cooldown period, allowing sufficient time for load adjustment before further scaling.

4. Scaling Rules for Memory Availability (Available Memory Bytes Metric Rules):

   • Scale-Out Rule: Triggers scaling out by adding 1 instance when available memory falls below 1GB.

   • Scale-In Rule: Triggers scaling in by removing 1 instance when available memory exceeds 2GB.

   • This approach ensures resource availability by adding VMs as memory demand increases and reducing VMs when memory is ample.

5. SYN Count-Based Scaling Rules (Load Balancer Metric Rules):

   • Monitors load balancer SYN request count for scale adjustments, beneficial for high-traffic scenarios.

   • Scale-Out Rule: Adds 1 VM if the SYN request count exceeds 10.

   • Scale-In Rule: Removes 1 VM if the SYN request count falls below 10, stabilizing resource usage during traffic fluctuations.

Each section within Profile 2 enables adaptive scaling based on real-time traffic and workload patterns, enhancing availability, optimizing costs, and aligning resource usage with demand.

Verifying Profile-2 on Azure Portal

Now post applying the Recurrence profile i.e. profile 2 is now in action where all the rules have been added respectively

While Profile-2 is in effect, it takes precedence, meaning that the Default Profile will not execute concurrently. This ensures that scaling adjustments occur according to the current profile’s configuration, based on weekday and demand metrics, optimizing resource alignment with operational needs.

Profile-3: Recurrence Profile (Weekend)

This profile manages auto-scaling configurations specifically for weekends, ensuring optimal resource allocation during lower usage periods with adjustments triggered by CPU, memory, and load balancer metrics.

  profile {
    name = "profile-3-weekends"
  # Capacity Block     
    capacity {
      default = 3
      minimum = 3
      maximum = 6
    }
  # Recurrence Block for Weekends (2 days)
    recurrence {
      timezone = "India Standard Time"
      days = ["Saturday", "Sunday"]
      hours = [0]
      minutes = [0]      
    }    
###########  START: Percentage CPU Metric Rules  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }            
      metric_trigger {
        metric_name        = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 75
      }
    }

  ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }        
      metric_trigger {
        metric_name        = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 25
      }
    }
###########  END: Percentage CPU Metric Rules   ###########    

###########  START: Available Memory Bytes Metric Rules  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }            
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 1073741824 # Increase 1 VM when Memory In Bytes is less than 1GB
      }
    }

  ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }        
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 2147483648 # Decrease 1 VM when Memory In Bytes is Greater than 2GB
      }
    }
###########  END: Available Memory Bytes Metric Rules  ###########  

###########  START: LB SYN Count Metric Rules - Just to Test scale-in, scale-out  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }      
      metric_trigger {
        metric_name        = "SYNCount"
        metric_resource_id = azurerm_lb.lb_web.id 
        metric_namespace   = "Microsoft.Network/loadBalancers"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 10 # 10 requests to an LB
      }
    }
  ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }      
      metric_trigger {
        metric_name        = "SYNCount"
        metric_resource_id = azurerm_lb.lb_web.id
        metric_namespace   = "Microsoft.Network/loadBalancers"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 10
      }
    }
###########  END: LB SYN Count Metric Rules  ###########    
} # End of Profile-3

1. Capacity Settings

   • Default: 3 instances

   • Minimum: 3 instances

   • Maximum: 6 instances

2. Recurrence Settings

   • Days: Saturday and Sunday

   • Time: 00:00 hours (India Standard Time)

3. Scaling Rules

   • CPU Utilization (Percentage CPU)

     • Scale-Out: Increase by 1 instance when average CPU > 75% over a 5-minute period.

     • Scale-In: Decrease by 1 instance when average CPU < 25% over a 5-minute period.

   • Memory Usage (Available Memory Bytes)

     • Scale-Out: Increase by 1 instance when available memory is < 1GB.

     • Scale-In: Decrease by 1 instance when available memory > 2GB.

   • Load Balancer Requests (SYNCount)

     • Scale-Out: Increase by 1 instance when SYN requests exceed 10 over a 5-minute period.

     • Scale-In: Decrease by 1 instance when SYN requests fall below 10 over a 5-minute period.

This weekend-specific profile ensures that resources are efficiently managed with minimal instances during off-peak times, responding dynamically to weekend traffic demands through auto-scaling adjustments.

Verifying Profile-3 on Azure Portal

The Weekend Profile (Profile-3) has now been successfully applied, configured with specific scaling rules to operate exclusively on Saturdays and Sundays. This ensures that the auto-scaling behavior aligns with weekend traffic patterns, repeating every Saturday and Sunday as specified in the recurrence settings.

With Profile-3 in action, scaling adjustments will adhere to the defined metrics, keeping resources optimized during weekend periods.

Profile-4: Fixed Profile (Specific Dates)

It is a targeted scaling profile that activates only on a specified date. It provides flexibility for scaling to meet anticipated needs for a specific day or event.

# Profile-4: Fixed Profile for a Specific Day
  profile {
    name = "profile-4-fixed-profile"
  # Capacity Block     
    capacity {
      default = 5
      minimum = 5
      maximum = 20
    }
  # Fixed Block for a specific day
    fixed_date {
      timezone = "India Standard Time"
      start    = "2021-08-16T00:00:00Z"  # CHANGE TO THE DATE YOU ARE TESTING
      end      = "2021-08-16T23:59:59Z"  # CHANGE TO THE DATE YOU ARE TESTING
    }  
###########  START: Percentage CPU Metric Rules  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }            
      metric_trigger {
        metric_name        = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 75
      }
    }

  ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }        
      metric_trigger {
        metric_name        = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 25
      }
    }
###########  END: Percentage CPU Metric Rules   ###########    

###########  START: Available Memory Bytes Metric Rules  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }            
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 1073741824 # Increase 1 VM when Memory In Bytes is less than 1GB
      }
    }

  ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }        
      metric_trigger {
        metric_name        = "Available Memory Bytes"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.web_vmss.id
        metric_namespace   = "microsoft.compute/virtualmachinescalesets"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 2147483648 # Decrease 1 VM when Memory In Bytes is Greater than 2GB
      }
    }
###########  END: Available Memory Bytes Metric Rules  ###########  


###########  START: LB SYN Count Metric Rules - Just to Test scale-in, scale-out  ###########    
  ## Scale-Out 
    rule {
      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }      
      metric_trigger {
        metric_name        = "SYNCount"
        metric_resource_id = azurerm_lb.web_lb.id 
        metric_namespace   = "Microsoft.Network/loadBalancers"        
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 10 # 10 requests to an LB
      }
    }
  ## Scale-In 
    rule {
      scale_action {
        direction = "Decrease"
        type      = "ChangeCount"
        value     = 1
        cooldown  = "PT5M"
      }      
      metric_trigger {
        metric_name        = "SYNCount"
        metric_resource_id = azurerm_lb.web_lb.id
        metric_namespace   = "Microsoft.Network/loadBalancers"                
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "LessThan"
        threshold          = 10
      }
    }
###########  END: LB SYN Count Metric Rules  ###########    
} # End of Profile-4