From 3eaeb2dd095a3a80a7594b5ebcac3921bf0d0c82 Mon Sep 17 00:00:00 2001 From: Jianbo Sun Date: Mon, 30 Aug 2021 13:08:41 +0800 Subject: [PATCH] update docs (#215) --- .gitignore | 1 + docs/end-user/binding-traits.md | 5 + .../cue}/examples/app-stateful.yaml | 0 .../cue}/examples/my-stateful.cue | 0 .../cue}/examples/my-stateful.yaml | 0 .../policy/custom-policy.md | 5 + .../workflow/custom-workflow.md | 5 + .../current/case-studies/paas.md | 357 -------------- .../current/end-user/component-delivery.md | 25 +- .../platform-engineers/cue/advanced.md | 451 +++++++++++++++++- .../current/platform-engineers/cue/basic.md | 2 +- .../platform-engineers/cue/definition-edit.md | 6 +- .../platform-engineers/debug/dry-run.md | 135 ------ .../policy/custom-policy.md | 5 + .../workflow/custom-workflow.md | 5 + sidebars.js | 6 +- 16 files changed, 501 insertions(+), 507 deletions(-) create mode 100644 docs/end-user/binding-traits.md rename docs/{case-studies => platform-engineers/cue}/examples/app-stateful.yaml (100%) rename docs/{case-studies => platform-engineers/cue}/examples/my-stateful.cue (100%) rename docs/{case-studies => platform-engineers/cue}/examples/my-stateful.yaml (100%) create mode 100644 docs/platform-engineers/policy/custom-policy.md create mode 100644 docs/platform-engineers/workflow/custom-workflow.md delete mode 100644 i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/debug/dry-run.md create mode 100644 i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/policy/custom-policy.md create mode 100644 i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/workflow/custom-workflow.md diff --git a/.gitignore b/.gitignore index fa14071a..0747e0d3 100644 --- a/.gitignore +++ b/.gitignore @@ -5,6 +5,7 @@ /build .Ulysses-Settings.plist +.Ulysses-Group.plist # Generated files .docusaurus diff --git a/docs/end-user/binding-traits.md b/docs/end-user/binding-traits.md new file mode 100644 index 00000000..91262386 --- /dev/null +++ b/docs/end-user/binding-traits.md @@ -0,0 +1,5 @@ +--- +title: Binding Traits +--- + +WIP \ No newline at end of file diff --git a/docs/case-studies/examples/app-stateful.yaml b/docs/platform-engineers/cue/examples/app-stateful.yaml similarity index 100% rename from docs/case-studies/examples/app-stateful.yaml rename to docs/platform-engineers/cue/examples/app-stateful.yaml diff --git a/docs/case-studies/examples/my-stateful.cue b/docs/platform-engineers/cue/examples/my-stateful.cue similarity index 100% rename from docs/case-studies/examples/my-stateful.cue rename to docs/platform-engineers/cue/examples/my-stateful.cue diff --git a/docs/case-studies/examples/my-stateful.yaml b/docs/platform-engineers/cue/examples/my-stateful.yaml similarity index 100% rename from docs/case-studies/examples/my-stateful.yaml rename to docs/platform-engineers/cue/examples/my-stateful.yaml diff --git a/docs/platform-engineers/policy/custom-policy.md b/docs/platform-engineers/policy/custom-policy.md new file mode 100644 index 00000000..6ec75d24 --- /dev/null +++ b/docs/platform-engineers/policy/custom-policy.md @@ -0,0 +1,5 @@ +--- +title: Custom Policy +--- + +TBD \ No newline at end of file diff --git a/docs/platform-engineers/workflow/custom-workflow.md b/docs/platform-engineers/workflow/custom-workflow.md new file mode 100644 index 00000000..a796edfb --- /dev/null +++ b/docs/platform-engineers/workflow/custom-workflow.md @@ -0,0 +1,5 @@ +--- +title: Custom Workflow +--- + +TBD \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/case-studies/paas.md b/i18n/zh/docusaurus-plugin-content-docs/current/case-studies/paas.md index ea532c36..2b44e40f 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/case-studies/paas.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/case-studies/paas.md @@ -1,360 +1,3 @@ --- title: 易用可扩展的 PaaS --- - -以 Kubernetes 为核心的云原生技术大多是围绕基础设施向上为平台构建者提供服务的，其功能的多样性和灵活性决定了用户学习使用这些技术有很高的门槛。传统 PaaS 的做法是将复杂的 API 进行固定的封装，以达到降低使用复杂度的目的。但是云原生时代用户的需求不再一成不变，会频繁随着复杂的使用场景不断改变。 - -KubeVela 针对这种使用需求，为平台管理员提供了一个易用可扩展的 PaaS 引擎，可以随着用户需求变化动态扩展 PaaS 层的能力。使得你的 PaaS 平台可以适应各类用户和场景，满足公司业务长期发展的迭代诉求。 - -> 注意：此用户案例的学习对象为期望构建可扩展 PaaS 的平台管理员。开始之前请确保你已经了解了[OAM 模型][1]和[模块定义（X-Definition ）][2]的概念。 - -## 将 Kubernetes API 对象转化为自定义组件 - -KubeVela 使用 [CUE][3] 构建用户抽象，也就是将复杂的 Kubernetes API 遮挡，只暴露简单的参数，同时也围绕 CUE 提供了管理工具来[编辑和生成 KubeVela 的模块定义对象][4]。 - -下面我们以 Kubernetes 官方的 [StatefulSet 对象][5]为例，来具体看 KubeVela 是如何构建用户抽象的。我们将官方文档中 StatefulSet 的 YAML 例子保存在本地，并命名为 `my-stateful.yaml` - -然后执行如下命令，生成一个名为 “my-stateful” 的 Component 模块定义，并输出到 “my-stateful.cue” 文件中： - - vela def init my-stateful -t component --desc "My StatefulSet component." --template-yaml ./my-stateful.yaml -o my-stateful.cue - -查看生成的 “my-stateful.cue” 文件： - - $ cat my-stateful.cue - "my-stateful": { - annotations: {} - attributes: workload: definition: { - apiVersion: " apps/v1" - kind: " Deployment" - } - description: "My StatefulSet component." - labels: {} - type: "component" - } - - template: { - output: { - apiVersion: "v1" - kind: "Service" - ... // 省略一些非重要信息 - } - outputs: web: { - apiVersion: "apps/v1" - kind: "StatefulSet" - ... // 省略一些非重要信息 - } - parameter: {} - } - -下面我们来对这个自动生成的自定义组件做一些修改： - -1. 根据 KubeVela [自定义组件的规则][6]，StatefulSet 官网的例子是由 `StatefulSet`和 `Service` 两个对象构成的一个复合组件，复合组件中，核心工作负载由 `template.output`字段表示，其他辅助对象用 `template.outputs`表示，所以我们将内容做一些调整，将自动生成的 output 和 outputs 中的全部调换。 -2. 然后我们将核心工作负载的 apiVersion 和 kind 数据填写到标注为 ``的部分 - -修改后可以用 `vela def vet`做一下格式检查和校验。 - - $ vela def vet my-stateful.cue - Validation succeed. - -经过两步改动后的文件如下： - - $ cat my-stateful.cue - "my-stateful": { - annotations: {} - attributes: workload: definition: { - apiVersion: "apps/v1" - kind: "StatefulSet" - } - description: "My StatefulSet component." - labels: {} - type: "component" - } - - template: { - output: { - apiVersion: "apps/v1" - kind: "StatefulSet" - metadata: name: "web" - spec: { - selector: matchLabels: app: "nginx" - replicas: 3 - serviceName: "nginx" - template: { - metadata: labels: app: "nginx" - spec: { - containers: [{ - name: "nginx" - ports: [{ - name: "web" - containerPort: 80 - }] - image: "k8s.gcr.io/nginx-slim:0.8" - volumeMounts: [{ - name: "www" - mountPath: "/usr/share/nginx/html" - }] - }] - terminationGracePeriodSeconds: 10 - } - } - volumeClaimTemplates: [{ - metadata: name: "www" - spec: { - accessModes: ["ReadWriteOnce"] - resources: requests: storage: "1Gi" - storageClassName: "my-storage-class" - } - }] - } - } - outputs: web: { - apiVersion: "v1" - kind: "Service" - metadata: { - name: "nginx" - labels: app: "nginx" - } - spec: { - clusterIP: "None" - ports: [{ - name: "web" - port: 80 - }] - selector: app: "nginx" - } - } - parameter: {} - } - -将该组件定义安装到 Kubernetes 集群中： - - $ vela def apply my-stateful.cue - ComponentDefinition my-stateful created in namespace vela-system. - -此时平台的最终用户已经可以通过 `vela components`命令看到有一个 `my-stateful`组件可以使用了。 - - $ vela components - NAME NAMESPACE WORKLOAD DESCRIPTION - ... - my-stateful vela-system statefulsets.apps My StatefulSet component. - ... - -通过 KubeVela 的应用部署计划发布到集群中，就可以拉起我们刚刚定义的 StatefulSet 和 Service 对象。 - - cat < apps/v1" + kind: " Deployment" + } + description: "My StatefulSet component." + labels: {} + type: "component" + } + + template: { + output: { + apiVersion: "v1" + kind: "Service" + ... // 省略一些非重要信息 + } + outputs: web: { + apiVersion: "apps/v1" + kind: "StatefulSet" + ... // 省略一些非重要信息 + } + parameter: {} + } + +下面我们来对这个自动生成的自定义组件做一些微调： + +1. 根据 KubeVela [自定义组件的规则][6]，StatefulSet 官网的例子是由 `StatefulSet`和 `Service` 两个对象构成的一个复合组件，复合组件中，核心工作负载由 `template.output`字段表示，其他辅助对象用 `template.outputs`表示，所以我们将内容做一些调整，将自动生成的 output 和 outputs 中的全部调换。 +2. 然后我们将核心工作负载的 apiVersion 和 kind 数据填写到标注为 ``的部分 + +修改后可以用 `vela def vet`做一下格式检查和校验。 + + $ vela def vet my-stateful.cue + Validation succeed. + +经过两步改动后的文件如下： + + $ cat my-stateful.cue + "my-stateful": { + annotations: {} + attributes: workload: definition: { + apiVersion: "apps/v1" + kind: "StatefulSet" + } + description: "My StatefulSet component." + labels: {} + type: "component" + } + + template: { + output: { + apiVersion: "apps/v1" + kind: "StatefulSet" + metadata: name: "web" + spec: { + selector: matchLabels: app: "nginx" + replicas: 3 + serviceName: "nginx" + template: { + metadata: labels: app: "nginx" + spec: { + containers: [{ + name: "nginx" + ports: [{ + name: "web" + containerPort: 80 + }] + image: "k8s.gcr.io/nginx-slim:0.8" + volumeMounts: [{ + name: "www" + mountPath: "/usr/share/nginx/html" + }] + }] + terminationGracePeriodSeconds: 10 + } + } + volumeClaimTemplates: [{ + metadata: name: "www" + spec: { + accessModes: ["ReadWriteOnce"] + resources: requests: storage: "1Gi" + storageClassName: "my-storage-class" + } + }] + } + } + outputs: web: { + apiVersion: "v1" + kind: "Service" + metadata: { + name: "nginx" + labels: app: "nginx" + } + spec: { + clusterIP: "None" + ports: [{ + name: "web" + port: 80 + }] + selector: app: "nginx" + } + } + parameter: {} + } + +将该组件定义安装到 Kubernetes 集群中： + + $ vela def apply my-stateful.cue + ComponentDefinition my-stateful created in namespace vela-system. + +此时平台的最终用户已经可以通过 `vela components`命令看到有一个 `my-stateful`组件可以使用了。 + + $ vela components + NAME NAMESPACE WORKLOAD DESCRIPTION + ... + my-stateful vela-system statefulsets.apps My StatefulSet component. + ... + +通过 KubeVela 的应用部署计划发布到集群中，就可以拉起我们刚刚定义的 StatefulSet 和 Service 对象。 + + cat < + +``` +# Application(website) -- Component(my-component) +--- + +apiVersion: v1 +kind: Service +metadata: + labels: + app: nginx + app.oam.dev/appRevision: "" + app.oam.dev/component: my-component + app.oam.dev/name: website + workload.oam.dev/type: my-stateful + name: nginx + namespace: default +spec: + clusterIP: None + ports: + - name: web + port: 80 + selector: + app: nginx + template: + spec: + containers: + - image: saravak/fluentd:elastic + name: my-sidecar + +--- +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.oam.dev/appRevision: "" + app.oam.dev/component: my-component + app.oam.dev/name: website + trait.oam.dev/resource: web + trait.oam.dev/type: AuxiliaryWorkload + name: web + namespace: default +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + serviceName: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - image: k8s.gcr.io/nginx-slim:0.8 + name: nginx + ports: + - containerPort: 80 + name: web + volumeMounts: + - mountPath: /usr/share/nginx/html + name: www + terminationGracePeriodSeconds: 10 + volumeClaimTemplates: + - metadata: + name: www + spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: my-storage-class +``` + + + + +你还可以通过 `vela dry-run -h` 来查看更多可用的功能参数。 + + +## 使用上下文信息减少参数 + +在我们上面的 Application 例子中，properties 中的 name 和 Component 的 name 字段是相同的，此时我们可以在模板中使用携带了上下文信息的 `context`关键字，其中 `context.name` 就是运行时组件名称，此时 `parameter` 中的 name 参数就不再需要的。 + + ... # 省略其他没有修改的字段 + template: { + output: { + apiVersion: "apps/v1" + kind: "StatefulSet" + metadata: name: context.name + ... // 省略其他没有修改的字段 + } + parameter: { + image: string + replicas: int + } + } + +KubeVela 内置了应用[所需的上下文信息][9]，你可以根据需要配置. + +## 使用运维能力按需添加配置 + +对于用户的新需求，除了修改组件定义增加参数以外，你还可以使用运维能力，按需添加配置。一方面，KubeVela 已经内置了大量的通用运维能力，可以满足诸如：添加 label、annotation，注入环境变量、sidecar，添加 volume 等等的需求。另一方面，你可以像自定义组件一样，自定义[补丁型运维特征][10]，来满足更多的配置灵活组装的需求。 + +你可以使用 `vela traits` 查看，带 `*` 标记的 trait 均为通用 trait，能够对常见的 Kubernetes 资源对象做操作。 + + $ vela traits + NAME NAMESPACE APPLIES-TO CONFLICTS-WITH POD-DISRUPTIVE DESCRIPTION + annotations vela-system * true Add annotations on K8s pod for your workload which follows + the pod spec in path 'spec.template'. + configmap vela-system * true Create/Attach configmaps on K8s pod for your workload which + follows the pod spec in path 'spec.template'. + env vela-system * false add env on K8s pod for your workload which follows the pod + spec in path 'spec.template.' + hostalias vela-system * false Add host aliases on K8s pod for your workload which follows + the pod spec in path 'spec.template'. + labels vela-system * true Add labels on K8s pod for your workload which follows the + pod spec in path 'spec.template'. + lifecycle vela-system * true Add lifecycle hooks for the first container of K8s pod for + your workload which follows the pod spec in path + 'spec.template'. + node-affinity vela-system * true affinity specify node affinity and toleration on K8s pod for + your workload which follows the pod spec in path + 'spec.template'. + scaler vela-system * false Manually scale K8s pod for your workload which follows the + pod spec in path 'spec.template'. + sidecar vela-system * true Inject a sidecar container to K8s pod for your workload + which follows the pod spec in path 'spec.template'. + + +以 sidecar 为例，你可以查看 sidecar 的用法： + + $ vela show sidecar + # Properties + +---------+-----------------------------------------+-----------------------+----------+---------+ + | NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT | + +---------+-----------------------------------------+-----------------------+----------+---------+ + | name | Specify the name of sidecar container | string | true | | + | cmd | Specify the commands run in the sidecar | []string | false | | + | image | Specify the image of sidecar container | string | true | | + | volumes | Specify the shared volume path | [[]volumes](#volumes) | false | | + +---------+-----------------------------------------+-----------------------+----------+---------+ + + + ## volumes + +------+-------------+--------+----------+---------+ + | NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT | + +------+-------------+--------+----------+---------+ + | path | | string | true | | + | name | | string | true | | + +------+-------------+--------+----------+---------+ + +直接使用 sidecar 注入一个容器，应用的描述如下： + + apiVersion: core.oam.dev/v1beta1 + kind: Application + metadata: + name: website + spec: + components: + - name: my-component + type: my-stateful + properties: + image: nginx:latest + replicas: 1 + name: my-component + traits: + - type: sidecar + properties: + name: my-sidecar + image: saravak/fluentd:elastic + +部署运行该应用，就可以看到 StatefulSet 中已经部署运行了一个 fluentd 的 sidecar。 + +你也可以使用 `vela def` 获取 sidecar 的 CUE 源文件进行修改，增加参数等。 + + vela def get sidecar + +运维能力的自定义与组件自定义类似，不再赘述，你可以阅读[运维能力自定义文档][11]了解更详细的功能。 + +## 总结 + +本节介绍了如何通过 CUE 交付完整的模块化能力，其核心是可以随着用户的需求，不断动态增加配置能力，逐步暴露更多的功能和用法，以便降低用户整体的学习门槛，最终提升研发效率。 +KubeVela 背后提供的开箱即用的能力，包括组件、运维功能、策略以及工作流，均是通过同样的方式提供了可插拔、可修改的能力。 + +## 下一步 + +* 了解更多[自定义组件](../components/custom-component)的功能。 +* 了解更多[自定义运维能力](../traits/customize-trait)的功能。 +* 了解[自定义策略](../policy/custom-policy)背后的功能。 +* 了解[自定义工作流](../workflow/custom-workflow)背后的功能。 + +[1]: ../oam/oam-model +[2]: ../oam/x-definition +[3]: ../cue/basic +[4]: ../cue/definition-edit +[5]: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ +[6]: ../components/custom-component#%E4%BA%A4%E4%BB%98%E4%B8%80%E4%B8%AA%E5%A4%8D%E5%90%88%E7%9A%84%E8%87%AA%E5%AE%9A%E4%B9%89%E7%BB%84%E4%BB%B6 +[7]: ../cue/basic#%E5%AE%9A%E4%B9%89%E4%B8%80%E4%B8%AA-cue-%E6%A8%A1%E6%9D%BF +[9]: ../oam/x-definition#%E6%A8%A1%E5%9D%97%E5%AE%9A%E4%B9%89%E8%BF%90%E8%A1%8C%E6%97%B6%E4%B8%8A%E4%B8%8B%E6%96%87 +[10]: ../traits/patch-trait +[11]: ../traits/customize-trait diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/cue/basic.md b/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/cue/basic.md index 9d57e63e..72f54395 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/cue/basic.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/cue/basic.md @@ -561,4 +561,4 @@ parameter: { ## 下一步 -统一使用 CUE 来[管理自定义 OAM 模块](./definition-edit)。 \ No newline at end of file +* 了解如何统一使用 CUE 来[管理自定义 OAM 模块](./definition-edit)。 \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/cue/definition-edit.md b/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/cue/definition-edit.md index e2f5f858..d816de3f 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/cue/definition-edit.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/cue/definition-edit.md @@ -1,5 +1,5 @@ --- -title: 管理 X-Definition +title: 编辑管理模块定义 --- 在 KubeVela CLI (>= v1.1.0) 工具中，`vela def` 命令组为开发者提供了一系列便捷的 X-Definition 编写工具，使得 Definition 的编写将全部在 CUE 文件中进行，避免将 Template CUE 与 Kubernetes 的 YAML 格式进行混合，方便进行格式化与校验。 @@ -240,3 +240,7 @@ ComponentDefinition my-comp: My component. [yes|no] > yes ComponentDefinition my-comp in namespace my-namespace deleted. ``` + +## 下一步 + +* 了解如何使用 CUE 和 KubeVela 工具[交付完整的模块能力](./advanced)。 \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/debug/dry-run.md b/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/debug/dry-run.md deleted file mode 100644 index 396c8802..00000000 --- a/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/debug/dry-run.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -title: 本地试运行 ---- - -如果你是一个 DevOps 用户或者运维管理员，并且对 Kubernetes 有所了解，为了保证一个应用部署计划在 Kubernetes 运行时集群的表现符合期望，在开发调试阶段，你也可以通过下面的试运行功能提前确认这个部署计划背后的逻辑是否正确。 - -KubeVela 提供了本地试运行（Dry-run）的功能，来满足你的这个需求。 - -### 如何使用 - -我们将以一个应用部署计划的示例，来进行讲解。 - -首先编写如下的 YAML 文件： - -```yaml -# app.yaml -apiVersion: core.oam.dev/v1beta1 -kind: Application -metadata: - name: vela-app -spec: - components: - - name: express-server - type: webservice - properties: - image: crccheck/hello-world - port: 8000 - traits: - - type: ingress - properties: - domain: testsvc.example.com - http: - "/": 8000 -``` - -可以看到，我们的期望是交付一个 Web Service 的组件，使用来自 `crccheck/hello-world` 的镜像，并最终提供一个可供对外访问的网关，地址域名为 `testsvc.example.com`，端口号 8000。 - -然后打开本地试运行模式，使用如下命令： - -```shell -kubectl vela dry-run -f app.yaml -``` -```console ---- -# Application(vela-app) -- Comopnent(express-server) ---- - -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - app.oam.dev/appRevision: "" - app.oam.dev/component: express-server - app.oam.dev/name: vela-app - workload.oam.dev/type: webservice -spec: - selector: - matchLabels: - app.oam.dev/component: express-server - template: - metadata: - labels: - app.oam.dev/component: express-server - spec: - containers: - - image: crccheck/hello-world - name: express-server - ports: - - containerPort: 8000 - ---- -apiVersion: v1 -kind: Service -metadata: - labels: - app.oam.dev/appRevision: "" - app.oam.dev/component: express-server - app.oam.dev/name: vela-app - trait.oam.dev/resource: service - trait.oam.dev/type: ingress - name: express-server -spec: - ports: - - port: 8000 - targetPort: 8000 - selector: - app.oam.dev/component: express-server - ---- -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - labels: - app.oam.dev/appRevision: "" - app.oam.dev/component: express-server - app.oam.dev/name: vela-app - trait.oam.dev/resource: ingress - trait.oam.dev/type: ingress - name: express-server -spec: - rules: - - host: testsvc.example.com - http: - paths: - - backend: - serviceName: express-server - servicePort: 8000 - path: / - ---- -``` - -查看本地试运行模式给出的信息，我们可以进行确认： - -1. Kubernetes 集群内部 Service 和我们期望的 `kind: Deployment` 部署，在相关的镜像地址、域名端口上，是否能匹配。 -2. 最终对外的 Ingress 网关，与 Kubernetes 集群内部的 `Service`，在相关的镜像地址、域名端口上，是否能匹配。 - -在完成上述信息确认之后，我们就能进行后续的开发调试步骤了。 - -最后，你还可以通过 `kubectl vela dry-run -h` 来查看更多可用的本地试运行模式： - -``` -Usage: - vela dry-run - -Examples: -kubectl vela dry-run - -Flags: - -d, --definition string specify a definition file or directory, it will only be used in dry-run rather than applied to K8s cluster - -f, --file string application file name (default "./app.yaml") - -h, --help help for dry-run - -n, --namespace string specify namespace of the definition file, by default is default namespace (default "default") -``` - diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/policy/custom-policy.md b/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/policy/custom-policy.md new file mode 100644 index 00000000..827d01b4 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/policy/custom-policy.md @@ -0,0 +1,5 @@ +--- +title: 自定义策略 +--- + +TBD \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/workflow/custom-workflow.md b/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/workflow/custom-workflow.md new file mode 100644 index 00000000..00348712 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/workflow/custom-workflow.md @@ -0,0 +1,5 @@ +--- +title: 自定义工作流 +--- + +TBD \ No newline at end of file diff --git a/sidebars.js b/sidebars.js index a76f294b..23960dfb 100644 --- a/sidebars.js +++ b/sidebars.js @@ -33,7 +33,7 @@ module.exports = { // 'end-user/components/helm', // 'end-user/components/kustomize', // 'end-user/components/cue', - // 'end-user/components/cloud-services', 先隐藏，需要等用户侧的云服务支持 terraform 原生的 HCL + // 'end-user/components/cloud-services', 先隐藏，需要等用户侧的云服务支持 terraform 原生的 HCL // { // 'Cloud Services': [ // { @@ -105,7 +105,7 @@ module.exports = { 'Learning CUE': [ 'platform-engineers/cue/basic', 'platform-engineers/cue/definition-edit', - // 'platform-engineers/cue/advanced', 暂时隐藏，来不及随 1.1 发布，随后补充 + 'platform-engineers/cue/advanced', ] }, { @@ -159,7 +159,7 @@ module.exports = { label: 'Case Studies', collapsed: false, items: [ - 'case-studies/paas', + // 'case-studies/paas', // 'case-studies/workflow-edge-computing', // 待完成 // 'case-studies/li-auto-inc', 暂时下掉，应该改写成一个 10 - 15 分钟体验的产品 lab 例子 // 'case-studies/workflow-with-ocm',