DEV Community: Md Mohiuddin

Pull Requests, Code Reviews & Git Rebase

Md Mohiuddin — Sun, 09 Aug 2026 17:54:48 +0000

If you've already learned Git commits, branching, and merging, you've mastered the mechanics of version control. But knowing Git alone doesn't make you effective on a real engineering team.

In this article, we'll cover:

What Pull Requests (PRs) actually are
How professional code reviews work
Why .gitignore is essential
The dangers of committing secrets
When to use git merge vs git rebase

These are the practices that transform a personal project into a professional software project.

Why This Matters

Imagine you're building a feature for a production application.

You create a branch, write code, test it, and everything works.

Should you push directly to main?

In most professional teams, the answer is no.

Instead, your code goes through a review process where:

Other developers inspect your changes
Automated tests run
Discussions happen around implementation decisions
Quality checks prevent bugs from reaching production

That process starts with a Pull Request.

Understanding Pull Requests

A Pull Request (PR) is not a Git feature.

It is a feature provided by platforms like GitHub, GitLab, and Bitbucket.

A PR is essentially a request that says:

"I've completed work on this branch. Please review it and merge it into the target branch."

What a Pull Request Contains

A good PR provides much more than code.

The Diff

A visual representation of every change introduced by the branch.

You'll see:

Added lines
Removed lines
Modified files

This allows reviewers to inspect exactly what changed.

Description and Context

A PR should explain:

What changed
Why it changed
How it was tested

Remember:

The code shows what changed. The PR description explains why it changed.

Review Discussion

Reviewers can:

Comment on specific lines
Ask questions
Suggest improvements
Request changes

This creates a permanent record of engineering decisions.

Automated Checks

Most modern teams connect CI/CD pipelines to Pull Requests.

Common checks include:

Unit tests
Integration tests
Linting
Security scans
Build verification

If these checks fail, the PR usually cannot be merged.

Merge Controls

Once reviews are complete and checks pass, the PR can be merged.

Behind the scenes, the platform performs the merge operation for you.

Why Pull Requests Exist

Quality Control

Fresh eyes catch bugs.

Reviewers often identify:

Edge cases
Logic flaws
Performance concerns
Security issues

before users ever encounter them.

Knowledge Sharing

Code reviews help teams stay informed about:

New features
Architecture decisions
Business rules
Coding standards

Reviewing code is one of the fastest ways to learn a codebase.

Historical Context

Months later, someone may ask:

Why was this implemented this way?

The answer often lives in the PR discussion.

Automation Gateway

PRs provide a natural checkpoint for CI/CD pipelines.

Before code reaches production:

Tests run
Builds run
Security checks run

This reduces deployment risk significantly.

Creating a Pull Request

Step 1: Create a Feature Branch

git switch -c feature/add-backup-script

Step 2: Make Changes and Commit

git add backup.sh

git commit -m "Add automated backup script with cron scheduling"

Step 3: Push the Branch

git push -u origin feature/add-backup-script

The -u flag links your local branch to the remote branch so future pushes can simply use:

git push

Step 4: Open the Pull Request

On GitHub:

Click Compare & Pull Request
Select the target branch (main)
Select your feature branch
Add a title
Write a meaningful description
Submit the PR

Writing Better PR Descriptions

A strong PR description answers four questions:

What changed?

Brief summary of the implementation.

Why was it needed?

Business or technical motivation.

How was it tested?

Evidence that the change works.

What should reviewers focus on?

Any area that may need extra attention.

Code Reviews: How Professionals Review Code

Code review is not about proving someone wrong.

It's about improving the software.

Focus on the Code, Not the Person

Avoid personal criticism.

Instead of:

You wrote this incorrectly.

Prefer:

This function could be simplified by...

Separate Requirements from Suggestions

Many teams use:

Nit:

for non-blocking suggestions.

Ask Questions

Instead of making assumptions, ask:

What happens if this input is empty?

Questions encourage discussion and often reveal hidden edge cases.

Receiving Review Feedback

Every developer receives feedback.

Good engineers:

Respond to comments
Explain decisions
Make improvements
Discuss disagreements respectfully

Code review is a conversation, not a battle.

Understanding .gitignore

One of the most important files in any repository is:

.gitignore

This file tells Git:

Never track these files.

Why .gitignore Matters

Without it, developers accidentally commit:

Secrets
Build artifacts
Dependency folders
Personal editor settings
Operating system files

Example .gitignore

# Secrets
*.pem
*.key
.env
id_rsa
id_ed25519

# Logs
*.log
logs/

# Dependencies
node_modules/
__pycache__/
venv/

# IDE Files
.vscode/
.idea/

# Terraform
*.tfstate
*.tfstate.backup
.terraform/

Never Commit Secrets

This is one of the most important rules in software engineering.

Why Deleting Later Doesn't Work

If a secret appears in Git history, it remains in history even after being removed from later commits.

Anyone with repository access can still retrieve it.

What Happens When Secrets Leak?

Automated bots constantly scan public repositories for:

API keys
Database credentials
AWS access keys
Tokens
Private keys

Often within minutes of a push.

Prevention Best Practices

Create .gitignore before starting a project
Use environment variables
Never hardcode credentials
Review changes before committing

Always run:

git status

and ideally:

git diff --staged

before every commit.

Git Rebase: An Alternative to Merge

Most developers learn merging first.

But Git also provides:

git rebase

Example

git switch feature/my-work

git rebase main

This replays your commits on top of the latest version of main.

Before Rebase

main:      A --- B --- C
                         \
feature:                  D --- E

After Rebase

main:      A --- B --- C
                         \
feature:                   D' --- E'

Git creates entirely new commits with new hashes.

Merge vs Rebase

Merge	Rebase
Preserves exact history	Creates linear history
Adds merge commits	Avoids merge commits
Safe for shared branches	Rewrites history
Great for team collaboration	Great for cleaning personal branches

The Golden Rule of Rebase

Never rebase a branch that other developers are already using.

A simple rule:

Rebase your own branches. Merge shared branches.

Final Thoughts

Learning Git commands is only the beginning.

Professional software development requires:

Pull Requests
Code Reviews
Secure Git practices
Proper .gitignore usage
Understanding when to merge and when to rebase

These skills help teams collaborate effectively, maintain quality, and deploy software with confidence.

Great developers don't just write code. They create systems that make collaboration, quality, and safety easier for everyone on the team.

Git Branching & Merging: The Foundation of Team Collaboration in Git

Md Mohiuddin — Thu, 06 Aug 2026 16:57:04 +0000

Git becomes truly powerful when multiple developers can work on different features at the same time without interfering with each other's work. That's exactly what branching and merging solve.

In this article, we'll explore how Git branches work, how to merge changes safely, resolve conflicts, collaborate through GitHub, and understand the workflow used by modern development teams.

Why Branching Matters

Imagine a team working on a web application:

One developer is building a login page.
Another is fixing a payment bug.
A third is improving performance.

If everyone worked directly on the same branch, changes would constantly collide, making development chaotic and risky.

Git branching allows developers to work independently in isolated environments and merge their changes only when they're ready.

This is the foundation of modern software collaboration.

What Is a Git Branch?

Many beginners think a branch is a complete copy of a project.

It isn't.

A Git branch is simply a lightweight pointer to a commit.

Consider a project history:

A --- B --- C
              ^
            main

Here, main points to the latest commit (C).

When you create a new branch:

A --- B --- C
              ^
            main
              ^
        feature-login

Git creates another pointer.

No files are copied.

No duplicate project is created.

Just another reference to the same commit.

How Branches Grow

Once you switch to the new branch and start making commits:

main:    A --- B --- C
                        ^
                      main

feature-login:
                    D --- E
                          ^
                    feature-login

Only the feature branch moves forward.

The main branch remains unchanged.

This allows you to experiment, develop features, and fix bugs without affecting the stable codebase.

Why Git Branches Are So Fast

Since a branch is only a pointer:

Creating a branch takes milliseconds.
Switching branches is extremely fast.
Large repositories don't become slower when creating branches.

Unlike older version control systems where branching was expensive, Git encourages creating branches frequently.

Creating a branch for every feature or bug fix is considered a best practice.

Creating and Switching Branches

View Existing Branches

git branch

Output:

* main

The * indicates the current branch.

Create a New Branch

git branch feature-login

This creates the branch but does not switch to it.

Switch to a Branch

git switch feature-login

Or:

git checkout feature-login

Create and Switch in One Command

git switch -c feature-login

Older equivalent:

git checkout -b feature-login

Delete a Branch

Safe delete:

git branch -d feature-login

Force delete:

git branch -D feature-login

Use force deletion carefully because it can remove unmerged work.

Branch Naming Best Practices

Professional teams typically follow naming conventions.

Examples:

feature/PROJ-123-user-authentication

bugfix/PROJ-456-fix-login-error

hotfix/critical-payment-issue

Benefits:

Easy to understand purpose
Connected to Jira tickets
Easier code reviews
Better repository organization

Understanding Git Merge

Once your work is complete, you'll want to bring it back into main.

First switch to the target branch:

git switch main

Then merge:

git merge feature-login

Git now combines both histories.

Fast-Forward Merge

This happens when no new commits exist on main.

Before merge:

main:
A --- B --- C

feature:
A --- B --- C --- D --- E

After merge:

A --- B --- C --- D --- E
                              ^
                      main & feature

Git simply moves the main pointer forward.

No special merge commit is created.

This is called a Fast-Forward Merge.

Three-Way Merge

Real projects usually look like this:

main:
A --- B --- C

feature:
      \
       D --- E

While you were working, someone else added commits to main.

Git must now combine both histories.

Result:

A --- B --- C ----------- M
          \             /
           D --- E ----

M is a merge commit.

It contains two parent commits:

One from main
One from feature

This process is called a Three-Way Merge.

What Is a Merge Conflict?

Sometimes Git can't determine which change should win.

Example:

Main Branch

Welcome to our application

Feature Branch

Welcome to our awesome application

Both modified the same line.

Git stops and asks for help.

This is called a Merge Conflict.

What a Conflict Looks Like

Git inserts markers directly into the file:

<<<<<<< HEAD
Welcome to our application
=======
Welcome to our awesome application
>>>>>>> feature-login

Understanding the Markers

<<<<<<< HEAD

Current branch version.

=======

Separator.

>>>>>>> feature-login

