Computer-Implemented Method, Computer Program Product, and System (Container Image Creation and Deployment)

Abstract

To provide a computer-implemented method, computer program product or system or a combination thereof for reducing a load generated in creating a container.SOLUTION: A computer-implemented method according to one embodiment includes: receiving a request to create a container; retrieving a manifest for a container image of the container; and mounting a file system for the container, utilizing the manifest.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present disclosure relates to hardware virtualization, and more specifically to creating and deploying container images. [Background technology]

[0002] Modern application deployments often rely on the use of containers. For example, container images are distributed through a central registry, and to start a container, the host retrieves the container image and uses it to create the container's root filesystem. The number of container images and the rate at which containers are deployed are growing rapidly.

[0003] However, current implementations of container images have several issues. For example, containers currently take a long time to start and are I / O intensive because large container images must be downloaded and stored, resulting in high local memory and / or storage usage. Transferring large container images over a communications network results in high network usage and a high load on the registry service storage subsystem. As a result, current container images are bulky and expensive to transfer and store.

[0004] Therefore, there is a need for a faster and more efficient way to store and distribute container images. Summary of the Invention [Problem to be solved by the invention]

[0005] An object of the present invention is to provide a computer-implemented method, a computer program product, a system, or a combination thereof that reduces the load incurred when creating a container. [Means for solving the problem]

[0006] According to one embodiment of the present disclosure, a computer-implemented method includes receiving a request to create a container, obtaining a container image manifest for the container, and mounting a file system of the container using the manifest.

[0007] According to another embodiment of the present disclosure, there is provided a computer program product for deploying a container image, the computer program product including a computer-readable storage medium having program instructions embodied thereon, the computer-readable storage medium being a non-transitory signal, the program instructions being executable by a processor to cause the processor to perform a method including receiving, by the processor, a request to create a container; obtaining, by the processor, a manifest for a container image of the container; and mounting, by the processor, a file system of the container using the manifest.

[0008] According to yet another embodiment of the present disclosure, a system includes a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic configured to receive a request to create a container, obtain a container image manifest for the container, and mount a file system of the container using the manifest.

[0009] According to yet another embodiment of the present disclosure, a method includes receiving a command to install a software package in a running container, obtaining a metadata package for the software package, installing the software package in the running container using the metadata package, identifying the need for a file during installation of the software package, and obtaining the file using the metadata package.

[0010] According to yet another embodiment of the present disclosure, there is provided a computer program product for deploying a container image, the computer program product including a computer-readable storage medium having program instructions embodied thereon, the computer-readable storage medium being a non-transitory signal, the program instructions being executable by a processor to cause the processor to perform a method including receiving a command to install a software package into a container being executed by the processor; obtaining, by the processor, a metadata package for the software package; installing, by the processor, the software package into the running container using the metadata package; identifying, by the processor, the need for a file during installation of the software package; and obtaining, by the processor, the file using the metadata package.

[0011] Other aspects and embodiments of the present invention will become apparent from the following detailed description, which, when taken in conjunction with the drawings, illustrate by way of example the principles of the invention. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 illustrates a cloud computing environment according to one embodiment of the present invention. [Figure 2] FIG. 2 illustrates an abstract model layer according to one embodiment of the present invention. [Figure 3] FIG. 3 illustrates a cloud computing node according to one embodiment of the present invention. [Figure 4] FIG. 4 illustrates a flowchart of a method for deploying a container image according to one embodiment of the present invention. [Figure 5] FIG. 5 illustrates a flowchart of a method for performing on-demand container image file access according to one embodiment of the present invention. [Figure 6] FIG. 6 illustrates a flowchart of a method for installing a package into a running container using a metadata package, according to one embodiment of the present invention. [Figure 7] FIG. 7 illustrates exemplary image distribution system components according to one embodiment of the present invention. [Figure 8] FIG. 8 illustrates an exemplary image distribution system implementation according to one embodiment of the present invention. [Figure 9] FIG. 9 illustrates an exemplary system architecture according to one embodiment of the present invention. [Figure 10] FIG. 10 illustrates an exemplary package installation according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0013] (Detailed explanation) The following description is made for the purpose of illustrating the general principles of the present invention and is not intended to limit the inventive concepts claimed herein. Moreover, particular features described herein can be used in combination with other described features in each of the various possible combinations and permutations.

[0014] Unless otherwise defined herein, all terms should be given the broadest possible interpretation, including the meaning implied from this specification and the meaning understood by a person skilled in the art or defined in dictionaries, treatises, etc., or both.

[0015] As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. As used herein, the term "comprises" and / or "comprising" specifies the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups or combinations thereof.

[0016] The following description discloses several embodiments for creating and deploying container images.

[0017] In one general embodiment, a computer-implemented method includes receiving a request to create a container, obtaining a container image manifest for the container, and mounting a file system for the container using the manifest.

[0018] In another general embodiment, a computer program product for deploying a container image includes a computer-readable storage medium having program instructions embodied thereon, the computer-readable storage medium being a non-transitory signal, the program instructions being executable by a processor to cause the processor to perform a method including receiving, by the processor, a request to create a container; obtaining, by the processor, a manifest for a container image of the container; and mounting, by the processor, a file system of the container using the manifest.

[0019] In another general embodiment, a system includes a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic configured to receive a request to create a container, obtain a container image manifest for the container, and mount a file system for the container using the manifest.

[0020] In another general embodiment, a computer-implemented method includes receiving a command to install a software package in a running container; obtaining a metadata package for the software package; installing the software package in the running container using the metadata package; identifying a need for a file during installation of the software package; and obtaining the file using the metadata package.

[0021] In another general embodiment, a computer program product for deploying a container image includes a computer-readable storage medium having program instructions embodied thereon, the computer-readable storage medium being a non-transitory signal, the program instructions being executable by a processor to cause the processor to perform a method including receiving a command to install a software package into a container being executed by the processor; obtaining, by the processor, a metadata package for the software package; installing, by the processor, the software package into the running container using the metadata package; identifying, by the processor, the need for a file during installation of the software package; and obtaining, by the processor, the file using the metadata package.

[0022] Although this disclosure includes detailed descriptions of cloud computing, implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the invention can be practiced in conjunction with any other type of computing environment now known or later developed.

[0023] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five characteristics, at least three service models, and at least four implementation models.

[0024] The characteristics are as follows:

[0025] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider.

[0026] Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, PDAs).

[0027] Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated based on demand. Consumers generally have no control or knowledge of the exact location of the resources they are provided with, so there is a sense of location independence. However, consumers may be able to identify their location at a higher level of abstraction (e.g., country, state, data center).

[0028] Rapid Elasticity: Computing capacity can be provisioned quickly and elastically, sometimes automatically, to instantly scale out and quickly released to instantly scale in. To the consumer, the computing power available to provision often appears unlimited, and can be purchased at any time and in any quantity.

[0029] Metered Services: Cloud systems leverage measurement capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of utilized services.

[0030] The service model is as follows:

[0031] Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure. The applications can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application functions, except for limited user-specific application configuration settings.

[0032] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire onto a cloud infrastructure using programming languages ​​and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of their hosting environment.

[0033] Infrastructure as a Service (IaaS): The functionality provided to consumers is the provisioning of processors, storage, networking, and other basic computing resources on which the consumer can deploy and run any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, and deployed applications, and in some cases partial control over some network components (e.g., host firewalls).

[0034] The deployment model is as follows:

[0035] Private Cloud: This cloud infrastructure is dedicated to a specific organization and can be managed by that organization or a third party, and can exist on-premise or off-premise.

[0036] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by those organizations or a third party and can exist on-premises or off-premises.

[0037] Public cloud: This cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0038] Hybrid cloud: This cloud infrastructure combines two or more cloud models (private, community, or public), each of which retains its inherent identities but is bound together by standards or specific technologies to enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0039] A cloud computing environment is a service-oriented environment that emphasizes statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0040] FIG. 1 illustrates an exemplary cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers (e.g., PDAs or cell phones 54A, desktop computers 54B, laptop computers 54C, or automobile computer systems 54N, or combinations thereof) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof. This enables the cloud computing environment 50 to provide infrastructure, platform, or software as a service, or combinations thereof, for which cloud consumers are not required to maintain resources on their local computing devices. It should be understood that the types of computing devices 54A-N illustrated in FIG. 1 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device via any type of network or network-addressable connection (e.g., using a web browser), or both.

[0041] A set of functional abstraction layers provided by cloud computing environment 50 (FIG. 1) is now shown in FIG. 2. It should be understood in advance that the components, layers, and functions shown in FIG. 2 are merely exemplary, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0042] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, reduced instruction set computer (RISC) architecture-based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0043] The virtualization layer 70 provides an abstraction layer from which the following virtual entities can be provided, for example: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0044] By way of example, the management layer 80 may provide the following functions: Resource provisioning 81 enables dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment; Metering and pricing 82 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources; By way of example, these resources may include application software licenses; Security enables identification and verification of cloud consumers and tasks, as well as protection for data and other resources; User portal 83 provides consumers and system administrators with access to the cloud computing environment; Service level management 84 enables allocation and management of cloud computing resources so that requested service levels are met; Service level agreement (SLA) planning and fulfillment 85 enables advance arrangement and procurement of anticipated future cloud computing resources required in accordance with SLAs.

[0045] The workload layer 90 provides examples of functionality available to a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and automated discovery and cataloging or inventorying of items or assets at a location or property 96.

[0046] 3, a schematic diagram of an example cloud computing node is shown. Cloud computing node 10 is merely one example of a suitable cloud computing node and is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present invention described herein. In any event, cloud computing node 10 may implement and / or perform any of the functions described above.

[0047] Cloud computing node 10 includes computer system / server 12, which is operable with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computer systems, environments, and / or configurations suitable for use with computer system / server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0048] Computer system / server 12 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system / server 12 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0049] 3, computer system / server 12 within cloud computing node 10 is shown in the form of a general-purpose computing device. Components of computer system / server 12 include, but are not limited to, one or more processors or processing units 16, system memory 28, and a bus 18 that couples various system components, including system memory 28, to processor 16.

[0050] Bus 18 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an Accelerated Graphics Port (AGP), and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0051] Computer system / server 12 typically includes a variety of computer system-readable media, which may be any available media that can be accessed by computer system / server 12 and includes both volatile and nonvolatile media, removable and non-removable media.

[0052] The system memory 28 may include computer-readable media such as volatile memory, such as RAM 30 and / or cache memory 32. The computer system / server 12 may also include other removable / non-removable and volatile / non-volatile computer storage media. By way of example only, a storage system 34 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a floppy disk), and an optical disk drive may be provided for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. In these examples, each may be connected to the bus 18 by one or more data media interfaces. As described in more detail below, the memory 28 may include at least one program product having one or more program modules configured to perform the functions of embodiments of the present invention.

[0053] A program / utility 40 having one or more program modules may be stored in memory 28, as well as, for example, without limitation, an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or a combination thereof, may include an implementation of a network environment. Program modules 42 generally perform the functions and / or methods of embodiments of the present invention described herein.

[0054] The computer system / server 12 may communicate with one or more external devices 14, such as a keyboard, pointing device, display 24, one or more devices that enable user interaction with the computer system / server 12, or any device (e.g., network card, modem, etc.) that enables the computer system / server 12 to communicate with one or more other computing devices, or any combination thereof. Such communication may occur via an input / output (I / O) interface 22. Furthermore, the computer system / server 12 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via a network adapter 20. As shown, the network adapter 20 communicates with other components of the computer system / server 12 via a bus 18. Note that other hardware and / or software components (not shown) may be used with the computer system / server 12, including, by way of example, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data archive storage systems, etc.

[0055] Referring to Figure 4, a flowchart of a method 400 according to one embodiment is shown. Method 400 may be performed in accordance with the present invention in various embodiments, particularly in any of the environments shown in Figures 1-3 and 7-10. Of course, more or fewer operations than those specifically described in Figure 4 may be included in method 400, as will be understood by those skilled in the art upon reading this description.

[0056] The steps of method 400 may be performed by any suitable component of an operating environment. For example, in various embodiments, method 400 may be performed in part or in whole by one or more servers, computers, or other devices having one or more processors therein. A processor, e.g., a processing circuit, chip, or module implemented in hardware or software or both, preferably having at least one hardware component, or a combination thereof, may be utilized in any device to perform one or more steps of method 400. Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or the like, combinations thereof, or any other suitable computing device known in the art.

[0057] 4, method 400 may begin at operation 402, where a request to create a container is received. In one embodiment, the request may be received from a user. In other embodiments, the request may be received at a cluster of computing nodes (e.g., a distributed computing network, a cloud-based computing environment, etc.).

[0058] Additionally, in one embodiment, a container may be implemented using operating system (OS)-level virtualization and may rely on a self-contained software package (e.g., an image). In other embodiments, creating a container may include a combination of mounting the container's file system on one of multiple computing nodes in a cluster, loading one or more files (including executables, libraries, data, etc.) into the container, and / or running one or more applications within the container using the mounted file system.

[0059] Further, method 400 proceeds to operation 404, where a manifest for a container image of the container is obtained. In one embodiment, the container image may include all files necessary to create a container on one of the cluster of computing nodes. For example, the container image may include multiple files (e.g., an executable package containing code, runtime, system tools, system libraries, and configuration, etc.).

[0060] Additionally, in one embodiment, a manifest for a container image may include metadata describing multiple files in the container image. For example, the manifest may include a list of file names (e.g., content identifiers), ownership or permission data associated with those files, or a combination thereof. In another example, the manifest may include content-based addresses for the files (e.g., file hashes, pointers to locations where multiple files are stored, etc.). In yet another example, the manifest may store multiple file stubs, each of which includes a pointer to a location where a file is stored.

[0061] Also, in one embodiment, the manifest may include metadata that describes the files in the container image, but not the files themselves. In other embodiments, the files may be stored remotely in a content store (e.g., a centralized object store). In yet other embodiments, one or more files may be stored locally (e.g., on the node where the container is created).

[0062] Additionally, in one embodiment, the manifest may be retrieved from a repository. For example, a node in a cluster may be assigned the task of creating a container and retrieve the manifest for the container image for the container from a manifest repository (e.g., a database) that is physically separate from the node.

[0063] Additionally, in one embodiment, the manifest may be retrieved locally from the node on which the container is being created. For example, a node assigned the task of creating a container may search for the manifest in cached data, and if the manifest is found in the cache, the cached manifest may be retrieved from the cache. In another example, if the manifest is not found in the cache, the manifest may be retrieved from a repository located elsewhere than the node.

[0064] Further, method 400 may proceed to operation 406, where the container's file system is mounted utilizing the manifest. In one embodiment, the manifest may include data sufficient to create (e.g., mount) the container's file system. In other embodiments, the manifest may include one or more inode descriptors and file hashes. In yet other embodiments, the inode descriptor may include metadata used to mount the container's file system. In other embodiments, the file system may be mounted on a node of a cluster of computing nodes (e.g., a node assigned the task of creating the container).

[0065] In this way, a container's file system can be mounted using the container image's manifest, rather than the complete container image itself. The manifest can contain only the metadata necessary to mount the file system and pointers to additional file data contained within the container image. As a result, the size of the manifest can be much smaller than the container image itself. By retrieving the manifest instead of the image to mount a container's file system, the bandwidth used by the node can be significantly reduced, which can improve the performance of the computing hardware used by the node, as well as the hardware components used to implement the communication network that facilitates the transmission of data between the node and data stores such as the manifest repository and container image repository.

[0066] Referring now to Figure 5, a flowchart of a method 500 for performing on-demand container image file access is shown, according to one embodiment. Method 500 may be performed in accordance with the present invention in various embodiments, particularly in any of the environments shown in Figures 1-3 and 7-10. Of course, more or fewer operations than those specifically set forth in Figure 5 may be included in method 500, as will be understood by those skilled in the art upon reading this description.

[0067] The steps of method 500 may be performed by any suitable component of an operating environment. For example, in various embodiments, method 500 may be performed partially or entirely by one or more servers, computers, or some other device having one or more processors therein. A processor, e.g., a processing circuit, chip, or module implemented in hardware or software or both, preferably having at least one hardware component, or a combination thereof, may be utilized in any device to perform one or more steps of method 500. Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or the like, combinations thereof, or any other suitable computing device known in the art.

[0068] 5, method 500 may begin at operation 502, where a request to access data in a container image of a container is identified by a mounted file system of the container. In one embodiment, the request to access data may include a file read request. In other embodiments, the request to access data may include a request from an application in the container to read data in the container image.

[0069] Additionally, in one embodiment, the file system may be mounted for the container at a node of the cluster of computing nodes, while in other embodiments, the file system may be mounted to the container in response to a request to create the container.

[0070] Further, method 500 proceeds to operation 504, where, in response to determining that the data is located locally in the cache, the data is retrieved from the cache. For example, the cache may include high-speed, low-latency memory that is faster than standard data storage within the nodes of the cluster. In other examples, the cache may include volatile memory.

[0071] Further, method 500 proceeds to operation 506, where a location of the data is determined utilizing a manifest for the container image, and in response to determining that the data is not located in the cache, the location of the data is utilized to remotely retrieve the data from a content store. In one embodiment, the location of the data may be included in metadata stored in the manifest. For example, the metadata may describe multiple files within the container image. In other embodiments, the manifest may include content-based addresses of the files (e.g., file hashes, pointers to locations where multiple files are stored, etc.). In other embodiments, the content store may be physically separate from the nodes of the cluster and may be accessed via a communications network.

[0072] Also, in one embodiment, the file system may be mounted on a predetermined node of the cluster. In other embodiments, in response to determining that the manifest for the image indicates that the data is stored locally in the cache, the data may be retrieved from the cache. In yet other embodiments, in response to determining that the manifest for the image indicates that the data is not stored locally in the cache, the data may be retrieved from a content store using a communications network. For example, the content store may store data in association with a container image.

[0073] Additionally, in one embodiment, the retrieved data may be used by a mounted file system, for example, the retrieved data may be provided to an application running within the node using the mounted file system.

[0074] In this way, the manifest for the container image can enable the container's mounted file system to retrieve data in the container image on demand, eliminating the need to store the container image locally on the node where the file system is mounted. This may reduce the amount of data required to deploy a container on a node, improving node performance. This may also reduce the amount of data that needs to be transferred to the node to deploy a container on the node, which may reduce the amount of network traffic between the node and the container image store, thereby improving the performance of one or more hardware components implementing network communications, etc.

[0075] Referring now to Figure 6, a flowchart of a method 600 for installing a package in a running container using a metadata package is shown, according to one embodiment. Method 600 may be performed in accordance with the present invention in various embodiments, particularly in any of the environments shown in Figures 1-3 and 7-10. Of course, more or fewer operations than those specifically set forth in Figure 6 may be included in method 600, as will be understood by those skilled in the art upon reading this description.

[0076] The steps of method 600 may be performed by any suitable component of an operating environment. For example, in various embodiments, method 600 may be performed partially or entirely by one or more servers, computers, or other devices having one or more processors therein. A processor, e.g., a processing circuit, chip, or module implemented in hardware or software or both, preferably having at least one hardware component, or a combination thereof, may be utilized in any device to perform one or more steps of method 600. Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or the like, combinations thereof, or any other suitable computing device known in the art.

[0077] 6, method 600 may begin at operation 602, where a command to install a software package into a running container is received. In one embodiment, the command may be received from a user, an application, etc. In other embodiments, the command may be received at a cluster of computing nodes (e.g., a distributed computing network, a cloud-based computing environment, etc.).

[0078] Additionally, in one embodiment, the software package may include all files necessary to add the software package to a running container on one of the cluster of computing nodes. In other embodiments, the running container may include a container installed on a node utilizing the container image. For example, a node of the cluster may be allocated to create the container image.

[0079] Further, method 600 begins at operation 604, where a metadata package for the software package is obtained. In one embodiment, the metadata package may be obtained from a public repository (e.g., a database such as a public package metadata store). For example, the public package metadata store may be physically separate from the public package data store that stores the files to which the metadata package points.

[0080] Additionally, in one embodiment, the metadata may include a list of files and hashes of the file contents, while in other embodiments, the metadata may include the location of each file rather than the file itself.

[0081] Also, in one embodiment, the node may first check the node's local cache to see if the metadata package is located in the cache. For example, if the metadata package is determined to be located in the cache, the metadata package may be retrieved from the cache. In another example, if the metadata package is not determined to be located in the cache, the metadata package may be retrieved from a public repository other than the cache and the node.

[0082] Further, method 600 may proceed to operation 606, where the software package is installed into the running container using the metadata package. In one embodiment, installing the software package may include installing the metadata in the metadata package onto nodes (e.g., assigned nodes) of the cluster.

[0083] Additionally, in one embodiment, metadata may be installed within a node as one or more stub files with pointers to the data. For example, each stub file may represent a file within a container image. In another example, each stub file may be a metadata placeholder for a file rather than the file itself. In yet another example, each stub file may point to where the file is stored (e.g., another file repository, cache, etc.).

[0084] Additionally, in one embodiment, hashes of the file contents in the metadata can be used as pointers within the software package.

[0085] Method 600 also proceeds to operation 608, where a file need is identified during installation of the software package. In one embodiment, a request for a particular file in the software package may be received during installation of the software package. For example, the request may be received from a compiler that is installing the software package. In other embodiments, installation of the software package may require a file that is not present in the metadata package.

[0086] Further, method 600 proceeds to operation 610, where the file is retrieved utilizing the metadata package. In one embodiment, in response to identifying the need for the file, a local cache of the node on which the container image is being created may be retrieved to see if the file is located in the cache. In other embodiments, if the file is located in the cache, the file may be retrieved from the cache. In yet other embodiments, if the file is not located in the cache, it may be retrieved from a file repository (e.g., a public repository other than the cache or the node).

[0087] Additionally, in one embodiment, a metadata placeholder for a file (e.g., a stub for the file) may be identified at the node. In other embodiments, a pointer to the location of the file may be associated with the metadata placeholder. In yet other embodiments, the pointer may be used to determine the location of the file and retrieve the file. In yet other embodiments, the file may be retrieved and used to continue and / or complete the installation of the software package.

[0088] In this way, a metadata package can contain only file metadata, excluding the actual files contained within the container image. As a result, installing a metadata package requires only copying the metadata and associated pointers, rather than the data itself. Data needed during software package installation can be retrieved on-demand as needed. This reduces the amount of storage required for software package installation and improves the performance of the hardware computing device performing the software package installation. This also helps create images in a fast and efficient manner. This can also reduce the amount of bandwidth required for software package installation, thereby improving the performance of one or more hardware components implementing one or more network communications used during software package installation.

[0089] (Efficient runtime image distribution, deployment, and operation) Image distribution has some consistent characteristics, such as high levels of replication of distributed images and a low percentage of image data actually used by containers. These insights can be leveraged to improve image distribution and deployment.

[0090] In one embodiment, each image can be represented by a small manifest that lists the filename and metadata. Furthermore, the manifest alone can create (e.g., mount) a file system on worker nodes and support read-only metadata operations without fetching file data.

[0091] Additionally, in one embodiment, for each container file, the manifest stores a content-based address of the file's data. The file contents themselves are stored, for example, in object storage. Only data actually accessed by a host is transferred to the host on-demand. No duplicate files are maintained in the local memory and storage of the node implementing the image, and no duplicates are included in the registry.

[0092] In one embodiment, a method for storing and distributing images is provided. A method for launching containers using only file system metadata is also provided. A method for downloading container data on demand is also provided. A method for avoiding duplication when transferring images using content-addressable storage is also provided.

[0093] Also provided is a method for managing a host-side image cache. Additionally, a method for transparently converting traditional images to content-addressable images is provided.

[0094] 7 illustrates exemplary image distribution system components 700, according to one embodiment. As shown, a manifest store 702 stores multiple image manifests 704. Each image manifest 704 includes one or more inode descriptors 706. The image manifests 704 are used to mount a file system 708 on a specified host 710. When a file within a container image is needed, the inode descriptor 706 is identified in the container image's image manifest 704 and used to retrieve the file from the content store 712.

[0095] 8 illustrates an exemplary image distribution system implementation 800, according to one embodiment. As shown, in response to a request to create a container on a host 802, a manifest 804 for the container's container image is retrieved from a manifest store 806. This manifest 804 is used to mount a file system 808 within the container host 802.

[0096] In response to a request for a first file in the mounted file system 808, the stub for the first file 810 in the file system 808 points to the shared cache 812 from which the file is retrieved. In response to a request for a second file in the mounted file system 808, the stub for the second file 814 in the file system 808 does not point to the shared cache 812. As a result, the content-based address of the second file is identified in the manifest 804 and used to retrieve the second file from the content store 816.

[0097] (Example container startup and file operations) In one embodiment, during startup, a user requests to start a container from Image A. If the manifest for Image A exists locally, the manifest is used to mount the container's file system. If the manifest does not exist locally, the manifest is retrieved from the manifest store and the manifest is used to mount the container's file system. After the file system is mounted, operations such as open, stat, readdir, etc. may be performed entirely locally (e.g., local to the node with the started container).

[0098] In another embodiment, an application requests to read data from file F. In response, the content hash of file F is used in the manifest to determine whether file F is available locally (e.g., in the node's cache). If file F is available locally, the requested data is returned to the application. If file F is not available locally, the missing file content is fetched from the content store and the requested data is returned to the application.

[0099] In yet another embodiment, an application requests to write data to file F. If the write is a complete overwrite, the copy is updated with the data provided by the application. In another embodiment, the update does not go to the content store unless explicitly requested. In another embodiment, changes to the root file system are lost when the container is stopped. A confirmation of the write is then sent to the application.

[0100] If the write is not a full overwrite, the content hash of file F in the manifest is used to determine if the file contents are available locally. If the file contents are available locally, a copy of F's contents is made, the copy is updated with the data provided by the application, and a write confirmation is sent to the application. If the content is not available locally, the missing file contents are fetched from the content store, a copy of F's contents is made, the copy is updated with the data provided by the application, and a write confirmation is sent to the application.

[0101] In yet other embodiments, metadata updates (e.g., create, delete, rename, directory operations, setattr, etc.) do not require communication with the content or manifest store.

[0102] (Content-addressable shared cache management) In one embodiment, the cache resides in volatile memory. A typical diskless configuration may be supported, or there may be optional support for a local storage cache. The memory cache size is fixed at container runtime startup, and the container orchestrator (K8s) takes into account the memory used for the cache when scheduling containers.

[0103] Additionally, there may be a hierarchical memory cache eviction order such as:

[0104] T1: Blob not referenced by locally pulled manifest (image deleted).

[0105] T2: Blob not referenced by the "running" image (but referenced by the local manifest).

[0106] T3: An unmodified BLOB that is not referenced by an open file (but is by an image execution).

[0107] T4: Other unchanged blobs.

[0108] Reference tracking and garbage collection techniques may also be used. LRU or ARC eviction policies may be used within the hierarchy. To handle cache thrashing or out-of-space situations, I / O may be blocked or an ENOSPC error may be provided. Prefetching of frequently used files within the image may also be performed (e.g., using manifest extensions).

[0109] (Compatible with existing registries) Standard images can also be used with other graph drivers (e.g., overlay, dm, etc.). The Image Conversion Service (ICS) can download images from traditional registries, unpack the tarball, upload missing files as blobs to the content store, generate a manifest, and upload it to the manifest store.

[0110] ICS can be converged onto regular worker nodes or run on a dedicated set of nodes. In a converged configuration, worker nodes can receive regular images, convert them to images, and immediately start containers using the file system. Uploading missing content and manifests to the appropriate stores can be done asynchronously.

[0111] (Fast container image building with metadata software packages) Building a container image consists of several steps.

[0112] Get the base image.

[0113] Install additional software on the image from a remote repository.

[0114] Copy local software and data to the image.

[0115] Extract / construct / generate additional image artifacts.

[0116] This build process can be time consuming due to the high input / output (network and storage) load as a lot of data needs to be copied / retrieved. Most of the time is spent retrieving and installing packages (yum, apt, etc.), and the overhead increases if the image is built repeatedly (for example, in a CI / CD pipeline or during image testing). This issue occurs with OCI-compliant images.

[0117] As a result, there is a need for a fast way to build container images.

[0118] In one embodiment, a method is provided for installing and managing software packages (e.g., RPMs, DEBs, etc.) if the same content does not exist in a private data store, the method including maintaining a package repository consisting of a public package data store, a public package metadata store, and a private data store; installing the software package and downloading only package metadata including a list of packaged files and their content hashes from the public metadata store; installing the metadata in a file system as a stub file with pointers to the data via the content hashes; and retrieving the data from the public data store to the private data store asynchronously or on demand.

[0119] In another embodiment, a method for creating and sharing a metadata package is provided, the method including traversing files listed in a package specification file or an existing package, calculating a content ID for each file, and adding the ID to the package metadata, and uploading the new package metadata to a public metadata store while uploading the file to the public data store only if the content does not already exist in the public data store.

[0120] Furthermore, in one embodiment, a package is a collection of file metadata only, with no actual content. Installing a package requires only copying the metadata, and retrieving the metadata from the package repository is resource-efficient and fast. No storage or network I / O is required during package installation; the file metadata is used to retrieve the package data when and where it is needed.

[0121] 9 illustrates an exemplary system architecture 900 according to one embodiment. As shown, a repostor 902 for storing package data is located separately from a repo package store 904 for storing package metadata and a cluster store 906 for locally storing package data accessed by containers. A container host 908 receives instructions 910 to build an image using a first package. Metadata 912 for the first package is retrieved from the repo package store 904 to build the image.

[0122] Additionally, when a file is needed during image building, the cluster store 906 is checked first. If the file is present in the cluster store 906, the file is retrieved from the cluster store 906 by the fetcher module 914 of the container host 908. If the file is not present in the cluster store 906, the file is retrieved from the repostor 902 by the fetcher module 914 of the container host 908.

[0123] 10 illustrates an exemplary package installation 1000 according to one exemplary embodiment. As shown, a metadata package 1002 is downloaded from a repository. All directories 1004 listed in the metadata package 1002 are created (e.g., using POSIX create). For each regular file listed in the metadata package 1002, a file is created and its FILELINK is set using an ioctl system call. Following the FILELINK, if the content does not exist in the content store 1006, the content is retrieved. In one embodiment, the ioctl system call is applied to the entire list to create all the content.

[0124] In one embodiment, existing (pre- / post-install) scriptlets can communicate with the file system as usual, and if a scriptlet requires a file that has not yet been fetched, the package manager will wait until the required data is retrieved.

[0125] (Package Creation) In one embodiment, packages are based on RPM. The definition may be provided via a spec file, which may be compatible with existing spec formats. Package creation may be implemented using the new build-skinny-pkg tool. An example of the build-skinny-pkg tool is shown below: example.spec[1] ---------------------------------------- Name: example Version: 0.1.1 BuildRequires: python Requires: bash %build python -m compileall %{name}.py %install mkdir -p %{buildroot} / usr / lib / %{name} install -m 0644 %{name}.py* %{buildroot} / usr / lib / %{name} / %files %dir / usr / lib / %{name} / / usr / lib / %{name} / %{name}.py*

[0126] Given the specs above, to create an spkg package file, the Build-skinny-pkg tool performs the following steps: 1. Traverse %{buildroot} 2. For each file, A: Calculate the hash B: Check if it already exists in the repository C: If not present, upload to Reposta D: Add metadata entries to the spkg file header 3.Upload the spkg file to the repo package store

[0127] (Package file layout and conversion) Package files may be based on the rpm format. They may contain a header preamble, a header index (with tags describing different entries in the header store), and a header store. spkg packages may have no payload (which may be a data archive, for example) and may contain a new header tag (HWTAG_FILELINKS) that stores the hash of each file. File links for directories and non-regular files can be set to "-1".

[0128] In one embodiment, the conversion from an rpm to an spkg package consists of the following steps: 1. Copy the preamble 2. Copy the index and add a new HWTAG_FILELINKS tag 3. Extract the contents from the rpm file 4. Iterating through a list of files and each file A: Calculate the hash B: Upload to Reposta C: Add hash to header store

[0129] (Prioritized Content Acquisition)

[0130] In one embodiment, the fetcher can retrieve content in parallel so as not to block image building. The fetcher can retrieve content in order of priority. Package files required during image building can be fetched first. The prioritized retrieval order can be determined by the following steps: 1. Scan the Dockerfile for invocation of binaries (RUN commands) 2. Process the detected binaries according to their location in the Dockerfile 3. For each binary found, scan current packages for a match 4. If a match is found, add the binary to the list of high-priority files 5. Get the highest priority binaries in order

[0131] Packages may also specify a preferred retrieval order as part of the package metadata.

[0132] (switching repositories) In one embodiment, the transition from a standard repository to a metadata repository can be achieved through two different options: the first option is a new toolset that provides an entirely new repository and toolset, and the second option is a new toolset that makes the toolset compatible with existing repository toolsets (e.g., yum). The previous toolset commands can be aliases to the new toolset commands for a seamless transition.

[0133] The second option is to update the existing toolset by modifying the existing tools to allow for the retrieval of metadata packages. An option can be added to indicate whether the metadata software package should be retrieved. There are two versions of each repository definition: the traditional repository definition and the metadata package repository definition. If the metadata package option is set, the metadata package repo can be used.

[0134] In one embodiment, a method for storing and providing a metadata package for installation within a container image during image build is provided. A method for installing a metadata software package within a container image is also provided. A method for creating a metadata software package that is compatible with existing package creation tools is also provided. A file layout for a metadata software package is also provided.

[0135] Also provided is a method for converting an existing package into a metadata software package, and a method for preferentially retrieving the contents of a metadata software package.

[0136] In one embodiment, a method is provided for creating, manipulating, and interacting with a container root filesystem and a container image registry, the method including: maintaining a per-container image manifest including paths, metadata, and content hashes of all files while retaining the file contents in a content-addressable store of the registry; during container startup, downloading only the image manifest from the image registry without the image content and mounting the filesystem using the content hash stored in the inode; upon file data access, checking whether the file content exists locally and, if the content is missing, downloading it from the registry to a cache; retaining the downloaded file contents in a local content-addressable cache shared among all container root filesystem instances on the host; and when pushing an image to the registry, generating a manifest and uploading the image to the registry with only the missing content.

[0137] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium having stored thereon computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0138] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, by way of example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, mechanically encoded devices having instructions recorded on punch cards or ridge-in-groove structures, or the like, and suitable combinations thereof. Computer-readable storage devices, as used herein, should not be construed as ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0139] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computer / processing device. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, a LAN, a WAN, or a wireless network, or a combination thereof). The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computer / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium in the respective computer / processing device for storage.

[0140] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer-readable program instructions may execute entirely on the user's computer as a stand-alone software package, or partially on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to customize the electronic circuitry for carrying out aspects of the present invention.

[0141] Aspects of the present invention are described herein with reference to flowchart and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. Each block of the flowchart and / or block diagrams, and combinations of blocks in the flowchart and / or block diagrams, can be implemented by computer-readable program instructions.

[0142] The computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, whereby the instructions, executed by the processor of such computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner. The computer-readable storage medium having the instructions stored thereon thereby constitutes an article of manufacture including instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0143] Computer-readable program instructions may also be loaded into a computer, other programmable device, or other device and a series of operational steps executed on the computer, other programmable device, or other device to create a computer-implemented process, whereby the instructions executing on the computer, other programmable device, or other device perform the functions / operations identified in one or more blocks in the flowcharts and / or block diagrams.

[0144] The flowcharts and block diagrams in the figures of this disclosure illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for performing specific logical functions. In some implementations, the functions depicted in the blocks may be performed in a different order than that depicted in the figures. For example, two blocks shown in succession may actually be accomplished as a single step, executed simultaneously or substantially simultaneously, executed in a partially or fully overlapping manner, or executed in reverse order, depending on the functionality involved. Note that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or by a combination of dedicated hardware and computer instructions.

[0145] Furthermore, systems according to various embodiments may include a processor and / or logic integrated with and / or executable by the processor, the logic configured to perform one or more of the process steps described herein. By integrated, it is meant that the processor has logic embedded as hardware logic, such as an application-specific integrated circuit (ASIC), FPGA, etc. By executable by the processor, it is meant that the logic is hardware logic or software logic, such as firmware, part of an operating system, part of an application program, or some combination of hardware and software logic, accessible by the processor and configured to cause the processor to perform some function when executed by the processor. The software logic may be stored in any memory type known in the art, local or remote, or both. Any processor known in the art, e.g., a software processor module or a hardware processor, such as an ASIC, FPGA, central processing unit (CPU), integrated circuit (IC), graphics processing unit (GPU), etc., or both, may be used.

