Patent Description:
Many traditional systems for container distribution make use of container images, static versions of the container code that are easily portable and that can be used to instantiate containers. Updating or otherwise modifying a container-based application that is generated from an image typically involves rebuilding the image and redistributing the new image to all the locations that host the container. Unfortunately, the process of rebuilding and redistributing an image can consume considerable computing resources and involve potentially undesirable delays. The instant disclosure, therefore, identifies and addresses a need for systems and methods for updating containers.

<CIT> describes that for efficient hosting of virtualized containers using read-only operating systems a single operating system image is shared among multiple running virtualized containers such that each running container interacts with underlying shared files and resources in system storage. Each container running on a server are provided the same image, which remains consistent among the containers. Each image is named and versioned and each container is configured in a manner that defines which underlying image is used when the container is started. When updates to the image are made, a new image is be generated, and the containers are be switched to the new image by changing configuration properties associated with the container and restarting the container.

As will be described in greater detail below, the instant disclosure describes various systems and methods for updating containers by distributing ancillary code in data volume containers that are discovered by the application containers.

Throughout the drawings, identical reference characters and descriptions indicate similar, but not necessarily identical, elements. While the example embodiments described herein are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. However, the example embodiments described herein are not intended to be limited to the particular forms disclosed. Rather, the instant disclosure covers all modifications, equivalents, and alternatives falling within the scope of the appended claims.

The present disclosure is generally directed to systems and methods for updating containers. As will be explained in greater detail below, by configuring an application container image and/or a container platform to automatically discover data volume containers containing add-ons, hotfixes, plugins, and the like by searching for new ancillary code whenever an application container is instantiated, the various systems and methods described herein may be able to efficiently update application containers with new code with the minimum of user intervention and without requiring changes to the base application container image. Moreover, the systems and methods described herein may improve the functioning and/or performance of a computing device (such as a cloud server) by improving the functioning of applications executing within containers on the computing device and/or improving the efficiency with which updates are applied to application containers on the computing device. These systems and methods may also improve the field of virtualization by providing an efficient process for updating applications executing in virtualization containers and/or allowing the same application container image to be used in different contexts by streamlining the process for customizing the application container with ancillary code.

The following will provide, with reference to <FIG>, <FIG>, <FIG>, and <FIG>, detailed descriptions of example systems for updating containers. Detailed descriptions of corresponding computer-implemented methods will also be provided in connection with <FIG>.

<FIG> is a block diagram of example system <NUM> for updating containers. As illustrated in this figure, example system <NUM> may include one or more modules <NUM> for performing one or more tasks. For example, and as will be explained in greater detail below, example system <NUM> includes an identification module <NUM> that identifies an application container that is instantiated from a static application container image and that isolates a user space of an application that executes within the application container from other software on a host system while sharing a kernel space with the other software. In some examples, identification module <NUM> also identifies ancillary code that is designed to modify execution of the application executing in the application container. Example system <NUM> additionally includes a packaging module <NUM> that packages the ancillary code into a data volume container image to be deployed to the host system that hosts the application container. Example system <NUM> also includes a discovery module <NUM> that discovers, by the application container, a pointer to a location of a data volume container instantiated from the data volume container image on the host system. Example system <NUM> additionally includes a modifying module <NUM> that modifies, by the application container, the execution of the application executing in the application container with the ancillary code, without modifying the static application container image, at least in part by instantiating the application container with the pointer to the location of the data volume container that contains the ancillary code. Although illustrated as separate elements, one or more of modules <NUM> in <FIG> may represent portions of a single module or application.

In certain embodiments, one or more of modules <NUM> in <FIG> may represent one or more software applications or programs that, when executed by a computing device, may cause the computing device to perform one or more tasks. For example, and as will be described in greater detail below, one or more of modules <NUM> may represent modules stored and configured to run on one or more computing devices, such as the devices illustrated in <FIG> (e.g., computing device <NUM> and/or host system <NUM>). One or more of modules <NUM> in <FIG> may also represent all or portions of one or more special-purpose computers configured to perform one or more tasks.

As illustrated in <FIG>, example system <NUM> may also include one or more memory devices, such as memory <NUM>. Memory <NUM> generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and/or computer-readable instructions. In one example, memory <NUM> may store, load, and/or maintain one or more of modules <NUM>. Examples of memory <NUM> include, without limitation, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, Hard Disk Drives (HDDs), Solid-State Drives (SSDs), optical disk drives, caches, variations or combinations of one or more of the same, or any other suitable storage memory.

As illustrated in <FIG>, example system <NUM> may also include one or more physical processors, such as physical processor <NUM>. Physical processor <NUM> generally represents any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions. In one example, physical processor <NUM> may access and/or modify one or more of modules <NUM> stored in memory <NUM>. Additionally or alternatively, physical processor <NUM> may execute one or more of modules <NUM> to facilitate updating containers. Examples of physical processor <NUM> include, without limitation, microprocessors, microcontrollers, Central Processing Units (CPUs), Field-Programmable Gate Arrays (FPGAs) that implement softcore processors, Application-Specific Integrated Circuits (ASICs), portions of one or more of the same, variations or combinations of one or more of the same, or any other suitable physical processor.

As illustrated in <FIG>, example system <NUM> may also include one or more additional elements <NUM>, such as application container <NUM>, ancillary code <NUM>, data volume container image <NUM>, and/or data volume container <NUM>. Application container <NUM> generally represents any type or form of virtualization platform capable of hosting an application. Ancillary code <NUM> generally represents any type or form of code that can be applied to an application and/or can modify the behavior of an application. Data volume container image <NUM> generally represents any type or form of code that can be used to instantiate a data volume container. Data volume container <NUM> generally represents any type or form of virtualization container capable of storing and/or executing ancillary code.

Example system <NUM> in <FIG> may be implemented in a variety of ways. For example, all or a portion of example system <NUM> may represent portions of example system <NUM> in <FIG>. As shown in <FIG>, system <NUM> may include a computing device <NUM> in communication with a host system <NUM> via a network <NUM>. In one example, all or a portion of the functionality of modules <NUM> may be performed by computing device <NUM>, host system <NUM>, and/or any other suitable computing system. As will be described in greater detail below, one or more of modules <NUM> from <FIG> may, when executed by at least one processor of computing device <NUM> and/or host system <NUM>, enable computing device <NUM> and/or host system <NUM> to update containers.

Computing device <NUM> generally represents any type or form of computing device capable of reading computer-executable instructions. In some embodiments, computing device <NUM> may be a personal computing device used by a developer. In other embodiments, computing device <NUM> may be a cloud server. Additional examples of computing device <NUM> include, without limitation, laptops, tablets, desktops, servers, cellular phones, Personal Digital Assistants (PDAs), multimedia players, embedded systems, wearable devices (e.g., smart watches, smart glasses, etc.), smart vehicles, so-called Internet-of-Things devices (e.g., smart appliances, etc.), gaming consoles, variations or combinations of one or more of the same, or any other suitable computing device.

Host system <NUM> generally represents any type or form of computing device that is capable of hosting one or more virtualization containers. In some embodiments, host system <NUM> may be a cloud server. Additional examples of host system <NUM> include, without limitation, storage servers, database servers, application servers, and/or web servers configured to run certain software applications and/or provide various storage, database, and/or web services. Although illustrated as a single entity in <FIG>, host system <NUM> may include and/or represent a plurality of servers that work and/or operate in conjunction with one another.

Network <NUM> generally represents any medium or architecture capable of facilitating communication or data transfer. In one example, network <NUM> may facilitate communication between computing device <NUM> and host system <NUM>. In this example, network <NUM> may facilitate communication or data transfer using wireless and/or wired connections. Examples of network <NUM> include, without limitation, an intranet, a Wide Area Network (WAN), a Local Area Network (LAN), a Personal Area Network (PAN), the Internet, Power Line Communications (PLC), a cellular network (e.g., a Global System for Mobile Communications (GSM) network), portions of one or more of the same, variations or combinations of one or more of the same, or any other suitable network.

Application <NUM> generally represents any type or form of executable code. Application container image <NUM> generally represents any type or form of code that can be used to instantiate an application container.

Many other devices or subsystems may be connected to system <NUM> in <FIG> and/or system <NUM> in <FIG>. Conversely, all of the components and devices illustrated in <FIG> and <FIG> need not be present to practice the embodiments described and/or illustrated herein. The devices and subsystems referenced above may also be interconnected in different ways from that shown in <FIG>. Systems <NUM> and <NUM> may also employ any number of software, firmware, and/or hardware configurations. For example, one or more of the example embodiments disclosed herein may be encoded as a computer program (also referred to as computer software, software applications, computer-readable instructions, and/or computer control logic) on a computer-readable medium.

The term "computer-readable medium," as used herein, generally refers to any form of device, carrier, or medium capable of storing or carrying computer-readable instructions. Examples of computer-readable media include, without limitation, transmission-type media, such as carrier waves, and non-transitory-type media, such as magnetic-storage media (e.g., hard disk drives, tape drives, and floppy disks), optical-storage media (e.g., Compact Disks (CDs), Digital Video Disks (DVDs), and BLU-RAY disks), electronic-storage media (e.g., solid-state drives and flash media), and other distribution systems.

<FIG> is a flow diagram of an example computer-implemented method <NUM> for updating containers. The steps shown in <FIG> may be performed by any suitable computer-executable code and/or computing system, including system <NUM> in <FIG>, system <NUM> in <FIG>, and/or variations or combinations of one or more of the same. In one example, each of the steps shown in <FIG> may represent an algorithm whose structure includes and/or is represented by multiple sub-steps, examples of which will be provided in greater detail below.

As illustrated in <FIG>, at step <NUM>, one or more of the systems described herein may identifies an application container that is instantiated from a static application container image and that isolates a user space of an application that executes within the application container from other software on a host system while sharing a kernel space with the other software. For example, identification module <NUM>, as part of computing device <NUM> in <FIG>, identifies application container <NUM> that is instantiated from a static application container image <NUM> and that isolates a user space of application <NUM> that executes within application container <NUM> from other software on host system <NUM> while sharing a kernel space with the other software.

The term "application," as used herein, generally refers to any executable code that is capable of launching a process. In some embodiments, an application may be a piece of software. Additionally or alternatively, an application is a script. In some examples, an application may be a standalone application. In other examples, an application may be a frontend for a larger system, such as an interface for a web application. In some examples, an application may include a collection of interoperating programs and/or executable objects. In one example, an application may be a backup, storage, and/or deduplication application.

The term "cotitainer," as used herein, generally refers to any type of virtual environment that does not include an entire operating system but does include enough computing resources to execute at least one process and/or application when supplemented by computing resources from an operating system of a host computing system. In some embodiments, the resources and/or processes within a container may be isolated from resources and/or processes outside the container. For example, a container may isolate user space of a deployment system from other software on the deployment system while sharing kernel space with the other software. The term "user space," as used herein, generally refers to the portion of memory in a computing environment where application software executes. In some embodiments, user space may include libraries, graphics engines, device drivers for certain devices, and/or system daemons. The term "kernel space," as used herein, generally refers to the portion of memory in a computing environment reserved for executing an operating system kernel, kernel extensions, and device drivers. In contrast, virtualization environments that are not containers, such as virtual machines, may not share kernel space with other software. Other forms of application virtualization that are also not containers may share both kernel space and user space with other applications. In some embodiments, a container may execute only a single process and/or application, while in other embodiments, a container may execute multiple processes and/or applications. In some embodiments, a container may be a DOCKER container. The term "application container," as used herein, generally refers to a container that stores and/or hosts an application. In some examples, an application container may also host bundled components for an application.

The term "container image," as used herein, generally refers to a data object that stores data describing a container and/or data that can be reconstructed into an executing container but that is not itself an executing container. In some embodiments, a container image may be a compressed file that contains data necessary to execute the container. In some examples, a container image may be built from a parent container image. In some examples, a container image may be read-only from the perspective of a system that creates container instances from the container image. In some examples, one or more of the systems described herein may create multiple container instances from a single container image.

Identification module <NUM> may identify the application container in a variety of ways and/or contexts. For example, identification module <NUM> may identify the application container in response to receiving information that updates are available for the application that executes in the container. In another example, identification module <NUM> may identify the application container by searching for all containers that are currently hosting a particular application. Additionally or alternatively, identification module <NUM> may identify the application container in response to a user specifying the application container.

At step <NUM>, one or more of the systems described herein identifies ancillary code that is designed to modify execution of the application executing in the application container. For example, identification module <NUM> may, as part of computing device <NUM> in <FIG>, identify ancillary code <NUM> that is designed to modify execution of application <NUM> executing in application container <NUM>.

The term "ancillary code," as used herein, generally refers to any code that is designed to modify the behavior of another application. In some embodiments, ancillary code may include an application that modifies the behavior of another application by supplying the application with parameters, restricting actions available to the application, intercepting messages to and/or from the application, and/or performing other actions. In other embodiments, ancillary code may not be a standalone application but may be code that is designed to be applied to an application. For example, ancillary code may be a hotfix, patch, plugin, update, or other code that is designed to fix a problem with and/or add functionality to an application. In some examples, ancillary code may include internal logic to update configuration parameters and/or process existing application data apart from installing new binaries and/or libraries. In some embodiments, ancillary code may include an installation script that creates binaries and/or libraries and/or makes configuration changes to an application.

Identification module <NUM> may identify the ancillary code in a variety of ways. In one example, the ancillary code may be an automatic update to the application and identification module <NUM> may identify the ancillary code via an update service for the application. In another example, a developer may specify the ancillary code to identification module <NUM>. Additionally or alternatively, identification module <NUM> may identify the ancillary code by performing a search for ancillary code relevant to the application.

At step <NUM>, one or more of the systems described herein packages the ancillary code into a data volume container image to be deployed to the host system that hosts the application container. For example, packaging module <NUM> as part of computing device <NUM> in <FIG>, packages ancillary code <NUM> into data volume container image <NUM> to be deployed to host system <NUM> that hosts application container <NUM>.

The term "data volume container," as used herein, generally refers to any container that contains one or more data volumes configured to be exposed to other containers. In some embodiments, a data volume container may be read-only and/or may contain data volumes that are exposed as read-only. In some examples, a data volume container may be and/or contain a named volume. In some embodiments, a data volume container may be treated by a container platform as a data volume in addition to or in place of being treated as a container. In some embodiments, multiple application containers may read from the same read-only data volume container. The term "data volume," as used herein, generally refers to any directory that stores one or more files that can be read by applications and/or processes. In some examples, a data volume may contain a combination of binaries, libraries, and/or configuration files.

Packaging module <NUM> may package the ancillary code in a variety of ways and/or contexts. For example, packaging module <NUM> may create a container image to host the ancillary code by copying from a base container image. In some embodiments, the ancillary code may be packaged into a container because the ancillary code may not be capable of executing independently.

In some examples, packaging module <NUM> may package a single piece of ancillary code, such as a plugin, in a data volume container image. In other examples, packaging module <NUM> may package multiple pieces of ancillary code intended for the same application into one data volume container image. In some embodiments, packaging module <NUM> may package multiple pieces of anciliary code into different data volumes that packaging module <NUM> then packages into a single data volume container image. In some examples, a data volume container may include only the ancillary code, resulting in a data volume container image that occupies the same amount of memory as the total memory occupied by the files in the ancillary code.

At step <NUM>, one or more of the systems described herein discovers, by the application container, a pointer to a location of a data volume container instantiated from the data volume container image on the host system. For example, discovery module <NUM> as part of computing device <NUM> in <FIG>, discovers, by application container <NUM>, a location of data volume container <NUM> on host system <NUM>.

Discovery module <NUM> discovers the pointer to the location of the data volume container instantiated from the data volume container image in a variety of ways. In some embodiments, the application container and/or container platform that executes the application container is configured with a script that discovers the location of the data volume container and/or data volume container image. In some examples, the data volume container image may be stored in the host system's container image cache and the data volume container image may be configured to instantiate the data volume container in a predetermined location. In some embodiments, discovery module <NUM> may discover the location of the data volume container image and may then instantiate a data volume container from the data volume container image before and/or when the application container is instantiated. In other embodiments, the container platform may instantiate the data volume container from the data volume container image as soon as the data volume container image is deployed and discovery module <NUM> may discover the location of the instantiated data volume container. In some examples, the application container may receive information about the instantiated data volume container but may receive no information about the data volume container image. In some embodiments, discovery module <NUM> may discover multiple data volumes within one data volume container. In some examples, discovery module <NUM> may discover all of the data volumes within a single data volume container.

For example, packaging module <NUM>, as part of the application container, packages the location of the data volume container image on the host system by configuring, at the creation of the static application container image, the static application container image with a script that scans for new ancillary code upon the application container being instantiated from the static application container image. In this embodiment, discovery module <NUM> discovers the location of the data volume container by the application container executing the script. In some embodiments, configuring the static application container image with the script that scans for the new ancillary code includes configuring the script to scan a predetermined directory and packaging the ancillary code into the data volume container image to be deployed to the host system that hosts the application container includes configuring the data volume container image to instantiate the data volume container in the predetermined directory on the host system. In this embodiment, discovering, by the script, the ancillary code includes discovering the data volume container in the predetermined directory. In some embodiments, discovery module <NUM> may discover and/or install the data volumes container before the application container is restarted and/or instantiated in order to minimize impact on the operation of the application.

In some examples, the container may discover all instances of data volume containers and/or container images stored in the predetermined directory and/or may discover multiple data volume containers at once. For example, as illustrated in <FIG>, an application container <NUM> may execute on a host system <NUM>. In some examples, application container <NUM> may host an application <NUM> and/or be configured with a script <NUM>. In one embodiment, whenever application <NUM> is instantiated, before application <NUM> is initiated, application container <NUM> may execute script <NUM> to search a predetermined directory <NUM> for data volume containers. In some examples, predetermined directory <NUM> may contain a data volume container <NUM> that contains ancillary code <NUM> and/or a data volume container <NUM> that contains ancillary code <NUM>. In one example, script <NUM> may discover data volume container <NUM> and/or data volume container <NUM> and/or may apply ancillary code <NUM> and/or ancillary code <NUM> to application <NUM>.

As claimed, packaging module <NUM> packages the data volume container image on the host system by configuring a container platform that instantiates the application container on the host system with a script that scans for new ancillary data upon instantiation of the application container by the container platform. In this embodiment, discovery module <NUM> may discover the location of the data volume container by the container platform executing the script while instantiating the application container. The term "container platform," as used herein, generally refers to any application, module, script, and/or code capable of executing a container. In some embodiments, a container platform may take a container image file as input and may launch the container from the image file. In some examples, a container platform may host data volumes and/or other data used by containers. In some embodiments, a container platform may include a container engine. For example, the container platform may be the DOCKER container engine.

In one embodiment, discovery module <NUM> may create a symbolic link between the location of the data volume container on the host system and a new location on the host system. In one example, discovery module <NUM> may create a symbolic link between the location of the data volume container and a location within the namespace of the application container. In some embodiments, the data volume container may include a script that creates the symbolic link. In some examples, the same script may create the symbolic link and install the ancillary code in the application container. By creating a symbolic link, the systems described herein may save memory and/or processing power over of copying the data volume container to a different directory. In some examples, the systems described herein may create symbolic links between the location of the data volume container and multiple other locations. For example, the systems described herein may create symbolic links to different application-specific directories where different application containers expect to find data volume containers. In some embodiments, the systems described herein may create symbolic links to read-only versions of the data volume container in order to preserve the integrity of the data volume container.

Returning to <FIG>, at step <NUM>, one or more of the systems described herein modifies, by the application container, the execution of the application executing in the application container with the ancillary code, without modifying the static application container image, at least in part by instantiating the application container with a pointer to the location of the data volume container that contains the ancillary code. For example, modifying module <NUM>, as part of computing device <NUM> in <FIG>, modifies, by application container <NUM>, the execution of application <NUM> executing in application container <NUM> with ancillary code <NUM>, without modifying the static application container image <NUM>, at least in part by instantiating application container <NUM> with a pointer to the location of data volume container <NUM> that contains ancillary code <NUM>.

Modifying module <NUM> may modify the application with the ancillary code in a variety of ways. For example, modifying module <NUM> may modify the application with the ancillary code by applying the ancillary code to the application, in cases where the ancillary code is a hotfix, patch, plugin, or similar. In another example, modifying module <NUM> may modify the application with the ancillary code by executing the ancillary code in a way that enables the ancillary code to take actions that affect the application, such as reconfiguring the application, supplying the application with parameters, intercepting traffic to and/or from the application, restricting permissions of the application, and/or managing the application in other ways. In some examples, modifying module <NUM> may also update the application's data, configuration, and/or other settings that are not packaged in the data volume container image.

In some examples, modifying module <NUM> may modify the application container with the pointer to the location of the data volume container that contains the ancillary code by restarting the application container. For example, modifying module <NUM> may restart the container and may pass the location of the data volume container as a parameter to the command to restart the application container. In other examples, modifying module <NUM> instantiates an application container that has not previously been executed and instantiates the application with a pointer to the location of the data volume container. As claimed, modifying module <NUM> modifies the application with the ancillary code by running an installation script in a data volume stored in the data volume container. In some examples, modifying module <NUM> may run an installation script inside each of multiple data volumes stored within the same data volume container.

In some embodiments, different application containers executing instances of the same application may discover and/or modify applications using different ancillary code stored in different data volumes stored in different data volume container images and/or data volume containers instantiated from data volume container images. For example, as illustrated in <FIG>, a host system <NUM> may host a container platform <NUM>. In some examples, container platform <NUM> may host application containers <NUM>, <NUM>, and/or <NUM> that are all instantiated from an application container image <NUM> and/or all host instances of application <NUM>. In one example, application container <NUM> may modify application <NUM> with ancillary code <NUM> after discovering data volume container <NUM>, application container <NUM> may modify application <NUM> with ancillary code <NUM> after discovering data volume container <NUM>, and/or application container <NUM> may modify application <NUM> with both ancillary code <NUM> and ancillary code <NUM> after discovering both data volume containers. In one example, ancillary code <NUM> may be a plugin that adds functionality useful to the tasks being performed by the instances of application <NUM> in application containers <NUM> and <NUM> but not application container <NUM>, while ancillary code <NUM> may be a plugin that adds functionality useful to the tasks being performed by the instances of application <NUM> in application containers <NUM> and <NUM> but not application container <NUM>.

In some embodiments, an application container that has previously discovered a data volume container may automatically rediscover that data volume container each time the application container is restarted. In some examples, the application container may automatically rediscover the previously discovered data volume containers even when restarting due to a new data volume container becoming available. For example, application container <NUM> may discover data volume container <NUM> and may modify application <NUM> with ancillary code <NUM>. At a later time, application container <NUM> may be restarted and may discover data volume container <NUM>. In some examples, application container <NUM> may also automatically rediscover data volume container <NUM> and may modify application <NUM> with both ancillary code <NUM> and ancillary code <NUM>. In some embodiments, application container <NUM> may discover both data volume containers because both data volume containers may be stored in a predetermined directory. Additionally or alternatively, container platform <NUM> may track which data volume containers have been discovered by which application containers.

In some embodiments, the systems described herein may provide a user interface that may allow a user to add and/or subtract the data volume containers that are read from by each application container. In one embodiment, a data volume container that has been discovered by an application container may be automatically rediscovered by that application container on ever restart until a user removes the data volume container from the list of data volume containers associated with that application container. In some examples, a user may remove the data volume container in order to prevent a patch, plugin, hotfix, or other ancillary code from continuing to be applied to the application after the next time the application container is restarted. In one example, a user may change the version of a plugin, hotfix, or other ancillary code that is applied to an application by removing the data volume container with the currently applied version, adding a data volume container with a different version, and restarting the application container.