Incoming branch version.

Resolving Merge Conflicts

Step 1: Open the File

Review both versions.

Step 2: Decide the Final Content

Example:

Welcome to our awesome application

Step 3: Remove Conflict Markers

Delete:

<<<<<<<
=======
>>>>>>>

Step 4: Stage the Resolved File

git add app.txt

Step 5: Complete the Merge

git commit

Git automatically generates a merge message.

Don't Fear Merge Conflicts

Many beginners panic when they see conflicts.

Don't.

Merge conflicts are:

Normal
Expected
Common in every team

Even senior engineers resolve conflicts regularly.

The skill isn't avoiding them.

The skill is understanding and resolving them confidently.

Understanding Remote Repositories

Everything so far has been local.

To collaborate, we use remote repositories hosted on platforms like:

GitHub
GitLab
Bitbucket

The most common remote name is:

origin

Pushing Changes to GitHub

Upload local commits:

git push origin main

This sends your local commits to GitHub.

Pulling Changes From GitHub

Download and merge changes:

git pull origin main

This keeps your local branch up to date.

What `git pull` Actually Does

Many developers use git pull daily without knowing what it really does.

Internally:

git pull
=
git fetch
+
git merge

Fetch

Downloads new commits.

git fetch

No files are changed.

No merge occurs.

Git simply updates its knowledge of the remote repository.

Merge

After fetching:

git merge

Git combines the changes into your current branch.

Why Pull Before Push?

Imagine:

You create new commits.
A teammate pushes changes first.
You try pushing.

Git rejects it:

! [rejected] main -> main (fetch first)

Git is protecting shared history.

Solution:

git pull origin main

Resolve conflicts if necessary.

Then:

git push origin main

Understanding GitHub Flow

GitHub Flow is one of the most widely used collaboration workflows.

It is simple, lightweight, and works perfectly with CI/CD pipelines.

Step 1: Create a Branch

git switch -c feature-login

Step 2: Make Commits

Example:

git add .
git commit -m "feat: add login page"

Step 3: Push the Branch

git push origin feature-login

This backs up your work and makes it visible to teammates.

Step 4: Open a Pull Request (PR)

A Pull Request is a request to merge your branch into main.

It allows:

Discussion
Review
Feedback
Collaboration

Step 5: Code Review

Teammates review:

Code quality
Architecture
Bugs
Security concerns

Suggestions are discussed before merging.

Step 6: Automated Checks Run

Modern CI/CD pipelines automatically run:

Unit tests
Linting
Security scans
Build verification

Only passing code can be merged.

Step 7: Merge Into Main

Once approved:

feature-login → main

The changes become part of the main codebase.

Step 8: Deploy

Many organizations automatically deploy after merging into main.

Merge → CI/CD Pipeline → Deployment

Step 9: Delete the Branch

After merging:

git branch -d feature-login

The branch has served its purpose.

Visualizing GitHub Flow

main:
A --- B ----------------------- M
          \                   /
           C --- D --- E ----
                feature-login

Workflow:

Create branch
Commit changes
Push branch
Open PR
Review
Run automated checks
Merge
Deploy
Delete branch

Why GitHub Flow Is So Popular

Simplicity

Only one long-lived branch:

main

Everything else is temporary.

CI/CD Friendly

Every Pull Request becomes a checkpoint for:

Testing
Validation
Security scanning

Encourages Code Reviews

Changes reach production only after another engineer reviews them.

This improves:

Quality
Knowledge sharing
Team collaboration

Key Takeaways

A branch is simply a movable pointer to a commit.
Branches allow isolated development without affecting main.
Merging combines work from multiple branches.
Fast-forward merges occur when histories haven't diverged.
Three-way merges create a merge commit when histories differ.
Merge conflicts happen when Git can't decide between overlapping changes.
git pull = git fetch + git merge.
git push shares your commits with a remote repository.
GitHub Flow is the modern workflow used by most teams and integrates naturally with CI/CD.

Master branching and merging, and you've learned the workflow that powers nearly every professional software team in the world.

Happy Coding! 🚀

Git Fundamentals: The Foundation of Modern DevOps

Md Mohiuddin — Wed, 05 Aug 2026 15:45:38 +0000

From CI/CD pipelines and Infrastructure as Code to Kubernetes deployments and application releases, almost every automation workflow begins with a change in a Git repository. A commit, push, merge, or tag can trigger an entire deployment pipeline automatically.

Understanding Git isn't just about version control—it's about understanding the foundation that modern software delivery is built on.

Why Git Matters in DevOps

Think about the Software Development Life Cycle (SDLC):

Plan → Code → Build → Test → Release → Deploy → Operate → Monitor

Git sits at the center of this workflow.

When code changes are committed and pushed:

CI/CD pipelines automatically start
Tests run automatically
Docker images get built
Deployments can be triggered
Infrastructure changes can be tracked
Teams can collaborate safely

In many organizations, Git becomes the single source of truth for both application code and infrastructure configuration.

What Is Git?

Git is a Distributed Version Control System (DVCS) that tracks changes to files over time.

It allows developers to:

Track project history
Revert mistakes
Collaborate with teams
Create isolated branches
Maintain a complete record of changes

Unlike older centralized systems, Git is distributed.

What Does "Distributed" Mean?

Every copy of a Git repository contains the complete project history.

This means:

You can work offline
You can create commits without internet access
Every clone acts as a backup
There is no single point of failure

When you clone a repository, you're not just downloading files—you're downloading the entire project history.

This is why platforms like GitHub, GitLab, and Bitbucket are not Git itself.

Git is the version control system.

GitHub and similar platforms simply provide a shared remote location where teams can collaborate.

Understanding Git's Snapshot Model

One of the most misunderstood concepts in Git is how it stores history.

Many beginners assume Git stores only the differences between files.

That's not how Git works.

Git Stores Snapshots

Every commit represents a complete snapshot of the project at a specific moment.

Commit A → Commit B → Commit C

Snapshot   Snapshot   Snapshot
of all     of all     of all
files      files      files

Think of each commit as a photograph of your project.

When you return to a previous commit, Git simply restores that snapshot.

This design makes operations like:

Switching branches
Viewing history
Restoring previous versions

extremely fast and efficient.

Behind the scenes, Git avoids storing duplicate file data when files haven't changed, making storage efficient while maintaining the snapshot model.

The Three Areas of a Git Project

To understand Git properly, you need to understand its three working areas.

Working Directory
        |
     git add
        ↓
Staging Area
        |
   git commit
        ↓
Repository

1. Working Directory

This is where you actively edit files.

Any changes made here are considered unstaged changes.

2. Staging Area

The staging area acts as a preparation zone.

You decide exactly which changes should be included in the next commit.

This allows you to create clean and focused commits instead of committing everything at once.

3. Repository

The repository contains committed snapshots and project history.

Once changes are committed, they become part of Git's permanent history.

Creating a Git Repository

To start tracking a project with Git:

git init

This command creates a hidden .git directory.

The .git folder stores:

Commit history
Branch information
Configuration
Repository metadata

Without the .git folder, Git history does not exist.

Configure Your Identity

Git records who created each commit.

Set your identity once per machine:

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

git status: Your Most Important Command

If there's one Git command you'll use constantly, it's:

git status

This command tells you:

Which files have changed
Which files are staged
Which files are untracked
What will happen next

Whenever you're unsure about your repository's state:

git status

is the first command to run.

Staging Changes with git add

Before creating a commit, changes must be staged.

Stage a Single File

git add file.txt

Stage Multiple Files

git add file1.txt file2.txt

Stage Everything

git add .

Interactive Staging

git add -p

This allows you to choose specific portions of a file to stage.

Be Careful with git add .

While convenient, git add . stages everything.

Always verify what's staged:

git status

before creating a commit.

Creating Snapshots with git commit

Once changes are staged:

git commit -m "Add user authentication endpoint"

This creates a permanent snapshot of the project.

The -m flag allows you to write the commit message directly in the command.

Without it, Git opens your default text editor.

Writing Better Commit Messages

Good commit messages save time for both you and your team.

Avoid Messages Like:

fix
update
changes
test
final
final-final

Prefer Messages Like:

feat: add user authentication endpoint

fix: resolve null pointer exception in payment service

docs: update installation guide

refactor: simplify database connection logic

test: add unit tests for user service

chore: upgrade nginx package version

ci: add GitHub Actions deployment workflow

This makes history easier to read and understand.

Viewing Project History with git log

Git provides several ways to inspect history.

Full History

git log

Displays:

Commit hash
Author
Date
Commit message

Compact View

git log --oneline

Example:

a1b2c3d Add authentication
e4f5g6h Fix API validation
i7j8k9l Initial project setup

Visual Branch Graph

git log --oneline --graph

Useful when working with multiple branches.

Show Actual Code Changes

git log -p

Displays the content changes for each commit.

Filter by Author

git log --author="John"

Filter by File

git log -- filename.txt

Shows only commits that modified a specific file.

Understanding Commit Hashes

Every commit has a unique identifier called a commit hash.

Example:

a1b2c3d4e5f67890abcdef1234567890

The hash is generated from:

Commit content
Metadata
Parent commit information

Even the smallest change creates a completely different hash.

In practice, you'll usually use only the first few characters:

git checkout a1b2c3d

Git can usually identify the correct commit from a short unique prefix.

Key Takeaways

Git is much more than a tool for saving code.

It is:

The foundation of CI/CD pipelines
The source of truth for modern infrastructure
The backbone of collaborative software development
The trigger behind most DevOps automation

Before learning branches, pull requests, Docker, Kubernetes, or Terraform, it's important to understand how Git stores history and manages changes.

Master these fundamentals, and every DevOps tool that follows will make much more sense.

Happy learning! 🚀

Virtualization & Containers — Understanding the Technology That Made Cloud and Docker Possible

Md Mohiuddin — Tue, 04 Aug 2026 16:04:30 +0000

Before diving into Git, Docker, and Kubernetes, it's worth understanding the technology that made modern cloud computing possible: Virtualization.

More importantly, understanding virtualization makes it much easier to understand why containers became so popular and why Docker transformed modern software deployment.

Why This Topic Matters

Virtualization sits between traditional infrastructure and modern containerized environments.

Without virtualization:

Cloud computing wouldn't exist in its current form
AWS EC2 instances wouldn't be possible
Running multiple servers on shared hardware would be difficult and expensive

