A method and device for a virtual machine container of an application program

Abstract

A computer-implemented method for managing the execution of an application in a memory space of a multi-tenant virtual machine (MVM). The method includes instantiating a container for the application. The container has a thin client and a namespace, the namespace being a portion of the memory space of the MVM. A thread of the application is moved from the MVM to the container. The thread is executed in the namespace of the container using the thin client.

Description

Technical Field

[0001] The present disclosure relates to processing of an application by a virtual machine, and more particularly to running an application by using a container on a virtual machine. Background Art

[0002] Microservices are often used to develop online applications. Writing applications with microservices provides better application modularity and is easier to understand, develop, and test than writing applications with monolithic structured code. Using microservices to perform a small portion of the functionality of a larger application can simplify the development process because each microservice is much smaller than the entire application.

[0003] It is also possible to scale individual microservices dynamically. Microservices make it easy to upgrade and separate services and perform fault isolation. Summary of the invention

[0004] Various examples are now described to briefly introduce some concepts that are further described in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] One aspect of the present disclosure provides a computer-implemented method for managing the execution of an application in a memory space of a multi-tenant virtual machine (MVM). The method includes instantiating a container for an application. The container has a thin client and a namespace, the namespace being part of the memory space of the MVM. A thread of the application is moved from the MVM to the container. The thread is executed using the thin client in the namespace of the container.

[0006] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: before moving the thread to the container, starting a thread of a first application among the applications in the MVM.

[0007] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: the thin client obtains a container ID, and provides the container ID to the MVM.

[0008] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: executing the thread in the namespace of the first container includes processing input / output redirection between the MVM and the thin client.

[0009] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: the MVM exports the namespace of the container based on the container ID.

[0010] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: moving the startup thread includes moving the thread startup thread to the namespace of the container.

[0011] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: the MVM includes JAVAMVM, and moving the thread to the first container includes transferring an application jar file to the container.

[0012] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: using the MVM to instantiate a second container, the second container has a namespace, and the namespace is located in the memory space of the MVM; starting a second thread of a second application within the MVM; moving the second started thread to the second container; and executing the thread in the namespace of the second container.

[0013] Optionally, in any of the aforementioned aspects, another implementation method of the aspect includes: using the MVM to instantiate a third container, the third container has a namespace, and the namespace is located in the memory space of the MVM; starting a third thread of a third application within the MVM; moving the third started thread to the third container; and executing the third started thread in the namespace of the third container.

[0014] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: the application includes microservices that form the application.

[0015] One aspect of the present disclosure provides a device, comprising a memory and one or more processors, the memory comprising instructions, and the one or more processors communicating with the memory. The one or more processors execute the instructions to manage the execution of an application in a memory space of a multi-tenant virtual machine (MVM) by performing operations. The operations include instantiating a container for an application. The container has a thin client and a namespace, and the namespace is part of the memory space of the MVM. A thread of the application is moved from the MVM to the container. The thread is executed using the thin client in the namespace of the container.

[0016] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: before moving the thread to the container, starting a thread of a first application among the applications in the MVM.

[0017] Optionally, in any of the aforementioned aspects, another implementation method of the aspect includes: the thin client obtains a container ID and provides the container ID to the MVM; the MVM exports the namespace of the container based on the container ID; and executing the thread in the namespace of the first container includes processing input / output redirection between the MVM and the thin client.

[0018] Optionally, in any of the aforementioned aspects, another implementation method of the aspect includes: using the MVM to instantiate a second container, the second container has a namespace, and the namespace is located in the memory space of the MVM; starting a thread of a second application in the application within the MVM; moving the second started thread to the second container; and executing the thread in the namespace of the second container.

[0019] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: the MVM includes JAVAMVM, and moving the thread to the container includes transferring an application jar file to the container.

[0020] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: the application includes microservices that form the application.

[0021] One aspect of the present disclosure provides a non-transitory computer-readable medium storing computer instructions for managing the execution of an application in the memory space of a multi-tenant virtual machine (MVM). One or more processors may execute the instructions to perform operations including instantiating a container for an application. The container has a thin client and a namespace, which is part of the memory space of the MVM. A thread of the application is moved from the MVM to the container. The thread is executed using the thin client in the namespace of the container.

[0022] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: before moving the thread to the container, starting a thread of a first application among the applications within the MVM, wherein the thin client obtains a container ID and provides the container ID to the MVM, the MVM exports the container namespace based on the container ID, and executing the thread in the namespace of the first container includes processing input / output redirection between the MVM and the thin client.

[0023] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: using the MVM to instantiate a second container, the second container has a namespace, and the namespace is located in the memory space of the MVM; starting a second thread of a second application within the MVM; moving the second started thread to the second container; and executing the second started thread in the namespace of the second container.

[0024] Optionally, in any of the aforementioned aspects, another implementation of the aspect includes: the application includes microservices that form the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 A block diagram of a system for providing container capabilities for applications provided by an exemplary embodiment.

[0026] Figure 2 is a block diagram of an alternative view of a system for providing container capabilities to applications provided by an exemplary embodiment.

[0027] Figure 3 is a block diagram of several containers with application files provided by an exemplary embodiment.

[0028] Figure 4 A flowchart of a computer-implemented method corresponding to a workflow of a thin client within a container is provided by an exemplary embodiment.

[0029] Figure 5 A flowchart of a computer-implemented method for a workflow of a multi-tenant virtual machine (MVM) server in a host virtual machine is provided by an exemplary embodiment.

[0030] Figure 6 A flowchart of a computer-implemented method for managing execution of an application program in a memory space of an MVM is provided by an exemplary embodiment.

[0031] Figure 7is a block diagram of a circuit for executing multiple applications and an execution method in a container provided by an exemplary embodiment, wherein the container has a namespace in a memory space of an MVM. DETAILED DESCRIPTION

[0032] The following is a detailed description in conjunction with the accompanying drawings, which are part of the description and show, by way of illustration, specific embodiments in which the present invention may be implemented. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present invention, and it should be understood that other embodiments may be utilized and that structural, logical, and electrical changes may be made without departing from the scope of the present invention. Therefore, the exemplary embodiments described below are not intended to be limiting, and the scope of the present invention is defined by the appended claims.

[0033] In one embodiment, the functions or algorithms described herein can be implemented in software. The software may include computer executable instructions stored on a computer-readable medium or a computer-readable storage device (e.g., one or more non-transient memories or other types of hardware-based local or network storage devices). In addition, these functions correspond to modules, which can be software, hardware, firmware, or any combination thereof. Multiple functions can be performed in one or more modules as needed, and the described embodiments are merely examples. The software can be executed on a digital signal processor, an ASIC, a microprocessor, or other types of processors running on a computer system, such as a personal computer, a server, or other computer system, thereby converting such a computer system into a specially programmed machine.

[0034] An application written using a microservices-based architecture enables many separate functions of the application to be performed by different microservice applications. For example, in a web-based sales application, the login function can be performed by one microservice, the purchase function can be performed by another microservice, and the address check can be performed by another microservice. Decomposing an application into microservices makes the development of the application much simpler.

[0035] JAVA is a language that is often used to develop online business applications. Several frameworks have been developed to help build microservices-based systems in JAVA, such as Spring Cloud, Netflix / eureka, Huawei's internal CSE, and Apache ServiceComb, the open source version of Huawei's CSE.

[0036] A JAVA application is just one example of an application designed to run on a language virtual machine, such as a JAVA virtual machine (JVM). Applications written for other types of language virtual machines are within the scope of the subject matter of the present invention. A language VM is a virtual machine designed to execute a specific language.

[0037] JAVA applications typically use more processing resource memory because the JVM has a huge base. Each JAVA microservice instance is a JAVA process that requires a JVM, which includes components such as a class loader, a JAVA just in time compiler (JIT), and garbage collection (GC). As each microservice service is miniaturized, each microservice service is still an independent process in a container, and there is a JVM on top of the operating system running in the virtual machine. A container is a portable runtime environment running on a host or virtual machine. An application or process running in a container is packaged with all the required dependencies and configuration files. The application is given the illusion that no other processes are running outside its container. The ratio of the memory footprint of the JVM base part to the memory footprint of the application becomes larger. Therefore, JAVA microservice applications occupy more memory than equivalent monolithic applications.

[0038] The original solution to this problem is to merge the microservices back into the monolithic application, but this will result in the loss of all the benefits of using microservices. Another industry solution to this problem is to use a multi-tenant virtual machine (MVM), a multi-tenant JVM (such as Webcontainer Tomcat / Websphere, IBM J9MVM), which allows multiple applications to run on one JVM, thereby reducing memory usage. However, most JAVA microservice applications are currently deployed in containers. Existing MVMs cannot run applications in containers on top of MVMs. In addition, the source code of the microservices may need to be modified to avoid conflicts caused by mapping to the same resources (such as the same port).

[0039] In one embodiment, container capabilities are provided inside the JVM. Figure 11 is a block diagram of a system 100 that provides container capabilities for applications such as microservices. In one embodiment, the system 100 includes a machine 110, which can be a physical machine or a virtual machine executed on a suitable processing resource (such as a computer system, a server, or a cloud-based resource). An operating system 115 is executed on top of the virtual machine 110. In one embodiment, Linux OS can be used as the operating system 115. Other virtual machines 120 such as JVM (JAVA virtual machine) are executed on top of the operating system 115. For example, Oracle's production JVM can be used. Although various embodiments are described using JAVA-based applications, other operating environments and programming languages ​​for applications running on virtual machines can also be used in other embodiments.

[0040] The language VM 120 includes a memory space 122 in which application code, such as a microservice executed on the language VM 120, is operated. Example code includes garbage collection 125, JIT 130, other code 135, virtual machine service (VM SVC) thread 140, and application thread 145. In one embodiment, the application thread 145 includes a microservice. Microservices may be referred to as tenant applications, which constitute an application. A single application running on a language VM is generally not referred to as a tenant application, but multiple applications running on the same language VM are referred to as tenant applications. An application may include a complete application, and may also be used to refer to an application composed of multiple applications (such as microservices).

[0041] In order to execute the application thread 145, the container engine instantiates a container 150 as a container instance on the operating system 115. In one embodiment, the container engine is a Docker container engine that provides a lightweight Linux container. A language VM 155, such as a JVM, is created in the container 150, and an app file 160, such as an app jar file, and the application thread 145 are transferred to the container 150 (as shown by arrow 165) for execution.

[0042] The container 150 relies on the namespace capability of the operating system 115. A namespace is a set of symbols used to organize various types of objects so that they can be referenced by name. Example namespaces include file systems that assign names to files, programming languages ​​that organize variables and subroutines in namespaces, and computer networks and distributed systems that assign names to resources such as computers, printers, websites, and remote files. Each container instance has its own namespace 170 in the memory space 122 to create lightweight virtualization and isolation capabilities. After the container 150 is started, the application thread 145 is created in the language VM and moved to the namespace of the container 150. These threads will run the app file 160 within the container 150, and these threads can still work with the language VM service thread 140 in the language VM 120 because all threads are still in the same process memory space 122. jar (JAVA ARchive) is a JAVA package file format, which is usually used to aggregate multiple JAVA class files and related metadata and resources (text, images, etc.) into one file for distribution. The application file 160 is basically an application code, which is written in JAVA or other programming languages ​​running in the virtual machine in the container 150 .

[0043] In one embodiment, the system 100 transparently runs the application, such as a JAVA application, in the container 150 on top of the MVM, which saves memory and provides transparent deployment.

[0044] In one embodiment, an independent application (such as a JAVA application) can be composed of classes and instances in memory, and execution starts from the main() method of the defined main class. Since JAVA provides a class loader mechanism, the tenant class loader can be used to load the main class of the application, and all subsequent code is within the limits of the class loader, thereby achieving tenant code isolation. Other class loaders can be used for applications written in other languages.

[0045] Figure 2 is a block diagram of an alternative view of a system 200 that provides container capabilities for applications. Figure 2 Similar components in use with Figure 1The MVM server VM 210 runs GC 125, JIT 130, and code 135 in addition to running MVM server code 215, which starts application threads, moves the application threads into the namespace of container 220, and manages the application lifecycle. A plurality of applications 225 are shown associated with the MVM server language VM 210 and managed by the MVM server 215 to run in the container 220 in the MVM memory space using the namespace of the container 220.

[0046] The container 220 uses a thin client 230 (e.g., a JAVA thin client in one example) to run the application. The application developer will use the thin client 230 to start the application. All conventional parameters remain unchanged. The MVM server 215 moves the application thread 145 into the namespace of the container and runs the application, as shown by arrow 232. After the thin client 230 receives the parameters, the client 230 sends the parameters to the MVM server 215 via connection 233. In some embodiments, the container 220 may also contain other files 235 and other applications 240.

[0047] The MVM server will create the application thread 145, such as a JAVA application, and move the application thread 145 to the namespace of the container 220. Then, the application thread 145 can access the jar file 160 in the container 220, load the jar file 160, and start executing the "main()" function. Since all execution behaviors are in the namespace of the container 220, the started application can use one or more communication protocols (such as an inter-process communication protocol) to seamlessly interact with all resources / other applications in the container. In addition, since all threads are in the same memory space, threads can interact with each other. For example, the JIT 130 can still generate code for hot methods used by the application, and the GC 125 can still clean up the garbage generated by the application.

[0048] Figure 3300 is a block diagram of several containers with application files. Similar elements use the same reference numerals as in the previous figures. The MVM server 215 includes an MVM server manager 310, which manages the execution of multiple applications, represented as APP1 315 and APPN 320, by instantiating a separate container 325, 330 for each application. Each container 325, 330 instance has its own namespace, resulting in lightweight virtualization and isolation capabilities.

[0049] After starting the container (as shown by arrow 232), the application threads in the VM are moved to the namespace of the application containers 325, 330. These application threads will access the app jar files in the containers 325, 330 and work with the VM service threads in the MVM 210 because all threads are still in the same process memory space.

[0050] The MVM server 215 is executed on top of the MVM 210 and manages the life cycle of each application when the application is started. The MVM server creates a new tenant in response to the request of the thin client 230, moves the tenant's worker thread to the container instance namespace, and sets all OS-related resource configurations. For example, the standard input and output of the tenant are packaged and connected to the thin client in the container 325, 330. The packaging of input and output can be used to identify how to open or otherwise process the input and output. When a tenant exits, the MVM server 215 also performs resource cleanup.

[0051] Figure 4 is a flow chart of a computer-implemented method 400 corresponding to the workflow of a thin client 230 within a container. Figure 5 is a flow chart of a computer-implemented method 500 that illustrates the workflow of an MVM server 215 in a host virtual machine. Figure 4 and 5 The detailed workflow of the thin client 230 and the MVM server 215 and the interaction between each other are shown. The following description of the entire workflow will move back and forth between the thin client workflow method 400 and the MVM server workflow method 500, and the figure numbers begin with the figure number to help follow the flow between the described methods.

[0052] Method 400 begins by starting a container. For example, if a website that interacts with a user is started first, one or more containers may be instantiated. The thin client in the container parses application parameters, such as JAVA parameters, and obtains a container identifier (ID) in operation 410. In order for the MVM server to move the application thread to the namespace of the container, the thin client must tell the MVM server the container ID. However, there is no direct way to get the container ID from the container. In one embodiment, the container ID may be obtained by the thin client by reading the " / proc / self / cgroup" file. For example, a line in the file includes the container ID, which is the last part of the line in the file (shown in bold): 11:name=systemd: / docker / 6a9df72d484d618dfe95ad705b141ee1711dbb1c718676339e395cf0d5c87ba8

[0053] In operation 420 , the thin client connects to the MVM server 215 and sends the ID to the MVM server 215 .

[0054] Method 500 starts from 505 and starts the MVM server 215 with the specified communication port in operation 510. In operation 515, the MVM server 215 waits for connection until the port is connected and the ID is received from the thin client operation 420. In operation 520, the MVM server 215 parses the input parameters, class path, container ID and other information received. Then, in operation 525, the namespace of the container of the thin client is derived from the container ID. After the MVM server obtains the container ID, method 500 can query the process ID of the thin client in the host OS through the API of the container manager (such as the API of Docker). After receiving the process identifier (PID) of the thin client (such as a JAVA thin client), method 500 reads the " / proc / {PID} / ns / " file system of the host OS to obtain handles of different namespaces.

[0055] In operation 530, the MVM server manager 310 creates an application thread, such as a JAVA thread, moves the thread to the namespace of the container, and runs the application. In operation 535, corresponding to the life cycle of the application depicted by the dotted line 537, the application is run in the MVM server 215 and input / output redirection is processed. Accordingly, in operation 430, when running the application, the thin client 230 also processes input / output redirection. Both methods 400 and 500 check to determine whether the application is completed, check the exit signal in operation 440, and monitor whether the application is finished in operation 540. In a JAVA application, the thin client 230 can use print(f) to output data to the standard output of the computer. However, the application runs in the MVM server, so the default output is on the MVM server side. Therefore, the data needs to be redirected to the container. The input / output redirection operation 430 performs data exchange for output and input.

[0056] In method 400, if the exit signal is not received, more input / output redirection is processed in operation 430 before checking for an exit signal again in operation 440. After receiving the exit signal in operation 440, method 400 ends in 450.

[0057] After the method 400 ends, in operation 545 , the resources used by the application are cleaned up in the MVM 210 , and the MVM server manager 310 kills the application thread, indicating the end of the application life cycle, and ends in 550 .

[0058] In operation 555, the status of the MVM server 215 is checked. If the application is no longer running, the server method 500 ends in 560. Otherwise, processing continues in operation 515, waiting for further connections.

[0059] In the MVM server 215, after the server processes all parameters from the thin client, a single entry thread is created in operation 530 as the application management thread. In one embodiment, the OS's "unshare(CLONE_NEWNS|CLONE_NEWIPC|CLONE_NEWNET|CLONE_NEWUTS|CLONE_FILES)" interface is used to disconnect the thread from the VM process's namespace. The OS's "setns()" API is used to add threads to the container's net, uts, ipc, user, and mnt namespaces. After this, the application itself can create more threads from the management thread, all of which will inherit from the parent thread and be in the container's namespace.

[0060] In one embodiment, the thin client 230 is a small native application that resides in the container 325, 330. The thin client 230 is also named java so that the application can transparently replace vanilla JAVA with the thin client 230. The thin client 230 obtains command line parameters and performs a quick check. If the MVM server 215 does not support some parameters, such as JVMTI, the thin client 230 falls back to the original language VM within the container 325, 330. Otherwise, the thin client 230 connects to the MVM server 215 and sends the parameters to the MVM server 230 to start the application. After this, the thin client 230 forwards the thin client's stdin to the application's System.in and forwards the application's System.out and System.err to the thin client's stdout and stderr. The thin client 230 also hijacks OS signals sent to the thin client 230 and forwards the OS signals to the MVM server 215. If kill-9 kills the thin client 230, or the container 325, 330 is directly closed, the MVM server 215 regards it as a timeout and directly kills the application.

[0061] The communication between the thin client 230 and the MVM server 215 is performed via a network socket. Since the thin client 230 and the MVM server 215 are located in the same host OS 115, interprocess communication (IPC) or the like may also be used for optimization.

[0062] This embodiment can eliminate the need to manually change the code required by existing solutions, such as merging applications such as microservices into a single program, where port mapping may be problematic due to port mapping conflicts unless the ports are changed by modifying the microservice code. Some existing solutions create a problem in that applications outside the container cannot interact with other resources or applications within the container.

[0063] Various embodiments of the inventive subject matter run the application within the container transparently into a multi-tenant VM, allowing the container to interact with other applications and the file system or other IO resources in the same container.

[0064] The use of application containers in the MVM system can also be applied to MVMs of other languages, such as JAVAScript, Go, Python, etc. This approach also allows applications to run transparently in containers on top of the MVM in the host.

[0065] Figure 6 6 is a flow chart of a computer-implemented method 600 for managing the execution of an application in a memory space of an MVM. The application may include one or more microservices of the application. The method 600 begins by instantiating a container for the application in operation 610. The container includes a thin client and has a namespace, which is part of the memory space of the MVM. In operation 620, if not already started, the method 600 starts a thread of a first application in the application within the MVM. Then, in operation 630, the startup thread of the application is moved from the MVM to the container. Moving the first thread startup thread includes moving the first thread startup thread to the namespace of the first container. Then, in operation 640, the moved thread is executed using the thin client in the namespace of the container. Input and output redirection between the MVM and the thin client is processed.

[0066] In one embodiment, the container of the start thread is unknown, the thin client obtains a container ID, and provides the container ID to the MVM. The MVM can deduce the namespace of the container based on the container ID.

[0067] In one embodiment, the MVM comprises a JAVA MVM.Transferring the first thread launcher thread to the first container comprises transferring an app jar file to the first container.

[0068] Multiple other applications can be processed by instantiating other containers using the MVM, each container having a namespace located in the memory space of the MVM. Threads of the other applications can be started within the MVM and transferred to the namespaces of other containers for execution.

[0069] Figure 7 is a block diagram of a circuit for executing multiple applications and execution methods in a container provided by an exemplary embodiment, wherein the container has a namespace in the memory space of an MVM. Not all components need to be used in various embodiments.

[0070] An exemplary computing device in the form of a computer 700 may include a processing unit 702, a memory 703, a removable memory 710, and a non-removable memory 712. Although the exemplary computing device is illustrated and described as a computer 700, the computing device may have different forms in different embodiments. For example, the computing device may be a smartphone, a tablet computer, a smart watch, or other computing device that includes a processor that combines Figure 7 The same or similar elements shown and described. Devices such as smartphones, tablets, and smart watches are generally referred to as mobile devices or user devices. In addition, although various data storage elements are described as part of the computer 700, the memory can also include or alternatively include cloud-based storage accessible via a network (e.g., the Internet or server-based storage).

[0071] The memory 703 may include a volatile memory 714 and a non-volatile memory 708. The computer 700 may include or have access to a computing environment that includes various computer-readable media, such as a computing environment that includes the volatile memory 714, the non-volatile memory 708, the removable memory 710, and the non-removable memory 712. Computer storage includes random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD ROM), digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium capable of storing computer-readable instructions.

[0072] The computer 700 may include or have access to a computing environment including an input interface 706, an output interface 704, and a communication interface 716. The output interface 704 may include a display device, such as a touch screen, which may also be used as an input device. The input interface 706 may include one or more of the following: a touch screen, a touch pad, a mouse, a keyboard, a camera, one or more device-specific buttons, one or more sensors integrated into the computer 700 or coupled to the computer 700 via a wired or wireless data connection, and other input devices.

[0073] The computer can be operated in a network environment using a communication connection to connect to one or more remote computers, such as a database server. The remote computer may include a personal computer (PC), a server, a router, a network PC, a peer device, or other common DFD network switches, etc. The communication connection may include a local area network (LAN), a wide area network (WAN), a cellular network, Wi-Fi, Bluetooth, or other networks. According to one embodiment, the various components of the computer 700 are connected to a system bus 720.

[0074] Computer readable instructions (e.g., program 718) stored on a computer readable medium can be executed by a processing unit 702 of a computer 700. In some embodiments, the program 718 includes software that, when executed by the processing unit 702, performs methods and algorithms associated with executing an application in a container according to any of the embodiments included herein. Hard drives, CD-ROMs, and RAM are some examples of products that include non-transitory computer readable media (e.g., storage devices). The terms computer readable media and storage devices do not include carrier waves because carrier waves are too short-lived. Storage can also include networked storage, such as a storage area network (SAN). The computer program 718 can be used to cause the processing unit 702 to perform one or more methods or algorithms described herein.

[0075] In an exemplary embodiment, the computer 700 includes a container module that instantiates a container for an application, the container having a thin client and having a namespace that is part of the memory space of the MVM; a thread movement module moves the thread of the application from the MVM to the container, and an execution module executes the thread in the namespace of the container using the thin client. In some embodiments, the computer 700 may include other modules or additional modules for performing any step or combination of steps described in the embodiments. In addition, any additional or alternative embodiments or aspects of the method (as shown in any figure or described in any claim) also contemplate including similar modules.

[0076] Although several embodiments are described in detail above, other modifications are possible. For example, the logic flow described in the figure does not require the specific order or sequential order shown to achieve the desired result. Other steps in the described flow can be provided or eliminated, and other components can be added or removed from the described system. Other embodiments may be within the scope of the appended claims.

Claims

1. A computer-implemented method for managing the execution of an application in the memory space of a multi-tenant virtual machine (MVM), characterized in that: The method comprises: Instantiating a container for an application, the container having a thin client and a namespace, the namespace being part of the memory space of the MVM; Creating a thread for the application through the MVM; Moving the thread from the MVM to the container; The thread is executed using the thin client in the namespace of the container, wherein the thread and the service thread are executed on the MVM.

2. The method according to claim 1, characterized in that Also includes: Before moving the thread to the container, starting the thread of the application within the MVM.

3. The method according to any one of claims 1 to 2, characterized in that The thin client obtains a container ID and provides the container ID to the MVM.

4. The method according to claim 3, characterized in that Executing the thread in the namespace of the container includes handling input / output redirection between the MVM and the thin client.

5. The method according to claim 3, characterized in that: The MVM derives the namespace of the container based on the container ID.

6. The method according to claim 5, characterized in that Moving the thread includes moving the thread to the namespace of the container.

7. The method according to any one of claims 1 to 5, characterized in that The MVM includes a JAVA MVM, and moving the thread to the container includes transferring an application jar file to the container.

8. The method according to any one of claims 1 to 5, characterized in that Also includes: Instantiate a second container using the MVM, where the second container has a namespace, and the namespace is located in the memory space of the MVM; Starting a second thread of a second application in the MVM; moving the second thread to the second container; The second thread is executed in the namespace of the second container.

9. The method according to claim 8, characterized in that Also includes: Instantiate a third container using the MVM, where the third container has a namespace, and the namespace is located in the memory space of the MVM; Starting a third thread of a third application in the MVM; moving the third thread to the third container; The third thread is executed in the namespace of the third container.

10. The method according to any one of claims 1 to 5, characterized in that The application includes microservices that form the application.

11. A computer-implemented device for managing the execution of applications in the memory space of a multi-tenant virtual machine (MVM), characterized in that include: a memory, the memory comprising instructions; One or more processors, the one or more processors in communication with the memory, the one or more processors executing the instructions to manage the execution of an application in a memory space of a multi-tenant virtual machine (MVM) by performing the following operations, the operations comprising: Instantiating a container for an application, the container having a thin client and a namespace, the namespace being part of the memory space of the MVM; Creating a thread for the application through the MVM; Moving the thread of the application from the MVM to the container; The thread is executed using the thin client in the namespace of the container, wherein the thread and the service thread are executed on the MVM.

12. The device according to claim 11, characterized in that Also includes: Before moving the thread to the container, starting a thread of a first one of the applications within the MVM.

13. The device according to any one of claims 11 to 12, characterized in that The thin client obtains a container ID and provides the container ID to the MVM, the MVM derives the namespace of the container based on the container ID, and executing the thread in the namespace of the first container includes processing input / output redirection between the MVM and the thin client.

14. The device according to any one of claims 11 to 12, characterized in that Also includes: Instantiate a second container using the MVM, where the second container has a namespace, and the namespace is located in the memory space of the MVM; Start a second thread in the application program within the MVM; moving the second thread to the second container; The thread is executed in the namespace of the second container.

15. The device according to any one of claims 11 to 12, characterized in that The MVM includes a JAVA MVM, and moving the thread to the container includes transferring an application jar file to the container.

16. The device according to any one of claims 11 to 12, characterized in that The application includes microservices that form the application.

17. A non-transitory computer readable medium storing computer instructions, characterized in that: The computer instructions are used to manage the execution of an application in the memory space of a multi-tenant virtual machine (MVM). When one or more processors execute the computer instructions, the one or more processors perform the following operations, including: Instantiating a container for an application, the container having a thin client and a namespace, the namespace being part of the memory space of the MVM; Creating a thread for the application through the MVM; Moving the thread of the application from the MVM to the container; The thread is executed using the thin client in the namespace of the container, wherein the thread and the service thread are executed on the MVM.

18. The medium according to claim 17, characterized in that Also includes: Before moving the thread to the container, starting a first thread in the application within the MVM, wherein the thin client obtains a container ID and provides the container ID to the MVM, the MVM derives the container namespace based on the container ID, and executing the thread in the namespace of the first container includes handling input / output redirection between the MVM and the thin client.

19. The medium according to claim 17, characterized in that Also includes: Instantiate a second container using the MVM, where the second container has a namespace, and the namespace is located in the memory space of the MVM; Starting a second thread of a second application in the MVM; moving the second thread to the second container; The second thread is executed in the namespace of the second container.

20. The medium according to claim 17, characterized in that The application includes microservices that form the application.

Images