As part of revamping the getting started guide I was going to ask a similar question. Some (many?) folks won't have local registries yet and pushing things to the Hub adds an extra burden.
For me this was a workflow issue not a trusted sources question. I think the "right" thing puts the onus on the distro to determine the official repository (Hub or separate) and we already know RHEL will supply its own trusted images.
There's an official Dockerfile for a local registry. Is there an easy way to turn that into a distro registry? Or have the step in a doc to update a local registry from a distro source?
I plan on sending a new outline for a getting started doc next week for comments btw
Brevity and typos result of tiny keyboard and giant thumbs
This is an open question in my mind, asking here to start a discussion.
To what degree is having a Docker registry part of the "Atomic pattern"
that can be applied to a distribution?
The Atomic Host comes from the distribution - it's built from the
distribution's component parts.
However, as we talk about things that might be part of the host, or
might be privileged containers (like sosreport), I feel a bit of a pull
towards the host for trust reasons. My feelings on the Hub are a bit
nuanced and I won't go into detail here, but basically if a distribution
had a registry, it would be possible to ship distribution-specific
"associated tools" with an Atomic Host as containers.
At the moment, neither Fedora nor CentOS (to my knowledge) have
registries. Particularly as we get towards privileged containers that
*do* have some level of host dependency, I'd like to be able to say:
"Oh, you need sosreport? docker pull centos.org/sosreport7" - and to
know that that version of sosreport works with that host.
Beyond the privileged container angle, if it was part of the pattern for
distributions to come with registries, this helps keep the trust
boundary. Not everyone is going to trust all content on the Hub, but if
the images provided by the distribution (and kept to the same level of
rigor, e.g. built from known package components which in turn were built
from known source code), it would keep the same trust level.