CoreOS實戰

CoreOS 實戰

(第 2 版) [美] Matt Bailey	著
蒲 成	譯

北 京
Matt Bailey
CoreOS in Action
EISBN: 978-1-61729-374-0
Original English language edition published by Manning Publications, 178 South Hill Drive, Westampton,
NJ 08060 USA. Copyright©2017 by Manning Publications. Simplified Chinese-language edition copyright
© 2018 by Tsinghua University Press. All rights reserved.
本書中文簡體字版由 Manning 出版公司授權清華大學出版社獨家出版。未經出版者書面許可，不得以任
何方式複製或抄襲本書內容。
版權所有，侵權必究。
北京市版權局著作權合同登記號 圖字： 01-2017-7949
本書封面貼有清華大學出版社防偽標籤，無標籤者不得銷售。
版權所有，侵權必究。侵權舉報電話： 010-62782989 13701121933
圖書在版編目 (CIP) 資料
CoreOS 實戰 / (美) 馬特·貝利(Matt Bailey) 著；蒲成 譯. —北京：清華大學出版社， 2018
書名原文： CoreOS in Action
ISBN 978-7-302-49452-2
Ⅰ. ①C… Ⅱ. ①馬… ②蒲… Ⅲ. ①作業系統 Ⅳ. ①TP316
中國版本圖書館 CIP 資料核字(2018)第 020929 號
責任編輯：王 軍 於 平
裝幀設計：思創景點
責任校對：曹 陽
責任印製：劉海龍
出版發行：清華大學出版社
網 址： ，
地 址：北京清華大學學研大廈 A 座 郵 編： 100084
社 總 機： 010-62770175 郵 購： 010-62786544
投稿與讀者服務： 010-62776969， c-service@tup.tsinghua.edu.cn
質 量 反 饋： 010-62772015， zhiliang@tup.tsinghua.edu.cn
印 裝 者：三河市少明印務有限公司
經 銷：全國新華書店
開 本： 185mm×260mm 印 張： 11.25 字 數： 274 千字
版 次： 2018 年 2 月第 1 版 印 次： 2018 年 2 月第 1 次印刷
印 數： 1～4000
定 價： 49.80 元
—————————————————————————————————————————————
產品編號： 075915-01
謹以本書獻給我的妻子 Jenn 以及我的孩子 Adam 和 Melanie。

譯 者 序
DevOps 和容器化差不多是目前 IT 行業最熱門的兩個詞。這要歸因於軟體行業日益清
晰地認識到，為了按時交付軟體產品和服務，開發和運營工作必須緊密合作。特別是在如
今移動網際網路和大資料分析應用大行其道的背景下，如何成為一名真正的消費者使用者並且
像消費者使用者那樣來考慮整件事情的意義，就成為各個企業追求的目標。而 DevOps 和容
器化正是為了實現這一目標而被廣泛應用的工具。
CoreOS 正是在此背景下誕生的， 它是一個基於 Docker 的輕量級容器化 Linux 發行版，
專為大型資料中心而設計，旨在透過輕量級系統架構和靈活的應用程式部署能力降低資料
中心的維護成本和複雜度。 CoreOS 作為 Docker 生態圈中的重要一員，日益得到各大雲服
務商的重視，目前所有的主流雲服務商都提供了對 CoreOS 的支援，其發展風頭正勁。
CoreOS 是為了計算機叢集的基礎設施建設而誕生的，專注於自動化、輕鬆部署、安全、可
靠和規模化。作為一個作業系統， CoreOS 提供了在應用容器內部署應用所需的基礎功能環
境，以及一系列用於服務發現和配置共享的內建工具。
本書從 CoreOS 的基礎組成部分開始， 深入淺出地講解了 CoreOS 在私有化部署和雲端
部署的完整步驟，從而為讀者描述了以 CoreOS 為基礎的完整生態。如果讀者之前從未接
觸過 CoreOS，那麼相信讀者在閱讀完本書之後，會對 CoreOS 有一個全面的認識，並且具
備部署 CoreOS 和在其上構建應用程式棧的基本能力。
本書側重於介紹 CoreOS 的元件、特性以及部署方式，並輔之以從易到難的示例，以
便讀者可以動手實踐，從而由淺入深地瞭解 CoreOS 的方方面面。透過這些示例，本書也抽
絲剝繭般闡述了 CoreOS 作為一種整合方式如何從其所執行的計算資源池中提取抽象，這樣，
開發運營人員就能專注於應用和服務，而不會受到 OS 本身各種依賴項的干擾了。作為一本
CoreOS 實戰類書籍，本書的內容完全可以滿足需要進行 CoreOS 實踐的使用者的需求。
在此要特別感謝清華大學出版社的編輯，在本書翻譯過程中他們提供了頗有助益的幫
助，沒有其熱情付出，本書將難以付梓。
本書全部章節由蒲成翻譯，參與翻譯的還有何東武、李鵬、李文強、林超、劉洋洋、
茆永鋒、潘麗臣、王濱、陳世佳、申成龍、王佳、趙棟、潘勇、貟書謙、楊達輝、趙永蘭、
鄭斌、楊曄。
由於譯者水平有限，難免會出現一些錯誤或翻譯不準確的地方，如果有讀者能夠指出
並勘正，譯者將不勝感激。
譯 者

致 謝
我要感謝 Manning 出版社聯絡我編寫本書，並且我要表達對於出版人 Marjan Bace 的
謝意，還要感謝 Cynthia Kane 在本書的長時間編寫過程中給予我的指導，感謝 Ivan
Kirkpatrick 在對本書技術評審過程中所進行的非常細緻的工作，感謝 Tiffany Taylor 幫助推
動越過終點線的最後一部分內容形成文字，並且要感謝編輯和製作團隊的每一個人，其中
包括 Janet Vail、 Katie Tennant、 Dottie Marsico，以及許多在幕後工作的人。此外，我還想
感謝#gh 和#omgp 中的所有朋友，你們總是在激勵我前進。
我無法用言語來感謝由 Ivan Martinovic 領導的技術評審部門，你們是非常棒的團隊，
其中包括 Michael Bright、 Raffaello Cimbro、 Luke Greenleaf、 Mike Haller、 Sriram Macharla、
Palak Mathur、 Javier Muñoz Mellid、 Thomas Peklak、 Austin Riendeau、 Kent Spillner、 Antonis
Tsaltas、 Filippo Veneri 以及 Marco Zuppone，還要感謝天賦甚高的論壇貢獻者。他們的貢獻
包括，找出了技術性錯誤、專業術語錯誤、打字錯誤，並且提供了主題建議。每一輪評審
過程以及透過論壇主題而實現的每一批反饋，都幫助到本書的成形。

