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). A container image may be comprised of a set of base layers that define the runtime environment, as well as the packages and utilities necessary for a containerized application to run. A container may include the base layers from a container image as well as an in-memory layer in which the containerized application may write/modify data. <CIT> discloses a containerized application system graph driver.

According to the present invention, there is provided a method in accordance with any of accompanying Claims <NUM> to <NUM>.

In a second aspect of the present invention a system is provided in accordance with any of accompanying Claims <NUM> to <NUM>.

In a further aspect of the present invention we provide a computer-readable medium having instructions stored thereon which, when executed by a processing device, cause the processing device to perform the above described method.

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 spirit and scope of the described embodiments.

A container image must be fetched (e.g., from a registry server) and stored locally in e.g., a container engine before a container can be created based on it. A file system in user space (FUSE) allows for a container to be started before the underlying image is fully fetched locally. The FUSE will intercept any request from the container to access files of the container image and/or open/write files, and fetch the requested files/open the requested files on demand. Until the file is fetched from the remote registry server, the request will be blocked by the FUSE. Normally, the higher level logic of a file system is implemented in the kernel, which allows for speed and efficient use of system resources. However, all of the higher level logic (e.g., primitives for interacting with the registry server, authentication etc.) of the FUSE is implemented in user space.

File systems implemented in user space are slower and require additional resources compared to file systems implemented in the kernel. This is because each request from the requesting process must still go through the kernel, which sends the request to the process running the FUSE. The process running the FUSE then sends the requested file(s) back to the kernel, which sends the request back to the requesting process. The extra step of sending the request to the process running the FUSE and receiving a reply back at the kernel requires additional time and resources. Because of this, for container images that are retrieved on demand using the lazy pull technique, there is a cost in resources even after the container image is fully fetched locally because all file requests must continue to go through the FUSE.

The present disclosure addresses the above-noted and other deficiencies by using a hybrid approach, wherein the FUSE is utilized to lazy pull the container image, and manages file requests while the container image is being fetched locally. Once the container image is fully fetched locally, the overlay structure of the container image expected by a file system in the kernel (e.g., Overlay FS) is created and control is passed to the file system in the kernel. Aa processing device is used to retrieve, by a file system in user space (FUSE), a plurality of files corresponding to a container image. The FUSE may be mounted on a FUSE mount point that overlays an empty mount point (i.e., has no directories). The FUSE mount point and the empty mount point may be combined into a single mount point by an Overlay file system (Overlay FS). The plurality of files are used by the FUSE to build, in the empty mount point, one or more base layers for running a container. During the retrieving, the FUSE receives from the container, one or more file requests, and may temporarily block each of the one or more file requests until it can process them. Stated differently, the FUSE acts as a proxy between the container and the container image. In response to determining that all of the plurality of files have been retrieved or requested, the FUSE processes any outstanding file requests and instruct the mount point to run the container using the one or more base layers created. The FUSE may then unmount itself, to thereby expose the container to the underlying mount point.

<FIG> is a block diagram that illustrates an example system <NUM>. 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> are 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>) include hardware such as processing device <NUM> (e.g., processors, central processing units (CPUs)), memory <NUM> (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.

<FIG> and the other figures may use like reference numerals to identify like elements. A letter after a reference numeral, such as "110A," indicates that the text refers specifically to the element having that particular reference numeral. A reference numeral in the text without a following letter, such as "<NUM>," refers to any or all of the elements in the figures bearing that reference numeral.

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), as discussed in more detail below. 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> runs a container <NUM>. In some embodiments, the container <NUM> may execute on a container engine (shown in <FIG>) which may execute on top of the host OS <NUM> of computing device <NUM>, as discussed in more detail below. The container engine may allow different containers to share the host OS <NUM> (e.g., the OS kernel, packages, binaries, libraries thereof etc.), and may also perform other functions as discussed in more detail below. 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. Container <NUM> may execute application <NUM>. Registry server <NUM> is a server which may store container images (e.g., docker images), as discussed in further detail herein. 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 the container <NUM> of <FIG> executing within computing device <NUM>, in accordance with some embodiments of the present disclosure. 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 host OS <NUM> may use namespaces to isolate the resources of containers from each other. In another embodiment, the container <NUM> may be a virtualized object similar to a virtual machine. However, the container <NUM> may not implement a separate guest OS. The container <NUM> may share the OS kernel and packages (e.g., libraries, binary files and source files) of the host OS <NUM> with other containers (not shown) that are executing on the computing device <NUM>. Although <FIG> illustrates one container <NUM>, the computing device <NUM> may include multiple containers in other embodiments. Each container 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>, shown in <FIG>).

In some embodiments, the container engine <NUM> may allow different containers to share the host OS <NUM> (including e.g., the OS kernel as well as packages including any associated libraries, binary and/or source files etc.) of the computing device <NUM>. For example, the container engine <NUM> may multiplex the packages of the host OS <NUM> between multiple containers. The container engine <NUM> may also facilitate interactions between the container <NUM> and the resources of the computing device <NUM>. For example, the container engine <NUM> may manage requests from container <NUM> to access a memory (e.g., a RAM) of the computing device <NUM>. In another example, the container engine <NUM> may manage requests from the container <NUM> to access certain packages of the host OS <NUM>. The container engine <NUM> may also create, remove, and manage containers. In one embodiment, the container engine <NUM> may be a component of the host operating system <NUM> (e.g., Red Hat™ Enterprise Linux). In another embodiment, container engine <NUM> may run on top of the host OS <NUM>, or may run directly on host hardware without the use of the host OS <NUM>. In yet other embodiments, container engine <NUM> may be a component of a network virtualization platform (not shown), such as the RedHat™ OpenStack™ platform for example, that runs on host OS <NUM>. Container engine <NUM> may include software or logic to build a container using a container image such as a docker file.

As illustrated in <FIG>, application <NUM> may execute within the container <NUM>. For example, the application <NUM> may execute within a runtime environment (not shown in the figures) of the container <NUM>. Both the container <NUM> and the application <NUM> may be created by the host OS <NUM> (e.g., via container engine <NUM>). The host OS <NUM>, via the computing device <NUM> may provide administrators and users with the capability to configure and deploy a variety of applications and/or network functions within containers.

Container engine <NUM> may provide an image-based deployment module for creating containers and may store one or more container images (referred to herein as "container images") for creating container instances. In some embodiments, the container images may be stored in registry server <NUM> (e.g., after being generated by a developer or vendor). Each container image includes a series of layers, which may be combined into a single image as discussed in further detail herein.

The host OS <NUM> may allow file systems on different partitions and removable devices (CDs, DVDs, or USB flash drives for example) to be attached to a certain point (a mount point) in the directory tree, and then detached again. Container engine <NUM> may include a file system such as the Overlay file system (referred to in <FIG> as Overlay FS 222A), which may combine multiple different underlying mount points into a single mount point, resulting in a single directory structure that contains underlying files and sub-directories from various sources. For example, Overlay FS 222A may generate a container by allowing a read-write (e.g. in-memory) layer to be overlaid on top of one or more read-only layers (e.g., the one or more base layers of a container image). Changes (e.g., data to be written) made by the container (or a process thereof) are recorded in the upper-most layer (e.g., the in-memory layer), while the lower layer(s) (e.g., base layers) remain unmodified. In this way, multiple containers may share a container image that includes base layers that are read-only. The higher level logic of the overlay FS 222A may be implemented in the kernel.

<FIG> illustrates an example container image <NUM> that the container <NUM> may be generated from using the overlay FS 222A. The container image <NUM> is stored by the container engine <NUM> illustrated in <FIG> or registry server <NUM> illustrated in <FIG>. In some embodiments, as illustrated in <FIG>, container image <NUM> may include base layers <NUM> and <NUM>. Container image <NUM> may be shared by multiple containers. When the container engine <NUM> (via Overlay FS 222A) creates a new container, it adds a new writable (e.g., in-memory) layer on top of the underlying base layers <NUM> and <NUM>. This new writable layer is illustrated as the in-memory layer <NUM> in <FIG>. When the container is deleted, the in-memory layer <NUM> is also deleted. However, the underlying container image <NUM> remains unchanged. Although illustrated as having two base layers for simplicity, container image <NUM> may include any suitable number of base layers. Base layers may define the runtime environment as well as the packages and utilities necessary for a containerized application to run. In the example of <FIG>, base layer <NUM> may comprise the host OS <NUM> (including e.g., the OS kernel as well as the packages of the host OS <NUM> including any associated libraries, binary and/or source files etc.), on which the application <NUM> may run. The base layer <NUM> may comprise the application itself including any packages and utilities necessary for the application <NUM> to run. Thus, base layers <NUM> and <NUM> may each comprise static snapshots of the container <NUM>'s configuration and may be read-only layers that are never modified. Any changes (e.g., data to be written by the application <NUM>) may be implemented in subsequent (upper) layers such as in-memory layer <NUM>. Changes made in the in-memory layer <NUM> may be saved by creating a new layered image.

The container engine <NUM> further comprises a file system in user space (FUSE) whose higher level logic may be implemented in user-space and may allow non-privileged users to create their own file systems without editing the code of the kernel. This is achieved by running the file system code in user space while a FUSE module provides a "bridge" to the actual kernel interfaces. The FUSE allows the container engine <NUM> to perform a "lazy image pull" where a container is created before a container image the container is to be based on is locally available (e.g., stored within the overlay FS 222A). The container image is loaded on demand when the container wants to access the container image. As discussed, traditional methods of performing a lazy image pull require the FUSE to exist for the lifetime of the container, even after the container image is fully fetched locally.

<FIG> and <FIG> illustrate the system <NUM> in accordance with some embodiments of the present disclosure. In response to a request to create a container by "lazy pulling" container image <NUM>, the container engine <NUM> (via the overlay FS 222A) creates a container process (illustrated as container <NUM>) and an empty overlay mount point (e.g., having empty directories, or layers), hereinafter referred to as and shown in <FIG> as "overlay mount <NUM>. " More specifically, the overlay mount <NUM> has a container file system with a number of empty layers (not shown) mounted to it, the empty layers include one or more lower layers within which base layers of the container image <NUM> are built as well as an upper (write) layer. On top of the overlay mount <NUM>, the container engine <NUM> (via the overlay FS 222A) creates (overlay) a FUSE mount point (hereinafter referred to as and shown in <FIG> as "FUSE mount <NUM>") where a FUSE (illustrated as FUSE 222B) is mounted. It should be noted that the overlay FS 222A may combine the FUSE mount <NUM> and the overlay mount <NUM> into a single mount point as discussed hereinabove. The higher level logic of the FUSE 222B may be implemented in user-space.

The FUSE 222B begins fetching the files that the container image <NUM> is comprised of from the registry server <NUM> as a background process in order to build (the base layers of) the container image <NUM> locally (e.g., within the currently empty lower layers of the overlay mount <NUM>). This is desirable as the higher level logic for retrieving container images is ideally located in user-space. While fetching the container image <NUM>, the FUSE 222B acts as a proxy between the container <NUM> and the underlying container image <NUM>. In this way, while the container image <NUM> is not fully built locally, the FUSE 222B manages requests from the container <NUM> to access files. To handle pending file requests, in some embodiments, the FUSE 222B emulates the overlay mount <NUM> so if the container <NUM> wishes to write a file, the FUSE 222B writes the file in the upper (write) layer at the appropriate location, or it may attempt to write to the overlay mount <NUM> through the overlay FS 222A.

More specifically, upon receiving a request from the container <NUM> to access a file, the FUSE 222B determines whether the requested file is one of the files that the container image <NUM> is comprised of, and if so determines whether the requested file has already been fetched from the registry server <NUM> and locally stored. If the FUSE 222B determines that the requested file is part of the container image <NUM> and has been locally stored, then it retrieves the file from the overlay mount <NUM> and provide it to the container <NUM>. If the FUSE 222B determines that the requested file is part of the container image <NUM> and that it has not been locally stored, it fetches the requested file from the registry server <NUM> and stores it in the overlay mount <NUM> (e.g., within the appropriate base layer being constructed in the overlay mount <NUM>). Once the requested file(s) has been written to the overlay mount <NUM>, the FUSE 222B provides it to the container <NUM>. If the FUSE 222B determines that the requested file is not part of the container image <NUM>, the FUSE 222B determines that the container wants to create a new file. Thus, the FUSE 222B creates an empty file in the upper (write) layer of the overlay mount <NUM>. While there are no active requests for files from the container <NUM>, the FUSE 222B continous fetching the files that the container image <NUM> is comprised of and storing them locally to build the base layers for the container image <NUM> within the overlay mount <NUM>.

Once the FUSE 222B determines that all of the files that the container image <NUM> is comprised of have been retrieved or requested, it processes any pending file requests as described above, thereby resulting in the entire container image <NUM> being locally stored. At this point, the base layers of container image <NUM> (i.e., a set of underlying directories corresponding to the container image <NUM>) are built in the overlay mount <NUM> and the FUSE 222B instructs the overlay mount <NUM> to use the underlying base layers to run the container <NUM>. At the same time, the FUSE 222B may unmount itself (i.e., detach itself from the file system view), so that the container <NUM> may be exposed to the underlying overlay mount <NUM> which now comprises the complete base layers of the container image <NUM>.

More specifically, the FUSE 222B may bind-mount on top of itself, the underlying overlay FS 222A. The FUSE 222B may fork a new process (not shown) which may join the container mount namespace. The new process may move or bind-mount every mount point that exists on top of the FUSE mount <NUM> (i.e., the current root file system of the container <NUM>) (e.g., sysfs for /sys, procfs for /proc, and every volume bind mount) under the overlay mount <NUM> (e.g., if the overlay mount <NUM> is mounted at rootfs/tmp/underlying-overlay, then /sys from the FUSE mount <NUM> is moved to /tmp/underlying-overlay/sys, and so on for each additional mount that exists on the FUSE mount <NUM>). The overlay mount <NUM> itself, which also exists on top of the FUSE mount <NUM>, is not moved. The new process may use a system call (e.g., syscall pivot_root(<NUM>)) to switch to the overlay mount <NUM>, at which point the overlay mount <NUM> may become the root file system of the container <NUM> (i.e., for the entire container mount namespace). The FUSE 222B may continue working in the background as a proxy for the overlay mount <NUM> until the plurality of files corresponding to the container image <NUM> are referenced by processes in the container <NUM>. Once there are no more files referenced in the FUSE 222B, the FUSE mount <NUM> is unmounted and the FUSE 222B terminates.

<FIG> is a flow diagram of a method <NUM> for performing a "lazy pull" of a container image, 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, the method <NUM> may be performed by a computing device (e.g., computing device <NUM> illustrated in <FIG> and <FIG>).

Referring simultaneously to <FIG> and <FIG> as well, the method <NUM> begins at block <NUM>, where the FUSE 222B retrieves a plurality of files corresponding to a container image to build, in a mount point implemented in an operating system kernel, one or more base layers for running a container. The FUSE 222B begins fetching the files that the container image <NUM> is comprised of from the registry server <NUM> as a background process in order to build (the base layers of) the container image <NUM> locally (e.g., within the currently empty lower layers of the overlay mount <NUM>). This is desirable as the higher level logic for retrieving container images is ideally located in user-space. While fetching the container image <NUM>, the FUSE 222B acts as a proxy between the container <NUM> and the underlying container image <NUM>. In this way, at block <NUM>, while the container image <NUM> is not fully built locally, the FUSE 222B manages requests from the container <NUM> to access files. To handle pending file requests, in some embodiments, the FUSE 222B memulates the overlay mount <NUM> so if the container <NUM> wishes to write a file, the FUSE 222B writes the file in the upper (write) layer at the appropriate location, or it may attempt to write to the overlay mount <NUM> through the overlay FS 222A.