Understanding virtualization helps answer a fundamental question:

Why did the industry move from Virtual Machines to Containers?

What Is Virtualization?

Virtualization is a technology that allows multiple isolated operating systems to run on a single physical machine.

Instead of dedicating one physical server to one application, virtualization enables multiple independent systems to share the same hardware resources.

The virtualization layer abstracts:

CPU
Memory (RAM)
Storage
Networking

This allows several virtual environments to coexist while behaving as separate machines.

Before Virtualization

A common approach was:

One physical server
One application
Large amounts of unused resources

Organizations often purchased many servers that spent most of their time underutilized.

After Virtualization

One powerful physical machine can host multiple virtual servers, significantly improving hardware utilization and reducing infrastructure costs.

What Is a Virtual Machine (VM)?

A Virtual Machine is a complete computer running inside another computer.

Each VM contains:

A full operating system
Its own kernel
Virtual CPU
Virtual memory
Virtual disk
Applications and services

From the VM's perspective, it believes it's running on actual hardware.

The layer that creates this illusion is called the Hypervisor.

Understanding Hypervisors

A Hypervisor is responsible for creating, managing, and isolating Virtual Machines.

It allocates physical resources and ensures one VM cannot interfere with another.

Type 1 Hypervisor (Bare Metal)

Runs directly on physical hardware.

┌─────────┐ ┌─────────┐ ┌─────────┐
│  VM 1   │ │  VM 2   │ │  VM 3   │
└─────────┘ └─────────┘ └─────────┘
┌─────────────────────────────┐
│      Type 1 Hypervisor      │
└─────────────────────────────┘
┌─────────────────────────────┐
│     Physical Hardware       │
└─────────────────────────────┘

Examples:

VMware ESXi
Hyper-V
Xen
AWS Infrastructure
Google Cloud Infrastructure
Azure Infrastructure

Benefits

Better performance
Lower overhead
Designed for production environments
Ideal for large-scale cloud platforms

Type 2 Hypervisor (Hosted)

Runs as an application on top of a host operating system.

┌─────────┐ ┌─────────┐
│  VM 1   │ │  VM 2   │
└─────────┘ └─────────┘
┌─────────────────────┐
│  Type 2 Hypervisor  │
└─────────────────────┘
┌─────────────────────┐
│      Host OS        │
└─────────────────────┘
┌─────────────────────┐
│ Physical Hardware   │
└─────────────────────┘

Examples:

VirtualBox
VMware Workstation
VMware Fusion
Parallels

Common Use Cases

Learning environments
Local development
Testing different operating systems

If you've ever run Ubuntu inside VirtualBox, you've already used a Type 2 Hypervisor.

Why Virtualization Was Revolutionary

Virtualization solved several major infrastructure challenges.

Better Resource Utilization

Multiple servers can share the same hardware.

Isolation

Problems inside one VM typically don't affect others.

Faster Provisioning

Creating a VM takes minutes instead of waiting for new hardware.

Snapshots and Rollbacks

Save a VM's state and restore it whenever needed.

Foundation of Cloud Computing

Virtualization enabled cloud providers to securely offer virtual servers to millions of customers on shared infrastructure.

The Limitations of Virtual Machines

Virtual Machines solved many problems, but they introduced new challenges.

Heavy Resource Usage

Every VM requires:

Its own operating system
Its own kernel
Background services
System processes

Even before your application starts, significant resources are already consumed.

Slower Startup Times

VMs must boot an entire operating system.

Startup times often range from:

30 seconds
Several minutes

Large Images

VM images often measure in gigabytes.

This makes them slower to:

Store
Transfer
Deploy

Poor Fit for Microservices

Modern applications frequently consist of dozens of small services.

Running every service inside its own VM becomes expensive and inefficient.

How Containers Changed Everything

Containers solve the same problem as Virtual Machines:

Running isolated workloads on shared hardware.

The difference lies in how isolation is achieved.

Virtual Machines

Every VM includes:

Application
Libraries
Guest Operating System
Guest Kernel

Containers

Containers include:

Application
Required Libraries

But they share the host operating system kernel.

Virtual Machines Architecture

┌─────┐ ┌─────┐ ┌─────┐
│ App │ │ App │ │ App │
├─────┤ ├─────┤ ├─────┤
│Bins/│ │Bins/│ │Bins/│
│Libs │ │Libs │ │Libs │
├─────┤ ├─────┤ ├─────┤
│Guest│ │Guest│ │Guest│
│ OS  │ │ OS  │ │ OS  │
└─────┘ └─────┘ └─────┘
┌─────────────────────┐
│     Hypervisor      │
└─────────────────────┘
┌─────────────────────┐
│ Physical Hardware   │
└─────────────────────┘

Containers Architecture

┌─────┐ ┌─────┐ ┌─────┐
│ App │ │ App │ │ App │
├─────┤ ├─────┤ ├─────┤
│Bins/│ │Bins/│ │Bins/│
│Libs │ │Libs │ │Libs │
└─────┴─┴─────┴─┴─────┘
┌─────────────────────┐
│  Container Engine   │
│      Docker         │
└─────────────────────┘
┌─────────────────────┐
│  Shared Host Kernel │
└─────────────────────┘
┌─────────────────────┐
│ Physical Hardware   │
└─────────────────────┘

Why Containers Became So Popular

Because containers share the host kernel, they provide several advantages.

Faster Startup

Containers typically start in milliseconds or a few seconds.

Smaller Images

Container images are often measured in megabytes rather than gigabytes.

Better Resource Efficiency

No duplicate operating systems consuming RAM and CPU.

Higher Density

One server can run dozens or hundreds of containers.

Perfect for Microservices

Containers make it easy to package, deploy, and scale individual services independently.

Containers vs Virtual Machines

Feature	Virtual Machines	Containers
Includes Full OS	✅ Yes	❌ No
Includes Own Kernel	✅ Yes	❌ No
Startup Speed	Slower	Faster
Resource Usage	Higher	Lower
Image Size	Larger	Smaller
Isolation	Stronger	Lighter
Density Per Server	Lower	Higher

Why Modern Infrastructure Uses Both

In production environments, containers and VMs often work together.

A common architecture looks like:

Physical Server
       ↓
Virtual Machine
       ↓
Docker Containers
       ↓
Applications

This approach combines:

VM-level isolation
Container efficiency
Better scalability
Stronger security boundaries

This is exactly how many Kubernetes environments run today.

Looking Ahead to Docker

The concepts from today directly map to Docker.

Virtualization Concept	Docker Equivalent
Hypervisor	Container Runtime
VM Image	Docker Image
Running VM	Running Container
Guest OS	Shared Host Kernel
VirtualBox	Docker Engine

Understanding this mapping makes Docker significantly easier to learn.

Final Thoughts

Virtualization transformed infrastructure by allowing multiple servers to share the same hardware.

Containers took that idea further by removing the need for a separate operating system in every workload.

The result was:

Faster deployments
Lower resource consumption
Better scalability
Cloud-native architectures

devops #linux #virtualization #containers #docker #cloudcomputing #aws #kubernetes

🌐 HTTP, HTTPS, Load Balancers & Firewalls: Networking Concepts Every DevOps Engineer Should Know

Md Mohiuddin — Mon, 03 Aug 2026 12:46:47 +0000

Networking doesn't stop at IP addresses, DNS, and ports.

Once a client successfully reaches a server, several other technologies come into play:

HTTP and HTTPS enable communication between clients and servers
Load balancers distribute traffic across multiple servers
Firewalls control who is allowed to access services

These concepts form the foundation of modern web applications, cloud infrastructure, Kubernetes environments, and production systems.

In this article, we'll explore:

What HTTP is and how it works
Common HTTP methods and status codes
How HTTPS secures communication
Why load balancers are essential
How firewalls protect infrastructure
Essential UFW commands for Linux servers

What Is HTTP?

HTTP (HyperText Transfer Protocol) is the communication protocol used by web browsers and servers.

It follows a simple request-response model:

A client sends a request.
The server processes the request.
The server returns a response.

HTTP is stateless, meaning every request is independent and the server doesn't automatically remember previous requests.

Anatomy of an HTTP Request

Example request:

GET /search?q=devops HTTP/1.1
Host: www.google.com
User-Agent: curl/8.1.2
Accept: text/html

An HTTP request consists of:

Component	Purpose
Method	Action to perform
Path	Resource being requested
Version	HTTP protocol version
Headers	Metadata about the request
Body	Optional request data

Anatomy of an HTTP Response

Example response:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 15258
Server: nginx

Response components:

Component	Purpose
Status Line	Status code and message
Headers	Metadata about the response
Body	Actual content returned

Common HTTP Methods

Different methods tell the server what action to perform.

Method	Purpose	Example
GET	Retrieve data	Load a webpage
POST	Create new data	Submit a form
PUT	Replace a resource	Update a profile
PATCH	Modify part of a resource	Update an email address
DELETE	Remove a resource	Delete an account

Understanding HTTP Status Codes

Status codes tell us the result of a request.

Status Code Categories

Range	Category
1xx	Informational
2xx	Success
3xx	Redirection
4xx	Client Errors
5xx	Server Errors

Common Status Codes Every DevOps Engineer Should Know

Code	Meaning
200	OK
201	Created
301	Permanent Redirect
302	Temporary Redirect
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
429	Too Many Requests
500	Internal Server Error
502	Bad Gateway
503	Service Unavailable
504	Gateway Timeout

Why 502, 503, and 504 Matter

These errors often indicate infrastructure issues rather than application bugs.

502 Bad Gateway

A proxy or load balancer received an invalid response from the backend service.

Common cause:

Backend application crashed
Service isn't running

503 Service Unavailable

The server is temporarily unable to handle requests.

Common cause:

Maintenance
Resource exhaustion
Overloaded server

504 Gateway Timeout

The backend service took too long to respond.

Common cause:

Slow database queries
Hung application processes
Network latency

These are among the most common production issues DevOps engineers troubleshoot.

What Is HTTPS?

HTTPS is HTTP running over TLS (Transport Layer Security).

The communication model remains exactly the same, but all data is encrypted before being transmitted.

Without HTTPS, attackers could potentially view:

Passwords
Cookies
API tokens
Personal information

HTTPS protects data while it's traveling across networks.

How TLS Works

