OpenShift에 AMQ Broker 배포

프로세스

1. 웹 브라우저에서 AMQ Broker 7.12.3 릴리스 의 소프트웨어 다운로드 페이지로 이동합니다.
2. 버전 드롭다운 목록의 값이 7.12.3 으로 설정되고 릴리스 탭이 선택되어 있는지 확인합니다.

3. 최신 AMQ Broker 7.12.3 Operator 설치 및 예제 파일 옆에 있는 Download 를 클릭합니다.

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

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

   $ mkdir ~/broker/operator
   $ mv amq-broker-operator-7.12.3-ocp-install-examples-rhel8.zip ~/broker/operator

5. 선택한 디렉터리에서 아카이브의 내용을 추출합니다. 예를 들면 다음과 같습니다.

   $ cd ~/broker/operator
   $ unzip amq-broker-operator-7.12.3-ocp-install-examples-rhel8.zip

6. 아카이브를 추출할 때 생성된 디렉터리로 전환합니다. 예를 들면 다음과 같습니다.

   $ cd amq-broker-operator-7.12.3-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-controller-manager 를 사용자 지정 이름으로 교체합니다.

   4. 프로젝트에서 서비스 계정을 생성합니다.

      $ oc create -f deploy/service_account.yaml

10. Operator의 역할 이름을 지정합니다.

    1. role.yaml 파일을 엽니다. 이 파일은 Operator가 사용하고 수정할 수 있는 리소스를 지정합니다.
    2. kind 요소가 Role 로 설정되어 있는지 확인합니다.
    3. 기본 역할 이름을 변경하려면 metadata 섹션에서 amq-broker-operator-role 을 사용자 지정 이름으로 교체합니다.

    4. 프로젝트에서 역할을 생성합니다.

       $ oc create -f deploy/role.yaml

11. Operator에 대한 역할 바인딩을 지정합니다. 역할 바인딩은 지정한 이름에 따라 이전에 생성된 서비스 계정을 Operator 역할에 바인딩합니다.

    1. role_binding.yaml 파일을 엽니다.

    2. ServiceAccount 및 Role 의 name 값이 service_account.yaml 및 role.yaml 파일에 지정된 값과 일치하는지 확인합니다. 예를 들면 다음과 같습니다.

       metadata:
           name: amq-broker-operator-rolebinding
       subjects:
           kind: ServiceAccount
           name: amq-broker-controller-manager
       roleRef:
           kind: Role
           name: amq-broker-operator-role

    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: amq-broker-controller-manager
         namespace: operator-project

       참고

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

    6. 프로젝트에 클러스터 역할을 생성합니다.

       $ oc create -f deploy/cluster_role.yaml

    7. 프로젝트에 클러스터 역할 바인딩을 생성합니다.

       $ oc create -f deploy/cluster_role_binding.yaml

프로세스

1. OpenShift CLI(명령줄 인터페이스)에서 OpenShift에 클러스터 관리자로 로그인합니다. 예를 들면 다음과 같습니다.

   $ oc login -u system:admin

2. 이전에 Operator 배포를 위해 준비한 프로젝트로 전환합니다. 예를 들면 다음과 같습니다.

   $ oc project <project_name>

3. 이전에 Operator 설치 아카이브를 추출할 때 생성된 디렉터리로 전환합니다. 예를 들면 다음과 같습니다.

   $ cd ~/broker/operator/amq-broker-operator-7.12.3-ocp-install-examples

4. Operator에 포함된 CRD를 배포합니다. Operator를 배포하고 시작하기 전에 OpenShift 클러스터에 CRD를 설치해야 합니다.

   1. 기본 브로커 CRD를 배포합니다.

      $ oc create -f deploy/crds/broker_activemqartemis_crd.yaml

   2. 주소 CRD를 배포합니다.

      $ oc create -f deploy/crds/broker_activemqartemisaddress_crd.yaml

   3. scaledown 컨트롤러 CRD를 배포합니다.

      $ oc create -f deploy/crds/broker_activemqartemisscaledown_crd.yaml

   4. 보안 CRD를 배포합니다.

      $ oc create -f deploy/crds/broker_activemqartemissecurity_crd.yaml

5. Red Hat Ecosystem Catalog에서 인증에 사용되는 계정과 연결된 풀 시크릿을 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.12.3-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:1fd01079ad519e1a47b886893a0635491759ace2f73eda7615a9c8c2f454ba89

   참고

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

7. Operator를 배포합니다.

   $ oc create -f deploy/operator.yaml

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

   OpenShift Container Platform 웹 콘솔의 Operator Pod의 Events 탭에 대한 정보는 OpenShift가 사용자가 지정한 Operator 이미지를 배포했음을 확인하고, OpenShift 클러스터의 노드에 새 컨테이너를 할당했으며, 새 컨테이너를 시작했습니다.

   또한 Pod에서 로그 탭을 클릭하면 출력에 다음과 같은 행이 포함되어야 합니다.

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

프로세스

1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.
2. 왼쪽 탐색 메뉴에서 Operators → OperatorHub 를 클릭합니다.
3. OperatorHub 페이지 상단에 있는 프로젝트 드롭다운 메뉴에서 Operator를 배포할 프로젝트를 선택합니다.

4. OperatorHub 페이지에서 키워드로 필터링…​ 상자를 사용하여 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.12의 경우 이 Operator의 최신 마이너 버전 태그는 7.12.3-opr-1 입니다.

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

6. Operator 설치 페이지에서 다음을 수행합니다.

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

      OpenShift Container Platform 클러스터가 설치된 시기에 따라 이전 버전의 AMQ Broker 채널도 표시될 수 있습니다. 지원되는 유일한 채널은 LTS 채널인 7.10.x 입니다.

   2. 설치 모드에서 Operator가 조사하는 네임스페이스를 선택합니다.

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

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

7. 설치된 네임스페이스 드롭다운 메뉴에서 Operator를 설치할 프로젝트를 선택합니다.

8. 승인 전략에서 라디오 버튼의 권한이 자동으로 선택되어 있는지 확인합니다. 이 옵션은 Operator에 대한 업데이트가 설치에 대한 수동 승인이 필요하지 않도록 지정합니다.

   참고

   승인 전략은 마이크로 버전의 Operator 간 업데이트에만 적용됩니다. 마이너 Operator 버전 간의 자동 업데이트는 지원되지 않습니다. 예를 들어 현재 Operator가 버전 7.11.7인 경우 버전 7.12.x에 대한 자동 업데이트를 사용할 수 없습니다. Operator의 마이너 버전 간에 업데이트하려면 현재 Operator를 수동으로 제거하고 해당 마이너 버전의 Operator를 사용할 수 있는 채널에서 새 Operator를 설치해야 합니다. 자세한 내용은 6.3절. “OperatorHub를 사용하여 Operator 수동 업그레이드”의 내용을 참조하십시오.

9. 설치를 클릭합니다.

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 인스턴스를 시작합니다. 왼쪽 창에서 Administration → Custom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.

      5. Create ActiveMQArtemis 를 클릭합니다.

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

   기본 브로커 배포의 경우 아래 표시된 구성과 유사할 수 있습니다.

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true

   broker_activemqartemis_cr.yaml 샘플 CR 파일에서 image 속성이 자리 표시자 의 기본값으로 설정되어 있는지 확인합니다. 이 값은 기본적으로 image 속성이 배포에 사용할 브로커 컨테이너 이미지를 지정하지 않음을 나타냅니다. Operator에서 사용할 적절한 브로커 컨테이너 이미지를 결정하는 방법을 알아보려면 2.7절. “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-ss-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 웹 콘솔에서 Workloads → StatefulSets 를 클릭합니다. ex-aao-ss 라는 새로운 StatefulSet이 표시됩니다.

   1. ex-aao-ss StatefulSet을 클릭합니다. CR에 정의한 단일 브로커에 해당하는 하나의 Pod가 있는지 확인합니다.
   2. StatefulSet에서 Pods 탭을 클릭합니다. ex-aao-ss s Pod를 클릭합니다. 실행 중인 Pod의 이벤트 탭에 브로커 컨테이너가 시작되었는지 확인합니다. 로그 탭에는 브로커 자체가 실행 중임을 보여줍니다.

5. 브로커가 정상적으로 실행 중인지 테스트하려면 브로커 Pod의 쉘에 액세스하여 일부 테스트 메시지를 보냅니다.

   1. OpenShift Container Platform 웹 콘솔 사용:

      1. 워크로드 → 포드 를 클릭합니다.
      2. ex-aao-ss s 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

프로세스

1. 기본 브로커 배포에 사용한 CR 파일을 엽니다.

2. 클러스터형 배포의 경우 deploymentPlan.size 값이 2 이상이어야 합니다. 예를 들면 다음과 같습니다.

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   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

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

프로세스

1. 브로커 배포에 사용할 ActiveMQArtemis CR 인스턴스를 편집합니다.

2. CR의 spec 섹션에서 CR에 아직 없는 경우 brokerProperties 속성을 추가합니다.

   spec:
     ...
     brokerProperties:
     ...

3. 형식으로 주소를 구성합니다.

   - addressConfigurations.<주소 이름>.routingTypes=<라우팅 유형>

   예를 들면 다음과 같습니다.

   spec:
     ...
     brokerProperties:
     - addressConfigurations.usa-news-address.routingTypes=MULTICAST
     ...

4. 형식으로 생성한 주소에 대한 큐를 구성합니다.

   - addressConfigurations.<주소 이름>.queueConfigs.<큐 이름>.address<address>

   중요

   .address 설정의 <address> 값은 생성한 각 큐에 대해 <주소 이름>과 일치해야 합니다. 이러한 값이 다른 경우 각각에 대해 별도의 주소가 생성됩니다. 다음 예에서 주소 이름과 .address 설정의 모두 usa-news-address 의 값과 동일합니다.

   spec:
     ...
     brokerProperties:
     - addressConfigurations.usa-news-address.queueConfigs.usa-news-queue.address=usa-news-address
     ...

