Automated change management methods, systems, media, and procedures for container applications

Abstract

This application relates to the field of data processing technology. It provides a method, system, media, and program product for automated change management of container applications. The method includes: defining standard steps required during the automated change process, and covering the operations during the container application change process through different combinations of steps in the standard steps; importing a control table, the control table including information required to change one or more services; grouping and orchestrating, arranging step lists for the one or more services based on the standard steps, the step lists indicating the steps and parameters required to change the corresponding services; and invoking a service of the container platform, pushing the step lists to the container platform to begin automated change management of the container application. This application improves execution efficiency and reduces labor costs.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an automated change method, system, media, and program product based on container applications. Background Technology

[0002] In today's era of rapid information technology development, people's lives are increasingly inseparable from the internet and electronic devices, making life more and more convenient. However, behind this convenience lies a vast number of software systems providing services. For large commercial banks, the systems running in production encompass tens of thousands of systems of varying sizes, from core functions like transactions, accounting, personal loans, and investment management, to portal management, human resources, and daily office work and development management. The vast majority of these software systems need to be deployed and run in production. Due to the unique nature of the banking industry's production environment, interoperability between the testing and production environments of dedicated software systems is strictly limited, while system deployment requires deploying code compiled in the testing environment to the production environment.

[0003] With container technology gaining widespread attention in the industry, there is ample evidence that it can significantly improve the efficiency of software deployment. Virtualization technology has become a widely accepted method for sharing server resources, providing system administrators with great flexibility in building operating system instances on demand. System deployment is no longer limited to simple files; there is also a growing demand for container images. With the rapid development of cloud-native technologies, containerized applications are becoming increasingly common. Currently, many container applications are deployed based on Kubernetes or products developed using Kubernetes, which offer powerful but complex user interfaces. In actual production deployments, common problems include error-prone operations and long deployment times. Summary of the Invention

[0004] This application provides an automated change method, system, media, and program product based on container applications to solve the aforementioned problems of error-proneness and long processing time.

[0005] Firstly, this application provides an automated change method for containerized applications, including:

[0006] Define the standard steps required for the automated change process, and cover the operations in the container application change process by different combinations of the steps in the standard steps;

[0007] Import the control table, which includes information required to change one or more services;

[0008] Grouping and orchestrating: Based on the standard steps, a list of steps is arranged for each of the one or more services, the list of steps indicating the steps and parameters required to change the corresponding service;

[0009] Invoke the container platform's services and push the list of steps to the container platform to begin automated changes to container applications.

[0010] The methods described above also include: change notifications, used to send the results of the current changes to the target audience.

[0011] The standard steps in the above method include:

[0012] ①Version Acquisition: The specified path for the container image used to pull files from the production version machine;

[0013] ② Import configuration, used to pull configuration files from the production version machine and load them into the container platform;

[0014] ③ Before stopping the service - execute the script, which is used to execute the user-defined script;

[0015] ④ Stop Service: Used to stop the current container service;

[0016] ⑤ Create / modify services: Create or modify services based on the configuration file;

[0017] ⑥ Rolling upgrade, used to perform rolling upgrades on the container image;

[0018] ⑦ Start Service, used to start the container service;

[0019] ⑧ Dynamic scaling is used to specify a new corresponding number of instances for a service;

[0020] ⑨ After starting the service - execute the script, which is used to execute user-defined scripts;

[0021] ⑩ Version check, used to check the version of container images;

[0022] Green light testing is used to execute user-defined green light test scripts within the container;

[0023] Health checks are used to execute user-defined health test scripts within the container.

[0024] In the above method, the grouping and orchestration step further includes: specifying that the one or more services are executed in parallel or serially.

[0025] In the above method, the grouping and orchestration step further includes: specifying that one or more services be executed at regular intervals.

[0026] In the above method, when there are multiple services executing in parallel among the one or more services: it is determined whether the change of the first service in the first parallel service should logically follow the change of the second service in the second parallel service. If so, the first service is made to wait for execution until the second service completes the automatic change.

[0027] Secondly, this application provides an automated change management system based on container applications, comprising:

[0028] The control table import module is used to import control tables, which include information required to change one or more services;

[0029] The grouping and orchestration module orchestrates a list of steps for the one or more services based on the standard steps. The list of steps indicates the steps and parameters required to change the corresponding service.

[0030] A container platform interface is used to push the list of steps to the container platform to initiate automated changes to container applications.

[0031] The system described above also includes a change notification module, which sends the results of the current changes to the target population.

[0032] The system described above also includes a pre-dependency module, which provides the dependencies between the one or more services.

[0033] The system described above also includes:

[0034] The parallel execution module is used to execute services that do not have the aforementioned dependencies on each other in parallel.

[0035] A serial execution module is used to execute services that have the aforementioned dependencies on each other in a serial manner.

[0036] The system described above also includes an execution waiting module, which, when one or more services simultaneously involve services executed in parallel and services executed serially, performs the following:

[0037] Determine whether the change to the first service depends on the second service. If so, instruct the first service to wait for execution until the second service completes the automated change.

[0038] Thirdly, this application also provides an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the system described above.

[0039] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the system described above.

[0040] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the system described above.

[0041] Compared to existing technologies, this application breaks down the modification process of container applications into several specific steps. When users need to implement container applications, they can select one or more or even all of these steps according to the actual operation required. By combining these steps, the possibility of misoperation can be reduced, the operation process is relatively simple, execution efficiency is greatly improved, and a large amount of labor costs are reduced. Attached Figure Description

[0042] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0043] Figure 1 This is an application scenario diagram of the container automated change method proposed according to some embodiments of this application;

[0044] Figure 1a for Figure 1 A schematic diagram of the development process in the development environment;

[0045] Figure 2 A flowchart illustrating the basic process of container modification is shown.

[0046] Figure 3 This is a flowchart of a container automation modification method proposed according to some embodiments of this application;

[0047] Figure 4 According to Figure 3 The flowchart shown is a schematic diagram illustrating the arrangement of the execution order of multiple change services.

[0048] Figure 5 This is a block diagram of an automated container change system proposed according to some embodiments of this application;

[0049] Figure 6 This is a schematic diagram of the hardware structure of an electronic device proposed according to some embodiments of this application.

[0050] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0051] The following specific embodiments illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Although the description of this application will be presented in conjunction with preferred embodiments, this does not mean that the features of this invention are limited to this embodiment. On the contrary, the purpose of describing the invention in conjunction with embodiments is to cover other options or modifications that may be derived based on the claims of this application. To provide a thorough understanding of this application, many specific details will be included in the following description. This application may also be implemented without using these details. Furthermore, to avoid confusion or obscuring the focus of this application, some specific details will be omitted in the description. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0052] It should be noted that in this specification, similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures, and is assumed to be the same definition.

[0053] It should also be stated that the methods and processes in this application are numbered for ease of reference, not to restrict the order of steps. If there is a sequence between the steps, the textual description shall prevail.

[0054] Terminology Explanation:

[0055] Testing environment: Used daily by development and testing personnel, primarily for requirement development, testing, and bug debugging. System access permissions are low and control is not strict.

[0056] Production environment: This refers to the environment in which the software system is deployed to provide services to users, including the system's operating environment and real user data. System service access is very restricted, especially in the financial sector where multi-level authorization is often required.

[0057] Container technology: This technology effectively divides the resources of a single operating system into isolated groups in order to better balance conflicting resource usage demands among these isolated groups.

[0058] Container image: An image is a unified view of a read-only layer, which can be understood as a production version of a container technology package.

[0059] Image repository: A specific service used to store container images, which can store and retrieve container images.

[0060] K8s: Kubernetes, also known as K8s or Kube, is Google's most popular container orchestrator in the industry, used to manage containerized applications on multiple hosts in a cloud platform.

[0061] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0062] Figure 1 This diagram illustrates an application scenario of the container automation change method proposed according to some embodiments of this application. As shown, a software product goes through three stages from development to formal deployment (production): development, testing, and production. To ensure production security, these three stages are physically isolated, and the transfer of related files and software from the development environment to the testing environment and from the testing environment to the production environment needs to be done through dedicated channels.

