Forem: Piyush Bagani

An overview of AWS ECS

Piyush Bagani — Thu, 03 Apr 2025 02:52:56 +0000

AWS Elastic Container Service (ECS)

Overview

AWS Elastic Container Service (ECS) is a fully managed container orchestration service that enables you to run, manage, and scale containerized applications. ECS supports both AWS Fargate (serverless compute) and EC2 instances for hosting containers.

Features

Fully Managed: No need to set up and manage Kubernetes.
Flexible Compute: Choose between AWS Fargate (serverless) or EC2 instances.
Deep AWS Integration: Works with IAM, CloudWatch, ALB, Route 53, and more.
Auto Scaling & Load Balancing: Adjusts resources dynamically based on demand.
Cost-Effective: Pay for only the resources used.

Architecture Components

Cluster - Logical grouping of ECS instances or Fargate tasks.
Task Definition - Blueprint for running containers, specifying CPU, memory, and networking.
Task - Running instance of a task definition.
Service - Maintains the desired number of tasks and ensures high availability.
Container Agent - Manages communication between ECS and EC2 instances.
Elastic Load Balancer (ELB) - Distributes traffic across running tasks.

Quick Deployment Guide (AWS Fargate)

Step 1: Create an ECS Cluster

Open AWS ECS Console.
Click Clusters > Create Cluster.
Choose Networking only (AWS Fargate).
Provide a cluster name and create it.

Step 2: Define a Task

Navigate to Task Definitions.
Click Create new task definition.
Select Fargate as the launch type.
Configure container settings:
- Set container name.
- Use a Docker image (e.g., nginx:latest).
- Define port mapping (e.g., 80:80).
Click Create.

Step 3: Deploy as a Service

Go to ECS > Services.
Click Create Service.
Choose Fargate as the launch type.
Select the cluster and task definition.
Configure networking & load balancing.
Click Deploy Service.

Step 4: Access Your Application

Find the Public IP/DNS from the ECS Console.
Open it in a browser to see the deployed application.

Monitoring & Scaling

Logging: Use CloudWatch Logs for application logs.
Auto Scaling: Configure ECS Service Auto Scaling based on CPU/memory usage.
Metrics: Monitor performance with CloudWatch Metrics.

Conclusion

AWS ECS simplifies containerized application deployment with minimal management. You can build scalable and cost-efficient solutions by leveraging ECS with Fargate or EC2.

Superfile: A Comprehensive Guide to Streamlined File Management in the Terminal

Piyush Bagani — Wed, 04 Dec 2024 14:09:10 +0000

In the fast-paced world of development, a robust file manager can significantly enhance productivity. Superfile is a feature-rich, terminal-based file manager designed to simplify file operations while leveraging the power of command-line tools.

Why Choose Superfile?

Superfile stands out due to its:

Multi-Panel Interface: Work with multiple directories simultaneously, making navigation intuitive.
Keyboard Shortcuts: Execute tasks like copying, moving, and renaming files with speed.
File Previews: View metadata and content inline without external commands.
Batch Operations: Perform actions on multiple files or folders at once.
Integration: Seamlessly integrates with editors, compression tools, and custom scripts.

Getting Started with Superfile

Installation: Download and install Superfile from its official site. Follow platform-specific installation steps to get started.
Launching Superfile: Run spf in your terminal to open the multi-panel interface.
Navigation:
- Use arrow keys to explore directories.
- Toggle between panels to compare or move files.
Operations:
- Press c to copy, m to move, and d to delete files.
- Use Enter to preview file content or metadata.

Advanced Features

Bulk Management: Select multiple files with Space and perform operations.
Compression and Extraction: Easily handle .zip and .tar files using built-in commands.
Custom Workflows: Configure Superfile to integrate with your favorite tools or scripts for specialized tasks.

Real-World Use Cases

Developers: Manage project directories, preview logs, or edit configuration files directly from the terminal.
Sysadmins: Handle server files efficiently, minimizing context switching.
Data Analysts: Organize datasets and quickly navigate through massive directory structures.

Conclusion

Superfile is more than a file manager—it’s a productivity enhancer for anyone who thrives in the terminal. Its sleek design and powerful features make it an indispensable tool for developers, sysadmins, and power users alike.

Ready to transform your file management workflow? Dive into the Superfile tutorial and unleash its full potential!

Automate Your Scripts with Systemd Services: Benefits and Step-by-Step Guide

Piyush Bagani — Sat, 02 Nov 2024 04:29:02 +0000

Introduction:

Scripts are a core part of many IT and DevOps workflows, performing everything from monitoring tasks to triggering automated responses. However, running these scripts manually or relying on cron jobs can introduce reliability issues. One powerful solution to streamline script execution is to run them as systemd services. This blog post dives into the benefits of using systemd for your scripts and provides a step-by-step guide to setting it up.

Why Run Scripts as Systemd Services?

Traditionally, scripts are often executed manually or scheduled via cron jobs, but this approach has some limitations:

Reliability Issues: If a script crashes or fails, cron will not restart it.
Environment Inconsistencies: Cron jobs and manual runs can vary in terms of environment variables and user permissions, leading to unpredictable results.
Limited Monitoring: Without a mechanism to check if a script is running successfully, monitoring and debugging can be a challenge.
Complexity in Control: Managing script processes (like stopping, restarting, or checking status) is not straightforward.

Systemd, a service manager for Linux, provides a robust alternative for managing scripts as services. With systemd, your scripts can run in a controlled, stable environment, making management and troubleshooting significantly easier.

Key Benefits of Running Scripts as Systemd Services

Using systemd brings several benefits:

Automatic Restarts: Systemd can automatically restart a service if it fails, ensuring high availability.
Environment Control: You can define environment variables, working directories, and permissions directly in the service file, providing a consistent runtime environment.
Enhanced Monitoring: Systemd logs outputs to the journal, so you can easily view logs and status updates.
Streamlined Control: You can start, stop, enable, disable, or check the status of your script with a single command.

Step-by-Step Guide: Configuring Your Script as a Systemd Service