5. 형식으로 큐에 대해 구성할 각 설정에 대해 별도의 행을 추가합니다.

   • addressConfigurations.<주소 이름>.queueConfigs.<큐 이름>.<큐 설정>

   예를 들면 다음과 같습니다.

   spec:
     ...
     brokerProperties:
     - addressConfigurations.usa-news-address.queueConfigs.usa-news-queue.routingType=ANYCAST
     - addressConfigurations.usa-news-address.queueConfigs.usa-news-queue.purgeOnNoConsumers=true
     - addressConfigurations.usa-news-address.queueConfigs.usa-news-queue.maxConsumers=20
     ...

6. CR을 저장합니다.
7. ActiveMQArtemis CR의 status 섹션을 검토하여 brokerProperties 구성에서 오류가 감지되지 않았는지 확인합니다. 자세한 내용은 2.4절. “CRD(사용자 정의 리소스 정의)에 노출되지 않은 항목 구성”의 내용을 참조하십시오.

프로세스

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 인스턴스를 시작합니다. 왼쪽 창에서 Administration → Custom 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 구성을 완료하면 생성 을 클릭합니다.

1. 브로커 배포에 사용할 ActiveMQArtemis CR 인스턴스를 편집합니다.

2. 배달되지 않은 메시지를 수신하기 위해 dead letter address 및 queue를 만듭니다. 예를 들면 다음과 같습니다.

   spec:
     ...
     brokerProperties:
     ...
     - addressConfigurations.usDeadLetter.routingTypes=MULTICAST
     - addressConfigurations.usDeadLetter.queueConfigs.usDeadLetter-queue.address=usDeadLetter

   brokerProperties 를 사용하여 주소 및 큐 생성에 대한 자세한 내용은 4.2.1절. “주소 및 큐 구성” 을 참조하십시오.