As discussed in connection with method <NUM> above, the systems and methods described herein may efficiently update application containers without creating new application container images by configuring the application container images and/or the container platform with a script that discovers relevant ancillary code whenever an application container is instantiated. In some examples, the ancillary code may be available to the application container every time the container is restarted until a user removes the ancillary code and/or the instructions to install the ancillary code. For example, a container may host a legacy application that requires a large number of patches to remain current and/or uses multiple plugins to add functionality that may not be necessary for all instances of the application. Rather than creating a new application container image each time a patch is released and/or for each instance of the application that uses different plugin configurations, the systems described herein may enable the application container to automatically discover and install the relevant patches and/or plugins on each restart by locating the ancillary code in a predictable location and/or tracking which ancillary code is applied to which container. By discovering and installing hotfixes, patches, and plugins in this way, the systems and methods described herein may support application containers that have a variety of different configurations and require a variety of updates without having to constantly create and deploy new application container images and without requiring administrators to manually apply patches and other code each time an application container is restarted.

While the foregoing disclosure sets forth various embodiments using specific block diagrams, flowcharts, and examples, each block diagram component, flowchart step, operation, and/or component described and/or illustrated herein may be implemented, individually and/or collectively, using a wide range of hardware, software, or firmware (or any combination thereof) configurations. In addition, any disclosure of components contained within other components should be considered example in nature since many other architectures can be implemented to achieve the same functionality.

In some examples, all or a portion of example system <NUM> in <FIG> may represent portions of a cloud-computing or network-based environment. Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment.

In various embodiments, all or a portion of example system <NUM> in <FIG> may facilitate multi-tenancy within a cloud-based computing environment. In other words, the modules described herein may configure a computing system (e.g., a server) to facilitate multi-tenancy for one or more of the functions described herein. For example, one or more of the modules described herein may program a server to enable two or more clients (e.g., customers) to share an application that is running on the server. A server programmed in this manner may share an application, operating system, processing system, and/or storage system among multiple customers (i.e., tenants). One or more of the modules described herein may also partition data and/or configuration information of a multi-tenant application for each customer such that one customer cannot access data and/or configuration information of another customer.

According to various embodiments, all or a portion of example system <NUM> in <FIG> may be implemented within a virtual environment. For example, the modules and/or data described herein may reside and/or execute within a virtual machine. As used herein, the term "virtual machine" generally refers to any operating system environment that is abstracted from computing hardware by a virtual machine manager (e.g., a hypervisor).

In some examples, all or a portion of example system <NUM> in <FIG> may represent portions of a mobile computing environment. Mobile computing environments may be implemented by a wide range of mobile computing devices, including mobile phones, tablet computers, e-book readers, personal digital assistants, wearable computing devices (e.g., computing devices with a head-mounted display, smartwatches, etc.), variations or combinations of one or more of the same, or any other suitable mobile computing devices. In some examples, mobile computing environments may have one or more distinct features, including, for example, reliance on battery power, presenting only one foreground application at any given time, remote management features, touchscreen features, location and movement data (e.g., provided by Global Positioning Systems, gyroscopes, accelerometers, etc.), restricted platforms that restrict modifications to system-level configurations and/or that limit the ability of third-party software to inspect the behavior of other applications, controls to restrict the installation of applications (e.g., to only originate from approved application stores), etc. Various functions described herein may be provided for a mobile computing environment and/or may interact with a mobile computing environment.

While various embodiments have been described and/or illustrated herein in the context of fully functional computing systems, one or more of these example embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable media used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using modules that perform certain tasks. These modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these modules may configure a computing system to perform one or more of the example embodiments disclosed herein.

The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the example embodiments disclosed herein. Reference should be made to the appended claims in determining the scope of the instant disclosure.

Claim 1:
A computer-implemented method for updating containers, the method being performed by a computing device comprising at least one processor, the method comprising:
configuring, at a creation of a static application container image, the static application container image with a script to scan a predetermined directory for ancillary code upon an application container being instantiated from the static application container image;
identifying the application container that is instantiated from the static application container image and that isolates a user space of an application that executes within the application container from other software on a host system while sharing a kernel space with the other software;
identifying the ancillary code that is designed to modify execution of the application executing in the application container;
packaging the ancillary code into a data volume container image to be deployed to the host system that hosts the application container;
discovering, by the application container executing the script, a pointer to a location of a data volume container instantiated from the data volume container image on the host system; and
modifying, by the application container, the execution of the application executing in the application container with the ancillary code, without modifying the static application container image, at least in part by instantiating the application container with the pointer to the location of the data volume container that contains the ancillary code.