File processing method and device, storage medium and equipment

Abstract

The embodiment of the invention discloses a file processing method and device, a storage medium and equipment, metadata is obtained, and the metadata at least comprises a configuration file and a construction file template; the configuration file comprises configuration data corresponding to each computer architecture; respectively rendering the construction file template according to the configuration data corresponding to each computer architecture, and generating a construction file corresponding to each computer architecture; and constructing a mirror image file corresponding to each computer architecture based on the construction file, and performing multi-architecture deployment according to the mirror image files. Therefore, the configuration file and the construction file template are preset, and the set configuration file comprises the configuration data corresponding to each computer architecture, so that the construction file template is quickly rendered according to the configuration data corresponding to each computer architecture, and the construction file corresponding to each computer architecture is generated; automatic multi-architecture deployment is achieved, construction files of the computer architecture do not need to be manually processed, the file processing efficiency is improved, and the labor cost is saved.

Description

Technical Field

[0001] The present application relates to the field of cloud technology, and in particular to a file processing method, device, storage medium and equipment. Background Art

[0002] Private Cloud, as the name implies, is a private cloud computing environment built within an organization or enterprise. It is to create cloud infrastructure and software and hardware resources within a firewall so that various departments within the organization or enterprise can share resources in the data center. Compared with public cloud services, private cloud has higher security and controllability for enterprises. It is usually composed of a group of servers, which can provide flexible computing resources and more professional technical support to users within the enterprise.

[0003] In a private cloud scenario, each enterprise can be privately deployed through source code, that is, a private cloud computing environment that is used separately by each enterprise can be built through source code to provide effective control over data security and service quality. However, due to the different computer architectures of different enterprises, the written source code needs to be configured for the operating environment according to different computer architectures. For example, the corresponding Dockerfile (build file) can be manually maintained for each computer architecture. Dockerfile is used to define the content and startup behavior of a single container and automatically build a configuration file for the Docker image. Users can use Dockerfile to quickly create image files of different computer architectures to achieve private deployment under different computer architectures.

[0004] However, this manual maintenance method has low processing efficiency, and with the continuous updating and iteration of computer equipment, the corresponding computer architecture will become more and more, resulting in more and more Dockerfiles that need to be manually maintained, making the manual maintenance process more and more cumbersome and the manual maintenance cost higher and higher. Summary of the invention

[0005] The embodiments of the present application provide a file processing method, apparatus, storage medium and device, which can improve the efficiency of file processing and reduce the labor cost of file processing.

[0006] To solve the above technical problems, the present application provides the following technical solutions:

[0007] A file processing method, comprising:

[0008] Obtaining metadata, the metadata including at least a configuration file and a build file template;

[0009] Wherein, the configuration file includes configuration data corresponding to each computer architecture;

[0010] Rendering the build file templates respectively according to the configuration data corresponding to each computer architecture to generate a build file corresponding to each computer architecture;

[0011] An image file corresponding to each computer architecture is constructed based on the construction file, and multi-architecture deployment is performed according to the image file.

[0012] A file processing device, comprising:

[0013] An acquisition unit, used for acquiring metadata, wherein the metadata at least includes a configuration file and a construction file template;

[0014] Wherein, the configuration file includes configuration data corresponding to each computer architecture;

[0015] A generating unit, configured to render the build file templates according to the configuration data corresponding to each computer architecture, and generate a build file corresponding to each computer architecture;

[0016] A deployment unit is used to build an image file corresponding to each computer architecture based on the build file, and perform multi-architecture deployment according to the image file.

[0017] In some implementations, the metadata further includes a preset script, and the generating unit is configured to:

[0018] The preset script is executed, and the configuration data corresponding to each computer architecture is called to render the build file template respectively, so as to generate the build file corresponding to each computer architecture.

[0019] In some implementations, the construction file template includes at least a placeholder, and the generating unit includes:

[0020] An acquisition subunit, used to execute the preset script to acquire configuration data corresponding to each computer architecture;

[0021] A replacement subunit, used to replace the placeholders in the build file template with the configuration data corresponding to each computer architecture, so as to obtain the replaced build file template of each computer architecture;

[0022] The generation subunit is used to generate a build file corresponding to each computer architecture according to the replaced build file template of each computer architecture.

[0023] In some embodiments, the acquisition subunit is used to:

[0024] Execute the preset script to obtain the common configuration data in the configuration file and the exclusive configuration data of each computer architecture;

[0025] The general configuration data and the architecture-specific configuration data of each computer architecture are respectively combined to generate configuration data corresponding to each computer architecture.

[0026] In some embodiments, the device further includes an architecture adding unit, configured to:

[0027] When an architecture-new instruction is detected, receiving exclusive configuration data corresponding to the newly added computer architecture;

[0028] Add the dedicated configuration data corresponding to the newly added computer architecture to the configuration file.

[0029] In some embodiments, the device further includes a source code detection unit, which is used to:

[0030] When source code changes are detected, deployment instructions are generated;

[0031] In response to the deployment instruction, an acquisition unit is executed.

[0032] In some embodiments, the device further comprises a modification unit, configured to:

[0033] Receiving corresponding configuration modification instructions when the source code changes;

[0034] Modify the configuration data in the configuration file based on the configuration modification instruction;

[0035] The placeholders in the build file template are modified based on the configuration modification instruction.

[0036] In some embodiments, the replacement subunit is used to:

[0037] Determining the data type of each placeholder in the build file template;

[0038] The configuration data of each computer architecture replaces the corresponding placeholders in the build file according to the data type, so as to obtain a replaced build file template for each computer architecture.

[0039] In some embodiments, the generating subunit is used to:

[0040] Get the template content in the replaced build file template for each computer architecture;

[0041] Write the template content of each computer architecture into the newly created build file to obtain the corresponding build file for each computer architecture.

[0042] In some embodiments, the deployment unit is used to:

[0043] Get the source code to be called;

[0044] Execute the build file corresponding to each computer architecture and call the source code respectively to generate the image file corresponding to each computer architecture;

[0045] Deploy each of the image files on a corresponding computer device according to the computer architecture type.

[0046] A computer-readable storage medium stores a plurality of instructions, wherein the instructions are suitable for a processor to load to execute the steps in the above-mentioned file processing method.

[0047] A computer device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps in the above-mentioned file processing method when executing the computer program.

[0048] A computer program product or a computer program, the computer program product or the computer program comprises computer instructions, the computer instructions are stored in a storage medium. A processor of a computer device reads the computer instructions from the storage medium, and the processor executes the computer instructions, so as to implement the steps in the above-mentioned file processing method.

[0049] The embodiment of the present application obtains metadata, and the metadata includes at least a configuration file and a build file template; wherein the configuration file includes configuration data corresponding to each computer architecture; the build file template is rendered according to the configuration data corresponding to each computer architecture, and the build file corresponding to each computer architecture is generated; the image file corresponding to each computer architecture is constructed based on the build file, and multi-architecture deployment is performed according to the image file. In this way, by presetting the configuration file and the build file template, and setting the configuration file to include the configuration data corresponding to each computer architecture, it is possible to quickly render the build file template according to the configuration data corresponding to each computer architecture, generate the build file corresponding to each computer architecture, and realize multi-architecture deployment. Compared with the solution in the related art that requires manual maintenance of the build file of each computer architecture, the embodiment of the present application does not need to manually process the build file of the computer architecture, thereby improving the efficiency of file processing and saving labor costs.

[0050] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0052] Figure 1 An architectural diagram of the Dockerfile provided in the embodiment of the present application;

[0053] Figure 2 A schematic diagram of a scenario of a file processing system provided in an embodiment of the present application;

[0054] Figure 3 A flowchart of a file processing method provided in an embodiment of the present application;

[0055] Figure 4 A multi-architecture deployment scenario provided for an embodiment of the present application;

[0056] Figure 5 New architecture scenarios provided for embodiments of this application;

[0057] Figure 6 A schematic diagram of the structure of metadata provided in the embodiment of the present application;

[0058] Figure 7 A schematic diagram of the structure of a construction file template provided in an embodiment of the present application;

[0059] Figure 8 A schematic diagram of the structure of a configuration file provided in an embodiment of the present application;

[0060] Fig. 9 Another schematic diagram of the structure of the configuration file provided in the embodiment of the present application;

[0061] Fig.10 Another schematic diagram of a process flow of a file processing method provided in an embodiment of the present application;

[0062] Fig.11 Another schematic diagram of a process flow of a file processing method provided in an embodiment of the present application;

[0063] Fig.12 Another schematic diagram of a process flow of a file processing method provided in an embodiment of the present application;

[0064] Fig.13 A schematic diagram of a file processing method provided in an embodiment of the present application;

[0065] Fig.14 Another schematic diagram of a process flow of a file processing method provided in an embodiment of the present application;

[0066] Fig.15 is a structural schematic diagram of a file processing device provided in an embodiment of the present application;

[0067] Fig.16 It is a schematic diagram of the structure of the server provided in the embodiment of the present application. DETAILED DESCRIPTION

[0068] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. 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 those skilled in the art without creative work are within the scope of protection of the present application.