[0063] In the development environment, developers base their work on, for example... Figure 1a The development process diagram illustrates a cyclical process of requirements gathering, development, testing, and requirements adjustment for software development. Once development is complete and a deliverable version of the program is available, the developers build a container image and associated files, submit a request for image changes to the container platform (for testing), such as Kubernetes, and transfer the developed software and related files, such as configuration files, through a dedicated channel.

[0064] In the testing environment, testers receive container images and accompanying files through the testing system and store them in the container platform (for testing). Here, the accompanying files can be configuration files and YAML files that accompany the container image. The container changes described above can involve a portion of a large software application's business systems. When a partial update to this large software application is needed, the container image and accompanying files received in the container platform correspond to that specific business system, eliminating the need to update the entire software, thus improving the efficiency of container changes.

[0065] In the test environment, testers perform various tests on the container images and their associated files. Firstly, since the container images and associated files may have been delivered separately previously, testers can associate the container images stored in the image repository with the associated files stored on the file server to facilitate testing. This association can be achieved by associating the container images and associated files to be used in this production deployment within the version plan.

[0066] Then, testers can test the container image and its accompanying files. These tests include user testing, non-functional testing, security testing, and installation testing. User testing primarily verifies whether the production-ready functionality meets user requirements; non-functional testing checks for performance issues and compliance with operational guidelines; security testing checks for security vulnerabilities; and installation testing ensures the target container application can be successfully deployed in the production environment by installing and deploying it in a test environment.

[0067] Optionally, testers can also use the testing system to package the supporting files (or the revised supporting files) into a version package file, such as a zip file or a tgz file, to facilitate the transfer of the supporting files, reduce the amount of data transferred, and improve the transfer efficiency and success rate of the supporting files.

[0068] When there is a need to change or deploy a container, the testing system will send the aforementioned version package files and container images to the file server and image repository in the production environment, respectively. Once the testers have successfully tested the container image and its accompanying files, it indicates that the installation and deployment can be smoothly implemented in the production environment. At this point, the testing system in the testing environment can automatically transfer the container image from the image repository to be deployed, the accompanying files from the test file server, and the deployment-related information of the target container application to the production environment.

[0069] In the production environment, the agile deployment process obtains supporting information (files) such as the transfer of development and operations permissions, image version information, and container change process from the test environment through a dedicated channel, and transmits this information (files) to the container application automated change system disclosed in this application through linkage implementation. The container application automated change system arranges the 12 standard steps proposed in this application based on the imported control table to realize the change operations required in the control table.

[0070] It's worth noting that the aforementioned orchestration can be completed before implementing (or starting) automatic changes to the container application. That is, it can be pre-orchestrated, unlike existing technologies where the required operations and parameters are manually searched and specified item by item during the implementation of container reference changes. Furthermore, the pre-orchestrated content can be reviewed, ensuring that various parameters and requirements are met through multiple rounds of manual verification.

[0071] After orchestrating the automated change process, it can be set to execute directly or on a schedule. When the change process actually begins, it can automatically deploy one or more container images based on the pre-arranged content, requiring no manual intervention. Compared to existing technologies, the container application automated change system proposed in this application can eliminate errors during container changes and efficiently complete the process.

[0072] Figure 2 This diagram illustrates the basic process of container changes from another perspective. As shown, developers can deliver container images and supporting files through the development and testing pipeline. After receiving the container image and supporting files, the testing system transfers the container image to the production image repository and the supporting files to the test file server. After associating the container image in the production image repository with the supporting files in the test file server, testers will test the container image and supporting files. Upon completion of the test, test information will be obtained. After the container image and supporting files pass the test, the testing system will synchronize the container image in the production image repository to the production image repository, synchronize the supporting files in the test file server to the production file server, and synchronize the production-related information of the target container application (including test information and required change operations) to the production environment. After the container deployment system in the production environment obtains the production-related information, it will generate a change order based on the production-related information. Approval personnel will then review the generated change order according to the approval process to obtain an approval result indicating whether to implement the deployment. If the approval result indicates that deployment should be implemented, the container deployment system will call the container platform's interface based on the change operation and deploy the target container application according to the container image and supporting files.