Follow these steps to set up your script as a systemd service:

Step 1: Create Your Script
Ensure that your script is ready and accessible. Let’s assume your script is located at /usr/local/bin/my-script.sh. This script could be anything from a data processor to a system monitor.

Step 2: Create the Systemd Service File
Open a terminal, and create a new service file in the /etc/systemd/system/ directory:

sudo nano /etc/systemd/system/my-script.service

Add the following configuration to define the service:

[Unit]
Description=My Custom Script
After=network.target

Description: A brief summary of the service.
After=network.target: Ensures that the network is available before the script starts, helpful if the script requires network access.

Step 3: Configure the Service Parameters

The [Service] section is where you define how the script runs, its environment, and restart behavior.

[Service]
ExecStart=/usr/local/bin/my-script.sh
Restart=on-failure
Environment="API_KEY=12345"
WorkingDirectory=/home/myuser/scripts
User=myuser

ExecStart: This line specifies the command to start your script. Use the absolute path to avoid path-related issues.
Restart: Set this to on-failure to restart the service if it fails. Other options include always (restarts regardless of the exit code) or no (never restarts).
Environment: Define any environment variables the script requires. You can add multiple variables here or point to an environment file with EnvironmentFile=/path/to/env.
WorkingDirectory: Sets the directory in which the service will run. This is useful if your script depends on relative paths or requires specific permissions.
User: Specifies the user under which the service should run, which improves security by restricting unnecessary permissions.

Step 4: Define When to Start the Service

In the [Install] section, specify the desired target. To ensure that the service starts on boot in a multi-user mode, use the multi-user.target.

[Install]
WantedBy=multi-user.target

What Is multi-user.target?
The multi-user.target is one of several targets in systemd, each representing a different state or mode of the operating system. Here’s a quick overview of what multi-user.target represents and how it fits in:

multi-user.target: This target is similar to "runlevel 3" in traditional Linux systems, a non-GUI mode where the system is fully operational and allows multiple users to connect. It’s typically used on servers and systems without a graphical user interface (GUI).

By setting WantedBy=multi-user.target, you’re telling systemd to start your service during the system’s multi-user mode, which is active on most Linux systems running in a non-GUI environment.
This setup is ideal for server processes, background scripts, and other tasks that need to be available as soon as the system is ready for normal operation but don’t require a graphical environment.

Step 5: Save and Close the File
Save the file (in nano, press Ctrl+O, then Enter to save, and Ctrl+X to exit).

Step 6: Reload Daemon, Enable and Start the Service

sudo systemctl daemon-reload
sudo systemctl enable my-script.service
sudo systemctl start my-script.service

Step 7: Managing and Troubleshooting Your Systemd Service

Once your service is running, systemd makes it easy to manage:

Check Service Status:

sudo systemctl status my-script.service

View Logs:

journalctl -u my-script

Stop or Restart the Service:

sudo systemctl stop my-script
sudo systemctl restart my-script

Conclusion

Running a script as a systemd service is a simple but powerful way to automate tasks with reliability and control. By leveraging systemd’s capabilities, you can ensure scripts run consistently in a controlled environment, automatically restart on failure, and provide clear, accessible logs. Whether you’re managing monitoring scripts, scheduled tasks, or any other automated workflows, systemd offers a robust solution that enhances script reliability and makes managing Linux-based systems much easier.

Give it a try, and see how it simplifies your workflow!

Happy scripting!

Building a Resilient AWS Infrastructure with Terraform

Piyush Bagani — Tue, 16 Jul 2024 12:31:11 +0000

Building resilient and scalable infrastructure is critical in today's era, where downtime or poor performance can directly impact customer satisfaction and business revenue. This blog explores the setup of a high availability architecture within Amazon Web Services (AWS) using Terraform, an Infrastructure as Code (IaC) tool. By the end of this guide, you'll understand how to use Terraform to create a fault-tolerant architecture that supports robust, scalable web applications.

Why Use Terraform?

Terraform is a powerful tool for building, changing, and versioning infrastructure safely and efficiently. It supports numerous service providers, including AWS, and allows users to define infrastructure through a high-level configuration language. Terraform shines in multi-cloud and complex system setups, making it an ideal choice for managing sophisticated cloud environments.

Project Setup Overview

We aim to deploy a VPC in AWS with all the necessary components to support a fault-tolerant, scalable web server. This includes:

A VPC with separate public and private subnets across multiple Availability Zones.
NAT Gateways to provide internet access to instances in private subnets. To improve resiliency NAT gateways(to be deployed in public subnets) lie in both AZs.
An Application Load Balancer to distribute incoming traffic evenly.
Auto Scaling Groups to handle dynamic scaling based on traffic.
For additional security, instances are in private subnets.

The full architecture diagram is shown below:

Reference link: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html

NOTE: Here we will not provision the S3 gateway.

Prerequisites

Install Terraform
- Goto this link and install terraform for your operating system.
Access to an AWS account
- Sign Up for a Free tier AWS Account, most of the items we aim to create will come under the free tier.

So let's get started by provisioning the above-given infrastructure step by step.

Structure of terraform configuration

aws-vpc-subnet-architecture/
├── aws_alb.tf
├── aws_asg.tf
├── aws_networking.tf
├── outputs.tf
├── providers.tf
├── setup.sh
├── terraform.tfvars
└── variables.tf

We will discuss the purpose of each file one by one.

Provisioning the Networking Components:

Here's the code that provisions all the networking components:
aws_networking.tf

# Creating the VPC
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr # value defined in terraform.tfvars
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = merge(
    var.common_tags,
    {
      Name = var.vpc_name
    }
  )
}

# Creating the Internet Gateway
resource "aws_internet_gateway" "internet_gateway" {
  vpc_id = aws_vpc.main.id

  tags = merge(
    var.common_tags,
    {
      Name = "Main Internet Gateway"
    }
  )
}

