书名：基础设施即代码（第二版）
书号：978-7-5239-0999-7
定价：128元
作者：[美]基夫·莫里斯(Kief Morris) 著 马晶慧 译
出版时间：2026-04-24
出版社：中国电力出版社
页码： 444    字数(千字)：437
开本：特16开    版次：1    印次：1

品牌介绍

中国电力出版社成立于 1951 年，作为中国成立最早的中央科技出版社之一，曾隶属于水利电力部、能源部、电力工业部、国家电力公司，现为国家电网公司所属的科技出版社，在电气技术专业出版领域享有极高的声誉。该社作为以图书出版为主体，音像、电子出版物、期刊、网络出版共同发展的大型出版企业，以强大的出版资源和高素质的专业队伍，致力于向读者提供包括电力工程、电气工程、建筑工程、电子技术、信息技术、外语、大中专教材、家教等学科门类齐全的权威出版物，也竭力为广大师生提供精品教材，是教育部和北京市教委规划教材的出版基地之一。

编辑推荐

编辑推荐 几年前，“基础设施即代码”还是一个全新的概念。而如今，甚至连银行等保守机构也开始计划向云端迁移，全球各地的开发团队都在尝试构建大型基础设施代码库。这本实用指南将向你展示如何有效地运用开发运维团队开创的原则、实践和模式来管理云时代的基础设施。 本书非常适合系统管理员、基础设施工程师、软件开发人员、团队负责人以及架构师。第二版展示了如何利用云和自动化技术，以简单、安全、快速和负责任的方式更新系统。你将学习如何将一切定义为代码，并运用软件设计和工程实践，通过多个小而松散耦合的组件来构建系统。 专家推荐 “基础设施即代码的实践已经从管理服务器发展到了管理完整的技术栈，但这种新技术也带来了复杂性的代价。本书的内容超越了命令本身，将带你深入了解优秀实践背后的设计模式，以及更高层自动化的实现方法。” ——Patrick Debois DevOpsDays创始人

产品特色

本书的内容超越了命令本身，将带你深入了解优秀实践背后的设计模式，以及更高层自动化的实现方法。

作者介绍

Kief Morriss是ThoughtWorks的全球云工程总监，致力于帮助各类组织和团队探索更有效的方法，通过云计算和基础设施技术更快速、更可靠地交付更高价值的成果。他从事自动化IT服务器基础设施的设计、构建和运维已有20多年，最初使用shell脚本和Perl，随着技术的发展，逐步采用了CFengine、Puppet、Chef和Terraform等工具。

内容介绍

本书的主要内容有：利用基础设施即代码推动持续变更，提高运维质量标准，使用工具和技术构建基于云的平台。学习如何定义、配置、测试基础设施资源，并持续交付变更。使用模式设计服务器和集群的配置与部署。学习工作流程、治理方法和架构模式，创建并管理基础设施组件。
本书适用于本书非常适合系统管理员、基础设施工程师、软件开发人员、团队负责人以及架构师。

前言

