Fuse on OpenShift 가이드

Red Hat Fuse 7.11

OpenShift에서 Red Hat Fuse 설치 및 관리, OpenShift에 Fuse 애플리케이션 개발 및 배포

Red Hat Fuse Documentation Team

초록

OpenShift에서 Fuse 사용 가이드

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

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

OpenShift의 Red Hat Fuse를 사용하면 OpenShift Container Platform에 Fuse 애플리케이션을 배포할 수 있습니다.

1장. 사전 준비 사항

릴리스 노트

이 릴리스에 대한 중요한 정보는 릴리스 정보를 참조하십시오.

버전 호환성 및 지원

버전 호환성 및 지원에 대한 자세한 내용은 Red Hat JBoss Fuse 지원 구성 페이지를 참조하십시오.

Windows O/S 지원

OpenShift에서 Fuse용 개발자 툴링(oc 클라이언트 및 컨테이너 개발 키트)은 Windows O/S에서 완전하게 지원됩니다. Linux 명령줄 구문에 표시된 예제는 Windows O/S에서도 작동할 수 있습니다. 이 예제는 Windows 명령줄 구문을 따르도록 적절하게 수정되어 있습니다.

1.1. 비교: Fuse Standalone 및 Fuse on OpenShift

기능에는 몇 가지 차이점이 있습니다.

  • OpenShift에서 Fuse를 사용한 애플리케이션 배포는 애플리케이션 및 컨테이너 이미지 내에 패키지된 모든 필수 런타임 구성 요소로 구성됩니다. 애플리케이션은 Fuse Standalone과 함께 런타임에 배포되지 않으며 애플리케이션 이미지 자체는 OpenShift를 통해 배포 및 관리되는 완전한 런타임 환경입니다.
  • 각 애플리케이션 이미지가 완전한 런타임 환경이므로 OpenShift 환경의 패치는 Fuse Standalone과 다릅니다. 패치를 적용하기 위해 OpenShift 내에서 애플리케이션 이미지가 다시 빌드 및 재배포됩니다. 핵심 OpenShift 관리 기능을 사용하면 롤링 업그레이드 및 병렬 배포를 통해 업그레이드 중에 애플리케이션의 가용성을 유지할 수 있습니다.
  • Fuse에서 Fabric에서 제공하는 프로비저닝 및 클러스터링 기능은 Kubernetes 및 OpenShift에서 동등한 기능으로 대체되었습니다. OpenShift가 애플리케이션 배포 및 확장의 일부로 자동으로 이 작업을 수행하므로 개별 하위 컨테이너를 생성하거나 구성할 필요가 없습니다.
  • Fabric 엔드포인트는 OpenShift 환경에서 사용되지 않습니다. Kubernetes 서비스를 대신 사용해야 합니다.
  • 메시징 서비스는 OpenShift용 A-MQ를 사용하여 생성 및 관리되며 Karaf 컨테이너에 직접 포함되지 않습니다. OpenShift의 Fuse는 Kubernetes를 통해 OpenShift에서 메시징 서비스에 원활하게 연결할 수 있도록 향상된 버전의 camel-amq 구성 요소를 제공합니다.
  • 애플리케이션 컨테이너를 다시 시작하거나 확장하면 업데이트가 유지되지 않으므로 Karaf 인스턴스를 실행하는 데 대한 실시간 업데이트가 권장되지 않습니다. 이는 변경할 수 없는 아키텍처의 기본 요소이며 OpenShift 내에서 확장성과 유연성을 달성하는 데 필수적입니다.
  • Red Hat Fuse 구성 요소에 직접 연결된 Maven 종속성은 Red Hat에서 지원합니다. 사용자가 도입한 타사 Maven 종속성은 지원되지 않습니다.
  • SSH 에이전트는 Apache Karaf 마이크로 컨테이너에 포함되어 있지 않으므로 bin/client 콘솔 클라이언트를 사용하여 연결할 수 없습니다.
  • Fuse on OpenShift 애플리케이션 내의 프로토콜 호환성 및 Camel 구성 요소: 비HTTP 기반 통신에서는 TLS 및 SNI를 사용하여 OpenShift 외부에서 Fuse 서비스(Camel 소비자 엔드포인트)로 라우팅해야 합니다.

2장. 관리자의 시작하기

OpenShift 관리자인 경우 다음을 통해 OpenShift 배포 시 OpenShift 클러스터를 준비할 수 있습니다.

  1. registry.redhat.io 를 사용한 인증 구성 .
  2. OpenShift 이미지 및 템플릿에 Fuse 설치.

2.1. 레지스트리 컨테이너 이미지에 대해 registry.redhat.io로 인증

OpenShift에 Fuse 컨테이너 이미지를 배포하기 전에 registry.redhat.io 로 인증을 구성합니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 대한 클러스터 관리자 액세스
  • OpenShift oc 클라이언트 툴이 설치되어 있습니다. 자세한 내용은 OpenShift CLI 설명서를 참조하십시오.

절차

  1. 관리자로 OpenShift 클러스터에 로그인합니다.

    oc login --user system:admin --token=my-token --server=https://my-cluster.example.com:6443
  2. Fuse를 배포할 프로젝트를 엽니다.

    oc project myproject
  3. Red Hat Customer Portal 계정을 사용하여 docker-registry 시크릿을 생성하고 PULL_SECRET_NAMEpsi-internal-registry 로 교체하여 다음을 생성합니다.

    oc create secret docker-registry psi-internal-registry \
      --docker-server=docker-registry.redhat.io \
      --docker-username=CUSTOMER_PORTAL_USERNAME \
      --docker-password=CUSTOMER_PORTAL_PASSWORD \
      --docker-email=EMAIL_ADDRESS

    다음 출력이 표시되어야 합니다.

    secret/psi-internal-registry created
    중요

    registry.redhat.io 에 인증할 모든 OpenShift 프로젝트 네임스페이스에 이 docker-registry 시크릿을 생성해야 합니다.

  4. 이미지를 가져오는 데 시크릿을 사용하도록 서비스 계정에 시크릿을 연결합니다. 다음 예제에서는 기본 서비스 계정, 빌더 서비스 계정 및 배포자 서비스 계정을 사용합니다.

    oc secrets link default psi-internal-registry
    oc secrets link default psi-internal-registry --for=pull
    oc secrets link builder psi-internal-registry
    oc secrets link builder psi-internal-registry --for=pull
    oc secrets link deployer psi-internal-registry
    oc secrets link deployer psi-internal-registry --for=pull

    서비스 계정 이름은 OpenShift pod에서 사용하는 이름과 일치해야 합니다.

    참고

    Red Hat 사용자 이름 및 암호를 사용하여 풀 시크릿을 생성하지 않으려면 레지스트리 서비스 계정을 사용하여 인증 토큰을 생성할 수 있습니다.

추가 리소스

컨테이너 이미지용 Red Hat으로 인증하는 방법에 대한 자세한 내용은 다음을 참조하십시오.

2.2. OpenShift 4.x 서버에 Fuse 이미지 스트림 및 템플릿 설치

참고

Fuse 7.11에서는 IBM Power Systems, IBM Z 및 LinuxONE에 OpenShift 이미지 스트림 및 템플릿에 Fuse를 설치하는 것은 지원되지 않습니다.

OpenShift Operator에서 Fuse를 사용하여 설치할 수 있는 구성 요소만 IBM Power Systems, IBM Z 및 LinuxONE에서 지원됩니다.

OpenShift Container Platform 4.x는 OpenShift 네임스페이스에서 작동하는 Samples Operator를 사용하여 RHEL(Red Hat Enterprise Linux) 기반 OpenShift Container Platform 이미지 스트림 및 템플릿을 설치 및 업데이트합니다. OpenShift 이미지 스트림 및 템플릿에 Fuse를 설치하려면 다음을 수행합니다.

  • Samples Operator 재구성
  • Skipped Imagestreams 및 템플릿 필드에 Fuse 이미지 스트림 및 템플릿을 추가합니다.

    • 건너뛰기된 이미지 스트림: Samples Operator의 인벤토리에 있지만 클러스터 관리자가 Operator에서 무시하거나 관리하지 않도록 하려는 이미지 스트림입니다.
    • 건너뛰기된 템플릿: Samples Operator 인벤토리에 있지만 클러스터 관리자가 Operator에서 무시하거나 관리하지 않도록 하려는 템플릿입니다.

사전 요구 사항

  • OpenShift Server에 액세스할 수 있습니다.
  • registry.redhat.io 에 대한 인증이 구성되어 있습니다.

절차

  1. OpenShift 4 서버를 시작합니다.
  2. 관리자로 OpenShift 서버에 로그인합니다.

    oc login --user system:admin --token=my-token --server=https://my-cluster.example.com:6443
  3. docker-registry 시크릿을 생성한 프로젝트를 사용하고 있는지 확인합니다.

    oc project openshift
  4. Samples Operator의 현재 구성을 봅니다.

    oc get configs.samples.operator.openshift.io -n openshift-cluster-samples-operator -o yaml
  5. 추가된 fuse 템플릿 및 이미지 스트림을 무시하도록 Samples Operator를 구성합니다.

    oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator
  6. Fuse imagestreams Skipped Imagestreams 섹션을 추가하고 Fuse 및 Spring Boot 2 템플릿을 Skipped Templates 섹션에 추가합니다.

    [...]
    spec:
      architectures:
      - x86_64
      managementState: Managed
      skippedImagestreams:
      - fuse-console-rhel8
      - fuse-eap-openshift-jdk8-rhel7
      - fuse-eap-openshift-jdk11-rhel8
      - fuse-java-openshift-rhel8
      - fuse-java-openshift-jdk11-rhel8
      - fuse-karaf-openshift-rhel8
      - fuse-karaf-openshift-jdk11-rhel8
      - fuse-apicurito-generator-rhel8
      - fuse-apicurito-rhel8
      skippedTemplates:
      - s2i-fuse711-eap-camel-amq
      - s2i-fuse711-eap-camel-cdi
      - s2i-fuse711-eap-camel-cxf-jaxrs
      - s2i-fuse711-eap-camel-cxf-jaxws
      - s2i-fuse711-karaf-camel-amq
      - s2i-fuse711-karaf-camel-log
      - s2i-fuse711-karaf-camel-rest-sql
      - s2i-fuse711-karaf-cxf-rest
      - s2i-fuse711-spring-boot-2-camel-amq
      - s2i-fuse711-spring-boot-2-camel-config
      - s2i-fuse711-spring-boot-2-camel-drools
      - s2i-fuse711-spring-boot-2-camel-infinispan
      - s2i-fuse711-spring-boot-2-camel-rest-3scale
      - s2i-fuse711-spring-boot-2-camel-rest-sql
      - s2i-fuse711-spring-boot-2-camel
      - s2i-fuse711-spring-boot-2-camel-xa
      - s2i-fuse711-spring-boot-2-camel-xml
      - s2i-fuse711-spring-boot-2-cxf-jaxrs
      - s2i-fuse711-spring-boot-2-cxf-jaxws
      - s2i-fuse711-spring-boot-2-cxf-jaxrs-xml
      - s2i-fuse711-spring-boot-2-cxf-jaxws-xml
  7. OpenShift 이미지 스트림에 Fuse를 설치합니다.

    BASEURL=https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002
    
    oc create -n openshift -f ${BASEURL}/fis-image-streams.json
  8. OpenShift 빠른 시작 템플릿에 Fuse를 설치합니다.

    for template in eap-camel-amq-template.json \
     eap-camel-cdi-template.json \
     eap-camel-cxf-jaxrs-template.json \
     eap-camel-cxf-jaxws-template.json \
     karaf-camel-amq-template.json \
     karaf-camel-log-template.json \
     karaf-camel-rest-sql-template.json \
     karaf-cxf-rest-template.json ;
     do oc create -n openshift -f \
     ${BASEURL}/quickstarts/${template}
     done
  9. Spring Boot 2 빠른 시작 템플릿을 설치합니다.

    for template in spring-boot-2-camel-amq-template.json \
     spring-boot-2-camel-config-template.json \
     spring-boot-2-camel-drools-template.json \
     spring-boot-2-camel-infinispan-template.json \
     spring-boot-2-camel-rest-3scale-template.json \
     spring-boot-2-camel-rest-sql-template.json \
     spring-boot-2-camel-template.json \
     spring-boot-2-camel-xa-template.json \
     spring-boot-2-camel-xml-template.json \
     spring-boot-2-cxf-jaxrs-template.json \
     spring-boot-2-cxf-jaxws-template.json \
     spring-boot-2-cxf-jaxrs-xml-template.json \
     spring-boot-2-cxf-jaxws-xml-template.json ;
     do oc create -n openshift -f \
     ${BASEURL}/quickstarts/${template}
     done
  10. (선택 사항) OpenShift 템플릿에 설치된 Fuse를 확인합니다.

    oc get template -n openshift

2.3. OpenShift 4.x에 API kdump 설치

Red Hat Fuse on OpenShift는 REST API를 설계하는 데 사용할 수 있는 웹 기반 API design 툴인 API Authenticator를 제공합니다. APIanchor Operator는 OpenShift Container Platform 4.x에서 APIanchor의 설치 및 업그레이드를 간소화합니다.

OpenShift 관리자는 APIanchor Operator를 OpenShift 프로젝트(네임스페이스)에 설치합니다. Operator가 설치되면 선택한 네임스페이스에서 Operator가 실행됩니다. 그러나 OpenShift 관리자 또는 OpenShift 관리자로서 API 7.3을 서비스로 사용할 수 있도록 하려면 또는 개발자가 APIanchor 인스턴스를 생성해야 합니다. APIanchor 서비스는 APIanchor 웹 콘솔에 액세스할 수 있는 URL을 제공합니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 관리자 액세스 권한이 있어야 합니다.
  • registry.redhat.io 에 대한 인증이 구성되어 있습니다.

절차

  1. OpenShift 4.x 서버를 시작합니다.
  2. 웹 브라우저에서 브라우저에서 OpenShift 콘솔로 이동합니다. 자격 증명을 사용하여 콘솔에 로그인합니다.
  3. Operators 를 클릭한 다음 OperatorHub 를 클릭합니다.
  4. 검색 필드에 APIanchor를 입력합니다.
  5. Red Hat Integration - APIanchor 카드를 클릭합니다. Red Hat Integration - API Authenticator Operator 설치 페이지가 열립니다.
  6. 설치를 클릭합니다. Operator 설치 페이지가 열립니다.

    1. Update Channelfuse-console-7.11.x 를 선택합니다.
    2. 설치 모드 의 경우 클러스터의 네임스페이스 목록에서 네임스페이스(프로젝트)를 선택합니다.
    3. 승인 전략 의 경우 자동 또는 설명서 를 선택하여 OpenShift가 APIanchor Operator에 대한 업데이트를 처리하는 방법을 구성합니다.

      • 자동 업데이트를 선택하는 경우 새 버전의 API Authenticator Operator를 사용할 수 있는 경우 OpenShift Operator Lifecycle Manager(OLM)는 사람의 개입 없이 APIanchor의 실행 중인 인스턴스를 자동으로 업그레이드합니다.
      • 수동 업데이트를 선택하면 최신 버전의 Operator가 사용 가능할 때 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 APIanchor Operator가 새 버전으로 업데이트되도록 업데이트 요청을 수동으로 승인해야 합니다.
  7. 설치를 클릭하여 지정된 네임스페이스(프로젝트)에서 API Authenticator Operator를 사용할 수 있도록 합니다.
  8. API Webhook가 프로젝트에 설치되었는지 확인하려면 Operator 를 클릭한 다음 설치된 Operator 를 클릭하여 목록에서 Red Hat Integration - APIanchor 를 확인합니다.

다음 단계

APIanchor Operator가 설치되면 APIanchor의 인스턴스를 생성하여 OpenShift 프로젝트에 서비스로 API design를 추가해야 합니다. 이 작업은 다음 두 가지 방법으로 수행할 수 있습니다.

2.3.1. OpenShift 4.x 프로젝트에 서비스로 API 7.3 추가

APIanchor Operator가 OpenShift 4.x 프로젝트에 설치되면 (또는 OpenShift 개발자)를 OpenShift 프로젝트에 서비스로 추가할 수 있습니다. API 7.3 서비스는 개발자가 API DaemonSet 웹 콘솔에 액세스하는 데 사용하는 URL을 제공합니다.

참고

OpenShift 개발자가 서비스로서 OpenShift 4.x 프로젝트에 API 7.3을 추가하기 위해 수행하는 단계는 API 설계를 참조하십시오.

사전 요구 사항

  • OpenShift 클러스터에 대한 관리자 액세스 권한이 있어야 합니다.
  • APIanchor Operator가 현재 OpenShift 프로젝트에 설치되어 있습니다.

절차

  1. OpenShift 웹 콘솔에서 Operator를 클릭한 다음 설치된 Operator 를 클릭합니다.
  2. 이름 열에서 Red Hat Integration - APIanchor를 클릭합니다.
  3. 제공된 API 에서 인스턴스 생성을 클릭합니다.

    APIanchor 인스턴스에 대한 시작 템플릿이 최소인 기본 양식이 열립니다. 기본값을 수락하거나 선택적으로 편집합니다.

  4. 만들기 를 클릭하여 새 apicurito-service 를 생성합니다. OpenShift는 새 API의 pod, 서비스 및 기타 구성 요소를 시작합니다.
  5. APIanchor 서비스를 사용할 수 있는지 확인하려면 다음을 수행하십시오.

    1. Operators 를 클릭한 다음 설치된 Operator를 클릭합니다.
    2. Provided APIs 열에서 Apicurito CRD 를 클릭합니다.

      Operator 세부 정보 페이지에서 apicurito-service 가 나열됩니다.

  6. API Authenticator를 여는 방법은 다음과 같습니다.

    1. 네트워킹 > 경로 를 선택합니다.
    2. 올바른 프로젝트가 선택되어 있는지 확인합니다.
    3. apicurito-service-ui 행의 위치 열에서 URL을 클릭합니다.

      API DaemonSet 웹 콘솔이 새 브라우저 탭에서 열립니다.

2.3.2. OpenShift 4.x에서 API Webhook 업그레이드

Red Hat OpenShift 4.x는 Red Hat Fuse Operator를 포함한 운영자 업데이트를 처리합니다. 자세한 내용은 Operator OpenShift 설명서 를 참조하십시오.

결과적으로 Operator 업데이트가 애플리케이션 업그레이드를 트리거할 수 있습니다. 애플리케이션 업그레이드 방법은 애플리케이션 구성 방법에 따라 다릅니다.

APIanchor 애플리케이션의 경우 API 지브러 Operator를 업그레이드할 때 OpenShift는 클러스터의 모든 APIPrefix 애플리케이션도 자동으로 업그레이드합니다.

참고

일반 Operator 업그레이드 프로세스는 API Authenticator 7.8에서 APIanchor 7.9로 업그레이드할 때 작동하지 않습니다. APIanchor를 Fuse 7.8에서 Fuse 7.9로 업그레이드하려면 7.8 API Authenticator Operator를 삭제한 다음 7.9 API visualization Operator를 설치해야 합니다.

2.3.3. API Authenticator의 미터링 라벨

OpenShift Metering Operator를 사용하여 설치된 API Authenticator Operator, UI 구성 요소 및 코드 생성기를 분석하여 Red Hat 서브스크립션을 준수하는지 여부를 확인할 수 있습니다. 미터링에 대한 자세한 내용은 OpenShift 설명서 를 참조하십시오.

다음 표에는 APIanchor의 미터링 라벨이 나열되어 있습니다.

표 2.1. APIelasticsearch 미터링 레이블

레이블가능한 값

com.company

Red_Hat

rht.prod_name

Red_Hat_Integration

rht.prod_ver

7.11

rht.comp

Fuse

rht.comp_ver

7.11

rht.subcomp

fuse-apicurito

apicurito-service-ui

apicurito-service-generator

rht.subcomp_t

인프라

  • API Authenticator Operator의 예:

    apicurito-operator
    com.company: Red_Hat
    rht.prod_name: Red_Hat_Integration
    rht.prod_ver: 7.11
    rht.comp: Fuse
    rht.comp_ver: 7.11
    rht.subcomp: fuse-apicurito
    rht.subcomp_t: infrastructure
  • API kdump UI 구성 요소의 예:

    com.company: Red_Hat
    rht.prod_name: Red_Hat_Integration
    rht.prod_ver: 7.11
    rht.comp: Fuse
    rht.comp_ver: 7.11
    rht.subcomp: apicurito-service-ui
    rht.subcomp_t: infrastructure
  • API Authenticator 생성 구성 요소의 예:

    com.company: Red_Hat
    rht.prod_name: Red_Hat_Integration
    rht.prod_ver: 7.11
    rht.comp: Fuse
    rht.comp_ver: 7.11
    rht.subcomp: apicurito-service-generator
    rht.subcomp_t: infrastructure

2.3.4. 제한된 환경에서 API Webhook를 설치하기 위한 고려 사항

제한된 환경에 설치된 OpenShift 클러스터는 기본적으로 Red Hat 제공 OperatorHub 소스에 액세스할 수 없습니다. 해당 원격 소스에는 완전한 인터넷 연결이 필요하기 때문입니다. 이러한 환경에서 APITEXT Operator를 설치하려면 다음 사전 요구 사항을 완료해야 합니다.

  • OLM(Operator Lifecycle Manager)의 기본 원격 OperatorHub 소스를 비활성화합니다.
  • 완전한 인터넷 액세스가 가능한 워크스테이션을 사용하여 OperatorHub 콘텐츠의 로컬 미러를 생성합니다.
  • 기본 원격 소스 대신 로컬 소스에서 Operator를 설치하고 관리하도록 OLM을 구성합니다.

자세한 내용은 OpenShift 문서의 제한된 네트워크에서 Operator Lifecycle Manager 사용 섹션을 참조하십시오. OperatorHub의 로컬 미러를 생성한 후에는 다음 단계를 수행할 수 있습니다.

2.4. OpenShift 4.x에서 Fuse Console 설정

OpenShift 4.x에서 Fuse 콘솔을 설정하려면 이를 설치하고 배포해야 합니다. Fuse 콘솔 설치 및 배포를 위한 다음 옵션이 있습니다.

필요한 경우 2.4.3절. “OpenShift 4.x에서 Fuse Console에 대한 역할 기반 액세스 제어” 에 설명된 대로 Fuse 콘솔에 대한 역할 기반 액세스 제어(RBAC)를 사용자 지정할 수 있습니다.

2.4.1. OperatorHub를 사용하여 OpenShift 4.x에 Fuse 콘솔 설치 및 배포

OpenShift 4.x에 Fuse Console을 설치하려면 OpenShift OperatorHub에서 제공하는 Fuse Console Operator를 사용할 수 있습니다. Fuse 콘솔을 배포하려면 설치된 Operator의 인스턴스를 만듭니다.

사전 요구 사항

절차

Fuse 콘솔을 설치하고 배포하려면 다음을 수행합니다.

  1. 웹 브라우저에서 클러스터 관리자 액세스 권한이 있는 사용자로 OpenShift 콘솔에 로그인합니다.
  2. Operators 를 클릭한 다음 OperatorHub 를 클릭합니다.
  3. 검색 필드 창에서 Fuse Console 을 입력하여 Operator 목록을 필터링합니다.
  4. Fuse Console Operator 를 클릭합니다.
  5. Fuse Console Operator 설치 창에서 설치를 클릭합니다.

    Create Operator Subscription 폼이 열립니다.

    • Update Channel7.11.x 를 선택합니다.
    • 설치 모드 의 경우 기본값(클러스터의 특정 네임스페이스)을 수락합니다.

      Operator를 설치한 후 Fuse 콘솔을 배포할 때 클러스터의 모든 네임스페이스에서 애플리케이션을 모니터링하거나 Fuse Console Operator가 설치된 네임스페이스에서만 애플리케이션을 모니터링하도록 선택할 수 있습니다.

    • 설치된 네임스페이스 의 경우 Fuse Console Operator를 설치할 네임스페이스를 선택합니다.
    • 업데이트 승인 의 경우 자동 또는 설명서 를 선택하여 OpenShift가 Fuse Console Operator에 대한 업데이트를 처리하는 방법을 구성할 수 있습니다.

      • 자동 업데이트를 선택하면 Fuse Console Operator의 새 버전이 사용 가능할 때 OpenShift Operator Lifecycle Manager (OLM)는 개입없이 Fuse Console의 실행 중인 인스턴스를 자동으로 업그레이드합니다.
      • 수동 업데이트를 선택하면 최신 버전의 Operator가 사용 가능할 때 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Fuse Console Operator가 새 버전으로 업데이트되도록 해당 업데이트 요청을 수동으로 승인해야 합니다.
  6. 설치를 클릭합니다.

    OpenShift는 현재 네임스페이스에 Fuse Console Operator를 설치합니다.

  7. 설치를 확인하려면 Operator를 클릭한 다음 설치된 Operator 를 클릭합니다. Operator 목록에서 Fuse 콘솔을 확인할 수 있습니다.
  8. OpenShift 웹 콘솔을 사용하여 Fuse 콘솔을 배포하려면 다음을 수행합니다.

    1. 설치된 Operator 목록에서 Name 열에서 Fuse Console 을 클릭합니다.
    2. 제공된 API 아래의 Operator Details 페이지에서 Create Instance 를 클릭합니다.

      구성 기본값을 수락하거나 선택적으로 편집합니다.

      Replicas 의 경우 Fuse 콘솔 성능(예: 고가용성 환경에서)을 늘리려면 Fuse 콘솔에 할당된 Pod 수를 늘릴 수 있습니다.

      Rbac (역할 기반 액세스 제어)의 경우 기본 RBAC 동작을 사용자 지정하려면 구성 맵 필드에 값만 지정하고 ConfigMap 파일이 Fuse Console Operator를 설치한 네임스페이스에 이미 존재하는 경우에만 지정합니다. RBAC에 대한 자세한 내용은 OpenShift 4.x의 Fuse Console에 대한 역할 기반 액세스 제어를 참조하십시오.

      Nginx 의 경우 Fuse Console Operator 설치에 대한 성능 튜닝 을 참조하십시오.

    3. 생성을 클릭합니다.

      Fuse Console Operator 세부 정보 페이지가 열리고 배포 상태를 표시합니다.

  9. Fuse 콘솔을 시작하려면 다음을 수행합니다.

    1. 네임스페이스 배포: OpenShift 웹 콘솔에서 Fuse Console Operator를 설치한 프로젝트를 연 다음 개요 를 선택합니다. 프로젝트 개요 페이지에서 시작 관리자 섹션까지 아래로 스크롤하여 Fuse Console 링크를 클릭합니다.

      클러스터 배포의 경우 OpenShift 웹 콘솔 제목 표시줄에서 그리드 아이콘( mf os grid icon )을 클릭합니다. 팝업 메뉴의 Red Hat 애플리케이션에서 Fuse Console URL 링크를 클릭합니다.

    2. Fuse 콘솔에 로그인합니다.

      필요한 권한이 나열된 브라우저에서 권한 부여 페이지가 열립니다.

    3. Allow selected permissions 를 클릭합니다.

      Fuse Console은 브라우저에서 열리고 액세스할 수 있는 권한이 있는 Fuse 애플리케이션 pod를 표시합니다.

  10. 보려는 애플리케이션에 대해 연결을 클릭합니다.

    Fuse Console에 애플리케이션을 표시하는 새 브라우저 창이 열립니다.

2.4.2. 명령줄을 사용하여 OpenShift 4.x에 Fuse 콘솔 설치 및 배포

OpenShift 4.x에서는 다음 배포 옵션 중 하나를 선택하여 명령줄에서 Fuse 콘솔을 설치하고 배포할 수 있습니다.

  • 클러스터 - Fuse 콘솔은 OpenShift 클러스터의 여러 네임스페이스(프로젝트)에 배포된 Fuse 애플리케이션을 검색하고 연결할 수 있습니다. 이 템플릿을 배포하려면 OpenShift 클러스터에 대한 관리자 역할이 있어야 합니다.
  • 역할 기반 액세스 제어가 있는 클러스터 - 구성 가능한 역할 기반 액세스 제어(RBAC)가 있는 클러스터 템플릿입니다. 자세한 내용은 OpenShift 4.x의 Fuse Console에 대한 역할 기반 액세스 제어를 참조하십시오.
  • 네임스페이스 - Fuse Console은 특정 OpenShift 프로젝트(네임스페이스)에 액세스할 수 있습니다. 이 템플릿을 배포하려면 OpenShift 프로젝트에 대한 관리자 역할이 있어야 합니다.
  • 역할 기반 액세스 제어가 있는 네임스페이스 - 구성 가능한 RBAC가 있는 네임스페이스 템플릿입니다. 자세한 내용은 OpenShift 4.x의 Fuse Console에 대한 역할 기반 액세스 제어를 참조하십시오.

Fuse Console 템플릿의 매개변수 목록을 보려면 다음 OpenShift 명령을 실행합니다.

oc process --parameters -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fuse-console-namespace-os4.json