[0069] The data collection and processing in this application should be strictly in accordance with the requirements of relevant national laws and regulations when applied in practice, and the informed consent or separate consent of the personal information subject should be obtained. Subsequent data use and processing should be carried out within the scope of authorization of laws and regulations and the personal information subject.

[0070] It should be noted that in some processes described in the specification, claims and the above-mentioned drawings, multiple steps appearing in a specific order are included, but it should be clearly understood that these steps may not be executed in the order in which they appear in this document or may be executed in parallel. The step numbers are only used to distinguish different steps, and the numbers themselves do not represent any execution order. In addition, descriptions such as "first", "second" or "preset" in this document are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0071] Before further describing the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations:

[0072] Source code: Source code is the most original code for writing program software and is a programming language.

[0073] Build: The process of turning code into an executable file is called compilation. Compiling this file first or compiling that file first (i.e. the arrangement of compilation) is called build.

[0074] Deployment, deployment simply means deploying the built image to the corresponding computer device.

[0075] A script is an executable file written in a specific descriptive language and in a certain format.

[0076] Computer architecture, also known as computer system architecture, is the property of a computer as seen by programmers, that is, the logical structure and functional characteristics of the computer, including the relationship between its various hardware and software components. For computer system designers, computer architecture refers to the study of the basic design ideas of computers and the resulting logical structure. For programmers, it refers to the functional description of the system (such as instruction set, compilation method, etc.). For example, X86 architecture, ARM architecture, and PowerpC architecture. Different computer architectures have different logical structures and functional characteristics due to different functional descriptions of the system, so the corresponding source code also needs to be configured for the corresponding operating environment according to different computer architectures. For example, the corresponding Dockerfile (build file) can be manually maintained for each computer architecture. Dockerfile is used to define the content and startup behavior of a single container. It is a configuration file for automatically building a Docker image. Users can use Dockerfile to quickly create image files corresponding to different computer architectures to achieve private deployment under different computer architectures.

[0077] The X86 architecture: The X86 architecture is a computer language instruction set executed by a microprocessor. It refers to a standard numbering abbreviation for an Intel general-purpose computer series and also identifies a set of general-purpose computer instruction sets.

[0078] ARM architecture: formerly known as Advanced RISC Machine (Advanced RISC Machine) and earlier known as AcornRISC Machine, is a 32-bit reduced instruction set (RISC) processor architecture.

[0079] The Powerpc architecture is a reduced instruction set computing (RISC) processor architecture.

[0080] Mirroring files are a form of file storage and a type of redundancy. The data on one disk has an identical copy on another disk, which is called a mirror. Many files can be made into a mirror file, which can be generally understood as a software deliverable that can be run to provide services.

[0081] Containers are lightweight virtualized runtime environments for running applications. Each container represents a software package that contains the code, system tools, libraries, dependencies, and configuration files required to run a specific application. In layman's terms, it can be understood as the running state of the software.

[0082] Docker is an open source application container engine that allows developers to package their applications and dependent packages into a portable image and then publish it to any popular Linux or Windows operating system machine, and can also achieve virtualization.

[0083] The build file (Dockerfile) is a configuration file used to define the content and startup behavior of a single container and automatically build a Docker image. Users can use Dockerfile to quickly create image files for different computer architectures and specify in the Dockerfile what code is needed and what configuration it depends on.

[0084] That is, Dockerfile is a text file that contains all the commands for creating an image. It contains instructions and descriptions. Each instruction builds a layer. Through the Docker build command, the image is built according to the content of the Dockerfile. Therefore, the content of each instruction describes the layer. With Dockerfile, you can formulate your own Docker image rules. You only need to add or modify instructions on the Dockerfile to generate a Docker image, so that the cloud computing control system source code can run on each different architecture, realizing multi-architecture cloud computing control services.

[0085] To better illustrate the embodiments of this application, please refer to Figure 1 As shown, Figure 1 An architectural diagram of the Dockerfile provided in the embodiment of the present application.

[0086] Dockerfile A: Execute Dockerfile. Dockerfile is the raw material of the software. The execution process is that Dockerfile runs a container from the base image, executes an instruction and makes changes to the image, and performs a similar Dockers commit operation to submit a new image layer. Docker runs a container based on the image just submitted and executes the next instruction in the Dockerfile until all instructions are executed.

[0087] Dockerfile Image B: Dockerfile Image B is the software deliverable. After defining a file with Dockerfile, a Docker image is generated during Docker build. When the Docker image is run, the service is actually started.

[0088] Dockerfile container C: Dockerfile container C is the running state of the software, which runs Dockerfile image B on the corresponding computer architecture to provide services.

[0089] Docker containers allow developers to package their applications with the required dependencies (such as configurations, frameworks, libraries, and runtimes) into them, thereby achieving portability of applications between different cloud computing platforms. That is, the corresponding Dockerfile can be manually maintained for each computer architecture to achieve subsequent private deployment under different computer architectures.

[0090] In private cloud scenarios, in the past, most customers tended to deploy cloud computing management and control systems in an X86 architecture environment. However, with the continuous updating and iteration of computer equipment, there are more and more corresponding computer architectures. Gradually, some customers choose to deploy cloud computing management and control systems in an ARM architecture environment, and may even deploy them in a Powerpc architecture environment.

[0091] In the related technology, a separate processing method is adopted for the "source code-build-deployment" process in the current multi-computer architecture scenario, that is, each computer architecture needs to establish a separate "build-deployment" process, and manually maintain the corresponding Dockerfile for each computer architecture. The reason why the corresponding Dockerfile needs to be maintained is that the container environment (that is, the configuration environment) required for the source code to run is different for different computer architectures, so different dockerfiles are needed for different computer architectures to generate different container environments to run cloud computing management and control services.

[0092] However, this manual maintenance method has low processing efficiency, and as the number of computer architectures increases, the number of Dockerfiles that need to be manually maintained also increases. The maintenance method becomes more and more cumbersome, and the cost rises sharply.

[0093] In order to solve the above problems, the embodiment of the present application proposes a "generative" method to generate Dockerfiles under different architectures, without the need to manually generate and maintain a large number of Dockerfiles, which greatly improves the efficiency of file processing and reduces the labor cost of file processing.

[0094] See also Figure 2 , Figure 2The scenario diagram of the file processing system provided for the embodiment of the present application includes: a terminal 110, and a server 120 (the file processing system may also include other terminals 110 in addition to the terminal 110, and the specific number of the terminal 110 is not limited here), the terminal 110 and the server 120 may be connected through a communication network, and the communication network may include a wireless network and a wired network, wherein the wireless network includes a combination of one or more of a wireless wide area network, a wireless local area network, a wireless metropolitan area network, and a wireless personal network. The network includes network entities such as routers and gateways, which are not shown in the figure. The terminal 110 can exchange information with the server 120 through the communication network, for example, the terminal 110 can send metadata to the server 120.

[0095] The file processing system may include a file processing device, which may be integrated in a server 120. The server 120 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Figure 1 As shown, the server 120 obtains metadata, which includes at least a configuration file and a build file template; wherein the configuration file includes configuration data corresponding to each computer architecture; the build file template is rendered according to the configuration data corresponding to each computer architecture, and a build file corresponding to each computer architecture is generated; an image file corresponding to each computer architecture is constructed based on the build file, and multi-architecture deployment is performed according to the image file.

[0096] The terminal 110 in the file processing system may be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited thereto. The terminal 110 may install various applications required by the user, such as program development applications and browser applications, etc. The terminal 110 may receive metadata set by the user and send the metadata to the server 120.

[0097] It should be noted that Figure 2 The scenario diagram of the file processing system shown is merely an example. The file processing system and scenario described in the embodiment of the present application are intended to more clearly illustrate the technical solution of the embodiment of the present application, and do not constitute a limitation on the technical solution provided in the embodiment of the present application. A person of ordinary skill in the art can appreciate that with the evolution of the file processing system and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is equally applicable to similar technical problems.

[0098] In this embodiment, the description will be made from the perspective of a file processing device. The file processing device can be specifically integrated in a computer device having a storage unit and a microprocessor installed with computing capabilities. The computer device can be a terminal or a server. In this embodiment, the computer device is described as a server.

[0099] See also Figure 3 , Figure 3 : is a flowchart of a file processing method provided in an embodiment of the present application. The file processing method includes:

[0100] In step 201, metadata is obtained.

[0101] Related technology, in the private cloud scenario, for the "source code-build-deployment" process in the current multi-computer architecture scenario, a separate processing method is adopted, that is, each computer architecture needs to establish a separate "build-deployment" process, and manually maintain the corresponding Dockerfile for each computer architecture. The reason why the corresponding Dockerfile needs to be maintained is that for different computer architectures, the container environment (i.e., configuration environment) required for the source code to run is different, so different dockerfiles need to be used for different computer architectures to generate different container environments to run cloud computing management and control services.

[0102] To better illustrate the embodiments of this application, please refer to Figure 4 As shown, Figure 4 The multi-architecture deployment scenario provided in the embodiment of the present application is composed of cloud computing management and control system source code 11, abstract architecture 12, X86 environment deployment 13 and ARM environment deployment.

