下载掌阅APP，畅读海量书库
立即打开
AWX旨在解决企业环境中与Ansible自动化相关的问题。为了保持实践重点，让我们考虑一下在第1章中讨论的有机增长场景。在已经实现了Ansible的小环境中，你可能只有一两个关键人员负责编写和运行针对此环境的剧本。在这个小环境中，很容易知道是谁运行了哪些剧本以及剧本的最新版本是什么，而且Ansible的培训要求很低，因为只有少数关键人员负责使用它。
随着环境向企业级规模扩展，Ansible操作人员的数量也随之增加。如果所有负责运行Ansible的人都在自己的机器上安装了它，并且本机都有剧本的副本，那么突然之间，管理该环境就变成了一场噩梦！如何确保每个人都在使用最新版本的剧本？如何知道是谁运行了什么以及运行结果如何？如果需要在几个小时内进行更改，你能否将Ansible工作移交给 网络运营中心（NOC） 团队？或者这是不可能的，因为他们将接受关于如何使用Ansible的培训。
正如我们随后将看到的，AWX着手解决所有这些挑战。从下一节开始，我们将探讨如何使用AWX来降低员工培训成本。
Ansible非常容易启动和运行。不过，使用它还需要经过培训。例如，没有接受过培训的IT管理员和操作员可能不习惯在命令行上运行剧本。下面的示例演示了这一点。尽管Ansible术语相当简单，但任何不熟悉该工具的人都会发现它的用户友好性不高：
虽然这个命令并不算复杂，但不熟悉它的人可能不愿意运行它，因为他们害怕对生产系统造成损害，更不用说解释一个相当大的剧本可能产生的输出页面了。
为了缓解这一问题，AWX提供了一个基于Web的图形界面，它实际上是点击式的。尽管熟悉剧本的人可以使用许多高级功能，但只需点击几下鼠标就可以运行剧本，并且使用简单的红绿灯（traffic light）系统显示结果（红色表示剧本运行失败，而绿色表示成功）。AWX提供了一个界面，通过这种方式，即使那些没有Ansible经验的人也可以从界面中启动一个剧本并将结果传递给另一个团队进行分析。
AWX也为安全团队和管理人员提供了好处，这通过记录所有操作和执行的工作的详细结果来实现，我们将在下一节中对此进行概述。
尽管Ansible命令行工具提供了日志记录选项，但这些选项在默认情况下是不启用的。因此，一旦终端会话关闭，剧本的运行输出就可能丢失。这在企业级场景中不是很好，特别是当出现问题或停机并且需要分析原因时。
AWX通过两种方式解决这个问题。首先，每个用户在执行任何操作之前都必须登录到GUI。AWX可以与集中式记账系统（如LDAP或Active Directory）集成，也可以在AWX主机上本机定义用户，然后跟踪UI中的所有操作，因此，可以跟踪特定用户运行的剧本，甚至配置更改。在企业环境中，这种级别的问责制和审计跟踪是必须具备（must-have）的。
除此之外，AWX还采集了每个剧本运行的所有输出，以及关键信息，如需要运行剧本的机器清单、传递给它的变量（如果有的话）以及运行的日期和时间。这意味着，如果出现问题，AWX可以提供一个完整的审计跟踪，帮助你找出发生的原因以及发生的时间。
AWX不仅可以帮助你审计你的自动化，还可以帮助你对剧本进行版本控制，我们将在下一节中讨论。
在企业场景中，个人在本机存储剧本可能是一个有待解决的问题。例如，如果用户A用一个关键修复程序更新了一个剧本，那么如何确保用户B能够访问该代码呢？理想情况下，代码应该存储在版本控制系统（例如GitHub）中，并且每次运行都会更新本机副本。
良好的流程是Linux企业级自动化的一个重要组成部分，虽然用户B在运行本机的剧本之前应该先更新它们，但是你不能强制他这样做。同样，AWX允许从版本控制存储库中获取剧本，并自动更新AWX服务器上的剧本的本机副本，从而解决了这个问题。
尽管AWX可以帮助你，特别是能确保你从存储库中提取最新版本的代码，但它不能帮助你处理其他错误行为，例如某人没有在第一时间提交他的代码。然而，强制将AWX用于Ansible剧本运行的意图是，任何对剧本进行更改的人都必须提交它们，以便AWX运行它们。对AWX服务器的本机访问应该严格限制，以防止人们在本机文件系统上进行代码更改，这样，你就可以确信每个人都在积极有效地使用版本控制系统。
这些更新可以是事件驱动的，因此，每次运行来自该存储库的剧本时都可以更新本机剧本。也可以根据AWX管理员的决定定期或手动更新。
AWX也可以帮助你实现自动化的安全性。我们将在下一节中通过研究AWX中的凭据管理来探讨这一点。
为了有效地管理企业Linux环境，Ansible必须具有某种形式的凭据才能访问它管理的所有服务器。SSH身份验证通常使用SSH密钥或口令进行保护，在由Ansible操作员组成的大型团队中，这意味着每个人都可以访问这些口令和SSH私钥，因为它们是Ansible运行所必需的。不用说，这会带来安全风险！
如前所述，从安全的角度来看，这是不可取的，因为太容易复制和粘贴凭据并以不当的方式使用它们了。AWX通过在其数据库中存储所需的凭据来处理此问题，并使用安装时选择的口令短语进行加密。GUI使用可逆加密存储所有凭据，以便在以后运行剧本时将它们传递给Ansible。但是，GUI不允许你看到任何以前输入的敏感数据（如密码或SSH密钥），也就是说，可以输入和更改这些数据，但是不能在GUI中显示密码或SSH密钥，因此操作员不能轻松地利用AWX前端获取凭据信息以供其他地方使用。通过这种方式，AWX可以帮助企业对其凭据进行锁定和密钥管理，并确保它们仅用于Ansible部署，而不会泄露或用于任何其他目的。
Ansible Vault是用来对剧本需要操作的任何敏感数据进行加密的优秀工具，无论是变量形式的剧本数据还是存储服务器凭据（如SSH密钥）本身。尽管Vault高度安全，但如果你有Vault密码，则很容易看到Vault内容（在这里，你需要运行使用Vault的剧本）。因此，AWX提供了独特的功能来辅助Ansible并确保企业环境的安全性。
通过这些方式，AWX有助于解决企业在大规模环境中部署Ansible时面临的许多挑战。在完成本章的这一部分之前，我们将简要地介绍如何将AWX与其他服务集成。
AWX可以与许多工具集成，例如Red Hat的Satellite 6和CloudForms产品（以及它们的开源对应产品Katello和ManageIQ）都提供了与AWX和Ansible Tower的天然集成。这仅仅是两个例子，而这一切成为可能，是因为我们在本章中要探讨的所有内容也可以通过API和命令行界面进行访问。
这使AWX能够与各种各样的服务集成，或者你甚至可以编写自己的服务，从AWX运行剧本作为其他操作的结果，这只需调用API即可。命令行界面（在Ansible Tower产品商用之后称为tower-cli）也非常有用，尤其是在AWX中以编程方式填充数据时。例如，如果要将主机添加到静态资源清单中，可以通过Web用户界面（稍后将演示）、API或使用CLI来完成。后两种方法非常适合与其他服务集成，例如， 配置管理数据库（CMDB） 可以使用API将新主机推送到资源清单中，而无须用户进行任何手动操作。
要进一步探索这两个集成点，你可以参考以下官方文档：
·AWX API的文档：https://docs.ansible.com/ansible-tower/latest/html/towerapi/index.html。
·tower-cli命令的文档：https://tower-cli.readthedocs.io/en/latest/。
考虑到这些集成的广泛性和多样性，它们超出了本书的范围，但在这里仍提到它们，是因为希望你在阅读本章时，能够有机会看到AWX与其他服务集成，从而能够进一步探讨这个主题。在本章的下一节中，我们将实际使用AWX并查看一个简单的部署。在本章的后面，我们将介绍一些示例。