JP2023535168A - Run-time environment determination for software containers - Google Patents

Abstract

Static parameters of the software container are identified that relate to metadata of the software container itself. Software containers are assigned to selected runtime environments based on static parameters using a first machine learning model. Runtime parameters of a software container are identified by analyzing the software container at runtime. Runtime parameters relate to actions required by the software container during runtime. A second machine learning model is used to determine whether the selected runtime environment matches the runtime parameters. If the runtime environment matches, the software container will continue to run in this environment. If the runtime environment does not match, the software container runs in a different runtime environment that matches both static and runtime parameters.

Description

Part of developing a system in which software can run involves configuring the system to provide the run-time environment in which the software will eventually run. The runtime environment should be defined to have all of the resources that will be required to run the application, and the runtime environment also provides some basic functionality needed for the application. can. For example, depending on the software language and application, the runtime environment may provide functionality such as garbage collection, stack and heap management, and the like. Additionally, the runtime environment may perform functionality such as load balancing, bin packing, self-healing actions, and the like, for example.

Aspects of the present disclosure relate to methods, systems, and computer program products related to determining runtime environment requirements of a software container. For example, the method includes identifying static parameters of the software container. Static parameters relate to metadata of the software container itself. The method further includes assigning the software containers to the selected runtime environment based on the static parameters using the first machine learning model. The method further includes identifying runtime parameters of the software container. Execution time parameters are identified by analyzing the software container prior to the execution time of the software container based on a second machine learning model. Runtime parameters relate to operations that the software container will require during runtime. The method further includes determining whether the selected runtime environment matches the runtime parameters; and executing the software container in the selected runtime environment when the selected runtime environment matches the runtime parameters. or running the software container in a different runtime environment that matches both the static and runtime parameters when the selected runtime environment does not match the runtime parameters. include. Systems and computer products configured to carry out the aforementioned methods are also disclosed.

The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure.

The drawings included in this application are incorporated into and form a part of this specification. They illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of certain embodiments and do not limit the disclosure.

1 depicts a conceptual diagram of an exemplary system in which a controller may assign tagged software containers to various run-time environments based on multiple machine learning models; FIG. 2 shows a conceptual box diagram of exemplary components of the controller of FIG. 1; FIG. 2 illustrates an exemplary flow diagram by which the controller of FIG. 1 may assign software containers to one of multiple runtime environments; 1 is a schematic diagram of a cloud computing environment in which playback speeds may be identified; FIG. 1 is a diagram of an abstract model layer of a cloud computing environment in which playback speeds may be identified; FIG.

While the invention is susceptible to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to particular embodiments described. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

While aspects of this disclosure relate to assigning software containers to runtime environments, more particular aspects of this disclosure relate to configuring a first machine learning model to analyze static parameters of software containers. and configuring a second machine learning model to analyze runtime parameters of software containers to determine runtime characteristics of software containers for the purpose of assigning software containers to runtime environments. . Although the disclosure is not necessarily limited to such applications, various aspects of the disclosure can be understood through discussion of various examples using this context.

In modern computer solutions, computing elements are becoming increasingly modular such that, for example, various virtual and/or real components, modules, workloads, etc. can be moved to different locations. For example, in a modern cloud environment there may be a large number of runtime environments available for running a large number of software containers for a large number of customers. Some or all runtime environments may have different kinds of resources available to them (e.g., different amounts of processing power, different amounts of memory, different input/output (IO) capabilities, etc.), and each A software container may use these functions to perform different functions within its run-time environment (e.g. different ratios of load balancing, different numbers of rollbacks, different ratios of automatic bin-packing, different ratios of self-healing, etc.). Different combinations of resources may be required.

The software container is in a run-time environment that is more robust than necessary (e.g., the software container only requires X load balancing actions per hour, and the run-time environment requires 2X load balancing actions per hour). actions can be provided), some resources of a complete computing system (whether within a single computer or across a network, e.g., a cloud computing network) are wasted or underutilized may not or both. Similarly, if the software container is in a runtime environment that does not provide the resources needed to run the software container at full capacity, then performance of the software container may be compromised. Modern systems routinely move software containers between different run-time environments to make poor use of resources or to slow down software containers during run-time due to insufficient resources of the run-time environment, or You can try to avoid both.

For example, conventional systems may employ a process in which a trained operator guesses which runtime environment best fits a software container. For example, a trained operator may have assigned multiple software containers to multiple run-time environments, assigning software containers to such run-time environments therein, and assigning similar software containers to similar software containers. may try to call something that worked before. The operator and/or the system then incrementally move the container to different environments over time until the needs of the software container appear to be a good match to the capabilities of the runtime environment, allowing the container to grow within the environment. You can monitor how it performs. However, this process is cumbersome and prone to user error, and it can take a relatively long time before the software container executes in a well-matched runtime environment.

To this end, conventional systems may attempt to use machine learning models to match software containers and runtime environments. Such machine learning models may attempt to find correlations between the characteristics of software containers, the needs of software containers within runtime environments, and potential runtime environments. However, there are many factors that distinguish software containers, and many capabilities that distinguish runtime environments. As such, conventional systems that use a single machine learning model can have difficulty finding true correlations.

