A software micro-service containerization construction method, device, equipment and medium

Abstract

The embodiment of the present specification discloses a software micro-service containerization construction method, device, equipment and medium, comprising: splitting software business into multiple micro-services according to business process; encapsulating the multiple micro-services through docker to generate images corresponding to each micro-service; uploading the images corresponding to each micro-service to a pre-created docker warehouse; in the docker warehouse, obtaining images required for constructing a specified software according to a preset orchestration tool; and constructing the specified software according to the required images. The embodiment of the present specification combines the advantages of micro-service and containerization, micro-service modularizes and disassembles software to meet the needs of different customers, docker container isolates micro-service modules, container orchestration facilitates software deployment, upgrade, start-stop and other operations, and reduces public dependency redundancy.

Description

A method, apparatus, device, and medium for containerizing software microservices. Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method, apparatus, device and medium for containerizing software microservices. Background Technology

[0002] Equipment manufacturing refers to the production of key equipment that occupies the high end of the value chain and the core link of the industrial chain, and determines the overall competitiveness of the entire industrial chain. Equipment manufacturing is characterized by its technology-intensive, capital-intensive, high added value, large growth potential, and strong driving effect.

[0003] In existing technologies, equipment manufacturing software needs to serve multiple customers simultaneously. Each customer has different actual business scenarios and different requirements for the same function, requiring a large number of customized development functions, which brings great inconvenience. Summary of the Invention

[0004] This specification provides one or more embodiments of a method, apparatus, device, and medium for containerizing software microservices to solve the technical problems raised in the background.

[0005] One or more embodiments of this specification employ the following technical solutions:

[0006] This specification provides one or more embodiments of a software microservice containerization construction method, including:

[0007] Break down software business processes into multiple microservices;

[0008] The multiple microservices are encapsulated using Docker to generate images corresponding to each microservice.

[0009] Upload the images corresponding to each microservice to the pre-created Docker repository;

[0010] In the Docker repository, the images required to build the specified software are obtained according to the preset orchestration tools;

[0011] Build the specified software based on the required image.

[0012] This specification provides one or more embodiments of a software microservice containerization construction apparatus, the apparatus comprising:

[0013] Decompose the software business into multiple microservices according to the business process;

[0014] The image generation unit encapsulates the multiple microservices using Docker and generates images corresponding to each microservice.

[0015] The upload unit uploads the images corresponding to each microservice to a pre-created Docker repository;

[0016] The image acquisition unit acquires the image required to build the specified software from the Docker repository according to a preset orchestration tool.

[0017] The software building unit builds the specified software based on the required image.

[0018] This specification provides one or more embodiments of a software microservice containerization building device, comprising:

[0019] At least one processor; and,

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

[0021] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0022] Break down software business processes into multiple microservices;

[0023] The multiple microservices are encapsulated using Docker to generate images corresponding to each microservice.

[0024] Upload the images corresponding to each microservice to the pre-created Docker repository;

[0025] In the Docker repository, the images required to build the specified software are obtained according to the preset orchestration tools;

[0026] Build the specified software based on the required image.

[0027] This specification provides one or more embodiments of a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0028] Break down software business processes into multiple microservices;

[0029] The multiple microservices are encapsulated using Docker to generate images corresponding to each microservice.

[0030] Upload the images corresponding to each microservice to the pre-created Docker repository;

[0031] In the Docker repository, the images required to build the specified software are obtained according to the preset orchestration tools;

[0032] Build the specified software based on the required image.

[0033] The above-described at least one technical solution used in the embodiments of this specification can achieve the following beneficial effects:

[0034] The embodiments in this specification combine the advantages of microservices and containerization. Microservices modularize and combine software to meet the needs of different customers, while Docker containers isolate microservice modules. Container orchestration facilitates software deployment, upgrades, startup, and shutdown, and reduces redundancy in common dependencies. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0036] Figure 1 is a flowchart illustrating a method for building a containerized software microservice according to one or more embodiments of this specification;

