A layered multi-version extended adaptation container image optimization management method and system

Abstract

The application discloses a layered multi-version extension adaptation container image optimization management method and system, the method comprises the following steps: pulling metadata of a target container image from an image warehouse; obtaining a container image layer set, traversing the container image layers in the container image layer set, searching for a locally stored container image layer for each current container image layer obtained through traversal, and if there is no same or extended and adapted container image layer locally, pulling the current container image layer from the image warehouse; finally, combining and constructing the pulled container image layer and the same or extended and adapted container image layer locally into a complete image of the target container image and storing the complete image. The application aims to solve the combination explosion problem caused by different versions of the layers of the container image, reduce the storage cost of the image warehouse, reduce the data transmission amount in the container image download process between the client and the image warehouse, and improve the container deployment efficiency.

Description

Technical Field

[0001] This invention relates to container technology in the field of operating system virtualization technology, specifically to a layered, multi-version extended adaptation container image optimization management method and system. Background Technology

[0002] Container technology, like virtual machine technology, can isolate applications from the underlying hardware and operating system, allowing for deployment in a stable environment. Container technology also offers advantages such as being more lightweight and efficient. Therefore, container technology, especially Docker, quickly gained attention and was widely adopted. A container image layer is an incremental overlay structure based on a union file system within the container technology ecosystem. When isolating applications from the underlying hardware and operating system using container technology, each application requires a separate container. Given the diversity of applications and the tight binding between applications and their required container image layer versions in current technologies, the container image combinatorial explosion problem arises. This leads to an increase in the number of images that the image repository needs to manage, resulting in high storage overhead. It also increases the amount of data transferred during container image downloads between the client and the image repository, consuming client bandwidth. Furthermore, it causes longer container image download times, leading to low deployment efficiency. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a layered, multi-version extended adaptation container image optimization management method and system to address the above-mentioned problems in the prior art. This invention aims to solve the combinatorial explosion problem caused by different versions of container images at each layer, reduce the storage overhead of the image repository, reduce the amount of data transfer during the container image download process between the client and the image repository, and improve container deployment efficiency.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0005] A layered, multi-version extension-adaptive container image optimization management method includes using a puller to perform the following steps to pull a target container image from an image repository:

[0006] S101, pull the metadata of the target container image from the image repository;

[0007] S102, Parse the metadata to obtain the set of container image layers of the target container image, the replaceable container image layers, and the set of container image layer versions that can be adapted to the replaceable container image layers.

[0008] S103: Traverse the container image layers in the container image layer set. For each current container image layer obtained through traversal, search the locally stored container image layer. If there is no locally stored container image layer that is the same as or matches the set of container image layer versions that can be replaced with the extended adaptation, pull the current container image layer from the image repository. Finally, combine the pulled container image layer with the locally stored container image layer that is the same as or has the extended adaptation to build a complete image of the target container image and store it.

[0009] Optionally, when parsing metadata in step S102, the method further includes: obtaining the matching information structure in the metadata, determining whether the value of the identifier in the matching information structure used to indicate whether multi-version extension adaptation is enabled is a preset value; if it is a preset value, it indicates that multi-version extension adaptation is enabled, and the process jumps to step S103; otherwise, it pulls the complete image of the target container image from the image repository and stores it, then ends and exits.

[0010] Optionally, when parsing metadata in step S102, the replaceable container image layer is recorded in the metadata matching information structure in the form of an integer array; the names of the multiple versions of container image layers that the replaceable container image layer extends and adapts to are recorded in the metadata matching information structure in the form of a two-dimensional character array.

[0011] Optionally, after step S102 and before step S103, the method further includes: determining whether the replaceable container image layer is empty; if the replaceable container image layer is empty, then pulling the complete image of the target container image from the image repository and storing it, ending and exiting; otherwise, jumping to step S103.

[0012] Optionally, step S103 includes:

[0013] S201, initialize the new layer descriptor list newLayers and the local layer summary list digs to be empty, and set the loop variable i to 0;

[0014] S202, iterate through the container image layer set and obtain the i-th container image layer as the current container image layer;

[0015] S203, determine whether the current container image layer is a replaceable container image layer. If it is a replaceable container image layer, proceed to step S204; otherwise, add the current container image layer to the new layer descriptor list newLayers and proceed to step S206.

[0016] S204, Get the set of container image layer versions that are currently adapted to the container image layer extension;

[0017] S205: Iterate through the container image layer version set to obtain a container image layer version as the current container image layer version. Extract the version identifier from the current container image layer version and verify the version identifier. If the version identifier passes the verification, search for the corresponding container image layer summary by the version identifier and add it to the local layer summary list digs. Obtain the descriptor of the current container image layer based on the container image layer summary. The descriptor includes the container image layer summary of the current container image layer and its local file path. Add the descriptor of the current container image layer to the new layer descriptor list newLayers and jump to step S206; otherwise, jump to step S205 to continue iterating.

[0018] S206, increment the loop variable i by 1. If the incremented loop variable i is greater than the size of the container image layer set, then jump to step S207; otherwise, jump to step S202 to continue traversing.

[0019] S207, Determine whether the local layer summary list digs is empty. If the local layer summary list digs is not empty, it means that the container image layer of the target container image consists of the container image layer without extended adaptation and the local container image layer with extended adaptation. Proceed to step S208. Otherwise, it means that the container image layer of the target container image consists entirely of the container image layer without extended adaptation, and there is no container image layer with extended adaptation. Proceed to step S209.

[0020] S208: Obtain the files of the non-replaceable container image layers respectively, and obtain the local file paths of all replaceable container image layers from the new layer descriptor list newLayers. Combine the files of all the obtained container image layers in the correct layer order to build the final image file of the target container image after replacement and store it. Return the identifier of the stored image file, end and exit.

[0021] S209: Obtain the files of the non-replaceable container image layers respectively, combine the files of all the obtained container image layers to build the final image file of the target container image and store it, return the stored file number, end and exit.

[0022] Optionally, when obtaining the files of the non-replaceable container image layers, the process includes first searching for the files of the non-replaceable container image layers locally. If the files of the non-replaceable container image layers are found locally, the files of the non-replaceable container image layers are obtained locally. Otherwise, the files of the non-replaceable container image layers are pulled from the image repository and stored locally.

[0023] Optionally, before step S101, the method further includes pushing the target container image to the image repository using a push program:

[0024] S401, initialize the matching information structure for the target container image;

[0025] S402, Determine whether the target container image needs to enable multi-version extension adaptation. If it does not need to enable multi-version extension adaptation, proceed to step S403; otherwise, proceed to step S404.

[0026] S403, set the value of the flag in the matching information structure that indicates whether multi-version extension adaptation is enabled to a preset value or an empty value that indicates that multi-version extension adaptation is not enabled; set the integer array in the matching information structure that records the replaceable container image layers to empty; set the two-dimensional character array in the matching information structure that records the names of the container image layers of multiple versions of the replaceable container image layer extension adaptation to empty; embed the serialized matching information structure into the newly added matching information field in the image manifest file of the target container image; push the image manifest file of the target container image and the files of each container image layer to the image repository; end and exit.

[0027] S404, Obtain all container image layers and build files of the target container image. The build file is a command sequence consisting of multiple build commands, and each build command corresponds to a container image layer.

[0028] S405, based on the functional type of each build command in the build file, divide the corresponding container image layer into replaceable container image layers and non-replaceable container image layers; for replaceable container image layers, record the identification information of multiple versions that they support for extended adaptation.

