Containerized computing environment

Abstract

Methods, computer program products, and systems for a containerized computing environment are provided. An image is constructed that implements improved utilization of a previously constructed image layer. An image building system evaluates commands before they are used and differentiates between stateful and stateless commands. By adopting this approach, stateless commands can be identified (e.g., tagged) so that the image building system can handle stateless commands in a different manner than stateful commands. This enables the reuse of cached / stored image layers, thereby reducing the image size by avoiding the creation of new image layers.

Description

Background Art

[0001] The present invention generally relates to computing environments, and more particularly to methods for containerized computing environments. The present invention also relates to a computer program product including computer-readable program code that enables a processor of a processing system to implement such methods. The present invention also relates to a system for building images for a containerized computing environment.

[0002] Operating system-level virtualization has been widely used in cloud computing and platform as a service (PaaS) frameworks. Operating system-level virtualization is a server virtualization method in which the operating system kernel allows multiple isolated user space instances (referred to as containers). On the LINUX operating system, with support from the kernel namespaces and cgroup mechanisms, emerging container solutions such as Docker and LXC have attracted increasing attention and are currently being developed rapidly. (Note: The terms "LINUX", "DOCKER", and / or "LXC" may be subject to trademark rights in various jurisdictions around the world and are used herein only with reference to the products or services appropriately named by the marks, where the naming of the mark is such that such trademark rights may exist).

[0003] Compared to traditional virtual machines, containers use a smaller image size, start up faster, and consume fewer resources (e.g., memory, processing clock cycles), making containers a lightweight and fast virtualization solution.

[0004] A container is a running instance of an image. Such an image is typically constructed as a chain of layers. Each new modification is represented as a new layer that is added on top of its parent (base) layer. Creating a new image layer for a new modification (e.g., caused by a command) can result in a large image size. Summary of the Invention

[0005] In one aspect of the present invention, a method, computer program product, and system for building an image for a containerized computing environment include: (i) analyzing a command including one or more instructions for building an image to determine whether the command is a stateless command or a stateful command; and (ii) based on the result of the analysis, associating an identifier with the command, the identifier being configured to indicate whether the command is stateful or stateless.

[0006] According to one aspect of the present invention, a computer-implemented method of processing a command for building an image for a containerized computing environment is provided. The method includes analyzing a command including one or more instructions for building an image to determine whether the command is a stateless command or a stateful command. Based on the result of the analysis, an identifier is associated with the command, the identifier being configured to indicate whether the command is stateful or stateless.

[0007] According to another aspect of the present invention, there is provided a computer-implemented method for building an image for a containerized computing environment. The method includes obtaining a set of commands including one or more instructions for building an image, wherein the commands in the set of commands have associated identifiers indicating whether the command is stateful or stateless. For the command, based on the associated identifier indicating whether the command is stateful or stateless, the reuse of a previously built image layer is controlled.

[0008] According to another embodiment of the present invention, there is provided a computer program product for processing commands for building an image for a containerized computing environment, the computer program product including a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processing unit to cause the processing unit to perform a method according to one or more of the proposed embodiments when executed on at least one processor of a data processing system.

[0009] According to another embodiment of the present invention, there is provided a computer program product for building an image for a containerized computing environment, the computer program product including a computer-readable storage medium having program instructions implemented therewith, the program instructions being capable of being executed by a processing unit to cause the processing unit to perform a method according to one or more of the proposed embodiments when executed on at least one processor of a data processing system.

[0010] According to yet another aspect of the present invention, there is provided a processing system including at least one processor and a computer program product according to one or more embodiments, wherein the at least one processor is adapted to execute the computer program code of the computer program product.

[0011] According to another aspect of the present invention, there is provided a system for processing commands for building an image for a containerized computing environment. The system includes an analysis component configured to analyze a command including one or more instructions for building an image to determine whether the command is a stateless command or a stateful command. The system further includes an editor component configured to associate an identifier with the command based on the result of the analysis, the identifier being configured to indicate whether the command is stateful or stateless.

[0012] According to yet another aspect of the present invention, there is provided an image building system for building an image for a containerized computing environment. The image building system includes an interface component configured to obtain a set of commands including one or more instructions for building an image, wherein the commands in the set of commands have associated identifiers indicating whether the command is stateful or stateless. The image building system further includes a controller configured to control the reuse of a previously built image layer for the command based on the associated identifier indicating whether the command is stateful or stateless. Description of the Drawings

[0013] Embodiments of the present invention will now be described by way of example only with reference to the following drawings, in which:

[0014] Figure 1 shows a container hosting environment in which one or more embodiments of the present invention are implemented;

[0015] Figure 2 is a table showing a build process implemented according to an exemplary traditional Docker file;

[0016] Figure 3 is a table showing a build process implemented according to an exemplary (modified) Docker file according to the proposed embodiment;

[0017] Figure 4 depicts a flowchart of a method according to the proposed embodiment;

[0018] Figure 5 depicts a simplified block diagram of a system according to the proposed embodiment;

[0019] Figure 6 shows a cloud system node;

[0020] Figure 7 shows a cloud computing environment according to an embodiment; and

[0021] Figure 8 shows a cloud abstraction pattern layer according to an embodiment. DETAILED DESCRIPTION

[0022] Build an image that can improve the utilization of previously built image layers. An image building system evaluates commands before they are used and distinguishes between stateful and stateless commands. Adopting this approach enables the identification (e.g., tagging) of stateless commands, so that the image building system can handle stateless commands in a different way from stateful commands. This enables the reuse of cached / stored image layers, thereby reducing the image size by avoiding the creation of new image layers.

[0023] The present invention seeks to provide a concept for building images that enables improved utilization of previously built image layers (e.g., available via an image cache memory), thereby potentially avoiding the creation of new image layers that would otherwise increase the image size, for example.

[0024] Embodiments can be used in conjunction with traditional / existing image building systems such as Docker building systems. In this way, embodiments can be integrated into traditional systems in order to improve and / or extend their functionality and capabilities. Thus, the proposed embodiments can provide an improved (e.g., reduced size and / or more efficient) containerized computing environment. The system can be adapted to preprocess container image build commands in order to provide enhanced / enhanced commands that enable an improved image caching utility to be implemented on a group of images.

[0025] The proposed system can be incorporated into existing / traditional image building systems. Thus, an image building system can be proposed that evaluates commands before their use and differentiates between stateful and stateless commands. Adopting this approach can enable stateless commands to be identified (e.g., tagged), so that the image building system can handle stateless commands in a different manner than stateful commands. This can, for example, enable cached / stored image layers to be reused, thereby reducing the image size by avoiding the creation of new image layers.

[0026] It should be understood that the drawings are merely schematic and not drawn to scale. It should also be understood that the same reference numerals are used throughout the drawings to represent the same or similar components.

[0027] In the context of the present application, where embodiments of the invention constitute a method, it should be understood that such a method is a process for execution by a computer, i.e., a computer-implementable method. Thus, the various steps of the method reflect the various parts of a computer program, e.g., the various parts of one or more algorithms.

[0028] Furthermore, in the context of the present application, a (processing) system can be a single device or a collection of distributed devices adapted to execute one or more embodiments of the method of the invention. For example, the system can be a personal computer (PC), a server, or a collection of PCs and / or servers connected via a network such as a local area network, the Internet, etc., in order to collaboratively execute at least one embodiment of the method of the invention.

[0029] Exemplary cloud infrastructures, data repositories, data centers, data processing systems, computing systems, data storage systems, and associated servers, computers, storage units and devices, and other processing devices may be referenced to describe illustrative embodiments. However, it should be understood that embodiments of the present invention are not limited to use with the specific illustrative system and device configurations shown. Additionally, as used herein, phrases such as "cloud environment," "cloud computing platform," "cloud infrastructure," "data repository," "data center," "data processing system," "computing system," "data storage system," "database," etc. are intended to be broadly construed so as to encompass, for example, private and / or public cloud computing or storage systems, as well as other types of systems including distributed virtual infrastructures. However, a given embodiment may more generally include any arrangement of one or more processing devices.

[0030] As mentioned above in the Background section, containers have become a preferred virtualization alternative to traditional virtual machines for hosting applications (apps) in cloud computing environments. However, existing container file system implementations still face various challenges, including the management of container image sizes.

[0031] To address the above and other challenges, illustrative embodiments of the present invention provide concepts for improving the (containerized) image building process. Such concepts can enable improved utilization of previously built image layers (e.g., available via an image cache memory), thereby potentially avoiding the creation of new image layers and, in turn, avoiding an increase in image size. Specifically, the concepts proposed are to enhance image build commands with identifiers (e.g., tags, indicators, annotations, etc.) so as to enable improved utilization of previously built image layers (e.g., from a stored image swarm). For example, an identifier can be associated with a stateless command, enabling an image build engine to clearly distinguish between stateful and stateless commands.

[0032] Unlike conventional image build systems that do not have any command identifiers, the embodiments proposed supplement commands with identifiers (e.g., "hints"), which can allow for more fine-grained control over stateful or stateless commands.

[0033] A "stateful command" is a command that depends on (i.e., utilizes) a previous or current execution state. A stateful command thus depends on the system state. As such, a stateful command tracks the previous (prior) execution state. In contrast, a "stateless command" is a command that is independent of the former's current execution state. A stateless command is thus self-contained, i.e., everything contained within the command, and is disposed of in two different phases, namely, "command" and "response." Thus, a stateless command does not track the former (prior) execution state.

[0034] References to "images" shall be considered to refer to entities that can be considered to be like files that are static files of which the container is a running instance. Images are typically constructed as a chain of layers. Since a container is a running instance of a container, an image can alternatively be referred to as a "container image" to indicate that the image facilitates the creation of a container.

[0035] Before describing concepts according to illustrative embodiments, an overview of a container system that can be used to implement the illustrative embodiments will be given.

[0036] For portability and reusability, containers utilize a union mount mechanism to construct and combine different layers for file sharing, rather than using an entire disk image file as in traditional virtual machines. Specifically, after container initialization, the container union mounts a base layer (read-only) and a top layer (read-write) together to build a root file system. During the life cycle of a container, all modifications to the root file system are written incrementally on the top layer. A commit operation causes the container to save the current top layer and start writing on a new layer on top of the saved top layer, thus creating a new top layer.

[0037] As Figure 1 shown, a container cluster 100 (such as Docker Swarm, Magnum, and Kubernetes) includes hosts 102 and a cluster controller 104. In a cloud computing platform, a cluster of host devices (hosts) that use containers to host applications, such as Figure 1 shown, is referred to as a "container hosting environment". Hosts 102 create and run containers 106 and are connected to each other via a high-speed network (represented by the interconnecting arrows in Figure 1 ). As described above, in the illustrative embodiments, hosts 102 create one or more containers 106 to execute one or more containerized stateful applications (i.e., applications that execute in a container and track the execution state of the former (previous) container) respectively. The cluster controller 104 is responsible for managing the container hosts 102. For example, the cluster controller 104 monitors the container state and starts high availability (HA) processes, and executes user commands, such as commands that cause container migration between hosts and start backup and recovery operations.

[0038] A running (executing) container starts from its container image. Before starting a container, the host needs to obtain the corresponding container image from a container registry. In a Docker container implementation, an image is constructed as a chain of layers. Each new modification is represented as a new layer and is added on top of its parent (base) layer.

[0039] Now, illustrative embodiments of the present invention that can provide improved cache utilization will be described.

[0040] Some embodiments of the present invention are directed to an image building engine configured to distinguish between stateful commands and stateless commands, thereby providing improved container layer cache reusability. In particular, it is proposed to associate an identifier (e.g., a hint, symbol, or special character) with a command to indicate whether the command is stateful or stateless. For example, the identifier can be placed before the command or with the command.

[0041] Some embodiments of the present invention relate to the concept of processing commands for building an image (or "container image") for a containerized computing environment. This can allow commands to be identified as stateful commands or stateless commands. In this way, the image building engine can clearly distinguish between stateless and stateful commands and improve the reusability of the container layer cache. In particular, it is proposed to use an identifier that will allow the image building system to determine whether a command is stateless or stateful. Based on such a determination, the building system can decide to reuse a previously built image layer.

[0042] Some embodiments of the present invention utilize tags, hints, or identifiers to enhance image building commands, which enable better image cache utilization overall in the image. Such tags or identifiers can also be used for debugging purposes.

[0043] Some embodiments of the present invention are directed to the concept of preprocessing image construction commands, which enables stateless commands to be clearly distinguished from stateful commands. As an example, some embodiments of the present invention can be considered to provide a hint attribute accompanying the command. Such a hint can be provided near, before, within, or beside the command.

[0044] An exemplary embodiment can provide a method of processing commands for building an image for a containerized computing environment. In such an exemplary method, a command including one or more instructions for building an image is analyzed to determine whether the command is a stateless command or a stateful command. Based on the result of the analysis, an identifier is associated with the command, where the identifier is configured to indicate whether the command is stateful or stateless.

[0045] For example, associating an identifier with a command can include appending a command prefix or command attribute to the command to indicate that the command is stateless. The command prefix or command attribute can, for example, include a symbol or an annotation string. In this way, a simple, human-readable, and / or computer-readable identifier can be used to identify (e.g., label, highlight, or otherwise mark) a stateless command such that the image building engine can potentially dispose of the stateless command in a manner that can result in, for example, increased efficiency and / or reduced image size. Moreover, using a simple symbol or string can help reduce the complexity and / or cost of implementation.

[0046] The analysis command may include: determining whether the command exists in a previous image layer; in response to determining that the command exists in the previous layer, determining whether an instance of the command in the previous layer can be reused; and in response to determining that the instance of the command in the previous layer can be reused, determining that the command is stateful. In this way, embodiments can run a simple check to determine whether a command is stateless, thereby helping to reduce the processing or resource requirements of the proposed embodiments.

[0047] Some embodiments of the present invention may provide a method for building an image for a containerized computing environment. In such an exemplary method, a command set including one or more instructions for building an image is obtained, wherein the commands in the command set have associated identifiers indicating whether the command is stateful or stateless. For commands having an associated identifier, the reuse of previously built image layers is controlled based on the associated identifier indicating whether the command is stateful or stateless.

[0048] In some embodiments of the present invention, controlling the reuse of previously built image layers may include: in response to the identifier associated with the command indicating that the command is stateful, reusing the previously built image layer; and in response to the identifier associated with the command indicating that the command is stateless, preventing the use of the previously built image layer. Thus, embodiments can enable an image building system to decide whether to reuse a cached layer or command. This can improve the reusability of the container layer cache, which can result in a smaller image size, better cache utilization, and / or improved performance.

[0049] In some embodiments of the present invention, controlling the reuse of previously built image layers may include: in response to the identifier associated with the command indicating that the command is stateless, ignoring the command. Thus, embodiments can provide an image building system that is flexible in handling stateless commands.

[0050] Some embodiments of the present invention allow an image building engine to clearly distinguish between stateful and stateless commands, and thus improve the reusability of the container layer cache. Some embodiments of the present invention are particularly advantageous in addressing the ongoing need for efficient cache utilization in an image building system.

[0051] By further describing some embodiments of the present invention, an image building system will now be considered. The image building system follows a command set (i.e., instructions) defined in a configuration file. When the image building system encounters the next command, it runs a check to determine whether the command exists in any previous image layer, and in the case where the layer cannot be reused, it may additionally check an associated stateless command identifier (where the identifier indicates that the command can be ignored and does not affect the layer structure).

[0052] The stateless command identifier can be provided as part of a comment or can be any kind of additional command attribute. For example, the identifier of a stateless command can include a comment such as: "#+hint stateless…(hint stateless)#", before the command definition.

[0053] According to another example, the identifier of a stateless command can include the "*" (asterisk) character added as a prefix to the command definition (i.e., provided immediately before the command definition), resulting in a command definition of the following form: "* <command> <arguments>”.

[0054] According to another example, the identifier of a stateless command can include the "!" (exclamation mark) character, which is added as a prefix to the command definition (i.e., provided immediately before the command definition), resulting in a command definition of the following form: "! <command> <arguments>”。

[0055] However, it should be understood that there are many other possible ways to associate identifiers with commands.

[0056] Subsequently, during the image creation process, the image creation system can decide to consider or ignore the stateless command identifiers associated with the commands.

[0057] The container layer can be marked as having certain properties (stateless, stateful, etc.). The container layer constructed in this way can be reused when constructing other images derived from these layers or based on the same configuration.

[0058] In addition, a command can be extended into multiple sub-commands (e.g., the ` / bin / sh -c` interpreter command), where each sub-command can have an associated identifier. In this case, the deeper the sub-command is in the chain, the higher its priority over the top-level command.

[0059] The identified stateless command (i.e., the stateless command having an associated identifier indicating that the command is stateless) can end, resulting in a "transient layer".

[0060] By further demonstrating some embodiments of the present invention, an example of a traditional Docker build system will be described (refer to Figure 2 ), and subsequently an example of such a system modified according to the proposed embodiments will be described (refer to Figure 3 ).

[0061] An example of a conventional Docker build system, and more specifically, an exemplary command set of a conventional Docker file can be as follows:

[0062] FROM busybox

[0063] ARG UNIQUE_ARG=world

[0064] RUN echo Hello${UNIQUE_ARG}

[0065] COPY. / files

[0066] Refer to Figure 2 , which shows a table of the build process for the first and second arguments in the command line "RUN echo Hello${UNIQUE_ARG}" implemented according to the above-mentioned traditional Docker file. For the second argument, the cache for the first argument from the build process is available.

[0067] Figure 2 Figure 250 shows a flowchart depicting a first method according to an embodiment of the present invention. Figure 3 Program 300 is shown that performs at least some of the method steps of flowchart 250. Now, during the course of the following paragraphs, reference will be made extensively to Figure 2 (for method step boxes) and Figure 3 (for software boxes) to discuss the method and the associated software.

[0068] From Figure 2 the second row (second box) of the second (right - hand) column of

[0069] it can be seen that the traditional build process does not have cache reuse. Instead, now an example of a Docker build system according to the proposed embodiment will be considered. More specifically, an exemplary command set for a (modified) Docker file according to the proposed embodiment can be as follows:

[0070] FROM busybox

[0071] ARG UNIQUE_ARG=world

[0072] #+hint stateless

[0073] RUN echo Hello${UNIQUE_ARG}

[0074] COPY. / files

[0075] In the above (modified) Docker file according to the proposed embodiment, before the command on the third line ("RUN echo Hello${UNIQUE_ARG}”) there is a "hint" of statelessness. That is, an identifier is associated with the third command, where the identifier is provided as a comment (or "hint") in the line immediately preceding the line containing the third command. The comment indicates that the next line (command) is stateless.

[0076] Referring to Figure 3 , a table of the build process for the first and second arguments in the command line "RUN echo Hello${UNIQUE_ARG}" implemented according to the above (modified) Docker file is shown. For the second argument, the cache for the first argument from the build process is available.

[0077] From Figure 3 the second row (second box) of the second (right - hand) column of

[0078] Accordingly, from the above description, it will be understood that an image building system with tagged instructions according to the proposed embodiments can achieve improved container image cache utilization. This can be achieved by identifying commands that do not affect the final container image content and then avoiding creating new container image layers for such commands (which would otherwise increase the container image size). Some embodiments of the present invention can be considered to distinguish between stateful and stateless commands to improve cache reusability, and this distinction between stateful and stateless commands can be achieved by associating an identifier with a command to indicate whether it is stateless.

[0079] Now referring to Figure 4 , a flowchart of a method according to an embodiment of the present invention is described. The method includes two (sub) methods: the first (sub) method 400 includes a method for processing commands for building an image according to an embodiment of the present invention; and the second (sub) method 450 includes a method for building a container image (using the processed commands). That is, Figure 4 the method described in

[0080] The first (sub) method 400 is for processing a set of commands for building an image for a containerized computing environment. Each command includes one or more instructions for building a container image.

[0081] In step 410, each command is analyzed to determine whether it is a stateless command or a stateful command. By way of example, the process of analyzing a command includes: determining whether the command exists in a previous image layer; in response to determining that the command exists in the previous layer, determining whether an instance of the command in the previous layer can be reused; and in response to determining that the instance of the command in the previous layer can be reused, determining that the command is stateful.

[0082] In step 420, based on the analysis result from step 410, a corresponding identifier is associated with each command that has been determined to be stateless. In this example, the identifier includes a character / symbol (such as "*" of "!") and the identifier is associated with the stateless command by inserting the character / symbol before the command (on the same code / command line). In this way, the stateless command is identified by a corresponding identifier prefix that indicates that the command following the identifier prefix is a stateless command.

[0083] It will be understood that as a result of completing the first (sub) method 400 to process the set of commands, a new set of (pre) processed commands is provided by the first (sub) method. The new set of (pre) processed commands includes one or more stateless commands, each command having an associated identifier indicating the stateless nature of the command.

[0084] Provide a new set of (pre-)processing commands to a second (sub-)method 450 for building a container image using the (pre-)processing commands (from a first sub-)method 400.

[0085] In step 460, obtain the set of (pre-)processing commands, for example, via a communication interface. As described above, one or more commands in the set have associated identifiers indicating that the associated commands are stateless.

[0086] In step 470, for each command, control the reuse (via a cache memory) of a previously built image layer based on whether the command has an associated identifier indicating that the command is stateless. In particular, in response to the identifier associated with the command indicating that the command is stateless, prevent the use of a previously built image layer in response to the command.

[0087] Now refer to Figure 5 , a simplified block diagram of a system 500 according to the proposed embodiment is described. The method includes two (sub-)systems: a first (sub-)system 505 includes a system for processing commands for building an image for a containerized computing environment according to the proposed embodiment; and a second (sub-)system 550 includes an image building system for building a container image (using the processed commands) according to an embodiment of the present invention. That is, Figure 5 the system 500 depicted in

[0088] combines the proposed system 500 for (pre-)processing commands to identify stateless commands and the proposed image building system 550 for building an image according to the (pre-)processed commands.

[0089] The first (sub-)system 505 is configured to process a set of commands for building an image for a containerized computing environment. Each command includes one or more instructions for building a container image. The first (sub-)system 505 includes an analysis component 510 and an editor component 520.

[0090] Based on the analysis results of the analysis component 510, the editor component associates corresponding identifiers with each command that has been determined to be stateless. In this example, the identifiers include comment / hint strings, and the identifiers are associated with the stateless commands by inserting the comment / hint strings in the line immediately preceding the command (the code / command line directly above the command). In this way, the stateless commands are identified by the corresponding identifier comments / hints, and the corresponding identifier comments / hints indicate that the command immediately following the comment / hint is a stateless command.

[0091] It will be understood that as a result of processing the set of commands, the first (sub) system 505 provides a new (pre) - processed set of commands. The set of (pre) - processed commands includes one or more stateless commands, each command having an associated identifier indicating the stateless nature of the command.

[0092] The new set of (pre) - processed commands is provided to the second (sub) system 550 for use in building a container image using the (pre) - processed commands (from the first sub) system 505. The second (sub) system 550 includes an interface component 560 and a controller 570.

[0093] The interface component 560 obtains the set of (pre) - processed commands via, for example, a wired or wireless communication link. As described above, one or more commands in the set have associated identifiers indicating that the associated commands are stateless.

[0094] For each command, the controller controls the (via the cache memory) reuse of previously built image layers based on whether the command has an associated identifier indicating that the command is stateless. In particular, in response to the identifier associated with the command indicating that the command is stateless, the controller prevents the use of previously built image layers in response to the command.

[0095] Thus, from the above description, it will be understood that the proposed method and system provide a distinction between stateless commands and stateful commands. Based on this distinction, the image building system / method can handle stateless commands differently from stateful commands, thereby improving the utilization of the cache memory.

[0096] Some embodiments of the present invention relate to a computer-implemented method for building an image for a containerized computing environment, comprising the steps of: (i) obtaining a set of commands comprising one or more instructions for building an image, wherein the commands in the set of commands have associated identifiers indicating whether the commands are stateful or stateless; and (ii) for a command, controlling the reuse of a previously established image layer by (a) reusing the previously established image layer in response to the identifier associated with the command indicating that the command is stateful, based on whether the identifier associated with the command indicates that the command is stateful or stateless; or (b) preventing the use of a previously built image layer in response to the identifier associated with the command indicating that the command is stateless.

[0097] Some embodiments of the present invention ignore commands identified as stateless.

[0098] The above embodiments include only a limited set of examples of identifiers for indicating whether a command is stateful or stateless. However, it should be understood that the concepts presented can be modified or adapted to employ other ways of identifying stateless (commands).

[0099] It will be apparent from the above description that all or part of the system according to the proposed embodiments is provided by a cloud computing system. Additionally, a system for processing commands for building an image can be provided or implemented in a hybrid cloud computing system.

[0100] Referring to the following description of cloud computing systems, it can be pre-understood that although the present disclosure includes a detailed description of cloud computing, the implementation of the teachings herein is not limited to a cloud computing environment. Instead, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed. The following description of cloud computing systems and environments is made only for purposes of explanation and understanding.

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

[0102] Features are as follows: On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities such as server time and network storage as needed, without the need for human interaction with the service provider. Wide area network access: The capabilities are available over the network and are accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs). Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reallocated according to demand. There is a location-independent meaning in that consumers generally do not control or know the exact location of the provided resources, but can specify the location at a higher level of abstraction (e.g., country, state, or data center). Rapid elasticity: In some cases, the ability to rapidly scale out and rapidly scale in can be provided quickly and elastically. To the consumer, the available capabilities for provisioning generally appear unlimited and can be purchased in any quantity at any time. Measured service: The cloud system automatically controls and optimizes resource use by leveraging metering capabilities at an appropriate level of abstraction for the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, thus providing transparency for both the provider and the consumer of the utilized service.

[0103] The service models are as follows:

[0104] Software as a Service (SaaS): The capabilities provided to the consumer are to use the provider's applications running on the cloud infrastructure. The applications can be accessed from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings. Platform as a Service (PaaS): The capabilities provided to the consumer are to deploy the applications created or acquired by the consumer onto the cloud infrastructure, where the applications created or acquired by the consumer are created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but has control over the deployed applications and possibly the configuration of the application hosting environment. Infrastructure as a Service (IaaS): The capabilities provided to the consumer are to provide processing, storage, networking, and other basic computing resources where the consumer can deploy and run arbitrary software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system; storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewall).

[0105] The deployment models are as follows:

[0106] Private Cloud: The cloud infrastructure is for the exclusive use of an organization. It can be managed by the organization or a third party and can be located either on or off the premises. Community Cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can be located either on or off the premises. Public Cloud: The cloud infrastructure is available to the general public or a large industrial group and is owned by an organization that sells cloud services. Hybrid Cloud: The cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds). The cloud computing environment is service-oriented, with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure of networks that includes interconnected nodes.

[0107] Now referring to Figure 6 , a schematic diagram showing an example of a cloud computing node is illustrated. Cloud computing node 10 is merely one example of a suitable cloud computing node and is not intended to impose any limitation on the scope of use or functionality of the embodiments of the invention described herein. In any case, cloud computing node 10 is capable of implementing and / or performing any of the functions set forth above.

[0108] In cloud computing node 10, there is a computer system / server 12, which can operate with many other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with computer system / server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

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

[0110] As Figure 6 As shown, the computer system / server 12 in the cloud computing node 10 is shown in the form of a general computing device. The components of the computer system / server 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including the system memory 28 to the processor 16.

[0111] The bus 18 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, these architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0112] The computer system / server 12 generally includes a variety of computer system readable media. Such media can be any available media accessible to the computer system / server 12, and it includes volatile and non-volatile media, removable and non-removable media.

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

[0114] A program / utilities 40 having a set (at least one) of program modules 42, as well as an operating system, one or more application programs, other program modules, and program data, may be stored in the memory 28 by way of example and not limitation. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networked environment. The program modules 42 generally execute the functions and / or methods of the embodiments of the present invention described herein.

[0115] The computer system / server 12 may also communicate with one or more external devices 14, such as a keyboard, pointing device, display 24, etc.; one or more devices that enable a user to interact with the computer system / server 12; and / or any device that enables the computer system / server 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication may occur via an input / output (I / O) interface 22. However, the computer system / server 12 may communicate with one or more networks via a network adapter 20, such networks as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet). As shown, the network adapter 20 communicates with other components of the computer system / server 12 via a bus 18. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with the computer system / server 12. Examples include but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0116] Now refer to Figure 7 , an illustrative cloud computing environment or cloud computing system 50 is depicted. In an embodiment, this may be equivalent to, for example, Figure 1 the cloud computing system depicted therein. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers may communicate, such local computing devices as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automotive computer system 54N. The nodes 10 may communicate with each other. They may be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud or a combination thereof as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service, and cloud consumers do not need to maintain resources on local computing devices for it. It should be understood that Figure 7 the types of computing devices 54A-N shown are only for illustration, and the computing nodes 10 and the cloud computing environment 50 may communicate with any type of computerized device via any type of network and / or network addressable connection (e.g., using a web browser).

