Mirror management method, system, and computing device

Abstract

This application relates to the field of computer software technology, providing an image management method, system, and computing device. The method is applied to a computing device equipped with a software integration system, including: responding to a code repository corresponding to the software integration system receiving a commit instruction, detecting the change status of the image configuration file; the change status is used to identify whether any instruction text in the image configuration file has changed; if the change status is "changed," loading the changed image configuration file; generating an image build instruction based on each instruction text in the image configuration file; generating an image file according to the image build instruction; and storing the image file in the image repository of the software integration system. Based on this solution, the computing device utilizes changes to the image configuration file to trigger the automatic generation and updating of image files, decoupling the image file generation process from the software package delivery request, avoiding repeated image building for each package delivery, and improving software build efficiency.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to an image management method, system and computing device. Background Technology

[0002] In the software development process, developers continuously merge code into the repository in small amounts and multiple times. The system needs to achieve rapid and efficient code integration and software building to provide build feedback. To improve build efficiency, containerized build technology can be used during development. Leveraging its high concurrency and resource sharing capabilities, it supports the parallel execution of multiple build tasks, thereby shortening the overall build time and improving the utilization of computing resources.

[0003] In a typical software build process, after receiving a package request, the system can obtain the image configuration file from the code repository, build the image using the image build instructions, store the completed image in the image repository, and load the image into the container resource pool to perform the actual compilation and build operations.

[0004] However, in the above process, the creation, synchronization and build tasks of the image are performed serially. That is, each package request must wait for its own image to be created and synchronized before compilation can begin, which prolongs the end-to-end time of a single build. In high-frequency package creation scenarios, this affects the efficiency of software development and delivery. Summary of the Invention

[0005] This application provides an image management method, system, and computing device that can decouple the image file generation process from the software package delivery request, avoid repeatedly executing the image building process each time a package is delivered, and improve software building efficiency.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide an image management method applied to a computing device equipped with a software integration system. The method includes: responding to a code repository corresponding to the software integration system receiving a commit instruction, detecting the change status of an image configuration file; the image configuration file includes multiple instruction texts for instructing image building, and the change status is used to identify whether any instruction text in the image configuration file has changed; if the change status is changed, loading the changed image configuration file; generating an image building instruction based on each instruction text in the changed image configuration file; generating an image file according to the image building instruction; the image file is used to encapsulate the environment parameters and compilation tools of the software integration system; and storing the image file in the image repository of the software integration system.

[0007] Based on this solution, the computing device triggers the automatic generation and updating of image files in response to changes in the image configuration file. This decouples the image file generation process from the software package output request, avoiding repeated image building for each package output and improving software build efficiency. By pre-generating and caching image files, the computing device can directly load synchronized image files when receiving a build task, improving resource utilization and build concurrency capabilities.

[0008] In one possible implementation, in response to the code repository corresponding to the software integration system receiving a commit instruction, the change status of the image configuration file is detected, including: in response to detecting that the code repository has received a commit instruction, parsing the code address corresponding to the commit instruction; if the code address is the same as the storage address of the image configuration file, then the change status is determined to have occurred.

[0009] Based on this solution, computing devices can detect changes in the image configuration file status, ensuring that the image build process is triggered only when the image configuration file is actually changed, thus avoiding accidental triggering of image build tasks.

[0010] In another possible implementation, image build instructions are generated based on each instruction text in the modified image configuration file, including: parsing the modified image configuration file to obtain multiple instruction texts and the hierarchical structure corresponding to the multiple instruction texts; and generating image build instructions that conform to the hierarchical structure based on the multiple instruction texts.

[0011] Based on this solution, computing devices can generate corresponding image build instructions based on image configuration files, ensuring that the image build process strictly follows the hierarchical dependency relationships defined in the configuration file, thereby improving the standardization and traceability of image builds.

[0012] In another possible implementation, the image configuration file includes at least a base image text, a working directory setting text, and an environment variable setting text. The modified image configuration file is parsed to obtain multiple command texts and their corresponding hierarchical structures, including: obtaining the base image text, working directory setting text, and environment variable setting text from the image configuration file based on text keywords; identifying the base image text, working directory setting text, and environment variable setting text as command texts; and determining the hierarchical structure of each command text based on its order in the image configuration file.

[0013] Based on this solution, the computing device can parse the image configuration file, obtain the order of multiple instruction texts in the image configuration file, determine the execution level corresponding to each instruction text, and construct an instruction execution sequence that conforms to the hierarchical structure.

[0014] In another possible implementation, generating an image file based on the image build instructions includes: obtaining an image build tool based on the image build instructions; using the image build tool to execute the instructions corresponding to each instruction text in the image build instructions to obtain the image layer corresponding to each instruction text; and combining the image layers in a hierarchical structure to generate an image file.

[0015] Based on this solution, computing devices can generate complete image files corresponding to image build instructions, ensuring that each image layer is stacked in a predefined order to form a final image with consistency and reproducibility, thereby improving the reliability of the build results and environmental consistency.

[0016] In another possible implementation, storing the image file in the image repository of the software integration system includes: generating an image code and version identifier corresponding to the image file; storing the image file in the image repository; establishing a mapping relationship between the image code, version identifier and the image file; and generating an image file storage record based on the image code, version identifier and mapping relationship.

[0017] Based on this solution, computing devices can store newly generated image files to the corresponding image repository and record their unique identifier and version information, thereby achieving traceable management of images; through the establishment of mapping relationships, it is also possible to load and call image files.

[0018] In another possible implementation, the method further includes: reading image files from an image repository; synchronizing the image files sequentially to each virtual machine; in response to receiving a package delivery request, matching the target image file corresponding to the package delivery request in the virtual machine; constructing a software installation package corresponding to the package delivery request based on the package delivery request and the target image file; generating identification information corresponding to the software installation package; and storing the identification information corresponding to the software installation package.

[0019] Based on this solution, the computing device can synchronize the image file to each virtual machine after it is generated. This allows the virtual machine to quickly load the corresponding image file and start the build task after receiving the software build task, without waiting for the image to be created, thus significantly shortening the software build time.

