Ansible 精妙设计：让你的自动化奔跑起来

Posted 2021-04-25 前沿技墅

本文作者 Lorin Hochstein

Netflix的Chaos工程团队的高级软件工程师,曾在SendGrid实验室担任高级软件工程师、在Nimbis Services担任云服务首席架构师，还曾是加州大学信息科学院计算机科学家。他在麦吉尔大学取得计算机工程学学士学位，在波士顿大学取得电子工程学硕士学位，在马里兰大学取得计算机科学的博士学位。

在 IT 行业工作其实挺纠结的。向客户交付软件的时候，不只是在一台计算机上一键安装了事。 实际上，慢慢的，我们都变成了系统工程师。

• 我们部署应用的时候需要把不同的服务组合起来，这些服务运行在一组分布式计算资源上，并且使用不同的网络协议相互通信。一个典型的应用一般由 Web 服务、 应用服务、内存缓存系统、任务队列、消息队列、SQL 数据库、NoSQL 数据库以及负载均衡等几部分组成。

• 我们还得保证服务具有适当的冗余。这样出现异常（放心，异常一定会有的）的时候，我们的软件可以平滑地处理这些异常。其次，我们还需要部署和维护配套服务，一般包括日志系统、监控系统、数据分析系统以及与我们交互通信的第三方服务，比如，管理虚拟机实例的 IaaS 终端。 

• 设想一下纯手工地配置这些服务的场景 ：使用 SSH 登录到一台服务器，安装软件包， 编辑配置文件，然后换下一台继续。光想想就痛苦，特别是在重复到第三四次的时候，你会感到特别费时费力，枯燥乏味还特别容易出错。而且还有很多更复杂的情况，比如在你的应用中使用了 OpenStack，全部手动来完成绝对是一个很疯狂的想法。幸运的是，现在有一个优雅的办法。

如果你赞同配置管理理念，并且正在考虑采用 Ansible 作为你的配置管理工具的。不管你是准备向生产环境部署自己代码的开发者，还是寻求更好的自动化解决方案的系统管理员，我保证你会爱上 Ansible 的。它就是解决你问题的完美解决方案。

溯源 Ansible

Ansible 出自科幻小说，是虚构的一种以超光速传递信息的通信装置。Ursula K. Le Guin 在他的 Rocannon’s World 一书中发明了这个概念。后来很多科幻作家都曾借鉴过这个概念。实际上，Ansible 的作者 Michael DeHaan 是从 Orson Scott Card 撰写的 Ender’s Game 一书中借鉴来的。在那本书中，Ansible 可以跨越任何距离同时控制无数飞船，就好像在我们的世界中控制海量远程服务器一样。

易读的语法

回忆一下，Ansible 的配置管理脚本叫作 playbook。playbook 的语法是基于YAML构建的，YAML 是一种以易于人类读写为设计理念的数据格式语言。从某种程度上说，YAML 至于 JSON 就好像 Markdown 至于 html。

我喜欢把 Ansible 的 playbook 看作可执行的文档。它就像一个 README 文件，里面记录了部署你的软件所必须使用的命令，只不过这些指令永远不会过期，因为它们同时也是直接执行的代码。

远程主机无须安装依赖

需要被 Ansible 管理的服务器需要安装 SSH 和 Python 2.5 或更新版本，或者安装了simplejson 库的 Python 2.4。除此以外，不再需要预装任何代理程序或其他软件了。控制服务器（用于控制远程服务器的那台）需要安装 Python 2.6 或者更高版本。

基于推送模式

以 Chef 和 Puppet 为代表的使用 agent 的配置管理系统，默认采用拉取模式。安装在服务器上的 agent 程序定期检查中心服务器，拉取配置信息。让配置变更能在服务器上生效大概需要经过如下过程。

1. 你 ：对配置管理脚本进行变更。

2. 你 ：将变更内容更新到配置管理中心服务。

3. 服务器上的 agent 程序 ：当周期计时器到期时唤醒。

4. 服务器上的 agent 程序 ：连接到配置管理中心服务。

5. 服务器上的 agent 程序 ：下载新的配置管理脚本。

6. 服务器上的 agent 程序 ：在本地执行那些改变服务器状态的配置管理脚本。

与此相反，Ansible 默认采取的是基于推送的模式。配置变更步骤如下所示。

1. 你 ：在 playbook 中进行变更。

2. 你 ：运行新的 playbook。

3. Ansible ：连接到服务器并执行那些改变服务器状态的模块。

一旦运行 ansible-playbook 命令，Ansible 马上连接到远程服务开始干活。

基于推送模式的方式最突出的优点是 ：直接由你来控制变更在服务器上发生的时间。你不需要呆呆地等计时器过期。拉取模式的拥趸号称拉取模式在大规模服务器场景下具有较好的扩展性，并且更适合处理新服务器随时上下线的场景。然而，Ansible 已经成功地在具有成千上万个节点的生产环境中工作，并且可以完美支持服务器动态上下线的场景。

如果你真的更喜欢拉取模式，Ansible 可以使用 ansible-pull 工具实现，它是在 Ansible官方版本内一起发布的。

使用Ansible管理小规模环境

没错，Ansible 可以用于管理成百上千个节点。但是，它真正吸引我的地方是应用于小规模集群时的易用性。使用 Ansible 管理单一节点非常简单，你只需编写一个 Ansible 脚本文件。Ansible 遵循了 Alan Kay 的格言“简单的事情应该保持简单，复杂的事情应该做到可能”。

内置模块

你可以使用 Ansible 在你管理的远程服务器上执行任何 shell 命令，但是 Ansible 真正强大的地方在于内置的模块集。使用模块你可以 ：安装某个软件包、重启某个服务或者复制某个配置文件。

