Part 1 · Linux, Processes & the Shell

Every other part of this book — containers, Kubernetes, CI runners, Terraform, your monitoring stack — ultimately resolves to a Linux process, reading files, started by a service manager, talking over a socket. A container is a Linux process with some walls around it. A Kubernetes node is a Linux box. A CI job is a shell script. If you understand Linux at the process / file / shell level, the rest of DevOps stops being magic and starts being the same few primitives, recombined.

So before we automate anything, we learn the thing being automated. This part is the substrate. Get it solid and everything above it gets easier.

Why Linux, specifically

You could run servers on other systems, but in practice the cloud is Linux. It’s free to run at scale, it’s scriptable to its core, and — most importantly for us — it exposes its internals as files and text. A process is a directory under /proc. A network connection is a file descriptor. Configuration is text you can read, diff, and put in version control. That transparency is exactly what makes Linux automatable, and automation is the whole job.

   YOUR APP
      │  runs as
      ▼
   a PROCESS   ──────────── reads/writes ──────────►  FILES (config, logs, /proc)
      │  managed by                                        │
      ▼                                                    ▼
   systemd (a SERVICE) ◄──── glued together by ──── the SHELL & scripts
      │  installed via
      ▼
   PACKAGES (apt / dnf)  ──────── observed via ──────►  LOGS & metrics

Read that diagram top to bottom and you have the six pages that follow.

By the numbers — ‘the cloud is Linux’ is almost literal

The claim that you’ll mostly run on Linux isn’t rhetorical:

TOP500 supercomputers running Linux   =  100%  (every one, since ~2017)
Public-cloud Linux instances          ≈  the large majority of VMs
Android (Linux kernel underneath)     =  billions of devices

When every one of the world’s 500 fastest supercomputers, the bulk of cloud VMs, and the kernel under Android all converge on the same system, learning it once pays off everywhere. And they converge for the reason this page opens with — Linux exposes its internals as files and text, which is exactly what makes it scriptable, and scripting away manual steps is the whole job.

The thread that runs through this book

For every tool and technique, keep asking the one question from the book’s introduction: what manual, error-prone step does this remove — and how does it make production safer? Linux is where that question first bites. Doing things “by hand” on a server — editing files as root, starting a process in a terminal and hoping it survives logout, installing whatever version apt happened to grab today — is exactly the kind of slow, irreproducible, human-error-prone toil the rest of this book exists to kill. Each page below replaces one of those manual habits with something repeatable.

The roadmap

Read these in order. Each one only uses ideas from the ones before it.

#	Page	The question it answers
2	The Process Model	What is a running program, and how do I start, watch, and stop one safely?
3	The Filesystem & Permissions	Where do things live, and who is allowed to touch them?
4	The Shell	How do I glue small tools into automation — the literacy underneath every script?
5	Package Management	How do I install software reproducibly instead of “it worked on my machine”?
6	systemd & Services	How do I make my app a managed service that survives crashes and reboots?
7	Logs & Troubleshooting	When it breaks at 3 a.m., how do I find out why, methodically?

How to follow along

You learn this by typing, not reading. Spin up a cheap Linux VM, or use a local one (multipass, WSL, a container). Run every command. Break things on purpose. A throwaway box you can rebuild is the safest classroom there is — which, not coincidentally, is the same instinct behind immutable infrastructure later in the book.

What “good” looks like by the end of Part 1

You should be able to: explain what happens between pressing Enter and a process running; reason about who can read a file and why; chain grep, find, and friends into a one-liner that answers a real question; install a pinned version of a package; run your own application as a systemd service that restarts on failure; and triage a misbehaving box with top, df, free, ss, and journalctl without flailing.

That’s the foundation. The networking part builds on it (those sockets and ports come from here), and containers are literally the namespaces and cgroups of a Linux process — so the better you know this layer, the less mysterious everything above it becomes.

A note on distributions

Commands here target modern Debian/Ubuntu (apt) and RHEL-family (dnf) systems with systemd, which covers the overwhelming majority of cloud servers and container base images. Where the two families differ, both forms are shown.

Check your understanding

1. In one sentence, why is “everything is a file (or text)” the property that makes Linux automatable?
2. A container is often described as “just a Linux process with walls.” Given the diagram above, which primitives are those “walls” built from? (You’ll confirm this in Containers.)
3. The recurring thread asks what manual step a tool removes. Name one manual, error-prone server habit and which page in this part replaces it.
4. Why does the book insist you run the commands on a throwaway VM rather than just reading the pages?
5. Without peeking ahead: in what order would you need to understand processes, the shell, and systemd, and why does that order matter?

Show answers

1. Because exposing internals as files and text means one set of tools and one permission model governs everything — config, logs, processes (/proc), even sockets. You can cat, grep, diff, and version-control it, which is exactly what lets a script reliably read and change it. Opaque binary state can’t be automated the same way.
2. The “walls” are built from namespaces (isolate what a process can see — its own filesystem, network, PIDs) and cgroups (limit what it can use — CPU, memory). A container is a normal Linux process with those boundaries applied. You confirm this in Containers.
3. Open-ended — e.g. starting a process with python app.py & and hoping it survives is replaced by systemd & Services; installing “whatever apt grabbed today” is replaced by package management; editing files by hand is replaced by the shell and scripts.
4. Because you learn this by typing, not reading — you build real intuition only by running commands and breaking things on purpose. A throwaway box you can rebuild is the safest classroom; it’s the same instinct behind immutable infrastructure later in the book.
5. Processes → the shell → systemd. You need processes first (what a running program is, signals, exit codes); the shell builds on that (it forks/execs processes and chains them by exit status); and systemd builds on both (it’s PID 1 supervising processes, configured in files you edit and inspect with shell tools). Each layer only makes sense once the one beneath it does.