前 言
正如本書的許多讀者一樣，我也是作為 Linux 和 UNIX 系統以及網路的系統管理員而
開啟技術行業職業生涯的。另外，就像許多人一樣，我從未對可用的自動化程度感到滿意
過，也從未對其無條件信任過。我們中的一些人或多或少使用過 CFEngine、 Puppet 和 Chef
來進行管理，並且使用我們的技術進行更嚴謹的工程設計和承擔較少的系統管理工作。之
後容器變得流行起來，並且 CoreOS 的釋出大規模地填平了容器與系統管理之間的溝壑。
我是在 2013 年末 CoreOS 剛剛問世時開始使用它的。它是一款大部分系統管理員都認
為遲早會出現的 OS。它提供了一種整合方式，以便將服務編制為從其所執行的計算資源
池中提取的抽象。 Manning 出版社在 2015 年末開始聯絡我，想要知道我是否有興趣編寫一
本 CoreOS 方面的書籍，我接受了這個提議並且開始奮筆疾書。當我由於這個專案而無法
在業餘時間陪伴我的孩子們時，我也感到愧疚。這是我的第一本書，我發現，內容構思以
及在 Vim 中輸入這些內容並不是最難的部分，最難的是同時找到充滿動力的書籍編寫時間
和不受打擾的自由時間。而這種情況很少會同時出現，尤其是在家有幼兒的情況下。
我希望《CoreOS 實戰》能夠引導讀者並且為讀者帶來一些挑戰。從某種程度上說，這
本書的內容發展遵循了我職業生涯的發展軌道以及此技術領域的發展軌道。具體而言，
CoreOS 和類似的系統都旨在將單調乏味的運營工作轉變成軟體開發，並且將系統管理救火
式的工作轉變成宣告式的工程設計。因此，《CoreOS 實戰》是從基礎組成部分開始介紹的，
並且以完整的軟體棧作為結束。
關於本書
《CoreOS 實戰》為應用程式架構、系統管理員以及尋求如何在不犧牲開發工作流或者
運營簡單性的情況下進行規模化計算的資訊的人提供了一個有效資源。CoreOS 及其元件套
裝提供了一種切實可行的方法來進行系統設計，其中高可用性、服務發現以及容錯性變得
不難實現，並且從一開始就成為核心基礎設施和應用程式架構的組成部分。 CoreOS 和它所
倡導的概念對於開發人員和運營專家來說都是有用的， CoreOS 意識到在某種程度上容器
化的意圖正變得更易於投入運營、維護和迭代。
如果讀者正在閱讀本書，那麼大概已經注意到了，技術領域的普遍行動就是分解豎
井並且將開發和運營這兩方面結合到一起。在許多組織中，運營專家和應用程式架構師
的角色正在被結合成一個角色，例如開發運營(DevOps)或者站點穩定工程(Site Reliability
Engineering)。因而，一些人可能最終面臨知識缺口。有時候，本書可能看起來使用更高階
的主題組合了對讀者而言顯而易見的資訊，不過那是因為我在嘗試為可能不具備成功使用
CoreOS 所需的部分基礎知識的人提供完整的全域性觀念。
本書讀者物件
本書的讀者物件是系統管理員、軟體工程師以及對構建可擴充套件容錯系統感興趣的人。
本書研究了使用 CoreOS 進行運營化和構建服務的軟體架構；如果讀者有興趣瞭解構建可
擴充套件的具有容錯性的系統，那麼本書就是很好的資料來源。
本書中並沒有大量的功能性程式碼——我基本上是在介紹配置檔案以及一些用於
Amazon Web Services 的 YAML 模板。對於 Bash 和通用 Linux 系統管理的基礎理解應該就
足以讓讀者入門了。在本書後面的內容中，會提供具有 JavaScript 前端的 Node.js 示例，不
過 JavaScript 經驗並不是必要的。
在描述本書章節之前，先介紹一些技術背景知識。
背景介紹
大約從 2008 年開始，擴充套件系統以便滿足組織顧客的需要已經催生了包括服務、工具
和諮詢公司的整個行業。這些行業的最終目標一直都是管理具有較少資源的更大規模的系
統——並且要非常快速地進行管理。這些平臺即服務(Platform-as-a-Service， PaaS)、基礎設
施即服務(Infrastructure-as-a-Service， IaaS)以及配置管理套件都旨在將系統管理的重擔轉換
成自動化系統，這樣組織才能“輕易地”從規模化目標中將 IT 人力資源釋放出來。其理念
可以用一個比喻來形容(這個比喻是由 Bill Baker 提出的，這是我能找到的最貼切的比喻)，
我們應該將基礎設施當作家畜而非寵物來對待。也就是說，計算資源單元是日用品或電器，
而非具有名稱的獨立的、精心維護的伺服器。當家畜出現問題時，我們會處理掉它們；而
在寵物生病時，我們需要對其進行護理以便它們恢復健康。我們應該充分利用自動化，並
且不應該過多關心是否必須進行重構；這樣做應該是容易並且可複製的。
不過現實情況是，嘗試達成這些可複製性和瞬時性目標通常會極其複雜。這樣做的具
體方式會變成豎井邏輯和工作流的黑盒，即使是在使用廣泛引用的工具也會如此。像 Chef
和 Puppet這樣的配置管理系統對於此複雜性而言尤其脆弱——不是因為它們的設計就是如
此，而是因為組織通常會遇到阻礙(技術性和非技術性的)，而這些阻礙的最終解決都是以
與這些工具的最佳實踐完全無關的方式來處理的。在 IaaS 領域，組織通常會像處理其現場
資源那樣處理其公有云計算資源，這主要是因為 IaaS 具有允許這樣做的靈活性，即使這樣
做會導致系統不可維護。下面介紹容器。
容器
LXC 是在 Linux 使用者空間中建立虛擬化執行時的早期實踐。 與 chroots 和 jails 相比較，
它是一種比較重的抽象，但又比完全虛擬化輕。在 Docker 於 2013 年推出並且圍繞 LXC 技
術增加大量特性之前，很少有人使用過或者聽說過 LXC，最終， Docker 用自己的元件完全
替換了 LXC 的元件。在我看來，大體而言， Docker 和容器化解決了虛擬化打算解決的問
題：關注點的簡單隔離、系統的複製以及不可變的執行時狀態。其優勢很明顯：依賴性管
理變得被輕易包含其中；執行時是標準化的；並且其方法對開發人員足夠友好，開發和運
營可以使用相同的工具，且每個位元組都在使用同一容器。因此，我們已經越來越少地聽到
“它僅對我適用，而不適用於生產”這樣的話了。 CoreOS 在某種程度上正是此計算模型的
運營化，它利用了在通用、分散式系統模型中容器化的優勢。
本書從頭至尾都在介紹如何利用此計算模型的優勢。讀者將瞭解如何同時在原型環境
和雲端生產環境中部署和管理 CoreOS。還將瞭解到如何設計和調整應用程式棧以便它能在
此上下文中很好地執行。除了該 OS，還將詳細介紹 CoreOS 的每個元件及其應用： etcd 用
於配置和發現， rkt 用於另一種方式的容器執行時， fleet 用於分散式服務排程， flannel 用於
網路抽象。
分散式計算並非新概念；許多用於分散式系統的模型和軟體包自從計算的廣泛應用開
始就已經問世了。不過這些系統中的大多數模型和軟體包都不為人所知，具有高度的專屬
權，或者隔絕在像科學計算這樣的特定行業中。最老的一些設計如今仍然存在的唯一原因
就是支援 20 世紀 70 年代的遺留系統，它們為大型機和小型機驅動著分散式計算。
CoreOS 背後的歷史與推動因素
單系統映像(Single System Image， SSI)計算的概念是一種 OS 架構，自 20 世紀 90 年代
以來並沒有看到它有多麼活躍，它只在一些長期支援遺留系統的場景中得到了應用。 SSI
是一種架構，它將叢集中的多臺計算機作為單一系統來提供。其中有單一的檔案系統、通
過共享執行時空間來共享的程式間通訊(Interprocess Communication， IPC)，以及程式檢查
點/遷移。 MOSIX/openMosix、 Kerrighed、 VMScluster 和 Plan 9(原生支援的)都是 SSI 系統。
Plan 9 上大概曾進行過大部分當前的開發活動，這應該表明了此計算模型當初的流行性。
SSI 的主要缺陷在於，首先，這些系統通常難以配置和維護，並且並非旨在實現通用
性。其次，該領域的發展已經明顯停滯了： SSI 中沒有什麼新東西出現，並且它已經無法
跟上發展以用作一個流行模型。我認為這是因為科學和其他大資料計算已經擁抱了網格計
算，比如像 Condor、 BOINC 和 Slurm 這樣的批處理操作模型。這些工具旨在在叢集中運
行計算任務並且交付結果； SSI 的共享 IPC 無法為這些應用程式提供多少好處，因為資料
傳輸的(時間)成本超過了阻塞式批處理過程的成本。在應用程式服務棧的領域中，透過像
HTTP 這樣的協議的抽象以及分散式佇列也讓人們不再值得對共享 IPC 進行投入。
目前，對於分散式計算而言，問題域是如何有效管理大規模的系統。無論我們是在使
用 Web 棧還是分散式批處理，可能都不需要共享 IPC，不過 SSI 帶來的其他內容具有更多
顯而易見的價值：共享檔案系統意味著我們僅需要配置一個系統，並且程式檢查點和遷移
意味著結點都是可丟棄的並且“更類似家畜”。在不使用共享 IPC 的情況下，這些解決方
案會難以實現。一些組織轉而使用將配置應用到多臺機器的配置管理系統，或者設定複雜
的具有完全自定義邏輯的監控系統。根據我的經驗來看，配置管理系統無法達成目標，因
為它僅會完全確保執行時的所有狀態；在它們執行完成之後，狀態就會變成未知。這些系
統更專注於可複製性而非一致性，這是一個好的目標，但無法提供透過分散式檔案系統進
行共享配置的可靠性。嘗試同時管理程式的監控系統通常要麼特定於應用程式，要麼難以
實現和維護。
無論是有意或無意，像 Docker 這樣的容器系統都為重新利用 SSI 的優勢奠定了基礎，
而不需要實現共享的 IPC。 Docker 確保了執行時狀態，並且提供了從 OS 中抽象出來的執
行模型。“不過，”大家可能會想，“這完全與 SSI 相反。現在每一個獨立的系統甚至都具有
了更為隔離的配置和執行時，而非共享式的！”的確，此方法是不相關的，不過它實現了相
同的目標。如果執行時狀態僅被定義一次(比如在 Dockerfile 中)，並且在整個容器生命週期
中都對其進行維護，那麼我們就達成單點配置的目標。並且，如果可以同時遠端和獨立於
其執行之上的 OS 與叢集結點來編制獨立程式狀態的話，我們就達成通用服務在叢集範圍
內的程式排程這一目標。
意識到那些可能性就是需要獨立於容器化系統之外的工具的地方。這正是 CoreOS 及
其系統套件發揮作用的地方。 CoreOS 提供了足夠的 OS 以供執行一些服務；其餘的都是由
etcd 和 fleet 的編制工作來處理的—— etcd 提供了分散式配置， 從中容器可以定義其執行時
特徵，而 fleet 管理著分散式初始化和容器排程。從內部看， CoreOS 也使用 etcd 來提供分
布式鎖以便自動管理 OS 升級，這轉而又會使用 fleet 在整個叢集中平衡服務，這樣結點就
可以自行升級了。
本書路線圖
第 1 章首先簡要介紹 CoreOS 生態系統。我提供了容器 OS 中核心繫統的一些闡釋，
以及一個並非真正旨在用於執行而是揭示這些部分如何適配到一起的簡要示例。
第 2 章介紹設定一個本地 CoreOS 環境的過程，我們將在本書大部分後續內容中使用
它作為沙盒。這也是人們在現實環境中使用的過程，以便為 CoreOS 構建元件，因此進一
步關注該章的內容會是一個好的做法。
第 3 章講解與 CoreOS 容錯性和系統升級的方式有關的內容，並且介紹設定一個容錯
性 Web 應用的處理步驟。我們在本書其餘內容中基於這個“Hello World”進行構建。
第 4 章探討了現實世界的需求和 CoreOS 生產部署的目標，以及與如何處理叢集中分
布式檔案系統選項有關的一個現實示例。
第 5 章會研究十二要素應用方法論以及如何將之應用到希望在 CoreOS 中部署的應用
程式棧上。該章會以如何在第 6 章中應用此方法論的概述作為結束。
第 6 章將第 3 章的示例擴充套件成一個具有許多層的更為真實的 Web 應用。 我們還將引入
一個持久化資料庫層。
第 7 章使用了第 6 章的持久化層並且深入探究瞭如何讓它具有容錯性和在所有叢集機
器中的可擴充套件性。
第 8 章深入研究 Amazon Web Services(AWS)中 CoreOS 的實踐部署。
第 9 章講解如何使用第 6 章和第 7 章中所構建的整個軟體棧，並且以自動化方式將它
部署到第 8 章所構造的 AWS 環境中。
第 10 章透過探討 CoreOS 的系統管理部分總結了本書內容， 其中包括日誌記錄、 備份、
擴充套件以及 CoreOS 的新 rkt 容器系統。
原始碼下載
本書中所有示例的原始碼，包括一些非常長的 AWS 模板，都可以在
books/coreos-in-action 下載。也可掃描封底的二維碼下載原始碼。
作者簡介
Matt Bailey 目前是 ZeniMax 的技術主管。他曾致力於高等教育行業，並且曾供職於科
學計算、醫療和網路技術公司，以及一些初創型公司。讀者可以透過 以線上
方式聯絡他。
作者線上
購買了《CoreOS 實戰》的讀者可以免費訪問 Manning 出版社所運營的一個私有網路
論壇，讀者可以在其中對本書進行評論，提出技術問題，並且接受來自作者和其他讀者的
幫助。要訪問該論壇並且進行訂閱，可以將 Web 瀏覽器導航到 books/
coreos-in-action。這個頁面提供了相關的資訊，其中包括如何在註冊之後登入該論壇，可
以得到哪些幫助，以及該論壇上的行為準則。
Manning 出版社對於讀者的承諾旨在提供一個場所，其中讀者與讀者之間以及讀者與
作者之間可以展開有意義的對話。作者方面的參與程度是無法得到保證的，但對於作者在
線的貢獻仍舊是自願的(並且免費的)。我們建議讀者嘗試向作者提出一些具有挑戰性的問
題以免他沒興趣關注！
只要本書還在印刷，就可以從出版商的網站上訪問作者線上論壇和前述探討內容的歸檔。
本書封面介紹
《CoreOS 實戰》封面上的圖畫是一個“敘利亞苦行僧”。穆斯林苦行僧生活在宗教團
體中，他們與世隔絕並且過著物資匱乏且冥想式的生活；他們是眾所周知的智慧、醫藥、
詩歌、啟迪和妙語的源泉。該圖例來自於倫敦老邦德街的 William Miller 於 1802 年 1 月 1
日出版的奧斯曼帝國服裝圖集。該圖集的扉頁已經丟失，並且我們至今都無法找到它的下
落。這本書的目錄同時使用英語和法語來標識插圖，每張插圖都有創作它的兩位藝術家的
名字，他們無疑一定會為自己的作品被裝飾到 200 年後的一本計算機程式設計書籍的封面上而
感到驚訝。
自那時起，衣著習慣已經改變了，當時如此豐富的地區多樣性已經逐漸消失。如今通
常從衣著很難區分不同國家的居民。也許，嘗試從樂觀的角度來看，我們已經用文化和視
覺上的多樣性換來了更為多樣化的個人生活——或者說是更為豐富以及有趣的知識技術生
活。 Manning 出版社的同仁崇尚創造性、進取性，這個圖集中的圖片使得兩個世紀以前豐
富多彩的地區生活躍然於紙上，以其作為圖書封面會讓計算機行業多一些趣味性。
目 錄
第Ⅰ部分 增進了解 CoreOS
第 1 章 CoreOS 家族介紹 ···················· 3
1.1 迎接 CoreOS ·······························3
1.1.1 CoreOS 家族···························· 4
1.1.2 etcd 和分散式配置狀態 ·········· 5
1.1.3 fleet 和分散式服務狀態 ·········· 6
1.1.4 充當 CoreOS init 系統
的 systemd ······························· 6
1.1.5 Docker 和/或 rkt，容器
執行時 ····································· 6
1.1.6 使用 cloud-config 進行
初始化配置 ····························· 7
1.2 將核心服務裝配到一起··············7
1.2.1 CoreOS 工作流························ 8
1.2.2 建立和執行服務······················ 9
1.2.3 建立單元檔案························ 10
1.2.4 服務拓撲和故障轉移 ············ 12
1.3 本章小結 ···································14
第 2 章 在工作站上開始研究 ·············· 15
2.1 設定 Vagrant······························15
2.1.1 需求和設定 ··························· 16
2.1.2 設定 Vagrant 並且執行它······ 17
2.1.3 讓 CoreOS 叢集在 Vagrant 中
執行 ······································· 20
2.2 用於與 CoreOS 互動的工具 ·····21
2.2.1 fleetctl ···································· 22
2.2.2 etcdctl ···································· 26
2.2.3 Toolbox 容器 ························· 27
2.2.4 Linux 管理員的概念轉換······ 28
2.3 本章小結 ···································29
第 3 章 可預期的故障： CoreOS 中的
容錯 ·······································31
3.1 監控的當前狀態 ·······················31
3.1.1 有何不足······························· 32
3.1.2 CoreOS 的處理有何不同······ 33
3.2 服務排程與發現 ·······················34
3.2.1 部署生產環境 NGINX
和 Express ····························· 35
3.2.2 將 etcd 用於配置··················· 35
3.3 進行一些破壞 ···························40
3.3.1 模擬機器故障 ······················· 40
3.3.2 自修復··································· 41
3.4 應用程式架構和 CoreOS··········42
3.4.1 常見陷阱······························· 42
3.4.2 新專案和遺留專案················ 43
3.4.3 配置管理······························· 43
3.5 本章小結 ···································43
第Ⅱ部分 應用程式架構
第 4 章 生產環境中的 CoreOS···········47
4.1 規劃和部署選項 ·······················47
4.1.1 Amazon Web 服務················· 48
4.1.2 使用內部 VM 基礎設施 ······· 50
4.1.3 在裸機上······························· 50
4.2 與網路有關的注意事項············50
4.2.1 網路的可程式設計程度有多大···· 51
4.2.2 使用 flannel 啟動和執行······· 52
4.3 我們的大容量儲存在何處········55
4.3.1 資料系統背景 ······················· 55
4.3.2 NAS 和儲存外包··················· 56
4.3.3 Ceph······································· 57
4.4 本章小結 ···································61
第 5 章 應用程式架構和工作流 ·········· 63
5.1 應用程式和十二要素方法論 ····63
5.1.1 CoreOS 的方法······················ 64
5.1.2 架構檢查清單························ 65
5.2 軟體開發週期 ···························66
5.2.1 程式碼庫和依賴性···················· 66
5.2.2 環境邏輯和微服務················ 67
5.2.3 應用程式外沿························ 69
5.3 本章小結 ···································69
第 6 章 Web 棧應用程式示例 ············ 71
6.1 示例範圍 ···································71
6.1.1 這個應用程式會做些什麼 ···· 72
6.1.2 應用架構概覽························ 73
6.1.3 目標環境 ······························· 74
6.2 設定持久化層 ···························75
6.2.1 Couchbase 設定 ····················· 75
6.2.2 設定 memcached···················· 77
6.3 應用程式層 ·······························79
6.3.1 工作執行緒 ······························· 80
6.3.2 Web 應用 ······························· 83
6.4 由此向何處發展························89
6.4.1 對故障進行響應···················· 89
6.4.2 遺漏了什麼 ··························· 90
6.5 本章小結 ···································91
第 7 章 大資料棧 ······························· 93
7.1 本章示例的範圍························93
7.1.1 架構的增加項························ 94
7.1.2 新的資料來源 ··························· 95
7.2 新的棧元件 ·······························95
7.2.1 Twitter 資料收集器 ··············· 96
7.2.2 編制 Couchbase ····················· 98
7.2.3 啟動和驗證 ························· 105
7.2.4 啟動工作執行緒······················ 106
7.3 破壞我們的棧 ·························108
7.3.1 監測故障····························· 108
7.3.2 恢復機器····························· 108
7.4 本章小結 ·································109
第Ⅲ部分 生產環境中的 CoreOS
第 8 章 AWS 上的 CoreOS ··············113
8.1 AWS 背景介紹························ 114
8.1.1 AWS 地區和正常執行
時間 ································ 114
8.1.2 AWS 服務 ··························· 115
8.1.3 本章必要條件 ····················· 115
8.1.4 CloudFormation 模板 ·········· 116
8.1.5 AWS 中的雲配置················ 126
8.1.6 部署····································· 129
8.2 本章小結 ·································132
第 9 章 整合到一起：部署 ················133
9.1 新的 CloudFormation 物件 ·····134
9.1.1 引數和輸出 ························· 134
9.1.2 AWS Lambda······················· 135
9.1.3 API Gateway ······················· 137
9.1.4 更新棧································· 138
9.2 部署應用 ·································139
9.2.1 Web sidekick························ 139
9.2.2 初始化部署 ························· 140
9.3 自動化部署 ·····························142
9.3.1 Docker Hub 設定················· 142
9.3.2 推送變更····························· 143
9.4 本章小結 ·································144
第 10 章 系統管理 ····························145
10.1 日誌記錄和備份····················145
10.1.1 設定日誌························· 146
10.1.2 更新雲配置····················· 146
10.1.3 單元中的 awslogs ··········· 147
10.1.4 瀏覽日誌························· 148
10.1.5 備份資料························· 149
10.2 系統擴充套件 ·······························151
10.2.1 叢集擴充套件························· 152
10.2.2 擴充套件分割槽 ························· 153
10.2.3 遷移服務 ························· 153
10.3 CoreOS 展望··························154
10.3.1 新的工具························· 155
10.3.2 rkt···································· 155
10.4 本章小結 ·······························159

