Fix: change ACR to Harbor (#451)
* Fix: change ACR to Harbor Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com> * generate 1.2 files and update the hack script Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>
This commit is contained in:
Tianxin Dong
GitHub
parent
4c2475a49c
commit
0e4ff4f8e8
Binary file not shown.
|
After Width: | Height: | Size: 229 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 101 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
|
|
@ -8,7 +8,7 @@ In our daily development, when image tags changed, it is more convenient for CI/
|
|||
|
||||
In KubeVela 1.2, [VelaUX](../install#3-install-velaux) provides a good way to do this. We can use KubeVela triggers to apply applications automatically.
|
||||
|
||||
In this section, we will use GitLab as code repository and ACR as image repository to integrate with KubeVela triggers, as a result, it will automatically update application when image tags changed.
|
||||
In this section, we will use GitLab as code repository and Harbor as image repository to integrate with KubeVela triggers, as a result, it will automatically update application when image tags changed.
|
||||
|
||||
## Create Application
|
||||
|
||||
|
|
@ -18,19 +18,19 @@ To use triggers, we need to create a new application on VelaUX first. We can cre
|
|||
|
||||
## Create Triggers for Application
|
||||
|
||||
After creating the application, use `New Trigger` to create a trigger. Here we use `ACR` as payload type to support requests from the `ACR` image registry.
|
||||
After creating the application, use `New Trigger` to create a trigger. Here we use `Harbor` as payload type to support requests from the `Harbor` image registry.
|
||||
|
||||
|
||||
|
||||
|
||||
Check the details of the trigger, you can see the specific Webhook URL and the manual trigger command.
|
||||
|
||||
|
||||
|
||||
## Setup ACR Trigger
|
||||
## Setup Harbor Trigger
|
||||
|
||||
ACR payload triggers need to cooperate with Ali Cloud ACR image registry. After creating a trigger of type ACR, we can copy the Webhook URL of the trigger and configure it in the ACR image registry.
|
||||
Harbor payload triggers need to cooperate with Harbor image registry. After creating a trigger of type Harbor, we can copy the Webhook URL of the trigger and configure it in the Harbor image registry.
|
||||
|
||||
|
||||
|
||||
|
||||
## Test and Apply
|
||||
|
||||
|
|
@ -58,13 +58,13 @@ data(){
|
|||
|
||||
After changing the code, the GitLab CI will automatically build the image and push it to the image registry.
|
||||
|
||||
In the access log of the ACR trigger, we can see that ACR sends a request to our Webhook URL when the latest image is pushed to the image registry.
|
||||
In the access log of the Harbor trigger, we can see that Harbor sends a request to our Webhook URL when the latest image is pushed to the image registry.
|
||||
|
||||
|
||||
|
||||
|
||||
Check the application revisions in VelaUX, you can see that the most recent revision was from `Webhook`.
|
||||
|
||||
|
||||
|
||||
|
||||
Looking back at the app page, you can see that the app version has changed to `v2.0.0` and the background of the page has changed with the version.
|
||||
|
||||
|
|
@ -73,6 +73,6 @@ Looking back at the app page, you can see that the app version has changed to `v
|
|||
|
||||
## Summary
|
||||
|
||||
The KubeVela triggers' combination with the image registry is smooth and seamless. In addition to ACR, KubeVela also supports Harbor and custom trigger payload types.
|
||||
The KubeVela triggers' combination with the image registry is smooth and seamless. In addition to Harbor, KubeVela also supports ACR registry and custom trigger payload types.
|
||||
|
||||
With KubeVela triggers, we can easily apply application based on image tags automatically and complete iterations of application versions.
|
||||
|
|
|
|||
|
|
@ -41,14 +41,13 @@ rm -rf versions.json.bak
|
|||
success "update versions.json"
|
||||
|
||||
# 4 update docusaurus.config.js
|
||||
sed -i.bak "s#lastVersion: '${version}'#lastVersion: 'current'#g" docusaurus.config.js
|
||||
rm -rf docusaurus.config.js.bak
|
||||
sed -i.bak "/${version}/d" docusaurus.config.js
|
||||
success "update docusaurus.config.js"
|
||||
|
||||
# 5 generate versioned docs
|
||||
yarn run docusaurus docs:version "${version}"
|
||||
sed -i.bak "s#lastVersion: 'current'#lastVersion: '${version}'#g" docusaurus.config.js
|
||||
rm -rf docusaurus.config.js.bak
|
||||
rm -rf docusaurus.config.js
|
||||
mv docusaurus.config.js.bak docusaurus.config.js
|
||||
success "generate versioned docs"
|
||||
|
||||
# 6 update i18n docs
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 229 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 101 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
|
|
@ -8,7 +8,7 @@ title: 在持续交付中集成镜像仓库
|
|||
|
||||
在 KubeVela 1.2 版本中，[VelaUX](../install#3-安装-velaux) 自带的应用触发器提供了一个很好的入口。我们可以使用这个触发器，来帮助我们完成这些自动部署的工作。
|
||||
|
||||
本文将详细介绍如何使用 KubeVela 触发器来完成基于镜像版本的自动化部署，在本文的例子当中，我们将使用 GitLab 作为代码仓库，ACR 作为镜像仓库来完成演示。
|
||||
本文将详细介绍如何使用 KubeVela 触发器来完成基于镜像版本的自动化部署，在本文的例子当中，我们将使用 GitLab 作为代码仓库，Harbor 作为镜像仓库来完成演示。
|
||||
|
||||
## 创建应用
|
||||
|
||||
|
|
@ -18,19 +18,19 @@ title: 在持续交付中集成镜像仓库
|
|||
|
||||
## 为应用新建触发器
|
||||
|
||||
在新建完应用后，使用 `New Trigger` 来创建新的触发器，这里我们选择 `ACR` 格式的触发器，使该触发器支持来自 `ACR` 镜像仓库的请求。
|
||||
在新建完应用后，使用 `New Trigger` 来创建新的触发器，这里我们选择 `Harbor` 格式的触发器，使该触发器支持来自 `Harbor` 镜像仓库的请求。
|
||||
|
||||
|
||||
|
||||
|
||||
查看这个触发器的详细信息，可以看到具体的 Webhook URL 以及手动触发的命令。
|
||||
|
||||
|
||||
|
||||
## 配置 ACR 触发器
|
||||
## 配置 Harbor 触发器
|
||||
|
||||
ACR 格式触发器需要配合阿里云 ACR 镜像仓库使用。当创建完 ACR 类型的触发器后，我们可以复制该触发器的 Webhook URL，并在 ACR 镜像仓库中进行配置。
|
||||
Harbor 格式触发器需要配合 Harbor 镜像仓库使用。当创建完 Harbor 类型的触发器后，我们可以复制该触发器的 Webhook URL，并在 Harbor 镜像仓库中进行配置。
|
||||
|
||||
|
||||
|
||||
|
||||
## 测试部署
|
||||
|
||||
|
|
@ -58,13 +58,13 @@ data(){
|
|||
|
||||
修改完成后，GitLab CI 将自动构建并推送最新镜像。
|
||||
|
||||
在 ACR 触发器的访问记录中，我们可以看到，当镜像仓库中有了最新镜像时，ACR 会往我们配置的 Webhook URL 中发送一个请求。
|
||||
在 Harbor 触发器的访问记录中，我们可以看到，当镜像仓库中有了最新镜像时，Harbor 会往我们配置的 Webhook URL 中发送一个请求。
|
||||
|
||||
|
||||
|
||||
|
||||
查看 VelaUX 的应用部署版本列表，可以看到，最近一次部署是来自 `webhook` 的部署。
|
||||
|
||||
|
||||
|
||||
|
||||
重新查看应用页面，可以看到，应用的版本已经变更成了 `v2.0.0`，同时页面的背景也随版本发生了变化。
|
||||
|
||||
|
|
@ -72,6 +72,6 @@ data(){
|
|||
|
||||
## 总结
|
||||
|
||||
KubeVela 触发器与制品仓库的对接是十分顺滑且无缝的，除了 ACR 之外，KubeVela 还支持 Harbor 以及自定义触发的格式。
|
||||
KubeVela 触发器与制品仓库的对接是十分顺滑且无缝的，除了 Harbor 之外，KubeVela 还支持 ACR 镜像仓库以及自定义触发的格式。
|
||||
|
||||
通过使用 KubeVela 触发器，我们可以轻松地根据镜像版本实现自动部署，从而完成应用版本的迭代。
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 229 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 101 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
|
|
@ -8,7 +8,7 @@ title: 在持续交付中集成镜像仓库
|
|||
|
||||
在 KubeVela 1.2 版本中，[VelaUX](../install#3-安装-velaux) 自带的应用触发器提供了一个很好的入口。我们可以使用这个触发器，来帮助我们完成这些自动部署的工作。
|
||||
|
||||
本文将详细介绍如何使用 KubeVela 触发器来完成基于镜像版本的自动化部署，在本文的例子当中，我们将使用 GitLab 作为代码仓库，ACR 作为镜像仓库来完成演示。
|
||||
本文将详细介绍如何使用 KubeVela 触发器来完成基于镜像版本的自动化部署，在本文的例子当中，我们将使用 GitLab 作为代码仓库，Harbor 作为镜像仓库来完成演示。
|
||||
|
||||
## 创建应用
|
||||
|
||||
|
|
@ -18,19 +18,19 @@ title: 在持续交付中集成镜像仓库
|
|||
|
||||
## 为应用新建触发器
|
||||
|
||||
在新建完应用后，使用 `New Trigger` 来创建新的触发器，这里我们选择 `ACR` 格式的触发器，使该触发器支持来自 `ACR` 镜像仓库的请求。
|
||||
在新建完应用后，使用 `New Trigger` 来创建新的触发器，这里我们选择 `Harbor` 格式的触发器，使该触发器支持来自 `Harbor` 镜像仓库的请求。
|
||||
|
||||
|
||||
|
||||
|
||||
查看这个触发器的详细信息，可以看到具体的 Webhook URL 以及手动触发的命令。
|
||||
|
||||
|
||||
|
||||
## 配置 ACR 触发器
|
||||
## 配置 Harbor 触发器
|
||||
|
||||
ACR 格式触发器需要配合阿里云 ACR 镜像仓库使用。当创建完 ACR 类型的触发器后，我们可以复制该触发器的 Webhook URL，并在 ACR 镜像仓库中进行配置。
|
||||
Harbor 格式触发器需要配合 Harbor 镜像仓库使用。当创建完 Harbor 类型的触发器后，我们可以复制该触发器的 Webhook URL，并在 Harbor 镜像仓库中进行配置。
|
||||
|
||||
|
||||
|
||||
|
||||
## 测试部署
|
||||
|
||||
|
|
@ -58,13 +58,13 @@ data(){
|
|||
|
||||
修改完成后，GitLab CI 将自动构建并推送最新镜像。
|
||||
|
||||
在 ACR 触发器的访问记录中，我们可以看到，当镜像仓库中有了最新镜像时，ACR 会往我们配置的 Webhook URL 中发送一个请求。
|
||||
在 Harbor 触发器的访问记录中，我们可以看到，当镜像仓库中有了最新镜像时，Harbor 会往我们配置的 Webhook URL 中发送一个请求。
|
||||
|
||||
|
||||
|
||||
|
||||
查看 VelaUX 的应用部署版本列表，可以看到，最近一次部署是来自 `webhook` 的部署。
|
||||
|
||||
|
||||
|
||||
|
||||
重新查看应用页面，可以看到，应用的版本已经变更成了 `v2.0.0`，同时页面的背景也随版本发生了变化。
|
||||
|
||||
|
|
@ -72,6 +72,6 @@ data(){
|
|||
|
||||
## 总结
|
||||
|
||||
KubeVela 触发器与制品仓库的对接是十分顺滑且无缝的，除了 ACR 之外，KubeVela 还支持 Harbor 以及自定义触发的格式。
|
||||
KubeVela 触发器与制品仓库的对接是十分顺滑且无缝的，除了 Harbor 之外，KubeVela 还支持 ACR 镜像仓库以及自定义触发的格式。
|
||||
|
||||
通过使用 KubeVela 触发器，我们可以轻松地根据镜像版本实现自动部署，从而完成应用版本的迭代。
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Terraform | Alibaba Cloud | [ACK](./terraform/alibaba-ack) | Terraform configura
|
|||
| | | [Redis](./terraform/alibaba-redis) | Terraform configuration for Alibaba Cloud Redis
|
||||
| | | [VPC](./terraform/alibaba-vpc) | Terraform configuration for Alibaba Cloud VPC
|
||||
| | Azure | [Mariadb](./terraform/azure-database-mariadb) | Terraform configuration for Azure Database Mariadb
|
||||
| | Azure | [Storage Account](./terraform/azure-storage-account) | Terraform configuration for Azure Storage Account
|
||||
| | | [Storage Account](./terraform/azure-storage-account) | Terraform configuration for Azure Storage Account
|
||||
| | AWS | [S3](./terraform/aws-s3) | Terraform configuration for AWS S3 bucket
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 229 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 101 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
|
|
@ -60,7 +60,7 @@ Alibaba Cloud | [ACK](../end-user/components/cloud-services/terraform/alibaba-a
|
|||
First [create an application](../how-to/dashboard/application/create-application). Please choose the type of your cloud service,
|
||||
which has a prefix of `aws-`, `azure` or `alibaba-`.
|
||||
|
||||
For different vendors, these parameters update accordingly.
|
||||
For different vendors, these parameters update accordingly.
|
||||
|
||||
For example, `aws-s3` has the following parameters:
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
|
|
@ -8,7 +8,7 @@ In our daily development, when image tags changed, it is more convenient for CI/
|
|||
|
||||
In KubeVela 1.2, [VelaUX](../install#3-install-velaux) provides a good way to do this. We can use KubeVela triggers to apply applications automatically.
|
||||
|
||||
In this section, we will use GitLab as code repository and ACR as image repository to integrate with KubeVela triggers, as a result, it will automatically update application when image tags changed.
|
||||
In this section, we will use GitLab as code repository and Harbor as image repository to integrate with KubeVela triggers, as a result, it will automatically update application when image tags changed.
|
||||
|
||||
## Create Application
|
||||
|
||||
|
|
@ -18,19 +18,19 @@ To use triggers, we need to create a new application on VelaUX first. We can cre
|
|||
|
||||
## Create Triggers for Application
|
||||
|
||||
After creating the application, use `New Trigger` to create a trigger. Here we use `ACR` as payload type to support requests from the `ACR` image registry.
|
||||
After creating the application, use `New Trigger` to create a trigger. Here we use `Harbor` as payload type to support requests from the `Harbor` image registry.
|
||||
|
||||
|
||||
|
||||
|
||||
Check the details of the trigger, you can see the specific Webhook URL and the manual trigger command.
|
||||
|
||||
|
||||
|
||||
## Setup ACR Trigger
|
||||
## Setup Harbor Trigger
|
||||
|
||||
ACR payload triggers need to cooperate with Ali Cloud ACR image registry. After creating a trigger of type ACR, we can copy the Webhook URL of the trigger and configure it in the ACR image registry.
|
||||
Harbor payload triggers need to cooperate with Harbor image registry. After creating a trigger of type Harbor, we can copy the Webhook URL of the trigger and configure it in the Harbor image registry.
|
||||
|
||||
|
||||
|
||||
|
||||
## Test and Apply
|
||||
|
||||
|
|
@ -58,13 +58,13 @@ data(){
|
|||
|
||||
After changing the code, the GitLab CI will automatically build the image and push it to the image registry.
|
||||
|
||||
In the access log of the ACR trigger, we can see that ACR sends a request to our Webhook URL when the latest image is pushed to the image registry.
|
||||
In the access log of the Harbor trigger, we can see that Harbor sends a request to our Webhook URL when the latest image is pushed to the image registry.
|
||||
|
||||
|
||||
|
||||
|
||||
Check the application revisions in VelaUX, you can see that the most recent revision was from `Webhook`.
|
||||
|
||||
|
||||
|
||||
|
||||
Looking back at the app page, you can see that the app version has changed to `v2.0.0` and the background of the page has changed with the version.
|
||||
|
||||
|
|
@ -73,6 +73,6 @@ Looking back at the app page, you can see that the app version has changed to `v
|
|||
|
||||
## Summary
|
||||
|
||||
The KubeVela triggers' combination with the image registry is smooth and seamless. In addition to ACR, KubeVela also supports Harbor and custom trigger payload types.
|
||||
The KubeVela triggers' combination with the image registry is smooth and seamless. In addition to Harbor, KubeVela also supports ACR registry and custom trigger payload types.
|
||||
|
||||
With KubeVela triggers, we can easily apply application based on image tags automatically and complete iterations of application versions.
|
||||
|
|
|
|||
Loading…
Reference in New Issue