Mirror dependency relationship judgment method and system, electronic device and readable storage medium

Abstract

The application provides a mirror image dependency relationship judgment method and system, electronic equipment and a readable storage medium, and belongs to the technical field of containerization. The method extracts layer construction information and layer identification numbers of each layer of a target business mirror image, calculates a hash value, and due to the uniqueness of the hash value, the mirror image dependency relationship analysis is more accurate and faster, accurate, fast and efficient analysis of the mass mirror image dependency relationship in a large warehouse is realized, the consumption of computing resources can be significantly reduced, the dependency relationship between the base mirror image and the business mirror image in the subsequent mirror image construction process is laid as a foundation for automatic identification, and when the base mirror image changes, the business mirror image that needs to be repaired can be accurately identified.

Description

Technical Field

[0001] This invention relates to the field of containerization technology, specifically to a method, system, electronic device, and readable storage medium for determining image dependencies. Background Technology

[0002] Image and image registry / repository are core concepts in containerization technologies (such as Docker). Their differences and relationships are as follows:

[0003] An image is a lightweight, read-only template that contains everything needed to run an application (such as code, runtime environment, libraries, configuration files, etc.). It is the foundation of containers, similar to a virtual machine's "system image," but more efficient.

[0004] An image itself cannot be modified, but new versions can be generated based on older images. An image consists of multiple "layers," each representing a change to the file system, shared and reused to save space. Images can run in any environment that supports container technology (such as local machines or cloud servers). An image is similar to a phone's "system installation package" (such as an Android .apk file), which, after installation, creates a usable system instance.

[0005] An image repository is a service for storing and distributing images, similar to a code repository (such as GitHub), but specifically designed for managing container images. Image repositories store user-built images or publicly available images, allowing users to pull or push images from the repository. Image repositories are similar to an "app store" (such as the App Store on a mobile phone): developers upload applications (images), and users download and install them (pull images), i.e.: Developer → Build image → Push image to repository → User pull image → Run container.