前言 十年前，当我建议一家全球银行的首席信息官考虑私有云技术和基础设施自动化工具时，他嗤之以鼻：“那种东西或许适合初创公司，但我们规模太大，需求太复杂。”即便在几年前，许多企业仍认为使用公共云完全不可能。 如今，云技术已无处不在。即便是规模最大、最保守的组织，也在迅速采用“云优先”的战略。而无法使用公共云的组织，则在其数据中心建立了动态配置的基础设施平台。注1 这些平台所提供的功能正在快速发展和改进，忽视这些技术，将面临被淘汰的风险。 云与自动化技术消除了变更生产系统的障碍，但这也带来了新的挑战。虽然大多数组织都希望加快变更的步伐，但他们不能忽视风险和管理的需求。传统的流程和技术虽然可以安全地变更基础设施，但无法应对快速变更的节奏。这些工作方式往往会限制现代“云时代”技术的优势，导致工作速度减慢并损害稳定性。注2 在第1 章，我使用了“铁器时代”和“云时代”这两个术语来描述两种不同的理念：前者管理的是物理基础设施，纠正错误的速度缓慢，且需要付出高昂的代价；后者管理的则是虚拟基础设施，错误可以被快速发现并修复。 基础设施即代码工具创造了以更高频率、更快速且更可靠的方式交付变更的机会，从而提升系统的整体质量。但这种收益并非来自工具本身，而是来自使用方式。关键在于如何利用这项技术，把质量、可靠性和合规性融入变更流程中。 本书的创作缘由 当初我发现关于如何管理基础设施即代码的系统性指导缺失，所以才创作了本书的第一版。很多博客文章、会议演讲以及各类产品和项目的文档中都零星提到了相关的建议，但实践者需要自己筛选并拼凑出一套策略，而大多数人根本没有时间去做这件事。 撰写第一版的经历非常奇妙。以此为契机，我走访了世界各地的许多人，与他们交流经验。这些对话让我获得了新的见解，也让我遇到新的挑战。我认识到，创作、大会演讲以及为客户提供咨询的价值在于促进交流。作为一个行业，我们仍在不断收集、分享并发展关于如何管理基础设施即代码的理念。 第二版的更新内容 自2016 年6 月第一版问世以来，情况已经发生了很大变化。第一版的副标题是“管理云端服务器”，表明当时大多数基础设施自动化的重点仍然集中在服务器配置上。从那以后，容器和集群变得越来越重要，基础设施的重点转移到了管理云平台提供的基础设施资源的集合—— 我在本书中称之为“栈”。 因此，第二版涵盖了更多关于构建栈的内容，即CloudFormation 和Terraform等工具的用武之处。我认为，应该使用栈管理工具来建立一整套基础设施资源，以提供应用的运行时环境。这些运行时环境包括服务器、集群以及无服务器的执行环境。 我根据对构建基础设施团队不断变化的挑战和需求的了解，对书中内容做了大幅调整。如前所述，我认为基础设施即代码最大的优势在于，可安全轻松地变更基础设施。我相信人们往往会低估这一点，错误地认为基础设施一旦建好就无需再理会。 然而，我遇到的许多团队都无法满足组织的需求：他们无法快速扩展和规模化，无法支持软件交付的节奏，也无法提供预期的可靠性和安全性。深入分析他们所面临的挑战，我们发现问题在于，他们被更新、修复和改进系统的需求压得喘不过气来。因此，本书将这一点作为核心主题重点讲解。 第二版引入了使用基础设施即代码安全且轻松地进行变更的三项核心实践：将一切定义为代码 顾名思义，我们可借此建立可重复性和一致性。 持续测试并交付所有正在进行的工作 提高每次变更的安全性，同时能够以更快的速度、更高的信心推进工作。 构建可独立变更、小而简单的模块 小模块的变更难度更低，且更安全。 这三项实践相辅相成。代码便于跟踪、管理版本，以及在变更管理流程的各个阶段交付。模块越小，越容易测试。而独立测试每个模块可迫使你保持松散耦合的设计。 软件开发领域对这些实践以及如何应用的细节并不陌生。本书第一版借鉴了敏捷软件工程和交付实践，第二版还借鉴了有效设计的规则和实践。 近年来，我目睹了团队在处理更大、更复杂的基础设施系统时遇到的困难，同时也看到了将软件设计模式和原则应用到基础设施管理中的好处。因此，第二版增加了几个章节，介绍如何应用这些经验。 此外，我还发现，对许多团队而言，组织和管理基础设施代码十分困难，因此我也针对各种痛点提供了解决方案。我介绍了如何保持代码库井然有序、如何为基础设施提供开发和测试实例，以及如何管理多人协作，包括负责管理的人。 未来展望 我认为，整个行业在基础设施管理方面尚未真正成熟。我希望本书能够呈现出当下各个团队普遍认为有效的一些做法，同时也会指出有待未来进一步改进的期许。 我十分确信，在未来五年内，工具链和方法论都会持续演进。我们会使用更多通用编程语言来构建库，甚至能够动态生成基础设施，而不是停留在底层定义环境的静态细节。毫无疑问，我们需要提升管理运行中的基础设施变更的水平。据我所知，大多数团队都很害怕将代码应用到生产环境 [ 有个团队甚至戏称Terraform 为“Terrorform”（恐怖形态），使用其他工具的人其实也有类似的感受]。 本书涵盖与不涵盖的内容 本书的主题是通过探索不同的工具使用方式来实现基础设施，帮助我们提升服务的质量。我们的目标是借助交付的速度与频率来提升交付成果的可靠性与质量。 因此，本书不会集中介绍某个具体的工具，而是会更加注重介绍如何使用这些工具。 虽然我会提及一些配置服务器与部署栈的工具示例，但不会介绍某一特定工具或云平台的使用细节。我会介绍一些模式、实践和技术，无论你使用何种工具或平台，这些内容都适用。 本书不包含真实工具或云平台的代码示例。在这一领域，工具的更新速度太快，真实的代码示例很难长期保持准确，而书中的建议则具有更持久的适用性，而且还可以跨工具使用。取而代之，我将采用伪代码示例和虚拟工具来说明概念。 相关的项目与示例代码，请参见本书的配套网站（地址：）。 本书不涉及如何使用Linux 操作系统、如何配置Kubernetes 集群，以及如何设置网络路由等内容。但我会介绍如何通过配置基础设施资源来创建这些组件，以及如何使用代码来交付它们。我将分享不同的集群拓扑模式，以及通过代码定义和管理集群的方式。我还会介绍如何使用代码来部署、配置以及修改服务器实例。 有关具体的操作系统、集群技术以及具体云平台的使用，请查阅相应的资源，作为本书实践内容的补充。再次强调，本书主要介绍使用这些工具和技术的通用方法，不依赖于特定工具，具有广泛适用性。 此外，本书还会简单地介绍可操作性的相关主题，例如监控与可观测性、日志聚合、身份管理，以及在云环境中支持服务所需的其他相关事项。本书的内容可以帮助你以代码的形式管理这些服务所需的基础设施，但具体服务的实现细节仍需参考更专业的资料。 基础设施即代码的发展简史 基础设施即代码（Infrastructure as Code，简称IaC）工具与实践的出现远早于这一术语的问世。系统管理员自早期就开始使用脚本来辅助管理系统。1993 年，Mark Burgess 创建了具有开创性的系统CFEngine（参考链接： 年代初，通过网站Infrastructures.org（地址：基础设施即代码的发展与开发运维运动密不可分。在2008 年的敏捷大会上，Andrew Clay Shafer 和Patrick Debois 发表的演讲掀起了开发运维运动（参考链接： as Code”这一术语的首次使用可以追溯到2009 年Clay-Shafer 在Velocity 大会上的演讲《Agile Infrastructure》（参考链接： Willis 撰写的一篇总结该演讲的文章（参考链接： 的联合创始人Adam Jacob和Puppet 的创始人Luke Kanies 也开始使用这一术语。 本书面向的读者对象 本书主要面向参与提供和使用基础设施以交付和运行软件的人群。读者可能拥有系统与基础设施的背景，也可能来自软件开发与交付领域。而角色则可能是工程、测试、架构或管理。我假设读者对云或虚拟化基础设施，以及使用代码自动化基础设施的工具有一定了解。 对基础设施即代码新手而言，本书是一本不错的入门指南。不过，如果读者熟悉基础设施云平台的工作原理，并掌握至少一种基础设施编程工具的基础知识，收获会更丰厚。 对于已有相关工具使用经验的读者，本书包含的概念和方法既有你熟悉的，也有新颖的。书中的内容能够建立共同的语言，以阐明挑战及解决方案的方式非常易于经验丰富的实践者和团队理解。 原理、实践与模式 我使用术语“原则”“实践”以及“模式”（和反模式）来描述一些核心概念。 以下是我对这些术语的使用方式： 原则 原则是一条规则，可帮助你在多种潜在解决方案中作出选择。 实践 实践是某种实现方式。某个具体的实践并不总是唯一的实现方法，在特定情境下也未必是最优方法。你应当使用原则作为指导，在特定情境下选择最合适的实践。 模式 模式是针对某个问题的一个潜在解决方案。与实践非常相似，在不同环境中，可能采用不同的模式更有效。我们通过一种格式描述每个模式，以便帮助你评估是否适合你的问题。 反模式 反模式是一种应当在大多数情况下避免的潜在解决方案。通常，这指的是表面看起来不错，人们会在不知不觉中采取的做法。 ShopSpinner 示例 在本书中，我使用一家虚构公司ShopSpinner 来说明各种概念。ShopSpinner 负责为客户构建并运行在线商店。 ShopSpinner 运行在FCS（Fictional Cloud Service，虚拟云服务）上，这是一个公共IaaS 提供商，其服务包括FSI（Fictional Server Images，虚拟服务器镜像）和FKS（Fictional Kubernetes Service，虚拟Kubernetes 服务）。ShopSpinner使用工具Stackmaker（类似于Terraform、CloudFormation 和Pulumi）来定义和管理云上的基础设施，还使用工具Servermaker（类似于Ansible、Chef 或Puppet）配置服务器。 根据我想要说明的重点不同，ShopSpinner 的基础设施和系统设计可能会发生变化，其虚拟工具的代码语法和命令行参数也会随之变化。 排版约定 本书使用了下述排版约定。 斜体（Italic） 表示新术语、URL、示例电子邮件地址、文件名和扩展名。 等宽字体（Constant width） 表示代码，在段内用以表示与代码相关的元素，例如变量或函数名、数据库、数据类型、环境变量、声明和关键字。 粗体等宽字体（Constant width bold） 表示应由用户原封不动输入的命令或其他文本。 斜体等宽字体（Constant width italic） 表示该文本应当由用户提供的值或由用户根据上下文决定的值替换。 O’Reilly 在线学习平台（O’Reilly Online Learning） 近40 年来，O’Reilly Media 致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。 公司独有的专家和改革创新者网络通过O’Reilly 书籍、文章以及在线学习平台，分享他们的专业知识和实践经验。O’Reilly 在线学习平台按照您的需要提供实时培训课程、深入学习渠道、交互式编程环境以及来自O’Reilly 和其他200 多家出版商的大量书籍与视频资料。更多信息，请访问网站：/。 联系我们 任何有关本书的意见或疑问，请按照以下地址联系出版社。 美国： O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 中国： 北京市西城区西直门南大街2 号成铭大厦C 座807 室（100035） 奥莱利技术咨询（北京）有限公司 这本书有专属网页，你可以在上面找到本书的勘误、示例和其他信息。地址是：。 如果你对本书有一些评论或技术上的建议，请发送电子邮件到bookquestions@oreilly.com。 对本书中文版有任何建议可以发电子邮件到errata@oreilly.com.cn。 要了解O’Reilly 图书、培训课程、会议和新闻的更多信息，请访问我们的网站http://。 我们的Facebook：。 我们的Twitter：。 我们的Youtube：。 致谢 与第一版相同，本书并非作者个人独创之作，而是对我从众多人士处获得的知识与经验进行整理与汇总的成果。对于未能在此明确致谢的人，谨致以歉意与衷心感谢。 我非常享受与James Lewis 交流想法，我们的对话以及他在著作和演讲中的见解，对本书的内容产生了直接和间接的影响。他慷慨地分享了软件设计方面的丰富经验以及对其他相关领域的广泛认知，并在本书即将定稿之际给予了许多意见与建议。这些建议帮助我更好地理顺了软件工程与基础设施即代码之间的联系。 自始至终Martin Fowler 对我的工作都给予了慷慨的支持。他善于从众多人士的经验中汲取见解，结合自身知识与洞察，将其整理为清晰而有益的建议，对我产生了极大的启发。 Thierry de Pauw 是思虑周全的审稿人，对我的帮助很大。他审阅了多版手稿并反馈了自己的意见，指出哪些内容具有新意和实用性，哪些观点与其自身经验相契合，以及哪些部分未能清楚传达。 另感谢Abigail Bangser、Jon Barber、Max Griffiths、Anne Simmons 和Claire Walkley 对我的鼓励与启发。 与我合作的诸位同仁提供了许多宝贵的意见与想法，极大地完善了本书的内容。James Green 分享了在基础设施背景下对于数据工程和机器学习的看法。Pat Downey 解释了基础设施“扩展与收缩”的应用。Vincenzo Fabrizi 指出基础设施依赖关系中控制反转的重要价值。Effy Elden 掌握了基础设施工具领域的大量知识。Moritz Heiber 对本书内容产生了直接和间接的影响，尽管希望他对本书内容百分之百认同未免过于奢望。 在ThoughtWorks，我有机会通过研讨会、项目，以及在线论坛，与众多同事和客户就基础设施即代码及相关主题进行交流与讨论。其中包括Ama Asare、Nilakhya Chatterjee、Audrey Conceicao、Patrick Dale、Dhaval Doshi、Filip Fafara、Adam Fahie、John Feminella、Mario Fernandez、Louise Franklin、Heiko Gerin、Jarrad “Barry” Goodwin、Emily Gorcenski、James Gregory、Col Harris、Prince M Jain、Andrew Jones、Aiko Klostermann、Charles Korn、Vishwas Kumar、Punit Lad、Suya Liu、Tom Clement Oketch、Gerald Schmidt、Boss Supanat Pothivarakorn、Rodrigo Rech、Florian Sellmayr、Vladimir Sneblic、Isha Soni、Widyasari Stella、Paul Valla、Srikanth Venugopalan、Ankit Wal、Paul Yeoh 和Jiayu Yi。同时感谢Kent Spillner，这一次，我终于记得为何要感谢他。 第二版的多份草稿得到了众多人士的审阅与反馈， 其中包括Artashes Arabajyan、Albert Attard、Simon Bisson、Phillip Campbell、Mario Cecchi、Carlos Conde、Bamdad Dashtban、Marc Hofer、Willem van Ketwich、Barry O’Reilly、Rob Park、Robert Quinlivan、Wasin Watthanasrisong 和Rebecca Wirfs-Brock。 衷心感谢我的编辑Virginia Wilson，在本书漫长而艰辛的制作过程中，她给予了我持续的支持与鼓励。我的同事John Amalana 将我拙劣的图示转化为此书中的精美插图，其耐心与敬业精神令人钦佩。 我的雇主ThoughtWorks 对本书的创作给予了巨大支持。第一，他们为我提供了向杰出人才学习的环境；第二，他们营造了鼓励成员向行业分享理念的文化；第三，在我与其他ThoughtWorks 同事及客户共同探索和测试新工作方法时给予了支持。感谢Ashok Subramanian、Ruth Harrison、Renee Hawkins、Ken Mugrage、Rebecca Parsons，以及Gayathri Rao 等的帮助，本书不仅仅是我个人的项目。 最后，我将最真挚的感谢与永恒的爱献给Ozlem 和Erel，感谢他们对于我全身心创作本书给予的包容。再次感谢。

