Computer-implemented method, computer program, and computer system (containerized computing environment)

Abstract

To provide a method for containerized computing environments, a computer program product including a computer readable code enabling a processor of a processing system implementing the method, and a system for building images for containerized computing environments.SOLUTION: An image build system builds images that enable improved utilization of previously built image layers, and evaluates commands prior to their use and differentiates between stateful and stateless commands.EFFECT: Stateless commands can be identified (e.g. labeled), thus enabling the image build system to handle the stateless commands differently from stateful commands. Cached / stored image layers can be reused, thus reducing image size by avoiding the creation of new image layers.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The field generally relates to computer environments, and more particularly to methods for containerized computing environments. The present invention further relates to a computer program product including computer readable program code for enabling a processor of a processing system to implement such methods. The present invention further relates to a system for building images for a containerized computing environment. [Background technology]

[0002] Operating system-level virtualization has become 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 enables multiple isolated user-space instances, called containers. On the LINUX® operating system, emerging container solutions such as Docker and LXC, along with support for kernel namespaces and cgroups, are gaining increasing attention and are currently undergoing rapid development. (Please note: The terms "LINUX," "DOCKER," and / or "LXC," or combinations thereof, are subject to trademark rights in various jurisdictions worldwide and are used herein to refer to products or services appropriately designated by the trademarks to the extent such trademark rights exist.)

[0003] Compared to traditional virtual machines, containers are a lightweight and fast virtualization solution because they use smaller image sizes, start up faster, and consume fewer resources, e.g., memory and process clock cycles.

[0004] A container is a running instance of an image. Such images are typically structured as a chain of layers, with each new modification represented as a new layer added on top of the parent (base) layer. Summary of the Invention [Problem to be solved by the invention]

[0005] Generating a new image layer for a new modification (eg, triggered by a command) can result in a large image size. [Means for solving the problem]

[0006] In one aspect of the invention, methods, computer program products, and systems 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) associating an identifier with the command based on a result of the analyzing, the identifier configured to indicate whether the command is stateful or stateless.

[0007] According to an aspect of the present invention, a computer-implemented method for processing a command for building an image for a containerized computing environment is provided. The method includes analyzing the 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 a result of the analyzing, an identifier is associated with the command, the identifier configured to indicate whether the command is stateful or stateless.

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

[0009] 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, comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by the processing unit when executed on at least one processor of a data processing system to cause the processing unit to perform a method according to one or more of the proposed embodiments.

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

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

[0012] According to yet 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 analyzer component configured to analyze the command including one or more instructions for building an image to determine whether the command is a stateful command or a stateless command. The system also includes an editor component configured to associate an identifier with the command based on a result of the analyzing, the identifier being configured to indicate whether the command is stateful or stateless.

[0013] 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 including an interface component configured to obtain a set of commands including one or more instructions for building an image, wherein a command in the set of commands has an associated identifier indicating whether the command is stateful or stateless. The image building system also includes a controller configured to control, for the command, reusing a previously built image layer based on the associated identifier indicating whether the command is stateful or stateless. [Brief explanation of the drawings]

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

[0015] [Figure 1] 1 illustrates a container host environment according to which one or more embodiments of the invention may be implemented.

[0016] [Figure 2] 1 is a table illustrating a build procedure implemented according to an exemplary conventional Docker file.

[0017] [Figure 3] 1 is a table illustrating a build procedure implemented according to an exemplary (modified) Docker file according to the proposed embodiment.

[0018] [Figure 4] FIG. 1 is a flow diagram of a method according to a proposed embodiment.

[0019] [Figure 5] FIG. 1 is a simplified block diagram of a system according to a proposed embodiment.

[0020] [Figure 6] FIG. 2 illustrates a cloud system node.

[0021] [Figure 7] FIG. 1 illustrates a cloud computing environment according to one embodiment.

[0022] [Figure 8] FIG. 1 illustrates a cloud abstraction mode layer according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0023] A method for building images is provided that allows for improved utilization of previously built image layers. The image building system evaluates commands before use and distinguishes between stateful and stateless commands. Using such a method, stateless commands can be identified (e.g., labeled) so that the image building system can process them differently from stateful commands. This process allows for reuse of cached / stored image layers, thereby reducing image size by avoiding the generation of new image layers.

[0024] The present invention aims to provide a concept for constructing images that allows for improved utilization of previously constructed image layers (e.g., available via an image cache memory), potentially avoiding, for example, the creation of new image layers that would otherwise increase image size.

[0025] The embodiments may be used in combination with traditional / existing image build systems, such as the Docker build system. In this manner, the embodiments may be integrated into legacy systems to improve and / or extend the functionality and capabilities of the legacy systems. Thus, an improved (e.g., reduced size and / or more efficient) containerized computing environment may be provided by the proposed embodiments. The system may be adapted to pre-process container image build commands to provide enhanced / improved commands that enable improved image cache utilization across a population of images.

