Documentation

8. OpenShift 部署和配置

Ansible Tower 支持在 OpenShift 上运行的基于容器的集群。本节概述了 OpenShift 和 Tower Pod 配置，特别是：

  • 标准 Tower 与 OpenShift Tower 的主要区别（如自动删除实例）

  • Tower 首先作为单个 pod 进行部署，并可在迁移后扩展

  • 迁移在任务运行程序 pod 中运行

_images/clusters-task-runner-pod-diagram.png

8.1. Tower 和 OpenShift

Tower OpenShift 文档假定读者了解如何在管理级别使用 OpenShift，并具有维护基于容器的基础架构的一些经验。不同之处是：

  • 独立的 Tower 和 OpenShift Tower 使用不同的安装程序。对于 OpenShift 安装程序，请访问 http://releases.ansible.com/ansible-tower/setup_openshift。

  • Tower 连接到 OpenShift 自身，以便在不需要用户手动执行 playbook（使新节点上线）或在 shell 中运行管理命令（使下线节点）的情况下，进行扩展和缩减。用户可在系统启动后配置 Tower Deployment 来添加更多的 Tower Pod，或删除额外的 Tower Pod。

  • 在没有 HTTPs 的情况下配置 Tower Pod，安装程序会配置一个 OpenShift 路由，该路由将处理 SSL 终止问题，并将请求发送到所有 Tower Pod。这在某种程度上相当于一个内部 OpenShift 负载均衡器。

  • 数据库迁移作为在 pod 中上线任务执行器容器程序的一部分运行（见图），因此通常在 playbook 完成后进行。

  • 容量/性能检测（请参阅 资源请求和请求规划）。

  • 在 OpenShift 中运行 Ansible Tower 不支持隔离的实例。

8.2. 配置选项

要求

  • 最新支持的 OpenShift 版本 3.x 和 4.x（详情请参阅 Red Hat Container Registry Authentication）

  • 每个 pod 默认资源要求：

    • 6GB RAM

    • 3CPU 内核

  • 在运行安装程序的机器上使用 OpenShift 命令行工具 (oc)

  • 已设置并正在运行的 Openshift 集群

  • 运行 openshift 安装程序的帐户的 admin 权限 （需要 cluster-admin 角色）

8.3. 基本配置

OpenShift 安装需要设置以下参数：

  • openshift_host

  • openshift_project

  • openshift_user

  • openshift_password

  • admin_password

  • secret_key

  • pg_username

  • pg_password

对于 OpenShift 安装方法，设置与 traditional Tower install method 相同，除了：

  • Tower UI 和 API 的 SSL 终止通过 OpenShift 服务对象处理。这里使用的证书由 OpenShift 内部 CA 生成并签名。

  • 可以选择部署到 OpenShift 安装中的容器化 PostgreSQL pod 无法配置 SSL。如果您在 OpenShift 环境中需要启用 SSL 的 PostgreSQL，则必须单独部署 PostgreSQL 服务器并配置 Tower 节点（使用 pg_sslmode）。

如果项目不存在，则创建项目，但用户需要满足以下条件之一：

  • 能够创建项目并在项目中添加 Tower 所需的 pod

或

  • 如果项目已存在，具有可以在项目中创建所需 pod 的权限

在执行安装程序时，需要在命令行中提供密码。

oc 命令行客户端应已安装并可用，客户端的版本应与服务器版本匹配。

在运行安装程序前，secret-key、管理员密码和 postgresql 用户名和密码应该被填充到清单文件中。

./setup_openshift.sh -e openshift_password=$OPENSHIFT_PASSWORD -- -v

注解

Tower 使用 Bubblewrap（来自 Project Atomic），为（相对）非特权的 awx 用户提供能够相互隔离不同 Ansible 进程的机制。运行 Tower web 所需的容器及特权模式中的任务容器需要被授予特定权限。

Tower web 服务的默认类型为 NodePort。要对它进行定制，在于清单文件中把 kubernetes_web_svc_type 设置为 ClusterIP 或 LoadBalancer，或作为额外变量进行传递。

8.4. 资源请求和请求规划

通常 Tower 会检查运行它的系统，以确定其自身运行作业和执行后台请求的能力。在 OpenShift 上会有所不同，因为 pod 和容器会共同存在于系统中。Pod 也可以根据当前状况（例如，如果 OpenShift 集群正在升级或处于停机状态）在主机间迁移。

Pod 和容器请求所需资源很常见。OpenShift 会根据此信息来决定运行位置（甚至确定是否可以运行）。

Tower 还将使用此信息来配置自身容量，确定可运行的独立作业的数量（及大小）。

每个 Tower pod 都由 3 个容器组成（请参阅 diagram），每个容器都配置有比较保守的默认值，但在将它们集中在一起时就可能会具有较大的值。这些默认设置也可以进行配置，但您最好在了解它们对集群的影响时才进行配置。

两个最重要的用来控制任务执行容器的 CPU 和内存分配的值。该容器实际上负责启动作业，因此这些值直接控制可以运行的作业数量和大小。这些设置可以在清单中更改，以下是它们的默认值：

task_cpu_request=1500

