A component-based container building system and method

Abstract

This application discloses a component-based container building system. The system includes an external software source module, a container component source module, a development machine module, and an execution machine module. The development machine module reads the application, analyzes the software it depends on, confirms the container component information, generates a list of dependent software, and packages the application and the list of dependent software into a task closure. The execution machine module reads the list of dependent software from the task closure, obtains the container component information that meets the requirements of the dependent software, selects the container component to be used, merges the container component and the application in the task closure into a root file system using a union file system, generates a container runtime configuration file based on the configuration information in the container component and the task closure, and starts the container instance from the root file system. The component-based container building method proposed in this invention has the advantages of small size, fast build speed, cross-platform compatibility, and high sharing.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, specifically to a method and system for constructing containers. Background Technology

[0002] Container technology is an operating system-level virtualization technology that leverages mechanisms such as namespaces and cgroups in the Linux kernel to create multiple isolated runtime environments on a single operating system kernel. Due to its advantages such as fast startup speed, low resource consumption, and high environment consistency, container technology has been widely adopted in various computing models, including cloud computing, serverless computing, fog computing, and edge computing. In these application scenarios, developers typically use image builders to package applications and their dependencies, and then distribute the generated container images to the target execution environment (execution machine). Upon receiving the container image, the execution machine loads and starts it as one or more container instances, thereby enabling rapid application deployment and elastic scaling.

[0003] Currently, the main technical problems encountered when using container images for development and deployment include their large size, slow build speed, and platform-specific nature.

[0004] Disadvantages: (1) Large container image size: Container images typically contain the application and all its dependent software, resulting in large file sizes and increased storage and transmission overhead. Existing "multi-stage build" technology can reduce image size to some extent, i.e., compiling the application in a full environment first, and then copying the compiled artifacts to a streamlined environment. However, for applications such as machine learning that require large dependent libraries, the image size can still reach hundreds of megabytes to several gigabytes.

[0005] Disadvantage 2: Slow container image build: Building an image typically requires using multiple package management tools (such as Debian system software management tool apt, Python programming language library management tool pip) within a temporary container to download, compile, and install various dependent software from different software sources, resulting in a long build time. Existing technologies attempt to shorten the build time by caching existing dependency packages or image layers, but this still cannot significantly reduce the build time for the first build or when dependencies are frequently updated.

[0006] Disadvantage (3) Container images only support a single platform: Because images contain software dependencies related to specific CPU, GPU architectures, or operating systems, a container image can usually only run on a single platform. To adapt to different platforms, existing technologies require compiling and storing multiple images separately, which not only consumes a lot of storage space but also requires more time and resources for building and maintaining them. Moreover, when new CPU or GPU architectures emerge, existing images are difficult to adapt in a timely manner.

[0007] In emerging computing paradigms such as multi-cloud computing, fog computing, and edge computing, compute migration is often required, which involves migrating computing tasks from one execution machine to another. The target execution machine may reside on a different platform or architecture, leading to container migration failures. There is an urgent need for a new container packaging method that can replace existing container images, possessing characteristics such as small size, fast build speed, and cross-platform compatibility to meet the requirements of dynamic migration and multi-platform compatibility.

[0008] like Figure 1 As shown, Figure 1 On the development machine, the application is passed to a container instance formed from a base image. The software management tools inside the container instance are used to download and install the software that the application depends on. Finally, a container image is generated from the container instance and sent to the execution machine. The execution machine imports the image and directly generates a container instance.

[0009] The three drawbacks mentioned above in current technologies are caused by three inherent problems in container image workflows:

[0010] Problem 1: Container images contain all the software that should be reusable, leading to disadvantages 1 and 3.

[0011] Problem (2) The container image builder only calls other package management tools from the outside and cannot actively control the package installation process in the container, which leads to disadvantage (2);

[0012] Problem (3) Container images are built by developers, and the architecture information of the execution machine cannot be known in advance, which leads to disadvantage (3).

[0013] In summary, the aforementioned shortcomings lead to large container image size, slow build speed, and platform-specific technical issues. Therefore, there is an urgent need to propose a lightweight, modular, and cross-platform container building method and system. Summary of the Invention

[0014] To address the issues of large container image size, slow build speed, and platform specificity in existing technologies, a lightweight, modular, and cross-platform container building method and system is proposed.

[0015] In a first aspect, embodiments of this application provide a component-based container building system, the system comprising:

[0016] External software source module: used to collect different external software sources and provide a unified access interface for container component sources;

[0017] Container component source module: used to convert external software into container components and store the container components;

[0018] Development machine module: Used to read the application, analyze the software that the application depends on, interact with the container component source module to confirm the container component information, and generate a list of dependent software; package the application and the list of dependent software into a task closure;

[0019] The execution module is used to read the list of dependent software in the task closure, interact with the container component source module to obtain container component information that meets the requirements of the dependent software, select the container component to be used, use the union file system to merge the container component and the application in the task closure into a root file system, generate a container runtime configuration file based on the configuration information in the container component and the task closure, call the container runtime, and start the container instance.

[0020] In a specific embodiment of the present invention, the above-mentioned container component source module includes:

[0021] Component conversion module: Used to access external software source modules according to the needs of dependent software, download the software and convert it into container components, and then send it back for storage;

[0022] Component storage module: Used to receive container components sent by the component conversion module and exchange information with the execution module. When encountering dependent software requirements that cannot be met, it will request the component conversion module to automatically convert them. The container components come from the developer's upload or from automatic conversion from various external software sources.

[0023] In a specific embodiment of the present invention, the above-mentioned development machine module includes:

[0024] Dependency analysis module: Used to read the application, analyze the software that the application depends on, interact with the container component source module to confirm component information, and generate a list of dependent software;

[0025] Task Packaging Module: Packages the application and its dependent software list into a task closure, and transmits the task closure to the repository for the executor to access and download, or directly to the executor module via any data transmission method.

[0026] In a specific embodiment of the present invention, the above-mentioned actuator module includes:

[0027] Dependency resolution module: used to read the list of dependent software in the task closure, interact with the component storage module to obtain container component information that can meet the requirements of the dependent software, and select the container component to be used;