[0103] The cloud computing management and control system source code 11 (hereinafter referred to as source code) has a unified source and can be managed in a unified manner using a version repository.

[0104] The abstract architecture 12 includes a general configuration, a difference manager, a general pipeline and a multi-architecture product manager. The general configuration refers to the configuration items that all architectures will use. These common configuration items are extracted and saved in a file, and all architectures can use them to avoid maintenance in multiple places. The difference manager is used to separate the differences between different computer architectures, and each computer architecture is uniformly managed by the corresponding Dockerfile. The general pipeline is used to implement the construction based on the source code, general configuration and the Dockerfile of each computer architecture, and generate the corresponding product (i.e., image file). The multi-architecture product manager is used to manage the image files of each computer architecture.

[0105] The X86 environment deployment 13 and the ARM environment deployment 14 are customer environment deployments. The multi-architecture product manager will push the image files of the corresponding computer architecture to the computer devices of the corresponding customers so that the operation and maintenance personnel can get the image files for deployment.

[0106] It is understandable that in the above method, different computer architectures need to maintain a separate Dockerfile, and the computer management and control system often contains multiple services, each service represents a function, such as user management, product display, payment and other functions. Each service is decoupled when deployed, and the advantage is that one service downtime does not affect other services. Therefore, under different services, each computer architecture also needs to maintain a separate Dockerfile. For example, if the cloud computing management and control system has 20 services, then the X86 architecture needs to maintain 20 Dockerfiles, and correspondingly, the ARM architecture also needs to maintain 20 Dockerfiles, that is, 40 Dockerfiles need to be generated and maintained at the same time. This manual maintenance method has extremely low processing efficiency, and manual code needs to be repeatedly written to generate Dockerfiles, and the labor cost is high. And as more and more computer architectures are added, the number of Dockerfiles that need to be maintained manually is also increasing. For example, if an architecture is added, 20 additional Dockerfiles need to be added manually. At this time, more Dockerfiles need to be maintained, and the maintenance process becomes more and more cumbersome, and the cost rises sharply.

[0107] Please also read Figure 5 As shown, Figure 5 The newly added architecture scenario provided in the embodiment of the present application consists of a newly added Powerpc architecture 21 and a directory structure 22. After executing the newly added Powerpc architecture 21, it is necessary to add a corresponding Powerpc architecture Dockerfile for each service in the directory structure 22 of the difference manager, for example, manually add Dockerfile.Powerpc221 for service-A, and manually add Dockerfile.Powerpc222 for service-B. Assuming there are 20 services, it is necessary to manually add the corresponding Dockerfile under all 20 services. The process is very cumbersome, and each Dockerfile needs to manually set the corresponding instructions, the maintenance cost is very high, and it is easy to make mistakes.

[0108] It can be seen that with the increasing number of computer architecture types, the generation, maintenance and management process of related technologies will become more and more complicated and the cost will be higher and higher. Therefore, in order to solve the above problems, the embodiment of the present application can automatically generate each computer architecture Dockerfile during the construction process, improve the efficiency of file processing, and reduce the labor cost of file processing. For specific implementation methods, please continue to refer to the following embodiments.

[0109] In an embodiment of the present application, metadata may be set, and the metadata may include at least a configuration file and a build file template, wherein the configuration file includes configuration data corresponding to each computer architecture, such as configuration data corresponding to the base image. The build file template may describe the necessary content required to run the corresponding service, and the specific parameters of these necessary contents may be obtained from the attached data, that is, the template file may be pre-set, and the build file template may include a set section of program, through which the configuration data under each computer architecture may be replaced to the corresponding position in the build file template, respectively, so that the build file template becomes a usable Dockerfile. The section of program in the build file template may be written in template engine syntax, such as Jinja2, which is a template engine based on python, and may dynamically generate Dockerfiles under different computer architectures according to the configuration data of different computer architectures.

[0110] In step 202, the build file templates are rendered according to the configuration data corresponding to each computer architecture, and the build files corresponding to each computer architecture are generated.

[0111] Among them, the configuration data corresponding to each computer architecture can be understood as a variable value, and the configuration data is a specific parameter for implementing subsequent instructions. A corresponding alternative position is set for each configuration data in the build file template, and the alternative position waits for subsequent configuration data to be filled. Therefore, the build file template is rendered separately through the configuration data corresponding to each computer architecture, and the configuration data corresponding to each computer architecture is filled into the alternative position in the build file template, so that the build file template becomes a Dockerfile available under each computer architecture.

[0112] For example, when the computer architecture includes X86 architecture and ARM architecture, the configuration data of the X86 architecture can be used to render the build file template, and the corresponding configuration data of the X86 architecture can be filled in the alternative position of the build file template to generate a corresponding usable Dockerfile under the X86 architecture. The configuration data of the ARM architecture can also be used to render the build file template, and the configuration data of the ARM architecture can be filled in the alternative position of the build file template to generate a corresponding usable Dockerfile under the ARM architecture.

[0113] In some embodiments, the metadata also includes a preset script, which is also referred to in Fig.10 As shown, step 202 includes:

[0114] In step 301, the preset script is executed, and the configuration data corresponding to each computer architecture is called to render the build file template respectively, so as to generate the build file corresponding to each computer architecture.

[0115] The metadata also includes a preset script, which is an executable file written in a certain format, such as a general generate.sh script, which is used to automatically generate a Dockerfile. In this way, the preset script can be executed to call the configuration data corresponding to each computer architecture to render the build file template respectively, that is, the configuration data corresponding to each computer architecture is automatically filled into the replacement position in the build template through the preset script, so that the build file becomes a Dockerfile available under each computer architecture.

[0116] To better illustrate the embodiments of this application, please refer to Figure 6 As shown, Figure 6 A schematic diagram of the structure of metadata provided in an embodiment of the present application.

[0117] 1. The outer layer of the metadata directory structure 30 maintains a general generate.sh script for automatically generating a Dockerfile.

[0118] 2. Create a separate directory for each service (for example: service-A, service-B, etc.) to facilitate organization and management.

[0119] 3. Inside each service directory, create two subdirectories, common and Dockerfile.

[0120] 4. The common directory is used to store configuration files shared by various services.

[0121] 5. The Dockerfile directory is used to store build file templates and corresponding configuration files, which will be used to generate Dockerfiles for multiple architectures. For example, service-A includes Dockerfile.yaml31 and Dockerfile.tmpl32, and service-B includes Dockerfile.yaml33 and Dockerfile.tmpl34.

[0122] In this way, placing common scripts in the outermost directory helps to improve the agent reuse rate and reduce duplicate code. Through a unified directory structure and common scripts, the management cost of multi-architecture compilation is reduced, which helps to improve the work efficiency of the development and operation and maintenance teams.

[0123] It should be noted that the configuration files and build file templates under each service in the embodiment of the present application are different. Therefore, each service needs to execute a preset script separately, call the corresponding configuration data of each computer architecture under the corresponding service, render the build file template respectively, and generate the corresponding build file for each architecture under the corresponding service.

[0124] In some embodiments, the build file template includes at least placeholders, such as Fig.11 As shown, step 301 includes:

[0125] In step 401, configuration data corresponding to each computer architecture is obtained.

[0126] In step 402, the configuration data corresponding to each computer architecture replaces the placeholders in the build file template respectively, so as to obtain the replaced build file template of each computer architecture.

[0127] In step 403, a build file corresponding to each computer architecture is generated according to the replaced build file template of each computer architecture.

[0128] The placeholder is a replacement position, which can be understood as a symbol that occupies a fixed position first and waits for content to be added thereto later. Therefore, a placeholder can be set in the build file template to be used to fill in the corresponding configuration data later.

[0129] To better illustrate the embodiments of this application, please refer to Figure 7 As shown, Figure 7 A schematic diagram of the structure of the build file template provided for the embodiment of the present application. The build file template 40 is a text file containing placeholders and control structures, where the control structure refers to a program set in a certain order, which is responsible for replacing the configuration data in the configuration file with the placeholders in the build file template to generate a Dockerfile. The placeholders and control structures in the build file template are written using a specific template engine syntax, such as Jinja2, so that the placeholders in the build file template can be replaced according to the configuration data of different computer architectures, and Dockerfiles under different computer architectures can be dynamically generated.

[0130] exist Figure 7 In the example, the build file template includes the following directives and placeholders:

[0131] 1. Base image: Use the {{base_image}} placeholder to specify the base image for the build stage.

[0132] 2. Build command: Use the {{build_command}} placeholder between {% for build_command in Build_commands %} and {% endfor %} to represent the command used to execute the build phase.

[0133] 3. Runtime base image: Use the {{runtime_base_image}} placeholder to specify the base image of the runtime stage.

[0134] 4. Working directory: Use the {{app_home}} placeholder to set the working directory of the application.

[0135] 5. Environment variables: Use the {{env_var}} placeholder between {% for env_var, value in environment_variables.items()%} and {% endfor%} to set the environment variables of the application.

[0136] 6. Build output: Use the {{build_output}} placeholder to specify the file or directory copied from the build phase to the runtime phase.

[0137] 7. Runtime command: Use {{runtime_command}} between {% for runtime_command in runtime_commands %} and {% endfor %} to execute commands in the runtime phase.