[0026] The proposed system may be embodied in existing / traditional image building systems. To this end, an image building system may be proposed that evaluates commands before use and distinguishes between stateful and stateless commands. Using such an approach, stateless commands can be identified (e.g., labeled) and the image building system can process them differently from stateful commands. This processing can, for example, allow for the reuse of cached / stored image layers, thereby reducing image size by avoiding the generation of new image layers.

[0027] It should be understood that the drawings are only schematic and are not drawn to scale, and it should be understood that the same reference symbols are used throughout the drawings to indicate the same or similar parts.

[0028] In the context of this application, where embodiments of the present invention constitute methods, it should be understood that such methods are other processes carried out by a computer, i.e., computer-implementable methods, and thus the steps of the method reflect different portions of a computer program, e.g., different portions of one or more algorithms.

[0029] Also, in the context of this application, a (processing) system may be a single device or a collection of distributed devices adapted to perform one or more embodiments of the method of the present invention. For example, a system may be a personal computer (PC), a server, a collection of PCs or servers, or a combination thereof, connected via a network, such as a local area network and the Internet, which may cooperate to perform at least one embodiment of the method of the present invention.

[0030] Exemplary embodiments may be described herein with reference to 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. However, it should be understood that embodiments of the invention are not limited to use with the particular exemplary system and device configurations shown. Furthermore, terms used herein, such as “cloud environment,” “cloud computing platform,” “cloud infrastructure,” “data repository,” “data center,” “data processing system,” “computing system,” “data storage system,” “data lake,” and the like, are intended to be broadly interpreted and encompass other types of systems, including, for example, private cloud computing, public cloud computing, or a combination thereof, as well as distributed virtual infrastructures. However, a given embodiment may more generally include an arrangement of one or more processing devices.

[0031] As mentioned in the Background section above, containers have become a more popular virtualization option than traditional virtual machines for hosting application programs (applications) in cloud computing environments. However, existing container file system implementations still face various challenges, including managing container image size.

[0032] To address the above and other challenges, exemplary embodiments of the invention provide a concept for improving the process of building images (for containers). Such a concept enables improved utilization of previously built image layers (e.g., available via an image cache memory), potentially avoiding the generation of new image layers and thus avoiding an increase in image size. In particular, the proposed concept is to augment image building commands with identifiers (e.g., labels, indications, comments, etc.) to enable improved utilization of previous image layers (e.g., from a stored collection of images). For example, an identifier may be associated with stateless commands, thereby enabling the image building engine to clearly distinguish between stateful and stateless commands.

[0033] Unlike traditional build systems (which do not have any identifiers for commands), the proposed embodiments complement commands with identifiers (e.g., "hints") that can allow for more fine-grained control of stateful or stateless commands.

[0034] A "stateful command" refers to a command that depends on (i.e., utilizes) a previous or current execution state. As such, a stateful command depends on the system state. In this way, a stateful command keeps a record of the previous (previous) execution state. Conversely, a "stateless command" refers to a command that does not depend on the previous or current execution state. As such, a stateless command is a self-contained language form, i.e., everything is contained within the command and is handled by two distinct phrases, "command" and "response." As such, a stateless command does not keep a record of the previous (previous) execution state.

[0035] The reference to an image should be made to a file-like entity that may be thought of as a static file, of which a container is a running instance. Images are typically structured as a chain of layers. Because a container is a running instance of a container, an image is otherwise called a container image, indicating that the image makes it easy to create a container.

[0036] Before describing concepts according to exemplary embodiments, an overview of a container system that can be implemented in exemplary embodiments will be provided.

[0037] To achieve portability and reusability, containers utilize a union mount mechanism to build and combine different layers for file sharing, instead of using entire disk images as traditional virtual machines do. Specifically, after container initialization, the container union mounts both the base layer (read-only) and the top layer (read-write) to build the root file system. During the container's lifecycle, all modifications to the root file system are incrementally written to the top layer. A commit operation causes the container to save the current top layer and start writing a new layer on top of the saved top layer, thus creating a new top layer.

[0038] As shown in FIG. 1 , a container cluster 100 (e.g., Docker Swarm, Magnum, and Kubernetes) includes a host 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 those shown in FIG. 1 , is called a “container host environment.” The hosts 102 create and run containers 106 and are connected to each other via a high-speed network (represented by interconnecting arrows in FIG. 1 ). As mentioned above, in an exemplary embodiment, the hosts 102 create one or more containers 106 and run one or more containerized stateful applications (i.e., applications that run in containers and maintain records of previous container execution states), respectively. The cluster controller 104 is responsible for managing the container hosts 102. For example, the cluster controller 104 monitors the status of containers, launches high availability (HA) processes, and executes user commands, such as commands to migrate containers between hosts and to initiate backup and recovery operations.

