Mirror image updating method and related device

Abstract

The embodiment of the invention provides a mirror image updating method and a related device. The method comprises the following steps: determining a second mirror image of a historical version corresponding to a first mirror image; the middle-layer information of the metadata of a plurality of third mirror images comprises a target mirror image of the description information of the second mirror image, and the level of the second mirror image is lower than that of the third mirror image; the description information about the second mirror image in the metadata of the target mirror image is replaced with the description information of the first mirror image to obtain new metadata after the target mirror image is updated, and the target mirror image after the metadata is updated is used for instantiating the application container. By adopting the embodiment of the invention, the updating of the upper mirror image can be quickly completed under the condition that the lower mirror image is changed, and the efficiency of reconstructing the mirror image is improved.

Description

Technical Field

[0001] This application relates to the field of cloud native technologies, and in particular, to a method for updating an image and related devices. Background Art

[0002] Docker is an open-source cloud project implemented in the GO language. The main goal of Docker is to "build, ship, and run any application anywhere", that is, to manage the life cycle of application encapsulation, distribution, deployment, and operation, achieving "once encapsulated, run everywhere". As Figure 1 shown, the Docker system framework includes an image 101, an image repository 102, and a container 103. Among them, an image is a special file system. In addition to providing programs, libraries, resources, configurations, and other files required for container runtime, it also contains some configuration parameters prepared for runtime (such as anonymous volumes, environment variables, users, etc.); a container is an instance in which an image runs. Docker uses containers to run and isolate applications. When a container starts from an image, Docker will create a writable layer on the top layer of the image, and the image itself remains unchanged. A repository is a place to store images, responsible for the storage, management, and distribution of images.

[0003] The emergence of Docker has changed the way applications run and the delivery mode. Applications run inside containers, and the delivery of software has become the delivery of container images. However, the security issues of containers are not optimistic, and the most common one is image vulnerabilities. Since an image is a layered structure, each layer will introduce some files / directories (including various program files). As long as it is a program, there will inevitably be vulnerabilities. Therefore, it is necessary to regularly scan the image, compare it with the community vulnerability database, immediately discover the program vulnerabilities in the image, and rebuild the image after repair. How to efficiently rebuild an image is a technical problem that those skilled in the art are studying. Summary of the Invention

[0004] Embodiments of this application provide a method for updating an image and related devices, which can quickly complete the update of the upper-layer image when the lower-layer image changes, improving the efficiency of rebuilding the image.

[0005] In a first aspect, embodiments of this application provide a method for updating an image, and the method includes:

[0006] Determine a second image corresponding to the historical version of the first image;

[0007] Determine a target image among multiple third images whose layer information in the metadata includes the description information of the second image, where the layer where the second image is located is lower than the layer where the third image is located;

[0008] The description information about the second image in the metadata of the target image is replaced with the description information of the first image to obtain updated new metadata of the target image. The target image with updated metadata is used to instantiate an application container.

[0009] This method breaks the inherent constraints of Docker in the generation and consumption of images. The image repository that provides storage capabilities is not located inside Docker and is not subject to the constraints of Docker. Therefore, a new "processing" link is added inside the image repository. Before the image is consumed, any lower-level image that the image depends on can be flexibly replaced. By dynamically replacing the lower-level image, the upper-level image (i.e., the APP image) does not need to perceive the change of the lower-level image, and does not need to completely rebuild a new upper-level image based on the changed lower-level image. It only needs to update the description information in the metadata of the lower-level image (for example, updating the description information about the second image to the description information about the first image) to complete the update of the upper-level image. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0010] In combination with the first aspect, in a possible implementation manner of the first aspect, the present invention further includes:

[0011] The image address of the target image after metadata update is sent to the running node.

[0012] It can be understood that after the image address is sent to the running node, the application container can be instantiated.

[0013] In combination with the first aspect, or any of the foregoing possible implementations of the first aspect, in another possible implementation of the first aspect, determining the second image of the historical version corresponding to the first image includes:

[0014] Obtaining an association list corresponding to the first image, wherein the association list includes at least one identity information, and the identity information is used to identify an image of a historical version of the first image;

[0015] Determine that the identity information is identical to the identity information in the association list.

[0016] It can be understood that the identity information of the historical version of the image is recorded in the form of an association list, and then the identity information is compared one by one based on the association list to determine the second image that meets the conditions. In this way, the search is relatively comprehensive, avoiding the omission of some historical versions of the image.

[0017] Combined with the first aspect, or any of the above possible implementation manners of the first aspect, in another possible implementation manner of the first aspect, the determining the target image whose layer information in the metadata of the multiple third images contains the description information of the second image includes:

[0018] Obtain the description information of the second image;

[0019] Traverse the metadata of the multiple third images;

[0020] Determine the target image whose description information in the layer information of the metadata of the multiple third images is the same as the description information of the second image.

[0021] It can be understood that by traversing the metadata of the third image and comparing it with the description information of the second image, all target images that meet the conditions can be accurately found, avoiding the problem of insufficient search in the front.

[0022] Combined with the first aspect, or any of the above possible implementation manners of the first aspect, in another possible implementation manner of the first aspect, there are multiple target images; the replacing the description information about the second image in the metadata of the target image with the description information of the first image to obtain the new metadata after the update of the target image includes:

[0023] Locate the description information about the second image in the metadata of each target image among the multiple target images;

[0024] Replace the description information about the second image in the metadata of each target image with the description information of the first image to obtain the new metadata after the update of each target image.

[0025] It can be understood that here, the position is located first, and the specific information is replaced specifically at the appropriate position, avoiding inaccurate replacement information or replacing more information, resulting in damage or inoperability of the target image.

[0026] Combined with the first aspect, or any of the above possible implementation manners of the first aspect, in another possible implementation manner of the first aspect, before determining the second image corresponding to the historical version of the first image, it further includes:

[0027] Receive the first image and the configuration file sent by the image building system, where the configuration file includes the identity information of the first image and an association list corresponding to the first image, and the association list includes at least one piece of identity information, and the identity information is used to identify the images of the historical versions of the first image.

[0028] Here, the first image and the configuration file are generated by the image building system and sent to the image repository, so that the image repository can determine the subsequent second image and the target image based on this.

[0029] Combined with the first aspect, or any of the above possible implementation manners of the first aspect, in another possible implementation manner of the first aspect, the third image includes an APP image, and the first image includes a LIB image or a BASE image.

[0030] Combined with the first aspect, or any of the above possible implementation manners of the first aspect, in another possible implementation manner of the first aspect, the description information includes a layer digest.

[0031] Combined with the first aspect, or any of the above possible implementation manners of the first aspect, in another possible implementation manner of the first aspect, the identity information includes one or more of a name, an identifier, or a version number.

[0032] Combined with the first aspect, or any of the above possible implementation manners of the first aspect, in another possible implementation manner of the first aspect, the multiple third images belong to the images of instantiated containers.

[0033] It can be understood that when replacing the description information, it is only for the images of instantiated containers, rather than for all images. It is equivalent to replacing the description information on demand, avoiding the computational overhead caused by large-scale replacement.

[0034] Combined with the first aspect, or any of the above possible implementation manners of the first aspect, in another possible implementation manner of the first aspect, the method is applied to a vulnerability repair scenario.

[0035] It can be understood that generally in a vulnerability repair scenario, it is not necessary to make large changes to the content of the target image. Therefore, only replacing the description information about the second image in its metadata can meet the image update requirements.

[0036] Combined with the first aspect, or any of the above possible implementation manners of the first aspect, in another possible implementation manner of the first aspect, the third image includes an APP image, and the vulnerability repair scenario includes the situation where the APP image layer in the APP image has not changed.