[0138] 8. Exposed port: Use the {{app_port}} placeholder to specify the exposed port of the application.

[0139] 9. Startup command: Use the {{cmd}} placeholder to specify the startup command of the application.

[0140] It should be noted that the values ​​in the above placeholders are to be filled, that is, the above placeholders in the build file template need to be filled with the configuration data in the configuration file to obtain the necessary content required to run the corresponding service. The structure of the build file template exemplified above is only for better illustrating the embodiment of the present application, and is not intended to limit the structure of the build file template. The build file template may also include other combinations of instructions and corresponding placeholders.

[0141] In this way, the generate.sh script can be executed to obtain the configuration data corresponding to each computer architecture. The configuration data of each computer architecture is different. Then, the corresponding configuration data of each computer replaces the placeholders in the build file template according to the data type to obtain the replaced build file template of each computer architecture. The replaced build file template of each computer architecture contains the necessary content required to describe the operation of the corresponding service. Therefore, the corresponding build file (i.e., image file or material package) of each computer architecture can be automatically generated according to the replaced build file template of each computer architecture, without the need to manually create or maintain the corresponding build file, which greatly improves the efficiency of file processing and reduces labor costs.

[0142] For example, replace the corresponding {{base_image}} placeholder in the build file template with the configuration data of the base image under the X86 architecture, replace the corresponding {{build_command}} placeholder in the build file template with the configuration data of the build command under the X86 architecture, replace the corresponding {{runtime_base_image}} placeholder in the build file template with the configuration data of the runtime base image under the X86 architecture, replace the corresponding {{app_home}} placeholder in the build file template with the configuration data of the working directory under the X86 architecture, and replace the corresponding {{build_command}} placeholder in the build file template with the configuration data of the environment variables under the X86 architecture. Replace the corresponding {{env_var}} placeholder in the template with the configuration data of the build output under the X86 architecture, replace the corresponding {{build_output}} placeholder in the build file template with the configuration data of the runtime command under the X86 architecture, replace the corresponding {{runtime_command}} placeholder in the build file template with the configuration data of the exposed port under the X86 architecture, and replace the corresponding {{app_port}} placeholder in the build file template with the configuration data of the startup command under the X86 architecture, and obtain the replaced X86 architecture build file template. And

[0143] Replace the corresponding {{base_image}} placeholder in the build file template with the configuration data of the base image under the ARM architecture, replace the corresponding {{build_command}} placeholder in the build file template with the configuration data of the build command under the ARM architecture, replace the corresponding {{runtime_base_image}} placeholder in the build file template with the configuration data of the runtime base image under the ARM architecture, replace the corresponding {{app_home}} placeholder in the build file template with the configuration data of the working directory under the ARM architecture, and replace the configuration data of the environment variables under the ARM architecture with the build file template. The corresponding {{env_var}} placeholder in the build file template is replaced with the configuration data of the build output under the ARM architecture, the corresponding {{build_output}} placeholder in the build file template is replaced with the configuration data of the runtime command under the ARM architecture, the corresponding {{runtime_command}} placeholder in the build file template is replaced with the configuration data of the exposed port under the ARM architecture, and the corresponding {{app_port}} placeholder in the build file template is replaced with the configuration data of the startup command under the ARM architecture, to obtain the replaced build file template for the ARM architecture.

[0144] In this way, the build file of the X86 architecture and the build file of the ARM architecture are automatically generated according to the replaced build file template of the X86 architecture and the build file template of the ARM architecture.

[0145] In some implementations, obtaining configuration data corresponding to each computer architecture includes:

[0146] (1) obtaining common configuration data and specific configuration data for each computer architecture in the configuration file;

[0147] (2) The general configuration data and the architecture-specific configuration data of each computer architecture are respectively combined to generate configuration data corresponding to each computer architecture.

[0148] Among them, the configuration file can be divided into general configuration data and exclusive configuration data for each computer architecture. The general configuration data is configuration data common to each computer architecture, and the exclusive configuration data is configuration data dedicated to the corresponding computer architecture. The exclusive configuration data for each computer architecture is different.

[0149] To better illustrate the embodiments of this application, please refer to Figure 8 As shown, Figure 8 A schematic diagram of the structure of a configuration file provided in an embodiment of the present application. The configuration file 50 includes general configuration data 51 and configuration data 52 specific to each computer architecture.

[0150] The general configuration data 51 includes the configuration data under the build command (i.e., build_command):

[0151] - "pip install --upgrade pip".

[0152] -"pip install -r requirements.txt".

[0153] Configuration data under the working directory (i.e. app_home): " / app".

[0154] Configuration data under environment variables (ie env_var):

[0155] FLASK_APP: "app.py".

[0156] FLASK_RUN_HOST: "0.0.0.0".

[0157] FLASK_RUN_PORT: "5000".

[0158] Configuration data under build output (i.e. build_output): ".".

[0159] Configuration data under runtime command (i.e. runtime_command): - "pip install gunicorn".

[0160] Configuration data under the exposed port (i.e. app_port): "5000".

[0161] Configuration data under the startup command (ie cmd): "gunicorn -w 4 -b 0.0.0.0:5000app:app".

[0162] The exclusive configuration data 52 includes the exclusive configuration data of the X86 architecture:

[0163] Configuration data under the base image (i.e. base_image): "python3.8 as build".

[0164] Configuration data under the runtime base image (i.e. runtime_base_image): "python3.8-slim".

[0165] ARM architecture-specific configuration data:

[0166] Configuration data under the base image (i.e. base_image): "arm32v7 / python3.8 as build".

[0167] Configuration data under the runtime base image (i.e. runtime_base_image): "arm32v7 / python3.8-slim".

[0168] It should be noted that the structure of the configuration file exemplified above is only for better illustrating the embodiment of the present application, and is not intended to limit the structure of the configuration file. The configuration file may also include a combination of general configuration data and exclusive configuration data.

[0169] Furthermore, the general configuration data and the architecture-specific configuration data of each computer architecture can be combined to generate complete configuration data corresponding to each computer architecture. For example, the general configuration data 61 and the architecture-specific configuration data can be combined to generate the configuration data of the X86 architecture. The general configuration data 61 and the architecture-specific configuration data can be combined to generate the configuration data of the ARM architecture.

[0170] In some embodiments, it further comprises:

[0171] (1.1) when a newly added architecture instruction is detected, receiving exclusive configuration data corresponding to the newly added computer architecture;

[0172] (1.2) Add the exclusive configuration data corresponding to the newly added computer architecture to the configuration file.

[0173] In the related art, when a new computer architecture is needed, a corresponding Dockerfile needs to be added for the new computer architecture under each service. The Dockerfile is generally created manually, and the process is very cumbersome. As the number of computer architecture types continues to increase, the process of Dockerfile generation, maintenance, and management will become more and more complicated.

[0174] Please continue reading Figure 8 As shown, in the configuration file 50, the general configuration data 51 is the configuration data common to each computer architecture, and the exclusive configuration data 52 is the configuration data dedicated to different computer architectures. Therefore, when a new computer architecture is added, only the exclusive configuration data corresponding to the new computer architecture needs to be added to realize the subsequent automatic generation of the Dockerfile under the new computer architecture. In this way, when a new computer architecture needs to be added, an architecture addition instruction can be generated. When an architecture addition instruction is detected, the exclusive configuration data corresponding to the new computer architecture can be received, and the exclusive configuration data corresponding to the new computer architecture can be added to the configuration file, so that the Dockerfile under the new computer architecture can be automatically generated according to the exclusive configuration data corresponding to the new computer architecture.

[0175] To better illustrate the embodiments of this application, please refer to Fig. 9 As shown, when it is necessary to add a Powerpc architecture, an architecture-added instruction can be generated. When the architecture-added instruction corresponding to the added Powerpc architecture is detected, the exclusive configuration data corresponding to the added Powerpc architecture can be received. The exclusive configuration data can be input by the developer according to the added Powerpc architecture, for example, the exclusive configuration data of the Powerpc architecture:

[0176] Configuration data under the base image (i.e. base_image): "powerpc / python3.8 as build".

[0177] Configuration data under the runtime base image (i.e. runtime_base_image): "powerpc / python3.8-slim".

[0178] In this way, the exclusive configuration data of the newly added Powerpc architecture is added to the exclusive configuration data 52 of the configuration file 50. Subsequently, the Dockerfile of the newly added Powerpc architecture can be quickly generated according to the exclusive configuration data of the newly added Powerpc architecture and the general configuration data without the need to manually create and maintain the Dockerfile, further improving the efficiency of file processing and saving labor costs.

[0179] In some implementations, after adding the dedicated configuration data corresponding to the newly added computer architecture to the configuration file, the process may return to step 201 so that a Dockerfile corresponding to the newly added computer architecture may be generated to implement subsequent deployment of the build file of the newly added computer architecture.

[0180] In some implementations, replacing the placeholders in the build file template with the configuration data corresponding to each computer architecture to obtain the replaced build file template for each computer architecture includes:

[0181] (2.1) Determine the data type of each placeholder in the build file template;

[0182] (2.2) The configuration data of each computer architecture is used to replace the corresponding placeholders in the build file according to the data type, so as to obtain the build file template of each computer architecture after replacement.

