2.7　把Ansible和SOE结合起来

我们已经用Ansible研究了许多端到端的例子。尽管很简单，但它们展示了本书所基于的Ansible自动化的基本构建块。在大规模的Linux环境中实现自动化的一个重要部分是拥有良好的标准和健壮的流程。因此，不仅操作环境应该标准化，部署和配置过程也应该标准化。

如前一章所讨论的，尽管定义良好的SOE在部署时是一致的，但是如果允许管理员使用他们首选的方法随意更改，这种一致性很快就会丧失。正如部署SOE以在自动化方面取得成功是可取的一样，让尽可能多（理想情况下是所有）的管理任务自动化也是可取的。

理想情况下，剧本应该有一个单一的真实来源（例如，一个中央Git存储库），清单应该有一个单一的真实来源（这可以是一个中央存储的静态清单，或者使用动态清单）。

任何写得好的Ansible剧本（或角色）的目标都是运行它的结果是可重复和可预测的。以上一节末尾运行的剧本为例，在这里用我们写的剧本部署了一个简单的Apache vhost.conf文件。每次在任何服务器上运行此剧本时，/etc/apache2/sites-available/my-vhost.conf文件将是相同的，因为剧本使用模板部署此文件，并覆盖目标文件（如果存在）。

当然，这只是标准操作环境的一个缩影，但这样的环境将由成百上千个小构件组成。毕竟，如果不能使Apache配置在整个基础设施中保持一致，那么如何能够确信它的任何其他部分都是按照你的标准构建的呢？

编写良好的剧本的可重复性在这里也很重要，因为部署了一致的Apache配置并不意味着它将保持一致。部署配置五分钟后，具有所需权限的人可以登录到服务器并更改配置。因此，环境几乎可以立即偏离你的SOE定义。在基础架构中反复运行Ansible剧本实际上是正在进行的流程的一个重要部分，因为这些剧本的本质是使配置与原始标准保持一致。因此，Ansible剧本不仅是定义和部署SOE的重要组成部分，而且在标准的持续执行中也是如此。

如果可能，不应手动部署修复程序。假设有人手动调整/etc/apache2/sites-available/my-vhost.conf文件中的配置来克服某个问题。这本身不是问题，但将这些更改放回剧本、角色或模板中是至关重要的。如果通过Ansible部署或强制SOE以某种方式破坏了它，那么你的流程就有问题了。

实际上，通过实现我们到目前为止讨论过的流程，并将在本书中继续探讨，可以实现跨企业的成功自动化。本章对Ansible自动化的介绍虽然简短，但也是这些建议过程的一部分。

关于Ansible还有很多需要学习的地方，简言之，我想提出一个大胆的说法：如果你可以将其设想为服务器部署或配置任务，Ansible可以提供帮助。由于Ansible是开源的，因此它具有很强的可扩展性，它的广泛采用意味着许多常见的自动化挑战已经得到解决，并且包含了相关的特性。希望本章能为你使用Ansible实现Linux自动化提供一个良好的开端。 0f55OYzyPDIwDULymwumQbJyfBHcCUwYMjUCvREWbyhhEzR/IJfuqU2ItuhIiSHu