[0028] Component caching module: used to cache container components and their information. When the cached container components cannot meet the needs of the dependent software, it interacts with the component storage module to obtain the container components. The container components cached by the component caching module include container components built by the execution machine and general container components from the container component source.

[0029] Container assembly module: Used to merge container components and application in task closures into a root file system using the union file system, generate a container runtime configuration file based on the configuration information in the container components and task closures, and call the container runtime system to start the container instance.

[0030] In a specific embodiment of the present invention, the dependency analysis module is configured to include:

[0031] Read the application's source code files and analyze the application's programming language type;

[0032] Based on the programming language type, call different dependency software list generation logic; generate dependency information, interact with the component storage module, obtain the indirect dependent components of the component, and delete all indirect dependencies from the dependency information;

[0033] Export all direct dependencies of the application as a list of dependent software and allow users to edit it further.

[0034] In a specific embodiment of the present invention, the task packaging module is configured to include:

[0035] The software dependency list is formatted, and if an error is found, the software dependency list is prompted to be edited.

[0036] Package the application and its dependent software list into an archive format to form a task closure;

[0037] If you choose to upload to the repository, the task closure will be uploaded; otherwise, the task closure will be exported as a file.

[0038] In a specific embodiment of the present invention, the dependency resolution module includes:

[0039] Read the list of dependent software in the task closure and perform operations on each item one by one, including: sending a dependency requirement triple to the component cache module, obtaining the path of the container component and recording it in the list, and returning an error message to the user and exiting if the component cache module reports an error. The triple includes: <component type t, component name n, component version requirement s>.

[0040] Read the triplet information of the obtained container component, add the dependency requirements of this container component to the dependency software list, run the conflict resolution algorithm if a dependency conflict occurs, and return an error message to the user and exit if the dependency conflict cannot be resolved.

[0041] If each dependent software item has been mapped to a container component, then all the corresponding container component paths are stored for use by subsequent container assembly modules.

[0042] In a specific embodiment of the present invention, the above-mentioned component caching module is configured to include:

[0043] Obtain the dependency triple;

[0044] Check if there is a component of type t in the cache. If not, proceed with the exit steps: send the dependency requirement triple and the platform characteristic information of this execution machine to the component storage module, wait for the return of a container component that meets the dependency requirements, cache the returned container component, return the path to the dependency resolution module, and exit the component caching module.

[0045] Check if there is a component named n in component type t in the cache. If not, proceed to the exit step.

[0046] Query all versions of component type t and component name n in the cache. Based on the version requirement check rules of component type, confirm whether the existing version meets the dependency requirements. If not, proceed to the exit step. If so, select the most suitable version v based on the selection rules.

[0047] Query all environment variants of component type t, component name n, and version v in the cache, and confirm whether the existing environment variants meet the environment of this execution machine. If not, proceed to the exit step; if so, select the most suitable environment variant e based on the selection rules.

[0048] Return the path of the container component with component type t, component name n, version v, and environment variant e in the cache to the dependency resolution module, and exit the execution component cache module;

[0049] If the container component source module returns an error, the error is reported to the dependency resolution module and the component caching module is exited.

[0050] In a specific embodiment of the present invention, the container assembly module includes:

[0051] Obtain all corresponding container component paths from the dependency resolution module;

[0052] Using a union file system, the paths of the application within the task closure and the paths of all container components are merged to form a root file system.

[0053] Generate a default configuration for the container runtime that conforms to a predetermined standard, and read the configuration information from container components and task closures, modify the default configuration, and generate the final runtime configuration file.

[0054] The root file system path and runtime configuration file are passed to the local container runtime system of the execution module, requesting the container runtime system to start the container instance.

[0055] In a specific embodiment of the present invention, the above-mentioned component storage module includes:

[0056] Receive the dependency requirement triple and execution platform characteristic information requested by the execution module;

[0057] Check if there is a component of component type t in the storage. If not, proceed to the exit step. The exit step is as follows: send the dependency requirement triplet and execution machine platform feature information to the component conversion module, wait for the return of a container component that meets the dependency requirements, store the returned container component and return it, and exit the component storage module.

[0058] Check if there is a component named n in component type t in the storage. If not, proceed to the exit step.

[0059] Query all versions of component type t and component name n in the storage. According to the version requirement check rules of component type, confirm whether the existing version meets the dependency requirements. If not, proceed to the exit step. If so, select the most suitable version v based on the selection rules.

[0060] Query all environment variants in the storage for component type t, component name n, and version v. Confirm whether the existing environment variants meet the execution machine platform characteristic information. If not, proceed to the exit step. If so, select the most suitable environment variant e based on the selection rules.

[0061] Return the container component with component type t, component name n, version v, and environment variant e from the cache, and exit the component storage module;

[0062] If the component conversion module returns an error, then return an error and exit the component storage module.

[0063] In a specific embodiment of the present invention, the above-mentioned component conversion module includes:

[0064] Received the dependency requirement triple and execution platform feature information requested by the component storage module;

[0065] Check if there is a conversion function for type t; if not, return an error.

[0066] Send a request to an external software source of type t to retrieve the software named n; return an error if the software does not exist.

[0067] Query all versions of name n in the external software source, and check whether the existing version meets the dependency requirements according to the version requirement check rules of component type t. If not, return an error; if so, select the most suitable version v based on the selection rules.

[0068] Query all environment variants e with name n and version v in the external software source, and confirm whether the existing environment variants meet the execution machine platform characteristics information. If not, return an error; if so, select the most suitable environment variant e according to the selection rules.

[0069] Download the software with name n, version v, and environment variant e from an external software source;

[0070] Use the conversion logic of type t to convert the software into a container component and return it; if an error occurs during conversion, return an error.

[0071] Secondly, embodiments of this application provide a component-based container construction method, applied to the aforementioned component-based container construction system, the method comprising:

[0072] Step 1: The development module reads the application, analyzes the software that the application depends on, interacts with the container component source module to confirm the container component information, and generates a list of dependent software; the application and the list of dependent software are packaged into a task closure;

[0073] Step 2: Transfer the task closure to the execution machine, or upload it from the development machine to the repository, and then download it from the repository to the execution machine;

[0074] Step 3: The execution module reads the list of dependent software in the task closure, interacts with the container component source module to obtain container component information that meets the requirements of the dependent software, and selects the container component to be used;

