ITPub博客

首页 > Linux操作系统 > Linux操作系统 > CoreOS实战

CoreOS实战

原创 Linux操作系统 作者:qinghuawenkang 时间:2018-10-30 11:00:19 0 删除 编辑


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 号
责任编辑:王 军 于 平
装帧设计:思创景点
责任校对:曹 阳
责任印制:刘海龙
出版发行:清华大学出版社
网 址: http://www.tup.com.cn, http://www.wqbook.com
地 址:北京清华大学学研大厦 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 模板,都可以在 www.manning.com/
books/coreos-in-action 下载。也可扫描封底的二维码下载源代码。
作者简介
Matt Bailey 目前是 ZeniMax 的技术主管。他曾致力于高等教育行业,并且曾供职于科
学计算、医疗和网络技术公司,以及一些初创型公司。读者可以通过 http://mdb.io 以在线
方式联系他。
作者在线
购买了《CoreOS 实战》的读者可以免费访问 Manning 出版社所运营的一个私有网络
论坛,读者可以在其中对本书进行评论,提出技术问题,并且接受来自作者和其他读者的
帮助。要访问该论坛并且进行订阅,可以将 Web 浏览器导航到 www.manning.com/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 年出版,
www.manning.com/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 来分发的,以便组成高可用的服务。
● 进行恰当的配置,容错能力就可以被内嵌到大多数已有系统中。

购买地址:

http://product.dangdang.com/25258031.html


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26421423/viewspace-2218010/,如需转载,请注明出处,否则将追究法律责任。

上一篇: Linux宝典(第9版)
请登录后发表评论 登录
全部评论
分享计算机前沿技术和国外计算机先进技术书籍。

注册时间:2011-11-08

  • 博文量
    54
  • 访问量
    104943