Remote mirror image push service system and method based on local containerd process

Abstract

The invention relates to the technical field of containers, in particular to a remote mirror image pushing service system and method based on a local containerd process, by deploying a simulation Docker Registry interface at a mirror image receiving node, a mirror image pushing request of a client side is intercepted, mirror image layer information and mirror image description information are read, and a remote mirror image pushing service system based on the local containerd process is obtained. The mirror image layer information and the mirror image description information are directly injected into the local containerd process, mirror image distribution can be completed without independently deploying a Registry warehouse, a flow link is shortened, intermediate redundant storage is eliminated, the distribution efficiency and the resource utilization rate are improved, and the method is particularly suitable for edge computing and other resource limited scenes.

Description

Technical Field

[0001] This invention relates to the field of container technology, and specifically to a remote image push service system and method based on the local containerd process. Background Technology

[0002] Container images are executable software packages containing applications and their dependencies, and are a core component of containerization technology. Currently, the common distribution process for container images is as follows: First, an image is built in a development or build environment using container image building tools (such as Docker, BuildKit, etc.); second, the image is pushed to a remote image repository using container image push commands (such as docker push); finally, the image is pulled from the remote image repository to the target deployment host for execution using container image pull commands (such as docker pull, ctr pull, etc.).

[0003] Docker Registry is currently the mainstream image repository. Its functions (such as image upload, download, query, and deletion) are all implemented through an HTTP REST interface, and image upload is completed in steps according to the OCI (Open Container Initiative) standard: First, the client uploads image layer blobs and image manifest information to the Registry by sending a PUT request; then, the Registry uses local or remote backend storage (such as local disks, S3, OSS, etc.) to save the image layer information; finally, when the client performs a pull operation, the Registry returns the corresponding image layer information to the client. This approach uses the Registry as a shared image repository, requiring long-term storage of a large number of multi-version, multi-tag images. Its data persistence mechanism is suitable for centralized repository scenarios. When applied to distribution terminals (such as deployment nodes) that only need to "receive and use" images, it has many shortcomings. ① High Deployment Complexity: Traditional Registries require independent deployment of complete services and backend storage systems, involving multiple key aspects such as storage media selection (e.g., local disks, S3), backup strategy configuration, and disaster recovery mechanism setup. In daily operations, continuous monitoring of service status and storage utilization is necessary, along with handling various operations such as scaling, migration, and version upgrades. Furthermore, the Registry service itself consumes CPU and memory resources, while the backend storage requires reserving significant space for storing mirrored data. This resource consumption is particularly problematic in resource-constrained scenarios such as edge nodes, where redundancy is a significant issue. ② Long Image Distribution Chain: Image distribution employs a two-stage process: "client → Registry → target host." When the client uploads the image, it must sequentially go through network transmission, data verification, and storage writing. When the target host pulls the image, it must repeat the network transmission, data verification, and local storage steps. This overlapping chain directly leads to increased distribution latency. In cross-datacenter or weak network environments, it is also prone to transmission interruptions and retry issues due to network fluctuations. In multi-node deployment scenarios, since each node needs to pull the image independently, latency accumulates as the number of nodes increases, severely impacting overall deployment efficiency. ③ Intermediate state redundant storage: The Registry needs to persistently store the image layer and description files, but in a pure transport scenario, these data only serve as a transit point. Once the target host has finished pulling the data, they lose their practical value. When the image is frequently updated, if the old version data is not cleaned up in time, disk space will be quickly occupied. At the same time, the process of writing and reading this transitional data will continuously consume IO bandwidth, which not only wastes disk resources but also causes storage performance degradation. ④ Inability to directly collaborate with local containerd: The Registry cannot directly write images to containerd or other container runtimes. Therefore, the target host must perform a secondary pull operation. This results in the same batch of image data undergoing two complete transfers: "client → Registry" and "Registry → target host." Even in a local node environment, there is a data copying process between storage locations. In addition, the data must undergo dual verification and format conversion by both the Registry and the runtime, which undoubtedly wastes network bandwidth, I / O resources, and CPU computing power.

[0004] Therefore, how to provide an optimized container image distribution solution that simplifies the deployment architecture, improves distribution efficiency, and reduces resource consumption to address the aforementioned problems of traditional Registry in the container image distribution process has become an urgent problem for those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a remote image push service system and method based on a local containerd process. By deploying a simulated Docker Registry interface on the image receiving node, the system intercepts client image push requests and reads image layer information and image description information. The image layer information and image description information are then directly injected into the local containerd process. This enables image distribution without the need for a separate Registry repository, shortens the distribution chain, eliminates redundant intermediate storage, and improves distribution efficiency and resource utilization. It is particularly suitable for resource-constrained scenarios such as edge computing.