[0183] Please continue to read Figure 7As shown, the data type of each placeholder in the build file template 40 can be determined, and the data type can be a base image (i.e., base_image) type, a build command (i.e., build_command) type, a runtime base image (i.e., runtime_base_image) type, a working directory (i.e., app_home) type, an environment variable (i.e., env_var) type, a build output (i.e., build_output) type, a runtime command (i.e., runtime_command) type, an exposed port (i.e., app_port) type, and a startup command (i.e., cmd) type.

[0184] Furthermore, the configuration data of each computer architecture may be used to replace corresponding placeholders in the build file according to the above data types, so as to obtain a build file template of each computer architecture after replacement.

[0185] For example, the configuration data of the X86 architecture can be replaced with the corresponding placeholders in the build file according to the above data type. For example, the configuration data of the base image of the X86 architecture "python3.8 as build" can replace the corresponding {{base_image}} placeholder in the build file to obtain the replaced X86 architecture build file template, and the configuration data of the ARM architecture can be replaced with the corresponding placeholders in the build file according to the above data type. For example, the configuration data of the base image of the ARM architecture "arm32v7 / python3.8 as build" can replace the corresponding {{base_image}} placeholder in the build file to obtain the replaced ARM architecture build file template.

[0186] In some implementations, generating a build file corresponding to each computer architecture according to the replaced build file template of each computer architecture includes:

[0187] (3.1) Obtain the template content in the build file template of each computer architecture after replacement.

[0188] (3.2) Write the template content of each computer architecture into the newly created build file to obtain the corresponding build file for each computer architecture.

[0189] Among them, since the placeholders in the build file template of each computer architecture after replacement are replaced by the corresponding configuration data, the build file template of each computer architecture after replacement includes all the content describing the operation of the corresponding service. In this way, the template content in the build file template of each computer architecture after replacement can be directly obtained, and the template content is the Dockerfile content.

[0190] Furthermore, the template content of each computer architecture can be written into the newly created Dockerfile to obtain the corresponding build file (i.e., image file) for each computer architecture. For example, create a new Dockerfile for the X86 architecture, named "Dockerfile.X86", write the template content of the X86 architecture into Dockerfile.X86, and obtain the Dockerfile corresponding to the X86 architecture. Create a new Dockerfile for the ARM architecture, named "Dockerfile.ARM", write the template content of the ARM architecture into Dockerfile.ARM, and obtain the Dockerfile corresponding to the ARM architecture.

[0191] In some embodiments, it further comprises:

[0192] (4.1) When source code changes are detected, deployment instructions are generated.

[0193] (4.2) In response to the deployment instruction, the metadata acquisition is performed.

[0194] Among them, due to changes in the source code, some functions implemented by the source code will change. For example, adding a new function, deleting a function or modifying a function in the source code will cause the corresponding function to change. The configuration of the function dependency will change, that is, it will cause the configuration file to change, and then the Dockerfile will change. Therefore, when the source code change is detected, a deployment instruction will be generated, and in response to the deployment instruction, metadata will be obtained to implement an automated build process, and a new Dockerfile will be automatically generated for each computer architecture, thereby realizing multi-architecture deployment.

[0195] In some implementations, before executing the step of obtaining metadata in response to the deployment instruction, the step further includes:

[0196] (5.1) Receive corresponding configuration modification instructions when the source code changes.

[0197] (5.2) Modify the configuration data in the configuration file based on the configuration modification instruction.

[0198] (5.3) Modify the placeholders in the build file template based on the configuration modification instruction.

[0199] Among them, since the source code changes, the corresponding functions change, which will cause the configurations that the functions depend on to change, that is, the configuration data in the configuration file will change. In order to adapt the configuration data in the configuration file to the changes in the source code and the placeholders in the build file template to the changes in the source code, it is necessary to receive configuration modification instructions when the source code changes.

[0200] Since changes in the source code will cause three situations, namely, adding a function, deleting a function or modifying a function, it will cause the corresponding configuration data to be added, deleted or changed in the configuration file, and will also cause the addition, deletion and change of placeholders in the build file template. Therefore, the configuration data in the configuration file can be modified and the placeholders in the build file template can be modified according to the indication type indicated by the configuration modification instruction.

[0201] For example, when the configuration modification instruction indicates a new type, the configuration data in the configuration file is added with corresponding configuration data according to the configuration modification instruction, and the placeholder in the build file template is added with corresponding placeholders based on the configuration modification instruction. When the configuration modification instruction indicates a deletion type, the configuration data in the configuration file is deleted according to the configuration modification instruction, and the placeholder in the build file template is deleted based on the configuration modification instruction. When the configuration modification instruction indicates a change type, the configuration data in the configuration file is changed according to the configuration modification instruction, and the placeholder in the build file template is changed based on the configuration modification instruction.

[0202] Therefore, the configuration files and build file templates can be made to quickly adapt to changes in the source code without maintaining the Dockerfile under each computer architecture. The above embodiment can be quickly executed according to the changed source code, configuration data and build file template, and the Dockerfile under each changed computer architecture can be automatically generated, so that the Dockerfile can be automatically updated after the source code is updated, thereby better improving the efficiency of file processing.

[0203] In step 203, an image file corresponding to each computer architecture is constructed based on the construction file, and multi-architecture deployment is performed according to the image file.

[0204] Among them, the Dockerfile under each computer architecture is executed, the corresponding source code is called, and the image file under each computer architecture is generated. Then, the image file of each computer architecture can be deployed on computer devices using different computer architectures to achieve multi-architecture deployment.

[0205] In some implementations, building an image file corresponding to each computer architecture based on the build file, and performing multi-architecture deployment according to the image file, includes:

[0206] (1) Obtain the source code to be called.

[0207] (2) Execute the build file corresponding to each computer architecture to call the source code respectively and generate the image file corresponding to each computer architecture.

[0208] (3) Deploy each image file on a corresponding computer device according to the computer architecture type.

[0209] Among them, the source code to be called can be obtained in advance, the Dockerfile under the X86 architecture can be executed, the source code can be called, and the image file under the X86 architecture can be generated, the Dockerfile under the ARM architecture can be executed, the source code can be called, and the image file under the ARM architecture can be generated. Then, the image file under the X86 architecture can be deployed on a computer device using the X86 architecture type, and the image file under the ARM architecture can be deployed on a computer device using the ARM architecture type.

[0210] As can be seen from the above, the embodiment of the present application obtains metadata, and the metadata includes at least a configuration file and a build file template; wherein the configuration file includes configuration data corresponding to each computer architecture; the build file template is rendered according to the configuration data corresponding to each computer architecture, and the build file corresponding to each computer architecture is generated; the image file corresponding to each computer architecture is constructed based on the build file, and multi-architecture deployment is performed according to the image file. In this way, by pre-setting the configuration file and the build file template, and setting the configuration file to include the configuration data corresponding to each computer architecture, it is possible to quickly render the build file template according to the configuration data corresponding to each computer architecture, generate the build file corresponding to each computer architecture, and realize multi-architecture deployment. Compared with the solution in the related art that requires manual maintenance of the build file of each computer architecture, the embodiment of the present application does not need to manually process the build file of the computer architecture, thereby improving the efficiency of file processing and saving labor costs.

[0211] In combination with the method described in the above embodiment, the method will be further described in detail with examples below.

[0212] In this embodiment, the file processing device is specifically integrated into a server as an example for description.

[0213] Please also read Fig.12 , Fig.12 A flowchart of a file processing method provided in an embodiment of the present application. The method flow may include:

[0214] In step 501, when the server detects that the source code has changed, it generates a deployment instruction, receives the corresponding configuration modification instruction when the source code has changed, modifies the configuration data in the configuration file based on the configuration modification instruction, modifies the placeholder in the build file template based on the configuration modification instruction, and executes the acquisition of metadata in response to the deployment instruction.

[0215] Among them, due to the change of source code, some functions implemented by the source code will change. For example, if a function is added, deleted or modified in the source code, the corresponding function will change, which will cause the configuration of the function dependency to change, that is, it will cause the configuration file to change, and then the Dockerfile will change. Therefore, when the source code change is detected, a deployment instruction will be generated.

[0216] Among them, since the source code changes, the corresponding functions change, which will cause the configurations that the functions depend on to change, that is, the configuration data in the configuration file will change. In order to adapt the configuration data in the configuration file to the changes in the source code and the placeholders in the build file template to the changes in the source code, it is necessary to receive configuration modification instructions when the source code changes.

[0217] Since changes in the source code will cause three situations, namely, adding a function, deleting a function or modifying a function, it will cause the corresponding configuration data to be added, deleted or changed in the configuration file, and will also cause the addition, deletion and change of placeholders in the build file template. Therefore, the configuration data in the configuration file can be modified and the placeholders in the build file template can be modified according to the indication type indicated by the configuration modification instruction.

