Patent Description:
Containers are active components executing on an operating system that provide an environment for applications to run, while being isolated from any other components of a host machine, network, or data center etc. Multiple containers may execute on a single operating system kernel and share the resources of the hardware the operating system is running on. All of the files, libraries and dependencies necessary to run applications in a container may be provided by a container image(s).

The primary difference between virtual machines and containers is that the virtual machines are meant to be maintained and updated while the containers are meant to be rebuilt. However, the containers are now part of a deployment strategy and are longer lived than the short term nature they were intended for. Therefore, the more a container is kept running, the more outdated the container may become. Thus, the higher the risk that the container contains a security vulnerability. <CIT> discloses a system and method for cognitively determining updates for container based solutions.

According to a first aspect of the present invention there is provided a method as set out in independent claim <NUM>. According to a second aspect of the present invention there is provided a system as set out in independent claim <NUM>, and according to a third aspect there is provided a non-transitory computer-readable medium as set out in independent claim <NUM>.

The dependent claims define preferred embodiments.

The described embodiments and the advantages thereof may best be understood by reference to the following description taken in conjunction with the accompanying drawings. These drawings in no way limit any changes in form and detail that may be made to the described embodiments by one skilled in the art without departing from the scope of the described embodiments.

The dichotomy between virtual machines and containers is that the former are meant to be maintained and updated while the latter are meant to be rebuilt. A container may have one or more layers or image layers. When there are new versions of layers or image layers within a container, the entire container needs to be rebuilt from the ground up. However, containers are now part of a deployment strategy and are longer lived than the short term nature they were intended for. The more a container is kept running, the more outdated the container may become. Thus, the higher the risk that the container contains a security vulnerability. It is challenging to keep running the container for a long term and handles the update of the container efficiently.

There are tools such as Kubernetes™ or OpenShift™ which may help manage fleets of containers. However, these tools are expensive and designed for managing hundreds and thousands of containers from a lifecycle management perspective. In the situation there are only a small number of containers, and these containers may not be changing very often, the tools such as Kubernetes™ or OpenShift™ may not be deployed due to the high overhead. Therefore, the small number of containers have the risk of becoming out of date and containing security vulnerabilities at various layers within the container.

The present disclosure addresses the above-noted and other deficiencies by performing a rebase action to rebase image layers of a container, instead of rebuilding the entire container, in response to a new base image or a container update being available. There are mechanisms such as static analysis tools or proactive service pings to send an indication that an image update of the container is available. Once receiving the indication, the base layer of the container may be updated to create a new base layer. Then, the rebase action may be performed to the next layer, similar to that in a Git oriented world. For example, the functionality and contents of the next layer may be integrated into the new base layer to create a first level update, which is a rebased layer (the new base layer + the next layer). The rebased layer may be stored in a repository, e.g., by using a repository command , for reuse elsewhere in the computing system. The same procedure may be repeated for the following layers to create more rebased layers. The rebased layers, which are the integration or combination of the new base layer with one or more layers, may be stored in the repository to be reused to update other containers in the computing system. To update other containers, which may have the same layers within which the same services may execute, need update, the stored rebased layers may be retrieved from the repository and reused. In this way, the computational overhead may be saved. The rebased layers may be saved in the local computing device instead of in the remote server, thereby the network roundtrip and the computational resources may be saved. Accordingly, the embodiments of the present disclosure reduce the amount of networking resources needed to update the containers, as well as, a decrease in network congestion and power consumption for the overall network infrastructure.

