Docker Community Forums

Share and learn in the Docker community.

Is it safe to perform a Docker pull while the image is being run?

docker

(Dwake) #1

If

  • I’m running a container off an image
  • While the container is running, I run “docker pull” on the digest of the same image that is running (expecting no change)

Is there any danger to the container?

Thanks.


Setting content trust on swarm already running services
(Dvohra) #2

If a Docker image is running it has already been pulled. What is the need to pull a Docker image again? The following command should list the Docker image if it is already running.

docker images

or

sudo docker images


(Dwake) #3

The use case is:

  • I am initially pulling and running an image, but do not have complete control over the pull and am unable to use Content Trust.
  • I want to perform a subsequent pull on the same machine using Content Trust to verify the integrity of the image
  • I want to be sure that this second pull will not affect the container that is already running

Thanks!


(Dvohra) #4

Is it the same tag of the Docker image? If so, it would have an effect as the image with the tag is already pulled and running. If a different tag image would not have an effect. The tag/version is the suffix in an image, for example
nginx:latest, the latest is the tag.


(Dwake) #5

Thanks for your reply. Would you mind saying a little more about why repulling the image (which would essentially be a no-op operation) would affect a container already running that image? Does the container not make its own copy of the image before it starts running?


(Dvohra) #6

A container does not make a copy of the image. Only one image is used regardless of how many containers are started.


(Dwake) #7

That’s very interesting – thanks! So what happens when a container makes changes to its own local filesystem. Is there a copy-on-write semantics?


(Dvohra) #8

The filesystem changes apply only to the filesystem being modified and not the filesystem on the host or the filesystem in an another container. Unless shared volumes are used, refer https://docs.docker.com/engine/userguide/containers/dockervolumes/


(Dvohra) #9

Also when deleting a Docker image, an image does not get deleted till all Docker containers making use of the image are deleted first.


(David Maze) #10

I’m pretty sure there isn’t. This is in large part because I’m pretty sure pulling an image (hex digest) you already have is a no-op. Even some of the cases that the followup posts highlight seem to me like they should be safe.

Let’s say you

docker pull registry.example.com/image:latest
docker run -d -P --name container registry.example.com/image:latest
sleep 300
docker pull registry.example.com/image:latest

After the first docker pull, the tag registry.example.com/image:latest points to some image ID, say 12345678. The docker run creates a new container ID, say 9abcdef0, that points at that image ID. That pairing will never change as long as the container exists; you can’t docker rmi 12345678 without docker rm 9abcdef0 first.

So, the second docker pull hits one of two states. Either the tag still points at the same image ID, and the pull will not re-fetch it, in which case you’re in an unchanged state; or the tag points at a different image ID (2468ace0), in which case the pull gets the new image content, moves the tag to the new image ID, and leaves the old container running. In this last case, docker images will show that 2468ace0 has the tag registry.example.com/image:latest and 12345678 has the tag <none>; docker ps will show that container is running against untagged image 12345678.

The images themselves (and the underlying layers) are immutable; running containers have a copy-on-write layer on top of their topmost image layer. It’s not that docker rmi waits until the last dependent container exits, docker rmi fails and refuses to delete an image that still has a running container based on it.


(Dvohra) #11

Tested with a different Docker image, “mysql”, but the result should be the same with any Docker image.

Run the following commands.

sudo docker pull mysql:latest

sudo docker run --name mysql -e MYSQL_ROOT_PASSWORD=‘mysql’ -d mysql

sudo docker pull mysql:latest

The output from the second docker pull is as follows:
ubuntu@ip-172-30-4-84:~$ sudo docker pull mysql:latest
latest: Pulling from library/mysql
_efd26ecc9548: Already exists _
_a3ed95caeb02: Already exists _
_af2f7dea6ac4: Already exists _
_d347a60f2547: Already exists _
_c09d9d095950: Already exists _
_b21685660552: Already exists _
_7e224052b3b1: Already exists _
_4d4d034e642a: Already exists _
_0f382c7f0090: Already exists _
_259142cd69d8: Already exists _
_3b23b8618fda: Already exists _
Digest: sha256:c5ea4e7879084e75c839f6a3939f3a89519f1e72e5eb9a34b1d02128013c36a0
Status: Image is up to date for mysql:latest
ubuntu@ip-172-30-4-84:~$


(Dvohra) #12

The Docker container already running is not effected.


(Dwake) #13

OK – thanks, everyone, for your help! This is the answer I was hoping for.