[0006] In summary: An image is a "static template" for an application, used to generate containers (a container = image + process + isolation mechanism; it's the "container" for application delivery, allowing developers to focus on code and operations to focus on deployment). An image repository is the "storage center" for images, responsible for image sharing and version management.

[0007] Both support the development, deployment, and operation processes of containerized applications.

[0008] In enterprise-level container image management, image repositories typically contain a large number of images, which may originate from different business systems and applications. Due to a lack of effective dependency tracking and management, it is often difficult to identify whether business images are built on a unified base image. This lack of transparency poses significant challenges to image maintenance and management, especially when the base image contains security vulnerabilities or other risks, making it difficult to quickly identify which business images depend on that base image and require remediation. Therefore, how to automatically identify the dependencies between base images and business images during the image building process, and how to accurately identify the business images that need remediation when the base image changes, have become urgent technical problems to be solved.

[0009] During the container image building process, an image may depend on other images or certain resources. For example, an application image may be based on a base image (such as an Alpine or Ubuntu image), and other dependent libraries and applications may be installed and configured on top of it. These relationships and dependencies can be expressed and managed through build scripts, Dockerfiles, build tools, etc.

[0010] The existing known technologies for identifying mirror dependencies mainly include the following:

[0011] Solution 1: Dockerfile Analysis: By parsing the FROM instructions in the Dockerfile, the image build relationships are determined. The Dockerfile is a plain text file containing instructions such as FROM, COPY, and RUN (see Table 1 below for instructions and their uses), describing how to build a new image step-by-step from a base image.

[0012] instruction use FROM Specify base image COPY Copy files to the image RUN Execute commands (such as installing software). ENV Set environment variables EXPOSE Declare the port that the container listens on. CMD The command executed by default when the container starts.

[0013] Table 1: Instructions and their uses for finding specific elements in the Dockerfile

[0014] For example: FROM java-openjdk:11.0.16-20220915

[0015] The From command specifies the base image for the build, namely java-openjdk:11.0.16-20220915.

[0016] Option 2: Docker image history analysis: using docker history This command retrieves the build history of each layer of an image and analyzes the build relationships of all images.

[0017] By comparing the layer build information of two images, the dependencies between them can be determined. If the first N layers of one image are the same as all layers of another image, then there may be a build dependency between the two images.

[0018] Option 3: Docker image tags and metadata: During the image building process, tags are added manually to record parent image information in order to track build relationships.

[0019] For example, LABEL BASEIMAGE="java-openjdk:11.0.16-20220915" shows an example of recording base image information in a Dockerfile using the Label field.

[0020] The disadvantages of existing technology are:

[0021] 1. Both Solution 1 and Solution 2 suffer from inaccurate detection because image names cannot uniquely identify an image. For example, a business image was built based on openjdk:latest in 2023. The openjdk:latest image had its vulnerability patched in 2024, but the name remained unchanged. Therefore, the vulnerability in the business image built on openjdk:latest will not be patched simply because the openjdk:latest image patched its vulnerability in 2024. This is because it was built based on the openjdk:latest image it created in 2023. Analyzing dependencies solely based on image names and build information in the Dockerfile may lead to errors.

[0022] 2. For large-scale image repositories, traditional analysis methods are time-consuming and difficult to adapt to practical application needs. Existing technologies require processing a large amount of image layer information when analyzing image history, consuming a significant amount of memory and computing resources. Summary of the Invention

[0023] The purpose of this invention is to overcome the above-mentioned technical deficiencies and provide an automatic generation method, sending method and detection method for security test emails, so as to solve the problem of low automation in network penetration testing through email in related technologies.

[0024] To achieve the above-mentioned technical objectives, the present invention adopts the following technical solution:

[0025] According to a first aspect of the present invention, a method for determining mirror dependency is provided, comprising:

[0026] Metadata of the target business image is obtained from the image repository through the application interface of the image repository;

[0027] Extract the layer construction information and layer identifier of each layer of the target business image from the metadata;

[0028] The layer identifier and layer construction information of each layer are concatenated, and the hash value of each concatenated layer is calculated separately.

[0029] The hash values ​​are concatenated according to the construction order of the image layers of the target business image to obtain a hash array;

[0030] If the hash array contains the hash value of the base image, it is determined that the current target business image has a mirror dependency relationship with the base image.

[0031] Preferably, the step of concatenating the hash values ​​according to the construction order of the image layers of the target business image to obtain a hash array is specifically as follows:

[0032] The hash values ​​of the target business image from the first layer to the Nth layer are concatenated in order to obtain the hash array of the Nth layer, where N≥2.

[0033] Preferably, if the hash array contains a hash value of the base image, then it is determined that the current target service image has a mirror dependency relationship with the base image, specifically as follows:

[0034] If any layer of the target business image has a hash value of the base image in its hash array, then it is determined that the current target business image has a dependency relationship with that base image.

[0035] Preferably, the hash value of the base image is calculated according to the following method, including:

[0036] The layer identifier and layer build information of each layer in the base image are concatenated, and the hash value of each concatenated layer is calculated separately.

[0037] The lowest layer of the base image is marked as the first layer. The hash values ​​of the first layer to the top layer of the base image are concatenated in order, and the resulting hash array is stored as the hash value of the entire base image.

[0038] According to a second aspect of the present invention, a mirror dependency determination system is provided, comprising:

[0039] The acquisition module is used to obtain the metadata of the target business image from the image repository through the application interface of the image repository;

[0040] The extraction module is used to extract the layer construction information and layer identifier of each layer of the target business image from the metadata;

[0041] The calculation module is used to concatenate the layer identifier and layer construction information of each layer, and calculate the hash value of each concatenated layer separately;

[0042] The concatenation module is used to concatenate the hash values ​​according to the construction order of the image layers of the target business image to obtain a hash array;

[0043] The judgment module is used to determine that if the hash value of the base image exists in the hash array, the current target business image has a mirror dependency relationship with the base image.

[0044] Preferably, the splicing module is specifically used for:

[0045] The hash values ​​of the target business image from the first layer to the Nth layer are concatenated in order to obtain the hash array of the Nth layer, where N≥2.

[0046] Preferably, the judgment module is specifically used for:

[0047] If any layer of the target business image has a hash value of the base image in its hash array, then it is determined that the current target business image has a dependency relationship with that base image.

[0048] According to a third aspect of the present invention, an electronic device is provided, comprising:

[0049] Processor and memory;

[0050] The memory is used to store programs, and the processor is used to run the programs to implement the methods described above.

[0051] Preferably, the electronic device is communicatively connected to the scanner;

[0052] The scanner is used to obtain the metadata of the target business image from the image repository through the application interface of the image repository.

[0053] According to a fourth aspect of the present invention, a computer-readable storage medium is provided storing computer-executable instructions for performing the above-described method.

[0054] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0055] By extracting the layer construction information and layer identifier of each layer of the target business image and calculating the hash value, the uniqueness of the hash value makes the image dependency analysis more accurate and faster. This enables accurate, fast and efficient analysis of the massive image dependencies in a large repository, which can significantly reduce the consumption of computing resources. This lays the foundation for automatically identifying the dependency relationship between the base image and the business image during the subsequent image construction process, as well as accurately identifying the business image that needs to be repaired when the base image changes. Attached Figure Description