[0006] The objective of this invention is achieved through the following approach: A remote image push service system based on a local containerd process includes an interface simulation module, a data processing module, a container runtime writing module, and a response generation module. The data input terminal of the interface simulation module serves as the data input terminal of the remote image push service system. The data output terminal of the interface simulation module is connected to the data input terminal of the data processing module. The data output terminal of the data processing module is connected to the data input terminal of the container runtime writing module. The data output terminal of the container runtime writing module is connected to the data input terminal of the response generation module. The data output terminal of the response generation module serves as the data output terminal of the remote image push service system. The interface simulation module is used to simulate the Docker Registry interface, accept image push requests sent by the client, and obtain image layer information and image description information uploaded by the client. The data processing module is used to read the image layer information and image description information, as well as to perform integrity verification; The container runtime writing module is used to inject the image layer information and image description information, which have been parsed and processed by the data processing module, into the local containerd content storage, and to build a local image reference; The response generation module is used to generate response information that conforms to the Docker Registry protocol specification, including uploading UUID, Location and status code, and return it to the client so that the client thinks it has been pushed to the standard Registry.

[0007] Preferably, the Docker Registry interface includes / v2 / and / v2 / <name> / blobs / uploads / 、 / v2 / <name> / manifests / .

[0008] A method for remote image pushing based on a local containerd process includes the following steps: 1) Build a local containerd process on the server side, and build a remote image push service system based on the local containerd process. The remote image push service system includes an interface simulation module, a data processing module, a container runtime writing module, and a response generation module. 2) Intercept the client's image push request using the interface simulation module, and obtain the image layer information and image description information uploaded by the client; 3) The data processing module is used to parse and verify the image layer information and image description information; 4) Utilize the container runtime writing module to inject image layer information and image description information into the local containerd process on the server and generate operation results; 5) Based on the Docker Registry protocol specifications and operation results, use the response generation module to generate a standardized response and return it to the client.

[0009] Preferably, in step 2), the step of intercepting the client's image push request using the interface simulation module and obtaining the image layer information and image description information uploaded by the client specifically includes: 2-1) Use the interface simulation module to simulate the Docker Registry interface to listen for client image upload requests; 2-2) Use the interface simulation module to intercept the POST request uploaded by the client's image layer, generate a unique identifier UUID and the URL path of the data uploaded by the client, and return it to the client; 2-3) Use the interface simulation module to intercept the PUT request uploaded by the client's image layer, and read the image layer information from the request body of the PUT request; 2-4) Use the interface simulation module to intercept the PUT request that the client uploads image description information, and read the image description information from the request body of the PUT request.

[0010] Preferably, in step 3), the data processing module is used to parse and verify the image layer information and image description information, specifically including: 3-1) Use the data processing module to write the image layer information into the local containerd content storage, and verify the data integrity of the image layer information according to the digest. 3-2) Use the data processing module to parse the hierarchical metadata and configuration metadata in the image description information, and verify the format of the image description information in accordance with the OCI specification; 3-3) Construct a local image reference based on the hierarchical meta-information in the image description information.

[0011] Preferably, the interface simulation module is used to simulate the Docker Registry interface, accept image push requests sent by the client, and obtain image layer information and image description information uploaded by the client; The data processing module is used to read the image layer information and image description information, as well as to perform integrity verification; The container runtime writing module is used to inject the image layer information and image description information, which have been parsed and processed by the data processing module, into the local containerd content storage, and to build a local image reference; The response generation module is used to generate response information that conforms to the Docker Registry protocol specification, including uploading UUID, Location and status code, and return it to the client so that the client thinks it has been pushed to the standard Registry.

[0012] Preferably, in the process of intercepting the client's image push request using the interface simulation module, a permission and verification process is also involved, which is used to authenticate the client and verify the request, as well as to whitelist the image tags.

