Red Hat Ansible Automation Platform from GCP Marketplace Guide
从 GCP Marketplace 安装和配置 Red Hat Ansible Automation Platform
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
对红帽文档提供反馈
我们非常感谢您对我们的技术内容提供反馈,并鼓励您告诉我们您的想法。如果您想添加评论,提供见解、纠正拼写错误甚至询问问题,您可以在文档中直接这样做。
您必须有一个红帽帐户并登录到客户门户网站。
要从客户门户网站提交文档反馈,请执行以下操作:
- 选择 Multi-page HTML 格式。
- 点文档右上角的 反馈 按钮。
- 突出显示您要提供反馈的文本部分。
- 点高亮文本旁的添加反馈对话框。
- 在页面右侧的文本框中输入您的反馈,然后点 Submit。
每次提交反馈时,我们都会自动创建跟踪问题。打开在点 Submit 后显示的链接,并开始监视问题或添加更多注释。
免责声明 :本文档中包含的指向外部网站的链接仅用于方便。红帽没有审阅链接的内容,并不对其内容负责。包含任何指向外部网站的链接并不表示红帽认可该网站或其实体、产品或服务。您同意红帽对因您使用(或依赖)外部网站或内容而导致的任何损失或费用不承担任何责任。
第 1 章 简介
GCP Marketplace 中的 Ansible Automation Platform 是一个可从 GCP Marketplace 门户部署的产品。来自 GCP Marketplace 的 Ansible Automation Platform 提供对 Ansible 内容集合库的访问,并与密钥 GCP 服务集成,以便您可以快速启动自动化部署、配置和管理基础架构和应用程序。
以下 Red Hat Ansible Automation Platform 组件在 GCP Marketplace 的 Ansible Automation Platform 上提供:
目前,从 GCP Marketplace 在 Ansible Automation Platform 上不提供自动化网格。
1.1. 应用程序架构
来自 GCP Marketplace 的 Red Hat Ansible Automation Platform 被安装到 GCP 帐户中运行的基础架构资源中。

GCP Marketplace 中的 Ansible Automation Platform 设计为私有,默认不允许使用公共访问权限。
这需要客户公开部署的 内部负载平衡器 (ILB)本身是否符合自己的网络要求和安全实践。公开 ILB 的一些潜在方法包括 VPC Peering, Transit Gateway, VPN, External Load Balancers 等。
所有云基础架构组件都部署在 虚拟私有云 (VPC)中。
客户可以选择部署到现有的 VPC 中,或者产品为其部署新的 VPC。默认情况下,所有虚拟机实例和云基础架构都有私有 IP 地址(由部署时指定的 VPC 和子网决定)。
所有内部流量都使用部署时生成的自签名证书进行加密(也可以通过在产品部署的 Internal Load Balancers 上部署您自己的证书来加密外部流量)。
Ansible Automation Platform 软件作为容器在部署的虚拟机实例上运行。
受管实例组 (MIG)管理虚拟机实例生命周期并监控虚拟机实例上运行的每个服务的健康状态,如果健康检查无法响应,则自动关闭虚拟机实例并将其替换为新的虚拟机实例,确保 Ansible Automation Platform 服务保持稳定并可用于处理请求。
虚拟机实例运行自定义 的红帽企业 Linux (RHEL) Google Cloud Machine Image 作为其基础镜像。此 Google Cloud Machine Image 会预先加载所有所需的容器镜像和软件包,以运行 Ansible Automation Platform (自动化中心、自动化控制器和执行节点组件)。
共享 Google File Store (GFS)卷被挂载到产品置备的每个虚拟机实例中,用于共享对常见文件和资源的访问。
Google Cloud SQL Service 在部署时由产品置备,包含自动化控制器和自动化中心的数据库。

