Argo-based Workflow Continuous Scheduling Method and Device

Abstract

The present invention relates to a method and apparatus for continuous scheduling of workflows based on Argo, including: generating a workflow code file corresponding to an application instance and argo events resources according to a workflow template; wherein the workflow template includes a first workflow script segment and a script segment for triggering a second workflow; the script segment for triggering the second workflow configures the parameter passing method and parameter items when the first workflow passes parameters to the second workflow; and realizing continuous scheduling between the first workflow and the second workflow by using the workflow code file and argo events resources. The present invention generates different workflow instances through the workflow template, solves the problems of single and non-reusable workflows, and reduces the development cost; in addition, the workflow template adds a code segment for triggering the next workflow, solves the problem that the call between workflows needs to be manually executed, and realizes the automatic call of different workflows.

Description

Technical Field

[0001] The present invention relates to the field of container orchestration, and in particular, to a continuous scheduling method and device for workflows based on Argo. Background Art

[0002] Argo (a container-native workflow engine) is an open-source tool for Workflow based on kubernetes CRD (Custom Resource Definition). It realizes the control of workflows and the execution of tasks based on the scheduling capabilities of kubernetes.

[0003] However, Argo focuses on the scheduling of workflow tasks, the scheduling between multiple workflows, and parameter passing, which are mostly achieved manually, consuming labor costs and being unfavorable for the flexibility of scheduling. Summary of the Invention

[0004] The purpose of the present invention is to provide a continuous scheduling method and device for workflows based on Argo, so as to solve the problem of manually implementing the scheduling and parameter passing between multiple workflows, thereby making the scheduling between workflows more flexible.

[0005] In a first aspect, an embodiment of the present invention provides a continuous scheduling method for workflows based on Argo, including:

[0006] Obtain a workflow template; wherein, the workflow template includes a first workflow script segment and a script segment for triggering a second workflow; the script segment for triggering the second workflow configures the parameter passing method and parameter items when the first workflow passes parameters to the second workflow;

[0007] Generate a workflow code file corresponding to the application instance and argo events resources according to the workflow template;

[0008] Utilize the workflow code file and the argo events resources to achieve continuous scheduling between the first workflow and the second workflow.

[0009] According to the continuous scheduling method for workflows based on Argo provided by the present invention, the first workflow script segment defines the tasks of the first workflow and the dependencies between the tasks through container orchestration; the tasks include task names, task parameters, task parameter values, and task execution logics;

[0010] The parameter passing method is to call the webhook interface through the API address of the webhook interface in the curl command, so as to use the webhook interface to achieve parameter passing between the first workflow and the second workflow;

[0011] The first workflow script segment and the script segment that triggers the second workflow edit the application instance number used to refer to the application instance;

[0012] In the workflow template, the API address, application instance number, and task parameter value of the webhook interface in the curl command are all filled with parameter placeholders.

[0013] According to the Argo-based workflow continuous scheduling method provided by the present invention, the generating the workflow code file and argo events resources corresponding to the application instance according to the workflow template includes:

[0014] Binding the workflow template to the application instance to obtain an instantiated workflow template;

[0015] Invoking the argo events service through the workflow service interface, so that the argo events service creates the argo events resources corresponding to the application instance according to the instantiated workflow template; wherein, the argo events resources include: scheduled tasks, first triggers, second triggers, and webhook interfaces;

[0016] Replacing the API address of the webhook interface given by the curl command with the API address of the created webhook interface, thereby obtaining the workflow code file corresponding to the application instance;

[0017] Among them, the first trigger has the function of monitoring the scheduled task and triggering the execution of the first workflow;

[0018] The second trigger has the function of monitoring the created webhook interface and triggering the execution of the second workflow.

[0019] According to the Argo-based workflow continuous scheduling method provided by the present invention, the binding the workflow template to the application instance to obtain an instantiated workflow template includes:

[0020] When receiving the workflow template and application instance binding instruction, automatically generating an application instance number for the application instance;

[0021] Replacing the application instance number in the workflow template with the generated application instance number, and at the same time replacing the task parameter value in the workflow template with the task parameter value in the application instance to obtain an instantiated workflow template.

[0022] According to the Argo-based workflow continuous scheduling method provided by the present invention, the scheduled task, the first trigger, the second trigger, and the created webhook interface are respectively named in the format of application instance number - scheduled task, application instance number - first trigger, application instance number - second trigger, and application instance number - webhook interface.