[0013] The beneficial effects of this invention are as follows: A remote image push service system based on a local containerd process includes an interface simulation module, a data processing module, a container runtime writing module, and a response generation module. The data input terminal of the interface simulation module serves as the data input terminal of the remote image push service system. The data output terminal of the interface simulation module is connected to the data input terminal of the data processing module. The data output terminal of the data processing module is connected to the data input terminal of the container runtime writing module. The data output terminal of the container runtime writing module is connected to the data input terminal of the response generation module. The data output terminal of the response generation module serves as the data output terminal of the remote image push service system. The interface simulation module is used to simulate the Docker Registry interface, accept image push requests sent by the client, and obtain image layer information and image description information uploaded by the client. The data processing module is used to read the image layer information and image description information, as well as to perform integrity verification; The container runtime writing module is used to inject the image layer information and image description information, which have been parsed and processed by the data processing module, into the local containerd content storage, and to build a local image reference; The response generation module is used to generate response information that conforms to the Docker Registry protocol specification, including uploading UUID, Location and status code, and return it to the client so that the client thinks it has been pushed to the standard Registry.

[0014] This invention employs an interface simulation module compatible with the standard Docker Registry interface, allowing clients to directly push images using commands like `docker push` without modifying the toolchain, thus reducing user costs. A data processing module reads and verifies the integrity of image layers and description information, ensuring accurate data transmission and preventing the injection of invalid or corrupted data. A container runtime writing module directly injects the processed data into the local containerd content storage and builds image references, bypassing intermediate Registry storage and achieving "ready to use upon receipt," reducing distribution latency and storage redundancy. Finally, a response generation module returns a protocol-compliant response, misleading clients into believing the image has been pushed to a standard Registry, ensuring process compliance. The overall architecture is lightweight and efficient, eliminating the need for a complete Registry deployment, saving resources, and adapting to edge node scenarios. Furthermore, modular division of labor strengthens security control, unifies image management entry points, and improves distribution efficiency and ease of maintenance.

[0015] Preferably, the Docker Registry interface includes / v2 / and / v2 / <name> / blobs / uploads / 、 / v2 / <name> / manifests / .

[0016] / v2 / is the base path for the Registry service, used by clients to verify service availability (such as protocol version negotiation); / v2 / <name> / blobs / uploads / is responsible for the upload process of image layers (blobs) (including initial upload, data transfer, checksum verification, etc.); / v2 / <name>` / manifests / ` is used to upload image description files (manifests), defining the image's hierarchical structure, configuration information, and other metadata. This invention simulates ` / v2 / ` and ` / v2 / `. <name> / blobs / uploads / 、 / v2 / <name>The / manifests / interface can intercept and process the entire process of image push, allowing users to push images to the server directly using existing tools without modifying any push commands or configurations. It also completes all necessary steps (such as digest verification and data fragmentation transmission) according to standard protocols, ultimately achieving complete reception and injection of the image layer and metadata, greatly reducing the user's usage cost.

[0017] A method for remote image pushing based on a local containerd process includes the following steps: 1) Build a local containerd process on the server side, and build a remote image push service system based on the local containerd process. The remote image push service system includes an interface simulation module, a data processing module, a container runtime writing module, and a response generation module. 2) Intercept the client's image push request using the interface simulation module, and obtain the image layer information and image description information uploaded by the client; 3) The data processing module is used to parse and verify the image layer information and image description information; 4) Utilize the container runtime writing module to inject image layer information and image description information into the local containerd process on the server and generate operation results; 5) Based on the Docker Registry protocol specifications and operation results, use the response generation module to generate a standardized response and return it to the client.

[0018] This invention intercepts client push requests by simulating the standard Docker Registry interface, processes image layer information and image description information in real time, and directly injects them into the local containerd. At the protocol layer, it "deceives" the client into thinking that the request is being pushed to the standard Registry. This achieves the goal of eliminating the need to deploy a complete Registry image repository and its backend storage system. At the same time, it eliminates the need for the Registry to persistently store intermediate format data of the image, avoiding the storage of intermediate format data such as image layers and description files. This results in significant savings in storage space and reduces the operational costs and burdens of repository deployment, storage management, and other maintenance.

[0019] Preferably, in step 2), the step of intercepting the client's image push request using the interface simulation module and obtaining the image layer information and image description information uploaded by the client specifically includes: 2-1) Use the interface simulation module to simulate the Docker Registry interface to listen for client image upload requests, ensuring that clients (such as docker push) can smoothly initiate requests according to the original logic, achieving seamless compatibility with the existing toolchain without requiring clients to adjust their operation methods; 2-2) Intercept the POST request uploaded by the client's image layer using the interface simulation module, generate a unique identifier UUID and the URL path of the data uploaded by the client, and return it to the client. Accurately follow the upload session management mechanism of the Registry protocol to ensure the compliance of the interaction between the client and the server and avoid upload interruption due to protocol mismatch. 2-3) Use the interface simulation module to intercept the PUT request uploaded by the client's image layer, and read the image layer information from the request body of the PUT request; 2-4) Use the interface simulation module to intercept the PUT request that the client uploads image description information, and read the image description information from the request body of the PUT request.

