| I believe most of your questions have a (mostly) positive answer. Admittedly the Docker project moves fast, so I've tried to provide a link or two for each: > Are these signed with some sort of crypto and known-good keys, similar to package signing keys attached to a package repo, or are we taking Docker's word for it? The official images are all signed with Notary[0] (released <2 years ago). The "Content Trust" feature makes use of TLS plus a number of keys[1]. It can be enabled in required environments to prevent the pulling of non-signed images (`export DOCKER_CONTENT_TRUST=1`). > 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. There is a helpful Chrome extension, OctoLinker[2], that makes the `FROM parent` clickable (among other non-Docker things). I'm sure 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/ |
I wanted to let you know that I gave `docker build --squash` a try today. This is the output I got:
so that feature is not yet mainlined.Also, I encountered another issue today when trying to do a `docker push`. It retried a cache layer multiple times before conceding with `open /dev/mapper/docker-254:0-xxx-yyy-zzz: no such file or directory` on one of the layers. I had to rebuild the image with `--no-cache` to get it to push.
Not doing anything unusual/fancy, just an ordinary docker push, which worked fine on other images before and after. No auto-cleanup scripts running in the background or anything that should cause a layer to go mysteriously missing.