DEV Community: Omkar Sharma

Guide For Starting Terraform

Omkar Sharma — Sun, 30 Aug 2026 10:57:48 +0000

Without Infrastructure as Code, creating infrastructure is a task. With Terraform, it becomes a repeatable process.

Imagine you are asked to create infrastructure for a new application/project.

You need:

A VPC
Subnets
Route tables
Security groups
EC2 instances
Load balancers
Databases
IAM roles
Monitoring

You open the cloud console and start creating everything manually.

The first environment takes a few hours.

Then someone asks:

"Can we create the same infrastructure for staging?"

So you start again.

Then production.

Then another region.

Then six months later, someone asks:

"What exactly did we change in the infrastructure?"

And now the real problem begins.

You might remember some of it.

Maybe you have documentation.

Maybe someone took screenshots.

Maybe you have a spreadsheet.

Or maybe you simply say:

"I don't remember. I created it manually."

This is where Terraform changes the way we think about infrastructure.

What Is Terraform?

Terraform is an Infrastructure as Code (IaC) tool that allows you to define and manage infrastructure using configuration files instead of manually creating resources through a cloud console.

Instead of saying:

"Go to AWS → VPC → Create → Subnet → Create → Security Group → Create..."

You define what you want in code.

For example:

resource "aws_instance" "web" {
  ami           = "ami-xxxxxxxx"
  instance_type = "t2.micro"

  tags = {
    Name = "web-server"
  }
}

Terraform reads this configuration and creates the infrastructure for you.

The important part isn't just that Terraform creates an EC2 instance.

The important part is that your infrastructure is now represented as code.

And code can be:

Version controlled
Reviewed
Reused
Tested
Shared
Automated
Recreated

That's where the real value comes from.

What Happens If We Don't Use Terraform?

Let's look at the traditional approach.

Suppose a company has three environments:

Development
     ↓
Staging
     ↓
Production

Someone manually creates resources in each environment.

Over time, small differences start appearing.

Development might have:

EC2: t3.micro
Security Group: Port 80, 22
Subnet: 10.0.1.0/24

Staging might have:

EC2: t3.small
Security Group: Port 80, 443, 22
Subnet: 10.0.2.0/24

Production might have:

EC2: t3.medium
Security Group: Port 80, 443
Subnet: 10.0.10.0/24

Some differences are intentional.

Others might simply be mistakes.

This creates the famous problem:

"It works in my environment."

The application may work in development but fail in staging because the environments aren't configured the same way.

Terraform helps solve this by making the infrastructure configuration repeatable and standardized.

1. Save Time

One of the biggest benefits of Terraform is simple:

Automation saves time.

Imagine manually creating:

1 VPC
4 subnets
2 route tables
3 security groups
5 EC2 instances
1 load balancer
1 database

Doing this manually can take considerable time.

Now imagine you need the same infrastructure again.

With Terraform, you don't start from zero.

You can reuse your configuration.

terraform init
terraform plan
terraform apply

That's it.

Instead of repeatedly clicking through the cloud console, you let Terraform perform the repetitive work.

Write once. Deploy many times.

2. Reduce Human Errors

Humans make mistakes.

It's normal.

Maybe someone:

Selects the wrong subnet
Opens the wrong security group port
Chooses the wrong instance type
Attaches the wrong route table
Forgets to enable encryption
Creates a resource in the wrong region

One small mistake in infrastructure can cause a major problem.

Terraform doesn't eliminate every possible mistake, but it significantly reduces manual configuration errors by making infrastructure configuration explicit and repeatable.

Instead of relying on memory:

"I think I configured production the same way."

You have code that defines exactly what should exist.

3. Environment Consistency

This is one of my favorite benefits of Infrastructure as Code.

Consider:

Development
     ↓
Staging
     ↓
Production

Without IaC, each environment can slowly become different.

With Terraform, you can define a standard infrastructure architecture and reuse it across environments.

For example:

terraform/
│
├── modules/
│   ├── network/
│   ├── compute/
│   └── database/
│
├── environments/
│   ├── dev/
│   ├── staging/
│   └── production/

The exact values can differ between environments, but the infrastructure structure can remain consistent.

This helps eliminate:

"It works on my machine."

And moves toward:

"It works because every environment follows the same infrastructure definition."

4. Repetitive Tasks Become Automation

Think about how many times DevOps engineers perform the same tasks.

Create a:

VPC
Subnet
Security group
IAM role
EC2 instance
Load balancer

Doing these things repeatedly is not a great use of engineering time.

Terraform turns repetitive infrastructure tasks into reusable code.

Instead of:

Click
Click
Click
Configure
Verify
Repeat

You move toward:

Code
   ↓
Plan
   ↓
Apply
   ↓
Infrastructure

Your time can then be spent on more valuable engineering problems instead of repetitive clicking.

5. Write Once, Deploy Many

This is where Terraform becomes extremely powerful.

Suppose you've created a network architecture using Terraform.

You can reuse it for:

Development
Staging
Production
DR
Testing
New Region
New Project

You don't need to recreate everything manually.

You can parameterize your configuration using variables.

For example:

variable "environment" {
  type = string
}

variable "instance_type" {
  type = string
}

Then different environments can provide different values.

dev        → t3.micro
staging    → t3.small
production → t3.medium

The infrastructure logic remains reusable.

6. Infrastructure Changes Become Trackable

Here's another major problem with manually created infrastructure:

Who changed what?

Imagine someone modifies a production security group.

You discover the change two weeks later.

Who changed it?

Why?

When?

What was the previous configuration?

With Terraform, your infrastructure configuration can live in Git.

For example:

Git Repository
      │
      ├── Commit 1
      ├── Commit 2
      ├── Commit 3
      └── Commit 4

Now infrastructure changes can go through the same process as application code:

Developer
   ↓
Change Terraform code
   ↓
Git commit
   ↓
Pull Request
   ↓
Code Review
   ↓
Terraform Plan
   ↓
Terraform Apply

Infrastructure becomes part of your software development lifecycle.

7. Terraform Plan: See Before You Change

One of the most useful Terraform commands is:

terraform plan

It shows what Terraform intends to change before actually making those changes.

For example:

Plan: 2 to add, 1 to change, 0 to destroy.

This gives you an opportunity to review infrastructure changes before applying them.

Instead of:

"I clicked something and now production changed."

You get:

"Here is exactly what Terraform plans to change."

That makes infrastructure changes much more predictable.

8. Easier Infrastructure Maintenance

Infrastructure isn't something you create once and forget.

It changes constantly.

You might need to:

Upgrade an instance
Add a subnet
Modify security rules
Add a load balancer
Change database configuration
Add monitoring
Update networking

Without IaC, these changes can become difficult to track.

With Terraform, you modify the configuration.

For example:

instance_type = "t3.micro"

can become:

instance_type = "t3.medium"

Terraform can determine the required change.

Your infrastructure configuration becomes the source of truth for the desired state.

9. Easier Disaster Recovery

Imagine your infrastructure is accidentally deleted.

If everything was created manually, rebuilding it could take hours or even days.

If your infrastructure is defined in Terraform:

Terraform Code
      ↓
terraform apply
      ↓
Infrastructure recreated

You can recreate the infrastructure from the configuration.

Of course, production recovery also requires proper backups, state management, secrets management, data recovery strategies, and testing.

Terraform isn't a backup system.

But it can make rebuilding infrastructure dramatically easier.

10. Save Engineering Cost

