Application release method and device, equipment, storage medium and program product

Abstract

The invention discloses an application publishing method and device, equipment, a storage medium and a program product, and the method comprises the steps: responding to at least one application publishing request, and determining to-be-published data corresponding to the at least one application publishing request and a publishing process corresponding to a to-be-executed architecture; based on a preset task template, performing classification processing on a release process corresponding to the to-be-executed architecture, and determining a target release process corresponding to the to-be-executed architecture; performing arrangement processing on the target release process, and determining a target arrangement engine result corresponding to the at least one application release request; and publishing the to-be-published data corresponding to the at least one application publishing request according to the target arrangement engine result. In this way, the hybrid application publishing requirements of a traditional architecture and a cloud native architecture can be compatible, and then the application publishing efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to an application publishing method, device, equipment, storage medium and program product. Background Art

[0002] With the development of automated and integrated release technologies, the application release process has become more efficient and convenient. However, considering that the release automation operation and maintenance tool (Ansible) mainly supports the release of applications in traditional architectures, and the continuous delivery tool (ArgoCD) only supports the release of applications in cloud-native architectures, the incompatibility of application release tools between traditional architectures and cloud-native architectures makes it more difficult to release applications when using multiple different tools, and reduces the efficiency of application release. Summary of the invention

[0003] The present application proposes an application publishing method, apparatus, device, storage medium, and program product that are compatible with hybrid application publishing requirements of traditional architecture and cloud native architecture, thereby improving the efficiency of application publishing.

[0004] The technical solution of this application is implemented as follows:

[0005] In a first aspect, an embodiment of the present application provides an application publishing method, the method comprising:

[0006] In response to at least one application publishing request, determining the publishing process corresponding to the to-be-published data and the to-be-executed architecture corresponding to the at least one application publishing request;

[0007] Classify the release processes corresponding to the architecture to be executed based on the preset task template, and determine the target release process corresponding to the architecture to be executed;

[0008] Performing orchestration processing on the target publishing process to determine a target orchestration engine result corresponding to at least one application publishing request;

[0009] According to the target orchestration engine result, the to-be-published data corresponding to at least one application publishing request is published.

[0010] In a second aspect, an embodiment of the present application provides an application publishing device, the application publishing device includes a determination unit, an arrangement determination unit and a publishing unit, wherein:

[0011] A determination unit, configured to determine, in response to at least one application release request, to-be-released data corresponding to the at least one application release request and a release process corresponding to the architecture to be executed; classify the release processes corresponding to the architecture to be executed based on a preset task template, and determine a target release process corresponding to the architecture to be executed;

[0012] An orchestration unit, configured to perform orchestration processing on a target publishing process and determine a target orchestration engine result corresponding to at least one application publishing request;

[0013] A publishing unit is used to publish the to-be-published data corresponding to at least one application publishing request according to the target orchestration engine result.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, the electronic device comprising a memory and a processor, wherein:

[0015] A memory for storing computer programs that can be executed on the processor;

[0016] A processor is used to execute the method described in the first aspect when running a computer program.

[0017] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by at least one processor, it implements the method described in the first aspect.

[0018] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the method described in the first aspect is implemented.

[0019] The embodiment of the present application provides an application publishing method, device, equipment, storage medium and program product, first responding to at least one application publishing request, determining the to-be-published data corresponding to the at least one application publishing request and the publishing process corresponding to the to-be-executed architecture; then classifying and processing the publishing process corresponding to the to-be-executed architecture based on the preset task template, and determining the target publishing process corresponding to the to-be-executed architecture; then orchestrating the target publishing process, determining the target orchestration engine result corresponding to at least one application publishing request; finally, according to the target orchestration engine result, publishing the to-be-published data corresponding to at least one application publishing request. In this way, by unifying the publishing process of the to-be-executed architecture through the preset task template, it can meet the host publishing requirements under the traditional architecture, and the container publishing requirements under the cloud native architecture, and also support the hybrid publishing requirements of the host and container under the hybrid architecture of the traditional architecture and the cloud native architecture; and orchestrating the target publishing process, and publishing the application according to the target orchestration engine result, that is, by unifying the publishing task template orchestration engine and execution engine and the task scheduling design, the application publishing task is more fine-grained and more accurate in the scheduling of steps and nodes, so that in the scenario where massive resources should be published at the same time, the efficiency of application publishing can be improved, thereby achieving the purpose of reducing costs and increasing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1A schematic diagram of a method for publishing an application provided in an embodiment of the present application Figure 1 ;

[0021] Figure 2 A schematic diagram of a target publishing process structure of a traditional architecture provided in an embodiment of the present application;

[0022] Figure 3 A schematic diagram of the target release process structure of a cloud native architecture provided in an embodiment of the present application;

[0023] Figure 4 A schematic diagram of a method for publishing an application provided in an embodiment of the present application Figure 2 ;

[0024] Figure 5 A schematic diagram of the composition of a task-step-node topology structure provided in an embodiment of the present application;

[0025] Figure 6 A schematic diagram of a method for publishing an application provided in an embodiment of the present application Figure 3 ;

[0026] Figure 7 A schematic diagram of the structure of an execution engine for application release provided by this application;

[0027] Figure 8 A schematic diagram of a processing flow of a scheduling pool provided in an embodiment of the present application;

[0028] Fig. 9 A schematic diagram of the architecture composition of an application release provided for the implementation of this application;

[0029] Fig.10 A schematic diagram of the structure of an application publishing device provided in an embodiment of the present application;

[0030] Fig.11 A schematic diagram of the specific hardware structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] In order to enable a more detailed understanding of the features and technical contents of the embodiments of the present application, the implementation of the embodiments of the present application is described in detail below in conjunction with the accompanying drawings. The attached drawings are for reference only and are not used to limit the embodiments of the present application.

[0032] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0033] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0034] It should also be pointed out that the terms "first\second\third" involved in the embodiments of the present application are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0035] In addition, the reference to "embodiment" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiment may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0036] The following is an introduction to the related technologies of this application.

[0037] In the related technologies, the traditional architecture release technology provided by the automated operation and maintenance tool (Ansible) mainly refers to the applications directly deployed on the host, such as monolithic architecture applications, vertical architecture applications, service-oriented architecture (SOA) applications, microservice architecture applications and distributed architecture applications. The cloud-native architecture release technology provided by the continuous delivery tool (Argo CD) is used.

[0038] Under the traditional framework, Ansible aims to simplify the management and execution processes of application releases. The following process is used to automate releases using Ansible: (1) Environment configuration: In the Ansible configuration file, define the host list and variables for different environments. For example, you can define a list of hosts for development, test, and production environments, as well as configuration variables related to each environment. (2) Integration with version control systems (such as Git): In the release process, you can pull specific code versions from the version control system. (3) Playbook orchestration and role management: Use Ansible's Playbook and Roles functions to define the steps and configuration of the release process. A Playbook contains a series of tasks, and Roles is used to organize tasks and variables. For example, tasks may include code pulling, building, testing, database migration, etc. (4) Host configuration: Ansible's Playbook can configure the host, including installing required software packages, creating file directories, setting environment variables, etc., which helps ensure that the target host meets the requirements of the application. (5) Release triggering: Use triggers (such as CI / CD tools, version tags, or manual triggers) to start Ansible's Playbook to perform release operations. This can be done in different environments to perform various tasks as needed.