# Creating the Public Subnets
resource "aws_subnet" "public_subnet" {
  count                   = length(var.public_subnet_cidrs)
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidrs[count.index]
  availability_zone       = var.availability_zones[count.index]
  map_public_ip_on_launch = true

  tags = merge(
    var.common_tags,
    {
      Name = "Public Subnet ${count.index + 1}"
    }
  )
}

# Creating the Private Subnets
resource "aws_subnet" "private_subnet" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.common_tags,
    {
      Name = "Private Subnet ${count.index + 1}"
    }
  )
}

# Creating the NAT Gateways with Elastic IPs
resource "aws_eip" "nat_eip" {
  count  = length(var.availability_zones)
  domain = "vpc"

  tags = merge(
    var.common_tags,
    {
      Name = "NAT EIP ${count.index + 1}"
    }
  )
}

resource "aws_nat_gateway" "nat_gateway" {
  count         = length(aws_subnet.public_subnet)
  allocation_id = aws_eip.nat_eip[count.index].id
  subnet_id     = aws_subnet.public_subnet[count.index].id

  tags = merge(
    var.common_tags,
    {
      Name = "NAT Gateway ${count.index + 1}"
    }
  )
}

# Creating the Route Table for Public Subnet
resource "aws_route_table" "public_route_table" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.internet_gateway.id
  }

  tags = merge(
    var.common_tags,
    {
      Name = "Public Route Table"
    }
  )
}

resource "aws_route_table_association" "public_route_table_association" {
  count          = length(aws_subnet.public_subnet)
  subnet_id      = aws_subnet.public_subnet[count.index].id
  route_table_id = aws_route_table.public_route_table.id
}

# Creating the Route Table for Private Subnet
resource "aws_route_table" "private_route_table" {
  count  = length(aws_subnet.private_subnet)
  vpc_id = aws_vpc.main.id

  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat_gateway[count.index].id
  }

  tags = merge(
    var.common_tags,
    {
      Name = "Private Route Table ${count.index + 1}"
    }
  )
}

resource "aws_route_table_association" "private_route_table_association" {
  count          = length(aws_subnet.private_subnet)
  subnet_id      = aws_subnet.private_subnet[count.index].id
  route_table_id = aws_route_table.private_route_table[count.index].id
}

This Terraform script is designed to systematically construct a robust network infrastructure within AWS.

At its core, the script initiates the creation of a Virtual Private Cloud (VPC), with a custom IP address range (CIDR block). The script further enhances network functionality by setting up an Internet Gateway, which is crucial for enabling communication between the VPC and the Internet, thereby facilitating public Internet access for the resources within public subnets.

Moreover, the code proceeds to systematically deploy both public and private subnets. Each Public subnet is configured to have NAT Gateways and Load Balancer which is ideal for front-end interfaces and services that need to interact with external clients. Conversely, private subnets are used for backend systems that require enhanced security by isolating them from direct internet access, thus they rely on NAT Gateways for external connections. NAT Gateways, strategically placed in each public subnet and equipped with Elastic IPs, ensure that instances in private subnets can reach the internet for necessary updates and downloads while remaining hidden from direct inbound internet traffic.

The script also creates route tables with predefined routes to manage the traffic flow: public route tables direct traffic to the internet gateway, allowing resources within public subnets to communicate with the internet, whereas private route tables route internal traffic through the NAT Gateways, safeguarding the private resources.

Finally, the script sets up associations between subnets and their respective route tables, ensuring that each subnet adheres to the correct routing policies for its intended use, whether for exposure to the public internet or protected internal operations.

Provisioning the Auto-Scaling Group and Launch Template:

aws_asg.tf: This file contains the main configuration for infrastructure like ASG and the launch template.

#  Creating Launch Template
resource "aws_launch_template" "app_lt" {
  name          = "app-launch-template"
  image_id      = var.ami_id
  instance_type = var.instance_type
  user_data     = base64encode(file("${path.module}/setup.sh")) # Setup script for web server

  vpc_security_group_ids = [aws_security_group.instance_sg.id]

  tag_specifications {
    resource_type = "instance"
    tags = merge(
      var.common_tags,
      {
        Name = "Instance Template"
      }
    )
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_security_group" "instance_sg" {
  name        = "instance-security-group"
  description = "Security group for instances"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb_sg.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = merge(
    var.common_tags,
    {
      Name = "Instance Security Group"
    }
  )
}

# Creating Auto Scaling Group
resource "aws_autoscaling_group" "app_asg" {

  launch_template {
    id      = aws_launch_template.app_lt.id
    version = "$Latest"
  }

  min_size            = 1
  max_size            = 4
  desired_capacity    = 2
  vpc_zone_identifier = aws_subnet.private_subnet.*.id

  tag {
    key                 = "Name"
    value               = "app-instance-${formatdate("YYYYMMDDHHmmss", timestamp())}"
    propagate_at_launch = true
  }
}

This section of the Terraform script orchestrates the automated deployment and management of EC2 instances within an AWS environment, focusing on scalability, security, and configuration efficiency. It involves setting up a Launch Template, a Security Group, and an Auto Scaling Group.

The Launch Template acts as a blueprint for the instances, detailing the Amazon Machine Image (AMI), instance type, and user data, which includes a script for initial setup tasks such as configuring web servers. This template ensures that all instances are uniformly configured as per the defined specifications and is accompanied by a security group that functions as a virtual firewall to regulate inbound and outbound traffic for the instances. It allows inbound HTTP traffic on port 80 from associated load balancers, facilitating access to web services hosted on the instances, while permitting all outbound traffic to ensure seamless external connectivity for updates and API interactions.

The Auto Scaling Group is a critical component that dynamically adjusts the number of instances based on demand. It utilizes the launch template for creating new instances, ensuring they adhere to the predefined configuration. The group is configured to operate within a range of instance counts, automatically scaling up or down between the minimum and maximum limits based on actual load, thus ensuring cost efficiency and resource availability.

Moreover, each instance is tagged with a unique timestamp at creation, enhancing manageability within the AWS ecosystem.

Provisioning the Application Load Balancer:

aws_alb.tf: This file contains the main configuration that helps to deploy the application load balancer.

#  Creating Application Load Balancer (ALB)
resource "aws_lb" "app_lb" {
  name               = "aws-app-prod-lb"
  internal           = false
  load_balancer_type = "application"
  subnets            = aws_subnet.public_subnet.*.id

  security_groups = [aws_security_group.alb_sg.id]

  tags = merge(
    var.common_tags,
    {
      Name = "Application Load Balancer"
    }
  )
}

#  Creating a Security Group for the Load Balancer
resource "aws_security_group" "alb_sg" {
  name        = "alb-security-group"
  description = "Allow web traffic"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = merge(
    var.common_tags,
    {
      Name = "ALB Security Group"
    }
  )
}


#  Creating a Target Group for ALB
resource "aws_lb_target_group" "tg" {
  name     = "aws-target-group"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    enabled             = true
    interval            = 30
    path                = "/"
    protocol            = "HTTP"
    timeout             = 5
    healthy_threshold   = 3
    unhealthy_threshold = 3
  }

  tags = merge(
    var.common_tags,
    {
      Name = "Target Group"
    }
  )
}

