Cloud native product management system and method

Abstract

The invention relates to a cloud native product management system and method, and the system comprises an interface layer which is used for receiving a product management request submitted by a user, the product management request comprises target node information, a product file and management configuration information, and the type of the product management request comprises a product deployment request or a product unloading request; the service layer is in communication connection with the interface layer and is used for analyzing the product management request to generate a product management task, and the type of the product management task comprises a product deployment task or a product unloading task; the Playbook generation layer is in communication connection with the service layer and is used for dynamically generating an Ansible Playbook script corresponding to the product management task based on a builder mode; and the Ansible integration layer is respectively in communication connection with the service layer and the Playbook generation layer, and is used for executing the Ansible Playbook script according to a control instruction of the service layer so as to manage the product on a target node. Based on the scheme, automatic deployment of the product can be realized.

Description

Technical Field

[0001] This application relates to the technical field of cloud-native application deployment, and in particular to a management system and method for cloud-native artifacts. Background Technology

[0002] Currently, cloud-native platforms based on Kubernetes typically use containerization to deploy and manage artifacts, mainly relying on technologies such as Docker images and Helm Charts for packaging, distribution, and deployment.

[0003] However, existing artifact deployment systems typically only handle artifacts of specific formats (such as Docker images), lacking a unified management mechanism for diverse artifact types such as traditional application artifacts and binary files. Furthermore, traditional artifact deployment methods often rely on manual operations, making it difficult to achieve consistent deployment and unified management in multi-node and multi-environment deployment scenarios. Summary of the Invention

[0004] In view of the above-mentioned problems of the prior art, this application provides a management system and method for cloud-native artifacts, which supports the deployment of diverse artifact types and can realize the automated deployment of artifacts.

[0005] To achieve the above objectives, the first aspect of this application provides an artifact management system for a cloud-native platform, comprising: an interface layer for receiving artifact management requests submitted by users, wherein the artifact management request includes target node information, artifact files, and management configuration information, and the type of the artifact management request includes an artifact deployment request or an artifact uninstallation request; a service layer, communicatively connected to the interface layer, for parsing the artifact management request to generate artifact management tasks, wherein the type of the artifact management task includes an artifact deployment task or an artifact uninstallation task; a Playbook generation layer, communicatively connected to the service layer, for dynamically generating Ansible Playbook scripts corresponding to the artifact management tasks based on the builder pattern; and an Ansible integration layer, communicatively connected to both the service layer and the Playbook generation layer, for executing the Ansible Playbook scripts according to the control instructions of the service layer to manage the artifacts on the target node.

[0006] Therefore, the artifact management system provided in this embodiment supports the automatic management of artifacts in various formats, eliminating the need to develop different deployment scripts and management tools for artifacts of different formats, thus reducing system complexity. Furthermore, after a user submits an artifact management request, the system can automatically generate and execute the corresponding Ansible Playbook script, thereby achieving automatic deployment or uninstallation of artifacts across multiple nodes.

[0007] As one implementation of the first aspect, the Playbook generation layer includes: a Playbook builder, used to call a corresponding playbook template according to the type of the artifact management task; a deployment playbook template, used to define the artifact deployment process; the deployment playbook template, in response to the call of the Playbook builder, generates an Ansible Playbook script for artifact deployment by calling one or more pre-packaged Ansible functional modules and based on the management configuration information; an uninstallation playbook template, used to define the artifact uninstallation process; the uninstallation playbook template, in response to the call of the Playbook builder, generates an Ansible Playbook script for artifact uninstallation by calling one or more pre-packaged Ansible functional modules and based on the management configuration information; and an Ansible wrapper module, pre-packaged with multiple Ansible functional modules; the deployment playbook template calls one or more pre-packaged Ansible functional modules in the Ansible wrapper module to generate an Ansible Playbook script for artifact deployment; the uninstallation playbook template calls one or more pre-packaged Ansible functional modules in the Ansible wrapper module to generate an Ansible Playbook script for artifact uninstallation.

[0008] As shown above, the Playbook generation layer can automatically generate Ansible Playbook scripts based on management configuration information.

[0009] As one implementation of the first aspect, the pre-packaged Ansible functional module includes at least one of the following: a system management module, used to control the process of the artifact management task through the systemd service; a copy module, used to copy the artifact file to the target node according to the target node information; a decompression module, used to decompress the artifact file on the target node; and a Shell module, used to execute arbitrary Shell commands on the target node, wherein the Shell commands include functions not covered by the pre-packaged Ansible functional module.

[0010] In summary, by pre-encapsulating commonly used functions and retaining an extensible Shell module, the system is simplified while its extensibility is enhanced.