[0039] In a cloud-native environment, using Argo CD to automate application releases on a container orchestration system (Kubernetes, also known as k8s) is a common technical approach that aims to lower the threshold for container releases and adapt to the needs of cloud-native releases. In Argo CD, declarative configuration files for applications are defined. These configuration files describe the components, services, configurations, dependencies, and other information of the application, and declarative configuration is used to ensure that the target state is consistent with the expected state. When the configuration in the distributed version control system (Git) repository changes, Argo CD automatically detects and synchronizes the application state.

[0040] However, for Ansible, its release technology cannot support the agile release of cloud-native applications. Users need to develop custom plug-ins to call k8s interfaces, and there is no management and maintenance of the cloud-native release media. Although Ansible can support the configuration of host lists and define release methods, it cannot configure cloud-native namespace lists and customize cloud-native applications. It cannot flexibly arrange traditional host release and cloud-native release playbooks to meet complex business needs. In addition, Ansible does not cope well with complex changes in public cloud massive resources. The release template is directly bound to the business host Internet Protocol (IP) address. Due to the need for resource reuse and evacuation, the business host IP address in public cloud scenarios often changes, resulting in a large amount of manpower required to check each Ansible release template before the change release to avoid abnormal business resource release. For Argo CD, it is a cloud-native release technology that does not support the deployment of traditional binary files at all, nor does it support the maintenance of host information, binary files, and application release orchestration of traditional architectures.

[0041] In short, with the development of automated and integrated release technologies, the application release process has become more efficient and convenient. However, considering that Ansible mainly supports the release of applications in traditional architectures, and Argo CD only supports the release of applications in cloud-native architectures, the incompatibility of application release tools between traditional architectures and cloud-native architectures makes it more difficult to release applications when using multiple different tools, and reduces the efficiency of application release.

[0042] Based on this, the embodiment of the present application provides an application publishing method; first, in response to at least one application publishing request, determine the data to be published corresponding to the at least one application publishing request and the publishing process corresponding to the to-be-executed architecture; then, based on the preset task template, classify the publishing process corresponding to the to-be-executed architecture, and determine the target publishing process corresponding to the to-be-executed architecture; then, orchestrate the target publishing process, and determine the target orchestration engine result corresponding to at least one application publishing request; finally, according to the target orchestration engine result, publish the data to be published corresponding to at least one application publishing request. In this way, by unifying the publishing process of the to-be-executed architecture through the preset task template, it can meet the host publishing requirements under the traditional architecture, and meet the container publishing requirements under the cloud native architecture, and also support the hybrid publishing requirements of the host and container under the hybrid architecture of the traditional architecture and the cloud native architecture; and orchestrate the target publishing process, and publish the application according to the target orchestration engine result, that is, by unifying the publishing task template, the orchestration engine and the execution engine and the task scheduling design, the application publishing task is more fine-grained and more accurate in the scheduling of steps and nodes, so that in the scenario where massive resources should be published at the same time, the efficiency of application publishing can be improved, thereby achieving the purpose of reducing costs and increasing efficiency.

[0043] The present application is further described in detail below through the accompanying drawings and specific embodiments.

[0044] In one embodiment of the present application, Figure 1 A schematic diagram of a method for publishing an application provided in an embodiment of the present application Figure 1 .like Figure 1 As shown, this method can:

[0045] S101, in response to at least one application publishing request, determining to-be-published data corresponding to the at least one application publishing request and a publishing process corresponding to a to-be-executed architecture.

[0046] In the embodiment of the present application, before step S101, the user can input an application release request in the system to establish a corresponding business item for the relevant business to be established, and can configure the development environment, test environment and production environment under the business item. In addition, business attributes can be configured in the business item, such as basic information such as business name and time zone, and roles of operation and maintenance personnel, testers, etc.

[0047] It should be noted that at least one regional node is created in the production environment of the business. The user can enter the place name and regional name so that the system can determine the regional name of the regional node, thereby generating at least one region based on the regional node and the regional name, which is conducive to the unified release of multiple regions in the environment and the unified management and maintenance of the regions involved in the system. For example, the user establishes an application release request, creates a new node (regional node) in the generation environment under the cloud native architecture, and then enters the instance name (place name and region): South China region, and clicks Submit to generate the region. The backend responds to the application release request triggered by the user, determines the release process corresponding to the application release request, and determines at least one target release location (also called at least one namespace) under the region, so as to release the application release request triggered by the user.

[0048] Here, for regional nodes, it can be a national or global regional distribution. Clusters are different clusters or target release addresses under the region. For example, region A in the production environment has two clusters, B and C, or region A has 100 host IP addresses to be released.

[0049] In an embodiment of the present application, based on an application publishing request triggered by a user on a front-end interface, the back-end receives at least one application publishing request triggered by the user, and determines the data to be published corresponding to at least one application publishing request and the publishing process corresponding to the architecture to be executed. Exemplarily, the data to be published is an application package, and the relevant personnel can generate and establish an application package by programming on the system or upload the application package from a local or cloud server to the system, thereby establishing an application package (referred to as a program package). After the application package is established, the program package information of the application package can be configured, and the application package can be bound to the corresponding service module.

[0050] S102: Classify the release process corresponding to the architecture to be executed based on the preset task template, and determine the target release process corresponding to the architecture to be executed.

[0051] It should be noted that, in the embodiment of the present application, for the preset task template, the method further includes: performing abstract processing based on the release processes corresponding to at least two architectures to generate the preset task template.

[0052] In an embodiment of the present application, at least two architectures may include a traditional architecture and a cloud-native architecture, or may also include other application publishing technology architectures, which are determined based on actual conditions.

[0053] In addition, the preset task template may include basic information, media, processes, and execution nodes. Here, basic information can be referred to as application information, processes can be referred to as operations, and execution nodes can be referred to as objects. Among them, basic information is used to characterize the relevant data corresponding to the application release request, such as the deployment environment, business, module, node name, etc. corresponding to the application release request; the medium is used to characterize the data required for storage, transmission, and processing of the data to be released in the release process, which can also be understood as a carrier; the process is used to characterize the steps that need to be performed in the release process; the object is used to characterize the regional node to which the data to be released needs to be sent. For the traditional architecture, each regional node can include at least one host IP address, and for the cloud native architecture, each regional node can include at least one k8s cluster and namespace.

[0054] For example, the concepts released by the traditional architecture include: process, binary package, configuration file, execution script and flow, release host list, etc.; the concepts released by the cloud native architecture include: container (pod), yaml file, image, k8s application programming interface (Application Programming Interface, API), k8s cluster and namespace, etc. By abstracting the release process of the two architectures: application information, medium, process, object, and define application information through the business-module in the configuration management database (CMDB); abstracting processes, binary packages, configuration files, yaml files, template sets, and images as media; unifying host execution processes (i.e., execution scripts and flows) and k8s API calls as operations; unifying hosts, k8s clusters, and namespaces as objects.

[0055] It should be noted that the preset task template is used to represent the release process (also called release node) of the application release template under different architectures. Here, by unifying the release process under different architectures and associating and binding with the CMDB business topology through the preset task template, it is not directly associated with the business host IP, thus avoiding the impact of the underlying host IP change on the pipeline template, reducing the large amount of underlying resource inspection work of the change release personnel each time, and improving the change release timeliness.

[0056] It should also be noted that the reason why the visual interface can provide multiple projects and services under multiple projects in the form of a drop-down list for users to select relevant information of the application release request is because the user enters the relevant information of the application release request into the CMDB before the application is released, and the front end calls the CMDB so that the relevant information of the application release request stored in the CMDB can be displayed in the drop-down list of the front-end visual interface.

