在 OpenShift 上部署 AMQ Broker


Red Hat AMQ Broker 7.10

对于使用 AMQ Broker 7.10

摘要

了解如何在 OpenShift Container Platform 上安装和部署 AMQ Broker。

使开源包含更多

红帽致力于替换我们的代码、文档和 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 安装方法)
地址 CRD

您可以根据此 CRD 部署 CR 实例,为代理部署创建地址和队列。

根据您安装 Operator 的方式,此 CRD 为:

  • Operator 安装存档(OpenShift CLI 安装方法)的 crds 目录中的 broker_activemqartemisaddress_crd 文件
  • OpenShift Container Platform Web 控制台的 Custom Resource Definitions 部分中的 ActiveMQArtemisAddresss CRD(OperatorHub 安装方法)
安全 CRD

您可以基于此 CRD 部署 CR 实例,以创建用户并将这些用户与安全上下文关联。

根据您安装 Operator 的方式,此 CRD 为:

  • Operator 安装存档(OpenShift CLI 安装方法)的 crds 目录中的 broker_activemqartemissecurity_crd 文件
  • OpenShift Container Platform Web 控制台的 Custom Resource Definitions 部分中的 ActiveMQArtemisSecurity CRD(OperatorHub 安装方法)。
scaleDown CRD

当实例化用于消息迁移的缩减控制器时,Operator 会根据这个 CRD 自动创建 CR 实例。

根据您安装 Operator 的方式,此 CRD 为:

  • Operator 安装存档(OpenShift CLI 安装方法)的 crds 目录中的 broker_activemqartemisscale_crd 文件
  • OpenShift Container Platform Web 控制台的 Custom Resource Definitions 部分中的 ActiveMQArtemisScaledown CRD(OperatorHub 安装方法)。

其他资源

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

  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_782
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_790
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_7100

IBM Z 上的 OpenShift Container Platform

  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_782_s390x
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_790_s390x
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_7100_s390x

IBM Power 系统上的 OpenShift Container Platform

  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_782_ppc64le
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_790_ppc64le
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_7100_ppc64le

每个环境变量的值都指定可通过红帽使用的代理容器镜像。例如:

- 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

  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_782
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_790
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_7100

IBM Z 上的 OpenShift Container Platform

  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_s390x_782
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_s390x_790
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_s390x_7100

IBM Power 系统上的 OpenShift Container Platform

  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_ppc64le_782
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_ppc64le_790
  • RELATED_IMAGE_ActiveMQ_Artemis_Broker_Init_ppc64le_7100

每个环境变量的值都指定红帽提供的初始容器镜像。例如:

- 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 版本)。

其他资源

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 所监视的命名空间。

流程

  1. 在 OpenShift Container Platform Web 控制台的左侧窗格中,点 WorkloadsDeployments
  2. Project 下拉列表中,选择 All Projects
  3. Filter Name 框中,指定一个字符串,如 amq,以显示集群中安装的 AMQ Broker 的 Operator。

    注意

    namespace 列中显示 部署 每个 Operator 的命名空间。

  4. 检查安装了 AMQ Broker 的每个安装 Operator 的命名空间,以监视

    1. 点 Operator 名称显示 Operator 详情并点击 YAML 选项卡。
    2. 搜索 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. 先决条件

3.2. 使用 CLI 安装 Operator

注意

每个 Operator 发行版本都要求您下载最新的 AMQ Broker 7.10.7 Operator 安装和示例文件,如下所述。

本节中的步骤演示了如何使用 OpenShift 命令行界面(CLI)在给定的 OpenShift 项目中安装和部署 AMQ Broker 7.10 的最新版本。在随后的步骤中,您可以使用此 Operator 部署一些代理实例。

3.2.1. 准备部署 Operator

在使用 CLI 部署 Operator 前,您必须下载 Operator 安装文件并准备部署。