这是要使用的 CPU 数量，1500 代表 OpenShift 自身的 CPU 请求（请参阅 https://docs.OpenShift.com/container-platform/3.9/dev_guide/compute_resources.html#dev-cpu-requests）（有关值的含义，请参阅 https://docs.OpenShift.com/container-platform/3.9/dev_guide/compute_resources.html#dev-compute-resources）

1500 是 1500 毫秒，可转换为大约 1.5 个 CPU 内核。

此值用来配置 Tower 容量，其方式如下：

((task_cpu_request/ 1000) * 4)

也就是说，默认情况下，OpenShift 的 Tower（完全配置为基于 cpu 的算法进行配置）可以最多运行 6 个并发分叉。

可调整的其他值：

task_mem_request=2 - This is the amount of memory to dedicate (in gigabytes).

在使用以下方式配置 Tower 容量是使用的值：

((task_mem_request * 1024) / 100)

也就是说，默认情况下，在为基于内存算法进行配置时，Tower 最多可运行 40 个并发分叉。

有关默认资源请求，请参阅 roles/kubernetes/defaults/main.yml。

将默认请求资源合并在一起的单个 Tower pod 的总计：

  • 3 个 CPU 内核

  • 6 GB 内存

要运行 Tower 的 OpenShift 实例应至少匹配这些值。如果更改了默认值，系统将需要更新以符合新要求。

注解

如果其他 Pod 在 OpenShift 实例上运行，或者系统太小，无法满足这些要求，那么 Tower 可能无法在任何位置运行。如需详情，请参阅 Capacity Algorithm。

8.5. 数据库配置和使用

对于在 Openshift 中运行的 Tower，有两个方法配置 Tower PostgreSQL 数据库：

  • （推荐）**外部管理的数据库**（不是由 Tower 设置 (setup) playbook 安装）。PostgreSQL 服务器会在 Tower 之前安装在 Openshift 集群内部或外部，而 Tower 被配置为使用这个外部管理的数据库

  • 使用 Tower 安装程序在 Openshift 中安装 PostgreSQL，方法是提供预创建的 PersistentVolumeClaim 并为其提供 Tower 安装 (install) playbook 清单文件 pg_pvc_name。

如果您安装 Tower 的目的是用于演示/评估，您可以设置 openshift_pg_emptydir=true，OpenShift 将创建一个临时卷供 pod 使用。

警告

此卷仅用于演示/评估目的，并在 pod 停止后删除。

8.6. 备份和恢复

您必须在升级前备份并恢复到同一版本。备份和恢复的过程类似传统的 Tower。从安装程序的根目录，运行：

./setup_openshift.sh -b # Backup
./setup_openshift.sh -r # Restore

注解

将利用清单文件中的值重新创建 configmap。清单文件包含在 tarball 中。

8.7. 升级

在进行升级前，您必须进行备份并保证可以恢复到升级前的版本。要升级 OpenShift 中的 Tower 部署，请从 http://releases.ansible.com/ansible-tower/setup_openshift 下载最新的安装程序。预期会停机一段时间，与传统的 Tower 安装一样。

8.8. 迁移

Tower 支持从传统设置迁移到 OpenShift 中的设置，如下所示：

  1. 首先，使用正常升级过程，将您的传统 Tower 设置升级到最新的 Ansible Tower 发行版本（至少升级到版本 3.3）。

  2. 下载 OpenShift 安装程序。

  3. 编辑 inventory 文件，把 pg_username、pg_password、pg_database 和 pg_port 的值从您的传统 Tower 设置改为升级的 Tower 数据库设置。

  4. 以正常方式运行 OpenShift 安装程序。

警告

不要在 pg_password 中使用特殊字符， 因为它可能导致设置失败。

8.9. 构建自定义虚拟环境

可能会覆盖基础容器镜像来构建自定义虚拟环境（virtualenvs）。覆盖基础容器用于定制和自定义 virtualenv 支持，或用于本地镜像 (mirroring)。如果要使用 OpenShift 中部署 Tower 的自定义虚拟环境，则需要定制 Tower 使用的容器镜像。

以下是一个可用作示例的 Dockerfile。这可将 Ansible 安装到自定义的虚拟环境中：

FROM registry.redhat.io/ansible-tower-38/ansible-tower-rhel7
USER root
RUN yum install -y gcc python-devel openssl-devel
RUN umask 0022
RUN virtualenv /var/lib/awx/venv/ansible2.7
RUN /var/lib/awx/venv/ansible2.7/bin/pip install psutil python "ansible==2.7.9"

如果您需要安装其他 python 依赖项（如自定义模块的依赖项），您可以在激活虚拟环境和调用 pip 的 docker 文件中添加其他 RUN 命令。

构建镜像后，请确保镜像位于 registry 中，并且 OpenShift 集群和安装程序有权访问该镜像。

覆盖 group_vars/all OpenShift 安装程序中的以下变量，以指向推送到 registry 的镜像：

kubernetes_web_image: registry.example.com/my-custom-tower
kubernetes_task_image: registry.example.com/my-custom-tower

如果镜像 (mirroring) 了 vanilla Red Hat 镜像：

kubernetes_web_image: registry.example.com/ansible-tower
kubernetes_task_image: registry.example.com/ansible-tower