Search

EP-4010797-B1 - DYNAMIC IMAGE COMPOSITION FOR CONTAINER DEPLOYMENT

EP4010797B1EP 4010797 B1EP4010797 B1EP 4010797B1EP-4010797-B1

Inventors

  • DE MARCO, Jonathan
  • SCHULTZ, BENJAMIN M.
  • SMITH, Frederick Justus, IV
  • PULAPAKA, HARI R.
  • IYIGUN, MEHMET
  • GUO, Amber Tianqi

Dates

Publication Date
20260506
Application Date
20200610

Claims (10)

  1. A method performed in a computing device (102) having a processor, a storage device (104) containing multiple files (107), and a memory containing instructions executable by the processor to provide a computing platform for hosting one or more containers (114) on the computing device (102), the method comprising: executing a container process on the computing device (102), the container process being an instance of a container image on the computing device, the container image comprising digital data representing a file system having files therein, wherein each file is identified by a file identifier and wherein reparse points are eliminated and only the file identifier and a corresponding location are included in the container image; receiving, from the container process, a request to access the file (107), the file identified by the file identifier corresponding to the requested file (107); and in response to receiving the request to access the file (107), querying a mapping table corresponding to the container process to locate an entry corresponding to the file identifier of the requested file (107), the entry also having data identifying the file location on the storage device (104) from which the requested file (107) is accessible; retrieving, from the file location, a copy or pointer of the file (107) according to the file location identified by the data in the located entry in the mapping table; and allowing the container process to access the file by providing the copy or pointer of the file (107) to the container process, thereby allowing the container process to access the file (107).
  2. The method of claim 1, wherein: the file location includes a file path to a file (107) included with a host operating system of the computing device (102); retrieving the copy of the file (107) includes retrieving a copy of the file (107) included with a host operating system of the computing device (102) from the storage device (104); and providing the copy includes providing the copy or pointer of the file (107) included with a host operating system of the computing device (102) to the container process.
  3. The method of claim 1 wherein: the file location includes a file path to a file (107) that is unique to the container process; retrieving the copy of the file (107) includes retrieving a copy of the file(107) that is unique to the container process; and providing the copy includes providing, to the container process, the copy of the file (107) that is unique to the container process.
  4. The method of claim 1 wherein: the file (107) is a first version of the file (107);the file location is a first file location; and the method further includes modifying the data in the entry of the mapping table to indicate a second file location corresponding to a second version of the file (107) different than the first version of the file (107).
  5. The method of claim 1 wherein: the file (107) is a first version of the file (107);the file location is a first file location; and the method further includes: receiving an indication that a second version of the file (107) is now available,the second version is an update to the first version of the file (107); and in response to receiving the indication, modifying the data in the entry of the mapping table to indicate a second file location corresponding toa second version of the file (107).
  6. The method of claim 1 wherein: the file (107) is a first version of the file (107); the file location is a first file location; and the method further includes: modifying the data in the entry of the mapping table to indicate a second file location corresponding to a second version of the file (107) different than the first version of the file (107); and upon receiving another request for the same file (107), retrieving, from the second file location, a copy of the second versionof the file; and providing the copy of the second version of the file (107) to the container process, thereby allowing the container processto access the second version of the file (107) without shutting down the container.
  7. The method of claim 1 wherein: the file (107) is a first version of the file (107); and the method further includes: receiving an indication that a second version of the file (107) is now available,the second version is an update to the first version of the file (107); and in response to receiving the indication, determining whether a copy of the first version of the file (107) is currently being accessed; and in response to determining that the copy of the first version of the file (107) is not currently being accessed, overwriting the first version of the file (107) in the file location with the second version of the file (107).
  8. The method of claim 1 wherein: the file (107) is a first version of the file (107); and the method further includes: receiving an indication that a second version of the file (107) is now available,the second version is an update to the first version of the file (107); and in response to receiving the indication, determining whether a copy of the second version ofthe file is currently available at the computing device; and in response to determining whether a copy of the second version of the file (107) is not currently available at the computing device (102), downloading, from a remote source, a copy of thesecond version of the file (107) to the storage device (104).
  9. The method of claim 1 wherein: the file (107) is a first version of the file (107);the file location is a first file location; and the method further includes, upon receiving an indication that a second version of the file (107) is now available, the second version is an update to the first version of the file (107), determining whether a copy of the second version of the file (107) is currently available at the computing device (102); and in response to determining whether a copy of the second version of the file (107) is not currently available at the computing device (102), downloading, from a remote source, a copy of the second version of the file (107) to the storage device (104); determining whether a copy of the first version of the file (107) is currently being accessed; and in response to determining that the copy of the first version of the file (107) is currently being accessed, modifying the data in the entry of the mapping table to indicate a second file location corresponding to the downloaded copy of the second versionofthe file (107), the second file location being different than the first file location.
  10. A computing device (102), comprising: a processor; a storage device (104) containing multiple files (107); and a memory operatively coupled to the processor, the memory having instructions executable by the processor to cause the computing device (102) to perform a process according to one of claims 1-9.