<FIG> is a block diagram that illustrates an example system <NUM>, in accordance with some embodiments of the present disclosure. As illustrated in <FIG>, the system <NUM> includes a computing device <NUM>, a registry server <NUM> and a network <NUM>. The computing device <NUM> and the registry server <NUM> may be coupled to each other (e.g., may be operatively coupled, communicatively coupled, may communicate data/messages with each other) via network <NUM>. Network <NUM> may be a public network (e.g., the internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), or a combination thereof. In one embodiment, network <NUM> may include a wired or a wireless infrastructure, which may be provided by one or more wireless communications systems, such as a WiFi™ hotspot connected with the network <NUM> and/or a wireless carrier system that can be implemented using various data processing equipment, communication towers (e.g. cell towers), etc. The network <NUM> may carry communications (e.g., data, message, packets, frames, etc.) between computing device <NUM> and registry server <NUM>. The computing device <NUM> (and registry server <NUM>) may include hardware such as processing device <NUM> (e.g., processors, central processing units (CPUs)), memory (e.g., random access memory (RAM), storage devices (e.g., hard-disk drive (HDD)), and solid-state drives (SSD), etc.), and other hardware devices (e.g., sound card, video card, etc.). A storage device may comprise a persistent storage that is capable of storing data. A persistent storage may be a local storage unit or a remote storage unit. Persistent storage may be a magnetic storage unit, optical storage unit, solid state storage unit, electronic storage units (main memory), or similar storage unit. Persistent storage may also be a monolithic/single device or a distributed set of devices.

The communication network <NUM> may be a public network (e.g., the internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), or a combination thereof. In one embodiment, communication network <NUM> may include a wired or a wireless infrastructure, which may be provided by one or more wireless communications systems, such as wireless fidelity (Wi-Fi) connectivity to the communication network <NUM> and/or a wireless carrier system that can be implemented using various data processing equipment, communication towers (e.g. cell towers), etc. The communication network <NUM> may carry communications (e.g., data, message, packets, frames, etc.) between any other the computing device.

The computing device <NUM> and registry server <NUM> may comprise any suitable type of computing device or machine that has a programmable processor including, for example, server computers, desktop computers, laptop computers, tablet computers, smartphones, set-top boxes, etc. In some examples, the computing device <NUM> and registry server <NUM> may comprise a single machine or may include multiple interconnected machines (e.g., multiple servers configured in a cluster). The computing device <NUM> and registry server <NUM> may be implemented by a common entity/organization or may be implemented by different entities/organizations. For example, computing device <NUM> may be operated by a first company/corporation and registry server <NUM> may be operated by a second company/corporation. The computing device <NUM> and registry server <NUM> may each execute or include an operating system (OS). The OSs of computing device <NUM> and registry server <NUM> may manage the execution of other components (e.g., software, applications, etc.) and/or may manage access to the hardware (e.g., processors, memory, storage devices etc.) of the computing device.

As illustrated in <FIG>, computing device <NUM> may run one or more containers, e.g., a container <NUM>. In some embodiments, the container <NUM> may execute on a container engine which may execute on top of the host operating system (OS) of computing device <NUM>. The container engine may allow different containers to share the host OS (e.g., the OS kernel, packages, binaries, libraries thereof etc.), and may also perform other functions. The container <NUM> may be isolated, in that it is not connected to any other device or component of system <NUM>, whether virtual or otherwise. The container <NUM> may execute one or more applications <NUM>. Registry server <NUM> may be a server which may store container images <NUM> (e.g., docker images). Although <FIG> illustrates only a single computing device <NUM> for ease of illustration and description, computing device <NUM> may be just one deployment among many within an overarching cloud or on-premises infrastructure that system <NUM> represents. For example, additional computing devices may be included within system <NUM> that act as additional deployments.

<FIG> is a block diagram that illustrates an example of the computing device <NUM> in <FIG>, according to some embodiments. While various devices, interfaces, and logic with particular functionality are shown, it should be understood that the computing device <NUM> includes any number of devices and/or components, interfaces, and logic for facilitating the functions described herein. For example, the activities of multiple devices may be combined as a single device and implemented on a same processing device (e.g., processing device <NUM>), as additional devices and/or components with additional functionality are included.

The computing device <NUM> includes a processing device <NUM> (e.g., general purpose processor, a PLD, etc.), which may be composed of one or more processors, and a memory <NUM> (e.g., synchronous dynamic random access memory (DRAM), read-only memory (ROM)), which may communicate with each other via a bus (not shown).

The processing device <NUM> may be provided by one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. In some embodiments, processing device <NUM> may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. In some embodiments, the processing device <NUM> may comprise one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device <NUM> may be configured to execute the operations described herein, in accordance with one or more aspects of the present disclosure, for performing the operations and steps discussed herein.