[0037] In a second aspect, an embodiment of the present application provides an image update method, the method comprising:

[0038] Generate a first image and a configuration file, wherein the configuration file includes identity information of the first image and an association list corresponding to the first image, the association list includes at least one identity information, and the identity information is used to identify an image of a historical version of the first image;

[0039] Send the first image and the configuration file to an image repository.

[0040] The adoption of this method breaks the inherent constraint of Docker in the generation and consumption of images. The image warehouse that provides storage capacity is not located inside Docker and is not subject to the constraints of Docker. Therefore, a new "processing" link is added inside the image warehouse, which can flexibly replace any lower-level image that the image depends on before it is consumed. By dynamically replacing the lower-level image, the upper-level image (i.e., the APP image) does not need to perceive the change of the lower-level image, and does not need to completely rebuild a new upper-level image based on the changed lower-level image. It only needs to update the description information in the metadata of the lower-level image (for example, update the description information about the second image to the description information about the first image) to complete the update of the upper-level image. In order to cooperate with the image warehouse to successfully complete the image update, the image building system needs to generate and send the first image and configuration file, which is the basis for the image warehouse to determine the target image. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0041] In a third aspect, an embodiment of the present application provides an image update method, the method comprising:

[0042] Receive the image address of the target image after metadata update sent by the image repository, wherein the metadata update includes replacing the description information of the second image on which the target image depends with the description information of the first image, and the second image is a historical version corresponding to the first image;

[0043] An application container is instantiated according to the image address.

[0044] By adopting this method, the inherent constraint that both the generation and consumption of images are within Docker is broken. An additional "processing" link is added inside the image repository that provides storage capabilities. Before the image is consumed, any underlying image on which the image depends can be flexibly replaced. Through the dynamic replacement of the underlying image, the upper-layer image (i.e., the APP image) does not need to be aware of the changes in the underlying image, and there is no need to rebuild a new upper-layer image completely according to the changed underlying image. Only the description information in the metadata of the underlying image needs to be updated (for example, updating the description information about the second image to the description information about the first image), and then the update of the upper-layer image can be completed. Subsequently, the image repository only needs to send the image address of the target image with updated metadata to the running node to re-instantiate the application container. Optionally, if it is applied to the vulnerability repair scenario (for example, the second image is a vulnerable image and the first image is an image with the vulnerability repaired), then through this method, the vulnerability governance of business applications can be achieved in batches; for the high-risk and urgent vulnerabilities in the underlying image, even if the number of images (such as APP images) involved is huge in a large-scale scenario, each image does not need to be linked to the underlying layer for re-building and delivery, saving a large amount of building time-consuming, greatly reducing the volume of the delivery piece, thus improving the building efficiency, delivery efficiency, and maintenance efficiency, and reducing costs and increasing efficiency.

[0045] Fourthly, an image update device is provided in an embodiment of the present application. The device includes:

[0046] A first determination unit, configured to determine a second image corresponding to a historical version of the first image;

[0047] A second determination unit, configured to determine a target image whose intermediate layer information in the metadata of multiple third images includes the description information of the second image, where the layer where the second image is located is lower than the layer where the third image is located;

[0048] A replacement unit, configured to replace the description information about the second image in the metadata of the target image with the description information of the first image to obtain new metadata after the target image is updated, and the target image after the metadata is updated is used to instantiate the application container.

[0049] This method breaks the inherent constraints of Docker in the generation and consumption of images. The image repository that provides storage capabilities is not located inside Docker and is not subject to the constraints of Docker. Therefore, a new "processing" link is added inside the image repository. Before the image is consumed, any lower-level image that the image depends on can be flexibly replaced. By dynamically replacing the lower-level image, the upper-level image (i.e., the APP image) does not need to perceive the change of the lower-level image, and does not need to completely rebuild a new upper-level image based on the changed lower-level image. It only needs to update the description information in the metadata of the lower-level image (for example, updating the description information about the second image to the description information about the first image) to complete the update of the upper-level image. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0050] In conjunction with the fourth aspect, in a possible implementation of the fourth aspect, the following further includes:

[0051] The sending unit is used to send the image address of the target image after the metadata is updated to the running node.

[0052] It can be understood that after the image address is sent to the running node, the application container can be instantiated.

[0053] In combination with the fourth aspect, or any of the foregoing possible implementations of the fourth aspect, in another possible implementation of the fourth aspect, in the aspect of determining the second image of the historical version corresponding to the first image, the first determining unit is further configured to:

[0054] Obtaining an association list corresponding to the first image, wherein the association list includes at least one identity information, and the identity information is used to identify an image of a historical version of the first image;

[0055] Determine that the identity information is identical to the identity information in the association list.

[0056] It can be understood that recording the identity information of the historical versions of the image in the form of an association list, and then comparing the identity information one by one based on the association list to determine the qualified second image, so that the search is more comprehensive and avoids the omission of some historical versions of the image.

[0057] In combination with the fourth aspect, or any of the above possible implementation manners of the fourth aspect, in another possible implementation manner of the fourth aspect, in the aspect of determining the target image whose layer information in the metadata of the multiple third images includes the description information of the second image, the second determining unit is further configured to:

[0058] Obtain the description information of the second image;

[0059] Traverse the metadata of the multiple third images;

[0060] Determine the target image whose description information in the layer information of the metadata of the multiple third images is the same as the description information of the second image.

[0061] It can be understood that by traversing the metadata of the third image and comparing it with the description information of the second image, all target images that meet the conditions can be accurately found, avoiding the problem of insufficient search in the front.

[0062] In combination with the fourth aspect, or any of the above possible implementation manners of the fourth aspect, in another possible implementation manner of the fourth aspect, there are multiple target images; in the aspect of replacing the description information about the second image in the metadata of the target image with the description information of the first image to obtain the updated new metadata of the target image, the replacing unit is specifically configured to:

[0063] Locate the description information about the second image in the metadata of each target image among the multiple target images;

[0064] Replace the description information about the second image in the metadata of each target image with the description information of the first image to obtain the updated new metadata of each target image.

[0065] It can be understood that here, the position is located first, and the specific information is replaced at the appropriate position, avoiding inaccurate replacement information or replacing more information, resulting in damage or inoperability of the target image.

[0066] In combination with the fourth aspect, or any of the above possible implementation manners of the fourth aspect, in another possible implementation manner of the fourth aspect, it further includes a receiving unit, configured to:

[0067] Receive the first image and the configuration file sent by the image building system, where the configuration file includes the identity information of the first image and an association list corresponding to the first image, and the association list includes at least one identity information, and the identity information is used to identify the image of the historical version of the first image.

[0068] Here, the first image and the configuration file are generated by the image building system and sent to the image repository, enabling the image repository to determine the subsequent second image and the target image based on this.

[0069] Combined with the fourth aspect, or any of the above possible implementation manners of the fourth aspect, in another possible implementation manner of the fourth aspect, the third image includes an APP image, and the first image includes a LIB image or a BASE image.

[0070] Combined with the fourth aspect, or any of the above possible implementation manners of the fourth aspect, in another possible implementation manner of the fourth aspect, the description information includes a layer summary.

[0071] Combined with the fourth aspect, or any of the above possible implementation manners of the fourth aspect, in another possible implementation manner of the fourth aspect, the identity information includes one or more of a name, an identifier, or a version number.

[0072] Combined with the fourth aspect, or any of the above possible implementation manners of the fourth aspect, in another possible implementation manner of the fourth aspect, the multiple third images belong to the images of the instantiated containers.

