漫步云端：CoreOS實踐指南（一）

jopen 11年前發布 | 34K 次閱讀 CoreOS 分布式/云計算/大數據

摘要：CoreOS是一個采用了高度精簡的系統內核及外圍定制的操作系統。ThoughtWorks的軟件工程師林帆將帶來“行走在云端：構建CoreOS集群”系列文章，介紹CoreOS的精華和推薦的實踐方法。本文為基礎第一篇：CoreOS俯瞰。

【編者按】Docker和CoreOS都是硅谷創業孵化器的優秀“畢業生”，據說兩家老板的私交很好，Docker做容器引擎，CoreOS做容器管理，合作得非常愉快，只是隨著Rocket的發布逐步“分道揚鑣”。雖然Docker和CoreOS都在求“簡”，但是 Docker的“簡”是力求用戶能達到最簡便地使用，CoreOS的“簡”是追求極致的輕量化，究竟哪個將是Container技術的未來，其實也很難說。今天開始，來自ThoughtWorks的軟件工程師林帆將帶來“漫步云端：CoreOS實踐指南”系列文章，帶大家了解CoreOS的精華和推薦的實踐方法。本文為基礎第一篇：CoreOS俯瞰。

漫步云端：CoreOS實踐指南（一）

作者簡介：

林帆，生在80后尾巴的IT攻城獅，ThoughtWorks成都辦公室CloudOps小組成員，平時喜歡在業余時間研究DevOps相關的應用，目前在備考AWS認證和推廣Docker相關技術。

引言

相信許多人開始了解CoreOS是從2014年7月底的一則新聞：內置Docker容器的操作系統CoerOS發布首個正式穩定版本。在那之后的半年里 CoreOS一路高歌猛進。8月中旬CoreOS收購私有Docker倉庫服務商Quay.io，9月初DigitalOcean與CoreOS達成戰略合作，9月底微軟Azure云服務開始支持CoreOS系統鏡像，10月中旬英國的知名云服務商BrightBox也加入支持CoreOS系統鏡像的陣營，加上此前已經支持CoreOS鏡像的全球主流云服務提供商，包括亞馬遜的AWS、云計算巨頭Rackspace和Google Computer Engine，CoreOS的名字已經無所不在。

作為一個發布僅僅一年有余的操作系統（首個發布版本在2013年3月），CoreOS在云計算相關的開源社區和大規模服務器集群的領域早已嶄露頭角，直接與主流Linux服務器操作系統同臺競爭。至于后來RedHat祭出內建容器管理服務的系統Atomic，以及Canonical剛剛推出的Ubuntu Core，逐步掀起ContainerOps的大潮，一個全新的集群運維時代正在開啟。而走在風頭浪尖的CoreOS正是這股潮流的先驅者，它的出現遠遠不只是“又一個Linux發行版”，而是一個時代理念的顛覆。

這篇系列教程將從最基本的概念開始，順著大規模集群管理和應用容器化這兩條主線帶大家了解 CoreOS 系統的獨到之處，使得沒有接觸過這個系統的用戶也能夠快速的理解其中功能的精華和推薦的實踐方法。

CoreOS 是什么

簡單的說，它是一種基于 Chrome OS 再定制的輕量級 Linux 發行版本。

作為一個操作系統，CoreOS 采用了高度精簡的系統內核及外圍定制，將許多原本需要復雜人工操作或者第三方軟件支持的功能在操作系統級別進行了實現，同時剔除了其他對于服務器系統非核心的軟件，比如GUI和包管理器。

特別值得一提的是 CoreOS 對包管理器的態度和 Docker 的原生支持。這是許多習慣了傳統 Linux 管理方式的用戶在剛接觸 CoreOS 時，最不習慣的地方，因為 CoreOS 沒有提供現成的包管理工具。一個典型的困惑是：在 CoreOS 安裝軟件太不方便了。事實上 CoreOS 并不鼓勵用戶將各種應用軟件直接安裝在操作系統之上，而是提倡將所有服務運行在單獨的應用容器中，由應用容器提供應用所需要的基礎功能環境。這種做法將操作系統和應用程序的職責做了更徹底的分離，降低操作系統和應用程序的耦合度，使運行這些服務器的公司可以更快速、更廉價地更新自己的線上業務。

