在 OpenShift 上部署 AMQ Broker
对于使用 AMQ Broker 7.10
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息。
第 1 章 OpenShift Container Platform 上 AMQ Broker 简介
Red Hat AMQ Broker 7.10 作为容器化镜像,用于 OpenShift Container Platform (OCP) 4.12、4.13、4.14 或 4.15。
AMQ Broker 基于 Apache ActiveMQ Artemis。它提供符合 JMS 的消息代理。设置初始代理 pod 后,您可以使用 OpenShift Container Platform 功能快速部署重复。
1.1. 版本兼容性和支持
有关 OpenShift Container Platform 镜像版本兼容性的详情,请参阅:
所有在 OpenShift Container Platform 上部署 AMQ Broker 现在都使用基于 RHEL 8 的镜像。
1.2. 不支持的功能
基于主从(master-slave)的高可用性
不支持通过配置主和从对来实现高可用性 (HA)。相反,AMQ Broker 使用 OpenShift Container Platform 中提供的 HA 功能。
外部客户端无法使用 AMQ Broker 提供的拓扑信息
当 AMQ 核心协议 JMS 客户端或 AMQ JMS 客户端连接到 OpenShift Container Platform 集群中的代理时,代理可以向客户端发送集群中所有其他代理的 IP 地址和端口信息,如果与当前代理的连接丢失,该列表充当客户端的故障转移列表。
每个代理提供的 IP 地址是一个内部 IP 地址,它不能被 OpenShift Container Platform 集群外部的客户端访问。要防止外部客户端尝试使用内部 IP 地址连接到代理,请在客户端使用的 URI 中设置以下配置,以初始连接到代理。
客户端 配置 AMQ 核心协议 JMS 客户端
useTopologyForLoadBalancing=false
AMQ JMS Client
failover.amqpOpenServerListAction=IGNORE
1.3. 文档惯例
本文档对 sudo
命令、文件路径和可替换值使用以下惯例:
sudo
命令
在本文档中,sudo
用于任何需要 root 特权的命令。使用 sudo
时,您应始终谨慎操作,因为任何更改都可能会影响整个系统。
有关使用 sudo
的更多信息,请参阅 sudo
命令。
关于在此文档中使用文件路径
在这个文档中,所有文件路径都对 Linux、UNIX 和类似操作系统(例如 /home/...
)有效。如果您使用的是 Microsoft Windows,则应使用等效的 Microsoft Windows 路径(例如,C:\Users\...
)。
可替换值
本文档有时会使用可替换值,您必须将这些值替换为特定于环境的值。可替换的值为小写,以尖括号(<>)
括起,样式则使用斜体和 monospace
字体。用下划线(_
)分隔多个词语。
例如,使用以下命令将 <project_name>
替换为您自己的项目名称。
$ oc new-project <project_name>
第 2 章 规划在 OpenShift Container Platform 上部署 AMQ Broker
本节论述了如何规划基于 Operator 的部署。
Operator 是使您能够打包、部署和管理 OpenShift 应用程序的程序。Operator 通常自动化常见或复杂任务。通常,Operator 旨在提供:
- 一致、可重复安装
- 系统组件的健康检查
- 无线 (OTA) 更新
- 受管升级
Operator 允许您在代理实例运行时进行更改,因为它们始终侦听您用来配置部署的自定义资源 (CR) 实例。当对 CR 进行更改时,Operator 会将更改与现有代理部署进行协调,并更新部署以反映更改。另外,Operator 提供了一个消息迁移功能,可确保消息数据的完整性。当因为部署有意缩减而在集群部署中代理关闭时,此功能会将信息迁移到仍然在同一代理集群中运行的代理 Pod。
2.1. AMQ Broker Operator 自定义资源定义概述
通常,自定义资源定义 (CRD) 是配置项目的模式,您可以针对通过 Operator 部署的自定义 OpenShift 对象进行修改。通过创建对应的自定义资源 (CR) 实例,您可以为 CRD 中的配置项目指定值。如果您是 Operator 开发人员,通过 CRD 公开的内容实际上就成为配置和使用对象的 API。您可以通过常规 HTTP curl
命令直接访问 CRD,因为 CRD 通过 Kubernetes 自动公开。
您可以使用 OpenShift 命令行界面 (CLI) 或 Operator Lifecycle Manager(OperatorHub 图形界面)安装 AMQ Broker Operator。在这两种情况下,AMQ Broker Operator 都会包括下面描述的 CRD。
- 主代理 CRD
您可以根据此 CRD 部署 CR 实例,以创建并配置代理部署。
根据您安装 Operator 的方式,此 CRD 为:
-
Operator 安装存档(OpenShift CLI 安装方法)的
crds
目录中的broker_activemqartemis_crd
文件 -
OpenShift Container Platform Web 控制台的
Custom Resource Definitions
部分中的ActiveMQArtemis
CRD(OperatorHub 安装方法)
-
Operator 安装存档(OpenShift CLI 安装方法)的
- 地址 CRD
您可以根据此 CRD 部署 CR 实例,为代理部署创建地址和队列。
根据您安装 Operator 的方式,此 CRD 为:
-
Operator 安装存档(OpenShift CLI 安装方法)的
crds
目录中的broker_activemqartemisaddress_crd
文件 -
OpenShift Container Platform Web 控制台的
Custom Resource Definitions
部分中的ActiveMQArtemisAddresss
CRD(OperatorHub 安装方法)
-
Operator 安装存档(OpenShift CLI 安装方法)的
- 安全 CRD
您可以基于此 CRD 部署 CR 实例,以创建用户并将这些用户与安全上下文关联。
根据您安装 Operator 的方式,此 CRD 为:
-
Operator 安装存档(OpenShift CLI 安装方法)的
crds
目录中的broker_activemqartemissecurity_crd
文件 -
OpenShift Container Platform Web 控制台的
Custom Resource Definitions
部分中的ActiveMQArtemisSecurity
CRD(OperatorHub 安装方法)。
-
Operator 安装存档(OpenShift CLI 安装方法)的
- scaleDown CRD
当实例化用于消息迁移的缩减控制器时,Operator 会根据这个 CRD 自动创建 CR 实例。
根据您安装 Operator 的方式,此 CRD 为:
-
Operator 安装存档(OpenShift CLI 安装方法)的
crds
目录中的broker_activemqartemisscale_crd
文件 -
OpenShift Container Platform Web 控制台的
Custom Resource Definitions
部分中的ActiveMQArtemisScaledown
CRD(OperatorHub 安装方法)。
-
Operator 安装存档(OpenShift CLI 安装方法)的
其他资源
要了解如何安装 AMQ Broker Operator(以及所有包含的 CRD):
- OpenShift CLI 请参阅 第 3.2 节 “使用 CLI 安装 Operator”
- Operator Lifecycle Manager 和 OperatorHub 图形界面,请参阅 第 3.3 节 “使用 OperatorHub 安装 Operator”。
有关基于主代理和地址 CRD 创建 CR 实例时使用的完整配置参考,请参阅:
2.2. AMQ Broker Operator 示例自定义资源概述
您在安装过程中下载和提取的 AMQ Broker Operator 归档包含 deploy/crs
目录中的示例自定义资源 (CR) 文件。这些 CR 文件示例可让您:
- 在没有 SSL 或集群的情况下部署最小代理。
- 定义地址。
您下载和提取的 broker Operator 归档还包括 deploy/examples
目录中部署示例 CR,如下所示。
artemis-basic-deployment.yaml
- 基本代理部署。
artemis-persistence-deployment.yaml
- 带有持久性存储的代理部署。
artemis-cluster-deployment.yaml
- 部署集群代理。
artemis-persistence-cluster-deployment.yaml
- 使用持久性存储部署集群代理。
artemis-ssl-deployment.yaml
- 带有 SSL 安全性的代理部署。
artemis-ssl-persistence-deployment.yaml
- 带有 SSL 安全性和持久性存储的代理部署。
artemis-aio-journal.yaml
- 将异步 I/O (AIO) 与代理日志搭配使用。
address-queue-create.yaml
- 地址和队列创建。
2.3. 观察 Cluster Operator 部署的选项
当 Cluster Operator 运行时,它开始 监视 AMQ Broker 自定义资源 (CR) 的更新。
您可以选择部署 Cluster Operator 来监视 CR:
- 单一命名空间(包含 Operator 的同一命名空间)
- 所有命名空间
如果您已经在集群中的命名空间中安装了 AMQ Broker Operator 的早期版本,红帽建议您不安装 AMQ Broker Operator 7.10 版本,以避免潜在的冲突。
2.4. Operator 如何选择容器镜像
为代理部署创建自定义资源 (CR) 实例时,您不需要在 CR 中明确指定代理或初始容器镜像名称。默认情况下,如果您部署 CR 且没有指定容器镜像值,Operator 会自动选择要使用的适当容器镜像。
如果使用 OpenShift 命令行界面安装 Operator,Operator 安装存档包括一个示例 CR 文件,名为 broker_activemqartemis_cr.yaml
。在示例 CR 中,包含 spec.deploymentPlan.image
属性,并将其默认值设置为 placeholder
。此值表示,在部署 CR 前,Operator 不会选择代理容器镜像。
spec.deploymentPlan.initImage
属性(用于指定 Init 容器镜像) 没有包括在 broker_activemqartemis_cr.yaml
示例 CR 文件中。如果您没有在 CR 中明确包含 spec.deploymentPlan.initImage
属性并指定值,Operator 会选择一个适当的内置初始容器镜像,以便在部署 CR 时使用。
本节中介绍了 Operator 选择这些镜像的方式。
要选择代理和初始容器镜像,Operator 首先决定镜像应与之对应的 AMQ Broker 版本。Operator 决定版本,如下所示:
-
如果主 CR 中的
spec.upgrades.enabled
属性已设置为true
,并且spec.version
属性指定7.7.0
,7.8.0
,7.8.1
, 或7.8.2
,则 Operator 会使用指定的版本。 -
如果
spec.upgrades.enabled
没有 设为true
,或spec.version
设置为早于7.7.0
的 AMQ Broker 版本,Operator 将 使用最新版本的 AMQ Broker (即7.10.7
)。
然后,Operator 会检测您的容器平台。AMQ Broker Operator 可以在以下容器平台中运行:
- OpenShift Container Platform (x86_64)
- IBM Z (s390x) 上的 OpenShift Container Platform
- IBM Power Systems (ppc64le) 上的 OpenShift Container Platform
然后,Operator 会根据 AMQ Broker 和容器平台的版本,在 operator.yaml
配置文件中引用两组环境变量。这些环境变量组为 AMQ Broker 的各种版本指定代理和初始容器镜像,如以下子章节中所述。
2.4.1. 代理容器镜像的环境变量
代理容器镜像的 operator.yaml
配置文件中包含的环境变量有以下命名规则:
- OpenShift Container Platform
-
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_<AMQ_Broker_version_identifier>
- IBM Z 上的 OpenShift Container Platform
-
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_<AMQ_Broker_version_identifier>_s390x
- IBM Power 系统上的 OpenShift Container Platform
-
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_<AMQ_Broker_version_identifier>_ppc64le
表中会显示每个受支持的容器平台和特定 AMQ Broker 版本的环境变量名称。
容器平台 | 环境变量名称 |
---|---|
OpenShift Container Platform |
|
IBM Z 上的 OpenShift Container Platform |
|
IBM Power 系统上的 OpenShift Container Platform |
|
每个环境变量的值都指定可通过红帽使用的代理容器镜像。例如:
- name: RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_7100 #value: registry.redhat.io/amq7/amq-broker-rhel8:7.10 value: registry.redhat.io/amq7/amq-broker-rhel8@sha256:982ba18be1ac285722bc0ca8e85d2a42b8b844ab840b01425e79e3eeee6ee5b9
因此,根据 AMQ Broker 版本和容器平台,Operator 会决定适用的环境变量名称。Operator 在启动代理容器时使用对应的镜像值。
在 operator.yaml
文件中,Operator 使用一个由 Secure Hash Algorithm (SHA) 值代表的镜像。注释行以数字符号 (#
) 符号开头,注明 SHA 值对应于特定的容器镜像标签。
2.4.2. Init 容器镜像的环境变量
Init 容器镜像的 operator.yaml
配置文件中包含的环境变量有以下命名约定:
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_<AMQ_Broker_version_identifier>
下面列出了特定 AMQ Broker 版本的环境变量名称。
-
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_782
-
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_790
-
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_7100
每个环境变量的值都指定红帽提供的初始容器镜像。例如:
- name: RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_7100 #value: registry.redhat.io/amq7/amq-broker-init-rhel8:0.4-21 value: registry.redhat.io/amq7/amq-broker-init-rhel8@sha256:f37f98c809c6f29a83e3d5a3ac4494e28efe9b25d33c54f533c6a08662244622
因此,Operator 基于 AMQ Broker 版本,决定适用的环境变量名称。Operator 在启动初始容器时使用对应的镜像值。
如示例所示,Operator 使用一个由 Secure Hash Algorithm (SHA) 值表示的镜像。注释行以数字符号 (#
) 符号开头,注明 SHA 值对应于特定的容器镜像标签。注意,对应的容器镜像标签为 0.4-21
的形式,因此不是浮动标签。这意味着 Operator 使用的容器镜像会保持固定。当它可以从红帽获得时,Operator 不会自动拉取并使用新的 micro 镜像版本(为 0.4-21-n
,其中 n 是最新的 micro 版本)。
Init 容器镜像的 operator.yaml
配置文件中包含的环境变量有以下命名约定:
- OpenShift Container Platform
-
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_<AMQ_Broker_version_identifier>
- IBM Z 上的 OpenShift Container Platform
-
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_s390x_<AMQ_Broker_version_identifier>
- IBM Power 系统上的 OpenShift Container Platform
-
RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_ppc64le_<AMQ_Broker_version_identifier>
表中会显示每个受支持的容器平台和特定 AMQ Broker 版本的环境变量名称。
容器平台 | 环境变量名称 |
---|---|
OpenShift Container Platform |
|
IBM Z 上的 OpenShift Container Platform |
|
IBM Power 系统上的 OpenShift Container Platform |
|
每个环境变量的值都指定红帽提供的初始容器镜像。例如:
- name: RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_7100 #value: registry.redhat.io/amq7/amq-broker-init-rhel8:0.4-21-1 value: registry.redhat.io/amq7/amq-broker-init-rhel8@sha256:f37f98c809c6f29a83e3d5a3ac4494e28efe9b25d33c54f533c6a08662244622
因此,根据 AMQ Broker 版本和容器平台,Operator 会决定适用的环境变量名称。Operator 在启动初始容器时使用对应的镜像值。
如示例所示,Operator 使用一个由 Secure Hash Algorithm (SHA) 值表示的镜像。注释行以数字符号 (#
) 符号开头,注明 SHA 值对应于特定的容器镜像标签。注意,对应的容器镜像标签为 0.4-21
的形式,因此不是浮动标签。这意味着 Operator 使用的容器镜像会保持固定。当它可以从红帽获得时,Operator 不会自动拉取并使用新的 micro 镜像版本(为 0.4-21-n
,其中 n 是最新的 micro 版本)。
其他资源
- 要了解如何使用 AMQ Broker Operator 创建代理部署,请参阅 第 3 章 使用 AMQ Broker Operator 在 OpenShift Container Platform 上部署 AMQ Broker。
- 如需有关 Operator 如何使用初始容器生成代理配置的更多信息,请参阅 第 4.1 节 “Operator 如何生成代理配置”。
- 要了解如何构建和 指定自定义 初始容器镜像,请参阅 第 4.7 节 “指定自定义 Init 容器镜像”。
2.5. Operator 部署备注
本节论述了在规划基于 Operator 的部署时的一些重要事项
- 部署与 AMQ Broker Operator 相关的自定义资源定义(CRD)需要 OpenShift 集群的集群管理员特权。部署 Operator 时,非管理员用户可以通过对应的自定义资源(CR)创建代理实例。要启用常规用户来部署 CR,集群管理员必须首先为 CRD 分配角色和权限。如需更多信息,请参阅 OpenShift Container Platform 文档中的 为自定义资源定义创建集群角色。
- 当使用最新 Operator 版本的 CRD 更新集群时,这个更新会影响 集群中的所有项目。任何从之前版本的 Operator 部署的代理 Pod 都可能无法更新其状态。当您点击 OpenShift Container Platform Web 控制台中正在运行的代理 Pod 的 Logs 选项卡时,您会看到显示"UpdatePodStatus"的消息已失败。但是,该项目中的代理 Pod 和 Operator 将继续按预期工作。要为受影响的项目修复这个问题,您还必须升级该项目以使用 Operator 的最新版本。
虽然您可以通过部署多个自定义资源(CR)实例在给定 OpenShift 项目中创建多个代理部署,但通常会在项目中创建单个代理部署,然后为地址部署多个 CR 实例。
红帽建议您在单独的项目中创建代理部署。
如果您打算使用持久性存储部署代理,且 OpenShift 集群中没有容器原生存储,则需要手动置备持久性卷(PV),并确保 Operator 可以声明这些代理。例如,如果要创建具有持久性存储的两个代理的集群(即,在 CR 中设置
persistenceEnabled=true
),则需要有两个持久性卷可用。默认情况下,每个代理实例都需要存储 2 GiB。如果您在 CR 中指定
persistenceEnabled=false
,部署的代理 将使用临时存储。临时存储意味着每次重启代理 Pod 时都会丢失任何现有数据。有关在 OpenShift Container Platform 中置备持久性存储的更多信息,请参阅:
首次部署 CR 之前,您必须将以下列出的项目添加到主代理 CR 实例中。您无法将 这些项目的配置添加到已在运行的代理部署中。
-
如果您更新 CR 中的参数,Operator 无法在 StatefulSet 中动态更新,Operator 会删除 StatefulSet 并使用更新的参数值重新创建它。删除 StatefulSet 会导致删除所有 pod 被删除并重新创建,这会导致临时代理中断。如果您将
persistenceEnabled=false
改为persistenceEnabled=true
,则 Operator 无法动态更新的 CR 更新示例。
2.6. 识别由现有 Operator 监控的命名空间
如果集群已经包含 AMQ Broker 安装的 Operator,并且希望新的 Operator 监视所有或多个命名空间,您必须确保新 Operator 不会监视与现有 Operator 相同的命名空间。使用以下步骤识别现有 Operator 所监视的命名空间。
流程
- 在 OpenShift Container Platform Web 控制台的左侧窗格中,点 → 。
-
在 Project 下拉列表中,选择
All Projects
。 在 Filter Name 框中,指定一个字符串,如
amq
,以显示集群中安装的 AMQ Broker 的 Operator。注意namespace 列中显示 部署 每个 Operator 的命名空间。
检查安装了 AMQ Broker 的每个安装 Operator 的命名空间,以监视。
- 点 Operator 名称显示 Operator 详情并点击 YAML 选项卡。
搜索
WATCH_NAMESPACE
并记录 Operator 监视的命名空间。-
如果
WATCH_NAMESPACE
部分有一个fieldPath
字段,其值为metadata.namespace
,Operator 监视部署的命名空间。 如果
WATCH_NAMESPACE
部分有一个具有命名空间列表的值
字段,Operator 将监控指定的命名空间。例如:- name: WATCH_NAMESPACE value: "namespace1, namespace2"
如果
WATCH_NAMESPACE
部分有一个为空或带有一个星号的value
字段时,Operator 会查看集群中的所有命名空间。例如:- name: WATCH_NAMESPACE value: ""
在这种情况下,在部署新 Operator 前,您必须卸载现有的 Operator 或重新配置它以监视特定的命名空间。
-
如果
下一节中的步骤演示了如何安装 Operator 并使用自定义资源(CR)在 OpenShift Container Platform 上创建代理部署。当您成功完成了流程后,您将让 Operator 在单独的 Pod 中运行。您创建的每个代理实例都会在与 Operator 相同的项目中作为单独的 Pod 运行。稍后,您将了解如何使用专用寻址 CR 在代理部署中定义地址。
第 3 章 使用 AMQ Broker Operator 在 OpenShift Container Platform 上部署 AMQ Broker
3.1. 先决条件
- 在安装 Operator 并使用它来创建代理部署前,您应该参阅 第 2.5 节 “Operator 部署备注” 中的 Operator 部署备注。
3.2. 使用 CLI 安装 Operator
每个 Operator 发行版本都要求您下载最新的 AMQ Broker 7.10.7 Operator 安装和示例文件,如下所述。
本节中的步骤演示了如何使用 OpenShift 命令行界面(CLI)在给定的 OpenShift 项目中安装和部署 AMQ Broker 7.10 的最新版本。在随后的步骤中,您可以使用此 Operator 部署一些代理实例。
- 有关安装使用 OperatorHub 图形界面的 AMQ Broker Operator 的替代方法,请参考 第 3.3 节 “使用 OperatorHub 安装 Operator”。
- 要了解 升级 基于 Operator 的代理部署的信息,请参阅 第 6 章 升级基于 Operator 的代理部署。
3.2.1. 准备部署 Operator
在使用 CLI 部署 Operator 前,您必须下载 Operator 安装文件并准备部署。
流程
- 在 Web 浏览器中,导航到 AMQ Broker 7.10.7 发行版本的 Software Downloads 页面。
-
确保 Version 下拉列表的值设为
7.10.7
,并且选择了 Releases 选项卡。 在 AMQ Broker 7.10.7 Operator Installation and Example Files 旁边,点 Download。
下载
amq-broker-operator-7.10.7-ocp-install-examples.zip
压缩存档会自动开始。将存档移到您选择的目录。以下示例将存档 移到名为
~/broker/operator
的目录。$ mkdir ~/broker/operator $ mv amq-broker-operator-7.10.7-ocp-install-examples.zip ~/broker/operator
在您选择的目录中,提取存档的内容。例如:
$ cd ~/broker/operator $ unzip amq-broker-operator-7.10.7-ocp-install-examples.zip
切换到提取存档时创建的目录。例如:
$ cd amq-broker-operator-7.10.7-ocp-install-examples
以集群管理员身份登录 OpenShift Container Platform。例如:
$ oc login -u system:admin
指定要安装 Operator 的项目。您可以创建新项目或切换到现有项目。
创建一个新项目
$ oc new-project <project_name>
或者,切换到现有项目:
$ oc project <project_name>
指定要与 Operator 搭配使用的服务帐户。
-
在您提取的 Operator 归档的
deploy
目录中,打开service_account.yaml
文件。 -
确保
kind
元素设置为ServiceAccount
。 -
如果要更改默认服务帐户名称,在
metadata
部分中,将amq-broker-operator
替换为自定义名称。 在项目中创建服务帐户。
$ oc create -f deploy/service_account.yaml
-
在您提取的 Operator 归档的
为 Operator 指定角色名称。
-
打开
role.yaml
文件。此文件指定 Operator 可以使用和修改资源。 -
确保
kind
元素设为Role
。 -
如果要更改默认角色名称,在
metadata
部分中,将amq-broker-operator
替换为自定义名称。 在项目中创建角色。
$ oc create -f deploy/role.yaml
-
打开
为 Operator 指定角色绑定。角色绑定根据您指定的名称将之前创建的服务帐户绑定到 Operator 角色。
-
打开
role_binding.yaml
文件。 确保
ServiceAccount
和Role
的name
值与service_account.yaml
和role.yaml
文件中指定的匹配。例如:metadata: name: amq-broker-operator subjects: kind: ServiceAccount name: amq-broker-operator roleRef: kind: Role name: amq-broker-operator
在项目中创建角色绑定。
$ oc create -f deploy/role_binding.yaml
-
打开
为 Operator 指定领导选举角色绑定。角色绑定根据您指定的名称将之前创建的服务帐户绑定到领导选举角色。
为 Operator 创建领导选举角色。
$ oc create -f deploy/election_role.yaml
在项目中创建领导选举角色绑定。
$ oc create -f deploy/election_role_binding.yaml
(可选)如果希望 Operator 监视多个命名空间,请完成以下步骤:
注意如果 OpenShift Container Platform 集群已经包含 AMQ Broker 安装的 Operator,您必须确保新的 Operator 不会监视与现有 Operator 相同的任何命名空间。有关如何识别现有 Operator 所监视的命名空间的信息,请参阅 识别现有 Operator 监视的命名空间。
-
在您下载并提取的 Operator 归档的 deploy 目录中,打开
operator_yaml
文件。 如果您希望 Operator 监控集群中的所有命名空间,在
WATCH_NAMESPACE
部分中添加一个value
属性,并将值设为星号。注释掉WATCH_NAMESPACE
部分中的现有属性。例如:- name: WATCH_NAMESPACE value: "*" # valueFrom: # fieldRef: # fieldPath: metadata.namespace
注意为了避免冲突,请确保多个 Operator 不会监视相同的命名空间。例如,如果您部署一个 Operator 来监控 集群中的所有命名空间,则无法部署另一个 Operator 来监控单独的命名空间。如果 Operator 已在集群中部署,您可以指定新 Operator 监视的命名空间列表,如下所述。
如果您希望 Operator 观察多个,但并非集群中的所有命名空间,在
WATCH_NAMESPACE
部分指定命名空间列表。确保排除现有 Operator 监视的任何命名空间。例如:- name: WATCH_NAMESPACE value: "namespace1, namespace2"`.
-
在您下载并提取的 Operator 归档的 deploy 目录中,打开
cluster_role_binding.yaml
文件。 在 Subjects 部分中,指定一个 与部署 Operator 的 OpenShift Container Platform 项目对应的命名空间。例如:
Subjects: - kind: ServiceAccount name: activemq-artemis-controller-manager namespace: operator-project
注意如果您之前使用早期版本的 Operator 部署代理,并且希望部署 Operator 来监控多个命名空间,请参阅 升级前。
在项目中创建集群角色。
$ oc create -f deploy/cluster_role.yaml
在项目中创建集群角色绑定。
$ oc create -f deploy/cluster_role_binding.yaml
-
在您下载并提取的 Operator 归档的 deploy 目录中,打开
在下面的流程中,您要在项目中部署 Operator。
3.2.2. 使用 CLI 部署 Operator
本节中的步骤演示了如何使用 OpenShift 命令行界面(CLI)在 OpenShift 项目中部署 AMQ Broker 7.10 的最新版本。
先决条件
- 您必须已经为 Operator 部署准备了 OpenShift 项目。请参阅 第 3.2.1 节 “准备部署 Operator”。
- 从 AMQ Broker 7.3 开始,您可以使用红帽生态系统目录的新版本访问容器镜像。这个 registry 的新版本需要您成为经过身份验证的用户,然后才能访问镜像。在按照本节中的步骤操作前,您必须首先完成 Red Hat Container Registry 身份验证 中描述的步骤。
如果您打算使用持久性存储部署代理,且 OpenShift 集群中没有容器原生存储,则需要手动置备持久性卷(PV),并确保 Operator 可以声明这些代理。例如,如果要创建具有持久性存储的两个代理的集群(即,通过在自定义资源中设置
persistenceEnabled=true
),则需要有两个 PV 可用。默认情况下,每个代理实例都需要存储 2 GiB。如果您在自定义资源中指定
persistenceEnabled=false
,部署的代理 将使用临时存储。临时存储意味着每次重启代理 Pod 时都会丢失任何现有数据。有关置备持久性存储的更多信息,请参阅:
流程
在 OpenShift 命令行界面(CLI)中,以集群管理员的身份登录到 OpenShift。例如:
$ oc login -u system:admin
切换到您之前为 Operator 部署准备的项目。例如:
$ oc project <project_name>
切换到之前提取 Operator 安装存档时创建的目录。例如:
$ cd ~/broker/operator/amq-broker-operator-7.10.7-ocp-install-examples
部署 Operator 中包含的 CRD。您必须在部署和启动 Operator 前,在 OpenShift 集群中安装 CRD。
部署主代理 CRD。
$ oc create -f deploy/crds/broker_activemqartemis_crd.yaml
部署地址 CRD。
$ oc create -f deploy/crds/broker_activemqartemisaddress_crd.yaml
部署 scaledown 控制器 CRD。
$ oc create -f deploy/crds/broker_activemqartemisscaledown_crd.yaml
部署安全 CRD:
$ oc create -f deploy/crds/broker_activemqartemissecurity_crd.yaml
将与 Red Hat Ecosystem Catalog 进行身份验证时使用的账户相关联的 pull secret 与您的 OpenShift 项目的
default
,deployer
, 和builder
服务账户进行链接。$ oc secrets link --for=pull default <secret_name> $ oc secrets link --for=pull deployer <secret_name> $ oc secrets link --for=pull builder <secret_name>
在您下载并提取的 Operator 归档的
deploy
目录中,打开operator.yaml
文件。确保spec.containers.image
属性的值对应于 Operator 的 7.10.7-opr-1 版本,如下所示。spec: template: spec: containers: #image: registry.redhat.io/amq7/amq-broker-rhel8-operator:7.10 image: registry.redhat.io/amq7/amq-broker-rhel8-operator@sha256:1a7aa54d2799d238eb5f49f7a95a78a896f6bf8d222567e9118e0e3963cc9aad
注意在
operator.yaml
文件中,Operator 使用一个由 Secure Hash Algorithm (SHA) 值代表的镜像。注释行以数字符号 (#
) 符号开头,注明 SHA 值对应于特定的容器镜像标签。部署 Operator。
$ oc create -f deploy/operator.yaml
在 OpenShift 项目中,Operator 会在新 Pod 中启动。
在 OpenShift Container Platform Web 控制台中,Operator Pod 的 Events 选项卡的信息确认 OpenShift 已部署了您指定的 Operator 镜像,已向 OpenShift 集群中的节点分配新容器,并已启动新的容器。
另外,如果您点击 Pod 中的 Logs 选项卡,输出应包含以下几行:
... {"level":"info","ts":1553619035.8302743,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"activemqartemisaddress-controller"} {"level":"info","ts":1553619035.830541,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"activemqartemis-controller"} {"level":"info","ts":1553619035.9306898,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"activemqartemisaddress-controller","worker count":1} {"level":"info","ts":1553619035.9311671,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"activemqartemis-controller","worker count":1}
前面的输出确认新部署的 Operator 与 Kubernetes 通信,代理和寻址的控制器正在运行,这些控制器已启动一些 worker。
建议在一个给定的 OpenShift 项目中仅部署 AMQ Broker Operator 的一个单个实例。不建议将 Operator 部署的 spec.replicas
属性设置为大于 1
的值,或者不要 在同一项目中部署 Operator。
其他资源
- 有关安装使用 OperatorHub 图形界面的 AMQ Broker Operator 的替代方法,请参考 第 3.3 节 “使用 OperatorHub 安装 Operator”。
3.3. 使用 OperatorHub 安装 Operator
3.3.1. Operator Lifecycle Manager 概述
在 OpenShift Container Platform 4.5 及之后的版本中,Operator Lifecycle Manager (OLM)可帮助用户安装、更新并通常管理所有 Operator 以及在用户集群中运行的关联服务的生命周期。Operator Framework 的一部分,后者是一个开源工具包,用于以有效、自动化且可扩展的方式管理 Kubernetes 原生应用程序(Operator)。
OLM 默认在 OpenShift Container Platform 4.5 及之后的版本中运行,辅助集群管理员对集群上运行的 Operator 进行安装、升级和授予访问权。OpenShift Container Platform Web 控制台提供一些管理界面,供集群管理员安装 Operator,以及为特定项目授权以便使用集群上的可用 Operator 目录。
OperatorHub 是 OpenShift 集群管理员用来使用 OLM 发现、安装和升级 Operator 的图形界面。只需单击一次,即可从 OperatorHub 拉取(由 OperatorHub 安装)并由 OLM 管理,为工程团队在开发、测试和生产环境中自助管理软件。
部署 Operator 后,您可以使用自定义资源(CR)实例来创建代理部署,如独立和集群代理等。
3.3.2. 从 OperatorHub 部署 Operator
此流程演示了如何使用 OperatorHub 将 AMQ Broker 的 Operator 的最新版本部署到指定的 OpenShift 项目中。
在 OperatorHub 中,您只能安装每个频道提供的最新 Operator 版本。如果要安装 Operator 的早期版本,则必须使用 CLI 安装 Operator。更多信息请参阅 第 3.2 节 “使用 CLI 安装 Operator”。
先决条件
-
Red Hat Integration - 用于 RHEL 8(Multiarch)Operator 的 AMQ Broker
必须在 OperatorHub 中提供。 - 您需要有集群管理员特权。
流程
- 以集群管理员身份登录 OpenShift Container Platform Web 控制台。
- 在左侧导航菜单中,点 → 。
- 在 OperatorHub 页面顶部的 Project 下拉菜单中,选择要在其上部署 Operator 的项目。
在 OperatorHub 页面中,使用 Filter by keyword… 复选框
为 RHEL 8(Multiarch)Operator 找到 Red Hat Integration - AMQ Broker
。注意在 OperatorHub 中,您可能会发现多个 Operator 多于在其名称中包含
AMQ Broker
。确保为 RHEL 8(Multiarch)Operator 点 Red Hat Integration - AMQ Broker
。当点此 Operator 时,请查看打开的信息窗格。对于 AMQ Broker 7.10,Operator 的最新次要版本标签为7.10.7-opr-1
。-
点
Red Hat Integration - AMQ Broker for RHEL 8(Multiarch)
Operator。在出现的对话框中,点 Install。 在 Install Operator 页面中:
在 Update Channel 下,选择
7.10.x
频道,以只接收版本 7.10 的更新。7.10.x
频道是当前的 Long Term Support (LTS)频道。注意以下频道也可见:
-
7.x
- 当前,此频道只为版本 7.9 提供更新。 -
7.8.x
- 此频道仅为版本 7.8 提供更新,并且是之前的 Long Term Support (LTS)频道。 -
根据安装 OpenShift Container Platform 集群的时间,您可能还会看到
Alpha
,current
andcurrent-76
等频道,这些频道适用于较旧版本的 AMQ Broker,可以被忽略。
-
在 Installation Mode 下,选择 Operator 监视的命名空间:
- 集群上的特定命名空间 - Operator 已安装在该命名空间中,仅监控该命名空间以了解 CR 更改。
- All namespaces - Operator 会监控所有命名空间以了解 CR 更改。
注意如果您之前使用早期版本的 Operator 部署代理,而您希望部署 Operator 以观察多个命名空间,请参阅升级前的操作。
- 在 Installed Namespace 下拉菜单中选择您要在其中安装 Operator 的项目。
-
在 批准策略 下,确保选择了授权
Automatic
的单选按钮。这个选项指定对 Operator 的更新不需要手动批准才能进行安装。 - 点 Install。
当 Operator 安装完成后,Installed Operators 页将打开。您应该会看到 Red Hat Integration - AMQ Broker for RHEL 8(Multiarch)
Operator 已安装到您指定的项目命名空间中。
其他资源
- 要了解如何在安装了 AMQ Broker 的项目中创建代理部署,请参阅 第 3.4.1 节 “部署基本代理实例”。
3.4. 创建基于 Operator 的代理部署
3.4.1. 部署基本代理实例
以下流程演示了如何使用自定义资源(CR)实例创建基本代理部署。
虽然您可以通过部署多个自定义资源(CR)实例在给定 OpenShift 项目中创建多个代理部署,但通常会在项目中创建单个代理部署,然后为地址部署多个 CR 实例。
红帽建议您在单独的项目中创建代理部署。
在 AMQ Broker 7.10 中,如果要配置以下项目,您必须在第一次部署 CR 前将 适当的配置添加到主代理 CR 实例中。
先决条件
您必须已安装了 AMQ Broker Operator。
- 要使用 OpenShift 命令行界面(CLI)安装 AMQ Broker Operator,请参阅 第 3.2 节 “使用 CLI 安装 Operator”。
- 要使用 OperatorHub 图形界面安装 AMQ Broker Operator,请参阅 第 3.3 节 “使用 OperatorHub 安装 Operator”。
- 您应该了解如何选择用于代理部署的代理容器镜像。更多信息请参阅 第 2.4 节 “Operator 如何选择容器镜像”。
- 从 AMQ Broker 7.3 开始,您可以使用红帽生态系统目录的新版本访问容器镜像。这个 registry 的新版本需要您成为经过身份验证的用户,然后才能访问镜像。在按照本节中的步骤操作前,您必须首先完成 Red Hat Container Registry 身份验证 中描述的步骤。
流程
当您成功安装 Operator 时,Operator 会运行并侦听与 CR 相关的更改。本例的步骤演示了如何使用 CR 实例在项目中部署基本代理。
开始为代理部署配置自定义资源(CR)实例。
使用 OpenShift 命令行界面:
以有权在用于创建部署的项目中部署 CR 的用户身份登录 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在用于创建部署的项目中部署 CR 的用户登录到控制台。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
对于基本的代理部署,配置可能类似以下示例。
apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true
观察到
broker_activemqartemis_cr.yaml
示例 CR 文件中,image
属性设为占位符
默认值。此值表示默认情况下,image
属性不指定用于部署的代理容器镜像。要了解 Operator 如何确定要使用的适当代理容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”。注意broker_activemqartemis_cr.yaml
示例 CR 使用ex-aao
的命名约定。这个命名惯例表示 CR 是 AMQ Broker Operator 的示例 资源。AMQ Broker 基于 ActiveMQ Artemis 项目。部署此示例 CR 时,生成的 StatefulSet 会使用名称ex-aao-s
。另外,部署中的代理 Pod 直接基于 StatefulSet 名称,如ex-aao-s-0
、ex-aao-s-1
等等。CR 中的应用程序名称作为 StatefulSet 上的标签出现在部署中。例如,您可以在 Pod 选择器中使用该标签。-
size
属性指定要部署的代理数量。指定为2
个或更多个集群代理部署。但是,要部署单个代理实例,请确保该值设置为1
。 部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
在 OpenShift Container Platform web 控制台中,点击
→ 。您会看到一个名为ex-aao-ss
的新 StatefulSet。- 点 ex-aao-s StatefulSet。您会看到一个 Pod,对应于您在 CR 中定义的单个代理。
- 在 StatefulSet 中,点 Pods 选项卡。点 ex-aao-ss Pod。在运行 Pod 的 Events 选项卡中,您会看到 broker 容器已启动。Logs 选项卡显示代理本身正在运行。
要测试代理是否正常运行,请访问代理 Pod 中的 shell 来发送一些测试消息。
使用 OpenShift Container Platform Web 控制台:
- 单击 → 。
- 点 ex-aao-ss Pod。
- 点击 Terminal 选项卡。
使用 OpenShift 命令行界面:
获取项目的 Pod 名称和内部 IP 地址。
$ oc get pods -o wide NAME STATUS IP amq-broker-operator-54d996c Running 10.129.2.14 ex-aao-ss-0 Running 10.129.2.15
访问代理 Pod 的 shell。
$ oc rsh ex-aao-ss-0
在 shell 中,使用
artemis
命令发送一些测试消息。在 URL 中指定代理 Pod 的内部 IP 地址。例如:sh-4.2$ ./amq-broker/bin/artemis producer --url tcp://10.129.2.15:61616 --destination queue://demoQueue
以上命令会在代理上自动创建一个名为
demoQueue
的队列,并将默认数量 1000 个消息发送到队列。您应该看到类似如下的输出:
Connection brokerURL = tcp://10.129.2.15:61616 Producer ActiveMQQueue[demoQueue], thread=0 Started to calculate elapsed time ... Producer ActiveMQQueue[demoQueue], thread=0 Produced: 1000 messages Producer ActiveMQQueue[demoQueue], thread=0 Elapsed time in second : 3 s Producer ActiveMQQueue[demoQueue], thread=0 Elapsed time in milli second : 3492 milli seconds
其他资源
- 有关主代理自定义资源(CR)的完整配置引用,请参阅 第 8.1 节 “自定义资源配置参考”。
- 要了解如何将正在运行的代理连接到 AMQ 管理控制台,请参阅 第 5 章 连接到基于 Operator 的代理部署的 AMQ Management Console。
3.4.2. 部署集群代理
如果项目中正在运行两个或多个代理 Pod,Pod 会自动组成代理集群。集群配置可让代理互相连接并根据需要重新分发信息,以进行负载平衡。
以下流程演示了如何部署集群代理。默认情况下,本部署中的代理 需要需要 负载平衡,这意味着代理仅将信息转发给具有匹配消费者的其他代理。
先决条件
- 已部署了基本的代理实例。请参阅 第 3.4.1 节 “部署基本代理实例”。
流程
- 打开用于基本代理部署的 CR 文件。
对于集群的部署,请确保
deploymentPlan.size
的值为2
或更高。例如:apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 4 image: placeholder ...
注意在
metadata
部分中,您需要包含namespace
属性,只有在 使用 OpenShift Container Platform Web 控制台来创建 CR 实例时才指定一个值。您应该指定的值是代理部署的 OpenShift 项目的名称。- 保存修改后的 CR 文件。
以有权在项目中创建基本代理部署的项目中部署 CR 的用户身份登录 OpenShift。
$ oc login -u <user> -p <password> --server=<host:port>
切换到您之前在其中创建基本代理部署的项目。
$ oc project <project_name>
在命令行中应用更改:
$ oc apply -f <path/to/custom_resource_instance>.yaml
在 OpenShift Container Platform Web 控制台中,根据 CR 中指定的数量,其他代理 Pod 会在您的项目中启动。默认情况下,在项目中运行的代理会被集群。
打开每个 Pod 的 Logs 选项卡。日志显示 OpenShift 在每个代理上建立了一个集群连接桥接。具体来说,日志输出包括如下一行:
targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@6f13fb88
3.4.3. 对运行代理部署应用自定义资源更改
以下是对运行代理部署应用自定义资源(CR)更改的一些重要事项:
-
您不能动态更新 CR 中的
persistenceEnabled
属性。要更改此属性,将集群缩减为零的代理。删除现有的 CR。然后,使用您的更改重新创建和重新部署 CR,同时指定部署大小。 -
CR 中的
deploymentPlan.size
属性的值会覆盖您通过oc scale
命令进行代理部署的大小。例如,假设您使用oc scale
将部署的大小从三个代理更改为两个,但 CR 中的deploymentPlan.size
的值仍是3
。在这种情况下,OpenShift 最初会将部署缩减到两个代理。但是,当 scaledown 操作完成后,Operator 会将部署恢复到三个代理(如 CR 中指定的)。 -
如 第 3.2.2 节 “使用 CLI 部署 Operator” 所述,如果您使用持久性存储(即,在 CR 中设置
persistenceEnabled=true
)创建代理部署,您可能需要为 AMQ Broker Operator 置备持久性卷(PV)来声明代理 Pod。如果您缩减代理部署的大小,Operator 会释放之前声明用于关闭的代理 Pod 的 PV。但是,如果您通过删除 CR 来删除代理部署,AMQ Broker Operator 不会为在删除时仍在部署中的代理 Pod 释放 PVC。另外,这些未发布的 PV 在任何新部署中都不可用。在这种情况下,您需要手动释放卷。如需更多信息,请参阅 OpenShift 文档中的 发布持久性卷。 在 AMQ Broker 7.10 中,如果要配置以下项目,您必须在第一次部署 CR 之前,将适当的配置添加到主 CR 实例中。
- 在活跃的扩展事件中,您应用的任何进一步更改都由 Operator 排队,仅在扩展完成后执行。例如,假设您将部署的大小从四个代理缩减为一。然后,当进行缩减时,您也会更改代理管理员用户名和密码的值。在这种情况下,Operator 会将用户名和密码更改排队,直到部署在一个活跃的代理下运行。
-
所有 CR 更改 - 除更改部署的大小外,或更改
expose
属性的值用于接收器、连接器或控制台 - 会导致现有代理重启。如果您的部署中有多个代理,则一次只会重启一个代理。
第 4 章 配置基于 Operator 的代理部署
4.1. Operator 如何生成代理配置
在使用自定义资源(CR)实例配置代理部署前,您应该了解 Operator 如何生成代理配置。
当您创建基于 Operator 的代理部署时,每个代理的 Pod 在 OpenShift 项目中的 StatefulSet 中运行。代理的应用程序容器在每个 Pod 中运行。
在初始化每个 Pod 时,Operator 会创建一个名为 Init 容器的容器。在 OpenShift Container Platform 中,初始容器是应用程序容器之前运行的专用容器。Init 容器可以包含没有存在于应用程序镜像中的实用程序或设置脚本。
默认情况下,AMQ Broker Operator 使用内置的初始容器。Init 容器使用部署的主 CR 实例来生成每个代理应用程序容器使用的配置。
如果您在 CR 中指定了地址设置,Operator 会生成一个默认配置,然后将该配置合并或替换为 CR 中指定的配置。此过程在后面的部分中进行说明。
4.1.1. Operator 如何生成地址设置配置
如果您在部署的主自定义资源(CR)实例中包含地址设置配置,Operator 会为每个代理生成地址设置配置,如下所述。
Operator 在代理应用程序容器前运行 Init 容器。Init 容器生成 默认 地址设置配置。默认地址设置配置如下所示。
<address-settings> <!-- if you define auto-create on certain queues, management has to be auto-create --> <address-setting match="activemq.management#"> <dead-letter-address>DLQ</dead-letter-address> <expiry-address>ExpiryQueue</expiry-address> <redelivery-delay>0</redelivery-delay> <!-- with -1 only the global-max-size is in use for limiting --> <max-size-bytes>-1</max-size-bytes> <message-counter-history-day-limit>10</message-counter-history-day-limit> <address-full-policy>PAGE</address-full-policy> <auto-create-queues>true</auto-create-queues> <auto-create-addresses>true</auto-create-addresses> <auto-create-jms-queues>true</auto-create-jms-queues> <auto-create-jms-topics>true</auto-create-jms-topics> </address-setting> <!-- default for catch all --> <address-setting match="#"> <dead-letter-address>DLQ</dead-letter-address> <expiry-address>ExpiryQueue</expiry-address> <redelivery-delay>0</redelivery-delay> <!-- with -1 only the global-max-size is in use for limiting --> <max-size-bytes>-1</max-size-bytes> <message-counter-history-day-limit>10</message-counter-history-day-limit> <address-full-policy>PAGE</address-full-policy> <auto-create-queues>true</auto-create-queues> <auto-create-addresses>true</auto-create-addresses> <auto-create-jms-queues>true</auto-create-jms-queues> <auto-create-jms-topics>true</auto-create-jms-topics> </address-setting> <address-settings>
- 如果您在自定义资源(CR)实例中指定了地址设置配置,Init 容器进程会进行配置并将其转换为 XML。
-
根据 CR 中的
applyRule
属性的值,Init 容器 合并 或者将 上面显示的默认地址设置配置替换为您在 CR 中指定的配置。这种合并或替换后是代理将使用的最终地址设置配置。 -
当 Init 容器完成生成代理配置(包括地址设置)时,代理应用程序容器会启动。开始时,代理容器会复制之前由 Init 容器使用的安装目录中的配置。您可以检查
broker.xml
配置文件中的地址设置配置。对于正在运行的代理,这个文件位于/home/jboss/amq-broker/etc
目录中。
其他资源
-
有关在 CR 中使用
applyRule
属性的示例,请参阅 第 4.2.3 节 “将地址设置与基于 Operator 的代理部署中配置的地址匹配”。
4.1.2. 代理 Pod 的目录结构
当您创建基于 Operator 的代理部署时,每个代理的 Pod 在 OpenShift 项目中的 StatefulSet 中运行。代理的应用程序容器在每个 Pod 中运行。
在初始化每个 Pod 时,Operator 会创建一个名为 Init 容器的容器。在 OpenShift Container Platform 中,初始容器是应用程序容器之前运行的专用容器。Init 容器可以包含没有存在于应用程序镜像中的实用程序或设置脚本。
在为代理实例生成配置时,Init 容器将使用默认安装目录中包含的文件。这个安装目录位于 Operator 挂载到代理 Pod 的卷中,以及 Init Container 和 broker 容器共享。Init 容器用来挂载共享卷的路径在名为 CONFIG_INSTANCE_DIR
的环境变量中定义。CONFIG_INSTANCE_DIR
的默认值为 /amq/init/config
。在文档中,此目录被称为 < install_dir>
。
您无法更改 CONFIG_INSTANCE_DIR
环境变量的值。
默认情况下,安装目录有以下子目录:
子目录 | 内容 |
---|---|
| 运行代理所需的二进制文件和脚本。 |
| 配置文件. |
| 代理日志。 |
| 运行代理所需的 JAR 和库。 |
| 代理日志文件。 |
| 临时 Web 应用文件。 |
当 Init 容器完成生成代理配置后,代理应用程序容器会启动。开始时,代理容器会复制之前由 Init 容器使用的安装目录中的配置。当代理 Pod 初始化并运行时,代理配置位于代理的 /home/jboss/amq-broker
目录中(和子目录)。
其他资源
- 如需有关 Operator 如何为内置 Init 容器选择容器镜像的更多信息,请参阅 第 2.4 节 “Operator 如何选择容器镜像”。
- 要了解如何构建和指定自定义初始容器镜像,请参阅 第 4.7 节 “指定自定义 Init 容器镜像”。
4.2. 为基于 Operator 的代理部署配置地址和队列
对于基于 Operator 的代理部署,您可以使用两个独立的自定义资源(CR)实例来配置地址和队列及其相关设置。
要在代理中创建地址和队列,您需要根据地址自定义资源定义(CRD)部署 CR 实例。
-
如果您使用 OpenShift 命令行界面(CLI)安装 Operator,则地址 CRD 是您下载并提取的 Operator 安装的
deploy/crds
中的broker_activemqartemisaddress_crd.yaml
文件。 -
如果使用 OperatorHub 安装 Operator,则地址 CRD 是 OpenShift Container Platform Web 控制台中的
ActiveMQAretmisAddress
CRD。 → 下列出的
-
如果您使用 OpenShift 命令行界面(CLI)安装 Operator,则地址 CRD 是您下载并提取的 Operator 安装的
要配置与特定地址匹配的地址和队列设置,您可以在用于创建代理部署的主自定义资源(CR)实例中包含配置。
-
如果您使用 OpenShift CLI 安装 Operator,则主代理 CRD 是您下载并提取的 Operator 安装的
deploy/crds
中的broker_activemqartemis_crd.yaml
文件。 -
如果使用 OperatorHub 安装 Operator,则主代理 CRD 是 OpenShift Container Platform Web 控制台中的
ActiveMQAretmis
CRD。 → 下列出的
通常,您可以为 OpenShift Container Platform 上的代理部署配置的地址和队列设置,完全相当于 Linux 或 Windows 上的独立代理部署。但是,您应该注意,这些设置是如何配置的一些变化。这些差别在以下子部分进行描述。
-
如果您使用 OpenShift CLI 安装 Operator,则主代理 CRD 是您下载并提取的 Operator 安装的
4.2.1. OpenShift 和独立代理部署之间配置地址和队列设置的不同
-
要为 OpenShift Container Platform 上代理部署配置地址和队列设置,您需要将配置添加到代理部署的主自定义资源(CR)实例的
addressSettings
部分中。这与 Linux 或 Windows 中的独立部署进行比较,您已将配置添加到broker.xml
配置文件中的address-settings
元素中。 OpenShift Container Platform 和独立代理部署间的配置项名称的格式不同。对于 OpenShift Container Platform 部署,配置项名称位于 camel case 中,如
defaultQueueRoutingType
。相反,独立部署的配置项名称是小写并使用横线(-
)分隔符,例如default-queue-routing-type
。下表显示了这种命名差别的一些更多示例。
独立代理部署的配置项 OpenShift 代理部署的配置项 address-full-policy
addressFullPolicy
auto-create-queues
autoCreateQueues
default-queue-routing-type
defaultQueueRoutingType
last-value-queue
lastValueQueue
其他资源
有关为 OpenShift Container Platform 代理部署创建地址和队列及匹配设置的示例,请参阅:
- 要了解 OpenShift Container Platform 代理部署的地址、队列和地址设置的所有配置选项,请参阅 第 8.1 节 “自定义资源配置参考”。
- 有关为独立代理部署配置地址、队列和相关地址设置的详细信息,请参阅配置 AMQ Broker 中的配置地址和队列。您可以使用这些信息为 OpenShift Container Platform 上的代理部署创建等效的配置。
4.2.2. 为基于 Operator 的代理部署创建地址和队列
以下流程演示了如何使用自定义资源(CR)实例将地址和相关队列添加到基于 Operator 的代理部署中。
要在代理部署中创建多个地址和/或队列,您需要创建单独的 CR 文件并单独部署,在每个情况下指定新地址和/或队列名称。另外,每个 CR 实例的 name
属性必须是唯一的。
先决条件
您必须已安装 AMQ Broker Operator,包括在您的代理上创建地址和队列所需的专用自定义资源定义(CRD)。有关安装 Operator 的两种替代方法的详情,请参考:
- 您应该熟悉如何使用 CR 实例创建基本代理部署。更多信息请参阅 第 3.4.1 节 “部署基本代理实例”。
流程
开始配置自定义资源(CR)实例,以定义代理部署的地址和队列。
使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemisaddress_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 根据地址 CRD 启动新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemisAddresss CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemisAddress。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
在 CR 的
spec
部分,添加行来定义地址、队列和路由类型。例如:apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemisAddress metadata: name: myAddressDeployment0 namespace: myProject spec: ... addressName: myAddress0 queueName: myQueue0 routingType: anycast ...
上述配置定义了名为
myAddress0
的地址,其队列名为myQueue0
,以及任何广播
路由类型。注意在
metadata
部分中,您需要包含namespace
属性,只有在 使用 OpenShift Container Platform Web 控制台来创建 CR 实例时才指定一个值。您应该指定的值是代理部署的 OpenShift 项目的名称。部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/address_custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
(可选)若要使用 CR 实例删除之前添加到部署的地址和队列,请使用以下命令:
$ oc delete -f <path/to/address_custom_resource_instance>.yaml
4.2.3. 将地址设置与基于 Operator 的代理部署中配置的地址匹配
如果向客户端发送一条消息失败,您可能不希望代理进行持续尝试传递消息。要防止有限发送尝试,您可以定义 死信地址和 一个关联的 死信队列。在指定的发送尝试次数后,代理会从其原始队列中删除未发送的消息,并将消息发送到配置的死信地址。系统管理员可以在以后消耗来自死信队列的未发送的消息来检查消息。
以下示例演示了如何为基于 Operator 的代理部署配置死信地址和队列。以下示例演示了如何进行:
-
使用主代理自定义资源(CR)实例的
addressSetting
部分来配置地址设置。 - 将这些地址设置与代理部署中的地址匹配。
先决条件
- 您应该熟悉如何使用 CR 实例创建基本代理部署。更多信息请参阅 第 3.4.1 节 “部署基本代理实例”。
- 您应该熟悉 Operator 合并或替换为 CR 实例中指定的配置 的默认 地址设置配置。更多信息请参阅 第 4.1.1 节 “Operator 如何生成地址设置配置”。
流程
开始配置 CR 实例,以添加死信地址和队列,以接收部署中的每个代理的消息。
使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemisaddress_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 根据地址 CRD 启动新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemisAddresss CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemisAddress。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
在 CR 的
spec
部分,添加行以指定死信地址和队列以接收未传输的消息。例如:apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemisAddress metadata: name: ex-aaoaddress spec: ... addressName: myDeadLetterAddress queueName: myDeadLetterQueue routingType: anycast ...
上述配置定义了一个名为
myDeadLetterAddress
的死信地址,其死信队列为myDeadLetterQueue
和anycast
路由类型。注意在
metadata
部分中,您需要包含namespace
属性,只有在 使用 OpenShift Container Platform Web 控制台来创建 CR 实例时才指定一个值。您应该指定的值是代理部署的 OpenShift 项目的名称。部署地址 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到代理部署的项目。
$ oc project <project_name>
创建地址 CR。
$ oc create -f <path/to/address_custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
启动为代理部署配置自定义资源(CR)实例。
在示例 CR 文件中:
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
-
打开名为
使用 OpenShift Container Platform Web 控制台:
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
对于基本的代理部署,配置可能类似以下示例。
apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true
观察到
broker_activemqartemis_cr.yaml
示例 CR 文件中,image
属性设为占位符
默认值。此值表示默认情况下,image
属性不指定用于部署的代理容器镜像。要了解 Operator 如何确定要使用的适当代理容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”。注意在
metadata
部分中,您需要包含namespace
属性,只有在 使用 OpenShift Container Platform Web 控制台来创建 CR 实例时才指定一个值。您应该指定的值是代理部署的 OpenShift 项目的名称。在 CR 的
deploymentPlan
部分中,添加一个包含单个addressSetting
部分的新addressSettings
部分,如下所示。spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true addressSettings: addressSetting:
将
match
属性的单个实例添加到addressSetting
块。指定地址匹配表达式。例如:spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true addressSettings: addressSetting: - match: myAddress
匹配
-
指定代理将配置应用到的地址 或一组 地址。在本例中,
match
属性的值与一个名为myAddress
的单个地址对应。
添加与未传输的消息相关的属性并指定值。例如:
spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true addressSettings: addressSetting: - match: myAddress deadLetterAddress: myDeadLetterAddress maxDeliveryAttempts: 5
deadLetterAddress
- 代理发送未接收的消息的地址。
maxDeliveryAttempts
代理在将消息移动到配置的死信地址前进行的最大交付尝试数。
在前面的示例中,如果代理失败试图将消息发送到以
myAddress
开头的地址,代理会将消息移到指定的死信地址myDeadLetterAddress
中。
(可选)将类似的配置应用到另一个地址或一组地址。例如:
spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true addressSettings: addressSetting: - match: myAddress deadLetterAddress: myDeadLetterAddress maxDeliveryAttempts: 5 - match: 'myOtherAddresses*' deadLetterAddress: myDeadLetterAddress maxDeliveryAttempts: 3
在本例中,第二个
match
属性的值包含一个星号通配符。通配符字符表示上述配置应用于以字符串myOtherAddresses
开头的任何地址。注意如果您使用通配符表达式作为
match
属性的值,则必须将值放在单引号中,如'myOtherAddresses*'
。在
addressSettings
部分的开头,添加applyRule
属性并指定一个值。例如:spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true addressSettings: applyRule: merge_all addressSetting: - match: myAddress deadLetterAddress: myDeadLetterAddress maxDeliveryAttempts: 5 - match: 'myOtherAddresses*' deadLetterAddress: myDeadLetterAddress maxDeliveryAttempts: 3
applyRule
属性指定 Operator 如何为每个匹配地址或一组地址应用您添加到 CR 的配置。您可以指定的值有:merge_all
对于 CR 中指定的地址设置,以及 符合相同地址或一组地址的默认配置:
- 将默认配置中指定的任何属性值替换为 CR 中指定的值。
- 保留在 CR 或 默认配置中指定的任何属性值。请在最终合并的配置中包含其中之一。
- 对于在 CR 中指定的地址设置,或者唯一匹配一个特定地址或一组地址的默认配置,将它们包括在最终合并的配置中。
merge_replace
- 对于 CR 中指定的地址设置,以及 符合相同地址或一组地址的默认配置,请将 CR 中指定的设置包括在最终合并的配置中。不要 包括默认配置中指定的任何属性,即使 CR 中没有指定这些属性。
- 对于在 CR 中指定的地址设置,或者唯一匹配一个特定地址或一组地址的默认配置,将它们包括在最终合并的配置中。
replace_all
- 使用在 CR 中指定的内容替换默认配置中指定的所有地址设置最后,合并的配置与 CR 中指定的完全相同。
注意如果您没有在 CR 中明确包含
applyRule
属性,Operator 将使用默认值merge_all
。部署代理 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
创建 CR 实例。
$ oc create -f <path/to/broker_custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
其他资源
- 要了解 OpenShift Container Platform 代理部署的地址、队列和地址设置的所有配置选项,请参阅 第 8.1 节 “自定义资源配置参考”。
如果您使用 OpenShift 命令行界面(CLI)安装 AMQ Broker Operator,则您下载并提取了一些额外的配置地址设置示例。在安装归档的
deploy/examples
文件夹中,请参阅:-
artemis-basic-address-settings-deployment.yaml
-
artemis-merge-replace-address-settings-deployment.yaml
-
artemis-replace-address-settings-deployment.yaml
-
- 有关为独立代理部署配置地址、队列和相关地址设置的详细信息,请参阅配置 AMQ Broker 中的配置地址和队列。您可以使用这些信息为 OpenShift Container Platform 上的代理部署创建等效的配置。
- 如需有关 OpenShift Container Platform 中初始容器的更多信息,请参阅 OpenShift Container Platform 文档中的 部署 pod 前使用初始容器执行任务。
4.3. 为基于 Operator 的代理部署创建安全配置
4.3.1. 为基于 Operator 的代理部署创建安全配置
以下流程演示了如何使用自定义资源(CR)实例将用户和关联的安全配置添加到基于 Operator 的代理部署中。
先决条件
您必须已安装了 AMQ Broker Operator。有关安装 Operator 的两种替代方法的详情,请参考:
- 您应该熟悉代理安全,如安全 代理所述
- 您应该熟悉如何使用 CR 实例创建基本代理部署。更多信息请参阅 第 3.4.1 节 “部署基本代理实例”。
您可以在创建代理部署前或之后部署安全 CR。但是,如果您在创建代理部署后部署安全 CR,代理 Pod 将重启来接受新配置。
开始配置自定义资源(CR)实例,以定义代理部署的用户和相关安全配置。
使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemissecurity_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 根据地址 CRD 启动新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemisSecurity CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemisSecurity。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
在 CR 的
spec
部分,添加行来定义用户和角色。例如:apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemisSecurity metadata: name: ex-prop spec: loginModules: propertiesLoginModules: - name: "prop-module" users: - name: "sam" password: "samspassword" roles: - "sender" - name: "rob" password: "robspassword" roles: - "receiver" securityDomains: brokerDomain: name: "activemq" loginModules: - name: "prop-module" flag: "sufficient" securitySettings: broker: - match: "#" permissions: - operationType: "send" roles: - "sender" - operationType: "createAddress" roles: - "sender" - operationType: "createDurableQueue" roles: - "sender" - operationType: "consume" roles: - "receiver" ...
注意始终为上例中的元素指定值。例如,如果没有为 role 指定
securityDomains.brokerDomain
或 values 的值,则生成的配置可能会导致意外结果。上述配置定义了两个用户:
-
名为
prop-module
的propertiesLoginModule
定义一个名为sam
的用户,角色名为sender
。 -
名为
prop-module
的propertiesLoginModule
,它定义名为rob
的角色以及名为receiver
的角色。
这些角色的属性在
securityDomains
的brokerDomain
和broker
部分中定义。例如,定义了send
角色,以允许具有该角色的用户在任何地址上创建持久队列。默认情况下,配置会应用到当前命名空间中 CR 定义的所有已部署代理。要将配置限制为特定的代理部署,请使用 第 8.1.3 节 “安全自定义资源配置参考” 中描述的applyToCrNames
选项。注意在
metadata
部分中,您需要包含namespace
属性,只有在 使用 OpenShift Container Platform Web 控制台来创建 CR 实例时才指定一个值。您应该指定的值是代理部署的 OpenShift 项目的名称。-
名为
部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/address_custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
4.3.2. 将用户密码存储在 secret 中
在 为基于 Operator 的代理部署流程创建安全配置中,用户密码存储在 ActiveMQArtemisSecurity
CR 中的明文中。如果您不想在 CR 中以明文形式存储密码,您可以从 CR 中排除密码并将其存储在 secret 中。应用 CR 时,Operator 会从 secret 检索每个用户的密码,并将它插入到代理 pod 的 artemis-users.properties
文件中。
流程
使用
oc create secret
命令创建 secret,并添加每个用户名和密码。secret 名称必须遵循security-properties-module name
的命名约定,其中 module name 是 CR 中配置的登录模块的名称。例如:oc create secret generic security-properties-prop-module \ --from-literal=sam=samspassword \ --from-literal=rob=robspassword
在 CR 的
spec
部分中,添加您在 secret 中指定的用户名以及角色信息,但不包括每个用户的密码。例如:apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemisSecurity metadata: name: ex-prop spec: loginModules: propertiesLoginModules: - name: "prop-module" users: - name: "sam" roles: - "sender" - name: "rob" roles: - "receiver" securityDomains: brokerDomain: name: "activemq" loginModules: - name: "prop-module" flag: "sufficient" securitySettings: broker: - match: "#" permissions: - operationType: "send" roles: - "sender" - operationType: "createAddress" roles: - "sender" - operationType: "createDurableQueue" roles: - "sender" - operationType: "consume" roles: - "receiver" ...
部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/address_custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 完成配置 CR 后,点 Create。
其他资源
如需有关 OpenShift Container Platform 中 secret 的更多信息,请参阅 OpenShift Container Platform 文档中的 向 pod 提供敏感数据。
4.4. 配置代理存储要求
要在基于 Operator 的代理部署中使用持久性存储,您可以在用于创建部署的自定义资源(CR)实例中将 persistenceEnabled
设置为 true
。如果您的 OpenShift 集群中没有容器原生虚拟化,则需要手动置备持久性卷(PV),并确保 Operator 可以使用持久性卷声明(PVC)来声明它们。如果您想创建一个有两个带有持久性存储的代理集群,例如,您需要有两个 PV 可用。
当您在 OpenShift Container Platform 中手动置备 PV 时,请确保将每个 PV 的重新声明策略设置为 Retain
。如果 PV 的重新声明策略没有设置为 Retain
,并且 Operator 用于声明 PV 的 PVC 会被删除,则 PV 也会被删除。删除 PV 会导致卷上任何数据丢失。如需更多信息,请参阅 OpenShift Container Platform 文档中的了解持久性存储。
默认情况下,PVC 从为集群配置的默认存储类获取每个代理的 2 GiB 存储。您可以覆盖 PVC 中请求的默认大小和存储类,但仅在首次部署 CR 前 在 CR 中配置新值。
4.4.1. 配置代理存储大小和存储类
以下流程演示了如何为代理部署配置自定义资源(CR)实例,以指定每个用于持久性消息存储所需的持久性卷声明(PVC)的大小和存储类。
在首次部署 CR 之前,您必须将代理存储大小和存储类的配置添加到代理部署的主 CR 中。您无法将 配置添加到已在运行的代理部署中。
先决条件
- 您应该熟悉如何使用 CR 实例创建基本代理部署。请参阅 第 3.4.1 节 “部署基本代理实例”。
您必须已经置备持久性卷(PV),并由 Operator 声明这些持久性卷(PV)。例如,如果要创建带有持久性存储的两个代理集群,则需要有两个 PV 可用。
如需有关置备持久性存储的更多信息,请参阅 OpenShift Container Platform 文档中的了解持久性存储。
流程
开始为代理部署配置自定义资源(CR)实例。
使用 OpenShift 命令行界面:
以有权在用于创建部署的项目中部署 CR 的用户身份登录 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在用于创建部署的项目中部署 CR 的用户登录到控制台。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
对于基本的代理部署,配置可能类似以下示例。
apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true
观察到
broker_activemqartemis_cr.yaml
示例 CR 文件中,image
属性设为占位符
默认值。此值表示默认情况下,image
属性不指定用于部署的代理容器镜像。要了解 Operator 如何确定要使用的适当代理容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”。要指定代理存储大小,在 CR 的
deploymentPlan
部分中添加storage
部分。添加size
属性并指定值。例如:spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true storage: size: 4Gi
storage.size
-
每个代理 Pod 需要用于持久性存储的持久性卷声明(PVC)大小(以字节为单位)。此属性仅在将
persistenceEnabled
设为true
时才适用。您指定的值 必须使用 字节表示法(例如 K、M、G)或者二进制等同的单元(Ki、Mi、Gi)。
要在
storage
部分指定每个代理 Pod 需要持久性存储的存储类,请添加storageClassName
属性并指定值。例如:spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true storage: size: 4Gi storageClassName: gp3
storage.storageClassName
在持久性卷声明(PVC)中请求的存储类的名称。存储类为管理员提供描述和分类可用存储的方法。例如,不同的存储类可能会映射到特定的服务质量级别、备份策略等。
如果没有指定存储类,则 PVC 声明具有为集群配置的默认存储类的持久性卷。
注意如果您指定了存储类,只有在卷的存储类与指定的存储类匹配时,PVC 才会声明持久性卷。
部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
4.5. 为基于 Operator 的代理部署配置资源限值和请求
创建基于 Operator 的代理部署时,部署中的代理 Pod 在 OpenShift 集群中的节点中运行。您可以为部署配置自定义资源(CR)实例,以指定每个 Pod 中运行的代理容器使用的 host-node 计算资源。通过为 CPU 和内存(RAM)指定限制和请求值,您可以确保代理 Pod 的性能不满意。
- 您必须先为代理部署的 CR 实例添加限制和请求的配置,然后再 第一次部署 CR。您无法将 配置添加到已在运行的代理部署中。
- 红帽无法为限制和请求推荐值,因为这些值取决于您的具体消息传递系统用例以及您实施的结果架构。但是,建议您在 为生产环境配置前测试和调整开发环境中的这些值。
- 在初始化每个代理 Pod 时,Operator 会创建一个名为 Init 容器的容器。每个代理容器配置的任何资源限值和请求也适用于每个初始容器。有关在代理部署中使用初始容器的更多信息,请参阅 第 4.1 节 “Operator 如何生成代理配置”。
您可以指定以下限制和请求值:
CPU 限制
- 对于 Pod 中运行的每个代理容器,这个值是容器可以消耗的 host-node CPU 的最大数量。如果代理容器尝试超过指定的 CPU 限制,OpenShift 会节流容器。这样可确保容器具有一致的性能,无论节点上运行的 Pod 数量是什么。
内存限制
- 对于 Pod 中运行的每个代理容器,这个值是容器可以使用的最大主机节点内存量。如果代理容器尝试超过指定的内存限值,OpenShift 会终止容器。代理 Pod 重启。
CPU 请求
对于 Pod 中运行的每个代理容器,这个值是容器请求的 host-node CPU 量。OpenShift 调度程序在 Pod 放置过程中考虑 CPU 请求值,以将代理 Pod 绑定到具有足够计算资源的节点。
CPU 请求值是代理容器运行 的最小 CPU 量。但是,如果节点上没有 CPU 争用,容器可以使用所有可用的 CPU。如果指定了 CPU 限制,则容器不能超过该 CPU 用量。如果节点上有 CPU 争用,则 CPU 请求值提供了一种方法来让 OpenShift 消耗所有容器的 CPU 用量。
内存请求
对于 Pod 中运行的每个代理容器,这个值是容器请求的 host-node 内存量。OpenShift 调度程序在 Pod 放置过程中会考虑内存请求值,将代理 Pod 绑定到具有足够计算资源的节点。
内存请求值是代理容器运行 的最小内存量。但是,容器可以尽可能消耗可用内存。如果指定了内存限制,则代理容器不能超过该内存用量。
CPU 以名为 millicores 的单位来衡量。OpenShift 集群中的每个节点检查操作系统,以确定节点上的 CPU 内核数。然后,节点将该值乘以 1000 以表示总容量。例如,如果节点有两个内核,则节点的 CPU 容量显示为 2000m
。因此,如果您使用一个核心的单位,则指定一个值 100m
。
内存单位为字节。您可以使用字节表示法(E、P、T、G、M、K)或二进制等同值(Ei、Pi、Ti、Gi、Mi、Ki)。您指定的值必须包含一个单元。
4.5.1. 配置代理资源限制和请求
以下示例演示了如何为代理部署配置主自定义资源(CR)实例,以便为部署中的 Pod 中运行的每个代理容器设置 CPU 和内存的限值和请求。
- 您必须先为代理部署的 CR 实例添加限制和请求的配置,然后再 第一次部署 CR。您无法将 配置添加到已在运行的代理部署中。
- 红帽无法为限制和请求推荐值,因为这些值取决于您的具体消息传递系统用例以及您实施的结果架构。但是,建议您在 为生产环境配置前测试和调整开发环境中的这些值。
先决条件
- 您应该熟悉如何使用 CR 实例创建基本代理部署。请参阅 第 3.4.1 节 “部署基本代理实例”。
流程
开始为代理部署配置自定义资源(CR)实例。
使用 OpenShift 命令行界面:
以有权在用于创建部署的项目中部署 CR 的用户身份登录 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在用于创建部署的项目中部署 CR 的用户登录到控制台。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
对于基本的代理部署,配置可能类似以下示例。
apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true
观察到
broker_activemqartemis_cr.yaml
示例 CR 文件中,image
属性设为占位符
默认值。此值表示默认情况下,image
属性不指定用于部署的代理容器镜像。要了解 Operator 如何确定要使用的适当代理容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”。在 CR 的
deploymentPlan
部分中,添加一个resources
部分。添加limits
和requests
子项。在每个子部分中,添加一个cpu
和memory
属性并指定值。例如:spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true resources: limits: cpu: "500m" memory: "1024M" requests: cpu: "250m" memory: "512M"
limits.cpu
- 在部署 Pod 中运行的每个代理容器都不能超过此数量 host-node CPU 用量。
limits.memory
- 在部署 Pod 中运行的每个代理容器都不能超过此数量的主机节点内存用量。
requests.cpu
- 在部署 Pod 中运行的每个代理容器都会请求这个数量 host-node CPU。这个值是代理容器运行 所需的最小 CPU 量。
requests.memory
- 在部署 Pod 中运行的每个代理容器都会请求这个数量的主机节点内存。这个值是代理容器运行所需的 最小内存量。
部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
4.6. 覆盖代理的默认内存限值
您可以覆盖为代理设置的默认内存限值。默认情况下,代理被分配一个一半内存,内存可用于代理的 Java 虚拟机。以下流程演示了如何为代理部署配置自定义资源(CR)实例以覆盖默认内存限值。
先决条件
- 您应该熟悉如何使用 CR 实例创建基本代理部署。请参阅 第 3.4.1 节 “部署基本代理实例”。
流程
开始配置自定义资源(CR)实例以创建基本代理部署。
使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
例如,基本代理部署的 CR 可能类似以下:
apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true
在 CR 的
spec
部分,添加一个brokerProperties
部分。在brokerProperties
部分中,添加一个globalMaxSize
属性并指定内存限制。例如:spec: ... brokerProperties: - globalMaxSize=500m ...
globalMaxSize
属性的默认单元是字节。要更改默认单元,请将 m(for MB)或 g(用于 GB)的后缀添加到值。将更改应用到 CR。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到代理部署的项目。
$ oc project <project_name>
应用 CR。
$ oc apply -f <path/to/broker_custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 编辑完 CR 后,点 Save。
(可选)验证您为
globalMaxSize
属性设置的新值会覆盖分配给代理的默认内存限值。- 连接到 AMQ 管理控制台。更多信息请参阅 第 5 章 连接到基于 Operator 的代理部署的 AMQ Management Console。
- 从菜单中,选择 JMX。
- 选择 org.apache.activemq.artemis。
-
搜索
全局
。 -
在显示的表中,确认 Global max 列中的值与您为
globalMaxSize
属性配置的值相同。
4.7. 指定自定义 Init 容器镜像
如 第 4.1 节 “Operator 如何生成代理配置” 所述,AMQ Broker Operator 使用默认内置初始容器来生成代理配置。要生成配置,初始容器将主自定义资源(CR)实例用于您的部署。您可以在 CR 中指定的 唯一 项目是主代理自定义资源定义(CRD)中公开的项目。
然而,在有些情况下,您需要包含 未在 CRD 中未 公开的配置。在这种情况下,您可以在主 CR 实例中 指定自定义 Init 容器。自定义 Init 容器可以修改或添加到由 Operator 创建的配置中。例如,您可以使用自定义 Init 容器来修改代理日志记录设置。或者,您可以使用自定义 Init 容器在代理安装目录中包含额外的运行时依赖项(即 .jar
文件)。
在构建自定义初始容器镜像时,您必须遵循以下重要准则:
在为自定义镜像创建的构建脚本(例如,Docker Dockerfile 或 Podman Containerfile)中,
FROM
指令必须指定 AMQ Broker Operator 内置初始容器作为基础镜像的最新版本。在脚本中包含以下行:FROM registry.redhat.io/amq7/amq-broker-init-rhel8:7.10
-
自定义镜像必须包含一个名为
post-config.sh
的脚本,此脚本包含在名为/amq/scripts
的目录中。post-config.sh
脚本是您修改或添加到 Operator 生成的初始配置中。当您指定自定义 Init Container 时,Operator 在使用 CR 实例生成配置后,但在启动代理应用程序容器前运行post-config.sh
脚本。 -
如 第 4.1.2 节 “代理 Pod 的目录结构” 所述,初始容器使用的安装目录的路径在名为
CONFIG_INSTANCE_DIR
的环境变量中定义。post-config.sh
脚本在引用安装目录时应使用此环境变量名称(例如:${CONFIG_INSTANCE_DIR}/lib
) 而不是 此变量的实际值(如/amq/init/config/lib
)。 -
如果要在自定义代理配置中包含其他资源(如
.xml
或.jar
文件),您必须确保它们已包含在自定义镜像中,并可以被post-config.sh
脚本访问。
以下流程描述了如何指定自定义初始容器镜像。
先决条件
- 您必须构建了一个符合上述指南的自定义 Init 容器镜像。有关为 mlxCloud Operator 构建和指定自定义 Init 容器镜像的完整示例,请参阅 基于 JDBC 的持久性的自定义 Init 容器镜像。
- 要为 AMQ Broker Operator 提供自定义 Init 容器镜像,您需要将镜像添加到容器 registry 中的存储库中,如 Quay 容器 registry。
- 您应该了解 Operator 如何使用初始容器来生成代理配置。更多信息请参阅 第 4.1 节 “Operator 如何生成代理配置”。
- 您应该熟悉如何使用 CR 创建代理部署。更多信息请参阅 第 3.4 节 “创建基于 Operator 的代理部署”。
流程
开始为代理部署配置自定义资源(CR)实例。
使用 OpenShift 命令行界面:
以有权在用于创建部署的项目中部署 CR 的用户身份登录 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在用于创建部署的项目中部署 CR 的用户登录到控制台。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
对于基本的代理部署,配置可能类似以下示例。
apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 1 image: placeholder requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true
观察到
broker_activemqartemis_cr.yaml
示例 CR 文件中,image
属性设为占位符
默认值。此值表示默认情况下,image
属性不指定用于部署的代理容器镜像。要了解 Operator 如何确定要使用的适当代理容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”。在 CR 的
deploymentPlan
部分中,添加initImage
属性。apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 1 image: placeholder initImage: requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true
将
initImage
属性的值设置为自定义初始容器镜像的 URL。apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 1 image: placeholder initImage: <custom_init_container_image_url> requireLogin: false persistenceEnabled: true journalType: nio messageMigration: true
initImage
- 指定自定义初始容器镜像的完整 URL,您必须添加到容器 registry 中的存储库中。
部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
其他资源
- 有关为 mlxCloud Operator 构建和指定自定义 Init 容器镜像的完整示例,请参阅 基于 JDBC 的持久性的自定义 Init 容器镜像。
4.8. 为客户端连接配置基于 Operator 的代理部署
4.8.1. 配置接收器
要在 OpenShift 部署中启用到代理 Pod 的客户端连接,为部署定义 acceptors。acceptors 定义代理 Pod 如何接受连接。您可以在用于代理部署的主自定义资源(CR)中定义接收器。当您创建接受器时,您可以指定要启用接收器的信息,以及用于这些协议的代理 Pod 上的端口。
以下流程演示了如何在 CR 中为代理部署定义新的接受者。
流程
-
在初始安装过程中下载并提取的 Operator 归档中的
deploy/crs
目录中,打开broker_activemqartemis_cr.yaml
自定义资源(CR)文件。 在
acceptors
元素中,添加命名的 acceptor。添加protocols
和port
参数。设置值,以指定接受者使用的消息传递协议,以及每个代理 Pod 上的端口来公开这些协议。例如:spec: ... acceptors: - name: my-acceptor protocols: amqp port: 5672 ...
配置的接受器将端口 5672 公开给 AMQP 客户端。您可以在表中显示您可以为 protocol
参数指定
的完整值。协议 值 核心协议
core
AMQP
amqp
OpenWire
OpenWire
MQTT
mqtt
STOMP
STOMP
所有支持的协议
all
注意- 对于部署中的每个代理 Pod,Operator 还会创建一个使用端口 61616 的默认接受器。代理集群需要这个默认接受器,并启用了 Core Protocol。
- 默认情况下,AMQ Broker 管理控制台使用代理 Pod 上的端口 8161。部署中的每个代理 Pod 都有一个专用的服务,它提供对控制台的访问。更多信息请参阅 第 5 章 连接到基于 Operator 的代理部署的 AMQ Management Console。
要在同一接收器中使用另一个协议,请修改
protocol
参数。指定以逗号分隔的协议列表。例如:spec: ... acceptors: - name: my-acceptor protocols: amqp,openwire port: 5672 ...
配置的接收器现在将端口 5672 公开给 AMQP 和 OpenWire 客户端。
要指定接受器允许的并发客户端连接数量,请添加
connectionAllowed
参数并设置值。例如:spec: ... acceptors: - name: my-acceptor protocols: amqp,openwire port: 5672 connectionsAllowed: 5 ...
默认情况下,接受者仅公开给与代理部署相同的 OpenShift 集群中的客户端。要也会将接受者公开给 OpenShift 之外的客户端,请添加
expose
参数,并将值设为true
。spec: ... acceptors: - name: my-acceptor protocols: amqp,openwire port: 5672 connectionsAllowed: 5 expose: true ... ...
当您向 OpenShift 外部的客户端公开接收器时,Operator 会自动为部署中的每个代理 Pod 创建一个专用的服务和路由。
要启用与 OpenShift 外部客户端的接受器的安全连接,请添加
sslEnabled
参数,并将值设为true
。spec: ... acceptors: - name: my-acceptor protocols: amqp,openwire port: 5672 connectionsAllowed: 5 expose: true sslEnabled: true ... ...
当您启用 SSL(即,安全套接字层)安全性在接收器(或连接器)安全性时,您可以添加相关的配置,例如:
- 用于在 OpenShift 集群中存储身份验证凭据的机密名称。当您在 acceptor 上启用 SSL 时,需要一个 secret。有关生成此 secret 的更多信息,请参阅 第 4.8.2 节 “保护 broker-client 连接”。
-
用于安全网络通信的传输层安全(TLS)协议。TLS 是一个更新的、更加安全的 SSL 版本。您在
enabledProtocols
参数中指定 TLS 协议。 -
接收器是否在代理和客户端之间使用双向 TLS(也称为 mutual 身份验证 )。您可以通过将
needClientAuth
参数的值设置为true
来指定。
其他资源
- 了解如何配置 TLS 来保护代理客户端连接,包括生成 secret 来存储身份验证凭据,请参阅 第 4.8.2 节 “保护 broker-client 连接”。
- 有关完整的自定义资源配置参考,包括配置接收器和连接器,请参阅 第 8.1 节 “自定义资源配置参考”。
4.8.2. 保护 broker-client 连接
如果您在接受者或连接器上启用了安全性(即,将 sslEnabled
设为 true
),您必须配置传输层安全(TLS)以允许代理和客户端之间的基于证书的身份验证。TLS 是一个更新的、更加安全的 SSL 版本。有两个主要 TLS 配置:
- 单向 TLS
- 只有代理会显示一个证书。客户端使用该证书来验证代理。这是最常见的配置。
- 双向 TLS
- 代理和客户端都提供证书。这有时被称为 mutual 身份验证。
以下描述了以下部分:
对于单向和双向 TLS,您可以生成一个 secret,在代理和客户端之间存储成功 TLS 握手所需的凭证来完成配置。这是您必须在安全接收器或连接器的 sslSecret
参数中指定的 secret 名称。secret 必须包含 Base64 编码的代理密钥存储(单向和双向 TLS)、Base64 编码的代理信任存储(仅双向 TLS)以及这些文件的对应密码,以及 Base64 编码的。单向和双向 TLS 配置流程演示了如何生成此 secret。
如果您没有在受保护接收器或连接器的 sslSecret
参数中明确指定 secret 名称,接受者或连接器会假定默认 secret 名称。默认 secret 名称使用 < custom_resource_name> - <acceptor_name> -secret
或 < custom_resource_name> - <connector_name>-secret
的格式。例如,my-broker-deployment-my-acceptor-secret
。
即使接受者或连接器假设默认 secrete 名称,您仍需要自己生成此 secret。它不会被自动创建。
4.8.2.1. 为主机名验证配置代理证书
本节介绍了在配置单向或双向 TLS 时必须生成的代理证书的一些要求。
当客户端尝试连接到部署中的代理 Pod 时,客户端连接 URL 中的 verifyHost
选项决定客户端是否将代理证书的通用名称(CN)与其主机名进行比较,以验证它们是否匹配。如果您指定了 verifyHost=true
或在客户端连接 URL 中类似,客户端会执行这个验证。
在罕见的情况下,如果您没有担心连接安全性,例如,如果在隔离的网络中的 OpenShift 集群上部署代理,则可能会省略这个验证。否则,建议客户端执行此验证。在这种情况下,正确的代理密钥存储证书配置是确保成功的客户端连接至关重要。
通常,当客户端使用主机验证时,您在生成代理证书时指定的 CN 必须与客户端要连接的代理 Pod 上的 Route 的完整主机名匹配。例如,如果您使用单个代理 Pod 部署,CN 可能类似如下:
CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
为确保 CN 可以解析带有多个代理的的代理 Pod 中的任何代理,您可以指定一个星号(*
)通配符字符来代替普通的代理 Pod。例如:
CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
上例中显示的 CN 成功解析为 my-broker-deployment
部署中的任何代理 Pod。
另外,您在生成代理证书时指定的 Subject Alternative Name(SAN)必须单独 列出 部署中的所有代理 Pod,作为逗号分隔列表。例如:
"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."
4.8.2.2. 配置单向 TLS
本节中的步骤演示了如何配置单向传输层安全(TLS)来保护 broker-client 连接。
在单向 TLS 中,只有代理会显示证书。客户端使用此证书验证代理。
先决条件
- 当客户端使用主机名验证时,您应该了解代理证书生成的要求。更多信息请参阅 第 4.8.2.1 节 “为主机名验证配置代理证书”。
流程
为代理密钥存储生成自签名证书。
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
从代理密钥存储导出证书,以便它与客户端共享。以 Base64 编码的
.pem
格式导出证书。例如:$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
在客户端上,创建一个导入代理证书的客户端信任存储。
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
以管理员身份登录 OpenShift Container Platform。例如:
$ oc login -u system:admin
切换到包含代理部署的项目。例如:
$ oc project <my_openshift_project>
创建用于存储 TLS 凭证的机密。例如:
$ oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/client.ks \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
注意在生成 secret 时,OpenShift 要求您同时指定密钥存储和信任存储。信任存储密钥通常被命名为
client.ts
。对于代理和客户端之间的单向 TLS,实际上并不需要信任存储。但是,若要成功生成 secret,您需要将 一些 有效的存储文件指定为client.ts
的值。上一步通过重复使用之前生成的代理密钥存储文件为client.ts
提供"dummy"值。这足以生成一个带有单向 TLS 所需的所有凭证的 secret。将 secret 链接到您在安装 Operator 时创建的服务帐户。例如:
$ oc secrets link sa/amq-broker-operator secret/my-tls-secret
在安全接受器或连接器的
sslSecret
参数中指定 secret 名称。例如:spec: ... acceptors: - name: my-acceptor protocols: amqp,openwire port: 5672 sslEnabled: true sslSecret: my-tls-secret expose: true connectionsAllowed: 5 ...
4.8.2.3. 配置双向 TLS
本节中的步骤演示了如何配置双向传输层安全(TLS)来保护 broker-client 连接。
在双向 TLS 中,代理和客户端都提供证书。代理和客户端使用这些证书在进程中相互验证,有时被称为 mutual身份验证。
先决条件
- 当客户端使用主机名验证时,您应该了解代理证书生成的要求。更多信息请参阅 第 4.8.2.1 节 “为主机名验证配置代理证书”。
流程
为代理密钥存储生成自签名证书。
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
从代理密钥存储导出证书,以便它与客户端共享。以 Base64 编码的
.pem
格式导出证书。例如:$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
在客户端上,创建一个导入代理证书的客户端信任存储。
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
在客户端上,为客户端密钥存储生成自签名证书。
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
在客户端上,从客户端密钥存储导出证书,以便它与代理共享。以 Base64 编码的
.pem
格式导出证书。例如:$ keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
创建导入客户端证书的代理信任存储。
$ keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
以管理员身份登录 OpenShift Container Platform。例如:
$ oc login -u system:admin
切换到包含代理部署的项目。例如:
$ oc project <my_openshift_project>
创建用于存储 TLS 凭证的机密。例如:
$ oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/broker.ts \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
注意在生成 secret 时,OpenShift 要求您同时指定密钥存储和信任存储。信任存储密钥通常被命名为
client.ts
。对于代理和客户端之间的双向 TLS,您必须生成一个包括代理信任存储的 secret,因为这包含客户端证书。因此,在前面的步骤中,您为client.ts
键指定的值实际上是 代理 信任存储文件。将 secret 链接到您在安装 Operator 时创建的服务帐户。例如:
$ oc secrets link sa/amq-broker-operator secret/my-tls-secret
在安全接受器或连接器的
sslSecret
参数中指定 secret 名称。例如:spec: ... acceptors: - name: my-acceptor protocols: amqp,openwire port: 5672 sslEnabled: true sslSecret: my-tls-secret expose: true connectionsAllowed: 5 ...
4.8.3. 代理部署中的网络服务
在代理部署的 OpenShift Container Platform Web 控制台的 Networking 窗格中,有两个正在运行的服务: 无头服务 和一个 ping 服务。无头服务的默认名称使用格式为 < custom_resource_name>-hdls-svc
,例如 my-broker-deployment-hdls-svc
。ping 服务的默认名称使用 < custom_resource_name> -ping-svc
格式,如 'my-broker-deployment-ping-svc
。
无头服务提供对端口 61616 的访问,它用于内部代理集群。
ping 服务由代理用于发现,并允许代理在 OpenShift 环境中组成集群。此服务在内部公开端口 8888。
4.8.4. 从内部和外部客户端连接到代理
本节中的示例演示了如何从内部客户端(即代理部署相同的 OpenShift 集群中的客户端)和外部客户端(即 OpenShift 集群外的客户端)连接到代理。
4.8.4.1. 从内部客户端连接到代理
要将内部客户端连接到代理(客户端连接详情中),请指定代理 Pod 的 DNS 可解析名称。例如:
$ tcp://ex–aao-ss-0:<port>
如果内部客户端使用 Core 协议,且连接 URL 中未设置 useTopologyForLoadBalancing=false
密钥,在客户端第一次连接到代理后,代理可以告知集群中所有代理的地址的客户端。然后,客户端可以在所有代理之间对连接进行负载平衡。
如果您的代理有持久的订阅队列或请求/回复队列,请注意在客户端连接负载平衡时使用这些队列的相关注意事项。更多信息请参阅 第 4.8.4.4 节 “如果您有持久性订阅队列或回复/请求队列时,需要负载平衡客户端连接的问题”。
4.8.4.2. 从外部客户端连接到代理
当您向外部客户端公开一个接受者(即,通过将 expose
参数的值设置为 true
时),Operator 会自动为部署中的每个代理 Pod 创建一个专用的服务和路由。
外部客户端可以通过指定为代理 pod 创建的路由的完整主机名连接到代理。您可以使用基本的 curl
命令测试对此完整主机名的外部访问。例如:
$ curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
代理 Pod 的路由的完整主机名必须解析到托管 OpenShift 路由器的节点。OpenShift 路由器使用主机名来决定在 OpenShift 内部发送流量的位置。默认情况下,OpenShift 路由器通过监听端口 80 进行不安全保护(即非 SSL)流量和端口 443(即 SSL 加密)流量。对于 HTTP 连接,如果您指定了安全连接 URL(即 https),或者端口 80 直接将流量定向到端口 443(即 https
),如果您指定了非安全连接 URL(即 http
)。
如果您希望外部客户端在集群中的代理间负载均衡连接:
-
通过在每个代理 Pod 的 OpenShift 路由中配置
haproxy.router.openshift.io/balance
roundrobin 选项来启用负载均衡。 -
如果外部客户端默认使用 Core 协议,则
useTopologyForLoadBalancing
配置选项将设为true
。确保该值没有在连接 URL 中设置为 false。
如果您的代理有持久的订阅队列或请求/回复队列,请注意在负载平衡客户端连接时使用这些队列的相关注意事项。更多信息请参阅 第 4.8.4.4 节 “如果您有持久性订阅队列或回复/请求队列时,需要负载平衡客户端连接的问题”。
如果您不希望外部客户端在集群中的不同代理间进行负载均衡连接:
-
在每个客户端使用的连接 URL 中设置
useTopologyForLoadBalancing=false
键。 - 在每个客户端的连接 URL 中,指定每个代理 pod 的路由的完整主机名。客户端尝试在连接 URL 中连接到第一个主机名。但是,如果第一个主机名不可用,客户端会自动连接到连接 URL 中的下一个主机名,以此类推。
对于非 HTTP 连接:
- 客户端必须明确指定端口号(例如,端口 443)作为连接 URL 的一部分。
- 对于单向 TLS,客户端必须指定信任存储的路径及其对应的密码,作为连接 URL 的一部分。
- 对于双向 TLS,客户端还必须指定其密钥存储的路径和对应的密码,作为连接 URL 的一部分。
一些客户端连接 URL 示例,适用于受支持的消息协议,如下所示。
外部核心客户端,使用单向 TLS
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&trustStorePath=~/client.ts&trustStorePassword=<password>
在连接 URL 中明确将 useTopologyForLoadBalancing
键明确设置为 false
,因为外部 Core 客户端无法使用代理返回的拓扑信息。如果此键被设置为 true
,或者您没有指定值,它会产生一个 DEBUG 日志消息。
外部核心客户端,使用双向 TLS
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \ &keyStorePath=~/client.ks&keyStorePassword=<password> \ &trustStorePath=~/client.ts&trustStorePassword=<password>
外部 OpenWire 客户端,使用单向 TLS
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"
# Also, specify the following JVM flags
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
外部 OpenWire 客户端,使用双向 TLS
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443" # Also, specify the following JVM flags -Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \ -Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
外部 AMQP 客户端,使用单向 TLS
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
外部 AMQP 客户端,使用双向 TLS
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \ &transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \ &transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
4.8.4.3. 使用 NodePort 连接到代理
作为使用路由的替代选择,OpenShift 管理员可以将 NodePort 配置为从 OpenShift 外部的客户端连接到代理 Pod。NodePort 应映射到由为代理配置的接受器指定的一个协议特定端口之一。
默认情况下,NodePort 在 30000 到 32767 范围中,这意味着 NodePort 通常与代理 Pod 上的预期端口不匹配。
要通过 NodePort 从 OpenShift 外部客户端连接到代理,您需要以 <protocol>://<ocp_node_ip>:<node_port_number>
格式指定一个 URL。
4.8.4.4. 如果您有持久性订阅队列或回复/请求队列时,需要负载平衡客户端连接的问题
持久化订阅
持久化订阅以代理上的队列形式表示,并在意外的订阅者第一次连接到代理时创建。这个队列存在并接收消息,直到客户端退订。如果客户端重新连接了不同的代理,则在该代理上创建另一个持久的订阅队列。这可能导致以下问题。
问题 | 缓解方案 |
---|---|
消息可能会发生在原始订阅队列中。 | 确保启用了消息 redistribution。如需更多信息,请参阅启用消息重新分发。 |
信息可能会以错误的顺序接收,因为当其他消息仍被路由时,消息会在消息重新分发时有一个窗口。 | 无。 |
当客户端取消订阅时,它会只删除它最近连接的代理上的队列。这意味着其他队列仍然可以存在并接收消息。 | 要删除其他可以被取消订阅的客户端的空队列,请配置以下这两个属性:
将 如需更多信息,请参阅配置自动创建和删除地址和队列。 |
Request/Reply 队列
当 JMS Producer 创建临时的回复队列时,队列会在代理上创建。如果从工作队列使用的客户端并回复临时队列连接到不同的代理,则可能会出现以下问题。
问题 | 缓解方案 |
---|---|
由于客户端连接的代理中不存在答复队列,客户端可能会生成错误。 |
确保 |
发送到工作队列的消息可能无法分发。 |
通过将 |
其他资源
有关使用方法(如 Routes 和 NodePort)从 OpenShift 集群外部与集群中运行的服务进行通信的更多信息,请参阅:
- OpenShift Container Platform 文档中的配置集群入口流量概述。
4.9. 为 AMQP 消息配置大型消息处理
客户端可能会发送超过代理内部缓冲大小的大型 AMQP 信息,从而导致意外错误。要防止这种情况,您可以将代理配置为在消息大于指定最小值时存储信息。以这种方式处理大型消息意味着代理不会在内存中保存消息。相反,代理将信息存储在用于存储大型消息文件的专用目录中。
对于 OpenShift Container Platform 上的代理部署,大型消息目录为 /opt/ <custom_resource_name> /data/large-messages
on the Persistent Volume(PV)用于消息存储。当代理将消息存储为大消息时,队列会保留对大型消息目录中的文件的引用。
对于 AMQ Broker 7.10 中的基于 Operator 的代理部署,大型消息处理仅适用于 AMQP 协议。
4.9.1. 为大型消息处理配置 AMQP 接受器
以下流程演示了如何配置接受器来处理大于指定大小作为较大消息的 AMQP 消息。
先决条件
- 您应该熟悉如何为基于 Operator 的代理部署配置接收器。请参阅 第 4.8.1 节 “配置接收器”。
要将大型 AMQP 消息存储在专用的大型消息目录中,代理部署必须使用持久性存储(即,在用于创建部署的自定义资源(CR)实例中将
persistenceEnabled
设为true
)。有关配置持久性存储的更多信息,请参阅:
流程
打开您之前定义 AMQP acceptor 的自定义资源(CR)实例。
使用 OpenShift 命令行界面:
$ oc edit -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Container Platform Web 控制台:
- 在左侧导航菜单中点 →
-
单击
ActiveMQArtemis
CRD。 -
点
Instances
选项卡。 - 查找与项目命名空间对应的 CR 实例。
之前配置的 AMQP 接受程序可能类似如下:
spec: ... acceptors: - name: my-acceptor protocols: amqp port: 5672 connectionsAllowed: 5 expose: true sslEnabled: true ...
指定代理作为较大消息的 AMQP 消息的最小大小,以字节为单位。例如:
spec: ... acceptors: - name: my-acceptor protocols: amqp port: 5672 connectionsAllowed: 5 expose: true sslEnabled: true amqpMinLargeMessageSize: 204800 ... ...
在前面的示例中,代理配置为接受端口 5672 上的 AMQP 信息。根据
amqpMinLargeMessageSize
的值,如果 acceptor 收到一个大于 204800 字节的 AMQP 消息(即 200 KB),代理会将消息存储为大消息。代理将消息存储在大型消息目录中(
/opt/ <custom_resource_name> /data/large-messages
,默认为代理用于消息存储的持久性卷(PV))。如果您没有显式指定
amqpMinLargeMessageSize
属性的值,则代理使用默认值 102400(即 100 KB)。如果将
amqpMinLargeMessageSize
设置为-1
,则会禁用 AMQP 消息的大型消息处理。
4.10. 配置代理健康检查
您可以使用存活度和就绪度探测在正在运行的代理容器上配置定期健康检查。存活度探测通过 ping 代理的 HTTP 端口来检查代理是否在运行。就绪度探测(Readiness probe)通过打开与为代理配置的每个接受器端口的连接来检查代理是否可以接受网络流量。
使用基本的存活度和就绪度探测打开与 HTTP 的连接,并接受器端口来验证代理的健康状况限制是这些检查无法识别底层问题,例如代理文件系统的问题。您可以将代理的命令行实用程序 artemis
合并到存活度或就绪度探测配置中,以创建包括向代理发送消息的更全面的健康检查。
4.10.1. 配置存活度和就绪度探测
以下示例演示了如何使用存活度和就绪度探测配置代理部署的主要自定义资源(CR)实例,以运行健康检查。
先决条件
- 您应该熟悉如何使用 CR 实例创建基本代理部署。请参阅 第 3.4.1 节 “部署基本代理实例”。
流程
创建 CR 实例。
使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
要配置存活度探测,在 CR 的
deploymentPlan
部分中添加一个livenessProbe
部分。例如:spec: deploymentPlan: livenessProbe: initialDelaySeconds: 5 periodSeconds: 5
initialDelaySeconds
-
探测在容器启动后运行前的延迟(以秒为单位)。默认值为
5
。 periodSeconds
探测运行的时间间隔(以秒为单位)。默认值为
5
。注意如果您没有配置存活度探测,或者配置探测中缺少处理程序,AMQ Operator 会创建一个具有以下配置的默认 TCP 探测。默认 TCP 探测尝试打开指定端口上的代理容器的套接字。
spec: deploymentPlan: livenessProbe: tcpSocket: port: 8181 initialDelaySeconds: 30 timeoutSeconds: 5
要配置就绪度探测,在 CR 的
deploymentPlan
部分中添加一个readinessProbe
部分。例如:spec: deploymentPlan: readinessProbe: initialDelaySeconds: 5 periodSeconds: 5
如果您没有配置就绪度探测,内置 脚本会 检查所有接收器是否可以接受连接。
如果要配置更全面的健康检查,请将
artemis 检查
命令行工具添加到存活度或就绪度探测配置中。如果要配置健康检查以在
livenessProbe
或readinessProbe
部分中创建一个与代理的完整客户端连接,请添加exec
部分。在exec
部分中,添加command
部分。在command
部分中,添加artemis 检查节点
命令语法。例如:spec: deploymentPlan: readinessProbe: exec: command: - bash - '-c' - /home/jboss/amq-broker/bin/artemis - check - node - '--silent' - '--acceptor' - <acceptor name> - '--user' - $AMQ_USER - '--password' - $AMQ_PASSWORD initialDelaySeconds: 30 timeoutSeconds: 5
默认情况下,
artemis 检查节点
命令使用名为artemis
的 acceptor 的 URI。如果代理有一个名为artemis
的接受器,您可以在该命令中排除--acceptor <acceptor name
> 选项。注意$AMQ_USER
和$AMQ_PASSWORD
是 AMQ Operator 配置的环境变量。如果要配置生成和使用消息的健康检查,在
livenessProbe
或readinessProbe
部分中验证代理文件系统的健康状况,请添加exec
部分。在exec
部分中,添加command
部分。在command
部分中,添加artemis 检查队列
命令语法。例如:spec: deploymentPlan: readinessProbe: exec: command: - bash - '-c' - /home/jboss/amq-broker/bin/artemis - check - queue - '--name' - livenessqueue - '--produce' - "1" - '--consume' - "1" - '--silent' - '--user' - $AMQ_USER - '--password' - $AMQ_PASSWORD initialDelaySeconds: 30 timeoutSeconds: 5
注意您指定的队列名称必须在代理上配置,且
anycast
为routingType
。例如:apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemisAddress metadata: name: livenessqueue namespace: activemq-artemis-operator spec: addressName: livenessqueue queueConfiguration: purgeOnNoConsumers: false maxConsumers: -1 durable: true enabled: true queueName: livenessqueue routingType: anycast
部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 完成配置 CR 后,点 Create。
其他资源
如需有关 OpenShift Container Platform 中存活度和就绪度探测的更多信息,请参阅 OpenShift Container Platform 文档中的使用 健康检查来监控应用程序健康状况。
4.11. 高可用性和消息迁移
4.11.1. 高可用性
术语 高可用性 指的是该系统的一部分或关闭系统也可以保持操作的系统。对于 OpenShift Container Platform 上的 AMQ Broker,这意味着在代理 Pod 失败时确保消息传递数据的完整性和可用性,或者因为部署的有意扩展而关闭。
要允许 OpenShift Container Platform 上 AMQ Broker 的高可用性,您可以在代理集群中运行多个代理 Pod。每个代理 Pod 将其消息数据写入您声明用于 PVC 的可用持久性卷(PV)。如果代理 Pod 失败或关闭,保存在 PV 的消息数据会迁移到代理集群中的另一个可用代理 Pod。其他代理 Pod 将消息数据存储在自己的 PV 中。
下图显示了基于 StatefulSet 的代理部署。在这种情况下,代理集群中的两个代理 Pod 仍然在运行。
当代理 Pod 关闭时,AMQ Broker Operator 会自动启动一个 scaledown 控制器,它将执行消息迁移到仍在代理集群中运行的另一个代理 Pod。此消息迁移过程也称为 Pod draining。下面的部分描述了消息迁移。
4.11.2. 消息迁移
消息迁移是由于部署的意图缩减,如何在集群部署中代理关闭时确保消息传递数据的完整性。也称为 Pod 排空,此过程指的是从已关闭的代理 Pod 中删除和重新分发消息。
- 执行消息迁移的 scaledown 控制器只能在单个 OpenShift 项目中操作。控制器无法在单独的项目中的代理之间迁移信息。
- 要使用消息迁移,您的部署中必须至少有两个代理。默认集群带有两个或多个代理的代理。
对于基于 Operator 的代理部署,您可以在用于部署的主代理自定义资源中将 messageMigration
设置为 true
来启用消息迁移。
消息迁移过程遵循以下步骤:
- 当部署中的代理 Pod 因部署的意图而关闭时,Operator 会自动启动缩减控制器以准备消息迁移。scaledown 控制器在与代理集群相同的 OpenShift 项目名称中运行。
- scaledown 控制器注册自己,并侦听项目中与持久性卷声明(PVC)相关的 Kubernetes 事件。
要检查已经孤立的持久性卷(PV),扩展控制器会在卷声明上查看 或dinal。控制器将卷声明上的 ordinal 与项目中仍然在 StatefulSet 中运行的代理 Pod(即代理集群)进行比较。
如果卷声明上的 ordinal 大于仍在代理集群中任何代理 Pod 的 ordinal,则 scaledown 控制器会确定代理 Pod 已关闭,且消息传递数据必须迁移到另一个代理 Pod。
scaledown 控制器启动一个 drainer Pod。drainer Pod 运行代理并执行消息迁移。然后,drainer Pod 标识可迁移到孤立消息的替代代理 Pod。
注意部署中必须至少有一个代理 Pod 仍在部署中运行,才能进行消息迁移。
下图演示了 scaledown 控制器(也称为 drain controller)如何将消息迁移到正在运行的代理 Pod。
当信息成功迁移到可操作的代理 Pod 后,排空器 Pod 会关闭,扩展控制器会删除孤立 PV 的 PVC。PV 返回为"Released"状态。
如果您将代理部署缩减为 0(零),则不会发生消息迁移,因为没有正在运行的代理 Pod 可以迁移到哪个代理数据。但是,如果您将部署缩减到零,然后再备份小于原始部署的大小,则为保持关闭的代理启动排空 Pod。
其他资源
- 有关缩减代理部署时的消息迁移示例,请参阅 大规模迁移信息。
4.11.3. 在缩减时迁移消息
要在代理部署时迁移消息,请使用主代理自定义资源(CR)来启用消息迁移。当您缩小集群代理部署时,AMQ Broker Operator 会自动运行专用的扩展控制器来执行消息迁移。
启用消息迁移后,Operator 中的 scaledown 控制器会检测到代理 Pod 的关闭,并启动 drainer Pod 来执行消息迁移。drainer Pod 连接到集群中的其他 live 代理 Pod,并将信息迁移到该实时代理 Pod。迁移完成后,scaledown 控制器将关闭。
- 缩减控制器仅在单一 OpenShift 项目中运行。控制器无法在单独的项目中的代理之间迁移信息。
- 如果您将代理部署缩减为 0(零),则不会发生消息迁移,因为没有运行可将消息传递数据迁移到的代理 Pod。但是,如果您将部署缩减到零代理,然后备份到原始部署中的一些代理,排空 Pod 会在保持关闭的代理中启动。
以下示例步骤显示 scaledown 控制器的行为。
先决条件
- 您已有基本的代理部署。请参阅 第 3.4.1 节 “部署基本代理实例”。
- 您应该了解消息迁移的工作原理。更多信息请参阅 第 4.11.2 节 “消息迁移”。
流程
-
在您最初下载并提取的 Operator 存储库的
deploy/crs
目录中,打开主代理 CRbroker_activemqartemis_cr.yaml
。 在主代理 CR 中,将
messageMigration
和persistenceEnabled
设置为true
。这些设置意味着,当您稍后缩减集群代理部署的大小时,Operator 会自动启动扩展控制器,并将信息迁移到仍然运行的代理 Pod。
在现有代理部署中,验证哪些 Pod 正在运行。
$ oc get pods
您会看到类似如下的输出。
activemq-artemis-operator-8566d9bf58-9g25l 1/1 Running 0 3m38s ex-aao-ss-0 1/1 Running 0 112s ex-aao-ss-1 1/1 Running 0 8s
前面的输出显示,有三个 Pod 正在运行:一个用于 broker Operator 本身,以及部署中每个代理一个单独的 Pod。
登录到每个 Pod,并将一些消息发送到每个代理。
作为 Pod
ex-aao-s-0 的补充
,其集群 IP 地址为172.17.0.6
,运行以下命令:$ /opt/amq/bin/artemis producer --url tcp://172.17.0.6:61616 --user admin --password admin
作为 Pod
ex-aao-s-1 的补充
,集群 IP 地址为172.17.0.7
,运行以下命令:$ /opt/amq/bin/artemis producer --url tcp://172.17.0.7:61616 --user admin --password admin
前面的命令在每个代理上创建一个名为
TEST
的队列,并将 1000 个消息添加到每个队列。
将集群从两个代理缩减为一个。
-
打开主代理 CR,
broker_activemqartemis_cr.yaml
。 -
在 CR 中,将
deploymentPlan.size
设置为1
。 在命令行中应用更改:
$ oc apply -f deploy/crs/broker_activemqartemis_cr.yaml
您会看到 Pod
ex-aao-s-1
开始关闭。scaledown 控制器会启动同一名称的新 drainer Pod。这个 drainer Pod 也会在将信息从代理 Podex-ao-s-1
中迁移到集群(ex-aao-ss-0
)中的其他代理 Pod 中后关闭。
-
打开主代理 CR,
-
当 drainer Pod 关闭时,检查 broker Pod
ex-aao-ss-0
的TEST
队列的消息数。您会看到队列中的消息数量为 2000,表示 drainer Pod 已成功迁移了关闭的代理 Pod 中的 1000 信息。
4.12. 控制 OpenShift Container Platform 节点上的代理 pod 放置
您可以使用节点选择器、容限或关联性和反关联性规则来控制 OpenShift Container Platform 节点上的 AMQ Broker pod 放置。
- 节点选择器
- 节点选择器允许您在特定节点上调度代理 pod。
- 容限(Tolerations)
- 如果容限与为节点配置的污点匹配,则容限可让代理 pod 调度到节点上。如果没有匹配的 pod 容限,污点允许节点拒绝接受 pod。
- 关联性/Anti-affinity
- 节点关联性规则控制 pod 可根据节点标签调度到哪些节点。pod 关联性和反关联性规则控制哪些节点可以根据已在该节点上运行的 pod 调度到哪些节点。
4.12.1. 使用节点选择器将 pod 放置到特定节点
节点选择器指定一个键值对,要求将 broker pod 调度到节点标签中具有匹配键值对的节点。
以下示例演示了如何配置节点选择器来在特定节点上调度代理 pod。
先决条件
- 您应该熟悉如何使用 CR 实例创建基本代理部署。请参阅 第 3.4.1 节 “部署基本代理实例”。
- 向要在其上调度代理 pod 的 OpenShift Container Platform 节点添加标签。有关添加节点标签的更多信息,请参阅 OpenShift Container Platform 文档中的 使用节点选择器来控制 pod 放置。
流程
根据主代理 CRD 创建自定义资源(CR)实例。
使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
在 CR 的
deploymentPlan
部分中,添加一个nodeSelector
部分,并添加您要与为 pod 选择节点匹配的节点标签。例如:spec: deploymentPlan: nodeSelector: app: broker1
在本例中,代理 pod 调度到具有
app: broker1
标签的节点上。部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
其他资源
如需有关 OpenShift Container Platform 中的节点选择器的更多信息,请参阅 OpenShift Container Platform 文档中的 使用节点选择器将 pod 放置到特定的节点上。
4.12.2. 使用容限控制 pod 放置
污点和容限控制 pod 是否可以调度到特定的节点上。通过使用污点(taint),节点可以拒绝调度 pod,除非 pod 具有匹配的容限(toleration)。您可以使用污点从节点排除 pod,以便为特定 pod 保留节点,如代理 pod,它们具有匹配容限。
具有匹配的容限(匹配容限)允许将代理 pod 调度到节点上,但不保证 pod 调度到该节点上。为确保代理 pod 调度到配置了污点的节点,您可以配置关联性规则。如需更多信息,请参阅 第 4.12.3 节 “使用关联性和反关联性规则控制 pod 放置”。
以下示例演示了如何配置容限,以匹配节点上配置的污点。
先决条件
- 您应该熟悉如何使用 CR 实例创建基本代理部署。请参阅 第 3.4.1 节 “部署基本代理实例”。
将污点应用到您要为调度代理 pod 保留的节点。污点由键、值和效果组成。污点效果决定是否:
- 节点上的现有 pod 被驱除
- 现有 pod 可以保留在节点上,但无法调度新 pod,除非它们有匹配的容限
- 必要时可将新 pod 调度到节点上,但首选项不将新 pod 调度到该节点上。
如需有关应用污点的更多信息,请参阅 OpenShift Container Platform 文档中的使用节点污点控制 pod 放置。
流程
根据主代理 CRD 创建自定义资源(CR)实例。
使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
在 CR 的
deploymentPlan
部分中,添加一个tolerations
部分。在tolerations
部分中,为您要匹配的节点污点添加容限。例如:spec: deploymentPlan: tolerations: - key: "app" value: "amq-broker" effect: "NoSchedule"
在本例中,容限与节点污点的
app=amq-broker:NoSchedule
匹配,因此 pod 可以调度到配置了此污点的节点。
要确保代理 pod 正确调度,请不要在 CR 的 tolerations
部分指定 tolerationsSeconds
属性。
部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
其他资源
如需有关 OpenShift Container Platform 中污点和容限的更多信息,请参阅 OpenShift Container Platform 文档中的使用节点污点控制 pod 放置。
4.12.3. 使用关联性和反关联性规则控制 pod 放置
您可以使用节点关联性、pod 关联性或 pod 反关联性规则来控制 pod 放置。节点关联性允许 pod 指定与一组目标节点的关联性。通过 pod 关联性和反关联性,您可以指定 pod 如何调度或无法调度到已在节点上运行的其他 pod 的规则。
4.12.3.1. 使用节点关联性规则控制 pod 放置
节点关联性允许代理 pod 指定与可放置它的一组节点的关联性。代理 pod 可以调度到具有与您为 pod 创建的关联性规则相同的键值对的任何节点上。
以下示例演示了如何使用节点关联性规则配置代理来控制 pod 放置。
先决条件
- 您应该熟悉如何使用 CR 实例创建基本代理部署。请参阅 第 3.4.1 节 “部署基本代理实例”。
-
为 OpenShift Container Platform 集群中的节点分配一个通用标签,它可以调度代理 pod,如
zone: emea
。
流程
根据主代理 CRD 创建自定义资源(CR)实例。
使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
在 CR 的
deploymentPlan
部分中,添加以下部分:关联性
、nodeAffinity
、requiredDuringSchedulingIgnoredDuringExecution
和nodeSelectorTerms
。在nodeSelectorTerms
部分中,添加- matchExpressions
参数,并指定要匹配的节点标签的键值字符串。例如:spec: deploymentPlan: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: zone operator: In values: - emea
在本例中,关联性规则允许将 pod 调度到具有键为
zone
且值为emea
的标签的任何节点上。部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
其他资源
如需有关 OpenShift Container Platform 中的关联性规则的更多信息,请参阅 OpenShift Container Platform 文档中的使用节点关联性规则控制节点上的 pod 放置。
4.12.3.2. 使用反关联性规则相对于其他 pod 放置 pod
通过反关联性规则,您可以根据已在该节点上运行的 pod 标签限制代理 pod 可以调度哪些节点。
使用反关联性规则的用例是确保不会将集群中的多个代理 pod 调度到同一节点上,从而创建一个故障点。如果您不控制集群中的 pod 放置,则可以将集群中的 2 或以上代理 pod 调度到同一节点上。
以下示例演示了如何配置反关联性规则,以防止将集群中的 2 代理 pod 调度到同一节点上。
先决条件
- 您应该熟悉如何使用 CR 实例创建基本代理部署。请参阅 第 3.4.1 节 “部署基本代理实例”。
流程
基于主代理 CRD,为集群中的第一个代理创建一个 CR 实例。
使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
单击 Create ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
在 CR 的
deploymentPlan
部分中,添加一个labels
部分。为第一个代理 pod 创建识别标签,以便您可以在第二个代理 pod 上创建反关联性规则,以防止将两个 pod 调度到同一个节点上。例如:spec: deploymentPlan: labels: name: broker1
部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
基于主代理 CRD,为集群中的第二个代理创建 CR 实例。
在 CR 的
deploymentPlan
部分中,添加以下部分:affinity
、podAntiAffinity
、requiredDuringSchedulingIgnoredDuringExecution
和labelSelector
。在labelSelector
部分中,添加- matchExpressions
参数,并指定要匹配的代理 pod 标签的键值字符串,因此此 pod 不会在同一节点上调度。spec: deploymentPlan: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: labelSelector: - matchExpressions: - key: name operator: In values: - broker1 topologyKey: topology.kubernetes.io/zone
在本例中,pod 反关联性规则可以防止 pod 放置到与带有
name
键的 pod 和值为broker1
的标签相同的节点上,这是分配给集群中第一个代理的标签。
部署 CR 实例。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到您要在其中创建代理部署的项目。
$ oc project <project_name>
创建 CR 实例。
$ oc create -f <path/to/custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 配置完 CR 后,点 Create。
其他资源
如需有关 OpenShift Container Platform 中的关联性规则的更多信息,请参阅 OpenShift Container Platform 文档中的使用节点关联性规则控制节点上的 pod 放置。
第 5 章 连接到基于 Operator 的代理部署的 AMQ Management Console
基于 Operator 的部署中的每个代理 Pod 托管自己的 AMQ 管理控制台实例(通过端口 8161)。要提供对每个代理的控制台的访问权限,您可以为代理部署配置自定义资源(CR)实例,以指示 Operator 自动为每个代理 Pod 创建专用的服务和路由。
以下流程描述了如何连接到部署的代理的 AMQ 管理控制台。
先决条件
- 您必须使用 AMQ Broker Operator 创建代理部署。例如,了解如何使用示例 CR 创建基本代理部署,请参阅 第 3.4.1 节 “部署基本代理实例”。
-
要指示 Operator 在控制台访问过程中自动为每个代理 Pod 创建服务和路由,您必须在用于创建部署的自定义资源(CR)实例中将
console.expose
属性的值设置为true
。此属性的默认值为false
。有关完整的自定义资源配置参考,包括 CR 的console
部分的配置,请参阅 第 8.1 节 “自定义资源配置参考”。
5.1. 连接到 AMQ 管理控制台
当您在用于创建代理部署的自定义资源(CR)实例中将 console.expose
属性的值设置为 true
时,Operator 会自动为每个代理 Pod 创建专用的服务和路由,以提供 AMQ 管理控制台的访问。
自动创建的服务的默认名称采用 < custom-resource-name> -wconsj- <broker-pod-ordinal> -svc
的形式。例如,my-broker-deployment-wconsj-0-svc
。自动创建的路由的默认名称格式为 < custom-resource-name> -wconsj- <broker-pod-ordinal> -svc-rte
。例如,my-broker-deployment-wconsj-0-svc-rte
。
此流程演示了如何访问正在运行的代理 Pod 的控制台。
流程
在 OpenShift Container Platform Web 控制台中,点击
→ 。在 Routes 页面中,识别给定代理 Pod 的
wconsj
Route。例如,my-broker-deployment-wconsj-0-svc-rte
。在 Location 下,单击与路由对应的链接。
在 Web 浏览器中打开一个新标签页。
点 Management Console 链接。
此时会打开 AMQ Management Console 登录页面。
要登录到控制台,请在用于创建代理部署的自定义资源(CR)实例中输入
adminUser
和adminPassword
属性指定的值。如果没有为 CR 中的
adminUser
和adminPassword
指定值,请按照 第 5.2 节 “访问 AMQ 管理控制台登录凭证” 中的说明来检索登录到控制台所需的凭证。注意只有在 CR 的
requireLogin
属性设置为true
时,才需要adminUser
和adminPassword
的值才能登录到控制台。此属性指定是否需要登录凭证才能登录到 代理和 控制台。如果将requireLogin
设置为false
,则可以在提示输入用户名和密码时通过输入任何文本来登录到控制台,而无需提供有效的用户名密码。
5.2. 访问 AMQ 管理控制台登录凭证
如果您没有在用于代理部署的自定义资源(CR)实例中为 adminUser
和 adminPassword
指定值,Operator 会自动生成这些凭证并将其存储在 secret 中。默认 secret 名称采用 < custom-resource-name>-credentials-secret
形式,如 my-broker-deployment-credentials-secret
。
只有在 CR 的 requireLogin
参数设置为 true
时,才需要 adminUser
和 adminPassword
的值才能登录到管理控制台。
如果将 requireLogin
设置为 false
,则可以在提示输入用户名和密码时通过输入任何文本来登录到控制台,而无需提供有效的用户名密码。
此流程演示了如何访问登录凭证。
流程
查看 OpenShift 项目中的 secret 的完整列表。
- 在 OpenShift Container Platform web 控制台中点击 → 。
在命令行中:
$ oc get secrets
打开适当的 secret,以显示 Base64 编码的控制台登录凭证。
- 在 OpenShift Container Platform web 控制台中,点击在其名称中包含代理自定义资源实例的 secret。点 YAML 标签。
在命令行中:
$ oc edit secret <my-broker-deployment-credentials-secret>
要解码 secret 中的一个值,请使用类似如下的命令:
$ echo 'dXNlcl9uYW1l' | base64 --decode console_admin
其他资源
- 如需了解更多有关使用 AMQ 管理控制台查看和管理代理的信息,请参阅管理 AMQ Broker 中的使用 AMQ Management Console 管理代理。
第 6 章 升级基于 Operator 的代理部署
本节中的步骤演示了如何升级:
- AMQ Broker Operator 版本,同时使用 OpenShift 命令行界面(CLI)和 OperatorHub
- 基于 Operator 的代理部署的代理容器镜像
6.1. 开始前
本节介绍了在为基于 Operator 的代理部署升级 Operator 和代理容器镜像前的一些重要事项。
- 使用 OpenShift 命令行界面(CLI)或 OperatorHub 升级 Operator 需要集群管理员权限。
如果您最初使用 CLI 安装 Operator,也应使用 CLI 来升级 Operator。如果您最初使用 OperatorHub 安装 Operator(即 OpenShift Container Platform Web 控制台中的项目的 → 下),您还应使用 OperatorHub 来升级 Operator。有关这些升级方法的更多信息,请参阅:
如果
redeliveryDelayMultiplier
和redeliveryCollisionAvoidanceFactor
属性在 7.8.x 或 7.9.x 部署中的主代理 CR 中配置,新的 Operator 在升级到 7.10.x 后无法协调任何 CR。协调失败,因为两个属性的数据类型从 float 改为 7.10.x 中的字符串。您可以通过删除
spec.deploymentPlan.addressSettings.addressSetting
元素的redeliveryDelayMultiplier
和redeliveryCollisionAvoidanceFactor
属性来解决这个问题。然后,在brokerProperties
元素中配置属性。例如:spec: ... brokerProperties: - "addressSettings.#.redeliveryMultiplier=2.1" - "addressSettings.#.redeliveryCollisionAvoidanceFactor=1.2"
注意在
brokerProperties
元素中,使用redeliveryMultiplier
属性名称而不是您删除的redeliveryDelayMultiplier
属性名称。如果要部署 Operator 来监视多个命名空间,例如监视所有命名空间,您必须:
- 请确定您已备份了与集群中代理部署相关的所有 CR。
- 卸载现有的 Operator。
- 部署 7.10 Operator,以观察您需要的命名空间。
- 检查所有部署并在必要时重新创建。
6.2. 使用 CLI 升级 Operator
本节中的步骤演示了如何使用 OpenShift 命令行界面(CLI)将不同的 Operator 版本升级到可用于 AMQ Broker 7.10 的最新版本。
6.2.1. 先决条件
- 只有在您最初使用 CLI 安装 Operator 时,才应使用 CLI 来升级 Operator。如果您最初使用 OperatorHub 安装 Operator(即,Operator 出现在 OpenShift Container Platform Web 控制台中您的项目的 → 下),您应该使用 OperatorHub 来升级 Operator。要了解如何使用 OperatorHub 升级 Operator,请参阅 第 6.3 节 “使用 OperatorHub 升级 Operator”。
6.2.2. 使用 CLI 升级 Operator
您可以使用 OpenShift 命令行界面(CLI)将 Operator 升级到 AMQ Broker 7.10 的最新版本。
流程
- 在 Web 浏览器中,导航到 AMQ Broker 7.10.7 补丁的 Software Downloads 页面。
-
确保 Version 下拉列表的值设为
7.10.7
,并且选择了 Releases 选项卡。 在 AMQ Broker 7.10.7 Operator Installation and Example Files 旁边,点 Download。
下载
amq-broker-operator-7.10.7-ocp-install-examples.zip
压缩存档会自动开始。下载完成后,将存档移至您选择的安装目录。以下示例将存档 移到名为
~/broker/operator
的目录。$ mkdir ~/broker/operator $ mv amq-broker-operator-7.10.7-ocp-install-examples.zip ~/broker/operator
在您选择的安装目录中,提取存档的内容。例如:
$ cd ~/broker/operator $ unzip amq-broker-operator-operator-7.10.7-ocp-install-examples.zip
以包含现有 Operator 部署的项目的管理员身份登录 OpenShift Container Platform。
$ oc login -u <user>
切换到要升级 Operator 版本的 OpenShift 项目。
$ oc project <project-name>
在您下载并提取的最新 Operator 归档的
deploy
目录中,打开operator.yaml
文件。注意在
operator.yaml
文件中,Operator 使用一个由 Secure Hash Algorithm (SHA) 值代表的镜像。注释行以数字符号 (#
) 符号开头,注明 SHA 值对应于特定的容器镜像标签。-
为 以前的 Operator 部署打开
operator.yaml
文件。检查您在之前配置中指定的任何非默认值是否在 新的operator.yaml
配置文件中复制。 在新的
operator.yaml
文件中,Operator 默认命名为controller-manager
。将controller-manager
的所有实例替换为amq-broker-operator
,这是之前版本中 Operator 的名称,并保存文件。例如:spec: ... selector matchLabels name: amq-broker-operator ...
更新 Operator 中包含的 CRD。在部署 Operator 前,您必须更新 CRD。
更新主代理 CRD。
$ oc apply -f deploy/crds/broker_activemqartemis_crd.yaml
更新地址 CRD。
$ oc apply -f deploy/crds/broker_activemqartemisaddress_crd.yaml
更新 scaledown 控制器 CRD。
$ oc apply -f deploy/crds/broker_activemqartemisscaledown_crd.yaml
更新安全 CRD。
$ oc apply -f deploy/crds/broker_activemqartemissecurity_crd.yaml
如果您只从 AMQ Broker Operator 7.10.0 升级,请删除 Operator 和 StatefulSet。
默认情况下,新 Operator 删除 StatefulSet 以删除自定义和 Operator metering 标签,这些标签被 7.10.0 中的 Operator 错误地添加到 StatefulSet 选择器。当 Operator 删除 StatefulSet 时,它还会删除现有的代理 Pod,这会导致临时代理中断。如果要避免中断,请完成以下步骤以删除 Operator 和 StatefulSet 而不删除代理 Pod。
删除 Operator。
$ oc delete -f deploy/operator.yaml
使用
--cascade=orphan
选项删除 StatefulSet,以孤立代理 Pod。孤立的代理 Pod 在删除 StatefulSet 后继续运行。$ oc delete statefulset <statefulset-name> --cascade=orphan
如果您要从 AMQ Broker Operator 7.10.0 或 7.10.1 升级,请检查您的主代理 CR 是否有名为
application
或ActiveMQArtemis
的标签,在deploymentPlan.labels
属性中配置。这些标签为 Operator 保留,以分配标签到 Pod,且不允许在 7.10.1 后作为自定义标签。如果在主代理 CR 中配置了这些自定义标签,则 Pod 上的 Operator 分配标签会被自定义标签覆盖。如果在主代理 CR 中配置了任何自定义标签,请完成以下步骤以在 Pod 上恢复正确的标签并从 CR 中删除标签。
如果您要从 7.10.0 升级,请删除上一步中的 Operator。如果要从 7.10.1 升级,请删除 Operator。
$ oc delete -f deploy/operator.yaml
运行以下命令以恢复正确的 Pod 标签。在以下示例中,'ex-aao' 是部署的 StatefulSet 的名称。
$ for pod in $(oc get pods | grep -o '^ex-aao[^ ]*') do; oc label --overwrite pods $pod ActiveMQArtemis=ex-aao application=ex-aao-app; done
从 CR 中的
deploymentPlan.labels
属性中删除application
和ActiveMQArtemis
标签。以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。 -
在 CR 的
deploymentPlan.labels
属性中,删除名为application
或ActiveMQArtemis
的任何自定义标签。 - 保存 CR 文件。
部署 CR 实例。
切换到代理部署的项目。
$ oc project <project_name>
应用 CR。
$ oc apply -f <path/to/broker_custom_resource_instance>.yaml
如果删除了以前的 Operator,请部署新的 Operator。
$ oc create -f deploy/operator.yaml
应用更新的 Operator 配置。
$ oc apply -f deploy/operator.yaml
新的 Operator 可以识别和管理之前的代理部署。如果在部署的 CR 中启用了自动更新,Operator 的协调过程会处理每个代理 pod 的协调过程。如果没有启用自动更新,您可以通过在 CR 中设置以下属性来启用它们:
spec: ... upgrades: enabled: true minor: true
有关启用自动更新的详情请参考 第 6.4 节 “通过指定 AMQ Broker 版本升级代理容器镜像”。
注意如果协调过程没有启动,您可以通过扩展部署来开始该过程。更多信息请参阅 第 3.4.1 节 “部署基本代理实例”。
- 根据需要在 CR 中为升级代理可用的新功能添加属性。
6.3. 使用 OperatorHub 升级 Operator
本节论述了如何使用 OperatorHub 为 AMQ Broker 升级 Operator。
6.3.1. 先决条件
- 只有在您最初使用 OperatorHub 安装 Operator 时,才应使用 OperatorHub 来升级 Operator(也就是说,OpenShift Container Platform Web 控制台的 → 下)。相反,如果您最初使用 OpenShift 命令行界面(CLI)来安装 Operator,您也应使用 CLI 升级 Operator。要了解如何使用 CLI 升级 Operator,请参阅 第 6.2 节 “使用 CLI 升级 Operator”。
- 使用 OperatorHub 升级 AMQ Broker Operator 需要 OpenShift 集群的集群管理员权限。
6.3.2. 开始前
本节介绍了使用 OperatorHub 升级 AMQ Broker Operator 实例前的一些重要事项。
- 当您从 OperatorHub 安装最新的 Operator 版本时,Operator Lifecycle Manager 会自动更新 OpenShift 集群中的 CRD。您不需要删除现有 CRD。如果您删除了现有的 CRD,则所有 CR 和代理实例也会被删除。
- 当使用最新 Operator 版本的 CRD 更新集群时,这个更新会影响 集群中的所有项目。任何从之前版本的 Operator 部署的代理 Pod 都无法在 OpenShift Container Platform Web 控制台中更新其状态。当您点正在运行的代理 Pod 的 Logs 选项卡时,您会看到指出 'UpdatePodStatus' 失败的消息。但是,该项目中的代理 Pod 和 Operator 将继续按预期工作。要为受影响的项目修复这个问题,您还必须升级该项目以使用 Operator 的最新版本。
- 遵循的步骤取决于您从其升级的 Operator 版本。确保遵循适用于当前版本的升级步骤。
6.3.3. 将 Operator 从 pre-7.10.0 升级到 7.10.1 或更高版本
您可以使用 OperatorHub 将 Operator 实例从 pre-7.10.0 升级到 7.10.1 或更高版本。
流程
- 以集群管理员身份登录 OpenShift Container Platform Web 控制台。
- 从项目中卸载现有的 AMQ Broker Operator。
- 在左侧导航菜单中,点 → 。
- 在页面顶部的 Project 下拉菜单中选择您要卸载 Operator 的项目。
- 找到您要卸载的 Red Hat Integration - AMQ Broker 实例。
- 对于 Operator 实例,点击右侧的 More Options 图标(三个垂直点)。点击 Uninstall Operator。
- 在确认对话框中点 Uninstall。
使用 OperatorHub 为 AMQ Broker 7.10 安装最新版本的 Operator。更多信息请参阅 第 3.3.2 节 “从 OperatorHub 部署 Operator”。
如果在部署的 CR 中启用了自动更新,Operator 协调过程会在新 Operator 启动时升级每个代理 pod。如果没有启用自动更新,您可以通过在 CR 中设置以下属性来启用它们:
spec: ... upgrades: enabled: true minor: true
有关启用自动更新的详情请参考 第 6.4 节 “通过指定 AMQ Broker 版本升级代理容器镜像”。
注意如果协调过程没有启动,您可以通过扩展部署来开始该过程。更多信息请参阅 第 3.4.1 节 “部署基本代理实例”。
6.3.4. 将 Operator 从 7.10.0 升级到 7.10.x
使用这个流程从 AMQ Broker Operator 7.10.0 升级。
流程
- 以集群管理员身份登录 OpenShift Container Platform Web 控制台。
从项目中卸载现有的 AMQ Broker Operator。
- 在左侧导航菜单中,点 → 。
- 在页面顶部的 Project 下拉菜单中选择您要卸载 Operator 的项目。
- 找到您要卸载的 Red Hat Integration - AMQ Broker 实例。
- 对于 Operator 实例,点击右侧的 More Options 图标(三个垂直点)。点击 Uninstall Operator。
- 在确认对话框中点 Uninstall。
当您升级 7.10.0 Operator 时,新 Operator 会删除 StatefulSet 来删除自定义和 Operator metering 标签,这些标签会错误地添加到 7.10.0 中 Operator 的 StatefulSet 选择器。当 Operator 删除 StatefulSet 时,它也会删除现有的代理 pod,这会导致临时代理中断。如果要避免中断,请完成以下步骤以删除 StatefulSet 并孤立代理 pod,以便它们继续运行。
以包含现有 Operator 部署的项目的管理员用户身份登录 OpenShift Container Platform CLI:
$ oc login -u <user>
切换到要升级 Operator 版本的 OpenShift 项目。
$ oc project <project-name>
使用
--cascade=orphan
选项删除 StatefulSet,以孤立代理 Pod。孤立的代理 Pod 在删除 StatefulSet 后继续运行。$ oc delete statefulset <statefulset-name> --cascade=orphan
检查您的主代理 CR 是否在
deploymentPlan.labels
属性中配置了名为application
或ActiveMQArtemis
的标签。在 7.10.0 中,可以在 CR 中配置这些自定义标签。这些标签是为 Operator 保留用于为 Pod 分配标签,且无法在 7.10.0 后作为自定义标签添加。如果在 7.10.0 中的主代理 CR 中配置了这些自定义标签,则自定义标签会覆盖 Pod 上的 Operator 分配标签。如果 CR 具有其中任一个标签,请完成以下步骤以在 Pod 上恢复正确的标签并从 CR 中删除标签。
在 OpenShift 命令行界面(CLI)中,运行以下命令来恢复正确的 Pod 标签。在以下示例中,'ex-aao' 是部署的 StatefulSet 的名称。
$ for pod in $(oc get pods | grep -o '^ex-aao[^ ]*') do; oc label --overwrite pods $pod ActiveMQArtemis=ex-aao application=ex-aao-app; done
从 CR 中的
deploymentPlan.labels
属性中删除application
和ActiveMQArtemis
标签。使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。 -
在 CR 的
deploymentPlan.labels
元素中,删除名为application
或ActiveMQArtemis
的任何自定义标签。 - 保存 CR 文件。
部署 CR 实例。
切换到代理部署的项目。
$ oc project <project_name>
应用 CR。
$ oc apply -f <path/to/broker_custom_resource_instance>.yaml
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
- 点代理部署的实例。
点 YAML 标签。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
-
在 CR 的
deploymentPlan.labels
元素中,删除名为application
或ActiveMQArtemis
的任何自定义标签。 - 点 Save。
使用 OperatorHub 为 AMQ Broker 7.10 安装最新版本的 Operator。更多信息请参阅 第 3.3.2 节 “从 OperatorHub 部署 Operator”。
新的 Operator 可以识别和管理之前的代理部署。如果在部署的 CR 中启用了自动更新,Operator 协调过程会在新 Operator 启动时升级每个代理 pod。如果没有启用自动更新,您可以通过在 CR 中设置以下属性来启用它们:
spec: ... upgrades: enabled: true minor: true
有关启用自动更新的详情请参考 第 6.4 节 “通过指定 AMQ Broker 版本升级代理容器镜像”。
注意如果协调过程没有启动,您可以通过扩展部署来开始该过程。更多信息请参阅 第 3.4.1 节 “部署基本代理实例”。
- 根据需要在 CR 中为升级代理可用的新功能添加属性。
6.3.5. 将 Operator 从 7.10.1 升级到 7.10.x
使用这个流程从 AMQ Broker Operator 7.10.1 升级。
流程
- 以集群管理员身份登录 OpenShift Container Platform Web 控制台。
检查您的主代理 CR 是否在
deploymentPlan.labels
属性中配置了名为application
或ActiveMQArtemis
的标签。这些标签为 Operator 保留,以分配标签到 Pod,在 7.10.1 后无法使用。如果在主代理 CR 中配置了这些自定义标签,则 Pod 上的 Operator 分配标签会被自定义标签覆盖。
- 如果在主代理 CR 中没有配置这些自定义标签,请使用 OperatorHub 为 AMQ Broker 7.10 安装 Operator 的最新版本。更多信息请参阅 第 3.3.2 节 “从 OperatorHub 部署 Operator”。
如果在主代理 CR 中配置了任何自定义标签,请完成以下步骤来卸载现有的 Operator,在安装新 Operator 前恢复正确的 Pod 标签并从 CR 中删除标签。
注意通过卸载 Operator,您可以在没有 Operator 删除 StatefulSet 的情况下删除自定义标签,这也会删除现有代理 pod 并导致临时代理中断。
从项目中卸载现有的 AMQ Broker Operator。
- 在左侧导航菜单中,点 → 。
- 在页面顶部的 Project 下拉菜单中选择您要卸载 Operator 的项目。
- 找到您要卸载的 Red Hat Integration - AMQ Broker 实例。
- 对于 Operator 实例,点击右侧的 More Options 图标(三个垂直点)。点击 Uninstall Operator。
- 在确认对话框中点 Uninstall。
在 OpenShift 命令行界面(CLI)中,运行以下命令来恢复正确的 Pod 标签。在以下示例中,'ex-aao' 是部署的 StatefulSet 的名称。
$ for pod in $(oc get pods | grep -o '^ex-aao[^ ]*') do; oc label --overwrite pods $pod ActiveMQArtemis=ex-aao application=ex-aao-app; done
从 CR 中的
deploymentPlan.labels
属性中删除application
和ActiveMQArtemis
标签。使用 OpenShift 命令行界面:
以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。
oc login -u <user> -p <password> --server=<host:port>
-
打开名为
broker_activemqartemis_cr.yaml
的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的deploy/crs
目录中。 -
在 CR 的
deploymentPlan.labels
属性中,删除名为application
或ActiveMQArtemis
的任何自定义标签。 - 保存 CR 文件。
部署 CR 实例。
切换到代理部署的项目。
$ oc project <project_name>
应用 CR。
$ oc apply -f <path/to/broker_custom_resource_instance>.yaml
使用 OpenShift Container Platform Web 控制台:
- 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
- 在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
- 点代理部署的实例。
点 YAML 标签。
在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。
-
在 CR 的
deploymentPlan.labels
属性中,删除名为application
或ActiveMQArtemis
的任何自定义标签。 - 点 Save。
使用 OperatorHub 为 AMQ Broker 7.10 安装最新版本的 Operator。更多信息请参阅 第 3.3.2 节 “从 OperatorHub 部署 Operator”。
新的 Operator 可以识别和管理之前的代理部署。如果在部署的 CR 中启用了自动更新,Operator 协调过程会在新 Operator 启动时升级每个代理 pod。如果没有启用自动更新,您可以通过在 CR 中设置以下属性来启用它们:
spec: ... upgrades: enabled: true minor: true
有关启用自动更新的详情请参考 第 6.4 节 “通过指定 AMQ Broker 版本升级代理容器镜像”。
注意如果协调过程没有启动,您可以通过扩展部署来开始该过程。更多信息请参阅 第 3.4.1 节 “部署基本代理实例”。
- 根据需要在 CR 中为升级代理可用的新功能添加属性。
6.4. 通过指定 AMQ Broker 版本升级代理容器镜像
以下流程演示了如何通过指定 AMQ Broker 版本为基于 Operator 的代理部署升级代理容器镜像。例如,如果您将 Operator 升级到 AMQ Broker 7.10.0,但 CR 中的 spec.upgrades.enabled
属性已设为 true
,spec.version
属性指定 7.9.0
。要升级 代理容器镜像,需要手动指定新的 AMQ Broker 版本(如 7.10.0
)。当您指定 AMQ Broker 的新版本时,Operator 会自动选择与此版本对应的代理容器镜像。
先决条件
- 如 第 2.4 节 “Operator 如何选择容器镜像” 所述,如果您部署一个 CR 且没有明确指定代理容器镜像,Operator 会自动选择要使用的适当容器镜像。要使用本节中描述的升级过程,您必须使用此默认行为。如果您在 CR 中直接指定代理容器镜像来覆盖默认行为,Operator 无法自动 升级代理容器镜像以对应 AMQ Broker 版本,如下所述。
流程
编辑代理部署的主要代理 CR 实例。
使用 OpenShift 命令行界面:
以具有权限权限的用户身份登录 OpenShift,以便在项目中为代理部署编辑和部署 CR。
$ oc login -u <user> -p <password> --server=<host:port>
-
在文本编辑器中,打开用于代理部署的 CR 文件。例如,这可能是之前下载并提取的 Operator 安装的
deploy/crs
目录中的broker_activemqartemis_cr.yaml
文件。
使用 OpenShift Container Platform Web 控制台:
- 以具有权限的用户身份登录控制台,在项目中为代理部署编辑和部署 CR。
- 在左侧窗格中,单击 → 。
- 单击 ActiveMQArtemis CRD。
- 点 实例 选项卡。
- 查找与项目命名空间对应的 CR 实例。
对于 CR 实例,单击右侧的 More Options 图标(三个垂直点)。选择 Edit ActiveMQArtemis。
在控制台中,会打开 YAML 编辑器,供您编辑 CR 实例。
指定将代理容器镜像升级到的 AMQ Broker 版本,为 CR 的
spec.version
属性设置一个值。例如:spec: version: 7.10.0 ...
在 CR 的
spec
部分,找到upgrade
部分。如果 CR 中还没有包括此部分,请添加它。spec: version: 7.10.0 ... upgrades:
确定 upgrade
部分包含
enabled
和minor
属性。spec: version: 7.10.0 ... upgrades: enabled: minor:
要根据 AMQ Broker 的指定版本启用代理容器镜像升级,请将
enabled
属性的值设置为true
。spec: version: 7.10.0 ... upgrades: enabled: true minor:
要定义代理的升级行为,请为
minor
属性设置值。要允许在 次要 AMQ Broker 版本间升级,将
minor
设置为true
。spec: version: 7.10.0 ... upgrades: enabled: true minor: true
例如,假设当前代理容器镜像与
7.9.0
和新镜像对应,对应于为spec.version
指定的7.10.0
版本。在这种情况下,Operator 决定在7.9.0
和7.10.0
次版本之间有可用的升级。根据前面的设置,允许在次版本之间进行升级,Operator 会升级代理容器镜像。相反,假设当前代理容器镜像与
7.10.0
对应,并且您为spec.version
指定 一个新的7.10.1
值。如果存在与7.10.1
对应的镜像,Operator 会决定7.10.0
和7.10.1
微版本之间有可用的升级。根据前面的设置,仅允许在次版本之间进行升级,Operator 不会 升级代理容器镜像。要允许在 微 AMQ Broker 版本间进行升级,将
minor
的值设为false
。spec: version: 7.10.0 ... upgrades: enabled: true minor: false
例如,假设当前代理容器镜像与
7.9.0
和新镜像对应,对应于为spec.version
指定的7.10.0
版本。在这种情况下,Operator 决定在7.9.0
和7.10.0
次版本之间有可用的升级。根据前面的设置,它不允许在次版本间进行升级(即在微版本间进行升级),Operator 不会 升级代理容器镜像。相反,假设当前代理容器镜像与
7.10.0
对应,并且您为spec.version
指定 一个新的7.10.1
值。如果存在与7.10.1
对应的镜像,Operator 会决定7.10.0
和7.10.1
微版本之间有可用的升级。根据前面的设置,允许在微版本间进行升级,Operator 会升级代理容器镜像。
将更改应用到 CR。
使用 OpenShift 命令行界面:
- 保存 CR 文件。
切换到代理部署的项目。
$ oc project <project_name>
应用 CR。
$ oc apply -f <path/to/broker_custom_resource_instance>.yaml
使用 OpenShift Web 控制台:
- 编辑完 CR 后,点击 Save。
应用 CR 更改时,Operator 首先会验证是否升级到为
spec.version
指定的 AMQ Broker 版本。如果您指定了将要升级到的 AMQ Broker 无效的版本的 AMQ Broker(例如,还没有可用的版本),Operator 会记录警告信息,且不采取进一步操作。但是,如果到指定版本的升级可用,并且为
upgrade.enabled
和upgrade.minor
指定的值允许升级,那么部署中的 Operator 升级每个代理都使用与新的 AMQ Broker 版本对应的代理容器镜像。Operator 使用的代理容器镜像在 Operator 部署的
operator.yaml
配置文件中的环境变量中定义。环境变量名称包括 AMQ Broker 版本的标识符。例如,环境变量RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_7100
对应于 AMQ Broker 7.10.7。当 Operator 应用 CR 更改时,它会在部署中重启每个代理 Pod,以便每个 Pod 使用指定的镜像版本。如果您的部署中有多个代理,则只有一个代理 Pod 会关闭并重启。
其他资源
- 要了解 Operator 如何使用环境变量来选择代理容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”。
第 7 章 监控代理
7.1. 在 Fuse 控制台中查看代理
您可以配置基于 Operator 的代理部署,以使用 Fuse Console for OpenShift 而不是 AMQ 管理控制台。当您正确配置了代理部署时,Fuse Console 会发现代理,并将其显示在专用 Artemis
选项卡中。您可以查看在 AMQ Management Console 中相同的代理运行时数据。您还可以执行相同的基本管理操作,如创建地址和队列。
以下流程描述了如何为代理部署配置自定义资源(CR)实例,以便为 OpenShift 启用 Fuse 控制台在部署中发现和显示代理。
先决条件
- OpenShift 的 Fuse 控制台必须部署到 OCP 集群,或部署到该集群上的特定命名空间。如果您已经将控制台部署到特定命名空间,则代理部署必须 位于同一命名空间中,以便控制台能够发现代理。否则,对 Fuse 控制台和要在同一 OCP 集群上部署的代理而言就足够了。有关在 OCP 上安装 Fuse Online 的更多信息,请参阅在 OpenShift Container Platform 上安装和操作 Fuse Online。
- 您必须已创建了代理部署。例如,了解如何使用自定义资源 (CR) 实例创建基于 Operator 的基本部署,请参阅 第 3.4.1 节 “部署基本代理实例”。
流程
打开用于代理部署的 CR 实例。例如,基本部署的 CR 可能类似以下:
apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 4 image: registry.redhat.io/amq7/amq-broker-rhel8:7.10 ...
在
deploymentPlan
部分中,添加jolokiaAgentEnabled
和managementRBACEnabled
属性,并指定值,如下所示。apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 4 image: registry.redhat.io/amq7/amq-broker-rhel8:7.10 ... jolokiaAgentEnabled: true managementRBACEnabled: false
- jolokiaAgentEnabled
-
指定 Fuse Console 是否可以发现并显示部署中代理的运行时数据。要使用 Fuse Console,请将值设为
true
。 - managementRBACEnabled
指定部署中的代理是否启用了基于角色的访问控制(RBAC)。您必须将 值设为
false
以使用 Fuse Console,因为 Fuse Console 使用自己的基于角色的访问控制。重要如果将
managementRBACEnabled
的值设置为false
,则代理的管理 MBeans 不再需要授权。当managementRBACEnabled
被设置为false
时,您不应该使用 AMQ 管理控制台,因为这可能会公开代理上的所有管理操作到未授权使用。
- 保存 CR 实例。
切换到之前创建的代理部署的项目。
$ oc project <project_name>
在命令行中应用更改。
$ oc apply -f <path/to/custom_resource_instance>.yaml
- 在 Fuse Console 中,要查看 Fuse 应用程序,请单击 Online 选项卡。要查看正在运行的代理,请在左侧导航菜单中,单击 NEXT。
其他资源
- 有关为 OpenShift 使用 Fuse 控制台的更多信息,请参阅在 OpenShift 中监控和管理 Red Hat Fuse 应用程序。
- 要了解使用 AMQ 管理控制台查看和管理代理的方式,您可以在 Fuse 控制台中相同的方式查看和管理 代理,请参阅使用 AMQ Management Console 管理代理。
7.2. 使用 Prometheus 监控代理运行时指标
下面的部分论述了如何在 OpenShift Container Platform 上为 AMQ Broker 配置 Prometheus 指标插件。您可以使用插件来监控和存储代理运行时指标。您还可以使用图形工具(如 Grafana)来配置 Prometheus 插件收集的数据的更多高级视觉化和仪表板。
Prometheus metrics 插件可让您以 Prometheus 格式 收集和导出代理指标。但是,红帽不提供 安装或配置 Prometheus 本身以及 Grafana 等视觉化工具的支持。如果您需要安装、配置或运行 Prometheus 或 Grafana 的支持,请访问产品网站以获取社区支持和文档。
7.2.1. 指标概述
要监控代理实例的健康状态和性能,您可以使用 AMQ Broker 的 Prometheus 插件来监控和存储代理运行时指标。AMQ Broker Prometheus 插件将代理运行时指标导出到 Prometheus 格式,可让您使用 Prometheus 本身来视觉化并运行数据的查询。
您还可以使用图形工具(如 Grafana)为 Prometheus 插件收集的指标配置更高级的视觉化和仪表板。
插件导出到 Prometheus 格式的指标如下所述。
代理指标
artemis_address_memory_usage
- 此代理上的所有地址用于内存消息的字节数。
artemis_address_memory_usage_percentage
-
此代理上的所有地址使用的内存作为
global-max-size
参数的百分比。 artemis_connection_count
- 连接到此代理的客户端数。
artemis_total_connection_count
- 自从启动以来连接到此代理的客户端数。
地址指标
artemis_routed_message_count
- 路由到一个或多个队列绑定的消息数。
artemis_unrouted_message_count
- 没有路由到任何队列绑定的消息数。
队列指标
artemis_consumer_count
- 使用来自给定队列的消息的客户端数。
artemis_delivering_durable_message_count
- 给定队列当前为消费者发送的持久消息的数量。
artemis_delivering_durable_persistent_size
- 给定队列当前为消费者提供的持久消息大小。
artemis_delivering_message_count
- 指定队列当前提供给消费者的消息数。
artemis_delivering_persistent_size
- 给定队列当前为消费者传输的消息的持久性大小。
artemis_durable_message_count
- 给定队列中当前具有持久性消息的数量。这包括调度、页面和发送中消息。
artemis_durable_persistent_size
- 目前在给定队列中持久化消息的大小。这包括调度、页面和发送中消息。
artemis_messages_acknowledged
- 从创建队列后确认来自给定队列的消息数。
artemis_messages_added
- 自队列创建以来添加到给定队列的消息数。
artemis_message_count
- 给定队列中当前的消息数。这包括调度、页面和发送中消息。
artemis_messages_killed
- 从创建队列后,从给定队列中删除的消息数量。当消息超过配置的最大交付尝试次数时,代理会终止一条消息。
artemis_messages_expired
- 自创建队列后,从给定队列已过期的消息数。
artemis_persistent_size
- 当前处于给定队列中的所有消息的持久性大小(durable 和不可durable)。这包括调度、页面和发送中消息。
artemis_scheduled_durable_message_count
- 给定队列中调度的消息数量。
artemis_scheduled_durable_persistent_size
- 持久大小,在给定队列中调度的消息。
artemis_scheduled_message_count
- 指定队列中调度的消息数。
artemis_scheduled_persistent_size
- 在给定队列中调度的消息的持久性大小。
对于以上未列出的高级代理指标,您可以通过聚合较低级别指标来计算这些指标。例如,要计算总消息计数,您可以聚合代理部署中的所有队列的 artemis_message_count
指标。
对于 AMQ Broker 的内部部署,托管代理的 Java 虚拟机(JVM)的指标也会导出到 Prometheus 格式。这不适用于在 OpenShift Container Platform 上部署 AMQ Broker。
7.2.2. 使用 CR 启用 Prometheus 插件
安装 AMQ Broker 时,安装中包含 Prometheus metrics 插件。启用后,插件会为代理收集运行时指标,并将其导出为 Prometheus 格式。
以下流程演示了如何使用 CR 为 AMQ Broker 启用 Prometheus 插件。此流程支持 AMQ Broker 7.9 或更高版本的新部署。
有关运行代理的替代流程,请参阅 第 7.2.3 节 “使用环境变量为正在运行的代理部署启用 Prometheus 插件”。
流程
打开用于代理部署的 CR 实例。例如,基本部署的 CR 可能类似以下:
apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 4 image: registry.redhat.io/amq7/amq-broker-rhel8:7.10 ...
在
deploymentPlan
部分中,添加enableMetricsPlugin
属性并将值设为true
,如下所示。apiVersion: broker.amq.io/v1beta1 kind: ActiveMQArtemis metadata: name: ex-aao application: ex-aao-app spec: deploymentPlan: size: 4 image: registry.redhat.io/amq7/amq-broker-rhel8:7.10 ... enableMetricsPlugin: true
- enableMetricsPlugin
- 指定部署中的代理是否启用 Prometheus 插件。
- 保存 CR 实例。
切换到之前创建的代理部署的项目。
$ oc project <project_name>
在命令行中应用更改。
$ oc apply -f <path/to/custom_resource_instance>.yaml
metrics 插件开始以 Prometheus 格式收集代理运行时指标。
其他资源
- 有关更新正在运行的代理的详情,请参考 第 3.4.3 节 “对运行代理部署应用自定义资源更改”。
7.2.3. 使用环境变量为正在运行的代理部署启用 Prometheus 插件
以下流程演示了如何使用环境变量为 AMQ Broker 启用 Prometheus 插件。对于替代流程,请参阅 第 7.2.2 节 “使用 CR 启用 Prometheus 插件”。
先决条件
- 您可以为使用 AMQ Broker Operator 创建的代理 Pod 启用 Prometheus 插件。但是,您部署的代理必须使用 AMQ Broker 7.7 或更高版本的代理容器镜像。
流程
- 使用包含代理部署的项目的管理员权限登录到 OpenShift Container Platform Web 控制台。
- 在 Web 控制台中,点 → 。选择包含代理部署的项目。
- 要查看项目中的 StatefulSets 或 DeploymentConfig,请点击 → 或 → 。
- 点击与代理部署对应的 StatefulSet 或 DeploymentConfig。
- 要访问代理部署的环境变量,请单击 Environment 选项卡。
添加新的环境变量
AMQ_ENABLE_METRICS_PLUGIN
。将 变量的值设置为true
。当您设置
AMQ_ENABLE_METRICS_PLUGIN
环境变量时,OpenShift 会在 StatefulSet 或 DeploymentConfig 中重启每个代理 Pod。在部署中有多个 Pod 时,OpenShift 会依次重启每个 Pod。当每个代理 Pod 重启时,代理的 Prometheus 插件会开始收集代理运行时指标。
7.2.4. 访问正在运行的代理 Pod 的 Prometheus 指标
此流程演示了如何访问正在运行的代理 Pod 的 Prometheus 指标。
先决条件
- 您必须已经为代理 Pod 启用了 Prometheus 插件。请参阅 第 7.2.3 节 “使用环境变量为正在运行的代理部署启用 Prometheus 插件”。
流程
对于您要访问的指标的代理 Pod,您需要识别之前创建的路由,以将 Pod 连接到 AMQ Broker 管理控制台。访问指标所需的 URL 的 Route 名称表单部分。
- 点击 → 。
对于您选择的代理 Pod,标识为将 Pod 连接到 AMQ Broker 管理控制台而创建的路由。在 Hostname 下,请注意显示的完整 URL。例如:
http://rte-console-access-pod1.openshiftdomain
要访问 Prometheus 指标,在网页浏览器中输入之前记录的 Route 名称,并附加
"/metrics
"。例如:http://rte-console-access-pod1.openshiftdomain/metrics
如果您的控制台配置没有使用 SSL,请在 URL 中指定 http
。在这种情况下,主机名的 DNS 解析会将流量定向到 OpenShift 路由器的端口 80。如果您的控制台配置使用 SSL,在 URL 中指定 https
。在这种情况下,您的浏览器默认为 OpenShift 路由器的端口 443。如果 OpenShift 路由器也使用端口 443 用于 SSL 流量,这可成功连接到控制台,路由器默认具有此端口。
7.3. 使用 JMX 监控代理运行时数据
本例演示了如何使用 Jolokia REST 接口监控到 JMX 的代理。
先决条件
- 建议完成部署基本代理。
流程
获取正在运行的 pod 列表:
$ oc get pods NAME READY STATUS RESTARTS AGE ex-aao-ss-1 1/1 Running 0 14d
运行
oc logs
命令:$ oc logs -f ex-aao-ss-1 ... Running Broker in /home/jboss/amq-broker ... 2021-09-17 09:35:10,813 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2021-09-17 09:35:10,882 INFO [org.apache.activemq.artemis.core.server] AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=data/journal,bindingsDirectory=data/bindings,largeMessagesDirectory=data/large-messages,pagingDirectory=data/paging) 2021-09-17 09:35:10,971 INFO [org.apache.activemq.artemis.core.server] AMQ221013: Using NIO Journal 2021-09-17 09:35:11,114 INFO [org.apache.activemq.artemis.core.server] AMQ221057: Global Max Size is being adjusted to 1/2 of the JVM max size (-Xmx). being defined as 2,566,914,048 2021-09-17 09:35:11,369 WARNING [org.jgroups.stack.Configurator] JGRP000014: BasicTCP.use_send_queues has been deprecated: will be removed in 4.0 2021-09-17 09:35:11,385 WARNING [org.jgroups.stack.Configurator] JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead 2021-09-17 09:35:11,480 INFO [org.jgroups.protocols.openshift.DNS_PING] serviceName [ex-aao-ping-svc] set; clustering enabled 2021-09-17 09:35:24,540 INFO [org.openshift.ping.common.Utils] 3 attempt(s) with a 1000ms sleep to execute [GetServicePort] failed. Last failure was [javax.naming.CommunicationException: DNS error] ... 2021-09-17 09:35:25,044 INFO [org.apache.activemq.artemis.core.server] AMQ221034: Waiting indefinitely to obtain live lock 2021-09-17 09:35:25,045 INFO [org.apache.activemq.artemis.core.server] AMQ221035: Live Server Obtained live lock 2021-09-17 09:35:25,206 INFO [org.apache.activemq.artemis.core.server] AMQ221080: Deploying address DLQ supporting [ANYCAST] 2021-09-17 09:35:25,240 INFO [org.apache.activemq.artemis.core.server] AMQ221003: Deploying ANYCAST queue DLQ on address DLQ 2021-09-17 09:35:25,360 INFO [org.apache.activemq.artemis.core.server] AMQ221080: Deploying address ExpiryQueue supporting [ANYCAST] 2021-09-17 09:35:25,362 INFO [org.apache.activemq.artemis.core.server] AMQ221003: Deploying ANYCAST queue ExpiryQueue on address ExpiryQueue 2021-09-17 09:35:25,656 INFO [org.apache.activemq.artemis.core.server] AMQ221020: Started EPOLL Acceptor at ex-aao-ss-1.ex-aao-hdls-svc.broker.svc.cluster.local:61616 for protocols [CORE] 2021-09-17 09:35:25,660 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live 2021-09-17 09:35:25,660 INFO [org.apache.activemq.artemis.core.server] AMQ221001: Apache ActiveMQ Artemis Message Broker version 2.16.0.redhat-00022 [amq-broker, nodeID=8d886031-179a-11ec-9e02-0a580ad9008b] 2021-09-17 09:35:26,470 INFO [org.apache.amq.hawtio.branding.PluginContextListener] Initialized amq-broker-redhat-branding plugin 2021-09-17 09:35:26,656 INFO [org.apache.activemq.hawtio.plugin.PluginContextListener] Initialized artemis-plugin plugin ...
运行查询来监控
MaxConsumers
的代理:$ curl -k -u admin:admin http://console-broker.amq-demo.apps.example.com/console/jolokia/read/org.apache.activemq.artemis:broker=%22broker%22,component=addresses,address=%22TESTQUEUE%22,subcomponent=queues,routing-type=%22anycast%22,queue=%22TESTQUEUE%22/MaxConsumers {"request":{"mbean":"org.apache.activemq.artemis:address=\"TESTQUEUE\",broker=\"broker\",component=addresses,queue=\"TESTQUEUE\",routing-type=\"anycast\",subcomponent=queues","attribute":"MaxConsumers","type":"read"},"value":-1,"timestamp":1528297825,"status":200}
第 8 章 参考
8.1. 自定义资源配置参考
自定义资源定义(CRD)是使用 Operator 部署的自定义 OpenShift 对象的配置项目的模式。通过部署对应的自定义资源(CR)实例,您可以为 CRD 中显示的配置项目指定值。
以下子部分详细介绍了基于主代理 CRD 在自定义资源实例中设置的配置项。
8.1.1. 代理自定义资源配置参考
基于主代理 CRD 的 CR 实例可让您在 OpenShift 项目中为部署配置代理。下表描述了您可以在 CR 实例中配置的项目。
部署的任何对应自定义资源(CR)中需要标记为星号(*)的配置项。如果您没有为非必需项显式指定值,则配置将使用默认值。
条目 | 子条目 | 描述和使用 |
---|---|---|
| 连接到代理和管理控制台所需的管理员用户名。
如果没有指定值,则值会自动生成并存储在 secret 中。默认 secret 名称的格式为 < 键入: string 示例 :my-user 默认值 :自动生成的随机值 | |
| 连接到代理和管理控制台所需的管理员密码。
如果没有指定值,则值会自动生成并存储在 secret 中。默认 secret 名称的格式为 < 键入: string 示例 :my-password 默认值 :自动生成的随机值 | |
| 代理部署配置 | |
| 部署中每个代理的代理容器镜像的完整路径。
您不需要在 CR 中为 要了解 Operator 如何选择要使用的代理容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”。 键入: string 示例 :registry.redhat.io/amq7/amq-broker-rhel8@sha256:982ba18be1ac285722bc0ca8e85d2a42b8b844ab840b01425e79e3eeee6ee5b9 默认值 :占位符 | |
| 要在部署中创建的代理 Pod 数量。
如果您指定一个 2 或更高值,则代理部署会默认集群。默认情况下,集群用户名和密码会自动生成并存储在与 键入: int 示例 :1 默认值 :2 | |
| 指定是否需要登录凭证才能连接到代理。 类型 :布尔值 示例 :false 默认值: true | |
|
指定部署中的每个代理 Pod 使用 journal 存储。如果设置为 类型 :布尔值 示例 :false 默认值: true | |
| 用于配置代理的 init 容器镜像。
您不需要在 CR 中为 要了解 Operator 如何选择要使用的内置初始容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”。 要了解如何 指定自定义 Init 容器镜像,请参阅 第 4.7 节 “指定自定义 Init 容器镜像”。 键入: string 示例 :registry.redhat.io/amq7/amq-broker-init-rhel8@sha256:f37f98c809c6f29a83e3d5a3ac4494e28efe9b25d33c54f533c6a08662244622 默认值 : 未指定 | |
| 指定是否使用异步 I/O(AIO)或非阻塞 I/O(NIO)。 键入: string 示例 :aio 默认值为: nio | |
| 当代理 Pod 因为代理部署的意图而关闭时,指定是否将消息迁移到仍在代理集群中运行的另一个代理 Pod。 类型 :布尔值 示例 :false 默认值: true | |
| 主机节点 CPU 的最大数量,单位为 millicore,部署中的 Pod 中运行的每个代理容器都可消耗。 键入: string 示例 :"500m" 默认值 : 使用与 OpenShift Container Platform 版本相同的默认值。查阅集群管理员。 | |
| 主机节点内存的最大数量,以字节为单位,部署中的 Pod 中运行的每个代理容器都可消耗。支持字节表示法(例如 K、M、G)或二进制等同的标记(Ki、Mi、Gi)。 键入: string 示例 :"1024M" 默认值 : 使用与 OpenShift Container Platform 版本相同的默认值。查阅集群管理员。 | |
| 主机节点 CPU 的数量,单位为 millicore,部署中的每个代理容器都明确请求在 Pod 中运行。 键入: string 示例 : "250m" 默认值 : 使用与 OpenShift Container Platform 版本相同的默认值。查阅集群管理员。 | |
| 主机节点内存量(以字节为单位),即在显式部署请求中 Pod 中运行的每个代理容器。支持字节表示法(例如 K、M、G)或二进制等同的标记(Ki、Mi、Gi)。 键入: string 示例 :"512M" 默认值 : 使用与 OpenShift Container Platform 版本相同的默认值。查阅集群管理员。 | |
|
以字节为单位,部署中每个代理所需的持久性卷声明(PVC)的大小(以字节为单位)。此属性仅在将 键入: string 示例 :4Gi 默认值 :2Gi | |
|
指定部署中的代理是否为 Jolokia JVM Agent 启用。如果此属性的值设置为 类型 :布尔值 示例 :true 默认值: false | |
|
指定部署中的代理是否启用了基于角色的访问控制(RBAC)。要使用 Fuse 控制台,您必须 将值设为 类型 :布尔值 示例 :false 默认值: true | |
| 指定 pod 的调度限制。有关关联性属性的信息,请参阅 OpenShift Container Platform 文档中的 属性。 | |
| 指定 pod 的容限。如需有关 tolerations 属性的信息,请参阅 OpenShift Container Platform 文档中的 属性。 | |
| 指定与要调度到该节点上的 pod 标签匹配的标签。 | |
| 指定用于 PVC 的存储类的名称。存储类为管理员提供描述和分类可用存储的方法。例如,存储类可能具有特定的质量级别的服务质量、备份策略或其他与其关联的管理策略。 键入: string 示例: gp3 默认值 : 未指定 | |
| 在正在运行的代理容器上配置定期健康检查,以检查代理是否正在运行。如需有关存活度探测属性的信息,请参阅 OpenShift Container Platform 文档中的 属性。 | |
| 在正在运行的代理容器上配置定期健康检查,以检查代理是否接受网络流量。有关就绪度探测属性的详情,请查看 OpenShift Container Platform 文档中的 属性。 | |
| 为代理 pod 分配标签。 键入: string 示例 :位置:"生产环境" 默认值 : 未指定 | |
| 代理管理控制台配置。 | |
| 指定是否在部署中的每个代理公开管理控制台端口。 类型 :布尔值 示例 :true 默认值: false | |
| 指定是否在管理控制台端口中使用 SSL。 类型 :布尔值 示例 :true 默认值: false | |
|
存储代理密钥存储、信任存储及其对应密码(所有 Base64 编码的)的 secret。如果没有为 键入: string 示例 :my-broker-deployment-console-secret 默认值 : 未指定 | |
| 为代理 pod 指定服务帐户名称。 键入: string 示例 :activemq-artemis-controller-manager 默认值 :default | |
| 指定以下 pod 级别安全属性和常见容器设置。 * fsGroup * fsGroupChangePolicy * runAsGroup * runAsUser * runAsNonRoot * seLinuxOptions * seccompProfile * supplementalGroups * sysctls * windowsOptions
如需有关 | |
| 指定管理控制台是否需要客户端授权。 类型 :布尔值 示例 :true 默认值: false | |
| 单个接受器配置实例。 | |
| 接受者名称. 键入: string 示例 :my-acceptor 默认值 :不适用 | |
| 用于接受或实例的端口号。 键入: int 示例 :5672 默认值 :61626,用于您定义的第一个接受者。然后,您定义的每个后续接受者会增加 10。 | |
| 在接受器实例上启用消息传递协议。 键入: string : amqp,core 默认值 :all | |
|
指定是否在接受器端口上启用 SSL。如果设置为 类型 :布尔值 示例 :true 默认值: false | |
| 存储代理密钥存储、信任存储及其对应密码(所有 Base64 编码的)的 secret。
如果您没有为 即使接受者假设默认名称,您也必须自行创建此 secret。 键入: string 示例 :my-broker-deployment-my-acceptor-secret 默认值: & lt;custom_resource_name>- <acceptor_name> -secret | |
| 用于 TLS/SSL 通信的密码套件的逗号分隔列表。
指定客户端应用程序支持的最安全密码套件。如果您使用逗号分隔列表指定代理和客户端的一组密码套件,或者您不指定任何密码套件,则代理和客户端会相互协商要使用的密码套件。如果您不知道要指定哪些密码套件,建议您首先与以 debug 模式运行的客户端建立 broker-client 连接,以验证代理和客户端是通用的密码套件。然后,在代理中配置 键入: string 默认值 : 未指定 | |
| 代理使用的密钥存储的供应商名称。 键入: string 示例 :SunJCE 默认值 : 未指定 | |
| 代理使用的信任存储供应商名称。 键入: string 示例 :SunJCE 默认值 : 未指定 | |
| 代理使用的信任存储类型。 键入: string 示例 :JCEKS 默认值 :JKS | |
| 用于 TLS/SSL 通信的以逗号分隔的协议列表。 键入: string 示例 : TLSv1,TLSv1.1,TLSv1.2 默认值 : 未指定 | |
|
指定代理是否告知客户端在接受者上需要双向 TLS。此属性覆盖 类型 :布尔值 示例 :true 默认值 : 未指定 | |
|
指定代理是否告知客户端在接受者上 请求 双向 TLS,但不强制要求。此属性将被 类型 :布尔值 示例 :true 默认值 : 未指定 | |
| 指定是否将客户端证书的 Common Name(CN)与其主机名进行比较,以验证它们是否匹配。这个选项仅在使用双向 TLS 时适用。 类型 :布尔值 示例 :true 默认值 : 未指定 | |
| 指定 SSL 供应商是 JDK 还是 OPENSSL。 键入: string 示例 :OPENSSL 默认值 : JDK | |
|
与传入连接上的 键入: string 示例 : some_regular_expression 默认值 : 未指定 | |
| 指定是否向 OpenShift Container Platform 之外的客户端公开接受者。 当您向 OpenShift 外部的客户端公开接收器时,Operator 会自动为部署中的每个代理 Pod 创建一个专用的服务和路由。 类型 :布尔值 示例 :true 默认值: false | |
|
客户端使用的前缀来指定应使用任何 键入: string 示例 :jms.queue 默认值 : 未指定 | |
|
客户端用来指定应该使用 键入: string 示例 :/topic/ 默认值 : 未指定 | |
| 接受者上允许的连接数。达到此限制时,会向日志发出 DEBUG 消息,并且连接将被拒绝。使用中的客户端类型决定了连接被拒绝时发生的情况。 键入: integer 示例 :2 默认值 : 0(无限连接) | |
|
代理至少需要消息大小,以便代理将 AMQP 消息作为较大消息处理。如果 AMQP 消息的大小等于或大于这个值,代理会将消息存储在大型消息目录中( 键入: integer 示例 : 204800 默认值为: 102400(100 KB) | |
| 如果设置为 true,则使用 0.0.0.0 IP 地址(而非 pod 的内部 IP 地址)配置代理接受器。当代理接受者具有 0.0.0.0 IP 地址时,它们绑定到为 pod 配置的所有接口,客户端通过使用 OpenShift Container Platform 端口转发将流量定向到代理。通常,您要使用这个配置来调试服务。如需有关端口转发的更多信息,请参阅 OpenShift Container Platform 文档中的使用 端口转发访问容器中的应用程序。 注意 如果错误地使用端口转发,则可能会给您的环境造成安全隐患。在可能的情况下,红帽建议您不要在生产环境中使用端口转发。 类型 :布尔值 示例 :true 默认值: false | |
| 单一连接器配置实例。 | |
| 连接器名称。 键入: string 示例 :my-connector 默认值 :不适用 | |
|
要创建的连接器类型,即 键入: string 示例 :vm 默认值 :tcp | |
| 要连接到的主机名或 IP 地址。 键入: string 示例 :192.168.0.58 默认值 : 未指定 | |
| 用于连接器实例的端口号。 键入: int 示例 : 22222 默认值 : 未指定 | |
|
指定是否在连接器端口上启用 SSL。如果设置为 类型 :布尔值 示例 :true 默认值: false | |
| 存储代理密钥存储、信任存储及其对应密码(所有 Base64 编码的)的 secret。
如果您没有为 即使连接器假定默认名称,您也必须自行创建此 secret。 键入: string 示例 :my-broker-deployment-my-connector-secret 默认值: & lt;custom_resource_name>- <connector_name> -secret | |
| 用于 TLS/SSL 通信的密码套件的逗号分隔列表。 键入: string 注意 : 对于连接器,建议您不要 指定密码套件列表。 默认值 : 未指定 | |
| 代理使用的密钥存储的供应商名称。 键入: string 示例 :SunJCE 默认值 : 未指定 | |
| 代理使用的信任存储供应商名称。 键入: string 示例 :SunJCE 默认值 : 未指定 | |
| 代理使用的信任存储类型。 键入: string 示例 :JCEKS 默认值 :JKS | |
| 用于 TLS/SSL 通信的以逗号分隔的协议列表。 键入: string 示例 : TLSv1,TLSv1.1,TLSv1.2 默认值 : 未指定 | |
|
指定代理是否告知客户端在连接器上需要双向 TLS。此属性覆盖 类型 :布尔值 示例 :true 默认值 : 未指定 | |
|
指定代理是否告知客户端在连接器上 请求 双向 TLS,但不要求。此属性将被 类型 :布尔值 示例 :true 默认值 : 未指定 | |
| 指定是否将客户端证书的 Common Name(CN)与其主机名进行比较,以验证它们是否匹配。这个选项仅在使用双向 TLS 时适用。 类型 :布尔值 示例 :true 默认值 : 未指定 | |
|
指定 SSL 供应商是 键入: string 示例 :OPENSSL 默认值 : JDK | |
|
与传出连接上的 键入: string 示例 : some_regular_expression 默认值 : 未指定 | |
| 指定是否将连接器公开给 OpenShift Container Platform 之外的客户端。 类型 :布尔值 示例 :true 默认值: false | |
| 指定 Operator 如何为每个匹配地址或一组地址应用您添加到 CR 中的配置。 您可以指定的值有:
键入: string 示例 : replace_all 默认值 :merge_all | |
| 匹配地址 或一组 地址的地址设置。 | |
|
指定配置有
键入: string 示例 : DROP 默认值 :PAGE | |
| 指定代理在客户端发送信息时是否自动创建地址,还是尝试使用来自消息的队列(绑定到不存在的地址的队列)。 类型 :布尔值 示例 :false 默认值: true | |
| 指定代理是否自动创建死信地址和队列来接收未传输的消息。
如果 参数设置为 类型 :布尔值 示例 :true 默认值: false | |
| 指定代理是否自动创建地址和队列来接收过期的消息。
如果 参数设置为 类型 :布尔值 示例 :true 默认值: false | |
|
此属性已弃用。改为使用 | |
|
此属性已弃用。改为使用 | |
| 指定代理在客户端发送消息时是否自动创建队列,还是尝试使用消息中的消息,即不存在的队列。 类型 :布尔值 示例 :false 默认值: true | |
| 指定代理不再有队列时,代理是否自动删除自动创建的地址。 类型 :布尔值 示例 :false 默认值: true | |
| 这个时间(以毫秒为单位),代理会在地址没有队列时自动删除自动创建的地址。 键入: integer 示例 :100 默认值 :0 | |
|
此属性已弃用。改为使用 | |
|
此属性已弃用。改为使用 | |
| 指定当队列没有使用者且没有消息时,代理是否自动删除自动创建的队列。 类型 :布尔值 示例 :false 默认值: true | |
| 指定当队列没有使用者且没有消息时,代理是否自动删除手动创建的队列。 类型 :布尔值 示例 :true 默认值: false | |
| 这个时间(以毫秒为单位),代理会在队列没有消费者时自动删除自动创建的队列。 键入: integer 示例 :10 默认值 :0 | |
| 在代理评估队列是否可自动删除前,可以处于队列中的最大消息数。 键入: integer 示例 :5 默认值 :0 | |
| 当配置文件重新加载时,这个参数指定如何处理从配置文件中删除的地址(及其队列)。您可以指定以下值:
键入: string 示例 : FORCE 默认值 :OFF | |
| 当配置文件重新加载时,此设置指定代理如何处理从配置文件中删除的队列。您可以指定以下值:
键入: string 示例 : FORCE 默认值 :OFF | |
| 代理发送到的地址(即,未发送)消息。 键入: string : DLA 示例 默认值: None | |
| 代理应用到自动创建死信队列的名称前缀。 键入: string 示例 :myDLQ. 默认值 :DLQ. | |
| 代理应用到自动创建的死信队列的后缀。 键入: string 示例 : .DLQ 默认值: None | |
| 在自动创建的地址上使用的路由类型。 键入: string 示例 : ANYCAST 默认值 :MULTICAST | |
| 在消息分配可以开始地址上的队列前所需的消费者数量。 键入: integer 示例 :5 默认值 :0 | |
| 消费者的默认窗口大小,以字节为单位。 键入: integer 示例 :300000 默认值 : 1048576(1024*1024) | |
|
默认时间(以毫秒为单位),如果尚未达到 键入: integer 示例 :5 默认值 : -1(无延迟) | |
| 指定默认情况下是否有地址上所有队列都是独占队列。 类型 :布尔值 示例 :true 默认值: false | |
| 用于消息分组的存储桶数。 键入: integer 示例 :0(禁用消息分组) 默认值 : -1(无限制) | |
| 用于指示组中消息先到的消费者的键。 键入: string 示例: firstMessageKey 默认值: None | |
| 指定在新消费者连接到代理时是否重新平衡组。 类型 :布尔值 示例 :true 默认值: false | |
| 指定在代理重新平衡组时是否暂停消息发送。 类型 :布尔值 示例 :true 默认值: false | |
| 指定地址上所有队列是否默认为最后值队列。 类型 :布尔值 示例 :true 默认值: false | |
| 用于最后一个值队列的默认键。 键入: string 示例 : stock_ticker 默认值: None | |
| 队列上允许的最大消费者数量。 键入: integer 示例 :100 默认值 : -1(无限制) | |
| 默认情况下,指定地址上所有队列是否不是破坏性。 类型 :布尔值 示例 :true 默认值: false | |
| 指定代理是否在没有消费者时清除队列的内容。 类型 :布尔值 示例 :true 默认值: false | |
|
在自动创建的队列中使用的路由类型。默认值为 键入: string 示例 : ANYCAST 默认值 :MULTICAST | |
| 没有明确设置环大小的匹配队列的默认环大小。 键入: integer 示例 :3 默认值 : -1(无大小限制) | |
| 指定配置了指标插件,如 Prometheus 插件会为匹配地址或一组地址收集指标。 类型 :布尔值 示例 :false 默认值: true | |
| 接收过期消息的地址。 键入: string 示例 :myExpiryAddress 默认值: None | |
| 过期时间(以毫秒为单位)应用于使用默认的过期时间。 键入: integer 示例 :100 默认值 : -1(没有应用过期时间) | |
| 代理应用到自动创建到期队列的名称前缀。 键入: string 示例 :myExp. 默认值 :EXP。 | |
| 代理应用于自动创建到期队列名称的后缀。 键入: string 示例 : .EXP 默认值: None | |
| 指定队列是否只使用最后的值。 类型 :布尔值 示例 :true 默认值: false | |
| 指定管理资源可以浏览多少消息。 键入: integer 示例 :100 默认值 :200 | |
| 与代理中配置的地址设置匹配的字符串。您可以指定一个准确的地址名称,或使用通配符表达式将地址设置与一组地址匹配。
如果您使用通配符表达式作为 键入: string 示例 :"myAddresses*" 默认值: None | |
| 指定代理在发送消息到配置的死信地址前尝试传递的次数。 键入: integer 示例 :20 默认值 :10 | |
| 过期时间(以毫秒为单位)应用于使用超过这个值的过期时间的信息。 键入: integer 示例 :20 默认值 : -1(没有应用最大到期时间) | |
| 代理重新发送尝试之间的最大值(以毫秒为单位)。 键入: integer 示例 :100
默认值 : | |
|
地址的最大内存大小,以字节为单位。当 键入: string 示例 :10Mb 默认值 : -1(无限制) | |
|
最大大小(以字节为单位),一个地址可在代理开始拒绝信息前访问。当 键入: integer 示例 :500 默认值 : -1(无最大大小) | |
| 代理为地址保留消息计数器历史记录的天数。 键入: integer 示例 :5 默认值 :0 | |
| 过期时间(以毫秒为单位)应用于使用过期时间低于这个值的消息。 键入: integer 示例 :20 默认值 : -1(没有应用最小过期时间) | |
| 要保留内存的页面文件数量,以便在分页导航期间优化 I/O。 键入: integer 示例 :10 默认值 :5 | |
|
分页大小(以字节为单位)。还支持字节表示法,如 键入: string 示例 :20971520 默认值为: 10485760(approximately 10.5 MB) | |
| 代理在重出已取消消息前等待的时间(以毫秒为单位)。 键入: integer 示例 :100 默认值 :0 | |
|
应用于 键入: number 示例 :5 默认值 :1 | |
|
应用到重新交付 键入: number 示例 :1.1 默认值 :0 | |
| 在重新分发所有剩余消息前,代理会在队列上关闭最后一个消费者后等待这一时间。 键入: integer 示例 :100 默认值 : -1(未设置) | |
| 为在地址上创建未来的队列保留的消息数量。 键入: integer 示例 :100 默认值 :0 | |
| 如果无法路由到任何队列,请指定消息是否会被发送到配置的死信地址。 类型 :布尔值 示例 :true 默认值: false | |
| 代理检查较慢的用户的频率( 以秒为单位 )。 键入: integer 示例 :15 默认值 :5 | |
|
指定识别缓慢消费者时会发生什么。有效选项为 键入: string 示例 : KILL 默认值 : NOTIFY | |
| 在消费者被视为缓慢前,每秒消息消耗率最少。 键入: integer 示例 :100 默认值 : -1(未设置) | |
| 配置在代理的自定义资源定义(CRD)中不公开的代理属性,且在自定义资源(CR)中不能配置。 | |
|
为代理配置的属性名称和值列表。
键入: string 示例: globalMaxSize=512m 默认值 :不适用 | |
| ||
|
当您更新 类型 :布尔值 示例 :true 默认值: false | |
|
指定当您将 类型 :布尔值 示例 :true 默认值: false | |
|
指定您希望 Operator 自动更新 CR 的目标 次版本 AMQ Broker,以使用对应的代理容器镜像。例如,如果您将 键入: string 示例 : 7.7.0 默认值 : AMQ Broker 的当前版本 |
8.1.2. 地址自定义资源配置参考
基于地址 CRD 的 CR 实例可让您为部署中的代理定义地址和队列。下表详细介绍了您可以配置的项目。
部署的任何对应自定义资源(CR)中需要标记为星号(*)的配置项。如果您没有为非必需项显式指定值,则配置将使用默认值。
条目 | 描述和使用 |
---|---|
| 要在代理上创建的地址名称。 键入: string 示例 :address0 默认值 : 未指定 |
|
在代理上创建的队列名称。如果没有指定 键入: string 示例 : queue0 默认值 : 未指定 |
|
指定 Operator 在删除该部署的地址 CR 实例时,是否删除部署中的所有代理的现有地址。默认值为 类型 :布尔值 示例 :true 默认值: false |
|
要使用的路由类型,任何广播 键入: string 示例 :任何广播 默认值 :多播 |
8.1.3. 安全自定义资源配置参考
基于安全 CRD 的 CR 实例可让您为部署中的代理定义安全配置,包括:
- 用户和角色
-
登录模块,包括
propertiesLoginModule
、guestLoginModule
和keycloakLoginModule
- 基于角色的访问控制
- 控制台访问控制
很多选项都需要您了解安全代理中描述的 代理安全概念
下表详细介绍了您可以配置的项目。
部署的任何对应自定义资源(CR)中需要标记为星号(*)的配置项。如果您没有为非必需项显式指定值,则配置将使用默认值。
条目 | 子条目 | 描述和使用 |
---|---|---|
loginModules | 一个或多个登录模块配置。 登录模块可以是以下类型之一:
| |
propertiesLoginModule | name* | 登录模块的名称。 键入: string 示例 :my-login 默认值 :不适用 |
users.name* | 用户名。 键入: string 示例 :jdoe 默认值 :不适用 | |
users.password* | 用户的密码。 键入: string 示例 :password 默认值 :不适用 | |
users.roles | 角色的名称。 键入: string 示例 :查看器 默认值 :不适用 | |
guestLoginModule | name* | 客户机登录模块的名称。 键入: string 示例 :guest-login 默认值 :不适用 |
guestUser | guest 用户的名称。 键入: string 示例 :myguest 默认值 :不适用 | |
guestRole | guest 用户的角色名称。 键入: string 示例 :guest 默认值 :不适用 | |
keycloakLoginModule | name | KeycloakLoginModule 的名称 键入: string 示例 :sso 默认值 :不适用 |
moduleType | KeycloakLoginModule(directAccess 或 bearerToken)的类型 键入: string 示例: bearerToken 默认值 :不适用 | |
配置 | 以下配置项目与红帽单点登录以及 OpenID Connect 文档中的详细信息。 | |
configuration.realm* | KeycloakLoginModule 的域 键入: string 示例 :myrealm 默认值 :不适用 | |
configuration.realmPublicKey | 域的公钥 键入: string 默认值 :不适用 | |
configuration.authServerUrl* | keycloak 验证服务器的 URL 键入: string 默认值 :不适用 | |
configuration.sslRequired | 指定是否需要 SSL 键入: string 有效值为 'all'、'external' 和 'none'。 | |
configuration.resource* | 资源名称 应用程序的 client-id。每个应用程序都有一个用于标识应用程序的 client-id。 | |
configuration.publicClient | 指定这是公共客户端。 类型 :布尔值 默认值: false 示例 :false | |
configuration.credentials.key | 指定凭证密钥。 键入: string 默认值 :不适用 键入: string 默认值 :不适用 | |
configuration.credentials.value | 指定凭证值 键入: string 默认值 :不适用 | |
configuration.useResourceRoleMappings | 指定是否使用资源角色映射 类型 :布尔值 示例 :false | |
configuration.enableCors | 指定是否启用跨资源共享(CORS) 它将处理 CORS preflight 请求。它还将查看访问令牌来确定有效的来源。 类型 :布尔值 默认值: false | |
configuration.corsMaxAge | CORS 最大年龄 如果启用了 CORS,这会设置 Access-Control-Max-Age 标头的值。 | |
configuration.corsAllowedMethods | CORS 允许的方法 如果启用了 CORS,这会设置 Access-Control-Allow-Methods 标头的值。这应该是一个用逗号分开的字符串。 | |
configuration.corsAllowedHeaders | CORS 允许的标头 如果启用了 CORS,这会设置 Access-Control-Allow-Headers 标头的值。这应该是一个用逗号分开的字符串。 | |
configuration.corsExposedHeaders | CORS 公开的标头 如果启用了 CORS,这会设置 Access-Control-Expose-Headers 标头的值。这应该是一个用逗号分开的字符串。 | |
configuration.exposeToken | 指定是否公开访问令牌 类型 :布尔值 默认值: false | |
configuration.bearerOnly | 指定是否验证 bearer 令牌 类型 :布尔值 默认值: false | |
configuration.autoDetectBearerOnly | 指定是否只自动探测 bearer 令牌 类型 :布尔值 默认值: false | |
configuration.connectionPoolSize | 连接池的大小 键入: Integer 默认值 :20 | |
configuration.allowAnyHostName | 指定是否允许任何主机名 类型 :布尔值 默认值: false | |
configuration.disableTrustManager | 指定是否禁用信任管理器 类型 :布尔值 默认值: false | |
configuration.trustStore* | 信任存储的路径 这是 REQUIRED,除非 ssl-required 为 none 或 disable-trust-manager 为 true。 | |
configuration.trustStorePassword* | truststore 密码 如果设置了 truststore 且信任存储需要密码,则这是 REQUIRED。 | |
configuration.clientKeyStore | 客户端密钥存储的路径 键入: string 默认值 :不适用 | |
configuration.clientKeyStorePassword | 客户端密钥存储密码 键入: string 默认值 :不适用 | |
configuration.clientKeyPassword | 客户端密钥密码 键入: string 默认值 :不适用 | |
configuration.alwaysRefreshToken | 指定是否始终刷新令牌 类型 :布尔值 示例 :false | |
configuration.registerNodeAtStartup | 指定是否在启动时注册节点 类型 :布尔值 示例 :false | |
configuration.registerNodePeriod | 重新注册节点的周期 键入: string 默认值 :不适用 | |
configuration.tokenStore | 令牌存储类型(会话或 Cookie) 键入: string 默认值 :不适用 | |
configuration.tokenCookiePath | Cookie 存储的 Cookie 路径 键入: string 默认值 :不适用 | |
configuration.principalAttribute | 使用 OpenID Connect ID Token 属性填充 UserPrincipal 名称 OpenID Connect ID Token 属性,用于填充 UserPrincipal 名称:如果 token 属性为空,则默认为 sub。可能的值有 sub、preferred_username、电子邮件、name、nickname、given_name、family_name。 | |
configuration.proxyUrl | 代理 URL | |
configuration.turnOffChangeSessionIdOnLogin | 指定是否在成功登录时更改会话 id 类型 :布尔值 示例 :false | |
configuration.tokenMinimumTimeToLive | 刷新活跃访问令牌的最低时间 键入: Integer 默认值 :0 | |
configuration.minTimeBetweenJwksRequests | 为 Keycloak 检索新公钥的两个请求之间的最小间隔 键入: Integer 默认值 :10 | |
configuration.publicKeyCacheTtl | 为 Keycloak 检索新公钥的两个请求之间的最大间隔 键入: Integer 默认值 :86400 | |
configuration.ignoreOauthQueryParameter | 是否为 bearer 令牌处理关闭对 access_token 查询参数的处理 类型 :布尔值 示例 :false | |
configuration.verifyTokenAudience | 验证令牌是否包含这个客户端名称(资源)作为使用者 类型 :布尔值 示例 :false | |
configuration.enableBasicAuth | 是否支持基本身份验证 类型 :布尔值 默认值: false | |
configuration.confidentialPort | Keycloak 服务器用来通过 SSL/TLS 进行安全连接的机密端口 键入: Integer 示例 :8443 | |
configuration.redirectRewriteRules.key | 用于匹配重定向 URI 的正则表达式。 键入: string 默认值 :不适用 | |
configuration.redirectRewriteRules.value | 替换的字符串 键入: string 默认值 :不适用 | |
configuration.scope | DirectAccessGrantsLoginModule 的 OAuth2 范围参数 键入: string 默认值 :不适用 | |
securityDomains | 代理安全域 | |
brokerDomain.name | 代理域名 键入: string 示例: activemq 默认值 :不适用 | |
brokerDomain.loginModules |
一个或多个登录模块。每个条目以前必须在上面的 | |
brokerDomain.loginModules.name | 登录模块的名称 键入: string 示例 : prop-module 默认值 :不适用 | |
brokerDomain.loginModules.flag |
与 propertiesLoginModule、 键入: string 示例 : sufficient 默认值 :不适用 | |
brokerDomain.loginModules.debug | Debug | |
brokerDomain.loginModules.reload | reload | |
consoleDomain.name | 代理域名 键入: string 示例: activemq 默认值 :不适用 | |
consoleDomain.loginModules | 单一登录模块配置。 | |
consoleDomain.loginModules.name | 登录模块的名称 键入: string 示例 : prop-module 默认值 :不适用 | |
consoleDomain.loginModules.flag |
与 propertiesLoginModule、 键入: string 示例 : sufficient 默认值 :不适用 | |
consoleDomain.loginModules.debug | Debug 类型 :布尔值 示例 :false | |
consoleDomain.loginModules.reload | reload 类型 :布尔值 示例 :true 默认 :false | |
securitySettings |
要添加到 | |
broker.match | 安全设置部分的地址匹配模式。有关匹配模式 语法的详情,请参阅 AMQ Broker 通配符语法。 | |
broker.permissions.operationType | 安全设置的操作类型,如 设置权限 中所述。 键入: string 示例 :createAddress 默认值 :不适用 | |
broker.permissions.roles | 安全设置应用于这些角色,如 设置权限 中所述。 键入: string 示例 :root 默认值 :不适用 | |
securitySettings.management |
用于配置 | |
hawtioRoles | 允许登录到代理控制台的角色。 键入: string 示例 :root 默认值 :不适用 | |
connector.host | 用于连接管理 API 的连接器主机。 键入: string : myhost 默认值 :localhost | |
connector.port | 用于连接管理 API 的连接器端口。 键入: integer 示例 :1099 默认值: 1099 | |
connector.jmxRealm | 管理 API 的 JMX 域。 键入: string 示例: activemq 默认值 :activemq | |
connector.objectName | 管理 API 的 JMX 对象名称。 键入: String 示例 : connector:name=rmi 默认 : connector:name=rmi | |
connector.authenticatorType | 管理 API 身份验证类型。 键入: String 示例 :password 默认 :password | |
connector.secured | 管理 API 连接是否设有保护。 类型 :布尔值 示例 :true 默认值: false | |
connector.keyStoreProvider | 管理连接器的密钥存储提供程序。如果您设置了 connector.secured="true",则需要此项。默认值为 JKS。 | |
connector.keyStorePath | 密钥存储的位置。如果您设置了 connector.secured="true",则需要此项。 | |
connector.keyStorePassword | 管理连接器的密钥存储密码。如果您设置了 connector.secured="true",则需要此项。 | |
connector.trustStoreProvider | 如果您设置了 connector.secured="true",则管理连接器的信任存储供应商。 键入: String 示例 :JKS 默认 : JKS | |
connector.trustStorePath | 管理连接器的信任存储位置。如果您设置了 connector.secured="true",则需要此项。 键入: string 默认值 :不适用 | |
connector.trustStorePassword | 管理连接器的信任存储密码。如果您设置了 connector.secured="true",则需要此项。 键入: string 默认值 :不适用 | |
connector.passwordCodec | 管理连接器的 password codec。其密码码c 的完全限定类名称使用,如 配置文件 中的加密密码 所述。 | |
authorisation.allowedList.domain | allowedList 的域 键入: string 默认值 :不适用 | |
authorisation.allowedList.key | allowedList 的密钥 键入: string 默认值 :不适用 | |
authorisation.defaultAccess.method | defaultAccess List 的方法 键入: string 默认值 :不适用 | |
authorisation.defaultAccess.roles | defaultAccess List 角色 键入: string 默认值 :不适用 | |
authorisation.roleAccess.domain | roleAccess List 域 键入: string 默认值 :不适用 | |
authorisation.roleAccess.key | roleAccess List 键 键入: string 默认值 :不适用 | |
authorisation.roleAccess.accessList.method | roleAccess List 的方法 键入: string 默认值 :不适用 | |
authorisation.roleAccess.accessList.roles | roleAccess List 角色 键入: string 默认值 :不适用 | |
applyToCrNames | 将此安全配置应用到当前命名空间中指定 CR 定义的代理。* 或空字符串的值是适用于所有代理。 键入: string 示例 :my-broker 默认值 :由当前命名空间中 CR 定义的所有代理。 |
8.2. 应用程序模板参数
通过指定应用程序模板参数的值来执行 OpenShift Container Platform 镜像中的 AMQ Broker 配置。您可以配置以下参数:
参数 | 描述 |
---|---|
| 在以逗号分隔的列表中,指定代理中默认可用的地址。 |
| 指定应用于多路复用协议端口 61616 和 61617 的任播前缀。 |
| 启用集群。 |
| 指定用于集群的密码。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。 |
| 指定集群要使用的集群用户。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。 |
| 指定存储在代理用户名/密码、集群用户名/密码以及 truststore 和密钥存储密码等敏感凭证的 secret。 |
| 指定数据的目录。StatefulSets 中使用。 |
| 指定数据目录日志记录的目录。 |
|
指定要传递给 |
| 指定消息数据可以消耗的最大内存量。如果没有指定值,则会分配一半系统内存。 |
| 指定 SSL 密钥存储文件名。如果没有指定值,会生成一个随机密码,但不会配置 SSL。 |
| (可选)指定用于解密 SSL 密钥存储的密码。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。 |
|
指定挂载 secret 的目录。默认值为 |
| 仅针对 SSL,指定接受者将接受的最大连接数。 |
| 指定应用于多个协议端口 61616 和 61617 的多播前缀。 |
|
指定代理实例的名称。默认值为 |
| 指定用于向代理进行身份验证的密码。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。 |
|
指定以逗号分隔的列表中代理使用的消息协议。可用选项包括 |
| 在以逗号分隔的列表中,指定代理上默认可用的队列。 |
|
如果设置为 |
|
指定创建的角色的名称。默认值为 |
| 指定 SSL 信任存储文件名。如果没有指定值,会生成一个随机密码,但不会配置 SSL。 |
| (可选)指定用于解密 SSL 信任存储的密码。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。 |
| 指定用于向代理进行身份验证的用户名。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。 |
| 指定 OpenShift 内部使用的应用程序的名称。它用于服务、Pod 和其他应用程序中的其他对象的名称。 |
|
指定镜像。用于 |
|
指定镜像流命名空间。在 |
| 指定 OpenShift DNS ping 服务的端口号。 |
|
指定 OpenShift DNS ping 服务的名称。如果您为 |
| 指定数据库卷的持久性存储大小。 |
如果您将 broker.xml
用于自定义配置,那么该文件中指定的所有值都适用于以下参数,将覆盖为应用程序模板中的相同参数指定的值。
- AMQ_NAME
- AMQ_ROLE
- AMQ_CLUSTER_USER
- AMQ_CLUSTER_PASSWORD
8.3. 日志记录
除了查看 OpenShift 日志外,您还可以通过查看到容器控制台的 AMQ 日志来排除 OpenShift Container Platform 镜像上运行的 AMQ Broker。
流程
- 在命令行中运行以下命令:
$ oc logs -f <pass:quotes[<pod-name>]> <pass:quotes[<container-name>]>
更新于 2024-06-11