Aspects of the present disclosure are intended to reduce or eliminate these problems of conventional systems. For example, aspects of the present disclosure include the use of a first machine learning model that analyzes static parameters of a software container to initially select a runtime environment, and that after executing in the runtime environment, the software container and using a second machine learning model that analyzes runtime parameters of the software container at runtime to check if it should be migrated. These two models can be updated independently based on the software container's performance in the initial (and any subsequent) runtime environment. By using two separate models in two different sets that process separate sets of variables, aspects of the present disclosure have relatively fast timeframes and relatively few iterations (e.g., several hours and within the first or second allocation to a given runtime environment, rather than the fourth, fifth, sixth, etc. allocation). It may improve the ability to assign software containers to runtime environments.

For example, FIG. 1 illustrates environment 100 in which controller 110 assigns software container 120 to one of a plurality of runtime environments 130A, 130B (collectively, "runtime environments 130"). Controller 110 includes a computing device, such as a processor communicatively coupled to a memory that, when executed by the processor, causes controller 110 to perform one or more of the operations described below. , can include

A software container 120 may contain a self-contained package containing code and a set of dependencies. This code and set dependencies may allow the software container 120 to execute in multiple runtime environments 130 that match the software container as described herein. In some examples, software container 120 may be received from a remote computing device, while in other examples software container 120 may be local to controller 110 . After executing in one of runtime environments 130, software container 120 may be accessed in this manner by one or more users. These users may be local or remote to one or each of controller 110, software container 120, or each assigned runtime environment 130, or a combination thereof.

Runtime environment 130 may be a structured environment within a computer system in which one or more software containers 120 may execute (e.g., the execution model of software container 120 is implemented by each runtime environment 130). (like being done). For example, runtime environment 130 may be associated with different nodes across a distributed system. Although only two runtime environments 130 are depicted in FIG. 1 for purposes of illustration, in other examples, controller 110 may have any number of runtime environments 130, each defining different capabilities.

Runtime environment 130 may be provided (eg, hosted) by one or more computing devices (eg, computing devices similar to computing system 200 of FIG. 2). Such computing device may be integrated with the computing device that hosts controller 110 and/or provides software container 120, or may be separate from such computing device. Such various computing devices in environment 100 may communicate via network 140 . Network 140 may include a computing network over which computing messages may be sent and/or received. For example, network 140 may include the Internet, a local area network (LAN), a wide area network (WAN), a wireless network such as a wireless LAN (WLAN), and the like. Network 140 may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or combinations thereof. A network adapter card or network interface within each computing/processing device receives messages and/or instructions from and/or over network 140 and sends messages and/or instructions to respective may be transferred to a respective memory or processor of a computing/processing device for storage, execution, or the like. Network 140 is depicted as a single entity in FIG. 1 for purposes of explanation, but in other examples network 140 is the one through which controller 110 manages connectivity as described herein. It may include multiple private and/or public networks that allow

Controller 110 may analyze static parameters of software container 120 to assign software container 120 to one of runtime environments 130 . These static parameters may relate to metadata of the software container itself. In some examples, none of these initial static parameters may directly define the requirements required by the software container 120 during runtime. Some of the static parameters may be nearly permanent in nature such that it is unlikely or impossible that the static parameters of the software container 120 will change over time.

For example, static parameters of the software container 120 may include variables such as the date and time when the software container 120 was created, when the software container 120 was last accessed (e.g., by a user or by a developer). the date and/or time that the software container 120 was last modified (e.g., such that the code and/or dependencies of the software container 120 changed); Size of software container 120 (in bytes), category or type of software container 120 (e.g., functionality of software container 120, target audience for software container 120, software container 120 being a cloud-based application) (based on whether there is, etc.), the template of the software container 120, or other such variables.

After controller 110 identifies these static parameters, controller 110 assigns software container 120 to one of runtime environments 130 . Controller 110 may use a first machine learning model to determine correlations between these static parameters and runtime environments 130 to assign software container 120 to one of runtime environments 130 . For example, controller 110 determines that the size of software container 120 created in the year in which software container 120 was created but not updated within the time frame reflected by the static parameters matches runtime environment 130A. can do. As such, controller 110 assigns software container 120 to runtime environment 130A and performs such steps (e.g., , moving software container 120 from a remote location to a location where software container 120 can execute in runtime environment 130A).

Controller 110 can monitor software container 120 during runtime in assigned runtime environment 130A. The controller 110 can monitor runtime parameters 120 of software containers. These run-time parameters may relate to actions required by the software container 120 during run-time. For example, as described above, the run-time parameters may include the restart policy of the software container 120, the number of load balancing actions per hour (e.g., the processing demand of the software container 120 allocated by the host of the software container 120). processing performed, including the number of times to further consider and/or filter out instances of maintenance, hardware failures, etc.), number of automatic rollbacks, number of automatic bin-packing actions, self It can relate to the number of recovery actions, and so on.

In addition, the controller 110 may determine the amount of accesses (reads) and/or the number of modification (write) actions of the software container 120 since its creation, and the number of accesses or modifications since the software container 120 was reset. Parameters such as the number of operations or both can be monitored.

