Method and apparatus for constructing a container image

Abstract

This disclosure proposes a method and apparatus for building a container image. The method includes: obtaining a container image contents list associated with a target application; running the target application in a test environment based on the container image contents list; generating a runtime behavior graph associated with each first file based on the runtime behavior data of the target application; and building a container image of the target application based on the runtime behavior graph and the container image contents list. By combining the actual access sequence and access dependencies of each file indicated by the runtime behavior graph, image building can place low-frequency and stable files in the lower image layer and high-frequency and frequently used files in the upper layer, thereby reducing I / O overhead during container startup. While maintaining environment independence, it also allows for updating only the upper image when business code changes, without needing to retransmit third-party dependencies, significantly reducing build time and network transmission volume, and improving the overall delivery efficiency of cloud-native applications.

Description

Technical Field

[0001] This disclosure relates to the field of microservices technology, and in particular to a method and apparatus for building container images. Background Technology

[0002] With the widespread adoption of microservice architecture and cloud-native technologies, containers have become the de facto standard for application deployment. In this context, how to efficiently build container images has become a key factor affecting continuous delivery efficiency and cloud computing resource costs. Related technologies mainly employ the following methods to build container images: On the one hand, relying on external application servers to deploy archive packages presents problems such as high environment coupling and long release cycles, making it difficult to meet the needs of rapid microservice iteration; on the other hand, using an integrated archive package model, such as packaging application code, dependency libraries, and resource configurations into a single executable file, achieves environment-independent deployment. However, this approach results in bloated image sizes, requiring the entire image to be rebuilt and transferred even with only minor modifications to business code, severely restricting the efficiency of container image builds. Summary of the Invention

[0003] This disclosure provides a method and apparatus for building container images, thereby at least partially addressing one of the technical problems in related technologies. The technical solution of this disclosure is as follows:

[0004] According to a first aspect of the present disclosure, a method for constructing a container image is provided, comprising: obtaining a container image contents manifest associated with a target application; wherein the first files indicated by the container image contents manifest include: an executable file compiled from the source code files of the target application, a configuration file for constructing the target application, and third-party dependency files that the target application depends on; running the target application in a test environment based on the container image contents manifest; generating a runtime behavior graph associated with each of the first files based on runtime behavior data of the target application; wherein the runtime behavior graph is used to indicate the access sequence of each of the first files and the runtime access dependencies between the files; and constructing a container image of the target application based on the runtime behavior graph and the container image contents manifest.

[0005] According to a second aspect of the present disclosure, a container image building apparatus is provided, comprising: an acquisition module, configured to acquire a container image contents manifest associated with a target application; wherein the first files indicated by the container image contents manifest include: an executable file compiled from the source code files of the target application, a configuration file for building the target application, and third-party dependency files that the target application depends on; a running module, configured to run the target application in a test environment based on the container image contents manifest; a generation module, configured to generate a runtime behavior graph associated with each of the first files based on runtime behavior data of the target application; wherein the runtime behavior graph is used to indicate the access sequence of each of the first files and the runtime access dependencies between the files; and a building module, configured to build a container image of the target application based on the runtime behavior graph and the container image contents manifest.

[0006] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement a container image construction method as described in the first aspect of the present disclosure.

[0007] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform a container image construction method as described in the first aspect of the present disclosure.

[0008] According to a fifth aspect of the present disclosure, a computer program product is provided, comprising: a computer program that, when executed by a processor, implements the container image construction method as described in the first aspect of the present disclosure.

