Docker image p2p distribution method based on cloud mobile edge room
By reading and importing data streams directly from the local container runtime in the cloud phone edge data center, the resource consumption, compatibility, and efficiency issues in Docker image distribution are resolved, achieving an efficient and stable image distribution solution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HUNAN XIAOSUAN TECH INFORMATION CO LTD
- Filing Date
- 2026-02-09
- Publication Date
- 2026-05-29
Smart Images
Figure CN122111335A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of data processing technology, and in particular to a Docker image p2p distribution method based on cloud mobile phone edge data centers. Background Technology
[0002] Currently, in containerized deployments, especially during the cluster deployment and updates of large-scale cloud phone instances, rapidly distributing Docker images to a large number of edge nodes is a key challenge. Existing technologies include P2P-based image distribution solutions, such as Dragonfly. These solutions typically require each peer node to allocate independent storage space on its local disk as a cache to store downloaded image data blocks. When a node needs a specific image, it pulls the data block from the central image repository or another peer node that owns the data block and writes it to its local cache. Subsequent nodes can then pull the cached data block from that node, thereby reducing the pressure on the central repository and network bandwidth consumption.
[0003] However, existing technical solutions have the following drawbacks: 1. Resource Consumption and Consumption: Additional fixed disk resources need to be allocated on each host machine as dedicated cache space. When the cache space is insufficient, algorithms such as LRU need to be used to frequently clean up the cache. This not only leads to unstable cache hit rates, but also generates a lot of write operations on the disk, affecting disk lifespan.
[0004] 2. Compatibility and version support issues: Some existing P2P solutions have compatibility issues with integration with Docker or specific container runtimes, and support for newer Docker image formats (such as the OCI standard) may be incomplete, leading to difficulties in deployment in complex production environments.
[0005] 3. Uncontrollable caching effect: The popularity of images changes over time, and general algorithms such as LRU cannot accurately adapt to the characteristics of long-term validity and short-term concentrated retrieval of image data. This may lead to the accidental cleanup of high-value image layers, making the cache hit effect unpredictable and making it difficult to guarantee the stability of distribution efficiency.
[0006] 4. Data redundancy and efficiency: Existing solutions typically involve a process of "download-write to cache-read-transfer". Data needs to undergo a complete write and read process on the disk of the peer node. In a high-speed network environment, disk I / O may become a performance bottleneck.
[0007] It is evident that there is an urgent need for a Docker image p2p distribution method based on cloud phone edge data centers that offers high transmission performance, cache hit rate, and compatibility. Summary of the Invention
[0008] In view of this, the present disclosure provides a Docker image p2p distribution method based on cloud mobile phone edge data center, which at least partially solves some of the problems existing in the prior art.
[0009] This disclosure provides a method for P2P distribution of Docker images based on cloud phone edge data centers, including: Step 1: Each edge node reports the metadata of its locally stored Docker image layer to the central coordinator; Step 2: When the first edge node needs to pull the target Docker image, it sends a query request to the central coordinator to obtain the list of owner nodes corresponding to each image layer that makes up the target Docker image. Step 3: The first edge node initiates a transmission request for the corresponding required mirror layer to at least one second edge node based on the list of owner nodes. Step 4: In response to the transmission request, the second edge node reads the raw data of the required image layer from the image storage structure of its local container runtime, and sends the raw data to the first edge node in the form of a data stream. Step 5: The first edge node receives the data stream and directly imports the data stream into its local container runtime. Step 6: After importing the required mirror layer into the first edge node, report the metadata of the mirror layer to the central coordinator.
[0010] According to a specific implementation of an embodiment of this disclosure, step 1 specifically includes: When an edge node starts up and / or its locally stored Docker image layer changes, it triggers an operation to report metadata to the central coordinator.
[0011] According to a specific implementation of this disclosure, the central coordinator is used to maintain a global mapping table between mirror layers and edge nodes, and responds to the query request based on the mapping table, returning the network address information of at least one second edge node that has the required mirror layer.
[0012] According to a specific implementation of an embodiment of this disclosure, step 3 specifically includes: The first edge node selects at least one second edge node from the owner node list based on preset indicators of each node in the owner node list and initiates a transmission request for the corresponding required mirror layer. The preset indicators include network status, node load, or geographical location.
[0013] According to a specific implementation of an embodiment of this disclosure, step 4 specifically includes: The second edge node reads the raw data from the image storage directory of its local container runtime, without writing the raw data to a temporary cache file during the reading process.
[0014] According to a specific implementation of an embodiment of this disclosure, step 5 specifically includes: After receiving the data stream, the first edge node does not write it to the local disk cache, but directly pipelines it into the local container runtime, where the container runtime completes the assembly and storage management of the image layer.
[0015] According to a specific implementation of an embodiment of this disclosure, the method further includes: If the list of owner nodes returned by the central coordinator is empty, or if pulling the required image layer from all second edge nodes fails, the first edge node will fall back to pulling the required image layer from the central image repository.
[0016] According to one specific implementation of this disclosure, the metadata of the mirror layer includes a summary identifier and size information of the mirror layer.
[0017] According to one specific implementation of this disclosure, the container runtime includes Docker or Containerd.
[0018] The Docker image P2P distribution scheme based on cloud phone edge data centers in this embodiment includes: Step 1, each edge node reports the metadata of its locally stored Docker image layers to the central coordinator; Step 2, when a first edge node needs to pull a target Docker image, it sends a query request to the central coordinator to obtain a list of owner nodes corresponding to each image layer that makes up the target Docker image; Step 3, based on the list of owner nodes, the first edge node initiates a transmission request for the corresponding required image layer to at least one second edge node; Step 4, in response to the transmission request, the second edge node reads the original data of the required image layer from the image storage structure of its local container runtime, and sends the original data to the first edge node in the form of a data stream; Step 5, the first edge node receives the data stream and directly imports the data stream into its local container runtime; Step 6, after the first edge node imports the required image layer, it reports the metadata of the image layer to the central coordinator.
[0019] The beneficial effects of the embodiments disclosed herein are as follows: 1. Eliminate dedicated caching and disk overhead: This solution eliminates the need to allocate and manage dedicated cache disk space on each peer node, avoiding disk I / O pressure and overhead caused by frequent writing and cleaning of cached data. Nodes share the mirrored data that they are "using," requiring no additional storage overhead.
[0020] 2. High and stable cache hit rate: Due to the immutability and long lifespan of Docker image layers, nodes report persistent image layers. As long as the image is not deleted, its data can always serve as a P2P source, greatly extending the availability of valid data and significantly improving the stability and predictability of P2P distribution hit rate.
[0021] 3. Higher transmission efficiency: It adopts the mode of "reading and transmitting at the same time and importing directly at runtime". The data avoids redundant disk write operations of "writing to disk first and then reading" in the transmission path, reducing latency. Especially in high-speed network environment, it can make fuller use of network bandwidth and improve distribution speed.
[0022] 4. Better compatibility: This solution operates at the image layer level, interacting with the container runtime, without intruding on the container runtime's internal storage format or virtualization technology. It only requires obtaining the raw data files of the image layer from the node and importing them into the target runtime. This decouples it from specific container runtimes (Docker, Containerd, etc.) and virtualization solutions (used in cloud phones), resulting in stronger compatibility.
[0023] 5. More rational resource utilization: It utilizes the existing mirrored storage of edge data center nodes as a natural and dynamic "cache", which is a resource reuse mode that is used on demand and does not require pre-allocation, thus improving the overall storage resource utilization efficiency. Attached Figure Description
[0024] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0025] Figure 1 A flowchart illustrating a Docker image p2p distribution method based on a cloud phone edge data center, provided in this embodiment of the disclosure; Figure 2 This is an overall structural diagram of a Docker image p2p distribution method based on a cloud phone edge data center provided in this embodiment of the disclosure; Figure 3 This is a core flowchart of a Docker image p2p distribution method based on a cloud phone edge data center, provided in an embodiment of this disclosure. Detailed Implementation
[0026] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.
[0027] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.
[0028] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.
[0029] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.
[0030] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.
[0031] This disclosure provides a method for P2P distribution of Docker images based on cloud phone edge data centers, which can be applied to the containerized deployment process in cloud phone scenarios.
[0032] See Figure 1 This is a flowchart illustrating a Docker image p2p distribution method based on a cloud phone edge data center, provided in an embodiment of this disclosure. Figure 1 , Figure 2 and Figure 3 As shown, the method mainly includes the following steps: Step 1: Each edge node reports the metadata of its locally stored Docker image layer to the central coordinator; In practice, each edge node (Peer) proactively reports the metadata information (such as image layer digest, size, etc.) of all Docker image layers it currently owns to the central coordinator when it starts up or when its local image layer changes (such as pulling or deleting an image).
[0033] Step 2: When the first edge node needs to pull the target Docker image, it sends a query request to the central coordinator to obtain the list of owner nodes corresponding to each image layer that makes up the target Docker image. In practice, the coordinator maintains a global, dynamic mapping table of image layers and peer nodes. It does not store the actual image data; it only acts as a discovery service. When an edge node (called a requesting node) needs to pull a Docker image, it first queries the coordinator for a list of owner nodes of all the image's constituent layers.
[0034] Step 3: The first edge node initiates a transmission request for the corresponding required mirror layer to at least one second edge node based on the list of owner nodes. For example, the requesting node selects the optimal source node (or multiple source nodes) to establish a direct network connection based on the list returned by the coordinator.
[0035] Step 4: In response to the transmission request, the second edge node reads the raw data of the required image layer from the image storage structure of its local container runtime, and sends the raw data to the first edge node in the form of a data stream. In practice, upon receiving a request, the source node directly reads the raw data of the required image layer from its local container runtime-managed image storage directory (such as the corresponding layer directory under / var / lib / docker / overlay2 / ). This process involves only disk read operations and does not require writing to any temporary cache files.
[0036] The source node then sends the read image layer data directly to the requesting node in a streaming manner.
[0037] Step 5: The first edge node receives the data stream and directly imports the data stream into its local container runtime. In practice, after receiving the data stream, the requesting node does not write it to the disk cache, but instead pipelines it directly into the local container runtime (e.g., through the Docker Daemon API for layer import), and the container runtime completes the assembly and storage management of the image layer.
[0038] Step 6: After importing the required mirror layer into the first edge node, report the metadata of the mirror layer to the central coordinator.
[0039] In practice, once a requesting node successfully imports a mirror layer, it immediately reports the metadata of the newly added mirror layer to the coordinator, making itself a new source for other nodes to pull from that layer.
[0040] The Docker image p2p distribution method based on cloud phone edge data centers provided in this embodiment, through architectural redesign, systematically solves core pain points such as resource consumption, efficiency fluctuations, and limited compatibility while ensuring functional integrity and reliability. It provides a more efficient, economical, and stable image distribution solution for cloud phone edge data centers and similar large-scale containerization scenarios.
[0041] Based on the above embodiments, the method further includes: If the list of owner nodes returned by the central coordinator is empty, or if pulling the required image layer from all second edge nodes fails, the first edge node will fall back to pulling the required image layer from the central image repository.
[0042] In practice, a rollback mechanism can be set up. If the Peer list returned by the coordinator is empty, or all Peer nodes fail to pull, the requesting node will automatically roll back to pull the image layer from the central image repository.
[0043] The method disclosed herein has been prototyped and its performance tested in a simulated cloud phone edge data center environment. A test cluster including a coordinator and multiple peer nodes was built to simulate a large-scale concurrent image pulling scenario. Test results show that: Functional feasibility: The solution can correctly complete the reporting, discovery, P2P transmission and direct import process of image layer metadata, and integrate normally with the Docker runtime.
[0044] Performance Improvement: With the required mirror layer already existing at the edge nodes, P2P distribution speed is orders of magnitude faster than pulling from a central repository. By avoiding local cache writes, P2P transmission time approaches the theoretical minimum for network transmission on high-speed networks.
[0045] Resource saving: Nodes do not need to reserve cache disks, and system load monitoring shows that the amount of disk write operations is significantly lower than that of traditional P2P caching solutions.
[0046] Hit rate: In the scenario of simulating the periodic deployment of the same version of cloud phone image, as the deployment rounds proceed, the P2P hit rate rises rapidly and stabilizes at an extremely high level, effectively reducing the load on the central warehouse and the pressure on the outbound bandwidth.
[0047] Experiments have proven that the solution is feasible and effective, and can meet the needs of cloud phone edge data centers for fast and efficient distribution of Docker images.
[0048] It should be understood that the various parts of this disclosure can be implemented in hardware, software, firmware, or a combination thereof.
[0049] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure.
[0050] Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.
Claims
1. A method for P2P distribution of Docker images based on cloud mobile phone edge data centers, characterized in that, include: Step 1: Each edge node reports the metadata of its locally stored Docker image layer to the central coordinator; Step 2: When the first edge node needs to pull the target Docker image, it sends a query request to the central coordinator to obtain the list of owner nodes corresponding to each image layer that makes up the target Docker image. Step 3: The first edge node initiates a transmission request for the corresponding required mirror layer to at least one second edge node based on the list of owner nodes. Step 4: In response to the transmission request, the second edge node reads the raw data of the required image layer from the image storage structure of its local container runtime, and sends the raw data to the first edge node in the form of a data stream. Step 5: The first edge node receives the data stream and directly imports the data stream into its local container runtime. Step 6: After importing the required mirror layer into the first edge node, report the metadata of the mirror layer to the central coordinator.
2. The method according to claim 1, characterized in that, Step 1 specifically includes: When an edge node starts up and / or its locally stored Docker image layer changes, it triggers an operation to report metadata to the central coordinator.
3. The method according to claim 1, characterized in that, The central coordinator is used to maintain a global mapping table between mirror layers and edge nodes, and responds to the query request based on the mapping table, returning the network address information of at least one second edge node that has the required mirror layer.
4. The method according to claim 3, characterized in that, Step 3 specifically includes: The first edge node selects at least one second edge node from the owner node list based on preset indicators of each node in the owner node list and initiates a transmission request for the corresponding required mirror layer. The preset indicators include network status, node load, or geographical location.
5. The method according to claim 1, characterized in that, Step 4 specifically includes: The second edge node reads the raw data from the image storage directory of its local container runtime, without writing the raw data to a temporary cache file during the reading process.
6. The method according to claim 1, characterized in that, Step 5 specifically includes: After receiving the data stream, the first edge node does not write it to the local disk cache, but directly pipelines it into the local container runtime, where the container runtime completes the assembly and storage management of the image layer.
7. The method according to claim 1, characterized in that, The method further includes: If the list of owner nodes returned by the central coordinator is empty, or if pulling the required image layer from all second edge nodes fails, the first edge node will fall back to pulling the required image layer from the central image repository.
8. The method according to claim 1, characterized in that, The metadata of the mirror layer includes the mirror layer's summary identifier and size information.
9. The method according to claim 1, characterized in that, The container runtime includes Docker or Containerd.