cOS-toolkit：Container OS 的下一程

作者简介
张智博，SUSE Rancher 大中华区研发总监，一直活跃在研发一线，经历了 OpenStack 到 Kubernetes 的技术变革，在底层操作系统 Linux、虚拟化 KVM 和 Docker 容器技术领域都有丰富的研发和实践经验。

背景：笔者曾经维护过一款面向 Docker 的开源容器化操作系统 RancherOS。cOS-toolkit 作为延续 Container OS 思想的新兴项目，做了更深层次的抽象。本文将逐步剖析 cOS-toolkit 的设计理念和使用方法，并分享个人的一些思考。

RancherOS 的反思

RancherOS 发布之初，Docker 正是如日中天之时，顺理成章，RancherOS 的目标就是成为一款面向 Docker 的 Container OS。除了基础的 Immutable OS 标准特性之外，我们做了很多魔改：比如把 dockerd 改为 system-docker 来替换 systemd，从而可以像管理容器一样管理一些系统服务；极致裁剪了内核，希望把它打造成以最低成本运行 Docker 的 OS；两层的 rootfs，当然用户空间的 rootfs 本质上是一个 Ubuntu/CentOS/Buildroot 等镜像运行的容器；使用 YAML 配置清单来做系统初始化，通过这种抽象来简化系统管理员的负担等等。

随着时间的推移，一些魔改的思路随着上游的发展而变得不可持续，比如 system-docker 组件始终停留在早期版本，无法进化。精简内核也带来了诸多问题，未能背靠一个强大的社区，很难持续维护这些内核以及系统组件，并在兼容性上提供可信任的保证。默认的 console 基于 Buildroot 项目构建，每次增加软件包都是非常繁琐复杂的工作，并且 Buildroot 本身追求的精简有时无法满足服务器端的需求。用户的自定义需求很难得到满足，用户通常需要等待官方版本的更新，用户自定义的技术成本非常高，难以上手。

RancherOS 的发展过程中取得了一定数量的社区用户，并尝试了小范围的商业化支持，它把想法变成现实，对于特定群体是一个好的开源项目。然而，从可持续发展角度，停止维护是一个更理性的选择。尽管，能够看到社区用户仍然在发布一些 RancherOS 的衍生版本 BurmillaOS（https://burmillaos.org/）。

cOS-toolkit 接棒下一程

cOS-toolkit 是一个构建 ContainerOS 的工具包，之前 RancherOS 本身就是一个 Linux 发行版，而 cOS-toolkit 提供了构建这种发行版更强大的抽象能力。吸取之前的一些开源项目经验，结合当下市场的主流需求，cOS-toolkit 可以带来以下关键特性：

• 使用 Container 方式进行构建和升级。cOS-toolkit 使用了开源工具luet（https://github.com/mudler/luet），luet 是一个基于容器的多平台包管理工具。cOS-toolkit 的核心能力就来自于 luet，cOS-toolkit 本身就维护了若干 luet packages（https://github.com/rancher-sandbox/cOS-toolkit/tree/master/packages）。在各种 Linux 发行版的基础镜像之上，叠加这些 packages，就可以基于 Dockerfile 的模式构建 Container OS。这种作法可以依托每个 Linux 发行版背后强大的社区，cOS-toolkit 无需关注某个软件包如何编译集成，也不会破坏每个发行版发烧友的使用习惯。
  

  

• 支持 OTA 更新。这个特性还处在不断进化中，Container OS 的 OTA 可以将更新内容构建后发布到镜像仓库中，通过 Kubernetes 的扩展编排能力来进行所有节点的系统升级，升级动作触发特定容器镜像更新，并应用到 cOS-toolkit 构建的 OS 中。

• Cloud-init 支持，基于 systemd，以及不可变特性。Cloud-init 的支持能力直接反映了在公有云环境的友好程度上；而基于 systemd 是可持续性发展的一个重要选择；对 Immutable 的支持在整个设计中具有优先权，这是几乎所有 Container OS 的标配属性。
• 简单方便的自定义。cOS-toolkit 不再只是一种发行版，它提供了更强大的自定义构建能力，用户除了可以引用 cOS-toolkit 中维护的 packages，还可以自定义 package 进行扩展，同时 cOS-toolkit 本身还简化了各种 OEM 配置（https://rancher-sandbox.github.io/cos-toolkit-docs/docs/customizing/oem_configuration/），更换 branding 以及变更初始用户名密码会非常简单。强大的自定义能力，还让用户可以针对云环境或者边缘环境等硬件规格特性来构建特定的 OS，针对各种硬件环境的驱动和软件包本身就依托背后强大的发行版社区，无论质量还是兼容性都有可靠保证。

cOS-toolkit 工程会默认构建一些基础发行版：

• Blue：基于 Fedora
• Green：基于 openSUSE
• Orange：基于 Ubuntu

由于核心工程人员来自 SUSE，基于 openSUSE 的变种会进行较完整的测试，这些镜像介质可以在 Github Release（https://github.com/rancher-sandbox/cOS-toolkit/releases）中下载。

SUSE Rancher 已经开始用 cOS-toolkit 构建一些新兴产品，比如 Harvester OS 以及RancherOS v2。前者提供了 Harvester 集群的底座 OS，便于 Harvester 对节点进行更深层次的管理；后者未来将致力于提供可以面向 Rancher 以及 K3s/RKE2 的底座 OS，进一步简化产品部署和运维难度。RancherOS v2 也处于开源积极孵化中：https://github.com/rancher-sandbox/os2