[0146] The various features of the systems and / or methods described above can be combined in any manner, producing multiple combinations as will be apparent from the above description.

[0147] It will further be appreciated that embodiments of the present invention may be provided in the form of a service that is deployed for customers to provide services on demand.

[0148] The description of various embodiments of the present disclosure is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. receiving a request to create a container; obtaining a container image manifest for the container; creating the container, including mounting a file system of the container using data from the manifest, wherein only data from the manifest is used to create the file system of the container and no file data is retrieved; Identifying, after creation of the container, a request for access to data within the container image for the container by the file system mounted for the container; utilizing the manifest of the container image to determine whether requested data is locally present in a cache; retrieving the data from the cache in response to determining that the manifest of the container image indicates that the data is stored locally in the cache; and retrieving the data from a content store in response to determining that the manifest of the container image indicates that the data is not locally available to the cache; and A computer-implemented method in which a processor performs operations including:

2. The container image consists essentially of a plurality of files necessary to create the container on a node of a cluster of computing nodes and metadata describing the plurality of files within the container image. The computer-implemented method of claim 1 .

3. The file system for the container is mounted on a node of a computing system, and the container image is not stored on the node on which the file system is mounted. The computer-implemented method of claim 1 .

4. The manifest includes one or more inode descriptors and file hashes, and the inode descriptors are used to retrieve data from a content store when it is determined that the manifest for the container image indicates that the data is not available locally in a cache. The computer-implemented method of claim 1 .

5. Receiving a command to install a software package into a running container; obtaining a metadata package corresponding to the software package; utilizing the metadata package to install the software package into the running container; identifying file needs during the installation of the software package; Utilizing the metadata package to retrieve the file; The computer-implemented method of claim 1 , comprising:

6. Receiving a request to create a container; obtaining a manifest of a container image of the container, the manifest having a file name and metadata; Mounting a file system of the container on a node of a computing system using data from the manifest; Creating a container, Including, only the data from the manifest is used to create the file system of the container, without retrieving any file data; The container image is not stored on the node where the file system is mounted. Computer-implemented methods.

7. Identifying a request for access to data within the container image of the container by the file system mounted for the container; determining the location of the data using a manifest of the container image; and obtaining the data using the location of the data. The computer-implemented method of claim 1 .

8. The request to access the data includes a request from an application in the container to read data in the container image. The computer-implemented method of claim 7.

9. The location of the data is included in metadata stored in the manifest. The computer-implemented method of claim 7.

10. The manifest contains the content-based addresses of the files. The computer-implemented method of claim 7.

11. and, in response to determining that the manifest of the container image indicates that the data is stored locally in a cache, retrieving the data from the cache. The computer-implemented method of claim 7.

12. and, in response to determining that the manifest of the container image indicates that the data is not stored locally in a cache, obtaining the data from a content store over a communications network. The computer-implemented method of claim 7.

13. Identifying, by the file system mounted for a container, a request from an application within the container to read data of the container image of the container; determining the location of the data using a manifest of the container image; retrieving the data using the location of the data; and The computer-implemented method of claim 6, comprising:

14. 1. A computer program product for deploying a container image, the computer program product comprising program instructions that cause a processor to: receiving a request to create a container by the processor; obtaining, by the processor, a container image manifest for the container; mounting a file system of the container using the manifest by the processor; identifying, by the processor, after creation of a container, a request for access to data within the container image for the container; determining whether the data is located locally in a cache using a manifest of the container image; If it is determined that the manifest of the container image indicates that the data is stored locally in the cache, retrieving the data from the cache; if it is determined that the manifest of the container image indicates that the data is not stored locally in a cache, obtaining the data from a content store; A computer program for causing a method comprising:

15. the container image includes a plurality of files necessary to create the container on a node of a cluster of computing nodes; The manifest of the container image includes metadata that describes the files in the container image.

15. A computer program according to claim 14.

16. The manifest is retrieved from a repository 15. A computer program according to claim 14.

17. The manifest includes one or more inode descriptors and file hashes.

15. A computer program according to claim 14.

18. The access request to the data includes a file read request.

15. A computer program according to claim 14.

19. The location of the data is included in metadata stored in the manifest.

15. A computer program according to claim 14.

20. A method for creating a container comprising: a processor-executable program; and a method for creating a container comprising:

15. A computer program according to claim 14.

21. The manifest essentially consists of metadata used to mount the file system and pointers to file data contained in the container image.

21. A computer program according to claim 20.

22. A method for implementing a method of a computer-implemented program comprising: the program instructions configured to cause the processor to: causing the processor to create the container; causing the processor to receive a command to install a software package into a running container; causing the processor to obtain a metadata package corresponding to the software package; causing the processor to install the software package into the running container using the metadata package; causing the processor to identify file needs during the installation of the software package; causing the processor to utilize the metadata package to obtain the file; 15. The computer program of claim 14, comprising:

23. a processor; and logic integrated with, executable by, or integrated with and executable by the processor, the logic comprising: receiving a request to create a container; obtaining a container image manifest for the container; Mounting a file system of the container using the manifest; Identifying, after creation of the container, a request for access to data within the container image for the container by the file system mounted for the container; utilizing the manifest of the container image to determine whether requested data is locally present in a cache; retrieving the data from the cache in response to determining that the manifest of the container image indicates that the data is stored locally in the cache; and retrieving the data from a content store in response to determining that the manifest of the container image indicates that the data is not locally available to the cache; and 2. A system configured to:

Images