The memory <NUM> (e.g., Random Access Memory (RAM), Read-Only Memory (ROM), Non-volatile RAM (NVRAM), Flash Memory, hard disk storage, optical media, etc.) of processing device <NUM> stores data and/or computer instructions/code for facilitating at least some of the various processes described herein. The memory <NUM> includes tangible, non-transient volatile memory, or non-volatile memory. The memory <NUM> stores programming logic (e.g., instructions/code) that, when executed by the processing device <NUM>, controls the operations of the computing device <NUM>. In some embodiments, the processing device <NUM> and the memory <NUM> form various processing devices and/or circuits described with respect to the Computing device <NUM>. The instructions include code from any suitable computer programming language such as, but not limited to, C, C++, C#, Java, JavaScript, VBScript, Perl, HTML, XML, Python, TCL, and Basic.

The processing device <NUM> may execute the container <NUM> and a container <NUM>. In one embodiment, the container <NUM> may be an isolated set of resources allocated to executing an application, software, and/or process independent from other applications, software, and/or processes. The container <NUM> may share the OS kernel and packages (e.g., libraries, binary files and source files) of the host OS with other container executing in the computing device <NUM>. The container <NUM> may have one or more respective file systems, memories, devices, network ports, etc., for accessing the physical resources of the computing device <NUM> (e.g., processing device <NUM> and memory <NUM>).

<FIG> illustrates an example of the container <NUM> executing in the computing device <NUM> in <FIG>, in accordance with some embodiments of the present disclosure. In some embodiments, as illustrated in <FIG>, the container <NUM> or a container image of the container <NUM> may have image layers including a base layers <NUM> and one or more upper layers <NUM>, <NUM>, <NUM>. Each layer, or image layer is a change on an image, or an intermediate image. For example, a command in a Docker file may cause the previous image to change, thus creating a new layer. The term "layer" and "image layer" are used interchangeably in this disclosure. In some embodiments, the container <NUM> may have one or more layers, where each layer originates from the previous layer but is different from it. In some embodiments, a read-only layers may be shared between any container image that is started from the same image. In some embodiments, each layer may include a set of differences from the layer before it. In some embodiments, the layers may be stacked on top of each other, as illustrated in <FIG>.

Referring to <FIG>, in some embodiments, the processing device <NUM> may comprise an updating module <NUM>, rebasing module <NUM>, storing module <NUM> and retrieving module <NUM>. The processing device <NUM> is configured to receive a first indication that an image update of a container (e.g., <NUM>) is available. The container <NUM> comprises a base layer <NUM> and one or more upper layers <NUM>, <NUM>, <NUM>. The updating module <NUM> is configured to update, in response to receiving the indication, the base layer <NUM> based on the image update to create an updated base layer (not shown). The rebasing module <NUM> is configured to rebase, using the updated base layer, the one or more upper layers <NUM>, <NUM>, <NUM> to create one or more rebased upper layers (not shown). The storing module <NUM> is configured to store the one or more rebased upper layers in a repository <NUM> to be reused to update other containers, e.g., the container <NUM>. The retrieving module <NUM> is configured to retrieve the one or more rebased upper layers from the repository <NUM>. The repository <NUM> may include a Git repository, an Ostree repository, or another type of repository. The Git repository and the Ostree repository are just examples of the repository <NUM>. There are other types of repositories which may perform the similar functions as the Git repository or the Ostree repository.

The computing device <NUM> includes a network interface <NUM> configured to establish a communication session with a computing device for sending and receiving data over the communication network <NUM> to the computing device. Accordingly, the network interface <NUM> includes a cellular transceiver (supporting cellular standards), a local wireless network transceiver (supporting <NUM>. 11X, ZigBee, Bluetooth, Wi-Fi, or the like), a wired network interface, a combination thereof (e.g., both a cellular transceiver and a Bluetooth transceiver), and/or the like. In some embodiments, the computing device <NUM> includes a plurality of network interfaces <NUM> of different types, allowing for connections to a variety of networks, such as local area networks (public or private) or wide area networks including the Internet, via different sub-networks.

