add en doc
Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>
This commit is contained in:
FogDong
parent
54b5c78279
commit
c3c2f36209
|
|
@ -0,0 +1,105 @@
|
|||
---
|
||||
title: Dependency
|
||||
---
|
||||
|
||||
This section will introduce how to specify dependencies for workflow steps.
|
||||
|
||||
> Note: In the current version (1.4), the steps in the workflow are executed sequentially, which means that there is an implicit dependency between steps, ie: the next step depends on the successful execution of the previous step. At this point, specifying dependencies in the workflow may not make much sense.
|
||||
>
|
||||
> In future versions (1.5+), you will be able to display the execution method of the specified workflow steps (eg: change to DAG parallel execution). At this time, you can control the execution of the workflow by specifying the dependencies of the steps.
|
||||
|
||||
## How to use
|
||||
|
||||
In KubeVela, the dependencies between steps can be specified by `dependsOn` in the steps.
|
||||
|
||||
For example: we want to send a message notification after deploying the component:
|
||||
|
||||
```yaml
|
||||
...
|
||||
workflow:
|
||||
steps:
|
||||
- name: comp
|
||||
type: apply-component
|
||||
- name: notify
|
||||
type: notification
|
||||
dependsOn:
|
||||
- comp
|
||||
```
|
||||
|
||||
In this case, KubeVela waits for the completion of the step `comp` before executing the `notify` step to send a message notification.
|
||||
|
||||
Apply the following YAML:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: dependsOn-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: oamdev/hello-world
|
||||
ports:
|
||||
- port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: comp
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
- name: slack-message
|
||||
type: notification
|
||||
dependsOn:
|
||||
- comp
|
||||
properties:
|
||||
slack:
|
||||
url:
|
||||
value: <your slack url>
|
||||
message:
|
||||
text: depends on comp
|
||||
```
|
||||
|
||||
## Expected outcome
|
||||
|
||||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status depends
|
||||
About:
|
||||
|
||||
Name: depends
|
||||
Namespace: default
|
||||
Created at: 2022-06-24 17:20:50 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: StepByStep
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:e6votsntq3
|
||||
name:comp
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:esvzxehgwc
|
||||
name:slack-message
|
||||
type:notification
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: express-server
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
|
||||
As you can see, all step statuses are succeeded. And when the component is successfully deployed, a message is also sent in slack.
|
||||
|
|
@ -0,0 +1,274 @@
|
|||
---
|
||||
title: If conditions
|
||||
---
|
||||
|
||||
This section introduces how to add if conditions to workflow steps.
|
||||
|
||||
In the KubeVela workflow, each step can specify an `if`, in which you can determine whether the step should be executed.
|
||||
|
||||
## No If specified
|
||||
|
||||
In the case where a step does not specify an If, KubeVela will determine whether to execute the step based on the status of the previous steps. In default, if all the previous steps are succeeded, the step will be executed.
|
||||
|
||||
This also means that if step A fails, step B after step A will be skipped and will not be executed.
|
||||
|
||||
Apply the following example:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: err-with-no-if
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: oamdev/hello-world
|
||||
ports:
|
||||
- port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: apply-err
|
||||
type: apply-object
|
||||
properties:
|
||||
value:
|
||||
test: err
|
||||
- name: apply-comp
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
```
|
||||
|
||||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status err-with-no-if
|
||||
About:
|
||||
|
||||
Name: err-with-no-if
|
||||
Namespace: default
|
||||
Created at: 2022-06-24 18:14:46 +0800 CST
|
||||
Status: workflowTerminated
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: StepByStep
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: true
|
||||
Steps
|
||||
- id:bztlmifsjl
|
||||
name:apply-err
|
||||
type:apply-object
|
||||
phase:failed
|
||||
message:step apply: run step(provider=kube,do=apply): Object 'Kind' is missing in '{"test":"err"}'
|
||||
- id:el8quwh8jh
|
||||
name:apply-comp
|
||||
type:apply-component
|
||||
phase:skipped
|
||||
message:
|
||||
|
||||
Services:
|
||||
```
|
||||
|
||||
As you can see, the step `apply-err` will fail due to an attempt to deploy an invalid resource, and the step `apply-comp` will be skipped because the previous step failed.
|
||||
|
||||
## If Always
|
||||
|
||||
If you want a step to be executed anyway, you can specify `if` to `always` for this step.
|
||||
|
||||
Apply the following example:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: err-with-always
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: invalid
|
||||
type: webservice
|
||||
properties:
|
||||
image: invalid
|
||||
ports:
|
||||
- port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: comp
|
||||
type: apply-component
|
||||
timeout: 5s
|
||||
outputs:
|
||||
- name: status
|
||||
valueFrom: output.status.conditions[0].type + output.status.conditions[0].status
|
||||
properties:
|
||||
component: invalid
|
||||
- name: notification
|
||||
type: notification
|
||||
inputs:
|
||||
- from: status
|
||||
parameterKey: slack.message.text
|
||||
if: always
|
||||
properties:
|
||||
slack:
|
||||
url:
|
||||
value: <your slack url>
|
||||
```
|
||||
|
||||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status err-with-always
|
||||
About:
|
||||
|
||||
Name: err-with-always
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:30:29 +0800 CST
|
||||
Status: workflowTerminated
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: StepByStep
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: true
|
||||
Steps
|
||||
- id:loeqr6dlcn
|
||||
name:comp
|
||||
type:apply-component
|
||||
phase:failed
|
||||
message:
|
||||
- id:hul9tayu82
|
||||
name:notification
|
||||
type:notification
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: invalid
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Unhealthy Ready:0/1
|
||||
No trait applied
|
||||
```
|
||||
|
||||
You can see that step `comp` will try to deploy a component whose image is `invalid`, and the component will fail due to timeout after five seconds because the image cannot be pulled. In the meanwhile, this step passes the component's `status` as outputs. The step `notification` will be executed because `if: always` is specified. At the same time, the content of the message notification is the status of the component in the previous step. Therefore, we can see the message notification carrying the status information in slack.
|
||||
|
||||
## Custom If conditions
|
||||
|
||||
> Note: You need to upgrade to version 1.5 or above to use custom If conditions.
|
||||
|
||||
You can also write your own judgment logic to determine whether the step should be executed. Note: The value in `if` will be executed as CUE codes. KubeVela provides some built-in variables in `if`, they are:
|
||||
|
||||
* `status`：`status` contains status information for all workflow steps. You can use `status.<step-name>.phase == "succeeded"` to determine the status of a step, or you can use the simplified `status.<step-name>.succeeded` to determine.
|
||||
* `inputs`：`inputs` contains all the inputs parameters of the step. You can use `inputs.<input-name> == "value"` to get input for the step.
|
||||
|
||||
> Note that if your step name or inputs name is not a valid CUE variable name (eg: contains `-`, or starts with a number, etc.), you can refer to it as follows: `status["invalid-name"].failed`
|
||||
|
||||
Apply the following example:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: custom-if
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: comp-custom-if
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
workflow:
|
||||
steps:
|
||||
- name: apply
|
||||
type: apply-component
|
||||
properties:
|
||||
component: comp-custom-if
|
||||
outputs:
|
||||
- name: comp-output
|
||||
valueFrom: context.name
|
||||
- name: notification
|
||||
type: notification
|
||||
inputs:
|
||||
- from: comp-output
|
||||
parameterKey: slack.message.text
|
||||
if: inputs["comp-output"] == "custom-if"
|
||||
properties:
|
||||
slack:
|
||||
url:
|
||||
value: <your slack url>
|
||||
- name: notification-skip
|
||||
type: notification
|
||||
if: status.notification.failed
|
||||
properties:
|
||||
slack:
|
||||
url:
|
||||
value: <your slack url>
|
||||
message:
|
||||
text: this notification should be skipped
|
||||
- name: notification-succeeded
|
||||
type: notification
|
||||
if: status.notification.succeeded
|
||||
properties:
|
||||
slack:
|
||||
url:
|
||||
value: <your slack url>
|
||||
message:
|
||||
text: the notification is succeeded
|
||||
```
|
||||
|
||||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status custom-if
|
||||
About:
|
||||
|
||||
Name: custom-if
|
||||
Namespace: default
|
||||
Created at: 2022-06-25 00:37:14 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: StepByStep
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:un1zd8qc6h
|
||||
name:apply
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:n5xbtgsi68
|
||||
name:notification
|
||||
type:notification
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:2ufd3v6n78
|
||||
name:notification-skip
|
||||
type:notification
|
||||
phase:skipped
|
||||
message:
|
||||
- id:h644x6o8mb
|
||||
name:notification-succeeded
|
||||
type:notification
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: comp-custom-if
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
|
||||
As you can see, after the first step `apply` succeeded, the outputs `comp-output` will be output. The second step `notification` refers to the outputs of the first step as inputs and makes a judgment. After the condition is met, the notification is successfully sent. The third step `notification-skip` judges whether the second step is in a failed state. If the condition is not met, this step is skipped. The fourth step `notification-succeeded` judges whether the second step is successful, if the condition is met, the step is successfully executed.
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
---
|
||||
title: Pass data between steps
|
||||
---
|
||||
|
||||
This section introduces how to use `Inputs` and `Outputs` to pass data between workflow steps in KubeVela.
|
||||
|
||||
## Outputs
|
||||
|
||||
Outputs consists of `name` and `valueFrom`. `name` declares the name of this output, which will be referenced by `from` in input.
|
||||
|
||||
`valueFrom` can be written in the following ways:
|
||||
|
||||
1. Fill string value in the field, eg. `valueFrom: "testString"`.
|
||||
2. Use CUE expression, eg. `valueFrom: output.value.status.workflow.message`. Note that `output.value.status.workflow.message` will use the value of the variable from the CUE template of the current step. If this field does not exist in the CUE template of the step, the resulting value will be empty.
|
||||
3. Use `+` to combine above two ways, the computed value will be the result, eg. `valueFrom: output.value.status.workflow.message + "testString"`.
|
||||
|
||||
## Inputs
|
||||
|
||||
Inputs is made of `from` and `parameterKey`. Input uses `from` to reference output, `parameterKey` is a expression that assigns the value of the input to the corresponding field.
|
||||
|
||||
eg. Specify inputs:
|
||||
|
||||
```yaml
|
||||
...
|
||||
- name: notify
|
||||
type: notification
|
||||
inputs:
|
||||
- from: read-status
|
||||
parameterKey: slack.message.text
|
||||
```
|
||||
|
||||
## How to use
|
||||
|
||||
Suppose we already have a `depends` application in the cluster, and we want to read the workflow status of the `depends` Application in a new Application and send the status information to Slack.
|
||||
|
||||
Apply the following YAML:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: input-output
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: oamdev/hello-world
|
||||
ports:
|
||||
- port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: read
|
||||
type: read-object
|
||||
properties:
|
||||
name: depends
|
||||
outputs:
|
||||
- name: read-status
|
||||
valueFrom: output.value.status.workflow.message
|
||||
- name: slack-message
|
||||
type: notification
|
||||
inputs:
|
||||
- from: read-status
|
||||
parameterKey: slack.message.text
|
||||
properties:
|
||||
slack:
|
||||
url:
|
||||
value: <your slack url>
|
||||
```
|
||||
|
||||
> When reading the `depends` application, we use the `read-object` step type. In this step type, the read resources will be placed in `output.value`, so we can use `output.value.status.workflow.message` reads the workflow status information of `depends`.
|
||||
|
||||
When the application runs successfully, we can receive the workflow status information of the `depends` application in the Slack message notification.
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
---
|
||||
title: Workflow Overview
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Workflows, as part of the Application, can glue together additional delivery processes and specify arbitrary delivery environments. In short, `Workflow` provides customized control flow and flexibility based on the original delivery model of Kubernetes(Apply). For example, `Workflow` can be used to implement complex operations such as pause, manual approval, if conditions, waiting status, data flow, multi-environment gray release, A/B testing, etc.
|
||||
|
||||
A workflow consists of multiple steps, and typical workflow steps include step groups (containing a series of sub-steps), human review, multi-cluster publishing, notifications, etc. You can view all built-in workflow steps provided by default in KubeVela in [built-in workflow steps](./built-in-workflow-defs). If the built-in workflow steps don't meet your needs, you can also [custom workflow steps](../../platform-engineers/workflow/workflow).
|
||||
|
||||
`Workflow` consists of steps, you can either use KubeVela's [built-in workflow steps](./built-in-workflow-defs) like `suspend`, `notification`, `deploy`, `step-group` etc, or [customize your own `WorkflowStepDefinition`](../../platform-engineers/workflow/workflow).
|
||||
|
||||
In fact, if you only use components in the Application and do not declare a workflow, KubeVela will automatically create a default workflow for deploying the components when running the Application.
|
||||
|
||||
In [VelaUX](../../how-to/dashboard/workflow/overview), you can feel the workflow more intuitively. As shown in the figure: The following is a workflow that controls the application to be deployed to the test environment, paused in the manual approval step, and then deployed to the production environment:
|
||||
|
||||
|
||||
|
||||
## Execution order
|
||||
|
||||
In the workflow, all the steps will be executed sequentially and the next step will be executed after the previous one succeeded. If a step is of type `step-group`, it can contain a series of sub-steps, all of which are executed together when the step group is executed.
|
||||
|
||||
> 在 KubeVela 未来的版本（1.5+）中，你可以显示地指定步骤的执行方式来控制并发或者单步执行，如：
|
||||
> In future versions of KubeVela (1.5+), you can explicitly specify the execution mode of steps, such as:
|
||||
> ```yaml
|
||||
> workflow:
|
||||
> mode:
|
||||
> steps: StepByStep
|
||||
> subSteps: DAG
|
||||
> ```
|
||||
> There're two modes of execution: StepByStep and DAG.
|
||||
>
|
||||
> If you do not explicitly declare the execution mode, by default steps are executed sequentially in StepByStep and subSteps are executed in parallel in DAG.
|
||||
|
||||
## State of Application and Workflow
|
||||
|
||||
| Application | Workflow | Description |
|
||||
| :-------: | :----: | :-----------------------------------: |
|
||||
| runningWorkflow | executing | When the workflow is executing, the status of the application is runningWorkflow |
|
||||
| workflowSuspending | suspending | When the workflow is suspended, the status of the application is workflowSuspending |
|
||||
| workflowTerminated | terminated | When a step in the workflow fails or is terminated, the status of the application is workflowTerminated |
|
||||
| running | succeeded | When all steps in the workflow are executed successfully, the status of the application is running |
|
||||
|
||||
## Core features
|
||||
|
||||
Workflow has powerful process control capabilities, including:
|
||||
|
||||
- View [Suspend and Resume Workflow](./suspend) to learn how to suspend and resume a workflow.
|
||||
- View [Sub Steps](./step-group) to learn how to use sub-steps in the workflow.
|
||||
- View [Dependency](./dependency) to learn how to specify dependencies for workflow steps.
|
||||
- View [Pass data between steps](./inputs-outputs) to learn how to use `inputs`, `outputs` to pass data between steps.
|
||||
- View [If Conditions](./if-condition) to learn how to use `if` to determine whether the step should be executed.
|
||||
- View [Timeout Steps](./timeout) to learn how to set `timeout` for steps.
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
---
|
||||
title: Step Group
|
||||
---
|
||||
|
||||
This section describes how to use sub steps in KubeVela.
|
||||
|
||||
There is a special step type `step-group` in KubeVela workflow where you can declare sub-steps when using `step-group` type steps.
|
||||
|
||||
> Note: In the current version (1.4), sub steps in a step group are executed concurrently.
|
||||
>
|
||||
> In future versions (1.5+), you will be able to specify the execution mode of steps and sub-steps.
|
||||
|
||||
Apply the following example:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: sub-success
|
||||
spec:
|
||||
components:
|
||||
- name: express-server1
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
- name: express-server2
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
- name: express-server3
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: step1
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server1
|
||||
- name: step2
|
||||
type: step-group
|
||||
subSteps:
|
||||
- name: step2-sub1
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server2
|
||||
- name: step2-sub2
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server3
|
||||
```
|
||||
|
||||
By default, steps are executed sequentially, so step2 is not executed until step1 is deployed. Whereas in the step-group, sub-steps will be executed concurrently by default, so step2-sub1 and step2-sub2 will be deployed at the same time.
|
||||
|
|
@ -0,0 +1,258 @@
|
|||
---
|
||||
title: Suspend and Resume Workflow
|
||||
---
|
||||
|
||||
This section introduces how to suspend and resume the workflow in KubeVela.
|
||||
|
||||
## Suspend the Workflow
|
||||
|
||||
In KubeVela, you can choose to use the `vela` command to manually suspend the execution of the workflow, or use a built-in special step type `suspend` to automatically suspend the workflow.
|
||||
|
||||
### Suspend Manually
|
||||
|
||||
If you have a running application and you want to suspend its execution, you can use `vela workflow suspend` to suspend the workflow.
|
||||
|
||||
```bash
|
||||
$ vela workflow suspend my-app
|
||||
Successfully suspend workflow: my-app
|
||||
```
|
||||
|
||||
### Use Suspend Step
|
||||
|
||||
Apply the following example:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: suspend
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: comp1
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: comp2
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: apply1
|
||||
type: apply-component
|
||||
properties:
|
||||
component: comp1
|
||||
- name: suspend
|
||||
type: suspend
|
||||
- name: apply2
|
||||
type: apply-component
|
||||
properties:
|
||||
component: comp2
|
||||
```
|
||||
|
||||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: workflowSuspending
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: StepByStep
|
||||
finished: false
|
||||
Suspend: true
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:yj9h29uv6v
|
||||
name:apply1
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:xvmda4he5e
|
||||
name:suspend
|
||||
type:suspend
|
||||
phase:running
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: comp1
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
|
||||
As you can see, when the first step is completed, the `suspend` step will be executed and this step will suspend the workflow.
|
||||
|
||||
## Resume the Workflow
|
||||
|
||||
### Resume Manually
|
||||
|
||||
Once the workflow is suspended, you can use the `vela workflow resume` command to manually resume the workflow.
|
||||
|
||||
Take the above suspended application as an example:
|
||||
|
||||
```bash
|
||||
$ vela workflow resume suspend
|
||||
Successfully resume workflow: suspend
|
||||
```
|
||||
|
||||
After successfully continuing the workflow, view the status of the app:
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: StepByStep
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:yj9h29uv6v
|
||||
name:apply1
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:xvmda4he5e
|
||||
name:suspend
|
||||
type:suspend
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:66jonaxjef
|
||||
name:apply2
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: comp2
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
|
||||
- Name: comp1
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
|
||||
As you can see, the workflow has continued to execute.
|
||||
|
||||
### Terminate Manually
|
||||
|
||||
If you want to terminate a workflow while it is suspended, you can use the `vela workflow terminate` command to terminate the workflow.
|
||||
|
||||
```bash
|
||||
$ vela workflow terminate my-app
|
||||
Successfully terminate workflow: my-app
|
||||
```
|
||||
|
||||
### Resume the Workflow Automatically
|
||||
|
||||
If you want the workflow to be continued automatically after a period of time has passed. Then, you can add a `duration` parameter to the `suspend` step. When the `duration` time elapses, the workflow will automatically continue execution.
|
||||
|
||||
Apply the following example:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: auto-resume
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: comp1
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: comp2
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: apply1
|
||||
type: apply-component
|
||||
properties:
|
||||
component: comp1
|
||||
- name: suspend
|
||||
type: suspend
|
||||
properties:
|
||||
duration: 5s
|
||||
- name: apply2
|
||||
type: apply-component
|
||||
properties:
|
||||
component: comp2
|
||||
```
|
||||
|
||||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status auto-resume
|
||||
About:
|
||||
|
||||
Name: auto-resume
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:57:35 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: StepByStep
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:q5jhm6mgwv
|
||||
name:apply1
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:3xgfcp3cuj
|
||||
name:suspend
|
||||
type:suspend
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:zjux8ud876
|
||||
name:apply2
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: comp2
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
|
||||
- Name: comp1
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
|
||||
As you can see, the `suspend` step is automatically executed successfully after five seconds, and the workflow is executed successfully.
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
---
|
||||
title: Timeout Steps
|
||||
---
|
||||
|
||||
> Note: You need to upgrade to version 1.5 or above to use the timeout.
|
||||
|
||||
This section introduces how to add timeout to workflow steps in KubeVela.
|
||||
|
||||
In KubeVela workflow, each step can specify a `timeout`, you can use `timeout` to specify the timeout time for the step.
|
||||
|
||||
`timeout` follows the `duration` format, e.g. `30s`, `1m`, etc. You can refer to Golang's [parseDuration](https://pkg.go.dev/time#ParseDuration).
|
||||
|
||||
If a step is not completed within the specified time, KubeVela will set the status of the step to `failed` and the `Reason` of the step will be set to `Timeout`.
|
||||
|
||||
Apply the following example:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: timeout-example
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: comp1
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: comp2
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: apply-comp1
|
||||
type: apply-component
|
||||
properties:
|
||||
component: comp1
|
||||
- name: suspend
|
||||
type: suspend
|
||||
timeout: 5s
|
||||
- name: apply-comp2
|
||||
type: apply-component
|
||||
properties:
|
||||
component: comp2
|
||||
```
|
||||
|
||||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status timeout-example
|
||||
About:
|
||||
|
||||
Name: timeout-example
|
||||
Namespace: default
|
||||
Created at: 2022-06-25 00:51:43 +0800 CST
|
||||
Status: workflowTerminated
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: StepByStep
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: true
|
||||
Steps
|
||||
- id:1f58n13qdp
|
||||
name:apply-comp1
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:1pfije4ugt
|
||||
name:suspend
|
||||
type:suspend
|
||||
phase:failed
|
||||
message:
|
||||
- id:lqxyenjxj4
|
||||
name:apply-comp2
|
||||
type:apply-component
|
||||
phase:skipped
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: comp1
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
|
||||
As you can see, when the first component is successfully deployed, the workflow is suspended on the second `suspend` step. The `suspend` step is set with a timeout of five seconds. If the workflow is not resumed within five seconds, the step will fail because of timeout. The third step is skipped because the previous `suspend` step failed.
|
||||
|
|
@ -161,12 +161,12 @@ Services:
|
|||
|
||||
> 注意：你需要升级到 1.5 及以上版本来使用自定义 If 条件判断。
|
||||
|
||||
你也可以编写自己的判断逻辑来确定是否应该执行该步骤。注意： `if` 里的值将作为 Cue 代码执行。KubeVela 在 `if` 中提供了一些内置变量，它们是：
|
||||
你也可以编写自己的判断逻辑来确定是否应该执行该步骤。注意： `if` 里的值将作为 CUE 代码执行。KubeVela 在 `if` 中提供了一些内置变量，它们是：
|
||||
|
||||
* `status`：status 中包含了所有工作流步骤的状态信息。你可以使用 `status.<step-name>.phase == "succeeded"` 来判断步骤的状态，也可以使用简化方式`status.<step-name>.succeeded` 来进行判断。
|
||||
* `inputs`：inputs 中包含了该步骤的所有 inputs 参数。你可以使用 `inputs.<input-name> == "value"` 来获取判断步骤的输入。
|
||||
|
||||
> 注意，如果你的步骤名或者 inputs 名并不是一个有效的 Cue 变量名（如：包含 `-`，或者以数字开头等），你可以用如下方式引用：`status["invalid-name"].failed`
|
||||
> 注意，如果你的步骤名或者 inputs 名并不是一个有效的 CUE 变量名（如：包含 `-`，或者以数字开头等），你可以用如下方式引用：`status["invalid-name"].failed`
|
||||
|
||||
部署如下例子：
|
||||
|
||||
|
|
@ -211,7 +211,7 @@ spec:
|
|||
url:
|
||||
value: <your slack url>
|
||||
message:
|
||||
text: skip
|
||||
text: this notification should be skipped
|
||||
- name: notification-succeeded
|
||||
type: notification
|
||||
if: status.notification.succeeded
|
||||
|
|
@ -220,7 +220,7 @@ spec:
|
|||
url:
|
||||
value: <your slack url>
|
||||
message:
|
||||
text: succeeded
|
||||
text: the notification is succeeded
|
||||
```
|
||||
|
||||
使用 vela status 命令查看应用状态：
|
||||
|
|
|
|||
10
sidebars.js
10
sidebars.js
|
|
@ -86,9 +86,13 @@ module.exports = {
|
|||
label: 'Declarative Workflow',
|
||||
collapsed: true,
|
||||
items: [
|
||||
'tutorials/workflows',
|
||||
'end-user/workflow/component-dependency-parameter',
|
||||
'end-user/workflow/webhook-notification',
|
||||
'end-user/workflow/overview',
|
||||
'end-user/workflow/suspend',
|
||||
'end-user/workflow/step-group',
|
||||
'end-user/workflow/dependency',
|
||||
'end-user/workflow/inputs-outputs',
|
||||
'end-user/workflow/if-condition',
|
||||
'end-user/workflow/timeout',
|
||||
],
|
||||
},
|
||||
{
|
||||
|
|
|
|||
Loading…
Reference in New Issue