Micro-service-based image generation method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a micro-service-based image generation method and device, electronic equipment and storage medium, relates to the technical field of artificial intelligence, in particular to the field of cloud application engine of cloud computing. The specific implementation scheme is: in response to a generation instruction, a program package of the micro-service indicated by the generation instruction is obtained; wherein the generation instruction is used to instruct to generate the image of the micro-service; the program package includes at least one program file, and the program file is used to represent the data required for running the micro-service; the service type of the micro-service is determined according to the program file in the program package of the micro-service; wherein the service type is used to represent the running environment of the micro-service; according to the preset image layering rule corresponding to the service type of the micro-service, the image of the micro-service is generated, and the image of the micro-service is pushed to the preset image warehouse for storage. By automatically generating the image, the image construction time is reduced, and the efficiency and accuracy of image generation are improved.

Description

Technical Field

[0001] This disclosure relates to the fields of cloud computing and cloud application engines in the field of artificial intelligence, and in particular to a microservice-based image generation method, apparatus, electronic device and storage medium. Background Technology

[0002] In the cloud-native era, microservice deployment has shifted from traditional service compilation and package deployment to image deployment. An image is a special file system containing the programs, libraries, resources, and configuration files required for container runtime. Creating the necessary deployment image requires writing image file code. This code writing demands a high level of expertise from the user, wasting significant manpower and time, and impacting the accuracy and efficiency of image generation. Summary of the Invention

[0003] This disclosure provides a microservice-based image generation method, apparatus, electronic device, and storage medium.

[0004] According to a first aspect of this disclosure, a microservice-based image generation method is provided, comprising:

[0005] In response to a generation instruction, a package of the microservice indicated by the generation instruction is obtained; wherein the generation instruction is used to instruct the generation of a microservice image; the package includes at least one program file, the program file being used to represent the data required to run the microservice;

[0006] The service type of the microservice is determined based on the program files in the microservice's program package; wherein, the service type is used to represent the microservice's operating environment;

[0007] Based on the preset image layering rules corresponding to the service type of the microservice, an image of the microservice is generated and pushed to a preset image repository for storage.

[0008] According to a second aspect of this disclosure, a microservice-based image generation apparatus is provided, comprising:

[0009] An acquisition unit is configured to acquire a package of a microservice indicated by a generation instruction in response to the generation instruction; wherein the generation instruction is used to instruct the generation of a microservice image; the package includes at least one program file, the program file being used to represent the data required to run the microservice;

[0010] The type determination unit is used to determine the service type of the microservice based on the program files in the microservice's program package; wherein the service type is used to represent the microservice's operating environment;

[0011] The generation unit is used to generate an image of the microservice according to a preset image layering rule corresponding to the service type of the microservice, and push the image of the microservice to a preset image repository for storage.

[0012] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0013] At least one processor; and

[0014] A memory communicatively connected to the at least one processor; wherein,

[0015] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect of this disclosure.

[0016] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing the computer to perform the method described in the first aspect of this disclosure.

[0017] According to a fifth aspect of this disclosure, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the method described in the first aspect of this disclosure.

[0018] The technology disclosed herein improves the efficiency and accuracy of microservice image generation.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0020] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0021] Figure 1 This is a flowchart illustrating a microservice-based image generation method according to an embodiment of this disclosure;

[0022] Figure 2 This is a flowchart illustrating a microservice-based image generation method according to an embodiment of this disclosure;

[0023] Figure 3 This is a flowchart illustrating a microservice-based image generation method according to an embodiment of this disclosure;

[0024] Figure 4 This is a schematic diagram of a mirror layer structure provided according to an embodiment of this disclosure;

[0025] Figure 5 This is a structural block diagram of a microservice-based image generation device provided according to an embodiment of the present disclosure;

[0026] Figure 6 This is a structural block diagram of a microservice-based image generation device provided according to an embodiment of the present disclosure;

[0027] Figure 7 This is a structural block diagram of an electronic device used to implement the microservice-based image generation method of the embodiments of this disclosure;

[0028] Figure 8 This is a structural block diagram of an electronic device used to implement the microservice-based image generation method of the embodiments of this disclosure. Detailed Implementation

[0029] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0030] In the cloud-native era, the deployment method for microservices has changed from the traditional deployment of compiled service packages to deployment using Docker (Application Container Engine) images. A Docker image is a special file system that includes the programs, libraries, resources, and configuration files required for container runtime, as well as some configuration parameters prepared for runtime, such as anonymous volumes, environment variables, and user identifiers.

[0031] Microservices must rely on Docker images to be deployed to the cloud. However, creating the Docker images required for deployment requires writing certain code based on professional knowledge, which requires a high level of expertise. Furthermore, the code format is not consistent among different microservice developers when creating images.

[0032] Cloud-native vendors typically build images based on Docker. When generating an image, a Dockerfile is added to the project. Users write Docker definitions describing the image generation process. The Dockerfile's definitions are read locally or on a server, and then interpreted and executed by the Docker server to build the image. However, if problems arise during use, troubleshooting requires significant time and effort, wasting considerable manpower and time.

[0033] This disclosure provides a microservice-based image generation method, apparatus, electronic device, and storage medium, applicable to the cloud computing field within the field of artificial intelligence, and particularly relating to the cloud application engine field of cloud computing, to improve the efficiency and accuracy of image generation.

[0034] It should be noted that the data in this embodiment is not specific to any particular user and does not reflect the personal information of any particular user. Furthermore, the data in this embodiment comes from a publicly available dataset.

[0035] The collection, storage, use, processing, transmission, provision, and disclosure of information or data involved in this technical solution comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0036] To help readers gain a deeper understanding of the implementation principles of this disclosure, the following will be discussed in conjunction with... Figures 1-8 The illustrated embodiments are further refined.