# Attaching Target Group to ALB
resource "aws_lb_listener" "front_end" {
  load_balancer_arn = aws_lb.app_lb.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.tg.arn
  }
}

# Attaching Target Group to Auto Scaling Group
resource "aws_autoscaling_attachment" "asg_attachment" {
  autoscaling_group_name = aws_autoscaling_group.app_asg.id
  lb_target_group_arn    = aws_lb_target_group.tg.arn
}

This portion of the Terraform script sets up an Application Load Balancer (ALB), along with its dedicated security group and a target group, to efficiently manage and distribute incoming web traffic across multiple EC2 instances. The ALB is designed to be internet-facing, as indicated by the internal flag set to false, allowing it to handle inbound internet traffic. It operates on HTTP protocol across instances located in public subnets, ensuring that the application can serve requests directly from the internet.

Additionally, a target group is configured to facilitate health checks and manage traffic distribution among instances, ensuring only healthy instances receive traffic. This improves application availability and user experience by optimizing resource use, reducing response times, and increasing uptime. Integrating the target group with both the ALB and an Auto Scaling group allows the system to adjust to traffic changes, enhancing robustness and cost-efficiency dynamically. This setup creates a scalable, fault-tolerant architecture ideal for high-availability web services.

There are a few more important files, that contribute towards successful provisioning of this whole architecture.

outputs.tf: This file specifies the outputs of created resources.

# Output for VPC
output "vpc_id" {
  value       = aws_vpc.main.id
  description = "The ID of the VPC"
}

# Output for Public Subnets
output "public_subnet_ids" {
  value       = aws_subnet.public_subnet.*.id
  description = "The IDs of the public subnets"
}

# Output for NAT Gateways
output "nat_gateway_ids" {
  value       = aws_nat_gateway.nat_gateway.*.id
  description = "The IDs of the NAT gateways"
}

# Output for Private Subnets
output "private_subnet_ids" {
  value       = aws_subnet.private_subnet.*.id
  description = "The IDs of the private subnets"
}


# Output for Application Load Balancer
output "alb_dns_name" {
  value       = aws_lb.app_lb.dns_name
  description = "The DNS name of the Application Load Balancer"
}

providers.tf: This file specifies the AWS provider and the region where the infrastructure will be provisioned.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.57.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

variables.tf: This file helps to declare the variables that will be used in the terraform configuration. Some variables have default variables as well.

######################
## Global variables ##  
######################
variable "aws_region" {
  description = "The AWS region to create resources in."
  default     = "ap-south-1"
}

variable "common_tags" {
  default = {
    Project     = "VPC Setup"
    Environment = "Production"
  }
}

variable "vpc_name" {
  type        = string
  description = "The name of the VPC."

}
#####################
## AWS Networking  ##  
#####################

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
}

variable "public_subnet_cidrs" {
  description = "CIDR blocks for public subnets"
  type        = list(string)
  default     = ["10.0.1.0/24", "10.0.2.0/24"]
}

variable "private_subnet_cidrs" {
  description = "CIDR blocks for private subnets"
  type        = list(string)
  default     = ["10.0.3.0/24", "10.0.4.0/24"]
}

variable "availability_zones" {
  description = "Availability zones for subnets"
  type        = list(string)
  default     = ["ap-south-1a", "ap-south-1b"]
}
############################
## AWS Auto-Scaling Group ##  
############################

variable "instance_type" {
  type        = string
  default     = "t2.micro"
  description = "The instance type"
}

variable "ami_id" {
  type        = string
  default     = "ami-0ec0e125bb6c6e8ec"
  description = "The AMI id of AWS Amazon Linux Instance in Mumbai"
}

terraform.tfvars: This file helps to define the values of the variables declared in variables.tf.

vpc_cidr = "10.0.0.0/16"
vpc_name = "aws_prod"

setup.sh: This file contains user-data that acts as a start-up script for the instances being launched.

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "Hello from $(hostname -f)" > /var/www/html/index.html

So this was it when it came to creating terraform scripts. Further execute the terraform init command to initialize terraform, and then execute the terraform plan to review the infrastructure to be provisioned and execute terraform apply to finally provision it.

terraform init

terraform plan

terraform apply: Finally, type yes when prompted to approve the infrastructure creation.

If terraform apply runs successfully, it will show the below-given output. It displays the outputs we defined in outputs.tf.

Now Let's verify the resources on the AWS Cloud Console.

The above image confirms that the networking components are created properly, aws_prod VPC with 4 subnets, (2 public and 2 private) that also in different AZs, Route tables, NAT Gateways with 2 EIPs, and Internet Gateway have been provisioned.

The above image confirms that the auto-scaling group with a launch template and with 2 instances have been provisioned. Also, you can see the instances with dedicated SG are created in different AZs that provide high availability and fault tolerance.

The above images confirm that the aws-app-prod-lb ALB with the aws-target-group target group has been provisioned. The 2 instances created as part of ASG are registered targets in this target group. The target group is configured to facilitate health checks and traffic distribution among the instances.