Controller 110 may determine how well software container 120 matches runtime environment 130A. Controller 110 may determine that software container 120 matches runtime environment 130A based on the performance of software container 120 in runtime environment 130A. For example, the controller 110 can monitor central processing unit usage, memory usage, input/output usage, the number of times the software container 120 is accessed/modified by a user during runtime, and the like.

Controller 110 then uses a second machine learning model to determine whether this monitored performance indicates that software container 120, quantified by the runtime parameters, matches runtime environment 130A. decide. This second machine learning model may or may not include or reflect static parameters. In some examples, the second machine learning model may include some static parameters, such as the size of software container 120 . In another example, the second machine learning model can include all static parameters as well as run-time parameters, and the software container 120 in the already assigned (by the first machine learning model) run-time environment 130A. controller 110 determines whether runtime environment 130A matches software container 120, or whether another of runtime environments 130 is matched by software container 120. It can improve the ability to quickly identify if a good match can be made, or both.

The controller 110 determines the cost (e.g., billable resource usage, e.g. One of the runtime environments 130 may be determined to match the software container 120 when the usage or processing power) meets a threshold, or both.

Controller 110 may continue to monitor software container 120 over time, gathering increased data regarding performance and/or changing parameters. For example, controller 110 may determine that processing usage and/or memory usage of software containers 120 in runtime environment 130A spike such that performance (and/or cost) falls below a threshold. can. In response, controller 110 selects another one of run-time environments 130 so that run-time performance (and/or cost) may meet a threshold when running in this different run-time environment 130 . It can be analyzed whether one better matches the software container 120 . If controller 110 thus determines that a different runtime environment runtime environment 130B will match the static and/or runtime parameters, controller 110 will cause software container 120 to match this different runtime environment. It can instead run in environment 130B.

Controller 110 may continue to monitor software container 120 until the update in progress falls below the threshold. This is done so that the usage, cost, or performance, or combination thereof, of the software container 120 within the assigned runtime environment 130 is identified as stable, below a threshold static or runtime parameter, or both. May include changes to both. This may also include any identified mismatch between software container 120 and runtime environment 130 being below a threshold (e.g., 98% match for software container 120 to runtime environment 130). identifying as doing so may fall below the threshold for the need to continue monitoring). When controller 110 determines that ongoing updates are minimal (so that software container 120 and runtime environment 130 are well-matched, as described above), controller 110 updates the runtime environment 130 with software container 120 monitoring may be terminated.

Controller 110 can independently update both the first machine learning model and the second machine learning model. For example, the controller 110 may include both the finalized static and/or run-time parameters, the complete past performance of the software container 120 in each assigned run-time environment 130, each assigned can be updated with information regarding the full historical cost of the software container 120 in the runtime environment 130, and so on. Controller 110 can further distinguish between different classes, types, categories, etc. of software containers (eg, software containers 120) by distinguishing between each model. Over time, controller 110 also determines what properties of software container 120 hold true correlations that should dictate assignment to various runtime environments 130, and enforces the rules of the machine learning model. In the future, software containers 120 can be allocated accordingly. In this way, the monitored data of software container 120 performance and cost in runtime environment 130 over time becomes training data for determining how to improve in future software container 120 allocations. obtain.

In some examples, the runtime parameters determined and monitored by controller 110 may include the effect of software container 120 running within assigned runtime environment 130 on other downstream processes. For example, controller 110 determines that software container 120 is used to spool print jobs and another container is used for live audio processing for conference calls (e.g., these ), which is the category of the container. The controller 110 may further determine that if high CPU usage causes some slowdown during operation, the process containing the software container 120 may be substantially unaffected; On the other hand, the process of receiving the processed audio of the second container may be more substantially impacted by any latency or jitter introduced by computer processing conflicts. Upon determining this, controller 110 may determine that the performance threshold of software container 120 is different than the performance threshold of the second software container. In this way, the controller 110 not only enhances the ability of the software container 120 to execute in a given runtime environment, but also reduces the execution time of the software container 120 in its assigned runtime environment. The execution of the full computation process, including, can also be improved.

As noted above, controller 110 may include or be a computing device that includes a processor configured to execute instructions stored in memory to perform the techniques described herein. can be part of For example, FIG. 2 is a conceptual box diagram of such a computing system 200 of controller 110 . Although the controller 110 is depicted as a single entity (eg, within a single enclosure) for purposes of explanation, in other examples, the controller 110 may be multiple separate physical systems (eg, multiple separate enclosures). in the body). Controller 110 may include interface 210 , processor 220 , and memory 230 . Controller 110 may include any number or amount of interfaces 210, processors 220, or memory 230, or combinations thereof.

Controller 110 may include components that enable controller 110 to communicate (eg, transmit data to, and receive and use data transmitted by) devices that are external to controller 110 . . For example, controller 110 may include interface 210 configured to enable controller 110 and other components within controller 110 (eg, processor 220, etc.) to communicate with entities external to controller 110. Specifically, interface 210 enables components of controller 110 to communicate with a computing device that provides software container 120, one or more computing devices that host runtime environment 130, and the like. can be configured. Interface 210 includes one or more network interface cards, such as Ethernet cards, and/or any other type of interface device capable of sending and receiving information. obtain. Any suitable number of interfaces may be used to perform the functions described according to particular needs.