第 Ⅰ部分
增進了解 CoreOS
在前三章中，大家將瞭解 CoreOS 到底是什麼。我將介紹一些專業術語以及組成 CoreOS
的系統，並且讓大家掌握和執行一個沙盒環境。大家還將開始著手處理要貫穿本書而構建
的一個應用程式棧。

第 1 章
CoreOS 家族介紹
本章內容：
● CoreOS 系統和概念概覽
● 理解 CoreOS 的常見工作流模式
● fleet 和 etcd，以及 systemd 單元介紹
假定你被一家新公司所僱用，並且該公司希望你為其開發人員構建一套現代的基礎設
施以及運維架構。該公司具有許多不同的應用程式棧，並且對於水平可擴充套件性和高可用性
具有強烈的需求。我們知道我們想要使用 Linux，但是所面臨的維護無窮無盡的作業系統
更新和變更或者設定複雜的配置管理系統的局面會令人不快。我們清楚，容器化可以讓這
一局面變得簡單很多——我們可以將操作性配置從應用程式中分離出來——但我們仍舊需
要面對如何大規模管理所有那些容器的難題。現如今大量的發行版軟體都支援 Docker，但
其支援方式卻並非旨在用於大規模生產應用。
進入 CoreOS：這是一個自底向上的設計，以便幫助解決任意規模的容器操作化問題的
作業系統。它具有高容錯性並且是極其輕量級的，另外，它也展現出很高的效能，不過要
如何上手使用它呢？我們都清楚該目標：我們希望將一種基於容器的平臺作為服務提供給
我們的工程師，並且我們知道 CoreOS 可以成為這樣的一種利器。但是如何才能讓它執行
起來呢？如何才能改寫或設計應用程式架構以便最好地利用這個系統的優勢呢？
提示： 如果我們希望更多地瞭解 CoreOS 中的理念源自何處，則務必要閱讀本書前言
中的“背景介紹”一節。
在本章中，我們將詳細介紹組成 CoreOS 家族的系統的各個部分，並將簡要介紹它們
如何解決基礎設施和架構問題，比如剛才所描述的那些問題。閱讀完本章，讀者將清晰地
理解 CoreOS 以及其核心元件是如何適配到一起的，同時讀者也會了解一些關於其實用程
序的知識，這些知識在第 2 章探討構建一個本地叢集時將發揮作用。
1.1 迎接 CoreOS
CoreOS 的到來可以解決我們的規模化、可用性以及部署工作流的問題。在本章中，
我們將介紹 NGINX(一種流行的 HTTP 伺服器)的一個簡單應用程式部署，以便揭示出
CoreOS 如何實現其中一些解決方案，另外我們還將檢視一些必要的系統。有了 CoreOS，
我們就不必管理包，發起漫長的升級過程，規劃複雜的配置檔案，擺弄許可權，規劃重要
的(用於 OS 的)維護視窗，或者應對複雜的配置模式變更。如果我們完全擁抱 CoreOS 的
特性，那麼我們的結點叢集就將一直具有該 OS 的最新版本，並且我們將不再需要任何停
機時間。
當我們剛開始接觸到 CoreOS 時，這些理念可能會難以領會，但它們具化了啟動之後
永恆不變的 OS 的思想體系，這樣就帶來一種前所未有的使用 OS 的體驗。 CoreOS 的分
布式排程器 fleet 會管理應用程式棧的狀態，並且 CoreOS 提供了一個平臺，可以讓那些
系統在平臺上詳細組織服務。如果讀者具有電腦科學的背景知識，則可以將傳統的配
置管理系統視作嚴重依賴於持續操作 OS 狀態而產生的副作用，而在 CoreOS 中， OS
的狀態會在啟動時一次性建立，絕不會變更，並且在關機時才丟失。這是一個強有力的
概念，它會強制架構具有高度的冪等性且沒有任何潛藏的副作用，其結果就是，極大地
提升了關於系統可靠程度的確定性，並且大幅減少了對於監控和管理 OS 的複雜工具層
的需要。在這一節中，我將概要介紹讓 CoreOS 運轉起來的各個部分以及這些部分是如何
互補的。
CoreOS 背景
CoreOS 基於一個 Linux 發行版本，在某種程度上說，基於 Gentoo Linux 。類似於 Google
的 Chrome OS 基於 Gentoo 一樣，這僅僅對於那些有興趣對 CoreOS 本身實施駭客行為的人
具有相關性，而這並非本書的內容範圍 ( 儘管本書確實是用於理解我們正在做些什麼的絕佳
指南 ) 。
這可能並非我們需要關心的內容，其原因較為複雜。 CoreOS 旨在提供少量充當一個輕
量級、分散式系統的服務； CoreOS 的主旨在於，它不會成為我們的障礙，並且它的配置在
啟動時就被固化了，這類似於容器。從整體來看，這幾乎完全不同於其他所有 Linux 發行
版本或者 OS 。在第 8 章中，我們將更深入地探究 cloud-config ，它描述了該 OS 的狀態，
其中大部分都與叢集發現和初始化在 fleet 外部管理的核心服務相關。
關於容器化
我們將研究如何才能調整容器以便讓其與 CoreOS 發揮最佳功效，不過讀者應該具
有一些使用 Docker 的經驗以及容器化的概念，以便最大程度地理解本書內容。讀者也
可以閱讀 Jeff Nickoloff 所著的 Docker in Action 一書 (Manning 出版社於 2016 年出版，
books/docker-in-action) 。
1.1.1 CoreOS 家族
CoreOS 由一些關鍵系統與服務構成， 這些系統與服務會管理它所宣稱要促成的所有可
擴充套件性和容錯性。圖 1.1 提供了其叢集佈局方式的高層次概覽。
我們將在下一節中較為詳細地研究其中的每一個元件，並且在本書後續內容中詳盡地
介紹它們，這代表構成 CoreOS 的關鍵系統：
● etcd 充當叢集的持久化配置狀態(參閱 1.1.2 節)。
● fleetd 充當叢集的分散式執行時排程器(參閱 1.1.3 節)。
● systemd 單元檔案是 fleetd 所依據的執行執行時的機制(參閱 1.1.4 節)。
● Docker 和 rkt 是常用的單元檔案將會執行的容器平臺。 CoreOS 旨在讓所有的運
行時在容器中發生，並且可以從這兩個平臺中選擇一個(或者組合使用這兩者；
參閱 1.1.5 節)。
圖 1.1 缺失的一個必要系統是 cloud-config，它用於設定機器的初始化配置狀態。相較
於理解 CoreOS 概念的必要條件，它在更大意義上是基礎設施配置的細節； 1.1.6 節會詳盡
地介紹它。