The computing device <NUM> includes an input/output device <NUM> configured to receive user input from and provide information to a user. In this regard, the input/output device <NUM> is structured to exchange data, communications, instructions, etc. with an input/output component of the computing device <NUM>. Accordingly, input/output device <NUM> may be any electronic device that conveys data to a user by generating sensory information (e.g., a visualization on a display, one or more sounds, tactile feedback, etc.) and/or converts received sensory information from a user into electronic signals (e.g., a keyboard, a mouse, a pointing device, a touch screen display, a microphone, etc.). The one or more user interfaces may be internal to the housing of computing device <NUM>, such as a built-in display, touch screen, microphone, etc., or external to the housing of computing device <NUM>, such as a monitor connected to computing device <NUM>, a speaker connected to computing device <NUM>, etc., according to various embodiments. In some embodiments, the computing device <NUM> includes communication circuitry for facilitating the exchange of data, values, messages, and the like between the input/output device <NUM> and the components of the computing device <NUM>. In some embodiments, the input/output device <NUM> includes machine-readable media for facilitating the exchange of information between the input/output device <NUM> and the components of the computing device <NUM>. In still another embodiment, the input/output device <NUM> includes any combination of hardware components (e.g., a touchscreen), communication circuitry, and machine-readable media.

The computing device <NUM> includes a device identification component <NUM> (shown in <FIG> as device ID component <NUM>) configured to generate and/or manage a device identifier associated with the computing device <NUM>. The device identifier may include any type and form of identification used to distinguish the computing device <NUM> from other computing devices. In some embodiments, to preserve privacy, the device identifier may be cryptographically generated, encrypted, or otherwise obfuscated by any device and/or component of Computing device <NUM>. In some embodiments, the computing device <NUM> may include the device identifier in any communication (e.g., a registry image request, application file request, application image request, etc.) that the computing device <NUM> sends to a computing device.

The computing device <NUM> includes a bus (not shown), such as an address/data bus or other communication mechanism for communicating information, which interconnects the devices and/or components of computing device <NUM>, such as processing device <NUM>, network interface <NUM>, input/output device <NUM>, device ID component <NUM>, and application development component <NUM>.

In some embodiments, some or all of the devices and/or components of computing device <NUM> may be implemented with the processing device <NUM>. For example, the computing device <NUM> may be implemented as a software application stored within the memory <NUM> and executed by the processing device <NUM>. Accordingly, such embodiment can be implemented with minimal or no additional hardware costs. In some embodiments, any of these above-recited devices and/or components rely on dedicated hardware specifically configured for performing operations of the devices and/or components.

<FIG> is a block diagram that illustrates an example of rebasing one or more image layers of containers <NUM>, <NUM> in the computing device <NUM> in <FIG>, in accordance with some embodiments of the present disclosure. <FIG> is a block diagram that illustrates an example of a process of rebasing the one or more image layers of containers <NUM>, <NUM> in the computing device <NUM> in <FIG>, in accordance with some embodiments of the present disclosure. Referring to <FIG> and <FIG>, the containers <NUM>, <NUM> may be executing in the computing devise <NUM>. Containers are based on layers or image layers. Each of the containers <NUM>, <NUM> may have a base layer and one or more layers or upper layers. For example, the container <NUM> may have a base layer <NUM> and one or more layers <NUM>, <NUM>, <NUM> on top of the base layer <NUM>; the container <NUM> may have a base layer <NUM> and one or more layers <NUM>, <NUM>, <NUM> on top of the base layer <NUM>. Although two containers are illustrated in <FIG> and <FIG>, the computing device <NUM> may execute any number of containers, such as a small number of containers, hundreds of containers, or only one container.

There are mechanisms such as static analysis tools or proactive service pings to determine when an image update <NUM> (e.g., a new base image or a container update) of the container <NUM> is available and send an indication <NUM> that the image update <NUM> is available. As illustrated in <FIG>, the processing device <NUM> receives the indication <NUM> that the image update <NUM> of the container <NUM> is available.

In response to the image update <NUM> of the container <NUM> being available, a rebase action may be performed to rebase layers (or upper image layers) <NUM>, <NUM>, <NUM> of the container <NUM>. Once the processing device <NUM> receiving the indication <NUM> that the image update <NUM> is available, the processing device <NUM> updates the base layer <NUM> of the container <NUM> to create an updated base layer <NUM>, as illustrated in <FIG>.