A simplified TLS handshake looks like this:

Step 1: Client Hello

The client initiates a secure connection request.

Step 2: Server Certificate

The server provides a digital certificate proving its identity.

Step 3: Certificate Validation

The client verifies:

Certificate validity
Domain ownership
Trusted Certificate Authority (CA)

Step 4: Key Exchange

Client and server securely establish a shared encryption key.

Step 5: Encrypted Communication

All subsequent HTTP traffic becomes encrypted.

What Is an SSL/TLS Certificate?

A certificate binds:

A domain name
A public key

The certificate is digitally signed by a trusted Certificate Authority (CA).

Popular providers include:

Let's Encrypt
DigiCert
Sectigo

Without a valid certificate, browsers display security warnings.

What Is a Load Balancer?

A load balancer sits between clients and backend servers.

Instead of sending all traffic to a single server, it distributes requests across multiple servers.

                  ┌──────────────┐
Clients ────────► │ Load Balancer│
                  └──────┬───────┘
                         │
         ┌───────────────┼───────────────┐
         ▼               ▼               ▼

     Server 1       Server 2       Server 3

Why Load Balancers Are Important

Scalability

Traffic is distributed across multiple servers.

High Availability

Failed servers are automatically removed from rotation.

Zero-Downtime Deployments

Applications can be updated one server at a time without affecting users.

Common Load Balancing Algorithms

Round Robin

Requests are distributed evenly in sequence.

Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3

Least Connections

Traffic goes to the server with the fewest active connections.

Useful when workloads vary significantly.

IP Hash

Traffic is routed based on the client's IP address.

Useful for session persistence.

What Is a Firewall?

A firewall controls incoming and outgoing network traffic using predefined rules.

Its purpose is to:

Allow legitimate traffic
Block unwanted traffic
Reduce attack surfaces

Firewalls can filter traffic based on:

Ports
Protocols
Source IP addresses
Destination IP addresses

The Default-Deny Security Principle

A strong security practice is:

Block Everything
↓
Allow Only What Is Needed

This approach minimizes exposure and reduces risk.

Managing Firewalls with UFW

Ubuntu provides a user-friendly firewall tool called UFW (Uncomplicated Firewall).

Check Firewall Status

sudo ufw status

Enable Firewall

sudo ufw enable

Disable Firewall

sudo ufw disable

Set Default Policies

sudo ufw default deny incoming
sudo ufw default allow outgoing

Allow Essential Services

Allow SSH

sudo ufw allow 22/tcp

Allow HTTP

sudo ufw allow 80/tcp

Allow HTTPS

sudo ufw allow 443/tcp

Allow a Specific IP Address

sudo ufw allow from 203.0.113.5

Remove a Firewall Rule

sudo ufw delete allow 80/tcp

View Detailed Firewall Rules

sudo ufw status verbose

Important Warning Before Enabling UFW

If you're connected via SSH, always allow port 22 before enabling the firewall.

Correct sequence:

sudo ufw allow 22/tcp
sudo ufw enable

Failing to do this can lock you out of your server.

Security Groups vs UFW

Cloud servers often have two firewall layers:

Cloud Security Groups

Examples:

AWS Security Groups
Azure NSGs
GCP Firewall Rules

These operate outside the virtual machine.

UFW / iptables

These operate inside the Linux operating system.

Using both provides stronger protection through defense in depth.

Bringing It All Together

When you visit a secure website:

DNS resolves the domain name.
Your browser connects to the server's IP.
Traffic is sent through port 443.
TLS encrypts the connection.
An HTTP request is sent.
A load balancer may distribute the request.
A backend server processes it.
Firewalls ensure only allowed traffic reaches the service.
The server returns an HTTP response.

Understanding this flow is essential for anyone working in DevOps, Cloud Engineering, Site Reliability Engineering, or System Administration.

The deeper you understand networking fundamentals, the easier it becomes to troubleshoot real-world production systems.

Happy Learning! 🚀

🌐 Networking Fundamentals Every DevOps Engineer Should Know (IP, DNS & Ports)

Md Mohiuddin — Sun, 02 Aug 2026 08:18:44 +0000

If you're learning DevOps, networking is not optional.

Every SSH connection, web request, Docker container, Kubernetes service, and cloud resource relies on networking behind the scenes.

When applications fail to communicate, deployments break, or services become unreachable, networking is often the first place engineers investigate.

In this article, I'll cover:

✅ What IP addresses are
✅ Public vs Private IPs
✅ Understanding Subnets and CIDR
✅ How DNS works
✅ Common DNS record types
✅ Understanding Ports
✅ The Client-Server Model
✅ Useful networking commands for troubleshooting

Let's dive in.

Why Networking Matters in DevOps

Almost every modern DevOps tool depends on networking.

Examples include:

SSH connections to servers
Web applications communicating with databases
Docker containers talking to each other
Kubernetes services routing traffic
CI/CD pipelines deploying applications
Cloud services communicating across regions

When something stops working, one of the first questions engineers ask is:

Is this a networking problem?

Understanding networking helps you answer that question quickly.

What Is an IP Address?

An IP (Internet Protocol) address is a unique identifier assigned to a device on a network.

It allows devices to locate and communicate with each other.

Example IPv4 address:

192.168.1.10

IPv4 addresses contain four numbers separated by dots.

Each section ranges from:

0 - 255

Without IP addresses, computers wouldn't know where to send data.

Public vs Private IP Addresses

There are two major categories of IP addresses.

Public IP

A public IP address is reachable from anywhere on the internet.

Examples:

Cloud servers
Public websites
Home internet routers

Your AWS EC2 instance will typically have a public IP so you can SSH into it remotely.

Private IP

Private IP addresses are only accessible within a local network.

Common private ranges:

10.0.0.0 – 10.255.255.255

172.16.0.0 – 172.31.255.255

192.168.0.0 – 192.168.255.255

You'll frequently encounter these ranges when working with:

AWS VPCs
Docker networks
Kubernetes clusters
Internal company networks

Localhost (Loopback Address)

A special IP address always refers to the current machine:

127.0.0.1

You'll often see:

localhost

which resolves to:

127.0.0.1

This allows you to test applications running on your own computer without using an external network.

Understanding Subnets

As networks grow, they are divided into smaller logical sections called subnets.

A subnet helps organize devices and control traffic efficiently.

CIDR Notation

Subnets are usually written using CIDR notation:

192.168.1.0/24

The /24 indicates the network portion of the address.

A /24 subnet provides:

256 IP addresses

from:

192.168.1.0

to:

192.168.1.255

Examples:

CIDR	Approx. Addresses
/16	65,536
/24	256
/28	16

You'll see CIDR blocks frequently when creating cloud networks and VPCs.

What Is DNS?

Humans prefer names.

Computers prefer IP addresses.

DNS (Domain Name System) translates domain names into IP addresses.

For example:

google.com

becomes something like:

142.250.xxx.xxx

This allows your browser to find the correct server.

How DNS Resolution Works

When you visit a website:

google.com

the lookup process generally follows these steps:

Your Device
      ↓
DNS Resolver
      ↓
Root Servers
      ↓
TLD Servers (.com)
      ↓
Authoritative DNS Server
      ↓
IP Address Returned

Finally, your computer connects to the returned IP address.

This entire process usually takes only milliseconds.

Common DNS Record Types

Record	Purpose
A	Domain → IPv4 Address
AAAA	Domain → IPv6 Address
CNAME	Domain Alias
MX	Mail Server Records
TXT	Verification & Security Records
NS	Name Server Information

As a DevOps engineer, you'll regularly manage DNS records when deploying applications.

Understanding Ports

An IP address identifies a machine.

A port identifies a service running on that machine.

Think of it like:

IP Address = Building Address
Port = Apartment Number

Multiple applications can run on the same server because each listens on a different port.

Common Ports Every DevOps Engineer Should Know

Port	Service
22	SSH
53	DNS
80	HTTP
443	HTTPS
3306	MySQL
5432	PostgreSQL
6379	Redis
27017	MongoDB

Examples:

192.168.1.10:22

SSH service

192.168.1.10:80

Web server

192.168.1.10:443

Secure website

The Client-Server Model

Most applications follow the client-server model.

A client sends a request.

A server receives the request and returns a response.

Example:

CLIENT                     SERVER

Browser  ───── Request ───► Nginx

Browser ◄──── Response ─── Nginx

Examples of clients:

Web browsers
Mobile apps
curl
API consumers

Examples of servers:

Nginx
Apache
Node.js applications
Databases

Useful Networking Commands

ping

Check whether a host is reachable.

ping google.com

Example output:

64 bytes from 142.x.x.x: time=14 ms

Useful for:

Basic connectivity testing
Measuring latency

Stop with:

Ctrl + C

nslookup

Perform a DNS lookup.

nslookup google.com

Output shows the IP address associated with the domain.

dig

A more advanced DNS troubleshooting tool.

Basic lookup:

dig google.com

Short output:

dig google.com +short

Lookup MX records:

dig google.com MX

View the full DNS resolution path:

dig +trace google.com

curl

Send HTTP requests directly from the terminal.

curl https://google.com

Show only response headers:

curl -I https://google.com

Verbose mode:

curl -v https://google.com

Save output to a file:

curl -o page.html https://google.com

curl -I is one of the most useful troubleshooting commands in DevOps.

Following the Journey of a Request

Let's see what happens when you run:

curl https://google.com

Step-by-step:

DNS resolves google.com to an IP address.
Your machine connects to that IP.
It uses port 443 for HTTPS.
A secure TLS connection is established.
The HTTP request is sent.
Google's server processes the request.
An HTTP response is returned.
curl displays the result.

DNS
 ↓
IP Address
 ↓
Port 443
 ↓
TLS Handshake
 ↓
HTTP Request
 ↓
HTTP Response

This flow is the foundation of nearly every web application you'll work with.

Final Thoughts

Networking is one of the most important skills in DevOps.

Understanding IP addresses, DNS, ports, and client-server communication gives you the foundation needed for cloud computing, Docker, Kubernetes, load balancers, CI/CD pipelines, and modern infrastructure.

The better you understand how systems communicate, the easier it becomes to troubleshoot real-world production issues.

If you have favorite networking commands or troubleshooting tips, feel free to share them in the comments.

Happy Learning! 🌐🚀

📦 Linux Package Management for DevOps Engineers: A Practical Guide

