moby: docker run doesn't pull down latest image if the image exists locally

Please stop the +1 spam

I think it’s a major issue/feature that should be considered to implement, as it has been reported over 2 years ago.

USER POLL

The best way to get notified of updates is to use the Subscribe button on this page.

Please don’t use “+1” or “I have this too” comments on issues. We automatically collect those comments to keep the thread short.

The people listed below have upvoted this issue by leaving a +1 comment:

@alexw23 @jonatanblue @Skilgarriff @david-antliff-imgtec

+1

I strongly agree that tags should be immutable.

An alternative approach may be to have a convention that “latest” tag or rather dev/unstable/snapshot should be auto-fetched from the Docker Hub if image checksum differs.

Similar approach has Maven regarding artifacts that have -SNAPSHOT in the version number.

+1

Thanks for your constructive comment @chenliu0831, it’s appreciated

IMO this is a good indication that tags should be immutable – especially once caching mirrors start to come into play, the behavior of changing tags becomes incredibly complex and hard to manage.

Additionally, one of the “big selling points” of Docker is that when I docker run myapp:v3.1.4, I get the exact same image as anybody else doing so. Mutable tags breaks this promise. Anecdotally, we already were bitten by this once when an upstream image of etcd overwrote a release tag with a “fixed” version that introduced a regression.

I’ve got a PR open to the CLI that should address this, if anybody wants to review: https://github.com/docker/cli/pull/1498

How about having a separation similar to git where git distinguishes between local and origin, so you could do something like this:

docker run foo-image:origin/latest  #pulls latest version from docker hub and runs it
docker run foo-image:latest         #uses the version tagged as `latest` from the local repository

This would also give users there necessary semantics in scripts to describe if they want automatic updates of if they want to stay on a certain locally cached version.

+1

–pull +1 for this feature

+1

+1

A force pull would be very useful. +1

I was just bitten by this. From an API perspective, the mistake the Docker team made was adding the shortcut to “run” to auto-pull images. The problem is that pulling on “run” becomes a modal operation. How the run command behaves w.r.t. pulling images has 2 modes: it behaves one way if the image has not been previously pulled and another way if it has. This of course is not naturally visible in the API – you have to read documentation (or spend time debugging as I did and hit the internet) to learn about this mode in the API.

If the run command never auto-pulled, then the API would no longer be modal and it would be predictable (yes the simple intro example is 2 lines now instead of 1 but everybody knows what is going on and how things work and that is a really big deal for usability).

Or you have to make it so that by default “run” always pulls. I can see both reasons that @thaJeztah gives as good reasons not to want to do this.

+1

i really need this feature. +1

LOL can’t believe this issue is still around! that’s the NO.1 docker gotchas I think

sigh…

It would be also cool see that flag on restart, so do that:

docker restart --pull container_name

instead of:

docker stop container_name
docker rm -v container_name
docker run --name container_name …

The problem there also what I should remember or store somewhere previous run options.

+1

I don’t want it pull by default. I want the option to make it always check when it’s run.

There are some good reasons not to have it pull by default (or at least to expose both the options , i.e. to auto-pull or not to the user):

• you often don’t want to pull latest tags, because it can include breaking changes that you need to check and prepare for, before applying them in your production environment. Note that latest tags are regular tags, there is nothing special about them compared to other tags (afaik). It’s just a best practice, but there is no guarantee whatsoever on how a maintainer follow the ‘latest’ best practice (e.g. will it always point to latest stable image? or might it also point to latest overall image, including pre-releases?).
  • Some popular images in docker-compose setups, like e.g. webhippie/mariadb, manage to only have a latest tag and make braking changes to them. You should be very careful with accidentally pulling them. It happened to me once that I pulled a newer version of webhippie/mariadb:latest, which contained a major mariadb upgrade (according to semantic versioning) with braking changes that broke my setup. You’d better have db backups before that happens to you 😉
• Some maintainers manage to make breaking changes even in the same tags (even if it’s not a latest tag). I experienced that with the official owncloud images before.

Bottom line: you first want to make sure that you trust a specific maintainer to provide you with a safely auto-pullable tag and/or have proper backup practices in place before you enable auto-pull on docker run in many cases.

Lastly: even if you’d want to change the default, please consider that you might get a whole lot of angry admins after you after they realize that suddenly the pulling behavior changed and started breaking there setups. Some admins consciously rely on the assumption that new version of a tag won’t be pulled automatically.

@rbair23 Actually the API does not automatically pull, this is strictly a client-side implementation, and the right one IMO.

@adamkdean To get around this (and in general is good practice anyway), people should take advantage of the new ability to specify an image via it’s content addressable digest. https://docs.docker.com/reference/commandline/cli/#listing-image-digests Though the UI (both in Hub and the CLI) could be better here, it’s a great feature.

I am actually using this work-around and generally agree. However, it comes down to UX and consistency. The very same argument could be made for the --no-cache flag where you could just docker rmi myimage:tag && docker build -t myimage:tag . So why does --no-cache exist? While they appear to be effectively doing the same, it’s not necessarily clear to the user if docker is performing other optimizations with the --no-cache flag set that wouldn’t happen using the workaround. A simple flag to pull is a lot cleaner.