[0073] It can be understood that when performing description information replacement, it is only for the images of the instantiated containers, rather than for all images. It is equivalent to performing description information replacement on demand, avoiding the computational overhead caused by large-scale replacement.

[0074] Combined with the fourth aspect, or any of the above possible implementation manners of the fourth aspect, in another possible implementation manner of the fourth aspect, the device is applied to the vulnerability repair scenario.

[0075] It can be understood that generally, in the vulnerability repair scenario, it is not necessary to make major changes to the content of the target image. Therefore, only replacing the description information about the second image in its metadata can meet the image update requirements.

[0076] Combined with the fourth aspect, or any of the above possible implementation manners of the fourth aspect, in another possible implementation manner of the fourth aspect, the third image includes an APP image, and the vulnerability repair scenario includes the situation where the APP image layer in the APP image has not changed.

[0077] In a fifth aspect, an embodiment of the present application provides an image update device, and the device includes:

[0078] a generating unit, configured to generate a first image and a configuration file, wherein the configuration file includes identity information of the first image and an association list corresponding to the first image, the association list includes at least one identity information, and the identity information is used to identify an image of a historical version of the first image;

[0079] A sending unit is used to send the first image and the configuration file to an image repository.

[0080] The adoption of this method breaks the inherent constraint of Docker in the generation and consumption of images. The image warehouse that provides storage capacity is not located inside Docker and is not subject to the constraints of Docker. Therefore, a new "processing" link is added inside the image warehouse, which can flexibly replace any lower-level image that the image depends on before it is consumed. By dynamically replacing the lower-level image, the upper-level image (i.e., the APP image) does not need to perceive the change of the lower-level image, and does not need to completely rebuild a new upper-level image based on the changed lower-level image. It only needs to update the description information in the metadata of the lower-level image (for example, update the description information about the second image to the description information about the first image) to complete the update of the upper-level image. In order to cooperate with the image warehouse to successfully complete the image update, the image building system needs to generate and send the first image and configuration file, which is the basis for the image warehouse to determine the target image. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0081] In a sixth aspect, an embodiment of the present application provides an image update device, the device comprising:

[0082] A receiving unit, configured to receive an image address of a target image after metadata update sent by an image repository, wherein the metadata update includes replacing description information of a second image on which the target image depends with description information of the first image, wherein the second image is a historical version corresponding to the first image;

[0083] An instantiation unit is used to instantiate an application container according to the image address.

[0084] This method breaks the inherent constraint of Docker in the generation and consumption of images. The image warehouse that provides storage capacity is not located inside Docker and is not subject to Docker constraints. Therefore, a new "processing" link is added inside the image warehouse, which can flexibly replace any lower-level images that the image depends on before it is consumed. By dynamically replacing the lower-level images, the upper-level image (i.e., the APP image) does not need to perceive the changes of the lower-level images, and does not need to completely rebuild a new upper-level image based on the changed lower-level images. It only needs to update the description information in the metadata of the lower-level image (for example, update the description information about the second image to the description information about the first image) to complete the update of the upper-level image. Subsequently, the image warehouse only needs to send the image address of the target image with updated metadata to the running node to re-instantiate the application container. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0085] In the seventh aspect, an embodiment of the present application provides a computing node, comprising a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call the computer program to implement the first aspect, or any possible implementation of the first aspect, or the second aspect, or the method described in the third aspect.

[0086] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is called by a processor, the first aspect, or any possible implementation method of the first aspect, or the second aspect, or the method described in the third aspect is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0087] Figure 1 This is a schematic diagram of the architecture of a Docker system in the prior art;

[0088] Figure 2 This is a schematic diagram of the hierarchical relationship of a complete APP image provided in an embodiment of the present application;

[0089] Figure 3 This is a schematic diagram of the principle of image layering deduplication and weight loss provided in an embodiment of the present application;

[0090] Figure 4It is a schematic diagram of the architecture of a Docker system provided by an embodiment of the present application;

[0091] Figure 5 It is a schematic flowchart of a mirror update method provided by an embodiment of the present application;

[0092] Figure 6 It is a schematic flowchart of another mirror update method provided by an embodiment of the present application;

[0093] Figure 7 It is a schematic diagram of the structure of a mirror update device provided by an embodiment of the present application;

[0094] Figure 8 It is a schematic diagram of the structure of a computing node provided by an embodiment of the present application. Detailed implementation manners

[0095] An embodiment of the present application first provides a solution for deduplicating and slimming mirror layers. Generally speaking, a complete APP mirror is actually a combination of multiple mirror layers, and each mirror layer has a unique character sequence as an identifier. For example, the sha256 digest is used as the mirror layer identifier. For the convenience of understanding, the mirror can be divided into three parts according to the role of the mirror layer and the level it is in. As Figure 2 shown, it can specifically include the underlying BASE mirror layer 201, the intermediate LIB mirror layer 202, and the upper APP mirror layer 203, where:

[0096] The underlying base (BASE) mirror layer 201: only contains basic operating system functions.

[0097] The intermediate library (LIB) mirror layer 202: on top of the basic operating system, it integrally provides enhanced general basic capabilities, such as Python, JRE, etc.

[0098] The upper application (APP) mirror layer 203: on the basis of the intermediate LIB mirror, it provides a variety of different service capabilities, such as common Redis, Zookeeper, etc.

[0099] The APP mirror layer depends on the LIB mirror layer, and the LIB mirror layer depends on the BASE mirror layer. Therefore, multiple APP mirrors of the same product may contain the same LIB mirror layer and BASE mirror layer, which will cause waste of storage resources. The duplicate LIB mirror layer and BASE mirror layer between APP mirrors can be deleted to perform deduplication and slimming of the mirror layer. Figure 3 It is illustrated by way of example.

[0100] Such as Figure 3In part a as shown, the complete APP1 image and APP2 image may contain the same BASE image layer and the same LIB image layer. As Figure 3 shown in part b, after layering, slimming down, and removing duplicates, the BASE image layer and the LIB image layer are independent of the upper APP image layer (such as the APP1 image layer and the APP2 image layer). As independent images, they are no longer integrated by the upper APP image. At the same time, the APP image deletes the duplicate BASE image layer and LIB image layer, and only retains the APP image layer (such as the APP1 image layer and the APP2 image layer). It is equivalent to obtaining a new APP1 image (essentially the APP1 image layer), APP2 image (essentially the APP2 image layer), LIB image (essentially the original LIB image layer), and BASE image (essentially the original BASE image layer). It should be noted that the image building system will add a description of the dependency relationship between this APP image and other BASE image layers and LIB image layers in the metadata file of the APP image (such as the APP1 image and the APP2 image). For example, in the metadata file of the APP2 image, the mirror identifiers of each mirror layer file it needs are defined in detail, and the order of arrangement of these mirror identifiers corresponds one by one to the order of its dependent mirrors. As Figure 3 shown in part c, in the order from top to bottom, the mirror identifier 301 in the first row represents the BASE image layer on which the entire APP image depends, and the mirror identifier 302 in the second row represents the LIB image layer on which the entire APP image depends. The mirror identifiers corresponding to the remaining mirror layer files all belong to the APP2 image itself.

[0101] When the BASE image, LIB image, and APP2 image are released, the image building system needs to upload the BASE image layer first, then the LIB image, and finally the APP2 image to the image repository. By ensuring the upload order, when uploading the APP2 image, even if the APP2 image itself does not contain the BASE image and LIB image, the image repository can still skip the upload of the BASE and LIB image layers in the APP2 image and only process the part of the APP2 image layer unique to the APP2 image based on the dependencies defined in the metadata file of the APP2 image. In terms of the effect, after layering, slimming down, and removing duplicates, the APP2 image changes the integration relationship of completely containing its own APP2 image layer, LIB image layer, and BASE image layer to an indirect dependency matching relationship, thus forming a smaller APP2 image. The slimming principle of other APP images is the same as that of the APP2 image, and no further examples will be given here. By using the layering, slimming down, and removing duplicates technology, the volume of the APP image can be greatly reduced, which is beneficial to the building and release efficiency.