[0029] S406, set the value of the identifier in the matching information structure that indicates whether multi-version extension adaptation is enabled to a preset value that indicates multi-version extension adaptation is enabled; set the integer array in the matching information structure that records the replaceable container image layers to the layer index number of the replaceable container image layers; set the two-dimensional character array in the matching information structure that records the names of the container image layers of multiple versions of the replaceable container image layer extension adaptation to the identifier name of the multiple extension adaptation versions supported by each replaceable container image layer; embed the serialized matching information structure into the newly added matching information field in the image manifest file of the target container image; and push the image manifest file of the target container image and the files of each container image layer to the image repository.

[0030] The present invention also provides a layered multi-version extended adaptation container image optimization management system, including a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the layered multi-version extended adaptation container image optimization management method.

[0031] The present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the layered multi-version extension adaptation container image optimization management method by a processor.

[0032] The present invention also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the layered multi-version extension adaptation container image optimization management method via a processor.

[0033] Compared with existing technologies, the present invention mainly achieves the following beneficial effects: The method of the present invention proposes a multi-version extension adaptation scheme for container images. By parsing metadata, it obtains the set of container image layers of the target container image, replaceable container image layers, and the set of container image layer versions for extension adaptation of replaceable container image layers. When pulling an image, if there is no locally available extension-adapted container image layer that matches or is not part of the set of container image layer versions for extension adaptation of replaceable container image layers, the current container image layer is pulled from the image repository. Otherwise, there is no need to download an additional container image layer; the local container image layer is used instead. The set of container image layer versions for extension adaptation of replaceable container image layers greatly expands the extension adaptation range of replaceable container image layers, effectively solving... To address the combinatorial explosion problem inherent in existing technologies where applications and their required container image layer versions are tightly bound, this approach introduces a version range matching mechanism for replaceable container image layers, building upon existing layered storage and exact-match reuse mechanisms. This breaks through the strict cryptographic digest exact-match limitation, allowing container image layers with different digests but equivalent functions to be reused within version compatibility. This maintains the advantages of the OCI layered storage architecture while further expanding the scope and probability of layer reuse, reducing the storage overhead of the image repository and the amount of data transferred during container image downloads between the client and the image repository, thus saving client bandwidth. Furthermore, it reduces the time spent downloading container images, improving container deployment efficiency. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0035] Figure 2 This is a schematic diagram illustrating an application example of the present invention. Detailed Implementation

[0036] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be further described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0037] like Figure 1As shown, the layered multi-version extended adaptation container image optimization management method in this embodiment includes using a pull program to perform the following steps to pull the target container image from the image repository:

[0038] S101, pull the metadata of the target container image from the image repository;

[0039] S102, Parse the metadata to obtain the set of container image layers of the target container image, the replaceable container image layers, and the set of container image layer versions that can be adapted to the replaceable container image layers.

[0040] S103: Traverse the container image layers in the container image layer set. For each current container image layer obtained through traversal, search the locally stored container image layer. If there is no locally stored container image layer that is the same as or matches the set of container image layer versions that can be replaced with the extended adaptation, pull the current container image layer from the image repository. Finally, combine the pulled container image layer with the locally stored container image layer that is the same as or has the extended adaptation to build a complete image of the target container image and store it.

[0041] In step S101 of this embodiment, when pulling the metadata of the target container image from the image repository, the metadata can generally be stored in two locations: one is the RawJSON data file stored with the image, and the other is the image manifest file stored on the image repository. Relatively speaking, because the RawJSON data file is not stored in the source code as a simple and easily understandable deserialized structure, its implementation is more difficult. Therefore, this embodiment uses the manifest file to store the metadata of the target container image; for example... Figure 2 As shown, when a client requests the target container image (MySQL: 6.0) from the image repository, it first pulls the manifest file of the target container image from the image repository.

