3 ms·

A problem I had with some dockerfiles, was that often they rely on debian/ubuntu upstream BUT rely on their own dockerfile container as an intermediary. I under

by wernerb 12y ago

A problem I had with some dockerfiles, was that often they rely on debian/ubuntu upstream BUT rely on their own dockerfile container as an intermediary. I understand this, it makes it easier to maintain if you have a lot of docker containers. But for me 'just pulling from the registry', I have to check out that intermediary dockerfile to ensure that no unexpected things happen or that the correct version of debian/ubuntu is referenced. What I then do is fork their docker containers and replace FROM 'bla/ubuntu' to the official one, to regain control. But this sticks me with the job of then maintaining the container. In short, I wish registry containers would just directly use the ubuntu/debian official images as some sort of guideline for general "public use" docker images. Edit: Off-topic, would love some kind of graph view or some kind of dependency-depth indicator when browsing registry containers, or set it as a requirement.

amouat 12y ago
What do you mean by "rely on their own dockerfile container as an intermediary"? Things like the buildpack-deps image? Graph view would be cool!
- wernerb 12y ago
  Basicly just a reiteration of your #1 point. I have seen containers where they create their own 'parent' containers that point to the ubuntu/debian base-image for their generic app containers. The extra layer irks me, i'd very much like to just have all app-containers depend on official containers. E.g. a project maintainer might install wget in their upstream container, then rely on that image for all its app-containers.
  - amouat 12y ago
    Ok. I think the issue is more transparency than layers though - for example the Hub could let you click on FROM lines and have them expand in place.
  - vidarh 12y ago
    I think the issue there is that once you start building a number of containers, it's easy to start noticing patterns that repeats across your containers, and so it's very tempting to do what you mention to avoid repeating yourself. I sort of agree with you, but I think it reflects a tooling problem in expanding dependencies more than anything. After all, Docker introduces temporary images for nearly every step of the Docker file anyway, so if these "parent containers" are genuine dependencies it's beneficial to collapse the steps for individual app containers down to a set of shared ancestors as possible.

by wernerb 12y ago

amouat 12y ago

What do you mean by "rely on their own dockerfile container as an intermediary"? Things like the buildpack-deps image? Graph view would be cool!

wernerb 12y ago
Basicly just a reiteration of your #1 point. I have seen containers where they create their own 'parent' containers that point to the ubuntu/debian base-image for their generic app containers. The extra layer irks me, i'd very much like to just have all app-containers depend on official containers. E.g. a project maintainer might install wget in their upstream container, then rely on that image for all its app-containers.
- amouat 12y ago
  Ok. I think the issue is more transparency than layers though - for example the Hub could let you click on FROM lines and have them expand in place.
- vidarh 12y ago
  I think the issue there is that once you start building a number of containers, it's easy to start noticing patterns that repeats across your containers, and so it's very tempting to do what you mention to avoid repeating yourself. I sort of agree with you, but I think it reflects a tooling problem in expanding dependencies more than anything. After all, Docker introduces temporary images for nearly every step of the Docker file anyway, so if these "parent containers" are genuine dependencies it's beneficial to collapse the steps for individual app containers down to a set of shared ancestors as possible.