[0023] According to the Argo-based workflow continuous scheduling method provided by the present invention, after creating the scheduled task corresponding to the application instance, it further includes:

[0024] Configure a cron expression for the scheduled task;

[0025] Wherein, the cron expression is used to instruct the scheduled task to issue an execution instruction.

[0026] According to the Argo-based workflow continuous scheduling method provided by the present invention, the realization of continuous scheduling between the first workflow and the second workflow by using the workflow code file and the argo events resource includes:

[0027] When the cron expression is satisfied, call the workflow service interface to start the scheduled task so that the scheduled task issues an execution instruction;

[0028] When the first trigger monitors the execution instruction, use the first trigger to trigger the execution of the first workflow; wherein, the trigger of the execution of the first workflow is realized by triggering the workflow code file, and when the workflow code file is triggered, each task in the first workflow is executed in sequence, and after the tasks in the first workflow are executed, call the Webhook interface to pass parameters to the second workflow;

[0029] When the second trigger monitors that the parameter passing of the Webhook interface is completed, use the second trigger to trigger the execution of the second workflow.

[0030] In a second aspect, the present invention further provides an Argo-based workflow continuous scheduling device, and the device includes:

[0031] An acquisition module, configured to acquire a workflow template; wherein, the workflow template includes a first workflow script segment and a script segment for triggering the second workflow; the script segment for triggering the second workflow configures the parameter passing method and parameter items when the first workflow passes parameters to the second workflow;

[0032] A generation module, configured to generate a workflow code file and argo events resources corresponding to the application instance according to the workflow template;

[0033] A scheduling module, configured to use the workflow code file and the Argo Events resource to implement continuous scheduling between a first workflow and a second workflow.

[0034] In a third aspect, the present invention further provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the steps of the Argo-based workflow continuous scheduling method as described in the first aspect are implemented.

[0035] In a fourth aspect, the present invention further provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the Argo-based workflow continuous scheduling method as described in the first aspect are implemented.

[0036] The Argo-based workflow continuous scheduling method and device provided by the present invention prefabricate a workflow template before scheduling; the workflow template adds a task to trigger the second workflow at the end of the first workflow, and stipulates to use the curl command to call the webhook interface to implement the trigger of the second workflow and the transfer of parameters; when formally scheduling, the workflow template is instantiated, that is, a workflow code file and Argo Events resources corresponding to the application instance are generated according to the prefabricated workflow template; among them, the Argo Events resource can be regarded as a task-driven resource allocated for the workflow code file; the instantiation process supports automatic configuration of multiple implementations of a workflow template, solving the defect that traditional workflow configuration must be prefabricated and is not flexible enough. Using the workflow code file and the Argo Events resource, continuous scheduling between the first workflow and the second workflow is implemented. It solves the drawback that the scheduling between traditional workflows is mostly triggered manually, consuming human labor costs, thereby making the scheduling between workflows more flexible and diverse. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained according to these drawings without creative efforts.

[0038] Figure 1 is a schematic flowchart of the Argo-based workflow continuous scheduling method provided by the present invention;

[0039] Figure 2 is an actual execution flowchart of the workflow continuous scheduling provided by the present invention;

[0040] Figure 3It is the technical architecture diagram for the continuous scheduling of the auxiliary workflow provided by the present invention;

[0041] Figure 4 It is the structural schematic diagram of the device for the continuous scheduling of the workflow based on Argo provided by the present invention;

[0042] Figure 5 It is the structural schematic diagram of the electronic device for implementing the method for the continuous scheduling of the workflow based on Argo provided by the present invention. Detailed implementation manners

[0043] To make the objectives, technical solutions and advantages of the present invention clearer, the technical solutions in the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the present invention. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art without making creative efforts based on the embodiments in the present invention belong to the scope of protection of the present invention.

[0044] To facilitate the understanding of the present invention, the following terms are explained.

[0045] Container orchestration: An application generally consists of individually containerized components (usually called microservices) and must be organized at the network level in sequence so that it can operate as planned. The process of organizing multiple containers in this way is called container orchestration.

[0046] argo workflow: A popular container workflow orchestration nowadays, which can be used for task orchestration based on containers.

[0047] argo events: A popular event-driven tool nowadays, which can be used for task driving based on containers. Together with argo workflow, it extends the native functions of Kubernetes and realizes things that native Kubernetes cannot complete.

[0048] Curl: An open-source file transfer tool that works in the command-line mode using the URL syntax.

[0049] Webhook interface: Also known as a reverse API, it is a web callback or an http push API, which is a way to provide real-time information to an APP or other applications.