[0075] Step 4: When the container component source finds that a certain software dependency cannot be satisfied, it automatically accesses the upstream software source, converts the upstream package into a container component, and stores it;

[0076] Step 5: The execution machine downloads all container components, uses the union file system to merge the container components and the application in the task closure into a root file system, generates a container runtime configuration file based on the configuration information in the container components and task closure, and starts the container instance from the root file system.

[0077] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and the aforementioned componentized container building system. The componentized container building system includes: a development machine module, an execution machine module, a container component source module, and an external software source module.

[0078] Compared with existing technologies, it has the following outstanding advantages:

[0079] 1) The method of this invention proposes to build containers directly on the execution machine for task closures, without the need to build container images on the development machine; it eliminates the need for manual adaptation for various execution machine hardware platforms in advance, instead relying on the execution machine's builder for automatic adaptation, saving labor costs; developers do not need to build corresponding images for each execution machine hardware platform, saving build time, storage space, and network transmission; the execution machine can automatically select the most suitable container components according to its own platform characteristics, improving local component reusability, saving build time, and obtaining container instances with high execution efficiency;

[0080] 2) The method of this invention proposes to use code to describe the environment in the task closure, while the container image directly packages all the content in the environment; this greatly reduces storage and transmission volume; since the content in the environment is usually platform-specific (for example, some software can only be executed on x86-64 architecture CPUs or only on certain versions of GPUs), the container image is platform-specific, while the task closure uses platform-independent code when describing the environment, so a single task closure can be deployed across platforms;

[0081] 3) The method of this invention proposes a container component source that uniformly converts various software packages into an installation-free container component format, while container image building methods require the installation of multiple software managers and then the separate installation of software packages in various formats. The task closure builder can uniformly manage software from multiple software sources, thus supporting cross-software source dependency management, making the build process more stable, and reducing the burden on software developers. Since container components are installation-free, build time is saved. Attached Figure Description

[0082] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0083] Figure 1 This is a schematic diagram of an existing container system architecture;

[0084] Figure 2 This is a schematic diagram of the component-based container construction system architecture of the present invention;

[0085] Figure 3 This is a schematic diagram of the component-based container construction workflow of the present invention;

[0086] Figure 4 This is a schematic diagram comparing the network and storage consumption of the present invention;

[0087] Figure 5 This is a schematic diagram comparing the execution time of the present invention;

[0088] Figure 6 This is a schematic diagram of the component-based container construction method of the present invention;

[0089] Figure 7 This is a hardware schematic diagram of the electronic device of the present invention. Detailed Implementation

[0090] It should be noted that the processor described in this invention is the control center of an electronic device. It can be a single processor or a collective term for multiple processing elements. For example, it can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of this invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0091] Alternatively, the processor can perform various functions of the electronic device by running or executing software programs stored in memory and by calling data stored in memory.

[0092] In a specific implementation, as one example, the processor may include one or more CPUs. Each of these processors may be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions). Electronic devices may include servers, desktop computers, laptops, smartphones, tablets, embedded computers, etc., where the embedded computer includes vehicles and robots, etc.

[0093] The memory is used to store the software program that executes the solution of the present invention, and the execution is controlled by the processor. For specific implementation methods, please refer to the above method embodiments, which will not be repeated here.

[0094] It should be noted that the structure of the electronic device shown in the accompanying drawings is not intended to limit it. The actual device may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0095] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0096] It should also be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0097] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0098] It should also be understood that, in various embodiments of the present invention, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0099] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, 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 device, 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; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0100] 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.

[0101] In addition, the functional units in the various embodiments of the present invention 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.

[0102] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a 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 a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0103] To make the above-mentioned features and effects of the present invention clearer and easier to understand, specific embodiments are described below in conjunction with the accompanying drawings. This specification discloses one or more embodiments incorporating the features of the present invention. The disclosed embodiments are merely illustrative. The scope of protection of the present invention is not limited to the disclosed embodiments, but is defined by the appended claims.

[0104] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.

[0105] The terminology involved in this invention:

[0106] Container technology is a lightweight virtualization technology that creates multiple isolated containers by partitioning resources on a single operating system kernel. Each container runs an application, and resource usage is independent between different containers, effectively balancing conflicting resource usage demands.

[0107] A container image is a binary representation of an application and all its software dependencies. It is an executable software package that makes explicit assumptions about its runtime environment. A container image is a static template of a container instance, containing application code, runtime, libraries, environment variables, and runtime configuration files.

[0108] Image Builder: A tool or system used to create container images from build scripts (such as Dockerfiles). By reading the build script, the image builder packages the application and its dependencies into a container image. Typical image builders include Docker buildx, Buildah, Kaniko, etc.

[0109] A container instance is an independent, executable containerized environment created and run based on a container image. Each container instance is a specific running instance of a container image, with its own lifecycle, resource allocation, and running processes. Container instances ensure application independence and security through operating system-level isolation (such as namespaces and control groups).

[0110] Image Registry: A centralized repository for storing and managing container images, categorized as public or private. Public repositories (such as Docker Hub) provide publicly accessible images, suitable for distributing open-source projects and public applications. Private repositories (such as Harbor) are used within production environments, offering enhanced security and access control, suitable for storing private applications and sensitive images.

[0111] A container runtime is a system responsible for loading container images and running them as container instances. A container runtime can read image files locally or download images from an image repository and manage the container's lifecycle, including starting, stopping, monitoring, and destroying it. Typical container runtime systems include containerd, CRI-O, LXC, and Podman.

[0112] Docker: A widely used container technology platform that integrates various container management tools. Docker includes the following key components: the image builder Docker buildx, the container runtime containerd, and the default public image repository DockerHub. Docker provides a complete containerization solution, including image building, management, network configuration, storage integration, and orchestration, greatly simplifying the development, deployment, and operation of container applications.

[0113] This invention aims to propose a novel container package format (hereinafter referred to as "task closure") and a method for building components based on this format. The task closure is characterized by containing an application and a list of dependent software, rather than the application and its complete dependencies, thus solving the problem of large container image size. The process of building a container from a task closure occurs on the execution machine. The builder reads the list of dependent software, accesses a container component source, and actively obtains container components adapted to the local execution machine platform, solving the problem of slow container image building. The list of dependent software in the task closure consists of a set of software names and version restrictions, without limiting the architecture of the execution machine, thus possessing cross-platform characteristics and solving the problem of container images only supporting a single platform.