As described herein, controller 110 may be configured to assign software containers to runtime environments using different machine learning models. Controller 110 may use processor 220 to allocate software containers in this manner. Processor 220 may include, for example, a microprocessor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or equivalent discrete or integrated logic circuits or combinations thereof. . Two or more of the processors 220 each use a different machine learning model to learn different correlations and cooperate to initially and then iteratively load the software container before or during run time. to the runtime environment.

Processor 220 may assign software containers to runtime environments according to instructions 232 stored in memory 230 of controller 110 . Memory 230 may include a computer-readable storage medium or computer-readable storage device. In some examples, memory 230 may include one or more of short-term memory or long-term memory. Memory 230 may be, for example, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), magnetic hard disk, optical disk, floppy disk, flash memory, The memory may include forms of electrically programmable memory (EPROM), electrically erasable programmable memory (EEPROM), and the like. In some examples, processor 220 implements software in a runtime environment as described herein according to instructions 232 of one or more applications (eg, software applications) stored in memory 230 of controller 110 . • Containers can be assigned.

In addition to instructions 232, in some examples, collected/predetermined data or techniques used by processor 220 to assign software containers to runtime environments as described herein may be stored in memory. 230. For example, memory 230 may include first model 234 (which may itself include static parameter data 236) and second model 238 (which may include static parameter data 240 and/or runtime parameter data 242). obtain). Although only two models 234, 238 are depicted in FIG. 2 for purposes of illustration, in other examples, each model 234, 238 describes how software containers should be assigned to run-time environments. It can be used to generate multiple sub-machine learning models themselves that learn how different parameters of the software container indicate what. For example, in practice, the controller 110 could monitor and capture parameter data while the software container 120 was executing within its assigned runtime environment, and the controller 110 would Machine learning techniques 246 such as can be used to determine associations between this metadata to define input vectors for subsequent machine learning models. The size of the input layer can be defined by the dimensions of the input vector, and associations can be classified by monitored performance within the run-time environment. This information is used to build and train (and retrain) each model over time, weighted accordingly (e.g., removing older annotations, reinforcing newer ones, etc.). obtain.

Additionally, memory 230 may include threshold data 244 . Threshold data 244 may indicate a point at which the performance and/or cost of a software container within a runtime environment indicates that the software container should be moved to a different runtime environment. Threshold data 244 may also indicate when monitoring of the software container should stop, when the match between the software container and the runtime environment is very good, or when performance and/or cost are very stable or both. It may contain data about points.

Memory 230 may also be used by controller 110 to improve the process of determining parameters of software containers for assigning these software containers to runtime environments as discussed herein over time. machine learning techniques 246 may be included. Machine learning techniques 244 perform supervised, unsupervised, or semi-supervised training of datasets and then apply the generated algorithms or models to assign software containers. may include algorithms or models generated by Using these machine learning techniques 246, the controller 110 can improve its ability to allocate software containers over time.

Machine learning techniques 246 include decision tree learning, association rule learning, artificial neural networks, deep learning, inductive logic programming, support vector machines, clustering, Bayesian networks, reinforcement learning, representation learning, similarity/metric training. , sparse dictionary learning, genetic algorithms, rule-based learning, or other machine learning techniques or combinations thereof. Specifically, machine learning techniques 246 may use one or more of the following exemplary techniques: k-nearest neighbor (KNN), learning vector quantization (LVQ), self-organizing maps (SOM). , logistic regression, least squares regression (OLSR), linear regression, stepwise regression, multivariate adaptive regression splines (MARS), ridge regression, LASSO (least absolute shrinkage and selection operator), elastic nets, LARS (least -angle regression), Probabilistic Classifier, Naive Bayes Classifier, Binary Classifier, Linear Classifier, Hierarchical Classifier, Canonical Correlation Analysis (CCA), Factor Analysis, Independent Component Analysis (ICA), Linear Discriminant Analysis (LDA), multidimensional scaling (MDS), non-negative metric factorization (NMF), partial least squares regression (PLSR), principal component analysis (PCA), principal component regression (PCR), Sammon mapping, t-distributed stochastic neighbor embedding (t-SNE), bootstrap aggregating, harmonic mean calculation, gradient boosted decision tree (GBRT), gradient boosting machine (GBM), recursive bias algorithm, Q-learning, SARSA (state-action-reward-state-action), temporal difference (TD) learning, a priori algorithm, ECLAT (equivalence class transformation) algorithm, Gaussian process regression , gene expression programming, GMDH (group method of data handling), inductive logic programming, instance-based learning, logistic model tree, information fuzzy network (IFN), hidden Markov model, Gaussian naive Bayes, multinomial naive Bayes (multinomial naive Bayes), AODE (averaged one-dependence estimators), classification and regression trees (CART), CHAID (chi-squared automatic interaction detection), expectation maximization algorithm, feedforward neural network, logic learning Machines, Self-Organizing Maps, Single-Link Clustering, Fuzzy Clustering, Hierarchical Clustering, Boltzmann Machines, Convolutional Neural Networks, Recurrent Neural Networks, Hierarchical Temporal Memory (HTM), or others machine learning algorithms or combinations thereof.