[0037] Figure 2 is a schematic diagram of a software microservice containerization construction device provided in one or more embodiments of this specification;

[0038] Figure 3 is a structural schematic diagram of a software microservice containerization construction device provided in one or more embodiments of this specification. Detailed Implementation

[0039] This specification provides a method, apparatus, device, and medium for containerizing software microservices.

[0040] The equipment manufacturing software serves multiple clients, each with different business scenarios and varying requirements for the same functionality, resulting in extensive custom development. Many enterprise clients have confidentiality requirements, and their on-site servers are only connected to the company's internal network, unable to connect to the internet, which also limits deployment and upgrade options.

[0041] Due to differences in outputs, processes, evaluation systems, and corporate management among equipment manufacturing companies, a significant amount of customized development is needed on top of standardized solutions to match their specific application scenarios. Moreover, these companies have strong confidentiality requirements and typically deploy in private, offline environments. A comprehensive solution that meets these customized needs, rapidly develops solutions, minimizes the impact between different customized versions, reduces redundancy, facilitates deployment and upgrades, and is suitable for private, offline environments is rare in the market. Traditional monolithic software construction methods are highly integrated; modifying a single module requires repackaging the entire software, resulting in low deployment and upgrade efficiency. Multiple customized versions of the same module are also redundantly packaged, increasing size and making development and management difficult. This often proves challenging with a large customer base, leading to high development and maintenance costs.

[0042] The embodiments in this specification can apply microservices and containerization technologies to finely decompose business processing code, achieving a modular effect, facilitating development and deployment, meeting the personalized needs of equipment manufacturing enterprises, and applying container orchestration technology to eliminate the limitations of offline environments on container solutions, ensuring availability even when offline.

[0043] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0044] Figure 1 is a flowchart illustrating a software microservice containerization construction method provided in one or more embodiments of this specification. This process can be executed by a software microservice containerization construction system. Certain input parameters or intermediate results in the process can be manually adjusted to help improve accuracy.

[0045] The method flow steps of the embodiments in this specification are as follows:

[0046] S102 breaks down software business into multiple microservices according to business processes.

[0047] In the embodiments of this specification, the software business is divided into multiple microservices according to the business process, which can achieve the effect of modularization. They can be combined according to different situations, which facilitates software development and deployment and meets the personalized needs of equipment manufacturing enterprises.

[0048] S104. The multiple microservices are encapsulated using Docker to generate images corresponding to each microservice.

[0049] In the embodiments of this specification, before generating the corresponding images for each microservice by encapsulating the multiple microservices using Docker, environment variables and startup commands can be added to each of the multiple microservices to facilitate batch management of microservices.

[0050] S106, upload the images corresponding to each microservice to the pre-created Docker repository.

[0051] S108, In the Docker repository, obtain the image required to build the specified software according to the preset orchestration tool.

[0052] In the embodiments of this specification, during the process of obtaining the image required to build the specified software according to the preset orchestration tool, when logging into the Docker repository while connected to the Internet, docker-compose can be started according to the pre-written container orchestration file to automatically pull the required image.

[0053] In the embodiments of this specification, before starting docker-compose to automatically pull the required image according to the pre-written container orchestration file, the container orchestration file can be written to combine the required functional modules, mount the volume to share the JRE runtime environment, and mount the volume to extract the JAR package file of each microservice and place it in the real path of the host machine.

[0054] In the embodiments of this specification, the image required for the specified software can also be built in an offline environment. The required image can be imported by specifying the docker command, and docker-compose can be started according to the container orchestration file to replace the corresponding jar package file with the required image.

[0055] In the embodiments of this specification, the process of automatically pulling the required image by starting docker-compose according to the pre-written container orchestration file can be carried out through the following specific steps:

[0056] The container orchestration file declares the containers to be started, including startup order control, volume configuration, port mapping, and environment variables. Based on the container's data volume characteristics, after mapping the container's internal path to the host machine's path, if no file exists on the host machine, it will be automatically copied from the container to the host machine after the container starts. If a file already exists on the host machine, it will be overwritten during runtime. Furthermore, modifying files on the host machine while the container is running will also change the files within the container. The container's runtime environment files are mapped to the host machine's path; after startup, the host machine will have a copy of the JRE file, and the remaining microservices will... The image declares the JRE path using environment variables during the build process or in the container orchestration file, mapping the physical path of the JRE on the host machine to the JRE path within each microservice container. After startup, the container will contain the necessary files for the runtime environment. All JRE files come from the same JRE image, and each microservice no longer contains its own JRE, ensuring a consistent runtime environment and reducing the overall size. Multiple microservices will depend on the same JAR package. Based on data volumes, the JAR package inside the microservice image is mounted to the host machine path. Replacing the host machine JAR package will synchronously replace the JAR package in the container, and restarting the container will take effect.

[0057] It should be noted that mounting a volume is the same as mounting a data volume. Mounting a data volume can involve mounting the host folder to a specified directory within the container. If there are files at the mount point, the original files will be hidden and will be restored after unmounting.

[0058] S110, Build the specified software based on the required image.

[0059] It should be noted that the embodiments in this specification may involve the application of Java microservice decomposition technology, Nacos microservice registration and discovery technology, Docker containerization technology, Docker-compose container orchestration technology, etc. in equipment manufacturing software. This method enables the use of Java microservice features and Docker container features in a private deployment mode without relying on a Docker repository, while also being compatible with public cloud mode.

[0060] The embodiments in this specification combine the advantages of microservices and containerization. Microservices modularize and combine software to meet the needs of different customers, while Docker containers isolate microservice modules. Container orchestration facilitates software deployment, upgrades, startup, and shutdown, reduces redundancy of common dependencies, and eliminates the adverse effects of offline environments on container solutions. It also makes up for the problem that container solutions are not suitable for offline environments, while being compatible with public clouds and private cloud environments.

[0061] The embodiments in this specification can be implemented through the following schemes:

[0062] 1. Business microservice decomposition solution

[0063] Based on actual business needs, microservice modules are distinguished, such as basic system function microservices, user permission and user settings microservices, document management microservices, etc. The scope and responsibilities of each microservice are determined through business analysis and decomposition. Nacos is used to register, discover and configure services to realize the microservice-based functionality of Java backend functions.

[0064] 2. Docker image packaging

[0065] Java microservices are packaged using Docker, based on a minimal Alpine image, for easy microservice package management. Default environment variables and startup commands can be added during packaging for convenient batch management of microservices.

[0066] 3. Docker-compose container orchestration

[0067] Each Java microservice is packaged into a Docker image. With a large number of images, Docker Compose facilitates image management and startup / shutdown. The volume-based nature of container orchestration allows for the sharing of common dependencies within the images, reducing the overall deployment size of the project.

[0068] 4. Upload the mirror repository

[0069] We build our own Docker repository in a stable network environment, targeting the public cloud, to facilitate product iteration. After updating the microservice code, we package it into a new image and push it to the Docker repository. Users can directly pull the latest image from the repository to get the new version and new features.

[0070] Furthermore, the embodiments of this specification can be implemented through the following optimization schemes:

[0071] This invention implements a microservice containerization construction method suitable for highly customized software in equipment manufacturing. Through the embodiments described in this specification, software microservices and image-based architecture can be achieved. Software can be developed, deployed, and updated in modules, with clear division of responsibilities after business decomposition. The same module can be highly customized into multiple versions. By adjusting container orchestration files, different module combinations can be achieved to meet user customization needs. During development, redundant code from multiple versions can be avoided, reducing development and maintenance costs. A self-built Docker repository facilitates the release of new versions in a public cloud environment. The Docker volume mounting feature is flexibly utilized to extract and mount redundant parts of each microservice, reducing size. Frequently updated parts are also extracted and mounted. Even when the repository is unavailable in a network outage environment, microservices can be deployed and updated via files without changing the software development, packaging, and deployment logic.