[0056] Figure 1This is a flowchart illustrating a method for determining mirror dependency relationships according to an exemplary embodiment;

[0057] Figure 2 This is a flowchart illustrating a method for determining mirror dependency relationships according to another exemplary embodiment;

[0058] Figures 3A to 3D This is a flowchart illustrating a method for generating a unique identifier for a base image layer according to an exemplary embodiment;

[0059] Figure 4 This is a flowchart illustrating a method for generating a unique layer identifier for a target service image according to an exemplary embodiment;

[0060] Figure 5 This is a schematic block diagram illustrating a mirror dependency determination system according to an exemplary embodiment. Detailed Implementation

[0061] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0062] Example 1

[0063] Figure 1 This is a flowchart illustrating a method for determining mirror dependency relationships according to an exemplary embodiment. See also... Figure 1 The method includes:

[0064] Step S11: Obtain the metadata of the target business image from the image repository through the application interface of the image repository;

[0065] Step S12: Extract the layer construction information and layer identifier of each layer of the target service image from the metadata;

[0066] Step S13: Concatenate the layer identifier and layer construction information of each layer, and calculate the hash value of each concatenated layer separately;

[0067] Step S14: Concatenate the hash values ​​according to the construction order of the image layers of the target business image to obtain a hash array;

[0068] Step S15: If the hash value of the base image exists in the hash array, it is determined that the current target business image has a mirror dependency relationship with the base image.

[0069] It should be noted that, in practice, the technical solution provided in this embodiment is loaded and runs on an electronic device. The electronic device includes, but is not limited to, tablet computers, computers, and smartphones.

[0070] The application interface (API) of the image repository in step S11 is the programmatic access interface provided by the image repository (such as Docker Hub, Harbor, Quay, etc.). Through these interfaces, users or programs can remotely operate the image repository and perform the following functions:

[0071] Pull image: Download the image to your local machine.

[0072] Push image: Upload the local image to the repository.

[0073] Query metadata: Get detailed information about the image (such as name, tags, layer information, build time, etc.).

[0074] Management permissions: Control the access permissions of the image (e.g., public, private).

[0075] Delete image: Clean up images that are no longer needed.

[0076] The layer identifier in step S12 is a unique identifier for each layer in the image, which is usually generated from the contents of the file system of that layer (such as a SHA256 hash value).

[0077] The layer identifier (layerId) is used for dependency analysis and security scanning (e.g., tracking whether a layer contains vulnerabilities). Layers with the same content always have the same hash value. The layer identifier (layerId) is immutable and will not change once generated.

[0078] If the technical solution provided in this embodiment relies solely on the layer identifier (layerId) to determine image dependencies, the following risks may exist:

[0079] Assuming that base image A and image B are both three-layered and each layer has the same content, then each layer will correspond to the same layerId. Business image C is four-layered. When it is necessary to determine which base image business image C depends on, since base image A and image B have the same layerId, it is impossible to accurately determine which base image business image C depends on.

[0080] Docker history is the metadata generated for each layer in an image during the build process. It records technical details such as how the layer was generated, its dependencies, and file system changes. It is crucial data for analyzing image dependencies, optimizing the build process, and performing security scans.

[0081] If the technical solution provided in this embodiment relies solely on layer build information (Docker history) to determine image dependencies, the following risks may exist:

[0082] Even with the same Dockerfile, the images built at different times may be different.