[0037] Figure 1 This is a flowchart illustrating a microservice-based image generation method according to an embodiment of this disclosure. This method can be executed by a microservice-based image generation device. Figure 1 As shown, the method includes the following steps:

[0038] S101. In response to the generation instruction, obtain the package of the microservice indicated by the generation instruction; wherein the generation instruction is used to instruct the generation of the microservice image; the package includes at least one program file, which is used to represent the data required to run the microservice.

[0039] For example, a microservice platform can obtain the application package of a microservice to be deployed, generate a microservice image, and store the microservice image in the platform's image repository. The microservice platform can be a cloud application platform, and a Java Server can be written within it to generate the image. The image generation process can utilize a Java thread pool. Developers of different microservices can upload the application packages of their developed microservices to the microservice platform for image generation.

[0040] Microservice developers can issue microservice image build commands to the microservice platform, instructing the platform to build the microservice image. Upon receiving the build command, the platform retrieves the corresponding microservice package. This can be done by retrieving the microservice package directly from the build command itself, for example, by sending the package along with the command to the platform. Alternatively, the package can be pre-stored in a preset location, and the platform retrieves it from that location upon receiving the command. Another option is to pre-store the package on the platform, and upon receiving the build command, use the unique identifier of the microservice in the command to find the package corresponding to that identifier and use it as the package for the microservice specified in the command.

[0041] The platform can periodically retrieve microservice packages. For example, the frequency of generation command issuance can be preset, and packages for each microservice can be obtained by periodically responding to these commands. For instance, each time a generation command is received, the platform checks a preset storage location for packages to determine if a package for an undeployed microservice exists. If not, the package is not retrieved; otherwise, it is retrieved. Alternatively, generation commands can be periodically issued for a specific microservice, thus periodically retrieving the package for that microservice. The platform can also automatically initiate package retrieval itself periodically without receiving external generation commands.

[0042] The application package can be pre-written by the microservice developers. The data in the application package can include libraries, resources, and configuration parameters required by the microservice at runtime. The application package can include one or more program files, that is, program files can be used to represent the libraries, resources, and configuration parameters required by the microservice at runtime. In this embodiment, a compressed application package can be obtained.

[0043] S102. Determine the service type of the microservice based on the program files in the microservice package; whereby the service type is used to represent the operating environment of the microservice.

[0044] For example, one or more program files can be obtained from the microservice's package. These program files may include data related to the microservice, such as the microservice's identifier, configuration parameters, runtime environment, and required libraries.

[0045] Different microservices can have different predefined service types, which can also exist in the application file. For example, each service type can have a unique type identifier, which developers can write into the application file. Different service types can correspond to different runtime environments; that is, the service type can be used to represent the runtime environment of the microservice. The application file can include the runtime environment required by the microservice, and the service type of the microservice is determined based on the runtime environment indicated in the application file.

[0046] In this embodiment, the service type can include Spring Boot, Node.js, front-end static web pages, and other types. Other types can include those with program files written in languages ​​such as C++ and Golang. Spring Boot is an open-source application framework, Node.js represents the JavaScript runtime environment, and C++ and Golang are open-source programming languages. The service type of the microservice is determined based on its program files. For example, the service type corresponding to the microservice is determined based on the language in which the program files are written.

[0047] In this embodiment, the method further includes: decompressing the microservice package to a preset storage location on the disk to obtain the program files in the microservice package.

[0048] Specifically, before determining the service type based on the program files, the program files need to be obtained from the program package. The program package can be in compressed format; when obtaining the program files, the package can be decompressed to obtain the program files within it.

[0049] You can pre-define a specific directory to which the program package is extracted. For example, you can pre-set a storage location on the disk, extract the program package to the preset storage location on the disk, and store the program files on the disk so that you can easily retrieve the program files directly from the preset storage location on the disk later.

[0050] The advantage of this setup is that it allows for the decompression of the program package, making it easier to obtain the program files in the required format. By storing the program files in the designated location, it enables effective data management, avoids data loss, and improves the efficiency and accuracy of image generation.

[0051] S103. Generate images of microservices according to the preset image layering rules corresponding to the service types of microservices, and push the images of microservices to the preset image repository for storage.

[0052] For example, different service types correspond to different image tiering rules. After determining the service type of a microservice, the image tiering rule corresponding to that service type is determined. Based on the corresponding image tiering rule, the microservice image is constructed. An image repository is pre-set in the platform to store images. After obtaining the microservice image, it can be stored in the image repository. The image can be associated with the microservice's identifier for easy retrieval of the microservice image from the repository later.

[0053] Image layering rules can be used to represent the rules for building microservice images based on application files. An image can include one or more image layers. Image layering clarifies the meaning and behavior of each layer, and the data in each layer can be different. Therefore, image layering rules can also be used to represent the rules for generating the data for each image layer of a microservice based on application files.

[0054] Based on the image layering rules, data for each image layer in a microservice image can be generated. Combining the data from each image layer yields the microservice image. For example, if an image has three image layers, the data from the first layer is placed at the bottom, the second layer in the middle, and the third layer at the top, resulting in a complete image. In this embodiment, Java code can be used to generate the final image.

[0055] In this embodiment, the method includes: in response to a microservice deployment instruction, determining the microservice to be deployed; obtaining the image of the microservice to be deployed from an image repository, and deploying the image of the microservice to be deployed to a preset server.

[0056] Specifically, microservices can be deployed on pre-defined servers. When deploying a microservice, its corresponding image needs to be deployed to the server. Users can issue microservice deployment commands, instructing the platform to deploy the microservice image to the server.