Md Mohiuddin — Sat, 01 Aug 2026 08:29:49 +0000

Every server, virtual machine, and container starts with a simple requirement: software needs to be installed.

Whether you're setting up a web server, deploying a database, configuring monitoring tools, or preparing a Docker image, package managers are the tools that make software installation fast, reliable, and repeatable.

As part of my DevOps learning journey, I explored how Linux package managers work, why they matter in modern infrastructure, and how they help automate software provisioning.

In this article, I'll cover:

✅ What package managers are
✅ Why package management matters in DevOps
✅ Using apt on Ubuntu
✅ Understanding repositories and dependencies
✅ yum and dnf basics
✅ Why minimal server images are preferred
✅ A real-world software installation workflow

Let's dive in.

Why Package Managers Matter in DevOps

Imagine installing software manually on every server:

Download source code
Install dependencies one by one
Compile the application
Configure everything manually

Not only would this take time, but it would also be difficult to reproduce consistently.

Package managers solve this problem by allowing you to install, update, and remove software using simple commands.

This becomes especially important in DevOps because:

Dockerfiles use package managers to install software
Configuration management tools like Ansible rely on package managers
Cloud servers start with minimal operating systems
Infrastructure should be repeatable and automated

Package managers are one of the foundations of modern infrastructure automation.

What Is a Package Manager?

A package manager is a tool that installs and manages software packages on a Linux system.

A package typically contains:

Application files
Dependencies
Configuration information
Installation instructions
Metadata

Package managers handle several important tasks automatically.

Dependency Resolution

If Software A requires Libraries B and C, the package manager installs them automatically.

You don't need to manually track every dependency.

Software Repositories

Package managers download software from trusted repositories maintained by operating system vendors or software providers.

Correct File Placement

Installed files are placed in the proper Linux directories automatically.

For example:

/usr/bin   → Executables
/etc       → Configuration files
/usr/lib   → Libraries

Version Tracking

Package managers keep track of installed software, making updates and removals much easier.

Understanding apt (Ubuntu Package Manager)

Since Ubuntu is one of the most popular Linux distributions in cloud environments, apt is a command you'll use frequently.

Refresh Package Information

sudo apt update

This command updates the local package catalog.

It does not install or upgrade software.

Think of it as refreshing a store's inventory before shopping.

Upgrade Installed Packages

sudo apt upgrade

This upgrades installed packages to newer available versions.

Install Software

Install Nginx:

sudo apt install nginx

Install multiple packages:

sudo apt install nginx docker.io

Remove Software

Remove a package:

sudo apt remove nginx

Remove a package and its configuration files:

sudo apt purge nginx

Clean Unused Dependencies

sudo apt autoremove

This removes packages that are no longer required.

Search for Packages

apt search nginx

View package details:

apt show nginx

List Installed Packages

apt list --installed

Useful when auditing a server.

Where Does apt Get Packages?

Package repositories are configured in:

/etc/apt/sources.list

and

/etc/apt/sources.list.d/

These files contain repository URLs where Ubuntu downloads software packages.

Most installations use Ubuntu's official repositories, but third-party repositories can also be added when necessary.

Understanding yum and dnf

While Ubuntu uses apt, Red Hat-based distributions use:

yum
dnf

You'll encounter these when working with:

Red Hat Enterprise Linux (RHEL)
CentOS
Fedora
Amazon Linux

Common Command Equivalents

Task	Ubuntu (apt)	RHEL/Fedora (dnf)
Update package info	`apt update`	`dnf check-update`
Install package	`apt install nginx`	`dnf install nginx`
Remove package	`apt remove nginx`	`dnf remove nginx`
Upgrade packages	`apt upgrade`	`dnf upgrade`
Search packages	`apt search nginx`	`dnf search nginx`
Package details	`apt show nginx`	`dnf info nginx`

The concepts remain the same regardless of the distribution.

Only the commands change.

Why Minimal Server Images Matter

Modern DevOps practices encourage using minimal operating system images.

Why?

Improved Security

Every installed package increases the attack surface.

Less software means fewer vulnerabilities to patch and monitor.

Faster Provisioning

Smaller images:

Download faster
Boot faster
Deploy faster

This becomes extremely important when working with containers.

Easier Maintenance

A minimal system contains only what your application needs.

This makes troubleshooting and auditing much simpler.

Reduced Resource Usage

Unused software consumes:

Disk space
Memory
CPU resources

Minimal systems avoid unnecessary overhead.

A Real-World Installation Workflow

Let's walk through a practical example using Nginx.

Step 1: Update Package Information

sudo apt update

Step 2: Install Nginx

sudo apt install nginx -y

The -y flag automatically confirms installation prompts.

Step 3: Verify Service Status

sudo systemctl status nginx

Step 4: Start and Enable Nginx

sudo systemctl start nginx
sudo systemctl enable nginx

This ensures Nginx starts automatically after server reboots.

Step 5: Verify Listening Ports

sudo ss -tulpn | grep :80

This confirms Nginx is listening on port 80.

Step 6: Check Logs

sudo tail -f /var/log/nginx/error.log

If something goes wrong, logs are usually the first place to investigate.

Quick Command Reference

Command	Purpose
`apt update`	Refresh package catalog
`apt upgrade`	Upgrade installed packages
`apt install`	Install software
`apt remove`	Remove software
`apt purge`	Remove software and configs
`apt autoremove`	Remove unused dependencies
`apt search`	Search available packages
`apt show`	View package details
`apt list --installed`	List installed software
`dnf install`	Install packages on RHEL/Fedora
`systemctl status`	Verify service status

Final Thoughts

Package managers are one of the most important tools in a DevOps engineer's toolkit.

They simplify software installation, automate dependency management, improve consistency, and make infrastructure easier to maintain.

Whether you're provisioning cloud servers, building Docker images, writing Ansible playbooks, or managing production environments, package management is a skill you'll use almost every day.

Understanding how package managers work today will make containerization, automation, and infrastructure management much easier as you continue your DevOps journey.

I'm documenting my DevOps learning journey and sharing beginner-friendly notes as I learn.

What package manager do you use most often—apt, dnf, yum, or something else?

Happy Learning! 🚀🐧

📝 Bash Scripting Basics Every DevOps Engineer Should Know

Md Mohiuddin — Fri, 31 Jul 2026 15:58:53 +0000

If you're learning DevOps, Linux, or Cloud Computing, Bash scripting is one of the most valuable skills you can develop.

Up until now, you've probably been running Linux commands one by one in the terminal. But in real-world DevOps, repeating the same commands manually isn't efficient. Instead, we automate those tasks using shell scripts.

Whether you're deploying applications, monitoring servers, creating backups, or scheduling maintenance jobs, Bash scripting is often the first step toward automation.

In this article, I'll cover:

✅ Why Bash scripting matters
✅ Terminal text editors (Nano & Vim)
✅ Creating your first Bash script
✅ Variables and special variables
✅ Conditionals (if, else)
✅ Loops (for, while)
✅ Functions
✅ Automating tasks with Cron

Let's get started.

Why Bash Scripting Matters

Imagine typing the same five commands every day to:

Deploy an application
Back up a database
Restart a service
Clean old log files

Instead of repeating these commands manually, you can place them inside a script and execute them with a single command.

That's automation.

In fact, Bash scripting is the foundation of many DevOps tools. Before Jenkins pipelines, Ansible playbooks, or Terraform modules execute tasks, they're often running shell commands behind the scenes.

Learning Bash means learning how automation actually works.

Terminal Text Editors

When working on remote Linux servers through SSH, you usually won't have a graphical editor like VS Code.

Instead, you'll use terminal-based editors.

The two most common are Nano and Vim.

Nano

Nano is beginner-friendly and easy to use.

Open a file:

nano script.sh

Useful shortcuts:

Shortcut	Action
Ctrl + O	Save
Ctrl + X	Exit
Ctrl + K	Cut a line
Ctrl + U	Paste
Ctrl + W	Search

Nano displays these shortcuts at the bottom of the screen, making it easy for beginners.

Vim

Vim is one of the most powerful text editors available on Linux.

Open a file:

vim script.sh

Unlike Nano, Vim uses different modes.

Mode	Purpose
Normal	Execute commands
Insert	Type text
Command	Save, quit, search

Essential Vim commands:

i      → Enter Insert mode
Esc    → Return to Normal mode
:w     → Save
:q     → Quit
:wq    → Save and Quit
:q!    → Quit without saving
dd     → Delete current line
/text  → Search for text

While Vim has a learning curve, it's installed on almost every Linux system, making it a valuable tool to know.

Creating Your First Bash Script

A Bash script is simply a text file containing Linux commands.

Every script should begin with a shebang.

#!/bin/bash

The shebang tells Linux which interpreter should execute the script.

Example:

#!/bin/bash

echo "Hello DevOps!"

Save the file as:

hello.sh

Make it executable:

chmod +x hello.sh

Run it:

./hello.sh

You can also execute it without making it executable:

bash hello.sh

Working with Variables

Variables store values that can be reused throughout a script.

Example:

#!/bin/bash

name="DevOps Engineer"
count=5

echo "Hello, $name"
echo "Count: $count"

Important Rules

No spaces around =
Use $ when accessing a variable
Wrap variables inside double quotes

Correct:

name="John"
echo "$name"

Incorrect:

name = "John"

Command Substitution

Store command output inside a variable.

Example:

current_date=$(date)

echo "$current_date"

Another example:

file_count=$(ls | wc -l)

echo "$file_count files found."

This technique is commonly used in automation scripts.

Special Variables

Bash provides several built-in variables.

Variable	Purpose
`$0`	Script name
`$1`	First argument
`$2`	Second argument
`$#`	Number of arguments
`$?`	Exit status of previous command

Example:

./deploy.sh production

Inside the script:

echo "$1"

Output:

production

Using Conditionals

Conditionals allow scripts to make decisions.

Example:

disk_usage=85

if [ "$disk_usage" -gt 80 ]; then
    echo "Disk usage is high!"
else
    echo "Disk usage is healthy."
fi

Common Comparison Operators

Operator	Meaning
`-eq`	Equal
`-ne`	Not equal
`-gt`	Greater than
`-lt`	Less than
`-ge`	Greater than or equal
`-le`	Less than or equal
`==`	String equality
`!=`	String inequality
`-f`	File exists
`-d`	Directory exists