<FIG> is a flow diagram of a method <NUM> of processing a file request by a container while retrieving a container image, 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, the method <NUM> may be performed by a computing device (e.g., computing device <NUM> illustrated in <FIG> and <FIG>).

At block <NUM>, upon receiving a request from the container <NUM> to access a file, the FUSE 222B may determine whether the requested file is one of the files that the container image <NUM> is comprised of, and if so, at block <NUM> may determine whether the requested file has already been fetched from the registry server <NUM> and locally stored. If the FUSE 222B determines that the requested file is part of the container image <NUM> and has been locally stored, then at block <NUM> it may retrieve the file from the overlay mount <NUM> and provide it to the container <NUM>. If at block <NUM> the FUSE 222B determines that the requested file has not been locally stored, then at block <NUM> it may fetch the requested file from the registry server <NUM> and store it in the overlay mount <NUM> (e.g., within the appropriate base layer being constructed in the overlay mount <NUM>). Once the requested file(s) has been written to the overlay mount <NUM>, at block <NUM> the FUSE 222B may provide it to the container <NUM>. If at block <NUM>, the FUSE 222B determines that the requested file is not part of the container image <NUM>, at block <NUM> the FUSE 222B may determine that the container wants to create a new file. Thus, the FUSE 222B may create an empty file in the upper (write) layer of the overlay mount <NUM>. While there are no active requests for files from the container <NUM>, the FUSE 222B may continue fetching the files that the container image <NUM> is comprised of and storing them locally to build the base layers for the container image <NUM> within the overlay mount <NUM>.

Referring back to <FIG>, at block <NUM>, once the FUSE 222B determines that all of the files that the container image <NUM> is comprised of have been retrieved or requested, it processes any pending file requests as described above at block <NUM>, thereby resulting in the entire container image <NUM> being locally stored. At this point, the base layers of container image <NUM> (i.e., a set of underlying directories corresponding to the container image <NUM>) are built in the overlay mount <NUM> and at block <NUM>, the FUSE 222B instructs the overlay mount <NUM> to use the underlying base layers to run the container <NUM>. At the same time, the FUSE 222B may unmount itself (i.e., detach itself from the file system view), so that the container <NUM> may be exposed to the underlying overlay mount <NUM> which now comprises the complete base layers of the container image <NUM>.

<FIG> illustrates a diagrammatic representation of a machine in the example form of a computer system <NUM> within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein for performing a lazy pull of a container image. In some embodiments, the machine retrievea, by a file system in user space (FUSE), a plurality of files corresponding to a container image. The FUSE is mounted on a FUSE mount point that overlays an empty mount point (i.e., has no directories). The FUSE mount point and the empty mount point may be combined into a single mount point by an Overlay file system (Overlay FS). The plurality of files are used by the FUSE to build, in the empty mount point, one or more base layers for running a container. During the retrieving, the FUSE may receive from the container, one or more file requests, and may temporarily block each of the one or more file requests until it can process them. Stated differently, the FUSE acts as a proxy between the container and the container image. In response to determining that all of the plurality of files have been retrieved or requested, the FUSE processes any outstanding file requests and instructs the mount point to run the container using the one or more base layers created. The FUSE may then unmount itself, to thereby expose the container to the underlying mount point.

In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a local area network (LAN), an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, a hub, an access point, a network access control device, 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 machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. In one embodiment, computer system <NUM> may be representative of a server.

The exemplary computer system <NUM> includes a processing device <NUM>, a main memory <NUM> (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), a static memory <NUM> (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device <NUM>, which communicate with each other via a bus <NUM>. Any of the signals provided over various buses described herein may be time multiplexed with other signals and provided over one or more common buses. Additionally, the interconnection between circuit components or blocks may be shown as buses or as single signal lines. Each of the buses may alternatively be one or more single signal lines and each of the single signal lines may alternatively be buses.

Computing device <NUM> may further include a network interface device <NUM> which may communicate with a 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).