[0218] For example, when the configuration modification instruction indicates a new type, the configuration data in the configuration file is added with corresponding configuration data according to the configuration modification instruction, and the placeholder in the build file template is added with corresponding placeholders based on the configuration modification instruction. When the configuration modification instruction indicates a deletion type, the configuration data in the configuration file is deleted according to the configuration modification instruction, and the placeholder in the build file template is deleted based on the configuration modification instruction. When the configuration modification instruction indicates a change type, the configuration data in the configuration file is changed according to the configuration modification instruction, and the placeholder in the build file template is changed based on the configuration modification instruction.

[0219] Therefore, the configuration files and build file templates can be made to quickly adapt to changes in the source code without maintaining the Dockerfile under each computer architecture. The above embodiment can be quickly executed according to the changed source code, configuration data and build file template, and the Dockerfile under each changed computer architecture can be automatically generated, so that the Dockerfile can be automatically updated after the source code is updated, thereby improving the efficiency of file processing.

[0220] Furthermore, in response to the deployment instruction, metadata can be obtained to implement a subsequent automated build process and automatically generate a new Dockerfile for each computer architecture, thereby achieving multi-architecture deployment.

[0221] Please continue reading Figure 6 , the outer layer of the metadata directory structure 30 maintains a common generate.sh script for automatically generating Dockerfile. Create a separate directory for each service (for example: service-A and service-B, etc.) for easy organization and management. Inside the directory of each service, create two subdirectories, common and Dockerfile. The common directory is used to store configuration files shared by each service. The Dockerfile directory is used to store build file templates and corresponding configuration files, which will be used to generate Dockerfiles for multiple architectures. For example, service-A includes Dockerfile.yaml31 and Dockerfile.tmpl32, and service-B includes Dockerfile.yaml33 and Dockerfile.tmpl34.

[0222] In step 502, the server executes a preset script to obtain the common configuration data in the configuration file and the specific configuration data of each computer architecture, and combines the common configuration data and the specific architecture configuration data of each computer architecture to generate configuration data corresponding to each computer architecture.

[0223] Please continue reading Figure 8 As shown, the configuration file 50 includes common configuration data 51 and configuration data 52 specific to each computer architecture.

[0224] The general configuration data 51 includes the configuration data under the build command (i.e., build_command):

[0225] -"pip install --upgrade pip"

[0226] -"pip install -r requirements.txt".

[0227] Configuration data under the working directory (i.e. app_home): " / app".

[0228] Configuration data under environment variables (ie env_var):

[0229] FLASK_APP: "app.py"

[0230] FLASK_RUN_HOST: "0.0.0.0"

[0231] FLASK_RUN_PORT: "5000".

[0232] Configuration data under build output (i.e. build_output): ".".

[0233] Configuration data under runtime command (i.e. runtime_command): - "pip install gunicorn".

[0234] Configuration data under the exposed port (i.e. app_port): "5000".

[0235] Configuration data under the startup command (ie cmd): "gunicorn -w 4 -b 0.0.0.0:5000app:app".

[0236] The exclusive configuration data 52 includes the exclusive configuration data of the X86 architecture:

[0237] Configuration data under the base image (i.e. base_image): "python3.8 as build".

[0238] Configuration data under the runtime base image (i.e. runtime_base_image): "python3.8-slim".

[0239] ARM architecture-specific configuration data:

[0240] Configuration data under the base image (i.e. base_image): "arm32v7 / python3.8 as build".

[0241] Configuration data under the runtime base image (i.e. runtime_base_image): "arm32v7 / python3.8-slim".

[0242] The server executes the generate.sh script to obtain the common configuration data 51 in the configuration file 50 and the specific configuration data 52 of each computer architecture.

[0243] The general configuration data 61 and the exclusive configuration data of the X86 architecture are combined to generate the configuration data of the X86 architecture. The general configuration data 61 and the exclusive configuration data of the ARM architecture are combined to generate the configuration data of the ARM architecture.

[0244] In step 503, the server determines the data type of each placeholder in the build file template, and replaces the corresponding placeholders in the build file with the configuration data of each computer architecture according to the data type, to obtain the replaced build file template of each computer architecture.

[0245] Please continue reading Figure 7 As shown, the build file template 40 includes the following instructions and placeholders:

[0246] 1. Base image: Use the {{base_image}} placeholder to specify the base image for the build stage.

[0247] 2. Build command: Use the {{build_command}} placeholder between {% for build_command in Build_commands %} and {% endfor %} to represent the command used to execute the build phase.

[0248] 3. Runtime base image: Use the {{runtime_base_image}} placeholder to specify the base image of the runtime stage.

[0249] 4. Working directory: Use the {{app_home}} placeholder to set the working directory of the application.

[0250] 5. Environment variables: Use the {{env_var}} placeholder between {% for env_var, value in environment_variables.items()%} and {% endfor%} to set the environment variables of the application.

[0251] 6. Build output: Use the {{build_output}} placeholder to specify the file or directory copied from the build phase to the runtime phase.

[0252] 7. Runtime command: Use {{runtime_command}} between {% for runtime_command in runtime_commands %} and {% endfor %} to execute commands in the runtime phase.

[0253] 8. Exposed port: Use the {{app_port}} placeholder to specify the exposed port of the application.

[0254] 9. Startup command: Use the {{cmd}} placeholder to specify the startup command of the application.

[0255] That is, the above placeholders in the construction file template 40 all need to be filled with configuration data of corresponding data types in the configuration file to obtain the necessary content required to run the corresponding service.

[0256] Replace the corresponding {{base_image}} placeholder in the build file template with the configuration data of the base image under the X86 architecture, replace the corresponding {{build_command}} placeholder in the build file template with the configuration data of the build command under the X86 architecture, replace the corresponding {{runtime_base_image}} placeholder in the build file template with the configuration data of the runtime base image under the X86 architecture, replace the corresponding {{app_home}} placeholder in the build file template with the configuration data of the working directory under the X86 architecture, and replace the configuration data of the environment variables under the X86 architecture with the build file template. Replace the corresponding {{env_var}} placeholder in the build file template with the configuration data of the build output under the X86 architecture, replace the corresponding {{build_output}} placeholder in the build file template with the configuration data of the runtime command under the X86 architecture, replace the corresponding {{runtime_command}} placeholder in the build file template with the configuration data of the exposed port under the X86 architecture, and replace the corresponding {{app_port}} placeholder in the build file template with the configuration data of the startup command under the X86 architecture, and obtain the replaced X86 architecture build file template. And

[0257] Replace the corresponding {{base_image}} placeholder in the build file template with the configuration data of the base image under the ARM architecture, replace the corresponding {{build_command}} placeholder in the build file template with the configuration data of the build command under the ARM architecture, replace the corresponding {{runtime_base_image}} placeholder in the build file template with the configuration data of the runtime base image under the ARM architecture, replace the corresponding {{app_home}} placeholder in the build file template with the configuration data of the working directory under the ARM architecture, and replace the configuration data of the environment variables under the ARM architecture with the build file template. The corresponding {{env_var}} placeholder in the build file template is replaced with the configuration data of the build output under the ARM architecture, the corresponding {{build_output}} placeholder in the build file template is replaced with the configuration data of the runtime command under the ARM architecture, the corresponding {{runtime_command}} placeholder in the build file template is replaced with the configuration data of the exposed port under the ARM architecture, and the corresponding {{app_port}} placeholder in the build file template is replaced with the configuration data of the startup command under the ARM architecture, to obtain the replaced build file template for the ARM architecture.

[0258] In step 504, the server obtains the template content in the replaced build file template of each computer architecture, writes the template content of each computer architecture into the newly created build file, and obtains the build file corresponding to each computer architecture.

[0259] Among them, since the placeholders in the build file template of each computer architecture after replacement are replaced by configuration data of the corresponding data type, the build file template of each computer architecture after replacement includes all the content describing the running of the corresponding service. In this way, the template content in the build file template of each computer architecture after replacement can be directly obtained, and the template content is the Dockerfile content.

[0260] Furthermore, a new Dockerfile is created for the X86 architecture and named "Dockerfile.X86", and the template content of the X86 architecture is written into Dockerfile.X86 to obtain the Dockerfile corresponding to the X86 architecture. A new Dockerfile is created for the ARM architecture and named "Dockerfile.ARM", and the template content of the ARM architecture is written into Dockerfile.ARM to obtain the Dockerfile corresponding to the ARM architecture.

[0261] In step 505, the server obtains the source code to be called, executes the build file corresponding to each computer architecture to call the source code respectively, generates the image file corresponding to each computer architecture, and deploys each image file on the corresponding computer device according to the computer architecture type.

[0262] Among them, the source code to be called can be obtained in advance, the Dockerfile under the X86 architecture can be executed, the source code can be called, and the image file under the X86 architecture can be generated. The Dockerfile under the ARM architecture is executed, the source code can be called, and the image file under the ARM architecture can be generated. Then, the image file under the X86 architecture can be deployed on a computer device using the X86 architecture type, and the image file under the ARM architecture can be deployed on a computer device using the ARM architecture type.

[0263] In step 506, when the server detects the architecture addition instruction, it receives the exclusive configuration data corresponding to the newly added computer architecture, and adds the exclusive configuration data corresponding to the newly added computer architecture to the configuration file.

