A Docker-based module deployment method, apparatus, and device

Abstract

This application discloses a Docker-based module deployment method, apparatus, device, and storage medium to address the problem that existing solutions for port conflicts between middleware modules to be deployed are time-consuming and labor-intensive, resulting in long module integration and testing cycles and slowing down deployment progress. The method includes: obtaining CPU architecture information of the target computing device; obtaining Docker middleware image containers that match the CPU architecture information; wherein the container set is used to store: Docker middleware image containers created based on images of middleware modules developed for different CPU architectures; and deploying the obtained Docker middleware image containers that match the CPU architecture information on the target computing device. This method ensures efficient deployment of middleware modules on the target computing device.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a Docker-based module deployment method, apparatus, device, and computer-readable storage medium. Background Technology

[0002] In the field of software development, teamwork is increasingly being adopted for multi-module development. Specifically, team members, based on mature middleware, each complete their own software component, ultimately resulting in a finished middleware.

[0003] Each middleware component, once developed, needs to be integrated and deployed on the same computing device. Therefore, relative to the final integrated software, each middleware component can be called a module, or middleware module.

[0004] Currently, the most common problem encountered when deploying middleware modules to computing devices is port conflicts due to inconsistencies in the middleware versions used for development. Existing solutions require operations and maintenance personnel to analyze the syntax of the conflicting middleware code and modify the inappropriate parts. Since different middleware modules may use different syntaxes, this approach requires significant learning effort from operations and maintenance personnel, is time-consuming and labor-intensive, and leads to lengthy integration and testing cycles, slowing down the deployment process. Summary of the Invention

[0005] This application provides a Docker-based module deployment method to address the problem that, when port conflicts arise between middleware modules during deployment, existing solutions require maintenance personnel to invest significant time and effort in learning the software code syntax used by different middleware modules, resulting in a long integration and testing cycle and slowing down the deployment progress.

[0006] This application also provides a Docker-based module deployment device, equipment, and computer-readable storage medium to solve the problem that when port conflicts occur between middleware modules during middleware module deployment, the existing solutions require maintenance personnel to invest a lot of time and effort in learning the software code syntax used by different middleware modules, which is time-consuming and laborious, resulting in a long middleware module integration and testing cycle and slowing down the deployment progress.

[0007] The embodiments of this application adopt the following technical solutions:

[0008] A Docker-based module deployment method includes:

[0009] Obtain information about the CPU architecture of the target computing device; the target computing device has a Docker server installed.

[0010] Based on the CPU architecture information, a Docker middleware image container matching the CPU architecture information is obtained from a pre-stored set of Docker middleware image containers; wherein, the set of containers is used to store: Docker middleware image containers created based on images of images of middleware modules developed for different CPU architectures.

[0011] On the target computing device, a Docker middleware image container that matches the acquired CPU architecture information is deployed.

[0012] A Docker-based module deployment device, the device comprising:

[0013] An architecture information acquisition unit is used to acquire information about the CPU architecture of the target computing device; the target computing device is equipped with a Docker server.

[0014] The container acquisition unit is used to acquire, based on the CPU architecture information, a Docker middleware image container that matches the CPU architecture information from a container set that has been pre-stored with Docker middleware image containers; wherein, the container set is used to store: Docker middleware image containers created based on images of middleware modules developed for different CPU architectures.

[0015] The deployment unit is used to deploy a Docker middleware image container that matches the CPU architecture information on the target computing device.

[0016] A computing device includes: a memory and a processor, wherein,

[0017] The memory is used to store programs;

[0018] The processor, coupled to the memory, is configured to execute the program stored in the memory for performing any of the methods described above.

[0019] A computer-readable storage medium storing a computer program that, when executed by a computer, can implement any of the methods described above.