[0011] As one implementation of the first aspect, the Ansible integration layer includes: a task dispatcher, a task queue, a work pool, a task executor, and an Ansible-Runner execution engine; the task dispatcher is used to receive the artifact management tasks from the service layer and store the artifact management tasks in the task queue; the task queue is used to receive and cache the artifact management tasks from the task dispatcher; the work pool is used to monitor the status of the task queue and the task executor, retrieve the artifact management tasks from the task queue according to the scheduling order, and assign them to currently idle task executors; the task executor is used to drive the Ansible-Runner execution engine to run the Ansible Playbook script corresponding to the artifact management task, so as to manage the artifact on the target node.

[0012] As described above, through the cooperation of the various modules in the Ansible integration layer, AnsiblePlaybook scripts can be executed automatically and systematically to automatically deploy or uninstall artifacts.

[0013] As one implementation of the first aspect, it further includes: a data layer, which is communicatively connected to the service layer, for storing target node information in the artifact management task into a target node record table, and for storing artifact files and management configuration information in the artifact management task into an artifact management table; the data layer is also communicatively connected to the Ansible integration layer, for monitoring the execution logs and execution results of the Ansible Playbook script, and storing the execution logs and execution results into an artifact running table, wherein the execution results include execution success information or execution error information.

[0014] A second aspect of this application provides a method for artifact management on a cloud-native platform, comprising: receiving an artifact management request submitted by a user, the artifact management request including target node information, artifact files, and management configuration information, the type of the artifact management request including an artifact deployment request or an artifact uninstallation request; parsing the artifact management request to generate an artifact management task, the type of the artifact management task including an artifact deployment task or an artifact uninstallation task; dynamically generating an Ansible Playbook script corresponding to the artifact management task based on the builder pattern; and executing the Ansible Playbook script to manage the artifact on the target node.

[0015] As one implementation of the second aspect, the dynamic generation of Ansible Playbook scripts corresponding to the artifact management tasks based on the builder pattern includes: calling corresponding playbook templates according to the type of the artifact management task, wherein the playbook templates include deployment playbook templates and uninstallation playbook templates; the deployment playbook template generates an Ansible Playbook script for artifact deployment by calling one or more pre-encapsulated Ansible functional modules and based on the management configuration information; wherein the deployment playbook template defines the artifact deployment process; the uninstallation playbook template generates an Ansible Playbook script for artifact uninstallation by calling one or more pre-encapsulated Ansible functional modules and based on the management configuration information; wherein the uninstallation playbook template defines the artifact uninstallation process.

[0016] As one implementation of the second aspect, the execution of the Ansible Playbook script to manage the artifact on the target node includes: receiving the artifact management task and storing the artifact management task in a task queue; retrieving the artifact management task from the task queue according to the scheduling order and assigning it to a currently idle task executor; the task executor driving the Ansible-Runner execution engine to run the Ansible Playbook script corresponding to the artifact management task to manage the artifact on the target node.

[0017] As one implementation of the second aspect, it further includes: generating an artifact run table for the artifact management task; monitoring the execution logs and execution results of the Ansible Playbook script, and storing the execution logs and execution results in the artifact run table, wherein the execution results include execution success information or execution error information.

[0018] As one implementation of the second aspect, it also includes: the artifact management request includes the dependencies of multiple artifact management tasks, and the dependencies are parsed; for artifact management tasks without dependencies, each artifact management task is executed in parallel; for artifact management tasks with dependencies, the subsequent artifact management task is executed after the preceding artifact management task has been completed.

[0019] For the beneficial effects of this aspect, please refer to the description of the beneficial effects in each part of the first aspect above.

[0020] A third aspect of this application provides a computing device comprising: at least one processor; and at least one memory connected to the processor and storing program instructions, which, when executed by the at least one processor, cause the at least one processor to perform an artifact management method for a cloud-native platform as described in any of the second aspects above.

[0021] For the beneficial effects of this aspect, please refer to the description of the beneficial effects in each part of the first aspect above.

[0022] A fourth aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a computer, cause the computer to perform the artifact management method of the cloud-native platform described in any of the second aspects above.

[0023] The beneficial effects in this regard can also be found in the descriptions of the beneficial effects in each part of the first aspect above. Attached Figure Description

