Note that pulling by image id may not be supported by Docker: moby/moby#4106.

We could help push/implement that feature, and/or we could potentially work around it by adding a new unique tag to the image.

How does this interact with PullPolicy?
On Oct 9, 2014 3:55 PM, "bgrant0607" notifications@github.com wrote:

Note that pulling by image id may not be supported by Docker:
moby/moby#4106 moby/moby#4106.

We could help push/implement that feature, and/or we could potentially
work around it by adding a new unique tag to the image
https://docs.docker.com/reference/api/docker_remote_api_v1.14/#tag-an-image-into-a-repository
.

—
Reply to this email directly or view it on GitHub
#1697 (comment)
.

@erictune Excellent question!

Current policies are PullAlways (the default), PullNever, and PullIfNotPresent.

Really only PullNever and PullIfNotPresent are useful if one binds to a specific version, though PullAlways would still work -- ideally Docker should realize it doesn't actually need to pull in that case.

I don't expect everyone to use this pass. People who don't care about predictable deployments and rollbacks probably wouldn't use it, for instance, and would just use a combination of PullPolicy and version tags (e.g., ubuntu:14.04) instead.

We could also do image name validation. Currently, pods just stay in Waiting forever and the user has to look at Docker logs to figure this out. This was discussed in #1088, but we should just validate image names as early as possible.

We're working on getting pull be immutable id into the next version of the registry.

Docker 1.6 supports content-addessable images.

Also discussed in the context of pull policy (#3028) and rolling updates (#1353, #1743).

Presentation on our internal package manager:
https://www.usenix.org/sites/default/files/conference/protected-files/lisa_2014_talk.pdf

Greetings,

just today I committed support for obtaining the image digest from the V2 Registry:

https://github.com/shaded-enmity/docker-doug/tree/distv2

It's as simple as:

$ doug-cli digest fedora:21
sha256:f53501a88bdc4bbc026f251671e9b3014699403d2015bf1473444d43a2de736f

A quick introduction into libdoug / doug-cli:

• self-sufficient library/binary for working with image histories and Docker internals
• focused on delivering consistent update model:
  • version information is stored in the tag
  • built-in solver for version-release versioning strategy
  • 'latest' tag is ignored because it's not what people expect it to be

My original plan was to have 'hooks' or 'triggers' into K8s to issue a configuration change when new version of an image was available, but after seeing this issue and #1743 I think that the scope of libdoug fits very well into the requirements:

• self-contained program
• ad-hoc querying of remote registries for image changes
• consistent update model

It's written in Python, but I could rewrite it in Go should that be a problem for integration.

distribution/distribution#387 was merged yesterday, providing a Go client for 2.0 registries.

We could vendor it in and use it directly, or if that's not desirable, we could provide a contrib example that uses the distribution code to get the digest for a specific repo and tag.

Also, see #7203 for information about rkt image identifiers, and the differences between how rkt and Docker identify images.

OpenShift 3.6 implements an admission controller that automatically replaces image tags with digests if the image matches a known construct. I believe weaveworks Flux also has mechanisms for this at config time. With initializers, it should now be possible to resolve images in replicasets to digests automatically, and that may be a good candidate for a simple example of how initializers can be used.

I've been thinking the image "stream" could be specified by an annotation initially and, eventually, a field.

One issue is that access to the image pull secrets is needed.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

/remove-lifecycle stale
/lifecycle frozen

While designing webhooks / apply we've actually had in mind the case where a mutating admission webhook resolves the image tag and swaps in the digest. Unfortunately, to get the right rollback behavior I think you'd have to resolve when the template is submitted and not when the pod is created (so on all of deployment, statefulset, daemonset, ... create/update).

Anyway I don't think there's anything stopping someone from making an image resolver cluster plugin.

(Which is to say, I'm not 100% sure it will work, but I'd be interested in seeing the results if someone tries.)

Openshift's solution:
https://docs.openshift.com/container-platform/3.9/dev_guide/managing_images.html
https://github.com/openshift/origin/blob/master/pkg/image/apiserver/admission/apis/imagepolicy/types.go
https://github.com/openshift/origin/blob/master/pkg/image/apiserver/admission/imagepolicy/imagepolicy.go

Another example solution:
https://carvel.dev/kbld

That would be great as a kubectl plugin.

https://github.com/google/k8s-digester also offers this either as an admission controller or a client-side kpt function.