1. 准备 Tower 安装¶

本指南帮助您完成 Ansible Tower 安装，并尽快运行它。

在安装结束时，您可以使用您的 web 浏览器访问并使用 Tower。

1.1. 安装和参考指南¶

虽然本指南涵盖了基础知识，但您可以参阅 Installation and Reference Guide 以了解更多信息。

在开始安装前，您可能还需要参阅 General Installation Notes

1.2. 前提条件和要求¶

注解

Tower 是一个完整的应用程序，它的安装过程包括安装一些依赖软件，如 PostgreSQL、Django、NGINX 和其他一些软件。Tower 需要在一个独立的虚拟机或云实例上安装，而不能和其他应用程序位于同一个机器上（相关的监控和日志程序除外）。虽然 Tower 和 Ansible 都是使用 Python 开发的，但它们并不是只使用简单的 Python 库。因此，Tower 不能在一个 Python virtualenv 或其他相似子系统上安装。您需要按照本指南中的内容安装它。如需了解基于 OpenShift 部署的信息，请参阅 OpenShift Deployment and Configuration。

Ansible Tower 有以下要求：

支持的操作系统：
- Red Hat Enterprise Linux 8.2 或更高的 64 位版本 (x86)
- Red Hat Enterprise Linux 7.7 或更高的 64 位版本 (x86)
- Centos 7.7 或更高的 64 位版本 (x86)

注解

从 Ansible Tower 3.6 开始，不再支持将 Ubuntu 作为 Tower 平台。

当前支持的 Mozilla Firefox 或 Google Chrome 版本
- 其它兼容 HTML5 其它兼容 HTML5 的网络浏览器可能可以正常工作，但没有经过充分测试并不被支持。。
最少 2 个 CPU 用于 Tower 安装。请参考 Ansible Tower User Guide 的 capacity algorithm 部分以确定您具体配置中 fork 数量所需的 CPU 容量。
最少 4 GB RAM 用于 Tower 安装
- 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 Tower versions 3.7 及更新版本需要运行 Ansible 版本 2.8（最低版本要求）

注解

您不能使用比上述版本旧的 PostgreSQL 和 Ansible 版本来运行 Ansible Tower 3.7 版本及之后的版本。安装脚本会在这些软件不存在时安装它们。

对于 Amazon EC2：
- 实例大小为 m4.large 或更大
- 如果超过 100 个主机，则实例大小为 m4.xlarge 或更于

1.2.1. 有关 Tower 要求的额外备注¶

虽然其他操作系统在技术上可能会正常工作，但目前只支持上述列表中的配置来进行 Ansible Tower 安装。如果您确实需要在不支持的操作系统中运行 Tower，请通过红帽客户门户网站（https://access.redhat.com/）联络 Ansible 团队。Ansible 项目提供了管理其他操作系统（节点）的信息，并有更广的支持列表。

实际 RAM 的要求取决于 Tower 同时管理的主机数量（它由作业模板或系统文件 ansible.cfg 中的 forks 参数控制）。为了避免可能的资源冲突，Ansible 建议每 10 的 fork 需要 1 GB 内存再加上 2 GB 保留内存用于 Tower。请参阅 :ref：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 团队。

由 Tower 管理的系统的要求和 Ansible 相同：http://docs.ansible.com/intro_getting_started.html

1.2.1.1. 显著的 PostgreSQL 变化¶

Ansible Tower 使用 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 3.7 中 Tower 使用 PostgreSQL 的 Software Collections 版本，所以 rh-postgresql10 scl 必须被启动才可以访问数据库。管理员可以使用 awx-manage dbshell 命令，它会自动启用 PostgreSQL SCL。
如果您只需要确定您的 Tower 实例是否可以访问数据库，您可以使用 awx-manage check_db 命令。

1.2.1.2. PostgreSQL 配置¶

另外，您可以将 PostgreSQL 数据库配置为不是由 Tower 安装程序管理的独立节点。当 Tower 安装程序管理数据库服务器时，它会使用通常为大多数工作负载推荐的默认值配置服务器。但是，您可以调整独立数据库服务器节点的这些 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。

1.2.2. Ansible 软件要求¶

虽然 Ansible Tower 依赖于 Ansible Playbook，在安装 Tower 前需要安装最新版本的 Ansible，但它不再需要手动安装 Ansible。

从 Ansible Tower 版本 2.3 开始，Tower 安装程序会尝试自动安装 Ansible 作为安装过程的一部分。以前，在运行 Tower 安装程序前，用户需要手动安装 Ansible 软件包。现在，Tower 会尝试安装最新的稳定版本的 Ansible 软件包。

如果执行捆绑的 Tower 安装，安装程序会尝试从捆绑包中安装 Ansible（及其依赖软件包）。详情请参阅使用捆绑 Tower 安装程序。

如果您选择自己手动安装 Ansible，Tower 安装程序会检测到已安装了 Ansible，并将不会尝试重新安装它。请注意，您必须使用软件包管理程序（如 yum）来安装 Ansible，并且必须安装最新的稳定版本才可以使 Ansible Tower 正常工作。Ansible Tower 3.7 及更新的版本最少需要 Ansible 2.8。

为方便起见，以下几节中提供了这些说明的总结。

1.2.3. 平台特有的安装注意事项¶

1.2.3.1. 在启用了 FIPS 模式的系统中安装 Tower¶