Referring to <FIG>, the processing device <NUM> rebases, using the updated base layer <NUM>, the one or more upper layers <NUM>, <NUM>, <NUM> to create one or more rebased first layers <NUM>, <NUM>, <NUM>. After updating the base layer <NUM> to create the updated base layer <NUM>, the rebasing action may be performed to the layer <NUM> (the next layer). For example, the processing device <NUM> may integrate the layer <NUM> and the updated base layer <NUM> to form an entirely new layer <NUM>, which is the updated base layer <NUM> plus the layer <NUM>. The functionality and contents of the layer <NUM> may be integrated into the updated base layer <NUM> to create the rebased layer <NUM>, which is the first level rebasing. The first level rebasing may include a combination of the updated base layer <NUM> and the layer <NUM>.

After the first level rebasing, the layer <NUM> may be integrated with the rebased layer <NUM> to form a rebased layer <NUM>, which is the second level rebasing. In another embodiment, the layer <NUM> may be integrated with the updated base layer <NUM> to form a rebased layer <NUM> (not shown).

For a third level rebasing, in one embodiment, upon request, the layer <NUM> may be integrated with the updated base layer <NUM>, skipping other rebased layers, to form a rebased layer <NUM>, which is the third level rebasing, as illustrated in <FIG>. In another embodiment, the layer <NUM> may be integrated with the rebased layer <NUM> to form a new rebased layer (not shown). In yet another embodiment, the layer <NUM> may be integrated with the rebased layer <NUM> to form a new rebased layer (not shown).

Referring to <FIG> and <FIG>, the rebasing action may be performed by using a repository command (e.g., a Git command, an Ostree command, etc.). The repository command may be used to track changes and merge changes. The repository command may capture a snapshot of a project's currently staged changes. The repository command may be used to create a snapshot of a rebased layer. The repository command may be used to save the rebased layer to the local repository <NUM>.

As illustrated in <FIG>, at the first level rebasing, the layer <NUM> is integrated with the updated base layer <NUM> to form the rebased layer <NUM>, thus, a repository command 411may be used to create a snapshot of the rebased layer <NUM> (the layer <NUM> + the updated base layer <NUM>). At the second level rebasing, the layer <NUM> is integrated with the updated base layer <NUM> to form the rebased layer <NUM>, and a repository command <NUM> may be used to create a snapshot of the rebased layer <NUM> (the layer <NUM> + the rebased layer <NUM>). At the third level rebasing, the layer <NUM> is integrated with the updated base layer <NUM>, to form a rebased layer <NUM>, and a repository command <NUM> may be used to create a snapshot of the rebased layer <NUM> (the layer <NUM> + the updated base layer <NUM>). By using the repository commands, three distinct snapshots are created in a single repository <NUM>. The three distinct snapshots include the repository command <NUM> of the rebased layer <NUM> (the layer <NUM> + the updated base layer <NUM>), the repository command <NUM> of the rebased layer <NUM> (the layer <NUM> + the layer <NUM> + the updated base layer <NUM>) and the repository command <NUM> of the rebased layer <NUM> (the layer <NUM> + the updated base layer <NUM>).

By using the repository commands, snapshots of rebased layers of different combinations, such as the combination of the layer <NUM> + the updated base layer <NUM>, the combination of the layer <NUM> + the layer <NUM> + the updated base layer <NUM>, and the combination of the layer <NUM> + the updated base layer <NUM>, may be created and saved in the repository <NUM>. Each combination of the different combinations only needs to be created once, and may be reused to update another container.

Referring to <FIG> and <FIG>, the processing device <NUM> stores the one or more rebased first layers <NUM>, <NUM>, <NUM> in the repository <NUM> in the memory <NUM>, e.g., by using the repository commands. Each rebased layer may be associated with a unique identifier or a tag. Each Commit may be associated with a message to indicate the unique identifier or the tag. The one or more rebased layers <NUM>, <NUM>, <NUM> in the repository <NUM> may be reused to update another container. The rebased layers <NUM>, <NUM>, <NUM> may be stored in the repository <NUM>, e.g., by using the repository command, for reuse elsewhere in the computing device <NUM>. The same procedure may be repeated for the following layers to create more rebased layers. The rebased layers, which are the integration or combination of the new base layer with one or more previous layers, may be stored in the repository t230 to be reused to update other containers in the computing device <NUM>.