[0050] Dag: Directed acyclic graph.

[0051] Axios: An HTTP library based on promises. Simply put, it can send get and post requests.

[0052] Echarts: It is a pure JavaScript chart library that is compatible with most browsers. It relies on the lightweight canvas library ZRender at the bottom layer and provides intuitive, vivid, interactive, and highly customizable data visualization charts.

[0053] Spring Cloud: It is a specification for microservice frameworks. Note that it is just a specification and not any specific framework.

[0054] Eureka: Also known as the service center, it manages various service functions including service registration, discovery, circuit breaking, load balancing, and degradation. By using the service center to obtain services, you don't need to worry about the IP addresses of the projects you call. It consists of several servers. You can directly go to the service center to obtain available services for invocation each time.

[0055] Ribbon: It is a user interface with a panel and tabbed page architecture.

[0056] Vue: It is a progressive framework for building user interfaces.

[0057] ElementUI: It is a UI library that does not depend on Vue. However, it is a relatively good UI framework for cooperating with Vue in project development.

[0058] Spring Boot: It is a brand-new framework provided by the Pivotal team, designed to simplify the creation, running, debugging, deployment, etc. of Spring applications. Using Spring Boot, you can focus on the development of Spring applications without paying too much attention to XML configuration.

[0059] Shiro (Apache Shiro): It is a Java security framework with three core components, namely Subject, Security Manager, and Realms.shiro. It can run in web applications, non-web applications, and cluster distributed applications, and is simple and flexible to use.

[0060] JWT is a claim specification, mainly used for a concise and URL-safe representational of passing security information.

[0061] Feign is a declarative and templated HTTP client developed by Netflix. Feign can help us call HTTP APIs more quickly and gracefully.

[0062] The following combines Figures 1 - 5 Describe a workflow continuous scheduling method and device based on Argo provided by the present invention.

[0063] In the first aspect, asFigure 1 As shown in the figure, a continuous scheduling method for workflows based on Argo provided by the present invention includes:

[0064] S11: Obtain a workflow template; wherein, the workflow template includes a first workflow script segment and a script segment for triggering a second workflow; the script segment for triggering the second workflow configures the parameter passing method and parameter items when the first workflow passes parameters to the second workflow;

[0065] To solve the problem of manual scheduling between multiple workflows, the present invention designs a workflow template, adding a task for triggering the next workflow to the traditional workflow template, so that the next workflow is automatically triggered after the completion of the current workflow; wherein, when performing container orchestration on the task for triggering the next workflow, the parameter items passed from the current workflow to the next workflow are declared, and a webhook event is triggered through the curl command to pass the parameters processed by the current workflow.

[0066] The workflow template is pre-configured, and can be in the yaml or json format, and unknown values are filled with parameter placeholders.

[0067] S12: Generate a workflow code file corresponding to the application instance and argo events resources according to the workflow template;

[0068] This step actually instantiates the workflow template to generate a workflow instance (workflow code file) and allocate task-driven resources, completing the container orchestration of each task in the first workflow in the application instance and the task for triggering the second workflow after the execution of the tasks in the first workflow, as well as the corresponding drive resource configuration.

[0069] Using the workflow template, it is possible to easily perform task orchestration of container applications in a short time and complete complex task requirements.

[0070] S13: Use the workflow code file and the argo events resources to achieve continuous scheduling between the first workflow and the second workflow.

[0071] This step can be regarded as the actual execution of the application instance. In argo events, use the workflow code file and the argo events resources to achieve the execution of the first workflow and the triggering of the second workflow;

[0072] It should be noted that after the second workflow is executed, relevant traces need to be cleared to reduce the use of storage resources.

[0073] A continuous scheduling method for workflows based on Argo provided by the present invention prefabricates a workflow template before scheduling; a trigger task for a second workflow is added at the end of the first workflow in the workflow template, and it is stipulated to use the curl command to call the webhook interface to implement the trigger of the second workflow and the transfer of parameters; when formally scheduling, the workflow template is instantiated, that is, a workflow code file corresponding to the application instance and argo events resources are generated according to the prefabricated workflow template; among them, the argo events resources can be regarded as task-driven resources allocated for the workflow code file; the instantiation process supports the automatic configuration of multiple implementations of a workflow template, solving the defect that traditional workflow configurations must be prefabricated and are not flexible enough. Using the workflow code file and the argo events resources, continuous scheduling between the first workflow and the second workflow is realized. It solves the drawback that the scheduling between traditional workflows is mostly triggered manually, consuming human costs, and thus makes the scheduling between workflows more flexible and diverse.