[0057] In the embodiment of the present application, a simple interactive orchestration page is used to provide users with a visual release orchestration process. Users can use it out of the box without having to master advanced operation and maintenance knowledge. The operation is simple and easy to use, with low difficulty for users to get started and strong promotion.

[0058] In a possible embodiment, the release process of the architecture to be executed can be abstracted based on the preset task template to obtain the target application release process. The architecture to be executed may include a traditional architecture, or a cloud-native architecture, or a hybrid architecture of the traditional architecture and the cloud-native architecture, etc., without any limitation here.

[0059] S103: Perform orchestration processing on the target publishing process to determine a target orchestration engine result corresponding to at least one application publishing request.

[0060] In the embodiment of the present application, after obtaining the target release process of the architecture to be executed, in order to meet the needs of the public cloud massive resource complex application release scenario, the release task template orchestration engine of the architecture application to be executed is unified to obtain the target orchestration result corresponding to at least one application release request. In addition, the target engine result may include the execution order, dependency relationship, etc. between each task, step and release node, so that the execution logic of the release node can be determined to release the data to be released corresponding to the application release request.

[0061] S104: Publish the to-be-published data corresponding to the at least one application publishing request according to the target orchestration engine result.

[0062] In an embodiment of the present application, for the front end, after the user triggers an application publishing request on the front end interface, it is determined that the program package will be sent to region A. Then the back end processes the application publishing request based on the user, obtains the target orchestration engine result, and publishes the program package through scheduling.

[0063] An embodiment of the present application provides an application publishing method, which unifies the publishing process of the architecture to be executed by pre-setting task templates, which can meet the host publishing requirements under the traditional architecture, and the container publishing requirements under the cloud native architecture, and also supports the hybrid publishing requirements of hosts and containers under the hybrid architecture of the traditional architecture and the cloud native architecture; and orchestrates the target publishing process, and publishes the application according to the target orchestration engine result, that is, by unifying the publishing task template orchestration engine and execution engine and task scheduling design, the application publishing task is more fine-grained and more accurate in the scheduling of steps and nodes, so that in the scenario where massive resources should be released at the same time, the efficiency of application publishing can be improved, thereby achieving the purpose of reducing costs and increasing efficiency.

[0064] In a possible implementation, the architecture to be executed may include a traditional architecture. Accordingly, the release process corresponding to the architecture to be executed is classified based on the preset task template to determine the target release process corresponding to the architecture to be executed, including:

[0065] Determine a first publishing process of at least one application publishing request under a traditional architecture, the first publishing process at least including: host type, business, module, node name, program package, configuration file, database file, basic operation and maintenance, execution task flow, script file and a selected publishing host address;

[0066] Classify the first release process based on the preset task template to determine the target release process corresponding to the traditional architecture;

[0067] Among them, in the target release process corresponding to the traditional architecture, the basic information includes the host type, business, module and node name in the first release process, the medium includes the program package, configuration file and database file in the first release process, the process includes the basic operation and maintenance, execution task flow and script file in the first release process, and the execution node includes the selected release host address in the first release process. Here, the selected host address can be determined from the CMDB, and the user only needs to determine the regional node to be released.

[0068] In the embodiment of the present application, the target release process corresponding to the traditional architecture includes basic information, medium, process and execution node. Here, the first release process of the traditional architecture is classified and processed, which can also be called abstract transformation, to construct the target release process of the traditional architecture. Figure 2 A schematic diagram of a target publishing process structure of a traditional architecture provided in an embodiment of the present application. Figure 2 As shown, the target release process of the traditional architecture includes four release nodes: basic information, medium, operation and execution node; among them, the basic information may include host type, business, module, node name and whether to pause. Here, whether to pause is an execution action, which is whether to pause the release task; the medium includes: program package, configuration file and database file; the process includes basic operation and maintenance, execution task flow and script file; the execution node includes the selected release host address, which is the host information bound under the CMDB business-module. For example, if the user chooses to send to the A region node, the host information corresponding to the A region node can be obtained from the CMDB, and then the application is released. Here, the database is Structured Query Language (SQL), so the database file can be referred to as SQL file.

[0069] It should be noted that a target release process of a traditional architecture includes all resource information released by each engineering change under the traditional architecture application. The release nodes in the release process are flexibly arranged and combined according to the different engineering release information of each application. In the scenario of public massive resource application change release, it can meet diverse release and deployment needs and improve the efficiency of public cloud massive resource change release.

[0070] In another possible implementation, the architecture to be executed may include a cloud native architecture. Accordingly, the release process corresponding to the architecture to be executed is classified based on the preset task template to determine the target release process corresponding to the architecture to be executed, including:

[0071] Determine a second publishing process for at least one application publishing request under the cloud native architecture, where the second publishing process includes at least: container type, service, module, node name, image file, template set, application programming interface, orchestration tool cluster, and namespace;

[0072] Classify the second release process based on the preset task template to determine the target release process corresponding to the cloud native architecture;

[0073] Among them, in the target release process corresponding to the cloud native architecture, the basic information includes the container type, business, module and node name in the second release process, the medium includes the image file and template set in the second release process, the process includes the business connectivity service (Business Connectivity Services, BCS) API interface in the second release process, and the execution node includes the k8s cluster and namespace in the second release process.

[0074] In the embodiment of the present application, the orchestration tool cluster can specifically refer to the k8s cluster. The target release process corresponding to the cloud native architecture includes basic information, media, processes, and execution nodes. Here, the second release process of the cloud native architecture is classified and processed, which can also be called abstract transformation, and then the target release process of the cloud native architecture is constructed. Figure 3 A schematic diagram of the target release process structure of a cloud native architecture provided in an embodiment of the present application. Figure 3As shown in the figure, the target release process of the cloud native architecture includes four release nodes: basic information, medium, operation and execution node; among them, the basic information includes container type, business, module and whether to pause. Whether to pause here is an execution action, which is whether to pause the release task; the medium includes yaml files, image files and template sets; the process includes API interface, where the API interface can be BCS API interface. BCSAPI interface refers to the API access layer that the platform provides services to the outside world, which is responsible for forwarding user requests to the corresponding k8s cluster, so it can also be called k8s API interface here; execution nodes include k8s cluster and namespace.

[0075] It should be noted that the target release process of a cloud-native architecture includes all resource information released by each engineering change under the cloud-native architecture application. The release nodes in the release process are flexibly arranged and combined according to the different engineering release information of each application. In the scenario of public massive resource application change release, it can meet diverse release and deployment needs and improve the efficiency of public cloud massive resource change release.

[0076] In another possible implementation, the architecture to be executed may include a traditional architecture and a cloud-native architecture. Accordingly, the release process corresponding to the architecture to be executed is classified based on the preset task template to determine the target release process corresponding to the architecture to be executed, including:

[0077] Determine a first publishing process of at least one application publishing request under a traditional architecture and a second publishing process under a cloud native architecture;

[0078] The first release process and the second release process are classified based on the preset task template to determine the target release process corresponding to the hybrid architecture of the traditional architecture and the cloud native architecture.

[0079] In the embodiment of the present application, a unified release task template is used to complete the hybrid orchestration of cloud-native architecture and traditional architecture. In the scenario of public cloud massive resource application change release, it can meet diverse release and deployment needs and improve the efficiency of public cloud massive resource change release.

