Ship and run cloud software safely: containers, CI/CD pipelines, Terraform with cost guardrails, SLOs, alerting and incident response.

DevOps & Cloud Delivery

Install Docker Desktop (Windows or macOS) or Docker Engine (Linux) from docs.docker.com, then run `docker run --rm hello-world` and confirm you see the "Hello from Docker!" message.

Create a folder `hello-devops`, run `git init` in it, and add `app.py` and `Dockerfile` exactly as shown in the Read tab.

Create `.dockerignore` and `.gitignore` files that both contain `.env`, `.git` (dockerignore only), `__pycache__/` and `.venv/`. You will never commit secrets in this course.

Run `docker build -t hello-devops:0.1 .` and read the output: note one line per Dockerfile instruction.

Run `docker run --rm -d --name hello -p 8000:8000 hello-devops:0.1`, then open http://localhost:8000 (or `curl` it) and confirm you see `Hello, DevOps!`.

Run `docker ps` and `docker logs hello`, then `docker exec hello whoami` and confirm the app runs as `nobody`, not root.

Change the greeting in `app.py`, rebuild with the tag `0.2`, and notice which build steps say `CACHED`. Run the new tag to confirm the change.

Clean up: `docker stop hello`, then `docker image rm hello-devops:0.1 hello-devops:0.2`, and check `docker system df`. Commit `app.py`, `Dockerfile`, `.dockerignore` and `.gitignore` to your local repository.

## Why it matters

"It works on my machine" is one of the oldest problems in software. An app that runs on a developer laptop can fail on a server because the operating system, the language version or a system library is different. Containers solve this by packaging the app together with everything it needs to run. The same package runs on your laptop, in a CI pipeline and in the cloud.

Cloud engineers meet containers everywhere: CI jobs run inside them, Kubernetes schedules them, and managed services such as AWS ECS, Azure Container Apps and Google Cloud Run deploy them. Docker is the most common tool for building and running them, so it is the starting point for this course.

## The core idea: images and containers

Two words do most of the work:

- An **image** is a read-only package: a filesystem snapshot (your code, the language runtime, libraries) plus metadata such as which command to start. Images are built once and shared through a **registry** such as Docker Hub or GitHub Container Registry.
- A **container** is a running instance of an image. It gets its own isolated filesystem, process list and network interface, but it shares the host's kernel. That is why a container starts in about a second, while a virtual machine boots a whole operating system.

You can start many containers from one image, just as you can open many windows of one program. When a container is deleted, any changes made inside it are lost unless you stored them in a **volume** (more on that in the next lesson).

## A Dockerfile, line by line

You describe an image in a text file called `Dockerfile`. Here is one for a tiny Python web app that uses only the standard library:

```python
# app.py
from http.server import BaseHTTPRequestHandler, HTTPServer


def greeting(name):
    return f"Hello, {name}!"


class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        body = greeting("DevOps").encode()
        self.send_response(200)
        self.send_header("Content-Type", "text/plain")
        self.end_headers()
        self.wfile.write(body)


if __name__ == "__main__":
    HTTPServer(("0.0.0.0", 8000), Handler).serve_forever()
```

```dockerfile
# Dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY app.py .
EXPOSE 8000
USER nobody
CMD ["python", "app.py"]
```

What each instruction does:

| Instruction | Meaning |
|---|---|
| `FROM` | Start from an existing base image (here, a small Debian image with Python 3.12). |
| `WORKDIR` | Set the working directory inside the image; later commands run there. |
| `COPY` | Copy files from your project (the **build context**) into the image. |
| `EXPOSE` | Document which port the app listens on. It does not publish the port by itself. |
| `USER` | Run the app as an unprivileged user instead of root. |
| `CMD` | The default command when a container starts. |

Notice that the app listens on `0.0.0.0`, not `127.0.0.1`. Inside a container, `127.0.0.1` means "this container only", so traffic forwarded from your laptop would never reach it.

## Build, run, inspect

```bash
docker build -t hello-devops:0.1 .
docker run --rm -d --name hello -p 8000:8000 hello-devops:0.1
curl http://localhost:8000        # Hello, DevOps!
docker ps                          # list running containers
docker logs hello                  # the app's output
docker stop hello                  # --rm deletes it once stopped
```