Checking Whether a File Exists

if [ -f "app.log" ]; then
    echo "Log file found."
else
    echo "Log file missing."
fi

This is a common pattern in deployment and monitoring scripts.

Using Loops

Loops execute commands repeatedly.

For Loop

for server in web1 web2 web3
do
    echo "Deploying to $server"
done

Loop through files:

for file in *.log
do
    echo "$file"
done

Loop over numbers:

for i in {1..5}
do
    echo "$i"
done

While Loop

count=1

while [ "$count" -le 5 ]
do
    echo "$count"
    count=$((count+1))
done

Real Example: Retry Until Success

attempt=0

while [ "$attempt" -lt 5 ]
do
    if curl -sf http://localhost:8080/health
    then
        echo "Service is running."
        break
    fi

    echo "Retrying..."

    attempt=$((attempt+1))

    sleep 5
done

This pattern is widely used in deployment scripts.

Creating Functions

Functions help organize larger scripts.

Example:

log_message() {
    local message=$1
    echo "$(date): $message"
}

Call the function:

log_message "Deployment started"

log_message "Deployment completed"

Using functions makes scripts easier to read and maintain.

Automating Tasks with Cron

Automation becomes even more powerful when scripts run automatically.

Linux provides cron for scheduling tasks.

Edit your cron jobs:

crontab -e

Cron format:

* * * * * command
│ │ │ │ │
│ │ │ │ └── Day of Week
│ │ │ └──── Month
│ │ └────── Day of Month
│ └──────── Hour
└────────── Minute

Common Cron Examples

Run every day at 2:30 AM:

30 2 * * * /home/user/backup.sh

Run every hour:

0 * * * * /home/user/health-check.sh

Run every Monday at 9 AM:

0 9 * * 1 /home/user/report.sh

Run every five minutes:

*/5 * * * * /home/user/monitor.sh

Logging Cron Output

Always redirect cron output to a log file.

30 2 * * * /home/user/backup.sh >> /home/user/backup.log 2>&1

This captures both:

Standard output
Error messages

Making troubleshooting much easier.

Best Practices for Bash Scripts

Start every script with #!/bin/bash
Use meaningful variable names
Always quote variables
Use functions for reusable logic
Test scripts before running them in production
Use absolute paths in cron jobs
Log script output for easier debugging
Add comments to improve readability

Quick Command Reference

Command	Purpose
`nano file.sh`	Open file in Nano
`vim file.sh`	Open file in Vim
`chmod +x file.sh`	Make script executable
`./file.sh`	Run script
`bash file.sh`	Execute with Bash
`crontab -e`	Edit cron jobs
`date`	Current date and time
`$(command)`	Command substitution
`$?`	Previous command exit status
`$#`	Number of arguments

Final Thoughts

Bash scripting is where Linux commands become automation.

By learning how to write scripts, use variables, create loops, organize code with functions, and schedule jobs with Cron, you're building the foundation for more advanced DevOps tools like Jenkins, Ansible, Terraform, and Kubernetes.

These concepts may seem simple now, but they're used every day in real production environments.

If you have any Bash scripting tips or favorite automation tricks, feel free to share them in the comments.

Happy Learning! 🐧🚀

🔐 SSH Essentials Every DevOps Engineer Should Know

Md Mohiuddin — Thu, 30 Jul 2026 17:35:22 +0000

If you're learning DevOps, Cloud Computing, or System Administration, SSH is one of the most important skills you'll ever learn.

Almost every cloud server, Kubernetes node, CI/CD runner, and Linux machine is managed remotely through SSH. Without SSH, you simply can't access or manage production infrastructure effectively.

As part of my DevOps learning journey, I spent time understanding how SSH works, how key-based authentication improves security, and how to securely connect to remote servers.

In this article, I'll cover:

✅ What SSH is
✅ How SSH works
✅ Public vs Private Keys
✅ Generating SSH keys
✅ Connecting to remote servers
✅ Managing SSH configurations
✅ Secure file transfers with SCP

Let's get started.

What Is SSH?

SSH (Secure Shell) is a secure network protocol that allows you to remotely access and manage another computer over a network.

Using SSH, you can:

Access a remote Linux server
Execute commands remotely
Manage cloud infrastructure
Transfer files securely
Automate deployments

Before SSH existed, tools like Telnet sent everything in plain text, including passwords.

SSH solved this problem by encrypting all communication between your computer and the remote server.

Why SSH Is Important for DevOps

Every modern DevOps workflow relies on SSH.

Some common examples include:

Connecting to AWS EC2 instances
Managing Linux servers
Accessing Kubernetes nodes
Deploying applications
Running automation scripts
Configuring CI/CD pipelines

In real-world DevOps work, you'll frequently need to answer questions like:

Is the server running properly?
Why is my application failing?
How do I deploy new code?
How can I transfer files securely?

SSH is usually the first tool you'll use to solve these problems.

How SSH Works

SSH works using encryption and authentication.

A typical SSH connection happens in two stages.

Step 1: Server Verification

When connecting to a server for the first time, SSH verifies the server's identity.

You may see a message like:

The authenticity of host '203.0.113.5' can't be established.
ED25519 key fingerprint is SHA256:xxxxxx.
Are you sure you want to continue connecting (yes/no)?

If you trust the server, type:

yes

SSH then stores the server fingerprint locally in:

~/.ssh/known_hosts

Future connections are checked against this fingerprint automatically.

Step 2: Authentication

After the encrypted channel is established, SSH verifies who you are.

There are two common methods.

Password Authentication

Client → Password → Server

The password travels through the encrypted connection.

While secure, passwords can still be:

Guessed
Reused
Phished
Brute-forced

Key-Based Authentication

This is the industry standard.

You create:

A private key
A public key

The public key is stored on the server.

The private key remains on your computer.

When connecting, SSH verifies that you own the matching private key without ever sending it across the network.

Benefits include:

Stronger security
No password typing
Resistant to brute-force attacks
Easy automation for CI/CD pipelines

Generating an SSH Key Pair

Create a new SSH key using:

ssh-keygen -t ed25519 -C "your_email@example.com"

Understanding the Options

Option	Purpose
`-t ed25519`	Modern and secure key type
`-C`	Comment to identify the key

You'll be prompted for:

File location
Passphrase

Press Enter to accept the default location.

Generated Files

View your SSH directory:

ls -la ~/.ssh

Example output:

id_ed25519
id_ed25519.pub

File	Purpose
`id_ed25519`	Private key (secret)
`id_ed25519.pub`	Public key (safe to share)

Important Security Rule

Never share:

id_ed25519

Never commit it to GitHub.

Never send it through email or chat.

Only share:

id_ed25519.pub

The .pub file is designed to be distributed.

Understanding Public and Private Keys

Think of it like this:

Public Key  → Lock
Private Key → Key

You can give your lock to anyone.

Only the person holding the matching key can unlock it.

This is essentially how SSH authentication works.

Adding Your Public Key to a Server

SSH servers store authorized public keys inside:

~/.ssh/authorized_keys

Any public key listed there can authenticate as that user.

Method 1: Cloud Provider

When launching an AWS EC2 instance, AWS can automatically place your public key on the server.

This is the most common method when learning cloud infrastructure.

Method 2: ssh-copy-id

If you already have password access:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server_ip

This automatically installs your public key.

Method 3: Manual Method

cat ~/.ssh/id_ed25519.pub | ssh username@server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

This manually appends your public key to the server's authorized keys file.

Connecting to a Remote Server

Basic SSH connection:

ssh username@server_ip

Example:

ssh ubuntu@203.0.113.5

Once connected, you'll receive a remote terminal session.

Using a Specific Key

If your key is stored in a different location:

ssh -i ~/.ssh/my-aws-key.pem ubuntu@203.0.113.5

This tells SSH exactly which key to use.

Common SSH Permission Error

You may encounter:

Permissions 0644 for 'my-aws-key.pem' are too open.

SSH refuses to use keys that other users can read.

Fix it:

chmod 400 my-aws-key.pem

This makes the file readable only by you.

Simplifying Connections with SSH Config

Instead of remembering long commands, create:

~/.ssh/config

Example:

Host my-ec2-server
    HostName 203.0.113.5
    User ubuntu
    IdentityFile ~/.ssh/my-aws-key.pem

Now connect using:

ssh my-ec2-server

This becomes incredibly useful when managing multiple servers.

Transferring Files with SCP

SCP (Secure Copy) uses SSH to transfer files securely.

Copy a Local File to a Server

scp -i ~/.ssh/my-key.pem local-file.txt ubuntu@203.0.113.5:/home/ubuntu/

Copy a Remote File to Your Computer

scp -i ~/.ssh/my-key.pem ubuntu@203.0.113.5:/home/ubuntu/file.txt ./

Copy an Entire Directory

scp -r -i ~/.ssh/my-key.pem ./project/ ubuntu@203.0.113.5:/home/ubuntu/

The -r flag means recursive.

SCP Syntax Made Simple

Think of SCP exactly like the Linux cp command:

scp source destination

The only difference is that remote locations use:

user@host:/path

instead of a normal local path.

Quick Command Reference

Command	Purpose
`ssh-keygen`	Generate SSH keys
`ssh`	Connect to a remote server
`ssh-copy-id`	Install public key on a server
`chmod 400 key.pem`	Secure private key permissions
`scp`	Transfer files securely
`scp -r`	Transfer directories
`cat ~/.ssh/known_hosts`	View trusted hosts
`cat ~/.ssh/authorized_keys`	View authorized keys
`ssh -i key.pem`	Connect using a specific key

Final Thoughts

SSH is one of the foundational skills every DevOps engineer must master.

Whether you're managing cloud servers, deploying applications, configuring CI/CD pipelines, or troubleshooting production systems, SSH is the secure gateway that gives you access.

Learning SSH early will make your journey into AWS, Docker, Kubernetes, Terraform, and automation much easier.

I'm currently documenting my DevOps learning journey and sharing beginner-friendly notes as I learn.

If you have any SSH tips or best practices, feel free to share them in the comments.

Happy Learning! 🚀🐧

⚙️ Linux Process Management Every DevOps Engineer Should Know

Md Mohiuddin — Wed, 29 Jul 2026 17:55:06 +0000

When an application stops responding, a server becomes slow, or a deployment suddenly fails, one of the first places a DevOps engineer looks is the Linux process list.