3. addressSettings.< 주소이름>.< 주소 설정 > 의 brokerProperties 속성 아래에 별도의 행을 추가합니다.

   • 생성된 dead letter address를 dead letter address로 설정합니다.

   • 배달 시도 횟수를 지정한 후 일치하는 주소로 전달할 수 없는 메시지를 dead letter 주소로 보냅니다.

     예를 들면 다음과 같습니다.

     spec:
       ...
       brokerProperties:
       ...
       - addressSettings.usa-news.deadLetterAddress=usDeadLetter
       - addressSettings.usa-news.maxDeliveryAttempts=5
       ...

     별표(*) 또는 숫자 기호(#) 문자를 와일드카드로 사용하여 주소 패턴을 만들 수 있습니다. 패턴의 일치는 마침표(.)로 표시되는 각 구분 기호 경계에서 수행됩니다. 숫자 기호 문자는 0개 이상의 단어와 일치하며 주소 문자열 끝에 사용할 수 있습니다. 별표 문자는 단일 단어와 일치하며 address 문자열 내의 모든 위치에서 사용할 수 있습니다. 예를 들면 다음과 같습니다.

     spec:
       ...
       brokerProperties:
       ...
       - addressSettings."usa-news.*".deadLetterAddress=usDeadLetter
       - addressSettings."europe-news.#".deadLetterAddress=euDeadLetter
       ...

     이전 예에서 다음 주소가 일치합니다.

   • usa-news.* 주소 패턴은 usa-news.domestic 및 usa-news. intl 과 같이 usa-news.politics 문자열과 일치하지만 usa-news.domestic.politics.

   • europe-news.# 주소 패턴은 europe-news , europe-news.politics 및 europe-news.politics. fr과 같이 europe-news 로 시작하는 모든 주소와 일치합니다.

     참고

     brokerProperties 항목에서 마침표(.)는 예약된 문자입니다. 마침표가 포함된 주소 패턴을 만들려면 주소를 따옴표로 묶어야 합니다. 예: "usa-news.*"

4. CR을 저장합니다.
5. ActiveMQArtemis CR의 status 섹션을 검토하여 brokerProperties 구성에서 오류가 감지되지 않았는지 확인합니다. 자세한 내용은 2.4절. “CRD(사용자 정의 리소스 정의)에 노출되지 않은 항목 구성”의 내용을 참조하십시오.

프로세스

1. 브로커 배포에 사용할 ActiveMQArtemis CR 인스턴스를 편집합니다.

    oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   1. OpenShift Container Platform 웹 콘솔 사용:
2. 브로커 배포를 위해 프로젝트에 CR을 배포할 권한이 있는 사용자로 콘솔에 로그인합니다.
3. 왼쪽 창에서 Operators → Installed Operator 를 클릭합니다.
4. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator를 클릭합니다.
5. AMQ Broker 탭을 클릭합니다.
6. ActiveMQArtemis 인스턴스 이름의 이름을 클릭합니다.

7. YAML 탭을 클릭합니다.

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

   참고

   metadata 섹션에는 namespace 속성을 포함하고 OpenShift Container Platform 웹 콘솔을 사용하여 CR 인스턴스를 생성하는 경우에만 값을 지정해야 합니다. 지정해야 하는 값은 브로커 배포를 위한 OpenShift 프로젝트의 이름입니다.

   1. CR의 spec 섹션에서 다음과 같이 단일 addressSetting 섹션이 포함된 새 addressSettings 섹션을 추가합니다.

      spec:
        ...
        addressSettings:
          addressSetting:

   2. addressSetting 블록에 match 속성의 단일 인스턴스를 추가합니다. 주소 일치 표현식을 지정합니다. 예를 들면 다음과 같습니다.

      spec:
        ...
        addressSettings:
          addressSetting:
          - match: myAddress

      match

      브로커가 다음 구성을 적용하는 주소 또는 주소를 지정합니다. 이 예제에서 match 속성의 값은 myAddress 라는 단일 주소에 해당합니다.

   3. 전달되지 않은 메시지와 관련된 속성을 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.

      spec:
        ...
        addressSettings:
          addressSetting:
          - match: myAddress
            deadLetterAddress: myDeadLetterAddress
            maxDeliveryAttempts: 5

      deadLetterAddress

      브로커가 전달되지 않은 메시지를 보내는 주소입니다.

      maxDeliveryAttempts

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

      이전 예에서 브로커가 myAddress 로 시작하는 주소로 5번 메시지를 전달하려고 하면 브로커는 지정된 dead letter address인 myDeadLetterAddress 로 메시지를 이동합니다.

   4. (선택 사항) 다른 주소 또는 주소 집합에 유사한 구성을 적용합니다. 예를 들면 다음과 같습니다.

      spec:
        ...
        addressSettings:
          addressSetting:
          - match: myAddress
            deadLetterAddress: myDeadLetterAddress
            maxDeliveryAttempts: 5
          - match: 'myOtherAddresses#'
            deadLetterAddress: myDeadLetterAddress
            maxDeliveryAttempts: 3

      이 예제에서 두 번째 match 속성 값에는 해시 와일드카드 문자가 포함됩니다. 와일드카드 문자는 이전 구성이 myOtherAddresses 문자열로 시작하는 모든 주소에 적용됨을 의미합니다.

      참고

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

   5. addressSettings 섹션의 시작 부분에 applyRule 속성을 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.

      spec:
        ...
          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 을 사용합니다.

   6. CR 인스턴스를 저장합니다.

프로세스

1. 브로커 배포에 사용할 ActiveMQArtemis CR 인스턴스를 편집합니다.

2. 다음 brokerProperties 항목을 추가하여 브로커가 숫자 기호(#) 및 CR에서 더 이상 찾을 수 없는 연결된 큐로 표시되는 주소를 삭제할 수 있습니다.

   spec:
     ...
     brokerProperties:
     - addressSettings.#.configDeleteAddresses=FORCE
     - addressSettings.#.configDeleteQueues=FORCE
     ...

3. brokerProperties 속성에서 제거할 주소와 큐를 참조하는 모든 행을 삭제합니다. 예를 들어 usa-news 주소를 참조하는 모든 행을 삭제하여 이 주소와 큐를 제거합니다.

   spec:
     ...
     brokerProperties:
     - addressConfigurations.usa-news.queueConfigs.usa-news-queue.routingType=MULTICAST
     - addressConfigurations.usa-news.queueConfigs.usa-news-queue.purgeOnNoConsumers=true
     - addressConfigurations.usa-news.queueConfigs.usa-news-queue.maxConsumers=20
     ...

4. CR을 저장합니다.

   브로커가 업데이트된 구성을 적용하면 CR에서 제거한 주소와 큐를 삭제합니다.

프로세스

1. 삭제할 주소 및 큐의 이름,addressName 및 queueName 과 같은 세부 정보가 있는 주소 CR 파일이 있는지 확인합니다. 예를 들면 다음과 같습니다.

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemisAddress
   metadata:
       name: myAddressDeployment0
       namespace: myProject
   spec:
       ...
       addressName: myAddress0
       queueName: myQueue0
       routingType: anycast
       ...

2. address CR의 spec 섹션에서 removeFromBrokerOnDelete 속성을 추가하고 true 값으로 설정합니다.

   ..
   spec:
      addressName: myAddress1
      queueName: myQueue1
      routingType: anycast
      removeFromBrokerOnDelete: true

   removeFromBrokerOnDelete 속성을 true 로 설정하면 주소 CR을 삭제할 때 Operator에서 배포의 모든 브로커에 대한 주소 및 관련 메시지가 제거됩니다.

3. 업데이트된 주소 CR을 적용하여 삭제하려는 주소에 대한 removeFromBrokerOnDelete 속성을 설정합니다.

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

4. 주소 CR을 삭제하여 배포의 브로커에서 주소를 삭제합니다.

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

프로세스

1. 새로운 JAAS 로그인 모듈 구성으로 텍스트 파일을 만들고 파일을 login.config 로 저장합니다. 파일을 login.config 로 저장하면 텍스트 파일에서 생성한 시크릿에 올바른 키가 삽입됩니다. 다음은 로그인 모듈 구성의 예입니다.

   activemq {
      org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule sufficient
         reload=true
         org.apache.activemq.jaas.properties.user="new-users.properties"
         org.apache.activemq.jaas.properties.role="new-roles.properties";
   
      org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule sufficient
         reload=false
         org.apache.activemq.jaas.properties.user="artemis-users.properties"
         org.apache.activemq.jaas.properties.role="artemis-roles.properties"
         baseDir="/home/jboss/amq-broker/etc";
   };

   시크릿에 JAAS 로그인 모듈을 구성하고 CR의 보안에 대한 참조를 추가하면 기본 로그인 모듈이 더 이상 AMQ Broker에서 사용되지 않습니다. 그러나 기본 로그인 모듈에서 참조되는 artemis-users.properties 파일의 사용자는 브로커로 인증하기 위해 Operator에 필요합니다. 새 JAAS 로그인 모듈을 구성한 후 Operator가 브로커로 인증할 수 있도록 하려면 다음 중 하나를 수행해야 합니다.

   • 위의 예와 같이 새 로그인 모듈 구성에 기본 속성 로그인 모듈을 포함합니다. 이 예제에서 기본 속성 로그인 모듈은 artemis-users.properties 및 artemis-roles.properties 파일을 사용합니다. 새 로그인 모듈 구성에 기본 로그인 모듈을 포함하는 경우 baseDir 을 각 브로커 Pod의 기본 속성 파일이 포함된 /home/jboss/amq-broker/etc 디렉터리로 설정해야 합니다.

   • Operator에서 브로커로 인증하는 데 필요한 사용자 및 역할 정보를 새 로그인 모듈 구성에서 참조하는 속성 파일에 추가합니다. 브로커 Pod의 /home/jboss/amq-broker/etc 디렉터리에 있는 기본 artemis-users.properties 및 artemis- roles.properties 파일에서 이 정보를 복사할 수 있습니다.

     참고

     로그인 모듈에서 참조된 속성 파일은 브로커가 로그인 모듈을 처음 호출할 때만 로드됩니다. 브로커는 사용자를 인증할 로그인 모듈을 찾을 때까지 login.config 파일에 나열된 순서대로 로그인 모듈을 호출합니다. login.config 파일 끝에 Operator에서 사용하는 인증 정보가 포함된 login 모듈을 배치하면 브로커가 Operator를 인증할 때 이전의 모든 로그인 모듈이 호출됩니다. 결과적으로 속성 파일이 브로커에 표시되지 않음을 나타내는 상태 메시지가 지워집니다.

2. 생성한 login.config 파일에 properties 로그인 모듈이 포함된 경우 모듈에 지정된 사용자 및 역할 파일에 사용자 및 역할 정보가 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

   new-users.properties

   ruben=ruben01!
   anne=anne01!
   rick=rick01!
   bob=bob01!

   new-roles.properties

   admin=ruben, rick
   group1=bob
   group2=anne

3. oc create secret 명령을 사용하여 새 로그인 모듈 구성으로 생성한 텍스트 파일에서 시크릿을 생성합니다. 로그인 모듈 구성에 properties 로그인 모듈이 포함된 경우 시크릿에 연결된 사용자 및 역할 파일도 포함됩니다. 예를 들면 다음과 같습니다.

   oc create secret generic custom-jaas-config --from-file=login.config --from-file=new-users.properties --from-file=new-roles.properties

   참고

   Operator가 로그인 모듈 구성이 포함되어 있음을 인식하고 각 브로커 Pod에 업데이트를 전파할 수 있도록 시크릿 이름에 -jaas-config 접미사가 있어야 합니다.

   시크릿 생성 방법에 대한 자세한 내용은 Kubernetes 문서의 시크릿을 참조하십시오. https://kubernetes.io/docs/concepts/configuration/secret/

4. 브로커 배포의 CR(사용자 정의 리소스) 인스턴스에 생성한 시크릿을 추가합니다.

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

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

      2. 배포에 사용할 CR을 편집합니다.

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 왼쪽 창에서 Operators → Installed Operator 를 클릭합니다.
      3. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator를 클릭합니다.
      4. AMQ Broker 탭을 클릭합니다.
      5. ActiveMQArtemis 인스턴스 이름의 이름을 클릭합니다.

      6. YAML 탭을 클릭합니다.

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

5. extraMounts 요소 및 secrets 요소를 생성하고 시크릿 이름을 추가합니다. 다음 예제에서는 custom-jaas-config 라는 시크릿을 CR에 추가합니다.

   deploymentPlan:
     ...
     extraMounts:
       secrets:
       - "custom-jaas-config"
     ...

6. CR에서 브로커에 구성된 역할에 권한을 부여합니다.

   1. CR의 spec 섹션에 brokerProperties 요소를 추가하고 권한을 추가합니다. 단일 주소에 대한 역할 권한을 부여할 수 있습니다. 또는 # 기호를 사용하여 와일드카드를 지정하여 모든 주소에 역할 권한을 부여할 수 있습니다. 예를 들면 다음과 같습니다.

      spec:
        ...
        brokerProperties:
        - securityRoles.#.group2.send=true
        - securityRoles.#.group1.consume=true
        - securityRoles.#.group1.createAddress=true
        - securityRoles.#.group1.createNonDurableQueue=true
        - securityRoles.#.group1.browse=true
        ...

      이 예제에서 group2 역할에는 모든 주소에 대한 send 권한이 할당되고 group1 역할은 consume,createAddress,createNonDurableQueue 를 할당하고 모든 주소에 대한 권한을 찾습니다.

      참고

      Java 속성 파일에서 콜론(:)은 키/값 쌍의 키와 값을 구분하는 데 사용되는 예약된 문자입니다. 주소 이름과 콜론(::)으로 구분된 큐 이름으로 구성된 정규화된 큐 이름(FQQN)에 권한을 부여하려면 FQQN에서 콜론(\) 문자를 이스케이프하려면 백슬래시(\) 문자를 사용해야 합니다. 예를 들면 다음과 같습니다.

      spec:
        ...
        brokerProperties:
        - 'securityRoles."my-address\:\:my-queue".group2.send=true'

7. CR을 저장합니다.

   Operator는 각 Pod의 /amq/extra/secrets/시크릿 이름 디렉터리에 있는 시크릿에 login.config 파일을 마운트하고 기본 login.config 파일 대신 마운트된 login.config 파일을 읽도록 브로커 JVM을 구성합니다. login.config 파일에 properties 로그인 모듈이 포함된 경우 참조된 사용자 및 역할 속성 파일도 각 Pod에 마운트됩니다.

8. CR에서 상태 정보를 보고 배포의 브로커가 인증을 위해 시크릿에서 JAAS 로그인 모듈을 사용하고 있는지 확인합니다.

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

      1. 브로커의 CR에서 상태 조건을 가져옵니다.

         $ oc get activemqartemis -o yaml

   2. OpenShift 웹 콘솔 사용:

      1. CR에서 status 섹션으로 이동합니다.

   3. 상태 정보에서 브로커가 시크릿에 구성된 JAAS 로그인 모듈을 사용하고 있음을 나타내는 JaasPropertiesApplied 유형이 있는지 확인합니다. 예를 들면 다음과 같습니다.

      - lastTransitionTime: "2023-02-06T20:50:01Z"
        message: ""
        reason: Applied
        status: "True"
        type: JaasPropertiesApplied

      시크릿의 파일을 업데이트할 때 OpenShift Container Platform이 시크릿의 최신 파일을 각 브로커 포드에 전파할 때까지 reason 필드의 값이 OutofSync 로 표시됩니다. 예를 들어 new 사용자를 new-users-properties 파일에 추가하고 보안을 업데이트하는 경우 업데이트된 파일이 각 Pod로 전파될 때까지 다음 상태 정보가 표시됩니다.

      - lastTransitionTime: "2023-02-06T20:55:20Z"
        message: 'new-users.properties status out of sync, expected: 287641156, current: 2177044732'
        reason: OutOfSync
        status: "False"
        type: JaasPropertiesApplied

9. 시크릿에서 참조되는 속성 파일에서 사용자 또는 역할 정보를 업데이트할 때 oc set data 명령을 사용하여 보안을 업데이트합니다. login.config 파일을 포함하여 시크릿에 대한 모든 파일을 다시 읽어야 합니다. 예를 들어 이 절차의 앞부분에서 생성한 new-users.properties 파일에 새 사용자를 추가하는 경우 다음 명령을 사용하여 custom-jaas-config 시크릿을 업데이트합니다.

   oc set data secret/custom-jaas-config --from-file=login.config=login.config --from-file=new-users.properties=new-users.properties --from-file=new-roles.properties=new-roles.properties

프로세스

1. oc create secret 명령을 사용하여 추가하려는 타사 JAR 파일이 포함된 시크릿을 생성합니다. 예를 들면 다음과 같습니다.

   oc create secret generic log4j-template --from-file=log4j-layout-template-json-2.22.1.jar

   시크릿 생성 방법에 대한 자세한 내용은 Kubernetes 문서의 시크릿을 참조하십시오. https://kubernetes.io/docs/concepts/configuration/secret/

2. 브로커 배포에 대한 CR을 편집하고 각 브로커 Pod에 타사 JAR 파일이 포함된 시크릿을 마운트하도록 Operator를 구성합니다. 예를 들어 다음 구성은 log4j-template 이라는 시크릿을 마운트합니다.

   deploymentPlan:
     ...
     extraMounts:
       secrets:
       - "log4j-template"
     ...

   JAR 파일은 각 브로커 Pod의 /amq/extra/secrets/시크릿 이름 디렉터리에 마운트됩니다. 예를 들어 /amq/extra/secrets/postgresql-driver/log4j-template.jar.

3. ARTEMIS_EXTRA_LIBS 환경 변수를 생성하여 브로커의 Java 클래스 경로를 확장하여 브로커가 각 Pod의 마운트된 디렉터리에서 JAR 파일을 로드합니다. 예를 들면 다음과 같습니다.

   spec:
     ...
     env:
     - name: ARTEMIS_EXTRA_LIBS
       value: /amq/extra/secrets/log4j-template

4. CR을 저장합니다.

프로세스

1. 브로커 배포에 사용할 ActiveMQArtemis CR을 편집합니다.

2. 브로커 CR에서 extraVolumes 및 extraVolumeMounts 속성을 사용하여 영구 볼륨을 추가하고 각 브로커 Pod에 볼륨을 마운트합니다. 예를 들면 다음과 같습니다.

   deploymentPlan:
     ...
     extraVolumes:
     - name: extra-volume
       persistentVolumeClaim:
         claimName: extra-jars
     extraVolumeMounts:
     - name: extra-volume
       mountPath: /opt/extra-lib
     ...

3. resourceTemplates 특성을 사용하여 배포에 대한 StatefulSet 리소스를 사용자 지정합니다. 사용자 지정에서 init 컨테이너를 사용하여 각 Pod에서 생성한 추가 볼륨 볼륨을 마운트하고 JAR 파일을 볼륨으로 다운로드합니다. 예를 들면 다음과 같습니다.

   spec:
     ...
     resourceTemplates:
     - selector:
         kind: StatefulSet
       patch:
         kind: StatefulSet
         spec:
           template:
             spec:
               initContainers:
               - name: mysql-jdbc-driver-init
                 volumeMounts:
                 - mountPath: /opt/extra-lib
                   name: extra-volume
                 image: curlimages/curl:8.6.0
                 command:
                 - /bin/sh
                 args:
                 - -c
                 - "if ! [ -f /opt/extra-lib/mysql-connector.jar ]; then curl https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.23/mysql-connector-java-8.0.23.jar --output /opt/extra-lib/mysql-connector.jar ; fi"

   이 예제에서 curl 이미지는 파일이 볼륨에 없는 경우 mysql-connector.jar 파일을 볼륨의 마운트된 경로인 /opt/extra-lib 에 다운로드하는 데 사용됩니다.

4. ARTEMIS_EXTRA_LIBS 환경 변수를 생성하여 브로커가 공유 볼륨에서 JAR 파일을 로드하도록 브로커의 Java 클래스 경로를 확장합니다. 예를 들면 다음과 같습니다.

   spec:
     ...
     env:
     - name: ARTEMIS_EXTRA_LIBS
       value: /opt/extra-lib

5. CR을 저장합니다.

프로세스

1. 브로커 배포에 대한 ActiveMQArtemis CR(사용자 정의 리소스)을 편집합니다.

2. persistenceEnabled 특성을 true 로 설정합니다. 예를 들면 다음과 같습니다.

   spec:
     ...
     deploymentPlan:
       persistenceEnabled: true
     ...

3. CR을 저장합니다.

프로세스

1. 브로커 배포에 대한 ActiveMQArtemis CR(사용자 정의 리소스)을 편집합니다.

2. brokerProperties 속성을 사용하여 JDBC 데이터베이스 지속성을 활성화합니다. 예를 들면 다음과 같습니다.

   spec:
     ...
     brokerProperties:
     - storeConfiguration=DATABASE
     - storeConfiguration.jdbcDriverClassName=<class name>
     - storeConfiguration.jdbcConnectionUrl=jdbc:<URL>
     - HAPolicyConfiguration=SHARED_STORE_PRIMARY
     ...

   storeConfiguration

   JDBC 데이터베이스에 메시지를 유지하려면 DATABASE 값을 지정합니다.

   storeConfiguration.jdbcDriverClassName

   JDBC 데이터베이스 드라이버의 정규화된 클래스 이름입니다. 예를 들면 org.postgresql.Driver 입니다.

   지원되는 데이터베이스에 대한 자세한 내용은 Red Hat Customer Portal의 Red Hat AMQ 7 지원 구성 을 참조하십시오.

   storeConfiguration.jdbcConnectionUrl

   데이터베이스 이름 및 모든 구성 매개변수를 포함하여 데이터베이스 서버의 전체 JDBC 연결 URL입니다. 예를 들면 다음과 같습니다.

   JDBC:postgresql://postgresql-service.default.svc.cluster.local:5432/postgres?user=postgres&password=postgres

   이 예에서 데이터베이스 이름은 postgres 입니다.

   HAPolicyConfiguration

   SHARED_STORE_ PRI Cryostat로 설정하여 브로커가 JDBC 리스 잠금을 사용하여 데이터베이스 테이블을 여러 브로커의 동시 액세스로부터 보호합니다. 두 번째 브로커 인스턴스가 의도치 않게 배포되는 경우 리스 잠금을 통해 두 번째 브로커가 데이터베이스에 기록되지 않습니다.

3. (선택 사항) 필요한 경우 다음 속성의 기본값을 변경합니다.

   storeConfiguration.jdbcNetworkTimeout

   JDBC 네트워크 연결 제한 시간(밀리초)입니다. 기본값은 20000밀리초입니다.

   storeConfiguration.jdbcLockRenewPeriod

   현재 JDBC 잠금에 대한 갱신 기간의 길이(밀리초)입니다. 이 시간이 지나면 브로커는 잠금을 갱신할 수 있습니다. storeConfiguration.jdbcLockExpiration 값보다 여러 번 작은 값을 설정하여 브로커에게 리스를 연장할 수 있는 충분한 시간을 제공하고 브로커에게 연결 문제 발생 시 잠금을 갱신할 수 있는 시간을 제공합니다. 기본값은 2000밀리초입니다.

   storeConfiguration.jdbcLockExpiration

   storeConfiguration.jdbcLockRenewPeriod 의 값이 경과한 경우에도 현재 JDBC 잠금이 보유(즉, 획득 또는 갱신됨)로 간주되는 시간(밀리초)입니다. 브로커는 storeConfiguration.jdbcLockRenewPeriod 의 값에 따라 소유한 잠금을 주기적으로 갱신하려고 합니다. 예를 들어 연결 문제로 인해 브로커가 잠금을 갱신하지 못하면 브로커는 잠금을 성공적으로 획득하거나 갱신한 후 storeConfiguration.jdbcLockExpiration 의 값이 전달될 때까지 잠금을 갱신하려고 합니다. 위에서 설명한 갱신 동작의 예외는 다른 브로커가 잠금을 취득하는 경우입니다. 이는 DBMS(데이터베이스 관리 시스템)와 브로커 간에 시간 불일치가 있거나 가비지 수집에 대한 일시 중지가 긴 경우 발생할 수 있습니다. 이 경우 원래 잠금을 보유한 브로커는 잠금을 손실하고 갱신하려고 시도하지 않습니다. 만료 후 현재 소유하고 있는 브로커에 의해 JDBC 잠금이 갱신되지 않은 경우 다른 브로커는 JDBC 잠금을 설정할 수 있습니다. 기본값은 20000밀리초입니다.

   storeConfiguration.jdbcJournalSyncPeriod

   브로커 저널이 JDBC와 동기화되는 기간(밀리초)입니다. 기본값은 5밀리초입니다.

   storeConfiguration.jdbcMaxPageSizeBytes

   AMQ Broker가 JDBC 데이터베이스에 메시지를 저장할 때 각 페이지 파일의 최대 크기(바이트)입니다. 기본값은 102400이며, 이는 100KB입니다. 지정한 값은 "K" "MB" 및 "GB"와 같은 바이트 표기법도 지원합니다.

4. 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 인스턴스를 시작합니다. 왼쪽 창에서 Administration → Custom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.

      5. Create ActiveMQArtemis 를 클릭합니다.

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

   기본 브로커 배포의 경우 아래 표시된 구성과 유사할 수 있습니다.

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true

   broker_activemqartemis_cr.yaml 샘플 CR 파일에서 image 속성이 자리 표시자 의 기본값으로 설정되어 있는지 확인합니다. 이 값은 기본적으로 image 속성이 배포에 사용할 브로커 컨테이너 이미지를 지정하지 않음을 나타냅니다. Operator에서 사용할 적절한 브로커 컨테이너 이미지를 결정하는 방법을 알아보려면 2.7절. “Operator에서 컨테이너 이미지를 선택하는 방법” 를 참조하십시오.

2. 브로커 스토리지 크기를 지정하려면 CR의 deploymentPlan 섹션에서 storage 섹션을 추가합니다. size 속성을 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.

   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true
       storage:
         size: 4Gi

   storage.size

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

3. 각 브로커 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 구성을 완료하면 생성 을 클릭합니다.

프로세스

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 인스턴스를 시작합니다. 왼쪽 창에서 Administration → Custom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.

      5. Create ActiveMQArtemis 를 클릭합니다.

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

   기본 브로커 배포의 경우 아래 표시된 구성과 유사할 수 있습니다.

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true

   broker_activemqartemis_cr.yaml 샘플 CR 파일에서 image 속성이 자리 표시자 의 기본값으로 설정되어 있는지 확인합니다. 이 값은 기본적으로 image 속성이 배포에 사용할 브로커 컨테이너 이미지를 지정하지 않음을 나타냅니다. Operator에서 사용할 적절한 브로커 컨테이너 이미지를 결정하는 방법을 알아보려면 2.7절. “Operator에서 컨테이너 이미지를 선택하는 방법” 를 참조하십시오.

2. CR의 deploymentPlan 섹션에서 resources 섹션을 추가합니다. 제한 및 요청 하위 섹션을 추가합니다. 각 하위 섹션에 cpu 및 memory 속성을 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.

   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true
       resources:
         limits:
           cpu: "500m"
           memory: "1024M"
         requests:
           cpu: "250m"
           memory: "512M"

   limits.cpu

   배포에서 Pod에서 실행되는 각 브로커 컨테이너는 이 양의 호스트 노드 CPU 사용량을 초과할 수 없습니다.

   limits.memory

   배포에서 Pod에서 실행되는 각 브로커 컨테이너는 이 양의 호스트 노드 메모리 사용량을 초과할 수 없습니다.

   requests.cpu

   배포의 Pod에서 실행되는 각 브로커 컨테이너는 이 양의 host-node CPU를 요청합니다. 이 값은 브로커 컨테이너를 실행하는 데 필요한 최소 CPU 양입니다.

   requests.memory

   배포의 Pod에서 실행되는 각 브로커 컨테이너는 이 양의 호스트 노드 메모리를 요청합니다. 이 값은 브로커 컨테이너를 실행하는 데 필요한 최소 메모리 양입니다.

   참고

   리소스에 대한 제한을 지정하고 요청을 지정하지 않으면 브로커 컨테이너에서 해당 리소스에 대해 구성된 제한 값을 요청합니다. 예를 들어 다음 구성에서 브로커 컨테이너는 500m cpu 및 1024M 메모리의 구성된 제한 값을 요청합니다.

   spec:
     deploymentPlan:
       size: 3
       ...
       resources:
         limits:
           cpu: "500m"
           memory: "1024M"

   중요

   요청된 메모리 및 CPU의 정확한 양을 제어하고 배포에 여러 브로커가 있는 경우 각 브로커 컨테이너에 동일한 값이 요청되도록 요청을 설정하지 않고 제한을 설정합니다.

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 구성을 완료하면 생성 을 클릭합니다.

프로세스

1. 브로커 배포에 대한 ActiveMQArtemis CR(사용자 정의 리소스)을 편집합니다.

2. acceptors 특성에 이름이 지정된 어셉터를 추가합니다. 프로토콜 및 포트 속성을 추가합니다. 값을 설정하여 어셉터에서 사용할 메시징 프로토콜과 해당 프로토콜에 노출할 각 브로커 Pod의 포트를 지정합니다. 예를 들면 다음과 같습니다.

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

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

   표 4.4. acceptor 프로토콜

   프로토콜	현재의
   코어 프로토콜	코어
   AMQP	amqp
   OpenWire	OpenWire
   MQTT	mqtt
   STOMP	stomp
   지원되는 모든 프로토콜	all

   참고
   • 배포의 각 브로커 Pod에 대해 Operator는 포트 61616을 사용하는 기본 수락자도 생성합니다. 이 기본 수락자는 브로커 클러스터링에 필요하며 코어 프로토콜이 활성화되어 있습니다.
   • 기본적으로 AMQ Broker 관리 콘솔은 브로커 Pod에서 포트 8161을 사용합니다. 배포의 각 브로커 포드에는 콘솔에 대한 액세스를 제공하는 전용 서비스가 있습니다. 자세한 내용은 5장. Operator 기반 브로커 배포를 위한 AMQ 관리 콘솔에 연결의 내용을 참조하십시오.

3. 동일한 수락자에서 다른 프로토콜을 사용하려면 protocols 속성을 수정합니다. 쉼표로 구분된 프로토콜 목록을 지정합니다. 예를 들면 다음과 같습니다.

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

   구성된 수락자는 이제 포트 5672를 AMQP 및 OpenWire 클라이언트에 노출합니다.

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

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

5. 기본적으로 수락자는 브로커 배포와 동일한 OpenShift 클러스터의 클라이언트에만 노출됩니다. OpenShift 외부의 클라이언트에 어셉터도 노출하려면 expose 속성과 sslEnabled 속성을 모두 true 로 설정합니다.

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

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

   • OpenShift 클러스터에 인증 자격 증명을 저장하는 데 사용되는 시크릿 이름입니다. 수락자에서 SSL을 활성화할 때 시크릿이 필요합니다.
   • 보안 네트워크 통신에 사용할 TLS(Transport Layer Security) 프로토콜입니다. TLS는 더 안전한 SSL 버전입니다. enabledProtocols 속성에 TLS 프로토콜을 지정합니다.
   • 수락자가 브로커와 클라이언트 간의 상호 인증이라고도 하는 mTLS를 사용하는지 여부입니다. needClientAuth 속성 값을 true 로 설정하여 이 값을 지정합니다.

   이러한 작업에 대한 자세한 내용은 4.12.2절. “broker-client 연결 보안” 을 참조하십시오.

   OpenShift 외부의 클라이언트에 어셉터를 노출하면 Operator는 배포의 각 브로커 Pod에서 수락자를 위한 전용 서비스와 Openshift 경로를 자동으로 생성합니다.

6. 각 pod에서 허용자가 Openshift 클러스터의 내부 라우팅 구성과 일치하도록 허용되는 경로의 호스트 이름을 사용자 지정하려면 다음 중 하나 또는 둘 다를 수행할 수 있습니다.

   • ingressHost 특성을 사용하여 기본 호스트 이름을 특정 수락자의 사용자 지정 호스트 이름으로 바꿉니다.

   • ingressDomain 특성을 사용하여 호스트 이름에 사용자 지정 도메인을 추가합니다. 사용자 정의 도메인은 CR 구성에 의해 노출되는 다른 어셉터 및 콘솔과 같은 다른 모든 경로에도 적용됩니다.

     1. acceptor 경로에 사용자 정의 호스트 이름을 설정하려면 ingressHost 속성을 추가하고 호스트 문자열을 지정합니다. 예를 들면 다음과 같습니다.

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

        참고

        ingressHost 값은 Openshift 클러스터에서 고유해야 합니다. 브로커 클러스터에 브로커 Pod가 여러 개 있는 경우 값에 $(BROKER_ORDINAL) 변수를 포함하여 ingressHost 값을 고유하게 만들 수 있습니다. Operator는 각 브로커 Pod의 이 변수를 Pod에 할당된 StatefulSet의 서수로 바꿉니다. 예를 들어, my-acceptor-$(BROKER_ORDINAL)-production.my-subdomain.com의 ingressHost 값을 첫 번째 Pod의 my-acceptor-0-production.my-subdomain 으로 설정합니다. my-acceptor-1-production.my-subdomain은 두 번째 Pod의 my-acceptor-1-production.my-subdomain 으로 설정합니다.

        허용자 경로에 대한 사용자 정의 호스트 이름 문자열에 다음 변수를 포함할 수 있습니다.

        표 4.5. acceptor 경로에 대한 사용자 정의 호스트 이름 문자열의 변수

        이름	설명
        $(CR_NAME)	CR의 metadata.name 속성 값입니다.
        $(CR_NAMESPACE)	사용자 정의 리소스의 네임스페이스입니다.
        $(BROKER_ORDINAL)	StatefulSet에서 브로커 Pod에 할당한 서수입니다.
        $(ITEM_NAME)	수락자의 이름입니다.
        $(RES_TYPE)	리소스 유형입니다. 경로에는 rte 의 리소스 유형이 있습니다. 수신에는 리소스 유형의 ing 이 있습니다.
        $(INGRESS_DOMAIN)	CR에 구성된 경우 spec.ingressDomain 속성의 값입니다.

     2. 경로의 호스트 이름에 사용자 정의 도메인을 추가하려면 spec.ingressDomain 속성을 추가하고 사용자 정의 문자열을 지정합니다. 예를 들면 다음과 같습니다.

        spec:
          ...
          ingressDomain: my.domain.com

7. 조직의 네트워크 정책에서 경로 대신 Ingress를 사용하여 수락자를 노출해야 하는 경우 다음 단계를 완료합니다.

   1. exposeMode 속성을 추가하고 값을 ingress 로 설정합니다.

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

   2. 허용자가 Openshift 클러스터의 내부 라우팅 구성과 일치하도록 노출된 Ingress의 호스트 이름을 사용자 지정하려면 다음 중 하나 또는 둘 다를 수행할 수 있습니다.

      • ingressHost 특성을 사용하여 기본 호스트 이름을 사용자 지정 호스트 이름으로 교체합니다.

      • ingressDomain 특성을 사용하여 호스트 이름에 사용자 지정 도메인을 추가합니다. 사용자 정의 도메인은 CR 구성에 의해 노출되는 다른 어셉터 및 콘솔의 Ingress와 같은 기타 모든 수신에도 적용됩니다.

        1. acceptor의 Ingress에 대한 사용자 정의 호스트 이름을 설정하려면 ingressHost 속성을 추가하고 호스트 문자열을 지정합니다. 예를 들면 다음과 같습니다.

           spec:
             ...
             acceptors:
             - name: my-acceptor
               protocols: amqp,openwire
               port: 5672
               connectionsAllowed: 5
               expose: true
               exposeMode: ingress
               ingressHost: my-acceptor-production.my-subdomain.com
             ...

           동일한 변수를 포함하여 이 절차의 앞부분에서 설명하는 경로 호스트로 수신 호스트를 사용자 지정할 수 있습니다.

        2. Ingress의 호스트 이름에 사용자 정의 도메인을 추가하려면 spec.ingressDomain 속성을 추가하고 사용자 지정 문자열을 지정합니다. 예를 들면 다음과 같습니다.

           spec:
             ...
             ingressDomain: my-subdomain.domain.com

           어셉터의 경우 수신의 기본 호스트 이름은 < cr-name>-<acceptor name>-<ordinal>-svc-ing-<namespace > 형식으로 되어 있습니다. 예를 들어 amqbroker 네임 스페이스에 production 이라는 CR이 있는 경우 mydomain.com 의 ingressDomain 값은 Pod 0에서 생성된 수신에 대해 production-wconsj-0-svc-svc-mynamespace.amqbroker.com 의 호스트 값을 제공합니다.

프로세스

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

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

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

   2. OpenShift Container Platform 웹 콘솔 사용:

      1. 왼쪽 탐색 메뉴에서 Administration → Custom 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 값을 기반으로 수락자가 204800바이트보다 크거나 같은 본문이 있는 AMQP 메시지를 수신하는 경우 브로커는 메시지를 큰 메시지로 저장합니다.

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

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

   amqpMinLargeMessageSize 를 값 -1 로 설정하면 AMQP 메시지의 대규모 메시지 처리가 비활성화됩니다.

프로세스

1. 브로커 배포의 CR 인스턴스를 편집합니다.

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

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

      2. 배포에 사용할 CR을 편집합니다.

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform 웹 콘솔 사용:

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

      6. YAML 탭을 클릭합니다.

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

2. CR의 deploymentPlan 섹션에서 startupProbe 섹션을 추가합니다. 예를 들면 다음과 같습니다.

   spec:
     deploymentPlan:
       startupProbe:
         exec:
           command:
             - /bin/bash
             - '-c'
             - /opt/amq/bin/artemis
             - 'check'
             - 'node'
             - '--up'
             - '--url'
             - 'tcp://$HOSTNAME:61616'
         initialDelaySeconds: 5
         periodSeconds: 10
         timeoutSeconds: 3
         failureThreshold: 30

   command

   컨테이너 내에서 실행할 startup probe 명령입니다. 이 예에서 시작 프로브는 Artemis check node 명령을 사용하여 브로커 Pod의 컨테이너에서 AMQ Broker가 시작되었는지 확인합니다.

   initialDelaySeconds

   컨테이너가 시작된 후 프로브가 실행되기 전에 지연(초)입니다. 기본값은 0입니다.

   periodSeconds

   프로브가 실행되는 간격(초)입니다. 기본값은 10입니다.

   timeoutSeconds

   시작 프로브 명령이 브로커의 응답을 기다리는 시간(초)입니다. 명령에 대한 응답이 수신되지 않으면 명령이 종료됩니다. 기본값은 1 입니다.

   failureThreshold

   프로브가 실패한 것으로 간주되는 시작 프로브의 시간 초과를 포함한 최소 연속 실패입니다. 프로브가 실패한 것으로 간주되면 Pod를 다시 시작합니다. 기본값은 3입니다.

   클러스터의 리소스 및 브로커 저널 크기에 따라 브로커가 프로브 검사를 시작하고 전달할 수 있도록 실패 임계값을 늘려야 할 수 있습니다. 그렇지 않으면 브로커가 실패 임계값에 반복적으로 도달하고 시작 프로브에 의해 매번 브로커가 다시 시작되는 루프 조건을 입력합니다. 예를 들어 failureThreshold 를 30 으로 설정하고 프로브가 기본 간격인 10초에서 실행되는 경우 브로커는 300초로 시작하여 프로브 확인을 전달합니다.

3. CR을 저장합니다.

프로세스

1. 브로커 배포의 CR 인스턴스를 편집합니다.

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

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

      2. 배포에 사용할 CR을 편집합니다.

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform 웹 콘솔 사용:

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

2. 활성 프로브를 구성하려면 CR의 deploymentPlan 섹션에 livenessProbe 섹션을 추가합니다. 예를 들면 다음과 같습니다.

   spec:
     deploymentPlan:
       livenessProbe:
         initialDelaySeconds: 5
         periodSeconds: 5
         failureThreshold: 30

   initialDelaySeconds

   컨테이너가 시작된 후 프로브가 실행되기 전에 지연(초)입니다. 기본값은 5 입니다.

   참고

   배포에 시작 프로브도 구성된 경우 활성 상태 프로브와 준비 상태 프로브 모두에 대해 지연을 0으로 설정할 수 있습니다. 이러한 두 프로브는 시작 프로브가 전달된 후에만 실행됩니다. 시작 프로브가 이미 통과된 경우 브로커가 성공적으로 시작되었으므로 활성 상태 프로브 및 준비 상태 프로브 실행 지연이 필요하지 않습니다.

   periodSeconds

   프로브가 실행되는 간격(초)입니다. 기본값은 5 입니다.

   failureThreshold

   프로브를 나타내는 활성 프로브의 시간 초과를 포함한 최소 연속 실패가 실패했습니다. 프로브가 실패하면 Pod를 다시 시작합니다. 기본값은 3입니다.

   배포에 활성 프로브가 실행되기 전에 브로커 애플리케이션이 시작되었는지 확인하는 시작 프로브가 구성되지 않은 경우 브로커가 활성 상태 프로브 검사를 시작하고 전달할 수 있도록 실패 임계값을 늘려야 할 수 있습니다. 그렇지 않으면 브로커는 실패 임계값에 반복적으로 도달하고 활성 상태 프로브에 의해 매번 브로커 Pod를 다시 시작하는 루프 조건을 입력할 수 있습니다.

   브로커가 활성 상태 프로브 검사를 시작하고 전달하는 데 필요한 시간은 클러스터의 리소스 및 브로커 저널 크기에 따라 다릅니다. 예를 들어 failureThreshold 를 30으로 설정하고 프로브가 기본 5초 간격으로 실행되는 경우 브로커는 150초 동안 활성 상태 프로브 검사를 시작하고 전달합니다.

   참고

   활성 상태 프로브를 구성하지 않거나 구성된 프로브에서 처리기가 없는 경우 AMQ Broker 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 check 명령줄 유틸리티를 활성 상태 또는 준비 상태 프로브 구성에 추가합니다.

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

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

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

      참고

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

   2. 메시지를 생성하고 사용하는 상태 점검을 구성하려면 활성Probe 또는 readinessProbe 섹션에서 브로커 파일 시스템의 상태를 검증 합니다. exec 섹션에서 command 섹션을 추가합니다. 명령 섹션에서 Artemis check queue 명령 구문을 추가합니다. 예를 들면 다음과 같습니다.

      spec:
        deploymentPlan:
          readinessProbe:
            exec:
              command:
                - bash
                - '-c'
                - /home/jboss/amq-broker/bin/artemis
                - check
                - queue
                - '--name'
                - livenessqueue
                - '--produce'
                - "1"
                - '--consume'
                - "1"
                - '--silent'
                - '--user'
                - $AMQ_USER
                - '--password'
                - $AMQ_PASSWORD
            initialDelaySeconds: 30
            timeoutSeconds: 5

      참고

      지정한 큐 이름은 브로커에 구성되어야 하며 anycast 의 routingType 이 있어야 합니다. 예를 들면 다음과 같습니다.

      apiVersion: broker.amq.io/v1beta1
      kind: ActiveMQArtemisAddress
      metadata:
        name: livenessqueue
        namespace: activemq-artemis-operator
      spec:
        addressName: livenessqueue
        queueConfiguration:
          purgeOnNoConsumers: false
          maxConsumers: -1
          durable: true
          enabled: true
        queueName: livenessqueue
        routingType: anycast

5. CR을 저장합니다.

1. 배포의 의도적인 스케일 다운으로 인해 배포의 브로커 Pod가 종료되면 Operator는 메시지 마이그레이션을 준비하기 위해 스케일 다운 사용자 정의 리소스를 자동으로 배포합니다.

2. 고립된 PV(영구 볼륨)를 확인하려면 scaledown 컨트롤러에서 볼륨 클레임의 서신을 확인합니다. 컨트롤러는 볼륨 클레임의 ordinal을 프로젝트의 StatefulSet(즉, 브로커 클러스터)에서 여전히 실행 중인 브로커 Pod의 것과 비교합니다.

   볼륨 클레임의 ordinal이 브로커 클러스터에서 계속 실행 중인 브로커 Pod의 서수보다 높으면 scaledown 컨트롤러에서 해당 ordinal의 브로커 Pod가 종료되었으며 메시징 데이터를 다른 브로커 Pod로 마이그레이션해야 합니다.

3. scaledown 컨트롤러는 drainer Pod를 시작합니다. drainer Pod는 클러스터의 다른 라이브 브로커 Pod 중 하나에 연결하고 해당 라이브 브로커 Pod로 메시지를 마이그레이션합니다.

프로세스

1. 브로커 배포의 CR 인스턴스를 편집합니다.

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

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

      2. 배포에 사용할 CR을 편집합니다.

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform 웹 콘솔 사용:

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

      6. YAML 탭을 클릭합니다.

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

2. CR의 deploymentPlan 섹션에서 messageMigration 속성을 추가하고 true 로 설정합니다. 아직 구성되지 않은 경우 persistenceEnabled 특성을 추가하고 true 로 설정합니다. 예를 들면 다음과 같습니다.

   spec:
     deploymentPlan:
       messageMigration: true
       persistenceEnabled: true
     ...

   이러한 설정은 나중에 클러스터형 브로커 배포 크기를 축소할 때 Operator는 확장 컨트롤러를 자동으로 시작하고 여전히 실행 중인 브로커 Pod로 메시지를 마이그레이션합니다.

3. CR을 저장합니다.

4. (선택 사항) 클러스터를 축소하고 메시지 마이그레이션 프로세스를 보려면 다음 단계를 완료합니다.

   1. 기존 브로커 배포에서 실행 중인 포드를 확인합니다.

      $ 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입니다.

   2. 각 Pod에 로그인하고 각 브로커에 일부 메시지를 보냅니다.

      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

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

      위의 명령은 각 브로커에서 queue이라는 큐 를 생성하고 각 큐에 1000개의 메시지를 추가합니다.

   4. 클러스터를 두 브로커에서 1개로 축소합니다.

      1. 기본 브로커 CR, broker_activemqartemis_cr.yaml 을 엽니다.
      2. CR에서 deploymentPlan.size 를 1 로 설정합니다.

      3. 명령줄에서 변경 사항을 적용합니다.

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

         Pod ex-aao-sss-1 이 종료되기 시작합니다. scaledown 컨트롤러는 동일한 이름의 새 드레이닝 Pod를 시작합니다. 이 드레인러 Pod는 브로커 Pod ex-aao-sss-1에서 클러스터의 다른 브로커 Pod인 ex- aao-ss-0 으로 모든 메시지를 마이그레이션한 후 종료됩니다.

   5. drainer Pod가 종료되면 브로커 Pod의 ex-aao-sss-0 의 메시지 수를 확인합니다. 드레인러 Pod가 종료된 브로커 Pod에서 1000개의 메시지를 성공적으로 마이그레이션했음을 나타내는 큐의 메시지 수가 2000개입니다.

프로세스

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 인스턴스를 시작합니다. 왼쪽 창에서 Administration → Custom 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 구성을 완료하면 생성 을 클릭합니다.

프로세스

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 인스턴스를 시작합니다. 왼쪽 창에서 Administration → Custom Resource Definitions 를 클릭합니다.
      3. ActiveMQArtemis CRD를 클릭합니다.
      4. Instances 탭을 클릭합니다.

      5. Create ActiveMQArtemis 를 클릭합니다.

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

2. CR의 deploymentPlan 섹션에서 tolerations 섹션을 추가합니다. 허용 오차 섹션에서 일치하려는 노드 테인트에 대한 허용 오차를 추가합니다. 예를 들면 다음과 같습니다.

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

   이 예에서 허용 오차는 app=amq-broker:NoSchedule 의 노드 테인트와 일치하므로 이 테인트가 구성된 노드에서 Pod를 예약할 수 있습니다.

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 구성을 완료하면 생성 을 클릭합니다.

프로세스

1. 브로커에 적용할 brokerProperties 구성이 포함된 Java 속성 형식으로 파일을 생성합니다. 속성 파일에서 각 속성을 별도의 줄에 추가합니다. 예를 들면 다음과 같습니다.

   securityRoles.address1.group2.send=true
   securityRoles.address2.group1.consume=true
   securityRoles.address2.group2.createAddress=true

2. .properties 확장자를 사용하여 파일을 저장합니다(예: securityRoles.properties ).

3. 생성한 .properties 파일이 포함된 보안을 생성합니다.

   oc create secret generic address-settings-bp --from-file=securityRoles.properties

   참고

   시크릿 이름에는 -bp 접미사가 있어야 합니다. 시크릿에 -bp 접미사가 있는 경우 Operator는 브로커가 브로커 Pod에 마운트된 디렉터리에서 속성 파일을 검색하도록 구성합니다.

4. Operator가 각 브로커 Pod의 시크릿에 있는 속성 파일을 마운트하도록 extraMounts 속성 속성의 보안에 대한 참조를 추가합니다.

   deploymentPlan:
     ...
     extraMounts:
       secrets:
       - "address-settings-bp"
     ...

   Operator는 시크릿에 있는 .properties 파일을 각 브로커 Pod의 /amq/extra/secrets/ <secret name > 디렉터리에 마운트합니다.

   시작 시 브로커는 .properties 확장자가 있는 파일을 각각 마운트하고, 파일을 알파벳순으로 정렬하고, 파일의 구성을 차례로 적용합니다. 속성 파일 내에서 브로커는 속성이 나열된 순서대로 적용됩니다.

프로세스

1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.
2. 프로젝트에서 기존 AMQ Broker Operator를 설치 제거합니다.
3. 왼쪽 탐색 메뉴에서 Operators → Installed Operators 를 클릭합니다.
4. 페이지 상단에 있는 프로젝트 드롭다운 메뉴에서 Operator를 제거할 프로젝트를 선택합니다.
5. 설치하려는 Red Hat Integration - AMQ Broker 인스턴스를 찾습니다.

6. Operator 인스턴스의 경우 오른쪽에서 더 많은 옵션 아이콘(세 개의 수직 점)을 클릭합니다. Operator 설치 제거를 선택합니다.

   주의

   이 Operator의 모든 피연산자 인스턴스 삭제 확인란이 선택 되지 않았는지 확인합니다. 이 확인란이 선택되면 Operator가 관리하는 브로커 인스턴스가 Operator가 제거될 때 삭제됩니다.

7. 확인 대화 상자에서 설치 제거를 클릭합니다.
8. OperatorHub를 사용하여 AMQ Broker 7.12용 Operator의 최신 버전을 설치합니다. 자세한 내용은 3.3.2절. “OperatorHub에서 Operator 배포”의 내용을 참조하십시오.
9. 왼쪽 탐색 메뉴에서 Operators → Installed Operators 를 클릭합니다.
10. 설치된 Red Hat Integration - AMQ Broker 인스턴스에 올바른 버전 번호가 표시되는지 확인합니다.

프로세스

1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.

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

   1. 왼쪽 탐색 메뉴에서 Operators → Installed Operators 를 클릭합니다.
   2. 페이지 상단에 있는 프로젝트 드롭다운 메뉴에서 Operator를 제거할 프로젝트를 선택합니다.
   3. 설치하려는 Red Hat Integration - AMQ Broker 인스턴스를 찾습니다.
   4. Operator 인스턴스의 경우 오른쪽에서 더 많은 옵션 아이콘(세 개의 수직 점)을 클릭합니다. 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. --cascade=orphan 옵션을 사용하여 StatefulSet을 삭제하여 브로커 Pod를 분리합니다. 분리된 브로커 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. 배포에 사용할 CR을 편집합니다.

            oc edit ActiveMQArtemis <statefulset name> -n <namespace>

         3. CR의 deploymentPlan.labels 요소에서 application 또는 ActiveMQArtemis 라는 사용자 지정 레이블을 삭제합니다.
         4. CR을 저장합니다.

      2. OpenShift Container Platform 웹 콘솔 사용:

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

         6. YAML 탭을 클릭합니다.

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

         7. CR의 deploymentPlan.labels 요소에서 application 또는 ActiveMQArtemis 라는 사용자 지정 레이블을 삭제합니다.
         8. 저장을 클릭합니다.

5. OperatorHub를 사용하여 AMQ Broker 7.12용 Operator의 최신 버전을 설치합니다. 자세한 내용은 3.3.2절. “OperatorHub에서 Operator 배포”의 내용을 참조하십시오.

   새 Operator는 이전 브로커 배포를 인식하고 관리할 수 있습니다. CR의 image 또는 version 필드에 값을 설정하면 Operator 조정 프로세스에서 Operator가 시작될 때 브로커 Pod를 해당 이미지로 업그레이드합니다. 자세한 내용은 6.6절. “브로커 컨테이너 이미지의 자동 업그레이드 제한”의 내용을 참조하십시오. 그러지 않으면 Operator가 각 브로커 Pod를 최신 컨테이너 이미지로 업그레이드합니다.

   참고

   조정 프로세스가 시작되지 않으면 배포를 스케일링하여 프로세스를 시작할 수 있습니다. 자세한 내용은 3.4.1절. “기본 브로커 인스턴스 배포”의 내용을 참조하십시오.

6. 필요에 따라 업그레이드된 브로커에서 사용할 수 있는 새로운 기능의 CR에 속성을 추가합니다.

프로세스

1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.

2. 기본 브로커 CR에 deploymentPlan.labels 속성에 application 또는 ActiveMQArtemis 라는 레이블이 있는지 확인합니다.

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

3. 이러한 사용자 정의 레이블이 기본 브로커 CR에 구성되지 않은 경우 OperatorHub를 사용하여 AMQ Broker 7.12용 Operator의 최신 버전을 설치합니다. 자세한 내용은 3.3.2절. “OperatorHub에서 Operator 배포”의 내용을 참조하십시오.

4. 이러한 사용자 정의 라벨 중 하나가 기본 브로커 CR에 구성된 경우 새 Operator를 설치하기 전에 기존 Operator를 제거하려면 다음 단계를 완료하고 올바른 Pod 레이블을 복원하고 CR에서 라벨을 제거합니다.

   참고

   Operator를 설치 제거하면 Operator가 StatefulSet을 삭제하지 않고 사용자 정의 라벨을 제거하여 기존 브로커 Pod도 삭제하여 임시 브로커가 중단될 수 있습니다.

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

      1. 왼쪽 탐색 메뉴에서 Operators → Installed Operators 를 클릭합니다.
      2. 페이지 상단에 있는 프로젝트 드롭다운 메뉴에서 Operator를 제거할 프로젝트를 선택합니다.
      3. 설치하려는 Red Hat Integration - AMQ Broker 인스턴스를 찾습니다.
      4. Operator 인스턴스의 경우 오른쪽에서 더 많은 옵션 아이콘(세 개의 수직 점)을 클릭합니다. 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. 배포에 사용할 CR을 편집합니다.

            oc edit ActiveMQArtemis <statefulset name> -n <namespace>

         3. CR의 deploymentPlan.labels 속성에서 application 또는 ActiveMQArtemis 라는 사용자 지정 레이블을 삭제합니다.
         4. CR 파일을 저장합니다.

      2. OpenShift Container Platform 웹 콘솔 사용:

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

         6. YAML 탭을 클릭합니다.

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

         7. CR의 deploymentPlan.labels 속성에서 application 또는 ActiveMQArtemis 라는 사용자 지정 레이블을 삭제합니다.
         8. 저장을 클릭합니다.

5. OperatorHub를 사용하여 AMQ Broker 7.12용 Operator의 최신 버전을 설치합니다. 자세한 내용은 3.3.2절. “OperatorHub에서 Operator 배포”의 내용을 참조하십시오.

   새 Operator는 이전 브로커 배포를 인식하고 관리할 수 있습니다. CR의 image 또는 version 필드에 값을 설정하면 Operator 조정 프로세스에서 Operator가 시작될 때 브로커 Pod를 해당 이미지로 업그레이드합니다. 자세한 내용은 6.6절. “브로커 컨테이너 이미지의 자동 업그레이드 제한”의 내용을 참조하십시오. 그러지 않으면 Operator가 각 브로커 Pod를 최신 컨테이너 이미지로 업그레이드합니다.

   참고

   조정 프로세스가 시작되지 않으면 배포를 스케일링하여 프로세스를 시작할 수 있습니다. 자세한 내용은 3.4.1절. “기본 브로커 인스턴스 배포”의 내용을 참조하십시오.

6. 필요에 따라 업그레이드된 브로커에서 사용할 수 있는 새로운 기능의 CR에 속성을 추가합니다.

프로세스

1. 웹 브라우저에서 AMQ Broker 7.12.3 의 소프트웨어 다운로드 페이지로 이동합니다.
2. 버전 드롭다운 목록의 값이 7.12.3 으로 설정되고 릴리스 탭이 선택되어 있는지 확인합니다.

3. AMQ Broker 7.12.3 Operator 설치 및 예제 파일 옆에 있는 Download 를 클릭합니다.

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

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

   $ mkdir ~/broker/operator
   $ mv amq-broker-operator-7.12.3-ocp-install-examples-rhel8.zip ~/broker/operator

5. 선택한 설치 디렉터리에서 아카이브의 내용을 추출합니다. 예를 들면 다음과 같습니다.

   $ cd ~/broker/operator
   $ unzip amq-broker-operator-operator-7.12.3-ocp-install-examples-rhel8.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의 이름은 기본적으로 amq-broker-controller-manager 입니다. 이전 배포의 Operator 이름이 amq-broker-controller-manager 가 아닌 경우 amq-broker-controller-manager 의 모든 인스턴스를 이전 Operator 이름으로 교체합니다. 예를 들면 다음과 같습니다.

    spec:
      ...
      selector
        matchLabels
          name: amq-broker-operator
      ...

11. 새 operator.yaml 파일에서 Operator의 서비스 계정 이름은 amq-broker-controller-manager 입니다. 이전 버전에서는 Operator의 서비스 계정 이름은 amq-broker-operator 였습니다.

    1. 이전 배포에서 서비스 계정 이름을 사용하려면 새 operator.yaml 파일의 서비스 계정 이름을 이전 배포에서 사용된 이름으로 교체합니다. 예를 들면 다음과 같습니다.

       spec:
         ...
         serviceAccountName: amq-broker-operator
         ...

    2. 새 서비스 계정 이름, amq-broker-controller-manager 를 Operator에 사용하려면 프로젝트에서 서비스 계정, 역할 및 역할 바인딩을 업데이트합니다.

       $ oc apply -f deploy/service_account.yaml

       $ oc apply -f deploy/role.yaml

       $ oc apply -f deploy/role_binding.yaml

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

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

       참고

       Operator를 삭제해도 Operator에서 관리하는 브로커 인스턴스는 제거되지 않습니다.

    2. --cascade=orphan 옵션을 사용하여 StatefulSet을 삭제하여 브로커 Pod를 분리합니다. 분리된 브로커 Pod는 StatefulSet이 삭제된 후에도 계속 실행됩니다.

       $ oc delete statefulset <statefulset-name> --cascade=orphan

14. AMQ Broker Operator 7.10.0 또는 7.10.1에서 업그레이드하는 경우 기본 브로커 CR에 deploymentPlan.labels 속성에 구성된 애플리케이션 또는 ActiveMQArtemis 라는 레이블이 있는지 확인합니다.

    이러한 라벨은 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

15. 업데이트된 Operator 구성을 적용합니다.

    $ oc apply -f deploy/operator.yaml

16. 필요에 따라 업그레이드된 브로커에서 사용할 수 있는 새로운 기능의 CR에 속성을 추가합니다.

프로세스

1. 브로커 배포의 기본 브로커 CR 인스턴스를 편집합니다.

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

      1. 브로커 배포를 위해 프로젝트에서 CR을 편집하고 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

         $ oc login -u <user> -p <password> --server=<host:port>

      2. CR을 편집합니다.

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 왼쪽 창에서 Operators → Installed Operator 를 클릭합니다.
      3. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator를 클릭합니다.
      4. AMQ Broker 탭을 클릭합니다.
      5. ActiveMQArtemis 인스턴스 이름의 이름을 클릭합니다.

      6. YAML 탭을 클릭합니다.

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

         참고

         CR의 status 섹션에서 .status.version.brokerVersion 필드에 현재 배포된 AMQ Broker 버전이 표시됩니다.

2. spec.version 속성에서 Operator가 배포의 브로커 및 init 컨테이너 이미지를 업그레이드할 수 있는 버전을 지정합니다. 다음은 지정할 수 있는 값의 예입니다.

   예

   다음 예에서 Operator는 배포의 현재 컨테이너 이미지를 7.12.0으로 업그레이드합니다.

   spec:
      version: '7.12.0'
       ...

   다음 예에서 Operator는 배포의 현재 컨테이너 이미지를 사용 가능한 최신 7.11.x 이미지로 업그레이드합니다. 예를 들어 배포에서 7.11.1 컨테이너 이미지를 사용하는 경우 Operator는 이미지를 7.11.6으로 자동 업그레이드하지만 7.12.3으로 업그레이드하지 않습니다.

   spec:
       version: '7.11'
       ...

   다음 예에서 Operator는 배포의 현재 컨테이너 이미지를 최신 7.x.x 이미지로 업그레이드합니다. 예를 들어 배포에서 7.11.6 이미지를 사용하는 경우 Operator는 이미지를 7.12.3으로 자동으로 업그레이드합니다.

   spec:
       version: '7'
       ...

   참고

   컨테이너 이미지의 마이너 버전(예: 7.11.x에서 7.12.x) 간에 업그레이드하려면 새 컨테이너 이미지와 동일한 마이너 버전이 있는 Operator가 필요합니다. 예를 들어 7.11.6에서 7.12.3으로 업그레이드하려면 7.12.x Operator를 설치해야 합니다.

3. CR을 저장합니다.

프로세스

1. Operator에서 현재 이미지를 업그레이드할 수 있는 브로커 및 init 컨테이너 이미지의 URL을 가져옵니다.

   1. Red Hat Catalog에서 브로커 컨테이너 구성 요소 페이지: AMQ Broker for RHEL 8(Multiarch) 을 엽니다.
   2. 아키텍처 드롭다운 메뉴에서 아키텍처를 선택합니다.
   3. 태그 드롭다운에서 설치하려는 이미지에 해당하는 태그를 선택합니다. 태그는 릴리스 날짜를 기반으로 하는 시간순으로 표시됩니다. 태그는 릴리스 버전과 할당된 태그로 구성됩니다.
   4. 이 이미지 가져오기 탭을 엽니다.
   5. Manifest 필드에서 복사 아이콘을 클릭합니다.
   6. URL을 텍스트 파일에 붙여넣습니다.
   7. Red Hat Catalog에서 init 컨테이너 구성 요소 페이지를 엽니다. AMQ Broker Init for RHEL 8 (Multiarch)
   8. init 컨테이너 이미지의 URL을 가져오려면 다음 단계를 반복하여 브로커 컨테이너 이미지의 URL을 가져옵니다.

2. 브로커 배포의 기본 브로커 CR 인스턴스를 편집합니다.

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

      1. 브로커 배포를 위해 프로젝트에서 CR을 편집하고 배포할 수 있는 권한이 있는 사용자로 OpenShift에 로그인합니다.

         $ oc login -u <user> -p <password> --server=<host:port>

      2. CR을 편집합니다.

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform 웹 콘솔 사용:

      1. 브로커 배포를 위해 프로젝트에 CR을 배포할 권한이 있는 사용자로 콘솔에 로그인합니다.
      2. 왼쪽 창에서 Operators → Installed Operator 를 클릭합니다.
      3. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator를 클릭합니다.
      4. AMQ Broker 탭을 클릭합니다.
      5. ActiveMQArtemis 인스턴스 이름의 이름을 클릭합니다.

      6. YAML 탭을 클릭합니다.

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

   3. 텍스트 파일에 기록한 브로커 및 init 컨테이너 이미지의 URL을 복사하여 CR의 spec.deploymentPlan.image 및 spec.deploymentPlan.initImage 필드에 삽입합니다. 예를 들면 다음과 같습니다.

      spec:
        ...
        deploymentPlan:
          image: registry.redhat.io/amq7/amq-broker-rhel8@55ae4e28b100534d63c34ab86f69230d274c999d46d1493f26fe3e75ba7a0cec
          initImage: registry.redhat.io/amq7/amq-broker-init-rhel8@442339c33549f2be9fe3b5c71184a753a3cf10b000b2ecc5bc9a062dd91c8def
        ...

3. CR을 저장합니다.

   CR을 저장하면 Operator는 새 이미지를 사용하도록 브로커를 업그레이드하고 spec.deploymentPlan.image 및 spec.deploymentPlan.initImage 속성 값을 다시 업데이트할 때까지 이러한 이미지를 사용합니다.

4. 향후 Operator 업그레이드가 배포에서 브로커를 다시 시작하지 못하도록 하려면 CR을 편집하고 spec.version 속성에 배포된 브로커의 버전 번호를 지정합니다.

   spec.version 속성이 CR에 구성되지 않은 경우 Operator의 후속 업그레이드로 브로커 Pod가 다시 시작됩니다. spec.version 속성에 버전 번호를 명시적으로 설정하지 않는 한 새 Operator에서 지원되는 최신 브로커 버전을 StatefulSet의 라벨에 추가하므로 Pod를 다시 시작해야 합니다.

   브로커를 시작한 후 CR의 status 섹션에서 spec.version 속성에 지정할 버전 번호 값을 찾을 수 있습니다. 자세한 내용은 브로커 배포에 대한 상태 정보 보기를 참조하십시오.

프로세스

1. 브로커 배포에 사용하는 CR 인스턴스를 엽니다. 예를 들어 기본 배포의 CR은 다음과 유사할 수 있습니다.

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 4
       image: registry.redhat.io/amq7/amq-broker-rhel8:7.12
     ...

2. deploymentPlan 섹션에서 enableMetricsPlugin 속성을 추가하고 아래 표시된 대로 값을 true 로 설정합니다.

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 4
       image: registry.redhat.io/amq7/amq-broker-rhel8:7.12
       ...
       enableMetricsPlugin: true

   enableMetricsPlugin

   배포의 브로커에 Prometheus 플러그인이 활성화되어 있는지 여부를 지정합니다.

3. CR 인스턴스를 저장합니다.

4. 이전에 브로커 배포를 생성한 프로젝트로 전환합니다.

   $ oc project <project_name>

5. 명령줄에서 변경 사항을 적용합니다.

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

   지표 플러그인은 Prometheus 형식으로 브로커 런타임 지표를 수집하기 시작합니다.

프로세스

1. 브로커 배포가 포함된 프로젝트에 대한 관리자 권한으로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
2. 웹 콘솔에서 홈 → 프로젝트를 클릭합니다. 브로커 배포가 포함된 프로젝트를 선택합니다.
3. 프로젝트에서 StatefulSets 또는 DeploymentConfigs를 보려면 Workloads → StatefulSets 를 클릭합니다.
4. 브로커 배포에 해당하는 StatefulSet 또는 DeploymentConfig를 클릭합니다.
5. 브로커 배포의 환경 변수에 액세스하려면 환경 탭을 클릭합니다.

6. 새 환경 변수 AMQ_ENABLE_METRICS_PLUGIN 을 추가합니다. 변수 값을 true 로 설정합니다.

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

프로세스

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

   1. 네트워킹 경로를 클릭합니다.

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

      http://rte-console-access-pod1.openshiftdomain

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

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