[0102] Due to the mutual dependence between image layers, after the underlying image layer changes, all the image layers above it that have a dependency relationship with it must be remade (constructed) in sequence. When the number of APPs is very large, the cost and time required for construction will increase significantly; at the same time, the volume of the newly constructed image package set will also be very large, and the cost and time for fetching packages in the live network will also increase substantially. Therefore, to further solve the cost and time problems caused by the reconstruction of APP images due to changes in the underlying image layer, the embodiments of this application further provide an image update method, which will be described below in combination with Figure 4 for illustration.

[0103] Please refer to Figure 4 , Figure 4 which is a schematic diagram of a Docker system architecture provided by the embodiments of this application. The Docker system architecture includes an image construction system 401, an image repository 402, and a running node 403. Among them,

[0104] The image construction system 401 is mainly used for image construction (such as offline construction), including BASE images, LIB images, APP images, etc. The construction process mainly includes source code compilation, complete image construction, hierarchical image slimming and deduplication, etc. The constructed image is thinned to strip the images it depends on (FROM), so the output is actually an image layer. In the embodiments of this application, for the common images below the top-level APP image, there must be the identity information of this image (such as the image name) compatible with the identity information of the old image (such as the image name), and a file list (the files in this layer of the image, used to restrict that the upper-layer image construction is not allowed to overwrite / modify / delete)

[0105] The image repository 402 is a module actually responsible for image storage and distribution. The image repository stores image layer files and all image metadata files. The newly added dynamic search (see step S504) and dynamic replacement (see step S505) in the embodiments of this application are handled by the image repository. At the same time, the image repository 402 may also receive and process image pull requests from the running node to complete image distribution.

[0106] The running node 403 is the business node where the image actually runs. The main actions include pulling the image from the repository, creating a container according to the image, and starting the application; optionally, the running node 403 can also send a pull request to the image repository 402 to obtain the image.

[0107] Please refer to Figure 5 , Figure 5 which is an image update method provided by the embodiments of this application. This image update method can be applied to the Figure 4 architecture shown, or can be applied to other architectures. This method includes but is not limited to:

[0108] Step S501: The image building system generates a first image and a configuration file.

[0109] Specifically, due to reasons such as vulnerability repair and product iteration, a new image needs to be generated. For example, for a complete APP image, which includes an APP image layer that depends on a certain LIB image (or LIB image layer) to function. Later, because a certain vulnerability needs to be repaired in a certain image layer, a certain file r included in it is modified, and after the modification, a new LIB image is generated. This new LIB image can be regarded as the first image here.

[0110] This configuration file can be regarded as a carrier for relationship description. It includes the identity information of the first image and an associated list corresponding to the first image. Among them, the associated list includes at least one piece of identity information, and this identity information is used to identify the images of the historical versions of the first image. This identity information includes one or more of name, identifier, or version number. For the convenience of description, the name will be used as an example hereinafter.

[0111] For example, the current name of the first image is LIB_a. The images of the historical versions of the first image LIB_a are multiple second images. Among them, the name of the second image 1 is LIB_1, the name of the second image 2 is LIB_2, and the name of the second image 3 is LIB_2. The names of the second image 2 and the second image 3 are the same but their version numbers are different. Then, in an optional solution, the associated list includes the two pieces of identity information LIB_1 and LIB_2. Therefore, the configuration file includes the identity information LIB_a, LIB_1, and LIB_2. It should be noted that when the identity information includes an identifier or a version number, it can be analogized with the example where the identity information includes a name. The principle is the same, and no further examples will be given here.

[0112] Step S502: The image building system sends the first image and the configuration file to the image repository.

[0113] Correspondingly, the image repository receives the first image and the configuration file.

[0114] Step S503: The image repository determines the second images of the historical versions corresponding to the first image.

[0115] Specifically, some rules can be pre-configured in the image repository to mark the relationship between the first image and the second image. In this way, the image repository can determine the second image according to this rule. In many scenarios where software is applied to development, it is relatively easy to establish and query the relationship between the new version and the old version. In the embodiments of the present application, the above steps S501 and S502 may or may not exist. When steps S501 and S502 exist, the second image can be determined through the above configuration file. The following is an example for illustration:

[0116] First, obtain the association list corresponding to the first image, where the association list includes at least one identity information, and the identity information is used to identify the images of the historical versions of the first image. For example, the obtained association list includes identity information LIB_1 and LIB_2.

[0117] Then, determine the second image whose identity information is the same as that in the association list. Similarly, for example, in this step, it is necessary to search for historical images according to the names LIB_1 and LIB_2 to see which images have identity information including LIB_1 or LIB_2. Eventually, the images with identity information including LIB_1 and the images with identity information including LIB_2 will be found. These found images can be called the second images. It can be understood that there may be one or more images with identity information including LIB_1, and there may be one or more images with identity information including LIB_2. Therefore, the number of the finally found second images may be one or more.

[0118] It should be noted that the historical versions mentioned in the embodiments of the present application may also be compatible versions, or versions with a large amount of duplication in functions (such as the number of duplicate functions or the number of duplicate programs exceeding a preset threshold). The specific rules can be predefined in advance.

[0119] Step S504: The image repository determines the target images whose description information in the metadata of multiple third images includes the description information of the second image.

[0120] Among them, the description information can be used to represent the dependency relationship. For example, the description information can be the layer digest (sha256) of the image. In the embodiments of the present application, the level of the second image is lower than the level of the third image. For example, if there are a BASE image, a LIB image, and an APP image, then the level of the BASE image is lower than the level of the LIB image, and the level of the LIB image is lower than the level of the APP image. In this case, if the second image is the BASE image, then the third image can be the APP image; if the second image is the LIB image, then the third image can be the APP image. Generally speaking, if the operation of the third image depends on the second image, then the layer information in the metadata of the third image contains the description information of the second image. Therefore, through this description information, it can be determined which third images' operations depend on the second image. The third images that need to depend on the second image are called target images. For the convenience of description, the following is an example:

[0121] (a) Traverse the metadata of all second images to obtain the description information. For example, perform the following operations on each second image:

[0122] 1. Read the metadata of the second image.

[0123] 2. Record the description information in the metadata, such as the layer digest (sha256), and denote this description information as target.

[0124] Optionally, if the second image is a LIB image, then this LIB image can be a LIB image after slimming. Therefore, this LIB image is actually an image mainly containing the LIB image layer. In this case, the description information (such as the layer digest) of this second image can specifically be the description information (such as the layer digest) of the LIB image layer contained therein.

[0125] (b) Traverse each of the multiple third images to determine the target images. For example, perform the following operations on each third image:

[0126] 1. Read the metadata (also called the metadata file) of the third image.

[0127] 2. Traverse the description information in the metadata. If this identity information is the same as the description information of the second image, then mark this third image as a target. For example, traverse the list of layer information layers (i.e., the description information) in the metadata. If the digest of a certain layer is the same as the previously marked target (i.e., the description of the second image), it means that this third image uses this second image and needs to be dynamically replaced. Therefore, mark this third image as a target image.

[0128] Optionally, the multiple third images in the embodiments of the present application may refer to a certain type of image, such as an APP image that has been instantiated into a container. The APP image category here is only an example, and other types of images can also be processed according to the same principle.

