DATA PROCESSING UNITS WITH DYNAMIC PROVISION OF SOFTWARE FUNCTIONS

Abstract

Data processing unit, comprising: a network interface (636); a processor (620); and a storage unit in which a set of instructions is stored, wherein execution of the set of instructions by the processor (620) configures the data processing unit to perform steps that include: Operating an application container that executes a core function which calls a service function; Receiving a capsule image via the network interface that contains images of the service function, wherein the capsule image contains metadata that matches the application container; Starting a capsule container based on the capsule image to execute the service function called by the application container's core function; and Exiting the capsule container after the service function has completed execution, where an image of the application container contains no image or dependencies of the service function called by the core function.

Description

BACKGROUNDTechnical field

[0001] The present disclosure relates generally to tools for developing and implementing software, and more particularly to data processing units with dynamic provisioning of software functions. Description of the state of the art

[0002] In agile DevOps (development and operations environments), applications are increasingly being containerized. An application comprises a complete runtime environment for running the desired software: an application with all its dependencies, libraries, and other binaries, as well as configuration files for running the software, bundled into a single package. Containerizing the application platform and its dependencies eliminates differences in OS distributions and the underlying infrastructure. The complete set of information of an application container is the image. An image is an inactive, immutable file that represents a snapshot of a container. A container image is created with a build command. The container image creates an application container when deployed or executed on host machines or host computing devices.

[0003] A method for partitioning functions into containers is known from the paper Rastogi et al.: “CIMPLIFIER: Automatically Debloating Containers”.

[0004] A method for constructing containers is known from the document "Taylor, Twain: Oracle pushes open source envelope to gain foothold in the cloud; TechGenix; September 29, 2017, pp. 1-10.", URL: https: / / techgenix.com / oracle-cloud-open-source / ", accessed on February 23, 2022.

[0005] From the document "crashcart - microcontainer debugging tool, GitHub, December 27, 2017" URL: https: / / github.com / oracle / crashcart / blob / 2af563e8f29a63d361c1c614464-ce1312d137f16 / README.md, accessed on February 23, 2022, a software for debugging microcontainers is known. SUMMARY

[0006] Some embodiments of the disclosure provide a container cloud platform that enables sharing of software functions among multiple applications in different application containers. The service functions are containerized and separated from the application containers. The containerized services are provided as a capsule for applications that invoke the service functions at application runtime. The images of the service containers are deployed on the host computing devices that run the corresponding application containers. The container cloud platform monitors the deployed service containers for both their execution and their termination.

[0007] The container cloud platform includes a run-escape controller that monitors a set of host compute units. Each host compute unit runs one or more application containers. The run-escape controller identifies a capsule image that has metadata matching an application container running on a host compute unit. The run-escape controller implements the identified capsule image on the host compute unit as a capsule container. The implemented capsule container includes a service function invoked by a core function of the matching application container. The run-escape controller receives an exit code from the host compute unit based on the execution of the service function.

[0008] A host machine runs an application container that executes a core function that calls a service function. The host machine receives a capsule image containing images of the service function. The capsule image contains metadata that matches the application container. The host machine starts a capsule container based on the capsule image to execute the service function called by the application container's core function. The host machine exits the capsule container after the service function completes execution.

[0009] The objects underlying the invention are achieved by the features of the independent claims. Advantageous developments of the subject matter of the independent claims are characterized in the subclaims. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 conceptually illustrates a container cloud platform implementing service containers on host computing devices running application containers, in accordance with an example embodiment. Fig. 2 conceptually illustrates using the metadata of a capsule image to identify matching application containers according to an example embodiment. Fig. 3 illustrates the creation of capsule images according to an exemplary embodiment. Fig. 4 conceptually illustrates a process for executing capsule images as service containers for core functions in application containers according to an example embodiment. Fig. Figure 5 conceptually illustrates a process for implementing capsule images of service functions on host machines running application containers that use the service functions. Fig. 6 shows a block diagram of the components of a data processing system according to an illustrative embodiment of the present disclosure. Fig. Figure 7 illustrates an example cloud computing environment. Fig. 8 illustrates a set of functional abstraction layers provided by a cloud computing environment, according to an example embodiment. DETAILED DESCRIPTION

