Kirill Bulygin
Kirill Bulygin

Reputation: 3826

How to obtain the build ID and to specify it in `FROM`?

Imagine we have FROM python:3.6.4 in our Dockerfile. It appears to be quite specific, so we may expect that every time Docker downloads this image as a part of docker build in a fresh environment, we'll get the same base image.

But that's actually not the case. At the time of writing, this Dockerfile (generated two days ago) was used for the image. The build itself was presumably two days ago too (so apt-get'd packages in the image are from that time), although neither https://hub.docker.com/_/python/ nor https://store.docker.com/images/python shows build details. But, for example, https://hub.docker.com/r/aslushnikov/latex-online/builds/ lists builds.

So two images built from the same Dockerfile may be different. A minor example of why this matters: an image built more than two days ago may generate a warning during pip install (because it has pip 9.0.2 but 9.0.3 is available), while an image built today may not (because it already has 9.0.3). Of course, this concrete issue (which is the discrepancy, not the warning itself) can be fixed using pip install --disable-pip-version-check, but more issues are possible.

As far as I understand, almost the whole point of Docker is repeatability, so it's a bit strange to see a leak in such a common place as specification of the base image. Sometimes this may be preferable (when we want latest fixes) but sometimes not (when we want repeatability).

Theoretically, every image can be tracked in git and so on, but that's a last resort. An ID in a Dockerfile, docker-compose.yml or an argument for docker would obviously be better. The question is: from where to get this ID and where to put it?

Upvotes: 1

Views: 2121

Answers (1)

Yuankun
Yuankun

Reputation: 7793

Docker has two mechanisms of identifying images.

  1. The first one is the well-known tagging mechanism, which gives no guarantee of deterministic deployments because a tag can be reused to point to other images.
  2. The second one is the much less familiar immutable identifier mechanism. The immutable identifier is essentially a SHA256 hash digest. Tags can be reused, but immutable identifiers never will.

See how to pull an image by its immutable identifier: https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier

Upvotes: 2

Related Questions