Feat: add trigger how to docs (#422)
* Feat: add trigger how to Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com> * add env and generate 1.2 docs Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com> * fix title Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>
This commit is contained in:
Tianxin Dong
GitHub
parent
88efd55fbd
commit
4bccb5ba7c
|
|
@ -0,0 +1,97 @@
|
|||
---
|
||||
title: Integrate with CI system by Triggers
|
||||
description: Integrate with CI system by Triggers
|
||||
---
|
||||
|
||||
After you have created an application, a default trigger is automatically created. You can also delete or create a new trigger.
|
||||
|
||||
|
||||
|
||||
KubeVela triggers can integrate with any CI tool like Gitlab CI, Jenkins Pipeline or image registry like Harbor or ACR.
|
||||
|
||||
We now support three types of triggers: Custom, ACR, and Harbor.
|
||||
|
||||
## Custom Trigger
|
||||
|
||||
Custom triggers will provide a webhook URL, which you can use to integrate with your CI tool using the specified request body.
|
||||
|
||||
The default trigger is a custom trigger, click `Manual Trigger` to get more info of this trigger:
|
||||
|
||||
|
||||
|
||||
Webhook URL is the address of this trigger, you can see request body in `Curl Command` example:
|
||||
|
||||
```json
|
||||
{
|
||||
// required, the upgrade of this deployment
|
||||
"upgrade": {
|
||||
// key is the name of application
|
||||
"<application-name>": {
|
||||
// the fields that need to be patched
|
||||
"image": "<image-name>"
|
||||
}
|
||||
},
|
||||
// optional, the code info of this deployment
|
||||
"codeInfo": {
|
||||
"commit": "<commit-id>",
|
||||
"branch": "<branch>",
|
||||
"user": "<user>",
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`upgrade` is the key of the object that need to be patched, `<application-name>` is the name of application. `image` is the field that need to be patched. You can also add more fields in `<application-name>`.
|
||||
|
||||
In `codeInfo`, you can add some code infos of this deployment like commit id, branch or user.
|
||||
|
||||
Below is an example of using Custom Trigger in Gitlab CI, we use env in this example:
|
||||
|
||||
```shell
|
||||
webhook-request:
|
||||
stage: request
|
||||
before_script:
|
||||
- apk add --update curl && rm -rf /var/cache/apk/*
|
||||
script:
|
||||
- |
|
||||
curl -X POST -H "Content-Type: application/json" -d '{"upgrade":{"'"$ APP_NAME"'":{"image":"'"$BUILD_IMAGE"'"}},"codeInfo":{"user":"'"$CI_COMMIT_AUTHOR"'","commit":"'"$CI_COMMIT_SHA"'","branch":"'"$CI_COMMIT_BRANCH"'"}}' $WEBHOOK_URL
|
||||
```
|
||||
|
||||
After CI have executed this step, we can see that application is deployed successfully in VelaUX. We can also see some relative code infos of this deployment.
|
||||
|
||||
|
||||
|
||||
## Harbor Trigger
|
||||
|
||||
Harbor Trigger can be integrated with Harbor image registry.
|
||||
|
||||
We can start with creating a new harbor trigger. The Payload Type is Harbor, and the Execution Workflow is the workflow you want to deploy in the trigger.
|
||||
|
||||
|
||||
|
||||
After creating the trigger, we can setup this trigger in Harbor:
|
||||
|
||||
|
||||
|
||||
After configuring the trigger, we can see the new deploy revisions when a new image is pushed to the registry.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## ACR Trigger
|
||||
|
||||
ACR Trigger can be integrated with ACR image registry.
|
||||
|
||||
We can start with creating a new ACR trigger. The Payload Type is ACR, and the Execution Workflow is the workflow you want to deploy in the trigger.
|
||||
|
||||
|
||||
|
||||
After creating the trigger, we can setup this trigger in ACR:
|
||||
|
||||
|
||||
|
||||
After configuring the trigger, we can see the new deploy revisions when a new image is pushed to the registry.
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 209 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 133 KiB |
|
|
@ -0,0 +1,97 @@
|
|||
---
|
||||
title: 使用触发器对接 CI 自动部署
|
||||
description: 使用触发器对接 CI 自动部署
|
||||
---
|
||||
|
||||
应用在创建完成后，会自动创建一个默认触发器，你可以删除或者创建新的触发器。
|
||||
|
||||
|
||||
|
||||
KubeVela 触发器可以对接不同类型的 CI 系统，在 CI 系统中添加触发器以此实现应用的自动部署。比如从制品仓库的镜像更新触发，通过 Jenkins Pipeline 触发等。
|
||||
|
||||
目前可以创建三种不同类型的触发器：Custom、ACR、Harbor，我们将分别介绍。
|
||||
|
||||
## Custom 触发器
|
||||
|
||||
Custom 为自定义类型的触发器，它提供一个 Webhook URL 以及指定的请求体格式，你可以用它来对接任意 CI 系统。
|
||||
|
||||
默认触发器是一个 Custom 类型的触发器，点击 `Manual Trigger`，可以查看触发器的详细信息：
|
||||
|
||||
|
||||
|
||||
Webhook URL 是这个触发器的触发地址，在 `Curl Command` 里，还提供了手动 Curl 该触发器的请求示例。我们来详细解析一下请求体：
|
||||
|
||||
```json
|
||||
{
|
||||
// 必填，此次触发的更新信息
|
||||
"upgrade": {
|
||||
// Key 为应用的名称
|
||||
"<application-name>": {
|
||||
// 需要更新的值，这里的内容会被 Patch 更新到应用上
|
||||
"image": "<image-name>"
|
||||
}
|
||||
},
|
||||
// 可选，此次触发携带的代码信息
|
||||
"codeInfo": {
|
||||
"commit": "<commit-id>",
|
||||
"branch": "<branch>",
|
||||
"user": "<user>",
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`upgrade` 下是本次触发要携带的更新信息，在应用名下，是需要被 Patch 更新的值。默认推荐的是更新镜像 `image`，也可以扩展这里的字段来更新应用的其他属性。
|
||||
|
||||
`codeInfo` 中是代码信息，可以选择性地携带，比如提交 ID、分支、提交者等，一般这些值可以通过在 CI 系统中使用变量替换来指定。
|
||||
|
||||
下面是一个在 GitLab CI 中使用触发器的例子，里面所有的值都使用了变量替换：
|
||||
|
||||
```shell
|
||||
webhook-request:
|
||||
stage: request
|
||||
before_script:
|
||||
- apk add --update curl && rm -rf /var/cache/apk/*
|
||||
script:
|
||||
- |
|
||||
curl -X POST -H "Content-Type: application/json" -d '{"upgrade":{"'"$ APP_NAME"'":{"image":"'"$BUILD_IMAGE"'"}},"codeInfo":{"user":"'"$CI_COMMIT_AUTHOR"'","commit":"'"$CI_COMMIT_SHA"'","branch":"'"$CI_COMMIT_BRANCH"'"}}' $WEBHOOK_URL
|
||||
```
|
||||
|
||||
配置完成后，当 CI 中执行了该步骤，则能在 VelaUX 中看到应用已被成功部署，且能看到本次部署相关的代码信息。
|
||||
|
||||
|
||||
|
||||
## Harbor 触发器
|
||||
|
||||
Harbor 触发器可以对接 Harbor 镜像仓库。
|
||||
|
||||
首先来创建一个 Harbor 触发器，Payload Type 选择 Harbor，Execution Workflow 选择触发器需要触发的工作流：
|
||||
|
||||
|
||||
|
||||
新建完毕后，在 Harbor 中配置该触发器：
|
||||
|
||||
|
||||
|
||||
配置完成后，当 Harbor 中被推送了新镜像时，VelaUX 中会收到对应的触发请求，从而完成自动部署。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## ACR 触发器
|
||||
|
||||
ACR 触发器可以对接 ACR 镜像仓库。
|
||||
|
||||
首先来创建一个 ACR 触发器，Payload Type 选择 ACR，Execution Workflow 选择触发器需要触发的工作流：
|
||||
|
||||
|
||||
|
||||
新建完毕后，在 ACR 中配置该触发器：
|
||||
|
||||
|
||||
|
||||
配置完成后，当 ACR 中被推送了新镜像时，VelaUX 中会收到对应的触发请求，从而完成自动部署。
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 209 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 133 KiB |
|
|
@ -8,7 +8,8 @@ title: 创建和使用云资源
|
|||
KubeVela 通过云资源组件（Component）和运维特征（Trait）里的资源绑定功能，高效安全地完成不同类型云资源的集成工作。目前你可以直接调用下面这些云资源默认组件。
|
||||
同时在未来，更多新的云资源也会在社区的支撑下逐渐成为默认选项，让你标准化统一地去使用各种厂商的云资源。
|
||||
|
||||
> ⚠️ 请确认管理员已经安装了 [Terraform 插件 'terraform/provider-alicloud'](../../../install#4-【可选】安装插件)。
|
||||
> ⚠️ 请确认管理员已经安装了 [Terraform 插件 'terraform/provider-alicloud'](../../../install#4-【可选】安装插件).
|
||||
|
||||
|
||||
## 支持的云资源列表
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,97 @@
|
|||
---
|
||||
title: 使用触发器对接 CI 自动部署
|
||||
description: 使用触发器对接 CI 自动部署
|
||||
---
|
||||
|
||||
应用在创建完成后，会自动创建一个默认触发器，你可以删除或者创建新的触发器。
|
||||
|
||||
|
||||
|
||||
KubeVela 触发器可以对接不同类型的 CI 系统，在 CI 系统中添加触发器以此实现应用的自动部署。比如从制品仓库的镜像更新触发，通过 Jenkins Pipeline 触发等。
|
||||
|
||||
目前可以创建三种不同类型的触发器：Custom、ACR、Harbor，我们将分别介绍。
|
||||
|
||||
## Custom 触发器
|
||||
|
||||
Custom 为自定义类型的触发器，它提供一个 Webhook URL 以及指定的请求体格式，你可以用它来对接任意 CI 系统。
|
||||
|
||||
默认触发器是一个 Custom 类型的触发器，点击 `Manual Trigger`，可以查看触发器的详细信息：
|
||||
|
||||
|
||||
|
||||
Webhook URL 是这个触发器的触发地址，在 `Curl Command` 里，还提供了手动 Curl 该触发器的请求示例。我们来详细解析一下请求体：
|
||||
|
||||
```json
|
||||
{
|
||||
// 必填，此次触发的更新信息
|
||||
"upgrade": {
|
||||
// Key 为应用的名称
|
||||
"<application-name>": {
|
||||
// 需要更新的值，这里的内容会被 Patch 更新到应用上
|
||||
"image": "<image-name>"
|
||||
}
|
||||
},
|
||||
// 可选，此次触发携带的代码信息
|
||||
"codeInfo": {
|
||||
"commit": "<commit-id>",
|
||||
"branch": "<branch>",
|
||||
"user": "<user>",
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`upgrade` 下是本次触发要携带的更新信息，在应用名下，是需要被 Patch 更新的值。默认推荐的是更新镜像 `image`，也可以扩展这里的字段来更新应用的其他属性。
|
||||
|
||||
`codeInfo` 中是代码信息，可以选择性地携带，比如提交 ID、分支、提交者等，一般这些值可以通过在 CI 系统中使用变量替换来指定。
|
||||
|
||||
下面是一个在 GitLab CI 中使用触发器的例子，里面所有的值都使用了变量替换：
|
||||
|
||||
```shell
|
||||
webhook-request:
|
||||
stage: request
|
||||
before_script:
|
||||
- apk add --update curl && rm -rf /var/cache/apk/*
|
||||
script:
|
||||
- |
|
||||
curl -X POST -H "Content-Type: application/json" -d '{"upgrade":{"'"$ APP_NAME"'":{"image":"'"$BUILD_IMAGE"'"}},"codeInfo":{"user":"'"$CI_COMMIT_AUTHOR"'","commit":"'"$CI_COMMIT_SHA"'","branch":"'"$CI_COMMIT_BRANCH"'"}}' $WEBHOOK_URL
|
||||
```
|
||||
|
||||
配置完成后，当 CI 中执行了该步骤，则能在 VelaUX 中看到应用已被成功部署，且能看到本次部署相关的代码信息。
|
||||
|
||||
|
||||
|
||||
## Harbor 触发器
|
||||
|
||||
Harbor 触发器可以对接 Harbor 镜像仓库。
|
||||
|
||||
首先来创建一个 Harbor 触发器，Payload Type 选择 Harbor，Execution Workflow 选择触发器需要触发的工作流：
|
||||
|
||||
|
||||
|
||||
新建完毕后，在 Harbor 中配置该触发器：
|
||||
|
||||
|
||||
|
||||
配置完成后，当 Harbor 中被推送了新镜像时，VelaUX 中会收到对应的触发请求，从而完成自动部署。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## ACR 触发器
|
||||
|
||||
ACR 触发器可以对接 ACR 镜像仓库。
|
||||
|
||||
首先来创建一个 ACR 触发器，Payload Type 选择 ACR，Execution Workflow 选择触发器需要触发的工作流：
|
||||
|
||||
|
||||
|
||||
新建完毕后，在 ACR 中配置该触发器：
|
||||
|
||||
|
||||
|
||||
配置完成后，当 ACR 中被推送了新镜像时，VelaUX 中会收到对应的触发请求，从而完成自动部署。
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 209 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 133 KiB |
|
|
@ -0,0 +1,97 @@
|
|||
---
|
||||
title: Integrate with CI system by Triggers
|
||||
description: Integrate with CI system by Triggers
|
||||
---
|
||||
|
||||
After you have created an application, a default trigger is automatically created. You can also delete or create a new trigger.
|
||||
|
||||
|
||||
|
||||
KubeVela triggers can integrate with any CI tool like Gitlab CI, Jenkins Pipeline or image registry like Harbor or ACR.
|
||||
|
||||
We now support three types of triggers: Custom, ACR, and Harbor.
|
||||
|
||||
## Custom Trigger
|
||||
|
||||
Custom triggers will provide a webhook URL, which you can use to integrate with your CI tool using the specified request body.
|
||||
|
||||
The default trigger is a custom trigger, click `Manual Trigger` to get more info of this trigger:
|
||||
|
||||
|
||||
|
||||
Webhook URL is the address of this trigger, you can see request body in `Curl Command` example:
|
||||
|
||||
```json
|
||||
{
|
||||
// required, the upgrade of this deployment
|
||||
"upgrade": {
|
||||
// key is the name of application
|
||||
"<application-name>": {
|
||||
// the fields that need to be patched
|
||||
"image": "<image-name>"
|
||||
}
|
||||
},
|
||||
// optional, the code info of this deployment
|
||||
"codeInfo": {
|
||||
"commit": "<commit-id>",
|
||||
"branch": "<branch>",
|
||||
"user": "<user>",
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`upgrade` is the key of the object that need to be patched, `<application-name>` is the name of application. `image` is the field that need to be patched. You can also add more fields in `<application-name>`.
|
||||
|
||||
In `codeInfo`, you can add some code infos of this deployment like commit id, branch or user.
|
||||
|
||||
Below is an example of using Custom Trigger in Gitlab CI, we use env in this example:
|
||||
|
||||
```shell
|
||||
webhook-request:
|
||||
stage: request
|
||||
before_script:
|
||||
- apk add --update curl && rm -rf /var/cache/apk/*
|
||||
script:
|
||||
- |
|
||||
curl -X POST -H "Content-Type: application/json" -d '{"upgrade":{"'"$ APP_NAME"'":{"image":"'"$BUILD_IMAGE"'"}},"codeInfo":{"user":"'"$CI_COMMIT_AUTHOR"'","commit":"'"$CI_COMMIT_SHA"'","branch":"'"$CI_COMMIT_BRANCH"'"}}' $WEBHOOK_URL
|
||||
```
|
||||
|
||||
After CI have executed this step, we can see that application is deployed successfully in VelaUX. We can also see some relative code infos of this deployment.
|
||||
|
||||
|
||||
|
||||
## Harbor Trigger
|
||||
|
||||
Harbor Trigger can be integrated with Harbor image registry.
|
||||
|
||||
We can start with creating a new harbor trigger. The Payload Type is Harbor, and the Execution Workflow is the workflow you want to deploy in the trigger.
|
||||
|
||||
|
||||
|
||||
After creating the trigger, we can setup this trigger in Harbor:
|
||||
|
||||
|
||||
|
||||
After configuring the trigger, we can see the new deploy revisions when a new image is pushed to the registry.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## ACR Trigger
|
||||
|
||||
ACR Trigger can be integrated with ACR image registry.
|
||||
|
||||
We can start with creating a new ACR trigger. The Payload Type is ACR, and the Execution Workflow is the workflow you want to deploy in the trigger.
|
||||
|
||||
|
||||
|
||||
After creating the trigger, we can setup this trigger in ACR:
|
||||
|
||||
|
||||
|
||||
After configuring the trigger, we can see the new deploy revisions when a new image is pushed to the registry.
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 209 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 133 KiB |
|
|
@ -353,24 +353,44 @@
|
|||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-eip"
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-ask"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-rds"
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-eip"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-oss"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-rds"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-redis"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-sls-project"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-sls-store"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-vpc"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/alibaba-vswitch"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/aws-s3"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/azure-database-mariadb"
|
||||
|
|
@ -378,10 +398,6 @@
|
|||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/azure-storage-account"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.2/end-user/components/cloud-services/terraform/aws-s3"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
|
|||
Loading…
Reference in New Issue