[0020] This invention intercepts PUT requests for image layers and image description information in stages and reads the data, enabling real-time acquisition and processing of image data. This lays the foundation for subsequent direct injection into containerd, supporting the core advantage of "skipping intermediate storage and end-to-end direct access," while ensuring complete data reception and process controllability, thus improving image distribution efficiency and reliability.

[0021] Preferably, in the process of intercepting the client's image push request using the interface simulation module, a permission and verification process is also involved to authenticate the client and verify the request, so as to prevent illegal image uploads and to whitelist the image tags to prevent overwriting of critical images.

[0022] The advantages of this invention are as follows: ① This invention eliminates the need to deploy a complete Registry image repository and its backend storage system, avoiding the storage of intermediate format data such as image layers (blobs) and description files (manifests), significantly saving storage space, and reducing the operation and maintenance costs and burdens of repository deployment and storage management; ② This invention skips the Registry storage step and directly injects the image data into the local containerd content storage, eliminating the traditional two-stage flow link of "pushing to the repository and then pulling", achieving zero-copy and low-latency image import. In a local area network environment, the injection time is only less than 60% of the traditional solution. ③ This invention strictly simulates the behavior of the Docker Registry interface and supports standard push commands such as docker push and ctr imagespush. Users can seamlessly replace the traditional Registry without modifying the client operation process, reducing the threshold for migration and use. ④ The service resource consumption of this invention is extremely low (only 10MB of memory), does not rely on complex backend storage, is suitable for resource-constrained scenarios such as edge computing nodes and CI / CD build nodes, and supports rapid deployment and expansion through systemd or Kubernetes sidecar mode; ⑤ This invention simplifies the system hierarchy by integrating the remote image upload entry with the local containerd storage, enabling end-to-end image distribution and significantly shortening node readiness time in scenarios such as cloud-native cluster initialization and edge node deployment.

[0023] Definitions: A container image is a lightweight, executable, standalone software package that encapsulates everything needed to run a specific application, including code, runtime environment, system tools, libraries, environment variables, and configuration files. The distribution and deployment of container images is a crucial aspect of cloud-native architectures.

[0024] Container image distribution refers to the process of transferring a built container image from a local or source repository to a target environment (such as a development, testing, or production server).

[0025] Container image deployment refers to the process of creating and running a container instance based on an image pulled to the local machine, making it an application that can provide services to the outside world.

[0026] Docker Registry is an open-source server-side application for storing and distributing Docker images. It allows users to upload, store, manage, and download Docker images and is a core component of the Docker ecosystem for image distribution and version control. Docker is an open-source containerization platform that allows developers to package applications and their dependencies (such as libraries and configuration files) into standardized containers, achieving the goal of "build once, run anywhere." In this invention, "Registry" refers to a repository service for storing container images.

[0027] Injection: In this invention, "injection" refers to the process of directly writing the image data (including image layer information and image description information) pushed by the client into the content storage system of the local containerd process on the server through technical means, and completing the registration of image metadata.

[0028] digest: refers to the hash digest of the mirror data (including mirror layer information, mirror description information, etc.), which is a unique identifier string obtained by calculating the data through a hash algorithm.

[0029] UUID: Universally Unique Identifier, is a string used to uniquely identify an image layer upload session.

[0030] Location: is the image layer upload session identifier defined in the Docker Registry v2 protocol, and its value is a relative URL path containing the UUID (such as / v2 / imagename / blobs / uploads / UUID). Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of the technical architecture for container image push in an embodiment of the present invention. Detailed Implementation

[0032] like Figures 1 to 2 As shown, a remote image push method based on the local containerd process includes the following steps: 1) Build a local containerd process on the server side, and build a remote image push service system based on the local containerd process. The remote image push service system includes an interface simulation module, a data processing module, a container runtime writing module, and a response generation module. 2) Intercept the client's image push request using the interface simulation module, and obtain the image layer information and image description information uploaded by the client; 3) The data processing module is used to parse and verify the image layer information and image description information; 4) Utilize the container runtime writing module to inject image layer information and image description information into the local containerd process on the server and generate operation results; 5) Based on the Docker Registry protocol specifications and operation results, use the response generation module to generate a standardized response and return it to the client.

