From 50bfeabb7645a53f177d52165dbd4d5f6080b4b6 Mon Sep 17 00:00:00 2001 From: Jianbo Sun Date: Tue, 4 Jul 2023 15:38:03 +0800 Subject: [PATCH] Update v1.8 version doc with faq Signed-off-by: Jianbo Sun --- .../version-v1.8/end-user/traits/sidecar.md | 22 ++++++- .../addons/nginx-ingress-controller.md | 15 ++--- .../version-v1.8/tutorials/helm.md | 5 +- .../developers/references/devex/faq.md | 18 ++++-- .../version-v1.8/end-user/traits/sidecar.md | 2 +- .../how-to/dashboard/trigger/overview.md | 62 +++++++++++++++++++ .../version-v1.8/installation/kubernetes.mdx | 2 +- .../platform-engineers/addon/intro.md | 6 +- .../version-v1.8/reference/addons/velaux.md | 38 ++++++------ versioned_docs/version-v1.8/tutorials/helm.md | 5 +- versioned_docs/version-v1.8/tutorials/sso.md | 5 +- versions.json | 2 +- 12 files changed, 137 insertions(+), 45 deletions(-) diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/end-user/traits/sidecar.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/end-user/traits/sidecar.md index fc0c1045..89d63478 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/end-user/traits/sidecar.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/end-user/traits/sidecar.md @@ -62,13 +62,29 @@ APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS C vela-app-with-sidecar log-gen-worker worker sidecar running healthy 2021-08-29 22:07:07 +0800 CST ``` - 成功后，查看 Sidecar 所输出的日志 -``` -vela logs vela-app-with-sidecar -c count-log +```shell +vela logs vela-app-with-sidecar --container count-log ``` 从输出的日志可以看到读取日志的 sidecar 已经生效。 +
+expected output + +```console +0: Fri Apr 16 11:08:45 UTC 2021 +1: Fri Apr 16 11:08:46 UTC 2021 +2: Fri Apr 16 11:08:47 UTC 2021 +3: Fri Apr 16 11:08:48 UTC 2021 +4: Fri Apr 16 11:08:49 UTC 2021 +5: Fri Apr 16 11:08:50 UTC 2021 +6: Fri Apr 16 11:08:51 UTC 2021 +7: Fri Apr 16 11:08:52 UTC 2021 +8: Fri Apr 16 11:08:53 UTC 2021 +9: Fri Apr 16 11:08:54 UTC 2021 +``` + +
diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/reference/addons/nginx-ingress-controller.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/reference/addons/nginx-ingress-controller.md index cd11ecdc..888dec4f 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/reference/addons/nginx-ingress-controller.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/reference/addons/nginx-ingress-controller.md @@ -7,7 +7,7 @@ title: Nginx Ingress Controller ## 安装 ```shell -vela addon enable ingress-controller +vela addon enable ingress-nginx ``` ## 指定 Service Type @@ -16,12 +16,12 @@ vela addon enable ingress-controller - `LoadBalancer` 需要你的集群运行在某个公有云上，并有一种支持的 cloud LoadBalancer。 ```shell script - vela addon enable ingress-controller serviceType=LoadBalancer + vela addon enable ingress-nginx serviceType=LoadBalancer ``` - `NodePort` 类型需要你能够访问集群节点的 IP和端口 ```shell script - vela addon enable ingress-controller serviceType=NodePort + vela addon enable ingress-nginx serviceType=NodePort ``` ## 获取网关地址 @@ -29,19 +29,19 @@ vela addon enable ingress-controller 如果指定了服务类型是 `NodePort` 和 `LoadBalancer`，你可以通过下面的命令，获取到网关的地址： ```shell -vela status addon-ingress-controller -n vela-system --endpoint +vela status addon-ingress-nginx -n vela-system --endpoint ``` 如果是 `ClusterIP` 类型，又可以通过 `vela port-forward` 命令将网关的端口映射到本地： ```shell -vela port-forward -n vela-system addon-ingress-controller 9080:80 +vela port-forward -n vela-system addon-ingress-nginx 9080:80 ``` ## 卸载 ```shell -vela addon disable ingress-controller +vela addon disable ingress-nginx ``` ## 例子 @@ -76,6 +76,3 @@ EOF $ curl -H "Host: canary-demo.com" /version Demo: V1 ``` - - - diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/tutorials/helm.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/tutorials/helm.md index ebefc499..8659925a 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/tutorials/helm.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.8/tutorials/helm.md @@ -12,6 +12,7 @@ description: 本文介绍通过 KubeVela 交付 Helm Chart ## 开始之前 - 选择一个你希望交付的 Chart 包，本文我们以 [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis) 为例。 +- 如果你在使用 [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis)，看一下[这里](https://artifacthub.io/packages/helm/bitnami/redis)是否官方还在提供你使用的版本. - 确保你交付的集群具有可用的默认 StorageClass，我们交付中间件大多需要数据持久化，需要默认的 StorageClass 来分配 PV。 ## 启用 fluxcd 插件 @@ -47,7 +48,7 @@ vela addon enable fluxcd 参考上图，需要做如下配置： - Repo Type: 仓库类型，目前支持 Git 和 Helm，本例我们选择 Helm 类型。 -- Repo URL: 仓库地址，基于不同的仓库类型填写仓库地址，这里我们填写：https://charts.bitnami.com/bitnami。另外，如果你在 [配置集成](../how-to/dashboard/config/helm-repo) 里配置了 helm 仓库，这里可以直接在下拉框中进行选择。 +- Repo URL: 仓库地址，基于不同的仓库类型填写仓库地址，这里我们填写：[https://charts.bitnami.com/bitnami](https://charts.bitnami.com/bitnami)。另外，如果你在 [配置集成](../how-to/dashboard/config/helm-repo) 里配置了 helm 仓库，这里可以直接在下拉框中进行选择。 - Chart: 填写仓库地址之后，这里会自动列举出所有可用的 Helm chart，这里我们选择: redis - Version: 选择 chart 之后，这里的下拉框会展示出所有当前 chart 所有可用的版本，这里我们选择 16.8.5 - Values: 确定 chart 和版本之后，这里的下来框会展出当前 chart 的自定义配置参数，这里由于我们使用的是 ACK 集群，PV 有最小容量要求，这里填写 15Gi。同理，其他配置参数也可以通过该方式进行配置，你需要根据你的集群情况进行配置。 @@ -77,7 +78,7 @@ spec: repoType: "helm" url: "https://charts.bitnami.com/bitnami" chart: "redis" - version: "16.8.5" + version: "17.7.3" values: master: persistence: diff --git a/versioned_docs/version-v1.8/developers/references/devex/faq.md b/versioned_docs/version-v1.8/developers/references/devex/faq.md index dcef75fa..6f8608ad 100644 --- a/versioned_docs/version-v1.8/developers/references/devex/faq.md +++ b/versioned_docs/version-v1.8/developers/references/devex/faq.md @@ -24,9 +24,19 @@ KubeVela natively support Crossplane as they're already CRDs, while terraform wa ## Common Issues -### The document website is very slow to access. +### Why things of https://*.kubevela.net is out of date? -You can use https://kubevela.net/ as a faster alternative. +Recently, we're removing the dependency of the domain `kubevela.net` due to some compliance issues, so things are migrated. Please check the following lists to find the new address: + +Content | old | new +--- | --- | --- +Documentation | https://kubevela.net | https://kubevela.io +Image Hub | "hub.kubevela.net" | "docker.io" or "ghcr.io/kubevela" +Helm charts | https://charts.kubevela.net/core | https://kubevela.github.io/charts +Official Addon Registry | https://addons.kubevela.net | https://kubevela.github.io/catalog/official +Experimental Addon Registry | - | https://kubevela.github.io/catalog/experimental +CLI | https://kubevela.net/script/install.sh | download from [release page](https://github.com/kubevela/kubevela/releases) +VelaD | - | migrating ### You have reached rate limit for Docker Image Registry @@ -37,9 +47,7 @@ By default, the community use images from docker registry for installation. You * Before v1.4.1, the image format is `ghcr.io//vela-core:`, e.g. "ghcr.io/kubevela/kubevela/vela-core:latest". * After v1.4.1, the image format has changed to `ghcr.io/kubevela/`, e.g. "ghcr.io/kubevela/oamdev/vela-core:latest". -2. Alibaba Container Registry also sponsor KubeVela community, you can use `acr.kubevela.net/` as prefix for the docker registry, acr has a sync for each KubeVela official images. Use it like `acr.kubevela.net/oamdev/vela-core:latest`. - -3. If you insist on using Docker registry, you may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit . +2. If you insist on using Docker registry, you may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit . ### SchemaError of ApplicationRevision CRD diff --git a/versioned_docs/version-v1.8/end-user/traits/sidecar.md b/versioned_docs/version-v1.8/end-user/traits/sidecar.md index 5fc31c69..4c688f46 100644 --- a/versioned_docs/version-v1.8/end-user/traits/sidecar.md +++ b/versioned_docs/version-v1.8/end-user/traits/sidecar.md @@ -65,7 +65,7 @@ vela-app-with-sidecar log-gen-worker worker sidecar running heal And check the logging output of sidecar. ```shell -vela logs vela-app-with-sidecar -c count-log +vela logs vela-app-with-sidecar --container count-log ```
diff --git a/versioned_docs/version-v1.8/how-to/dashboard/trigger/overview.md b/versioned_docs/version-v1.8/how-to/dashboard/trigger/overview.md index 73703125..ffea19f7 100644 --- a/versioned_docs/version-v1.8/how-to/dashboard/trigger/overview.md +++ b/versioned_docs/version-v1.8/how-to/dashboard/trigger/overview.md @@ -72,6 +72,68 @@ After CI have executed this step, we can see that application is deployed succes You can refer to [Jenkins CI](../../../tutorials/jenkins) guide for a real use case about custom trigger. +Apart from this, Custom Triggers also supports some other type of actions, they are : + +#### Execute workflow + +Integrate Custom Triggers into your CI tool to execute a workflow. This action behaves the same as the default custom trigger with no action provided. The request body for executing a workflow using Custom Triggers is as follows: + +```json + { + "action":"execute" + // required, the upgrade of this deployment + "upgrade": { + // key is the name of application + "": { + // the fields that need to be patched + "image": "" + } + }, + // optional, the code info of this deployment + "codeInfo": { + "commit": "", + "branch": "", + "user": "", + } + } +``` + +#### Approve workflow + +During the `suspending` phase of a workflow step, the CI tool can approve the workflow by calling the Custom Trigger with the following request body: + +```json + { + "action":"approve", + // optional, name of the suspending step + "step":"suspend" + } +``` + +#### Terminate workflow + +If a workflow step is in the `suspending` phase, the CI tool can terminate the workflow by calling the Custom Trigger with the following request body: + +```json + { + "action":"terminate", + // optional, name of the suspending step + "step":"suspend" + } +``` + +#### Rollback workflow + +If a workflow step is in the `suspending` phase, the CI tool can initiate a rollback of an application workflow to the latest revision by calling the Custom Trigger with the following request body: + +```json + { + "action":"rollback", + // optional, name of the suspending step + "step":"suspend" + } +``` + ### Harbor Trigger Harbor Trigger can be integrated with Harbor image registry. diff --git a/versioned_docs/version-v1.8/installation/kubernetes.mdx b/versioned_docs/version-v1.8/installation/kubernetes.mdx index 1f6d491f..1ee5dbb5 100644 --- a/versioned_docs/version-v1.8/installation/kubernetes.mdx +++ b/versioned_docs/version-v1.8/installation/kubernetes.mdx @@ -176,7 +176,7 @@ helm v3.2.0+ required ::: ``` -helm repo add kubevela https://charts.kubevela.net/core +helm repo add kubevela https://kubevela.github.io/charts helm repo update helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait ``` diff --git a/versioned_docs/version-v1.8/platform-engineers/addon/intro.md b/versioned_docs/version-v1.8/platform-engineers/addon/intro.md index 52679cbb..c9984e8e 100644 --- a/versioned_docs/version-v1.8/platform-engineers/addon/intro.md +++ b/versioned_docs/version-v1.8/platform-engineers/addon/intro.md @@ -100,7 +100,7 @@ deployTo: dependencies: - name: addon_name - version: addon_version + version: ">= 1.0.0, < 2.0.0" system: vela: ">=v1.4.0" @@ -119,7 +119,9 @@ Here's the usage of every field: | icon | no | string | Icon of the addon, will display in addon dashboard. | | url | no | string | The official website of the project behind the addon. | | tags | no | []string | The tags to display and organize the addon. | -| dependencies | no | []{ name: string, version: string } | Infos of other addons it depends on. You can specify the version of dependency addon by defining the `version` filed, otherwise would use latest one. KubeVela will make sure these dependencies are enabled before installing this addon. | +| dependencies[] | no | array of objects | Addons which this addon depends upon. KubeVela will make sure these dependencies are enabled before installing this addon. | +| dependencies[].name | yes | string | Name of the addon dependency. | +| dependencies[].version | no | string | Required version constraints for the dependency. You can specify a range like ">= 1.0.0, < 2.0.0". KubeVela will select the latest version matching the constraints. If no constraint is given, KubeVela will select the latest version. | | system.vela | no | string | Required version of vela controller, vela CLI will block the installation if vela controller can't match the requirements. | | system.kubernetes | no | string | Required version of Kubernetes, vela CLI will block the installation if Kubernetes cluster can't match the requirements. | | deployTo.runtimeCluster | no | bool | By default, the addon will not be installed in the managed clusters. If it's `true`, it will be delivered to all managed clusters automatically. (This field only take effect when application template file is YAML typed) | diff --git a/versioned_docs/version-v1.8/reference/addons/velaux.md b/versioned_docs/version-v1.8/reference/addons/velaux.md index 254b3945..2197569a 100644 --- a/versioned_docs/version-v1.8/reference/addons/velaux.md +++ b/versioned_docs/version-v1.8/reference/addons/velaux.md @@ -26,9 +26,11 @@ By default, VelaUX didn't have any exposed port. Port forward will work as a proxy to allow visiting VelaUX dashboard by local port. -```bash -vela port-forward addon-velaux -n vela-system 8000:8000 ``` +vela port-forward addon-velaux -n vela-system +``` + +Choose `> local | velaux | velaux` for visit. ## Setup with Specified Service Type @@ -49,23 +51,23 @@ If you want to expose your VelaUX dashboard for convenience, you can specify the After the service type specified to `LoadBalancer` or `NodePort`, you can obtain the access address through `vela status`: -```bash +``` vela status addon-velaux -n vela-system --endpoint ``` The expected output: -```bash -+---------+---------------+-----------------------------------+--------------------------------+-------+ -| CLUSTER | COMPONENT | REF(KIND/NAMESPACE/NAME) | ENDPOINT | INNER | -+---------+---------------+-----------------------------------+--------------------------------+-------+ -| local | velaux-server | Service/vela-system/velaux-server | velaux-server.vela-system:8000 | true | -+---------+---------------+-----------------------------------+--------------------------------+-------+ +``` ++----------------------------+----------------------+ +| REF(KIND/NAMESPACE/NAME) | ENDPOINT | ++----------------------------+----------------------+ +| Service/vela-system/velaux | http:// | ++----------------------------+----------------------+ ``` ## Setup with Ingress domain -If you have ingress and domain available in your cluster, you can also deploy VelaUX by specifying a domain like below: +If you have ingress and domain available in your cluster, you can also deploy VelaUX by specify a domain like below: ```bash vela addon enable velaux domain=example.domain.com @@ -73,16 +75,16 @@ vela addon enable velaux domain=example.domain.com The expected output: -```bash +``` I0112 15:23:40.428364 34884 apply.go:106] "patching object" name="addon-velaux" resource="core.oam.dev/v1beta1, Kind=Application" I0112 15:23:40.676894 34884 apply.go:106] "patching object" name="addon-secret-velaux" resource="/v1, Kind=Secret" Addon: velaux enabled Successfully. Please access the velaux from the following endpoints: -+-----------------------------------+---------------------------+ -| REF(KIND/NAMESPACE/NAME) | ENDPOINT | -+-----------------------------------+---------------------------+ -| Ingress/vela-system/velaux-server | http://example.domain.com | -+-----------------------------------+---------------------------+ ++----------------------------+---------------------------+ +| REF(KIND/NAMESPACE/NAME) | ENDPOINT | ++----------------------------+---------------------------+ +| Ingress/vela-system/velaux | http://example.domain.com | ++----------------------------+---------------------------+ ``` If you enabled the traefik addon, you can set the `gatewayDriver` parameter to use the Gateway API. @@ -170,13 +172,13 @@ spec: type: deploy ``` -After deployment, let's get the root password from the secret `vela-system/velaux-db-mongodb`. +After deployed, let's get the root password from the secret `vela-system/velaux-db-mongodb`. ## Specify the addon image By default the image repo is docker hub, you can specify the image repo by the `repo` parameter: -```bash +``` vela addon enable velaux repo=acr.kubevela.net ``` diff --git a/versioned_docs/version-v1.8/tutorials/helm.md b/versioned_docs/version-v1.8/tutorials/helm.md index f2b3aba1..a1d97ff4 100644 --- a/versioned_docs/version-v1.8/tutorials/helm.md +++ b/versioned_docs/version-v1.8/tutorials/helm.md @@ -11,6 +11,7 @@ Starting from here, you will learn to use the KubeVela Addons to install plug-in ## Before starting - Choose a Helm Chart you want to deploy. In the tutorial, we take [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis) as an example. +- If you are using [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis), check if the chart version you specified is still listed [here](https://artifacthub.io/packages/helm/bitnami/redis) and available. - Ensure that the cluster you deliver has a usable default StorageClass. Most of our delivery middleware requires data persistence, and the default StorageClass is needed to allocate PV. - Make sure you have VelaUX addon enabled for UI console. If you are only CLI users, you can skip to [Deploy via CLI](#deploy-via-cli) ``` @@ -52,7 +53,7 @@ spec: repoType: "helm" url: "https://charts.bitnami.com/bitnami" chart: "redis" - version: "16.8.5" + version: "17.7.3" values: master: persistence: @@ -235,4 +236,4 @@ spec: Your fluxcd addon version must be `1.3.1+`. ::: -Now, you have learned the basic helm delivery. If you want to delivery Helm Chart into multi-clusters, you can refer to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster). \ No newline at end of file +Now, you have learned the basic helm delivery. If you want to delivery Helm Chart into multi-clusters, you can refer to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster). diff --git a/versioned_docs/version-v1.8/tutorials/sso.md b/versioned_docs/version-v1.8/tutorials/sso.md index bd6c31df..0f5231be 100644 --- a/versioned_docs/version-v1.8/tutorials/sso.md +++ b/versioned_docs/version-v1.8/tutorials/sso.md @@ -16,10 +16,13 @@ After the platform is initialized, local login is used by default. Platform admi ![alt](https://static.kubevela.net/images/1.3/dex-addon.png) +2. After enabling the Dex Addon, we also need to upgrade the VelaUX addon and open its Dex option: + +![alt](https://static.kubevela.net/images/1.5/enable-dex-in-velaux.png) + ## Configure Dex Connectors Next, we need to configure the Dex Connectors. - ### Configure GitHub Connector Take GitHub Connector as an example, if you don't have a GitHub Oauth App, you need to create an OAuth App on GitHub's Developer settings first, and set the App's Authorization callback URL to `[Vela UX address]/dex/callback`. diff --git a/versions.json b/versions.json index 22ff56b6..c9800ae3 100644 --- a/versions.json +++ b/versions.json @@ -2,4 +2,4 @@ "v1.8", "v1.7", "v1.6" -] \ No newline at end of file +]