Description

Technical Field The present disclosure relates to the technical field of computer systems and software deployment, and more particularly to methods, systems, and computer-implemented techniques for dynamic image composition in container deployment environments. BACKGROUND Sandboxing is a software management strategy devised to isolate operating systems and/or applications from underlying computing resources and other programs on a host device. For example, datacenters providing cloud computing services can include a large number of servers individually hosting one or more virtual machines, containers, or other types of virtualized components. The virtualized components can separately execute applications for tenants without having direct access to the underlying computing resources of the severs or to one another. Sandboxing can thus provide a layer of security that prevents malware or harmful applications from negatively affecting a host device or other virtualized components on the same host device. US2018129666A1 describes how the state of a file may be a combination of local state, typically small (e.g., a placeholder file), and some external source state such as that maintained in a read-only namespace managed by a cloud provider or by another local file system, typically large. A file system component responsible for overlaying (i.e., merging) the partial local state and the external source state into a single file system view that can be used by an application of a container as if the full state exists locally. Overlays that comprise the file system state may be referred to as "layers". A tombstone mechanism may be provided to record delete or rename modifications in the top layer. SUMMARY The invention is set out in the appended set of claims. This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Though both virtual machines and containers can be used as virtualization techniques to accommodate compute, communications, or other types of computing services, virtual machines and containers have different characteristics. For instance, virtual machines can incur a significantly more overhead in resources than containers. A virtual machine typically has an entire operating system, a full set of files and directory structures, a unique configuration, virtual memory allocation, and applications, all of which can amount to tens of gigabytes in size. In contrast, containers (e.g., Docker-based containers) are software packages that provide facilities a software application or service needs to run, such as code, runtime, tools, system libraries, etc. Containers can share resources of a host device, such as an operating system kernel, device drivers, data files, configuration parameters, etc. Thus, containers typically have a much lower memory and image footprints than virtual machines (e.g. megabytes instead of gigabytes in size). Software packages of containers, or container images, can include digital data representing a complete filesystem (e.g., organized as a file folder with subordinate file folders) that contains operating system kernels, device drivers, event logs, temporary files/directories, applications, and/or other suitable components. Container images typically have sizes of about a few hundred megabytes. In datacenters or other computing environments with abundant computing/network resources, deploying such container images generally would not cause undue delays. However, in other computing environments with scarce computing/network resources (e.g., smartphones, Internet of Things (IoT) devices, etc.), deploying a container image of a few hundred megabytes may cause unacceptable delays. For instance, transmitting a few hundred megabytes of data via a slow data network (e.g., a satellite data network, Zigbee network, etc.) can take up significant amounts of time. One technique to reduce data sizes of container images includes dynamically generating a container image during deployment time based on a recipe file. The recipe file can identify layers of software components, such as, a "base layer" having kernel modules, device drivers, applications, etc. that are available from a host operating system at the host device, one or more "modification layers" to a container to supplement and/or modify one or more files in the base layer, and a "scratch layer" having files for capturing modifications unique to the container. For example, the base layer can include a set of clean, unmodified copies of operating system files and a set of reparse points that are placeholders that redirect to a host/package file. Examples of such clean files can include a registry and other files usually modified during installation processes. The var