Using these components, the controller 110 can assign software containers to runtime environments as described herein. For example, controller 110 may allocate software containers according to flowchart 300 depicted in FIG. Although flowchart 300 of FIG. 3 is discussed with respect to FIG. 1 for purposes of explanation, it is understood that in other examples, other systems may be used to implement flowchart 300 of FIG. should. Further, in some examples, the controller 110 may perform a different method than the flowchart 300 of FIG. 3, or the controller 110 may perform a similar method with more or fewer steps in a different order, etc. .

Flowchart 300 may begin with controller 110 identifying 302 static parameters for software container 120 . Controller 110 may assign software containers 120 to runtime environments 130A (or RTEs provided in flowchart 300) using the first machine learning model (304). The controller may assign software containers 120 to runtime environments 130A based on the identified static parameters.

Controller 110 may identify runtime parameters for software container 120 (306). Controller 110 may identify these runtime environments during execution of software container 120 in runtime environment 130A. In some examples, if these real-time static parameters are updated versions of the preliminary static parameters identified by controller 110 (the preliminary static parameters are those identified in step 302). static parameters), controller 110 may collect a set of real-time static parameters for software container 120 . In other words, if the static parameters are collected by the controller 110 both before the runtime to identify the initial runtime environment 130 and during a subsequent runtime, then the static parameters collected prior to the runtime are: can be classified as preliminary static parameters, and (potentially, but not necessarily) different versions of those static parameters collected during runtime are classified as real-time static parameters can be

Controller 110 may determine whether the assigned runtime environment 130A matches the identified runtime parameters (308). Controller 110 may use a second machine learning model to determine whether assigned runtime environment 130A matches the identified runtime parameters. In some examples, controller 110 may use the model to determine whether both run-time parameters and real-time static parameters match assigned run-time environment 130A. When the performance and/or cost of the software container 120 within the assigned runtime environment 130A meets one or more thresholds (e.g., has performance above the threshold and has cost below the threshold), Controller 110 may determine that runtime and/or real-time static parameters of software container 120 match assigned runtime environment 130A.

If the controller 110 determines that the model indicates that one (or both) of the parameters match the assigned run-time environment 130A, the controller 110 creates the software container 120 in the selected run-time environment 130A. may continue to execute (310). Alternatively, if controller 110 determines that there is no match as discussed herein, controller 110 is determined to have an improved match with the parameters using a second model. A software container 120 may be moved 312 to a different runtime environment 130B. Similarly, controller 110 determines that although there is no match as discussed herein, the match score is higher between software container 120 and assigned run-time environment 130A than between other run-time environments 130. If so, controller 110 may continue to run in assigned run-time environment 130A until one or more improved run-time environments 130 are discovered, brought online, created, etc., occur. A decision may be made to maintain the software container 120 .

In any event, controller 110 may collect updates over time (314). Controller 110 may collect these updates on a predetermined schedule (eg, once every 20 minutes, or once every few actions, etc.). These updates may be parameter updates/changes, performance updates, cost updates, and the like. Controller 110 may then determine whether these updates are below a threshold (316). For example, thresholds may include a threshold amount of change, or a threshold severity of change such that either the complete and final set of parameters or the complete and final performance of software container 120 are unknown. If the updates are less stringent or less numerous than the threshold (such that the software container 120 matches any runtime environment 130 to which the software container 120 is currently assigned), the controller 110 The container 120 determines that the software container 120 matches any of the runtime environments 130 currently executing in a stable manner, and subsequent analysis of the software container 120 during runtime (e.g., according to a predetermined schedule). is terminated (318). As part of stopping monitoring, controller 110 also updates both (or all, if more than two exist) machine learning models with final parameter readings, performance data, cost data, etc. can.

Alternatively, the controller 110 determines that the updates are of severity and/or number above a threshold (match is not yet satisfactory, or parameters and/or performance still appear to be in flux). , or both), the controller 110 determines whether the current runtime environment 130 matches the software container 120 or the other runtime environment 130 matches the software container 120 according to the second model. A better match, or both, may be analyzed (320). If the current runtime environment 130 matches the software container 120 as well as other runtime environments 130, the controller 110 continues executing the software container 120 in the current software environment 130 (322).

In some examples, controller 110 may determine that another runtime environment 130 is more suitable for software container 120 . In this example, controller 110 moves software container 120 to this other runtime environment 130 and causes software container 120 to run in this different runtime environment 130 (324). Regardless of whether controller 110 continues to execute software container 120 in current runtime environment 130, controller 110 continues to collect parameter update information (e.g., at 314 according to a predetermined schedule), Determine if another runtime environment 130 is matched by the software container 120 (at 320) until the controller determines (at 316) that the severity and/or number of updates collected are below a threshold. in).

cloud computing

Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementations of the teachings recited herein are not limited to cloud computing environments. Rather, embodiments of the invention may be implemented in conjunction with any other type of computing environment now known or later developed.