[0074] Based on the above embodiments, as an optional embodiment, the first workflow script segment defines the tasks of the first workflow and the dependencies between tasks through container orchestration; the tasks include task names, task parameters, task parameter values, and task execution logics.

[0075] The parameter passing method is to call the webhook interface through the API address of the webhook interface in the curl command, so as to use the webhook interface to realize the parameter transfer between the first workflow and the second workflow.

[0076] The first workflow script segment and the script segment for triggering the second workflow edit the application instance number used to refer to the application instance.

[0077] The API address of the webhook interface, the application instance number, and the task parameter value in the curl command in the workflow template are all filled with parameter placeholders.

[0078] The workflow template is a general template, which shows how to execute the first workflow, how to trigger the second workflow after the first workflow is completed, and how the first workflow transfers parameters to the second workflow.

[0079] In the present invention, the workflow template supports the automatic configuration of multiple implementations of a workflow template, that is, a workflow template can be bound to different application instances (the application instance is referred to by the application instance number in the code), so as to generate different workflow instances through a workflow template, solving the problems of workflow singleness and non-reusability, and reducing the development cost.

[0080] In addition, the design of the parameter passing method in the workflow template solves the problem that the invocation between workflows needs to be executed manually, and realizes the automatic invocation of different workflows.

[0081] Based on the above embodiments, as an optional embodiment, generating a workflow code file and argo events resources corresponding to the application instance according to the workflow template includes:

[0082] Binding the workflow template to the application instance to obtain an instantiated workflow template;

[0083] Invoking the argo events service through the workflow service interface, so that the argo events service creates argo events resources corresponding to the application instance according to the instantiated workflow template; wherein, the argo events resources include: scheduled tasks, a first trigger, a second trigger, and a webhook interface;

[0084] Replacing the API address of the webhook interface given by the curl command with the API address of the created webhook interface, thereby obtaining a workflow code file corresponding to the application instance;

[0085] Wherein, the first trigger has the function of monitoring the scheduled task and triggering the execution of the first workflow;

[0086] The second trigger has the function of monitoring the created webhook interface and triggering the execution of the second workflow.

[0087] The present invention instantiates the workflow template to complete the container orchestration of each task in the first workflow in the application instance and the tasks of the second workflow triggered after the task execution of the first workflow, and correspondingly allocates the driving resources for the application instance to provide preparations for the execution of the application instance; at the same time, this operation can be completed in a short time with the help of the workflow template to meet complex task requirements.

[0088] Based on the above embodiments, as an optional embodiment, the binding the workflow template to the application instance to obtain an instantiated workflow template includes:

[0089] When receiving the binding instruction of the workflow template and the application instance, automatically generating an application instance number for the application instance;

[0090] Replacing the application instance number in the workflow template with the generated application instance number, and at the same time replacing the task parameter values in the workflow template with the task parameter values in the application instance to obtain an instantiated workflow template.

[0091] In the present invention, by binding a workflow template to an application instance, simple replacement of parameters in the workflow template is achieved to instantiate the workflow template, laying a foundation for the subsequent generation of a workflow code file.

[0092] Based on the above embodiments, as an optional embodiment, the scheduled task, the first trigger, the second trigger, and the created webhook interface are respectively named in the format of application instance number - scheduled task, application instance number - first trigger, application instance number - second trigger, and application instance number - webhook interface.

[0093] The argo events resources created in the present invention are all named according to a fixed specification to distinguish different binding operations and generate scheduling tasks between different workflows.

[0094] Of course, this embodiment is only a format example, and other formats can also be used without changing the original intention of the present invention.

[0095] Based on the above embodiments, as an optional embodiment, after creating the scheduled task corresponding to the application instance, it further includes:

[0096] Configuring a cron expression for the scheduled task;

[0097] Wherein, the cron expression is used to instruct the scheduled task to issue an execution instruction.

[0098] For example: the cron expression indicates execution at 6 o'clock every day. At 6 o'clock every day, the workflow service interface is called to start the scheduled task so that the scheduled task issues an execution instruction at 6 o'clock every day.

[0099] The argo events service of the present invention utilizes the scheduled task and the cron expression to trigger the first workflow, and the triggering method is simple and fast, which can meet the task requirements.

[0100] Based on the above embodiments, as an optional embodiment, the implementation of continuous scheduling between the first workflow and the second workflow by using the workflow code file and the argo events resources includes:

[0101] When the cron expression is satisfied, the workflow service interface is called to start the scheduled task so that the scheduled task issues an execution instruction;

[0102] When the first trigger monitors the execution instruction, the first trigger is used to trigger the execution of the first workflow; wherein, the triggering of the execution of the first workflow is achieved by triggering the workflow code file, and when the workflow code file is triggered, each task in the first workflow is executed in sequence, and after the tasks in the first workflow are executed, the Webhook interface is called to pass parameters to the second workflow;

[0103] After the second trigger monitors that the parameter passing of the Webhook interface is completed, the second trigger is used to trigger the execution of the second workflow.

[0104] It can be understood that the second workflow receives the input parameters passed by the webhook interface and processes its own tasks sequentially. After the execution is completed, the entire process ends and the relevant traces are cleared.

[0105] The present invention realizes the scheduling and parameter passing between multiple workflows, and can meet complex task requirements.

[0106] For a clearer understanding of the present invention, Figure 2 A practical execution flowchart of continuous workflow scheduling is provided.

[0107] The first step: Pre-prepare a workflow template;

[0108] Taking a workflow template in Yaml format as an example, this workflow template is divided into a workflow summary part and a workflow task details part;

[0109] The workflow task details part is further divided into four small parts: the first workflow task definition part (including defining each task and the dependency relationship between tasks); the declaration part for triggering the next workflow, the execution logic part of the first workflow task, and the implementation logic part for triggering the second workflow;

[0110] Among them, the script fragment of the workflow summary part is as follows:

[0111]

[0112] It can be seen that for the created workflow template, relevant parameters are replaced when binding the application instance, and a workflow instance is correspondingly generated, thereby supporting the automated configuration of multiple implementations of a workflow template and being able to solve the defect that the traditional workflow configuration needs to be pre-prepared and is not flexible enough.

[0113] The script fragment of the first workflow task definition part is as follows:

[0114]

[0115]

[0116] Trigger the next workflow declaration section

[0117]

[0118] It can be seen that the declaration section defines the parameters transmitted from the first workflow to the second workflow.

[0119] First workflow task execution logic section:

[0120]

[0121] Implementation logic section for triggering the second workflow:

[0122]

[0123] It can be seen that in the present invention, by adding a trigger task at the end of the first workflow, the curl command is used to call the webhook to trigger the second workflow and realize the parameter transfer; the problem that the scheduling between traditional workflows is mostly triggered manually and consumes human labor costs is solved, so that the scheduling between workflows is more flexible and diverse.

[0124] In addition, connecting these parts of code in sequence is the complete workflow template; in this template, #param represents the parameter value corresponding to the parameter param, '#appId' represents the application instance number corresponding to the bound application instance, #webhookUrl represents the API address of the webhook interface, and "#" means filling with parameter placeholders; these values need to be replaced with meaningful values during the procedure of instantiating the workflow template.

[0125] Second step: Bind the workflow template to the application instance;

[0126] The operation of the first stage of workflow template instantiation is carried out by binding the workflow template to a specific application instance, and the specific operations are as follows:

[0127] When receiving the instruction to bind the workflow template to the application instance, automatically generate the corresponding application instance number for the application instance;

[0128] Replace the parameter values filled with parameter placeholders in the workflow template with the real parameter values in the application instance, and replace the / #appId in the summary part of the workflow template and the #appId in the curl command with the application instance number appId.

[0129] Third step: Create a scheduled task, webhook and trigger;

[0130] The operation of the second stage of workflow template instantiation is carried out by creating a scheduled task, webhook and trigger, and the specific operations are as follows:

[0131] Through the workflow service interface, call the underlying argo events service to generate corresponding scheduled tasks calendar, webhook, first trigger, and second trigger;

[0132] Replace the #webhookUrl parameter in the yaml file according to the generated API address of the webhook to obtain the workflow instance.

[0133] Among them, the generated argo events resources (i.e., scheduled tasks calendar, webhook, first trigger, and second trigger) are all named according to fixed specifications, such as #appId-calendar, #appId-webhook, etc., to be used to distinguish different binding operations and generate scheduling tasks between different workflows.

[0134] Step 4: Start the scheduled task