Every web server, database, monitoring agent, Docker container, and CI/CD tool ultimately runs as a process inside the operating system.

Understanding how processes work is a fundamental Linux skill that will help you troubleshoot servers, monitor resource usage, and manage applications effectively.

In this article, I'll cover:

✅ What a process is
✅ Viewing running processes
✅ Monitoring CPU and memory usage
✅ Running jobs in the background
✅ Killing processes safely
✅ Checking disk and memory usage
✅ Managing services with systemctl

Let's dive in.

Why Process Management Matters in DevOps

Every application you deploy goes through a lifecycle:

Start → Run → Stop

Or sometimes:

Start → Run → Crash 😅

As a DevOps engineer, you'll frequently need to answer questions like:

Is my application actually running?
Why is the server slow?
Which process is consuming all the memory?
How can I stop a misbehaving process?
How do I ensure my application restarts after a reboot?

Linux process management provides the answers.

What Is a Process?

A process is simply a running instance of a program.

For example:

python app.py

When you run this command, Linux creates a new process.

Every process has:

A Process ID (PID)
A Parent Process ID (PPID)
CPU usage
Memory allocation
A current state

Each running application on your system is represented by one or more processes.

Viewing Running Processes

Using ps

The ps command provides a snapshot of currently running processes.

Show processes running in your current terminal:

ps

Show all processes:

ps aux

Alternative format:

ps -ef

Understanding ps Output

Example:

USER   PID  %CPU %MEM COMMAND
ana   1234   0.5  1.2 python app.py

Column	Meaning
USER	Process owner
PID	Process ID
%CPU	CPU usage
%MEM	Memory usage
COMMAND	Executed command

Finding a Specific Process

One of the most common DevOps commands:

ps aux | grep nginx

Example:

ps aux | grep docker

This searches for running Docker processes.

Monitoring Processes in Real Time

top

The top command provides a live view of running processes.

top

Useful shortcuts inside top:

Key	Action
P	Sort by CPU usage
M	Sort by memory usage
k	Kill a process
q	Quit

htop

A more user-friendly version of top.

Install:

sudo apt install htop

Run:

htop

Benefits:

Color-coded interface
Easier navigation
Better process management

Many Linux administrators prefer htop for daily use.

Running Processes in the Background

Normally, commands run in the foreground.

Example:

sleep 500

Your terminal remains occupied until the command finishes.

Run a Process in the Background

Add & at the end:

sleep 500 &

Output:

[1] 12345

Where:

[1] = Job number
12345 = PID

Your terminal becomes available immediately.

Listing Background Jobs

View jobs running in the current terminal:

jobs

Example:

[1]+ Running sleep 500 &

Moving Jobs Between Background and Foreground

Bring a job back to the foreground:

fg %1

Send a suspended job to the background:

bg %1

Pause a Running Process

Press:

Ctrl + Z

This pauses the process without terminating it.

Then resume it:

bg

This is useful for long-running commands.

Stopping Processes

Linux uses signals to communicate with processes.

The kill command sends those signals.

Graceful Shutdown

kill 12345

This sends:

SIGTERM (15)

The application gets a chance to clean up before stopping.

Force Kill

kill -9 12345

This sends:

SIGKILL (9)

The process stops immediately.

No cleanup occurs.

Best Practice

Always try:

kill PID

before:

kill -9 PID

Force-killing applications can sometimes cause data corruption.

Killing Processes by Name

Instead of finding the PID manually:

pkill nginx

Or:

killall nginx

Very useful during troubleshooting.

Checking Disk Space

One of the most common production issues is a full disk.

Check disk usage:

df -h

Example output:

Filesystem Size Used Avail Use%
/dev/sda1 50G 32G 16G 67%

The -h flag means:

Human Readable

Checking Memory Usage

Use:

free -h

Example:

Mem: 7.8G 2.1G 3.2G

Important columns:

Column	Meaning
Used	Memory currently used
Free	Completely unused memory
Available	Memory available to applications

Common Beginner Mistake

Many people panic when they see low "Free" memory.

Linux intentionally uses unused RAM for caching.

The important value is:

Available

Not:

Free

Managing Services with systemctl

Running commands with & works for temporary tasks.

Production services require something more reliable.

Examples:

Nginx
Docker
Jenkins
PostgreSQL
Redis

These services are managed using:

systemctl

Starting a Service

sudo systemctl start nginx

Stopping a Service

sudo systemctl stop nginx

Restarting a Service

sudo systemctl restart nginx

Checking Service Status

sudo systemctl status nginx

One of the most frequently used commands in Linux administration.

Enable Service at Boot

Automatically start after reboot:

sudo systemctl enable nginx

Disable automatic startup:

sudo systemctl disable nginx

Understanding a Service File

Example:

[Unit]
Description=My Application
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/user/app.py
Restart=always
User=user

[Install]
WantedBy=multi-user.target

Important fields:

Field	Purpose
ExecStart	Command to run
Restart=always	Restart automatically if it crashes
User	Run as a specific user
WantedBy	Start during system boot

Reload systemd After Changes

After editing a service file:

sudo systemctl daemon-reload

Then:

sudo systemctl restart myapp

Quick Command Reference

Command	Purpose
ps	View running processes
ps aux	View all processes
top	Live process monitoring
htop	Enhanced process monitoring
jobs	List background jobs
fg	Move job to foreground
bg	Move job to background
kill	Stop a process gracefully
kill -9	Force kill a process
pkill	Kill process by name
killall	Kill all matching processes
df -h	Check disk usage
free -h	Check memory usage
systemctl start	Start a service
systemctl stop	Stop a service
systemctl restart	Restart a service
systemctl status	View service status
systemctl enable	Auto-start service on boot

Final Thoughts

Process management is one of the most important Linux skills for DevOps engineers.

Whether you're troubleshooting a slow server, debugging an application, monitoring resource usage, or managing production services, these commands become part of your daily toolkit.

The more comfortable you become with processes and services, the easier it will be to work with Docker containers, Kubernetes workloads, CI/CD pipelines, and cloud infrastructure.

I'm currently documenting my DevOps learning journey and sharing beginner-friendly notes as I learn.

If you have favorite Linux troubleshooting commands, feel free to share them in the comments.

Happy Learning! 🐧🚀

🔐 Linux Permissions Every DevOps Engineer Should Know

Md Mohiuddin — Tue, 28 Jul 2026 14:35:56 +0000

If you're learning Linux for DevOps, sooner or later you'll encounter errors like:

Permission denied

Could not read private key

Operation not permitted

At first, these errors can feel confusing. But once you understand Linux permissions, ownership, file searching, and command chaining, troubleshooting becomes much easier.

In this article, I'll cover some of the most practical Linux concepts that DevOps engineers use every day:

✅ Linux permissions
✅ chmod
✅ chown
✅ sudo
✅ cat, head, and tail
✅ grep and find
✅ Piping and redirection

Let's dive in.

Why Permissions Are a Big Deal in DevOps

Linux was designed as a multi-user operating system. Multiple users and processes can run on the same machine at the same time.

Permissions exist to answer one important question:

Is this user or process allowed to read, write, or execute this file?

As a DevOps engineer, permissions appear everywhere:

SSH won't allow login if your private key permissions are too open.
Nginx needs permission to read your application's files.
Docker containers often run as specific users, causing permission mismatches.
CI/CD pipelines frequently fail because of permission issues.

Understanding permissions can save hours of debugging.

Understanding Linux Permissions

Run the following command:

ls -l

Example output:

-rwxr-xr-- 1 ana developers 220 Jul 27 10:00 deploy.sh

The first section contains the permission information:

-rwxr-xr--

Let's break it down.

File Types

The first character indicates the file type.

Symbol	Meaning
`-`	Regular file
`d`	Directory
`l`	Symbolic link

Permission Groups

The next nine characters are divided into three groups.

rwx     r-x     r--
---     ---     ---
Owner   Group   Others

Each group represents permissions for a different category of users.

Permission Meanings

For Files

Permission	Meaning
`r`	Read the file
`w`	Modify the file
`x`	Execute the file

For Directories

Permission	Meaning
`r`	List directory contents
`w`	Create or delete files
`x`	Enter the directory using `cd`

Example

Consider:

-rwxr-xr--

This means:

Owner (rwx)

Read
Write
Execute

Group (r-x)

Read
Execute
Cannot modify

Others (r--)

Read only

Understanding the Full Output

-rwxr-xr-- 1 ana developers 220 Jul 27 10:00 deploy.sh

Value	Meaning
`1`	Number of hard links
`ana`	Owner
`developers`	Group
`220`	File size
`Jul 27 10:00`	Last modified
`deploy.sh`	File name

chmod — Changing Permissions

The chmod command is used to modify permissions.

There are two common approaches.

Method 1: Symbolic Notation

Add execute permission for the owner:

chmod u+x deploy.sh

Remove write permission from the group:

chmod g-w deploy.sh

Set others to read-only:

chmod o=r deploy.sh

Add read permission for everyone:

chmod a+r deploy.sh

Symbol Meanings

Symbol	Meaning
`u`	User (owner)
`g`	Group
`o`	Others
`a`	All

Method 2: Numeric (Octal) Notation

This is the method you'll see most often in DevOps.

Each permission has a value:

Permission	Value
Read	4
Write	2
Execute	1
None	0

Common Permission Values

Number	Permission
7	rwx
6	rw-
5	r-x
4	r--
0	---

Example

chmod 754 deploy.sh

This translates to:

Owner  = 7 = rwx
Group  = 5 = r-x
Others = 4 = r--

Common chmod Values Used in DevOps

SSH Private Keys

chmod 600 id_rsa

Only the owner can read and write the file.

SSH often refuses to use private keys with weaker permissions.

Configuration Files

chmod 644 config.yaml

Owner can modify the file.

Everyone else can read it.

Scripts and Executables

chmod 755 deploy.sh

Everyone can run the script.

Only the owner can modify it.

Sensitive Files

chmod 400 secrets.txt

Owner can read the file.

Nobody else has access.

chown — Changing Ownership

While chmod controls permissions, chown controls ownership.

Change Owner

chown ana deploy.sh

Changes the file owner to ana.

Change Owner and Group

chown ana:developers deploy.sh

Changes both owner and group.

Recursive Ownership Change

chown -R ana:developers app/