[0024] The various technical features of this application and their relationships will be further explained below with reference to the accompanying drawings. The drawings are exemplary; some technical features are not shown to scale, and some drawings may omit technical features commonly used in the art to which this application pertains that are not essential for understanding and implementing this application, or additionally show technical features that are not essential for understanding and implementing this application. In other words, the combination of various technical features shown in the drawings is not intended to limit this application. Furthermore, throughout this application, the same reference numerals refer to the same things. Specific descriptions of the drawings are as follows: Figure 1 A schematic diagram of the structure of a cloud-native platform artifact management system provided in this application embodiment; Figure 2 A flowchart illustrating an artifact management method for a cloud-native platform provided in this application embodiment; Figure 3 A sequence diagram of an artifact deployment process for a cloud-native platform is provided as an embodiment of this application; Figure 4 A schematic diagram of the structure of a product management device for a cloud-native platform provided in this application embodiment; Figure 5 A schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions provided in this application will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the solutions provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that, with the evolution of system structures and methods, the technical solutions provided in this application are equally applicable to similar technical problems.

[0026] It should be understood that the embodiments of this application provide a solution for artifact management on a cloud-native platform. Since these technical solutions address the same or similar problems, some repetitions may not be repeated in the following descriptions of specific embodiments, but these specific embodiments should be considered as mutually referencing each other and can be combined with each other.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit the scope of this application.

[0028] In order to accurately describe the technical content of this application and to accurately understand the present invention, the following explanations or definitions of the terms used in this specification are given before describing the specific embodiments: 1) Go: A statically typed, compiled, and concurrency-friendly open-source programming language developed by Google. It has a concise syntax, built-in goroutines and channels, and is suitable for building high-performance, high-concurrency backend services.

[0029] 2) Ansible: An open-source IT automation platform used for configuration management, application deployment, task orchestration, and cloud infrastructure management. It uses YAML format playbooks to describe automated tasks and executes operations on remote nodes via the SSH protocol, eliminating the need to install an agent on the target machine (agentless).

[0030] 3) Playbook: Sometimes referred to as a script in the industry, a Playbook is a YAML file in Ansible used to describe a sequence of automated tasks. It defines, for example, which nodes to run on, in what order to run them, and what operations to perform.

[0031] 4) Ansible Playbook: Ansible Playbook is a declarative configuration file based on YAML format used by Ansible to define a set of automated tasks that are executed sequentially on remote target nodes. It describes the application deployment process in a readable way. In this application, the Ansible Playbook is not a manually written static YAML file, but is automatically generated in real time by the Go language's PlaybookBuilder, PlayBuilder, and TaskBuilder based on the deployment configuration parameters (such as installation path, environment variables, target nodes, etc.) submitted by the user.

[0032] 5) Ansible-Runner: This refers to the Ansible executor, commonly known as Ansible-Runner in the industry. Ansible-Runner is a Python library and command-line tool provided by Red Hat for programmatically invoking Ansible Playbooks. It encapsulates the Ansible execution environment, providing standardized input / output interfaces (such as event streams, logs, and status).

[0033] 6) Builder Pattern: Also known as the builder pattern or generator pattern, it is a classic creational design pattern used to separate the construction process of a complex object from its final representation, allowing the same construction process to create different representations. Simply put, when creating a complex object composed of multiple parts, the builder pattern allows you to "assemble" it step by step, rather than passing all parameters at once. In this application, the complex object to be built is an Ansible Playbook, which contains multiple Plays, each Play contains multiple Tasks, and each Task has corresponding parameters.

[0034] 7) TaskBuilder: Also known as a task builder, it is used to build the smallest unit of execution (i.e., a task).

[0035] 8) PlayBuilder: Also known as the script builder, it organizes multiple tasks created by TaskBuilder into a script segment.

[0036] 9) PlaybookBuilder: Also known as the script master builder, it combines multiple script segments created by PlayBuilder into a complete, executable Playbook file.

[0037] 10) systemd: A system and service manager widely used in the Linux operating system, used to start, stop, restart, and monitor services or tasks.

[0038] 11) Gin Framework: Gin is a high-performance HTTP Web framework written in Go that can provide high-performance RESTful interfaces.

[0039] 12) RESTful API Interface: A RESTful API interface is a web service interface designed based on the REST architectural style. It uses standard HTTP protocol methods (such as GET, POST, PUT, DELETE) to operate on resources in order to realize communication between the client and the server. REST is a set of design constraints proposed by Roy Fielding in 2000. APIs that conform to these constraints are called "RESTful".

[0040] 13) GORM: is a Go language object-relational mapping (ORM) library used to simplify the interaction between Go applications and relational databases such as MySQL, PostgreSQL, SQLite, SQL Server, etc.

[0041] 14) Shell: In this application, it refers to the Shell script fragments or executable commands that are dynamically constructed by PlaybookBuilder and encapsulated as Ansible Tasks during the deployment process. These commands are executed in the operating system Shell environment of the target node by calling the Ansible Shell module, so as to achieve customized operations that cannot be covered by the standard Ansible module.