[0010] An application has many component software functions. Some of these functions can be classified as core functions, and others can be classified as service or secondary software functions. Core functions are typically written specifically for the application by the application developer to define the application. They are not predefined for use by different applications. Service or secondary functions support the implementation of the core functions. These are typically predefined functions written for use by different applications (such as libraries). Some service functions are low-level routines that target specific hardware platforms. Examples of such secondary or service functions include periodically called functions such as an NTP update, a data backup, or a data consistency check function.Examples of secondary or service functions include sporadic functions such as increasing the size of the database table and selective data compression or pruning functions.

[0011] Secondary software features used by an application are typically built together with the application's core features in the same container image. This results in bloated container images, with portions of the images corresponding to shared secondary software features being rebuilt repeatedly.

[0012] To separate the secondary function from the application container image, some embodiments of the disclosure provide a container cloud platform that enables sharing of software functions, e.g., secondary service functions, between multiple applications in different application containers. The service functions are containerized and separated from the application containers. The containerized services are provided as a capsule for applications that invoke the service functions at application runtime. These containerized services are referred to as service containers. The service container images are deployed on the host computing devices that run the corresponding application containers. The container cloud platform monitors the deployed service containers for both their execution and their termination.In some embodiments, service containers are implemented on the host computing devices as capsule images, so a service container may also be referred to as a capsule container.

[0013] The container cloud platform 100 is managed and controlled by an execution exit controller 110. The execution exit controller 110 exchanges data with host computing units 101 to 103 participating in the container cloud platform 100. The computing units 101 to 103 and the execution exit controller 110 can use their respective network interfaces to exchange data with each other via the Internet, the computing cloud, a local area network, or another type of data transmission medium.

[0014] Execution exit controller 110 is a computing device that has access to an image registry database 120, which stores a variety of software images, including capsule images for various service functions. When deployed on a host machine running an application container, a capsule image is executed as a service container. Execution exit controller 110 monitors host machines 101 through 103 for the application containers running on these computing devices. Execution exit controller 110 identifies the service functions required by these application containers and implements corresponding capsule images of the service containers on these host machines.In the example, the container cloud platform allocates or deploys capsule images A and B to host machine 101, capsule image B to host machine 102, and capsule images A and C to host machine 103.

[0015] As illustrated, the host computing device 101 operates application containers S, V, T, and Z. The image of each of these application containers contains images of one or more core functions. However, the images of application containers S, V, and T do not contain the images or dependencies of the service functions used to execute the core functions. In the example, the core functions of application containers S and V are concurrent with service function A, but the images of application containers S and V do not include service function A. The core functions of application container T are concurrent with service function B, but the image of application container T does not include service function B. Accordingly, the execution exit controller 110 of the container cloud platform 100 implements capsule images for service function A and service function B on the host computing device 101.

[0016] Once a capsule image is deployed on a host machine, the host machine can run the capsule image as a service container for the service function. The host machine runs the service function for core functions that call the service function. In the example from Fig. 1, the host computing device 101 executes the capsule image A as a service container A for the service function A. This enables the host computing device 101 to properly execute the core functions of the application containers S and V with the service function A. Likewise, the host computing device 101 executes the capsule image B as a service container B for the service function B. This enables the host computing device 101 to properly execute the core functions of the application container T with the service function B.

[0017] In some embodiments, for each application container using a service function, the corresponding service container starts a service thread that executes an instance of the service function for the application container. The host machine exits each instance of the service function by terminating its corresponding service thread when the service thread has completed its work. Because the service function thread in the service container terminates once it has finished executing the service function, a capsule image of a service container is referred to as a run-escape capsule (REC). The controller 110 of the container cloud platform 100 is referred to as a run-escape controller because it monitors and controls the execution and termination of each run-escape capsule.