To update other containers, which may have the same layers within which the same services may execute, the stored rebased layers may be retrieved from the repository and reused. As illustrated in <FIG>, after the container <NUM> being updated and rebased, the rebased layers <NUM>, <NUM>, <NUM> are saved in the repository <NUM>. When the container <NUM> needs to be updated, instead of redoing the updating and rebasing all over again, the stored rebased layer <NUM> may be retrieved from the repository <NUM> and reused to update the container <NUM>.

When the processing device <NUM> may receive an indication that the image update of the container <NUM> is available, the processing device <NUM> may determine whether there is the at least one rebased layer in the repository which can be reused to update the container <NUM>. The container <NUM> may have the base layer <NUM> and one or more upper layers <NUM>, <NUM>, <NUM>.

When the computing device <NUM> runs a number of containers, some of the containers may share the same base layer and one or more same upper layers. The container <NUM> may share the same base layer <NUM> and the layer <NUM> with the container <NUM>. As there is the repository command <NUM> for the rebased layer <NUM> (the layer <NUM> + the updated base layer <NUM>), the rebased layer <NUM> may be shared between the container <NUM> and the container <NUM>. The processing device <NUM> may determine that there is at least one rebased layer <NUM> in the repository to be reused to update the container <NUM>. The at least one rebased layer integrating the layer <NUM> and the updated base layer <NUM> matches the rebased layer <NUM> in the repository <NUM>, where the layer <NUM> is shared between the container <NUM> and the container <NUM>, thus the layer <NUM> of the container <NUM> is the same as the layer <NUM> of the container <NUM>.

As illustrated in <FIG>, the processing device <NUM> may retrieve the rebased layer <NUM> from the repository <NUM>, for example, by using a repository command <NUM>. The processing device <NUM> may pull the rebased layer <NUM> from the repository <NUM>, and therefore save the computational time. The rebased layer <NUM> may be associated with a unique identifier or a tag. The rebased layer <NUM> may be retrieved by using the repository command <NUM> based on the unique identifier or the tag of the rebased layer <NUM>. The processing device <NUM> may update the layer <NUM> based on the rebased layer <NUM> retrieved from the repository. The processing device <NUM> may just use the rebased layer <NUM> retrieved from the repository, instead of going through the process of updating the base later <NUM> and rebasing the layer <NUM>.

Next, the processing device <NUM> may rebase the layer <NUM> by integrating the layer <NUM> with the rebased layer <NUM> to create a rebased layer <NUM>. A repository command <NUM> may be used to store the rebased layer <NUM> in the repository <NUM>. Then, the processing device <NUM> may rebase the layer <NUM> by integrating the layer <NUM> with the rebased layer <NUM> to create a rebased layer <NUM>. A repository command <NUM> may be used to store the rebased layer <NUM> in the repository <NUM>. In another embodiment, the rebased layer <NUM> may be already stored in the repository <NUM>, due to updating a different container, thus, the rebased layer <NUM> may be retrieved from the repository and stitched together with the rebased layer <NUM>.

Similarly, if there is another container (not shown) having the base layer <NUM>, the layer <NUM>, the layer <NUM>, and other layers, the rebased layer <NUM> may be pulled from the repository and reused to update the another container, since the rebased layer <NUM> has already exist in the repository. The rebased layer <NUM> has already stored in the repository <NUM> by the repository command <NUM>.

In this way, individual commits (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) are created to integrate different layers to form rebased layers in real time. Thus, the containers (e.g., <NUM>, <NUM>) are updated by rebasing the layers or selected layers instead of rebuilding the entire containers. This approach may be used to enhance a tool such as Podman with functionality that can react to a new base image or container being updated. This approach may also be integrated with Kubernetes™ or OpenShift™. The rebased layers may include different combinations of the layers. The different combinations of the layers may be stored in the repository to be reused to update other containers. By this approach, the computational overhead may be saved. The rebased layers including the different combinations of the layers may be saved in the local computing device instead of in the remote server, thereby the network roundtrip and the computational resources may be saved. Accordingly, the embodiments of the present disclosure reduce the amount of networking resources needed to update the containers, as well as, a decrease in network congestion and power consumption for the overall network infrastructure.

