前言

初看《基础设施即代码》这本书(亚马逊有英文影印版)的时候,觉得基础设施即代码可能和IaaS、PaaS这些概念类似,应该和云计算有关;而自己做过虚拟化的项目,感觉应该不会吃力。不过真正看起这本书的时候,还是觉得有些吃力,主要原因是里面的一些版本管理及其他工具之前没有接触过或者接触不多。
吃力归吃力,读书的过程自己观念还是得到了一些更新。个人觉得这本书最大的意义在于让我们了解,基础设施也可以按照代码管理的思路去管理,从而去实现基础设施的自动化部署,并且保证可靠性,持续交付。所有的目的就是让我们的基础设施健壮,并让我们拥有持续交付的能力,而且不需要把时间总是花在一些重复的劳动上。因为我只读了第一遍,所以有些地方可能没有覆盖到,你可以自己去发现。
这次的分享我将按照自己的知识体系更新,按三大块来分享,主要分为观念的更新,工具集的更新,以及自己可以采取的行动。

一、观念的更新

从整体架构上,本书第一部分主要介绍了“基础设施即代码”的一些基本知识。例如什么是动态基础设施平台,我们都需要从哪些方面去定义它们。结合服务器的创建、置备、更新等生命周期,我们该如何利用CFEngine、Puppet、Chef、Ansible等自动化工具实现服务器全生命周期的自动化。
第二部分使用了单独的章节介绍服务器置备、服务器模板镜像管理和服务器变更管理。第二部分的最后一章提升到了更高的层次,基于服务器管理的模式描述了管理多种基础设施元素和环境的方式。
第三部分则主要从工程实践角度出发,讲解了如何开展测试、如何管理变更、如何确保持续性等内容。
以下是我阅读过程觉得需要记录的一些点,供大家参考:

1.1 要自动化部署服务器

自动化服务器管理的目标:
能够完全按需置备一台新服务器,等待时间不超过数分钟。
置备新服务器时完全不用人工参与,比如不需要人工响应事件。
当定义了服务器配置变更之后,向服务器应用该变更的过程不需要人工参与。
每个变更都应该被应用到所有相关的服务器,而且在该变更之后置备的新服务器都应该包含该变更。
置备以及变更服务器的过程具有可重复性、一致性、自文档和透明化等特性。
修改置备服务器以及变更配置的流程既容易又安全。
每次修改服务器配置定义以及修改置备服务器和更改服务器的流程都会触发运行自动化测试。
配置的变更和处理基础设施任务的流程变更都应版本化,并且要应用到不同的环境中,以便支持对照性测试和阶段性发布策略。

1.2 容器和虚拟机概念上并非一样

从使用硬件资源角度看,容器不是虚拟机。容器没有模拟硬件,与主机服务器使用同一个操作系统,而且实际运行在同一个内核上。容器系统使用操作系统特性来隔离进程、文件系统和网络,运行在容器中的进程就像运行在独立的系统中。这靠的是严格限定该进程的访问权,而不是模拟硬件资源。 使用容器的最佳方式是将它作为一种打包服务、应用程序或者任务的方法。它是一种快速建造的方式,将应用程序加入它的依赖当中,并提供一种标准方式让其主机系统管理自身的运行时环境。

1.3 容器的好处之一是程序环境与主机环境解耦

容器化系统的价值在于,它为容器镜像和工具提供了一种标准格式来构建、分发和运行这些镜像。在 Docker 出现之前,团队可以使用相同的操作系统特性来隔离运行的进程,但 Docker 以及类似工具大大简化了这一过程。 容器化的好处如下:
将具体应用程序的运行时需求与容器运行的主机服务器解耦; 通过容器镜像可以重复创建一致的运行时环境,而该容器镜像可以被分发和运行在任何支持该运行时的主机服务器上; 将容器定义为可以被 VCS 管理的代码(比如在 Dockerfile 中),从而用来触发自动化测试,并通常拥有基础设施即代码的所有特性。

1.4 容器安全关注点之一在于镜像包安全

讨论容器时一个不可避免的话题就是安全性。容器提供的隔离性会引导人们认为容器提供的内在安全性比实际上要多。如果没有小心对待社区提供的镜像,Docker 基于其来构建定制化容器的模式会导致严重的漏洞

1.5 凤凰服务器应该是指经受了磨难可以自动重建的服务器(8.2.3的补充内容)

作者用凤凰服务器的意思,应该是凤凰涅槃、浴火重生,就是历经劫难、义无反顾,置之死地之后重获新生。有些章节也提到netflix定期自己破坏掉他们的部分服务器,看到底多久可以重建起来。 这样经过劫难的服务器,才是足够强健的。 https://martinfowler.com/bliki/PhoenixServer.html

1.6 对于大规模服务器,要自动化并将人员价值体现在更有意义的事情上

第二部分侧重于介绍服务器的置备和配置。第9章将探讨怎样置备和配置更大的基础设施元素组。随着基础设施的规模、复杂度和用户数不断增长,基础设施即代码的收益越来越难实现: 特定变更的影响范围越来越大,从而很难实现频繁、快速和安全的变更;
人们在例行维护和救火上花费更多时间,在为服务带来有价值的提升上花的时间越来越少;
允许用户置备和管理自己的资源可能会对其他用户和服务造成破坏。
典型的应对方式就是对基础设施实施集中式的控制。这会导致在会议、文档和变更流程上花费更多时间,在给组织增值的活动上花费的时间越来越少。