[0042] Since Docker defines both RawJSON data files and manifest files as being in JSON format, this allows for the possibility of adding fields. Based on this, this embodiment further adds the option to enable or disable multi-version extension adaptation. Specifically, as follows... Figure 1 As shown, in step S102 of this embodiment, when parsing metadata, the method further includes: obtaining the matching information structure in the metadata (manifest file), determining whether the value of the identifier "On" in the matching information structure, which indicates whether multi-version extension adaptation is enabled, is a preset value; if it is a preset value, it indicates that multi-version extension adaptation is enabled, and the process jumps to step S103; otherwise, it pulls the complete image of the target container image from the image repository and stores it, then ends and exits.

[0043] As an optional implementation, in step S102 of this embodiment, when parsing metadata, the replaceable container image layer is recorded in the metadata matching information structure as an integer array; the names of the multiple versions of container image layers that the replaceable container image layer extends and adapts to are recorded in the metadata matching information structure as a two-dimensional character array. In this embodiment, the matching information structure is named MatchInfo, which implements three attributes: the first attribute is named On, the second attribute is named Mlevel, and the third attribute is named Range. The On attribute indicates whether multi-version extension adaptation is enabled; the Mlevel attribute represents the replaceable container image layer; the Mlevel attribute is an array of int type. Because of the layered structure of the image, the rootfs that make up the complete image has a combination order. In the Docker source code, the order of this system is from the bottommost image to the first layer. Thus, an array can be used to record the replaceable image layers in this image. The Range attribute represents the names of the multiple versions of container image layers that the replaceable container image layer extends and adapts to. The `Range` attribute is a two-dimensional array of strings. The implementation corresponds to the range of replaceable image layers stored at each index in `Mlevel`, which is an array of strings retrieved from the same index within the `Range` array. The image name is a special string, and the source code includes functions to convert this string into a container image layer digest reference. Then, through the corresponding function interface, the container image layer digest reference can be used to search for the existence of a file corresponding to that container image layer name locally. The container image layer name is stored in the format NAME:TAG, where NAME represents the container image layer name and TAG is the version identifier. For example... Figure 2 As shown, the manifest file of the target container image (MySQL: 6.0) records that its original image A includes three layers: Layer 1 to Layer 3, namely Ubuntu: 20.04, glibc 5.0, and MySQL 6.0. The attribute Mlevel has a value of [1, 2], indicating that Ubuntu: 20.04 and glibc 5.0 in Layer 1 and Layer 2 are replaceable layers. The set of container image layer versions adapted for Ubuntu: 20.04 extension includes Ubuntu: 20.04 and Ubuntu: 22.04, and the set of container image layer versions adapted for glibc 5.0 extension includes glibc: 5.0, gib: 5.1, and gib: 5.2.

[0044] In this embodiment, the pull process first checks if the metadata contains a field indicating multi-version compatibility is enabled. If so, the corresponding data is retrieved. If not, the unmodified pull process directly downloads the complete image. If enabled, it first identifies which image layers have replaceable version ranges. Then, based on the replaceable ranges of each replaceable image layer in the data, it searches for existing container image layers locally. If a matching container image layer exists locally, it downloads only the missing image layers and builds them into a complete image; otherwise, it downloads the complete image. Finally, the image is stored locally. Figure 2 As shown, since Ubuntu:22.04 already exists on the client's local machine, it is not necessary to pull Ubuntu:22.04 from the image repository. Instead, it is only necessary to pull the missing glibc5.0 and MySQL6.0 container image layers.

[0045] In this embodiment, after step S102 and before step S103, it also includes: determining whether the replaceable container image layer is empty. If the replaceable container image layer is empty, the complete image of the target container image is retrieved from the image repository and stored, and the process ends and exits; otherwise, the process jumps to step S103.

[0046] In this embodiment, step S103 includes:

[0047] S201, initialize the new layer descriptor list newLayers and the local layer summary list digs to be empty, and set the loop variable i to 0;

[0048] S202, iterate through the container image layer set and obtain the i-th container image layer as the current container image layer;

[0049] S203, determine whether the current container image layer is a replaceable container image layer. If it is a replaceable container image layer, proceed to step S204; otherwise, add the current container image layer to the new layer descriptor list newLayers and proceed to step S206.