圖 1.1 CoreOS 配置
1.1.2 etcd 和分散式配置狀態
etcd 是一種高可靠的分散式鍵/值儲存。如果讀者熟悉 memcached 或者 redis，就會知
道它也與其類似，不過相較於效能，它更專注於(分散式)一致性和可靠性。可以透過自定
義命令列工具來訪問它，並且它是完全基於 RESTful 和 JSON 的。顧名思義， etcd 旨在分
發系統和服務配置。它是用於 fleet(CoreOS 的分散式排程器)的資料儲存。
fleet 和 CoreOS 使用 etcd 找出同等項，分發用於各種目的的鎖，並且在整個叢集中協
調執行中的 systemd 單元。儘管單就這方面來說它已經很有用了，但它還旨在成為儲存集
群中配置的位置。在本章稍後的示例中，我們將使用它註冊 NGINX 例項，以便用於可發
現的負載均衡器。
etcd 並不是為大型物件儲存或者強大的效能而設計的；其主要目的在於，讓叢集的狀
態單一化。除了設定初始化狀態的 cloud-config 之外，就沒有其他的(非瞬時)狀態存在於任
何特定的 CoreOS 結點上。 etcd 提供了一種方式，以便讓狀態成為作為整體計算機叢集的
一個屬性，而非任何離散結點的屬性。它也提供了一種公共匯流排，可以圍繞這條匯流排來設
計更高階的、可充分利用叢集單系統特性優勢的功能。
我們可以使用 etcd 的 CLI 工具 etcdctl 來操作它，或者使用像 curl 這樣的任意 HTTP
客戶端來操作它，不過後者通常需要大量更多的細節處理——這也是由於其普適性造成的。
我們將在本書後續的內容中研究 etcd 更為高階的使用和配置。
1.1.3 fleet 和分散式服務狀態
fleet 與 etcd 就像一枚硬幣的兩面。 fleet 使得 CoreOS 可以透過在整個 CoreOS 叢集中
智慧分發 systemd 單元來充當單臺機器，這是透過使用 etcd 分發這個狀態來實現的。在整
個叢集中，我們可以輕易地告知 fleet 啟動任意數量的服務單元，並且它將所請求的內容在
整個叢集中均勻分發或者基於一些單元檔案的擴充套件配置來分發，我們將在本章後續內容中
簡要探討這一點。
這就是 CoreOS 的優勢開始顯露出來的地方。我們可以藉助 fleet 來充分利用 CoreOS 集
群大小的優勢，以便同時達成功能和高可用性的目標，並且開始將我們的整個部署用作單個
資源池。在整本書中，我們將進一步研究關於 fleet 的細節以及它與單元檔案互動的方式。
1.1.4 充當 CoreOS init 系統的 systemd
systemd 是一個較新的 init 系統， 它旨在顯著應對比傳統的 sysvinit 系統多得多的特性。
許多認為它處理的事情過多的使用者或者認為它與他們所想的 init 系統所應該有的設計方式
背道而馳的使用者，都會覺得這是值得詬病的一點。不過，它已經獲得了巨大的推動力——
足以讓大多數 Linux 發行版本已經切換到或者將會切換到 systemd。
CoreOS 廣泛地使用了 systemd，並且我們需要理解和編寫 systemd 單元檔案以便在
CoreOS 中執行服務。當然，關於如何使用 systemd，已經有了大量的文件可供借鑑。我不
會在本書中非常詳細地介紹它，而是會專注於我們需要知道的關於讓 systemd 和單元檔案
在 CoreOS 中發揮作用的內容。我們還將學習如何使用 fleet 對於 systemd 的擴充套件，以便讓
我們的單元能夠感知到叢集；並且我們將學習 fleet 與 systemd 日誌的互動方式，這對於理
解在 CoreOS 中日誌記錄如何工作是至關重要的。
1.1.5 Docker 和 / 或 rkt ，容器執行時
Docker 和 rkt 都是 CoreOS 中用於我們服務的受支援的執行時。 rkt 是由 CoreOS 開發
人員所開發的一個較新的容器系統。
首先澄清一點， CoreOS 同時支援 Docker 和 rkt 執行時環境； rkt 也可以執行 Docker
容器，這是與構建它時所要支援的應用程式容器(app container， appc)規範映像(ACI)保持一
致的。 rkt 的構建是為了驅動更為健壯的許可權隔離以及更易於與 Linux init 系統整合。它不
具有 Docker 使用的守護程式，並且它依賴於我們用於管理容器程式控制的任意 init 系統。
當然，在 CoreOS 中這就是 systemd，但 rkt 可以在任何位置執行。
無論是選擇 rkt 還是 Docker(或者同時選擇這兩者)以便抽象出執行時， 我們從這些容器
系統中所獲得的東西都是完全在 CoreOS 中實現了的。總之，只要我們考慮遵循構造容器
化架構的最佳實踐，那麼容器執行時的瞬時特性就會變成我們從作為一個整體的叢集中抽
象狀態的方式。我們將在本書後續內容中更為深入地介紹 CoreOS 中的應用程式架構。
類容器 (container-like) 系統的簡要歷史
儘管像 Docker 這樣的容器系統最近已經變得極為流行 ( 這無疑要歸因於相對於其他實
現的大幅改進了的工具 ) ，但容器化並不是特別新的概念。 Docker 最初依賴於 LXC ，並且
像 chroot jails 、 FreeBSD jail 、 Solaris Zones 等這樣的系統已經出現很長一段時間了，這類
系統正是為了嘗試解決這些相同的問題。其目標是實現一個不需要完整虛擬機器硬體抽象的
抽象執行時，完整的虛擬機器硬體通常具有很高的開銷和運營成本。
在我看來， Docker 已經取得了成功，這是因為它帶來了高質量的工具套件，並且圍繞
該產品的社群已經發展壯大了。設定和執行 Docker 相對也很容易，而對於我們提及的其他
系統來說，情況就絕非如此了。
1.1.6 使用 cloud-config 進行初始化配置
CoreOS 的大部分 OS 配置都並非旨在可以被操作，除非我們是在為了開發而除錯該
OS 本身。 CoreOS 的配置範圍完全包含在 cloud-config 檔案中。
令人困惑的是， CoreOS 開發人員對這個系統的命名類似於其受啟發的系統： cloud-init，
它是被廣泛使用的、基於 YAML 的初始化配置系統。 cloud-init 並非 CoreOS 所特有的；如
果讀者具有在 AWS 或 OpenStack 中使用 Ubuntu 或 CentOS 的經驗，則會發現它無處不在。
開發人員通常使用 cloud-init 來引導其他像 Chef 和 Puppet 這樣較重的配置管理系統，但
CoreOS 打算讓 cloud-config 成為該 OS 配置真正意義上的單一源。使用 cloud-config 來引導
像 Chef 這樣的系統是可行的，但這樣做與 CoreOS 結點處於單一狀態和瞬時狀態的意圖背
道而馳。
最小化的 cloud-config 檔案通常由一個發現令牌和一些 SSH 金鑰構成。
相較於傳統的配置管理，為何要使用 cloud-config ？
CoreOS 構造 cloud-config 的好處在於，它是精心定製的，以便在 CoreOS 如何趨近於
OS 設計的背景下滿足初始化配置的需要。相較於學習與如何劃分發行版本以及管理配置
檔案有關的檔案系統佈局和細微差異，我們要面對的是，利用易於使用的配置抽象進行基
礎配置。
CoreOS 是全新設計的，以便不再具有任何超出可以在 cloud-config 中定義的內容的配
置需求，因此並不需要應對此任務的其他系統。例如，可以透過在 YAML 清單中列舉新的
服務單元來定義它們，而 cloud-config 將處理其餘的事情。
1.2 將核心服務裝配到一起
既然我們已經理解了讓 CoreOS 發揮作用的必要系統，那麼就來看一看它們是如何彼
此配合以便組織起來執行一個高可用服務的。我們將從很可能會在日常運營中遇到的工作
流開始講解，並且逐步建立起一個位於叢集中的示例 NGINX HTTP 伺服器。
應用程式棧的組織正是 CoreOS 及其工具為我們帶來大量強有力支援和靈活性的地方。
不過在我們可以構造複雜系統之前，需要學習這些工具是如何執行的。
1.2.1 CoreOS 工作流
設定一個基礎 NGINX 例項叢集的工作流看起來就像是圖 1.2 中的流程一樣。最好將
CoreOS 及其系統視作運營和基礎設施中容器典範的體現。擁抱瞬時性，並且忘掉與過去管
理伺服器方式有關的想法；它們大多數都不再適用了。將叢集視作達成目標的單一機制，
而非一組需要細心管理的裝置。一旦具備此思維模式，擴充套件向量就會變得顯而易見，並且
可以輕易實現容錯的可能性。
圖 1.2 表示一個基礎工作流：建立 Docker 或 rkt 容器和 systemd 單元來支援 NGINX
伺服器，使用 fleet 將單元提交到叢集，並且，基於單元檔案(或者未提供選項)指定的任何