[0135] Configure relevant cron expressions for the calendar scheduled task (for example: the cron expression represents execution at 6 o'clock every day), and call the workflow service interface to start the scheduled task accordingly.

[0136] Step 5: The workflow is executed in sequence:

[0137] 1. When the calendar scheduled task meets the cron expression, send an execution message indicating that the trigger condition has been reached;

[0138] 2. After the first trigger that monitors the scheduled task captures the execution message, trigger the execution of the first workflow bound to the scheduled task;

[0139] 3. The first workflow is executed according to the task order. When it reaches the last task, execute the pre-configured curl command, call the webhook interface, and pass relevant processed parameters;

[0140] 4. After the second trigger that monitors the webhook interface receives the webhook message, trigger the execution of the second workflow;

[0141] Thereafter, the second workflow receives the input parameters passed by the webhook and processes its own tasks sequentially. After the execution is completed, the entire process ends and relevant traces are cleared.

[0142] Figure 3 Provide a technical architecture diagram for continuous scheduling of auxiliary workflows, such as Figure 3As shown, the overall technical architecture adopts the design concept of a layered architecture. The microservice framework uses the SpringCloud microservice framework, with Eureka as the registration center and Ribbon for load balancing to jointly complete the construction of the service platform.

[0143] The technical architecture is layered, from top to bottom are the front-end display layer, the control layer, and the business layer. Among them, for the front-end display: Vue, a progressive framework, and the ElementUI component library are used for the front end. Axios is used for HTTP requests, and Echarts is used for chart display. Control layer: The entire control layer is implemented using the SpringBoot framework. System authentication and authorization are completed through the Shrio security framework and jwt. Feign is used to complete Http requests for service calls, and Ribbon is used for load balancing. Business layer: All business modules are implemented using the SpringBoot technology stack, including the processing of workflow services and the invocation of underlying argo components, the processing of application instance services and the interaction with the front end, the creation and binding of workflow templates, and the invocation between workflow templates and workflow services.

[0144] In the second aspect, a workflow continuous scheduling device based on Argo provided by the present invention is described. The workflow continuous scheduling device based on Argo described below can be correspondingly referred to the workflow continuous scheduling method based on Argo described above. Figure 4 An example of the structural schematic diagram of a workflow continuous scheduling device based on Argo is shown in Figure 4 As shown, the device includes: an acquisition module 21, a generation module 22, and a scheduling module 23;

[0145] Among them, the acquisition module 21 is used to acquire a workflow template. Among them, the workflow template includes a first workflow script segment and a script segment for triggering a second workflow. The script segment for triggering the second workflow configures the parameter passing method and parameter items when the first workflow passes parameters to the second workflow;

[0146] The generation module 22 is used to generate a workflow code file corresponding to the application instance and argo events resources according to the workflow template;

[0147] The scheduling module 23 is used to use the workflow code file and the argo events resources to achieve continuous scheduling between the first workflow and the second workflow.

[0148] A continuous scheduling device for a workflow based on Argo provided by the present invention prefabricates a workflow template before scheduling; a trigger task for a second workflow is added to the end of the first workflow in the workflow template, and it is stipulated to use the curl command to call the webhook to achieve the triggering of the second workflow and the transfer of parameters; when formally scheduling, the workflow template is instantiated, that is, a workflow code file corresponding to the application instance and argo events resources are generated according to the prefabricated workflow template; among them, the argo events resources can be regarded as task-driven resources allocated for the workflow code file; the instantiation process supports the automatic configuration of multiple implementations of a workflow template, solving the defect that traditional workflow configurations must be prefabricated and are not flexible enough. Using the workflow code file and the argo events resources, continuous scheduling between the first workflow and the second workflow is achieved. It solves the disadvantage that the scheduling between traditional workflows is mostly triggered manually, consuming labor costs, thus making the scheduling between workflows more flexible and diverse.

[0149] Based on the above embodiments, as an optional embodiment, the first workflow script segment defines the tasks of the first workflow and the dependencies between tasks through a container orchestration method; the tasks include task names, task parameters, task parameter values, and task execution logics.

[0150] The parameter passing method is to call the webhook interface through the API address of the webhook interface in the curl command, so as to use the webhook interface to achieve parameter transfer between the first workflow and the second workflow.

[0151] The first workflow script segment and the script segment for triggering the second workflow edit an application instance number used to refer to the application instance.

[0152] The API address of the webhook interface, the application instance number, and the task parameter value in the curl command in the workflow template are all filled with parameter placeholders.

[0153] Based on the above embodiments, as an optional embodiment, the generating module includes:

[0154] A binding unit for binding the workflow template to the application instance to obtain an instantiated workflow template.

[0155] A creating unit for calling the argo events service through the workflow service interface, so that the argo events service creates argo events resources corresponding to the application instance according to the instantiated workflow template; among them, the argo events resources include: scheduled tasks, a first trigger, a second trigger, and a webhook interface.

[0156] A replacement unit, configured to replace the API address of the webhook interface given by the curl command with the API address of the created webhook interface, so as to obtain the workflow code file corresponding to the application instance;

[0157] Wherein, the first trigger has the functions of monitoring the timing task and triggering the execution of the first workflow;

[0158] The second trigger has the functions of monitoring the created webhook interface and triggering the execution of the second workflow.

[0159] Based on the above embodiments, as an optional embodiment, the binding unit includes:

[0160] A generation subunit, configured to automatically generate an application instance number for the application instance when receiving a binding instruction between the workflow template and the application instance;

[0161] A replacement subunit, configured to replace the application instance number in the workflow template with the generated application instance number, and at the same time replace the task parameter value in the workflow template with the task parameter value in the application instance, so as to obtain an instantiated workflow template.

[0162] Based on the above embodiments, as an optional embodiment, the timing task, the first trigger, the second trigger, and the created webhook interface are respectively named in the format of application instance number - timing task, application instance number - first trigger, application instance number - second trigger, and application instance number - webhook interface.

[0163] Based on the above embodiments, as an optional embodiment, the generation module further includes a configuration unit;

[0164] The configuration unit is configured to configure a cron expression for the timing task after creating the timing task corresponding to the application instance;

[0165] Wherein, the cron expression is used to instruct the timing task to issue an execution instruction.

[0166] Based on the above embodiments, as an optional embodiment, the scheduling module includes:

[0167] A timing task start unit, configured to call the workflow service interface to start the timing task when the cron expression is satisfied, so that the timing task issues an execution instruction;

[0168] The first workflow trigger unit is used to trigger the execution of the first workflow by using the first trigger when the first trigger monitors the execution instruction; wherein, the trigger of the execution of the first workflow is realized by triggering the workflow code file, and when the workflow code file is triggered, each task in the first workflow is executed in sequence, and after the tasks in the first workflow are executed, the Webhook interface is called to transfer parameters to the second workflow;

[0169] The second workflow trigger unit is used to trigger the execution of the second workflow by using the second trigger after the second trigger monitors that the parameter transfer of the Webhook interface is completed.

[0170] In a third aspect, Figure 5 illustrates a schematic diagram of the entity structure of an electronic device, as Figure 5 shown. The electronic device may include: a processor 510, a communication interface 520, a memory 530, and a communication bus 540. Among them, the processor 510, the communication interface 520, and the memory 530 complete mutual communication through the communication bus 540. The processor 510 can call the logical instructions in the memory 530 to execute the continuous scheduling method of the workflow based on Argo. The method includes: obtaining a workflow template; wherein, the workflow template includes a first workflow script segment and a script segment for triggering the second workflow; the script segment for triggering the second workflow configures the parameter transfer method and parameter items when the first workflow transfers parameters to the second workflow; according to the workflow template, generating a workflow code file and argo events resources corresponding to the application instance; using the workflow code file and the argo events resources to realize the continuous scheduling between the first workflow and the second workflow.

[0171] In addition, when the logical instructions in the above-mentioned memory 530 are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs that can store program codes.

[0172] In a fourth aspect, the present invention also provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it is configured to execute the continuous scheduling method based on Argo provided above. The method includes: obtaining a workflow template; wherein, the workflow template includes a first workflow script segment and a script segment for triggering a second workflow; the script segment for triggering the second workflow configures the parameter passing method and parameter items when the first workflow passes parameters to the second workflow; generating a workflow code file corresponding to the application instance and argo events resources according to the workflow template; and implementing continuous scheduling between the first workflow and the second workflow by using the workflow code file and the argo events resources.

[0173] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. A person of ordinary skill in the art can understand and implement it without creative efforts.

[0174] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the essence of the above technical solution, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0175] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features. These modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A continuous scheduling method for workflows based on Argo, characterized in that, The method includes: Obtain a workflow template; wherein, the workflow template includes a first workflow script segment and a script segment for triggering a second workflow; the script segment for triggering the second workflow configures the parameter passing method and parameter items when the first workflow passes parameters to the second workflow; Generate a workflow code file corresponding to the application instance and argo events resources according to the workflow template; Utilize the workflow code file and the argo events resources to achieve continuous scheduling between the first workflow and the second workflow; Wherein, the argo events resources include: a timed task, a first trigger, a second trigger, and a webhook interface; the utilization of the workflow code file and the argo events resources to achieve continuous scheduling between the first workflow and the second workflow includes: When the cron expression is satisfied, call the workflow service interface to start the timed task so that the timed task issues an execution instruction; the cron expression is used to indicate that the timed task issues an execution instruction; when the first trigger monitors the execution instruction, use the first trigger to trigger the execution of the first workflow; wherein, the trigger of the execution of the first workflow is achieved by triggering the workflow code file, and when the workflow code file is triggered, each task in the first workflow is executed in sequence, and after the tasks in the first workflow are executed, call the Webhook interface to pass parameters to the second workflow; after the second trigger monitors that the parameter passing of the Webhook interface is completed, use the second trigger to trigger the execution of the second workflow.