[0018] In some embodiments, each service thread of an instance of the service function operates in the namespace of the application container that invokes the instance of the service function. As illustrated, service container A operates a first service thread for a first instance 131 of service function A in the namespace of application container S. Service container A also operates a second service thread for a second instance 132 of service function A in the namespace of application container V. Because the two instances 131 and 132 of service function A operate in different namespaces, the operations of service function A for application container S would not affect the operations of service function A for application container V, and vice versa. Similarly, service container B operates a service thread for an instance 141 of service function B in the namespace of application container T.

[0019] In some embodiments, the host machine may run the different instances of the service function for different application containers in parallel. The host machine may also run only one instance of the service function at any time, so that each application container calling the service function must wait its turn to execute the service function (e.g., sequentially or iteratively).

[0020] Implementing capsule images allows application container images to contain only core functions and not service functions and their dependencies. Using capsule images also allows different application containers on the same host machine to share the same service function image. Furthermore, the container cloud platform can implement the same capsule image on different host machines, allowing application containers on different host machines to call the same service function without having to include the service function in their container images. In the example from Fig. 1, the execution exit control unit 110 implements the capsule image A on the two host machines 101 and 103, the capsule image B on the two host machines 101 and 102.

[0021] In some embodiments, each capsule image is associated with a set of metadata. The metadata of a capsule image provides labels or tags that a host machine receiving the capsule image can use to identify the application containers that match the service function of the capsule image. The metadata of a capsule image also enables the execution exit controller 110 to identify the host machines on which the matching application containers are running.

[0022] Fig. Figure 2 conceptually illustrates using the metadata of a capsule image to identify matching application containers according to an exemplary embodiment. As illustrated, capsule images A, B, and C are registered in the image registry database 120, which is accessible to the exit execution controller 110 of the container cloud platform 100. The exit execution controller 110 monitors multiple application containers S, T, U, V, W, X, and Y. These application containers are run on host machines such as host machines 101 through 103 (not illustrated). Each capsule image may include the image of a service function, a capsule management script, and metadata.

[0023] The capsule image A contains a service image 211, a capsule management script 212 and metadata 213.

[0024] The service image 211 is the image of the service function that can be executed to perform the service function of the capsule image A.

[0025] The capsule management script 212 manages the data exchange between the execution exit controller 110, which implements the capsule image, and the host machine that receives the deployed capsule image. The capsule management script 212 is also configured to invoke the default entry point. The capsule management script 212 enables the execution exit controller 110 to exchange data with the capsule container for the purpose of management activities. For example, the execution exit controller 110 can invoke the capsule management script to query the status of the service function executing within the service container.

[0026] The metadata 213 contains a set of capsule reference tags 221. The set of capsule reference tags 221 specifies the criteria for identifying matching application containers for the service function of capsule image A. The set of capsule reference tags 221 specifies "OS=ubuntu," i.e., using the Ubuntu operating system. This matches application containers S, V, and Y, which use the Ubuntu operating system ("OS=ubuntu"). The execution exit control unit 110, in turn, implements capsule image A on the host machines running application containers S, V, or Y (e.g., on host machines 101 and 103).

[0027] In addition to the set of capsule reference tags 221, the metadata 213 of a capsule image also contains information such as a service function identifier 220, a restriction parameter 222, and a security rating flag 223. The restriction parameter 222 specifies whether the host machine can run different instances of the service function for different application containers in parallel, or only one instance of the service function at any time. The security rating flag 223 is an indication of whether the capsule image has passed or failed a security check. The execution exit controller 110 can use this flag to determine whether the execution of this service function should be restricted for certain application containers. This ensures the security of executed service functions.

[0028] Fig. Figure 2 also illustrates the contents of capsule images B and C. The set of capsule reference tags of capsule image B indicates "OS=rhel, app=db2." This matches application containers T and W, so the execution exit controller 110 implements capsule image B on the host machines running application containers T and W. The capsule reference tags of capsule image C indicate "app=kafka." This matches application containers U, X, and Y, so the execution exit controller 110 implements capsule image C on the host machines running application containers U, X, and Y.

[0029] It should be noted that an application container can use service functions from multiple different capsule images. In the example, application container Y matches the capsule reference marks of both capsules A and C (OS=ubuntu and app=kafka), so the execution exit controller 110 deploys both capsule images A and C to host machines running application container Y.