[0057] The microservice deployment command can include a microservice identifier. Upon receiving the deployment command, the identifier is determined, thus identifying the microservice to be deployed. An image repository can store images corresponding to multiple microservices. Based on the identified identifier, the image corresponding to the microservice to be deployed is retrieved from the image repository. The image of the microservice to be deployed is then deployed to the server, completing the deployment of the microservice.

[0058] The advantage of this setup is that after generating a microservice image, it can be retrieved from the image repository at any time for microservice deployment, which facilitates the management of microservice images and improves the deployment efficiency and accuracy of microservices.

[0059] When deploying microservices, the image building process and image file generation are unified through the Java Server process, which is more stable and reliable than building with Docker files.

[0060] In this embodiment, there are at least two images of the microservice to be deployed; obtaining the image of the microservice to be deployed from the image repository and deploying the image of the microservice to be deployed to a preset server includes: in response to the user's selection operation of the image of the microservice to be deployed, determining the target image of the microservice to be deployed from at least two images; obtaining the target image of the microservice to be deployed from the image repository and deploying the target image to the preset server.

[0061] Specifically, in the image repository, a microservice can correspond to multiple images; for example, a microservice may correspond to different versions of the image. After determining the microservice to be deployed, the image repository searches for all images corresponding to the microservice to be deployed. Users can select from these images; for example, users can see the image names of multiple images on a visual interface, and the image names can be used to indicate the image version.

[0062] Users can select an image for the microservice to be deployed through a visual interface. In response to the user's selection, the image chosen by the user from multiple images is determined as the target image. That is, the image required to deploy the microservice is determined. The data of the target image is retrieved from the image repository, and the target image is deployed to the server, completing the deployment of the microservice.

[0063] The advantage of this setup is that users can choose the image to deploy based on their actual needs, avoiding image deployment errors and improving the flexibility and accuracy of microservice deployment.

[0064] This disclosure allows for the acquisition of microservice packages and the determination of microservice service types based on the program files within the packages. Different service types correspond to different image layering rules. Microservice images are generated according to these rules and stored in an image repository. This eliminates the need for users to focus on the code writing process for image building. For different service types, images are automatically generated according to preset rules, reducing image building time, effectively minimizing the need for specialized user expertise, and saving manpower. By establishing image layering rules, unified image management is achieved, significantly reducing the likelihood of anomalies in Docker files written by different developers, and improving the accuracy and efficiency of image generation.

[0065] Figure 2 This is a flowchart illustrating a microservice-based image generation method provided in this embodiment of the present disclosure. This embodiment is an optional embodiment based on the above embodiments.

[0066] In this embodiment, in response to the generation command, the microservice package indicated by the generation command is obtained, which can be further refined as follows: in response to the generation command issued periodically, the microservice to be generated as an image is determined, and the microservice package retrieval method is determined from the preset task database; wherein, the package retrieval method is used to indicate the source of the package when retrieval; and the microservice package is obtained according to the microservice package retrieval method.

[0067] like Figure 2 As shown, the method includes the following steps:

[0068] S201. In response to the timed generation command, determine the microservice to be generated as an image, and determine the package retrieval method of the microservice from the preset task database; wherein, the package retrieval method is used to indicate the source of the package when retrieval.

[0069] For example, the generation command can be issued and responded to by the microservice platform itself; that is, the microservice platform can automatically obtain the application package. The generation command issuance cycle can be preset; for example, the microservice platform can issue one generation command to itself every hour, meaning the microservice platform can respond to one generation command every hour. Alternatively, the application package obtaining cycle can be set for the microservice platform, automatically obtaining the application package according to the cycle; for example, the application package can be obtained once per hour.

[0070] The generation command can include the identifier of the microservice to be generated. Upon receiving the scheduled generation command, the identifier of the microservice to be generated can be obtained from the command, and the microservice to be generated can be determined based on the obtained identifier. The microservice platform uses a pre-defined task database, which stores the package retrieval methods for microservices. The package retrieval method refers to the source of the package when it is retrieved. For example, the source of the package can be an HTTP (Hypertext Transfer Protocol) address or a database. That is, the task database does not directly store the package, but rather stores the package retrieval method, and the package is obtained based on the retrieval method. The task database can store the association between microservices and their corresponding package retrieval methods; for example, the identifier of a microservice can be associated with its package retrieval method. After determining the identifier of the microservice to be generated, the corresponding package retrieval method is found in the task database. If a package retrieval period is set, the platform can automatically retrieve image generation tasks from the task database every retrieval period, that is, retrieve the package retrieval method corresponding to the microservice that has not yet generated an image.

[0071] In this embodiment, the method further includes: pre-storing the package retrieval method corresponding to the microservice in a preset task database; wherein, the package retrieval method includes retrieving the package from a preset package retrieval address or retrieving the package from a preset package database; the package retrieval address is used to represent the address of the package entered by the user through a web page; the package database is used to represent the database storing the package.

[0072] Specifically, the method for pulling the microservice package can be stored in the task database when an image needs to be generated. Alternatively, after the microservice package is developed, but before generating the image, the method for pulling the microservice package can be stored in the task database in advance. For example, the microservice developer can log in to the microservice platform and store the package pulling method in the platform's task database, waiting for the microservice platform to retrieve the pulling method from the task database and then obtain the package.

[0073] The package retrieval method indicates the source of the package. The source can be a specific address or a database. That is, the package can be retrieved from a preset retrieval address or from a preset package database. The retrieval address is the location of the package, which can be used to represent the address of the package entered by the microservice developer through a web interface. The package database indicates the database where the package is stored. After completing the package, the microservice developer can place it in the package database.