[0033] The following is an example of implementing the above method: 1) Use Ubuntu 22.04 LTS or any Linux distribution that supports systemd as the server operating system, and install containerd version v1.7.0 or higher on the operating system with " / run / containerd / containerd.sock" as the installation path. Create a local containerd process on the server, and based on the containerd process, use Go 1.20+ (the Go software development kit (SDK) provided by containerd) to build a remote image push service system based on the local containerd process. This system listens for image receiving services at https: / / <service IP>:5000, and clients can push images using the following commands: Docker tag myapp:latest<service IP>:5000 / myapp:latest docker push<service IP>:5000 / myapp:latest In this embodiment, the remote image push service system includes an interface simulation module, a data processing module, a container runtime writing module, and a response generation module. The data input terminal of the interface simulation module is the data input terminal of the remote image push service system, and the data output terminal of the interface simulation module is connected to the data input terminal of the data processing module. The data output terminal of the data processing module is connected to the data input terminal of the container runtime writing module, and the data output terminal of the container runtime writing module is connected to the data input terminal of the response generation module. The data output terminal of the response generation module is the data output terminal of the remote image push service system. The interface simulation module is used to simulate the Docker Registry interface, which includes / v2 / and / v2 / . <name> / blobs / uploads / 、 / v2 / <name>The ` / manifests / ` directive accepts image push / upload requests from clients and retrieves image layer information (blobs) and image description information (manifests) uploaded by the clients. The data processing module is used to read the image layer information and image description information, as well as to perform integrity verification; The container runtime writing module is used to inject the image layer information and image description information, which have been parsed and processed by the data processing module, into the local containerd content store through the containerd public SDK or gRPC interface, and to build a local image reference through the containerd imageservice.Create() interface; The response generation module is used to generate response information that conforms to the Docker Registry protocol specification, including uploading UUID, Location and status code, and return it to the client so that the client thinks it has been pushed to the standard Registry.

[0034] In this embodiment, the interface simulation module, data processing module, container runtime writing module, and response generation module are sequentially connected to form a complete image push processing flow. The connection relationship of each module is as follows: a. Interface Simulation Module → Data Processing Module The interface simulation module is the "entry point" of the entire process. It is responsible for listening to and intercepting image push requests sent by clients (including image layer information uploads, image description information uploads, etc.). After intercepting the request, the interface simulation module will pass the core data in the request (such as image layer binary data, manifest JSON content, request path parameters, etc.) to the data processing module, triggering subsequent parsing operations.

[0035] b. Data processing module → Container runtime write module After parsing (such as extracting the digest of the image layer and parsing the hierarchical relationship in the manifest) and verifying (such as verifying data integrity) the received data, the data processing module passes the processed structured data (such as image layer information and manifest metadata that conform to the OCI standard) to the container runtime write module, which then performs the actual local storage write operation.

[0036] c. Container runtime write module → response generation module After the container runtime write module completes the writing of data to the containerd content storage (such as injecting the image layer through the SDK interface and creating an image reference), it will feed back the operation results (such as the write success / failure status, the generated digest, etc.) to the response generation module as the basis for building the client response.

[0037] d. Response generation module → Client The response generation module generates a standardized response (such as status code, Location header, UUID, etc.) according to the Docker Registry protocol specification based on the feedback from the container runtime writing module. It then returns the response to the client through the HTTP service of the interface simulation module, ensuring that the client believes that the push process conforms to the interaction logic of the standard image repository.

[0038] In short, the interface simulation module, data processing module, container runtime writing module, and response generation module are sequentially connected in the order of "request interception → data parsing → local writing → response feedback" to form a closed loop: the interface simulation module is responsible for "accessing" requests, the data processing module is responsible for "parsing" data, the container runtime writing module is responsible for "landing" data, and the response generation module is responsible for "closing" the interaction, together realizing the complete processing of the image push process.

[0039] 2) Intercept the client's image push request using the interface simulation module, and obtain the image layer information and image description information uploaded by the client, specifically including: 2-1) Use the interface simulation module to simulate the Docker Registry interface to listen for client image upload requests; 2-2) Use the interface simulation module to intercept the POST request uploaded by the client's image layer, generate a unique identifier UUID to identify this upload session and the URL path of the data uploaded by the client, and return it to the client; 2-3) Use the interface simulation module to intercept the PUT request uploaded by the client's image layer, and read the image layer information from the request body of the PUT request; 2-4) Use the interface simulation module to intercept the PUT request that the client uploads image description information, and read the image description information from the request body of the PUT request.