[0030] Fig. Figure 3 illustrates the creation of capsule images according to an exemplary embodiment. The capsule images of service containers are created based on codes or definitions of service functions provided by a developer. The created capsule images are registered in the image registry database 120 for retrieval by the execution exit control unit 110, which implements the capsule images on the application containers running on host machines. The figure illustrates the creation and registration of capsule images in six stages, labeled '1' through '6'.

[0031] In the first stage (denoted by '1'), a developer computing unit 301 receives a description or content (e.g., code) of a service function.

[0032] In the second stage (denoted by '2'), the developer computing unit 301 creates a service image 305 for the received service function. The service image 305 is created using a build command to include all dependencies and libraries required by the service function. The developer computing unit also specifies a startup script or default entry point 306 for invoking the service function. The developer computing unit also specifies the reference mark 307, which indicates which application containers monitored by the container cloud platform should receive the service image. The service image 305, the entry point 306, and the reference mark 307 are stored in the image registry 120 as a Docker image 320. A Docker image is an image of a Docker container, which is an open-source software development platform.The Docker container allows the service functionality to be portable to any system running the Linux operating system (OS).

[0033] In the third stage (denoted by '3'), the execution exit controller 110 retrieves the Docker image 320 from the image registry 120.

[0034] In the fourth stage (denoted by 4'), the execution exit controller 110 creates a capsule image 310 that wraps the service image. The execution exit controller 110 overrides the service image's default entry point with a capsule management script (e.g., 212) configured to call the service image's default entry point. The execution exit controller 110 also performs a security or vulnerability assessment of the newly created capsule image. The result of the security assessment is included in the metadata of the capsule image (which also includes the service image) as a security assessment flag (e.g., 223).

[0035] In the fifth stage, the execution exit controller 110 stores or registers the newly created capsule image 310 in the image registry database 120. The capsule image 310 contains the service function image, the capsule management script, and the service function metadata. The service function metadata includes a capsule reference tag, restrictions, and a security assessment result flag. In some embodiments, the execution exit controller 110 only registers or stores capsule images that pass the security assessment.

[0036] In the sixth stage, the capsule image 310 is registered in the image register 120 for subsequent retrieval and implementation by the execution exit control unit 110. Other service images of other service functions from other developer computing units (e.g., 302) may also be processed by the execution exit control unit 110 to generate other capsule images.

[0037] Fig. Figure 4 conceptually illustrates a process 400 for executing capsule images as service containers for core functions in application containers, according to an example embodiment. In some embodiments, a host machine (e.g., 101) performs process 400 when running application containers and communicating with the container cloud platform's execution exit controller 110. In some embodiments, one or more processing units (e.g., a processor) of the host machine perform process 400 by executing instructions stored in a computer-readable medium.

[0038] The host machine runs (at 410) an application container and executes a core application function that depends on (or invokes) a service function. The host machine may also run other application containers with other core functions. The host machine exchanges data with the execution exit controller 110 so that the execution exit controller 110 can learn which application containers are running on the host machine and which service functions are required by their core functions.

[0039] The host machine receives (at 420) a capsule image from the execution exit controller 110. The capsule image contains the image of a service function (or the service image) and its dependencies. The capsule image includes metadata with a reference tag that identifies the service function with application containers that use the service function.

[0040] The host machine executes (at 425) a capsule management script of the capsule image. The capsule management script manages data exchanges between the host machine and the execution exit controller that implements the capsule image. The management script is also configured to call the default entry point of the service function.

[0041] The host machine starts (at 430) a service thread based on the capsule image to execute the service function invoked by the application container's core function. In some embodiments, the service thread exists for an instance of the service function operating in the namespace of an application container, such that the service thread's operations would not affect the operations of other containers in the host machine. A constraint parameter (e.g., 222) in the capsule image metadata may allow the host machine to run different instances (such as service threads 131 and 132) of the service function for different application containers in parallel, or to restrict the host machine to running only one instance of the service function at a time.

[0042] The host machine exits (at 440) the service thread after the thread completes its work for the application container. In some embodiments, the host machine also reports an exit code to the exit execution controller 110. The capsule container on the host machine may retrigger the service thread if the application container requires it.

[0043] The host machine exits (at 450) the service container (capsule container) after applying the service function to all applicable application containers (or when the execution exit controller 110 instructs the host machine to forcibly exit the application container). The process 400 then ends.

[0044] Fig. Figure 5 conceptually illustrates a process 500 for implementing capsule images of service functions on host machines running application containers that use the service functions. In some embodiments, the execution exit controller 110 performs the process 500 when monitoring remotely located host machines for application containers that depend on the service functions. In some embodiments, one or more processing units (e.g., a processor) of the execution exit controller 110 perform the process 500 by executing instructions stored in a computer-readable medium.

[0045] The execution exit controller 110 monitors (at 510) a set of remotely located host computing devices, each host computing device running one or more application containers with core functions that depend on service functions.

[0046] The execution exit controller 110 identifies (at 520) a capsule image having metadata matching an application container running on one of the host machines. In some embodiments, this matching is based on a capsule reference flag (e.g., 221) in the capsule image's metadata. The reference flag may be inserted by the developer of the service function at the developer's computing device (e.g., 301) or by the execution exit controller 110. In some embodiments, the execution exit controller 110 determines whether the capsule image should be implemented based on a security assessment flag (e.g., 223) such that cloud images that fail the security assessment would not be deployed.

[0047] The execution exit controller 110 implements (at 530) the identified capsule image in the host machine running the matching application container as a service container. This service container (or capsule container) includes the service function invoked by a core function of the matching application container.

[0048] Exit execution controller 110 receives (at 540) an exit code from the host machine. The exit code indicates complete execution of the service function for an application container or for all application containers using the service function. In some embodiments, exit execution controller 110 notifies an administrator if it does not receive the exit code from the host machine within a threshold time period or if the exit code indicates that the execution of the service function was incorrect. Process 500 then ends.

[0049] Although not illustrated as part of process 500, the execution exit controller 110 also retrieves service images from the image registry database 120 and modifies them to become capsule images during the execution of process 500. As described with reference to Fig. 3 above, the execution exit controller 110 retrieves the service image to create a capsule image that wraps the service image. The default entry point of the service image is overwritten with a capsule management script. The execution exit controller 110 also performs a security or vulnerability assessment of the newly created capsule image. The newly created capsule image is registered in the image registry database 120. Example electronic system

[0050] The present invention may be a system, a method, and / or a computer program product at any possible technical level of integration. The computer program product may include computer-readable storage medium(s) having computer-readable program instructions stored thereon for causing a processor to perform aspects of the present disclosure.

[0051] The computer-readable storage medium may be any physical device that can retain and store instructions for use by an instruction-executing device. The 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 thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM).Flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded device such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium, as used herein, shall not be construed as containing transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., pulses of light carried through a fiber optic cable), or electrical signals carried through a wire.