[0074] The advantage of this setup is that by pre-storing the package retrieval method, the package can be retrieved from the task database at any time, enabling automatic image generation and improving the efficiency of image generation.

[0075] In this embodiment, the package retrieval method is to retrieve the package from a preset package retrieval address; according to the package retrieval method of the microservice, obtaining the microservice package includes: obtaining the Hypertext Transfer Protocol address entered by the user through a web page, and obtaining the microservice package from the Hypertext Transfer Protocol address; or, obtaining the package retrieval command entered by the user through a web page, determining the microservice package retrieval address from the package retrieval command, and obtaining the microservice package from the microservice package retrieval address; wherein, the package retrieval command is used to retrieve the package.

[0076] Specifically, if the package retrieval method involves obtaining the package from a package database, it indicates that the user has pre-stored the package in the package database, and the user is the microservice developer. For example, microservice developers can use CI (Continuous Integration) and CD (Continuous Delivery) processes to send packages to their internal repository, which serves as the package database. The microservice platform can then retrieve packages from this package repository.

[0077] If the package retrieval method is to retrieve the package from a preset retrieval address, it indicates that the user has pre-stored the package in the retrieval address. The retrieval address can be an HTTP address, which the user can pre-enter via a web interface to specify the package's source and store in the task database. When retrieving the package, the task database retrieves the HTTP address entered by the user via the web interface, and the microservice package is obtained from that HTTP address.

[0078] Users can also store package retrieval commands in the task database, which contain the address of the program package. That is, the program package can be retrieved by using the retrieval address in the command. The retrieval command can be the Wget command, a command-line tool for downloading files. Users can enter the Wget command through a web interface, specifying the source of the program package using the retrieval address. When retrieving the program package, the system can retrieve the Wget command entered by the user from the web interface and obtain the package from the location specified in the command.

[0079] The advantage of this setup is that users can specify the method of pulling the program package in multiple ways, which facilitates user operation and allows the platform to obtain the program package through different channels, improving the flexibility of program package pulling and thus improving the efficiency of image generation.

[0080] S202. Obtain the microservice package according to the microservice package retrieval method.

[0081] For example, after obtaining the package retrieval method, the microservice package is obtained according to the package retrieval method. For instance, if the package retrieval method is to obtain the package from the package database, the microservice platform can search for the package corresponding to the microservice from the package database.

[0082] If the package retrieval method involves obtaining the package from a preset retrieval address, then the package stored at that address is retrieved as the microservice's package. Alternatively, the retrieval address can be obtained first from the retrieval command, and then the microservice's package can be retrieved from that address. In this embodiment, the microservice's corresponding package is retrieved within the Java Server process via retrieval commands, retrieval addresses, or a package database. This achieves automatic package retrieval, improving image generation efficiency.

[0083] S203. Determine the service type of the microservice based on the program files in the microservice package; whereby the service type is used to represent the operating environment of the microservice.

[0084] For example, this step can refer to step S102 above, and will not be repeated here.

[0085] S204. Generate images of microservices according to the preset image layering rules corresponding to the service types of microservices, and push the images of microservices to the preset image repository for storage.

[0086] For example, this step can refer to step S103 above, and will not be repeated here.

[0087] This disclosure allows for the acquisition of microservice packages and the determination of microservice service types based on the program files within the packages. Different service types correspond to different image layering rules. Microservice images are generated according to these rules and stored in an image repository. This eliminates the need for users to focus on the code writing process for image building. For different service types, images are automatically generated according to preset rules, reducing image building time and effectively lowering the professional requirements for users. Users do not need to concern themselves with the technologies used in the images or the building process, saving manpower. By establishing image layering rules, unified management of images is achieved, significantly reducing the possibility of anomalies in Docker files written by different developers and improving the accuracy and efficiency of image generation.

[0088] Figure 3 This is a flowchart illustrating a microservice-based image generation method provided in this embodiment of the present disclosure. This embodiment is an optional embodiment based on the above embodiments.

[0089] In this embodiment, the microservice image is generated according to the preset image layering rules corresponding to the service type of the microservice. This can be further refined as follows: determine the image layering rules corresponding to the service type of the microservice based on the preset association between the service type and the image layering rules; generate the microservice image layer data according to the image layering rules corresponding to the service type of the microservice; and obtain the microservice image based on the microservice image layer data.

[0090] like Figure 3 As shown, the method includes the following steps:

[0091] S301. In response to the generation instruction, obtain the package of the microservice indicated by the generation instruction; wherein the generation instruction is used to instruct the generation of the microservice image; the package includes at least one program file, which is used to represent the data required to run the microservice.

[0092] For example, this step can refer to step S101 above, and will not be repeated here.

[0093] S302. Determine the service type of the microservice based on the program files in the microservice package; whereby the service type is used to represent the operating environment of the microservice.

[0094] For example, this step can refer to step S102 above, and will not be repeated here.

[0095] S303. Based on the preset association between service types and image layering rules, determine the image layering rules corresponding to the service types of microservices.

[0096] For example, the association between service types and image layering rules is pre-defined, with different image layering rules corresponding to different service types. Image layering rules are rules generated to divide images into layers. An image can include multiple image layers. Therefore, when generating an image, each image layer can be generated according to the image layering rules.

[0097] After determining the service type of a microservice, the system finds the corresponding image layering rule based on the relationship between the service type and the image layering rule. This facilitates image building based on the found rule. The platform's image generation service unifies the image building process for Spring Boot, Node.js, front-end static web pages, and Golang images, achieving a standardized build workflow. Users don't need to focus on the image building process, reducing manpower and time, improving image building efficiency and accuracy, and enabling the deployment of microservices in different environments.