[0129] Step S505: The image repository replaces the description information about the second image in the metadata of the target image with the description information of the first image to obtain new metadata after updating the target image.

[0130] Specifically, a replacement operation is performed for each target image, that is, the description information about the second image in the metadata of the target image is replaced with the description information of the first image. For example, the layer digest (i.e., description information) AAAA about the second image in the original source data of the target image is replaced with the layer digest BBBB of the first image. Therefore, after updating, the metadata of the target image contains the layer digest BBBB of the first image and no longer contains the layer digest AAAA of the second image, and other information in the metadata of the target image remains unchanged.

[0131] For ease of understanding, the following is an example to illustrate this process:

[0132] (c) Read the metadata of the first image.

[0133] 1. Record the description information contained in the metadata, such as the layer digest (sha256), and for convenience of description, it is denoted as new.

[0134] (d) Traverse the target images, and perform the following operations for each target image:

[0135] 1. Copy the metadata of the target image as new metadata. It should be noted that copying can be used for backup for subsequent recovery, but this step is an optional step rather than a necessary step. If there is no copying, the subsequent operations are directly performed on the original metadata of the target image.

[0136] 2. Traverse the layer information list layers in the new metadata to locate the description information to be replaced, such as the layer digest

[0137] (sha256).

[0138] 3. Replace the located layer description information with the description information in the metadata of the first image recorded previously, such as replacing it with the previously marked new.

[0139] 4. After the description information in the new metadata is replaced, generate an image address based on the latest metadata.

[0140] It should be noted that after the image address of the target image is updated, it is equivalent to updating the target image.

[0141] Step S506: The image repository returns the image address of the target image with updated metadata to the container management component.

[0142] Optionally, the container management component can be a node or device outside the image repository, such as a device that initiates or triggers Figure 5 the process shown.

[0143] Step S507: The container management component sends the image address of the target image with updated metadata to the running node.

[0144] Step S508: The running node receives the image address of the target image with updated metadata.

[0145] Step S509: The running node reinstantiates the application container according to the image address.

[0146] Specifically, the running node sends a pull request to the image repository according to the image address of the updated target image. After receiving the pull request, the image repository sends the target image with updated metadata to the running node. Of course, corresponding policies can also be preconfigured, and the pull request is sent to reinstantiate the application container when certain conditions are met. In this step, the original target image can be closed (or killed) first, and the target image with updated metadata is restarted. This step can receive a batch of image addresses and reinstantiate the application container in batches through the new image addresses. If it is used in a vulnerability repair scenario, the effect of batch vulnerability repair can be achieved.

[0147] It should be noted that Figure 5 the method shown can be applied to the scenario of hierarchical slimming and deduplication, or to the scenario of non-hierarchical slimming and deduplication. When applied to the non-hierarchical slimming and deduplication scenario, the above first image, second image, and third image are actually image layers. For example, if the first image and the second image mentioned above are actually LIB images, then they are actually LIB image layers; if the third image mentioned above is actually an APP image, then it is actually an APP layer.

[0148] In an alternative solution, the above method is applied to a vulnerability repair scenario. For example, the third image includes an APP image, and in the vulnerability repair scenario, the APP image layer in the APP image has not changed, then this scenario can be considered a vulnerability repair scenario; another example is that the first image has changed the file r compared with the second image, and the file r also exists in the APP image layer, then this does not belong to the vulnerability repair scenario. It should be noted that the two situations here are only examples. Specifically, what situations belong to the vulnerability repair scenario and what situations do not belong to the vulnerability repair scenario also depend on how it was defined beforehand, and this application does not make specific restrictions.

[0149] In another optional solution, the steps performed by the image building system may be considered to belong to the offline building phase, and the steps performed by the image repository may belong to the online updating phase. Figure 6 In a possible implementation, the steps executed by the image building system may also be assigned to the image warehouse for execution, such as the step of generating the first image, and some of the steps executed by the image warehouse may also be assigned to the image building system for execution, such as the above steps S503, S504, and one or more of the steps S504 may be completed by the image building system; in addition, in some scenarios, the above image building system and the image warehouse may be merged, and many of the above steps may be considered to be the main body executed by the merger of the two.

[0150] exist Figure 5 In the method shown, the inherent constraint of Docker in the generation and consumption of images is broken. The image warehouse that provides storage capabilities is not located inside Docker and is not subject to the constraints of Docker. Therefore, a new "processing" link is added inside the image warehouse. Any lower-level images that the image depends on can be flexibly replaced before the image is consumed. By dynamically replacing the lower-level images, the upper-level image (i.e., the APP image) does not need to perceive the changes of the lower-level images, and does not need to completely rebuild a new upper-level image based on the changed lower-level image. It only needs to update the description information in the metadata of the lower-level image (for example, update the description information about the second image to the description information about the first image) to complete the update of the upper-level image. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0151] The method of the embodiment of the present application is described in detail above, and the device of the embodiment of the present application is provided below.

[0152] See also Figure 7 , Figure 7: is a schematic diagram of the structure of an image update device provided in an embodiment of the present application, the image update device 70 may include a first determination unit 701, a second determination unit 702 and a replacement unit 703, the device 70 may be the image warehouse mentioned above or a component in the image warehouse, the image warehouse may be a physical device or a software function system mounted on a computing node, and no specific limitation is made here. The detailed description of each unit is as follows.

[0153] In a fourth aspect, an embodiment of the present application provides an image update device, the device comprising:

[0154] A first determining unit 701 is used to determine a second image of a historical version corresponding to a first image;

[0155] A second determining unit 702 is configured to determine a target image whose layer information in metadata of a plurality of third images includes description information of the second image, wherein the layer at which the second image is located is lower than the layer at which the third image is located;

[0156] The replacement unit 703 is used to replace the description information about the second image in the metadata of the target image with the description information of the first image to obtain new metadata of the target image after update. The target image after the metadata update is used to instantiate an application container.

[0157] This method breaks the inherent constraints of Docker in the generation and consumption of images. The image repository that provides storage capabilities is not located inside Docker and is not subject to the constraints of Docker. Therefore, a new "processing" link is added inside the image repository. Before the image is consumed, any lower-level image that the image depends on can be flexibly replaced. By dynamically replacing the lower-level image, the upper-level image (i.e., the APP image) does not need to perceive the change of the lower-level image, and does not need to completely rebuild a new upper-level image based on the changed lower-level image. It only needs to update the description information in the metadata of the lower-level image (for example, updating the description information about the second image to the description information about the first image) to complete the update of the upper-level image. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0158] In a possible implementation, the device 70 further includes:

[0159] A sending unit, configured to send the image address of the target image after metadata update to a running node.

[0160] It can be understood that after the image address is sent to the running node, the application container can be instantiated.

[0161] In another possible implementation manner, in terms of determining the second image corresponding to the historical version of the first image, the first determining unit is further configured to:

[0162] Obtain an association list corresponding to the first image, where the association list includes at least one identity information for identifying the image of the historical version of the first image;

[0163] Determine the second image whose identity information is the same as the identity information in the association list.

[0164] It can be understood that the identity information of the images of historical versions is recorded in the form of an association list, and then the identity information is compared one by one based on the association list to determine the eligible second image, so that the search is relatively comprehensive and some images of historical versions are avoided from being omitted.

[0165] In another possible implementation manner, in terms of determining the target image whose layer information in the metadata of multiple third images contains the description information of the second image, the second determining unit is further configured to:

[0166] Obtain the description information of the second image;

[0167] Traverse the metadata of multiple third images;

[0168] Determine the target image whose description information in the layer information of the metadata of the multiple third images is the same as the description information of the second image.