[0052] Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing units or to an external computer or storage unit 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, fiber optic transmission lines, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing unit.Computer-readable program instructions for performing operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, integrated circuit configuration data, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, as well as traditional procedural programming 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 the remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, over the Internet using an Internet service provider).In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuits to perform aspects of the present disclosure.

[0053] Fig. Figure 6 shows a block diagram of the components of data processing systems 600 and 650 that may be used to implement the execution exit control unit 110 or a host machine (e.g., 101) according to an illustrative embodiment of the present invention. It should be appreciated that Fig. 6 merely provides an illustration of one implementation and imposes no limitations on the environments in which various embodiments may be implemented. Many variations may be made to the depicted environments based on design and implementation requirements.

[0054] Data processing systems 600 and 650 represent any electronic device capable of executing machine-readable program instructions. Data processing systems 600 and 650 may represent a smartphone, a computer system, a PDA, or other electronic devices. Examples of data processing systems, environments, and / or configurations that data processing systems 600 and 650 may represent 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, network PCs, minicomputer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0055] The data processing systems 600 and 650 may include a set of internal components 600 and a set of external components 650 that are Fig. 6. The set of internal components 600 includes one or more processors 620, one or more computer-readable RAMs 622 and one or more computer-readable ROMs 624 on one or more buses 626, as well as one or more operating systems 628 and one or more computer-readable physical storage devices 630. The one or more operating systems 628 and programs, such as the programs for executing processes 400 and 500, are stored on one or more computer-readable physical storage devices 630 for execution by one or more processors 620 via one or more RAMs 622 (which typically include cache memory). Fig. In the embodiment illustrated in Figure 6, each of the computer-readable physical storage devices 630 is a magnetic disk storage device of an internal hard disk drive. Alternatively, each of the computer-readable physical storage devices 630 is a semiconductor storage device such as ROM 624, EPROM, flash memory, or any other computer-readable physical storage device capable of storing a computer program and digital information.

