DevOps

A query that takes 200ms against your database still takes 200ms the millionth time someone runs it, and every one of those runs competes for the same connections, disk I/O, and CPU. Redis keeps the answer in memory, on a server that does nothing else, so the millionth read costs a network round trip instead of a query plan. What Redis actually does as a cache Redis is an in-memory key-value store. Values live in RAM, so reads and writes measure in sub-millisecond time instead of the tens or hundreds of milliseconds a relational query costs once you add joins, indexes under pressure, or a busy connection pool. It sits next to your database, not in place of it: your application asks Redis first and goes to the database only when Redis doesn’t have the answer. ...

What sits between a browser and your app Point a browser at example.com and the request never touches the process running your code. It hits something else first: a server that reads the request, decides which backend should answer, forwards it there, and sends the response back as if it had produced that response itself. That server is a reverse proxy. Nginx, Caddy, Traefik and HAProxy all do this job, and so does the load balancer sitting in front of a Kubernetes cluster. The arrangement never changes: clients talk to the proxy and to nothing else. The real servers stay behind it, however many there are and wherever they run. ...

You pull the latest main and Git stops with CONFLICT (content): Merge conflict in checkout.js. You resolve it, and the log now shows a commit called Merge branch 'main' into feature/checkout sitting on top of the three commits you actually wrote. Four commits, one real change. A teammate reading that history next month can’t tell which is which. git merge and git rebase both answer the same question: how do I bring my branch up to date with changes made elsewhere. They leave very different traces behind, and picking the wrong one on a shared branch causes real damage. ...

docker build && docker push from your laptop works until someone else has to ship the same image, or it has to happen on every merge without you at the keyboard. GitHub Actions runs that build on GitHub’s runners, tags the image from whatever triggered the workflow, and pushes it to a registry your deploy step can pull from. Nothing runs locally. What it takes to build and push a Docker image from CI Five pieces have to be in place before a runner can push an image: ...

Run kubectl run nginx --image=nginx:1.27 and Kubernetes creates exactly one Pod named nginx. Delete it with kubectl delete pod nginx and it is gone for good — nothing notices, nothing replaces it. A Pod is the smallest deployable unit in Kubernetes: one or more containers that share a network namespace and a set of volumes, scheduled together onto a single node. That single Pod is a dead end in production. If the container inside it crashes, the kubelet restarts the container in place. If the node reboots, or someone deletes the Pod, nothing recreates it. A bare Pod has no memory of the fact that it is supposed to exist. ...

Where a container’s environment variables end up Start a container with -e DB_PASSWORD=hunter2 and run docker inspect on it: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] The password sits there in plain text, readable by anyone with access to the Docker socket, by docker exec api env, and by any process running inside the container. That is not a bug — it is what environment variables are for. The problem is using them for values that should never be that visible. ...

Why a Docker image ends up ten times bigger than the app A Node service with a few hundred kilobytes of source code ships as an image over 1 GB. That is the normal outcome of a working build, not a mistake anyone made on a particular line. The weight comes from a base image carrying a full OS, a build toolchain the running app never calls, and a package manager cache nobody told the build to delete. ...

What a bad Dockerfile costs you 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Four lines, and every one of them costs you something. docker build re-runs npm install on every code change, because COPY . . breaks the layer cache before the install step ever gets a chance to be reused. The final image carries the full Debian base, the entire node_modules tree including dev dependencies, and whatever build tools npm install pulled in to compile native modules. Nothing is discarded. The container runs as root, because nothing tells it not to, and node:latest means the base image can change under you between one build and the next, with no record of what you actually shipped. ...

Why two containers on the same host can’t reach each other by default Start Postgres and your API with plain docker run and the API cannot reach the database, even though both containers sit on the same machine. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Both land on Docker’s default bridge network, where every Docker container goes unless you say otherwise. They get IP addresses. What they don’t get is any way to find each other by name, so the API would have to hardcode the database’s internal IP — an address that changes every time the container restarts. ...

The problem Compose solves A real application is rarely one container. A web API needs a database, the database needs a volume so its data survives a restart, and then you add a Redis cache and a background worker. That is four docker run commands, each with its own flags for ports, volumes, environment variables and a shared network. In the right order. Every time you sit down to work. ...