<FIG> and <FIG> are flow diagrams of a method <NUM> of rebasing one or more image layers of containers, in accordance with some embodiments of the present disclosure. Method <NUM> may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, a processor, a processing device, a central processing unit (CPU), a system-on-chip (SoC), etc.), software (e.g., instructions running/executing on a processing device), firmware (e.g., microcode), or a combination thereof. In some embodiments, method <NUM> may be performed by the processing device <NUM> in the computing device <NUM> in <FIG>.

With reference to <FIG> and <FIG>, method <NUM> illustrates example functions used by various embodiments. Although specific function blocks ("blocks") are disclosed in method <NUM>, such blocks are examples. That is, embodiments are well suited to performing various other blocks or variations of the blocks recited in method <NUM>. It is appreciated that the blocks in method <NUM> may be performed in an order different than presented, and that not all of the blocks in method <NUM> may be performed.

As shown in <FIG>, the method <NUM> includes the block <NUM> of receiving a first indication that an image update of a first container is available, the first container comprising a base layer and one or more first layers. The method <NUM> includes the block <NUM> of updating, in response to receiving the first indication, the base layer based on the image update to create an updated base layer. The method <NUM> includes the block <NUM> of rebasing, by a processing device, using the updated base layer, the one or more first layers to create one or more rebased first layers. The method <NUM> includes the block <NUM> of storing the one or more rebased first layers in a repository to be reused to update a second container.

In some embodiments, the rebasing the one or more first layers further comprises integrating each first layer of the one or more first layers with the updated base layer to create a respective rebased first layer. In some embodiments, the rebasing the one or more first layers further comprises integrating each first layer with at least one rebased first layer of a previous layer to create the respective rebased first layer, and wherein each rebased first layer comprises an integration of a first layer, the at least one rebased first layer of the previous layer and the updated base layer. In some embodiments, a repository command is used to store the one or more rebased first layers in the repository. In some embodiments, each rebased first layer of the one or more rebased first layers is associated with a unique identifier.

As shown in <FIG>, the method <NUM> may further include the block <NUM> of receiving a second indication that an image update of the second container is available, the second container comprising the base layer and one or more second layers. The method <NUM> may further include the block <NUM> of determining that there is the at least one rebased second layer in the repository, where the at least one rebased second layer matches at least one rebased first layer, and where the at least one rebased second layer corresponds to at least one second layer being the same as at least one first layer. The method <NUM> may further include the block <NUM> of retrieving the at least one rebased first layer from the repository. The method <NUM> may further include the block <NUM> of updating the at least one second layer based on the at least one rebased first layer retrieved from the repository.

<FIG> is a block diagram of an example computing device <NUM> that may perform one or more of the operations described herein, in accordance with some embodiments. Computing device <NUM> may be connected to other computing devices in a LAN, an intranet, an extranet, and/or the Internet. The computing device may operate in the capacity of a server machine in client-server network environment or in the capacity of a client in a peer-to-peer network environment. The computing device may be provided by a personal computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single computing device is illustrated, the term "computing device" shall also be taken to include any collection of computing devices that individually or jointly execute a set (or multiple sets) of instructions to perform the methods discussed herein.

The example computing device <NUM> may include a processing device (e.g., a general purpose processor, a PLD, etc.) <NUM>, a main memory <NUM> (e.g., synchronous dynamic random access memory (DRAM), read-only memory (ROM)), a static memory <NUM> (e.g., flash memory and a data storage device <NUM>), which may communicate with each other via a bus <NUM>.

Processing device <NUM> may be provided by one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. In an illustrative example, processing device <NUM> may comprise a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. Processing device <NUM> may also comprise one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device <NUM> may be configured to execute the operations described herein, in accordance with one or more aspects of the present disclosure, for performing the operations and steps discussed herein.