[0114] The method of this invention solves the following main technical difficulties:

[0115] Challenge ⑴ Accurate analysis of application software dependencies: Identifying the specific software dependencies of an application requires syntax analysis of the application's source code, or secondary processing using the analysis results of other dependency analysis software.

[0116] Challenge 2: Multi-Software Manager Ecosystem Compatibility: In order to integrate with the ecosystems of various existing software managers, the system should understand the version representation rules, version selection priority ranking rules, and platform-specific identification methods of various software managers, and select the appropriate components.

[0117] Challenge 3: Cross-platform differences: For the same software dependency requirements, the indirect dependent components may differ across platforms. Taking machine learning frameworks as an example, platforms that include GPUs (Graphics Processing Units) will require drivers related to the GPU version and model, while platforms that only include CPUs (Central Processing Units) will not require drivers.

[0118] Challenge 4: Portable Components: Components need to bypass the installation process and be directly merged into the root file system. Existing software packages typically need to be placed in specific directories and undergo compilation, building, and configuration operations. To achieve direct merging capability, existing software packages need to be preprocessed and pre-compiled to eliminate the installation process and improve efficiency.

[0119] The following detailed description is provided in conjunction with specific embodiments:

[0120] Example 1

[0121] like Figure 2 As shown, Figure 2 To achieve this, the present invention does not run container instances on the development machine, but directly performs dependency analysis on the application, packages the application and analysis results into a task closure and sends it to the execution machine; the execution machine obtains container components suitable for its own execution machine based on the dependency information in the task closure, and combines them to generate a container instance.

[0122] like Figure 3 As shown in the figure, this application provides a component-based container building system, the system including:

[0123] The external software repository module 10 collects software repositories maintained by different organizations, companies, or individuals, providing a unified access interface for the container component repository module 20. The container component repository accesses these external software repositories via network requests or application programming interfaces (APIs) to obtain software information and download software packages. External software repositories include, but are not limited to, Python software repositories (such as pypi.org), JavaScript software repositories (such as npmjs.com), and Debian software repositories (such as packages.debian.org).

[0124] The container component source module 20 is used to store container components; it is a storage repository for container components, providing them to one or more execution machines. The operation of the container component source is not limited to a specific computing device or architecture; it can be a centralized computing device, a computing device containing authoritative computing devices and multi-level distributed caches, or multiple distributed computing devices. The container components stored in the container component source support user uploads or conversion from other software package formats. The container component source executes the component storage module 202 and the component conversion module 201. The component storage module 202 exchanges information with the component cache module 402 of the execution machine. When encountering unmet dependency software requirements, it requests the component conversion module 201 to attempt automatic conversion. The container components in the component storage module 202 come from both developer uploads and automatic conversions from various external software sources. The component conversion module 201 accesses the corresponding external software source according to the dependency software requirements, downloads the software, converts it into a container component, and returns it to the component storage module 202.

[0125] The development module 30 is used to read the application, analyze the software that the application depends on, interact with the container component source module to confirm the container component information, and generate a list of dependent software; and package the application and the list of dependent software into a task closure;

[0126] In a specific embodiment of the present invention, the development machine module 30 is the producer of task closures, and any computing device can assume this role. The development machine runs the dependency analysis module 301 and the task packaging module 302. The dependency analysis module 301 reads the application, analyzes its dependent software, interacts with the component storage module 202 of the container component source to confirm component information, and generates a list of dependent software. The task packaging module 302 packages the application and the list of dependent software into a task closure. After the development machine generates the task closure, it can transmit the task closure to a repository (i.e., a storage service or storage device for task closures, which can be public or private) for the execution machine to access and download, or it can directly transmit it to the execution machine via any data transmission method such as a network or removable storage.

[0127] The execution module 40 is used to read the list of dependent software in the task closure, interact with the container component source module 20 to obtain container component information that meets the requirements of the dependent software, select the container component to be used, use the union file system to merge the container component and the application in the task closure into a root file system, generate a container runtime configuration file based on the configuration information in the container component and the task closure, and start the container instance from the root file system.

[0128] The execution machine module 40 is the consumer of the task closure, used to run and manage containers; any computing device can assume this role. The execution machine runs a dependency resolution module 401, a component caching module 402, and a container assembly module 403. The dependency resolution module 401 reads the list of dependent software in the task closure, interacts with the component storage module 202 to obtain container component information that can meet the requirements of the dependent software, and selects the container component to be used. The component caching module 402 caches container components and their information. When a cached container component cannot meet the requirements of a certain dependent software, it interacts with the component storage module 202 of the container component source to obtain the container component. The component caching module 402 caches both container components specifically built for this execution machine and more general container components from the container component source. The container assembly module 403 uses a union filesystem to merge the container components and the application in the task closure into a root filesystem (RootFS), generates a container runtime configuration file based on the configuration information in the container components and the task closure, and calls the container runtime system to start the container instance.

[0129] In a specific embodiment of the present invention, the container component source module 20 includes:

[0130] Component conversion module 201: Used to access external software source modules according to the needs of dependent software, download the software and convert it into container components, and then send it back for storage;

[0131] Component storage module 202: Used to receive container components sent by component conversion module 201 and exchange information with execution module 40. When encountering dependent software requirements that cannot be met, it will request component conversion module 201 to automatically convert them. The container components come from the developer's upload or from automatic conversion from various external software sources.

[0132] In a specific embodiment of the present invention, the development machine module 30 includes:

[0133] Dependency Analysis Module 301: Used to read the application, analyze the software that the application depends on, interact with the container component source module 20 to confirm component information, and generate a list of dependent software;

[0134] Task Packaging Module 302: Packages the application and the list of dependent software into a task closure, and transmits the task closure to the repository for the executor to access and download, or transmits it directly to the executor module through any data transmission method.

[0135] In a specific embodiment of the present invention, the actuator module 40 includes:

