DEV Community: Sreekanth Kuruba

Docker in Production: What Changes When Containers Meet Reality?

Sreekanth Kuruba — Wed, 26 Aug 2026 12:25:33 +0000

post 8:

You run a container.

It starts successfully.

The application works.

So… is it production-ready?

Not necessarily.

The real test of a production container isn't what happens when everything works.

It's what happens when something goes wrong.

What happens when the application consumes all available memory?

What happens when the process crashes?

What happens when the application is running, but isn't actually healthy?

Where do the logs go?

How do you know something is wrong before users tell you?

And when the container fails, how do you find the actual cause?

Running Docker in production isn't just about starting containers.

It's about making them reliable, observable, manageable, and recoverable.

1. Production Starts With Boundaries

A container that works perfectly on a developer's laptop can behave very differently under production load.

Development often prioritizes:

Speed
Convenience
Easy debugging
Frequent changes

Production prioritizes:

Reliability
Predictability
Security
Observability
Recovery

One of the first production questions is:

What happens if this container consumes more resources than expected?

That's where resource limits come in.

2. Resource Limits – Don't Let One Container Consume Everything

Without appropriate resource limits, a container can consume more host resources than intended.

For example:

docker run \
  --memory=512m \
  --cpus=1.0 \
  nginx

This limits the container to:

512 MB memory
1 CPU

Why does this matter?

Imagine one application suddenly starts consuming several gigabytes of memory.

Without appropriate limits, it could affect other workloads running on the same host.

Resource limits create boundaries between workloads.

But remember:

A resource limit doesn't fix a memory leak.

It only limits how much damage that container can cause to the host.

So now we have another question:

What if the container is running, but the application inside it is broken?

3. Health Checks – Running Doesn't Mean Healthy

One of the most important production concepts is the difference between:

Container is running

and

Application is healthy.

A container can be running while the application inside is:

Hung
Unable to connect to a database
Returning errors
Failing internal checks

Docker supports health checks.

For example:

HEALTHCHECK --interval=30s --timeout=5s \
  CMD curl -f http://localhost:8080/health || exit 1

Now Docker can track the application's health status.

The important idea is:

Process alive ≠ application healthy

A health check only reports the container's health status. Docker does not automatically restart a container simply because it becomes unhealthy.

An orchestrator or external health-monitoring tool is needed to take further action.

Health vs. Recovery

Situation	What happens
Process exits	A restart policy can restart the container
Health check becomes `unhealthy`	Docker reports the status; it doesn't automatically restart the container
Container repeatedly crashes	A restart policy may keep retrying
Application is unhealthy but still running	Monitoring or orchestration is needed to take further action

So what happens when the application actually crashes and exits?

That's where restart policies come in.

4. Restart Policies – What Happens After a Crash?

Applications crash.

Processes exit unexpectedly.

Production systems need a recovery strategy.

Docker provides restart policies such as:

docker run --restart=unless-stopped nginx

Common policies include:

no
on-failure
always
unless-stopped

For example:

--restart=on-failure

tells Docker to restart the container when it exits with a failure.

Notice the distinction:

Health check → reports health

Restart policy → reacts to container exits

A restart policy doesn't automatically fix an application that is alive but unhealthy.

And if an application crashes repeatedly, restarting it doesn't solve the underlying problem.

It simply keeps trying to recover.

Recovery and diagnosis are two different problems.

Which leads to another question:

When something fails, where is the evidence?

5. Logging – Keep the Evidence

When something fails in production, logs are often your first source of evidence.

Docker captures container output from:

stdout
stderr

You can inspect it with:

docker logs <container>

Follow logs in real time:

docker logs -f <container>

And limit the output:

docker logs --tail 100 <container>

But don't treat docker logs as your complete production logging strategy.

Docker's default json-file logging driver can grow over time and consume host disk space if log rotation isn't configured.

Production environments should consider log rotation using options such as:

max-size
max-file

For high-volume applications, a non-blocking logging mode can also help prevent logging from affecting application performance.

Larger environments may also send logs to a centralized logging system for:

Log retention
Search and filtering
Centralized access
Alerting

Logs are your first witness. Treat them like evidence, not decoration.

They tell you what happened. But what if you want to know what is happening right now?

6. Monitoring – Know Before Users Tell You

Logs tell you what happened.

Metrics help you understand what is happening.

At minimum, monitor things such as:

CPU usage
Memory usage
Network activity
Container restarts
Disk usage
Application response time
Error rates

Docker provides a simple starting point:

docker stats

This gives you a live view of container resource consumption.

But production monitoring usually goes further.

You want to know:

Is the application healthy before customers start reporting that it is broken?

That's where metrics, dashboards, and alerts become important.

But even with monitoring, failures will happen.

The next skill is knowing how to investigate them.

7. Troubleshooting – Don't Just Restart Everything

When a container isn't working, don't randomly restart everything.

Use a systematic approach.

Step 1: Check the container status

docker ps -a

Look for:

Exited containers
Restarting containers
Unexpectedly stopped services

Step 2: Check the logs

docker logs <container>

Look for:

Application errors
Configuration problems
Connection failures
Permission issues

Step 3: Inspect the container

docker inspect <container>

Check:

Environment variables
Mounts
Networks
Restart policies
Health status

Step 4: Check resource usage

docker stats

Look for:

High CPU
High memory
Unusual resource consumption

Step 5: Check networking

If the application cannot reach another service, verify:

Network configuration
Service/container name
Ports
DNS resolution
Connectivity between containers

Step 6: Check the image

Sometimes the problem isn't the container.

It's the image.

Check:

Image version
Recent changes
Application dependencies
Base image updates

The goal is to move from:

“The container isn't working.”

to:

“This specific component is failing for this specific reason.”

8. Image Versions – Know What You're Running

Consider:

FROM nginx:latest

It looks convenient.

But latest can change over time.

The same Dockerfile may produce different results later because the underlying image changed.

Using a known version gives you more predictable deployments:

FROM nginx:1.29

Production environments can go even further by using carefully controlled image versions or immutable image references.

The principle is simple:

Know exactly what you're deploying.

9. Smaller Images – Reduce What You Ship

Production images should contain only what the application needs.

Smaller images can provide:

Faster image pulls
Faster deployments
Smaller attack surface
Less unnecessary software

Multi-stage builds can help.

For example:

FROM node:22 AS build

WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

The build environment doesn't need to be included in the final runtime image.

This separates:

Build environment

from

Runtime environment

10. Make Containers Replaceable

Here's another important production mindset:

Containers should be replaceable, not precious.

Don't rely on manually changing files inside a running container as a permanent fix.

For example:

docker exec -it <container> bash

can be useful for troubleshooting.

But manually editing application files inside the container creates a change that disappears when the container is replaced.

Instead:

Change the configuration or code
Build a new image
Test it
Deploy the new version
Replace the old container