[0020] In another possible implementation, the method further includes: obtaining a list of virtual machines and an image generation plan; the list of virtual machines is used to store virtual machines used to perform software builds, and the image generation plan is used to identify the number and size of images preset during the software build process; based on the image generation plan, a storage area partitioning operation is performed on each virtual machine in the list of virtual machines; and an image synchronization directory is established in each virtual machine.

[0021] Based on this solution, the computing device can allocate a dedicated area in the disk space of each virtual machine for loading image files, and pre-synchronize the required images from the image repository to this directory, ensuring that the virtual machine can directly load and use the image files in the disk control when building software, without repeated downloading or transmission, which significantly improves image loading efficiency and build response speed.

[0022] Secondly, embodiments of this application also provide a mirror management system, including: The code acquisition unit is configured to, in response to the code repository corresponding to the software integration system receiving a commit instruction, detect the change status of the image configuration file; the image configuration file includes multiple instruction texts for instructing image building, and the change status is used to identify whether any instruction text in the image configuration file has been changed; and, if the change status is changed, load the changed image configuration file; the image building unit is configured to, based on each instruction text in the changed image configuration file, generate image building instructions; and, based on the image building instructions, generate an image file; the image file is used to encapsulate the environment parameters and compilation tools of the software integration system; the image storage unit is configured to store the image file in the image repository of the software integration system.

[0023] Thirdly, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to perform the method as described in any of the first aspects above.

[0024] Fourthly, embodiments of this application provide a chip for performing the methods described in any of the first aspects above.

[0025] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0026] In a sixth aspect, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of a software package output; Figure 2 A flowchart illustrating an image management method provided in an embodiment of this application; Figure 3 A flowchart illustrating a process for detecting changes in an image configuration file, as provided in an embodiment of this application. Figure 4A flowchart illustrating a method for generating image build instructions, provided in an embodiment of this application; Figure 5 This application provides a schematic diagram of a process for generating an image file. Figure 6 This is a schematic diagram of a process for storing image files, provided in an embodiment of this application. Figure 7 This application provides a schematic diagram of a process for calling an image file. Figure 8 A schematic diagram illustrating a disk storage area partitioning process provided in an embodiment of this application; Figure 9 A schematic diagram of a mirror management system provided in an embodiment of this application; Figure 10 This is a schematic diagram illustrating the construction of a computing device image, as provided in an embodiment of this application. Figure 11 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0029] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0030] A containerization platform refers to a tool that can package applications and their dependencies into a lightweight, portable container for execution. Containerization tools, such as Docker or Kubernetes, automate the building and deployment of containers throughout the software development process, ensuring consistency across development, testing, and production environments.

[0031] An image is a lightweight, executable software package built through an automated process in a containerization platform. An image can contain everything needed for an application to run during the development process, including code, runtime, libraries, environment variables, configuration files, and other files.

[0032] The application scenarios of the embodiments of this application will be described below.

[0033] In software development processes such as application development, to promptly identify development issues, code is often continuously, in small batches, and multiple times merged into the version control repository, enabling software integration and rapid iteration. To improve development efficiency, developers utilize containerization technologies during development. Through a containerization platform, when the system triggers a package delivery request, an image build process is initiated. By building images, the development, testing, and production environments of the software are unified, ensuring consistency of the runtime environment relied upon by each stage and facilitating subsequent software delivery.

[0034] Figure 1 This is a schematic diagram of a software package.

[0035] like Figure 1 As shown, after receiving a package delivery request, the software development system triggers the containerization platform's build process, sending an image build request to the platform's image build service. Upon receiving the request, the image build service retrieves the image configuration file and image build tools from the image configuration file code repository and image build tool repository, respectively. Based on the image configuration file and build instructions, it generates the corresponding image file and archives it to the image repository. The system then utilizes the container resource pool to load the image file stored in the image repository, triggering the compilation and archiving process of the code corresponding to the package delivery request. Finally, a software version package is generated and delivered to the version repository as the response to the package delivery request. The container resource pool integrates multiple virtual machines and disk resources, enabling on-demand allocation and rapid deployment of container instances.

[0036] Depend on Figure 1 As shown, during the software deployment process, the corresponding image must be built and loaded before the code compilation process can begin in the container resource pool. Due to the large image size, the creation, transmission, and loading processes are time-consuming, extending the end-to-end time of building the software version package. Especially in scenarios where software development systems deploy frequently, the image building process executed each time a package is deployed further prolongs compilation waiting time, impacting the development and delivery efficiency of developers.

[0037] Based on this, embodiments of this application provide an image management method, which is applied to a computing device equipped with a software integration system. This method utilizes changes to the image configuration file during development to trigger the image build process, decoupling the image build process from the software version package build process. This avoids the image build process affecting the compilation efficiency when the code is packaged, thereby improving software development and interaction efficiency.

[0038] Figure 2 This is a flowchart illustrating an image management method provided in an embodiment of this application. The following is based on... Figure 2 The content shown is an exemplary description of the image management method provided in the embodiments of this application.

[0039] like Figure 2 As shown, the image management method provided in this application embodiment may include the following steps S100 to S500.

[0040] S100: In response to the code repository corresponding to the software integration system receiving a commit instruction, check the change status of the image configuration file.

[0041] In step S100, the computing device equipped with the software integration system can monitor the submission instructions sent by the user-side device in real time to determine the change status of the image configuration file stored in the computing device based on the submission instructions. The image configuration file may include multiple instruction texts for instructing image building, and the change status is used to identify whether any instruction text in the image configuration file has changed.

[0042] For example, the image configuration file may include base image text, working directory setting text, environment variable setting text, port declaration text, build process text, and container startup text. When any of the above text contents are detected to have changed, it is determined that the image configuration file has been modified, triggering the subsequent image build process; if no change has occurred, the existing image remains unchanged to avoid duplicate builds.

[0043] In this embodiment, the computing device can use the received submission instruction to identify whether the submission instruction contains a modification operation on the image configuration file. If a change to the image configuration file is detected, the change status of the image configuration file can be "changed"; if no modification operation is detected, the change status is "no change". When the change status is "changed", the computing device can trigger subsequent processes S200 to S500 to execute the image building process.

[0044] It should be understood that the detection of changed states by computing devices is a process triggered by code commits, which can be completed synchronously when developers commit code, requiring no additional operation. This improves the automation and response efficiency of the detection process and reduces the risk of delays caused by human intervention.

[0045] Figure 3 This is a flowchart illustrating a process for detecting changes in the status of an image configuration file, as provided in an embodiment of this application.

[0046] like Figure 3 As shown, in the image management method provided in this application embodiment, the detection of the image configuration file change status can be achieved through the following steps S110 and S120.

[0047] S110: In response to detecting that a commit instruction has been received in the code repository, parse the code address corresponding to the commit instruction.

[0048] In some embodiments of this application, the code repository storing the program code written by the storage developer and the code repository storing the image configuration file can be different branches or directories of the same repository. After the computing device detects that the code repository has received a commit instruction, it can parse the commit instruction and extract the code address of the code change involved to determine the file path affected by the commit instruction.

[0049] The code address refers to the path information used to identify the specific location of the code file in the repository, which includes parameters such as branch name, directory level, and file name. The computing device determines the storage path range of the program code and image configuration file by pre-defined storage rules, and then determines whether the commit command involves changes to the image configuration file.

[0050] S120: If the code address is the same as the storage address of the image configuration file, the change status is determined to have occurred.

[0051] In step S120, the computing device can compare the code address with the storage address of the image configuration file by reading the storage path of the image configuration file based on the code address corresponding to the submission instruction obtained in step S110. If they are the same, the change status is determined to be "changed" and the subsequent image building process is triggered; otherwise, it is determined to be "no change" and the current image version remains unchanged.

[0052] In another embodiment of this application, the storage address of the image configuration file and the storage address of the program code may belong to different code repositories. In this case, the computing device can use a cross-repository listening mechanism to directly parse the submission instruction and obtain the corresponding code address when it detects the code repository submission instruction corresponding to the image configuration file, and then determine whether the preset image configuration file path is hit. If it is hit, the S200 image building process is triggered to ensure version consistency and environment isolation.

[0053] In this way, by accurately identifying the source of configuration changes, the unrelated code submissions that trigger the image build process are avoided, significantly improving the stability and resource utilization efficiency of the build system.

[0054] It should be noted that, because the code address of the submission command can only determine whether the submitted file path involves the image configuration file, it cannot confirm whether its content has actually changed. Therefore, after comparing the addresses, it is necessary to further analyze the specific content of the file before and after the change, and use difference comparison technology to identify whether there are substantial modifications, such as field updates, parameter adjustments, or version number changes. This will avoid invalid builds triggered due to path matching but unchanged content, and ensure the accuracy of change determination and the necessity of process execution.

[0055] For example, computing devices can use text difference comparison algorithms to compare the image configuration files of the versions before and after submission line by line to identify the actual modified configuration items. If substantial changes such as updates to the base image version number, changes to dependency packages, or adjustments to build parameters are detected, it is determined to be a valid change, triggering the image rebuild process.

[0056] In some embodiments, the image configuration file contains comment text for each text item. Since the comment text is only used to explain the meaning of each instruction text and does not participate in the image building process, changes to the comment text are not considered changes to the image configuration file. That is, if the computing device detects that the submission instruction modifies the comment text of the image configuration file, the image building process will not be triggered.

[0057] For example, in the image configuration file, the "#" symbol can be used to mark comment text. When the computing device recognizes that the commit command only changes the content of the line after the "#", it determines that the commit command has not introduced configuration changes, and the change status of the image configuration file is "no change has occurred".

[0058] S200: If the change status is "Change Occurred", load the changed image configuration file.

[0059] When a computing device detects that the image configuration file has been changed to "changed," it can initiate the image building process and start the image building task. For example, the computing device can determine the loading method based on the number of times it has loaded the image configuration file. If it is the first load, the computing device can copy the contents of the image configuration file to its local working directory based on the file's storage address to complete the loading of the image configuration file.

[0060] If this loading of the image configuration file is not the first loading, the computing device can use a differential update mechanism to only pull and record the parts of the image configuration file that have changed since the last loading, thereby reducing data transmission overhead and loading time.

[0061] After loading is complete, the computing device can verify the loaded image configuration file to determine its syntax correctness and configuration completeness, ensuring that there are no missing fields or illegal parameters in the loaded image configuration file, and that the image configuration file meets the requirements of the image building process.

[0062] If the computing device verifies the image configuration file and passes, it executes the subsequent build process according to the instructions in the image configuration file. If the computing device fails to verify the image configuration file, it can execute step S200 again to reload the image configuration file and verify it until the verification passes. Alternatively, the computing device can terminate the loading process and report an error after the number of times the image configuration file is reloaded reaches a preset limit.

[0063] S300: Generates image build instructions based on each instruction text in the modified image configuration file.

[0064] After loading the image configuration file, the computing device can extract the instruction information required to build the image by parsing the instruction text in the image configuration file, and then generate the corresponding image building instructions.

[0065] In this embodiment, the computing device can parse the corresponding instructions from the various instruction texts in the image configuration file, and then combine them to generate image build instructions. As disclosed in the foregoing embodiments, the computing device can parse key information such as the base image name, architecture type, operating system version, and build dependency tools from the instruction texts such as the base image text, working directory setting text, environment variable setting text, port declaration text, build process text, and container startup text, and integrate them into a standardized build command sequence according to a preset instruction execution order.

[0066] Figure 4 This is a flowchart illustrating a method for generating image building instructions, as provided in an embodiment of this application.

[0067] like Figure 4 As shown, the process of generating image building instructions for a computing device provided in this application embodiment may include the following steps S311 to S313 and step S320.

[0068] S310: Parse the modified image configuration file to obtain multiple instruction texts and their corresponding hierarchical structures.

[0069] In this embodiment, the computing device can determine multiple instruction texts of the modified image configuration file and the hierarchical structure corresponding to each instruction text by parsing the image configuration file. The image configuration file may include at least instruction texts such as base image text, working directory setting text, and environment variable setting text. The hierarchical structure of the instruction texts can be determined based on their nesting relationship and execution order within the configuration file.

[0070] like Figure 4 As shown, the process by which the computing device provided in this application determines the instruction text and the hierarchical structure of the instruction text may include the following steps S311 to S313.

[0071] S311: Based on text keywords, retrieve the base image text, working directory setting text, and environment variable setting text from the image configuration file.

[0072] In this embodiment of the application, the computing device can identify and classify each instruction text based on the text keywords corresponding to each instruction text in the image configuration file. For example, the instruction text in the image configuration file may include line content corresponding to “FROM”, “WORKDIR”, “ENV”, “EXPOSE”, “ADD”, “COPY”, “RUN”, “CMD”, and “ENTRYPOINT”.

[0073] In the image configuration file, "FROM" corresponds to the base image text, "WORKDIR" corresponds to the working directory setting text, "ENV" corresponds to the environment variable setting text, "EXPOSE" corresponds to the port declaration text, "RUN", "ADD" and "COPY" correspond to the build process text, and "CMD" or "ENTRYPOINT" corresponds to the container startup text.

[0074] For example, the content of an image configuration file can be the following text: {FROM python:3.9-slim WORKDIR / app COPY . / app RUN pip install --no-cache-dir -r requirements.txt EXPOSE 80 ENV NAME World CMD ["python", "app.py"] } The computing device can identify keywords in the image configuration file through regular expression matching or syntax analysis, and then extract the corresponding instruction content to obtain instruction texts such as base image text, working directory setting text, and environment variable setting text. The computing device can use the content following keywords as the parameter part of the instruction text, and combine the keyword type to classify the instruction text, determining the specific content and category of each instruction text. For example, "FROM python:3.9-slim" is identified as the base image text of the image configuration file, with "python:3.9-slim" as its parameter part; "WORKDIR / app" is identified as the working directory setting text, with " / app" as its parameter part; "ENV NAME World" is identified as the environment variable setting text, with "World" as its parameter part; "COPY . / app" and "RUN pip install --no-cache-dir -r requirements.txt" are both identified as build process text, used for file copying and dependency installation, respectively; "EXPOSE 80" is identified as the port declaration text, with "80" as its parameter; and "CMD ["python", "app.py"]" is identified as the container startup text, with the startup command as its parameter. By performing structured parsing of various instruction texts, computing devices can accurately extract the key configuration information required for image building from the input configuration file, and perform subsequent processing and verification according to categories, thereby improving the controllability and consistency of the image generation process.

[0075] It should be understood that the keywords involved in the above embodiments are only examples. In actual applications and in the image configuration file, more content may be included, and there may be comments. For example, lines starting with "#" indicate comments, which the computing device should ignore when parsing the image configuration file.

[0076] In some embodiments, when loading the image configuration file, the computing device can read and parse it line by line, skipping blank lines and comment lines. It then performs syntax analysis on each valid instruction, uses its corresponding keywords to identify the instruction type, and extracts the parameter content. This avoids contextual interference and disordered instruction text order that can occur when the computing device matches content in the file based on keywords, thus ensuring that the parsing results of the image configuration file accurately reflect the actual build logic.

[0077] S312: Define the base image text, working directory setting text, and environment variable setting text as command texts respectively.

[0078] After separating various types of text from the image configuration file using keywords, the computing device can perform semantic verification on the parameter content based on the extracted instruction text type. This includes verifying whether the base image exists, whether the port is valid, and whether the environment variable format is correct. The text that passes the verification, along with its corresponding keywords, is then identified as the corresponding instruction text.

[0079] In some embodiments, the computing device may also record the original position information of each line of instruction during the process of parsing the image configuration file, so that the computing device can determine the definition order of the corresponding instruction text in the image configuration file.

[0080] S313: Determine the hierarchical structure of each instruction text based on the order of multiple instruction texts in the image configuration file.

[0081] After receiving the instruction text, the computing device can determine the hierarchical structure corresponding to each instruction text based on the order of each instruction text in the image configuration file. For example, taking the text of the image configuration file provided in step S311 above as an example, the base image text "FROM python:3.9-slim" can be the first level, the working directory setting text "WORKDIR / app" is the second level, the build process texts "COPY . / app" and "RUN pip install --no-cache-dir -r requirements.txt" are the third level, and so on, ultimately forming a hierarchical structure of instruction texts with hierarchical dependencies.

[0082] In this way, the computing device can accurately restore the dependencies and execution flow in the image building process based on the order of the various instruction texts in the image configuration file, ensuring that each building step proceeds step by step according to the predetermined logic.

[0083] S320: Generates image building instructions that conform to a hierarchical structure based on multiple instruction texts.

[0084] Once the computing device determines each instruction text and the corresponding hierarchical structure, it can combine the instruction texts based on the hierarchical structure to obtain image building instructions that conform to the hierarchical structure.

[0085] In some embodiments of this application, the image configuration file can also be used as part of the build context for the computing device to generate image build instructions. During the process of generating image build instructions, the computing device can obtain all files in the preset file path and include them in the build context to ensure that the resources required during the image build process are complete and traceable, thereby improving the consistency and reproducibility of the build.

[0086] For example, the computing device user determines that the preset file path of the build context includes the file path corresponding to the image configuration file and related dependency files. The computing device will automatically scan all files in the preset file path to generate a build context together with the image configuration file, and based on the build context, encapsulate the instruction text of each level into executable image build instructions in the order of dependency.

[0087] S400: Generates image files based on image build instructions.

[0088] Upon receiving the image build instruction, the computing device can generate the corresponding image file based on it. In this embodiment, the image file is used to encapsulate the environment parameters and compilation tools of the software integration system mounted on the computing device. The image file provides a consistent, isolated, and reusable runtime environment for the software development and integration process, ensuring a high degree of consistency between development, testing, and production environments, and avoiding operational differences caused by different devices.

[0089] Computing devices can generate image files layer by layer by executing image building instructions, thus producing the final image file. Each image file corresponds to one or more instruction texts in the image building instructions, and each subsequent image file records the file changes between the previous and current layers after the instruction execution. This makes the image file generation process traceable and supports rolling back to any historical layer for problem localization and repair.

[0090] Figure 5 This is a schematic diagram illustrating a process for generating an image file, provided as an embodiment of this application. The following is based on... Figure 5 The content shown illustrates, by way of example, the process of generating image files using image build instructions provided in the embodiments of this application.

[0091] like Figure 5 As shown, the process for generating an image file provided in this application embodiment may include the following steps S410 to S430.

[0092] S410: Obtain image building tools based on image build commands.

[0093] In this embodiment, the image building tool can be used to assist a computing device in generating corresponding image files based on image building instructions. For example, the image building tool includes various files and base images involved in the image building instructions, such as the base image defined in the base image text and the source files requested in the build process text. By calling the image building tool, the computing device obtains the base image and dependent files required for image building and executes the build operations sequentially according to the hierarchical order of the image building instructions.

[0094] It should be noted that when acquiring the image build tool, the computing device can verify the integrity and version consistency of the image build tool based on the content of the image build command. This ensures that the version of the image build tool used matches the version declared in the image configuration file, avoiding inconsistencies in build results due to tool version differences. If the verification passes, the computing device will execute the subsequent step S420 to build each image layer of the image file. If the verification fails, the computing device can use a rollback mechanism to re-download or switch to a matching version of the image build tool and trigger an alarm to notify operations and maintenance personnel for intervention, ensuring the consistency and stability of the build environment.

[0095] It should be understood that the base image can be a pre-built minimal operating system image stored on the computing device, containing the most basic system files and runtime environment required to run the target application. It serves as the initial read-only layer for image building through a layered storage mechanism. When the computing device executes the first image building instruction, it will use this base image as a starting point to create new read-only layers to record file changes caused by subsequent instructions. This ensures that each build operation is performed in an isolated environment, guaranteeing that the build results of each layer do not interfere with each other.

[0096] S420: Use the image building tool to execute the instructions corresponding to each instruction text in the image building instruction to obtain the image layer corresponding to each instruction text.

[0097] Once the computing device obtains the image building tool, it can utilize the resources corresponding to the image building tool to execute the building operations corresponding to each instruction text in sequence according to the hierarchical structure in the image configuration file, so as to generate the image layer corresponding to each instruction text.

[0098] For example, the computing device can first load the base image obtained through the aforementioned step S410 into the build environment as the initial image layer Layer0, and create a temporary container based on the initial image layer Layer0. Then, the working directory setting instruction is executed to create a directory in the temporary container, and this operation forms a new image layer Layer1. Subsequently, the build process instruction is executed to copy the source code or binary files to the directory of the temporary container, and install the corresponding installation package in the directory. After the installation is completed, an image layer change record is generated and an image layer Layer2 is formed. Subsequently, according to the hierarchical structure, environment variable setting instructions, port declaration instructions, and container startup instructions can be executed sequentially to generate image layers Layer3, Layer4, and so on until the final image layer.

[0099] In some embodiments, the computing device may also employ a caching mechanism to cache the generated image layers to assist in the subsequent image building process. For example, after receiving the image building tool and image building instructions, the computing device can check layer by layer during the current building process whether there are differences between the current instructions and the instructions of the cached image layers. If there are no changes, the cached image layers are directly reused to avoid wasting resources by repeatedly executing the same instructions. If there are differences in one layer, such as when the source code version is updated when generating image layer Layer2, the build process instructions in the image building instructions and all subsequent instructions are re-executed from that layer onwards to ensure that the updated content is accurately reflected in the final image, while retaining the previously unchanged cached layers to improve building efficiency.

[0100] S430: Combine the various image layers according to their hierarchical structure to generate an image file.

[0101] After generating each image layer, the computing device can stack the image layers in a hierarchical structure to form a complete container image file. At this point, the computing device can remove the temporary containers used during the build process and release the related resources, and then generate the image code corresponding to the image file so that the computing device can store the image file in the image repository for unified management.

[0102] It should be noted that each image layer built by the computing device executing the image build instructions is a read-only layer. Correspondingly, the image file, which is a collection of these read-only layers, is also read-only, ensuring the consistency and security of the image during distribution and operation.

[0103] Steps S410 to S430 in this embodiment can effectively improve the automation level and resource utilization efficiency of building images on computing devices. By combining the layered building mechanism with the caching strategy, the building time can be significantly shortened while ensuring image consistency.

[0104] S500: Stores image files to the image repository of the software integration system.

[0105] Once the computing device obtains the image file, it can store it in the image repository of the software integration system, which facilitates the unified management and subsequent use of newly built images.

[0106] Figure 6 This is a schematic diagram illustrating a process for storing image files, as provided in an embodiment of this application.

[0107] like Figure 6 As shown, after generating the image file, the computing device can store the image file for later use through the following steps S510 to S540.

[0108] S510: Generate the image code and version identifier corresponding to the image file.

[0109] During the image file generation process, the computing device can generate a unique hash value as its image code based on the image file's content, and generate a corresponding image file version identifier using version information such as the source code version and build tool version used during image file generation. The computing device can combine the image code and version identifier to generate a unique storage identifier corresponding to that image file.

[0110] In some embodiments of this application, the computing device can also generate image metadata containing multi-dimensional attributes by combining image encoding, version identifier, image generation timestamp, operating system identifier, operating system version, and central processing unit architecture type. This metadata is used for subsequent image traceability, environment adaptation, and compliance verification. This metadata is stored in the image repository along with the image file and supports indexing by dimension, improving image retrieval efficiency and management accuracy.

[0111] S520: Stores image files to an image repository.

[0112] The computing device can obtain the free storage space in the storage address corresponding to the image repository and establish a storage allocation scheme that matches the size of the image file; then the image file is transferred to the storage address to realize the storage mapping of the image file.

[0113] After the computing device transmits the image file to the storage address of the image repository, it can also verify the integrity of the image file during the transmission process by comparing the hash values ​​of the source and the target to ensure consistency; if the verification fails, a retransmission mechanism is triggered until success is achieved.

[0114] During the process of storing image files on computing devices, the image code and version identifier or image metadata can also be written into the metadata index table of the image repository. This makes it easier to quickly locate image files of specific versions or attributes through the index table, thereby improving the retrieval efficiency and management accuracy of image files in the image repository.

[0115] S530: Establish the mapping relationship between image encoding, version identifier and image file.

[0116] After storing information such as image files, image codes, and version identifiers in an image repository, the computing device can establish an image index mapping table based on the correspondence between the three, bind the image files to unique storage identifiers, and achieve fast location and retrieval through metadata indexing services. This mapping relationship supports multi-dimensional queries by version identifier, build time, architecture type, etc., improving the efficiency of image retrieval.

[0117] S540: Generates image file storage records based on image encoding, version identifier, and mapping relationship.

[0118] Furthermore, computing devices can generate image file storage records through image encoding, version identification, and mapping relationships, making the image file storage records uniquely traceable and facilitating auditing, rollback, and lifecycle management. When an image file needs to be updated or taken offline, the system automatically identifies dependencies based on the storage records to ensure environmental consistency.

[0119] In this embodiment of the application, the computing device can complete the entire process of dynamically building an image file by utilizing changes in the image configuration file by executing the above steps S100 to S500 and the sub-steps corresponding to each step, thereby realizing on-demand customization and automated scheduling of image building; by using changes in the image configuration file as a trigger condition to dynamically generate differentiated images, and decoupling the image building process from the packet output process, the delay caused by starting image building only after receiving the packet output request is avoided, and the time window from request to packet output is significantly shortened.

[0120] Figure 7 This is a schematic diagram illustrating a process for calling an image file, provided as an embodiment of this application. The following is based on... Figure 7 The content shown illustrates the image file calling process provided in the embodiments of this application.

[0121] like Figure 7 As shown, the process of a computing device calling an image file provided in this embodiment may include the following steps S610 to S660.

[0122] S610: Reads image files from the image repository.

[0123] Once the new image file is generated, the computing device can load it into the containerization platform of the build task for subsequent package delivery tasks to use. The containerization platform provides the computing device with a containerized runtime environment and corresponding runtime resources, enabling the computing device to provide an isolated, lightweight execution environment for software integration projects.

[0124] Containerization platforms provide container resource pools for computing devices, enabling these devices to execute tasks on demand by calling any available node in the pool. This avoids task blocking caused by single-node resource bottlenecks, further improving the concurrent processing capabilities and resource utilization of build tasks. For example, a container resource pool may include multiple compute nodes and local disks. Each compute node provides computing resources to the computing device, while the local disk stores the various versions of image files and intermediate build artifacts required by the compute nodes.

[0125] In this embodiment of the application, the compute nodes in the container resource pool provided by the containerization platform can be multiple virtual machines, and each virtual machine has a standardized image loading interface and resource scheduling capability, supporting dynamic matching and scheduling based on image version identifier and architecture type.

[0126] After building and storing the image file, the computing device can read the image file through the image repository and distribute it to the compute nodes in the container resource pool. This allows the compute nodes to call the appropriate image version when the corresponding task is triggered, complete the instant initialization of the build environment, optimize the build startup efficiency, and reduce the risk of build failure due to environment inconsistency.

[0127] S620: Synchronizes the image files to each virtual machine sequentially.

[0128] After reading the image file, the computing device can store it in the local disk of the container resource pool and synchronize the stored image file to the computing nodes of the container resource pool. This allows each computing node to quickly load the cached image file when a task is triggered, avoiding the network overhead and latency caused by repeatedly pulling from the remote repository.

[0129] In this embodiment of the application, the compute nodes in the container resource pool are virtual machines. The compute device can load new image files into the local disks corresponding to each virtual machine in the container resource pool, so that the new image files can be synchronized to the virtual machines. This allows the virtual machines to automatically match and load the corresponding image based on the image version identifier and architecture type when they receive a build task, thereby completing the rapid initialization of the container runtime environment.

[0130] In some embodiments of this application, steps S610 and S620 can be triggered immediately after step S500 is completed, forming a closed-loop management of the image file, avoiding task execution abnormalities caused by newly generated image files being called before storage and synchronization are completed, and improving the reliability of image management.

[0131] S630: In response to receiving a packet output request, match the target image file corresponding to the packet output request in the virtual machine.

[0132] In this embodiment, after receiving a build request, the computing device can instruct the virtual machine to search for a matching target image file on the corresponding local disk based on the build environment parameters specified in the build request. If the target image file exists on the local disk, the virtual machine can directly load and start the build task. If the target image file does not exist on the local disk, an image retrieval process is triggered to download the corresponding version of the image file from the image repository to the local disk and synchronize it to each virtual machine. This mechanism ensures the consistency and reproducibility of the build environment while avoiding task blocking caused by network fluctuations.

[0133] Meanwhile, because the loading and synchronization process of the image file is completed before the build task is triggered, the build phase does not need to wait for the image to be pulled, which significantly shortens the task startup delay and improves the software build efficiency.

[0134] S640: Based on the package request and the target image file, construct the software installation package corresponding to the package request.

[0135] After the target image file is determined and synchronized to the virtual machine, the virtual machine can execute the corresponding package output request and start the containerized build task. Based on the preloaded image environment, the compilation environment initialization is completed quickly, further shortening the build waiting time.

[0136] After initializing the compilation environment, the virtual machine will mount the specified code repository branch according to the task requirements and start the build process. The entire build process is executed in an isolated container environment, ensuring a clean environment and reproducible results. The computing device can monitor the execution status of the build task and verify the execution results of the virtual machine to obtain the software installation package corresponding to the output request.

[0137] S650: Generate identification information corresponding to the software installation package.

[0138] After the software installation package is built, the computing device can generate a unique identifier for the software installation package and upload the software installation package to the version repository for archiving, thereby achieving unified version management of the software installation package.

[0139] S660: Identification information corresponding to the storage software installation package.

[0140] In some embodiments, the computing device can also associate and store identification information with the software installation package to facilitate subsequent traceability and version comparison, while supporting rapid retrieval by product line, environment type, build time and other dimensions.

[0141] The solution provided in the above embodiments optimizes the timing of image building from every package request to only when the image configuration file changes. Combined with preloading and synchronization mechanisms, it effectively reduces the load on the image service and improves the utilization rate of building resources.

[0142] Figure 8 This is a schematic diagram illustrating a disk storage area partitioning process provided in an embodiment of this application. The following is based on... Figure 8 The disk storage area partitioning process provided in the embodiments of this application is illustrated by way of example.

[0143] like Figure 8 As shown, the process of partitioning a computing device into disk storage areas provided in this embodiment may include the following steps S710 to S730.

[0144] S710: Get the list of virtual machines and image generation plan.

[0145] In some embodiments of this application, because the computing device loads the obtained image file into the virtual machine's local disk, it is necessary to ensure that the virtual machine's local disk has sufficient storage space to accommodate the pre-loaded image file. The computing device can plan storage space for the image file and calculate the required capacity based on the number of images and the average image size before building the image file.

[0146] Before building the image file, the computing device can first obtain a list of virtual machines and an image generation plan from the container resource pool. The virtual machine list stores the virtual machines used to perform software builds, and the image generation plan identifies the number and size of image files to be pre-set during the software build process.

[0147] The computing device can determine the number of images to be built and the estimated size of each image based on the image generation plan, and calculate the total storage requirements by combining the redundancy factor. Then, the virtual machine's local disk is partitioned to allocate a dedicated storage area for image file preloading.

[0148] For example, if the current computing device has 70 images to be built in the image generation plan, with an average size of 3GB per image and a redundancy factor of 1.2, then the total storage requirement is 70 × 3GB × 1.2 = 252GB.

[0149] It should be noted that the above image generation plan is only an example; in actual applications, the number and size of images may vary depending on the product line. The computing device dynamically adjusts its disk storage area partitioning strategy based on the actual resource pool size to ensure that each computing node has sufficient image storage space.

[0150] S720: Based on the image generation plan, perform storage area partitioning operations on each virtual machine in the virtual machine list.

[0151] After obtaining the list of virtual machines and the image generation plan, the computing device can allocate corresponding storage space on the local disk of each virtual machine to preload the image file, based on the storage requirements in the image generation plan. This allocation process is dynamically adjusted based on the virtual machine's hardware configuration and current disk usage to ensure that each computing node has sufficient available space.

[0152] In some embodiments of this application, when the remaining capacity of a virtual machine's local disk is lower than a threshold, the computing device can also trigger an expansion process to add a specified amount of storage space to the disk corresponding to the virtual machine through the container resource pool, ensuring that the image preloading process is not affected by storage limitations.

[0153] Taking a storage requirement of 252GB as an example, if the remaining capacity of the local disk corresponding to the virtual machine is 50GB, which is lower than the storage requirement, the computing device can add storage space to the local disk corresponding to the difference between the storage requirement and the remaining capacity, i.e., 202GB, to avoid the image generated by the computing device failing to synchronize to the corresponding virtual machine.

[0154] S730: Create an image synchronization directory in each virtual machine.

[0155] During the disk storage area partitioning process, the computing device can also build a corresponding image storage directory in each virtual machine, classifying and storing images according to information such as product, OS type, architecture, and timestamp, ensuring the uniqueness and traceability of image files. This allows the virtual machine to quickly load the corresponding image from its local disk and start the compilation process after receiving a package request, avoiding delays caused by image downloads or creation.

[0156] Based on the image management method provided in this application embodiment, by utilizing a preloading mechanism triggered in response to changes in the image configuration file and dynamic management of storage space, not only is software build efficiency improved, but the resource utilization and stability of the software integration system are also enhanced. This method, while ensuring the response speed of high-concurrency build tasks, provides a scalable and maintainable image management solution for large-scale containerized build environments.

[0157] Figure 9 This is a schematic diagram of a mirror management system provided in an embodiment of this application.

[0158] Corresponding to the aforementioned embodiments of the image management method, this application also provides an embodiment of an image management system. The image management system 900 includes a code acquisition unit 910, an image building unit 920, and an image storage unit 930.

[0159] Specifically, the code acquisition unit 910 is configured to detect the change status of the image configuration file in response to a commit instruction received by the code repository corresponding to the software integration system. The image configuration file includes multiple instruction texts for instructing image building, and the change status indicates whether any instruction text in the image configuration file has been changed. Furthermore, if the change status indicates a change has occurred, the modified image configuration file is loaded.

[0160] Image build unit 920 is configured to generate image build instructions based on each instruction text in the modified image configuration file, and to generate image files based on these instructions. The image files are used to encapsulate the environment parameters and compilation tools of the software integration system.

[0161] The image storage unit 930 is configured to store image files to the image repository of the software integration system.

[0162] Figure 10 This is a schematic diagram illustrating the construction of a computing device image according to an embodiment of this application.

[0163] like Figure 10 As shown, the computing device is equipped with a software integration system, which may include an image management unit 1010, an image configuration file code library 1020, a build tool library 1030, an image repository 1040, a container resource pool 1050, a build task unit 1060, and a software version library 1070.

