一款跑在雲上的定制容器專屬 OS 來了——LifseaOS | 龍蜥技術
引言
在 2021 年 10 月的雲栖大會上，
為雲原生而生的 OS Lifsea 正式對外釋出，并內建進入阿裡雲容器服務 ACK Pro 的托管節池，成為可選的作業系統選項。
不久前，LifseaOS 核心代碼正式在龍蜥社群開源，使用者可以基于 LifseaOS 開源代碼建構、定制一個屬于自己的容器專屬 OS。
WHY LifseaOS？
說到 LifseaOS，不得不提到其主要面向的場景：容器。
從最早的 UNIX chroot，到 Linux 的 LXC，早期以 cgroup、namespace 為基礎的容器運作時技術一直在持續演進，但并沒有出現階段性的突破。直到 2013 年，docker 的出現直接推進了容器的快速普及，經過短短幾年的發展，容器已經成為了主流的 IT基礎設施技術被廣泛地應用。容器的快速發展 docker 功不可沒，而我們回顧當時 docker 最初的工作，可以發現其并沒有進行颠覆性的技術變革，其核心創新主要包括以下兩個部分：
- 定義了容器分層鏡像标準以及鏡像倉庫：容器鏡像将應用運作環境，包括代碼、依賴庫、工具、資源檔案和元資訊等，打包成一種作業系統發行版無關的不可變更軟體包
- 定義了覆寫容器全生命周期 restful API：restful API 的将整個容器的建立、監控、銷毀過程标準化，部署、運維人員可以在一個叢集内對大量的容器進行統一化的管理
這兩個關鍵創新帶來了整個開發、內建、部署的革命。首先鏡像能力為 devops 提供了一條便捷的道路，開發人員可以在開發過程中便完成對于整個運作環境的把控，将自己開發成果直接上線部署生産投入，無需再去考慮作業系統相容、庫依賴等環境因素，實作了 docker 的口号“Build，Ship and Run Any App，Anywhere”。其次，restful API 出現使得容器的生命周期管理愈加的便捷，利用編排工具對容器的管理，SRE 可以快速、無差别地進行應用的部署、更新、下線，實作了針對應用管理由“寵物”到“牛群”的質的飛越。
伴随着容器一起發展的是以容器為基礎衍生而出的容器編排、容器存儲、容器網絡等領域，這些領域緊密結合形成了“雲原生”生态，并且在 2015 年開始，圍繞着 K8S 逐漸形成了一套完整的“雲原生作業系統”。通過 K8S，使用者可以在一個分布式叢集内快速、高效地部署容器，無需再去關注複雜的叢集資源配置設定、容器排程等工作。為了完整地支援 K8S，雲廠商也進行了大量的 K8S 的支撐對接，紛紛提供适配自身 I 層基礎設施的 CNI（Container Network Interface）、CSI（Container Storage Interface）以及相對應的 cluster-autoscaler 等元件，讓 K8S 可以完美的管理自己的存儲、網絡、計算資源。
在基礎設施紛紛“雲原生化”的過程中，有一個同屬于 Infra 的元件卻步驟緩慢，這就是作業系統，也就是我們一直說的 OS。雖然存在感并不是很強，但是 OS 作為下接硬體、上接業務的底層軟體，默默地為應用提供了單機資源管理、運作環境建構等能力，發揮着舉足輕重的作用。但是在雲原生場景下，傳統作業系統已經逐漸表現出各種“不适”：
- 體積臃腫：傳統的作業系統為了相容不同的使用場景，包含了各種各樣的硬體驅動、軟體包、系統庫、系統服務等，作業系統背景服務繁多，體積也顯得龐大。在雲原生容器場景下，必要的服務大都已經被容器化，以容器的方式被部署到節點上，通過容器的方式來實作版本、配置的管理，逐漸取代了傳統 OS 上的系統服務；同時，雲上硬體資源通過雲廠商的虛拟化抽象往往更加地簡化，并不需要去支援各種硬體。而容器鏡像本身就有運作時自包含的能力，是以很多傳統 OS 上的能力會顯得厚重而備援，這些厚重的元件還會使整個 OS 啟動變慢并占用相當的系統資源（CPU、記憶體等）。
- 版本零散：為了能夠支援不同的訴求，作業系統提供了各種各樣不同的軟體，并以軟體包為粒度進行版本管理，每個軟體包有自己獨立的功能以及代碼、版本号，由使用者根據自身的需求進行軟體包的增、删。這樣每台主控端上的 OS 狀态是由大量不同軟體包版本号組成的，而在日常運維時一般是針對某一個軟體包進行管理。在雲原生的場景下，叢集計算節點日趨增多，生産過程中由于 bugfix、問題定位等可能在某一節點上針對某個包進行管理（更新、配置修改等），如果沒有一套完整的叢集 OS 運維機制，極容易出現叢集内 OS 狀态不統一的情況，如果在灰階的過程中出現依賴元件版本不一，可能會導緻整個釋出流程受阻，給運維人員帶來極大的困難。
- 安全風險：一方面，傳統作業系統包含了大量雲原生場景下不需要的軟體包和系統服務，帶來更大的攻擊面。另一方面，傳統作業系統的運維人員大多通過 ssh 登入進系統進行黑屏的運維操作，過程難以追溯，誤操作極易帶來災難性的後果。
以上的問題主要還是展現在運維上，這時我們回頭看下，在 docker 出現之前，應用的運維人員也有類似的問題：如何保障應用在不同條件下運作環境的比對一緻、如何便捷快速地管理應用等。而 docker 很好地解決了應用層的問題，那是不是我們可以借鑒 docker 的思路來解決 OS 運維的問題？
其實在業界已經有了一些容器優化版作業系統，即我們常說的 ContainerOS，包括 AWS 的 bottlerocket、Redhat 的 Fodera CoreOS 以及 Rancher 的 RancherOS 等，它們大多具有以下特點：
- 輕量化：作業系統僅僅包含足夠支撐容器運作所需的軟體包與系統服務，大大減少攻擊面，啟動快。
- 原子更新復原：基于不可變基礎設施的設計原則，提供隻讀根檔案系統保證系統不被惡意篡改，作業系統的管理以鏡像為粒度，不提供 YUM 等包管理軟體，整個系統以鏡像為粒度進行更新與復原。Bottlerocket 采用了 A/B 雙分區的方式實作鏡像的原子更新，CoreOS 則通過 rpm-ostree 像管理一個 git 代碼倉一樣管理一個 OS 版本，而 RancherOS 則更加激進地把所有的系統服務全部容器化，實作用容器"管理"作業系統鏡像。
- 預設內建雲原生元件：預設安裝 docker/containerd/kubernetes 等雲原生元件，作業系統開箱即用，不需要使用者進行額外的安裝操作，簡單易用。
- 受控的運維通道：系統去除 sshd 服務，不允許直接登入系統進行運維，同時提供豐富的 API 接口用于主機的運維，另外還提供專用的運維容器作為最後的“退路”用以登入系統。
這些特點其實也印證了我們的思考：用鏡像的方式解決版本零散的問題，用 API 解決叢集運維的問題，而我們更是發現，如果可以把運維 API 化，那我們是不是可以把 OS 也作為一個 K8S 可以管理的資源，讓 K8S 像管理容器一樣管理OS？
LifseaOS：為雲而生的作業系統
基于以上的思考，我們推出了 LifSeaOS，一款為雲原生而生的 OS。
LifseaOS 延續了 CoreOS rpm-ostree 的技術流派，基于由龍蜥社群(OpenAnolis)釋出的龍蜥作業系統(Anolis OS) 作為軟體包選型基礎。
LifseaOS 使用了 rpm-ostree 的功能，實作鏡像的原子性更新復原，讓使用者可以在叢集次元對 OS 鏡像進行 rolling upgrade，像管理牛群一樣管理一整個叢集的作業系統；同時做了大量的裁剪優化，使整體 OS 更輕、更快、更安全。
同時，我們提供了一個用于 OS 運維的小工具（功能還在持續豐富中），将正常的 OS 運維抽象出來并進行收斂，借助阿裡雲雲助手或自動化運維編排服務，使用者針對 OS 的運維操作通過調用運維工具的方式進行，減少針對作業系統的開放性操作，并進行相應的審計。
API 化運維更重要的作用是将 OS 運維往雲原生的方向牽引，我們可以通過一個 K8s 的 controller 對接運維 API，結合上述的 OS 版本化，讓 K8s 像管理一個容器一樣管理一個 HostOS。
當然，LifseaOS 的特征不僅僅是以上描述的鏡像版本化和運維 API 化，它的名字也直接闡述了 LifseaOS 作為一個為雲而生、為容器而生的 OS 所具備的特質：
Lightweight
LifseaOS 預設內建 containerd、kubernetes 元件，僅僅保留 kubernetes pods 運作所需的系統服務與軟體包，整個系統大約隻有 200 左右的軟體包，相比傳統作業系統（Alibaba Cloud Linux 2/3、CentOS）500+ 軟體包而言，數量減少 60%，更加的輕量。
繁重的 cloud-init（雲廠商常用的雲主機中繼資料管理元件）套件被替換為 CoreOS 的 Ignition，且裁剪了大量不需要的功能，僅保留最基礎的磁盤擴容、hostname 配置、chronyd 時區同步伺服器配置與執行 user-data 腳本的功能。去除了不必要的核心子產品、 systemd 服務（比如 systemd-logind、systemd-resolved）以及 systemd 附帶的許多實用性極低的小工具。
Fast
LifseaOS 的定位是跑在雲上虛拟機的作業系統，是以不會涉及到太多的硬體驅動，必要的核心驅動子產品修改為 built-in 模式，去除了 initramfs，udev 規則也被大大簡化，這樣，啟動速度得到了大幅提升，以 ecs.g7.large 規格的 ECS 執行個體為例，LifseaOS 的首次啟動時間保持在 2s 左右：
傳統的作業系統，以 Alibaba Cloud Linux 3 為例，首次啟動時間則在 1min 以上：
Security
LifseaOS 根檔案系統為隻讀權限，隻有 /etc 和 /var 目錄可寫以滿足基礎的系統配置需求。這種設計既符合雲原生場景下的基礎設施不可變原則，又能防止逃逸容器篡改主機檔案系統。不支援 python 但仍然保留了 shell（因為 ACK 在叢集部署階段需要執行一系列的 shell 腳本來進行初始化工作，後續會考慮進一步去除）。
另外，LifseaOS 去除了 sshd 服務，禁止使用者直接登入到系統中進行一系列可能無法追溯的操作；當然，考慮到特殊運維或者緊急運維的需要，LifseaOS 仍然提供一個專用的運維容器滿足非日常的運維需求，運維容器需要通過 API 按需拉起，預設不開啟。
Atomic
LifseaOS 不支援單個 rpm 包的安裝、更新和解除安裝，不提供 yum，是以去除了 Fedora CoreOS 裡的 rpm-ostree 軟體包而僅保留 ostree 的功能（前者提供了以 rpm 包為粒度的管理功能，而後者僅僅管理檔案）。以整個鏡像為粒度的更新和復原極大程度上保證整個叢集内的各個節點的軟體包版本與系統配置的一緻性。每個鏡像經過内部嚴格的測試之後才會上線，相較于傳統作業系統基于單個 rpm 包的更新帶來的不确定性，以鏡像為粒度的測試釋出更能保證更新後系統的穩定性。
小結
最後，也歡迎大家加入龍蜥社群的 OS SIG，一起構造打磨為雲原生而生的容器專屬作業系統。
通路連結位址
龍蜥社群 SIG 連結：
https://openanolis.cn/sig/container-osLifseaOS 開源代碼連結：
https://gitee.com/anolis/lifsea-config https://gitee.com/anolis/lifsea-assembler—— 完 ——
加入龍蜥社群
加入微信群：添加社群助理-龍蜥社群小龍（微信：openanolis_assis），備注【龍蜥】拉你入群；加入釘釘群：掃描下方釘釘群二維碼。歡迎開發者/使用者加入龍蜥社群（OpenAnolis）交流，共同推進龍蜥社群的發展，一起打造一個活躍的、健康的開源作業系統生态！
關于龍蜥社群
龍蜥社群(OpenAnolis)是由企事業機關、高等院校、科研機關、非營利性組織、個人等按照自願、平等、開源、協作的基礎上組成的非盈利性開源社群。龍蜥社群成立于 2020 年 9 月，旨在建構一個開源、中立、開放的Linux上遊發行版社群及創新平台。
短期目标是開發龍蜥作業系統(Anolis OS)作為 CentOS 替代版，重新建構一個相容國際 Linux 主流廠商發行版。中長期目标是探索打造一個面向未來的作業系統，建立統一的開源作業系統生态，孵化創新開源項目，繁榮開源生态。
龍蜥OS 8.4已釋出，支援 x86_64 、ARM64、LoongArch 架構，完善适配 Intel、飛騰、海光、兆芯、鲲鵬、龍芯等晶片，并提供全棧國密支援。
歡迎下載下傳：
https://openanolis.cn/download加入我們，一起打造面向未來的開源作業系統！
https://openanolis.cn