[0050] S204, Get the set of container image layer versions that are currently adapted to the container image layer extension;

[0051] S205: Iterate through the container image layer version set to obtain a container image layer version as the current container image layer version. Extract the version identifier from the current container image layer version and verify the version identifier (e.g., determine whether the version identifiers of Ubuntu:22.04 and Ubuntu:20.04 are compatible in the preset extended adaptation compatibility list). If the version identifier verification passes, search for the corresponding container image layer summary by the version identifier and add it to the local layer summary list digs. Obtain the descriptor of the current container image layer based on the container image layer summary. The descriptor includes the container image layer summary of the current container image layer and its local file path. Add the descriptor of the current container image layer to the new layer descriptor list newLayers and jump to step S206; otherwise, jump to step S205 to continue iterating.

[0052] The descriptor includes a summary of the current container image layer and its local file path. The local file path can be, for example, a remote URL, a local file URL, or a URL using other custom protocols, as shown in the following example:

[0053] Remote URL: https: / / registry.example.com / v2 / blobs / sha256 / ...;

[0054] Local file URL (the storage location of a local file): file: / / var / lib / containers / storage / ...;

[0055] S206, increment the loop variable i by 1. If the incremented loop variable i is greater than the size of the container image layer set, then jump to step S207; otherwise, jump to step S202 to continue traversing.

[0056] S207, Determine whether the local layer summary list digs is empty. If the local layer summary list digs is not empty, it means that the container image layer of the target container image consists of the container image layer without extended adaptation and the local container image layer with extended adaptation. Proceed to step S208. Otherwise, it means that the container image layer of the target container image consists entirely of the container image layer without extended adaptation, and there is no container image layer with extended adaptation. Proceed to step S209.

[0057] S208: Obtain the files of the non-replaceable container image layers, and retrieve the local file paths of all replaceable container image layers from the new layer descriptor list `newLayers`. Combine the files of all the obtained container image layers in the correct layer order to construct the final image file of the replaced target container image and store it. Return the identifier of the stored image file, end and exit; Figure 2As shown in this embodiment, the Ubuntu:22.04 already existing on the client's local machine is used to pull glibc 5.0 and MySQL 6.0 from the image repository and concatenate them to obtain an image A1 that is compatible with the original image A of the target container image (MySQL:6.0). Since image A1 is compatible with the original image A, it can maximize the use of the local container image layer. On the one hand, it greatly reduces the number of images that the image repository needs to manage, reduces the storage overhead of the image repository, and reduces the amount of data transfer during the container image download process between the client and the image repository, saving client bandwidth. On the other hand, it can also reduce the time spent downloading container images and improve container deployment efficiency.

[0058] S209: Obtain the files of the non-replaceable container image layers respectively, combine the files of all the obtained container image layers to build the final image file of the target container image and store it, return the stored file number, end and exit.

[0059] In this embodiment, when obtaining the files of the non-replaceable container image layer, the process includes first searching for the files of the non-replaceable container image layer locally. If the files of the non-replaceable container image layer are found locally, the files of the non-replaceable container image layer are obtained locally. Otherwise, the files of the non-replaceable container image layer are pulled from the image repository and stored locally. Thus, local priority can also be achieved for the files of the non-replaceable container image layer.

[0060] The data required when pulling an image needs to be transferred to the target repository along with the image when pushing it. Therefore, the image pushing process also needs to be modified: First, it is determined whether multi-version matching needs to be enabled. If it needs to be enabled, the corresponding data is stored in the metadata; otherwise, no data is written. The modification to pushing the image involves using the matching information field newly added to the image manifest file. After pushing the image layer in the previously parsed process and before pushing the image manifest file, the corresponding information for enabling multi-version image adaptation will be written into this matching information structure. Specifically, before step S101 in this embodiment, the process also includes pushing the target container image to the image repository using a push program:

[0061] S401, initialize the matching information structure for the target container image;