Cloud computing provides configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, application , virtual machines, and services) to enable convenient, on-demand network access to a shared pool. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

Characteristics are:

On-demand self-service: Cloud consumers unilaterally provision computing power, e.g., server time and network storage, as needed automatically without requiring human interaction with the provider of the service. obtain.

Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms facilitating use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs) be done.

Resource Pooling: A provider's computing resources are pooled to serve a large number of consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reassigned on demand. Consumers generally do not have control or knowledge of the exact location of the resources provided, but may be able to specify location at a higher level of abstraction (e.g., country, state, or data center). In that sense, there is a sense of position independence.

Rapid Elasticity: Capacities can be rapidly elastically provisioned, possibly automatically, to scale out quickly, and can be quickly released to scale in quickly. To consumers, the capacity available to provision often appears unlimited and can be purchased in any quantity at any time.

Measured services: Cloud systems automate resource utilization by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). control and optimize Resource usage can be monitored, controlled, and reported, providing transparency for both providers and consumers of the services utilized.

The service model is as follows:

Software as a Service (SaaS): The ability offered to consumers is to use the provider's applications running on cloud infrastructure. Applications are accessible from various client devices via thin client interfaces such as web browsers (eg, web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or individual application capabilities, with the possible exception of limited user-specific application configuration settings. .

Platform as a Service (PaaS): The ability offered to consumers is to deploy to cloud infrastructure consumer create or acquire applications created using programming languages and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but do control the deployed applications and possibly the application hosting environment configuration.

Infrastructure as a Service (IaaS): Capabilities provided to consumers are processing, storage, networking, and other fundamentals that allow consumers to deploy and run arbitrary software, which may include operating systems and applications. It is provisioning of generic computing resources. Consumers do not manage or control the underlying cloud infrastructure, but do control the operating system, storage, deployed applications, and may have limited control over select network components (e.g., host firewalls) I do.

The deployment model is as follows:

Private Cloud: A cloud infrastructure operated solely for an organization. Cloud infrastructure can be managed by an organization or a third party and can exist on-premises or off-premises.

Community cloud: A cloud infrastructure shared by several organizations to support a specific community with common concerns (eg, missions, security requirements, policies, and compliance considerations). Cloud infrastructure can be managed by an organization or a third party and can exist on-premises or off-premises.

Public cloud: A cloud infrastructure that is made available to the general public or large industry groups and owned by an organization that sells cloud services.

Hybrid cloud: The cloud infrastructure remains a unique entity, but is standardized or proprietary to enable data and application portability (e.g., cloud bursting for load balancing between clouds) is a composition of multiple clouds (private, community, or public) connected by technology.

Cloud computing environments are service oriented with an emphasis on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

Referring now to Figure 4, an exemplary cloud computing environment 50 is depicted. As shown, cloud computing environment 50 includes local computing devices used by cloud consumers, such as personal digital assistants (PDA) or cellular phones 54A, desktop computers 54B, laptop computers 54C, or automobiles. includes one or more cloud computing nodes 10 with which computer systems 54N, or combinations thereof, may communicate. Nodes 10 may communicate with each other. They may be physically or virtually grouped in one or more networks, eg, private, community, public, or hybrid clouds as described above, or combinations thereof (not shown). This enables cloud computing environment 50 to provide infrastructure, platform and/or software as a service that does not require cloud consumers to maintain resources on local computing devices. The types of computing devices 54A-N shown in FIG. 4 are intended to be exemplary only, and that computing nodes 10 and cloud computing environment 50 may have any type of network or network-addressable connection (e.g., , using a web browser), or both, with any type of computerized device.

Referring now to Figure 5, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 4) is shown. It should be foreseen that the components, layers, and functions shown in FIG. 5 are intended to be exemplary only, and that embodiments of the present invention are not so limited. As depicted, the following layers and corresponding functions are provided:

Hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframes 61, RISC (reduced instruction set computer) architecture-based servers 62, servers 63, blade servers 64, storage devices 65, and networks and network components. 66. In some embodiments, the software components include network application server software 67 and database software 68 .

The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71, virtual storage 72, virtual networks 73 including virtual private networks, virtual applications and operating systems. 74, as well as virtual clients 75;

In one example, management layer 80 may provide the functionality described below. Resource provisioning 81 provides dynamic procurement of computing and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are used within the cloud computing environment and billing or billing for consumption of those resources. In one example, these resources may include application software licenses. Security provides identity verification of cloud consumers and tasks, and protection of data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management such that required service levels are met. Planning and fulfillment of service level agreements (SLAs) 85 provides for pre-arranging and procurement of cloud computing resources in anticipation of future demand according to SLAs.

Workload tier 90 provides an example of functionality for which a cloud computing environment may be used. Examples of workloads and functions that may be provided from this layer include: mapping and navigation 91, software development and lifecycle management 92, virtual classroom teaching delivery 93, data analysis processing 94, transaction processing 95, and software. • Determining the runtime environment 96 of the container.

The description of various embodiments of the present disclosure has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Numerous modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein may be used to describe principles of the embodiments, practical applications, or technical improvements to technology found on the market, or to explain the embodiments disclosed herein to others skilled in the art. was chosen to allow the understanding of