[0072] Taking Java as an example, the main steps are as follows:

[0073] 1. Obtain the official Nacos Docker image for microservice configuration and registration / discovery. The software is containerized using Docker, and Nacos also uses a Docker image to avoid the hassle of environment configuration.

[0074] 2. Develop and build a gateway microservice to distribute requests to target microservices. This microservice is required.

[0075] 3. Develop and build a user authentication microservice, responsible for user identity verification, etc. This can be adjusted according to actual needs, or it can be merged into the gateway microservice.

[0076] 4. Develop and build basic functional microservices, such as user registration, login, permission management, and message notification, which are generally also necessary.

[0077] 5. Develop and build functional module microservices, break them down according to business needs, define responsibilities, and form standardized products.

[0078] 6. Develop and build custom module microservices, creating a new codebase to avoid duplication and conflicts with standard modules during development, ensuring they do not interfere with each other. These are customized according to customer needs and are not suitable for inclusion in standardized products.

[0079] 7. Taking Java as an example, programs require a JRE runtime environment to run. The JRE file and other necessary files are packaged into an image, which is then mounted into a container to provide a runtime environment for all Java microservices. Nacos also requires a JRE.

[0080] 8. Package each of the microservices built above into a Docker image. Generally, you only need the base image, the packaged JAR file, and a script containing the startup commands for the JAR file. When packaging the image, specify the JRE path using environment variables in the Dockerfile, or you can set environment variables in the container orchestration file later.

[0081] 9. Write container orchestration files to combine the required functional modules. Mount the volume to share the JRE runtime environment. Extract the JAR file for each microservice from the volume and place it in the actual path on the host machine. When the network is offline, the JAR file can be directly replaced to update the module.

[0082] 10. You can build your own Docker repository and choose Harbor.

[0083] 11. All the above images are pushed to the self-built repository. Users can log in to the repository online and start docker-compose according to the container orchestration file to automatically pull the missing images. When updating images, users can manually pull and restart to make the changes take effect.

[0084] 12. For the initial deployment in an offline environment, export the required images as a compressed package, specifically using docker commands. After providing the image to the user, import it and start docker-compose according to the container orchestration file; no repository dependency is required. To update functionality, replace the corresponding JAR files and restart the container.

[0085] Furthermore, the embodiments of this specification can be implemented through the following specific schemes:

[0086] 1. Base Image Preparation

[0087] The entire microservice architecture is managed by Nacos, which handles container configuration, microservice registration, discovery, and scheduling. Obtain the Nacos image from the official website; further encapsulation can be performed if needed. Both Java programs and Nacos depend on the JRE; the JRE environment package is encapsulated into an image to provide the runtime environment for all Java microservices. The Gateway microservice distributes requests to specific module microservices; user authentication logic can be added, and it is packaged together with the startup script into an image. Common user registration, login, system settings, and message notifications are generally standardized functions; these functions are centralized into a single microservice, packaged together with the startup script into an image. All of these images are essential in various module combination schemes.

[0088] 2. Functional Module Business Division

[0089] Following the standard product design, functionalities are distributed across modules, which are then packaged together with the startup script into a single image. Modules with a high probability of customization can be broken down into smaller parts to reduce redundant development and facilitate module combination; frequently updated components should also be broken down into smaller parts to allow for independent module updates and reduce the probability of interference with other modules.

[0090] 3. Customized module development

[0091] For new customization requirements beyond the standard modules, a new image is created, just like adding a new standard module. For highly customized modifications to the standard modules, a new set of module code is created, customized, packaged into an image, and used to replace the corresponding standard module during module deployment to meet the customization requirements.

[0092] 4. Self-built Docker repository

[0093] For self-hosted Docker repositories, Harbor is typically chosen. Deployment to a public cloud server follows the official guidelines, and user passwords are set. Product images are pushed to the repository, and users can remotely pull them.

[0094] 5. Docker-compose container orchestration