[0136] Dependency resolution module 401: used to read the list of dependent software in the task closure, interact with component storage module 202, obtain container component information that can meet the requirements of the dependent software, and select the container component to be used;

[0137] Component caching module 402: used to cache container components and their information. When the cached container components cannot meet the needs of the dependent software, it interacts with the component storage module 202 to obtain the container components. The container components cached by the component caching module 402 include machine-specific container components and general container components from the container component source.

[0138] Container Assembly Module 403: Used to merge container components and applications in task closures into a root file system using a union file system, generate a container runtime configuration file based on the configuration information in the container components and task closures, and call the container runtime system to start the container instance.

[0139] In a specific embodiment of the present invention, the component conversion module 201 includes:

[0140] Received the dependency requirement triple and execution platform feature information requested by component storage module 202;

[0141] Check if there is a conversion function for type t; if not, return an error.

[0142] Send a request to an external software source of type t to retrieve the software named n; return an error if the software does not exist.

[0143] Query all versions of name n in the external software source, and check whether the existing version meets the dependency requirements according to the version requirement check rules of component type t. If not, return an error; if so, select the most suitable version v based on the selection rules.

[0144] Query all environment variants e with name n and version v in the external software source, and confirm whether the existing environment variants meet the execution machine platform characteristics information. If not, return an error; if so, select the most suitable environment variant e based on the selection rules.

[0145] Download the software with name n, version v, and environment variant e from an external software source;

[0146] Use the conversion logic of type t to convert the software into a container component and return it; if an error occurs during conversion, return an error.

[0147] In a specific embodiment of the present invention, the component conversion module 201 includes: Step 1: Receiving a dependency requirement triple <component type t, component name n, component version requirement s> and execution platform characteristic information requested by a component storage module; Step 2: Querying whether there is a conversion function for type t, and returning an error if not; Step 3: Sending a request to the external software source s of type t to obtain the software with name n, and returning an error if not found; Step 4: Querying all versions of name n in the external software source s, and confirming whether the existing version meets the dependency requirements according to the version requirement check rules for this component type, and returning an error if not found, and selecting the most suitable version v based on the selection rules; Step 5: Querying all environment variants of version v of name n in the external software source s, and confirming whether the existing environment variants meet the execution platform characteristic information, and returning an error if not found, and selecting the most suitable environment variant e based on the selection rules; Step 6: Downloading the software of environment variant e of version v of name n from the external software source s; Step 7: Using the conversion logic of type t, converting the software into a container component and returning; if an error occurs during conversion, returning an error.

[0148] The selection rules for the aforementioned versions and environment variants are as follows: each external software source has its own unique version selection specifications and environment variant selection specifications (for example, the Python software source uses the PyPA specification https: / / packaging.python.org / en / latest / specifications / , and the Debian software source uses the Debian policy manual https: / / www.debian.org / doc / debian-policy / ).

[0149] Taking a Python language package as an example, during the conversion to a container component, the file named "METADATA" in the ".dist-info" directory of the package will be read to extract the package's dependencies on the Python interpreter version, dependencies on other Python packages, etc., and the information in the file named "entrypoint.txt" will be read to create the entry file, etc.

[0150] In a specific embodiment of the present invention, the component storage module 202 includes:

[0151] Received the dependency requirement triple and execution platform feature information requested by the execution module 40;

[0152] Check if there is a component of component type t in the storage. If not, proceed to the exit step. The exit step is as follows: send the dependency requirement triplet and execution machine platform feature information to the component conversion module, wait for the return of a container component that meets the dependency requirements, store the returned container component and return it, and exit the component storage module.

[0153] Check if there is a component named n in component type t in the storage. If not, proceed to the exit step.

[0154] Query all versions of component type t and component name n in the storage. According to the version requirement check rules of component type, confirm whether the existing version meets the dependency requirements. If not, proceed to the exit step. If so, select the most suitable version v according to the version selection specifications of each external software source.

[0155] Query all environment variants in the storage for component type t, component name n, and version v. Confirm whether the existing environment variants meet the execution machine platform characteristic information. If not, proceed to the exit step. If so, select the most suitable environment variant e according to the selection rules.

[0156] Return the container component with component type t, component name n, version v, and environment variant e from the cache, and exit the component storage module;

[0157] If the component conversion module returns an error, then return an error and exit the component storage module.

[0158] In a specific embodiment of the present invention, the component storage module 202 includes: Step 1: Receiving a dependency requirement triple <component type t, component name n, component version requirement s> and execution machine platform characteristic information for a certain execution machine request; Step 2: Querying whether there is a component of type t in the storage; if not, proceeding to step 7; Step 3: Querying whether there is a component of type t with name n in the storage; if not, proceeding to step 7; Step 4: Querying all versions of type t with name n in the storage, and confirming whether the existing versions meet the dependency requirements according to the version requirement check rules for this component type; if not, proceeding to step 7; if so, selecting the most suitable version v; Step 5: Querying the storage... For all environment variants of type t, name n, and version v, confirm whether the existing environment variants meet the execution machine platform characteristics. If not, proceed to step 7; if so, select the most suitable environment variant e. Step 6: Return the container component of environment variant e of type t, name n, and version v from the cache and exit this module. Step 7: Send the dependency requirement triple <component type t, component name n, component version requirement s> and execution machine platform characteristics to the component conversion module, wait for it to return a container component that meets the dependency requirements, store the returned container component and return it, and exit this module. Step 8: If the component conversion module returns an error, return an error and exit this module.

[0159] In a specific embodiment of the present invention, the dependency analysis module 301 is configured to include:

[0160] Read the application's source code files and analyze the application's programming language type; ultimately, a programming language type can be obtained through various methods, including but not limited to file extensions, file content, and project metadata.

[0161] Based on the programming language type, call different dependency software list generation logic; generate dependency information, interact with the component storage module, obtain the indirect dependent components of the component, and delete all indirect dependencies from the dependency information;

[0162] Export all direct dependencies of the application as a list of dependent software and allow users to edit it further.