[0009] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects: In this technical solution, by obtaining the container image content list associated with the target application, the scope of files to be packaged is precisely defined, avoiding the inclusion of irrelevant files and effectively controlling the image size. Furthermore, the application is run in a test environment and runtime behavior data is collected to generate a runtime behavior graph, which is used to identify the actual access sequence and runtime access dependencies of each file. Finally, the container image of the target application is dynamically constructed by combining the runtime behavior graph and the content list. That is, image construction is performed by combining the actual access sequence and runtime access dependencies of each file, which allows low-frequency and stable files to be placed in the lower image layer and high-frequency startup files to be placed in the upper layer, thereby reducing I / O during container startup. Overhead; While maintaining environment independence, it ensures that only the upper-layer image needs to be updated when business code changes, without retransmitting third-party dependencies, significantly reducing build time and network traffic, and improving the overall delivery efficiency of cloud-native applications; Among them, the runtime behavior graph is generated from the actual access data of each first file, so that the construction of container images no longer relies on static empirical rules, but is based on real runtime load. Therefore, based on the runtime behavior graph, high-frequency startup files, low-frequency configuration files, and strongly related file groups at runtime can be accurately identified, further improving the accuracy of the layering strategy, significantly reducing redundant transmission and storage overhead caused by full rebuild, and also effectively reducing the impact of container cold starts. I / O latency; furthermore, when building the container image of the target application, a container image layering strategy can be generated based on the runtime behavior graph and the container image content list. That is, according to the access time distribution and access frequency of each first file revealed by the runtime behavior graph, the first files are clustered and grouped to form at least one file group; then, combined with the preset image layer number constraint, the mapping relationship from each group to the specific image layer is optimized, thereby generating the final container image layering strategy. This strategy effectively realizes the centralized storage of frequently co-occurring and runtime-dependent files in the same image layer, while avoiding the splitting of frequently interacting files during execution into different layers, significantly reducing cross-layer I / O operations, and improving container startup efficiency and runtime performance.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0012] Figure 1 This is a flowchart illustrating the method for building a container image according to the first embodiment of this disclosure; Figure 2This is a flowchart illustrating the method for building a container image according to the second embodiment of this disclosure; Figure 3 This is a flowchart illustrating the method for building a container image according to the third embodiment of this disclosure; Figure 4 This is a flowchart illustrating the method for building a container image according to the fourth embodiment of this disclosure; Figure 5 This is a flowchart illustrating the method for building a container image according to the fifth embodiment of this disclosure; Figure 6 This is a schematic diagram illustrating the principle of the container image construction method shown in the embodiments of this disclosure. Figure 7 This is a schematic diagram of the structure of the container image building apparatus shown in the sixth embodiment of this disclosure; Figure 8 This is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of the present disclosure. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0014] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0015] It should be noted that the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in the technical solution disclosed herein are all carried out with the consent of the user, and all comply with the provisions of relevant laws and regulations, and do not violate public order and good morals.

[0016] To improve container image caching efficiency, the industry has introduced a layered build mechanism. This technology employs static rules based on file types for layering. For example, third-party dependency JAR packages are placed in the dependency layer, project configuration files and other resources in the resource layer, compiled user code in the application class layer, and the Spring Boot loader in a separate layer. This method can reuse the underlying dependency layer when only business code changes, reducing image transfer volume. However, files frequently and sequentially accessed during startup may be scattered across multiple layers, resulting in a large amount of cross-layer random I / O during container startup. This hinders effective utilization of the operating system cache, causing cold start performance to fall short of optimal levels.

[0017] Furthermore, layering decisions are typically based on coarse-grained partitioning according to file type or build stage, failing to detect runtime non-explicit dependency behaviors such as reflection, dynamic proxies, and configuration-driven loading. This leads to frequent cross-accesses to files in different image layers, disrupting I / O locality and significantly increasing disk read overhead and startup latency. Secondly, in scenarios sensitive to cold starts, general layering schemes struggle to centrally arrange high-frequency files on the startup critical path, becoming a key bottleneck restricting response speed and resource elasticity. In addition, because the image layer organization does not conform to the spatiotemporal locality principle of program execution, the operating system's page cache prefetching mechanism cannot be effectively hit, further weakening runtime performance.

[0018] To address any of the above-mentioned problems, this disclosure proposes a method and apparatus for constructing container images.

[0019] The method and apparatus for building container images according to embodiments of the present disclosure are described below with reference to the accompanying drawings.

[0020] Figure 1 This is a flowchart illustrating the method for building a container image as shown in the first embodiment of this disclosure.

[0021] It should be noted that, in this embodiment of the disclosure, the container image building method is configured in a container image building apparatus as an example. This container image building apparatus can be applied to an electronic device so that the electronic device can perform the container image building function.

[0022] like Figure 1 As shown, the method for building this container image includes: Step 110: Obtain the list of contents of the container image associated with the target application.

[0023] The first file indicated by the container image manifest includes: an executable file compiled from the source code files of the target application, a configuration file used to build the target application, and third-party dependency files that the target application depends on.

[0024] To avoid packaging irrelevant content such as temporary files, logs, and test code into the image, one possible approach is to identify all files that need to be packaged into the image before building the image and generate a container image contents manifest. The first file indicated by the container image contents manifest includes: the executable file compiled from the source code, the configuration file used to build the target application, and the project resource files of the project to which the target application belongs.