[0020] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0021] Compared to existing technologies that address port conflicts between middleware modules during deployment, the method provided in this application leverages the sandbox mechanism of Docker containers, which eliminates the need to resolve port conflicts between middleware modules during deployment. This avoids the need for operations and maintenance personnel to invest significant time in learning the different software code syntaxes used by various middleware modules, thus preventing prolonged integration and testing cycles and delays in deployment. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1a A diagram illustrating the process of obtaining a Docker middleware image container for a target computing device;

[0024] Figure 1b A schematic diagram illustrating the specific implementation process of a Docker-based module deployment method provided in Embodiment 1 of this application;

[0025] Figure 1c This is a flowchart illustrating a specific implementation of deleting a Docker middleware image container in Embodiment 1 of this application;

[0026] Figure 2 This is a schematic diagram of the specific structure of a Docker-based module deployment device in an embodiment of this application;

[0027] Figure 3 This is a schematic diagram of the specific structure of a computing device provided in Embodiment 3 of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0030] Example 1

[0031] To address the issue that existing solutions for middleware module deployment require maintenance personnel to invest significant time and effort in learning the different software code syntaxes used by various middleware modules when port conflicts arise between middleware modules, resulting in long integration and testing cycles and slowing down deployment progress, this application provides a Docker-based module deployment method applicable to computing devices with Docker servers installed.

[0032] Before providing a detailed description of the method, the following explanations will clarify some related terms and the concepts of the embodiments in this application:

[0033] Mirroring, or image storage, is a file storage method. A mirror image is created when data from one disk is copied exactly to another disk. Many files can be created into an image file and placed on the same disk as programs like GHOST. After opening the image with GHOST or similar software, the image is restored to the original set of files used to create it.

[0034] Docker is a lightweight container management engine that allows developers to package their applications and dependencies into a portable image, which can then be deployed to physical or virtual machines. Using this image, containers (Docker-managed containers are also called Docker containers) can be created and then run. Docker containers use a sandbox mechanism, meaning they have no interfaces with each other. Docker provides various container management / operation tools, such as those for distribution, porting, deletion, and restarting. Docker uses a client-server (C / S) architecture. The Docker daemon acts as the Docker server, receiving requests from Docker clients and processing these requests (such as requests to the Docker server to create, run, or distribute containers) using a remote application programming interface (API) to perform corresponding actions on the Docker containers.

[0035] A container is an independently running application (or a group of applications) and its required runtime environment. From a technical implementation perspective, a container is a running instance of an application created from an image. Containers run directly in user space above the operating system kernel, and one or more processes can run within a container. Container technology allows multiple independent user spaces to run on the same host machine. Containers can run on both physical machines and virtual machines.

[0036] Based on the relevant technologies corresponding to the above-mentioned terms, the inventors conceived a method for deploying middleware modules based on the characteristics of Docker. After developers create the middleware module, the middleware module is made into an image (middleware module image), and then a Docker container is created from the image.

[0037] A Docker container created in the manner described above can be called a Docker middleware image container. The created Docker middleware image container can be centrally stored in a container collection, which can then be deployed in the storage space of a specific device.

[0038] Subsequently, such as Figure 1a As shown, the computing device on which the middleware module is to be deployed (for ease of description, it can be referred to as the target computing device, which has a Docker server installed) can connect to the network with the device that has the container set deployed (for ease of description, it can be referred to as the storage device), and then obtain the Docker middleware image container that matches the CPU architecture of the target computing device from the container set and run it, thereby completing the deployment of the middleware module on the target computing device, so that the target computing device has the corresponding functions of the middleware module.

[0039] As mentioned above, one characteristic of Docker is that Docker containers use a sandbox mechanism and have no interfaces with each other. Therefore, compared with the middleware module deployment methods used in the prior art, the deployment method provided in this application embodiment can achieve the purpose of middleware module deployment without facing the problem of resolving port conflicts between middleware modules during the middleware module deployment process. This also avoids the problem that operation and maintenance personnel have to spend a lot of energy learning the software code syntax used by different middleware modules, resulting in a long middleware module integration and testing cycle and slowing down the deployment progress.