[0062] S402, Determine whether the target container image needs to enable multi-version extension adaptation. If it does not need to enable multi-version extension adaptation, proceed to step S403; otherwise, proceed to step S404.

[0063] S403, set the value of the flag in the matching information structure that indicates whether multi-version extension adaptation is enabled to a preset value or an empty value that indicates that multi-version extension adaptation is not enabled; set the integer array in the matching information structure that records the replaceable container image layers to empty; set the two-dimensional character array in the matching information structure that records the names of the container image layers of multiple versions of the replaceable container image layer extension adaptation to empty; embed the serialized matching information structure into the newly added matching information field in the image manifest file of the target container image; push the image manifest file of the target container image and the files of each container image layer to the image repository; end and exit.

[0064] S404, Obtain all container image layers and build files of the target container image. The build file is a command sequence consisting of multiple build commands, and each build command corresponds to a container image layer.

[0065] S405, based on the functional type of each build command in the build file, divide the corresponding container image layer into replaceable container image layers and non-replaceable container image layers; for replaceable container image layers, record the identification information of multiple versions that they support for extended adaptation.

[0066] S406, set the value of the identifier in the matching information structure that indicates whether multi-version extension adaptation is enabled to a preset value that indicates multi-version extension adaptation is enabled; set the integer array in the matching information structure that records the replaceable container image layers to the layer index number of the replaceable container image layers; set the two-dimensional character array in the matching information structure that records the names of the container image layers of multiple versions of the replaceable container image layer extension adaptation to the identifier name of the multiple extension adaptation versions supported by each replaceable container image layer; embed the serialized matching information structure into the newly added matching information field in the image manifest file of the target container image; and push the image manifest file of the target container image and the files of each container image layer to the image repository.

[0067] As an optional implementation, in step S405, when dividing the corresponding container image layer into replaceable and non-replaceable container image layers according to the function type of each build command in the build file, the function type of the build command can be determined by looking up a table first. For example, the content of a certain build command is as follows:

[0068] FROM ubuntu:20.04

[0069] RUN apt-get update&&apt-get install -y python3

[0070] COPY . / app

[0071] RUN pip install -r requirements.txt

[0072] The code snippet shows how to import a container image layer: Ubuntu 20.04 (first line), application commands (second and fourth lines), file copying (third line), Python 3 installation (second line), and Python components listed in the `requirements.txt` file (fourth line). The code then uses a lookup table to determine whether a container image layer is replaceable or non-replaceable based on the build command, its type, the commands within it, and the resource file names. Generally, layers strongly related to the application within the container are non-replaceable, such as the main executable, generated binaries (ELF, JAR, PyC, etc.), and specific runtime versions (e.g., specific Node.js versions). Layers related to general build processes are replaceable, such as common dependency libraries (glibc, openssl, etc.), language runtime packages (Python 3.10 runtime), common resource files (fonts, language packs), common build tools (e.g., `apt install build-essential`), and large model / static data files.

[0073] As another optional implementation, in step S405, when dividing the corresponding container image layer into replaceable and non-replaceable container image layers according to the functional type of each build command in the build file, the corresponding functional type of the build command can be determined by looking up a table first. The build command, the functional type of the build command, the operation command in the build command, and the resource file name in the build command are classified and predicted by a pre-trained machine learning classification model to determine whether the corresponding container image layer is a replaceable or non-replaceable container image layer. The machine learning classification model establishes a mapping relationship between the input (build command, functional type of the build command, operation command in the build command, and resource file name in the build command) and the output (classification result) by pre-selected classification. A fully connected neural network model consisting of an input layer, a hidden layer, and an output layer can be used. The input layer has 4 neurons to input the build command, the functional type of the build command, the operation command in the build command, and the resource file name in the build command. The output layer has one neuron to output the classification result.

