Reputation: 3826
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
Reputation: 7793
Docker has two mechanisms of identifying images.
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