[0080] In yet another embodiment of the present application, Figure 4 A schematic diagram of a method for publishing an application provided in an embodiment of the present application Figure 2 After determining the target release process of the architecture to be executed, the target release process is orchestrated to determine the target orchestration engine result corresponding to at least one application release request, see Figure 4 , the method may include:

[0081] S401, determining the task-step-node topology structure corresponding to the target release process.

[0082] In an embodiment of the present application, in order to meet the needs of complex application release scenarios with massive resources in public clouds, it is necessary to build a unified release task template orchestration engine for pending architecture applications, such as a unified release task template engine for traditional architecture applications and cloud native architectures. After obtaining the node information corresponding to the target release process of the pending architecture, the release task corresponding to the entire application release request is abstracted into at least one task. For each task, it includes multiple states: pending release, queued, released, suspended, error, and completed. For a task, it includes multiple release nodes, which can also be referred to as nodes here. These multiple nodes are orchestrated to determine the steps corresponding to these multiple nodes. That is to say, for a task, it can include different execution logics for determining multiple nodes. Thus, a task-step-node topology corresponding to the target release process is constructed. Here, step is an execution action, such as parallel execution between two release nodes, or serial execution, etc.

[0083] S402 , configuring the execution order of each task, step, and node in at least one application publishing request based on the topological hierarchy of the task-step-node topological structure, and generating a target orchestration engine result.

[0084] In an embodiment of the present application, each task, step and node is configured for execution order. For example, under one task, for the release node of the traditional architecture, different release nodes can perform one-way serial execution and / or parallel execution logic; for the release node of the cloud native architecture, gray release and / or blue-green release can be performed between different release nodes; there is no specific limitation on this, and it is determined according to the actual situation; in addition, it can also be determined whether each release node is started in real time or scheduled, so as to determine the orchestration engine results corresponding to multiple release nodes. In addition, node is a clear release type. For traditional release operations, standard operation and maintenance (Standard Operation Procedures System, SOPS) and task processes are executed, and for cloud native architecture, BCS-API is called to perform application release work. Here, the release node can also be referred to as a node. In an embodiment of the present application, the task-step-node topology structure can also be referred to as a unified release task template orchestration engine.

[0085] In an embodiment of the present application, based on the topological level of task-step-node, the calculation of task status is more accurate and fast by using a preset algorithm (such as a single tree depth traversal algorithm). By obtaining the status information of all publishing nodes in the scheduling service pool (Pool), cumulative loading and real-time calculation are performed layer by layer, and the publishing status of each publishing node, each step and each task is obtained and presented to the user through a visual page, which not only reduces the loss and pressure of the database reading library, but also further improves the real-time performance of the publishing status results, and also lays the results out to the user through a visual page for display, so that even under the massive resources of the public cloud, the observability of each resource publishing result can be achieved at a glance. At the same time, the topological level of task-step-node supports very flexible business expansion, and users can customize and combine the expansion of traditional host publishing nodes, cloud native publishing nodes and extended database publishing nodes, and dynamically configure the publishing nodes, with good scalability.

[0086] For example, Figure 5 A schematic diagram of the composition of a task-step-node topology structure provided in an embodiment of the present application. Figure 5 As shown, the solid arrows represent the issuance and execution of tasks, and the dotted arrows represent the current step in which the node feeds back its own publishing status to the next level. For a task, it may include step 1, step 2, step 3, ..., step N; the corresponding nodes under step 1 and step 2 are used for exemplary explanation, step 1 may include node1-1, and step 2 may include node2-1 and node2-2; wherein, step 1 is the serial execution of node1-1, calling SOPS to publish the application under the traditional architecture of node1-1, that is, calling SOPS to publish the target publishing address included in node1-1; step 2 is the concurrent execution of node2-1 and node2-2, and the corresponding call data is used for application publishing, for example, node2-1 corresponds to yaml file, and node2-2 corresponds to SOPS. Here, the publishing node can be a regional node, such as Q City, W City, etc. Each publishing node corresponds to a regional node to be published, and the division of regions can be determined according to actual conditions. In addition, Figure 5 This is only an example, and the publishing task template orchestration engine corresponding to the architecture to be executed is determined according to the actual situation.

[0087] An embodiment of the present application provides an application publishing method, which uses a unified publishing task orchestration engine and is composed of a three-level task orchestration engine that arranges a group of tasks, steps, and nodes. For publishing tasks of massive publishing nodes in public clouds, users can customize extended host publishing nodes, cloud native publishing nodes, and SQL publishing nodes, etc. At the same time, the resources, nodes, and modules to be published are visualized, thereby improving the efficiency of comparison and verification between operation and maintenance operators and the publishing list.

[0088] In another embodiment of the present application, Figure 6 A schematic diagram of a method for publishing an application provided in an embodiment of the present application Figure 3 According to the target orchestration engine result, at least one application publishing request corresponding to the to-be-published data is published, such as Figure 6 As shown, the method may include:

[0089] S601, registering the correspondence between the medium and the execution object in the target publishing process and the target orchestration engine result to the scheduling pool in the form of a task queue, and storing the task queue of the scheduling pool to a preset database.

[0090] In the embodiment of the present application, the task queue is constructed based on the media and execution objects in the target publishing process and the target orchestration engine result. Specifically, the media and execution objects in the target publishing process and the target orchestration engine result execute the message queue (MQ) to obtain the task queue.

[0091] In the embodiment of the present application, the preset database may be a remote dictionary server database (Remote Dictionary Server, Redis). Redis includes high-speed memory access, rich data type support, atomicity of transaction operations, and features when used as a cache message, such as automatically deleting data by setting an expiration time by key, which makes Redis perform particularly well when processing frequent read operations, and using Redis can improve the efficiency of application publishing.

[0092] It should be noted that in high-load situations, such as when massive amounts of data need to be published, MQ can be used to buffer and regulate traffic; by buffering requests and gradually processing them, MQ can help smooth system load fluctuations, prevent the system from being overwhelmed by sudden requests, and improve the stability and reliability of application publishing, especially when processing a large number of concurrent requests. Moreover, MQ can classify and filter different messages to achieve more fine-grained control and management, which helps to better organize and manage message flows and improve the maintainability and scalability of the system.

[0093] In a specific embodiment, after executing the message queue (MQ) to obtain the task queue, the guardian node is also required to monitor the running status of the MQ. For example, the guardian node will regularly check the running status of the MQ service, including the status of the queue, the number of messages, the number of connections, etc. Once a service abnormality or insufficient resources (such as memory, disk space, etc.) is found, the guardian node will immediately issue a warning or trigger a corresponding recovery mechanism. For example, the guardian node will record the running log of the MQ, including various events, errors and warning information. For example, the guardian node will screen the data in the task queue, and remove the task data of the task that has been lost and the task data of the task that has timed out, etc. In other words, the task queue can be better executed stably through the guardian node.

[0094] In the embodiment of the present application, the arranged release resource information such as each task, the node corresponding to each task, the host host, the yaml file container, etc. is registered in the service scheduling pool (referred to as "scheduling pool") for the scheduling center to call. Here, the host host refers to a computer or device connected to the network and capable of communicating with other devices. Each host host has a unique IP address for identification and positioning in the network.

[0095] S602: Pull task data corresponding to the first application publishing request from a task queue in a preset database.

[0096] In the embodiment of the present application, by injecting data into a preset database, such as Redis, Redis stores data in memory, and has a very fast read and write speed, which can process more than 100,000 read and write operations per second, so it can process a large number of requests. And it can publish the request to the front-end interface faster, which helps the user's perception.

