前言

前言

在构建和管理基础设施的过程中,基础设施团队与软件开发团队正在越来越多地使用名为“基础设施即代码”的自动化工具。这些工具要求用户在类似软件源代码的文件中定义服务器、网络以及基础设施的其他元素。它们会编译并解读这些文件,以决定采取哪些行动。

这类工具随着 DevOps 运动 1 蓬勃发展。DevOps 运动主要是关于软件开发人员与软件运维人员之间的文化和协作。基于软件开发范式的基础设施管理工具促进了开发与运维的融合。

1Andrew Clay Shafer 与 Patrick Debois 在 Agile 2008 大会上的演讲引发了 DevOps 运动。Debois 组织的一系列 DevOpsDays 大会极大推动了 DevOps 运动。

基础设施即代码的管理方式与传统的基础设施管理方式迥然不同。我遇到过不少团队努力地去实现这一转变,但是有效应用这些工具的理念、模式与实践却只在各种大会演讲、博客以及文章里提及过。我一直在等待一本书,能把这些想法整合到一起,但迟迟没有看到有人写作的迹象,于是我最终决定亲自动手。你正在阅读的这本书就是我努力的成果。

我是怎样学着不再担忧并且爱上云的

1992 年,我搭建了自己的第一台服务器——一个拨号的 BBS2,由此成为 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 integration,CI)和持续交付(continuous delivery,CD)4。由于我已经使用过源代码控制系统来管理基础设施的脚本和配置文件,将这些严格的开发和测试方法应用于基础设施领域也是水到渠成。

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 为本书绘制了所有图片。她对于我含糊不清的表达总是极具耐心。如果图片有表述不清或不一致之处,责任在我;但图片的精妙之处都归功于她。

长期处于休眠状态的 Infrastructures.org 网站 5 背后的人们让我接触到了基础设施即代码的观念,纵然这个词后来才出现。

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,他们忍受了我对本书写作的沉迷。

电子书

扫描如下二维码,即可购买本书电子版。

{%}

目录

  • 版权声明
  • O'Reilly Media, Inc. 介绍
  • 中文版推荐序
  • 译者序
  • 前言
  • 第一部分 基础
  • 第 1 章 挑战与原则
  • 第 2 章 动态基础设施平台
  • 第 3 章 基础设施定义工具
  • 第 4 章 服务器配置工具
  • 第 5 章 基础服务概述
  • 第二部分 模式
  • 第 6 章 置备服务器的模式
  • 第 7 章 管理服务器模板的模式
  • 第 8 章 服务器更新与变更模式
  • 第 9 章 定义基础设施的模式
  • 第三部分 实践
  • 第 10 章 基础设施的软件工程实践
  • 第 11 章 测试基础设施变更
  • 第 12 章 基础设施的变更管理流水线
  • 第 13 章 基础设施团队的工作流
  • 第 14 章 动态基础设施的连续性
  • 第 15 章 基础设施即代码的组织要求
  • 关于作者
  • 关于封面