In the above images, one can see the DNS name(A record) of the ALB. If we access this in the browser, we can see that the load-balancing is balancing the load among instances. Below are the images that depict the same.

The above images clearly show that we have successfully deployed and configured the webserver securely in a Private instance, We can access it through the Internet using the Application Load Balancer securely.

Conclusion

This Terraform setup provides a robust template for deploying a high-availability architecture in AWS. It ensures that your infrastructure is resilient and adaptable to load changes, making it ideal for enterprises aiming to maximize uptime and performance. The entire infrastructure is codified, which simplifies changes and versioning over time.

By automating infrastructure management with Terraform, organizations can significantly reduce the potential for human errors while enabling faster deployment and scalability. This makes Terraform an indispensable tool in modern cloud environments.

Thank you for reading my blog post, please do share it with your peers.

Keep Learning, Keep Sharing

Reference Links: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html

Unleashing the Power of Kubernetes Network Policies

Piyush Bagani — Sun, 14 Jul 2024 12:48:26 +0000

Introduction

As Kubernetes continues to dominate the container orchestration landscape, understanding and leveraging its networking capabilities becomes essential. One often underutilized feature is Kubernetes Network Policies, which offer a powerful way to manage network traffic and enhance security within your cluster. This blog post will dive deep into Kubernetes Network Policies, their benefits, key concepts, and practical implementation tips.
What Are Kubernetes Network Policies?

Network Policies in Kubernetes define how groups of pods are allowed to communicate with each other and other network endpoints. They provide a declarative way to manage network traffic, ensuring that on

Why Network Policies Matter

Implementing Network Policies offers several key advantages:

Enhanced Security: By restricting traffic between pods, you can prevent unauthorized access and potential security breaches.
Improved Isolation: Network Policies ensure that only authorized services can communicate with each other, enforcing the principle of least privilege.
Simplified Network Management: Using declarative configurations, you can manage complex network topologies and traffic rules more efficiently.

Key Concepts

Before diving into the implementation, it’s essential to understand the key components of Network Policies:

Pod Selector: Defines which pods the network policy applies to based on labels.
Ingress Rules: Specify which incoming connections are allowed to the selected pods.
Egress Rules: Control the outgoing connections from the selected pods.
Namespaces: Use namespaces to apply network policies to different environments or applications within the same cluster.

Creating a Network Policy

Let’s walk through creating a basic Network Policy. Consider a scenario where you want to restrict traffic to a group labeled app: web so that only pods labeled app: backend can communicate with them.

Define the Policy YAML:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

Apply the Policy:

kubectl apply -f allow-backend-policy.yaml

This Network Policy allows incoming traffic to pods labeled app: web only from pods labeled app: backend within the same namespace.

Best Practices

Start with Default Deny: Implement a default deny policy for both ingress and egress to block all traffic by default and then explicitly allow necessary communication.
Use Namespaces Wisely: Leverage namespaces to create isolated environments and apply network policies accordingly.
Monitor Traffic: Regularly monitor network traffic to ensure policies are effective and adjust as necessary.

Advanced Example: Combining Ingress and Egress Rules

In a more advanced scenario, you might want to control both incoming and outgoing traffic for a set of pods. Here’s an example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database

Conclusion

Kubernetes Network Policies are a powerful tool for managing and securing network traffic within your cluster. By defining clear and concise policies, you can enhance the security, isolation, and manageability of your applications. Start experimenting with Network Policies today to see the benefits in your Kubernetes environments.

Let’s connect and discuss how you’re leveraging Network Policies in your Kubernetes setups! Share your experiences, challenges, and innovative use cases in the comments below.

Understanding Security Context in Kubernetes

Piyush Bagani — Sun, 30 Jun 2024 13:31:01 +0000

Introduction

Kubernetes, a leader in container orchestration, ensures that applications run efficiently and securely across a cluster of machines. An essential component of Kubernetes' security mechanism is the security context, which configures permissions and access controls for Pods and containers. This blog delves into the specifics of security contexts, helping you understand how to deploy secure applications within your Kubernetes environment.

Key Features of Kubernetes Security Contexts

RunAsUser: Controls the UID with which the container executes. This prevents the container from running with root privileges, which could pose security risks.
ReadOnlyRootFilesystem: Ensures the container's root filesystem is mounted as read-only, prohibiting modifications to the root filesystem and mitigating some forms of attack.
Capabilities: Allows administrators to grant or remove specific Linux capabilities for a container, enabling a principle of least privilege to be enforced.
SELinuxOptions: Specifies the SELinux context that the container should operate within. SELinux can enforce granular access control policies.

NOTE: There can be more settings as well, So please check out the official documentation.

Best Practices for Configuring Security Contexts

Non-root Containers: Always try to run containers as non-root users. Even if the container is compromised, this limits the potential for damage.
Enforce Read-Only Filesystems: Where possible, set ReadOnlyRootFilesystem to true to prevent tampering with system files.
Restrict Capabilities: Start with minimal necessary capabilities and add more only as needed. This limits the actions a container can perform, reducing the attack surface.
Configure SELinux Properly: Use SELinux to enforce strict access controls tailored to your operational needs. Understand your applications' requirements to configure these settings accurately.

Pod-Level Security Context Example

Here's an example of a Kubernetes manifest file that specifies security settings at the pod level. The security context applied here affects all containers within the pod.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: example-container
    image: nginx
    ports:
    - containerPort: 80

Explanation:

runAsUser: This setting ensures that the container runs as a user with UID 1000, which is a non-root user.

Container-Level Security Context Example

In this example, the security context is specified at the container level, meaning it only affects this particular container within the pod.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: secure-container
    image: nginx
    securityContext:
      runAsUser: 1001
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
        add:
        - NET_BIND_SERVICE
    ports:
    - containerPort: 80

Explanation:

runAsUser: The container runs as a user with UID 1001.
readOnlyRootFilesystem: This setting makes the root filesystem of the container read-only, preventing any write operations.
capabilities: This setting customizes the capabilities the container has:
- drop: ALL removes all capabilities by default.
- add: NET_BIND_SERVICE adds the capability to bind a service to well-known ports (below 1024).

Conclusion

Security contexts are one of those critical characteristics for managing security within Kubernetes. It assures enforcement of security policies and reduces the risk of unauthorized access or escalation occurring within the cluster. This can help to further improve the security of Kubernetes deployments if the concept of security contexts is properly understood and used.

Simplifying Persistent Storage in Kubernetes: A Deep Dive into PVs, PVCs, and SCs

Piyush Bagani — Sat, 22 Jun 2024 13:19:39 +0000

In the world of Kubernetes, managing persistent storage efficiently stands as a cornerstone for deploying resilient and scalable applications. Kubernetes not only orchestrates containers but also offers robust solutions for handling persistent data across these containers.

This blog dives into the critical components of Kubernetes storage management: Persistent Volumes (PV), Persistent Volume Claims (PVC), Storage Classes (SC), and Volume Claim Templates. These elements are pivotal in making Kubernetes a powerhouse for maintaining stateful applications amidst the dynamic nature of containerized environments.

Persistent Volumes (PV)

Persistent Volumes are one of the building blocks of storage in Kubernetes. A PV is a networked storage unit in the cluster that has been provisioned by an administrator or automatically provisioned via Storage Classes. It represents a piece of storage that is physically backed by some underlying mass storage system, like NFS, iSCSI, or a cloud provider-specific storage system.

Characteristics of PVs:

Lifecycle Independence: PVs exist independently of pods' lifecycles. This means that the storage persists even after the pods that use them are deleted.
Storage Abstraction: PVs abstract the details of how storage is provided from how it is consumed, allowing for a separation of concerns between administrators and users.
Multiple Access Modes: PVs support different access modes like ReadWriteOnce, ReadOnlyMany, and ReadWriteMany, which dictate how the volume can be mounted on a node.

Persistent Volume Claims (PVC)

Persistent Volume Claims are essentially requests for storage by a pod. PVCs consume PV resources by specifying size and access modes, like a kind of "storage lease" that a user requests to store their data.

How PVCs Work:

Binding: When a PVC is created, Kubernetes looks for a PV that matches the PVC’s requirements and binds them together. If no suitable PV exists, the PVC will remain unbound until a suitable one becomes available or is dynamically provisioned.
Dynamic Provisioning: If a PVC specifies a Storage Class, and no PV matches its requirements, a new PV is dynamically created according to the specifics of the Storage Class.

Storage Classes (SC)

Storage Classes define and classify the types of storage available within a Kubernetes cluster. They enable dynamic volume provisioning by describing the "classes" of storage (different levels of performance, backups, and policies).

Features of SCs:

Provisioning: Admins can define as many Storage Classes as needed, each specifying a different quality of service or backup policy.
Automation: Based on the Storage Class specified in a PVC, Kubernetes automates the volume provisioning, without manual PV creation by the administrator.

Example:

Consider a scenario where a Kubernetes cluster needs to dynamically provide storage for a database application:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-storage
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-disk
  resources:
    requests:
      storage: 100Gi

This PVC requests a 100 GiB disk with read-write access on a single node. The fast-disk Storage Class is designed to provision high-performance SSD-based storage, tailored for database applications.

How It Works:

PVC Creation: The above PVC is created, requesting specific storage characteristics.
Dynamic Provisioning: If no existing PV matches the PVC, the Storage Class fast-disk triggers the dynamic creation of a new PV that fits the criteria.
Binding: The newly created PV is automatically bound to the PVC, ensuring the database application has the necessary storage.

Conclusion

Understanding PVs, PVCs, and SCs is crucial for effectively managing storage in Kubernetes. These components offer a flexible, powerful way to handle persistent data, ensuring applications can be highly available and resilient. As Kubernetes continues to evolve, the capabilities and complexity of managing storage will likely increase, offering even more robust solutions for cloud-native environments.

In a nutshell

PVs act as a bridge between the physical storage and the pods, offering a lifecycle independent of the pods.
PVCs allow pods to request specific sizes and access modes from the available PVs.
SCs automate the provisioning of storage based on the desired characteristics, facilitating dynamic storage allocation without manual intervention.

Understanding Jobs and CronJobs in Kubernetes

Piyush Bagani — Sat, 15 Jun 2024 14:20:01 +0000

If you’ve ever scheduled an email to go out later or set a reminder to do something at a specific time, you’re already familiar with the concepts behind Jobs and CronJobs in Kubernetes. These tools help manage and automate tasks within your Kubernetes cluster, ensuring things get done when they should. Let's break it down in simple terms.

Jobs: The Task Managers of Kubernetes

Imagine you have a list of tasks to complete, like cleaning your room or finishing a report. In Kubernetes, a Job is like a task manager that ensures these chores get done. When you create a Job, you’re telling Kubernetes, “Hey, please run this task for me, and make sure it’s completed successfully.”

How it works:

Create the Job: You define what needs to be done in a Job manifest. Think of it as a to-do list.
Run the Job: Kubernetes takes this manifest and runs the task.
Check Completion: It makes sure the task finishes. If it fails, Kubernetes will try again until it succeeds (or hits a limit you set).
This is perfect for tasks that need to be run once or just a few times, like processing a batch of data or sending a notification email.

Diving Deeper into Job Configurations

Parallelism: Controls how many pods can run concurrently. If the parallelism field is not specified, the default value is 1. This means only one pod will be created at a time.
Completions: Specifies the number of successful completions needed. If the completions field is not specified, the default value is 1. This means the job is considered complete when one pod successfully completes.
BackoffLimit: Sets the number of retries before the Job is considered failed. If the backoffLimit field is not specified, the default value is 6. This means the job will retry up to 6 times before it is marked as failed.

Example Manifest file:

# job-definition.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: advanced-job
spec:
  parallelism: 3
  completions: 5
  backoffLimit: 4
  template:
    spec:
      containers:
      - name: example
        image: busybox
        command: ["sh", "-c", "echo Job running... && sleep 30"]
      restartPolicy: OnFailure