The present invention may be a system, method, or computer program product, or combination thereof, in any level of technical detail possible. A computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to implement aspects of the present invention.

A computer-readable storage medium may be a tangible device capable of holding and storing 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 any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer readable storage media include: portable computer diskettes, hard disks, random access memory (RAM), read only memory (ROM) ), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable CD-ROM, digital versatile disk (DVD), memory stick, floppy disk Mechanically encoded devices such as discs, punched cards or raised structures in grooves on which instructions are recorded, and any suitable combination of the foregoing. As used herein, computer-readable storage media refers to transient signals themselves, e.g., radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating in waveguides or other transmission media (e.g., fiber optic cables). light pulse passing through a wire), or an electrical signal transmitted through a wire.

The computer readable program instructions described herein can be transferred to a respective computing/processing device from a computer readable storage medium or over a network such as the Internet, a local area network, a wide area network or a wireless network or combinations thereof. can be downloaded to an external computer or external storage device via A network may include copper transmission cables, optical transmission fibers, 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 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 device. do.

Computer readable program instructions for implementing the operations of the present invention include assembler instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state and status data, for integrated circuits. or in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, and procedural programming languages, e.g., the "C" programming language or similar programming languages It may be written source code or object code. The computer-readable program instructions may reside entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or on a remote computer or server. can be fully executed with In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or the connection may be an external computer (eg, 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) are computer readable to carry out aspects of the invention. Computer readable program instructions may be executed by customizing electronic circuitry using the state information of the program instructions.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams 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 and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

Instructions executing through a processor of a computer or other programmable data processing apparatus produce means for implementing the functions/acts specified in one or more blocks of the flowchart illustrations and/or block diagrams. , these computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine. A computer-readable storage medium having instructions stored thereon may comprise an article of manufacture that includes instructions for implementing aspects of the functions/activities specified in one or more blocks of the flow diagrams and/or block diagrams. Program instructions may also be stored on a computer-readable storage medium capable of directing a computer, programmable data processing device, or other device, or combination thereof, to function in a specific manner.

Computer readable program instructions also such that the instructions executing on a computer, other programmable apparatus, or other device implement the functions/acts specified in one or more blocks of the flowchart illustrations and/or block diagrams. , computer or other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to produce a computer-implemented process.

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 may represent a module, segment, or portion of instructions containing one or more executable instructions to implement the specified logical function. In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be executed concurrently, substantially contemporaneously, partially or completely in a temporally overlapping fashion to accomplish as one step; Alternatively, the blocks may sometimes be executed in reverse order, depending on the functionality involved. Each block in the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, is intended to perform a specified function or activity or implement a combination of special purpose hardware and computer instructions. Note also that it can be implemented by any hardware-based system of interest.

Claims (20)

