USING VIRTUAL MACHINE CONTAINERS IN A VIRTUALIZED COMPUTING PLATFORM

[0001] Recently, the use of application containers has become prevalent as a way of executing applications on a host computer. A container provides for the isolation of a group of processes from the others on an operating system. By making use of existing operating system functionality (such as Linux name spaces), containers maintain their own private view of the operating system, file system structure, and network interfaces. Containers share the operating system kernel with other processes, but can be constrained to some extent to use an amount of resources such as the central processing unit (CPU), random access memory (RAM), or input/output (I/O) devices. Containers have proven advantageous because they typically have a small system “footprint.” That is, containers provide a relatively thin encapsulation layer above and beyond any applications contained therein. Thus, instantiation and deployment of containers is relatively quick.

[0002] Virtual machines, on the other hand, tend to deploy more slowly than containers. This is due to the fact that virtual machines are a software abstraction of a physical computer. Thus, a virtual machine typically includes a guest operating system and a virtual hardware platform. These virtualized system components are not present in containers.

[0003] However, virtual machines are advantageous because a higher degree of isolation and security may be achieved between virtual machines as opposed to the degree of isolation that may be achieved between containers. This is due to the filet that containers run on the same kernel; thus problems from one container may “infect” other containers. In addition, while containers may be configured to use a certain amount of system resources, it is possible for a malicious application executing in a container to circumvent such restrictions and monopolize CPU, storage, or I/O resources, By contrast, virtual machines allow system administrators to separately configure each virtual machine in a cloud environment to receive a predefined allocation of system resources. For example, in some cases, a virtual machine may be configured to receive a guaranteed minimum allocation of CPU resources. In other cases, a virtual machine may be configured to receive a constant relative share of available CPU resources. This isolation and security provided by virtual machines is especially important in multi-tenant cloud-based computing environments.

[0004] Further, because the application programming interface (API) that a hypervisor uses to execute a virtual machine is more limited than the API of a general purpose kernel operating system, virtual machines tend to have a smaller attack surface than a shared kernel. Thus, it is generally more difficult to compromise a virtual machine executing under control of a hypervisor than it is to compromise a container running under the control of a shared kernel. Further, even if a virtual machine is compromised, superior isolation of virtual machines prevents the compromised virtual machine from affecting other virtual machines. Finally, there exists a rich set of management tools directed to virtual machine environments that is lacking in containerized environments.

[0005] Therefore, cloud-based computing environments are often faced with a choice between rapidly deployable, but weakly isolated and unsecure, containers, and strongly isolated and highly secure, but slowly deployed, virtual machines.

[0006] In a first embodiment, a method of creating a hierarchy of virtual machine templates in a virtualized computing system is provided, the virtualized computing system supporting the execution of a plurality of virtual machines, and each virtual machine supporting the execution of one or more applications therein. Each application executes within a container that isolates the application executing therein from other processes executing on the virtualized computing system. The method comprises the steps of instantiating a first parent virtual machine template having a guest operating system and a first container, and determining a first application to be run in a container. The method further comprises the steps of forking the first parent virtual machine template to create a first child virtual machine template, the child template virtual machine including a replica of the first container, wherein the guest operating system of the first parent virtual machine template is mapped to a memory location that overlaps with a memory location of a guest operating system of the first child virtual machine template. The method further comprises the step of installing the first application in the replica of the first container.

[0007] A second embodiment provides a non-transitory computer-readable medium that includes instructions that, when executed, enable a host computer to implement one or more aspects of the above method.

[0008] In a third embodiment, a method of deploying containerized applications for execution within virtual machines is provided, the virtual machines executing in a virtualized computing system, each virtual machine supporting the execution of one or more containerized applications therein, and each application executing within a container that isolates the application executing therein from other processes executing on the virtualized computing system. The method comprises the steps of receiving from a requestor a request to execute an application and locating a first virtual machine template that includes a container configured to execute the application. The method further includes the steps of forking the first virtual machine template to create a first child virtual machine that includes a replica of the container, and launching the application to execute within the first child virtual machine.

[0014] FIG. 1 is a conceptual diagram that depicts a process of forking a parent VM order to create a child VM, according to embodiments. VM 110₁ is a parent VM, while VM 110₂ is the child VM created from VM 110₁. The fork operation is depicted, conceptually, by arrow 130. Each VM (both parent and child) executes guest operating systems (OS′), a container daemon, and one or more containers. Further, each VM executes under control of a hypervisor in a host computer (not shown).

[0015] As shown in FIG. 1, VM 110₁ executes a guest operating system (OS) 111. Guest OS 111 is an operating system capable of being executed in a virtualized computing environment, and which supports application containers (described in more detail below). Examples of guest OS 111 include, for example, versions of the Linux® operating system.

[0016] When guest OS 111 executes within VM 110₁, portions of the operating system code and associated data are allocated memory pages in system random access memory, or RAM (depicted as RAM 140 in FIG. 1). Conceptually, the allocation of RAM to guest OS 111 may be depicted as a segment of RAM. Thus, guest OS 111 is depicted as being allocated segment 141₁ in FIG. 1, should be noted that the allocation of physical memory for guest OS 111 is not necessarily a contiguous range of physical memory addresses. Rather, the depiction of segment 141₁ as a contiguous block of memory is for illustrative purposes. In embodiments, instructions and data for guest OS 111 are loaded into RAM 140 (typically through execution of a hypervisor (not shown) configured to manage the execution of virtual machines), where the instructions and data are fetched from segment 141₁ to be executed on a central processing unit (CPU) when VM 110₁ is allocated processing time on the CPU.

[0017] VM 110₁ also executes container daemon 112. Container daemon 112 (which runs as a virtualized application under the control of guest OS 111) is a process that enables the creation, deletion, and management of container objects (or “containers”) for VM 110₁. Containers are software instances that enable virtualization at the operating system level. That is, with containerization, the kernel of an operating system that manages a host computer is configured to provide multiple isolated user space instances. These instances, referred to as containers, appear as unique servers from the standpoint of an end user that communicates with the containers. However, from the standpoint of the operating system that manages the host computer on which the containers execute, the containers are user processes that are scheduled and dispatched by the operating system.

[0018] According to one or more embodiments, container daemon 112 communicates with local (or remote) processes according to a client/server model. For example, a client process (e.g., a system administration process) may transmit a request to container daemon 112 to instantiate a new container or to install a new application in an already existing container. Further, another client process may transmit a request to container daemon 112 to quiesce or destroy a container.

[0019] As was the case for guest OS 111, program instructions that correspond to container daemon 112 are loaded, after translation of virtual addresses to physical addresses, into RAM 140 and subsequently executed from RAM 140. As shown in FIG. 1, container daemon 112 is allocated segment 141₂ in RAM 140. Segment 141₂ is depicted as a contiguous block of physical RAM. However, the depiction is for illustrative purposes. That is, instructions and data corresponding to container daemon 112 may be loaded into non-contiguous portions of RAM 140.

[0020] It should be noted that container daemon executes as a part of VM 110₁, and runs, in a virtualized manner, under the control of guest OS 111. Thus, container daemon 112 executes system calls and requests operating system services and VM resources from guest OS 111. Guest OS 111 allocates virtual resources to container daemon 112, which correspond to physical computing resources (such as physical memory in RAM 140). The physical resources are allocated by a hypervisor that manages the execution of VM 110₁, as well as all other virtual machines executing within the particular host computer on which VM 110₁ runs.

[0021] Referring to FIG. 1, VM 110₁ also includes a container that executes therein, depicted as container 113₁. Container 113₁ is instantiated on VM 110₁ by container daemon 112. An instantiated container executes in a state where an application may be installed therein. Container 113₁ also executes under the control of guest OS 111. As shown, instructions and data corresponding to container 113₁ (which executes in a virtual address space) are loaded into segment 141₃ of physical RAM 140.

[0022] As previously mentioned, fork operation 130 creates a child VM (i.e., VM 110₂) based on parent VM 110₁. In embodiments, a system administrator initiates fork operation 130 using a system management software platform. In other embodiments, fork operation 130 is initiated automatically by system management software upon detection of a condition on the host computer on which the VMs execute. In addition, the parent VM may itself initiate fork operation 130. The forking of a VM is similar in spirit to the forking of a process, such as performed by the fork( ) system call in the Unix operating system. When a parent VM issues a fork call, one or more clones of the parent VM (referred to as child VMs) are created. Each child VM replicates all of the running processes and threads executing in the parent VM and executes on the same host computer that the parent VM executes on. When a child VM is created, the child VM has an identical view of the host computer on which the parent VM is running. Indeed, once a child VM is created as a result of a fork operation executed by a parent VM, the child VM starts executing at the instruction that immediately follows the fork operation executed in the parent. Each child VM has a different (and unique) identifier, which allows each to be distinguished from the other child VMs and from the parent. Each child VM executes independent of the parent VM and from other child VMs.

[0023] At the time a child VM is created, the memory image of the child VM (i.e., the instructions and data stored in RAM 140) maps to the same memory locations in RAM 140 as the memory image of the parent VM. Indeed, the VM fork operation results in the creation of a stateful clone of the parent VM, meaning that, at the time of the VM fork operation, the current state of the child VM (including the memory state of the child VM) is the same as that of the parent VM. However, as a child VM begins to execute and attempt to modify the memory pages that are shared with the parent VM, those memory pages are first copied to a different region of memory (e.g., RAM 140), the child VM's virtual memory is then altered to map to the copied pages, and the copied pages are then modified by the child VM. Such a scheme is referred to as “copy-on-write” (COW). Embodiments of the present invention implement a COW scheme, such that the memory state of the parent VM is not disturbed by memory writes issued by corresponding child VMs.

[0024] Thus, as shown in FIG. 1, when VM 110₂ is created by forking operation 130, the guest OS executing in VM 110₂ (denoted also by guest OS 111) maps to segment 141₁ of RAM 140, which is the same segment of RAM 140 that guest OS 111 of VM 110₁ maps to. Similarly, container daemon 112 executing in VM 110₂ maps to segment 141₂ of RAM 140, which is the same segment of RAM 140 that container daemon 112 that is executing in VM 110₁ maps to.

[0025] At the time that VM 110₂ is created by forking process 130, VM 110₂ includes container 113₂, which maps to the same physical memory location (i.e., segment 141₃) as does container 113₁ executing in VM 110₁. It should be noted that container 113₁ is an “empty” container, which does not have any applications installed therein. However, once an application is installed in a container (e.g., by a system administrator), the memory image of the container changes (i.e., the container grows in size and the data stored therein changes) because additional application instructions and data are stored with the container. Thus, as shown in FIG. 1, application 120 is depicted as having been installed into container 113₂ of VM 110₂. Due to the COW semantics reined to above, once application 120 is installed in container 1132, container 113₂ no longer maps to segment 141₃. This is due to the fact that, when application 1120 is installed, segment 141₃ is insufficient to support the increased memory required to execute application 120 within container 113₂. Further, because application installation changes the memory to which container 113₂ is mapped, COW requires container 113₂ to be mapped to a different memory segment. Thus, in order to accommodate the increased memory needs of application container 113₂, guest OS 111 allocates additional virtual memory for application container 113₂, which is mapped (by a hypervisor that manages physical RAM for VM 110₂) to segment 141₄ of RAM 140. Although segment 141₄ is depicted as being completely separate from segment 141₃, it should be noted that the two segments may in fact partially overlap. That is, some instructions and data pertaining to container 113₁ may also remain unchanged as a result of the execution of application container 113₂. Thus, the portion of RAM 140 that corresponds to these instructions and data may he shared by VMs 110₁ and 110₂. In such a case, only the additional instructions and data for application 120 (and any container data that application 120 changes as a result of executing) would be located in a portion of RAM 140 that does not overlap with segment 141₃.

[0026] Containerized applications that run within virtual machines provide a number of benefits. Application containers have the benefit of being lightweight and having low startup times. In addition, application containers are able to execute under the direct control of a native operating system or a guest operating system of a virtual machine. However, application containers do not provide the same level of isolation as do virtual machines, which is important in multi-tenant cloud-based computing environments. Further, containers are difficult, if not impossible, to manage using existing virtual machine management and monitoring tools. On the other hand, virtual machines (which each include a guest operating system executing therein) tend to have larger memory footprints and higher startup times. Thus, containerized applications executing within virtual machines that have low startup times are advantageous.

[0027] FIG. 2 is a conceptual diagram depicting the creation of a hierarchy of template VMs, each of which may be forked to create a child VM in which a containerized application executes. As shown, a system administrator uses management server 200 to create the hierarchy (which is referred to in the figure as VM templates 270). Management server 200 comprises management software that may execute on a desktop or server-class computer, a laptop or notebook computer, or as a smartphone application. Management server 200 creates and updates VM templates 270 over a local or wide area network, a wireless network, or via a direct connection to a host computer on which the virtual machines in VM templates 270 execute. It should be noted that the virtual machines that comprise VM templates 270 may execute on a common host computer, or may be distributed among several host computers.

[0028] As shown in FIG. 2, management server 200 coordinates the creation of VMs and the addition of the created VMs to VM templates 270. Management server 200 creates a base VM (depicted as VM 110_A), which includes a guest OS 111 (similar to guest OS 111 in FIG. 1). According to embodiments, guest OS 111 is capable of executing in a virtual machine (i.e., under the control of a hypervisor) and is capable of supporting execution of application containers. When management server 200 creates VM 110_A, management server 200 records information about VM 110_A in a registry 260. Registry 260 is a database that stores information pertaining to virtual machines, such as virtual machine identifiers, network addresses (e.g., media access control (MAC) addresses and Internet Protocol (IP) addresses), as well as identifiers of application containers that the virtual machines execute. In one or more embodiments, this information enables an application server (described below), in response to an application request, to locate an appropriate template VM in the hierarchy, and to create a child VM based on the template that is responsive to the needs of the application requestor.

[0029] Management server 200 instructs VM 110_A to perform a VM fork operation (similar to fork operation 130 in FIG. 1), in order to create VM 110_B, immediately after the fork, VM 110_B includes guest OS 111 (which is shared with VM 110_A). After creation, management server 200 instantiates a container 113_B in VM 110_B, which runs under the control of guest OS 111. It should be noted that container 113_B does not contain any applications. Management server 200 then registers VM 110_B in registry 260.

[0030] Management server 200 then continues creating VM templates 270 by instructing VM 110_B to perform two fork operations in order to create VMs 110_C and 110_D, respectively. At the time of creation, both VMs 110_C and 110_D are exact copies of VM 110_B. That is, both VMs 110_C and 110_D have the same state as VM 110_B, execute all of the same processes as VM 110_B, and include a container that shares the same memory location as container 113_B. However, as shown in FIG. 2, management server 200 installs application 120_C into the container of VM 110_C. This container is referred. to as container 113_C because container 113_C (after installation of application 120_C) no longer shares the same state (including memory location) as that of container 113_B of VM 110_B. Similarly, management server 200 installs application 120_D into the container of VM 110_D, which is referred to as container 113_D in FIG. 2. After creating both VMs 110_C and 110_D, management server 200 registers both VMs in registry 260.

[0031] It should be noted that VMs 110_A-D each shares (from a memory standpoint) the same guest OS 111. However, each of containers 113_B-D is stored in a different part of system RAM (such as RAM 140 in FIG. 1).

[0032] Although it is often advantageous to execute a single application container within a virtual machine, it is, at times, desirable to have more than one application container execute in a virtual machine. This is especially true when the applications need to communicate with each other with minimal latency. Thus, continuing with the creation of the hierarchy represented by VM templates 270, management server 200 instructs VM 110_C to perform fork operations to create VMs 110_E and 110_F. Immediately after each of VMs 110_E and 110_F is created, these VMs are exact copies of VM 110_C. Thus, each of these VMs includes guest OS 111 and container 113_C, with application 120_C executing therein. However, as shown in the figure, management server 200 proceeds to instantiate container 113_E on VM 110_E and container 113_F on VM 110_F. Moreover, management server 200 installs application 120_E in container 113_E and application 120_F in container 113_F. Management server 200 also registers both Wills 110_E and 110_F in registry 260.

[0033] It should be noted that container 113_C in VM 110_E and container 113_C in VM 110_F are identical in terms of memory state at the time each of these VMs is created as a result of the forking of VM 110_C. However, VMs 110_E and 110_F are independent virtual machines. This means that, should either virtual machine execute application 120_C, then the respective containers would cease to be exact replicas of container 113_C of parent VM 110_C. This results in unintended memory usage, as additional memory would be required by each of the independently executing application containers of VMs 110_E and 110_F. Indeed, this holds true for any of the applications, containers, and guest OS of any child VM. Thus, in order to avoid containers, applications, and any operating system software in a child VM from changing from any corresponding software in a parent VM, management server 200 stalls the execution each of the virtual machines in VM templates 270, once that virtual machine has been created by a forking operation, and once a container (or application) has been installed on the virtual machine. Thus, referring to FIG. 2, once management server 200 completes creating each of VMs 110_A-F, and completes instantiating on child VMs new containers and installing applications into those newly instantiated containers, management server 200 stalls execution of each of the VMs in VM templates 270 to ensure that the underlying state (including the memory state) of each VM is preserved.

[0034] Therefore, once management server 200 finishes creating VMs in VM templates 270, each of VMs 110_C, 110_E, and 110_F has a “warmed up” application container 113_C (i.e., an application container that, upon being deployed in a forked virtual machine, is immediately executable). Further, VM 110_D has a warmed up application container 113_D, VM 110_E has a warmed up application container 113_E, and VM 110_F has a warmed up application container 113_F. Further, each of VMs 110_C, 110_E, and 110_F is registered as having executing therein the aforementioned containers as illustrated in FIG. 2.

[0035] FIG. 3 is a conceptual diagram depicting an application server receiving application requests and, in response, creating child VMs by forking corresponding parent VMs, according to one or more embodiments. VM templates 270 are based on the hierarchy created by management server 200, which is illustrated in FIG. 2.

[0036] As shown in the figure, three application requestors (requestors 300_1-3) generate application requests and transmit those requests to application server 310. Requestors 300_1-3 may he client processes that require performance of discrete transactions by a remote application (such as, for example, a database query). In such a case, requestors 300_1-3 transmit requests to application server 310. Application server 310 creates one or more virtual machines (by instructing a template virtual machine to perform a fork operation). The forked virtual machines execute to service the request, and application server returns results (either synchronously or asynchronously) to the requestor 300 whose request has been serviced.

[0037] In other cases, requestors 300_1-3 may require continuing access to a newly created containerized application. In such cases, application server 310 instructs a template virtual machine to perform a fork operation, and then, after the virtual machine is forked, application server 310 returns a handle to the forked virtual machine to the requestor 300. This enables the requestor 300 to interact with the forked virtual machine on a continuing basis.

[0038] In still other cases, any of requestors 300_1-3 may have an application that requires execution in an application container. In such a case, the requestor 300 invokes application server 310 and passes a copy of the application or a pointer to the application to application server 310, or, alternatively, specifies the name of the application as a parameter that is passed to application server 310. In such a case, application server 310 forks a containerized VM template that executes in VM templates 270. Application server 310 then installs the application passed from the requestor 300 into a container executing within the forked VM and launches the application. Other patterns for invoking application server 310 are possible and within the scope of the present disclosure.

[0039] For example, referring to FIG. 3, requestor 300₁ transmits an application request to application server 310. The request of requestor 300₁ includes an application that requestor 300₁ requires to be executed in a container in a virtual machine. In response to receiving the request from requestor 300₁, application server 310 performs a lookup function in registry 260 in order to locate a VM template that includes a container into which the application may be installed (i.e., an “empty” container). Application server 310 locates VM 110_B, because VM 110_B includes empty container 113_B. Application server 310 then instructs VM 110_B to perform a fork operation, which creates VM 110₁ . Upon creation of VM 110₁, the VM includes guest OS 111 and container 113_B. Application server 310 then installs application 120₁ (which is the application that requestor 300₁ passes to application server 310) into container 113_B of VM 110₁. Once application 120₁ is installed in container 113_B, in one or more embodiments, application 120₁ is launched. In addition, according to embodiments, application server 310 transmits a handle to VM 110 back to requestor 300₁, which enables requestor 300₁ to interact with VM 110₁.

[0040] Still referring to FIG. 3, requestor 300₃ transmits a second application request to application server 310. The request transmitted by requestor 300₃ does not include a copy of (or a pointer to) an application. Rather the request transmitted by requestor 300₃ indicates application 120_C, and, optionally, includes parameters to be passed to that application. In response to receiving the request from requestor 300₃, application server 310 locates (in registry 260) VM 110_C as a template virtual machine that executes a container that includes application 120_C. Therefore, application server 310 instructs VM 110_C to perform a fork operation. This results in the creation of VM 110₂, which, as shown, includes container 113_C, which, itself, contains application 120_C. After creation of VM 110₂, containerized application 120_C is launched, parameters (if required) are passed to application 120_C, and results from application 120_C are returned to requestor 300₃. In other embodiments, once VM 110₂ is created by the fork operation, application server 310 returns a handle to the forked VM to requestor 300₃.

[0041] Still referring to FIG. 3, requestor 300₃ transmits a third application request to application server 310. The request transmitted by requestor 300₃ indicates that requestor 300₃ requires access to two applications (namely, applications 120_C and 120_F), each of which executes in a separate container. In response to the request from requestor 300₃, application server 310 locates VM 110_F in registry 260 because VM 110_F includes containers 113_C and 113_F, each of which includes, respectively, application 120_C and 120_F. Application server 310 then instructs VM 110_F to perform a fork operation to create VM 110₃. As shown, VM 110₃ includes container 113_C (which executes application 120_C) and container 113_F (which executes application 120_F). After creation of VM 110₃, application server 310 launches containerized applications 120_C and 120_F, passes parameters (if required) to the applications, and returns any results generated by the launched applications to requestor 300₃. In other embodiments, once VM 110₃ is created by the fork operation, application server 310 returns a handle to the forked VM to requestor 300₃, which enables requestor 300₃ to communicate with containerized applications 120_C and 120_F on an ongoing basis.

[0042] It bears mentioning that, when each of VMs 110_1-3 is created by a corresponding fork operation, each of the VMs is an exact replica (i.e., has identical state) as its parent VM (i.e., VM 110_B, 110_C, and 110_F, respectively). However, after applications are installed or launched in each of the forked VMs, the states of the child and parent VMs become different and each child VM executes independent of the corresponding parent VM.

[0043] FIG. 4 is a flow diagram that depicts a method 400 for creating a hierarchy of VM templates, where each VM template may be forked to create a child VM configured to execute one or more containerized applications. Method 400 is performed by management software executed in response to requests from a system administrator. An example of such an administrative software platform is shown in FIG. 2 as management server 200.

[0044] Method 400 begins at step 405, where management server 200 instantiates a parent VM on a host computer. The parent VM includes a. guest OS, where the guest OS is capable of executing one or more application containers. An example of such a parent VM is VM 110_A, depicted in FIG. 2.

[0045] Once the parent VM is instantiated, method 400 proceeds to step 410. At step 410, management server 200 instructs the parent VM to perform a forking operation to create a child VM, where, after forking, management server 200 starts a container daemon on the child VM and instantiates an empty application container on the child VM. The child VM created at step 410 is referred to as a container VM template. An example of a container VM template is VM 110_B, depicted in FIG. 2.

[0046] After the parent VM and container VM template are created at steps 405 and 410, management server 200 registers both the parent VM and container VM template at step 415. As previously mentioned, the registering of template VMs in a hierarchy (such as VM templates 270, depicted in FIG. 2) enables, for example, an application server to locate a VM in that hierarchy in order to appropriately service application requests. Registration of the parent VM and the container VM template is accomplished, in embodiments, by updating a centralized registry, such as registry 260 shown in FIG. 2. According to embodiments, management server 200 stores, for each registered VM, a virtual machine identifier, a network address, and one or more application identifiers that correspond to applications that execute in the registered VM.

[0047] At step 420, management server 200 stalls execution in both the parent VM and container VM template. The stalling step is performed to prevent updates to the state (including the memory state) of each of these VMs. As mentioned above. VM templates that are instantiated in a hierarchy through a forking process share one or more segments of RAM. This memory-sharing scheme provides for consistency among VMs in the hierarchy and conserves scarce memory resources. According to one or more embodiments, the stalling is performed by preventing any VM template from executing instructions that would modify any of its shared memory segments.

[0048] At step 425, the administrative software (i.e., management server 200) performing method 400 determines a next application that is to be executed in a container. According to one or more embodiments, management server 200 maintains a list of applications that are required by one or more end users to run in an application container. It is advantageous to run some of these applications in a single-container virtual machine, while it may be advantageous to execute other applications in a multi-container virtual machine.

[0049] Accordingly, once management server 200 determines the next application to be run in a container, method 400 proceeds to step 430. At step 430, management server 200 determines whether the next application is to run in a VM with any other containerized applications.

[0050] If the next application is to be run in the same VM with other containerized applications, then method 400 proceeds to step 435. At step 435, management server 200 locates a VM template in the hierarchy that contains the applications with which the current application is to execute. Management server 200 locates an appropriate VM template by performing a lookup to the registry (i.e., registry 260). After locating a VM template that has the required containerized applications, method 400 proceeds to step 440, where management server 200 instructs the located VM template to perform a fork operation, thereby creating a replica of the VM template in the hierarchy. As previously mentioned, at the time that the replica of the VM template is created, the VM replica executes with identical state as the parent VM template, and execution of the VM replica begins at the instruction immediately following the fork operation executed by the parent VM template.

[0051] Referring back to step 430, if management server 200 determines that the next application is to run in a container “standalone” in a virtual machine, then method 400 proceeds to step 445. At step 445, management server 200 instructs the container VM template (e.g., VM 110_B in FIG. 2), which has a single empty container, to perform a fork operation, thereby creating a replica of the container VM template in the hierarchy, where the state of the VM replica is identical, at the time of the fork, as the state of the parent VM template.

[0052] Next, at step 450, management server 200 instantiates a new container (if needed) on the forked VM and installs the application in the container. It should be noted that anew container would need to be instantiated in the case of a multi-container VM. However, if the application is to run in a single-container VM, then the application is installed in the empty container that is copied (due to the fork operation) from the container VM template. Further, once an application is installed in the empty container, that container with the application installed therein occupies a segment of RAM that is different from the segment occupied by the empty container. This is shown in FIG. 1 by containers 113₁ and 113₂. It should be noted that, due to COW semantics, once an application is installed in a container, the virtual memory of the forked VM is remapped so that the physical memory pages allocated to the application container are no longer the same as the physical memory pages allocated to the “empty” container of the parent VM template.

[0053] Once the application is installed to the container in the forked VM, management server 200 then registers and stalls the execution of the forked VM as a new VM template at step 455. The registration of the forked VM specifies, in embodiments, an identifier and network address for the new VM template, as well as an inventory of all application containers installed therein. The stalling of the execution of the new VM template ensures that its state is preserved.

[0054] Once step 455 is complete, the hierarchy (e.g. VM templates 270 shown in FIG. 2) includes a new VM template with one or more “warmed up” containerized applications ready for rapid deployment. Management server 200 then determines, at step 460, whether there are more applications that are required to be run in a container. If there are more applications that require execution in a container, then method 400 proceeds back to step 425, where management server 200 determines a next application. Management server 200 then performs steps 430-455 as set forth above. However, if management server 200 determines that there are no more applications that require execution in a container, then method 400 terminates.

[0055] FIG. 5 is a flow diagram that depicts a method 500 for deploying one or more containerized applications, according to embodiments. Method 500 is performed by an application server, such as application server 310 depicted in FIG. 3.

[0056] Method 500 begins at step 505, where application server 310 receives an application request. Application requests include, for example, an identifier for an application, one or more parameters for the application, as well as an address where results from execution of the application are to be returned. In addition, the application request may include a copy of (or a pointer to) an application that a requestor requires to be executed in a container.

[0057] Thus, at step 510, application server 310 determines whether the request includes the application to be executed. If the request does include a copy of or pointer to the application to be executed, then method 500 proceeds to step 515. At step 515, application server 310 forks a container VM template (or, alternatively, instructs a container VM template to execute a fork operation), such as the container VM template described in connection with method 400 in FIG. 4. As previously mentioned, such a container VM template is a virtual machine template that executes a single empty container. After executing the fork operation, a forked VM template is created, where the forked VM template has identical state as the parent VM template. Further, once created, the forked VM template is a fully initialized and executing virtual machine that begins execution at the instruction immediately following the fork operation executed by the parent VM template. Once application server 310 forks the container VM template, method 500 proceeds to step 520.

[0058] At step 520, application server 310 installs the application provided with the application request into the container of the forked VM template created at step 515. As previously mentioned, as a result of COW, installation of the application at step 520 causes the virtual memory of the forked VM template corresponding to the container to be remapped so that the container of the forked VM template no longer overlaps in physical memory with the container of the parent VM template. Thus, after step 520, a VM is instantiated with a warmed up application, where the application is the one provided in the request received at step 505. Method 500 then proceeds to step 540.

[0059] However, referring back to step 510, if the received request does not include a copy of the application (or pointer to the application), then method 500 proceeds to step 525. At step 525, application server 310 locates a VM template in the hierarchy that includes the application specified in the received request. According to embodiments, the request may specify a particular application with a unique application identifier. In response, application server 310 performs a lookup in a centralized registry (such as registry 260 in FIG. 2) to locate a VM template that includes a container that executes the specified application.

[0060] Application server determines, at step 530, whether such a VM template has been located. If application server 310 does not locate an appropriate VM template, then method 500 proceeds to step 555, where an error is returned to the application requester. Method 500 then terminates.

[0061] However, if application server is able to locate an appropriate VM template, then method 500 proceeds to step 535. At step 535, application server 310 forks the located VM template to produce a child VM that includes the containerized application that was specified in the request. Then, at step 540, the forked VM is launched to process the received request. It should be noted that step 540 is reached from step 520 (when the request includes the application to be run) and from step 535 (when the request does not include the application to be run). Processing of the request at 540 entails, in embodiments, the launching of the forked VM, the invoking of one or more containerized applications in the forked VM, and the passing of parameters received in the request to the containerized applications.

[0062] After the request is processed at step 540, method 500 proceeds to step 545. At step 545, results (if any) from executing the containerized application are obtained and returned to the requestor. In other embodiments, a handle to the forked VM is returned to the requestor, which enables the requestor to conduct ongoing communication with the forked VM.

[0063] After step 545, method 500 proceeds to step 550. At step 550, application server 310 (having returned results to the requestor) determines that the forked VM is no longer needed and, in order to conserve system resources, kills all processes executing on behalf of the forked VM. However, in other embodiments, application server 310 receives an indication from a requestor that the forked VM is no longer required before proceeding to kill the forked VM.

[0064] Although one or more embodiments have been described herein in some detail for clarity of understanding, it should be recognized that certain changes and modifications may be made without departing from the spirit of the disclosure. The various embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities—usually, though not necessarily, these quantities may take the form of electrical or magnetic signals, where they or representations of them are capable of being stored, transferred, combined, compared, or otherwise manipulated. Further, such manipulations are often referred to in terms, such as producing, yielding, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments of the disclosure may be useful machine operations. In addition, one or more embodiments of the disclosure also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for specific required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

[0065] The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.

[0066] One or more embodiments of the present disclosure may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system—computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. Examples of a computer readable medium include a hard drive, network attached storage (NAS), read-only memory, random-access memory (e.g., a flash memory device), a CD (Compact Discs)—CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.

[0067] Although one or more embodiments of the present disclosure have been described in some detail for clarity of understanding, it will be apparent that certain changes and modifications may be made within the scope of the claims. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein, but may be modified within the scope and equivalents of the claims. In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.

[0068] Many variations, modifications, additions, and improvements are possible. Plural instances may be provided for components, operations or structures described herein as a single instance. Boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the disclosure(s). In general, structures and functionality presented as separate components in exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the appended claim(s).