[0073] exist Figure 2 As shown in the process, an essential step in building a software image is obtaining its dependency information. During operation, software may call other operating systems, software packages, databases, and configuration information. These relationships are called dependencies and need to be determined before building the image; otherwise, errors are likely to occur during the image building process, reducing efficiency. Currently, developers manually analyze application software dependencies and then write them into supporting files, such as Dockerfiles. However, manually writing Dockerfiles for packaging is tedious, requires a high level of technical expertise, and it's difficult to cover all the prerequisites for packaging (i.e., establishing dependencies).

[0074] Therefore, one concept of this application is to pre-program the operations that can change container applications before actually initiating the change process, and then automate their execution directly during the production change process. This not only improves the efficiency of the change process but also avoids operational errors.

[0075] like Figure 3 As shown, this application discloses a flowchart of a container automated change method.

[0076] S31, Define Standard Steps. Define the standard steps required in the automated change process, covering the operations in the container application change process through different combinations of steps in the standard steps. The standard steps are atomic operations summarized from various operations performed in existing manual change processes. Subsequent steps restore the operations required for corresponding manual changes by combining several standard steps, or more accurately, restore the effects achieved through manual changes in existing technologies.

[0077] Based on the scope that banking operations may involve, this invention first defines a series of standard steps. By arranging and combining these standard steps, all container changes within the scope of banking operations can be achieved.

[0078] Specifically, in one embodiment of this application, the following 12 standard steps are defined:

[0079] ① Version retrieval: This is used to pull the container image (referring to software files) from the production version machine to a specified path. In other words, it retrieves the container image of the specified version, not the file version information.

[0080] ② Import Configuration: This function pulls configuration files from the production machine and loads them into the container platform. It supports both full and incremental configuration. The configuration file can be an Excel template file.

[0081] ③ Before stopping the service - execute the script, which is used to execute the user-defined script. An interface is reserved for users' personalized needs, allowing users to write their own logic.

[0082] ④ Stop Service: Used to stop the current container service.

[0083] ⑤ Create / modify services: Create or modify services based on the configuration file.

[0084] ⑥ Rolling upgrade, used to perform rolling upgrades on the container image. This can include parameters, primarily: container name, image name, and image version number. These parameters can be manually entered by the user or imported from a configuration file specified in the control table. The parameters stored in the configuration file can be the result of multiple checks, including proposal, verification, and review. This allows for proactive risk management; during non-container deployment periods, parameters can be selected with less pressure, and auditors can be involved to manually check and eliminate potential errors.

[0085] ⑦ Start the service, used to start the container service.

[0086] ⑧ Dynamic scaling is used to specify a new number of corresponding instances for a service.

[0087] ⑨ After starting the service, execute scripts. This is used to execute user-defined scripts. By executing / stopping user-defined scripts, operations that cannot be covered by the standard procedures can be effectively supplemented.

[0088] ⑩ Version check: Used to check the version of container images. It confirms the version of the image currently being used and can be used to check whether the object being operated on is correct, whether the updated image is the target image, and other version-related information.

[0089] Green light testing is used to execute user-defined green light test scripts within the container.

[0090] Health checks are used to execute user-defined health test scripts within the container.

[0091] S32, Import the control table, which includes information required to change one or more services. For example, the source location (container name) and target location, name, and version of the image file, as well as configuration files, dependency files, etc. The control table mainly provides the storage location of each file, rather than the files themselves.

[0092] S33, Grouping and Arranging: Based on the standard steps, arrange a list of steps for each of the one or more services, the list of steps indicating the steps and parameters required to change the corresponding service.

[0093] The execution of multiple services may have a logical order. For example, a change to service A may depend on a change to service B, meaning that a change to service A depends on service B.

[0094] The following is for reference Figure 4 Further explanation. Figure 4 According to Figure 3 The flowchart shown illustrates the arrangement of the execution order of multiple change services. As shown, services 1, 2, and 3 form a group of services that need to be executed sequentially, while service 4 can be executed in parallel with group 1. That is, services within group 1 are executed sequentially, while groups 1 and 2 are executed in parallel.

