add and fix more docs
This commit is contained in:
天元
parent
a389d7ee76
commit
fde02dc4a4
|
|
@ -2,4 +2,63 @@
|
|||
title: Deploy First Application
|
||||
---
|
||||
|
||||
TBD
|
||||
Welcome to KubeVela! In this guide, we'll walk you through how to install KubeVela, and deploy your first simple application.
|
||||
|
||||
## Step 1: Install
|
||||
|
||||
Make sure you have finished and verified the installation following [this guide](quick-install).
|
||||
|
||||
## Step 2: Deploy Your First Application
|
||||
|
||||
```bash
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
|
||||
application.core.oam.dev/first-vela-app created
|
||||
```
|
||||
|
||||
Above command will apply an application to KubeVela and let it distribute the application to proper runtime infrastructure.
|
||||
|
||||
Check the status until we see `status` is `running` and services are `healthy`:
|
||||
|
||||
```bash
|
||||
$ kubectl get application first-vela-app -o yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
...
|
||||
status:
|
||||
...
|
||||
services:
|
||||
- healthy: true
|
||||
name: express-server
|
||||
traits:
|
||||
- healthy: true
|
||||
message: 'Visiting URL: testsvc.example.com, IP: your ip address'
|
||||
type: ingress
|
||||
status: running
|
||||
```
|
||||
|
||||
You can now directly visit the application (regardless of where it is running).
|
||||
|
||||
```
|
||||
$ curl -H "Host:testsvc.example.com" http://<your ip address>/
|
||||
<xmp>
|
||||
Hello World
|
||||
|
||||
|
||||
## .
|
||||
## ## ## ==
|
||||
## ## ## ## ## ===
|
||||
/""""""""""""""""\___/ ===
|
||||
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
|
||||
\______ o _,/
|
||||
\ \ _,'
|
||||
`'--.._\..--''
|
||||
</xmp>
|
||||
```
|
||||
**Voila!** You are all set to go.
|
||||
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn KubeVela's [Core Concepts](../core-concepts/application).
|
||||
- Learn KubeVela's [Architecture](../core-concepts/architecture).
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ slug: /
|
|||
|
||||
---
|
||||
|
||||
|
||||
## Motivation
|
||||
|
||||
The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does not introduce abstractions to model software deployment on top of today's hybrid and distributed environments. We’ve seen the lack of application level context have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production.
|
||||
|
|
|
|||
|
|
@ -4,245 +4,3 @@ title: CUE Advanced
|
|||
|
||||
TBD
|
||||
|
||||
## Using CLI to manage definitions
|
||||
|
||||
In Vela CLI (>v1.1), `vela def` command group provides a series of convenient definition writing tools. With these commands, users only need to write CUE files to generate and edit definitions, instead of composing Kubernetes YAML object with mixed CUE string.
|
||||
|
||||
### init
|
||||
|
||||
`vela def init` is a command that helps users bootstrap new definitions. To create an empty trait definition, run `vela def init my-trait -t trait --desc "My trait description."`
|
||||
|
||||
```json
|
||||
"my-trait": {
|
||||
annotations: {}
|
||||
attributes: {
|
||||
appliesToWorkloads: []
|
||||
conflictsWith: []
|
||||
definitionRef: ""
|
||||
podDisruptive: false
|
||||
workloadRefPath: ""
|
||||
}
|
||||
description: "My trait description."
|
||||
labels: {}
|
||||
type: "trait"
|
||||
}
|
||||
template: patch: {}
|
||||
```
|
||||
|
||||
Or you can use `vela def init my-comp --interactive` to initiate definitions interactively.
|
||||
|
||||
```bash
|
||||
$ vela def init my-comp --interactive
|
||||
Please choose one definition type from the following values: component, trait, policy, workload, scope, workflow-step
|
||||
> Definition type: component
|
||||
> Definition description: My component definition.
|
||||
Please enter the location the template YAML file to build definition. Leave it empty to generate default template.
|
||||
> Definition template filename:
|
||||
Please enter the output location of the generated definition. Leave it empty to print definition to stdout.
|
||||
> Definition output filename: my-component.cue
|
||||
Definition written to my-component.cue
|
||||
```
|
||||
|
||||
In addition, users can create definitions from existing YAML files. For example, if a user want to create a ComponentDefinition which is designed to generate a deployment, and this deployment has already been created elsewhere, he/she can use the `--template-yaml` flag to complete the transformation. The YAML file is as below
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: hello-world
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: hello-world
|
||||
spec:
|
||||
containers:
|
||||
- name: hello-world
|
||||
image: somefive/hello-world
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 80
|
||||
protocol: TCP
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: hello-world-service
|
||||
spec:
|
||||
selector:
|
||||
app: hello-world
|
||||
ports:
|
||||
- name: http
|
||||
protocol: TCP
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
type: LoadBalancer
|
||||
```
|
||||
|
||||
Running `vela def init my-comp -t component --desc "My component." --template-yaml ./my-deployment.yaml` to get the CUE-format ComponentDefinition
|
||||
|
||||
```json
|
||||
"my-comp": {
|
||||
annotations: {}
|
||||
attributes: workload: definition: {
|
||||
apiVersion: "<change me> apps/v1"
|
||||
kind: "<change me> Deployment"
|
||||
}
|
||||
description: "My component."
|
||||
labels: {}
|
||||
type: "component"
|
||||
}
|
||||
template: {
|
||||
output: {
|
||||
metadata: name: "hello-world"
|
||||
spec: {
|
||||
replicas: 1
|
||||
selector: matchLabels: "app.kubernetes.io/name": "hello-world"
|
||||
template: {
|
||||
metadata: labels: "app.kubernetes.io/name": "hello-world"
|
||||
spec: containers: [{
|
||||
name: "hello-world"
|
||||
image: "somefive/hello-world"
|
||||
ports: [{
|
||||
name: "http"
|
||||
containerPort: 80
|
||||
protocol: "TCP"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
apiVersion: "apps/v1"
|
||||
kind: "Deployment"
|
||||
}
|
||||
outputs: "hello-world-service": {
|
||||
metadata: name: "hello-world-service"
|
||||
spec: {
|
||||
ports: [{
|
||||
name: "http"
|
||||
protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
}]
|
||||
selector: app: "hello-world"
|
||||
type: "LoadBalancer"
|
||||
}
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
}
|
||||
parameter: {}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
Then the user can make further modifications based on the definition file above, like removing *\<change me\>* in **workload.definition**。
|
||||
|
||||
### vet
|
||||
|
||||
After initializing definition files, run `vela def vet my-comp.cue` to validate if there are any syntax error in the definition file. It can be used to detect some simple errors such as missing brackets.
|
||||
|
||||
```bash
|
||||
$ vela def vet my-comp.cue
|
||||
Validation succeed.
|
||||
```
|
||||
|
||||
### render / apply
|
||||
|
||||
After confirming the definition file has correct syntax. users can run `vela def apply my-comp.cue --namespace my-namespace` to apply this definition in the `my-namespace` namespace。If you want to check the transformed Kubernetes YAML file, `vela def apply my-comp.cue --dry-run` or `vela def render my-comp.cue -o my-comp.yaml` can achieve that.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: My component.
|
||||
labels: {}
|
||||
name: my-comp
|
||||
namespace: vela-system
|
||||
spec:
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
metadata: name: "hello-world"
|
||||
spec: {
|
||||
replicas: 1
|
||||
selector: matchLabels: "app.kubernetes.io/name": "hello-world"
|
||||
template: {
|
||||
metadata: labels: "app.kubernetes.io/name": "hello-world"
|
||||
spec: containers: [{
|
||||
name: "hello-world"
|
||||
image: "somefive/hello-world"
|
||||
ports: [{
|
||||
name: "http"
|
||||
containerPort: 80
|
||||
protocol: "TCP"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
apiVersion: "apps/v11"
|
||||
kind: "Deployment"
|
||||
}
|
||||
outputs: "hello-world-service": {
|
||||
metadata: name: "hello-world-service"
|
||||
spec: {
|
||||
ports: [{
|
||||
name: "http"
|
||||
protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
}]
|
||||
selector: app: "hello-world"
|
||||
type: "LoadBalancer"
|
||||
}
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
}
|
||||
parameter: {}
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
```
|
||||
|
||||
```bash
|
||||
$ vela def apply my-comp.cue -n my-namespace
|
||||
ComponentDefinition my-comp created in namespace my-namespace.
|
||||
```
|
||||
|
||||
### get / list / edit / del
|
||||
|
||||
While you can use native kubectl tools to confirm the results of the apply command, as mentioned above, the YAML object mixed with raw CUE template string is complex. Using `vela def get` will automatically convert the YAML object into the CUE-format definition.
|
||||
|
||||
```bash
|
||||
$ vela def get my-comp -t component
|
||||
```
|
||||
|
||||
Or you can list all defintions installed through `vela def list`
|
||||
|
||||
```bash
|
||||
$ vela def list -n my-namespace -t component
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
my-comp ComponentDefinition my-namespace My component.
|
||||
```
|
||||
|
||||
Similarly, using `vela def edit` to edit definitions in pure CUE-format. The transformation between CUE-format definition and YAML object is done by the command. Besides, you can specify the `EDITOR` environment variable to use your favourate editor.
|
||||
|
||||
```bash
|
||||
$ EDITOR=vim vela def edit my-comp
|
||||
```
|
||||
|
||||
Finally, `vela def del` can be utilized to delete existing definitions.
|
||||
|
||||
```bash
|
||||
$ vela def del my-comp -n my-namespace
|
||||
Are you sure to delete the following definition in namespace my-namespace?
|
||||
ComponentDefinition my-comp: My component.
|
||||
[yes|no] > yes
|
||||
ComponentDefinition my-comp in namespace my-namespace deleted.
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,244 @@
|
|||
---
|
||||
title: Manage X-Definition
|
||||
---
|
||||
|
||||
In KubeVela CLI (>= v1.1.0), `vela def` command group provides a series of convenient definition writing tools. With these commands, users only need to write CUE files to generate and edit definitions, instead of composing Kubernetes YAML object with mixed CUE string.
|
||||
|
||||
## init
|
||||
|
||||
`vela def init` is a command that helps users bootstrap new definitions. To create an empty trait definition, run `vela def init my-trait -t trait --desc "My trait description."`
|
||||
|
||||
```json
|
||||
"my-trait": {
|
||||
annotations: {}
|
||||
attributes: {
|
||||
appliesToWorkloads: []
|
||||
conflictsWith: []
|
||||
definitionRef: ""
|
||||
podDisruptive: false
|
||||
workloadRefPath: ""
|
||||
}
|
||||
description: "My trait description."
|
||||
labels: {}
|
||||
type: "trait"
|
||||
}
|
||||
template: patch: {}
|
||||
```
|
||||
|
||||
Or you can use `vela def init my-comp --interactive` to initiate definitions interactively.
|
||||
|
||||
```bash
|
||||
$ vela def init my-comp --interactive
|
||||
Please choose one definition type from the following values: component, trait, policy, workload, scope, workflow-step
|
||||
> Definition type: component
|
||||
> Definition description: My component definition.
|
||||
Please enter the location the template YAML file to build definition. Leave it empty to generate default template.
|
||||
> Definition template filename:
|
||||
Please enter the output location of the generated definition. Leave it empty to print definition to stdout.
|
||||
> Definition output filename: my-component.cue
|
||||
Definition written to my-component.cue
|
||||
```
|
||||
|
||||
In addition, users can create definitions from existing YAML files. For example, if a user want to create a ComponentDefinition which is designed to generate a deployment, and this deployment has already been created elsewhere, he/she can use the `--template-yaml` flag to complete the transformation. The YAML file is as below
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: hello-world
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: hello-world
|
||||
spec:
|
||||
containers:
|
||||
- name: hello-world
|
||||
image: somefive/hello-world
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 80
|
||||
protocol: TCP
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: hello-world-service
|
||||
spec:
|
||||
selector:
|
||||
app: hello-world
|
||||
ports:
|
||||
- name: http
|
||||
protocol: TCP
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
type: LoadBalancer
|
||||
```
|
||||
|
||||
Running `vela def init my-comp -t component --desc "My component." --template-yaml ./my-deployment.yaml` to get the CUE-format ComponentDefinition
|
||||
|
||||
```json
|
||||
"my-comp": {
|
||||
annotations: {}
|
||||
attributes: workload: definition: {
|
||||
apiVersion: "<change me> apps/v1"
|
||||
kind: "<change me> Deployment"
|
||||
}
|
||||
description: "My component."
|
||||
labels: {}
|
||||
type: "component"
|
||||
}
|
||||
template: {
|
||||
output: {
|
||||
metadata: name: "hello-world"
|
||||
spec: {
|
||||
replicas: 1
|
||||
selector: matchLabels: "app.kubernetes.io/name": "hello-world"
|
||||
template: {
|
||||
metadata: labels: "app.kubernetes.io/name": "hello-world"
|
||||
spec: containers: [{
|
||||
name: "hello-world"
|
||||
image: "somefive/hello-world"
|
||||
ports: [{
|
||||
name: "http"
|
||||
containerPort: 80
|
||||
protocol: "TCP"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
apiVersion: "apps/v1"
|
||||
kind: "Deployment"
|
||||
}
|
||||
outputs: "hello-world-service": {
|
||||
metadata: name: "hello-world-service"
|
||||
spec: {
|
||||
ports: [{
|
||||
name: "http"
|
||||
protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
}]
|
||||
selector: app: "hello-world"
|
||||
type: "LoadBalancer"
|
||||
}
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
}
|
||||
parameter: {}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
Then the user can make further modifications based on the definition file above, like removing *\<change me\>* in **workload.definition**。
|
||||
|
||||
## vet
|
||||
|
||||
After initializing definition files, run `vela def vet my-comp.cue` to validate if there are any syntax error in the definition file. It can be used to detect some simple errors such as missing brackets.
|
||||
|
||||
```bash
|
||||
$ vela def vet my-comp.cue
|
||||
Validation succeed.
|
||||
```
|
||||
|
||||
## render / apply
|
||||
|
||||
After confirming the definition file has correct syntax. users can run `vela def apply my-comp.cue --namespace my-namespace` to apply this definition in the `my-namespace` namespace。If you want to check the transformed Kubernetes YAML file, `vela def apply my-comp.cue --dry-run` or `vela def render my-comp.cue -o my-comp.yaml` can achieve that.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: My component.
|
||||
labels: {}
|
||||
name: my-comp
|
||||
namespace: vela-system
|
||||
spec:
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
metadata: name: "hello-world"
|
||||
spec: {
|
||||
replicas: 1
|
||||
selector: matchLabels: "app.kubernetes.io/name": "hello-world"
|
||||
template: {
|
||||
metadata: labels: "app.kubernetes.io/name": "hello-world"
|
||||
spec: containers: [{
|
||||
name: "hello-world"
|
||||
image: "somefive/hello-world"
|
||||
ports: [{
|
||||
name: "http"
|
||||
containerPort: 80
|
||||
protocol: "TCP"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
apiVersion: "apps/v11"
|
||||
kind: "Deployment"
|
||||
}
|
||||
outputs: "hello-world-service": {
|
||||
metadata: name: "hello-world-service"
|
||||
spec: {
|
||||
ports: [{
|
||||
name: "http"
|
||||
protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
}]
|
||||
selector: app: "hello-world"
|
||||
type: "LoadBalancer"
|
||||
}
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
}
|
||||
parameter: {}
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
```
|
||||
|
||||
```bash
|
||||
$ vela def apply my-comp.cue -n my-namespace
|
||||
ComponentDefinition my-comp created in namespace my-namespace.
|
||||
```
|
||||
|
||||
## get / list / edit / del
|
||||
|
||||
While you can use native kubectl tools to confirm the results of the apply command, as mentioned above, the YAML object mixed with raw CUE template string is complex. Using `vela def get` will automatically convert the YAML object into the CUE-format definition.
|
||||
|
||||
```bash
|
||||
$ vela def get my-comp -t component
|
||||
```
|
||||
|
||||
Or you can list all defintions installed through `vela def list`
|
||||
|
||||
```bash
|
||||
$ vela def list -n my-namespace -t component
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
my-comp ComponentDefinition my-namespace My component.
|
||||
```
|
||||
|
||||
Similarly, using `vela def edit` to edit definitions in pure CUE-format. The transformation between CUE-format definition and YAML object is done by the command. Besides, you can specify the `EDITOR` environment variable to use your favourate editor.
|
||||
|
||||
```bash
|
||||
$ EDITOR=vim vela def edit my-comp
|
||||
```
|
||||
|
||||
Finally, `vela def del` can be utilized to delete existing definitions.
|
||||
|
||||
```bash
|
||||
$ vela def del my-comp -n my-namespace
|
||||
Are you sure to delete the following definition in namespace my-namespace?
|
||||
ComponentDefinition my-comp: My component.
|
||||
[yes|no] > yes
|
||||
ComponentDefinition my-comp in namespace my-namespace deleted.
|
||||
```
|
||||
|
||||
|
|
@ -2,12 +2,13 @@
|
|||
title: 应用部署计划
|
||||
---
|
||||
|
||||
KubeVela 将 Application 应用程序作为建模的基础，使用 Components 组件和 Traits 运维特征，完成一整套的应用部署计划。在熟悉这些核心概念后，你可以根据需求，对应按照 [用户手册](../end-user/components/helm) 和 [管理员手册](../platform-engineers/oam/oam-model) 进行开发。
|
||||
KubeVela 背后的应用交付模型是 [OAM（Open Application Model）](../platform-engineers/oam/oam-model.md)，其核心是将应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的“部署计划”，进而实现在混合环境中进行标准化和高效率的应用交付。这个应用部署计划就是这一节所要介绍的 **Application** 对象，也是 OAM 模型的使用者唯一需要了解的 API。
|
||||
|
||||
### Application 应用程序
|
||||
## 应用程序部署计划（Application）
|
||||
|
||||
在技术建模中，YAML 文件是应用部署计划的承载。一个典型的 YAML 样例如下：
|
||||
```
|
||||
KubeVela 通过 YAML 文件的方式描述应用部署计划。一个典型的 YAML 样例如下：
|
||||
|
||||
```yaml
|
||||
# sample.yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
|
|
@ -36,24 +37,42 @@ spec:
|
|||
cmd:
|
||||
- sleep
|
||||
- '1000'
|
||||
workflow:
|
||||
steps:
|
||||
# 步骤名称
|
||||
- name: deploy-frontend
|
||||
# 指定步骤类型
|
||||
type: apply-component
|
||||
properties:
|
||||
# 指定组件名称
|
||||
component: frontend
|
||||
- name: manual-approval
|
||||
# 工作流内置 suspend 类型的任务，用于暂停工作流
|
||||
type: suspend
|
||||
- name: deploy-backend
|
||||
type: apply-component
|
||||
properties:
|
||||
component: backend
|
||||
```
|
||||
|
||||
这里的字段对应着：
|
||||
|
||||
- `apiVersion`：所使用的 OAM API 版本。
|
||||
- `kind`：种类。我们最经常用到的就是 Pod 了。
|
||||
- `metadata`：业务相关信息。比如这次要创建的是一个网站。
|
||||
- `Spec`：描述我们需要应用去交付什么，告诉 Kubernetes 做成什么样。这里我们放入 KubeVela 的 `components`。
|
||||
- `components`：KubeVela 的组件系统。
|
||||
- `traits`：KubeVela 的运维特征系统。
|
||||
- `components`：一次应用交付部署计划所涵盖的全部组件。
|
||||
- `traits`：应用交付部署计划中每个组件独立的运维策略。
|
||||
- `workflow`: 自定义应用交付的执行流程，可以不填，则默认依次全部创建。
|
||||
|
||||
下面这张示意图诠释了它们之间的关系：
|
||||
|
||||
|
||||
先有一个应用程序 Application。在此基础之上我们申明应用主体为可配置、可部署的组件 Components，并同时对应地去申明，期望每个组件要拥有的相关运维特征 Traits。
|
||||
先有一个总体的应用部署计划 Application。在此基础之上我们申明应用主体为可配置、可部署的组件（Components），并同时对应地去申明，期望每个组件要拥有的相关运维特征 （Traits），如果有需要，还可以申明自定义的执行流程 （Workflow）。
|
||||
|
||||
你使用 KubeVela 的时候，就像在玩“乐高“积木：先拿起一块大的“应用程序”，然后往上固定一块或几块“组件”，组件上又可以贴上任何颜色大小的“运维特征”。同时根据需求的变化，你随时可以重新组装，形成新的应用部署计划。
|
||||
|
||||
### Components 组件
|
||||
## 组件（Components）
|
||||
|
||||
KubeVela 内置了常用的组件类型，使用 [KubeVela CLI](../getting-started/quick-install.mdx##3) 命令查看：
|
||||
```
|
||||
|
|
@ -73,11 +92,11 @@ worker vela-system deployments.apps Describes long-run
|
|||
|
||||
```
|
||||
|
||||
作为用户的你，可以继续使用 [CUE 组件](../end-user/components/cue)、[Helm 组件](../end-user/components/helm)、[Kustomize 组件](../end-user/components/kustomize)和[云服务组件](../end-user/components/cloud-services)来实现你需要的任何组件类型。
|
||||
你可以继续使用 [Helm 组件](../end-user/components/helm)、[Kustomize 组件](../end-user/components/kustomize)、[CUE 组件](../end-user/components/cue) 等开箱即用的 KubeVela 内置组件来构建你的应用部署计划。
|
||||
|
||||
同时作为管理员的你，也可以使用 [自定义组件](../platform-engineers/components/custom-component)、[Terraform 组件](../platform-engineers/components/component-terraform) 来自定义你的用户所需要的任何组件类型。
|
||||
如果你是熟悉 Kubernetes 的平台管理员，你可以通过[自定义组件入门](../platform-engineers/components/custom-component)文档了解 KubeVela 是如何扩展任意类型的自定义组件的。特别的，[Terraform 组件](../platform-engineers/components/component-terraform) 就是 KubeVela 自定义组件能力的一个最佳实践，可以满足任意云资源的供应，只需少量云厂商特定配置（如鉴权、云资源模块等），即可成为一个开箱即用的云资源组件。
|
||||
|
||||
### Traits 运维特征
|
||||
## 运维特征（Traits）
|
||||
|
||||
KubeVela 也内置了常用的运维特征类型，使用 [KubeVela CLI](../getting-started/quick-install.mdx##3) 命令查看：
|
||||
```
|
||||
|
|
@ -94,73 +113,33 @@ scaler vela-system webservice,worker false Manually
|
|||
sidecar vela-system deployments.apps true Inject a sidecar container to the component.
|
||||
```
|
||||
|
||||
作为用户的你，可以继续阅读用户手册里的 [绑定运维特征](../end-user/traits/ingress) ，具体查看如何完成各种运维特征的开发。
|
||||
你可以继续阅读用户手册里的 [绑定运维特征](../end-user/traits/ingress) ，具体查看如何完成各种运维特征的开发。
|
||||
|
||||
同时作为管理员的你，也可以继续使用 [自定义运维特征](../platform-engineers/traits/customize-trait) 为你的用户，自定义任何需要的运维特征类型。
|
||||
如果你是熟悉 Kubernetes 的平台管理员，也可以了解 KubeVela 中[自定义运维特征](../platform-engineers/traits/customize-trait) 的能力，为你的用户扩展任意运维功能。
|
||||
|
||||
### Workflow 工作流
|
||||
## 工作流（Workflow）
|
||||
|
||||
在 KubeVela 里，工作流能够让用户去粘合各种运维任务到一个流程中去，实现自动化地快速交付云原生应用到任意混合环境中。
|
||||
从设计上讲，工作流是为了定制化控制逻辑：不仅仅是简单地 Apply 所有资源，更是为了能够提供一些面向过程的灵活性。
|
||||
比如说，使用工作流能够帮助我们实现暂停、人工验证、等待状态、数据流传递、多环境灰度、A/B 测试等复杂操作。
|
||||
KubeVela 的工作流机制允许用户自定义应用交付计划中的步骤，粘合额外的交付流程，指定任意的交付环境。简而言之，工作流提供了定制化的控制逻辑，在原有 Kubernetes 模式交付资源（Apply）的基础上，提供了面向过程的灵活性。比如说，使用工作流实现暂停、人工验证、状态等待、数据流传递、多环境灰度、A/B 测试等复杂操作。
|
||||
|
||||
工作流是基于模块化设计的。
|
||||
每一个工作流模块都由一个 Definition CRD 定义并且通过 K8s API 来提供给用户操作。
|
||||
工作流模块作为一个“超级粘合剂”可以将你任意的工具和流程都通过 CUE 语言来组合起来。
|
||||
这让你可以通过强大的声明式语言和云原生 API 来创建你自己的模块。
|
||||
工作流是 KubeVela 实践过程中基于 OAM 模型的进一步探索和最佳实践，充分遵守 OAM 的模块化理念和可复用特性。每一个工作流模块都是一个“超级粘合剂”，可以将你任意的工具和流程都组合起来。使得你在现代复杂云原生应用交付环境中，可以通过一份申明式的配置，完整的描述所有的交付流程，保证交付过程的稳定性和便利性。
|
||||
|
||||
下面是一个例子：
|
||||
> 需要说明的是，工作流机制是应用交付过程中的强大补充能力，但并非必填能力，用户在不编写 Workflow 过程的情况下，依旧可以完成组件和运维策略的自动化部署。
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
接下来我们对上面的例子做更详细的说明：
|
||||
在上面的例子中，我们已经可以看到一些工作流的步骤：
|
||||
|
||||
- 这里使用了 `apply-component` 和 `suspend` 类型的工作流步骤：
|
||||
- `apply-component` 类型可以使用户部署指定的组件及其运维特征。
|
||||
- 在第一步完成后，开始执行 `suspend` 类型的工作流步骤。该步骤会暂停工作流，我们可以查看集群中第一个组件的状态，当其成功运行后，再使用 `vela workflow resume first-vela-workflow` 命令来继续该工作流。
|
||||
- 在第一步完成后，开始执行 `suspend` 类型的工作流步骤。该步骤会暂停工作流，我们可以查看集群中第一个组件的状态，当其成功运行后，再使用 `vela workflow resume website` 命令来继续该工作流。
|
||||
- 当工作流继续运行后，第三个步骤开始部署组件及运维特征。此时我们查看集群，可以看到所以资源都已经被成功部署。
|
||||
|
||||
到这里我们已经介绍完 KubeVela 工作流的基本概念。作为下一步，你可以：
|
||||
关于工作流，你可以从[指定组件部署](../end-user/workflow/apply-component)这个工作流节点类型开始逐次了解更多 KubeVela 当前的内置工作流节点类型。
|
||||
|
||||
- [动手尝试工作流的实践案例](../end-user/workflow/apply-component).
|
||||
- [学习创建你自己的 Definition 模块](../platform-engineers/workflow/steps).
|
||||
- [了解工作流系统背后的设计和架构](https://github.com/oam-dev/kubevela/blob/master/design/vela-core/workflow_policy.md).
|
||||
如果你是熟悉 Kubernetes 的平台管理员，你可以[学习创建自定义工作流节点类型](../platform-engineers/workflow/steps)，或者通过[设计文档](https://github.com/oam-dev/kubevela/blob/master/design/vela-core/workflow_policy.md)了解工作流系统背后的设计和架构.
|
||||
|
||||
## 下一步
|
||||
|
||||
后续步骤:
|
||||
|
||||
- 加入 KubeVela 中文社区钉钉群，群号：23310022。
|
||||
- 阅读**用户手册**基于开箱即用功能构建你的应用交付计划。
|
||||
- 阅读**管理员手册**了解 KubeVela 的扩展方式和背后的原理。
|
||||
|
|
@ -2,7 +2,6 @@
|
|||
title: 系统架构
|
||||
---
|
||||
|
||||
|
||||
KubeVela 的系统在默认安装的模式下，是一个只包含“控制平面”的架构，通过插件机制与各种运行时系统进行紧密配合。其中 KubeVela 核心控制器工作在管控 Kubernetes 集群。
|
||||
如下图所示，自上而下看，用户只与 KubeVela 所在的控制面 Kubernetes 集群发生交互。
|
||||
|
||||
|
|
@ -98,3 +97,11 @@ KubeVela 的用户数据面数据流动采用 Pull 模式（订阅模式），Ku
|
|||
- 在首次管控数据下发后，后续持续的发布可以由运行时集群自动化的进行持续交付，没有管控集群的限制，可以支撑更大的规模
|
||||
* 更好的容灾能力
|
||||
- 管控面的故障不影响运行时集群的持续运行
|
||||
|
||||
## 下一步
|
||||
|
||||
后续步骤:
|
||||
|
||||
- 加入 KubeVela 中文社区钉钉群，群号：23310022。
|
||||
- 阅读**用户手册**基于开箱即用功能构建你的应用交付计划。
|
||||
- 阅读**管理员手册**了解 KubeVela 的扩展方式和背后的原理。
|
||||
|
|
|
|||
|
|
@ -97,6 +97,6 @@ Hello World
|
|||
|
||||
后续步骤:
|
||||
|
||||
- 加入 KubeVela 中文社区钉钉群，群号：23310022。
|
||||
- 查看 KubeVela 的[`核心概念`](../core-concepts/application.md)，进一步理解其是如何工作的。
|
||||
<!-- - 直接使用 [`用户手册`](../core-concepts/application.md) 或者 [`管理员手册`](../core-concepts/application.md) 开始实际开发。 -->
|
||||
- 查看 KubeVela 的[`应用部署计划及其概念`](../core-concepts/application)，进一步理解其是如何工作的。
|
||||
- 查看 KubeVela 的[`系统架构`](../core-concepts/architecture)，了解 KubeVela 的系统构成和运转模式。
|
||||
- 加入 KubeVela 中文社区钉钉群，群号：23310022。
|
||||
|
|
@ -21,6 +21,13 @@ KubeVela 是一个开箱即用的、现代化的应用交付与管理平台。Ku
|
|||
- **可编程式交付工作流** - KubeVela 的交付模型是利用 [CUE](https://cuelang.org/) 来实现的。CUE 是一种诞生自 Google Borg 系统的数据配置语言，它可以将应用交付的所有步骤、所需资源、关联的运维动作以可编程的方式粘合成一个 DAG（有向无环图）来作为最终的声明式交付计划。相比于其他系统的复杂性和不可扩展性，KubeVela 基于 CUE 的实现不仅使用简单、扩展性极强，也更符合现代 GitOps 应用交付的趋势与要求。
|
||||
- **运行时无关** - KubeVela 是一个完全与运行时基础设施无关的应用交付与管理控制平面。所以它可以按照你定义的工作流与策略，面向任何环境交付和管理任何应用组件，比如：容器、云函数、数据库，甚至 AWS EC2 实例等等。
|
||||
|
||||
## 什么情况下该学习、使用 KubeVela ？
|
||||
|
||||
- 云原生时代的应用研发人员、DevOps 开发者：KubeVela 基于 Kubernetes 提供了大量开箱即用的能力，提供了围绕应用开发者的平台体验，无需学习复杂概念即可满足大多数通用场景的需求。
|
||||
- 云原生应用平台的构建者、PaaS 服务提供商、基础设施平台管理员：KubeVela 基于 Kubernetes 提供了大量编排和扩展能力，能够 100% 满足任意的扩展需求，交付任意形态的应用制品。
|
||||
- 第三方软件供应商（ISV）、垂直领域应用开发者：KubeVela 可以帮助你构建标准化的软件交付物，交付到任意云厂商和 Kubernetes 数据中心。
|
||||
|
||||
|
||||
## 架构图
|
||||
|
||||
KubeVela 的整体架构如下图所示：
|
||||
|
|
@ -71,4 +78,4 @@ KubeVela 是一个基于云原生技术栈构建的现代应用交付系统。
|
|||
|
||||
## 下一步
|
||||
|
||||
现在，让我们开始安装使用 KubeVela！
|
||||
现在，让我们开始[安装使用 KubeVela](./getting-started/quick-install)！
|
||||
|
|
@ -226,4 +226,4 @@ worker vela-system deployments.apps Describes long-running, scalable, contai
|
|||
|
||||
## 下一步
|
||||
|
||||
安装完毕 KubeVela，动手来写交付第一个应用！
|
||||
安装完毕 KubeVela，开始动手编写[第一个应用部署计划](./first-application)。
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: 自定义组件
|
||||
title: 自定义组件入门
|
||||
---
|
||||
|
||||
> 在阅读本部分之前，请确保你已经学习了 KubeVela 中的[组件定义（ComponentDefinition）](../oam/x-definition.md##组件定义（ComponentDefinition）) 原理
|
||||
> 在阅读本部分之前，请确保你已经了解 KubeVela 中[组件定义（ComponentDefinition）](../oam/x-definition.md##组件定义（ComponentDefinition）) 的概念
|
||||
|
||||
> 学习掌握了 [CUE 的基本知识](../cue/basic)
|
||||
|
||||
|
|
@ -384,12 +384,12 @@ output: {
|
|||
|
||||
### CUE `context` 的配置项
|
||||
|
||||
| Context 变量名 | 说明 |
|
||||
| :--: | :---------: |
|
||||
| `context.appRevision` | 应用部署计划的版本 |
|
||||
| `context.appRevisionNum` | 应用部署计划的版本号(`int` 类型), 比如说如果 `context.appRevision` 是 `app-v1` 的话，`context.appRevisionNum` 会是 `1` |
|
||||
| `context.appName` | 应用部署计划的名称 |
|
||||
| `context.name` | 组件的名称 |
|
||||
| `context.namespace` | 应用部署计划的命名空间 |
|
||||
| `context.output` | 组件中渲染的工作负载 API 资源，这通常用在运维特征里 |
|
||||
| `context.outputs.<resourceName>` | 组件中渲染的运维特征 API 资源，这通常用在运维特征里 |
|
||||
| Context 变量名 | 说明 |
|
||||
| :------------------------------: | :--------------------------------------------------------------------------------------------------------------------: |
|
||||
| `context.appRevision` | 应用部署计划的版本 |
|
||||
| `context.appRevisionNum` | 应用部署计划的版本号(`int` 类型), 比如说如果 `context.appRevision` 是 `app-v1` 的话，`context.appRevisionNum` 会是 `1` |
|
||||
| `context.appName` | 应用部署计划的名称 |
|
||||
| `context.name` | 组件的名称 |
|
||||
| `context.namespace` | 应用部署计划的命名空间 |
|
||||
| `context.output` | 组件中渲染的工作负载 API 资源，这通常用在运维特征里 |
|
||||
| `context.outputs.<resourceName>` | 组件中渲染的运维特征 API 资源，这通常用在运维特征里 |
|
||||
|
|
@ -2,597 +2,5 @@
|
|||
title: 开发与调试
|
||||
---
|
||||
|
||||
本节将介绍如何使用 [CUE](https://cuelang.org/) 通过 `ComponentDefinition` 来声明 app 组件。
|
||||
TBD
|
||||
|
||||
> 在阅读本部分之前，请确保你已经学习了 KubeVela 中的 [Definition CRD](../definition-and-templates)。
|
||||
## 声明 `ComponentDefinition`
|
||||
|
||||
这是一个基于 CUE 的 `ComponentDefinition` 示例，它提供了无状态工作负载类型的抽象：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: stateless
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
parameter: {
|
||||
name: string
|
||||
image: string
|
||||
}
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "Deployment"
|
||||
spec: {
|
||||
selector: matchLabels: {
|
||||
"app.oam.dev/component": parameter.name
|
||||
}
|
||||
template: {
|
||||
metadata: labels: {
|
||||
"app.oam.dev/component": parameter.name
|
||||
}
|
||||
spec: {
|
||||
containers: [{
|
||||
name: parameter.name
|
||||
image: parameter.image
|
||||
}]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
详细来说：
|
||||
- 需要 `.spec.workload` 来指示该组件的工作负载类型。
|
||||
- `.spec.schematic.cue.template` 是一个 CUE 模板，具体来说：
|
||||
* `output` 字段定义了抽象模板。
|
||||
* `parameter` 字段定义了模板参数，即在 `Application` 抽象中公开的可配置属性（KubeVela 将基于parameter字段自动生成Json schema）。
|
||||
|
||||
让我们声明另一个名为 `task` 的组件，即 run-to-completion 负载的抽象。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: task
|
||||
annotations:
|
||||
definition.oam.dev/description: "Describes jobs that run code or a script to completion."
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
apiVersion: "batch/v1"
|
||||
kind: "Job"
|
||||
spec: {
|
||||
parallelism: parameter.count
|
||||
completions: parameter.count
|
||||
template: spec: {
|
||||
restartPolicy: parameter.restart
|
||||
containers: [{
|
||||
image: parameter.image
|
||||
if parameter["cmd"] != _|_ {
|
||||
command: parameter.cmd
|
||||
}
|
||||
}]
|
||||
}
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
count: *1 | int
|
||||
image: string
|
||||
restart: *"Never" | string
|
||||
cmd?: [...string]
|
||||
}
|
||||
```
|
||||
|
||||
将上面的 `ComponentDefinition` 对象保存到文件中，并通过 `$ kubectl apply -f stateless-def.yaml task-def.yaml` 将它们安装到你的 Kubernetes 集群。
|
||||
|
||||
## 声明一个 `Application`
|
||||
|
||||
`ComponentDefinition` 可以在 `Application` 抽象中实例化，如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: hello
|
||||
type: stateless
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
name: mysvc
|
||||
- name: countdown
|
||||
type: task
|
||||
properties:
|
||||
image: centos:7
|
||||
cmd:
|
||||
- "bin/bash"
|
||||
- "-c"
|
||||
- "for i in 9 8 7 6 5 4 3 2 1 ; do echo $i ; done"
|
||||
```
|
||||
|
||||
### 背后含义
|
||||
<details>
|
||||
|
||||
上述应用程序资源将根据 CUE 模板中的 `output` 和 `Application` 属性中的用户输入生成和管理目标集群中的以下 Kubernetes 资源。
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: backend
|
||||
... # skip tons of metadata info
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: mysvc
|
||||
image: crccheck/hello-world
|
||||
metadata:
|
||||
labels:
|
||||
app.oam.dev/component: mysvc
|
||||
selector:
|
||||
matchLabels:
|
||||
app.oam.dev/component: mysvc
|
||||
---
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: countdown
|
||||
... # skip tons of metadata info
|
||||
spec:
|
||||
parallelism: 1
|
||||
completions: 1
|
||||
template:
|
||||
metadata:
|
||||
name: countdown
|
||||
spec:
|
||||
containers:
|
||||
- name: countdown
|
||||
image: 'centos:7'
|
||||
command:
|
||||
- bin/bash
|
||||
- '-c'
|
||||
- for i in 9 8 7 6 5 4 3 2 1 ; do echo $i ; done
|
||||
restartPolicy: Never
|
||||
```
|
||||
</details>
|
||||
|
||||
## CUE `Context`
|
||||
|
||||
KubeVela 允许你通过 `context` 关键字引用应用程序的运行时信息。
|
||||
|
||||
最广泛使用的上下文是应用程序名称(`context.appName`) 组件名称(`context.name`)。
|
||||
|
||||
```cue
|
||||
context: {
|
||||
appName: string
|
||||
name: string
|
||||
}
|
||||
```
|
||||
|
||||
例如，假设你要使用用户填写的组件名称作为工作负载实例中的容器名称：
|
||||
|
||||
```cue
|
||||
parameter: {
|
||||
image: string
|
||||
}
|
||||
output: {
|
||||
...
|
||||
spec: {
|
||||
containers: [{
|
||||
name: context.name
|
||||
image: parameter.image
|
||||
}]
|
||||
}
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
> 请注意，在将资源应用于目标集群之前，会自动注入 `context` 信息。
|
||||
### CUE `context` 包含的所有信息
|
||||
|
||||
| Context Variable | Description |
|
||||
| :------------------------------: | :-----------------------------------------------------------------------------: |
|
||||
| `context.appRevision` | The revision of the application |
|
||||
| `context.appName` | The name of the application |
|
||||
| `context.name` | The name of the component of the application |
|
||||
| `context.namespace` | The namespace of the application |
|
||||
| `context.output` | The rendered workload API resource of the component, this usually used in trait |
|
||||
| `context.outputs.<resourceName>` | The rendered trait API resource of the component, this usually used in trait |
|
||||
|
||||
|
||||
## 构造
|
||||
|
||||
一个组件定义通常由多个 API 资源组成，例如，一个由 Deployment 和 Service 组成的 `webserver` 组件。 CUE 是一个很好的解决方案，可以在简化的原语中实现这一点。
|
||||
|
||||
> 当然，另一种在 KubeVela 中进行组合的方法是 [使用 Helm](../helm/component)。
|
||||
## 怎么做
|
||||
|
||||
KubeVela 要求你在 `output` 部分定义工作负载类型的模板，并在 `outputs` 部分保留所有其他资源模板，格式如下：
|
||||
|
||||
```cue
|
||||
outputs: <unique-name>:
|
||||
<full template data>
|
||||
```
|
||||
|
||||
> 此要求的原因是 KubeVela 需要知道它当前正在渲染工作负载，因此它可以执行一些“魔术”，例如在此期间修补注释/标签或其他数据。
|
||||
下面是 `webserver` 定义的例子：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: webserver
|
||||
annotations:
|
||||
definition.oam.dev/description: "webserver is a combo of Deployment + Service"
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "Deployment"
|
||||
spec: {
|
||||
selector: matchLabels: {
|
||||
"app.oam.dev/component": context.name
|
||||
}
|
||||
template: {
|
||||
metadata: labels: {
|
||||
"app.oam.dev/component": context.name
|
||||
}
|
||||
spec: {
|
||||
containers: [{
|
||||
name: context.name
|
||||
image: parameter.image
|
||||
if parameter["cmd"] != _|_ {
|
||||
command: parameter.cmd
|
||||
}
|
||||
if parameter["env"] != _|_ {
|
||||
env: parameter.env
|
||||
}
|
||||
if context["config"] != _|_ {
|
||||
env: context.config
|
||||
}
|
||||
ports: [{
|
||||
containerPort: parameter.port
|
||||
}]
|
||||
if parameter["cpu"] != _|_ {
|
||||
resources: {
|
||||
limits:
|
||||
cpu: parameter.cpu
|
||||
requests:
|
||||
cpu: parameter.cpu
|
||||
}
|
||||
}
|
||||
}]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
// an extra template
|
||||
outputs: service: {
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
spec: {
|
||||
selector: {
|
||||
"app.oam.dev/component": context.name
|
||||
}
|
||||
ports: [
|
||||
{
|
||||
port: parameter.port
|
||||
targetPort: parameter.port
|
||||
},
|
||||
]
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
image: string
|
||||
cmd?: [...string]
|
||||
port: *80 | int
|
||||
env?: [...{
|
||||
name: string
|
||||
value?: string
|
||||
valueFrom?: {
|
||||
secretKeyRef: {
|
||||
name: string
|
||||
key: string
|
||||
}
|
||||
}
|
||||
}]
|
||||
cpu?: string
|
||||
}
|
||||
```
|
||||
|
||||
用户现在可以用它声明一个 `Application`：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: webserver-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: hello-world
|
||||
type: webserver
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
env:
|
||||
- name: "foo"
|
||||
value: "bar"
|
||||
cpu: "100m"
|
||||
```
|
||||
|
||||
它将在目标集群中生成和管理以下 API 资源：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
hello-world-v1 1/1 1 1 15s
|
||||
$ kubectl get svc
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
hello-world-trait-7bdcff98f7 ClusterIP <your ip> <none> 8000/TCP 32s
|
||||
```
|
||||
|
||||
## 使用 CLI 编辑管理 Definitions
|
||||
|
||||
在 Vela CLI 工具中，`vela def` 命令组为开发者提供了一系列便捷的 Definition 编写工具，使得 Definition 的编写将全部在 CUE 文件中进行，避免将 Template CUE 与 Kubernetes 的 YAML 格式进行混合，方便进行格式化与校验。
|
||||
|
||||
### init
|
||||
|
||||
`vela def init` 是一个用来帮助用户初始化新的 Definition 的脚手架命令。用户可以通过 `vela def init my-trait -t trait --desc "My trait description."` 来创建一个新的空白 TraitDefinition ，如下
|
||||
|
||||
```json
|
||||
"my-trait": {
|
||||
annotations: {}
|
||||
attributes: {
|
||||
appliesToWorkloads: []
|
||||
conflictsWith: []
|
||||
definitionRef: ""
|
||||
podDisruptive: false
|
||||
workloadRefPath: ""
|
||||
}
|
||||
description: "My trait description."
|
||||
labels: {}
|
||||
type: "trait"
|
||||
}
|
||||
template: patch: {}
|
||||
```
|
||||
|
||||
或者是采用 `vela def init my-comp --interactive` 来交互式地创建新的 Definition 。
|
||||
|
||||
```bash
|
||||
$ vela def init my-comp --interactive
|
||||
Please choose one definition type from the following values: component, trait, policy, workload, scope, workflow-step
|
||||
> Definition type: component
|
||||
> Definition description: My component definition.
|
||||
Please enter the location the template YAML file to build definition. Leave it empty to generate default template.
|
||||
> Definition template filename:
|
||||
Please enter the output location of the generated definition. Leave it empty to print definition to stdout.
|
||||
> Definition output filename: my-component.cue
|
||||
Definition written to my-component.cue
|
||||
```
|
||||
|
||||
除此之外，如果用户创建 ComponentDefinition 的目的是一个 Deployment（或者是其他的 Kubernetes Object ），而这个 Deployment 已经有了 YAML 格式的模版，用户还可以通过 `--template-yaml` 参数来完成从 YAML 到 CUE 的自动转换。例如如下的 `my-deployment.yaml`
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: hello-world
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: hello-world
|
||||
spec:
|
||||
containers:
|
||||
- name: hello-world
|
||||
image: somefive/hello-world
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 80
|
||||
protocol: TCP
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: hello-world-service
|
||||
spec:
|
||||
selector:
|
||||
app: hello-world
|
||||
ports:
|
||||
- name: http
|
||||
protocol: TCP
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
type: LoadBalancer
|
||||
```
|
||||
|
||||
运行 `vela def init my-comp -t component --desc "My component." --template-yaml ./my-deployment.yaml` 可以得到 CUE 格式的 ComponentDefinition
|
||||
|
||||
```json
|
||||
"my-comp": {
|
||||
annotations: {}
|
||||
attributes: workload: definition: {
|
||||
apiVersion: "<change me> apps/v1"
|
||||
kind: "<change me> Deployment"
|
||||
}
|
||||
description: "My component."
|
||||
labels: {}
|
||||
type: "component"
|
||||
}
|
||||
template: {
|
||||
output: {
|
||||
metadata: name: "hello-world"
|
||||
spec: {
|
||||
replicas: 1
|
||||
selector: matchLabels: "app.kubernetes.io/name": "hello-world"
|
||||
template: {
|
||||
metadata: labels: "app.kubernetes.io/name": "hello-world"
|
||||
spec: containers: [{
|
||||
name: "hello-world"
|
||||
image: "somefive/hello-world"
|
||||
ports: [{
|
||||
name: "http"
|
||||
containerPort: 80
|
||||
protocol: "TCP"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
apiVersion: "apps/v1"
|
||||
kind: "Deployment"
|
||||
}
|
||||
outputs: "hello-world-service": {
|
||||
metadata: name: "hello-world-service"
|
||||
spec: {
|
||||
ports: [{
|
||||
name: "http"
|
||||
protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
}]
|
||||
selector: app: "hello-world"
|
||||
type: "LoadBalancer"
|
||||
}
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
}
|
||||
parameter: {}
|
||||
}
|
||||
```
|
||||
|
||||
接下来，用户就可以在该文件的基础上进一步做进一步的修改了。比如将属性中对于 **workload.definition** 中的 *\<change me\>* 去掉。
|
||||
|
||||
### vet
|
||||
|
||||
在初始化 Definition 文件之后，可以运行 `vela def vet my-comp.cue` 来校验 Definition 是否在语法上有错误。比如如果少写了一个括号，该命令能够帮助用户识别出来。
|
||||
|
||||
```bash
|
||||
$ vela def vet my-comp.cue
|
||||
Validation succeed.
|
||||
```
|
||||
|
||||
### render / apply
|
||||
|
||||
确认 Definition 撰写无误后，开发者可以运行 `vela def apply my-comp.cue --namespace my-namespace` 来将该 Definition 应用在 Kubernetes 的 my-namespace 命名空间中。如果想了解一下 CUE 格式的 Definition 文件会被渲染成什么样的 Kubernetes YAML 文件，可以使用 `vela def apply my-comp.cue --dry-run` 或者 `vela def render my-comp.cue -o my-comp.yaml` 来预先渲染一下 YAML 文件进行确认。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: My component.
|
||||
labels: {}
|
||||
name: my-comp
|
||||
namespace: vela-system
|
||||
spec:
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
metadata: name: "hello-world"
|
||||
spec: {
|
||||
replicas: 1
|
||||
selector: matchLabels: "app.kubernetes.io/name": "hello-world"
|
||||
template: {
|
||||
metadata: labels: "app.kubernetes.io/name": "hello-world"
|
||||
spec: containers: [{
|
||||
name: "hello-world"
|
||||
image: "somefive/hello-world"
|
||||
ports: [{
|
||||
name: "http"
|
||||
containerPort: 80
|
||||
protocol: "TCP"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
apiVersion: "apps/v11"
|
||||
kind: "Deployment"
|
||||
}
|
||||
outputs: "hello-world-service": {
|
||||
metadata: name: "hello-world-service"
|
||||
spec: {
|
||||
ports: [{
|
||||
name: "http"
|
||||
protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
}]
|
||||
selector: app: "hello-world"
|
||||
type: "LoadBalancer"
|
||||
}
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
}
|
||||
parameter: {}
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
```
|
||||
|
||||
```bash
|
||||
$ vela def apply my-comp.cue -n my-namespace
|
||||
ComponentDefinition my-comp created in namespace my-namespace.
|
||||
```
|
||||
|
||||
### get / list / edit / del
|
||||
|
||||
在 apply 命令后，开发者可以采用原生的 kubectl 来对结果进行确认，但是正如我们上文提到的，YAML 格式的结果会相对复杂。使用 `vela def get` 命令可以自动将其转换成 CUE 格式，方便用户查看。
|
||||
|
||||
```bash
|
||||
$ vela def get my-comp -t component
|
||||
```
|
||||
|
||||
或者用户可以通过 `vela def list` 命令来查看当前系统中安装的所有 Definition（可以指定命名空间及类型）。
|
||||
|
||||
```bash
|
||||
$ vela def list -n my-namespace -t component
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
my-comp ComponentDefinition my-namespace My component.
|
||||
```
|
||||
|
||||
同样的，在使用 `vela def edit` 命令来编辑 Definition 时，用户也只需要对转换过的 CUE 格式 Definition 进行修改，该命令会自动完成格式转换。用户也可以通过设定环境变量 `EDITOR` 来使用自己想要使用的编辑器。
|
||||
|
||||
```bash
|
||||
$ EDITOR=vim vela def edit my-comp
|
||||
```
|
||||
|
||||
类似的，用户可以运行 `vela def del` 来删除相应的 Definition。
|
||||
|
||||
```bash
|
||||
$ vela def del my-comp -n my-namespace
|
||||
Are you sure to delete the following definition in namespace my-namespace?
|
||||
ComponentDefinition my-comp: My component.
|
||||
[yes|no] > yes
|
||||
ComponentDefinition my-comp in namespace my-namespace deleted.
|
||||
```
|
||||
|
||||
## 下一步是什么
|
||||
|
||||
请查看 [Learning CUE](./basic) 文档，了解我们为什么支持 CUE 作为一流的模板解决方案，以及有关有效使用 CUE 的更多详细信息。
|
||||
|
|
@ -17,8 +17,8 @@ KubeVela 将 CUE 作为应用交付核心依赖和扩展方式的原因如下：
|
|||
## 前提
|
||||
|
||||
请确保你的环境中已经安装如下命令行：
|
||||
* [`cue` >=v0.2.2](https://cuelang.org/docs/install/)
|
||||
* [`vela` >v1.0.0](../../getting-started/quick-install#3-get-kubevela-cli) 目前 KubeVela 暂时只支持 CUE v0.2.2 版本，将在后续迭代中升级支持新的 CUE 版本。
|
||||
* [`cue` v0.2.2](https://cuelang.org/docs/install/) 目前 KubeVela 暂时只支持 CUE v0.2.2 版本，将在后续迭代中升级支持新的 CUE 版本。
|
||||
* [`vela` >= v1.1.0](../../getting-started/quick-install#3-get-kubevela-cli)
|
||||
|
||||
## 学习 CUE 命令行
|
||||
|
||||
|
|
@ -557,4 +557,8 @@ output: {
|
|||
parameter: {
|
||||
name: "myapp"
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
## 下一步
|
||||
|
||||
统一使用 CUE 来[管理自定义 OAM 模块](./definition-edit)。
|
||||
|
|
@ -0,0 +1,242 @@
|
|||
---
|
||||
title: 管理 X-Definition
|
||||
---
|
||||
|
||||
在 KubeVela CLI (>= v1.1.0) 工具中，`vela def` 命令组为开发者提供了一系列便捷的 X-Definition 编写工具，使得 Definition 的编写将全部在 CUE 文件中进行，避免将 Template CUE 与 Kubernetes 的 YAML 格式进行混合，方便进行格式化与校验。
|
||||
|
||||
## init
|
||||
|
||||
`vela def init` 是一个用来帮助用户初始化新的 Definition 的脚手架命令。用户可以通过 `vela def init my-trait -t trait --desc "My trait description."` 来创建一个新的空白 TraitDefinition ，如下
|
||||
|
||||
```json
|
||||
"my-trait": {
|
||||
annotations: {}
|
||||
attributes: {
|
||||
appliesToWorkloads: []
|
||||
conflictsWith: []
|
||||
definitionRef: ""
|
||||
podDisruptive: false
|
||||
workloadRefPath: ""
|
||||
}
|
||||
description: "My trait description."
|
||||
labels: {}
|
||||
type: "trait"
|
||||
}
|
||||
template: patch: {}
|
||||
```
|
||||
|
||||
或者是采用 `vela def init my-comp --interactive` 来交互式地创建新的 Definition 。
|
||||
|
||||
```bash
|
||||
$ vela def init my-comp --interactive
|
||||
Please choose one definition type from the following values: component, trait, policy, workload, scope, workflow-step
|
||||
> Definition type: component
|
||||
> Definition description: My component definition.
|
||||
Please enter the location the template YAML file to build definition. Leave it empty to generate default template.
|
||||
> Definition template filename:
|
||||
Please enter the output location of the generated definition. Leave it empty to print definition to stdout.
|
||||
> Definition output filename: my-component.cue
|
||||
Definition written to my-component.cue
|
||||
```
|
||||
|
||||
除此之外，如果用户创建 ComponentDefinition 的目的是一个 Deployment（或者是其他的 Kubernetes Object ），而这个 Deployment 已经有了 YAML 格式的模版，用户还可以通过 `--template-yaml` 参数来完成从 YAML 到 CUE 的自动转换。例如如下的 `my-deployment.yaml`
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: hello-world
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: hello-world
|
||||
spec:
|
||||
containers:
|
||||
- name: hello-world
|
||||
image: somefive/hello-world
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 80
|
||||
protocol: TCP
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: hello-world-service
|
||||
spec:
|
||||
selector:
|
||||
app: hello-world
|
||||
ports:
|
||||
- name: http
|
||||
protocol: TCP
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
type: LoadBalancer
|
||||
```
|
||||
|
||||
运行 `vela def init my-comp -t component --desc "My component." --template-yaml ./my-deployment.yaml` 可以得到 CUE 格式的 ComponentDefinition
|
||||
|
||||
```json
|
||||
"my-comp": {
|
||||
annotations: {}
|
||||
attributes: workload: definition: {
|
||||
apiVersion: "<change me> apps/v1"
|
||||
kind: "<change me> Deployment"
|
||||
}
|
||||
description: "My component."
|
||||
labels: {}
|
||||
type: "component"
|
||||
}
|
||||
template: {
|
||||
output: {
|
||||
metadata: name: "hello-world"
|
||||
spec: {
|
||||
replicas: 1
|
||||
selector: matchLabels: "app.kubernetes.io/name": "hello-world"
|
||||
template: {
|
||||
metadata: labels: "app.kubernetes.io/name": "hello-world"
|
||||
spec: containers: [{
|
||||
name: "hello-world"
|
||||
image: "somefive/hello-world"
|
||||
ports: [{
|
||||
name: "http"
|
||||
containerPort: 80
|
||||
protocol: "TCP"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
apiVersion: "apps/v1"
|
||||
kind: "Deployment"
|
||||
}
|
||||
outputs: "hello-world-service": {
|
||||
metadata: name: "hello-world-service"
|
||||
spec: {
|
||||
ports: [{
|
||||
name: "http"
|
||||
protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
}]
|
||||
selector: app: "hello-world"
|
||||
type: "LoadBalancer"
|
||||
}
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
}
|
||||
parameter: {}
|
||||
}
|
||||
```
|
||||
|
||||
接下来，用户就可以在该文件的基础上进一步做进一步的修改了。比如将属性中对于 **workload.definition** 中的 *\<change me\>* 去掉。
|
||||
|
||||
## vet
|
||||
|
||||
在初始化 Definition 文件之后，可以运行 `vela def vet my-comp.cue` 来校验 Definition 是否在语法上有错误。比如如果少写了一个括号，该命令能够帮助用户识别出来。
|
||||
|
||||
```bash
|
||||
$ vela def vet my-comp.cue
|
||||
Validation succeed.
|
||||
```
|
||||
|
||||
## render / apply
|
||||
|
||||
确认 Definition 撰写无误后，开发者可以运行 `vela def apply my-comp.cue --namespace my-namespace` 来将该 Definition 应用在 Kubernetes 的 my-namespace 命名空间中。如果想了解一下 CUE 格式的 Definition 文件会被渲染成什么样的 Kubernetes YAML 文件，可以使用 `vela def apply my-comp.cue --dry-run` 或者 `vela def render my-comp.cue -o my-comp.yaml` 来预先渲染一下 YAML 文件进行确认。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: My component.
|
||||
labels: {}
|
||||
name: my-comp
|
||||
namespace: vela-system
|
||||
spec:
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
metadata: name: "hello-world"
|
||||
spec: {
|
||||
replicas: 1
|
||||
selector: matchLabels: "app.kubernetes.io/name": "hello-world"
|
||||
template: {
|
||||
metadata: labels: "app.kubernetes.io/name": "hello-world"
|
||||
spec: containers: [{
|
||||
name: "hello-world"
|
||||
image: "somefive/hello-world"
|
||||
ports: [{
|
||||
name: "http"
|
||||
containerPort: 80
|
||||
protocol: "TCP"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
apiVersion: "apps/v11"
|
||||
kind: "Deployment"
|
||||
}
|
||||
outputs: "hello-world-service": {
|
||||
metadata: name: "hello-world-service"
|
||||
spec: {
|
||||
ports: [{
|
||||
name: "http"
|
||||
protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
}]
|
||||
selector: app: "hello-world"
|
||||
type: "LoadBalancer"
|
||||
}
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
}
|
||||
parameter: {}
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
```
|
||||
|
||||
```bash
|
||||
$ vela def apply my-comp.cue -n my-namespace
|
||||
ComponentDefinition my-comp created in namespace my-namespace.
|
||||
```
|
||||
|
||||
## get / list / edit / del
|
||||
|
||||
在 apply 命令后，开发者可以采用原生的 kubectl 来对结果进行确认，但是正如我们上文提到的，YAML 格式的结果会相对复杂。使用 `vela def get` 命令可以自动将其转换成 CUE 格式，方便用户查看。
|
||||
|
||||
```bash
|
||||
$ vela def get my-comp -t component
|
||||
```
|
||||
|
||||
或者用户可以通过 `vela def list` 命令来查看当前系统中安装的所有 Definition（可以指定命名空间及类型）。
|
||||
|
||||
```bash
|
||||
$ vela def list -n my-namespace -t component
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
my-comp ComponentDefinition my-namespace My component.
|
||||
```
|
||||
|
||||
同样的，在使用 `vela def edit` 命令来编辑 Definition 时，用户也只需要对转换过的 CUE 格式 Definition 进行修改，该命令会自动完成格式转换。用户也可以通过设定环境变量 `EDITOR` 来使用自己想要使用的编辑器。
|
||||
|
||||
```bash
|
||||
$ EDITOR=vim vela def edit my-comp
|
||||
```
|
||||
|
||||
类似的，用户可以运行 `vela def del` 来删除相应的 Definition。
|
||||
|
||||
```bash
|
||||
$ vela def del my-comp -n my-namespace
|
||||
Are you sure to delete the following definition in namespace my-namespace?
|
||||
ComponentDefinition my-comp: My component.
|
||||
[yes|no] > yes
|
||||
ComponentDefinition my-comp in namespace my-namespace deleted.
|
||||
```
|
||||
|
|
@ -89,3 +89,7 @@ KubeVela 当前内置的工作流步骤节点包括了创建资源、条件判
|
|||
在具体实现上，KubeVela 采用了脱胎于 Google Borg 系统的 [CUE 配置语言](https://cuelang.org/) 作为模型层实现，从而以 IaC (Infrastructure-as-Code) 的方式实现了 OAM 各个模块之间的高效协作和灵活扩展。但另一方面，常规的 IaC 技术往往会引入“配置漂移”（Infrastructure/Configuration Drift）的问题，即：当用户声明的应用部署配置和生产环境实际运行的实例状态发生不一致时，IaC 就无能为力了。
|
||||
|
||||
所以 KubeVela 在采用 IaC 技术实现的同时，还同时通过 [Kubernetes 控制循环](https://kubernetes.io/docs/concepts/architecture/controller/) 来管控整个 IaC 模型的渲染和执行，从而以完全自动化的方式保证了应用配置和终态的一致性，同时在模块定义、封装、扩展过程中保留了完整的 IaC 的使用体验。简介明了的 CUE 模板语法是平台管理员自行扩展 KubeVela 时唯一需要学习的一项技术。
|
||||
|
||||
## 下一步
|
||||
|
||||
- [X-Definition](x-definition) 对接标准化模型：在这些概念的背后，平台管理员可以利用 OAM 的扩展功能，通过自定义的方式对接自己的基础设施能力到开发模型中，以统一的方式暴露用户功能。而这些扩展的对接方式，就是[X-Definition](x-definition)。
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 模块定义（X-Definitions）
|
||||
title: 模块定义（X-Definition）
|
||||
---
|
||||
|
||||
最终用户使用的 OAM 模型 [应用部署计划 Application](./oam-model) 中，有很多声明“类型的字段”，如组件类型、运维特征类型、应用策略类型、工作流节点类型等，这些类型实际上就是 OAM 模型的模块定义（X-Definition）。
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ module.exports = {
|
|||
},
|
||||
{
|
||||
'Policies': [
|
||||
'end-user/policies/envbinding',
|
||||
'end-user/policies/envbinding',
|
||||
]
|
||||
},
|
||||
{
|
||||
|
|
@ -100,7 +100,7 @@ module.exports = {
|
|||
type: 'category',
|
||||
label: 'Learning OAM',
|
||||
collapsed: false,
|
||||
items:[
|
||||
items: [
|
||||
'platform-engineers/oam/oam-model',
|
||||
'platform-engineers/oam/x-definition',
|
||||
]
|
||||
|
|
@ -108,6 +108,7 @@ module.exports = {
|
|||
{
|
||||
'Learning CUE': [
|
||||
'platform-engineers/cue/basic',
|
||||
'platform-engineers/cue/definition-edit',
|
||||
// 'platform-engineers/cue/advanced', 暂时隐藏，来不及随 1.1 发布，随后补充
|
||||
]
|
||||
},
|
||||
|
|
|
|||
Loading…
Reference in New Issue