Feat: add s2i doc (#1124)
Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com> Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>
This commit is contained in:
Tianxin Dong
GitHub
parent
6b6b74f4dc
commit
d6f511ddca
|
|
@ -1,27 +1,27 @@
|
|||
---
|
||||
title: Triggers
|
||||
title: Integrate with CI system
|
||||
description: Integrate with CI system by Triggers
|
||||
---
|
||||
|
||||
You can use triggers from [VelaUX addon](../../../reference/addons/velaux) to integrate with different CI systems, the architecture and supported platforms are described in the following picture, they're:
|
||||
In KubeVela, you can choose to directly use declarative workflow with CI steps, such as: build code, push image, etc. Alternatively, you can choose to use triggers to integrate with external CI systems, such as Jenkins, image registry, etc.
|
||||
|
||||
- [Custom](#custom-trigger), refer to [Jenkins CI](../../../tutorials/jenkins) guide for a real world use case
|
||||
## Use declarative workflow with CI steps
|
||||
|
||||
KubeVela v1.7+ provide built-in step for image building, please refer to [Integration with image build & push](../../../tutorials/s2i) for details.
|
||||
|
||||
## Use triggers to integrated with CI system.
|
||||
|
||||
You can use triggers from [VelaUX addon](../../../reference/addons/velaux) to integrate with different CI systems. In VelaUX, a default trigger will be automatically generated after an application created, you can also delete it and create a new one. The architecture and supported platforms are described in the following picture, they're:
|
||||
|
||||
- [Custom](#custom-trigger), refer to [Jenkins CI](../../../tutorials/jenkins) guide for a real world use case.
|
||||
- [ACR](#ACR-trigger)
|
||||
- [Harbor](#Harbor-trigger), refer to [Harbor Integration](../../../tutorials/trigger) guide for a real world use case
|
||||
- [Harbor](#Harbor-trigger), refer to [Harbor Integration](../../../tutorials/trigger) guide for a real world use case.
|
||||
- [DockerHub](#DockerHub-trigger)
|
||||
- [JFrog](#JFrog-trigger)
|
||||
|
||||
|
||||
|
||||
## How to use
|
||||
|
||||
A default trigger will be automatically generated after an application created. You can also delete it and create a new one.
|
||||
|
||||
|
||||
|
||||
KubeVela triggers can integrate with any CI tool like Gitlab CI, Jenkins Pipeline or image registry like Harbor or ACR.
|
||||
|
||||
## Custom Trigger
|
||||
### Custom Trigger
|
||||
|
||||
Custom triggers will provide a webhook URL, which you can use to integrate with your CI tool using the specified request body.
|
||||
|
||||
|
|
@ -72,13 +72,13 @@ 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.
|
||||
|
||||
## Harbor Trigger
|
||||
### Harbor Trigger
|
||||
|
||||
Harbor Trigger can be integrated with Harbor image registry.
|
||||
|
||||
You can refer to [Harbor Image Registry](../../../tutorials/trigger) guide for the end to end tutorial.
|
||||
|
||||
## ACR Trigger
|
||||
### ACR Trigger
|
||||
|
||||
ACR Trigger can be integrated with ACR image registry.
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ After configuring the trigger, we can see the new deploy revisions when a new im
|
|||
|
||||
|
||||
|
||||
## DockerHub Trigger
|
||||
### DockerHub Trigger
|
||||
|
||||
DockerHub Trigger can be integrated with DockerHub.
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ After configuring the trigger, we can see the new deploy revisions when a new im
|
|||
|
||||
|
||||
|
||||
## JFrog Trigger
|
||||
### JFrog Trigger
|
||||
|
||||
jFrog Trigger can be integrated with JFrog Artifactory.
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 261 KiB |
|
|
@ -0,0 +1,155 @@
|
|||
---
|
||||
title: Integration with image build & push
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
From code to application, one of the indispensable step is to build image. This section will introduce how to orchestrate image build, image push and application delivery in KubeVela.
|
||||
|
||||
## How to use
|
||||
|
||||
### Use standalone workflow
|
||||
|
||||
KubeVela introduced [standalone workflow](../end-user/pipeline/workflowrun) in version v1.6 that can be used **independently**, which can be used to orchestrate the process between CI steps and application delivery. Different from the workflow in the KubeVela application, it is **one-time** and does not manage resources. Even if the workflow is deleted, the created resources will not be deleted.
|
||||
|
||||
:::tip
|
||||
Please make sure that you have enabled workflow addon with `vela addon enable vela-workflow`.
|
||||
:::
|
||||
|
||||
Apply the following workflow:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: build-push-image
|
||||
namespace: default
|
||||
spec:
|
||||
context:
|
||||
image: my-registry/test-image:v2
|
||||
workflowSpec:
|
||||
steps:
|
||||
# or use kubectl create secret generic git-token --from-literal='GIT_TOKEN=<your-token>'
|
||||
- name: create-git-secret
|
||||
type: export2secret
|
||||
properties:
|
||||
secretName: git-secret
|
||||
data:
|
||||
token: <git token>
|
||||
# or use kubectl create secret docker-registry docker-regcred \
|
||||
# --docker-server=https://index.docker.io/v1/ \
|
||||
# --docker-username=<your-username> \
|
||||
# --docker-password=<your-password>
|
||||
- name: create-image-secret
|
||||
type: export2secret
|
||||
properties:
|
||||
secretName: image-secret
|
||||
kind: docker-registry
|
||||
dockerRegistry:
|
||||
username: <username>
|
||||
password: <password>
|
||||
- name: build-push
|
||||
type: build-push-image
|
||||
inputs:
|
||||
- from: context.image
|
||||
parameterKey: image
|
||||
properties:
|
||||
# use your kaniko executor image like below, if not set, it will use default image oamdev/kaniko-executor:v1.9.1
|
||||
# kanikoExecutor: gcr.io/kaniko-project/executor:latest
|
||||
# you can use context with git and branch or directly specify the context, please refer to https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts
|
||||
context:
|
||||
git: github.com/FogDong/simple-web-demo
|
||||
branch: main
|
||||
# Note that this field will be replaced by the image in inputs
|
||||
image: my-registry/test-image:v1
|
||||
# specify your dockerfile, if not set, it will use default dockerfile ./Dockerfile
|
||||
# dockerfile: ./Dockerfile
|
||||
credentials:
|
||||
image:
|
||||
name: image-secret
|
||||
# buildArgs:
|
||||
# - key="value"
|
||||
# platform: linux/arm
|
||||
- name: apply-app
|
||||
type: apply-app
|
||||
inputs:
|
||||
- from: context.image
|
||||
parameterKey: data.spec.components[0].properties.image
|
||||
properties:
|
||||
data:
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
spec:
|
||||
components:
|
||||
- name: my-web
|
||||
type: webservice
|
||||
properties:
|
||||
# Note that this field will be replaced by the image in inputs
|
||||
image: my-registry/test-image:v1
|
||||
imagePullSecrets:
|
||||
- image-secret
|
||||
ports:
|
||||
- port: 80
|
||||
expose: true
|
||||
```
|
||||
|
||||
The workflow has four steps in total:
|
||||
|
||||
1. Create a secret with Git token, which is used to pull the code from the private repository to build the image. If your repository is public, you can skip this step. You can also skip this step and use the `kubectl create secret generic git-token --from-literal='GIT_TOKEN=<your-token>'` command to create the secret.
|
||||
2. Create a secret with the image registry token to push the image to your image registry. You can also skip this step and use `kubectl create secret docker-registry docker-regcred --docker-server=https://index.docker.io/v1/ --docker-username=<your-username> -- docker-password=<your-password>` command to create the secret.
|
||||
3. Use the `build-push-image` step type to build and push the image. This step will use the specified Git url and the code in its branch to build the image. You can also directly specify in the context field. The bottom layer of this step will use [Kaniko](https://github.com/GoogleContainerTools/kaniko) for image building. During the building, you can use `vela workflow logs build-push-image --step build-push` to view the log of the step. Note that this step has an input from `context.image`, which will override the image field in properties. As you can see, we currently declare `image: my-registry/test-image:v2` in the context. When we need to reuse this workflow to build a new image version, we only need to update the data in the context to update the entire process.
|
||||
4. In the last step, the image version in `context.image` will be used to publish the application. When the application starts, you can use `vela port-forward my-app 8080:80` to check the result.
|
||||
|
||||
If you configure the process in VelaUX's Pipeline, you can directly see the status and sequence of all steps on the page, including step logs, input and output, etc.
|
||||
|
||||
|
||||
|
||||
### Use Application workflow
|
||||
|
||||
You can also directly build the image in the application, and use the newly built image in the component. Apply the following application:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: build-push-image
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-web
|
||||
type: webservice
|
||||
properties:
|
||||
image: my-registry/test-image:v1
|
||||
ports:
|
||||
- port: 80
|
||||
expose: true
|
||||
workflow:
|
||||
steps:
|
||||
- name: build-push
|
||||
type: build-push-image
|
||||
properties:
|
||||
# use your kaniko executor image like below, if not set, it will use default image oamdev/kaniko-executor:v1.9.1
|
||||
# kanikoExecutor: gcr.io/kaniko-project/executor:latest
|
||||
# you can use context with git and branch or directly specify the context, please refer to https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts
|
||||
context:
|
||||
git: github.com/FogDong/simple-web-demo
|
||||
branch: main
|
||||
# you must align the image value with image field of the component properties
|
||||
image: my-registry/test-image:v1
|
||||
# specify your dockerfile, if not set, it will use default dockerfile ./Dockerfile
|
||||
# dockerfile: ./Dockerfile
|
||||
credentials:
|
||||
image:
|
||||
name: image-secret
|
||||
# buildArgs:
|
||||
# - key="value"
|
||||
# platform: linux/arm
|
||||
- name: apply-comp
|
||||
type: apply-component
|
||||
properties:
|
||||
component: my-web
|
||||
```
|
||||
|
||||
In the application above, the first step in the workflow will use the `build-push-image` step to build the image, and the second step will deploy the component with the newly built image.
|
||||
|
|
@ -1,29 +1,27 @@
|
|||
---
|
||||
title: 触发器
|
||||
description: 使用触发器对接 CI 自动部署
|
||||
title: 对接 CI 自动部署
|
||||
description: 对接 CI 自动部署
|
||||
---
|
||||
|
||||
You can use triggers from [VelaUX addon](../../../reference/addons/velaux) to integrate with different CI systems, the architecture and supported platforms are described in the following picture, they're:
|
||||
在 KubeVela 中，你可以选择使用声明式工作流直接对接 CI 步骤，如：代码构建，镜像推送等。或者，你可以选择使用触发器对接外部的 CI 系统，如：对接 Jenkins，镜像仓库等。
|
||||
|
||||
- [Custom](#custom-trigger), refer to [Jenkins CI](../../../tutorials/jenkins) guide for a real world use case
|
||||
- [ACR](#ACR-trigger)
|
||||
- [Harbor](#Harbor-trigger), refer to [Harbor Integration](../../../tutorials/trigger) guide for a real world use case
|
||||
- [DockerHub](#DockerHub-trigger)
|
||||
- [JFrog](#JFrog-trigger)
|
||||
## 使用声明式工作流对接 CI 步骤
|
||||
|
||||
KubeVela v1.7+ 中默认提供了构建镜像的内置步骤，具体请参考 [镜像构建集成](../../../tutorials/s2i)
|
||||
|
||||
## 使用触发器对接 CI 系统
|
||||
|
||||
你可以使用 [VelaUX addon](../../../reference/addons/velaux) 的触发器来和不同 CI 系统进行集成，在 ValueUX 中，每个应用在创建完成后，都会自动创建一个默认触发器，你可以删除或者创建新的不同类型的触发器。下图描述了架构体系和支持对接的平台：
|
||||
|
||||
- [自定义触发器](#custom-trigger), 你可以参考 [Jenkins CI 对接](../../../tutorials/jenkins) 作为自定义触发器的实际案例。
|
||||
- [ACR 镜像仓库](#ACR-trigger)
|
||||
- [Harbor 镜像仓库](#Harbor-trigger), 你可以参考 [Harbor 镜像仓库](../../../tutorials/trigger) 获得更详细的用例。
|
||||
- [DockerHub 镜像仓库](#DockerHub-trigger)
|
||||
- [JFrog 镜像仓库](#JFrog-trigger)
|
||||
|
||||
|
||||
|
||||
## 如何使用
|
||||
|
||||
应用在创建完成后，会自动创建一个默认触发器，你可以删除或者创建新的触发器。
|
||||
|
||||
|
||||
|
||||
KubeVela 触发器可以对接不同类型的 CI 系统，在 CI 系统中添加触发器以此实现应用的自动部署。比如从制品仓库的镜像更新触发，通过 Jenkins Pipeline 触发等。
|
||||
|
||||
目前可以创建五种不同类型的触发器：Custom、ACR、Harbor、DockerHub、JFrog，我们将分别介绍。
|
||||
|
||||
## Custom 触发器
|
||||
### Custom 触发器
|
||||
|
||||
Custom 为自定义类型的触发器，它提供一个 Webhook URL 以及指定的请求体格式，你可以用它来对接任意 CI 系统。
|
||||
|
||||
|
|
@ -72,25 +70,13 @@ webhook-request:
|
|||
|
||||
|
||||
|
||||
## Harbor 触发器
|
||||
你还可以参考 [Jenkins CI 对接](../../../tutorials/jenkins) 作为自定义触发器的实际案例。
|
||||
|
||||
Harbor 触发器可以对接 Harbor 镜像仓库。
|
||||
### Harbor 触发器
|
||||
|
||||
首先来创建一个 Harbor 触发器，Payload Type 选择 Harbor，Execution Workflow 选择触发器需要触发的工作流：
|
||||
请参考 [Harbor 镜像仓库](../../../tutorials/trigger)。
|
||||
|
||||
|
||||
|
||||
新建完毕后，在 Harbor 中配置该触发器：
|
||||
|
||||
|
||||
|
||||
配置完成后，当 Harbor 中被推送了新镜像时，VelaUX 中会收到对应的触发请求，从而完成自动部署。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## ACR 触发器
|
||||
### ACR 触发器
|
||||
|
||||
ACR 触发器可以对接 ACR 镜像仓库。
|
||||
|
||||
|
|
@ -108,7 +94,7 @@ ACR 触发器可以对接 ACR 镜像仓库。
|
|||
|
||||
|
||||
|
||||
## DockerHub 触发器
|
||||
### DockerHub 触发器
|
||||
|
||||
DockerHub 触发器可以对接 DockerHub 仓库。
|
||||
|
||||
|
|
@ -126,7 +112,7 @@ DockerHub 触发器可以对接 DockerHub 仓库。
|
|||
|
||||
|
||||
|
||||
## JFrog 触发器
|
||||
### JFrog 触发器
|
||||
|
||||
JFrog 触发器可以对接 JFrog Artifactory。
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,154 @@
|
|||
---
|
||||
title: 镜像构建集成
|
||||
---
|
||||
|
||||
## 简介
|
||||
|
||||
从业务代码到最终的应用，其中不可或缺的一步就是构建镜像。本文将详细介绍如何在 KubeVela 中完成从代码到镜像构建、镜像推送以及应用部署的全过程。
|
||||
|
||||
## 如何使用
|
||||
|
||||
### 使用独立工作流
|
||||
|
||||
KubeVela 在 v1.6 版本中引入了[独立的工作流](../end-user/pipeline/workflowrun)，可以用于串联 CI 步骤与应用部署间的流程。与 KubeVela 应用内的工作流不同的是，独立工作流的发布是**一次性**的，它不对资源做管理，即使删除流水线也不会删除创建出来的资源。
|
||||
|
||||
:::tip
|
||||
请确保你已经使用 `vela addon enable vela-workflow` 开启了独立工作流插件。
|
||||
:::
|
||||
|
||||
部署如下工作流：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: build-push-image
|
||||
namespace: default
|
||||
spec:
|
||||
context:
|
||||
image: my-registry/test-image:v2
|
||||
workflowSpec:
|
||||
steps:
|
||||
# 你也可以使用 kubectl create secret generic git-token --from-literal='GIT_TOKEN=<your-token>' 直接创建 Git 秘钥
|
||||
- name: create-git-secret
|
||||
type: export2secret
|
||||
properties:
|
||||
secretName: git-secret
|
||||
data:
|
||||
token: <git token>
|
||||
# 你也可以使用 kubectl create secret docker-registry docker-regcred \
|
||||
# --docker-server=https://index.docker.io/v1/ \
|
||||
# --docker-username=<your-username> \
|
||||
# --docker-password=<your-password>
|
||||
# 直接创建镜像仓库秘钥
|
||||
- name: create-image-secret
|
||||
type: export2secret
|
||||
properties:
|
||||
secretName: image-secret
|
||||
kind: docker-registry
|
||||
dockerRegistry:
|
||||
username: <username>
|
||||
password: <password>
|
||||
- name: build-push
|
||||
type: build-push-image
|
||||
inputs:
|
||||
- from: context.image
|
||||
parameterKey: image
|
||||
properties:
|
||||
# 你可以在 kanikoExecutor 字段中指定你的 kanikoExecutor 镜像，如果没有指定，默认使用 oamdev/kaniko-executor:v1.9.1
|
||||
# kanikoExecutor: gcr.io/kaniko-project/executor:latest
|
||||
# 你可以在 context 中指定 git 和 branch，或者直接指定完整的 context，请参考 https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts
|
||||
context:
|
||||
git: github.com/FogDong/simple-web-demo
|
||||
branch: main
|
||||
# 注意，该字段会被 inputs 中的 image 覆盖
|
||||
image: my-registry/test-image:v1
|
||||
# 指定 dockerfile 路径，如果没有指定，默认会使用 ./Dockerfile
|
||||
# dockerfile: ./Dockerfile
|
||||
credentials:
|
||||
image:
|
||||
name: image-secret
|
||||
# buildArgs:
|
||||
# - key="value"
|
||||
# platform: linux/arm
|
||||
- name: apply-app
|
||||
type: apply-app
|
||||
inputs:
|
||||
- from: context.image
|
||||
parameterKey: data.spec.components[0].properties.image
|
||||
properties:
|
||||
data:
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
spec:
|
||||
components:
|
||||
- name: my-web
|
||||
type: webservice
|
||||
properties:
|
||||
# 注意，该字段会被 inputs 中的 image 覆盖
|
||||
image: my-registry/test-image:v1
|
||||
imagePullSecrets:
|
||||
- image-secret
|
||||
ports:
|
||||
- port: 80
|
||||
expose: true
|
||||
```
|
||||
|
||||
该工作流总共有四个步骤：
|
||||
|
||||
1. 创建带有 Git 秘钥的 Secret，用于拉取私有仓库的代码来构建镜像。如果你的仓库是公开的，可以跳过这一步。你也可以跳过这一步，使用 `kubectl create secret generic git-token --from-literal='GIT_TOKEN=<your-token>'` 命令来创建秘钥。
|
||||
2. 创建带有镜像仓库秘钥的 Secret，用于将镜像推送至你的镜像仓库。你也可以跳过这一步，使用 `kubectl create secret docker-registry docker-regcred --docker-server=https://index.docker.io/v1/ --docker-username=<your-username> --docker-password=<your-password>` 命令来创建秘钥。
|
||||
3. 使用 `build-push-image` 步骤类型来构建并推送镜像，该步骤会使用指定的 Git 地址及其分支中的代码来构建镜像，你也可以显示指定构建的 context 信息。这个步骤底层会使用 [Kaniko](https://github.com/GoogleContainerTools/kaniko) 进行镜像构建，在构建的过程中，你可以使用 `vela workflow logs build-push-image --step build-push` 来查看步骤的日志。值得注意的是，这个步骤有一个来源于 `context.image` 的 inputs，这个 inputs 将覆盖 properties 中的 image 字段。可以看到，当前我们在 context 中声明了 `image: my-registry/test-image:v2`。当我们需要复用这条工作流来构建新的镜像版本时，只需要更新 context 中的数据，就能够更新整个流程。
|
||||
4. 最后一步中将使用 `context.image` 中的镜像版本来发布应用，当应用启动后，你可以使用 `vela port-forward my-app 8080:80` 来查看应用的效果。
|
||||
|
||||
如果你是在 VelaUX 的 Pipeline 中配置的流程，你可以直接在页面中看到所有步骤的状态和顺序，包括步骤的日志、输入输出等。
|
||||
|
||||
|
||||
|
||||
### 在应用中构建镜在应用中构建像，并将新构建的作为组件的镜像，部署如下应用：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: build-push-image
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-web
|
||||
type: webservice
|
||||
properties:
|
||||
image: my-registry/test-image:v1
|
||||
ports:
|
||||
- port: 80
|
||||
expose: true
|
||||
workflow:
|
||||
steps:
|
||||
- name: build-push
|
||||
type: build-push-image
|
||||
properties:
|
||||
# 你可以在 kanikoExecutor 字段中指定你的 kanikoExecutor 镜像，如果没有指定，默认使用 oamdev/kaniko-executor:v1.9.1
|
||||
# kanikoExecutor: gcr.io/kaniko-project/executor:latest
|
||||
# 你可以在 context 中指定 git 和 branch，或者直接指定完整的 context，请参考 https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts
|
||||
context:
|
||||
git: github.com/FogDong/simple-web-demo
|
||||
branch: main
|
||||
# 请确保此处 image 字段与 Component 中的 image 相同
|
||||
image: my-registry/test-image:v1
|
||||
# 指定 dockerfile 路径，如果没有指定，默认会使用 ./Dockerfile
|
||||
# dockerfile: ./Dockerfile
|
||||
credentials:
|
||||
image:
|
||||
name: image-secret
|
||||
# buildArgs:
|
||||
# - key="value"
|
||||
# platform: linux/arm
|
||||
- name: apply-comp
|
||||
type: apply-component
|
||||
properties:
|
||||
component: my-web
|
||||
```
|
||||
|
||||
在上面这个应用中，工作流中的的第一步会使用 `build-push-image` 步骤来构建镜像，而第二步则会使用新构建的镜像来部署组件。
|
||||
|
|
@ -160,7 +160,7 @@ module.exports = {
|
|||
type: 'doc',
|
||||
id: 'how-to/dashboard/trigger/overview',
|
||||
},
|
||||
items: ['tutorials/jenkins', 'tutorials/trigger'],
|
||||
items: ['tutorials/s2i', 'tutorials/jenkins', 'tutorials/trigger'],
|
||||
},
|
||||
{
|
||||
'Day-2 Operations': [
|
||||
|
|
|
|||
Loading…
Reference in New Issue