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 使用不同的安装程序。

  • 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.11+（请参阅 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 所需的容器及特权模式中的任务容器需要被授予特定权限。

8.4. 资源请求和请求规划

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

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

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

每个 Tower pod 都由 4 个容器组成（请参阅 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 2.3 安装到自定义的虚拟环境中：

FROM registry.access.redhat.com/ansible-tower/ansible-tower:3.3.0
USER root
RUN mkdir -p /var/lib/awx/venv/ansible2.3
RUN virtualenv --system-site-packages /var/lib/awx/venv/ansible2.3
RUN cp -a /var/lib/awx/venv/ansible/lib64/python2.7/site-packages/* /var/lib/awx/venv/ansible2.3/lib64/python2.7/site-packages/
RUN sh -c ". /var/lib/awx/venv/ansible2.3/bin/activate ; pip install ansible==2.3.3.0"

如果您需要安装其他 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

注解

镜像必须使用 3.3.0 标签（tag），或者将版本变量传递给安装程序进行覆盖。

在本地 registry 中托管所有镜像（如离线安装）时，您需要包含这些其他镜像：

kubernetes_memcached_image: registry.example.com/ansible-tower-memcached

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

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