Docker completely deletes private library images

First, let’s take a look at the general practices on the Internet

By default, private libraries do not support image deletion. You need to modify the config.yml configuration file, add delete: enabled: true under the storage node, and then restart the private library.

The image deletion API provided by Docker is:

DELETE ip:port/v2/<repository>/manifests/<reference>

repository is the mirrored repository

reference is the digest generated after the image is pushed successfully: sha256 value

Get digest:

curl --header "Accept: application/vnd.docker.distribution.manifest.v2+json" -I -XGET <private library ip>:port number/v2/<image repository>/manifests/<image tag>

Notice:

--header "Accept: application/vnd.docker.distribution.manifest.v2+json" This header must be added. If it is not added, the Content-Type is v1+prettyjws and the digest obtained is wrong! !

example:

curl --header "Accept: application/vnd.docker.distribution.manifest.v2+json" -I -XGET 192.168.120.107:5000/v2/my-registry/manifests/1.0

To delete an image:

example:

curl -I -X DELETE http://192.168.120.107:5000/v2/my-repository/manifests/sha256:4d523adb3c653bab7dfd0326081860b3cba24dc393f69d6731daa513c435ec0c

After deletion, let's check the private library

curl 192.168.120.107:5000/ v2/my-repository/tags/list

You will find that the tag you just deleted is gone. However, if you check the file size of the private library image storage directory in the garage before and after executing the command, you will find that there is not much change.

Obviously the data is not really deleted, we still need to run the garbage collection command provided by Docker.

Garbage Collection

We need to log in to the server where the private library is located and then execute the command:

docker exec -it <container ID or container name of the private library> sh -c 'registry garbage-collect /etc/docker/registry/config.yml'

Of course, you can also enter the container of the private library and execute:

docker exec -it <container ID or container name of the private library> sh
registry garbage-collect /etc/docker/registry/config.yml

This method is very troublesome. It can only delete tags but not repositories. After deletion, many empty folders will be left in the blobs directory. Moreover, if there are multiple tags in a repository and the data of these tags are the same, deleting one tag will delete all tags at the same time.

Although there are Python scripts for deleting private library images on the Internet, I don’t think they are easy to use.

I won't be satisfied with this, so I wrote a sh script myself to see the effect first.

The script also has some user-friendly prompts, and the sh script is easy to understand and expand. I have also uploaded the script to gitHub. If you are interested, you can download it and try it.

gitHub address: https://github.com/hushuai86/docker-delete

Download and run:

#First download the script to the /usr/local/bin/directory curl https://raw.githubusercontent.com/hushuai86/docker-delete/master/docker-delete-2.0.sh | sudo tee /usr/local/bin/docker-delete >/dev/null

#Give executable permission chmod a+x /usr/local/bin/docker-delete

#Private library image storage directory path global environment variable (this path is the path to mount the /var/lib/registry directory in the private library container to the local machine using the -v command when running the private library container) #Example: /opt/data/registry is the directory where the private library image storage directory is mounted to the local machine when I run the container echo "export DOCKER_REGISTRY_DIR=/opt/data/registry" >>/etc/profile

#Run private library container ID global environment variable setting (the ID of the running private library container) #Example: 89b9b3c9054ay is the ID of my private library container echo "export DOCKER_REGISTRY_CONTAINER_ID=89b9b3c9054a" >>/etc/profile

#Make the configuration effectivesource /etc/profile

Then you can use the docker-delete command. If you feel uncomfortable with the script, you can edit the script and change it yourself.

Principle analysis:

(In the following screenshot, /opt/data/registry is the directory where the private library image storage directory is mounted to the local directory when I run the container)

There are two folders blobs and repositories under the private library image storage directory

The repositories directory contains several files named after the mirror repository.

In other words, if you want to know what images are in the private library, just look at the subfolders in this folder.

In each image repository folder/_manifests/tags directory, you can see which tags the image has

However, the real data of the image is not in the repositories directory, but is stored in the blobs directory in the form of data blocks. An image is divided into multiple data blocks, which is the association relationship like 'marking blob ...' output when executing the garbage collection command. The association between the image and the data block is the sha256 value in the repositories/mirrorrepository/_manifests/revisions/sha256/ directory.

In the directory named after the sha256 value, there is a link file, and the content is this sha256 value

After my test, I found that as long as this link file is deleted and the garbage collection command 'registry garbage-collect /etc/docker/registry/config.yml' is executed in the private library container, the blobs associated with this sha256 value will be completely deleted.

However, an image may have many tags, so which tag does the blobs data associated with this sha256 value belong to?

When we go to a tag/index/sha256/ directory of the image, we will find a folder named after the sha256 value, and this sha256 value exists under the previous revisions/sha256/. There is also a link file in this folder, which saves the sha256 value.

So according to my understanding, when we call the API provided by docker to delete a tag, we will get the sha256 value in the tag/index/sha256/<sha256 value>/link file of this image, and then check whether there are other tags associated with this sha256 value. If so, only delete this tag folder. If not, then when deleting the tag file, the link file corresponding to the changed sha256 in the revisions/sha256/ directory will also be deleted. In this way, when the garbage collection command is executed in the container, the blobs data associated with the sha256 value will be completely deleted.

Special Note:

After completely deleting the data of an image, you need to restart the private library container. If you do not restart it, when you push the image to the private library again, it will always output "Layer already exists", which seems to be pushed up, but if you delete the local image and then pull it again, you will get an error.

Of course, there is this step in the script I wrote

The above is my personal experience. I hope it can give you a reference. I also hope that you will support 123WORDPRESS.COM. If there are any mistakes or incomplete considerations, please feel free to correct me.