[0097] S603: According to the task data, publish the to-be-published data corresponding to the first application publishing request and publish the target application service.

[0098] In an embodiment of the present application, the first application publishing request is any one of at least one application publishing request.

[0099] In the embodiment of the present application, before obtaining the application publishing request, a unified publishing task template executes the engine task template. Figure 7 A schematic diagram of the structure of an execution engine for application release provided by this application. Figure 7As shown, the execution engine includes a service center 701, a scheduling pool 702, a Redis 703, a scheduling center 704, an MQ 705, and a guardian node 706. Among them, the service center 701 obtains the application publishing request triggered by the user and processes the application publishing request. The service center 701, as a task message processing unit, completes the data association, resource calculation and other capabilities of task, step and node, and specifically includes two parts of newspaper and periodical services: orchestration service and basic service. The orchestration service here is composed of task, step and node, which is mainly the process orchestration information (such as the order of execution of each node and the dependency relationship between steps); the basic service can be understood as the deadline and execution object in the target publishing process, including host information, program packages, template sets, yaml files, etc., which are mainly data files required for task execution. The service center 701 can be used by the scheduling center 704 by composing the arranged release resource information such as task, step, node, host, yaml file, etc. into the scheduling pool 702. The scheduling center 704, as the brain of the execution engine, is responsible for the unified scheduling and execution of all tasks, steps, nodes, and resources, and refines the task execution to atomic level operations, calculates the association relationship and required time of each task, step, and node, and flexibly schedules it, completes the concurrent execution of massive tasks and resources, and takes into account the release performance and release efficiency. In addition, after executing the MQ storage message execution node information for the orchestration service and basic service in the service center 701, the release task resources are stored in the form of task queues, and the guardian node is used for screening to obtain the medium and execution object in the final target release process and the task queue corresponding to the target orchestration engine result, and store them in Redis 703 for use by the scheduling center 704.

[0100] It should be noted that the service pool is designed with a queue data structure, so that centralized service management and scheduling can be performed on the massive resources and applications of the public cloud, making the service status flow more clear and robust, ensuring the reliability of the entire task scheduling performance, and improving the execution speed of published tasks by directly calculating the atomic operations of the disassembled tasks in memory. The orderly use of each published resource is guaranteed through the resource lock design, making the allocation and use of resources more controllable.

[0101] For example, Figure 8 A schematic diagram of a processing flow of a scheduling pool provided in an embodiment of the present application. Figure 8As shown, the flowchart may include a scheduling pool 702, a memory 801, a resource lock 802, a Redis 703, a MySQL 803 and a distributed memory object cache system (Memcache) 804; wherein Redis is used as a memory database for fast access and temporary storage of data; MySQL is used as a relational database for persistent storage of data and supports complex queries and transaction processing. Specifically, the tasks to be scheduled in the scheduling pool 703 are stored in a queue (i.e., a task queue) of the scheduling pool 703 in a certain order (e.g., first come first served, priority expedited, etc.) to ensure the orderly progress of the tasks, and the data is written into the memory 801, and the data is written from the memory 801 into the Redis 703. When the data needs to be accessed, it can be obtained from the Redis 703 first. In order to improve the execution order of the published tasks, the atomic operations of the disassembled tasks are directly calculated in the memory 801, thereby improving the task processing speed. In addition, through the design of the resource lock 802, the task data in the task queue can be ensured to be accessed in an orderly manner, that is, only one task can access a certain resource at the same time, avoiding resource competition and conflict. Moreover, through the lock mechanism such as lock and unlock, the system can accurately control the allocation and use of resources, ensure the effective use of resources and avoid waste, and in some cases, the resource lock may be used to control the access order or allocation strategy of specific resources. When these resources are cached in Redis 703 or a distributed memory object cache system (Memcache) 804, the lock mechanism can ensure the reasonable allocation and synchronous access of resources. When Memcache is used as a backup of Redis, the resource lock mechanism may also involve the process of fault recovery and data synchronization. For example, when Redis 703 fails, the system may need to use a lock mechanism to ensure consistency when restoring data from Memcache 804 or other backups. Moreover, in the user's front-end interface, the data stored in Redis 703 can be read first and displayed to the front-end interface for the user to watch. And the data flow from Redis to MySQL is bidirectional according to actual needs. For example, in some cases, it may be necessary to import data in MySQL into Redis as a cache to improve data access speed. At the same time, when the data in Redis changes, it is also necessary to synchronize these changes back to MySQL to maintain data consistency.

[0102] It should also be noted that in the embodiments of the present application, in accordance with the concept of everything as a service, the complex process orchestration logic and various types of basic publishing plug-ins are disassembled; large operations are converted into smaller atomic operations, making the application publishing function more streamlined and stable; and atomic operations are executed as the smallest subtask, which consumes less memory and central processing unit (CPU) performance, that is, under low system configuration, application publishing can also proceed normally.

[0103] In the embodiments of the present application, compared with the publishing tools in the related art, the problems of manual publishing or mixed use of multiple tools are avoided by unifying the publishing process, and by means of unified specifications and unified management, etc., the stability of application publishing is improved, and the failures caused by application changes are reduced, thereby reducing the economic losses caused by failures. In other words, the publishing tasks of multiple different tools are converted into unified distributed publishing tasks, which reduces the difficulty and cost of user use, and through the unique publishing orchestration engine and execution engine, the publishing time is reduced by more than half, the efficiency of change publishing is improved, and the purpose of reducing costs and increasing efficiency is achieved.

[0104] In some embodiments, the method may include: determining at least one regional node corresponding to the first application release request; querying the target release location corresponding to at least one regional node from the configuration management database; and publishing the to-be-released data corresponding to the first application release request based on the task data and the target release location corresponding to at least one regional node.

[0105] In an embodiment of the present application, for the front-end interface, the user can determine the regional node to be sent, or it can be called a resource pool, such as City A. The back-end can obtain the target publishing address related to the regional node from the CMDB, such as all the host IPs under City A, thereby avoiding the impact of changes in the underlying host IP on the pipeline template, reducing the large amount of underlying resource inspection work that the change release personnel have to do each time, and improving the timeliness of change release.

[0106] It should be noted that the CMDB pre-stores data related to the application release request. When the user triggers the application release request and selects a specific regional node, the information related to the regional node can be queried from the CMDB to determine the final target release location. It should be noted that the target release location can include at least one selected release host IP.

[0107] The embodiment of the present application provides an application publishing method and a unified publishing task template execution engine, which completes the publishing task execution supporting traditional host architecture and cloud native architecture through a scheduling center, a service center, a guardian node, a scheduling pool, Redis storage task information and MQ storage execution node information, and supports the concurrent execution of massive public cloud resources, multiple tasks, and multiple publishing methods. In this way, the efficiency of application publishing can be improved in the scenario where massive resources are released at the same time.