[0039] An executing container is launched from the container image of the running container. Before a container is launched, the host needs to retrieve the corresponding container image from a container registry. In the Docker container implementation, images are structured as a chain of layers. Each new modification is represented as a new layer that is added on top of the new layer's parent (base) layer.

[0040] Exemplary embodiments of the present invention that can provide improved cache utilization will now be described.

[0041] Some embodiments of the present invention relate to an image build engine that is configured to distinguish between stateful and stateless commands, thereby providing improved container layer cache reusability. In particular, we propose to indicate whether a command is stateful or stateless by associating an identifier (e.g., a hint, symbol, or special character) with the command. For example, the identifier may be placed before or inline with the command.

[0042] Some embodiments of the present invention relate to a concept of processing commands for building images (or "container images") for containerized computing environments. This concept allows commands to be identified as either stateful or stateless. In this way, an image building engine may clearly distinguish between stateless and stateful commands and improve container layer cache reusability. In particular, we propose using an identifier that allows an image building system to determine whether a command is stateless or stateful. Based on such a determination, the building system may decide to reuse previously built image layers.

[0043] Some embodiments of the present invention augment image build commands with labels, hints, or identifiers that enable better image cache utilization across a population of images. Such labels or identifiers may also be used for debugging purposes.

[0044] Some embodiments of the present invention relate to the concept of pre-processing image building commands, which allows stateless commands to be clearly distinguished from stateful commands. By way of example, some embodiments of the present invention may be thought of as providing hint attributes to accompany commands. Such hints may be provided adjacent to, preceding, within, or along with the command.

[0045]

[0006] Exemplary embodiments may provide a method for processing a command 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 results of the analysis, an identifier is associated with the command, the identifier configured to indicate whether the command is stateful or stateless.

[0046] For example, associating an identifier with a command may include appending a command prefix or a command attribute to the command to indicate that the command is stateless. The command prefix or command attribute may include, for example, a symbol or a command string. In this manner, a simple, human-readable or computer-readable identifier, or both, may be used to identify (e.g., label, highlight, or otherwise mark) the stateless command, so that the image building engine may be able to process the stateless command in a manner that may result in, for example, improved efficiency or reduced image size, or a combination thereof. Additionally, using a simple symbol or string may help reduce complexity or implementation cost, or a combination thereof.

[0047] Analyzing the command may include determining whether the command exists in a previous image layer, determining whether an instance of the command in the previous layer can be reused in response to determining that the command exists in the previous layer, and determining that the command is stateful in response to determining that the instance of the command in the previous layer can be reused. In this manner, embodiments may help reduce the processing or resource requirements of proposed embodiments by performing a simple check to determine whether a command is stateless.

[0048] 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 set of commands including one or more instructions for building an image is obtained, and commands in the set of commands have associated identifiers indicating whether the commands are stateful or stateless. For commands having associated identifiers, reusing previously built image layers is controlled based on the associated identifiers indicating whether the commands are stateful or stateless.

[0049] In some embodiments of the present invention, controlling the reuse of previously built image layers may include reusing previously built image layers in response to an identifier associated with a command indicating the command is stateful, and preventing the use of previously built image layers in response to an identifier associated with a command indicating the command is stateless. Accordingly, embodiments may enable an image building system to determine whether to reuse cached layers or commands. This may improve container layer cache reusability, which may result in smaller image sizes, better cache utilization, or improved performance, or a combination thereof.

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

[0051] Some embodiments of the present invention allow for improved container layer cache reusability because the image build engine clearly distinguishes between stateful and stateless commands. Some embodiments of the present invention are particularly useful for addressing the continuing need for efficient cache utilization in image build systems.

[0052] As a further explanation of some embodiments of the present invention, consider now an image building system. The image building system follows a set of commands (i.e., instructions) defined in a configuration file. When a next command is encountered in the image building system, the image building system performs a check to determine whether the command exists in any of the previous image layers; if the layer cannot be reused, the image building system may additionally check for an associated stateless command identifier (which indicates that the command may be ignored and has no effect on the layer structure).

[0053] The stateless command identifier may be provided as part of a comment or may be any kind of additional command attribute. For example, the identifier for a stateless command may include a comment such as "#+ hint stateless...#" preceding the command definition.

[0054] By way of another example, the identifier for a stateless command includes an "*" (asterisk) character added as a prefix (i.e., provided immediately preceding) to the command definition, thus "* <command> <arguments>" may result in a command definition of the form

