Shulou(Shulou.com)05/31 Report--

Editor to share with you a sample analysis of docker volume source code, I hope you will gain something after reading this article, let's discuss it together!

This is in the process of using docker v1.10.3, using convoy as volume driver, in a docker volume remove failure, I had to do an analysis of the source code of docker volume.

Problem: the creation of a deleted volume will fail. The request for no error will be returned to the reproduction process:

Create a container, and volume uses test5_volume

Delete container, delete volume

Failed to create volume with the same name again

At that time, there was a Workaround scheme: create a volume with the same name (of any size) on the host through convoy, and then execute docker volume rm again to delete the volume; then you can recreate the volume through docker volume create. At that time, it was considered that the docker cache was not cleaned in time, so I had to analyze the relevant code.

# # docker volume create source code analysis:

When you look at the flowchart and find-create, it triggers the re-registration of the unregistered driver, only checking whether the volume is in the docker daemon cache, and if so, it is not created. Instead of calling the convoy interface to confirm whether the volume really exists. If the convoy and docker daemon cache information are out of sync at this time, the create operation will not work as expected.

# # docker volume remove source code analysis:

When you look at the flowchart and find-remove, only the volume information recorded in the docker daemon cache will be deleted, and the volume information of docker dameon and convoy will not be synchronized. If the volume data in convoy is inconsistent with the volume data in docker daemon cache at this time, it will not be corrected.

# # docker volume list source code analysis:

When you look at the flowchart and find-list, if a volume is recorded in the convoy but the volume is not in the docker daemon cache, the volume information is synchronized from the convoy to the docker daemon.

# # problem location # the code of docker volume delete # the code of docker volume list can be seen in the first picture. Each time a volume is deleted, the name of the volume is locked, and then the vd.Remove (v) function calls convoy to delete the volume, and then cleans up the cache of the docker.

As can be seen in the second figure, each time the list API is called, List first calls the s.list () function. The list () function is not restricted by locking a single volume. The s.list () function calls convoy to get all the volume, and then for loops each volume in the List method, first locks the name of the volume, and adds it to the cache if the volume does not exist in the cache.

The cause of our problem: there is no lock restriction for s.list () to find convoy to get all volume, and list will for loop to process all volume for a long time, which leads to such a situation: list gets a certain volume of convoy first, then docker receives a request to delete this volume, docker deletes the volume of convoy and deletes its own cache, and then the for loop in list processes this volume. It is found that the volume is no longer in the cache, so the volume is added to the cache (s.setNamed (v, ")). As a result, the volume on the cache converse side has been cleared, but there is still this volume in the cache, and the data on both sides are inconsistent. At this point, when docker receives the creation of the volume with the same name again, it first looks up the cache and finds that the volume already exists, so it no longer creates and returns success directly. Later, when docker receives a request to delete the volume, docker will call convoy to delete, but the volume is no longer in convoy, so it returns a failed message to docker, and docker also returns a failed message.

# # solution when we try to solve this problem, we find that docker version 1.11 has solved this problem: bug: https://github.com/docker/docker/issues/21403 patch: https://github.com/docker/docker/commit/f04334ea040500181727c47dc626171e98660cae solution: in list volume, if the volume does not exist in the cache, it will no longer be added to the cache, so as to avoid having more data in docker than in convoy. Although there is still a problem of data inconsistency, as long as the data of docker is less than that of plugin, docker will request plugin again each time. Conversely, if there is data for a volume in docker, but not in convoy, then a problem arises. The addition of cached lines of code in the figure above causes docker to have more data than convoy, and the problem arises.

I believe that at this stage, everyone is using a larger version of docker than 1.10. Otherwise, type this patch.

After reading this article, I believe you have some understanding of "sample Analysis of docker volume Source Code". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.