感谢您对 Ansible Tower 的关注。Tower 是支持图形化的框架，可通过 Web 界面和适用于开源 IT 编配引擎 Ansible 的 REST API 端点进行访问。无论是与团队共享操作任务，还是通过 Tower REST API 与 Ansible 集成，Tower 都提供了许多强大的工具来简化您的自动化工作。
实时监控 playbook 运行，在每台主机签入时看到它们。轻松返回并探索特定任务和主机的详细结果。搜索特定 play 或主机，并仅查看这些结果，或在发生需要更正的错误时快速归零。
通过最少的点击访问常用的项目，并从 Web 界面重新触发执行。Tower 将要求提供输入变量、提示输入您的凭证、启动和监控作业，并显示一段时间内的结果和主机历史记录。
Ansible Tower 允许通过基于角色的访问控制 (RBAC) 向不同的团队或显式用户授予权限来执行特定的任务（如查看、创建或修改文件）。
将一些项目保留为私密，同时允许某些用户编辑清单，并允许其他用户在检查（干运行）或实时模式下只针对某些系统运行 playbook。您也可以在不向某些用户公开凭证的情况下允许他们使用凭证。不管您执行什么操作，Tower 都会记录操作历史记录和执行者，包括编辑的对象和启动的作业。
基于用户反馈，Ansible Tower 可以扩展并简化基于角色的访问控制。不再需要通过清单、项目和凭证的权限组合来配置作业模板可见性。如果您想要授予用户或团队使用作业模板的权限，请直接在作业模板上分配权限。同样，凭证现在是 Tower 的 RBAC 系统中的完整对象，并可分配给多个用户和/或团队使用。
在 Tower 中也引入了一个新的“Auditor”类型，它们可看到系统自动化的所有方面，但没有权限为需要系统级审核员的用户运行或更改自动化。（这对于从 Tower 的 API 中提取自动化信息的服务帐户也很有用。）如需更多信息，请参阅 基于角色的访问控制。
Ansible Tower 的后续发行版本提供了更细粒度的权限，更加便于在您的机构内部进行委托并消除自动化瓶颈。
Tower 具有强大的配置回调功能，允许节点按需请求配置。尽管是可选的，但对于云自动缩放方案，与 Cobbler 之类的配置服务器集成来说，或在处理正常运行时间不可预测的受管系统时，这是一种理想的解决方案。回调解决方案可以通过简单调用“curl”或“wget”来触发，并且可以轻松地嵌入到 init 脚本、kickstart 或 preseed 中，不需要在远程节点上安装任何管理软件。访问受到控制，以便只有清单中的机器才能请求配置。
Tower REST API 是系统管理应用程序的理想 RESTful API，所有资源都完全可发现、已分页、可搜索并已精心建模。样式化的 API 浏览器允许从 API 根 (http://<Tower server name>/api/) 进行 API 探索，显示出所有资源和关系。可在用户界面中完成的所有操作都可以在 API 中完成，除此之外还可以完成其他操作。
备份和恢复系统的功能已集成到 Tower 设置 playbook 中，让您可以根据需要轻松备份和复制 Tower 实例。
提到描述您的自动化，任何人都会强调 DRY 原则，意为“Don’t Repeat Yourself”（不要重复自己）。使用 Ansible 角色的集中副本，比如在 Ansible Galaxy 中，您可将这个原则应用到 playbook 中。通过在项目目录中包含 Ansible Galaxy requirements.yml 文件，Tower 会自动从 Galaxy、GitHub 或您的本地源控制获取 playbook 所需的角色。如需更多信息，请参阅 Ansible Galaxy 支持。
Ansible 致力于让 OpenStack 对于每个人来说都简单易用。其中一项举措是为 OpenStack 添加了动态清单支持。这可让您轻松地将您在 OpenStack 云中运行的任何虚拟机或映像作为目标。
通常，您只需要在几个主机上执行简单的任务，无论是添加单个用户，更新单个安全漏洞还是重新启动行为异常的服务。从版本 2.2.0 开始，Tower 包括远程命令执行，意味着任何可以描述为单个 Ansible play 的任务都可以在清单中的一个主机或一组主机上运行，从而使您可以快速轻松地管理系统。此外，其背后都得到了 Tower 的 RBAC 引擎和详细审核日志的支持，从而消除了有关谁对什么机器执行了什么操作的任何问题。
您可以在 Ansible Tower 中轻松跟踪自动化的状态。您可以为作业模板、项目或整个机构配置可堆栈通知，并为（工作流节点的）作业启动、作业成功、作业失败和作业批准配置不同的通知。支持以下通知源：
电子邮件
Grafana
HipChat
IRC
Mattermost
PagerDuty
Rocket.Chat
Slack
Twilio
Webhook（发布到任意 Webhook，用于集成到其他工具）
此外，您可以为以上每个通知类型:ref:customize notification messages <ug_custom_notifications>。
Ansible Tower 3.0 还添加了 Red Hat Satellite 6 和 Red Hat CloudForms 的动态清单源。
Ansible Tower 3.1 支持与 Red Hat Insights 集成，允许 Insights playbook 用作 Tower 项目。
在 Ansible Tower 3.3 中，对用户界面的布局进行了重新组织以改进导航元素。由于在概览中显示了更多信息，您可以更直观地查找和使用您需要的自动化功能。紧凑和展开的查看模式可根据需要显示和隐藏信息，各种内置属性可方便排序。
有了自定义 Ansible 环境支持，您可以具有不同的 Ansible 环境，并为不同的团队和作业指定自定义路径。
Ansible Tower 3.3 增强了 LDAP 和 SAML 支持并引入了基于令牌的身份验证。增强的 LDAP 和 SAML 支持可让您以更灵活的方式集成您的企业级帐户信息。基于令牌的身份验证允许您通过集成的 OAuth 2 令牌支持轻松地向 Tower 验证第三方工具和服务。
集群组的运行时管理实现了可轻松配置的缩放。
Tower 可作为 Red Hat OpenShift Container Platform 的容器化 pod 服务，可根据需要轻松扩展和缩减。
为了更好地为复杂配置、部署和编配工作流建模，Ansible Tower 以多种方式扩展了工作流：
Inventory overrides for Workflows。现在您可以在工作流定义时，甚至在启动时覆盖工作流中的清单。定义应用程序部署工作流，然后轻松地在多个环境中重复使用。
Convergence nodes for Workflows。在对复杂流程建模时，有时需要等待多个步骤完成才能继续。现在 Ansible Tower 工作流可以轻松复制这一点；现在，工作流步骤可以等待任何数量的先前工作流步骤正确完成，然后再继续。
Workflow Nesting。重复使用单独的工作流作为较大工作流的组件。例如，将配置和应用程序部署工作流合并到单个主工作流中。
Workflow Pause and Appproval。您可以构建包含需要用户干预的批准节点的工作流。这样就可以在 playbook 间暂停工作流，以便用户批准（或拒绝）继续到工作流中的下一步。
随着自动化在全企业范围内扩展，对大规模自动化需求不断增加。在 Ansible Tower 3.4 中，我们现在支持在数千台机器中运行事实收集或配置作业，并将它分片成可在 Ansible Tower 集群中分发的单独作业分片，以便提高可靠性、作业完成速度以及集群利用率。如果您需要为 15,000 台交换机大规模更改一个参数，或者在数千个节点的 RHEL 设施内收集信息，现在您可以轻松地完成此操作。
如果您需要以受限模式（如 FIPS）运行您的环境，Ansible Tower 现在会在此类环境中部署并运行。
许多大型机构都有在许多机构之间共享的 Tower 实例。他们不希望任何一个机构能够使用所有许可的主机，此功能允许超级用户为每个机构可以分配到多少许可的主机设置指定的上限。Tower 算法会考虑机构的限制以及所有机构中的主机总数的变化。如果库存同步使机构不符合策略，则任何库存更新都将失败。此外，超级用户可以在显示警告的情况下“过度分配”其许可证。
对于各种源，在 Ansible 版本 2.8 及更高版本中运行的清单更新中，添加了清单插件的使用。
使用 secret 管理系统，外部凭证会存储下来以供在 Tower 中使用，因此您不必直接向 Tower 提供这些凭证。