[0055] By way of further example, the identifier for a stateless command may include the character "!" (exclamation point) added as a prefix (i.e., provided immediately preceding) to the command definition, thus resulting in "! <command> <arguments>" may result in a command definition of the form

[0056] However, it will be appreciated that there are many other possible ways of associating an identifier with a command.

[0057] Then, during the image building procedure, the image building system may decide to either respect or ignore the stateless command identifier associated with the command.

[0058] Container layers may be labeled as having particular attributes (stateless, stateful, etc.) Container layers constructed in this manner may be reused in the construction of other images derived from these layers or based on the same configuration.

[0059] Furthermore, a command may be expanded into multiple subcommands (e.g., a " / bin / sh -c" interpreter command), and each subcommand may have an associated identifier. In such cases, the deeper a subcommand is in the chain, the higher the priority it has relative to the parent command.

[0060] Identified stateless commands (ie, stateless commands that have an associated identifier that indicates the command is stateless) may result in the creation of a "temporal layer."

[0061] To further illustrate some embodiments of the present invention, an example of a conventional Docker build system will be described (with reference to FIG. 2), followed by an example of such a system modified in accordance with proposed embodiments (with reference to FIG. 3).

[0062] An example of a conventional Docker build system, and more specifically, an exemplary set of commands in a conventional Docker file, may be as follows: FFROM busybox ARG UNIQUE_ARG=world RUN echo Hello ${UNIQUE_ARG} COPY . / files

[0063] Referring to Figure 2, a table showing the build steps implemented according to the conventional Dockerfile described above for the first and second arguments in the command line of "RUN echo Hello ${UNIQUE_ARG}" is shown. For the second argument, the cache from the build step for the first argument is available.

[0064] Figure 2 shows a flowchart 250 illustrating a first method according to an embodiment of the present invention. Figure 3 shows a program 300 for performing at least some of the method steps of flowchart 250. This method, and associated software, will now be described over the following paragraphs with detailed reference to Figure 2 (for method step blocks) and Figure 3 (for software blocks).

[0065] As can be seen in the second row (second box) of the second (right) column of Figure 2, there is no cache reuse with the conventional construction procedure.

[0066] Conversely, an example of a Docker build system according to the proposed embodiments will now be considered. More specifically, an example set of commands for a (modified) Docker file according to the proposed embodiments may be as follows: FROM busybox ARG UNIQUE_ARG=world #+ hint stateless RUN echo Hello ${UNIQUE_ARG} COPY . / files

[0067] In the (modified) Dockerfile described above in accordance with the proposed embodiment, the command on the third line ("RUN echo Hello ${UNIQUE_ARG}") is preceded by a "hint" that the command on the third line is stateless. That is, an identifier is associated with the third command, and the identifier is provided as a comment (or "hint") on the line immediately preceding the line containing the third command. The comment indicates that the following line (command) is stateless.

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

[0069] As can be seen in the second row (second box) of the second (right) column of Figure 3, the Docker build system determines the third command from the identifier. In response to this determination, the Docker build system leverages the original layer from its cache.

[0070] Thus, from the foregoing, it can be seen that an image building system using labeled instructions according to proposed embodiments can implement improved utilization of the container image cache. This can be achieved by identifying commands that do not affect the final container image content and then avoiding the creation of new container image layers for such commands, which would otherwise increase the container image size. Some embodiments of the present invention can be thought of as distinguishing between stateful and stateless commands to improve cache reusability, which can be achieved by associating an identifier with commands that indicates whether the commands are stateless or not.

[0071] Referring now to Figure 4, a flow diagram of a method according to one embodiment of the present invention is illustrated. The method includes two (sub) methods: a first (sub) method 400 includes a method for processing commands to build an image according to one embodiment of the present invention, and a second (sub) method 450 includes a method for building a container image (using the processed commands). That is, the method illustrated in Figure 4 implements a method for (pre-)processing commands that identify stateless commands, followed by a proposed method for building an image from the (pre-)processed commands.

[0072] A first (sub) method 400 is undertaken to process a set of commands for building an image for a containerized computing environment, each command including one or more instructions for building a container image.

[0073] At 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, determining whether an instance of the command in the previous layer can be reused in response to determining that the command exists in the previous layer, and determining that the command is stateful in response to determining that an instance of the command in the previous layer can be reused.

[0074] In step 420, based on the analysis results from step 410, a respective identifier is associated with each command determined to be stateless. In this example, the identifier includes a character / symbol (such as "*" or "!"), and the identifier is associated with a stateless command by inserting the character / symbol immediately preceding the command (on the same code line / command line). In this way, stateless commands are identified by their respective identifier prefixes, which indicate that the command immediately following the identifier prefix is a stateless command.