- `-t hello-devops:0.1` gives the image a **name and tag**. Use meaningful tags (a version or a Git commit SHA), not only `latest`.
- `-p 8000:8000` maps port 8000 on your machine to port 8000 in the container (`host:container`).
- `-d` runs it in the background; `--rm` removes the container when it stops.

## Layers and caching

Every instruction in a Dockerfile creates a **layer**. Docker caches layers and reuses them when nothing they depend on has changed. Order instructions from "changes rarely" to "changes often": install dependencies first, copy your source code last. For a typical Python app that means copying `requirements.txt` and running `pip install` before `COPY . .`, so editing one line of code does not reinstall every library.

Add a `.dockerignore` file (same syntax as `.gitignore`) so that `.git`, virtual environments and, above all, `.env` files never enter the build context.

## Common mistakes

- **Baking secrets into images.** Anything you `COPY` or put in `ENV` is readable by anyone who can pull the image, even if a later layer deletes it. Pass secrets at run time (environment variables from a secret store) and keep them out of Git.
- **Running as root.** Add a `USER` line; many security scanners flag images that run as root.
- **Huge images.** Use `-slim` or `alpine` bases and clean up package caches. Smaller images pull faster and have fewer vulnerabilities.
- **Using only `latest`.** You cannot tell which code `latest` contains, and rolling back becomes guesswork.
- **Forgetting to clean up.** Old images and stopped containers fill your disk. `docker system df` shows usage; `docker image prune` removes dangling images.

A note on licensing: Docker Desktop is free for personal use, education, open source and small businesses, but larger companies need a paid subscription. On Linux you can install Docker Engine directly, and Podman or Colima are free alternatives. Check Docker's current terms for your situation.

## Quick recap

- An image is a package; a container is a running instance of it.
- A Dockerfile lists the steps to build an image; each step is a cached layer.
- `docker build`, `docker run -p`, `docker ps`, `docker logs` and `docker stop` cover daily use.
- Keep secrets out of images and Git, run as a non-root user, and tag images meaningfully.

## Try it

Open the Do tab to install Docker, build the image above and run it on your own machine. Everything runs locally and costs nothing.

Package a small app into a Docker image with a Dockerfile, run it as a container and clean up afterwards.

Docker basics

Docker in 100 Seconds

Dockerfiles for absolute beginners

In your `hello-devops` folder, confirm `.gitignore` contains `.env`, then create `.env` with `POSTGRES_PASSWORD=` followed by a random local password, and create `.env.example` with `POSTGRES_PASSWORD=replace-me`.

Add `compose.yaml` from the Read tab (web + db, named volume, health check, `depends_on` with `service_healthy`).

Add the `db_reachable()` function to `app.py` and change the handler so the response reads, for example, `Hello, DevOps! db_reachable=True`.

Run `docker compose up -d --build`, then `docker compose ps` and wait until `db` shows `healthy` and `web` is running.

Open http://localhost:8000 and confirm the response says `db_reachable=True`.

Run `docker compose exec db psql -U app -d appdb -c "create table notes(id serial primary key, body text); insert into notes(body) values ('persisted');"`, then `docker compose down` and `docker compose up -d`, and confirm `select * from notes;` still returns the row.

Run `docker compose stop db`, reload the page and confirm it now says `db_reachable=False`; then `docker compose start db`.

Run `git status` and confirm `.env` is NOT listed, then commit `compose.yaml`, `.env.example` and `app.py`. Clean up with `docker compose down` (add `-v` only if you want to delete the practice data).

## Why it matters

Real applications are rarely one container. A web app usually needs a database, often a cache, sometimes a background worker. Starting each one by hand with long `docker run` commands, creating networks and volumes, and remembering the right order quickly becomes error-prone. **Docker Compose** lets you describe the whole stack in one YAML file and start it with one command.

Compose is the standard way to run a realistic local development environment, and it is a common way to run integration tests in CI. The ideas it teaches (services, networks, volumes, health checks, configuration from the environment) are the same ideas Kubernetes uses at larger scale.

## The core idea: services in one file