Terraform itself doesn't magically make your cloud bill cheaper.

But it can help reduce costs indirectly.

How?

Less manual work

Engineers spend less time repeatedly creating infrastructure.

Fewer configuration mistakes

Incorrect configurations can lead to unnecessary resource usage.

Easier cleanup

Temporary environments can be destroyed when they're no longer needed.

terraform destroy

For example:

Testing Environment
       ↓
Create
       ↓
Run Tests
       ↓
No longer needed
       ↓
terraform destroy

This is much better than leaving forgotten resources running and discovering them later on the cloud bill.

11. Infrastructure Lifecycle Becomes Simple

Terraform can help manage the infrastructure lifecycle:

Provision
    ↓
Maintain
    ↓
Modify
    ↓
Scale
    ↓
Destroy

Provision

terraform apply

Create infrastructure.

Maintain

Modify Terraform configuration and apply changes.

Destroy

terraform destroy

Remove infrastructure that is no longer required.

The entire lifecycle can be managed through code.

12. Multi-Cloud Infrastructure

Another major advantage is that Terraform supports many infrastructure providers.

For example:

             Terraform
                 │
       ┌─────────┼─────────┐
       ↓         ↓         ↓
      AWS       Azure      GCP

You can use Terraform to manage resources across different providers.

This doesn't mean you should always use multiple clouds.

It simply means your infrastructure tooling doesn't have to be tied to a single cloud platform.

13. Terraform Fits Naturally Into CI/CD

Terraform becomes even more powerful when combined with CI/CD.

For example:

Developer
    ↓
Git Push
    ↓
CI/CD Pipeline
    ↓
terraform fmt
    ↓
terraform validate
    ↓
terraform plan
    ↓
Approval
    ↓
terraform apply
    ↓
Infrastructure

Now infrastructure changes can follow an automated workflow.

You don't necessarily need someone sitting in front of the cloud console.

Terraform Isn't Just About Creating Resources

This is probably the most important point.

Terraform isn't valuable simply because it can create an EC2 instance.

You could create an EC2 instance manually.

You could also use a cloud CLI.

The real value is:

Terraform turns infrastructure into code.

And once infrastructure becomes code, you gain:

Version Control
       +
Automation
       +
Consistency
       +
Reusability
       +
Reviewability
       +
Repeatability
       +
Reduced Human Error

That's the real benefit.

Manual Infrastructure vs Terraform

Manual Approach	Terraform
Click through console	Infrastructure as Code
Repetitive work	Automation
Higher human error	Consistent configuration
Difficult to reproduce	Easily reproducible
Harder to track changes	Git version control
Environment drift	Standardized environments
Manual documentation	Code acts as documentation
Difficult to scale	Reusable configuration
Manual cleanup	`terraform destroy`
Harder collaboration	Code review + Git
Time-consuming	Faster provisioning

But Should Everything Be Terraform?

Not necessarily.

Terraform is powerful, but it's not a magic solution for everything.

You still need to think about:

Terraform state management
Secrets management
State locking
Module design
Provider versions
Access control
CI/CD security
Infrastructure testing
Cloud architecture

And you should avoid blindly putting every manual action into Terraform.

The goal isn't:

"Use Terraform because everyone uses Terraform."

The goal is:

Use Infrastructure as Code when repeatability, consistency, automation, and controlled infrastructure changes matter.

The Real Shift

Without Infrastructure as Code, the process often looks like this:

Human
  ↓
Cloud Console
  ↓
Manual Configuration
  ↓
Infrastructure

With Terraform:

Engineer
    ↓
Terraform Code
    ↓
Git
    ↓
Review
    ↓
Terraform Plan
    ↓
Terraform Apply
    ↓
Infrastructure

That's a fundamental change in how infrastructure is managed.

So instead of infrastructure being something that engineers manually build, Terraform allows infrastructure to become something engineers define, review, reproduce, and automate.

And that's why Infrastructure as Code has become such an important part of modern DevOps.

Write once. Review once. Deploy repeatedly.

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

Docker Hub Was the Default Registry for Me. But This Time, I Tried Amazon ECR.

Omkar Sharma — Sun, 23 Aug 2026 18:14:04 +0000

Docker Hub had always been my go-to registry whenever I worked with Docker.

But this time, while deploying a Weather Application on AWS, I thought — why not try Amazon ECR?

Since I was already deploying the application on ECS with Fargate, keeping the container image within AWS felt like a good opportunity to explore ECR, especially with its integration with ECS and AWS IAM.

So, I decided to give it a try.

Source Code → EC2 → Docker → ECR → ECS Fargate

Here’s how the journey went.

1. Launch and Configure EC2

After launching and connecting to the Ubuntu EC2 instance, install and verify the tools required to build and deploy the application.

Install Docker

sudo apt install docker.io -y

Installs Docker on the Ubuntu EC2 instance.

Verify Docker Installation

docker --version

Checks whether Docker is installed and displays the installed version.

Check Running Containers

docker ps

Lists the currently running Docker containers.

Give the Current User Docker Permissions

sudo usermod -aG docker $USER && newgrp docker

Adds the current user to the Docker group and applies the new group membership immediately, allowing Docker commands to run without sudo.

Verify Docker Permissions

docker ps

Confirms that the current user can run Docker commands without requiring sudo.

Install AWS CLI

sudo apt install awscli

Installs the AWS Command Line Interface for interacting with AWS services from the EC2 instance.

Verify AWS CLI Installation

aws --version

Checks whether the AWS CLI is installed correctly and displays its installed version.

2. Pull and Dockerize the Weather Application

After configuring the EC2 instance, pull the application source code from GitHub and prepare it for containerization.

Clone the Repository

Clone the application repository onto the EC2 instance:

git clone https://github.com/omkarsharma2821/Weather-App-for-AWS.git

Downloads the application source code from GitHub to the EC2 instance.

Navigate to the Application Directory

cd Weather-App-for-AWS/

Moves into the application directory where the source code and Dockerfile are located.

Inspect the Application

ls

Lists the application files and directories to verify that the repository was cloned successfully.

Build the Docker Image

docker build --build-arg VITE_API_KEY="YOUR_API_KEY" -t weather-app .

The command docker build --build-arg VITE_API_KEY="YOUR_API_KEY" -t weather-app . builds a Docker image using the Dockerfile in the current directory (.), while --build-arg VITE_API_KEY="YOUR_API_KEY" passes the VITE_API_KEY value to the Docker build process so that the Vite application can use it during npm run build; -t weather-app gives the resulting Docker image the name weather-app, which can then be used to run, tag, and push the image to Amazon ECR.

Verify the Docker Image

docker images

Lists the available Docker images and confirms that the weather-app image was created successfully.

Run the Container

docker run -d -p 3000:80--name weather-app weather-app

Starts the weather application as a background container and maps the application's port to the EC2 instance.

Note: Replace 3000:80 with the port used by your application.

Verify the Running Container

docker ps

Confirms that the weather application container is running successfully.

Test the Application

The application can now be tested using the EC2 instance's public IP and the exposed port:

http://<EC2-PUBLIC-IP>:3000

This confirms that the application works correctly inside the Docker container before pushing the image to Amazon ECR.

3. Create an ECR Repository and Push the Docker Image

Once the Docker image has been built and tested on the EC2 instance, the next step is to store the image in Amazon Elastic Container Registry (ECR). ECR provides a private container registry where the Docker image can be securely stored and later pulled by Amazon ECS.

