New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker run doesn't pull down latest image if the image exists locally #13331

Open
mlehner616 opened this Issue May 19, 2015 · 73 comments

Comments

Projects
None yet
@mlehner616

mlehner616 commented May 19, 2015

docker run should have an --pull or --update option to pull down the most up to date version of an image tag, then run. The behavior should match docker build.

See #4238

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 20, 2015

Member

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 #4238 (comment). 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?

Member

thaJeztah commented May 20, 2015

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 #4238 (comment). 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?

@mlehner616

This comment has been minimized.

Show comment
Hide comment
@mlehner616

mlehner616 May 20, 2015

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.

mlehner616 commented May 20, 2015

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.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 20, 2015

Member

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.

Member

thaJeztah commented May 20, 2015

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.

@stevenschlansker

This comment has been minimized.

Show comment
Hide comment
@stevenschlansker

stevenschlansker May 22, 2015

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.

stevenschlansker commented May 22, 2015

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.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 22, 2015

Member

@stevenschlansker I agree, but changing tags to be immutable will not be possible without causing a serious BC breaking change.

However, #10740 and #11109 added support for referring images by digest, which does make this possible.

Member

thaJeztah commented May 22, 2015

@stevenschlansker I agree, but changing tags to be immutable will not be possible without causing a serious BC breaking change.

However, #10740 and #11109 added support for referring images by digest, which does make this possible.

@eburnette

This comment has been minimized.

Show comment
Hide comment
@eburnette

eburnette May 28, 2015

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?

eburnette commented May 28, 2015

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?

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 28, 2015

Member

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.
Member

thaJeztah commented May 28, 2015

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.
@sielaq

This comment has been minimized.

Show comment
Hide comment
@sielaq

sielaq May 29, 2015

+1
@mlehner616 has mentioned

docker run should have an --pull or --update option

which imply that user have to use this option by purpose (it would not be a default option)
and have to deal with any consequences
(so mentioned by @thaJeztah reasons are valid, but if optional and documented - not so important).

This option is very needed,
imagine that we have to deal with hundreds docker slaves
if you prefer "consistence of images" over "speed",
then performance can be solved with local registry.

Sync problem we have solved using mcollective or consul exec to trigger docker pull
whenever new image is released - but not everyone have/use those tools.

sielaq commented May 29, 2015

+1
@mlehner616 has mentioned

docker run should have an --pull or --update option

which imply that user have to use this option by purpose (it would not be a default option)
and have to deal with any consequences
(so mentioned by @thaJeztah reasons are valid, but if optional and documented - not so important).

This option is very needed,
imagine that we have to deal with hundreds docker slaves
if you prefer "consistence of images" over "speed",
then performance can be solved with local registry.

Sync problem we have solved using mcollective or consul exec to trigger docker pull
whenever new image is released - but not everyone have/use those tools.

@eburnette

This comment has been minimized.

Show comment
Hide comment
@eburnette

eburnette May 29, 2015

@thaJeztah Yes, I can understand now why it was done this way by default, but it was surprising at first. Docker run might get you the latest image or it might get you a year old image, you can't tell.

eburnette commented May 29, 2015

@thaJeztah Yes, I can understand now why it was done this way by default, but it was surprising at first. Docker run might get you the latest image or it might get you a year old image, you can't tell.

@rbair23

This comment has been minimized.

Show comment
Hide comment
@rbair23

rbair23 Jun 12, 2015

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.

rbair23 commented Jun 12, 2015

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.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jun 12, 2015

Member

ping @duglin @tiborvass @unclejack (just some random names, sorry) wdyt? I think this is a reasonable request that brings a friendlier UX and parity with docker build --pull.

Member

thaJeztah commented Jun 12, 2015

ping @duglin @tiborvass @unclejack (just some random names, sorry) wdyt? I think this is a reasonable request that brings a friendlier UX and parity with docker build --pull.

@adamkdean

This comment has been minimized.

Show comment
Hide comment
@adamkdean

adamkdean Jun 12, 2015

Just my 2¢, how exactly is docker pull image && docker run image supposed to work with Swarm? I really need a way to pull the new image as part of the run command.

adamkdean commented Jun 12, 2015

Just my 2¢, how exactly is docker pull image && docker run image supposed to work with Swarm? I really need a way to pull the new image as part of the run command.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Jun 12, 2015

Contributor

@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.

Contributor

cpuguy83 commented Jun 12, 2015

@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.

@rbair23

This comment has been minimized.

Show comment
Hide comment
@rbair23

rbair23 Jun 12, 2015

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

rbair23 commented Jun 12, 2015

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

@adamkdean

This comment has been minimized.

Show comment
Hide comment
@adamkdean

adamkdean Jun 12, 2015