[0083] For example, a certain layer of a business image might use the `apt-get update` command. If this command is executed at different times, the updated content will be different, resulting in different layer files. Therefore, even with the same Dockerfile, executing it at different times can produce different images, making simple comparisons based on layer build information unreliable.

[0084] The `apt-get update` command updates the system's package index (similar to refreshing the App Store list, the contents of which may change), fetching a list of currently available software packages. These lists are obtained from configured software repositories (usually online mirror servers). The package list, available package versions, or package content in the repositories may change at different times when this command is executed. For example:

[0085] • New versions of software packages: After running apt-get update, the software repositories may contain new versions of software packages, which may result in different versions of software being installed.

[0086] • Package removal or replacement: Some packages may be removed or replaced with other versions at some point, which can also lead to differences between images built at different times.

[0087] It is understood that the technical solution provided in this embodiment extracts the layer construction information and layer identifier of each layer of the target business image and calculates the hash value. Due to the uniqueness of the hash value, the image dependency analysis is more accurate and faster. It realizes accurate, fast and efficient analysis of massive image dependencies in a large warehouse, which can significantly reduce the consumption of computing resources. It lays the foundation for automatically identifying the dependency relationship between the base image and the business image in the subsequent image construction process, and for accurately identifying the business image that needs to be repaired when the base image changes.

[0088] In practice, step S13, concatenating the hash values ​​according to the construction order of the image layers of the target business image to obtain a hash array, specifically involves:

[0089] The hash values ​​of the target business image from the first layer to the Nth layer are concatenated in order to obtain the hash array of the Nth layer, where N≥2.

[0090] See Figure 4 The target business image is named Bizimage and has four layers. First, the layer identifier and layer construction information of each layer are calculated using MD5 and then concatenated to obtain the hash value of the second layer: MD5(hash value of the first layer + hash value of the second layer). The same process is followed for each subsequent layer.

[0091] Preferably, if the hash array contains a hash value of the base image, then it is determined that the current target service image has a mirror dependency relationship with the base image, specifically as follows:

[0092] If any layer of the target business image has a hash value of the base image in its hash array, then it is determined that the current target business image has a dependency relationship with that base image.

[0093] See Figures 3A to 3D The hash value of the base image is calculated according to the following methods:

[0094] The layer identifier and layer build information of each layer in the base image are concatenated, and the hash value of each concatenated layer is calculated separately.

[0095] The lowest layer of the base image is marked as the first layer. The hash values ​​of the first layer to the top layer of the base image are concatenated in order, and the resulting hash array is stored as the hash value of the entire base image.

[0096] See Figures 3A to 3D There are two base images, named BaseImage1 and BaseImage2. The layer ID (layerId) and build history information (Docker history) of each image are concatenated in a fixed way, and the MD5 hash of each layer is calculated. Then, all the MD5 hashes are concatenated to obtain the correspondence between the MD5 hashes of all layers in the base image and the base image itself.

[0097] Example 2

[0098] Figure 2 This is a flowchart illustrating a method for determining mirror dependencies according to another exemplary embodiment, see [link to flowchart]. Figure 2 The method includes:

[0099] Step S21: Obtain the metadata of the target business image from the image repository through the application interface of the image repository;

[0100] Step S22: Extract the layer construction information and layer identifier of each layer of the target service image from the metadata;

[0101] Step S23: Concatenate the layer identifier and layer construction information of each layer, and calculate the hash value of each concatenated layer separately;

[0102] Step S24: Concatenate the hash values ​​from the first layer to the Nth layer of the target service image in order to obtain the hash array of the Nth layer, where N≥2;

[0103] Step S25: If the hash array layer of any layer of the target business image contains the hash value of the base image, then it is determined that the current target business image has an image dependency relationship with the base image.

[0104] It should be noted that, in practice, the technical solution provided in this embodiment is loaded and runs on an electronic device. The electronic device includes, but is not limited to, tablet computers, computers, and smartphones.

[0105] In practical application, the applicant also verified the image dependency determination method provided in this embodiment. Compared with existing technical solutions, the technical solution provided in this embodiment has significant improvements in efficiency and memory usage. Assuming we need to analyze a repository containing 100,000 images, of which 1,000 are base images, the traditional Docker image history analysis algorithm will be referred to as Method 1, while the algorithm proposed in this paper will be referred to as Method 2. The two algorithms are compared below:

[0106] 1. Speed ​​comparison:

[0107] Assume that determining whether one image is built on top of another takes 10 milliseconds. Using Method 1, 100 million comparisons are needed, taking approximately 106 seconds in total. Method 2, however, only requires 100,000 comparisons, taking approximately 103 seconds in total, demonstrating a significant improvement in efficiency.

[0108] 2. Memory comparison:

[0109] Assuming each image has an average of 10 layers, and the build information and layerId of each layer occupy an average of 300 bytes. After using Method 2, the calculated hash value is fixed at 16 bytes. Using Method 1 to read the layer information of 100,000 images requires approximately 300MB of memory; while using Method 2, only about 10MB of memory is needed, which is about 1 / 30 of Method 1.

[0110] As can be seen, the technical solution provided in this embodiment can quickly and accurately determine the dependencies between images in a repository. This solution not only reduces the consumption of memory and computing resources, but also significantly improves the efficiency of analysis due to the use of hash value comparison, making it particularly suitable for dependency analysis of large-scale image repositories.

[0111] It is understood that the technical solution provided in this embodiment extracts the layer construction information and layer identifier of each layer of the target business image and calculates the hash value. Due to the uniqueness of the hash value, the image dependency analysis is more accurate and faster. It realizes accurate, fast and efficient analysis of massive image dependencies in a large warehouse, which can significantly reduce the consumption of computing resources. It lays the foundation for automatically identifying the dependency relationship between the base image and the business image in the subsequent image construction process, and for accurately identifying the business image that needs to be repaired when the base image changes.

[0112] Example 3

[0113] Figure 5 This is a schematic block diagram illustrating a mirror dependency determination system 100 according to an exemplary embodiment. See also... Figure 5 The system 100 includes:

[0114] The acquisition module 101 is used to obtain the metadata of the target business image from the image repository through the application interface of the image repository;

[0115] Extraction module 102 is used to extract the layer construction information and layer identifier of each layer of the target business image from the metadata;

[0116] The calculation module 103 is used to concatenate the layer identifier and layer construction information of each layer, and calculate the hash value of each concatenated layer respectively;

[0117] The splicing module 104 is used to splice the hash values ​​according to the construction order of the image layers of the target business image to obtain a hash array;

[0118] The judgment module 105 is used to determine that the current target business image has a mirror dependency relationship with the base image if the hash value of the base image exists in the hash array.

[0119] Preferably, the splicing module 104 is specifically used for:

[0120] The hash values ​​of the target business image from the first layer to the Nth layer are concatenated in order to obtain the hash array of the Nth layer, where N≥2.

[0121] Preferably, the judgment module 105 is specifically used for:

[0122] If any layer of the target business image has a hash value of the base image in its hash array, then it is determined that the current target business image has a dependency relationship with that base image.

[0123] It should be noted that, in practice, the technical solution provided in this embodiment is loaded and runs on an electronic device. The electronic device includes, but is not limited to, tablet computers, computers, and smartphones.

[0124] The specific implementation methods of each module are described in the relevant steps of Embodiment 1, and will not be repeated in this embodiment.

[0125] It is understood that the technical solution provided in this embodiment extracts the layer construction information and layer identifier of each layer of the target business image and calculates the hash value. Due to the uniqueness of the hash value, the image dependency analysis is more accurate and faster. It realizes accurate, fast and efficient analysis of massive image dependencies in a large warehouse, which can significantly reduce the consumption of computing resources. It lays the foundation for automatically identifying the dependency relationship between the base image and the business image in the subsequent image construction process, and for accurately identifying the business image that needs to be repaired when the base image changes.

[0126] Example 4

[0127] An electronic device according to an exemplary embodiment includes:

[0128] Processor and memory;

[0129] The memory is used to store programs, and the processor is used to run the programs to implement the methods described above.

[0130] Preferably, the electronic device is communicatively connected to the scanner;

[0131] The scanner is used to obtain the metadata of the target business image from the image repository through the application interface of the image repository.

