作者：（美）基夫·莫里斯（Kief Morris）
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
基础设施即代码：云服务器管理试读：
前言
在构建和管理基础设施的过程中，基础设施团队与软件开发团队正在越来越多地使用名为“基础设施即代码”的自动化工具。这些工具要求用户在类似软件源代码的文件中定义服务器、网络以及基础设施的其他元素。它们会编译并解读这些文件，以决定采取哪些行动。1
这类工具随着 DevOps 运动 蓬勃发展。DevOps 运动主要是关于软件开发人员与软件运维人员之间的文化和协作。基于软件开发范式的基础设施管理工具促进了开发与运维的融合。1Andrew Clay Shafer 与 Patrick Debois 在 Agile 2008 大会上的演讲引发了 DevOps 运动。Debois 组织的一系列 DevOpsDays 大会极大推动了 DevOps 运动。
基础设施即代码的管理方式与传统的基础设施管理方式迥然不同。我遇到过不少团队努力地去实现这一转变，但是有效应用这些工具的理念、模式与实践却只在各种大会演讲、博客以及文章里提及过。我一直在等待一本书，能把这些想法整合到一起，但迟迟没有看到有人写作的迹象，于是我最终决定亲自动手。你正在阅读的这本书就是我努力的成果。我是怎样学着不再担忧并且爱上云的2
1992 年，我搭建了自己的第一台服务器——一个拨号的 BBS，由此成为 Unix 系统管理员，随后负责为不同规模的公司构建与运维托管式软件系统［后来我们称之为 SaaS（software as a service，软件即服务）］，其中既包括创业公司也包括大型企业。在我听说“基础设施即代码”这个术语之前，就始终在朝着基础设施即代码的方向前进。2BBS 是电子公告板系统（bulletin board system）的简称。
虚拟化让一切变得难以为继。对很多人而言，我磕磕绊绊地实施虚拟化和云计算的经历可能并不陌生，它揭示了基础设施即代码要在现代 IT 运维中扮演的角色。我的第一组虚拟机集群
2007 年，当我的团队获得预算，可以购买两台强劲的 HP 机架服务器以及 VMware ESX 服务器的软件许可证时，我兴奋极了。
我们当时的办公室机架上有大概 20 台 1U 和 2U 服务器，分别以水果（Linux 服务器）和莓果（Windows 数据库服务器）命名，上面运行着开发团队使用的测试环境。我们每天的工作就是大量使用这些服务器，测试不同的版本、分支，以及高优先级、验证概念型的应用程序。这些服务器上塞满了网络服务，如 DNS、文件服务器和电子邮件，并且运行了多个应用程序实例、Web 服务器与数据库服务器。
因此，我们非常确信这些新的虚拟服务器将改变我们的生活。我们可以清晰地将以上服务分离到它们各自的虚拟机（virtual machine，VM）上面，而 ESX Hypervisor 虚拟化管理软件会帮助我们从多核服务器和内存上榨取尽可能多的性能。我们可以很容易地复制服务器来创建新的环境，并且将不再需要的服务器归档到磁盘上面，而不用担心在未来需要的时候无法恢复它们。
这些服务器真真切切地改变了我们的生活。不过，虽然解决了很多老问题，我们却发现了新的问题，不得不学习采用完全不同的方式来思考基础设施。
虚拟化使服务器的创建与管理变得更容易了。它带来的负面影响是，我们最终创建的服务器数量远远超出了想象。产品和市场部门的同事高兴极了，因为我们一天之内就能提供一个全新的演示环境，而不用他们提供预算并等待几周时间以便我们完成硬件服务器的采购和设置。魔法师的学徒
一年之后，我们运行了超过 100 台虚拟机，而且这个数字还在增长。我们当时正在将生产服务器转向虚拟化，并且在尝试亚马逊新推出的云计算托管服务。虚拟化给业务人员带来的好处意味着，我们有钱购买更多的 ESX 服务器和强大的 SAN（存储网络）设备，以满足基础设施对于存储的惊人“胃口”。
但是，我们发现自己有点像动画电影《幻想曲》里面“魔法师的学徒”情节中的米老鼠。虚拟机的数量不断增加，最后多到了我们无法承受的地步。当出现问题的时候，我们追踪到具体的虚拟机，然后修复故障，但是从不跟踪记录在哪些地方做了哪些修改。噢，完美的一击！看我把它砍成两半！现在我又重拾希望了，可以无忧无虑地呼吸了！ 唉，我高兴得太早了！两半都变成了完整的一个，现在，有两个仆人听从我的吩咐！伟大的神啊，救救我吧！我恳求你！3——摘录自歌德的十四行诗《魔法师的学徒》31797 年，德国诗人歌德创作了十四行叙事诗《魔法师的学徒》，讲述了一位学徒魔法师在老魔法师离开后，使用半吊子魔法指挥拖把、水桶等工具进行清扫工作，最后因为不能掌控局面而弄得一片混乱，几乎将房间淹没。老魔法师回来后才将一切复原。作者此处借用了这个典故，比喻不加节制地使用虚拟机反而导致基础设施团队陷入困境。——译者注
每当操作系统、Web 服务器、应用服务器、数据库服务器、Java 虚拟机和其他各类软件推出更新版本，我们就不得不忙于在所有系统上安装更新。有些服务器可以成功安装更新，但有些服务器上的更新则会导致一些东西无法工作，而我们没有时间来解决每一个不兼容性的问题。随着时间流逝，几百台服务器上最终混杂了很多不同的版本。
在引入虚拟化之前我们就在使用配置自动化软件了，这些软件本该帮助我们解决这些问题。我在之前的公司里使用过 CFEngine，刚来这个团队时，也尝试过一款名为 Puppet 的新工具。之后，在研究 AWS 基础设施的时候，我的同事 Andrew 又引入了 Chef。所有这些工具都很有用，然而却并没有把我们从服务器差异巨大的困境之中解救出来，尤其是在最初的日子里。
问题在于，虽然 Puppet（以及 Chef 等其他工具）应该在所有的服务器上都设置好并且无人值守地运行，但我们却不放心。服务器的差异实在太大了。我们可能针对某一台特定应用服务器编写了一些配置清单文件（manifest）来进行配置和管理；但是当在另一台理论上相似的应用服务器上运行这些配置清单文件时，我们发现不同版本的 Java、应用程序和 OS 组件会导致 Puppet 运行失败，甚至更糟——导致应用服务器无法工作。
我们最终只是临时使用 Puppet。我们能在新的虚拟机上放心地运行 Puppet，不过每次运行之后可能还要再做一些小调整。我们会针对某个特殊的任务编写一些配置清单文件，然后逐一在每台服务器上运行，小心翼翼地检查结果，并按照需要做一些调整。
因此配置自动化是一个有用的辅助手段，比批处理脚本更好，但是我们的用法并没有避免服务器不一致的蔓延。从零开始的云
当我们开始往云上迁移时，一切都改变了。使情况好转的并不是这项技术本身，因为我们用自己的 VMware 服务器也能做到同样的事情。但由于是从零开始，我们采纳了新的服务器管理方法——基于从虚拟服务器集群中学到的经验，以及从 Flickr、Etsy 与 Netflix 等公司的 IT 运维团队那里读到、听到的经验。在将服务器迁移到云上的时候，我们就把这些新的想法融入到了服务的管理方式里面。
这种新方法的关键在于，每台服务器都能够自动化地从零开始重新创建，并且配置工具会持续而非临时地运行。添加到新基础设施的每台服务器都要遵循这种方法。如果自动化在某些边界情况下失败了，我们要么修改自动化脚本，处理这个问题，要么修改该服务的设计，使其不再是边界情况。
这个新方法并非一帆风顺。我们不得不培养新习惯，不得不寻找各种办法来克服高度自动化的基础设施所带来的挑战。当团队成员进入其他组织、参与到诸如 DevOpsDays 的社区里，我们都会不断学习和提高。随着时间的推移，我们终于开始习惯数百台服务器规模的自动化基础设施。与曾经的“魔法师的学徒”岁月相比，我们只需要投入很少的工作量，遇到的烦心事也更少了。
加入 ThoughtWorks 为我打开了一扇新的大门。与我一起工作的开发团队非常热衷于使用来自于极限编程的工程实践，例如测试驱动开发（test-driven development，TDD）、持续集成（continuous 4integration，CI）和持续交付（continuous delivery，CD）。由于我已经使用过源代码控制系统来管理基础设施的脚本和配置文件，将这些严格的开发和测试方法应用于基础设施领域也是水到渠成。4可参阅曾获得第 21 届 Jolt 大奖的《持续交付》一书，其中文版已由人民邮电出版社出版，图书主页为 http://www.ituring.com.cn/book/758。——编者注
在 ThoughtWorks 的工作让我可以与很多 IT 运维团队交流，他们中的很多人都在使用虚拟化、云计算和自动化工具来解决大量问题。在工作中与他们一起分享和学习新的想法与技巧，是一段非常棒的经历。为什么写作本书
我遇见过很多团队处于我几年前的状态：虽然使用了云计算、虚拟化和自动化工具，但却没有竭尽所能发挥其功用。
时间是最大的问题。系统管理员的日常就是疲于应付无休止的紧急任务——灭火、解决问题以及启动新的业务关键项目，没有给简化日常工作的基础性改善任务留下太多的时间。
我希望本书能够从实用的视角，针对如何管理 IT 基础设施介绍一些团队可以尝试和使用的技巧与模式。我将避免陷于配置和使用具体工具的细节之中，而是使内容适用于各种不同的工具，甚至那些尚未面世的工具。同时，我会以现有工具作为例子来展示观点。
基础设施即代码的方法对于管理任何实际规模或复杂性的云基础设施都是非常关键的，但是并不局限于使用公有云的组织。本书介绍的技巧和实践已经被证实适用于虚拟化的环境，甚至未虚拟化的裸机服务器。
基础设施即代码是 DevOps 的基石之一。它就是 CAMS 中的“A”。［CAMS 是指 culture（文化）、automation（自动化）、measurement（度量）和 sharing（分享），详见 IT Revolution 网站上的文章“DevOps Culture (Part 1)”。］本书适合哪些读者
本书适合于维护 IT 基础设施的人，尤其是管理服务器和服务器集群的人，包括系统管理员、基础设施工程师、团队领导、架构师或者对技术感兴趣的经理。本书也适合有意构建和使用基础设施的软件开发人员。
本书默认读者对于虚拟化或 IaaS（infrastructure as a service，基础设施即服务）有一些基础认识，知道如何创建虚拟机和配置操作系统，至少体验过 Ansible、Chef 或 Puppet 等配置自动化软件。
除了作为基础设施即代码的入门指南，本书对已经采取这种工作方式的读者也有所裨益，让大家借此分享想法、交流意见，以便做得更好。本书涵盖哪些工具
本书不会介绍具体脚本语言或工具的用法。书中会提供某些特定工具的代码示例，但都仅仅是为了说明概念和方法，而非教程。无论你是在 OpenStack 上使用 Chef，在 AWS 上使用 Puppet，还是在裸机上使用 Ansible，抑或是完全迥异的技术栈，本书都会有所帮助。
书中提及的特定工具都是我所知晓的、在本领域有一定影响力的。不过这个领域在持续变化，存在着大量其他相关工具。
本书示例中使用的工具一般都是我所熟悉的，能够编写例子来演示我的观点。例如，我使用 Terraform 来编写基础设施定义文件的例子，因为它是一款非常不错、语法干净的工具，而且我在很多项目上用过。本书的很多示例使用了亚马逊的 AWS 云平台，因为读者对它可能最为熟悉。如何阅读本书
阅读第 1 章，至少快速浏览一遍，以理解本书中的术语以及提倡的原则。你可以基于它们来决定应该专注于本书的哪个部分。
如果你对这些自动化、云和基础设施编排工具比较陌生，需要先了解第一部分，再继续第二部分。对前两部分都有所得之后，再阅读第三部分。
如果你使用过本书介绍的自动化工具，但在阅读第 1 章之后，觉得之前并没有遵照这些工具的设计意图来使用，那么可以跳过或者快速浏览第一部分，集中精力在第二部分。第二部分描述了使用动态和自动化基础设施的方法，并且这些方法与第 1 章概括的原则一致。
如果你对第 1 章描述的动态基础设施与自动化方法已经很熟悉了，可以快速浏览第一部分和第二部分，集中精力在第三部分。第三部分更深入地探讨了基础设施管理领域：架构方式与团队工作流。排版约定
本书使用以下排版约定。● 黑体表示新术语和重点强调的内容。● 等宽字体（constant width）表示代码程序，以及正文中出现的变量名、函数名、数据库、
数据类型、环境参数、语句和关键词等。● 等宽粗体（constant width bold）表示由用户输入的命令或者其他文本。● 等宽斜体（constant width italic）表示需要由用户输入的值或根据上下文确定的值进行替换的
文本。 该图标表示提示或建议。 该图标表示一般性说明。 该图标表示警告或注意事项。®Safari在线图书
Safari Books Online（http://www.safaribooksonline.com）是应运而生的数字图书馆。它同时以图书和视频的形式出版世界顶级技术和商务作家的专业作品。技术专家、软件开发人员、Web 设计师、商务人士和创意专家等，在开展调研、解决问题、学习和认证培训时，都将 Safari Books Online 视作获取资料的首选渠道。
对于组织团体、政府机构和个人，Safari Books Online 提供各种产品组合和灵活的定价策略。用户可通过一个功能完备的数据库检索系统访问 O'Reilly Media、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 以及其他几十家出版社的上千种图书、培训视频和正式出版之前的书稿。要了解 Safari Books Online 的更多信息，我们网上见。联系我们
请把对本书的评价和问题发给出版社。
美国：
O'Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
北京市西城区西直门南大街 2 号成铭大厦 C 座 807 室（100035）
奥莱利技术咨询（北京）有限公司
O'Reilly 的每一本书都有专属网页，你可以在那里找到本书的相关信息，包括勘误表、示例代码以及其他信息。本书的网站地址是：http://shop.oreilly.com/product/0636920039297.do。
对于本书的评论和技术性问题，请发送电子邮件到：bookquestions@oreilly.com
要了解更多 O'Reilly 图书、培训课程、会议和新闻的信息，请访问以下网站：
http://www.oreilly.com
我们在 Facebook 的地址如下：http://facebook.com/oreilly
请关注我们的 Twitter 动态：http://twitter.com/oreillymedia
我们的 YouTube 视频地址如下：http://www.youtube.com/oreillymedia致谢
当我开始编写此书的时候，以为全部内容都将来自于我个人的总结。但最后的事实却恰恰相反：本书是很多人的想法、思考、观点以及经验的结晶，远远超出我的想象。我可能提取、简化或者曲解了大家的观点。但是如果没有这些贡献，本书就根本不会存在。
我从田纳西大学计算机科学实验室的同事们那里学到了 Unix 的技巧和文化。尤其是 Chad Mynhier 对于我进入 Unix 世界提供了极大的帮助。他向我详细解释了为什么执行了 chmod 命令之后就再也无法用 cd 进入我自己的 home 目录。
与 Syzygy、Vizyon、Cellectivity 以及 Map of Medicine 等一系列公司的合作经历，让我有充分的空间来强化对于基础设施自动化的理解，并且学习如何将基础设施自动化应用到现实世界的业务和用户问题上。这在很大程度上归功于这些组织里的很多优秀同事。我尤其要感谢 Jonathan Waywell 和 Ketan Patel 无止境的支持与鼓励；感谢 Andrew Fulcher 能够快速了解我要传递什么知识，并且教会我更多；感谢 Nat Billington 的灵感。
如果没有我现在的“家”——ThoughtWorks，本书根本不可能面世。由于 5 年多来我在这里参与了众多不同规模、不同行业以及不同技术的客户项目，因而学到了本书中的很多知识，以及如何去思考和向人们表达。前同事和现同事的无穷好奇心，他们发自内心想改善这个行业的驱动力，以及行业里同道中人的经验，都持续地激励着我不断向前。
作为一家公司，ThoughtWorks 给予的慷慨支持和鼓励对于本书至关重要，尤其是当截止时间临近、我精力不殆的时候。Chris Murphy、Dave Elliman、Maneesh Subherwal、Suzi Edwards-Alexander 以及其他很多人，让本书变得不仅仅是我一个人的项目。
ThoughWorks 的很多前员工和现员工都不辞辛劳地分享了他们的建议、反馈和其他支持，下面列举其中的一些：Abigail Bangser、Ashok Subramanian、Barry O'Reilly、Ben Butler- Cole、Chris Bird（DevOops!）、Chris Ford、David Farley、Gurpreet Luthra、Inny So、Jason Yip、Jim Gumbley、Kesha Stickland、Marco Abis、Nassos Antoniou、Paul Hammant、Peter Gillard-Moss、Peter Staples、Philip Potter、Rafael Gomes、Sam Newman、Simon Brunning、Tom Duckering、Venu Murthy 和 Vijay Raghavan Aravamudhan。
Martin Fowler 在我撰写本书时给予了大量的鼓励和实际帮助。他投入的时间远远超过我的请求，多次、全面地审校了本书的原稿。凭借着梳理和表达技术概念方面的经验，Martin 给了我细致入微、大有裨益的反馈和建议。他是本书真正的捍卫者。
我的同事 Rong Tang 为本书绘制了所有图片。她对于我含糊不清的表达总是极具耐心。如果图片有表述不清或不一致之处，责任在我；但图片的精妙之处都归功于她。5
长期处于休眠状态的 Infrastructures.org 网站 背后的人们让我接触到了基础设施即代码的观念，纵然这个词后来才出现。5遗憾的是，截至 2016 年上半年，Infrastructures.org 一直停留在 2007 年的内容，没有更新。
我非常感谢 DevOpsDays 社区的人们，他们群策群力地把 DevOps 和基础设施即代码的观念发扬光大。不管究竟是谁发明了“基础设施即代码”这个术语，Adam Jacob、Andrew Clay-Shafer、John Allspaw、John Willis、Luke Kaines、Mark Burgess 和众望所归的 Patrick Debois（DevOps 之父）等人都给了我很多启发和好的想法。
很多人给本书的初稿提出了很多反馈和建议，包括 Axel Fontaine、Jon Cowie、Jose Maria San Jose Juarez、Marcos Hermida 和 Matt Jones。我还要感谢 Kent Spillner，虽然记不清楚为什么了，但是肯定有充分的原因。
最后着重感谢我挚爱的 Ozlem 和 Erel，他们忍受了我对本书写作的沉迷。第一部分基础第1章挑战与原则
新一代的基础设施管理技术有望改变 IT 基础设施的管理方式。但是，许多组织目前并没有看到显著的差异，有些甚至认为这些工具让管理更为混乱。我们将在本书中看到，基础设施即代码的方法提供了有效应用这些技术的原则、实践与模式。1.1 为什么采用基础设施即代码
虚拟化、云、容器、服务器自动化和软件定义网络（software-defined network，SDN）理应简化 IT 运维工作。服务的置备、配置、更新和维护理应花费更少的时间和精力。问题应该被迅速地发现和解决，系统配置应该全部一致并且及时更新。IT 人员应该减少在日常苦差事上投入的时间，有余暇快速地执行变更和改进，以帮助组织适应现实世界里不断变化的需求。
然而，即便拥有最新、最好的工具和平台，IT 运维团队也很难完成每天的工作。他们没有时间去解决系统长期存在的问题，更没有时间去掌握这些最新的工具。事实上，云和自动化往往让事情变得更糟。新基础设施的置备（provision）很容易，导致系统组合不断增长，而防止这一切崩溃又需要投入越来越多的时间。
采用云和自动化工具立刻降低了基础设施变更的门槛，但这些工具并没有可以提高一致性和可靠性的现成方法来管理变更。这需要人们去思考如何使用这些工具，并且形成高效使用它们的系统、流程和习惯。
一些 IT 组织使用他们在云和自动化时代以前用于管理基础设施和软件的流程、结构和治理方式来应对挑战。但是，那些原则在需要花费几天或几周来置备新服务器的时代或许有效，而在当今这个只需要几分钟甚至几秒钟就能完成同一任务的时代，它们已经力不从心了。
急着完成任务的人们往往会忽略、绕过或者否决传统的变更管理1流程。 可以越来越多地看到，成功推行这些流程的组织被技术上更灵活的竞争对手超越。1“影子 IT”是指人们绕过正式的 IT 管理，使用自己的设备，并且购买和安装未受认可的软件，或者采用云托管服务。这个迹象表明内部 IT 无法跟上所服务组织的需求。
传统的变更管理方法难以应对云和自动化提供的变更节奏。尽管云和自动化工具导致系统日益增长、不断变化，我们仍然需要积极应2对。这就是基础设施即代码 的用武之地。2“基础设施即代码”（infrastructure as code）这个说法并没有明确的来源或作者。在写作本书时，我关注了一群影响了这一概念的人，而每个人都说自己没有创造这个概念，只是提供了一些建议。他们之间互相进行了借鉴。我能找到对其的最早引用出于 2009 年 Andrew Clay Shafer 和 Adam Jacob 在 Velocity 大会上的演讲。John Willis 可能是第一个记录了这一说法的人，详见其在 IT Knowledge Exchange 上关于此次大会的文章“Infrastructure as Code”。Luke Kaines 承认他可能也参与其中，是最接近于接受这个荣誉的人。“铁器时代”和“云时代”在 IT 的“铁器时代”，系统都直接安装在物理硬件上。基础设施的置备和维护都是手动作业，迫使人们花费时间点击鼠标、输入命令来保持系统运转。由于变更涉及很多工作，变更管理流程强调细致的前期考虑、设计和审查工作。因为错误的代价非常昂贵，所以这个流程是合理的。在 IT 的“云时代”，系统与物理硬件解耦了。日常的置备和维护可以委托给软件系统，让人类从苦差事中解放出来。在几分钟甚至几秒钟之内就能做出变更。变更管理可以利用这样的速度，提供更快的上市速度和更高的可靠性。1.2 什么是基础设施即代码
基础设施即代码是一种基于软件开发实践的基础设施自动化方法。它强调系统及其配置的日常置备和变更具有一致性和可重复性。先修改配置的定义代码，再通过包括全面验证的无人值守过程应用到系统中去。
这种方法的前提是，现代工具可以把基础设施作为软件和数据进行处理。这允许人们在管理基础设施时应用软件开发工具，如版本控制系统（VCS）、自动化测试类库和部署编排工具。这也为利用诸如测试驱动开发（TDD）、持续集成（CI）和持续交付（CD）等开发实践打开了大门。
基础设施即代码已在最苛刻的环境中得到了验证。对于像亚马逊、Netflix、谷歌、Facebook 和 Etsy 这样的公司，IT 系统不仅是业务的关键，而且本身就是业务。宕机是无法容忍的。亚马逊的系统每天处理数亿美元的交易。因此，诸如此类的组织为大规模、高可靠性的 IT 基础设施开拓新的实践不足为奇。
本书旨在解释如何利用云时代的基础设施即代码方法来管理 IT 基础设施。本章探讨了组织在采用新一代基础设施技术时经常掉进的陷阱，详述了避开这些陷阱的核心原则以及基础设施即代码的关键实践。基础设施即代码的目标
很多团队和组织期待通过基础设施即代码实现如下目标。● IT 基础设施支持并允许变更，而不是成为阻碍或者约束。● 对系统的变更是家常便饭，不应该对用户或者 IT 人员造成惊吓
或者压力。● IT 人员把时间花费在体现自身能力的有价值的事情上，而不是
花费在处理日常的重复性工作上。● 用户可以自行定义、置备和管理他们需要的资源，不需要 IT 人
员参与。● 团队能够轻松、快速地从故障中恢复，而不是假设可以完全避免
故障。● 持续地改进，而不是通过昂贵且危险的“大爆炸”项目去改进。● 通过实施、测试和测量来验证问题解决方案，而不是利用会议和
文件进行讨论。基础设施即代码不仅仅适用于云基础设施即代码经常和云一起出现，因为在云上不这么做很难管理好服务器。但是基础设施即代码的原则和和实践不仅可以应用在云和虚拟化系统上，甚至可以直接应用在物理硬件上。我使用“动态基础设施”一词指代程序化创建和销毁服务器的能力，第 2 章会着重介绍这个主题。云可以很自然地处理这些，虚拟化平台也可以通过配置来实现同样的功能。即便是硬件，也可以自动化置备，从而以完全动态的方式使用。有时候这也叫作“裸机云”。静态基础设施也可以使用基础设施即代码的很多概念。手动置备的服务器可以通过服务器配置工具进行配置和更新。然而，对于本书中描述的很多高级实践，毫不费力地销毁并重建服务器的能力是不可或缺的。1.3 动态基础设施的挑战
本节关注团队采用动态基础设施和自动化配置工具时常见的一些问题。这些问题是基础设施即代码要着力解决的，因此充分了解它们是学习后续原则和概念的基础。1.3.1 服务器蔓延
利用云和虚拟化，从资源池置备新的服务器可谓小菜一碟。这会导致服务器的数量飞速增长，甚至超过团队能够管理或者希望管理的规模。
当这种情况发生时，团队会忙于给服务器打补丁并且让它们保持更新，系统容易受到已知漏洞的影响。当发现问题时，补丁无法及时地应用到可能受影响的所有系统上。服务器之间的版本和配置差异意味着在一些机器上运行良好的软件和脚本无法在其他机器上运行。
这会导致服务器之间的不一致，也叫作配置漂移。1.3.2 配置漂移
即便服务器在最初创建和配置的时候是一致的，其差异也会随着时间而增加。● 有人在一台 Oracle 服务器上做了一次修改，修复了一个特定用
户的问题，现在它和其他的 Oracle 服务器就不同了。● 新版本的 JIRA 需要新版本的 Java，但是没有时间去测试其他所
有基于 Java 的应用是否都可以升级。● 3 个人在几个月内分别在不同的 Web 服务器上安装了 IIS，并且
每个人配置得都不一样。● 某台 JBoss 服务器比其他服务器接受了更多的流量并且开始出
现性能问题，有人对它进行了性能调优，之后它的配置就和其
他 JBoss 服务器不同了。
不一样并非不好。相比负载较低的服务器，负载高的 JBoss 服务器理应有不同的调优配置。但是这些变化应该以一种易于重现和重建服务器及服务的方式进行捕获和管理。
服务器间未经管理的变化会导致雪花服务器的产生和对自动化的恐惧。1.3.3 雪花服务器
雪花服务器和网络中的其他所有服务器都不同。它非常特殊，无法复制。
几年前，我在一家为客户构建 Web 应用的公司里管理服务器，其中大部分 Web 应用都是庞大、复杂的 Perl CGI 脚本。（不要批评我们，那是 .COM 年代，大家都这么做。）我们一开始使用的是 Perl 5.6，但是后来最好的类库都升级到了 Perl 5.8，而且不兼容 5.6。最后，几乎所有的新应用都是基于 Perl 5.8 实现的，但是有一个特别重要的客户应用程序就是无法运行在 5.8 上面。
实际的情况比这更糟糕。这个应用程序在升级共享的预发布服务器到 5.8 时运行正常，但是在升级预发布环境时却崩溃了。不要问我们为什么没有解决预发布环境的问题就把产品环境升级到了 5.8，最后的结果就是这样的。我们有一台特殊的服务器可以运行 Perl 5.8 的应用程序，但其他服务器都不行。
我们就这样可耻地持续了很长时间——在预发布服务器上保留 Perl 5.6，每次部署到产品环境时都祈祷不要出问题。我们不敢触碰产品服务器上的任何东西，害怕解除能使唯一服务器运行客户应用的魔法。
这样的情况促使我们发现了 Infrastructures.org，这个网站为我打开了基础设施即代码的大门。我们确保以可重复的方式构建所有的服务器，用全自动安装（fully automatic installation，FAI）工具安装操作系统，用 CFEngine 配置服务器，并将所有的东西都用版本控制系统管理起来。
大多数 IT 运维团队都有过这样的尴尬：不能触碰或者难以复制服务器。如此脆弱的原因并非总是神秘莫测，有时是因为某个重要的软件运行在与其他服务器完全不同的操作系统上。我记得有个会计软件需要运行在 AIX 上，而另一个运行在 Windows NT 3.51 服务器上的 PBX 系统则是由一个已被遗忘的承包商特别安装的。
再次强调，不一致并非坏事。问题在于拥有服务器的团队对于服务器如何以及为何不一致一无所知，并且无法重建服务器。运维团队应当能够自信、快速地重建基础设施中的任意服务器。如果有任何服务器不能满足这个需求，团队的最高优先级应该是设立一个可复制的全新流程，来构建一台新的服务器并替换掉老的服务器。1.3.4 脆弱的基础设施
脆弱的基础设施很容易中断，而且不容易修复。这是由于雪花服务器问题扩展到了整个系统组合。
解决方案是逐步将基础设施中的一切迁移到可靠、可复制的基础3设施里。Visible Ops Handbook 一书论述了如何在困难的基础设施上实现稳定性和可预测性。3于 2005 年出版，由 Gene Kim、George Spafford 和 Kevin Behr 合著，成书的时间早于 DevOps、虚拟化以及自动化配置成为主流的时间，但是很容易看出如何在作者描述的框架中应用基础设施即代码。不要碰那台服务器，别指它，甚至不要看它这也许是一个虚构的故事：数据中心里有一台服务器，没有人知道登录的信息，也没有人知道那台服务器的作用。有人以身犯险，将那台服务器的电缆从网络中拔掉。整个网络彻底断了。于是，电缆被重新插回，没有人敢再动那台服务器了。1.3.5 自动化恐惧症
在 DevOpsDays 大会上关于配置自动化的开放空间演讲中，我问在座的人当中有多少在使用类似 Puppet 或者 Chef 之类的自动化工具。大多数人都举手了。我又问有多少人以无人值守、自动排期的方式运行这些工具。只剩少数人的手还举着。
很多人都存在我在早期使用自动化工具时所遇到的问题。我那时选择性地使用自动化，例如为了构建新的服务器，或者进行特定配置的修改。每次运行自动化工具的时候，我都会调整配置，让它去适应我在做的任务。
我之所以不敢完全信任自动化工具，是因为我对它们做的事情缺乏信心。
我之所以缺乏对自动化的信心，是因为我的服务器不一致。
我的服务器之所以不一致，是因为我没有频繁和一致地执行自动化。
这就是自动化恐惧恶性循环，如图 1-1 所示。基础设施团队需要打破这种恶性循环，才能成功实施自动化。最有效的方式是直面恐惧。挑选一组服务器，调整配置定义，确保它们可以工作，并安排它们至少每小时以无人值守的方式运行一次。然后，挑选另一组服务器并重复这个过程，直到所有的服务器都持续更新。图 1-1：自动化恐惧恶性循环
本书第三部分提到了良好的监控和有效的自动化测试制度，有助于我们树立可靠地应用配置以及快速定位问题的信心。1.3.6 侵蚀
理想情况下，一旦基础设施被自动构建出来，你就永远不需要去4触碰它了，除非需要支持更新或者修复问题。可悲的是，熵力 意味着即使没有新的需求，基础设施也会随着时间衰败。Heroku 的人们把这称为侵蚀（erosion resistance）。侵蚀的意思是，问题随着时间的推移蔓延到正常工作的系统之中。4熵力在物理学中是指系统中的一种宏观作用力，其性质表现为整个系统对于熵增加的统计趋势。——编者注
Heroku 列举了以下随着时间侵蚀系统的因素。● 操作系统升级、内核补丁以及基础设施软件（如 Apache、
MySQL、SSH、OpenSSL）修复安全漏洞的升级补丁。● 服务器磁盘被日志文件塞满。● 一个或者更多应用进程崩溃或者卡住，需要有人登录并且重启它
们。● 底层的硬件失败导致一台或者更多服务器以及在它上面运行的应
用出现问题。1.4 基础设施即代码的原则
本节将介绍一些能够帮助团队克服上述挑战的原则。1.4.1 系统能够轻松复制
我们应该能够毫不费力并且可靠地重建基础设施中的任何元素。毫不费力意味着无须对于如何构建元素做出任何重大的决策。在服务器上安装什么软件、安装软件的什么版本以及选择什么主机名等决策都应该包括在置备基础设施元素的脚本和工具中。
这种毫不费力地创建和重建基础设施任意部分的能力是非常强大的。在变更的时候，风险会更小，无须过多担心。我们可以有信心地快速处理故障，无须花费什么力气即可置备新的服务或环境。
本书的第二部分会讨论如何以可复制的方式置备服务器以及其他基础设施元素。1.4.2 系统是用完可扔的
动态基础设施的好处之一是可以轻松创建、销毁、替换、扩容和移动资源。为了利用这一点，设计系统时必须假设基础设施始终在变更。即使服务器消失了、出现了或者大小改变了，软件也应该依然正常运行。
这种优雅处理变更的能力让增强和修复正在运行的基础设施变得更容易，也使得服务具有更强的容错性。当共享大规模的云基础设施无法保证底层硬件的可靠性时，这种能力变得尤为重要。 牲口，而非宠物5有一句流行的话：“将你的服务器视作牲口，而不是宠物。” 我很怀念那些为服务器名称指定一个主题，然后为每个新置备的服务器小心选择名称的时光。但我一点也不怀念不得不手动调整每台服务器的时光。5 CloudConnect 的首席技术官 Randy Bias 在演讲“Architectures for Open and Scalable Clouds”中将这个说法归功于前微软员工 Bill Baker。我是在 Gavin McCance 的演讲“CERN Data Centre Evolution”中第一次听到这个说法。这两个演讲都非常精彩。
铁器时代和云时代的根本差异在于，铁器时代是不可靠的软件运行于可靠的硬件之上，而云时代是软件可靠地运行于不可靠的硬件之
6上。 第 14 章会详细介绍采用用完可扔的基础设施能如何提升服务的连续性。6 Sam Johnson 在他的文章“Simplifying Cloud: Reliability”中表述了硬件与软件可靠性的观点。消失的文件服务器服务器并不是永久存在的，这个理念需要一段时间才能被人们领会。我们曾在一个团队中使用 VMware 和 Chef 建立起了自动化的基础设施，并且养成了随意删除和替换 VM 的习惯。有个开发人员需要一台 Web 服务器来放置文档并供团队其他成员下载使用，因此在开发环境中的一台服务器上安装了 Web 服务应用程序并放置了文档。几天后，他吃惊地发现这台服务器上的 Web 服务应用程序和文档都不见了。这名开发人员有些困惑，随后在 Chef 配置中加入了针对其文件仓库的配置，利用该工具的优势把数据持久化到 SAN 中。这个团队最终拥有了一个高度可靠、自动配置的文件共享服务。
试读结束[说明：试读内容隐藏了图片]