Full Blog TOC

Full Blog Table Of Content with Keywords Available HERE

Wednesday, October 23, 2019

Docker cleanup using system prune


Running docker build usually involves creating new docker image, and tagging it with the current build number. But this leads to leaving images leftovers on the build machine, that would eventually cause out of disk space issues. Let's examine the reason for that, and how can we address this issue.


The Build Process

The build process usually includes the following steps:
  • Run docker build using tag according to the Jenkins build number
  • Push the build number tagged docker image
  • Tag the image using :latest tag as well
  • Push the latest tagged docker image
For example (assuming 123 is the current build number):

1. docker build -t my-registry/my-image:123 .
2. docker push my-registry/my-image:123
3. docker tag my-registry/my-image:123 my-registry/my-image:latest
4. docker push my-registry/my-image:latest
5. docker rmi my-registry/my-image:123

The problem starts when we run the next build.
Let examine the docker images after running build #123:
REPOSITORY            TAG     IMAGE ID      CREATED             SIZE
my-registry/my-image  latest  8193a6ec2439  17 seconds ago      91.4MB

And now let run build #124:

1. docker build -t my-registry/my-image:124 .
2. docker push my-registry/my-image:124

So the docker images are now:
REPOSITORY            TAG     IMAGE ID      CREATED             SIZE
my-registry/my-image  124     bfef88428b40  17 seconds ago      91.4MB
my-registry/my-image  latest  8193a6ec2439  55 seconds ago      91.4MB

And after the tag to latest command:

3. docker tag my-registry/my-image:124 my-registry/my-image:latest
4. docker push my-registry/my-image:latest

The images are now:
REPOSITORY            TAG     IMAGE ID      CREATED             SIZE
my-registry/my-image  124     bfef88428b40  17 seconds ago      91.4MB
my-registry/my-image  latest  bfef88428b40  55 seconds ago      91.4MB
<none>                <none>  8193a6ec2439  2 minutes ago       91.4MB

So now we have leftover "zombie" image marked with <none>.
This is even we have removed the previous build image, and marked the new build as "latest".
Even after removing the build 124:

5. docker rmi my-registry/my-image:124

We still have the zombie image:
REPOSITORY            TAG     IMAGE ID      CREATED             SIZE
my-registry/my-image  latest  bfef88428b40  55 seconds ago      91.4MB
<none>                <none>  8193a6ec2439  2 minutes ago       91.4MB

The Solution

The solution is to use the command:

docker system prune -f


This would remove any zombie images.
Notice this only works in combination with `docker rmi`  for the current build image, and leave only the 'latest' tag for the image. This ensures that the latest tag is replaced to the new build, and the onld image remains as <none>, hence allowing the docker system prune command to remove it.

From the docker documentation page, we can find the the system prune command removes all unused containers (and more).


See also Delete images from a Private Docker Registry.

No comments:

Post a Comment