A lesson in dockerizing shell scripts

Original Article ↗ Hacker News Discussion ↗

Efforts to shrink a Docker image for a 500‑line bash tool highlight the tradeoff between minimal image sizes and long‑term maintainability. Commenters warn that manually copying binaries and shared libraries into a `scratch` or Alpine-based image can create fragile, hard‑to‑debug containers that break with OS updates, for only marginal space savings over a straightforward 30‑MB base image. The conversation broadens into when containerizing simple shell scripts is justified, touching on alternatives like static binaries, BusyBox, Nix, and traditional package managers, as well as tooling for analyzing and optimizing images.

Image size vs. complexity

  • Many think the initial ~31 MB image is already “small enough”; further shrinking to ~17 MB isn’t worth the added complexity for most production uses.
  • Several commenters would rather accept a 30–40 MB image than maintain a fragile, highly tuned Dockerfile.
  • Others enjoy the optimization exercise as a learning tool and appreciate the exploration of what’s minimally required to run the script.

Copying binaries and shared libraries

  • Strong criticism of copying binaries and .so files directly from one Alpine image into another (or into scratch) and overwriting system lib/bin paths.
  • Concerns: version skew, broken symlinks, subtle incompatibilities as base images evolve, and brittle images that may silently break later.
  • Some argue this is partly mitigated when source and target use the same base version, but others regard the pattern as an “anti‑package‑manager” reinvention.

Alpine, reproducibility, and pinning

  • Alpine is described as hostile to version pinning and long‑term reproducible builds: packages and indexes disappear quickly.
  • Recommendation: don’t use Alpine if you need reproducible, cache‑friendly Docker builds; snapshot-based Debian images are cited as a more promising direction.

Alternatives for small images

  • Suggestions include:
    • Static binaries or BusyBox builds instead of copying many individual tools.
    • Using Nix to define images declaratively; works, can be very small, but often pulls in large closures (e.g., “gitMinimal” still big) and adds complexity.
    • Rewriting the tool in a compiled language with a single static binary, if someone is willing to invest effort.

Security, trust, and auditing

  • Debate over whether “random shell scripts” or “random Docker images” are safer.
  • Points for scripts: easier to read and run through tools like ShellCheck.
  • Points for containers: isolation via namespaces and volume/network controls, with tools like Dive to inspect contents.
  • Counterpoint: containers are not strong security boundaries; breakouts exist, and auditing whole images plus base layers is nontrivial.

Usefulness of dockerizing a shell script

  • Some find containerization overkill for a 500-line bash script that only needs standard tools.
  • Others argue containers simplify dependency management and make tools reproducible across many machines.
  • Practical concerns raised: you still need a wrapper (script/alias/compose) to mount the working directory and make usage ergonomic.