Foundation 产品包含与自动化控制器组件在同一虚拟机实例上运行的两个执行节点(这称为 Ansible Automation Platform 中的混合节点配置)。可以购买额外的执行节点产品,以增加 Ansible Automation Platform 部署许可的规模(受管节点的总数)。将执行节点产品部署到现有的 Ansible Automation Platform Foundation 部署中时,可以部署额外的执行节点虚拟机实例,并自动连接到基础部署的自动化控制器,以便立即开始处理自动化任务。
Ansible Automation Platform 组件使用 Podman 容器运行时在虚拟机实例上作为容器运行。Podman 运行时配置作为系统服务使用 systemd 进行管理,以确保正常运行时间和可用性,以及自动重启任何失败的容器。
在虚拟机实例上启用 SELinux,并支持到容器级别。
产品提供了额外的操作自动化,可作为单独的 docker 容器从 registry.redhat.io 下载。这些额外的操作自动化包括备份、恢复和升级。
在 RHEL OS 基础镜像、Ansible Automation Platform 容器或任何包含的软件包都包括在升级 Ansible Automation Platform 产品的过程中解决了在升级 Ansible Automation Platform 产品中的 常见漏洞和风险 (CVE),方法是将基础 RHEL Google Cloud Machine 镜像与较新的版本(包括所有必需的软件、软件包和容器)交换出来。
这可以通过使用包含的升级自动化来自动完成此操作。
客户可以利用这些操作自动化来简化他们自己的企业标准内 Ansible Automation Platform 的操作就绪性,让自己专注于开发 Ansible Automation 以管理自己的基础架构和应用程序,而不是花费在开发自动化管理 Ansible Automation Platform 的时间。
1.2. 服务描述
| 服务名称 | 描述 |
|---|---|
| Compute Engine | GCP VM 计算平台 |
| Cloud SQL | GCP 数据库服务 |
| FileStore | GCP 文件存储服务 |
| 虚拟私有云(VPC) | GCP 网络服务 |
| 云监控 | GCP 指标收集器 |
| 云日志记录 | GCP 日志管理服务 |
第 2 章 安装
2.1. 先决条件
在安装和注册 Ansible Automation Platform 之前,您必须熟悉 GCP,包括服务操作方式、数据存储方式以及这些服务可能存在的任何隐私影响。您还必须使用 Google Cloud Platform (GCP)设置帐户。
您必须了解 Google Cloud Platform 的以下方面:
- 从 GCP Marketplace 部署解决方案
- 计算 引擎虚拟机 (VM)实例
- PostgreSQL 的云 SQL
- FileStore
GPC Virtual Private Clouds (VPC)
- 子网
- 路由表
- Load Balancers
网络设计
- hub-and-spoke 网络设计
- VPC Peering
- 类域间路由 (CIDR)块
- 传输路由
GCP Cloud 监控
- GCP Ops 代理
- SSH
有关 Google Cloud Platform 和术语的更多信息,请参阅 GCP 产品文档。
2.2. 创建一个项目
要安装 Ansible Automation Platform,您必须在 Google Cloud Platform 帐户中创建项目,以便在还没有应用程序时托管应用程序。请参阅 GCP 文档中的 创建和管理项目。
2.2.1. 所需的 API
Google Cloud Platform (GCP)项目需要访问多个 API 服务来完成 Ansible Automation Platform 安装。在 marketplace 部署中,流程会自动尝试启用以下 API。
如果您愿意,您可以提前启用 API,以确保您的机构允许它们。
| API 服务 | 控制台服务名称 |
|---|---|
| Compute Engine API |
|
| Google Cloud API |
|
| Identity and Access Management(IAM)API |
|
| Cloud SQL Admin API |
|
| Cloud Logging API |
请参阅监控和日志记录 |
| 云监控 API |
请参阅监控和日志记录 |
| Cloud Resource Manager API |
|
| 云身份代理 API |
|
| Secret Manager API |
|
| 服务网络 API |
|
| Service Usage API |
|
| OS Config API |
|
| Cloud Runtime Configuration API |
|
| Cloud Filestore API |
|
2.2.2. 创建服务帐户
您必须有一个服务帐户才能从 GCP Marketplace 设置 Ansible Automation Platform。此帐户用于安装和配置应用程序,并保持与 Ansible Automation Platform 虚拟机关联的。您可以使用具有所需角色的现有服务帐户,或者 Ansible Automation Platform 部署可以代表您需要的角色创建一个。如果使用现有帐户,或者提前创建服务帐户,则必须具有以下角色:
- Editor
- logs Writer
- Cloud SQL Client
- Cloud SQL 实例用户
- Secret Manager Secret Accessor
- Compute Network Admin
如需了解 将所需角色添加到现有服务帐户的步骤,请参阅授予单个角色。
只有在部署时才需要 Compute Network Administrator 角色来正确配置应用。安装并配置完成后,可以从服务帐户中删除此角色,该帐户仍然在 Ansible Automation Platform Virtual Machines 上配置。
2.2.3. 策略和权限
您的 GCP 帐户必须具有以下 Identity and Access Management (IAM)权限,才能成功创建和管理 Ansible Automation Platform 部署,以及 应用程序架构 中描述的资源。
您的 GCP 帐户还必须被授权从 GCP Marketplace 部署 Ansible Automation Platform。
如果您的 IAM 策略限制了这些资源的部署和管理,应用程序将无法部署。
应用程序有两个部署选项:
- 使用新的 VPC 创建部署。
- 使用现有的 VPC 创建部署。
两个选项都需要相同的最小权限
Cloud SQL Client Cloud SQL Instance User Compute Network Admin Editor Logs Writer Secret Manager Secret Accessor
2.3. 应用程序部署
要在 Google Cloud Console 上启动您的服务,请进入到 marketplace 并搜索 Red Hat Ansible Automation Platform 2 - Up to 100 Managed Nodes。选择此项后,点启动。
一个临时但必需的约束被放置在部署名称的长度上。这是因为 GCP 在组成 Ansible Automation Platform 部署的内部组件的命名方案。基于此命名方案的组件名称可能会太长,通常破坏其他服务实施的命名限制,创建部署错误。
部署名称的长度,以及您的 GCP 项目名称长度必须小于 35 个字符,部署名称的长度必须小于 30 个字符。
以下计算将帮助您在项目中找到 Ansible Automation Platform 部署的名称的最大长度。
length of deployment name < = (minimum between 30 and 35) - length(gcp project name)
部署应用程序的方法有两种:
2.3.1. 使用新的 VPC 部署应用程序
此流程创建新的 VPC 网络,并在创建的 VPC 中部署应用程序。
流程
- 在 Deployment 页面中,选中 Confirm Service Usage API is enabled 下的 Service Usage API 链接。
- 在 API/Service Details 选项卡中,确保启用 API,然后返回到 Deployment 页面。
- 选中 Confirm Service Usage API is enabled 复选框。
- 选择或 创建服务帐户。如需更多信息,请参阅您的服务帐户。
- 在 Region 字段中,选择您要部署应用的区域。
- 在 Zone 字段中,选择您希望部署 Filestore 的区域。区域必须位于您选择的区域。
- 在 Observability 部分,您可以启用日志记录和指标发送到云日志记录和云监控。如需启用这些服务的财务成本,请参阅 运营套件定价。有关配置此功能的更多信息,请参阅监控和日志记录。
- 在 Network Selection 部分中,选择 New network。Networking 部分为部署中使用的所有网络范围提供默认值。如果要修改这些值,请参阅网络选项。
- 可选: 在 Additional Labels 部分中,提供添加到属于部署一部分的 GCP 资源的额外标签键和值对。有效键和值必须满足 GCP 标签要求。对于 键,只允许连字符、下划线、小写字符和数字。键 必须以小写字符开头。对于 值,只允许连字符、下划线、小写字符和数字。
- 单击 DEPLOY。
- Deployment Manager 显示正在运行的部署。
- 应用程序开始置备。可能需要过些时间,基础架构和应用程序才会完全调配。
您将看到部署上的警告
This deployment has resources from the Runtime Configurator service, which is in Beta
这个警告是正常的,不会导致问题。
如果要在部署后修改网络范围,则必须删除您的当前部署,然后按照 使用现有 VPC 部署应用程序中 的说明进行操作。
2.3.2. 使用现有 VPC 部署应用程序
以下流程使用现有的 VPC 网络来部署应用程序。
流程
- 在 Deployment 页中,选择 Confirm Service Usage API is enabled 下的 Service Usage API 链接。
- 在 API/Service Details 选项卡中,确保启用了 API,然后返回到 Deployment 页面。
- 选中 Confirm Service Usage API is enabled 复选框。
- 选择或 创建服务帐户。如需更多信息,请参阅您的服务帐户。
- 在 Region 字段中,选择您要部署应用的区域。
- 在 Zone 字段中,选择您希望部署 Filestore 的区域。区域必须位于您选择的区域。
- 在 Observability 部分,您可以启用日志记录和指标发送到云日志记录和云监控。如需启用这些服务的财务成本,请参阅 运营套件定价。有关配置此功能的更多信息,请参阅监控和日志记录。
- 在 Network Selection 部分中,选择 现有网络。
在 Existing Network 部分中,提供现有的 VPC 网络名称、现有子网名称和现有代理子网名称。
注意现有代理子网必须是 Regional Managed Proxy 类型,这是用于负载平衡的保留仅代理子网。
选择 云 NAT 路由器 在 VPC 网络中创建 NAT 路由器。
- Networking 部分为部署中使用的所有网络范围提供默认值。根据现有网络配置提供这些值。如果要修改这些值,请参阅网络选项
- 可选: 在 Additional Labels 部分中,提供添加到属于部署一部分的 GCP 资源的额外标签键和值对。有效键和值必须满足 GCP 标签要求。对于 键,只允许连字符、下划线、小写字符和数字。键 必须以小写字符开头。对于 值,只允许连字符、下划线、小写字符和数字。
- 单击 DEPLOY。
- Deployment Manager 显示正在运行的部署。
应用程序开始置备。可能需要过些时间,基础架构和应用程序才会完全调配。
注意您将在部署中看到警告。
This deployment has resources from the Runtime Configurator service, which is in Beta.
这个警告是正常的,不会导致问题。
2.4. 部署信息
部署 Ansible Automation Platform 后,请使用以下步骤检索与部署相关的信息。
2.4.1. 检索管理密码
使用以下步骤检索管理密码。
流程
- 在 GCP UI 中,选择主菜单。
- 选择 Security。如果没有看到 Security,请选择 View All Products。
- 选择 Secret Manager。
-
使用部署的名称替换。secret 名称格式为 <
DeploymentName>-aap-admin。 - 单击部署的 secret 名称
- 点部署 行中的 More Actions 图标。
- 选择 View secret value。此时会显示管理密码。
2.4.2. 检索负载均衡器地址
使用以下步骤检索控制器和 hub IP 地址。
流程
- 在 GCP UI 中,选择主菜单。
- 选择 Deployment Manager。
- 选择 Deployments。
- 选择部署名称。
- 选择 View Details。
- 在右侧窗格中,在 Deployment 属性下, 找到 Layout 行。
- 选择 View。Outputs: 部分 显示名称 controllerIp 和 hubIp 的 finalValue。
2.5. 在部署时设置监控和日志记录
流程
- 在 GCP UI 中,进入到 Observability。
选中 Connect Logging 和 Connect Metrics 复选框。
注意这些复选框仅适用于基础部署。
2.6. 部署扩展节点
在从公共或私有提供购买并启动扩展后,您可以配置扩展节点。
流程
- 在 Deployment name 字段中,输入足够简短的名称,如 应用程序部署 中所述。
- 对于 服务帐户,请选择用于 Red Hat Ansible Automation Platform 的服务帐户,最多 100 个受管节点部署。
- 在 Region 字段中,选择您要部署应用的区域。
- 在 Zone 字段中,在部署基础产品时,在 Region 中选择一个区。此字段仅用于过滤网络列表。
在 Main Deployment Name 字段中输入您要部署扩展的基础部署名称。
注意主 Deployment Name 是必填字段。
- 在 Networking 部分中,展开默认选项。
-
在 Network 字段中,选择以
-aap-net结尾的现有基础网络。 在 Subnetwork 字段中,选择以
-aap-subnet结尾的现有基础子网。重要不要选择以
-aap-proxy-subnet结尾的子网。- 确保选中了在所选 VPC 中扩展 Ansible Automation Platform 部署。
- 单击 DEPLOY。
- Deployment Manager 显示正在运行的部署。
扩展开始置备。
可能需要过些时间,基础架构和扩展才能完全调配。
第 3 章 部署扩展节点
默认情况下,基础部署有两个自动化控制器节点和一个自动化中心节点。您可以添加执行节点,从 GCP Marketplace 扩展 Ansible Automation Platform。扩展节点提供一起混合和匹配,以扩展和横向扩展 Ansible Automation Platform 部署。
在部署新扩展节点前,您必须创建 Ansible Automation Platform 部署的备份。
该流程包含以下步骤:
- 决定扩展节点的提供类型。
- 确保满足管理扩展节点的最小权限。
-
拉取
ansible-on-clouds-ops容器镜像。 -
运行
ansible-on-clouds-ops容器来生成数据文件。 - 填充数据文件。
-
运行
ansible-on-clouds-ops容器来部署扩展节点。
前提条件
- Linux 或 macOS 系统(将运行 ansible-on-clouds-ops 容器镜像)。
- Docker
3.1. 决定提供的类型
下表列出了提供的类型和对应的 GCP 实例类型。根据工作负载需求,您可以为扩展节点选择更合适的产品类型。
| 优惠类型(节点) | GCP 实例类型 |
|---|---|
| 100 | n2-standard-2 |
| 200 | n2-standard-4 |
| 400 | n2-standard-8 |
扩展节点提供可以混合和匹配,以扩展 Ansible Automation Platform 部署。
3.2. IAM 最低权限
您的 GCP 帐户必须具有以下 Identity and Access Management (IAM)权限,才能在 Ansible Automation Platform 上成功创建和管理扩展节点。
您的 GCP 帐户还必须被授权从 GCP Marketplace 部署为 Ansible Automation Platform 提供的扩展节点。
Minimum Permissions - Cloud SQL Client Cloud SQL Instance User Editor Logs Writer Secret Manager Secret Accessor IAP-secured Tunnel User
3.3. 拉取 ansible-on-clouds-ops 容器镜像
在云操作容器上拉取 Ansible 的 Docker 镜像,其标签与您要部署到的版本相同。
在拉取 docker 镜像前,请确保使用 docker 登录到 registry.redhat.io。使用以下命令登录到 registry.redhat.io。
$ docker login registry.redhat.io
如需有关 registry 登录的更多信息,请参阅 Registry 身份验证
例如,如果您的基础部署版本是 2.4.20230630-00,则必须拉取带有 2.4.20230630 标签的操作镜像,以便将扩展节点部署到基础部署中。
使用以下命令:
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
3.4. 运行 ansible-on-clouds-ops 容器来生成数据文件
以下命令生成所需的数据文件。这些命令创建目录,并在部署扩展节点时使用空数据模板。
流程
创建用于存放配置文件的文件夹。
$ mkdir command_generator_data
使用配置文件模板填充
command_generator_data文件夹。$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE \ command_generator_vars gcp_add_extension_nodes \ --output-data-file /data/extra_vars.yml
这些命令创建一个
command_generator_data/extra_vars.yml模板文件。此模板文件类似于以下内容:gcp_add_extension_nodes: cloud_credentials_path: deployment_name: extra_vars: gcp_compute_region: gcp_extension_node_subscription: gcp_instance_group_name: gcp_instance_template_name: gcp_offer_type:
3.5. 填充数据文件
在触发操作前,您必须填充数据文件。数据文件中列出的变量定义如下。
-
cloud_credentials_path是 Google Cloud 服务帐户凭证文件的路径。这必须是绝对路径。 -
DEPLOYMENT_NAME 是您要为其创建扩展节点的 AAP 部署的名称。 -
gcp_instance_group_name是要为扩展节点创建的 GCP 实例组的名称。 -
gcp_instance_template_name是要创建的 GCP 实例模板的名称。 -
gcp_offer_type是扩展节点的提供类型。这必须是 100、200 或 400。 -
gcp_compute_region是部署基础部署的 GCP 区域。这可以通过检查 Deployment Manager 中的 Deployments 配置来检索。 -
gcp_extension_node_subscription是确认是否购买扩展节点订阅的标记。必须为true或false。
3.6. 部署扩展节点
流程
若要部署扩展节点,可运行命令生成器来生成 CLI 命令。
$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator --data-file /data/extra_vars.yml
提供以下命令:
----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro / --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> / --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_add_extension_nodes / -e 'gcp_deployment_name=<deployment_name> gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_compute_region=<region> gcp_instance_template_name=<instance_template_name> / gcp_instance_group_name=<instance_group_name> gcp_offer_type=100 gcp_extension_node_subscription=True' ===============================================
运行提供的命令来添加扩展节点。
$ docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro / --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=leena1 / --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_add_extension_nodes / -e 'gcp_deployment_name=<deployment_name> gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_compute_region=<region> gcp_instance_template_name=<instance_template_name> / gcp_instance_group_name=<instance_group_name> gcp_offer_type=100 gcp_extension_node_subscription=True'
playbook 运行后,输出类似于以下内容:
TASK [redhat.ansible_on_clouds.standalone_gcp_add_extension_nodes : [deploy_extension_nodes] Extension node created] *** ok: [localhost] => { "msg": "Extension node is created for deployment test-ext1." } PLAY RECAP ********************************************************************* localhost : ok=39 changed=5 unreachable=0 failed=0 skipped=6 rescued=0 ignored=0
第 4 章 删除扩展节点
在删除扩展节点前,您必须创建 Ansible Automation Platform 部署的备份。
按照以下步骤从 Ansible Automation Platform 从 GCP Marketplace 环境中删除执行节点。
先决条件
-
Linux 或 macOS 系统(将运行
ansible-on-clouds-ops容器镜像) - Docker
步骤
-
拉取
ansible-on-clouds-ops容器镜像。 - 运行 ansible-on-clouds-ops 容器来生成数据文件。
- 更新数据文件。
-
运行
ansible-on-clouds-ops容器,以删除扩展节点。
4.1. 拉取 ansible-on-clouds-ops 容器镜像
使用与基础部署相同的标签,在云操作容器上拉取 Ansible 的 Docker 镜像。
在拉取 docker 镜像前,请确保使用 docker 登录到 registry.redhat.io。使用以下命令登录到 registry.redhat.io。
$ docker login registry.redhat.io
如需有关 registry 登录的更多信息,请参阅 Registry 身份验证
例如,如果您的基础部署版本是 2.4.20230630-00,则必须拉取带有 2.4.20230630 标签的操作镜像,以便将扩展节点部署到基础部署中。
使用以下命令:
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
4.2. 运行 ansible-on-clouds-ops 容器来生成数据文件
以下命令生成所需的数据文件。这些命令会创建目录,并在升级过程中使用填充时的空数据模板。
流程
创建用于存放配置文件的文件夹。
$ mkdir command_generator_data
使用配置文件模板填充
$(pwd)/command_generator_data文件夹。$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE \ command_generator_vars gcp_remove_extension_nodes \ --output-data-file /data/extra_vars.yml
运行这些命令时,会创建一个 command_generator_data/extra_vars.yml 模板文件。此模板文件类似于以下内容:
gcp_add_extension_nodes:
cloud_credentials_path:
deployment_name:
extra_vars:
gcp_compute_region:
gcp_instance_group_name:
gcp_instance_template_name:4.3. 填充数据文件
在触发操作前,您必须填充数据文件。数据文件中列出的变量定义如下。
-
cloud_credentials_path是 Google Cloud 服务帐户凭证文件的路径。这必须是绝对路径。 -
DEPLOYMENT_NAME 是您要为其创建扩展节点的部署名称。 -
gcp_instance_group_name是要为扩展节点创建的 GCP 实例组的名称。 -
gcp_instance_template_name是要创建的 GCP 实例模板的名称。 -
gcp_compute_region是部署基础部署的 GCP 区域。这可以通过检查 Deployment Manager 中的 Deployments 配置来检索。
4.4. 运行 ansible-on-clouds-ops 容器以删除扩展节点
流程
要删除一组扩展节点,请运行命令生成器来生成 CLI 命令。
$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator --data-file /data/extra_vars.yml
命令生成器输出提供以下命令:
d----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> \ --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_remove_extension_nodes \ -e 'gcp_deployment_name=<deployment_name> gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_compute_region=<region> gcp_instance_template_name=<instance_template_name> \ gcp_instance_group_name=<instance_group_name>' ===============================================
运行提供的命令以删除一组扩展节点。
$ docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> \ --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_remove_extension_nodes \ -e 'gcp_deployment_name=<deployment_name> gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_compute_region=<region> gcp_instance_template_name=<instance_template_name> \ gcp_instance_group_name=<instance_group_name>'
如果没有错误,扩展节点会被成功删除。
第 5 章 网络和应用程序访问
当部署了来自 GCP Marketplace 的 Ansible Automation Platform 时,它会被安装到隔离的 VPC 中,且无法访问。以下说明描述了如何将 Ansible Automation Platform 从 GCP Marketplace 使用的 VPC 连接到现有的 GCP 网络。连接后,您必须确定您的用户如何连接到 Ansible Automation Platform。
有多种方法可以启用此连接,如 VPN、Google Cloud Interconnect 或 bastion 服务器进行私有网络访问。您还可以使用 GCP 服务(如 Load Balancer)公开具有公共互联网访问的平台。
您的机构如何配置 GCP 上的应用程序访问权限,超出了红帽指南的范围,并从 GCP Marketplace 对 Ansible Automation Platform 的支持。如需更多信息,请参阅 安全地连接到虚拟机 以获取有关这些主题的指南。
5.1. 网络选项
GCP Marketplace 的 Ansible Automation Platform 的网络拓扑包括几个可配置的网络片段,可更改为符合您机构的网络要求。
部署会创建一个新的 VPC 和子网,这些子网无法从公共互联网访问,或使用现有的 VPC 网络。您必须提供对应用程序的访问权限,如网络和应用程序访问中所述。
在指定以下网络范围时,请考虑您的现有网络配置。确保每个范围不与此处指定的任何其他范围重叠,且不会与您网络中的现有范围重叠。每个范围都应该存在于私有网络类中。
应用程序子网范围
定义由产品部署的自定义 VPC 使用的子网范围的网络 CIDR。必须至少为 /24 段,且必须位于专用网络范围(192.168 或 10.0)。
默认:192.168.240.0/24
Cloud SQL Peering Network Range
网络 CIDR 定义用于将 GCP CloudSQL 网络与产品部署的应用程序子网进行对等的网络段。必须是一个 /24 段。/24 段范围是 GCP CloudSQL 网络对等配置的要求。
默认值:192.168.241.0/24
FileStore Peering Network Range
GCP Marketplace 的 Ansible Automation Platform 使用 GCP Filestore 服务在多个自动化控制器和自动化中心虚拟机间共享配置文件。此网络 CIDR 范围定义产品用于 GCP Filestore 网络与产品的自定义 VPC 应用程序子网之间的对等网络。必须至少为 /29 段。
默认值:192.168.243.0/29
Load Balancer 代理子网范围
GCP Marketplace 中的 Ansible Automation Platform 使用 GCP 的原生云功能进行部署,以提供可扩展且可靠的安装。作为 GCP Marketplace 部署拓扑中的 Ansible Automation Platform 的一部分,在自动化中心和自动化控制器虚拟机前部署两个负载均衡器。所有流量都定向到这些负载均衡器,并代理到可用的后端虚拟机。部署利用 GCP 的原生负载平衡支持,使客户能够向负载均衡器添加额外的端口(https),将请求捕获并转发到后端虚拟机。这还提供请求平衡和会话跟踪,以提高可靠性。作为负载均衡器部署的一部分,GCP 需要创建一个特殊的代理网络,其中 GCP 原生处理请求重定向到后端虚拟机的重定向。对于 GCP 负载均衡器的代理网络以外的其他目的,从 GCP Marketplace 中使用这个特殊代理网络网络。需要 /24 个片段。
默认:192.168.242.0/24
Controller Internal Load Balancer IP 地址
这是分配给自动化控制器 Load Balancer 的静态 IP 地址。此地址必须在应用子网范围段内。
默认:192.168.240.20
hub Internal Load Balancer IP 地址
这是分配给自动化中心 Load Balancer 的静态 IP 地址。此地址必须在应用子网范围段内。
默认:192.168.240.21
5.2. 网络对等选项
许多网络配置可以访问平台,但已验证了以下配置以使用来自 GCP Marketplace 的 Ansible Automation Platform。
虽然一切都是为了与 Google Cloud Platform 文档中的内容保持一致,但随着时间的推移的准确性可能会有偏差。使用 GCP 文档 作为 GCP 网络主题的信息源。
5.3. VPC 对等
Ansible Automation Platform 需要 VPC Peering 来访问位于私有 VPC 上的资源,或者在 Google Cloud Platform 和您的内部网络间的传输路由。它能够在 GCP 基础架构中直接连接不同的网络。VPC 单独连接到另一个,它们之间没有其他路由跃点。VPC 部署默认从公共互联网访问。
这也是从 GCP Marketplace 中 Ansible Automation Platform 使用的 GCP 架构的部署模型。
这是一个简单的对等模型,在连接多个网络时非常有用。
可以配置复杂的对等功能,但随着时间推移,路由可能会变得更加复杂。
当配置了 VPC 对等和路由时,您可以通过连接的 VPC 子网上的虚拟机访问 Ansible Automation Platform,或者如果您的机构在 GCP 和本地网络间传输路由设置,您可以直接访问 Ansible Automation Platform。
当两个或更多个网络被对等时,Google 会执行自动操作 来帮助路由,但可以执行可路由的更新,以启用 GCP 基础架构内的流量流。
先决条件
在使用 VPC 对等连接任何 VPC 之前,您必须确保您要在 VPC 和 GCP Marketplace 的 VPC 地址空间空间之间没有网络地址空间重叠。如果尝试此操作,GCP 门户应该会阻止对等。
使用 Ansible Automation Platform 配置 VPC 对等过程。
流程
- 在 GCP Portal 中,进入到 VPC Network。
- 在 VPC 菜单中,选择 VPC Network Peering。
- 点 Create peering connection。
- 单击 CONTINUE。
- 在 Name 字段中输入您需要的对等连接的名称。
- 在 VPC Network 字段中,选择第一个您要对等的 VPC。
在 Peered VPC Network 字段中,选择第二个 VPC 到 peer。这必须是来自 GCP Marketplace VPC 的 Ansible Automation Platform。
- 默认情况下,这两个网络之间的子网路由创建。因此,对 Ansible Automation Platform 的访问可能会来自位于对等 VPC 上的虚拟机。但是,如果您有更复杂的路由,如 hub 和spoke 网络模型,则必须创建其他路由。
- 仔细选择 Exchange custom routes and Exchange subnet route with public IP。Google 提供了对每个字段的作用的解释。您的选择会影响流量通过 VPC 的流处理方式。通常,这些复选框通过路由表交换配置新对等网络与其他网络之间的路由,并使网络流量能够遍历多个网络(转换路由)。
- 点 Create。
如需有关 VPC Peering 的路由表、防火墙和其他网络组件的更多信息,请参阅 GCP 文档。
5.4. 使用外部负载均衡器
如果您希望用户可从任何互联网连接的机器访问平台,可以将 Ansible 自动化控制器和 Ansible 私有自动化中心公开给公共互联网。
不建议作为安全原因的最佳实践。
但是,这个实现可以使用不同的 GCP 工具进行保护。这部分论述了如何连接面临公共互联网的负载均衡器,但不包括通过 Google 安全产品强化访问的步骤。只有当您打算使用 Google Cloud Armor 或类似产品保护公共端点时,才使用此方法。
GCP Marketplace 中的 Ansible Automation Platform 使用两个 内部应用程序 负载均衡器进行部署。这些负载均衡器在本地 VPC 中直接流量,且必须保持部署的一部分,即使您配置了公共负载均衡器。
流程
- 从左上角的主菜单。
- 选择 Network Services。如果没有看到 Network Services,请选择 View All Products。
- 选择 Load Balancing。
- 在顶部菜单中,选择 CREATE LOAD BALANCER。
- 选择 Application Load Balancer (HTTP/S) 标题,再单击 START CONFIGURATION。
- 选择 From Internet to my VMs or serverless services and Global external Application Load Balancer。
- 单击 CONTINUE。
-
为您的负载均衡器指定一个名称,例如 <
DeploymentName>-aap-<cntrlr/hub>-ext-lb - 确保屏幕左侧选择了 Frontend 配置。
在 Frontend 配置页面中,完成以下字段:
- 协议 :HTTPS。
- 端口 :443.
- IP 地址 :选择现有的 IP 地址或创建新地址。
- 证书 :您可以使用自己的 SSL 证书或使用 Google 受管证书。
SSL 策略 :GCP 默认或其他配置策略。
注意如需更多信息,请参阅 SSL 证书
- 单击 DONE。
- 从左侧的菜单中选择 Backend configuration。
- 点 Backend services & backend bucket 下拉菜单。
单击 CREATE A BACKEND SERVICE。
-
为您的后端服务命名,例如 <
DeploymentName>-aap-<cntrlr/hub>-ext-lb-bknd-svc - 将 Backend 类型设置为 Instance group。
-
将 Protocol 设置为
HTTPS,并将指定 端口设为https。 -
将 Timeout 更改为
86400。 向下滚动到 Backends 部分,然后在 New backend 字段中选择 Instance group 下拉菜单。选择正确的实例组。
对于自动化控制器负载均衡器,正确的实例组后缀
-aap-cntrlr-igm。对于自动化中心负载均衡器,正确的实例组后缀
-aap-hub-igm。- 在生成的对话框中,选择 USE EXISTING PORT NAME。
- 将 Balancing 模式设置为 Rate。
- 将最大 RPS 设置为 300。
- 向下滚动,直到您看到 Cloud CDN。取消选择 云 CDN 的复选框。
- 向下滚动,直到您看到一个显示 Health 复选框 的文本框。
- 选择下拉菜单,再单击 CREATE A HEALTH CHECK。
-
为您的健康检查输入一个名称,例如,<
DeploymentName>-aap-<cntrlr/hub>-ext-lb-hc 对于自动化控制器,请使用以下健康检查设置
-
在 Health Check 对话框中,将 Protocol 设置为
HTTPS,并将 端口设为8052。 -
将 Request 设置为
/api/v2/ping/。
-
在 Health Check 对话框中,将 Protocol 设置为
对于自动化中心,请使用以下健康检查设置
-
在 Health Check 对话框中,将 Protocol 设置为
HTTPS,并将端口设为8080。 -
将 Request 设置为
/api/galaxy/pulp/api/v3/status/。
-
在 Health Check 对话框中,将 Protocol 设置为
- 向下滚动到 Health criteria 部分。
- 在 Check interval 字段中,输入值 15。
- 在 Timeout 字段中,输入值 10。
- 在 Healthy threshold 字段中,输入值 2。
- 在 Unhealthy 阈值 字段中,输入值 10。
单击 SAVE。
这会返回到后端服务和后端存储桶窗口。
单击 CREATE。
这会将您返回到 Backend 配置部分。
- 点击 OK。
- 点 CREATE 为自动化控制器或自动化中心 UI 创建负载均衡器。完成此过程需要几分钟时间。
-
为您的后端服务命名,例如 <
- 现在创建了一个负载均衡器。
- 配置您在 SSL 证书中使用的域的 DNS 记录,以指向负载均衡器的 IP 地址。
此时,您应该有权访问 Ansible Automation Platform 自动化控制器 UI。您可以在检索管理密码后登录。
对私有自动化中心重复相同的过程。此过程相同,除了在后端配置过程中选择实例组 -aap-hub-igm。
第 6 章 其他配置
以下章节描述了在 GCP 上部署后您可以执行 Ansible Automation Platform 配置步骤。
6.1. 更改默认管理员密码
当部署了来自 GCP Marketplace 的 Ansible Automation Platform 时,Ansible Automation Platform 的默认管理员密码会被随机生成。按照以下步骤更改自动化控制器和自动化中心的管理员密码。
流程
进入 GCP Secrets Manager 控制台。
-
使用名称 <
deployment_name> -aap-admin来查找并打开 Ansible Automation Platform 部署的 secret。 - 选择 NEW VERSION 以添加新版本。
- 输入密码 secret 值。
- 选中 禁用所有过去版本 复选框。
- 单击 ADD NEW VERSION。
-
使用名称 <
更改正在运行的 Ansible Automation Platform 虚拟机实例以使用新的管理员密码。
- 进入 GCP VM Instances 控制台。
- 识别并删除一个自动化控制器虚拟机实例,并为 Ansible Automation Platform 部署有一个自动化中心虚拟机实例。
- 等待自动化控制器和自动化中心实例组创建新的虚拟机实例。
- 当新的自动化控制器和自动化中心虚拟机实例到达 Running Instance State 时,可以使用新的管理员密码。
6.2. 替换自动化控制器和自动化中心虚拟机实例 SSL/TLS 证书和密钥
默认情况下,虚拟机实例使用自签名 SSL/TLS 证书进行保护,其有效期为 10 年。当证书过期或希望虚拟机实例使用自己的证书时,您需要替换 SSL/TLS 证书和密钥。
流程
进入 GCP Secrets Manager 控制台。
-
使用名称 <deployment_name>
-pulp_cert 查找并打开 Ansible Automation Platform 部署的secret。 - 选择 NEW VERSION 以添加新版本。
- 输入新的 SSL/TLS 证书值。
- 选中 禁用所有过去版本 复选框。
- 单击 ADD NEW VERSION。
-
使用名称 <deployment_name>
进入 GCP Secrets Manager 控制台。
-
使用名称 <deployment_name>
-pulp_key 来查找并打开 Ansible Automation Platform 部署的 secret。 - 选择 NEW VERSION 以添加新版本。
- 输入新的 SSL/TLS 密钥值。
- 选中 禁用所有过去版本 复选框。
- 单击 ADD NEW VERSION。
-
使用名称 <deployment_name>
更改正在运行的 Ansible Automation Platform 虚拟机实例以使用新的 SSL/TLS 证书和密钥。
- 进入 GCP VM Instances 控制台。
- 为 Ansible Automation Platform 部署识别并删除所有自动化控制器和自动化中心虚拟机实例。
- 等待自动化控制器和自动化中心实例组创建新的虚拟机实例。
- 当新的自动化控制器和自动化中心虚拟机实例到达 Running 实例时,会使用新证书。
6.3. 使用 SSL 保护内部通信
GCP Marketplace 中的 Ansible Automation Platform 部署有两个 内部应用程序 负载均衡器,各自在 hub 和控制器实例前面。这些内部负载均衡器必须在部署完成后使用 SSL 证书进行配置。
通过这些内部负载均衡器保护流量与在前面的步骤中通过外部负载均衡器保护流量不同。此过程可确保 HTTP 流量被加密,即使流量被本地化为私有 GCP VPC。对于自动化控制器和自动化中心负载均衡器,可以遵循相同的步骤。
要修改自动化控制器和自动化中心负载均衡器,其名称格式为 < DEPLOYMENT_NAME>-aap-<cntrlr/hub>-int-lb。
流程
使用以下命令生成自动化控制器或自动化中心证书:
$ openssl req -x509 -nodes -newkey rsa:2048 -keyout key.pem -out cert.pem -sha256 -days 365
- 在 GCP 控制台中,进入 Load Balancing 页面。
- 在搜索栏中输入部署的名称,以过滤到负载均衡器。
-
点 &
lt;DEPLOYMENT_NAME>-aap-<cntrlr/hub>-int-lb。 - 点 Edit。
- 单击 Frontend 配置。
单击 ADD FRONTEND IP 和 PORT。使用以下值:
- 协议 :HTTPS (包括 HTTP/2)
- 子网: 选择可用的 aap-subnet。
- 端口: 443
-
IP 地址 :&
lt;DEPLOYMENT_NAME>-aap<cntrlr/hub>-intl-lb-ip
如果您已经添加了证书,请选择它。
- 如果您还没有添加证书,请单击 CREATE A NEW CERTIFICATE。
- 为您的证书提供名称。
-
使用之前生成的证书,复制
cert.pem内容并将其粘贴到 证书 下。 -
使用之前生成的证书密钥,复制
key.pem内容并将其粘贴到 私钥 下。 - 点 Create。
- 点 Done。
可选:删除 HTTP Frontend 配置。
- 打开 Load balancer 实例。
- 单击 Frontend Configuration,配置会出现在 UI 左侧的配置。
- 滚动到您要删除的配置。
- 点 trashcan 图标删除配置。
- 单击 Update,并确认更新。
6.4. 安全考虑
要使用可启用 多因素身份验证 (MFA)的身份提供程序配置 Red Hat Single Sign-On,请按照以下步骤 将企业 身份验证连接到 Ansible Automation Platform。
保护基础架构服务对于任何云部署都至关重要。对于用作 GCP Marketplace 部署的一部分的服务,请参阅 GCP 文档中的 实施和安全建议。
第 7 章 命令生成器
命令生成器用于生成启动由 Ansible-on-clouds 操作 playbook 集合提供的操作 playbook 的命令。
这个过程涉及五个步骤:
-
拉取
ansible-on-clouds-ops容器镜像。 - 列出可用的 playbook。
-
使用命令生成器生成数据文件以及要运行的下一个命令。
command_generator_vars和 command_generator 使用 docker 容器实施,并且使用 docker 命令行界面运行。 填充数据文件并运行上一个生成的命令。这会生成含有所有参数的最后一个命令。
注意完成此步骤后,您可以保存生成的命令,并在需要时运行 playbook。
- 运行最终命令。
先决条件
- Docker
- GCP 凭证文件
- 与 Google Cloud 的互联网连接
7.1. 拉取 ansible-on-clouds-ops 容器镜像
使用与部署相同的标签版本,在云操作容器上拉取 Ansible 的 Docker 镜像。
在提取 docker 镜像前,请确保使用 docker 登录到 registry.redhat.io。使用以下命令登录到 registry.redhat.io。
$ docker login registry.redhat.io
有关 registry 登录的更多信息,请参阅 Registry 身份验证
例如,如果您的基础部署版本是 2.4.20230630-00,则必须使用标签 2.4.20230630 拉取操作镜像。
使用以下命令:
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
7.2. 列出可用的 playbook
流程
如需没有详细信息的可用 playbook 列表,请使用以下命令:
$ docker run --rm $IMAGE command_generator_vars | grep Playbook The current version of the operational playbooks collection contains the following playbooks: Playbook: aws_add_extension_nodes Playbook: aws_add_labels Playbook: aws_backup_delete Playbook: aws_backup_stack Playbook: aws_backups_delete Playbook: aws_check_aoc_version Playbook: aws_deployment_inventory Playbook: aws_get_aoc_version Playbook: aws_remove_extension_nodes Playbook: aws_remove_labels Playbook: aws_restore_stack Playbook: aws_upgrade Playbook: gcp_aap_health_check Playbook: gcp_add_extension_nodes Playbook: gcp_add_labels Playbook: gcp_backup_delete Playbook: gcp_backup_deployment Playbook: gcp_backup_list Playbook: gcp_backups_delete Playbook: gcp_check_aoc_version Playbook: gcp_deployment_inventory Playbook: gcp_get_aoc_version Playbook: gcp_health_check Playbook: gcp_list_deployments Playbook: gcp_nodes_health_check Playbook: gcp_remove_extension_nodes Playbook: gcp_remove_labels Playbook: gcp_restore_deployment Playbook: gcp_setup_logging_monitoring Playbook: gcp_upgrade
若要提供所有可用 playbook 的列表并使用命令生成器,可使用以下命令:
$ docker run --rm $IMAGE command_generator_vars
这提供了 playbook 列表和类似如下的命令:
=============================================== Playbook: gcp_upgrade Description: Performs the upgrade of the Ansible Automation Platform from GCP Marketplace components to the latest version. ----------------------------------------------- Performs the upgrade of the Ansible Automation Platform from GCP Marketplace components to the latest version. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_upgrade [--ansible-config ansible_config_path>] \ -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone> gcp_backup_taken=<true|false>' ===============================================
7.3. 生成数据文件
流程
运行命令生成器。
$ docker run --rm -v <local_directory_data_file>:/data $IMAGE command_generator_vars <playbook_name> --output-data-file /data/<data-file>.yml
此命令的输出是要运行的命令和数据文件模板。数据文件也保存在
<local_data_file_directory>中。这是您填充数据的模板。以下示例使用
gcp_backup_deploymentplaybook。$ docker run --rm -v <local_data_file_directory>:/data $IMAGE command_generator_vars gcp_backup_deployment \ --output-data-file /data/backup.yml
生成以下输出:
=============================================== Playbook: gcp_backup_deployment Description: This playbook is used to backup the AoC Self-managed GCP environment. ----------------------------------------------- This playbook is used to backup the AoC Self-managed GCP environment. For more information regarding backup and restore, visit our official documentation - ----------------------------------------------- Command generator template: docker run --rm -v /tmp:/data $IMAGE command_generator gcp_backup_deployment --data-file /data/backup.yml Data template: gcp_backup_deployment: cloud_credentials_path: deployment_name: extra_vars: gcp_bucket_backup_name: gcp_compute_region: gcp_compute_zone: ===============================================
7.4. 填充数据文件
流程
编辑生成数据文件过程中生成的数据文件。
代表路径的任何属性都必须是绝对路径。
command_generator在最终命令中自动挂载卷。例如,在
gcp_backup_deploymentplaybook 时,该文件将变为:gcp_backup_deployment cloud_credentials_path: /path/to/credentials deployment_name: my-deployment extra_vars: cp_bucket_backup_name: my-bucket gcp_compute_region: us-east1 gcp_compute_zone: us-east1-b
7.5. 运行生成的命令
流程
确保挂载的卷指向数据文件的目录。
对于
gcp_backup_deploymentplaybook 示例,这是:$ docker run --rm -v /tmp:/data $IMAGE command_generator gcp_backup_deployment --data-file /data/backup.yml
生成以下输出:
Command to run playbook: $ docker run --rm --env PLATFORM=GCP -v /path/to/credentials:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg $IMAGE\ redhat.ansible_on_clouds.gcp_backup_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=my-deployment gcp_compute_region=us-east1 gcp_compute_zone=us-east1-b'
此新命令具有所需的参数、环境变量和已挂载的卷,以运行 playbook。
- 运行生成的命令。如果需要,您可以保存这个命令来稍后重新运行该命令。
7.6. 使用 playbook
本文档中描述了一些,但不是所有 playbook。在这里,用于从云部署上的 Ansible 检索信息或检查信息的用户已描述。这些 playbook 不修改部署。
gcp_aap_health_check
此 playbook 检查 Ansible 应用是否健康。
$ docker run --rm $IMAGE command_generator_vars gcp_aap_health_check
生成以下输出:
=============================================== Playbook: gcp_aap_health_check Description: This playbook checks if the deployment is healthy using the Ansible health service. ----------------------------------------------- The health check consists of checking the Ansible Automation Platform from GCP Marketplace environemnt to verify it is healthy. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_aap_health_check [--ansible-config ansible_config_path>] -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone>' ===============================================
通过替换参数启动这个命令会生成新命令来启动和输出:
... PLAY RECAP ********************************************************************* localhost : ok=29 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
故障 不等于零表示在云部署上 Ansible 存在问题。
gcp_add_labels
此 playbook 为部署添加标签。
$ docker run --rm $IMAGE command_generator_vars gcp_add_labels
生成以下输出:
=============================================== Playbook: gcp_add_labels Description: This playbook adds labels to the deployment. ----------------------------------------------- Add labels to the Ansible Automation Platform from GCP Marketplace deployment. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_add_labels -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone> gcp_labels=<gcp_labels>' ===============================================
参数 gcp_labels 是以逗号分隔的 key=value 对列表,用于添加或更新。例如: key1=value1,key2=value2
通过替换参数启动这个命令会生成新命令来启动和输出:
... PLAY RECAP ********************************************************************* localhost : ok=22 changed=2 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
gcp_remove_labels
此 playbook 从部署中删除标签。
$ docker run --rm $IMAGE command_generator_vars gcp_remove_labels
生成以下输出:
=============================================== Playbook: gcp_remove_labels Description: This playbook removes labels from the deployment. ----------------------------------------------- Remove labels from the Ansible Automation Platform from GCP Marketplace deployment. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_remove_labels -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone> gcp_labels=<gcp_labels>' ===============================================
参数 gcp_labels 是以逗号分隔的键列表。例如: key1,key2
通过替换参数启动这个命令会生成新命令来启动和输出:
... PLAY RECAP ********************************************************************* localhost : ok=22 changed=2 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
gcp_check_aoc_version
此 playbook 检查云版本的 Ansible 是否与命令生成器容器相同。每次调用 playbook 时都会进行检查。
$ docker run --rm $IMAGE command_generator_vars gcp_check_aoc_version
生成以下输出:
=============================================== Playbook: gcp_check_aoc_version Description: Check the operational container version matches the Ansible on Clouds version. ----------------------------------------------- Check the operational container version matches the Ansible on Clouds version. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_check_aoc_version [--ansible-config ansible_config_path>] -c <cloud_credentials_path> -d <deployment_name> ===============================================
通过替换参数启动这个命令会生成新命令来启动和输出:
...
TASK [redhat.ansible_on_clouds.standalone_check_aoc_version : Verify operational playbook and Ansible on Clouds deployment versions] ***
ok: [localhost] => {
"changed": false,
"msg": "This operation playbook version and the Ansible on Clouds deployment version are identical: 2.4.20230606-00"
}
PLAY RECAP *********************************************************************
localhost : ok=8 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
失败 为零表示 Clouds 部署版本的 Ansible 与 command_generator 容器不匹配,而命令生成器需要不同的版本来管理该部署。
gcp_get_aoc_version
此 playbook 在云部署中检索 Ansible 的版本。
$ docker run --rm $IMAGE command_generator_vars gcp_get_aoc_version
生成以下输出:
=============================================== Playbook: gcp_get_aoc_version Description: Get the current Ansible on Clouds version. ----------------------------------------------- Get the current Ansible on Clouds version. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_get_aoc_version [--ansible-config ansible_config_path>] -c <cloud_credentials_path> -d <deployment_name> ===============================================
通过替换参数启动这个命令会生成新命令来启动和输出:
...
TASK [Print version] ***********************************************************
ok: [localhost] => {
"msg": "The AOC version is 2.4.20230606-00"
}
PLAY RECAP *********************************************************************
localhost : ok=5 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0gcp_health_check
此 playbook 检查节点和 Ansible 应用是否健康。
$ docker run --rm $IMAGE command_generator_vars gcp_health_check
生成以下输出:
=============================================== Playbook: gcp_health_check Description: This playbook checks if the Ansible Automation Platform from GCP Marketplace deployment is healthy. ----------------------------------------------- The health check consists of checking the Ansible Automation Platform from GCP Marketplace heatlh checks and the health of the monitoring exporter. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_health_check [--ansible-config ansible_config_path>] -c <cloud_credentials_path> -d <deployment_name> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone>' ===============================================
通过替换参数启动此命令将生成新命令以启动并将输出:
... PLAY RECAP ********************************************************************* localhost : ok=47 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
故障 不等于零表示节点或云部署上的 Ansible 存在问题。
gcp_list_deployments
此 playbook 列出部署,地区和区域是可选的。
$ docker run --rm $IMAGE command_generator_vars gcp_list_deployments
生成以下输出:
=============================================== Playbook: gcp_list_deployments Description: This playbook generates a list of available Ansible Automation Platform from GCP Marketplace deployments. ----------------------------------------------- This playbook is used to generate a list of available Ansible Automation Platform from GCP Marketplace deployments. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_list_deployments -c <cloud_credentials_path> --extra-vars '[gcp_compute_region=<gcp_compute_region>] [gcp_compute_zone=<gcp_compute_zone>]' ===============================================
通过替换参数启动这个命令会生成新命令来启动和输出:
...
TASK [Show deployment list] ****************************************************
ok: [localhost] => {
"msg": [
"Deployment list: ['dep1', 'dep2', 'dep3']"
]
}
PLAY RECAP *********************************************************************
localhost : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0gcp_nodes_health_check
此 playbook 检查节点是否健康。
$ docker run --rm $IMAGE command_generator_vars gcp_nodes_health_check
生成以下输出:
=============================================== Playbook: gcp_nodes_health_check Description: This role runs a health check on a group of nodes in the Ansible Automation Platform from GCP Marketplace deployment ----------------------------------------------- The playbook checks if the Ansible Automation Platform from GCP Marketplace monitoring exporter is up and running. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_nodes_health_check [--ansible-config ansible_config_path>] -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'check_monitoring=True' ===============================================
通过替换参数启动这个命令会生成新命令来启动和输出:
... PLAY RECAP ********************************************************************* localhost : ok=47 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
故障 不等于零表示部署中的节点存在问题。
第 8 章 自动化工作负载
GCP Marketplace 的默认 Ansible Automation Platform 被设计为自动化 100 个受管节点。
8.1. 自动化性能
根据您提供的许可证受管节点分配的自动化,提供以下操作预期:不支持在这些标准边界外实现自动化,但仍可根据您的自动化功能。
| 指标 | threshold |
|---|---|
| 并发作业 | 10 |
| 每个作业的 fork | 10 |
GCP Marketplace 中的 Ansible Automation Platform 使用三个 n2-standard-2 实例驱动,其中两个运行自动化控制器和一个运行自动化中心。自动化控制器实例统一支持 100 个托管活跃节点的标准工作负载。红帽已测试过这一点并证明,每个分叉最多有 10 个分叉支持。这个操作标准已使用输出密集型、"chatty" 工作负载进行设置和测试,它在两个自动化控制器节点上生成 2 个信息,它们彼此相隔 7 秒。负载较高 I/O 密集型工作负载可能无法在这些条件范围内工作,且可能需要使用扩展节点来扩展部署来支持这样的自动化。
8.2. 部署扩展
如果要在支持的受管节点的初始数量之外扩展部署,可以使用单独销售的扩展节点手动扩展来自 GCP Marketplace 的 Ansible Automation Platform。
扩展节点是可以部署以扩展或横向扩展的额外计算实例,具体取决于即时扩展要求。如果您的要求较高并行自动化操作,您可以选择计算形成扩展,而如果您有需要随着时间的推移自动执行更多节点,则可以选择计算形成扩展的计算。
扩展节点是从 GCP Marketplace 扩展 Ansible Automation Platform 的功能支持的方法。
红帽不支持通过客户设计和实施扩展的环境。
第 9 章 监控和日志记录
您可以将指标发送到 Google Cloud Platform 监控系统,以便在 Google Cloud Platform UI 中视觉化。默认情况下,来自 GCP Marketplace 指标和日志记录的 Ansible Automation Platform 会被禁用,因为将这些指标发送到 GCP 的成本。如需更多信息,请参阅云监控和云日志记录。
您可以设置 GCP 监控和日志记录:
- 在部署时,在部署时读取设置监控和日志记录,或者
- 部署后
9.1. 部署后设置监控和日志记录
您可以使用 registry.redhat.com 提供的 gcp_setup_logging_monitoring playbook 在部署后启动或停止日志和监控。
9.1.1. 所需权限
您必须具有以下 GCP IAM 权限来设置日志记录和监控:
required-roles: Service Account User Compute Instance Admin (v1) required-permissions: cloudsql.instances.connect cloudsql.instances.get cloudsql.instances.login cloudsql.users.update compute.addresses.get compute.addresses.list compute.instances.delete compute.instances.get compute.instances.list compute.instances.setLabels compute.zoneOperations.get deploymentmanager.deployments.list deploymentmanager.manifests.get deploymentmanager.manifests.list file.instances.get file.instances.list file.instances.update file.operations.get iap.tunnelInstances.accessViaIAP logging.logEntries.create monitoring.timeSeries.create resourcemanager.projects.get runtimeconfig.variables.create runtimeconfig.variables.get runtimeconfig.variables.list runtimeconfig.variables.update secretmanager.secrets.create secretmanager.secrets.delete secretmanager.secrets.get secretmanager.versions.add secretmanager.versions.get secretmanager.versions.list servicenetworking.operations.get servicenetworking.services.addPeering serviceusage.services.list
9.1.2. 拉取 ansible-on-clouds-ops 容器镜像
在云操作容器上拉取 Ansible 的 Docker 镜像,与基础部署的版本保持一致。
在拉取 docker 镜像前,请确保使用 docker 登录到 registry.redhat.io。使用以下命令登录到 registry.redhat.io。
$ docker login registry.redhat.io
有关 registry 登录的更多信息,请参阅 Registry 身份验证
例如,如果您的基础部署版本是 2.4.20230630-00,则必须使用标签 2.4.20230630 拉取操作镜像。
使用以下命令:
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
9.1.3. 运行 ansible-on-clouds-ops 容器来生成数据文件
以下命令生成所需的数据文件。这些命令会创建一个目录,并使用填充时的空数据模板来生成 playbook。
流程
创建用于存放配置文件的文件夹。
$ mkdir command_generator_data
使用配置文件模板填充
command_generator_data文件夹。注意在 Linux 上,命令生成器创建的任何文件或目录默认归
root:root所有。要更改文件和目录的所有权,您可以在创建文件后运行sudo chmod命令。如需更多信息,请阅读 命令生成器 - 由 root 拥有的 Linux 文件。$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE \ command_generator_vars gcp_setup_logging_monitoring \ --output-data-file /data/logging-monitoring.yml
运行这些命令时,会创建一个
command_generator_data/logging-monitoring.yml模板文件。注意在以下示例中,
ansible_config_path是可选的。此模板文件类似于以下内容:-
gcp_setup_logging_monitoring: ansible_config_path: cloud_credentials_path: deployment_name: extra_vars: components: default_collector_interval: logging_enabled: monitoring_enabled:
9.1.4. 更新数据文件
如果不需要参数,请从配置文件中删除该参数。
流程
-
编辑
command_generator_data/logging-monitoring.yml文件并设置以下参数: -
ansible_config_path默认用作ansible-on-cloud 产品的标准配置,但如果您的环境中有额外的要求,则可以自行指定。 -
cloud_credentials_path是您的凭证的绝对路径。这必须是绝对路径。 -
deployment_name是部署的名称。 -
组件(可选)您要在其上执行设置的组件类型。默认为 [ "controller", "hub" ],这意味着在自动化控制器和自动化中心上都启用了日志记录监控。 -
monitoring_enabled(可选)设置为true以启用监控,否则为false。默认为false。 -
logging_enabled(可选)设置为true以启用日志记录,否则为false。默认为false。 default_collector_interval(可选)是监控数据必须发送到 Google Cloud 的频率。默认为 59s。注意此服务的 Google 成本取决于该定期性,因此收集器间隔的值越高,其成本越低。
不要设置小于 59 秒的值。
注意如果禁用了监控和日志记录,则 'default_collector_interval' 的值会自动设置为
0。
填充数据文件后,它应类似于以下内容:
以下示例提供了以下值:
本节中描述的可选参数在下面的数据文件示例中被忽略。playbook 使用从数据文件忽略的任何可选参数的默认值。如果要覆盖可选参数的默认值,则必须将其包含在数据文件中并分配一个值。
gcp_setup_logging_monitoring: cloud_credentials_path: ~/secrets/GCP-secrets.json deployment_name: AnsibleAutomationPlatform extra_vars:
9.1.5. 生成 playbook
若要生成 playbook,请运行命令生成器来生成 CLI 命令。
docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_setup_logging_monitoring \ --data-file /data/logging-monitoring.yml
提供以下命令:
docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> --env GENERATE_INVENTORY=true \ $IMAGE redhat.ansible_on_clouds.gcp_setup_logging_monitoring -e 'gcp_deployment_name=<deployment_name> \ gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials monitoring_enabled=<monitoring_enabled> \ logging_enabled=<logging_enabled> default_collector_interval=<interval>'
运行提供的命令以运行 playbook。
$ docker run --rm --env PLATFORM=GCP -v /path/to/credentials:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=mu-deployment \ --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_setup_logging_monitoring \ -e 'gcp_deployment_name=mu-deployment \ gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials components=["hubs","controllers"]\ monitoring_enabled=True logging_enabled=True default_collector_interval=60s'
此过程可能需要一些时间,并提供类似如下的输出:
TASK [redhat.ansible_on_clouds.setup_logging_monitoring : Update runtime variable logging_enabled] *** changed: [<user_name> -> localhost] TASK [redhat.ansible_on_clouds.setup_logging_monitoring : Update runtime variable monitoring_enabled] *** changed: [<user_name> -> localhost] PLAY RECAP ********************************************************************* <user_name> : ok=20 changed=6 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
9.2. 自定义监控和日志记录
指标由 Ansible、Podman 和 Google Ops 代理提供。Google Ops Agent 和 Podman 安装在自动化控制器和自动化中心虚拟机实例上,但 Ansible 指标仅安装在自动化中心实例上。
一个可配置的进程(collector)在每个自动化控制器虚拟机实例和自动化中心虚拟机实例上运行,将收集的 Ansible 和 Podman 指标导出到 Google Cloud Platform 监控。由于 Google Ops Agent 是 Google Cloud 解决方案的一部分,它拥有自己的配置文件。
Google Ops Agent 还负责日志配置。
为监控和日志记录功能分别启用服务 API monitoring.googleapis.com 和 logging.googleapis.com。
配置
配置文件位于每个自动化控制器和自动化中心共享的磁盘上。修改文件 /aap/bootstrap/config_file_templates/<controller|hub>/monitoring.yml,以配置所有导出器和代理。
9.2.1. Ansible 和 podman 配置
自动化控制器或自动化中心上的 /aap/bootstrap/config_file_templates/<controller|hub>/monitoring.yaml 文件包含收集 Ansible 和 podman 指标到 GCP 的配置。
自动化控制器的默认配置如下:
# This value will be set at deployment time. # Set to zero if monitoringEnabled is false otherwise 59s # The collection interval for each collector will be the minimum # between the defaultCollectorInterval and all send Interval # of a given collector # NB: The awx exported should not run on controllers as # it duplicates the number of records sent to GCP Monitoring defaultCollectorInterval: $DEFAULT_COLLECTOR_INTERVAL collectors: - name: podman endpoint: http://localhost:9882/podman/metrics enabled: true # list of metrics to exclude # excludedMetrics: # - podman_container_created_seconds metrics: - name: podman_container_exit_code # interval on which the metric must be pushed to gcp sendInterval: 59s
Automation hub 的默认配置如下:
# This value will be set at deployment time. # Set to zero if monitoringEnabled is false otherwise 59s # The collection interval for each collector will be the minimum # between the defaultCollectorInterval and all sendInterval # of a given collector # NB: The awx exporter should not run on controllers as # it duplicates the number of records sent to GCP Monitoring defaultCollectorInterval: 59s collectors: - name: awx userName: admin endpoint: http://<Controller_LB_IP>/api/v2/metrics/ enabled: true metrics: - name: awx_inventories_total # interval on which the metric must be pushed to gcp sendInterval: 59s - name: podman endpoint: http://localhost:9882/podman/metrics enabled: true # list of metrics to exclude # excludedMetrics: # - podman_container_created_seconds metrics: - name: podman_container_exit_code # interval on which the metric must be pushed to gcp sendInterval: 59s
其中 collectors 是一个配置数组,每个收集器有一个项目,即 awx 和 podman。
awx 收集器需要身份验证,因此 userName 必须设置为 admin。密码从 secret-manager 检索。
不应更改端点。
defaultCollectorInterval 指定导出器从指标端点收集信息并将其发送到 Google Cloud Platform Monitoring 的默认间隔。
将此值设置为 0 或省略此属性会禁用所有收集器。
通过将 enabled 设为 true 或 false,可以单独启用或禁用每个收集器。
收集器返回按系列分组的所有可用指标,但您可以通过在数组 exclude Metrics 中添加名称来排除不应发送到 Google Cloud Platform Monitoring 的系列。
对于所有其他系列指标,您可以指定要收集的时间间隔并将其发送到 Google Cloud Platform Monitoring。收集器间隔是所有系列指标间隔和 defaultCollectorInterval 之间的最小值。这样可确保为发送到 Google Cloud Platform Monitoring 的每个指标集合集合。
9.2.2. Google Cloud ops 代理配置
配置文件详细信息可在此位置找到。
配置文件位于 /etc/google-cloud-ops-agent/config.yml 中。
这是到共享磁盘 /aap/bootstrap/config_file_templates/controller/gcp-ops-agent-config.yml 或 /aap/bootstrap/config_file_templates/hub/gcp-ops-agent-config.yml 的符号链接,具体取决于组件类型。
配置文件包含多个接收器,指定 ops 代理应收集的内容。
您在部署过程中的 Connect Logging 和 Connect Metrics 决定了哪些管道包含在文件中,因此会收集哪些日志和指标并发送到 GCP。
如果需要在部署后添加更多管道,您可以在 /aap/bootstrap/config_file_templates/hub|controller/gcp-ops-agent-config.yml 中插入它们。
如果最后 10 分钟内更改了 gcp-ops-agent-config.yml,则 crontab 作业会重新启动代理。代理在重启后重新读取其配置。
第 10 章 备份和恢复
- 您必须使用与备份相同的操作镜像版本进行恢复。
- 要备份和恢复 Ansible Automation Platform 部署,务必要使现有 Ansible Automation Platform 管理 secret 名称和值记录在某个地方安全。
- 还需要对 Cloud SQL 数据库实例和 filestore 备份进行常规手动备份,以确保部署可以尽可能接近其以前的工作状态。
playbook 备份和恢复为来自 GCP Marketplace 基础部署的 Ansible Automation Platform 提供备份和恢复支持。
恢复过程会部署一个新的 Ansible Automation Platform,并将 filestore 和 SQL 数据库实例恢复到指定的备份。
10.1. 备份过程
备份允许您通过保存数据库和共享文件系统来备份您的环境。使用保存的共享文件系统在恢复过程中创建一个新环境。当新环境就位时,进程会恢复数据库。
备份和恢复过程必须使用相同的版本。如果使用早期版本执行备份,则必须使用该版本的恢复过程。然后,如果需要,您可以运行升级。
您还必须在升级前进行备份。如需更多信息,请参阅升级部署
备份过程涉及在给定时间点对 Cloud SQL 数据库和 filestore 实例进行备份。备份 playbook 需要运行 GCP Marketplace 基础部署的活跃 Ansible Automation Platform。
需要在项目中创建存储桶,因为恢复信息将存储在该存储桶中。
bucket 可以包含来自同一部署或不同的部署的多个备份。备份将生成一个名为 <prefix>-<deployment_name>-<timestamp> 的目录,以及名为 <prefix>-<deployment_name>-<timestamp>.json 的文件。目录包含 awx 和 pulp 数据库备份、部署配置和 secret。json 文件包含恢复过程的信息。
Playbook 通过 CLI 提供,以列出和删除备份。
以下流程描述了如何从 GCP Marketplace 部署备份 Ansible Automation Platform。
10.1.1. 拉取 ansible-on-clouds-ops 容器镜像
流程
使用与基础部署相同的标签,拉取
ansible-on-clouds-ops容器的 docker 镜像。注意在拉取 docker 镜像前,请确保使用 docker 登录到 registry.redhat.io。使用以下命令登录到 registry.redhat.io。
$ docker login registry.redhat.io
有关 registry 登录的更多信息,请参阅 Registry 身份验证
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
10.1.2. 所需权限
您必须具有以下 GCP IAM 权限才能备份堆栈:
required-roles: Service Account User Compute Instance Admin (v1) required-permissions: compute.instances.list deploymentmanager.deployments.get deploymentmanager.manifests.get deploymentmanager.manifests.list deploymentmanager.resources.list file.backups.create file.operations.get iap.tunnelInstances.accessViaIAP storage.objects.create storage.objects.list
10.1.3. 设置环境
流程
创建用于存放配置文件的文件夹。
$ mkdir command_generator_data
10.1.4. 备份要求
您必须创建一个存储桶,将 Ansible 存储在云部署备份上。bucket 包含备份信息、secret 和数据库备份。
流程
- 在 Google Cloud 控制台中进入 Cloud Storage → Buckets
- 选择项目。
- 点 Create。
- 输入名称。
- 输入适合您的要求的数据位置。通过多和双区域,您可以对另一个区域进行恢复。
- 输入适合您要求的存储类。
- 输入适合您的要求的控制访问。
- 输入适合您的要求的数据保护。
- 点 Create
故障排除
如果存储桶名称已在另一个项目中使用,则会引发错误。
10.1.5. 创建备份数据文件
流程
运行命令 generator
command_generator_vars来生成backup.yml。注意在 Linux 上,命令生成器创建的任何文件或目录默认归
root:root所有。要更改文件和目录的所有权,您可以在创建文件后运行sudo chmod命令。如需更多信息,请阅读 命令生成器 - 由 root 拥有的 Linux 文件。docker run --rm -v $(pwd)/command_generator_data/:/data $IMAGE command_generator_vars gcp_backup_deployment --output-data-file /data/backup.yml
运行此命令后,会创建一个
$(pwd)/command_generator_data/backup.yml模板文件。此模板文件类似于以下内容:gcp_backup_deployment: cloud_credentials_path: deployment_name: extra_vars: backup_prefix: aoc-backup gcp_bucket_backup_name: gcp_compute_region: gcp_compute_zone:
10.1.6. backup.yml 文件中的参数
在触发备份前,您必须填充数据文件。以下变量是数据文件中列出的参数。
-
cloud_credentials_path是 Google Cloud 服务帐户凭证文件的路径。这必须是绝对路径。 -
DEPLOYMENT_NAME 是您要备份的 AAP 部署的名称。 -
backup_prefix是您要添加到备份名称的前缀(默认:oc-backup) -
gcp_bucket_backup_name是之前创建的用于备份的存储桶。 -
gcp_compute_region是部署基础部署的 GCP 区域。这可以通过检查 Deployment Manager 中的 Deployments 配置来检索。 -
gcp_compute_zone是部署基础部署的 GCP 区。这可以通过检查 Deployment Manager 中的 Deployments 配置来检索。
10.1.7. 运行备份 playbook
流程
要运行备份,请运行命令生成器来生成 backup 命令。
docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_backup_deployment --data-file /data/backup.yml
会产生以下 ouput:
----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name --env GENERATE_INVENTORY=true \ $IMAGE redhat.ansible_on_clouds.gcp_backup_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=<deployment_name> gcp_compute_region=<region> gcp_compute_zone=<zone> \ gcp_bucket_backup_name=<bucket> backup_prefix=aoc-backup'
运行提供的备份命令来触发备份。
$ docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name --env GENERATE_INVENTORY=true \ $IMAGE redhat.ansible_on_clouds.gcp_backup_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=<deployment_name> gcp_compute_region=<region> gcp_compute_zone=<zone> \ gcp_bucket_backup_name=<bucket> backup_prefix=aoc-backup'
playbook 运行后,输出类似于以下内容:
TASK [redhat.ansible_on_clouds.standalone_gcp_backup : [backup_deployment] Print the variable required to restore deployment my-deployment] *** ok: [localhost] => { "msg": [ "AAP on GCP Backup successful. Please note below the bucket name and backup name which are required for restore process.", "gcp_bucket_backup_name: my-bucket", "backup_name: aoc-backup-my-deployment-20230616T134002" ] } PLAY RECAP ********************************************************************* localhost : ok=38 changed=6 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
10.1.8. 列出备份
此 playbook 允许您列出特定存储桶中的现有备份。
流程
使用配置文件模板填充
command_generator_data目录。注意在 Linux 上,命令生成器创建的任何文件或目录默认归
root:root所有。要更改文件和目录的所有权,您可以在创建文件后运行sudo chmod命令。如需更多信息,请阅读 技术说明。docker run --rm -v $(pwd)/command_generator_data/:/data $IMAGE command_generator_vars gcp_backup_list --output-data-file /data/backups_list.yml
运行此命令后,会创建一个
$(pwd)/command_generator_data/backups_list.yml模板文件。此模板文件类似于以下内容:gcp_backup_list: cloud_credentials_path: extra_vars: gcp_bucket_backup_name:要运行备份,请运行命令生成器来生成 backup 命令。
docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_backup_list --data-file /data/backups_list.yml
会产生以下 ouput:
----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg $IMAGE redhat.ansible_on_clouds.gcp_backup_list \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_bucket_backup_name=<bucket>'
- 运行提供的 backup 命令,以触发备份列表。
playbook 运行后,输出类似于以下内容:
TASK [redhat.ansible_on_clouds.standalone_gcp_backup_list : [list_backup] Display list of backups] *** ok: [localhost] => { "msg": [ "aoc-backup-deployment1-20230614T203926", "aoc-backup-deployment1-20230616T114134", "aoc-backup-deployment1-20230616T134002", "aoc-backup-deployment2-20230613T124127" ] } PLAY RECAP ********************************************************************* localhost : ok=11 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
10.1.9. 删除备份
删除备份有两个 playbook:
-
使用
gcp_backup_deleteplaybook 删除单个备份。 -
使用
gcp_backups_deleteplaybook 一次性删除多个备份。
gcp_backups_delete 使用字符串 ["backup1","backup2",…] 的数组,而 gcp_backup_delete 只需要一个字符串,它是特定备份的名称 "backup1"。
本节描述了 gcp_backups_delete 的使用。
流程
使用配置文件模板填充
command_generator_data目录。注意在 Linux 上,命令生成器创建的任何文件或目录默认归
root:root所有。要更改文件和目录的所有权,您可以在创建文件后运行sudo chmod命令。如需更多信息,请阅读 命令生成器 - 由 root 拥有的 Linux 文件。docker run --rm -v $(pwd)/command_generator_data/:/data $IMAGE command_generator_vars gcp_backups_delete --output-data-file /data/backups_delete.yml
运行此命令后,会创建一个
$(pwd)/command_generator_data/backups_delete.yml模板文件。此模板文件类似于以下内容:gcp_backups_delete: cloud_credentials_path: extra_vars: backup_names: delete: gcp_bucket_backup_name:
backup_names 参数必须指定字符串数组,例如 ["backup1","backup2 "]。delete 参数必须设置为 true 才能成功删除。
要删除备份,请运行命令生成器来生成
gcp_backups_delete'命令。docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_backups_delete --data-file /data/backups_delete.yml
会产生以下 ouput:
----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg $IMAGE redhat.ansible_on_clouds.gcp_backups_delete \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_bucket_backup_name=<bucket> \ backup_names=<backup_names> delete=True'
- 运行提供的备份命令以删除备份。
playbook 运行后,输出类似于以下内容:
TASK [redhat.ansible_on_clouds.standalone_gcp_backup_delete : [delete_backup] Dry-run message] *** skipping: [localhost] PLAY RECAP ********************************************************************* localhost : ok=23 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
10.1.10. 修复失败的备份删除
如果删除备份失败,请执行以下操作:
流程
- 导航到包含备份的存储桶。
- 找到具有备份名称的目录。
- 打开备份目录。
- 使用备份名称删除该目录。
-
删除带有
.json扩展名的备份名称的文件。 - 导航到 Filestore → Backup。
- 使用与备份相同的名称删除 Filestore 备份。
10.2. 恢复过程
恢复过程会创建新的部署,并将 filestore 和 SQL 数据库实例恢复到指定的备份。
- 您必须使用用于备份的相同操作镜像版本恢复。
以下流程描述了如何从 GCP Marketplace 部署中恢复 Ansible Automation Platform。
10.2.1. 拉取 ansible-on-clouds-ops 容器镜像
流程
使用与基础部署相同的标签,拉取
ansible-on-clouds-ops容器的 docker 镜像。注意在拉取 docker 镜像前,请确保使用 docker 登录到 registry.redhat.io。使用以下命令登录到 registry.redhat.io。
$ docker login registry.redhat.io
有关 registry 登录的更多信息,请参阅 Registry 身份验证
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
10.2.2. 设置环境
流程
创建用于存放配置文件的文件夹。
$ mkdir command_generator_data
10.2.3. 所需权限
您必须具有以下 GCP IAM 权限才能恢复堆栈:
required-roles: Cloud SQL Client Cloud SQL Instance User Compute Instance Admin (v1) Compute Network Admin Editor Logs Writer Secret Manager Secret Accessor Service Account User required-permissions: compute.instances.list compute.networks.create deploymentmanager.deployments.create deploymentmanager.deployments.get deploymentmanager.operations.get file.instances.create file.operations.get iap.tunnelInstances.accessViaIAP secretmanager.secrets.create secretmanager.secrets.delete secretmanager.secrets.get secretmanager.secrets.update secretmanager.versions.add secretmanager.versions.list storage.objects.get storage.objects.list
10.2.4. 生成 restore.yml 文件
流程
运行命令 generator
command_generator_vars来生成restore.yml。注意在 Linux 上,命令生成器创建的任何文件或目录默认归
root:root所有。要更改文件和目录的所有权,您可以在创建文件后运行sudo chmod命令。如需更多信息,请阅读 技术说明。docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator_vars gcp_restore_deployment --output-data-file /data/restore.yml
运行此命令后,会创建一个
$(pwd)/command_generator_data/restore.yml模板文件。此模板文件类似于以下内容:=============================================== Playbook: gcp_restore_deployment Description: This playbook is used to restore the Ansible Automation Platform from GCP Marketplace environment from a backup. ----------------------------------------------- This playbook is used to restore the Ansible Automation Platform from GCP Marketplace environment from a backup. For more information regarding backup and restore, visit our official documentation - https://access.redhat.com/documentation/zh-cn/ansible_on_clouds/2.x/html/red_hat_ansible_automation_platform_from_gcp_marketplace_guide/index ----------------------------------------------- Command generator template: docker run --rm -v <local_data_file_directory>:/data $IMAGE command_generator gcp_restore_deployment --data-file /data/restore.yml
模板类似于以下内容:
gcp_restore_deployment: cloud_credentials_path: deployment_name: extra_vars: backup_name: gcp_bucket_backup_name: gcp_cloud_sql_peering_network: gcp_compute_region: gcp_compute_zone: gcp_controller_internal_ip_address: gcp_existing_vpc: gcp_filestore_ip_range: gcp_hub_internal_ip_address:
10.2.5. restore.yml 文件的参数
您只能恢复到新的 VPC 网络。
对于新的 VPC
如果要使用新的 VPC 恢复,请设置以下参数:
-
gcp_existing_vpc必须设为false。
必须删除以下参数:
-
gcp_filestore_ip_range -
gcp_cloud_sql_peering_network -
gcp_controller_internal_ip_address -
gcp_hub_internal_ip_address
为以下参数提供值:
-
gcp_existing_vpc必须设为false。 -
cloud_credentials_path是 Google Cloud 服务帐户凭证文件的路径。 -
DEPLOYMENT_NAME 是必须恢复部署的名称。将使用此名称创建新的部署。此名称不能已存在部署。 -
backup_name是存储桶中的备份名称。使用 gcp_backup_deployment 或命令时会显示此名称。gcp_backup_list -
gcp_bucket_backup_name是用于备份的存储桶名称。 -
gcp_compute_region是进行备份的区域。这可以通过检查 Deployment Manager 中的 Deployments 配置来检索。 -
gcp_compute_zone是进行备份的区域。这可以通过检查 Deployment Manager 中的 Deployments 配置来检索。
对于现有的 VPC
如果要使用现有的 VPC 恢复,您必须设置上面显示的参数。
您还必须设置以下附加参数:
-
gcp_existing_vpc设置为true。 -
gcp_filestore_ip_range必须设置为您的 VPC 的空闲 ip/29 范围。例如: 192.168.245.0/29。从 GCP Marketplace 部署 Ansible Automation Platform 时,不得使用 192.168.243.0/29 作为默认值。 -
gcp_cloud_sql_peering_network必须设置为空闲/24子网。您不能使用 192.168.241.0/24,因为这会在原始部署过程中使用。 -
gcp_controller_internal_ip_address必须设置为 VPC 网络中的一个空闲 IP。 -
gcp_hub_internal_ip_address必须设置为 VPC 网络中的一个空闲 IP。
10.2.6. 运行 restore 命令
填充 $(pwd)/command_generator_data/restore.yml 时,您可以使用命令生成器来创建恢复命令。
流程
运行命令生成器。
$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_restore_deployment --data-file /data/restore.yml
这会生成一个包含所有所需卷、环境变量和参数的新命令。
生成的命令类似如下:
docker run --rm --env PLATFORM=GCP -v <local_credential_file>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> --env GENERATE_INVENTORY=true -\ -env CHECK_GENERATED_INVENTORY=false $IMAGE redhat.ansible_on_clouds.gcp_restore_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=<deployment_name> gcp_compute_region=<region> gcp_compute_zone=<zone> \ gcp_bucket_backup_name=<bucket> backup_name=<backup_name> gcp_existing_vpc=<existing_vpc>'
运行生成的命令。
$ docker run --rm --env PLATFORM=GCP -v <local_credential_file>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg $IMAGE redhat.ansible_on_clouds.gcp_restore_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=<former_deployment_name> gcp_restored_deployment_name=<new_deployment_name> \ gcp_compute_region=<region> gcp_compute_zone=<zone> gcp_bucket_backup_name=<bucket> gcp_existing_vpc=False'
playbook 完成后,输出类似于以下内容:
TASK [redhat.ansible_on_clouds.standalone_gcp_restore : Display internal IP addresses] *** ok: [localhost] => msg: - 'Hub internal IP: 192.168.240.21' - 'Controller internal IP: 192.168.240.20' PLAY RECAP ********************************************************************* localhost : ok=33 changed=8 unreachable=0 failed=0 skipped=6 rescued=0 ignored=2
10.2.7. 无法恢复
如果在恢复过程中出现类似以下内容的消息,则必须联系支持,因为必须手动进行恢复。
TASK [redhat.ansible_on_clouds.standalone_gcp_restore : [restore_deployment] Restore awx db] *
fatal: [localhost -> dvernier-restore1-aap-cntrlr-x2c6]: FAILED!第 11 章 升级
您可以将现有的 Ansible Automation Platform 部署升级到更新的版本。升级过程涵盖了升级自动化中心、自动化控制器和扩展节点。升级过程所需的时间与 Ansible Automation Platform 部署安装大约相同。在运行升级前,需要创建备份。
先决条件
- 必须安装 Docker 才能运行升级 playbook。
-
运行
ansible-on-clouds-ops容器镜像的 Linux 或 macOS 系统。 - 升级过程需要挂载几个卷。准备要用于此过程的新目录。
以下流程组成升级过程:
备份 Ansible Automation Platform 2.3 堆栈。
升级 Ansible Automation Platform
- 拉取 ansible-on-clouds-ops 2.4 容器镜像
- 确保满足最低所需的权限
- 生成数据文件
- 更新数据文件
- 运行操作容器开始升级 Ansible Automation Platform
(可选)从备份中恢复堆栈。
11.1. 在升级前备份
在开始升级 Ansible Automation Platform 环境前,您必须首先在其当前版本处备份您的环境。
要在早期版本中备份 Ansible Automation Platform 环境,请按照 Clouds 2.3 备份说明中的 Ansible 进行操作。
11.2. 升级 Ansible Automation Platform
11.2.1. 拉取 ansible-on-clouds-ops 容器镜像
流程
在云操作容器上拉取 Ansible 的 Docker 镜像,其标签与您要升级到的版本相同。
注意在拉取 docker 镜像前,请确保使用 docker 登录到 registry.redhat.io。使用以下命令登录到 registry.redhat.io。
$ docker login registry.redhat.io
有关 registry 登录的更多信息,请参阅 Registry 身份验证
注意Clouds 操作镜像标签上的 Ansible 必须与您要升级到的版本匹配。例如,如果您的基础部署版本为 2.3.20230221,请使用标签 2.4.20230630 拉取操作镜像,以升级到 2.4.20230630 版本。
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
11.2.2. 所需权限
您必须具有以下 GCP IAM 权限才能升级堆栈:
required-roles: - Service Account User - Compute Instance Admin (v1) required-permissions: - compute.healthChecks.update - compute.healthChecks.use - compute.healthChecks.useReadOnly - compute.regionBackendServices.update - iap.tunnelInstances.accessViaIAP - runtimeconfig.variables.get - secretmanager.locations.get - secretmanager.locations.list - secretmanager.secrets.create - secretmanager.secrets.delete - secretmanager.secrets.get - secretmanager.secrets.list - secretmanager.secrets.update - secretmanager.versions.access - secretmanager.versions.add - secretmanager.versions.disable - secretmanager.versions.enable - secretmanager.versions.get - secretmanager.versions.list
11.2.3. 生成数据文件
本节中的命令会创建一个目录,并使用在升级过程中使用填充时的空数据模板填充。
流程
运行以下命令以生成所需的数据文件。
# Create a folder to hold the configuration files $ mkdir command_generator_data
使用配置文件模板填充
command_generator_data文件夹。注意在 Linux 上,命令生成器创建的任何文件或目录默认归
root:root所有。要更改文件和目录的所有权,您可以在创建文件后运行sudo chmod命令。如需更多信息,请阅读 命令生成器 - 由 root 拥有的 Linux 文件。$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE \ command_generator_vars gcp_upgrade \ --output-data-file /data/extra_vars.yml
运行这些命令后,会创建一个
command_generator_data/extra_vars.yml模板文件。此模板文件类似于以下内容:gcp_upgrade: ansible_config_path: cloud_credentials_path: deployment_name: extra_vars: gcp_backup_taken: gcp_compute_region: gcp_compute_zone:
11.2.4. 更新数据文件
在触发升级前,您必须填充数据文件。每个参数都需要,除非将其标记为可选。如果该参数为可选,可以从数据文件中删除其键和值。
-
ansible_config_path(可选)仅在使用自定义ansible_config覆盖时使用。 -
cloud_credentials_path是 GCP 凭证文件的路径。 DEPLOYMENT_NAME是基础部署的名称。- 这是部署基础时使用的相同名称。
-
gcp_backup_taken是最近在运行此升级前创建的手动备份当前部署的验证。此处使用true验证最近的备份是否已创建。 -
gcp_compute_region是部署基础部署时提供的 GCP 区域。如果您在部署基础时未提供区域,请在此处使用默认区域us-east1。 -
gcp_compute_zone是部署基础部署时提供的 GCP 区。如果您在部署基础时未提供区域,请在此处使用默认的us-east1-b。
填充数据文件后,它应类似于以下内容:
以下示例提供了以下值:
gcp_upgrade:
ansible_config_path:
cloud_credentials_path: ~/secrets/GCP-secrets.json
deployment_name: AnsibleAutomationPlatform
extra_vars:
gcp_backup_taken: true
gcp_compute_region: us-east1
gcp_compute_zone: us-east1-b11.2.5. 运行升级 playbook
Ansible Automation Platform 升级到 2.4.20230630 更新其内部负载均衡器的协议。如果在安装后添加了额外的网络配置,它们可能需要更新以确保连接。如需更多信息,请参阅升级 备注。
要运行升级,请运行命令生成器来生成 upgrade CLI 命令:
$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator --data-file /data/extra_vars.yml
这会生成以下命令:
----------------------------------------------- docker run --rm --env PLATFORM=GCP -v ~/secrets/GCP-secrets.json:/home/runner/.gcp/credentials:ro --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=AnsibleAutomationPlatform --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_upgrade \ -e 'gcp_deployment_name=AnsibleAutomationPlatform \ gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_compute_region=us-east1 gcp_compute_zone=us-east1-b gcp_backup_taken=True' ===============================================
运行给定的 upgrade 命令以触发升级。
$ docker run --rm --env PLATFORM=GCP -v ~/secrets/GCP-secrets.json:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg \ --env DEPLOYMENT_NAME=AnsibleAutomationPlatform \ --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_upgrade \ -e 'gcp_deployment_name=AnsibleAutomationPlatform \ gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_compute_region=us-east1 gcp_compute_zone=us-east1-b gcp_backup_taken=True'
升级可能需要一些时间才能完成,但根据系统中的扩展节点数量,可能需要更长的时间。以下日志会标记成功升级。
TASK [redhat.ansible_on_clouds.standalone_gcp_upgrade : [upgrade] Show GCP current version] *** ok: [localhost] => { "msg": "gcp_current_version: 2.3.20230221-00" }- 来自 GCP Marketplace 部署的 Ansible Automation Platform 现在已升级到更新的版本,您可以使用部署凭证登录到 Red Hat Ansible Automation Platform 自动化控制器和自动化中心。
11.3. 从备份中恢复
如果要将 Ansible Automation Platform 环境的早期版本恢复到升级前的状态,请按照 Clouds 2.3 恢复说明的 Ansible 进行操作。
第 12 章 卸装
本章介绍了如何卸载 Ansible Automation Platform。
12.1. 删除扩展节点
这个操作无法撤销。
扩展节点作为部署在 GCP Deployment Mananger 中创建。因此,删除 Ansible Automation Platform 扩展节点的过程与删除主 Ansible Automation Platform 部署的过程相同。
流程
- 选择主菜单。
- 选择 Deployment Manager。如果没有看到 Deployment Manager,请选择 View All Products。
选中您要删除的扩展节点的复选框。
注意扩展节点和主要部署可在 Deployment Manager 中找到。确保您选择了扩展节点,而不是主部署。扩展节点的名称由创建它的人员选择。
- 点顶部栏中的 Delete。这个操作无法撤销。
扩展节点已删除。
12.2. 卸载 Ansible Automation Platform
这个操作无法撤销。
如果为部署添加了外部负载均衡器,则必须在卸载部署前删除它。如需更多信息,请参阅 Load Balancers。
如果部署中添加了扩展节点,则必须在卸载部署前删除它们。按照删除扩展节点中的说明进行操作
流程
- 从左上角的主菜单。
- 选择 Deployment Manager。如果没有看到 Deployment Manager,请选择 View All Products。
- 选中要删除的部署前面的复选框。
- 点顶部栏中的 Delete。这个操作无法撤销。
完成删除可能需要一些时间。
12.3. 删除升级资源
以下流程描述了如何删除升级后遗留的任何资源。
这些操作无法撤销。
只有在部署被删除时才需要执行这些操作。
12.3.1. 删除 secret
这个操作无法撤销。
只有在您的部署被删除时才执行此操作。
您可以根据您完成的步骤,您可以找到几个可能的 secret 名称:
- <deployment_name>-aap-secret-key
- <deployment_name>-aap-admin
- <deployment_name>-container_auth_private_key_pem
- <deployment_name>-container_auth_public_key_pem
- <deployment_name>-database_fields_symmetric_key
- <deployment_name>-pulp_cert
- <deployment_name>-pulp_key
流程
- 从左上角的主菜单。
- 选择 Security。如果没有看到 Security,请选择 View All Products。
- 选择 Secret Manager。
- 搜索您的部署名称,在上面的列表中查找名称。
- 点部署 行中的 More Actions 图标。
- 选择 Delete。此时会显示管理密码。
- 输入 secret 的名称。
- 点 Delete Secret。
12.4. 删除备份资源
以下流程描述了如何在卸载 Ansible Automation Platform 部署后删除卸载 Ansible Automation Platform 部署时保留的任何资源。
这些操作无法撤销。
只有在部署被删除时才需要执行这些操作。
12.4.1. 删除 filestore
这个操作无法撤销。
- 流程
- 从左上角的主菜单。
- 选择 Filestore。如果没有看到 Filestore,请选择 View All Products。
- 选择 Backups。
-
备份名称的格式是
<DeploymentName>-filestore-<RandomSufix>。使用此名称进行过滤。 - 点部署 行中的 More Actions 图标。
- 选择 Delete。
- 此时会显示管理密码。
- 输入 secret 的名称。
- 点 Delete Backup。
12.4.2. 删除存储桶
流程
- 从左上角的主菜单。
- 选择 Cloud Storage。如果没有看到 Cloud Storage,请选择 View All Products。
- 选择 Buckets。
- 搜索您的部署名称。
- 点部署 行中的 More Actions 图标。
- 选择 Delete。
- 此时会显示管理密码。
- 输入 secret 的名称。
- 点 Delete Secret。
12.5. 删除剩余的资源
以下流程描述了如何删除卸载 Ansible Automation Platform 部署时保留的任何资源。
这些操作无法撤销。
只有在部署被删除时才需要执行这些操作。
12.5.1. 删除服务帐户
如果为部署创建了新服务帐户,并且如果没有在其他位置使用,则可以将它删除
流程
- 从左上角的主菜单。
- 选择 IAM & Admin。如果没有看到 IAM & Admin,请选择 View All Products。
- 选择 Service Accounts。
- 使用服务帐户的名称替换。
- 在服务帐户 的行中 点 More Actions 图标。
- 选择 Delete。
- 此时会显示管理密码。
- 单击 Delete。
第 13 章 技术备注
GCP Marketplace 中的 Ansible Automation Platform 是一个自我管理的部署。以下是来自 GCP Marketplace 部署的 Ansible Automation Platform 的技术备注。
13.1. Upgrade - 日志记录和监控
为确保升级成功,在运行升级前必须禁用日志记录和监控。按照以下说明,在开始升级前关闭当前版本的监控和日志记录。升级完成后,您可以 按照以下说明 重新启用日志记录和监控。
13.2. 命令生成器 - 由 root 拥有的 Linux 文件
在 Linux 上,命令生成器创建的任何文件或目录默认归 root:root 所有。要更改文件和目录的所有权,您可以在创建文件后运行 sudo chmod 命令:
# Change the owner of the command_generator_data directory recursively $ sudo chown -R $USER:$USER command_generator_data/ # Check the permissions $ ls -la command_generator_data/
命令生成器目前预期在 守护进程模式中使用 Docker CLI。默认 Docker 安装没有 Discretionary 访问控制(DAC)的用户命名空间映射。因此,如果文件位于共享卷中,则容器从 创建的任何文件也将归主机上的 root 所有。
root
您可以了解更多有关 Linux 命名空间的信息,包括用户命名空间,网址为 7 个最常用的 Linux 命名空间。
13.3. 升级备注
将 Ansible Automation Platform 升级到 2.4.20230630 将其内部负载均衡器的协议从 HTTP 更新至 HTTP。如果添加了额外的网络配置,也可以更新它们以确保连接。当升级成功时,您必须重新验证任何其他添加的网络配置。
13.4. Ansible Automation Platform Controller API
Controller 的 API 端点必须包含尾部斜杠,才能请求通过。目前,来自 GCP Marketplace 的 Ansible Automation Platform 不支持自动尾部的斜杠重定向。例如,当 < controller_base_url>/api/v2/metrics /api/v2/metrics / 接管时,<controller_base_url>/api/v2/metrics/ 等请求会超时。
13.5. 删除扩展节点备注
使用 Ansible-on-Clouds ops playbook 删除扩展节点时,请确保已提供正确的实例组名称和实例模板名称。实例组名称和实例模板名称不正确,会导致一些孤立的资源。
13.6. Secret 更新
当您更新 GCP secret Manager 中的任何 secret 时,请确保启用了最新的 secret 版本。例如,如果您有两个 secret 版本用于 < deployment-name>-aap-admin secret,则必须启用 secret 版本 2,其中 & lt;deployment-name > 是您的基础部署的名称。
第 14 章 支持
GCP Marketplace 中的 Ansible Automation Platform 是一个自我管理的部署。当应用程序部署到 GCP 基础架构中时,客户负责维护 GCP 基础架构、操作系统补丁和 Ansible Automation Platform 补丁。
除非红帽有介绍过程的文档,如网络或记录升级过程的路由表配置中,红帽不支持作为解决方案的一部分部署的基础架构资源更改。在扩展节点之外添加额外的计算资源,以避免从 GCP Marketplace 部署中对 Ansible Automation Platform 的支持。
从 GCP Marketplace 升级到 Ansible Automation Platform 与自安装的 Ansible Automation Platform 不同。也支持使用 dnf 或其他方法在虚拟机上升级单个软件包。本文档的升级部分中将为每个版本提供相关内容的升级部分。
14.1. 支持的基础架构配置更改
红帽支持对以下选项的更改:
- VPC 路由配置
- VPC 防火墙配置
- VPC Load Balancer 配置
- 块存储扩展
-
DNS 和
resolv.conf文件
Red Hat Responsibilities
红帽有以下职责:
- 对 Ansible Automation Platform 的高级支持
- 从 GCP Marketplace 升级 Ansible Automation Platform 的指示和如何进程。
- 红帽支持当前版本的 Ansible Automation Platform。程序错误修复和 CVE 补丁需要升级到最新版本
客户响应
您有以下职责:
- GCP 基础架构正常运行时间
- GCP 基础架构更改,例如增加块存储大小
- GCP 网络对等和配置
Ansible Automation Platform 升级的应用程序
- 包括操作系统升级
- 备份 GCP 资源
14.2. 虚拟机镜像软件包
GCP Marketplace 的 Ansible Automation Platform 通过基于 Red Hat Ansible 团队生成的虚拟机镜像的虚拟机提供。此镜像包含来自 Red Hat 和 Google 的软件包,以便在 Google Cloud Platform 上正常工作并运行 Red Hat Ansible Automation Platform。镜像包含以下 Google 软件包和容器:
| 软件包名称 | 描述 |
|---|---|
|
| Google OS 配置代理使用管理服务来部署、查询和维护一致的配置,即虚拟机实例所需的状态和软件。 |
|
| Ops Agent 是从您的 Compute Engine 实例收集遥测的主要代理。将日志记录和指标合并到单个代理中,Ops Agent 将 Fluent Bit 用于日志,它支持高吞吐量日志记录,以及 OpenTelemetry Collector 用于指标。 |
|
| Cloud SQL Authorization 代理用于使用虚拟机服务帐户将 Ansible Automation Platform 组件与 Cloud SQL 数据库连接。 |
|
| gcloud 命令行界面用于配置 Ansible Automation Platform 安装。 |
附录 A. Clouds 2.4 上的 Ansible 发行注记
此发行版本包括很多改进、添加以及从 GCP Marketplace 为 Ansible Automation Platform 实施的修复。
目前,在云产品的自助管理的 Ansible 上还不支持 Automation Mesh 和 Event Driven Automation。
功能增强
GCP Marketplace 中的 Ansible Automation Platform 版本 2.4.20230630 包括以下改进:
- 添加了对 Ansible Automation Platform 2.4 的支持。
向 web 服务器添加了内部加密
- 现在支持添加自定义证书。
添加了对自定义标记和标记的支持。
- 在 GCP 中添加了对标签支持,以添加或删除部署所拥有的资源的标签支持。
- GCP Marketplace 中的 Ansible Automation Platform 现在具有用于添加和删除扩展节点的 playbook。
备份和恢复功能有改进。
- 添加了对使用多个备份的支持。
- 添加了一个可操作的 playbook 来列出可用的备份。
- 添加了一个操作 playbook 来删除所选备份。
- 添加了恢复现有 VPC 的功能。
添加了用于检查当前版本的操作功能。
- 现在,运行 playbook 会检查以确保它们运行的 Ansible Automation Platform 环境在开始操作前在同一版本中。
弃用和删除的功能
之前版本中的一些功能已被弃用或删除。弃用的功能仍然包含在 Ansible Automation Platform 中,并且仍然被支持。但是,这个功能会在以后的发行版本中被删除,且不建议在新的部署中使用。以下是 Ansible Automation Platform 2.3 中已弃用并删除的主要功能列表:
- 内部组件 Automation Services Catalog 现已从 Ansible Automation Platform 2.4 中删除。
- 在 Ansible Automation Platform 2.4 发行版本中,Ansible 2.9 的 Execution Environment 容器镜像(ee-29-rhel-8)不再默认加载到 Automation Controller 配置中。
与 Ansible Automation Platform 相关的其他发行注记
- 查看 Red Hat Enterprise Linux 9的最新功能
- 了解有关最新 Ansible Automation Platform 功能的更多信息