[0098] S304. Generate microservice image layer data according to the image layering rules corresponding to the service type of the microservice.

[0099] For example, an image may include multiple image layers, and the data in each image layer may differ. Image layering rules can be used to generate the image layer data for each layer; that is, image layer data for each layer of a microservice can be generated based on the image layering rules corresponding to the service type of the microservice. For example, if a microservice image has three layers, the image layering rules may include methods for generating image layer data for the first, second, and third layers. Based on the image layer data generation methods for each layer, the image layer data for each layer can be obtained.

[0100] The first layer of the image is the basic environment required for microservices to run, such as CentOS 7 (Community Enterprise Operating System) or CentOS 8. The second layer includes the necessary software packages for the runtime environment; for example, Spring Boot requires OpenJDK (Open Java Development Kit), and may also include start / stop scripts, such as start functions, stop functions, and liveness check functions. The third layer consists of software packages that the user can freely choose for the microservices; these are generally larger packages, allowing for selective configuration based on needs. Unnecessary packages can reduce the final image size. The fourth layer and above consist of compiled files generated from the code in the microservice's application files.

[0101] In this embodiment, generating microservice image layer data according to the image layering rules corresponding to the service type of the microservice includes: determining the number of microservice image layers and the image layer data generation method corresponding to each image layer according to the image layering rules corresponding to the service type of the microservice; and generating image layer data for each image layer of the microservice according to the image layer data generation method corresponding to each image layer.

[0102] Specifically, the number of image layers for microservices of different service types can vary. The number of image layers for a microservice is determined according to the image layering rules corresponding to its service type. In this embodiment, the number of image layers for each service type is greater than or equal to four. For example, for Spring Boot, the number of image layers can be seven; for Node.js, it can be five; for front-end static web pages, it can be four; and for other types such as Golang and C++, it can also be four. The image data for each layer is different, and the image layering rules can include the generation method for each image layer's data. That is, the image layering rules can be used to determine the image data generation method for each image layer.

[0103] Based on the image layer data generation method corresponding to each image layer, image layer data for each layer is automatically generated. For Spring Boot type microservices, the essence is to run a fat-jar (uber-jar, containing all dependent jar packages). A typical fat-jar is over 100MB in size. If the entire fat-jar is built, the entire jar package will be pulled every time a deployment is made, resulting in time consumption. In this embodiment, during image building, the image layer data generation method for the first three layers is to generate data on the basic environment required for microservice operation, data on the software packages required for the runtime environment, and data on software packages freely selected by the user for the microservice, respectively, according to pre-defined rules. The image layer data generation method for the fourth layer is to obtain the third-party jar packages dependent on the microservice from the program file and compile them into the image layer data for the fourth layer according to preset compilation rules. The version changes of the image layer data for the fourth layer are relatively small. The image layer data for the fifth layer consists of some fixed configuration files related to the microservice, with relatively small version changes. The image layer data generation method can be to obtain and compile them from the program file. The sixth layer is also based on the snapshot jar packages of the service dependencies obtained from the program file. The seventh layer compiles code based on program files according to preset rules. The version of the mirror layer data in the seventh layer is frequently changed and placed in the top layer.

[0104] For Node.js image layers, the generation method is as follows: the first layer generates the basic environment data required for service operation; the second layer contains the Node environment and Node.js service start / stop scripts; the third layer is still optional software packages; the fourth layer contains larger files containing third-party dependency packages; and the fifth layer contains smaller files containing the compiled generated files. For front-end static webpage images, the second layer primarily generates multiple versions of the Nginx (engine x, server) runtime environment and Nginx service start / stop files. For other types such as Golang and C++, which do not depend on other environment packages besides the CentOS runtime environment, the second layer only contains start / stop scripts.

[0105] Startup and shutdown scripts mainly include service start commands, stop commands, and liveness check commands. For example, the entry function scripts for package startup, stop, and liveness check can correspond to the `start`, `stop`, and `check` functions, respectively. The `start` and `stop` functions call functions in `run.sh`, and the `check` function calls functions in `check.sh`. `run.sh` represents the function scripts for starting and stopping the package, while `check.sh` represents the package liveness check script, including the liveness check implementation logic. Startup and shutdown scripts can also include custom environment variable scripts to implement some special user customization requirements, such as custom health checks.

[0106] The benefits of this setup are that it allows for the generation of data for each layer of the image, avoiding data corruption, improving the accuracy and efficiency of image generation, and ensuring the normal operation of microservices. It also provides unified management of start / stop scripts and liveness detection commands, freeing users from the complex configurations required for cloud-native deployments. This unified platform management significantly reduces the occurrence of anomalies.

[0107] In this embodiment, the image layer is a package configuration layer; the package configuration layer includes the package selected and configured by the user; according to the image layer data generation method corresponding to each image layer, the image layer data of each image layer of the microservice is generated, including: responding to the user's custom operation of the package, determining that the package selected by the user is a custom package; obtaining the custom package, and configuring the custom package as image layer data in the package configuration layer.

[0108] Specifically, the package configuration layer can be the third layer in the image. Users can freely choose packages before generating the image to meet actual business needs. Selectable packages are pre-stored on the platform. Users select packages before generating the image; this selection is the user's customization operation. In response to the user's customization operation, the selected package is determined as the custom package. When image generation begins, the user-selected custom package is retrieved. Based on the image layer data generation method of the package configuration layer, the custom package is compiled into image layer data and configured into the package configuration layer.

[0109] The optional software packages are designed to provide users with configuration data for selecting from a range of practically needed, less common, and larger software packages.