[0040] The above is an introduction to some related terms and inventive concepts. The following continues to introduce the specific implementation process of the method provided in the embodiments of this application.

[0041] like Figure 1b The diagram shown is a schematic of the specific implementation process of a Docker-based module deployment method provided in Embodiment 1 of this application. The execution subject of this method can be the target computing device itself, or other devices specifically used to deploy middleware modules for computing devices, such as middleware module deployment servers. This embodiment of the application does not specifically limit the execution subject of this method.

[0042] For ease of description, the following description uses the target computing device as the execution subject of this method. The method specifically includes the following steps:

[0043] Step 11: The target computing device obtains information about the architecture of its central processing unit (CPU);

[0044] The target computing device mentioned here refers to the computing device on which the middleware module is to be deployed.

[0045] CPU architecture is a specification defined by CPU manufacturers for CPU products within the same series, primarily to differentiate between different types of CPUs. The CPU market is mainly divided into two camps: one is the Complex Instruction Set Computing (CASIC) CPU, led by Intel (a global leader in the semiconductor industry and computing innovation) and AMD (Advanced Micro Devices), and the other is the Reduced Instruction Set Computing (RISC) CPU, led by IBM (International Business Machines Corporation) and ARM (a global leader in semiconductor intellectual property). Different brands of CPUs use different architectures; for example, Intel and AMD CPUs use the x86 architecture, while IBM CPUs use the PowerPC architecture, and ARM CPUs use the ARM architecture.

[0046] In this embodiment, the reason for obtaining CPU architecture information is to ensure that the Docker middleware image container obtained subsequently can match the CPU architecture of the target computing device, so that it can be run normally by the target computing device.

[0047] Step 12: Based on the obtained CPU architecture information, the target computing device retrieves a Docker middleware image container that matches the CPU architecture information from a pre-stored collection of Docker middleware image containers.

[0048] The container set is used to store Docker middleware image containers created based on images of middleware modules developed for different CPU architectures.

[0049] In one implementation, the Docker middleware image container, created based on middleware modules developed for different CPU architectures, is generated in the following manner:

[0050] Using Spring Boot to publish JAR files, middleware modules developed for different CPU architectures are published as JAR files; based on these JAR files, a Docker middleware image container containing the JAR files is generated.

[0051] The advantage of publishing as a JAR file to generate a Docker middleware image container is that, subsequently, if a middleware module needs to be upgraded on the target computing device or within the container set, it is only necessary to delete the old Docker middleware image container and then create a new Docker middleware image container using the upgraded middleware module image. Specifically, if a Docker middleware image container cannot be deleted, the upgrade can be performed directly by replacing the JAR file within that undeletable Docker middleware image container, and then the Docker middleware image container can be restarted to complete the upgrade.

[0052] Once the middleware module is developed, developers can configure its CPU architecture information to indicate which CPU architecture it is compatible with. This CPU architecture information can be stored in a container collection along with corresponding Docker middleware image containers. This allows the system to query the container collection for information matching the CPU architecture of the target computing device; if a match is found, the corresponding Docker middleware image container can be retrieved from the container collection.

[0053] In this embodiment of the application, when obtaining Docker middleware image containers from the container set, it is considered that the container set contains a relatively large number of Docker middleware image containers that match the CPU architecture information of the target computing device. However, not all Docker middleware image containers that match the CPU architecture information of the target computing device are actually needed by the target computing. Therefore, it is possible to further combine the list of middleware modules required by the target computing device to obtain them, and only obtain the Docker middleware image containers created by the images of the middleware modules listed on the list, thereby avoiding the problem of unnecessary waste of processing resources caused by obtaining useless containers.

[0054] The list of middleware modules can be pre-set and input into the target computing device by the operators. The list can include the names of the middleware modules, such as Redis (Remote Dictionary Server, an open-source, ANSI C-written, network-enabled, memory-based or persistent log-type key-value database that provides APIs for multiple languages), nginx (a high-performance HTTP and reverse proxy web server that also provides IMAP / POP3 / SMTP services), cs, MySQL (a relational database management system), etc.