This makes deployments predictable and repeatable.

And this raises another important question:

What happens to data when the container disappears?

11. Separate Application Lifecycle From Data Lifecycle

Containers are usually treated as disposable.

Application data may not be.

For example:

Database data
Uploaded files
Application-generated persistent data

That's where Docker volumes or external storage come in.

The container can be replaced while the data remains.

This separation is important:

Application lifecycle ≠ Data lifecycle

The application can change.

The container can disappear.

The data should survive when it needs to.

12. Security Still Matters

Production reliability doesn't replace security.

The security principles from the previous article still apply:

Don't run applications as root when unnecessary
Avoid --privileged
Use appropriate capabilities
Keep images updated
Use seccomp and other security controls
Scan images
Limit container resources

A production container isn't secure simply because it is running.

Reliability, security, and observability have to work together.

13. A Practical Production Checklist

Before running a container in production, ask:

[ ] Is the image version controlled?
[ ] Is the container running as a non-root user where possible?
[ ] Are CPU and memory limits defined?
[ ] Is a health check configured?
[ ] Is an appropriate restart policy configured?
[ ] Is log rotation configured?
[ ] Are important metrics being monitored?
[ ] Are alerts configured for critical failures?
[ ] Is persistent data stored outside the container filesystem?
[ ] Can the container be safely replaced?
[ ] Is the image regularly updated and scanned?
[ ] Is there a documented troubleshooting process?

You don't need every advanced platform feature on day one.

But you should know what happens when something goes wrong.

Summary

Running Docker in production isn't simply:

docker run

It's about designing for what happens after the container starts.

You need to think about:

Resources → How much can the container consume?
Health → Is the application actually working?
Recovery → What happens when it crashes?
Logs → Where is the evidence?
Monitoring → How do we know something is wrong?
Troubleshooting → How do we find the cause?
Images → Do we know exactly what we're deploying?
Data → What survives when the container disappears?
Security → What privileges does the workload actually need?

A container that runs successfully is only the beginning.

Production readiness starts when you ask what happens when things go wrong.

Question for You

What's the first thing you check when a Docker container fails in production — logs, resources, health status, or something else?

Next Topic

Rootless Docker & Advanced Security: Running Containers With Fewer Privileges

Think `docker compose up` just starts containers? There’s more happening behind the scenes. And one common assumption about `depends_on` can cause real problems. I break down what Compose actually does—and what it doesn’t.

Sreekanth Kuruba — Tue, 18 Aug 2026 08:10:23 +0000

Sreekanth Kuruba

Aug 18

Docker Compose Isn't What I Thought It Was

#docker #devops #containerization #cloudnative

3 min read

Docker Compose Isn't What I Thought It Was

Sreekanth Kuruba — Tue, 18 Aug 2026 03:21:36 +0000

post 7:

A practical guide to understanding Docker Compose—what it is, how it works, and the misconceptions that catch most beginners.

You've mastered single containers.

Now it's time to build a real application.

A frontend.
A backend.
A database.
A Redis cache.

Suddenly you're juggling multiple docker run commands.

Ports.
Networks.
Volumes.
Environment variables.

Chaos.

Then someone says:

"Just use Docker Compose."

It works beautifully.

But here's the twist most people never realize…

Why Docker Compose Exists

Imagine starting an application like this:

Frontend
Backend
PostgreSQL
Redis

Running each container manually quickly becomes repetitive and error-prone.

Docker Compose lets you describe your entire application in a single YAML file and start everything with one command.

Instead of remembering dozens of commands, you define your infrastructure once.

What Docker Compose Actually Is

Docker Compose is not a container orchestrator.

Docker Compose is a tool that reads your Compose YAML file and uses the Docker Engine to create and manage the resources defined in it.”

Modern Docker uses Compose V2, which runs as:

docker compose

instead of the older:

docker-compose

Compose runs only when you execute a command.

It creates the required Docker resources, starts the containers, and then exits.

This makes it ideal for development, testing, and single-host deployments, but it doesn't provide orchestration features like automatic scheduling, self-healing, or multi-node management.

A Simple docker-compose.yml

services:
  web:
    build: .
    ports:
      - "8080:80"
    environment:
      - DB_HOST=db
    depends_on:
      - db

  db:
    image: postgres:15
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:alpine

volumes:
  postgres_data:

YAML Quick Reference

Key	Purpose
services	Defines containers (web, db, redis)
build	Builds an image from a Dockerfile
image	Uses an existing image from a registry
ports	Maps host ports to container ports
environment	Sets environment variables
depends_on	Controls startup order
volumes	Stores persistent data

What Happens When You Run docker compose up?

docker-compose.yml
        ↓
Compose reads the YAML
        ↓
Creates networks
        ↓
Creates volumes
        ↓
Builds images (if needed)
        ↓
Starts containers
        ↓
Application is running

One command replaces many manual docker run commands.

Modern Compose Features

1. Profiles

Profiles let you enable optional services only when needed.

For example, if your Compose file has a service assigned to the cache profile:

redis:
  image: redis:alpine
  profiles:
    - cache

You can start it with:

docker compose --profile cache up

Useful for:

Development-only services
Optional tools
Testing environments

2. Watch (Compose V2)

develop:
  watch:
    - action: sync
      path: ./src
      target: /app/src

Run:

docker compose watch

Compose automatically syncs file changes without rebuilding the container.

(Available in recent Docker Compose V2 releases.)

The Biggest Gotcha

Many beginners believe this:

depends_on:
  - db

means

"The database is ready."

It doesn't.

It only means

"The database container has started."

The application inside may still be initializing.

A better approach is to combine startup ordering with health checks or design your application to retry connections until dependencies are available.

Common Expectations vs Reality

Expectation	Reality
Compose is a production orchestrator	It's primarily a development and single-host deployment tool
`depends_on` waits for the application	It only waits for the container to start
Automatic scaling	Manual
Self-healing	Not provided
Multi-node orchestration	Not supported
Hot reload	Supported with `docker compose watch` (Compose V2)

Simple Mental Model

Think of Docker Compose as a project manager.

Instead of starting every container one by one, Compose reads a blueprint and launches everything in the correct configuration.

It doesn't replace Docker.

It simply coordinates Docker for you.

Summary

In this guide you learned:

Why Docker Compose exists
What Compose actually is
Compose V2 vs the old Compose V1
Understanding services, build, image, ports, environment, depends_on, profiles, networks, and volumes
What happens during docker compose up
Modern features like Profiles and Watch
Common misconceptions about Compose

Why This Matters

Docker Compose is one of the most valuable tools for local development.

It lets developers spin up complete applications with a single command, making multi-container development simple and repeatable.

As applications grow across multiple servers and require features like automatic scaling, self-healing, and high availability, orchestration platforms such as Kubernetes become the next step.

Question for You

What's the biggest misconception you had about Docker Compose?

