Workflow Step Definition

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:

ActionDescriptionParameter
ApplyApplicationApply all the resources in Application.-
ReadRead resources in Kubernetes cluster.value: the resource metadata to be get. And after successful execution, value will be updated with resource definition in cluster.
err: if an error occurs, the err will contain the error message.
ConditionalWaitThe 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 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:

  1. 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:

  1. $ cat my-helm.cue
  2. "my-helm": {
  3. annotations: {}
  4. attributes: {}
  5. description: "Apply helm charts and wait till it's running."
  6. labels: {}
  7. type: "workflow-step"
  8. }
  9. template: {
  10. }

Import vela/op and complete the Cue code in template:

  1. import (
  2. "vela/op"
  3. )
  4. "my-helm": {
  5. annotations: {}
  6. attributes: {}
  7. description: "Apply helm charts and wait till it's running."
  8. labels: {}
  9. type: "workflow-step"
  10. }
  11. template: {
  12. // Apply all the resources in Application
  13. apply: op.#ApplyApplication & {}
  14. resource: op.#Read & {
  15. value: {
  16. kind: "Deployment"
  17. apiVersion: "apps/v1"
  18. metadata: {
  19. name: "tomcat"
  20. // we can use context to get any metadata in Application
  21. namespace: context.namespace
  22. }
  23. }
  24. }
  25. workload: resource.value
  26. // wait till it's ready
  27. wait: op.#ConditionalWait & {
  28. continue: workload.status.readyReplicas == workload.status.replicas && workload.status.observedGeneration == workload.metadata.generation
  29. }
  30. }

Apply it to the cluster:

  1. $ vela def apply my-helm.cue
  2. WorkflowStepDefinition my-helm in namespace vela-system updated.

Step: Send Slack notifications

Use the built-in step, [webhook-notification].

Apply the Application

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: first-vela-workflow
  5. namespace: default
  6. spec:
  7. components:
  8. - name: tomcat
  9. type: helm
  10. properties:
  11. repoType: helm
  12. url: https://charts.bitnami.com/bitnami
  13. chart: tomcat
  14. version: "9.2.20"
  15. workflow:
  16. steps:
  17. - name: tomcat
  18. # specify the step type
  19. type: my-helm
  20. outputs:
  21. - name: msg
  22. # get value from the deployment status in my-helm
  23. valueFrom: resource.value.status.conditions[0].message
  24. - name: send-message
  25. type: webhook-notification
  26. inputs:
  27. - from: msg
  28. # use the output value in the previous step and pass it into the properties slack.message.text
  29. parameterKey: slack.message.text
  30. properties:
  31. slack:
  32. # the address of your slack webhook, please refer to: https://api.slack.com/messaging/webhooks
  33. 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.