[0025] In some embodiments, such as Figure 2 As shown, the container image manifest can be generated using the following steps: Step 1101: Obtain the executable file of the target application, the configuration file used to build the target application, and the project resource files of the project to which the target application belongs.

[0026] An executable file is obtained by compiling the source code file of the target application.

[0027] To improve the integrity of image building, one possible approach is to compile source code files (such as Java class files) to generate executable files representing application logic, such as bytecode .class files, JAR packages, or native binary files. Simultaneously, configuration files (e.g., pom.xml) used to build the target application are extracted. These configuration files define the target application's project metadata, compilation dependencies, plugin configurations, etc. Furthermore, project resource files, such as application.yml, logback.xml, the static resource directory static / , and template files, are collected.

[0028] Step 1102: Obtain the third-party dependency files that the target application depends on, based on the third-party dependency information declared in the configuration file.

[0029] To avoid image unavailability due to missing dependencies or version conflicts, one possible approach is to parse the dependencies declared in the build configuration file and automatically download the third-party dependency files that the target application depends on using a dependency management tool.

[0030] Step 1103: Generate a container image contents list based on the archive paths and filenames of the executable file, third-party dependency files, and project resource files.

[0031] To facilitate accurate location of the files to be packaged, after obtaining all the files to be packaged, it is necessary to further determine the archive path of each file in the target application archive package, and generate a container image content list based on the archive path and file name.

[0032] Step 120: Run the target application in the test environment based on the container image manifest.

[0033] To improve the accuracy of image building, after obtaining a complete list of files to be packaged, the target application is started and run in a test environment. It should be noted that the test environment needs to reproduce the real running scenario to ensure the authenticity of the collected file access behavior. The running process may include stages such as startup initialization, API calls, and resource loading.

[0034] Step 130: Generate a runtime behavior map associated with each first file based on the runtime behavior data of the target application.

[0035] The runtime behavior graph is used to indicate the access sequence of each first file and the runtime access dependencies between files.

[0036] Furthermore, during application operation, access events for each first file can be recorded, including access timestamps and call contexts. These data can then be modeled into a directed graph structure to generate a runtime behavior graph. For example, nodes in the runtime behavior graph represent files, edges represent the access order between files, and edge weights can reflect co-occurrence frequency or temporal proximity. The runtime behavior graph can be used to indicate the access sequence of each first file and the runtime access dependencies between files. Thus, by parsing the runtime behavior graph, the access sequence and dependencies of files can be obtained, providing a basis for subsequent image layering.

[0037] In some embodiments, such as Figure 3 As shown, step 130 may include the following steps: Step 1301: Determine the actual access data of each first file based on the runtime behavior data of the target application.

[0038] The actual access data includes at least one of the following: access order, access frequency, and access timestamp of the corresponding first file.

[0039] To obtain the behavioral characteristics of each file in a real-world running scenario, one possible approach is to extract the actual access data of the first file from the behavior logs of the target application in the test environment. The actual access data may include at least one of the following: access order, access frequency, and access timestamp. Access order refers to the order in which the first file is loaded or read, access frequency refers to the number of times a file is accessed per unit time, and access timestamp refers to the specific time point when the first file is accessed.

[0040] Step 1302: Generate a runtime behavior graph of the target application based on the actual access data of each first file.

[0041] To clearly demonstrate the interactions and dependencies between files during the execution of the target application, one possible approach is to convert the actual access data of each first file into a runtime behavior graph.

[0042] As an example, each first file is used as a graph node; based on the actual access data of each first file, directed edges are established between the graph nodes corresponding to adjacent accessed first files, and the weight values ​​of the directed edges are determined; wherein, the directed edges are used to indicate the runtime access dependencies between files; and a runtime behavior graph is generated based on the directed edges and their weight values.

[0043] In other words, each first file in the container image's manifest is abstracted as a node in a graph. Based on the actual access data collected during the target application's test run, pairs of files accessed adjacently in time are identified. For each pair of adjacent first files, a directed edge is established between the corresponding graph nodes. The direction of this directed edge indicates the order of access; for example, if file A is accessed before file B, the direction of the directed edge is from A to B. Simultaneously, the weight value of the directed edge is determined based on the co-occurrence frequency of these files within a preset time window. This weight value can be used to indicate the strength of the association between files at runtime. Finally, all nodes, directed edges, and the weights of the directed edges together constitute a runtime behavior graph. The directed edges represent the runtime access dependencies between files, providing a decision-making basis for the subsequent layering of the container image.

