The Curse of Docker

Original Article ↗ Hacker News Discussion ↗

Developers and operators weigh Docker’s benefits in simplifying deployment against its growing role as a blunt packaging tool for server software. Many praise containers for reproducible setups, easier experimentation, and reduced “works on my machine” problems, but criticize image provenance, opaque configuration, root-by-default security, and the burden of patching many separate base systems. Alternatives such as traditional distro packages, Nix, VMs, and more disciplined container practices are raised as ways to regain control over dependencies and long‑term maintenance.

Scope of the Critique: Docker as Distribution vs Deployment

  • Many commenters say the article is really about Docker being misused as a distribution mechanism (like a package format), not about containers for deployment.
  • Complaint: shipping only a Docker image (or docker‑compose stack) hides dependencies, makes integration with existing infra (databases, backups, monitoring, auth, TLS) harder.
  • Defense: for complex apps (e.g., many services like DB, cache, queues), docker compose up dramatically lowers the barrier to trying and running software, especially for hobbyists and small teams.

Trust, Provenance, and “Random Images from the Internet”

  • Concern: people casually run third‑party images with little thought to maintenance, support, update guarantees, architecture support, or long‑term availability.
  • Some argue that “official” org images (e.g., Bitnami, linuxserver.io) are still effectively random internet binaries unless you have a business relationship or clear guarantees.
  • Others counter that all software stacks involve trust (distros, hardware, cloud), and containers are just another trust layer.

Security, Root, and Updates

  • Widely noted problem: running containers as root is normalized and making non‑root/read‑only images is painful, so insecure defaults win.
  • Questions raised about how organizations actually manage base image and library security updates across many containers; some say CI rebuilds + scanners and tools (e.g., Watchtower‑style) make this a “solved” problem, others say in practice most don’t do it well.

Configuration, Filesystems, and Networking

  • Frequent pain points:
    • File/volume mounts and UID mapping are fiddly; copying files in/out of containers often breaks on permissions.
    • Docker networking and Docker Compose become fragile on complex hosts; podman networking also called out as problematic by some.
    • Config generators/entrypoint scripts and multi‑layered config (Helm → env vars → image → app) can make debugging very opaque.

Alternatives and Broader Packaging Debate

  • Nix/NixOS repeatedly cited as a better answer for reproducibility, dependency isolation, and supply‑chain control; others note it still has binary blobs and complexity.
  • Some advocate traditional OS packaging, static binaries (Go, musl), or simple “single EXE/zip” models (as on Windows) as cleaner than Docker.
  • Meta‑theme: Docker is seen both as an enormous practical improvement over pre‑container chaos and as a tool that entrenches laziness, complexity, and opaque stacks.