@cpuguy83 I got around this by going though each Swarm node and running docker -H $host pull <image> prior to the run, but if I can specify a sha1 digest then that might actually be better. Thanks.

adamkdean commented Jun 12, 2015

@cpuguy83 I got around this by going though each Swarm node and running docker -H $host pull <image> prior to the run, but if I can specify a sha1 digest then that might actually be better. Thanks.

@tiborvass

This comment has been minimized.

Show comment
Hide comment
@tiborvass

tiborvass Jul 24, 2015

Collaborator

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

Collaborator

tiborvass commented Jul 24, 2015

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

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jul 24, 2015

Member

@tiborvass more an "omission"; I think the default behavior does make sense (see #13331 (comment)), 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?

Member

thaJeztah commented Jul 24, 2015

@tiborvass more an "omission"; I think the default behavior does make sense (see #13331 (comment)), 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?

@ledjon

This comment has been minimized.

Show comment
Hide comment
@ledjon

ledjon Jul 30, 2015

I'm not really concerned if it is part of default behavior or a --pull parameter, but I really think there should be a way to do this as part of one command. Perhaps even just spit out a message saying "I am starting this container, but be aware that this is not the latest. use --pull to get the latest"

Just my thoughts on it.

ledjon commented Jul 30, 2015

I'm not really concerned if it is part of default behavior or a --pull parameter, but I really think there should be a way to do this as part of one command. Perhaps even just spit out a message saying "I am starting this container, but be aware that this is not the latest. use --pull to get the latest"

Just my thoughts on it.

@andrerom

This comment has been minimized.

Show comment
Hide comment
@andrerom

andrerom Aug 6, 2015

+1 on this, and +1 on adding this to docker-compose where you just like build don't know about external deps.

andrerom commented Aug 6, 2015

+1 on this, and +1 on adding this to docker-compose where you just like build don't know about external deps.

@coderfi

This comment has been minimized.

Show comment
Hide comment
@coderfi

coderfi Aug 8, 2015

--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.

coderfi commented Aug 8, 2015

--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.

@andrerom

This comment has been minimized.

Show comment
Hide comment
@andrerom

andrerom Aug 9, 2015

@coderfi This is for docker run, support for pull already exists for docker build which is what you are most likely looking for given you refer to FROM lines in DockerFile.

The need to also add this to docker run is most clear for tools like Docker compose being able to very simple being able to add such features for docker-compose up which would be huge, and is much needed.

andrerom commented Aug 9, 2015

@coderfi This is for docker run, support for pull already exists for docker build which is what you are most likely looking for given you refer to FROM lines in DockerFile.

The need to also add this to docker run is most clear for tools like Docker compose being able to very simple being able to add such features for docker-compose up which would be huge, and is much needed.

@bmannix

This comment has been minimized.

Show comment
Hide comment
@bmannix

bmannix Sep 18, 2015

+1 for a --pull flag. This would simplify my workflows.

bmannix commented Sep 18, 2015

+1 for a --pull flag. This would simplify my workflows.

@yinchuan

This comment has been minimized.

Show comment
Hide comment
@yinchuan

yinchuan Oct 13, 2015

+1 for a --pull flag

yinchuan commented Oct 13, 2015

+1 for a --pull flag

@coolljt0725

This comment has been minimized.

Show comment
Hide comment
@coolljt0725

coolljt0725 Oct 14, 2015

Contributor

I think this is a easy client only implementation.
docker run will call createContainer which will pull the image.

Contributor

coolljt0725 commented Oct 14, 2015

I think this is a easy client only implementation.
docker run will call createContainer which will pull the image.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Oct 14, 2015

Member

@coolljt0725 sounds good, are you interested in opening a PR?

Member

thaJeztah commented Oct 14, 2015

@coolljt0725 sounds good, are you interested in opening a PR?

@coolljt0725

This comment has been minimized.

Show comment
Hide comment
@coolljt0725

coolljt0725 Oct 14, 2015

Contributor

PR is coming :)

Contributor

coolljt0725 commented Oct 14, 2015

PR is coming :)

@stefan-evinance

This comment has been minimized.

Show comment
Hide comment
@stefan-evinance

stefan-evinance commented Apr 21, 2017

+1

@dolobanko

This comment has been minimized.

Show comment
Hide comment
@dolobanko

dolobanko Jun 12, 2017

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

dolobanko commented Jun 12, 2017

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

@schasse

This comment has been minimized.

Show comment
Hide comment
@schasse

schasse commented Jun 14, 2017

+1

@bombadiltom

This comment has been minimized.

Show comment
Hide comment
@bombadiltom

bombadiltom commented Jun 14, 2017

+1

@abdvl

This comment has been minimized.

Show comment
Hide comment
@abdvl

abdvl commented Jun 18, 2017

+1

@MarcinMilewski

This comment has been minimized.

Show comment
Hide comment
@MarcinMilewski

