作者簡介
張智博，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/