[0042] The following is a detailed description of a cloud-native platform artifact management system provided in this embodiment, with reference to the accompanying drawings.

[0043] like Figure 1 The diagram shows the structure of an artifact management system for a cloud-native platform provided in an embodiment of this application. The artifact management system includes an interface layer 110, a service layer 120, a Playbook generation layer 130, and an Ansible integration layer 140. In some embodiments, the artifact management system further includes a data layer 150.

[0044] In some embodiments, the interface layer 110 can be an API interface layer, built on the Gin framework, used to provide RESTful API interfaces. The interface layer 110 is used to receive artifact management requests submitted by users. The type of artifact management request can include artifact deployment requests or artifact uninstallation requests. Specifically, the interface layer 110 can include a node management interface, an artifact management interface, and a deployment management interface. The node management interface is used to receive target node information from the artifact management request. The target node represents the node that needs artifact management, and the target node information can include the target node identifier, target node path, and the key used to connect to the target node. The artifact management interface is used to receive the artifact file itself and artifact metadata. The artifact file can be any common format, such as .tar.gz, .zip, .jar, Docker images, etc. The deployment management interface is used to receive management-related configuration information, which generally includes a complete management scheme configuration, such as artifact identifier, target node information, management path, environment variables, dependencies, etc.

[0045] Service layer 120 communicates with interface layer 110 and is used to parse data in artifact management requests from interface layer 110 to generate artifact management tasks. Specifically, service layer 120 may include node service (NodeService), artifact service (ArtifactService), and deployment service (ArtifactRunService). It should be understood that although it is called deployment service here, it can be used not only for artifact deployment but also for artifact uninstallation, artifact version rollback, etc. In this embodiment, node service communicates with node management interface and is used to receive target node information from node management interface and verify the received target node information. Artifact service communicates with artifact management interface and is used to receive artifact files and artifact metadata from artifact management interface and verify artifact files and artifact metadata. Deployment service communicates with deployment management interface and is used to receive management configuration information from deployment management interface and parse management configuration information to generate artifact management tasks. These artifact management tasks may include artifact deployment tasks, artifact uninstallation tasks, artifact version rollback tasks, etc.

[0046] Data layer 150 communicates with service layer 120 and is built on GORM. Data layer 150 receives target node information from node service and stores it in its node record table (Nodes). Data layer 150 also receives artifact files and artifact metadata from artifact service and stores them in its artifact management table (Artifacta).

[0047] Playbook generation layer 130 communicates with service layer 120 to dynamically generate Ansible Playbook scripts corresponding to artifact management tasks based on the builder pattern. Specifically, Playbook generation layer 130 includes a Playbook builder, a DeployPlaybook template, an UndeployPlaybook template, and an Ansible wrapper module.

[0048] In this embodiment, PlaybookBuilder, by combining builders such as PlayBuilder and TaskBuilder in the Builder pattern, and based on the management configuration information in the artifact management request (from the deployment management interface of service layer 120), can dynamically generate Ansible Playbook scripts. Specifically, the Playbook builder is used to call the corresponding script module according to the type of artifact management task. The type of artifact management task includes artifact uninstallation or artifact deployment. That is, when the type of artifact management task is artifact deployment, the Playbook builder calls the deployment script template to generate the deployment script; when the type of artifact management task is artifact uninstallation, the Playbook builder calls the uninstallation script template to generate the uninstallation script.

[0049] In this embodiment, the deployment script template defines the artifact deployment process. When the artifact management task type issued by the server is artifact deployment, the deployment script template responds to the Playbook builder's call by invoking one or more pre-packaged Ansible functional modules at the underlying level and automatically filling the management configuration information into the corresponding positions, thereby generating an Ansible Playbook script for artifact deployment. The uninstallation script template defines the artifact uninstallation process. When the artifact management task type issued by the server is artifact uninstallation, the uninstallation script template responds to the Playbook builder's call by invoking one or more pre-packaged Ansible functional modules at the underlying level and automatically filling the management configuration information into the corresponding positions, thereby generating an Ansible Playbook script for artifact uninstallation.

[0050] In this embodiment, the Ansible wrapper module pre-encapsulates multiple Ansible functional modules represented by Go objects. These pre-encapsulated Ansible functional modules are located at the bottom layer of the Playbook generation layer 130. In response to calls to deploy or unload playbook templates, the deployment and unload playbook templates can generate corresponding Ansible Playbook scripts by calling these Ansible functional modules represented by Go objects. In some embodiments, chained calls are supported when invoking Ansible functional modules, thereby enabling the generation of complex Ansible Playbook scripts.