[0264] Please continue to read Fig. 9 As shown, when the server needs to add a Powerpc architecture, an architecture-added instruction can be generated. When the architecture-added instruction corresponding to the added Powerpc architecture is detected, the exclusive configuration data corresponding to the added Powerpc architecture can be received. The exclusive configuration data can be input by the developer according to the added Powerpc architecture. For example, the exclusive configuration data of the Powerpc architecture is as follows:

[0265] Configuration data under the base image (i.e. base_image): "powerpc / python3.8 as build".

[0266] Configuration data under the runtime base image (i.e. runtime_base_image): "powerpc / python3.8-slim".

[0267] In this way, the exclusive configuration data of the newly added Powerpc architecture is added to the exclusive configuration data 52 of the configuration file 50. Subsequently, the Dockerfile of the newly added Powerpc architecture can be quickly generated according to the exclusive configuration data of the newly added Powerpc architecture and the general configuration data, without the need to manually create and maintain the Dockerfile of the Powerpc architecture, further improving the efficiency of file processing and saving labor costs.

[0268] In one embodiment, after adding the exclusive configuration data corresponding to the newly added Powerpc architecture to the configuration file 50, the metadata acquisition can be re-executed to generate a Dockerfile corresponding to the newly added Powerpc architecture to implement the subsequent deployment of the build file of the newly added Powerpc architecture.

[0269] In this way, when adding a new computer architecture or updating an existing computer architecture, it can be quickly implemented in the dedicated configuration data 52 of the configuration file 50, making maintenance work easier. The scalability of the multi-architecture system is greatly improved, and the needs of the ever-changing computer framework can be quickly used.

[0270] Furthermore, the embodiments of the present application can realize customization of corresponding build file templates and configuration files for different services and computer frameworks, providing higher flexibility.

[0271] To better illustrate the embodiments of this application, please refer to Fig.13 Shown and Fig.14 As shown, Fig.13 A schematic diagram of the framework of the file processing method provided in the embodiment of the present application. Fig.14 Another flowchart of the file processing method provided in an embodiment of the present application.

[0272] Among them, the framework diagram of the file processing method consists of a cloud computing management and control system source code 61 (ie, source code), a Dockerfile generator 62, an X86 environment deployment 63, and an ARM environment deployment 64.

[0273] The source code 61 of the cloud computing management and control system has a unified source and can be managed in a unified manner using a version repository.

[0274] The common configuration refers to the configuration items that all architectures will use. By extracting these common configuration items and saving them in one file, all architectures can use them to avoid maintenance in multiple places.

[0275] The Dockerfile generator 62 is used to automatically generate corresponding Dockerfiles according to different architectures. That is, for different architectures, we no longer maintain complex and numerous Dockerfiles for cloud computing management services. We use the Dockerfile generator to automatically generate Dockerfiles for the corresponding architectures, which is easier to manage in the scenario where the architectures are constantly increasing.

[0276] The general pipeline is used to build according to the source code, general configuration and Dockerfile of each computer architecture to generate the corresponding product (i.e., image file).

[0277] The multi-architecture product manager is used to manage the image files of each computer architecture.

[0278] The X86 environment deployment 63 and the ARM environment deployment 64 are customer environment deployments. The multi-architecture product manager will push the image files of the corresponding computer architecture to the computer devices of the corresponding computer architecture types, so that the operation and maintenance personnel can get the image files for deployment.

[0279] like Fig.14 As shown, Fig.14 The detailed process for Dockerfile generator 62 is as follows:

[0280] Service-A triggers the pipeline. When the source code is changed, Service-A starts the build pipeline and begins the automated build process.

[0281] Calling the Dockerfile generator, the pipeline calls the pre-configured Dockerfile generator.

[0282] The Dockerfile generator obtains metadata, which includes the build file template, configuration file, and generate.sh script. These metadata will be used to generate Dockerfiles for different architectures.

[0283] The Dockerfile generator executes the generate.sh script, which automatically renders the build file template based on the provided configuration file. Through this process, the generator creates a corresponding Dockerfile for each target architecture (such as X86, ARM, etc.).

[0284] Generate material packages corresponding to computer architectures: Finally, the pipeline builds material packages corresponding to computer architectures based on the generated Dockerfile. These material packages can be used to deploy and run on devices of different architectures.

[0285] As can be seen from the above, the embodiment of the present application obtains metadata, and the metadata includes at least a configuration file and a build file template; wherein the configuration file includes configuration data corresponding to each computer architecture; the build file template is rendered according to the configuration data corresponding to each computer architecture, and the build file corresponding to each computer architecture is generated; the image file corresponding to each computer architecture is constructed based on the build file, and multi-architecture deployment is performed according to the image file. In this way, by pre-setting the configuration file and the build file template, and setting the configuration file to include the configuration data corresponding to each computer architecture, it is possible to quickly render the build file template according to the configuration data corresponding to each computer architecture, generate the build file corresponding to each computer architecture, and realize multi-architecture deployment. Compared with the solution in the related art that requires manual maintenance of the build file of each computer architecture, the embodiment of the present application does not need to manually process the build file of the computer architecture, thereby improving the efficiency of file processing and saving labor costs.

[0286] Furthermore, the embodiments of the present application can also quickly generate Dockerfiles for subsequent newly added architectures by receiving exclusive configuration data corresponding to the newly added computer architecture and adding the exclusive configuration data corresponding to the newly added computer architecture to the configuration file when a new architecture instruction is detected, thereby making file processing more flexible, more efficient, and reducing maintenance labor costs.

[0287] In order to better implement the file processing method provided in the embodiment of the present application, the embodiment of the present application also provides a device based on the above file processing method. The meanings of the terms are the same as those in the above file processing method, and the specific implementation details can refer to the description in the method embodiment.

[0288] See also Fig.15 , Fig.15 A structural schematic diagram of a file processing device provided in an embodiment of the present application, wherein the file processing device is applied to a sending device, wherein the file processing device may include an acquisition unit 601, a generation unit 602, and a deployment unit 603, etc.

[0289] The acquisition unit 601 is used to acquire metadata, which at least includes a configuration file and a construction file template.

[0290] The configuration file includes configuration data corresponding to each computer architecture.

[0291] The generating unit 602 is used to render the build file template according to the configuration data corresponding to each computer architecture, and generate a build file corresponding to each computer architecture.

[0292] In some implementations, the metadata further includes a preset script, and the generating unit 602 is configured to:

[0293] Execute the preset script, call the configuration data corresponding to each computer architecture to render the build file template respectively, and generate the build file corresponding to each computer architecture.

[0294] In some implementations, the build file template includes at least a placeholder, and the generating unit 602 includes:

[0295] An acquisition subunit (not identified) is used to execute the preset script to acquire configuration data corresponding to each computer architecture;

[0296] A replacement subunit (not identified), used to replace the placeholders in the build file template with the configuration data corresponding to each computer architecture, to obtain a replaced build file template for each computer architecture;

[0297] A generation subunit (not identified) is used to generate a build file corresponding to each computer architecture according to the replaced build file template of each computer architecture.

[0298] In some embodiments, the acquisition subunit (not identified) is used to:

[0299] Execute the preset script to obtain the common configuration data in the configuration file and the exclusive configuration data of each computer architecture;

[0300] The general configuration data and the architecture-specific configuration data of each computer architecture are respectively combined to generate configuration data corresponding to each computer architecture.

[0301] In some embodiments, the device further includes an architecture adding unit (not labeled) configured to:

[0302] When an architecture-new instruction is detected, receiving exclusive configuration data corresponding to the newly added computer architecture;

[0303] Add the dedicated configuration data corresponding to the newly added computer architecture to the configuration file.

[0304] In some embodiments, the device further includes a source code detection unit (not identified) configured to:

[0305] When source code changes are detected, deployment instructions are generated;

[0306] In response to the deployment instruction, an acquisition unit is executed.

[0307] In some embodiments, the device further includes a modification unit (not shown) configured to:

[0308] Receive corresponding configuration modification instructions when the source code changes;

[0309] Modify the configuration data in the configuration file based on the configuration modification instruction;

[0310] The placeholders in the build file template are modified based on the configuration modification instruction.

[0311] In some embodiments, the replacement subunit (not identified) is used to:

[0312] Determine the data type of each placeholder in the build file template;

[0313] The configuration data of each computer architecture is used to replace the corresponding placeholders in the build file according to the data type, so as to obtain the replaced build file template of each computer architecture.

[0314] In some embodiments, the generating subunit (not identified) is used to:

[0315] Get the template content in the replaced build file template for each computer architecture;

[0316] Write the template content of each computer architecture into the newly created build file to obtain the corresponding build file for each computer architecture.

[0317] The deployment unit 603 is used to build an image file corresponding to each computer architecture based on the build file, and perform multi-architecture deployment according to the image file.

[0318] In some embodiments, the deployment unit 603 is used to:

[0319] Get the source code to be called;

[0320] Execute the corresponding build file of each computer architecture and call the source code respectively to generate the corresponding image file of each computer architecture;

[0321] Deploy each image file on the corresponding computer device according to the computer architecture type.

[0322] The specific implementation of each of the above units can be found in the previous embodiments, which will not be described in detail here.