[0055] Given the aforementioned list, when retrieving Docker middleware image containers from the container set, the target computing device can obtain Docker middleware image containers corresponding to the names of the middleware modules listed in the list. In this way, the target computing device obtains Docker middleware image containers that match both its CPU architecture information and the names of the middleware modules in the list.

[0056] Considering that the target computing device may also obtain the Docker middleware image container based on the name of the middleware module, in this embodiment of the application, when storing the Docker middleware image container in the container set, the name of the middleware module, the CPU architecture information and the Docker middleware image container can be stored accordingly, so that the target computing device can obtain the Docker middleware image container based on the name of the middleware module and the CPU architecture information.

[0057] Step 13: Deploy the Docker middleware image container that matches the CPU architecture information on the target computing device.

[0058] After obtaining the Docker middleware image container, the target computing device can run these Docker middleware image containers, thereby enabling the target computing device to have the functionality of the target middleware module corresponding to these Docker middleware image containers, and achieving the purpose of deploying the middleware module on the target computing device.

[0059] Compared to existing technologies that address port conflicts between middleware modules during deployment, the method provided in this application leverages the sandbox mechanism of Docker containers, which eliminates the need to resolve port conflicts between middleware modules during deployment. This avoids the problem of operations and maintenance personnel investing significant time in learning the different software code syntaxes used by various middleware modules, thus preventing prolonged integration and testing cycles and delays in deployment.

[0060] Optionally, in one implementation, when creating a Docker middleware image container, the middleware module is first published as a JAR file, and then a Docker middleware image container containing the JAR file is generated based on the JAR file. This can be achieved using methods such as... Figure 1c The middleware module is upgraded using the following method:

[0061] Step 111: Before upgrading a Docker middleware image container (referred to as the target Docker middleware image container for ease of description) deployed on the target computing device, the target computing device determines whether the target Docker middleware image container can be deleted; if it is determined that it can be deleted, then proceed to step 112; if it is determined that it cannot be deleted, then proceed to step 113.

[0062] Step 112: Delete the target Docker middleware image container, obtain the upgraded target Docker middleware image container, and deploy it to the target computing device;

[0063] Step 113: Obtain the upgraded JAR file corresponding to the target Docker middleware image container; use the upgraded JAR file to replace the JAR file in the target Docker middleware image container deployed on the target computing device; after the replacement is complete, restart the target Docker middleware image container so that the upgraded middleware module's functionality takes effect.

[0064] Optionally, restarting the Docker middleware image container on the target computing device can be achieved through methods such as:

[0065] The target computing device receives a restart instruction for a middleware module to be restarted deployed on the target computing device; wherein, the restart instruction may include the identifier (such as name) of the specific middleware module (or Docker middleware image container) to be restarted;

[0066] In response to the restart command, the target computing device determines the Docker middleware image container corresponding to the middleware module to be restarted—for example, it can determine the Docker middleware image container to be restarted based on the identifier (such as the name) of the middleware module (or Docker middleware image container) to be restarted.

[0067] For the Docker middleware image container that corresponds to the middleware module to be restarted, perform the restart operation.

[0068] Example 2

[0069] Based on the same inventive concept as Embodiment 1 of this application, Embodiment 2 of this application provides a Docker-based module deployment device to solve the problem that when there are port conflicts between middleware modules during the middleware module deployment process, the existing solutions require maintenance personnel to invest a lot of effort to learn the software code syntax used by different middleware modules, which is time-consuming and laborious, resulting in a long middleware module integration and testing cycle and slowing down the deployment progress.

[0070] A schematic diagram of the specific structure of the device is shown below. Figure 2 As shown, it includes the following functional units:

[0071] Architecture information acquisition unit 21 is used to acquire information about the CPU architecture of the target computing device; the target computing device is equipped with a Docker server.