[0040] In this embodiment, the reference code for simulating the Registry interface service logic is as follows: Initialize main.go (simplified version): func main() { r := http.NewServeMux() r.HandleFunc(" / v2 / ", handleV2Root) r.HandleFunc(" / v2 / ", registryHandler) log.Println("starting mock registry at :5000") log.Fatal(http.ListenAndServe(":5000", r)) } It is worth noting that in this embodiment, during the process of intercepting the client's image push request using the interface simulation module, a permission and verification process is also involved to perform user authentication and request verification on the client. By binding the local containerd interface, mechanisms such as user authentication (e.g., Basic Auth, JWT) and image tag whitelist are integrated to accurately intercept illegal image uploads and to whitelist and restrict image tags to prevent overwriting of critical images, thereby enhancing the security and controllability of the image import process.

[0041] 3) The data processing module is used to parse and verify the image layer information and image description information, specifically including: 3-1) Use the data processing module to write the image layer information into the local containerd content storage, and verify the data integrity of the image layer information according to the digest. In this embodiment, the principle of verifying data integrity through the digest is as follows: During the image push process, the client generates a digest based on local data and transmits it with the request. After receiving the data, the server recalculates the digest. By comparing whether the two are consistent, it ensures that the image layer or description information has not been tampered with or damaged during transmission. This is a key verification mechanism to ensure the accurate transmission of image data.

[0042] It is worth noting that if the image layer information (blob) is large, the received image data can be temporarily stored in memory or a temporary directory. After the data integrity is verified (i.e., the data is confirmed to be undamaged by digest comparison), the verified complete data can be injected into the containerd content storage. This avoids the problem of untimely verification that may occur during direct streaming processing, reduces containerd write failures caused by data transmission interruption or corruption, reduces the instantaneous pressure on system memory from direct processing of large files, and improves the stability in large image push scenarios.

[0043] 3-2) Use the data processing module to parse the hierarchical metadata and configuration metadata in the image description information, and verify the format of the image description information in accordance with the OCI specification; 3-3) Construct a local image reference based on the hierarchical meta-information in the image description information.

[0044] It is worth noting that in step 3-3), if the image layer information (blob) referenced in the image description information (manifest) has already been written into containerd through step 3-2), then step 3-3) will no longer build the image reference and will directly jump to the next step to perform image injection.

[0045] In this embodiment, the reference code for the image layer information upload process is as follows: func handleUpload(w http.ResponseWriter, r *http.Request) { if r.Method == "POST" { / / Initialize upload, return UUID uuid := generateUUID() w.Header().Set("Location", " / v2 / "+imageName+" / blobs / uploads / "+uuid) w.Header().Set("Docker-Upload-UUID", uuid) w.WriteHeader(http.StatusAccepted) } else if r.Method == "PUT" { / / Read the complete blob and write it to containerd data, _ := io.ReadAll(r.Body) digest := r.URL.Query().Get("digest") ctx := context.Background() client, _ := containerd.New(" / run / containerd / containerd.sock") defer client.Close() writer, _ := client.ContentStore().Writer(ctx, content.WithRef("upload-"+digest)) io.Copy(writer, bytes.NewReader(data)) writer.Commit(ctx, int64(len(data)), digest) w.WriteHeader(http.StatusCreated) } } In this embodiment, the upload process for the image details manifest is shown in the following code: func handleManifest(w http.ResponseWriter, r *http.Request) { if r.Method != "PUT" { w.WriteHeader(http.StatusMethodNotAllowed) return } ctx := context.Background() client, _ := containerd.New(" / run / containerd / containerd.sock") defer client.Close() manifestData, _ := io.ReadAll(r.Body) desc := ocispec.Descriptor{ MediaType: images.MediaTypeDockerSchema2Manifest, Digest: digest.FromBytes(manifestData), Size: int64(len(manifestData)), } / / Write the manifest to the content store contentStore := client.ContentStore() writer, _ := contentStore.Writer(ctx, content.WithRef("manifest-"+desc.Digest.String())) io.Copy(writer, bytes.NewReader(manifestData)) writer.Commit(ctx, desc.Size, desc.Digest) / / Register the image client.ImageService().Create(ctx, images.Image{ Name: " <image-name> : <tag>", Target: desc, }) w.WriteHeader(http.StatusCreated) } 4) Utilize the container runtime writing module to inject image layer information and image description information into the local containerd process on the server and generate operation results; 5) Based on the Docker Registry protocol specifications and operation results, use the response generation module to generate a standardized response and return it to the client.

