Complete DevOps Tutorial

DevOps is not a tool set, and the fastest way to see that is to notice which knowledge survives a job change. The kubectl flags do not. What does is the ability to reason about a system you did not build: to trace a request through every hop, to tell a saturation problem from a configuration problem, and to know what changed.

Almost every incident reduces to four questions. What changed? Where in the request path does it break? Is the failure resource exhaustion or misconfiguration? And what is the fastest safe mitigation while you diagnose? Everything in this track is in service of answering those faster.

Containers are processes, and that explains the error messages

A container is a normal Linux process with namespaces limiting what it can see and cgroups limiting what it can consume. There is no guest kernel. Internalising that one fact answers most container questions before they are asked: why startup is instant, why you cannot run a different kernel, why isolation is weaker than a virtual machine's, and why a process died at exactly its memory limit.

It also reframes image building. A layer is a filesystem diff, cached by the instruction that produced it, so ordering decides your build times: anything that changes rarely goes first. And a secret in any layer is in the image permanently, even if a later layer deletes the file — the earlier layer still contains it.

# Dependencies first: this layer is cached until the manifest changes
FROM node:22-slim AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev

# Source last: the layer that changes on every commit
FROM node:22-slim
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# Run unprivileged, and forward signals properly so SIGTERM reaches the app
USER node
CMD ["node", "server.js"]

The five Kubernetes failures, and what actually tells you which

Liveness and readiness probes are worth separating properly, because conflating them causes outages. Readiness controls whether traffic is sent; liveness controls whether the container is restarted. A liveness probe that checks a downstream dependency will restart your healthy pods during that dependency's outage — turning someone else's incident into yours.

Debug outside in, and mitigate before you diagnose

Under pressure the temptation is to start where you last found a bug. A repeatable outside-in order is faster and far less likely to send you down a familiar but wrong path: establish the blast radius, check what changed, then walk the request path hop by hop asking whether the request arrives and whether it is answered.

And separate mitigation from diagnosis. Rolling back a deploy, shifting traffic or scaling up restores service while you investigate with the pressure off. Diagnosing first while users are affected is the most common reason a ten-minute incident becomes an hour-long one.

# 1. What changed? Almost always the highest-yield question.
kubectl rollout history deploy/api
git log --oneline --since="2 hours ago"

# 2. Mitigate, then investigate
kubectl rollout undo deploy/api

# 3. Walk the path: DNS -> TCP -> TLS -> HTTP
dig +short api.internal
nc -vz api.internal 443
curl -w 'dns %{time_namelookup} tcp %{time_connect} ttfb %{time_starttransfer}\n' \
     -o /dev/null -s https://api.internal/health

# 4. Saturation: CPU, memory, file descriptors, connections
kubectl top pods
ss -s

Pipelines and infrastructure as code

A CI pipeline earns its keep through feedback speed and reproducibility. Fast, cheap checks first — lint, unit tests, type checks — so a broken commit fails in two minutes rather than twenty. Build the artefact once and promote that same artefact through environments; rebuilding per environment means the thing you tested is not the thing you shipped.

For infrastructure as code the recurring themes are state and drift. State belongs in a remote backend with locking and versioning, never in git — it holds resource IDs and often secrets, and git has no locking, so two concurrent applies conflict after the damage rather than before it. Plans should be reviewed like code, and manual console changes should be detected rather than assumed away.