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 设置为 ClusterIPLoadBalancer,或作为额外变量进行传递。

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 被配置为使用这个外部管理的数据库

  • PostgreSQL is installed in Openshift using the Tower Installer by providing a pre-created PersistentVolumeClaim and providing it the Tower install playbook inventory file as openshift_pg_pvc_name.

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

警告

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

8.6. 备份和恢复

The process for backup and restore resembles that of traditional Tower. From the root of the installer directory of the current Tower version, run:

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

注解

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

8.7. 升级

To upgrade a Tower deployment in OpenShift, you need to download and use the most recent installer from http://releases.ansible.com/ansible-tower/setup_openshift. Expect some downtime, just as traditional Tower installations.

8.8. 迁移

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

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

  2. 下载 OpenShift 安装程序。

  3. 编辑 inventory 文件,把 pg_usernamepg_passwordpg_databasepg_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