Skip to content

00. Docker — ELI5

A Docker container is a sealed lunch box. The food inside is your app and every spoon and bowl it needs. The kitchen outside is the host machine, and it does not get to season your dal.

See. Your laptop has Python 3.11. The server has Python 3.9. Your laptop has libssl 3. The server has libssl 1.1. You ship the code. It breaks. Classic story.

Docker fixes this by packing the entire kitchen with the dish. Not just the code — the interpreter, the libraries, the system tools, the file layout. All sealed in one box called an image. Run the box anywhere and you get the same dish. Simple, no?

The picture

        BUILD TIME                          RUN TIME
   ┌──────────────────┐               ┌──────────────────────┐
   │   Dockerfile     │               │   Container (live)   │
   │   FROM python    │   docker      │   pid=1 python app   │
   │   COPY . .       │   build       │   own filesystem     │
   │   RUN pip ...    │  ────────►    │   own network ns     │
   └──────────────────┘               │   own pid ns         │
            │                         │   cgroup: 2 CPU, 4G  │
            ▼                         └──────────┬───────────┘
   ┌──────────────────┐                          │
   │   Image (layers) │                          │
   │  ┌────────────┐  │   docker run             │
   │  │ app code   │  │  ──────────────►         │
   │  ├────────────┤  │                          │
   │  │ pip pkgs   │  │                          │
   │  ├────────────┤  │                          │
   │  │ python     │  │                          │
   │  ├────────────┤  │                          │
   │  │ debian min │  │                          │
   │  └────────────┘  │                          │
   └──────────────────┘                          │
                                                 ▼
   ══════════════════════════════════════════════════════════
                    HOST LINUX KERNEL
        (namespaces + cgroups + overlayfs + seccomp)
   ══════════════════════════════════════════════════════════

The image is the recipe, stacked as read-only layers. The container is one running instance of that recipe. There is no second OS. The container shares the host kernel. What looks like isolation is just kernel namespaces fencing off views.

What problem does it solve

Before, every server was a snowflake. Someone SSH'd in, installed a package, edited a config, left. Six months later nobody remembers what is on the box. "Works on my machine" was the team motto.

After, the image is the truth. Same bytes run in CI, in staging, in prod. A new replica is one docker run away. A bad deploy is one docker stop away. The server becomes disposable. The image becomes precious.

The three things you actually deal with

Images. A read-only stack of filesystem layers plus metadata. Built from a Dockerfile. Identified by a content hash (the digest) and human tags like myapp:1.4.2. Cheap to copy because layers are shared between images.

Containers. A running process tree on top of an image, plus a thin writable layer on top of the read-only stack. Has its own PID 1, its own network interface, its own view of the filesystem. Dies, and the writable layer dies with it.

Registries. The fridge where images live between build and run. Docker Hub is the public one. Each cloud has its own — ECR on AWS, Artifact Registry on GCP, ACR on Azure. CI pushes an image; production pulls it. The image digest is the contract.

Where this lives in the wild

  1. Netflix Titus — Titus is Netflix's internal container platform, launching over three million Docker containers per week on EC2 for streaming, recommendations, encoding, and ML workloads.
  2. Uber Makisu — Uber built and open-sourced Makisu to build Docker images in unprivileged Kubernetes pods, using a distributed layer cache to cut build times by up to 90% across thousands of daily builds.
  3. Uber Kraken — Uber runs Kraken, a peer-to-peer Docker registry, in production since 2018; one cluster distributes more than 1 million blobs per day to 15k+ hosts.
  4. Shopify — Shopify ran 100% of production storefront traffic in Docker containers as one of the first large-scale Docker production users, then migrated that container fleet onto Kubernetes via custom tooling like PIPA and kubernetes-deploy.
  5. Spotify Helios — Spotify's earlier in-house orchestrator Helios deployed Docker containers across their backend fleet, before they migrated the bulk of 1,600+ services onto Kubernetes.
  6. Spotify Backstage — Spotify's open-source developer portal Backstage ships as a Docker image so 280+ internal teams can self-host the catalogue that manages 2,000+ backend services.
  7. PayPal — PayPal containerised 700+ applications onto Docker Enterprise, running over 200,000 containers in production and cutting deploy time by roughly 90%.
  8. Pinterest — Pinterest dockerised 100% of its API fleet and the bulk of its stateless services, storing images in Amazon ECR with a replicated secondary registry for prod high availability.
  9. Yelp PaaSTA — Yelp's PaaSTA runs more than 100 production services as Docker containers, with developers declaring build/deploy/route config in YAML and the platform handling the rest.
  10. Airbnb — Airbnb packages its service-oriented architecture into Docker containers and runs hundreds of workloads across tens of Kubernetes clusters and thousands of nodes.
  11. Goldman Sachs — Goldman Sachs is migrating roughly 90% of its software — about 5,000 applications across 8,000 developers — into Docker containers as the base unit of deployment.
  12. Bloomberg — Bloomberg's internal Data Science Platform runs ML training and inference as containers on Kubernetes, with KServe (originally KFServing) serving models from container images.
  13. Salesforce Hyperforce — Hyperforce repackages Salesforce's core stack as Kubernetes-orchestrated containers so the same workloads run on AWS, GCP, and Azure without code changes.
  14. CERN — CERN's HTCondor batch service runs LHC physics jobs inside Docker containers so analysts can pin their own ROOT/CMS software stack without depending on worker-node OS versions.
  15. NVIDIA NGC — NVIDIA publishes GPU-optimised Docker images at nvcr.io — CUDA, PyTorch, TensorFlow, Triton — that ship preconfigured with matching driver/runtime versions so users skip the CUDA install dance.
  16. Hugging Face Spaces — Hugging Face Spaces lets users deploy any ML demo by writing a Dockerfile; the platform builds the image and schedules it on CPU or GPU hardware.
  17. Replit — Every Replit repl is a Docker container running user code as a non-root runner user, providing the isolation boundary while Nix manages packages inside.
  18. GitHub Actions — Hosted runners and the container: job key let CI jobs execute inside arbitrary Docker images, and self-hosted runners themselves are commonly deployed as containers.
  19. GitLab Runner — GitLab Runner's Docker executor spins up a fresh container per CI job using /var/run/docker.sock, giving every pipeline an isolated, reproducible build environment.
  20. Datadog Agent — Datadog ships its monitoring agent as a Docker image; running one agent container per host with the Docker socket mounted auto-discovers every other container and scrapes their metrics.
  21. Stripe CLI — Stripe distributes its developer CLI as a Docker image so teams can run stripe listen --forward-to inside Docker Compose stacks for webhook testing without local installs.
  22. Jupyter Docker Stacks — The Jupyter project publishes scipy-notebook, datascience-notebook, and tensorflow-notebook images so labs and classrooms get an identical notebook environment with one docker run.
  23. VS Code Dev Containers — Microsoft's Dev Containers extension reads a devcontainer.json and Dockerfile, builds an image, and connects the editor's language servers and debuggers to a container so onboarding to a repo is a one-click operation.
  24. Lyft Envoy — Envoy, originally built at Lyft, is distributed and CI-tested via the envoyproxy/envoy-build-ubuntu Docker images, and most production deployments of Envoy ship as a sidecar container next to the application.

Where to go next