Method and apparatus for loading container images

Abstract

To provide methods, apparatus, systems, and articles of manufacture for loading of a container image.SOLUTION: An example apparatus includes a prioritizer to determine a priority level at which a container is to be executed. A container controller determines a first expected location for a first set of layers of the container, the container controller to determine a second expected location for a second set of layers of the container, the first expected location and the second expected location are determined based on the determined priority level, the second set of layers are separated from the first set of layers in an image by a landmark. A container loader mounts the first set of layers from the first expected location. A container executor initiates execution of the container based on the mounted first set of layers.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure generally relates to container-based computing, and more particularly enables an efficient load of container images.

Background Art

[0002] A container is a virtual structure used for running isolated instances of applications within a host virtualization environment. Containers are used to facilitate operating system virtualization, thereby abstracting (e.g., isolating) applications from the operating system. As a result, an application running in a first container is isolated from another application (possibly a copy of the same application) running outside the container (e.g., the host operating system or another container).

Brief Description of the Drawings

[0003] [Figure 1A] A block diagram showing a first exemplary container image without a landmark and a second exemplary container image with a landmark. [Figure 1B] A block diagram showing an exemplary container. [Figure 2] A block diagram of an exemplary computing system implemented in accordance with the teachings of the present disclosure to enable lazy loading of container images. [Figure 3] An exemplary priority level for a memory mapping table that can be used to identify locations for storage of layers of a container. [Figure 4] A flowchart representing exemplary machine-readable instructions that can be executed to implement the exemplary computing system of FIG. 2 for compressing and storing a container. [Figure 5]This flowchart represents exemplary machine-readable instructions that can be executed to implement the exemplary computing system shown in Figure 2 in order to load containers for execution. [Figure 6] Figure 2 is an example block diagram of a processor platform structured to execute the instructions in Figures 4 and / or 5, in order to implement the exemplary computing system in Figure 2. [Figure 7] This is a block diagram of an exemplary software distribution platform for distributing software (e.g., software corresponding to the exemplary computer-readable instructions in Figures 4 and / or 5) to client devices such as consumers (e.g., for licensing, sales, and / or use), retailers (e.g., for sales, resale, licensing, and / or sublicensing), and / or original equipment manufacturers (OEMs) (e.g., for inclusion in products distributed to retailers and / or sold directly to customers). [Figure 8] This figure shows exemplary performance improvements resulting from using the exemplary approaches disclosed herein.

[0004] The numbers are not to scale. Generally, the same reference number is used throughout the drawings and accompanying written descriptions to refer to the same or similar parts.

[0005] Unless otherwise specified, descriptors such as “First,” “Second,” and “Third” are used solely as labels and / or arbitrary names to distinguish elements for the sake of clarity in the disclosed examples, without supplementing or otherwise indicating the meaning of priority, physical order, placement in a list, and / or any order. In some examples, the descriptor “First” may be used to refer to an element in a mode for carrying out the invention, but the same element may be referred to in the claims using different descriptors such as “Second,” “Third,” etc. In such cases, it should be understood that such descriptors are used solely to distinguish these elements, for example, which may otherwise share the same name. [Modes for carrying out the invention]

[0006] Operating system (OS) level virtualization allows multiple isolated user-space instances to run on a computing system. These instances are typically called containers, but may be additionally or alternatively referred to as zones, virtual private servers, partitions, virtual environments (VEs), virtual kernels, jails, and so on. Such containers appear to function as complete computer systems from the perspective of the applications running within them. However, while applications running on traditional computer operating systems can access the computer's resources (e.g., connected devices, file systems, network shares), applications running within a container can only access resources associated with that container. In other words, an application cannot access resources outside of its container (e.g., resources in another container, resources of the host operating system, etc.) other than those outside the container that the application is specifically permitted to access.

[0007] For this purpose, containers are useful from a resource management perspective (for example, resources used by containerized components are isolated so that they are used only by components that are part of the same container) and / or from a security perspective (for example, access to containerized files or components can be restricted). Similarly, containers are useful for achieving lightweight and reproducible application deployments. In this way, containers are frequently used in cloud computing environments to allow resources to be allocated, deleted, and / or reallocated on demand.

[0008] Before a container is run in the host environment, it is stored as a container image that specifies the components of the container, including, for example, libraries, binaries, and / or other files necessary for the container to run.

[0009] From a storage perspective, containers differ from container images in that the container image represents the base on which the container starts. A container adds a readable and writable "thin" layer on top of the image. Any changes a container attempts to make to the contents of files within the image trigger a copy-on-write mechanism, creating a copy from the image to the thin layer of files instead, which is then used by the container for both reading and writing purposes. Thus, container images, and more generally containers, differ from virtual machine images (or other data structures) in that changes made to a virtual machine image by an application running within the virtual machine cause writes to the image itself.

[0010] A container image can contain one or more container layers, which can be thought of as the basic unit of container storage. Each layer adds a different set of files and folders to the entire image. The container layers of an image are considered read-only and are often reused as building blocks for one or more containers that can share them (for example, two containers with the same operating system will share the layer representing that OS). When a container is created, the container runtime engine (e.g., the entity that creates and manages containers for the lifetime of a container) has a handler responsible for ensuring that all the layers necessary to create the container are on disk, and if they are unavailable, retrieving them from remote storage over the network, and creating the last thin layer (container-specific) that the container can read and write. This approach is called copy-on-write and prevents the container from writing to files in the read-only layer. Therefore, once a decision is made to run the container in the host environment, the container runtime engine pulls all missing layers from the container registry (e.g., over the network), creates a small copy-on-write layer, mounts all layers to the new container (the mount operation does not involve read, write, or run operations), and loads or runs any binaries or programs specified to run from the final image. These steps of creating container storage are typically referred to as the pull phase, the create phase (including mounting), and the run phase. These steps are the main source of overhead when launching a container and should be mitigated.

[0011] In Function-as-a-Service (FAAS) and Container-as-a-Service (CAAS) environments, container startup time significantly impacts Quality of Service (QoS) from the end-user's perspective. Cold start time, i.e., the time required to launch a container from a command, involves three preparation steps (pull, create, and run) before the first execution on the machine is complete. The impact on functional performance can be significant depending on how many layers are missing and how long it takes to create and mount all container layers. This cold start time can also be influenced by runtime requirements for processing large or numerous files for the first time, and high latency in file operations. High latency and volatile runtimes are unacceptable in some use cases (e.g., real-time processing, streaming, sub-second functionality). Furthermore, for workloads considered high priority, startup time (and its variability) should ideally be reduced and / or minimized. The exemplary approaches disclosed herein enable reduced container startup time, particularly in FaaS and CaaS environments. Furthermore, most hosts for FaaS / CaaS services desire predictable runtimes with low variability, as long cold starts can result in high charges for customers (if billed by time) or losses for providers (if cold starts are not billed). In addition, the examples disclosed herein provide differentiated services based on the priority and / or importance of specific containers.

[0012] Existing approaches attempt to minimize cold start times by keeping containers warm; that is, the container image is stored in DRAM using a RAM disk. However, continuously storing container images in DRAM is a costly solution, especially if those containers are not actively used.

[0013] Several other existing approaches attempt to overcome the latency associated with downloading the full image to disk to start a container, instead offering lazy loading of the image. In such traditional approaches, the container can start once the critical parts of the image have been downloaded to storage, while other layers are downloaded after the container has started and pulled from the registry during execution.

[0014] As described herein, the use of tiered storage topologies (e.g., based on Intel® 3D XPoint) can further improve cold start times, increase the density of functionality deployed in the system, and provide differentiated services (e.g., improved load times based on workload prioritization). In this way, tiered storage topologies (e.g., based on Intel® 3D XPoint) are used to provide differentiated services and reduce container cold start times in FaaS / CaaS deployments. In some examples, Intel® Resource Director Technology (Intel® RDT) is used to further expand service differentiation and improve performance predictability (e.g., container runtime). Thus, the exemplary approaches disclosed herein have the additional benefit of extending the concept of image lazy loading in the context of tiered storage systems and providing varying levels of performance and / or predictability using different tiers of the tiered storage system.

[0015] Figure 1A is a block diagram showing a first exemplary container image 110 without landmarks and a second exemplary container image 120 with landmarks. The first exemplary container image 110 in Figure 1A is compressed using a first compression format that does not use landmarks. In the exemplary example of Figure 1A, the first compression format represents the stargz compression format. The first exemplary container image 110 in Figure 1A includes a first layer 131, a second layer 132, a third layer 133, a fourth layer 134, a fifth layer 135, a table of contents 140, and a footer 145. Each of the first layer 131, second layer 132, third layer 133, fourth layer 134, and fifth layer 135 corresponds to the respective section of image 110. As shown in the exemplary example of Figure 1A, each of the layers 131, 132, 133, 134, and 135 is a TAR archive. However, any other past, present, and / or future archiving format may be used additionally or alternatively. In the exemplary example in Figure 1A, the first layer 131 and the fourth layer 134 represent the layers required for the immediate execution of the container. In this way, the second layer 132, the third layer 133, and the fifth layer 135 are not required for the immediate execution of the image.

[0016] In the illustrative example in Figure 1A, the table of contents 140 contains image metadata and offset information. In some examples, the table of contents 140 is formatted using JSON (JavaScript Object Notation). However, any other data format may be used additionally or alternatively. The illustrative footer 145 represents the offset from the table of contents 140.

[0017] The second exemplary image 120 in Figure 1A includes a first layer 131, a second layer 132, a third layer 133, a fourth layer 134, a fifth layer 135, a table of contents 140, and a footer 145. The second exemplary container image 120 in Figure 1A is compressed using a second compression format that includes a landmark 150. In contrast to the first exemplary image 110, the first layer 131 and the fourth layer 134 are placed before the landmark 150 in the second image 120. The second layer 132, the third layer 133, and the fifth layer 135 are placed after the landmark 150.

[0018] By using landmark 150, layers of the image prior to landmark 150 can be prefetched for loading into memory. In some examples, prefetching layers prior to landmark 150 is performed using a single operation. In the illustrative example in Figure 1A, the layers of the image required for the execution of the container (e.g., the first layer 131 and the fourth layer 134) are placed prior to the landmark, but such layers can be pulled into storage rather than requiring the entire image to be available on disk. Such prefetching and / or loading of specific layers of an image (e.g., layers required for immediate execution of the image) is called delayed loading and / or delayed image pulling.

[0019] In the illustrative example in Figure 1A, the second compression format is implemented using the estargz compression format. However, any other compression format that uses landmarks and / or otherwise enables prefetching of a range of layers of an image may be used additionally or alternatively.

[0020] In the exemplary example of FIG. 1A, the exemplary images are shown as each having five layers, but in reality, the container images may include any number of layers. Further, the exemplary images of FIG. 1A show two layers as being necessary for the immediate execution of the images, but in reality, any number of such layers may be identified as being necessary for the immediate execution of the images.

[0021] FIG. 1B is a block diagram showing an exemplary container 151. As described above, a container is different from a container image in that the container represents the base from which the container starts. In the exemplary example of FIG. 1B, the exemplary container 150 includes a "thin" layer 160 that is readable and writable. The container 150 also includes an image layer 170 that includes a first layer 171, a second layer 172, a third layer 173, and a fourth layer 174. Changes that the container attempts to make to the contents of files within the image layer 170 trigger a copy-on-write mechanism, which instead creates a copy from the image 170 to the thin layer 160 of the file, which is used by the container for both read and write purposes.

[0022] FIG. 2 is a block diagram of an exemplary container runtime engine 201 implemented in accordance with the teachings of the present disclosure to enable the lazy loading of container images. The exemplary container runtime engine 201 of the exemplary example of FIG. 2 includes a container layer manager 205 and computing resources 207. The exemplary computing resources 207 include a first-tier storage device 220, a second-tier storage device 225, a third-tier storage device 230, and an nth-tier storage device 235. The exemplary container layer manager 205 of the exemplary example of FIG. 2 includes a container compressor 250, a prioritizer 270, a container controller 275, a container loader 280, and a container executor 290. The exemplary container runtime engine 201 communicates with a container registry 295 via a network 296.

[0023] The first tier storage device 220, exemplary second tier storage device 225, exemplary third tier storage device 230, and exemplary Nth tier storage device 235 of the exemplary example of FIG. 2 are implemented by storage devices having different performance characteristics. For example, the first tier memory device 220 of the exemplary example of FIG. 2 has the highest performance characteristics (e.g., the highest read / write rate, the highest bandwidth, etc.), and the Nth tier memory device 235 of the exemplary example of FIG. 2 has the lowest performance characteristics (e.g., the lowest read / write rate, the lowest bandwidth, etc.). There are various trade-offs for using higher performance memory devices. For example, low latency storage devices such as DRAM disks are very expensive to implement in large quantities and / or have low reliability. In contrast, low performance memory devices are easy to implement in large quantities and / or have high reliability.

[0024] In the exemplary example in Figure 2, the first tier storage device 220 is implemented using a dynamic random access memory (DRAM) disk (e.g., a slice of DRAM memory allocated to and mounted on the machine as a storage device). The exemplary second tier memory device 225 in the exemplary example in Figure 2 is implemented using persistent memory such as Intel® Optane® DC Persistent Memory (DCPMM). In some examples, the persistent memory operates in "App Direct" mode. In this way, the second tier storage device 225 has slightly lower performance characteristics than the first tier memory device 230. The exemplary third tier storage device 230 is implemented using a solid-state drive (SDD) such as Intel® Optane® DC Solid State Drive (SDD). The exemplary nth tier storage device 235 is implemented using a legacy solid-state drive and / or conventional hard disk drive (HDD) to operate the memory device 235. In the exemplary example shown in Figure 2, four tier storage devices are depicted, but any number of tier storage devices may be used additionally or alternatively. Furthermore, different memory technologies may be used to implement each tier storage device. For example, the first tier storage device 220 may be implemented by persistent memory (e.g., Intel® Optane® DC Persistent Memory (DCPMM)).

[0025] The exemplary container compressor 250 in the exemplary example of Figure 2 constructs the container image using a compression format that includes landmarks. In the examples disclosed herein, the use of landmarks in the compression format makes it possible to pull the compressed image layers into different memory tiers for storage. In the examples disclosed herein, the estargz compression format is used. However, any other compression format that uses landmarks and / or otherwise enables segmentation of layers for loading into working memory may be used additionally or alternatively. In this way, a second set of layers (e.g., layers appearing after landmarks) can be given lower priority and / or later placed in a slower storage tier. Thus, different layers from different media are mounted and a thin layer of the container itself is created (e.g., on the fastest available storage device) before the container is ready to enter the run phase. After this layer is mounted to the container, execution can begin. In some examples, the exemplary container compressor 250 is implemented by compression means.

[0026] The exemplary priorityizer 270 in the exemplary example of Figure 2 determines the priority level to which a container should be given priority. In the examples disclosed herein, the priority of a container is determined based on instructions included in a request to store the container received by the container controller 275. Such instructions may be provided, for example, by the user who submitted the request. However, the priority of a container may also be determined based on other criteria, including, for example, the execution history of the container, the type of operation performed by the container, etc. In some examples, the priority may correspond to a desired latency for the execution of the container, a desired QoS (Quality of Service), etc. In some examples, the priorityizer is extended to use Intel® Resource Director Technology (Intel® RDT). In some examples, the priorityizer 270 is implemented by compression means.

[0027] The exemplary container controller 275 in the exemplary example of Figure 2 selects a storage location based on the priority level to which the container should be preferred. Using the priority levels identified by the priorityizer 270, the exemplary container controller 275 refers to a priority mapping table (e.g., the mapping table 300 disclosed below in relation to Figure 3). The container controller 275 communicates with the container registry 295 and pulls the layers to their appropriate storage devices. In some examples, the exemplary container controller 275 is implemented by control means.

[0028] The exemplary container loader 280 in the exemplary example of Figure 2, in response to a request to load a container, refers to the container registry 278 to identify the location of the first set of layers in first memory and performs one or more actions to pull the layers of the container to the appropriate storage device. In some examples, the container loader 280 omits the performance of the load operation if, for example, the data is already stored on disk (e.g., the layers of the image are already in storage). In such examples, move and / or copy commands may be executed by the container loader 280 to move and / or copy the layers of the image to the appropriate storage medium for execution. In some examples, the exemplary container loader 280 is implemented by a load means.

[0029] In the exemplary container executor 290 in the exemplary example of Figure 2, the exemplary container executor 290 triggers container execution when the layers up to the landmark have been pulled into the appropriate storage and a thin read / write layer has been created. For example, after mounting the first layer set and creating and mounting the thin R / W layer, the exemplary container executor 290 may trigger container execution using the first layer set, while the container loader 280 continues loading the second layer set to the rest of the storage medium. In some examples, the exemplary container executor 290 is implemented by an execution means.

[0030] The exemplary container registry 295 in Figure 2 stores container images for extended periods to prevent local storage devices from overloading. In some examples, the container registry 295 is referred to as a container repository. The exemplary container registry 295 is implemented by exposing REST-like endpoints for storage devices (e.g., flash memory, magnetic media, optical media, solid-state disks, hard drives, etc.). Furthermore, the data stored in the exemplary container registry 278 includes read-only container images, as described above in relation to Figures 1A and 1B, stored layer by layer. The container registry typically stores layers in targz format, which is backward compatible with the estargz format and its landmarks. In the exemplary example in Figure 2, the exemplary container registry 278 also stores an indication of which storage / storage medium the container layers should be pulled from. In some examples, the container registry 278 additionally stores priority levels to a memory tier mapping table, as disclosed below in relation to Figure 3.

[0031] In the exemplary example of Figure 2, the exemplary network 296 is implemented by the internet. However, exemplary network 296 may be implemented by any other network that facilitates data communication between exemplary container runtime engine 201 and container registry 295. In some examples, network 296 is implemented as a local area network (LAN), but it may be additionally or alternatively implemented as a wide area network (WAN), virtual private network (VPN), etc. In some examples, network 296 may represent multiple networks.

[0032] Figure 3 shows priority levels to a memory tier mapping table 300 that can be used to identify locations for storage of container layers. The exemplary mapping table 300 in the exemplary example of Figure 3 includes a priority level column 310, a storage location column 320 for a first set of layers, and a storage location column 330 for a second set of layers. The exemplary mapping table 300 includes a first row 340 that identifies where the first and second layers of a high-priority container should be stored (e.g., within the first-tier storage and the second-tier storage). The exemplary mapping table 300 includes a second row 350 that identifies where the first and second layers of a medium-priority container should be stored (e.g., within the first-tier storage and the third-tier storage). The exemplary mapping table 300 includes a third row 360 that identifies where the first and second layers of a low-priority container should be stored (e.g., within the second-tier storage and the third-tier storage).

[0033] In the illustrative example in Figure 3, three priority levels are shown, but any number of priority levels may be used. For example, a system with two priority levels (e.g., high priority and low priority) or a system with three priority levels (e.g., high priority, medium priority, and low priority) may be used. As an alternative example of the mapping table 300 in Figure 3, in a two-priority level implementation, the first layer of a first container having a first priority (e.g., high priority) may be stored in the first tier memory device 220, and the second layer of the first container may be stored in the second tier memory device 225. In the same alternative example, the first layer of a second container having a second priority (e.g., low priority) may be stored in the second tier memory device 225, and the second layer of the second container may be stored in the third tier memory device 230. Defining additional priority levels allows for different combinations of memory device tiers for storing the layers of containers used.

[0034] Furthermore, while the example shown in Figure 3 defines two storage locations for each priority level, in some examples, additional storage locations may be defined for each priority level. For example, a third layer set may have its own storage location defined. In such examples, multiple landmarks are detected within the compressed image, enabling identification of the first, second, and third layer sets.

[0035] Figure 2 shows an exemplary implementation of the container layer manager 205, but one or more of the elements, processes, and / or devices shown in Figure 2 may be combined, split, rearranged, omitted, removed, and / or implemented in any other way. Furthermore, the exemplary container compressor 250, exemplary priorityizer 270, exemplary container controller 275, exemplary container loader 280, exemplary container executor 290, and / or more generally, the exemplary container layer manager 205 in Figure 2 may be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Therefore, for example, any of the exemplary container compressor 250, exemplary priority locator 270, exemplary container controller 275, exemplary container loader 280, exemplary container executor 290, and / or more generally, the exemplary container layer manager 205 in Figure 2 may be implemented by one or more analog or digital circuits, logic circuits, programmable processors, programmable controllers, graphics processing units (GPUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field-programmable logic devices (FPLDs). When reading any of the claims for an apparatus or system of this patent purely to cover the implementation of software and / or firmware, at least one of the exemplary container compressor 250, exemplary priority locator 270, exemplary container controller 275, exemplary container loader 280, exemplary container executor 290, and / or more generally, the exemplary container layer manager 205 in Figure 2 is expressly defined herein as including a non-temporary computer-readable storage device or storage disk such as memory, a digital versatile disc (DVD), a compact disc (CD), or a Blu-ray® disc containing software and / or firmware.Furthermore, the exemplary container layer manager 205 in Figure 2 may include, in addition to or instead of, one or more elements, processes, and / or devices shown in Figure 2, and / or one or more of any or all of the elements, processes, and devices shown. As used herein, the phrase “communicating,” including its variations, encompasses direct and / or indirect communication through one or more intermediate components, and does not require direct physical (e.g., wired) communication and / or constant communication, but rather includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and / or one-time events.

[0036] Figures 4 and / or 5 show flowcharts representing exemplary hardware logic, machine-readable instructions, a hardware implementation state machine, and / or any combination thereof for implementing the container layer manager 205 of Figure 2. The machine-readable instructions may be one or more executable programs or parts thereof for execution by a computer processor and / or processor circuit, for example, a processor 612 shown in the exemplary processor platform 600 described later in relation to Figure 6. The program may be implemented as software stored on a non-temporary computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, DVD, Blu-ray disk, or memory associated with the processor 612; however, alternatively, the entire program and / or parts thereof may be executed by a device other than the processor 612 and / or implemented in firmware or dedicated hardware. Furthermore, although the exemplary program is described with reference to the flowcharts shown in Figures 4 and / or 5, many other methods for implementing the exemplary container layer manager 205 may be used alternatively. For example, the execution order of blocks can be changed, and / or some of the described blocks can be modified, deleted, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and / or integrated analog and / or digital circuits, FPGAs, ASICs, comparators, operational amplifiers (op-amps), logic circuits, etc.) structured to perform the corresponding operations without running software or firmware. The processor circuits may be distributed to different network locations and / or locally to one or more devices (e.g., a multi-core processor in a single machine, multiple processors distributed in a server rack, etc.).

[0037] The machine-readable instructions described herein may be stored in one or more of the following formats: compressed format, encrypted format, fragmented format, compiled format, executable format, packaged format, etc. The machine-readable instructions described herein may be stored as data or data structures (e.g., instruction parts, code, code representations, etc.) that can be used to create, manufacture, and / or generate machine-executable instructions. For example, machine-readable instructions may be fragmented and stored in one or more storage devices and / or computing devices (e.g., servers) located at the same or different locations in a network or set of networks (e.g., a cloud, edge devices, etc.). Machine-readable instructions may require one or more of the following to be directly readable, interpretable, and / or executable by computing devices and / or other machines: installation, modification, adaptation, updating, combination, supplementation, configuration, decryption, decompression, unpacking, distribution, reallocation, compilation, etc. For example, machine-readable instructions may be stored in multiple parts, each individually compressed, encrypted, and stored on separate computing devices, which, when decrypted, decompressed, and combined, form a set of executable instructions that implement one or more functions, which together can form a program as described herein.

[0038] In another example, machine-readable instructions may be stored in a state in which they can be read by processor circuitry, but additional libraries (e.g., dynamic link libraries (DLLs)), software development kits (SDKs), application programming interfaces (APIs), etc., may be required to execute the instructions on a particular computing device or other device. In yet another example, machine-readable instructions (e.g., stored settings, data inputs, recorded network addresses, etc.) may need to be set before the machine-readable instructions and / or corresponding programs can be executed in whole or in part. Thus, machine-readable media used herein may contain machine-readable instructions and / or programs stored, or not stored, in a stationary or transporting state, regardless of the specific format or state of the machine-readable instructions and / or programs.

[0039] The machine-readable instructions described herein may be expressed in past, present, or future instruction languages, scripting languages, programming languages, etc. For example, machine-readable instructions may be expressed using any of the following languages: C, C++, Java, C#, Perl, Python, JavaScript, HTML (HyperText Markup Language), SQL (Structured Query Language), Swift, Go, etc.

[0040] As described above, the exemplary processes in Figures 4-5 may also be implemented using executable instructions (e.g., computer and / or machine-readable instructions) stored in non-temporary computer and / or machine-readable media such as hard disk drives, flash memory, read-only memory, compact disks, digital multipurpose disks, caches, random access memory, and / or any other storage devices or storage disks, where information is stored for any duration (e.g., long-term, permanent, short-term, brief moment, temporary buffer, and / or cache of information). As used herein, the term non-temporary computer-readable media includes any type of computer-readable storage device and / or storage disk and is explicitly defined to exclude propagating signals and transmission media.

[0041] The terms “including” and “comprising” (and all their forms and tenses) are used herein as open-ended terms. Therefore, whenever a claim uses any form of “include” or “comprise” (e.g., including comprises, includes, comprising, including, having, etc.) as a preamble or within the description of any type of claim, it should be understood that additional elements, terms, etc., may exist without exceeding the scope of the corresponding claim or description. When used herein, for example, when the phrase “at least” is used as a transitional clause in the preamble of a claim, it is open-ended, just as the terms “comprising” and “including” are open-ended. The term "and / or" refers to any combination or subset of A, B, and C, for example, when used in the form of A, B, and / or C, such as (1) A only, (2) B only, (3) C only, (4) A and B, (5) A and C, (6) B and C, (7) A, B, and C. When used herein in the context of describing a structure, component, item, object, and / or thing, the phrase "at least one of A and B" is intended to refer to an implementation that includes either (1) at least one A, (2) at least one B, or (3) at least one A and at least one B. Similarly, when used herein in the context of describing a structure, component, item, object, and / or thing, the phrase "at least one of A or B" is intended to refer to an implementation that includes either (1) at least one A, (2) at least one B, or (3) at least one A and at least one B. When used herein in the context of describing the performance or execution of a process, instruction, action, activity and / or step, the phrase "at least one of A and B" is intended to refer to an implementation that includes (1) at least one A, (2) at least one B, or (3) at least one A and at least one B.Similarly, when used herein in a context describing the execution of a process, instruction, action, activity and / or step, the phrase “at least one of A or B” is intended to refer to an implementation that includes (1) at least one A, (2) at least one B, or (3) at least one A and at least one B.

[0042] Where used herein, singular references (e.g., “a,” “an,” “first,” “second,” etc.) do not exclude plurals. Where used herein, the entity referred to as “a” or “an” refers to one or more of those entities. The terms “a” (or “an”), “one or more,” and “at least one” may be used interchangeably herein. Furthermore, multiple means, elements, or method actions, although individually listed, may be implemented, for example, by a single unit or processor. In addition, individual features may be included in different examples or claims, but they may be combined, and their inclusion in different examples or claims does not imply that the combination of features is unfeasible and / or advantageous.

[0043] Figure 4 is a flowchart representing exemplary machine-readable instructions that can be executed to implement the exemplary computing system of Figure 2 for compressing and storing an image. The exemplary process 400 in the exemplary example of Figure 4 begins when the exemplary container compressor 250 constructs an image of a container using a compression format that includes landmarks (block 410). In the examples disclosed herein, the use of landmarks in the compression format allows for the segmentation of the layers of the compressed image into different memory tiers for storage. As a result of the segmentation, the different segments can be requested and / or pulled to their respective tier storage devices (e.g., first-tier storage device 220, second-tier storage device 225, third-tier storage device 230, nth-tier storage device 235, etc.) based on their priority. In the examples disclosed herein, the estargz compression format is used. However, any other compression format that uses landmarks and / or otherwise allows for the segmentation of layers for loading into working memory may be used additionally or alternatively. The exemplary container compressor 250 sends the image for storage to the container registry 295. (Block 420). The exemplary process 400 in Figure 4 terminates, but may be repeated if there is a subsequent request to build an image for storage in the container registry 295, for example.

[0044] Figure 5 is a flowchart representing exemplary machine-readable instructions that can be executed to implement the exemplary computing system of Figure 2 for loading containers for execution. The exemplary process 500 in the exemplary example of Figure 5 begins when the exemplary container controller 275 identifies the container to be loaded for execution (block 505). The container may be identified based on a request to run the container received, for example, from a user or any other entity.

[0045] An exemplary priorityizer 270 determines the priority level to which a container should be given priority (block 510). In the examples disclosed herein, the priority of a container is determined based on instructions included in the request to run the container. Such instructions may be provided, for example, by the user who submitted the request to run the container. However, the priority of a container may also be determined based on other criteria, including, for example, the execution history of the container, the type of operation performed by the container, etc. In some examples, the priority may correspond to a desired latency for running the container, a desired QoS (Quality of Service), etc.

[0046] An exemplary container controller 275 identifies a first expected location of a first set of layers in a container image based on the priority level identified by the priorityizer 270 (block 515). In some examples, the container controller 275 refers to a priority mapping table (e.g., the mapping table 300 in Figure 3, which may be stored in the container registry 295 or in the local memory and / or storage device of the container runtime engine 201) to identify the first expected location of the first set of layers. Any number of priorities may be used in the examples disclosed herein. For example, a system with two priority levels (e.g., high priority and low priority) or a system with three priority levels (e.g., high priority, medium priority, low priority) may be used. As an example, in a two-priority-level implementation, the first layer of a first container having a first priority (e.g., high priority) may be stored in a first tier memory device 220, and the second layer of the first container may be stored in a second tier memory device 225. In the same example, the first layer of a second container having a second priority (e.g., a lower priority) may be stored in the second tier memory device 225, and the second tier of the second container may be stored in the third tier memory device 230. Defining additional priority levels allows for different combinations of memory device tiers for storing the layers of containers used.

[0047] The exemplary container loader 280 determines whether the first layer set exists at the first expected location (block 520). If the exemplary container loader 280 determines that the first layer set exists at the first expected location (for example, block 520 returns a YES result), the exemplary container loader 280 mounts the first layer set from the first expected location (block 525). In this way, the first layer set can begin execution from the selected layer of the storage device, and the remaining layers are loaded (or retrieved).

[0048] If the exemplary container loader 280 determines that the first layer set does not exist at the first expected location (for example, block 520 returns a NO result), the exemplary container loader 280 determines whether the first layer set of the image exists on another storage device of the container runtime engine 201 (block 530). If the first layer set of the image does not exist on another storage device of the container runtime engine 201 (for example, block 530 returns a NO result), the exemplary container controller 275 pulls the first layer set from the container registry to the first expected location (block 535). The exemplary container loader 280 then mounts the first layer set from the first expected location (block 525).

[0049] In some examples, the first set of layers in a container may not yet exist in the first expected location (e.g., block 520 returns NO), but may exist in a different storage device of the container runtime engine 201 (e.g., block 530 returns YES). Such situations may, in some examples, result from a change in the container's priority level. Such a change may be made to increase the container's priority level (e.g., layers will be loaded from a faster storage device), or alternatively, to decrease the container's priority level (e.g., layers will be loaded from a slower storage device).

[0050] If the exemplary container loader 280 determines that the first layer set of the image does not exist at the first expected location but exists at another location on the container runtime engine 201 (for example, block 530 returns a YES result), the exemplary container loader 280 mounts the first layer set from the current location (block 540). In such an example, using the first layer set from the current location not only results in improved loading performance compared to pulling the first layer set from the container registry 295, but also saves network bandwidth that would have been consumed by pulling the first layer set from the container registry 295.

[0051] After mounting the first layer set from its current location (block 540), the exemplary container loader 280 moves and / or copies the first layer set to a first expected location (block 545). Such move / copy operations are performed in the background to ensure that the first layer set is present at the first expected location when a subsequent request to run the container is made. In some examples, after moving / copying the first layer set to the first expected location, the first layer set is remounted from the first expected location. In some alternative examples, the first layer set is first moved to the first expected location and mounted from there (for example, the first layer set is moved / copied to the first expected location while being mounted from its current location).

[0052] Once the first layer set is mounted (e.g., from the first expected position in block 525, or from the current position in block 540), the exemplary container executor 290 begins executing the container (block 550). In some examples, getting the container executor 290 to execute the container involves initializing thin read / write layers. In this way, the first layer set is implemented and can be done from a first storage device (e.g., where the second layer set of the image may be stored) which is implemented using memory techniques that provide improved performance compared to the second storage device, so that critical components of the container can be mounted more quickly, less critical components of the container can be mounted, and / or, otherwise, execution can be made available in a delayed manner. Such an approach reduces the cold start time of container execution.

[0053] The exemplary container controller 275 identifies the second expected location of the second layer set of the container image based on the priority level identified by the priorityizer 270 in block 515 (block 555). In some examples, the identification of the second expected location of the second layer set may be performed concurrently with the identification of the first expected location of the first layer set. In other words, after identifying the priority level of the container, the exemplary controller 275 can determine each of the locations where the layers of the container image are expected to be stored.

[0054] The exemplary container loader 280 determines whether the second layer set exists at the second expected location (block 560). If the exemplary container loader 280 determines that the second layer set exists at the second expected location (for example, block 560 returns YES), the exemplary container loader 280 mounts the second layer set from the first expected location (block 565). In this way, the second layer set can be accessed as part of the container execution. In the exemplary example of Figure 5, the second layer set is mounted from the second expected location. In some examples, the second expected location may correspond to a storage device that is efficient for storing the second layer set but inefficient for executing the second layer set. Therefore, in some examples, instead of directly mounting the second layer set from the second expected location, the exemplary container loader 280 may copy the second layer set to another location for mounting. In other words, if the second expected location corresponds to the third tier storage device 230, the second layer set may be copied to the second tier storage device 225 (or the first tier storage device 220) for mounting and execution. After the container has run, the second layer set may be removed from the location to which they were temporarily copied for execution.

[0055] If the exemplary container loader 280 determines that the second layer set does not exist at the second expected location (for example, block 560 returns NO), the exemplary container loader 280 determines whether the second layer set of the image exists on another storage device of the container runtime engine 201 (block 570). If the second layer set of the image does not exist on another storage device of the container runtime engine 201 (for example, block 570 returns NO), the exemplary container controller 275 pulls the second layer set from the container registry to the second expected location (block 575). The exemplary container loader 280 then mounts the second layer set from the second expected location (block 565).

[0056] In some examples, the container's second layer set may not yet exist at the second expected location (e.g., block 560 returns NO), but may exist on a different storage device of the container runtime engine 201 (e.g., block 570 returns YES). Such situations may, in some examples, result from a change in the container's priority level. Such a change may be made to increase the container's priority level (e.g., layers will be loaded from a faster storage device), or alternatively, to decrease the container's priority level (e.g., layers will be loaded from a slower storage device).

[0057] If the exemplary container loader 280 determines that a second layer set of the image does not exist at a second expected location but does exist at another location on the container runtime engine 201 (for example, block 530 returns a YES result), the exemplary container loader 280 mounts the second layer set from the current location (block 580). In such an example, using the second layer set from the current location not only results in improved loading performance compared to pulling the second layer set from the repository, but also saves network bandwidth that would have been consumed by pulling the second layer set from the container registry 295.

[0058] After mounting the second layer set from its current location (block 580), the exemplary container loader 280 moves and / or copies the second layer set to a second expected location (block 585). Such move / copy operations are performed in the background, ensuring that when there is a subsequent request to run the container, the second layer set is present at the second expected location. In some examples, after moving / copying the second layer set to the second expected location, the second layer set is remounted from the second expected location. In some alternative examples, the second layer set is moved to the second expected location and mounted from there (for example, the second layer set is moved / copied to the second expected location while being mounted from its current location).

[0059] When a second layer set is mounted (for example, from a second expected position in block 525, or from the current position in block 540), the container executor 290 continues the execution of the container using the layers in the second layer set mounted in a delayed manner, if necessary. As described above, such an approach reduces the cold start time of the container execution. Next, the exemplary process 500 in Figure 5 terminates (for example, while the container execution continues). The exemplary process 500 in Figure 5 may be repeated, for example, if there is a subsequent request to run the container.

[0060] For example, if a subsequent request for container execution (e.g., a second request) is received, and the initial request is to request container execution and has changed the container's priority level (e.g., causing the first and / or second layer sets to move to new expected locations, as described in blocks 540, 545, 580, and 585 respectively), then the container execution in the context of the second request will result in mounting from the expected locations (e.g., blocks 525 and 565). As a result, the time it takes to start execution in response to the second request is improved compared to the time it takes to start execution in response to the first request, because it is no longer necessary to move the first and / or second layer sets to their new expected locations. Thus, a change in the container's priority indicated by a request for container execution does not affect the loading and / or execution of the container in response to the request, but the subsequent execution of the container may benefit from the adjusted priority level.

[0061] In the illustrative example in Figure 5, the adjustment of the location where the container image layers are stored is performed in the context of a request to run the container; however, such adjustments do not have to be performed only in response to such a request, and in some examples, they are performed after an instruction that the container's priority level should be changed. In other words, the location of the first layer set and / or the second layer set may be changed independently of the request to run the container associated with the layers.

[0062] Figure 6 is a block diagram of an exemplary processor platform 200 configured to execute the instructions in Figure 4 and / or Figure 5 in order to implement the container layer manager 205 of Figure 2. The processor platform 600 could be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a mobile phone, a smartphone, a tablet such as an iPad™), a personal digital assistant (PDA), an internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a game console, a personal video recorder, a set-top box, a headset, or other wearable devices, or other types of computing devices.

[0063] The processor platform 600 in the example shown includes a processor 612. The processor 612 in the example shown is hardware. For example, the processor 612 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers of any desired family or manufacturer. The hardware processor may also be a semiconductor-based (e.g., silicon-based) device. In this example, the processor implements an exemplary container compressor 250, an exemplary priorityizer 270, an exemplary container controller 275, an exemplary container loader 280, and an exemplary container executor 290.

[0064] The processor 612 in the shown example includes local memory 613 (e.g., cache). The processor 612 in the shown example communicates with main memory, which includes volatile memory 614 and non-volatile memory 616, via bus 618. The volatile memory 614 may be implemented by SDRAM (Synchronous Dynamic Random Access Memory), DRAM (Dynamic Random Access Memory), RDRAM® (RAMBUS® Dynamic Random Access Memory), and / or any other type of random access memory device. The non-volatile memory 616 may be implemented by flash memory and / or any other desired type of memory device. Access to main memory 614, 616 is controlled by a memory controller.

[0065] The example processor platform 600 also includes an interface circuit 620. The interface circuit 620 may be implemented by any type of interface standard, such as an Ethernet® interface, a Universal Serial Bus (USB), a Bluetooth® interface, a Near Field Communication (NFC) interface, and / or a PCI Express interface.

[0066] In the example shown, one or more input devices 622 are connected to the interface circuit 620. The input devices 622 allow the user to input data and / or commands to the processor 612. The input devices can be implemented, for example, by audio sensors, microphones, cameras (still or video), keyboards, buttons, mice, touchscreens, trackpads, trackballs, IsoPoint, and / or speech recognition systems.

[0067] Additionally, one or more output devices 624 are also connected to the interface circuit 620 of the illustrated example. The output devices 624 may be, for example, display devices (e.g., light-emitting diodes (LEDs), organic light-emitting diodes (OLEDs), liquid crystal displays (LCDs), cathode ray tube (CRT) displays, field-switching (IPS) displays, touchscreens, etc.), haptic output devices, printers, and / or speakers. Thus, the interface circuit 620 of the shown example typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0068] The interface circuit 620 in the example shown also includes communication devices such as transmitters, receivers, transceivers, modems, residential gateways, wireless access points, and / or network interfaces to facilitate data exchange with external machines (e.g., computing devices of any kind) via the network 626. Communication can be via, for example, Ethernet connections, digital subscriber line (DSL) connections, telephone line connections, coaxial cable systems, satellite systems, line-of-site wireless systems, cellular telephone systems, etc.

[0069] The processor platform 600 in the example shown also includes one or more mass storage devices 628 for storing software and / or data. Examples of such mass storage devices 628 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID (redundant array of independent disks), and digital versatile disk (DVD) drives.

[0070] The machine-executable instructions 632 in Figure 4 and / or Figure 5 may be stored in a mass storage device 628, in volatile memory 614, in non-volatile memory 616, and / or in a removable non-temporary computer-readable storage medium such as a CD or DVD.

[0071] Figure 7 shows a block diagram illustrating an exemplary software distribution platform 705 for distributing software, such as the exemplary computer-readable instruction 632 in Figure 6, to third parties. The exemplary software distribution platform 705 may be implemented by any computer server, data facility, cloud service, etc., that can store and transmit the software to other computing devices. The third party may be a customer entity that owns and / or operates the software distribution platform. For example, the entity that owns and / or operates the software distribution platform may be the developer, seller, and / or licensor of the software, such as the exemplary computer-readable instruction 632 in Figure 6. The third party may be a consumer, user, retailer, OEM, etc., that purchases and / or licenses the software for use and / or resale and / or sublicensing. In the example shown, the software distribution platform 705 includes one or more servers and one or more storage devices. The storage devices store computer-readable instructions 632, which may correspond to the exemplary computer-readable instructions 400 and / or 500 in Figures 4 and / or 5, as described above. One or more servers of the exemplary software distribution platform 705 communicate with network 710, which may correspond to any one or more of the Internet described above and / or one or more of the exemplary network 626. In some examples, one or more servers respond to requests to send software to requesters as part of a commercial transaction. Payment for delivery, sale, and / or licensing of the software may be handled by one or more servers of the software distribution platform and / or through a third-party payment entity. The servers enable purchasers and / or licensors to download computer-readable instructions 632 from the software distribution platform 705.For example, software that may correspond to the exemplary computer-readable instruction 632 in Figure 6 may be downloaded to an exemplary processor platform 600, which executes the computer-readable instruction 632 to implement the container layer manager 205. In some examples, one or more servers of the software distribution platform 705 periodically provide, transmit, and / or enforce updates to the software (e.g., the exemplary computer-readable instruction 632 in Figure 6) to ensure that improvements, patches, updates, etc., are distributed and applied to the software on end-user devices.

[0072] Figure 8 shows exemplary performance improvements resulting from using the exemplary approach disclosed herein. Figure 8 shows a histogram 800 for running 168 concurrent functions (e.g., containers). The exemplary histogram 800 includes a vertical axis 810 representing frequency, a horizontal axis 820 representing time buckets, and two datasets 830 and 840. The first dataset 830 represents functions (e.g., containers) that run more frequently and therefore result in a higher priority level. The second dataset 840 represents functions (e.g., containers) that run less frequently (e.g., less frequently than the functions represented by the first dataset) and therefore result in a lower priority level. Generally, functions with higher priority levels exhibited faster execution.

[0073] From the above, it will be understood that exemplary methods, apparatus, and articles are disclosed that enable the efficient loading of containers into working memory for execution. The exemplary approaches disclosed herein enable storing portions of a container image in separate memories having different performance characteristics, thereby enabling preferential loading of sections of the container image necessary for the immediate execution of the container. Such prioritization enables improved loading and / or execution times for such containers. The disclosed methods, apparatus, and articles improve the efficiency of using computing devices by enabling the loading of images into working memory for execution in a more efficient manner. Thus, the disclosed methods, apparatus, and articles aim to improve one or more functions of a computer.

[0074] While certain exemplary methods, apparatus, and articles are disclosed herein, the scope of this patent is not limited to these. Conversely, this patent covers all methods, apparatus, and articles that fall within the claims of this patent.

[0075] Exemplary methods, apparatus, systems, and manufactured articles for loading container images are disclosed herein. Further examples and combinations thereof include:

[0076] Example 1 is a device for managing a container image, which includes a priorityizer that determines the priority level at which a container will be executed, a container controller that determines a first expected position for a first layer set of a container, the container controller determines a second expected position for a second layer set of a container, the first and second expected positions are determined based on the determined priority levels, and the second layer set is separated from the first layer set in the image by landmarks, a container loader that mounts the first layer set from the first expected position, and a container executor that starts executing the container based on the mounted first layer set.

[0077] Example 2 includes the apparatus described in Example 1, further comprising a container compressor that constructs an image of a container using a compression format that includes landmarks.

[0078] Example 3 includes the apparatus described in Example 1, wherein the container controller pulls a first layer set from the container registry to a first expected location, and the container controller pulls a second layer set from the container registry to a second expected location.

[0079] Example 4 includes the device described in Example 1, in which the container executor triggers the execution of a container based on a first layer set before the container loader mounts a second layer set.

[0080] Example 5 includes the apparatus described in Example 1, in which the first expected location identifies the first storage device.

[0081] Example 6 includes the device described in Example 5, wherein the first storage device is implemented using dynamic random access memory.

[0082] Example 7 includes the apparatus described in Example 5, wherein the second expected location identifies a second storage device different from the first storage device.

[0083] Example 8 includes the device described in Example 7, where the second storage device is implemented by persistent memory.

[0084] Example 9 is a non-temporary computer-readable medium containing an instruction, the instruction including, when executed, causes at least one processor to determine at least: determine the priority level at which a container will be executed; determine a first expected position for a first set of layers of a container; determine a second expected position for a second set of layers of a container, where the first and second expected positions are determined based on the determined priority levels, and the second set of layers is separated from the first set of layers in the image by landmarks; mount the first set of layers from the first expected position; and start execution of the container based on the first set of layers.

[0085] Example 10 includes at least one non-temporary computer-readable medium as described in Example 9, in which the instruction causes at least one processor to construct an image of a container using a compressed format that includes landmarks when the instruction is executed.

[0086] Example 11 includes at least one non-temporary computer-readable medium as in Example 9, wherein the instruction causes at least one processor to pull a first layer set from the container registry to a first expected location in response to a first determination that a first layer set does not exist at a first expected location, and to pull a second layer set from the container registry to a second expected location in response to a second determination that a second layer set does not exist at a second expected location.

[0087] Example 12 includes at least one non-temporary computer-readable medium as in Example 9, wherein the instruction causes at least one processor to mount a second layer set from a second expected location after the execution of the container has begun based on a first layer set, when the instruction is executed.

[0088] Example 13 includes at least one non-transient computer-readable medium as described in Example 9, in which the first expected location identifies the first storage device.

[0089] Example 14 includes at least one non-temporary computer-readable medium as described in Example 13, where the first storage device is implemented using dynamic random access memory.

[0090] Example 15 includes at least one non-transient computer-readable medium as described in Example 13, wherein the second expected location identifies a second storage device different from the first storage device.

[0091] Example 16 includes at least one non-temporary computer-readable medium as described in Example 15, wherein the second storage device is persistent memory.