[0169] It can be understood that by traversing the metadata of the third images and comparing it with the description information of the second image, all eligible target images can be accurately found, avoiding the problem of insufficient search in the front.

[0170] In another possible implementation manner, there are multiple target images; in terms of replacing the description information about the second image in the metadata of the target image with the description information of the first image to obtain the updated new metadata of the target image, the replacing unit is specifically configured to:

[0171] Locate the description information about the second image in the metadata of each target image among the multiple target images;

[0172] Replace the description information about the second image in the metadata of each target image with the description information of the first image to obtain the updated new metadata of each target image.

[0173] It can be understood that here, position positioning is performed first, and specific information is replaced at the appropriate position to avoid inaccurate replacement information or replacing more information than necessary, resulting in damage or inoperability of the target image.

[0174] In another possible implementation manner, it further includes a receiving unit for:

[0175] Receive the first image and the configuration file sent by the image building system, where the configuration file includes the identity information of the first image and the association list corresponding to the first image, and the association list includes at least one identity information, and the identity information is used to identify the images of the historical versions of the first image.

[0176] Here, the first image and the configuration file are generated by the image building system and sent to the image repository, so that the image repository can determine the subsequent second image and the target image based on this.

[0177] In another possible implementation manner, the third image includes an APP image, and the first image includes a LIB image or a BASE image.

[0178] In another possible implementation manner, the description information includes a layer digest.

[0179] In another possible implementation manner, the identity information includes one or more of a name, an identifier, or a version number.

[0180] In another possible implementation manner, the multiple third images belong to the images of instantiated containers.

[0181] It can be understood that when performing the description information replacement, it is only for the images of instantiated containers, rather than for all images. It is equivalent to replacing the description information on demand, avoiding the computational overhead caused by large-scale replacement.

[0182] In another possible implementation manner, the device is applied to a vulnerability repair scenario.

[0183] It can be understood that generally, in a vulnerability repair scenario, it is not necessary to make large changes to the content of the target image. Therefore, only replacing the description information about the second image in its metadata can meet the image update requirements.

[0184] In yet another possible implementation, the third image includes an APP image, and the vulnerability repair scenario includes a situation where an APP image layer in the APP image is not changed.

[0185] It should be noted that the implementation and beneficial effects of each unit can also refer to Figure 5 The corresponding description of the method embodiment shown.

[0186] Furthermore, the embodiment of the present application also provides an image update device, which may include a generation unit and a sending unit. The device may be the image building system mentioned above or a component in the image building system. The image building system may be a physical device or a software function system mounted on a computing node, which is not specifically limited here. The detailed description of each unit is as follows.

[0187] a generating unit, configured to generate a first image and a configuration file, wherein the configuration file includes identity information of the first image and an association list corresponding to the first image, the association list includes at least one identity information, and the identity information is used to identify an image of a historical version of the first image;

[0188] A sending unit is used to send the first image and the configuration file to an image repository.

[0189] The adoption of this method breaks the inherent constraint of Docker in the generation and consumption of images. The image warehouse that provides storage capacity is not located inside Docker and is not subject to the constraints of Docker. Therefore, a new "processing" link is added inside the image warehouse, which can flexibly replace any lower-level image that the image depends on before it is consumed. By dynamically replacing the lower-level image, the upper-level image (i.e., the APP image) does not need to perceive the change of the lower-level image, and does not need to completely rebuild a new upper-level image based on the changed lower-level image. It only needs to update the description information in the metadata of the lower-level image (for example, update the description information about the second image to the description information about the first image) to complete the update of the upper-level image. In order to cooperate with the image warehouse to successfully complete the image update, the image building system needs to generate and send the first image and configuration file, which is the basis for the image warehouse to determine the target image. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0190] It should be noted that the implementation and beneficial effects of each unit can also refer to Figure 5 The corresponding description of the method embodiment shown.

[0191] Furthermore, the embodiment of the present application also provides an image update device, which may include a receiving unit and an instantiation unit. The device may be the aforementioned running node or a component in the running node. The running node may be a physical device or a software function system mounted on a computing node, which is not specifically limited here. The detailed description of each unit is as follows.

[0192] A receiving unit, configured to receive an image address of a target image after metadata update sent by an image repository, wherein the metadata update includes replacing description information of a second image on which the target image depends with description information of the first image, wherein the second image is a historical version corresponding to the first image;

[0193] An instantiation unit is used to instantiate an application container according to the image address.

[0194] This method breaks the inherent constraint of Docker in the generation and consumption of images. The image warehouse that provides storage capacity is not located inside Docker and is not subject to Docker constraints. Therefore, a new "processing" link is added inside the image warehouse, which can flexibly replace any lower-level images that the image depends on before it is consumed. By dynamically replacing the lower-level images, the upper-level image (i.e., the APP image) does not need to perceive the changes of the lower-level images, and does not need to completely rebuild a new upper-level image based on the changed lower-level images. It only needs to update the description information in the metadata of the lower-level image (for example, update the description information about the second image to the description information about the first image) to complete the update of the upper-level image. Subsequently, the image warehouse only needs to send the image address of the target image with updated metadata to the running node to re-instantiate the application container. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0195] It should be noted that the implementation and beneficial effects of each unit can also refer to Figure 5 The corresponding description of the method embodiment shown.

[0196] See alsoFigure 8 , Figure 8 Figure 8 is a computing node 80 provided by an embodiment of the present application. The computing node 80 includes a processor 801, a memory 802, and a communication interface 803. The processor 801, the memory 802, and the communication interface 803 are interconnected through a bus.

[0197] The memory 802 includes, but is not limited to, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or a compact disc read-only memory (CD-ROM). The memory 802 is used for relevant computer programs and data. The communication interface 803 is used to receive and send data.

[0198] The processor 801 may be one or more central processing units (CPUs). When the processor 801 is a single CPU, the CPU may be a single-core CPU or a multi-core CPU.

[0199] In an alternative solution, the computing node 80 is used to implement the operations performed by the above mirror repository. Specifically, the processor 801 in the computing node 80 is used to read the computer program code stored in the memory 802 and perform the following operations:

[0200] Determine a second mirror corresponding to the historical version of the first mirror;

[0201] Determine a target mirror among the metadata of multiple third mirrors whose layer information contains the description information of the second mirror, where the layer where the second mirror is located is lower than the layer where the third mirror is located;

[0202] Replace the description information about the second mirror in the metadata of the target mirror with the description information of the first mirror to obtain the updated new metadata of the target mirror. The target mirror after the metadata update is used to instantiate an application container.

[0203] This method breaks the inherent constraints of Docker in the generation and consumption of images. The image repository that provides storage capabilities is not located inside Docker and is not subject to the constraints of Docker. Therefore, a new "processing" link is added inside the image repository. Before the image is consumed, any lower-level image that the image depends on can be flexibly replaced. By dynamically replacing the lower-level image, the upper-level image (i.e., the APP image) does not need to perceive the change of the lower-level image, and does not need to completely rebuild a new upper-level image based on the changed lower-level image. It only needs to update the description information in the metadata of the lower-level image (for example, updating the description information about the second image to the description information about the first image) to complete the update of the upper-level image. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0204] In a possible implementation manner, the processor 801 is further configured to:

[0205] The image address of the target image after metadata update is sent to the running node through the communication interface 803.

[0206] It can be understood that after the image address is sent to the running node, the application container can be instantiated.

[0207] In another possible implementation, determining the second image of the historical version corresponding to the first image includes:

[0208] Obtaining an association list corresponding to the first image, wherein the association list includes at least one identity information, and the identity information is used to identify an image of a historical version of the first image;

