Docker & Kubernetes.

I keep deploying things I built. Most of the time the deploy is the rough part — not the code. This subject is me getting the basics of containers and orchestration properly under my belt so I stop guessing.

Chapter 1 — containers

A container is a process that thinks it has its own filesystem and network. That's it. The clever part is how Linux makes that cheap.

# Build an image from a Dockerfile in the current directory.
docker build -t myapp:0.1 .

# Run it, mapping the container's port 3000 to host 8080.
docker run --rm -p 8080:3000 myapp:0.1

A Dockerfile is a recipe of layers. Each RUN, COPY, ADD produces a new layer; the layers are content-addressed and cached. Putting expensive steps (dependency install) before cheap, frequently changing ones (source code) is the whole reason builds stay fast.

Chapter 2 — orchestration

Kubernetes is a cluster of machines pretending to be one machine. You describe what you want — a Deployment with three replicas of a Pod that runs your image, exposed by a Service — and the cluster figures out where to put them.

The minimum useful manifests:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp:0.1
          ports:
            - containerPort: 3000

The deployment owns the lifecycle. If a node dies, the scheduler reschedules the pods elsewhere. That's the whole pitch.

Chapter 3 — what's next

Probes, configmaps, secrets, ingress. Once those are stable, the interesting part starts: how you actually roll out a new version without dropping traffic.

More chapters as I get through the course.