[0110] The benefits of this setup are that it enables image generation to meet actual needs, improves the flexibility of image generation, simplifies user operation, saves manpower and time, and improves the accuracy and efficiency of image generation.

[0111] S305. Based on the microservice image layer data, obtain the microservice image and push the microservice image to the preset image repository for storage.

[0112] For example, the image data of each layer is concatenated to obtain a complete microservice image. An image repository is pre-set in the platform to store the microservice images for easy deployment. Different microservices can have different image layer concatenation logic. For example, the association between images and image layers can be pre-defined, and the image layer data of the associated image layers can be combined. The image layer data of each layer can be concatenated according to the order of the image layers to obtain the final image. In this embodiment, the image can be generated using Java. Alternatively, the image layer data can be stored in an image repository. When a microservice image needs to be deployed, the image layer associated with the microservice image is retrieved from the image repository, and the image data of the associated image layer is concatenated according to the layer number to obtain the microservice image for deployment.

[0113] In this embodiment, obtaining the image of a microservice based on the microservice image layer data includes: determining the order of the microservice image layers according to the image layering rules corresponding to the service type of the microservice; and constructing the microservice image from the microservice image layer data according to the order of the microservice image layers.

[0114] Specifically, the image layering rules can include the order of each image layer. The order refers to the vertical arrangement of the image layers when assembling the image. For example, the first layer is at the bottom, and the higher the layer number, the higher it is in the order. From the image layering rules, the order of each image layer of the microservice is determined. Based on the order of the image layers, the image layer data is assembled to build the microservice image.

[0115] For example, in Spring Boot applications, the last layer is the code compiled from the microservice's application files. The version of this image layer's data is frequently updated. For an image, when data within it needs to change, data is retrieved starting from the top layer. Lower layers require more storage space to modify. Therefore, the last layer can be placed at the top, while less frequently modified image layers can be placed at lower layers. In other words, image layers that are more easily modified should be placed at the top, and those less easily modified should be placed at the bottom.

[0116] The advantage of this setup is that data that is easy to change is placed at the upper level, while data that is not easy to change is placed at the lower level. When the image server saves the images, it can share the underlying files, reducing the pressure on the image storage, that is, reducing the storage space of the image repository. During deployment, it reduces the time to pull images and improves deployment efficiency.

[0117] Figure 4 This is a schematic diagram of the image layer structure provided in an embodiment of this disclosure. The first layer 401 can be the bottom layer of the image, and the second layer 402, the third layer 403 and the fourth layer 404 are arranged upwards in sequence. There can be other image layers above the fourth layer 404. The image layers above the fourth layer 404 can be compiled according to the application code of the microservice.

[0118] This disclosure allows for the acquisition of microservice packages and the determination of microservice service types based on the program files within the packages. Different service types correspond to different image layering rules. Microservice images are generated according to these rules and stored in an image repository. This eliminates the need for users to focus on the code writing process for image building. For different service types, images are automatically generated according to preset rules, reducing image building time and effectively lowering the professional requirements for users. Users do not need to concern themselves with the technologies used in the images or the building process, saving manpower. By establishing image layering rules, unified management of images is achieved, significantly reducing the possibility of anomalies in Docker files written by different developers and improving the accuracy and efficiency of image generation.

[0119] Figure 5 This is a structural block diagram of a microservice-based image generation apparatus provided in an embodiment of this disclosure. For ease of explanation, only the parts relevant to the embodiments of this disclosure are shown. (Refer to...) Figure 5 The microservice-based image generation device 500 includes: an acquisition unit 501, a type determination unit 502, and a generation unit 503.

[0120] The acquisition unit 501 is configured to acquire the microservice package indicated by the generation instruction in response to the generation instruction; wherein the generation instruction is used to instruct the generation of a microservice image; the package includes at least one program file, the program file being used to represent the data required to run the microservice;

[0121] The type determination unit 502 is used to determine the service type of the microservice based on the program files in the microservice's program package; wherein the service type is used to represent the microservice's operating environment;

[0122] The generation unit 503 is used to generate an image of the microservice according to a preset image layering rule corresponding to the service type of the microservice, and push the image of the microservice to a preset image repository for storage.

[0123] Figure 6 This is a structural block diagram of a microservice-based image generation device provided in an embodiment of this disclosure. Figure 6As shown, the microservice-based image generation device 600 includes an acquisition unit 601, a type determination unit 602, and a generation unit 603. The acquisition unit 601 includes an instruction response module 6011 and a package acquisition module 6012.

[0124] The instruction response module 6011 is used to respond to the generation instruction issued at regular intervals, determine the microservice to be generated as an image, and determine the package retrieval method of the microservice from a preset task database; wherein, the package retrieval method is used to indicate the source of the package when retrieval;

[0125] The package acquisition module 6012 is used to acquire the package of the microservice according to the package retrieval method of the microservice.

[0126] In one example, the device 600 also includes:

[0127] The method storage unit is used to pre-store the package retrieval method corresponding to the microservice in a preset task database; wherein, the package retrieval method includes retrieving the package from a preset package retrieval address or retrieving the package from a preset package database; the package retrieval address is used to represent the address of the package entered by the user through a web page; the package database is used to represent the database storing the package.

[0128] In one example, the package is retrieved from a preset package retrieval address;

[0129] Package acquisition module 6012 includes:

[0130] The first acquisition submodule is used to acquire the Hypertext Transfer Protocol (HTTP) address entered by the user through a web page, and retrieve the microservice package from the HTTP address; or...

[0131] The second acquisition submodule is used to acquire the package pull command input by the user through the web page, determine the package pull address of the microservice from the package pull command, and acquire the program package of the microservice from the package pull address of the microservice; wherein, the package pull command is used to pull the program package.