[0323] As can be seen from the above, the embodiment of the present application obtains metadata through the acquisition unit 601, and the metadata includes at least a configuration file and a build file template; wherein the configuration file includes the configuration data corresponding to each computer architecture; the generation unit 602 renders the build file template according to the configuration data corresponding to each computer architecture, and generates the build file corresponding to each computer architecture; the deployment unit 603 builds the image file corresponding to each computer architecture based on the build file, and performs multi-architecture deployment according to the image file. In this way, by pre-setting the configuration file and the build file template, and setting the configuration file to include the configuration data corresponding to each computer architecture, it is possible to quickly render the build file template according to the configuration data corresponding to each computer architecture, generate the build file corresponding to each computer architecture, and realize multi-architecture deployment. Compared with the solution in the related art that requires manual maintenance of the build file of each computer architecture, the embodiment of the present application does not need to manually process the build file of the computer architecture, thereby improving the efficiency of file processing and saving labor costs.

[0324] The present application also provides a computer device, such as Fig.16 As shown, it shows a schematic diagram of the structure of the server involved in the embodiment of the present application, specifically:

[0325] The computer device may include one or more processing core processors 701, one or more computer readable storage media memories 702, a power supply 703, an input unit 704 and other components. Those skilled in the art will appreciate that Fig.16 The computer device structure shown in the figure does not constitute a limitation on the computer device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. Among them:

[0326] The processor 701 is the control center of the computer device. It uses various interfaces and lines to connect various parts of the entire computer device. By running or executing software programs and / or modules stored in the memory 702 and calling data stored in the memory 702, it executes various functions of the computer device and processes data, thereby monitoring the computer device as a whole. Optionally, the processor 701 may include one or more processing cores; optionally, the processor 701 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 701.

[0327] The memory 702 can be used to store software programs and modules. The processor 701 executes various functional applications and data processing by running the software programs and modules stored in the memory 702. The memory 702 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the server, etc. In addition, the memory 702 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Accordingly, the memory 702 may also include a memory controller to provide the processor 701 with access to the memory 702.

[0328] The computer device also includes a power supply 703 for supplying power to various components. Optionally, the power supply 703 can be logically connected to the processor 701 through a power management system, so as to manage charging, discharging, and power consumption through the power management system. The power supply 703 can also include any components such as one or more DC or AC power supplies, recharging systems, power failure detection circuits, power converters or inverters, and power status indicators.

[0329] The computer device may further include an input unit 704, which may be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.

[0330] Although not shown, the computer device may also include a display unit, etc., which will not be described in detail here. Specifically in this embodiment, the processor 701 in the computer device will load the executable files corresponding to the processes of one or more application programs into the memory 702 according to the following instructions, and the processor 701 will run the application programs stored in the memory 702, thereby implementing the various method steps provided in the above embodiments, as follows:

[0331] Obtaining metadata, the metadata including at least a configuration file and a build file template;

[0332] Wherein, the configuration file includes configuration data corresponding to each computer architecture;

[0333] Rendering the build file template according to the configuration data corresponding to each computer architecture respectively, generating a build file corresponding to each computer architecture;

[0334] Build an image file corresponding to each computer architecture based on the build file, and perform multi-architecture deployment based on the image file.

[0335] In the above embodiments, the description of each embodiment has its own focus. For the part that is not described in detail in a certain embodiment, please refer to the detailed description of the queue processing method above, and will not be repeated here.

[0336] As can be seen from the above, the computer device of the embodiment of the present application can obtain metadata, and the metadata includes at least a configuration file and a build file template; wherein the configuration file includes configuration data corresponding to each computer architecture; render the build file template according to the configuration data corresponding to each computer architecture, and generate the build file corresponding to each computer architecture; build the image file corresponding to each computer architecture based on the build file, and perform multi-architecture deployment according to the image file. In this way, by pre-setting the configuration file and the build file template, and setting the configuration file to include the configuration data corresponding to each computer architecture, it is possible to quickly render the build file template according to the configuration data corresponding to each computer architecture, generate the build file corresponding to each computer architecture, and realize multi-architecture deployment. Compared with the solution in the related art that requires manual maintenance of the build file of each computer architecture, the embodiment of the present application does not need to manually process the build file of the computer architecture, thereby improving the efficiency of file processing and saving labor costs.

[0337] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0338] To this end, an embodiment of the present application provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions can be loaded by a processor to execute the steps in any file processing method provided in the embodiment of the present application. For example, the instructions can execute the following steps:

[0339] Obtaining metadata, the metadata including at least a configuration file and a build file template;

[0340] Wherein, the configuration file includes configuration data corresponding to each computer architecture;

[0341] Rendering the build file template according to the configuration data corresponding to each computer architecture respectively, generating a build file corresponding to each computer architecture;

[0342] Build an image file corresponding to each computer architecture based on the build file, and perform multi-architecture deployment based on the image file.

[0343] According to one aspect of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided in various optional implementations provided in the above embodiments.

[0344] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0345] The computer-readable storage medium may include: a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0346] Since the instructions stored in the computer-readable storage medium can execute the steps in any file processing method provided in the embodiments of the present application, the beneficial effects that can be achieved by any file processing method provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.

[0347] The above is a detailed introduction to a file processing method, device, and computer-readable storage medium provided in an embodiment of the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A file processing method, characterized in that: include: Obtaining metadata, the metadata including at least a configuration file and a build file template; Wherein, the configuration file includes configuration data corresponding to each computer architecture; Rendering the build file templates respectively according to the configuration data corresponding to each computer architecture to generate a build file corresponding to each computer architecture; An image file corresponding to each computer architecture is constructed based on the construction file, and multi-architecture deployment is performed according to the image file.

2. The file processing method according to claim 1, characterized in that: The metadata also includes a preset script, which renders the build file template according to the configuration data corresponding to each computer architecture to generate a build file corresponding to each computer architecture, including: The preset script is executed, and the configuration data corresponding to each computer architecture is called to render the build file template respectively, so as to generate the build file corresponding to each computer architecture.

3. The file processing method according to claim 2, characterized in that: The build file template includes at least a placeholder, and calling the configuration data corresponding to each computer architecture to render the build file template respectively to generate a build file corresponding to each computer architecture includes: Get the configuration data corresponding to each computer architecture; Replacing the placeholders in the build file template with the configuration data corresponding to each computer architecture, respectively, to obtain a replaced build file template for each computer architecture; Generate a corresponding build file for each computer architecture according to the replaced build file template for each computer architecture.

4. The file processing method according to claim 3, characterized in that: The obtaining of configuration data corresponding to each computer architecture includes: Obtaining common configuration data and specific configuration data for each computer architecture in the configuration file; The general configuration data and the architecture-specific configuration data of each computer architecture are respectively combined to generate configuration data corresponding to each computer architecture.

5. The file processing method according to claim 4, characterized in that: The method further comprises: When an architecture-new instruction is detected, receiving exclusive configuration data corresponding to the newly added computer architecture; Add the dedicated configuration data corresponding to the newly added computer architecture to the configuration file.

6. The file processing method according to claim 3, characterized in that: The method further comprises: When source code changes are detected, deployment instructions are generated; In response to the deployment instruction, the obtaining of metadata is performed.

7. The file processing method according to claim 6, characterized in that: Before executing the step of obtaining metadata in response to the deployment instruction, the step further includes: Receiving corresponding configuration modification instructions when the source code changes; Modify the configuration data in the configuration file based on the configuration modification instruction; The placeholders in the build file template are modified based on the configuration modification instruction.

8. The file processing method according to claim 3, characterized in that: The step of replacing the placeholders in the build file template with the configuration data corresponding to each computer architecture to obtain the replaced build file template for each computer architecture includes: Determining the data type of each placeholder in the build file template; The configuration data of each computer architecture replaces the corresponding placeholders in the build file according to the data type, so as to obtain a replaced build file template for each computer architecture.

9. The file processing method according to claim 3, characterized in that: The step of generating a build file corresponding to each computer architecture according to the replaced build file template of each computer architecture includes: Get the template content in the replaced build file template for each computer architecture; Write the template content of each computer architecture into the newly created build file to obtain the corresponding build file for each computer architecture.

10. The file processing method according to any one of claims 1 to 9, characterized in that: The step of building an image file corresponding to each computer architecture based on the build file and performing multi-architecture deployment according to the image file includes: Get the source code to be called; Execute the build file corresponding to each computer architecture and call the source code respectively to generate the image file corresponding to each computer architecture; Deploy each of the image files on a corresponding computer device according to the computer architecture type.

11. A file processing device, characterized in that: include: An acquisition unit, used for acquiring metadata, wherein the metadata at least includes a configuration file and a construction file template; Wherein, the configuration file includes configuration data corresponding to each computer architecture; A generating unit, configured to render the build file templates according to the configuration data corresponding to each computer architecture, and generate a build file corresponding to each computer architecture; A deployment unit is used to build an image file corresponding to each computer architecture based on the build file, and perform multi-architecture deployment according to the image file.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor to execute the steps in the file processing method according to any one of claims 1 to 10.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the file processing method according to any one of claims 1 to 10 are implemented.

14. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the steps in the file processing method according to any one of claims 1 to 10 are implemented.

Images