refactor definition docs (#944)
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com> Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
GitHub
parent
aa8e0b4b07
commit
157b3c3af5
|
|
@ -2,9 +2,15 @@
|
|||
title: Definition
|
||||
---
|
||||
|
||||
Definition are the basic building block of the KubeVela platform. A definition encapsulates an arbitrarily complex automation as a lego style module that can be used to compose an Application, then safely shared, and repeatably executed by any KubeVela engine.
|
||||
OAM Definitions are basic building blocks of the KubeVela platform. A definition encapsulates an arbitrarily complex automation as a lego style module, then safely shared, discovered and be used to compose an Application delivered by any KubeVela engine.
|
||||
|
||||
There're four types of Definition, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts.
|
||||
With the help of OAM definitions, the platform builder can easily adopt infrastructure capabilities from ecosystem, hide complexity with their best practices without losing any extensibility, the most important is the application won't be affected even if we change the capability providers.
|
||||
|
||||
|
||||
|
||||
The picture above is an example of `helm` definition, we can use [FluxCD](https://fluxcd.io/) or [ArgoCD](https://argo-cd.readthedocs.io/) as Helm capability provider. Once the platform builder registered the definition written by [CUE](https://cuelang.org/), the end user can discover the helm capability and define application by referring to the type.
|
||||
|
||||
There're mainly four types of definitions in KubeVela, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts. As an end user, you can get out-of-box definitions from KubeVela community.
|
||||
|
||||
## How to get out-of-box Definitions?
|
||||
|
||||
|
|
@ -15,7 +21,7 @@ There're two sources to get out-of-box definitions:
|
|||
- [Trait Definition](../end-user/traits/references)
|
||||
- [Policy Definition](../end-user/policies/references)
|
||||
- [Workflow Step Definition](../end-user/workflow/built-in-workflow-defs)
|
||||
* [Addons](../reference/addons/overview), as extensions of KubeVela, each addon contains a bunch of definitions along its CRD controllers.
|
||||
* Install [Addons](../reference/addons/overview), they're scenario-oriented system extensions of KubeVela, each addon contains a bunch of definitions along its CRD controllers.
|
||||
- The community has a [verified addon registry](https://github.com/kubevela/catalog) which contains a large catalog of addons, the registry is maintained by the KubeVela team.
|
||||
|
||||
## Lifecycle of a Definition
|
||||
|
|
@ -26,10 +32,17 @@ A definition's lifecycle usually has 3 stages:
|
|||
|
||||
When definitions installed in the system, they can be discovered by end user immediately.
|
||||
|
||||
* Check the list:
|
||||
* Check the definition list
|
||||
|
||||
```
|
||||
vela def list
|
||||
```
|
||||
|
||||
The expected output:
|
||||
|
||||
<details>
|
||||
|
||||
```
|
||||
$ vela def list
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
webservice ComponentDefinition vela-system Describes long-running, scalable, containerized services
|
||||
that have a stable network endpoint to receive external
|
||||
|
|
@ -40,10 +53,19 @@ health PolicyDefinition vela-system Apply periodica
|
|||
notification WorkflowStepDefinition vela-system Send message to webhook
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
* Show property details of one definition
|
||||
|
||||
```
|
||||
vela show webservice
|
||||
```
|
||||
|
||||
The expected output:
|
||||
|
||||
<details>
|
||||
|
||||
* Show the details:
|
||||
```
|
||||
$ vela show webservice
|
||||
# Properties
|
||||
+------------------+-------------------------------------------------------------------------------------------+-----------------------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
|
|
@ -57,24 +79,24 @@ $ vela show webservice
|
|||
+------------------+-------------------------------------------------------------------------------------------+-----------------------------------+----------+---------+
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
You can also view the details with a browser, the following command will launch a server and invoke your browser automatically:
|
||||
You can also view the details from documentation website, the following command will launch a server and invoke your browser automatically:
|
||||
|
||||
```
|
||||
vela show webservice --web
|
||||
```
|
||||
|
||||
* Discover in UI console ( addon `velaux` installed)
|
||||
* Discover in UI console ([`velaux`](../reference/addons/velaux))
|
||||
|
||||
|
||||
Once installed, these definitions can be discovered and generated with forms by the UI console automatically. More than that, you can even customize the layout by defining the [ui schema](../reference/ui-schema) like below.
|
||||
|
||||
|
||||
|
||||
These definitions can also be discovered by the UI console, the more important thing is they can be displayed very well with [ui schema](../reference/ui-schema) defined.
|
||||
|
||||
### Use
|
||||
|
||||
If you're a fan of our UI console, the usage of definition is very straight forward, just click along with the creation of the deployment process.
|
||||
|
||||
|
||||
Using definition on UI console is very straight forward, just click along with the application creation process.
|
||||
|
||||
1. Create Application and choose Component type which is actually choosing which component definition to use.
|
||||
2. Fill the properties of component is actually fill the parameter of component definition.
|
||||
|
|
@ -134,12 +156,14 @@ spec:
|
|||
policies: ["target-prod", "deploy-ha"]
|
||||
```
|
||||
|
||||
Use the definition in command works the same, you can compose the application yaml manually and use `vela` command line tool to deploy.
|
||||
Use the definition in `vela` command line works the same, you can compose the application yaml manually and deploy by `vela up` command.
|
||||
|
||||
```
|
||||
vela up -f https://kubevela.net/example/applications/first-app.yaml
|
||||
```
|
||||
|
||||
Application is also one kind of Kubernetes CRD, you can also use `kubectl apply` or invoke Kubernetes API to integrate with vela application.
|
||||
|
||||
### Customize
|
||||
|
||||
> **⚠️ In most cases, you don't need to customize any definitions unless you're going to extend the capability of KubeVela. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.**
|
||||
|
|
@ -175,6 +199,3 @@ template: {
|
|||
The `type` defines what kind of definition it is, the `parameter` defines the inputs, while the `output` section defines the outputs.
|
||||
You can refer to detail docs about [how to manage definition](../platform-engineers/cue/definition-edit) or learn the [definition protocol](../platform-engineers/oam/x-definition).
|
||||
|
||||
## Next Step
|
||||
|
||||
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.
|
||||
|
|
|
|||
|
|
@ -2,6 +2,10 @@
|
|||
title: VelaUX
|
||||
---
|
||||
|
||||
VelaUX provides the UI console of KubeVela.
|
||||
|
||||
|
||||
|
||||
## Install
|
||||
|
||||
```shell script
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 224 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 541 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 242 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 274 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 218 KiB |
|
|
@ -210,7 +210,7 @@
|
|||
"message": "天然支持企业级集成，安全、合规、可观测一应俱全"
|
||||
},
|
||||
"Choose from the wide range of LDAP integrations we provided out-of-box, enjoy enhanced multi-cluster authorization and authentication, pick and apply fine-grained RBAC modules and customize them per your own supply chain requirements. All delivery process has fully automated observability.": {
|
||||
"message": "天然支持多集群安全和 RBAC 集成，你还可以从社区的插件中心找到一系列开箱即用的平台扩展，包括多种用户体系（LDAP 等）集成、多租户权限控制、安全校验和扫描、应用可观测性等大量企业级能力。轻松根据需求和场景来设计和定制你的平台扩展能力，满足业务快速增长的需求，同时持续保证生产环境的稳定和安全。整个应用交付流程完全透明化、可观测。"
|
||||
"message": "天然支持多集群安全和 RBAC 集成，你还可以从社区的插件中心找到一系列开箱即用的平台扩展，包括多种用户体系（LDAP 等）集成、多租户权限控制、安全校验和扫描、应用可观测性等大量企业级能力。轻松根据需求和场景来设计和定制你的平台扩展能力，满足业务快速增长的需求，同时持续保证生产环境的稳定和安全。整个应用交付流程充分具备透明化、可观测能力，系统自身的各项指标和监控大盘完全自动化生成。"
|
||||
},
|
||||
"Multi-cloud/hybrid-environments app delivery as first-class citizen": {
|
||||
"message": "面向多云多集群混合环境，丰富的应用交付和管理能力"
|
||||
|
|
|
|||
|
|
@ -4,6 +4,12 @@ title: 模块定义
|
|||
|
||||
模块定义是组成 KubeVela 平台的基本扩展能力单元，一个模块定义就像乐高积木，它将底层的能力封装成抽象的模块，使得这些能力可以被最终用户快速理解、使用并和其他能力组装、衔接，最终构成一个具有丰富功能的业务应用。模块定义最大的优势是可以被**分发**和**共享**，在不同的业务应用中重复使用，在基于 KubeVela 的不同平台上均能执行。
|
||||
|
||||
通过模块定义，平台构建者可以很容易的将云原生生态的基础设施组件扩展为应用层能力，基于最佳实践为上层开发者屏蔽底层细节而不失可扩展性。最重要的是，模块定义为上层应用提供了良好的抽象体系，能力的实现层即使被完全替换也不会影响上层应用，真正做到基础设施无关。
|
||||
|
||||
|
||||
|
||||
为了更好的理解模块定义，上图给出了以 `helm` 为例的原理示意图。平台构建者可以基于 [FluxCD](https://fluxcd.io/) 或者 [ArgoCD](https://argo-cd.readthedocs.io/) 编写模块定义并注册为 `helm` 模块，最终用户可以自动发现这个模块并在应用中定义 `helm` 模块暴露的参数。模块定义的编写基于 [CUE](https://cuelang.org/) 语言，在本节的最后你也将了解到如何制作自定义模块。
|
||||
|
||||
目前 KubeVela 一共有四种不同类型的模块定义，分别是组件定义（ComponentDefinition）、运维特征定义（TraitDefinition）、策略定义（PolicyDefinition）以及工作流步骤定义（WorkflowStepDefinition），对应了构成[应用](./core-concept)的四个基本概念。
|
||||
|
||||
## 如何获取现成的模块定义？
|
||||
|
|
@ -27,8 +33,15 @@ title: 模块定义
|
|||
当模块定义被安装到 KubeVela 控制平面以后，最终用户就可以立即发现和查看它们。
|
||||
|
||||
* 查看模块定义列表
|
||||
|
||||
```
|
||||
vela def list
|
||||
```
|
||||
|
||||
期望输出：
|
||||
<details>
|
||||
|
||||
```
|
||||
$ vela def list
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
webservice ComponentDefinition vela-system Describes long-running, scalable, containerized services
|
||||
that have a stable network endpoint to receive external
|
||||
|
|
@ -39,10 +52,16 @@ health PolicyDefinition vela-system Apply periodica
|
|||
notification WorkflowStepDefinition vela-system Send message to webhook
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
* 查看模块定义的参数
|
||||
```
|
||||
$ vela show webservice
|
||||
vela show webservice
|
||||
```
|
||||
期望输出：
|
||||
<details>
|
||||
|
||||
```
|
||||
# Properties
|
||||
+------------------+-------------------------------------------------------------------------------------------+-----------------------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
|
|
@ -56,6 +75,7 @@ $ vela show webservice
|
|||
+------------------+-------------------------------------------------------------------------------------------+-----------------------------------+----------+---------+
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
你也可以通过命令行打开一个网页查看这些参数：
|
||||
|
||||
|
|
@ -63,18 +83,17 @@ $ vela show webservice
|
|||
vela show webservice --web
|
||||
```
|
||||
|
||||
* 在 KubeVela 的 UI 控制台（需安装 velaux 插件）也可以看到
|
||||
* 在 KubeVela 的 UI 控制台（ [velaux 插件](../reference/addons/velaux)）
|
||||
|
||||
|
||||
模块定义在 UI 控制台上可以比较方便的查看和使用，更重要的是，你还可以[自定义 UI 展示](../reference/ui-schema)来优化 UI 控制台上模块定义的参数展示。
|
||||
|
||||
|
||||
|
||||
模块定义在 UI 控制台上可以比较方便的查看，更重要的是会有一个比较好的用户体验，你还可以[自定义 UI 展示](../reference/ui-schema)来优化 UI 控制台上模块定义的参数展示。
|
||||
|
||||
### 使用
|
||||
|
||||
在 KubeVela 的 UI 控制台上使用模块定义是非常自然的，整个流程紧紧围绕应用部署计划展开，你只要跟着界面操作指引一步步点击即可使用。
|
||||
|
||||
|
||||
|
||||
分为如下几步：
|
||||
|
||||
1. 创建应用选择组件类型，这个过程就是选择使用某个组件定义。
|
||||
|
|
@ -176,7 +195,3 @@ template: {
|
|||
```
|
||||
|
||||
`type` 字段定义了这个模块是哪种类型（组件、运维特征、策略或者工作流步骤）， `parameter` 定义了模块的输入，`output` 定义了模块的输出。还有一些高级的操作你可以通过了解[如何管理、编写模块定义](../platform-engineers/cue/definition-edit)以及[模块定义与 Kubernetes 的交互协议](../platform-engineers/oam/x-definition) 等章节文档了解更多细节。
|
||||
|
||||
## 下一步
|
||||
|
||||
- 查看 KubeVela [项目架构](./architecture)文档了解全局的架构。
|
||||
|
|
|
|||
|
|
@ -23,11 +23,11 @@ KubeVela 是一个开箱即用的现代化应用交付与管理平台，它使
|
|||
|
||||
- **应用部署即代码（Deployment as Code），完整定义全交付流程**
|
||||
|
||||
KubeVela 创新性的通过 [开放应用模型（OAM）](https://oam.dev/)来作为应用交付的顶层抽象，这种方式使你可以用声明式的方式描述应用交付全流程，自动化的集成 CI/CD 及 GitOps 体系，通过 [CUE](https://cuelang.org/) 轻松扩展或重新编写你的交付过程。再也没有难以维护的脚本和复杂的衔接代码，复用社区丰富的功能模块，且无需关注任何基础设施细节，专注于定义和部署应用，一次编排、随处运行！
|
||||
KubeVela 创新性的通过 [开放应用模型（OAM）](https://oam.dev/)来作为应用交付的顶层抽象，这种方式使你可以用声明式的方式描述应用交付全流程，自动化的集成 CI/CD 及 GitOps 体系，通过 [CUE](https://cuelang.org/) 轻松扩展或重新编写你的交付过程。再也没有难以维护的脚本和复杂的衔接代码，从[插件市场](./reference/addons/overview)复用社区丰富的功能模块，且无需关注任何基础设施细节，专注于定义和部署应用，一次编排、随处运行！
|
||||
|
||||
- **天然支持企业级集成，安全、合规一应俱全**
|
||||
- **天然支持企业级集成，安全、合规、可观测性一应俱全**
|
||||
|
||||
KubeVela 天然支持多集群安全和 RBAC 集成，你还可以从社区的插件中心找到一系列开箱即用的平台扩展，包括多种用户体系（LDAP 等）集成、多租户权限控制、安全校验和扫描、应用可观测性等大量企业级能力。轻松根据需求和场景来设计和定制你的平台扩展能力，满足业务快速增长的需求，同时持续保证生产环境的稳定和安全。
|
||||
KubeVela 天然支持[多集群认证和授权](./platform-engineers/auth/advance)并与 Kubernetes RBAC 集成，你还可以从社区的插件中心找到一系列开箱即用的平台扩展，包括多种用户体系（LDAP 等）集成、多租户权限控制、安全校验和扫描、应用可观测性等大量企业级能力。轻松根据需求和场景来设计和定制你的平台扩展能力，满足业务快速增长的需求，同时持续保证生产环境的稳定和安全。整个应用交付流程充分具备透明化、可观测能力，系统自身的各项指标和监控大盘完全[自动化生成](./platform-engineers/operations/observability)。
|
||||
|
||||
- **面向多云多集群混合环境，丰富的应用交付和管理能力**
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,10 @@
|
|||
title: VelaUX 控制台
|
||||
---
|
||||
|
||||
VelaUX 插件为 KubeVela 提供了可视化的 UI 控制台操作能力。
|
||||
|
||||
|
||||
|
||||
## 安装插件
|
||||
|
||||
```shell script
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 224 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 541 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 242 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 274 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 218 KiB |
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: 云资源列表
|
||||
---
|
||||
|
||||
|
||||
| 编排类型 | 云服务商 | 云资源 | 描述 | 已验证 |
|
||||
|--------------------|-----------------------|-----------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|
|
||||
|Terraform|AWS| [acm](./terraform/aws-acm.md) | Terraform module which creates and validates ACM certificate | false |
|
||||
|
|
@ -134,6 +134,7 @@ title: 云资源列表
|
|||
| | | [subnet](./terraform/gcp-subnet.md) | Terraform module for creating Subnets on Google Cloud | false |
|
||||
| | | [tested oses](./terraform/gcp-tested-oses.md) | GCP Tested-Oses | false |
|
||||
| | | [vpc](./terraform/gcp-vpc.md) | Terraform module for creating VPCs on Google Cloud | false |
|
||||
| |Elastic Cloud| [ec deployment](./terraform/elastic-ec-deployment.md) | Provides an Elastic Cloud deployment resource, which allows deployments to be created, updated, and deleted. | true |
|
||||
| |百度云| [vpc](./terraform/baidu-vpc.md) | Baidu Cloud VPC | false |
|
||||
| |腾讯云| [subnet](./terraform/tencent-subnet.md) | Tencent Cloud Subnet | false |
|
||||
| | | [vpc](./terraform/tencent-vpc.md) | Terraform configuration for Tencent Cloud VPC | false |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,57 @@
|
|||
---
|
||||
title: Elastic Cloud Deployment
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
提供一个 Elastic Cloud deployment 资源，允许创建、更新和删除 deployment。
|
||||
|
||||
## Examples
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ec-deploy
|
||||
spec:
|
||||
components:
|
||||
- name: ec-deploy-comp
|
||||
type: elastic-ec-deployment
|
||||
properties:
|
||||
name: test-app
|
||||
region: aws-ap-east-1
|
||||
deployment_template_id: aws-compute-optimized-v3
|
||||
version: 8.3.3
|
||||
```
|
||||
|
||||
## 参数说明
|
||||
|
||||
### 属性
|
||||
|
||||
名称 | 描述 | 类型 | 是否必须 | 默认值
|
||||
---- | ----------- | ---- | -------- | -------
|
||||
deployment_template_id | Deployment template identifier to create the deployment from, full list: https://www.elastic.co/guide/en/cloud/current/ec-regions-templates-instances.html. | string | false |
|
||||
name | Name of the deployment. | string | false |
|
||||
region | Elasticsearch Service region, full list: https://www.elastic.co/guide/en/cloud/current/ec-regions-templates-instances.html. | string | false |
|
||||
writeConnectionSecretToRef | The secret which the cloud resource connection will be written to. | [writeConnectionSecretToRef](#writeConnectionSecretToRef) | false |
|
||||
|
||||
|
||||
#### writeConnectionSecretToRef
|
||||
|
||||
名称 | 描述 | 类型 | 是否必须 | 默认值
|
||||
---- | ----------- | ---- | -------- | -------
|
||||
name | The secret name which the cloud resource connection will be written to. | string | true |
|
||||
namespace | The secret namespace which the cloud resource connection will be written to. | string | false |
|
||||
|
||||
|
||||
### 输出
|
||||
|
||||
如果设置了 `writeConnectionSecretToRef`，一个 Kubernetes Secret 将会被创建，并且，它的数据里有这些键（key）：
|
||||
|
||||
名称 | 描述
|
||||
------------ | -------------
|
||||
ES_CLOUD_ID |
|
||||
ES_HTTPS_ENDPOINT |
|
||||
ES_PASSWORD |
|
||||
ES_USERNAME |
|
||||
ES_VERSION |
|
||||
|
|
@ -4,6 +4,12 @@ title: 模块定义
|
|||
|
||||
模块定义是组成 KubeVela 平台的基本扩展能力单元，一个模块定义就像乐高积木，它将底层的能力封装成抽象的模块，使得这些能力可以被最终用户快速理解、使用并和其他能力组装、衔接，最终构成一个具有丰富功能的业务应用。模块定义最大的优势是可以被**分发**和**共享**，在不同的业务应用中重复使用，在基于 KubeVela 的不同平台上均能执行。
|
||||
|
||||
通过模块定义，平台构建者可以很容易的将云原生生态的基础设施组件扩展为应用层能力，基于最佳实践为上层开发者屏蔽底层细节而不失可扩展性。最重要的是，模块定义为上层应用提供了良好的抽象体系，能力的实现层即使被完全替换也不会影响上层应用，真正做到基础设施无关。
|
||||
|
||||
|
||||
|
||||
为了更好的理解模块定义，上图给出了以 `helm` 为例的原理示意图。平台构建者可以基于 [FluxCD](https://fluxcd.io/) 或者 [ArgoCD](https://argo-cd.readthedocs.io/) 编写模块定义并注册为 `helm` 模块，最终用户可以自动发现这个模块并在应用中定义 `helm` 模块暴露的参数。模块定义的编写基于 [CUE](https://cuelang.org/) 语言，在本节的最后你也将了解到如何制作自定义模块。
|
||||
|
||||
目前 KubeVela 一共有四种不同类型的模块定义，分别是组件定义（ComponentDefinition）、运维特征定义（TraitDefinition）、策略定义（PolicyDefinition）以及工作流步骤定义（WorkflowStepDefinition），对应了构成[应用](./core-concept)的四个基本概念。
|
||||
|
||||
## 如何获取现成的模块定义？
|
||||
|
|
@ -27,8 +33,15 @@ title: 模块定义
|
|||
当模块定义被安装到 KubeVela 控制平面以后，最终用户就可以立即发现和查看它们。
|
||||
|
||||
* 查看模块定义列表
|
||||
|
||||
```
|
||||
vela def list
|
||||
```
|
||||
|
||||
期望输出：
|
||||
<details>
|
||||
|
||||
```
|
||||
$ vela def list
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
webservice ComponentDefinition vela-system Describes long-running, scalable, containerized services
|
||||
that have a stable network endpoint to receive external
|
||||
|
|
@ -39,10 +52,16 @@ health PolicyDefinition vela-system Apply periodica
|
|||
notification WorkflowStepDefinition vela-system Send message to webhook
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
* 查看模块定义的参数
|
||||
```
|
||||
$ vela show webservice
|
||||
vela show webservice
|
||||
```
|
||||
期望输出：
|
||||
<details>
|
||||
|
||||
```
|
||||
# Properties
|
||||
+------------------+-------------------------------------------------------------------------------------------+-----------------------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
|
|
@ -56,6 +75,7 @@ $ vela show webservice
|
|||
+------------------+-------------------------------------------------------------------------------------------+-----------------------------------+----------+---------+
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
你也可以通过命令行打开一个网页查看这些参数：
|
||||
|
||||
|
|
@ -63,18 +83,17 @@ $ vela show webservice
|
|||
vela show webservice --web
|
||||
```
|
||||
|
||||
* 在 KubeVela 的 UI 控制台（需安装 velaux 插件）也可以看到
|
||||
* 在 KubeVela 的 UI 控制台（ [velaux 插件](../reference/addons/velaux)）
|
||||
|
||||
|
||||
模块定义在 UI 控制台上可以比较方便的查看和使用，更重要的是，你还可以[自定义 UI 展示](../reference/ui-schema)来优化 UI 控制台上模块定义的参数展示。
|
||||
|
||||
|
||||
|
||||
模块定义在 UI 控制台上可以比较方便的查看，更重要的是会有一个比较好的用户体验，你还可以[自定义 UI 展示](../reference/ui-schema)来优化 UI 控制台上模块定义的参数展示。
|
||||
|
||||
### 使用
|
||||
|
||||
在 KubeVela 的 UI 控制台上使用模块定义是非常自然的，整个流程紧紧围绕应用部署计划展开，你只要跟着界面操作指引一步步点击即可使用。
|
||||
|
||||
|
||||
|
||||
分为如下几步：
|
||||
|
||||
1. 创建应用选择组件类型，这个过程就是选择使用某个组件定义。
|
||||
|
|
@ -176,7 +195,3 @@ template: {
|
|||
```
|
||||
|
||||
`type` 字段定义了这个模块是哪种类型（组件、运维特征、策略或者工作流步骤）， `parameter` 定义了模块的输入，`output` 定义了模块的输出。还有一些高级的操作你可以通过了解[如何管理、编写模块定义](../platform-engineers/cue/definition-edit)以及[模块定义与 Kubernetes 的交互协议](../platform-engineers/oam/x-definition) 等章节文档了解更多细节。
|
||||
|
||||
## 下一步
|
||||
|
||||
- 查看 KubeVela [项目架构](./architecture)文档了解全局的架构。
|
||||
|
|
|
|||
|
|
@ -23,11 +23,11 @@ KubeVela 是一个开箱即用的现代化应用交付与管理平台，它使
|
|||
|
||||
- **应用部署即代码（Deployment as Code），完整定义全交付流程**
|
||||
|
||||
KubeVela 创新性的通过 [开放应用模型（OAM）](https://oam.dev/)来作为应用交付的顶层抽象，这种方式使你可以用声明式的方式描述应用交付全流程，自动化的集成 CI/CD 及 GitOps 体系，通过 [CUE](https://cuelang.org/) 轻松扩展或重新编写你的交付过程。再也没有难以维护的脚本和复杂的衔接代码，复用社区丰富的功能模块，且无需关注任何基础设施细节，专注于定义和部署应用，一次编排、随处运行！
|
||||
KubeVela 创新性的通过 [开放应用模型（OAM）](https://oam.dev/)来作为应用交付的顶层抽象，这种方式使你可以用声明式的方式描述应用交付全流程，自动化的集成 CI/CD 及 GitOps 体系，通过 [CUE](https://cuelang.org/) 轻松扩展或重新编写你的交付过程。再也没有难以维护的脚本和复杂的衔接代码，从[插件市场](./reference/addons/overview)复用社区丰富的功能模块，且无需关注任何基础设施细节，专注于定义和部署应用，一次编排、随处运行！
|
||||
|
||||
- **天然支持企业级集成，安全、合规一应俱全**
|
||||
- **天然支持企业级集成，安全、合规、可观测性一应俱全**
|
||||
|
||||
KubeVela 天然支持多集群安全和 RBAC 集成，你还可以从社区的插件中心找到一系列开箱即用的平台扩展，包括多种用户体系（LDAP 等）集成、多租户权限控制、安全校验和扫描、应用可观测性等大量企业级能力。轻松根据需求和场景来设计和定制你的平台扩展能力，满足业务快速增长的需求，同时持续保证生产环境的稳定和安全。
|
||||
KubeVela 天然支持[多集群认证和授权](./platform-engineers/auth/advance)并与 Kubernetes RBAC 集成，你还可以从社区的插件中心找到一系列开箱即用的平台扩展，包括多种用户体系（LDAP 等）集成、多租户权限控制、安全校验和扫描、应用可观测性等大量企业级能力。轻松根据需求和场景来设计和定制你的平台扩展能力，满足业务快速增长的需求，同时持续保证生产环境的稳定和安全。整个应用交付流程充分具备透明化、可观测能力，系统自身的各项指标和监控大盘完全[自动化生成](./platform-engineers/operations/observability)。
|
||||
|
||||
- **面向多云多集群混合环境，丰富的应用交付和管理能力**
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,10 @@
|
|||
title: VelaUX 控制台
|
||||
---
|
||||
|
||||
VelaUX 插件为 KubeVela 提供了可视化的 UI 控制台操作能力。
|
||||
|
||||
|
||||
|
||||
## 安装插件
|
||||
|
||||
```shell script
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 224 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 541 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 242 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 274 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 218 KiB |
|
|
@ -178,5 +178,6 @@ title: Supported Cloud Resource list
|
|||
| | | [subnet](./terraform/gcp-subnet.md) | Terraform module for creating Subnets on Google Cloud | false |
|
||||
| | | [tested oses](./terraform/gcp-tested-oses.md) | GCP Tested-Oses | false |
|
||||
| | | [vpc](./terraform/gcp-vpc.md) | Terraform module for creating VPCs on Google Cloud | false |
|
||||
| |Elastic Cloud| [ec deployment](./terraform/elastic-ec-deployment.md) | Provides an Elastic Cloud deployment resource, which allows deployments to be created, updated, and deleted. | ture |
|
||||
| |Tencent Cloud| [subnet](./terraform/tencent-subnet.md) | Tencent Cloud Subnet | false |
|
||||
| | | [vpc](./terraform/tencent-vpc.md) | Terraform configuration for Tencent Cloud VPC | false |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,57 @@
|
|||
---
|
||||
title: Elastic Cloud EC Deployment
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Provides an Elastic Cloud deployment resource, which allows deployments to be created, updated, and deleted.
|
||||
|
||||
## Examples
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ec-deploy
|
||||
spec:
|
||||
components:
|
||||
- name: ec-deploy-comp
|
||||
type: elastic-ec-deployment
|
||||
properties:
|
||||
name: test-app
|
||||
region: aws-ap-east-1
|
||||
deployment_template_id: aws-compute-optimized-v3
|
||||
version: 8.3.3
|
||||
```
|
||||
|
||||
## Specification
|
||||
|
||||
### Properties
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
---- | ----------- | ---- | -------- | -------
|
||||
deployment_template_id | Deployment template identifier to create the deployment from, full list: https://www.elastic.co/guide/en/cloud/current/ec-regions-templates-instances.html. | string | false |
|
||||
name | Name of the deployment. | string | false |
|
||||
region | Elasticsearch Service region, full list: https://www.elastic.co/guide/en/cloud/current/ec-regions-templates-instances.html. | string | false |
|
||||
writeConnectionSecretToRef | The secret which the cloud resource connection will be written to. | [writeConnectionSecretToRef](#writeConnectionSecretToRef) | false |
|
||||
|
||||
|
||||
#### writeConnectionSecretToRef
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
---- | ----------- | ---- | -------- | -------
|
||||
name | The secret name which the cloud resource connection will be written to. | string | true |
|
||||
namespace | The secret namespace which the cloud resource connection will be written to. | string | false |
|
||||
|
||||
|
||||
### Outputs
|
||||
|
||||
If `writeConnectionSecretToRef` is set, a secret will be generated with these keys as below:
|
||||
|
||||
Name | Description
|
||||
------------ | -------------
|
||||
ES_CLOUD_ID |
|
||||
ES_HTTPS_ENDPOINT |
|
||||
ES_PASSWORD |
|
||||
ES_USERNAME |
|
||||
ES_VERSION |
|
||||
|
|
@ -2,9 +2,15 @@
|
|||
title: Definition
|
||||
---
|
||||
|
||||
Definition are the basic building block of the KubeVela platform. A definition encapsulates an arbitrarily complex automation as a lego style module that can be used to compose an Application, then safely shared, and repeatably executed by any KubeVela engine.
|
||||
OAM Definitions are basic building blocks of the KubeVela platform. A definition encapsulates an arbitrarily complex automation as a lego style module, then safely shared, discovered and be used to compose an Application delivered by any KubeVela engine.
|
||||
|
||||
There're four types of Definition, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts.
|
||||
With the help of OAM definitions, the platform builder can easily adopt infrastructure capabilities from ecosystem, hide complexity with their best practices without losing any extensibility, the most important is the application won't be affected even if we change the capability providers.
|
||||
|
||||
|
||||
|
||||
The picture above is an example of `helm` definition, we can use [FluxCD](https://fluxcd.io/) or [ArgoCD](https://argo-cd.readthedocs.io/) as Helm capability provider. Once the platform builder registered the definition written by [CUE](https://cuelang.org/), the end user can discover the helm capability and define application by referring to the type.
|
||||
|
||||
There're mainly four types of definitions in KubeVela, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts. As an end user, you can get out-of-box definitions from KubeVela community.
|
||||
|
||||
## How to get out-of-box Definitions?
|
||||
|
||||
|
|
@ -15,7 +21,7 @@ There're two sources to get out-of-box definitions:
|
|||
- [Trait Definition](../end-user/traits/references)
|
||||
- [Policy Definition](../end-user/policies/references)
|
||||
- [Workflow Step Definition](../end-user/workflow/built-in-workflow-defs)
|
||||
* [Addons](../reference/addons/overview), as extensions of KubeVela, each addon contains a bunch of definitions along its CRD controllers.
|
||||
* Install [Addons](../reference/addons/overview), they're scenario-oriented system extensions of KubeVela, each addon contains a bunch of definitions along its CRD controllers.
|
||||
- The community has a [verified addon registry](https://github.com/kubevela/catalog) which contains a large catalog of addons, the registry is maintained by the KubeVela team.
|
||||
|
||||
## Lifecycle of a Definition
|
||||
|
|
@ -26,10 +32,17 @@ A definition's lifecycle usually has 3 stages:
|
|||
|
||||
When definitions installed in the system, they can be discovered by end user immediately.
|
||||
|
||||
* Check the list:
|
||||
* Check the definition list
|
||||
|
||||
```
|
||||
vela def list
|
||||
```
|
||||
|
||||
The expected output:
|
||||
|
||||
<details>
|
||||
|
||||
```
|
||||
$ vela def list
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
webservice ComponentDefinition vela-system Describes long-running, scalable, containerized services
|
||||
that have a stable network endpoint to receive external
|
||||
|
|
@ -40,10 +53,19 @@ health PolicyDefinition vela-system Apply periodica
|
|||
notification WorkflowStepDefinition vela-system Send message to webhook
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
* Show property details of one definition
|
||||
|
||||
```
|
||||
vela show webservice
|
||||
```
|
||||
|
||||
The expected output:
|
||||
|
||||
<details>
|
||||
|
||||
* Show the details:
|
||||
```
|
||||
$ vela show webservice
|
||||
# Properties
|
||||
+------------------+-------------------------------------------------------------------------------------------+-----------------------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
|
|
@ -57,24 +79,24 @@ $ vela show webservice
|
|||
+------------------+-------------------------------------------------------------------------------------------+-----------------------------------+----------+---------+
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
You can also view the details with a browser, the following command will launch a server and invoke your browser automatically:
|
||||
You can also view the details from documentation website, the following command will launch a server and invoke your browser automatically:
|
||||
|
||||
```
|
||||
vela show webservice --web
|
||||
```
|
||||
|
||||
* Discover in UI console ( addon `velaux` installed)
|
||||
* Discover in UI console ([`velaux`](../reference/addons/velaux))
|
||||
|
||||
|
||||
Once installed, these definitions can be discovered and generated with forms by the UI console automatically. More than that, you can even customize the layout by defining the [ui schema](../reference/ui-schema) like below.
|
||||
|
||||
|
||||
|
||||
These definitions can also be discovered by the UI console, the more important thing is they can be displayed very well with [ui schema](../reference/ui-schema) defined.
|
||||
|
||||
### Use
|
||||
|
||||
If you're a fan of our UI console, the usage of definition is very straight forward, just click along with the creation of the deployment process.
|
||||
|
||||
|
||||
Using definition on UI console is very straight forward, just click along with the application creation process.
|
||||
|
||||
1. Create Application and choose Component type which is actually choosing which component definition to use.
|
||||
2. Fill the properties of component is actually fill the parameter of component definition.
|
||||
|
|
@ -134,12 +156,14 @@ spec:
|
|||
policies: ["target-prod", "deploy-ha"]
|
||||
```
|
||||
|
||||
Use the definition in command works the same, you can compose the application yaml manually and use `vela` command line tool to deploy.
|
||||
Use the definition in `vela` command line works the same, you can compose the application yaml manually and deploy by `vela up` command.
|
||||
|
||||
```
|
||||
vela up -f https://kubevela.net/example/applications/first-app.yaml
|
||||
```
|
||||
|
||||
Application is also one kind of Kubernetes CRD, you can also use `kubectl apply` or invoke Kubernetes API to integrate with vela application.
|
||||
|
||||
### Customize
|
||||
|
||||
> **⚠️ In most cases, you don't need to customize any definitions unless you're going to extend the capability of KubeVela. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.**
|
||||
|
|
@ -175,6 +199,3 @@ template: {
|
|||
The `type` defines what kind of definition it is, the `parameter` defines the inputs, while the `output` section defines the outputs.
|
||||
You can refer to detail docs about [how to manage definition](../platform-engineers/cue/definition-edit) or learn the [definition protocol](../platform-engineers/oam/x-definition).
|
||||
|
||||
## Next Step
|
||||
|
||||
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.
|
||||
|
|
|
|||
|
|
@ -2,6 +2,10 @@
|
|||
title: VelaUX
|
||||
---
|
||||
|
||||
VelaUX provides the UI console of KubeVela.
|
||||
|
||||
|
||||
|
||||
## Install
|
||||
|
||||
```shell script
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 224 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 541 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 242 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 274 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 218 KiB |
Loading…
Reference in New Issue