[0074] In summary, the method proposed in this embodiment offers a multi-version extension adaptation scheme for container images. Through metadata design and optimization of the pull and push programs, it effectively solves the problem of tightly bound application and required container image layer versions and the combinatorial explosion problem in existing technologies. On the one hand, it enables the image repository to be stored in layers at the granularity of container image layers, greatly reducing the number of images that the image repository needs to manage, reducing the storage overhead of the image repository, and reducing the amount of data transmission during container image download between the client and the image repository, thus saving client bandwidth. On the other hand, it can also reduce the time spent downloading container images and improve container deployment efficiency.

[0075] This embodiment also provides a layered multi-version extended adaptation container image optimization management system, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute the layered multi-version extended adaptation container image optimization management method.

[0076] This embodiment also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the layered multi-version extension adaptation container image optimization management method by a processor.

[0077] This embodiment also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the layered multi-version extension adaptation container image optimization management method via a processor.

[0078] Those skilled in the art will understand that the technical solutions provided by this invention may take the form of a method, system, or computer program product. Therefore, this invention may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this invention may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce an implementation of the flowchart... Figure 1 One or more processes and / or boxes Figure 1The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0079] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principle of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A layered multi-version extended adaptation container image optimization management method, characterized in that, The steps are performed by using a pulling procedure to pull a target container image from an image repository, including: S101, pulling metadata of the target container image from the image repository; S102, parsing the metadata to obtain a container image layer set of the target container image, replaceable container image layers, and a container image layer version set extended and adapted to the replaceable container image layers; S103, traversing the container image layers in the container image layer set, searching for a locally stored container image layer for each current container image layer obtained through the traversal, and pulling the current container image layer from the image repository if there is no same or extended and adapted container image layer matching the container image layer version set extended and adapted to the replaceable container image layers; and finally, combining the pulled container image layers and the same or extended and adapted container image layers locally to construct a complete image of the target container image and storing the complete image; Step S103 includes: S201, initializing a new layer descriptor list newLayers and a local layer digest list digs as empty, and a loop variable i as 0; S202, obtaining an i-th container image layer from the container image layer set as a current container image layer through traversal; S203, judging whether the current container image layer is a replaceable container image layer, and if so, jumping to step S204; otherwise, adding the current container image layer to the new layer descriptor list newLayers and jumping to step S206; S204, obtaining a container image layer version set extended and adapted to the current container image layer; S205, obtaining a container image layer version from the container image layer version set as a current container image layer version through traversal, extracting a version identifier from the current container image layer version, verifying the version identifier, searching for a container image layer digest corresponding to the version identifier through the version identifier if the version identifier passes the verification, adding the container image layer digest to the local layer digest list digs, obtaining a descriptor of the current container image layer according to the container image layer digest, the descriptor including a container image layer digest of the current container image layer and a local file path of the current container image layer, adding the descriptor of the current container image layer to the new layer descriptor list newLayers, and jumping to step S206; otherwise, jumping to step S205 to continue the traversal; S206, increasing the loop variable i by 1, and jumping to step S202 to continue the traversal if the loop variable i after the increase is greater than a size of the container image layer set; otherwise, jumping to step S207; S207, judging whether the local layer digest list digs is empty, and if not, jumping to step S208; otherwise, jumping to step S209; S208, judging whether the target container image is composed of the container image layers not extended and adapted and the locally extended and adapted container image layers, and if so, jumping to step S209; otherwise, jumping to step S210; S209, obtaining a container image layer from the image repository, and jumping to step S202 to continue the traversal; and S210, obtaining a container image layer from the image repository, and jumping to step S202 to continue the traversal. S208: Obtain the files of the non-replaceable container image layers respectively, and obtain the local file paths of all replaceable container image layers from the new layer descriptor list newLayers. Combine the files of all the obtained container image layers in the correct layer order to build the final image file of the target container image after replacement and store it. Return the identifier of the stored image file, end and exit. S209: Obtain the files of the non-replaceable container image layers respectively, combine the files of all the obtained container image layers to build the final image file of the target container image and store it, return the stored file number, end and exit; When obtaining the files of the non-replaceable container image layers, the process includes first searching for the files of the non-replaceable container image layers locally. If the files of the non-replaceable container image layers are found locally, the files of the non-replaceable container image layers are obtained locally. Otherwise, the files of the non-replaceable container image layers are pulled from the image repository and stored locally.