[0051] In this embodiment, commonly used functions for artifact deployment and artifact uninstallation are encapsulated into Ansible functional modules. These Ansible functional modules may include a system management module (Systemd module), a copy module, an unarchive module, and a shell module. The system management module controls the process and lifecycle of tasks through the systemd service. This module is crucial for standardized management; tasks are started, stopped, or restarted by calling this module. For example, when deploying an artifact, if the management configuration information requires the task to start automatically on boot, then parameters for automatic startup need to be configured in this module. Similarly, when uninstalling an artifact, if the management configuration information requires stopping the service and disabling automatic startup, then parameters for stopping the service and disabling automatic startup also need to be configured in this module. The copy module copies artifact files to the target node. This copying process relies on target node information, which can be sent by the service layer 120 or obtained from the node record table in the database 150. The decompression module is used to decompress artifact files on the target node and store them in the target installation directory. The Shell module is used to execute arbitrary shell commands provided by the user on the target node. The configuration of this module provides flexibility to the entire system, allowing operations not covered by pre-packaged Ansible functional modules to be performed via shell commands, thereby improving the flexibility and scalability of the system.

[0052] The Ansible integration layer 140 is communicatively connected to both the service layer 120 and the Playbook generation layer 130. It executes the Ansible Playbook scripts generated by the Playbook generation layer 130 according to control instructions from the service layer 120 to manage artifacts on target nodes. Specifically, the Ansible integration layer 140 includes a task dispatcher, a task queue, a worker pool, a worker executor, and an Ansible-Runner execution engine. In this embodiment, the task dispatcher receives artifact management tasks from the service layer 120. These artifact management tasks refer to Ansible tasks received after the Playbook generation layer 130 generates the Ansible Playbook script. The task dispatcher stores the received Ansible tasks in the task queue. The task queue receives and caches artifact management tasks from the task dispatcher; as an implementation, the task queue follows a first-in, first-out (FIFO) rule. The work pool manages multiple task executors. It monitors the queuing status of tasks in the task queue and the working status of task executors. It retrieves tasks from the task queue according to the scheduling order and assigns them to currently idle task executors. The task executors drive the Ansible-Runner execution engine to execute the Ansible Playbook scripts corresponding to the assigned tasks. The Ansible-Runner execution engine communicates with the target node 160, thereby enabling the deployment or unloading of corresponding artifacts on the target node 160.

[0053] In some embodiments, the Ansible integration layer 140 is also communicatively connected to the data layer 150. The data layer 150 monitors the execution logs and results of the Ansible-Runner execution engine executing the Ansible Playbook scripts, and stores the execution logs and results in the ArtifactRuns table of the data layer 150. The execution results may include success information and error information corresponding to failures.

[0054] Based on the artifact management system provided in the above embodiments, it supports the automatic management of artifacts in various formats without the need to develop different deployment scripts and management tools for artifacts of different formats, thus reducing the complexity of the system. Furthermore, in the artifact management system provided in this embodiment, after a user submits an artifact management request, the system can automatically generate and execute the corresponding Ansible Playbook script, thereby achieving automatic deployment or automatic uninstallation of artifacts across multiple nodes.

[0055] Another embodiment of this application provides an artifact management method for a cloud-native platform. This method is implemented based on the artifact management system for a cloud-native platform provided in the above embodiments. Therefore, this embodiment will not repeat the details of the above embodiments. The following will be combined with... Figure 2 The method is described in detail below, and includes steps S210-S240: S210: Receive an artifact management request submitted by a user. The artifact management request includes target node information, artifact files, and management configuration information. The type of artifact management request includes an artifact deployment request or an artifact uninstallation request.

[0056] In this step, the interface layer of the artifact management system on the cloud-native platform receives artifact management requests submitted by the user. The target node represents the node where artifact deployment or uninstallation is required; there can be one or more target nodes. The artifact file can be a compressed package of the artifact, artifact metadata, etc. Management configuration information represents information related to artifact deployment or uninstallation.

[0057] S220: Parse the artifact management request to generate an artifact management task, wherein the artifact management task type includes an artifact deployment task or an artifact unloading task.

[0058] In this step, the service layer of the artifact management system on the cloud-native platform parses the artifact management request. This parsing mainly refers to the processing of business logic, such as verifying the target node, verifying the artifact file, and parsing and classifying management configuration information, thereby generating an artifact management task. When the goal of the artifact management task is to unload the artifact on the target node, then the artifact management task is an artifact unloading task; when the goal of the artifact management task is to deploy the artifact on the target node, then the artifact management task is an artifact deployment task.