[0163] In a specific embodiment of the present invention, the dependency analysis module 301 includes: Step 1: Reading the file list of the application folder, guessing the programming language type of the application based on the frequency of occurrence of different file extensions; if the language type is not supported for analysis, subsequent steps are not executed and the user is prompted to edit the dependency software list; Step 2: Calling different dependency software list generation logic according to the programming language type; Step 3: Taking Python application software as an example, first scanning the file list in the root directory of the program folder, confirming one by one whether there is dependency information generated by other software or provided by the application software developer; Step 4: If a file named requirements.txt exists (analysis result generated by pipreqs software), If a file named pyproject.toml exists (the analysis result generated by the Poetry software), the corresponding converter is called; otherwise, if no dependency information exists, each Python program is traversed and read, its syntax is analyzed, the names of the imported Python libraries are extracted, and dependency information is generated. If no dependency information exists, the dependency information generated in steps 4, 5, or 6 above is read, and the component storage module of the container component source is interacted with to obtain the indirect dependent components of the component, and all indirect dependencies are deleted from the dependency information. If no dependency information exists, the corresponding converter is called; otherwise, if ...

[0164] In a specific embodiment of the present invention, the task packaging module is configured 302 to include:

[0165] The software dependency list is formatted, and if an error is found, the software dependency list is prompted to be edited.

[0166] Package the application and its dependent software list into an archive format to form a task closure;

[0167] If you choose to upload to the repository, the task closure will be uploaded; otherwise, the task closure will be exported as a file.

[0168] In a specific embodiment of the present invention, the task packaging module 302 includes: step (1) checking the format of the dependent software list; if a format error is found, the user is prompted to re-edit the dependent software list; step (2) packaging the application and the dependent software list into an archive format to form a task closure; step (3) if the user chooses to upload to the repository, the task closure is uploaded; otherwise; step (4) exporting the task closure as a file.

[0169] In a specific embodiment of the present invention, the dependency resolution module 401 includes:

[0170] Read the list of dependent software in the task closure and perform operations on each item one by one, including: sending a dependency requirement triple to the component cache module, obtaining the path of the container component and recording it in the list, and returning an error message to the user and exiting if the component cache module reports an error. The triple includes: <component type t, component name n, component version requirement s>.

[0171] Read the tuple information of the obtained container component, add the dependency requirements of this container component to the dependency software list, run the conflict resolution algorithm if a dependency conflict occurs, and return an error message to the user and exit if the dependency conflict cannot be resolved.

[0172] If each dependent software item has been mapped to a container component, then all the corresponding container component paths are stored for use by subsequent container assembly modules.

[0173] In a specific embodiment of the present invention, the dependency resolution module 401 includes: step (1) reading the list of dependent software in the task closure and performing the following operations on each item; step (2) sending a dependency requirement triple <component type t, component name n, component version requirement s> to the component cache module, obtaining the path of the container component and recording it in the list; if the component cache module reports an error, it returns an error message to the user and exits; step (3) reading the metadata of the container component obtained in the previous step, adding the dependency requirements of this container component to the list of dependent software; if a dependency conflict occurs, it runs a conflict resolution algorithm; if the dependency conflict cannot be resolved, it returns an error message to the user and exits; step (4) if each dependent software has been mapped to a container component, it stores all the corresponding container component paths for use by the subsequent container assembly module.

[0174] In a specific embodiment of the present invention, the component caching module configuration 402 includes:

[0175] Obtain the dependency triple;

[0176] Check if there is a component of type t in the cache. If not, proceed with the exit steps: send the dependency requirement triple and the platform characteristic information of this execution machine to the component storage module, wait for the return of a container component that meets the dependency requirements, cache the returned container component, return the path to the dependency resolution module, and exit the execution component cache.

[0177] Check if there is a component named n in component type t in the cache. If not, proceed to the exit step.

[0178] Query all versions of component type t and component name n in the cache. Based on the version requirement check rules of component type, confirm whether the existing version meets the dependency requirements. If not, proceed to the exit step. If so, select the most suitable version v based on the selection rules.

[0179] Query all environment variants of component type t, component name n, and version v in the cache, and confirm whether the existing environment variants meet the environment of this execution machine. If not, proceed to the exit step; if so, select the most suitable environment variant e based on the selection rules.

[0180] Return the path of the container component with component type t, component name n, version v, and environment variant e in the cache to the dependency resolution module, and exit the execution component cache module;

[0181] If the container component source module returns an error, it reports the error to the dependency resolution module and exits the current module.

[0182] In a specific embodiment of the present invention, the component caching module 402 includes: step (1) obtaining a dependency requirement triple <component type t, component name n, component version requirement s>; step (2) querying whether there is a component of type t in the cache, if not, proceeding to step 7; step (3) querying whether there is a component of type t with name n in the cache, if not, proceeding to step 7; step (4) querying all versions of type t with name n in the cache, and confirming whether the existing versions meet the dependency requirements according to the version requirement check rules for this component type, if not, proceeding to step 7, if so, selecting the most suitable version v; step (5) querying all loops of type t with name n and version v in the cache. Step 6: Check if an existing environment variant meets the requirements of this execution machine. If not, proceed to step 7. If one exists, select the most suitable environment variant e. Step 7: Return the path of the container component of type t, name n, version v, and environment variant e in the cache to the dependency resolution module and exit this module. Step 8: Send the dependency requirement triple and the platform characteristic information of this execution machine to the component storage module of the container component source, wait for it to return a container component that meets the dependency requirements, cache the returned container component, return the path to the dependency resolution module, and exit this module. Step 9: If the container component source returns an error, report the error to the dependency resolution module and exit this module.

[0183] In a specific embodiment of the present invention, the container assembly module 403 includes:

[0184] Obtain all corresponding container component paths from the dependency resolution module;

[0185] Using a union file system, the paths of the application within the task closure and the paths of all container components are merged to form a root file system.

[0186] Generate a default configuration for the container runtime that conforms to a predetermined standard, and read the configuration information from container components and task closures, modify the default configuration, and generate the final runtime configuration file.

[0187] The root file system path and runtime configuration file are passed to the local container runtime system of the execution module, requesting the container runtime system to start the container instance.

