OS 아키텍처, 커널, 셸 및 파일 시스템

🐧 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:

Responsibility Purpose Resource Management Decides which process gets CPU time Memory Management Allocates and releases RAM Process Management Creates, schedules, and terminates processes Device Management Communicates with hardware through drivers

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

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

Shell Common Usage sh Original Unix shell bash Default Linux shell and DevOps standard zsh Interactive shell with productivity features fish Beginner-friendly shell nologin Prevents interactive logins

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:

Enter fullscreen mode Exit fullscreen mode

Linux takes a completely different approach.

Everything begins from a single root directory:

/

Enter fullscreen mode Exit fullscreen mode

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

Some directories are especially important for DevOps work:

Directory Purpose /home User home directories /root Root user’s home directory /etc Configuration files /var Logs and application data /tmp Temporary files /proc Kernel and process information /bin Essential commands /sbin Administrative commands

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

Enter fullscreen mode Exit fullscreen mode

A relative path depends on your current location:

projects/deploy.sh

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

The command I probably use most often is:

pwd

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

mkdir -p project/src/app

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

To edit files, Linux commonly uses:

vi file.txt

Enter fullscreen mode Exit fullscreen mode

or

nano file.txt

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

Reading Files Efficiently

Several commands exist for viewing file contents.

For small files:

cat file.txt

Enter fullscreen mode Exit fullscreen mode

For large files:

less file.txt

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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.