[0059] S230: Dynamically generate the Ansible Playbook script corresponding to the artifact management task based on the builder pattern.

[0060] In this step, the Playbook generation layer 130 in the artifact management system of the cloud-native platform automatically generates the corresponding Ansible Playbook scripts by calling various builders (such as PlaybookBuilder, PlayBuilder, and TaskBuilder). Specifically, the Playbook generation layer 130 calls the corresponding playbook template based on the type of artifact management task. When the artifact management task is artifact deployment, the Playbook generation layer 130 calls the deployment playbook template. The deployment playbook template generates an Ansible Playbook script for artifact deployment by calling one or more pre-packaged Ansible functional modules at the underlying level and based on management configuration information. The deployment playbook template predefines the artifact deployment-related process. When the artifact management task is artifact uninstallation, the Playbook generation layer 130 calls the uninstallation playbook template. The uninstallation playbook template generates an Ansible Playbook script for artifact uninstallation by calling one or more pre-packaged Ansible functional modules at the underlying level and based on management configuration information. The uninstallation playbook template predefines the artifact uninstallation process.

[0061] S240: Execute the Ansible Playbook script to manage the artifact on the target node.

[0062] In this step, after the Ansible Playbook script is generated, the Ansible integration layer 140 in the artifact management system of the cloud-native platform receives the artifact management task issued by the service layer 120 and stores the received artifact management task in the task queue. Here, the artifact management task refers to the Ansible task. Then, according to the scheduling order, the Ansible task is retrieved from the task queue and assigned to the currently idle task executor. The task executor drives the Ansible-Runner execution engine to run the corresponding Ansible Playbook script, so that the artifact can be installed on the target node or unloaded from the target node.

[0063] In some embodiments, the execution results and execution logs of Ansible Playbook scripts can also be stored in the artifact run table of the data layer, thereby allowing the execution status to be known.

[0064] In some embodiments, the artifact management request may also declare dependencies between multiple artifact management tasks, which may be included in the management configuration information. The artifact management system of the cloud-native platform parses the dependencies between these multiple artifact management tasks, determines the execution order of the tasks based on these dependencies, and then generates Ansible Playbook scripts for each task in that order. These Ansible Playbook scripts are then executed sequentially, thereby enabling the management of multiple tasks with dependencies on the target node.

[0065] Next, we will take product deployment as an example and combine it with... Figure 3 This document details the artifact management method of the cloud-native platform. The principle of this embodiment is the same as that of the above embodiments, so the above embodiments can be partially or completely referenced. This embodiment will not repeat the same parts in detail, but will focus on the implementation process of the method.

[0066] Users package application artifacts (including executables, configuration files, installation scripts, etc.) into tar format and submit artifact deployment requests through the API interface layer of the artifact management system on the cloud-native platform. These deployment requests include management configuration information such as target node selection, artifact installation path configuration, system service configuration parameters, environment variables, startup parameters, and dependent service configurations. Upon receiving the artifact deployment request, the API interface layer calls the deployment service of the service layer. This service automatically parses the artifact's metadata (including artifact name, version, architecture, description, etc.) to create an artifact runtime task and stores it in the ArtifactRuns database of the data layer. The database returns the ID of the artifact runtime task to the service layer. Then, the service layer's deployment service drives the Playbook builder to dynamically generate the corresponding Ansible Playbook deployment script based on the task parameters. The Playbook builder returns the generated Playbook object (i.e., the generated Ansible Playbook deployment script) to the service layer's deployment service. Table 1 below shows an example of an Ansible Playbook deployment script.

[0067] Then, the service layer's deployment service submits the created Ansible tasks to the task dispatcher. The task dispatcher submits the Ansible tasks to the task queue for caching and queuing. When an idle task executor (Worker) is available, the task dispatcher retrieves the Ansible task from the task queue and assigns it to the idle task executor. The task executor then calls the Ansible-Runner execution engine, which executes the generated Ansible Playbook deployment script. In this example, the process of executing the Ansible Playbook deployment script includes: connecting to the specified target node via the SSH protocol, and then sequentially performing the copying, decompression, installation, systemd service configuration, and startup of the artifact files. During this process, the Ansible-Runner execution engine records the execution status and execution logs in real time. After the Worker learns of the deployment result of the artifact deployment task, it notifies the service layer's deployment service to update the task status. The service layer's deployment service updates the status of the artifact running tasks in the ArtifactRuns data layer and finally returns the deployment result through the API layer, notifying the user of the deployment result, such as deployment success or failure, and may also include the reason for failure.