[0132] It is understood that the technical solution provided in this embodiment extracts the layer construction information and layer identifier of each layer of the target business image and calculates the hash value. Due to the uniqueness of the hash value, the image dependency analysis is more accurate and faster. It realizes accurate, fast and efficient analysis of massive image dependencies in a large warehouse, which can significantly reduce the consumption of computing resources. It lays the foundation for automatically identifying the dependency relationship between the base image and the business image in the subsequent image construction process, and for accurately identifying the business image that needs to be repaired when the base image changes.

[0133] Example 5

[0134] A computer-readable storage medium according to an exemplary embodiment is shown storing computer-executable instructions for performing the method described above.

[0135] It is understood that the technical solution provided in this embodiment extracts the layer construction information and layer identifier of each layer of the target business image and calculates the hash value. Due to the uniqueness of the hash value, the image dependency analysis is more accurate and faster. It realizes accurate, fast and efficient analysis of massive image dependencies in a large warehouse, which can significantly reduce the consumption of computing resources. It lays the foundation for automatically identifying the dependency relationship between the base image and the business image in the subsequent image construction process, and for accurately identifying the business image that needs to be repaired when the base image changes.

[0136] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0137] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0138] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0139] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0140] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0141] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0142] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for determining mirror dependency relationships, characterized in that, include: Metadata of the target business image is obtained from the image repository through the application interface of the image repository; Extract the layer construction information and layer identifier of each layer of the target business image from the metadata; The layer identifier and layer construction information of each layer are concatenated, and the hash value of each concatenated layer is calculated separately. The hash values ​​are concatenated according to the construction order of the image layers of the target business image to obtain a hash array; If the hash array contains the hash value of the base image, it is determined that the current target business image has a mirror dependency relationship with the base image. The hash value of the base image is calculated using the following methods: The layer identifier and layer build information of each layer in the base image are concatenated, and the hash value of each concatenated layer is calculated separately. The lowest layer of the base image is marked as the first layer. The hash values ​​of the first layer to the top layer of the base image are concatenated in order, and the resulting hash array is stored as the hash value of the entire base image.

2. The method according to claim 1, characterized in that, The hash values ​​are concatenated according to the construction order of the image layers of the target business image to obtain a hash array, specifically as follows: The hash values ​​of the target business image from the first layer to the Nth layer are concatenated in order to obtain the hash array of the Nth layer, where N≥2.

3. The method according to claim 1, characterized in that, If the hash array contains the hash value of the base image, then it is determined that the current target service image has a mirror dependency relationship with the base image, specifically: If any layer of the target business image has a hash value of the base image in its hash array, then it is determined that the current target business image has a dependency relationship with that base image.

4. A mirror dependency determination system, characterized in that, include: The acquisition module is used to obtain the metadata of the target business image from the image repository through the application interface of the image repository; The extraction module is used to extract the layer construction information and layer identifier of each layer of the target business image from the metadata; The calculation module is used to concatenate the layer identifier and layer construction information of each layer, and calculate the hash value of each concatenated layer separately; The concatenation module is used to concatenate the hash values ​​according to the construction order of the image layers of the target business image to obtain a hash array; The judgment module is used to determine that if the hash value of the base image exists in the hash array, the current target business image has a mirror dependency relationship with the base image. The hash value of the base image is calculated using the following methods: The layer identifier and layer build information of each layer in the base image are concatenated, and the hash value of each concatenated layer is calculated separately. The lowest layer of the base image is marked as the first layer. The hash values ​​of the first layer to the top layer of the base image are concatenated in order, and the resulting hash array is stored as the hash value of the entire base image.

5. The system according to claim 4, characterized in that, The splicing module is specifically used for: The hash values ​​of the target business image from the first layer to the Nth layer are concatenated in order to obtain the hash array of the Nth layer, where N≥2.

6. The system according to claim 4, characterized in that, The judgment module is specifically used for: If any layer of the target business image has a hash value of the base image in its hash array, then it is determined that the current target business image has a dependency relationship with that base image.

7. An electronic device, characterized in that, include: Processor and memory; The memory is used to store a program, and the processor is used to run the program to implement the method according to any one of claims 1-3.

8. The electronic device according to claim 7, characterized in that, The electronic device is communicatively connected to the scanner; The scanner is used to obtain the metadata of the target business image from the image repository through the application interface of the image repository.

9. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used to perform the method as described in any one of claims 1 to 3.

Images