A `compose.yaml` file lists **services**. Each service becomes one or more containers built from an image. Compose also creates a private **network** for the project, so services can reach each other by name, and named **volumes** that keep data when containers are recreated.

Here is the web app from the previous lesson plus PostgreSQL:

```yaml
# compose.yaml
services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      DB_HOST: db
      DB_PORT: "5432"
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_DB: appdb
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d appdb"]
      interval: 5s
      timeout: 3s
      retries: 10

volumes:
  db-data:
```

```bash
# .env  (listed in .gitignore, never committed)
POSTGRES_PASSWORD=change-me-locally
```

Key points:

- **Service names are hostnames.** The web container reaches the database at `db:5432`, not `localhost:5432`. Compose's built-in DNS resolves the name to the right container.
- **Only `web` publishes a port.** The database is reachable from other services on the project network but not from outside your machine. Publish only what you need.
- **`${POSTGRES_PASSWORD}`** is read from a `.env` file next to `compose.yaml` or from your shell. The password never appears in the YAML you commit. Commit a `.env.example` with placeholder values instead, so teammates know which variables to set.
- **`depends_on` with `service_healthy`** waits until the database's health check passes before starting the web app. Without the health check, `depends_on` only waits for the container to start, not for Postgres to accept connections.
- **The named volume `db-data`** stores the database files outside the container, so data survives `docker compose down` and rebuilds.

## Proving the connection

To show that the web app can reach the database, add a check to `app.py` that opens a TCP connection to `DB_HOST:DB_PORT` using the standard library:

```python
import os
import socket


def db_reachable():
    host = os.environ.get("DB_HOST", "localhost")
    port = int(os.environ.get("DB_PORT", "5432"))
    try:
        with socket.create_connection((host, port), timeout=2):
            return True
    except OSError:
        return False
```

Then make the handler include `db_reachable()` in its response. A real app would use a database driver, but this keeps the image dependency-free.

## Everyday commands

```bash
docker compose up -d --build     # build images and start everything in the background
docker compose ps                # status and health of each service
docker compose logs -f web       # follow one service's logs
docker compose exec db psql -U app -d appdb -c "select version();"
docker compose down              # stop and remove containers and the network
docker compose down -v           # ...and also delete named volumes (data is gone)
```

The difference between `down` and `down -v` matters: the first keeps your data, the second wipes it. Use `-v` deliberately, for example to reset a test database.

## Common mistakes

- **Using `localhost` between services.** Inside a container, `localhost` is that container. Use the service name.
- **Committing `.env`.** Add it to `.gitignore` before you create it. If a secret is ever committed, treat it as leaked: rotate it, then remove it from history.
- **Publishing the database port to the world.** `"5432:5432"` is handy for a local GUI client, but on a cloud VM it can expose your database to the internet. Bind to loopback (`"127.0.0.1:5432:5432"`) if you need it.
- **Expecting `depends_on` alone to wait for readiness.** Add a health check and `condition: service_healthy`, and still make your app retry connections, because databases restart in production too.
- **Thinking Compose is a production orchestrator.** It runs on one host. For many hosts, self-healing and rolling updates you need an orchestrator such as Kubernetes or a managed container service.

## Quick recap

- `compose.yaml` declares services, networks and volumes; `docker compose up` starts the stack.
- Services reach each other by service name on a private project network.
- Named volumes keep data; `down -v` deletes it.
- Secrets come from an uncommitted `.env` file or the environment, never from the YAML in Git.

## Try it

The Do tab walks you through running the web app and PostgreSQL together on your own machine and proving that they can talk to each other.

Run a web app and a PostgreSQL database together with Docker Compose, using service names, volumes, health checks and an uncommitted .env file.

Multi-container apps

What is Docker Compose? | Docker Concepts

Docker Compose in 12 Minutes

## Why it matters

Compose runs containers on one machine. Production systems run hundreds of containers across many machines, and they must keep running when a machine dies, scale when traffic grows and update without downtime. **Kubernetes** (often written **K8s**) is the most widely used system for that job. Cloud engineer job postings mention it constantly, and managed versions exist on every major cloud: Amazon EKS, Azure AKS and Google GKE.