[0056] The set of internal components 600 also includes a read / write drive or interface 632 for reading from and writing to one or more portable, computer-readable physical storage devices 686, such as a CD-ROM, DVD, memory stick, magnetic tape, magnetic disk, optical disk, or semiconductor storage device. Instructions for executing processes 400 and 500 may be stored on one or more of the respective portable, computer-readable physical storage devices 686, read via the respective read / write drive or interface 632, and loaded into the respective hard disk drive 630.

[0057] The set of internal components 600 may also include network adapters (or switch port cards) or interfaces 636, such as TCP / IP adapter cards, wireless Wi-Fi interface cards, or wireless 3G or 4G interface cards, or other wired or wireless data transmission connections. Instructions from the above-described processes or programs may be downloaded from an external computer (e.g., server) via a network (e.g., the Internet, a local area network, or another wide area network) and the respective network adapters or interfaces 636. The instructions and data of the described programs or processes are loaded from the network adapters (or switch port adapters) or interfaces 636 into the respective hard disk drive 630. The network may include copper cables, fiber optic cables, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers.

[0058] The set of external components 650 may include a computer display screen 670, a keyboard 680, and a computer mouse 684. The set of external components 650 may also include touch-sensitive screens, virtual keyboards, touchpads, pointing devices, and other human-machine interface devices. The set of internal components 600 also includes device drivers 640 for interfacing with the computer display screen 670, the keyboard 680, and the computer mouse 684. The device drivers 640, the R / W drive or interface 632, and the network adapter or interface 636 comprise hardware and software (stored in the storage device 630 and / or the ROM 624). Cloud computing environment

[0059] It should be understood from the outset that, although this disclosure includes a detailed description of cloud computing, implementation of the teachings herein is not limited to a cloud computing environment. Rather, embodiments of the present disclosure may be implemented in conjunction with any other type of computing environment now known or later invented. Cloud computing is a service delivery model for enabling seamless, 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 overhead or interaction with a service provider.This cloud model can include at least five properties, at least three service models, and at least four implementation models.

[0060] Example properties: On-demand self-service: A cloud user can unilaterally and automatically provision data processing functions such as server time and network storage as needed, without requiring human interaction with the service provider. Broad Network Access: Functions are available over a network and accessed through standard mechanisms that support 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 users using a multi-tenant model, with various physical and virtual resources dynamically allocated and reassigned as needed. There is a perceived location independence, as the user generally has no control or knowledge over the exact location of the provided resources, but may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center). Rapid Elasticity: Features can be deployed quickly and elastically for rapid horizontal scaling out, in some cases automatically, and released quickly for rapid scale-in. To the user, the features available for deployment often appear unlimited, and they can be purchased in any quantity at any time. Measured Service: Cloud systems automatically control and optimize resource usage by leveraging a measurement function at a certain level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, creating transparency for both the provider and the user of the service.

[0061] Example service models: Software as a Service (SaaS): The functionality provided to the user is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices via a thin client interface such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings. Platform as a Service (PaaS): The functionality provided to the user is to deploy applications created or obtained by a user, which were built using programming languages ​​and tools supported by the provider, on the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly over configurations of the application hosting environment. Infrastructure as a Service (laaS): The functionality provided to the user is to provide the processing, storage, networking, and other basic computing resources, whereby the user is able to deploy and run arbitrary software, which may include operating systems and applications. The user manages ordoes not control the underlying cloud infrastructure, but has control over operating systems, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls).