[0068] In some embodiments, within a microservice orchestration scenario, multiple microservice artifact deployment requests with dependencies are submitted through the API interface layer of the cloud-native platform's artifact management system. Upon receiving these deployment requests, the API interface layer invokes the deployment service of the service layer. This service service parses the deployment plan and checks the dependencies between the microservice components. The deployment service intelligently schedules deployment tasks based on dependencies, prioritizing the parallel execution of independent tasks without pre-existing dependencies and monitoring their execution status in real time. Once a service is detected as successfully deployed, the deployment service immediately initiates the deployment process for its dependent services, thus achieving dependency deployment.

[0069] Another embodiment of this application provides an artifact management device for a cloud-native platform. It should be understood that... Figure 4 This is merely an illustrative structural diagram of an artifact management device for a cloud-native platform, and this application does not limit the division of functional modules within such an artifact management device. Figure 4As shown, the artifact management device 40 of the cloud-native platform can be logically divided into multiple modules, each with different functions. The function of each module is implemented by a processor in a computing device reading and executing instructions from memory. For example, the artifact management device of the cloud-native platform includes a receiving module 410, a parsing module 420, a generating module 430, and an execution module 440. In one implementation, the FPGA is used for execution... Figure 2 The content shown.

[0070] Specifically: a receiving module 410 is used to receive an artifact management request submitted by a user. The artifact management request includes target node information, artifact files, and management configuration information. The type of the artifact management request includes an artifact deployment request or an artifact uninstallation request. A parsing module 420 is used to parse the artifact management request to generate an artifact management task. The type of the artifact management task includes an artifact deployment task or an artifact uninstallation task. A generation module 430 is used to dynamically generate an Ansible Playbook script corresponding to the artifact management task based on the builder pattern. An execution module 440 is used to execute the Ansible Playbook script to manage the artifact on the target node.

[0071] The specific implementation methods of each functional module in this embodiment can be found in the description of the above embodiments, and will not be repeated here.

[0072] Figure 5 This is a structural schematic diagram of a computing device 900 provided in an embodiment of this application. This computing device can execute various optional embodiments of the artifact management method for cloud-native platforms described above. The computing device can be a terminal, or a chip or chip system within the terminal. Figure 5 As shown, the computing device 900 includes: a processor 910, a memory 920, and a communication interface 930.

[0073] It should be understood that Figure 5 The communication interface 930 in the computing device 900 shown can be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0074] The processor 910 can be connected to the memory 920. The memory 920 can be used to store the program code and data. Therefore, the memory 920 can be a storage unit inside the processor 910, an external storage unit independent of the processor 910, or a component that includes both the storage unit inside the processor 910 and the external storage unit independent of the processor 910.

[0075] Optionally, the computing device 900 may also include a bus. The memory 920 and communication interface 930 can be connected to the processor 910 via the bus. The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The symbol is represented by a line without an arrow, but this does not mean that there is only one bus or one type of bus.

[0076] It should be understood that in the embodiments of this application, the processor 910 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Alternatively, the processor 910 may employ one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0077] The memory 920 may include read-only memory and random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include non-volatile random access memory. For example, the processor 910 may also store device type information.

[0078] When the computing device 900 is running, the processor 910 executes computer execution instructions stored in the memory 920 to perform any of the operational steps of the above method and any of the optional embodiments thereof.

[0079] It should be understood that the computing device 900 according to the embodiments of this application can correspond to the corresponding subject in executing the methods according to the various embodiments of this application, and the above and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of the methods of this embodiment. For the sake of brevity, they will not be described in detail here.

[0080] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0081] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0082] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0083] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0085] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0086] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to perform the above-described method, which includes at least one of the schemes described in the above embodiments.

[0087] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0088] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0089] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0090] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0091] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, all of which fall within the scope of protection of this application.

Claims

1. A product management system for a cloud-native platform, characterized in that, include: The interface layer is used to receive artifact management requests submitted by users. The artifact management requests include target node information, artifact files and management configuration information. The types of artifact management requests include artifact deployment requests or artifact uninstallation requests. The service layer, which communicates with the interface layer, is used to parse the artifact management request to generate artifact management tasks. The types of artifact management tasks include artifact deployment tasks or artifact unloading tasks. The Playbook generation layer, which communicates with the service layer, is used to dynamically generate Ansible Playbook scripts corresponding to the artifact management tasks based on the builder pattern. The Ansible integration layer is communicatively connected to both the service layer and the Playbook generation layer, and is used to execute the Ansible Playbook script according to the control instructions of the service layer in order to manage the artifacts on the target node.