[0075] It will be appreciated that as a result of completing the first (sub) method 400 of processing a set of commands, a new set of (pre-)processed commands is provided by the first (sub) method, the new set of (pre-)processed commands including one or more stateless commands, each of the stateless commands having an associated identifier indicating the stateless nature of the command.

[0076] The new set of (pre-)processed commands is provided to a second (sub) method 450 for building a container image using the (pre-)processed commands (from the first (sub) method 400).

[0077] In step 460, a set of (pre-)processed commands is obtained, for example via a communications interface. As mentioned above, one or more commands in the set have an associated identifier that indicates that the associated command is stateless.

[0078] At step 470, for each command, reuse of a previously constructed image layer (via cache memory) is controlled based on whether the command has an associated identifier that indicates the command is stateless. In particular, in response to an identifier being associated with the command that indicates the command is stateless, use of a previously constructed image layer to respond to the command is prevented.

[0079] Referring now to Figure 5, a simplified block diagram of a system 500 according to a proposed embodiment is shown. The method includes two (sub)systems: a first (sub)system 505 includes a system for processing commands for building an image according to a 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 invention. That is, the system 500 shown in Figure 5 embodies the proposed system 500 for (pre-)processing commands specifying stateless commands, combined with the proposed image building system 550 for building an image from the (pre-)processed commands.

[0080] 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 analyzer component 510 and an editor component 520.

[0081] The analysis component 510 analyzes each command to determine whether the command 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, determining whether an instance of the command in the previous layer can be reused in response to determining that the command exists in the previous layer, and determining whether the command is stateful in response to determining that an instance of the command in the previous layer can be reused.

[0082] Based on the analysis results of the analysis component 510, the editor component associates each identifier with the commands determined to be stateless. In this example, the identifiers include a comment / hint string, and the identifiers are associated with stateless commands by inserting the comment / hint string on the line immediately preceding the command (in the line of code / command line immediately above the command). In this way, stateless commands are identified with a comment / hint for each identifier that indicates that the command immediately following the comment / hint is a stateless command.

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

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

[0085] The interface component 560 retrieves a set of (pre-)processed commands, for example, via a wired or wireless communications link. As mentioned above, one or more commands in the set have an associated identifier that indicates that the associated command is stateless.

[0086] For each command, the controller controls (via cache memory) the reuse of a previously constructed image layer based on whether the command has an associated identifier that indicates the command is stateless. In particular, in response to an identifier being associated with the command that indicates the command is stateless, the controller responds to the command by preventing the use of a previously constructed image layer.

[0087] Thus, from the foregoing, it will be appreciated that the proposed method and system provides a distinction between stateless and stateful commands, based on which the image building system / method processes stateless commands differently from stateful commands, thereby improving cache memory utilization.

[0088] Some embodiments of the present invention relate to a computer-implemented method for building an image for a containerized computing environment, the computer-implemented method including: (i) obtaining a set of one or more instruction commands for building an image, wherein a command in the set of commands has an associated identifier indicating the command is stateful or stateless; and (ii) controlling, for a command, based on the associated identifier indicating the command is stateful or stateless, by: (a) reusing a previously built image layer in response to an identifier associated with the command indicating the command is stateful, and (b) preventing use of a previously built image layer in response to an identifier associated with the command indicating the command is stateless.

[0089] Some embodiments of the present invention ignore commands that are identified as stateless.

[0090] The above embodiments have included a limited set of example identifiers for indicating stateful or statelessness, however it will be appreciated that the proposed concepts may be adapted or modified to use other ways of identifying statelessness (commands).

[0091] As is apparent from the foregoing description, all or part of the system according to the proposed embodiment is provided by a cloud computing system, and the system for processing commands to build an image may be provided or implemented in a hybrid cloud computing system.

[0092] With reference to the following description made with respect to a cloud computing system, it is understood in advance that although the present disclosure includes detailed descriptions of cloud computing, implementation of the present teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the present invention can be implemented in connection with other types of computing environments, now known or later developed. The following description of a cloud computing system and environment is made purely for purposes of explanation and understanding.

[0093] Cloud computing is a service delivery model that enables 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 administrative effort or interaction with the service provider. This off-premises cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0094] Characteristics include: On-Demand Service: Cloud consumers can unilaterally provide computing capacity, such as server time or network storage, without requiring human interaction with the service provider. Wide Network Access: Capacity is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin- or thick-client platforms (e.g., mobile phones, laptops, and PDAs). Resource Pooling: Provider computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated based on demand. There is a sense of location independence in that consumers generally have no control or knowledge of the exact location of the resources provided, although it may be possible to specify location at a higher level of abstraction (e.g., country, state, or data center). Rapid Elasticity: Capacity can be provisioned quickly and elastically, and in some instances can be automatically scaled out quickly, released quickly, and scaled in quickly. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased in any quantity and at any time. Metered Services: Cloud systems automatically control and optimize resource usage by leveraging their ability to measure at several levels of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to providers and consumers of the services used.