[0062] Deployment models: Private Cloud: The cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can be located on its own premises or on a third-party site. Community Cloud: The cloud infrastructure is shared by multiple organizations and supports a specific user community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organizations or a third party and can be located on their own premises or on someone else's premises. Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services. Hybrid Cloud: Cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain separate entities but are interconnected by a standardized or proprietary technology that enables data and application portability (e.g., cloud targeting for load balancing between clouds).

[0063] A cloud computing environment is service-oriented, focusing on state independence, low coupling, modularity, and semantic interoperability. At the heart of cloud computing lies an infrastructure consisting of a network of interconnected nodes.

[0064] With reference to Fig. 7 depicts an illustrative cloud computing environment 750. As shown, the cloud computing environment 750 includes one or more cloud computing nodes 710 with which local computing devices used by cloud users, such as the personal digital assistant (PDA) or cellular phone 754A, the desktop computer 754B, the laptop computer 754C, and / or the automotive computer system 754N, can communicate. The nodes 710 can communicate with each other. They can be physically or virtually grouped into one or more networks, such as private, community, public, or hybrid clouds (not shown), as described above, or a combination thereof. This enables the cloud computing environment 750 to offer infrastructure, platforms, and / or software as a service, for which a cloud user does not need to maintain resources on a local computing device.It should be noted that the types of in . Fig. 7 are intended to be merely illustrative, and that the computing nodes 710 and the cloud computing environment 750 may communicate with any type of computer-based device via any type of network and / or via any type of network-accessible connection (e.g., using a web browser).

[0065] With reference to Fig. 8 shows a set of functional abstraction layers implemented by the cloud computing environment 750 ( Fig. 7). It should be clear that the Fig. The components, layers, and functions shown in Figure 8 are intended to be illustrative only, and embodiments of the disclosure are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0066] A hardware and software layer 860 includes hardware and software components. Examples of hardware components include: mainframe computers 861; Reduced Instruction Set Computer (RISC) architecture-based servers 862; servers 863; blade servers 864; storage devices 865; and networks and network components 866. In some embodiments, software components include network application server software 867 and database software 868.

[0067] A virtualization layer 870 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 871; virtual storage 872; virtual networks 873, including virtual private networks; virtual applications and operating systems 874; and virtual clients 875.

[0068] In one example, a management layer 880 may provide the functions described below. Resource provisioning 881 provides for the dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 882 provides cost tracking when using resources within the cloud computing environment, as well as billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud users and tasks, as well as protection for data and other resources. A user portal 883 provides users and system administrators with access to the cloud computing environment.Service level management 884 provides for the allocation and management of cloud computing resources so that the required service objectives are met. Service level agreement (SLA) planning and fulfillment 885 provides for the pre-arranging and procurement of cloud computing resources for which future requirements are anticipated, according to an SLA.

[0069] A workload layer 890 provides examples of the functionality for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: mapping and navigation 891; software development and lifecycle management 892; virtual classroom education delivery 893; data analytics processing 894; transaction processing 895; and an exit execution controller 896. In some embodiments, the workload 896 performs some of the operations of the exit execution controller 110 in the container cloud platform 100.

[0070] The above one or more embodiments in which a computing infrastructure implements a container cloud platform comprising an execution exit controller computing unit that monitors a plurality of host computing units executing application containers. The execution exit controller implements capsule images on the host computing units, and the host computing units execute service containers from the implemented capsule images to provide service functions for the core functions in the application containers.

Claims