2. The layered multi-version extended adaptation container image optimization management method of claim 1, wherein, In step S102, when parsing metadata, the method further includes: obtaining the matching information structure in the metadata, determining whether the value of the identifier in the matching information structure used to indicate whether multi-version extension adaptation is enabled is a preset value; if it is a preset value, it indicates that multi-version extension adaptation is enabled, and the process jumps to step S103; otherwise, it pulls the complete image of the target container image from the image repository and stores it, then ends and exits.

3. The layered multi-version extension adaptation container image optimization management method of claim 1, wherein, In step S102, when parsing metadata, the replaceable container image layer is recorded in the metadata matching information structure in the form of an integer array; the names of the multiple versions of container image layers that the replaceable container image layer extends and adapts to are recorded in the metadata matching information structure in the form of a two-dimensional character array.

4. The layered multi-version extension adaptation container image optimization management method of claim 1, wherein, The process after step S102 and before step S103 also includes: determining whether the replaceable container image layer is empty; if the replaceable container image layer is empty, then pulling the complete image of the target container image from the image repository and storing it, ending and exiting; otherwise, then jumping to step S103.

5. The layered multi-version extended adaptation container image optimization management method of claim 3, wherein, Before step S101, the process also includes pushing the target container image to the image repository using a push program: S401, initialize the matching information structure for the target container image; S402, determine whether the target container image needs to enable multi-version extension adaptation. If it does not need to enable multi-version extension adaptation, proceed to step S403. Otherwise, proceed to step S404; S403, set the value of the flag in the matching information structure that indicates whether multi-version extension adaptation is enabled to a preset value or an empty value that indicates that multi-version extension adaptation is not enabled; set the integer array in the matching information structure that records the replaceable container image layers to empty; set the two-dimensional character array in the matching information structure that records the names of the container image layers of multiple versions of the replaceable container image layer extension adaptation to empty; embed the serialized matching information structure into the newly added matching information field in the image manifest file of the target container image; push the image manifest file of the target container image and the files of each container image layer to the image repository; end and exit. S404, Obtain all container image layers and build files of the target container image. The build file is a command sequence consisting of multiple build commands, and each build command corresponds to a container image layer. S405, based on the functional type of each build command in the build file, divide the corresponding container image layer into replaceable container image layers and non-replaceable container image layers; for replaceable container image layers, record the identification information of multiple versions that they support for extended adaptation. S406, set the value of the identifier in the matching information structure that indicates whether multi-version extension adaptation is enabled to a preset value that indicates multi-version extension adaptation is enabled; set the integer array in the matching information structure that records the replaceable container image layers to the layer index number of the replaceable container image layers; set the two-dimensional character array in the matching information structure that records the names of the container image layers of multiple versions of the replaceable container image layer extension adaptation to the identifier name of the multiple extension adaptation versions supported by each replaceable container image layer; embed the serialized matching information structure into the newly added matching information field in the image manifest file of the target container image; and push the image manifest file of the target container image and the files of each container image layer to the image repository.

6. A layered multi-version extended adaptation container image optimization management system comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to execute the layered multi-version extension adaptation container image optimization management method according to any one of claims 1 to 5.

7. A computer-readable storage medium having stored therein a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute, via a processor, the layered multi-version extension adaptation container image optimization management method as described in any one of claims 1 to 5.

8. A computer program product comprising computer programs or instructions, characterized in that, The computer program or instructions are programmed or configured to execute, via a processor, the layered multi-version extension adaptation container image optimization management method as described in any one of claims 1 to 5.

Images