CoreOS 行走在云端

毫不夸張的說，CoreOS 是為云而生的操作系統。

這個“為云而生”包含兩層含義：

首先，CoreOS 的設計立足點充分的考慮了云端生態系統的分布式部署、大規模伸縮擴展(Scaling)需求，我們將會再后面的內容中充分體會到這一點；
另一方面，CoreOS 對特定的云環境也有相當的依賴，其啟動配置服務 cloud-init 是需要高度定制化的，CoreOS 官方提供了基于Vagrant、VMWare、AZure、AWS、RackSpace 等虛擬機或云服務提供商的定制版本，因此本地直接通過 ISO 安裝的 CoreOS 則無法獲得 cloud-init 相關的功能，比如集群的自發現和fleet的跨主機管理。

CoreOS 的用戶體驗

CoreOS 的核心思想來自于 Chrome 瀏覽器的用戶體驗：快速啟動，后臺更新，跨版本無縫更新，每個Tab頁采用獨立沙盒，單個Tab頁崩潰能快速修復，整個瀏覽器也不會因為單個沙盒進程的崩潰而崩潰。引申到服務器上，試想將一個應用托管在應用容器中的服務從一個服務器轉移到另一個服務器上，就像用鼠標將 Tab 頁從一個瀏覽器拖拽到另一個瀏覽器界面上那樣簡單。而這些，正是 CoreOS 希望帶給每一個用戶的體驗。

更快的啟動速度

因為輕，所以快。做為現代網絡的服務器的產物，CoreOS 團隊對這個服務器操作系統做了最大的精簡，結果不僅使得系統與應用高度分離，更獲得了極大的啟動速度提升。根據官方數據，其系統運行時內存使用量只有114M（作者注：這是官方數據，實測在Vagrant環境下只有大約80M，比宣傳的還要低），只有常見 Linux 服務器系統的一半略多 (約60%)。

此外，CoreOS 使用經 Mac 系統 launchd 的啟發而開發的 Systemd 作為默認系統啟動和服務管理器 (CentOS 7 也使用 Systemd 取代了過去的 SysV 啟動服務)。與 SysV 相比，Systemd 不但可以更好的追蹤系統進程，而且也具備優秀的并行化處理能力，加之按需啟動等特點，并結合 Docker 的快速啟動能力，在 CoreOS 集群中大規模部署 Docker Containers 與使用其他操作系統相比在性能上的優勢將更加明顯。

平滑版本升級

傳統的服務器操作系統，包括大多數Linux發行版，每隔幾年都會更換。在這期間，開發者會不斷用安全補丁和更新完善這個系統，但是不會進行特別大的改動，最終這個操作系統以及其上的軟件會慢慢僵化。但是 CoreOS 的思想是成為一個隨時可被更新的操作系統，其本身沒有跨發布版本升級的概念，而是使用了類似 Arch Linux 的升級通道(Update Channel)和滾動更新的方式，在任何時候系統都能夠直接升級成最新的發布版本。甚至在整個更新的過程中，應用程序的運行不會被打斷。有了 CoreOS，基礎架構會自動升級，就像無需用戶操心的 Chrome 瀏覽器升級一樣。

CoreOS 有兩個系統分區 (dual root partition 有些地方翻譯為雙啟動分區，這里實際上應該是系統分區，包括 /bin /sbin /lib 等目錄，這些目錄都是只讀的)。兩個分區分別被設置成主動模式和被動模式并在系統運行期間各司其職。主動分區負責系統運行，被動分區負責系統升級。一旦新版本的操作系統被發布，一個完整的系統文件將被下載至被動分區，并在系統下一次重啟時從新版本分區啟動，原來的被動分區將切換為主動分區，而之前的主動分區則被切換為被動分區。這個個過程中，被更新的機器不需要從負載集群中移除。同時，為了保證其它應用程序不被打斷，CoreOS 會通過 Linux cgroups 限制更新過程中的硬盤和網絡I/O。