[0095] The service model is as follows:

[0096] Software as a Service (SaaS): The capability offered to the consumer is to use a provider's applications running on a cloud infrastructure. The applications are accessible from multiple 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 application capabilities, with the only possible exception being limited user-specific application configuration. Platform as a Service (PaaS): The capability offered to the consumer is deployed on cloud infrastructure created by the consumer or on resulting applications 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 does have control over the deployed applications and, in some cases, the application host environment configuration. Infrastructure as a Service (IaaS): The capability offered to the consumer is provisioned with processing, storage, network, and other underlying computing resources, and the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does manage or control the operating system, storage, deployed applications, and in some cases has limited control of selected network components (e.g., host firewalls).

[0097] The deployment model is as follows:

[0098] Private cloud: Cloud infrastructure is dedicated to an organization. It may be managed by the organization or a third party and may exist on-premises or off-premises. Community cloud: Cloud infrastructure is shared by several organizations and supports a specific community that shares shared concerns (e.g., mission, security requirements, policy and compliance considerations). Cloud infrastructure may be managed by the organization or a third party and may exist on-premises or off-premises. Public cloud: Cloud infrastructure is owned by an organization that sells available and created cloud services to the general public or large industry groups. Hybrid cloud: Cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data portability and application portability. Cloud computing environments are service oriented with an emphasis on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0099] 6, there is shown a schematic diagram of an example cloud computing node. Cloud computing node 10 is merely one example of a suitable cloud computing node and is not intended to suggest any limitation on the scope of use or functionality of the inventive embodiments described herein. Regardless, cloud computing node 10 may implement or perform any of the functions described above, or a combination thereof.

[0100] Cloud computing node 10 includes computer system / server 12, which may operate using countless other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system / server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, distributed cloud computing environments that include these systems or devices, and the like.

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

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

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

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

[0105] The system memory 28 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 30 or cache memory 32, or a combination thereof. The computer system / server 12 may further 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 non-removable, non-volatile magnetic media (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to removable, non-volatile magnetic media (e.g., floppy disks), and an optical disk drive may be provided for reading from and writing to removable, non-volatile magnetic media, such as CD-ROMs, DVD-ROMs, or other optical media. In such an example, each may be connected to the bus 18 by one or more data media interfaces. As further illustrated and described below, the memory 28 may include at least one program having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the present invention.

[0106] The program / utility 40, having a set of (at least one) program modules 42, may be stored in memory 28, for example and without limitation, and may be stored in an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or a combination thereof, may include a network environment implementation. The program modules 42 generally perform the functions or methodologies, or a combination thereof, of embodiments of the present invention as described herein.

[0107] 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 allow a user to interact with the computer system / server 12, and / or any devices (e.g., network cards, modems, etc.) that allow the computer system / server 12 to communicate with one or more other computing devices. Such communication may occur via an input / output (I / O) interface 22. Still further, the computer system / server 12 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet) via a network adapter 20. As shown, the network adapter 20 communicates with other components of the computer system / server 12 via a bus 18. Although not shown, it should be understood that other hardware or software components, or combinations thereof, may be used in connection 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 archive storage systems.

[0108] Referring now to FIG. 7, an exemplary cloud computing environment or cloud computing system 50 is illustrated, which, in embodiments, may be considered equivalent to a cloud computing system such as that illustrated in FIG. 1. As illustrated, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, may communicate. The nodes 10 may also communicate with each other. The nodes may be physically or virtually grouped (not shown) in one or more networks in a private, community, public, or hybrid cloud, or combinations thereof, as described above. This enables the cloud computing environment 50 to provide infrastructure, platform, or software, or a combination thereof, as a service, without the cloud consumer having to maintain resources on their local computing device. It will be understood that the types of computing devices 54A-54N shown in FIG. 7 are intended to be illustrative only, and that computing node 10 and cloud computing environment 50 may communicate with any type of computerized device (e.g., using a web browser) through any type of network or network-addressable connection, or combination thereof.

[0109] Referring now to Figure 8, there is shown a set of functional abstraction layers provided by cloud computing environment 50 (Figure 7). It should be understood in advance that the components, layers, and functions shown in Figure 8 are intended to be merely exemplary, and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0110] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes, such as IBM® z-Series® systems; RISC (reduced instruction set computer) architecture-based servers, such as IBM p-Series® systems, IBM x-Series® systems, and IBM BladeCenter® systems; storage devices; and networks and network components. Examples of software components include network application server software, such as IBM WebSphere® application server software; and database software, such as IBM DB2® database software. (IBM, z-Series, p-Series, x-Series, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide.)

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