cOS-toolkit初体验

支持公有云的友好体验已经是新兴操作系统的标配，cOS-toolkit 构建的 Green（基于openSUSE）变种完全支持 AWS/Azure/GCP 等公有云。我们以 AWS 版本为例进行初始体验，AMI 信息可以在Github Release（https://github.com/rancher-sandbox/cOS-toolkit/releases）中下载到，本文体验版本为v0.7.4。

由于这些 AMI 在构建时默认使用 UEFI 方式启动，所以部分实例类型无法支持，本次体验使用 t3.large。

默认情况下，系统初始会进入 Recovery 模式，用户可以在该模式下进行自定义安装，通过内置的安装工具配合预定义的 YAML 配置进行系统初始化安装。不过，由于我们使用 AWS 云环境，我们可以借助 cloud-init 机制来简化这一过程。在基于 cOS AMI 启动实例时（根磁盘 16GiB），配置以下 cloud-init 内容：

name: "Default deployment"
stages:
   rootfs.after:
     - name: "Repart image"
       layout:
         # It will partition a device including the given filesystem label or part label (filesystem label matches first)
         device:
           label: COS_RECOVERY
         add_partitions:
           - fsLabel: COS_STATE
             # 10Gb for COS_STATE, so the disk should have at least 16Gb
             size: 10240
             pLabel: state
           - fsLabel: COS_PERSISTENT
             # unset size or 0 size means all available space
             pLabel: persistent
   initramfs:
     - if: '[ -f "/run/cos/recovery_mode" ]'
       name: "Set sshd to wait for deployment"
       files:
       - path: "/etc/systemd/system/sshd.service.d/override.conf"
         content: |
             [Unit]
             After=cos-setup-network.service
   network:
     - if: '[ -f "/run/cos/recovery_mode" ]'
       name: "Deploy cos-system"
       commands:
         - |
             cos-deploy --no-verify --no-cosign && shutdown -r now

这份 cloud-init userdata 会帮助我们规划根磁盘分区表信息，同时进行初始化安装。注意 cos-deploy 时如果没有指定版本，则会安装最新版本。这意味着尽管我们使用 v0.7.4 的 AMI，但在 cos-deploy 后会在源中寻找更新的版本来部署到根磁盘中，这其实也是 OTA 更新机制的一部分。

系统安装初始化完毕后，可以通过 ssh 访问，由于还没有完整适配 AWS 的 metadata，所以暂时还是使用 user/password 方式访问，且我们没有在 userdata 中更改密码，故可以使用默认用户名和密码 root/cos。整个系统会异常干净简洁，由于 Green 变种使用 openSUSE 发行版为基础，其内核版本也与 openSUSE 15.3 保持一致，系统版本也同时追踪到 v0.8.2。

除了使用 cloud-init 机制安装系统外，还可以手动使用 cos-deploy 进行安装，可以在执行过程中清晰看到拉取了 v0.8.2 较新的系统镜像。

当然，我们也可以制作自定义镜像并推送到镜像仓库中，系统镜像的构建可以依托 Dockerfile 机制。以 Github Repo 中的 standard example（https://github.com/rancher-sandbox/cOS-toolkit/blob/master/examples/standard/Dockerfile）为例，基础镜像使用 openSUSE 后，通过在 Dockerfile 中执行 zypper 来安装软件包，而这些软件包则依托强大的社区来保障质量：

ARG LUET_VERSION=0.20.6
FROM quay.io/luet/base:$LUET_VERSION AS luet


FROM opensuse/leap:15.3


ENV COSIGN_EXPERIMENTAL=1
ENV COSIGN_REPOSITORY=raccos/releases-green


ARG ARCH=amd64
ENV ARCH=${ARCH}
RUN zypper in -y \
    bash-completion \
    conntrack-tools \
    coreutils \
    curl \
    device-mapper \
    dosfstools \
    dracut \
    kernel-default \
    kernel-firmware-bnx2 \
    kernel-firmware-i915 \
    kernel-firmware-intel \
    kernel-firmware-iwlwifi \
    kernel-firmware-mellanox \
    kernel-firmware-network \
    kernel-firmware-platform \
    kernel-firmware-realtek \
    less \
…
…

我们把这个 Dockerfile 构建成容器镜像（如：niusmallnan/containeros:dev），并推送到 Dockerhub。在刚才已经启动的 AWS VM 执行：cos-upgrade --no-verify --reboot -d niusmallnan/containeros:dev ，自动重启后，我们可以获得一个新版本的 OS，这就是基于容器模式的 OTA 更新的基础演示。访问虚拟机可以看到，无论是 OS 版本信息，内置软件包，以及内核版本均发生了变化：

cOS-toolkit 还在不断完善中，很多细节还有优化空间。cOS-toolkit 并不是在持续提供某个发行版，而是维护构建个性化 Container OS 的工具集，用户可以依托它进行 OS 的制作和发布，同时享受其带来的容器镜像风格的 OTA 更新机制。

更多内容请参考官方文档：https://rancher-sandbox.github.io/cos-toolkit-docs/docs/