[0108] In another embodiment of the present application, based on the application publishing method of the aforementioned embodiment, the present application provides an application publishing method that supports both traditional architecture and cloud native architecture. The method first defines a unified publishing node (i.e., target publishing process) to be compatible with the publishing process of the traditional architecture and the publishing process of the cloud native architecture, wherein the publishing process of the traditional architecture is composed of modules, program packages, standard operation and maintenance, hosts, etc.; the publishing process of the cloud native architecture is composed of modules, template sets, namespaces, etc.; the method supports separate and mixed orchestration of traditional architecture and cloud native architecture in the publishing task template. Specifically, by unifying the orchestration engine and execution engine of the traditional architecture and the cloud native architecture to meet the complex change release scenarios of the massive application resources of the public cloud, it can simultaneously support the multi-task, multi-project, multi-resource pool, and multi-node hybrid orchestration release pipeline of traditional binary files and cloud native applications. The orchestrated pipeline template is associated and bound with the business topology of the CMDB, and is not directly associated with the business host IP, thereby avoiding the impact of the underlying host IP change on the pipeline template, reducing the large amount of underlying resource inspection work of the change release personnel each time, and improving the change release timeliness.

[0109] In the embodiments of the present application, Fig. 9 A schematic diagram of the architecture of an application release provided for the implementation of this application. Fig. 9As shown, the architecture includes an application system 901, an orchestration engine 902, an execution engine 903, and a scheduling engine 904. Among them, the application system 901 includes traditional architecture application release, cloud native architecture application release, and evil soul box architecture application release, that is, the method can release applications for traditional architecture and cloud native architecture separately, or can release applications for a mixture of the two architectures; through the unified orchestration engine 902 (i.e., the topological structure of task-step-node), the cloud native architecture structure and the traditional architecture can be separately orchestrated (i.e., step one and step two), and the mixed orchestration of cloud native organizations can also be realized (i.e., step three); through the scheduling center, service center, daemon node, and MQ in the execution engine 903, the tasks released by the application can be allocated, and the tasks can be allocated to the corresponding execution units according to the specific requirements of the tasks. The scheduling pool, Redis, MySQL, and machine memory (i.e., memory 801) in the scheduling engine 904 are responsible for the allocation of tasks and the optimization of resources in the application release to improve the overall performance and efficiency of the system. In this way, after implementing a unified orchestration of release task templates, it is necessary to build a unified release task execution engine, which uses step and node to schedule standard operation and maintenance processes and BCS APIs to meet a variety of business release requirements. It can meet both traditional host release requirements and cloud native container release requirements, and also support the hybrid release requirements of host + container.

[0110] In some embodiments, for Fig. 9 The application publishing architecture shown in the figure, the application publishing method provided by the embodiment of the present application includes the following steps:

[0111] Step 1: uniformly define the release node of the application release task template (ie, the preset task template).

[0112] The concepts of traditional architecture release include: process, binary package, configuration file, execution script and process, and release host list; the concepts of cloud native architecture release include: container (pod), yaml file, image, k8s API, k8s cluster and namespace. By abstracting the release process of the two architectures: application information, medium, process, object, and define application information through CMDB business-module; abstracting processes, binary packages, configuration files, yaml files, template sets, and images as media; unifying host execution processes (execution scripts and processes) and BCS API (i.e. k8s API) calls as operations; unifying hosts and k8s clusters and namespaces as objects. By associating and binding the release task template with the business topology of CMDB, instead of directly associating it with the business host IP, the impact of changes in the underlying host IP on the pipeline template is avoided, reducing the large amount of underlying resource inspection work of change release personnel each time, and improving the timeliness of change release.

[0113] Step 2: Build a release process for the traditional architecture.

[0114] By abstracting and transforming the traditional architecture application process, and then constructing the target release process of the traditional architecture, it can be seen from step 1 that the target release process of the traditional architecture after abstraction is composed of the following parts: basic information, media, process and execution node; basic information: host type, business, module, node name and whether it is suspended; media: program package and configuration file; operation and standard operation and maintenance, execution task flow and script file; execution node and CMDB business-module binding host information (that is, the selected release host address). A traditional architecture release process includes all resource information released by each engineering change under the traditional architecture application. The release nodes in the release process can be flexibly arranged and combined according to the different engineering release information of each application. For details, see Figure 2 .

[0115] Step 3: Build a release process for the cloud-native architecture.

[0116] By abstracting and transforming the cloud native architecture application process, we can build the target release process of the cloud native architecture. From step 1, we know that the target release process of the cloud native architecture after abstraction consists of the following parts: basic information, medium, process and execution node; basic information: container type, business, module, node name and whether to pause; medium: yaml file, image and template set; operation: BCS API interface; execution node: k8s cluster and namespace. A cloud native architecture release process includes all resource information released by each engineering change under the cloud native architecture application. The release nodes in the release process can be flexibly arranged and combined according to the different engineering release information of each application. For details, see Figure 3 .

[0117] Step 4: Unified publishing task template orchestration engine.

[0118] In order to meet the needs of complex application release scenarios with massive resources in public clouds, it is necessary to build a unified release task template orchestration engine for traditional architecture applications and cloud native architecture applications. Through steps 2 and 3, the construction of engineering application node information based on traditional architecture and cloud native architecture can be completed, and all release tasks of the entire application can be abstractly defined as tasks. Among them, tasks have multiple states: waiting to be released, queued, released, paused, error, completed, etc. Each task is divided into different steps, and the steps support single-layer serial and parallel logic, as well as different scheme designs of real-time startup and scheduled startup. For details, see Figure 5 .

[0119] Below step are different nodes, which are the release nodes in the target release process of the traditional architecture and cloud native architecture described in step 2 and step 3. There are also single-layer serial and parallel logic between different nodes, and both support real-time startup. Through the logical judgment of whether to pause after execution, it meets the scenario of manually checking the release status and results of the node after execution. As a clear release type, node executes SOPS and task flow for traditional host release operations, and calls BCS-API for application release for cloud native architecture.

[0120] Based on the task-step-node topology level, the calculation of task status is more accurate and faster by using preset algorithms (such as single tree depth traversal algorithm). By obtaining the status information of all publishing nodes in the scheduling service pool (Pool), cumulative loading and real-time calculation are performed layer by layer, and the publishing status of each publishing node, each step and each task is obtained and presented to the user through a visual page. This not only reduces the loss and pressure of database reading, but also further improves the real-time performance of the publishing status results. In addition, the results are flattened to the user through a visual page for display. In this way, even with massive resources in the public cloud, the publishing results of each resource can be clearly observable. At the same time, the task-step-node topology level supports very flexible business expansion. Users can customize and combine the expansion of traditional host publishing nodes, cloud native publishing nodes, and extended database (SQL) publishing nodes, and dynamically configure publishing nodes, which has good scalability.

[0121] Step 5: Unified publishing task template execution engine.

[0122] Through the self-developed unified release task template execution engine, the task templates arranged in step 4 are executed in an orderly manner according to the arranged pipeline sequence. Figure 7As shown in the figure, its components include: scheduling center, service center, guardian node, scheduling pool, Redis storage task information, MQ storage execution node information. Among them, the service center, as a task information processing unit, completes the data association, resource calculation and other capabilities of tasks (task), (step), and publishing nodes (node). The services included are divided into two parts: "Orchestration Service" + "Basic Service". The orchestration service consists of tasks (task), (step), and publishing nodes (node), which are mainly process orchestration information, including the order of execution, the dependency relationship between steps, etc. The basic service consists of host information, program packages, template sets, yaml files, etc., which are mainly basic service information such as media files required for task execution. By putting the orchestrated publishing resource information such as task, step, node, host, yaml registration, etc. into the scheduling pool, it can be used for scheduling by the scheduling center. The scheduling center serves as the brain of the execution engine. It is responsible for the unified scheduling and execution of all tasks, steps, nodes, and resources. It breaks down task execution into atomic-level operations, calculates the relationships and required time of each task, step, and node, and flexibly schedules them to complete the concurrent execution of massive tasks and resources, while taking into account both release performance and efficiency.