Create the ECR Repository

Create a private ECR repository from the AWS Management Console.

Navigate to:

AWS Console → ECR → Repositories → Create repository

Give the repository a name, for example:

weather-app

Keep the repository private and create it.

Authenticate Docker with Amazon ECR

Note: Ensure the IAM user/role has ECR permissions, especially ecr:GetAuthorizationToken, before authenticating Docker with ECR.

This creates an ECR-compatible tag for the local weather-app image.

Push the Image to ECR

Verify the Image

At this point, the application image is available in ECR and ready to be deployed through Amazon ECS with AWS Fargate.

4. Create ECS Cluster and Deploy Using Fargate

Once the Docker image is available in Amazon ECR, the next step is to deploy the containerized weather application using Amazon ECS with AWS Fargate.

Create an ECS Cluster

Navigate to:

AWS Console → ECS → Clusters → Create Cluster

Create a cluster and select the AWS Fargate infrastructure option.

Give the cluster a suitable name, for example:

weather-app-cluster

An ECS cluster provides a logical grouping of ECS services and tasks.

Why Fargate?

AWS Fargate is a serverless compute engine for containers. It allows ECS to run containers without requiring you to provision or manage EC2 instances for the container workloads.

In this deployment:

ECS = Container orchestration
Fargate = Compute used to run the containers

ECS manages the tasks and services, while Fargate provides the underlying compute capacity.

Create an ECS Task Definition

Navigate to:

ECS → Task Definitions → Create new task definition

Configure the task definition with the required application settings.

Create an ECS Service

After creating the task definition, create an ECS service inside the previously created cluster.

Navigate to:

ECS → Clusters → weather-app-cluster → Create Service

Select:

Launch type: Fargate
Task definition: weather-app
Desired tasks: 1

The desired task count determines how many copies of the container ECS should keep running.

Configure Networking

Select the VPC and subnets where the Fargate task will run.

Configure:

VPC: Application VPC
Subnets: Required subnets
Security Group: Application security group
Public IP: Enable if the application needs to be directly accessible from the internet

The security group should allow inbound traffic on the application's required port.

For example:

Type: Custom TCP
Port: 3000
Source: Required traffic source

For a production architecture, the application would typically be placed in private subnets and exposed through an Application Load Balancer (ALB) rather than assigning a public IP directly to the task.

Deploy the Service

Review the configuration and create the ECS service.

ECS will then:

Pull the Docker image from ECR.
Provision the required Fargate compute.
Start the container.
Attach the configured networking and security group.
Keep the desired number of tasks running.

Once the task reaches the RUNNING state, the weather application is successfully deployed on ECS using Fargate.

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

Jenkins CI/CD Pipeline for a Dockerized Node.js Application: Manual Trigger vs Automatic Trigger Using GitHub Webhooks

Omkar Sharma — Sat, 23 May 2026 08:32:33 +0000

Have you ever pushed code to GitHub and wished your application could automatically build and deploy itself without logging into a server or clicking a button in Jenkins? In this article, you'll learn how to build a complete CI/CD pipeline for a Dockerized Node.js application using Jenkins, starting with manual deployments and progressing to fully automated deployments using GitHub webhooks.

We will cover:

Creating a Jenkins pipeline
Building a Docker image
Deploying a container
Triggering builds manually
Triggering builds automatically
GitHub Personal Access Tokens
Fine-grained vs Classic Tokens
Jenkins credentials
GitHub webhooks
Required Jenkins plugins
Common errors and troubleshooting The goal is to understand not only how to configure everything but also why each component is needed.

Node.js Application Repo URL- https://github.com/omkarsharma2821/Node.js-App-Deploy-Github-Action

Architecture Overview

The complete flow looks like this:

Developer
    |
    | Git Push
    v
GitHub Repository
    |
    | Webhook
    v
Jenkins
    |
    | Build Docker Image
    v
Docker
    |
    | Run Container
    v
Application Running

Without webhooks:

Developer
    |
    | Git Push
    v
GitHub Repository

Jenkins Build Now (Manual Trigger)
    |
    v
Build and Deploy

With webhooks:

Developer
    |
    | Git Push
    v
GitHub Repository
    |
    v
Webhook
    |
    v
Jenkins
    |
    v
Build and Deploy Automatically

Prerequisites

Before starting, ensure you have:

Ubuntu Server
Jenkins installed
Docker installed
Git installed
GitHub repository
Node.js application with Dockerfile Verify installations:

jenkins --version
docker --version
git --version

Installing Docker on Jenkins Server

Install Docker:

sudo apt update
sudo apt install docker.io -y

Enable Docker:

sudo systemctl enable docker
sudo systemctl start docker

Verify:

docker --version

Allow Jenkins to Use Docker

By default Jenkins cannot execute Docker commands.

Add Jenkins user to Docker group:

sudo usermod -aG docker jenkins

Restart Jenkins:

sudo systemctl restart jenkins

Verify:

sudo su - jenkins
docker ps

If Docker works without sudo, Jenkins is ready.

Creating the Pipeline

Initially we created a Jenkins pipeline that manually clones the repository.

Example:

pipeline {
    agent any

    stages {

        stage('Clone Repository') {
            steps {
                sh '''
                    mkdir -p devops
                    cd devops
                    rm -rf Node.js-App-Deploy-Github-Action
                    git clone -b main https://github.com/username/repository.git
                '''
            }
        }

        stage('Build Image') {
            steps {
                sh '''
                    cd devops/Node.js-App-Deploy-Github-Action
                    docker build -t node-app .
                '''
            }
        }

        stage('Deploy') {
            steps {
                sh '''
                    docker run -d -p 8000:8080 node-app
                '''
            }
        }
    }
}

This works, but every deployment requires manually clicking:

Build Now

Problem with Multiple Deployments

Suppose the application is already running.

Running:

docker run -d -p 8000:8080 node-app

again will fail because port 8000 is already occupied.

Error:

Bind for 0.0.0.0:8000 failed

Better Deployment Approach

Before starting a new container, remove the old one.

docker rm -f node-app-container || true

Then start a new container:

docker run -d --name node-app-container -p 8000:8080 node-app

Understanding docker rm -f node-app-container || true

Let's break it down.

docker rm

Removes a container.

docker rm node-app-container

Works only if container is stopped.

-f

Force remove.

docker rm -f node-app-container

This:

Stops container
Removes container

||

OR operator.

Syntax:

command1 || command2

If command1 fails, command2 executes.

true

Always returns success.

true

Exit code:

Final Meaning

docker rm -f node-app-container || true

If container exists:

Remove it

If container doesn't exist:

Ignore error and continue

This prevents Jenkins from failing.

Manual Triggering

The simplest approach is manual execution.

Navigate to:

Jenkins Job
|
└── Build Now

Advantages:

Easy to understand
Good for learning
Disadvantages:
Requires human intervention
Not real CI/CD

Automatic Triggering

The goal of CI/CD is:

Code Push
    |
    v
Automatic Build
    |
    v
Automatic Deployment

This is where GitHub webhooks come into play.

Required Jenkins Plugins

Install the following Jenkins plugins before configuring the CI/CD pipeline:

1. Git Plugin

Enables Jenkins to interact with Git repositories.
Allows Jenkins to clone repositories, fetch changes, and checkout specific branches.
Required for integrating Jenkins with GitHub repositories.

2. GitHub Plugin

Provides integration between Jenkins and GitHub.
Allows Jenkins to communicate with GitHub repositories and services.
Supports GitHub-related features within Jenkins.