流程

  1. 在 Web 浏览器中,导航到 AMQ Broker 7.10.7 发行版本的 Software Downloads 页面。
  2. 确保 Version 下拉列表的值设为 7.10.7,并且选择了 Releases 选项卡。
  3. AMQ Broker 7.10.7 Operator Installation and Example Files 旁边,点 Download

    下载 amq-broker-operator-7.10.7-ocp-install-examples.zip 压缩存档会自动开始。

  4. 将存档移到您选择的目录。以下示例将存档 移到名为 ~/broker/operator 的目录。

    $ mkdir ~/broker/operator
    $ mv amq-broker-operator-7.10.7-ocp-install-examples.zip ~/broker/operator
  5. 在您选择的目录中,提取存档的内容。例如:

    $ cd ~/broker/operator
    $ unzip amq-broker-operator-7.10.7-ocp-install-examples.zip
  6. 切换到提取存档时创建的目录。例如:

    $ cd amq-broker-operator-7.10.7-ocp-install-examples
  7. 以集群管理员身份登录 OpenShift Container Platform。例如:

    $ oc login -u system:admin
  8. 指定要安装 Operator 的项目。您可以创建新项目或切换到现有项目。

    1. 创建一个新项目

      $ oc new-project <project_name>
    2. 或者,切换到现有项目:

      $ oc project <project_name>
  9. 指定要与 Operator 搭配使用的服务帐户。

    1. 在您提取的 Operator 归档的 deploy 目录中,打开 service_account.yaml 文件。
    2. 确保 kind 元素设置为 ServiceAccount
    3. 如果要更改默认服务帐户名称,在 metadata 部分中,将 amq-broker-operator 替换为自定义名称。
    4. 在项目中创建服务帐户。

      $ oc create -f deploy/service_account.yaml
  10. 为 Operator 指定角色名称。

    1. 打开 role.yaml 文件。此文件指定 Operator 可以使用和修改资源。
    2. 确保 kind 元素设为 Role
    3. 如果要更改默认角色名称,在 metadata 部分中,将 amq-broker-operator 替换为自定义名称。
    4. 在项目中创建角色。

      $ oc create -f deploy/role.yaml
  11. 为 Operator 指定角色绑定。角色绑定根据您指定的名称将之前创建的服务帐户绑定到 Operator 角色。

    1. 打开 role_binding.yaml 文件。
    2. 确保 ServiceAccountRolename 值与 service_account.yamlrole.yaml 文件中指定的匹配。例如:

      metadata:
          name: amq-broker-operator
      subjects:
          kind: ServiceAccount
          name: amq-broker-operator
      roleRef:
          kind: Role
          name: amq-broker-operator
    3. 在项目中创建角色绑定。

      $ oc create -f deploy/role_binding.yaml
  12. 为 Operator 指定领导选举角色绑定。角色绑定根据您指定的名称将之前创建的服务帐户绑定到领导选举角色。

    1. 为 Operator 创建领导选举角色。

      $ oc create -f deploy/election_role.yaml
    2. 在项目中创建领导选举角色绑定。

      $ oc create -f deploy/election_role_binding.yaml
  13. (可选)如果希望 Operator 监视多个命名空间,请完成以下步骤:

    注意

    如果 OpenShift Container Platform 集群已经包含 AMQ Broker 安装的 Operator,您必须确保新的 Operator 不会监视与现有 Operator 相同的任何命名空间。有关如何识别现有 Operator 所监视的命名空间的信息,请参阅 识别现有 Operator 监视的命名空间

    1. 在您下载并提取的 Operator 归档的 deploy 目录中,打开 operator_yaml 文件。
    2. 如果您希望 Operator 监控集群中的所有命名空间,在 WATCH_NAMESPACE 部分中添加一个 value 属性,并将值设为星号。注释掉 WATCH_NAMESPACE 部分中的现有属性。例如:

      - name: WATCH_NAMESPACE
        value: "*"
      # valueFrom:
      #   fieldRef:
      #     fieldPath: metadata.namespace
      注意

      为了避免冲突,请确保多个 Operator 不会监视相同的命名空间。例如,如果您部署一个 Operator 来监控 集群中的所有命名空间,则无法部署另一个 Operator 来监控单独的命名空间。如果 Operator 已在集群中部署,您可以指定新 Operator 监视的命名空间列表,如下所述。

    3. 如果您希望 Operator 观察多个,但并非集群中的所有命名空间,在 WATCH_NAMESPACE 部分指定命名空间列表。确保排除现有 Operator 监视的任何命名空间。例如:

      - name: WATCH_NAMESPACE
        value: "namespace1, namespace2"`.
    4. 在您下载并提取的 Operator 归档的 deploy 目录中,打开 cluster_role_binding.yaml 文件。
    5. 在 Subjects 部分中,指定一个 与部署 Operator 的 OpenShift Container Platform 项目对应的命名空间。例如:

      Subjects:
      - kind: ServiceAccount
        name: activemq-artemis-controller-manager
        namespace: operator-project
      注意

      如果您之前使用早期版本的 Operator 部署代理,并且希望部署 Operator 来监控多个命名空间,请参阅 升级前

    6. 在项目中创建集群角色。

      $ oc create -f deploy/cluster_role.yaml
    7. 在项目中创建集群角色绑定。

      $ oc create -f deploy/cluster_role_binding.yaml

在下面的流程中,您要在项目中部署 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 时都会丢失任何现有数据。

    有关置备持久性存储的更多信息,请参阅:

流程

  1. 在 OpenShift 命令行界面(CLI)中,以集群管理员的身份登录到 OpenShift。例如:

    $ oc login -u system:admin
  2. 切换到您之前为 Operator 部署准备的项目。例如:

    $ oc project <project_name>
  3. 切换到之前提取 Operator 安装存档时创建的目录。例如:

    $ cd ~/broker/operator/amq-broker-operator-7.10.7-ocp-install-examples
  4. 部署 Operator 中包含的 CRD。您必须在部署和启动 Operator 前,在 OpenShift 集群中安装 CRD。

    1. 部署主代理 CRD。

      $ oc create -f deploy/crds/broker_activemqartemis_crd.yaml
    2. 部署地址 CRD。

      $ oc create -f deploy/crds/broker_activemqartemisaddress_crd.yaml
    3. 部署 scaledown 控制器 CRD。

      $ oc create -f deploy/crds/broker_activemqartemisscaledown_crd.yaml
    4. 部署安全 CRD:

      $ oc create -f deploy/crds/broker_activemqartemissecurity_crd.yaml
  5. 将与 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>
  6. 在您下载并提取的 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 值对应于特定的容器镜像标签。

  7. 部署 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。

其他资源

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 中提供。
  • 您需要有集群管理员特权。

流程

  1. 以集群管理员身份登录 OpenShift Container Platform Web 控制台。
  2. 在左侧导航菜单中,点 OperatorsOperatorHub
  3. OperatorHub 页面顶部的 Project 下拉菜单中,选择要在其上部署 Operator 的项目。
  4. 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

  5. Red Hat Integration - AMQ Broker for RHEL 8(Multiarch) Operator。在出现的对话框中,点 Install
  6. Install Operator 页面中:

    1. 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 and current-76 等频道,这些频道适用于较旧版本的 AMQ Broker,可以被忽略。
    2. Installation Mode 下,选择 Operator 监视的命名空间:

      • 集群上的特定命名空间 - Operator 已安装在该命名空间中,仅监控该命名空间以了解 CR 更改。
      • All namespaces - Operator 会监控所有命名空间以了解 CR 更改。
      注意

      如果您之前使用早期版本的 Operator 部署代理,而您希望部署 Operator 以观察多个命名空间,请参阅升级前的操作

  7. Installed Namespace 下拉菜单中选择您要在其中安装 Operator 的项目。
  8. 批准策略 下,确保选择了授权 Automatic 的单选按钮。这个选项指定对 Operator 的更新不需要手动批准才能进行安装。
  9. Install

当 Operator 安装完成后,Installed Operators 页将打开。您应该会看到 Red Hat Integration - AMQ Broker for RHEL 8(Multiarch) Operator 已安装到您指定的项目命名空间中。

其他资源

3.4. 创建基于 Operator 的代理部署

3.4.1. 部署基本代理实例

以下流程演示了如何使用自定义资源(CR)实例创建基本代理部署。

注意

先决条件

流程

当您成功安装 Operator 时,Operator 会运行并侦听与 CR 相关的更改。本例的步骤演示了如何使用 CR 实例在项目中部署基本代理。

  1. 开始为代理部署配置自定义资源(CR)实例。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在用于创建部署的项目中部署 CR 的用户身份登录 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在用于创建部署的项目中部署 CR 的用户登录到控制台。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 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-0ex-aao-s-1 等等。CR 中的应用程序名称作为 StatefulSet 上的标签出现在部署中。例如,您可以在 Pod 选择器中使用该标签。

  2. size 属性指定要部署的代理数量。指定为 2 个或更多个集群代理部署。但是,要部署单个代理实例,请确保该值设置为 1
  3. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 CR 后,点 Create
  4. 在 OpenShift Container Platform web 控制台中,点击 WorkloadsStatefulSets。您会看到一个名为 ex-aao-ss 的新 StatefulSet。

    1. ex-aao-s StatefulSet。您会看到一个 Pod,对应于您在 CR 中定义的单个代理。
    2. 在 StatefulSet 中,点 Pods 选项卡。点 ex-aao-ss Pod。在运行 Pod 的 Events 选项卡中,您会看到 broker 容器已启动。Logs 选项卡显示代理本身正在运行。
  5. 要测试代理是否正常运行,请访问代理 Pod 中的 shell 来发送一些测试消息。

    1. 使用 OpenShift Container Platform Web 控制台:

      1. 单击 WorkloadsPods
      2. ex-aao-ss Pod。
      3. 点击 Terminal 选项卡。
    2. 使用 OpenShift 命令行界面:

      1. 获取项目的 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
      2. 访问代理 Pod 的 shell。

        $ oc rsh ex-aao-ss-0
  6. 在 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

其他资源

3.4.2. 部署集群代理

如果项目中正在运行两个或多个代理 Pod,Pod 会自动组成代理集群。集群配置可让代理互相连接并根据需要重新分发信息,以进行负载平衡。

以下流程演示了如何部署集群代理。默认情况下,本部署中的代理 需要需要 负载平衡,这意味着代理仅将信息转发给具有匹配消费者的其他代理。

先决条件

流程

  1. 打开用于基本代理部署的 CR 文件。
  2. 对于集群的部署,请确保 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 项目的名称。

  3. 保存修改后的 CR 文件。
  4. 以有权在项目中创建基本代理部署的项目中部署 CR 的用户身份登录 OpenShift。

    $ oc login -u <user> -p <password> --server=<host:port>
  5. 切换到您之前在其中创建基本代理部署的项目。

    $ oc project <project_name>
  6. 在命令行中应用更改:

    $ oc apply -f <path/to/custom_resource_instance>.yaml

    在 OpenShift Container Platform Web 控制台中,根据 CR 中指定的数量,其他代理 Pod 会在您的项目中启动。默认情况下,在项目中运行的代理会被集群。

  7. 打开每个 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 会为每个代理生成地址设置配置,如下所述。

  1. 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>
  2. 如果您在自定义资源(CR)实例中指定了地址设置配置,Init 容器进程会进行配置并将其转换为 XML。
  3. 根据 CR 中的 applyRule 属性的值,Init 容器 合并 或者将 上面显示的默认地址设置配置替换为您在 CR 中指定的配置。这种合并或替换后是代理将使用的最终地址设置配置。
  4. 当 Init 容器完成生成代理配置(包括地址设置)时,代理应用程序容器会启动。开始时,代理容器会复制之前由 Init 容器使用的安装目录中的配置。您可以检查 broker.xml 配置文件中的地址设置配置。对于正在运行的代理,这个文件位于 /home/jboss/amq-broker/etc 目录中。

其他资源

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 环境变量的值。

默认情况下,安装目录有以下子目录:

子目录内容

<install_dir>/bin

运行代理所需的二进制文件和脚本。

<install_dir>/etc

配置文件.

<install_dir>/data

代理日志。

<install_dir>/lib

运行代理所需的 JAR 和库。

<install_dir>/log

代理日志文件。

<install_dir>/tmp

临时 Web 应用文件。

当 Init 容器完成生成代理配置后,代理应用程序容器会启动。开始时,代理容器会复制之前由 Init 容器使用的安装目录中的配置。当代理 Pod 初始化并运行时,代理配置位于代理的 /home/jboss/amq-broker 目录中(和子目录)。

其他资源

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 控制台中的 Administration自定义资源定义 下列出的 ActiveMQAretmisAddress CRD。
  • 要配置与特定地址匹配的地址和队列设置,您可以在用于创建代理部署的主自定义资源(CR)实例中包含配置。

    • 如果您使用 OpenShift CLI 安装 Operator,则主代理 CRD 是您下载并提取的 Operator 安装的 deploy/crds 中的 broker_activemqartemis_crd.yaml 文件。
    • 如果使用 OperatorHub 安装 Operator,则主代理 CRD 是 OpenShift Container Platform Web 控制台中的 Administration自定义资源定义 下列出的 ActiveMQAretmis CRD。

    通常,您可以为 OpenShift Container Platform 上的代理部署配置的地址和队列设置,完全相当于 Linux 或 Windows 上的独立代理部署。但是,您应该注意,这些设置是如何配置的一些变化。这些差别在以下子部分进行描述。

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

其他资源

4.2.2. 为基于 Operator 的代理部署创建地址和队列

以下流程演示了如何使用自定义资源(CR)实例将地址和相关队列添加到基于 Operator 的代理部署中。

注意

要在代理部署中创建多个地址和/或队列,您需要创建单独的 CR 文件并单独部署,在每个情况下指定新地址和/或队列名称。另外,每个 CR 实例的 name 属性必须是唯一的。

先决条件

流程

  1. 开始配置自定义资源(CR)实例,以定义代理部署的地址和队列。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemisaddress_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
      2. 根据地址 CRD 启动新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemisAddresss CRD。
      4. 实例 选项卡。
      5. 单击 Create ActiveMQArtemisAddress

        在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

  2. 在 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 项目的名称。

  3. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/address_custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 CR 后,点 Create
  4. (可选)若要使用 CR 实例删除之前添加到部署的地址和队列,请使用以下命令:

    $ oc delete -f <path/to/address_custom_resource_instance>.yaml

4.2.3. 将地址设置与基于 Operator 的代理部署中配置的地址匹配

如果向客户端发送一条消息失败,您可能不希望代理进行持续尝试传递消息。要防止有限发送尝试,您可以定义 死信地址和 一个关联的 死信队列。在指定的发送尝试次数后,代理会从其原始队列中删除未发送的消息,并将消息发送到配置的死信地址。系统管理员可以在以后消耗来自死信队列的未发送的消息来检查消息。

以下示例演示了如何为基于 Operator 的代理部署配置死信地址和队列。以下示例演示了如何进行:

  • 使用主代理自定义资源(CR)实例的 addressSetting 部分来配置地址设置。
  • 将这些地址设置与代理部署中的地址匹配。

先决条件

流程

  1. 开始配置 CR 实例,以添加死信地址和队列,以接收部署中的每个代理的消息。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemisaddress_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
      2. 根据地址 CRD 启动新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemisAddresss CRD。
      4. 实例 选项卡。
      5. 单击 Create ActiveMQArtemisAddress

        在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

  2. 在 CR 的 spec 部分,添加行以指定死信地址和队列以接收未传输的消息。例如:

    apiVersion: broker.amq.io/v1beta1
    kind: ActiveMQArtemisAddress
    metadata:
      name: ex-aaoaddress
    spec:
      ...
      addressName: myDeadLetterAddress
      queueName: myDeadLetterQueue
      routingType: anycast
      ...

    上述配置定义了一个名为 myDeadLetterAddress 的死信地址,其死信队列为 myDeadLetterQueueanycast 路由类型。

    注意

    metadata 部分中,您需要包含 namespace 属性,只有在 使用 OpenShift Container Platform Web 控制台来创建 CR 实例时才指定一个值。您应该指定的值是代理部署的 OpenShift 项目的名称。

  3. 部署地址 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到代理部署的项目。

        $ oc project <project_name>
      3. 创建地址 CR。

        $ oc create -f <path/to/address_custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 CR 后,点 Create
  4. 启动为代理部署配置自定义资源(CR)实例。

    1. 在示例 CR 文件中:

      1. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      2. 单击 ActiveMQArtemis CRD。
      3. 实例 选项卡。
      4. 单击 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 项目的名称。

  5. 在 CR 的 deploymentPlan 部分中,添加一个包含单个 addressSetting 部分的新 addressSettings 部分,如下所示。

    spec:
      deploymentPlan:
        size: 1
        image: placeholder
        requireLogin: false
        persistenceEnabled: true
        journalType: nio
        messageMigration: true
      addressSettings:
        addressSetting:
  6. match 属性的单个实例添加到 addressSetting 块。指定地址匹配表达式。例如:

    spec:
      deploymentPlan:
        size: 1
        image: placeholder
        requireLogin: false
        persistenceEnabled: true
        journalType: nio
        messageMigration: true
      addressSettings:
        addressSetting:
        -  match: myAddress
    匹配
    指定代理将配置应用到的地址 或一组 地址。在本例中,match 属性的值与一个名为 myAddress 的单个地址对应。
  7. 添加与未传输的消息相关的属性并指定值。例如:

    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 中。

  8. (可选)将类似的配置应用到另一个地址或一组地址。例如:

    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*'

  9. 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

  10. 部署代理 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 创建 CR 实例。

        $ oc create -f <path/to/broker_custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 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 的代理部署中。

先决条件

流程

您可以在创建代理部署前或之后部署安全 CR。但是,如果您在创建代理部署后部署安全 CR,代理 Pod 将重启来接受新配置。

  1. 开始配置自定义资源(CR)实例,以定义代理部署的用户和相关安全配置。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemissecurity_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
      2. 根据地址 CRD 启动新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemisSecurity CRD。
      4. 实例 选项卡。
      5. 单击 Create ActiveMQArtemisSecurity

        在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

  2. 在 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-modulepropertiesLoginModule 定义一个名为 sam 的用户,角色名为 sender
    • 名为 prop-modulepropertiesLoginModule,它定义名为 rob 的角色以及名为 receiver 的角色。

    这些角色的属性在 securityDomainsbrokerDomainbroker 部分中定义。例如,定义了 send 角色,以允许具有该角色的用户在任何地址上创建持久队列。默认情况下,配置会应用到当前命名空间中 CR 定义的所有已部署代理。要将配置限制为特定的代理部署,请使用 第 8.1.3 节 “安全自定义资源配置参考” 中描述的 applyToCrNames 选项。

    注意

    metadata 部分中,您需要包含 namespace 属性,只有在 使用 OpenShift Container Platform Web 控制台来创建 CR 实例时才指定一个值。您应该指定的值是代理部署的 OpenShift 项目的名称。

  3. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/address_custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 CR 后,点 Create

4.3.2. 将用户密码存储在 secret 中

为基于 Operator 的代理部署流程创建安全配置中,用户密码存储在 ActiveMQArtemisSecurity CR 中的明文中。如果您不想在 CR 中以明文形式存储密码,您可以从 CR 中排除密码并将其存储在 secret 中。应用 CR 时,Operator 会从 secret 检索每个用户的密码,并将它插入到代理 pod 的 artemis-users.properties 文件中。

流程

  1. 使用 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
  2. 在 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"
                  ...
  3. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/address_custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 完成配置 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 文档中的了解持久性存储

流程

  1. 开始为代理部署配置自定义资源(CR)实例。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在用于创建部署的项目中部署 CR 的用户身份登录 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在用于创建部署的项目中部署 CR 的用户登录到控制台。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 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 如何选择容器镜像”

  2. 要指定代理存储大小,在 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)。
  3. 要在 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 才会声明持久性卷。

  4. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 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。您无法将 配置添加到已在运行的代理部署中。
  • 红帽无法为限制和请求推荐值,因为这些值取决于您的具体消息传递系统用例以及您实施的结果架构。但是,建议您在 为生产环境配置前测试和调整开发环境中的这些值。

先决条件

流程

  1. 开始为代理部署配置自定义资源(CR)实例。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在用于创建部署的项目中部署 CR 的用户身份登录 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在用于创建部署的项目中部署 CR 的用户登录到控制台。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 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 如何选择容器镜像”

  2. 在 CR 的 deploymentPlan 部分中,添加一个 resources 部分。添加 limitsrequests 子项。在每个子部分中,添加一个 cpumemory 属性并指定值。例如:

    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 中运行的每个代理容器都会请求这个数量的主机节点内存。这个值是代理容器运行所需的 最小内存量
  3. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 CR 后,点 Create

4.6. 覆盖代理的默认内存限值

您可以覆盖为代理设置的默认内存限值。默认情况下,代理被分配一个一半内存,内存可用于代理的 Java 虚拟机。以下流程演示了如何为代理部署配置自定义资源(CR)实例以覆盖默认内存限值。

先决条件

流程

  1. 开始配置自定义资源(CR)实例以创建基本代理部署。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 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
  2. 在 CR 的 spec 部分,添加一个 brokerProperties 部分。在 brokerProperties 部分中,添加一个 globalMaxSize 属性并指定内存限制。例如:

    spec:
        ...
        brokerProperties:
        - globalMaxSize=500m
        ...

    globalMaxSize 属性的默认单元是字节。要更改默认单元,请将 m(for MB)或 g(用于 GB)的后缀添加到值。

  3. 将更改应用到 CR。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到代理部署的项目。

        $ oc project <project_name>
      3. 应用 CR。

        $ oc apply -f <path/to/broker_custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 编辑完 CR 后,点 Save
  4. (可选)验证您为 globalMaxSize 属性设置的新值会覆盖分配给代理的默认内存限值。

    1. 连接到 AMQ 管理控制台。更多信息请参阅 第 5 章 连接到基于 Operator 的代理部署的 AMQ Management Console
    2. 从菜单中,选择 JMX
    3. 选择 org.apache.activemq.artemis
    4. 搜索 全局
    5. 在显示的表中,确认 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 脚本访问。

以下流程描述了如何指定自定义初始容器镜像。

先决条件

流程

  1. 开始为代理部署配置自定义资源(CR)实例。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在用于创建部署的项目中部署 CR 的用户身份登录 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在用于创建部署的项目中部署 CR 的用户登录到控制台。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 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 如何选择容器镜像”

  2. 在 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
  3. 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 中的存储库中。
  4. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 CR 后,点 Create

其他资源

4.8. 为客户端连接配置基于 Operator 的代理部署

4.8.1. 配置接收器

要在 OpenShift 部署中启用到代理 Pod 的客户端连接,为部署定义 acceptors。acceptors 定义代理 Pod 如何接受连接。您可以在用于代理部署的主自定义资源(CR)中定义接收器。当您创建接受器时,您可以指定要启用接收器的信息,以及用于这些协议的代理 Pod 上的端口。

以下流程演示了如何在 CR 中为代理部署定义新的接受者。

流程

  1. 在初始安装过程中下载并提取的 Operator 归档中的 deploy/crs 目录中,打开 broker_activemqartemis_cr.yaml 自定义资源(CR)文件。
  2. acceptors 元素中,添加命名的 acceptor。添加 protocolsport 参数。设置值,以指定接受者使用的消息传递协议,以及每个代理 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
  3. 要在同一接收器中使用另一个协议,请修改 protocol 参数。指定以逗号分隔的协议列表。例如:

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
    ...

    配置的接收器现在将端口 5672 公开给 AMQP 和 OpenWire 客户端。

  4. 要指定接受器允许的并发客户端连接数量,请添加 connectionAllowed 参数并设置值。例如:

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        connectionsAllowed: 5
    ...
  5. 默认情况下,接受者仅公开给与代理部署相同的 OpenShift 集群中的客户端。要也会将接受者公开给 OpenShift 之外的客户端,请添加 expose 参数,并将值设为 true

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        connectionsAllowed: 5
        expose: true
        ...
    ...

    当您向 OpenShift 外部的客户端公开接收器时,Operator 会自动为部署中的每个代理 Pod 创建一个专用的服务和路由。

  6. 要启用与 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 来指定。

其他资源

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> - &lt;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 中,只有代理会显示证书。客户端使用此证书验证代理。

先决条件

流程

  1. 为代理密钥存储生成自签名证书。

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
  2. 从代理密钥存储导出证书,以便它与客户端共享。以 Base64 编码的 .pem 格式导出证书。例如:

    $ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
  3. 在客户端上,创建一个导入代理证书的客户端信任存储。

    $ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
  4. 以管理员身份登录 OpenShift Container Platform。例如:

    $ oc login -u system:admin
  5. 切换到包含代理部署的项目。例如:

    $ oc project <my_openshift_project>
  6. 创建用于存储 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。

  7. 将 secret 链接到您在安装 Operator 时创建的服务帐户。例如:

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
  8. 在安全接受器或连接器的 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身份验证

先决条件

流程

  1. 为代理密钥存储生成自签名证书。

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
  2. 从代理密钥存储导出证书,以便它与客户端共享。以 Base64 编码的 .pem 格式导出证书。例如:

    $ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
  3. 在客户端上,创建一个导入代理证书的客户端信任存储。

    $ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
  4. 在客户端上,为客户端密钥存储生成自签名证书。

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
  5. 在客户端上,从客户端密钥存储导出证书,以便它与代理共享。以 Base64 编码的 .pem 格式导出证书。例如:

    $ keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
  6. 创建导入客户端证书的代理信任存储。

    $ keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
  7. 以管理员身份登录 OpenShift Container Platform。例如:

    $ oc login -u system:admin
  8. 切换到包含代理部署的项目。例如:

    $ oc project <my_openshift_project>
  9. 创建用于存储 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 键指定的值实际上是 代理 信任存储文件。

  10. 将 secret 链接到您在安装 Operator 时创建的服务帐户。例如:

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
  11. 在安全接受器或连接器的 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。如需更多信息,请参阅启用消息重新分发

信息可能会以错误的顺序接收,因为当其他消息仍被路由时,消息会在消息重新分发时有一个窗口。

无。

当客户端取消订阅时,它会只删除它最近连接的代理上的队列。这意味着其他队列仍然可以存在并接收消息。

要删除其他可以被取消订阅的客户端的空队列,请配置以下这两个属性:

auto-delete-queues-message-count 属性设置为 0, 以便只能在队列中没有消息时删除队列。设置 auto-delete-queues-delay 属性,以在没有消息后删除没有消息的队列,以毫秒为单位。

如需更多信息,请参阅配置自动创建和删除地址和队列。

Request/Reply 队列

当 JMS Producer 创建临时的回复队列时,队列会在代理上创建。如果从工作队列使用的客户端并回复临时队列连接到不同的代理,则可能会出现以下问题。

问题缓解方案

由于客户端连接的代理中不存在答复队列,客户端可能会生成错误。

确保 auto-create-queues 属性设为 true。如需更多信息,请参阅配置自动创建和删除地址和队列。

发送到工作队列的消息可能无法分发。

通过将 message-load-balancing 属性设置为 ON-DEMAND,确保消息按需负载平衡。另外,请确保启用了消息 redistribution。如需更多信息,请参阅启用消息重新分发

其他资源

  • 有关使用方法(如 Routes 和 NodePort)从 OpenShift 集群外部与集群中运行的服务进行通信的更多信息,请参阅:

4.9. 为 AMQP 消息配置大型消息处理

客户端可能会发送超过代理内部缓冲大小的大型 AMQP 信息,从而导致意外错误。要防止这种情况,您可以将代理配置为在消息大于指定最小值时存储信息。以这种方式处理大型消息意味着代理不会在内存中保存消息。相反,代理将信息存储在用于存储大型消息文件的专用目录中。

对于 OpenShift Container Platform 上的代理部署,大型消息目录为 /opt/ &lt;custom_resource_name&gt; /data/large-messages on the Persistent Volume(PV)用于消息存储。当代理将消息存储为大消息时,队列会保留对大型消息目录中的文件的引用。

重要

对于 AMQ Broker 7.10 中的基于 Operator 的代理部署,大型消息处理仅适用于 AMQP 协议。

4.9.1. 为大型消息处理配置 AMQP 接受器

以下流程演示了如何配置接受器来处理大于指定大小作为较大消息的 AMQP 消息。

先决条件

流程

  1. 打开您之前定义 AMQP acceptor 的自定义资源(CR)实例。

    1. 使用 OpenShift 命令行界面:

      $ oc edit -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 在左侧导航菜单中点 AdministrationCustom Resource Definitions
      2. 单击 ActiveMQArtemis CRD。
      3. Instances 选项卡。
      4. 查找与项目命名空间对应的 CR 实例。

    之前配置的 AMQP 接受程序可能类似如下:

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp
        port: 5672
        connectionsAllowed: 5
        expose: true
        sslEnabled: true
    ...
  2. 指定代理作为较大消息的 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/ &lt;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)实例,以运行健康检查。

先决条件

流程

  1. 创建 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 Create ActiveMQArtemis

        在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

  2. 要配置存活度探测,在 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
  3. 要配置就绪度探测,在 CR 的 deploymentPlan 部分中添加一个 readinessProbe 部分。例如:

    spec:
      deploymentPlan:
        readinessProbe:
          initialDelaySeconds: 5
          periodSeconds: 5

    如果您没有配置就绪度探测,内置 脚本会 检查所有接收器是否可以接受连接。

  4. 如果要配置更全面的健康检查,请将 artemis 检查 命令行工具添加到存活度或就绪度探测配置中。

    1. 如果要配置健康检查以在 livenessProbereadinessProbe 部分中创建一个与代理的完整客户端连接,请添加 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 配置的环境变量。

    2. 如果要配置生成和使用消息的健康检查,在 livenessProbereadinessProbe 部分中验证代理文件系统的健康状况,请添加 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
      注意

      您指定的队列名称必须在代理上配置,且 anycastroutingType。例如:

      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
  5. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 完成配置 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 仍然在运行。

AH ocp pod 排空

当代理 Pod 关闭时,AMQ Broker Operator 会自动启动一个 scaledown 控制器,它将执行消息迁移到仍在代理集群中运行的另一个代理 Pod。此消息迁移过程也称为 Pod draining。下面的部分描述了消息迁移。

4.11.2. 消息迁移

消息迁移是由于部署的意图缩减,如何在集群部署中代理关闭时确保消息传递数据的完整性。也称为 Pod 排空,此过程指的是从已关闭的代理 Pod 中删除和重新分发消息。

注意
  • 执行消息迁移的 scaledown 控制器只能在单个 OpenShift 项目中操作。控制器无法在单独的项目中的代理之间迁移信息。
  • 要使用消息迁移,您的部署中必须至少有两个代理。默认集群带有两个或多个代理的代理。

对于基于 Operator 的代理部署,您可以在用于部署的主代理自定义资源中将 messageMigration 设置为 true 来启用消息迁移。

消息迁移过程遵循以下步骤:

  1. 当部署中的代理 Pod 因部署的意图而关闭时,Operator 会自动启动缩减控制器以准备消息迁移。scaledown 控制器在与代理集群相同的 OpenShift 项目名称中运行。
  2. scaledown 控制器注册自己,并侦听项目中与持久性卷声明(PVC)相关的 Kubernetes 事件。
  3. 要检查已经孤立的持久性卷(PV),扩展控制器会在卷声明上查看 或dinal。控制器将卷声明上的 ordinal 与项目中仍然在 StatefulSet 中运行的代理 Pod(即代理集群)进行比较。

    如果卷声明上的 ordinal 大于仍在代理集群中任何代理 Pod 的 ordinal,则 scaledown 控制器会确定代理 Pod 已关闭,且消息传递数据必须迁移到另一个代理 Pod。

  4. scaledown 控制器启动一个 drainer Pod。drainer Pod 运行代理并执行消息迁移。然后,drainer Pod 标识可迁移到孤立消息的替代代理 Pod。

    注意

    部署中必须至少有一个代理 Pod 仍在部署中运行,才能进行消息迁移。

下图演示了 scaledown 控制器(也称为 drain controller)如何将消息迁移到正在运行的代理 Pod。

AH ocp pod draining 3

当信息成功迁移到可操作的代理 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 控制器的行为。

先决条件

流程

  1. 在您最初下载并提取的 Operator 存储库的 deploy/crs 目录中,打开主代理 CR broker_activemqartemis_cr.yaml
  2. 在主代理 CR 中,将 messageMigrationpersistenceEnabled 设置为 true

    这些设置意味着,当您稍后缩减集群代理部署的大小时,Operator 会自动启动扩展控制器,并将信息迁移到仍然运行的代理 Pod。

  3. 在现有代理部署中,验证哪些 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。

  4. 登录到每个 Pod,并将一些消息发送到每个代理。

    1. 作为 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
    2. 作为 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 个消息添加到每个队列。

  5. 将集群从两个代理缩减为一个。

    1. 打开主代理 CR, broker_activemqartemis_cr.yaml
    2. 在 CR 中,将 deploymentPlan.size 设置为 1
    3. 在命令行中应用更改:

      $ oc apply -f deploy/crs/broker_activemqartemis_cr.yaml

      您会看到 Pod ex-aao-s-1 开始关闭。scaledown 控制器会启动同一名称的新 drainer Pod。这个 drainer Pod 也会在将信息从代理 Pod ex-ao-s-1 中迁移到集群(ex-aao-ss-0)中的其他代理 Pod 中后关闭。

  6. 当 drainer Pod 关闭时,检查 broker Pod ex-aao-ss-0TEST 队列的消息数。您会看到队列中的消息数量为 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。

先决条件

流程

  1. 根据主代理 CRD 创建自定义资源(CR)实例。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 Create ActiveMQArtemis

        在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

  2. 在 CR 的 deploymentPlan 部分中,添加一个 nodeSelector 部分,并添加您要与为 pod 选择节点匹配的节点标签。例如:

    spec:
        deploymentPlan:
          nodeSelector:
            app: broker1

    在本例中,代理 pod 调度到具有 app: broker1 标签的节点上。

  3. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 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 放置

流程

  1. 根据主代理 CRD 创建自定义资源(CR)实例。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 Create ActiveMQArtemis

        在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

  2. 在 CR 的 deploymentPlan 部分中,添加一个 tolerations 部分。在 tolerations 部分中,为您要匹配的节点污点添加容限。例如:

    spec:
         deploymentPlan:
            tolerations:
            - key: "app"
              value: "amq-broker"
              effect: "NoSchedule"

    在本例中,容限与节点污点的 app=amq-broker:NoSchedule 匹配,因此 pod 可以调度到配置了此污点的节点。

注意

要确保代理 pod 正确调度,请不要在 CR 的 tolerations 部分指定 tolerationsSeconds 属性。

  1. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 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

流程

  1. 根据主代理 CRD 创建自定义资源(CR)实例。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 Create ActiveMQArtemis

        在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

  2. 在 CR 的 deploymentPlan 部分中,添加以下部分: 关联性nodeAffinityrequiredDuringSchedulingIgnoredDuringExecutionnodeSelectorTerms。在 nodeSelectorTerms 部分中,添加 - matchExpressions 参数,并指定要匹配的节点标签的键值字符串。例如:

    spec:
        deploymentPlan:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                - matchExpressions:
                  - key: zone
                    operator: In
                    values:
                    - emea

    在本例中,关联性规则允许将 pod 调度到具有键为 zone 且值为 emea 的标签的任何节点上。

  3. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 CR 后,点 Create

其他资源

如需有关 OpenShift Container Platform 中的关联性规则的更多信息,请参阅 OpenShift Container Platform 文档中的使用节点关联性规则控制节点上的 pod 放置

4.12.3.2. 使用反关联性规则相对于其他 pod 放置 pod

通过反关联性规则,您可以根据已在该节点上运行的 pod 标签限制代理 pod 可以调度哪些节点。

使用反关联性规则的用例是确保不会将集群中的多个代理 pod 调度到同一节点上,从而创建一个故障点。如果您不控制集群中的 pod 放置,则可以将集群中的 2 或以上代理 pod 调度到同一节点上。

以下示例演示了如何配置反关联性规则,以防止将集群中的 2 代理 pod 调度到同一节点上。

先决条件

流程

  1. 基于主代理 CRD,为集群中的第一个代理创建一个 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
      2. 根据主代理 CRD 启动一个新的 CR 实例。在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 单击 Create ActiveMQArtemis

        在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

  2. 在 CR 的 deploymentPlan 部分中,添加一个 labels 部分。为第一个代理 pod 创建识别标签,以便您可以在第二个代理 pod 上创建反关联性规则,以防止将两个 pod 调度到同一个节点上。例如:

    spec:
        deploymentPlan:
          labels:
            name: broker1
  3. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 CR 后,点 Create
  4. 基于主代理 CRD,为集群中的第二个代理创建 CR 实例。

    1. 在 CR 的 deploymentPlan 部分中,添加以下部分: affinitypodAntiAffinityrequiredDuringSchedulingIgnoredDuringExecutionlabelSelector。在 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 的标签相同的节点上,这是分配给集群中第一个代理的标签。

  5. 部署 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到您要在其中创建代理部署的项目。

        $ oc project <project_name>
      3. 创建 CR 实例。

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 配置完 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 的控制台。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 NetworkingRoutes

    Routes 页面中,识别给定代理 Pod 的 wconsj Route。例如,my-broker-deployment-wconsj-0-svc-rte

  2. Location 下,单击与路由对应的链接。

    在 Web 浏览器中打开一个新标签页。

  3. Management Console 链接。

    此时会打开 AMQ Management Console 登录页面。

  4. 要登录到控制台,请在用于创建代理部署的自定义资源(CR)实例中输入 adminUseradminPassword 属性指定的值。

    如果没有为 CR 中的 adminUseradminPassword 指定值,请按照 第 5.2 节 “访问 AMQ 管理控制台登录凭证” 中的说明来检索登录到控制台所需的凭证。

    注意

    只有在 CR 的 requireLogin 属性设置为 true 时,才需要 adminUseradminPassword 的值才能登录到控制台。此属性指定是否需要登录凭证才能登录到 代理和 控制台。如果将 requireLogin 设置为 false,则可以在提示输入用户名和密码时通过输入任何文本来登录到控制台,而无需提供有效的用户名密码。

5.2. 访问 AMQ 管理控制台登录凭证

如果您没有在用于代理部署的自定义资源(CR)实例中为 adminUseradminPassword 指定值,Operator 会自动生成这些凭证并将其存储在 secret 中。默认 secret 名称采用 < custom-resource-name>-credentials-secret 形式,如 my-broker-deployment-credentials-secret

注意

只有在 CR 的 requireLogin 参数设置为 true 时,才需要 adminUseradminPassword 的值才能登录到管理控制台。

如果将 requireLogin 设置为 false,则可以在提示输入用户名和密码时通过输入任何文本来登录到控制台,而无需提供有效的用户名密码。

此流程演示了如何访问登录凭证。

流程

  1. 查看 OpenShift 项目中的 secret 的完整列表。

    1. 在 OpenShift Container Platform web 控制台中点击 WorkloadSecrets
    2. 在命令行中:

      $ oc get secrets
  2. 打开适当的 secret,以显示 Base64 编码的控制台登录凭证。

    1. 在 OpenShift Container Platform web 控制台中,点击在其名称中包含代理自定义资源实例的 secret。点 YAML 标签。
    2. 在命令行中:

      $ oc edit secret <my-broker-deployment-credentials-secret>
  3. 要解码 secret 中的一个值,请使用类似如下的命令:

    $ echo 'dXNlcl9uYW1l' | base64 --decode
    console_admin

其他资源

第 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 控制台中的项目的 OperatorsInstalled Operators 下),您还应使用 OperatorHub 来升级 Operator。有关这些升级方法的更多信息,请参阅:

  • 如果 redeliveryDelayMultiplierredeliveryCollisionAvoidanceFactor 属性在 7.8.x 或 7.9.x 部署中的主代理 CR 中配置,新的 Operator 在升级到 7.10.x 后无法协调任何 CR。协调失败,因为两个属性的数据类型从 float 改为 7.10.x 中的字符串。

    您可以通过删除 spec.deploymentPlan.addressSettings.addressSetting 元素的 redeliveryDelayMultiplierredeliveryCollisionAvoidanceFactor 属性来解决这个问题。然后,在 brokerProperties 元素中配置属性。例如:

    spec:
        ...
        brokerProperties:
        - "addressSettings.#.redeliveryMultiplier=2.1"
        - "addressSettings.#.redeliveryCollisionAvoidanceFactor=1.2"
    注意

    brokerProperties 元素中,使用 redeliveryMultiplier 属性名称而不是您删除的 redeliveryDelayMultiplier 属性名称。

  • 如果要部署 Operator 来监视多个命名空间,例如监视所有命名空间,您必须:

    1. 请确定您已备份了与集群中代理部署相关的所有 CR。
    2. 卸载现有的 Operator。
    3. 部署 7.10 Operator,以观察您需要的命名空间。
    4. 检查所有部署并在必要时重新创建。

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 控制台中您的项目的 OperatorsInstalled Operators 下),您应该使用 OperatorHub 来升级 Operator。要了解如何使用 OperatorHub 升级 Operator,请参阅 第 6.3 节 “使用 OperatorHub 升级 Operator”

6.2.2. 使用 CLI 升级 Operator

您可以使用 OpenShift 命令行界面(CLI)将 Operator 升级到 AMQ Broker 7.10 的最新版本。

流程

  1. 在 Web 浏览器中,导航到 AMQ Broker 7.10.7 补丁的 Software Downloads 页面。
  2. 确保 Version 下拉列表的值设为 7.10.7,并且选择了 Releases 选项卡。
  3. AMQ Broker 7.10.7 Operator Installation and Example Files 旁边,点 Download

    下载 amq-broker-operator-7.10.7-ocp-install-examples.zip 压缩存档会自动开始。

  4. 下载完成后,将存档移至您选择的安装目录。以下示例将存档 移到名为 ~/broker/operator 的目录。

    $ mkdir ~/broker/operator
    $ mv amq-broker-operator-7.10.7-ocp-install-examples.zip ~/broker/operator
  5. 在您选择的安装目录中,提取存档的内容。例如:

    $ cd ~/broker/operator
    $ unzip amq-broker-operator-operator-7.10.7-ocp-install-examples.zip
  6. 以包含现有 Operator 部署的项目的管理员身份登录 OpenShift Container Platform。

    $ oc login -u <user>
  7. 切换到要升级 Operator 版本的 OpenShift 项目。

    $ oc project <project-name>
  8. 在您下载并提取的最新 Operator 归档的 deploy 目录中,打开 operator.yaml 文件。

    注意

    operator.yaml 文件中,Operator 使用一个由 Secure Hash Algorithm (SHA) 值代表的镜像。注释行以数字符号 (#) 符号开头,注明 SHA 值对应于特定的容器镜像标签。

  9. 以前的 Operator 部署打开 operator.yaml 文件。检查您在之前配置中指定的任何非默认值是否在 新的 operator.yaml 配置文件中复制。
  10. 在新的 operator.yaml 文件中,Operator 默认命名为 controller-manager。将 controller-manager 的所有实例替换为 amq-broker-operator,这是之前版本中 Operator 的名称,并保存文件。例如:

    spec:
    ...
      selector
        matchLabels
          name: amq-broker-operator
    ...
  11. 更新 Operator 中包含的 CRD。在部署 Operator 前,您必须更新 CRD。

    1. 更新主代理 CRD。

      $ oc apply -f deploy/crds/broker_activemqartemis_crd.yaml
    2. 更新地址 CRD。

      $ oc apply -f deploy/crds/broker_activemqartemisaddress_crd.yaml
    3. 更新 scaledown 控制器 CRD。

      $ oc apply -f deploy/crds/broker_activemqartemisscaledown_crd.yaml
    4. 更新安全 CRD。

      $ oc apply -f deploy/crds/broker_activemqartemissecurity_crd.yaml
  12. 如果您只从 AMQ Broker Operator 7.10.0 升级,请删除 Operator 和 StatefulSet。

    默认情况下,新 Operator 删除 StatefulSet 以删除自定义和 Operator metering 标签,这些标签被 7.10.0 中的 Operator 错误地添加到 StatefulSet 选择器。当 Operator 删除 StatefulSet 时,它还会删除现有的代理 Pod,这会导致临时代理中断。如果要避免中断,请完成以下步骤以删除 Operator 和 StatefulSet 而不删除代理 Pod。

    1. 删除 Operator。

      $ oc delete -f deploy/operator.yaml
    2. 使用 --cascade=orphan 选项删除 StatefulSet,以孤立代理 Pod。孤立的代理 Pod 在删除 StatefulSet 后继续运行。

      $ oc delete statefulset <statefulset-name> --cascade=orphan
  13. 如果您要从 AMQ Broker Operator 7.10.0 或 7.10.1 升级,请检查您的主代理 CR 是否有名为 applicationActiveMQArtemis 的标签,在 deploymentPlan.labels 属性中配置。

    这些标签为 Operator 保留,以分配标签到 Pod,且不允许在 7.10.1 后作为自定义标签。如果在主代理 CR 中配置了这些自定义标签,则 Pod 上的 Operator 分配标签会被自定义标签覆盖。如果在主代理 CR 中配置了任何自定义标签,请完成以下步骤以在 Pod 上恢复正确的标签并从 CR 中删除标签。

    1. 如果您要从 7.10.0 升级,请删除上一步中的 Operator。如果要从 7.10.1 升级,请删除 Operator。

      $ oc delete -f deploy/operator.yaml
    2. 运行以下命令以恢复正确的 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
    3. 从 CR 中的 deploymentPlan.labels 属性中删除 applicationActiveMQArtemis 标签。

      1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

        oc login -u <user> -p <password> --server=<host:port>
      2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
      3. 在 CR 的 deploymentPlan.labels 属性中,删除名为 applicationActiveMQArtemis 的任何自定义标签。
      4. 保存 CR 文件。
      5. 部署 CR 实例。

        1. 切换到代理部署的项目。

          $ oc project <project_name>
        2. 应用 CR。

          $ oc apply -f <path/to/broker_custom_resource_instance>.yaml
    4. 如果删除了以前的 Operator,请部署新的 Operator。

       $ oc create -f deploy/operator.yaml
  14. 应用更新的 Operator 配置。

    $ oc apply -f deploy/operator.yaml
  15. 新的 Operator 可以识别和管理之前的代理部署。如果在部署的 CR 中启用了自动更新,Operator 的协调过程会处理每个代理 pod 的协调过程。如果没有启用自动更新,您可以通过在 CR 中设置以下属性来启用它们:

    spec:
        ...
        upgrades:
            enabled: true
            minor: true

    有关启用自动更新的详情请参考 第 6.4 节 “通过指定 AMQ Broker 版本升级代理容器镜像”

    注意

    如果协调过程没有启动,您可以通过扩展部署来开始该过程。更多信息请参阅 第 3.4.1 节 “部署基本代理实例”

  16. 根据需要在 CR 中为升级代理可用的新功能添加属性。

6.3. 使用 OperatorHub 升级 Operator

本节论述了如何使用 OperatorHub 为 AMQ Broker 升级 Operator。

6.3.1. 先决条件

  • 只有在您最初使用 OperatorHub 安装 Operator 时,才应使用 OperatorHub 来升级 Operator(也就是说,OpenShift Container Platform Web 控制台的 OperatorsInstalled Operators 下)。相反,如果您最初使用 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 或更高版本。

流程

  1. 以集群管理员身份登录 OpenShift Container Platform Web 控制台。
  2. 从项目中卸载现有的 AMQ Broker Operator。
  3. 在左侧导航菜单中,点 OperatorsInstalled Operators
  4. 在页面顶部的 Project 下拉菜单中选择您要卸载 Operator 的项目。
  5. 找到您要卸载的 Red Hat Integration - AMQ Broker 实例。
  6. 对于 Operator 实例,点击右侧的 More Options 图标(三个垂直点)。点击 Uninstall Operator
  7. 在确认对话框中点 Uninstall
  8. 使用 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 升级。

流程

  1. 以集群管理员身份登录 OpenShift Container Platform Web 控制台。
  2. 从项目中卸载现有的 AMQ Broker Operator。

    1. 在左侧导航菜单中,点 OperatorsInstalled Operators
    2. 在页面顶部的 Project 下拉菜单中选择您要卸载 Operator 的项目。
    3. 找到您要卸载的 Red Hat Integration - AMQ Broker 实例。
    4. 对于 Operator 实例,点击右侧的 More Options 图标(三个垂直点)。点击 Uninstall Operator
    5. 在确认对话框中点 Uninstall
  3. 当您升级 7.10.0 Operator 时,新 Operator 会删除 StatefulSet 来删除自定义和 Operator metering 标签,这些标签会错误地添加到 7.10.0 中 Operator 的 StatefulSet 选择器。当 Operator 删除 StatefulSet 时,它也会删除现有的代理 pod,这会导致临时代理中断。如果要避免中断,请完成以下步骤以删除 StatefulSet 并孤立代理 pod,以便它们继续运行。

    1. 以包含现有 Operator 部署的项目的管理员用户身份登录 OpenShift Container Platform CLI:

      $ oc login -u <user>
    2. 切换到要升级 Operator 版本的 OpenShift 项目。

      $ oc project <project-name>
    3. 使用 --cascade=orphan 选项删除 StatefulSet,以孤立代理 Pod。孤立的代理 Pod 在删除 StatefulSet 后继续运行。

      $ oc delete statefulset <statefulset-name> --cascade=orphan
  4. 检查您的主代理 CR 是否在 deploymentPlan.labels 属性中配置了名为 applicationActiveMQArtemis 的标签。

    在 7.10.0 中,可以在 CR 中配置这些自定义标签。这些标签是为 Operator 保留用于为 Pod 分配标签,且无法在 7.10.0 后作为自定义标签添加。如果在 7.10.0 中的主代理 CR 中配置了这些自定义标签,则自定义标签会覆盖 Pod 上的 Operator 分配标签。如果 CR 具有其中任一个标签,请完成以下步骤以在 Pod 上恢复正确的标签并从 CR 中删除标签。

    1. 在 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
    2. 从 CR 中的 deploymentPlan.labels 属性中删除 applicationActiveMQArtemis 标签。

      1. 使用 OpenShift 命令行界面:

        1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

          oc login -u <user> -p <password> --server=<host:port>
        2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
        3. 在 CR 的 deploymentPlan.labels 元素中,删除名为 applicationActiveMQArtemis 的任何自定义标签。
        4. 保存 CR 文件。
        5. 部署 CR 实例。

          1. 切换到代理部署的项目。

            $ oc project <project_name>
          2. 应用 CR。

            $ oc apply -f <path/to/broker_custom_resource_instance>.yaml
      2. 使用 OpenShift Container Platform Web 控制台:

        1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
        2. 在左侧窗格中,单击 AdministrationCustom Resource Definitions
        3. 单击 ActiveMQArtemis CRD。
        4. 实例 选项卡。
        5. 点代理部署的实例。
        6. YAML 标签。

          在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

        7. 在 CR 的 deploymentPlan.labels 元素中,删除名为 applicationActiveMQArtemis 的任何自定义标签。
        8. Save
  5. 使用 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 节 “部署基本代理实例”

  6. 根据需要在 CR 中为升级代理可用的新功能添加属性。

6.3.5. 将 Operator 从 7.10.1 升级到 7.10.x

使用这个流程从 AMQ Broker Operator 7.10.1 升级。

流程

  1. 以集群管理员身份登录 OpenShift Container Platform Web 控制台。
  2. 检查您的主代理 CR 是否在 deploymentPlan.labels 属性中配置了名为 applicationActiveMQArtemis 的标签。

    这些标签为 Operator 保留,以分配标签到 Pod,在 7.10.1 后无法使用。如果在主代理 CR 中配置了这些自定义标签,则 Pod 上的 Operator 分配标签会被自定义标签覆盖。

  3. 如果在主代理 CR 中没有配置这些自定义标签,请使用 OperatorHub 为 AMQ Broker 7.10 安装 Operator 的最新版本。更多信息请参阅 第 3.3.2 节 “从 OperatorHub 部署 Operator”
  4. 如果在主代理 CR 中配置了任何自定义标签,请完成以下步骤来卸载现有的 Operator,在安装新 Operator 前恢复正确的 Pod 标签并从 CR 中删除标签。

    注意

    通过卸载 Operator,您可以在没有 Operator 删除 StatefulSet 的情况下删除自定义标签,这也会删除现有代理 pod 并导致临时代理中断。

    1. 从项目中卸载现有的 AMQ Broker Operator。

      1. 在左侧导航菜单中,点 OperatorsInstalled Operators
      2. 在页面顶部的 Project 下拉菜单中选择您要卸载 Operator 的项目。
      3. 找到您要卸载的 Red Hat Integration - AMQ Broker 实例。
      4. 对于 Operator 实例,点击右侧的 More Options 图标(三个垂直点)。点击 Uninstall Operator
      5. 在确认对话框中点 Uninstall
    2. 在 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
    3. 从 CR 中的 deploymentPlan.labels 属性中删除 applicationActiveMQArtemis 标签。

      1. 使用 OpenShift 命令行界面:

        1. 以有权在项目中部署代理部署的 CR 的用户登录到 OpenShift。

          oc login -u <user> -p <password> --server=<host:port>
        2. 打开名为 broker_activemqartemis_cr.yaml 的示例 CR 文件,该文件包含在您下载和提取的 Operator 安装存档的 deploy/crs 目录中。
        3. 在 CR 的 deploymentPlan.labels 属性中,删除名为 applicationActiveMQArtemis 的任何自定义标签。
        4. 保存 CR 文件。
        5. 部署 CR 实例。

          1. 切换到代理部署的项目。

            $ oc project <project_name>
          2. 应用 CR。

            $ oc apply -f <path/to/broker_custom_resource_instance>.yaml
      2. 使用 OpenShift Container Platform Web 控制台:

        1. 以有权在项目中部署 CR 的用户登录到控制台,以进行代理部署。
        2. 在左侧窗格中,单击 AdministrationCustom Resource Definitions
        3. 单击 ActiveMQArtemis CRD。
        4. 实例 选项卡。
        5. 点代理部署的实例。
        6. YAML 标签。

          在控制台中,会打开 YAML 编辑器,供您配置 CR 实例。

        7. 在 CR 的 deploymentPlan.labels 属性中,删除名为 applicationActiveMQArtemis 的任何自定义标签。
        8. Save
  5. 使用 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 节 “部署基本代理实例”

  6. 根据需要在 CR 中为升级代理可用的新功能添加属性。

6.4. 通过指定 AMQ Broker 版本升级代理容器镜像

以下流程演示了如何通过指定 AMQ Broker 版本为基于 Operator 的代理部署升级代理容器镜像。例如,如果您将 Operator 升级到 AMQ Broker 7.10.0,但 CR 中的 spec.upgrades.enabled 属性已设为 truespec.version 属性指定 7.9.0要升级 代理容器镜像,需要手动指定新的 AMQ Broker 版本(如 7.10.0)。当您指定 AMQ Broker 的新版本时,Operator 会自动选择与此版本对应的代理容器镜像。

先决条件

  • 第 2.4 节 “Operator 如何选择容器镜像” 所述,如果您部署一个 CR 且没有明确指定代理容器镜像,Operator 会自动选择要使用的适当容器镜像。要使用本节中描述的升级过程,您必须使用此默认行为。如果您在 CR 中直接指定代理容器镜像来覆盖默认行为,Operator 无法自动 升级代理容器镜像以对应 AMQ Broker 版本,如下所述。

流程

  1. 编辑代理部署的主要代理 CR 实例。

    1. 使用 OpenShift 命令行界面:

      1. 以具有权限权限的用户身份登录 OpenShift,以便在项目中为代理部署编辑和部署 CR。

        $ oc login -u <user> -p <password> --server=<host:port>
      2. 在文本编辑器中,打开用于代理部署的 CR 文件。例如,这可能是之前下载并提取的 Operator 安装的 deploy/crs 目录中的 broker_activemqartemis_cr.yaml 文件。
    2. 使用 OpenShift Container Platform Web 控制台:

      1. 以具有权限的用户身份登录控制台,在项目中为代理部署编辑和部署 CR。
      2. 在左侧窗格中,单击 AdministrationCustom Resource Definitions
      3. 单击 ActiveMQArtemis CRD。
      4. 实例 选项卡。
      5. 查找与项目命名空间对应的 CR 实例。
      6. 对于 CR 实例,单击右侧的 More Options 图标(三个垂直点)。选择 Edit ActiveMQArtemis

        在控制台中,会打开 YAML 编辑器,供您编辑 CR 实例。

  2. 指定将代理容器镜像升级到的 AMQ Broker 版本,为 CR 的 spec.version 属性设置一个值。例如:

    spec:
        version: 7.10.0
        ...
  3. 在 CR 的 spec 部分,找到 upgrade 部分。如果 CR 中还没有包括此部分,请添加它。

    spec:
        version: 7.10.0
        ...
        upgrades:
  4. 确定 upgrade 部分包含 enabledminor 属性。

    spec:
        version: 7.10.0
        ...
        upgrades:
            enabled:
            minor:
  5. 要根据 AMQ Broker 的指定版本启用代理容器镜像升级,请将 enabled 属性的值设置为 true

    spec:
        version: 7.10.0
        ...
        upgrades:
            enabled: true
            minor:
  6. 要定义代理的升级行为,请为 minor 属性设置值。

    1. 要允许在 次要 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.07.10.0 次版本之间有可用的升级。根据前面的设置,允许在次版本之间进行升级,Operator 会升级代理容器镜像。

      相反,假设当前代理容器镜像与 7.10.0 对应,并且您为 spec.version 指定 一个新的 7.10.1 值。如果存在与 7.10.1 对应的镜像,Operator 会决定 7.10.07.10.1 微版本之间有可用的升级。根据前面的设置,仅允许在次版本之间进行升级,Operator 不会 升级代理容器镜像。

    2. 要允许在 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.07.10.0 次版本之间有可用的升级。根据前面的设置,它不允许在次版本间进行升级(即在微版本间进行升级),Operator 不会 升级代理容器镜像。

      相反,假设当前代理容器镜像与 7.10.0 对应,并且您为 spec.version 指定 一个新的 7.10.1 值。如果存在与 7.10.1 对应的镜像,Operator 会决定 7.10.07.10.1 微版本之间有可用的升级。根据前面的设置,允许在微版本间进行升级,Operator 会升级代理容器镜像。

  7. 将更改应用到 CR。

    1. 使用 OpenShift 命令行界面:

      1. 保存 CR 文件。
      2. 切换到代理部署的项目。

        $ oc project <project_name>
      3. 应用 CR。

        $ oc apply -f <path/to/broker_custom_resource_instance>.yaml
    2. 使用 OpenShift Web 控制台:

      1. 编辑完 CR 后,点击 Save

    应用 CR 更改时,Operator 首先会验证是否升级到为 spec.version 指定的 AMQ Broker 版本。如果您指定了将要升级到的 AMQ Broker 无效的版本的 AMQ Broker(例如,还没有可用的版本),Operator 会记录警告信息,且不采取进一步操作。

    但是,如果到指定版本的升级可用,并且为 upgrade.enabledupgrade.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 会关闭并重启。

其他资源

第 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 节 “部署基本代理实例”

流程

  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
            ...
  2. deploymentPlan 部分中,添加 jolokiaAgentEnabledmanagementRBACEnabled 属性,并指定值,如下所示。

    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 管理控制台,因为这可能会公开代理上的所有管理操作到未授权使用。

  3. 保存 CR 实例。
  4. 切换到之前创建的代理部署的项目。

    $ oc project <project_name>
  5. 在命令行中应用更改。

    $ oc apply -f <path/to/custom_resource_instance>.yaml
  6. 在 Fuse Console 中,要查看 Fuse 应用程序,请单击 Online 选项卡。要查看正在运行的代理,请在左侧导航菜单中,单击 NEXT

其他资源

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 插件”

流程

  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
      ...
  2. 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 插件。
  3. 保存 CR 实例。
  4. 切换到之前创建的代理部署的项目。

    $ oc project <project_name>
  5. 在命令行中应用更改。

    $ oc apply -f <path/to/custom_resource_instance>.yaml

    metrics 插件开始以 Prometheus 格式收集代理运行时指标。

其他资源

7.2.3. 使用环境变量为正在运行的代理部署启用 Prometheus 插件

以下流程演示了如何使用环境变量为 AMQ Broker 启用 Prometheus 插件。对于替代流程,请参阅 第 7.2.2 节 “使用 CR 启用 Prometheus 插件”

先决条件

  • 您可以为使用 AMQ Broker Operator 创建的代理 Pod 启用 Prometheus 插件。但是,您部署的代理必须使用 AMQ Broker 7.7 或更高版本的代理容器镜像。

流程

  1. 使用包含代理部署的项目的管理员权限登录到 OpenShift Container Platform Web 控制台。
  2. 在 Web 控制台中,点 HomeProjects。选择包含代理部署的项目。
  3. 要查看项目中的 StatefulSets 或 DeploymentConfig,请点击 WorkloadsStatefulSetsWorkloadsDeploymentConfig
  4. 点击与代理部署对应的 StatefulSet 或 DeploymentConfig。
  5. 要访问代理部署的环境变量,请单击 Environment 选项卡。
  6. 添加新的环境变量 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 指标。

先决条件

流程

  1. 对于您要访问的指标的代理 Pod,您需要识别之前创建的路由,以将 Pod 连接到 AMQ Broker 管理控制台。访问指标所需的 URL 的 Route 名称表单部分。

    1. 点击 NetworkingRoutes
    2. 对于您选择的代理 Pod,标识为将 Pod 连接到 AMQ Broker 管理控制台而创建的路由。在 Hostname 下,请注意显示的完整 URL。例如:

      http://rte-console-access-pod1.openshiftdomain
  2. 要访问 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 的代理。

先决条件

流程

  1. 获取正在运行的 pod 列表:

    $ oc get pods
    
    NAME                 READY     STATUS    RESTARTS   AGE
    ex-aao-ss-1   1/1       Running   0          14d
  2. 运行 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
    ...
  3. 运行查询来监控 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)中需要标记为星号(*)的配置项。如果您没有为非必需项显式指定值,则配置将使用默认值。

条目子条目描述和使用

adminUser*

 

连接到代理和管理控制台所需的管理员用户名。

如果没有指定值,则值会自动生成并存储在 secret 中。默认 secret 名称的格式为 < custom_resource_name>-credentials-secret。例如: my-broker-deployment-credentials-secret

键入: string

示例 :my-user

默认值 :自动生成的随机值

adminPassword*

 

连接到代理和管理控制台所需的管理员密码。

如果没有指定值,则值会自动生成并存储在 secret 中。默认 secret 名称的格式为 < custom_resource_name>-credentials-secret。例如: my-broker-deployment-credentials-secret

键入: string

示例 :my-password

默认值 :自动生成的随机值

deploymentPlan*

 

代理部署配置

 

image*

部署中每个代理的代理容器镜像的完整路径。

您不需要在 CR 中为 镜像 指定一个值。占位符 默认值表示 Operator 尚未决定要使用的适当镜像。

要了解 Operator 如何选择要使用的代理容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”

键入: string

示例 :registry.redhat.io/amq7/amq-broker-rhel8@sha256:982ba18be1ac285722bc0ca8e85d2a42b8b844ab840b01425e79e3eeee6ee5b9

默认值 :占位符

 

size*

要在部署中创建的代理 Pod 数量。

如果您指定一个 2 或更高值,则代理部署会默认集群。默认情况下,集群用户名和密码会自动生成并存储在与 adminUseradminPassword 相同的机密中。

键入: int

示例 :1

默认值 :2

 

requireLogin

指定是否需要登录凭证才能连接到代理。

类型 :布尔值

示例 :false

默认值: true

 

persistenceEnabled

指定部署中的每个代理 Pod 使用 journal 存储。如果设置为 true,则每个代理 Pod 需要一个可用的持久性卷(PV),供 Operator 使用持久性卷声明(PVC)来声明。

类型 :布尔值

示例 :false

默认值: true

 

initImage

用于配置代理的 init 容器镜像。

您不需要在 CR 中为 initImage 显式指定值,除非您要提供自定义镜像。

要了解 Operator 如何选择要使用的内置初始容器镜像,请参阅 第 2.4 节 “Operator 如何选择容器镜像”

要了解如何 指定自定义 Init 容器镜像,请参阅 第 4.7 节 “指定自定义 Init 容器镜像”

键入: string

示例 :registry.redhat.io/amq7/amq-broker-init-rhel8@sha256:f37f98c809c6f29a83e3d5a3ac4494e28efe9b25d33c54f533c6a08662244622

默认值 : 未指定

 

journalType

指定是否使用异步 I/O(AIO)或非阻塞 I/O(NIO)。

键入: string

示例 :aio

默认值为: nio

 

messageMigration

当代理 Pod 因为代理部署的意图而关闭时,指定是否将消息迁移到仍在代理集群中运行的另一个代理 Pod。

类型 :布尔值

示例 :false

默认值: true

 

resources.limits.cpu

主机节点 CPU 的最大数量,单位为 millicore,部署中的 Pod 中运行的每个代理容器都可消耗。

键入: string

示例 :"500m"

默认值 : 使用与 OpenShift Container Platform 版本相同的默认值。查阅集群管理员。

 

resources.limits.memory

主机节点内存的最大数量,以字节为单位,部署中的 Pod 中运行的每个代理容器都可消耗。支持字节表示法(例如 K、M、G)或二进制等同的标记(Ki、Mi、Gi)。

键入: string

示例 :"1024M"

默认值 : 使用与 OpenShift Container Platform 版本相同的默认值。查阅集群管理员。

 

resources.requests.cpu

主机节点 CPU 的数量,单位为 millicore,部署中的每个代理容器都明确请求在 Pod 中运行。

键入: string

示例 : "250m"

默认值 : 使用与 OpenShift Container Platform 版本相同的默认值。查阅集群管理员。

 

resources.requests.memory

主机节点内存量(以字节为单位),即在显式部署请求中 Pod 中运行的每个代理容器。支持字节表示法(例如 K、M、G)或二进制等同的标记(Ki、Mi、Gi)。

键入: string

示例 :"512M"

默认值 : 使用与 OpenShift Container Platform 版本相同的默认值。查阅集群管理员。

 

storage.size

以字节为单位,部署中每个代理所需的持久性卷声明(PVC)的大小(以字节为单位)。此属性仅在将 persistenceEnabled 设为 true 时才适用。您指定的值 必须包含一个 单元。支持字节表示法(例如 K、M、G)或二进制等同的标记(Ki、Mi、Gi)。

键入: string

示例 :4Gi

默认值 :2Gi

 

jolokiaAgentEnabled

指定部署中的代理是否为 Jolokia JVM Agent 启用。如果此属性的值设置为 true,Fuse Console 可以发现并显示代理的运行时数据。

类型 :布尔值

示例 :true

默认值: false

 

ManagementRBACEnabled

指定部署中的代理是否启用了基于角色的访问控制(RBAC)。要使用 Fuse 控制台,您必须 将值设为 false,因为 Fuse 控制台使用自己的基于角色的访问控制。

类型 :布尔值

示例 :false

默认值: true

 

关联性

指定 pod 的调度限制。有关关联性属性的信息,请参阅 OpenShift Container Platform 文档中的 属性

 

容限(tolerations)

指定 pod 的容限。如需有关 tolerations 属性的信息,请参阅 OpenShift Container Platform 文档中的 属性

 

nodeSelector

指定与要调度到该节点上的 pod 标签匹配的标签。

 

storageClassName

指定用于 PVC 的存储类的名称。存储类为管理员提供描述和分类可用存储的方法。例如,存储类可能具有特定的质量级别的服务质量、备份策略或其他与其关联的管理策略。

键入: string

示例: gp3

默认值 : 未指定

 

livenessProbe

在正在运行的代理容器上配置定期健康检查,以检查代理是否正在运行。如需有关存活度探测属性的信息,请参阅 OpenShift Container Platform 文档中的 属性

 

readinessProbe

在正在运行的代理容器上配置定期健康检查,以检查代理是否接受网络流量。有关就绪度探测属性的详情,请查看 OpenShift Container Platform 文档中的 属性

 

labels

为代理 pod 分配标签。

键入: string

示例 :位置:"生产环境"

默认值 : 未指定

控制台

 

代理管理控制台配置。

 

expose

指定是否在部署中的每个代理公开管理控制台端口。

类型 :布尔值

示例 :true

默认值: false

 

sslEnabled

指定是否在管理控制台端口中使用 SSL。

类型 :布尔值

示例 :true

默认值: false

 

sslSecret

存储代理密钥存储、信任存储及其对应密码(所有 Base64 编码的)的 secret。如果没有为 sslSecret 指定值,控制台将使用默认 secret 名称。默认 secret 名称采用 < custom_resource_name> -console-secret 的形式。此属性仅在 sslEnabled 属性设置为 true 时才应用。

键入: string

示例 :my-broker-deployment-console-secret

默认值 : 未指定

 

podSecurity.serviceAccountName

为代理 pod 指定服务帐户名称。

键入: string

示例 :activemq-artemis-controller-manager

默认值 :default

 

podSecurityContext

指定以下 pod 级别安全属性和常见容器设置。

* fsGroup

* fsGroupChangePolicy

* runAsGroup

* runAsUser

* runAsNonRoot

* seLinuxOptions

* seccompProfile

* supplementalGroups

* sysctls

* windowsOptions

如需有关 podSecurityContext 属性的信息,请参阅 OpenShift Container Platform 文档中的 属性

 

useClientAuth

指定管理控制台是否需要客户端授权。

类型 :布尔值

示例 :true

默认值: false

acceptors.acceptor

 

单个接受器配置实例。

 

name*

接受者名称.

键入: string

示例 :my-acceptor

默认值 :不适用

 

port

用于接受或实例的端口号。

键入: int

示例 :5672

默认值 :61626,用于您定义的第一个接受者。然后,您定义的每个后续接受者会增加 10。

 

协议

在接受器实例上启用消息传递协议。

键入: string

: amqp,core

默认值 :all

 

sslEnabled

指定是否在接受器端口上启用 SSL。如果设置为 true,在 sslSecret 中指定的 secret 名称中查找 TLS/SSL 所需的凭证。

类型 :布尔值

示例 :true

默认值: false

 

sslSecret

存储代理密钥存储、信任存储及其对应密码(所有 Base64 编码的)的 secret。

如果您没有为 sslSecret 指定自定义 secret 名称,接受器会假定默认 secret 名称。默认 secret 名称的格式为 < custom_resource_name> - &lt;acceptor_name>-secret

即使接受者假设默认名称,您也必须自行创建此 secret。

键入: string

示例 :my-broker-deployment-my-acceptor-secret

默认值: & lt;custom_resource_name>- &lt;acceptor_name&gt; -secret

 

enabledCipherSuites

用于 TLS/SSL 通信的密码套件的逗号分隔列表。

指定客户端应用程序支持的最安全密码套件。如果您使用逗号分隔列表指定代理和客户端的一组密码套件,或者您不指定任何密码套件,则代理和客户端会相互协商要使用的密码套件。如果您不知道要指定哪些密码套件,建议您首先与以 debug 模式运行的客户端建立 broker-client 连接,以验证代理和客户端是通用的密码套件。然后,在代理中配置 enabledCipherSuites

键入: string

默认值 : 未指定

 

keyStoreProvider

代理使用的密钥存储的供应商名称。

键入: string

示例 :SunJCE

默认值 : 未指定

 

trustStoreProvider

代理使用的信任存储供应商名称。

键入: string

示例 :SunJCE

默认值 : 未指定

 

trustStoreType

代理使用的信任存储类型。

键入: string

示例 :JCEKS

默认值 :JKS

 

enabledProtocols

用于 TLS/SSL 通信的以逗号分隔的协议列表。

键入: string

示例 : TLSv1,TLSv1.1,TLSv1.2

默认值 : 未指定

 

needClientAuth

指定代理是否告知客户端在接受者上需要双向 TLS。此属性覆盖 wantClientAuth

类型 :布尔值

示例 :true

默认值 : 未指定

 

wantClientAuth

指定代理是否告知客户端在接受者上 请求 双向 TLS,但不强制要求。此属性将被 needClientAuth 覆盖。

类型 :布尔值

示例 :true

默认值 : 未指定

 

verifyHost

指定是否将客户端证书的 Common Name(CN)与其主机名进行比较,以验证它们是否匹配。这个选项仅在使用双向 TLS 时适用。

类型 :布尔值

示例 :true

默认值 : 未指定

 

sslProvider

指定 SSL 供应商是 JDK 还是 OPENSSL。

键入: string

示例 :OPENSSL

默认值 : JDK

 

sniHost

与传入连接上的 server_name 扩展匹配的正则表达式。如果名称不匹配,则拒绝与接受器的连接。

键入: string

示例 : some_regular_expression

默认值 : 未指定

 

expose

指定是否向 OpenShift Container Platform 之外的客户端公开接受者。

当您向 OpenShift 外部的客户端公开接收器时,Operator 会自动为部署中的每个代理 Pod 创建一个专用的服务和路由。

类型 :布尔值

示例 :true

默认值: false

 

anycastPrefix

客户端使用的前缀来指定应使用任何 广播 路由类型。

键入: string

示例 :jms.queue

默认值 : 未指定

 

multicastPrefix

客户端用来指定应该使用 多播路由 类型的前缀。

键入: string

示例 :/topic/

默认值 : 未指定

 

connectionsAllowed

接受者上允许的连接数。达到此限制时,会向日志发出 DEBUG 消息,并且连接将被拒绝。使用中的客户端类型决定了连接被拒绝时发生的情况。

键入: integer

示例 :2

默认值 : 0(无限连接)

 

amqpMinLargeMessageSize

代理至少需要消息大小,以便代理将 AMQP 消息作为较大消息处理。如果 AMQP 消息的大小等于或大于这个值,代理会将消息存储在大型消息目录中(/opt/ <custom_resource_name> /data/large-messages,默认)由代理用于消息存储。将值设为 -1 可禁用 AMQP 消息的大型消息处理。

键入: integer

示例 : 204800

默认值为: 102400(100 KB)

 

BindToAllInterfaces

如果设置为 true,则使用 0.0.0.0 IP 地址(而非 pod 的内部 IP 地址)配置代理接受器。当代理接受者具有 0.0.0.0 IP 地址时,它们绑定到为 pod 配置的所有接口,客户端通过使用 OpenShift Container Platform 端口转发将流量定向到代理。通常,您要使用这个配置来调试服务。如需有关端口转发的更多信息,请参阅 OpenShift Container Platform 文档中的使用 端口转发访问容器中的应用程序

注意

如果错误地使用端口转发,则可能会给您的环境造成安全隐患。在可能的情况下,红帽建议您不要在生产环境中使用端口转发。

类型 :布尔值

示例 :true

默认值: false

connectors.connector

 

单一连接器配置实例。

 

name*

连接器名称。

键入: string

示例 :my-connector

默认值 :不适用

 

type

要创建的连接器类型,即 tcpvm

键入: string

示例 :vm

默认值 :tcp

 

host*

要连接到的主机名或 IP 地址。

键入: string

示例 :192.168.0.58

默认值 : 未指定

 

port*

用于连接器实例的端口号。

键入: int

示例 : 22222

默认值 : 未指定

 

sslEnabled

指定是否在连接器端口上启用 SSL。如果设置为 true,在 sslSecret 中指定的 secret 名称中查找 TLS/SSL 所需的凭证。

类型 :布尔值

示例 :true

默认值: false

 

sslSecret

存储代理密钥存储、信任存储及其对应密码(所有 Base64 编码的)的 secret。

如果您没有为 sslSecret 指定自定义 secret 名称,连接器会假定默认 secret 名称。默认 secret 名称的格式为 < custom_resource_name> - &lt;connector_name>-secret

即使连接器假定默认名称,您也必须自行创建此 secret。

键入: string

示例 :my-broker-deployment-my-connector-secret

默认值: & lt;custom_resource_name>- &lt;connector_name&gt; -secret

 

enabledCipherSuites

用于 TLS/SSL 通信的密码套件的逗号分隔列表。

键入: string

注意 : 对于连接器,建议您不要 指定密码套件列表。

默认值 : 未指定

 

keyStoreProvider

代理使用的密钥存储的供应商名称。

键入: string

示例 :SunJCE

默认值 : 未指定

 

trustStoreProvider

代理使用的信任存储供应商名称。

键入: string

示例 :SunJCE

默认值 : 未指定

 

trustStoreType

代理使用的信任存储类型。

键入: string

示例 :JCEKS

默认值 :JKS

 

enabledProtocols

用于 TLS/SSL 通信的以逗号分隔的协议列表。

键入: string

示例 : TLSv1,TLSv1.1,TLSv1.2

默认值 : 未指定

 

needClientAuth

指定代理是否告知客户端在连接器上需要双向 TLS。此属性覆盖 wantClientAuth

类型 :布尔值

示例 :true

默认值 : 未指定

 

wantClientAuth

指定代理是否告知客户端在连接器上 请求 双向 TLS,但不要求。此属性将被 needClientAuth 覆盖。

类型 :布尔值

示例 :true

默认值 : 未指定

 

verifyHost

指定是否将客户端证书的 Common Name(CN)与其主机名进行比较,以验证它们是否匹配。这个选项仅在使用双向 TLS 时适用。

类型 :布尔值

示例 :true

默认值 : 未指定

 

sslProvider

指定 SSL 供应商是 JDK 还是 OPENSSL

键入: string

示例 :OPENSSL

默认值 : JDK

 

sniHost

与传出连接上的 server_name 扩展匹配的正则表达式。如果名称不匹配,则拒绝连接器连接。

键入: string

示例 : some_regular_expression

默认值 : 未指定

 

expose

指定是否将连接器公开给 OpenShift Container Platform 之外的客户端。

类型 :布尔值

示例 :true

默认值: false

addressSettings.applyRule

 

指定 Operator 如何为每个匹配地址或一组地址应用您添加到 CR 中的配置。

您可以指定的值有:

merge_all

对于 CR 中指定的地址设置,以及 符合相同地址或一组地址的默认配置:

  • 将默认配置中指定的任何属性值替换为 CR 中指定的值。
  • 保留在 CR 默认配置中指定的任何属性值。请在最终合并的配置中包含其中之一。

对于在 CR 中指定的地址设置,或者唯一匹配一个特定地址或一组地址的默认配置,将它们包括在最终合并的配置中。

merge_replace

对于 CR 中指定的地址设置,以及 符合相同地址或一组地址的默认配置,请将 CR 中指定的设置包括在最终合并的配置中。不要 包括默认配置中指定的任何属性,即使 CR 中没有指定这些属性。

+ 对于在 CR 中指定的地址设置,或者唯一匹配一个特定地址或一组地址的默认配置,将它们包括在最终合并的配置中。

replace_all
使用在 CR 中指定的内容替换默认配置中指定的所有地址设置最后,Igred 配置与 CR 中指定的完全一致。

键入: string

示例 : replace_all

默认值 :merge_all

addressSettings.addressSetting

 

匹配地址 或一组 地址的地址设置。

 

addressFullPolicy

指定配置有 maxSizeBytes 的地址已满时会发生什么。可用的策略有:

页面
发送到完整地址的消息将传给磁盘。
DROP
发送到完整地址的消息将被静默丢弃。
FAIL
发送到完整地址的消息将被丢弃,消息制作者会收到异常。
BLOCK

当消息制作者试图发送任何进一步消息时,会阻断。

BLOCK 策略仅适用于 AMQP、OpenWire 和 Core 协议,因为这些协议支持流控制。

键入: string

示例 : DROP

默认值 :PAGE

 

autoCreateAddresses

指定代理在客户端发送信息时是否自动创建地址,还是尝试使用来自消息的队列(绑定到不存在的地址的队列)。

类型 :布尔值

示例 :false

默认值: true

 

autoCreateDeadLetterResources

指定代理是否自动创建死信地址和队列来接收未传输的消息。

如果 参数设置为 true,代理会自动创建一个死信地址和一个关联的死信队列。自动创建的地址的名称与您为 deadLetterAddress 指定的值匹配。

类型 :布尔值

示例 :true

默认值: false

 

autoCreateExpiryResources

指定代理是否自动创建地址和队列来接收过期的消息。

如果 参数设置为 true,代理会自动创建一个到期地址和关联的到期队列。自动创建的地址的名称与您为 到期Address 指定的值匹配。

类型 :布尔值

示例 :true

默认值: false

 

autoCreateJmsQueues

此属性已弃用。改为使用 autoCreateQueues

 

autoCreateJmsTopics

此属性已弃用。改为使用 autoCreateQueues

 

autoCreateQueues

指定代理在客户端发送消息时是否自动创建队列,还是尝试使用消息中的消息,即不存在的队列。

类型 :布尔值

示例 :false

默认值: true

 

autoDeleteAddresses

指定代理不再有队列时,代理是否自动删除自动创建的地址。

类型 :布尔值

示例 :false

默认值: true

 

autoDeleteAddressDelay

这个时间(以毫秒为单位),代理会在地址没有队列时自动删除自动创建的地址。

键入: integer

示例 :100

默认值 :0

 

autoDeleteJmsQueues

此属性已弃用。改为使用 autoDeleteQueues

 

autoDeleteJmsTopics

此属性已弃用。改为使用 autoDeleteQueues

 

autoDeleteQueues

指定当队列没有使用者且没有消息时,代理是否自动删除自动创建的队列。

类型 :布尔值

示例 :false

默认值: true

 

autoDeleteCreatedQueues

指定当队列没有使用者且没有消息时,代理是否自动删除手动创建的队列。

类型 :布尔值

示例 :true

默认值: false

 

autoDeleteQueuesDelay

这个时间(以毫秒为单位),代理会在队列没有消费者时自动删除自动创建的队列。

键入: integer

示例 :10

默认值 :0

 

autoDeleteQueuesMessageCount

在代理评估队列是否可自动删除前,可以处于队列中的最大消息数。

键入: integer

示例 :5

默认值 :0

 

configDeleteAddresses

当配置文件重新加载时,这个参数指定如何处理从配置文件中删除的地址(及其队列)。您可以指定以下值:

OFF
重新加载配置文件时,代理不会删除地址。
FORCE
当配置文件重新加载时,代理会删除地址及其队列。如果队列中有任何消息,它们也会被删除。

键入: string

示例 : FORCE

默认值 :OFF

 

configDeleteQueues

当配置文件重新加载时,此设置指定代理如何处理从配置文件中删除的队列。您可以指定以下值:

OFF
重新加载配置文件时,代理不会删除队列。
FORCE
当配置文件重新加载时,代理会删除队列。如果队列中有任何消息,它们也会被删除。

键入: string

示例 : FORCE

默认值 :OFF

 

deadLetterAddress

代理发送到的地址(即,未发送)消息。

键入: string

: DLA 示例

默认值: None

 

deadLetterQueuePrefix

代理应用到自动创建死信队列的名称前缀。

键入: string

示例 :myDLQ.

默认值 :DLQ.

 

deadLetterQueueSuffix

代理应用到自动创建的死信队列的后缀。

键入: string

示例 : .DLQ

默认值: None

 

defaultAddressRoutingType

在自动创建的地址上使用的路由类型。

键入: string

示例 : ANYCAST

默认值 :MULTICAST

 

defaultConsumersBeforeDispatch

在消息分配可以开始地址上的队列前所需的消费者数量。

键入: integer

示例 :5

默认值 :0

 

defaultConsumerWindowSize

消费者的默认窗口大小,以字节为单位。

键入: integer

示例 :300000

默认值 : 1048576(1024*1024)

 

defaultDelayBeforeDispatch

默认时间(以毫秒为单位),如果尚未达到 defaultConsumersBeforeDispatch 指定的值,代理会在分配消息前等待。

键入: integer

示例 :5

默认值 : -1(无延迟)

 

defaultExclusiveQueue

指定默认情况下是否有地址上所有队列都是独占队列。

类型 :布尔值

示例 :true

默认值: false

 

defaultGroupBuckets

用于消息分组的存储桶数。

键入: integer

示例 :0(禁用消息分组)

默认值 : -1(无限制)

 

defaultGroupFirstKey

用于指示组中消息先到的消费者的键。

键入: string

示例: firstMessageKey

默认值: None

 

defaultGroupRebalance

指定在新消费者连接到代理时是否重新平衡组。

类型 :布尔值

示例 :true

默认值: false

 

defaultGroupRebalancePauseDispatch

指定在代理重新平衡组时是否暂停消息发送。

类型 :布尔值

示例 :true

默认值: false

 

defaultLastValueQueue

指定地址上所有队列是否默认为最后值队列。

类型 :布尔值

示例 :true

默认值: false

 

defaultLastValueKey

用于最后一个值队列的默认键。

键入: string

示例 : stock_ticker

默认值: None

 

defaultMaxConsumers

队列上允许的最大消费者数量。

键入: integer

示例 :100

默认值 : -1(无限制)

 

defaultNonDestructive

默认情况下,指定地址上所有队列是否不是破坏性。

类型 :布尔值

示例 :true

默认值: false

 

defaultPurgeOnNoConsumers

指定代理是否在没有消费者时清除队列的内容。

类型 :布尔值

示例 :true

默认值: false

 

defaultQueueRoutingType

在自动创建的队列中使用的路由类型。默认值为 MULTICAST

键入: string

示例 : ANYCAST

默认值 :MULTICAST

 

defaultRingSize

没有明确设置环大小的匹配队列的默认环大小。

键入: integer

示例 :3

默认值 : -1(无大小限制)

 

enableMetrics

指定配置了指标插件,如 Prometheus 插件会为匹配地址或一组地址收集指标。

类型 :布尔值

示例 :false

默认值: true

 

expiryAddress

接收过期消息的地址。

键入: string

示例 :myExpiryAddress

默认值: None

 

expiryDelay

过期时间(以毫秒为单位)应用于使用默认的过期时间。

键入: integer

示例 :100

默认值 : -1(没有应用过期时间)

 

expiryQueuePrefix

代理应用到自动创建到期队列的名称前缀。

键入: string

示例 :myExp.

默认值 :EXP。

 

expiryQueueSuffix

代理应用于自动创建到期队列名称的后缀。

键入: string

示例 : .EXP

默认值: None

 

lastValueQueue

指定队列是否只使用最后的值。

类型 :布尔值

示例 :true

默认值: false

 

managementBrowsePageSize

指定管理资源可以浏览多少消息。

键入: integer

示例 :100

默认值 :200

 

匹配*

与代理中配置的地址设置匹配的字符串。您可以指定一个准确的地址名称,或使用通配符表达式将地址设置与一组地址匹配。

如果您使用通配符表达式作为 match 属性的值,则必须将值放在单引号中,如 'myAddresses*'

键入: string

示例 :"myAddresses*"

默认值: None

 

maxDeliveryAttempts

指定代理在发送消息到配置的死信地址前尝试传递的次数。

键入: integer

示例 :20

默认值 :10

 

maxExpiryDelay

过期时间(以毫秒为单位)应用于使用超过这个值的过期时间的信息。

键入: integer

示例 :20

默认值 : -1(没有应用最大到期时间)

 

maxRedeliveryDelay

代理重新发送尝试之间的最大值(以毫秒为单位)。

键入: integer

示例 :100

默认值redeliveryDelay 值的 10 倍,默认值为 0

 

maxSizeBytes

地址的最大内存大小,以字节为单位。当 地址FullPolicy 设置为 PAGING、BeilometerFAIL 时使用。还支持字节表示法,如"K"、"Mb"和"GB"。

键入: string

示例 :10Mb

默认值 : -1(无限制)

 

maxSizeBytesRejectThreshold

最大大小(以字节为单位),一个地址可在代理开始拒绝信息前访问。当 address-full-policy 设置为 BLOCK 时使用。只能与 maxSizeBytes 结合使用,用于 AMQP 协议。

键入: integer

示例 :500

默认值 : -1(无最大大小)

 

messageCounterHistoryDayLimit

代理为地址保留消息计数器历史记录的天数。

键入: integer

示例 :5

默认值 :0

 

minExpiryDelay

过期时间(以毫秒为单位)应用于使用过期时间低于这个值的消息。

键入: integer

示例 :20

默认值 : -1(没有应用最小过期时间)

 

pageMaxCacheSize

要保留内存的页面文件数量,以便在分页导航期间优化 I/O。

键入: integer

示例 :10

默认值 :5

 

pageSizeBytes

分页大小(以字节为单位)。还支持字节表示法,如 KMbGB

键入: string

示例 :20971520

默认值为: 10485760(approximately 10.5 MB)

 

redeliveryDelay

代理在重出已取消消息前等待的时间(以毫秒为单位)。

键入: integer

示例 :100

默认值 :0

 

redeliveryDelayMultiplier

应用于 重新传送延迟 值的多因素。

键入: number

示例 :5

默认值 :1

 

redeliveryCollisionAvoidanceFactor

应用到重新交付 延迟 值的多选因素以避免发生冲突。

键入: number

示例 :1.1

默认值 :0

 

redistributionDelay

在重新分发所有剩余消息前,代理会在队列上关闭最后一个消费者后等待这一时间。

键入: integer

示例 :100

默认值 : -1(未设置)

 

retroactiveMessageCount

为在地址上创建未来的队列保留的消息数量。

键入: integer

示例 :100

默认值 :0

 

sendToDlaOnNoRoute

如果无法路由到任何队列,请指定消息是否会被发送到配置的死信地址。

类型 :布尔值

示例 :true

默认值: false

 

slowConsumerCheckPeriod

代理检查较慢的用户的频率( 以秒为单位 )。

键入: integer

示例 :15

默认值 :5

 

slowConsumerPolicy

指定识别缓慢消费者时会发生什么。有效选项为 KILLNOTIFYKILL 可以终止使用者的连接,这样可使用相同的连接影响任何客户端线程。NotI FY 向客户端发送 CONSUMER_SLOW 管理通知。

键入: string

示例 : KILL

默认值 : NOTIFY

 

slowConsumerThreshold

在消费者被视为缓慢前,每秒消息消耗率最少。

键入: integer

示例 :100

默认值 : -1(未设置)

brokerProperties

 

配置在代理的自定义资源定义(CRD)中不公开的代理属性,且在自定义资源(CR)中不能配置。

 

<property name>=<value>

为代理配置的属性名称和值列表。代理Properties 部分中目前可配置属性 globalMaxSize。设置 globalMaxSize 属性会覆盖分配给代理的默认内存量。默认情况下,代理会为代理 Java 虚拟机提供的最大内存一半。

globalMaxSize 属性的默认单元是字节。要更改默认单元,请将 m(for MB)或 g(用于 GB)的后缀添加到值。

键入: string

示例: globalMaxSize=512m

默认值 :不适用

升级

  
 

enabled

当您更新 version 值来指定 AMQ Broker 的新目标版本时,指定是否允许 Operator 自动将 deploymentPlan.image 值更新为与 AMQ Broker 版本对应的代理容器镜像。

类型 :布尔值

示例 :true

默认值: false

 

指定当您将 version 值从一个 AMQ Broker 的一个次版本升级到另一个 次版本时,是否允许 Operator 自动更新 deploymentPlan.image 值,例如从 7.8.0 升级到 7.10.7

类型 :布尔值

示例 :true

默认值: false

version

 

指定您希望 Operator 自动更新 CR 的目标 次版本 AMQ Broker,以使用对应的代理容器镜像。例如,如果您将 version 的值从 7.6.0 改为 7.7.0 (且 upgrade .enabled 和 upgrade .minor 都被设置为 true),则 Operator 会将 deploymentPlan.image 更新为表单 registry.redhat.io/amq7/amq-broker-rhel8:7.8-x 的代理镜像。

键入: string

示例 : 7.7.0

默认值 : AMQ Broker 的当前版本

8.1.2. 地址自定义资源配置参考

基于地址 CRD 的 CR 实例可让您为部署中的代理定义地址和队列。下表详细介绍了您可以配置的项目。

重要

部署的任何对应自定义资源(CR)中需要标记为星号(*)的配置项。如果您没有为非必需项显式指定值,则配置将使用默认值。

条目描述和使用

addressName*

要在代理上创建的地址名称。

键入: string

示例 :address0

默认值 : 未指定

queueName

在代理上创建的队列名称。如果没有指定 queueName,则 CR 只创建地址。

键入: string

示例 : queue0

默认值 : 未指定

removeFromBrokerOnDelete*

指定 Operator 在删除该部署的地址 CR 实例时,是否删除部署中的所有代理的现有地址。默认值为 false,这意味着在删除 CR 时,Operator 不会删除现有的地址。

类型 :布尔值

示例 :true

默认值: false

routingType*

要使用的路由类型,任何广播 多播

键入: string

示例 :任何广播

默认值 :多播

8.1.3. 安全自定义资源配置参考

基于安全 CRD 的 CR 实例可让您为部署中的代理定义安全配置,包括:

  • 用户和角色
  • 登录模块,包括 propertiesLoginModuleguestLoginModulekeycloakLoginModule
  • 基于角色的访问控制
  • 控制台访问控制
注意

很多选项都需要您了解安全代理中描述的 代理安全概念

下表详细介绍了您可以配置的项目。

重要

部署的任何对应自定义资源(CR)中需要标记为星号(*)的配置项。如果您没有为非必需项显式指定值,则配置将使用默认值。

条目子条目描述和使用

loginModules

 

一个或多个登录模块配置。

登录模块可以是以下类型之一:

  • propertiesLoginModule 允许您直接定义代理用户。
  • guestLoginModule - 对于没有登录凭证的用户,或者凭证失败身份验证,您可以使用客户机帐户为代理授予有限访问权限。
  • keycloakLoginModule. - 允许您使用红帽单点登录保护代理。

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

一个或多个登录模块。每个条目以前必须在上面的 loginModules 部分中定义。

 

brokerDomain.loginModules.name

登录模块的名称

键入: string

示例 : prop-module

默认值 :不适用

 

brokerDomain.loginModules.flag

与 propertiesLoginModule、requiredrequisitesufficientoptional 相同。

键入: 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、requiredrequisitesufficientoptional 相同。

键入: string

示例 : sufficient

默认值 :不适用

 

consoleDomain.loginModules.debug

Debug

类型 :布尔值

示例 :false

 

consoleDomain.loginModules.reload

reload

类型 :布尔值

示例 :true

默认 :false

securitySettings

 

要添加到 broker.xmlmanagement.xml的其他安全设置

 

broker.match

安全设置部分的地址匹配模式。有关匹配模式 语法的详情,请参阅 AMQ Broker 通配符语法。

 

broker.permissions.operationType

安全设置的操作类型,如 设置权限 中所述

键入: string

示例 :createAddress

默认值 :不适用

 

broker.permissions.roles

安全设置应用于这些角色,如 设置权限 中所述

键入: string

示例 :root

默认值 :不适用

securitySettings.management

 

用于配置 management.xml 的选项。

 

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 配置。您可以配置以下参数:

表 8.1. 应用程序模板参数
参数描述

AMQ_ADDRESSES

在以逗号分隔的列表中,指定代理中默认可用的地址。

AMQ_ANYCAST_PREFIX

指定应用于多路复用协议端口 61616 和 61617 的任播前缀。

AMQ_CLUSTERED

启用集群。

AMQ_CLUSTER_PASSWORD

指定用于集群的密码。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。

AMQ_CLUSTER_USER

指定集群要使用的集群用户。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。

AMQ_CREDENTIAL_SECRET

指定存储在代理用户名/密码、集群用户名/密码以及 truststore 和密钥存储密码等敏感凭证的 secret。

AMQ_DATA_DIR

指定数据的目录。StatefulSets 中使用。

AMQ_DATA_DIR_LOGGING

指定数据目录日志记录的目录。

AMQ_EXTRA_ARGS

指定要传递给 artemis create 的额外参数。

GLOBAL_MAX_SIZE

指定消息数据可以消耗的最大内存量。如果没有指定值,则会分配一半系统内存。

AMQ_KEYSTORE

指定 SSL 密钥存储文件名。如果没有指定值,会生成一个随机密码,但不会配置 SSL。

AMQ_KEYSTORE_PASSWORD

(可选)指定用于解密 SSL 密钥存储的密码。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。

AMQ_KEYSTORE_TRUSTSTORE_DIR

指定挂载 secret 的目录。默认值为 /etc/amq-secret-volume

AMQ_MAX_CONNECTIONS

仅针对 SSL,指定接受者将接受的最大连接数。

AMQ_MULTICAST_PREFIX

指定应用于多个协议端口 61616 和 61617 的多播前缀。

AMQ_NAME

指定代理实例的名称。默认值为 amq-broker

AMQ_PASSWORD

指定用于向代理进行身份验证的密码。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。

AMQ_PROTOCOL

指定以逗号分隔的列表中代理使用的消息协议。可用选项包括 amqpmqttopenwirestomphornetq。如果没有指定,则所有协议都可用。请注意,要与红帽 JBoss 企业应用平台集成镜像,必须指定 OpenWire 协议,同时也可以选择指定其他协议。

AMQ_QUEUES

在以逗号分隔的列表中,指定代理上默认可用的队列。

AMQ_REQUIRE_LOGIN

如果设置为 true,则需要登录。如果没有指定,或设置为 false,则允许匿名访问。默认情况下不指定此参数的值。

AMQ_ROLE

指定创建的角色的名称。默认值为 amq

AMQ_TRUSTSTORE

指定 SSL 信任存储文件名。如果没有指定值,会生成一个随机密码,但不会配置 SSL。

AMQ_TRUSTSTORE_PASSWORD

(可选)指定用于解密 SSL 信任存储的密码。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。

AMQ_USER

指定用于向代理进行身份验证的用户名。AMQ Broker 应用程序模板使用存储在 AMQ_CREDENTIAL_SECRET 中名为 的 secret 的值。

APPLICATION_NAME

指定 OpenShift 内部使用的应用程序的名称。它用于服务、Pod 和其他应用程序中的其他对象的名称。

IMAGE

指定镜像。用于 持久性persistent-sslstatefulset-clustered 模板。

IMAGE_STREAM_NAMESPACE

指定镜像流命名空间。在 ssl基本模板中 使用。

OPENSHIFT_DNS_PING_SERVICE_PORT

指定 OpenShift DNS ping 服务的端口号。

PING_SVC_NAME

指定 OpenShift DNS ping 服务的名称。如果您为 APPLICATION_NAME 指定值,则默认值为 $APPLICATION_NAME-ping。否则,默认值为 ping。如果您为 PING_SVC_NAME 指定自定义值,这个值会覆盖默认值。如果要使用模板在同一 OpenShift 项目命名空间中部署多个代理集群,您必须确保每个部署都有 PING_SVC_NAME 唯一值。

VOLUME_CAPACITY

指定数据库卷的持久性存储大小。

注意

如果您将 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

法律通告

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.