Or what's one feature you wish you had discovered sooner?

Docker Security Internals: How Safe Are Your Containers Really?

Sreekanth Kuruba — Tue, 11 Aug 2026 07:27:40 +0000

post 6:

You run containers every day.

But have you ever asked yourself this uncomfortable question:

If one container gets compromised… can it break out and take down the entire host?

Most people assume containers are “secure by default.”

They’re not.

They’re isolated by default — and isolation is not the same as security.

This post explains how Docker security actually works under the hood, what the real risks are, and how to harden your containers properly.

1. The Foundation: Linux Kernel Features

Docker doesn’t invent its own security model.

It relies heavily on existing Linux kernel features:

Namespaces → Isolation of processes, network, filesystem, and more
cgroups → Resource limits for CPU, memory, and I/O
Capabilities → Fine-grained control over root privileges
seccomp → Filtering of potentially dangerous system calls
AppArmor / SELinux → Mandatory Access Control

Understanding these layers is the key to understanding container security.

2. Namespaces – Isolation, Not Security

Namespaces give each container its own private view of the system.

For example:

PID namespace → Container processes are isolated from host processes
Network namespace → Container gets its own network stack
Mount namespace → Container gets its own filesystem view
User namespace → Container users can be mapped to unprivileged users on the host

This isolation is powerful — but it isn't perfect.

All containers still share the same Linux kernel.

That means a serious kernel vulnerability could potentially affect the host and other containers.

Namespaces provide isolation, not complete security.

3. cgroups – Preventing Resource Exhaustion

Namespaces control what a container can see.

cgroups control how much of the host's resources it can consume.

Without resource limits, a single container could potentially:

Consume excessive CPU
Exhaust available memory
Generate excessive disk I/O

For example:

docker run --memory=512m --cpus=1.0 nginx

Here:

--memory=512m limits memory usage
--cpus=1.0 limits CPU usage

This helps prevent one container from consuming an unreasonable amount of the host's resources.

4. The Root Problem – Still Real

By default, many containers run as root (UID 0) inside the container.

However, Docker starts containers with a reduced set of Linux capabilities, limiting what that root process can do.

This significantly reduces the attack surface.

But container root is still something to take seriously.

If an application is compromised and has excessive privileges, combined with a kernel or runtime vulnerability, an attacker could potentially attempt a container escape.

A good practice is to run applications as a non-root user whenever possible.

For example, in a Dockerfile:

FROM nginx:alpine

USER 1000

Also avoid using:

--privileged

unless there is a specific, well-understood requirement.

The --privileged option grants a container significantly more access to the host and disables or weakens several isolation protections.

5. seccomp – Blocking Dangerous System Calls

seccomp (Secure Computing Mode) is another important Docker security layer.

Applications interact with the Linux kernel through system calls.

A compromised application could potentially try to use unusual or dangerous system calls to interact with the kernel.

Docker provides a default seccomp profile that blocks many system calls that containers typically don't need.

You can also apply a custom, stricter profile:

docker run \
  --security-opt seccomp=/path/to/custom-profile.json \
  nginx

This can further reduce the container's attack surface.

The key idea is simple:

If an application doesn't need a system call, don't give it access to that system call.

6. Rootless Docker – Reducing Host-Level Risk

Traditional Docker deployments commonly use a Docker daemon that requires root privileges.

This creates an important security consideration because access to the Docker daemon can provide powerful control over containers and, depending on configuration, the host.

Rootless Docker allows the Docker daemon and containers to operate without requiring root privileges.

Container root can be mapped to an unprivileged user on the host.

This reduces the potential impact of certain container or daemon compromises.

Rootless Docker is particularly useful in environments where reducing host-level privileges is important, although it can have some feature and compatibility limitations.

7. Practical Docker Hardening Checklist

Here are some practical steps you can apply:

Run containers as a non-root user whenever possible
Use official and regularly updated base images
Enable Rootless Docker when it fits your environment
Use --read-only for the container filesystem when the application allows it
Set resource limits such as --memory and --cpus
Keep Docker's default seccomp profile unless you have a reason to change it
Use AppArmor or SELinux where appropriate
Scan images regularly with tools such as Trivy or Docker Scout
Avoid --privileged unless there is a specific requirement
Keep Docker Engine and container images updated

Security is not achieved by using just one of these controls.

It comes from multiple layers working together.

Summary

Docker security is not magic.

It is a combination of multiple Linux and Docker security mechanisms:

Namespaces → Process and resource isolation
cgroups → Resource control
Capabilities → Privilege reduction
seccomp → System call filtering
AppArmor / SELinux → Mandatory Access Control
Rootless Docker → Reduced host-level privileges

Default Docker settings provide a useful level of isolation, but production environments often require deliberate security hardening.

The important thing to remember is:

Containers are isolated, but isolation alone does not make them secure.

Understanding what happens underneath Docker helps you move from:

“It works.”

“It works — and it’s properly secured.”

Next Topic

Docker Compose Internals – How It Orchestrates Multi-Container Applications

Linux Troubleshooting Workflow for Beginners: A Step-by-Step Guide

Sreekanth Kuruba — Tue, 04 Aug 2026 06:18:32 +0000

Most Linux problems aren't actually difficult.

They're difficult because they're often debugged in the wrong order.

Many beginners immediately:

Restart services randomly
Run commands without a plan
Change configurations before understanding the problem
Guess instead of observing

Experienced engineers do something different.

They follow a structured troubleshooting process.

This article isn't about learning new Linux commands.

It's about knowing when and why to use the commands you've already learned throughout this Linux Beginner Series.

Think of it as putting everything together into one practical troubleshooting workflow that's used in real Linux and DevOps environments.

Quick Troubleshooting Workflow

Observe
   ↓
Check System Health
   ↓
Identify Problem Type
   ↓
Read Logs
   ↓
Verify Service
   ↓
Check Network
   ↓
Check Disk
   ↓
Recent Changes
   ↓
Find the Root Cause
   ↓
Apply the Fix

Keep this workflow in mind as you read through the guide.

Step 0: Observe Before You Change Anything

Before running a single command, pause for a moment.

Ask yourself:

What exactly is broken?
When did the issue start?
Is everyone affected or only some users?
Is the problem constant or intermittent?
What changed recently?

Many troubleshooting sessions become longer because people try to fix the problem before they understand it.

Good troubleshooting begins with observation, not commands.

Step 1: Check Overall System Health

Your first goal is to understand the overall health of the system—not to fix anything yet.

Useful commands:

uptime
free -h
top

Look for:

High load average
High CPU usage
Low available memory
Signs that the server is under heavy load

At this stage, you're only gathering evidence.

A quick system health check often tells you where to investigate next.

Step 2: Identify the Type of Problem

Before diving deeper, classify the issue.