[0095] In the grouping and orchestration step, services are grouped based on their dependencies. Services that need to be executed sequentially are assigned to a group (e.g., a sequential queue). Figure 4Group 1 is a sequential execution group. Services 1 through 3 in Group 1 are dependent on each other. Executing Service 2 requires executing Service 1 first, and executing Service 3 requires executing Service 2 first. Therefore, Group 1 is a sequential execution group, with Services 1 through 3 executed in order.

[0096] Services that do not depend on each other can be assigned to two groups, such as Figure 4 As shown in Group 1 and Group 2, Service 4 can be changed independently without depending on any of Services 1-Service 3. Group 1 and Group 2 are two groups that execute in parallel.

[0097] In addition, the grouping and arrangement process also includes a waiting step. (See also: [link to relevant documentation]). Figure 4 Group 1 and Group 2 are two groups of services that execute in parallel. Service 3 is in Group 1, and service 4 is in Group 2. Service 4 is a service that has no dependency on service 3. However, it is only meaningful for service 4 to start executing after service 3 has completed. That is, logically speaking, service 4 should only be executed after service 3 has finished executing or after service 3 outputs a certain signal. Therefore, service 4 is scheduled to wait for a certain triggering condition (such as service 3 finishing executing) before it starts executing.

[0098] Secondly, in the grouping and orchestration process, one or more services may need to be executed repeatedly or periodically. For example, Figure 4 If Service 3 in the container may need to perform its own health checks periodically, then during orchestration, Service 3 should be specified to execute user-defined health test scripts within the container at preset intervals.

[0099] The grouping and orchestration process may also include specifying the start time for the deployment of one or more services, which may also be set based on a control table.

[0100] S34, invoke the container platform's service to push the list of steps to the container platform to begin automated changes to the container application.

[0101] S35, Change Notification, is used to send the results of current changes to the target audience.

[0102] The above description outlines 12 standard steps defined based on the specific application scenario of banking. These steps are executed sequentially, following the indicated number order. Users can choose whether to execute a specific step, but the relative relationships between the steps cannot be altered. That is, if a user selects the version retrieval step, it will be the first step executed; if a user selects steps 1, 6, 9, or 10 of the 12 standard steps, the execution order must be 1-6-9-10, not 1-9-10-6.

[0103] In other specific application scenarios, through analysis and experimentation by R&D personnel, the standardized steps may be defined as 10 or 20; or the relative execution order between the standard steps may not be defined. These should all fall within the scope of protection sought by this application.

[0104] Figure 5 This is a block diagram of an automated container change system proposed according to some embodiments of this application. The automated change system 500 includes: a control table import module 501, a grouping and orchestration module 502, a maintenance period setting module 503, a change notification module 504, a container platform interface 505, a prerequisite dependency module 506, a parallel execution module 507, a serial execution module 508, and an execution waiting module 509.

[0105] The control table import module 501 is used to import control tables, which include information required to change one or more services.

[0106] The group orchestration module 502 orchestrates a list of steps for each of the one or more services based on the standard steps. This list indicates the steps and parameters required to change the corresponding service. For a complete description of its orchestration process, please refer to the documentation. Figure 3 and Figure 4 Explanation.

[0107] The maintenance period setting module 503 is used to configure periodic service changes and trigger service changes based on the set time period.

[0108] The change notification module 504 sends the current change result to the target group, such as the user who proposed the change. There are various ways to send the notification, such as SMS, email, telephone, fax, etc., including displaying a prompt message on the user interface.

[0109] The container platform interface 505 is used to push the list of steps to the container platform to initiate automated changes to container applications.

[0110] The pre-dependency module 506 provides the dependencies between the one or more services, which serve as the basis for the grouping and orchestration module 502 to orchestrate the specific steps of multiple services.

[0111] The parallel execution module 507 and the serial execution module 508 are respectively used to execute services that have no dependency relationship with each other in parallel and to execute services that have a dependency relationship with each other in serial order.