[0209] Determine that the identity information is identical to the identity information in the association list.

[0210] It can be understood that recording the identity information of the historical versions of the image in the form of an association list, and then comparing the identity information one by one based on the association list to determine the qualified second image, so that the search is more comprehensive and avoids the omission of some historical versions of the image.

[0211] In yet another possible implementation, determining a target image whose layer information in metadata of the plurality of third images includes description information of the second image includes:

[0212] Obtain the description information of the second image;

[0213] Traverse the metadata of multiple third images;

[0214] Determine the target image among the multiple third images whose description information in the layer information of the metadata is the same as the description information of the second image.

[0215] It can be understood that by traversing the metadata of the third image and comparing it with the description information of the second image, all target images that meet the conditions can be accurately found, avoiding the problem of insufficient search in the front.

[0216] In another possible implementation, there are multiple target images; the step of replacing the description information about the second image in the metadata of the target image with the description information of the first image to obtain the updated new metadata of the target image includes:

[0217] Locate the description information about the second image in the metadata of each target image among the multiple target images;

[0218] Replace the description information about the second image in the metadata of each target image with the description information of the first image to obtain the updated new metadata of each target image.

[0219] It can be understood that here, the position is located first, and specific information is replaced at the appropriate position, avoiding inaccurate replacement information or replacing redundant information, resulting in damage or inaccessibility of the target image.

[0220] In another possible implementation, before determining the second image corresponding to the historical version of the first image, it further includes:

[0221] Receive the first image and the configuration file sent by the image building system, where the configuration file includes the identity information of the first image and the associated list corresponding to the first image, and the associated list includes at least one identity information, and the identity information is used to identify the image of the historical version of the first image.

[0222] Here, the first image and the configuration file are generated by the image building system and sent to the image repository, so that the image repository can determine the subsequent second image and the target image based on this.

[0223] In another possible implementation, the third image includes an APP image, and the first image includes a LIB image or a BASE image.

[0224] In another possible implementation, the description information includes a layer summary.

[0225] In yet another possible implementation, the identity information includes one or more of a name, an identifier, or a version number.

[0226] In yet another possible implementation, the multiple third images belong to the images of the instantiated containers.

[0227] It can be understood that when performing description information replacement, it is only for the images of the instantiated containers, rather than for all images. It is equivalent to performing description information replacement on demand, avoiding the computational overhead caused by large-scale replacement.

[0228] In yet another possible implementation, the method is applied to a vulnerability repair scenario.

[0229] It can be understood that generally in a vulnerability repair scenario, it is not necessary to make major changes to the content of the target image. Therefore, only replacing the description information about the second image in its metadata can meet the image update requirements.

[0230] In yet another possible implementation, the third image includes an APP image, and the vulnerability repair scenario includes the case where the APP image layer in the APP image has not changed.

[0231] It should be noted that the implementation and beneficial effects of each operation can also be correspondingly referred to Figure 5 the corresponding description of the method embodiment shown.

[0232] In an alternative solution, the computing node 80 is used to implement the operations performed by the above-mentioned image building system. Specifically, the processor 801 in the computing node 80 is used to read the computer program code stored in the memory 802 and perform the following operations:

[0233] Generate a first image and a configuration file, where the configuration file includes the identity information of the first image and an association list corresponding to the first image, and the association list includes at least one piece of identity information, and the identity information is used to identify the images of the historical versions of the first image;

[0234] Send the first image and the configuration file to the image repository through the communication interface 803.

[0235] By adopting this method, the inherent constraint that both the generation and consumption of images are within Docker is broken. The image repository that provides storage capabilities is not set inside Docker and is not restricted by Docker. Therefore, a "processing" link is added inside the image repository. Before the image is consumed, any lower-layer image on which the image depends can be flexibly replaced. Through the dynamic replacement of the lower-layer image, the upper-layer image (i.e., the APP image) does not need to be aware of the changes in the lower-layer image and does not need to rebuild a new upper-layer image completely according to the changed lower-layer image. Only the description information in the metadata of the lower-layer image needs to be updated (for example, updating the description information about the second image to the description information about the first image), and the update of the upper-layer image can be completed. To cooperate with the image repository to successfully complete the image update, the image building system needs to generate and send the first image and the configuration file, which is the basis for the image repository to determine the target image. Optionally, if it is applied to the vulnerability repair scenario (for example, the second image is a vulnerable image and the first image is the image with the vulnerability repaired), then through this method, the vulnerability governance of business applications can be achieved in batches; for the high-risk and urgent vulnerabilities in the lower-layer image, even if the number of images (such as APP images) involved in a large-scale scenario is huge, each image does not need to be linked to the lower layer for re-building and delivery, saving a large amount of building time-consuming, greatly reducing the volume of the delivery piece, thus improving the building efficiency, delivery efficiency, and maintenance efficiency, and reducing costs and increasing efficiency.

[0236] It should be noted that the implementation and beneficial effects of each operation can also be correspondingly referred to Figure 5 the corresponding description of the method embodiment shown.

[0237] In an optional solution, the computing node 80 is used to implement the operations executed by the above running node. Specifically, the processor 801 in the computing node 80 is used to read the computer program code stored in the memory 802 and execute the following operations:

[0238] Receive the image address of the target image after the metadata update sent by the image repository. The metadata update includes replacing the description information of the second image on which the target image depends with the description information of the first image, and the second image is the historical version corresponding to the first image;

[0239] Instantiate an application container according to the image address.

[0240] This method breaks the inherent constraint of Docker in the generation and consumption of images. The image warehouse that provides storage capacity is not located inside Docker and is not subject to Docker constraints. Therefore, a new "processing" link is added inside the image warehouse, which can flexibly replace any lower-level images that the image depends on before it is consumed. By dynamically replacing the lower-level images, the upper-level image (i.e., the APP image) does not need to perceive the changes of the lower-level images, and does not need to completely rebuild a new upper-level image based on the changed lower-level images. It only needs to update the description information in the metadata of the lower-level image (for example, update the description information about the second image to the description information about the first image) to complete the update of the upper-level image. Subsequently, the image warehouse only needs to send the image address of the target image with updated metadata to the running node to re-instantiate the application container. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0241] It should be noted that the implementation and beneficial effects of each operation can also refer to Figure 5 The corresponding description of the method embodiment shown.

[0242] The embodiment of the present application also provides a chip system, the chip system includes at least one processor, a memory and an interface circuit, the memory, the interface circuit and the at least one processor are interconnected through a line, and a computer program is stored in the at least one memory; when the computer program is executed by the processor, Figure 5 The method flow is shown.

[0243] The present application also provides a computer-readable storage medium in which a computer program is stored. When the computer-readable storage medium is executed on a processor, Figure 5 The method flow is shown.

[0244] The present application also provides a computer program product, which, when executed on a processor, implements Figure 5 The method flow is shown.

[0245] To summarize, by implementing the embodiments of the present application, the inherent constraints of Docker in the generation and consumption of images are broken. The image warehouse that provides storage capabilities is not located inside Docker and is not subject to the constraints of Docker. Therefore, a new "processing" link is added inside the image warehouse, and any lower-level images that the image depends on can be flexibly replaced before the image is consumed. By dynamically replacing the lower-level images, the upper-level image (i.e., the APP image) does not need to perceive the changes of the lower-level images, and does not need to completely rebuild a new upper-level image based on the changed lower-level image. It only needs to update the description information in the metadata of the lower-level image (for example, updating the description information about the second image to the description information about the first image) to complete the update of the upper-level image. Optionally, if it is applied to vulnerability repair scenarios (for example, the second image is an image with a vulnerability, and the first image is an image with the vulnerability fixed), vulnerability management of business applications can be achieved in batches in this way; for high-risk emergency vulnerabilities in lower-level images, even in large-scale scenarios where a large number of images (such as APP images) are involved, each image does not need to be linked to the lower layer for reconstruction and delivery, which saves a lot of construction time and greatly reduces the size of deliverables, thereby improving construction efficiency, delivery efficiency, and maintenance efficiency, reducing costs and increasing efficiency.

