镜像构建集成

从业务代码到最终的应用，其中不可或缺的一步就是构建镜像。本文将详细介绍如何在 KubeVela 中完成从代码到镜像构建、镜像推送以及应用部署的全过程。

KubeVela 在 v1.6 版本中引入了独立的工作流，可以用于串联 CI 步骤与应用部署间的流程。与 KubeVela 应用内的工作流不同的是，独立工作流的发布是一次性的，它不对资源做管理，即使删除流水线也不会删除创建出来的资源。

镜像构建集成 - 图1提示

请确保你已经使用 vela addon enable vela-workflow 开启了独立工作流插件。

部署如下工作流：

  1. apiVersion: core.oam.dev/v1alpha1
  2. kind: WorkflowRun
  3. metadata:
  4.   name: build-push-image
  5.   namespace: default
  6. spec:
  7.   context:
  8.     image: my-registry/test-image:v2
  9.   workflowSpec:
  10.    steps:
  11.     # 你也可以使用 kubectl create secret generic git-token --from-literal='GIT_TOKEN=<your-token>' 直接创建 Git 秘钥
  12.     - name: create-git-secret
  13.       type: export2secret
  14.       properties:
  15.         secretName: git-secret
  16.         data:
  17.           token: <git token>
  18.     # 你也可以使用 kubectl create secret docker-registry docker-regcred \
  19.     # --docker-server=https://index.docker.io/v1/ \
  20.     # --docker-username=<your-username> \
  21.     # --docker-password=<your-password>
  22.     # 直接创建镜像仓库秘钥
  23.     - name: create-image-secret
  24.       type: export2secret
  25.       properties:
  26.         secretName: image-secret
  27.         kind: docker-registry
  28.         dockerRegistry:
  29.           username: <username>
  30.           password: <password>
  31.     - name: build-push
  32.       type: build-push-image
  33.       inputs:
  34.         - from: context.image
  35.           parameterKey: image
  36.       properties:
  37.         # 你可以在 kanikoExecutor 字段中指定你的 kanikoExecutor 镜像，如果没有指定，默认使用 oamdev/kaniko-executor:v1.9.1
  38.         # kanikoExecutor: gcr.io/kaniko-project/executor:latest
  39.         # 你可以在 context 中指定 git 和 branch，或者直接指定完整的 context，请参考 https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts
  40.         context:
  41.           git: github.com/FogDong/simple-web-demo
  42.           branch: main
  43.         # 注意，该字段会被 inputs 中的 image 覆盖
  44.         image: my-registry/test-image:v1
  45.         # 指定 dockerfile 路径，如果没有指定，默认会使用 ./Dockerfile
  46.         # dockerfile: ./Dockerfile
  47.         credentials:
  48.           image:
  49.             name: image-secret
  50.         # buildArgs:
  51.         #   - key="value"
  52.         # platform: linux/arm
  53.     - name: apply-app
  54.       type: apply-app
  55.       inputs:
  56.         - from: context.image
  57.           parameterKey: data.spec.components[0].properties.image
  58.       properties:
  59.         data:
  60.           apiVersion: core.oam.dev/v1beta1
  61.           kind: Application
  62.           metadata:
  63.             name: my-app
  64.           spec:
  65.             components:
  66.               - name: my-web
  67.                 type: webservice
  68.                 properties:
  69.                   # 注意，该字段会被 inputs 中的 image 覆盖
  70.                   image: my-registry/test-image:v1
  71.                   imagePullSecrets:
  72.                     - image-secret
  73.                   ports:
  74.                     - port: 80
  75.                       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 进行镜像构建，在构建的过程中，你可以使用 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 中配置的流程，你可以直接在页面中看到所有步骤的状态和顺序，包括步骤的日志、输入输出等。

镜像构建集成 - 图2

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4.   name: build-push-image
  5.   namespace: default
  6. spec:
  7.   components:
  8.   - name: my-web
  9.     type: webservice
  10.     properties:
  11.       image: my-registry/test-image:v1
  12.       ports:
  13.         - port: 80
  14.           expose: true
  15.   workflow:
  16.     steps:
  17.     - name: build-push
  18.       type: build-push-image
  19.       properties:
  20.         # 你可以在 kanikoExecutor 字段中指定你的 kanikoExecutor 镜像，如果没有指定，默认使用 oamdev/kaniko-executor:v1.9.1
  21.         # kanikoExecutor: gcr.io/kaniko-project/executor:latest
  22.         # 你可以在 context 中指定 git 和 branch，或者直接指定完整的 context，请参考 https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts
  23.         context:
  24.           git: github.com/FogDong/simple-web-demo
  25.           branch: main
  26.          # 请确保此处 image 字段与 Component 中的 image 相同
  27.         image: my-registry/test-image:v1
  28.         # 指定 dockerfile 路径，如果没有指定，默认会使用 ./Dockerfile
  29.         # dockerfile: ./Dockerfile
  30.         credentials:
  31.           image:
  32.             name: image-secret
  33.         # buildArgs:
  34.         #   - key="value"
  35.         # platform: linux/arm
  36.     - name: apply-comp
  37.       type: apply-component
  38.       properties:
  39.         component: my-web

在上面这个应用中，工作流中的的第一步会使用 build-push-image 步骤来构建镜像，而第二步则会使用新构建的镜像来部署组件。

Last updated on 2023年8月4日 by Daniel Higuero