MarcinMilewski commented Jun 22, 2017

+1

@centigrade-thomas-becker

This comment has been minimized.

Show comment
Hide comment
@centigrade-thomas-becker

centigrade-thomas-becker Jun 29, 2017

Please stop the +1 spam

centigrade-thomas-becker commented Jun 29, 2017

Please stop the +1 spam

joekir pushed a commit to cloudfoundry-incubator/bpm-release that referenced this issue Jul 18, 2017

Joe Kirwin
Added `docker pull` to test script
- This is because `docker run` [doesn't pull the latest image if the tag
  exists locally](moby/moby#13331)
- It's now an idempotent run and will avoid future frustrations.

Signed-off-by: Joe Kirwin <jkirwin@pivotal.io>

@thaJeztah thaJeztah added this to backlog in maintainers-session Aug 3, 2017

@thaJeztah thaJeztah removed this from backlog in maintainers-session Aug 3, 2017

@kyprifog

This comment has been minimized.

Show comment
Hide comment
@kyprifog

kyprifog commented Aug 15, 2017

sigh...

@montanaflynn

This comment has been minimized.

Show comment
Hide comment
@montanaflynn

montanaflynn Sep 27, 2017

The kubernetes equivalent would be imagePullPolicy which is something I always put on.

The default pull policy is IfNotPresent which causes the Kubelet to skip pulling an image if it already exists. If you would like to always force a pull, you can do one of the following:
set the imagePullPolicy of the container to Always.

montanaflynn commented Sep 27, 2017

The kubernetes equivalent would be imagePullPolicy which is something I always put on.

The default pull policy is IfNotPresent which causes the Kubelet to skip pulling an image if it already exists. If you would like to always force a pull, you can do one of the following:
set the imagePullPolicy of the container to Always.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Sep 28, 2017

Member

See the continuation in #13331 #34394, which has a similar proposal

Member

thaJeztah commented Sep 28, 2017

See the continuation in #13331 #34394, which has a similar proposal

@montanaflynn

This comment has been minimized.

Show comment
Hide comment
@montanaflynn

montanaflynn Sep 28, 2017

@thaJeztah that is this issue

montanaflynn commented Sep 28, 2017

@thaJeztah that is this issue

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Sep 28, 2017

Member

@montanaflynn oops, copy/pasta mistake: updated

Member

thaJeztah commented Sep 28, 2017

@montanaflynn oops, copy/pasta mistake: updated

@kwerle

This comment has been minimized.

Show comment
Hide comment
@kwerle

kwerle Nov 15, 2017

Specifically, I am running docker as a child process command. It's fairly easy to invoke a single command and have it run and attach to its stdin/out and all that good stuff. It's significantly more complicated to have to try to pull and then run the actual command that I want to run whether the pull succeeds or not.

kwerle commented Nov 15, 2017

Specifically, I am running docker as a child process command. It's fairly easy to invoke a single command and have it run and attach to its stdin/out and all that good stuff. It's significantly more complicated to have to try to pull and then run the actual command that I want to run whether the pull succeeds or not.

@lanoxx

This comment has been minimized.

Show comment
Hide comment
@lanoxx

lanoxx Dec 14, 2017

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.

lanoxx commented Dec 14, 2017

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.

@chenliu0831

This comment has been minimized.

Show comment
Hide comment
@chenliu0831

chenliu0831 Dec 20, 2017

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

chenliu0831 commented Dec 20, 2017

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

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 21, 2017

Member

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

Member

thaJeztah commented Dec 21, 2017

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

@bean5

This comment has been minimized.

Show comment
Hide comment
@bean5

bean5 Dec 24, 2017

bean5 commented Dec 24, 2017

@NicoTexas

This comment has been minimized.

Show comment
Hide comment
@NicoTexas

NicoTexas Feb 1, 2018

Rather than an option, I think a convention would be better, like the Maven SNAPSHOT one.
I am thinking of compatibility with Compose for example, but also that I would turn on this option almost everywhere, which at the end would create more risks and break the immutability contract of Docker images.

NicoTexas commented Feb 1, 2018

Rather than an option, I think a convention would be better, like the Maven SNAPSHOT one.
I am thinking of compatibility with Compose for example, but also that I would turn on this option almost everywhere, which at the end would create more risks and break the immutability contract of Docker images.

@bean5

This comment has been minimized.

Show comment
Hide comment
@bean5

bean5 Feb 2, 2018

bean5 commented Feb 2, 2018

@purnendu91

This comment has been minimized.

Show comment
Hide comment
@purnendu91

purnendu91 Aug 23, 2018

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 …
?

purnendu91 commented Aug 23, 2018

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 …
?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Aug 23, 2018

Contributor

No.

Contributor

cpuguy83 commented Aug 23, 2018

No.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment