Mirror image generation method and device for cross-CPU architecture of DevOps platform and medium

Abstract

The invention discloses a mirror image generation method and device for a cross-CPU architecture of a DevOps platform and a medium. The mirror image generation method and device are used for solving the problems that an existing cross-CPU architecture mirror image generation method is complex and low in efficiency. The method comprises the following steps: creating a Docker file on a DevOps platform to define a mirror image construction process; comparing the target CPU architecture with a platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture; according to the method, the Docerfile is called through the DevOps platform to construct the mirror image corresponding to the target CPU structure if the Docerfile is called through the DevOps platform, and the mirror image corresponding to the target CPU structure is constructed if the Docerfile is called through the QEMU node to construct the mirror image if the Docerfile is not called through the QEMU node, so that mirror image generation of a cross-CPU architecture is realized, the application range of the DevOps platform is greatly expanded, and the DevOps platform can support more diversified deployment environments.

Description

Technical Field

[0001] The present application relates to the field of image generation technology, and in particular to a method, device and medium for generating an image across CPU architectures on a DevOps platform. Background Art

[0002] Container technology ensures that applications run consistently in different environments by encapsulating applications and their dependencies in an "image". However, in the actual application of container technology, the generation and distribution of images face a key challenge: traditional image generation methods are usually bound to a single CPU architecture.

[0003] As technology develops, the need for cross-CPU architecture compatibility becomes increasingly prominent. This challenge is particularly prominent in the DevOps field. As an emerging software development and operation model, DevOps aims to improve development and operation efficiency through automation, standardization, and monitoring. However, most DevOps platforms are currently limited to building and running images for the single CPU architecture on which they are located. This brings limitations in actual production environments, because different hardware environments may require images of different CPU architectures to ensure the normal operation of the software.

[0004] In addition, the existing cross-CPU architecture image generation methods are often complex and inefficient, and cannot meet the needs of rapid iteration and efficient operation and maintenance. General DevOps platforms lack the ability to directly support cross-architecture image building and distribution, which limits their wide application in diverse hardware environments. Summary of the invention

[0005] The embodiments of the present application provide a method, device and medium for generating images across CPU architectures on a DevOps platform to solve the above-mentioned technical problems.

[0006] On the one hand, an embodiment of the present application provides a method for generating an image across CPU architectures on a DevOps platform, including:

[0007] Create a Dockerfile file on the DevOps platform to define the image building process;

[0008] Comparing the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture;

[0009] If yes, the Dockerfile file is called through the DevOps platform to build an image corresponding to the target CPU structure. If no, the Dockerfile file is called through the QEMU node to build an image, thereby realizing image generation across CPU architectures.

[0010] In one implementation of the present application, before comparing the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture, the method further includes:

[0011] Determine the platform CPU architecture currently running on the DevOps platform according to preset configuration information, and receive an image building request through the DevOps platform;

[0012] According to the input parameters in the image building request, the target CPU architecture corresponding to the image to be generated is determined; wherein the input parameters include the CPU architecture type or the hardware requirements of the target deployment environment.

[0013] In one implementation of the present application, comparing the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture specifically includes:

[0014] Determine a string corresponding to the target CPU architecture and a string corresponding to the platform CPU architecture of the DevOps platform;

[0015] Compare the character string corresponding to the target CPU architecture with the character string corresponding to the platform CPU architecture to obtain a corresponding comparison result;

[0016] Determine whether the character strings of the target CPU architecture and the platform CPU architecture are consistent according to the comparison result, so as to determine whether the target CPU architecture is consistent with the platform CPU architecture.

[0017] In one implementation of the present application, if not, before building an image by calling the Dockerfile file through the QEMU node to realize image generation across CPU architectures, the method further includes:

[0018] Installing QEMU virtual machine software in the DevOps platform; wherein the QEMU node corresponding to the QEMU virtual machine software is used to simulate the hardware environment corresponding to the CPU structure;

[0019] Docker container software and Buildx plug-in are installed in the DevOps platform; wherein the Docker container software is used to build an image corresponding to the CPU architecture through the Buildx plug-in.

[0020] In one implementation of the present application, if not, the Dockerfile file is called by the QEMU node to build an image, thereby realizing image generation across CPU architectures, specifically including:

[0021] When the target CPU architecture is inconsistent with the platform CPU architecture, scheduling to a QEMU node corresponding to the QEMU virtual machine software on the DevOps platform;

[0022] The QEMU node is used to simulate the hardware environment corresponding to the target CPU architecture, so that the Docker container software can execute the instructions in the Dockerfile file corresponding to the image building process through the Buildx plug-in under the hardware environment corresponding to the target CPU architecture to build an image that matches the target CPU architecture.

[0023] In one implementation of the present application, it also includes:

[0024] During the image building process, the resource usage and construction progress of the QEMU node are monitored in real time;

[0025] After the construction is completed, the generated image is verified, and the verified image is stored in a preset target image repository; wherein the image verification is used to determine that the image runs on the target CPU architecture.

[0026] In one implementation of the present application, if yes, then the Dockerfile file is called by the DevOps platform to build an image corresponding to the target CPU structure, specifically including:

[0027] When the target CPU architecture is consistent with the platform CPU architecture, calling the Dockerfile file and parsing the Dockerfile file;

[0028] The instruction sequence in the Dockerfile file is determined according to the parsing result, and each instruction is executed in sequence according to the instruction sequence; wherein the instructions at least include: copying files, installing dependencies, setting environment variables and exposing ports.

[0029] In one implementation of the present application, a Dockerfile file is created on a DevOps platform to define the image building process, specifically including:

[0030] Based on a click trigger on the visualization interface, a definition template corresponding to the Dockerfile file is returned to the visualization interface, and configuration information of the image building process returned based on the definition template is received through an API interface on the DevOps platform; wherein the configuration information includes a base image, building steps, and environment configuration;

[0031] A syntax check is performed on the configuration information, and if the check passes, a Dockerfile file corresponding to the image building process is created on the DevOps platform according to the configuration information.

[0032] On the other hand, an embodiment of the present application further provides a cross-CPU architecture image generation device for a DevOps platform, the device comprising:

[0033] at least one processor;

[0034] and, a memory communicatively coupled to the at least one processor;

[0035] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above-mentioned DevOps platform cross-CPU architecture image generation method.

[0036] On the other hand, an embodiment of the present application further provides a non-volatile computer storage medium storing computer executable instructions, which, when executed, implements a method for generating an image across CPU architectures of a DevOps platform as described above.

[0037] The embodiments of the present application provide a method, device, and medium for generating images across CPU architectures on a DevOps platform, which at least have the following beneficial effects:

[0038] By creating a Dockerfile file on the DevOps platform to define the image building process, developers can customize the image building steps and configuration according to actual needs, thereby improving the flexibility and customizability of image building; by comparing the target CPU architecture with the platform CPU architecture of the DevOps platform and selecting the corresponding building method based on the comparison results, the ability to generate images under different CPU architectures is realized, greatly expanding the application scope of the DevOps platform and enabling it to support more diverse deployment environments; when the target CPU architecture is consistent with the platform CPU architecture of the DevOps platform, directly calling the Dockerfile file through the DevOps platform for building can make full use of platform resources and improve building efficiency. When the target CPU architecture is inconsistent with the platform CPU architecture, simulation building through the QEMU node may increase some building time, but avoids the complexity and cost of migrating images between different architectures. Through a unified cross-architecture image generation method, the workload of developers adapting to multiple platforms is significantly reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0040] Figure 1 A flowchart of a method for generating an image across CPU architectures on a DevOps platform provided in an embodiment of the present application;

[0041] Figure 2 A schematic diagram of a DevOps platform cross-CPU architecture image building process provided in an embodiment of the present application;

[0042] Figure 3 A schematic diagram of the internal structure of a cross-CPU architecture image generation device for a DevOps platform provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0044] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0045] Figure 1 A flowchart of a method for generating an image across CPU architectures on a DevOps platform is provided in an embodiment of the present application.

[0046] The analysis method involved in the embodiments of the present application can be implemented by a terminal device or a server, and the present application does not impose any special restrictions on this. For the convenience of understanding and description, the following embodiments are described in detail by taking a server as an example.

[0047] It should be noted that the server may be a single device or a system consisting of multiple devices, that is, a distributed server, and this application does not make any specific limitation on this.

[0048] like Figure 1 As shown, an embodiment of the present application provides a method for generating a cross-CPU architecture image on a DevOps platform, including:

[0049] 101. Create a Dockerfile file on the DevOps platform to define the image building process.

[0050] Specifically, in one embodiment of the present application, a Dockerfile file is created on a DevOps platform to define an image building process, which specifically includes:

[0051] Based on the click trigger on the visualization interface, the definition template corresponding to the Dockerfile file is returned to the visualization interface, and the configuration information of the image building process returned based on the definition template is received through the API interface on the DevOps platform; wherein the configuration information includes the base image, building steps and environment configuration;

[0052] Perform a syntax check on the configuration information, and if the check passes, create a Dockerfile file corresponding to the image building process on the DevOps platform based on the configuration information.

[0053] In one embodiment, the developer clicks on the visual interface of the DevOps platform to trigger a request to obtain a definition template of the Dockerfile file. After receiving the request, the DevOps platform retrieves a Dockerfile definition template that matches the developer's needs from a preset template library or database. It should be noted that the definition template usually contains some commonly used Dockerfile instructions and placeholders so that developers can quickly fill in and customize them.

[0054] The DevOps platform displays the Dockerfile definition template to developers through a visual interface, and guides developers to enter the configuration information of the image building process. According to the template prompts, fill in key information such as the basic image, building steps, and environment configuration on the visual interface. The configuration information returned by the developer based on the definition template is received through its API interface, and preliminary data verification and formatting are performed.

[0055] The DevOps platform also needs to perform a detailed syntax check on the configuration information received. It should be noted that syntax checking includes verifying the validity of the base image, the compliance of the build steps, and the rationality of the environment configuration. If the check finds syntax errors or unreasonableness, the platform will immediately feedback the error information to the developer and guide the developer to make corrections.

[0056] If the syntax check passes, the corresponding Dockerfile file will be automatically created on the DevOps platform based on the configuration information provided by the developer. During the creation process, the placeholders in the configuration information will be replaced with actual values, and the Dockerfile file content that conforms to the Docker specification will be generated. Subsequently, the image building process will be started according to the Dockerfile file, including pulling the base image, executing the building steps, and setting the environment configuration. During the image building process, the build log will also be recorded in real time, and the build results and generated image information will be displayed to the developer after the build is completed.

[0057] 102. Compare the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture.

[0058] In one embodiment of the present application, before comparing the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture, the following further includes:

[0059] According to the preset configuration information, determine the platform CPU architecture currently running on the DevOps platform, and receive the image building request through the DevOps platform;

[0060] According to the input parameters in the image building request, the target CPU architecture corresponding to the image to be generated is determined; wherein the input parameters include the CPU architecture type or the hardware requirements of the target deployment environment.

[0061] In one embodiment, in the implementation of the DevOps platform, preset configuration information is stored in the platform's configuration file, including but not limited to the type of operating system currently running on the platform, CPU architecture type (such as x86_64, ARM64, etc.), memory size and other hardware resource information. This information is read and stored in memory or database when the platform is started for quick access.

[0062] When a developer submits an image build request through the DevOps platform's API or developer interface, the request contains detailed information about the target image, one of the key pieces of information being the target CPU architecture. This information can be provided through an explicit CPU architecture type parameter, such as "x86_64" or "arm64". In addition, if the developer does not directly specify the CPU architecture, but provides the hardware requirements of the target deployment environment (such as a specific cloud service provider, hardware platform, or operating system version), the DevOps platform can infer the target CPU architecture based on this indirect information.

[0063] For example, if the developer specifies that the target deployment environment is AWS's EC2 instance type "m5.large", the DevOps platform knows that this instance type is based on the x86_64 architecture, and therefore determines that the target CPU architecture is x86_64.

[0064] Specifically, in one embodiment of the present application, comparing the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture specifically includes:

[0065] Determine the string corresponding to the target CPU architecture and the string corresponding to the platform CPU architecture of the DevOps platform;

[0066] Compare the string corresponding to the target CPU architecture with the string corresponding to the platform CPU architecture to obtain a corresponding comparison result;

[0067] Determine whether the character strings of the target CPU architecture and the platform CPU architecture are consistent according to the comparison result, so as to determine whether the target CPU architecture is consistent with the platform CPU architecture.

[0068] In one embodiment, in a specific DevOps platform implementation, in order to determine whether the target CPU architecture is consistent with the platform CPU architecture of the DevOps platform, the platform first needs to represent the two architectures in the form of strings. These strings are usually based on standardized architecture naming rules, such as x86_64 for 64-bit x86 architecture, arm64 for 64-bit ARM architecture, etc.

[0069] When developers submit image build requests, they usually specify the target CPU architecture. This information is received by the DevOps platform and parsed into a string, such as "x86_64" or "arm64". The DevOps platform determines and stores the CPU architecture of the currently running hardware platform at startup or during configuration. This information is also represented as a string, such as "x86_64" if the platform is a 64-bit processor based on Intel or AMD.

[0070] The DevOps platform uses a string comparison function or method to compare the target CPU architecture string with the platform CPU architecture string. This comparison is usually case-sensitive because the naming of CPU architectures is usually case-sensitive. If the two strings are exactly the same (that is, the character sequence and case are the same), the comparison result is "consistent", indicating that the target CPU architecture matches the platform CPU architecture. If the two strings are not the same, the comparison result is "inconsistent", indicating that the target CPU architecture does not match the platform CPU architecture.

[0071] 103. If yes, the Dockerfile file is called through the DevOps platform to build an image corresponding to the target CPU structure. If no, the Dockerfile file is called through the QEMU node to build the image, so as to realize the image generation across CPU architectures.

[0072] Specifically, in one embodiment of the present application, if not, before building an image by calling the Dockerfile file through the QEMU node to realize the image generation across CPU architectures, it also includes:

[0073] Install QEMU virtual machine software in the DevOps platform; the QEMU node corresponding to the QEMU virtual machine software is used to simulate the hardware environment corresponding to the CPU structure;

[0074] Install the Docker container software and Buildx plug-in on the DevOps platform. The Docker container software is used to build the image corresponding to the CPU architecture through the Buildx plug-in.

[0075] In one embodiment, in the implementation of the DevOps platform, in order to support image building across CPU architectures, QEMU virtual machine software is installed on the server of the DevOps platform. QEMU is an open source machine simulator and virtualizer that can simulate a variety of different CPU architectures and hardware environments on the host machine. After the installation is complete, QEMU nodes are also configured, which will be used to simulate the hardware environment of the target CPU architecture. For example, if the target architecture is ARM64, the QEMU node will be configured to simulate an ARM64 virtual machine.

[0076] Next, the Docker container software was installed on the DevOps platform. Docker is an open source application container engine that allows developers to package applications and their dependencies into a portable container and run them on any platform that supports Docker. In order to support cross-architecture image building, the Docker Buildx plug-in was also installed. Buildx is an extension of Docker that provides support for multi-platform building, allowing developers to build images suitable for multiple different platforms on one platform.

[0077] After that, Docker Buildx is configured to use the simulated environment provided by the QEMU node for cross-architecture image building. This usually involves setting some environment variables and configuration files to ensure that Docker Buildx knows how to communicate with the QEMU nodes and how to use them for building.

[0078] In one embodiment of the present application, if not, the Dockerfile file is called by the QEMU node to build the image, so as to realize the image generation across CPU architectures, specifically including:

[0079] When the target CPU architecture is inconsistent with the platform CPU architecture, it is scheduled to the QEMU node corresponding to the QEMU virtual machine software on the DevOps platform;

[0080] Through the QEMU node, the hardware environment corresponding to the target CPU architecture is simulated, so that the Docker container software can execute the instructions in the Dockerfile file corresponding to the image building process through the Buildx plug-in in the hardware environment corresponding to the target CPU architecture to build an image that matches the target CPU architecture.

[0081] In one embodiment, in the implementation of the DevOps platform, in order to cope with the challenge of inconsistency between the target CPU architecture and the platform CPU architecture, the platform integrates QEMU virtual machine software and Docker container software, and is equipped with a Docker Buildx plug-in.

[0082] In the case where the target CPU architecture is inconsistent with the platform CPU architecture, a cross-architecture build process will be decided. At this point, the DevOps platform will select a suitable QEMU node for scheduling based on the preset scheduling strategy or load balancing algorithm. QEMU nodes are servers or virtual machine instances with QEMU virtual machine software installed, which have the ability to simulate hardware environments with different CPU architectures. The selected QEMU node will start a virtual machine instance whose CPU architecture matches the target CPU architecture in the request. This simulation process includes copying the processor instruction set, memory model, and other related hardware features of the target architecture.

[0083] In the simulated hardware environment, the QEMU node installs the Docker container software and configures the Docker Buildx plug-in. The Docker Buildx plug-in is configured to recognize and utilize the simulated hardware environment to ensure that the built image is fully compatible with the target CPU architecture.

[0084] In the hardware environment simulated by the QEMU node, the Docker container software will load and parse the Dockerfile file, and build the image step by step according to the instructions in the Dockerfile, including installing necessary software packages, configuring environment variables, copying files, and performing other building steps. At the same time, the Docker Buildx plug-in will monitor and manage the entire building process to ensure that the image building meets multi-platform requirements.

[0085] After the build is complete, the QEMU node stores the images in the image repository of the DevOps platform, allowing developers to easily download and use these images from the image repository to deploy them to the hardware environment of the target CPU architecture.

[0086] In one embodiment of the present application, if yes, the Dockerfile file is called through the DevOps platform to build an image corresponding to the target CPU structure, specifically including:

[0087] When the target CPU architecture is consistent with the platform CPU architecture, call the Dockerfile file and parse the Dockerfile file;

[0088] Determine the instruction sequence in the Dockerfile file based on the parsing results, and execute each instruction in sequence according to the instruction sequence; the instructions include at least: copying files, installing dependencies, setting environment variables, and exposing ports.

[0089] In one embodiment, when the DevOps platform receives an image building request and determines that the target CPU architecture is consistent with the platform CPU architecture, the DevOps platform will first locate the specified Dockerfile file. Then, the Dockerfile file will be parsed. The parsing process includes reading the file content, identifying the instruction format, and extracting instruction parameters. The instructions in the Dockerfile file are usually written in a specific format, such as COPY, RUN, ENV, and EXPOSE, which are used to copy files, install dependencies, set environment variables, and expose ports, etc.

[0090] After parsing the Dockerfile, the platform will generate an instruction execution queue based on the order of the instructions. This queue ensures that the instructions in the Dockerfile can be executed in the order in which they are written. The platform will execute the instructions one by one in the order in the queue. For each instruction, the platform will call the corresponding Docker engine API or internal component to perform the specific operation.

[0091] For example, for the COPY instruction, the platform will copy the specified file or directory to the image; for the RUN instruction, the platform will execute the specified command inside the image to install dependencies or perform other operations; for the ENV instruction, the platform will set the environment variables in the image; for the EXPOSE instruction, the platform will record the ports that the image needs to expose.

[0092] As the instructions in the Dockerfile file are executed one by one, the image will be gradually built. After each instruction is executed, the platform will generate a new image layer. Finally, when all instructions are executed, the platform will generate a complete image.

[0093] Figure 2 A schematic diagram of a DevOps platform cross-CPU architecture image building process provided in an embodiment of the present application. Figure 2 As shown, on the DevOps platform, determine whether the target CPU structure is consistent with the platform CPU architecture of the DevOps platform. If so, directly build the image corresponding to the target CPU architecture on the DevOps platform. If not, it needs to be scheduled to the QEMU node, so as to build the image corresponding to the target CPU architecture on the QEMU node, thereby realizing the image generation across CPU architectures.

[0094] In one embodiment of the present application, it also includes:

[0095] During the image building process, the resource usage and construction progress of the QEMU node are monitored in real time;

[0096] After the build is complete, the generated image is verified, and the verified image is stored in the preset target image repository; the image verification is used to determine whether the image runs on the target CPU architecture.

[0097] In one embodiment, after the build process is started, the platform monitors the resource usage of the QEMU node in real time, including but not limited to CPU usage, memory usage, disk I / O, and network bandwidth, etc. The monitoring data is used to evaluate the performance of the build task and to adjust resources or optimize task scheduling when necessary.

[0098] At the same time, the DevOps platform also tracks the progress of the image build in real time. This usually involves parsing the build log provided by the Docker Buildx plugin to extract key information such as the current build stage, completed steps, and estimated remaining time. Real-time information on the build progress is displayed to developers or platform administrators to understand the latest status of the build task.

[0099] Once the image is built, the platform automatically starts the image verification process. The purpose of image verification is to ensure that the generated image can run correctly on the target CPU architecture. This usually involves running a series of automated tests to verify the basic functions, performance, and compatibility of the image. The verification process may include starting a QEMU virtual machine instance that matches the target CPU architecture and running the image in it for actual testing.

[0100] The images that have been verified and confirmed to be correct will be stored in the preset target image repository. The target image repository is a component in the DevOps platform that is specifically used to store and manage images. It provides image upload, download, version control, and access rights management functions. Developers can easily download and use these verified images from the target image repository to deploy them to the hardware environment of the target CPU architecture.

[0101] The above is an embodiment of the method proposed in this application. Based on the same inventive concept, the embodiment of this application also provides a DevOps platform cross-CPU architecture image generation device, whose structure is as follows Figure 3 shown.

[0102] Figure 3 The internal structure diagram of a cross-CPU architecture image generation device for a DevOps platform provided in an embodiment of the present application is shown in FIG. Figure 3 As shown, the device includes:

[0103] at least one processor;

[0104] and, a memory communicatively coupled to the at least one processor;

[0105] The memory stores instructions that can be executed by at least one processor, and the instructions are executed by at least one processor to enable the at least one processor to:

[0106] Create a Dockerfile file on the DevOps platform to define the image building process;

[0107] Compare the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture;

[0108] If yes, the Dockerfile file is called through the DevOps platform to build an image corresponding to the target CPU structure. If no, the Dockerfile file is called through the QEMU node to build the image, thus realizing image generation across CPU architectures.

[0109] The present application also provides a non-volatile computer storage medium storing computer executable instructions. When the computer executable instructions are executed, they can:

[0110] Create a Dockerfile file on the DevOps platform to define the image building process;

[0111] Compare the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture;

[0112] If yes, the Dockerfile file is called through the DevOps platform to build an image corresponding to the target CPU structure. If no, the Dockerfile file is called through the QEMU node to build the image, thus realizing image generation across CPU architectures.

[0113] Each embodiment in this application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0114] The above describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0115] The devices and media provided in the embodiments of the present application correspond one-to-one to the methods. Therefore, the devices and media also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0116] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0117] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0118] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0119] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0120] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0121] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0122] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0123] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0124] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for generating images across CPU architectures on a DevOps platform, characterized in that: The method comprises: Create a Dockerfile file on the DevOps platform to define the image building process; Comparing the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture; If yes, the Dockerfile file is called through the DevOps platform to build an image corresponding to the target CPU structure. If no, the Dockerfile file is called through the QEMU node to build an image, thereby realizing image generation across CPU architectures.

2. According to claim 1, a DevOps platform cross-CPU architecture image generation method is characterized in that: Before comparing the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture, the method further includes: Determine the platform CPU architecture currently running on the DevOps platform according to preset configuration information, and receive the image building request through the DevOps platform; According to the input parameters in the image building request, the target CPU architecture corresponding to the image to be generated is determined; wherein the input parameters include the CPU architecture type or the hardware requirements of the target deployment environment.

3. According to claim 1, a DevOps platform cross-CPU architecture image generation method is characterized in that: Comparing the target CPU architecture with the platform CPU architecture of the DevOps platform to determine whether the target CPU architecture is consistent with the platform CPU architecture, specifically including: Determine a string corresponding to the target CPU architecture and a string corresponding to the platform CPU architecture of the DevOps platform; Compare the character string corresponding to the target CPU architecture with the character string corresponding to the platform CPU architecture to obtain a corresponding comparison result; Determine whether the character strings of the target CPU architecture and the platform CPU architecture are consistent according to the comparison result, so as to determine whether the target CPU architecture is consistent with the platform CPU architecture.

4. According to claim 1, a DevOps platform cross-CPU architecture image generation method is characterized in that: If not, before building an image by calling the Dockerfile file through the QEMU node to realize image generation across CPU architectures, the method further includes: Installing QEMU virtual machine software in the DevOps platform; wherein the QEMU node corresponding to the QEMU virtual machine software is used to simulate the hardware environment corresponding to the CPU structure; Docker container software and Buildx plug-in are installed in the DevOps platform; wherein the Docker container software is used to build an image corresponding to the CPU architecture through the Buildx plug-in.

5. According to claim 4, a DevOps platform cross-CPU architecture image generation method is characterized in that: If not, the Dockerfile file is called by the QEMU node to build the image, so as to realize the image generation across CPU architectures, which specifically includes: When the target CPU architecture is inconsistent with the platform CPU architecture, scheduling to a QEMU node corresponding to the QEMU virtual machine software on the DevOps platform; The QEMU node is used to simulate the hardware environment corresponding to the target CPU architecture, so that the Docker container software can execute the instructions in the Dockerfile file corresponding to the image building process through the Buildx plug-in under the hardware environment corresponding to the target CPU architecture to build an image that matches the target CPU architecture.

6. The method for generating a cross-CPU architecture image on a DevOps platform according to claim 1, characterized in that: The method further comprises: During the image building process, the resource usage and construction progress of the QEMU node are monitored in real time; After the construction is completed, the generated image is verified, and the verified image is stored in a preset target image repository; wherein the image verification is used to determine that the image runs on the target CPU architecture.

7. The method for generating a cross-CPU architecture image on a DevOps platform according to claim 1, characterized in that: If yes, the Dockerfile is called through the DevOps platform to build an image corresponding to the target CPU structure, specifically including: When the target CPU architecture is consistent with the platform CPU architecture, calling the Dockerfile file and parsing the Dockerfile file; The instruction sequence in the Dockerfile file is determined according to the parsing result, and each instruction is executed in sequence according to the instruction sequence; wherein the instructions at least include: copying files, installing dependencies, setting environment variables and exposing ports.

8. The method for generating a cross-CPU architecture image on a DevOps platform according to claim 1, characterized in that: Create a Dockerfile file on the DevOps platform to define the image building process, including: Based on a click trigger on the visualization interface, a definition template corresponding to the Dockerfile file is returned to the visualization interface, and configuration information of the image building process returned based on the definition template is received through an API interface on the DevOps platform; wherein the configuration information includes a base image, building steps, and environment configuration; A syntax check is performed on the configuration information, and if the check passes, a Dockerfile file corresponding to the image building process is created on the DevOps platform according to the configuration information.

9. A cross-CPU architecture image generation device for a DevOps platform, characterized in that: The device comprises: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a DevOps platform cross-CPU architecture image generation method as described in any one of claims 1-8.

10. A non-volatile computer storage medium storing computer executable instructions, characterized in that: When the computer executable instructions are executed, a method for generating a cross-CPU architecture image for a DevOps platform as described in any one of claims 1 to 8 is implemented.

Images