稍后我们就会看到，Ansible 模块是声明式的。模块声明它可以用于描述你希望服务器所处于的状态。例如，你打算借助用户模块保证拥有一个名为 deploy 且所属组为 web 的账号。如下所示 ：

user: name=deploy group=web

另外，模块是幂等的。如果用户 deploy 不存在，Ansible 就创建它。如果它存在，Ansible 不会做任何事。幂等性是一个非常赞的特性，因为它意味着向同一台服务器多次执行同一个 Ansible playbook 是安全的。相对于一般运维团队自己编写的 shell 脚本来说，这是一个非常大的优势。运维团队自己编写的脚本在第二次执行的时候很可能会带来不一样（往往是预期以外的）的影响。

关于收敛性

配置管理领域的书籍往往会提到收敛性的概念。与配置管理中的收敛性最相关的是Mark Burgess 以及他编写的配置管理系统 CFEngine。对于一个配置管理系统，如果它具有收敛性，那么这个系统也许需要多次运行才能将服务器置于期望的状态。而在这个过程中的每一次运行，都会使服务器更接近于那个状态。

收敛性的想法并没有被真正应用到 Ansible 中，Ansible 并没有需要多次运行来配置服务器的设计。相对的，Ansible 的模块实现的行为是 ：只需要运行 playbook 一次即可以将每台服务器都置为期望的状态。

非常轻量的抽象层

某些配置管理工具提供一个抽象层，这样你就可以使用相同的配置管理脚本对运行不同操作系统的服务器进行管理。例如 ：配置管理工具提供一个 package 抽象去替代 yum 或者 apt 这样的包管理器，这样就无须处理包管理器的差异了。

Ansible 的处理方式不太一样。如果在基于 apt 的系统上安装软件包，那么你还是得使用apt 模块，在基于 yum 的系统上安装软件包使用 yum 模块。

虽然听起来这种设计是一个缺点，但从工程实践上来看，我认为它反倒使得 Ansible 更易用。Ansible 不需要我们去学习一套新的用于屏蔽不同操作系统差异的抽象。这使得Ansible 需要学习的东西更少，在开始使用它之前几乎不需要其他必备知识。

如果你真的希望有这层抽象，可以在编写自己的 Ansible playbook 时，实现针对不同操作系统的远程服务器运行不同的操作。但是实际工作中我尽量避免这么做，我会更专注于编写用于某个特定的操作系统（比如 Ubuntu）的 playbook。

在 Ansible 社区，复用的基本单元是模块。由于模块的功能范围非常小，并且可以只针对特定的操作系统，所以非常易于实现定义明确且易于分享的模块。Ansible 项目对于接受社区贡献的模块这点上非常开放。我也贡献过几个模块，因此对此了如指掌。

Ansible playbook 在设计上并不考虑在不同的系统环境之间复用。在第 7 章我们将会讨论 role，它将 playbook 整合为更可复用的对象，此外还有非常便利的 Ansible Galaxy，它是一个在线的 role 仓库。

在实际工作中，每家公司组建服务器的方式都会有一些不同，根据你的公司的情况编写playbook 会比尝试复用别人的 playbook 更合适。但我相信翻阅其他人分享的 playbook范例对于理解工作原理有重要价值。

Ansible 软件与 Ansible 公司是什么关系

Ansible 这个名字不仅指代软件，还是运作这个开源软件的公司的名字。Ansible软件的创始人 Michael DeHaan 同时也是 Ansible 公司的前 CTO。为了防止混淆，我们把软件称作Ansible，而公司则使用“Ansible 公司”来称呼。

Ansible 公司主要经营 Ansible 的培训和咨询服务。除此之外，还有一个叫作Ansible Tower 的 Web 管理工具作为专有软件产品。2015 年 10 月，Red Hat 收购了 Ansible 公司。

本文节选自《奔跑吧Ansible（第2版）：探索自动化配置与部署捷径》一书。Ansible 的设计初衷是在若干服务器上从零开始执行所有必需的配置与操作，因为使用极度简便的模型来实现对各种操作按照所需顺序执行的控制，它成为自动化运维、DevOps的最佳配置。本书由知名互联网企业SRE团队精心翻译，基于真实生产环境案例，涵盖大量官方文档缺少的重要概念和主题，覆盖编写playbook、管理远程服务器、探索内置模块等高级内容。“奶牛书”的营养美味，让阅读原文带你酣畅体会！。

• 内容简介：Ansible是近年来急速发展的开源配置管理工具。在Ansible之前，行业中已经有很多开源配置管理工具了，特别是大名鼎鼎的Puppet，简直是配置管理工具中的超级star。然而，Ansible依靠它的简单易用、“零依赖”以及弱抽象获得了无数开发者和运维工程师的青睐。遗憾的是，除了官方文档外，Ansible相关的优秀文档凤毛麟角，而本书恰恰就是为了缓解这一问题而编写的。作者在《奔跑吧Ansible（第2版）：探索自动化配置与部署捷径》中演示了如何使用Ansible管理接近真实生产环境的案例。既展现了Ansible的强大功能，又能够帮助读者快速入门与上手，《奔跑吧Ansible（第2版）：探索自动化配置与部署捷径》非常适合作为官方文档的补充或者搭配阅读。特别值得一提的是，《奔跑吧Ansible（第2版）：探索自动化配置与部署捷径》第2版还增加了管理Windows服务器和网络设备方面的章节，并重新编写了Docker相关章节，及时地对第1版中的不足进行了改进。

  

长按二维码，关注“前沿技墅”，抢先接收新知、了解书讯、结识大咖。

任何伟大，无不起步于不经意间，你可以选择不经意错过，或不经意开始……