Problem Type	Common Symptoms	First Commands to Check
CPU	Slow system, high CPU usage	`top`, `htop`
Memory	Applications crashing, OOM kills	`free -h`
Disk	"No space left on device"	`df -h`, `du -sh`
Network	Connection failures	`ping`, `curl`, `ip a`
Service	Service unavailable	`systemctl status`
Application	Errors or exceptions	Application logs

Classification narrows your investigation instead of jumping between unrelated commands.

A well-classified problem is already half solved.

Step 3: Read the Logs

Logs are usually the most reliable source of information during troubleshooting.

System logs:

journalctl -xe

Specific service:

journalctl -u nginx

Traditional log files:

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

Search for errors:

grep -i error /var/log/syslog

For large log files, use less to navigate comfortably instead of opening the entire file at once.

💡 Tip: Replace nginx with the service you're troubleshooting, such as sshd, docker, or apache2.

Logs often tell you what failed.

Your job is to discover why it failed.

Step 4: Verify the Service

Never assume a service is healthy just because the application isn't responding.

Check the service status:

systemctl status nginx

Verify the running process:

ps aux | grep nginx

A service can be running while still failing to serve requests correctly.

For example:

The process may be running.
The application may have failed during startup.
The service may be unable to connect to its database.
Configuration errors may prevent it from serving requests.

Always verify the service before moving on to other areas.

Step 5: Check the Network

If the service looks healthy, verify connectivity.

Useful commands:

ping <host>
curl -I http://localhost:8080
ip a
ss -tuln

These commands help answer questions like:

Can the server reach other systems?
Is the application listening on the expected port?
Is the network interface configured correctly?

Many "application issues" are actually network or DNS problems.

Step 6: Check Disk Space and Inodes

Disk-related problems are among the most common causes of Linux issues.

Check disk usage:

df -h

Check inode usage:

df -i

Find large directories:

du -sh /* 2>/dev/null | sort -hr

A full disk—or exhausted inodes—can prevent applications from:

Writing log files
Creating temporary files
Saving uploaded data
Starting correctly

Even if CPU and memory look healthy, disk issues can bring an application down.

Step 7: Look for Recent Changes

Many production issues are caused by something that recently changed.

Review recent logs:

journalctl --since "1 hour ago"

Check recent logins:

last -10

Ask yourself:

Was there a recent deployment?
Was a configuration changed?
Was a package updated?
Did anyone restart the service?

If you need to locate a configuration file, use tools like find or whereis.

Before making major configuration changes, consider creating a backup with tar so you can easily restore the original if needed.

Looking for recent changes often shortens the investigation dramatically.

Step 8: Find the Root Cause, Not Just the Symptom

Finding an error doesn't always mean you've found the real problem.

For example:

A web application crashes.

The logs show write failures.

You check the disk.

The disk is full.

The application wasn't the real problem.

The full disk was.

Always ask yourself:

"Is this the root cause, or just another symptom?"

This habit separates troubleshooting from guessing.

A Simple Troubleshooting Workflow

Whenever something breaks, follow the same sequence:

Observe the problem
        ↓
Check system health
        ↓
Identify the problem type
        ↓
Read the logs
        ↓
Verify the service
        ↓
Check the network
        ↓
Check disk space
        ↓
Look for recent changes
        ↓
Find the root cause
        ↓
Apply the fix

Following the same workflow every time reduces guesswork and speeds up troubleshooting.

A Real-World Example

Imagine a user reports:

"The website is down."

Instead of restarting Nginx immediately:

Check whether the service is running.
Read the service logs.
Notice repeated "No space left on device" errors.
Run:

df -h

Discover the disk is full.
Free up disk space.
Restart the service if necessary.

The restart wasn't the solution. Finding the root cause was.

Common Beginner Mistakes

Avoid these habits:

Restarting services without checking logs
Ignoring CPU, memory, or disk usage
Running random commands without a plan
Assuming the first error is the real cause
Skipping recent changes

Good troubleshooting isn't about memorizing commands.

It's about following a consistent process.

Final Thoughts

Linux troubleshooting isn't about knowing hundreds of commands.

It's about asking the right questions in the right order.

Commands help you collect evidence.

A structured process helps you solve the problem.

The faster you narrow down the problem, the faster you'll reach the root cause.

That's the mindset experienced engineers develop over time.

Start with a simple process.

Practice it consistently.

You'll spend less time guessing and more time solving problems.

Congratulations!

If you've followed this Linux Beginner Series from the beginning, you've built a solid foundation in:

Linux basics
Filesystem structure
Users & Permissions
Processes
Disk usage
Networking
Logs
Package management
Finding files & text
Viewing files efficiently
File compression
Troubleshooting workflow

That's no longer just a collection of Linux commands.

It's a practical foundation for understanding how Linux systems work and how to troubleshoot them with confidence.

Remember:

Good engineers don't memorize every command.

They know how to investigate problems, gather evidence, and find the root cause.

The best way to improve at troubleshooting is simple:

Break things in a safe environment.
Fix them.
Learn from them.

That's where real learning happens.

Thank you for following this Linux Beginner Series!

Your Turn

What's one Linux troubleshooting lesson you learned the hard way?

Share your experience in the comments—your story might help another beginner avoid the same mistake.

Happy learning!

File Compression in Linux Explained Simply (tar, gzip, zip & unzip)

Sreekanth Kuruba — Thu, 30 Jul 2026 06:44:14 +0000

Working with files in Linux isn't just about creating and editing them.

Sometimes you need to:

Archive multiple files into one
Compress files to save disk space
Share files with others
Create backups

Linux provides several tools for this, each with a different purpose.

Let's simplify them.

What is File Compression?

File compression reduces the size of a file.

Benefits:

Saves disk space
Faster file transfers
Easier backups
Reduces bandwidth usage

Example:

A 100 MB log file might become a much smaller compressed file, depending on its contents.

Archive vs Compression

Many beginners think they're the same.

They are not.

Archive

Combines multiple files into a single file.

Example:

photos/
docs/
notes.txt

↓

backup.tar

Compression

Reduces the size of a file.

Example:

backup.tar

↓

backup.tar.gz

👉 tar archives files. gzip compresses them.

1. Create an Archive with tar

tar -cvf backup.tar Documents/    #Create an archive
tar -tvf backup.tar               #View archive contents
tar -xvf backup.tar               #Extract an archive

Options:

c → Create
v → Verbose (show progress)
f → File name
x → Extract

Best for:

Backups
Bundling multiple files
Moving folders

2. Compress with gzip

Compress a file:

gzip file.txt          # Creates file.txt.gz
# Result
file.txt.gz
gunzip file.txt.gz     # decompress
gzip -k file.txt       # Keep original file

Best for:

Log files
Large text files
Saving disk space

3. Archive and Compress Together

Most common command:

# Create compressed archive
tar -czvf backup.tar.gz Documents/
# Extract
tar -xzvf backup.tar.gz

Options:

z → Use gzip compression

👉 This is one of the most common backup commands in Linux.

4. Working with ZIP Files

# Create ZIP
zip -r project.zip project/
# Extract
unzip project.zip
# List contents
unzip -l project.zip

Best for:

Sharing files with Windows users
Cross-platform compatibility

5. Compare the Tools

Tool	Purpose	Best For
`tar`	Archive files	Backups
`gzip`	Compress files	Saving space
`tar + gzip`	Archive and compress	Linux backups
`zip`	Archive and compress	Sharing files across operating systems

Real-World Example

You need to back up a website before making changes.

# Create backup
tar -czvf website-backup.tar.gz /var/www/html
# Restore later if needed
tar -xzvf website-backup.tar.gz

This is a common practice before upgrades, migrations, or configuration changes.

Common Beginner Mistakes

Thinking tar compresses files by itself
Forgetting -z when creating .tar.gz archives
Compressing files that are already compressed (like .jpg or .mp4)
Extracting archives into the wrong directory
Deleting backups before verifying they can be restored

Simple Mental Model

Think of it like packing for a trip:

tar → Put all your clothes into one suitcase.
gzip → Compress the suitcase to make it smaller.
tar.gz → Pack everything into one suitcase and compress it.
zip → A suitcase that's easy to share with almost any operating system.

Summary

In this guide you learned:

What file compression is
Archive vs. compression
Creating archives with tar
Compressing files with gzip
Creating .tar.gz archives
Working with ZIP files
Common beginner mistakes

Why This Matters

File compression is used every day by:

Linux administrators
DevOps engineers
Cloud engineers
Developers

Whether you're creating backups, transferring files, or saving disk space, understanding these tools is an essential Linux skill.

Congratulations!
You’ve now covered the essential Linux fundamentals.

In the next and final post, we’ll combine everything from this series into a practical troubleshooting workflow you can use to diagnose Linux issues with confidence.

Next Post

Linux Troubleshooting Flow for Beginners

Question for You

Which compression format do you use most often: .tar.gz or .zip? And in what situation?

Viewing Files in Linux Explained Simply (cat, less, head, tail & wc)

Sreekanth Kuruba — Tue, 21 Jul 2026 06:38:18 +0000

Introduction

Finding a file is only half the job.

The next step is reading it.

Whether it's a configuration file, a log, or a text document, Linux provides several commands to view files efficiently.

Each command has a different purpose.

Knowing which one to use can save time and make troubleshooting much easier.

Let's simplify them.

Why Not Just Use cat for Everything?

Many beginners learn:

cat filename

Then use it for every file.

It works...

Until the file has 50,000 lines.

Linux provides better tools depending on what you're trying to do.

1. View the Entire File with cat

The cat command displays the complete contents of a file.

Example:

cat config.txt
cat file1.txt file2.txt     # Combine files
cat > notes.txt             # Create new file

Best for:

Small files
Quick checks
Combining files

2. Read Large Files with less

Large files are difficult to read with cat.

Use:

less /var/log/syslog
less /etc/nginx/nginx.conf

Useful shortcuts:

Space → Next page
b → Previous page
/text → Search
q → Quit

Best for:

Configuration files
Large logs
Documentation

3. View the Beginning with head

Sometimes you only need the first few lines.

head file.txt
head -20 file.txt          # First 20 lines

Useful for:

Checking file headers
Previewing files

4. View the End with tail

Need the latest log entries?

tail file.txt
tail -20 file.txt          # Last 20 lines

Perfect for log files.
Checking recent changes.

5. Monitor Files Live with tail -f

One of the most-used Linux troubleshooting commands.

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

As new lines are written, they appear instantly.

Stop with:

Ctrl + C

Useful for:

Monitoring logs
Watching application output
Debugging services

6. Count with wc

Want to know how big a file is?

wc file.txt
wc -l file.txt             # Count only lines
wc -w file.txt             # Count words
wc -m file.txt             # Count characters

Useful for:

Scripts
Reports
Log analysis

Real-World Example

An application isn't starting.

First, check the configuration file:

# First, check the configuration file:
less /etc/nginx/nginx.conf

# Monitor the error log:
tail -f /var/log/nginx/error.log

# Need to know how many errors occurred?
grep -i error app.log | wc -l

This is a common workflow when troubleshooting Linux systems.

Common Beginner Mistakes

Using cat for huge files
Forgetting less supports searching
Not using tail -f for live logs
Thinking head and tail only work with 10 lines

Simple Mental Model

Think of these commands like reading a book.

Command	Think of it as...
`cat`	Read the whole book
`less`	Read page by page
`head`	Read the first page
`tail`	Read the last page
`tail -f`	Watch new pages being written
`wc`	Count pages, words, or characters

Summary

In this guide you learned:

cat → View complete files
less → Read large files
head → View the beginning
tail → View the end
tail -f → Monitor files live
wc → Count lines, words, and characters

Why This Matters

Configuration files and logs are everywhere in Linux.

Knowing how to read them efficiently is an essential skill for developers, system administrators, and DevOps engineers.

The right command can save time and make troubleshooting much easier.

Next Post

File Compression in Linux Explained Simply (tar, gzip, zip & unzip)

Question for You

Which command do you use the most when reading files in Linux?

cat
less
tail
Or something else?

Finding Files & Text in Linux Explained Simply (find, grep, which & whereis)

Sreekanth Kuruba — Tue, 14 Jul 2026 03:03:02 +0000

One of the most common questions Linux beginners ask is:

“Where is this file?”
“How do I find a specific error in logs?”
“Where is this command installed?”

Linux has powerful tools to answer these questions quickly.

In this guide, you’ll learn the most useful search commands.

Finding Files vs Searching Text

These are two different tasks:

Finding files = Locating a file or directory on the system → find
Searching text = Looking for words inside files → grep

1. Find Files with `find`

# Find a specific file
find /home -name "nginx.conf"

# Search entire system (ignore permission errors)
find / -name "*.log" 2>/dev/null

# Find only directories
find . -type d

# Find only files
find . -type f

# Find files larger than 100MB
find / -type f -size +100M 2>/dev/null

Useful for:

Finding configuration files
Locating log files
Finding large files
Searching project directories

Best Tip: Always try to narrow the search path instead of searching from / whenever possible.

2. Search Text Inside Files with `grep`

# Search for a word
grep error app.log

# Case insensitive search
grep -i error app.log

# Search recursively in directory
grep -r "database" /etc/

# Show line numbers
grep -n "listen" nginx.conf

# Count matches
grep -c "failed" auth.log

Useful for:

Searching logs
Finding configuration values
Looking for error messages
Debugging applications

3. Find Executable Location with `which`

which python3
which docker
which nginx

Shows the full path of the command that will be executed.

Useful for:

Finding executable locations
Checking which version of a command Linux will run
Verifying software installation

4. Find Program Files with `whereis`

whereis nginx
whereis python3

It can show:

Binary location
Source files (if available)
Manual pages

Useful when you want to know where a program and its documentation are stored.

Bonus: Fast File Search with `locate`

locate nginx.conf

Much faster than find because it uses a database.

If it doesn't return recent files, Update database:

sudo updatedb

Note: locate may not be installed by default on every Linux distribution.

Real-World Troubleshooting Example

Nginx is not starting.

# Find config file
find /etc -name nginx.conf 2>/dev/null

# Search for errors in logs
grep -i error /var/log/nginx/error.log

# Check executable
which nginx

# See all related files
whereis nginx

This is a common workflow during Linux troubleshooting.

Common Beginner Mistakes

Using find / instead of a specific directory
Forgetting 2>/dev/null when searching the whole system
Confusing find with grep
Not knowing the difference between which and whereis
Forgetting that locate may require an updated database

Simple Mental Model

Command	Use For
`find`	Locate files and directories
`grep`	Search text inside files
`which`	Find executable path
`whereis`	Find program + docs
`locate`	Fast filename search

Summary

In this guide you learned:

How to find files with find
How to search text with grep
How to locate commands with which and whereis
How to perform fast filename searches with locate

Next Post:

Viewing Files in Linux (cat, less, head, tail & wc)

Question for You

Which command do you use most while troubleshooting — find, grep, or something else?

Linux Package Management Explained Simply (apt, dnf, yum & rpm)

Sreekanth Kuruba — Tue, 07 Jul 2026 03:13:00 +0000

Quick Note

In my previous article, I mentioned that Linux Troubleshooting Flow for Beginners would be the final post in this series.

While preparing it, I realized there were a few practical Linux skills every beginner should learn first. These topics will make the troubleshooting guide much easier to understand and follow.

Before we wrap up the series, we'll cover:

Package Management
Finding Files & Text
Viewing Files Efficiently
File Compression

Then we'll bring everything together in the final Linux Troubleshooting Flow for Beginners.

Introduction

Installing software on Linux is very different from Windows.

On Windows, you usually download an .exe installer.

On Linux, software is typically installed and managed using package managers.

This is one of the most practical skills every Linux beginner should learn early.

What is a Package?

A package is a ready-to-install bundle that contains:

The main program
Required libraries
Configuration files
Documentation

Examples: nginx, git, docker, curl, vim

Think of a package as a ready-to-install software box.

What is a Package Manager?

A package manager is a tool that installs, updates, removes, and manages software packages.
Instead of downloading software manually, you simply run a command.

Example:

sudo apt install git

The package manager automatically:

Downloads packages from trusted repositories
Install required dependencies automatically
Upgrade installed software
Removes them cleanly

Instead of manual downloading, you just run one command.

Why Use a Package Manager?

Without package managers, you would have to:

Search for software manually
Download files from websites
Install dependencies yourself
Update each application separately

Package managers automate all of this.

What is a Repository?

Package managers download software from repositories.

A repository is a trusted online collection of software packages maintained by your Linux distribution.

Instead of downloading software from random websites, Linux installs it securely from these repositories.

Common Package Managers

Distribution	Package Manager	Low-level Tool
Ubuntu / Debian	`apt`	`dpkg`
Fedora / RHEL / Rocky	`dnf`	`rpm`
Older RHEL / CentOS	`yum`	`rpm`

Most Ubuntu users will use apt, while Fedora and modern RHEL-based systems use dnf.

Most Useful Commands

1. Update Package List

Before installing software, update the package list.

sudo apt update          # Ubuntu/Debian
sudo dnf check-update    # Fedora/RHEL

Note: apt update does not upgrade installed packages.

2. Upgrade Installed Packages

sudo apt upgrade   #Ubuntu/Debian
sudo dnf upgrade   #Fedora/RHEL

Installs the latest available versions of your installed packages.

3. Install a Package

sudo apt install nginx   #Ubuntu/Debian
sudo dnf install nginx   #Fedora/RHEL

Example packages:

sudo apt install git
sudo apt install curl
sudo apt install vim

4. Remove a Package

sudo apt remove nginx    #Ubuntu/Debian
# Remove package and configuration files
sudo apt purge nginx     
sudo dnf remove nginx    #Fedora/RHEL

5. Search for Packages

apt search docker    #Ubuntu/Debian
dnf search docker    #Fedora/RHEL

Useful when you're unsure of the exact package name.

6. View Package Information

apt show nginx    #Ubuntu/Debian
dnf info nginx    #Fedora/RHEL

Shows details such as:

Version
Description
Dependencies
Package size

7. List Installed Packages

apt list --installed   #Ubuntu/Debian
dnf list installed     #Fedora/RHEL

Useful for verifying whether software is already installed.

Low-Level Tool: rpm

The rpm command works directly with RPM package files.

rpm -q nginx          # Check if installed
rpm -qi nginx         # Detailed info

Usually you don't need to use rpm directly. On RPM-based systems, dnf handles package installation and dependencies for you.

Common Beginner Mistakes

Running apt upgrade without apt update first
Confusing apt update with apt upgrade
Installing software from random websites instead of official repositories
Forgetting to use sudo
Removing important system packages

Simple Mental Model

Think of a package manager like an App Store for Linux:

Package = App
Repository = App Store
Package Manager = Installer + Updater

Summary

In this guide you learned:

What packages and package managers are
Basic package management commands using apt and dnf
Basic package management commands
Common mistakes to avoid

Why This Matters

Package management is a daily task for:

Linux administrators
DevOps engineers
Cloud engineers
Developers

If you know how to manage packages, setting up and maintaining Linux systems becomes much easier.

Next Post:

Finding Files & Text in Linux Explained Simply (find, grep, which & whereis)

Linux Logs Explained Simply

Sreekanth Kuruba — Tue, 30 Jun 2026 03:22:27 +0000

post: 7

When something breaks in Linux, experienced engineers don’t guess.

They check the logs.

👉 Logs are the “black box recorder” of a Linux system.

They tell you:

what happened
when it happened
why it failed

If you can read logs properly, you can debug almost anything.

What Are Logs?

Logs are records of system and application activity.

Linux constantly records:

System events
Errors
User activity
Application behavior

Linux constantly records:

Where are Logs Stored?

Most Linux logs are stored inside:

/var/log

Check logs directory:

cd /var/log
ls

This is the first place DevOps engineers check during system issues.

Important Log Files

Log File	Purpose	Command to View
`/var/log/syslog`	General system messages	`tail /var/log/syslog`
`/var/log/auth.log`	Login attempts & authentication	`tail /var/log/auth.log`
`/var/log/kern.log`	Kernel & hardware messages	`dmesg` or `tail /var/log/kern.log`
`/var/log/nginx/error.log`	Web server errors (Nginx)	`tail /var/log/nginx/error.log`
`/var/log/dmesg`	Boot and hardware logs	`dmesg`

/var/log/apache2/ -> Apache logs

These logs help you identify system, security, and application-level issues.

View Logs

Using cat

cat /var/log/syslog

Good for small files.

Using less

less /var/log/syslog

Useful keys::

Space → Next page
b → Previous page
q→ Quit

👉 Best for large log files.

Using tail

tail /var/log/syslog

Show last 10 lines.

Real-Time Monitoring (tail -f)

tail -f /var/log/syslog

👉 -f = follow live updates

This is one of the most-used debugging commands in production servers.

Stop with:

Ctrl + C

Searching Logs with grep

grep error /var/log/syslog

Case-insensitive:

grep -i failed /var/log/auth.log

Show latest matching errors:

grep error /var/log/syslog | tail -n 50

👉 Essential for filtering huge logs quickly.

Boot & Hardware Logs (dmesg)

dmesg

Shows:

Boot messages
Hardware detection
Kernel events

Useful for startup and hardware troubleshooting.

Modern Log System: journalctl

Modern Linux systems use systemd logs.

journalctl

Recent errors:

journalctl -xe

Specific service logs:

journalctl -u nginx

Live monitoring:

journalctl -f

Last 1 hour:

journalctl --since "1 hour ago"

👉 journalctl is the modern replacement for many traditional log files.

What is Log Rotation?

Logs grow continuously.

Without cleanup:

disks fill up
systems slow down

Linux automatically rotates logs using:

logrotate

👉 Old logs are compressed or removed automatically.

Real-Life Troubleshooting Example

Problem: Website is not working.

systemctl status nginx
tail -f /var/log/nginx/error.log
journalctl -u nginx -xe

👉 In real systems, logs usually reveal the exact root cause.

⚠️ Common Beginner Mistakes

guessing instead of checking logs
using cat on huge files
deleting logs blindly
ignoring tail -f
assuming service is healthy because it says “active”

Simple Mental Model

Think of logs like CCTV recordings:

system logs → building activity
auth logs → door access records
kernel logs → hardware monitoring
app logs → employee activity

👉 Debugging Linux = investigating evidence

Summary

what logs are
where logs are stored (/var/log)
important log files
cat, less, tail
live monitoring with tail -f
searching logs with grep
boot logs using dmesg
modern logging with journalctl
log rotation basics

Why Logs Matter

Logs are the foundation of:

Linux troubleshooting
DevOps debugging
production incident response
server monitoring
security analysis

👉 The better you read logs, the faster you solve problems.

End of Linux Beginner Series

You now learned:

Linux basics
filesystem structure
permissions
users & groups
processes
disk usage
networking
logs & troubleshooting

That’s already more Linux knowledge than most beginners have.

Final Next Step:
Linux Troubleshooting Flow for Beginners

Final Question

Which topic in this Linux series helped you the most?

And what Linux topic should the next series cover?

How CoreDNS Powers Service Discovery in Kubernetes

Sreekanth Kuruba — Tue, 23 Jun 2026 12:00:47 +0000

CoreDNS is the DNS server that powers service discovery in Kubernetes. This post explains how Pods translate Service names into IP addresses, explores common DNS records, and provides practical troubleshooting commands for debugging connectivity issues.

In the previous post, we learned how Kubernetes Services provide stable virtual IPs for Pods.

But another question remains:

How do applications find those Services?

Before kube-proxy can forward traffic to a Service, Kubernetes first needs to translate the Service name into its ClusterIP. That's exactly what CoreDNS does.

Applications rarely communicate using IP addresses. Instead, they use names such as:

backend-service
mysql-service
redis-service

So how does a Pod translate those names into IP addresses?

That's where CoreDNS comes in.

Why Do We Need DNS in Kubernetes?

Imagine a frontend application connecting to a backend Service.

Without DNS:

Backend IP = 10.96.15.21

If the Service IP changes, the application configuration must change.

With DNS:

backend-service

CoreDNS automatically resolves the name to the correct Service IP.

This allows applications to communicate without knowing actual IP addresses.

What Is CoreDNS?

CoreDNS is the DNS server for Kubernetes clusters.

It watches Kubernetes resources and automatically creates DNS records for:

Services
Pods (optional)
Namespaces

Applications can then use Service names instead of IP addresses.

Where Does CoreDNS Run?

CoreDNS runs as Pods inside the kube-system namespace.

Verify this with:

kubectl get pods -n kube-system

Typical output:

coredns-xxxxx
coredns-yyyyy

Multiple replicas provide high availability.

How Service Discovery Works

Suppose we have:

Service Name: backend-service
Namespace: default
ClusterIP: 10.96.15.21

A Pod sends a request to:

backend-service

CoreDNS resolves it to:

10.96.15.21

The application never needs to know the actual IP address.

Kubernetes DNS Naming

DNS Name	Used When
`backend-service`	Same namespace
`backend-service.default`	Specify the namespace
`backend-service.default.svc`	Include the Service domain
`backend-service.default.svc.cluster.local`	Fully Qualified Domain Name (FQDN)

Most applications simply use backend-service because Kubernetes automatically appends the remaining DNS suffix.

Why Does backend-service Work Without Typing the Full DNS Name?

Every Pod receives a DNS configuration file:

cat /etc/resolv.conf

It contains the CoreDNS nameserver and search domains, allowing short Service names like backend-service to resolve automatically without typing the full FQDN.

DNS Lookup Flow

Application Pod
        ↓
DNS Query
        ↓
CoreDNS
        ↓
Service ClusterIP
        ↓
kube-proxy
        ↓
Backend Pod

The entire process usually takes only a few milliseconds.

Important DNS Records

ClusterIP Service

CoreDNS returns the Service IP:

backend-service → 10.96.15.21

Headless Service

If the Service uses:

clusterIP: None

CoreDNS returns the individual Pod IPs:

database-0
database-1
database-2

This is commonly used by StatefulSets.

Common DNS Problems and Solutions

1. Service name not resolving?

Verify the Service exists:

kubectl get svc

2. Test DNS from a Pod

kubectl exec -it <pod> -- nslookup backend-service

3. Check CoreDNS Pods

kubectl get pods -n kube-system

4. View CoreDNS Logs

kubectl logs -n kube-system deployment/coredns

Why CoreDNS Matters

Without CoreDNS:

Applications would need hardcoded IP addresses.
Configuration changes would happen frequently.
Service discovery would become difficult.
Microservices communication would break easily.

CoreDNS makes Kubernetes applications independent of changing IP addresses.

Summary

Pods communicate using names, not IP addresses.

CoreDNS acts as the phonebook of Kubernetes, translating Service names into IP addresses.

Understanding CoreDNS helps you:

Debug Service discovery problems.
Troubleshoot application connectivity.
Understand Kubernetes networking better.
Build resilient microservices.

Next in the Series:
Ingress Explained – How External Traffic Enters Your Kubernetes Cluster.

Linux Networking Basics for Beginners

Sreekanth Kuruba — Tue, 23 Jun 2026 05:18:20 +0000

Post: 6

Most Linux “server down” problems are not actually system failures.

They are network issues.

👉 The system is running fine
👉 But it cannot talk to the outside world

That’s why networking is one of the most critical skills in Linux, DevOps, and cloud environments.

Let’s simplify it.

Basic Networking Concepts (Must Know First)

What is an IP Address?

An IP address is a unique address assigned to a device in a network.

Example:

192.168.1.10

👉 Used for communication between systems.

What is localhost (127.0.0.1)?

localhost refers to your own computer.

127.0.0.1

👉 This means “your own computer”

Used for:

testing apps
local development
debugging services

What is DNS?

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

Example:

google.com → 142.x.x.x

👉 Without DNS, we would need to remember IPs manually.

What is a Port?

Ports are like “doors” for services.

Ports are communication endpoints used by applications.

Examples:

Port 80 → HTTP
Port 443 → HTTPS
Port 22 → SSH

👉 One server can run multiple services using different ports.

1. Check Internet Connectivity with `ping`

ping google.com

Limit requests:

ping -c 4 google.com

👉 First command used in troubleshooting.

Checks:

is host reachable?
is network working?

2. Test Web Requests with `curl`

curl google.com

Headers only:

curl -I google.com   # Show only HTTP headers

Verbose mode:

curl -v google.com   # Verbose (detailed output)

Used for:

API testing
checking web services
debugging HTTP issues

3. Check DNS Resolution

nslookup google.com

# More detailed DNS lookup
dig google.com

👉 If DNS fails:

website won’t open
even if internet is working

4. Check Your IP Address

ip a          # full network interface details
hostname -I   # Show only IP addresses

👉 Shows your system’s network identity

5. Check Routing path

ip route
ip route | grep default   # Show default gateway

👉 Shows how traffic leaves your system

6. Check Open Ports

ss -tuln               # Show listening ports
ss -tuln | grep :80    # Check specific port

Shows which services are listening on your system.

Modern replacement for netstat.

7. Trace Network Path with `traceroute`

traceroute google.com

Install if needed:

sudo apt install traceroute    # Ubuntu/Debian
sudo dnf install traceroute    # Fedora/RHEL

👉 Shows where delay or failure happens in network path

8. Enhanced Traceroute with `mtr`

mtr is a powerful combination of ping and traceroute. It continuously monitors the connection.

mtr google.com

Install if needed:

sudo apt install mtr

👉 Combines:

ping
traceroute

Real-time network diagnostics tool

Simple Troubleshooting Flow (VERY IMPORTANT)

ping 8.8.8.8 → check internet
ping google.com → check DNS
ip a → check IP
ip route → check routing
curl -I site → check HTTP
traceroute / mtr → find failure point

👉 This is real DevOps incident workflow

⚠️ Common Beginner Mistakes

assuming internet is down (when DNS is broken)
not checking IP address first
using old tools (ifconfig, netstat)
routing checks

Simple Mental Model

Think of networking like delivery:

IP → house address
DNS → contact name → address lookup
Port → door number
Routing → delivery path
ping → “are you there?”

Summary

You learned:

IP address basics
localhost (127.0.0.1)
DNS resolution
ports (80, 443, 22)
ping → connectivity
curl → web/API testing
nslookup, dig → DNS tools
ip a, ip route → network config
ss → open ports
traceroute, mtr → path debugging

Why This Matters

Networking is the backbone of:

cloud systems
DevOps pipelines
APIs
production servers

👉 If networking breaks, everything breaks

Next Post:
Linux Logs Explained Simply,(journalctl, /var/log)

Question for You

Have you ever faced a situation where:

internet was working
but website still didn’t load?

That’s usually DNS — I’ll show debugging in Part 8.

DEV Community: Sreekanth Kuruba

Docker in Production: What Changes When Containers Meet Reality?

Health vs. Recovery

Step 1: Check the container status

Step 2: Check the logs

Step 3: Inspect the container

Step 4: Check resource usage

Step 5: Check networking

Step 6: Check the image

Think `docker compose up` just starts containers? There’s more happening behind the scenes. And one common assumption about `depends_on` can cause real problems. I break down what Compose actually does—and what it doesn’t.

Docker Compose Isn't What I Thought It Was

Docker Compose Isn't What I Thought It Was

Docker Security Internals: How Safe Are Your Containers Really?

1. The Foundation: Linux Kernel Features

2. Namespaces – Isolation, Not Security

3. cgroups – Preventing Resource Exhaustion

4. The Root Problem – Still Real

5. seccomp – Blocking Dangerous System Calls

6. Rootless Docker – Reducing Host-Level Risk

7. Practical Docker Hardening Checklist

Summary

Next Topic

Linux Troubleshooting Workflow for Beginners: A Step-by-Step Guide

File Compression in Linux Explained Simply (tar, gzip, zip & unzip)

Viewing Files in Linux Explained Simply (cat, less, head, tail & wc)

Finding Files & Text in Linux Explained Simply (find, grep, which & whereis)

Finding Files vs Searching Text

1. Find Files with find

2. Search Text Inside Files with grep

3. Find Executable Location with which

4. Find Program Files with whereis

Bonus: Fast File Search with locate

Real-World Troubleshooting Example

Common Beginner Mistakes

Simple Mental Model

Summary

Linux Package Management Explained Simply (apt, dnf, yum & rpm)

What is a Package?

What is a Package Manager?

Why Use a Package Manager?

What is a Repository?

Common Package Managers

Most Useful Commands

Low-Level Tool: rpm

Common Beginner Mistakes

Simple Mental Model

Summary

Why This Matters

Linux Logs Explained Simply

What Are Logs?

Where are Logs Stored?

Important Log Files

Real-Life Troubleshooting Example

⚠️ Common Beginner Mistakes

Summary

How CoreDNS Powers Service Discovery in Kubernetes

Important DNS Records

Common DNS Problems and Solutions

Linux Networking Basics for Beginners

Basic Networking Concepts (Must Know First)

1. Check Internet Connectivity with ping

2. Test Web Requests with curl

3. Check DNS Resolution

4. Check Your IP Address

5. Check Routing path

6. Check Open Ports

7. Trace Network Path with traceroute

8. Enhanced Traceroute with mtr

Simple Troubleshooting Flow (VERY IMPORTANT)

⚠️ Common Beginner Mistakes

Summary

1. Find Files with `find`

2. Search Text Inside Files with `grep`

3. Find Executable Location with `which`

4. Find Program Files with `whereis`

Bonus: Fast File Search with `locate`

1. Check Internet Connectivity with `ping`

2. Test Web Requests with `curl`

7. Trace Network Path with `traceroute`

8. Enhanced Traceroute with `mtr`