圖 1.2 基礎工作流
選項， fleet 將判定服務應該在哪臺機器上執行。 fleet 具有兩個主要關注點：機器，也
就是叢集中的 CoreOS 結點(實際的物理伺服器或者虛擬機器)，以及單元，也就是它所管
理的 systemd 單元。具體而言，單元就是 systemd 服務的普通文字配置； fleet 會圍繞它
們新增上下文並且透過 etcd 來分發它們。在本書的其餘內容中，我將始終如一地使用這
些術語。當然，這裡還缺乏大量的細節，不過這就是 CoreOS 叢集上所有任務正常執行的
日常工作流。
我們從 CoreOS 中獲得的許多好處都來源於此部署模式。可以在 fleet 中將單元提交到
任何機器——它們全都處理完全相同的任務。如果一臺機器變得不可達，那麼 fleet 就會在
另一臺機器上執行 NGINX。如果想要執行至少兩個 NGINX 例項，那麼 fleet 就會根據引數
來恰當地分發它們。 fleet 是在整個叢集中將服務的執行時維繫在一起並且讓 CoreOS 成為
叢集感知系統的黏合劑。
“但是剩下的呢？”讀者可能會這樣問。在一個叢集中分發一個或多個程式並不是任
務的全部，我們將在下一節中使用一個簡要示例來更詳細地進行研究。應該從中汲取的經
驗就是：假設 CoreOS 叢集已經設定好並且正在執行(就像第 2 章中將探討的那樣)，並且
NGINX 伺服器已經容器化了，那麼要得到一個具有服務的容錯、可擴充套件環境就會相對變得
簡單。
隨著應用程式棧的複雜性增加，這些目標實現起來會變得更加複雜；但它們仍舊遵循
這一基礎模式，這對於使用許多可能的架構來說是足夠通用的。我們將在第 3 章中開始研
究更復雜的示例。
1.2.2 建立和執行服務
這個示例會假定，我們面臨一項任務，需要建立一個網站並且執行在高度容錯且高可
用的 NGINX 上。我們將在本書後續內容中看到一些非常完整的示例，但這一初始的 CoreOS
執行方式的體驗應該會讓我們理解我們將要採用的能夠在自身的應用程式以及本書介紹的
實踐示例和場景中取得成功的路徑。
提示： 這只是一次熱身，並不是要用作我們將要構建的示例。我們從第 2 章才開始介
紹開發環境的設定。
作為一個僅供閱讀的示例，這僅僅是為了提供熟悉的術語和概念，以便我們能夠在實
踐示例開始之前，基本理解 systemd、 fleet、 etcd 和 Docker 在 CoreOS 叢集的舞臺上共同協
作的方式。它假定我們可能不具有的一些事項：使用 NGINX 配置構建的 Docker 容器，以
及配置好的 CoreOS 叢集。
首先，要開始熟悉叢集的常用基礎設施拓撲，如圖 1.3 所示。這一設想的基礎設施由
三臺 CoreOS 機器和一個負載均衡器構成。我們假設，該負載均衡器能夠輪詢配置的
RESTful API，這對於我們之後研究如何在叢集中使用 etcd 發現服務來說會變得很重要。