[0112] In one example, the management layer 64 may provide the following functions: Resource provisioning provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing provides cost tracking as resources are utilized within the cloud computing environment and billing consumers or organizations for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity recognition for cloud consumers and tasks, as well as protection for data and other resources. A user portal provides access to the cloud computing environment for consumers and system administrators. Service level management provides cloud computing resource allocation and management to meet required service levels. Image building provides container image building according to the proposed concepts detailed above.

[0113] The workload layer 66 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this layer include mapping and navigation, software and lifecycle management, virtual classroom instruction delivery, data analytics processing, transaction processing, and mobile desktops.

[0114] The present invention may be a system, a method, or a computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to perform aspects of the present invention.

[0115] A computer-readable storage medium may be a tangible device that may retain and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer diskette, 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 disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or raised structure having instructions recorded in grooves, or a suitable combination thereof. Computer-readable storage medium, as used herein, should not be construed as being signals that are transitory in nature, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through wires.

[0116] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each 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, or a wireless network, or a combination thereof. The network may comprise copper transmission cables, optical transmission cables, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. 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 each computing / processing device.

[0117] The computer-readable program instructions for carrying out the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in a combination of one or more programming languages, including object-oriented programming languages such as Smalltalk®, C++, etc., and traditional procedural languages such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In a remote computer scenario, the remote computer may be connected to the user's computer through any type of local area network (LAN) or wide area network (WAN) network, or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0118] Aspects of the present invention are described herein with reference to flowchart illustrations or block diagrams, or combinations thereof, of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations or block diagrams, or combinations thereof, and combinations of blocks of the flowchart illustrations or block diagrams, or combinations thereof, can be implemented by computer-readable program instructions. These computer-readable program instructions can 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 means for implementing the functions / acts specified in one or more blocks of the flowchart illustrations or block diagrams, or combinations thereof. These computer-readable program instructions, which can direct a computer, programmable data processing apparatus, or other device, or combinations thereof, to function in a particular manner, can also be stored on a computer-readable storage medium, such that a computer-readable storage medium having instructions stored therein includes an article of manufacture containing instructions that implement the functions / acts specified in one or more blocks of the flowchart illustrations or block diagrams, or combinations thereof.

[0119] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram represents a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may not occur in the order noted in the figures. For example, two blocks shown in succession may, in fact, be performed substantially in parallel, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of a flowchart or block diagram, or a combination thereof, and combinations of blocks in a flowchart or block diagram, or a combination thereof, are implemented by a special-purpose hardware-based system that performs the specified functions or operates or executes special-purpose hardware and computer instructions. According to this specification, the following items are also disclosed. [Item 1] 1. A computer-implemented method for processing commands to build an image for a containerized computing environment, comprising: analyzing the command, including one or more instructions for building an image, to determine whether the command is a stateful command or a stateless command; and associating an identifier with the command based on the results of the analysis, the identifier configured to indicate whether the command is stateful or stateless. [Item 2] Item 10. The method of item 1, wherein associating an identifier with the command includes appending a command prefix or command attribute to the command to indicate that the command is stateless. [Item 3] Item 3. The method of item 2, wherein the identifier comprises a symbol or a command string. [Item 4] The stage of analyzing the command is determining whether the command exists in a previous image layer; in response to determining that the command exists in a previous layer, determining whether an instance of the command in the previous layer can be reused; determining that the command is stateful in response to determining that the instance of the command in the previous layer can be reused. [Item 5] determining whether the command exists in the previous image layer; Item 5. The method of item 4, including searching for the command in image layer data stored in a cache memory. [Item 6] 6. The method according to any one of items 1 to 5, wherein the command is a container image build command of a Docker build system. [Item 7] A computer program for processing commands for building an image for a containerized computing environment, the computer program comprising: analyzing the command, including one or more instructions for building an image, to determine whether the command is a stateful command or a stateless command; associating an identifier with the command based on the results of the analysis, the identifier configured to indicate whether the command is stateful or stateless; A computer program to be executed. [Item 8] 8. The computer program of claim 7, wherein associating an identifier with the command includes adding a command prefix or command attribute to the command to indicate that the command is stateless. [Item 9] Item 9. The computer program of item 8, wherein the identifier comprises a symbol or a command string. [Item 10] The procedure for analyzing the command is determining whether the command exists in a previous image layer; in response to determining that the command exists in a previous layer, determining whether an instance of the command in the previous layer can be reused; and determining that the command is stateful in response to determining that the instance of the command in the previous layer can be reused. [Item 11] determining whether the command exists in the previous image layer, Item 11. The computer program of item 10, including a procedure for searching for the command in image layer data stored in a cache memory. [Item 12] 12. The computer program of any one of items 7 to 11, wherein the command is a container image build command of a Docker build system. [Item 13] 1. A computer system for processing commands to build an image for a containerized computing environment, comprising: A processor set; a computer-readable storage medium having program instructions stored therein; wherein said program instructions, when executed by said processor set, cause said processor set to perform an operation, said operation being: analyzing the command, including one or more instructions for building an image, to determine whether the command is a stateful command or a stateless command; and associating an identifier with the command based on a result of the analysis, the identifier configured to indicate whether the command is stateful or stateless. [Item 14] Item 14. The computer system of item 13, wherein associating an identifier with the command includes appending a command prefix or command attribute to the command to indicate that the command is stateless. [Item 15] Item 15. The computer system of item 14, wherein the identifier comprises a symbol or a command string. [Item 16] Analyzing the command determining whether the command exists in a previous image layer; In response to determining that the command exists in a previous layer, determining whether an instance of the command in the previous layer can be reused; and determining that the command is stateful in response to determining that the instance of the command in the previous layer can be reused. [Item 17] Determining whether the command exists in the previous image layer Item 17. The computer system of item 16, including searching for the command in image layer data stored in a cache memory. [Item 18] 18. The computer system of any one of items 13 to 17, wherein the command is a container image build command of a Docker build system. < / arguments> < / arguments>