[0132] In one example, the device 600 also includes:

[0133] The decompression unit is used to decompress the microservice package to a preset storage location on the disk to obtain the program files in the microservice package.

[0134] In one example, generating unit 603 includes:

[0135] The rule determination module is used to determine the image layering rule corresponding to the service type of the microservice based on the preset association relationship between service type and image layering rule;

[0136] The image layer generation module is used to generate image layer data for the microservice according to the image layering rules corresponding to the service type of the microservice.

[0137] The image generation module is used to obtain the image of the microservice based on the image layer data of the microservice.

[0138] In one example, the image layer generation module includes:

[0139] The image layer determination submodule is used to determine the number of image layers for the microservice and the image layer data generation method for each image layer according to the image layering rules corresponding to the service type of the microservice.

[0140] The image layer generation submodule is used to generate image layer data for each image layer of the microservice according to the image layer data generation method corresponding to each image layer.

[0141] In one example, the image layer is a package configuration layer; the package configuration layer includes packages selected and configured by the user.

[0142] The image layer generation submodule is specifically used for:

[0143] In response to a user's custom operation on a software package, the system determines that the selected software package is a custom software package; it then retrieves the custom software package and configures it as image layer data into the software package configuration layer.

[0144] In one example, the image generation module includes:

[0145] The sequence determination submodule is used to determine the order of the image layers of the microservice according to the image layering rules corresponding to the service type of the microservice;

[0146] The image building submodule is used to build the image of the microservice from the image layer data of the microservice according to the sorting of the image layers of the microservice.

[0147] In one example, the device 600 also includes:

[0148] The deployment response unit is used to respond to microservice deployment instructions and determine the microservices to be deployed;

[0149] The image deployment unit is used to retrieve images of microservices to be deployed from the image repository and deploy the images of microservices to be deployed to a preset server.

[0150] In one example, there are at least two images of the microservice to be deployed;

[0151] The image deployment unit includes:

[0152] The target determination module is used to determine the target image of the microservice to be deployed from at least two images in response to the user's selection operation of the image of the microservice to be deployed.

[0153] The deployment module is used to obtain the target image of the microservice to be deployed from the image repository and deploy the target image to a preset server.

[0154] According to embodiments of this disclosure, this disclosure also provides an electronic device.

[0155] Figure 7 A structural block diagram of an electronic device provided in this disclosure embodiment, such as... Figure 7 As shown, the electronic device 700 includes: at least one processor 702; and a memory 701 communicatively connected to the at least one processor 702; wherein the memory stores instructions executable by the at least one processor 702, the instructions being executed by the at least one processor 702 to enable the at least one processor 702 to execute the microservice-based image generation method of this disclosure.

[0156] The electronic device 700 also includes a receiver 703 and a transmitter 704. The receiver 703 is used to receive instructions and data sent by other devices, and the transmitter 704 is used to send instructions and data to external devices.

[0157] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0158] According to embodiments of this disclosure, this disclosure also provides a computer program product comprising: a computer program stored in a readable storage medium, at least one processor of an electronic device being able to read the computer program from the readable storage medium, and the at least one processor executing the computer program causing the electronic device to perform the method provided in any of the above embodiments.

[0159] Figure 8A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0160] like Figure 8 As shown, device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 802 or a computer program loaded from storage unit 808 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0161] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0162] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as a microservice-based image generation method. For example, in some embodiments, the microservice-based image generation method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the microservice-based image generation method described above can be performed. Alternatively, in other embodiments, the computing unit 801 can be configured to perform the microservice-based image generation method by any other suitable means (e.g., by means of firmware).

[0163] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0164] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0165] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0166] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0167] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0168] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server, or simply "VPS") services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0169] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0170] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A microservice-based image generation method, comprising: In response to a generation instruction, a package of the microservice indicated by the generation instruction is obtained; wherein the generation instruction is used to instruct the generation of a microservice image; the package includes at least one program file, the program file being used to represent the data required to run the microservice; The service type of the microservice is determined based on the program files in the microservice's program package; wherein, the service type is used to represent the microservice's runtime environment; different service types correspond to different image layering rules; the image layering rules are used to generate data for each image layer; Based on the preset association between service types and image layering rules, determine the image layering rules corresponding to the service types of the microservices; Based on the image layering rules corresponding to the service type of the microservice, determine the number of image layers for the microservice and the image layer data generation method corresponding to each image layer; Based on the image layer data generation method corresponding to each image layer, generate the image layer data for each image layer of the microservice; Based on the image layer data of the microservice, the image of the microservice is obtained, and the image of the microservice is pushed to a preset image repository for storage.

2. The method according to claim 1, wherein, The step of responding to a generation command and obtaining the package of the microservice indicated by the generation command includes: In response to a timed generation command, the microservice to be generated as an image is determined, and the package retrieval method for the microservice is determined from a preset task database; wherein, the package retrieval method is used to indicate the source of the package when it is retrieved. Obtain the package of the microservice according to the package retrieval method of the microservice.

3. The method according to claim 2, further comprising: The package retrieval method corresponding to the microservice is pre-stored in a preset task database; wherein, the package retrieval method includes retrieving the package from a preset package retrieval address or retrieving the package from a preset package database; the package retrieval address is used to represent the address of the package entered by the user through a web page; the package database is used to represent the database storing the package.

4. The method according to claim 3, wherein, The package retrieval method is to retrieve the package from a preset package retrieval address; The step of obtaining the microservice package according to the microservice package retrieval method includes: Obtain the Hypertext Transfer Protocol (HTTP) address entered by the user via a webpage, and retrieve the microservice package from the HTTP address; or, The system obtains a package retrieval command input by the user via a web page, determines the package retrieval address of the microservice from the package retrieval command, and retrieves the program package of the microservice from the package retrieval address of the microservice; wherein, the package retrieval command is used to retrieve the program package.