Ah, yes, https://github.com/docker/cli/pull/1498 has been merged, but missed the cut-off for Docker 19.03, so will ship as part of Docker 19.09 (but you can download nightly builds with that change)

Let me close this one

It is a big gotcha I think. I can’t imagine it would be hard to add. Docker is open source, right? Let’s just add it and make a merge request.

On Thu, Dec 21, 2017, 1:25 AM Sebastiaan van Stijn notifications@github.com wrote:

Thanks for your constructive comment @chenliu0831 https://github.com/chenliu0831, it’s appreciated

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/moby/moby/issues/13331#issuecomment-353288143, or mute the thread https://github.com/notifications/unsubscribe-auth/AB9SJiIyR-fvEDcCOzMwS6BFIOaymb1zks5tChYAgaJpZM4EgvtS .

@Hubbitus it’s unlikely that will be implemented for docker run, but you can find similar functionality in docker service update, which does exactly that

I’d really like to see this feature too. After rebuilding, I’d like to send a single docker command to remote hosts to start a container, but currently I have to send two: docker pull and docker run.

I found it surprising that docker didn’t check for new versions by default. Currently, if the image doesn’t exist, it pulls the newest version but from then on it doesn’t check or do a pull. Was it done that way for performance reasons?

any updates on this issue?

Is this feature included /developed in the current version?

Or do we still have to docker stop container_name docker rm -v container_name docker run --name container_name … ?

+1

--pull would be huge!

It is too cumbersome, for every Dockerfile, to:

• figure out what the base image is (awk the FROM line? hard code it in your build script?)
• issue a docker pull for that if it contains the word ‘latest’ or is omitted (and/or leveraging additional build/CI systems)
• then proceed to build

A generic option like --pull, --pull-always, --pull-if-missing, etc. would be much simpler than trying to do the above in every project.

Yes, you could argue: “well why not just specify the image version”.

The problem with that is the case when you are maintaining a series of Dockers which build upon each other.

We’d have to roll in a complex build system to propagate base versions down as they get build up … and that would mean hacking the downstream Dockerfiles each time… (or dynamically generating them? even messier…)

It is much simpler to just use the ‘latest’ for every FROM base in our Dockerfiles.

I agree on the UX perspective. But we need to prevent adding features “just because we can”. Not entirely against, so don’t give up hope yet. Let’s see what others think.

Wrt docker rmi myimage:tag && docker build -t myimage:tag .. I don’t think that’s comparable. Doing that won’t work if the old myimage:tag is still in use by a container, while --no- cache does. But I understand why you’re comparing.

+1

We deploy our images via systemd which doesn’t like long running processes such as docker pull in the ExecStartPre fields and we have a few images, so I don’t want to have to have a second service file just to pull the images first. A simple --pull or --update would be great.

@tiborvass more an “omission”; I think the default behavior does make sense (see https://github.com/docker/docker/issues/13331#issuecomment-106361207), but adding a --pull option is something that needs to be added.

Now that you completed the “docker daemon” PR, are you perhaps interested in creating a PR? 😉

Wrt the reference to “trust”; would that mean that on every build, Docker should pull / verify the image?

cough https://github.com/moby/moby/issues/13331#issuecomment-436380634

@sunshineo I need a 😐 emoji

–pull +1

@cpuguy83 I was using API in the general term applying it to the programming interface exposed by the ‘docker’ command, not the REST API.

I found it surprising that docker didn’t check for new versions by default. Currently, if the image doesn’t exist, it pulls the newest version but from then on it doesn’t check or do a pull. Was it done that way for performance reasons?

I think this was discussed at some point, but (if I recall correctly) there were a number of reasons;

• If I have a locally built image (foobar:latest), and want to test it before pushing, automatically pulling that image from the registry would overwrite the local image.
• Performance; pulling for each run can have quite an performance impact.

Running the following on a cron may be appropriate for some uses: docker images --filter "dangling=false" --format "{{.Repository}}:{{.Tag}}" | xargs -L1 docker pull.

PR is coming 😃

@thaJeztah I think this is not a feature, it’s a bug. With the ongoing trust efforts I hope that this will be resolved.

@bean5 if you’re having that issue for docker build, then there’s already --pull flag, however if you need builds to be exactly the same, you should use docker content trust, or refer to images by digest, e.g.:

FROM alpine@sha256:3dcdb92d7432d56604d4545cbd324b14e647b313626d99b889d0626de158f73a

or

docker run image@sha256:......

Alternatively, docker pull image && docker run ... should do the trick if you want to always pull.

This issue is still something we want to address, but last PR opened for this, there’s was no consensus on design yet; see https://github.com/docker/docker/pull/16609

Unfortunately, even if you use --no-cache, you are affected by this. This lack of pulling makes it really easy for builds to differ between machines, particularly Jenkins slaves, especially when one slave is much older than the other. Automated and non-automated (developer) builds are affected by this.

I think it would be consistent with docker build --pull, on the other hand; the --pull flag had to be implemented because for build there’s no alternative way to deal with this, see https://github.com/docker/docker/issues/4238#issuecomment-54322081. For docker run, this would work: docker pull myimage:tag && docker run myimage:tag

@unclejack you implemented this for docker build at the time, any thoughts?