cOS-toolkit：Container OS 的下一程

Rancher發表於2022-03-17
AI
作者簡介
張智博，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-sa...）。在各種 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.githu...），更換 branding 以及變更初始使用者名稱密碼會非常簡單。強大的自定義能力，還讓使用者可以針對雲環境或者邊緣環境等硬體規格特性來構建特定的 OS，針對各種硬體環境的驅動和軟體包本身就依託背後強大的發行版社群，無論質量還是相容性都有可靠保證。

cOS-toolkit 工程會預設構建一些基礎發行版：

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

由於核心工程人員來自 SUSE，基於 openSUSE 的變種會進行較完整的測試，這些映象介質可以在 Github Release（https://github.com/rancher-sa...）中下載。

SUSE Rancher 已經開始用 cOS-toolkit 構建一些新興產品，比如 Harvester OS 以及RancherOS v2。前者提供了 Harvester 叢集的底座 OS，便於 Harvester 對節點進行更深層次的管理；後者未來將致力於提供可以面向 Rancher 以及 K3s/RKE2 的底座 OS，進一步簡化產品部署和運維難度。RancherOS v2 也處於開源積極孵化中：https://github.com/rancher-sa...

cOS-toolkit初體驗

支援公有云的友好體驗已經是新興作業系統的標配，cOS-toolkit 構建的 Green（基於openSUSE）變種完全支援 AWS/Azure/GCP 等公有云。我們以 AWS 版本為例進行初始體驗，AMI 資訊可以在Github Release（https://github.com/rancher-sa...）中下載到，本文體驗版本為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-sa...）為例，基礎映象使用 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.githu...

相關文章