Applies ownership changes to all files and directories inside the folder.

Real-World Example

Suppose a web application runs under:

www-data

If the files are owned by another user, the application may fail with:

Permission denied

A common fix is:

sudo chown -R www-data:www-data /var/www/myapp

sudo — Temporary Administrator Access

sudo allows a user to run commands with administrator privileges.

Update Packages

sudo apt update

Open a Root Shell

sudo -i

Use carefully.

Change Ownership

sudo chown root:root file.txt

Why Use sudo?

Accountability

Every sudo command is logged.

Security

You only elevate privileges when necessary.

Control

Administrators can grant limited access without giving full root permissions.

Reading Files in Linux

When troubleshooting systems, reading logs and configuration files is a daily task.

cat

Display the entire file.

cat app.log

head

Display the first few lines.

head app.log

Display the first 20 lines:

head -n 20 app.log

tail

Display the last few lines.

tail app.log

Display the last 50 lines:

tail -n 50 app.log

tail -f

Monitor a file in real time.

tail -f /var/log/nginx/access.log

This is one of the most frequently used commands in DevOps.

It's perfect for watching logs while debugging applications or deployments.

grep — Searching Inside Files

The grep command searches file contents for a specific pattern.

Find Errors

grep "ERROR" app.log

Case-Insensitive Search

grep -i "error" app.log

Search Recursively

grep -r "TODO" ./src

Count Matches

grep -c "ERROR" app.log

Show Line Numbers

grep -n "ERROR" app.log

Exclude Matches

grep -v "DEBUG" app.log

find — Searching for Files

Unlike grep, the find command searches for files and directories.

Find Log Files

find . -name "*.log"

Files Modified Within One Day

find /var/log -type f -mtime -1

Find Specific Directories

find . -type d -name "node_modules"

Find Large Files

find . -size +100M

grep vs find

This is a common beginner confusion.

grep

Searches inside file contents.

grep "ERROR" app.log

find

Searches for files and directories.

find . -name "*.log"

Piping Commands

One of Linux's greatest strengths is combining commands together.

The pipe operator (|) sends the output of one command as the input to another.

Find Error Messages

cat app.log | grep "ERROR"

Count Error Messages

cat app.log | grep "ERROR" | wc -l

Find Running Nginx Processes

ps aux | grep nginx

Search Command History

history | grep docker

Output Redirection

Redirection allows you to save command output into files.

Overwrite Output

echo "Deployment started" > deploy.log

Creates a new file or replaces existing content.

Append Output

echo "Step completed" >> deploy.log

Adds content to the end of the file.

More Examples

Save directory contents:

ls -la > files.txt

Save only error messages:

grep "ERROR" app.log > errors.log

Important Warning

Be careful when using:

It overwrites the file completely.

If you want to preserve existing content, use:

>>

Many engineers have accidentally overwritten important files by using the wrong operator.

Quick Command Reference

Command	Purpose
`chmod`	Change permissions
`chown`	Change ownership
`sudo`	Run commands as administrator
`cat`	Display file contents
`head`	View beginning of a file
`tail`	View end of a file
`tail -f`	Follow logs in real time
`grep`	Search inside files
`find`	Search for files and directories
`	`
`>`	Overwrite file output
`>>`	Append file output

Final Thoughts

Linux permissions, ownership, file searching, and command chaining are fundamental skills for every DevOps engineer.

The better you understand these concepts, the easier it becomes to troubleshoot servers, debug deployments, manage containers, and automate infrastructure.

I'm currently documenting my DevOps learning journey and will continue sharing beginner-friendly guides on Linux, Docker, Git, Kubernetes, Jenkins, Terraform, AWS, and more.

If you have any tips or favorite Linux commands, feel free to share them in the comments.

Happy Learning! 🐧🚀

🐧 Linux Basics Every Developer Should Know

Md Mohiuddin — Sun, 26 Jul 2026 15:21:43 +0000

If you're learning DevOps, Cloud, or Backend Development, Linux is a skill you simply can't avoid.

Most production servers run Linux. Docker containers run on Linux. Kubernetes is built around Linux. Even many cloud services are powered by Linux.

As part of my DevOps learning journey, I started with the Linux fundamentals. In this article, I'll share the concepts and commands every beginner should know.

What is Linux?

Linux is an open-source operating system kernel that acts as the bridge between software and hardware.

It manages resources like:

CPU
Memory
Storage
Devices
Running processes

Whenever you execute a command, Linux communicates with the hardware on your behalf.

Popular Linux Distributions

Linux comes in many distributions (often called distros), each designed for different use cases.

Debian-Based

Examples:

Ubuntu
Debian

Package Manager:

apt

These distributions are popular among developers because they're easy to use and have excellent community support.

Red Hat-Based

Examples:

Red Hat Enterprise Linux (RHEL)
CentOS
Fedora
Amazon Linux

Package Managers:

yum

dnf

These are commonly used in enterprise environments.

Alpine Linux

Package Manager

apk

Alpine is extremely lightweight and is widely used for Docker containers.

Understanding the Linux File System

Unlike Windows, Linux has a single directory tree that starts from the root directory.

/
├── bin/
├── boot/
├── dev/
├── etc/
├── home/
├── lib/
├── media/
├── mnt/
├── opt/
├── proc/
├── root/
├── sbin/
├── tmp/
├── usr/
└── var/

Here's what each directory is used for.

Directory	Purpose
`/bin`	Essential command binaries like `ls`, `cp`, and `cat`
`/boot`	Bootloader and Linux kernel
`/dev`	Device files (USB, disks, terminals, etc.)
`/etc`	System configuration files
`/home`	Home directories for normal users
`/lib`	Shared libraries used by applications
`/media`	Automatically mounted removable media
`/mnt`	Temporary mount point
`/opt`	Optional third-party software
`/proc`	Information about running processes
`/root`	Home directory of the root user
`/sbin`	System administration commands
`/tmp`	Temporary files
`/usr`	User applications and documentation
`/var`	Logs, caches, databases, and changing data

Navigating the File System

Show Current Directory

pwd

Displays your current working directory.

List Files

ls

Lists files and folders.

Detailed list:

ls -l

Include hidden files:

ls -la

Change Directory

Go to another directory:

cd /var/log

Go back one level:

cd ..

Go to your home directory:

cd ~

Return to the previous directory:

cd -

Understanding Paths

Absolute Path

Always starts from the root directory.

Example:

/home/mohiuddin/projects/app.py

No matter where you currently are, this path always points to the same file.

Relative Path

Relative paths depend on your current location.

Example:

projects/app.py

If you're already inside:

/home/mohiuddin

then both paths point to the same file.

Useful Shortcuts

Shortcut	Meaning
`.`	Current directory
`..`	Parent directory
`~`	Home directory
`cd -`	Previous directory

Basic File Operations

Create a Directory

mkdir project

Create nested directories:

mkdir -p project/src/components

Copy Files

cp file.txt backup.txt

Copy directories recursively:

cp -r folder1 folder2

Move or Rename Files

Rename:

mv old.txt new.txt

Move:

mv notes.txt /tmp/

Remove Files

Delete a file:

rm file.txt

Delete a directory:

rm -r folder

Force delete:

rm -rf folder

⚠️ Warning: rm -rf permanently deletes files without asking for confirmation. Always double-check the path before running it.

Create an Empty File

touch notes.txt

Display File Contents

cat notes.txt

Example output:

Today I learned Linux basics.

Quick Command Reference

Command	Description
`pwd`	Show current directory
`ls`	List files
`ls -la`	Show all files including hidden
`cd`	Change directory
`mkdir`	Create directory
`cp`	Copy files
`mv`	Move or rename files
`rm`	Remove files
`touch`	Create empty file
`cat`	Display file contents

Final Thoughts

Linux is one of the most valuable skills for software developers, especially if you're interested in DevOps, Cloud Computing, Docker, Kubernetes, or Backend Development.

These commands may seem simple, but you'll use them every day when working with servers and containers.

I'm currently documenting my DevOps learning journey, and I'll continue sharing beginner-friendly guides on Git, Docker, Kubernetes, Jenkins, Terraform, AWS, and more.

If you have any tips for Linux beginners, feel free to share them in the comments.

Happy Learning! 🐧

DEV Community: Md Mohiuddin

Pull Requests, Code Reviews & Git Rebase

Why This Matters

Understanding Pull Requests

What a Pull Request Contains

The Diff

Description and Context

Review Discussion

Automated Checks

Merge Controls

Why Pull Requests Exist

Quality Control

Knowledge Sharing

Historical Context

Automation Gateway

Creating a Pull Request

Step 1: Create a Feature Branch

Step 2: Make Changes and Commit

Step 3: Push the Branch

Step 4: Open the Pull Request

Writing Better PR Descriptions

What changed?

Why was it needed?

How was it tested?

What should reviewers focus on?

Code Reviews: How Professionals Review Code

Focus on the Code, Not the Person

Separate Requirements from Suggestions

Ask Questions

Receiving Review Feedback

Understanding .gitignore

Why .gitignore Matters

Example .gitignore

Never Commit Secrets

Why Deleting Later Doesn't Work

What Happens When Secrets Leak?

Prevention Best Practices

Git Rebase: An Alternative to Merge

Example

Before Rebase

After Rebase

Merge vs Rebase

The Golden Rule of Rebase

Final Thoughts

Git Branching & Merging: The Foundation of Team Collaboration in Git

Why Branching Matters

What Is a Git Branch?

How Branches Grow

Why Git Branches Are So Fast

Creating and Switching Branches

View Existing Branches

Create a New Branch

Switch to a Branch

Create and Switch in One Command

Delete a Branch

Branch Naming Best Practices

Understanding Git Merge

Fast-Forward Merge

Three-Way Merge

What Is a Merge Conflict?

Main Branch

Feature Branch

What a Conflict Looks Like

Understanding the Markers

Resolving Merge Conflicts

Step 1: Open the File

Step 2: Decide the Final Content

Step 3: Remove Conflict Markers

Step 4: Stage the Resolved File

Step 5: Complete the Merge

Don't Fear Merge Conflicts

Understanding Remote Repositories

Pushing Changes to GitHub

Pulling Changes From GitHub

What git pull Actually Does

Fetch

Merge

Why Pull Before Push?

Understanding GitHub Flow

Step 1: Create a Branch

What `git pull` Actually Does