Docs: optimize init doc and make version 1.1 (#341)
* Docs: optimize init doc and make version 1.1 * Fix in workflow def
This commit is contained in:
Tianxin Dong
GitHub
parent
43bbaf026d
commit
88ea46964f
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Initialize custom environment
|
||||
title: Initialize environment
|
||||
---
|
||||
|
||||
This case will introduce what is environment and how to initialize an environment.
|
||||
|
|
@ -18,9 +18,7 @@ In general, the resource types that can be initialized include the following typ
|
|||
|
||||
3. All kinds of shared resources and services. For example. shared resources in microservices. These shared resources can be a microservice component, cloud database, cache, load balancer, API gateway, and so on.
|
||||
|
||||
4. Various management policies and processes. An environment may have different global policies. The policy can be initializing a database table, registering an automatic discovery configuration, and so on.
|
||||
|
||||
## Initialize the environment
|
||||
4. Various management policies and processes. An environment may have different global policies. The policy can be chaos test, security scan, SLO and son on; the process can be initializing a database table, registering an automatic discovery configuration, and so on.
|
||||
|
||||
KubeVela allows you to use different resources to initialize the environment.
|
||||
|
||||
|
|
@ -34,13 +32,20 @@ For example, if both the test and develop environments rely on the same controll
|
|||
|
||||
### Directly use Application for initialization
|
||||
|
||||
If we want to use `kruise` in cluster, we can use `Helm` to initialize `kruise`.
|
||||
> Make sure your KubeVela version is `v1.1.6+`.
|
||||
|
||||
We can directly use Application to initialize a kruise environment. The application below will deploy a kruise controller in cluster:
|
||||
If we want to use some CRD controller like [OpenKruise](https://github.com/openkruise/kruise) in cluster, we can use `Helm` to initialize `kruise`.
|
||||
|
||||
We can directly use Application to initialize a kruise environment. The application below will deploy a kruise controller in cluster.
|
||||
|
||||
We have to enable `fluxcd` in cluster since we use `Helm` to deploy kruise.
|
||||
We can use `depends-on-app` to make sure `fluxcd` is deployed before kruise.
|
||||
|
||||
> `depends-on-app` will check if the cluster has the application with `name` and `namespace` defines in `properties`.
|
||||
> If the application exists, the next step will be executed after the application is running.
|
||||
> If the application do not exists, KubeVela will check the ConfigMap with the same name, and read the config of the Application and apply to cluster.
|
||||
> For more information, please refer to [depends-on-app](../end-user/workflow/built-in-workflow-defs#depends-on-app).
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
|
|
@ -73,7 +78,7 @@ spec:
|
|||
EOF
|
||||
```
|
||||
|
||||
After applying the files, we can check the application in cluster:
|
||||
Check the application in cluster:
|
||||
|
||||
```shell
|
||||
$ vela ls -n vela-system
|
||||
|
|
@ -82,26 +87,7 @@ kruise ... raw running healthy 2021
|
|||
fluxcd ... raw running healthy 2021-09-24 20:59:06 +0800 CST
|
||||
```
|
||||
|
||||
Kruise is running successfully! Then you can use kruise in your cluster. If you need to set up a new environment, the only thing you need to do is to apply the files above.
|
||||
|
||||
#### Customize initialization dependencies
|
||||
|
||||
In the example above, `depends-on-app` means this initialization depends on the ability of fluxcd.
|
||||
|
||||
`depends-on-app` will check if the cluster has the application with `name` and `namespace` defines in `properties`.
|
||||
|
||||
If the application exists, the next step will be executed after the application is running.
|
||||
If the application do not exists, KubeVela will check the configMap with the same name, and read the config of the Application and apply to cluster.
|
||||
> If the application do not exists, we need configMap like below:
|
||||
> ```yaml
|
||||
> apiVersion: v1
|
||||
> kind: ConfigMap
|
||||
> metadata:
|
||||
> name: fluxcd
|
||||
> namespace: vela-system
|
||||
> data:
|
||||
> fluxcd: ...
|
||||
> ```
|
||||
Kruise is running successfully! Then you can use kruise in your cluster. If you need to set up a new environment, the only thing you need to do is to apply the files like above.
|
||||
|
||||
### Add initialize workflow in application
|
||||
|
||||
|
|
|
|||
|
|
@ -47,6 +47,20 @@ spec:
|
|||
|
||||
Wait for the specified Application to complete.
|
||||
|
||||
> `depends-on-app` will check if the cluster has the application with `name` and `namespace` defines in `properties`.
|
||||
> If the application exists, the next step will be executed after the application is running.
|
||||
> If the application do not exists, KubeVela will check the ConfigMap with the same name, and read the config of the Application and apply to cluster.
|
||||
> The ConfigMap is like below: the `name` and `namespace` of the ConfigMap is the same in properties. In data, the key is `name`, and the value is the yaml of the deployed application yaml.
|
||||
> ```yaml
|
||||
> apiVersion: v1
|
||||
> kind: ConfigMap
|
||||
> metadata:
|
||||
> name: myapp
|
||||
> namespace: vela-system
|
||||
> data:
|
||||
> myapp: ...
|
||||
> ```
|
||||
|
||||
### Parameter
|
||||
|
||||
| Name | Type | Description |
|
||||
|
|
|
|||
|
|
@ -45,7 +45,6 @@ func main() {
|
|||
d := strings.Index(s, ")")
|
||||
subStr := s[:d]
|
||||
targetFilePath := filepath.Clean(targetDir + "/" + subStr)
|
||||
//fmt.Println(path, subStr, "=>", targetFilePath)
|
||||
if _, err1 := os.Stat(targetFilePath); err1 != nil {
|
||||
if _, err2 := os.Stat(targetFilePath + ".md"); err2 != nil {
|
||||
ss := strings.LastIndex(targetFilePath, "#")
|
||||
|
|
@ -70,5 +69,5 @@ func main() {
|
|||
cnt++
|
||||
return nil
|
||||
})
|
||||
fmt.Printf("%d total files effected\n", cnt)
|
||||
fmt.Printf("%d total files checked\n", cnt)
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,16 +1,15 @@
|
|||
---
|
||||
title: 自定义环境初始化
|
||||
title: 初始化环境
|
||||
---
|
||||
|
||||
本案例将介绍环境的概念以及如何初始化一个环境。
|
||||
本案例将介绍如何使用 KubeVela 在交付应用时对环境进行初始化。
|
||||
|
||||
## 什么是环境？
|
||||
|
||||
一个应用开发团队通常需要初始化一些共享环境供用户部署他们的应用部署计划（Application）。环境是一个逻辑概念，他表示一组应用部署计划依赖的公共资源。
|
||||
例如，一个团队想要初始化2个环境： 一个开发环境用于开发和测试，一个生产环境用于实际应用部署并提供对外服务。
|
||||
管理员可以针对环境所代表的实际含义配置相关的初始化方式，创建不同的资源。
|
||||
一个应用开发团队通常需要做一些初始化工作来满足应用部署时方方面面的需要，即“初始化环境”。
|
||||
这里的环境是一个逻辑概念，既可以表示应用部署时依赖的公共资源，也可以表示应用运行必要的准备工作。
|
||||
|
||||
环境初始化背后也是用 OAM 模型的方式来执行的，所以环境初始化控制器的功能非常灵活，几乎可以满足任何初始化的需求，同时也是可插拔的。通常而言，可以初始化的资源类型包括但不限于下列类型：
|
||||
KubeVela 同样是 Application 对象做环境的初始化，可以初始化的资源类型包括但不限于下列类型：
|
||||
|
||||
1. 一个或多个 Kubernetes 集群，不同的环境可能需要不同规模和不同版本的 Kubernetes 集群。同时环境初始化还可以将多个 Kubernetes 集群注册到一个中央集群进行统一的多集群管控。
|
||||
|
||||
|
|
@ -20,27 +19,31 @@ title: 自定义环境初始化
|
|||
|
||||
4. 各类管理策略和流程，一个环境可能会配备不同的全局策略和流程，举例来说，环境策略可能会包括混沌测试、安全扫描、错误配置检测、SLO指标等等；而流程则可以是初始化一个数据库表、注册一个自动发现配置等。
|
||||
|
||||
## 环境初始化
|
||||
不仅如此，KubeVela 的环境初始化能力还可以跟工作流、策略、依赖等功能相结合，做不同环境的差异化部署，依赖管理等。
|
||||
|
||||
KubeVela 允许你自定义组合不同的资源来初始化环境。
|
||||
|
||||
你可以利用应用部署计划中的 “应用的执行策略（Policy）” 和 “部署工作流（Workflow）” 来流程化、配置化地创建环境。需要注意的是，多个环境初始化
|
||||
之间可能会存在依赖关系，一个环境初始化会依赖其他环境初始化提供的能力。我们通过工作流中的 `depends-on-app` 来完成依赖关系的确定。
|
||||
|
||||
不同环境初始化存在依赖关系，可以将不同环境初始化的公共资源分离出一个单独的环境初始化作为依赖，这样可以形成可以被复用的初始化模块。
|
||||
若不同环境初始化存在依赖关系，可以初始化的公共资源分离出一个单独的 Application 作为依赖，这样可以形成可以被复用的初始化模块。
|
||||
例如，测试环境和开发环境都依赖了一些相同的控制器，可以将这些控制器提取出来作为单独的环境初始化，在开发环境和测试环境中都指定依赖该环境初始化。
|
||||
|
||||
## 如何使用
|
||||
|
||||
### 直接使用应用部署计划完成环境初始化
|
||||
|
||||
如果我们希望在环境中使用 kruise 的能力，那么，我们可以使用 Helm 组件初始化 kruise。
|
||||
> 请确保你的 KubeVela 版本在 v1.1.6 及以上。
|
||||
|
||||
我们可以直接使用应用部署计划来初始化 kruise 的环境，该应用会帮你在集群中部署一个 [kruise](https://github.com/openkruise/kruise) 的控制器，给集群提供 kruise 的各种能力：
|
||||
如果我们希望在环境中使用一个自定义 CRD 控制器(如 [OpenKruise](https://github.com/openkruise/kruise))，那么，我们可以使用 Helm 组件初始化 kruise。
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
我们可以直接使用 KubeVela 的应用部署计划来初始化 kruise 的环境，该应用会帮你在集群中部署一个 OpenKruise 的控制器，给集群提供 kruise 的各种能力。
|
||||
|
||||
由于我们使用 Helm 组件完成 kruise 的部署，我们首先要在集群中使用 `fluxcd` 开启 helm 功能。
|
||||
当环境初始化具备多个模块时，可以对初始化的内容进行拆分，同时使用工作流的 `depends-on-app` 步骤，描述不同初始化模块的依赖关系。
|
||||
比如我们可以在这个例子里，使用 `depends-on-app` 表示环境初始化 kruise 依赖环境初始化 fluxcd 提供的能力。
|
||||
|
||||
> `depends-on-app` 会根据 `properties` 中的 `name` 及 `namespace`，去查询集群中是否存在对应的应用。
|
||||
如果应用存在，则当该应用的状态可用时，才会进行下一个步骤；
|
||||
若该应用不存在，则会去查询同名的 configMap，从中读取出应用的配置并部署到集群中。
|
||||
> 更详细的说明，请查看 [depends-on-app](../end-user/workflow/built-in-workflow-defs#depends-on-app)。
|
||||
|
||||
部署如下文件：
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
|
|
@ -73,7 +76,7 @@ spec:
|
|||
EOF
|
||||
```
|
||||
|
||||
部署如上文件后，可以查看集群中应用的状态：
|
||||
查看集群中应用的状态：
|
||||
|
||||
```shell
|
||||
$ vela ls -n vela-system
|
||||
|
|
@ -82,26 +85,7 @@ kruise ... raw running healthy 2021
|
|||
fluxcd ... raw running healthy 2021-09-24 20:59:06 +0800 CST
|
||||
```
|
||||
|
||||
kruise 已经成功运行！之后，你可以在环境中使用 kruise 的能力。如果需要配置新的环境，也只需要部署如上应用文件。
|
||||
|
||||
#### 自定义初始化依赖关系
|
||||
|
||||
在应用的工作流中，`depends-on-app` 表示环境初始化 kruise 依赖环境初始化 fluxcd 提供的能力。
|
||||
|
||||
`depends-on-app` 会根据 `properties` 中的 `name` 及 `namespace`，去查询集群中是否存在对应的应用。
|
||||
|
||||
如果应用存在，则当该应用的状态可用时，才会进行下一个步骤；
|
||||
若该应用不存在，则会去查询同名的 configMap，从中读取出应用的配置并部署到集群中。
|
||||
> 若应用不存在，则需要形如下的 configMap：
|
||||
> ```yaml
|
||||
> apiVersion: v1
|
||||
> kind: ConfigMap
|
||||
> metadata:
|
||||
> name: fluxcd
|
||||
> namespace: vela-system
|
||||
> data:
|
||||
> fluxcd: ...
|
||||
> ```
|
||||
kruise 已经成功运行！之后，你可以在环境中使用 kruise 的能力。如果需要配置新的环境初始化，也只需要类似的定义一个部署计划。
|
||||
|
||||
### 在应用部署中加入初始化的工作流
|
||||
|
||||
|
|
|
|||
|
|
@ -47,6 +47,21 @@ spec:
|
|||
|
||||
等待指定的 Application 完成。
|
||||
|
||||
`depends-on-app` 会根据 `properties` 中的 `name` 及 `namespace`，去查询集群中是否存在对应的应用。
|
||||
|
||||
如果应用存在，则当该应用的状态可用时，才会进行下一个步骤；
|
||||
若该应用不存在，则会去查询同名的 configMap，从中读取出应用的配置并部署到集群中。
|
||||
> 若应用不存在，则需要形如下的 configMap：`name` 与 `namespace` 和 `properties` 中声明的保持一致，在 `data` 中，以 `name` 为 key，实际的 value 为需要部署的 KubeVela Application yaml。
|
||||
> ```yaml
|
||||
> apiVersion: v1
|
||||
> kind: ConfigMap
|
||||
> metadata:
|
||||
> name: myapp
|
||||
> namespace: vela-system
|
||||
> data:
|
||||
> myapp: ...
|
||||
> ```
|
||||
|
||||
### 参数
|
||||
|
||||
| 参数名 | 类型 | 说明 |
|
||||
|
|
|
|||
|
|
@ -1,16 +1,15 @@
|
|||
---
|
||||
title: 自定义环境初始化
|
||||
title: 初始化环境
|
||||
---
|
||||
|
||||
本案例将介绍环境的概念以及如何初始化一个环境。
|
||||
本案例将介绍如何使用 KubeVela 在交付应用时对环境进行初始化。
|
||||
|
||||
## 什么是环境？
|
||||
|
||||
一个应用开发团队通常需要初始化一些共享环境供用户部署他们的应用部署计划（Application）。环境是一个逻辑概念，他表示一组应用部署计划依赖的公共资源。
|
||||
例如，一个团队想要初始化2个环境： 一个开发环境用于开发和测试，一个生产环境用于实际应用部署并提供对外服务。
|
||||
管理员可以针对环境所代表的实际含义配置相关的初始化方式，创建不同的资源。
|
||||
一个应用开发团队通常需要做一些初始化工作来满足应用部署时方方面面的需要，即“初始化环境”。
|
||||
这里的环境是一个逻辑概念，既可以表示应用部署时依赖的公共资源，也可以表示应用运行必要的准备工作。
|
||||
|
||||
环境初始化背后也是用 OAM 模型的方式来执行的，所以环境初始化控制器的功能非常灵活，几乎可以满足任何初始化的需求，同时也是可插拔的。通常而言，可以初始化的资源类型包括但不限于下列类型：
|
||||
KubeVela 同样是 Application 对象做环境的初始化，可以初始化的资源类型包括但不限于下列类型：
|
||||
|
||||
1. 一个或多个 Kubernetes 集群，不同的环境可能需要不同规模和不同版本的 Kubernetes 集群。同时环境初始化还可以将多个 Kubernetes 集群注册到一个中央集群进行统一的多集群管控。
|
||||
|
||||
|
|
@ -20,27 +19,31 @@ title: 自定义环境初始化
|
|||
|
||||
4. 各类管理策略和流程，一个环境可能会配备不同的全局策略和流程，举例来说，环境策略可能会包括混沌测试、安全扫描、错误配置检测、SLO指标等等；而流程则可以是初始化一个数据库表、注册一个自动发现配置等。
|
||||
|
||||
## 环境初始化
|
||||
不仅如此，KubeVela 的环境初始化能力还可以跟工作流、策略、依赖等功能相结合，做不同环境的差异化部署，依赖管理等。
|
||||
|
||||
KubeVela 允许你自定义组合不同的资源来初始化环境。
|
||||
|
||||
你可以利用应用部署计划中的 “应用的执行策略（Policy）” 和 “部署工作流（Workflow）” 来流程化、配置化地创建环境。需要注意的是，多个环境初始化
|
||||
之间可能会存在依赖关系，一个环境初始化会依赖其他环境初始化提供的能力。我们通过工作流中的 `depends-on-app` 来完成依赖关系的确定。
|
||||
|
||||
不同环境初始化存在依赖关系，可以将不同环境初始化的公共资源分离出一个单独的环境初始化作为依赖，这样可以形成可以被复用的初始化模块。
|
||||
若不同环境初始化存在依赖关系，可以初始化的公共资源分离出一个单独的 Application 作为依赖，这样可以形成可以被复用的初始化模块。
|
||||
例如，测试环境和开发环境都依赖了一些相同的控制器，可以将这些控制器提取出来作为单独的环境初始化，在开发环境和测试环境中都指定依赖该环境初始化。
|
||||
|
||||
## 如何使用
|
||||
|
||||
### 直接使用应用部署计划完成环境初始化
|
||||
|
||||
如果我们希望在环境中使用 kruise 的能力，那么，我们可以使用 Helm 组件初始化 kruise。
|
||||
> 请确保你的 KubeVela 版本在 v1.1.6 及以上。
|
||||
|
||||
我们可以直接使用应用部署计划来初始化 kruise 的环境，该应用会帮你在集群中部署一个 [kruise](https://github.com/openkruise/kruise) 的控制器，给集群提供 kruise 的各种能力：
|
||||
如果我们希望在环境中使用一个自定义 CRD 控制器(如 [OpenKruise](https://github.com/openkruise/kruise))，那么，我们可以使用 Helm 组件初始化 kruise。
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
我们可以直接使用 KubeVela 的应用部署计划来初始化 kruise 的环境，该应用会帮你在集群中部署一个 OpenKruise 的控制器，给集群提供 kruise 的各种能力。
|
||||
|
||||
由于我们使用 Helm 组件完成 kruise 的部署，我们首先要在集群中使用 `fluxcd` 开启 helm 功能。
|
||||
当环境初始化具备多个模块时，可以对初始化的内容进行拆分，同时使用工作流的 `depends-on-app` 步骤，描述不同初始化模块的依赖关系。
|
||||
比如我们可以在这个例子里，使用 `depends-on-app` 表示环境初始化 kruise 依赖环境初始化 fluxcd 提供的能力。
|
||||
|
||||
> `depends-on-app` 会根据 `properties` 中的 `name` 及 `namespace`，去查询集群中是否存在对应的应用。
|
||||
如果应用存在，则当该应用的状态可用时，才会进行下一个步骤；
|
||||
若该应用不存在，则会去查询同名的 configMap，从中读取出应用的配置并部署到集群中。
|
||||
> 更详细的说明，请查看 [depends-on-app](../end-user/workflow/built-in-workflow-defs#depends-on-app)。
|
||||
|
||||
部署如下文件：
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
|
|
@ -73,7 +76,7 @@ spec:
|
|||
EOF
|
||||
```
|
||||
|
||||
部署如上文件后，可以查看集群中应用的状态：
|
||||
查看集群中应用的状态：
|
||||
|
||||
```shell
|
||||
$ vela ls -n vela-system
|
||||
|
|
@ -82,26 +85,7 @@ kruise ... raw running healthy 2021
|
|||
fluxcd ... raw running healthy 2021-09-24 20:59:06 +0800 CST
|
||||
```
|
||||
|
||||
kruise 已经成功运行！之后，你可以在环境中使用 kruise 的能力。如果需要配置新的环境，也只需要部署如上应用文件。
|
||||
|
||||
#### 自定义初始化依赖关系
|
||||
|
||||
在应用的工作流中，`depends-on-app` 表示环境初始化 kruise 依赖环境初始化 fluxcd 提供的能力。
|
||||
|
||||
`depends-on-app` 会根据 `properties` 中的 `name` 及 `namespace`，去查询集群中是否存在对应的应用。
|
||||
|
||||
如果应用存在，则当该应用的状态可用时，才会进行下一个步骤；
|
||||
若该应用不存在，则会去查询同名的 configMap，从中读取出应用的配置并部署到集群中。
|
||||
> 若应用不存在，则需要形如下的 configMap：
|
||||
> ```yaml
|
||||
> apiVersion: v1
|
||||
> kind: ConfigMap
|
||||
> metadata:
|
||||
> name: fluxcd
|
||||
> namespace: vela-system
|
||||
> data:
|
||||
> fluxcd: ...
|
||||
> ```
|
||||
kruise 已经成功运行！之后，你可以在环境中使用 kruise 的能力。如果需要配置新的环境初始化，也只需要类似的定义一个部署计划。
|
||||
|
||||
### 在应用部署中加入初始化的工作流
|
||||
|
||||
|
|
|
|||
|
|
@ -47,6 +47,21 @@ spec:
|
|||
|
||||
等待指定的 Application 完成。
|
||||
|
||||
`depends-on-app` 会根据 `properties` 中的 `name` 及 `namespace`，去查询集群中是否存在对应的应用。
|
||||
|
||||
如果应用存在，则当该应用的状态可用时，才会进行下一个步骤；
|
||||
若该应用不存在，则会去查询同名的 configMap，从中读取出应用的配置并部署到集群中。
|
||||
> 若应用不存在，则需要形如下的 configMap：`name` 与 `namespace` 和 `properties` 中声明的保持一致，在 `data` 中，以 `name` 为 key，实际的 value 为需要部署的 KubeVela Application yaml。
|
||||
> ```yaml
|
||||
> apiVersion: v1
|
||||
> kind: ConfigMap
|
||||
> metadata:
|
||||
> name: myapp
|
||||
> namespace: vela-system
|
||||
> data:
|
||||
> myapp: ...
|
||||
> ```
|
||||
|
||||
### 参数
|
||||
|
||||
| 参数名 | 类型 | 说明 |
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Initialize custom environment
|
||||
title: Initialize environment
|
||||
---
|
||||
|
||||
This case will introduce what is environment and how to initialize an environment.
|
||||
|
|
@ -18,9 +18,7 @@ In general, the resource types that can be initialized include the following typ
|
|||
|
||||
3. All kinds of shared resources and services. For example. shared resources in microservices. These shared resources can be a microservice component, cloud database, cache, load balancer, API gateway, and so on.
|
||||
|
||||
4. Various management policies and processes. An environment may have different global policies. The policy can be initializing a database table, registering an automatic discovery configuration, and so on.
|
||||
|
||||
## Initialize the environment
|
||||
4. Various management policies and processes. An environment may have different global policies. The policy can be chaos test, security scan, SLO and son on; the process can be initializing a database table, registering an automatic discovery configuration, and so on.
|
||||
|
||||
KubeVela allows you to use different resources to initialize the environment.
|
||||
|
||||
|
|
@ -34,13 +32,20 @@ For example, if both the test and develop environments rely on the same controll
|
|||
|
||||
### Directly use Application for initialization
|
||||
|
||||
If we want to use `kruise` in cluster, we can use `Helm` to initialize `kruise`.
|
||||
> Make sure your KubeVela version is `v1.1.6+`.
|
||||
|
||||
We can directly use Application to initialize a kruise environment. The application below will deploy a kruise controller in cluster:
|
||||
If we want to use some CRD controller like [OpenKruise](https://github.com/openkruise/kruise) in cluster, we can use `Helm` to initialize `kruise`.
|
||||
|
||||
We can directly use Application to initialize a kruise environment. The application below will deploy a kruise controller in cluster.
|
||||
|
||||
We have to enable `fluxcd` in cluster since we use `Helm` to deploy kruise.
|
||||
We can use `depends-on-app` to make sure `fluxcd` is deployed before kruise.
|
||||
|
||||
> `depends-on-app` will check if the cluster has the application with `name` and `namespace` defines in `properties`.
|
||||
> If the application exists, the next step will be executed after the application is running.
|
||||
> If the application do not exists, KubeVela will check the ConfigMap with the same name, and read the config of the Application and apply to cluster.
|
||||
> For more information, please refer to [depends-on-app](../end-user/workflow/built-in-workflow-defs#depends-on-app).
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
|
|
@ -73,7 +78,7 @@ spec:
|
|||
EOF
|
||||
```
|
||||
|
||||
After applying the files, we can check the application in cluster:
|
||||
Check the application in cluster:
|
||||
|
||||
```shell
|
||||
$ vela ls -n vela-system
|
||||
|
|
@ -82,26 +87,7 @@ kruise ... raw running healthy 2021
|
|||
fluxcd ... raw running healthy 2021-09-24 20:59:06 +0800 CST
|
||||
```
|
||||
|
||||
Kruise is running successfully! Then you can use kruise in your cluster. If you need to set up a new environment, the only thing you need to do is to apply the files above.
|
||||
|
||||
#### Customize initialization dependencies
|
||||
|
||||
In the example above, `depends-on-app` means this initialization depends on the ability of fluxcd.
|
||||
|
||||
`depends-on-app` will check if the cluster has the application with `name` and `namespace` defines in `properties`.
|
||||
|
||||
If the application exists, the next step will be executed after the application is running.
|
||||
If the application do not exists, KubeVela will check the configMap with the same name, and read the config of the Application and apply to cluster.
|
||||
> If the application do not exists, we need configMap like below:
|
||||
> ```yaml
|
||||
> apiVersion: v1
|
||||
> kind: ConfigMap
|
||||
> metadata:
|
||||
> name: fluxcd
|
||||
> namespace: vela-system
|
||||
> data:
|
||||
> fluxcd: ...
|
||||
> ```
|
||||
Kruise is running successfully! Then you can use kruise in your cluster. If you need to set up a new environment, the only thing you need to do is to apply the files like above.
|
||||
|
||||
### Add initialize workflow in application
|
||||
|
||||
|
|
|
|||
|
|
@ -47,6 +47,20 @@ spec:
|
|||
|
||||
Wait for the specified Application to complete.
|
||||
|
||||
> `depends-on-app` will check if the cluster has the application with `name` and `namespace` defines in `properties`.
|
||||
> If the application exists, the next step will be executed after the application is running.
|
||||
> If the application do not exists, KubeVela will check the ConfigMap with the same name, and read the config of the Application and apply to cluster.
|
||||
> The ConfigMap is like below: the `name` and `namespace` of the ConfigMap is the same in properties. In data, the key is `name`, and the value is the yaml of the deployed application yaml.
|
||||
> ```yaml
|
||||
> apiVersion: v1
|
||||
> kind: ConfigMap
|
||||
> metadata:
|
||||
> name: myapp
|
||||
> namespace: vela-system
|
||||
> data:
|
||||
> myapp: ...
|
||||
> ```
|
||||
|
||||
### Parameter
|
||||
|
||||
| Name | Type | Description |
|
||||
|
|
|
|||
Loading…
Reference in New Issue