除了集中控制,另一个选项是设计基础设施以最小化特定变更的影响范围。即使基础设施的规模变得更大,一种定义、置备和管理基础设施的有效方式也将支持频繁和充满信心的变更。这就允许将应用和服务基础设施安全地委托出去。

1.7 基础设施即代码的涵义就是使用软件管理的思想来管理系统和设备

基础设施即代码的涵义是,运行软件的系统和设备本身就可以当作软件来对待。这样才能够在基础设施领域采用那些在软件开发领域中被证明有效的实践和工具。

1.8 软件和基础设施开发中保障质量的一些原则

及早开始交付可工作、有用的代码;
持续进行小而有用的增量交付;
只做当下必要的构建;
每一次增量构建都尽可能简单;
确保每一个变更都是精心设计和实现的;
尽早收集每一个变更的反馈;
随着你和用户对系统的学习,改变需求是意料之中的事情;
假设交付的一切都将随着系统的演化而变更。

1.9 持续交付不是持续部署(10.4.3)

持续交付(Continuous Delivery)的概念使得发布决策变为了商业决策而不是技术决策。 关于 CD 的一个误解是,它意味着每一个变更在提交并通过自动化测试后,需要立即应用到生产环境。虽然有些组织实际上是按照持续部署的做法来应用持续交付,但大多数组织并不是这样。CD 的要点不是将每一个变更立即应用到生产环境,而是确保每个变更都可以部署到生产环境。

这仍然需要决定什么时候真正地将特定的变更或者发布版本推送到生产环境。这可以由人来决定,但是由工具自动执行。实现决策流程的授权和审核甚至也会成为可能。

CD 的伟大之处在于将发布的决策变成商业决策,而非技术决策。其实技术验证早已在每一次提交时完成。

1.10 始终关注质量

10章回顾了一些核心的软件开发实践,以及它们如何与基础设施即代码一起工作。这些实践的核心问题是质量。为了保证系统和定义系统的代码的质量,必须把对质量的关注放在首位。

将系统的质量置为高优先级,持续接受反馈并立即采取行动,这样的团队才能让流程良性循环。他们有信心定期做一些小的修复和调整,从而保障系统的顺利运行。这也让他们可以把更多的时间花费在更令客户满意的、更高优先级的工作上,而不是天天忙于救火。

1.11 要管理技术债务,让它可控

我们不要养成“认为现在已经足够好”的坏习惯。
技术债务的四象限(10.5.2) https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

1.12 灾难恢复:Netflix 和“猿猴军团”(14.4.1)

Netflix 使用了名声在外的自动化工具“混乱猴子”(Chaos Monkey)来证明基础设施的弹性可以承受单个服务器的故障。“混乱猴子”自动地半随机销毁一些服务器实例。员工不会注意到这件事的发生,所以可以快速地识别任何被引入基础设施中的弱点。 这是常规性的。 “混乱猴子”只是 Netflix“猿猴军团”中的一个组成部分(参见 Netflix 技术博客上的文章“The Netflix Simian Army”)。另一个是“混乱大猩猩”(Chaos Gorilla),它将整个数据中心(AWS 的可用区域)在运行过程中移除,以证明基础设施的其他部分可以不间断地继续运行。“延迟猴子”(Latency Monkey)在客户和服务器之间的通信中加入人为的延时,以发现上游服务器能够正确地应对服务降级。 正因为激进、持续地对灾备过程进行了验证,Netflix 每次都能不受亚马逊云基础设施的故障影响,没有中断的情况。 这样做的价值就在于主动摧毁,主动验证。

二、工具和网站集

为了理解服务器管理工具,最好参考服务器的生命周期拥有的多个阶段(如图 4-1 所示)。 enter image description here

图 4-1:服务器的生命周期

2.1、chef(原书1.4.2)

https://www.ibm.com/developerworks/cn/cloud/library/1407_caomd_chef/index.html

2.2、作者获得思路的一个网站

http://www.infrastructures.org/

2.3、Martin Fowler的网站(雪花服务器)

https://martinfowler.com/bliki/SnowflakeServer.html

2.4、Puppet

https://puppet.com/
https://www.cnblogs.com/waiwofei/p/3678173.html
puppet有可以练习的虚拟机

2.5、aminator

https://github.com/Netflix/aminator

2.6、MCollective

https://puppet.com/docs/mcollective/current/index.html

2.7、cron脚本

https://blog.csdn.net/ithomer/article/details/6817019

三、自己可以采取的行动

3.1 要重新理解私有云和公有云

第二章 2.2节,2.23节

3.2 要开始了解公有云,并尝试选择公有云

3.3 要尝试使用VCS去管理变更

VCS 是真相的唯一来源。如果两个团队都要检出文件并进行基础设施的变更,他们可能做出不兼容的修改。举例来说,我可能要给一个应用服务器增加配置,但与此同时 Jim 需要变更防火墙规则,正好会阻止对我的服务器的访问。如果我们都直接将变更应用到基础设施上,就不知道彼此正在做什么。我们可能重复应用变更,期望能强行应用自己的配置,但这样会一直扰乱对方的工作。

不过,如果我们都需要提交变更才能让它生效,就会很快知道变更冲突了。在VCS中,当前文件的状态正确地代表了已经把什么应用到了基础设施中。

3.4 要理解模板的厚和薄,在实际工作中学习如何处理

一个关键的权衡点是,如果越来越多的元素被打包到了服务器模板中,那么需要经常更新模板。这要求更加复杂的流程和工具来构建和管理模板。(4.2.3)

囫囵吞枣的读了一遍,希望今后有机会再来一遍。学习软件编程后再来体会。

2018年12月13日晨,南京,第一遍阅读