3. GitHub Integration Plugin

Enables GitHub webhook support.
Allows Jenkins to automatically trigger builds when code is pushed to GitHub.
Essential for implementing automated CI/CD workflows.

4. Pipeline Plugin

Enables support for Jenkins Pipelines.
Allows execution of Jenkinsfiles written in Declarative or Scripted Pipeline syntax.
Required for defining CI/CD workflows as code.

5. Credentials Plugin

Provides secure storage for sensitive information.
Allows storing:
- GitHub Personal Access Tokens (PATs)
- Usernames and passwords
- SSH keys
- API tokens
Prevents hardcoding secrets in Jenkins jobs and pipelines.

GitHub Authentication

When Jenkins needs to access a GitHub repository, authentication requirements depend on the repository type.

Public Repository

Can typically be cloned without authentication.

Example:

git clone https://github.com/username/repository.git

Private Repository

Requires authentication.
GitHub no longer supports account passwords for Git operations.
A Personal Access Token (PAT) must be used instead of a password.

Why Use a Personal Access Token (PAT)?

More secure than passwords.
Allows granular permission control.
Can be revoked without affecting your GitHub account password.
Recommended by GitHub for all Git operations requiring authentication.

Classic Personal Access Token

Older token type.

Advantages:

Simple
Easy to configure
Disadvantages:
Broad permissions
Less secure
Example scopes:

repo
workflow
admin:repo_hook

Fine-Grained Personal Access Token

Newer and recommended approach.

Advantages:

Repository-level access
Better security
Granular permissions Example:

Repository Access:
Only selected repositories

Permissions:

Contents: Read and Write
Metadata: Read
Webhooks: Read and Write

Fine-Grained vs Classic Token

Feature	Fine-Grained	Classic
Security	High	Lower
Repository Scope	Specific	Broad
Permission Control	Granular	Broad
Recommended	Yes	Legacy

For modern projects, prefer Fine-Grained tokens.

Adding GitHub Token to Jenkins

Navigate to:

Manage Jenkins
|
Credentials

Select:

Global Credentials

Choose:

Add Credentials

Kind:

Username with Password

Example:

Username: GitHub Username
Password: Personal Access Token

ID:

github-creds

Save.

Pipeline Script vs Pipeline Script from SCM

Many beginners get confused here.

Pipeline Script

Pipeline stored inside Jenkins UI.

Example:

pipeline {
    agent any
}

Advantages:

Quick setup
Disadvantages:
Not version controlled
Difficult to maintain

Pipeline Script from SCM

Pipeline stored in GitHub repository.

Repository structure:

project/
|
|-- Dockerfile
|-- package.json
|-- app.js
|-- Jenkinsfile

Jenkins automatically downloads Jenkinsfile.

Advantages:

Version controlled
Industry standard
Easier maintenance Recommended approach.

Configuring Pipeline from SCM

Create Jenkins job.

Select:

Pipeline

Under Definition:

Pipeline script from SCM

SCM:

Git

Repository URL:

https://github.com/username/repository.git

Branch:

*/main

Script Path:

Jenkinsfile

Save.

Creating GitHub Webhook

Navigate to:

GitHub Repository
|
Settings
|
Webhooks
|
Add Webhook

Payload URL:

http://JENKINS_PUBLIC_IP:8080/github-webhook/

Content Type:

application/json

Event:

Just the push event

Save webhook.

Configuring Jenkins Trigger

Open job configuration.

Under Build Triggers:

Select:

GitHub hook trigger for GITScm polling

Save.

Testing the Webhook

Push code:

git add .
git commit -m "testing webhook"
git push origin main

Expected flow:

GitHub Push
    |
    v
Webhook
    |
    v
Jenkins
    |
    v
Pipeline Starts

No manual click required.

Common Troubleshooting

Webhook Returns 404

Cause:

Wrong webhook URL

Correct:

http://SERVER-IP:8080/github-webhook/

Webhook Returns 403

Cause:

Authentication or security issue

Verify:

GitHub plugin
GitHub integration plugin

Webhook Returns 200 But Build Doesn't Start

Common cause:

Pipeline Script instead of Pipeline Script from SCM

Repository mapping issue

Dockerfile Not Found

Example:

unable to evaluate symlinks in Dockerfile path

Cause:

Wrong working directory.

Check:

pwd
ls -la

Verify Dockerfile location.

Permission Denied While Running Docker

Cause:

Jenkins not in docker group

Fix:

sudo usermod -aG docker jenkins
sudo systemctl restart jenkins

Final Jenkinsfile

pipeline {
    agent any

    stages {

        stage('Build Image') {
            steps {
                sh '''
                    docker build -t node-app .
                '''
            }
        }

        stage('Deploy') {
            steps {
                sh '''
                    docker rm -f node-app-container || true
                    docker run -d --name node-app-container -p 8000:8080 node-app
                '''
            }
        }
    }
}

Conclusion

A Jenkins pipeline can be triggered manually or automatically. Manual triggering is useful for learning and testing, but real CI/CD begins when code pushes automatically trigger builds and deployments.

The recommended production approach is:

Store the Jenkinsfile in GitHub.
Use Pipeline Script from SCM.
Configure GitHub credentials using a Personal Access Token.
Enable GitHub webhook integration.
Use Docker for packaging and deployment.
Remove old containers before deploying new versions. With this setup, every code push automatically builds a Docker image, deploys a fresh container, and updates the application without requiring any manual intervention.

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

Deploy Node.js & Express Application Using CI/CD (GitHub Actions + Docker)

Omkar Sharma — Sat, 11 Apr 2026 11:09:46 +0000

Quick Flow before deep dive

Developer pushes code to GitHub
GitHub Actions triggers pipeline
Pipeline connects to EC2 via SSH
Pulls latest code
Rebuilds Docker image
Runs container using Docker Compose
Application is live on EC2 public IP

Prerequisites

Node.js (v16+) and npm installed on local machine
Git installed on local machine and basic commands knowledge
Docker installed on local machine
GitHub account
AWS account
Basic cloud/devops knowledge

1. Create a Simple Node.js + Express Application

Initialize a Node.js project:

npm init

Install required dependencies:

npm install express
npm install @types/express --save-dev

2. Update `package.json`

Add the following:

{
  "name": "node-app",
  "version": "1.0.0",
  "type": "module",
  "scripts": {
    "start": "node index.js"
  }
}

3. Create `index.js`

import express from 'express';

const app = express();
const PORT = process.env.PORT || 8080;

app.get('/', (req, res) => {
  res.send('Hello from the server!');
});

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

4. Create a Dockerfile

FROM node:22-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 8080

CMD [ "node" , "index" ]

5. Build Docker Image

docker build -t node-app .

Explanation

docker build → Builds a Docker image
-t node-app → Tags the image with the name node-app
. → Refers to the current directory (build context)

Purpose of . (dot):
It tells Docker to use the current folder as the context, meaning all files in this directory are available to the Docker daemon during build.

6. Run the Container

Note: Before running below command make sure docker engine is running state........ for testing trying to run container before creating compose file after creating compose file we dont need to run container manually just compose up commmand will take care of everything

docker run -d -p 8080:8080 --rm node-app

Explanation

-d → Runs container in detached mode
-p 8080:8080 → Maps host port 8080 to container port 8080
--rm → Automatically removes the container when it stops

Purpose of --rm:

Prevents accumulation of stopped containers
Keeps the system clean
Useful for temporary/testing containers

7. Test Using curl

curl http://localhost:8080

curl is a command-line tool used to transfer data to and from a server using URLs.

Expected output:

Hello from the server!

8. Create Docker Compose File

Create docker-compose.yml:

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    restart: unless-stopped
    ports:
      - "8080:8080"

Run the Application

docker compose up -d

In browser test the application

Stop the Application

docker compose down

Verify Again

curl http://localhost:8080

9. Push Code to GitHub

Check my github repo for this task - omkarsharma2821

Initialize Git and push code:

git init
git add .
git commit -m "Initial commit"

git branch -M main

git remote add origin <your-repo-url>

git push -u origin main

10. Create an EC2 Instance (Ubuntu)

Once the instance is created, connect via SSH and run:

sudo apt update
sudo apt upgrade -y

Importance of Update & Upgrade

Updates package list from repositories
Installs latest security patches
Fixes vulnerabilities
Ensures system stability before installing new software

11. Install Docker & Docker Compose

Option 1: Install from Ubuntu Repository

sudo apt install docker.io -y
sudo apt install docker-compose -y

Option 2: Install from Official Docker Website

Recommended for:

Latest stable version
Better performance and features
Production environments

12. Run Application on EC2

Clone your repository:

git clone <your-repo-url>
cd <repo-name>

Run:

docker compose up -d

Test Application

curl http://<EC2-PUBLIC-IP>:8080

make sure you have allowed port no. 8080 in the instance security group to get the response.

13. Setup GitHub Actions (CI/CD)

Create workflow file:

.github/workflows/deploy.yml

Example:

name: Deploy Node App

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            set -e

            cd /home/ubuntu/node-app/Node.js-App-Deploy-Github-Action

            echo "Pulling latest code..."
            git pull origin main

            echo "Stopping existing containers..."
            docker compose down

            echo "Removing unused images..."
            docker image prune -f

            echo "Building and starting containers..."
            docker compose up -d --build

            echo "Deployment completed successfully"

**set -e** Stops execution if any command fails Prevents partial deployments **Cleanup Step** docker image prune -f Prevents disk space issues over time

14. Generate SSH Keys

On local machine:

ssh-keygen -t rsa -b 4096

Setup

Copy public key to EC2:

cat ~/.ssh/id_rsa.pub

Paste it into:

~/.ssh/authorized_keys

Add private key to GitHub:

Go to:

GitHub → Repo → Settings → Secrets → Actions

Add:

SSH_KEY - <your-key>
SSH_HOST - <public-ip of ec2>
SSH_USERNAME - <root or ubuntu>

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

Evolution of Deployment: From Bare Metal to Kubernetes (K8s Explained)

Omkar Sharma — Sat, 21 Mar 2026 12:03:04 +0000

Building an application is one challenge, but deploying it efficiently and scaling it for real-world users is an entirely different game.

Over the years, deployment strategies have evolved significantly—from physical servers to modern container orchestration tools like Kubernetes. In this blog, we will understand this journey step by step.

Step 1: Application Development

Let’s assume a developer builds an application using:

Node.js
Redis
PostgreSQL

The choice of tech stack depends on the developer’s comfort and project requirements.

Once the application is ready on the local machine, the next step is deployment.

Step 2: Traditional Deployment (Bare Metal Servers)

To make the application publicly accessible, the developer needs a server.

Options:

Buy a physical server (Bare Metal)
Rent a server from a third-party provider

Process:

Deploy application on server
Purchase a domain
Map domain to server’s static IP

Now the application is live 🎉

Challenges in Traditional Deployment

1. Environment Consistency

The application should behave the same in production as it does locally.

Famous problem: “It works on my machine”

2. Scaling Issues

As traffic grows, scaling becomes necessary.

Vertical Scaling:

Increase RAM (4GB → 16GB)
Increase CPU cores

Problems:

Expensive
Manual effort required
Limited scalability

Step 3: Cloud Computing Revolution

Cloud providers like:

AWS
Azure
GCP

transformed how applications are deployed.

Benefits:

No need to manage physical infrastructure
Deploy applications from anywhere
Ready-to-use services:
- Load Balancers
- CDN
- DNS (Route 53)
- Managed Databases (PostgreSQL, Redis)

Auto Scaling in Cloud

Cloud platforms introduced:

Auto Scaling Groups (ASG)
Policy-based scaling

Now scaling becomes:

Automatic
Faster
Cost-efficient

Still a Problem: Environment Replication

Even with cloud, consistency issues remain:

Local system → Windows
Production → Linux

Different OS and dependencies can break applications.

Step 4: Virtualization (Virtual Machines)

To solve consistency issues, Virtual Machines (VMs) were introduced.

How it works:

Each VM has:
- Its own OS
- Dependencies
- Application

Advantages:

Consistent environments

Disadvantages:

Heavy (includes full OS)
Slow startup
Resource intensive

Step 5: Containerization (Docker Era)

Containers improved virtualization.

Key Idea:

Package application + dependencies
No full OS required

Benefits:

Lightweight
Fast startup
Portable across environments
Consistent behavior everywhere

Challenge: Managing Containers at Scale

When applications grow:

Hundreds or thousands of containers are needed

Problems:

How to create containers?
How to restart failed ones?
How to manage networking?
How to scale automatically?

Manual management becomes impossible.

Step 6: Google’s Internal Solution – Borg

Google faced this challenge early due to massive traffic.

Solution:

Built Borg (around 2013–2014)

What Borg did:

Managed containers at scale
Automated scheduling and recovery
Handled failures efficiently

Step 7: Kubernetes (K8s)

Based on Borg’s experience, Google introduced Kubernetes.

What is Kubernetes?

Kubernetes is an open-source container orchestration platform that automates:

Deployment
Scaling
Management of containers

Why the Name Kubernetes?

Derived from Greek word meaning “Helmsman” (ship pilot)
Represents managing containers like steering a ship
Abbreviated as K8s (8 letters between K and S)

Final Comparison

Stage	Problem Solved	Limitation
Bare Metal	Basic hosting	Hard to scale
Cloud	Easy infrastructure	Env consistency issues
Virtual Machines	Consistent environments	Heavy & slow
Containers	Lightweight & portable	Hard to manage at scale
Kubernetes	Full orchestration	Learning curve

Conclusion

The journey from bare metal servers to Kubernetes shows how deployment has evolved to handle:

Scalability
Reliability
Efficiency

Today, Kubernetes has become the industry standard for managing containerized applications at scale.

SEO Keywords (for better reach)

Kubernetes explained, what is Kubernetes, container orchestration, Docker vs Kubernetes, evolution of deployment, cloud computing, DevOps tools, K8s tutorial, container management, microservices deployment

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

Complete Guide to Jenkins CI/CD Pipeline Setup on AWS EC2 (Ubuntu)

Omkar Sharma — Fri, 27 Feb 2026 10:56:26 +0000

Developers from the Application team write the code and push it to GitHub.

Now, instead of manually building and deploying the application, we use Jenkins as a CI/CD tool to automate the entire process.

Here’s how the flow works:

Developers commit and push the code to GitHub.
Jenkins is connected to the repository using a webhook. Whenever new code is pushed, Jenkins automatically triggers a pipeline.
Jenkins pulls the latest code and starts the build process.
During the build stage, Docker is used to create a Docker image from that code.
The Docker image is then pushed to a container registry (like Docker Hub or ECR).
In the deployment stage, Jenkins deploys that image either:

On an Amazon EC2 instance, or
On a Kubernetes cluster.

Once the application is live, monitoring tools like Prometheus are used to monitor application health, metrics, and performance.

In Simple Terms

Jenkins acts as the brain of the CI/CD pipeline.

It automates:

Code integration (Continuous Integration)
Testing and building
Docker image creation
Deployment to servers or Kubernetes
And ensures the whole process runs automatically whenever new code is pushed

This is the concept of CI/CD using Jenkins — automation from code commit to production deployment and monitoring, without manual intervention.

Setting Up Jenkins on AWS EC2 (Ubuntu)

Launch EC2 Instance

Launch an Ubuntu Server EC2 instance.
Instance type: Free Tier eligible (e.g., t2.micro).
Storage: 15 GB (Free Tier eligible).
Allow Port 80 in the Security Group (HTTP traffic).
(Recommended) Also allow Port 8080 for Jenkins default access.

What is Jenkins?

Jenkins is a self-contained, open source automation server which can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software.

Jenkins can be installed through native system packages, Docker, or even run standalone on any machine with a Java Runtime Environment (JRE) installed.

Installation Steps (Ubuntu/Debian)

Official Documentation:

https://www.jenkins.io/doc/book/installing/linux/#debianubuntu

Step 1: Update Packages

sudo apt update

Step 2: Install Java (Required Before Jenkins)

sudo apt install fontconfig openjdk-21-jre
java -version

On Debian/Ubuntu, it is strongly recommended to install Java before Jenkins. If Jenkins is installed first and Java is added later, the Jenkins service may fail to start with:

jenkins: failed to find a valid Java installation

Install Jenkins (Long Term Support Release)

sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key

echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc]" \
  https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

sudo apt update
sudo apt install jenkins

Check Jenkins Service Status

sudo systemctl status jenkins

If the service is active and running, Jenkins has been installed successfully.

To ensure Jenkins is active and running whenever you reboot or restart your server, check whether the service is enabled:

sudo systemctl is-enabled jenkins

If the output is enabled, Jenkins will start automatically on boot.
If the output is disabled, run the following command:

sudo systemctl enable jenkins

Access Jenkins in Browser

Go to the Public IP of your EC2 instance.
Open your browser and type:

http://<public-ip>:8080

You will see the Getting Started page.

Unlock Jenkins

You need to enter the initial admin password stored in the following file on your server:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Copy the password and paste it into the Jenkins setup page.

Install Plugins

After unlocking Jenkins, click on:

Install suggested plugins

Congratulations you have setup the Jenkins

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

Docker Compose - Multi Container Setup

Omkar Sharma — Sat, 14 Feb 2026 07:30:54 +0000

Docker Recap — Environment Replication and Container Management

so now we understand how docker works and how it solves the pain point of environment replication.

Quick Recap

you need a VM or any machine where docker is installed — either docker CLI or docker desktop
once docker is set up, you can start managing the lifecycle of your containers

Example Scenario — React Application Containerization

for example, in a company developers are working on a react application and they ask you:

“hey omkar, can you containerize or dockerize this application?”

Steps involved:

create a dockerfile
set up a call with the developers to understand the application requirements
choose the base image
run commands to install all the dependencies required for the application
copy the source code
expose the required ports
define the entrypoint

Step 2 — Build and Run the Application

create the docker image using:

  docker build -t <image-name> .

after building the image:
- push it to docker hub
- run the docker container from that image

Multi-Container Scenario — Docker Compose

now consider another scenario — what if you have an e-commerce application that requires a multi-container setup?

docker compose is used to manage multi-container applications
an e-commerce application usually follows a multi-service or microservice architecture
when working with multiple containers, we need to manage the execution order and dependencies between services

Example:

a payment or catalog service will not run properly without a database
docker compose helps define all services in one place
it manages how containers start and interact with each other

Docker Recap — Environment Replication and Container Management

so now we understand how docker works and how it solves the pain point of environment replication.

Quick Recap

you need a VM or any machine where docker is installed — either docker CLI or docker desktop
once docker is set up, you can start managing the lifecycle of your containers

Example Scenario — React Application Containerization

for example, in a company developers are working on a react application and they ask you:

“Hey omkar, can you containerize or dockerize this application?”

Steps involved:

create a dockerfile
set up a call with the developers to understand the application requirements
choose the base image
run commands to install all the dependencies required for the application
copy the source code
expose the required ports
define the entrypoint

Step 2 — Build and Run the Application

create the docker image using:

  docker build -t <image-name> .

after building the image:
- push it to docker hub
- run the docker container from that image

Multi-Container Scenario — Docker Compose

now consider another scenario — what if you have an e-commerce application that requires a multi-container setup?

docker compose is used to manage multi-container applications
an e-commerce application usually follows a multi-service or microservice architecture
when working with multiple containers, we need to manage the execution order and dependencies between services

Example:

a payment or catalog service will not run properly without a database
docker compose helps define all services in one place
it manages how containers start and interact with each other

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

Docker Basics : Problem Statement, Concepts & Commands

Omkar Sharma — Wed, 11 Feb 2026 06:48:46 +0000

Problem Statement - What Problem Does Docker Solve?

“Same code works on my machine but not on yours.”

Why does this happen?

Environment Replication Issues

Example Scenario

You worked on a project for the past 3 months.
During development, you installed multiple dependencies, libraries, and packages.
Now you want to onboard another developer.
You shared the source code and asked them to install dependencies with exact versions.

Challenges

Hard to remember specific versions over time.
New developers may install latest versions instead of required ones.
Latest versions may introduce breaking changes.
Suppose you put extra effort to remember the version and dependencies but what if they are using diff OS in that case if Windows CLI you are using will not work in MAC.
Example:
- Your project uses Node.js 14.x
- Another developer installs Node.js 18.x
- Result: Application may break or behave differently.

Docker solves this by standardizing environments so applications run the same everywhere.

Installation of Docker CLI & Docker Desktop

Download Docker Desktop from:
https://www.docker.com/products/docker-desktop/

Docker Desktop includes:

Docker CLI
Docker Engine
Docker Compose
GUI Dashboard

Understanding Images vs Containers

Docker Images

Preconfigured read-only templates.
Include:
- Base OS (optional)
- Runtime (Node, Python, Java, etc.)
- Dependencies
- Application setup
Used to create containers.
Images act as blueprints.

Docker Containers

Running instances of Docker Images.
Package application and dependencies together.
Lightweight compared to VMs.
Share host OS kernel (not a full OS like VMs).
Containers are running applications created from images.

Running Ubuntu Image in a Container

docker run -it <image_name>

Example:

docker run -it ubuntu

If the image is not available locally, Docker pulls it from Docker Hub automatically.

Useful Docker Commands

List Containers

docker container ls -a

List Images

docker image ls

Enter an Existing Running Container

docker exec -it <container_name> bash

Multiple Containers

Start a Container:

docker start <container_name>

Stop a Container:

docker stop <container_name>

Key Concept

Multiple containers can run from the same image.
Each container has an isolated environment.
Example:
- Create directory in Container 1
- Create directory in Container 2
- Both remain isolated from each other.

Port Mapping

docker run -it -p <local_machine_port>:<container_port> <image_name>

Example:

docker run -it -p 3000:3000 omkarsharma2821/omkar-node-app

Allows access to container services from local machine.

Environment Variables

docker run -it -e PORT=4000 -p 4000:4000 <image_name>