[0188] In a specific embodiment of the present invention, the container assembly module 403 includes: step (1) obtaining the local paths of all required modules from the dependency resolution module; step (2) using a union file system, including but not limited to OverlayFS, AUFS, etc., merging the application paths in the task closure and the paths of all container modules to form a root file system; step (3) generating a default container runtime configuration conforming to the OCI standard, reading the configuration information in the container components and task closure, modifying the default configuration, and generating the final runtime configuration file; step (4) passing the root file system path and runtime configuration file to the local container runtime system of the execution machine, including but not limited to runc, containerd, CRI-O, gVisor, etc., requesting the container runtime system to start the container instance.

[0189] In summary, the component-based container building method and system proposed by the inventors offer advantages over existing container image building systems, including smaller size, faster build speed, cross-platform compatibility, and high sharing capabilities. In a specific quantitative comparison experiment, the task closure system was compared with the three most widely used container image building systems (Docker, Buildah, and Apptainer). The test set consisted of nine real-world, commonly used open-source applications in the field of machine learning (CLIP, LoRA, SAM2, StableBaselines 3, Stable Diffusion, Transformers, TTS, Whisper, and YOLO11). In this experiment, all files to be transferred during the build process were pre-cached on a proxy server, ensuring stable and consistent network conditions throughout the experiment.

[0190] like Figure 4 As shown, the differences in network and storage are as follows: the size of task closures is reduced by an average of 94% compared to container images, and the size of container instances built from task closures is reduced by an average of 36% compared to container instances loaded from container images. Regarding network traffic, the task closure system reduces network traffic by an average of 97% on development machines and by an average of 55% on execution machines. Furthermore, the storage sharing rate between container instances built from task closures is 58%, while the storage sharing rate between container instances generated from images is only 20%.

[0191] like Figure 5 As shown, the differences in execution time are as follows: the task closure system reduces the average time consumed on the development machine by 98%, the average time consumed on the execution machine by 67%, and the total time by 92%. If only the build operation time is considered, the task closure system reduces the time by an average of 87% compared to the container image system.

[0192] Qualitative experiments show that a single task closure supports execution machine platforms of various GPU models (such as multiple models from NVIDIA and AMD) and CPU models (such as x86-64 and arm64).

[0193] Example 2

[0194] like Figure 6 As shown, this application provides a componentized container construction method, applied to the aforementioned componentized container construction system. The method includes:

[0195] Step 1: The development module reads the application, analyzes the software that the application depends on, interacts with the container component source module to confirm the container component information, and generates a list of dependent software; the application and the list of dependent software are packaged into a task closure;

[0196] Step 2: Transfer the task closure to the execution machine, or upload it from the development machine to the repository, and then download it from the repository to the execution machine;

[0197] Step 3: The execution module reads the list of dependent software in the task closure, interacts with the container component source module to obtain container component information that meets the requirements of the dependent software, and selects the container component to be used;

[0198] Step 4: When the container component source finds that a certain software dependency cannot be satisfied, it automatically accesses the upstream software source, converts the upstream package into a container component, and stores it;

[0199] Step 5: The execution machine downloads all container components, uses the union file system to merge the container components and the application in the task closure into a root file system, generates a container runtime configuration file based on the configuration information in the container components and task closure, and starts the container instance from the root file system.

[0200] Example 3

[0201] like Figure 7 As shown, Figure 7 This is a schematic diagram of the hardware structure of a computing device according to an embodiment of this application. An embodiment of this application provides an electronic device, including a memory, a processor, and the aforementioned modular container building system. The modular container building system includes: a development machine module, an execution machine module, a container component source module, and an external software source module.

[0202] In some embodiments, the computing device may further include a communication interface 83 and a bus 80. For example, Figure 7 As shown, the componentized container building system 81, memory 82, and communication interface 83 are connected through bus 80 and complete mutual communication.

[0203] This modular container construction method and system can run on any computer (including servers, personal computers, IoT devices, etc.), and the system operating environment includes, but is not limited to, Linux, Windows and Mac systems.

[0204] Specifically, the component-based container building system 81 may include a development machine module, an execution machine module, a container component source module, and an external software source module;

[0205] The memory 82 can be used to store or cache various data files that need to be processed and / or communicated, as well as possible computer program instructions executed by the componentized container building system 81.

[0206] The componentized container building system 81 reads and executes computer program instructions stored in the memory 82 to implement any of the componentized container building computation methods in the above embodiments.

[0207] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0208] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A component-based container building system, characterized in that, The system includes: External software source module: used to collect different external software sources and provide a unified access interface for container component sources; Container component source module: used to convert external software into container components and store the container components; Development machine module: used to read the application, analyze the software that the application depends on, interact with the container component source module to confirm the container component information, and generate a list of dependent software; package the application and the list of dependent software into a task closure; Execution module: used to read the list of dependent software in the task closure, interact with the container component source module to obtain container component information that meets the requirements of the dependent software, select the container component to be used, use the union file system to merge the container component and the application in the task closure into a root file system, generate a container runtime configuration file according to the configuration information in the container component and the task closure, call the container runtime, and start the container instance. The container component source module includes: Component conversion module: used to access the external software source module according to the needs of dependent software, download the software and convert it into container components, and send it back for storage; the container component source module converts various software packages into a container component format that does not require installation. Component storage module: Used to receive container components sent by the component conversion module, exchange information with the execution module, and request the component conversion module to automatically convert when encountering dependent software requirements that cannot be met. The container components come from the developer's upload or from automatic conversion from various external software sources.

2. The component-based container construction system according to claim 1, characterized in that, The development machine module includes: Dependency analysis module: used to read the application, analyze the software that the application depends on, interact with the container component source module to confirm component information, and generate a list of dependent software; Task Packaging Module: Packages the application and the list of dependent software into a task closure, transmits the task closure to the repository for the executor to access and download, or transmits it directly to the executor module through any data transmission method.

3. The component-based container construction system according to claim 1, characterized in that, The actuator module includes: Dependency resolution module: used to read the list of dependent software in the task closure, interact with the component storage module, obtain container component information that can meet the requirements of the dependent software, and select the container component to be used; Component caching module: used to cache the container components and their information. When the cached container components cannot meet the needs of the dependent software, it interacts with the component storage module and obtains the container components. The container components cached by the component caching module include the container components built by the execution machine and the general container components from the container component source module. Container assembly module: Used to merge the container components and the application in the task closure into a root file system using the union file system, generate a container runtime configuration file based on the configuration information in the container components and the task closure, and start the container by calling the container runtime system.