[0044] Step 140: Build the container image of the target application based on the runtime behavior graph and the container image contents manifest.

[0045] As one possible implementation, based on the access sequence and dependency relationships in the runtime behavior graph, combined with the files to be packaged and the archive path in the manifest, the files are allocated in layers. For example, files with similar access patterns, frequent consecutive access, or strong runtime dependencies are grouped into the same image layer, while following the preset constraints on the number of image layers. Then, according to the build order from the bottom layer to the top layer, the files allocated to each layer are written to the corresponding intermediate directories and packaged in sequence to generate image layers, finally generating the optimized container image.

[0046] In some embodiments, such as Figure 4 As shown, step 140 may include the following steps: Step 1401: Generate a container image layering strategy based on the runtime behavior graph and the container image contents list.

[0047] The container image layering strategy is used to indicate the mapping relationship between each first file and its corresponding image layer.

[0048] It's important to understand that since the runtime behavior graph displays the access sequence, co-occurrence frequency, and dynamic dependencies of each file during application execution in a graph structure, and the container image manifest provides all files to be packaged and their logical paths within the archive, the files to be packaged can be clustered based on the runtime behavior graph and the container image manifest. For example, files with high-frequency, continuous access can be grouped into the same layer, or low-frequency, stable dependency libraries can be placed at the bottom layer. The final output container image layering strategy can be a mapping table, where each entry specifies which image layer the first file should be assigned to. Therefore, based on the container image layering strategy, the container image of the target application can be built, ensuring that the container image corresponds to the actual runtime behavior of the application. This can also significantly improve build efficiency, reduce network transmission overhead, and thus comprehensively enhance the delivery and execution performance of cloud-native applications.

[0049] In some embodiments, such as Figure 5 As shown, step 1401 may include the following steps: Step 14011: Determine the access time distribution and access frequency of each first file based on the runtime behavior graph.

[0050] To avoid the problem of traditional static layering being out of touch with actual runtime scenarios, as a possible implementation, the access time distribution and access frequency of each first file are extracted from the constructed runtime behavior graph. The access time distribution describes the time distribution of the file being accessed throughout the entire runtime process, and the access frequency indicates the number of times the file is read or loaded per unit time.

[0051] As an example, the access events and access timestamps corresponding to each first file are extracted from the runtime behavior graph; the access timestamps corresponding to each first file are arranged in chronological order to generate an access timestamp sequence for each first file; and the access time distribution and access frequency of each first file are determined based on the access timestamp sequence for each first file.

[0052] In other words, extracting the access events and access timestamps corresponding to each first file from the runtime behavior graph means obtaining the actual access records of the target application to each file during the test run and the specific time when the access occurred. Then, all access timestamps of the same file are arranged in chronological order to generate an access timestamp sequence for the same file. The access timestamp sequence can show the access trajectory of the same file throughout the entire test run. Furthermore, by statistically analyzing the access timestamp sequence, the number of accesses per unit time can be calculated, access concentration areas can be identified, and the access frequency and access time distribution of the file can be accurately determined.

[0053] Step 14012: Based on the access time distribution and access frequency of each first file, group each first file to obtain at least one file group.

[0054] In this case, the first file in the same file group is accessed multiple times and consecutively during the same time period of the target application's startup and execution process.

[0055] Furthermore, based on the access time distribution and access frequency of each first file, a clustering algorithm can be used to group the files. Specifically, the first files in the same file group are accessed multiple times and consecutively within the same time period during the startup and execution of the target application. For example, all files that are frequently and consecutively accessed within 0–800ms after application startup can be grouped into the first file group; similarly, files that repeatedly appear during the user login process can be grouped into the second file group.

[0056] Step 14013: Generate a container image layering strategy based on at least one file group and setting image layer constraints.

[0057] Furthermore, after obtaining the file groups, the final layering strategy needs to be generated by combining the set image layer number constraints. In other words, the container image layering strategy is used to assign each file in each file group to a target image layer, while satisfying the requirement that the total number of layers does not exceed the preset constraint.