This Kubernetes Job will create a pod using the busybox image, run a command that prints a message, and sleep for 30 seconds. It will run up to 3 pods in parallel until 5 successful completions are achieved. If a pod fails, it will be retried up to 4 times before marking the Job as failed. The pod will be restarted only if it fails.

CronJobs: Your Scheduled Assistants

CronJobs extends Jobs by allowing you to schedule tasks at specific times or intervals. If Jobs are your reliable friends, CronJobs are those friends who show up at the same time every week to help with recurring tasks.

How it works:

Define the Schedule: You set up a CronJob with a schedule, using the Cron format (a standard way to specify time intervals).
Automate the Task: At the specified times, Kubernetes will automatically create Jobs to perform the task.
Repeat: It keeps running these tasks on the schedule you set, whether that’s every hour, day, week, or month.
CronJobs are ideal for repetitive tasks, such as backing up databases, cleaning up logs, or generating reports.

Note: Cron Syntax: Cron format consists of five fields (minute, hour, day of month, month, day of week) and a command.

* * * * * - every minute
0 * * * * - every hour
0 0 * * * - every day at midnight

Example Manifest file:

# cronjob-definition.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: example-cronjob
spec:
  schedule: "0 0 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: example
            image: busybox
            command: ["sh", "-c", "echo CronJob running... && sleep 30"]
          restartPolicy: OnFailure

This CronJob is configured to run a container named "example" using the "busybox" image every day at midnight. The container executes a shell command that prints a message and sleeps for 30 seconds. If the job fails, it will be restarted.

Real-World Scenarios

Data Processing:

Job: Run a data processing script to analyze yesterday’s sales figures.
CronJob: Automatically run this script every night at midnight.

System Maintenance:

Job: Clean up old, temporary files to free up space.
CronJob: Schedule this cleanup to happen every Sunday at 3 AM.

Notifications:

Job: Send a welcome email to a new user.
CronJob: Send a daily summary email to all users at 8 AM.

Conclusion

Jobs and CronJobs in Kubernetes are your reliable helpers, taking care of tasks efficiently and on time. Jobs ensures one-time tasks get done, while CronJobs handles recurring tasks effortlessly. By leveraging these tools, you can automate and manage your workloads effectively, freeing up time to focus on more critical aspects of your projects.

Understanding /var/run/docker.sock: The Key to Docker's Inner Workings 🐳

Piyush Bagani — Thu, 30 May 2024 16:40:18 +0000

If you're diving into Docker, one term you’ll encounter often is /var/run/docker.sock. But what is it, and why is it so important?

🔍 What is /var/run/docker.sock?
In simple terms, /var/run/docker.sock is a Unix socket file used by Docker to communicate with the Docker daemon (dockerd). This socket file acts as a bridge between your Docker client (like the Docker CLI) and the Docker daemon, enabling you to manage containers, images, networks, and more.

🔧 How Does It Work?
Communication Channel: Instead of using network-based protocols (like HTTP or TCP), Docker uses this Unix socket for efficient and secure communication between the client and the daemon on the same host.
API Access: All Docker commands you run via the CLI (docker run, docker ps, etc.) interact with the Docker daemon through this socket. Essentially, it’s the API endpoint for Docker operations.

🔐 Why Should You Care?
Understanding /var/run/docker.sock is crucial for advanced Docker operations:
Container Management: Tools like Docker Compose and various CI/CD systems use this socket to orchestrate and manage containers.
Security: Be cautious when granting access to this socket. Mounting /var/run/docker.sock inside a container provides that container with root-level access to the host’s Docker daemon, which can pose significant security risks.

💡 Practical Use Case
Ever wondered how to manage Docker from within a container? By mounting the Docker socket inside your container, you can.

Check out my blog on How to run docker in docker.

📈 The Bigger Picture
For developers and DevOps professionals, understanding how Docker operates under the hood, including the role of /var/run/docker.sock, is key to leveraging the full power of containerization. It opens up possibilities for automation, advanced orchestration, and efficient resource management.

Stay curious, and keep exploring the depths of Docker! 🌊🐳

Keep Learning, Keep Hustling.

A Day in the Life of a DevOps Engineer

Piyush Bagani — Thu, 25 Apr 2024 11:49:06 +0000

Introduction

DevOps engineers play a pivotal role in blending software development and system operations to enhance both system reliability and deployment efficiency. Their importance has grown significantly in the tech industry, driven by the need for faster software delivery cycles and robust, scalable systems.

Morning Activities

Start of Day

System Monitoring: Check system health and performance using tools like Prometheus, Grafana, or New Relic.

Daily Stand-up Meeting

Team Collaboration: Engage in Agile stand-up meetings to discuss progress, challenges, and plan the day's tasks.

Updating Scripts/Tooling

Automation: Write or refine automation scripts in Bash or Python to improve system management and deployment processes.

Midday Activities

Code Deployment

CI/CD Pipelines: Deploy code updates using CI/CD tools such as Jenkins, GitLab CI, or CircleCI. Manage configurations and dependencies through IaC tools like Terraform or Ansible.

Collaboration and Planning

Inter-team Meetings: Discuss upcoming features, necessary infrastructure changes, or capacity planning with development teams.

Afternoon Activities

Incident Management

Troubleshooting: Address and resolve production issues, often collaborating with the site reliability engineering (SRE) team.

Performance Optimization

System Tuning: Analyze performance data to identify bottlenecks and optimize configurations using tools like Chef or Puppet.

Documentation and Reporting

Record Keeping: Update internal documentation with recent changes and prepare reports on deployments, system status, or incident resolutions.

Evening Wrap-up

Review and Reflect

End of Day Review: Check the final metrics and review the completed tasks and any outstanding issues.

Knowledge Sharing

Community Engagement: Participate in webinars, contribute to blogs, or prepare talks on recent challenges or new technologies.

Planning for the Next Day