2. The continuous scheduling method for Argo-based workflows according to claim 1, wherein The first workflow script segment defines the tasks of the first workflow and the dependencies between tasks through container orchestration; the tasks include task names, task parameters, task parameter values, and task execution logics; The parameter passing method is to call the webhook interface through the API address of the webhook interface in the curl command to utilize the webhook interface to achieve parameter passing between the first workflow and the second workflow; The first workflow script segment and the script segment for triggering the second workflow edit the application instance number used to refer to the application instance; The API address of the webhook interface, the application instance number, and the task parameter value in the curl command in the workflow template are all filled with parameter placeholders.

3. The method for continuous scheduling of the Argo-based workflow according to claim 2, wherein The generation of a workflow code file corresponding to the application instance and argo events resources according to the workflow template includes: Bind the workflow template to the application instance to obtain an instantiated workflow template; Call the argo events service through the workflow service interface so that the argo events service creates the argo events resources corresponding to the application instance according to the instantiated workflow template; Replace the API address of the webhook interface given by the curl command with the API address of the created webhook interface, so as to obtain the workflow code file corresponding to the application instance; Among them, the first trigger has the functions of listening to the scheduled task and triggering the execution of the first workflow; The second trigger has the functions of listening to the created webhook interface and triggering the execution of the second workflow.