目录

目录
前言 1
第一部分 基础
第1 章 什么是基础设施即代码 15
11 从铁器时代到云时代 17
12 基础设施即代码 18
13 基础设施即代码的优势 18
14 使用基础设施即代码来优化变更 19
141 反对意见：“我们的变更频率不高，不值得自动化” 19
142 反对意见：“我们应该先构建，然后再自动化” 20
143 反对意见：“我们必须在速度和质量之间做出选择” 21
15 四个关键指标 23
16 基础设施即代码的三个核心实践 24
161 核心实践：一切皆定义为代码 25
162 核心实践：持续测试并交付所有正在进行的工作 25
163 核心实践：构建可独立变更的、小而简单的部件 26
17 小结 26
第2 章 云时代基础设施的原则 27
21 原则：假设系统不可靠 28
22 原则：一切皆可复制 28
23 陷阱：雪花系统 29
24 原则：创建一次性系统 30
25 原则：最小化变化 31
26 原则：确保所有过程皆可重复 35
27 小结 35
第3 章 基础设施平台 37
31 基础设施系统的组成部分 37
32 基础设施平台 39
33 基础设施资源 41
331 计算资源 42
332 存储资源 44
333 网络资源 45
34 小结 47
第4 章 核心实践：一切皆定义为代码 49
41 为什么应将基础设施定义为代码 49
42 什么可定义为代码 50
421 选择具有外部化配置的工具 50
422 利用版本控制系统管理代码 51
43 基础设施编程语言 52
431 基础设施脚本 54
432 声明式基础设施语言56
433 可编程的、命令式基础设施语言 58
434 基础设施的声明式语言与命令式语言 59
435 特定领域的基础设施语言 60
436 基础设施的通用语言与DSL 61
44 将基础设施即定义为代码的实现原则 62
441 声明式代码和命令式代码的分离 62
442 把基础设施代码当作真正的代码 62
45 小结 63
第二部分 基础设施栈
第5 章 基础设施栈即为代码的构建 67
51 什么是基础设施堆栈 67
511 栈代码 69
512 栈实例 69
513 配置栈中的服务器 70
514 低级基础设施语言 71
515 高级基础设施语言 72
52 结构化栈的模式和反模式 72
521 反模式：单体栈 73
522 模式：应用程序组栈75
523 模式：服务栈 77
524 模式：微栈 78
53 小结 80
第6 章 使用栈构建环境 81
61 环境是什么 81
611 交付环境 82
612 多个生产环境 82
613 环境、一致性和配置83
62 构建环境的模式 84
621 反模式：多环境栈 84
622 反模式：复制粘贴环境 86
623 模式：可复用栈 88
63 构建多栈环境 90
64 小结 92
第7 章 配置栈实例 93
71 通过栈参数创建唯一标识符95
72 栈参数示例 95
73 配置栈的模式 96
731 反模式：手动管理栈参数 97
732 模式：栈环境变量 98
733 模式：脚本化参数 101
734 模式：栈配置文件 104
735 模式：包装栈 108
736 模式：管道栈参数 110
737 模式：栈参数注册表113
74 配置注册表  117
741 实现配置注册表 117
742 单个或多个配置注册表 119
75 将机密作为参数 120
751 加密机密 120
752 无机密授权 121
753 在运行时注入机密 121
754 一次性机密 122
76 小结 122
第8 章 核心实践：持续测试与交付  123
81 为什么要持续测试基础设施代码 124
811 持续测试意味着什么124
812 基础设施应该测试什么 126
82 测试基础设施代码的挑战 129
821 挑战：测试声明式代码的价值通常较低 129
822 挑战：基础设施代码的测试速度很慢 132
823 挑战：依赖导致基础设施的测试复杂化 133
83 渐进式测试 134
831 测试金字塔 135
832 瑞士奶酪测试模型 137
84 基础设施交付管道 138
841 管道的各个阶段 139
842 阶段内测试的组件范围 140
843 阶段的依赖范围 141
844 阶段所需的平台元素141
845 交付管道软件和服务142
85 生产测试 144
851 无法在生产环境外重现的情况 145
852 管理生产环境测试的风险 146
86 小结 148
第9 章 测试基础设施栈  149
91 基础设施示例 149
911 栈示例 150
912 栈管道示例 151
92 栈的离线测试阶段 152
921 语法检查 152
922 离线静态代码分析 153
923 使用API 的静态代码分析 153
924 使用模拟API 测试 154
93 栈的在线测试阶段 154
931 预览：检查变更的内容 155
932 验证：断言基础设施资源 156
933 结果：证明基础设施正常运行 158
94 使用测试夹具处理依赖关系158
941 上游依赖的测试替身160
942 下游依赖的测试夹具160
943 重构组件实现隔离 162
95 栈测试实例的生命周期模式163
951 模式：持久测试栈 163
952 模式：临时测试栈 164
953 反模式：持久栈和临时栈双阶段 166
954 模式：周期性重建栈167
955 模式：连续重置栈 169
96 测试编排 170
961 支持本地测试 171
962 避免与管道工具紧密耦合 172
963 测试编排工具 172
97 小结 173
第三部分 服务器和其他应用程序运行时平台
第10 章 应用程序运行时  177
101 云原生与应用程序驱动的基础设施 178
102 应用程序运行时目标 179
1021 应用程序的可部署组件 179
1022 部署包 180
103 将应用程序部署到服务器 181
1031 在容器中打包应用程序 181
1032 将应用程序部署到服务器集群 182
104 将应用程序部署到集群 183
105 将应用程序部署到集群的包 184
106 部署FaaS 无服务器应用程序 186
107 应用程序数据 187
1071 数据模式与结构 187
1072 云原生应用存储基础设施 188
108 应用程序连接 189
109 服务发现 190
1010 小结 192
第11 章 服务器即代码  193
111 服务器的组成 194
112 各个组成部分的来源 195
113 服务器配置代码 197
1131 服务器配置代码模块 198
1132 设计服务器配置代码模块 198
1133 服务器代码的版本控制和升级 199
1134 服务器角色 200
114 测试服务器代码 201
1141 服务器代码的渐进式测试 202
1142 服务器代码的测试内容 202
1143 服务器代码的测试方法 204
115 新建服务器实例 204
1151 手动新建服务器实例 206
1152 使用脚本创建服务器 206
1153 使用栈管理工具创建服务器 207
1154 配置平台自动创建服务器 207
1155 使用网络配置工具构建服务器 208
116 预构建服务器 209
1161 热克隆服务器 210
1162 使用服务器快照 210
1163 创建干净的服务器镜像 210
117 配置新的服务器实例  211
1171 “煎”服务器实例 212
1172 “烘焙”服务器镜像 214
1173 结合“烘焙”与“煎” 214
1174 创建服务器时应用服务器配置 215
118 小结 216
第12 章 服务器变更  217
121 变更管理模式：何时应用变更 218
1211 反模式：变更时应用 218
1212 模式：持续同步配置 220
1213 模式：不可变服务器 222
122 应用服务器配置代码的方式 224
1221 模式：推送服务器配置 224
1222 模式：拉取服务器配置 226
123 服务器生命周期中的其他事件 228
1231 停止与重启服务器实例 229
1232 更换服务器实例 230
1233 恢复故障服务器 231
124 小结 232
第13 章 服务器镜像即代码  233
131 构建服务器镜像 234
1311 为什么要构建服务器镜像 234
1312 如何构建服务器镜像 235
1313 构建服务器镜像的工具 235
1314 在线构建镜像 236
1315 离线构建镜像 239
132 服务器镜像的原内容 241
1321 基于标准服务器镜像的构建 241
1322 从零构建服务器镜像 242
1323 服务器镜像及其内容的来源 242
133 服务器镜像变更 243
1331 重新加热或烘焙新镜像 243
1332 服务器镜像的版本控制 244
1333 镜像变更时更新服务器实例 245
1334 跨团队提供和使用服务器镜像 247
1335 处理镜像的重大变更 247
134 使用管道测试和交付服务器镜像 248
1341 服务器镜像的构建阶段 249
1342 服务器镜像的测试阶段 250
1343 服务器镜像的交付阶段 251
135 使用多个服务器镜像 252
1351 不同基础设施平台的服务器镜像 252
1352 不同操作系统的服务器镜像 253
1353 不同硬件架构的服务器镜像 253
1354 不同角色的服务器镜像 253
1355 分层构建服务器镜像 254
1356 跨服务器镜像共享代码 255
136 小结 256
第14 章 集群即为代码  257
141 应用程序集群解决方案 258
1411 集群即服务258
1412 集群打包发行版 259
142 应用程序集群的栈拓扑 260
1421 使用集群即服务的单体栈 262
1422 打包集群解决方案的单体栈 263
1423 单体应用程序集群栈的管道 263
1424 集群的多栈示例 266
143 应用程序集群的共享策略 269
1431 单一大集群270
1432 交付阶段设置单独的集群 271
1433 治理相关的集群 272
1434 团队专用集群 273
1435 服务网格 273
144 FaaS 无服务器的基础设施 275
145 小结 277
第四部分 设计基础设施
第15 章 核心实践：小而简单的部件  281
151 模块化设计 282
1511 设计良好的组件特征 282
1512 组件设计规则 283
1513 测试指导设计决策 286
152 基础设施模块化 287
1521 栈组件与栈即组件 287
1522 栈中的服务器 289
153 划分组件的边界 293
1531 根据自然变化模式划分边界 293
1532 根据组件生命周期划分边界 293
1533 根据组织结构划分边界 295
1534 创建支持弹性的边界 296
1535 创建支持扩展的边界 297
1536 根据安全和治理要求划分边界 300
154 小结 301
第16 章 利用组件构建栈  303
161 栈组件的基础设施语言 304
1611 通过模块重用声明式代码 304
1612 使用库动态创建栈元素 305
162 栈组件的模式 307
1621 模式：外观模块 307
1622 反模式：混乱模块 308
1623 反模式：非共享模块 310
1624 模式：捆绑模块 311
1625 反模式：意大利面条式模块 313
1626 模式：基础设施域实体 316
163 构建抽象层 318
164 小结 319
第17 章 将栈视为组件  321
171 发现栈之间的依赖关系 321
1711 模式：资源匹配 323
1712 模式：栈数据查找 325
1713 模式：集成注册表查找 328
1714 依赖注入 331
172 小结 334
第五部分 交付基础设施
第18 章 组织基础设施代码  337
181 组织项目和存储库337
1811 一个存储库还是多个 338
1812 单一存储库338
1813 每个项目一个单独的存储库（微存储库） 341
1814 拥有多个项目的多个存储库 342
182 组织不同类型的代码 343
1821 项目支持文件 343
1822 跨项目测试345
1823 专用集成测试项目 346
1824 按域概念组织代码 346
1825 组织配置值文件 347
183 管理基础设施与应用程序代码 348
1831 交付基础设施和应用程序 349
1832 使用基础设施测试应用程序 350
1833 集成之前测试基础设施 351
1834 使用基础设施代码部署应用程序 352
184 小结 354
第19 章 交付基础设施代码  355
191 交付基础设施代码概述 355
1911 构建基础设施项目 356
1912 打包基础设施代码 357
1913 使用存储库交付基础设施代码 357
192 项目集成 360
1921 模式：构建时项目集成 362
1922 模式：交付时项目集成 365
1923 模式：应用时项目集成 368
193 使用脚本封装基础设施工具 370
1931 组装配置值371
1932 简化封装脚本 372
194 小结 373
第20 章 团队工作流程  375
201 人员 376
202 谁编写基础设施代码 378
203 将代码应用于基础设施 380
2031 从本地工作站应用代码 380
2032 通过集中式服务应用代码 381
2033 个人基础设施实例 383
2034 工作流程中的源代码分支 384
204 防止配置漂移 386
2041 最大限度地减少自动化滞后 386
2042 避免临时应用 387
2043 持续应用代码 387
2044 不可变基础设施 387
205 基于管道的工作流程中的治理 388
2051 重新分配职责 389
2052 左移 390
2053 基础设施即代码与治理的示例流程 390
206 小结 391
第21 章 安全地修改基础设施  393
211 缩小变更范围 393
2111 小改动 396
2112 重构示例 397
212 将不完整的变更推送到生产 399
2121 并行实例 399
2122 向后兼容转换 403
2123 功能开关 404
213 修改实时的基础设施 407
2131 基础设施手术 408
2132 扩展与收缩411
2133 零停机变更415
214 连续性 416
2141 通过预防错误实现连续性 416
2142 通过快速恢复实现连续性 417
2143 持续灾难恢复 418
2144 混沌工程 419
2145 为失败做好计划 419
215 不断变化的系统中的数据连续性 421
2151 锁定 422
2152 隔离 422
2153 复制 422
2154 重载 423
2155 数据连续性混合法 423
216 小结 424