[0072] The container acquisition unit 22 is used to acquire, based on the CPU architecture information acquired by the architecture information acquisition unit 21, a Docker middleware image container that matches the CPU architecture information from a container set that has been pre-stored with Docker middleware image containers; wherein, the container set is used to store: Docker middleware image containers created based on images of middleware modules developed for different CPU architectures.

[0073] Deployment unit 23 is used to deploy a Docker middleware image container that matches the CPU architecture information obtained by container acquisition unit 22 on the target computing device.

[0074] Compared to existing technologies that address port conflicts between middleware modules during deployment, the device provided in this application utilizes the sandbox mechanism of Docker containers, which eliminates the need to resolve port conflicts between middleware modules during deployment. This avoids the problem of maintenance personnel spending excessive time learning the different software code syntaxes used by different middleware modules, thus preventing long integration and testing cycles and slowing down the deployment process.

[0075] Optionally, the Docker middleware image container created based on images of middleware modules developed for different CPU architectures is generated in the following manner:

[0076] The middleware modules, developed for different CPU architectures, are distributed as JAR files using Spring Boot.

[0077] Based on the JAR file, a Docker middleware image container containing the JAR file is generated.

[0078] Optionally, the apparatus provided in this application embodiment may further include:

[0079] The deletion determination unit is used to determine whether the target Docker middleware image container can be deleted before upgrading the target Docker middleware image container deployed on the target computing device.

[0080] The deletion unit is used to delete the target Docker middleware image container if the determination result of the deletion determination unit is that it can be deleted, and to obtain the upgraded target Docker middleware image container and deploy it to the target computing device.

[0081] The container processing unit is configured to, if the deletion determination unit determines that deletion is not possible, obtain an upgraded JAR package corresponding to the target Docker middleware image container; use the upgraded JAR package to replace the JAR package deployed in the target computing device; and restart the target Docker middleware image container after the replacement is completed.

[0082] Optionally, the apparatus provided in this application embodiment may further include:

[0083] The restart command receiving unit is used to receive restart commands for the image of the middleware module to be restarted;

[0084] A container determination unit is used to determine, in response to the restart command, the Docker middleware image container corresponding to the image of the middleware module to be restarted;

[0085] The restart unit is used to perform a restart operation on the Docker middleware image container corresponding to the image of the middleware module to be restarted.

[0086] Example 3

[0087] Based on the same inventive concept as Embodiment 1 of this application, Embodiment 3 of this application provides a computing device to solve the problem that when there are port conflicts between middleware modules during the deployment of middleware modules, the existing solutions require maintenance personnel to invest a lot of effort in learning the software code syntax used by different middleware modules, which is time-consuming and laborious, resulting in a long middleware module integration and testing cycle and slowing down the deployment progress.

[0088] like Figure 3 As shown, the computing device includes a memory 31 and a processor 32. The memory 31 can be configured to store various other data to support operation on the electronic device. Examples of such data include instructions for any application or method used to operate on the electronic device. The memory 31 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0089] The processor 32, coupled to the memory 31, is used to execute the program stored in the memory 31 for executing a Docker-based module deployment method as described in Embodiment 1 of this application.

[0090] When the processor 32 executes the program in the memory 31, in addition to the functions mentioned above, it can also perform other functions, as detailed in the descriptions of the preceding embodiments.

[0091] Furthermore, such as Figure 3 As shown, the computing device also includes other components such as a display 34, a communication component 33, a power supply component 35, and an audio component 36. Figure 3 The diagram only shows some components and does not mean that the computing device includes only these components. Figure 3 The components shown.

[0092] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement the steps or functions of the methods provided in the above embodiments.