[0058] As an example, with the goal of maximizing runtime correlation within each file group in at least one file group and minimizing cross-layer access overhead between different file groups, and with a set number of image layers as a constraint, the mapping relationship between each file and its corresponding image layer is solved; based on the mapping relationship between each file and its corresponding image layer, a container image layering strategy is generated.

[0059] In other words, with the optimization objectives of maximizing the runtime correlation within each file group and minimizing the cross-layer access overhead between different file groups, and with the number of mirror layers as a constraint, a combinatorial optimization problem is constructed to solve for the optimal mapping relationship from each file to the target mirror layer. That is, frequently co-occurring and strongly dependent files are stored together in the same layer, while frequently interacting files are avoided from being split into different mirror layers. At the same time, with the maximum number of mirror layers as a constraint, the optimal mapping relationship from each file to the target mirror layer is solved. This mapping relationship is used to indicate the specific mirror layer to which each file should belong.

[0060] Step 1402: Build the container image of the target application according to the container image layering strategy.

[0061] To improve the accuracy of container image building, one possible approach is to organize the files to be layered according to the assigned image layers based on the generated container image layering strategy, thereby generating a container image of the target application.

[0062] As an example, based on the container image layering strategy, the second files to be layered in each first file are copied to the intermediate directories corresponding to their respective target image layers; according to the preset image layer order, each intermediate directory is packaged into its corresponding image layer to generate a container image.

[0063] In other words, based on the generated container image layering strategy, the second files to be layered from the first file are organized according to the corresponding target image layers. For example, an independent intermediate directory is created for each target image layer. Then, according to the file-to-layer mapping relationship defined in the container image layering strategy, each second file is copied to the intermediate directory of the corresponding image layer. After the file layout is completed, each intermediate directory is packaged into an image layer in the preset order from the bottom layer to the top layer, and finally a complete container image is generated.

[0064] It should be noted that the second file to be layered is a subset of the files selected from all the first files in the container image content list, based on the runtime behavior graph and layering strategy, that need to participate in this image layer allocation and packaging. For example, the second file to be layered may be a frequently changing file, a file whose content has changed or is being introduced for the first time, or a subset of files that have been determined by the container image layering strategy to be allocated to the image layer that needs to be rebuilt.

[0065] The container image construction method of this disclosure obtains a container image content list associated with the target application, accurately defines the range of files to be packaged, avoids the inclusion of irrelevant files, and effectively controls the image size. Furthermore, it runs the application in a test environment and collects runtime behavior data to generate a runtime behavior graph, which is used to identify the actual access sequence and runtime access dependencies of each file. Finally, it dynamically constructs the container image of the target application by combining the runtime behavior graph and the content list. That is, it builds the image by combining the actual access sequence and runtime access dependencies of each file, which allows low-frequency and stable files to be placed in the lower image layer and high-frequency startup files to be placed in the upper layer, thereby reducing I / O overhead during container startup. While maintaining environment independence, it ensures that only the upper image needs to be updated when only business code changes, without the need to retransmit third-party dependencies, significantly reducing build time and network transmission volume, and improving the overall delivery efficiency of cloud-native applications.

[0066] Based on any of the above embodiments, such as Figure 6 As shown, the container image construction method of this disclosure embodiment may further include the following steps: Step 1: Static Analysis and Initialization (1) Input: The application's source code (e.g., Java), configuration file (pom.xml), and all third-party dependencies; (2) Process: The build tool (such as Maven) first compiles the source code, generating all the .class files. Then it parses the project dependency tree and collects the actual JAR packages of all dependencies. It also collects the project resource files (such as application.yml, static / , templates / ). (3) Output: Generate an initial file list containing all files that need to be packaged and their path information; Step 2: Runtime Behavioral Data Acquisition (1) Input: The above initial file list, and the complete integration test suite of the project; (2) Process: In the test environment, the application is launched using Java Agent technology. This Agent is the core of data collection. Run a complete integration test suite to ensure that all startup paths and business functions are covered as much as possible. JavaAgent monitors and records in real time: Class loading events: Records the timestamp of each class being loaded, its class loader, and the source JAR package. File access events: Records all read operations on resource files (such as .xml, .properties) and their timestamps; Method call hotspots (optional): Records methods that are frequently called during the startup phase for finer-grained optimization; (3) Output: Generate a runtime behavior graph (e.g., in JSON format), which is a large dataset containing time series data, recording the access order, frequency and correlation of all files; Step 3: Intelligent Hierarchical Strategy Generation Input: Initial file list and runtime behavior graph; Process: Data points (such as a class) in runtime behavior are mapped back to specific files in the initial manifest for data association. Machine learning clustering algorithms (such as K-Means) are used to cluster the files; primarily based on the time and frequency of file loading / access, files frequently and continuously accessed within the same time period are clustered into the same group; the goal is to maximize the correlation between files within a group and minimize cross-access between different groups; based on the clustering results and combined with container best practices (controlling the number of layers), logical layers are defined; for example: startup core layer, mid-term business layer, lazy loading layer, and static resource layer; the algorithm ultimately assigns a target layer to each file. Output: Generate container image layering strategy, such as a layering configuration file (e.g., layers.json), which precisely describes which image layer each file should belong to; Step 4: Image Building and Deployment (1) Input: layered configuration file, compiled application file; (2) Process: A customized build plugin (such as the Maven Plugin) reads the layers.json file. Based on the instructions in the configuration, the plugin copies the file to different directories, each representing a final image layer. The plugin calls the container or Jib API to package these directories sequentially, building the final container image. The image is then pushed to the repository and deployed to the production environment. (3) Output: A layered container image that has been intelligently optimized.

