Nextjs

这篇文档讲什么 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 里这三样东西分别是： ...

问题从哪来 构建容器镜像，最常见的做法是写一个 Dockerfile（或 Containerfile），交给 BuildKit、Buildah、Kaniko 之类的构建器执行。Cloud Native Buildpacks（CNB）则不需要 Dockerfile：把源码或 jar 交给 builder，自动产出 OCI 镜像。 既然 Dockerfile 已经能构建任意镜像，为什么还会出现 CNB？它解决的是 Dockerfile 解决不了的问题，还是别的问题？本文把这几个问题放在一起整理。CNB 的概念与 Paketo 用法见 CNB: Cloud Native Buildpacks 与 Paketo，Dockerfile 写法见 Containerfile。 先说结论：CNB 主要解决的不是「单个镜像能不能构建出来」，而是「几百上千个应用的镜像由谁来写、怎么统一、基础镜像出漏洞后怎么批量修」。这是组织规模上的问题，不是 Dockerfile 语法能力上的问题。 BuildKit 是什么 BuildKit 是 Moby 项目下的构建引擎，Docker Engine 23.0 起在 Linux 上成为 docker build 的默认后端，docker buildx 也基于它。 一个常被忽略的点：BuildKit 本身并不依赖 Dockerfile。它的结构分两层： 前端（frontend）：把某种构建描述翻译成 LLB（Low-Level Build definition，一种描述构建步骤的有向无环图）。Dockerfile 只是其中一个前端，Dockerfile 首行的 # syntax=docker/dockerfile:1 指定的就是前端镜像。 求解器（solver）：执行 LLB，负责并行、缓存、导出镜像。 flowchart LR DF[Dockerfile] OTHER[其他前端Dagger / Railpack 等] FE[Frontend] LLB[LLB DAG] SOLVER[BuildKit Solver并行 + 缓存] OUT[OCI 镜像 / 本地文件] DF --> FE OTHER --> LLB FE --> LLB --> SOLVER --> OUT 所以更准确的说法是：「Dockerfile 是一种构建描述语言，BuildKit 是执行引擎」。Dagger 的引擎、Railway 的 Railpack 等工具都直接生成 LLB，不写 Dockerfile 也能用 BuildKit。 ...

Turbopack 是 Vercel 开发的 JavaScript/TypeScript 打包工具（bundler），用 Rust 编写，定位是 Webpack 的继任者。它目前主要通过 Next.js 使用：从 Next.js 16 开始，next dev 和 next build 默认都用 Turbopack。 打包工具做什么 浏览器不能直接运行一个现代前端项目的源码：TypeScript 和 JSX 要编译成 JavaScript，import 了上百个 npm 包的模块图要合并、拆分成若干个文件，CSS、图片要处理，生产环境还要压缩、去掉没用到的代码（tree shaking）。打包工具做的就是这件事：从入口文件出发，沿着 import 建出完整的模块图，再按规则输出浏览器和 Node.js 能直接加载的文件。 Next.js 这类同时有服务端和客户端代码的框架，还要求打包工具同时产出两套结果：服务端渲染用的代码，和发给浏览器的代码。 常见的打包工具： 工具 实现语言 说明 Webpack JS 2012 年起的事实标准，插件和 loader 生态最大 Rollup JS 偏库打包，Vite 的生产构建原先基于它 esbuild Go 速度快，常被其他工具当作底层编译器 Vite JS 开发模式基于浏览器原生 ESM，正在把底层换成 Rust 实现 Turbopack Rust Vercel 出品，与 Next.js 绑定 背景 Webpack 统治前端工程化十余年，但它用 JavaScript 实现，项目一大，冷启动和热更新都慢。Vercel 在 2022 年随 Next.js 13 发布了 Turbopack 的 alpha 版。Webpack 的原作者 Tobias Koppers 是 Turbopack 的核心作者之一。 ...