圖 1.3 示例叢集
1.2.3 建立單元檔案
fleet 使用 systemd 作為其 init 系統，以便管理和分發服務； systemd 也充當 fleet 收集狀
態和操作服務的入口。 systemd 相對較新，但正如我們所知，它正在變成大多數流行 Linux
發行版本的標準。如果讀者不熟悉 systemd 單元檔案的話，請不要擔心；對於讓單元檔案
在 CoreOS 中生效而言，讀者所必須瞭解的內容並不複雜，並且我們將在本書中逐漸學習
更多與其有關的知識。
現在需要編寫兩個 systemd 單元檔案模板：一個用於 NGINX，另一個用於 sidekick。
sidekick 服務是一個 systemd 單元，它被繫結到實際的服務，並且會基於該服務的狀態執行
各種操作。 sidekick 服務主要被用於服務發現，這樣內部和外部的系統就可以理解服務的
狀態。並非總是需要 sidekick 單元，但如果一些東西最終要依賴通知或者服務的發現——
在這個例子中，也就是負載均衡器——那麼需要一個 sidekick 單元來負責該事務。
這裡首先呈現一個 NGINX 模板單元，可以使用它來執行伺服器容器。
程式碼清單 1.1 NGINX 單元檔案： nginx@.service
這樣的一個單元檔案被稱為一個模板，因為它的檔名中具有一個@；它無法直接運
行，但在@之後和.service 之前所新增的任何內容都會被插入到單元檔案中出現%i 的任何
位置。例如，如果單元檔案被命名為 nginx@.service，並且使用像 fleetctl start nginx@1.service
這樣的一個命令來啟動服務， 那麼 fleetctl 就會知道使用該檔案並且用 1 來替換該檔案中的
所有%i。後面將介紹與該機制有關的更多內容，但這就是我們使用相同服務的多個例項來
實現規模化服務的方式。
接下來，需要編寫一個 nginx-sidekick 模板。
程式碼清單 1.2 nginx-sidekick 單元檔案 : nginx-sidekick@.service
現在， systemd 單元檔案準備好了，並且可以在工作站上使用 fleetctl 註冊它們：
$ fleetctl --tunnel=10.0.0.1 start nginx@1.service nginx-sidekick@1.service
可以選擇要執行--tunnel 的任意結點，並且 fleetctl 將會自動將單元檔案上傳到叢集(通
過 SSH)以及在其中一個結點上啟動它們。注意，在@之後放置了數字 1； fleetctl 足夠智慧，
它知道這意味著其是一個 systemd 模板，並且將抓取正確的檔案。
如果我們希望上傳服務而不啟動它們，則可以用 submit 替換 start。我們將在第 2 章和
第 3 章中研究與 fleet 和 fleetctl 有關的更多細節。
服務現在就已經啟動並且在執行中了，負載均衡器應該已經根據對 etcd 的觀察選取了
NGINX 的執行位置。也可以使用 fleetctl 檢查執行中服務的狀態：
$ fleetctl --tunnel=10.0.0.1 list-units
UNIT MACHINE ACTIVE SUB
nginx-sidekick@1.service 22f78fd4.../10.0.0.1 active running
nginx@1.service 22f78fd4.../10.0.0.1 active running
我們可能會看到， sidekick 的狀態是 inactive，而 NGINX 的狀態是 activating。所發生
的事情是， Docker 正在首次下載映像層，因此需要花費幾分鐘來讓這兩者變成活動/執行中
狀態。由於 sidekick 被繫結到服務，因此只有在服務被正確啟動後，它才會執行。
也可以檢視 sidekick 伺服器是否已經註冊了 NGINX 伺服器：
既然服務和 sidekick 已經啟動並且處於執行狀態，那麼我們就來看看故障轉移是如何
工作的。
1.2.4 服務拓撲和故障轉移
叢集中的服務(nginx@1)和 sidekick(nginx-sidekick@1)的狀態目前看起來會像圖 1.4 一
樣。如前所述，我們假定，透過為/services/www/nginx@1 訪問 etcd 並且使用 JSON 響應來
設定其自己的配置，負載均衡器就可以輪詢 etcd。