Used to configure applications dynamically inside containers.

Dockerization of a Node.js Application

Initialize Node Project:

npm init

Install Express:

npm install express

Build Docker Image:

docker build -t omkar-node-app .

As if now the img is avaialbel locally to push to hub.docker.com you need to run the following coommands

docker login

Tag your image with latest

docker tag <local_image_name>:latest <dockerhub_username>/<repo_name>:latest

Example

docker tag omkar-nodejs:latest omkarsharma2821/omkar-node-app:latest

Push to docker hub

docker push <dockerhub_username>/<repo_name>:latest

Example

docker push omkarsharma2821/omkar-node-app:latest

Summary

Docker ensures consistent environments across machines.
Images are templates.
Containers are running instances.
Supports isolated environments, easy onboarding, and scalable deployments.
Essential for modern development workflows and microservices architecture.

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

GIT: Version Control System-Complete Guide

Omkar Sharma — Sun, 25 Jan 2026 11:46:12 +0000

1. What is a Version Control System (VCS)?

Version control, also known as source control, is a system that helps track and manage changes made to software code over time.

Why is it required?

As a project grows, code is continuously updated—new features are added, bugs are fixed, and existing logic is modified. In such cases, it becomes difficult to answer questions like:

Who made a specific change?
When was the change made?
Why was the change introduced?
How can we revert to an older stable version?

A Version Control System solves this by maintaining a complete timeline (history) of code changes, making collaboration, tracking, and rollback easy and reliable.

Famous VCS Tools

Git (Most popular)
Apache Subversion (SVN)
Piper (Used internally by Google)

2. Introduction to Git VCS

Download Git from the official website:

https://git-scm.com/install/

Verify Installation

git
git -v

If Git is installed correctly, it will display the installed version.

What is Git?

Git is a distributed version control system that allows multiple developers to work on the same project simultaneously while keeping track of all changes.

Why Git Configuration is Required?

In an organization, multiple developers work on the same codebase. Git uses global configuration (username and email) to identify who made which changes in the commit history.

Setting Up Git Global Configuration

First let's create a folder where we keep our source code and config the user name and email to it.

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

3. Version Controlling with Git

Initializing a Git Project

By default, a folder is not Git-enabled, and Git does not track it.

To enable Git tracking:

git init

This initializes a Git repository in the folder.

Tracking Files

After initialization, files are still untracked
You must explicitly add files to Git

git add index.js
git add <File Path Name>

Once added, Git starts tracking changes to the file.

Viewing Changes

git diff

Shows differences between the working directory and the staging area.

Add Multiple Files

git add .

Adds all modified and untracked files at once.

By default, Git does not track any folder or file on your local machine unless you initialize it and add files manually.

Removing Files from VCS

git rm <FILE_PATH>

Introduction to Commits

What is a Commit?

A commit is a snapshot of the staged changes at a specific point in time.

Committing Files

git commit -m "commit message"

Staging Area

The staging area is an intermediate step where files are prepared before committing.

Viewing Commit History

git log
git log --oneline
git diff <to see the changes in code file>

git show <commit id> to see the changes made in particular commit

git blame <File Name> to see the changes made in particular file by whom

Reverting Back

git reset --hard <commit id>

here we are moving our head so we will loose the below commits

whenever we are saying VCS we should have something when we do any thing wrong we can revert back.....so Git allows reverting commits to return to a previous stable state when required.

In this feature we use the concept of Linked List head points to the latest commit.....so we just point our head where we want to revert.

git revert <commit id>

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

A Clear Introduction to DevOps and Its Importance

Omkar Sharma — Wed, 14 Jan 2026 18:23:40 +0000

What is DevOps?

DevOps is a culture and set of practices that improve an organization’s ability to deliver projects and applications efficiently.

DevOps is not only about CI/CD .... it involves many other vital aspects of a project, such as:

Improving delivery
Automation
Enhancing Quality
Monitoring (Observability)
Continuous Testing

PS: DevOps is the process of improving application delivery by automating tasks, increasing quality, and ensuring continuous monitoring and continuous testing.

Why DevOps?

As shown in the diagram earlier, all these activities were traditionally manual. Multiple teams worked in silos, and it often took many days to release a project or application. DevOps streamlines and accelerates this entire process.

How to Introduce Yourself in DevOps

“Hi, I am working as a DevOps Engineer with X years of experience. In my previous company, I worked on improving application delivery, enhancing quality, and implementing observability and monitoring practices.”

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

AWS Lambda: The Serverless Engine Powering Cloud Automation

Omkar Sharma — Mon, 12 Jan 2026 16:56:12 +0000

AWS Lambda is one of the most powerful and popular services in the AWS ecosystem. It allows you to run application logic without managing servers, making it ideal for automation, event-driven workflows, and lightweight backend tasks. With Lambda, you simply upload your code and define a trigger—AWS handles provisioning, scaling, and execution automatically.

What Is AWS Lambda?

AWS Lambda is a serverless compute service that executes your code in response to events. It supports languages like Python, Node.js, Java, Go, and more. There is no need to create or manage EC2 servers. Instead, Lambda runs your function in a fully managed environment, scales instantly, and charges you only for the compute time consumed.

Key Characteristics

No servers to configure or maintain
Automatic scaling from 0 to thousands of requests
Pay-per-use billing model
Deep integration with AWS services

Why Is AWS Lambda So Popular?

1. Completely Serverless

You don’t need to provision, patch, or maintain any infrastructure. Lambda removes the operational burden from developers and cloud teams.

2. Automatic, Instant Scaling

Lambda scales based on event load. Whether 1 or 1,000 requests, it adjusts automatically without any configuration.

3. Highly Cost-Effective

Since Lambda charges only when your function executes, there's no cost for idle time. This makes it ideal for workloads with unpredictable volume.

4. Event-Driven Architecture

Lambda works natively with services like:

S3
DynamoDB
CloudWatch
EventBridge
SNS / SQS
API Gateway

This makes it perfect for automation, integrations, and reactive systems.

5. Multi-Language Support

Lambda supports Python, Node.js, Java, Go, .NET, Ruby, and custom runtimes—giving teams flexibility to choose the best language.

What Problem Does AWS Lambda Solve?

Traditionally, even small tasks required running dedicated servers—leading to:

Costly idle infrastructure
Manual scaling
OS patching and maintenance
Complex automation scripts

Lambda solves this by offering:

Serverless compute on demand
Automatic resource management
Event-based execution
Reduced operational workload

It empowers developers to focus purely on logic instead of infrastructure.

Three Real-World Use Cases of AWS Lambda

Below are three practical AWS Lambda use cases (without code), based on your requirement:

1. Automatically Delete Historical Snapshots

Organizations create regular EBS snapshots but often forget to delete old ones, increasing storage cost over time.

How Lambda Helps

A scheduled EventBridge rule triggers your Lambda daily.
Lambda fetches all EBS snapshots.
It identifies snapshots older than a set retention period.
It deletes those snapshots automatically.

Benefits

Saves storage cost
Ensures retention compliance
Eliminates manual cleanup

import boto3

ec2 = boto3.client('ec2')

def lambda_handler(event, context):
    # Describe all snapshots owned by you
    snapshots = ec2.describe_snapshots(OwnerIds=['self'])['Snapshots']

    for snap in snapshots:
        snap_id = snap['SnapshotId']
        print(f"Deleting Snapshot: {snap_id}")
        try:
            ec2.delete_snapshot(SnapshotId=snap_id)
        except Exception as e:
            print(f"Error deleting {snap_id}: {e}")

    return {
        "status": "Completed",
        "deleted_snapshots": len(snapshots)
    }