[0123] Step 6: Design release task scheduling that takes into account both speed and performance.

[0124] In accordance with the concept of everything as a service, the complex process orchestration logic and various types of basic release plug-ins are disassembled; huge operations are converted into smaller atomic operations. This makes the application release function more streamlined and stable, and atomic operations are executed as the smallest subtask, which consumes less memory and CPU performance. That is, the release can proceed normally under very low system configuration.

[0125] The service pool is designed with a queue data structure to centrally manage and schedule the massive resources and applications of the public cloud, making the service status flow clearer and more robust, and ensuring the reliability of the entire task scheduling performance. The execution speed of the release task is improved by directly calculating the atomic operations of the disassembled tasks in memory, and the orderly use of each release resource is guaranteed through the resource lock design, making the allocation and use of resources more controllable; see Figure 8 .

[0126] In some embodiments, a custom Ansible plug-in can be written to call the native interface of k8s for encapsulation to meet the release support for cloud-native architecture applications; custom design can also be used to simultaneously meet the application release scenarios that support traditional architecture and cloud-native architecture. The user integrates Ansible and k8s container release native interfaces, uses the task orchestration page to integrate release resources, and completes task execution by calling a combination of Ansible and k8s container release interfaces.

[0127] That is to say, the application publishing method provided by the present application can be compatible with the application publishing supporting traditional architecture and cloud native architecture, which can meet the publishing requirements of traditional hosts and cloud native containers, and also support the hybrid publishing requirements of hosts + containers, that is, the application publishing method provided by the present application has a flexible and scalable architecture, and the supported objects have flexible expansion space based on actual needs. Moreover, the embodiment of the present application can simultaneously support the hybrid orchestration and release pipeline of multi-task, multi-project, multi-resource pool, and multi-node of traditional binary files and cloud native applications. The orchestrated release pipeline template is associated and bound with the business topology of CMDB, and is not directly associated with the business host IP, avoiding the impact of the underlying host IP change on the pipeline template, reducing the large amount of underlying resource inspection work of the change release personnel each time, and improving the change release timeliness. In addition, the embodiment of the present application makes the change release task more fine-grained and more accurate in the scheduling of steps and nodes by designing the release task template orchestration engine, execution engine, and task scheduling, and has better performance than Ansible and Argo CD in the related technology, especially in the scenario where a large number of massive resources are released at the same time, the release timeliness can be improved by more than 50%.

[0128] The embodiment of the present application provides an application publishing method. The specific implementation of the aforementioned embodiment is elaborated in detail through the above embodiment. It can be seen that the embodiment of the present application proposes an application publishing method that supports both traditional architecture and cloud native architecture. Through a unified publishing task template orchestration engine, the hybrid orchestration and release of cloud native architecture and traditional host architecture applications are completed, meeting the diversified publishing and deployment requirements in the public cloud massive resource application change release scenario, and improving the efficiency of public cloud massive resource change release; and through a unified publishing task orchestration engine, that is, by setting a three-level task orchestration engine that orchestrates a group of task, step, and node to form a publishing task for a public cloud massive publishing node, users can customize extended host publishing nodes, cloud native publishing nodes, sql publishing nodes, etc., and at the same time, the resources, nodes, and modules to be released are visualized, thereby improving the efficiency of comparison and verification between operation and maintenance operators and the release checklist. In addition, this application proposes a unified release task template execution engine, which supports the release task execution of traditional host architecture and cloud native architecture through self-designed scheduling center, service center, guardian node, scheduling pool, Redis storage task information and MQ storage execution node information, and supports the concurrent execution of massive public cloud resources, multiple tasks, and multiple release methods.

[0129] Based on the same inventive concept as the above embodiments, Fig.10 A schematic diagram of the structure of an application publishing device provided in an embodiment of the present application. Fig.10As shown, the application publishing device 100 includes a determining unit 1001, an arrangement unit 1002 and a publishing unit 1003, wherein:

[0130] The determination unit 1001 is used to determine the to-be-published data corresponding to the at least one application publishing request and the publishing process corresponding to the to-be-executed architecture in response to at least one application publishing request; classify the publishing processes corresponding to the to-be-executed architecture based on a preset task template, and determine the target publishing process corresponding to the to-be-executed architecture;

[0131] The orchestration unit 1002 is used to perform orchestration processing on the target publishing process and determine a target orchestration engine result corresponding to at least one application publishing request;

[0132] The publishing unit 1003 is used to publish the to-be-published data corresponding to at least one application publishing request according to the target orchestration engine result.

[0133] In some embodiments, Fig.10 As shown, the application publishing device may also include a construction unit 1004, which is used to perform abstract processing based on the publishing processes corresponding to at least two architectures to generate a preset task template; wherein, the at least two architectures include a traditional architecture and a cloud-native architecture, and the preset task template includes basic information, media, processes and execution nodes.

[0134] In some embodiments, when the architecture to be executed includes a traditional architecture, the determination unit 1001 is further used to determine a first release process of at least one application release request under the traditional architecture, the first release process including at least a host type, a business, a module, a node name, a program package, a configuration file, a database file, basic operation and maintenance, an execution task flow, a script file and a selected release host address; the construction unit 1004 is further used to classify the first release process based on a preset task template to determine a target release process corresponding to the traditional architecture; wherein, in the target release process corresponding to the traditional architecture, the basic information includes the host type, the business, the module and the node name, the medium includes the program package, the configuration file and the database file, the process includes the basic operation and maintenance, the execution task flow and the script file, and the execution node includes the selected release host address.

[0135] In some embodiments, when the architecture to be executed includes a cloud native architecture, the determination unit 1001 is also used to determine a second release process of at least one application release request under the cloud native architecture, and the second release process includes at least: container type, business, module, node name, image file, template set, application programming interface, orchestration tool cluster and namespace; the construction unit 1004 is also used to classify the second release process based on the preset task template to determine the target release process corresponding to the cloud native architecture; wherein, in the target release process corresponding to the cloud native architecture, the basic information includes: container type, business, module and node name, the medium includes image file and template set, the process includes application programming interface, and the execution node includes orchestration tool cluster and namespace.

[0136] In some embodiments, the orchestration unit 1002 is further used to determine the task-step-node topology structure corresponding to the target release process; configure the execution order of each task, step and node based on the topological hierarchy of the task-step-node topology structure, and generate a target orchestration engine result.

[0137] In some embodiments, see Fig.10 The application publishing device 100 may also include a scheduling unit 1005, which is used to register the media and execution objects in the target publishing process and the target orchestration engine results in the scheduling pool in the form of a task queue, and store the task queue of the scheduling pool in the remote dictionary service database; pull the task data corresponding to the first application publishing request from the task queue of the remote dictionary service database; the publishing unit 1003 is also used to publish the to-be-published data corresponding to the first application publishing request according to the task data; wherein the task queue is constructed based on the media and execution objects in the target publishing process and the target orchestration engine results, and the first application publishing request is any one of the at least one application publishing request.

[0138] In some embodiments, the determination unit 1001 is further used to determine at least one regional node corresponding to at least one application publishing request based on the target orchestration engine result; and to query the target publishing location corresponding to at least one regional node from the configuration management database; the publishing unit 1003 is further used to publish the to-be-published data corresponding to the first application publishing request based on the task data and the target publishing location corresponding to at least one regional node.