[0092] Example 17 is a method for managing a container image, comprising: determining the priority level at which the container will run; determining a first expected position for a first set of layers of the container; determining a second expected position for a second set of layers of the container by executing instructions using a processor, wherein the first and second expected positions are determined based on the determined priority level; mounting the first set of layers from the first expected position; and starting the execution of the container based on the first set of layers.

[0093] Example 18 includes the method of Example 17, further comprising building a container image using a compression format that includes landmarks.

[0094] Example 19 further includes the method of Example 17, which includes pulling a first layer set from the container registry to a first expected location in response to a first determination that a first layer set does not exist at a first expected location, and pulling a second layer set from the container registry to a second expected location in response to a second determination that a second layer set does not exist at a second expected location.

[0095] Example 20 includes the method of Example 17, further comprising mounting a second layer set from a second expected location after the container execution has started based on a first layer set.

[0096] Example 21 is a device for managing a container image, comprising: a prioritizing means for determining the priority level at which a container will be executed; a control means for determining a first expected position for a first layer set of a container, the control means for determining a second expected position for a second layer set of a container, the first and second expected positions being determined based on the determined priority level, and the second layer set being separated from the first layer set in the image by landmarks; a loading means for mounting the first layer set from the first expected position; and an execution means for starting the execution of the container based on the mounted first layer set.

[0097] Example 22 includes the apparatus described in Example 21, further comprising a compression means for constructing a container image using a compression format that includes landmarks.

[0098] Example 23 includes the apparatus described in Example 21, wherein the control means pulls a first layer set from the container registry to a first expected position, and the control means pulls a second layer set from the container registry to a second expected position.

[0099] Example 24 includes the apparatus described in Example 21, wherein the execution means triggers the execution of a container based on a first layer set before the load means mounts a second layer set.

[0100] Example 25 includes the apparatus described in Example 21, in which the first expected location identifies the first storage device.

[0101] Example 26 includes the device described in Example 25, in which the first storage device is implemented using dynamic random access memory.

[0102] Example 27 includes the apparatus described in Example 25, wherein the second expected location identifies a second storage device different from the first storage device.

[0103] Example 28 includes the device described in Example 27, in which the second storage device is implemented by persistent memory.

[0104] The following claims are incorporated by this reference into a mode for carrying out the present invention, and each claim is set in itself as a distinct embodiment of the present disclosure.

Claims

1. A device for managing container images, A priorityizer that determines the priority level at which a container will run, A container controller that determines a first expected position for a first layer set of the container, wherein the container controller determines a second expected position for a second layer set of the container, the first and second expected positions are determined based on the determined priority level, and the second layer set is separated from the first layer set in the image by landmarks, A container loader that mounts the first layer set from the first expected position, A device including a container executor that initiates the execution of the container based on the mounted first layer set.

2. The apparatus according to claim 1, further comprising a container compressor that constructs the container image using a compression format that includes the aforementioned landmarks.

3. The apparatus according to any one of claims 1 to 2, wherein the container controller pulls the first layer set from the container registry to the first expected position, and the container controller pulls the second layer set from the container registry to the second expected position.

4. The apparatus according to any one of claims 1 to 3, wherein the container executor triggers the execution of the container based on the first layer set before the container loader mounts the second layer set.

5. The apparatus according to any one of claims 1 to 4, wherein the first expected position identifies a first storage device.

6. The apparatus according to claim 5, wherein the first storage device is implemented using dynamic random access memory.

7. The apparatus according to claim 5, wherein the second expected location identifies a second storage device different from the first storage device.

8. The apparatus according to claim 7, wherein the second storage device is implemented by persistent memory.

9. A computer-readable medium comprising instructions for managing a container image, wherein, when the instructions are executed, at least one processor is provided with at least one instruction. Determining the priority level at which the container will run, Determining the first expected position for the first layer set of the container, Determining a second expected position for a second layer set of the container, wherein the first and second expected positions are determined based on the determined priority levels, and the second layer set is separated from the first layer set in the image by landmarks, Mounting the first layer set from the first expected position, A non-transient computer-readable medium that causes the execution of the container to start based on the first layer set.

10. The instruction causes the at least one non-temporary computer-readable medium according to claim 9 to construct the container image using a compressed format including landmarks when the instruction is executed.

11. The instruction, when executed, causes at least one processor to: In response to the first determination that the first layer set does not exist at the first expected location, the first layer set is pulled from the container registry to the first expected location. At least one non-temporary computer-readable medium according to any one of claims 9 to 10, which causes the second layer set to be pulled from the container registry to the second expected location in response to a second determination that the second layer set does not exist at the second expected location.

12. The instruction causes the at least one non-temporary computer-readable medium according to any one of claims 9 to 11 to mount the second layer set from the second expected location after the execution of the container has started based on the first layer set, when the instruction is executed.

13. The first expected location is at least one non-transient computer-readable medium according to any one of claims 9 to 12, which identifies the first storage device.

14. The first storage device is implemented using dynamic random access memory, wherein the first storage device is at least one non-temporary computer-readable medium according to claim 13.

15. The second expected location identifies a second storage device different from the first storage device, the at least one non-temporary computer-readable medium according to claim 13.

16. The second storage device is persistent memory, wherein the at least one non-temporary computer-readable medium is as described in claim 15.

17. A method for managing container images, Determining the priority level at which the container will run, Determining the first expected position for the first layer set of the container, The process involves determining a second expected position for a second layer set of the container by executing instructions using a processor, wherein the first and second expected positions are determined based on the determined priority level. Mounting the first layer set from the first expected position, A method comprising: initiating the execution of the container based on the first layer set.

18. The method according to claim 17, further comprising constructing the container image using a compression format that includes landmarks.

19. In response to the first determination that the first layer set does not exist at the first expected location, the first layer set is pulled from the container registry to the first expected location. The method according to any one of claims 17 to 18, further comprising pulling the second layer set from the container registry to the second expected location in response to a second determination that the second layer set does not exist at the second expected location.

20. The method according to any one of claims 17 to 19, further comprising mounting the second layer set from the second expected location after the execution of the container has started based on the first layer set.

21. A device for managing container images, A means of prioritizing to determine the priority level at which a container will run, A control means for determining a first expected position for a first layer set of the container, wherein the control means determines a second expected position for a second layer set of the container, the first and second expected positions are determined based on the determined priority level, and the second layer set is separated from the first layer set in the image by landmarks, A loading means for mounting the first layer set from the first expected position, An apparatus comprising: execution means for initiating the execution of the container based on the mounted first layer set.

22. The apparatus according to claim 21, further comprising compression means for constructing the container image using a compression format that includes the landmarks.

23. The apparatus according to any one of claims 21 to 22, wherein the control means pulls the first layer set from the container registry to the first expected position, and the control means pulls the second layer set from the container registry to the second expected position.

24. The apparatus according to any one of claims 21 to 23, wherein the execution means triggers the execution of the container based on the first layer set before the load means mounts the second layer set.

25. The apparatus according to any one of claims 21 to 24, wherein the first expected position identifies a first storage device.

Images