[0067] It's worth noting that when this image runs, the physical arrangement of its files on disk closely matches the application's runtime access patterns. This allows the operating system to perform efficient sequential prefetching, quickly loading the entire layer into the memory cache, thus significantly reducing disk I / O wait time and achieving a qualitative leap in container cold start speed. Simultaneously, due to the optimized layering strategy, each code change only affects the smallest layer, resulting in a substantial improvement in deployment efficiency.

[0068] Corresponding to the container image building method provided in the above embodiments, this disclosure also provides a container image building apparatus. Since the container image building apparatus provided in this disclosure corresponds to the container image building method provided in the above embodiments, the implementation method of the container image building method is also applicable to the container image building apparatus provided in this disclosure, and will not be described in detail in this disclosure.

[0069] Figure 7 This is a schematic diagram of the structure of the container image building apparatus shown in the sixth embodiment of this disclosure.

[0070] like Figure 7 As shown, the container image building apparatus 700 includes: an acquisition module 710, a running module 720, a generation module 730, and a building module 740.

[0071] The acquisition module 710 is used to acquire a container image manifest associated with the target application; wherein the first files indicated by the container image manifest include: an executable file compiled from the source code files of the target application, a configuration file for building the target application, and third-party dependency files that the target application depends on; the running module 720 is used to run the target application in a test environment based on the container image manifest; the generation module 730 is used to generate a runtime behavior graph associated with each first file based on the runtime behavior data of the target application; wherein the runtime behavior graph is used to indicate the access sequence of each first file and the runtime access dependency relationship between each file; and the building module 740 is used to build a container image of the target application based on the runtime behavior graph and the container image manifest.

[0072] As one possible implementation, the build module 740 is used to generate a container image layering strategy based on the runtime behavior graph and the container image contents manifest; wherein, the container image layering strategy is used to indicate the mapping relationship between each first file and its corresponding image layer; and the container image of the target application is built according to the container image layering strategy.

[0073] As one possible implementation, the construction module 740 is used to determine the access time distribution and access frequency of each first file based on the runtime behavior graph; group each first file according to the access time distribution and access frequency of each first file to obtain at least one file group; wherein, the first file in the same file group is accessed multiple times and continuously during the same time period of the target application's startup and execution process; and generate a container image layering strategy based on at least one file group and setting image layer constraints.

[0074] As one possible implementation, module 740 is used to extract access events and access timestamps corresponding to each first file from the runtime behavior graph; arrange the access timestamps corresponding to each first file in chronological order to generate an access timestamp sequence for each first file; and determine the access time distribution and access frequency of each first file based on the access timestamp sequence for each first file.

[0075] As one possible implementation, the building module 740 is used to solve the mapping relationship between each file and its corresponding image layer with the goal of maximizing the runtime correlation within each file group in at least one file group and minimizing the cross-layer access overhead between different file groups, and with a set number of image layers as a constraint; and to generate a container image layering strategy based on the mapping relationship between each file and its corresponding image layer.

[0076] As one possible implementation, the build module 740 is used to copy the second files to be layered in each first file to the intermediate directories corresponding to their respective target image layers, based on the container image layering strategy; and to package each intermediate directory into its corresponding image layer according to the preset image layer order to generate a container image.