Claims

1. 1. A computer-implemented method for processing commands to build an image for a containerized computing environment, comprising: analyzing the command, including one or more instructions for building an image, to determine whether the command is a stateful command or a stateless command; and associating an identifier with the command based on the results of the analysis, the identifier configured to indicate whether the command is stateful or stateless.

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

3. The method of claim 2 , wherein the identifier comprises a symbol or a command string.

4. The stage of analyzing the command is determining whether the command is present in a previously constructed image layer, the previously constructed image layer being one of cached image layers that comprise the image; determining whether the previously constructed image layer can be reused in response to determining that the command exists in the previously constructed image layer; and determining that the command is stateful in response to determining that the previously constructed image layer can be reused.

5. determining whether the command exists in the previously constructed image layer, 5. The method of claim 4, including searching for the command in image layer data stored in a cache memory.

6. The method of claim 1 , wherein the command is a container image build command of an image build system, and the image is built by the container image build command of the image build system.

7. A computer program for processing commands for building an image for a containerized computing environment, the computer program comprising: analyzing the command, which includes one or more instructions for building an image, to determine whether the command is a stateful command or a stateless command; associating an identifier with the command based on the results of the analysis, the identifier configured to indicate whether the command is stateful or stateless; A computer program to be executed.

8. 8. The computer program product of claim 7, wherein associating an identifier with the command comprises appending a command prefix or a command attribute to the command to indicate that the command is stateless.

9. The computer program product of claim 8 , wherein the identifier comprises a symbol or a command string.

10. The procedure for analyzing the command is determining whether the command is present in a previously constructed image layer, the previously constructed image layer being one of the cached image layers that comprise the image; determining whether the previously constructed image layer can be reused in response to determining that the command exists in the previously constructed image layer; and determining that the command is stateful in response to determining that the previously constructed image layer can be reused.

11. determining whether the command exists in the previously constructed image layer; 11. The computer program of claim 10, further comprising searching for the command in image layer data stored in a cache memory.

12. The computer program product of claim 7 , wherein the command is a container image building command of an image building system, and the image is built by the container image building command of the image building system.

13. 1. A computer system for processing commands to build an image for a containerized computing environment, comprising: A processor set; a computer-readable storage medium having program instructions stored therein; wherein the program instructions, when executed by the processor set, cause the processor set to perform an operation, the operation comprising: analyzing the command, including one or more instructions for building an image, to determine whether the command is a stateful command or a stateless command; and associating an identifier with the command based on a result of the analysis, the identifier configured to indicate whether the command is stateful or stateless.

14. 14. The computer system of claim 13, wherein associating an identifier with the command comprises appending a command prefix or a command attribute to the command to indicate that the command is stateless.

15. The computer system of claim 14 , wherein the identifier comprises a symbol or a command string.

16. Analyzing the command determining whether the command is present in a previously constructed image layer, the previously constructed image layer being one of the cached image layers that comprise the image; and determining whether the previously constructed image layer can be reused in response to determining that the command exists in the previously constructed image layer; and determining that the previously constructed command is stateful in response to determining that the previously constructed image layer can be reused.

17. determining whether the command exists in the previously constructed image layer; 17. The computer system of claim 16, further comprising searching for the command in image layer data stored in a cache memory.

18. 18. The computer system of claim 13, wherein the command is a container image build command of an image build system, and the image is built by the container image build command of the image build system.

Images