🐧 Linux for DevOps — Session 2: Understanding the Kernel, Shell, OS Architecture & File System

📓 Learning in public — These are my personal notes from my Linux for DevOps & Cloud journey. I'm sharing them in a way that's easy to revisit later and hopefully useful for anyone else starting out.

In the previous session, I got comfortable with Linux basics and terminal access. This session focused on understanding what actually happens behind the scenes when we run commands, how Linux is structured internally, and how files are organized on the system.

These concepts might sound theoretical at first, but they're the foundation of everything you'll do in DevOps—from managing EC2 instances and Docker containers to troubleshooting production servers.

The Linux Kernel: The Heart of the Operating System

The kernel is the most important component of Linux.

Think of it as a translator sitting between software and hardware. Applications can't directly talk to the CPU, RAM, disks, or network interfaces. Instead, every request goes through the kernel.

When you run a command, open a browser, start a Docker container, or deploy an application, the kernel is responsible for making it happen.

Its main responsibilities include:

Without the kernel, Linux would simply be a collection of files with no way to interact with hardware.

Types of Kernels

Not every operating system uses the same kernel design.

Monolithic Kernel (Linux) keeps most operating system services inside a single kernel space. This approach is extremely fast because components communicate directly.

Microkernel keeps only essential functionality in kernel space and moves other services outside. This improves isolation and stability but introduces additional overhead.

Hybrid Kernel combines elements of both approaches. Windows NT follows this model.

One reason Linux dominates cloud computing is that its monolithic architecture delivers excellent performance for server workloads.

☁️ DevOps Context

When you launch an AWS EC2 instance, you're ultimately running on a Linux kernel. Understanding kernel behavior becomes important when diagnosing CPU bottlenecks, memory pressure, or process scheduling issues in production environments.

Understanding Linux OS Architecture

Linux follows a layered architecture.

User

 ↓

User Space

 ↓

Shell & Libraries

 ↓

Kernel

 ↓

Hardware

Every action travels through these layers before reaching the physical machine.

At the top is User Space, where applications such as browsers, terminals, and editors operate.

The Shell acts as an interpreter that converts your commands into instructions the operating system understands.

Libraries provide reusable functionality that applications rely on rather than implementing everything from scratch.

The kernel then translates those requests into hardware operations involving the CPU, memory, storage, and network devices.

Program vs Process

This distinction appears in interviews constantly.

A program is simply a file containing instructions stored on disk.

A process is a program that has been loaded into memory and is actively executing.

For example:

• 
  nginx installed on disk = Program


• Running nginx service = Process

Every process running on a Linux machine has its own Process ID (PID).

🐳 DevOps Context

Docker containers are essentially isolated Linux processes that share the host's kernel. Unlike virtual machines, containers don't require a separate operating system, which is why they start quickly and consume fewer resources.

The Shell: Where DevOps Engineers Spend Their Time

The shell acts as a bridge between users and the kernel.

When you type a command like:

ls -la

the shell interprets it and forwards the appropriate system calls to the kernel.

Several shell types exist, but one dominates the DevOps world:

Why Bash Matters

Bash is everywhere.

CI/CD pipelines, provisioning scripts, automation jobs, EC2 user-data scripts, and infrastructure deployments often rely on Bash.

If you're working with:

• GitHub Actions


• Jenkins


• GitLab CI/CD


• Terraform bootstrapping


• Linux automation

you'll almost certainly encounter Bash scripting.

That's why becoming comfortable with Bash early pays off enormously.

Understanding the Linux File System

One thing that initially confused me coming from Windows was Linux's file system structure.

Windows separates storage into drives:

C:

D:

E:

Linux takes a completely different approach.

Everything begins from a single root directory:

/

Every file, directory, process, and device exists somewhere beneath this root.

Some directories are especially important for DevOps work:

If you're troubleshooting Linux servers, you'll spend a surprising amount of time inside /etc and /var.

Absolute vs Relative Paths

An absolute path starts from root and works from anywhere:

/home/tejas/projects/deploy.sh

A relative path depends on your current location:

projects/deploy.sh

For personal use, both are fine.

For scripts, automation, and CI/CD pipelines, absolute paths are generally safer and more predictable.

Essential Linux Navigation Commands

Once you understand the filesystem, navigation becomes straightforward.

pwd          # show current directory

cd ~         # go to home directory

cd /         # go to root directory

cd ..        # move one level up

whoami       # current user

history      # command history

The command I probably use most often is:

pwd

It's a simple way to verify where I am before making changes.

Working with Files and Directories

Creating directories is easy:

mkdir test_dir

However, in real-world automation you'll almost always prefer:

mkdir -p project/src/app

The -p flag creates missing parent directories automatically and doesn't fail if directories already exist.

That's exactly the behavior you want inside deployment scripts.

Creating files is equally straightforward:

touch notes.txt

To edit files, Linux commonly uses:

vi file.txt

or

nano file.txt

Most servers ship with vi, so learning a few basic commands is worthwhile.

i      → Insert mode

Esc    → Normal mode

:wq    → Save and quit

:q!    → Quit without saving

Reading Files Efficiently

Several commands exist for viewing file contents.

For small files:

cat file.txt

For large files:

less file.txt

I quickly learned that less is usually better than more because it supports searching and backward navigation.

Useful commands include:

head -n 5 file.txt

tail -n 5 file.txt

These are perfect when you're only interested in the beginning or end of a file.

The DevOps Favorite: tail -f

One command shows up constantly in production environments:

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

The -f flag follows the file and displays new lines in real time.

When applications fail, logs are usually the first place to investigate.

A common pattern is:

tail -f app.log | grep ERROR

This streams only error messages as they occur.

Key Takeaways

This session helped connect several important Linux concepts together:

• The kernel manages resources and interacts with hardware.


• Linux uses a layered architecture from user space down to hardware.


• Bash is the standard shell for DevOps automation.


• Linux organizes everything under a single root directory.


• 
  /etc and /var are critical directories for system administration.


• 
  mkdir -p is safer for scripts than plain mkdir.


• 
  less is usually more useful than more.


• 
  tail -f is one of the most valuable troubleshooting commands in production.

The more I learn Linux, the more I realize that nearly every DevOps tool—Docker, Kubernetes, Terraform, Jenkins, Ansible, and cloud platforms—ultimately builds on these fundamentals.

Mastering Linux isn't a separate DevOps skill. It's the foundation underneath all of it.