[0246] A person skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by a computer program or hardware related to the computer program, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned method embodiments. The aforementioned storage medium includes: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store computer program codes.

Claims

1. A mirror update method, characterized in that, it includes: Determine a second mirror corresponding to the historical version of the first mirror; Determine a target mirror among the metadata of multiple third mirrors whose layer information contains the description information of the second mirror, where the layer where the second mirror is located is lower than the layer where the third mirror is located; Replace the description information about the second mirror in the metadata of the target mirror with the description information of the first mirror to obtain new metadata after updating the target mirror, and the target mirror after metadata update is used to instantiate an application container.

2. The method according to claim 1, characterized in that, it further includes: Send the mirror address of the target mirror after metadata update to the running node.

3. The method according to claim 1 or 2, characterized in that, The step of determining the second mirror corresponding to the historical version of the first mirror includes: Obtain an association list corresponding to the first mirror, where the association list includes at least one identity information, and the identity information is used to identify the mirror of the historical version of the first mirror; Determine the second mirror whose identity information is the same as that in the association list.

4. The method according to any one of claims 1-3, characterized in that, The step of determining a target mirror among the metadata of multiple third mirrors whose layer information contains the description information of the second mirror includes: Obtain the description information of the second mirror; Traverse the metadata of multiple third mirrors; Determine the target mirror among the multiple third mirrors whose description information in the layer information of the metadata is the same as the description information of the second mirror.

5. The method according to any one of claims 1-4, characterized in that, There are multiple target mirrors; the step of replacing the description information about the second mirror in the metadata of the target mirror with the description information of the first mirror to obtain new metadata after updating the target mirror includes: Locate the description information about the second mirror in the metadata of each target mirror among the multiple target mirrors; Replace the description information about the second mirror in the metadata of each target mirror with the description information of the first mirror to obtain new metadata after updating each target mirror.

6. The method according to any one of claims 1-5, characterized in that, Before determining the second mirror corresponding to the historical version of the first mirror, it further includes: Receive the first mirror and a configuration file sent by a mirror building system, where the configuration file includes the identity information of the first mirror and an association list corresponding to the first mirror, and the association list includes at least one identity information, and the identity information is used to identify the mirror of the historical version of the first mirror.

7. The method according to any one of claims 1-6, characterized in that, The third mirror includes an APP mirror, and the first mirror includes a LIB mirror or a BASE mirror.

8. The method according to any one of claims 1-7, characterized in that, The description information includes a layer digest.

9. The method according to any one of claims 1-8, characterized in that, The identity information includes one or more of a name, an identifier, or a version number.

10. The method according to any one of claims 1-9, wherein, the multiple third images belong to the images of the instantiated containers.

11. The method according to any one of claims 1-10, wherein, the method is applied to a vulnerability repair scenario.

12. The method according to claim 11, wherein, the third image includes an APP image, and the vulnerability repair scenario includes a situation where the APP image layer in the APP image has not changed.

13. A method for updating an image, wherein, comprises: generating a first image and a configuration file, wherein the configuration file includes the identity information of the first image and an association list corresponding to the first image, the association list includes at least one piece of identity information, and the identity information is used to identify the image of the historical version of the first image; sending the first image and the configuration file to an image repository.

14. A method for updating an image, wherein, comprises: receiving the image address of the target image after the metadata is updated, where the metadata update includes replacing the description information of the second image on which the target image depends with the description information of the first image, and the second image is the historical version corresponding to the first image; instantiating an application container according to the image address.

15. An image update device, wherein, comprises: a first determination unit, configured to determine a second image of the historical version corresponding to the first image; a second determination unit, configured to determine a target image whose layer information in the metadata of multiple third images includes the description information of the second image, wherein the layer where the second image is located is lower than the layer where the third image is located; a replacement unit, configured to replace the description information about the second image in the metadata of the target image with the description information of the first image to obtain the new metadata after the target image is updated, and the target image after the metadata is updated is used to instantiate an application container.

16. The device according to claim 15, wherein, further comprises: a sending unit, configured to send the image address of the target image after the metadata is updated to a running node.

17. The device according to claim 15 or 16, wherein, in the aspect of determining the second image of the historical version corresponding to the first image, the first determination unit is further configured to: obtain the association list corresponding to the first image, wherein the association list includes at least one piece of identity information, and the identity information is used to identify the image of the historical version of the first image; determine the second image whose identity information is the same as the identity information in the association list.

18. The device according to any one of claims 15-17, wherein, in the aspect of determining the target image whose layer information in the metadata of multiple third images includes the description information of the second image, the second determination unit is further configured to: obtain the description information of the second image; traverse the metadata of multiple third images; Determine the target mirror among the multiple third mirrors whose description information in the layer information of the metadata is the same as that of the second mirror.

19. The device according to any one of claims 15-18, wherein, there are multiple target mirrors; in terms of replacing the description information about the second mirror in the metadata of the target mirror with the description information of the first mirror to obtain the new metadata after updating the target mirror, the replacement unit is specifically used for: Locate the description information about the second mirror in the metadata of each target mirror among the multiple target mirrors; Replace the description information about the second mirror in the metadata of each target mirror with the description information of the first mirror to obtain the new metadata after updating each target mirror.

20. The device according to any one of claims 15-19, wherein, it further includes a receiving unit, which is used for: Receiving the first mirror and the configuration file sent by the mirror building system, wherein the configuration file includes the identity information of the first mirror and the association list corresponding to the first mirror, and the association list includes at least one piece of identity information, and the identity information is used to identify the mirror of the historical version of the first mirror.

21. The device according to any one of claims 15-20, wherein, the third mirror includes an APP mirror, and the first mirror includes a LIB mirror or a BASE mirror.

22. The device according to any one of claims 15-21, wherein, the description information includes a layer summary.

23. The device according to any one of claims 15-22, wherein, the identity information includes one or more of a name, an identifier, or a version number.

24. The device according to any one of claims 15-23, wherein, the multiple third mirrors belong to the mirrors of instantiated containers.

25. The device according to any one of claims 15-24, wherein, the device is applied to a vulnerability repair scenario.

26. The device according to claim 25, wherein, the third mirror includes an APP mirror, and the vulnerability repair scenario includes the situation where the APP mirror layer in the APP mirror has not changed.

27. A mirror update device, wherein, it includes: A generating unit, which is used to generate a first mirror and a configuration file, wherein the configuration file includes the identity information of the first mirror and the association list corresponding to the first mirror, and the association list includes at least one piece of identity information, and the identity information is used to identify the mirror of the historical version of the first mirror; A sending unit, which is used to send the first mirror and the configuration file to the mirror repository.

28. A mirror update device, wherein, it includes: A receiving unit, which is used to receive the mirror address of the target mirror after the metadata is updated, and the metadata update includes replacing the description information of the second mirror on which the target mirror depends with the description information of the first mirror, and the second mirror is the historical version corresponding to the first mirror; An instantiation unit for instantiating an application container according to the mirror address.

29. A computing node, characterized in that the computing node includes a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call the computer program to implement the method according to any one of claims 1-14.

30. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, and when the computer program is called by a processor, the method according to any one of claims 1-14 is implemented.

Images