本指南帮助您尽快启动并运行您的 Ansible Automation Platform 安装。
在安装结束时，您可以使用您的网页浏览器访问并充分利用 Automation Platform。
虽然本指南涵盖了基础知识，但您可以参阅 Installation and Reference Guide 以了解更多信息。
在开始安装前，您可能还需要参阅 General Installation Notes
有关平台信息，请参阅 平台特有的安装注意事项。
注解
Tower 是一个完整的应用程序，它的安装过程包括安装一些依赖软件，如 PostgreSQL、Django、NGINX 和其他一些软件。Tower 需要在一个独立的虚拟机或云实例上安装，而不能和其他应用程序位于同一个机器上（相关的监控和日志程序除外）。虽然 Tower 和 Ansible 都是使用 Python 开发的，但它们并不是只使用简单的 Python 库。因此，Tower 不能在一个 Python virtualenv 或其他相似子系统上安装。您需要按照本指南中的内容安装它。如需了解基于 OpenShift 部署的信息，请参阅 OpenShift Deployment and Configuration。
Ansible Tower 有以下要求：
从 Ansible Tower 3.8 开始，在安装和运行 |aap|前，必须**附加了有效的订阅。**如果您已经拥有来自以前版本的有效许可证，在升级到 Tower 3.8 时，仍必须提供您的凭证或订阅清单。 详情请参阅 附加订阅。
支持的操作系统：
Red Hat Enterprise Linux 8.2 或更高的 64 位版本 (x86)
Red Hat Enterprise Linux 7.7 或更高的 64 位版本 (x86)
Centos 7.7 或更高的 64 位版本 (x86)
注解
对于 Automation Hub，selinux-policy 软件包版本需要大于或等于 3.13.1-268。另外，RHUI 订阅**不能用于**安装 Automation Hub。
注解
Ansible Tower 的下一个主要发行版本将不支持 Red Hat Enterprise Linux 7 或任何版本的 CentOS 作为安装平台。
当前支持的 Mozilla Firefox 或 Google Chrome 版本
其它兼容 HTML5 其它兼容 HTML5 的网络浏览器可能可以正常工作，但没有经过充分测试并不被支持。。
最少 2 个 CPU 用于 Automation Platform 安装。请参考 Ansible Tower User Guide 的 capacity algorithm 部分以确定您具体配置中 fork 数量所需的 CPU 容量。
最少 4 GB RAM 用于 Automation Platform 安装
4 GB RAM（Vagrant trial 版本安装的最小和推荐值）
4 GB RAM（外部独立 PostgreSQL 数据库最小值）
对于特定 RAM 的要求，请参考 Ansible Tower User Guide 的 capacity algorithm 部分以确定您具体配置中 fork 数量所需的 RAM。
20 GB 专用硬盘空间 用于 Tower 服务节点
20 GB 中的 10 GB 必须专用
/var/，Tower 在这个目录中存储其文件和并进行工作。存储卷的最低基础线评级应该是 750 IOPS。
20 GB 专用硬盘空间，用于包含数据库的节点（推荐值为150 GB+）
存储卷的基础线 IOPS 评级应该比较高（1000 或更高）。
所有 Tower 数据都存储在数据库中。随着所管理的主机数量、运行作业的数量、在 fact 缓存中的 face 数量以及每个独立作业中的任务数量的增加，数据库存储量也会随之增加。例如，一个每小时运行一次（一天 24 次），在 250 个主机上运行且有 20 个任务的 playbook，每周会在数据库中保存超过 800000 个事件。
如果没有为数据库保留足够空间，旧的作业和 fact 将会被定期清除。请参阅 Ansible Tower Administration Guide 中的 Management Jobs 以获得更多信息
**需要 64 位支持**（内核和运行时）
Ansible Tower 3.7 或更新的版本需要运行 PostgreSQL 10 。备份和恢复*只在**您当前的 Ansible Tower 所支持的 PostgreSQL 版本中可以正常工作。
Ansible 版本 2.9 需要 运行 Ansible Tower 版本 3.8 或更新版本
注解
您不能使用比上述版本旧的 PostgreSQL 和 Ansible 版本来运行 Ansible Tower 3.7 版本及之后的版本。安装脚本会在这些软件不存在时安装它们。
对于 Automation Hub：从 Ansible Tower 3.8 开始，Automation Hub 将充当 Ansible Tower 的内容供应商，这需要 Ansible Tower 部署和 Automation Hub 部署一起运行。Tower 和 Automation Hub 可以在 RHEL 7 或 8 上运行，但 OpenShift Container Platform（OCP）上只支持 Tower（不支持 Automation Hub）
对于 Amazon EC2：
实例大小为 m4.large 或更大
如果超过 100 个主机，则实例大小为 m4.xlarge 或更于
实际 RAM 的要求取决于 Tower 同时管理的主机数量（它由作业模板或系统文件 ansible.cfg 中的 forks 参数控制）。为了避免可能的资源冲突，Ansible 建议每 10 的 fork 需要 1 GB 内存再加上 2 GB 保留内存用于 Tower。请参阅 capacity algorithm。如果 forks 被设置为 400，建议使用 40 GB 内存。
对于安装 Ansible Tower 的主机，Tower 会检查 umask 是否被设置为 0022。如果没有，则设置过程会失败。请确定设置 umask=0022 以避免出现这个错误。
大量主机可以被处理，但如果 fork 数量小于主机的总数，则在主机间需要更多的 pass。在以下情况下，这些 RAM 的限制在以下情况下会被忽略：当使用滚动升级时；或使用 Tower 中内建的置备 callback 系统（这里每个系统请求配置都会进入一个队列，并尽快被处理）时；或 Tower 在生成或部署镜像（如 AMI）时。这些情况会出现在管理大型系统时。如有其他问题，请通过红帽客户门户网站（ https://access.redhat.com/）联络 Ansible 团队。
由 Ansible Automation Platform 管理的系统的要求和 Ansible 相同： https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#prerequisites
Automation Platform 使用 PostgreSQL 10，它在 RHEL 7 上是一个 SCL 软件包，在 RHEL8 上是一个应用程序流。在升级到 PostgreSQL 10 时，请注意以下变化：
现在，在将 PostgreSQL 用户密码保存到数据库前，会使用 SCRAM-SHA-256 安全散列算法对其进行处理。
您将不再需要在安装时在 inventory 文件中提供 pg_hashed_password，因为 PostgreSQL 10 现在可以安全地保存用户的密码。如果用户为安装程序在 inventory 文件中提供了密码 (pg_password)，做为安装过程的一部分，PostgreSQL 会对这个密码进行 SCRAM-SHA-256 散列处理。**不要**在 pg_password 中使用特殊字符，因为可能会导致设置失败。
因为 Ansible Tower 和 Automation Hub 在 3.8 中使用 PostgreSQL 的 Software Collections 版本，所以 rh-postgresql10 scl 必须被启用才可以访问数据库。管理员可以使用 awx-manage dbshell 命令，它会自动启用 PostgreSQL SCL。
如果您只需要确定您的 Tower 实例是否可以访问数据库，您可以使用 awx-manage check_db 命令。
另外，您可以将 PostgreSQL 数据库配置为不是由 Automation Platform 安装程序管理的独立节点。当 Automation Platform 安装程序管理数据库服务器时，它会使用通常为大多数工作负载推荐的默认值配置服务器。但是，您可以调整独立数据库服务器节点的这些 PostgreSQL 设置，其中 ansible_memtotal_mb 是数据库服务器的总内存大小：
max_connections == 1024
shared_buffers == ansible_memtotal_mb*0.3
work_mem == ansible_memtotal_mb*0.03
maintenance_work_mem == ansible_memtotal_mb*0.04
详情请参考 PostgreSQL documentation tuning your PostgreSQL server。
虽然 Automation Platform 依赖于 Ansible Playbook，在安装 Tower 前需要安装最新版本的 Ansible，但它不再需要手动安装 Ansible。
在进行新安装时，Tower 会安装最新版本的 Ansible 2.9。
如果执行捆绑的 Automation Platform 安装，安装程序会尝试从捆绑包中安装 Ansible（及其依赖软件包）。详情请参阅 使用捆绑的 Ansible Automation Platform 安装程序。
如果您选择自己手动安装 Ansible，Automation Platform 安装程序会检测到已安装了 Ansible，并将不会尝试重新安装它。请注意，您必须使用软件包管理程序（如 yum）来安装 Ansible，并且必须安装最新的稳定版本才可以使 Automation Platform 正常工作。Ansible Tower 3.8 及更新的版本最少需要 Ansible 2.9。
为方便起见，以下几节中提供了这些说明的总结。
Ansible Automation Platform 可以在启用了 FIPS 模式的系统中运行，但要记住有一些限制：
只支持 Enterprise Linux 7+。当 Ansible Tower 在启用了 FIPS 模式的环境中工作时，必须使用 RHEL 附带的标准 python。不支持在 Tower 中使用任何非标准、非系统的 python。
默认情况下，Tower 使用基于密码的身份验证来配置 PostgreSQL，在安装过程中运行的 CREATE USER 需要使用 md5。要从启用了 FIPS 的系统中运行 Tower 安装程序，在清单（inventory）文件中指定 pg_password 。不要 在 pg_password 中使用特殊的字符，因为它可能会导致设置失败：
pg_password='choose-a-password'
详情请查看 设置清单（Inventory）文件。
如果您在 inventory 文件中提供安装程序的密码（pg_password），作为安装过程的一部分，PostgreSQL 会对该密码进行 SCRAM-SHA-256 哈希处理。
ssh-keygen 命令会生成 RFC4716 格式的密钥，它在处理的过程中会使用 md5 摘要算法（做为对输入密令处理的一部分）在一个启用了 FIPS 的系统中，md5 会被完全禁用，因此这类加密的 SSH 密钥（RFC4716 私人密钥由密令加以保护）将不可用。当启用了 FIPS 模式时，任何导入到 Ansible Tower 的加密的 SSH 密钥**必须**是一个 PKCS8 格式的密钥。运行以下 openssl 命令可以把已有的 AES128 密钥转换为 PKCS8 密钥：
$ openssl pkcs8 -topk8 -v2 aes128 -in <INPUT_KEY> -out <NEW_OUTPUT_KEY>
Ansible 中需要使用 paramiko 库的功能与 FIPS 不兼容。这些功能包括设置 ansible_connection=paramiko 做为传输，使用需要利用 ncclient NETCONF 库的网络模块。
TACACS+ 协议使用 md5 来混淆授权数据包的内容。启用了 FIPS 模式的系统不支持 TACACS+ Authentication。
RADIUS 协议使用 md5 来加密 Access-Request 查询中的密码；启用了 FIPS 模式的系统不支持 RADIUS Authentication。
PackageKit 可能会经常影响到安装/更新机制。如果安装了 PackageKit，则考虑在运行设置（setup）过程前禁用或删除它。
只支持 "targeted" SELinux 策略。targeted 策略可以被设置为 disabled 、permissive 或 enforcing。
当执行捆绑的安装时，请参考 使用捆绑的 Ansible Automation Platform 安装程序。
当安装 Ansible Tower 时，您只需要运行 setup.sh，Tower 所需的所有软件仓库都会被自动安装。
在设置过程中会自动安装最新版本的 Ansible。不需要进行额外的安装或配置。
Ansible Tower 不再支持 Ubuntu。如需更多与 Ubuntu 相关的信息，请参阅 Ansible Automation Platform Installation and Reference Guide 以前的版本。
对于基于 OpenShift 的部署，请参考 OpenShift Deployment and Configuration。
在安装 Tower 之前，Satellite 用户需要在 Tower 节点上为您的 Satellite 实例安装 Katello RPM。此 RPM 会自动将订阅管理器配置为使用 Satellite 作为其内容源，hostname 值会在 ``/etc/rhsm/rhsm.conf``中被更新。
注解
如果您要在安装 Tower 后 安装 Katello RPM，Tower 将无法访问 rhsm.conf-- 它依赖于通过 Satellite 应用订阅。这是因为 Tower 安装程序在 rhsm.conf 文件中设置 ACL 规则，因此如果该文件不存在，则无法应用订阅，或者用户没有权限访问该文件。
有关如何在 Satellite 服务器中注册主机的详情，请参考 Satellite 文档的 Registration 部分。
Ansible Automation Platform 可使用以下场景之一安装：
单机：
带有数据库的独立的 Tower，作为 Tower 管理的或非安装程序管理的数据库位于同一个节点上 。这是 Tower 的单一机器安装 - web 前端、REST API 后端和数据库都位于一台机器上。这是 Tower 的标准安装。它还从 OS 厂商仓库安装 PostgreSQL，并将 Tower 服务配置为将其用作数据库。
[tower]
host
带有一个外部数据库的独立 Tower：这会在一台机器上安装 Tower 服务器，并将它配置为使用一个远程的 PostgreSQL 10 实例作为它的数据库。这个远程 PostgreSQL 可以是您自己管理的服务器，也可由 云服务商（如 Amazon RDS）提供。
[tower]
host
[database]
host2
带有一个位于同一个节点上的数据库的 Automation Hub，这个数据库可以是 Automation Hub 或非安装程序管理的数据库：
[automationhub]
host
带有一个外部数据库的独立的 Automation Hub。这会在一台机器上安装 Automation Hub 服务器，并通过 playbook 安装程序（由 Automation Platform 安装程序管理）安装一个远程 PostgreSQL 数据库。
[automationhub]
host
[database]
host2
平台安装：
平台安装涉及 Tower 和 Automation Hub。平台安装程序允许您每个清单部署 1 个且只能部署 1 个 Automation Hub。安装程序可以作为 Automation Hub 独立安装程序使用，如果您要部署多个 Automation Hub 节点，则可多次使用不同的清单运行安装程序。平台安装支持的 2 个选项是：
带有一个位于同一个节点上的数据库的平台（Tower 和 Automation Hub），这个数据库可以是 Tower 或非安装程序管理的数据库：
[tower]
host1
[automationhub]
host2
带有一个外部管理的数据库的平台（Tower 和 Automation Hub）：
[tower]
host1
[automationhub]
host2
[database]
host3
多机器集群
这个场景包括使用外部管理的数据库的平台（集群的 Tower 和 Automation Hub）安装。在这个模式下，会安装并激活多个 Tower 节点。任何节点都可以接收 HTTP 请求，所有节点都可以执行作业。这会在一台机器上安装平台服务器，并将它配置为与远程 PostgreSQL 实例进行对话。这个远程 PostgreSQL 可以是您自己管理的服务器，也可以由云服务（如 Amazon RDS）提供：
[tower]
host1
host11
host12
[automationhub]
host2
[database]
host3
注解
在集群设置中运行需要 Tower 使用外部的数据库，PostgreSQL 必须在一个不是主（primary）或（secondary）tower 节点的机器上安装。在一个冗余设置中，远程 PostgreSQL 版本要求是 PostgreSQL 10。
有关配置集群设置的详情，请参考 集群。
注解
1). Tower 将不会为它使用的数据库配置复制或故障转移功能，但 Tower 应该可以和已有的复制机制一起工作。2). 为获得更好的性能，数据库服务器应该和 Tower 服务器位于同一个网络或同一个数据中心。3）Tower 和 Automation Hub 不能在同一节点上运行，这种场景不被支持。这意味着，任何平台的部署都会是至少 2 个节点部署的拓扑。
Automation Platform 安装的可用设置：
automationhub_importer_settings：传递给 galaxy-importer 的设置/配置字典，它最终会位于 /etc/galaxy-importer/galaxy-importer.cfg 中
automationhub_require_content_approval：在集合可用前，Automation Hub 是否强制实施批准机制
automationhub_disable_https：Automation Hub 是否应该被部署为启用 TLS
automationhub_disable_hsts：Automation Hub 是否应该被部署为启用 HTTP Strict Transport Security（HSTS）Web-security 策略机制
automationhub_ssl_validate_certs：在请求自身时 Automation Hub 是否应该验证证书（默认为 False）。默认情况下，平台被部署为带有自签名证书
automationhub_ssl_cert：与 web_server_ssl_cert 相同，但用于 Automation Hub UI 和 API
automationhub_ssl_key：与 web_server_ssl_key 相同，但用于 Automation Hub UI 和 API
automationhub_backup_collections：Automation Hub 在 /var/lib/pulp 中提供工件。默认情况下，它会被设置为 true，因此 Tower 会默认自动备份工件。如果在此挂载了一个分区（如 LVM、NFS、CephFS 等），企业级的机构会确保它始终被备份。因此，您可以设置 automationhub_backup_collections = false，从而使备份/恢复过程不对 /var/lib/pulp 进行备份和恢复。
对于基于 OpenShift 的部署，请参考 OpenShift Deployment and Configuration。