U.S. patent application number 17/186284 was filed with the patent office on 2022-07-21 for updating container runtime using standby virtual machines.
The applicant listed for this patent is VMware, Inc.. Invention is credited to Chen Liu, Junfei Wu, Kai Xiang, Xiaodong Ye, Zhaokai Yuan.
Application Number | 20220229651 17/186284 |
Document ID | / |
Family ID | |
Filed Date | 2022-07-21 |
United States Patent
Application |
20220229651 |
Kind Code |
A1 |
Wu; Junfei ; et al. |
July 21, 2022 |
UPDATING CONTAINER RUNTIME USING STANDBY VIRTUAL MACHINES
Abstract
Described herein are systems, methods, and software to manage
the updates for a container runtime. In one example, a host
identifies a request to update a container runtime from a first
version to a second version for a container executing in a virtual
machine. The host further initiates execution of a second container
in a second virtual machine with the second version of the
container runtime, wherein the second container uses the same root
filesystem as the first container. The host also updates any
required networking configurations to direct communications to the
second container over the first container and stops execution of
the first container.
Inventors: |
Wu; Junfei; (Beijing,
CN) ; Ye; Xiaodong; (Beijing, CN) ; Yuan;
Zhaokai; (Beijing, CN) ; Liu; Chen; (Beijing,
CN) ; Xiang; Kai; (Beijing, CN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
VMware, Inc. |
Palo Alto |
CA |
US |
|
|
Appl. No.: |
17/186284 |
Filed: |
February 26, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
PCT/CN2021/072815 |
Jan 20, 2021 |
|
|
|
17186284 |
|
|
|
|
International
Class: |
G06F 8/65 20060101
G06F008/65; G06F 9/455 20060101 G06F009/455; H04L 12/24 20060101
H04L012/24 |
Claims
1. A method comprising: identifying a request to update a container
runtime from a first version to a second version for a first
container executing in a first virtual machine, wherein the first
container uses a first root filesystem; initiating execution of a
second container in a second virtual machine with the second
version of the container runtime, wherein the second container uses
the first root filesystem; updating a networking configuration to
direct communications to the second container in place of the first
container; and stopping execution of the first container.
2. The method of claim 1, wherein initiating the execution of the
second container comprises mounting one or more storage volumes
also mounted to the first container.
3. The method of claim 1, wherein updating the networking
configuration comprises updating a port forwarding configuration to
forward incoming requests on a port to the second container in
place of the first container.
4. The method of claim 1, wherein the first virtual machine and the
second virtual machine execute on a host computing system.
5. The method of claim 1 further comprising: identifying one or
more additional containers to update the container runtime from the
first version to the second version, wherein the one or more
additional containers each execute in a separate virtual machine;
and for each container in the one or more additional containers:
initiating execution of a standby container in a standby virtual
machine with the second version of the container runtime, wherein
the standby container shares a root filesystem with the container;
and updating the networking configuration to direct communications
to the standby container in place of the container.
6. The method of claim 5 further comprising: for each of the one or
more additional containers, stopping execution of the one or more
additional containers in response to updating the networking
configuration.
7. The method of claim 5 further comprising: determining when no
containers are using the first version of the container runtime;
and deleting data associated with the first version of the
container runtime.
8. The method of claim 5, wherein initiating the execution of the
one or more standby containers and second container occurs in
parallel or in serial.
9. The method of claim 1, wherein the second version comprises
updated networking services or resource management services.
10. A computing apparatus comprising: a storage system; a
processing system operatively coupled to the storage system;
program instructions stored on the storage system that, when
executed by the processing system, direct the computing apparatus
to: identify a request to update a container runtime from a first
version to a second version for a first container executing in a
first virtual machine, wherein the first container uses a first
root filesystem; initiate execution of a second container in a
second virtual machine with the second version of the container
runtime, wherein the second container uses the first root
filesystem; update a networking configuration to direct
communications to the second container in place of the first
container; and stop execution of the first container.
11. The computing apparatus of claim 10, wherein initiating the
execution of the second container comprises mounting one or more
storage volumes also mounted to the first container.
12. The computing apparatus of claim 10, wherein updating the
networking configuration comprises updating a port forwarding
configuration to forward incoming requests on a port to the second
container in place of the first container.
13. The computing apparatus of claim 10, wherein the first virtual
machine and the second virtual machine execute on a host computing
system.
14. The computing apparatus of claim 10, wherein the program
instructions further direct the computing apparatus to: identify
one or more additional containers to update the container runtime
from the first version to the second version, wherein the one or
more additional containers each execute in a separate virtual
machine; and for each container in the one or more additional
containers: initiate execution of a standby container in a standby
virtual machine with the second version of the container runtime,
wherein the standby container shares a root filesystem with the
container; and update the networking configuration to direct
communications to the standby container in place of the
container.
15. The computing apparatus of claim 14, wherein the program
instructions further direct the computing apparatus to: for each of
the one or more additional containers, stop execution of the one or
more additional containers in response to updating the networking
configuration.
16. The computing apparatus of claim 14, wherein the program
instructions further direct the computing apparatus to: determine
when no containers are using the first version of the container
runtime; and delete data associated with the first version of the
container runtime.
17. The computing apparatus of claim 14, wherein initiating the
execution of the one or more standby containers and second
container occurs in parallel or in serial.
18. The computing apparatus of claim 10, wherein the second version
comprises updated networking services or resource management
services.
19. A method comprising: identifying a request a request to update
a container runtime from a first version to a second version for a
plurality of containers, wherein the plurality of containers each
execute on a separate virtual machine; for each container in the
plurality of containers: initiating execution of a standby
container in a standby virtual machine with the second version of
the container runtime; and stopping execution of the virtual
machine associated with the container.
20. The method of claim 19 further comprising: for each container
in the plurality of containers, updating the networking
configuration to direct communications to the standby container in
place of the container.
Description
RELATED APPLICATIONS
[0001] This application is a continuation of and claims benefit
from and priority to PCT Application Serial No. PCT/CN2021/072815
filed in China entitled "UPDATING CONTAINER RUNTIME USING STANDBY
VIRTUAL MACHINES", on Jan. 20, 2021, which is herein incorporated
in its entirety by reference for all purposes.
BACKGROUND
[0002] Containers, such as Docker.TM. Containers, Linux containers,
or other types of containers, provide an efficient mechanism to
deploy applications in a computing environment. Containers are used
to isolate software from its environment to ensure that the
application can execute regardless of infrastructure. Unlike
virtual machines, which contain an operating system, containers
include the necessary executables, binary code, libraries, and
other configuration files to execute the application in the
container without dependencies from outside the container.
[0003] When deployed in a computing environment, containers use a
container runtime to provide required functionality. The container
runtime is software that runs and manages the components required
to execute containers. This software may include networking
services, resource management services, or some other service to
support the services or applications in the container. In some
implementations, the container runtime may require an update to
provide fixes to the runtime, provide additional features to the
runtime, or provide some other functionality. However, these
updates can cause downtime in the execution of the containers as
the container must be stopped while the container runtime is
updated.
OVERVIEW
[0004] The technology disclosed herein manages container runtime
updates using standby virtual machines. In one implementation, a
method includes identifying a request to update a container runtime
from a first version to a second version for a first container
executing in a first virtual machine, wherein the first container
uses a first root filesystem. In response to identifying the
request, the method further provides initiating execution of a
second container in a second virtual machine with the second
version of the container runtime, wherein the second container uses
the first root filesystem. Once initiated, the method updates a
networking configuration to direct communications to the second
container in place of the first container and stops execution of
the first container.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 illustrates a host capable of updating a container
runtime using standby virtual machines according to an
implementation.
[0006] FIG. 2 illustrates a method of updating a container runtime
using standby virtual machines according to an implementation.
[0007] FIGS. 3A-3C illustrate an operational scenario of updating a
container runtime for a container according to an
implementation.
[0008] FIG. 4 illustrates a method of updating the container
runtime for a plurality of containers according to an
implementation.
[0009] FIG. 5 illustrates an operational scenario of updating
container runtime for a plurality of containers according to an
implementation.
[0010] FIG. 6 illustrates a host computing system capable of
managing the updates to container runtime according to an
implementation.
DETAILED DESCRIPTION
[0011] FIG. 1 illustrates a host 100 capable of updating a
container runtime using standby virtual machines according to an
implementation. Host 100 includes host network interface (host NIC)
152, network service 150, virtual machines 120-121, and container
data 155. Virtual machines 120-121 further include virtual network
interfaces (VNICs) 140-141 and containers 130-131. Container data
155 further includes root filesystem (rootfs) 170 and data volumes
160-162 that can be mounted to containers executing on host 100.
Host 100 may comprise a desktop computer, a server computer, a
laptop computer, or some other computer capable of supporting the
virtual machines and the containers.
[0012] In operation, container 130 is executed in virtual machine
120, wherein container 130 may provide various operations including
microservices, web database services, front-end services, or some
other application or service. To support the execution of the
application or service, virtual machine 120 includes a container
runtime that is used to provide components to the application, such
as networking services, resource management services, or some other
services. Container 130 may include executables, binary code,
libraries, and other configuration files to support the execution
of the application or service. In the example of container 130,
container 130 uses rootfs 170 and further has data volumes 160-162
mounted and accessible to container 130. Volumes 160-162 may
comprise physical disks, partitions, virtual disks, or some other
volume accessible to container 130. Although demonstrated as local
to host 100, it should be understood that data volumes 160-162 may
comprise a network storage element capable of being mounted to the
container in the virtual machine.
[0013] As container 130 executes in virtual machine 120, a request
may be identified to update the container runtime. The update
request may be generated by a user of host 100, pushed to host 100
from another computing system, or provided in some other manner. To
support the request and minimize disruptions caused by the update,
host 100 may initiate a replacement virtual machine 121 with
replacement container 131 that can be used to handover the
operations of container 130. In particular, replacement container
131 may use an updated version of the container runtime, wherein
the updated version may include updated networking services,
resource management services, or some other services. In some
examples, virtual machine 121 and replacement container 131 may be
initiated with the updated services. In other examples, virtual
machine 121 may be initiated with an older version of the container
runtime and update the container runtime to make replacement
container 131 available to replace container 130. Replacement
container 131 uses the same rootfs 170 as container 130 and further
mounts data volumes 160-162 that are used by container 130.
[0014] Once replacement container 131 is initiated and available
with the updated container runtime, host 100 may initiate
operations to retire container 130 and virtual machine 120. In some
implementations, network service 150 may be updated to reflect port
forwarding changes for packets received at host NIC 152. In
particular, host 100 may identify an IP address for virtual machine
121 and VNIC 141 and update network service 150 to communicate
packets to virtual machine 121 in place of virtual machine 120.
Although this is one example of an updated networking
configuration, it should be understood that other updates may be
implemented by host 100 including firewall updates or some other
updates to use virtual machine 121 in place of virtual machine 120.
In updating network service 150, a port may be used to identify a
packet destined for the container, perform network address
translation for the IP address in the packet and forward the packet
to the associated virtual machine. In some implementations, virtual
machines 120-121 may comprise optimized virtual machines to support
containers 130-131, however, it should be understood that the
virtual machine may comprise any virtual machine. When a packet is
received at VNIC 140-141, the virtual machine may forward the
packet to a linked interface for the container.
[0015] While demonstrated in the example of FIG. 1 with a single
replacement container and virtual machine for an existing virtual
machine and container, it should be understood that the operation
may be repeated as necessary to update the container runtime for a
plurality of containers. In some implementations, the host, for
each container that requires an update, may initiate a new virtual
machine with an updated runtime for the container. Once a
replacement container is initiated with the appropriate rootfs and
mounted data volumes, the networking configuration, if required,
may be updated to use the replacement container in place of the
existing container, wherein the update may be used to forward
packets to the replacement virtual machine in place of virtual
machine. Once the replacement container is initiated and any
networking configuration is updated, the existing virtual machine
and container can be retired by stopping or deleting the virtual
machine. In some implementations, host 100 may determine when the
container runtime for every container has been updated using the
replacement containers or virtual machines. This determination may
be made when packets are no longer being forwarded to or received
at the virtual machines, which can be identified using timeouts for
packets neither being sent or received by the virtual machine. Once
the runtime is updated, data, such as files and directories
associated with the previous version of the runtime, may be deleted
from host 100.
[0016] FIG. 2 illustrates a method 200 of updating a container
runtime using standby virtual machines according to an
implementation. The steps of method 200 are referenced
parenthetically in the paragraphs that follow with reference to
systems and elements of host 100 of FIG. 1.
[0017] As depicted, method 200 includes identifying (201) a request
to update a container runtime from a first version to a second
version for a first container executing in a first virtual machine,
wherein the first container uses a first root filesystem. The
request may be obtained from a user of host 100, pushed from an
external server indicating the update, or identified in some other
manner. In response to identifying the request, method 200 further
initiates (202) execution of a second container in a second virtual
machine with the second version of the container runtime, wherein
the second container uses the first root filesystem. In some
implementations, virtual machine 121 may be initiated with the same
container runtime as virtual machine 120 and subsequently update
the container runtime. In other implementations, the image for
virtual machine 121 may include the updated runtime required for
replacement container 131.
[0018] As an example, using host 100, a request is received to
update the container runtime associated with container 130. In
response to the request, virtual machine 121 is initiated with
replacement container 131, wherein replacement container 131 is
directed to rootfs 170 and mounts the applicable volumes 160-162 to
replace container 130. For example, if container 130 used data
volumes 160-161, replacement container 131 may mount the same data
volumes 160-161 in preparation of replacing container 130.
[0019] Once the second container is initiated with the updated
container runtime, the method updates (203) a networking
configuration to direct communications to the second container in
place of the first container and stops or retires (204) the
execution of the first container. In some examples, containers may
receive packets using port forwarding, wherein packets received at
a port value may be forwarded to a virtual machine associated with
the port value. To replace container 130, an IP address associated
with VNIC 141 may be used to replace the IP address for VNIC 140 in
network service 150. Accordingly, when a packet is received using
the associated port, the packet may be forwarded to VNIC 141, in
some examples using network address translation. Although described
in the previous example as updating port forwarding, it should be
understood that updates may further be provided to firewalls, NAT
operations, or some other operations to communicate with
replacement container 131. In some implementations, replacement
container 131 may not require networking configuration changes if
it does not communicate with external services. Instead, when
container 131 is initiated, container 130 may be stopped or
retired, permitting the execution of the application or service in
replacement container 131 to assume responsibility for the
application.
[0020] In some examples, multiple containers may require an updated
runtime. As a result, host 100 may initiate a standby virtual
machine with a standby container for each of the containers and
repeat operation 200 for each of the containers. The update for
each of the containers may be implemented in parallel, in serial,
or in some other sequence. Once each of the containers is updated,
any container runtime data that is not required for the new
container runtime may be deleted or removed from the host.
[0021] FIGS. 3A-3C illustrate an operational scenario of updating a
container runtime for a container according to an implementation.
The processes in the operational scenario includes elements from
host 100 of FIG. 1.
[0022] Referring first to FIG. 3A, host 100 may identify, at step
1, an update request to for the container runtime associated with
container 130 and, in response to the request, initiate virtual
machine 121 with replacement container 131. In initiating virtual
machine 121, replacement container 131 may be provided with a data
path to rootfs 170 that can be stored locally on host 100 and
includes the filesystem for replacement container 131 and container
130. Additionally, volumes mounted to container 130 are also
mounted to replacement container 131, permitting access to the same
data for both of the containers.
[0023] Turning to FIG. 3B, once replacement container 131 is
initiated with access to rootfs 170 and data volumes 160-162, host
100 will identify an IP address allocated to virtual machine 121
and VNIC 141, at step 3, and update a networking configuration, at
step 4. In some implementations, a container may rely on port
forwarding to receive communications from other services. When
replacement container 131 is active with the appropriate data and
container runtime, host 100 may identify the IP address for VNIC
141 and update network service 150 to forward packets to the IP
address associated with virtual machine 121 instead of virtual
machine 120. In some implementations, the update to the networking
configuration may update firewalls, routing tables, or some other
information to redirect communications to virtual machine 121 in
place of virtual machine 120.
[0024] Referring now to FIG. 3C, once replacement container 131 is
available to replace container 130 and the networking configuration
is updated, virtual machine 120 and container 130 can be retired.
In particular, virtual machine 120 may be stopped or deleted, once
virtual machine 121 is used to replace the operations of virtual
machine 120 and container 130. Thus, when new a packet is received,
network service 150 may forward the packet to VNIC 141 with
replacement container 131 to provide replacement operations for
container 130. In some implementations, a host may include multiple
containers that each require an update. As a result, host 100 may
update each of the containers using the operations described in
FIGS. 3A-3B and, once updated using replacement virtual machines
and containers, delete any unrequired files or data that was
associated with the previous container runtime.
[0025] FIG. 4 illustrates a method 400 of updating the container
runtime for a plurality of containers according to an
implementation. The steps of method 400 are referenced
parenthetically in the paragraphs that follow.
[0026] As depicted, method 400 includes identifying (401) a request
to update a container runtime for a plurality of containers each
executing on its own unique virtual machine. In response to the
request, method 400 further provides, for each container,
initiating (402) a standby container in a new virtual machine with
the updated container runtime. The standby container may access the
same root filesystem as the container it is replacing and may
further mount the same storage volumes, such that the standby
container has access to the same data as the container it is
replacing. In some implementations, when the new virtual machine is
initiated, the virtual machine may include the updated container
runtime. In other implementations, the new virtual machine may be
initiated, and the container runtime updated after initiation. The
initiation of the new virtual machines may occur in parallel, in
serial, or in some combination thereof.
[0027] As the new virtual machines are initiated with the standby
containers, the method further includes, for each container,
updating (403) a networking configuration to direct communications
to the new virtual machine with the associated standby container.
The update may include port forwarding update to direct
communications to the IP address associated with the new virtual
machine, update a firewall to permit communications to the new
virtual machine, or some other networking configuration update. In
some implementations, at least a portion of the containers may not
require networking configuration modifications. Instead, an update
may be completed when the container is executable with the updated
container runtime.
[0028] Once the networking configuration is modified to direct
communications to the standby containers, the host may stop the
execution of the containers associated with the previous version of
the container runtime. After stopping the execution of the
containers and virtual machines associated with the previous
version of the container runtime, method 400 further includes
removing (404) unused data associated with the previous container
runtime. Advantageously, the host may use the previous version of
the container runtime, while new virtual machines and containers
are initiated with the new container runtime. Although demonstrated
in the example of FIG. 4 as removing the data associated with the
previous version of the container runtime, it should be understood
that the data may remain available on the host.
[0029] FIG. 5 illustrates an operational scenario 500 of updating
container runtime for a plurality of containers according to an
implementation. Operational scenario 500 includes virtual machines
520-521 with containers 530-531 and runtimes 540-541. Operational
scenario 500 further includes update operation 550 and delete
operation 552.
[0030] In operation, when a request is received to update a
container runtime from container runtime 540 to container runtime
541, update operation 550 initiates virtual machines 521 that each
correspond to a different virtual machine from virtual machines
520. Virtual machines 520 and virtual machines 521 may comprise
optimized virtual machines for containers or may comprise some
other type of virtual machine. Virtual machines 521 may be
initiated in parallel, may be initiated in serial, or may be
initiated in some other sequence. In some implementations, for each
container of containers 530, update operation 550 may initiate a
new virtual machine in virtual machines 521 with a new container
that accesses the same root filesystem as the original container.
The new container may further access, or mount, one or more storage
volumes associated with the container from virtual machines 520,
wherein the storage volumes may comprise partitions, a storage
pool, a disk, a virtual disk, or some other type of volume.
[0031] As containers 531 are initiated in virtual machines 521,
update operation 550 may update a networking configuration
associated with the containers. The update may be used to forward
communications to containers 531 in place of a corresponding
container in containers 530. The update may include an update to a
port forwarding configuration, an update to a firewall
configuration, or some other update to the networking
configuration. For example, when after initiating a standby
container in containers 531, update operation 550 may identify an
IP address for the virtual machine associated with the standby
container and update a port forwarding configuration to forward
packets to the container in containers 531 in place of the
container in containers 530.
[0032] While updating the container runtime, delete operation 552
may monitor for when containers 531 have replaced all of containers
530. This monitoring may include determining when all of containers
531 are executing, determining when the networking configuration
has been updated for all of the containers, or determining some
other factor associated with completing the transition from
containers 530 with runtime 540 to containers 531 with runtime 541.
After determining that containers 531 have replaced containers 530,
delete operation 552 may delete any unnecessary data associated
with runtime 540. In some implementations, a host may maintain
multiple copies of a runtime as required, wherein a runtime 540 may
represent a first copy with first features and runtime 541 may
represent an updated copy with second features. When the update is
completed to executing containers 531 in place of containers 530,
the host may delete the copy of runtime 540. In other
implementations, the host may delete files or directories that are
replaced are unused by runtime 541.
[0033] FIG. 6 illustrates a host computing system 600 capable of
managing the updates to container runtime according to an
implementation. Host computing system 600 is representative of any
computing system or systems with which the various operational
architectures, processes, scenarios, and sequences disclosed herein
for a host can be implemented. Host computing system 600 is an
example of host 100 of FIG. 1, although other examples may exist.
Host computing system 600 includes storage system 645, processing
system 650, and communication interface 660. Processing system 650
is operatively linked to communication interface 660 and storage
system 645. Host computing system 600 may further include other
components such as a battery and enclosure that are not shown for
clarity.
[0034] Communication interface 660 comprises components that
communicate over communication links, such as network cards, ports,
radio frequency (RF), processing circuitry and software, or some
other communication devices. Communication interface 660 may be
configured to communicate over metallic, wireless, or optical
links. Communication interface 660 may be configured to use Time
Division Multiplex (TDM), Internet Protocol (IP), Ethernet, optical
networking, wireless protocols, communication signaling, or some
other communication format--including combinations thereof.
Communication interface 660 may be configured to communicate with
other computing systems, such as clients, other hosts, or some
other computing element or device.
[0035] Processing system 650 comprises microprocessor and other
circuitry that retrieves and executes operating software from
storage system 645. Storage system 645 may include volatile and
nonvolatile, removable and non-removable media implemented in any
method or technology for storage of information, such as computer
readable instructions, data structures, program modules, or other
data. Storage system 645 may be implemented as a single storage
device but may also be implemented across multiple storage devices
or sub-systems. Storage system 645 may comprise additional
elements, such as a controller to read operating software from the
storage systems. Examples of storage media include random access
memory, read only memory, magnetic disks, optical disks, and flash
memory, as well as any combination or variation thereof, or any
other type of storage media. In some implementations, the storage
media may be a non-transitory storage media. In some instances, at
least a portion of the storage media may be transitory. It should
be understood that in no case is the storage media a propagated
signal.
[0036] Processing system 650 is typically mounted on a circuit
board that may also hold the storage system. The operating software
of storage systems 645 comprises computer programs, firmware, or
some other form of machine-readable program instructions. The
operating software of storage system 645 comprises update process
632 and virtual machines 620-623 with containers 625-628. The
operating software on storage system 645 may further include
utilities, drivers, network interfaces, applications, or some other
type of software. Although illustrated as separate in the present
implementation, it should be understood that container service(s)
630 may be implemented as part of operating system 632 in some
examples. When read and executed by processing system 650 the
operating software on storage system 645 directs host computing
system 600 to operate as described herein.
[0037] In at least one implementation, virtual machines 620-623
execute on host computing system 600 to provide a platform for
containers 625-528. Virtual machines 620-623 may represent virtual
machines optimized to support containers or may represent some
other virtual machine. Virtual machines 620-623 may execute on an
operating system or standalone hypervisor capable of supporting the
virtualization of hardware for the virtual machines. In providing
the platform for containers 625-628, virtual machines 620-623 may
include a container runtime, wherein the container runtime may
include services for networking, resource management, or some other
service to support the container.
[0038] During the execution of virtual machines 620-623, update
process 632 directs processing system 650 to identify a request to
update the container runtime, wherein the request may be initiated
by a user, may be initiated by an updated received by host
computing system 600 from an external server or computing system,
or initiated in some other manner. In response to the request,
update process 632 directs processing system 650 to identify the
virtual machines with the container runtime that is to be updated
and, for each of the virtual machines, initiate a replacement
virtual machine. For example, virtual machines 620-623 may include
a container runtime for containers 625 that is to be updated.
Consequently, update process 632 may initiate new virtual machines
for each of virtual machines 620-623 to support the update. The
initiation of each of the replacement virtual machines may occur in
parallel, in serial, or some combination thereof.
[0039] In one example of updating the runtime associated with
container 625, update process 632 may direct processing system 650
to initiate a standby virtual machine with a replacement container
for container 625, wherein the standby virtual machine includes an
updated runtime for the standby container. The updated runtime may
be included as part of the image for the replacement virtual
machine or may be made available by initiating the standby virtual
machine and subsequently updating the runtime in the standby
virtual machine to support the replacement container.
[0040] Once the updated runtime is available on the replacement
virtual machine for the replacement container, update process 632
may direct processing system 650 to execute the replacement
container using the same root filesystem as container 625 and mount
any required volumes that are also mounted to container 625. In
some implementations, the host may maintain a record of the root
filesystem associated with each of the containers and select the
corresponding root filesystem to initiate each of the containers.
Once the container is executable using the required filesystem and
associated data, update process 632 may initiate one or more
modifications to the networking configuration on at least host
computing system 600. The update may be used to update port
forwarding, a virtual switch, a firewall, or some other network
configuration to communicate packets to the standby container in
place of container 625. In at least one example, update process 632
may direct processing system 645 to update a port forwarding for a
port associated with communication interface 660. For example, a
port forwarding configuration may initially permit that packets
received on port 8080 to be forwarded to the IP address associated
with virtual machine 620 and container 625. To update the port
forwarding configuration, update process 632 may identify an IP
address associated with the standby virtual machine and update the
port forwarding configuration to forward packets received on port
8080 to the IP address associated with the standby virtual machine
(using network address translation). Once the networking
configuration is updated to use the virtual machine with the
updated container runtime in place of the virtual machine with the
older version container runtime, the container executing with the
older version of the container runtime may be retired. The
retirement process may include unmounting any volumes for the
container, stopping execution of the container and virtual machine,
or some other operation to retire the older virtual machine and
container.
[0041] As the containers are updated by update process 632, update
process 632 may monitor for the completion of the update. This may
be identified when no original container is executing or using the
initial version of the container runtime. In response to
identifying that the update is completed, update process 632 may
delete or remove the data associated with the previous version of
the container runtime. In some implementations, host computing
system 600 may maintain multiple versions of the container runtime
and may delete the version that is no longer required by the
containers. In other examples, only portions of the runtime may be
deleted or removed from host computing system 600.
[0042] The included descriptions and figures depict specific
implementations to teach those skilled in the art how to make and
use the best mode. For the purpose of teaching inventive
principles, some conventional aspects have been simplified or
omitted. Those skilled in the art will appreciate variations from
these implementations that fall within the scope of the invention.
Those skilled in the art will also appreciate that the features
described above can be combined in various ways to form multiple
implementations. As a result, the invention is not limited to the
specific implementations described above, but only by the claims
and their equivalents.
* * * * *