2. The system according to claim 1, characterized in that, The Playbook generation layer includes: The Playbook builder is used to call the corresponding playbook template based on the type of the artifact management task. A deployment script template is used to define the process of artifact deployment; the deployment script template responds to the call of the Playbook builder by calling one or more pre-packaged Ansible functional modules and generating an Ansible Playbook script for artifact deployment based on the management configuration information; An uninstallation script template is used to define the process of uninstalling artifacts; the uninstallation script template responds to the call of the Playbook builder by calling one or more pre-packaged Ansible functional modules and generating an Ansible Playbook script for artifact uninstallation based on the management configuration information; Ansible wrapper module, which pre-packages multiple Ansible functional modules; the deployment playbook template calls one or more of the pre-packaged Ansible functional modules in the Ansible wrapper module to generate an Ansible Playbook script for artifact deployment; the uninstallation playbook template calls one or more of the pre-packaged Ansible functional modules in the Ansible wrapper module to generate an Ansible Playbook script for artifact uninstallation.

3. The system according to claim 2, characterized in that, The pre-packaged Ansible functional modules include at least one of the following: The system management module is used to control the process of the product management tasks through the systemd service; The copy module is used to copy the product file to the target node according to the target node information; The decompression module is used to decompress the product file on the target node; The Shell module is used to execute arbitrary Shell commands on the target node, including functions not covered by the pre-packaged Ansible functional module.

4. The system according to claim 1, characterized in that, The Ansible integration layer includes: a task dispatcher, a task queue, a work pool, a task executor, and the Ansible-Runner execution engine; The task dispatcher is used to receive the artifact management task from the service layer and store the artifact management task in the task queue; The task queue is used to receive and cache the artifact management tasks from the task distributor; The work pool is used to monitor the status of the task queue and the task executor, retrieve the product management task from the task queue according to the scheduling order, and assign it to the currently idle task executor. The task executor is used to drive the Ansible-Runner execution engine to run the Ansible Playbook script corresponding to the artifact management task, so as to manage the artifact on the target node.

5. The system according to claim 4, characterized in that, Also includes: The data layer, which is communicatively connected to the service layer, is used to store the target node information in the product management task into the target node record table, and to store the product files and management configuration information in the product management task into the product management table. The data layer is also connected to the Ansible integration layer to monitor the execution logs and execution results of the Ansible Playbook scripts, and to store the execution logs and execution results in the artifact run table. The execution results include execution success information or execution error information.

6. A method for managing artifacts on a cloud-native platform, characterized in that, include: Receive artifact management requests submitted by users. The artifact management requests include target node information, artifact files, and management configuration information. The types of artifact management requests include artifact deployment requests or artifact uninstallation requests. The artifact management request is parsed to generate an artifact management task, the type of which includes an artifact deployment task or an artifact unloading task; Ansible Playbook scripts corresponding to the artifact management tasks are dynamically generated based on the builder pattern. Execute the Ansible Playbook script to manage the artifacts on the target node.

7. The method according to claim 6, characterized in that, The Ansible Playbook script dynamically generated based on the builder pattern and corresponding to the artifact management task includes: The corresponding script template is invoked according to the type of the product management task, and the script template includes a deployment script template and an unloading script template; The deployment playbook template generates an Ansible Playbook script for artifact deployment by calling one or more pre-packaged Ansible functional modules and based on the management configuration information; wherein, the deployment playbook template defines the artifact deployment process; The uninstallation playbook template generates an Ansible Playbook script for artifact uninstallation by calling one or more pre-packaged Ansible functional modules and based on the management configuration information; wherein, the uninstallation playbook template defines the artifact uninstallation process.

8. The method according to claim 6, characterized in that, The execution of the Ansible Playbook script to manage the artifacts on the target node includes: Receive the product management task and store the product management task in the task queue; The artifact management task is retrieved from the task queue according to the scheduling order and assigned to the currently idle task executor. The task executor drives the Ansible-Runner execution engine to run the Ansible Playbook script corresponding to the artifact management task in order to manage the artifact on the target node.

9. The method according to claim 6, characterized in that, Also includes: Generate the product operation table for the product management task; Monitor the execution logs and results of the Ansible Playbook script, and store the execution logs and results in the artifact run table. The execution results include execution success information or execution error information.

10. The method according to claim 6, characterized in that, Also includes: The product management request includes dependencies between multiple product management tasks; the dependencies are then parsed. For product management tasks that do not have dependencies, execute each product management task in parallel; For product management tasks with dependencies, the subsequent product management task is executed after the preceding product management task is completed.

Images