DEPLOYMENT OF CONTAINER IMAGES WITH SEPARATE ADD-ONS

A container image is deployed, at runtime, on a node within a computing environment. The deploying includes downloading, at runtime, container image content from multiple sites. The downloading includes obtaining a core image of the container image from one or more image registries and updating a local image store with the core image, and obtaining one or more add-ons of the container image from one or more add-on registries and updating a local add-on store with the one or more add-ons. The deployed container image is executed on the node.

BACKGROUND

One or more aspects relate, in general, to facilitating processing within a computing environment, and in particular, to the deployment of container images.

A container image is a software package that includes the software to be used to run an application, including, for example, code, application and system libraries and runtime default settings. The size of container images continues to grow larger, and some are several gigabytes in size. A change, including a slight change, in configuration requires a different image, and at times, there are requirements to dynamically change the components in the image.

Due to the increasing size of images, consumption of storage and network resources of container systems has increased, as well as the cost of an image registry. Further, deployment processes used to deploy container images and the development of container-related processes have slowed down.

SUMMARY

Shortcomings of the prior art are overcome, and additional advantages are provided through the provision of a computer-implemented method of facilitating processing within a computing environment. The computer-implemented method includes deploying, at runtime, a container image on a node within the computing environment. The deploying includes downloading, at runtime, container image content from multiple sites. The downloading includes obtaining a core image of the container image from one or more image registries and updating a local image store with the core image, and obtaining one or more add-ons of the container image from one or more add-on registries and updating a local add-on store with the one or more add-ons. The container image is executed on the node.

Computer systems and computer program products relating to one or more aspects are also described and claimed herein. Further, services relating to one or more aspects are also described and may be claimed herein.

DETAILED DESCRIPTION

In accordance with one or more aspects, a capability is provided to facilitate processing within a computing environment. In one or more aspects, the capability includes improving deployment of container images within the computing environment. For example, the capability includes providing a deployment process that reduces image size and costs at runtime. In one or more aspects, the size of a container image is reduced and stabilized, and dynamically changing application components are provided as extensions or add-ons to the image.

In one or more aspects, a container image is separated into multiple parts including, for instance, a core image and one or more add-ons. The core image is, for instance, the data packaging that follows an image format specification loaded from one or more image registries. One example of an image format specification is an Open Container Initiative® (OCI) image format specification, which is an open governance structure for creating open industry standards around container formats and runtimes. Open Container Initiative is a registered trademark of The Linux Foundation, San Francisco, CA. Other image format specifications may be used. The image add-ons are, e.g., components dynamically loaded from one or more add-on registries, which are, e.g., separate registries from the image registries. In one example, the add-ons support multiple media types, such as gzip, Zstandard (zstd), tar, etc. Other media types are possible.

In one or more aspects, container image content is downloaded from multiple sites at runtime in order to avoid placing redundant data in the image. In one or more aspects, add-ons are developed for one or more images of one or more types. In one or more aspects, the dynamic content applied to the image is well scanned, and protected by, for example, a setting of read-only. Different users are used for installation and runtime, in one example.

One or more aspects of the present invention are incorporated in, performed and/or used by a computing environment. As examples, the computing environment may be of various architectures and of various types, including, but not limited to: personal computing, client-server, distributed, virtual, emulated, partitioned, non-partitioned, cloud-based, quantum, grid, time-sharing, cluster, peer-to-peer, wearable, mobile, having one node or multiple nodes, having one processor or multiple processors, and/or any other type of environment and/or configuration, etc. that is capable of executing a process (or multiple processes) to, e.g., deploy container images and/or perform one or more other aspects of the present invention. Aspects of the present invention are not limited to a particular architecture or environment.

One example of a computing environment to perform, incorporate and/or use one or more aspects of the present invention is described with reference toFIG.1. In one example, a computing environment100contains an example of an environment for the execution of at least some of the computer code involved in performing the inventive methods, such as container image deployment code or module150. In addition to block150, computing environment100includes, for example, computer101, wide area network (WAN)102, end user device (EUD)103, remote server104, public cloud105, and private cloud106. In this embodiment, computer101includes processor set110(including processing circuitry120and cache121), communication fabric111, volatile memory112, persistent storage113(including operating system122and block150, as identified above), peripheral device set114(including user interface (UI) device set123, storage124, and Internet of Things (IoT) sensor set125), and network module115. Remote server104includes remote database130. Public cloud105includes gateway140, cloud orchestration module141, host physical machine set142, virtual machine set143, and container set144.

The computing environment described above is only one example of a computing environment to incorporate, perform and/or use one or more aspects of the present invention. Other examples are possible. For instance, in one or more embodiments, one or more of the components/modules ofFIG.1are not included in the computing environment and/or are not used for one or more aspects of the present invention. Further, in one or more embodiments, additional and/or other components/modules may be used. Other variations are possible.

As indicated, in one example, computing environment100supports containers. The containers may be provided in a cloud, such as a public cloud (e.g., public cloud105), a private cloud (e.g., private cloud106), a hybrid cloud and/or on-premises (e.g., computer101). In one example, containers are managed by one or more of various management platforms. One example of such a platform is Kubernetes®, which is an open-source, extensible, portable container management platform. Kubernetes is a registered trademark of The Linux Foundation, San Francisco, CA. Other platforms may also be used. In Kubernetes, for example, a container has its own central processing unit share, filesystem, process space, memory and more. Further, containers may share the operating system (OS) among applications due to their relaxed isolation properties; containers are decoupled from the underlying infrastructure; containers are portable across operating system distributions and clouds; and each container is repeatable. Containers are intended to be stateless and immutable-code of a running container is not to be changed; instead, a new container image is built to include the change. Further details regarding containers are described with reference toFIG.2.

In one example, referring toFIG.2, a computing environment200includes one or more nodes210, an operating system280shared by the one or more nodes, and underlying hardware290, such as processing units, etc. used by the one or more nodes. The nodes may be virtual or physical machines, and they may be on-premise (e.g., in computer101and/or other computing devices) and/or in a cloud environment (e.g., public cloud105, private cloud106, a hybrid cloud environment and/or other cloud environment). In one example, computing environment200employs a platform, such as Kubernetes and/or another platform, to manage the containers. Kubernetes is a platform for running and managing containers from a plurality of container runtimes, including, but not limited to, DockerR, containerdR, Container Runtime Interface-Open Container Initiative (CRI-O), etc. Although examples of platforms and runtimes are provided, additional, fewer and/or other platforms and/or runtimes may be used. Docker is a registered trademark of Docker, Inc., San Francisco, CA; and containerd is a registered trademark of The Linux Foundation, San Francisco, CA.

In one example, a node210includes a container runtime220, such as, for instance, Docker, containerd, Container Runtime Interface-Open Container Initiative (CRI-O), etc.; one or more pods230; a proxy250; and an agent260. One example of proxy250is a kube-proxy, which is a network proxy that runs on each node in a cluster, implementing part of the Kubernetes Service concept. A kube-proxy maintains network rules on the nodes, and these network rules allow network communication to the pods from network sessions inside or outside of the cluster. One example of agent260is a kubelet that runs on each node. It can register the node, using one or more of a hostname, flag or other, with an application programming interface (api) server that validates and configures data for objects (e.g., pods). In other examples in which the platform is other than Kubernetes, the proxy and agent may be for that platform. Many examples are possible.

In one example, a container runtime interface270is provided, which is a plugin interface that enables agent260(e.g., the kubelet) to use a wide variety of container runtimes (e.g., container runtime220) without having to recompile the cluster components.

In one example, a pod230includes one or more containers240, and a container240includes, for instance, a container image242having one or more applications246with one or more libraries244, and/or one or more binary and/or text resources. A container image is deployed on the node (e.g., node210), as described herein.

In accordance with one or more aspects, deployment of a container image (e.g., container image242) is facilitated, reducing and stabilizing the size of the image. In one or more aspects, a container image deployment module (e.g., container image deployment module150) is used to deploy container images, at runtime. A container image deployment module (e.g., container image deployment module150) includes code or instructions used to perform container image deployment, in accordance with one or more aspects of the present invention. A container image deployment module (e.g., container image deployment module150) includes, in one example, various sub-modules to be used to perform the processing. The sub-modules are, e.g., computer readable program code (e.g., instructions) in computer readable media, e.g., storage (storage124, persistent storage113, cache121, other storage, as examples). The computer readable media may be part of a computer program product and the computer readable program code may be executed by and/or using one or more computing devices (e.g., one or more computers, such as computer(s)101; one or more servers, such as remote server(s)104; one or more processors or nodes, such as processor(s) or node(s) of processor set110; processing circuitry, such as processing circuitry120of processor set110; and/or other computing devices, etc.). Additional and/or other computers, servers, processors, nodes, processing circuitry and/or other computing devices may be used to execute one or more of the sub-modules and/or portions thereof. Many examples are possible.

One example of container image deployment module150is described with reference toFIG.3. In one example, container image deployment module150includes a resolve arguments/options sub-module300to resolve arguments/options of a container image being deployed; an obtain core image sub-module310to obtain (e.g., pull, download, retrieve, be provided, etc.) a core image of a container image from a registry, such as an image registry; an add-on processing sub-module320to check if there are one or more add-ons and to obtain (e.g., pull, download, retrieve, be provided, etc.) one or more add-ons, if they exist, for the container image; and an update sub-module330to update one or more local stores with the obtained core image and the one or more add-ons. Additional, fewer and/or other sub-modules may be provided and/or used in one or more aspects of the present invention.

The sub-modules are used, in accordance with one or more aspects of the present invention, to deploy container images, as further described with reference toFIG.4. In one example, a container image deployment process (e.g., a container image deployment process400) is implemented using one or more of the sub-modules (e.g., sub-modules300-330) and is executed by one or more computing devices (e.g., one or more computers (e.g., computer(s)101, other computer(s), etc.), one or more servers (e.g., server(s)104, other server(s), etc.), one or more processor(s), node(s) and/or processing circuitry, etc. (e.g., of processor set110or other processor sets), and/or other computing devices, etc.). Although example computers, servers, processors, nodes, processing circuitry and/or computing devices are provided, additional, fewer and/or other computers, servers, processors, nodes, processing circuitry and/or computing devices may be used for the container image deployment process and/or other processing. Various options are possible.

Referring toFIG.4, in one example, container image deployment process400(also referred to herein as process400) is performed by an agent (e.g., agent260—e.g., a kubelet) executing on a node (e.g., node210) in which the container image is to be deployed. Other variations are possible.

In one example, process400resolves410arguments and/or options including, for instance, security access parameters for the container image. As an example, the configurations of an image to be deployed include, e.g., the command line arguments, environment variables, ports, volume mounting points, image pull policy, restart policy, and/or resource limits, etc., as well as some security access parameters (e.g., example image pull secrets and various security context, for example, if using privileged user, if allowing privileged escalation, is the root file system read-only, etc.).

Further, in one example, process400obtains (e.g., pulls, downloads, retrieves, is provided, etc.)420a core image from a registry. For instance, in accordance with one or more aspects of the present invention, a container image is divided into, for example, a core image and one or more add-ons, assuming there are add-ons. As shown inFIG.5, a container image500includes a core image510, which is pulled from one or more image registries520. The core image is, for instance, the image based on the current container image specification. The dynamic and optional contents are removed, in accordance with an aspect of the present invention, and provided as add-ons, which may be selected, as described herein.

Returning toFIG.4, process400updates430a local image store. For instance, it updates432the local image store by adding the core image (e.g., a new digest and/or tag for the core image) to the local image store.

Further, in one example, process400determines440whether there is at least one add-on for the container image. For instance, a user specifies, if desired, add-on addresses with arguments in their pod manifest (e.g., Kubernetes pod manifest) and an additional parameter in the image spec message indicates if there are add-ons.

Should there be no add-ons, add-on processing is complete450. However, should there be at least one add-on, then process400obtains (e.g., pulls, downloads, retrieves, is provided, etc.)460an add-on from a corresponding registry. For instance, as shown inFIG.5, an add-on, such as App-a530aand/or App-b530b, is pulled from one or more add-on registries540. In one example, the one or more add-on registries540are separate from the one or more image registries520.

Returning toFIG.4, process400updates430a local add-on store. For instance, process400updates434the local add-on store by adding the add-on (e.g., a new digest and/or tag for the add-on) to the local add-on store. The add-on processing, including for instance, checking whether an add-on exists and obtaining the add-on, should one exist, and the updating the local add-on store, are performed for each add-on to be deployed for the container image.

