OpenShift에 AMQ Broker 배포

Red Hat AMQ Broker 7.10

AMQ Broker 7.10과 함께 사용하는 경우

초록

OpenShift Container Platform에 AMQ Broker를 설치하고 배포하는 방법을 알아봅니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. OpenShift Container Platform의 AMQ Broker 소개

Red Hat AMQ Broker 7.10은 OCP(OpenShift Container Platform) 4.11, 4.12, 4.13 또는 4.14에서 사용할 수 있는 컨테이너화된 이미지로 사용할 수 있습니다.

AMQ Broker는 Apache ActiveMQ Artemis를 기반으로 합니다. JMS와 호환되는 메시지 브로커를 제공합니다. 초기 브로커 Pod를 설정한 후에는 OpenShift Container Platform 기능을 사용하여 중복을 빠르게 배포할 수 있습니다.

1.1. 버전 호환성 및 지원

OpenShift Container Platform 이미지 버전 호환성에 대한 자세한 내용은 다음을 참조하십시오.

참고

OpenShift Container Platform에서 AMQ Broker를 모두 배포하면 이제 RHEL 8 기반 이미지를 사용합니다.

1.2. 지원되지 않는 기능

  • 마스터 슬레이브 기반 고가용성

    마스터 및 슬레이브 쌍을 구성하여 달성한 고가용성(HA)은 지원되지 않습니다. 대신 AMQ Broker는 OpenShift Container Platform에 제공된 HA 기능을 사용합니다.

  • 외부 클라이언트는 AMQ Broker에서 제공하는 토폴로지 정보를 사용할 수 없습니다.

    AMQ Core Protocol JMS Client 또는 AMQ JMS Client가 OpenShift Container Platform 클러스터의 브로커에 연결하는 경우 브로커는 현재 브로커에 대한 연결이 손실되는 경우 클라이언트의 다른 브로커 각각에 대한 IP 주소 및 포트 정보를 클라이언트에 보낼 수 있습니다.

    각 브로커에 제공된 IP 주소는 내부 IP 주소로, OpenShift Container Platform 클러스터 외부에 있는 클라이언트에 액세스할 수 없습니다. 외부 클라이언트가 내부 IP 주소를 사용하여 브로커에 연결하지 못하도록 하려면 클라이언트가 처음에 브로커에 연결하도록 클라이언트에서 사용하는 URI에 다음 구성을 설정합니다.

    클라이언트설정

    AMQ Core Protocol JMS 클라이언트

    useTopologyForLoadBalancing=false

    AMQ JMS 클라이언트

    failover.amqpOpenServerListAction=IGNORE

1.3. 문서 규칙

이 문서에서는 sudo 명령, 파일 경로 및 대체 가능한 값에 대해 다음 규칙을 사용합니다.

sudo 명령

이 문서에서는 root 권한이 필요한 모든 명령에 sudo 를 사용합니다. sudo 를 사용할 때는 변경 사항이 전체 시스템에 영향을 줄 수 있으므로 항상 주의해야 합니다.

sudo 사용에 대한 자세한 내용은 The sudo command 를 참조하십시오.

이 문서에서 파일 경로 사용 정보

이 문서에서 모든 파일 경로는 Linux, UNIX 및 유사한 운영 체제(예: /home/.. )에 유효합니다. Microsoft Windows를 사용하는 경우 동등한 Microsoft Windows 경로(예 : C:\Users\.. )를 사용해야 합니다.

교체 가능한 값

이 문서에서는 환경에 고유한 값으로 교체해야 하는 대체 가능한 값을 사용하는 경우가 있습니다. 교체할 수 있는 값은 소문자로 묶고(< >), italics 및 monospace 글꼴을 사용하여 스타일을 지정합니다. 여러 단어가 밑줄(_)으로 구분됩니다.

예를 들어 다음 명령에서 < project_name> 을 자체 프로젝트 이름으로 교체합니다.

$ oc new-project <project_name>

2장. OpenShift Container Platform에서 AMQ Broker 배포 계획

이 섹션에서는 Operator 기반 배포를 계획하는 방법을 설명합니다.

Operator 는 OpenShift 애플리케이션을 패키징, 배포, 관리할 수 있는 프로그램입니다. Operator는 종종 일반 또는 복잡한 작업을 자동화합니다. 일반적으로 Operator는 다음을 제공하기 위한 것입니다.

  • 일관되고 반복 가능한 설치
  • 시스템 구성 요소의 상태 점검
  • OTA(Over-the-Air) 업데이트
  • 관리형 업그레이드

Operator를 사용하면 배포를 구성하는 데 사용한 사용자 정의 리소스(CR) 인스턴스의 변경 사항을 항상 수신 대기하므로 브로커 인스턴스가 실행되는 동안 변경할 수 있습니다. CR을 변경하면 Operator는 변경 사항을 기존 브로커 배포와 조정하고, 변경 사항을 반영하도록 배포를 업데이트합니다. 또한 Operator는 메시지 마이그레이션 기능을 제공하여 메시징 데이터의 무결성을 보장합니다. 배포의 의도적인 스케일 다운으로 인해 클러스터형 배포의 브로커가 종료되면 이 기능은 동일한 브로커 클러스터에서 계속 실행 중인 브로커 Pod로 메시지를 마이그레이션합니다.

2.1. AMQ Broker Operator 사용자 정의 리소스 정의 개요

일반적으로 CRD(Custom Resource Definition)는 Operator와 함께 배포된 사용자 정의 OpenShift 오브젝트에 대해 수정할 수 있는 구성 항목의 스키마입니다. 해당 CR(사용자 정의 리소스) 인스턴스를 생성하면 CRD의 구성 항목에 대한 값을 지정할 수 있습니다. Operator 개발자인 경우 CRD를 통해 노출하는 항목은 기본적으로 배포된 오브젝트가 구성 및 사용되는 방법에 대한 API가 됩니다. CRD가 Kubernetes를 통해 자동으로 노출되므로 일반 HTTP curl 명령을 통해 CRD에 직접 액세스할 수 있습니다.

OperatorHub 그래픽 인터페이스를 통해 OpenShift CLI(명령줄 인터페이스) 또는 Operator Lifecycle Manager를 사용하여 AMQ Broker Operator를 설치할 수 있습니다. 두 경우 모두 AMQ Broker Operator에 아래에 설명된 CRD가 포함되어 있습니다.

기본 브로커 CRD

이 CRD를 기반으로 CR 인스턴스를 배포하여 브로커 배포를 생성하고 구성합니다.

Operator 설치 방법에 따라 이 CRD는 다음과 같습니다.

  • Operator 설치 아카이브(OpenShift CLI 설치 방법)의 crds 디렉터리에 있는 broker_activemqartemis_crd 파일
  • OpenShift Container Platform 웹 콘솔의 Custom Resource Definitions 섹션에 있는 ActiveMQArtemis CRD(OperatorHub 설치 방법)
Address CRD

이 CRD를 기반으로 CR 인스턴스를 배포하여 브로커 배포에 대한 주소 및 큐를 생성합니다.

Operator 설치 방법에 따라 이 CRD는 다음과 같습니다.

  • Operator 설치 아카이브(OpenShift CLI 설치 방법)의 crds 디렉터리에 있는 broker_activemqartemisaddress_crd 파일
  • OpenShift Container Platform 웹 콘솔 (OperatorHub 설치 방법)의 Custom Resource Definitions 섹션에 있는 ActiveMQArtemisAddresss CRD
보안 CRD

이 CRD를 기반으로 CR 인스턴스를 배포하여 사용자를 생성하고 해당 사용자를 보안 컨텍스트와 연결합니다.

Operator 설치 방법에 따라 이 CRD는 다음과 같습니다.

  • Operator 설치 아카이브(OpenShift CLI 설치 방법)의 crds 디렉터리에 있는 broker_activemqartemissecurity_crd 파일
  • OpenShift Container Platform 웹 콘솔(OperatorHub 설치 방법)의 Custom Resource Definitions 섹션에 있는 ActiveMQArtemisSecurity CRD입니다.
scaleDown CRD

Operator 는 메시지 마이그레이션을 위해 스케일다운 컨트롤러를 인스턴스화할 때 이 CRD를 기반으로 CR 인스턴스를 자동으로 생성합니다.

Operator 설치 방법에 따라 이 CRD는 다음과 같습니다.

  • Operator 설치 아카이브(OpenShift CLI 설치 방법)의 crds 디렉터리에 있는 broker_activemqartemisscaledown_crd 파일
  • OpenShift Container Platform 웹 콘솔(OperatorHub 설치 방법)의 Custom Resource Definitions 섹션에 있는 ActiveMQArtemisScaledown CRD입니다.

추가 리소스

2.2. AMQ Broker Operator 샘플 사용자 정의 리소스 개요

설치 중에 다운로드하여 추출한 AMQ Broker Operator 아카이브에는 deploy/crs 디렉터리에 샘플 CR(사용자 정의 리소스) 파일이 포함되어 있습니다. 다음 샘플 CR 파일을 사용하면 다음을 수행할 수 있습니다.

  • SSL 또는 클러스터링 없이 최소 브로커를 배포합니다.
  • 주소를 정의합니다.

다운로드 및 추출한 브로커 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
브로커 저널과 함께 AIO(Asynchronous I/O)를 사용합니다.
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에 broker 또는 Init Container 이미지 이름을 명시적으로 지정 할 필요가 없습니다. 기본적으로 CR을 배포하고 컨테이너 이미지 값을 명시적으로 지정하지 않으면 Operator에서 사용할 적절한 컨테이너 이미지를 자동으로 선택합니다.

참고

OpenShift 명령줄 인터페이스를 사용하여 Operator를 설치하는 경우 Operator 설치 아카이브에 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일이 포함됩니다. 샘플 CR에서 spec.deploymentPlan.image 속성이 포함되어 자리 표시자 의 기본값으로 설정됩니다. 이 값은 Operator에서 CR을 배포할 때까지 브로커 컨테이너 이미지를 선택하지 않음을 나타냅니다.

Init Container 이미지를 지정하는 spec.deploymentPlan.initImage 속성은 broker_activemqartemis_cr.yaml 샘플 CR 파일에 포함되어 있지 않습니다. CR에 spec.deploymentPlan.initImage 속성을 명시적으로 포함하지 않고 값을 지정하면 Operator에서 CR을 배포할 때 사용할 적절한 기본 제공 Init Container 이미지를 선택합니다.

Operator가 이러한 이미지를 선택하는 방법은 이 섹션에 설명되어 있습니다.

브로커 및 Init Container 이미지를 선택하려면 먼저 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.enabledtrue설정되지 않거나 spec.version7.7.0 이전의 AMQ Broker 버전으로 설정된 경우 Operator는 최신 버전의 AMQ Broker(즉, 7.10.6)를 사용합니다.

그러면 Operator에서 컨테이너 플랫폼을 탐지합니다. AMQ Broker Operator는 다음 컨테이너 플랫폼에서 실행할 수 있습니다.

  • OpenShift Container Platform (x86_64)
  • IBM Z의 OpenShift Container Platform (s390x)
  • IBM Power Systems의 OpenShift Container Platform (ppc64le)

AMQ Broker 및 컨테이너 플랫폼의 버전에 따라 Operator는 operator.yaml 구성 파일에서 두 개의 환경 변수 세트를 참조합니다. 이러한 환경 변수 세트는 다음 하위 섹션에 설명된 대로 다양한 AMQ Broker 버전에 대해 브로커 및 Init Container 이미지를 지정합니다.

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 Systems의 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 Systems의 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

각 환경 변수의 값은 Red Hat에서 사용할 수 있는 브로커 컨테이너 이미지를 지정합니다. 예를 들면 다음과 같습니다.

- 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:a8b2a9364fd06c8e1c29b8f8f28d3e4844bf7840a62b67137b663c558982d4a3

따라서 AMQ Broker 버전 및 컨테이너 플랫폼에 따라 Operator에서 해당 환경 변수 이름을 결정합니다. Operator는 브로커 컨테이너를 시작할 때 해당 이미지 값을 사용합니다.

참고