4. The workflow continuous scheduling method based on Argo according to claim 3, wherein Binding the workflow template to the application instance to obtain an instantiated workflow template includes: When receiving the binding instruction of the workflow template and the application instance, automatically generate an application instance number for the application instance; Replace the application instance number in the workflow template with the generated application instance number, and at the same time replace the task parameter values in the workflow template with the task parameter values in the application instance to obtain an instantiated workflow template.

5. The continuous scheduling method for Argo-based workflows according to claim 4, characterized in that, The scheduled task, the first trigger, the second trigger, and the created webhook interface are named in the format of application instance number - scheduled task, application instance number - first trigger, application instance number - second trigger, and application instance number - webhook interface respectively.

6. The Argo-based continuous scheduling method for workflows according to claim 3 or 5, characterized in that After creating the scheduled task corresponding to the application instance, it further includes: Configure a cron expression for the scheduled task.

7. An Argo-based workflow continuous scheduling device, characterized in that, The device includes: An acquisition module for acquiring a workflow template; among them, the workflow template includes a first workflow script segment and a script segment for triggering a second workflow; the script segment for triggering the second workflow configures the parameter passing method and parameter items when the first workflow passes parameters to the second workflow; A generation module for generating a workflow code file and argoevents resources corresponding to the application instance according to the workflow template; A scheduling module for using the workflow code file and the argo events resources to realize continuous scheduling between the first workflow and the second workflow; Among them, the argo events resources include: a scheduled task, a first trigger, a second trigger, and a webhook interface; the scheduling module includes: A scheduled task start unit for calling the workflow service interface to start the scheduled task when the cron expression is satisfied, so that the scheduled task issues an execution instruction; the cron expression is used to indicate that the scheduled task issues an execution instruction; A first workflow trigger unit for triggering the execution of the first workflow by using the first trigger when the first trigger monitors the execution instruction; among them, the trigger of the execution of the first workflow is realized by triggering the workflow code file, and when the workflow code file is triggered, each task in the first workflow is executed in sequence, and after the tasks in the first workflow are executed, the Webhook interface is called to pass parameters to the second workflow; A second workflow trigger unit for triggering the execution of the second workflow by using the second trigger when the second trigger monitors that the parameter passing of the Webhook interface is completed.

8. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the Argo-based workflow continuous scheduling method according to any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the Argo-based workflow continuous scheduling method according to any one of claims 1 to 6.

Images