[0095] Docker-compose leverages container orchestration to retain the advantages of microservice containerization while reducing project size, facilitating deployment and updates, and ensuring compatibility with private, offline environments. The Docker-compose container orchestration file declares the containers to be started, controls the startup order, configures volumes, maps ports, and sets environment variables. Based on the data volume characteristics of containers, after mapping paths within containers to paths on the host machine, if a file doesn't already exist on the host machine, it will be automatically copied from the container to the host machine after the container starts. If a file already exists on the host machine, it will be overwritten during runtime. Modifying files on the host machine during container runtime will also change the files within the container; the same applies to folders. The JRE runtime environment files within the container are mapped to the host machine path. After startup, the host machine will store a copy of the JRE file. Other Java microservice images declare the JRE path during construction or through environment variables in the container orchestration file, mapping the physical path where the JRE is stored on the host machine to the JRE path within each microservice container. This ensures that the containers will contain the necessary runtime environment files after startup. All JRE files originate from the same JRE image, eliminating the need for individual JREs within each microservice. This ensures a consistent runtime environment and reduces overall size. Multiple microservices may depend on the same JAR file; larger JAR files can be extracted and packaged into a separate image. Also based on data volumes, JAR files within the microservice image are mounted to the host machine's path. Replacing a JAR file on the host machine synchronously replaces the JAR files within the container, and the changes take effect upon container restart. Even in offline environments, new JAR files can be added to update functionality without relying on Docker repositories.

[0096] Figure 2 is a schematic diagram of a software microservice containerization construction device provided in one or more embodiments of this specification. The device includes: a splitting unit 202, an image generation unit 204, an uploading unit 206, an image acquisition unit 208, and a software construction unit 210.

[0097] Unit 202 splits the software business into multiple microservices according to the business process;

[0098] Image generation unit 204 encapsulates the multiple microservices using Docker to generate images corresponding to each microservice.

[0099] Upload unit 206 uploads the images corresponding to each microservice to a pre-created Docker repository;

[0100] Image acquisition unit 208 acquires the image required to build the specified software from the Docker repository according to a preset orchestration tool;

[0101] Software building unit 210 builds the specified software based on the required image.

[0102] Furthermore, the mirror acquisition unit 208 is used for:

[0103] When logging into the Docker repository while connected to the internet, starting Docker-compose according to the pre-written container orchestration file can automatically pull the required images.

[0104] Figure 3 is a schematic diagram of the structure of a software microservice containerization construction device provided in one or more embodiments of this specification, including:

[0105] At least one processor; and,

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

[0107] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0108] Break down software business processes into multiple microservices;

[0109] The multiple microservices are encapsulated using Docker to generate images corresponding to each microservice.

[0110] Upload the images corresponding to each microservice to the pre-created Docker repository;

[0111] In the Docker repository, the images required to build the specified software are obtained according to the preset orchestration tools;

[0112] Build the specified software based on the required image.

[0113] This specification provides one or more embodiments of a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0114] Break down software business processes into multiple microservices;

[0115] The multiple microservices are encapsulated using Docker to generate images corresponding to each microservice.

[0116] Upload the images corresponding to each microservice to the pre-created Docker repository;

[0117] In the Docker repository, the images required to build the specified software are obtained according to the preset orchestration tools;

[0118] Build the specified software based on the required image.