operator.yaml 파일에서 Operator는SHA( Secure Hash Algorithm ) 값으로 표시되는 이미지를 사용합니다. 숫자 기호(#) 기호로 시작하는 주석 행은 SHA 값이 특정 컨테이너 이미지 태그에 해당함을 나타냅니다.

2.4.2. Init Container 이미지의 환경 변수

Init Container 이미지의 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

각 환경 변수의 값은 Red Hat에서 사용할 수 있는 Init Container 이미지를 지정합니다. 예를 들면 다음과 같습니다.

- 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:35b7d96d5065f280a528626abd2c3df84e79ccea93ab6bd8b8837af66c330f30

따라서 AMQ Broker 버전에 따라 Operator에서 적용 가능한 환경 변수 이름을 결정합니다. Operator는 Init Container를 시작할 때 해당 이미지 값을 사용합니다.

참고

예제에 표시된 대로 Operator는SHA( Secure Hash Algorithm ) 값으로 표시되는 이미지를 사용합니다. 숫자 기호(#) 기호로 시작하는 주석 행은 SHA 값이 특정 컨테이너 이미지 태그에 해당함을 나타냅니다. 해당 컨테이너 이미지 태그가 0.4-21 형식의 유동 태그가 아닌 것을 확인합니다. 즉 Operator에서 사용하는 컨테이너 이미지는 여전히 고정되어 있습니다. Operator 는 Red Hat에서 사용할 수 있게 되면 새 마이크로 이미지 버전(즉, 0.4-21- n )을 자동으로 가져와서 사용하지 않습니다.

Init Container 이미지의 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 Systems의 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 Systems의 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

각 환경 변수의 값은 Red Hat에서 사용할 수 있는 Init Container 이미지를 지정합니다. 예를 들면 다음과 같습니다.

- 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:35b7d96d5065f280a528626abd2c3df84e79ccea93ab6bd8b8837af66c330f30

따라서 AMQ Broker 버전 및 컨테이너 플랫폼에 따라 Operator에서 해당 환경 변수 이름을 결정합니다. Operator는 Init Container를 시작할 때 해당 이미지 값을 사용합니다.

참고

예제에 표시된 대로 Operator는SHA( Secure Hash Algorithm ) 값으로 표시되는 이미지를 사용합니다. 숫자 기호(#) 기호로 시작하는 주석 행은 SHA 값이 특정 컨테이너 이미지 태그에 해당함을 나타냅니다. 해당 컨테이너 이미지 태그가 0.4-21 형식의 유동 태그가 아닌 것을 확인합니다. 즉 Operator에서 사용하는 컨테이너 이미지는 여전히 고정되어 있습니다. Operator 는 Red Hat에서 사용할 수 있게 되면 새 마이크로 이미지 버전(즉, 0.4-21- n )을 자동으로 가져와서 사용하지 않습니다.

추가 리소스

2.5. Operator 배포 노트

이 섹션에서는 Operator 기반 배포를 계획할 때 몇 가지 중요한 고려 사항에 대해 설명합니다.

  • AMQ Broker Operator를 동반하는 CRD(Custom Resource Definitions)를 배포하려면 OpenShift 클러스터에 대한 클러스터 관리자 권한이 필요합니다. Operator가 배포되면 관리자가 아닌 사용자는 해당 CR(사용자 정의 리소스)을 통해 브로커 인스턴스를 생성할 수 있습니다. 일반 사용자가 CR을 배포할 수 있도록 하려면 먼저 클러스터 관리자가 CRD에 역할 및 권한을 할당해야 합니다. 자세한 내용은 OpenShift Container Platform 설명서의 사용자 정의 리소스 정의에 대한 클러스터 역할 생성 을 참조하십시오.
  • 최신 Operator 버전의 CRD로 클러스터를 업데이트하면 이 업데이트는 클러스터의 모든 프로젝트에 영향을 미칩니다. 이전 버전의 Operator에서 배포한 모든 브로커 Pod는 상태를 업데이트할 수 없게 될 수 있습니다. OpenShift Container Platform 웹 콘솔에서 실행 중인 브로커 Pod의 로그 탭을 클릭하면 'UpdatePodStatus'가 실패했음을 나타내는 메시지가 표시됩니다. 그러나 해당 프로젝트의 브로커 Pod 및 Operator는 예상대로 계속 작동합니다. 영향을 받는 프로젝트의 이 문제를 해결하려면 최신 버전의 Operator를 사용하도록 해당 프로젝트도 업그레이드해야 합니다.
  • 여러 CR(사용자 정의 리소스) 인스턴스를 배포하여 지정된 OpenShift 프로젝트에서 둘 이상의 브로커 배포를 생성할 수 있지만 일반적으로 프로젝트에 단일 브로커 배포를 생성한 다음 주소에 대해 여러 CR 인스턴스를 배포합니다.

    별도의 프로젝트에서 브로커 배포를 생성하는 것이 좋습니다.

  • 영구 스토리지를 사용하여 브로커를 배포하고 OpenShift 클러스터에 컨테이너 네이티브 스토리지가 없는 경우 PV(영구 볼륨)를 수동으로 프로비저닝하고 Operator가 요청할 수 있는지 확인해야 합니다. 예를 들어, 영구 스토리지를 사용하여 두 브로커의 클러스터를 생성하려면 CR에서 persistenceEnabled=true 를 설정하여 두 개의 영구 볼륨을 사용할 수 있어야 합니다. 기본적으로 각 브로커 인스턴스에는 2GiB의 스토리지가 필요합니다.

    CR에서 persistenceEnabled=false 를 지정하면 배포된 브로커는 임시 스토리지를 사용합니다. 임시 스토리지는 브로커 Pod를 다시 시작할 때마다 기존 데이터가 손실됩니다.

    OpenShift Container Platform에서 영구 스토리지 프로비저닝에 대한 자세한 내용은 다음을 참조하십시오.

  • CR을 처음 배포하기 전에 아래 나열된 항목에 대한 구성을 기본 브로커 CR 인스턴스에 추가해야 합니다. 이러한 항목에 대한 구성을 이미 실행 중인 브로커 배포에 추가할 수 없습니다.

  • Operator가 StatefulSet에서 동적으로 업데이트할 수 없는 CR에서 매개변수를 업데이트하면 Operator는 StatefulSet을 삭제하고 업데이트된 매개변수 값으로 다시 생성합니다. StatefulSet을 삭제하면 모든 Pod가 삭제되고 다시 생성되어 일시적인 브로커 중단이 발생합니다. StatefulSet에서 Operator에서 동적으로 업데이트할 수 없는 CR 업데이트의 예는 persistenceEnabled=falsepersistenceEnabled=true 로 변경하는 경우입니다.

2.6. 기존 Operator에서 조사하는 네임스페이스 식별

클러스터에 AMQ Broker용 Operator가 이미 포함되어 있고 새 Operator에서 모든 네임스페이스 또는 여러 네임스페이스를 조사하려면 새 Operator에서 기존 Operator와 동일한 네임스페이스를 모니터링하지 않도록 해야 합니다. 다음 절차에 따라 기존 Operator에서 조사하는 네임스페이스를 식별합니다.

절차

  1. OpenShift Container Platform 웹 콘솔의 왼쪽 창에서 WorkloadsDeployments (배포) 를 클릭합니다.
  2. 프로젝트 드롭다운 목록에서 모든 프로젝트를 선택합니다.
  3. Filter Name (필터 이름) 상자에서 문자열을 지정합니다(예: amq )은 클러스터에 설치된 AMQ Broker에 대한 Operator를 표시합니다.

    참고

    namespace 열에는 각 Operator가 배포된 네임스페이스가 표시됩니다.

  4. AMQ Broker에 설치된 각 Operator가 조사 하도록 구성된 네임스페이스를 확인합니다.

    1. Operator 이름을 클릭하여 Operator 세부 정보를 표시하고 YAML 탭을 클릭합니다.
    2. WATCH_NAMESPACE 를 검색하고 Operator에서 감시하는 네임스페이스를 확인합니다.

      • WATCH_NAMESPACE 섹션에 metadata.namespace 값이 있는 fieldPath 필드가 있는 경우 Operator는 배포된 네임스페이스를 감시하고 있습니다.
      • WATCH_NAMESPACE 섹션에 네임스페이스 목록이 있는 value 필드가 있는 경우 Operator는 지정된 네임스페이스를 조사하고 있습니다. 예를 들면 다음과 같습니다.

        - name: WATCH_NAMESPACE
          value: "namespace1, namespace2"
      • WATCH_NAMESPACE 섹션에 비어 있거나 별표가 있는 필드가 있는 경우 Operator는 클러스터의 모든 네임스페이스를 감시하고 있습니다. 예를 들면 다음과 같습니다.

        - name: WATCH_NAMESPACE
          value: ""

        이 경우 새 Operator를 배포하기 전에 기존 Operator를 설치 제거하거나 특정 네임스페이스를 조사하도록 재구성해야 합니다.

다음 섹션의 절차에서는 Operator를 설치하고 CR(사용자 정의 리소스)을 사용하여 OpenShift Container Platform에서 브로커 배포를 생성하는 방법을 보여줍니다. 절차를 성공적으로 완료하면 Operator가 개별 Pod에서 실행됩니다. 생성하는 각 브로커 인스턴스는 Operator와 동일한 프로젝트에서 StatefulSet에서 개별 Pod로 실행됩니다. 나중에 전용 주소 지정 CR을 사용하여 브로커 배포에서 주소를 정의하는 방법을 확인할 수 있습니다.

3장. AMQ Broker Operator를 사용하여 OpenShift Container Platform에 AMQ Broker 배포

3.1. 사전 요구 사항

  • Operator를 설치하고 이를 사용하여 브로커 배포를 생성하기 전에 2.5절. “Operator 배포 노트” 에서 Operator 배포 노트를 참조해야 합니다.

3.2. CLI를 사용하여 Operator 설치

참고

각 Operator 릴리스에서는 아래에 설명된 대로 최신 AMQ Broker 7.10.6 Operator 설치 및 예제 파일을 다운로드해야 합니다.

이 섹션의 절차에서는 OpenShift CLI(명령줄 인터페이스)를 사용하여 지정된 OpenShift 프로젝트에서 AMQ Broker 7.10용 최신 버전의 Operator를 설치하고 배포하는 방법을 보여줍니다. 후속 절차에서는 이 Operator를 사용하여 일부 브로커 인스턴스를 배포합니다.

3.2.1. Operator 배포 준비

CLI를 사용하여 Operator를 배포하기 전에 Operator 설치 파일을 다운로드하고 배포를 준비해야 합니다.

절차

  1. 웹 브라우저에서 AMQ Broker 7.10.6 릴리스소프트웨어 다운로드 페이지로 이동합니다.
  2. 버전 드롭다운 목록의 값이 7.10.6 으로 설정되고 릴리스 탭이 선택되어 있는지 확인합니다.
  3. AMQ Broker 7.10.6 Operator 설치 및 예제 파일 옆에 있는 Download 를 클릭합니다.

    amq-broker-operator-7.10.6-ocp-install-examples.zip 압축 아카이브가 자동으로 시작됩니다.

  4. 아카이브를 선택한 디렉터리로 이동합니다. 다음 예제에서는 아카이브를 ~/broker/operator 라는 디렉터리로 이동합니다.

    $ mkdir ~/broker/operator
    $ mv amq-broker-operator-7.10.6-ocp-install-examples.zip ~/broker/operator
  5. 선택한 디렉터리에서 아카이브의 콘텐츠를 추출합니다. 예를 들면 다음과 같습니다.

    $ cd ~/broker/operator
    $ unzip amq-broker-operator-7.10.6-ocp-install-examples.zip
  6. 아카이브를 추출했을 때 생성된 디렉터리로 전환합니다. 예를 들면 다음과 같습니다.

    $ cd amq-broker-operator-7.10.6-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 아카이브의 배포 디렉터리에서 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 아카이브의 배포 디렉터리에서 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 아카이브의 배포 디렉터리에서 cluster_role_binding.yaml 파일을 엽니다.
    5. 주체 섹션에서 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의 최신 버전을 배포하는 방법을 보여줍니다.

사전 요구 사항

  • Operator 배포를 위해 OpenShift 프로젝트를 이미 준비해야 합니다. 3.2.1절. “Operator 배포 준비”을 참조하십시오.
  • AMQ Broker 7.3부터 새 버전의 Red Hat Ecosystem Catalog를 사용하여 컨테이너 이미지에 액세스합니다. 이 새 버전의 레지스트리는 인증된 사용자가 되어 이미지에 액세스할 수 있어야 합니다. 이 섹션의 절차를 수행하기 전에 먼저 Red Hat Container Registry Authentication 에 설명된 단계를 완료해야 합니다.
  • 영구 스토리지를 사용하여 브로커를 배포하고 OpenShift 클러스터에 컨테이너 네이티브 스토리지가 없는 경우 PV(영구 볼륨)를 수동으로 프로비저닝하고 Operator가 요청할 수 있는지 확인해야 합니다. 예를 들어, 영구 스토리지를 사용하여 두 브로커의 클러스터를 생성하려면 사용자 정의 리소스에서 persistenceEnabled=true 를 설정하여 두 개의 PV를 사용할 수 있어야 합니다. 기본적으로 각 브로커 인스턴스에는 2GiB의 스토리지가 필요합니다.

    사용자 정의 리소스에서 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.6-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. 스케일다운 컨트롤러 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의 인증에 사용되는 계정과 연결된 풀 시크릿을 OpenShift 프로젝트의 기본,배포자빌더 서비스 계정과 연결합니다.

    $ 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 아카이브의 배포 디렉터리에서 operator.yaml 파일을 엽니다. 다음과 같이 spec.containers.image 속성 값이 Operator의 버전 7.10.6-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:5175979c4b57586009cbcbffdcb90ef81c7a9f6520451f733cabd3e8b50c1eb2
    참고

    operator.yaml 파일에서 Operator는SHA( Secure Hash Algorithm ) 값으로 표시되는 이미지를 사용합니다. 숫자 기호(#) 기호로 시작하는 주석 행은 SHA 값이 특정 컨테이너 이미지 태그에 해당함을 나타냅니다.

  7. Operator를 배포합니다.

    $ oc create -f deploy/operator.yaml

    OpenShift 프로젝트에서 Operator는 새 포드에서 시작됩니다.

    OpenShift Container Platform 웹 콘솔에서 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와 통신하고, 브로커 및 주소 지정에 대한 컨트롤러가 실행 중이며 이러한 컨트롤러에서 일부 작업자를 시작했는지 확인합니다.

참고

지정된 OpenShift 프로젝트에서 AMQ Broker Operator의 단일 인스턴스 만 배포하는 것이 좋습니다. Operator 배포의 spec.replicas 속성을 1 보다 큰 값으로 설정하거나 동일한 프로젝트에서 두 번 이상 Operator를 배포하는 것은 권장되지 않습니다.

추가 리소스

3.3. OperatorHub를 사용하여 Operator 설치

3.3.1. Operator Lifecycle Manager 개요

OpenShift Container Platform 4.5 이상에서 OLM( Operator Lifecycle Manager )은 사용자가 클러스터에서 실행되는 모든 Operator 및 관련 서비스의 라이프사이클을 설치, 업데이트 및 관리하는 데 도움이 됩니다. Operator 프레임워크의 일부입니다. Kubernetes 네이티브 애플리케이션(Operator)을 효율적이고 자동화되고 확장 가능한 방식으로 관리하도록 설계된 오픈 소스 툴킷입니다.

OLM은 OpenShift Container Platform 4.5 이상에서 기본적으로 실행되므로 클러스터 관리자는 클러스터에서 실행되는 Operator를 설치, 업그레이드 및 액세스할 수 있습니다. OpenShift Container Platform 웹 콘솔은 클러스터 관리자가 Operator를 설치할 수 있는 관리 화면을 제공하고, 클러스터에 제공되는 Operator 카탈로그를 사용할 수 있는 액세스 권한을 특정 프로젝트에 부여합니다.

OperatorHub 는 OpenShift 클러스터 관리자가 OLM을 사용하여 Operator를 검색, 설치 및 업그레이드하는 데 사용하는 그래픽 인터페이스입니다. 한 번의 클릭으로 이러한 Operator를 OperatorHub에서 가져오고 클러스터에 설치하고 OLM에서 관리하며 엔지니어링 팀이 개발, 테스트 및 프로덕션 환경에서 소프트웨어를 셀프서비스로 관리할 수 있습니다.

Operator를 배포한 경우 사용자 정의 리소스(CR) 인스턴스를 사용하여 독립 실행형 및 클러스터 브로커와 같은 브로커 배포를 생성할 수 있습니다.

3.3.2. OperatorHub에서 Operator 배포

다음 절차에서는 OperatorHub를 사용하여 AMQ Broker에 대한 최신 버전의 Operator를 지정된 OpenShift 프로젝트에 배포하는 방법을 설명합니다.

참고

OperatorHub에서는 각 채널에 제공되는 최신 Operator 버전만 설치할 수 있습니다. 이전 버전의 Operator를 설치하려면 CLI를 사용하여 Operator를 설치해야 합니다. 자세한 내용은 3.2절. “CLI를 사용하여 Operator 설치”의 내용을 참조하십시오.

사전 요구 사항

  • OperatorHub에서 Red Hat Integration - AMQ Broker for RHEL 8(Multiarch) Operator를 사용할 수 있어야 합니다.
  • 클러스터 관리자 권한이 있어야 합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 왼쪽 탐색 메뉴에서 OperatorsOperatorHub 를 클릭합니다.
  3. OperatorHub 페이지 상단에 있는 프로젝트 드롭다운 메뉴에서 Operator를 배포할 프로젝트를 선택합니다.
  4. OperatorHub 페이지에서 Filter by keyword…​ 상자를 사용하여 Red Hat Integration - AMQ Broker for RHEL 8(Multiarch) Operator를 찾습니다.

    참고

    OperatorHub에서는 해당 이름에 AMQ Broker 를 포함하는 것보다 두 개 이상의 Operator를 찾을 수 있습니다. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator를 클릭합니다. 이 Operator를 클릭하면 열리는 정보 창을 확인합니다. AMQ Broker 7.10의 경우 이 Operator의 최신 마이너 버전 태그는 7.10.6-opr-1 입니다.

  5. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator를 클릭합니다. 표시되는 대화 상자에서 설치를 클릭합니다.
  6. Operator 설치 페이지에서 다음을 수행합니다.

    1. Update Channel 에서 7.10.x 채널을 선택하여 버전 7.10에 대한 업데이트만 수신합니다. 7.10.x 채널은 현재LTS(Long Term Support) 채널입니다.

      참고

      다음 채널도 표시됩니다.

      • 7.x - 현재 이 채널은 버전 7.9에 대한 업데이트만 제공합니다.
      • 7.8.x - 이 채널은 버전 7.8에만 대한 업데이트를 제공하며 이전 LTS(Long Term Support) 채널이었습니다.
      • OpenShift Container Platform 클러스터가 설치된 시기에 따라 이전 AMQ Broker 버전에 해당하는 Alpha,current, current-76 과 같은 채널도 표시될 수 있으며 이 채널은 무시해도 됩니다.
    2. 설치 모드에서 Operator가 감시하는 네임스페이스를 선택합니다.

      • 클러스터의 특정 네임스페이스 - Operator가 해당 네임스페이스에 설치되고 CR 변경 사항만 모니터링합니다.
      • 모든 네임스페이스 - Operator는 모든 네임스페이스를 모니터링하여 CR 변경 사항을 모니터링합니다.
      참고

      이전 버전의 Operator를 사용하여 브로커를 이전에 배포하고 Operator를 배포하여 많은 네임스페이스를 조사 하려면 업그레이드하기 전에 참조하십시오.

  7. 설치된 네임스페이스 드롭다운 메뉴에서 Operator를 설치할 프로젝트를 선택합니다.
  8. 승인 전략에서 자동으로 권한이 있는 라디오 버튼이 선택되어 있는지 확인합니다. 이 옵션은 설치를 위해 Operator에 대한 업데이트를 수동으로 승인할 필요가 없도록 지정합니다.
  9. 설치를 클릭합니다.

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. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 배포를 생성하는 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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-ss 이름을 사용합니다. 또한 배포의 브로커 Pod는 StatefulSet 이름 (예: ex-aao-ss-0,ex-aao-sss-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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.
  4. OpenShift Container Platform 웹 콘솔에서 WorkloadsStatefulSets 를 클릭합니다. ex-aao-ss 라는 새로운 StatefulSet이 표시됩니다.

    1. ex-aao-ss StatefulSet을 클릭합니다. CR에 정의된 단일 브로커에 해당하는 하나의 Pod가 있음을 확인할 수 있습니다.
    2. StatefulSet에서 Pod 탭을 클릭합니다. ex-aao-ss Pod를 클릭합니다. 실행 중인 Pod의 이벤트 탭에서 브로커 컨테이너가 시작된 것을 확인할 수 있습니다. Logs (로그) 탭에 브로커 자체가 실행 중임을 보여줍니다.
  5. 브로커가 정상적으로 실행되고 있는지 테스트하려면 브로커 Pod의 쉘에 액세스하여 일부 테스트 메시지를 보냅니다.

    1. OpenShift Container Platform 웹 콘솔 사용:

      1. 워크로드포드 를 클릭합니다.
      2. ex-aao-ss Pod를 클릭합니다.
      3. 터미널 탭을 클릭합니다.
    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 쉘에 액세스합니다.

        $ oc rsh ex-aao-ss-0
  6. 쉘에서 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 웹 콘솔을 사용하여 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 웹 콘솔에서 CR에 지정된 수에 따라 추가 브로커 Pod가 프로젝트에서 시작됩니다. 기본적으로 프로젝트에서 실행되는 브로커는 클러스터됩니다.

  7. 각 Pod의 로그 탭을 엽니다. 로그에 OpenShift가 각 브로커에 클러스터 연결 브리지를 설정했음을 보여줍니다. 특히 로그 출력에는 다음과 같은 행이 포함됩니다.

    targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@6f13fb88

3.4.3. 실행 중인 브로커 배포에 사용자 정의 리소스 변경 적용

다음은 브로커 배포 실행에 CR(사용자 정의 리소스) 변경 사항을 적용하는 방법에 유의해야 할 몇 가지 중요한 사항입니다.

  • CR의 persistenceEnabled 속성을 동적으로 업데이트할 수 없습니다. 이 특성을 변경하려면 클러스터를 0 브로커로 축소합니다. 기존 CR을 삭제합니다. 그런 다음 변경 사항으로 CR을 다시 생성하고 재배포하여 배포 크기를 지정합니다.
  • CR의 deploymentPlan.size 속성 값은 oc scale 명령을 통해 브로커 배포 크기에 대한 변경 사항을 덮어씁니다. 예를 들어 oc scale 을 사용하여 배포 크기를 3개의 브로커에서 2개로 변경하지만 CR의 deploymentPlan.size 값은 여전히 3 입니다. 이 경우 OpenShift는 처음에 배포를 두 개의 브로커로 축소합니다. 그러나 scaledown 작업이 완료되면 Operator는 CR에 지정된 대로 배포를 세 개의 브로커로 복원합니다.
  • 3.2.2절. “CLI를 사용하여 Operator 배포” 에 설명된 대로, CR에서 persistenceEnabled=true를 설정하여 영구 스토리지를 사용하여 브로커 배포를 생성하는 경우 (즉, CR에서 persistenceEnabled=true )를 설정하여 브로커 Pod에 요청하는 AMQ Broker Operator에 대한 PV(영구 볼륨)를 프로비저닝해야 할 수 있습니다. 브로커 배포 크기를 축소하면 Operator는 현재 종료된 브로커 Pod에 대해 이전에 요청한 모든 PV를 해제합니다. 그러나 CR을 삭제하여 브로커 배포를 제거하면 AMQ Broker Operator 는 이를 제거할 때 배포에 계속 있는 브로커 포드에 대한 PVC(영구 볼륨 클레임)를 해제하지 않습니다. 또한 릴리스되지 않은 PV는 새 배포에서 사용할 수 없습니다. 이 경우 볼륨을 수동으로 릴리스해야 합니다. 자세한 내용은 OpenShift 문서의 영구 볼륨 릴리스 를 참조하십시오.
  • AMQ Broker 7.10에서 다음 항목을 구성하려면 CR을 처음 배포하기 전에 기본 CR 인스턴스에 적절한 구성을 추가해야 합니다.

  • 활성 확장 이벤트 중에 적용하는 추가 변경 사항은 Operator에 의해 큐에 추가되고 스케일링이 완료된 경우에만 실행됩니다. 예를 들어 배포 크기를 4개 브로커에서 1개로 축소한다고 가정합니다. 그러면 스케일다운이 진행되는 동안 브로커 관리자의 사용자 이름과 암호 값도 변경합니다. 이 경우 Operator는 배포가 하나의 활성 브로커로 실행될 때까지 사용자 이름과 암호를 대기열에 넣습니다.
  • 배포 크기를 변경하거나 어셉터, 커넥터 또는 콘솔에 대한 expose 특성 값을 변경하는 것 외에 모든 CR이 변경되어 기존 브로커가 다시 시작됩니다. 배포에 여러 개의 브로커가 있는 경우 한 번에 하나의 브로커만 다시 시작됩니다.

4장. Operator 기반 브로커 배포 구성

4.1. Operator에서 브로커 구성을 생성하는 방법

CR(사용자 정의 리소스) 인스턴스를 사용하여 브로커 배포를 구성하기 전에 Operator에서 브로커 구성을 생성하는 방법을 이해해야 합니다.

Operator 기반 브로커 배포를 생성할 때 각 브로커의 Pod는 OpenShift 프로젝트의 StatefulSet에서 실행됩니다. 브로커의 애플리케이션 컨테이너는 각 Pod 내에서 실행됩니다.

Operator는 각 Pod를 초기화할 때 Init Container 라는 컨테이너 유형을 실행합니다. OpenShift Container Platform에서 Init Container는 애플리케이션 컨테이너보다 먼저 실행되는 특수 컨테이너입니다. Init Containers에는 애플리케이션 이미지에 없는 유틸리티 또는 설정 스크립트가 포함될 수 있습니다.

기본적으로 AMQ Broker Operator는 기본 제공 Init Container를 사용합니다. Init Container는 배포에 기본 CR 인스턴스를 사용하여 각 브로커 애플리케이션 컨테이너에서 사용하는 구성을 생성합니다.

CR에 지정된 주소 설정이 있는 경우 Operator는 기본 구성을 생성한 다음 해당 구성을 CR에 지정된 구성과 병합하거나 교체합니다. 이 프로세스는 다음 섹션에 설명되어 있습니다.

4.1.1. Operator에서 주소 설정 구성을 생성하는 방법

배포에 사용되는 기본 CR(사용자 정의 리소스) 인스턴스에 주소 설정 구성을 포함하는 경우 Operator는 아래에 설명된 대로 각 브로커의 주소 설정 구성을 생성합니다.

  1. Operator는 브로커 애플리케이션 컨테이너보다 먼저 Init Container를 실행합니다. Init Container는 기본 주소 설정 구성을 생성합니다. 기본 주소 설정 구성은 다음과 같습니다.

    <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 Container는 해당 구성을 처리하고 XML로 변환합니다.
  3. CR의 applyRule 속성 값에 따라 Init Container는 위에 표시된 기본 주소 설정 구성을 CR에 지정한 구성으로 병합 하거나 대체합니다. 이 병합 또는 교체의 결과는 브로커가 사용할 최종 주소 설정 구성입니다.
  4. Init Container가 브로커 구성 생성(address 설정 포함)을 완료하면 브로커 애플리케이션 컨테이너가 시작됩니다. 브로커를 시작하면 브로커 컨테이너는 이전에 Init Container에서 사용한 설치 디렉터리에서 해당 구성을 복사합니다. broker.xml 구성 파일에서 주소 설정 구성을 검사할 수 있습니다. 실행 중인 브로커의 경우 이 파일은 /home/jboss/amq-broker/etc 디렉터리에 있습니다.

추가 리소스

4.1.2. 브로커 Pod의 디렉터리 구조

Operator 기반 브로커 배포를 생성할 때 각 브로커의 Pod는 OpenShift 프로젝트의 StatefulSet에서 실행됩니다. 브로커의 애플리케이션 컨테이너는 각 Pod 내에서 실행됩니다.

Operator는 각 Pod를 초기화할 때 Init Container 라는 컨테이너 유형을 실행합니다. OpenShift Container Platform에서 Init Container는 애플리케이션 컨테이너보다 먼저 실행되는 특수 컨테이너입니다. Init Containers에는 애플리케이션 이미지에 없는 유틸리티 또는 설정 스크립트가 포함될 수 있습니다.

브로커 인스턴스에 대한 구성을 생성할 때 Init Container는 기본 설치 디렉터리에 포함된 파일을 사용합니다. 이 설치 디렉터리는 Operator가 브로커 Pod 및 Init Container 및 브로커 컨테이너 공유에 마운트하는 볼륨에 있습니다. Init Container에서 공유 볼륨을 마운트하는 데 사용하는 경로는 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

브로커를 실행하는 데 필요한 ScanSetting 및 라이브러리.

<install_dir>/log

브로커 로그 파일.

<install_dir>/tmp

임시 웹 애플리케이션 파일.

Init Container가 브로커 구성 생성을 완료하면 브로커 애플리케이션 컨테이너가 시작됩니다. 브로커를 시작하면 브로커 컨테이너는 이전에 Init Container에서 사용한 설치 디렉터리에서 해당 구성을 복사합니다. 브로커 포드가 초기화되어 실행되면 브로커 구성은 브로커의 /home/jboss/amq-broker 디렉터리(및 하위 디렉터리)에 있습니다.

추가 리소스

4.2. Operator 기반 브로커 배포를 위한 주소 및 큐 구성

Operator 기반 브로커 배포의 경우 두 개의 별도의 CR(사용자 정의 리소스) 인스턴스를 사용하여 주소 및 대기열 및 관련 설정을 구성합니다.

  • 브로커에서 주소 및 큐를 생성하려면 주소 CRD(Custom Resource Definition)를 기반으로 CR 인스턴스를 배포합니다.

    • OpenShift CLI(명령줄 인터페이스)를 사용하여 Operator를 설치하는 경우 CRD는 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crds 에 포함된 broker_activemqartemisaddress_crd.yaml 파일입니다.
    • OperatorHub를 사용하여 Operator를 설치하는 경우 CRD는 OpenShift Container Platform 웹 콘솔의 AdministrationCustom Resource Definitions 에 나열된 ActiveMQAretmisAddress CRD입니다.
  • 그런 다음 특정 주소와 일치하는 주소 및 큐 설정을 구성하려면 브로커 배포를 생성하는 데 사용되는 기본 CR(사용자 정의 리소스) 인스턴스에 구성을 포함합니다.

    • OpenShift CLI를 사용하여 Operator를 설치하는 경우 주요 브로커 CRD는 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crds 에 포함된 broker_activemqartemis_crd.yaml 파일입니다.
    • OperatorHub를 사용하여 Operator를 설치하는 경우 기본 브로커 CRD는 OpenShift Container Platform 웹 콘솔의 AdministrationCustom Resource Definitions 에 나열된 ActiveMQAretmis CRD입니다.

    일반적으로 OpenShift Container Platform의 브로커 배포에 대해 구성할 수 있는 주소 및 큐 설정은 Linux 또는 Windows의 독립 실행형 브로커 배포 와 완전히 동일합니다. 그러나 이러한 설정이 구성된 방법 의 몇 가지 차이점이 있습니다. 이러한 차이점은 다음 섹션에서 설명합니다.

4.2.1. OpenShift와 독립 실행형 브로커 배포 간의 주소 및 대기열 설정 구성의 차이점

  • OpenShift Container Platform에서 브로커 배포에 대한 주소 및 큐 설정을 구성하려면 브로커 배포의 기본 CR(사용자 정의 리소스) 인스턴스의 address >-< 섹션에 구성을 추가합니다. 이는 Linux 또는 Windows의 독립 실행형 배포와 대조되며, broker.xml 구성 파일의 address-settings 요소에 구성을 추가합니다.
  • 구성 항목 이름에 사용되는 형식은 OpenShift Container Platform 및 독립 실행형 브로커 배포마다 다릅니다. OpenShift Container Platform 배포의 경우 구성 항목 이름은 camel 케이스에 있습니다(예: 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. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemisaddress_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 주소 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemisAddresss CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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
        ...

    앞의 구성은 myQueue0 이라는 큐와 anycast 라우팅 유형을 사용하여 myAddress0 이라는 주소를 정의합니다.

    참고

    metadata 섹션에서 namespace 속성을 포함하고 OpenShift Container Platform 웹 콘솔을 사용하여 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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.
  4. (선택 사항) CR 인스턴스를 사용하여 배포에 이전에 추가된 주소 및 큐를 삭제하려면 다음 명령을 사용합니다.

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

4.2.3. Operator 기반 브로커 배포에서 구성된 주소와 일치하는 주소 설정

클라이언트에 메시지 전달이 실패하면 브로커가 메시지를 지속적으로 전달하려고 시도하지 않을 수 있습니다. 무한한 전달 시도를 방지하기 위해, dead letter 주소와 연관된 dead letter queue 를 정의할 수 있습니다. 지정된 수의 전송 시도 후 브로커는 원래 큐에서 전달되지 않은 메시지를 제거하고 구성된 dead letter 주소로 메시지를 보냅니다. 나중에 시스템 관리자는 배달 못 한 편지 대기열에서 전달되지 않은 메시지를 사용하여 메시지를 검사할 수 있습니다.

다음 예제에서는 Operator 기반 브로커 배포에 대해 배달 못 한 주소 및 대기열을 구성하는 방법을 보여줍니다. 예제에서는 다음을 수행하는 방법을 보여줍니다.

  • 기본 브로커 CR(사용자 정의 리소스) 인스턴스의 addressSetting 섹션을 사용하여 주소 설정을 구성합니다.
  • 브로커 배포의 주소에 해당 주소 설정과 일치합니다.

사전 요구 사항

절차

  1. 배포의 각 브로커에 대해 전달되지 않은 메시지를 수신하도록 배달 못 한 주소 및 큐를 추가하도록 CR 인스턴스 구성을 시작합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. 브로커 배포의 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemisaddress_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 주소 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemisAddresss CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      5. Create ActiveMQArtemisAddress 를 클릭합니다.

        콘솔에서 YAML 편집기가 열리고 CR 인스턴스를 구성할 수 있습니다.

  2. CR의 spec 섹션에서 dead letter address 및 큐를 지정하여 전달되지 않은 메시지를 수신할 행을 추가합니다. 예를 들면 다음과 같습니다.

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

    앞의 구성은 myDeadLetterQueue 라는 dead letter 큐와 anycast 라우팅 유형을 사용하여 myDeadLetterAddress 라는 dead letter 주소를 정의합니다.

    참고

    metadata 섹션에서 namespace 속성을 포함하고 OpenShift Container Platform 웹 콘솔을 사용하여 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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.
  4. 브로커 배포용 CR(사용자 정의 리소스) 인스턴스 구성을 시작합니다.

    1. 샘플 CR 파일에서 다음을 수행합니다.

      1. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      2. ActiveMQArtemis CRD를 클릭합니다.
      3. Instances 탭을 클릭합니다.
      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 웹 콘솔을 사용하여 CR 인스턴스를 생성하는 경우에만 값을 지정해야 합니다. 지정해야 하는 값은 브로커 배포를 위한 OpenShift 프로젝트의 이름입니다.

  5. CR의 deploymentPlan 섹션에서 다음과 같이 단일 addressSetting 섹션이 포함된 새 주소 10.0.0.1 섹션을 추가합니다.

    spec:
      deploymentPlan:
        size: 1
        image: placeholder
        requireLogin: false
        persistenceEnabled: true
        journalType: nio
        messageMigration: true
      addressSettings:
        addressSetting:
  6. match 속성의 단일 인스턴스를 addressSetting 블록에 추가합니다. address-matching 표현식을 지정합니다. 예를 들면 다음과 같습니다.

    spec:
      deploymentPlan:
        size: 1
        image: placeholder
        requireLogin: false
        persistenceEnabled: true
        journalType: nio
        messageMigration: true
      addressSettings:
        addressSetting:
        -  match: myAddress
    match
    브로커가 다음 구성을 적용하는 주소 또는 주소 집합을 지정합니다. 이 예에서 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

    구성된 배달 주소로 메시지를 이동하기 전에 브로커가 수행하는 최대 전달 시도 횟수입니다.

    위 예에서 브로커가 5번의 실패한 시도를 하는 경우 myAddress 로 시작하는 주소로 메시지를 전달하려고 하면 브로커는 메시지를 지정된 dead letter 주소 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 속성 값에는 별표 와일드카드 문자가 포함됩니다. 와일드카드 문자는 이전 구성이 myECDHEAddresses 문자열로 시작하는 모든 주소에 적용됨을 나타냅니다.

    참고

    와일드카드 표현식을 match 속성의 값으로 사용하는 경우 해당 값을 작은 따옴표로 묶어야 합니다(예: 'myECDHEAddresses*' ).

  9. address>-&lt; 섹션의 시작 부분에 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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.

추가 리소스

  • 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의 Init Container에 대한 자세한 내용은 OpenShift Container Platform 설명서에 Pod를 배포하기 전에 Init Container를 사용하여 작업을 수행합니다.

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. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemissecurity_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 주소 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemisSecurity CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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"
                  ...
    참고

    항상 이전 예제의 요소 값을 지정합니다. 예를 들어 securityDomains.brokerDomain 또는 역할의 값을 지정하지 않으면 결과 구성으로 인해 예기치 않은 결과가 발생할 수 있습니다.

    앞의 구성은 두 사용자를 정의합니다.

    • sender 라는 역할로 sam 이라는 사용자를 정의하는 propertiesLoginModule 이라는 prop-module.
    • receiver 라는 역할이 있는 developer라는 사용자를 정의하는 prop- module 이라는 propertiesLoginModule 입니다.

    이러한 역할의 속성은 securityDomains 섹션의 broker Domain 및 broker 섹션에 정의되어 있습니다. 예를 들어 send 역할은 해당 역할을 가진 사용자가 모든 주소에 있는 영구 대기열을 생성할 수 있도록 정의되었습니다. 기본적으로 구성은 현재 네임스페이스의 CR에 정의된 모든 배포된 브로커에 적용됩니다. 특정 브로커 배포로 구성을 제한하려면 8.1.3절. “보안 사용자 정의 리소스 구성 참조” 에 설명된 applyToCrNames 옵션을 사용합니다.

    참고

    metadata 섹션에서 namespace 속성을 포함하고 OpenShift Container Platform 웹 콘솔을 사용하여 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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.

4.3.2. 시크릿에 사용자 암호 저장

Operator 기반 브로커 배포 절차에 대한 보안 구성 생성 절차에서 사용자 암호는 ActiveMQArtemisSecurity CR에 일반 텍스트로 저장됩니다. CR에 암호를 일반 텍스트로 저장하지 않으려면 CR에서 암호를 제외하여 시크릿에 저장할 수 있습니다. CR을 적용하면 Operator는 시크릿에서 각 사용자의 암호를 검색하여 브로커 Pod의 artemis-users.properties 파일에 삽입합니다.

절차

  1. oc create secret 명령을 사용하여 보안을 생성하고 각 사용자의 이름과 암호를 추가합니다. 보안 이름은 security-properties-모듈 이름 지정 규칙을 따라야 합니다. 여기서 모듈 이름은 CR에 구성된 로그인 모듈의 이름입니다. 예를 들면 다음과 같습니다.

    oc create secret generic security-properties-prop-module \
      --from-literal=sam=samspassword \
      --from-literal=rob=robspassword
  2. CR의 spec 섹션에서 역할 정보와 함께 시크릿에 지정한 사용자 이름을 추가하지만 각 사용자의 암호는 포함하지 않습니다. 예를 들면 다음과 같습니다.

    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 웹 콘솔 사용:

      1. CR 구성을 완료하면 생성을 클릭합니다.

추가 리소스

OpenShift Container Platform의 보안에 대한 자세한 내용은 OpenShift Container Platform 설명서의 Pod에 중요한 데이터 제공을 참조하십시오.

4.4. 브로커 스토리지 요구 사항 구성

Operator 기반 브로커 배포에서 영구 스토리지를 사용하려면 배포를 생성하는 데 사용되는 CR(사용자 정의 리소스) 인스턴스에서 persistenceEnabledtrue 로 설정합니다. OpenShift 클러스터에 컨테이너 네이티브 스토리지가 없는 경우 PV(영구 볼륨)를 수동으로 프로비저닝하고 PVC(영구 볼륨 클레임)를 사용하여 Operator에서 이러한 볼륨을 클레임할 수 있는지 확인해야 합니다. 예를 들어 영구 스토리지를 사용하여 두 개의 브로커로 구성된 클러스터를 생성하려면 두 개의 PV를 사용할 수 있어야 합니다.

중요

OpenShift Container Platform에서 PV를 수동으로 프로비저닝하는 경우 각 PV의 회수 정책을 Retain 으로 설정해야 합니다. PV의 회수 정책이 Retain 으로 설정되지 않고 Operator에서 PV를 요청하는 데 사용한 PVC도 삭제됩니다. PV를 삭제하면 볼륨의 데이터가 손실됩니다. 자세한 내용은 회수 정책 설정에 대한 자세한 내용은 OpenShift Container Platform 설명서의 영구 스토리지 이해 를 참조하십시오.

기본적으로 PVC는 클러스터에 대해 구성된 기본 스토리지 클래스에서 각 브로커의 2GiB 스토리지를 가져옵니다. PVC에서 요청된 기본 크기 및 스토리지 클래스를 재정의할 수 있지만 CR을 처음 배포하기 전에 CR에서 새 값을 구성하는 경우에만 해당합니다.

4.4.1. 브로커 스토리지 크기 및 스토리지 클래스 구성

다음 절차에서는 브로커 배포에 사용할 CR(사용자 정의 리소스) 인스턴스를 구성하여 영구 메시지 스토리지를 위해 각 브로커에 필요한 PVC(영구 볼륨 클레임)의 크기 및 스토리지 클래스를 지정하는 방법을 설명합니다.

중요

CR을 처음 배포하기 전에 브로커 스토리지 크기 및 스토리지 클래스에 대한 구성을 브로커 배포의 기본 CR에 추가해야 합니다. 이미 실행 중인 브로커 배포에 구성을 추가할 수 없습니다.

사전 요구 사항

  • CR 인스턴스를 사용하여 기본 브로커 배포를 생성하는 방법에 대해 잘 알고 있어야 합니다. 3.4.1절. “기본 브로커 인스턴스 배포”을 참조하십시오.
  • 이미 PV(영구 볼륨)를 프로비저닝하고 Operator에서 클레임할 수 있도록 해야 합니다. 예를 들어 영구 스토리지를 사용하여 두 브로커의 클러스터를 생성하려면 두 PV를 사용할 수 있어야 합니다.

    영구 스토리지 프로비저닝에 대한 자세한 내용은 OpenShift Container Platform 설명서의 영구 스토리지 이해 를 참조하십시오.

절차

  1. 브로커 배포용 CR(사용자 정의 리소스) 인스턴스 구성을 시작합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. 배포를 생성하는 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 배포를 생성하는 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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(영구 볼륨 클레임)의 크기(바이트)입니다. 이 속성은 persistenceEnabledtrue 로 설정된 경우에만 적용됩니다. 지정한 값은 바이트 표기법(예: K, M, G) 또는 바이너리 동등한 단위(Ki, Mi, Gi)를 사용하는 단위를 포함해야 합니다.
  3. 각 브로커 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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.

4.5. Operator 기반 브로커 배포에 대한 리소스 제한 및 요청 구성

Operator 기반 브로커 배포를 생성할 때 배포의 브로커 Pod는 OpenShift 클러스터의 노드의 StatefulSet에서 실행됩니다. 배포에 대한 CR(사용자 정의 리소스) 인스턴스를 구성하여 각 Pod에서 실행하는 브로커 컨테이너에서 사용하는 host-node 컴퓨팅 리소스를 지정할 수 있습니다. CPU 및 메모리(RAM)에 대한 제한 및 요청 값을 지정하면 브로커 Pod의 정상적인 성능을 보장할 수 있습니다.

중요
  • CR을 처음 배포하기 전에 브로커 배포의 CR 인스턴스에 제한 및 요청에 대한 구성을 추가해야 합니다. 이미 실행 중인 브로커 배포에 구성을 추가할 수 없습니다.
  • 특정 메시징 시스템 사용 사례와 구현한 결과 아키텍처를 기반으로 하므로 Red Hat은 제한 및 요청 값을 권장할 수 없습니다. 그러나 프로덕션 환경에 맞게 구성하기 전에 개발 환경에서 이러한 값을 테스트하고 조정하는 것이 좋습니다.
  • Operator는 각 브로커 포드를 초기화할 때 Init Container 라는 컨테이너 유형을 실행합니다. 각 브로커 컨테이너에 대해 구성하는 리소스 제한 및 요청도 각 Init 컨테이너에 적용됩니다. 브로커 배포에서 Init Container 사용에 대한 자세한 내용은 4.1절. “Operator에서 브로커 구성을 생성하는 방법” 을 참조하십시오.

다음 제한 및 요청 값을 지정할 수 있습니다.

CPU 제한
Pod에서 실행 중인 각 브로커 컨테이너에 대해 이 값은 컨테이너에서 사용할 수 있는 최대 host-node CPU 양입니다. 브로커 컨테이너가 지정된 CPU 제한을 초과하려고 하면 OpenShift에서 컨테이너를 제한합니다. 이렇게 하면 노드에서 실행되는 Pod 수에 관계없이 컨테이너가 일관된 성능을 유지할 수 있습니다.
메모리 제한
Pod에서 실행 중인 각 브로커 컨테이너의 경우 이 값은 컨테이너에서 사용할 수 있는 최대 host-node 메모리 양입니다. 브로커 컨테이너가 지정된 메모리 제한을 초과하려고 하면 OpenShift에서 컨테이너를 종료합니다. 브로커 Pod가 다시 시작됩니다.
CPU 요청

Pod에서 실행 중인 각 브로커 컨테이너의 경우 이 값은 컨테이너에서 요청하는 host-node CPU의 양입니다. OpenShift 스케줄러는 포드 배치 중 CPU 요청 값을 고려하여 브로커 Pod를 충분한 컴퓨팅 리소스가 있는 노드에 바인딩하는 것으로 간주합니다.

CPU 요청 값은 브로커 컨테이너를 실행하는 데 필요한 최소 CPU 양입니다. 그러나 노드에 CPU에 대한 경합이 없는 경우 컨테이너는 사용 가능한 모든 CPU를 사용할 수 있습니다. CPU 제한을 지정한 경우 컨테이너는 해당 CPU 사용량을 초과할 수 없습니다. 노드에 CPU 경합이 있는 경우 CPU 요청 값은 OpenShift가 모든 컨테이너에서 CPU 사용량을 줄이는 방법을 제공합니다.

메모리 요청

Pod에서 실행되는 각 브로커 컨테이너의 경우 이 값은 컨테이너에서 요청하는 host-node 메모리의 양입니다. OpenShift 스케줄러는 포드 배치 중 메모리 요청 값을 고려하여 브로커 Pod를 충분한 컴퓨팅 리소스가 있는 노드에 바인딩하는 것으로 간주합니다.

memory 요청 값은 브로커 컨테이너를 실행하는 데 필요한 최소 메모리 양입니다. 그러나 컨테이너는 사용 가능한 메모리를 최대한 많이 사용할 수 있습니다. 메모리 제한을 지정한 경우 브로커 컨테이너는 메모리 사용량을 초과할 수 없습니다.

CPU는 밀리코어라는 단위로 측정됩니다. OpenShift 클러스터의 각 노드는 운영 체제를 검사하여 노드의 CPU 코어 수를 결정합니다. 그런 다음 노드는 해당 값을 1000으로 곱하여 총 용량을 표현합니다. 예를 들어 노드에 두 개의 코어가 있는 경우 노드의 CPU 용량이 2000m 으로 표시됩니다. 따라서 단일 코어의 10분의 1을 사용하려는 경우 값을 100m 로 지정합니다.

메모리는 바이트 단위로 측정됩니다. 바이트 표기법(E, P, T, G, M, K) 또는 바이너리 동등한 값(Ei, Pi, Ti, Gi, Mi, Ki)을 사용하여 값을 지정할 수 있습니다. 지정한 값은 단위를 포함해야 합니다.

4.5.1. 브로커 리소스 제한 및 요청 구성

다음 예제에서는 브로커 배포에 대한 기본 CR(사용자 정의 리소스) 인스턴스를 구성하여 배포의 Pod에서 실행되는 각 브로커 컨테이너의 CPU 및 메모리에 대한 제한 및 요청을 설정하는 방법을 보여줍니다.

중요
  • CR을 처음 배포하기 전에 브로커 배포의 CR 인스턴스에 제한 및 요청에 대한 구성을 추가해야 합니다. 이미 실행 중인 브로커 배포에 구성을 추가할 수 없습니다.
  • 특정 메시징 시스템 사용 사례와 구현한 결과 아키텍처를 기반으로 하므로 Red Hat은 제한 및 요청 값을 권장할 수 없습니다. 그러나 프로덕션 환경에 맞게 구성하기 전에 개발 환경에서 이러한 값을 테스트하고 조정하는 것이 좋습니다.

사전 요구 사항

절차

  1. 브로커 배포용 CR(사용자 정의 리소스) 인스턴스 구성을 시작합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. 배포를 생성하는 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 배포를 생성하는 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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 섹션을 추가합니다. 제한요청 섹션을 추가합니다. 각 하위 섹션에서 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에서 실행 중인 각 브로커 컨테이너는 이 양의 host-node 메모리 사용량을 초과할 수 없습니다.
    requests.cpu
    배포의 Pod에서 실행 중인 각 브로커는 이 양의 host-node CPU를 요청합니다. 이 값은 브로커 컨테이너를 실행하는 데 필요한 최소 CPU 양입니다.
    requests.memory
    배포의 Pod에서 실행 중인 각 브로커에서는 이 양의 host-node 메모리를 요청합니다. 이 값은 브로커 컨테이너를 실행하는 데 필요한 최소 메모리 양입니다.
  3. CR 인스턴스를 배포합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. CR 파일을 저장합니다.
      2. 브로커 배포를 생성하는 프로젝트로 전환합니다.

        $ oc project <project_name>
      3. CR 인스턴스를 생성합니다.

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. OpenShift 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.

4.6. 브로커의 기본 메모리 제한 덮어쓰기

브로커에 설정된 기본 메모리 제한을 재정의할 수 있습니다. 기본적으로 브로커에는 브로커의 Java 가상 머신에 사용할 수 있는 최대 메모리의 절반이 할당됩니다. 다음 절차에서는 브로커 배포에 대한 CR(사용자 정의 리소스) 인스턴스를 구성하여 기본 메모리 제한을 재정의하는 방법을 보여줍니다.

사전 요구 사항

절차

  1. 기본 브로커 배포를 생성하도록 CR(사용자 정의 리소스) 인스턴스 구성을 시작합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. 브로커 배포의 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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(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 웹 콘솔 사용:

      1. CR 편집을 완료하면 저장 을 클릭합니다.
  4. (선택 사항) globalMaxSize 속성에 설정한 새 값이 브로커에 할당된 기본 메모리 제한을 덮어씁니다.

    1. AMQ 관리 콘솔에 연결합니다. 자세한 내용은 5장. Operator 기반 브로커 배포를 위해 AMQ 관리 콘솔에 연결의 내용을 참조하십시오.
    2. 메뉴에서 10.0.0.1을 선택합니다.
    3. org.apache.activemq.artemis 를 선택합니다.
    4. 글로벌 검색 .
    5. 표시되는 표에서 Global max 열의 값이 globalMaxSize 속성에 대해 구성한 값과 동일한지 확인합니다.

4.7. 사용자 정의 Init Container 이미지 지정

4.1절. “Operator에서 브로커 구성을 생성하는 방법” 에 설명된 대로 AMQ Broker Operator는 기본 기본 Init Container를 사용하여 브로커 구성을 생성합니다. 구성을 생성하기 위해 Init Container는 배포에 기본 CR(사용자 정의 리소스) 인스턴스를 사용합니다. CR에서 지정할 수 있는 항목은 주요 브로커 CRD(Custom Resource Definition)에 노출되는 항목 뿐입니다.

그러나 CRD에 노출되지 않은 구성을 포함해야 하는 경우가 있을 수 있습니다. 이 경우 기본 CR 인스턴스에서 사용자 정의 Init Container를 지정할 수 있습니다. 사용자 정의 Init Container는 Operator에서 이미 생성한 구성을 수정하거나 추가할 수 있습니다. 예를 들어 사용자 정의 Init Container를 사용하여 브로커 로깅 설정을 수정할 수 있습니다. 또는 사용자 정의 Init Container를 사용하여 브로커 설치 디렉터리에 추가 런타임 종속성(즉, .jar 파일)을 포함할 수 있습니다.

사용자 정의 Init Container 이미지를 빌드할 때 다음 중요한 지침을 따라야 합니다.

  • 사용자 정의 이미지에 대해 생성하는 빌드 스크립트(예: Docker Dockerfile 또는 Podman Containerfile)에서 FROM 명령은 최신 버전의 AMQ Broker Operator 기본 제공 Init Container를 기본 이미지로 지정해야 합니다. 스크립트에서 다음 행을 포함합니다.

    FROM registry.redhat.io/amq7/amq-broker-init-rhel8:7.10
  • 사용자 지정 이미지에는 /amq/scripts 라는 디렉터리에 포함하는 post-config.sh 스크립트가 포함되어야 합니다. post-config.sh 스크립트는 Operator가 생성하는 초기 구성을 수정하거나 추가할 수 있는 위치입니다. 사용자 지정 Init Container를 지정하면 Operator는 CR 인스턴스를 사용하여 구성을 생성한 브로커 애플리케이션 컨테이너를 시작하기 전에 post-config.sh 스크립트를 실행합니다.
  • 4.1.2절. “브로커 Pod의 디렉터리 구조” 에 설명된 대로 Init Container에서 사용하는 설치 디렉터리의 경로는 CONFIG_INSTANCE_DIR 이라는 환경 변수에 정의됩니다. post-config.sh 스크립트는 설치 디렉터리(예: ${CONFIG_INSTANCE_DIR}/lib)를 참조할 때 이 환경 변수 이름을 사용해야 하며 이 변수의 실제 값(예: /amq/init/config/lib)을 사용해야 합니다.
  • 사용자 정의 브로커 구성에 추가 리소스(예: .xml 또는 .jar 파일)를 포함하려면 사용자 정의 이미지에 포함되어 있고 post-config.sh 스크립트에 액세스할 수 있는지 확인해야 합니다.

다음 절차에서는 사용자 정의 Init Container 이미지를 지정하는 방법을 설명합니다.

사전 요구 사항

  • 위에서 설명한 지침을 충족하는 사용자 정의 Init Container 이미지를 빌드해야 합니다. ArtemisCloud Operator에 대한 사용자 정의 Init Container 이미지를 빌드하고 지정하는 전체 예제는 JDBC 기반 지속성에 대한 사용자 정의 Init Container 이미지를 참조하십시오.
  • AMQ Broker Operator에 대한 사용자 지정 Init Container 이미지를 제공하려면 Quay 컨테이너 레지스트리와 같은 컨테이너 레지스트리의 리포지토리에 이미지를 추가할 수 있어야 합니다.
  • Operator에서 Init Container를 사용하여 브로커 구성을 생성하는 방법을 이해해야 합니다. 자세한 내용은 4.1절. “Operator에서 브로커 구성을 생성하는 방법”의 내용을 참조하십시오.
  • CR을 사용하여 브로커 배포를 생성하는 방법에 대해 잘 알고 있어야 합니다. 자세한 내용은 3.4절. “Operator 기반 브로커 배포 생성”의 내용을 참조하십시오.

절차

  1. 브로커 배포용 CR(사용자 정의 리소스) 인스턴스 구성을 시작합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. 배포를 생성하는 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 배포를 생성하는 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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 속성 값을 사용자 정의 Init Container 이미지의 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
    사용자 정의 Init Container 이미지의 전체 URL을 지정합니다. 이 URL은 컨테이너 레지스트리의 리포지토리에 추가해야 합니다.
  4. CR 인스턴스를 배포합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. CR 파일을 저장합니다.
      2. 브로커 배포를 생성하는 프로젝트로 전환합니다.

        $ oc project <project_name>
      3. CR 인스턴스를 생성합니다.

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. OpenShift 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.

추가 리소스

4.8. 클라이언트 연결에 대한 Operator 기반 브로커 배포 구성

4.8.1. 수락자 구성

OpenShift 배포에서 브로커 Pod에 대한 클라이언트 연결을 활성화하려면 배포에 대한 어셉터 를 정의합니다. acceptors는 브로커 Pod에서 연결을 수락하는 방법을 정의합니다. 브로커 배포에 사용되는 주요 CR(사용자 정의 리소스)에서 어셉터를 정의합니다. 어셉터를 생성할 때 acceptor에서 사용할 메시징 프로토콜과 같은 정보와 이러한 프로토콜에 사용할 브로커 Pod의 포트를 지정합니다.

다음 절차에서는 브로커 배포를 위해 CR에 새 어셉터를 정의하는 방법을 보여줍니다.

절차

  1. 초기 설치 중에 다운로드하여 추출한 Operator 아카이브의 deploy/crs 디렉터리에서 broker_activemqartemis_cr.yaml CR(사용자 정의 리소스) 파일을 엽니다.
  2. acceptors 요소에서 named acceptor를 추가합니다. protocolsport 매개 변수를 추가합니다. acceptor 및 각 브로커 Pod의 포트를 해당 프로토콜에 노출할 메시징 프로토콜을 지정하려면 값을 설정합니다. 예를 들면 다음과 같습니다.

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

    구성된 acceptor는 포트 5672를 AMQP 클라이언트에 노출합니다. protocols 매개변수에 지정할 수 있는 전체 값 세트는 표에 표시됩니다.

    프로토콜현재의

    코어 프로토콜

    코어

    AMQP

    amqp

    OpenWire

    Open>-<re

    MQTT

    mqtt

    STOMP

    stomp

    지원되는 모든 프로토콜

    all

    참고
    • 배포의 각 브로커 Pod에 대해 Operator는 포트 61616을 사용하는 기본 어셉터도 생성합니다. 이 기본 어셉터는 브로커 클러스터링에 필요하며 코어 프로토콜이 활성화되어 있습니다.
    • 기본적으로 AMQ Broker 관리 콘솔은 브로커 Pod에서 포트 8161을 사용합니다. 배포의 각 브로커 Pod에는 콘솔에 대한 액세스를 제공하는 전용 서비스가 있습니다. 자세한 내용은 5장. Operator 기반 브로커 배포를 위해 AMQ 관리 콘솔에 연결의 내용을 참조하십시오.
  3. 동일한 어셉터에서 다른 프로토콜을 사용하려면 protocols 매개변수를 수정합니다. 쉼표로 구분된 프로토콜 목록을 지정합니다. 예를 들면 다음과 같습니다.

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

    이제 구성된 acceptor가 AMQP 및 OpenForwardedre 클라이언트에 포트 5672를 노출합니다.

  4. 수락자가 허용하는 동시 클라이언트 연결 수를 지정하려면 connectionsAllowed 매개변수를 추가하고 값을 설정합니다. 예를 들면 다음과 같습니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        connectionsAllowed: 5
    ...
  5. 기본적으로 어셉터는 브로커 배포와 동일한 OpenShift 클러스터의 클라이언트에만 노출됩니다. OpenShift 외부의 클라이언트에 acceptor도 노출하려면 expose 매개변수를 추가하고 값을 true 로 설정합니다.

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

    OpenShift 외부의 클라이언트에 어셉터를 노출하면 Operator는 배포의 각 브로커 포드에 대해 전용 서비스 및 경로를 자동으로 생성합니다.

  6. OpenShift 외부의 클라이언트에서 어셉터에 대한 보안 연결을 활성화하려면 sslEnabled 매개변수를 추가하고 값을 true 로 설정합니다.

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

    수락자(또는 커넥터)에서 SSL(즉, Secure Sockets Layer) 보안을 활성화하면 다음과 같은 관련 구성을 추가할 수 있습니다.

    • OpenShift 클러스터에 인증 자격 증명을 저장하는 데 사용되는 시크릿 이름입니다. 수락자에서 SSL을 활성화하면 시크릿이 필요합니다. 이 시크릿 생성에 대한 자세한 내용은 4.8.2절. “broker-client 연결 보안” 을 참조하십시오.
    • 보안 네트워크 통신에 사용할 TLS(Transport Layer Security) 프로토콜입니다. TLS는 보다 안전한 SSL 버전입니다. enabledProtocols 매개변수에 TLS 프로토콜을 지정합니다.
    • 어셉터가 2방향 TLS를 사용하는지 여부 (중간 인증 이라고도 함) 브로커와 클라이언트 사이입니다. needClientAuth 매개변수의 값을 true 로 설정하여 지정합니다.

추가 리소스

4.8.2. broker-client 연결 보안

어셉터 또는 커넥터에서 보안을 활성화한 경우(즉, sslEnabledtrue로 설정하여 브로커와 클라이언트 간의 인증서 기반 인증을 허용하도록 TLS(Transport Layer Security)를 구성해야 합니다. TLS는 보다 안전한 SSL 버전입니다. 다음 두 가지 기본 TLS 구성이 있습니다.

단방향 TLS
브로커만 인증서를 제공합니다. 인증서는 클라이언트가 브로커를 인증하는 데 사용됩니다. 가장 일반적인 구성입니다.
양방향 TLS
브로커와 클라이언트 모두 인증서를 제공합니다. 이를 상호 인증 이라고 합니다.

다음 섹션은 다음과 같습니다.

단방향 및 양방향 TLS의 경우 브로커와 클라이언트 간에 성공적인 TLS 핸드셰이크에 필요한 인증 정보를 저장하는 시크릿을 생성하여 구성을 완료합니다. 보안 수락자 또는 커넥터의 sslSecret 매개변수에 지정해야 하는 보안 이름입니다. 시크릿에는 Base64로 인코딩된 브로커 키 저장소(한방향 및 양방향 TLS 모두), Base64로 인코딩된 브로커 신뢰 저장소(two-way TLS만 해당), Base64 인코딩 브로커의 해당 암호도 포함되어야 합니다. 단방향 및 양방향 TLS 구성 프로시저에서는 이 시크릿을 생성하는 방법을 보여줍니다.

참고

보안 수용자 또는 커넥터의 sslSecret 매개변수에 보안 이름을 명시적으로 지정하지 않으면 어셉터 또는 커넥터가 기본 보안 이름을 가정합니다. 기본 시크릿 이름은 < custom_resource_name> - <acceptor_name> -secret 또는 < custom_resource_name> - <connector_name> -secret 을 사용합니다. 예를 들면 my-broker-deployment-my-acceptor-secret 입니다.

어셉터 또는 커넥터가 기본 시크릿 이름을 가정하더라도 이 시크릿을 직접 생성해야 합니다. 자동으로 생성되지 않습니다.

4.8.2.1. 호스트 이름 확인을 위한 브로커 인증서 구성

참고

이 섹션에서는 단방향 또는 양방향 TLS를 구성할 때 생성해야 하는 브로커 인증서의 몇 가지 요구 사항에 대해 설명합니다.

클라이언트가 배포의 브로커 Pod에 연결을 시도할 때 클라이언트 연결 URL의 verifyHost 옵션은 클라이언트가 브로커 인증서의 CN(Common Name)을 호스트 이름과 비교하여 일치하는지 여부를 결정합니다. 클라이언트는 클라이언트 연결 URL에서 verifyHost=true 또는 유사한 것을 지정하는 경우 이 확인을 수행합니다.

연결이 분리된 네트워크의 OpenShift 클러스터에 배포된 경우와 같이 연결 보안에 대한 우려가 없는 드문 경우 이러한 확인을 생략할 수 있습니다. 그렇지 않으면 보안 연결의 경우 클라이언트가 이 확인을 수행하는 것이 좋습니다. 이 경우 클라이언트 연결이 성공하려면 브로커 키 저장소 인증서에 대한 올바른 구성이 필요합니다.

일반적으로 클라이언트가 호스트 확인을 사용하는 경우 브로커 인증서를 생성할 때 지정하는 CN은 클라이언트가 연결하는 브로커 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로 성공적으로 확인되었습니다.

또한 브로커 인증서를 생성할 때 지정하는 SAN(Subject Alternative Name)은 배포의 모든 브로커 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 구성

이 섹션의 절차에서는 broker-client 연결을 보호하기 위해 단방향 전송 계층 보안(TLS)을 구성하는 방법을 보여줍니다.

단방향 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>
    참고

    시크릿을 생성할 때 OpenShift에서는 키 저장소와 신뢰 저장소를 모두 지정해야 합니다. 신뢰 저장소 키의 이름은 일반적으로 client.ts 로 지정됩니다. 브로커와 클라이언트 간의 단방향 TLS의 경우 실제로 신뢰 저장소가 필요하지 않습니다. 그러나 시크릿을 성공적으로 생성하려면 몇 가지 유효한 저장소 파일을 client.ts 의 값으로 지정해야 합니다. 이전 단계에서는 이전에 생성된 브로커 키 저장소 파일을 재사용하여 client.ts 에 대한 "dummy" 값을 제공합니다. 이는 단방향 TLS에 필요한 모든 자격 증명으로 시크릿을 생성하기에 충분합니다.

  7. Operator를 설치할 때 생성한 서비스 계정에 보안을 연결합니다. 예를 들면 다음과 같습니다.

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
  8. 보안 수용자 또는 커넥터의 sslSecret 매개변수에 보안 이름을 지정합니다. 예를 들면 다음과 같습니다.

    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 구성

이 섹션의 절차에서는 broker-client 연결을 보호하기 위해 양방향 전송 계층 보안(TLS)을 구성하는 방법을 보여줍니다.

양방향 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. 클라이언트에서 클라이언트 키 저장소에 대한 자체 서명된 인증서를 생성합니다.

    $ 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>
    참고

    시크릿을 생성할 때 OpenShift에서는 키 저장소와 신뢰 저장소를 모두 지정해야 합니다. 신뢰 저장소 키의 이름은 일반적으로 client.ts 로 지정됩니다. 브로커와 클라이언트 간의 양방향 TLS의 경우 클라이언트 인증서가 포함되므로 브로커 신뢰 저장소를 포함하는 보안을 생성해야 합니다. 따라서 이전 단계에서 client.ts 키에 대해 지정하는 값은 실제로 브로커 신뢰 저장소 파일입니다.

  10. Operator를 설치할 때 생성한 서비스 계정에 보안을 연결합니다. 예를 들면 다음과 같습니다.

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
  11. 보안 수용자 또는 커넥터의 sslSecret 매개변수에 보안 이름을 지정합니다. 예를 들면 다음과 같습니다.

    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 웹 콘솔의 네트워킹 창에는 두 개의 실행 중인 서비스( 헤드리스 서비스 및 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 프로토콜을 사용하고 있고 useTopologyForLoadBalancing=false 키가 연결 URL에 설정되지 않은 경우 클라이언트가 브로커에 처음 연결된 후 브로커는 클러스터에 있는 모든 브로커의 주소를 알릴 수 있습니다. 그러면 클라이언트가 모든 브로커 간에 연결을 로드 밸런싱할 수 있습니다.

브로커에 미미한 서브스크립션 대기열 또는 요청/응답 대기열이 있는 경우 클라이언트 연결이 부하 분산될 때 이러한 큐 사용과 관련된 주의 사항을 알고 있어야 합니다. 자세한 내용은 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 라우터는 보안되지 않은(SSL이 아닌) 트래픽(즉, SSL 암호화) 트래픽에 대해 포트 80을 수신합니다. HTTP 연결의 경우 보안 연결 URL(즉, https)을 지정하거나 안전하지 않은 연결 URL(즉, http)을 지정하면 라우터에서 포트 443으로 트래픽을 자동으로 전달합니다.

외부 클라이언트가 클러스터의 브로커 간에 연결을 로드 밸런싱하려면 다음을 수행합니다.

  • 각 브로커 포드에 대해 OpenShift 경로에 haproxy.router.openshift.io/balance roundrobin 옵션을 구성하여 부하 분산을 활성화합니다.
  • 외부 클라이언트가 Core 프로토콜을 사용하는 경우 기본적으로 useTopologyForLoadBalancing 구성 옵션이 true 로 설정됩니다. 연결 URL에서 이 값이 false로 설정되어 있지 않은지 확인합니다.

브로커에 미미한 서브스크립션 대기열 또는 요청/응답 대기열이 있는 경우 클라이언트 연결을 부하 분산할 때 이러한 큐 사용과 관련된 주의 사항을 알고 있어야 합니다. 자세한 내용은 4.8.4.4절. “미정형 서브스크립션 대기열 또는 응답/요청 대기열이 있는 경우 클라이언트 연결을 로드 밸런싱하는 경고”의 내용을 참조하십시오.

외부 클라이언트가 클러스터의 브로커 간에 연결을 로드 밸런싱하지 않도록 하려면 다음을 수행합니다.

  • 각 클라이언트가 사용하는 연결 URL에서 useTopologyForLoadBalancing=false 키를 설정합니다.
  • 각 클라이언트의 연결 URL에서 각 브로커 Pod의 경로 전체 호스트 이름을 지정합니다. 클라이언트는 연결 URL의 첫 번째 호스트 이름에 연결을 시도합니다. 그러나 첫 번째 호스트 이름을 사용할 수 없는 경우 클라이언트는 연결 URL의 다음 호스트 이름에 자동으로 연결됩니다.

비HTTP 연결의 경우:

  • 클라이언트는 연결 URL의 일부로 포트 번호(예: 포트 443)를 명시적으로 지정해야 합니다.
  • 단방향 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>

참고

외부 Core 클라이언트가 브로커가 반환하는 토폴로지 정보를 사용할 수 없기 때문에 연결 URL에서 useTopologyForLoadBalancing 키는 명시적으로 false 로 설정됩니다. 이 키를 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>

외부 OpenECDHEre 클라이언트, 단방향 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>

외부 OpenECDHEre 클라이언트, 양방향 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 관리자는 OpenShift 외부의 클라이언트에서 브로커 포드에 연결하도록 NodePort를 구성할 수 있습니다. NodePort는 브로커에 대해 구성된 어셉터에 의해 지정된 프로토콜별 포트 중 하나에 매핑되어야 합니다.

기본적으로 NodePort는 30000~32767 범위에 있으므로 NodePort가 일반적으로 브로커 Pod에서 의도한 포트와 일치하지 않습니다.

NodePort를 통해 OpenShift 외부의 클라이언트에서 브로커에 연결하려면 < protocol > :// <ocp_node_ip> : <node_ port_number > 형식으로 URL을 지정합니다.

4.8.4.4. 미정형 서브스크립션 대기열 또는 응답/요청 대기열이 있는 경우 클라이언트 연결을 로드 밸런싱하는 경고

조정된 서브스크립션

장악한 서브스크립션은 브로커의 큐로 표현되며, 장엄한 구독자가 먼저 브로커에 연결될 때 생성됩니다. 이 큐가 존재하며 클라이언트가 구독 해제될 때까지 메시지를 수신합니다. 클라이언트가 다른 브로커에 다시 연결되면 해당 브로커에서 또 다른 안정된 서브스크립션 큐가 생성됩니다. 이로 인해 다음 문제가 발생할 수 있습니다.

문제완화 방법

메시지는 원래 서브스크립션 큐에 포함될 수 있습니다.

메시지 재배포가 활성화되었는지 확인합니다. 자세한 내용은 메시지 재배포 활성화를 참조하십시오.

다른 메시지가 라우팅될 때 메시지 재배포 중 창이 있으므로 잘못된 순서로 메시지가 수신될 수 있습니다.

없음.

클라이언트가 구독을 취소하면 마지막으로 연결된 브로커에서만 큐를 삭제합니다. 즉, 다른 대기열은 여전히 존재하며 메시지를 수신할 수 있습니다.

구독 해제된 클라이언트에 대해 존재할 수 있는 다른 빈 큐를 삭제하려면 다음 속성을 둘 다 구성합니다.

큐에 메시지가 없는 경우에만 큐를 삭제할 수 있도록 auto-delete-queues-message-count 속성을 0 으로 설정합니다. 지정된 시간(밀리초)에 사용되지 않은 메시지가 없는 큐를 삭제하도록 auto-delete-queues-delay 속성을 설정합니다.

자세한 내용은 주소 및 큐의 자동 생성 및 삭제 구성을 참조하십시오.

요청/응답 대기열

JMS Producer에서 임시 응답 대기열을 생성하면 큐가 브로커에서 생성됩니다. 작업 대기열에서 소비하고 임시 대기열에 응답하는 클라이언트가 다른 브로커에 연결된 경우 다음 문제가 발생할 수 있습니다.

문제완화 방법

클라이언트가 연결된 브로커에 응답 대기열이 없으므로 클라이언트는 오류를 생성할 수 있습니다.

auto-create-queues 속성이 true 로 설정되어 있는지 확인합니다. 자세한 내용은 주소 및 큐의 자동 생성 및 삭제 구성을 참조하십시오.

작업 큐로 전송된 메시지는 배포되지 않을 수 있습니다.

message-load-balancing 속성을 ON-DEMAND 로 설정하여 필요에 따라 메시지의 부하를 분산시킵니다. 또한 메시지 재배포가 활성화되어 있는지 확인합니다. 자세한 내용은 메시지 재배포 활성화를 참조하십시오.

추가 리소스

  • OpenShift 클러스터 외부에서 클러스터에서 실행되는 서비스와 통신하는 데 경로 및 NodePort와 같은 방법을 사용하는 방법에 대한 자세한 내용은 다음을 참조하십시오.

4.9. AMQP 메시지에 대한 대규모 메시지 처리 구성

클라이언트는 브로커의 내부 버퍼 크기를 초과할 수 있는 대용량 AMQP 메시지를 보내 예기치 않은 오류가 발생할 수 있습니다. 이 상황을 방지하려면 메시지가 지정된 최소 값보다 클 때 메시지를 파일로 저장하도록 브로커를 구성할 수 있습니다. 이러한 방식으로 대용량 메시지를 처리한다는 것은 브로커가 메모리에 메시지를 보관하지 않음을 의미합니다. 대신 브로커는 대규모 메시지 파일을 저장하는 데 사용되는 전용 디렉터리에 메시지를 저장합니다.

OpenShift Container Platform에서 브로커 배포의 경우 큰 messages 디렉터리는 메시지 스토리지를 위해 브로커가 사용하는 PV(영구 볼륨)의 /opt/ <custom_resource_name> /data/large- knative입니다. 브로커가 메시지를 큰 메시지로 저장하면 큐는 큰 메시지 디렉터리에 파일에 대한 참조를 유지합니다.

중요

AMQ Broker 7.10의 Operator 기반 브로커 배포의 경우 AMQP 프로토콜에서만 대규모 메시지 처리를 사용할 수 있습니다.

4.9.1. 대규모 메시지 처리를 위한 AMQP 어셉터 구성

다음 절차에서는 지정된 크기보다 큰 AMQP 메시지를 대규모 메시지로 처리하도록 어셉터를 구성하는 방법을 보여줍니다.

사전 요구 사항

  • Operator 기반 브로커 배포에 대한 수락자를 구성하는 방법에 대해 잘 알고 있어야 합니다. 4.8.1절. “수락자 구성”을 참조하십시오.
  • 대규모 AMQP 메시지를 전용 대규모 메시지 디렉터리에 저장하려면 브로커 배포가 영구 스토리지를 사용해야 합니다(즉, 배포를 생성하는 데 사용되는 CR(사용자 정의 리소스) 인스턴스에서 persistenceEnabledtrue 로 설정됨). 영구 스토리지 구성에 대한 자세한 내용은 다음을 참조하십시오.

절차

  1. 이전에 AMQP 어셉터를 정의한 CR(사용자 정의 리소스) 인스턴스를 엽니다.

    1. OpenShift 명령줄 인터페이스 사용:

      $ oc edit -f <path/to/custom_resource_instance>.yaml
    2. OpenShift Container Platform 웹 콘솔 사용:

      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 메시지를 수신하는 경우 브로커는 메시지를 큰 메시지로 저장합니다.

    브로커는 메시지 스토리지를 위해 브로커가 사용하는 PV(영구 볼륨)의 큰 메시지 디렉터리(/opt/ <custom_resource_name> /data/large- ECDHE )에 메시지를 저장합니다.

    amqpMinLargeMessageSize 속성 값을 명시적으로 지정하지 않으면 브로커는 기본값 102400(즉, 100 킬로바이트)을 사용합니다.

    amqpMinLargeMessageSize-1 로 설정하면 AMQP 메시지에 대한 큰 메시지 처리가 비활성화됩니다.

4.10. 브로커 상태 점검 구성

liveness 및 readiness 프로브를 사용하여 실행 중인 브로커 컨테이너에 대해 정기적인 상태 점검을 구성할 수 있습니다. 활성 상태 프로브는 브로커의 HTTP 포트를 ping하여 브로커가 실행 중인지 확인합니다. 준비 상태 프로브는 브로커가 브로커에 대해 구성된 각 어셉터 포트에 대한 연결을 열어 네트워크 트래픽을 허용할 수 있는지 확인합니다.

기본 활성 및 준비 상태 프로브를 사용하여 HTTP 및 어셉터 포트에 대한 연결을 열어 브로커의 상태를 확인하는 제한은 이러한 검사에서 브로커 파일 시스템의 기본 문제를 식별할 수 없다는 것입니다. 브로커의 명령줄 유틸리티인 artemis 를 활성 상태 또는 준비 상태 프로브 구성에 통합하여 브로커에게 메시지 전송을 포함하는 보다 포괄적인 상태 점검을 생성할 수 있습니다.

4.10.1. 활성 상태 프로브 및 준비 상태 프로브 구성

다음 예제에서는 활성 상태 프로브를 사용하여 상태 점검을 실행하도록 브로커 배포의 기본 CR(사용자 정의 리소스) 인스턴스를 구성하는 방법을 보여줍니다.

사전 요구 사항

절차

  1. CR 인스턴스를 생성합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. 브로커 배포의 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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 검사 명령줄 유틸리티를 liveness 또는 readiness 프로브 구성에 추가합니다.

    1. 브로커에 대한 전체 클라이언트 연결을 생성하는 상태 점검을 구성하려면 livenessProbe 또는 readinessProbe 섹션에서 exec 섹션을 추가합니다. exec 섹션에서 command 섹션을 추가합니다. command 섹션에서 artemis 검사 노드 명령 구문을 추가합니다. 예를 들면 다음과 같습니다.

      spec:
        deploymentPlan:
          readinessProbe:
            exec:
              command:
                - bash
                - '-c'
                - /home/jboss/amq-broker/bin/artemis
                - check
                - node
                - '--silent'
                - '--acceptor'
                - <acceptor name>
                - '--user'
                - $AMQ_USER
                - '--password'
                - $AMQ_PASSWORD
            initialDelaySeconds: 30
            timeoutSeconds: 5

      기본적으로 artemis check node 명령은 artemis 라는 어셉터의 URI를 사용합니다. 브로커에 artemis 라는 어셉터가 있는 경우 명령에서 --acceptor <acceptor name > 옵션을 제외할 수 있습니다.

      참고

      $AMQ_USER$AMQ_PASSWORD 는 AMQ Operator에 의해 구성된 환경 변수입니다.

    2. 메시지를 생성하고 사용하는 상태 점검을 구성하려면 broker 파일 시스템의 상태를 livenessProbe 또는 readinessProbe 섹션에서 검증합니다. exec 섹션을 추가합니다. exec 섹션에서 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 웹 콘솔 사용:

      1. CR 구성을 완료하면 생성을 클릭합니다.

추가 리소스

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 draining

브로커 Pod가 종료되면 AMQ Broker Operator는 브로커 클러스터에서 계속 실행 중인 다른 브로커 Pod로 메시지 마이그레이션을 수행하는 스케일다운 컨트롤러를 자동으로 시작합니다. 이 메시지 마이그레이션 프로세스는 Pod 드레이닝 이라고도 합니다. 다음 섹션에서는 메시지 마이그레이션을 설명합니다.

4.11.2. 메시지 마이그레이션

메시지 마이그레이션은 배포의 의도적인 축소로 인해 클러스터형 배포의 브로커가 종료될 때 메시징 데이터의 무결성을 보장하는 방법입니다. Pod 드레이닝 이라고도 하는 이 프로세스는 종료된 브로커 Pod에서 메시지 제거 및 재배포를 참조합니다.

참고
  • 메시지 마이그레이션을 수행하는 스케일다운 컨트롤러는 단일 OpenShift 프로젝트 내에서만 작동할 수 있습니다. 컨트롤러는 별도의 프로젝트에서 브로커 간에 메시지를 마이그레이션할 수 없습니다.
  • 메시지 마이그레이션을 사용하려면 배포에 최소 두 개의 브로커가 있어야 합니다. 두 개 이상의 브로커가 있는 브로커는 기본적으로 클러스터됩니다.

Operator 기반 브로커 배포의 경우 배포에 대한 기본 브로커 사용자 정의 리소스에서 messageMigrationtrue 로 설정하여 메시지 마이그레이션을 활성화합니다.

메시지 마이그레이션 프로세스는 다음 단계를 따릅니다.

  1. 배포의 의도적인 스케일 다운으로 인해 배포의 브로커 Pod가 종료되면 Operator는 축소 컨트롤러를 자동으로 시작하여 메시지 마이그레이션을 준비합니다. 스케일다운 컨트롤러는 브로커 클러스터와 동일한 OpenShift 프로젝트 이름으로 실행됩니다.
  2. 스케일다운 컨트롤러는 자체적으로 등록하고 프로젝트의 PVC(영구 볼륨 클레임)와 관련된 Kubernetes 이벤트를 수신 대기합니다.
  3. 분리된 PV(영구 볼륨)를 확인하려면 축소 컨트롤러에서 볼륨 클레임의 오디널을 확인합니다. 컨트롤러는 볼륨 클레임의 오디널을 프로젝트의 StatefulSet (즉, 브로커 클러스터)에서 실행 중인 브로커 Pod의 항목과 비교합니다.

    볼륨 클레임의 오디널이 브로커 클러스터에서 실행 중인 브로커 Pod의 서수보다 많은 경우 축소 컨트롤러는 해당 ordinal의 브로커 Pod가 종료되고 메시징 데이터를 다른 브로커 Pod로 마이그레이션해야 함을 결정합니다.

  4. scaledown 컨트롤러는 drainer Pod를 시작합니다. drainer Pod는 브로커를 실행하고 메시지 마이그레이션을 실행합니다. 그런 다음 drainer Pod는 고립된 메시지를 마이그레이션할 수 있는 대체 브로커 Pod를 식별합니다.

    참고

    메시지 마이그레이션이 수행되려면 배포에 하나 이상의 브로커 Pod가 실행 중이어야 합니다.

다음 그림은 스케일다운 컨트롤러(레이닝 컨트롤러라고도 함)가 실행 중인 브로커 Pod로 메시지를 마이그레이션하는 방법을 보여줍니다.

Ah ocp pod draining 3

메시지가 작동 브로커 Pod로 성공적으로 마이그레이션되면 드레이닝기 Pod가 종료되고 축소 컨트롤러에서 고립된 PV의 PVC를 제거합니다. PV가 "Released" 상태로 돌아갑니다.

참고

브로커 배포를 0(zero)으로 축소하면 메시징 데이터를 마이그레이션할 수 있는 실행 중인 브로커 Pod가 없기 때문에 메시지 마이그레이션이 발생하지 않습니다. 그러나 배포를 0으로 축소한 다음 원래 배포보다 작은 크기로 백업하면 종료된 브로커에 대해 드레인더 Pod가 시작됩니다.

추가 리소스

4.11.3. 스케일 다운 시 메시지 마이그레이션

브로커 배포의 축소 시 메시지를 마이그레이션하려면 주요 브로커 CR(사용자 정의 리소스)을 사용하여 메시지 마이그레이션을 활성화합니다. AMQ Broker Operator는 클러스터형 브로커 배포를 축소할 때 메시지 마이그레이션을 실행하도록 전용 스케일다운 컨트롤러를 자동으로 실행합니다.

메시지 마이그레이션이 활성화되면 Operator 내의 스케일다운 컨트롤러에서 브로커 Pod의 종료를 감지하고 드레인러 Pod를 시작하여 메시지 마이그레이션을 실행합니다. drainer Pod는 클러스터의 다른 라이브 브로커 Pod 중 하나에 연결하고 해당 라이브 브로커 Pod로 메시지를 마이그레이션합니다. 마이그레이션이 완료되면 스케일다운 컨트롤러가 종료됩니다.

참고
  • 스케일다운 컨트롤러는 단일 OpenShift 프로젝트 내에서만 작동합니다. 컨트롤러는 별도의 프로젝트에서 브로커 간에 메시지를 마이그레이션할 수 없습니다.
  • 브로커 배포를 0(zero)으로 축소하면 메시징 데이터를 마이그레이션할 수 있는 실행 중인 브로커 Pod가 없기 때문에 메시지 마이그레이션이 수행되지 않습니다. 그러나 배포를 0 브로커로 축소한 다음 원래 배포에 있는 브로커 중 일부만 지원하는 경우, 종료된 브로커의 경우 드레이너 포드가 시작됩니다.

다음 예제 절차에서는 축소 컨트롤러의 동작을 보여줍니다.

사전 요구 사항

절차

  1. 원래 다운로드 및 추출한 Operator 리포지토리의 deploy/crs 디렉터리에서 주요 브로커 CR, broker_activemqartemis_cr.yaml 을 엽니다.
  2. 메인 브로커 CR에서 messageMigrationpersistenceEnabledtrue 로 설정합니다.

    이러한 설정은 나중에 클러스터형 브로커 배포 크기를 축소할 때 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

    앞의 출력에서는 3개의 Pod가 실행 중임을 보여줍니다. 하나는 브로커 Operator 자체와 배포의 각 브로커에 대해 별도의 Pod입니다.

  4. 각 포드에 로그인하여 일부 메시지를 각 브로커에 보냅니다.

    1. 해당 Pod ex-aao-ss-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-ss-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개로 축소합니다.

    1. 주요 브로커 CR, broker_activemqartemis_cr.yaml 을 엽니다.
    2. CR에서 deploymentPlan.size1 로 설정합니다.
    3. 명령줄에서 변경 사항을 적용합니다.

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

      ex-aao-s-1 Pod가 종료되기 시작하는 것을 확인할 수 있습니다. scaledown 컨트롤러는 동일한 이름의 새 드레인러 Pod를 시작합니다. 이 드레이너 Pod는 브로커 포드 ex-aao-ss-1 의 모든 메시지를 클러스터의 다른 브로커 Pod인 ex-aao-s-0 으로 마이그레이션한 후에도 종료됩니다.

  6. drainer Pod가 종료되면 브로커 Pod ex-aao-ss-0TEST 대기열에서 메시지 수를 확인합니다. 대기열의 메시지 수가 2000개이며, 드레이너 Pod가 종료된 브로커 Pod에서 1000개의 메시지를 마이그레이션했음을 나타냅니다.

4.12. OpenShift Container Platform 노드에서 브로커 Pod 배치 제어

노드 선택기, 허용 오차 또는 유사성 및 유사성 방지 규칙을 사용하여 OpenShift Container Platform 노드에서 AMQ Broker Pod 배치를 제어할 수 있습니다.

노드 선택기
노드 선택기를 사용하면 특정 노드에 브로커 Pod를 예약할 수 있습니다.
허용 오차
허용 오차가 노드에 구성된 테인트와 일치하는 경우 허용 오차를 노드에 예약할 수 있습니다. 일치하는 Pod 허용 오차가 없으면 테인트를 사용하면 노드가 Pod의 수락을 거부할 수 있습니다.
Affinity/Anti-affinity
노드 유사성 규칙은 노드의 라벨에 따라 Pod를 예약할 수 있는 노드를 제어합니다. Pod 유사성 및 유사성 방지 규칙은 해당 노드에서 이미 실행 중인 Pod에 따라 Pod를 예약할 수 있는 노드를 제어합니다.

4.12.1. 노드 선택기를 사용하여 특정 노드에 Pod 배치

노드 선택기는 노드 라벨에 일치하는 키-값 쌍이 있는 노드에 브로커 Pod를 예약해야 하는 키-값 쌍을 지정합니다.

다음 예제에서는 특정 노드에 브로커 Pod를 예약하도록 노드 선택기를 구성하는 방법을 보여줍니다.

사전 요구 사항

절차

  1. 기본 브로커 CRD를 기반으로 CR(사용자 정의 리소스) 인스턴스를 생성합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. 브로커 배포의 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.

추가 리소스

OpenShift Container Platform의 노드 선택기에 대한 자세한 내용은 OpenShift Container Platform 설명서의 노드 선택기를 사용하여 특정 노드에 Pod 배치를 참조하십시오.

4.12.2. 허용 오차를 사용하여 Pod 배치 제어

테인트 및 허용 오차는 특정 노드에서 Pod를 예약할 수 있는지 여부를 제어합니다. 테인트를 사용하면 Pod에 일치하는 톨러레이션이 없으면 노드에서 Pod 예약을 거부할 수 있습니다. 테인트를 사용하여 노드의 Pod를 제외할 수 있으므로 일치하는 톨러레이션이 있는 브로커 Pod와 같은 특정 Pod에 노드가 예약됩니다.

일치하는 톨러레이션이 있으면 브로커 Pod를 노드에 예약할 수 있지만 해당 노드에 Pod가 예약된다는 보장은 없습니다. 브로커 Pod가 테인트가 구성된 노드에 예약되도록 하려면 유사성 규칙을 구성할 수 있습니다. 자세한 내용은 다음을 참조하십시오. 4.12.3절. “유사성 및 유사성 방지 규칙을 사용하여 Pod 배치 제어”

다음 예제에서는 노드에 구성된 테인트와 일치하도록 허용 오차를 구성하는 방법을 보여줍니다.

사전 요구 사항

  • CR 인스턴스를 사용하여 기본 브로커 배포를 생성하는 방법에 대해 잘 알고 있어야 합니다. 3.4.1절. “기본 브로커 인스턴스 배포”을 참조하십시오.
  • 브로커 Pod를 예약하기 위해 예약할 노드에 테인트를 적용합니다. 테인트는 key, value 및 effect로 구성됩니다. 테인트 효과에 따라 다음이 결정됩니다.

    • 노드의 기존 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. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.

추가 리소스

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절. “기본 브로커 인스턴스 배포”을 참조하십시오.
  • 브로커 Pod를 예약할 수 있는 OpenShift Container Platform 클러스터의 노드에 공통 레이블을 할당합니다(예: zone: emea ).

절차

  1. 기본 브로커 CRD를 기반으로 CR(사용자 정의 리소스) 인스턴스를 생성합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. 브로커 배포의 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      5. Create ActiveMQArtemis 를 클릭합니다.

        콘솔에서 YAML 편집기가 열리고 CR 인스턴스를 구성할 수 있습니다.

  2. CR의 deploymentPlan 섹션에서 affinity,nodeAffinity,requiredDuringSchedulingIgnoredDuringExecution, nodeSelectorTerms 섹션을 추가합니다. nodeSelectorTerms 섹션에서 - matchExpressions 매개변수를 추가하고 일치시킬 노드 라벨의 키-값 문자열을 지정합니다. 예를 들면 다음과 같습니다.

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

    이 예에서 유사성 규칙을 사용하면 zone 키 및 emea 값이 있는 라벨이 있는 모든 노드에서 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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.

추가 리소스

OpenShift Container Platform의 유사성 규칙에 대한 자세한 내용은 OpenShift Container Platform 설명서의 노드 유사성 규칙을 사용하여 노드에 대한 Pod 배치 제어를 참조하십시오.

4.12.3.2. 유사성 방지 규칙을 사용하여 다른 Pod에 상대적인 Pod 배치

유사성 방지 규칙을 사용하면 해당 노드에서 이미 실행중인 Pod의 라벨에 따라 브로커 Pod를 예약할 수 있는 노드를 제한할 수 있습니다.

유사성 방지 규칙을 사용하는 사용 사례는 클러스터의 여러 브로커 Pod가 동일한 노드에 예약되지 않도록하여 단일 장애 지점을 생성하는 것입니다. Pod 배치를 제어하지 않으면 클러스터에 있는 2개 이상의 브로커 Pod를 동일한 노드에 예약할 수 있습니다.

다음 예제에서는 클러스터의 브로커 Pod 2가 동일한 노드에 예약되지 않도록 유사성 방지 규칙을 구성하는 방법을 보여줍니다.

사전 요구 사항

절차

  1. 기본 브로커 CRD를 기반으로 클러스터의 첫 번째 브로커에 대한 CR 인스턴스를 생성합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. 브로커 배포의 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 기본 브로커 CRD를 기반으로 새 CR 인스턴스를 시작합니다. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      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 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.
  4. 기본 브로커 CRD를 기반으로 클러스터에서 두 번째 브로커의 CR 인스턴스를 생성합니다.

    1. CR의 deploymentPlan 섹션에서 affinity,podAntiAffinity,requiredDuringSchedulingIgnoredDuringExecution, labelSelector 섹션을 추가합니다. labelSelector 섹션에서 - matchExpressions 매개변수를 추가하고 일치시킬 broker Pod 라벨의 키-값 문자열을 지정하므로 이 Pod는 동일한 노드에서 예약되지 않습니다.

      spec:
          deploymentPlan:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  labelSelector:
                    - matchExpressions:
                    - key: name
                      operator: In
                      values:
                        - broker1
                  topologyKey: topology.kubernetes.io/zone

      이 예에서 Pod 유사성 방지 규칙은 name 키가 있는 레이블과 클러스터의 첫 번째 브로커에 할당된 라벨인 broker1 값이 있는 Pod와 동일한 노드에 Pod를 배치하지 못하도록 합니다.

  5. CR 인스턴스를 배포합니다.

    1. OpenShift 명령줄 인터페이스 사용:

      1. CR 파일을 저장합니다.
      2. 브로커 배포를 생성하는 프로젝트로 전환합니다.

        $ oc project <project_name>
      3. CR 인스턴스를 생성합니다.

        $ oc create -f <path/to/custom_resource_instance>.yaml
    2. OpenShift 웹 콘솔 사용:

      1. CR 구성을 마쳤으면 생성을 클릭합니다.

추가 리소스

OpenShift Container Platform의 유사성 규칙에 대한 자세한 내용은 OpenShift Container Platform 설명서의 노드 유사성 규칙을 사용하여 노드에 대한 Pod 배치 제어를 참조하십시오.

5장. Operator 기반 브로커 배포를 위해 AMQ 관리 콘솔에 연결

Operator 기반 배포의 각 브로커 Pod는 포트 8161에서 AMQ Management Console의 자체 인스턴스를 호스팅합니다. 각 브로커에 대한 콘솔에 대한 액세스 권한을 제공하기 위해 브로커 배포에 대한 사용자 정의 리소스(CR) 인스턴스를 구성하여 각 브로커 Pod에 대한 전용 서비스 및 경로를 자동으로 생성하도록 Operator에 지시할 수 있습니다.

다음 절차에서는 배포된 브로커의 AMQ 관리 콘솔에 연결하는 방법을 설명합니다.

사전 요구 사항

  • AMQ Broker Operator를 사용하여 브로커 배포를 생성해야 합니다. 예를 들어 샘플 CR을 사용하여 기본 브로커 배포를 생성하는 방법을 알아보려면 3.4.1절. “기본 브로커 인스턴스 배포” 를 참조하십시오.
  • 콘솔 액세스를 위해 배포에 각 브로커 포드에 대한 서비스 및 경로를 자동으로 생성하도록 Operator에 지시하려면 배포를 생성하는 데 사용되는 CR(사용자 정의 리소스) 인스턴스에서 console.expose 속성 값을 true 로 설정해야 합니다. 이 속성의 기본값은 false 입니다. CR의 console 섹션 구성을 포함한 전체 사용자 정의 리소스 구성 참조는 8.1절. “사용자 정의 리소스 구성 참조” 을 참조하십시오.

5.1. AMQ 관리 콘솔에 연결

브로커 배포를 생성하는 데 사용되는 CR(사용자 정의 리소스) 인스턴스에서 console.expose 속성 값을 true 로 설정하면 Operator는 각 브로커 포드에 대한 전용 서비스 및 경로를 자동으로 생성하여 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 웹 콘솔에서 네트워킹경로 를 클릭합니다.

    경로 페이지에서 지정된 브로커 Pod의 wconsj 경로를 확인합니다. 예를 들면 my-broker-deployment-wconsj-0-svc-rte 입니다.

  2. 위치 에서 경로에 해당하는 링크를 클릭합니다.

    웹 브라우저에서 새 탭이 열립니다.

  3. 관리 콘솔 링크를 클릭합니다.

    AMQ Management Console 로그인 페이지가 열립니다.

  4. 콘솔에 로그인하려면 브로커 배포를 생성하는 데 사용되는 CR(사용자 정의 리소스) 인스턴스에 adminUseradminPassword 속성에 지정된 값을 입력합니다.

    CR에 adminUseradminPassword 에 대해 명시적으로 지정된 값이 없는 경우 5.2절. “AMQ Management Console 로그인 자격 증명 액세스” 의 지침에 따라 콘솔에 로그인하는 데 필요한 인증 정보를 검색합니다.

    참고

    adminUseradminPassword 값은 CR의 requireLogin 속성이 true 로 설정된 경우에만 콘솔에 로그인해야 합니다. 이 속성은 브로커 콘솔에 로그인하는 데 로그인 인증 정보가 필요한지 여부를 지정합니다. requireLoginfalse 로 설정된 경우 사용자 이름과 암호를 입력하라는 메시지가 표시되면 텍스트를 입력하여 유효한 사용자 이름 암호를 제공하지 않고 콘솔에 로그인할 수 있습니다.

5.2. AMQ Management Console 로그인 자격 증명 액세스

브로커 배포에 사용된 CR(사용자 정의 리소스) 인스턴스에 adminUseradminPassword 값을 지정하지 않으면 Operator는 이러한 인증 정보를 자동으로 생성하여 시크릿에 저장합니다. 기본 시크릿 이름은 < custom-resource-name> -credentials-secret (예: my-broker-deployment-credentials-secret ) 형식으로 되어 있습니다.

참고

adminUseradminPassword 값은 CR의 requireLogin 매개변수가 true 로 설정된 경우에만 관리 콘솔에 로그인해야 합니다.

requireLoginfalse 로 설정된 경우 사용자 이름과 암호를 입력하라는 메시지가 표시되면 텍스트를 입력하여 유효한 사용자 이름 암호를 제공하지 않고 콘솔에 로그인할 수 있습니다.

다음 절차에서는 로그인 자격 증명에 액세스하는 방법을 설명합니다.

절차

  1. OpenShift 프로젝트의 전체 시크릿 목록을 참조하십시오.

    1. OpenShift Container Platform 웹 콘솔에서 워크로드 시크릿 클릭합니다.
    2. 명령줄에서 다음을 수행합니다.

      $ oc get secrets
  2. 적절한 시크릿을 열어 Base64로 인코딩된 콘솔 로그인 자격 증명을 표시합니다.

    1. OpenShift Container Platform 웹 콘솔에서 해당 이름에 브로커 사용자 정의 리소스 인스턴스가 포함된 시크릿을 클릭합니다. YAML 탭을 클릭합니다.
    2. 명령줄에서 다음을 수행합니다.

      $ oc edit secret <my-broker-deployment-credentials-secret>
  3. 시크릿에서 값을 디코딩하려면 다음과 같은 명령을 사용합니다.

    $ echo 'dXNlcl9uYW1l' | base64 --decode
    console_admin

추가 리소스

6장. Operator 기반 브로커 배포 업그레이드

이 섹션의 절차에서는 업그레이드 방법을 보여줍니다.

  • OpenShift CLI(명령줄 인터페이스) 및 OperatorHub를 모두 사용하는 AMQ Broker Operator 버전
  • Operator 기반 브로커 배포의 브로커 컨테이너 이미지

6.1. 사전 준비 사항

이 섹션에서는 Operator 기반 브로커 배포를 위해 Operator 및 브로커 컨테이너 이미지를 업그레이드하기 전에 몇 가지 중요한 고려 사항에 대해 설명합니다.

  • OpenShift CLI(명령줄 인터페이스) 또는 OperatorHub를 사용하여 Operator를 업그레이드하려면 OpenShift 클러스터에 대한 클러스터 관리자 권한이 필요합니다.
  • 원래 CLI를 사용하여 Operator 를 설치한 경우 CLI를 사용하여 Operator를 업그레이드해야 합니다. 원래 OperatorHub를 사용하여 Operator를 설치하는 경우(즉, OpenShift Container Platform 웹 콘솔의 프로젝트의 Operators 에 설치된 Operator)에도 OperatorHub를 사용하여 Operator를 업그레이드해야 합니다. 이러한 업그레이드 방법에 대한 자세한 내용은 다음을 참조하십시오.

  • redeliveryDelayMultiplierredeliveryCollisionAvoidanceFactor 속성이 7.8.x 또는 7.9.x 배포의 주요 브로커 CR에 구성된 경우 새 Operator는 7.10.x로 업그레이드한 후 CR을 조정할 수 없습니다. 두 속성의 데이터 유형이 float에서 7.10.x에서 문자열로 변경되었기 때문에 조정이 실패합니다.

    spec.deploymentPlan.address>-<.addressSetting 요소에서 redeliveryDelayMultiplierredeliveryCollisionAvoidanceFactor 속성을 삭제하여 이 문제를 해결할 수 있습니다. 그런 다음 brokerProperties 요소에서 특성을 구성합니다. 예를 들면 다음과 같습니다.

    spec:
        ...
        brokerProperties:
        - "addressSettings.#.redeliveryMultiplier=2.1"
        - "addressSettings.#.redeliveryCollisionAvoidanceFactor=1.2"
    참고

    brokerProperties 요소에서 삭제한 redeliveryDelayMultiplier 특성 이름 대신 redeliveryMultiplier 특성 이름을 사용합니다.

  • 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를 처음 설치하는 경우에만 Operator를 업그레이드해야 합니다. 원래 OperatorHub를 사용하여 Operator를 설치하는 경우 (즉, OpenShift Container Platform 웹 콘솔의 프로젝트에 InstalledOperators )에 표시되는 경우 OperatorHub를 사용하여 Operator를 업그레이드해야 합니다. OperatorHub를 사용하여 Operator를 업그레이드하는 방법을 알아보려면 6.3절. “OperatorHub를 사용하여 Operator 업그레이드” 를 참조하십시오.

6.2.2. CLI를 사용하여 Operator 업그레이드

OpenShift CLI(명령줄 인터페이스)를 사용하여 Operator를 AMQ Broker 7.10의 최신 버전으로 업그레이드할 수 있습니다.

절차

  1. 웹 브라우저에서 AMQ Broker 7.10.6 패치소프트웨어 다운로드 페이지로 이동합니다.
  2. 버전 드롭다운 목록의 값이 7.10.6 으로 설정되고 릴리스 탭이 선택되어 있는지 확인합니다.
  3. AMQ Broker 7.10.6 Operator 설치 및 예제 파일 옆에 있는 Download 를 클릭합니다.

    amq-broker-operator-7.10.6-ocp-install-examples.zip 압축 아카이브가 자동으로 시작됩니다.

  4. 다운로드가 완료되면 아카이브를 선택한 설치 디렉터리로 이동합니다. 다음 예제에서는 아카이브를 ~/broker/operator 라는 디렉터리로 이동합니다.

    $ mkdir ~/broker/operator
    $ mv amq-broker-operator-7.10.6-ocp-install-examples.zip ~/broker/operator
  5. 선택한 설치 디렉터리에서 아카이브의 콘텐츠를 추출합니다. 예를 들면 다음과 같습니다.

    $ cd ~/broker/operator
    $ unzip amq-broker-operator-operator-7.10.6-ocp-install-examples.zip
  6. 기존 Operator 배포가 포함된 프로젝트의 관리자로 OpenShift Container Platform에 로그인합니다.

    $ oc login -u <user>
  7. Operator 버전을 업그레이드하려는 OpenShift 프로젝트로 전환합니다.

    $ oc project <project-name>
  8. 다운로드 및 추출한 최신 Operator 아카이브의 배포 디렉터리에서 operator.yaml 파일을 엽니다.

    참고

    operator.yaml 파일에서 Operator는SHA( Secure Hash Algorithm ) 값으로 표시되는 이미지를 사용합니다. 숫자 기호(#) 기호로 시작하는 주석 행은 SHA 값이 특정 컨테이너 이미지 태그에 해당함을 나타냅니다.

  9. 이전 Operator 배포의 operator.yaml 파일을 엽니다. 이전 구성에서 지정한 기본값이 아닌 값이 operator.yaml 구성 파일에 복제되었는지 확인합니다.
  10. operator.yaml 파일에서 Operator 이름은 기본적으로 controller-manager 로 지정됩니다. controller-manager 의 모든 인스턴스를 amq-broker-operator 로 교체하고 이전 버전의 Operator 이름인 amq-broker-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 미터링 레이블을 삭제합니다. 이 레이블은 7.10.0의 Operator의 StatefulSet 선택기에 잘못 추가되었습니다. Operator가 StatefulSet을 삭제하면 기존 브로커 Pod도 삭제하여 일시적인 브로커 중단이 발생합니다. 중단을 방지하려면 다음 단계를 완료하여 브로커 Pod를 삭제하지 않고 Operator 및 StatefulSet을 삭제합니다.

    1. Operator를 삭제합니다.

      $ oc delete -f deploy/operator.yaml
    2. 브로커 Pod를 분리하려면 --cascade=orphan 옵션을 사용하여 StatefulSet을 삭제합니다. 고립된 브로커 Pod는 StatefulSet이 삭제된 후에도 계속 실행됩니다.

      $ oc delete statefulset <statefulset-name> --cascade=orphan
  13. AMQ Broker Operator 7.10.0 또는 7.10.1에서 업그레이드하는 경우 기본 브로커 CR에 application 또는 ActiveMQArtemis 라는 레이블이 deploymentPlan.labels 속성에 구성되어 있는지 확인합니다.

    이러한 라벨은 Operator가 Pod에 라벨을 할당하도록 예약되며 7.10.1 이후 사용자 정의 라벨로 허용되지 않습니다. 이러한 사용자 정의 라벨이 기본 브로커 CR에 구성된 경우 Pod에 Operator 할당 라벨을 사용자 정의 라벨로 덮어씁니다. 이러한 사용자 정의 라벨 중 하나가 기본 브로커 CR에 구성된 경우 다음 단계를 완료하여 Pod에서 올바른 라벨을 복원하고 CR에서 라벨을 제거합니다.

    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 속성에서 애플리케이션ActiveMQArtemis 레이블을 삭제합니다.

      1. 브로커 배포의 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        oc login -u <user> -p <password> --server=<host:port>
      2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
      3. CR의 deploymentPlan.labels 속성에서 application 또는 ActiveMQArtemis 라는 사용자 지정 레이블을 삭제합니다.
      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를 처음 설치한 경우에만 Operator를 업그레이드해야 합니다(즉, OpenShift Container Platform 웹 콘솔의 프로젝트의 Operators 에 Operator 설치됨 ). 반대로 원래 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 웹 콘솔에서 해당 상태를 업데이트할 수 없습니다. 실행 중인 브로커 Pod의 로그 탭을 클릭하면 '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 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 프로젝트에서 기존 AMQ Broker Operator를 설치 제거합니다.
  3. 왼쪽 탐색 메뉴에서 Operators(운영자) InstalledOperators 를 클릭합니다.
  4. 페이지 상단에 있는 프로젝트 드롭다운 메뉴에서 Operator를 설치 제거할 프로젝트를 선택합니다.
  5. 설치하려는 Red Hat Integration - AMQ Broker 인스턴스를 찾습니다.
  6. Operator 인스턴스의 경우 오른쪽에 있는 More Options 아이콘(세 개의 수직 점)을 클릭합니다. Operator 설치 제거를 선택합니다.
  7. 확인 대화 상자에서 제거를 클릭합니다.
  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. 7.10.0에서 7.10.x로 Operator 업그레이드

AMQ Broker Operator 7.10.0에서 업그레이드하려면 다음 절차를 사용하십시오.

절차

  1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 프로젝트에서 기존 AMQ Broker Operator를 설치 제거합니다.

    1. 왼쪽 탐색 메뉴에서 Operators(운영자) InstalledOperators 를 클릭합니다.
    2. 페이지 상단에 있는 프로젝트 드롭다운 메뉴에서 Operator를 설치 제거할 프로젝트를 선택합니다.
    3. 설치하려는 Red Hat Integration - AMQ Broker 인스턴스를 찾습니다.
    4. Operator 인스턴스의 경우 오른쪽에 있는 More Options 아이콘(세 개의 수직 점)을 클릭합니다. Operator 설치 제거를 선택합니다.
    5. 확인 대화 상자에서 제거를 클릭합니다.
  3. 7.10.0 Operator를 업그레이드할 때 새 Operator는 StatefulSet을 삭제하여 사용자 정의 및 Operator 미터링 라벨을 삭제합니다. 이 라벨은 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. 브로커 Pod를 분리하려면 --cascade=orphan 옵션을 사용하여 StatefulSet을 삭제합니다. 고립된 브로커 Pod는 StatefulSet이 삭제된 후에도 계속 실행됩니다.

      $ oc delete statefulset <statefulset-name> --cascade=orphan
  4. 기본 브로커 CR에 deploymentPlan.labels 속성에 구성된 application 또는 ActiveMQArtemis 라는 레이블이 있는지 확인합니다.

    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 속성에서 애플리케이션ActiveMQArtemis 레이블을 삭제합니다.

      1. OpenShift 명령줄 인터페이스 사용:

        1. 브로커 배포의 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

          oc login -u <user> -p <password> --server=<host:port>
        2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
        3. CR의 deploymentPlan.labels 요소에서 application 또는 ActiveMQArtemis 라는 사용자 지정 레이블을 삭제합니다.
        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 웹 콘솔 사용:

        1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
        2. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
        3. ActiveMQArtemis CRD를 클릭합니다.
        4. Instances 탭을 클릭합니다.
        5. 브로커 배포의 인스턴스를 클릭합니다.
        6. YAML 탭을 클릭합니다.

          콘솔에서 YAML 편집기가 열리고 CR 인스턴스를 구성할 수 있습니다.

        7. CR의 deploymentPlan.labels 요소에서 application 또는 ActiveMQArtemis 라는 사용자 지정 레이블을 삭제합니다.
        8. 저장을 클릭합니다.
  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. 7.10.1에서 7.10.x로 Operator 업그레이드

AMQ Broker Operator 7.10.1에서 업그레이드하려면 다음 절차를 사용하십시오.

절차

  1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 기본 브로커 CR에 deploymentPlan.labels 속성에 구성된 application 또는 ActiveMQArtemis 라는 레이블이 있는지 확인합니다.

    이러한 라벨은 Operator가 Pod에 라벨을 할당하도록 예약되어 있으며 7.10.1 이후에는 사용할 수 없습니다. 이러한 사용자 정의 라벨이 기본 브로커 CR에 구성된 경우 Pod에 Operator 할당 라벨을 사용자 정의 라벨로 덮어씁니다.

  3. 이러한 사용자 정의 라벨이 기본 브로커 CR에 구성되지 않은 경우 OperatorHub를 사용하여 AMQ Broker 7.10용 최신 버전의 Operator를 설치합니다. 자세한 내용은 3.3.2절. “OperatorHub에서 Operator 배포”의 내용을 참조하십시오.
  4. 이러한 사용자 정의 라벨 중 하나가 기본 브로커 CR에 구성된 경우 다음 단계를 완료하여 기존 Operator를 제거하고, 올바른 Pod 라벨을 복원하며, 새 Operator를 설치하기 전에 CR에서 라벨을 제거합니다.

    참고

    Operator를 설치 제거하여 Operator에서 StatefulSet을 삭제하지 않고 사용자 정의 레이블을 제거할 수 있습니다. 이로 인해 기존 브로커 Pod도 삭제되고 일시적으로 브로커 중단이 발생합니다.

    1. 프로젝트에서 기존 AMQ Broker Operator를 설치 제거합니다.

      1. 왼쪽 탐색 메뉴에서 Operators(운영자) InstalledOperators 를 클릭합니다.
      2. 페이지 상단에 있는 프로젝트 드롭다운 메뉴에서 Operator를 설치 제거할 프로젝트를 선택합니다.
      3. 설치하려는 Red Hat Integration - AMQ Broker 인스턴스를 찾습니다.
      4. Operator 인스턴스의 경우 오른쪽에 있는 More Options 아이콘(세 개의 수직 점)을 클릭합니다. Operator 설치 제거를 선택합니다.
      5. 확인 대화 상자에서 제거를 클릭합니다.
    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 속성에서 애플리케이션ActiveMQArtemis 레이블을 삭제합니다.

      1. OpenShift 명령줄 인터페이스 사용:

        1. 브로커 배포의 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

          oc login -u <user> -p <password> --server=<host:port>
        2. 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 이라는 샘플 CR 파일을 엽니다.
        3. CR의 deploymentPlan.labels 속성에서 application 또는 ActiveMQArtemis 라는 사용자 지정 레이블을 삭제합니다.
        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 웹 콘솔 사용:

        1. 브로커 배포를 위해 프로젝트에 CR을 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
        2. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
        3. ActiveMQArtemis CRD를 클릭합니다.
        4. Instances 탭을 클릭합니다.
        5. 브로커 배포의 인스턴스를 클릭합니다.
        6. YAML 탭을 클릭합니다.

          콘솔에서 YAML 편집기가 열리고 CR 인스턴스를 구성할 수 있습니다.

        7. CR의 deploymentPlan.labels 속성에서 application 또는 ActiveMQArtemis 라는 사용자 지정 레이블을 삭제합니다.
        8. 저장을 클릭합니다.
  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 속성이 이미 true 로 설정되고 spec.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. 브로커 배포를 위해 프로젝트에 CR을 편집하고 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

        $ oc login -u <user> -p <password> --server=<host:port>
      2. 텍스트 편집기에서 브로커 배포에 사용한 CR 파일을 엽니다. 예를 들어 이전에 다운로드 및 추출한 Operator 설치 아카이브의 deploy/crs 디렉터리에 포함된 broker_activemqartemis_cr.yaml 파일이 될 수 있습니다.
    2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 편집하고 배포할 수 있는 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 왼쪽 창에서 AdministrationCustom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.
      5. 프로젝트 네임스페이스에 해당하는 CR 인스턴스를 찾습니다.
      6. CR 인스턴스의 경우 오른쪽에 있는 More Options 아이콘(여러 개의 수직점)을 클릭합니다. Edit ActiveMQArtemis 를 선택합니다.

        콘솔에서 YAML 편집기가 열리고 CR 인스턴스를 편집할 수 있습니다.

  2. 브로커 컨테이너 이미지를 업그레이드할 AMQ Broker 버전을 지정하려면 CR의 spec.version 속성 값을 설정합니다. 예를 들면 다음과 같습니다.

    spec:
        version: 7.10.0
        ...
  3. CR의 spec 섹션에서 upgrades 섹션을 찾습니다. 이 섹션이 CR에 아직 포함되지 않은 경우 추가합니다.

    spec:
        version: 7.10.0
        ...
        upgrades:
  4. upgrades 섹션에 enabledminor 속성이 포함되어 있는지 확인합니다.

    spec:
        version: 7.10.0
        ...
        upgrades:
            enabled:
            minor:
  5. AMQ Broker의 지정된 버전을 기반으로 브로커 컨테이너 이미지를 업그레이드하려면 enabled 속성 값을 true 로 설정합니다.

    spec:
        version: 7.10.0
        ...
        upgrades:
            enabled: true
            minor:
  6. 브로커의 업그레이드 동작을 정의하려면 마이너 속성 값을 설정합니다.

    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 웹 콘솔 사용:

      1. CR 편집을 마쳤으면 저장 을 클릭합니다.

    CR 변경을 적용하면 Operator에서 먼저 spec.version 에 지정된 AMQ Broker 버전으로 업그레이드할 수 있는지 확인합니다. 업그레이드할 잘못된 버전의 AMQ Broker를 지정한 경우 (예: 아직 사용할 수 없는 버전) Operator는 경고 메시지를 기록하여 추가 작업을 수행하지 않습니다.

    그러나 지정된 버전으로 업그레이드할 수 있고 upgrades.enabledupgrades.minor 에 지정된 값을 사용할 수 있는 경우 Operator 배포의 각 브로커를 업그레이드하여 새 AMQ Broker 버전에 해당하는 브로커 컨테이너 이미지를 사용합니다.

    Operator에서 사용하는 브로커 컨테이너 이미지는 Operator 배포의 operator.yaml 구성 파일의 환경 변수에 정의됩니다. 환경 변수 이름에는 AMQ Broker 버전의 식별자가 포함됩니다. 예를 들어 환경 변수 RELATED_IMAGE_ActiveMQ_Artemis_Broker_Kubernetes_7100 은 AMQ Broker 7.10.6에 해당합니다.

    Operator가 CR 변경을 적용하면 각 Pod가 지정된 이미지 버전을 사용하도록 배포의 각 브로커 Pod를 다시 시작합니다. 배포에 여러 브로커가 있는 경우 한 번에 하나의 브로커 Pod만 종료하고 다시 시작합니다.

추가 리소스

7장. 브로커 모니터링

7.1. Fuse 콘솔에서 브로커 보기

AMQ Management Console 대신 OpenShift에 Fuse Console을 사용하도록 Operator 기반 브로커 배포를 구성할 수 있습니다. 브로커 배포를 적절하게 구성한 경우 Fuse Console은 브로커를 검색하여 전용 Artemis 탭에 표시합니다. AMQ 관리 콘솔에서 수행하는 것과 동일한 브로커 런타임 데이터를 볼 수 있습니다. 주소 및 큐 생성과 같은 동일한 기본 관리 작업을 수행할 수도 있습니다.

다음 절차에서는 브로커 배포에 대한 사용자 정의 리소스(CR) 인스턴스를 구성하여 OpenShift에서 배포 중 브로커를 검색하고 표시할 수 있도록 Fuse Console을 활성화하는 방법을 설명합니다.

사전 요구 사항

  • OpenShift용 Fuse Console은 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(역할 기반 액세스 제어)를 활성화할지 여부를 지정합니다. Fuse Console이 자체 역할 기반 액세스 제어를 사용하므로 Fuse Console을 사용하려면 false설정해야 합니다.

    중요

    Fuse Console 사용을 활성화하려면 managementRBACEnabled 의 값을 false 로 설정하면 브로커의 관리에는 더 이상 권한 부여가 필요하지 않습니다. managementRBACEnabled 가 false로 설정되어 있는 동안에는 AMQ 관리 콘솔을 사용해서는 됩니다. 이는 브로커의 모든 관리 작업을 무단으로 사용하기 때문에 false 로 설정됩니다.

  3. CR 인스턴스를 저장합니다.
  4. 이전에 브로커 배포를 생성한 프로젝트로 전환합니다.

    $ oc project <project_name>
  5. 명령줄에서 변경 사항을 적용합니다.

    $ oc apply -f <path/to/custom_resource_instance>.yaml
  6. Fuse 콘솔에서 Fuse 애플리케이션을 보려면 온라인 탭을 클릭합니다. 실행 중인 브로커를 보려면 왼쪽 탐색 메뉴에서 Artemis 를 클릭합니다.

추가 리소스

7.2. Prometheus를 사용하여 브로커 런타임 메트릭 모니터링

다음 섹션에서는 OpenShift Container Platform에서 AMQ Broker에 대한 Prometheus 지표 플러그인을 구성하는 방법을 설명합니다. 플러그인을 사용하여 브로커 런타임 메트릭을 모니터링하고 저장할 수 있습니다. Grafana와 같은 그래픽 도구를 사용하여 Prometheus 플러그인이 수집하는 데이터의 고급 시각화 및 대시보드를 구성할 수도 있습니다.

참고

Prometheus 지표 플러그인을 사용하면 Prometheus 형식으로 브로커 지표를 수집하고 내보낼 수 있습니다. 그러나 Red Hat 은 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
지정된 큐에 현재 없는 메시지 수입니다. 여기에는 scheduled, paged, in-delivery 메시지가 포함됩니다.
artemis_durable_persistent_size
현재 지정된 큐에 있는 미완성 메시지의 영구 크기입니다. 여기에는 scheduled, paged, in-delivery 메시지가 포함됩니다.
artemis_messages_acknowledged
대기열이 생성된 이후 지정된 큐에서 확인되는 메시지 수입니다.
artemis_messages_added
큐가 생성된 이후 지정된 큐에 추가된 메시지 수입니다.
artemis_message_count
지정된 큐에 현재 메시지 수입니다. 여기에는 scheduled, paged, in-delivery 메시지가 포함됩니다.
artemis_messages_killed
큐가 생성된 이후 지정된 큐에서 삭제된 메시지 수입니다. 메시지가 구성된 최대 전달 시도 수를 초과하면 브로커가 메시지를 종료합니다.
artemis_messages_expired
큐가 생성된 이후 지정된 큐에서 만료된 메시지 수입니다.
artemis_persistent_size
현재 지정된 큐에 있는 모든 메시지의 영구 크기(아니요 및 비내화 가능)입니다. 여기에는 scheduled, paged, in-delivery 메시지가 포함됩니다.
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 지표 플러그인이 설치에 포함됩니다. 활성화하면 플러그인은 브로커에 대한 런타임 지표를 수집하고 이를 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

    지표 플러그인은 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 웹 콘솔에 로그인합니다.
  2. 웹 콘솔에서 HomeProjects (프로젝트) 를 클릭합니다. 브로커 배포가 포함된 프로젝트를 선택합니다.
  3. 프로젝트의 StatefulSets 또는 DeploymentConfigs를 보려면 WorkloadsStatefulSets 를 클릭합니다.
  4. 브로커 배포에 해당하는 StatefulSet 또는 DeploymentConfig를 클릭합니다.
  5. 브로커 배포의 환경 변수에 액세스하려면 환경 탭을 클릭합니다.
  6. AMQ_ENABLE_METRICS_PLUGIN 이라는 새 환경 변수를 추가합니다. 변수의 값을 true 로 설정합니다.

    AMQ_ENABLE_METRICS_PLUGIN 환경 변수를 설정하면 OpenShift에서 StatefulSet 또는 DeploymentConfig에서 각 브로커 포드를 재시작합니다. 배포에 Pod가 여러 개 있는 경우 OpenShift는 각 포드를 차례로 다시 시작합니다. 각 브로커 Pod가 다시 시작되면 해당 브로커의 Prometheus 플러그인이 브로커 런타임 메트릭을 수집하기 시작합니다.

7.2.4. 실행 중인 브로커 Pod에 대한 Prometheus 메트릭 액세스

다음 절차에서는 실행 중인 브로커 Pod에 대한 Prometheus 메트릭에 액세스하는 방법을 보여줍니다.

사전 요구 사항

절차

  1. 액세스할 메트릭이 있는 브로커 Pod의 경우 Pod를 AMQ Broker 관리 콘솔에 연결하기 위해 이전에 생성한 경로를 확인해야 합니다. 경로 이름은 메트릭에 액세스하는 데 필요한 URL의 일부를 형성합니다.

    1. NetworkingRoutes (경로) 를 클릭합니다.
    2. 선택한 브로커 Pod의 경우 Pod를 AMQ Broker 관리 콘솔에 연결하기 위해 생성된 경로를 확인합니다. Hostname 에서 표시되는 전체 URL을 기록해 둡니다. 예를 들면 다음과 같습니다.

      http://rte-console-access-pod1.openshiftdomain
  2. Prometheus 지표에 액세스하려면 웹 브라우저에 "/metrics" 가 추가된 이전에 명시된 경로 이름을 입력합니다. 예를 들면 다음과 같습니다.

    http://rte-console-access-pod1.openshiftdomain/metrics
참고

콘솔 구성에서 SSL을 사용하지 않는 경우 URL에 http 를 지정합니다. 이 경우 호스트 이름의 DNS 확인은 트래픽을 OpenShift 라우터의 포트 80으로 전달합니다. 콘솔 구성에서 SSL을 사용하는 경우 URL에 https 를 지정합니다. 이 경우 브라우저는 기본적으로 OpenShift 라우터의 443 포트로 설정됩니다. 이렇게 하면 OpenShift 라우터에서 기본적으로 수행하는 SSL 트래픽에 포트 443을 사용하는 경우 콘솔에 성공적으로 연결할 수 있습니다.

7.3. CloudEvent를 사용하여 브로커 런타임 데이터 모니터링

이 예제에서는 Jolokia REST 인터페이스를 사용하여 브로커를 모니터링하는 방법을 보여줍니다.

사전 요구 사항

절차

  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장. reference

8.1. 사용자 정의 리소스 구성 참조

CRD(Custom Resource Definition)는 Operator와 함께 배포된 사용자 정의 OpenShift 오브젝트의 구성 항목 스키마입니다. 해당 CR(사용자 정의 리소스) 인스턴스를 배포하면 CRD에 표시된 구성 항목의 값을 지정합니다.

다음 하위 섹션에서는 기본 브로커 CRD를 기반으로 사용자 정의 리소스 인스턴스에서 설정할 수 있는 구성 항목을 자세히 설명합니다.

8.1.1. 브로커 사용자 정의 리소스 구성 참조

기본 브로커 CRD를 기반으로 하는 CR 인스턴스를 사용하면 OpenShift 프로젝트에 배포할 브로커를 구성할 수 있습니다. 다음 표에서는 CR 인스턴스에서 구성할 수 있는 항목에 대해 설명합니다.

중요

별표(*)로 표시된 구성 항목은 배포하는 해당 사용자 정의 리소스(CR)에 필요합니다. 필수가 아닌 항목의 값을 명시적으로 지정하지 않으면 구성은 기본값을 사용합니다.

entry하위 항목설명 및 사용

adminUser*

 

브로커 및 관리 콘솔에 연결하는 데 필요한 관리자 이름입니다.

값을 지정하지 않으면 값이 자동으로 생성되어 시크릿에 저장됩니다. 기본 시크릿 이름의 형식은 < custom_resource_name> -credentials-secret 입니다. 예를 들면 my-broker-deployment-credentials-secret 입니다.

유형: 문자열

: my-user

기본값: 자동 생성, 임의 값

adminPassword*

 

브로커 및 관리 콘솔에 연결하는 데 필요한 관리자 암호입니다.

값을 지정하지 않으면 값이 자동으로 생성되어 시크릿에 저장됩니다. 기본 시크릿 이름의 형식은 < custom_resource_name> -credentials-secret 입니다. 예를 들면 my-broker-deployment-credentials-secret 입니다.

유형: 문자열

: my-password

기본값: 자동 생성, 임의 값

deploymentPlan*

 

브로커 배포 구성

 

image*

배포의 각 브로커에 사용되는 브로커 컨테이너 이미지의 전체 경로입니다.

CR에서 image 값을 명시적으로 지정할 필요는 없습니다. 기본값은 Operator 에서 사용할 적절한 이미지를 아직 결정하지 않았음을 나타냅니다.

Operator에서 사용할 브로커 컨테이너 이미지를 선택하는 방법에 대한 자세한 내용은 2.4절. “Operator에서 컨테이너 이미지를 선택하는 방법” 을 참조하십시오.

유형: 문자열

: registry.redhat.io/amq-broker-rhel8@sha256:a8b2a9364fd06c8e1c29b8f28d3e4844bf7840a62b67137b663c558982d4a3a3

기본값: 자리 표시자

 

크기*

배포에 생성할 브로커 Pod 수입니다.

값을 2 이상으로 지정하면 브로커 배포가 기본적으로 클러스터됩니다. 클러스터 사용자 이름과 암호는 자동으로 생성되며 기본적으로 adminUseradminPassword 와 동일한 시크릿에 저장됩니다.

유형: int

: 1

기본값: 2

 

requireLogin

브로커에 연결하는 데 로그인 인증 정보가 필요한지 여부를 지정합니다.

유형: 부울

: false

기본값: true

 

persistenceEnabled

배포에서 각 브로커 Pod에 저널 스토리지를 사용할지 여부를 지정합니다. true 로 설정하면 각 브로커 Pod에 PVC(영구 볼륨 클레임)를 사용하여 요청할 수 있는 사용 가능한 PV(영구 볼륨)가 필요합니다.

유형: 부울

: false

기본값: true

 

initImage

브로커를 구성하는 데 사용되는 init 컨테이너 이미지입니다.

사용자 정의 이미지를 제공하지 않는 한 CR에서 initImage 값을 명시적으로 지정할 필요가 없습니다.

Operator에서 사용할 기본 제공 Init Container 이미지를 선택하는 방법에 대한 자세한 내용은 2.4절. “Operator에서 컨테이너 이미지를 선택하는 방법” 을 참조하십시오.

사용자 지정 Init Container 이미지를 지정하는 방법에 대한 자세한 내용은 4.7절. “사용자 정의 Init Container 이미지 지정” 을 참조하십시오.

유형: 문자열

: registry.redhat.io/amq-broker-init-rhel8@sha256:35b7d96d5065f280a528626abd2c3df84e79cc93ab6bd8b8837af66c330f30f30

기본값: 지정되지 않음

 

journalType

비동기 I/O(AIO) 또는 비차단 I/O(NIO) 사용 여부를 지정합니다.

유형: 문자열

: aio

기본값: nio

 

messageMigration

브로커 배포의 의도적인 규모로 인해 브로커 Pod가 종료되면 브로커 클러스터에서 계속 실행 중인 다른 브로커 Pod로 메시지를 마이그레이션할지 여부를 지정합니다.

유형: 부울

: false

기본값: true

 

resources.limits.cpu

배포의 Pod에서 실행 중인 각 브로커 컨테이너에서 사용할 수 있는 최대 호스트 노드 CPU 양(밀리코어)입니다.

유형: 문자열

: "500m"

기본값: OpenShift Container Platform 버전에서 사용하는 것과 동일한 기본값을 사용합니다. 클러스터 관리자를 참조하십시오.

 

resources.limits.memory

배포의 Pod에서 실행 중인 각 브로커 컨테이너가 사용할 수 있는 최대 호스트 노드 메모리(바이트)입니다. 바이트 표기법(예: K, M, G) 또는 이에 해당하는 바이너리(Ki, Mi, Gi)를 지원합니다.

유형: 문자열

: "1024M"

기본값: OpenShift Container Platform 버전에서 사용하는 것과 동일한 기본값을 사용합니다. 클러스터 관리자를 참조하십시오.

 

resources.requests.cpu

배포의 Pod에서 실행 중인 각 브로커 컨테이너가 명시적으로 요청하는 호스트 노드 CPU의 양입니다.

유형: 문자열

: "250m"

기본값: OpenShift Container Platform 버전에서 사용하는 것과 동일한 기본값을 사용합니다. 클러스터 관리자를 참조하십시오.

 

resources.requests.memory

배포의 각 브로커 컨테이너가 명시적으로 요청하는 호스트 노드 메모리(바이트)의 양입니다. 바이트 표기법(예: K, M, G) 또는 이에 해당하는 바이너리(Ki, Mi, Gi)를 지원합니다.

유형: 문자열

: "512M"

기본값: OpenShift Container Platform 버전에서 사용하는 것과 동일한 기본값을 사용합니다. 클러스터 관리자를 참조하십시오.

 

storage.size

배포의 각 브로커에 영구 스토리지에 필요한 PVC(영구 볼륨 클레임)의 크기(바이트)입니다. 이 속성은 persistenceEnabledtrue 로 설정된 경우에만 적용됩니다. 지정한 값은 단위를 포함해야 합니다. 바이트 표기법(예: K, M, G) 또는 이에 해당하는 바이너리(Ki, Mi, Gi)를 지원합니다.

유형: 문자열

: 4Gi

기본값: 2Gi

 

jolokiaAgentEnabled

배포의 브로커에 대해 Jolokia JVM 에이전트가 활성화되어 있는지 여부를 지정합니다. 이 속성 값을 true 로 설정하면 Fuse Console에서 브로커의 런타임 데이터를 검색하고 표시할 수 있습니다.

유형: 부울

: true

기본값: false

 

managementRBACEnabled

배포 브로커에 대해 RBAC(역할 기반 액세스 제어)를 활성화할지 여부를 지정합니다. Fuse Console을 사용하려면 Fuse Console이 자체 역할 기반 액세스 제어를 사용하므로 값을 false 로 설정해야 합니다.

유형: 부울

: false

기본값: true

 

유사성

Pod에 대한 예약 제약 조건을 지정합니다. 유사성 속성에 대한 자세한 내용은 OpenShift Container Platform 설명서의 속성을 참조하십시오.

 

허용 오차

Pod의 톨러레이션을 지정합니다. 허용 오차 속성에 대한 자세한 내용은 OpenShift Container Platform 설명서의 속성을 참조하십시오.

 

nodeSelector

해당 노드에서 예약할 Pod의 노드의 라벨과 일치하는 라벨을 지정합니다.

 

storageClassName

PVC(영구 볼륨 클레임)에 사용할 스토리지 클래스의 이름을 지정합니다. 스토리지 클래스는 관리자가 사용 가능한 스토리지를 설명하고 분류하는 방법을 제공합니다. 예를 들어 스토리지 클래스에는 특정 서비스 품질 수준, 백업 정책 또는 연결된 기타 관리 정책이 있을 수 있습니다.

유형: 문자열

: gp3

기본값: 지정되지 않음

 

livenessProbe

실행 중인 브로커 컨테이너에 정기적인 상태 점검을 구성하여 브로커가 실행 중인지 확인합니다. 활성 프로브 속성에 대한 자세한 내용은 OpenShift Container Platform 설명서의 속성을 참조하십시오.

 

readinessProbe

실행 중인 브로커 컨테이너에 정기적인 상태 점검을 구성하여 브로커가 네트워크 트래픽을 수락하는지 확인합니다. 준비 상태 프로브 속성에 대한 자세한 내용은 OpenShift Container Platform 설명서의 속성을 참조하십시오.

 

labels

브로커 Pod에 라벨을 할당합니다.

유형: 문자열

: location: "production"

기본값: 지정되지 않음

console

 

브로커 관리 콘솔 구성.

 

expose

배포의 각 브로커에 대해 관리 콘솔 포트를 노출할지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

sslEnabled

관리 콘솔 포트에서 SSL 사용 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

sslSecret

브로커 키 저장소, 신뢰 저장소 및 해당 암호(Base64로 인코딩된)가 저장되는 시크릿입니다. sslSecret 의 값을 지정하지 않으면 콘솔에서 기본 보안 이름을 사용합니다. 기본 시크릿 이름은 < custom_resource_name> -console-secret 형식으로 되어 있습니다. 이 속성은 sslEnabled 속성이 true 로 설정된 경우에만 적용됩니다.

유형: 문자열

: my-broker-deployment-console-secret

기본값: 지정되지 않음

 

podSecurity.serviceAccountName

브로커 Pod의 서비스 계정 이름을 지정합니다.

유형: 문자열

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

수락자의 이름입니다.

유형: 문자열

: my-acceptor

기본값: 해당 없음

 

port

acceptor 인스턴스에 사용할 포트 번호입니다.

유형: int

: 5672

기본값: 첫 번째 수락자의 경우 61626입니다. 그런 다음 기본값은 사용자가 정의한 이후의 모든 수락자에 대해 10씩 증가합니다.

 

프로토콜

acceptor 인스턴스에서 활성화할 메시징 프로토콜입니다.

유형: 문자열

: amqp,core

기본값: 모두

 

sslEnabled

어셉터 포트에서 SSL이 활성화되었는지 여부를 지정합니다. true 로 설정하는 경우 sslSecret 에 지정된 보안 이름을 TLS/SSL에 필요한 인증 정보를 찾습니다.

유형: 부울

: true

기본값: false

 

sslSecret

브로커 키 저장소, 신뢰 저장소 및 해당 암호(Base64로 인코딩된)가 저장되는 시크릿입니다.

sslSecret 의 사용자 정의 보안 이름을 지정하지 않으면 acceptor에서 기본 보안 이름을 가정합니다. 기본 시크릿 이름은 < custom_resource_name> 형식 - <acceptor_name> -secret 입니다.

acceptor가 기본 이름을 가정하더라도 항상 이 시크릿을 직접 생성해야 합니다.

유형: 문자열

: my-broker-deployment-my-acceptor-secret

기본값: <custom_resource_name> - <acceptor_name&gt; -secret

 

enabledCipherSuites

TLS/SSL 통신에 사용할 암호화 제품군의 쉼표로 구분된 목록입니다.

클라이언트 애플리케이션에서 지원하는 가장 안전한 암호화 제품군을 지정합니다. 쉼표로 구분된 목록을 사용하여 브로커와 클라이언트에 공통적인 암호화 제품군 세트를 지정하거나 암호화 제품군을 지정하지 않으면 브로커 및 클라이언트가 사용할 암호화 제품군을 상호 협상합니다. 지정할 암호화 제품군을 모르는 경우 먼저 디버그 모드에서 실행 중인 클라이언트와 broker-client 연결을 설정하여 브로커와 클라이언트 모두에 공통된 암호화 제품군을 확인하는 것이 좋습니다. 그런 다음 브로커에서 enabledCipherSuites 를 구성합니다.

유형: 문자열

기본값: 지정되지 않음

 

keyStoreProvider

브로커가 사용하는 키 저장소 공급자의 이름입니다.

유형: 문자열

: SunJCE

기본값: 지정되지 않음

 

trustStoreProvider

브로커가 사용하는 신뢰 저장소 공급자의 이름입니다.

유형: 문자열

: SunJCE

기본값: 지정되지 않음

 

trustStoreType

브로커가 사용하는 신뢰 저장소 유형입니다.

유형: 문자열

: JCEKS

기본값: JKS

 

enabledProtocols

TLS/SSL 통신에 사용할 프로토콜의 쉼표로 구분된 목록입니다.

유형: 문자열

: TLSv1,TLSv1.1,TLSv1.2

기본값: 지정되지 않음

 

needClientAuth

브로커가 클라이언트에 어셉터에 양방향 TLS가 필요한지 여부를 지정합니다. 이 속성은 wantClientAuth 를 덮어씁니다.

유형: 부울

: true

기본값: 지정되지 않음

 

wantClientAuth

브로커가 클라이언트에 허용기에서 양방향 TLS가 요청 되었지만 필수는 아님을 알릴지 여부를 지정합니다. 이 속성은 needClientAuth 로 재정의됩니다.

유형: 부울

: true

기본값: 지정되지 않음

 

verifyHost

클라이언트 인증서의 CN(Common Name)을 호스트 이름과 비교할지 여부를 지정하여 해당 인증서가 일치하는지 확인합니다. 이 옵션은 양방향 TLS를 사용하는 경우에만 적용됩니다.

유형: 부울

: true

기본값: 지정되지 않음

 

sslProvider

SSL 공급자가 JDK인지 OPENSSL인지 지정합니다.

유형: 문자열

: OPENSSL

기본값: JDK

 

sniHost

들어오는 연결의 server_name 확장과 일치하는 정규식입니다. 이름이 일치하지 않으면 수락자에 대한 연결이 거부됩니다.

유형: 문자열

: some_regular_expression

기본값: 지정되지 않음

 

expose

OpenShift Container Platform 외부의 클라이언트에 어셉터를 노출할지 여부를 지정합니다.

OpenShift 외부의 클라이언트에 어셉터를 노출하면 Operator는 배포의 각 브로커 포드에 대해 전용 서비스 및 경로를 자동으로 생성합니다.

유형: 부울

: true

기본값: false

 

anycastPrefix

클라이언트가 anycast 라우팅 유형을 사용해야 함을 지정하는 데 사용하는 접두사입니다.

유형: 문자열

: jms.queue

기본값: 지정되지 않음

 

multicastPrefix

클라이언트에서 멀티 캐스트 라우팅 유형을 사용하도록 지정하는 접두사입니다.

유형: 문자열

: /topic/

기본값: 지정되지 않음

 

connectionsAllowed

수락자에서 허용되는 연결 수입니다. 이 제한에 도달하면 DEBUG 메시지가 로그에 발행되고 연결이 거부됩니다. 사용 중인 클라이언트 유형에 따라 연결이 거부될 때 수행되는 작업이 결정됩니다.

유형: 정수

: 2

기본값: 0 (무제한 연결)

 

amqpMinLargeMessageSize

브로커가 AMQP 메시지를 큰 메시지로 처리하는 데 필요한 최소 메시지 크기(바이트)입니다. AMQP 메시지 크기가 이 값과 같거나 큰 경우 브로커는 메시지 저장을 위해 브로커가 사용하는 PV(영구 볼륨)의 큰 메시지 디렉터리(/opt/ <custom_resource_name> /data/large- anchor , 기본적으로)에 메시지를 저장합니다. 값을 -1 로 설정하면 AMQP 메시지에 대한 큰 메시지 처리가 비활성화됩니다.

유형: 정수

: 204800

기본값: 102400 (100 KB)

 

BindToAllInterfaces

true로 설정하면 Pod의 내부 IP 주소 대신 0.0.0.0 IP 주소로 브로커 어셉터를 구성합니다. 브로커 어셉터에 0.0.0.0 IP 주소가 있으면 Pod에 구성된 모든 인터페이스에 바인딩되고 클라이언트는 OpenShift Container Platform port-forwarding을 사용하여 트래픽을 브로커로 보낼 수 있습니다. 일반적으로 이 구성을 사용하여 서비스를 디버그합니다. port-forwarding에 대한 자세한 내용은 OpenShift Container Platform 설명서의 컨테이너의 애플리케이션에 액세스하는 데 포트 전달을 참조하십시오.

참고

포트 전달을 잘못 사용하는 경우 환경에 보안 위험이 발생할 수 있습니다. 가능한 경우 Red Hat은 프로덕션 환경에서 포트 전달을 사용하지 않는 것이 좋습니다.

유형: 부울

: true

기본값: false

connectors.connector

 

단일 커넥터 구성 인스턴스입니다.

 

name*

커넥터의 이름입니다.

유형: 문자열

: my-connector

기본값: 해당 없음

 

type

생성할 커넥터 유형; tcp 또는 vm.

유형: 문자열

: vm

기본값: tcp

 

host*

연결할 호스트 이름 또는 IP 주소입니다.

유형: 문자열

: 192.168.0.58

기본값: 지정되지 않음

 

포트*

커넥터 인스턴스에 사용할 포트 번호입니다.

유형: int

: 22222

기본값: 지정되지 않음

 

sslEnabled

커넥터 포트에서 SSL이 활성화되었는지 여부를 지정합니다. true 로 설정하는 경우 sslSecret 에 지정된 보안 이름을 TLS/SSL에 필요한 인증 정보를 찾습니다.

유형: 부울

: true

기본값: false

 

sslSecret

브로커 키 저장소, 신뢰 저장소 및 해당 암호(Base64로 인코딩된)가 저장되는 시크릿입니다.

sslSecret 의 사용자 정의 시크릿 이름을 지정하지 않으면 커넥터는 기본 보안 이름을 가정합니다. 기본 시크릿 이름은 < custom_resource_name> 형식 - <connector_name> -secret 입니다.

커넥터가 기본 이름을 가정하더라도 항상 이 시크릿을 직접 생성해야 합니다.

유형: 문자열

: my-broker-deployment-my-connector-secret

기본값: <custom_resource_name> - <connector_name&gt; -secret

 

enabledCipherSuites

TLS/SSL 통신에 사용할 암호화 제품군의 쉼표로 구분된 목록입니다.

유형: 문자열

참고: 커넥터의 경우 암호화 제품군 목록을 지정하지 않는 것이 좋습니다.

기본값: 지정되지 않음

 

keyStoreProvider

브로커가 사용하는 키 저장소 공급자의 이름입니다.

유형: 문자열

: SunJCE

기본값: 지정되지 않음

 

trustStoreProvider

브로커가 사용하는 신뢰 저장소 공급자의 이름입니다.

유형: 문자열

: SunJCE

기본값: 지정되지 않음

 

trustStoreType

브로커가 사용하는 신뢰 저장소 유형입니다.

유형: 문자열

: JCEKS

기본값: JKS

 

enabledProtocols

TLS/SSL 통신에 사용할 프로토콜의 쉼표로 구분된 목록입니다.

유형: 문자열

: TLSv1,TLSv1.1,TLSv1.2

기본값: 지정되지 않음

 

needClientAuth

브로커가 클라이언트에 커넥터에 양방향 TLS가 필요한지 여부를 지정합니다. 이 속성은 wantClientAuth 를 덮어씁니다.

유형: 부울

: true

기본값: 지정되지 않음

 

wantClientAuth

브로커가 커넥터에 양방향 TLS가 요청 되었지만 필수는 아님에 대해 클라이언트에 알릴지 여부를 지정합니다. 이 속성은 needClientAuth 로 재정의됩니다.

유형: 부울

: true

기본값: 지정되지 않음

 

verifyHost

클라이언트 인증서의 CN(Common Name)을 호스트 이름과 비교할지 여부를 지정하여 일치하는지 확인합니다. 이 옵션은 양방향 TLS를 사용하는 경우에만 적용됩니다.

유형: 부울

: true

기본값: 지정되지 않음

 

sslProvider

SSL 공급자가 JDK 인지 OPENSSL 인지 지정합니다.

유형: 문자열

: OPENSSL

기본값: JDK

 

sniHost

나가는 연결의 server_name 확장 기능과 일치하는 정규식입니다. 이름이 일치하지 않으면 커넥터 연결이 거부됩니다.

유형: 문자열

: 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에 지정된 주소로 바꿉니다. 최종 병합 구성은 CR에 지정된 구성과 정확히 일치합니다.

유형: 문자열

: replace_all

기본값: merge_all

addressSettings.addressSetting

 

일치하는 주소 또는 주소 집합에 대한 주소 설정입니다.

 

addressFullPolicy

maxSizeBytes 로 구성된 주소가 가득 찼을 때 발생하는 상황을 지정합니다. 사용 가능한 정책은 다음과 같습니다.

PAGE
전체 주소로 전송된 메시지는 디스크로 호출됩니다.
DROP
전체 주소로 전송된 메시지는 자동으로 삭제됩니다.
FAIL
전체 주소로 전송된 메시지가 삭제되고 메시지 생산자가 예외를 받습니다.
BLOCK

메시지 생산자는 추가 메시지를 보내려고 할 때 차단됩니다.

BLOCK 정책은 해당 프로토콜이 흐름 제어를 지원하므로 AMQP, OpenECDHEre 및 Core Protocol에만 작동합니다.

유형: 문자열

: DROP

기본값: PAGE

 

autoCreateAddresses

클라이언트가 메시지를 보낼 때 브로커가 주소를 자동으로 생성할지, 또는 존재하지 않는 주소에 바인딩된 대기열인 메시지를 사용하려고 할 때 지정합니다.

유형: 부울

: false

기본값: true

 

autoCreateDeadLetterResources

브로커가 배달되지 않은 메시지를 수신하기 위해 배달 못 한 주소 및 대기열을 자동으로 생성할지 여부를 지정합니다.

매개 변수가 true 로 설정된 경우 브로커는 배달 못 한 주소 및 관련된 배달 못 한 큐를 자동으로 생성합니다. 자동 생성된 주소의 이름은 deadLetterAddress 에 지정한 값과 일치합니다.

유형: 부울

: true

기본값: false

 

autoCreateExpiryResources

브로커가 만료된 메시지를 수신할 주소와 큐를 자동으로 생성할지 여부를 지정합니다.

매개 변수가 true 로 설정되면 브로커는 만료 주소와 관련 만료 큐를 자동으로 생성합니다. 자동 생성 주소의 이름은 expiryAddress 에 대해 지정한 값과 일치합니다.

유형: 부울

: true

기본값: false

 

autoCreateJmsQueues

이 속성은 더 이상 사용되지 않습니다. 대신 autoCreateQueues 를 사용합니다.

 

autoCreateJmsTopics

이 속성은 더 이상 사용되지 않습니다. 대신 autoCreateQueues 를 사용합니다.

 

autoCreateQueues

클라이언트가 메시지를 보낼 때 브로커가 자동으로 큐를 생성할지, 아니면 아직 존재하지 않는 큐인 메시지를 사용하려고 하는지 지정합니다.

유형: 부울

: false

기본값: true

 

autoDeleteAddresses

브로커에 더 이상 큐가 없는 경우 브로커가 자동으로 생성된 주소를 삭제할지 여부를 지정합니다.

유형: 부울

: false

기본값: true

 

autoDeleteAddressDelay

주소에 큐가 없는 경우 브로커가 자동으로 생성된 주소를 삭제하기 전에 대기하는 시간(밀리초)입니다.

유형: 정수

: 100

기본값: 0

 

autoDeleteJmsQueues

이 속성은 더 이상 사용되지 않습니다. 대신 autoDeleteQueues 를 사용합니다.

 

autoDeleteJmsTopics

이 속성은 더 이상 사용되지 않습니다. 대신 autoDeleteQueues 를 사용합니다.

 

autoDeleteQueues

큐에 소비자가 없고 메시지가 없을 때 브로커가 자동으로 생성된 큐를 삭제할지 여부를 지정합니다.

유형: 부울

: false

기본값: true

 

autoDeleteCreatedQueues

큐에 소비자가 없고 메시지가 없을 때 브로커가 수동으로 생성된 큐를 자동으로 삭제할지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

autoDeleteQueuesDelay

큐에 소비자가 없는 경우 브로커가 자동으로 생성된 큐를 삭제하기 전에 대기하는 시간(밀리초)입니다.

유형: 정수

: 10

기본값: 0

 

autoDeleteQueuesMessageCount

브로커가 대기열을 자동으로 삭제할 수 있는지 여부를 평가하기 전에 큐에 있을 수 있는 최대 메시지 수입니다.

유형: 정수

: 5

기본값: 0

 

configDeleteAddresses

구성 파일이 다시 로드되면 이 매개 변수는 구성 파일에서 삭제된 주소(및 대기열)를 처리하는 방법을 지정합니다. 다음 값을 지정할 수 있습니다.

OFF
구성 파일이 다시 로드될 때 브로커는 주소를 삭제하지 않습니다.
FORCE
브로커는 구성 파일이 다시 로드될 때 주소 및 해당 큐를 삭제합니다. 큐에 메시지가 있는 경우 해당 메시지도 제거됩니다.

유형: 문자열

: FORCE

기본값: OFF

 

configDeleteQueues

구성 파일이 다시 로드되면 이 설정은 브로커가 구성 파일에서 삭제된 큐를 처리하는 방법을 지정합니다. 다음 값을 지정할 수 있습니다.

OFF
구성 파일이 다시 로드되면 브로커는 큐를 삭제하지 않습니다.
FORCE
브로커는 구성 파일이 다시 로드되면 큐를 삭제합니다. 큐에 메시지가 있는 경우 해당 메시지도 제거됩니다.

유형: 문자열

: FORCE

기본값: OFF

 

deadLetterAddress

브로커가 종료한 메시지(즉, 전달되지 않은메시지)를 전송하는 주소입니다.

유형: 문자열

: DLA

기본값: 없음

 

deadLetterQueuePrefix

브로커가 자동으로 생성된 dead letter 큐의 이름에 적용되는 접두사입니다.

유형: 문자열

: myDLQ.

기본값: DLQ.

 

deadLetterQueueSuffix

브로커가 자동 생성된 dead letter 큐에 적용되는 접미사입니다.

유형: 문자열

: .DLQ

기본값: 없음

 

defaultAddressRoutingType

자동 생성된 주소에서 사용되는 라우팅 유형입니다.

유형: 문자열

: ANYCAST

기본값: MULTICAST

 

defaultConsumersBeforeDispatch

메시지 디스패치가 주소의 큐를 시작하기 전에 필요한 소비자 수입니다.

유형: 정수

: 5

기본값: 0

 

defaultConsumerWindowSize

소비자의 기본 창 크기(바이트)입니다.

유형: 정수

: 300000

기본값: 1048576(1024*1024)

 

defaultDelayBeforeDispatch

defaultConsumersBeforeDispatch 에 지정된 값이 도달하지 않은 경우 브로커가 메시지를 디스패치하기 전에 대기하는 기본 시간(밀리초)입니다.

유형: 정수

: 5

기본값: -1 ( delay)

 

defaultExclusiveQueue

주소의 모든 큐가 기본적으로 전용 대기열인지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

defaultGroupBuckets

메시지 그룹화에 사용할 버킷 수입니다.

유형: 정수

: 0(메시지 그룹화 비활성화)

기본값: -1 (제한 없음)

 

defaultGroupFirstKey

그룹에서 메시지를 먼저 나타내는 데 사용되는 키입니다.

유형: 문자열

: firstMessageKey

기본값: 없음

 

defaultGroupRebalance

새 소비자가 브로커에 연결할 때 그룹을 재조정할지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

defaultGroupRebalancePauseDispatch

브로커가 그룹을 재조정하는 동안 메시지 디스패치를 일시 정지할지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

defaultLastValueQueue

주소의 모든 큐가 기본적으로 마지막 값 대기열인지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

defaultLastValueKey

마지막 값 큐에 사용할 기본 키입니다.

유형: 문자열

: shares_ticker

기본값: 없음

 

defaultMaxConsumers

언제든지 큐에 허용되는 최대 소비자 수입니다.

유형: 정수

: 100

기본값: -1 (제한 없음)

 

defaultNonDestructive

주소의 모든 큐가 기본적으로 결정되지 않았는지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

defaultPurgeOnNoConsumers

소비자가 없는 한 브로커가 대기열의 콘텐츠를 제거하는지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

defaultQueueRoutingType

자동 생성 대기열에서 사용되는 라우팅 유형입니다. 기본값은 MULTICAST 입니다.

유형: 문자열

: ANYCAST

기본값: MULTICAST

 

defaultRingSize

명시적으로 설정된 링 크기가 없는 일치하는 큐의 기본 링 크기입니다.

유형: 정수

: 3

기본값: -1 (크기 제한 없음)

 

enableMetrics

Prometheus 플러그인과 같은 구성된 지표 플러그인에서 일치하는 주소 또는 주소 집합에 대한 지표를 수집하는지 여부를 지정합니다.

유형: 부울

: false

기본값: true

 

expiryAddress

만료된 메시지를 수신하는 주소입니다.

유형: 문자열

: myExpiryAddress

기본값: 없음

 

expiryDelay

기본 만료 시간을 사용하는 메시지에 적용되는 만료 시간(밀리초)입니다.

유형: 정수

: 100

기본값: -1( 만료 시간 적용 없음)

 

expiryQueuePrefix

브로커가 자동으로 생성된 만료 큐의 이름에 적용되는 접두사입니다.

유형: 문자열

: myExp.

기본값: EXP.

 

expiryQueueSuffix

브로커가 자동으로 생성된 만료 큐의 이름에 적용되는 접미사입니다.

유형: 문자열

: .EXP

기본값: 없음

 

lastValueQueue

큐에서 마지막 값만 사용하는지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

managementBrowsePageSize

관리 리소스에서 검색할 수 있는 메시지 수를 지정합니다.

유형: 정수

: 100

기본값: 200

 

일치 항목*

브로커에 구성된 주소와 주소 설정과 일치하는 문자열입니다. 정확한 주소 이름을 지정하거나 와일드카드 표현식을 사용하여 주소 설정과 주소 집합 과 일치시킬 수 있습니다.

와일드카드 표현식을 match 속성의 값으로 사용하는 경우 해당 값을 작은 따옴표로 묶어야 합니다(예: 'myAddresses*' ).

유형: 문자열

: 'myAddresses*'

기본값: 없음

 

maxDeliveryAttempts

브로커가 구성된 dead letter 주소로 메시지를 보내기 전에 메시지를 전달하려고 시도하는 횟수를 지정합니다.

유형: 정수

: 20

기본값: 10

 

maxExpiryDelay

이 값보다 큰 만료 시간을 사용하는 메시지에 적용되는 만료 시간(밀리초)입니다.

유형: 정수

: 20

기본값: -1 (최대 만료 시간 적용 없음)

 

maxRedeliveryDelay

브로커가 만든 메시지 재전송 시도 사이의 최대 값(밀리초)입니다.

유형: 정수

: 100

기본값: 기본값은 0 입니다. 기본값은 redeliveryDelay 의 값 10배입니다.

 

maxSizeBytes

주소에 대한 최대 메모리 크기(바이트)입니다. addressFullPolicyPAGING,BLOCK 또는 FAIL 로 설정된 경우 사용됩니다. 또한 "K", "Mb", "GB"와 같은 바이트 표기법도 지원합니다.

유형: 문자열

: 10Mb

기본값: -1 (제한 없음)

 

maxSizeBytesRejectThreshold

브로커가 메시지를 거부하기 시작하기 전에 주소에 도달할 수 있는 최대 크기(바이트)입니다. address-full-policyBLOCK 로 설정될 때 사용됩니다. AMQP 프로토콜용으로만 maxSizeBytes 와 함께 작동합니다.

유형: 정수

: 500

기본값: -1 (최대 크기 없음)

 

messageCounterHistoryDayLimit

브로커가 주소에 대한 메시지 카운터 기록을 유지하는 일 수입니다.

유형: 정수

: 5

기본값: 0

 

minExpiryDelay

이 값보다 만료 시간을 사용하는 메시지에 적용되는 만료 시간(밀리초)입니다.

유형: 정수

: 20

기본값: -1 (최소 만료 시간 없음)

 

pageMaxCacheSize

페이징 탐색 중에 I/O를 최적화하기 위해 메모리에 보관할 페이지 파일 수입니다.

유형: 정수

: 10

기본값: 5

 

pageSizeBytes

페이지 크기(바이트)입니다. 또한 K,MbGB 와 같은 바이트 표기법을 지원합니다.

유형: 문자열

: 20971520

기본값: 10485760 (약 10.5MB)

 

redeliveryDelay

브로커가 취소된 메시지를 재전송하기 전에 대기하는 시간(밀리초)입니다.

유형: 정수

: 100

기본값: 0

 

redeliveryDelayMultiplier

redeliveryDelay 의 값에 적용할 요인을 곱합니다.

유형: 번호

: 5

기본값: 1

 

redeliveryCollisionAvoidanceFactor

충돌을 피하기 위해 redeliveryDelay 값에 적용할 요소를 곱합니다.

유형: 번호

: 1.1

기본값: 0

 

redistributionDelay

시간(밀리초) 동안 브로커가 대기열에서 마지막 소비자가 종료된 후 나머지 메시지를 다시 배포하기 전에 대기하는 시간(밀리초)입니다.

유형: 정수

: 100

기본값: -1(설정되지 않음)

 

retroactiveMessageCount

주소에 생성된 향후 큐에 보관할 메시지 수입니다.

유형: 정수

: 100

기본값: 0

 

sendToDlaOnNoRoute

메시지를 큐로 라우팅할 수 없는 경우 구성된 배달 못 한 주소로 메시지를 보낼지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

slowConsumerCheckPeriod

브로커가 느린 소비자를 확인하는 빈도( )입니다.

유형: 정수

: 15

기본값: 5

 

slowConsumerPolicy

느린 소비자가 식별될 때 발생하는 상황을 지정합니다. 유효한 옵션은 KILL 또는 NOTIFY 입니다. KILL 은 소비자의 연결을 종료하여 동일한 연결을 사용하여 모든 클라이언트 스레드에 영향을 미칩니다. NOTIFYCONSUMER_SLOW 관리 알림을 클라이언트에 보냅니다.

유형: 문자열

: KILL

기본값: NOTIFY

 

slowConsumerThreshold

소비자가 느린 것으로 간주되기 전에 초당 메시지 사용량의 최소 속도입니다.

유형: 정수

: 100

기본값: -1(설정되지 않음)

brokerProperties

 

브로커의 CRD(Custom Resource Definitions)에 노출되지 않고 사용자 정의 리소스(CR)에서 구성할 수 없는 브로커 속성을 구성합니다.

 

<property name>=<value>

브로커에 대해 구성할 속성 이름 및 값 목록입니다. 하나의 property인 globalMaxSize 는 현재 brokerProperties 섹션에서 구성할 수 있습니다. globalMaxSize 속성을 설정하면 브로커에 할당된 기본 메모리 양이 재정의됩니다. 기본적으로 브로커에는 브로커의 Java 가상 머신에서 사용할 수 있는 최대 메모리의 절반이 할당됩니다.

globalMaxSize 속성의 기본 단위는 바이트입니다. 기본 단위를 변경하려면 m(MB) 또는 g(GB) 접미사를 값에 추가합니다.

유형: 문자열

: globalMaxSize=512m

기본값: 해당 없음

업그레이드

  
 

enabled

version 값을 업데이트하여 AMQ Broker의 새 대상 버전을 지정하는 경우 Operator에서 해당 버전의 AMQ Broker에 해당하는 브로커 컨테이너 이미지로 deploymentPlan.image 값을 자동으로 업데이트할지 여부를 지정합니다.

유형: 부울

: true

기본값: false

 

마이너

AMQ Broker의 마이너 버전에서 다른 마이너 버전으로 버전 값을 업데이트할 때 Operator에서 deploymentPlan.image 값을 자동으로 업데이트할지 여부를 지정합니다(예: 7.8.0 에서 7.10.6 ).

유형: 부울

: true

기본값: false

버전

 

Operator가 해당 브로커 컨테이너 이미지를 사용하도록 CR을 자동으로 업데이트하도록 AMQ Broker의 대상 마이너 버전을 지정합니다. 예를 들어 버전 값을 7.6.0 에서 7.7.0 으로 변경하면(업그레이드. enabled 및 upgrades. minor 가 모두 true로 설정된 경우 Operator는 registry.redhat.io/amq-broker-rhel8:7.8-x 형식의 브로커 이미지로 deploymentPlan. image 를 업데이트합니다.

유형: 문자열

: 7.7.0

기본값: 현재 AMQ Broker 버전

8.1.2. 주소 사용자 정의 리소스 구성 참조

주소 CRD를 기반으로 하는 CR 인스턴스를 사용하면 배포 브로커의 주소 및 대기열을 정의할 수 있습니다. 다음 표에서는 구성할 수 있는 항목에 대해 자세히 설명합니다.

중요

별표(*)로 표시된 구성 항목은 배포하는 해당 사용자 정의 리소스(CR)에 필요합니다. 필수가 아닌 항목의 값을 명시적으로 지정하지 않으면 구성은 기본값을 사용합니다.

entry설명 및 사용

addressName*

브로커에 생성할 주소 이름입니다.

유형: 문자열

: address0

기본값: 지정되지 않음

queueName

브로커에 생성할 큐 이름입니다. queueName 을 지정하지 않으면 CR은 주소만 생성합니다.

유형: 문자열

: queue0

기본값: 지정되지 않음

removeFromBrokerOnDelete*

해당 배포의 address CR 인스턴스를 제거할 때 Operator에서 배포의 모든 브로커의 기존 주소를 제거할지 여부를 지정합니다. 기본값은 false 입니다. 즉, CR을 제거할 때 Operator에서 기존 주소를 삭제하지 않습니다.

유형: 부울

: true

기본값: false

routingType*

사용할 라우팅 유형; anycast 또는 multicast.

유형: 문자열

: anycast

기본값: 멀티 캐스트

8.1.3. 보안 사용자 정의 리소스 구성 참조

보안 CRD를 기반으로 하는 CR 인스턴스를 사용하면 다음을 포함하여 배포 브로커에 대한 보안 구성을 정의할 수 있습니다.

  • 사용자 및 역할
  • propertiesLoginModule,guestLoginModulekeycloakLoginModule을 포함한 로그인 모듈
  • 역할 기반 액세스 제어
  • 콘솔 액세스 제어
참고

대부분의 옵션에서는 보안 브로커에 설명된 브로커 보안 개념을 이해해야 합니다.

다음 표에서는 구성할 수 있는 항목에 대해 자세히 설명합니다.

중요

별표(*)로 표시된 구성 항목은 배포하는 해당 사용자 정의 리소스(CR)에 필요합니다. 필수가 아닌 항목의 값을 명시적으로 지정하지 않으면 구성은 기본값을 사용합니다.

entry하위 항목설명 및 사용

loginModules

 

하나 이상의 로그인 모듈 구성입니다.

로그인 모듈은 다음 유형 중 하나일 수 있습니다.

  • propertiesLoginModule - 브로커 사용자를 직접 정의할 수 있습니다.
  • guestLoginModule - 로그인 자격 증명이 없거나 인증 정보가 실패하는 사용자에 대해 게스트 계정을 사용하여 브로커에 제한된 액세스 권한을 부여할 수 있습니다.
  • keycloakLoginModule. - Red Hat Single Sign-On을 사용하여 보안 브로커를 사용할 수 있습니다.

propertiesLoginModule

name*

로그인 모듈의 이름입니다.

유형: 문자열

: my-login

기본값: 해당 없음

 

users.name*

사용자 이름입니다.

유형: 문자열

: jdoe

기본값: 해당 없음

 

users.password*

사용자의 암호입니다.

유형: 문자열

: password

기본값: 해당 없음

 

users.roles

역할 이름.

유형: 문자열

: 뷰어

기본값: 해당 없음

guestLoginModule

name*

게스트 로그인 모듈의 이름입니다.

유형: 문자열

: guest-login

기본값: 해당 없음

 

guestUser

게스트 사용자의 이름입니다.

유형: 문자열

: myguest

기본값: 해당 없음

 

guestRole

게스트 사용자의 역할 이름입니다.

유형: 문자열

: guest

기본값: 해당 없음

keycloakLoginModule

name

KeycloakLoginModule 이름

유형: 문자열

: sso

기본값: 해당 없음

 

moduleType

KeycloakLoginModule 유형 (directAccess 또는 bearerToken)

유형: 문자열

: bearerToken

기본값: 해당 없음

 

구성

다음 구성 항목은 Red Hat Single Sign-On과 관련된 것이며 자세한 정보는 OpenID Connect 설명서에서 확인할 수 있습니다.

 

configuration.realm*

KeycloakLoginModule의 영역

유형: 문자열

: myrealm

기본값: 해당 없음

 

configuration.realmPublicKey

영역의 공개 키

유형: 문자열

기본값: 해당 없음

 

configuration.authServerUrl*

keycloak 인증 서버의 URL

유형: 문자열

기본값: 해당 없음

 

configuration.sslRequired

SSL이 필요한지 여부를 지정

유형: 문자열

유효한 값은 'all', 'external' 및 'none'입니다.

 

configuration.resource*

리소스 이름

애플리케이션의 클라이언트 ID입니다. 각 애플리케이션에는 애플리케이션을 식별하는 데 사용되는 클라이언트 ID가 있습니다.

 

configuration.publicClient

공용 클라이언트인지 여부를 지정합니다.

유형: 부울

기본값: false

: false

 

configuration.credentials.key

인증 정보 키를 지정합니다.

유형: 문자열

기본값: 해당 없음

유형: 문자열

기본값: 해당 없음

 

configuration.credentials.value

인증 정보 값 지정

유형: 문자열

기본값: 해당 없음

 

configuration.useResourceRoleMappings

리소스 역할 매핑 사용 여부를 지정

유형: 부울

: false

 

configuration.enableCors

CORS(Cross-Origin Resource Sharing) 활성화 여부를 지정합니다.

CORS 사전 진행 요청을 처리합니다. 또한 액세스 토큰을 확인하여 유효한 출처를 결정합니다.

유형: 부울

기본값: 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

전달자 토큰 확인 여부를 지정

유형: 부울

기본값: false

 

configuration.autoDetectBearerOnly

자동으로 전달자 토큰만 감지할지 여부를 지정

유형: 부울

기본값: false

 

configuration.connectionPoolSize

연결 풀의 크기

유형: Integer

기본값: 20

 

configuration.allowAnyHostName

호스트 이름 허용 여부를 지정합니다.

유형: 부울

기본값: false

 

configuration.disableTrustManager

신뢰 관리자 비활성화 여부를 지정

유형: 부울

기본값: false

 

configuration.trustStore*

신뢰 저장소의 경로

ssl-required가 none 또는 disable-trust-manager가 true인 경우가 아니면 REQUIRED입니다.

 

configuration.trustStorePassword*

truststore 암호

truststore가 설정되어 있고 truststore에 암호가 필요한 경우 REQUIRED입니다.

 

configuration.clientKeyStore

클라이언트 키 저장소의 경로

유형: 문자열

기본값: 해당 없음

 

configuration.clientKeyStorePassword

클라이언트 키 저장소 암호

유형: 문자열

기본값: 해당 없음

 

configuration.clientKeyPassword

클라이언트 키 암호

유형: 문자열

기본값: 해당 없음

 

configuration.alwaysRefreshToken

토큰을 항상 새로 고칠지 여부를 지정합니다.

유형: 부울

: false

 

configuration.registerNodeAtStartup

시작 시 노드 등록 여부를 지정

유형: 부울

: false

 

configuration.registerNodePeriod

노드 다시 등록 기간

유형: 문자열

기본값: 해당 없음

 

configuration.tokenStore

토큰 저장소 유형 (세션 또는 쿠키)

유형: 문자열

기본값: 해당 없음

 

configuration.tokenCookiePath

쿠키 저장소의 쿠키 경로

유형: 문자열

기본값: 해당 없음

 

configuration.principalAttribute

OpenID Connect ID 토큰 속성을 사용하여 UserPrincipal 이름을 입력합니다.

OpenID Connect ID 토큰 속성을 사용하여 UserPrincipal 이름을. token 속성이 null이면 기본값은 sub입니다. 가능한 값은 sub, preferred_username, email, 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

전달자 토큰 처리를 위해 access_token 쿼리 매개변수 처리를 해제할지 여부

유형: 부울

: false

 

configuration.verifyTokenAudience

토큰에 대상자로 이 클라이언트 이름(리소스)이 포함되어 있는지 확인합니다.

유형: 부울

: false

 

configuration.enableBasicAuth

기본 인증 지원 여부

유형: 부울

기본값: false

 

configuration.confidentialPort

SSL/TLS를 통한 보안 연결을 위해 Keycloak 서버에서 사용하는 기밀 포트

유형: Integer

: 8443

 

configuration.redirectRewriteRules.key

리디렉션 URI와 일치하는 데 사용되는 정규식입니다.

유형: 문자열

기본값: 해당 없음

 

configuration.redirectRewriteRules.value

대체 문자열

유형: 문자열

기본값: 해당 없음

 

configuration.scope

DirectAccessGrantsLoginModule의 OAuth2 범위 매개변수

유형: 문자열

기본값: 해당 없음

securityDomains

 

브로커 보안 도메인

 

brokerDomain.name

브로커 도메인 이름

유형: 문자열

: activemq

기본값: 해당 없음

 

brokerDomain.loginModules

하나 이상의 로그인 모듈. 각 항목은 위의 loginModules 섹션에서 이전에 정의해야 합니다.

 

brokerDomain.loginModules.name

로그인 모듈의 이름

유형: 문자열

: prop-module

기본값: 해당 없음

 

brokerDomain.loginModules.flag

propertiesLoginModule, 필수, 필수 조건,충분한선택적 값은 유효한 값입니다.

유형: 문자열

: 충분한 경우

기본값: 해당 없음

 

brokerDomain.loginModules.debug

Debug

 

brokerDomain.loginModules.reload

reload

 

consoleDomain.name

브로커 도메인 이름

유형: 문자열

: activemq

기본값: 해당 없음

 

consoleDomain.loginModules

단일 로그인 모듈 구성입니다.

 

consoleDomain.loginModules.name

로그인 모듈의 이름

유형: 문자열

: prop-module

기본값: 해당 없음

 

consoleDomain.loginModules.flag

propertiesLoginModule, 필수, 필수 조건,충분한선택적 값은 유효한 값입니다.

유형: 문자열

: 충분한 경우

기본값: 해당 없음

 

consoleDomain.loginModules.debug

Debug

유형: 부울

: false

 

consoleDomain.loginModules.reload

reload

유형: 부울

: true

기본값: false

securitySettings

 

broker.xml 또는 management.xml에 추가할 추가 보안 설정

 

broker.match

보안 설정 섹션의 주소 일치 패턴입니다. 일치 패턴 구문에 대한 자세한 내용은 AMQ Broker 와일드카드 구문을 참조하십시오.

 

broker.permissions.operationType

권한 설정에 설명된 대로 보안 설정 의 작업 유형입니다.

유형: 문자열

: createAddress

기본값: 해당 없음

 

broker.permissions.roles

보안 설정은 권한 설정에 설명된 대로 이러한 역할에 적용됩니다.

유형: 문자열

: root

기본값: 해당 없음

securitySettings.management

 

management.xml 을 구성하는 옵션 .

 

hawtioRoles

브로커 콘솔에 로그인할 수 있는 역할입니다.

유형: 문자열

: root

기본값: 해당 없음

 

connector.host

관리 API에 연결하기 위한 커넥터 호스트입니다.

유형: 문자열

: myhost

기본값: localhost

 

connector.port

관리 API에 연결하기 위한 커넥터 포트입니다.

유형: 정수

: 1099

기본값: 1099

 

connector.jmxRealm

관리 API의 영역입니다.

유형: 문자열

: activemq

기본값: activemq

 

connector.objectName

관리 API의 object 이름입니다.

유형: 문자열

: connector:name=rmi

기본값: connector:name=rmi

 

connector.authenticatorType

관리 API 인증 유형입니다.

유형: 문자열

: 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"를 설정한 경우 관리 커넥터의 신뢰 저장소 공급자가 필요합니다.

유형: 문자열

: JKS

기본값: JKS

 

connector.trustStorePath

관리 커넥터에 대한 신뢰 저장소의 위치입니다. connector.secured="true"를 설정한 경우 필수 항목입니다.

유형: 문자열

기본값: 해당 없음

 

connector.trustStorePassword

관리 커넥터의 truststore 암호입니다. connector.secured="true"를 설정한 경우 필수 항목입니다.

유형: 문자열

기본값: 해당 없음

 

connector.passwordCodec

관리 커넥터의 암호 codec: 구성 파일에서 암호 암호 암호화에 설명된 대로 사용할 암호 코드c의 정규화된 클래스 이름입니다.

 

authorisation.allowedList.domain

allowedList 도메인

유형: 문자열

기본값: 해당 없음

 

authorisation.allowedList.key

allowedList의 키

유형: 문자열

기본값: 해당 없음

 

authorisation.defaultAccess.method

defaultAccess List의 방법

유형: 문자열

기본값: 해당 없음

 

authorisation.defaultAccess.roles

defaultAccess List의 역할

유형: 문자열

기본값: 해당 없음

 

authorisation.roleAccess.domain

roleAccess List의 도메인

유형: 문자열

기본값: 해당 없음

 

authorisation.roleAccess.key

roleAccess List의 키

유형: 문자열

기본값: 해당 없음

 

authorisation.roleAccess.accessList.method

roleAccess List의 메서드

유형: 문자열

기본값: 해당 없음

 

authorisation.roleAccess.accessList.roles

roleAccess List의 역할

유형: 문자열

기본값: 해당 없음

 

applyToCrNames

이 보안 구성을 현재 네임스페이스에 이름이 지정된 CR에서 정의한 브로커에 적용합니다. * 또는 빈 문자열 값은 모든 브로커에 적용되는 것을 의미합니다.

유형: 문자열

: my-broker

기본값: 현재 네임스페이스의 CR에 의해 정의된 모든 브로커입니다.

8.2. 애플리케이션 템플릿 매개변수

애플리케이션 템플릿 매개변수 값을 지정하여 OpenShift Container Platform 이미지에서 AMQ Broker를 구성합니다. 다음 매개변수를 구성할 수 있습니다.

표 8.1. 애플리케이션 템플릿 매개변수

매개변수설명

AMQ_ADDRESSES

시작의 브로커에서 기본적으로 사용할 수 있는 주소를 쉼표로 구분된 목록으로 지정합니다.

AMQ_ANYCAST_PREFIX

다중 프로토콜 포트 61616 및 61617에 적용되는 anycast 접두사를 지정합니다.

AMQ_CLUSTERED

클러스터링을 활성화합니다.

AMQ_CLUSTER_PASSWORD

클러스터링에 사용할 암호를 지정합니다. AMQ Broker 애플리케이션 템플릿은 AMQ_CREDENTIAL_SECRET에 이름이 지정된 시크릿에 저장된 이 매개변수의 값을 사용합니다.

AMQ_CLUSTER_USER

클러스터링에 사용할 클러스터 사용자를 지정합니다. AMQ Broker 애플리케이션 템플릿은 AMQ_CREDENTIAL_SECRET에 이름이 지정된 시크릿에 저장된 이 매개변수의 값을 사용합니다.

AMQ_CREDENTIAL_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에 이름이 지정된 시크릿에 저장된 이 매개변수의 값을 사용합니다.

AMQ_KEYSTORE_TRUSTSTORE_DIR

보안이 마운트된 디렉터리를 지정합니다. 기본값은 /etc/amq-secret-volume 입니다.

AMQ_MAX_CONNECTIONS

SSL 전용의 경우 수락자가 허용할 최대 연결 수를 지정합니다.

AMQ_MULTICAST_PREFIX

멀티플렉싱 프로토콜 포트(61616 및 61617)에 적용되는 멀티 캐스트 접두사를 지정합니다.

AMQ_NAME

브로커 인스턴스의 이름을 지정합니다. 기본값은 amq-broker 입니다.

AMQ_PASSWORD

브로커 인증에 사용되는 암호를 지정합니다. AMQ Broker 애플리케이션 템플릿은 AMQ_CREDENTIAL_SECRET에 이름이 지정된 시크릿에 저장된 이 매개변수의 값을 사용합니다.

AMQ_PROTOCOL

브로커가 사용하는 메시징 프로토콜을 쉼표로 구분된 목록으로 지정합니다. 사용 가능한 옵션은 amqp,mqtt,openwire,stomp, hornetq 입니다. 지정하지 않으면 모든 프로토콜을 사용할 수 있습니다. Red Hat JBoss Enterprise Application Platform과 이미지를 통합하려면 Open>-<re 프로토콜을 지정해야 하며 다른 프로토콜도 선택적으로 지정할 수 있습니다.

AMQ_QUEUES

시작의 브로커에서 기본적으로 사용할 수 있는 대기열을 쉼표로 구분된 목록으로 지정합니다.

AMQ_REQUIRE_LOGIN

true 로 설정하면 로그인이 필요합니다. 지정하지 않거나 false 로 설정하면 익명 액세스가 허용됩니다. 기본적으로 이 매개변수의 값은 지정되지 않습니다.

AMQ_ROLE

생성된 역할의 이름을 지정합니다. 기본값은 amq 입니다.

AMQ_TRUSTSTORE

SSL 신뢰 저장소 파일 이름을 지정합니다. 값을 지정하지 않으면 임의의 암호가 생성되지만 SSL이 구성되지 않습니다.

AMQ_TRUSTSTORE_PASSWORD

(선택 사항) SSL 신뢰 저장소의 암호를 해독하는 데 사용되는 암호를 지정합니다. AMQ Broker 애플리케이션 템플릿은 AMQ_CREDENTIAL_SECRET에 이름이 지정된 시크릿에 저장된 이 매개변수의 값을 사용합니다.

AMQ_USER

브로커 인증에 사용되는 사용자 이름을 지정합니다. AMQ Broker 애플리케이션 템플릿은 AMQ_CREDENTIAL_SECRET에 이름이 지정된 시크릿에 저장된 이 매개변수의 값을 사용합니다.

APPLICATION_NAME

OpenShift 내에서 내부적으로 사용되는 애플리케이션의 이름을 지정합니다. 애플리케이션 내의 서비스, Pod 및 기타 오브젝트 이름에 사용됩니다.

IMAGE

이미지를 지정합니다. 지속성,persistent-ssl, statefulset-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_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-02-22에 최종 업데이트된 문서

법적 공지

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.