2. Delete Unused (Available) EBS Volumes

After EC2 instances are terminated, their EBS volumes often remain in the "available" state and keep incurring cost.

How Lambda Helps

A scheduled Lambda function lists all EBS volumes.
It identifies volumes in "available" state.
Lambda deletes these unused volumes.

Benefits

Reduces wasted storage cost
Improves cloud hygiene
Automates cleanup without manual checks

import boto3

ec2 = boto3.client('ec2')

def lambda_handler(event, context):
    # Find volumes that are 'available' (i.e., NOT attached)
    volumes = ec2.describe_volumes(
        Filters=[{'Name': 'status', 'Values': ['available']}]
    )['Volumes']

    for vol in volumes:
        vol_id = vol['VolumeId']
        print(f"Deleting Unattached Volume: {vol_id}")
        try:
            ec2.delete_volume(VolumeId=vol_id)
        except Exception as e:
            print(f"Error deleting {vol_id}: {e}")

    return {
        "status": "Completed",
        "deleted_volumes": len(volumes)
    }

3. Start EC2 Instances That Are in Stopped State

Some environments require EC2 instances to automatically start during working hours or operational windows and often during patching time.

How Lambda Helps

A scheduled trigger (e.g., daily at 9 AM) runs the Lambda function.
Lambda checks for EC2 instances in "stopped" state.
It starts them automatically based on tag filters or instance IDs.

Benefits

Ensures required servers start on time
Reduces manual effort
Supports DevOps automation

import boto3

ec2 = boto3.client('ec2')

def lambda_handler(event, context):
    # Find all instances that are stopped
    response = ec2.describe_instances(
        Filters=[
            {'Name': 'instance-state-name', 'Values': ['stopped']}
        ]
    )

    stopped_instances = []

    for reservation in response['Reservations']:
        for instance in reservation['Instances']:
            stopped_instances.append(instance['InstanceId'])

    if stopped_instances:
        print(f"Starting instances: {stopped_instances}")
        ec2.start_instances(InstanceIds=stopped_instances)
    else:
        print("No stopped instances found")

    return {
        "action": "start_instances",
        "instances": stopped_instances
    }

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub

Cloud Computing – Complete Overview

Omkar Sharma — Sat, 20 Dec 2025 08:09:19 +0000

What Is Cloud Computing?

Cloud computing is the practice of renting computing resources such as servers, storage, networking, databases, and software from a third-party provider over the internet. Instead of owning and maintaining physical hardware, users access these resources on demand and pay only for what they use.

In simple terms, cloud computing allows you to store data and run applications on remote servers hosted over the internet rather than on local machines or on-premises infrastructure.

Key Features of Cloud Computing

Scalability

Ability to allocate and deallocate resources based on demand.
Elasticity

Automatic scaling of resources up or down as workload changes.
High Availability

Ensures minimal downtime by distributing services across multiple systems.
Agility

Rapid provisioning of resources to respond quickly to business needs.
Fault Tolerance

Capability of systems to continue operating even when components fail.
Disaster Recovery

Ability to recover data and applications after unexpected events.
Consumption-Based Model (Pay-as-You-Go)

Users pay only for the resources they consume.

Cloud Service Models

Infrastructure as a Service (IaaS)

Most responsibility lies with the consumer.
The provider manages networking, storage, servers, and virtualization.
Common use cases:
- Test and development
- Lift-and-shift migration
- Virtual machines
Examples:
- Azure Virtual Machines
- AWS EC2

Platform as a Service (PaaS)

Responsibilities are shared between provider and consumer.
The provider manages OS, runtime, middleware, and infrastructure.
The consumer focuses on application code and data.
Use cases:
- Application development frameworks
Example:
- Heroku

Software as a Service (SaaS)

Most responsibility lies with the provider.
Users access applications directly over the internet.
Examples:
- Gmail
- Outlook
- OneDrive
- Microsoft 365

Shared Responsibility Model

The shared responsibility model defines how security and management responsibilities are divided between the cloud provider and the customer.

The cloud provider is responsible for securing the cloud infrastructure.
The customer is responsible for securing data, access, and configurations, depending on the service model.

Cloud Deployment Models

Private Cloud

Offers greater control and security.
Higher cost and requires skilled technical teams.

Public Cloud

Fully owned and managed by the cloud provider.
No large initial investment.

Hybrid Cloud

Combination of private and public clouds.
Sensitive workloads remain in private clouds while leveraging public cloud flexibility.

Multi-Cloud

Uses multiple cloud providers.
Leverages different services and features from different clouds.

API (Application Programming Interface)

An API is a set of rules that allows software applications to communicate with each other.

In cloud computing, APIs provide a programmatic way to interact with cloud services such as:

Compute
Storage
Databases
Artificial Intelligence services

Scaling in Cloud Computing

Vertical Scaling

Increasing or decreasing the capacity of a resource.
Example: Adding more CPU or RAM to a virtual machine.

Horizontal Scaling

Adding or removing multiple instances of resources.
Commonly used in high-traffic applications.

Virtualization

Virtualization is the process of creating virtual versions of physical resources such as servers, operating systems, storage, and networks.

Key points:

Enables running multiple operating systems on a single physical machine.
Improves resource utilization by logically dividing servers.
Allows OSs like Windows and Linux to run on the same hardware.

Hypervisor

A hypervisor enables virtualization by:

Simulating complete machines with their own operating systems.
Isolating multiple virtual machines on a single physical host.
Allowing multiple OSs to run independently on the same hardware.

Containerization

Containerization is a lightweight alternative to virtualization and is best suited for microservices architectures.

Key characteristics:

Containers package applications with all required dependencies.
They share the host OS kernel.
No separate OS is required for each container.
Solves the “works on my machine” problem.

Containers are ideal for scenarios such as:

Full-stack applications with high backend load
Microservices-based architectures

Note: Containers cannot run a completely different operating system since they rely on the host OS kernel.

Datacenters, Regions, and Availability Zones

Datacenter

A physical facility that houses servers, storage, and networking equipment.

Region

A geographical area containing multiple datacenters to ensure resiliency and reliability for business-critical workloads.

Availability Zones (Azure)

Physically separate datacenters within a region.
Azure regions contain a minimum of three availability zones.
If one zone fails, the others continue operating.

Azure-Specific Concepts

Management Groups

Used to organize subscriptions.
Apply policies, permissions, and restrictions at scale.

Azure Virtual Machines

Provide Infrastructure as a Service (IaaS).

VM Scale Sets

Centrally manage and scale large numbers of identical virtual machines.

Availability Sets

Improve application uptime by distributing VMs across fault and update domains.

Virtual Machines vs Containers

Virtual Machines

Reduce cost compared to physical hardware.
Each VM runs a single operating system.
Heavier than containers due to OS overhead.

Containers

Lightweight and fast.
Allow multiple application instances on a single host.
Package all application dependencies.
Remove OS-level dependency issues.

Summary

Cloud computing enables organizations to build, deploy, and scale applications efficiently by providing computing resources as services. It offers scalability, flexibility, high availability, and cost efficiency while eliminating the need for heavy upfront infrastructure investments.

✍️ Author: Omkar Sharma

📬 Feel free to connect on LinkedIn or explore more on GitHub