[0046] After deploying the remote image push service system as described above and using this system as the server, the client's (which can be another Docker host) operation process is as follows: (1) Configure the service node (i.e., the server) as a Docker insecure registry Add "insecure-registries": ["<service IP>:5000"] to the client's ` / etc / docker / daemon.json` file. This tells Docker that the service node is a "trusted unencrypted repository," allowing clients to communicate with it via HTTP (or unverified HTTPS), thus preventing push notifications from being rejected due to certificate issues. See the example code below: / / / etc / docker / daemon.json { "insecure-registries": ["<service IP>:5000"] } (2) Restart the Docker daemon process to make the modified Docker daemon configuration (such as updating daemon.json) take effect, that is, to load the "insecure registry" configuration so that the client can interact with the server according to the new rules.

[0047] (3) Build and push the test image: ① Build a test image (such as an application image named myapp:latest) locally on the client side as the data source for push notifications. See the following code for reference: docker build -t myapp:latest ② Add a tag to the local image that conforms to the server path rules. When pushing an image to Docker, the repository address must be specified. The tag format is <service IP>:5000 / myapp:latest, where <service IP>:5000 is the address of the service, and myapp:latest is the image's identifier on the server. Ensure that the client sends requests to the target service according to the standard Registry protocol. See the following code for reference: Docker tag myapp:latest<service IP>:5000 / myapp:latest ③ Triggering the image push process, the client sends image layer (blobs) and manifest (manifest) requests to the server according to the Docker Registry v2 protocol, verifying whether the server can correctly intercept, process, and inject the local containerd. See the following code for reference: docker push<service IP>:5000 / myapp:latest (4) Server log observation and local mirror query The local image list is queried using the containerd command-line tool `ctr` to verify whether the pushed `myapp:latest` has been successfully injected into the containerd content storage on the server. The core purpose is to confirm the effectiveness of the function of "writing images directly to the local runtime without a transit repository" (i.e., verifying whether the service can normally intercept requests and process data, and confirming that there are no errors). The reference code is as follows: ctr -n default images list After successfully pushing the image to the server using the above method, the image can be loaded directly from the local containerd content storage without needing to be pulled from the repository via `docker pull` or `ctr pull`. The server's containerd can then directly use this image to run containers. See the following code for reference: ctr run -t --rm<service IP>:5000 / myapp:latest test-instance In this embodiment, the image push performance between the client and the constructed remote image push service system based on local containerd is as follows: ① The average upload size of Blob test data (compressed mirror layer) is 12~150MB; In other words, the remote image push service system can reliably handle image layer data of a normal size (12MB to 150MB after compression), covering the layering requirements of most application images and having high compatibility with typical scenarios.

[0048] ② Throughput performance: Under local area network conditions, the image injection time does not exceed 60% of the original Registry push + pull solution; In other words, compared with the traditional two-stage process of "pushing to the Registry + pulling from the target node", this invention, by skipping intermediate storage and directly writing to containerd, compresses the image distribution time to less than 60% of the original solution, and has the advantages of "zero transfer and low latency".

[0049] ③ System usage: Memory usage is only 10MB, disk usage increases slightly with the size of the received image, and there are no duplicate intermediate files.

[0050] In other words, the remote image push service system built in this embodiment only uses 10MB of memory, which is lower than a full Registry service (which typically requires hundreds of MB of memory). It has high lightweight characteristics and is suitable for resource-constrained scenarios such as edge nodes and CI / CD build machines. In addition, traditional Registries store intermediate files (such as the blobs directory) between the image layer and the manifest, while this embodiment directly writes the data to the content storage of containerd, without additional redundant storage. The disk usage comes only from the image itself, which can greatly save storage space.

[0051] It is worth noting that the remote image push service system constructed in this embodiment supports systemd unit startup and boot startup. It can refer to the standardized service deployment method in the Linux system. The specific steps are as follows: by writing the service file / etc / systemd / system / containerd-injector.service, the remote image push service system is registered as a system service managed by systemd to support systemctl start / stop control, and then the enable setting is used to achieve automatic boot startup.

[0052] The remote image push service system constructed in this embodiment also supports Kubernetes sidecar mode deployment. The specific steps are as follows: In the Kubernetes cluster, the remote image push service system is used as a "sidecar container" and deployed in the same Pod as the application container, providing local image receiving capabilities for nodes within the cluster. This is suitable for CI / CD build nodes (directly receiving built images) or edge cluster nodes (quickly importing images), extending the system's applicability in cloud-native environments.