Further details regarding one example of an add-on registry, such as add-on registry540, are described with reference toFIG.6. In one example, an add-on registry, such as add-on registry540, includes, for instance, an add-on representational state transfer (REST) application programming interface (API)610for one or more add-ons; access control620for the one or more add-ons; enter handlers630, such as, e.g., push, pull, etc. for the one or more add-ons; a manifest640including, for example, media-type, size, digest, platform (e.g., architecture, operating system, etc.) and/or custom labels and/or tags used for users to filter a selected or best add-on with an add-on address and one or more arguments for the one or more add-ons; and storage650of the one or more add-ons. A registry may include additional, fewer and/or other information/components.

Thus, in accordance with one or more aspects of the present invention, as depicted inFIG.7, in one example, deployment of a container image includes deploying a core image700(e.g., on a node) and separately deploying one or more add-ons702(e.g., on a node). The core image (e.g., core image700) and the add-ons are distributed separately and then composed at runtime, as depicted inFIG.7. The container image is composed dynamically, which is more efficient than traditional processes (which focus on optimizing container image size statically by building separate images for different usages), especially when there is a common base foundation with one or many (e.g., a large variety of) add-ons per selection at runtime.

In one example, the container image is executed at runtime. It uses a container runtime (e.g., container runtime220), which is, e.g., software responsible for running the containers, and it logically runs in a pod (e.g., pod230). The pod includes a specification that specifies how to run the containers. Thus, in accordance with an aspect of the present invention, a pod specification is revised to include an optional add-on field, which is in addition to the image field. For instance, one example of a pod specification includes:

As shown above, in accordance with one or more aspects of the present invention, an add-on field has been added. In this example, the add-on field specifies add-on app-a (e.g., add-on530a) and add-on app-b (e.g., add-on530b). Additional, fewer and/or other add-ons may be specified.

In one or more aspects, an add-ons field is also added to the container runtime interface (e.g., container runtime interface270). The container runtime interface defines the protocol (e.g., gRPCR® (gRemote Procedure Call; gRPC is a registered trademark of The Linux Foundation, San Francisco, CA.) or other protocol) for communication between, e.g., the agent (e.g., agent260; e.g., kubelet in a Kubernetes architecture) and the container runtime (e.g., container runtime220). In one aspect, the container runtime interface image message type has been enriched to include an add-ons field, which supports the multi-architecture feature provided by, e.g., an annotations field of the message type. One example of a definition of a container runtime interface image message type is depicted below:

In one or more aspects, enhanced security is provided for an add-on lifecycle, which includes, for instance, distribution, install and run. As examples: Distribution: an add-on may be scanned and certified when distributed via an add-on registry; Install: the root filesystem may be set to read-only after being loaded; Run: an add-on may be run in a sandbox with restricted security context. The user to install and run the add-ons are different, in one example.

In one or more aspects, the image specification is not changed; instead, the container runtime interface specification is changed in order to reduce the image size. The final image data size may be reduced since the configuration is at deployment time. The capability provided herein is generic in that it may be used for many platforms and/or application types, including those that use binary resources and/or dynamic resources.

In one or more aspects, an image size of a container is reduced and stabilized by placing dynamically changing application components as add-ons to the image. Container image contents for a particular user are removed, and provided as one or more add-ons, reducing the size of the core image in the image registry, as well as the size of the container image. This facilitates maintenance of the image registry and provides flexibility in image composition. Add-ons, which may be pre-built, are placed in a central location, such as one or more add-on registries, and are loaded therefrom and placed on top of a core image. That is, a pluggable system is provided that enables add-ons to be dynamically included (e.g., when selected) with a core image and/or removed, at runtime. This reduces the size of the static core image and provides flexibility.

In one or more aspects:

The container image is separated into multiple parts, including a core image (e.g., the data package following, e.g., a selected image format specification loaded from image registries) and image add-ons (components dynamically loaded from add-on registries). The container runtime interface specification, as an example, is enhanced by changing, e.g., the container runtime interface image message type;

The add-on supports multiple media types, including, but not limited to, gzip, zstd, tar, etc.); and

The pod specification is enhanced to include an optional add-on field, in addition to the image field.

Although various aspects and/or embodiments are described herein, other aspects, variations and/or embodiments are possible.

Although various embodiments are described above, these are only examples. For example, different types of platforms, protocols, interfaces, add-ons, etc. may use and/or benefit from one or more aspects of the present invention. Many variations are possible.

Various aspects and embodiments are described herein. Further, many variations are possible without departing from a spirit of aspects of the present invention. It should be noted that, unless otherwise inconsistent, each aspect or feature described and/or claimed herein, and variants thereof, may be combinable with any other aspect or feature.