4. The component-based container construction system according to claim 2, characterized in that, The dependency analysis module is configured to include: Read the application's source code files and analyze the application's programming language type; Based on the programming language type, different dependency software list generation logic is invoked; dependency information is generated, and the component storage module is interacted with to obtain the indirect dependent components of the component, and all indirect dependencies are deleted from the dependency information; Export all direct dependencies of the application as a list of dependent software, and allow users to edit it further.

5. The component-based container construction system according to claim 2, characterized in that, The task packaging module is configured to include: The dependent software list is checked for formatting errors. If a formatting error is found, the user is prompted to edit the dependent software list. The application and its dependent software list are packaged into an archive format to form a task closure. If you choose to upload to the repository, then upload the task closure; otherwise, export the task closure as a file.

6. The component-based container construction system according to claim 3, characterized in that, The dependency resolution module includes: Read the list of dependent software in the task closure and perform operations on each item one by one, including: sending a dependency requirement triple to the component cache module, obtaining the path of the container component and recording it in the list, and if the component cache module reports an error, returning an error message to the user and exiting. The triple includes: <component type t, component name n, component version requirement s>. Read the triple information of the obtained container component, add the dependency requirements of this container component to the dependency software list, if a dependency conflict occurs, run the conflict handling algorithm, if the dependency conflict cannot be resolved, return an error message to the user and exit. If each of the dependent software items has been mapped to a container component, then all the corresponding container component paths are stored for use by the container assembly module in the subsequent steps.

7. The component-based container construction system according to claim 6, characterized in that, The component caching module is configured to include: Obtain the dependency requirement triple; Check if there is a component of component type t in the cache. If not, proceed to the exit step: send the dependency requirement triplet and the platform feature information of this execution machine to the component storage module, wait for the return of a container component that meets the dependency requirements, cache the returned container component, return the path to the dependency resolution module, and exit the component caching module. Check if there is a component with the name n in the component type t in the cache. If not, proceed to the exit step. Query all versions of the component type t and the component name n in the cache, and confirm whether the existing version meets the dependency requirements according to the version requirement check rules of the component type. If not, proceed to the exit step; if so, select the most suitable version v based on the selection rules. Query all environment variants of the component type t, component name n, and version v in the cache, and confirm whether the existing environment variants meet the environment of this execution machine. If not, proceed to the exit step. If so, select the most suitable environment variant e based on the selection rules. Return the path of the container component with component type t, component name n, version v, and environment variant e in the cache to the dependency resolution module, and exit the execution component cache module; If the container component source module returns an error, the error is reported to the dependency resolution module and the component caching module is exited.

8. The component-based container construction system according to claim 3, characterized in that, The container assembly module includes: Obtain all corresponding container component paths from the dependency resolution module; Using a union file system, the paths of the application in the task closure and the paths of all container components are merged to form a root file system. Generate a default configuration for the container runtime that conforms to a predetermined standard, and read the configuration information from container components and task closures, modify the default configuration, and generate the final runtime configuration file. The path to the root file system and the runtime configuration file are passed to the container runtime system local to the execution module, requesting the container runtime system to start the container instance.

9. The component-based container construction system according to claim 6, characterized in that, The component storage module includes: Receive the dependency requirement triple and execution platform feature information requested by the execution module; The system checks if a component of type t exists in the storage. If not, it proceeds to the exit step, which involves sending the dependency triplet and execution platform feature information to the component conversion module, waiting for a container component that meets the dependency requirements to be returned, storing the returned container component and returning it, and then exiting the component storage module. Check if there is a component with the name n in the component type t in the storage. If not, proceed to the exit step. Query all versions of the component type t and the component name n in the storage. According to the version requirement check rule of the component type, confirm whether the existing version meets the dependency requirement. If not, proceed to the exit step. If so, select the most suitable version v based on the selection rule. Query all environment variants of the component type t, component name n, and version v in the storage, and confirm whether the existing environment variants meet the execution machine platform characteristic information. If not, proceed to the exit step; if so, select the most suitable environment variant e based on the selection rules. Return the container component containing the component type t, component name n, version v, and environment variant e from the cache, and exit the component storage module; If the component conversion module returns an error, then return an error and exit the component storage module.

10. The component-based container construction system according to claim 9, characterized in that, The component conversion module includes: Receive the dependency requirement triple and execution platform feature information requested by the component storage module; Check if there is a conversion function for component type t; if not, return an error. Send a request to the external software source of component type t to obtain the software with name n; if it does not exist, return an error. Query all versions of name n in the external software source, and check whether the existing version meets the dependency requirements according to the version requirement check rule of component type t. If not, return an error; if so, select the most suitable version v based on the selection rule. Query all environment variants e with name n and version v in the external software source, and confirm whether the existing environment variants meet the execution machine platform characteristic information. If not, return an error; if so, select the most suitable environment variant e based on the selection rules. Download the software with name n, version v, and environment variant e from an external software source; Using the conversion logic of type t, the software is converted into a container component and returned; if an error occurs during conversion, an error is returned.

11. A component-based container construction method, applied to the component-based container construction system according to any one of claims 1-10, characterized in that, The method includes: Step 1: The development module reads the application, analyzes the software that the application depends on, interacts with the container component source module to confirm the container component information, and generates a list of dependent software; the application and the list of dependent software are packaged into a task closure; Step 2: Transfer the task closure to the execution machine, or upload it from the development machine to the repository, and then download it from the repository to the execution machine; Step 3: The execution module reads the list of dependent software in the task closure, interacts with the container component source module to obtain container component information that meets the requirements of the dependent software, and selects the container component to be used; Step 4: When the container component source finds that a certain software dependency cannot be satisfied, it automatically accesses the upstream software source, converts the upstream package into a container component, and stores it. Step 5: The execution machine downloads all container components, uses the union file system to merge the container components and the application in the task closure into a root file system, generates a container runtime configuration file based on the configuration information in the container components and task closure, and starts the container instance from the root file system.

12. An electronic device, comprising a memory, a processor, and a modular container construction system as described in any one of claims 1-10, characterized in that, The modular container building system includes: an external software source module, a container component source module, a development machine module, and an execution machine module.

Images