[0093] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0094] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0095] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A module deployment method based on Docker, characterized in that, include: Obtain information about the CPU architecture of the target computing device; The target computing device is equipped with a Docker server. Obtain a list of middleware modules pre-configured on the target computing device; Based on the CPU architecture information, Docker middleware image containers that match the CPU architecture information and the names of the middleware modules listed in the middleware module list are obtained from a pre-stored set of Docker middleware image containers; wherein, the container set is used to store: Docker middleware image containers created based on images of middleware modules developed for different CPU architectures. On the target computing device, a Docker middleware image container that matches the acquired CPU architecture information and the list of middleware modules is deployed.

2. The method as described in claim 1, characterized in that, The Docker middleware image container, created based on middleware modules developed for different CPU architectures, is generated in the following manner: The middleware modules, developed for different CPU architectures, are distributed as JAR files using Spring Boot. Based on the aforementioned JAR file, a Docker middleware image container containing the JAR file is created.

3. The method as described in claim 2, characterized in that, The method further includes: Before upgrading the target Docker middleware image container deployed on the target computing device, determine whether the target Docker middleware image container can be deleted; If it is determined that it can be deleted, then delete the target Docker middleware image container, obtain the upgraded target Docker middleware image container, and deploy it to the target computing device; If it is determined that it cannot be deleted, then obtain the upgraded JAR package corresponding to the target Docker middleware image container; use the upgraded JAR package to replace the JAR package in the target Docker middleware image container deployed in the target computing device; after the replacement is completed, restart the target Docker middleware image container.

4. The method as described in claim 1, characterized in that, The method further includes: Receive a restart command for the image of the middleware module to be restarted, which is deployed on the target computing device; In response to the restart command, the target computing device determines the Docker middleware image container corresponding to the image of the middleware module to be restarted; For the Docker middleware image container that corresponds to the image of the middleware module to be restarted, perform a restart operation.

5. A module deployment device based on Docker, characterized in that, The device includes: An architecture information acquisition unit is used to acquire information about the CPU architecture of the target computing device; the target computing device has a Docker server installed; and to acquire a list of middleware modules pre-configured on the target computing device. The container acquisition unit is used to acquire, based on the CPU architecture information, a Docker middleware image container that matches the CPU architecture information and the name of the middleware module listed in the middleware module list from a container set that has been pre-stored with Docker middleware image containers; wherein, the container set is used to store: Docker middleware image containers created based on images of middleware modules developed for different CPU architectures. The deployment unit is used to deploy, on the target computing device, a Docker middleware image container that matches the CPU architecture information and the list of middleware modules.

6. The apparatus as claimed in claim 5, characterized in that, The Docker middleware image container, created based on middleware modules developed for different CPU architectures, is generated in the following manner: The middleware modules, developed for different CPU architectures, are distributed as JAR files using Spring Boot. Based on the JAR file, a Docker middleware image container containing the JAR file is generated.

7. The apparatus as claimed in claim 6, characterized in that, The device further includes: The deletion determination unit is used to determine whether the target Docker middleware image container can be deleted before upgrading the target Docker middleware image container deployed on the target computing device. The deletion unit is used to delete the target Docker middleware image container if the determination result of the deletion determination unit is that it can be deleted, and to obtain the upgraded target Docker middleware image container and deploy it to the target computing device. The container processing unit is configured to, if the deletion determination unit determines that deletion is not possible, obtain an upgraded JAR package corresponding to the target Docker middleware image container; use the upgraded JAR package to replace the JAR package deployed in the target computing device; and restart the target Docker middleware image container after the replacement is completed.

8. The apparatus as claimed in claim 5, characterized in that, The device further includes: The restart command receiving unit is used to receive restart commands for the image of the middleware module to be restarted; A container determination unit is used to determine, in response to the restart command, the Docker middleware image container corresponding to the image of the middleware module to be restarted; The restart unit is used to perform a restart operation on the Docker middleware image container corresponding to the image of the middleware module to be restarted.

9. A computing device, characterized in that, include: Memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is configured to execute the program stored in the memory for performing the method according to any one of claims 1 to 4.

10. A computer-readable storage medium storing a computer program that, when executed by a computer, enables the implementation of the method described in any one of claims 1 to 4.

Images