[0119] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0120] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0121] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for containerizing software microservices, characterized in that, The method includes: splitting software business into multiple microservices according to business processes; encapsulating the multiple microservices using Docker to generate images corresponding to each microservice; uploading the images corresponding to each microservice to a pre-created Docker repository; obtaining the images required to build the specified software from the Docker repository according to a preset orchestration tool; and building the specified software according to the required images. The step of obtaining the images required to build the specified software according to the preset orchestration tool includes: when logging into the Docker repository while connected to the internet, starting Docker-compose according to a pre-written container orchestration file can automatically pull the required images. Before starting Docker-compose according to the pre-written container orchestration file to automatically pull the required images, the method further includes: writing the container orchestration file, combining the required functional modules, mounting a shared JRE runtime environment, extracting the JAR package files of each microservice from the mounted file, and placing them in the actual path of the host machine. The step of starting Docker-compose according to the pre-written container orchestration file to automatically pull the required images includes: in the container orchestration file... The configuration file declares the containers to be started, controls the startup order, configures volumes, maps ports, and sets environment variables. Based on the container's data volume characteristics, after mapping the container's internal path to the host machine's path, if the file does not exist on the host machine, it will be automatically copied from the container to the host machine after the container starts. If the file already exists on the host machine, it will be overwritten during runtime. Modifying files on the host machine during container runtime will also change the files within the container. Mapping the container's runtime environment files to the host machine's path ensures that a copy of the JRE file will be stored on the host machine after startup; other microservice images will be stored in the configuration file. During container setup or in the container orchestration file, declare the JRE path using environment variables. Map the physical path where the JRE is stored on the host machine to the JRE path within each microservice container. After startup, the container will contain the necessary files for the runtime environment. All JRE files come from the same JRE image, and each microservice no longer contains its own JRE, ensuring a consistent runtime environment and reducing the overall size. Multiple microservices will depend on the same JAR package. Based on data volumes, the JAR package inside the microservice image is mounted to the host machine path. Replacing the host machine JAR package will synchronously replace the JAR package in the container, and restarting the container will take effect.

2. The method according to claim 1, characterized in that, Before generating images corresponding to each microservice by encapsulating the multiple microservices using Docker, the method further includes adding environment variables and startup commands to the multiple microservices respectively.

3. The method according to claim 1, characterized in that, When building the image required for specified software in an offline environment, the method further includes: importing the required image by specifying a docker command, starting docker-compose according to the container orchestration file, and replacing the corresponding jar package file with the required image.

4. A software microservice containerization construction device, characterized in that, The device includes: a splitting unit for splitting software business into multiple microservices according to business processes; an image generation unit for encapsulating the multiple microservices using Docker to generate images corresponding to each microservice; an uploading unit for uploading the images corresponding to each microservice to a pre-created Docker repository; an image acquisition unit for acquiring images required to build specified software from the Docker repository according to a preset orchestration tool; and a software building unit for building the specified software based on the required images. The image acquisition unit is used to: automatically pull the required images by starting Docker-compose according to a pre-written container orchestration file when logging into the Docker repository while connected to the network; before starting Docker-compose according to the pre-written container orchestration file to automatically pull the required images, the device further includes: writing the container orchestration file, combining the required functional modules, mounting a shared JRE runtime environment, extracting the JAR package files of each microservice from the mounted file, and placing them in the actual path of the host machine; the automatic pulling of the required images by starting Docker-compose according to the pre-written container orchestration file includes: The container orchestration file declares the containers to be started, including startup order control, volume configuration, port mapping, and environment variables. Based on the container's data volume characteristics, after mapping the container's internal path to the host machine's path, if no file exists on the host machine, it will be automatically copied from the container to the host machine after the container starts. If a file already exists on the host machine, it will be overwritten during runtime. Modifying files on the host machine during container runtime will also change the files within the container. Mapping the container's runtime environment files to the host machine's path ensures that a copy of the JRE file will be stored on the host machine after startup, along with other microservice images. During the build process or in the container orchestration file, the path to the JRE is declared using environment variables. This maps the physical path where the JRE is stored on the host machine to the JRE path within each microservice container. After startup, the container will contain the necessary files for the runtime environment. All JRE files come from the same JRE image, and each microservice no longer contains its own JRE, ensuring a consistent runtime environment and reducing the overall size. Multiple microservices will depend on the same JAR file. Based on data volumes, the JAR file inside the microservice image is mounted to the host machine path. Replacing the host machine JAR file will synchronously replace the JAR file in the container, and restarting the container will take effect.