[0139] In yet another embodiment of the present application, Fig.11 This is a schematic diagram of a specific hardware structure of an electronic device provided in an embodiment of the present application. Fig.11As shown, the electronic device 110 may include: a communication interface 1101, a memory 1102 and a processor 1103; each component is coupled together via a bus system 1104. It is understood that the bus system 1104 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 1104 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Fig. 9 Various buses are labeled as bus system 1104. Among them, the communication interface 1101 is used for receiving and sending signals in the process of sending and receiving information between other external network elements;

[0140] A memory 1102, used for storing a computer program that can be run on the processor 1103;

[0141] The processor 1103 is configured to execute, when running the computer program:

[0142] In response to at least one application publishing request, determine the to-be-published data corresponding to the at least one application publishing request and the publishing process corresponding to the to-be-executed architecture; classify the publishing process corresponding to the to-be-executed architecture based on a preset task template, and determine the target publishing process corresponding to the to-be-executed architecture; orchestrate the target publishing process, and determine the target orchestration engine result corresponding to the at least one application publishing request; and publish the to-be-published data corresponding to the at least one application publishing request according to the target orchestration engine result.

[0143] It can be understood that the memory 1102 in the embodiment of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus random access memory (DRRAM). The memory 1102 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0144] The processor 1103 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 1103. The above-mentioned processor 1103 can be a general-purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware decoding processor to execute, or the hardware and software modules in the decoding processor are combined and executed. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 1102, and the processor 1103 reads the information in the memory 1102 and completes the steps of the above method in combination with its hardware.

[0145] It is understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in the present application, or a combination thereof.

[0146] For software implementation, the techniques described herein can be implemented by modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0147] Optionally, as another embodiment, the processor 1103 is further configured to execute the steps of the method described in any one of the aforementioned embodiments when running the computer program.

[0148] In some embodiments, the embodiments of the present application further provide an electronic device 110, which may at least include the application publishing device 100 described in any one of the aforementioned embodiments.

[0149] The description of the above device and equipment embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the device embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

[0150] It can be understood that in this embodiment, a "unit" can be a part of a circuit, a part of a processor, a part of a program or software, etc., and of course it can also be a module, or it can be non-modular. Moreover, the components in this embodiment can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional module.

[0151] In this embodiment, if the integrated unit is implemented in the form of a software function module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment is essentially or the part that contributes to the prior art or the whole or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the method described in this embodiment. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.

[0152] An embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps of the method described in any one of the aforementioned embodiments are implemented.

[0153] An embodiment of the present application also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implements the steps of the method described in any of the aforementioned embodiments.

[0154] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, devices, equipment, or computer program products. Therefore, the present application may adopt the form of hardware embodiments, software embodiments, or embodiments in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) that contain computer-usable program code.

[0155] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0156] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0157] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0158] It should be noted here that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0159] It should be noted that, in this application, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, product or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, product or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, product or device including the element.

[0160] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0161] The methods disclosed in several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0162] The features disclosed in several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0163] The features disclosed in several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0164] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. An application publishing method, characterized in that: The method comprises: In response to at least one application publishing request, determining the publishing process corresponding to the to-be-published data and the to-be-executed architecture corresponding to the at least one application publishing request; Classify the release process corresponding to the architecture to be executed based on the preset task template, and determine the target release process corresponding to the architecture to be executed; Performing orchestration processing on the target publishing process to determine a target orchestration engine result corresponding to the at least one application publishing request; According to the target orchestration engine result, the to-be-published data corresponding to the at least one application publishing request is published.

2. The method according to claim 1, characterized in that The method comprises: Perform abstract processing based on the release processes corresponding to at least two architectures to generate preset task templates; Among them, the at least two architectures include a traditional architecture and a cloud-native architecture, and the preset task template includes basic information, media, processes and execution nodes.

3. The method according to claim 2, characterized in that When the architecture to be executed includes the traditional architecture, the classifying and processing the release process corresponding to the architecture to be executed based on the preset task template to determine the target release process corresponding to the architecture to be executed includes: Determine a first publishing process of the at least one application publishing request under the traditional architecture, wherein the first publishing process at least includes: host type, service, module, node name, program package, configuration file, database file, basic operation and maintenance, execution task flow, script file and a selected publishing host address; Classify the first release process based on the preset task template to determine the target release process corresponding to the traditional architecture; Among them, in the target release process corresponding to the traditional architecture, the basic information includes the host type, business, module and node name in the first release process, the medium includes the program package, configuration file and database file in the first release process, the process includes the basic operation and maintenance, execution task flow and script file in the first release process, and the execution node includes the selected release host address in the first release process.

4. The method according to claim 2 or 3, characterized in that: When the architecture to be executed includes the cloud native architecture, the classifying and processing the release process corresponding to the architecture to be executed based on the preset task template to determine the target release process corresponding to the architecture to be executed includes: Determine a second publishing process for the at least one application publishing request under the cloud native architecture, the second publishing process including at least: container type, service, module, node name, image file, template set, application programming interface, orchestration tool cluster and namespace; Classify the second release process based on the preset task template to determine the target release process corresponding to the cloud native architecture; Among them, in the target release process corresponding to the cloud native architecture, the basic information includes the container type, business, module and node name in the second release process, the medium includes the image file and template set in the second release process, the process includes the application programming interface in the second release process, and the execution node includes the orchestration tool cluster and namespace in the second release process.

5. The method according to claim 1, characterized in that The orchestrating the target publishing process to determine the target orchestration engine result corresponding to the at least one application publishing request includes: Determine the task-step-node topology corresponding to the target release process; The execution order of each task, step and node in the at least one application publishing request is configured based on the topological hierarchy of the task-step-node topological structure to generate the target orchestration engine result.

6. The method according to any one of claims 2, characterized in that The step of publishing the to-be-published data corresponding to the at least one application publishing request according to the target orchestration engine result includes: Registering the media and execution objects in the target publishing process and the target orchestration engine result to the scheduling pool in the form of a task queue, and storing the task queue of the scheduling pool to a preset database; Pulling task data corresponding to the first application publishing request from the task queue of the preset database; According to the task data, publishing the to-be-published data corresponding to the first application publishing request; The task queue is constructed based on the medium and execution object in the target publishing process and the target orchestration engine result, and the first application publishing request is any one of the at least one application publishing request.

7. The method according to claim 6, characterized in that The method further comprises: Determine at least one regional node corresponding to the first application publishing request; Querying a target publishing location corresponding to the at least one regional node from a configuration management database; Based on the target publishing location corresponding to the task data and the at least one regional node, the to-be-published data corresponding to the first application publishing request is published.

8. An application publishing device, characterized in that: The application publishing device includes a determination unit, an arrangement unit and a publishing unit, wherein: The determination unit is used to determine the to-be-published data corresponding to the at least one application publishing request and the publishing process corresponding to the to-be-executed architecture in response to at least one application publishing request; classify the publishing processes corresponding to the to-be-executed architecture based on a preset task template to determine the target publishing process corresponding to the to-be-executed architecture; The orchestration unit is used to perform orchestration processing on the target publishing process and determine a target orchestration engine result corresponding to the at least one application publishing request; The publishing unit is used to publish the to-be-published data corresponding to the at least one application publishing request according to the target orchestration engine result.

9. An electronic device, characterized in that: The electronic device comprises a memory and a processor, wherein: The memory is used to store a computer program that can be run on the processor; The processor is configured to execute the method according to any one of claims 1 to 7 when running the computer program.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

11. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images