圖 1.4 服務處於執行中的叢集
我們來測試容錯水平。假設有個新的實習生在資料中心中被絆倒了，並且碰掉了
10.0.0.1 機器的網線。一旦 fleet 意識到該機器掉線，則會發生圖 1.5 所示的情形。

圖 1.5 叢集中有機器當機
我們來逐步研究這一機器故障：
(1) fleet 透過 etcd 發現 10.0.0.1 掉線了。
(2) fleet 從 etcd 中的記錄得知， nginx@1 及其 sidekick nginx-sidekick@1 曾執行在該機
器上。
(3) fleet 在 10.0.0.3 上開啟 nginx@1，然後開啟 nginx-sidekick@1。
(4) nginx-sidekick@1 更新 etcd 中的資訊，該資訊表明了目前 nginx@1 執行的宿主機。
(5) 負載均衡器正在輪詢所有的 etcd 端點，它將會基於新的 etcd 資訊重新配置其自身。
正確配置了所有一切後，我們就有了一套穩固的故障轉移解決方案； 但就其本身而言，
那並不算完美。簡單的故障轉移必然不是高可用的——我們仍舊可能面臨中斷的局面。我
們需要什麼呢？更多的服務！
一名合格的系統架構師清楚，不應混淆容量縮放和可用性縮放的概念：實際上，它們
可能會被混為一談，但我們絕不應該陷入該混淆的概念。這些概念在 CoreOS 中也得到了
充實。 新增相同型別的更多服務確實提升了容量， 但其目標可能是為了提高高可用性(HA)。
當我們進行規劃時，要記得關注故障點並且將它們視為容量的可用性倍增器。將在第 4 章
中開始研究容量和可用性規劃。
如何才能讓更多的服務生效？我們很幸運：已經透過製作 systemd 單元模板對這一目
標進行了規劃！使用 fleetctl 開啟它們：
$ fleetctl --tunnel=10.0.0.1 start nginx@2.service nginx-sidekick@2.service
就這麼簡單！注意，沒有修改 IP 地址，主要是為了揭示打通哪臺宿主機並不重要。單
元檔案會告知 fleet，是否存在 NGINX 服務與其他任意 NGINX 服務的衝突，這樣該服務就
會自動執行在另一臺機器上。
現在叢集看起來就像圖 1.6 一樣，並且 fleetctl 會報告，更多的服務和 sidekick 正在執行：