這里值得一提的是，與傳統 Linux 服務器不同，CoreOS 的系統分區被設計成在系統運行期間保持只讀狀態，這樣確保了 CoreOS 的安全性，也進一步體現了 CoreOS 不希望用戶將應用軟件直接安裝在操作系統上的態度。同時，集群內高度一致的系統內核和外圍應用版本，簡化了由于版本問題帶來的操作復雜性，使得操作系統自身的維護更加容易。

應用容器化

在 CoreOS 中，所有應用程序都被裝在一個個 Docker 容器中，這些容器就像一個個軟件代碼的集裝箱，通過最簡單的接口運行在操作系統之上。這意味著它們可以被很輕松的在操作系統和計算機之間轉移，就像是在輪船和火車上搬運箱子一樣，同時也意味著可以在不中斷應用程序的情況下更新操作系統。

Docker 在開發者將應用部署到云基礎架構上時變得日益流行。通過容器化 (containerized) 的運算環境向應用程序提供運算資源，應用程序之間共享系統內核和資源，卻互不干涉運行。單個容器的故障能夠快速的重啟修復，并且容器內的應用故障不會引起整個系統的崩潰。這個思想和瀏覽器的沙盒是如出一轍的。

CoreOS 的分布式系統服務

云的問題，最主要是由集中式到分布式思考方式的轉變，分布式服務、分布式部署、分布式管理、分布式數據存儲… 而這些都是 CoreOS 帶給服務器革命的一部分。

為了從系統層面上解決這些分布式思維所面臨的問題，CoreOS 團隊提供了一些重要的工具幫助用戶管理 CoreOS 集群以及部署 Docker 容器。

Cloud-init

在系統啟動時，CoreOS 會讀取一個平臺定制的用戶配置文件 (稱為 cloud-config) 完成系統的初始化配置。通過配置中的信息，新啟動 CoreOS 服務器將初始化必要的服務進程，并自動發現并指定集群的其他服務器交互信息，然后加入這個集群中。這種基于集群的“自發現”組織方式使得集群管理變得簡單且高效。

通常來說，cloud-config 配置文件至少應當包括服務器所屬的集群通信地址，以及啟動 etcd 和 fleet 所需服務的參數。用戶可以根據需要，在配置中添加更多定制化的服務，使得節點啟動后立即成為功能完備的集群成員投入運行。

Etcd

在CoreOS 集群中處于骨架地位的是 etcd。 etcd 是一個分布式 key/value 存儲服務，CoreOS 集群中的程序和服務可以通過 etcd 共享信息或做服務發現。etcd 基于非常著名的 raft 一致性算法：通過選舉形式在服務器之中選舉 Lead 來同步數據，并以此確保集群之內信息始終一致和可用。etcd 以默認的形式安裝于每個 CoreOS 系統之中。

在默認的配置下，etcd 使用系統中的兩個端口：4001和7001，其中4001提供給外部應用程序以HTTP+Json的形式讀寫數據，而7001則用作在每個 etcd 之間進行數據同步。用戶更可以通過配置 CA Cert讓 etcd 以 HTTPS 的方式讀寫及同步數據，進一步確保數據信息的安全性。

Fleet

fleet 是一個通過 Systemd對CoreOS 集群中進行控制和管理的工具。fleet 與 Systemd 之間通過 D-Bus API 進行交互，每個 fleet agent 之間通過 etcd 服務來注冊和同步數據。fleet 提供的功能非常豐富，包括查看集群中服務器的狀態、啟動或終止 Docker 容器、讀取日志內容等。更為重要的是 fleet 可以確保集群中的服務一直處于可用狀態。當出現某個通過 fleet 創建的服務在集群中不可用時，如由于某臺主機因為硬件或網絡故障從集群中脫離時，原本運行在這臺服務器中的一系列服務將通過fleet 被重新分配到其他可用服務器中。雖然當前 fleet 還處于非常早期的狀態，但是其管理 CoreOS 集群的能力是非常有效的，并且仍然有很大的擴展空間，目前已提供簡單的 API 接口供用戶集成。