Tower 可以在启用了 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>
```

如需了解更多详细信息，请参阅： https://access.redhat.com/solutions/1519083

Ansible 中需要使用 paramiko 库的功能与 FIPS 不兼容。这些功能包括设置 ansible_connection=paramiko 做为传输，使用需要利用 ncclient NETCONF 库的网络模块。
TACACS+ 协议使用 md5 来混淆授权数据包的内容。启用了 FIPS 模式的系统不支持 TACACS+ Authentication。
RADIUS 协议使用 md5 来加密 Access-Request 查询中的密码；启用了 FIPS 模式的系统不支持 RADIUS Authentication。

1.2.3.2. Red Hat Enterprise Linux 及 CentOS 设置的备注¶

为了使 Ansible Tower 可以在 RHEL 8 上运行，需要安装 Ansible 2.8 或更高的版本。Ansible 2.8 及更高版本是 RHEL 8 支持的版本。
从 Ansible Tower 3.5 开始，Tower 使用 Python 3，它会在安装 Tower 时在 RHEL 8 中自动安装。
PackageKit 可能会经常影响到安装/更新机制。如果安装了 PackageKit，则考虑在运行设置（setup）过程前禁用或删除它。
只支持 "targeted" SELinux 策略。targeted 策略可以被设置为 disabled 、permissive 或 enforcing。
当执行捆绑的安装时，请参考使用捆绑 Tower 安装程序。
当安装 Ansible Tower 时，您只需要运行 setup.sh，Tower 所需的所有软件仓库都会被自动安装。
在设置过程中会自动安装最新版本的 Ansible。不需要进行额外的安装或配置。

1.2.3.3. Ubuntu 设置备注¶

Ansible Tower 不再支持 Ubuntu。如需更多与 Ubuntu 相关的信息，请参阅 Ansible Tower Installation and Reference Guide 以前的版本。

1.2.3.4. OpenShift 上的配置和安装¶

对于基于 OpenShift 的部署，请参考 OpenShift Deployment and Configuration。

1.3. Tower 安装场景¶

可使用以下场景之一安装 Tower：

单机：

作为一个集成安装：
- 这是一个单一的 Tower 机器安装 - web 前端、REST API 后端和数据库都安装在一台机器上。这是 Tower 的标准安装。它还会从您的 OS 厂商仓库中安装 PostgreSQL，并将 Tower 服务配置为将其用作数据库。
使用外部数据库（2 个可用选项）：
- 带有远程 DB 配置的 Tower：这会在一台机器上安装 Tower 服务器，并将它配置为使用一个远程的 PostgreSQL 10 实例作为它的数据库。这个远程 PostgreSQL 可以是您自己管理的服务器，也可由云服务商（如 Amazon RDS）提供。
- 带有使用 playbook 安装的远程 PostgreSQL 的Tower：这会在一台机器上安装 Tower 服务器，并通过 playbook 安装程序（由 Tower 管理）安装远程 PostgreSQL 数据库。

注解

1). Tower 将不会为它使用的数据库配置复制或故障转移功能，但 Tower 应该可以和已有的复制机制一起工作。2). 数据库服务器应该位于同一个网络或同一个数据中心以使 Tower 服务器具有高性能。

用于传统 Tower 安装的设置：

pg_sslmode 控制 PostgreSQL 客户端的 SSL 功能，例如 Tower 服务器如何连接到数据库。它的默认值是 prefer，如果数据库服务器提供 SSL，客户端将使用它。您还可以将其设置为 verify-full 来完全验证证书信任以强制实现 SSL。
用户使用 web_server_ssl_cert 和 web_server_ssl_key 提供 Tower UI 和 API 的 web 服务器上要安装的证书和密钥。它们必须同时提供，或同时不提供。如果没有提供，会在安装时生成一个自签发（不受信任）的证书。
postgres_use_ssl (true/false) - 控制 PostgreSQL 服务器是否会被配置为需要 SSL。这只会对内部/嵌入的数据库（例如，Tower 安装脚本正在执行数据库服务器部署时）产生影响。它对外部数据库没有影响。
postgres_ssl_cert 和 postgres_ssl_key - 在 postgres_use_ssl 为 true 时必须提供。这些证书应该具有与 Tower 节点用来连接到数据库服务器的主机名匹配的 CN（或通配符、主题备用名称等等）。

对于基于 OpenShift 的部署，请参考 OpenShift Deployment and Configuration。

高可用性多机器集群：

Tower 可以以一个高可用性集群的形式安装。在这个模式下，会安装并激活多个 Tower 节点。任何节点都可以接收 HTTP 请求，所有节点都可以执行作业。

集群的 Tower 环境需要有一个外部的数据库（2 个可用选项）：
- 带有远程 DB 配置的 Tower：这会在一台机器上安装 Tower 服务器，并将它配置为使用一个远程的 PostgreSQL 实例作为它的数据库。这个远程 PostgreSQL 可以是您自己管理的服务器，也可由云服务商（如 Amazon RDS）提供。
- 带有使用 playbook 安装的远程 PostgreSQL 的Tower：这会在一台机器上安装 Tower 服务器，并通过 playbook 安装程序（由 Tower 管理）安装远程 PostgreSQL 数据库。
有关配置集群设置的详情，请参考集群。

注解

在集群设置中运行需要 Tower 使用外部的数据库，PostgreSQL 必须在一个不是主（primary）或（secondary）tower 节点的机器上安装。在一个冗余设置中，远程 PostgreSQL 版本要求是 PostgreSQL 10。