书评与摘要：Infrastructure as Code-InfoQ

关键要点

在这本书中作者描写了基础设施即代码、动态基础设施平台、一些基础设施定义和服务器配置工具。

作者详细描写了处理动态基础设施时可能遇到的一些挑战，以及处理时的一些原则和实践。

书中覆盖了部署服务器、管理服务器模板、更新服务器和定义基础设施等的模式。

作者提到了一些从软件开发实践中总结出来的实践建议，可用于建立和维护一套可定性的基础设施。

一些书中提到的其它内容包括：自动化基础设施中的持续提交、运维团队工作流、连续性和组织原则。

在这篇文章中我们简单介绍 Kief Morris 的新书“ Infrastructure as Code - Managing Servers in the Cloud ”，他在 ThoughtWorks 欧洲公司领导持续提交和 DevOps 工作。在长达 300 页的篇幅里，Morris 写明了基础设施即代码的基础，并提出了构建它的主要模式和建议实践行为。

我们从问作者一些和书相关的问题开始。

InfoQ: 能请您讲讲你在公司中的职责吗？

Kief Morris：作为 ThoughtWorks 在英国的云实践部门负责人，我主要是帮助客户们使用云、基础设施和平台来提交和运行软件。这个行业发展太快了。大概一年前，云还只是一个让初创公司免于传统 IT 运维之苦的工具，而现在，传统 IT 公司都在找办法他们可以怎样使用云。

InfoQ: 为什么云和自动化让基础设施团队遇到了更大挑战？

Morris：云带来的好的一方面是它让公司中的任何人都可以轻松部署、配置和管理他们需要的基础设施。可关于云糟糕的事情也恰恰是相同的。基础设施团队怎样才能让用户有非常良好的使用体验，而不是给他们一套配置粗糙、不安全不稳定的系统？

InfoQ: 为什么大家应该采用基础设施即代码的方法？

Morris：基础设施即代码为大家带来的是应对动态基础设施的软件工程中的原则、实践和工具。基础设施被定义为文件，用源码控制工具管理，一致地应用在不同环境中，并且通过管道测试和提升。基础设施代码用松耦合的方式组织，可以减少技术债务并允许多个团队一起有效地并行工作。

这种方式意味着变更可以比手工方式更快更频繁地提交，而且更稳定、更可控。业务团队可以自行编辑和上传文件来配置他们的环境。如果基础设施团队可以把精力花在确保管道和自动化测试足够强大上，从而可以在有问题的内容提交到核心系统之前就发现的话，他们就不必把时间花在手工完成业务团队的每次请求上。这对于涉及到的每一个人都是个非常重要的良性循环。

InfoQ: 如果一个公司采用基础设施即代码的方式的话，她有没有碰到什么陷阱的风险？

Morris：很多基础设施团队采用了云和自动化技术，却没有采用相应的自动化测试和发布流程。它们把这些当作一门过于复杂的脚本语言来使用。他们会为每一次具体的改动编写手册、配置文件和执行脚本，再针对一部分指定的服务器手工运行它们，也就是说每一次改动都还需要花费专业知识、时间和精力。这种工作方式意味着基础设施团队没有把他们自己从日常的重复性劳动中解放出来，他们在需要做变更时也不能减少破坏系统的风险，也没能对他们的用户产生帮助。

这本书分为三部分：基础、模式和实践。在第一部分，作者描述了基础设施即代码、动态基础设施平台、一些基础设施定义和服务器配置工具，以及关于基础设施服务应该如何在动态设置中工作的一些建议。在处理动态基础设施时碰到的挑战有：服务器散乱、配置漂移、雪花服务器、脆弱的基础设施、自动化恐惧和腐蚀等。

Morris 提到的在动态基础设施背后的原则有：

系统可以轻易重建；
系统可被随意处理；
系统是一致的；
流程可重复；
设计经常改变；

除了上述原则，作者也详细描述了在构建基础设施即代码时的一些推荐实践：

使用定义文件；
创建自动记录的系统和流程；
将所有东西版本化；
实现持续测试；
做小的改动；
持续保证服务在线；

书的第二部分包括部署服务器、管理服务器模板、更新服务器和定义基础设施的模式。提到部署服务器时，作者提到了一个反模式——手工安装服务器和将运行中的服务器克隆。作者建议应该使用脚本去安装服务器，应该用模板去创建服务器，而不是克隆一个正在运行中的。

在书的最后一部分，作者提到了一些从软件开发实践中总结出来的实践建议，可用于建立和维护一套可定性的基础设施。Morris 解释了如何测试基础设施的改动，尤其是做自动化测试就意味着在基础设施中验证改动。这对于及早发现配置问题、避免随着时间推移而构建出脆弱的系统非常重要。作者建议采用敏捷的方法做测试，将测试集成到管理基础设施、在每次变更后执行测试的自动化流程中。他也把测试分了级：验证定义文件的低级测试、验证服务器角色的中级测试和测试多层服务的高级测试。

Morris 也解释了如何通过构建变更管理管道来将持续提交引入自动化的基础设施中。这个实践的关键是要“创建一个优化过的流程来快速和严格地验证持续的小变更流”。

有一章专门用于指导运维团队在全自动化环境中构建工作流。这样的工作流的主要特征包括速度和可靠性：“必须有足够快的方式把交更提交到生产系统上，这是处理紧急事件的正确办法”和“做出变更的人必须有自信变更会如愿工作，也知道它会不会产生新问题”。

第 14 章讨论了“连续性”，这是一个用于在生产环境中表达运维质量的词。运维团队要保证服务在正确运行、及时响应和提供正确的数据。整个过程都必须确保符合安全要求。传统的运维持续性方法是尽可能地限制变更的产生，基础设施即代码则反其道而行之，要求按需使用基础设施时要有最大的弹性。在这一章中，作者解释了如何才能达到这样的效果。

在书的最后一章，作者提炼了在公司中实施基础设施即代码的几个原则：

要有一连串的方法来设计、实现和改进服务；
使团队能够自己去持续提交和改进服务；
在快速和持续提交的同时保证高质量和高兼容；

为了让大家对书的内容和风格有更好的理解，我们从书“Working with Infrastructure Definition Tools”的第三章“基础设施定义工具”（ O’Reilly 出版）中节选了一段。其中涉及到的内容包括：用过程性脚本部署基础设施、用声明的方式定义基础设施、配置服务器、配置注册表等。

关于书的作者

Kief Morris是 ThoughtWorks 公司的云实践部门负责人。他非常乐于帮助有想法的公司在软件提交和运维方面采用颠覆性的想法。这包括云平台、基础设施自动化、DevOps 和持续提交等。最初是在田纳西州，从.com 时代 Kief 就开始在伦敦打造团队以服务方式提交软件。他是‘Infrastructure as Code’ (O’Reilly 出版) 的作者。