Task Prioritization: Set up monitoring alerts and organize tasks for the following day.

Tools and Technologies Commonly Used

Cloud Platforms: AWS, Azure, Google Cloud
IaC and Configuration Management: Terraform, Ansible, Chef, Puppet
CI/CD Tools: Jenkins, GitLab CI, CircleCI
Scripting Languages: Python, Bash
Monitoring Tools: Prometheus, Grafana, New Relic, ELK Stack

Challenges Faced by DevOps Engineers

Rapid Technological Changes: Continuously learning and adapting to new tools.
System Scalability and Reliability: Ensuring systems are robust enough to handle growth and peak loads.
Security Concerns: Balancing rapid deployment needs with stringent security measures.

Conclusion

DevOps engineers are crucial to modern tech organizations, ensuring fast and reliable software deployment and system management. The role is expected to evolve with technological advancements in AI, machine learning, and increased automation.

Call to Action

For Aspiring DevOps Engineers

Skill Development: Focus on developing technical skills, pursuing relevant certifications, and joining professional communities.

For Organizations

Adopting DevOps Practices: Integrate DevOps to enhance operational productivity and system efficiency.

Mastering the Crontab: A Guide to Automated Tasks in Unix-like Systems

Piyush Bagani — Sat, 16 Mar 2024 13:49:08 +0000

Introduction:

Have you ever wished you could automate repetitive tasks on your computer, freeing up your time for more important things? Enter crontab, your personal timekeeper in the world of Unix-like systems. In this human-friendly guide, we'll explore crontab together, demystifying its workings and showing you how to leverage its power to simplify your life.

Understanding the Basics:

At its core, crontab operates on the principle of scheduling tasks to run at specific times or intervals. Each user on a Unix-like system can have their own crontab file, which contains a list of commands along with the schedule for when those commands should be executed. These schedules are defined using a syntax that consists of five fields:

Minute (0-59)
Hour (0-23)
Day of the month (1-31)
Month (1-12)
Day of the week (0-7, where both 0 and 7 represent Sunday)

Additionally, there are special characters that can be used in these fields to denote specific intervals or wildcard values. For example, an asterisk (*) represents all possible values for a field, while a hyphen (-) denotes a range, and a comma (,) separates multiple values.

Creating and Managing Crontab Entries:

To create or edit your crontab file, you can use the crontab -e command, which opens the default text editor specified in your environment. Each line in the crontab file represents a separate job entry, with the schedule followed by the command to be executed. For example:
`

Send out a weekly report every Monday at 8:00 AM

0 8 * * 1 /path/to/weekly_report.sh

Run a Script Every Sunday at Midnight:

0 0 * * 0 /path/to/weekly_script.sh

Run a Script Every Weekday at 8:30 AM:

30 8 * * 1-5 /path/to/script.sh
`

Best Practices for Success:

To make the most of crontab, it's essential to follow a few best practices:

Keep It Organized: Use comments to document your crontab entries, making it easier to understand and manage your schedule.
Test Before Deploying: Always test your commands or scripts manually before adding them to crontab to ensure they work as expected.
Monitor and Log: Redirect the output of your cron jobs to log files to track their execution and troubleshoot any issues.
Stay Secure: Be cautious when running automated tasks as root, and ensure your commands and scripts are secure to prevent any unintended consequences.

Conclusion:

With crontab as your trusty timekeeper, you can automate away the mundane tasks that eat up your precious time. By understanding its basics, setting up your schedule, and following best practices, you'll be well on your way to mastering the art of automation. So go ahead, seize control of your time with crontab, and let it work its magic in the background while you focus on what truly matters.

How to Ace Your Google Cloud DevOps Certification: Insider Tips and Strategies

Piyush Bagani — Fri, 09 Feb 2024 16:00:19 +0000

Stepping into the world of cloud technology and DevOps, I embarked on a transformative journey towards achieving the Google Cloud Professional Cloud DevOps Engineer Certification. It was a path paved with curiosity, challenges, and countless moments of learning.

In this blog, I will share the strategy and resources of my preparation process, as I delve deep into the world of Google Cloud and hone my skills in DevOps practices. From the initial spark of interest to the triumphant moment of certification, every step of this adventure was filled with invaluable insights and experiences.

Navigating the Exam Structure: What to Expect:

The exam price is $200 and You can expect 50 questions to be answered within 2 hours.

The Exam Guide Covers:

Bootstrap a Google Cloud organization for DevOps
Building and implementing CI/CD pipelines for a service
Apply site reliability engineering practices to a service
Implementing Service Monitoring Strategies
Optimize service performance

You can check the Exam guide here.

Mastering Google Cloud Tools for DevOps: Key Concepts and Best Practices

This particular exam focuses mainly on the following topics.

Google Kubernetes Engine
SRE Best practices (Very IMP)
Binary Authorization
Monitoring and Logging
Incident Management
Artifact registry, Source Repositories
Deployment and testing strategies

Resources I followed

The DevOps and SRE path by Google.
This may be a little time taking but it is worth watching. You can find it here
The Google SRE Book
This is a valuable resource to understand SRE principles deeply. Worth reading. Find it here.
The Last Minutes Notes.
This is Ammett William's Prepsheet, good to read while revising the concepts. Here is the link
Google SRE DevOps Playlist
You won't regret watching this playlist right from Google.
This is a Bonus Resource.
I have created an extensive guide, covering all the concepts. In this document, I have covered all the best practices an SRE follows. You can read it here.

Important Tips:

Practice with sample questions: Spend some time reviewing sample questions or taking practice exams to familiarize yourself with the format and types of questions you may encounter.
Also practice the questions from a website called examtopics.com. This website includes previous questions that already came in the exam.
Focus on understanding key concepts rather than memorizing details.
Manage your time effectively during the exam.
Stay calm, read questions carefully, and trust in your preparation.

I trust that this guidance aids you in your exam readiness and eventual success. Thank you for taking the time to read through it. Wishing you the best of luck in your performance on the exam!

Thanks for Reading.
Keep Learning, Keep Sharing