[0077] As one possible implementation, the generation module 730 is used to determine the actual access data of each first file based on the runtime behavior data of the target application; wherein the actual access data includes at least one of the access order, access frequency and access timestamp of the corresponding first file; and to generate a runtime behavior map of the target application based on the actual access data of each first file.

[0078] As one possible implementation, the generation module 730 is used to treat each first file as a graph node; based on the actual access data of each first file, it establishes directed edges between the graph nodes corresponding to adjacent accessed first files and determines the weight values ​​of the directed edges; wherein, the directed edges are used to indicate the runtime access dependencies between files; and a runtime behavior graph is generated based on the directed edges and their weight values.

[0079] As one possible implementation, the generation module 730 is also used to obtain the executable file of the target application, the configuration file for building the target application, and the project resource files of the project to which the target application belongs; wherein, the executable file is obtained by compiling the source code file of the target application; according to the third-party dependency information declared in the configuration file, the third-party dependency files that the target application depends on are obtained; and the container image content list is generated according to the archive path and file name of the executable file, the third-party dependency files, and the project resource files.

[0080] The container image building apparatus of this disclosure obtains a container image content list associated with the target application, accurately defines the range of files to be packaged, avoids the inclusion of irrelevant files, and effectively controls the image size. Furthermore, it runs the application in a test environment and collects runtime behavior data to generate a runtime behavior graph, which is used to identify the actual access sequence and runtime access dependencies of each file. Finally, it dynamically builds the container image of the target application by combining the runtime behavior graph and the content list. That is, it builds the image by combining the actual access sequence and runtime access dependencies of each file, which allows low-frequency and stable files to be placed in the lower image layer and high-frequency startup files to be placed in the upper layer, thereby reducing I / O overhead during container startup. While maintaining environment independence, it ensures that only the upper image needs to be updated when only business code changes, without the need to retransmit third-party dependencies, significantly reducing build time and network transmission volume, and improving the overall delivery efficiency of cloud-native applications.

[0081] In an exemplary embodiment, an electronic device is also proposed.

[0082] The electronic devices include: processor; Memory used to store processor-executable instructions; The processor is configured to execute instructions to implement the container image construction method as proposed in any of the foregoing embodiments.

[0083] As an example, Figure 8 This is a schematic diagram of the structure of an electronic device 800 as shown in an exemplary embodiment of this disclosure, as follows: Figure 8 As shown, the above-mentioned electronic device 800 may further include: The system includes a memory 810 and a processor 820, and a bus 830 connecting different components (including the memory 810 and the processor 820). The memory 810 stores a computer program, and when the processor 820 executes the program, it implements the container image construction method described in this embodiment of the present disclosure.

[0084] Bus 830 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0085] Electronic device 800 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 800, including volatile and non-volatile media, removable and non-removable media.

[0086] The memory 810 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 840 and / or cache 850. The electronic device 800 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 860 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 8 Not shown; usually referred to as a "hard drive"). Although Figure 8Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 830 via one or more data media interfaces. Memory 810 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this disclosure.

[0087] A program / utility 880 having a set (at least one) of program modules 870 may be stored, for example, in memory 810. Such program modules 870 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 870 typically perform the functions and / or methods described in the embodiments of this disclosure.

[0088] Electronic device 800 can also communicate with one or more external devices 890 (e.g., keyboard, pointing device, display 891, etc.), and with one or more devices that enable a user to interact with electronic device 800, and / or with any device that enables electronic device 800 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 892. Furthermore, electronic device 800 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 893. As shown, network adapter 893 communicates with other modules of electronic device 800 via bus 830. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0089] The processor 820 performs various functional applications and data processing by running programs stored in the memory 810.

[0090] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the container image construction method of this disclosure embodiment, and will not be repeated here.

[0091] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory including instructions, which can be executed by a processor of an electronic device to complete the container image construction method proposed in any of the above embodiments. Optionally, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0092] In an exemplary embodiment, a computer program product is also provided, including a computer program / instructions, characterized in that the computer program / instructions, when executed by a processor, implement the container image construction method proposed in any of the above embodiments.