Computing device <NUM> may further include a network interface device <NUM> which may communicate with a communication network <NUM>. The computing device <NUM> also may include a video display unit <NUM> (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device <NUM> (e.g., a keyboard), a cursor control device <NUM> (e.g., a mouse) and an acoustic signal generation device <NUM> (e.g., a speaker). In one embodiment, video display unit <NUM>, alphanumeric input device <NUM>, and cursor control device <NUM> may be combined into a single component or device (e.g., an LCD touch screen).

Data storage device <NUM> may include a computer-readable storage medium <NUM> on which may be stored one or more sets of instructions <NUM> that may include instructions for one or more components and/or applications <NUM> (e.g., container <NUM>, container <NUM>, updating module <NUM>, rebasing module <NUM>, storing module <NUM> and retrieving module <NUM> in <FIG>) for carrying out the operations described herein, in accordance with one or more aspects of the present disclosure. Instructions <NUM> may also reside, completely or at least partially, within main memory <NUM> and/or within processing device <NUM> during execution thereof by computing device <NUM>, main memory <NUM> and processing device <NUM> also constituting computer-readable media. The instructions <NUM> may further be transmitted or received over a communication network <NUM> via network interface device <NUM>.

While computer-readable storage medium <NUM> is shown in an illustrative example to be a single medium, the term "computer-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable storage medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform the methods described herein. The term "computer-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media.

Unless specifically stated otherwise, terms such as "executing," "performing," or the like, refer to actions and processes performed or implemented by computing devices that manipulates and transforms data represented as physical (electronic) quantities within the computing device's registers and memories into other data similarly represented as physical quantities within the computing device memories or registers or other such information storage, transmission or display devices. Also, the terms "first," "second," "third," "fourth," etc., as used herein are meant as labels to distinguish among different elements and may not necessarily have an ordinal meaning according to their numerical designation.

Examples described herein also relate to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computing device selectively programmed by a computer program stored in the computing device. Such a computer program may be stored in a computer-readable non-transitory storage medium.

The methods and illustrative examples described herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used in accordance with the teachings described herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear as set forth in the description above.

The above description is intended to be illustrative, and not restrictive. Although the present disclosure has been described with references to specific illustrative examples, it will be recognized that the present disclosure is not limited to the examples described. The dependent claims define preferred embodiments.

It will be further understood that the terms "comprises", "comprising", "includes", and/or "including", when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Therefore, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

Although the method operations were described in a specific order, it should be understood that other operations may be performed in between described operations, described operations may be adjusted so that they occur at slightly different times or the described operations may be distributed in a system which allows the occurrence of the processing operations at various intervals associated with the processing.

Various units, circuits, or other components may be described or claimed as "configured to" or "configurable to" perform a task or tasks. In such contexts, the phrase "configured to" or "configurable to" is used to connote structure by indicating that the units/circuits/components include structure (e.g., circuitry) that performs the task or tasks during operation. As such, the unit/circuit/component can be said to be configured to perform the task, or configurable to perform the task, even when the specified unit/circuit/component is not currently operational (e.g., is not on). The units/circuits/components used with the "configured to" or "configurable to" language include hardware--for example, circuits, memory storing program instructions executable to implement the operation, etc. Reciting that a unit/circuit/component is "configured to" perform one or more tasks, or is "configurable to" perform one or more tasks, is expressly intended not to invoke <NUM> U. §<NUM>, sixth paragraph, for that unit/circuit/component. Additionally, "configured to" or "configurable to" can include generic structure (e.g., generic circuitry) that is manipulated by software and/or firmware (e.g., an FPGA or a general-purpose processor executing software) to operate in manner that is capable of performing the task(s) at issue. "Configured to" may also include adapting a manufacturing process (e.g., a semiconductor fabrication facility) to fabricate devices (e.g., integrated circuits) that are adapted to implement or perform one or more tasks. "Configurable to" is expressly intended not to apply to blank media, an unprogrammed processor or unprogrammed generic computer, or an unprogrammed programmable logic device, programmable gate array, or other unprogrammed device, unless accompanied by programmed media that confers the ability to the unprogrammed device to be configured to perform the disclosed function(s).

Claim 1:
A method comprising:
receiving a first indication that an image update of a first container (<NUM>) is available, the first container (<NUM>) comprising a base layer (<NUM>) and a first layer (<NUM>); characterized by
updating, in response to receiving the first indication, the base layer (<NUM>) based on the image update to create an updated base layer;
rebasing, by a processing device (<NUM>) using the updated base layer, the first layer (<NUM>) to create a rebased first layer; and
storing the rebased first layer in a repository (<NUM>) to be reused to update a second container (<NUM>).