[0117] Now refer to Figure 8 , which shows a set of functional abstraction layers provided by a cloud computing environment 50( Figure 7 ). It should be understood in advance that Figure 8 the components, layers, and functions shown in

[0118] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes, in one example a system; servers based on RISC (Reduced Instruction Set Computer) architecture, in one example a system; IBM systems; IBM systems; storage devices; networks and network components. Examples of software components include network application server software, in one example application server software; and database software, in one instance IBM DB2 database software. (IBM, zSeries, pSeries, xSeries, BladeCerter, WebSphere, and DB2 are trademarks of International Business Machines Corporation registered in many jurisdictions worldwide).

[0119] The virtualization layer 62 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers; virtual storage; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients.

[0120] In one example, the management layer 64 can provide the functions described below. Resource provisioning provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing provide cost tracking when resources are utilized in the cloud computing environment, as well as billing or invoicing for the consumption of these resources. In one example, these resources can include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. The user portal provides access to the cloud computing environment for consumers and system administrators. Service level management provides cloud computing resource allocation and management such that the required service levels are met. Image building provides container image building according to the concepts proposed as detailed above.

[0121] The workload layer 66 provides examples of functions that can utilize the cloud computing environment. Examples of workloads and functions that can be provided from this layer include: mapping and navigation; software development and lifecycle management; virtual classroom education delivery; data analysis processing; transaction processing; and mobile desktop.

[0122] The present invention may be a system, method, and / or computer program product. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the present invention.

[0123] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a storage class memory (SCM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[0124] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or may be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing / processing device.

[0125] The computer-readable program instructions for performing the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state-setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages (such as Smalltalk, C++, etc.) and conventional procedural programming languages (such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network connection, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, in order to perform aspects of the present invention, an electronic circuit, including for example a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit.

[0126] Aspects of the present invention are described herein with reference to the flowchart and / or block diagram of a method, apparatus (system), and computer program product according to embodiments of the present invention. It will be understood that each block of the flowchart and / or block diagram, and combinations of blocks in the flowchart and / or block diagram, can be implemented by computer-readable program instructions. These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus create a means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium, which may direct a computer, a programmable data processing apparatus, and / or other devices to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing the specified (multiple) logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.< / arguments> < / arguments>

Claims

1. A computer-implemented method for processing a command for building an image for a containerized computing environment, the method comprises: analyzing a command comprising one or more instructions for building an image to determine whether the command is a stateless command or a stateful command, wherein a stateless command indicates a former command independent of the current execution state, and wherein a stateful command indicates a command depending on a previous or current execution state; and associating an identifier with the command based on the result of the analysis, the identifier being configured to indicate whether the command is stateful or stateless.

2. The method according to claim 1, wherein associating an identifier with the command comprises attaching a command prefix or a command attribute to the command to indicate that the command is stateless.

3. The method according to claim 2, wherein the identifier comprises a symbol or an annotation string.

4. The method according to claim 1, wherein analyzing the command comprises: determining whether the command exists in a previous image layer; responsive to determining that the command exists in the previous layer, determining whether an instance of the command in the previous layer can be reused; and responsive to determining that the instance of the command in the previous layer can be reused, determining that the command is stateful.

5. The method according to claim 4, wherein determining whether the command exists in the previous image layer comprises: searching for the command in the image layer data stored in a cache memory.

6. The method according to claim 1, wherein the command is a container image building command of a Docker build system.

7. A computer program product for processing a command for building an image for a containerized computing environment, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions being executable by a processing unit to cause the processing unit to perform the operations of the method according to any one of claims 1 to 6.

8. A computer system for processing a command for building an image for a containerized computing environment, the computer system comprises: a set of processors; and a computer-readable storage medium storing program instructions; wherein: the program instructions, when executed by the set of processors, cause the set of processors to perform the operations of the method according to any one of claims 1 to 6.

9. A computer system for processing a command for building an image for a containerized computing environment, the computer system comprising means for performing the method according to any one of claims 1 to 6.

Images