[1] Data processing unit comprising: a network interface (636); a processor (620); and a storage unit in which a set of instructions is stored, wherein execution of the set of instructions by the processor (620) configures the data processing unit to perform steps comprising: Running an application container that executes a core function that calls a service function; Receiving, via the network interface, a capsule image comprising images of the service function, the capsule image comprising metadata consistent with the application container; Starting a capsule container based on the capsule image to execute the service function called by the application container's core function; and Exiting the capsule container after the service function has completed execution, where an image of the application container has no images or dependencies of the service function called by the core function. [2] The computing device of claim 1, wherein starting the capsule container to execute the service function comprises starting a service thread that executes the service function in a namespace of the application container. [3] The computing device of claim 1, wherein starting a capsule container to execute the service function comprises executing a management script of the capsule image configured to communicate with a controller computing device and invoking a default entry point of the service function. [4] The computing device of claim 1, wherein the application container is one of a plurality of application containers that invokes the service function, each application container of the plurality of application containers matching the metadata of the capsule image. [5] The computing device of claim 4, wherein a plurality of service threads for the service function are executed in parallel for the plurality of application containers. [6] The computing device of claim 4, wherein the metadata of the capsule image includes an indication of whether multiple threads of the service function are allowed to execute in parallel for the plurality of application containers. [7] The data processing unit of claim 1, wherein the metadata of the capsule image includes an indication of whether the capsule image passes a security assessment. [8] The computing device of claim 1, wherein the application container image does not include the service function. [9] Data processing unit according to claim 1, wherein: the capsule image is received by a control unit data processing unit, and leaving the capsule container involves reporting a termination code to the control unit data processing unit. [10] The computing device of claim 1, wherein the application container is a first application container, the service function is a first service function, and the capsule image is a first capsule image, wherein the execution of the set of instructions by the processor further configures the computing device to perform steps comprising: Receiving a second capsule image having a second service function different from the first capsule image and the first service function, the second capsule image having metadata corresponding to a second application container having the second service function; and Starting the second capsule image to execute the second service function for a core function of the second application container. [11] Data processing unit, comprising: a set of one or more processing units (620); and a storage unit in which a set of instructions is stored, wherein execution of the set of instructions by the set of processing units (620) configures the data processing unit to perform steps comprising: Monitoring a set of host computing devices via a network interface (636), each host computing device running one or more application containers; Identifying a capsule image having metadata corresponding to an application container operating on a host computing device; Implementing the identified capsule image on the host computing device as a capsule container, wherein the implemented capsule container has a service function invoked by a core function of the matching first application container; and Receiving an exit code from the host computing device based on executing the service function, wherein an image of the application container has no images or dependencies of the service function called by the core function. [12] The data processing unit of claim 11, further comprising retrieving the identified capsule container image from a registry database in which a plurality of capsule images are stored. [13] The computing device of claim 11, wherein the application container image does not include the service function. [14] The computing device of claim 11, wherein the metadata of the capsule image includes an indication of whether multiple threads of the service function are permitted to execute in parallel for the plurality of application containers. [15] The data processing unit of claim 11, wherein the metadata of the capsule container includes an indication of whether the capsule container passes a security assessment. [16] The computing device of claim 11, wherein the capsule container comprises a management script that overrides a default entry point of the service function. [17] The computing device of claim 11, wherein executing the set of instructions by the set of processing devices further configures the computing device to perform steps comprising: Identifying a second host computing device running a second application container that matches the metadata of the capsule container; and Implementing the identified capsule container image on the second host computing device, wherein the service function is invoked by a core function of the second matching application container operating on the second host computing device. [18] The computing device of claim 11, wherein the application container is a first application container, the service function is a first service function, and the capsule image is a first capsule image, wherein the execution of the set of instructions by the set of processing devices further configures the computing device to perform steps comprising: Implementing a second capsule image having a second service function different from the first capsule image on the host computing device, wherein: a core function of the second application container calls the second service function, and the second capsule image has metadata that matches the second application container. [19] Data processing unit, comprising: a processor (620); and a storage unit in which a set of instructions is stored, wherein execution of the set of instructions by the processor (620) configures the data processing unit to perform steps comprising: Receiving an image of a service function that has a standard entry point; Building a capsule image for the service function; Assigning a metadata reference mark to the capsule image to identify an application container that matches the service function; Embedding a capsule management script in the capsule image for (i) managing data transfer between a control unit computing unit implementing the capsule image and the host machine receiving the implemented capsule image, and (ii) invoking the standard entry point of the service function; and Storing the capsule image in a registry of capsule images, where an image of the application container has no images or dependencies of the service function called by the core function. [20] The computing device of claim 19, wherein the capsule image has dependencies for the service function.

Images