149 lines
5.2 KiB
Markdown
149 lines
5.2 KiB
Markdown
---
|
||
title: Workflow Step Definition
|
||
slug: /platform-engineers/workflow/workflow
|
||
---
|
||
|
||
## Overview
|
||
|
||
`Workflow` allows you to customize steps in `Application`, 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, waiting status, data flow, multi-environment gray release, A/B testing, etc.
|
||
|
||
`Workflow` is a further exploration and best practice based on OAM model in KubeVela, it obeys the modular concept and reusable characteristics of OAM. Each workflow module is a "super glue" that can combine your arbitrary tools and processes. In modern complex cloud native application delivery environment, you can completely describe all delivery processes through a declarative configuration, ensuring the stability and convenience of the delivery process.
|
||
|
||
## Using workflow
|
||
|
||
`Workflow` consists of steps, you can either use KubeVela's [built-in workflow steps], or write their own `WorkflowStepDefinition` to complete the operation.
|
||
|
||
We can use `vela def` to define workflow steps by writing `Cue templates`. Let's write an `Application` that apply a Tomcat using Helm chart and automatically send message to Slack when the Tomcat is running.
|
||
|
||
### Workflow Steps
|
||
|
||
KubeVela provides several CUE actions for writing workflow steps. These actions are provided by the `vela/op` package. In order to achieve the above scenario, we need to use the following three CUE actions:
|
||
|
||
| Action | Description | Parameter |
|
||
| :---: | :--: | :-- |
|
||
| [ApplyApplication](./cue-actions#apply) | Apply all the resources in Application. | - |
|
||
| [Read](./cue-actions#read) | Read resources in Kubernetes cluster. | value: the resource metadata to be get. And after successful execution, `value` will be updated with resource definition in cluster.<br /> err: if an error occurs, the `err` will contain the error message. |
|
||
| [ConditionalWait](./cue-actions#conditionalwait) | The workflow step will be blocked until the condition is met. | continue: The workflow step will be blocked until the value becomes `true`. |
|
||
|
||
> For all the workflow actions, please refer to [Built-in Workflow Operations](./cue-actions) reference docs.
|
||
|
||
After this, we need two `WorkflowStepDefinitions` to complete the Application：
|
||
|
||
1. Apply Tomcat and wait till it's status become running. We need to write a custom workflow step for it.
|
||
2. Send Slack notifications, we can use the built-in [webhook-notification] step for it.
|
||
|
||
#### Step: Apply Tomcat
|
||
|
||
First, use `vela def init` to generate a `WorkflowStepDefinition` template：
|
||
|
||
```shell
|
||
vela def init my-helm -t workflow-step --desc "Apply helm charts and wait till it's running." -o my-helm.cue
|
||
```
|
||
|
||
The result is as follows：
|
||
```shell
|
||
$ cat my-helm.cue
|
||
|
||
"my-helm": {
|
||
annotations: {}
|
||
attributes: {}
|
||
description: "Apply helm charts and wait till it's running."
|
||
labels: {}
|
||
type: "workflow-step"
|
||
}
|
||
|
||
template: {
|
||
}
|
||
```
|
||
|
||
Import `vela/op` and complete the Cue code in `template`:
|
||
|
||
```
|
||
import (
|
||
"vela/op"
|
||
)
|
||
|
||
"my-helm": {
|
||
annotations: {}
|
||
attributes: {}
|
||
description: "Apply helm charts and wait till it's running."
|
||
labels: {}
|
||
type: "workflow-step"
|
||
}
|
||
|
||
template: {
|
||
// Apply all the resources in Application
|
||
apply: op.#ApplyApplication & {}
|
||
|
||
resource: op.#Read & {
|
||
value: {
|
||
kind: "Deployment"
|
||
apiVersion: "apps/v1"
|
||
metadata: {
|
||
name: "tomcat"
|
||
// we can use context to get any metadata in Application
|
||
namespace: context.namespace
|
||
}
|
||
}
|
||
}
|
||
|
||
workload: resource.value
|
||
// wait till it's ready
|
||
wait: op.#ConditionalWait & {
|
||
continue: workload.status.readyReplicas == workload.status.replicas && workload.status.observedGeneration == workload.metadata.generation
|
||
}
|
||
}
|
||
```
|
||
|
||
Apply it to the cluster：
|
||
|
||
```shell
|
||
$ vela def apply my-helm.cue
|
||
|
||
WorkflowStepDefinition my-helm in namespace vela-system updated.
|
||
```
|
||
|
||
#### Step: Send Slack notifications
|
||
|
||
Use the built-in step, [webhook-notification].
|
||
|
||
### Apply the Application
|
||
|
||
```yaml
|
||
apiVersion: core.oam.dev/v1beta1
|
||
kind: Application
|
||
metadata:
|
||
name: first-vela-workflow
|
||
namespace: default
|
||
spec:
|
||
components:
|
||
- name: tomcat
|
||
type: helm
|
||
properties:
|
||
repoType: helm
|
||
url: https://charts.bitnami.com/bitnami
|
||
chart: tomcat
|
||
version: "9.2.20"
|
||
workflow:
|
||
steps:
|
||
- name: tomcat
|
||
# specify the step type
|
||
type: my-helm
|
||
outputs:
|
||
- name: msg
|
||
# get value from the deployment status in my-helm
|
||
valueFrom: resource.value.status.conditions[0].message
|
||
- name: send-message
|
||
type: webhook-notification
|
||
inputs:
|
||
- from: msg
|
||
# use the output value in the previous step and pass it into the properties slack.message.text
|
||
parameterKey: slack.message.text
|
||
properties:
|
||
slack:
|
||
# the address of your slack webhook, please refer to: https://api.slack.com/messaging/webhooks
|
||
url: <your slack url>
|
||
```
|
||
|
||
Apply the Application to the cluster and you can see that all resources have been successfully applied and Slack has received the messages of the Deployment status.
|