Processing device <NUM> represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device may be complex instruction set computing (CISC) microprocessor, reduced instruction set computer (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device <NUM> may also be 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> is configured to execute lazy image pull instructions <NUM>, for performing the operations and steps discussed herein.

The data storage device <NUM> may include a machine-readable storage medium <NUM>, on which is stored one or more sets of lazy image pull instructions <NUM> (e.g., software) embodying any one or more of the methodologies of functions described herein. The lazy image pull instructions <NUM> may also reside, completely or at least partially, within the main memory <NUM> or within the processing device <NUM> during execution thereof by the computer system <NUM>; the main memory <NUM> and the processing device <NUM> also constituting machine-readable storage media. The lazy image pull instructions <NUM> may further be transmitted or received over a network <NUM> via the network interface device <NUM>.

While the machine-readable storage medium <NUM> is shown in an exemplary embodiment to be a single medium, the term "machine-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that store the one or more sets of instructions. A machine-readable medium includes any mechanism for storing information in a form (e.g., software, processing application) readable by a machine (e.g., a computer). The machine-readable medium may include, but is not limited to, magnetic storage medium (e.g., floppy diskette); optical storage medium (e.g., CD-ROM); magneto-optical storage medium; read-only memory (ROM); random-access memory (RAM); erasable programmable memory (e.g., EPROM and EEPROM); flash memory; or another type of medium suitable for storing electronic instructions.

The preceding description sets forth numerous specific details such as examples of specific systems, components, methods, and so forth, in order to provide a good understanding of several embodiments of the present disclosure. It will be apparent to one skilled in the art, however, that at least some embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known components or methods are not described in detail or are presented in simple block diagram format in order to avoid unnecessarily obscuring the present disclosure. Thus, the specific details set forth are merely exemplary. Particular embodiments may vary from these exemplary details and still be contemplated to be within the scope of the present disclosure.

Additionally, some embodiments may be practiced in distributed computing environments where the machine-readable medium is stored on and or executed by more than one computer system. In addition, the information transferred between computer systems may either be pulled or pushed across the communication medium connecting the computer systems.

Embodiments of the claimed subject matter include, but are not limited to, various operations described herein. These operations may be performed by hardware components, software, firmware, or a combination thereof.

Although the operations of the methods herein are shown and described in a particular order, the order of the operations of each method may be altered so that certain operations may be performed in an inverse order or so that certain operation may be performed, at least in part, concurrently with other operations. In another embodiment, instructions or sub-operations of distinct operations may be in an intermittent or alternating manner.

The above description of illustrated implementations of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. The words "example" or "exemplary" are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the words "example" or "exemplary" is intended to present concepts in a concrete fashion. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise, or clear from context, "X includes A or B" is intended to mean any of the natural inclusive permutations. That is, if X includes A; X includes B; or X includes both A and B, then "X includes A or B" is satisfied under any of the foregoing instances. In addition, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form. Moreover, use of the term "an embodiment" or "one embodiment" or "an implementation" or "one implementation" throughout is not intended to mean the same embodiment or implementation unless described as such. Furthermore, 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.

Claim 1:
A computer-implemented method comprising:
retrieving, by a file system in user space, FUSE (222B), a plurality of files corresponding to an image file comprising one or more base layers and an upper layer for recording changes made by the container, to build, in a mount point (<NUM>) implemented in an operating system kernel, one or more base layers (<NUM>, <NUM>) for running a container (<NUM>), from a registry server (<NUM>) as a background process; characterised by;
during the retrieving, receiving from the container (<NUM>), one or more file requests, each of the one or more file requests processed by the FUSE (222B) and wherein the FUSE (222B) acts as a proxy between the container (<NUM>) and the image file;
building the base layers of the image file locally within empty layers of the mount point (<NUM>), the FUSE (222B) arranged to manage file requests from the container by emulating the mount point (<NUM>) in the FUSE (222B) to write a file in the upper layer of the image file;
in response to the FUSE (222B) determining that all of the plurality of files have been retrieved or requested:
processing any outstanding file requests; and
instructing the mount point (<NUM>), by a processing device to use the one or more base layers (<NUM>, <NUM>) built in the mount point (<NUM>) to run the container (<NUM>).