ruby

there are similar extensions, but this is the one I currently use. > a) still derived from some other upstream Dockerfile (must this file also be validated by Docker to qualify as an "official repo"?) The `FROM` line in the Dockerfile would likely be the first thing to undergo scrutiny, for obvious reasons. Also, all the layers go through security scanning[3], some issues can be fixed[4] and others are tracked upstream (e.g. by Debian in the case of the Ruby image you linked[5]). > you end up with an image that is very bloated due to the way Docker's caching layer functions You can now use `docker build --squash`[6] to combine multiple image layers while still benefiting from layer caching during builds. Also, the final image won't contain files that are added in previous layers and removed in later ones. (And with multi-stage builds recently merged, soon multiple inheritance will be easier.) > Is this "transparency" only the case on "official" images? As far as I can see Docker Hub just stores the pushed binary blob and not the Dockerfile required to build it I would say groups or sole developers that want others to use their images will usually provide documentation and links to the Dockerfiles. Of course, this isn't always possible or desired (e.g. see closed-source projects like Windows Server Core[7], or the countless people using Docker Hub as a free image host.) [0]: https://github.com/docker/notary [1]: https://docs.docker.com/engine/security/trust/trust_key_mng/ [2]: https://octolinker.github.io/ [3]: https://docs.docker.com/docker-hub/official_repos/#how-do-i-... [4]: https://github.com/docker-library/official-images/pulls?utf8... [5]: https://github.com/docker-library/ruby/issues/117 [6]: https://docs.docker.com/engine/reference/commandline/build/#... [7]: https://hub.docker.com/r/microsoft/windowsservercore/

e from the various Git repositories linked to from the library. Well, here's an example [0] of a base Dockerfile. I had to go 3 levels up from the link on the Docker Hub page to get to this one because most of the images are FROM:something. After chasing the tree up, this is a) still derived from some other upstream Dockerfile (must this file also be validated by Docker to qualify as an "official repo"?) and b) a good example of the "brilliance" of the Dockerfile format. That massive set of line continuations is necessary because if you implement the Dockerfile "naively", by making each modification a "RUN" command, you end up with an image that is very bloated due to the way Docker's caching layer functions. Bonus feature: if any of those commands is to return a non-0 exit code, the line will abort. Is this "transparency" only the case on "official" images? As far as I can see Docker Hub just stores the pushed binary blob and not the Dockerfile required to build it, so if you're not picking your image base carefully, there may not be a way to verify its contents (short of introspecting the image). [0] https://github.com/docker-library/ruby/blob/752c5f7cf44870ce...