5. The method according to any one of claims 1-4, further comprising: The microservice package is decompressed to a preset storage location on the disk to obtain the program files in the microservice package.

6. The method according to claim 1, wherein, The image layer is a software package configuration layer; the software package configuration layer includes software packages selected and configured by the user. The step of generating image layer data for each image layer of the microservice according to the image layer data generation method corresponding to each image layer includes: In response to a user's custom operation on a software package, determine the software package selected by the user, and classify it as a custom software package; Obtain the custom software package, and configure it as image layer data in the software package configuration layer.

7. The method according to claim 1, wherein, Obtaining the image of the microservice based on the image layer data of the microservice includes: The order of the image layers of the microservices is determined according to the image layering rules corresponding to the service type of the microservices; Based on the sorting of the microservice's image layers, the image layer data of the microservice is used to construct the image of the microservice.

8. The method according to any one of claims 1-4 and 6-7, further comprising: In response to the microservice deployment command, determine the microservices to be deployed; Retrieve the image of the microservice to be deployed from the image repository and deploy the image of the microservice to be deployed to the preset server.

9. The method according to claim 8, wherein, There are at least two images of the microservice to be deployed; The step of obtaining the image of the microservice to be deployed from the image repository and deploying the image of the microservice to be deployed to the preset server includes: In response to the user's selection of an image for the microservice to be deployed, determine the target image for the microservice to be deployed from at least two images; Obtain the target image of the microservice to be deployed from the image repository, and deploy the target image to the preset server.

10. A microservice-based image generation device, comprising: An acquisition unit is configured to acquire a package of microservices indicated by a generation instruction in response to a generation instruction; wherein the generation instruction is used to instruct the generation of a microservice image; the package includes at least one program file, the program file being used to represent the data required to run the microservice; The type determination unit is used to determine the service type of the microservice based on the program files in the microservice's program package; wherein, the service type is used to represent the microservice's runtime environment; different service types correspond to different image layering rules; the image layering rules are used to generate data for each image layer; The generation unit is used to generate an image of the microservice according to a preset image layering rule corresponding to the service type of the microservice, and push the image of the microservice to a preset image repository for storage. The generation unit includes: The rule determination module is used to determine the image layering rule corresponding to the service type of the microservice based on the preset association relationship between service type and image layering rule; The image layer determination submodule is used to determine the number of image layers for the microservice and the image layer data generation method for each image layer according to the image layering rules corresponding to the service type of the microservice. The image layer generation submodule is used to generate image layer data for each image layer of the microservice according to the image layer data generation method corresponding to each image layer. The image generation module is used to obtain the image of the microservice based on the image layer data of the microservice.

11. The apparatus according to claim 10, wherein, The acquisition unit includes: The instruction response module is used to respond to the generation instruction issued at regular intervals, determine the microservice to be generated as an image, and determine the package retrieval method of the microservice from a preset task database; wherein, the package retrieval method is used to indicate the source of the package when retrieval; The package acquisition module is used to acquire the package of the microservice according to the package retrieval method of the microservice.

12. The apparatus of claim 11, further comprising: The method storage unit is used to pre-store the package retrieval method corresponding to the microservice in a preset task database; wherein, the package retrieval method includes retrieving the package from a preset package retrieval address or retrieving the package from a preset package database; the package retrieval address is used to represent the address of the package entered by the user through a web page; the package database is used to represent the database storing the package.

13. The apparatus according to claim 12, wherein, The package retrieval method is to retrieve the package from a preset package retrieval address; The package acquisition module includes: The first acquisition submodule is used to acquire the Hypertext Transfer Protocol (HTTP) address entered by the user through a web page, and retrieve the microservice package from the HTTP address; or... The second acquisition submodule is used to acquire the package pull command input by the user through the web page, determine the package pull address of the microservice from the package pull command, and acquire the program package of the microservice from the package pull address of the microservice; wherein, the package pull command is used to pull the program package.

14. The apparatus according to any one of claims 10-13, further comprising: The decompression unit is used to decompress the microservice package to a preset storage location on the disk to obtain the program files in the microservice package.

15. The apparatus according to claim 10, wherein, The image layer is a software package configuration layer; the software package configuration layer includes software packages selected and configured by the user. The mirror layer generation submodule is specifically used for: In response to a user's custom operation on a software package, the system determines that the selected software package is a custom software package; it then retrieves the custom software package and configures it as image layer data into the software package configuration layer.

16. The apparatus according to claim 10, wherein, The image generation module includes: The sequence determination submodule is used to determine the order of the image layers of the microservice according to the image layering rules corresponding to the service type of the microservice; The image building submodule is used to build the image of the microservice from the image layer data of the microservice according to the sorting of the image layers of the microservice.

17. The apparatus according to any one of claims 10-13 and 15-16, further comprising: The deployment response unit is used to respond to microservice deployment instructions and determine the microservices to be deployed; The image deployment unit is used to retrieve images of microservices to be deployed from the image repository and deploy the images of microservices to be deployed to a preset server.

18. The apparatus according to claim 17, wherein, There must be at least two images of the microservice to be deployed; The mirror deployment unit includes: The target determination module is used to determine the target image of the microservice to be deployed from at least two images in response to the user's selection operation of the image of the microservice to be deployed. The deployment module is used to obtain the target image of the microservice to be deployed from the image repository and deploy the target image to a preset server.

19. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

20. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

21. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-9.

Images