Docs: add apply object (#329)
* Docs: add apply object * fix broken links * fix broken links * fix multi env
This commit is contained in:
Tianxin Dong
GitHub
parent
00e5cd5f51
commit
43bbaf026d
|
|
@ -1,131 +0,0 @@
|
|||
---
|
||||
title: Apply Components and Traits
|
||||
---
|
||||
|
||||
In this guide, you will learn how to apply components and traits in `Workflow`.
|
||||
|
||||
## How to use
|
||||
|
||||
Apply the following `Application`:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
workflow:
|
||||
steps:
|
||||
- name: express-server
|
||||
# specify the workflow step type
|
||||
type: apply-component
|
||||
properties:
|
||||
# specify the component name
|
||||
component: express-server
|
||||
- name: manual-approval
|
||||
# suspend is a built-in task of workflow used to suspend the workflow
|
||||
type: suspend
|
||||
- name: nginx-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: nginx-server
|
||||
```
|
||||
|
||||
If we want to suspend the workflow for manual approval before applying some certain components, we can use `suspend` step to pause the workflow.
|
||||
|
||||
In this case, the workflow will be suspended after applying the first component. The second component will wait to be applied util the `resume` command is called.
|
||||
|
||||
Check the status after applying the `Application`:
|
||||
|
||||
```shell
|
||||
$ kubectl get app first-vela-workflow
|
||||
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
first-vela-workflow express-server webservice workflowSuspending 2s
|
||||
```
|
||||
|
||||
We can use `vela workflow resume` to resume the workflow.
|
||||
|
||||
> For more information of `vela workflow`，please ref [vela cli](../../cli/vela_workflow).
|
||||
|
||||
```shell
|
||||
$ vela workflow resume first-vela-workflow
|
||||
|
||||
Successfully resume workflow: first-vela-workflow
|
||||
```
|
||||
|
||||
Check the status, the `Application` is now `runningWorkflow`:
|
||||
|
||||
```shell
|
||||
$ kubectl get app first-vela-workflow
|
||||
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
first-vela-workflow express-server webservice running true 10s
|
||||
```
|
||||
## Expected outcome
|
||||
|
||||
Check the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
All the step status in workflow is succeeded:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: express-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: nginx-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
Check the component status in cluster:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 3m28s
|
||||
nginx-server 1/1 1 1 3s
|
||||
|
||||
$ kubectl get ingress
|
||||
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 4m7s
|
||||
```
|
||||
|
||||
We can see that all the components and traits have been applied to the cluster.
|
||||
|
|
@ -1,164 +0,0 @@
|
|||
---
|
||||
title: Apply Remaining
|
||||
---
|
||||
|
||||
If we want to apply one component first and then apply the rest of the components after the first one is running, KubeVela provides the `apply-remaining` workflow step to filter out selected resources and apply remaining.
|
||||
|
||||
In this guide, you will learn how to apply remaining resources via `apply-remaining` in `Workflow`.
|
||||
|
||||
## How to use
|
||||
|
||||
Apply the following `Application` with workflow step type of `apply-remaining`:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
- name: express-server2
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: express-server3
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: express-server4
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: first-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
- name: manual-approval
|
||||
# suspend is a built-in task of workflow used to suspend the workflow
|
||||
type: suspend
|
||||
- name: remaining-server
|
||||
# specify the workflow step type
|
||||
type: apply-remaining
|
||||
properties:
|
||||
# specify the component that needs to be skipped
|
||||
exceptions:
|
||||
# specify the configuration of the component
|
||||
express-server:
|
||||
# skipApplyWorkload indicates whether to skip apply the workload resource
|
||||
skipApplyWorkload: true
|
||||
# skipAllTraits indicates to skip apply all resources of the traits
|
||||
skipAllTraits: true
|
||||
```
|
||||
|
||||
## Expected outcome
|
||||
|
||||
Check the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
We can see that the workflow is suspended at `manual-approval`:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 2
|
||||
steps:
|
||||
- name: first-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
```
|
||||
|
||||
Check the component status in cluster and resume the workflow after the component is running:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 5s
|
||||
|
||||
$ kubectl get ingress
|
||||
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 47s
|
||||
```
|
||||
|
||||
Resume the workflow:
|
||||
|
||||
```
|
||||
vela workflow resume first-vela-workflow
|
||||
```
|
||||
|
||||
Recheck the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
All the step status in workflow is succeeded:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: first-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: remaining-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-remaining
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
Recheck the component status:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 110s
|
||||
express-server2 1/1 1 1 6s
|
||||
express-server3 1/1 1 1 6s
|
||||
express-server4 1/1 1 1 6s
|
||||
```
|
||||
|
||||
We can see that all of the components has been applied to the cluster successfully. Besides, the first component `express-server` is not applied repeatedly.
|
||||
|
||||
With `apply-remaining`, we can easily filter and apply resources by filling in the built-in parameters.
|
||||
|
|
@ -218,6 +218,62 @@ spec:
|
|||
text: Workflow ended.
|
||||
```
|
||||
|
||||
## apply-object
|
||||
|
||||
### Overview
|
||||
|
||||
Apply Kubernetes native resources, you need to upgrade to KubeVela v1.1.4 or higher to enable `apply-object`.
|
||||
|
||||
### Parameters
|
||||
|
||||
| Name | Type | Description |
|
||||
| :-------: | :----: | :-----------------------------------: |
|
||||
| ... | ... | Kubernetes native resources fields |
|
||||
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: server-with-pvc
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
volumes:
|
||||
- name: "my-pvc"
|
||||
type: "pvc"
|
||||
mountPath: "/test"
|
||||
claimName: "myclaim"
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: apply-pvc
|
||||
type: apply-object
|
||||
properties:
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: myclaim
|
||||
namespace: default
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 8Gi
|
||||
storageClassName: standard
|
||||
- name: apply-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
```
|
||||
|
||||
## suspend
|
||||
|
||||
### Overview
|
||||
|
|
|
|||
|
|
@ -1,173 +0,0 @@
|
|||
---
|
||||
title: Multi Environments
|
||||
---
|
||||
|
||||
If we have multiple clusters, we want to apply our application in the test cluster first, and then apply it to the production cluster after the application in test cluster is running. KubeVela provides the `deploy2env` workflow step to manage multi environments. You can have a glimpse of how does it work as below:
|
||||
|
||||
|
||||
|
||||
In this guide, you will learn how to manage multi environments via `deploy2env` in `Workflow`.
|
||||
|
||||
> Before reading this section, please make sure you have learned about the [Env Binding](../policies/envbinding) in KubeVela.
|
||||
|
||||
## How to use
|
||||
|
||||
Apply the following `Application` with workflow step type of `deploy2env`:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: multi-env-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
|
||||
policies:
|
||||
- name: env
|
||||
type: env-binding
|
||||
properties:
|
||||
created: false
|
||||
envs:
|
||||
- name: test
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
clusterSelector:
|
||||
labels:
|
||||
purpose: test
|
||||
- name: prod
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
clusterSelector:
|
||||
labels:
|
||||
purpose: prod
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
# specify the workflow step type
|
||||
type: deploy2env
|
||||
properties:
|
||||
# specify the component name
|
||||
component: nginx-server
|
||||
# specify the policy name
|
||||
policy: env
|
||||
# specify the env name in policy
|
||||
env: test
|
||||
- name: manual-approval
|
||||
# suspend is a built-in task of workflow used to suspend the workflow
|
||||
type: suspend
|
||||
- name: deploy-prod-server
|
||||
type: deploy2env
|
||||
properties:
|
||||
component: nginx-server
|
||||
policy: env
|
||||
env: prod
|
||||
```
|
||||
|
||||
## Expected outcome
|
||||
|
||||
Check the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
We can see that the workflow is suspended at `manual-approval`:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 2
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
```
|
||||
|
||||
Switch to `test` cluster and check the component status:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-server 1/1 1 1 1m10s
|
||||
```
|
||||
|
||||
Use `resume` command after everything is ok in test cluster:
|
||||
|
||||
```shell
|
||||
$ vela workflow resume multi-env-demo
|
||||
|
||||
Successfully resume workflow: multi-env-demo
|
||||
```
|
||||
|
||||
Recheck the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
All the step status in workflow is succeeded:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: deploy-prod-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
Then, check the component status in `prod` cluster:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-server 1/1 1 1 1m10s
|
||||
```
|
||||
|
||||
We can see that the component have been applied to both clusters.
|
||||
|
||||
With `deploy2env`, we can easily manage applications in multiple environments.
|
||||
|
|
@ -171,4 +171,4 @@ Service `podinfo-server` 绑定了一个 EXTERNAL-IP，允许用户通过公网
|
|||
上述应用部署计划 `workflow-demo` 中使用了内置的应用策略 `env-binding` 对应用部署计划进行差异化配置，修改了组件 `podinfo-server` 的镜像，
|
||||
以及运维特征 `expose` 的类型以允许集群外部的请求访问，同时应用策略 `env-binding` 指定了资源调度策略，将资源部署到新注册的 ACK 集群内。
|
||||
|
||||
应用部署计划的交付工作流也使用了内置的 [`multi-env`](../end-user/workflow/multi-env) 交付工作流定义，指定具体哪一个配置后的组件部署到集群中。
|
||||
应用部署计划的交付工作流也使用了内置的 `multi-env` 交付工作流定义，指定具体哪一个配置后的组件部署到集群中。
|
||||
|
|
@ -1,132 +0,0 @@
|
|||
---
|
||||
title: 部署组件和运维特征
|
||||
---
|
||||
|
||||
本节将介绍如何在工作流中部署组件和运维特征。
|
||||
|
||||
## 如何使用
|
||||
|
||||
部署如下应用部署计划：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
workflow:
|
||||
steps:
|
||||
- name: express-server
|
||||
# 指定步骤类型
|
||||
type: apply-component
|
||||
properties:
|
||||
# 指定组件名称
|
||||
component: express-server
|
||||
- name: manual-approval
|
||||
# 工作流内置 suspend 类型的任务，用于暂停工作流
|
||||
type: suspend
|
||||
- name: nginx-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: nginx-server
|
||||
```
|
||||
|
||||
在一些情况下，我们在部署某些组件前，需要暂停整个工作流，以等待人工审批。
|
||||
|
||||
在本例中，部署完第一个组件后，工作流会暂停。直到继续的命令被发起后，才开始部署第二个组件。
|
||||
|
||||
部署应用特征计划后，查看工作流状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get app first-vela-workflow
|
||||
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
first-vela-workflow express-server webservice workflowSuspending 2s
|
||||
```
|
||||
|
||||
可以通过 `vela workflow resume` 命令来使工作流继续执行。
|
||||
|
||||
> 有关于 `vela workflow` 命令的介绍，可以详见 [vela cli](../../cli/vela_workflow)。
|
||||
|
||||
```shell
|
||||
$ vela workflow resume first-vela-workflow
|
||||
|
||||
Successfully resume workflow: first-vela-workflow
|
||||
```
|
||||
|
||||
查看应用部署计划，可以看到状态已经变为执行中：
|
||||
|
||||
```shell
|
||||
$ kubectl get app first-vela-workflow
|
||||
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
first-vela-workflow express-server webservice running true 10s
|
||||
```
|
||||
|
||||
## 期望结果
|
||||
|
||||
查看应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
所有步骤的状态均已成功：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: express-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: nginx-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
确认集群中组件的状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 3m28s
|
||||
nginx-server 1/1 1 1 3s
|
||||
|
||||
$ kubectl get ingress
|
||||
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 4m7s
|
||||
```
|
||||
|
||||
可以看到，所有的组件及运维特征都被成功地部署到了集群中。
|
||||
|
|
@ -1,163 +0,0 @@
|
|||
---
|
||||
title: 部署剩余资源
|
||||
---
|
||||
|
||||
在一些情况下，我们希望先部署一个组件，等待其成功运行后，再一键部署剩余组件。KubeVela 提供了一个 `apply-remaining` 类型的工作流步骤，可以使用户方便的一键过滤不想要的资源，并部署剩余组件。
|
||||
本节将介绍如何在工作流中通过 `apply-remaining` 部署剩余资源。
|
||||
|
||||
## 如何使用
|
||||
|
||||
部署如下应用部署计划，其工作流中的步骤类型为 `apply-remaining`：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
- name: express-server2
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: express-server3
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: express-server4
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: first-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
- name: manual-approval
|
||||
# 工作流内置 suspend 类型的任务，用于暂停工作流
|
||||
type: suspend
|
||||
- name: remaining-server
|
||||
# 指定步骤类型
|
||||
type: apply-remaining
|
||||
properties:
|
||||
# 指定需要被跳过的组件
|
||||
exceptions:
|
||||
# 配置组件参数
|
||||
express-server:
|
||||
# skipApplyWorkload 表明是否需要跳过组件的部署
|
||||
skipApplyWorkload: true
|
||||
# skipAllTraits 表明是否需要跳过所有运维特征的部署
|
||||
skipAllTraits: true
|
||||
```
|
||||
|
||||
## 期望结果
|
||||
|
||||
查看此时应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
可以看到执行到了 `manual-approval` 步骤时，工作流被暂停执行了：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 2
|
||||
steps:
|
||||
- name: first-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
```
|
||||
|
||||
查看集群中组件的状态，当组件运行成功后，再继续工作流：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 5s
|
||||
|
||||
$ kubectl get ingress
|
||||
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 47s
|
||||
```
|
||||
|
||||
继续该工作流：
|
||||
|
||||
```
|
||||
vela workflow resume first-vela-workflow
|
||||
```
|
||||
|
||||
重新查看应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
可以看到所有步骤的状态均已成功：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: first-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: remaining-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-remaining
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
重新查看集群中组件的状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 110s
|
||||
express-server2 1/1 1 1 6s
|
||||
express-server3 1/1 1 1 6s
|
||||
express-server4 1/1 1 1 6s
|
||||
```
|
||||
|
||||
可以看到，所有的组件都被部署到了集群中，且没有被重复部署。
|
||||
|
||||
通过填写 `apply-remaining` 中提供的参数，可以使用户方便的过滤部署资源。
|
||||
|
|
@ -218,6 +218,62 @@ spec:
|
|||
text: 工作流运行完成
|
||||
```
|
||||
|
||||
## apply-object
|
||||
|
||||
### 简介
|
||||
|
||||
部署 Kubernetes 原生资源，该功能在 KubeVela v1.1.4 及以上版本可使用。
|
||||
|
||||
### 参数
|
||||
|
||||
| 参数名 | 类型 | 说明 |
|
||||
| :-------: | :----: | :-----------------------------------: |
|
||||
| ... | ... | Kubernetes 原生资源字段 |
|
||||
|
||||
### 示例
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: server-with-pvc
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
volumes:
|
||||
- name: "my-pvc"
|
||||
type: "pvc"
|
||||
mountPath: "/test"
|
||||
claimName: "myclaim"
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: apply-pvc
|
||||
type: apply-object
|
||||
properties:
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: myclaim
|
||||
namespace: default
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 8Gi
|
||||
storageClassName: standard
|
||||
- name: apply-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
```
|
||||
|
||||
## suspend
|
||||
|
||||
### 简介
|
||||
|
|
|
|||
|
|
@ -1,175 +0,0 @@
|
|||
---
|
||||
title: 多环境交付
|
||||
---
|
||||
|
||||
本节将介绍如何在工作流中使用多环境功能。
|
||||
|
||||
在多集群的情况下，我们首先需要在测试集群部署应用，等到测试集群的应用一切正常后，再部署到生产集群。KubeVela 提供了一个 `multi-env` 类型的工作流步骤，可以帮助用户方便的管理多环境配置。你可以大致了解它的工作原理，如下所示：
|
||||
|
||||
|
||||
|
||||
本节将介绍如何在工作流使用 `multi-env` 来管理多环境。
|
||||
|
||||
> 在阅读本部分之前，请确保你已经学习了 KubeVela 中的 [Env Binding](../policies/envbinding)。
|
||||
|
||||
## 如何使用
|
||||
|
||||
部署如下应用部署计划，其工作流中的步骤类型为 `multi-env`：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: multi-env-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
|
||||
policies:
|
||||
- name: env
|
||||
type: env-binding
|
||||
properties:
|
||||
created: false
|
||||
envs:
|
||||
- name: test
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
clusterSelector:
|
||||
labels:
|
||||
purpose: test
|
||||
- name: prod
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
clusterSelector:
|
||||
labels:
|
||||
purpose: prod
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
# 指定步骤类型
|
||||
type: deploy2env
|
||||
properties:
|
||||
# 指定组件名称
|
||||
component: nginx-server
|
||||
# 指定 policy 名称
|
||||
policy: env
|
||||
# 指定 policy 中的 env 名称
|
||||
env: test
|
||||
- name: manual-approval
|
||||
# 工作流内置 suspend 类型的任务，用于暂停工作流
|
||||
type: suspend
|
||||
- name: deploy-prod-server
|
||||
type: deploy2env
|
||||
properties:
|
||||
component: nginx-server
|
||||
policy: env
|
||||
env: prod
|
||||
```
|
||||
|
||||
## 期望结果
|
||||
|
||||
查看此时应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
可以看到执行到了 `manual-approval` 步骤时，工作流被暂停执行了：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 2
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
```
|
||||
|
||||
切换到 `test` 集群，并查看应用的状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-server 1/1 1 1 1m10s
|
||||
```
|
||||
|
||||
测试集群的应用一切正常后，使用命令继续工作流：
|
||||
|
||||
```shell
|
||||
$ vela workflow resume multi-env-demo
|
||||
|
||||
Successfully resume workflow: multi-env-demo
|
||||
```
|
||||
|
||||
重新查看应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
可以看到所有步骤的状态均已成功：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: deploy-prod-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
在 `prod` 集群中，查看应用的状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-server 1/1 1 1 1m10s
|
||||
```
|
||||
|
||||
可以看到，使用最新配置的组件已经被成功地部署到了两个集群中。
|
||||
|
||||
通过 `deploy2env`，我们可以轻松地在多个环境中管理应用。
|
||||
|
|
@ -171,4 +171,4 @@ Service `podinfo-server` 绑定了一个 EXTERNAL-IP，允许用户通过公网
|
|||
上述应用部署计划 `workflow-demo` 中使用了内置的应用策略 `env-binding` 对应用部署计划进行差异化配置，修改了组件 `podinfo-server` 的镜像，
|
||||
以及运维特征 `expose` 的类型以允许集群外部的请求访问，同时应用策略 `env-binding` 指定了资源调度策略，将资源部署到新注册的 ACK 集群内。
|
||||
|
||||
应用部署计划的交付工作流也使用了内置的 [`multi-env`](../end-user/workflow/multi-env) 交付工作流定义，指定具体哪一个配置后的组件部署到集群中。
|
||||
应用部署计划的交付工作流也使用了内置的 `deploy2env` 交付工作流定义，指定具体哪一个配置后的组件部署到集群中。
|
||||
|
|
@ -1,132 +0,0 @@
|
|||
---
|
||||
title: 部署组件和运维特征
|
||||
---
|
||||
|
||||
本节将介绍如何在工作流中部署组件和运维特征。
|
||||
|
||||
## 如何使用
|
||||
|
||||
部署如下应用部署计划：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
workflow:
|
||||
steps:
|
||||
- name: express-server
|
||||
# 指定步骤类型
|
||||
type: apply-component
|
||||
properties:
|
||||
# 指定组件名称
|
||||
component: express-server
|
||||
- name: manual-approval
|
||||
# 工作流内置 suspend 类型的任务，用于暂停工作流
|
||||
type: suspend
|
||||
- name: nginx-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: nginx-server
|
||||
```
|
||||
|
||||
在一些情况下，我们在部署某些组件前，需要暂停整个工作流，以等待人工审批。
|
||||
|
||||
在本例中，部署完第一个组件后，工作流会暂停。直到继续的命令被发起后，才开始部署第二个组件。
|
||||
|
||||
部署应用特征计划后，查看工作流状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get app first-vela-workflow
|
||||
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
first-vela-workflow express-server webservice workflowSuspending 2s
|
||||
```
|
||||
|
||||
可以通过 `vela workflow resume` 命令来使工作流继续执行。
|
||||
|
||||
> 有关于 `vela workflow` 命令的介绍，可以详见 [vela cli](../../cli/vela_workflow)。
|
||||
|
||||
```shell
|
||||
$ vela workflow resume first-vela-workflow
|
||||
|
||||
Successfully resume workflow: first-vela-workflow
|
||||
```
|
||||
|
||||
查看应用部署计划，可以看到状态已经变为执行中：
|
||||
|
||||
```shell
|
||||
$ kubectl get app first-vela-workflow
|
||||
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
first-vela-workflow express-server webservice running true 10s
|
||||
```
|
||||
|
||||
## 期望结果
|
||||
|
||||
查看应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
所有步骤的状态均已成功：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: express-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: nginx-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
确认集群中组件的状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 3m28s
|
||||
nginx-server 1/1 1 1 3s
|
||||
|
||||
$ kubectl get ingress
|
||||
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 4m7s
|
||||
```
|
||||
|
||||
可以看到，所有的组件及运维特征都被成功地部署到了集群中。
|
||||
|
|
@ -1,163 +0,0 @@
|
|||
---
|
||||
title: 部署剩余资源
|
||||
---
|
||||
|
||||
在一些情况下，我们希望先部署一个组件，等待其成功运行后，再一键部署剩余组件。KubeVela 提供了一个 `apply-remaining` 类型的工作流步骤，可以使用户方便的一键过滤不想要的资源，并部署剩余组件。
|
||||
本节将介绍如何在工作流中通过 `apply-remaining` 部署剩余资源。
|
||||
|
||||
## 如何使用
|
||||
|
||||
部署如下应用部署计划，其工作流中的步骤类型为 `apply-remaining`：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
- name: express-server2
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: express-server3
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: express-server4
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: first-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
- name: manual-approval
|
||||
# 工作流内置 suspend 类型的任务，用于暂停工作流
|
||||
type: suspend
|
||||
- name: remaining-server
|
||||
# 指定步骤类型
|
||||
type: apply-remaining
|
||||
properties:
|
||||
# 指定需要被跳过的组件
|
||||
exceptions:
|
||||
# 配置组件参数
|
||||
express-server:
|
||||
# skipApplyWorkload 表明是否需要跳过组件的部署
|
||||
skipApplyWorkload: true
|
||||
# skipAllTraits 表明是否需要跳过所有运维特征的部署
|
||||
skipAllTraits: true
|
||||
```
|
||||
|
||||
## 期望结果
|
||||
|
||||
查看此时应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
可以看到执行到了 `manual-approval` 步骤时，工作流被暂停执行了：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 2
|
||||
steps:
|
||||
- name: first-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
```
|
||||
|
||||
查看集群中组件的状态，当组件运行成功后，再继续工作流：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 5s
|
||||
|
||||
$ kubectl get ingress
|
||||
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 47s
|
||||
```
|
||||
|
||||
继续该工作流：
|
||||
|
||||
```
|
||||
vela workflow resume first-vela-workflow
|
||||
```
|
||||
|
||||
重新查看应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
可以看到所有步骤的状态均已成功：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: first-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: remaining-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-remaining
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
重新查看集群中组件的状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 110s
|
||||
express-server2 1/1 1 1 6s
|
||||
express-server3 1/1 1 1 6s
|
||||
express-server4 1/1 1 1 6s
|
||||
```
|
||||
|
||||
可以看到，所有的组件都被部署到了集群中，且没有被重复部署。
|
||||
|
||||
通过填写 `apply-remaining` 中提供的参数，可以使用户方便的过滤部署资源。
|
||||
|
|
@ -218,6 +218,62 @@ spec:
|
|||
text: 工作流运行完成
|
||||
```
|
||||
|
||||
## apply-object
|
||||
|
||||
### 简介
|
||||
|
||||
部署 Kubernetes 原生资源，该功能在 KubeVela v1.1.4 及以上版本可使用。
|
||||
|
||||
### 参数
|
||||
|
||||
| 参数名 | 类型 | 说明 |
|
||||
| :-------: | :----: | :-----------------------------------: |
|
||||
| ... | ... | Kubernetes 原生资源字段 |
|
||||
|
||||
### 示例
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: server-with-pvc
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
volumes:
|
||||
- name: "my-pvc"
|
||||
type: "pvc"
|
||||
mountPath: "/test"
|
||||
claimName: "myclaim"
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: apply-pvc
|
||||
type: apply-object
|
||||
properties:
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: myclaim
|
||||
namespace: default
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 8Gi
|
||||
storageClassName: standard
|
||||
- name: apply-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
```
|
||||
|
||||
## suspend
|
||||
|
||||
### 简介
|
||||
|
|
|
|||
|
|
@ -1,175 +0,0 @@
|
|||
---
|
||||
title: 多环境交付
|
||||
---
|
||||
|
||||
本节将介绍如何在工作流中使用多环境功能。
|
||||
|
||||
在多集群的情况下，我们首先需要在测试集群部署应用，等到测试集群的应用一切正常后，再部署到生产集群。KubeVela 提供了一个 `multi-env` 类型的工作流步骤，可以帮助用户方便的管理多环境配置。你可以大致了解它的工作原理，如下所示：
|
||||
|
||||
|
||||
|
||||
本节将介绍如何在工作流使用 `multi-env` 来管理多环境。
|
||||
|
||||
> 在阅读本部分之前，请确保你已经学习了 KubeVela 中的 [Env Binding](../policies/envbinding)。
|
||||
|
||||
## 如何使用
|
||||
|
||||
部署如下应用部署计划，其工作流中的步骤类型为 `multi-env`：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: multi-env-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
|
||||
policies:
|
||||
- name: env
|
||||
type: env-binding
|
||||
properties:
|
||||
created: false
|
||||
envs:
|
||||
- name: test
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
clusterSelector:
|
||||
labels:
|
||||
purpose: test
|
||||
- name: prod
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
clusterSelector:
|
||||
labels:
|
||||
purpose: prod
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
# 指定步骤类型
|
||||
type: deploy2env
|
||||
properties:
|
||||
# 指定组件名称
|
||||
component: nginx-server
|
||||
# 指定 policy 名称
|
||||
policy: env
|
||||
# 指定 policy 中的 env 名称
|
||||
env: test
|
||||
- name: manual-approval
|
||||
# 工作流内置 suspend 类型的任务，用于暂停工作流
|
||||
type: suspend
|
||||
- name: deploy-prod-server
|
||||
type: deploy2env
|
||||
properties:
|
||||
component: nginx-server
|
||||
policy: env
|
||||
env: prod
|
||||
```
|
||||
|
||||
## 期望结果
|
||||
|
||||
查看此时应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
可以看到执行到了 `manual-approval` 步骤时，工作流被暂停执行了：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 2
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
```
|
||||
|
||||
切换到 `test` 集群，并查看应用的状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-server 1/1 1 1 1m10s
|
||||
```
|
||||
|
||||
测试集群的应用一切正常后，使用命令继续工作流：
|
||||
|
||||
```shell
|
||||
$ vela workflow resume multi-env-demo
|
||||
|
||||
Successfully resume workflow: multi-env-demo
|
||||
```
|
||||
|
||||
重新查看应用的状态：
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
可以看到所有步骤的状态均已成功：
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: deploy-prod-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
在 `prod` 集群中，查看应用的状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-server 1/1 1 1 1m10s
|
||||
```
|
||||
|
||||
可以看到，使用最新配置的组件已经被成功地部署到了两个集群中。
|
||||
|
||||
通过 `deploy2env`，我们可以轻松地在多个环境中管理应用。
|
||||
|
|
@ -1,131 +0,0 @@
|
|||
---
|
||||
title: Apply Components and Traits
|
||||
---
|
||||
|
||||
In this guide, you will learn how to apply components and traits in `Workflow`.
|
||||
|
||||
## How to use
|
||||
|
||||
Apply the following `Application`:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
workflow:
|
||||
steps:
|
||||
- name: express-server
|
||||
# specify the workflow step type
|
||||
type: apply-component
|
||||
properties:
|
||||
# specify the component name
|
||||
component: express-server
|
||||
- name: manual-approval
|
||||
# suspend is a built-in task of workflow used to suspend the workflow
|
||||
type: suspend
|
||||
- name: nginx-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: nginx-server
|
||||
```
|
||||
|
||||
If we want to suspend the workflow for manual approval before applying some certain components, we can use `suspend` step to pause the workflow.
|
||||
|
||||
In this case, the workflow will be suspended after applying the first component. The second component will wait to be applied util the `resume` command is called.
|
||||
|
||||
Check the status after applying the `Application`:
|
||||
|
||||
```shell
|
||||
$ kubectl get app first-vela-workflow
|
||||
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
first-vela-workflow express-server webservice workflowSuspending 2s
|
||||
```
|
||||
|
||||
We can use `vela workflow resume` to resume the workflow.
|
||||
|
||||
> For more information of `vela workflow`，please ref [vela cli](../../cli/vela_workflow).
|
||||
|
||||
```shell
|
||||
$ vela workflow resume first-vela-workflow
|
||||
|
||||
Successfully resume workflow: first-vela-workflow
|
||||
```
|
||||
|
||||
Check the status, the `Application` is now `runningWorkflow`:
|
||||
|
||||
```shell
|
||||
$ kubectl get app first-vela-workflow
|
||||
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
first-vela-workflow express-server webservice running true 10s
|
||||
```
|
||||
## Expected outcome
|
||||
|
||||
Check the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
All the step status in workflow is succeeded:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: express-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: nginx-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
Check the component status in cluster:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 3m28s
|
||||
nginx-server 1/1 1 1 3s
|
||||
|
||||
$ kubectl get ingress
|
||||
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 4m7s
|
||||
```
|
||||
|
||||
We can see that all the components and traits have been applied to the cluster.
|
||||
|
|
@ -1,164 +0,0 @@
|
|||
---
|
||||
title: Apply Remaining
|
||||
---
|
||||
|
||||
If we want to apply one component first and then apply the rest of the components after the first one is running, KubeVela provides the `apply-remaining` workflow step to filter out selected resources and apply remaining.
|
||||
|
||||
In this guide, you will learn how to apply remaining resources via `apply-remaining` in `Workflow`.
|
||||
|
||||
## How to use
|
||||
|
||||
Apply the following `Application` with workflow step type of `apply-remaining`:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
- name: express-server2
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: express-server3
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
- name: express-server4
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: first-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
- name: manual-approval
|
||||
# suspend is a built-in task of workflow used to suspend the workflow
|
||||
type: suspend
|
||||
- name: remaining-server
|
||||
# specify the workflow step type
|
||||
type: apply-remaining
|
||||
properties:
|
||||
# specify the component that needs to be skipped
|
||||
exceptions:
|
||||
# specify the configuration of the component
|
||||
express-server:
|
||||
# skipApplyWorkload indicates whether to skip apply the workload resource
|
||||
skipApplyWorkload: true
|
||||
# skipAllTraits indicates to skip apply all resources of the traits
|
||||
skipAllTraits: true
|
||||
```
|
||||
|
||||
## Expected outcome
|
||||
|
||||
Check the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
We can see that the workflow is suspended at `manual-approval`:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 2
|
||||
steps:
|
||||
- name: first-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
```
|
||||
|
||||
Check the component status in cluster and resume the workflow after the component is running:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 5s
|
||||
|
||||
$ kubectl get ingress
|
||||
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 47s
|
||||
```
|
||||
|
||||
Resume the workflow:
|
||||
|
||||
```
|
||||
vela workflow resume first-vela-workflow
|
||||
```
|
||||
|
||||
Recheck the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application first-vela-workflow -o yaml
|
||||
```
|
||||
|
||||
All the step status in workflow is succeeded:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: first-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-component
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: remaining-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: apply-remaining
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
Recheck the component status:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 110s
|
||||
express-server2 1/1 1 1 6s
|
||||
express-server3 1/1 1 1 6s
|
||||
express-server4 1/1 1 1 6s
|
||||
```
|
||||
|
||||
We can see that all of the components has been applied to the cluster successfully. Besides, the first component `express-server` is not applied repeatedly.
|
||||
|
||||
With `apply-remaining`, we can easily filter and apply resources by filling in the built-in parameters.
|
||||
|
|
@ -218,6 +218,62 @@ spec:
|
|||
text: Workflow ended.
|
||||
```
|
||||
|
||||
## apply-object
|
||||
|
||||
### Overview
|
||||
|
||||
Apply Kubernetes native resources, you need to upgrade to KubeVela v1.1.4 or higher to enable `apply-object`.
|
||||
|
||||
### Parameters
|
||||
|
||||
| Name | Type | Description |
|
||||
| :-------: | :----: | :-----------------------------------: |
|
||||
| ... | ... | Kubernetes native resources fields |
|
||||
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: server-with-pvc
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
volumes:
|
||||
- name: "my-pvc"
|
||||
type: "pvc"
|
||||
mountPath: "/test"
|
||||
claimName: "myclaim"
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: apply-pvc
|
||||
type: apply-object
|
||||
properties:
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: myclaim
|
||||
namespace: default
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 8Gi
|
||||
storageClassName: standard
|
||||
- name: apply-server
|
||||
type: apply-component
|
||||
properties:
|
||||
component: express-server
|
||||
```
|
||||
|
||||
## suspend
|
||||
|
||||
### Overview
|
||||
|
|
|
|||
|
|
@ -1,173 +0,0 @@
|
|||
---
|
||||
title: Multi Environments
|
||||
---
|
||||
|
||||
If we have multiple clusters, we want to apply our application in the test cluster first, and then apply it to the production cluster after the application in test cluster is running. KubeVela provides the `deploy2env` workflow step to manage multi environments. You can have a glimpse of how does it work as below:
|
||||
|
||||
|
||||
|
||||
In this guide, you will learn how to manage multi environments via `deploy2env` in `Workflow`.
|
||||
|
||||
> Before reading this section, please make sure you have learned about the [Env Binding](../policies/envbinding) in KubeVela.
|
||||
|
||||
## How to use
|
||||
|
||||
Apply the following `Application` with workflow step type of `deploy2env`:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: multi-env-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
|
||||
policies:
|
||||
- name: env
|
||||
type: env-binding
|
||||
properties:
|
||||
created: false
|
||||
envs:
|
||||
- name: test
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
clusterSelector:
|
||||
labels:
|
||||
purpose: test
|
||||
- name: prod
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
clusterSelector:
|
||||
labels:
|
||||
purpose: prod
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
# specify the workflow step type
|
||||
type: deploy2env
|
||||
properties:
|
||||
# specify the component name
|
||||
component: nginx-server
|
||||
# specify the policy name
|
||||
policy: env
|
||||
# specify the env name in policy
|
||||
env: test
|
||||
- name: manual-approval
|
||||
# suspend is a built-in task of workflow used to suspend the workflow
|
||||
type: suspend
|
||||
- name: deploy-prod-server
|
||||
type: deploy2env
|
||||
properties:
|
||||
component: nginx-server
|
||||
policy: env
|
||||
env: prod
|
||||
```
|
||||
|
||||
## Expected outcome
|
||||
|
||||
Check the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
We can see that the workflow is suspended at `manual-approval`:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 2
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
```
|
||||
|
||||
Switch to `test` cluster and check the component status:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-server 1/1 1 1 1m10s
|
||||
```
|
||||
|
||||
Use `resume` command after everything is ok in test cluster:
|
||||
|
||||
```shell
|
||||
$ vela workflow resume multi-env-demo
|
||||
|
||||
Successfully resume workflow: multi-env-demo
|
||||
```
|
||||
|
||||
Recheck the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
All the step status in workflow is succeeded:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: deploy-prod-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: deploy2env
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
Then, check the component status in `prod` cluster:
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-server 1/1 1 1 1m10s
|
||||
```
|
||||
|
||||
We can see that the component have been applied to both clusters.
|
||||
|
||||
With `deploy2env`, we can easily manage applications in multiple environments.
|
||||
Loading…
Reference in New Issue