圖 1.6 兩臺 NGINX
$ fleetctl --tunnel=10.0.0.1 list-units
UNIT MACHINE ACTIVE SUB
nginx-sidekick@1.service 6c945e2e.../10.0.0.3 active running
nginx-sidekick@2.service 22f78fd4.../10.0.0.1 active running
nginx@1.service 6c945e2e.../10.0.0.3 active running
nginx@2.service 22f78fd4.../10.0.0.1 active running
如果其中任何一臺機器出現故障，其服務將轉移到叢集中的另一臺機器上，就像之前
所描述的那樣，並且我們不會面臨中斷的情況，因為負載均衡器仍將具有可以依靠的一個
執行中服務。如果兩臺機器出現故障，那麼——最好的情況是——我們將具有一半的容量
處於執行中，因為我們將只有一個 NGINX 例項處於執行中。最壞的情況是，如果那兩臺
機器正是執行這兩個服務的機器，那麼在其中一個服務在單臺仍舊處於執行狀態的機器上
啟動期間，我們將面臨中斷的情形。
正如之前講過的，需要思考這種情況對於容量規劃來說意味著什麼，因為我們不希望
在一個 NGINX 例項出現故障時過載 NGINX 的單個例項。當然， CoreOS 支援的機器數遠
大於三臺；思考叢集故障和容量的規劃方式就是我們將在第 4 章和第 5 章中介紹的內容。
1.3 本章小結
● CoreOS 的基礎元件由 etcd、 fleet、 systemd 和 cloud-config 構成：
– etcd 維護配置和發現狀態。
– fleet 會在整個叢集中排程服務。
– systemd 被用作 init 系統。
– cloud-config 會設定機器的初始化固定狀態。
● systemd 單元檔案和可選的 sidekick 都是由 fleet 來分發的，以便組成高可用的服務。
● 進行恰當的配置，容錯能力就可以被內嵌到大多數已有系統中。

購買地址：