[0053] It is worth noting that the write operations to containerd in this embodiment rely on its officially released Go SDK (such as client.ContentStore().Writer(), imageservice.Create()) and standard interfaces, without using private APIs or hacks. This ensures that when the containerd version is upgraded (such as from v1.7.x to a higher version), the service can remain compatible without significant modifications, guaranteeing the long-term maintainability of the system.

[0054] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications made to the present invention by those skilled in the art without departing from the spirit of the present invention shall fall within the protection scope of the present invention.< / tag> < / image-name> < / name> < / name> < / name> < / name> < / name> < / name> < / name> < / name> < / name> < / name>

Claims

1. A remote image push service system based on a local containerd process, characterized in that, The system includes an interface simulation module, a data processing module, a container runtime writing module, and a response generation module. The data input terminal of the interface simulation module is connected to the data input terminal of the remote image push service system. The data output terminal of the interface simulation module is connected to the data input terminal of the data processing module. The data output terminal of the data processing module is connected to the data input terminal of the container runtime writing module. The data output terminal of the container runtime writing module is connected to the data input terminal of the response generation module. The data output terminal of the response generation module is the data output terminal of the remote image push service system. The interface simulation module is used to simulate the Docker Registry interface, accept image push requests sent by the client, and obtain image layer information and image description information uploaded by the client. The data processing module is used to read the image layer information and image description information, as well as to perform integrity verification; The container runtime writing module is used to inject the image layer information and image description information, which have been parsed and processed by the data processing module, into the local containerd content storage, and to build a local image reference; The response generation module is used to generate response information that conforms to the Docker Registry protocol specification, including uploading UUID, Location and status code, and return it to the client so that the client thinks it has been pushed to the standard Registry.

2. The remote mirror push service system according to claim 1, characterized in that: The Docker Registry interface includes / v2 / and / v2 / <name> / blobs / uploads / 、 / v2 / <name> / manifests / .< / name> < / name> 3. A method for remote image pushing based on a local containerd process, characterized in that, Includes the following steps: 1) Build a local containerd process on the server side, and build a remote image push service system based on the local containerd process. The remote image push service system includes an interface simulation module, a data processing module, a container runtime writing module, and a response generation module. 2) Intercept the client's image push request using the interface simulation module, and obtain the image layer information and image description information uploaded by the client; 3) The data processing module is used to parse and verify the image layer information and image description information; 4) Utilize the container runtime writing module to inject image layer information and image description information into the local containerd process on the server and generate operation results; 5) Based on the Docker Registry protocol specifications and operation results, use the response generation module to generate a standardized response and return it to the client.

4. The remote mirror push method according to claim 3, characterized in that: In step 2), the step of intercepting the client's image push request using the interface simulation module and obtaining the image layer information and image description information uploaded by the client specifically includes: 2-1) Use the interface simulation module to simulate the Docker Registry interface to listen for client image upload requests; 2-2) Use the interface simulation module to intercept the POST request uploaded by the client's image layer, generate a unique identifier UUID and the URL path of the data uploaded by the client, and return it to the client; 2-3) Use the interface simulation module to intercept the PUT request uploaded by the client's image layer, and read the image layer information from the request body of the PUT request; 2-4) Use the interface simulation module to intercept the PUT request that the client uploads image description information, and read the image description information from the request body of the PUT request.

5. The remote mirror push method according to claim 3, characterized in that: Step 3) utilizes the data processing module to parse and verify the image layer information and image description information, specifically including: 3-1) Use the data processing module to write the image layer information into the local containerd content storage, and verify the data integrity of the image layer information according to the digest. 3-2) Use the data processing module to parse the hierarchical metadata and configuration metadata in the image description information, and verify the format of the image description information in accordance with the OCI specification; 3-3) Construct a local image reference based on the hierarchical meta-information in the image description information.

6. The remote mirror push method according to claim 3, characterized in that: The interface simulation module is used to simulate the Docker Registry interface, accept image push requests sent by the client, and obtain image layer information and image description information uploaded by the client. The data processing module is used to read the image layer information and image description information, as well as to perform integrity verification; The container runtime writing module is used to inject the image layer information and image description information, which have been parsed and processed by the data processing module, into the local containerd content storage, and to build a local image reference; The response generation module is used to generate response information that conforms to the Docker Registry protocol specification, including uploading UUID, Location and status code, and return it to the client so that the client thinks it has been pushed to the standard Registry.

7. The remote mirror push method according to claim 3, characterized in that: In the process of intercepting the client's image push request using the interface simulation module, a permission verification process is also involved, which is used to authenticate the client and verify the request, as well as to whitelist the image tags.

Images