You do not need to run a cluster to understand it. This lesson builds the mental model: what the main objects are, how they relate and what happens when something fails.

## The core idea: desired state

Kubernetes is **declarative**. You do not tell it "start three containers". You describe the state you want, in YAML, and submit it to the cluster's API. Controllers then work continuously to make the real state match: if a container crashes or a machine disappears, they create a replacement. This loop of "compare desired with actual, then fix the difference" is called **reconciliation**, and it is the single most important idea in Kubernetes.

## The cluster

- The **control plane** runs the API server (everything talks to it), a database of desired state (etcd), the **scheduler** (decides which machine runs each workload) and controllers. Managed services run the control plane for you.
- **Nodes** are the worker machines (VMs) that actually run your containers. Each node runs an agent called the kubelet and a container runtime.

You interact with the cluster through `kubectl`, the command-line client.

## Pods

A **pod** is the smallest thing Kubernetes runs: one or more containers that share a network address and can share storage. Most pods hold a single app container. Pods are **disposable**: they get a new IP address when recreated and are never repaired in place. You almost never create pods directly.

## Deployments

A **Deployment** says "keep N identical pods of this template running". It manages a **ReplicaSet**, which does the counting. When you change the image tag, the Deployment performs a **rolling update**: it starts new pods and stops old ones gradually, so the app stays up, and you can roll back to the previous revision.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: web
          image: ghcr.io/example/hello-devops:3f9c2a1
          ports:
            - containerPort: 8000
          readinessProbe:
            httpGet:
              path: /
              port: 8000
```

The **readiness probe** tells Kubernetes when a pod can receive traffic. A pod that fails its readiness probe is taken out of rotation; a failing **liveness probe** makes Kubernetes restart the container.

## Services

Pods come and go, so you need a stable address. A **Service** gives a set of pods one stable name and virtual IP and load-balances across them. It finds its pods with a **label selector**, the same `app: hello` label as above.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
  ports:
    - port: 80
      targetPort: 8000
  type: ClusterIP
```

Service types:

| Type | Reachable from |
|---|---|
| `ClusterIP` (default) | Inside the cluster only, at `hello` or `hello.<namespace>.svc` |
| `NodePort` | A fixed port on every node |
| `LoadBalancer` | A cloud load balancer with an external address (this costs money on a cloud) |

For HTTP routing by hostname or path, clusters usually add an **Ingress** or the newer **Gateway API** in front of services.

## Other objects you will meet

- **Namespaces** split a cluster into separate areas, for example per team or per environment.
- **ConfigMaps** hold configuration; **Secrets** hold sensitive values. By default Secrets are only base64-encoded, not encrypted, so clusters enable encryption at rest and limit who can read them.
- **Labels** are key-value tags on every object, and selectors use them to connect objects.

The everyday workflow is `kubectl apply -f deployment.yaml`, then `kubectl get pods`, `kubectl describe pod <name>` and `kubectl logs <pod>`.

## Do you need it?

Kubernetes is powerful but complex, and a managed cluster has ongoing costs for the control plane, nodes and load balancers. Many small teams are better served by a simpler managed container service (Cloud Run, Azure Container Apps, ECS with Fargate). To practise for free, run a local cluster with **kind** or **minikube** on Docker, and delete it afterwards.

## Common mistakes

- Creating bare pods instead of Deployments, so nothing replaces them when they die.
- Mismatched labels between a Service selector and the pod template, so the Service has no endpoints.
- No readiness probe, so traffic reaches pods before the app is ready.
- Treating Secrets as encrypted by default.

## Quick recap

- Kubernetes reconciles desired state (your YAML) with actual state.
- Pods run containers and are disposable; Deployments keep N pods running and roll out updates.
- Services give pods a stable name and load-balance across them using labels.
- Practise locally with kind or minikube; managed clusters cost money.

## Try it

This lesson has no hands-on activity. Take the quiz in the Do tab to check your mental model.

Explain how Kubernetes runs containers with pods, deployments and services, and when a team actually needs it.

Kubernetes concepts

Kubernetes Explained in 6 Minutes | k8s Architecture

Kubernetes Simply Explained

Package apps as Docker images, run multi-container stacks with Compose, and understand how Kubernetes runs containers at scale.