3

When building Docker images, I find myself in a strange place -- I feel like I'm doing something that somebody has already done many times before -- and did a vastly better job at it. In most cases, this gut feeling is absolutely right -- I'm taking a piece of software and re-describe everything that's already described in the OS's packaging system in a Dockerfile.

More often than not, I even find myself installing software into the image using a packager manager and then looking inside that package to get some clues about writable paths, configuration files, open ports etc. for my Dockerfile. The duplication of effort between OS packager and Docker packager is most evident in such a case which I assume is one of the more common.

So basically, every Docker user building an image on top of pre-packaged software is re-packaging almost from scratch, but without the time and often the domain knowledge the OS packagers had for trial, error and polish. If we consider the low reusability of community-maintained images (re-basing from Debian to RHEL hurts), we're stuck with copying or re-implementing functionality that already exists and works on OS level, wasting a lot of time and putting a maintenance burden on the poor souls who'd inherit whatever we might leave behind.

Is there any way to resolve this duplication of effort and re-use whatever package maintainers have already learned about a piece of software in Docker?

Nikolai Prokoschenko
  • 8,465
  • 11
  • 58
  • 97

1 Answers1

1

The main source for Docker image reuse is hub.docker.com

Search first there if your system is already described in one of those images.

You can see their Dockerfile, and start your own from one of those images instead of starting from a basic ubuntu or wheezy one.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I think the question here is more generally about better `Dockerfile` experience, i.e. how that could be made more high-level then just a bunch of inlined shell scripts... – errordeveloper Apr 07 '15 at 10:22