[0112] When the execution waiting module 509 determines whether the change of the first service depends on the second service in the case that there are services that are executed in parallel and services that are executed serially in one or more services, if so, the first service is made to wait for execution, or to pause execution, until the second service completes the automatic change before the change of the first service is started.

[0113] The aforementioned automated change management system 500, based on predefined standard procedures, imports image files and various supporting files through the control table import module 501. These supporting files include all the parameters and information required to execute the change. The group orchestration module 502 then orchestrates how the services specified in the control table should execute the change based on these supporting files, including how and when to execute it. All parameters and information needed during the orchestration process are obtained from the supporting files, requiring no manual intervention throughout. Human intervention is only required when the change is actually executed, thus avoiding operational errors during the change process, improving execution efficiency, and reducing labor costs.

[0114] The electronic device provided in this application embodiment can be the terminal device described in the above embodiments. Figure 6 A schematic diagram of the basic hardware structure of the electronic device is shown.

[0115] like Figure 6 As shown, the electronic device 100 includes at least a main processor 101 and a storage medium 103. Depending on the actual usage requirements, the electronic device 100 may also include a coprocessor 102, an I / O unit 104, a network communication unit 105, and some other expansion units 106. The selectivity of the coprocessor 102, I / O unit 104, network communication unit 105, and other expansion units 106 is shown by dashed lines in the figure.

[0116] The main processor 101 and / or coprocessor 102 execute computer instructions stored in the storage medium 103 to implement the method proposed in this application. The main processor 101 is the control center of the electronic device 100, typically a general-purpose processor (e.g., Intel CPUs from various series), capable of performing a relatively balanced logical processing and arithmetic calculations. The main processor 101 connects to various parts of the electronic device 100 using various interfaces, and implements various functions of the electronic device 100 by running or executing software programs stored in the storage medium 103 and calling data stored in the storage medium 103, thereby providing overall monitoring of the electronic device 100.

[0117] The coprocessor 102 is typically a dedicated processor (e.g., a user-programmable embedded microprocessor) used to implement a single function. For example, the coprocessor 102 could be a graphics processing unit (GPU), dedicated to processing graphics and images. The main processor 101 does not directly process information related to graphics and images at this time, but instead provides data from other units to the coprocessor 102 or sends management instructions to the coprocessor 102 to instruct it to retrieve data from other units. After the coprocessor 102 processes the data, the main processor 101 receives the processing result from the coprocessor 102 so that it can make other decisions based on the processing result. For different professional fields, the coprocessor 102 can also be a signal processor, network communication processor, complex computing processor, etc. Typically, the hardware implementation of the coprocessor 102 is based on a digital signal processing (DSP) chip, or an application-specific integrated circuit (ASIC) such as a complex programmable logic device (CPLD) or a field-programmable gate array (FPGA).

[0118] Storage medium 103 may include internal and external memory, or it may include volatile and non-volatile memory, or it may include magnetic storage devices, solid-state memory, flash memory, floppy disks, and hard disks, etc. Storage medium 103 can be used to store an operating system (e.g., which may be executed by the main processor 101) and data generated by the operating system during operation, application software programs and data generated by the application software during operation, and software programs of dedicated modules (e.g., which may be executed by a coprocessor 102) and data generated by the program during operation. For example, in one embodiment of this application, the main processor 101 executes various functional applications and data processing by running a monitoring program stored in storage medium 103. In some embodiments, storage medium 103 may also be a remote memory (as opposed to a conventional memory) remotely located relative to the main processor 101, and these remote memories can be connected to the main processor 101 or a coprocessor 102 via a network connection (e.g., via a network communication device 105). Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0119] The I / O (Input / Output) unit 104 includes information input devices and information output devices, enabling users to interact with the electronic device 100. Input devices can be used to receive input numerical or character information, and may specifically include: a keyboard, mouse, joystick, touch input device, or trackball, etc. Output devices can be used to output / display the processing results processed by the electronic device 100, which may be based on the information input from the input devices. Specifically, output devices may include: a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc.