5. A software microservice containerization building device, characterized in that, include: At least one processor; And, a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: decompose software business into multiple microservices according to business processes; encapsulate the multiple microservices using Docker to generate images corresponding to each microservice; upload the images corresponding to each microservice to a pre-created Docker repository; in the Docker repository, obtain the images required to build the specified software according to a preset orchestration tool; build the specified software according to the required images; the step of obtaining the images required to build the specified software according to the preset orchestration tool includes: when logging into the Docker repository while connected to the network, starting Docker-compose according to a pre-written container orchestration file can automatically pull the required images; before starting Docker-compose according to the pre-written container orchestration file to automatically pull the required images, it further includes: writing the container orchestration file, combining the required functional modules, mounting a shared JRE runtime environment, extracting the JAR package files of each microservice from the mounted file, and placing them in the actual path of the host machine; the step of starting Docker-compose according to the pre-written container orchestration file... ocker-compose can automatically pull the required images, including: declaring the containers to be started in the container orchestration file, controlling the startup order, configuring volume, port mapping, and environment variables; based on the data volume characteristics of the container, after mapping the paths inside the container to the host machine path, if there are no files in the host machine path, a copy will be automatically copied from the container to the host machine path after the container starts; if files already exist in the host machine path, they will be overwritten during runtime; when the container is running, modifying files in the host machine path will also change the files inside the container; mapping the runtime environment files inside the container to the host machine path will ensure that the host machine stores them after startup. A single JRE file is used, and the paths to the JREs in the remaining microservice images are declared as environment variables during the build process or in the container orchestration file. This maps the physical path where the JRE is stored on the host machine to the JRE path within each microservice container, ensuring that the necessary runtime environment files are present in the container after startup. Since all JRE files originate from the same JRE image, each microservice no longer contains its own JRE, guaranteeing a consistent runtime environment and reducing overall size. Multiple microservices will depend on the same JAR file. Based on data volumes, the JAR file inside the microservice image is mounted to the host machine path. Replacing the host machine JAR file will synchronously replace the JAR file within the container, and restarting the container will take effect.

6. A non-volatile computer storage medium, characterized in that, The system stores computer-executable instructions, which are configured to: decompose software business into multiple microservices according to business processes; encapsulate the multiple microservices using Docker to generate images corresponding to each microservice; upload the images corresponding to each microservice to a pre-created Docker repository; obtain the images required to build the specified software from the Docker repository according to a preset orchestration tool; and build the specified software based on the required images. The step of obtaining the images required to build the specified software according to the preset orchestration tool includes: when logging into the Docker repository while connected to the internet, starting Docker-compose according to a pre-written container orchestration file can automatically pull the required images; before starting Docker-compose according to the pre-written container orchestration file to automatically pull the required images, the system further includes: writing the container orchestration file, combining the required functional modules, mounting a shared JRE runtime environment, extracting the JAR file of each microservice from the mounted file, and placing it in the actual path of the host machine; the step of starting Docker-compose according to the pre-written container orchestration file to automatically pull the required images includes... The container orchestration file declares the containers to be started, including startup order control, volume configuration, port mapping, and environment variables. Based on the container's data volume characteristics, after mapping the container's internal path to the host machine's path, if no file exists on the host machine, it will be automatically copied from the container to the host machine after the container starts. If a file already exists on the host machine, it will be overwritten during runtime. Modifying files on the host machine during container runtime will also change the files within the container. Mapping the container's runtime environment files to the host machine's path ensures that a copy of the JRE file will be stored on the host machine after startup, while other microservice mirrors will remain. By declaring the JRE path as an environment variable during build or in the container orchestration file, the physical path where the JRE is stored on the host machine is mapped to the JRE path within each microservice container. After startup, the container will contain the necessary files for the runtime environment. All JRE files come from the same JRE image, and each microservice no longer contains its own JRE, ensuring a consistent runtime environment and reducing the overall size. Multiple microservices will depend on the same JAR package. Based on data volumes, the JAR package inside the microservice image is mounted to the host machine path. Replacing the host machine JAR package will synchronously replace the JAR package in the container, and restarting the container will take effect.

Images