Tekton

这篇文档讲什么 Homelab 里两个前端 enx-ui（Next.js）和 rssx-ui（Vue + Vite）的镜像，现在都用 Cloud Native Buildpacks（CNB）构建，不再用 Dockerfile + Kaniko。本文按实际配置说明这套构建是怎么搭起来的：编译用哪个镜像、运行用哪个镜像、自己写的 buildpack 做了什么、Tekton 里怎么跑。 CNB 本身的概念（buildpack、builder、lifecycle、platform）见 CNB: Cloud Native Buildpacks 与 Paketo；为什么会有 CNB、它和 Dockerfile 的取舍见 Dockerfile/BuildKit vs CNB。这里只写 homelab 的落地。 为什么换掉 Kaniko Kaniko 上游（GoogleContainerTools/kaniko）2025-06 已归档，executor:v1.23.0 之后没有安全更新。 enx-ui 用 Kaniko 构建一次约 5 分 20 秒，其中解压缓存的 node_modules 层 78 秒，每次新建并挂载 Longhorn RWX 卷约 40 秒。 备选里 BuildKit 需要常驻 buildkitd，rootless 模式也要放宽 seccomp/AppArmor；CNB 的 lifecycle 以普通用户运行，不需要特权，还支持 rebase。所以选了 CNB。2026-10 rssx 也迁过来之后，集群里已经没有 Kaniko 了。 三个组件：builder、buildpack、run image CNB 构建出来的镜像，是把「构建产物」叠到「运行镜像」上。homelab 里这三样东西分别是： ...

背景 Spring Boot REST API 打成 jar 之后，放进容器常见有三层递进：先有一个能跑的 fat jar，再用分层 JAR 优化 Docker 缓存，最后用 Cloud Native Buildpacks 一键出镜像；若还要缩小运行时，可在 Buildpack 上显式开启 jlink 裁剪 JRE。fat jar 布局与 JarLauncher 见专文 Spring Boot Executable JAR。 Spring Framework 本身几乎不讲容器镜像；相关说明集中在 Spring Boot Reference 的 Packaging → Container Images。本文把分层 JAR、bootBuildImage、Paketo jlink 串成一条阅读路径，并附上官方文档索引。GraalVM Native Image 是另一条路线，见 GraalVM Native Image 简介。 三条路径总览 flowchart TB subgraph build [构建] SRC[源码 mvn package / bootJar] FAT[Fat JAR 可执行 uber jar] LAY[分层 JAR 含 layers.idx] end subgraph deploy [容器化] D1[简单 DockerfileCOPY jar + java -jar] D2[分层 Dockerfilejarmode extract --layers] BP[bootBuildImage / build-imagePaketo Buildpacks] end subgraph runtime [运行时 JVM] JRE[完整 JRE] JLINK[jlink 精简 JREBP_JVM_JLINK_ENABLED] end SRC --> FAT FAT --> LAY FAT --> D1 LAY --> D2 LAY --> BP D1 --> JRE D2 --> JRE BP --> JRE BP -.->|可选| JLINK 路径 典型产物 主要收益 复杂度 Fat jar + 简单镜像 单层 app.jar + JRE 基础镜像 上手最快 低 分层 JAR + Dockerfile 多 COPY 层 + JRE 推送镜像时依赖层可缓存 中 Buildpack（bootBuildImage） OCI 镜像，自动检测 jar 零 Dockerfile、与 Paketo 生态一致 低～中 Buildpack + jlink 同上，运行时 JRE 更小 缩小镜像体积 中（需调 env） 分层 JAR 分层 JAR 在 fat jar 布局不变的前提下，额外写入 BOOT-INF/layers.idx，声明哪些路径属于哪一层、层的写入顺序。Spring Boot 2.3 起默认开启；Maven repackage / Gradle bootJar 的 layered 无需额外配置即可得到。 ...

这篇文档讲什么 Homelab 里跑 enx-api 时，从本机一条 Taskfile 命令到 Pod 滚动更新，中间经过 Tekton 构建镜像、Nexus 存镜像、GitOps 改 manifest、Argo CD 同步集群。本文按实际配置把这条链路拆开说明。 Tekton、Kaniko、Argo CD 各自的概念见 Tekton 与 Kaniko 和 Argo CD 与 GitOps 持续部署；这里只写 enx-api 这条线的落地细节。 涉及的两个仓库 仓库 作用 enx 应用源码、enx-api/Containerfile、根目录 Taskfile w10n-config（私有仓库） K8s manifest、Tekton Pipeline/PipelineRun、Argo CD Application CI 在集群里 clone 的是 GitHub 上的 enx，不是本机工作区；CD 改的是 GitHub 上的 w10n-config（私有仓库，不对外公开），再由 Argo CD 拉到集群。文中出现的 manifest、Pipeline 路径均指该仓库内的 infra/homelab/k8s/ 目录。 整体流程 flowchart LR A[本机 task tekton:build:api] --> B[创建 PipelineRun] B --> C[git-clone-ssh拉 enx 源码] C --> D[kaniko-build构建并推送镜像] D --> E[update-gitops-repo改 deployment.yaml] E --> F[Argo CD 自动 sync] F --> G[enx namespace Pod 更新] 一次完整发布可以概括成四步： ...

Tekton 什么是 Tekton Tekton（发音：/ˈtɛktɒn/，“TEK-ton”）名称来自希腊语 τέκτων，意为"建造者"。 Tekton 是一个开源的云原生 CI/CD 框架，运行在 Kubernetes 上，通过 CRD（自定义资源定义）的方式定义流水线。它是强制 Kubernetes 原生的，所有流水线组件都以 Pod 方式运行，没有其他执行模式。 与 Jenkins、GitLab CI 等工具不同，Tekton 从设计之初就只能运行在 Kubernetes 上，而不是"可选支持 K8s"。这是架构层面的硬性约束，带来的好处是与 K8s 生态深度集成，代价是强依赖 K8s 环境。 Tekton 是 CD Foundation 旗下项目，前身是 Knative 的 Build 模块。 核心概念 Step（步骤） 流水线中的最小执行单元，对应容器中的一条命令。 Task（任务） 由一组有序的 Step 组成，运行在同一个 Pod 中，Steps 共享存储卷。 apiVersion: tekton.dev/v1 kind: Task metadata: name: build-and-push spec: params: - name: image type: string steps: - name: build image: gcr.io/kaniko-project/executor:latest args: - "--dockerfile=$(workspaces.source.path)/Dockerfile" - "--context=$(workspaces.source.path)" - "--destination=$(params.image)" workspaces: - name: source Pipeline（流水线） 由多个 Task 按顺序或并行组成，定义完整的 CI/CD 工作流。 ...