[0120] The network communication unit 105 enables communication between the electronic device 100 and various remote devices via a wired / wireless network connection, thereby allowing the electronic device 100 to exchange data with remote devices (e.g., the remote storage device described above). Alternatively, the electronic device 100 can also connect to other electronic devices (e.g., electronic devices with client software installed) via the network communication unit 105, enabling the electronic device 100 to interact with other electronic devices as part of a larger system.

[0121] Other expansion units 106 include various peripheral components and their interfaces, enabling electronic device 100 to interact with various devices. For example, via a Bluetooth interface, it can connect to a Bluetooth headset, allowing audio played by electronic device 100 to be received by the Bluetooth headset. Alternatively, via a bus interface (e.g., RS-485 bus), electronic device 100 can connect to sensors to obtain monitoring data to assist in achieving specific functions. In various embodiments, other expansion interfaces 106 can exist independently or be integrated with other components of electronic device 100. Furthermore, other expansion interfaces 106 are optional, and their optionality is indicated by dashed lines in the figures.

[0122] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the task scheduling method described in the above embodiments.

[0123] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the task scheduling method in the above embodiments.

[0124] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0125] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. An automated change management method for containerized applications, characterized in that, include: Define the standard steps required for automated change processes, and cover the operations in the container application change process through different combinations of the steps in the standard steps. The standard steps include: 1) Version Acquisition: The specified path for the container image used to pull files from the production version machine; 2) Import configuration, used to pull configuration files from the production version machine and load them into the container platform; 3) Before stopping the service - execute the script, which is used to execute the user-defined script; 4) Stop Service: Used to stop the current container service; 5) Create / modify services: Create or modify services based on the configuration file; 6) Rolling upgrade, used to perform rolling upgrades on the container image; 7) Start the service, used to start the container service; 8) Dynamic scaling, used to specify a new corresponding number of instances for a service; 9) After starting the service, execute the script, which is used to execute user-defined scripts. 10) Version check, used to check the version of the container image; 11) Green light test, used to execute user-defined green light test scripts within the container; 12) Health checks, used to execute user-defined health test scripts within the container; Import the control table, which includes information required to change one or more services; Grouping and orchestrating: Based on the standard steps, a list of steps is arranged for each of the one or more services, the list of steps indicating the steps and parameters required to change the corresponding service; Invoke the container platform's services and push the list of steps to the container platform to begin automated changes to container applications.

2. The method according to claim 1, characterized in that, Also includes: Change notifications are used to send the results of current changes to the target audience.

3. The method according to claim 1, characterized in that, The grouping and orchestration step further includes: specifying that one or more services be executed in parallel or serially.

4. The method according to claim 1, characterized in that, The grouping and orchestration step further includes: specifying that one or more services be executed at regular intervals.

5. The method according to claim 3, characterized in that, In the case where multiple services are executed in parallel within one or more of the aforementioned services: Determine whether the change to the first service in the first parallel execution service should logically follow that of the second service in the second parallel execution service. If so, instruct the first service to wait for execution until the second service completes the automatic change.

6. An automated change management system based on container applications, characterized in that, An automated change management method for container-based applications as described in any one of claims 1-5, comprising: The control table import module is used to import control tables, which include information required to change one or more services; The grouping and orchestration module orchestrates a list of steps for the one or more services based on the standard steps. The list of steps indicates the steps and parameters required to change the corresponding service. A container platform interface is used to push the list of steps to the container platform to initiate automated changes to container applications.

7. The system according to claim 6, characterized in that, It also includes a change notification module, which sends the results of the current changes to the target audience.

8. The system according to claim 6, characterized in that, It also includes a pre-dependency module, which provides the dependencies between the one or more services.

9. The system according to claim 8, characterized in that, Also includes: The parallel execution module is used to execute services that do not have the aforementioned dependencies on each other in parallel. A serial execution module is used to execute services that have the aforementioned dependencies on each other in a serial manner.

10. The system according to claim 9, characterized in that, It also includes an execution waiting module, which, when there are both services executing in parallel and services executing serially among the one or more services, performs the following: Determine whether the change to the first service depends on the second service. If so, instruct the first service to wait for execution until the second service completes the automated change.

11. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-5.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-5.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-5.

Images