[0093] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0094] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for constructing a container image, characterized in that, include: Obtain the container image contents manifest associated with the target application; wherein the first file indicated by the container image contents manifest includes: an executable file compiled from the source code files of the target application, a configuration file for building the target application, and third-party dependency files that the target application depends on; Based on the container image contents manifest, run the target application in the test environment; Based on the runtime behavior data of the target application, a runtime behavior graph associated with each of the first files is generated; wherein, the runtime behavior graph is used to indicate the access sequence of each of the first files and the runtime access dependencies between the files; Based on the runtime behavior graph and the container image contents list, construct the container image of the target application.

2. The method according to claim 1, characterized in that, The step of constructing the container image of the target application based on the runtime behavior graph and the container image contents manifest includes: Based on the runtime behavior graph and the container image content list, a container image layering strategy is generated; wherein, the container image layering strategy is used to indicate the mapping relationship between each of the first files and its corresponding image layer; The container image of the target application is constructed according to the container image layering strategy.

3. The method according to claim 2, characterized in that, The step of generating a container image layering strategy based on the runtime behavior graph and the container image content list includes: Based on the runtime behavior graph, the access time distribution and access frequency of each of the first files are determined; Based on the access time distribution and access frequency of each of the first files, the first files are grouped to obtain at least one file group; wherein, the first files in the same file group are accessed multiple times and continuously within the same time period during the startup and execution process of the target application. The container image layering strategy is generated based on the at least one file group and the set image layer number constraint.

4. The method according to claim 3, characterized in that, The step of determining the access time distribution and access frequency of each of the first files based on the runtime behavior graph includes: Extract the access events and access timestamps corresponding to each of the first files from the runtime behavior graph; Arrange the access timestamps corresponding to each of the first files in chronological order to generate an access timestamp sequence for each of the first files. Based on the access timestamp sequence of each of the first files, the access time distribution and access frequency of each of the first files are determined.

5. The method according to claim 3, characterized in that, The step of generating the container image layering strategy based on the at least one file group and the set image layer number constraint includes: With the goal of maximizing the runtime correlation within each file group in the at least one file group and minimizing the cross-layer access overhead between different file groups, and with a set number of mirror layers as a constraint, the mapping relationship between each file and its respective mirror layer is solved. The container image layering strategy is generated based on the mapping relationship between each file and its corresponding image layer.

6. The method according to claim 2, characterized in that, The step of constructing the container image of the target application according to the container image layering strategy includes: Based on the container image layering strategy, the second files to be layered in each of the first files are copied to the intermediate directory corresponding to their respective target image layers. According to the preset image layer order, each intermediate directory is packaged into its corresponding image layer in sequence to generate the container image.

7. The method according to claim 1, characterized in that, The step of generating a runtime behavior map associated with each of the first files based on the runtime behavior data of the target application includes: Based on the runtime behavior data of the target application, the actual access data of each of the first files is determined; wherein, the actual access data includes at least one of the access order, access frequency and access timestamp of the corresponding first file; Based on the actual access data of each of the first files, a runtime behavior graph of the target application is generated.

8. The method according to claim 7, characterized in that, The step of generating a runtime behavior graph of the target application based on the actual access data of each of the first files includes: Each of the first files is used as a graph node; Based on the actual access data of each of the first files, directed edges are established between the graph nodes corresponding to adjacent accessed first files, and the weight values ​​of the directed edges are determined; wherein, the directed edges are used to indicate the runtime access dependencies between files; The runtime behavior graph is generated based on the directed edges and their weights.

9. The method according to claim 1, characterized in that, The container image contents manifest is generated using the following steps: Obtain the executable file of the target application, the configuration file for building the target application, and the project resource files of the project to which the target application belongs; wherein the executable file is obtained by compiling the source code file of the target application; Based on the third-party dependency information declared in the configuration file, obtain the third-party dependency files that the target application depends on; The container image contents list is generated based on the archive path and filename of the executable file, the third-party dependency files, and the project resource files.

10. A container image building apparatus, characterized in that, include: The acquisition module is used to acquire a container image content manifest associated with the target application; wherein the first file indicated by the container image content manifest includes: an executable file compiled from the source code file of the target application, a configuration file for building the target application, and third-party dependency files that the target application depends on; The runtime module is used to run the target application in a test environment based on the container image manifest. The generation module is used to generate a runtime behavior graph associated with each of the first files based on the runtime behavior data of the target application; wherein the runtime behavior graph is used to indicate the access sequence of each of the first files and the runtime access dependencies between the files; A build module is used to build a container image of the target application based on the runtime behavior graph and the container image contents list.

Images