在构建机上构建并发布

本页介绍如何在一台独立的构建机（build host）上用 kibo-build 构建 Template 与 Platform，再把产物交给 Operator 发布到目录。负责构建镜像的人和 Operator 都会用到这一流程。

• 第一次构建 Template、想从一个 OCI 镜像走完到创建 Workspace 的流程，见构建自己的 Template。
• 发布后的批准与默认版本设置见 目录。

概述复制标题链接

构建与发布分在两台机器、两个账户上：

1. 构建机以 root 运行 kibo-build，产出 Template 结果与 Platform 归档。它不需要任何 Operator、ctrl 或 store 凭证。
2. Operator 拿到产物后，在自己的工作机上用 kibo template publish 与 kibo platform publish 上传到目录。

构建工具与 Debian 包复制标题链接

kibo-build 启动时检查所需的宿主机工具。各类构建需要的工具及其 Debian/Ubuntu 包：

注意：

• 生成 rootfs 需要 root。从镜像仓库导入不需要 Docker；用 Containerfile 生成内容和构建 Platform 容器需要 Docker 与 Buildx。
• kibo-build 通过宿主机的 Skopeo 与 umoci 操作 OCI 镜像，自身不包含镜像传输或解包的库。
• 工具缺失时构建直接失败。kibo-build 不会自动下载、安装工具或提升权限。
• 构建 KiboVM 独立内核还需要按 lock 文件准备的源码、OCI 镜像、Debian 软件源与 Go modules，见构建输入与缓存。
• 隔离的 HOME 下也要能找到 Buildx，只安装在个人 HOME 中的插件不满足要求。
• BuildKit 的垃圾回收至少保留 20 GB 可复用缓存，最多使用存储的 80%，并尝试留出 20 GB 空闲空间。按此规划构建机的磁盘。

独立构建工具包复制标题链接

kibo-build_VERSION_amd64.deb 包含 kibo-build 与 normalize-ext4。在 Linux amd64 构建机上安装它，apt 会同时安装 Skopeo、umoci、ext4 工具及其运行库。构建机不需要 Go、Git、C 编译器或源码。

sudo apt-get install ./kibo-build_0.0.0-rc.1_amd64.deb

注意：

• 工具的最低版本是 e2fsprogs 1.47.0、util-linux 2.39、umoci 0.4.7 与 Skopeo 1.9.0。更高版本可以使用，实际使用的工具版本会记入缓存与结果。不同版本生成的 ext4 字节可能不同。
• 用这个包从镜像仓库或本地 OCI 镜像构建 Template，见构建自己的 Template与从本地 OCI 导入。
• 构建产物需要让发布账户可读；自定义输出路径时，上级目录要允许该账户进入。

构建 Template 与 Platform复制标题链接

什么时候需要源码复制标题链接

步骤复制标题链接

以下命令以 root 身份在构建机上执行：

build_root=/var/lib/kibotos/build
install -d -m 0755 "$build_root"
printf 'root = "%s"\n' "$build_root" > "$build_root/config.toml"
export KIBOTOS_BUILD_CONFIG="$build_root/config.toml"
source_root=/srv/kibotos
rootfs_result=$(kibo-build template "$source_root/templates/minimal/template.json")
firecracker_archive=$(kibo-build firecracker --source-root "$source_root")
kibovm_archive=$(kibo-build kibovm --source-root "$source_root" \
  --runtime-lock "$source_root/build/kibovm/runtime-artifact.json" \
  --runtime-cache "$source_root/.cache/kibovm-runtime")

• 示例构建的是仓库内最小的验证用 Template。换成其他定义文件即可构建其他 Template，容量和来源都在定义文件里声明。
• 用非 root 账户执行构建时，管理员先创建构建目录并授权这个账户使用。
• Platform 也可以不自己构建，直接使用发布包里的 kibotos-platform-<backend>_<tag>_amd64.tar.zst（例如 kibotos-platform-kibovm_v0.2.0_amd64.tar.zst）。它与本地构建的归档格式相同。

交付并发布复制标题链接

交付物复制标题链接

发布复制标题链接

在 Operator 工作机上执行，不需要构建机的配置文件。--build-cache-root 要传 stage 缓存根目录本身，也就是 kibo-build 构建根下的 cache/stages：

• 它直接包含缓存标记文件，以及内部的又一层 stages/ 目录。
• 不是它的上一级 <构建根>/cache。传了上一级，命令在连接网络之前就失败，并提示应传的精确路径。
• 在构建机上用 kibo-build cache root 打印这个路径。

下面的例子把构建根 /srv/build-root 原样复制到了 Operator 工作机的 /srv/build-handoff：

kibo template publish /srv/build-handoff/results/rootfs-result \
  --build-cache-root /srv/build-handoff/cache/stages --json
kibo platform publish /srv/build-handoff/platform.tar.zst --json

下一步复制标题链接

发布只是把 revision 放进目录。Template 与 Platform 需要分别批准，两者互不影响：

1. 用 kibo platform publish 返回的 revision 执行 kibo platform approve 与 kibo platform set-default。
2. 用 kibo template publish 返回的 Template ID 与 revision 执行 kibo template approve 与 kibo template set-default。

命令细节见 目录。创建 Workspace 时指定 Template revision 见 Template 与资源。在首次使用前让 node 预先准备 Template，见 kibo template prepare。

清理构建缓存复制标题链接

在构建机上执行：

sudo kibo-build cache clean

• 清理不影响对象存储、node 的缓存和已发布的 Template、Platform 与 Launch。
• 更新构建或发布工具后，清理旧缓存，丢弃未发布的旧结果，重新构建或组装。