BAbauerd·Nov 19, 2017
onbuild tags are deprecated: https://github.com/docker-library/official-images/issues/207...
… although using an onbuild image here wouldn't hurt
In Show HN: Example of a polyglot microservice appdocker-library
official-images
Shell2014–2026
docker-library / official-images
official-images
Primary source of truth for the Docker "Official Images" program
23Distinct people
30Mentions
1Explicit recommenders
7KGitHub stars
What to know before exploring
What it is
Primary source of truth for the Docker "Official Images" program
GitHub
Where it is used
- Eclipse Temurin (Adoptium) Docker containers — Adoptium's containers repo documents automated and manual steps to generate and submit an official-images manifest for eclipse-temurin, and states that PRs in docker-library/official-images are inspected for matching release tags. Source
What people are saying
Unless your product requires AIX to function, I recommend against AIX and POWER in general. You aren’t going to be able to get cheap POWER machines for distributed computing in…
lukevp used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:02:05 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year30 dated mentions
Observed mentions: 2014-11-05 02:33:21 UTC to 2026-10-21 15:31:56 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 5 | 1 | 4 |
What Hacker News says
3 sourcesI 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
Read the rest
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/
> If you want Ruby, the habit is to go find someone's "pre-configured" alpine-ruby image (for instance)
I think the habit for most folks (and the best practice) is to use one of the "official" Ruby images[0]. Similar official repositories exist for many server daemons, language runtimes, and command-line tools[1].
> My understanding is that most public image repositories are unmoderated.
To the best of my understanding, the official images are maintained by Docker folks, or people associated with the upstream projects, or some mixture of both.
> most Dockerfiles are built on opaque images registered with an image registry
Far from opaque, the official images are typically well-documented, and the source code is available from the various Git repositories linked to from the library.
So yes, while it's true there are a lot of public images
Read the rest
out there with questionable provenance, there's usually a solid, well-supported foundation to base your own images on.
0. https://hub.docker.com/_/ruby/
1. https://github.com/docker-library/official-images/tree/maste...