절차

  1. 다음 명령을 사용하여 모든 템플릿 목록을 검색하여 Fuse Console 이미지 스트림이 설치되었는지 확인합니다.

    oc get template -n openshift
  2. 필요한 경우 이미 설치된 이미지 스트림을 새 릴리스 태그로 업데이트하려면 다음 명령을 사용하여 Fuse Console 이미지를 openshift 네임스페이스로 가져옵니다.

    oc import-image fuse7/fuse-console-rhel8:1.10 --from=registry.redhat.io/fuse7/fuse-console-rhel8:1.10 --confirm -n openshift
  3. 다음 명령을 실행하여 Fuse Console APP_NAME 값을 가져옵니다.

    oc process --parameters -f TEMPLATE-FILENAME

    여기서 TEMPLATE-FILENAME 은 다음 템플릿 중 하나입니다.

    • 클러스터 템플릿:

      `https://github.com/jboss-fuse/application-templates/blob/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002//fuse-console-cluster-os4.json`
    • 구성 가능한 RBAC가 있는 클러스터 템플릿:

      `https://github.com/jboss-fuse/application-templates/blob/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002//fuse-console-cluster-rbac.yml`
    • 네임스페이스 템플릿:

      `https://github.com/jboss-fuse/application-templates/blob/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002//fuse-console-namespace-os4.json`
    • 구성 가능한 RBAC가 있는 네임스페이스 템플릿:

      `https://github.com/jboss-fuse/application-templates/blob/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002//fuse-console-namespace-rbac.yml`

      예를 들어 구성 가능한 RBAC가 있는 클러스터 템플릿의 경우 다음 명령을 실행합니다.

      oc process --parameters -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fuse-console-cluster-rbac.yml
  4. OpenShift 4.x에서 Fuse Console 보안에서 생성한 인증서에서 다음 명령을 사용하여 시크릿을 생성하고 Fuse Console에 마운트합니다(여기서 APP_NAME 은 Fuse Console 애플리케이션의 이름입니다).

    oc create secret tls APP_NAME-tls-proxying --cert server.crt --key server.key
  5. 다음 명령을 실행하여 Fuse Console 템플릿의 로컬 사본을 기반으로 새 애플리케이션을 생성합니다(여기서 myproject 는 OpenShift 프로젝트의 이름이고 mytemp 는 Fuse 콘솔 템플릿이 포함된 로컬 디렉터리의 경로이며 myhost 는 Fuse 콘솔에 액세스할 수 있는 호스트 이름입니다.

    • 클러스터 템플릿의 경우:

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fuse-console-cluster-os4.json  -p ROUTE_HOSTNAME=myhost
    • RBAC 템플릿이 있는 클러스터의 경우:

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fuse-console-cluster-rbac.yml -p ROUTE_HOSTNAME=myhost
    • 네임스페이스 템플릿의 경우 다음을 수행합니다.

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fuse-console-namespace-os4.json
    • RBAC 템플릿이 있는 네임스페이스의 경우 다음을 수행합니다.

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fuse-console-namespace-rbac.yml
  6. OpenShift 웹 콘솔을 열 수 있도록 Fuse 콘솔을 구성하려면 다음 명령을 실행하여 OPENSHIFT_knative_CONSOLE_URL 환경 변수를 설정합니다.

    oc set env dc/${APP_NAME} OPENSHIFT_WEB_CONSOLE_URL=`oc get -n openshift-config-managed cm console-public -o jsonpath={.data.consoleURL}`
  7. 다음 명령을 실행하여 Fuse Console 배포의 상태 및 URL을 가져옵니다.

    oc status
  8. 브라우저에서 Fuse 콘솔에 액세스하려면 7단계에서 반환된 URL(예: https://fuse-console.192.168.64.12.nip.io)을 사용합니다.

2.4.2.1. OpenShift 4.x에서 Fuse 콘솔을 보호하는 인증서 생성

OpenShift 4.x에서 Fuse 콘솔 프록시와 Jolokia 에이전트 간 연결을 유지하려면 Fuse 콘솔을 배포하기 전에 클라이언트 인증서를 생성해야 합니다. 서비스 서명 인증 기관 개인 키를 사용하여 클라이언트 인증서에 서명해야 합니다.

명령줄을 사용하여 Fuse 콘솔을 설치하고 배포하는 경우에만 이 절차를 따라야 합니다. Fuse Console Operator를 사용하는 경우 이 작업을 처리합니다.

중요

각 OpenShift 클러스터에 대해 별도의 클라이언트 인증서를 생성하고 서명해야 합니다. 두 개 이상의 클러스터에 동일한 인증서를 사용하지 마십시오.

사전 요구 사항

  • OpenShift 클러스터에 대한 클러스터 관리자 액세스 권한이 있어야 합니다.
  • 두 개 이상의 OpenShift 클러스터에 대한 인증서를 생성하고 이전에 현재 디렉터리의 다른 클러스터에 대한 인증서를 생성한 경우 다음 중 하나를 수행하여 현재 클러스터에 대해 다른 인증서를 생성하십시오.

    • 현재 디렉터리에서 기존 인증서 파일(예: ca.crt,ca.key, ca.srl)을 삭제합니다.
    • 다른 작업 디렉터리로 변경합니다. 예를 들어 현재 작업 디렉터리의 이름이 cluster1 인 경우 새 cluster2 디렉터리를 생성하고 작업 디렉터리를 이 디렉터리로 변경합니다.

      mkdir ../cluster2

      cd ../cluster2

절차

  1. 클러스터 관리자 액세스 권한이 있는 사용자로 OpenShift에 로그인합니다.

    oc login -u <user_with_cluster_admin_role>
  2. 다음 명령을 실행하여 서비스 서명 인증 기관 키를 검색합니다.

    • 인증서를 검색하려면 다음을 수행합니다.

      oc get secrets/signing-key -n openshift-service-ca -o "jsonpath={.data['tls\.crt']}" | base64 --decode > ca.crt
    • 개인 키를 검색하려면 다음을 수행합니다.

      oc get secrets/signing-key -n openshift-service-ca -o "jsonpath={.data['tls\.key']}" | base64 --decode > ca.key
  3. Kubernetes 인증서 관리에 설명된 대로 easyrsa,openssl 또는 cfssl 을 사용하여 클라이언트 인증서를 생성합니다.

    openssl을 사용하는 명령의 예는 다음과 같습니다.

    1. 개인 키를 생성합니다.

      openssl genrsa -out server.key 2048
    2. CSR 구성 파일을 작성합니다.

      cat <<EOT >> csr.conf
        [ req ]
        default_bits = 2048
        prompt = no
        default_md = sha256
        distinguished_name = dn
      
        [ dn ]
        CN = fuse-console.fuse.svc
      
        [ v3_ext ]
        authorityKeyIdentifier=keyid,issuer:always
        keyUsage=keyEncipherment,dataEncipherment,digitalSignature
        extendedKeyUsage=serverAuth,clientAuth
      EOT

      여기에서 CN 매개 변수의 값은 애플리케이션 이름과 애플리케이션에서 사용하는 네임스페이스를 나타냅니다.

    3. CSR을 생성합니다.

      openssl req -new -key server.key -out server.csr -config csr.conf
    4. 서명된 인증서를 발행합니다.

      openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000 -extensions v3_ext -extfile csr.conf

2.4.3. OpenShift 4.x에서 Fuse Console에 대한 역할 기반 액세스 제어

Fuse 콘솔은 OpenShift에서 제공하는 사용자 권한에 따라 액세스를 유추하는 RBAC(역할 기반 액세스 제어)를 제공합니다. Fuse 콘솔에서 RBAC는 Pod에서 사용자가 작업을 수행할 수 있는 기능을 결정합니다.

OpenShift 권한 부여에 대한 자세한 내용은 Using RBAC to define and apply permissions section of the OpenShift documentation에서 참조하십시오.

Operator를 사용하여 OpenShift에 Fuse Console을 설치할 때 역할 기반 액세스는 기본적으로 활성화됩니다.

템플릿으로 설치하여 Fuse Console에 대한 역할 기반 액세스를 구현하려면 명령줄을 사용하여 Fuse Console 설치 및 배포에 설명된 대로 RBAC(fuse-console-cluster-rbac.yml 또는 fuse-console-namespace-rbac.yml)로 구성할 수 있는 템플릿 중 하나를 사용해야 합니다.

Fuse 콘솔 RBAC는 OpenShift의 포드 리소스에 대한 사용자의 동사 액세스를 활용하여 Fuse 콘솔에서 Pod의 pod 작업에 대한 사용자의 액세스 권한을 결정합니다. 기본적으로 Fuse 콘솔에는 다음 두 가지 사용자 역할이 있습니다.

  • admin

    사용자가 OpenShift에서 포드를 업데이트할 수 있는 경우 사용자는 Fuse Console에 대한 admin 역할을 구성합니다. 사용자는 Pod에 대한 Fuse 콘솔에서 쓰기 tasks 작업을 수행할 수 있습니다.

  • 뷰어

    사용자가 OpenShift에서 포드를 가져올 수 있는 경우 사용자는 Fuse Console에 대한 뷰어 역할을 유추합니다. 사용자는 Pod에 대한 Fuse 콘솔에서 읽기 전용 ScanSetting 작업을 수행할 수 있습니다.

참고

RBAC가 아닌 템플릿을 사용하여 Fuse Console을 설치하는 경우 pod 리소스에 update 동사가 부여된 OpenShift 사용자만 Fuse Console>-<s 작업을 수행할 수 있는 권한이 부여됩니다. Pod 리소스에 get 동사가 부여된 사용자는 Pod를 수 있지만 Fuse Console 작업은 수행할 수 없습니다.

2.4.3.1. OpenShift 4.x에서 Fuse Console의 액세스 역할 확인

Fuse Console 역할 기반 액세스 제어는 pod에 대한 사용자의 OpenShift 권한에서 유추됩니다. 특정 사용자에게 부여된 Fuse Console 액세스 역할을 확인하려면 포드에 대해 사용자에게 부여된 OpenShift 권한을 받으십시오.

사전 요구 사항

  • 사용자 이름을 알고 있습니다.
  • Pod의 이름을 알고 있습니다.

절차

  • 사용자에게 포드에 대한 Fuse Console admin 역할이 있는지 확인하려면 다음 명령을 실행하여 사용자가 OpenShift에서 포드를 업데이트할 수 있는지 확인합니다.

    oc auth can-i update pods/<pod> --as <user>

    응답이 yes 인 경우 사용자에게 포드에 대한 Fuse Console admin 역할이 있습니다. 사용자는 Pod에 대한 Fuse 콘솔에서 쓰기 tasks 작업을 수행할 수 있습니다.

  • 사용자에게 포드에 대한 Fuse Console viewer 역할이 있는지 확인하려면 다음 명령을 실행하여 사용자가 OpenShift에서 Pod를 가져올 수 있는지 확인합니다.

    oc auth can-i get pods/<pod> --as <user>

    응답이 yes 인 경우 사용자에게 포드에 대한 Fuse Console viewer 역할이 있습니다. 사용자는 Pod에 대한 Fuse 콘솔에서 읽기 전용 ScanSetting 작업을 수행할 수 있습니다. 컨텍스트에 따라 Fuse Console은 옵션을 비활성화하거나 사용자가 쓰기 를 시도할 때 "이 사용자에 대해 허용되지 않음" 메시지를 표시하여 뷰어 역할의 사용자가 쓰기 10.0.0.1 작업을 수행하지 못하도록 합니다.

    응답이 없는 경우 사용자가 Fuse Console 역할에 바인딩되지 않으며 사용자는 Fuse Console에서 포드를 볼 수 없습니다.

2.4.3.2. OpenShift 4.x에서 Fuse 콘솔에 대한 역할 기반 액세스 사용자 정의

OperatorHub를 사용하여 Fuse 콘솔을 설치하는 경우 OpenShift 4.x의 Fuse Console에 대한 역할 기반 액세스 제어에 설명된 대로 기본적으로 역할 기반 액세스 제어 (RBAC)가 활성화됩니다. Fuse Console을 배포하기 전에 Fuse Console RBAC 동작을 사용자 지정하려면 ConfigMap 파일을 제공해야 합니다(사용자 지정 RBAC 동작을 정의함). Fuse Console Operator를 설치한 동일한 네임스페이스에 사용자 정의 ConfigMap 파일을 배치해야 합니다.

명령줄 템플릿을 사용하여 Fuse 콘솔을 설치하는 경우 deployment-cluster-rbac.ymldeployment-namespace-rbac.yml 템플릿은 구성 파일(ACL.yml)이 포함된 ConfigMap을 생성합니다. 구성 파일은 CloudEvent 작업에 허용되는 역할을 정의합니다.

사전 요구 사항

  • OperatorHub를 사용하거나 Fuse 콘솔 RBAC 템플릿(deployment-cluster-rbac.yml 또는 deployment-namespace-rbac.yml) 중 하나를 사용하여 Fuse 콘솔을 설치했습니다.

절차

Fuse 콘솔 RBAC 역할을 사용자 지정하려면 다음을 수행합니다.

  1. 명령줄을 사용하여 Fuse 콘솔을 설치한 경우 설치 템플릿에 기본 ConfigMap 파일이 포함되어 있으므로 다음 단계로 건너뛸 수 있습니다.

    OperatorHub를 사용하여 Fuse 콘솔을 설치한 경우 Fuse 콘솔을 배포하기 전에 RBAC ConfigMap을 생성합니다.

    1. 현재 OpenShift 프로젝트가 Fuse Console을 설치할 프로젝트인지 확인합니다. 예를 들어 fusetest 프로젝트에 Fuse 콘솔을 설치하려면 다음 명령을 실행합니다.

      oc project fusetest
    2. 템플릿에서 Fuse 콘솔 RBAC ConfigMap 파일을 생성하려면 다음 명령을 실행합니다.

      oc process -f https://raw.githubusercontent.com/jboss-fuse/application-templates/2.1.x.sb2.redhat-7-8-x/fuse-console-operator-rbac.yml -p APP_NAME=fuse-console | oc create -f -
  2. 다음 명령을 실행하여 편집기에서 ConfigMap을 엽니다.

    oc edit cm $APP_NAME-rbac

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

    oc edit cm fuse-console-rbac
  3. 파일을 편집합니다.
  4. 파일을 저장하여 변경 사항을 적용합니다. OpenShift는 Fuse 콘솔 포드를 자동으로 다시 시작합니다.

2.4.3.3. OpenShift 4.x에서 Fuse Console에 대한 역할 기반 액세스 제어 비활성화

명령줄을 사용하여 Fuse Console을 설치하고 Fuse Console RBAC 템플릿 중 하나를 지정한 경우 Fuse 콘솔의 HAWTIO_ONLINE_RBAC_ACL 환경 변수가 OpenShift 서버에 역할 기반 액세스 제어(RBAC) ConfigMap 구성 경로를 전달합니다. HAWTIO_ONLINE_RBAC_ACL 환경 변수를 지정하지 않으면 RBAC 지원이 비활성화되어 있으며 pod 리소스(OpenShift)에서 업데이트 동사가 부여된 사용자만 Fuse 콘솔의 Pod에서 ScanSettings 작업을 호출할 수 있습니다.

OperatorHub를 사용하여 Fuse 콘솔을 설치하는 경우 기본적으로 역할 기반 액세스가 활성화되며 HAWTIO_ONLINE_RBAC_ACL 환경 변수는 적용되지 않습니다.

사전 요구 사항

명령줄을 사용하여 Fuse 콘솔을 설치하고 Fuse 콘솔 RBAC 템플릿(deployment-cluster-rbac.yml 또는 deployment-namespace-rbac.yml) 중 하나를 지정한 것입니다.

절차

Fuse 콘솔의 역할 기반 액세스를 비활성화하려면 다음을 수행합니다.

  1. OpenShift에서 Fuse 콘솔의 Deployment Config 리소스를 편집합니다.
  2. 전체 HAWTIO_ONLINE_RBAC_ACL 환경 변수 정의를 삭제합니다.

    (해당 값을 지우는 것만으로는 충분하지 않습니다.)

  3. 파일을 저장하여 변경 사항을 적용합니다. OpenShift는 Fuse 콘솔 포드를 자동으로 다시 시작합니다.

2.4.4. OpenShift 4.x에서 Fuse 콘솔 업그레이드

Red Hat OpenShift 4.x는 Red Hat Fuse Operator를 포함한 운영자 업데이트를 처리합니다. 자세한 내용은 Operator OpenShift 설명서 를 참조하십시오.

결과적으로 Operator 업데이트는 애플리케이션 구성 방법에 따라 애플리케이션 업그레이드를 트리거할 수 있습니다.

Fuse Console 애플리케이션의 경우 애플리케이션 사용자 정의 리소스 정의의 .spec.version 필드를 편집하여 애플리케이션으로 업그레이드를 트리거할 수도 있습니다.

사전 요구 사항

  • OpenShift 클러스터 관리자 권한이 있어야 합니다.

절차

Fuse Console 애플리케이션을 업그레이드하려면 다음을 수행합니다.

  1. 터미널 창에서 다음 명령을 사용하여 애플리케이션 사용자 정의 리소스 정의의 .spec.version 필드를 변경합니다.

    oc patch -n <project-name> <custom-resource-name> --type='merge' -p '{"spec":{"version":"1.7.1"}}'

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

    oc patch -n myproject hawtio/example-fuseconsole --type='merge' -p '{"spec":{"version":"1.7.1"}}'
  2. 애플리케이션 상태가 업데이트되었는지 확인합니다.

     oc get -n myproject hawtio/example-fuseconsole

    응답은 버전 번호를 포함하여 애플리케이션에 대한 정보를 표시합니다.

    NAME                  AGE   URL                                        IMAGE
    example-fuseconsole   1m    https://fuseconsole.192.168.64.38.nip.io   docker.io/fuseconsole/online:1.7.1

    .spec.version 필드의 값을 변경하면 OpenShift에서 애플리케이션을 자동으로 재배포합니다.

  3. 버전 변경에 의해 트리거되는 재배포 상태를 확인하려면 다음을 수행합니다.

    oc rollout status deployment.v1.apps/example-fuseconsole

    배포에 성공하면 이 응답을 보여줍니다.

    deployment "example-fuseconsole" successfully rolled out

2.4.5. OpenShift 4.x 서버에서 Fuse 이미지 스트림 및 템플릿 업그레이드

OpenShift Container Platform 4.x는 OpenShift 네임스페이스에서 작동하는 Samples Operator를 사용하여 RHEL(Red Hat Enterprise Linux) 기반 OpenShift Container Platform 이미지 스트림 및 템플릿을 업그레이드 및 업데이트합니다.

OpenShift 이미지 스트림 및 템플릿에서 Fuse를 업그레이드하려면 다음을 수행합니다.

  • Samples Operator 재구성
  • Skipped Imagestreams 및 템플릿 필드에 Fuse 이미지 스트림 및 템플릿을 추가합니다.

    • 건너뛰기된 이미지 스트림: Samples Operator의 인벤토리에 있지만 클러스터 관리자가 Operator에서 무시하거나 관리하지 않도록 하려는 이미지 스트림입니다.
    • 건너뛰기된 템플릿: Samples Operator 인벤토리에 있지만 클러스터 관리자가 Operator에서 무시하거나 관리하지 않도록 하려는 템플릿입니다.

사전 요구 사항

  • OpenShift Server에 액세스할 수 있습니다.
  • registry.redhat.io 에 대한 인증이 구성되어 있습니다.

절차

  1. OpenShift 4 서버를 시작합니다.
  2. 관리자로 OpenShift 서버에 로그인합니다.

    oc login --user system:admin --token=my-token --server=https://my-cluster.example.com:6443
  3. docker-registry 시크릿을 생성한 프로젝트를 사용하고 있는지 확인합니다.

    oc project openshift
  4. Samples Operator의 현재 구성을 봅니다.

    oc get configs.samples.operator.openshift.io -n openshift-cluster-samples-operator -o yaml
  5. 추가된 fuse 템플릿 및 이미지 스트림을 무시하도록 Samples Operator를 구성합니다.

    oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator
  6. Fuse imagestreams Skipped Imagestreams 섹션을 추가하고 Fuse 및 Spring Boot 2 템플릿을 Skipped Templates 섹션에 추가합니다.

    [...]
    spec:
      architectures:
      - x86_64
      managementState: Managed
      skippedImagestreams:
      - fuse-console-rhel8
      - fuse-eap-openshift-jdk8-rhel7
      - fuse-eap-openshift-jdk11-rhel8
      - fuse-java-openshift-rhel8
      - fuse-java-openshift-jdk11-rhel8
      - fuse-karaf-openshift-rhel8
      - fuse-karaf-openshift-jdk11-rhel8
      - fuse-apicurito-generator-rhel8
      - fuse-apicurito-rhel8
      skippedTemplates:
      - s2i-fuse711-eap-camel-amq
      - s2i-fuse711-eap-camel-cdi
      - s2i-fuse711-eap-camel-cxf-jaxrs
      - s2i-fuse711-eap-camel-cxf-jaxws
      - s2i-fuse711-karaf-camel-amq
      - s2i-fuse711-karaf-camel-log
      - s2i-fuse711-karaf-camel-rest-sql
      - s2i-fuse711-karaf-cxf-rest
      - s2i-fuse711-spring-boot-2-camel-amq
      - s2i-fuse711-spring-boot-2-camel-config
      - s2i-fuse711-spring-boot-2-camel-drools
      - s2i-fuse711-spring-boot-2-camel-infinispan
      - s2i-fuse711-spring-boot-2-camel-rest-3scale
      - s2i-fuse711-spring-boot-2-camel-rest-sql
      - s2i-fuse711-spring-boot-2-camel
      - s2i-fuse711-spring-boot-2-camel-xa
      - s2i-fuse711-spring-boot-2-camel-xml
      - s2i-fuse711-spring-boot-2-cxf-jaxrs
      - s2i-fuse711-spring-boot-2-cxf-jaxws
      - s2i-fuse711-spring-boot-2-cxf-jaxrs-xml
      - s2i-fuse711-spring-boot-2-cxf-jaxws-xml
  7. OpenShift 이미지 스트림에서 Fuse 업그레이드.

    BASEURL=https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002
    
    oc replace -n openshift -f ${BASEURL}/fis-image-streams.json
  8. OpenShift 빠른 시작 템플릿으로 Fuse 업그레이드:

    for template in eap-camel-amq-template.json \
     eap-camel-cdi-template.json \
     eap-camel-cxf-jaxrs-template.json \
     eap-camel-cxf-jaxws-template.json \
     karaf-camel-amq-template.json \
     karaf-camel-log-template.json \
     karaf-camel-rest-sql-template.json \
     karaf-cxf-rest-template.json ;
     do
     oc replace -n openshift \
     ${BASEURL}/quickstarts/${template}
     done
  9. Spring Boot 2 빠른 시작 템플릿 업그레이드:

    for template in spring-boot-2-camel-amq-template.json \
     spring-boot-2-camel-config-template.json \
     spring-boot-2-camel-drools-template.json \
     spring-boot-2-camel-infinispan-template.json \
     spring-boot-2-camel-rest-3scale-template.json \
     spring-boot-2-camel-rest-sql-template.json \
     spring-boot-2-camel-template.json \
     spring-boot-2-camel-xa-template.json \
     spring-boot-2-camel-xml-template.json \
     spring-boot-2-cxf-jaxrs-template.json \
     spring-boot-2-cxf-jaxws-template.json \
     spring-boot-2-cxf-jaxrs-xml-template.json \
     spring-boot-2-cxf-jaxws-xml-template.json ;
     do oc replace -n openshift \
     ${BASEURL}/quickstarts/${template}
     done
  10. (선택 사항) OpenShift 템플릿에서 업그레이드된 Fuse를 확인합니다.

    oc get template -n openshift

2.4.6. OpenShift 4.x에서 Fuse 콘솔의 성능 튜닝

기본적으로 Fuse 콘솔은 다음 Nginx 설정을 사용합니다.

  • clientBodyBufferSize: 256k
  • proxyBuffers: 16 128k
  • subrequestOutputBufferSize: 10m

참고: 이러한 설정에 대한 자세한 내용은 Nginx 설명서를 참조하십시오. http://nginx.org/en/docs/dirindex.html

Fuse Console의 성능을 튜닝하려면 clientBodyBufferSize,proxyBuffers, subrequestOutputBufferSize 환경 변수를 모두 설정할 수 있습니다. 예를 들어 Fuse 콘솔을 사용하여 수많은 Pod 및 경로(예: 총 100개 경로)를 모니터링하는 경우 Fuse Console의 subrequestOutputBufferSize 환경 변수를 60m 에서 100m 사이로 설정하여 로드 시간 초과 문제를 해결할 수 있습니다.

이러한 환경 변수를 설정하는 방법은 Openshift 4.x에 Fuse Console을 설치한 방법에 따라 다릅니다.

  • Fuse Console Operator 사용
  • Fuse Console 템플릿 사용

2.4.6.1. Fuse Console Operator 설치에 대한 성능 튜닝

Openshift 4.x에서는 Fuse Console을 배포하기 전이나 후에 Nginx 성능 튜닝 환경 변수를 설정할 수 있습니다. 나중에 이 작업을 수행하면 OpenShift에서 Fuse 콘솔을 재배포합니다.

사전 요구 사항

절차

Fuse Console을 배포하기 전이나 후에 환경 변수를 설정할 수 있습니다.

  • Fuse 콘솔을 배포하기 전에 환경 변수를 설정하려면 다음을 수행합니다.

    1. OpenShift 웹 콘솔에서 Fuse Console Operator가 설치된프로젝트에서 Operator > 설치된 Operator > Red Hat Integration - Fuse Console 을 선택합니다.
    2. Hawtio 탭을 클릭한 다음 Hawtio 만들기 를 클릭합니다.
    3. Hawtio 생성 페이지의 양식 보기에서 구성 > Nginx 섹션까지 아래로 스크롤합니다.
    4. Nginx 섹션을 확장한 다음 환경 변수를 설정합니다. 예를 들면 다음과 같습니다.

      • clientBodyBufferSize: 256k
      • proxyBuffers: 16 128k
      • subrequestOutputBufferSize: 100m
    5. 설정을 저장합니다.
    6. 생성을 클릭하여 Fuse 콘솔을 배포합니다.
    7. 배포가 완료되면 Deployments> fuse-console 페이지를 열고 Environment 를 클릭하여 환경 변수가 목록에 있는지 확인합니다.
  • Fuse 콘솔을 배포한 후 환경 변수를 설정하려면 다음을 수행합니다.

    1. OpenShift 웹 콘솔에서 Fuse Console이 배포된 프로젝트를 엽니다.
    2. Operator> 설치된 Operator> Red Hat Integration - Fuse Console 을 선택합니다.
    3. Hawtio 탭을 클릭한 다음 fuse-console 을 클릭합니다.
    4. 작업> Hawtio 편집 을 선택합니다.
    5. 편집기 창에서 spec 섹션까지 아래로 스크롤합니다.
    6. spec 섹션에서 새 nginx 섹션을 추가하고 하나 이상의 환경 변수를 지정합니다. 예를 들면 다음과 같습니다.

      apiVersion: hawt.io/v1alpha1
      kind: Hawtio
      metadata:
        name: fuse-console
      spec:
        type: Namespace
        nginx:
          clientBodyBufferSize: 256k
          proxyBuffers: 16 128k
          subrequestOutputBufferSize: 100m
      .
      .
      .
    7. 저장을 클릭합니다.

      OpenShift는 Fuse 콘솔을 재배포합니다.

    8. 재배포가 완료되면 Workloads> Deployments> fuse-console 페이지를 열고 Environment 를 클릭하여 목록에서 환경 변수를 확인합니다.

2.4.6.2. Fuse Console 템플릿 설치에 대한 성능 튜닝

Openshift 4.x에서는 Fuse Console을 배포하기 전이나 후에 Nginx 성능 튜닝 환경 변수를 설정할 수 있습니다. 나중에 이 작업을 수행하면 OpenShift에서 Fuse 콘솔을 재배포합니다.

사전 요구 사항

절차

Fuse Console을 배포하기 전이나 후에 환경 변수를 설정할 수 있습니다.

  • Fuse 콘솔을 배포하기 전에 환경 변수를 설정하려면 다음을 수행합니다.

    1. 사용할 Fuse 콘솔 템플릿을 결정합니다.

      • 클러스터 템플릿 (fuse-console-cluster-os4.json)
      • 구성 가능한 RBAC가 있는 클러스터 템플릿 (fuse-console-cluster-rbac.yml)
      • 네임스페이스 템플릿(fuse-console-namespace-os4.json)
      • 구성 가능한 RBAC가 있는 네임스페이스 템플릿 (fuse-console-namespace-rbac.yml)
    2. 다음 예에 표시된 대로 Fuse Console 템플릿의 로컬 사본을 편집하여 NGINX_CLIENT_BODY_BUFFER_SIZE,NGINX_PROXY_BUFFERS, 및/또는 NGINX_SUBREQUEST_OUTPUT_BUFFER_SIZE 환경 변수를 포함합니다.

      apiVersion: apps.openshift.io/v1
      kind: DeploymentConfig
      metadata:
        name: fuse-console
      spec:
        template:
          spec:
            containers:
            - env:
              - name: NGINX_CLIENT_BODY_BUFFER_SIZE
                value: 256k
              - name: NGINX_PROXY_BUFFERS
                value: 16 128k
              - name: NGINX_SUBREQUEST_OUTPUT_BUFFER_SIZE
                value: 100m
    3. 변경 사항을 저장하십시오.
    4. OpenShift 4.x에서 Fuse Console 설정에 설명된 대로 Fuse Console을 설치하고 배포하는 단계를 따르십시오.
  • Fuse 콘솔을 배포한 후 환경 변수를 설정하려면 다음을 수행합니다.

    1. 터미널 창에서 OpenShift 클러스터에 로그인합니다.
    2. Fuse Console이 배포된 프로젝트를 엽니다. 예를 들어 Fuse Console이 myfuse 프로젝트에 배포된 경우 다음 명령을 사용합니다.

      oc project myfuse

    3. Fuse Console 배포의 이름을 가져옵니다.

      oc get deployments

      이 명령은 현재 프로젝트에서 실행 중인 배포 목록을 반환합니다. 예를 들면 다음과 같습니다.

      NAME                        READY   UP-TO-DATE   AVAILABLE    AGE
      fuse-console                1/1     1               1           114m
    4. 다음 명령 중 하나 이상을 실행하여 Fuse Console 배포에 대한 환경 변수를 설정합니다.

      oc set env dc/fuse-console NGINX_CLIENT_BODY_BUFFER_SIZE="256k"
      
      oc set env dc/fuse-console NGINX_PROXY_BUFFERS="16 128k"
      
      oc set env dc/fuse-console NGINX_SUBREQUEST_OUTPUT_BUFFER_SIZE="10m"

      OpenShift는 Fuse 콘솔을 재배포합니다.

    5. 재배포가 완료되면 환경 변수 설정을 확인합니다.

      1. Fuse Console Pod 이름을 가져옵니다.

        oc get pods
      2. 다음 명령을 실행하여 환경 설정을 확인합니다.

        oc exec <fuse-console-podname> -- cat /opt/app-root/etc/nginx.d/nginx-gateway.conf | grep "Performance tuning" -A 3

        예를 들어 Pod 이름이 fuse-console-6646cbbd4c-9rplg 인 경우 다음 명령을 실행합니다.

        oc exec fuse-console-6646cbbd4c-9rplg -- cat /opt/app-root/etc/nginx.d/nginx-gateway.conf | grep "Performance tuning" -A 3

2.4.6.3. Fuse Console에서 애플리케이션을 볼 수 있는 성능 튜닝

Fuse 콘솔의 성능 튜닝 기능을 통해 많은 수의 applications를 통해 애플리케이션을 볼 수 있습니다. 이 기능을 사용하려면 다음 단계를 수행하십시오.

사전 요구 사항

절차

  1. 애플리케이션의 메모리 제한을 늘립니다.

    예를 들어 256Mi에서 512Mi로 메모리 제한을 늘려야 하므로 애플리케이션이 Fuse 콘솔에 도달하기 전에 OOM 오류와 충돌하지 않습니다. Fuse 빠른 시작의 경우 애플리케이션의 skopeo /main/jkube/deployment.yml 파일을 편집합니다.

    spec:
      template:
        spec:
          containers:
            -
              resources:
                [...]
                limits:
                  cpu: "1.0"
                  memory: 512Mi
  2. Fuse Console Deployment 또는 DeploymentConfig 에 메모리 제한이 충분한지 확인합니다. 충분하지 않은 경우 제한을 200Mi에서 512Mi로 늘립니다.
  3. nginx 로그에 "too large subrequest response while sending to client" 오류가 표시되면 2.4.6.1절. “Fuse Console Operator 설치에 대한 성능 튜닝” 섹션에 언급된 솔루션을 적용합니다.

2.5. OpenShift에서 Fuse 애플리케이션을 모니터링하도록 Prometheus 구성

2.5.1. Prometheus 정보

Prometheus 는 Red Hat OpenShift 환경에 배포된 서비스를 모니터링하는 데 사용할 수 있는 오픈 소스 시스템 및 서비스 모니터링 및 경고 툴킷입니다. Prometheus는 지정된 간격으로 구성된 서비스에서 지표를 수집 및 저장하고, 규칙 표현식을 평가하고, 결과를 표시하며, 지정된 조건이 true가 되면 경고를 트리거할 수 있습니다.

중요

Prometheus에 대한 Red Hat 지원은 Red Hat 제품 설명서에 제공된 설정 및 구성 권장 사항으로 제한됩니다.

OpenShift 서비스를 모니터링하려면 엔드포인트를 Prometheus 형식으로 노출하도록 각 서비스를 구성해야 합니다. 이 끝점은 메트릭 목록과 메트릭의 현재 값을 제공하는 HTTP 인터페이스입니다. Prometheus는 각 대상 정의 끝점을 주기적으로 스크랩하고 수집된 데이터를 해당 데이터베이스에 씁니다. Prometheus는 현재 실행 중인 세션뿐만 아니라 연장된 시간 동안 데이터를 수집합니다. Prometheus는 데이터를 그래픽으로 시각화하고 데이터에 대한 쿼리를 실행할 수 있도록 데이터를 저장합니다.

2.5.1.1. Prometheus 쿼리

Prometheus 웹 인터페이스에서 Prometheus 쿼리 언어(PromQL) 에서 쿼리를 작성하여 수집된 데이터를 선택하고 집계할 수 있습니다.

예를 들어 다음 쿼리를 사용하여 메트릭 이름으로 http_requests_total 이 있는 모든 시계열 데이터에 대해 Prometheus가 지난 5분 내에 기록된 모든 값을 선택할 수 있습니다.

http_requests_total[5m]

쿼리 결과를 추가로 정의하거나 필터링하려면 메트릭에 대한 레이블( 키:값 쌍)을 지정합니다. 예를 들어 다음 쿼리를 사용하여 지표 이름 http_requests_total통합 으로 설정된 모든 시계열 데이터에 대해 Prometheus가 지난 5분 내에 기록된 모든 값을 선택할 수 있습니다.

http_requests_total{job="integration"}[5m]

2.5.1.2. Prometheus 데이터를 표시하는 옵션

Prometheus가 쿼리 결과를 처리하는 방법을 지정할 수 있습니다.

  • Prometheus의 표현식 브라우저에서 Prometheus 데이터를 테이블 형식 데이터로 확인합니다.
  • Prometheus HTTP API 를 통해 외부 시스템에서 Prometheus 데이터를 사용합니다.
  • 그래프에 Prometheus 데이터를 표시합니다.

    Prometheus는 수집하는 데이터에 대한 기본 그래픽 보기를 제공합니다. Prometheus 데이터를 보기 위해 보다 강력한 그래픽 대시보드를 선호하는 경우 Grafana가 널리 사용됩니다.

    참고

    Grafana는 커뮤니티 지원 기능입니다. Red Hat 제품을 모니터링하기 위해 Grafana를 배포하는 것은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서는 지원되지 않습니다.

PromQL 언어를 사용하여 Prometheus의 Alertmanager 툴 에서 경고를 구성할 수도 있습니다.

2.5.2. 4.13용 Prometheus 설정

Prometheus를 설정하려면 클러스터에 Prometheus Operator 사용자 정의 리소스 정의를 설치한 다음 Fuse 애플리케이션이 포함된 OpenShift 프로젝트에 Prometheus를 추가합니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 클러스터 관리자 액세스 권한이 있어야 합니다.
  • OpenShift의 Fuse에 설명된 대로 OpenShift 이미지 및 템플릿에 Fuse를 설치하여 OpenShift 클러스터를 준비했습니다.
  • 클러스터에 OpenShift 프로젝트를 생성하고 여기에 Fuse 애플리케이션을 추가했습니다.

절차

  1. 관리자 권한으로 OpenShift에 로그인합니다.

    oc login --user system:admin --token=my-token --server=https://my-cluster.example.com:6443
  2. cluster-monitoring-config.yml:이라는 파일을 생성합니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
    data:
     config.yaml: |
       enableUserWorkload: true
  3. "openshift-monitoring" 네임스페이스에 클러스터 모니터링 구성을 적용합니다.

    oc create -f cluster-monitoring-config.yml -n openshift-monitoring

서비스 모니터에 는 OpenShift Container Platform에서 지정된 서비스 및 프로젝트(네임스페이스)에 대한 지표를 수집하는 Prometheus에 대한 지침이 포함되어 있습니다.

  1. 서비스 모니터를 설치하려면 다음을 수행합니다.
oc process -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/monitors/fuse-servicemonitor.yml -p NAMESPACE=<your-fuse-namespace> -p FUSE_SERVICE_NAME=<fuse-app-name> | oc apply -f -

+ 예를 들어 myfuseapp 이라는 Fuse 애플리케이션을 포함하는 myproject 라는 OpenShift 프로젝트(네임스페이스)를 사용합니다.

+

예제

oc process -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/monitors/fuse-servicemonitor.yml -p NAMESPACE=myproject -p FUSE_SERVICE_NAME=myfuseapp | oc apply -f -

  1. Prometheus 대시보드를 여는 다음을 수행합니다.

    1. OpenShift 콘솔에 로그인합니다.
    2. Prometheus를 추가한 프로젝트를 엽니다.
    3. 왼쪽 창에서 관리자 보기를 선택하고 모니터링 -> 메트릭을 엽니다.
    4. Prometheus Hostname URL을 클릭하여 Prometheus 대시보드를 엽니다.

Prometheus에 대한 자세한 내용은 Prometheus 설명서 를 참조하십시오.

2.5.3. OpenShift 환경 변수

애플리케이션의 Prometheus 인스턴스를 구성하려면 표 2.2. “Prometheus 환경 변수” 에 나열된 OpenShift 환경 변수를 설정할 수 있습니다.

표 2.2. Prometheus 환경 변수

환경 변수설명Default

AB_PROMETHEUS_HOST

바인딩할 호스트 주소입니다.

0.0.0.0

AB_PROMETHEUS_OFF

설정된 경우 Prometheus의 활성화를 비활성화합니다(예: 빈 값 선택).

Prometheus가 활성화되어 있습니다.

AB_PROMETHEUS_PORT

사용할 포트입니다.

9779

AB_JMX_EXPORTER_CONFIG

파일(path 포함)을 Prometheus 구성 파일로 사용합니다.

Camel 지표를 사용한 /opt/prometheus/prometheus-config.yml 파일

AB_JMX_EXPORTER_OPTS

10.0.0.1 내보내기 구성에 추가할 수 있는 추가 옵션입니다.

해당 없음

추가 리소스

Pod의 환경 변수 설정에 대한 자세한 내용은 OpenShift 개발자 가이드 (https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html/developer_guide/)를 참조하십시오.

2.5.4. Prometheus가 모니터링하고 수집하는 메트릭 제어

기본적으로 Prometheus는 Camel에 의해 노출되는 모든 가능한 지표를 포함하는 구성 파일( https://raw.githubusercontent.com/jboss-fuse/application-templates/master/prometheus/prometheus-config.yml)을 사용합니다.

Prometheus가 모니터링 및 수집(예: 애플리케이션 프로세스 순서 수)에 사용자 지정 메트릭이 있는 경우 자체 구성 파일을 사용할 수 있습니다. 확인할 수 있는 지표는 ScanSetting에서 제공된 지표로 제한됩니다.

절차

사용자 지정 구성 파일을 사용하여 기본 Prometheus 구성에서 다루지 않는ans를 노출하려면 다음 단계를 따르십시오.

  1. 사용자 정의 Prometheus 구성 파일을 생성합니다. 기본 파일(prometheus-config.yml https://raw.githubusercontent.com/jboss-fuse/application-templates/master/prometheus/prometheus-config.yml)의 내용을 형식의 가이드로 사용할 수 있습니다.

    사용자 지정 구성 파일에 모든 이름을 사용할 수 있습니다(예: my-prometheus-config.yml ).

  2. prometheus 설정 파일(예: my-prometheus-config.yml)을 애플리케이션의 gRPC /main/jkube-includes 디렉터리에 추가합니다.
  3. 애플리케이션 내에 ScanSetting /main/jkube/deployment.xml 파일을 생성하고 해당 값을 구성 파일로 설정하여 AB_JMX_EXPORTER_CONFIG 환경 변수에 대한 항목을 추가합니다. 예를 들면 다음과 같습니다.

    spec:
      template:
        spec:
          containers:
            -
              resources:
                requests:
                  cpu: "0.2"
                limits:
                  cpu: "1.0"
              env:
              - name: SPRING_APPLICATION_JSON
                value: '{"server":{"tomcat":{"max-threads":1}}}'
              - name: AB_JMX_EXPORTER_CONFIG
                value: "my-prometheus-config.yml"

    이 환경 변수는 Pod 수준에서 애플리케이션에 적용됩니다.

  4. 애플리케이션을 다시 빌드하고 배포합니다.

2.6. OpenShift에서 Fuse에 미터링 사용

OCP 4에서 사용 가능한 미터링 툴을 사용하여 다양한 데이터 소스에서 미터링 보고서를 생성할 수 있습니다. 클러스터 관리자는 미터링을 사용하여 클러스터에서 발생하는 상황을 분석할 수 있습니다. 자체적으로 작성하거나 사전 정의된 SQL 쿼리를 사용하여 사용 가능한 다양한 데이터 소스에서 데이터를 처리하는 방법을 정의할 수 있습니다. Prometheus를 기본 데이터 소스로 사용하여 Pod, 네임스페이스 및 대부분의 기타 Kubernetes 리소스에 대한 보고서를 생성할 수 있습니다. 미터링 툴을 사용하려면 먼저 OpenShift Container Platform 4.x에 Metering Operator를 설치하고 구성해야 합니다. 미터링에 대한 자세한 내용은 미터링 을 참조하십시오.

참고

IBM Power Systems 및 IBM Z에서는 Fuse on OpenShift 미터링이 지원되지 않습니다.

2.6.1. 미터링 리소스

미터링에는 많은 리소스가 있으며, 기능 미터링을 보고하는 기능과 함께 미터링 배포 및 설치를 관리하는 데 사용할 수 있습니다. 미터링은 다음 CRD(CustomResourceDefinitions)를 사용하여 관리합니다.

표 2.3. 미터링 리소스

이름설명

MeteringConfig

배포에 대해 미터링 스택을 구성합니다. 미터링 스택을 구성하는 각 구성 요소를 제어하기 위한 사용자 정의 및 구성 옵션이 포함되어 있습니다.

Reports

사용할 쿼리, 쿼리를 실행할 빈도 및 결과를 저장할 위치를 제어합니다.

ReportQueries

ReportDataSources에 포함된 데이터에서 분석을 수행하는 데 사용되는 SQL 쿼리를 포함합니다.

ReportDataSources

ReportQueries 및 Reports에서 사용할 수 있는 데이터를 제어합니다. 미터링 내에서 사용할 수 있도록 다양한 데이터베이스에 대한 액세스를 구성할 수 있습니다.

2.6.2. OpenShift에서 Fuse의 미터링 레이블

표 2.4. 미터링 라벨

레이블가능한 값

com.company

Red_Hat

rht.prod_name

Red_Hat_Integration

rht.prod_ver

7.11

rht.comp

Fuse

rht.comp_ver

7.11

rht.subcomp

fuse7-java-openshift

fuse7-eap-openshift

fuse7-karaf-openshift

rht.subcomp_t

인프라

2.7. 사용자 지정 Grafana 대시보드를 사용하여 OpenShift에서 Fuse 모니터링

OpenShift Container Platform 4.6에서는 클러스터 구성 요소 및 사용자 정의 워크로드의 상태를 이해하는 데 도움이 되는 모니터링 대시보드를 제공합니다.

사전 요구 사항

OpenShift에서 Fuse에 대한 사용자 정의 대시보드

OpenShift에서 Fuse에 사용할 수 있는 두 가지 사용자 지정 대시보드가 있습니다. 이러한 대시보드를 사용하려면 클러스터에 Grafana 및 Prometheus를 설치하고 구성해야 합니다. OpenShift에서는 Fuse에 대해 제공되는 두 가지 종류의 예제 대시보드가 있습니다. Fuse Grafana 대시보드에서 이러한 대시보드를 가져올 수 있습니다.

  • Fuse Pod / 인스턴스 지표 대시보드:

    이 대시보드는 단일 Fuse 애플리케이션 Pod / 인스턴스에서 지표를 수집합니다. fuse-grafana-dashboard.yml 을 사용하여 대시보드를 가져올 수 있습니다. OpenShift의 Fuse Pod 지표 대시보드용 패널 테이블에는 다음이 포함됩니다.

    표 2.5. Fuse Pod 지표 대시보드

    제목번들쿼리설명

    프로세스 시작 시간

    -

    process_start_time_seconds{pod="$pod"}*1000

    프로세스가 시작된 시간

    현재 메모리 HEAP

    -

    sum(jvm_memory_bytes_used{pod="$pod", area="heap"})*100/sum(jvm_memory_bytes_max{pod="$pod", area="heap"})

    Fuse에서 현재 사용 중인 메모리

    메모리 사용량

    committed

    sum(jvm_memory_bytes_committed{pod="$pod"})

    커밋된 메모리

     

    사용됨

    sum(jvm_memory_bytes_used{pod="$pod"})

    사용된 메모리

     

    최대

    sum(jvm_memory_bytes_max{pod="$pod"})

    최대 메모리

    스레드

    current

    jvm_threads_current{pod="$pod"}

    현재 스레드 수

     

    daemon

    jvm_threads_daemon{pod="$pod"}

    데몬 스레드 수

     

    peak

    jvm_threads_peak{pod="$pod"}

    최대 스레드 수

    Camel 교환/1m

    exchange 완료 / 1m

    sum(increase(org_apache_camel_ExchangesCompleted{pod="$pod"}[1m]))

    1분당 Camel 출력 완료

     

    exchange Failed / 1m

    sum(increase(org_apache_camel_ExchangesFailed{pod="$pod"}[1m]))

    분당 Camel의 전환 실패

     

    exchange total / 1m

    sum(increase(org_apache_camel_ExchangesTotal{pod="$pod"}[1m]))

    분당 총 Camel 교환

     

    exchange inflight

    sum(org_apache_camel_ExchangesInflight{pod="$pod"})

    Camel의 현재 처리 중입니다.

    Camel 처리 시간

    CloudEvent 처리 시간

    sum(org_apache_camel_DeltaProcessingTime{pod="$pod"})

    Camel 처리 시간

     

    마지막 처리 시간

    sum(org_apache_camel_LastProcessingTime{pod="$pod"})

    Camel 처리 마지막 시간

     

    최대 처리 시간

    sum(org_apache_camel_MaxProcessingTime{pod="$pod"})

    Camel 처리 최대 시간

     

    최소 처리 시간

    sum(org_apache_camel_MinProcessingTime{pod="$pod"})

    최소 Camel 처리 시간

     

    평균 처리 시간

    sum(org_apache_camel_MeanProcessingTime{pod="$pod"})

    평균 Camel 처리 시간

    Camel 서비스 기간

    최대 기간

    sum(org_apache_camel_MaxDuration{pod="$pod"})

    최대 Camel 서비스 기간

     

    최소 기간

    sum(org_apache_camel_MinDuration{pod="$pod"})

    최소 Camel 서비스 기간

     

    기간

    sum(org_apache_camel_MeanDuration{pod="$pod"})

    mean Camel 서비스 기간

    Camel 실패 및 반환

    Redeliveries

    sum(org_apache_camel_Redeliveries{pod="$pod"})

    재전송 수

     

    마지막 처리 시간

    sum(org_apache_camel_LastProcessingTime{pod="$pod"})

    Camel 처리 마지막 시간

     

    외부 재전송

    sum(org_apache_camel_ExternalRedeliveries{pod="$pod"})

    외부 재전송 수

  • Fuse Camel 경로 지표 대시보드:

    이 대시보드는 Fuse 애플리케이션에서 단일 Camel 경로에서 지표를 수집합니다. fuse-grafana-dashboard-routes.yml 을 사용하여 대시보드를 가져올 수 있습니다. OpenShift의 Fuse Camel 경로 지표 대시보드용 패널 표에는 다음이 포함됩니다.

    표 2.6. Fuse Camel Route 지표 대시보드

    제목번들쿼리설명

    교환/초당

    -

    rate(org_apache_camel_ExchangesTotal{route="\"$route\""}[5m])

    초당 총 Camel 교환

    exchange inflight

    -

    max(org_apache_camel_ExchangesInflight{route="\"$route\""})

    현재 처리 중인 Camel exchange 수

    교환 실패 비율

    -

    sum(org_apache_camel_camel_ExchangesFailed{route="\"route\""}) / sum(org_apache_camel_ExchangesTotal{route="\"""})

    실패한 Camel 교환의 백분율

    평균 처리 시간

    -

    org_apache_camel_MeanProcessingTime{route="\"$route\""}

    평균 Camel 처리 시간

    교환/초당

    실패

    rate(org_apache_camel_ExchangesFailed{route="\"$route\""}[5m])

    초당 교환 실패

     

    Completed

    rate(org_apache_camel_ExchangesCompleted{route="\"$route\""}[5m])

    초당 완료된 교환

    exchange inflight

    exchange inflight

    org_apache_camel_ExchangesInflight{route="\"$route\""}

    Camel의 현재 처리 중입니다.

    처리 시간

    최대

    org_apache_camel_MaxProcessingTime{route="\"$route\""}

    Camel 처리 최대 시간

     

    mean

    org_apache_camel_MeanProcessingTime{route="\"$route\""}

    평균 Camel 처리 시간

     

    min

    org_apache_camel_MinProcessingTime{route="\"$route\""}

    최소 Camel 처리 시간

    외부 재전송(초당 전송)

    -

    rate(org_apache_camel_ExternalRedeliveries{route="\"$route\""}[5m])

    초당 외부 전송

    Redeliveries per second

    -

    rate(org_apache_camel_Redeliveries{route="\"$route\""}[5m])

    Redeliveries per second

    초당 처리 실패

    -

    rate(org_apache_camel_FailuresHandled{route="\"$route\""}[5m])

    초당 처리 실패

2.8. OpenShift 3.x 서버에 Fuse 이미지 스트림 및 템플릿 설치

registry.redhat.io 에 대한 인증을 구성한 후 OpenShift 이미지 스트림 및 템플릿에서 Red Hat Fuse를 가져오고 사용합니다.

절차

  1. OpenShift Server를 시작합니다.
  2. 관리자로 OpenShift 서버에 로그인합니다.

    oc login -u system:admin
  3. docker-registry 시크릿을 생성한 프로젝트를 사용하고 있는지 확인합니다.

    oc project openshift
  4. OpenShift 이미지 스트림에 Fuse를 설치합니다.

    BASEURL=https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002
    
    oc create -n openshift -f ${BASEURL}/fis-image-streams.json
  5. 빠른 시작 템플릿을 설치합니다.

    for template in eap-camel-amq-template.json \
     eap-camel-cdi-template.json \
     eap-camel-cxf-jaxrs-template.json \
     eap-camel-cxf-jaxws-template.json \
     karaf-camel-amq-template.json \
     karaf-camel-log-template.json \
     karaf-camel-rest-sql-template.json \
     karaf-cxf-rest-template.json ;
     do
     oc create -n openshift -f \
     ${BASEURL}/quickstarts/${template}
     done
  6. Spring Boot 2 빠른 시작 템플릿을 설치합니다.

    for template in spring-boot-2-camel-amq-template.json \
     spring-boot-2-camel-config-template.json \
     spring-boot-2-camel-drools-template.json \
     spring-boot-2-camel-infinispan-template.json \
     spring-boot-2-camel-rest-3scale-template.json \
     spring-boot-2-camel-rest-sql-template.json \
     spring-boot-2-camel-template.json \
     spring-boot-2-camel-xa-template.json \
     spring-boot-2-camel-xml-template.json \
     spring-boot-2-cxf-jaxrs-template.json \
     spring-boot-2-cxf-jaxws-template.json \
     spring-boot-2-cxf-jaxrs-xml-template.json \
     spring-boot-2-cxf-jaxws-xml-template.json ;
     do oc create -n openshift -f \
     ${BASEURL}/quickstarts/${template}
     done
  7. Fuse Console용 템플릿을 설치합니다.

    oc create -n openshift -f ${BASEURL}/fis-console-cluster-template.json
    oc create -n openshift -f ${BASEURL}/fis-console-namespace-template.json
    참고

    Fuse Console 배포에 대한 자세한 내용은 OpenShift에 Fuse Console 설정을 참조하십시오.

  8. Apicurito 템플릿을 설치합니다.

    oc create -n openshift -f ${BASEURL}/fuse-apicurito.yml
  9. (선택 사항) OpenShift 이미지 및 템플릿에 설치된 Fuse를 확인합니다.

    oc get template -n openshift

2.8.1. OpenShift 3.11에서 Fuse Console 설정

OpenShift 3.11에서는 Fuse 콘솔에 액세스할 수 있습니다.

  • 프로젝트에서 실행 중인 모든 Fuse 컨테이너를 모니터링할 수 있도록 Fuse 콘솔을 OpenShift 프로젝트에 추가합니다.
  • 클러스터의 모든 프로젝트에서 실행 중인 모든 Fuse 컨테이너를 모니터링할 수 있도록 OpenShift 클러스터에 Fuse 콘솔을 추가합니다.
  • 실행 중인 단일 Fuse 컨테이너를 모니터링할 수 있도록 특정 Fuse Pod에서 이 파일을 엽니다.

명령줄에서 Fuse Console 템플릿을 배포합니다.

참고

Minishift 또는 CDK 기반 환경에 Fuse Console을 설치하려면 아래 KCS 문서에 설명된 단계를 따르십시오.

  • Minishift 또는 CDK 기반 환경에 Fuse Console을 설치하려면 KCS 4998441 을 참조하십시오.
  • Jolokia 인증을 비활성화해야 하는 경우 KCS 3988671 에 설명된 해결 방법을 참조하십시오.

사전 요구 사항

참고
  • Fuse Console의 사용자 관리는 OpenShift에서 처리합니다.
  • OpenShift 3.11의 Fuse에서는 아직 Fuse를 사용할 수 없습니다.(배포 후 Fuse 콘솔에 액세스하는 사용자의 경우)은 아직 OpenShift 3.11에서 Fuse에 액세스할 수 없습니다.

2.8.1.1절. “OpenShift 3.11에 Fuse 콘솔 배포”

2.8.1.2절. “OpenShift 3.11의 Fuse 콘솔에서 단일 Fuse Pod 모니터링”

2.8.1.1. OpenShift 3.11에 Fuse 콘솔 배포

표 2.7. “Fuse 콘솔 템플릿” Fuse 애플리케이션 배포 유형에 따라 명령줄에서 Fuse 콘솔을 배포하는 데 사용할 수 있는 OpenShift 3.11 템플릿에 대해 설명합니다.

표 2.7. Fuse 콘솔 템플릿

유형설명

fis-console-cluster-template.json

Fuse Console은 여러 네임스페이스 또는 프로젝트에 배포된 Fuse 애플리케이션을 검색하고 연결할 수 있습니다. 이 템플릿을 배포하려면 OpenShift cluster-admin 역할이 있어야합니다.

fis-console-namespace-template.json

이 템플릿은 현재 OpenShift 프로젝트(네임스페이스)에 대한 Fuse Console 액세스를 제한하며, 이러한 액세스는 단일 테넌트 배포 역할을 합니다. 이 템플릿을 배포하려면 현재 OpenShift 프로젝트에 대한 admin 역할이 있어야 합니다.

선택적으로 다음 명령을 실행하여 모든 템플릿에 대한 매개변수 목록을 볼 수 있습니다.

oc process --parameters -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fis-console-namespace-template.json
참고

Fuse Console 템플릿은 기본적으로 엔드 투 엔드 암호화를 구성하여 브라우저에서 클러스터 내 서비스로 Fuse Console 요청을 보호합니다.

사전 요구 사항

  • OpenShift 3.11의 클러스터 모드의 경우 클러스터 관리자 역할과 클러스터 모드 템플릿이 필요합니다. 다음 명령을 실행합니다.

    oc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:openshift-infra:template-instance-controller

절차

명령줄에서 Fuse 콘솔을 배포하려면 다음을 수행합니다.

  1. 다음 명령 중 하나를 실행하여 Fuse Console 템플릿을 기반으로 새 애플리케이션을 생성합니다(여기서 myproject 는 프로젝트 이름입니다).

    • Fuse Console 클러스터 템플릿의 경우 myhost 는 Fuse 콘솔에 액세스할 수 있는 호스트 이름입니다.

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fis-console-cluster-template.json -p ROUTE_HOSTNAME=myhost
    • Fuse Console 네임스페이스 템플릿의 경우:

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fis-console-namespace-template.json
      참고

      OpenShift가 자동으로 생성되므로 네임스페이스 템플릿의 route_hostname 매개변수를 생략할 수 있습니다.

  2. 다음 명령을 실행하여 Fuse Console 배포의 상태 및 URL을 가져옵니다.

    oc status
  3. 브라우저에서 Fuse Console에 액세스하려면 제공된 URL을 사용합니다.

2.8.1.2. OpenShift 3.11의 Fuse 콘솔에서 단일 Fuse Pod 모니터링

OpenShift 3.11에서 실행되는 Fuse Pod의 Fuse 콘솔을 열 수 있습니다.

사전 요구 사항

  • 포드 보기에서 Fuse Console에 대한 링크를 표시하도록 OpenShift를 구성하려면 OpenShift 이미지에서 Fuse를 실행하는 Pod에서 jolokia 로 설정된 name 속성 내에서 TCP 포트를 선언해야 합니다.

    {
      "kind": "Pod",
      [...]
      "spec": {
        "containers": [
          {
            [...]
            "ports": [
              {
                "name": "jolokia",
                "containerPort": 8778,
                "protocol": "TCP"
              }

절차

  1. OpenShift 프로젝트의 애플리케이션 → Pod 보기에서 포드 이름을 클릭하여 실행 중인 Fuse Pod의 세부 정보를 확인합니다. 이 페이지 오른쪽에는 컨테이너 템플릿에 대한 요약이 표시됩니다.

    Container Template View

  2. 이 보기에서 Open Java Console (Java 콘솔 열기) 링크를 클릭하여 Fuse 콘솔을 엽니다.

    Fuse Console view

3장. 제한된 환경에서 Fuse on Openshift 설치

제한적이지 않은 환경에서 OpenShift에 Fuse를 설치하려면 registry.redhat.io 에서 이미지 스트림 및 템플릿을 가져옵니다. 인터넷 액세스가 제한되거나 제한되지 않은 프로덕션 환경에서는 이 작업을 수행할 수 없습니다. 이 섹션에서는 제한된 환경에서 OpenShift에 Fuse를 설치하는 방법을 설명합니다.

참고

제한된 환경에 설치는 현재 IBM Power Systems, IBM Z 및 LinuxONE에서 지원되지 않습니다.

사전 요구 사항

  • 제한된 환경에서 실행할 수 있도록 OpenShift 서버를 설치하고 구성했습니다.

3.1. 내부 Docker 레지스트리 설정

이 섹션에서는 이미지를 내보내거나 가져오는 데 사용할 수 있는 내부 Docker 레지스트리를 설정하는 방법을 설명합니다. 이미지를 가져오거나 내보낼 수 있는 내부 Docker 레지스트리를 구성해야 합니다.

절차

  1. 내부 루트 CA를 설치합니다.

    cd /etc/pki/ca-trust/source/anchors
    sudo curl -O https://password.corp.redhat.com/RH-IT-Root-CA.crt
    sudo update-ca-trust extract
    sudo update-ca-trust update

    이 인증서를 사용하면 시스템이 레지스트리에 자체적으로 인증할 수 있습니다.

  2. registry.redhat.io 에 로그인합니다.

    docker login -u USERNAME -p PASSWORD registry.redhat.io
  3. registry.redhat.io 에서 OpenShift 이미지의 Fuse를 가져옵니다.

    docker pull registry.redhat.io/fuse7/fuse-java-openshift-rhel8:1.11
    docker pull registry.redhat.io/fuse7/fuse-java-openshift-jdk11-rhel8:1.11
    docker pull registry.redhat.io/fuse7/fuse-karaf-openshift-rhel8:1.11
    docker pull registry.redhat.io/fuse7/fuse-console-rhel8:1.11
    docker pull registry.redhat.io/fuse7/fuse-apicurito-rhel8:1.11
    docker pull registry.redhat.io/fuse7/fuse-apicurito-generator-rhel8:1.11
  4. 가져온 이미지 스트림에 태그를 지정합니다.

    docker tag registry.redhat.io/fuse7/fuse-java-openshift-rhel8:1.11 docker-registry.upshift.redhat.com/fuse7/fuse-java-openshift-rhel8:1.11
    docker tag registry.redhat.io/fuse7/fuse-java-openshift-jdk11-rhel8:1.11 docker-registry.upshift.redhat.com/fuse7/fuse-java-openshift-jdk11-rhel8:1.11
    docker tag registry.redhat.io/fuse7/fuse-karaf-openshift-rhel8:1.11 docker-registry.upshift.redhat.com/fuse-karaf-openshift-rhel8:1.11
    docker tag registry.redhat.io/fuse7/fuse-console-rhel8:1.11 docker-registry.upshift.redhat.com/fuse7-fuse-console-rhel8:1.11
    docker tag registry.redhat.io/fuse7/fuse-apicurito-rhel8:1.11 docker-registry.upshift.redhat.com/fuse7-fuse-apicurito-rhel8:1.11
    docker tag registry.redhat.io/fuse7/fuse-apicurito-generator-rhel8:1.11 docker-registry.upshift.redhat.com/fuse7-fuse-apicurito-generator-rhel8:1.11
  5. 태그가 지정된 이미지 스트림을 내부 Docker 레지스트리로 푸시합니다.

    docker push docker-registry.upshift.redhat.com/fuse7/fuse-java-openshift-rhel8:1.11
    docker push docker-registry.upshift.redhat.com/fuse7/fuse-java-openshift-jdk11-rhel8:1.11
    docker push docker-registry.upshift.redhat.com/fuse-karaf-openshift-rhel8:1.11
    docker push docker-registry.upshift.redhat.com/fuse7-fuse-console-rhel8:1.11
    docker push docker-registry.upshift.redhat.com/fuse7-fuse-apicurito-rhel8:1.11
    docker push docker-registry.upshift.redhat.com/fuse7-fuse-apicurito-generator-rhel8:1.11

3.2. 내부 레지스트리 보안 구성

제한된 Docker 레지스트리를 설정하고 모든 이미지를 푸시한 후 내부 레지스트리와 통신할 수 있도록 제한된 OpenShift 서버를 구성해야 합니다.

절차

  1. 관리자로 OpenShift 클러스터에 로그인합니다.

    oc login --user system:admin --token=my-token --server=https://my-cluster.example.com:6443
  2. Fuse를 배포할 프로젝트를 엽니다.

    oc project myproject
  3. Red Hat Customer Portal 계정을 사용하여 docker-registry 시크릿을 생성하고 PULL_SECRET_NAMEpsi-internal-registry 로 교체하여 다음을 생성합니다.

    oc create secret docker-registry psi-internal-registry \
      --docker-server=docker-registry.redhat.io \
      --docker-username=CUSTOMER_PORTAL_USERNAME \
      --docker-password=CUSTOMER_PORTAL_PASSWORD \
      --docker-email=EMAIL_ADDRESS

    다음 출력이 표시되어야 합니다.

    secret/psi-internal-registry created
    중요

    registry.redhat.io 에 인증할 모든 OpenShift 프로젝트 네임스페이스에 이 docker-registry 시크릿을 생성해야 합니다.

  4. 이미지를 가져오는 데 시크릿을 사용하도록 서비스 계정에 시크릿을 연결합니다. 다음 예제에서는 기본 서비스 계정, 빌더 서비스 계정 및 배포자 서비스 계정을 사용합니다.

    oc secrets link default psi-internal-registry
    oc secrets link default psi-internal-registry --for=pull
    oc secrets link builder psi-internal-registry
    oc secrets link builder psi-internal-registry --for=pull
    oc secrets link deployer psi-internal-registry
    oc secrets link deployer psi-internal-registry --for=pull

    서비스 계정 이름은 OpenShift pod에서 사용하는 이름과 일치해야 합니다.

    참고

    Red Hat 사용자 이름 및 암호를 사용하여 풀 시크릿을 생성하지 않으려면 레지스트리 서비스 계정을 사용하여 인증 토큰을 생성할 수 있습니다.

3.3. 제한된 환경에서 OpenShift 이미지에 Fuse 설치

fis-image-streams.json 파일에는 OpenShift에서 Red Hat Fuse의 imageStream 정의가 포함되어 있습니다. 그러나 모든 이미지 스트림은 registry.redhat.io 를 참조합니다. psi-internal-registry URL에 대한 모든 registry.redhat.io 참조를 변경해야 합니다.

절차

  1. OpenShift 이미지 스트림 json 파일에서 Red Hat Fuse를 다운로드합니다.

    curl -o fis-image-streams.json https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002/fis-image-streams.json
  2. fis-image-streams.json 파일을 열고 registry.redhat.io 에 대한 모든 참조를 찾습니다. 예를 들면 다음과 같습니다.

    {
    "name": "1.9",
    "annotations": {
    "description": "Red Hat Fuse 7.11 Karaf S2I images.",
    "openshift.io/display-name": "Red Hat Fuse 7.11 Karaf",
    "iconClass": "icon-rh-integration",
    "tags": "builder,jboss-fuse,java,karaf,xpaas,hidden",
    "supports":"jboss-fuse:7.11.0,java:8,xpaas:1.2",
    "version": "1.9"
    },
    "referencePolicy": {
    "type": "Local"
    },
    "from": {
    "kind": "DockerImage",
    "name": "registry.redhat.io/fuse7/fuse-karaf-openshift-rhel8:1.11"
    }
    },
  3. 파일의 모든 registry.redhat.io 참조를 psi-internal-registry 이름으로 바꿉니다. 예를 들면 다음과 같습니다.

    {
    "name": "1.9",
    "annotations": {
    "description": "Red Hat Fuse 7.11 Karaf S2I images.",
    "openshift.io/display-name": "Red Hat Fuse 7.11 Karaf",
    "iconClass": "icon-rh-integration",
    "tags": "builder,jboss-fuse,java,karaf,xpaas,hidden",
    "supports":"jboss-fuse:7.11.0,java:8,xpaas:1.2",
    "version": "1.9"
    },
    "referencePolicy": {
    "type": "Local"
    },
    "from": {
    "kind": "DockerImage",
    "name": "docker-registry.upshift.redhat.com/fuse7/fuse-karaf-openshift-rhel8:1.11"
    }
    },
  4. 모든 참조가 교체된 후 다음 명령을 실행하여 OpenShift 이미지 스트림에 Fuse를 설치합니다.

    oc create -f fis-image-streams.json -n {namespace}

3.4. 내부 Maven 리포지토리 사용

제한된 환경에서는 다른 Maven 리포지토리를 사용해야 합니다. MAVEN_MIRROR_URL 이라는 템플릿 매개변수를 사용하여 지정할 수 있습니다. 이 MAVEN_MIRROR_URL 매개변수를 사용하여 명령줄에서 새 애플리케이션을 생성할 수 있습니다.

3.4.1. MAVEN_MIRROR_URL을 사용하여 Spring Boot 애플리케이션 실행

이 예에서는 MAVEN_MIRROR_URL을 사용하여 Spring Boot 애플리케이션을 배포하고 실행하는 방법을 설명합니다.

절차

  1. Spring Boot Camel XML 빠른 시작을 다운로드합니다.

    oc create -f ./spring-boot-2-camel-xml-template.json -n openshift
  2. 다음 명령을 입력하여 MAVEN_MIRROR_URL 매개변수를 사용하여 Spring Boot 빠른 시작 템플릿을 실행하는 데 필요한 리소스를 생성합니다.

    제한된 환경에서는 로컬 리포지토리에 대한 GIT_REPOGIT_REF 매개변수를 지정해야 합니다.

    oc new-app s2i-fuse711-spring-boot-2-camel-xml -n {namespace} -p IMAGE_STREAM_NAMESPACE={namespace} -p MAVEN_MIRROR_URL={Maven mirror URL} -p GIT_REPO={Git Repo URL} -p GIT_REF={Git branch/tag name}

    그러면 빠른 시작에 대한 배포 구성 및 빌드 구성이 생성됩니다. 빠른 시작 및 생성된 리소스의 기본 매개변수에 대한 정보가 터미널에 표시됩니다.

3.4.2. OpenShift Maven 플러그인으로 Spring Boot 애플리케이션 실행

이 예제에서는 내부 Maven 리포지토리를 사용하여 OpenShift Maven 플러그인으로 Spring Boot 애플리케이션을 배포하고 실행하는 방법을 설명합니다.

절차

  1. OpenShift Maven 플러그인으로 빠른 시작을 실행하려면 로컬 리포지토리에서 Spring Boot 2 camel archetype을 다운로드한 다음 빠른 시작을 배포합니다. {Maven Mirror URL} 을 Maven 미러 저장소 URL로 바꿉니다.

    mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate \
      -DarchetypeCatalog={Maven Mirror URL}/archetypes/archetypes-catalog/2.2.0.fuse-sb2-7_11_1-00018-redhat-00002/archetypes-catalog-2.2.0.fuse-sb2-7_11_1-00018-redhat-00002-archetype-catalog.xml \
      -DarchetypeGroupId=org.jboss.fuse.fis.archetypes \
      -DarchetypeArtifactId=spring-boot-camel-xml-archetype
      -DarchetypeVersion=2.2.0.fuse-sb2-7_11_1-00018-redhat-00002
  2. archetype 플러그인이 대화형 모드로 전환하여 나머지 필드를 입력하라는 메시지를 표시합니다.

    Define value for property 'groupId': : org.example.fis
    Define value for property 'artifactId': : fuse711-spring-boot2
    Define value for property 'version':  1.0-SNAPSHOT: :
    Define value for property 'package':  org.example.fis: :
    Confirm properties configuration:
    groupId: org.example.fis
    artifactId: fuse711-spring-boot
    version: 1.0-SNAPSHOT
    package: org.example.fis
     Y: : Y
  3. 위의 명령이 BUILD SUCCESS 상태로 종료되면 이제 fuse711-spring-boot2 하위 디렉터리 아래에 OpenShift 프로젝트에 새 Fuse가 있어야 합니다.
  4. 이제 fuse711-spring-boot2 프로젝트를 빌드하고 배포할 준비가 되었습니다. 아직 OpenShift에 로그인했다고 가정하면 fuse711-spring-boot2 프로젝트의 디렉터리로 변경한 다음 다음과 같이 프로젝트를 빌드하고 배포합니다.

    cd fuse711-spring-boot2
    mvn oc:deploy -Popenshift

4장. 관리자가 아닌 사용자로 OpenShift에 Fuse 설치

애플리케이션을 생성하고 OpenShift에 배포하여 OpenShift에서 Fuse on OpenShift 사용을 시작할 수 있습니다. 먼저 OpenShift 이미지 및 템플릿에 Fuse를 설치해야 합니다.

4.1. 관리자가 아닌 사용자로 OpenShift 이미지 및 템플릿에 Fuse 설치

사전 요구 사항

  • OpenShift 서버에 액세스할 수 있습니다. CDK별 가상 OpenShift 서버 또는 원격 OpenShift 서버일 수 있습니다.
  • registry.redhat.io 를 사용한 인증이 구성되어 있습니다.

자세한 내용은 다음을 참조하십시오.

절차

  1. OpenShift 프로젝트에서 Fuse를 빌드 및 배포하기 위한 준비 과정에서 다음과 같이 OpenShift 서버에 로그인합니다.

    oc login -u developer -p developer https://OPENSHIFT_IP_ADDR:8443

    여기서 OPENSHIFT_IP_ADDR 은 이 IP 주소가 항상 동일하지는 않으므로 OpenShift 서버의 IP 주소 자리 표시자입니다.

    참고

    개발자 사용자(개발자 암호 포함)는 CDK별 가상 OpenShift Server에서 자동으로 생성되는 표준 계정입니다. 원격 서버에 액세스하는 경우 OpenShift 관리자가 제공한 URL 및 인증 정보를 사용합니다.

  2. test 라는 새 프로젝트 네임스페이스를 생성합니다(아직 존재하지 않는다고 가정).

    oc new-project test

    test 프로젝트 네임스페이스가 이미 있는 경우 해당 네임스페이스로 전환합니다.

    oc project test
  3. OpenShift 이미지 스트림에 Fuse를 설치합니다.

    BASEURL=https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002
    
    oc create -n test -f ${BASEURL}/fis-image-streams.json

    명령 출력에는 이제 OpenShift 프로젝트의 Fuse에서 사용할 수 있는 Fuse 이미지 스트림이 표시됩니다.

  4. 빠른 시작 템플릿을 설치합니다.

    BASEURL=https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002
    
    for template in eap-camel-amq-template.json \
     eap-camel-cdi-template.json \
     eap-camel-cxf-jaxrs-template.json \
     eap-camel-cxf-jaxws-template.json \
     karaf-camel-amq-template.json \
     karaf-camel-log-template.json \
     karaf-camel-rest-sql-template.json \
     karaf-cxf-rest-template.json ;
     do
     oc create -n test -f \
     ${BASEURL}/quickstarts/${template}
     done
  5. Spring Boot 2 빠른 시작 템플릿을 설치합니다.

    BASEURL=https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002
    
    for template in spring-boot-2-camel-amq-template.json \
     spring-boot-2-camel-config-template.json \
     spring-boot-2-camel-drools-template.json \
     spring-boot-2-camel-infinispan-template.json \
     spring-boot-2-camel-rest-3scale-template.json \
     spring-boot-2-camel-rest-sql-template.json \
     spring-boot-2-camel-template.json \
     spring-boot-2-camel-xa-template.json \
     spring-boot-2-camel-xml-template.json \
     spring-boot-2-cxf-jaxrs-template.json \
     spring-boot-2-cxf-jaxws-template.json \
     spring-boot-2-cxf-jaxrs-xml-template.json \
     spring-boot-2-cxf-jaxws-xml-template.json ;
     do oc create -n openshift -f \
     ${BASEURL}/quickstarts/${template}
     done
  6. Fuse Console용 템플릿을 설치합니다.

    oc create -n test -f ${BASEURL}/fis-console-cluster-template.json
    oc create -n test -f ${BASEURL}/fis-console-namespace-template.json
    참고

    Fuse Console 배포에 대한 자세한 내용은 OpenShift에 Fuse Console 설정을 참조하십시오.

  7. (선택 사항) OpenShift 이미지 및 템플릿에 설치된 Fuse를 봅니다.

    oc get template -n test
  8. 브라우저에서 OpenShift 콘솔로 이동합니다.

    1. https://OPENSHIFT_IP_ADDR:8443 을 사용하고 OPENSHIFT_IP_ADDR 을 OpenShift 서버의 IP 주소로 바꿉니다.
    2. 자격 증명을 사용하여 OpenShift 콘솔에 로그인합니다(예: 사용자 이름 developer 및 암호 developer).

5장. 개발자를 위한 시작하기

5.1. 개발 환경 준비

OpenShift 프로젝트에서 Fuse를 개발하고 테스트하려면 OpenShift Server에 액세스할 수 있어야 합니다. 다음과 같은 기본 대체 방법이 있습니다.

5.1.1. 로컬 머신에 CDK(컨테이너 개발 키트) 설치

개발자로서 빠르게 시작하려는 경우 가장 실용적인 대안은 로컬 시스템에 Red Hat CDK 를 설치하는 것입니다. CDK를 사용하면 RHEL(Red Hat Enterprise Linux) 7에서 OpenShift 이미지를 실행하는 VM(가상 머신) 인스턴스를 부팅할 수 있습니다. CDK 설치는 다음과 같은 주요 구성 요소로 구성됩니다.

  • 가상 머신(libvirt,ECDHE 또는 Hyper-V)
  • 컨테이너 개발 환경을 시작하고 관리하기 위한 Minishift
중요

Red Hat CDK는 개발 목적으로만 사용됩니다. 프로덕션 환경과 같은 다른 용도로는 사용되지 않으며 알려진 보안 취약점을 해결할 수 없습니다. docker 형식의 컨테이너 내에서 미션 크리티컬 애플리케이션을 실행하기 위해서는 활성 RHEL 7 또는 RHEL Atomic 서브스크립션이 필요합니다. 자세한 내용은 Red Hat Container Development Kit (CDK) 지원을 참조하십시오.

사전 요구 사항

  • Java 버전

    개발자 시스템에서 Fuse 7.11에서 지원하는 Java 버전을 설치했는지 확인합니다. 지원되는 Java 버전에 대한 자세한 내용은 지원되는 구성을 참조하십시오.

절차

로컬 컴퓨터에 CDK를 설치하려면 다음을 수행합니다.

  1. OpenShift에서 Fuse의 경우 CDK 버전 3.17을 설치하는 것이 좋습니다. CDK 3.17 설치 및 사용에 대한 자세한 지침은 Red Hat CDK 3.17 시작하기 가이드에서 제공됩니다.
  2. 컨테이너 이미지의 registry.redhat.io 로 인증하는 지침에 따라 Red Hat Ecosystem Catalog에 액세스하도록 OpenShift 인증 정보를 구성합니다.
  3. 2장. 관리자의 시작하기 에 설명된 대로 OpenShift 이미지 및 템플릿에 Fuse를 수동으로 설치합니다.

    참고

    CDK 버전에는 OpenShift 이미지 및 템플릿에 대한 Fuse가 사전 설치되어 있을 수 있습니다. 그러나 OpenShift 인증 정보를 구성한 후 OpenShift 이미지 및 템플릿에 Fuse를 설치(또는 업데이트)해야 합니다.

  4. 이 장의 예제를 진행하기 전에 Red Hat CDK 3.17 시작하기 가이드 의 내용을 읽고 철저히 이해해야 합니다.

5.1.2. 기존 OpenShift 서버에 대한 원격 액세스 가져오기

IT 부서에서 이미 일부 서버 시스템에서 OpenShift 클러스터를 설정했을 수 있습니다. 이 경우 OpenShift에서 Fuse를 시작하려면 다음 요구 사항을 충족해야 합니다.

  • 서버 머신은 지원되는 구성 페이지에 설명된 대로 지원되는 OpenShift Container Platform 버전을 실행해야 합니다. 이 가이드의 예는 3.11 버전에 대해 테스트되었습니다.
  • OpenShift 관리자에게 최신 Fuse를 OpenShift 컨테이너 기본 이미지에 설치하고 OpenShift 서버에 OpenShift 템플릿에 Fuse를 설치하도록 요청합니다.
  • OpenShift 관리자에게 일반 개발자 권한이 있는 사용자 계정을 생성하도록 요청합니다(OpenShift 프로젝트를 생성, 배포, 실행할 수 있도록 허용).
  • 관리자에게 OpenShift Server의 URL(OpenShift 콘솔을 찾아보거나 oc 명령줄 클라이언트를 사용하여 OpenShift에 연결할 수 있음) 및 계정의 로그인 자격 증명을 요청할 수 있습니다.

5.1.3. 클라이언트-Side 툴 설치

개발자 머신에 다음 툴을 설치하는 것이 좋습니다.

  • Apache Maven 3.6.x: OpenShift 프로젝트의 로컬 빌드에 필요합니다. Apache Maven 다운로드 페이지에서 적절한 패키지를 다운로드합니다. 최소 버전 3.6.x(또는 이후 버전)가 설치되어 있는지 확인합니다. 그러지 않으면 Maven에 프로젝트를 빌드할 때 종속성을 해결하는 데 문제가 있을 수 있습니다.
  • Git: OpenShift S2I 소스 워크플로에 필요하며 일반적으로 OpenShift 프로젝트에서 Fuse의 소스 제어에 권장됩니다. Git 다운로드 페이지에서 적절한 패키지를 다운로드합니다.
  • OpenShift 클라이언트: CDK를 사용하는 경우 minishift oc -env 를 사용하여 oc 바이너리를 추가하여 쉘에 입력해야 하는 명령을 표시할 수 있습니다( oc-env 의 출력은 OS 및 쉘 유형에 따라 달라집니다).

    $ minishift oc-env
    export PATH="/Users/john/.minishift/cache/oc/v1.5.0:$PATH"
    # Run this command to configure your shell:
    # eval $(minishift oc-env)

    자세한 내용은 CDK 3.17 시작하기 가이드에서 OpenShift 클라이언트 바이너리 사용을 참조하십시오.

    CDK를 사용하지 않는 경우 CLI 참조 의 지침에 따라 oc 클라이언트 도구를 설치합니다.

  • (선택 사항) Docker 클라이언트: 고급 사용자는 Docker 클라이언트 툴을 설치(OpenShift 서버에서 실행 중인 docker 데몬과 통신)하는 것이 편리합니다. 운영 체제의 특정 바이너리 설치에 대한 자세한 내용은 Docker 설치 사이트를 참조하십시오.

    자세한 내용은 CDK 3.17 시작하기 가이드에서 docker Daemon 재사용을 참조하십시오.

    중요

    OpenShift Server에서 실행되는 OpenShift 버전과 호환되는 oc 툴 및 docker 툴을 설치해야 합니다.

5.1.4. Maven 리포지토리 구성

로컬 시스템에서 OpenShift에서 Fuse 프로젝트를 빌드하는 데 필요한 archetypes 및 아티팩트를 보유하는 Maven 리포지토리를 구성합니다.

절차

  1. 일반적으로 ~/.m2/ settings.xml (Linux 또는 macOS) 또는 Documents 및 Settings\<USER_NAME>\.m2\settings.xml (Windows에서)에 있는 Maven settings.xml 파일을 엽니다.
  2. 다음 Maven 리포지토리를 추가합니다.

5.2. OpenShift에서 Fuse에서 애플리케이션 생성 및 배포

다음 S2I(Source-to-Image) 애플리케이션 개발 워크플로우 중 하나를 사용하여 애플리케이션을 생성하고 OpenShift에 배포하여 OpenShift에서 Fuse on OpenShift를 사용할 수 있습니다.

S2I 바이너리 워크플로
바이너리 소스의 빌드 입력이 있는 S2I. 이 워크플로는 빌드가 개발자의 자체 시스템에서 부분적으로 실행된다는 사실을 특징으로 합니다. 바이너리 패키지를 로컬로 빌드한 후 이 워크플로는 바이너리 패키지를 OpenShift로 전달합니다. 자세한 내용은 빌드 OpenShift Container Platform 가이드의 바이너리 소스를 참조하십시오.
S2I 소스 워크플로
Git 소스에서 빌드 입력이 있는 S2I . 이 워크플로는 빌드가 OpenShift 서버에서 완전히 실행되는 것을 특징으로 합니다. 자세한 내용은 빌드 OpenShift Container Platform 가이드의 Git 소스를 참조하십시오.

5.2.1. S2I 바이너리 워크플로를 사용하여 애플리케이션 생성 및 배포

이 섹션에서는 OpenShift S2I 바이너리 워크플로를 사용하여 OpenShift 프로젝트에서 Fuse를 생성, 빌드 및 배포합니다.

참고
JDK11로 빠른 시작 실행
런타임 시 JDK11 기반 이미지를 사용하려는 경우 컴파일 시간 동안 올바른 JDK11 프로필을 사용합니다. JDK11을 사용하여 빠른 시작을 빌드하고 배포할 때 빌드 머신에 JDK11을 설치한 다음 올바른 JDK11 프로필을 사용하여 빠른 시작을 빌드해야 합니다.

절차

  1. Maven archetype을 사용하여 OpenShift 프로젝트에서 새 Fuse를 만듭니다. 이 예제에서는 샘플 Spring Boot Camel 프로젝트를 생성하는 archetype을 사용합니다. 새 쉘 프롬프트를 열고 다음 Maven 명령 중 하나를 입력합니다.

    • 모든 S2I 빠른 시작에 액세스하려면 다음을 수행하십시오.

      mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate \
        -DarchetypeCatalog=https://maven.repository.redhat.com/ga/io/fabric8/archetypes/archetypes-catalog/2.2.0.fuse-sb2-7_11_1-00018-redhat-00002/archetypes-catalog-2.2.0.fuse-sb2-7_11_1-00018-redhat-00002-archetype-catalog.xml \
        -DarchetypeGroupId=org.jboss.fuse.fis.archetypes \
        -DarchetypeVersion=2.2.0.fuse-sb2-7_11_1-00018-redhat-00002
    • spring-boot-2-camel-xml 빠른 시작에 액세스하려면 다음을 수행하십시오.

      mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate \
        -DarchetypeCatalog=https://maven.repository.redhat.com/ga/io/fabric8/archetypes/archetypes-catalog/2.2.0.fuse-sb2-7_11_1-00018-redhat-00002/archetypes-catalog-2.2.0.fuse-sb2-7_11_1-00018-redhat-00002-archetype-catalog.xml \
        -DarchetypeGroupId=org.jboss.fuse.fis.archetypes \
        -DarchetypeArtifactId=spring-boot-camel-xml-archetype \
        -DarchetypeVersion=2.2.0.fuse-sb2-7_11_1-00018-redhat-00002

      archetype 플러그인이 대화형 모드로 전환하여 나머지 필드를 입력하라는 메시지를 표시합니다.

      Define value for property 'groupId': : org.example.fis
      Define value for property 'artifactId': : fuse711-spring-boot
      Define value for property 'version':  1.0-SNAPSHOT: :
      Define value for property 'package':  org.example.fis: :
      Confirm properties configuration:
      groupId: org.example.fis
      artifactId: fuse711-spring-boot
      version: 1.0-SNAPSHOT
      package: org.example.fis
       Y: : Y

      메시지가 표시되면 groupId 값으로 org.example.fis 를 입력하고 artifactId 값으로 fuse711-spring-boot 를 입력합니다. 나머지 필드에는 기본값을 수락합니다.

  2. 이전 명령이 BUILD SUCCESS 상태로 종료되면 이제 fuse711-spring-boot 하위 디렉터리 아래에 OpenShift 프로젝트에 새 Fuse가 있어야 합니다. fuse711-spring-boot/src/main/resources/spring/camel-context.xml 파일에서 XML DSL 코드를 검사할 수 있습니다. 데모 코드는 임의의 번호가 포함된 메시지를 로그에 지속적으로 전송하는 간단한 Camel 경로를 정의합니다.
  3. OpenShift 프로젝트에서 Fuse를 빌드 및 배포하기 위한 준비 과정에서 다음과 같이 OpenShift 서버에 로그인합니다.

    oc login -u developer -p developer https://OPENSHIFT_IP_ADDR:8443

    여기서 OPENSHIFT_IP_ADDR 은 이 IP 주소가 항상 동일하지는 않으므로 OpenShift 서버의 IP 주소 자리 표시자입니다.

    참고

    개발자 사용자( 개발자 암호 포함)는 CDK별 가상 OpenShift Server에서 자동으로 생성되는 표준 계정입니다. 원격 서버에 액세스하는 경우 OpenShift 관리자가 제공한 URL 및 인증 정보를 사용합니다.

  4. 다음과 같이 openshift 프로젝트( openshift 프로젝트에 아직 없는 경우)로 전환합니다.

    oc project openshift
  5. 다음 명령을 실행하여 Fuse on OpenShift 이미지 및 템플릿이 이미 설치되어 있고 액세스할 수 있는지 확인합니다.

    oc get template -n openshift

    이미지 및 템플릿이 사전 설치되지 않거나 제공된 버전이 최신 상태인 경우 OpenShift 이미지 및 템플릿에 Fuse를 수동으로 설치(또는 업데이트)합니다. OpenShift 이미지에 Fuse를 설치하는 방법에 대한 자세한 내용은 2장. 관리자의 시작하기 에서 참조하십시오.

  6. 이제 fuse711-spring-boot 프로젝트를 빌드하고 배포할 준비가 되었습니다. 아직 OpenShift에 로그인했다고 가정하면 fuse711-spring-boot 프로젝트의 디렉터리로 변경한 다음 다음과 같이 프로젝트를 빌드하고 배포합니다.

    cd fuse711-spring-boot
    mvn oc:deploy -Popenshift

    성공적인 빌드가 끝나면 다음과 같은 일부 출력이 표시됩니다.

    ...
    [INFO] OpenShift platform detected
    [INFO] Using project: openshift
    [INFO] Creating a Service from openshift.yml namespace openshift name fuse711-spring-boot
    [INFO] Created Service: target/jkube/applyJson/openshift/service-fuse711-spring-boot.json
    [INFO] Using project: openshift
    [INFO] Creating a DeploymentConfig from openshift.yml namespace openshift name fuse711-spring-boot
    [INFO] Created DeploymentConfig: target/jkube/applyJson/openshift/deploymentconfig-fuse711-spring-boot.json
    [INFO] Creating Route openshift:fuse711-spring-boot host: null
    [INFO] F8: HINT: Use the command `oc get pods -w` to watch your pods start up
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 05:38 min
    [INFO] Finished at: 2020-12-04T12:15:06+05:30
    [INFO] Final Memory: 63M/688M
    [INFO] ------------------------------------------------------------------------
    참고

    이 명령을 처음 실행할 때 Maven은 많은 종속성을 다운로드해야 하는데, 이 경우 몇 분이 걸립니다. 이후 빌드가 더 빨라집니다.

  7. 브라우저에서 OpenShift 콘솔로 이동하여 자격 증명을 사용하여 콘솔에 로그인합니다(예: 사용자 이름 developer 및 암호, developer).
  8. 왼쪽 패널에서 을 확장한 다음 상태를 클릭하여 openshift 프로젝트의 프로젝트 상태 페이지를 확인합니다.
  9. fuse711-spring-boot 를 클릭하여 fuse711-spring-boot 애플리케이션의 개요 정보 페이지를 확인합니다.

    Overview

  10. 왼쪽 패널에서 워크로드 를 확장합니다.
  11. 포드 를 클릭합니다. openshift 프로젝트에서 실행 중인 모든 포드가 표시됩니다.
  12. Pod 이름 (이 예에서는 fuse711-spring-boot-xxxxx)을 클릭하여 실행 중인 Pod의 세부 정보를 확인합니다.

    Pod Details

  13. 로그 탭을 클릭하여 애플리케이션 로그를 확인하고 로그를 아래로 스크롤하여 Camel 애플리케이션에서 생성한 임의 번호 로그 메시지를 찾습니다.

    ...
    06:45:54.311 [Camel (MyCamel) thread #1 - timer://foo] INFO simple-route - >>> 130
    06:45:56.265 [Camel (MyCamel) thread #1 - timer://foo] INFO simple-route - >>> 898
    06:45:58.265 [Camel (MyCamel) thread #1 - timer://foo] INFO simple-route - >>> 414
    06:46:00.265 [Camel (MyCamel) thread #1 - timer://foo] INFO simple-route - >>> 486
    06:46:02.265 [Camel (MyCamel) thread #1 - timer://foo] INFO simple-route - >>> 093
    06:46:04.265 [Camel (MyCamel) thread #1 - timer://foo] INFO simple-route - >>> 080
  14. 실행 중인 Pod를 종료하려면

    1. openshift 프로젝트의 프로젝트 상태 페이지에서 fuse711-spring-boot 애플리케이션을 클릭합니다.
    2. 개요 탭을 클릭하여 애플리케이션의 개요 정보 페이지를 확인합니다.
    3. 원하는 개수 옆에 있는 edit pod count 아이콘을 클릭합니다. 개수 편집 창이 표시됩니다.
    4. Pod를 중지하려면 아래쪽 화살표를 사용하여 0으로 축소합니다.

5.2.2. 프로젝트 배포 취소 및 재배포

다음과 같이 프로젝트를 배포 취소하거나 재배포할 수 있습니다.

절차

  • 프로젝트 배포를 취소하려면 다음 명령을 입력합니다.

    mvn oc:undeploy
  • 프로젝트를 재배포하려면 명령을 입력합니다.

    mvn oc:undeploy
    mvn oc:deploy -Popenshift

5.2.3. S2I 소스 워크플로를 사용하여 애플리케이션 생성 및 배포

이 섹션에서는 OpenShift S2I 소스 워크플로를 사용하여 템플릿을 기반으로 OpenShift 애플리케이션을 기반으로 Fuse를 빌드하고 배포합니다. 이 데모의 시작점은 원격 Git 리포지토리에 저장된 빠른 시작 프로젝트입니다. OpenShift 콘솔을 사용하여 이 빠른 시작 프로젝트를 OpenShift 서버에 다운로드, 빌드 및 배포합니다.

절차

  1. 다음과 같이 OpenShift 서버에 로그인합니다.

    oc login -u developer -p developer https://OPENSHIFT_IP_ADDR:8443

    여기서 OPENSHIFT_IP_ADDR 은 이 IP 주소가 항상 동일하지는 않으므로 OpenShift 서버의 IP 주소 자리 표시자입니다.

    참고

    개발자 사용자( 개발자 암호 포함)는 CDK별 가상 OpenShift Server에서 자동으로 생성되는 표준 계정입니다. 원격 서버에 액세스하는 경우 OpenShift 관리자가 제공한 URL 및 인증 정보를 사용합니다.

  2. 다음과 같이 openshift 프로젝트( openshift 프로젝트에 아직 없는 경우)로 전환합니다.

    oc project openshift
  3. 다음 명령을 실행하여 OpenShift 템플릿의 Fuse가 이미 설치되어 있고 액세스할 수 있는지 확인합니다.

    oc get template -n openshift

    이미지 및 템플릿이 사전 설치되지 않거나 제공된 버전이 최신 상태인 경우 OpenShift 이미지 및 템플릿에 Fuse를 수동으로 설치(또는 업데이트)합니다. OpenShift 이미지에 Fuse를 설치하는 방법에 대한 자세한 내용은 2장. 관리자의 시작하기 에서 참조하십시오.

  4. 다음 명령을 입력하여 Red Hat Fuse 7.11 Camel XML DSL을 Spring Boot 빠른 시작 템플릿으로 실행하는 데 필요한 리소스를 생성합니다. 그러면 빠른 시작에 대한 배포 구성 및 빌드 구성이 생성됩니다. 빠른 시작 및 생성된 리소스의 기본 매개변수에 대한 정보가 터미널에 표시됩니다.

    oc new-app s2i-fuse7-spring-boot-camel-xml
    
    --> Deploying template "openshift/s2i-fuse7-spring-boot-camel-xml" to project openshift
    ...
    --> Creating resources ...
        imagestream.image.openshift.io "s2i-fuse7-spring-boot-camel-xml" created
        buildconfig.build.openshift.io "s2i-fuse7-spring-boot-camel-xml" created
        deploymentconfig.apps.openshift.io "s2i-fuse7-spring-boot-camel-xml" created
    --> Success
        Build scheduled, use 'oc logs -f bc/s2i-fuse7-spring-boot-camel-xml' to track its progress.
        Run 'oc status' to view your app.
  5. 브라우저의 OpenShift 웹 콘솔로 이동합니다(https://OPENSHIFT_IP_ADDR, OPENSHIFT_IP_ADDR 을 클러스터의 IP 주소로 교체) 자격 증명으로 로그인합니다(예: 사용자 이름 개발자 및 암호, developer).
  6. 왼쪽 패널에서 을 확장합니다. 상태를 클릭하여 프로젝트 상태 페이지를 확인합니다. 선택한 네임스페이스(예: openshift)의 기존 애플리케이션이 모두 표시됩니다.
  7. s2i-fuse7-spring-boot-camel-xml 을 클릭하여 빠른 시작에 대한 개요 정보 페이지를 확인합니다.

    Spring Boot Camel XML Overview

  8. Resources 탭을 클릭한 다음 로그 보기를 클릭하여 애플리케이션의 빌드 로그를 확인합니다.

    Spring Boot Camel XML build logs

  9. 왼쪽 패널에서 워크로드 를 확장합니다.
  10. Pod 를 클릭한 다음 s2i-fuse7-spring-boot-camel-xml-xxxx 를 클릭합니다. 애플리케이션의 Pod 세부 정보가 표시됩니다.

    Spring Boot Camel XML pod details

  11. 실행 중인 Pod를 종료하려면

    1. openshift 프로젝트의 프로젝트 상태 페이지에서 s2i-fuse7-spring-boot-camel-xml-xxxx 애플리케이션을 클릭합니다.
    2. 개요 탭을 클릭하여 애플리케이션의 개요 정보 페이지를 확인합니다.
    3. 원하는 개수 옆에 있는 edit pod count 아이콘을 클릭합니다. 개수 편집 창이 표시됩니다.
    4. Pod를 중지하려면 아래쪽 화살표를 사용하여 0으로 축소합니다.

6장. Spring Boot 이미지용 애플리케이션 개발

이 장에서는 Spring Boot 이미지의 애플리케이션을 개발하는 방법을 설명합니다.

6.1. Maven archetype을 사용하여 Spring Boot 2 프로젝트 생성

이 빠른 시작에서는 Maven archetypes를 사용하여 Spring Boot 2 프로젝트를 생성하는 방법을 설명합니다.

절차

  1. 시스템의 적절한 디렉터리로 이동합니다.
  2. 쉘 프롬프트에서 다음 mvn 명령을 입력하여 Spring Boot 2 프로젝트를 생성합니다.

    mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate \
      -DarchetypeCatalog=https://maven.repository.redhat.com/ga/io/fabric8/archetypes/archetypes-catalog/2.2.0.fuse-sb2-7_11_1-00018-redhat-00002/archetypes-catalog-2.2.0.fuse-sb2-7_11_1-00018-redhat-00002-archetype-catalog.xml \
      -DarchetypeGroupId=org.jboss.fuse.fis.archetypes \
      -DarchetypeArtifactId=spring-boot-camel-xml-archetype \
      -DarchetypeVersion=2.2.0.fuse-sb2-7_11_1-00018-redhat-00002

    archetype 플러그인이 대화형 모드로 전환하여 나머지 필드를 입력하라는 메시지를 표시합니다.

    Define value for property 'groupId': : org.example.fis
    Define value for property 'artifactId': : fuse711-spring-boot
    Define value for property 'version':  1.0-SNAPSHOT: :
    Define value for property 'package':  org.example.fis: :
    Confirm properties configuration:
    groupId: org.example.fis
    artifactId: fuse711-spring-boot
    version: 1.0-SNAPSHOT
    package: org.example.fis
     Y: : Y

    메시지가 표시되면 groupId 값으로 org.example.fis 를 입력하고 artifactId 값으로 fuse711-spring-boot 를 입력합니다. 나머지 필드에는 기본값을 수락합니다.

  3. 위의 명령이 BUILD SUCCESS 상태로 종료되면 이제 fuse711-spring-boot 하위 디렉터리 아래에 OpenShift 프로젝트에 새 Fuse가 있어야 합니다.
  4. 이제 fuse711-spring-boot 프로젝트를 빌드하고 배포할 준비가 되었습니다. 아직 OpenShift에 로그인했다고 가정하면 fuse711-spring-boot 프로젝트의 디렉터리로 변경한 다음 다음과 같이 프로젝트를 빌드하고 배포합니다.

    cd fuse711-spring-boot
    mvn oc:deploy -Popenshift
참고

사용 가능한 Spring Boot 2 archetypes의 전체 목록은 Spring Boot 2 Archetype 카탈로그 를 참조하십시오.

6.2. Camel Spring Boot 애플리케이션의 구조

Camel Spring Boot 애플리케이션의 디렉터리 구조는 다음과 같습니다.

  ├── LICENSE.md
  ├── pom.xml
  ├── README.md
  ├── configuration
  │   └── settings.xml
  └── src
      ├── main
      │   ├── jkube
      │   │   └── deployment.yml
      │   ├── java
      │   │   └── org
      │   │       └── example
      │   │           └── fis
      │   │               ├── Application.java
      │   │               └── MyTransformer.java
      │   └── resources
      │       ├── application.properties
      │       ├── logback.xml
      │       └── spring
      │           └── camel-context.xml
      └── test
          └── java
              └── org
                  └── example
                      └── fis

다음 파일이 애플리케이션을 개발하는 데 중요한 위치:

pom.xml
추가 종속 항목을 포함합니다. Spring Boot와 호환되는 Camel 구성 요소는 시작 버전 (예: camel-jdbc-starter 또는 camel-infinispan-starter )에서 사용할 수 있습니다. 시작자가 pom.xml 에 포함되면 부팅 시 Camel 컨텐츠에 자동으로 구성 및 등록됩니다. 사용자는 application.properties 파일을 사용하여 구성 요소의 속성을 구성할 수 있습니다.
application.properties

다양한 환경에서 구성을 외부화하고 동일한 애플리케이션 코드로 작업할 수 있습니다. 자세한 내용은 외부 설정을 참조하십시오.

예를 들어 이 Camel 애플리케이션에서는 애플리케이션 이름 또는 IP 주소와 같은 특정 속성을 구성할 수 있습니다.

application.properties

#spring.main.sources=org.example.fos

logging.config=classpath:logback.xml

# the options from org.apache.camel.spring.boot.CamelConfigurationProperties can be configured here
camel.springboot.name=MyCamel

# lets listen on all ports to ensure we can be invoked from the pod IP
server.address=0.0.0.0
management.address=0.0.0.0

# lets use a different management port in case you need to listen to HTTP requests on 8080
management.server.port=8081

# disable all management endpoints except health
endpoints.enabled = false
endpoints.health.enabled = true

Application.java

애플리케이션을 실행하는 것이 중요한 파일입니다. 사용자는 여기에서 Spring DSL을 사용하여 경로를 구성하기 위해 camel-context.xml 파일을 가져옵니다.

Application.java 파일은 기본 속성을 사용하여 @Configuration,@EnableAutoConfiguration@ComponentScan 에 해당하는 @SpringBootApplication 주석을 지정합니다.

Application.java

@SpringBootApplication
// load regular Spring XML file from the classpath that contains the Camel XML DSL
@ImportResource({"classpath:spring/camel-context.xml"})

Spring Boot 애플리케이션을 실행하는 기본 방법이 있어야 합니다.

Application.java

public class Application {
    /**
     * A main method to start this application.
     */
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

camel-context.xml

CloudEvent /main/resources/spring/camel-context.xml 은 Camel 경로가 포함되어 있으므로 애플리케이션을 개발하는 데 중요한 파일입니다.

참고

Spring-Boot 애플리케이션 개발에 대한 자세한 내용은 첫 번째 Spring Boot Application 개발에서확인할 수 있습니다.

src/main/jkube/deployment.yml

openshift-maven-plugin에서 생성한 기본 OpenShift 구성 파일과 병합되는 추가 구성을 제공합니다.

참고

이 파일은 Spring Boot 애플리케이션의 일부에는 사용되지 않지만 CPU 및 메모리 사용량과 같은 리소스를 제한하기 위해 모든 빠른 시작에서 사용됩니다.

6.3. Spring Boot 2 archetype 카탈로그

Spring Boot 2 Archetype 카탈로그에는 다음 예제가 포함되어 있습니다.

표 6.1. Spring Boot 2 Maven Archetypes

이름설명

spring-boot-camel-archetype

fabric8 Java 기본 이미지를 기반으로 Spring Boot와 함께 Apache Camel을 사용하는 방법을 시연합니다.

spring-boot-camel-amq-archetype

Spring Boot 애플리케이션을 ActiveMQ 브로커에 연결하고 Kubernetes 또는 OpenShift를 사용하여 두 Camel 경로 간에 JMS 메시징을 사용하는 방법을 보여줍니다.

spring-boot-camel-drools-archetype

Apache Camel을 사용하여 Kubernetes 또는 OpenShift에서 실행되는 Spring Boot 애플리케이션을 원격 Kie Server와 통합하는 방법을 보여줍니다.

spring-boot-camel-infinispan-archetype

Hot Rod 프로토콜을 사용하여 Spring Boot 애플리케이션을 JBoss Data Grid 또는 Infinispan 서버에 연결하는 방법을 보여줍니다.

spring-boot-camel-rest-3scale-archetype

Camel의 REST DSL을 사용하여 RESTful API를 노출하고 3scale에 노출하는 방법을 보여줍니다.

spring-boot-camel-rest-sql-archetype

Camel의 REST DSL과 함께 JDBC를 통해 SQL을 사용하여 RESTful API를 노출하는 방법을 시연합니다.

spring-boot-camel-xml-archetype

Spring XML 구성 파일을 통해 Spring Boot에서 Camel 경로를 구성하는 방법을 시연합니다.

spring-boot-cxf-jaxrs-archetype

fabric8 Java 기본 이미지를 기반으로 Spring Boot에서 Apache CXF를 사용하는 방법을 보여줍니다. 빠른 시작에서는 Spring Boot를 사용하여 Swagger가 활성화된 CXF>-<RS 엔드 포인트가 포함된 애플리케이션을 구성합니다.

spring-boot-cxf-jaxws-archetype

fabric8 Java 기본 이미지를 기반으로 Spring Boot에서 Apache CXF를 사용하는 방법을 보여줍니다. 빠른 시작에서는 Spring Boot를 사용하여 CXF>-<WS 엔드포인트를 포함하는 애플리케이션을 구성합니다.

spring-boot-cxf-jaxrs-xml-archetype

OpenShift에서 Spring Boot 2에서 Apache CXF>-<-RS를 사용하는 방법을 보여줍니다. 이 빠른 시작에서는 Spring Boot2를 사용하여 Swagger가 활성화된 CXFECDHERS 엔드포인트가 포함된 Spring 구성 파일 기반 CXF 애플리케이션을 시작합니다.

spring-boot-cxf-jaxws-xml-archetype

OpenShift에서 Spring Boot 2에서 Apache CXF>-<-WS를 사용하는 방법을 보여줍니다. 빠른 시작에서는 Spring Boot2를 사용하여 CXFECDHEWS 엔드포인트가 포함된 Spring 구성 파일 기반 CXF 애플리케이션을 시작합니다.

참고

다음 Spring Boot 2 Maven archetypes는 OpenShift에 빌드 및 배포되지 않습니다. 자세한 내용은 릴리스 정보를 참조하십시오.

  • spring-boot-camel-archetype
  • spring-boot-camel-infinspan-archetype
  • spring-boot-cxf-jaxrs-archetype
  • spring-boot-cxf-jaxws-archetype

이 문제를 해결하려면 빠른 시작에 대한 Maven 프로젝트를 생성한 후 프로젝트의 Maven pom.xml 파일을 편집하여 다음 종속성을 추가합니다.

<dependency>
  <groupId>org.assertj</groupId>
  <artifactId>assertj-core</artifactId>
  <version>2.4.1</version>
  <scope>test</scope>
</dependency>

6.4. BOM 파일 for Spring Boot

Maven gr of materialss(BOM) 파일의 목적은 선별된 Maven 종속성 버전 세트를 제공하여 모든 Maven 아티팩트에 대해 개별적으로 버전을 정의할 필요가 없도록 하는 것입니다.

중요

사용 중인 Spring Boot 버전에 따라 올바른 Fuse BOM을 사용하고 있는지 확인합니다.

Spring Boot용 Fuse BOM은 다음과 같은 이점을 제공합니다.

  • POM에 종속성을 추가할 때 버전을 지정할 필요가 없도록 Maven 종속성의 버전을 정의합니다.
  • 특정 버전의 Fuse에서 완전하게 테스트 및 지원되는 선별된 종속성 세트를 정의합니다.
  • Fuse 업그레이드 간소화.
중요

Red Hat에서는 Fuse BOM에서 정의한 종속 항목 집합만 지원합니다.

6.5. BOM 파일 통합

BOM 파일을 Maven 프로젝트에 통합하려면 Spring Boot 2의 예제와 같이 프로젝트의 pom.xml 파일 (또는 상위 POM 파일에서)의 dependencyManagement 요소를 지정합니다.

Spring Boot 2 BOM

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project ...>
  ...
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

    <!-- configure the versions you want to use here -->
    <fuse.version>7.11.1.fuse-sb2-7_11_1-00022-redhat-00002</fuse.version>
  </properties>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.redhat-fuse</groupId>
        <artifactId>fuse-springboot-bom</artifactId>
        <version>${fuse.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  ...
</project>

종속성 관리 메커니즘을 사용하여 BOM을 지정한 후에는 아티팩트 버전을 지정하지 않고 POM에 Maven 종속 항목을 추가할 수 있습니다. 예를 들어 camel-hystrix 구성 요소에 대한 종속성을 추가하려면 POM의 종속 요소에 다음 XML 조각을 추가합니다.

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-hystrix-starter</artifactId>
</dependency>

Camel 아티팩트 ID가 -starter suffix consumption-ECDHE로 지정된 방법을 참조하십시오. 즉, Camel Hystrix 구성 요소를 camel-hystrix-starter 로 지정( camel-hystrix )으로 지정합니다. Camel Starter 구성 요소는 Spring Boot 환경에 최적화된 방식으로 패키지됩니다.

6.6. Spring Boot Maven 플러그인

Spring Boot Maven 플러그인은 Spring Boot에서 제공하며 Spring Boot 프로젝트를 빌드하고 실행하기 위한 개발자 유틸리티입니다.

  • 프로젝트 디렉터리에 mvn 패키지를 입력하여 빌드 하면 Spring Boot 애플리케이션에 대한 실행 가능한 Jar 패키지를 생성합니다. 빌드의 출력은 Maven 프로젝트의 target/ 하위 디렉터리에 배치됩니다.
  • 편의를 위해 실행, mvn spring-boot:start 명령을 사용하여 새로 빌드된 애플리케이션을 실행할 수 있습니다.

Spring Boot Maven 플러그인을 프로젝트 POM 파일에 통합하려면 다음 예와 같이 pom.xml 파일의 project/build/plugins 섹션에 플러그인 구성을 추가합니다.

예제

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project ...>
  ...
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

    <!-- configure the versions you want to use here -->
    <fuse.version>7.11.1.fuse-sb2-7_11_1-00022-redhat-00002</fuse.version>

  </properties>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.jboss.redhat-fuse</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <version>${fuse.version}</version>
        <executions>
          <execution>
            <goals>
              <goal>repackage</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  ...
</project>

7장. Spring Boot에서 Apache Camel 애플리케이션 실행

Apache Camel Spring Boot 구성 요소는 Spring Boot에 대한 Camel 컨텍스트를 자동으로 구성합니다. Camel 컨텍스트의 자동 구성은 Spring 컨텍스트에서 사용 가능한 Camel 경로를 자동으로 감지하고 생산자 템플릿, 소비자 템플릿, 유형 변환기와 같은 주요 Camel 유틸리티를 빈으로 등록합니다. Apache Camel 구성 요소에는 시작점을 사용하여 Spring Boot 애플리케이션을 개발할 수 있는 Spring Boot starter 모듈이 포함되어 있습니다.

7.1. Camel Spring Boot 구성 요소 소개

모든 Camel Spring Boot 애플리케이션은 프로젝트의 pom.xmldependencyManagement 요소를 사용하여 제품화된 버전의 종속성을 지정해야 합니다. 이러한 종속 항목은 Red Hat Fuse BOM에 정의되어 있으며 특정 Red Hat Fuse 버전에서 지원됩니다. BOM에서 버전을 재정의하지 않도록 추가 시작자의 버전 번호 속성을 생략할 수 있습니다. 자세한 내용은 빠른 시작 pom 을 참조하십시오.

예제

<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.jboss.redhat-fuse</groupId>
			<artifactId>fuse-springboot-bom</artifactId>
			<version>${fuse.version}</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
	</dependencies>
</dependencyManagement>

참고

camel-spring-boot journalctl에는 Spring Boot가 Camel 컨텍스트를 자동으로 구성하도록 해당 종속성을 클래스 경로에 추가할 수 있는 spring.factories 파일이 포함되어 있습니다.

7.2. Camel Spring Boot starter 모듈 소개

Starters는 Spring Boot 애플리케이션에서 사용할 Apache Camel 모듈입니다. 각 Camel 구성 요소에는 camel-xxx-starter 모듈이 있습니다( 7.3절. “시작 모듈이 없는 Camel 구성 요소 목록” 섹션에 몇 가지 예외 사항이 있음).

Starter는 다음 요구 사항을 충족합니다.

  • IDE 툴과 호환되는 네이티브 Spring Boot 구성 시스템을 사용하여 구성 요소의 자동 구성을 허용합니다.
  • 데이터 형식 및 언어의 자동 구성을 허용합니다.
  • 전송 가능한 로깅 종속성을 관리하여 Spring Boot 로깅 시스템과 통합합니다.
  • 추가 종속성을 포함하고 전송적 종속성을 정렬하여 Spring Boot 애플리케이션 생성 노력을 최소화합니다.

각 Starter에는 현재 Spring Boot 릴리스와의 호환성을 확인하는 tests/camel-itest-spring-boot 에 자체 통합 테스트가 있습니다.

참고

자세한 내용은 link: Apache Camel Spring-Boot 예제 를 참조하십시오.

7.3. 시작 모듈이 없는 Camel 구성 요소 목록

다음 구성 요소에는 호환성 문제로 인해 시작 모듈이 없습니다.

  • Camel-blueprint (OSGi 전용 힌트)
  • Camel-cdi (CDI 전용 정수)
  • Camel-core-osgi (OSGi 전용 의도)
  • Camel-knative (JJ에만 의도됨)
  • Camel-eventadmin (OSGi 전용 의도)
  • Camel-ibatis (camel-myinitiatoris-starter 포함)
  • camel-jclouds
  • Camel-mina (camel-mina2-starter 포함)
  • Camel-paxlogging (OSGi 전용 힌트)
  • Camel-quartz (camel-quartz2-starter 포함)
  • camel-spark-rest
  • Camel-openapi-java (camel-openapi-java-starter 포함)

7.4. Camel Spring Boot Starter 사용

Apache Camel은 Spring Boot 애플리케이션 개발을 빠르게 시작할 수 있는 시작 모듈을 제공합니다.

절차

  1. Spring Boot pom.xml 파일에 다음 종속성을 추가합니다.

    <dependency>
        <groupId>org.apache.camel</groupId>
        <artifactId>camel-spring-boot-starter</artifactId>
    </dependency>
  2. 아래 스니펫에 표시된 대로 Camel 경로를 사용하여 클래스를 추가합니다. 이러한 경로가 클래스 경로에 추가되면 경로가 자동으로 시작됩니다.

    package com.example;
    
    import org.apache.camel.builder.RouteBuilder;
    import org.springframework.stereotype.Component;
    
    @Component
    public class MyRoute extends RouteBuilder {
    
        @Override
        public void configure() throws Exception {
            from("timer:foo")
              .to("log:bar");
        }
    }
  3. 선택 사항: Camel이 유지되도록 기본 스레드를 차단하려면 다음 중 하나를 수행하십시오.

    1. spring-boot-starter-web 종속성을 포함합니다.
    2. 또는 application.properties 또는 application.yml 파일에 camel.springboot.main-run-controller=true 를 추가합니다.

      camel.springboot.* 속성을 사용하여 application.properties 또는 application.yml 파일에서 Camel 애플리케이션을 사용자 지정할 수 있습니다.

  4. 선택 사항: 빈의 ID 이름을 사용하여 사용자 지정 빈을 참조하려면 skopeo/ main/resources/application.properties(또는 application.yml ) 파일에서 옵션을 구성합니다. 다음 예제에서는 xslt 구성 요소가 빈 ID를 사용하여 사용자 지정 빈을 참조하는 방법을 보여줍니다.

    1. myExtensionFactory ID로 사용자 지정 빈을 참조하십시오.

      camel.component.xslt.saxon-extension-functions=myExtensionFactory
    2. 그런 다음 Spring Boot @Bean 주석을 사용하여 사용자 지정 빈을 생성합니다.

      @Bean(name = "myExtensionFactory")
      public ExtensionFunctionDefinition myExtensionFactory() {
          }

      또는 Jackson ObjectMapper의 경우 camel-jackson 데이터 형식의 경우:

      camel.dataformat.json-jackson.object-mapper=myJacksonMapper

7.5. Spring Boot의 Camel 컨텍스트 자동 구성 정보

Camel Spring Boot 자동 구성에서는 CamelContext 인스턴스를 제공하며 SpringCamelContext 를 생성합니다. 또한 해당 컨텍스트의 종료를 초기화하고 수행합니다. 이 Camel 컨텍스트는 camelContext env name 아래의 Spring 애플리케이션 컨텍스트에 등록되며 다른 Spring console처럼 액세스할 수 있습니다. 아래 표시된 대로 camelContext 에 액세스할 수 있습니다.

예제

@Configuration
public class MyAppConfig {

  @Autowired
  CamelContext camelContext;

  @Bean
  MyService myService() {
    return new DefaultMyService(camelContext);
  }

}

7.6. Spring Boot 애플리케이션의 Camel 경로 자동 감지

Camel 자동 구성에서는 Spring 컨텍스트에서 모든 RouteBuilder 인스턴스를 수집하여 CamelContext 에 자동으로 삽입합니다. 이를 통해 Spring Boot Starter를 사용하여 새 Camel 경로를 생성하는 프로세스를 단순화합니다. 다음과 같이 경로를 생성할 수 있습니다.

예제

@Component 주석이 달린 클래스를 classpath에 추가합니다.

@Component
public class MyRouter extends RouteBuilder {

  @Override
  public void configure() throws Exception {
    from("jms:invoices").to("file:/invoices");
  }

}

또는 @Configuration 클래스에 새 경로 RouteBuilder 빈을 생성합니다.

@Configuration
public class MyRouterConfiguration {

  @Bean
  RoutesBuilder myRouter() {
    return new RouteBuilder() {

      @Override
      public void configure() throws Exception {
        from("jms:invoices").to("file:/invoices");
      }

    };
  }
 
}

7.7. Camel Spring Boot 자동 구성의 Camel 속성 구성

Spring Boot 자동 구성은 속성 자리 표시자, OS 환경 변수 또는 Camel 속성이 지원되는 시스템 속성과 같은 Spring Boot 외부 구성에 연결됩니다.

절차

  1. application.properties 파일에서 속성을 정의합니다.  

    route.from = jms:invoices

    또는 Camel의 적절한 시스템 속성을 설정합니다. 예를 들면 다음과 같습니다.

    java -Droute.to=jms:processed.invoices -jar mySpringApp.jar
  2. 구성된 속성을 Camel 경로에서 자리 표시자로 다음과 같이 사용합니다.

    @Component
    public class MyRouter extends RouteBuilder {
    
      @Override
      public void configure() throws Exception {
        from("{{route.from}}").to("{{route.to}}");
      }
    
    }

7.8. 사용자 정의 Camel 컨텍스트 구성

Camel Spring Boot 자동 구성으로 생성된 CamelContext kubeconfig에서 작업을 수행하려면 Spring 컨텍스트에 CamelContextConfiguration 인스턴스를 등록합니다.

절차

  • 아래와 같이 Spring 컨텍스트에서 CamelContextConfiguration 인스턴스를 등록합니다.

    @Configuration
    public class MyAppConfig {
    
      ...
    
      @Bean
      CamelContextConfiguration contextConfiguration() {
        return new CamelContextConfiguration() {
          @Override
          void beforeApplicationStart(CamelContext context) {
            // your custom configuration goes here
          }
        };
      }
    
    }

CamelContextConfigurationbeforeApplicationStart(CamelContext) 방법은 Spring 컨텍스트가 시작되기 전에 호출되므로 이 콜백에 전달되는 CamelContext 인스턴스는 완전히 자동 구성됩니다. CamelContextConfiguration 의 여러 인스턴스를 Spring 컨텍스트에 추가할 수 있으며, 모두 실행됩니다.

7.9. 자동 구성된 CamelContext에서 ScanSetting 비활성화

자동 구성된 CamelContext 에서 ScanSetting을 비활성화하려면 camel.springboot.jmxEnabled 속성을 기본적으로 활성화하므로 사용할 수 있습니다.

절차

  • 다음 속성을 application.properties 파일에 추가하고 false 로 설정합니다.

    camel.springboot.jmxEnabled = false

7.10. Spring 관리 빈에 자동 구성된 소비자 및 생산자 템플릿 삽입

Camel 자동 구성은 사전 구성된 ConsumerTemplateProducerTemplate 인스턴스를 제공합니다. Spring 관리 빈에 삽입할 수 있습니다.

예제

@Component
public class InvoiceProcessor {

  @Autowired
  private ProducerTemplate producerTemplate;

  @Autowired
  private ConsumerTemplate consumerTemplate;
  public void processNextInvoice() {
    Invoice invoice = consumerTemplate.receiveBody("jms:invoices", Invoice.class);
    ...
    producerTemplate.sendBody("netty-http:http://invoicing.com/received/" + invoice.id());
  }

}

기본적으로 소비자 템플릿 및 생산자 템플릿에는 1000으로 설정된 끝점 캐시 크기가 함께 제공됩니다. 다음 Spring 속성을 원하는 캐시 크기로 설정하여 이러한 값을 변경할 수 있습니다. 예를 들면 다음과 같습니다.

camel.springboot.consumerTemplateCacheSize = 100
camel.springboot.producerTemplateCacheSize = 200

7.11. Spring 컨텍스트에서 자동 구성된 TypeConverter 정보

Camel 자동 구성에서는 Spring 컨텍스트에서 typeConverter 라는 TypeConverter 인스턴스를 등록합니다.

예제

@Component
public class InvoiceProcessor {

  @Autowired
  private TypeConverter typeConverter;

  public long parseInvoiceValue(Invoice invoice) {
    String invoiceValue = invoice.grossValue();
    return typeConverter.convertTo(Long.class, invoiceValue);
  }

}

7.12. Spring 유형 변환 API 브리지

Spring은 강력한 유형 변환 API 로 구성됩니다. Spring API는 Camel 유형 변환기 API 와 유사합니다. 두 API 간의 성능 저하로 인해 Camel Spring Boot는 Spring 변환 API에 위임하는 브리지 변환기(SpringTypeConverter)를 자동으로 등록합니다. 즉, Camel이 즉시 사용 가능한 Camel과 비슷한 영향을 미칩니다.

이렇게 하면 다음과 같이 Camel TypeConverter API를 사용하여 Camel 및 Spring 변환기 모두에 액세스할 수 있습니다.

예제

@Component
public class InvoiceProcessor {

  @Autowired
  private TypeConverter typeConverter;

  public UUID parseInvoiceId(Invoice invoice) {
    // Using Spring's StringToUUIDConverter
    UUID id = invoice.typeConverter.convertTo(UUID.class, invoice.getId());
  }

}

여기에서 Spring Boot는 애플리케이션 컨텍스트에서 사용 가능한 Spring의 ConversionService 인스턴스로 변환합니다. ConversionService 인스턴스를 사용할 수 없는 경우 Camel Spring Boot 자동 구성으로 ConversionService 인스턴스가 생성됩니다.

7.13. 유형 변환 기능 비활성화

Camel Spring Boot 유형 변환 기능을 비활성화하려면 camel.springboot.typeConversion 속성을 false 로 설정합니다. 이 속성이 false 로 설정되면 자동 구성이 type converter 인스턴스를 등록하지 않으며 Spring Boot 유형 변환 API로의 위임을 활성화하지 않습니다.

절차

  • Camel Spring Boot 구성 요소의 유형 변환 기능을 비활성화하려면 다음과 같이 camel.springboot.typeConversion 속성을 false 로 설정합니다.

    camel.springboot.typeConversion = false

7.14. 자동 구성을 위해 classpath에 XML 경로 추가

기본적으로 Camel Spring Boot 구성 요소는 auto-detects 및 camel 디렉터리의 classpath에 있는 Camel XML 경로를 포함합니다. 구성 옵션을 사용하여 디렉터리 이름을 구성하거나 이 기능을 비활성화할 수 있습니다.

절차

  • classpath에서 Camel Spring Boot XML 경로를 다음과 같이 구성합니다.

    // turn off
    camel.springboot.xmlRoutes = false
    // scan in the com/foo/routes classpath
    camel.springboot.xmlRoutes = classpath:com/foo/routes/*.xml
    참고

    XML 파일은 CamelContext 요소가 아닌 Camel XML 경로 요소를 정의해야 합니다. 예를 들면 다음과 같습니다.

       <routes xmlns="http://camel.apache.org/schema/spring">
            <route id="test">
                <from uri="timer://trigger"/>
                <transform>
                    <simple>ref:myBean</simple>
                </transform>
                <to uri="log:out"/>
            </route>
        </routes>

Spring XML 파일 사용

<camelContext>와 함께 Spring XML 파일을 사용하려면 Spring XML 파일 또는 application.properties 파일에서 Camel 컨텍스트를 구성할 수 있습니다. Camel 컨텍스트의 이름을 설정하고 스트림 캐싱을 활성화하려면 application.properties 파일에 다음을 추가합니다.

camel.springboot.name = MyCamel
camel.springboot.stream-caching-enabled=true

7.15. 자동 구성을 위한 XML Rest-DSL 경로 추가

Camel Spring Boot 구성 요소는 camel-rest 디렉터리의 classpath에 추가된 Camel Rest-DSL XML 경로를 자동으로 감지하고 포함합니다. 구성 옵션을 사용하여 디렉터리 이름을 구성하거나 이 기능을 비활성화할 수 있습니다.

절차

  • 다음과 같이 classpath에서 Camel Spring Boot Rest-DSL XML 경로를 구성합니다.

    // turn off
    camel.springboot.xmlRests = false
    // scan in the com/foo/routes classpath
    camel.springboot.xmlRests = classpath:com/foo/rests/*.xml
    참고

    Rest-DSL XML 파일은 CamelContext 요소가 아닌 Camel XML REST 요소를 정의해야 합니다. 예를 들면 다음과 같습니다.

       <rests xmlns="http://camel.apache.org/schema/spring">
          <rest>
             <post uri="/persons">
                <to uri="direct:postPersons"/>
             </post>
             <get uri="/persons">
                <to uri="direct:getPersons"/>
             </get>
             <get uri="/persons/{personId}">
                 <to uri="direct:getPersionId"/>
             </get>
             <put uri="/persons/{personId}">
                 <to uri="direct:putPersionId"/>
             </put>
             <delete uri="/persons/{personId}">
                 <to uri="direct:deletePersionId"/>
             </delete>
          </rest>
        </rests>

7.16. Camel Spring Boot로 테스트

Camel이 Spring Boot에서 실행되면 Spring Boot에 @Component 주석이 달린 Camel 및 모든 경로가 자동으로 포함됩니다. Spring Boot로 테스트할 때 @ContextConfiguration 대신 @SpringBootTest 를 사용하여 사용할 구성 클래스를 지정합니다.

다른 RouteBuilder 클래스에 여러 Camel 경로가 있는 경우 Camel Spring Boot 구성 요소는 애플리케이션을 실행할 때 이러한 모든 경로를 자동으로 포함합니다. 따라서 하나의 RouteBuilder 클래스에서만 경로를 테스트하려는 경우 다음 패턴을 사용하여 활성화할 RouteBuilders를 포함하거나 제외할 수 있습니다.

  • Java-routes-include-pattern: 패턴과 일치하는 RouteBuilder 클래스를 포함하는 데 사용됩니다.
  • Java-routes-exclude-pattern: 패턴과 일치하는 RouteBuilder 클래스를 제외하는 데 사용됩니다. exclude는 include보다 우선합니다.

절차

  1. 다음과 같이 단위 테스트 클래스에 포함된 패턴을 @SpringBootTest 주석의 속성으로 지정합니다.

    @RunWith(CamelSpringBootRunner.class)
    @SpringBootTest(classes = {MyApplication.class);
       properties = {"camel.springboot.java-routes-include-pattern=**/Foo*"})
    public class FooTest {

    ECDHE Test 클래스에서 포함 패턴은 **/ECDHE* 이며, 해당 패턴은 10.0.0.1 스타일 패턴을 나타냅니다. 여기서 패턴은 선행 패키지 이름과 일치하는 이중 별표로 시작됩니다. /foo* 는 클래스 이름이 ECDHE(예: ECDHERoute)로 시작해야 함을 나타냅니다.

  2. 다음 maven 명령을 사용하여 테스트를 실행합니다.

    mvn test -Dtest=FooTest

8장. OpenShift에서 Fuse에서 Spring Boot 2에 대한 REST 브리지 빠른 시작 버전 실행

이 빠른 시작에서는 Camel의 REST DSL을 사용하여 백엔드 CHAP API를 노출하는 방법을 설명합니다. 간단한 camel 경로는 REST 호출을 레거시 CHAP 서비스에 연결할 수 있습니다. 보안은 모두 RH SSO에서 지원하는 REST 엔드포인트 및 CHAP 끝점 모두에 적용됩니다. OAuth 및 OpenID Connect를 통해 보호되는 프런트 엔드 REST API와 클라이언트는 Resource Owner Password Credentials OAuth2 모드를 사용하여 RH SSO에서 JWT 액세스 토큰을 가져오고 이 토큰을 사용하여 REST 엔드포인트에 액세스합니다.

Prerequsites

  • OCP 4.1 이상을 설치 및 구성했습니다.
  • RH SSO 7.4 이상을 설치했습니다.
  • 3Scale 2.8 이상 버전을 설치했습니다.
  • registry.redhat.io 에 대한 인증이 구성되어 있습니다. 자세한 내용은 Red Hat Container Registry 인증 구성을 참조하십시오.

절차

다음 섹션에서는 OpenShift에서 Fuse에서 gRPC를 실행하고 REST 브리지 빠른 시작에 배포하는 방법을 설명합니다.

  1. OpenShift 서버를 시작합니다. 이 빠른 시작의 전제 조건으로 RH SSO 이미지(2 pod) 및 3Scale 이미지(15개)를 설치해야 하므로 옵션 --memory 8GB --cpus 4 를 사용하여 강력한 시스템에서 OpenShift 서버를 시작해야 합니다. 또한 만료 시간과 함께 보안 토큰을 발행해야 하므로 시간대 옵션도 추가해야 합니다. Openshift 클러스터가 로컬 시스템과 동일한 시간대를 사용하는지 확인합니다(기본적으로 UTC 시간대 사용).
  2. 사용자 developercluster-admin 역할을 추가합니다.

    $ oc login -u system:admin
    $ oc adm policy add-cluster-role-to-user cluster-admin developer
    $ oc login -u developer
    $ oc project openshift

    이 빠른 시작은 openshift 네임스페이스(관련 템플릿의 기본 구성 요구 사항)와 RH SSO 이미지에 배포되므로 사용자 개발자에게 cluster-admin 역할을 추가해야 합니다.

  3. 시크릿을 생성하여 serviceaccounts 에 연결합니다.

    $ oc create secret docker-registry camel-bridge --docker-server=registry.redhat.io \
      --docker-username=USERNAME \
      --docker-password=PASSWORD \
      --docker-email=EMAIL_ADDRESS
    $ oc secrets link default camel-bridge --for=pull
    $ oc secrets link builder camel-bridge
  4. RH SSO 이미지 스트림을 추가하고 템플릿 sso74-x509-postgresql-persistent 를 사용하여 RH SSO를 설치합니다.

    $ for resource in sso74-image-stream.json \
       sso74-https.json \
       sso74-postgresql.json \
       sso74-postgresql-persistent.json \
       sso74-x509-https.json \
       sso74-x509-postgresql-persistent.json
     do
       oc create -f \
       https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/sso74-dev/templates/${resource}
     done
    
    $ oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default
    
    $ oc new-app --template=sso74-x509-postgresql-persistent

    openshift 네임스페이스에서 RH SSO 이미지를 사용할 수 있는지 확인한 다음 템플릿 sso74-x509-postgresql-persistent 를 사용하여 RH SSO를 설치합니다. 이 템플릿은 RH SSO 구성을 영구적으로 저장할 수 있으므로 Openshift 서버를 다시 시작한 후에도 구성이 유지됩니다.

  5. RH SSO 이미지가 서버에 설치되면 다음과 같이 콘솔에 출력이 표시됩니다.

    A new persistent RH-SSO service (using PostgreSQL) has been created in your project. The admin username/password for accessing the master realm via the RH-SSO console is tprYtXP1/nEjf7fojv11FmhJ5eaqadoh0SI2gvlls. The username/password for accessing the PostgreSQL database "root" is userqxe/XNYRjL74CrJEWW7HiSYEdH5FMKVSDytx. The HTTPS keystore used for serving secure content, the JGroups keystore used for securing JGroups communications, and server truststore used for securing RH-SSO requests were automatically created via OpenShift's service serving x509 certificate secrets.
    
         * With parameters:
            * Application Name=sso
            * Custom RH-SSO Server Hostname=
            * JGroups Cluster Password=1whGRnsAWu162u0e4P6jNpLn5ysJLWjg # generated
            * Database JNDI Name=java:jboss/datasources/KeycloakDS
            * Database Name=root
            * Datasource Minimum Pool Size=
            * Datasource Maximum Pool Size=
            * Datasource Transaction Isolation=
            * PostgreSQL Maximum number of connections=
            * PostgreSQL Shared Buffers=
            * Database Username=userqxe # generated
            * Database Password=XNYRjL74CrJEWW7HiSYEdH5FMKVSDytx # generated
            * Database Volume Capacity=1Gi
            * ImageStream Namespace=openshift
            * RH-SSO Administrator Username=tprYtXP1 # generated
            * RH-SSO Administrator Password=nEjf7fojv11FmhJ5eaqadoh0SI2gvlls # generated
            * RH-SSO Realm=
            * RH-SSO Service Username=
            * RH-SSO Service Password=
            * PostgreSQL Image Stream Tag=10
            * Container Memory Limit=1Gi
  6. RH SSO 관리 콘솔에 액세스하는 데 사용되는 Username/Password를 기록해 두십시오. 예를 들면 다음과 같습니다.

     * RH-SSO Administrator Username=tprYtXP1 # generated
     * RH-SSO Administrator Password=nEjf7fojv11FmhJ5eaqadoh0SI2gvlls # generated
  7. 3scale 프로젝트에 3scale 템플릿을 설치합니다.

    $ oc new-project 3scale
    $ oc create secret docker-registry threescale-registry-auth --docker-server=registry.redhat.io --docker-server=registry.redhat.io \
      --docker-username=USERNAME \
      --docker-password=PASSWORD \
      --docker-email=EMAIL_ADDRESS
    $ oc secrets link default threescale-registry-auth --for=pull
    $ oc secrets link builder threescale-registry-auth
    $ oc new-app --param WILDCARD_DOMAIN="OPENSHIFT_IP_ADDR.nip.io" -f https://raw.githubusercontent.com/3scale/3scale-amp-openshift-templates/2.8.0.GA/amp/amp-eval-tech-preview.yml

    openshift에 3scale 설치는 15개의 Pod를 시작하므로 3scale에 대한 새 특정 프로젝트를 생성해야 합니다. 3scale의 새로운 3scale-registry-auth (이 이름을 사용하여 3scale 템플릿으로 작성된 보안) 시크릿을 생성해야 합니다. camel-bridge에서 USERNAME/PASSWORD를 재사용할 수 있습니다. 여기서는 로컬 머신/laptop에서 쉽게 실행할 수 있도록 하드웨어 리소스를 명시적으로 지정하지 않기 때문에 이 템플릿을 의도적으로 사용할 수 있습니다.

  8. 3scale 템플릿이 Openshift에 성공적으로 설치되면 다음과 같이 콘솔에 출력이 표시됩니다.

    3scale API Management
         ---------
         3scale API Management main system (Evaluation)
    
         Login on https://3scale-admin.192.168.64.33.nip.io as admin/b6t784nt
    
         * With parameters:
            * AMP_RELEASE=2.8
            * APP_LABEL=3scale-api-management
            * TENANT_NAME=3scale
            * RWX_STORAGE_CLASS=null
            * AMP_BACKEND_IMAGE=registry.redhat.io/3scale-amp2/backend-rhel7:3scale2.8
            * AMP_ZYNC_IMAGE=registry.redhat.io/3scale-amp2/zync-rhel7:3scale2.8
            * AMP_APICAST_IMAGE=registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.8
            * AMP_SYSTEM_IMAGE=registry.redhat.io/3scale-amp2/system-rhel7:3scale2.8
            * ZYNC_DATABASE_IMAGE=registry.redhat.io/rhscl/postgresql-10-rhel7
            * MEMCACHED_IMAGE=registry.redhat.io/3scale-amp2/memcached-rhel7:3scale2.8
            * IMAGESTREAM_TAG_IMPORT_INSECURE=false
            * SYSTEM_DATABASE_IMAGE=registry.redhat.io/rhscl/mysql-57-rhel7:5.7
            * REDIS_IMAGE=registry.redhat.io/rhscl/redis-32-rhel7:3.2
            * System MySQL User=mysql
            * System MySQL Password=mrscfh4h # generated
            * System MySQL Database Name=system
            * System MySQL Root password.=xbi0ch3i # generated
            * WILDCARD_DOMAIN=192.168.64.33.nip.io
            * SYSTEM_BACKEND_USERNAME=3scale_api_user
            * SYSTEM_BACKEND_PASSWORD=kraji167 # generated
            * SYSTEM_BACKEND_SHARED_SECRET=8af5m6gb # generated
            * SYSTEM_APP_SECRET_KEY_BASE=726e63427173e58cbb68a63bdc60c7315565d6acd037caedeeb0050ecc0e6e41c3c7ec4aba01c17d8d8b7b7e3a28d6166d351a6238608bb84aa5d5b2dc02ae60 # generated
            * ADMIN_PASSWORD=b6t784nt # generated
            * ADMIN_USERNAME=admin
            * ADMIN_EMAIL=
            * ADMIN_ACCESS_TOKEN=k055jof4itblvwwn # generated
            * MASTER_NAME=master
            * MASTER_USER=master
            * MASTER_PASSWORD=buikudum # generated
            * MASTER_ACCESS_TOKEN=xa7wkt16 # generated
            * RECAPTCHA_PUBLIC_KEY=
            * RECAPTCHA_PRIVATE_KEY=
            * SYSTEM_REDIS_URL=redis://system-redis:6379/1
            * SYSTEM_MESSAGE_BUS_REDIS_URL=
            * SYSTEM_REDIS_NAMESPACE=
            * SYSTEM_MESSAGE_BUS_REDIS_NAMESPACE=
            * Zync Database PostgreSQL Connection Password=efyJdRccBbYcWtWl # generated
            * ZYNC_SECRET_KEY_BASE=dcmNGWtrjCReuJlQ # generated
            * ZYNC_AUTHENTICATION_TOKEN=3FKMAije3V3RWQQ8 # generated
            * APICAST_ACCESS_TOKEN=2ql8txu4 # generated
            * APICAST_MANAGEMENT_API=status
            * APICAST_OPENSSL_VERIFY=false
            * APICAST_RESPONSE_CODES=true
            * APICAST_REGISTRY_URL=http://apicast-staging:8090/policies
  9. 3scale 관리 콘솔에 액세스할 수 있는 Username/Password를 기록해 둡니다.

            * ADMIN_PASSWORD=b6t784nt # generated
            * ADMIN_USERNAME=admin
  10. RH SSO 구성.

    1. RH SSO 설치 후 콘솔에 표시된 사용자 이름/암호를 사용하여 https://sso-openshift.OPENSHIFT_IP_ADDR.nip.io/auth 에서 RH SSO 관리 콘솔에 로그인합니다.
    2. 페이지의 왼쪽 상단에 있는 Add ECDHE 버튼을 클릭합니다.
    3. Add CloudEvent 페이지에서 Import Select file 버튼을 선택합니다.
    4. 이 예제에 대해 사전 정의된 필수 영역/ 클라이언트/사용자/역할을 가져올 디렉터리에서 ./src/main/resources/keycloak-config/realm -export-new.json 을 선택합니다.
  11. 3Scale API Gateway를 구성합니다.

    1. 3Scale 설치 후 https://3scale-admin.OPENSHIFT_IP_ADDR.nip.io/p/admin/dashboard 에서 3Scale 관리 콘솔에 로그인합니다.
    2. 새 제품을 생성할 때 수동으로 정의를 선택하고 NameSystem name 에 모두 camel-security-bridge 를 사용합니다.
    3. 새 백엔드를 생성할 때 이름 및 시스템 이름 모두에 camel-security-bridge 를 사용하고 개인 기본 URLhttp://spring-boot-camel-soap-rest-bridge-openshift.OPENSHIFT_IP_ADDR.nip.io/ 이어야 합니다.
    4. 새로 생성된 제품에 새로 생성된 백엔드를 추가합니다.
    5. 매핑 규칙 Verb:ECDHE Pattern:/ 를 추가합니다.
    6. 애플리케이션 계획을 생성할 때 NameSystem 이름 모두에 camel-security-bridge 를 사용합니다.
    7. 애플리케이션을 생성할 때 새로 생성된 camel-security-bridge 애플리케이션 계획을 선택합니다. 애플리케이션을 생성한 후 API 자격 증명을 기록해 둡니다. 이러한 인증 정보를 사용하여 3scale 게이트웨이에 액세스합니다. Eample의 경우

          User Key 	bdfb53fe9b426fbf21428fd116035798
    8. 새로 생성된 camel-security-bridge 프로젝트를 편집하고 대시보드의 camel-security-bridge 에서 게시합니다.
    9. Integration > Settings 으로 이동합니다. 인증 정보 위치로 HTTP 헤더 로 을 선택합니다.
    10. 대시보드의 camel-security-bridge 에서 Integration > Configuration으로 이동하여 staging APIcast 및 Production APIcast 를 모두 승격합니다.
  12. 추출된 빠른 시작 애플리케이션이 포함된 디렉터리로 이동합니다(예: my_openshift/spring-boot-camel-soap-rest-bridge).

    $ cd my_openshift/spring-boot-camel-soap-rest-bridge
  13. 프로젝트를 빌드하고 OpenShift 클러스터에 배포합니다.

    $ mvn clean oc:deploy -Popenshift -DJAVA_OPTIONS="-Dsso.server=https://sso-openshift.OPENSHIFT_IP_ADDR.nip.io -Dweather.service.host=${your local ip}"

    openshift에서 두 가지 속성을 camel-soap-rest-bridge 이미지에 전달해야 합니다. 하나는 openshift의 RH SSO 서버 주소이며 이는 https://sso-openshift.OPENSHIFT_IP_ADDR.nip.io 입니다. 또 다른 하나는 백엔드 soap 서버입니다. 이 빠른 시작에서는 로컬 시스템에서 backend soap 서버를 실행하므로 시스템의 로컬 IP 주소를 -Dw lights.service.host로 전달합니다. (이 주소는 localhost 또는 127.0.0.1 이외의 IP 주소여야 합니다.)

  14. 브라우저에서 OpenShift 콘솔에서 openshift 프로젝트로 이동합니다. spring-boot-camel-soap-rest-bridge 의 Pod가 시작되었는지 확인할 때까지 기다립니다.
  15. 프로젝트의 개요 페이지에서 spring-boot-camel-soap-rest-bridge 애플리케이션의 세부 정보 페이지 배포로 이동합니다. https://OPENSHIFT_IP_ADDR:8443/console/project/openshift/browse/pods/spring-boot-camel-soap-rest-bridge-NUMBER_OF_DEPLOYMENT?tab=details.
  16. Camel의 로그를 보려면 로그 탭으로 전환합니다.
  17. OpenApi API에 액세스합니다.

이 예제에서는 context-path camelcxf/openapi를 사용하여 openapi를 사용하여 서비스에 대한 API 문서를 제공합니다. 웹 브라우저 http://spring-boot-camel-soap-rest-bridge-openshift.OPENSHIFT_IP_ADDR.nip.io/camelcxf/openapi/openapi.jsonn 에서 API 문서에 액세스할 수 있습니다.

9장. XA 트랜잭션을 사용하여 Spring Boot에서 Camel 서비스 실행

Spring Boot Camel XA 트랜잭션 빠른 시작에서는 두 개의 외부 트랜잭션 리소스인 JMS 리소스(A-MQ) 및 데이터베이스(PostgreSQL)에서 XA 트랜잭션을 지원하는 Spring-Boot에서 Camel 서비스를 실행하는 방법을 보여줍니다. 이러한 외부 리소스는 OpenShift에서 제공하며 이 빠른 시작을 실행하기 전에 시작해야 합니다.

9.1. StatefulSet 리소스

이 빠른 시작에서는 OpenShift StatefulSet 리소스를 사용하여 트랜잭션 관리자의 고유성을 보장하고 트랜잭션 로그를 저장하기 위해 PersistentVolume이 필요합니다. 애플리케이션은 StatefulSet 리소스에서 스케일링을 지원합니다. 각 인스턴스에는 자체 프로세스 복구 관리자가 있습니다. 특수 컨트롤러는 애플리케이션이 축소될 때, 종료된 모든 인스턴스이며 보류 중인 트랜잭션을 종료하지 않고 모든 작업을 올바르게 완료할 수 있도록 합니다. 복구 관리자가 종료하기 전에 보류 중인 모든 작업을 플러시할 수 없는 경우 스케일 다운 작업이 컨트롤러에서 롤백됩니다. 이 빠른 시작에서는 Spring Boot Narayana 복구 컨트롤러를 사용합니다.

9.2. Spring Boot Narayana 복구 컨트롤러

Spring Boot Narayana 복구 컨트롤러를 사용하면 종료 전에 보류 중인 트랜잭션을 정리하여 StatefulSet의 축소 다운 단계를 정상적으로 처리할 수 있습니다. 축소 작업이 실행되고 종료 후 Pod가 정리되지 않으면 이전 복제본 수가 복원되므로 축소 작업이 효과적으로 취소됩니다.

StatefulSet의 모든 Pod에는 StatefulSet에 속하는 각 Pod의 종료 상태를 저장하는 데 사용되는 공유 볼륨에 액세스해야 합니다. StatefulSet의 pod-0은 주기적으로 상태를 확인하고 StatefulSet이 일치하지 않는 경우 올바른 크기로 스케일링합니다.

복구 컨트롤러가 작동하려면 현재 네임스페이스에 대한 편집 권한이 필요합니다(OpenShift에 게시된 리소스 세트에 역할 바인딩이 포함되어 있음). 복구 컨트롤러는 CLUSTER_RECOVERY_ENABLED 환경 변수를 사용하여 비활성화할 수 있습니다. 이 경우 서비스 계정에는 특별한 권한이 필요하지 않지만 축소 작업은 종료된 Pod에서 보류 중인 트랜잭션을 통지 없이 종료할 수 있습니다.

9.3. Spring Boot Narayana 복구 컨트롤러 구성

다음 예제에서는 복구 컨트롤러를 사용하여 OpenShift에서 작동하도록 Narayana를 구성하는 방법을 보여줍니다.

절차

  1. 샘플 application.properties 파일입니다. Kubernetes yaml 설명자에서 다음 옵션을 교체합니다.

    # Cluster
    cluster.nodename=1
    cluster.base-dir=./target/tx
    
    # Transaction Data
    spring.jta.transaction-manager-id=${cluster.nodename}
    spring.jta.log-dir=${cluster.base-dir}/store/${cluster.nodename}
    
    # Narayana recovery settings
    snowdrop.narayana.openshift.recovery.enabled=true
    snowdrop.narayana.openshift.recovery.current-pod-name=${cluster.nodename}
    # You must enable resource filtering in order to inject the Maven artifactId
    snowdrop.narayana.openshift.recovery.statefulset=${project.artifactId}
    snowdrop.narayana.openshift.recovery.status-dir=${cluster.base-dir}/status
  2. 종료와 관련된 거래 및 정보를 모두 저장하려면 공유 볼륨이 필요합니다. 다음과 같이 StatefulSet yaml 설명자에 마운트할 수 있습니다.

    apiVersion: apps/v1
    kind: StatefulSet
    #...
    spec:
    #...
      template:
    #...
        spec:
          containers:
          - env:
            - name: CLUSTER_BASE_DIR
              value: /var/transaction/data
              # Override CLUSTER_NODENAME with Kubernetes Downward API (to use `pod-0`, `pod-1` etc. as tx manager id)
            - name: CLUSTER_NODENAME
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.name
    #...
            volumeMounts:
            - mountPath: /var/transaction/data
              name: the-name-of-the-shared-volume
    #...

Camel Extension for Spring Boot Narayana 8080 Controller

Camel이 Spring Boot 애플리케이션 컨텍스트에서 있는 경우 보류 중인 모든 트랜잭션을 플러시하기 전에 Camel 컨텍스트가 자동으로 중지됩니다.

9.4. OpenShift에서 Camel Spring Boot XA 빠른 시작 실행

다음 절차에서는 실행 중인 단일 노드 OpenShift 클러스터에서 빠른 시작을 실행하는 방법을 설명합니다.

절차

  1. Camel Spring Boot XA 프로젝트를 다운로드합니다.

    git clone --branch spring-boot-camel-xa-7.11.1.fuse-sb2-7_11_1-00022-redhat-00002 https://github.com/jboss-fuse/spring-boot-camel-xa
  2. spring-boot-camel-xa 디렉터리로 이동하여 다음 명령을 실행합니다.

    mvn clean install
  3. OpenShift 서버에 로그인합니다.

    oc login -u developer -p developer
  4. test 라는 새 프로젝트 네임스페이스를 생성합니다(아직 존재하지 않는다고 가정).

    oc new-project test

    test 프로젝트 네임스페이스가 이미 있는 경우 해당 네임스페이스로 전환합니다.

    oc project test
  5. 종속 항목을 설치합니다.

    • 사용자 이름으로 postgresql 를 설치하고 암호를 Thepassword1! 로 사용합니다.

      oc new-app --param=POSTGRESQL_USER=theuser --param=POSTGRESQL_PASSWORD='Thepassword1!' --env=POSTGRESQL_MAX_PREPARED_TRANSACTIONS=100 --template=postgresql-persistent
    • 사용자 이름으로 사용자 이름 및 암호 Thepassword1! 사용하여 A-MQ 브로커를 설치합니다.

      oc new-app --param=MQ_USERNAME=theuser --param=MQ_PASSWORD='Thepassword1!' --template=amq63-persistent
  6. 트랜잭션 로그에 대한 영구 볼륨 클레임을 만듭니다.

    oc create -f persistent-volume-claim.yml
  7. 빠른 시작을 빌드하고 배포합니다.

    mvn oc:deploy -Popenshift
  8. 원하는 복제본 수로 확장합니다.

    oc scale statefulset spring-boot-camel-xa --replicas 3

    참고: 포드 이름은 트랜잭션 관리자 ID(spring.jta.ECDHE-manager-id 속성)로 사용됩니다. 현재 구현에서는 트랜잭션 관리자 ID의 길이도 제한합니다. 다음 사항에 유의하십시오.

    • StatefulSet의 이름은 트랜잭션 시스템의 식별자이므로 변경할 수 없습니다.
    • 해당 Pod 이름의 길이가 모두 23자보다 작거나 같도록 StatefulSet의 이름을 지정해야 합니다. 포드 이름은 <statefulset-name>-0, <statefulset-name>-1 등을 사용하여 OpenShift에서 생성합니다. Narayana는 동일한 ID의 복구 관리자가 여러 개인 복구 관리자를 사용하지 않기 위해 최선을 다하고 있으므로 Pod 이름이 제한보다 길면 마지막 23 바이트가 트랜잭션 관리자 id로 사용됩니다 (-와 같은 일부 문자를 제거).
  9. 빠른 시작이 실행되면 다음 명령을 사용하여 기본 서비스 URL을 가져옵니다.

    NARAYANA_HOST=$(oc get route spring-boot-camel-xa -o jsonpath={.spec.host})

9.5. 성공적인 XA 트랜잭션 테스트

다음 워크플로는 성공적인 XA 트랜잭션을 테스트하는 방법을 보여줍니다.

절차

  1. audit_log 테이블에서 메시지 목록을 가져옵니다.

    curl -w "\n" http://$NARAYANA_HOST/api/
  2. 목록은 처음에 비어 있습니다. 이제 첫 번째 요소를 추가할 수 있습니다.

    curl -w "\n" -X POST http://$NARAYANA_HOST/api/?entry=hello

    잠시 기다린 후 새 목록을 가져옵니다.

    curl -w "\n" http://$NARAYANA_HOST/api/
  3. 새 목록에는 hellohello-ok 라는 두 개의 메시지가 포함되어 있습니다. hello-ok 는 메시지가 발신 대기열로 전송된 다음 기록되었는지 확인합니다. 여러 메시지를 추가하고 로그를 볼 수 있습니다.

9.6. 실패한 XA 트랜잭션 테스트

다음 워크플로는 실패한 XA 트랜잭션을 테스트하는 방법을 보여줍니다.

절차

  1. fail 라는 메시지를 보냅니다.

    curl -w "\n" -X POST http://$NARAYANA_HOST/api/?entry=fail
  2. 잠시 기다린 후 새 목록을 가져옵니다.

    curl -w "\n" http://$NARAYANA_HOST/api/
  3. 이 메시지는 경로 끝에 예외가 생성되므로 트랜잭션이 항상 롤백됩니다. audit_log 테이블에 있는 메시지 추적을 찾을 수 없습니다.

10장. A-MQ 브로커와 Camel 애플리케이션 통합

이 튜토리얼에서는 A-MQ 이미지를 사용하여 빠른 시작을 배포하는 방법을 설명합니다.

10.1. Spring Boot Camel A-MQ 빠른 시작 빌드 및 배포

이 빠른 시작에서는 OpenShift에서 Fuse를 사용하여 Spring Boot 애플리케이션을 AMQ Broker에 연결하고 두 Camel 경로 간에 JMS 메시징을 사용하는 방법을 보여줍니다.

사전 요구 사항

절차

  1. OpenShift 서버에 개발자로 로그인합니다.

    oc login -u developer -p developer
  2. 빠른 시작용 새 프로젝트를 만듭니다. 예를 들면 다음과 같습니다.

    oc new-project quickstart
  3. Maven archetype을 사용하여 빠른 시작 프로젝트를 검색합니다.

    mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate -DarchetypeCatalog=https://maven.repository.redhat.com/ga/io/fabric8/archetypes/archetypes-catalog/2.2.0.fuse-sb2-790047-redhat-00004/archetypes-catalog-2.2.0.fuse-sb2-790047-redhat-00004-archetype-catalog.xml -DarchetypeGroupId=org.jboss.fuse.fis.archetypes -DarchetypeArtifactId=spring-boot-camel-amq-archetype -DarchetypeVersion=2.2.0.fuse-sb2-790047-redhat-00004
  4. 빠른 시작 디렉터리 fuse711-spring-boot-camel-amq 로 이동합니다.

    cd fuse711-spring-boot-camel-amq
  5. 다음 명령을 실행하여 AMQ Broker에 구성 파일을 적용합니다. 이러한 구성 파일은 admin 권한으로 AMQ Broker 사용자와 큐를 생성합니다.

    oc login -u admin -p admin
    
    oc apply -f src/main/resources/k8s
  6. 애플리케이션의 ConfigMap을 생성합니다. 예를 들면 다음과 같습니다.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: spring-boot-camel-amq-config
      namespace: quickstarts
    data:
      service.host: 'fuse-broker-amqps-0-svc'
      service.port.amqp: '5672'
      service.port.amqps: '5671'
  7. mvn 명령을 실행하여 3단계의 ImageStream을 사용하여 OpenShift 서버에 빠른 시작을 배포합니다.

    mvn oc:deploy -Popenshift -Djkube.generator.fromMode=istag -Djkube.generator.from=openshift/fuse-java-openshift:1.9
  8. 빠른 시작이 성공적으로 실행되고 있는지 확인하려면 다음을 수행하십시오.

    1. 브라우저의 OpenShift 웹 콘솔로 이동합니다(https://OPENSHIFT_IP_ADDR, OPENSHIFT_IP_ADDR을 클러스터의 IP 주소로 교체) 자격 증명으로 로그인합니다(예: 사용자 이름 개발자 및 암호, developer).
    2. 왼쪽 패널에서 을 확장한 다음 상태를 클릭하여 openshift 프로젝트의 프로젝트 상태 페이지를 확인합니다.
    3. fuse711-spring-boot-amq 를 클릭하여 빠른 시작에 대한 개요 정보 페이지를 확인합니다.
    4. 왼쪽 패널에서 워크로드 를 확장합니다.
    5. Pod 를 클릭한 다음 fuse711-spring-boot-camel-amq-xxxxx 를 클릭합니다. 빠른 시작에 대한 Pod 세부 정보가 표시됩니다.
    6. 로그를 클릭하여 애플리케이션의 로그를 확인합니다.

      출력은 메시지가 성공적으로 전송되었음을 보여줍니다.

      10:17:59.825 [Camel (camel) thread #10 - timer://order] INFO  generate-order-route - Generating order order1379.xml
      10:17:59.829 [Camel (camel) thread #8 - JmsConsumer[incomingOrders]] INFO  jms-cbr-route - Sending order order1379.xml to the UK
      10:17:59.829 [Camel (camel) thread #8 - JmsConsumer[incomingOrders]] INFO  jms-cbr-route - Done processing order1379.xml
      10:18:02.825 [Camel (camel) thread #10 - timer://order] INFO  generate-order-route - Generating order order1380.xml
      10:18:02.829 [Camel (camel) thread #7 - JmsConsumer[incomingOrders]] INFO  jms-cbr-route - Sending order order1380.xml to another country
      10:18:02.829 [Camel (camel) thread #7 - JmsConsumer[incomingOrders]] INFO jms-cbr-route - Done processing order1380.xml
  9. 웹 인터페이스에서 경로를 보려면 Java 콘솔 열기 를 클릭하고 AMQ 대기열에서 메시지를 확인합니다.

11장. Kubernetes와 Spring Boot 통합

현재 Spring Cloud Kubernetes 플러그인을 사용하면 Spring Boot 및 Kubernetes의 다음 기능을 통합할 수 있습니다.

11.1. Spring Boot 외부 구성

Spring Boot에서 외부화된 구성은 외부 소스의 구성 값을 Java 코드에 삽입할 수 있는 메커니즘입니다. Java 코드에서는 일반적으로 @Value 주석(단일 필드에 삽입) 또는 @ConfigurationProperties 주석으로 주석을 달아 주입이 활성화됩니다(Java kubeconfig 클래스의 여러 속성에 삽입하기 위해).

구성 데이터는 다양한 소스(또는 속성소스)에서 가져올 수 있습니다. 특히 구성 속성은 프로젝트의 application.properties 파일(또는 원하는 경우 application.yaml 파일)에 설정되는 경우가 많습니다.

11.1.1. Kubernetes ConfigMap

Kubernetes ConfigMap 은 배포된 애플리케이션에 구성 데이터를 제공할 수 있는 메커니즘입니다. 일반적으로 ConfigMap 오브젝트는 YAML 파일에 정의되며 Kubernetes 클러스터에 업로드되므로 배포된 애플리케이션에 구성 데이터를 사용할 수 있습니다.

11.1.2. Kubernetes Secrets

Kubernetes 시크릿 은 배포된 애플리케이션에 중요한 데이터(암호, 인증서 등)를 제공하는 메커니즘입니다.

11.1.3. Spring Cloud Kubernetes 플러그인

Spring Cloud Kubernetes 플러그인은 Kubernetes와 Spring Boot 간의 통합을 구현합니다. 일반적으로 Kubernetes API를 사용하여 ConfigMap에서 구성 데이터에 액세스할 수 있습니다. 그러나 Kubernetes ConfigMap이 Spring Boot 외부 구성 메커니즘과 직접 통합되므로 Kubernetes ConfigMap이 Spring Boot 구성에 대한 대체 속성 소스 역할을 하는 것이 훨씬 편리합니다. 기본적으로 Spring Cloud Kubernetes 플러그인에서 제공하는 것입니다.

11.1.4. Kubernetes 통합을 사용하여 Spring Boot 활성화

pom.xml 파일에 Maven 종속성으로 추가하여 Kubernetes 통합을 활성화할 수 있습니다.

절차

  1. Spring Boot Maven 프로젝트의 pom.xml 파일에 다음 Maven 종속성을 추가하여 Kubernetes 통합을 활성화합니다.

    <project ...>
      ...
      <dependencies>
        ...
        <dependency>
          <groupId>org.springframework.cloud</groupId>
          <artifactId>spring-cloud-starter-kubernetes-config</artifactId>
        </dependency>
        ...
      </dependencies>
      ...
    </project>
  2. 통합을 완료하려면,

    • Java 소스 코드에 몇 가지 주석을 추가합니다.
    • Kubernetes ConfigMap 오브젝트 생성
    • 애플리케이션이 ConfigMap 오브젝트를 읽을 수 있도록 OpenShift 서비스 계정 권한을 수정합니다.

11.2. ConfigMap 속성 소스에 대한 튜토리얼 실행

다음 튜토리얼에서는 Kubernetes Secrets 및 ConfigMap 설정을 실험할 수 있습니다. Kubernetes 통합 활성화에 설명된 대로 Spring Cloud Kubernetes 플러그인을 활성화하여 Kubernetes 구성 오브젝트를 Spring Boot Externalized Configuration과 통합합니다.

11.2.1. Spring Boot Camel Config 빠른 시작 실행

다음 튜토리얼에서는 Kubernetes Secrets 및 ConfigMaps를 설정할 수 있는 spring-boot-camel-config-archetype Maven archetype을 기반으로 합니다.

절차

  1. 새 쉘 프롬프트를 열고 다음 Maven 명령을 입력하여 간단한 Camel Spring Boot 프로젝트를 생성합니다.

    mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate \
      -DarchetypeCatalog=https://maven.repository.redhat.com/ga/io/fabric8/archetypes/archetypes-catalog/2.2.0.fuse-sb2-7_11_1-00018-redhat-00002/archetypes-catalog-2.2.0.fuse-sb2-7_11_1-00018-redhat-00002-archetype-catalog.xml \
      -DarchetypeGroupId=org.jboss.fuse.fis.archetypes \
      -DarchetypeArtifactId=spring-boot-camel-config-archetype \
      -DarchetypeVersion=2.2.0.fuse-sb2-7_11_1-00018-redhat-00002

    archetype 플러그인이 대화형 모드로 전환하여 나머지 필드를 입력하라는 메시지를 표시합니다.

    Define value for property 'groupId': : org.example.fis
    Define value for property 'artifactId': : fuse711-configmap
    Define value for property 'version':  1.0-SNAPSHOT: :
    Define value for property 'package':  org.example.fis: :
    Confirm properties configuration:
    groupId: org.example.fis
    artifactId: fuse711-configmap
    version: 1.0-SNAPSHOT
    package: org.example.fis
    Y: : Y

    메시지가 표시되면 groupId 값으로 org.example.fis 를 입력하고 artifactId 값에 fuse711-configmap 을 입력합니다. 나머지 필드에는 기본값을 수락합니다.

  2. OpenShift에 로그인하고 애플리케이션을 배포할 OpenShift 프로젝트로 전환합니다. 예를 들어 developer 사용자로 로그인하여 openshift 프로젝트에 배포하려면 다음 명령을 입력합니다.

    oc login -u developer -p developer
    oc project openshift
  3. 명령줄에서 새 fuse711-configmap 프로젝트의 디렉터리로 변경하고 이 애플리케이션의 Secret 오브젝트를 생성합니다.

    cd fuse711-configmap
    oc create -f sample-secret.yml
    참고

    애플리케이션을 배포하기 전에 Secret 오브젝트를 생성해야 합니다. 그러지 않으면 배포된 컨테이너가 시크릿을 사용할 수 있을 때까지 대기 상태가 됩니다. 이후에 시크릿을 생성하면 컨테이너가 대기 상태가 해제됩니다. Secret Object 설정 방법에 대한 자세한 내용은 시크릿 설정을 참조하십시오.

  4. 빠른 시작 애플리케이션을 빌드하고 배포합니다. fuse711-configmap 프로젝트의 최상위 수준에서 다음을 입력합니다.

    mvn oc:deploy -Popenshift
  5. 다음과 같이 애플리케이션 로그를 확인합니다.

    1. 브라우저의 OpenShift 웹 콘솔로 이동합니다(https://OPENSHIFT_IP_ADDR, OPENSHIFT_IP_ADDR 을 클러스터의 IP 주소로 교체) 자격 증명으로 로그인합니다(예: 사용자 이름 개발자 및 암호, developer).
    2. 왼쪽 패널에서 을 확장합니다. 상태를 클릭하여 프로젝트 상태 페이지를 확인합니다. 선택한 네임스페이스(예: openshift)의 기존 애플리케이션이 모두 표시됩니다.
    3. fuse711-configmap 을 클릭하여 빠른 시작에 대한 개요 정보 페이지를 확인합니다.
    4. 왼쪽 패널에서 워크로드 를 확장합니다.
    5. Pod 를 클릭한 다음 fuse711-configmap-xxxx 를 클릭합니다. 애플리케이션의 Pod 세부 정보가 표시됩니다.
    6. 로그 탭을 클릭하여 애플리케이션 로그를 확인합니다.
  6. CloudEvent/ main/resources/application.properties 에 구성된 기본 수신자 목록은 생성된 메시지를 두 개의 더미 엔드포인트인 direct:async-queuedirect:file 로 보냅니다. 이렇게 하면 다음과 같은 메시지가 애플리케이션 로그에 기록됩니다.

    5:44:57.377 [Camel (camel) thread #0 - timer://order] INFO  generate-order-route - Generating message message-44, sending to the recipient list
    15:44:57.378 [Camel (camel) thread #0 - timer://order] INFO  target-route-queue - ----> message-44 pushed to an async queue (simulation)
    15:44:57.379 [Camel (camel) thread #0 - timer://order] INFO  target-route-queue - ----> Using username 'myuser' for the async queue
    15:44:57.380 [Camel (camel) thread #0 - timer://order] INFO  target-route--file - ----> message-44 written to a file
  7. ConfigMap 오브젝트를 사용하여 fuse711-configmap 애플리케이션의 구성을 업데이트하려면 먼저 OpenShift ApiServer에서 데이터를 볼 수 있는 fuse711-configmap 애플리케이션 권한을 부여해야 합니다. 다음 명령을 입력하여 fuse711-configmap 애플리케이션의 서비스 계정에 보기 권한을 부여합니다.

    oc policy add-role-to-user view system:serviceaccount:openshift:qs-camel-config
    참고

    서비스 계정은 system:serviceaccount:PROJECT_NAME:SERVICE_ACCOUNT_NAME 구문을 사용하여 지정됩니다. fis-config 배포 설명자는 SERVICE_ACCOUNT_NAMEqs-camel-config 로 정의합니다.

  8. 실행 중인 실시간 다시 로드 기능을 보려면 다음과 같이 ConfigMap 오브젝트를 생성합니다.

    oc create -f sample-configmap.yml

    새 ConfigMap은 실행 중인 애플리케이션에서 Camel 경로의 수신자 목록을 재정의하고, 생성된 메시지를 세 개의 더미 엔드포인트로 전송하도록 구성합니다. direct:async-queue,direct:file, direct:mail.mail . ConfigMap 오브젝트에 대한 자세한 내용은 ConfigMap 설정을 참조하십시오. 이렇게 하면 다음과 같은 메시지가 애플리케이션 로그에 기록됩니다.

    16:25:24.121 [Camel (camel) thread #0 - timer://order] INFO  generate-order-route - Generating message message-9, sending to the recipient list
    16:25:24.124 [Camel (camel) thread #0 - timer://order] INFO  target-route-queue - ----> message-9 pushed to an async queue (simulation)
    16:25:24.125 [Camel (camel) thread #0 - timer://order] INFO  target-route-queue - ----> Using username 'myuser' for the async queue
    16:25:24.125 [Camel (camel) thread #0 - timer://order] INFO  target-route--file - ----> message-9 written to a file (simulation)
    16:25:24.126 [Camel (camel) thread #0 - timer://order] INFO  target-route--mail - ----> message-9 sent via mail

11.2.2. 구성 속성 console

구성 속성 빈은 삽입을 통해 구성 설정을 수신할 수 있는 일반 Java 빈입니다. Java 코드와 외부 구성 메커니즘 간의 기본 인터페이스를 제공합니다.

외부화된 구성 및 iPXE 레지스트리

다음 이미지에서는 Spring Boot 외부화된 구성이 spring-boot-camel-config 빠른 시작에서 작동하는 방법을 보여줍니다.

kube spring boot 01

구성 메커니즘에는 다음과 같은 주요 부분이 있습니다.

속성 소스
구성에 삽입하기 위한 속성 설정을 제공합니다. 기본 속성 소스는 애플리케이션의 application.properties 파일이며, ConfigMap 오브젝트 또는 Secret 오브젝트로 재정의할 수도 있습니다.
구성 속성 빈
속성 소스에서 configuraton 업데이트를 수신합니다. 구성 속성 빈은 @Configuration@ConfigurationProperties 주석으로 장식된 Java 빈입니다.
Spring opening 레지스트리
필수 주석을 사용하면 구성 속성 빈이 Spring console 레지스트리에 등록됩니다.
Camel console 레지스트리와 통합
Camel 빈 레지스트리는 Camel 경로에서 등록된 Spring 빈을 참조할 수 있도록 Spring console 레지스트리와 자동으로 통합됩니다.

QuickstartConfiguration 클래스

fuse711-configmap 프로젝트의 구성 속성ball은 다음과 같이 빠른 시작 구성 Java 클래스(이중요 /main/java/org/example/fis/ 디렉터리 아래)로 정의됩니다.

package org.example.fis;

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Configuration;

@Configuration  1
@ConfigurationProperties(prefix = "quickstart")  2
public class QuickstartConfiguration {

    /**
     * A comma-separated list of routes to use as recipients for messages.
     */
    private String recipients;  3

    /**
     * The username to use when connecting to the async queue (simulation)
     */
    private String queueUsername;  4

    /**
     * The password to use when connecting to the async queue (simulation)
     */
    private String queuePassword;  5

    // Setters and Getters for Bean properties
    // NOT SHOWN
    ...
}
1
@Configuration 주석을 사용하면 빠른 시작Configuration 클래스가 ID인 QuickstartConfiguration.com으로 Spring에서 인스턴스화 및 등록됩니다. 이렇게 하면 Camel에서 빈에 자동으로 액세스할 수 있습니다. 예를 들어 target-route-queue 경로는 Camel 구문 ${ovn:quickstartConfiguration?method=getQueueUsername} 을 사용하여 queueUserName 속성에 액세스할 수 있습니다.
2
@ConfigurationProperties 주석은 속성 소스에서 속성 값을 정의할 때 사용해야 하는 접두사인 빠른 시작을 정의합니다. 예를 들어 속성 파일은 recipient 속성을 quickstart.recipients 로 참조합니다.
3
받는 사람 속성은 속성 소스에서 삽입할 수 있습니다.
4
queueUsername 속성은 속성 소스에서 삽입할 수 있습니다.
5
queuePassword 속성은 속성 소스에서 삽입할 수 있습니다.

11.2.3. 시크릿 설정

이 빠른 시작의 Kubernetes 보안은 추가 필수 단계를 제외하고 표준 방식으로 설정됩니다. Spring Cloud Kubernetes 플러그인은 시크릿의 마운트 경로로 구성되어야 런타임 시 시크릿을 읽을 수 있습니다. 보안을 설정하려면 다음을 수행합니다.

  1. 샘플 보안 오브젝트 생성
  2. 시크릿의 볼륨 마운트 구성
  3. Secret 속성을 읽도록 spring-cloud-kubernetes 구성

샘플 Secret 오브젝트

빠른 시작 프로젝트는 다음과 같이 샘플 Secret, sample-secret.yml 을 제공합니다. Secret 오브젝트의 속성 값은 항상 base64로 인코딩됩니다( base64 명령줄 유틸리티 사용). Pod의 파일 시스템에 시크릿이 마운트되면 값이 다시 일반 텍스트로 다시 디코딩됩니다.

sample-secret.yml 파일

apiVersion: v1
kind: Secret
metadata: 1
  name: camel-config
type: Opaque
data:
  # The username is 'myuser'
  quickstart.queue-username: bXl1c2VyCg== 2
  quickstart.queue-password: MWYyZDFlMmU2N2Rm 3

1
metadata.name: 시크릿을 식별합니다. OpenShift 시스템의 다른 부분에서는 이 ID를 사용하여 보안을 참조합니다.
2
빠른 시작.queue-username: 빠른 시작Configuration 빈의 queueUsername 속성에 삽입해야 합니다. 값은 base64로 인코딩 되어야 합니다.
3
Quickstart.queue-password: 빠른 시작Configuration 빈의 queuePassword 속성에 삽입해야 합니다. 값은 base64로 인코딩 되어야 합니다.
참고

Kubernetes에서는 CamelCase에서 속성 이름을 정의할 수 없습니다(속성 이름이 모두 소문자여야 함). 이 제한을 해결하려면 Spring Boot가 queueUsername 과 일치하는 하이픈 양식 queue-username 을 사용합니다. 이를 통해 Spring Boot의 외부화된 구성에 대한 완화된 바인딩 규칙을 활용합니다.

시크릿의 볼륨 마운트 구성

보안을 볼륨 마운트로 구성하여 런타임에 보안을 로드하도록 애플리케이션을 구성해야 합니다. 애플리케이션이 시작되면 Secret 속성을 파일 시스템의 지정된 위치에서 사용할 수 있게 됩니다. 애플리케이션의 deployment.yml 파일은 Secret의 볼륨 마운트를 정의하는 CloudEvent /main/jkube/ 디렉터리에 있습니다.

deployment.yml 파일

spec:
  template:
    spec:
      serviceAccountName: "qs-camel-config"
      volumes: 1
        - name: "camel-config"
          secret:
            # The secret must be created before deploying this application
            secretName: "camel-config"
      containers:
        -
          volumeMounts: 2
            - name: "camel-config"
              readOnly: true
              # Mount the secret where spring-cloud-kubernetes is configured to read it
              # see src/main/resources/bootstrap.yml
              mountPath: "/etc/secrets/camel-config"
          resources:
#            requests:
#              cpu: "0.2"
#              memory: 256Mi
#            limits:
#              cpu: "1.0"
#              memory: 256Mi
             env:
              - name: SPRING_APPLICATION_JSON
               value: '{"server":{"undertow":{"io-threads":1, "worker-threads":2 }}}'

1
volumes 섹션에서 배포는 camel-config 라는 새 볼륨을 선언하고, camel-config 라는 Secret을 참조합니다.
2
volumeMounts 섹션에서 배포는 camel-config 볼륨을 참조하는 새 볼륨 마운트를 선언하고 Pod 파일 시스템의 /etc/secrets/camel-config 경로에 Secret 볼륨을 마운트해야 함을 지정합니다.

보안 속성을 읽도록 spring-cloud-kubernetes 구성

Spring Boot 외부 구성과 시크릿을 통합하려면 Spring Cloud Kubernetes 플러그인을 시크릿 마운트 경로로 구성해야 합니다. Spring Cloud Kubernetes는 지정된 위치에서 시크릿을 읽고 속성 소스로 Spring Boot에서 사용할 수 있도록 합니다. Spring Cloud Kubernetes 플러그인은 빠른 시작 프로젝트의 CloudEvent /main/resources 에 있는 bootstrap.yml 파일의 설정으로 구성됩니다.

bootstrap.yml file

# Startup configuration of Spring-cloud-kubernetes
spring:
  application:
    name: camel-config
  cloud:
    kubernetes:
      reload:
        # Enable live reload on ConfigMap change (disabled for Secrets by default)
        enabled: true
      secrets:
        paths: /etc/secrets/camel-config

spring.cloud.kubernetes.secrets.paths 속성은 Pod에 보안 볼륨 마운트 경로 목록을 지정합니다.

참고

bootstrap.properties 파일(또는 bootstrap.yml 파일)은 application.properties 파일과 유사하게 작동하지만 애플리케이션 시작 초기 단계에서 로드됩니다. bootstrap.properties 파일에서 Spring Cloud Kubernetes 플러그인과 관련된 속성을 설정하는 것이 더 안정적입니다.

11.2.4. ConfigMap 설정

ConfigMap 오브젝트를 생성하고 보기 권한을 적절하게 설정하는 것 외에도 Spring Cloud Kubernetes와의 통합에서는 프로젝트의 bootstrap.yml 파일에 구성된 Spring .application.name 속성 값과 ConfigMap의 metadata.name 을 일치시켜야 합니다. ConfigMap을 설정하려면 다음을 수행합니다.

  • 샘플 ConfigMap 오브젝트 생성
  • 보기 권한 설정
  • Spring Cloud Kubernetes 플러그인 구성

샘플 ConfigMap 오브젝트

빠른 시작 프로젝트는 샘플 ConfigMap, sample-configmap.yml 을 제공합니다.

kind: ConfigMap
apiVersion: v1
metadata: 1
  # Must match the 'spring.application.name' property of the application
  name: camel-config
data:
  application.properties: | 2
    # Override the configuration properties here
    quickstart.recipients=direct:async-queue,direct:file,direct:mail 3
1
metadata.name: ConfigMap을 식별합니다. OpenShift 시스템의 다른 부분에서는 이 식별자를 사용하여 ConfigMap을 참조합니다.
2
data.application.properties: 이 섹션에서는 애플리케이션과 함께 배포된 원래 application.properties 파일의 설정을 재정의할 수 있는 속성 설정을 나열합니다.
3
빠른 시작.recipients: 빠른 시작Configuration 빈의 수신자 속성에 삽입해야 합니다.

보기 권한 설정

Secret의 deployment.yml 파일에 표시된 대로 serviceAccountName 은 프로젝트의 deployment.yml 파일에서 qs-camel-config 로 설정됩니다. 따라서 빠른 시작 애플리케이션에 대한 보기 권한을 활성화하려면 다음 명령을 입력해야 합니다( test 프로젝트 네임스페이스에 배포한다고 가정).

oc policy add-role-to-user view system:serviceaccount:test:qs-camel-config

Spring Cloud Kubernetes 플러그인 구성

Spring Cloud Kubernetes 플러그인은 bootstrap.yml 파일의 다음 설정으로 구성됩니다.

spring.application.name
이 값은 ConfigMap 오브젝트의 metadata.name 과 일치해야 합니다(예: 빠른 시작 프로젝트의 sample-configmap.yml 에 정의된 대로). 기본값은 application 입니다.
spring.cloud.kubernetes.reload.enabled
이 값을 true 로 설정하면 ConfigMap 오브젝트를 동적으로 다시 로드할 수 있습니다.

지원되는 속성에 대한 자세한 내용은 PropertySource Reload Configuration Properties 을 참조하십시오.

11.3. ConfigMap PropertySource 사용

Kubernetes에는 구성을 애플리케이션에 전달하기 위한 ConfigMap 의 개념이 있습니다. Spring 클라우드 Kubernetes 플러그인은 ConfigMap 과의 통합을 통해 Spring Boot에서 구성 맵에 액세스할 수 있도록 합니다.

ConfigMap PropertySource 가 활성화되면 애플리케이션 뒤에 이름이 지정된 ConfigMap 에 대한 Kubernetes를 찾습니다( spring.application.name참조). 맵이 발견되면 해당 데이터를 읽고 다음을 수행합니다.

11.3.1. 개별 속성 적용

속성을 사용하여 스레드 풀 구성을 읽는 demo 라는 Spring Boot 애플리케이션이 있다고 가정하겠습니다.

  • pool.size.core
  • pool.size.max

이는 YAML 형식의 구성 맵으로 외부화할 수 있습니다.

kind: ConfigMap
apiVersion: v1
metadata:
  name: demo
data:
  pool.size.core: 1
  pool.size.max: 16

11.3.2. application.yaml ConfigMap 속성 적용

개별 속성은 대부분의 경우 잘 작동하지만 경우에 따라 YAML이 더 편리합니다. 이 경우 application.yaml 이라는 단일 속성을 사용하고 YAML을 여기에 포함합니다.

kind: ConfigMap
apiVersion: v1
metadata:
  name: demo
data:
  application.yaml: |-
    pool:
      size:
        core: 1
        max:16

11.3.3. application.properties ConfigMap 속성 적용

Spring Boot application.properties 파일의 스타일로 ConfigMap 속성을 정의할 수도 있습니다. 이 경우 application.properties 라는 단일 속성을 사용하고 그 내부의 속성 설정을 나열합니다.

kind: ConfigMap
apiVersion: v1
metadata:
  name: demo
data:
  application.properties: |-
    pool.size.core: 1
    pool.size.max: 16

11.3.4. ConfigMap 배포

ConfigMap을 배포하고 Spring Boot 애플리케이션에서 액세스할 수 있도록 하려면 다음 단계를 수행합니다.

절차

  1. Spring Boot 애플리케이션에서 외부 구성 메커니즘을 사용하여 ConfigMap 속성 소스에 액세스합니다. 예를 들어 @Configuration 주석을 사용하여 Java 빈에 주석을 달면 ConfigMap에 의해 빈의 속성 값을 삽입할 수 있습니다.
  2. 프로젝트의 bootstrap.properties 파일(또는 bootstrap.yaml 파일)에서 spring.application.name 속성을 ConfigMap의 이름과 일치하도록 설정합니다.
  3. 애플리케이션과 연결된 서비스 계정에 대한 보기 권한을 활성화합니다(기본적으로 기본 서비스 계정임). 예를 들어 기본 서비스 계정에 보기 권한을 추가하려면 다음을 수행합니다.

    oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default -n $(oc project -q)

11.4. Secrets PropertySource 사용

Kubernetes에는 암호, OAuth 토큰 등과 같은 중요한 데이터를 저장하기 위한 시크릿 개념이 있습니다. Spring 클라우드 Kubernetes 플러그인은 Secrets 와의 통합을 제공하여 Spring Boot에서 시크릿에 액세스할 수 있도록 합니다.

활성화된 Secrets 속성 소스는 다음 소스에서 Kubernetes for Secrets 를 찾습니다. 시크릿이 발견되면 해당 데이터를 애플리케이션에 사용할 수 있습니다.

  1. 시크릿 마운트에서 재귀적으로 읽기
  2. 애플리케이션 뒤에 이름이 지정됨( spring.application.name참조)
  3. 일부 라벨 일치

기본적으로 API를 통해 시크릿을 사용하는 경우 (위의 2점과 3점) 는 사용할 수 없습니다.

11.4.1. 보안 설정 예

속성을 사용하여 ActiveMQ 및 PostreSQL 구성을 읽는 demo 라는 Spring Boot 애플리케이션이 있다고 가정하겠습니다.

amq.username
amq.password
pg.username
pg.password

이러한 보안은 YAML 형식의 시크릿 으로 외부화될 수 있습니다.

ActiveMQ 보안
apiVersion: v1
kind: Secret
metadata:
  name: activemq-secrets
  labels:
    broker: activemq
type: Opaque
data:
  amq.username: bXl1c2VyCg==
  amq.password: MWYyZDFlMmU2N2Rm
PostreSQL 보안
apiVersion: v1
kind: Secret
metadata:
  name: postgres-secrets
  labels:
    db: postgres
type: Opaque
data:
  pg.username: dXNlcgo=
  pg.password: cGdhZG1pbgo=

11.4.2. 보안 사용

사용할 시크릿을 여러 가지 방법으로 선택할 수 있습니다.

  • 보안이 매핑되는 디렉터리를 나열하여 다음을 수행하십시오.

    -Dspring.cloud.kubernetes.secrets.paths=/etc/secrets/activemq,etc/secrets/postgres

    공통 루트에 매핑된 모든 시크릿이 있는 경우 다음과 같이 설정할 수 있습니다.

    -Dspring.cloud.kubernetes.secrets.paths=/etc/secrets
  • 이름이 지정된 보안을 설정하면 다음을 수행합니다.

    -Dspring.cloud.kubernetes.secrets.name=postgres-secrets
  • 레이블 목록을 정의합니다.

    -Dspring.cloud.kubernetes.secrets.labels.broker=activemq
    -Dspring.cloud.kubernetes.secrets.labels.db=postgres

11.4.3. Secrets PropertySource의 구성 속성

다음 속성을 사용하여 Secrets 속성 소스를 구성할 수 있습니다.

spring.cloud.kubernetes.secrets.enabled
Secrets 속성 소스를 활성화합니다. type은 Boolean 이고 기본값은 true 입니다.
spring.cloud.kubernetes.secrets.name
검색할 시크릿의 이름을 설정합니다. type은 String 이고 기본값은 ${spring.application.name} 입니다.
spring.cloud.kubernetes.secrets.labels
시크릿을 조회하는 데 사용되는 레이블을 설정합니다. 이 속성은 맵 기반 바인딩에 정의된 대로 작동합니다. type은 java.util.Map 이며 기본값은 null 입니다.
spring.cloud.kubernetes.secrets.paths
보안이 마운트된 경로를 설정합니다. 이 속성은 컬렉션 기반 바인딩에 정의된 대로 작동합니다. type은 java.util.List 이며 기본값은 null 입니다.
spring.cloud.kubernetes.secrets.enableApi
API를 통해 시크릿 사용 활성화/비활성화. type은 Boolean 이고 기본값은 false 입니다.
참고

보안상의 이유로 API를 통한 시크릿에 대한 액세스가 제한될 수 있습니다. 기본 방법은 POD에 시크릿을 마운트하는 것입니다.

11.5. PropertySource 재로드 사용

일부 애플리케이션에서는 외부 속성 소스의 변경 사항을 감지하고 새 구성을 반영하도록 내부 상태를 업데이트해야 할 수 있습니다. Spring Cloud Kubernetes의 다시 로드 기능은 관련 ConfigMap 또는 시크릿이 변경될 때 애플리케이션 다시 로드를 트리거할 수 있습니다.

11.5.1. PropertySource Reload 활성화

Spring Cloud Kubernetes의 PropertySource 재로드 기능은 기본적으로 비활성화되어 있습니다.

절차

  1. 빠른 시작 프로젝트의 gRPC/main/resources 디렉터리로 이동하여 bootstrap.yml 파일을 엽니다.
  2. 구성 속성 spring.cloud.kubernetes.reload.enabled=true 를 변경합니다.

11.5.2. PropertySource 재로드 수준

spring.cloud.kubernetes.reload.strategy 속성에 대해 다음 수준의 재로드가 지원됩니다.

새로고침

(기본값) @ConfigurationProperties 또는 @RefreshScope 로 주석이 달린 구성 빈만 다시 로드됩니다. 이 재로드 수준은 Spring Cloud Context의 새로 고침 기능을 활용합니다.

참고

PropertySource 재로드 기능은 다시 로드 전략이 새로 고침 하도록 설정된 경우 간단한 속성(즉, 컬렉션 아님)에만 사용할 수 있습니다. 컬렉션에서 지원하는 속성은 런타임에 변경할 수 없습니다.

restart_context
Spring ApplicationContext 전체를 정상적으로 다시 시작합니다. 빈은 새 구성을 사용하여 다시 생성됩니다.
shutdown
컨테이너 재시작을 활성화하기 위해 Spring ApplicationContext 가 종료되었습니다. 이 수준을 사용하는 경우 모든daemon 스레드의 라이프사이클이 ApplicationContext에 바인딩되고 복제 컨트롤러 또는 복제본 세트가 Pod를 다시 시작하도록 구성되어 있는지 확인합니다.

11.5.3. PropertySource Reload의 예

다음 예제에서는 다시 로드 기능이 활성화될 때 어떤 일이 발생하는지 설명합니다.

절차

  1. 다시 로드 기능이 기본 설정으로 활성화되어 있다고 가정합니다(다시 모드). 구성 맵이 변경되면 다음 빈이 새로 고쳐집니다.

    @Configuration
    @ConfigurationProperties(prefix = "bean")
    public class MyConfig {
    
        private String message = "a message that can be changed live";
    
        // getter and setters
    
    }
  2. 변경 사항이 발생하는 것을 보려면 아래와 같이 메시지를 주기적으로 출력하는 다른 빈을 만듭니다.

    @Component
    public class MyBean {
    
        @Autowired
        private MyConfig config;
    
        @Scheduled(fixedDelay = 5000)
        public void hello() {
            System.out.println("The message is: " + config.getMessage());
        }
    }
  3. 아래와 같이 ConfigMap을 사용하여 애플리케이션에서 출력한 메시지를 변경할 수 있습니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: reload-example
    data:
      application.properties: |-
        bean.message=Hello World!

    Pod와 연결된 구성 맵의 balloon .message 라는 속성에 대한 모든 변경 사항이 프로그램의 출력에 반영됩니다.

11.5.4. PropertySource 재로드 운영 모드

재로드 기능은 다음 두 가지 작동 모드를 지원합니다.

event
(기본값) Kubernetes API(웹 소켓)를 사용하여 ConfigMap 또는 시크릿의 변경 사항을 감시합니다. 모든 이벤트는 구성에 재확인되고 변경 시 다시 로드됩니다. 구성 맵 변경 사항을 수신 대기하려면 서비스 계정의 보기 역할이 필요합니다. 상위 수준 역할(예:) Edit)는 시크릿에 필요합니다(기본적으로 시크릿을 모니터링하지 않음).
폴링
구성 맵과 시크릿에서 주기적으로 구성을 다시 생성하여 변경되었는지 확인합니다. 폴링 기간은 spring.cloud.kubernetes.reload.period 속성을 사용하여 구성할 수 있으며 기본값은 15초입니다. 모니터링된 속성 소스와 동일한 역할이 필요합니다. 예를 들어, 파일 마운트된 시크릿 소스에 폴링을 사용하는 경우 특정 권한이 필요하지 않습니다.

11.5.5. PropertySource 재로드 구성 속성

다음 속성을 사용하여 다시 로드 기능을 구성할 수 있습니다.

spring.cloud.kubernetes.reload.enabled
속성 소스 및 구성 다시 로드를 모니터링할 수 있습니다. type은 Boolean 이고 기본값은 false 입니다.
spring.cloud.kubernetes.reload.monitoring-config-maps
구성 맵의 변경 사항을 모니터링할 수 있습니다. type은 Boolean 이고 기본값은 true 입니다.
spring.cloud.kubernetes.reload.monitoring-secrets
시크릿의 변경 사항을 모니터링할 수 있습니다. type은 Boolean 이고 기본값은 false 입니다.
spring.cloud.kubernetes.reload.strategy
다시 로드를 실행할 때 사용할 전략(새로 고침,restart_context,shutdown). type은 Enum 이고 기본값은 refresh 입니다.
spring.cloud.kubernetes.reload.mode
속성 소스(Event,polling)의 변경 사항을 청취하는 방법을 지정합니다. type은 Enum 이고 기본값은 event 입니다.
spring.cloud.kubernetes.reload.period
폴링 전략을 사용할 때 변경 사항을 확인하기 위한 시간(밀리초)입니다. type은 이며 기본값은 15000 입니다.

다음 사항에 유의하십시오.

  • spring.cloud.kubernetes.reload.* 속성은 ConfigMaps 또는 Secrets에서 사용해서는 안 됩니다. 런타임에 이러한 속성을 변경하면 예기치 않은 결과가 발생할 수 있습니다.
  • 새로 고침 수준을 사용할 때 속성 또는 전체 구성 맵을 삭제하면 빈의 원래 상태가 복원되지 않습니다.

12장. Karaf 이미지에 대한 애플리케이션 개발

이 튜토리얼에서는 Karaf 이미지에 대한 애플리케이션을 생성하고 배포하는 방법을 보여줍니다.

12.1. Maven archetype을 사용하여 Karaf 프로젝트 생성

Maven archetype을 사용하여 Karaf 프로젝트를 생성하려면 다음 단계를 따르십시오.

절차

  1. 시스템의 적절한 디렉터리로 이동합니다.
  2. Maven 명령을 시작하여 Karaf 프로젝트를 생성합니다.

    mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate \
      -DarchetypeCatalog=https://maven.repository.redhat.com/ga/io/fabric8/archetypes/archetypes-catalog/2.2.0.fuse-sb2-7_11_1-00018-redhat-00002/archetypes-catalog-2.2.0.fuse-sb2-7_11_1-00018-redhat-00002-archetype-catalog.xml \
      -DarchetypeGroupId=org.jboss.fuse.fis.archetypes \
      -DarchetypeArtifactId=karaf-camel-log-archetype \
      -DarchetypeVersion=2.2.0.fuse-sb2-7_11_1-00018-redhat-00002
  3. archetype 플러그인이 대화형 모드로 전환하여 나머지 필드를 입력하라는 메시지를 표시합니다.

    Define value for property 'groupId': : org.example.fis
    Define value for property 'artifactId': : fuse711-karaf-camel-log
    Define value for property 'version':  1.0-SNAPSHOT: :
    Define value for property 'package':  org.example.fis: :
    Confirm properties configuration:
    groupId: org.example.fis
    artifactId: fuse711-karaf-camel-log
    version: 1.0-SNAPSHOT
    package: org.example.fis
     Y: : Y

    메시지가 표시되면 groupId 값으로 org.example.fis 를 입력하고 artifactId 값에 fuse711-karaf-camel-log 를 입력합니다. 나머지 필드에는 기본값을 수락합니다.

  4. 위의 명령이 BUILD SUCCESS 상태로 종료되면 이제 fuse711-karaf-camel-log 하위 디렉터리 아래에 OpenShift 프로젝트에 새 Fuse가 있어야 합니다.
  5. 이제 fuse711-karaf-camel-log 프로젝트를 빌드하고 배포할 준비가 되었습니다. OpenShift에 로그인되어 있다고 가정하면 fuse711-karaf-camel-log 프로젝트의 디렉터리로 변경한 다음 다음과 같이 프로젝트를 빌드하고 배포합니다.

    cd fuse711-karaf-camel-log
    mvn oc:deploy -Popenshift
참고

사용 가능한 Karaf archetypes의 전체 목록은 Karaf Archetype Catalog 를 참조하십시오.

12.2. Camel Karaf 애플리케이션의 구조

Camel Karaf 애플리케이션의 디렉터리 구조는 다음과 같습니다.

  ├── pom.xml 1
  ├── README.md
  ├── configuration
  │   └── settings.xml
  └── src
      ├── main
      │   ├── jkube
      │   │   └── deployment.yml 2
      │   ├── java
      │   │   └── org
      │   │       └── example
      │   │           └── fis
      │   └── resources
      │       ├── assembly
      │       │   └── etc
      │       │       └── org.ops4j.pax.logging.cfg 3
      │       └── OSGI-INF
      │           └── blueprint
      │               └── camel-log.xml 4
      └── test
          └── java
              └── org
                  └── example
                      └── fis

다음 파일이 Karaf 애플리케이션을 개발하는 데 중요한 위치:

1
POM.xml: 추가 종속 항목이 포함되어 있습니다. 예를 들어 logging에 대해 pom.xml 파일에 종속 항목을 추가할 수 있습니다.
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
    </dependency>
2
CloudEvent/main/jkube/deployment.yml: openshift-maven-plugin에서 생성한 기본 OpenShift 구성 파일과 병합되는 추가 구성을 제공합니다.
참고

이 파일은 Karaf 애플리케이션의 일부로 사용되지 않지만 모든 빠른 시작에서 CPU 및 메모리 사용량과 같은 리소스를 제한하는 데 사용됩니다.

3
org.ops4j.pax.logging.cfg: 제공하십시오. 로그 수준을 사용자 지정하는 방법, 로깅 수준을 기본 INFO 대신 DEBUG로 설정합니다.
4
Camel-log.xml: 애플리케이션의 소스 코드를 포함합니다.

12.3. Karaf archetype catalog

Karaf archetype 카탈로그에는 다음 예제가 포함되어 있습니다.

표 12.1. Karaf Maven Archetypes

이름설명

karaf-camel-amq-archetype

Camel amq 구성 요소를 사용하여 Apache ActiveMQ 메시지 브로커에 메시지를 보내고 수신하는 방법을 보여줍니다.

karaf-camel-log-archetype

5초마다 서버 로그에 메시지를 기록하는 간단한 Apache Camel 애플리케이션을 보여줍니다.

karaf-camel-rest-sql-archetype

Camel의 REST DSL과 함께 JDBC를 통해 SQL을 사용하여 RESTful API를 노출하는 방법을 시연합니다.

karaf-cxf-rest-archetype

CXF를 사용하여 RESTful(JAX-RS) 웹 서비스를 생성하고 OSGi HTTP 서비스를 통해 노출하는 방법을 보여줍니다.

12.4. Fabric8 Karaf 기능 사용

Fabric8은 Apache Karaf를 지원하여 Kubernetes용 OSGi 앱을 보다 쉽게 개발할 수 있습니다.

Fabric8의 중요한 기능은 다음과 같습니다.

  • Blueprint XML 파일에서 자리 표시자를 해결하기 위한 다양한 전략
  • 환경 변수
  • 시스템 속성
  • 서비스
  • Kubernetes ConfigMap
  • Kubernetes Secrets
  • Kubernetes 구성 맵을 사용하여 OSGi 구성 관리를 동적으로 업데이트합니다.
  • Kubernetes heath에서 OSGi 서비스에 대한 heath 검사를 제공합니다.

12.4.1. Fabric8 Karaf 기능 추가

기능을 사용하려면 fabric8-karaf-features 종속성을 프로젝트 POM 파일에 추가합니다.

절차

  1. 프로젝트의 pom.xml 파일을 열고 fabric8-karaf-features 종속성을 추가합니다.
<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>fabric8-karaf-features</artifactId>
  <version>${fabric8.version}</version>
  <classifier>features</classifier>
  <type>xml</type>
</dependency>

fabric8 karaf 기능은 Karaf 서버에 설치됩니다.

12.4.2. Fabric8 Karaf Core 번들 기능 추가

번들 fabric8-karaf-core 는 청사진 및 ConfigAdmin 확장에서 사용하는 기능을 제공합니다.

절차

  1. 프로젝트의 pom.xml 을 열고 fabric8-karaf-corestartupFures 섹션에 추가합니다.

    <startupFeatures>
      ...
      <feature>fabric8-karaf-core</feature>
      ...
    </startupFeatures>

    이렇게 하면 사용자 정의 Karaf 배포에서 fabric8-karaf-core 기능이 추가됩니다.

12.4.3. Property placesholder 서비스 옵션 설정

번들 fabric8-karaf-core 는 다음과 같은 인터페이스를 사용하여 서비스 platformholderResolver 를 내보냅니다.

public interface PlaceholderResolver {
    /**
     * Resolve a placeholder using the strategy indicated by the prefix
     *
     * @param value the placeholder to resolve
     * @return the resolved value or null if not resolved
     */
    String resolve(String value);

    /**
     * Replaces all the occurrences of variables with their matching values from the resolver using the given source string as a template.
     *
     * @param source the string to replace in
     * @return the result of the replace operation
     */
    String replace(String value);

    /**
     * Replaces all the occurrences of variables within the given source builder with their matching values from the resolver.
     *
     * @param value the builder to replace in
     * @rerurn true if altered
     */
    boolean replaceIn(StringBuilder value);

    /**
     * Replaces all the occurrences of variables within the given dictionary
     *
     * @param dictionary the dictionary to replace in
     * @rerurn true if altered
     */
    boolean replaceAll(Dictionary<String, Object> dictionary);

    /**
     * Replaces all the occurrences of variables within the given dictionary
     *
     * @param dictionary the dictionary to replace in
     * @rerurn true if altered
     */
    boolean replaceAll(Map<String, Object> dictionary);
}

platform holderResolver 서비스는 다른 속성 자리 표시자 해상도 전략의 수집기 역할을 합니다. 기본적으로 제공되는 해결 전략은 표 Resolution Strategies 에 나열되어 있습니다. 속성 자리 표시자 서비스 옵션을 설정하려면 시스템 속성 또는 환경 변수 또는 둘 다를 사용할 수 있습니다.

절차

  1. OpenShift에서 ConfigMap에 액세스하려면 서비스 계정에 보기 권한이 필요합니다. 서비스 계정에 보기 권한을 추가합니다.

    oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default -n $(oc project -q)
  2. API를 통해 보안에 대한 액세스 권한이 제한될 수 있으므로 Pod에 보안을 마운트합니다.
  3. 볼륨 마운트로 Pod에서 사용 가능한 보안은 다음과 같이 보안이라는 디렉터리에 매핑됩니다.

    containers:
      -
       env:
       - name: FABRIC8_K8S_SECRETS_PATH
         value: /etc/secrets
         volumeMounts:
       - name: activemq-secret-volume
         mountPath: /etc/secrets/activemq
         readOnly: true
       - name: postgres-secret-volume
         mountPath: /etc/secrets/postgres
         readOnly: true
    
    volumes:
      - name: activemq-secret-volume
      secret:
      secretName: activemq
      - name: postgres-secret-volume
       secret:
      secretName: postgres

12.4.4. 사용자 정의 속성 자리 표시자 확인자 추가

사용자 정의 암호화와 같은 특정 요구 사항을 지원하기 위해 사용자 정의 자리 표시자 확인자를 추가할 수 있습니다. 또한 placesholder Resolver 서비스를 사용하여 해결자를 청사진 및 ConfigAdmin에서 사용할 수 있도록 할 수 있습니다.

절차

  1. pom.xml 프로젝트에 다음 mvn 종속성을 추가합니다.

    pom.xml

    ---
    <dependency>
      <groupId>io.fabric8</groupId>
      <artifactId>fabric8-karaf-core</artifactId>
    </dependency>
    ---

  2. PropertiesFunction 인터페이스를 구현하고 SCR을 사용하여 OSGi 서비스로 등록합니다.

    import io.fabric8.karaf.core.properties.function.PropertiesFunction;
    import org.apache.felix.scr.annotations.Component;
    import org.apache.felix.scr.annotations.ConfigurationPolicy;
    import org.apache.felix.scr.annotations.Service;
    
    @Component(
        immediate = true,
        policy = ConfigurationPolicy.IGNORE,
        createPid = false
    )
    @Service(PropertiesFunction.class)
    public class MyPropertiesFunction implements PropertiesFunction {
        @Override
        public String getName() {
            return "myResolver";
        }
    
        @Override
        public String apply(String remainder) {
            // Parse and resolve remainder
            return remainder;
        }
    }
  3. 다음과 같이 구성 관리에서 해결 프로그램을 참조할 수 있습니다.

    속성

    my.property = $[myResolver:value-to-resolve]

12.4.5. 해결 전략 목록

platform holderResolver 서비스는 다른 속성 자리 표시자 해상도 전략의 수집기 역할을 합니다. 기본적으로 제공하는 해결 전략은 표에 나열되어 있습니다.

  1. 해결 전략 목록

접두사

예제

설명

env

env:JAVA_HOME

OS 환경 변수에서 속성을 조회합니다.

'sys

sys:java.version

Java JVM 시스템 속성에서 속성을 조회합니다.

`service

service:amq

서비스 이름 지정 규칙을 사용하여 OS 환경 변수에서 속성을 조회합니다.

service.host

service.host:amq

hostname 부분만 반환하는 서비스 이름 지정 규칙을 사용하여 OS 환경 변수에서 속성을 찾습니다.

service.port

service.port:amq

포트 부분만 반환하는 서비스 이름 규칙을 사용하여 OS 환경 변수에서 속성을 찾습니다.

k8s:map

k8s:map:myMap/myKey

Kubernetes ConfigMap (API를 통해)에서 속성 조회

k8s:secret

k8s:secret:amq/password

Kubernetes 보안 (API 또는 볼륨 마운트를 통해)에서 속성 조회

12.4.6. Property placesholder 서비스 옵션 목록

속성 자리 표시자 서비스는 다음 옵션을 지원합니다.

  1. 속성 자리 표시자 서비스 옵션 목록
이름기본설명

fabric8.placeholder.prefix

$[

자리 표시자의 접두사

fabric8.placeholder.suffix

]

자리 표시자의 접미사입니다.

fabric8.k8s.secrets.path

null

시크릿이 매핑되는 쉼표로 구분된 경로 목록

fabric8.k8s.secrets.api.enabled

false

API를 통해 시크릿 사용/비활성화

12.5. Fabric8 Karaf Config 관리자 지원 추가

12.5.1. Fabric8 Karaf Config 관리자 지원 추가

Fabric8 Karaf Config admin 지원을 사용자 정의 Karaf 배포판에 추가할 수 있습니다.

절차

  • 프로젝트의 pom.xml 을 열고 fabric8-karaf-cmstartupFures 섹션에 추가합니다.

    pom.xml

    <startupFeatures>
      ...
      <feature>fabric8-karaf-cm</feature>
      ...
    </startupFeatures>

12.5.2. ConfigMap 삽입 추가

fabric8-karaf-cm 는 Karaf의 ConfigAdminConfigMap 값을 삽입하는 ConfigAdmin 브리지를 제공합니다.

절차

  1. ConfigAdmin 브리지에서 추가하려면 ConfigMap에 karaf.pid 로 레이블이 지정되어야 합니다. karaf.pid 값은 구성 요소의 pid에 해당합니다. 예를 들면 다음과 같습니다.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: myconfig
      labels:
        karaf.pid: com.mycompany.bundle
    data:
      example.property.1: my property one
      example.property.2: my property two
  2. 구성을 정의하려면 단일 속성 이름을 사용하면 됩니다. 개별 속성은 대부분의 경우에 작동합니다. karaf/etc 의 pid 파일과 동일합니다. 예를 들면 다음과 같습니다.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: myconfig
      labels:
        karaf.pid: com.mycompany.bundle
    data:
      com.mycompany.bundle.cfg: |
        example.property.1: my property one
        example.property.2: my property two

12.5.3. 구성 플러그인

fabric8-karaf-cm 는 구성 속성 자리 표시자를 확인하는 ConfigurationPlugin 을 제공합니다.

fabric8-karaf-cm 플러그인으로 속성 대체를 활성화하려면 Java 속성인 fabric8.config.plugin.enabledtrue 로 설정해야 합니다. 예를 들어 다음과 같이 Karaf 이미지의 JAVA_OPTIONS 환경 변수를 사용하여 이 속성을 설정할 수 있습니다.

JAVA_OPTIONS=-Dfabric8.config.plugin.enabled=true

12.5.4. 구성 속성 platformholders

구성 속성 자리 표시자의 예는 다음과 같습니다.

my.service.cfg

    amq.usr = $[k8s:secret:$[env:ACTIVEMQ_SERVICE_NAME]/username]
    amq.pwd = $[k8s:secret:$[env:ACTIVEMQ_SERVICE_NAME]/password]
    amq.url = tcp://$[env+service:ACTIVEMQ_SERVICE_NAME]

my-service.xml

    <?xml version="1.0" encoding="UTF-8"?>

    <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
               xsi:schemaLocation="
                 http://www.osgi.org/xmlns/blueprint/v1.0.0
                 https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
                 http://camel.apache.org/schema/blueprint
                 http://camel.apache.org/schema/blueprint/camel-blueprint.xsd">

      <cm:property-placeholder persistent-id="my.service" id="my.service" update-strategy="reload"/>

      <bean id="activemq" class="org.apache.activemq.camel.component.ActiveMQComponent">
         <property name="userName"  value="${amq.usr}"/>
         <property name="password"  value="${amq.pwd}"/>
         <property name="brokerURL" value="${amq.url}"/>
      </bean>
    </blueprint>

12.5.5. Fabric8 Karaf Config Admin 옵션

Fabric8 Karaf Config Admin은 다음 옵션을 지원합니다.

이름기본설명

fabric8.config.plugin.enabled

false

Enable ConfigurationPlugin

fabric8.cm.bridge.enabled

true

ConfigAdmin 브리지 활성화

fabric8.config.watch

true

ConfigMap 변경 조사 활성화

fabric8.config.merge

false

ConfigAdmin에서 병합 ConfigMap 값 활성화

fabric8.config.meta

true

ConfigAdmin 브릿지에서 ConfigMap 메타 삽입 활성화

fabric8.pid.label

karaf.pid

ConfigAdmin 브리지가 찾는 레이블을 정의합니다(즉, 선택해야 하는 ConfigMap에는 해당 레이블이 있어야 합니다. 해당 PID가 연결된 값을 결정).

fabric8.pid.filters

empty

ConfigAdmin 브릿지에 대한 추가 조건을 정의하여 ConfigMap을 선택합니다. 지원되는 구문은 다음과 같습니다.

  • 서로 다른 레이블의 조건은 ""로 구분되며 서로 AND로 사용됩니다.
  • 레이블 내에서colums(;)는 OR로 간주되며 레이블 값의 조건에 대한 구분자로 사용될 수 있습니다.

예를 들어 -Dfabric8.pid.filters=appName=A;B,database.name=my.oracle.datasource 와 같은 필터는 값이 A 또는 B인 appName 레이블이 있는 모든 ConfigMaps로 변환됩니다.

중요

ConfigurationPlugin 에는 Aries Blueprint CM 1.0.9 이상이 필요합니다.

12.6. Fabric8 Karaf 청사진 지원 추가

fabric8-karaf-blueprintAries PropertyEvaluator 및 속성 자리 표시자를 fabric8-karaf-core 에서 사용하여 청사진 XML 파일의 자리 표시자를 해결합니다.

절차

  • 사용자 지정 Karaf 배포판에 청사진 지원 기능을 포함하려면 pom.xmlstartup Fundueures 섹션에 fabric8-karaf-blueprint 를 추가합니다.

    <startupFeatures>
      ...
      <feature>fabric8-karaf-blueprint</feature>
      ...
    </startupFeatures>

예제

fabric8 evaluator는 ${env+service:MY_ENV_VAR} 와 같은 체인된 평가자를 지원합니다. MY_ENV_VAR 변수를 환경 변수에 대해 확인해야 합니다. 그러면 서비스 기능을 사용하여 결과가 해결됩니다. 예를 들면 다음과 같습니다.

<?xml version="1.0" encoding="UTF-8"?>

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.2.0"
           xsi:schemaLocation="
             http://www.osgi.org/xmlns/blueprint/v1.0.0
             https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
             http://camel.apache.org/schema/blueprint
             http://camel.apache.org/schema/blueprint/camel-blueprint.xsd
             http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.3.0
             http://aries.apache.org/schemas/blueprint-ext/blueprint-ext-1.3.xsd">

  <ext:property-placeholder evaluator="fabric8" placeholder-prefix="$[" placeholder-suffix="]"/>

  <bean id="activemq" class="org.apache.activemq.camel.component.ActiveMQComponent">
     <property name="userName"  value="$[k8s:secret:$[env:ACTIVEMQ_SERVICE_NAME]/username]"/>
     <property name="password"  value="$[k8s:secret:$[env:ACTIVEMQ_SERVICE_NAME]/password]"/>
     <property name="brokerURL" value="tcp://$[env+service:ACTIVEMQ_SERVICE_NAME]"/>
  </bean>
</blueprint>
중요

중첩된 속성 자리 표시자 대체에는 Aries Blueprint Core 1.7.0 이상이 필요합니다.

12.7. Fabric8 Karaf 상태 점검 활성화

fabric8-karaf-checks 를 시작 기능으로 설치하는 것이 좋습니다. 활성화되면 Karaf 서버에서 준비 상태 및 활성 상태 프로브에 사용할 수 있는 http://0.0.0.0:8181/readiness-checkhttp://0.0.0.0:8181/health-check URL을 노출할 수 있습니다.

참고

이러한 URL은 다음에 해당하는 경우에만 HTTP 200 상태 코드로 응답합니다.

  • OSGi Framework가 시작되었습니다.
  • 모든 OSGi 번들이 시작됩니다.
  • 모든 부팅 기능이 설치됩니다.
  • 배포된 모든 Blue gRPC 번들은 생성된 상태에 있습니다.
  • 배포된 모든 SCR 번들은 활성, 등록 또는 팩토리 상태에 있습니다.
  • 모든 웹 번들은 웹 서버에 배포됩니다.
  • 생성된 모든 Camel 컨텍스트가 시작 상태에 있습니다.

절차

  1. 프로젝트의 pom.xml 을 열고 startup Fureures 섹션에 fabric8-karaf-checks 기능을 추가합니다.

    pom.xml

    <startupFeatures>
      ...
      <feature>fabric8-karaf-checks</feature>
      ...
    </startupFeatures>

    oc:resources 목표는 fabric8-karaf-checks 기능을 사용하는지 여부를 감지하고 컨테이너 구성에 준비 및 활성 상태 프로브를 위해 Kubernetes를 자동으로 추가합니다.

12.7.1. 상태 점검 구성

기본적으로 fabric8-karaf-checks 끝점은 포트 8181 에서 실행되는 내장 HTTP 서버 엔진(Undertow)에 등록됩니다. 컨테이너에서 실행 중인 다른 HTTP 프로세스에서 실행 중인 다른 HTTP 프로세스에서 상태 및 준비 상태 점검 요청이 차단되는 것을 방지하기 위해 엔드포인트를 별도의 container에 등록할 수 있습니다.

이러한 검사는 다음 속성을 설정하여 etc/io.fabric8.checks.cfg 파일에서 구성할 수 있습니다.

  • httpPort: 이 속성이 지정되어 있고 유효한 포트 번호인 경우 readiness-checkhealth-check 끝점이 CloudEvent 서버의 별도의 인스턴스에 등록됩니다.
  • readinessCheckPathhealthCheckPath 속성을 사용하면 준비 및 상태 점검에 사용할 수 있는 실제 URI를 구성할 수 있습니다. 기본적으로 이 값은 이전 값과 동일합니다.
참고

이러한 속성은 Fuse-Karaf를 시작한 후 변경될 수 있지만, etc/io.fabric8.checks.cfg 파일에 사용자 지정 Karaf 배포판의 일부로 지정될 수도 있습니다. 이 파일은 즉시 실행 중인 fabric8-karaf-checks 기능을 사용하고자 하는 고객이 사용합니다.

다음 예제에서는 etc/io.fabric8.checks.cfg 파일의 health 및 readiness 속성의 구성을 보여줍니다.

예제

httpPort = 8182
readinessCheckPath = /readiness-check
healthCheckPath = /health-check

12.8. 사용자 정의 상태 점검 추가

Karaf 서버가 요청을 처리할 준비가 되었기 전에 사용자 트래픽을 수신하지 못하도록 추가 사용자 정의 heath 검사를 제공할 수 있습니다. 사용자 정의 상태 점검을 사용하려면 io.fabric8.karaf.checks.HealthChecker 또는 io.fabric8.karaf.checks.ReadinessChecker 인터페이스를 구현하고 OSGi 레지스트리에 해당 오브젝트를 등록해야 합니다.

절차

  • pom.xml 파일에 다음 mvn 종속성을 추가합니다.

    pom.xml

    <dependency>
      <groupId>io.fabric8</groupId>
      <artifactId>fabric8-karaf-checks</artifactId>
    </dependency>

    참고

    OSGi 레지스트리에서 오브젝트를 생성하고 등록하는 가장 간단한 방법은 SCR을 사용하는 것입니다.

예제

사용 가능한 디스크 공간이 있는지 확인하기 위해 상태 점검을 수행하는 예는 다음과 같습니다.

import io.fabric8.karaf.checks.*;
import org.apache.felix.scr.annotations.*;
import org.apache.commons.io.FileSystemUtils;
import java.util.Collections;
import java.util.List;

@Component(
    name = "example.DiskChecker",
    immediate = true,
    enabled = true,
    policy = ConfigurationPolicy.IGNORE,
    createPid = false
)
@Service({HealthChecker.class, ReadinessChecker.class})
public class DiskChecker implements HealthChecker, ReadinessChecker {

    public List<Check> getFailingReadinessChecks() {
        // lets just use the same checks for both readiness and health
        return getFailingHeathChecks();
    }

    public List<Check> getFailingHealthChecks() {
        long free = FileSystemUtils.freeSpaceKb("/");
        if (free < 1024 * 500) {
            return Collections.singletonList(new Check("disk-space-low", "Only " + free + "kb of disk space left."));
        }
        return Collections.emptyList();
    }
}

13장. JBoss EAP 이미지용 애플리케이션 개발

JBoss EAP에서 Fuse 애플리케이션을 개발하기 위한 대안은 S2I 소스 워크플로를 사용하여 EAP를 통해 Red Hat Camel CDI용 OpenShift 프로젝트를 생성하는 것입니다.

사전 요구 사항

  • OpenShift가 올바르게 실행되고 Fuse 이미지 스트림이 OpenShift에 이미 설치되어 있는지 확인합니다. 관리자용 시작하기를 참조하십시오.
  • Maven 리포지토리가 fuse용으로 구성되었는지 확인합니다. Maven 리포지토리 구성을 참조하십시오.

13.1. S2I 소스 워크플로를 사용하여 JBoss EAP 프로젝트 생성

JBoss EAP에서 Fuse 애플리케이션을 개발하기 위한 대안은 S2I 소스 워크플로를 사용하여 EAP를 통해 Red Hat Camel CDI용 OpenShift 프로젝트를 생성하는 것입니다.

절차

  1. 클러스터링을 활성화하려면 default 서비스 계정에 view 역할을 추가합니다. 이렇게 하면 사용자에게 기본 서비스 계정에 대한 보기 액세스 권한이 부여됩니다. 빌드, 배포 및 기타 포드를 실행하려면 각 프로젝트에 서비스 계정이 필요합니다. 쉘 프롬프트에서 다음 oc client 명령을 입력합니다.

    oc login -u developer -p developer
    oc policy add-role-to-user view -z default
  2. OpenShift에 설치된 Fuse 템플릿을 확인합니다.

    oc get template -n openshift
  3. 다음 명령을 입력하여 Red Hat Fuse 7.11 Camel CDI를 EAP 빠른 시작으로 실행하는 데 필요한 리소스를 생성합니다. 빠른 시작에 대한 배포 구성 및 빌드 구성을 생성합니다. 빠른 시작 및 생성된 리소스에 대한 정보가 터미널에 표시됩니다.

    oc new-app s2i-fuse7-eap-camel-cdi
    
    --> Creating resources ...
        service "s2i-fuse7-eap-camel-cdi" created
        service "s2i-fuse7-eap-camel-cdi-ping" created
        route.route.openshift.io "s2i-fuse7-eap-camel-cdi" created
        imagestream.image.openshift.io "s2i-fuse7-eap-camel-cdi" created
        buildconfig.build.openshift.io "s2i-fuse7-eap-camel-cdi" created
        deploymentconfig.apps.openshift.io "s2i-fuse7-eap-camel-cdi" created
    --> Success
        Access your application via route 's2i-fuse7-eap-camel-cdi-OPENSHIFT_IP_ADDR'
        Build scheduled, use 'oc logs -f bc/s2i-fuse7-eap-camel-cdi' to track its progress.
        Run 'oc status' to view your app.
  4. 브라우저의 OpenShift 웹 콘솔로 이동합니다(https://OPENSHIFT_IP_ADDR, OPENSHIFT_IP_ADDR 을 클러스터의 IP 주소로 교체) 자격 증명으로 로그인합니다(예: 사용자 이름 개발자 및 암호, developer).
  5. 왼쪽 패널에서 을 확장합니다. 상태를 클릭하여 프로젝트 상태 페이지를 확인합니다. 선택한 네임스페이스(예: openshift)의 기존 애플리케이션이 모두 표시됩니다.
  6. s2i-fuse7-eap-camel-cdi 를 클릭하여 빠른 시작에 대한 개요 정보 페이지를 확인합니다.

    eap image s2i source 08

  7. 리소스 탭을 클릭한 다음 경로 섹션에 표시된 링크를 클릭하여 애플리케이션에 액세스합니다.

    eap image s2i source 07

    링크의 형식은 http://s2i-fuse7-eap-camel-cdi-OPENSHIFT_IP_ADDR 입니다. 브라우저에서 다음과 같은 메시지가 표시됩니다.

    Hello world from 172.17.0.3
  8. URL의 name 매개변수를 사용하여 이름을 지정할 수도 있습니다. 예를 들어 브라우저에서 http://s2i-fuse7-eap-camel-cdi-openshift.apps.cluster-name.openshift.com/?name=jdoe URL을 입력하면 응답이 표시됩니다.

    Hello jdoe from 172.17.0.3
  9. View Logs (로그 보기)를 클릭하여 애플리케이션의 로그를 확인합니다.
  10. 실행 중인 Pod를 종료하려면

    1. 개요 탭을 클릭하여 애플리케이션의 개요 정보 페이지로 돌아갑니다.
    2. 원하는 개수 옆에 있는 eap image s2i source 06 아이콘을 클릭합니다. 개수 편집 창이 표시됩니다.
    3. Pod를 중지하려면 아래쪽 화살표를 사용하여 0으로 축소합니다.

13.2. JBoss EAP 애플리케이션 구조

다음 위치에서 EAP를 사용하여 Red Hat Fuse 7.11 Camel CDI의 소스 코드를 찾을 수 있습니다.

https://github.com/wildfly-extras/wildfly-camel-examples/tree/wildfly-camel-examples-5.2.0.fuse-720021/camel-cdi

EAP에서 Camel의 디렉터리 구조는 다음과 같습니다.

  ├── pom.xml
  ├── README.md
  ├── configuration
  │   └── settings.xml
  └── src
      └── main
          ├── java
          │   └── org
          │       └── wildfly
          │           └── camel
          │               └── examples
          │                   └── cdi
          │                       └── camel
          │                           ├── MyRouteBuilder.java
          │                           ├── SimpleServlet.java
          │                           └── SomeBean.java
          └── webapp
              └── WEB-INF
                  └── beans.xml

JBoss EAP 애플리케이션을 개발하는 데 다음 파일이 중요한 위치:

pom.xml
추가 종속 항목을 포함합니다.

13.3. JBoss EAP 빠른 시작 템플릿

Fuse on JBoss EAP에서 제공되는 S2I 템플릿은 다음과 같습니다.

표 13.1. JBoss EAP S2I 템플릿

이름설명

JBoss Fuse 7.11 EAP가 포함된 Camel A-MQ (ECDHE-camel-amq-template)

camel-activemq 구성 요소를 사용하여 OpenShift에서 실행 중인 AMQ 메시지 브로커에 연결하는 방법을 보여줍니다. 브로커가 이미 배포되었다고 가정합니다.

Red Hat Fuse 7.11 Camel CDI (EAP-camel-cdi-template)

camel-cdi 구성 요소를 사용하여 CDI 빈과 Camel 경로를 통합하는 방법을 보여줍니다.

Red Hat Fuse 7.11 CXF>-<-RS(EAP-camel-cxf-jaxrs-template)

camel-cxf 구성 요소를 사용하여 ScanSetting-RS REST 서비스를 생성하고 사용하는 방법을 보여줍니다.

Red Hat Fuse 7.11 CXF>-<-WS with EAP (ECDHE-camel-cxf-jaxws-template)

camel-cxf 구성 요소를 사용하여 CloudEvent-WS 웹 서비스를 생성하고 사용하는 방법을 보여줍니다.

14장. OpenShift에서 Fuse에서 영구 스토리지 사용

OpenShift 애플리케이션의 Fuse는 영구 파일 시스템이 없는 OpenShift 컨테이너를 기반으로 합니다. 애플리케이션을 시작할 때마다 변경 불가능한 Docker 형식의 이미지를 사용하여 새 컨테이너에서 시작됩니다. 따라서 컨테이너가 중지되면 파일 시스템의 모든 영구 데이터가 손실됩니다. 그러나 애플리케이션에서는 일부 상태를 영구 저장소에 데이터로 저장해야 하며, 애플리케이션에서 공통 데이터 저장소에 대한 액세스를 공유하는 경우도 있습니다. OpenShift 플랫폼은 영구 스토리지로 외부 저장소 프로비저닝을 지원합니다.

14.1. 볼륨 및 볼륨 유형 정보

OpenShift를 사용하면 포드와 컨테이너가 여러 로컬 또는 네트워크 연결된 스토리지 끝점에서 지원하는 파일 시스템으로 볼륨을 마운트할 수 있습니다.

볼륨 유형은 다음과 같습니다.

  • emptyDir(empty directory): 기본 볼륨 유형입니다. Pod가 로컬 호스트에서 생성될 때 할당되는 디렉터리입니다. 이는 서버에 복사되지 않으며, 디렉터리가 제거된 Pod를 삭제할 때 복사되지 않습니다.
  • ConfigMap: 이름이 지정된 configmap에서 키-값 쌍으로 채워진 콘텐츠가 있는 디렉터리입니다.
  • hostpath(호스트 디렉터리): 모든 호스트에서 특정 경로가 있는 디렉터리이며 승격된 권한이 필요합니다.
  • 보안(가장된 보안): 시크릿 볼륨은 지정된 시크릿을 제공된 디렉터리에 마운트합니다.
  • PersistentVolumeClaim 또는 pvc(영구 볼륨 클레임): 컨테이너의 볼륨 디렉터리를 이름으로 할당한 영구 볼륨 클레임에 연결합니다. 영구 볼륨 클레임은 스토리지를 할당하는 요청입니다. 클레임이 바인딩되지 않으면 Pod가 시작되지 않습니다.

볼륨은 Pod 수준에서 구성되며 hostPath 를 사용하여 외부 스토리지에 직접 액세스할 수 있습니다. 따라서 여러 Pod의 공유 리소스에 대한 액세스를 hostPath 볼륨으로 관리하는 것이 더 어렵습니다.

14.2. PersistentVolumes 정보

영구 볼륨을 사용하면 클러스터 관리자가 NFS, Ceph RBD, AWS EBS(Elastic Block Store) 등과 같은 다양한 유형의 네트워크 스토리지에서 지원하는 클러스터 전체 스토리지를 프로비저닝할 수 있습니다. 또한 persistentVolume은 용량, 액세스 모드 및 재활용 정책을 지정합니다. 이를 통해 여러 프로젝트의 Pod는 기본 리소스의 특성을 고려하지 않고 영구 스토리지에 액세스할 수 있습니다.

다양한 유형의 PersistentVolumes를 생성하려면 영구 스토리지 구성을 참조하십시오.

14.3. 영구 볼륨 구성

구성 파일을 생성하여 영구 볼륨을 프로비저닝할 수 있습니다. 그런 다음 PersistentVolume Claim을 생성하여 이 스토리지에 액세스할 수 있습니다.

절차

  1. 아래 샘플 구성을 사용하여 pv.yaml 이라는 구성 파일을 생성합니다. 그러면 호스트 시스템의 경로가 pv001이라는 PersistentVolume으로 프로비저닝됩니다.

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv0001
    spec:
      accessModes:
        - ReadWriteOnce
      capacity:
        storage: 2Mi
      hostPath:
        path: /data/pv0001/

    여기서 호스트 경로는 /data/pv0001 이고 스토리지 용량이 2MB로 제한됩니다. 예를 들어 OpenShift CDK를 사용하면 OpenShift 클러스터를 호스팅하는 가상 시스템에서 /data/pv0001 디렉토리를 프로비저닝합니다.

  2. PersistentVolume 을 생성합니다.

    oc create -f pv.yaml
  3. PersistentVolume 만들기를 확인합니다. 그러면 OpenShift 클러스터에 구성된 모든 PersistentVolume 이 나열됩니다.

    oc get pv

14.4. PersistentVolumeClaims 생성

PersistentVolume 은 OpenShift 클러스터에서 이름이 지정된 엔티티로 스토리지 끝점을 노출합니다. 프로젝트에서 이 스토리지에 액세스하려면 PersistentVolume 에 액세스할 수 있는 PersistentVolumeClaims 를 생성해야 합니다. 각 프로젝트에 대해 특정 액세스 모드가 있는 특정 스토리지에 대해 사용자 지정 클레임을 사용하여 각 프로젝트에 대해 PersistentVolumeClaims 가 생성됩니다.

절차

  • 아래 샘플 구성은 pv0001이라는 PersistentVolume 에 대해 읽기-쓰기-온스 액세스를 사용하여 1MB의 스토리지용 pvc0001이라는 클레임을 생성합니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc0001
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Mi

14.5. Pod에서 영구 볼륨 사용

Pod는 볼륨 마운트를 사용하여 참조 PersistentVolumeClaims 를 정의할 파일 시스템 마운트 위치 및 볼륨을 정의합니다.

절차

  1. /usr/share/dataPersistentVolumeClaim pvc0001을 마운트하는 아래 표시된 대로 샘플 컨테이너 구성을 생성합니다.

    spec:
      template:
        spec:
          containers:
            - volumeMounts:
              - name: vol0001
                mountPath: /usr/share/data
          volumes:
            - name: vol0001
              persistentVolumeClaim:
                claimName: pvc0001

    애플리케이션이 /usr/share/data 로 작성한 모든 데이터는 이제 컨테이너를 다시 시작할 때마다 유지됩니다.

  2. OpenShift 애플리케이션의 Fuse에 있는 file gRPC/main/jkube/deployment.yml 파일에 다음 명령을 사용하여 OpenShift 리소스를 만듭니다.

    mvn oc:resource-apply
  3. 생성된 DeploymentConfiguration 에 볼륨 마운트와 볼륨이 있는지 확인합니다.

    oc describe deploymentconfig <application-dc-name>

    Fuse on OpenShift 빠른 시작의 경우 < application-dc-name >을 Maven 프로젝트 이름(예: spring-boot-camel )으로 바꿉니다.

15장. OpenShift에서 Fuse 패치

Fuse on OpenShift 제품을 최신 패치 수준으로 가져오려면 다음 작업 중 하나 이상을 수행해야 할 수 있습니다.

OpenShift 이미지에서 Fuse 패치
OpenShift 서버의 OpenShift 이미지에서 Fuse를 업데이트하여 새 애플리케이션 빌드가 패치된 버전의 Fuse 기본 이미지를 기반으로 하도록 합니다.
BOM을 사용하여 애플리케이션 종속 패치
애플리케이션이 패치된 버전의 Maven 아티팩트를 사용하도록 프로젝트 POM 파일의 종속성을 업데이트합니다.
OpenShift 템플릿에서 Fuse 패치
OpenShift 서버의 OpenShift 템플릿에서 Fuse on OpenShift 템플릿을 업데이트하여 Fuse on OpenShift 템플릿을 사용하여 생성된 새 프로젝트가 패치된 버전의 Maven 아티팩트를 사용하도록 합니다.

15.1. BOM 및 Maven 종속 항목에 대한 중요한 참고 사항

OpenShift에서 Fuse의 컨텍스트에서 애플리케이션은 Red Hat Maven 리포지토리에서 다운로드한 Maven 아티팩트를 사용하여 완전히 빌드됩니다. 따라서 애플리케이션 코드를 패치하기 위해 프로젝트의 POM 파일을 편집하여 OpenShift 패치 버전에 적절한 Fuse를 사용하도록 Maven 종속 항목을 변경하는 것입니다.

프로젝트에서 모두 동일한 패치 버전의 종속 항목을 사용하도록 OpenShift의 Fuse에 대한 모든 Maven 종속성을 함께 업그레이드하는 것이 중요합니다. OpenShift의 Fuse 프로젝트는 함께 빌드 및 테스트된 신중하게 선별된 Maven 아티팩트 세트로 구성됩니다. OpenShift 패치 수준에서 서로 다른 Fuse의 Maven 아티팩트를 혼합하여 일치시키려면 Red Hat에서 테스트하지 않고 지원되지 않는 구성으로 끝날 수 있습니다. 이 시나리오를 방지하는 가장 쉬운 방법은 Maven에서 Fuse on OpenShift에서 지원하는 모든 Maven 아티팩트 버전을 정의하는 Maven(Bill of materialss) 파일을 사용하는 것입니다. BOM 파일 버전을 업데이트할 때 프로젝트의 POM에서 모든 Fuse on OpenShift Maven 아티팩트의 버전을 자동으로 업데이트합니다.

OpenShift Maven archetype에서 Fuse on OpenShift Maven archetype 또는 OpenShift 템플릿 Fuse에 의해 생성되는 POM 파일에는 BOM 파일을 사용하고 특정 필수 플러그인의 버전을 정의하는 표준 레이아웃이 있습니다. 애플리케이션의 종속성을 패치하고 업그레이드하는 것이 훨씬 쉬워지므로 자체 애플리케이션에서 이 표준 레이아웃을 유지하는 것이 좋습니다.

15.2. OpenShift 이미지 패치 적용

Fuse on OpenShift 이미지는 주요 Fuse 제품과 독립적으로 업데이트됩니다. Fuse on OpenShift 이미지에 패치가 필요한 경우 OpenShift 이미지 스트림의 표준 Fuse에서 업데이트된 이미지를 사용할 수 있으며 registry.redhat.io 에서 업데이트된 이미지를 다운로드할 수 있습니다. OpenShift의 Fuse는 다음과 같은 이미지 스트림을 제공합니다(OpenShift 이미지 스트림 이름으로확인).

  • fuse-java-openshift-rhel8
  • fuse-java-openshift-jdk11-rhel8
  • fuse-karaf-openshift-rhel8
  • fuse-eap-openshift-jdk8-rhel7
  • fuse-eap-openshift-jdk11-rhel8
  • fuse-console-rhel8
  • fuse-apicurito-generator-rhel8
  • fuse-apicurito-rhel8

절차

  1. OpenShift 이미지 스트림의 Fuse는 일반적으로 OpenShift 서버의 openshift 프로젝트에 설치됩니다. OpenShift에서 OpenShift 이미지의 Fuse 상태를 확인하려면 관리자로 OpenShift에 로그인하고 다음 명령을 입력합니다.

    $ oc get is -n openshift
    NAME                           DOCKER REPO                                          TAGS                                    	UPDATED
    fuse-console-rhel8               172.30.1.1:5000/openshift/fuse7/fuse-console-rhel8              1.5,1.6,1.7,1.8,1.9,1.10,1.11    About an hour ago
    fuse7-eap-openshift-jdk8-rhel7   172.30.1.1:5000/openshift/fuse7/fuse-eap-openshift-jdk8-rhel7        1.5,1.6,1.7,1.8,1.9,1.10,1.11    About an hour ago
    fuse7-eap-openshift-jdk11-rhel8  172.30.1.1:5000/openshift/fuse7/fuse-eap-openshift-jdk11-rhel8        1.5,1.6,1.7,1.8,1.9,1.10,1.11    About an hour ago
    fuse7-java-openshift-rhel8       172.30.1.1:5000/openshift/fuse7/fuse-java-openshift-rhel8       1.5,1.6,1.7,1.8,1.9,1.10,1.11    About an hour ago
    fuse7-java-openshift-jdk11-rhel8 172.30.1.1:5000/openshift/fuse7/fuse-java-openshift-jdk11-rhel8       1.5,1.6,1.7,1.8,1.9,1.10,1.11    About an hour ago
    fuse7-karaf-openshift-rhel8      172.30.1.1:5000/openshift/fuse7/fuse-karaf-openshift-rhel8      1.5,1.6,1.7,1.8,1.9,1.10,1.11    About an hour ago
    fuse-apicurito-generator-rhel8   172.30.1.1:5000/openshift/fuse7/fuse-apicurito-generator-rhel8   1.5,1.6,1.7,1.8,1.9,1.10,1.11    About an hour ago
    apicurito-ui-rhel8               172.30.1.1:5000/openshift/fuse7/apicurito-ui-rhel8               1.5,1.6,1.7,1.8,1.9,1.10,1.11    About an hour ago
  2. 이제 각 이미지 스트림을 한 번에 하나씩 업데이트할 수 있습니다.

    oc import-image -n openshift fuse7/fuse7-java-openshift-rhel8:1.11
    oc import-image -n openshift fuse7/fuse7-java-openshift-jdk11-rhel8:1.11
    oc import-image -n openshift fuse7/fuse7-karaf-openshift-rhel8:1.11
    oc import-image -n openshift fuse7/fuse7-eap-openshift-jdk8-rhel7:1.11
    oc import-image -n openshift fuse7/fuse7-eap-openshift--jdk11-rhel8:1.11
    oc import-image -n openshift fuse7/fuse7-console-rhel8:1.11
    oc import-image -n openshift fuse7/apicurito-ui-rhel8:1.11
    oc import-image -n openshift fuse7/fuse-apicurito-generator-rhel8:1.11
참고

이미지 스트림의 버전 태그에는 1.9-<BUILDNUMBER> 형식이 있습니다. 태그를 1.9 로 지정하면 1.9 스트림에 최신 빌드가 표시됩니다.

참고

OpenShift 이미지의 새 Fuse를 사용할 수 있을 때마다 다시 빌드가 자동으로 트리거되도록 Fuse 애플리케이션을 구성할 수도 있습니다. 자세한 내용은 빌드 OpenShift Container Platform 설명서에서 빌드 트리거 및 수정 섹션을 참조하십시오.

15.3. OpenShift 템플릿 패치 적용

올바른 패치 종속 항목을 사용하여 새 템플릿 기반 프로젝트를 빌드하려면 OpenShift 템플릿의 Fuse를 최신 패치 수준으로 업데이트해야 합니다.

절차

  1. OpenShift에서 Fuse 템플릿을 업데이트하려면 관리자 권한이 필요합니다. 다음과 같이 OpenShift 서버에 관리자로 로그인합니다.

    oc login URL -u ADMIN_USER -p ADMIN_PASS

    여기서 URL 은 OpenShift 서버의 URL이고 ADMIN_USER,ADMIN_PASS 는 OpenShift 서버에 있는 관리자 계정의 자격 증명입니다.

  2. OpenShift 템플릿에 패치된 Fuse를 설치합니다. 명령 프롬프트에서 다음 명령을 입력합니다.

    BASEURL=https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002
    
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/eap-camel-amq-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/eap-camel-cdi-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/eap-camel-cxf-jaxrs-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/eap-camel-cxf-jaxws-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/karaf-camel-amq-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/karaf-camel-log-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/karaf-camel-rest-sql-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/karaf-cxf-rest-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/spring-boot-camel-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/spring-boot-camel-amq-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/spring-boot-camel-config-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/spring-boot-camel-drools-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/spring-boot-camel-infinispan-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/spring-boot-camel-xml-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/spring-boot-cxf-jaxrs-template.json
    oc replace --force -n openshift -f ${BASEURL}/quickstarts/spring-boot-cxf-jaxws-template.json
    참고

    BASEURL 은 빠른 시작 템플릿을 저장하는 Git 리포지토리의 GA 분기를 가리킵니다. HEAD 에 항상 최신 템플릿이 있습니다. 이전 명령을 실행할 때마다 최신 버전의 템플릿을 가져옵니다.

15.4. BOM을 사용하여 애플리케이션 종속 패치

애플리케이션 pom.xml 파일이 새로운 스타일 BOM을 사용하도록 구성된 경우 이 섹션의 지침에 따라 Maven 종속성을 업그레이드하십시오.

15.4.1. Spring Boot 애플리케이션에서 종속성 업데이트

다음 코드 조각은 OpenShift의 Fuse에서 Spring Boot 애플리케이션에 대한 POM 파일의 표준 레이아웃을 보여주고 몇 가지 중요한 속성 설정을 강조합니다.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project ...>
  ...
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

    <fuse.version>7.11.1.fuse-sb2-7_11_1-00022-redhat-00002</fuse.version>
    ...
  </properties>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.redhat-fuse</groupId>
        <artifactId>fuse-springboot-bom</artifactId>
        <version>${fuse.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  ...
  <build>
    ...
    <plugins>
      <!-- Core plugins -->
      ...
      <plugin>
        <groupId>org.jboss.redhat-fuse</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        ...
        <version>${fuse.version}</version>
      </plugin>
    </plugins>
  </build>

  <profiles>
    <profile>
      <id>openshift</id>
      <build>
        <plugins>
          <plugin>
            <groupId>org.jboss.redhat-fuse</groupId>
            <artifactId>openshift-maven-plugin</artifactId>
            ...
            <version>${fuse.version}</version>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>
</project>

애플리케이션을 패치하거나 업그레이드하는 경우 다음 버전 설정이 중요합니다.

Fuse.version
새로운 스타일 fuse-springboot-bom BOM 버전과 openshift-maven-plugin 플러그인 및 spring-boot-maven-plugin 플러그인의 버전을 정의합니다.

15.4.2. Karaf 애플리케이션에서 종속성 업데이트

다음 코드 조각은 OpenShift의 Fuse에서 Karaf 애플리케이션에 대한 POM 파일의 표준 레이아웃을 보여주고 몇 가지 중요한 속성 설정을 강조합니다.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project ...>
  ...
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

    <fuse.version>7.11.1.fuse-sb2-7_11_1-00022-redhat-00002</fuse.version>
    ...
  </properties>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.redhat-fuse</groupId>
        <artifactId>fuse-karaf-bom</artifactId>
        <version>${fuse.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>org.jboss.redhat-fuse</groupId>
        <artifactId>karaf-maven-plugin</artifactId>
        <version>${fuse.version}</version>
        ...
      </plugin>
      ...
      <plugin>
        <groupId>org.jboss.redhat-fuse</groupId>
        <artifactId>openshift-maven-plugin</artifactId>
        <version>${fuse.version}</version>
        ...
      </plugin>
    </plugins>
  </build>

</project>

애플리케이션을 패치하거나 업그레이드하는 경우 다음 버전 설정이 중요합니다.

Fuse.version
새로운 스타일 fuse-karaf-bom BOM 버전과 openshift-maven-plugin 플러그인의 버전을 정의합니다.

15.4.3. JBoss EAP 애플리케이션에서 종속성 업데이트

다음 코드 조각은 OpenShift의 Fuse에서 JBoss EAP 애플리케이션에 대한 POM 파일의 표준 레이아웃을 보여주고 몇 가지 중요한 속성 설정을 강조합니다.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project ...>
  ...
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

    <fuse.version>7.11.1.fuse-sb2-7_11_1-00022-redhat-00002</fuse.version>
    ...
  </properties>

  <!-- Dependency Management -->
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.redhat-fuse</groupId>
        <artifactId>fuse-eap-bom</artifactId>
        <version>${fuse.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  ...
</project>

애플리케이션을 패치하거나 업그레이드하는 경우 다음 버전 설정이 중요합니다.

Fuse.version
fuse-eap-bom BOM 파일 버전 (이전 스타일 wildfly-camel-bom BOM 파일을 대체함)을 정의합니다. BOM 버전을 특정 패치 버전으로 업데이트하면 JBoss EAP Maven의 모든 Fuse 종속성도 효과적으로 업데이트할 수 있습니다.

15.5. 사용 가능한 BOM 버전

다음 표는 Red Hat Fuse의 다양한 패치 릴리스에 해당하는 새로운 스타일 BOM 버전을 보여줍니다.

표 15.1. Red Hat Fuse 릴리스 및 새 Style BOM 버전 수정

Red Hat Fuse 릴리스org.jboss.redhat-fuse BOM 버전

Red Hat Fuse 7.11 GA

7.11.1.fuse-sb2-7_11_1-00022-redhat-00002

Red Hat Fuse 7.0.1 패치

7.0.1.fuse-000008-redhat-4

애플리케이션 POM을 특정 Red Hat Fuse 패치 릴리스로 업그레이드하려면 fuse.version 속성을 해당 BOM 버전으로 설정합니다.

16장. OpenShift에서 Fuse 설치 제거

OpenShift에서 Fuse를 설치 제거하려면 oc delete 명령을 사용하여 registry.redhat.io 에서 이미지 스트림 및 템플릿을 제거합니다.

16.1. OpenShift 4.x 서버에서 Fuse 이미지 스트림 및 템플릿 설치 제거

절차

+ 버전의 BASEURL 을 찾아 아래 명령에서 사용할 변수로 정의합니다.

+

BASEURL=https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002
  1. Spring Boot 2 빠른 시작 템플릿을 삭제합니다.

    for template in spring-boot-2-camel-amq-template.json \
     spring-boot-2-camel-config-template.json \
     spring-boot-2-camel-drools-template.json \
     spring-boot-2-camel-infinispan-template.json \
     spring-boot-2-camel-rest-3scale-template.json \
     spring-boot-2-camel-rest-sql-template.json \
     spring-boot-2-camel-template.json \
     spring-boot-2-camel-xa-template.json \
     spring-boot-2-camel-xml-template.json \
     spring-boot-2-cxf-jaxrs-template.json \
     spring-boot-2-cxf-jaxws-template.json \
     spring-boot-2-cxf-jaxrs-xml-template.json \
     spring-boot-2-cxf-jaxws-xml-template.json ;
     do oc delete -n openshift -f \
     ${BASEURL}/quickstarts/${template}
     done
  2. OpenShift 빠른 시작 템플릿에서 Fuse를 삭제합니다.

    for template in eap-camel-amq-template.json \
     eap-camel-cdi-template.json \
     eap-camel-cxf-jaxrs-template.json \
     eap-camel-cxf-jaxws-template.json \
     karaf-camel-amq-template.json \
     karaf-camel-log-template.json \
     karaf-camel-rest-sql-template.json \
     karaf-cxf-rest-template.json ;
     do
     oc delete -n openshift -f \
     ${BASEURL}/quickstarts/${template}
     done
  3. 이미지 스트림을 삭제합니다.

    oc delete -n openshift -f ${BASEURL}/fis-image-streams.json
  4. Samples Operator에서 항목을 제거합니다.

    Samples Operator의 구성을 편집합니다.

    oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator
  5. skippedImagestreamsskippedTemplates 섹션에서 Fuse 및 Spring Boot 2 템플릿을 제거합니다.
기본 제공 이미지 스트림

일부 이미지 스트림 및 템플릿은 일반적인 사용 사례에 기본적으로 제공됩니다. 샘플 Operator에 의해 관리되므로 수동으로 제거할 수 없습니다. 제거하는 동안 무시할 수 있습니다.

기본 제공 이미지 스트림은 매니페스트에서 samples.operator.openshift.io/managed: "true" 라벨을 사용하여 구성되므로 oc getgrep 명령으로 관리되는지 확인할 수 있습니다.

예제

]$ oc get is fuse7-eap-openshift -n openshift -o yaml | grep 'samples.operator.openshift.io/managed'
    samples.operator.openshift.io/managed: "true"
]$

부록 A. Spring Boot Maven 플러그인

Spring Boot Maven 플러그인은 Maven에서 Spring Boot 지원을 제공하며, 실행 가능한 CloudEvent 또는 War 아카이브를 패키징하고 애플리케이션을 현재 위치에서 실행할 수 있습니다.

A.1. Spring Boot Maven 플러그인 목표

Spring Boot Maven 플러그인은 다음과 같은 목표를 포함합니다.

  • Spring-boot:run 은 Spring Boot 애플리케이션을 실행합니다.
  • spring-boot:repackages your .jar and .war files to be executable.
  • Spring -boot:startspring-boot:stop 둘 다 Spring Boot 애플리케이션의 라이프사이클을 관리하는 데 사용됩니다.
  • spring-boot:build-info 는 액추에이터에서 사용할 수 있는 빌드 정보를 생성합니다.

A.2. Spring Boot Maven 플러그인 사용

Spring Boot 플러그인을 사용하는 방법에 대한 일반적인 지침은 https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using 에서 확인할 수 있습니다. 다음 예제에서는 Spring Boot에 spring-boot-maven-plugin 을 사용하는 방법을 보여줍니다.

참고

Spring Boot Maven 플러그인에 대한 자세한 내용은 https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/ 링크를 참조하십시오.

A.2.1. Spring Boot 2용 Spring Boot Maven 플러그인 사용

다음 예제에서는 Spring Boot 2에 spring-boot-maven-plugin 을 사용하는 방법을 보여줍니다.

예제

<project>
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.redhat.fuse</groupId>
  <artifactId>spring-boot-camel</artifactId>
  <version>1.0-SNAPSHOT</version>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

        <!-- configure the Fuse version you want to use here -->
        <fuse.bom.version>7.11.1.fuse-sb2-7_11_1-00022-redhat-00002</fuse.bom.version>

        <!-- maven plugin versions -->
        <maven-compiler-plugin.version>3.7.0</maven-compiler-plugin.version>
        <maven-surefire-plugin.version>2.19.1</maven-surefire-plugin.version>
    </properties>


    <build>
        <defaultGoal>spring-boot:run</defaultGoal>

        <plugins>
            <plugin>
                <groupId>org.jboss.redhat-fuse</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <version>${fuse.bom.version}</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>repackage</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

    <repositories>
        <repository>
            <id>redhat-ga-repository</id>
            <url>https://maven.repository.redhat.com/ga</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
        <repository>
            <id>redhat-ea-repository</id>
            <url>https://maven.repository.redhat.com/earlyaccess/all</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
    </repositories>

    <pluginRepositories>
        <pluginRepository>
            <id>redhat-ga-repository</id>
            <url>https://maven.repository.redhat.com/ga</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </pluginRepository>
        <pluginRepository>
            <id>redhat-ea-repository</id>
            <url>https://maven.repository.redhat.com/earlyaccess/all</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </pluginRepository>
    </pluginRepositories>
</project>

부록 B. Karaf Maven 플러그인 사용

karaf-maven-plugin 을 사용하면 Karaf 컨테이너의 마이크로 서비스 스타일 패키징인 Karaf 서버 어셈블리를 만들 수 있습니다. 완료된 어셈블리에는 Karaf 설치의 모든 필수 구성 요소(etc/, data/, lib 및 system 디렉터리 포함)의 모든 필수 구성 요소가 포함되어 있지만 애플리케이션을 실행하는 데 필요한 최소 수준으로 제거됩니다.

B.1. Maven 종속 항목

karaf-assembly 프로젝트의 Maven 종속성은 기능 리포지토리(classifier 기능) 또는 kar 아카이브입니다.

  • 기능 리포지토리는 maven 구조화된 시스템/내부 리포지토리에 설치됩니다.
  • Kar 아카이브에는 서버 상단에 컨텐츠가 압축 해제되어 있으며 포함된 기능 리포지토리가 설치되어 있습니다.

Maven 종속성 범위

종속성의 Maven 범위는 기능 리포지토리가 기능 구성 파일 etc/org.apache.karaf.features.cfg ( featuresRepositories 속성)에 나열되어 있는지 확인합니다. 이러한 범위는 다음과 같습니다.

  • compile(기본값): 리포지토리의 모든 기능(또는 kar 아카이브)이 startup.properties 에 설치됩니다. 기능 리포지토리는 기능 서비스 구성 파일에 나열되지 않습니다.
  • 런타임: karaf-maven-plugin 의 부팅 단계 .
  • 제공됨: karaf-maven-plugin 의 설치 단계에 해당합니다.

B.2. Karaf Maven 플러그인 구성

karaf-maven-plugin 은 Maven 범위와 관련된 세 가지 단계를 정의합니다. 플러그인 구성은 설치된 기능 저장소의 기능을 참조하여 이러한 요소를 사용하여 기능을 설치하는 방법을 제어합니다.

  • 시작 단계: etc/startup.properties

    이 단계에서는 시작 기능, 시작 프로필 및 시작 번들을 사용하여 etc/startup.properties 에 포함될 번들 목록을 준비합니다. 이렇게 하면 적절한 시작 수준에서 기능 번들이 etc/startup.properties 에 나열되고 시스템 내부 리포지토리에 복사되는 번들이 표시됩니다. feature_name 또는 feature_name/feature_version 형식을 사용할 수 있습니다(예: < startupFeature>foo</startupFeature > ).

  • 부팅 단계: etc/org.apache.karaf.features.cfg

    이 단계에서는 featuresBoot 속성 및 리포지토리의 featuresRepositories 속성에서 사용 가능한 기능을 관리합니다. 그러면 기능 이름이 기능 서비스 구성 파일의 boot-features에 추가되고 시스템 내부 리포지토리에 복사된 기능의 모든 번들이 추가됩니다. feature_name 또는 feature_name/feature_version 형식을 사용할 수 있습니다(예: < bootFeature>bar</bootFeature > ).

  • 설치 단계:

    이 단계에서는 ${karaf.home}/${karaf.default.repository} 에 아티팩트를 설치합니다. 그러면 시스템의 내부 리포지토리에 설치된 기능의 모든 번들이 생성됩니다. 따라서 런타임 시 외부 리포지토리에 액세스하지 않고 기능을 설치할 수 있습니다. feature_name 또는 feature_name/feature_version 형식을 사용할 수 있습니다(예: < installedFeature>baz</installedFeature >).

  • 라이브러리

    플러그인은 라이브러리 URL을 지정하는 라이브러리 하위 요소가 하나 이상 있을 수 있는 라이브러리 요소를 허용합니다.

    예제

    <libraries>
        <library>mvn:org.postgresql/postgresql/9.3-1102-jdbc41;type:=endorsed</library>
    </libraries>

B.3. 사용자 정의 Karaf 어셈블리

Karaf 서버 어셈블리를 생성하는 권장 방법은 karaf-maven-plugin 에서 제공하는 karaf:assembly 목표를 사용하는 것입니다. 이렇게 하면 프로젝트의 pom.xml 파일에 Maven 종속 항목에서 서버가 어셈블됩니다. karaf-maven-plugin 구성에 지정된 번들(또는 기능)과 pom.xml 의 < dependencies > 섹션에 지정된 종속성은 사용자 지정 karaf 어셈블리에 들어갈 수 있습니다.

  • kar의 경우

    kar 유형의 종속성은 시작(scope=컴파일), 부팅(scope=runtime) 또는 karaf-maven-plugin에서 설치된 (scope=provided) kars로 추가됩니다. kars는 작업 디렉터리(target/assembly)에 압축을 풀며 기능 XML이 추가 기능 리포지토리(해당 kar의 단계)로 검색 및 사용됩니다.

  • features.xml의 경우

    기능 분류기를 사용하는 종속성은 karaf-maven-plugin에서 시작 (scope=compile), 부팅 (scope=runtime) 또는 설치된 (scope=provided) 리포지토리로 사용됩니다. kar에서 발견된 기능 리포지토리를 명시적으로 추가할 필요가 없습니다.

  • ScanSetting 및 번들의 경우

    번들 유형이 있는 종속성은 시작(scope=컴파일), 부팅(scope=runtime) 또는 karaf-maven-plugin에 설치된 (scope=provided) 번들로 사용됩니다.

B.3.1. Karaf:assembly 목표

karaf-maven-plugin 에서 제공하는 karaf:assembly 목표를 사용하여 Karaf 서버 어셈블리를 생성할 수 있습니다. 이 목표는 프로젝트 POM의 Maven 종속 항목에서 마이크로 서비스 스타일 서버 어셈블리를 어셈블합니다. Fuse on OpenShift 프로젝트에서 karaf:assembly 목표를 Maven 설치 단계에 바인딩하는 것이 좋습니다. 프로젝트는 번들 패키징을 사용하며 프로젝트 자체는 bootBundles 요소 내부에 나열하여 Karaf 컨테이너에 설치됩니다.

참고

시작 단계에서 karaf 프레임워크 기능과 같은 필요한 요소만 포함합니다. etc/startup.properties 에 들어갈 것이며 이 단계에서는 karaf 기능 서비스가 완전히 시작되지 않습니다. 부팅 단계의 다른 요소를 지연시킵니다.

예제

다음 예제는 빠른 시작에 일반적인 Maven 구성을 표시합니다.

<plugin>
  <groupId>org.jboss.redhat-fuse</groupId>
  <artifactId>karaf-maven-plugin</artifactId>
  <version>${fuse.version}</version>
  <extensions>true</extensions>
  <executions>
    <execution>
      <id>karaf-assembly</id>
      <goals>
        <goal>assembly</goal>
      </goals>
      <phase>install</phase>
    </execution>
  </executions>
  <configuration>

    <karafVersion>{karafMavenPluginVersion}</karafVersion>
    <useReferenceUrls>true</useReferenceUrls>
    <archiveTarGz>false</archiveTarGz>
    <includeBuildOutputDirectory>false</includeBuildOutputDirectory>
    <startupFeatures>
      <feature>karaf-framework</feature>
            </startupFeatures>
            <bootFeatures>
      <feature>shell</feature>
      <feature>jaas</feature>
      <feature>aries-blueprint</feature>
      <feature>camel-blueprint</feature>
      <feature>fabric8-karaf-blueprint</feature>
      <feature>fabric8-karaf-checks</feature>
    </bootFeatures>
    <bootBundles>
      <bundle>mvn:${project.groupId}/${project.artifactId}/${project.version}</bundle>
    </bootBundles>
  </configuration>
</plugin>

부록 C. OpenShift Maven 플러그인

OpenShift Maven 플러그인은 OpenShift용 Java 애플리케이션을 빌드하고 배포하는 데 사용됩니다. Java 애플리케이션을 OpenShift로 가져옵니다. 이를 통해 maven에 긴밀하게 통합할 수 있으며 이미 제공된 빌드 구성의 이점을 활용할 수 있습니다. 다음 세 가지 작업에 중점을 둡니다.

  • S2I 이미지 빌드
  • OpenShift 리소스 생성
  • OpenShift에서 애플리케이션 배포

C.1. OpenShift Maven 플러그인 정보

OpenShift Maven 플러그인에는 다음과 같은 기능이 있습니다.

  • S2I 이미지를 처리하여 유연하고 강력한 구성을 상속합니다.
  • 두 OpenShift 설명자 지원
  • OpenShift Docker는 바이너리 소스를 사용하여 빌드(Docker 데몬에 대한 직접 이미지 빌드 대신)
  • mulitple 설정 스타일:

    • 예상 기본값이 미리 선택되어 있는 빠른 완화 기능을 위한 제로 구성입니다.
    • 플러그인 구성 내 인라인 구성의 XML 구문.
    • 플러그인에 의해 보강되는 실제 배포 설명자의 외부 구성 템플릿입니다.
  • 유연한 사용자 정의:

    • 생성기는 Maven 빌드 및 생성된 자동 Docker 이미지 구성을 분석합니다(spring-boot, 일반 java, karaf)
    • Enrichers는 SCM 레이블과 같은 추가 정보로 OpenShift 리소스 설명자를 확장하고 Services와 같은 기본 오브젝트를 추가할 수 있습니다.
    • 생성기 및 Enrichers는 개별적으로 구성하고 프로필에 결합할 수 있습니다.

C.2. 이미지 빌드

oc:build 목표는 애플리케이션이 포함된 Docker 형식의 이미지를 생성하는 데 사용됩니다. 그런 다음 나중에 Kubernetes 또는 OpenShift에 배포할 수 있습니다. 이 플러그인은 maven-assembly-plugin 의 어셈블리 설명자 형식을 사용하여 이미지에 추가할 콘텐츠를 지정합니다. 그런 다음 이러한 이미지는 oc:push 를 사용하여 공개 또는 프라이빗 Docker 레지스트리로 내보낼 수 있습니다. oc:watch 목표를 사용하면 코드 변경 사항에 대응하여 이미지를 자동으로 다시 생성하거나 실행 중인 컨테이너에 새 아티팩트를 복사할 수 있습니다.

C.3. Kubernetes 및 OpenShift 리소스

Kubernetes 및 OpenShift 리소스 설명자는 oc:resource 를 사용하여 생성할 수 있습니다. 이러한 파일은 Maven 아티팩트 내에서 패키지화되며 oc:apply 를 사용하여 실행 중인 오케스트레이션 플랫폼에 배포할 수 있습니다.

설정

구성 수준은 다음 4가지가 있습니다.

  • Zero-Config 모드는 pom.xml 파일에 존재하는 내용, 사용할 기본 이미지 또는 노출할 포트를 기반으로 매우 유용한 결정을 내릴 수 있습니다. 작업을 시작하고 빠른 시작 애플리케이션을 작고 깔끔하게 유지하는 데 사용됩니다.
  • XML 플러그인 구성 모드는 docker-maven-plugin이 제공하는 것과 유사합니다. IDE 지원을 통해 유형 안전 구성을 허용하지만 가능한 리소스 설명자 기능의 하위 집합만 제공됩니다.
  • Kubernetes 및 OpenShift 리소스 조각은 플러그인에 의해 보강될 수 있는 사용자가 제공하는 YAML 파일입니다. 이를 통해 전문가 사용자는 일반 구성 파일을 모든 기능과 함께 사용하여 프로젝트별 빌드 정보를 추가하고 상용구 코드를 방지할 수 있습니다.
  • Docker Compose는 OpenShift 클러스터에서 Docker 작성 배포를 가져오는 데 사용됩니다. 이 경우 최소한 OpenShift 배포 프로세스에 대한 지식이 필요하지 않습니다.

C.4. OpenShift Maven 플러그인 설치

이 플러그인은 Maven 중앙 리포지토리에서 사용할 수 있으며 아래와 같이 사전 및 후부 단계에 연결할 수 있습니다. 기본적으로 Maven은 org.apache.maven.plugins 및 org.codehaus.mojo 패키지에서만 플러그인을 검색합니다. JKube 플러그인 목표에 대한 공급자를 확인하려면 ~/.m2/settings.xml 파일을 편집하고 <pluginGroups> 구성으로 org.eclipse.jkube 네임스페이스를 추가합니다.

절차

  • OpenShift Maven 플러그인을 사전 및 통합 단계에 연결하려면 ~/.m2/settings.xml 파일에 다음을 추가합니다.
<settings>
      ...

      <pluginGroups>
        <pluginGroup>org.jboss.redhat-fuse</pluginGroup>
      </pluginGroups>

      ...
</settings>

<plugin>
  <groupId>org.jboss.redhat-fuse</groupId>
  <artifactId>openshift-maven-plugin</artifactId>
  <version>${fuse.version}</version>

  <configuration>
     ....
     <images>
        <!-- A single's image configuration -->
        <image>
          ...
          <build>
           ....
          </build>
        </image>
        ....
     </images>
  </configuration>

  <!-- Connect oc:resource, oc:build and oc:helm to lifecycle phases -->
  <executions>
    <execution>
       <id>jkube</id>
       <goals>
         <goal>resource</goal>
         <goal>build</goal>
         <goal>helm</goal>
       </goals>
    </execution>
  </executions>
</plugin>

C.5. OpenShift Maven 플러그인 이해 목표

빌드 목표는 Docker 형식의 이미지 또는 S2I 빌드와 같은 Kubernetes 및 OpenShift 빌드 아티팩트를 생성하고 관리하는 데 사용됩니다.

표 C.1. OpenShift Maven 플러그인 빌드 목표

목표설명

oc:resource

Kubernetes 또는 OpenShift 리소스 설명자를 생성합니다. 생성된 리소스는 target/classes/META-INF/jkube/openshift 디렉터리에 있습니다.

oc:build

이미지 빌드.

oc:push

이미지를 레지스트리로 푸시합니다. 내보낼 레지스트리는 기본적으로 docker.io이지만 이미지 이름의 일부로 지정할 수 있습니다.

oc:apply

실행 중인 클러스터에 리소스를 적용합니다. 이 목표는 oc:deploy와 유사하지만 전체 배포 주기는 수행하지 않습니다.

C.6. OpenShift Maven 플러그인 개발 목표 이해

개발 목표는 개발 클러스터에 리소스 설명자를 배포하는 데 사용됩니다. 또한 개발 클러스터의 라이프사이클을 관리하는 데 도움이 됩니다.

표 C.2. OpenShift Maven 플러그인 개발 목표

목표설명

oc:deploy

리소스를 생성하고 앱을 빌드한 후 클러스터에 리소스 설명자를 배포합니다. oc:apply와 동일하며 백그라운드에서 실행됩니다.

oc:undeploy

클러스터에서 리소스 설명자를 배포 취소하고 제거합니다.

oc:log

실행 중인 애플리케이션의 로그를 표시합니다.

oc:debug

원격 디버깅을 활성화합니다.

oc:watch

파일 변경 사항을 조사하고 다시 빌드 및 재배포를 수행합니다.

부록 D. Camel Maven 플러그인

camel-maven 플러그인을 사용하여 소스 코드에서 모든 Camel 엔드포인트의 유효성을 확인할 수 있습니다. 이를 통해 Camel 애플리케이션 또는 단위 테스트를 실행하기 전에 끝점이 유효한지 확인할 수 있습니다.

D.1. Camel Maven 플러그인 목표

소스 코드에서 Camel 끝점의 유효성을 검증하기 위해

  • Camel:validate: 이 목표는 Maven 프로젝트 소스 코드를 검증하여 잘못된 camel 엔드포인트 URI를 확인합니다.

D.2. 프로젝트에 camel-maven 플러그인 추가

프로젝트의 pom.xml 파일에 camel-maven 플러그인을 프로젝트에 추가할 수 있습니다.

절차

  1. 플러그인을 활성화하려면 pom.xml 파일에 다음을 추가합니다.

    <plugin>
        <groupId>org.jboss.redhat-fuse</groupId>
        <artifactId>camel-maven-plugin</artifactId>
        <version>${fuse.bom.version}</version>
    </plugin>
  2. 명령줄 또는 Java 편집기에서 검증 목표를 실행합니다.

    mvn camel:validate

플러그인을 자동으로 실행

플러그인은 빌드의 일부로 자동으로 실행되도록 설정하여 오류를 추적할 수 있습니다. 단계는 플러그인이 실행되는 시기를 결정합니다.

다음 예에서 플러그인은 기본 소스 코드 컴파일 후 실행되는 process-classes 단계에서 실행됩니다.

예제

<plugin>
    <groupId>org.jboss.redhat-fuse</groupId>
    <artifactId>camel-maven-plugin</artifactId>
    <version>7.11.0.fuse-sb2-7_11_0-00028-redhat-00001</version>
    <executions>
        <execution>
            <phase>process-classes</phase>
                <goals>
                    <goal>validate</goal>
                </goals>
        </execution>
    </executions>
</plugin>

테스트 소스 코드 검증

단계를 process-test-classes 로 변경하여 테스트 소스 코드의 유효성을 검사하도록 maven 플러그인을 구성할 수 있습니다.

예제

<plugin>
    <groupId>org.jboss.redhat-fuse</groupId>
    <artifactId>camel-maven-plugin</artifactId>
    <version>7.11.0.fuse-sb2-7_11_0-00028-redhat-00001</version>
    <executions>
        <execution>
          <configuration>
            <includeTest>true</includeTest>
          </configuration>
            <phase>process-test-classes</phase>
                <goals>
                    <goal>validate</goal>
                </goals>
        </execution>
    </executions>
</plugin>

D.3. Maven 프로젝트에서 목표 실행

pom.xml 파일에 플러그인을 추가하지 않고 모든 Maven 프로젝트에서 validate 목표를 실행할 수도 있습니다. 정규화된 이름을 사용하여 플러그인을 지정해야 합니다.

절차

  • Apache Camel의 camel-example-cdi 플러그인에서 목표를 실행하려면 다음 명령을 실행합니다.

        $cd camel-example-cdi
        $mvn org.apache.camel:camel-maven-plugin:7.11.0.fuse-sb2-7_11_0-00028-redhat-00001:validate

    그러면 다음 출력이 표시됩니다.

    [INFO] ------------------------------------------------------------------------
    [INFO] Building Camel :: Example :: CDI 2.16.2
    [INFO] ------------------------------------------------------------------------
    [INFO]
    [INFO] --- fabric8-camel-maven-plugin:2.3.80:validate (default-cli) @ camel-example-cdi ---
    [INFO] Endpoint validation success: (4 = passed, 0 = invalid, 0 = incapable, 0 = unknown components)
    [INFO] Simple validation success: (0 = passed, 0 = invalid)
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------

검증을 성공적으로 통과하면 4개의 끝점을 검증할 수 있습니다. 다음 예제에서는 유효성을 검사하는 방법을 보여주고 필요한 경우 camel 엔드포인트를 수정합니다.

예제

소스 코드의 Camel 엔드포인트 URI 중 하나로 오타를 입력했다고 가정하겠습니다. 다음과 같습니다.

  1. 올바른 Camel 엔드 포인트 URI는 다음과 같습니다.

      @Uri("timer:foo?period=5000")
  2. period 옵션에 오타 오류를 포함하도록 변경할 수 있습니다. 예를 들면 다음과 같습니다.

      @Uri("timer:foo?perid=5000")
  3. 검증 목표를 다시 실행합니다.

    [INFO] ------------------------------------------------------------------------
    [INFO] Building Camel :: Example :: CDI 2.16.2
    [INFO] ------------------------------------------------------------------------
    [INFO]
    [INFO] --- org.apache.camel:camel-maven-plugin:7.11.0.fuse-sb2-7_11_0-00028-redhat-00001:validate (default-cli) @ camel-example-cdi ---
    [WARNING] Endpoint validation error at: org.apache.camel.example.cdi.MyRoutes(MyRoutes.java:32)
    
    	timer:foo?perid=5000
    
    	                   perid    Unknown option. Did you mean: [period]
    
    
    [WARNING] Endpoint validation error: (3 = passed, 1 = invalid, 0 = incapable, 0 = unknown components)
    [INFO] Simple validation success: (0 = passed, 0 = invalid)
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------

    위에 표시된 대로 camel 끝점 URI에 오류가 표시됩니다.

D.4. 옵션

maven 플러그인은 명령행에서 구성하거나 ( -D 구문 사용) < configuration > 태그의 pom.xml 파일에 정의할 수 있는 다음 옵션을 지원합니다.

표 D.1. Camel Maven 플러그인 옵션

매개변수Default설명주석

downloadVersion

true

인터넷에서 Camel 카탈로그 버전을 다운로드할 수 있습니다.

프로젝트에서 플러그인 기본값과 다른 Camel 버전을 사용하는 경우 를 사용합니다.

failOnError

false

잘못된 Camel 엔드 포인트를 발견한 경우 실패합니다.

기본적으로 플러그인은 WARN 수준의 오류를 기록합니다.

logUnparseable

false

구문 분석할 수 없으므로 확인할 수 없는 로그 끝점 URI입니다.

 

includeJava

true

Camel 엔드포인트 검증에 Java 파일을 포함합니다.

includesexcludes 도 참조하십시오.

includeXML

true

Camel 엔드포인트 검증에 XML 파일을 포함합니다.

includesexcludes 도 참조하십시오.

includeTest

false

검증에 테스트 소스 코드를 포함합니다.

 

includes

-

유효성 검사에 포함할 java 및 xml 파일 이름을 필터링하는 와일드카드 및 정규식 패턴입니다.

여러 값을 쉼표로 구분할 수 있습니다.

excludes

-

유효성 검사에서 제외할 java 및 xml 파일을 필터링하는 와일드카드 및 정규식 패턴입니다.

여러 값을 쉼표로 구분할 수 있습니다.

ignoreUnknownComponent

true

알 수 없는 구성 요소를 무시합니다.

 

ignoreIncapable

true

끝점 URI를 구문 분석할 수 없는 것을 무시합니다.

 

ignoreLenientProperties

true

사용자 지정 매개 변수를 가질 수 있도록 lenient 속성을 사용하는 구성 요소를 무시합니다.

기본적으로 URI 유효성 검사는 구성 요소에 포함되지 않은 속성에서 실패합니다. (예: 끝점 URI에 쿼리 매개변수를 제공하는 데 사용되는 HTTP 구성 요소)

showAll

false

모든 끝점과 간단한 표현식을 표시합니다.

invalid 및 valid 둘 다 표시됩니다.

D.5. 검증에는 다음이 포함됩니다.

Maven 프로젝트가 있는 경우 플러그인을 실행하여 단위 테스트 소스 코드에서 엔드포인트를 검증할 수 있습니다.

절차

  • -D 를 사용하여 옵션을 전달합니다.
$cd myproject

$mvn org.apache.camel:camel-maven-plugin:7.11.0.fuse-sb2-7_11_0-00028-redhat-00001:validate -DincludeTest=true

부록 E. JVM 환경 변수 사용자 정의

JVM 환경 변수를 사용하여 OpenShift 이미지에서 Fuse의 모든 옵션을 설정할 수 있습니다.

E.1. OpenJDK 8을 사용하여 S2I Java 빌더 이미지 사용

S2I Java 빌더 이미지를 사용하면 다른 애플리케이션 서버를 사용하지 않고 결과를 직접 실행할 수 있습니다. 이 S2I 이미지는 플랫 클래스 경로(cis fat10.0.0.1s 포함)가 있는 마이크로 서비스에 적합합니다.

Fuse on OpenShift 이미지를 사용할 때 Java 옵션을 구성할 수 있습니다. JVM 옵션의 경우 환경 변수 JAVA_OPTIONS 를 사용할 수 있습니다. 또한 애플리케이션에 제공된 인수에 JAVA_ARGS 를 제공하십시오.

E.2. OpenJDK 8을 사용하여 S2I Karaf 빌더 이미지 사용

S2I Karaf 빌더 이미지는 OpenShift의 Source To Image 워크플로우와 함께 사용하여 Karaf4 사용자 지정 어셈블리 기반 maven 프로젝트를 빌드할 수 있습니다.

절차

  • 다음 명령을 사용하여 S2I 워크플로를 사용합니다.
s2i build <git repo url> registry.redhat.io/fuse7/fuse-karaf-openshift:1.6 <target image name>
docker run <target image name>

E.2.1. Karaf4 어셈블리 구성

maven 프로젝트에서 빌드한 Karaf4 어셈블리의 위치는 여러 가지 방법으로 제공될 수 있습니다.

  • 출력 디렉토리의 기본 어셈블리 파일 *.tar.gz
  • sti 또는 oc 명령에서 -e 플래그 사용
  • 프로젝트 소스 아래에 FUSE_ASSEMBLY 속성을 .sti/environment 에 설정하여

E.2.2. Maven 빌드 사용자 정의

maven 빌드를 사용자 지정할 수 있습니다. MAVEN_ARGS 환경 변수는 동작을 변경하도록 설정할 수 있습니다. 기본적으로 MAVEN_ARGS 는 다음과 같이 설정됩니다.

`Karaf4: install karaf:assembly karaf:archive -DskipTests -e`

E.3. 빌드 시간 환경 변수

다음은 빌드 시간 동안 S2I Java 및 Karaf 빌더 이미지의 동작에 영향을 미치는 환경 변수입니다.

  • MAVEN_ARGS: maven을 호출할 때 사용할 인수이며 기본 패키지를 대체합니다.
  • MAVEN_ARGS_APPEND: 추가 Maven 인수는 -X 또는 - am - pl 와 같은 임시 인수를 추가하는 데 유용합니다.
  • ARTIFACT_DIR: 다중 모듈 빌드를 위해 files are created to target/ 로 이동합니다. ${MAVEN_ARGS} 에 추가됩니다.
  • ARTIFACT_COPY_ARGS: 출력 디렉토리에서 애플리케이션 디렉터리로 아티팩트를 복사할 때 사용할 인수입니다. 이미지의 일부가 될 아티팩트를 지정하는 데 유용합니다.
  • MAVEN_CLLOG_REPO: 설정되어 있는 경우 아티팩트를 빌드한 후 Maven 리포지토리를 제거합니다. 이는 애플리케이션 이미지를 작게 유지하는 데 유용하지만 증분 빌드를 방지합니다. 기본값은 false입니다.

E.4. 런타임 환경 변수 런타임

다음 환경 변수를 사용하여 run 스크립트에 영향을 미칠 수 있습니다.

  • JAVA_APP_DIR: 애플리케이션이 상주하는 디렉터리입니다. 애플리케이션의 모든 경로는 디렉터리를 기준으로 합니다.
  • JAVA_LIB_DIR: 이 디렉토리에는 classpath가 들어 있는 선택적 classpath 파일뿐만 아니라 Java ScanSetting 파일이 포함되어 있습니다. 단일 라인 클래스 경로 (colon separated) 또는 line-by-line으로 나열 된 ScanSetting 파일과 함께. 그러나 설정하지 않으면 JAVA_LIB_DIRJAVA_APP_DIR 디렉터리와 동일합니다.
  • JAVA_OPTIONS: java를 호출할 때 추가할 옵션입니다.
  • JAVA_MAX_MEM_RATIO: JAVA_OPTIONS에서 -Xmx 옵션이 제공되지 않을 때 사용됩니다. 이는 컨테이너 제한을 기반으로 기본 최대 힙 메모리를 계산하는 데 사용됩니다. 컨테이너에 대한 메모리 제약 조건 없이 Docker 컨테이너에서 사용하는 경우 이 옵션은 적용되지 않습니다.
  • JAVA_MAX_CORE: 가비지 수집기 스레드 수와 같은 특정 기본값을 계산하는 데 사용되는 사용 가능한 코어 수를 수동으로 제한합니다. 0으로 설정하면 코어 수에 따라 기본 JVM 튜닝을 수행할 수 없습니다.
  • JAVA_DIAGNOSTICS: 상황이 발생할 때 표준으로 일부 진단 정보를 가져오도록 설정합니다.
  • JAVA_MAIN_CLASS: java의 인수로 사용할 주요 클래스입니다. 이 환경 변수를 사용하면 $JAVA_APP_DIR 디렉터리의 모든 files가 classpath 및 $JAVA_LIB_DIR 디렉터리에 추가됩니다.
  • JAVA_APP_JAR: java -jar 로 시작할 수 있도록 적절한 매니페스트가 있는 files. 그러나 제공되지 않으면 $JAVA_MAIN_CLASS 가 설정됩니다. 모든 경우에 이 ScanSetting 파일이 classpath에 추가됩니다.
  • JAVA_APP_NAME: 프로세스에 사용할 이름입니다.
  • JAVA_CLASSPATH: 사용할 클래스 경로입니다. 지정하지 않으면 시작 스크립트는 ${JAVA_APP_DIR}/classpath 파일을 확인하고 해당 콘텐츠를 classpath로 사용합니다. 이 파일이 존재하지 않으면 애플리케이션 디렉토리의 모든 ScanSetting이 (classes:${JAVA_APP_DIR}/*) 아래에 추가됩니다.
  • JAVA_DEBUG: 설정된 경우 원격 디버깅이 켜집니다.
  • JAVA_DEBUG_PORT: 원격 디버깅에 사용되는 포트입니다. 기본값은 5005입니다.

E.5. Jolokia 구성

Jolokia에서는 다음 환경 변수를 사용할 수 있습니다.

  • ab_JOLOKIA_OFF: 설정된 경우 Jolokia의 활성화를 비활성화합니다(비 빈 값 선택). 기본적으로 Jolokia가 활성화됩니다.
  • AB_JOLOKIA_CONFIG: 설정된 경우 파일(path 포함)을 Jolokia JVM 에이전트 속성으로 사용합니다. 그러나 설정하지 않으면 설정을 사용하여 /opt/jolokia/etc/jolokia.properties 가 생성됩니다.
  • ab_JOLOKIA_HOST: 바인딩할 호스트 주소 (기본값은 0.0.0.0)
  • ab_JOLOKIA_PORT: 사용할 포트 (기본값은 8778)
  • AB_JOLOKIA_USER: 기본 인증을 위한 사용자 기본적으로 jolokia 입니다.
  • AB_JOLOKIA_PASSWORD: 기본 인증을 위한 암호 기본적으로 인증이 해제됩니다.By default, authentication is switched off.
  • AB_JOLOKIA_PASSWORD_RANDOM: 값을 생성하고 /opt/jolokia/etc/jolokia.pw 파일에 작성됩니다.
  • ab_JOLOKIA_HTTPS : HTTPS 와 보안 통신을 이용하십시오. 기본적으로 자체 서명된 서버 인증서가 생성되어 있지 않으면 AB_JOLOKIA_OPTS 에 serverCert 구성이 제공되지 않습니다.
  • ab_JOLOKIA_ID: 사용할 에이전트 ID
  • AB_JOLOKIA_DISCOVERY_ENABLED: Jolokia 검색을 활성화합니다. 기본값은 false입니다.
  • AB_JOLOKIA_OPTS: 에이전트 구성에 추가할 추가 옵션입니다. 옵션은 key=value 형식으로 제공됩니다.

다음은 다양한 환경과의 통합을 위한 옵션입니다.

  • AB_JOLOKIA_AUTH_OPENSHIFT: OpenShift TSL 통신을 위한 클라이언트 인증 전환 이 매개변수의 값이 클라이언트 인증서에 있어야 합니다. 이 매개변수를 활성화하면 Jolokia를 HTTPS 통신 모드로 자동 전환합니다. 기본 CA 인증서는 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 로 설정됩니다.

JAVA_ARGS 변수를 해당 값으로 설정하여 애플리케이션 인수를 제공할 수 있습니다.

부록 F. Linux 컨테이너에서 실행되도록 JVM 튜닝

Linux 컨테이너 내에서 실행되는 Java 프로세스는 JVM ergonomics 가 가비지 수집기, 힙 크기 및 런타임 컴파일러의 기본값을 설정할 수 있을 때 예상대로 작동하지 않습니다. 예를 들어, 매개 변수의 조정 없이 Java 애플리케이션을 실행할 때(예: java -jar mypplication-fat.jar knative-); JVM은 컨테이너 제한이 아닌 호스트 제한을 기반으로 여러 매개 변수를 자동으로 설정합니다.

이 섹션에서는 Linux 컨테이너 내에서 Java 애플리케이션 패키징에 대한 정보를 제공하므로 컨테이너의 제한이 기본값 계산에 고려됩니다.

F.1. JVM 튜닝

현재 Java JVM 생성은 컨테이너를 인식하지 않으므로 컨테이너 크기가 아닌 물리적 호스트의 크기에 따라 리소스를 할당합니다. 예를 들어 JVM은 일반적으로 호스트의 실제 메모리의 최대 힙 크기를 1/4로 설정합니다. 대규모 호스트 시스템에서 이 값은 컨테이너에 대해 정의된 메모리 제한을 쉽게 초과할 수 있으며, 런타임에 컨테이너 제한이 초과되면 OpenShift에서 애플리케이션을 종료합니다.

이 문제를 해결하려면 Java JVM이 제한된 컨테이너 내에서 실행되고 수동으로 수행하지 않은 경우 최대 힙 크기를 자동으로 조정할 수 있는 OpenShift 기본 이미지에서 Fuse를 사용할 수 있습니다. 애플리케이션을 실행하는 JVM에 최대 메모리 제한과 코어 제한을 설정하는 솔루션을 제공합니다. OpenShift 이미지의 Fuse의 경우 다음을 수행할 수 있습니다.

  • 컨테이너 코어에 따라 CICompilerCount 설정
  • 컨테이너 메모리 제한이 300MB 미만인 경우 C2ECDHE 컴파일러 비활성화
  • 300MB 미만의 경우 기본 힙 크기에 대해 컨테이너 메모리 제한의 1/4을 사용합니다.

F.2. OpenShift 이미지에서 Fuse의 기본 동작

Fuse on OpenShift에서 애플리케이션 빌드의 기본 이미지는 Java 이미지(S Spring Boot 애플리케이션용) 또는 Karaf 이미지(Karaf 애플리케이션용)일 수 있습니다. OpenShift 이미지의 Fuse는 컨테이너 제한을 읽고 리소스 할당을 기반으로 이러한 제한을 사용하는 스크립트를 실행합니다. 기본적으로 스크립트는 JVM에 다음 리소스를 할당합니다.

  • 컨테이너 메모리 제한의 50%는
  • 컨테이너 코어 제한의 50%입니다.

이에 대한 몇 가지 예외가 있습니다. Karaf 및 Java 이미지의 경우 실제 메모리가 300MB 임계값 미만인 경우 힙 크기가 1-half 대신 기본 힙 크기의 4번째로 복원됩니다.

F.3. OpenShift 이미지에서 Fuse 사용자 정의 튜닝

이 스크립트는 내부 리소스를 튜닝하기 위해 사용자 지정 애플리케이션에서 읽는 CONTAINER_MAX_MEMORYCONTAINER_CORE_LIMIT 환경 변수를 설정합니다. 또한 애플리케이션을 실행하는 JVM의 설정을 사용자 지정할 수 있는 다음 런타임 환경 변수를 지정할 수 있습니다.

  • JAVA_OPTIONS
  • JAVA_MAX_MEM_RATIO

제한을 명시적으로 사용자 지정하려면 Maven 프로젝트에서 deployment.yml 파일을 편집하여 JAVA_MAX_MEM_RATIO 환경 변수를 설정할 수 있습니다.

예제

spec:
  template:
    spec:
      containers:
        -
          resources:
            requests:
              cpu: "0.2"
               memory: 256Mi
            limits:
              cpu: "1.0"
               memory: 256Mi
          env:
          - name: JAVA_MAX_MEM_RATIO
            value: 60

F.4. 타사 라이브러리 튜닝

Red Hat은 rubyty와 같은 타사 Java 라이브러리에 대한 제한을 사용자 지정하는 것이 좋습니다. 이러한 라이브러리는 제한을 수동으로 사용자 지정하지 못하는 경우 지정된 기본 제한을 사용합니다. 시작 스크립트는 애플리케이션에서 사용할 수 있는 컨테이너 제한을 설명하는 일부 환경 변수를 노출합니다.

CONTAINER_CORE_LIMIT
계산된 코어 제한
CONTAINER_MAX_MEMORY
컨테이너에 지정된 메모리 제한

법적 공지

Copyright © 2023 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.