[0164] The image management unit 1010 is configured to monitor change events in the image configuration file code repository 1020. When a modification to the image configuration file is detected, the image build process is automatically triggered. During the build process, the necessary tools are downloaded from the build tool repository 1030, and the latest image configuration file is read from the image configuration file code repository 1020 to generate the corresponding image build instructions. Subsequently, the built image file is pushed to the image repository 1040 and simultaneously distributed to the container resource pool 1050.

[0165] In this embodiment, the container resource pool 1050 may have multiple build nodes 1051 and local disks 1052 corresponding to each build node 1051. After receiving a new image file in the image repository 1040, the computing device can synchronize it to the local disks 1052 corresponding to each build node 1051. This ensures that each build node 1051 can quickly load the required image and start the container build task when the build task unit 1060 receives the package output request, so as to quickly generate the software version package and store it in the software version repository 1070, thereby optimizing the build process and improving the package output efficiency.

[0166] Figure 11 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0167] like Figure 11 As shown, the computing device 1100 includes a processor 1101 and a memory 1102. Exemplarily, the computing device 1100 may also include a communications interface 1103 and a communications bus 1104.

[0168] The processor 1101, memory 1102, and communication interface 1103 communicate with each other via communication bus 1104. The communication interface 1103 may include a transmitter and receiver for communicating with other devices or communication networks. It can be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0169] In some embodiments, the processor 1101 is used to execute program 1105, specifically performing the relevant steps in the above-described image management method embodiments. Specifically, program 1105 may include program code, which includes computer-executable instructions.

[0170] For example, processor 1101 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 1100 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0171] In some embodiments, memory 1102 is used to store program 1105. Memory 1102 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0172] Specifically, program 1105 can be called by processor 1101 to cause computing device 1100 to perform image management method operations.

[0173] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 1100, causes the computing device 1100 to perform the image management method described in the above embodiments.

[0174] For example, the computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device.

[0175] This application provides a chip system in several embodiments, which is applied to a server. The chip system includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the processor executes the computer instructions, the server performs the various steps of the image management method shown in the above-described method embodiments.

[0176] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the corresponding image management method provided above, and will not be repeated here.

[0177] The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A mirror management method, characterized in that, The method, applied to a computing device equipped with a software integration system, includes: In response to the code repository corresponding to the software integration system receiving a commit instruction, the change status of the image configuration file is detected; the image configuration file includes multiple instruction texts for instructing image building, and the change status is used to identify whether any of the instruction texts in the image configuration file has been changed; If the change status is "changed", load the changed image configuration file; Based on each instruction text in the modified image configuration file, generate image build instructions; According to the image build instructions, an image file is generated; the image file is used to encapsulate the environment parameters and compilation tools of the software integration system; The image file is stored in the image repository of the software integration system.

2. The method according to claim 1, characterized in that, The step of responding to the code repository corresponding to the software integration system receiving a commit instruction and detecting the change status of the image configuration file includes: In response to detecting that the code repository has received a commit instruction, the code address corresponding to the commit instruction is parsed; If the code address is the same as the storage address of the image configuration file, then the change status is determined to have occurred.

3. The method according to claim 1 or 2, characterized in that, The process of generating image build instructions based on each instruction text in the modified image configuration file includes: Parse the modified image configuration file to obtain multiple instruction texts and the hierarchical structure corresponding to the multiple instruction texts; Based on the multiple instruction texts, the image building instructions that conform to the hierarchical structure are generated.

4. The method according to claim 3, characterized in that, The image configuration file includes at least the base image text, the working directory setting text, and the environment variable setting text; The process of parsing the modified image configuration file to obtain multiple instruction texts and their corresponding hierarchical structures includes: Based on text keywords, the base image text, the working directory setting text, and the environment variable setting text are obtained from the image configuration file, respectively. The base image text, the working directory setting text, and the environment variable setting text are respectively defined as the instruction text; The hierarchical structure of each instruction text is determined based on the order of the multiple instruction texts in the image configuration file.

5. The method according to claim 3 or 4, characterized in that, The step of generating an image file according to the image building instructions includes: Based on the image build instructions, obtain the image build tool; The image building tool is used to execute the instructions corresponding to each instruction text in the image building instruction to obtain the image layer corresponding to each instruction text; The individual image layers are combined according to the hierarchical structure to generate the image file.

6. The method according to any one of claims 1 to 5, characterized in that, The step of storing the image file in the image repository of the software integration system includes: Generate an image code and version identifier corresponding to the image file; Store the image file in the image repository; Establish a mapping relationship between the image encoding, the version identifier, and the image file; Based on the image encoding, the version identifier, and the mapping relationship, an image file storage record is generated.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Read the image file from the image repository; The image files are synchronized to each virtual machine sequentially. In response to receiving a packet output request, a target image file corresponding to the packet output request is matched in the virtual machine; Based on the output request and the target image file, construct a software installation package corresponding to the output request; Generate identification information corresponding to the software installation package; Store the identification information corresponding to the software installation package.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Obtain a list of virtual machines and an image generation plan; the list of virtual machines is used to store virtual machines used to perform software building, and the image generation plan is used to identify the preset number and size of images during the software building process; Based on the image generation plan, a storage region partitioning operation is performed on each virtual machine in the virtual machine list; Create an image synchronization directory in each of the virtual machines.

9. A mirror management system, characterized in that, include: The code acquisition unit is configured to detect the change status of the image configuration file in response to the code repository corresponding to the software integration system receiving a commit instruction; The image configuration file includes multiple instruction texts for instructing image building, and the change status is used to identify whether any of the instruction texts in the image configuration file has been changed; And, if the change status is "changed", load the changed image configuration file; The image build unit is configured to generate image build instructions based on each instruction text in the modified image configuration file; And, according to the image building instructions, generate an image file; The image file is used to encapsulate the environment parameters and compilation tools of the software integration system; The image storage unit is configured to store the image file in the image repository of the software integration system.

10. A computing device, characterized in that, include: Processor and memory; The processor and the memory are coupled together; The memory is used to store program instructions; The processor is used to execute the program instructions to perform the image management method as described in any one of claims 1 to 8.

Images