identifying static parameters of a software container, the static parameters relating to metadata of the software container itself;
assigning the software container to a selected runtime environment based on the static parameters using a first machine learning model;
identifying run-time parameters of the software container by analyzing the software container at run-time, wherein the run-time parameters relate to operations required by the software container during run-time; identifying the run-time parameter for
continuing execution of the software container in the selected runtime environment in response to determining that the selected runtime environment matches the runtime parameters using a second machine learning model; and
Matching both the static parameter and the run-time parameter in response to determining that the selected run-time environment does not match the run-time parameter using the second machine learning model. and executing the software container in different runtime environments. monitoring performance of the software container during runtime;
updating the first machine learning model based on the performance;
2. The computer-implemented method of claim 1, further comprising: updating the second machine learning model based on the performance. 3. The computer-implemented method of claim 2, wherein the performance is monitored for at least central processing unit (CPU) usage, memory usage, and input/output (I/O) metrics. the static parameter is a preliminary static parameter, the computer-implemented method further comprising:
identifying real-time static parameters of the software container by analyzing the software container at runtime;
the selected execution in response to determining, using the second machine learning model, that the selected runtime environment matches both the real-time static parameters and the runtime parameters; continuing to run the software container in a time environment;
responsive to determining that the selected runtime environment does not match the real-time static parameters and the runtime parameters using the second machine learning model; 4. The computer-implemented method of any one of claims 1-3, comprising: executing the software container in the different runtime environment that matches both a time parameter and a time parameter. identifying one or more updates to either the real-time static parameters or the run-time parameters by analyzing the software container during the run-time, and identifying the run-time parameters according to a predetermined schedule; identifying after the
in response to determining, using the second machine learning model, that with the updated information, the selected runtime environment still matches both the real-time static parameters and the runtime parameters. , executing the software container in the selected runtime environment;
In response to determining, using the second machine learning model, that the update information does not match the selected run-time environment to the real-time static parameters and the run-time parameters, the different 5. The computer-implemented method of claim 4, further comprising: executing the software container in a runtime environment. terminating subsequent analysis of the software container during the execution time according to the predetermined schedule, in response to determining that the quantity or severity of the one or more updates is below a threshold; 6. The computer-implemented method of claim 5, further comprising: 7. The computer-implemented method of any one of claims 1-6, wherein the run-time parameter comprises a computational process of which the software container is a part. The static parameter is
the type of software container;
a template for the software container;
8. The computer-implemented method of any one of claims 1-7, comprising: the category of software containers; said run-time parameter is
the number of load balancing operations per hour; and
the number of automatic rollbacks and
the number of automatic bin-packing operations per hour;
9. The computer-implemented method of any one of claims 1-8, comprising: a number of self-healing actions per hour; a processor;
a memory in communication with the processor, comprising:
identifying static parameters of a software container, the static parameters relating to metadata of the software container itself;
assigning the software container to a selected runtime environment based on the static parameters using a first machine learning model;
identifying run-time parameters of the software container by analyzing the software container at run-time, wherein the run-time parameters relate to operations required by the software container during run-time; identifying the run-time parameter;
continuing execution of the software container in the selected runtime environment in response to determining that the selected runtime environment matches the runtime parameters using a second machine learning model; that, and
Matching both the static parameter and the run-time parameter in response to determining that the selected run-time environment does not match the run-time parameter using the second machine learning model. and said memory containing instructions that, when executed by said processor, cause said processor to execute said software container in different runtime environments. When the memory is executed by the processor,
monitoring performance of the software container during runtime;
updating the first machine learning model based on the performance;
11. The system of claim 10, comprising additional instructions that cause the processor to: update the second machine learning model based on the performance. 12. The system of claim 11, wherein the performance is monitored for at least central processing unit (CPU) usage, memory usage, and input/output (I/O) metrics. the static parameter is a spare static parameter, and the memory comprises:
identifying real-time static parameters of the software container by analyzing the software container at runtime;
the selected execution in response to determining, using the second machine learning model, that the selected runtime environment matches both the real-time static parameters and the runtime parameters; continuing to run the software container in a time environment;
responsive to determining that the selected runtime environment does not match the real-time static parameters and the runtime parameters using the second machine learning model; executing the software container in the different runtime environment that matches both a time parameter and a time parameter; The system according to item 1. the memory
identifying one or more updates to either the real-time static parameters or the run-time parameters by analyzing the software container during the run-time, and identifying the run-time parameters according to a predetermined schedule; identifying after the
in response to determining, using a second machine learning model, that the updated information still matches the selected run-time environment with both the real-time static parameters and the run-time parameters; executing the software container in the selected runtime environment;
using a second machine learning model, in response to determining from the updated information that the selected runtime environment does not match the real-time static parameters and the runtime parameters; 14. The system of claim 13, comprising additional instructions that, when executed by the processor, cause the processor to: execute the software container in a time environment. the memory, when executed by the processor, in response to determining that the quantity or severity of the one or more updates is below a threshold; 15. The system of claim 14, comprising additional instructions that cause the processor to finish subsequent analysis of the container. A computer program product comprising a computer-readable storage medium with program instructions embodied thereon, said program instructions for:
identifying static parameters of a runtime environment of a software container, the static parameters relating to metadata of the software container itself;
assigning the software containers to selected runtime environments based on the static parameters using a first machine learning model;
identifying run-time parameters of the software container by analyzing the software container at run-time, wherein the run-time parameters relate to operations required by the software container during run-time; identifying the run-time parameter for
continuing execution of the software container in the selected runtime environment in response to determining that the selected runtime environment matches the runtime parameters using a second machine learning model; and
Match both the static parameter and the run-time parameter in response to determining that the selected run-time environment does not match the run-time parameter using a second machine learning model. A computer program product executable by said computer to cause said computer to: run said software container in a different runtime environment. The computer-readable storage medium is
monitoring the performance of the software container during runtime to the computer when executed by the computer;
updating the first machine learning model based on the performance;
17. The computer program product of claim 16, comprising additional program instructions to: update the second machine learning model based on the performance; 18. The computer program product of claim 17, wherein the performance is monitored for at least central processing unit (CPU) usage, memory usage, and input/output (I/O) metrics. wherein the static parameter is a preliminary static parameter, and the computer-readable storage medium comprises:
identifying real-time static parameters of the software container by analyzing the software container prior to the execution time;
the selected runtime in response to determining, using a second machine learning model, that the selected runtime environment matches both the real-time static parameter and the runtime parameter; continuing to run the software container in an environment;
the software in the different runtime environment in response to determining that the selected runtime environment does not match the real-time static parameters and the runtime parameters using a second machine learning model; 19. A computer program product according to any one of claims 16 to 18, comprising additional program instructions which, when executed by said computer, cause said computer to: - run a container. The computer-readable storage medium is
one or more updates to either the real-time static parameters or the run-time parameters by analyzing the software container during the run-time, after the identifying the run-time parameters; and identifying according to a predetermined schedule;
in response to determining, using a second machine learning model, that the updated information still matches the selected run-time environment with both the real-time static parameters and the run-time parameters; continuing to run the software container in the selected runtime environment;
using a second machine learning model, in response to determining from the updated information that the selected runtime environment does not match the real-time static parameters and the runtime parameters; 20. The computer program product of claim 19, comprising additional program instructions that, when executed by the computer, cause the computer to: execute the software container in a time environment.

Images