검색

Using JBoss EAP XP 4.0.0

download PDF
Red Hat JBoss Enterprise Application Platform 7.4

JBoss EAP XP 4.0.0에서 사용하는 경우

Red Hat Customer Content Services

초록

이 문서에서는 JBoss EAP XP 4.0.0에서 MicroProfile 사용에 대한 일반적인 정보를 제공합니다.

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

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

JBoss EAP 문서에 대한 피드백 제공

오류를 보고하거나 문서를 개선하기 위해 Red Hat Jira 계정에 로그인하여 문제를 제출하십시오. Red Hat Jira 계정이 없는 경우 계정을 생성하라는 메시지가 표시됩니다.

프로세스

  1. 티켓을 생성하려면 다음 링크를 클릭하십시오.
  2. 문서 URL, 섹션 번호 를 포함하고 문제를 설명하십시오.
  3. 요약 에 문제에 대한 간략한 설명을 입력합니다.
  4. 설명에서 문제 또는 개선 사항에 대한 자세한 설명을 제공합니다. 문서에서 문제가 발생한 위치에 URL을 포함합니다.
  5. Submit 을 클릭하고 문제를 적절한 문서 팀으로 라우팅합니다.

1장. 최신 MicroProfile 기능을 위한 JBoss EAP XP

1.1. JBoss EAP XP 정보

MicroProfile 확장 팩(JBoss EAP XP)은 JBoss EAP XP 관리자를 사용하여 제공되는 패치 스트림으로 사용할 수 있습니다.

참고

JBoss EAP XP에는 별도의 지원 및 라이프 사이클 정책이 적용됩니다. 자세한 내용은 JBoss Enterprise Application Platform 확장 팩 지원 및 라이프 사이클 정책 페이지를 참조하십시오.

JBoss EAP XP 패치는 다음과 같은 MicroProfile 4.1 구성 요소를 제공합니다.

  • MicroProfile Config
  • MicroProfile Fault Tolerance
  • MicroProfile Health
  • MicroProfile JWT
  • MicroProfile Metrics
  • MicroProfile OpenAPI
  • MicroProfile OpenTracing
  • MicroProfile REST Client
  • MicroProfile Reactive Messaging
참고

MicroProfile Reactive Messaging 하위 시스템은 Red Hat AMQ Streams를 지원합니다. 이 기능은 MicroProfile Reactive Messaging 2.0.1 API를 구현하고 Red Hat은 JBoss EAP XP 4.0.0의 기술 프리뷰로 기능을 제공합니다.

Red Hat은 JBoss EAP에서 Red Hat AMQ Streams 2021.Q4를 테스트했습니다. 그러나 JBoss EAP XP 4.0.0에서 테스트된 최신 Red Hat AMQ Streams 버전에 대한 정보는 Red Hat JBoss Enterprise Application Platform 지원 구성 페이지를 확인하십시오.

기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

1.2. JBoss EAP XP 설치

JBoss EAP XP를 설치할 때 JBoss EAP XP 패치가 JBoss EAP EAP 버전과 호환되는지 확인하십시오. JBoss EAP XP 4.0.x 패치는 JBoss EAP 7.4 릴리스와 호환됩니다.

참고

XP 관리자 및 EAP 아카이브 또는 JBoss EAP XP OpenShift Container 이미지를 사용하여 JBoss EAP XP를 설치할 수 있습니다. EAP RPM 상단에 JBoss EAP XP를 설치할 수 없습니다.

추가 리소스

  • 최신 JBoss EAP 릴리스에 최신 JBoss EAP XP 패치를 설치하는 방법에 대한 자세한 내용은 JBoss EAP XP 4.0.0을 JBoss EAP 7.4.x에 설치를 참조하십시오.

1.3. JBoss EAP XP 관리자

JBoss EAP XP Manager는 제품 다운로드 페이지에서 다운로드할 수 있는 실행 파일입니다. JBoss EAP XP 관리자를 사용하여 JBoss EAP XP 패치 스트림에서 JBoss EAP XP 패치를 적용합니다. 패치에는 MicroProfile 4.1 구현과 이러한 MicroProfile 4.1 구현에 대한 버그 수정이 포함되어 있습니다.

참고

관리 콘솔을 사용하여 JBoss EAP XP 패치를 관리할 수 없습니다.

인수 없이 JBoss EAP XP 관리자를 실행하거나 help 명령을 실행하면 사용 가능한 모든 명령 목록이 표시됩니다.

사용 가능한 인수에 대한 자세한 정보를 얻으려면 manager를 help 명령으로 실행합니다.

참고

대부분의 JBoss EAP XP 관리자 명령은 --jboss-home 인수를 사용하여 JBoss EAP XP 패치 스트림을 관리합니다. 이 값을 생략하려면 JBOSS_HOME 환경 변수에서 서버의 경로를 지정합니다. --JBoss-home 은 환경 변수보다 우선합니다.

1.4. JBoss EAP XP Manager 4.0 명령

JBoss EAP XP manager 4.0은 JBoss EAP XP 패치 스트림을 관리하기 위한 다양한 명령을 제공합니다.

다음 명령이 제공됩니다.

patch-apply

JBoss EAP 설치에 패치를 적용하려면 이 명령을 사용합니다.

patch-apply 명령은 patch apply 관리 CLI 명령과 유사합니다. patch-apply 명령은 도구를 사용하여 패치를 적용하는 데 필요한 인수만 허용합니다. 다른 패치 적용 관리 CLI 명령 인수에 기본값을 사용합니다.

patch-apply 명령을 사용하여 서버에서 활성화된 모든 패치 스트림에 패치를 적용할 수 있습니다. 명령을 사용하여 기본 서버 패치와 XP 패치를 모두 적용할 수도 있습니다.

patch-apply 명령 사용 예:

$ java -jar jboss-eap-xp-manager.jar patch-apply --jboss-home=/PATH/TO/EAP --patch=/PATH/TO/PATCH/jboss-eap-7.3.4-patch.zip

XP 패치를 적용하면 JBoss EAP XP manager 4.0은 패치 및 패치 스트림 불일치를 방지하기 위해 검증을 수행합니다. 다음 예제에서는 잘못된 조합을 보여줍니다.

  • XP 4.0 패치 스트림이 설정된 서버에 JBoss EAP XP 3.0 패치를 설치하려고 하면 다음과 같은 오류가 발생합니다.

    java.lang.IllegalStateException: The JBoss EAP XP patch stream in the patch 'jboss-eap-xp-3.0' does not match the currently enabled JBoss EAP XP patch stream [jboss-eap-xp-4.0]
    	at org.jboss.eap.util.xp.patch.stream.manager.ManagerPatchApplyAction.doExecute(ManagerPatchApplyAction.java:33)
    	at org.jboss.eap.util.xp.patch.stream.manager.ManagerAction.execute(ManagerAction.java:40)
    	at org.jboss.eap.util.xp.patch.stream.manager.ManagerMain.main(ManagerMain.java:50)
  • JBoss EAP XP 4.0.0 패치 스트림에 설정되지 않은 서버에 JBoss EAP XP 4.0.0 패치를 설치하려고 하면 다음과 같은 오류가 발생합니다.

    java.lang.IllegalStateException: You are attempting to install a patch for the 'jboss-eap-xp-4.0' JBoss EAP XP Patch Stream. However this patch stream is not yet set up in the JBoss EAP server. Run the 'setup' command to enable the patch stream.
    	at org.jboss.eap.util.xp.patch.stream.manager.ManagerPatchApplyAction.doExecute(ManagerPatchApplyAction.java:29)
    	at org.jboss.eap.util.xp.patch.stream.manager.ManagerAction.execute(ManagerAction.java:40)
    	at org.jboss.eap.util.xp.patch.stream.manager.ManagerMain.main(ManagerMain.java:50)

    두 경우 모두 서버에 대한 변경 사항이 없습니다.

제거

이 명령을 사용하여 JBoss EAP 서버에서 JBoss EAP XP 패치 스트림 설정을 제거합니다.

remove 명령 사용 예

$ java -jar jboss-eap-xp-manager.jar remove --jboss-home=/PATH/TO/EAP

setup

이 명령을 사용하여 JBoss EAP XP 패치 스트림에 대해 정리 JBoss EAP 서버를 설정합니다.

설정 명령을 사용하면 JBoss EAP XP 관리자가 다음 작업을 수행합니다.

  • JBoss EAP XP 4.0.0 패치 스트림을 활성화합니다.
  • --base-patch--xp-patch 특성을 사용하여 지정된 패치를 적용합니다.
  • standalone-microprofile.xmlstandalone-microprofile-ha.xml 구성 파일을 서버 구성 디렉터리에 복사합니다.

    이전 구성 파일이 이미 설치된 경우 새 파일은 standalone-microprofile-yyyyMMdd-HHmms.xml 과 같은 대상 구성 디렉터리에 타임스탬프된 사본으로 저장됩니다.

    --jboss-config-directory 인수를 사용하여 대상 디렉터리를 설정할 수 있습니다.

setup 명령 사용 예

$ java -jar jboss-eap-xp-manager.jar setup --jboss-home=/PATH/TO/EAP

status

이 명령을 사용하여 JBoss EAP XP 서버의 현재 상태를 찾습니다. status 명령은 다음 정보를 반환합니다.

  • JBoss EAP XP 스트림의 상태.
  • 현재 상태로 인해 지원 정책 변경
  • JBoss EAP XP의 주요 버전입니다.
  • 패치 스트림 및 누적 패치 ID를 활성화합니다.
  • 사용 가능한 JBoss EAP XP 관리자 명령으로 상태를 변경합니다.

status 명령 사용 예

$ java -jar jboss-eap-xp-manager.jar status --jboss-home=/PATH/TO/EAP

업그레이드

이 명령을 사용하여 이전 JBoss EAP XP 패치 스트림을 JBoss EAP 서버의 최신 패치 스트림으로 업그레이드합니다.

업그레이드 명령을 사용하면 JBoss EAP XP 관리자가 다음 작업을 수행합니다.

  • 서버에서 이전 패치 스트림을 활성화하는 파일 백업을 생성합니다.
  • JBoss EAP XP 4.0 패치 스트림을 활성화합니다.
  • --base-patch--xp-patch 특성을 사용하여 지정된 패치를 적용합니다.
  • standalone-microprofile.xmlstandalone-microprofile-ha.xml 구성 파일을 서버 구성 디렉터리에 복사합니다. 이전 구성 파일이 이미 설치된 경우 새 파일은 standalone-microprofile-yyyyMMdd-HHmms.xml 과 같은 대상 구성 디렉터리에 타임스탬프된 사본으로 저장됩니다.
  • 문제가 발생하면 JBoss EAP XP 관리자가 생성한 백업에서 이전 패치 스트림을 복원하려고 합니다.

    --jboss-config-directory 인수를 사용하여 대상 디렉터리를 설정할 수 있습니다.

upgrade 명령 사용 예:

$ java -jar jboss-eap-xp-manager.jar upgrade --jboss-home=/PATH/TO/EAP

1.5. Installing JBoss EAP XP 4.0.0 on JBoss EAP 7.4.x

JBoss EAP 7.4 기본 서버에 JBoss EAP XP 4.0.0을 설치합니다.

JBoss EAP XP 관리자 4.0.0을 사용하여 JBoss EAP XP 4.0.0 패치 스트림을 관리합니다.

참고

JBoss EAP XP 4.0.0은 JBoss EAP 7.4.x에서 인증되었습니다.

사전 요구 사항

  • 제품 다운로드 페이지에서 다음 파일을 다운로드 했습니다.

    • jboss-eap-xp-4.0.0-manager.jar 파일(JBoss EAP XP manager 4.0)
    • JBoss EAP 7.4 서버 아카이브 파일
    • JBoss EAP XP 4.0.0 패치

프로세스

  1. 다운로드한 JBoss EAP 7.4 서버 아카이브 파일을 JBoss EAP 설치 경로로 추출합니다.
  2. 다음 명령을 사용하여 JBoss EAP XP Manager 4.0.0을 설정하여 JBoss EAP XP 4.0 패치 스트림을 관리합니다.

    $ java -jar jboss-eap-xp-manager.jar setup --jboss-home=<path_to_eap>
    참고

    JBoss EAP XP 4.0.0 패치를 동시에 적용할 수 있습니다. --xp-patch 인수를 사용하여 JBoss EAP XP 4.0.0 패치 경로를 포함합니다.

    예제:

    $ java -jar jboss-eap-xp-manager.jar setup --jboss-home=<path_to_eap> --xp-patch=<path_to_patch>jboss-eap-xp-4.0.0-patch.zip

    서버는 이제 JBoss EAP XP 4.0.0 패치 스트림을 관리할 준비가 되었습니다.

  3. 선택 사항: --xp-patch 인수를 사용하여 JBoss EAP XP 4.0.0 패치를 JBoss EAP 서버에 적용하지 않은 경우 JBoss EAP XP 관리자 4.0.0 patch-apply 명령을 사용하여 JBoss EAP XP 4.0.0 패치를 적용합니다.

    $ java -jar jboss-eap-xp-manager.jar patch-apply --jboss-home=<path_to_eap> --patch=<path_to_patch>jboss-eap-xp-4.0.0-patch.zip

    patch-apply 명령은 patch apply 관리 CLI 명령과 유사합니다. patch apply 관리 CLI 명령을 사용하여 패치를 적용할 수도 있습니다.

JBoss EAP XP 4.0.0 패치를 사용하여 JBoss EAP 서버에 패치를 적용할 때 JBoss EAP XP 4.0.0 패치를 관리할 준비가 되었습니다.

1.6. JBoss EAP XP 설치 제거

JBoss EAP XP를 제거하면 JBoss EAP XP 4.0.0 패치 스트림 및 MicroProfile 4.1 기능 활성화와 관련된 모든 파일이 제거됩니다. 설치 제거 프로세스는 기본 서버 패치 스트림 또는 기능에는 영향을 미치지 않습니다.

참고

제거 프로세스는 JBoss EAP XP 패치 스트림을 활성화할 때 JBoss EAP XP 패치에 추가한 파일을 포함하여 구성 파일을 제거하지 않습니다.

프로세스

  • 다음 명령을 실행하여 JBoss EAP XP 4.0.0을 설치 제거합니다.

    $ java -jar jboss-eap-xp-manager.jar remove --jboss-home=/PATH/TO/EAP

MicroProfile 4.1 기능을 다시 설치하려면 setup 명령을 다시 실행하여 패치 스트림을 활성화한 다음 JBoss EAP XP 패치를 적용하여 MicroProfile 4.1 모듈을 추가합니다.

1.7. JBoss EAP XP의 상태 보기

status 명령을 사용하여 다음 정보를 볼 수 있습니다.

  • JBoss EAP XP 스트림의 상태.
  • 현재 상태로 인해 지원 정책 변경
  • JBoss EAP XP의 주요 버전입니다.
  • 패치 스트림 및 누적 패치 ID를 활성화했습니다.
  • 사용 가능한 JBoss EAP XP 관리자 명령으로 상태를 변경합니다.

JBoss EAP XP는 다음 상태 중 하나일 수 있습니다.

설정되지 않음
JBoss EAP는 깔끔하고 JBoss EAP XP가 설정되어 있지 않습니다.
설정
JBoss EAP에는 JBoss EAP XP가 설정되어 있습니다. 사용자가 CLI를 사용하여 확인할 수 있으므로 XP 패치 스트림 버전이 표시되지 않습니다.
일관성 없음
JBoss EAP XP와 관련된 파일은 일관되지 않은 상태입니다. 이는 오류 조건이며 정상적으로 발생하지 않아야 합니다. 이 오류가 발생하면 JBoss EAP XP 설치 제거 항목에 설명된 대로 JBoss EAP XP 관리자를 제거하고 setup 명령을 사용하여 JBoss EAP XP를 다시 설치합니다.

프로세스

  • 다음 명령을 실행하여 JBoss EAP XP의 상태를 확인합니다.

    $ java -jar jboss-eap-xp-manager.jar status --jboss-home=<path_to_eap>

1.8. JBoss EAP XP 및 JBoss EAP 7.4.x 기본 패치 롤백

관리 CLI를 사용하여 이전에 적용한 JBoss EAP XP 패치 또는 JBoss EAP 7.4.x 기본 패치를 롤백할 수 있습니다.

추가 리소스

2장. MicroProfile 이해

2.1. MicroProfile Config

2.1.1. JBoss EAP의 MicroProfile Config

구성 데이터는 동적으로 변경될 수 있으며 애플리케이션은 서버를 다시 시작하지 않고도 최신 구성 정보에 액세스할 수 있어야 합니다.

MicroProfile Config는 구성 데이터의 이식 가능한 외부화를 제공합니다. 즉, 수정 또는 재패키징 없이 여러 환경에서 실행되도록 애플리케이션 및 마이크로서비스를 구성할 수 있습니다.

MicroProfile Config 기능은 SmallRye Config 구성 요소를 사용하여 JBoss EAP에서 구현되며 microprofile-config-undercloudrye 하위 시스템에서 제공합니다.

참고

MicroProfile Config는 JBoss EAP XP에서만 지원됩니다. JBoss EAP에서는 지원되지 않습니다.

중요

자체 Config 구현을 추가하는 경우 최신 버전의 Config 인터페이스에서 메서드를 사용해야 합니다.

2.1.2. MicroProfile Config에서 지원되는 MicroProfile Config 소스

MicroProfile Config 구성 속성은 다른 위치에서 가져올 수 있으며 다른 형식일 수 있습니다. 이러한 속성은 ConfigSources에서 제공합니다. ConfigSources는 org.eclipse.microprofile.config.spi.ConfigSource 인터페이스의 구현입니다.

MicroProfile Config 사양은 구성 값을 검색하기 위한 다음과 같은 기본 ConfigSource 구현을 제공합니다.

  • System.getProperties().
  • system.getenv().
  • 클래스 경로의 모든 META-INF/microprofile-config.properties 파일

microprofile-config-#159rye 하위 시스템은 구성 값을 검색하기 위해 추가 유형의 ConfigSource 리소스를 지원합니다. 다음 리소스에서 구성 값을 검색할 수도 있습니다.

  • microprofile-config-undercloudrye/config-source 관리 리소스의 속성
  • 디렉터리의 파일
  • ConfigSource 클래스
  • ConfigSourceProvider 클래스

2.2. MicroProfile Fault Tolerance

2.2.1. MicroProfile Fault Tolerance 사양 정보

MicroProfile Fault Tolerance 사양은 분산 마이크로 서비스에 내재된 오류를 처리하는 전략을 정의합니다.

MicroProfile Fault Tolerance 사양은 오류를 처리하기 위한 다음 전략을 정의합니다.

Timeout
실행을 완료해야 하는 시간을 정의합니다. 시간 초과를 정의하면 실행이 무기한 대기되지 않습니다.
Retry
실패한 실행을 재시도하는 기준을 정의합니다.
폴백
실행에 실패한 경우 대안을 제공합니다.
CircuitBreaker
일시적으로 중지되기 전에 실패한 실행 시도 수를 정의합니다. 실행을 다시 시작하기 전에 지연의 길이를 정의할 수 있습니다.
Bulkhead
시스템의 나머지 부분이 계속 작동할 수 있도록 오류를 격리합니다.
비동기
별도의 스레드에서 클라이언트 요청을 실행합니다.

2.2.2. JBoss EAP의 MicroProfile Fault Tolerance

microprofile-fault-tolerance-undercloudrye 하위 시스템은 JBoss EAP에서 MicroProfile Fault Tolerance를 지원합니다. 하위 시스템은 JBoss EAP XP 스트림에서만 사용할 수 있습니다.

microprofile-fault-tolerance-undercloudrye 하위 시스템은 인터셉터 바인딩에 대해 다음과 같은 주석을 제공합니다.

  • @timeout
  • @Retry
  • @Fallback
  • @CircuitBreaker
  • @Bulkhead
  • @Asynchronous

이러한 주석은 클래스 수준 또는 메서드 수준에서 바인딩할 수 있습니다. 클래스에 바인딩된 주석은 해당 클래스의 모든 비즈니스 메서드에 적용됩니다.

다음 규칙은 바인딩 인터셉터에 적용됩니다.

  • 구성 요소 클래스가 클래스 수준 인터셉터 바인딩을 선언하거나 상속하는 경우 다음과 같은 제한 사항이 적용됩니다.

    • 클래스는 final로 선언해서는 안 됩니다.
    • 클래스에는 정적, 개인 또는 최종 메서드가 포함되어 있지 않아야 합니다.
  • 구성 요소 클래스의 비정적, 비개인적 메서드의 메서드 수준 인터셉터 바인딩을 선언하는 경우 메서드 및 구성 요소 클래스를 final로 선언할 수 없습니다.

내결함성 작업에는 다음과 같은 제한 사항이 있습니다.

  • fault tolerance interceptor 바인딩은 Quarkus 클래스 또는 Cryostat 클래스 메서드에 적용해야 합니다.
  • 호출 시 호출은 Jakarta 컨텍스트 및 종속성 사양에 정의된 비즈니스 메서드 호출이어야 합니다.
  • 다음 두 조건이 모두 true인 경우 작업이 내결함성으로 간주되지 않습니다.

    • 방법 자체는 내결함성 인터셉터에 바인딩되지 않습니다.
    • 메서드를 포함하는 클래스는 내결함성 인터셉터에 바인딩되지 않습니다.

microprofile-fault-tolerance-undercloudrye 하위 시스템은 MicroProfile Fault Tolerance에서 제공하는 구성 옵션 외에도 다음과 같은 구성 옵션을 제공합니다.

  • io.smallrye.faulttolerance.mainThreadPoolSize
  • io.smallrye.faulttolerance.mainThreadPoolQueueSize

2.3. MicroProfile Health

2.3.1. JBoss EAP의 MicroProfile Health

JBoss EAP에는 JBoss EAP 인스턴스가 예상대로 응답하는지 확인하는 데 사용할 수 있는 SmallRye Health 구성 요소가 포함되어 있습니다. 이 기능은 기본적으로 활성화되어 있습니다.

MicroProfile Health는 JBoss EAP를 독립 실행형 서버로 실행하는 경우에만 사용할 수 있습니다.

MicroProfile Health 사양은 다음과 같은 상태 점검을 정의합니다.

준비
애플리케이션에서 요청을 처리할 준비가 되었는지 확인합니다. @Readiness 는 이 상태 점검을 제공합니다.
활성
애플리케이션이 실행 중인지 확인합니다. @Liveness 는 이 상태 점검을 제공합니다.
startup
애플리케이션이 이미 시작되었는지 여부를 확인합니다. @Startup 주석에서는 이 상태 점검을 제공합니다.

@Health 주석은 MicroProfile Health 3.0에서 제거되었습니다.

MicroProfile Health 3.1에는 새로운 시작 상태 점검 프로브가 포함되어 있습니다.

MicroProfile Health 3.1의 변경 사항에 대한 자세한 내용은 MicroProfile Health 3.1 릴리스 노트를 참조하십시오.

중요

:empty-readiness-checks-status,:empty-liveness -checks-status, :empty-startup-checks-status 관리 속성은 준비 상태, 활성 상태 또는 시작 프로브가 정의되지 않은 경우 글로벌 상태를 지정합니다.

2.4. MicroProfile JWT

2.4.1. JBoss EAP에서 MicroProfile JWT 통합

하위 시스템 microprofile-jwt-Neutronrye 는 JBoss EAP에서 MicroProfile JWT 통합을 제공합니다.

다음 기능은 microprofile-jwt-undercloudrye 하위 시스템에서 제공합니다.

  • MicroProfile JWT 보안을 사용하는 배포 감지.
  • MicroProfile JWT 지원 활성화

하위 시스템에는 구성 가능한 속성 또는 리소스가 포함되어 있지 않습니다.

org.eclipse. microprofile.jwt.auth.api 모듈은 JBoss EAP에서 MicroProfile JWT 통합을 제공합니다.

추가 리소스

2.4.2. 기존 배포와 MicroProfile JWT 배포 간의 차이점

MicroProfile JWT 배포는 기존 JBoss EAP 배포와 같은 관리형 SecurityDomain 리소스에 의존하지 않습니다. 대신, MicroProfile JWT 배포에서 가상 SecurityDomain이 생성되고 사용됩니다.

MicroProfile JWT 배포가 전적으로 MicroProfile Config 속성 및 microprofile-jwt-undercloudrye 하위 시스템 내에 구성되므로 가상 SecurityDomain에는 배포에 대한 다른 관리 구성이 필요하지 않습니다.

2.4.3. JBoss EAP에서 MicroProfile JWT 활성화

MicroProfile JWT는 애플리케이션에 auth-method 가 있는 애플리케이션에 따라 활성화됩니다.

MicroProfile JWT 통합은 다음과 같은 방식으로 애플리케이션에 대해 활성화됩니다.

  • 배포 프로세스의 일부로 JBoss EAP는 auth-method 가 있는지 애플리케이션 아카이브를 검사합니다.
  • auth-method 가 있고 MP-JWT 로 정의된 경우 MicroProfile JWT 통합이 활성화됩니다.

auth-method 는 다음 파일 중 하나 또는 둘 다에 지정할 수 있습니다.

  • javax.ws.rs.core.Application 을 확장하는 클래스가 포함된 파일, @LoginConfig주석이 추가됨
  • web.xml 구성 파일

auth-method 가 주석과 web.xml 구성 파일에서 클래스 모두에서 정의되면 web.xml 구성 파일의 정의가 사용됩니다.

2.4.4. JBoss EAP에서 MicroProfile JWT의 제한 사항

JBoss EAP의 MicroProfile JWT 구현에는 특정 제한이 있습니다.

JBoss EAP에는 MicroProfile JWT 구현의 다음과 같은 제한 사항이 있습니다.

  • MicroProfile JWT 구현은 mp.jwt.verify.publickey 속성에 제공된 JWKS(JWKS)의 첫 번째 키만 구문 분석합니다. 따라서 토큰을 두 번째 키 또는 두 번째 키 뒤에 있는 키로 서명해야 하는 경우 토큰 확인이 실패하고 토큰을 포함하는 요청이 인증되지 않습니다.
  • JWKS의 Base64 인코딩은 지원되지 않습니다.

두 경우 모두 mp.jwt.verify.publickey.location config 속성을 사용하는 대신 일반 텍스트 JWKS를 참조할 수 있습니다.

2.5. MicroProfile Metrics

2.5.1. JBoss EAP의 MicroProfile 지표

JBoss EAP에는 SmallRye Metrics 구성 요소가 포함되어 있습니다. SmallRye Metrics 구성 요소는 microprofile-metrics-overcloudrye 하위 시스템을 사용하여 MicroProfile Metrics 기능을 제공합니다.

microprofile-metrics-undercloudrye 하위 시스템은 JBoss EAP 인스턴스에 대한 모니터링 데이터를 제공합니다. 하위 시스템은 기본적으로 활성화되어 있습니다.

중요

microprofile-metrics-undercloudrye 하위 시스템은 독립 실행형 구성에서만 활성화됩니다.

2.6. MicroProfile OpenAPI

2.6.1. JBoss EAP의 MicroProfile OpenAPI

MicroProfile OpenAPI는 microprofile-openapi-undercloudrye 하위 시스템을 사용하여 JBoss EAP에 통합됩니다.

MicroProfile OpenAPI 사양은 OpenAPI 3.0 문서를 제공하는 HTTP 끝점을 정의합니다. OpenAPI 3.0 문서는 호스트의 REST 서비스를 설명합니다. OpenAPI 끝점은 배포와 연결된 호스트의 루트에 로컬로 구성된 경로(예: http://localhost:8080/openapi)를 사용하여 등록합니다.

참고

현재 가상 호스트의 OpenAPI 엔드포인트는 단일 배포만 문서화할 수 있습니다. 동일한 가상 호스트에서 다른 컨텍스트 경로에 등록된 여러 배포와 함께 OpenAPI를 사용하려면 각 배포에서 별도의 엔드포인트 경로를 사용해야 합니다.

OpenAPI 엔드포인트는 기본적으로 YAML 문서를 반환합니다. Accept HTTP 헤더 또는 형식 쿼리 매개변수를 사용하여 JSON 문서를 요청할 수도 있습니다.

지정된 애플리케이션의 Cryostat 서버 또는 호스트가 HTTPS 리스너를 정의하는 경우 HTTPS를 사용하여 OpenAPI 문서도 사용할 수 있습니다. 예를 들어 HTTPS의 끝점은 https://localhost:8443/openapi입니다.

2.7. MicroProfile OpenTracing

2.7.1. MicroProfile OpenTracing

특히 요청이 라이프사이클 동안 여러 서비스를 통해 전달될 수 있는 마이크로 서비스 환경에서 요청을 추적하는 기능이 중요합니다.

MicroProfile OpenTracing 사양은 CDI-bean 애플리케이션 내에서 OpenTracing compliant Tracer 인터페이스에 액세스하기 위한 동작 및 API를 정의합니다. Tracer 인터페이스는 Cryostat-RS 애플리케이션을 자동으로 추적합니다.

동작은 OpenTracing Spans가 들어오고 나가는 요청에 대해 자동으로 생성되는 방법을 지정합니다. API는 지정된 엔드포인트에 대해 추적을 명시적으로 비활성화하거나 활성화하는 방법을 정의합니다.

추가 리소스

2.7.2. JBoss EAP에서 MicroProfile OpenTracing

microprofile-opentracing-overcloudrye 하위 시스템을 사용하여 Jakarta EE 애플리케이션의 분산 추적을 구성할 수 있습니다. 이 하위 시스템은 SmallRye OpenTracing 구성 요소를 사용하여 JBoss EAP에 MicroProfile OpenTracing 기능을 제공합니다.

MicroProfile OpenTracing 2.0은 애플리케이션 요청 추적을 지원합니다. 관리 CLI 또는 관리 콘솔과 JBoss EAP 관리 API를 사용하여 Jakarta EE에서 일반적으로 사용되는 구성 요소에 대한 기본 Jaeger Java 클라이언트 추적기 및 조정 라이브러리 세트를 구성할 수 있습니다.

참고

JBoss EAP 서버에 배포된 각 개별 WAR에는 자체 추적기 인스턴스가 자동으로 있습니다. EAR 내의 각 WAR는 개별 WAR로 취급되며 각각 자체 추적기 인스턴스가 있습니다. 기본적으로 Jaeger Client와 함께 사용되는 서비스 이름은 배포 이름(일반적으로 WAR 파일 이름)에서 파생됩니다.

microprofile-opentracing-undercloudrye 하위 시스템 내에서 시스템 속성 또는 환경 변수를 설정하여 Jaeger Java 클라이언트를 구성할 수 있습니다.

중요

시스템 속성 및 환경 변수를 사용하여 Jaeger 클라이언트 추적기를 구성하는 것은 기술 프리뷰로 제공됩니다. Jaeger 클라이언트 추적기와 제휴된 시스템 속성 및 환경 변수는 향후 릴리스에서 변경되어 서로 호환되지 않을 수 있습니다.

기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

참고

기본적으로 Java용 Jaeger 클라이언트의 확률 샘플링 전략은 0.001 로 설정되어 있습니다. 즉, 약 1,000개의 추적 중 하나만 샘플링됩니다. 모든 요청을 샘플링하려면 시스템 속성 JAEGER_SAMPLER_TYPEconstJAEGER_SAMPLER_PARAM1 로 설정합니다.

추가 리소스

2.8. MicroProfile REST Client

2.8.1. MicroProfile REST 클라이언트

JBoss EAP XP 4.0.0은 Jakarta RESTful Web Services 2.1.6 클라이언트 API를 기반으로 하는 MicroProfile REST 클라이언트 2.0을 지원하여 HTTP를 통해 RESTful 서비스를 호출할 수 있는 형식이 안전한 접근 방식을 제공합니다. MicroProfile Type Safe REST 클라이언트는 Java 인터페이스로 정의됩니다. MicroProfile REST 클라이언트를 사용하면 실행 가능한 코드로 클라이언트 애플리케이션을 작성할 수 있습니다.

MicroProfile REST 클라이언트를 사용하여 다음 기능을 사용할 수 있습니다.

  • 직관적인 구문
  • 공급자의 프로그래밍 방식 등록
  • 공급자의 선언적 등록
  • 헤더의 선언적 사양
  • ResponseExceptionMapper
  • Jakarta Contexts and dependency Cryostat 통합
  • SSE(서버 관련 이벤트) 액세스

2.8.2. resteasy.original.webapplicationexception.behavior MicroProfile Config 속성

MicroProfile Config 는 개발자가 애플리케이션을 수정하거나 다시 패키징하지 않고도 여러 환경에서 실행되도록 애플리케이션 및 마이크로서비스를 구성하는 데 사용할 수 있는 사양의 이름입니다. 이전에는 JBoss EAP에서 기술 프리뷰로 MicroProfile Config를 사용할 수 있었지만 이후 제거되었습니다. MicroProfile Config는 이제 JBoss EAP XP에서만 사용할 수 있습니다.

resteasy.original.webapplicationexception.behavior MicroProfile Config 속성 정의

resteasy.original.webapplicationexception.behavior 매개변수를 web.xml 서블릿 속성 또는 시스템 속성으로 설정할 수 있습니다. 다음은 web.xml 에서 이러한 서블릿 속성 중 하나의 예입니다.

<context-param>
    <param-name>resteasy.original.webapplicationexception.behavior</param-name>
    <param-value>true</param-value>
</context-param>

MicroProfile Config를 사용하여 다른 REST Cryostat 속성을 구성할 수도 있습니다.

추가 리소스

2.9. MicroProfile Reactive Messaging

2.9.1. MicroProfile reactive 메시징

JBoss EAP XP 4.0.0으로 업그레이드하는 경우 reactive messaging extensions 및 subsystems를 포함하는 MicroProfile Reactive Messaging의 최신 버전을 활성화할 수 있습니다.

"반복 스트림"은 처리 프로토콜 및 표준과 함께 이벤트 데이터의 연속으로, 버퍼링 없이 비동기 경계(예: 스케줄러)에 푸시됩니다. 예를 들어, "이벤트"가 예정된 일 수 있으며, 예를 들어, 환경 앱에서 온도 검사를 반복할 수 있습니다. 반응 스트림의 주요 이점은 다양한 애플리케이션 및 구현의 원활한 상호 운용성입니다.

반응형 메시징은 이벤트 중심, 데이터 스트리밍 및 이벤트 소싱 애플리케이션을 빌드하기 위한 프레임워크를 제공합니다. 반응성 메시징은 한 앱에서 다른 앱으로 이벤트 데이터, 반응 스트림의 일정 및 원활한 교환을 초래합니다. 예를 들어 애플리케이션이 Apache Kafka와 같은 다른 사용자와 상호 작용할 수 있도록 반응 스트림을 통해 비동기 메시징에 MicroProfile Reactive Messaging을 사용할 수 있습니다.

MicroProfile Reactive Messaging 인스턴스를 최신 버전으로 업그레이드한 후 다음을 수행할 수 있습니다.

  • Apache Kafka 데이터 스트리밍 플랫폼에 대한 MicroProfile Reactive Messaging으로 서버를 프로비저닝합니다.
  • 최신 반응 메시징 API를 통해 메모리 내 반응형 메시징과 상호 작용하고 Apache Kafka 주제에서 지원합니다.
  • MicroProfile Metrics를 사용하여 지정된 채널에서 스트리밍되는 메시지 수를 확인합니다.

추가 리소스

  • Apache Kafka에 대한 자세한 내용은 Apache Kafka를 참조하십시오.

2.9.2. MicroProfile reactive 메시징 커넥터

커넥터를 사용하여 MicroProfile Reactive Messaging을 여러 외부 메시징 시스템과 통합할 수 있습니다. JBoss EAP용 MicroProfile은 Apache Kafka 커넥터와 함께 제공됩니다. Eclipse MicroProfile Config 사양을 사용하여 커넥터를 구성합니다.

Apache Kafka 커넥터 및 통합 계층

MicroProfile Reactive Messaging에는 MicroProfile Config로 구성할 수 있는 Kafka 커넥터가 포함되어 있습니다. Kafka 커넥터는 microprofile-reactive-messaging-kafkamicroprofile-reactive-messaging Galleon 계층을 통합합니다. microprofile-reactive-messaging 계층은 핵심 MicroProfile Reactive Messaging 기능을 제공합니다.

표 2.1. Reactive messaging and Apache Kafka connector Galleon Layer
계층정의

microprofile-reactive-streams-operators

  • MicroProfile Reactive Streams Operator API를 제공하고 모듈 구현을 지원합니다.
  • SmallRye 확장 및 하위 시스템이 포함된 MicroProfile Reactive Streams Operator가 포함되어 있습니다.
  • cdi 계층에 따라 다릅니다.

    • CDI 는 Jakarta Contexts and dependency Cryostat의 약자이며 @Inject 기능을 추가하는 하위 시스템을 제공합니다.

microprofile-reactive-messaging

  • MicroProfile Reactive Messaging API를 제공하고 모듈 구현을 지원합니다.
  • SmallRye 확장 및 하위 시스템이 포함된 MicroProfile을 포함합니다.
  • microprofile-configmicroprofile-reactive-streams-operators 계층에 따라 다릅니다.

microprofile-reactive-messaging-kafka

  • MicroProfile Reactive Messaging이 Kafka와 상호 작용할 수 있는 Kafka 커넥터 모듈을 제공합니다.
  • microprofile-reactive-messaging 계층에 따라 달라집니다.

2.9.3. Apache Kafka 이벤트 스트리밍 플랫폼

Apache Kafka는 실시간으로 레코드 스트림을 게시, 구독, 저장 및 처리할 수 있는 오픈 소스 분산 이벤트(데이터) 스트리밍 플랫폼입니다. 여러 소스의 이벤트 스트림을 처리하고 여러 소비자에 전달하여 대량의 데이터를 A에서 Z로 이동하고 다른 모든 위치에서 동시에 이동합니다. MicroProfile Reactive Messaging은 Apache Kafka를 사용하여 이러한 이벤트 레코드를 2 마이크로초 미만으로 제공하여 분산된 내결함성 클러스터에 안전하게 저장하고 모든 팀 정의 영역 또는 지역 리전에서 사용할 수 있도록 합니다.

3장. JBoss EAP에서 MicroProfile 관리

3.1. MicroProfile OpenTracing 관리

중요

REST 호출을 위해 내보낸 중복 추적이 표시되면 microprofile-opentracing-overcloudrye 하위 시스템을 비활성화합니다. microprofile-opentracing-undercloudrye 를 비활성화하는 방법에 대한 자세한 내용은 microprofile-opentracing-overcloudrye 하위 시스템 제거를 참조하십시오.

3.1.1. MicroProfile Open Tracing 활성화

다음 관리 CLI 명령을 사용하여 서버 구성에 하위 시스템을 추가하여 서버 인스턴스에 전역적으로 MicroProfile Open Tracing 기능을 활성화합니다.

프로세스

  1. 다음 관리 명령을 사용하여 microprofile-opentracing-undercloudrye 하위 시스템을 활성화합니다.

    /subsystem=microprofile-opentracing-smallrye:add()
  2. 변경 사항을 적용하려면 서버를 다시 로드합니다.

    reload

3.1.2. microprofile-opentracing-Neutronrye 하위 시스템 제거

microprofile-opentracing-#159rye 하위 시스템은 기본 JBoss EAP 7.4 구성에 포함되어 있습니다. 이 하위 시스템은 JBoss EAP 7.4에 대한 MicroProfile OpenTracing 기능을 제공합니다. MicroProfile OpenTracing이 활성화된 시스템 메모리 또는 성능 저하가 발생하는 경우 microprofile-opentracing-undercloudrye 하위 시스템을 비활성화할 수 있습니다.

관리 CLI에서 제거 작업을 사용하여 지정된 서버에 대해 전역적으로 MicroProfile OpenTracing 기능을 비활성화할 수 있습니다.

프로세스

  1. microprofile-opentracing-Neutronrye 하위 시스템을 제거합니다.

    /subsystem=microprofile-opentracing-smallrye:remove()
  2. 변경 사항을 적용하려면 서버를 다시 로드합니다.

    reload

3.1.3. Jaeger 설치

docker 를 사용하여 Jaeger를 설치합니다.

사전 요구 사항

  • Docker 가 설치되어 있어야 합니다.

프로세스

  1. CLI에서 다음 명령을 실행하여 docker 를 사용하여 Jaeger를 설치합니다.

    $ docker run -d --name jaeger   -p 6831:6831/udp   -p 5778:5778   -p 14268:14268   -p 16686:16686   jaegertracing/all-in-one:1.16

3.2. MicroProfile Config 구성

3.2.1. ConfigSource 관리 리소스에 속성 추가

구성 소스 하위 시스템에 직접 속성을 관리 리소스로 저장할 수 있습니다.

프로세스

  • ConfigSource를 생성하고 속성을 추가합니다.

    /subsystem=microprofile-config-smallrye/config-source=props:add(properties={"name" = "jim"})

3.2.2. 디렉터리를 ConfigSources로 구성

속성이 파일로 디렉터리에 저장되면 file-name은 속성의 이름이고 파일 콘텐츠는 속성 값입니다.

프로세스

  1. 파일을 저장할 디렉터리를 생성합니다.

    $ mkdir -p ~/config/prop-files/
  2. 디렉터리로 이동합니다.

    $ cd ~/config/prop-files/
  3. 속성 이름 값을 저장할 파일 이름을 생성합니다.

    $ touch name
  4. 속성 값을 파일에 추가합니다.

    $ echo "jim" > name
  5. 파일 이름이 속성인 ConfigSource를 생성하고 파일의 값은 속성 값을 생성합니다.

    /subsystem=microprofile-config-smallrye/config-source=file-props:add(dir={path=~/config/prop-files})

    그러면 다음과 같은 XML 구성이 생성됩니다.

    <subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
        <config-source name="file-props">
            <dir path="/etc/config/prop-files"/>
        </config-source>
    </subsystem>

3.2.3. ConfigSource 클래스에서 ConfigSource 가져오기

사용자 지정 org.eclipse.microprofile.config.spi.ConfigSource 구현 클래스를 생성하고 구성 값에 대한 소스를 제공할 수 있습니다.

프로세스

  • 다음 관리 CLI 명령은 org.example 이라는 JBoss 모듈에서 제공하는 org.example.My ConfigSource 라는 구현 클래스에 대한 ConfigSource를 생성합니다.

    org.example 모듈의 ConfigSource 를 사용하려면 < module name="org.eclipse.microprofile.config.api"/ > 종속성을 path/to/org/example/main/module.xml 파일에 추가합니다.

    /subsystem=microprofile-config-smallrye/config-source=my-config-source:add(class={name=org.example.MyConfigSource, module=org.example})

    이 명령을 실행하면 microprofile-config-undercloudrye 하위 시스템에 대해 다음과 같은 XML 구성이 생성됩니다.

    <subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
        <config-source name="my-config-source">
            <class name="org.example.MyConfigSource" module="org.example"/>
        </config-source>
    </subsystem>

사용자 정의 org.eclipse.microprofile.config.spi.ConfigSource 구현 클래스에서 제공하는 속성은 모든 JBoss EAP 배포에서 사용할 수 있습니다.

3.2.4. ConfigSourceProvider 클래스에서 ConfigSource 구성 가져오기

여러 ConfigSource 인스턴스의 구현을 등록하는 사용자 지정 org.eclipse.microprofile.config.spi.ConfigSourceProvider 구현 클래스를 생성하고 구성할 수 있습니다.

프로세스

  • config-source-provider 를 생성합니다.

    /subsystem=microprofile-config-smallrye/config-source-provider=my-config-source-provider:add(class={name=org.example.MyConfigSourceProvider, module=org.example})

    이 명령은 org.example 이라는 JBoss 모듈에서 제공하는 org.example.MyConfigSourceProvider 라는 구현 클래스에 대해 config-source-provider 를 생성합니다.

    org.example 모듈의 config-source-provider 를 사용하려면 < module name="org.eclipse.microprofile.config.api"/ > 종속성을 path/to/org/example/main/module.xml 파일에 추가합니다.

    이 명령을 실행하면 microprofile-config-undercloudrye 하위 시스템에 대해 다음과 같은 XML 구성이 생성됩니다.

    <subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
        <config-source-provider name="my-config-source-provider">
             <class name="org.example.MyConfigSourceProvider" module="org.example"/>
        </config-source-provider>
    </subsystem>

ConfigSourceProvider 구현에서 제공하는 속성은 모든 JBoss EAP 배포에서 사용할 수 있습니다.

추가 리소스

  • JBoss EAP 서버에 글로벌 모듈을 추가하는 방법에 대한 자세한 내용은 JBoss EAP의 구성 가이드에서 글로벌 모듈 정의를 참조하십시오.

3.3. MicroProfile Fault Tolerance 구성

3.3.1. MicroProfile Fault Tolerance 확장 추가

MicroProfile Fault Tolerance 확장은 JBoss EAP XP의 일부로 제공되는 standalone-microprofile.xmlstandalone-microprofile-ha.xml 구성에 포함되어 있습니다.

확장은 표준 standalone.xml 구성에 포함되지 않습니다. 확장을 사용하려면 수동으로 활성화해야 합니다.

사전 요구 사항

  • EAP XP 팩이 설치되어 있습니다.

프로세스

  1. 다음 관리 CLI 명령을 사용하여 MicroProfile Fault Tolerance 확장을 추가합니다.

    /extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
  2. 다음 managenent 명령을 사용하여 microprofile-fault-tolerance-undercloudrye 하위 시스템을 활성화합니다.

    /subsystem=microprofile-fault-tolerance-smallrye:add
  3. 다음 관리 명령을 사용하여 서버를 다시 로드합니다.

    reload

3.4. MicroProfile 상태 구성

3.4.1. 관리 CLI를 사용하여 상태 검사

관리 CLI를 사용하여 시스템 상태를 확인할 수 있습니다.

프로세스

  • 상태를 검사합니다.

    /subsystem=microprofile-health-smallrye:check
    {
        "outcome" => "success",
        "result" => {
            "status" => "UP",
            "checks" => []
        }
    }

3.4.2. 관리 콘솔을 사용하여 상태 검사

관리 콘솔을 사용하여 시스템 상태를 확인할 수 있습니다.

검사 런타임 작업은 상태 점검과 글로벌 결과를 부울 값으로 표시합니다.

프로세스

  1. 런타임 탭으로 이동하여 서버를 선택합니다.
  2. Monitor 열에서 MicroProfile HealthView 를 클릭합니다.

3.4.3. HTTP 끝점을 사용하여 상태 검사

상태 점검은 JBoss EAP의 상태 컨텍스트에 자동으로 배포되므로 HTTP 끝점을 사용하여 현재 상태를 얻을 수 있습니다.

관리 인터페이스에서 액세스할 수 있는 /health 끝점의 기본 주소는 http://127.0.0.1:9990/health 입니다.

프로세스

  • HTTP 끝점을 사용하여 서버의 현재 상태를 얻으려면 다음 URL을 사용합니다.

    http://<host>:<port>/health

    이 컨텍스트에 액세스하면 서버가 정상 상태인지 여부를 나타내는 JSON 형식의 상태 점검이 표시됩니다.

3.4.4. MicroProfile 상태에 대한 인증 활성화

액세스를 위해 인증이 필요하도록 상태 컨텍스트를 구성할 수 있습니다.

프로세스

  1. microprofile-health-undercloudrye 하위 시스템에서 security- enabled 속성을 true 로 설정합니다.

    /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
  2. 변경 사항을 적용하려면 서버를 다시 로드합니다.

    reload

이후 /health 엔드포인트에 액세스하려고 하면 인증 프롬프트가 트리거됩니다.

3.4.5. 서버 상태 및 준비 상태를 확인하는 준비 상태 프로브

JBoss EAP XP 4.0.0은 서버 상태 및 준비 상태를 확인하기 위해 세 가지 준비 상태 프로브를 지원합니다.

  • server-status - server-state가 실행 중일 때 UP 을 반환합니다.
  • boot-errors - 프로브에서 부팅 오류를 감지하지 않으면 UP 을 반환합니다.
  • deployment-status - 모든 배포의 상태가 OK 이면 UP 을 반환합니다.

이러한 준비 상태 프로브는 기본적으로 활성화되어 있습니다. MicroProfile Config 속성 mp.health.disable-default-procedures 를 사용하여 프로브를 비활성화할 수 있습니다.

다음 예제에서는 검사 작업에서 세 개의 프로브를 사용하는 방법을 보여줍니다.

[standalone@localhost:9990 /] /subsystem=microprofile-health-smallrye:check
{
    "outcome" => "success",
    "result" => {
        "status" => "UP",
        "checks" => [
            {
                "name" => "boot-errors",
                "status" => "UP"
            },
            {
                "name" => "server-state",
                "status" => "UP",
                "data" => {"value" => "running"}
            },
            {
                "name" => "empty-readiness-checks",
                "status" => "UP"
            },
            {
                "name" => "deployments-status",
                "status" => "UP"
            },
            {
                "name" => "empty-liveness-checks",
                "status" => "UP"
            },
            {
                "name" => "empty-startup-checks",
                "status" => "UP"
            }
        ]
    }
}

3.4.6. 프로브가 정의되지 않은 경우 글로벌 상태

:empty-readiness-checks-status,:empty-liveness -checks-status, :empty-startup-checks-status 관리 속성은 준비 상태, 활성 상태 또는 시작 프로브가 정의되지 않은 경우 글로벌 상태를 지정합니다.

이러한 속성을 사용하면 애플리케이션이 애플리케이션이 준비되었는지, 실시간 또는 시작 여부를 확인할 때까지 애플리케이션이 'DOWN'을 보고할 수 있습니다. 기본적으로 애플리케이션은 'UP'을 보고합니다.

  • :empty- readiness -checks-status 속성은 준비 프로브가 정의되지 않은 경우 준비 상태 프로브의 글로벌 상태를 지정합니다.

    /subsystem=microprofile-health-smallrye:read-attribute(name=empty-readiness-checks-status)
    {
        "outcome" => "success",
        "result" => expression "${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}"
    }
  • :empty- liveness -checks-status 속성은 활성 프로브가 정의되지 않은 경우 활성 프로브에 대한 글로벌 상태를 지정합니다.

    /subsystem=microprofile-health-smallrye:read-attribute(name=empty-liveness-checks-status)
    {
        "outcome" => "success",
        "result" => expression "${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}"
    }
  • :empty- startup -checks-status 속성은 시작 프로브가 정의되지 않은 경우 시작 프로브에 대한 글로벌 상태를 지정합니다.

    /subsystem=microprofile-health-smallrye:read-attribute(name=empty-startup-checks-status)
    {
        "outcome" => "success",
        "result" => expression "${env.MP_HEALTH_EMPTY_STARTUP_CHECKS_STATUS:UP}"
    }

    준비 상태 프로브,활성 상태 프로브 및 시작 프로브를 확인하는 /health HTTP 끝점 및 :check 작업도 이러한 특성을 고려합니다.

다음 예와 같이 이러한 속성을 수정할 수도 있습니다.

/subsystem=microprofile-health-smallrye:write-attribute(name=empty-readiness-checks-status,value=DOWN)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

3.5. MicroProfile JWT 구성

3.5.1. microprofile-jwt-Neutronrye 하위 시스템 활성화

MicroProfile JWT 통합은 microprofile-jwt-undercloudrye 하위 시스템에서 제공하며 기본 구성에 포함되어 있습니다. 기본 구성에 하위 시스템이 없으면 다음과 같이 추가할 수 있습니다.

사전 요구 사항

  • EAP XP가 설치되어 있어야 합니다.

프로세스

  1. JBoss EAP에서 MicroProfile JWT smallrye 확장을 활성화합니다.

    /extension=org.wildfly.extension.microprofile.jwt-smallrye:add
  2. microprofile-jwt-undercloudrye 하위 시스템을 활성화합니다.

    /subsystem=microprofile-jwt-smallrye:add
  3. 서버를 다시 로드합니다.

    reload

microprofile-jwt-Neutronrye 하위 시스템이 활성화됩니다.

3.6. MicroProfile 지표 관리

3.6.1. 관리 인터페이스에서 사용할 수 있는 지표

JBoss EAP 하위 시스템 지표는 Prometheus 형식으로 노출됩니다.

메트릭은 다음 컨텍스트를 사용하여 JBoss EAP 관리 인터페이스에서 자동으로 사용할 수 있습니다.

  • /metrics/ - MicroProfile 3.0 사양에 지정된 메트릭을 포함합니다.
  • /metrics/vendor - 메모리 풀과 같은 벤더별 메트릭이 포함되어 있습니다.
  • /metrics/application - MicroProfile Metrics API를 사용하는 배포된 애플리케이션 및 하위 시스템의 지표를 포함합니다.

지표 이름은 하위 시스템 및 속성 이름을 기반으로 합니다. 예를 들어, undertow 하위 시스템은 애플리케이션 배포의 모든 서블릿에 대한 지표 특성 request-count 를 노출합니다. 이 메트릭의 이름은 jboss_undertow_request_count 입니다. 접두사 jboss 는 JBoss EAP를 지표의 소스로 식별합니다.

3.6.2. HTTP 끝점을 사용하여 메트릭 검사

HTTP 끝점을 사용하여 JBoss EAP 관리 인터페이스에서 사용할 수 있는 메트릭을 검사합니다.

프로세스

  • curl 명령을 사용합니다.

    $ curl -v http://localhost:9990/metrics | grep -i type

3.6.3. MicroProfile Metrics HTTP 끝점에 대한 인증 활성화

사용자에게 컨텍스트에 액세스할 수 있도록 권한을 부여하도록 메트릭 컨텍스트를 구성합니다. 이 구성은 메트릭 컨텍스트의 모든 하위 컨텍스트로 확장됩니다.

프로세스

  1. microprofile-metrics-undercloudrye 하위 시스템에서 security- enabled 속성을 true 로 설정합니다.

    /subsystem=microprofile-metrics-smallrye:write-attribute(name=security-enabled,value=true)
  2. 변경 사항을 적용하려면 서버를 다시 로드합니다.

    reload

이후 지표 끝점에 액세스하려고 하면 인증 프롬프트가 표시됩니다.

3.6.4. 웹 서비스에 대한 요청 수 가져오기

요청 수 메트릭을 노출하는 웹 서비스의 요청 수를 가져옵니다.

다음 절차에서는 요청 수를 가져오기 위한 웹 서비스로 helloworld-rs quickstart를 사용합니다. 빠른 시작은 jboss-eap-quickstarts 에서 퀵 스타트를 다운로드할 수 있습니다.

전제 조건

  • 웹 서비스는 요청 수를 노출합니다.

프로세스

  1. undertow 하위 시스템에 대한 통계를 활성화합니다.

    • 통계가 활성화된 독립 실행형 서버를 시작합니다.

      $ ./standalone.sh -Dwildfly.statistics-enabled=true
    • 이미 실행 중인 서버의 경우 undertow 하위 시스템에 대한 통계를 활성화합니다.

      /subsystem=undertow:write-attribute(name=statistics-enabled,value=true)
  2. helloworld-rs 빠른 시작을 배포합니다.

    • 빠른 시작의 루트 디렉터리에서 Maven을 사용하여 웹 애플리케이션을 배포합니다.

      $ mvn clean install wildfly:deploy
  3. curl 명령을 사용하여 CLI에서 HTTP 끝점을 쿼리하고 request_count 에 대해 필터링합니다.

    $ curl -v http://localhost:9990/metrics |  grep request_count

    예상 출력:

    jboss_undertow_request_count_total{server="default-server",http_listener="default",} 0.0

    반환되는 속성 값은 0.0 입니다.

  4. 웹 브라우저에서 http://localhost:8080/helloworld-rs/에 있는 퀵 스타트에 액세스하고 링크 중 하나를 클릭합니다.
  5. CLI에서 HTTP 끝점을 다시 쿼리합니다.

    $ curl -v http://localhost:9990/metrics |  grep request_count

    예상 출력:

    jboss_undertow_request_count_total{server="default-server",http_listener="default",} 1.0

    이 값은 1.0 으로 업데이트됩니다.

    마지막 두 단계를 반복하여 요청 수가 업데이트되었는지 확인합니다.

3.7. MicroProfile OpenAPI 관리

3.7.1. MicroProfile OpenAPI 활성화

microprofile-openapi-undercloudrye 하위 시스템은 standalone-microprofile.xml 구성에 제공됩니다. 그러나 JBoss EAP XP는 기본적으로 standalone.xml 을 사용합니다. 이를 사용하려면 standalone.xml 에 하위 시스템을 포함해야 합니다.

또는 MicroProfile 하위 시스템 및 확장 기능을 사용하여 독립 실행형 구성 업데이트 절차에 따라 standalone.xml 구성 파일을 업데이트할 수 있습니다.

프로세스

  1. JBoss EAP에서 MicroProfile OpenAPI smallrye 확장을 활성화합니다.

    /extension=org.wildfly.extension.microprofile.openapi-smallrye:add()
  2. 다음 관리 명령을 사용하여 microprofile-openapi-undercloudrye 하위 시스템을 활성화합니다.

    /subsystem=microprofile-openapi-smallrye:add()
  3. 서버를 다시 로드합니다.

    reload

microprofile-openapi-Neutronrye 하위 시스템이 활성화됩니다.

3.7.2. Accept HTTP 헤더를 사용하여 MicroProfile OpenAPI 문서 요청

Accept HTTP 헤더를 사용하여 배포에서 MicroProfile OpenAPI 문서를 JSON 형식으로 요청합니다.

기본적으로 OpenAPI 엔드포인트는 YAML 문서를 반환합니다.

사전 요구 사항

  • 쿼리 중인 배포는 MicroProfile OpenAPI 문서를 반환하도록 구성됩니다.

프로세스

  • 다음 curl 명령을 실행하여 배포의 /openapi 엔드포인트를 쿼리합니다.

    $ curl -v -H'Accept: application/json' http://localhost:8080/openapi
    < HTTP/1.1 200 OK
    ...
    {"openapi": "3.0.1" ... }

    http://localhost:8080를 배포의 URL 및 포트로 교체합니다.

    Accept 헤더는 application/json 문자열을 사용하여 JSON 문서를 반환함을 나타냅니다.

3.7.3. HTTP 매개변수를 사용하여 MicroProfile OpenAPI 문서 요청

HTTP 요청의 쿼리 매개변수를 사용하여 배포에서 MicroProfile OpenAPI 문서를 요청합니다.

기본적으로 OpenAPI 엔드포인트는 YAML 문서를 반환합니다.

사전 요구 사항

  • 쿼리 중인 배포는 MicroProfile OpenAPI 문서를 반환하도록 구성됩니다.

프로세스

  • 다음 curl 명령을 실행하여 배포의 /openapi 엔드포인트를 쿼리합니다.

    $ curl -v http://localhost:8080/openapi?format=JSON
    < HTTP/1.1 200 OK
    ...

    http://localhost:8080를 배포의 URL 및 포트로 교체합니다.

    HTTP 매개변수 format=JSON 은 JSON 문서가 반환됨을 나타냅니다.

3.7.4. 정적 OpenAPI 문서를 제공하도록 JBoss EAP 구성

호스트의 REST 서비스를 설명하는 정적 OpenAPI 문서를 제공하도록 JBoss EAP를 구성합니다.

JBoss EAP가 정적 OpenAPI 문서를 제공하도록 구성된 경우 정적 OpenAPI 문서는 Jakarta RESTful Web Services 및 MicroProfile OpenAPI 주석보다 먼저 처리됩니다.

프로덕션 환경에서 정적 문서를 제공할 때 주석 처리를 비활성화합니다. 주석 처리를 비활성화하면 클라이언트에 변경 불가능한 버전이 지정된 API 계약을 사용할 수 있습니다.

프로세스

  1. 애플리케이션 소스 트리에 디렉터리를 생성합니다.

    $ mkdir APPLICATION_ROOT/src/main/webapp/META-INF

    APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일을 포함하는 디렉터리입니다.

  2. OpenAPI 엔드포인트를 쿼리하여 출력을 파일로 리디렉션합니다.

    $ curl http://localhost:8080/openapi?format=JSON > src/main/webapp/META-INF/openapi.json

    기본적으로 끝점은 YAML 문서를 제공하며 format=JSON 은 JSON 문서가 반환되도록 지정합니다.

  3. OpenAPI 문서 모델을 처리할 때 주석 스캔을 건너뛰도록 애플리케이션을 구성합니다.

    $ echo "mp.openapi.scan.disable=true" > APPLICATION_ROOT/src/main/webapp/META-INF/microprofile-config.properties
  4. 애플리케이션을 다시 빌드합니다.

    $ mvn clean install
  5. 다음 관리 CLI 명령을 사용하여 애플리케이션을 다시 배포합니다.

    1. 애플리케이션 배포를 취소합니다.

      undeploy microprofile-openapi.war
    2. 애플리케이션을 배포합니다.

      deploy APPLICATION_ROOT/target/microprofile-openapi.war

JBoss EAP는 이제 OpenAPI 엔드포인트에서 정적 OpenAPI 문서를 제공합니다.

3.7.5. microprofile-openapi-undercloudrye 비활성화

관리 CLI를 사용하여 JBoss EAP XP에서 microprofile-openapi-undercloudrye 하위 시스템을 비활성화할 수 있습니다.

프로세스

  • microprofile-openapi-Neutronrye 하위 시스템을 비활성화합니다.

    /subsystem=microprofile-openapi-smallrye:remove()

3.8. MicroProfile Reactive Messaging 관리

3.8.1. JBoss EAP에 필요한 MicroProfile reactive 메시징 확장 및 하위 시스템 구성

JBoss EAP 인스턴스에 비동기 반응 메시징을 활성화하려면 JBoss EAP 관리 CLI를 통해 확장을 추가해야 합니다.

사전 요구 사항

프로세스

  1. JBoss EAP 관리 CLI를 엽니다.
  2. 다음 코드를 입력합니다.
[standalone@localhost:9990 /] /extension=org.wildfly.extension.microprofile.reactive-messaging-smallrye:add
{"outcome" => "success"}

[standalone@localhost:9990 /] /subsystem=microprofile-reactive-messaging-smallrye:add
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
참고

OpenShift에서 Galleon을 사용하여 서버를 프로비저닝하는 경우 마이크로profile-reactive-messaging Galleon 계층을 포함하여 코어 MicroProfile 2.0.1 및 reactive 메시징 기능을 가져오고 필요한 하위 시스템 및 확장을 활성화하십시오. 이 구성에는 Kafka 커넥터 기능을 활성화하는 데 필요한 JBoss EAP 모듈이 포함되어 있지 않습니다. 이렇게 하려면 microprofile-reactive-messaging-kafka 계층을 사용합니다.

검증

관리 CLI에서 결과 코드에서 두 곳에서 성공이 표시되는 경우 JBoss EAP에 필요한 MicroProfile Reactive Messaging 확장 및 하위 시스템을 성공적으로 추가했습니다.

작은 정보

결과 코드에서 reload-required 라고 하는 경우 서버 구성을 다시 로드하여 모든 변경 사항을 완전히 적용해야 합니다. 다시 로드하려면 독립 실행형 서버 CLI에서 reload 를 입력합니다.

3.9. 독립 실행형 서버 구성

3.9.1. 독립 실행형 서버 구성 파일

JBoss EAP XP에는 독립 실행형 서버 구성 파일, standalone-microprofile.xmlstandalone-microprofile-ha.xml 이 포함되어 있습니다.

JBoss EAP에 포함된 표준 구성 파일은 변경되지 않습니다. JBoss EAP XP 4.0.0은 domain.xml 파일 또는 도메인 모드를 지원하지 않습니다.

표 3.1. JBoss EAP XP에서 사용 가능한 독립 실행형 구성 파일
구성 파일목적포함된 기능제외된 기능

standalone.xml

독립 실행형 서버를 시작할 때 사용되는 기본 구성입니다.

하위 시스템, 네트워킹, 배포, 소켓 바인딩 및 기타 구성 가능한 세부 정보를 포함하여 서버에 대한 정보를 포함합니다.

메시징 또는 고가용성에 필요한 하위 시스템을 제외합니다.

standalone-microprofile.xml

이 구성 파일은 MicroProfile을 사용하는 애플리케이션을 지원합니다.

하위 시스템, 네트워킹, 배포, 소켓 바인딩 및 기타 구성 가능한 세부 정보를 포함하여 서버에 대한 정보를 포함합니다.

다음 기능을 제외합니다.

  • Jakarta Enterprise Cryostats
  • 메시징
  • Jakarta EE Batch
  • Jakarta Server seems
  • Jakarta Enterprise Cryostat 타이머

standalone-ha.xml

 

기본 하위 시스템을 포함하고 고가용성을 위해 modclusterjgroups 하위 시스템을 추가합니다.

메시징에 필요한 하위 시스템을 제외합니다.

standalone-microprofile-ha.xml

이 독립 실행형 파일은 MicroProfile을 사용하는 애플리케이션을 지원합니다.

기본 하위 시스템 외에도 고가용성을 위해 modclusterjgroups 하위 시스템을 포함합니다.

메시징에 필요한 하위 시스템을 제외합니다.

standalone-full.xml

 

기본 하위 시스템 외에도 messaging-activemqiiop-openjdk 하위 시스템을 포함합니다.

 

standalone-full-ha.xml

가능한 모든 하위 시스템을 지원합니다.

기본 하위 시스템 외에도 메시징 및 고가용성을 위한 하위 시스템 포함.

 

standalone-load-balancer.xml

기본 제공 mod_cluster 프런트 엔드 로드 밸런서를 사용하여 다른 JBoss EAP 인스턴스의 부하를 분산하는 데 필요한 최소 하위 시스템 지원.

  

기본적으로 JBoss EAP를 독립 실행형 서버로 시작하면 standalone.xml 파일이 사용됩니다. 독립 실행형 MicroProfile 구성으로 JBoss EAP를 시작하려면 -c 인수를 사용합니다. 예를 들면 다음과 같습니다.

$ EAP_HOME/bin/standalone.sh -c=standalone-microprofile.xml

3.9.2. MicroProfile 하위 시스템 및 확장을 사용하여 독립 실행형 구성 업데이트

docs/examples/enable-microprofile.cli 스크립트를 사용하여 MicroProfile 하위 시스템 및 확장을 사용하여 표준 독립 실행형 서버 구성 파일을 업데이트할 수 있습니다. enable-microprofile.cli 스크립트는 사용자 지정 구성이 아닌 표준 독립 실행형 서버 구성 파일을 업데이트하기 위한 예제 스크립트로 사용됩니다.

enable-microprofile.cli 스크립트는 기존 독립 실행형 서버 구성을 수정하고 독립 실행형 구성 파일에 없는 경우 다음 MicroProfile 하위 시스템 및 확장을 추가합니다.

  • microprofile-config-smallrye
  • microprofile-fault-tolerance-smallrye
  • microprofile-health-smallrye
  • microprofile-jwt-smallrye
  • microprofile-metrics-smallrye
  • microprofile-openapi-smallrye
  • microprofile-opentracing-smallrye

enable-microprofile.cli 스크립트는 수정 사항에 대한 높은 수준의 설명을 출력합니다. 구성은 elytron 하위 시스템을 사용하여 보호됩니다. 보안 하위 시스템은 (있는 경우) 구성에서 제거됩니다.

사전 요구 사항

  • JBoss EAP XP가 설치되어 있습니다.

프로세스

  1. 다음 CLI 스크립트를 실행하여 기본 standalone.xml 서버 구성 파일을 업데이트합니다.

    $ EAP_HOME/bin/jboss-cli.sh --file=docs/examples/enable-microprofile.cli
  2. 다음 명령을 사용하여 기본 standalone.xml 서버 구성 파일 이외의 독립 실행형 서버 구성을 선택합니다.

    $ EAP_HOME/bin/jboss-cli.sh --file=docs/examples/enable-microprofile.cli -Dconfig=<standalone-full.xml|standalone-ha.xml|standalone-full-ha.xml>
  3. 이제 지정된 구성 파일에 MicroProfile 하위 시스템 및 확장 기능이 포함됩니다.

4장. JBoss EAP용 MicroProfile 애플리케이션 개발

4.1. Maven 및 JBoss EAP MicroProfile Maven 리포지토리

4.1.1. JBoss EAP MicroProfile Maven 리포지토리 패치를 아카이브 파일로 다운로드

JBoss EAP용 MicroProfile 확장 팩이 릴리스될 때마다 JBoss EAP MicroProfile Maven 리포지토리에 해당하는 패치가 제공됩니다. 이 패치는 기존 Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven 리포지토리에 추출된 증분 아카이브 파일로 제공됩니다. 증분 아카이브 파일은 기존 파일을 덮어쓰거나 제거하지 않으므로 롤백 요구 사항이 없습니다.

프로세스

  1. 브라우저를 열고 Red Hat 고객 포털에 로그인합니다.
  2. 페이지 상단의 메뉴에서 다운로드를 선택합니다.
  3. 목록에서 Red Hat JBoss Enterprise Application Platform 항목을 찾아 선택합니다.
  4. 제품 드롭다운 목록에서 JBoss EAP XP 를 선택합니다.
  5. 버전 드롭다운 목록에서 4.0.0 을 선택합니다.
  6. 릴리스 탭을 클릭합니다.
  7. 목록에서 JBoss EAP XP 4.0.0 증분 Maven 리포지토리 를 찾은 다음 다운로드를 클릭합니다.
  8. 아카이브 파일을 로컬 디렉터리에 저장합니다.

추가 리소스

4.1.2. 로컬 시스템에 JBoss EAP MicroProfile Maven 리포지토리 패치 적용

로컬 파일 시스템에 JBoss EAP MicroProfile Maven 리포지토리 패치를 설치할 수 있습니다.

증분 아카이브 파일 형태로 패치를 리포지토리에 적용하면 새 파일이 이 리포지토리에 추가됩니다. 증분 아카이브 파일은 리포지토리에서 기존 파일을 덮어쓰거나 제거하지 않으므로 롤백 요구 사항이 없습니다.

사전 요구 사항

  • 로컬 시스템에 Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven 리포지토리를 다운로드하여 설치했습니다.

    • 로컬 시스템에 Red Hat JBoss Enterprise Application Platform 7.4 Maven 리포지토리의 마이너 버전이 설치되어 있는지 확인합니다.
  • 로컬 시스템에 JBoss EAP XP 4.0.0 증분 Maven 리포지토리를 다운로드했습니다.

프로세스

  1. Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven 리포지토리의 경로를 찾습니다. 예를 들어 /path/to/repo/jboss-eap-7.4.0.GA-maven-repository/.
  2. 다운로드한 JBoss EAP XP 4.0.0 증분 Maven 리포지토리를 Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven 리포지토리의 디렉터리에 직접 추출합니다. 예를 들어 터미널을 열고 다음 명령을 실행하여 Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven 리포지토리 경로의 값을 교체합니다.

    $ unzip -o jboss-eap-xp-4.0.0-incremental-maven-repository.zip -d EAP_MAVEN_REPOSITORY_PATH
참고

EAP_MAVEN_REPOSITORY_PATHjboss-eap-7.4.0.GA-maven-repository 를 가리킵니다. 예를 들어 이 절차에서는 경로 /path/to/repo/jboss-eap-7.4.0.GA-maven-repository/ 를 사용하는 방법을 보여줍니다.

JBoss EAP XP Incremental Maven 리포지토리를 Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven 리포지토리에 추출한 후 리포지토리 이름은 JBoss EAP MicroProfile Maven 리포지토리가 됩니다.

4.1.3. 지원되는 JBoss EAP MicroProfile BOM

JBoss EAP XP 4.0.0에는 JBoss EAP MicroProfile BOM이 포함되어 있습니다. 이 BOM의 이름은 jboss-eap-xp-microprofile 이며, 사용 사례는 JBoss EAP MicroProfile API를 지원합니다.

표 4.1. JBoss EAP MicroProfile BOM
BOM Artifact ID사용 사례

jboss-eap-xp-microprofile

groupIdorg.jboss.bom 인 이 BOM은 microprofile-openapi-apimicroprofile-config-api 와 같은 많은 JBoss EAP MicroProfile 지원 API 종속 항목을 패키징합니다. jboss-eap-xp-microprofile BOM이 종속성에 대해 이 값을 지정하므로 이 BOM을 사용하는 경우 지원되는 API 종속성에 대한 버전을 지정할 필요가 없습니다.

4.1.4. JBoss EAP MicroProfile Maven 리포지토리 사용

Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven 리포지토리를 설치한 후 jboss-eap-xp-microprofile BOM에 액세스하여 JBoss EAP XP Incremental Maven 리포지토리를 적용할 수 있습니다. 그러면 리포지토리 이름이 JBoss EAP MicroProfile Maven 리포지토리가 됩니다. BOM은 JBoss EAP XP Incremental Maven 리포지토리 내에 제공됩니다.

JBoss EAP MicroProfile Maven 리포지토리를 사용하려면 다음 중 하나를 구성해야 합니다.

  • Maven 글로벌 또는 사용자 설정
  • 프로젝트의 POM 파일

공유 서버의 리포지토리 관리자 또는 리포지토리와 함께 사용되는 Maven 설정은 프로젝트의 제어 및 관리 가능성을 개선할 수 있습니다.

대체 미러를 사용하여 특정 저장소에 대한 모든 조회 요청을 프로젝트 파일을 변경하지 않고 리포지토리 관리자로 리디렉션할 수 있습니다.

주의

POM 파일을 수정하여 JBoss EAP MicroProfile Maven 리포지토리를 구성하면 구성된 프로젝트의 글로벌 및 사용자 Maven 설정이 재정의됩니다.

사전 요구 사항

  • 로컬 시스템에 Red Hat JBoss Enterprise Application Platform 7.4 Maven 리포지토리를 설치했으며 JBoss EAP XP Incremental Maven 리포지토리를 적용했습니다.

프로세스

  1. 구성 방법을 선택하고 JBoss EAP MicroProfile Maven 리포지토리를 구성합니다.
  2. JBoss EAP MicroProfile Maven 리포지토리를 구성한 후 jboss-eap-xp-microprofile BOM을 POM 파일에 추가합니다. 다음 예제에서는 pom.xml 파일의 < dependencyManagement&gt; 섹션에서 BOM을 구성하는 방법을 보여줍니다.

    <dependencyManagement>
      <dependencies>
        ...
        <dependency>
          <groupId>org.jboss.bom</groupId>
          <artifactId>jboss-eap-xp-microprofile</artifactId>
          <version>4.0.0.GA</version>
          <type>pom</type>
          <scope>import</scope>
      </dependency>
        ...
      </dependencies>
    </dependencyManagement>
    참고

    pom.xml 파일에서 type 요소의 값을 지정하지 않으면 Maven은 요소의 ScanSetting 값을 지정합니다.

추가 리소스

  • JBoss EAP Maven 리포지토리를 구성할 방법을 선택하는 방법에 대한 자세한 내용은 JBoss EAP 개발 가이드 의 Maven 리포지토리 사용을 참조하십시오.
  • 종속성 관리에 대한 자세한 내용은 종속성 관리를 참조하십시오 .

4.2. MicroProfile Config 개발

4.2.1. MicroProfile Config에 대한 Maven 프로젝트 생성

MicroProfile Config 애플리케이션을 생성하기 위한 디렉터리 구조와 필수 종속성을 사용하여 Maven 프로젝트를 생성합니다.

사전 요구 사항

  • Maven이 설치되어 있어야 합니다.

프로세스

  1. Maven 프로젝트를 설정합니다.

    $ mvn archetype:generate \
        -DgroupId=com.example \
        -DartifactId=microprofile-config \
        -DinteractiveMode=false \
        -DarchetypeGroupId=org.apache.maven.archetypes \
        -DarchetypeArtifactId=maven-archetype-webapp
    cd microprofile-config

    이렇게 하면 프로젝트 및 pom.xml 구성 파일에 대한 디렉터리 구조가 생성됩니다.

  2. POM 파일이 jboss-eap-xp-microprofile BOM의 MicroProfile Config 아티팩트 및 MicroProfile REST Client 아티팩트를 자동으로 관리하도록 하려면 POM 파일의 < dependencyManagement > 섹션으로 BOM을 가져옵니다.

    <dependencyManagement>
      <dependencies>
        <!-- importing the microprofile BOM adds MicroProfile specs -->
        <dependency>
            <groupId>org.jboss.bom</groupId>
            <artifactId>jboss-eap-xp-microprofile</artifactId>
            <version>4.0.0.GA</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
      </dependencies>
    </dependencyManagement>
  3. MicroProfile Config 아티팩트와 MicroProfile REST 클라이언트 아티팩트 및 BOM에서 관리하는 기타 종속성을 POM 파일의 < dependency > 섹션에 추가합니다. 다음 예제에서는 MicroProfile Config 및 MicroProfile REST Client 종속 항목을 파일에 추가하는 방법을 보여줍니다.

    <!-- Add the MicroProfile REST Client API. Set provided for the <scope> tag, as the API is included in the server. -->
    <dependency>
      <groupId>org.eclipse.microprofile.rest.client</groupId>
      <artifactId>microprofile-rest-client-api</artifactId>
      <scope>provided</scope>
    </dependency>
    <!-- Add the MicroProfile Config API. Set provided for the <scope> tag, as the API is included in the server. -->
    <dependency>
      <groupId>org.eclipse.microprofile.config</groupId>
      <artifactId>microprofile-config-api</artifactId>
      <scope>provided</scope>
    </dependency>
    <!-- Add the {JAX-RS} API. Set provided for the <scope> tag, as the API is included in the server. -->
    <dependency>
      <groupId>org.jboss.spec.javax.ws.rs</groupId>
      <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
      <scope>provided</scope>
    </dependency>
    <!-- Add the CDI API. Set provided for the <scope> tag, as the API is included in the server. -->
    <dependency>
      <groupId>jakarta.enterprise</groupId>
      <artifactId>jakarta.enterprise.cdi-api</artifactId>
      <scope>provided</scope>
    </dependency>

4.2.2. 애플리케이션에서 MicroProfile Config 속성 사용

구성된 ConfigSource 를 사용하는 애플리케이션을 생성합니다.

사전 요구 사항

  • JBoss EAP에서 MicroProfile Config가 활성화되어 있습니다.
  • 최신 POM이 설치되어 있어야 합니다.
  • Maven 프로젝트는 MicroProfile Config 애플리케이션을 생성하기 위해 구성됩니다.

프로세스

  1. 클래스 파일을 저장할 디렉터리를 생성합니다.

    $ mkdir -p APPLICATION_ROOT/src/main/java/com/example/microprofile/config/

    여기서 APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일이 포함된 디렉터리입니다.

  2. 새 디렉터리로 이동합니다.

    $ cd APPLICATION_ROOT/src/main/java/com/example/microprofile/config/

    이 디렉터리에 설명된 클래스 파일을 모두 만듭니다.

  3. 다음 콘텐츠를 사용하여 HelloApplication.java 라는 클래스 파일을 생성합니다.

    package com.example.microprofile.config;
    
    import javax.ws.rs.ApplicationPath;
    import javax.ws.rs.core.Application;
    
    @ApplicationPath("/")
    public class HelloApplication extends Application {
    
    }

    이 클래스는 애플리케이션을 Jakarta RESTful Web Services 애플리케이션으로 정의합니다.

  4. 다음 콘텐츠를 사용하여 HelloService.java 라는 클래스 파일을 생성합니다.

    package com.example.microprofile.config;
    
    public class HelloService {
    	String createHelloMessage(String name){
            return "Hello " + name;
        }
    }
  5. 다음 콘텐츠를 사용하여 HelloWorld.java 라는 클래스 파일을 생성합니다.

    package com.example.microprofile.config;
    
    import javax.inject.Inject;
    import javax.ws.rs.GET;
    import javax.ws.rs.Path;
    import javax.ws.rs.Produces;
    import org.eclipse.microprofile.config.inject.ConfigProperty;
    
    @Path("/config")
    public class HelloWorld {
    
        @Inject
        @ConfigProperty(name="name", defaultValue="jim") 1
        String name;
    
       	@Inject
       	HelloService helloService;
    
       	@GET
       	@Path("/json")
       	@Produces({ "application/json" })
       	public String getHelloWorldJSON() {
            String message = helloService.createHelloMessage(name);
           	return "{\"result\":\"" + message + "\"}";
    	}
    }
    1
    MicroProfile Config 속성은 @ConfigProperty(name="name", defaultValue="jim") 주석을 사용하여 클래스에 삽입됩니다. ConfigSource 가 구성되지 않은 경우 jim 값이 반환됩니다.
  6. src/main/webapp/WEB-INF/ 디렉터리에 beans.xml 이라는 빈 파일을 만듭니다.

    $ touch APPLICATION_ROOT/src/main/webapp/WEB-INF/beans.xml

    여기서 APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일이 포함된 디렉터리입니다.

  7. 애플리케이션의 루트 디렉터리로 이동합니다.

    $ cd APPLICATION_ROOT

    여기서 APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일이 포함된 디렉터리입니다.

  8. 프로젝트를 빌드합니다.

    $ mvn clean install wildfly:deploy
  9. 출력을 테스트합니다.

    $ curl http://localhost:8080/microprofile-config/config/json

    다음은 예상되는 출력입니다.

    {"result":"Hello jim"}

4.3. MicroProfile Fault Tolerance 애플리케이션 개발

4.3.1. MicroProfile Fault Tolerance 확장 추가

MicroProfile Fault Tolerance 확장은 JBoss EAP XP의 일부로 제공되는 standalone-microprofile.xmlstandalone-microprofile-ha.xml 구성에 포함되어 있습니다.

확장은 표준 standalone.xml 구성에 포함되지 않습니다. 확장을 사용하려면 수동으로 활성화해야 합니다.

사전 요구 사항

  • EAP XP 팩이 설치되어 있습니다.

프로세스

  1. 다음 관리 CLI 명령을 사용하여 MicroProfile Fault Tolerance 확장을 추가합니다.

    /extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
  2. 다음 managenent 명령을 사용하여 microprofile-fault-tolerance-undercloudrye 하위 시스템을 활성화합니다.

    /subsystem=microprofile-fault-tolerance-smallrye:add
  3. 다음 관리 명령을 사용하여 서버를 다시 로드합니다.

    reload

4.3.2. MicroProfile Fault Tolerance에 대한 Maven 프로젝트 구성

MicroProfile Fault Tolerance 애플리케이션을 생성하기 위한 디렉터리 구조와 필수 종속성을 사용하여 Maven 프로젝트를 생성합니다.

사전 요구 사항

  • Maven이 설치되어 있어야 합니다.

프로세스

  1. Maven 프로젝트를 설정합니다.

    mvn archetype:generate \
        -DgroupId=com.example.microprofile.faulttolerance \
        -DartifactId=microprofile-fault-tolerance \
        -DarchetypeGroupId=org.apache.maven.archetypes \
        -DarchetypeArtifactId=maven-archetype-webapp \
        -DinteractiveMode=false
    cd microprofile-fault-tolerance

    명령은 프로젝트에 대한 디렉터리 구조와 pom.xml 구성 파일을 생성합니다.

  2. POM 파일이 jboss-eap-xp-microprofile BOM의 MicroProfile Fault Tolerance 아티팩트 버전을 자동으로 관리하도록 하려면 POM 파일의 < dependencyManagement > 섹션으로 BOM을 가져옵니다.

    <dependencyManagement>
      <dependencies>
        <!-- importing the microprofile BOM adds MicroProfile specs -->
        <dependency>
            <groupId>org.jboss.bom</groupId>
            <artifactId>jboss-eap-xp-microprofile</artifactId>
            <version>${version.microprofile.bom}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
      </dependencies>
    </dependencyManagement>

    ${version.microprofile.bom}을 설치된 BOM 버전으로 교체합니다.

  3. BOM에서 관리하는 MicroProfile Fault Tolerance 아티팩트를 POM 파일의 & lt;dependency > 섹션에 추가합니다. 다음 예제에서는 파일에 MicroProfile Fault Tolerance 종속성을 추가하는 방법을 보여줍니다.

    <!-- Add the MicroProfile Fault Tolerance API. Set provided for the <scope> tag, as the API is included in the server. -->
    <dependency>
      <groupId>org.eclipse.microprofile.fault.tolerance</groupId>
      <artifactId>microprofile-fault-tolerance-api</artifactId>
      <scope>provided</scope>
    </dependency>

4.3.3. 내결함성 애플리케이션 생성

내결함성에 대한 재시도, 시간 초과 및 대체 패턴을 구현하는 내결함성 애플리케이션을 생성합니다.

사전 요구 사항

  • Maven 종속 항목이 구성되었습니다.

프로세스

  1. 클래스 파일을 저장할 디렉터리를 생성합니다.

    $ mkdir -p APPLICATION_ROOT/src/main/java/com/example/microprofile/faulttolerance

    APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일을 포함하는 디렉터리입니다.

  2. 새 디렉터리로 이동합니다.

    $ cd APPLICATION_ROOT/src/main/java/com/example/microprofile/faulttolerance

    다음 단계에서는 새 디렉터리에 클래스 파일을 모두 생성합니다.

  3. 다음 콘텐츠를 사용하여 Coffee.java로 Coffee.java 로 Coffee 샘플을 나타내는 간단한 엔터티를 생성합니다.

    package com.example.microprofile.faulttolerance;
    
    public class Coffee {
    
        public Integer id;
        public String name;
        public String countryOfOrigin;
        public Integer price;
    
        public Coffee() {
        }
    
        public Coffee(Integer id, String name, String countryOfOrigin, Integer price) {
            this.id = id;
            this.name = name;
            this.countryOfOrigin = countryOfOrigin;
            this.price = price;
        }
    }
  4. 다음 내용으로 클래스 파일 CoffeeApplication.java 를 생성합니다.

    package com.example.microprofile.faulttolerance;
    
    import javax.ws.rs.ApplicationPath;
    import javax.ws.rs.core.Application;
    
    @ApplicationPath("/")
    public class CoffeeApplication extends Application {
    }
  5. 다음 콘텐츠를 사용하여 CoffeeRepositoryService.java 로 Jakarta Contexts 및 dependency Cryostat Cryostat를 생성합니다.

    package com.example.microprofile.faulttolerance;
    
    import java.util.ArrayList;
    import java.util.Collections;
    import java.util.HashMap;
    import java.util.List;
    import java.util.Map;
    import java.util.stream.Collectors;
    import javax.enterprise.context.ApplicationScoped;
    
    @ApplicationScoped
    public class CoffeeRepositoryService {
    
        private Map<Integer, Coffee> coffeeList = new HashMap<>();
    
        public CoffeeRepositoryService() {
            coffeeList.put(1, new Coffee(1, "Fernandez Espresso", "Colombia", 23));
            coffeeList.put(2, new Coffee(2, "La Scala Whole Beans", "Bolivia", 18));
            coffeeList.put(3, new Coffee(3, "Dak Lak Filter", "Vietnam", 25));
        }
    
        public List<Coffee> getAllCoffees() {
            return new ArrayList<>(coffeeList.values());
        }
    
        public Coffee getCoffeeById(Integer id) {
            return coffeeList.get(id);
        }
    
        public List<Coffee> getRecommendations(Integer id) {
            if (id == null) {
                return Collections.emptyList();
            }
            return coffeeList.values().stream()
                    .filter(coffee -> !id.equals(coffee.id))
                    .limit(2)
                    .collect(Collectors.toList());
        }
    }
  6. 다음 내용으로 클래스 파일 CoffeeResource.java 를 생성합니다.

    package com.example.microprofile.faulttolerance;
    
    import java.util.List;
    import java.util.Random;
    import java.util.concurrent.atomic.AtomicLong;
    import javax.inject.Inject;
    import javax.ws.rs.GET;
    import javax.ws.rs.Path;
    import javax.ws.rs.Produces;
    import javax.ws.rs.core.MediaType;
    import java.util.Collections;
    import javax.ws.rs.PathParam;
    import org.eclipse.microprofile.faulttolerance.Fallback;
    import org.eclipse.microprofile.faulttolerance.Timeout;
    import org.eclipse.microprofile.faulttolerance.Retry;
    
    @Path("/coffee")
    @Produces(MediaType.APPLICATION_JSON)
    public class CoffeeResource {
    
        @Inject
        private CoffeeRepositoryService coffeeRepository;
    
        private AtomicLong counter = new AtomicLong(0);
    
        @GET
        @Retry(maxRetries = 4) 1
        public List<Coffee> coffees() {
            final Long invocationNumber = counter.getAndIncrement();
            return coffeeRepository.getAllCoffees();
        }
    
    
        @GET
        @Path("/{id}/recommendations")
        @Timeout(250) 2
        public List<Coffee> recommendations(@PathParam("id") int id) {
                return coffeeRepository.getRecommendations(id);
            }
    
        @GET
        @Path("fallback/{id}/recommendations")
        @Fallback(fallbackMethod = "fallbackRecommendations") 3
        public List<Coffee> recommendations2(@PathParam("id") int id) {
            return coffeeRepository.getRecommendations(id);
            }
    
        public List<Coffee> fallbackRecommendations(int id) {
            //always return a default coffee
            return Collections.singletonList(coffeeRepository.getCoffeeById(1));
        }
    }
    1
    re-tries 수를 4 로 정의합니다.
    2
    시간 초과 간격을 밀리초 단위로 정의합니다.
    3
    호출이 실패할 때 호출할 대체 메서드를 정의합니다.
  7. 애플리케이션의 루트 디렉터리로 이동합니다.

    $ cd APPLICATION_ROOT
  8. 다음 Maven 명령을 사용하여 애플리케이션을 빌드합니다.

    $ mvn clean install wildfly:deploy

    http://localhost:8080/microprofile-fault-tolerance/coffee 에서 애플리케이션에 액세스합니다.

추가 리소스

  • 애플리케이션의 내결함성을 테스트하는 인공 실패를 포함하는 내결함성 애플리케이션의 자세한 예는 microprofile-fault-tolerance 빠른 시작을 참조하십시오.

4.4. MicroProfile 상태 개발

4.4.1. 사용자 정의 상태 점검 예

microprofile-health-undercloudrye 하위 시스템에서 제공하는 기본 구현은 기본 상태 점검을 수행합니다. 자세한 내용은 서버 또는 애플리케이션 상태에 대한 사용자 지정 상태 점검이 포함될 수 있습니다. org.eclipse.microprofile.health.Liveness,org.eclipse.microprofile.health.Readiness 또는 org.eclipse.microprofile.health.Startup 주석을 포함하는 모든 Jakarta Contexts 및Dependency ans는 런타임 시 자동으로 검색되고 호출됩니다.

다음 예제에서는 UP 상태를 반환하는 상태 점검의 새 구현을 생성하는 방법을 보여줍니다.

import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Liveness;

import javax.enterprise.context.ApplicationScoped;

@Liveness
@ApplicationScoped
public class HealthTest implements HealthCheck {

    @Override
    public HealthCheckResponse call() {
        return HealthCheckResponse.named("health-test").up().build();
    }
}

상태 점검을 배포한 후 다음 예와 같이 후속 상태 점검 쿼리에 사용자 정의 검사가 포함됩니다.

[standalone@localhost:9990 /] /subsystem=microprofile-health-smallrye:check
{
    "outcome" => "success",
    "result" => {
        "status" => "UP",
        "checks" => [
            {
                "name" => "deployments-status",
                "status" => "UP",
                "data" => {"<deployment_name>.war" => "OK"}
            },
            {
                "name" => "server-state",
                "status" => "UP",
                "data" => {"value" => "running"}
            },
            {
                "name" => "boot-errors",
                "status" => "UP"
            },
            {
                "name" => "health-test",
                "status" => "UP"
            },
            {
                "name" => "ready-deployment.<deployment_name>.war,
                "status" => "UP"
            },
            {
                "name" => "started-deployment.<deployment_name>.war",
                "status" => "UP"
            }
        ]
    }
}
참고

활성 상태, 준비 상태 및 시작 검사에 다음 명령을 사용할 수 있습니다.

  • /subsystem=microprofile-health-smallrye:check-live
  • /subsystem=microprofile-health-smallrye:check-ready
  • /subsystem=microprofile-health-smallrye:check-started

4.4.2. @Liveness 주석 예

다음 예제에서는 애플리케이션에서 @Liveness 주석을 사용하는 방법을 보여줍니다.

@Liveness
@ApplicationScoped
public class DataHealthCheck implements HealthCheck {

    @Override
    public HealthCheckResponse call() {
        return HealthCheckResponse.named("Health check with data")
            .up()
            .withData("foo", "fooValue")
            .withData("bar", "barValue")
            .build();
    }
}

4.4.3. @Readiness 주석 예

다음 예제에서는 데이터베이스에 대한 연결을 확인하는 방법을 보여줍니다. 데이터베이스가 다운되면 준비 상태 점검에서 오류를 보고합니다.

@Readiness
@ApplicationScoped
public class DatabaseConnectionHealthCheck implements HealthCheck {

    @Inject
    @ConfigProperty(name = "database.up", defaultValue = "false")
    private boolean databaseUp;

    @Override
    public HealthCheckResponse call() {

        HealthCheckResponseBuilder responseBuilder = HealthCheckResponse.named("Database connection health check");

        try {
            simulateDatabaseConnectionVerification();
            responseBuilder.up();
        } catch (IllegalStateException e) {
            // cannot access the database
            responseBuilder.down()
                .withData("error", e.getMessage()); // pass the exception message
        }

        return responseBuilder.build();
    }

    private void simulateDatabaseConnectionVerification() {
        if (!databaseUp) {
            throw new IllegalStateException("Cannot contact database");
        }
    }
}

4.4.4. @Startup 주석 예

다음은 애플리케이션에서 @Startup 주석을 사용하는 예입니다.

@Startup
@ApplicationScoped
public class StartupHealthCheck implements HealthCheck {

    @Override
    public HealthCheckResponse call() {
        return HealthCheckResponse.up("Application started");
    }
}

4.5. MicroProfile JWT 애플리케이션 개발

4.5.1. microprofile-jwt-Neutronrye 하위 시스템 활성화

MicroProfile JWT 통합은 microprofile-jwt-undercloudrye 하위 시스템에서 제공하며 기본 구성에 포함되어 있습니다. 기본 구성에 하위 시스템이 없으면 다음과 같이 추가할 수 있습니다.

사전 요구 사항

  • EAP XP가 설치되어 있어야 합니다.

프로세스

  1. JBoss EAP에서 MicroProfile JWT smallrye 확장을 활성화합니다.

    /extension=org.wildfly.extension.microprofile.jwt-smallrye:add
  2. microprofile-jwt-undercloudrye 하위 시스템을 활성화합니다.

    /subsystem=microprofile-jwt-smallrye:add
  3. 서버를 다시 로드합니다.

    reload

microprofile-jwt-Neutronrye 하위 시스템이 활성화됩니다.

4.5.2. JWT 애플리케이션 개발을 위한 Maven 프로젝트 구성

필요한 종속성과 JWT 애플리케이션을 개발하기 위한 디렉터리 구조를 사용하여 Maven 프로젝트를 생성합니다.

사전 요구 사항

  • Maven이 설치되어 있어야 합니다.
  • MicroProfile-jwt-Neutronrye 하위 시스템이 활성화됩니다.

프로세스

  1. maven 프로젝트를 설정합니다.

    $ mvn archetype:generate -DinteractiveMode=false \
        -DarchetypeGroupId=org.apache.maven.archetypes \
        -DarchetypeArtifactId=maven-archetype-webapp \
        -DgroupId=com.example -DartifactId=microprofile-jwt \
        -Dversion=1.0.0.Alpha1-SNAPSHOT
      cd microprofile-jwt

    명령은 프로젝트에 대한 디렉터리 구조와 pom.xml 구성 파일을 생성합니다.

  2. POM 파일이 jboss-eap-xp-microprofile BOM에서 MicroProfile JWT 아티팩트의 버전을 자동으로 관리하도록 하려면 POM 파일의 < dependencyManagement > 섹션으로 BOM을 가져옵니다.

    <dependencyManagement>
      <dependencies>
        <!-- importing the microprofile BOM adds MicroProfile specs -->
        <dependency>
            <groupId>org.jboss.bom</groupId>
            <artifactId>jboss-eap-xp-microprofile</artifactId>
            <version>${version.microprofile.bom}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
      </dependencies>
    </dependencyManagement>

    ${version.microprofile.bom}을 설치된 BOM 버전으로 교체합니다.

  3. BOM에서 관리하는 MicroProfile JWT 아티팩트를 POM 파일의 & lt;dependency > 섹션에 추가합니다. 다음 예제에서는 MicroProfile JWT 종속성을 파일에 추가하는 방법을 보여줍니다.

    <!-- Add the MicroProfile JWT API. Set provided for the <scope> tag, as the API is included in the server. -->
    <dependency>
      <groupId>org.eclipse.microprofile.jwt</groupId>
      <artifactId>microprofile-jwt-auth-api</artifactId>
      <scope>provided</scope>
    </dependency>

4.5.3. MicroProfile JWT로 애플리케이션 생성

JWT 토큰을 기반으로 요청을 인증하고 토큰 전달자의 ID를 기반으로 권한을 구현하는 애플리케이션을 생성합니다.

참고

다음 절차에서는 토큰을 생성하기 위한 예제 코드를 제공합니다. 프로덕션 환경의 경우 Red Hat Single Sign-On(SSO)과 같은 ID 공급자를 사용합니다.

사전 요구 사항

  • Maven 프로젝트는 올바른 종속 항목으로 구성됩니다.

프로세스

  1. 토큰 생성기를 생성합니다.

    이 단계는 참조 역할을 합니다. 프로덕션 환경의 경우 Red Hat SSO와 같은 ID 공급자를 사용합니다.

    1. 생성기 유틸리티에 대한 디렉터리 src/test/java 를 생성하고 해당 디렉터리로 이동합니다.

      $ mkdir -p src/test/java
      $ cd src/test/java
    2. 다음 콘텐츠를 사용하여 클래스 파일 TokenUtil.java 를 생성합니다.

      package  com.example.mpjwt;
      
      import java.io.FileInputStream;
      import java.io.InputStream;
      import java.nio.charset.StandardCharsets;
      import java.security.KeyFactory;
      import java.security.PrivateKey;
      import java.security.spec.PKCS8EncodedKeySpec;
      import java.util.Base64;
      import java.util.UUID;
      
      import javax.json.Json;
      import javax.json.JsonArrayBuilder;
      import javax.json.JsonObjectBuilder;
      
      import com.nimbusds.jose.JOSEObjectType;
      import com.nimbusds.jose.JWSAlgorithm;
      import com.nimbusds.jose.JWSHeader;
      import com.nimbusds.jose.JWSObject;
      import com.nimbusds.jose.JWSSigner;
      import com.nimbusds.jose.Payload;
      import com.nimbusds.jose.crypto.RSASSASigner;
      
      public class TokenUtil {
      
          private static PrivateKey loadPrivateKey(final String fileName) throws Exception {
              try (InputStream is = new FileInputStream(fileName)) {
                  byte[] contents = new byte[4096];
                  int length = is.read(contents);
                  String rawKey = new String(contents, 0, length, StandardCharsets.UTF_8)
                          .replaceAll("-----BEGIN (.*)-----", "")
                          .replaceAll("-----END (.*)----", "")
                          .replaceAll("\r\n", "").replaceAll("\n", "").trim();
      
                  PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(Base64.getDecoder().decode(rawKey));
                  KeyFactory keyFactory = KeyFactory.getInstance("RSA");
      
                  return keyFactory.generatePrivate(keySpec);
              }
          }
      
          public static String generateJWT(final String principal, final String birthdate, final String...groups) throws Exception {
          	PrivateKey privateKey = loadPrivateKey("private.pem");
      
              JWSSigner signer = new RSASSASigner(privateKey);
              JsonArrayBuilder groupsBuilder = Json.createArrayBuilder();
              for (String group : groups) { groupsBuilder.add(group); }
      
              long currentTime = System.currentTimeMillis() / 1000;
              JsonObjectBuilder claimsBuilder = Json.createObjectBuilder()
                      .add("sub", principal)
                      .add("upn", principal)
                      .add("iss", "quickstart-jwt-issuer")
                      .add("aud", "jwt-audience")
                      .add("groups", groupsBuilder.build())
                      .add("birthdate", birthdate)
                      .add("jti", UUID.randomUUID().toString())
                      .add("iat", currentTime)
                      .add("exp", currentTime + 14400);
      
              JWSObject jwsObject = new JWSObject(new JWSHeader.Builder(JWSAlgorithm.RS256)
                      .type(new JOSEObjectType("jwt"))
                      .keyID("Test Key").build(),
                      new Payload(claimsBuilder.build().toString()));
      
              jwsObject.sign(signer);
      
              return jwsObject.serialize();
          }
      
          public static void main(String[] args) throws Exception {
              if (args.length < 2) throw new IllegalArgumentException("Usage TokenUtil {principal} {birthdate} {groups}");
              String principal = args[0];
              String birthdate = args[1];
              String[] groups = new String[args.length - 2];
              System.arraycopy(args, 2, groups, 0, groups.length);
      
              String token = generateJWT(principal, birthdate, groups);
              String[] parts = token.split("\\.");
              System.out.println(String.format("\nJWT Header - %s", new String(Base64.getDecoder().decode(parts[0]), StandardCharsets.UTF_8)));
              System.out.println(String.format("\nJWT Claims - %s", new String(Base64.getDecoder().decode(parts[1]), StandardCharsets.UTF_8)));
              System.out.println(String.format("\nGenerated JWT Token \n%s\n", token));
          }
      }
  2. 다음 콘텐츠를 사용하여 src/main/webapp/WEB-INF 디렉터리에 web.xml 파일을 만듭니다.

    <context-param>
        <param-name>resteasy.role.based.security</param-name>
        <param-value>true</param-value>
    </context-param>
    
    <security-role>
        <role-name>Subscriber</role-name>
    </security-role>
  3. 다음 내용으로 클래스 파일 SampleEndPoint.java 를 생성합니다.

    package com.example.mpjwt;
    
    import javax.ws.rs.GET;
    import javax.ws.rs.Path;
    
    import java.security.Principal;
    import javax.ws.rs.core.Context;
    import javax.ws.rs.core.SecurityContext;
    
    import javax.annotation.security.RolesAllowed;
    import javax.inject.Inject;
    
    import java.time.LocalDate;
    import java.time.Period;
    import java.util.Optional;
    
    import org.eclipse.microprofile.jwt.Claims;
    import org.eclipse.microprofile.jwt.Claim;
    
    import org.eclipse.microprofile.jwt.JsonWebToken;
    
    @Path("/Sample")
    public class SampleEndPoint {
    
        @GET
        @Path("/helloworld")
        public String helloworld(@Context SecurityContext securityContext) {
            Principal principal = securityContext.getUserPrincipal();
            String caller = principal == null ? "anonymous" : principal.getName();
    
            return "Hello " + caller;
        }
    
        @Inject
    	JsonWebToken jwt;
    
    	@GET()
    	@Path("/subscription")
    	@RolesAllowed({"Subscriber"})
    	public String helloRolesAllowed(@Context SecurityContext ctx) {
        	Principal caller =  ctx.getUserPrincipal();
        	String name = caller == null ? "anonymous" : caller.getName();
        	boolean hasJWT = jwt.getClaimNames() != null;
        	String helloReply = String.format("hello + %s, hasJWT: %s", name, hasJWT);
    
        	return helloReply;
    	}
    
    	@Inject
    	@Claim(standard = Claims.birthdate)
    	Optional<String> birthdate;
    
    	@GET()
    	@Path("/birthday")
    	@RolesAllowed({ "Subscriber" })
    	public String birthday() {
        	if (birthdate.isPresent()) {
            	LocalDate birthdate = LocalDate.parse(this.birthdate.get().toString());
            	LocalDate today = LocalDate.now();
            	LocalDate next = birthdate.withYear(today.getYear());
            	if (today.equals(next)) {
                	return "Happy Birthday";
            }
            if (next.isBefore(today)) {
                next = next.withYear(next.getYear() + 1);
            }
    
            Period wait = today.until(next);
    
            return String.format("%d months and %d days until your next birthday.", wait.getMonths(), wait.getDays());
        }
    
        return "Sorry, we don't know your birthdate.";
    
    	}
    
    }

    @Path 로 주석이 달린 메서드는 Jakarta RESTful Web Services 엔드포인트입니다.

    @Claim 주석은 JWT 클레임을 정의합니다.

  4. Jakarta RESTful Web Services를 활성화하려면 클래스 파일 App.java 를 생성합니다.

    package com.example.mpjwt;
    
    import javax.ws.rs.ApplicationPath;
    import javax.ws.rs.core.Application;
    
    import org.eclipse.microprofile.auth.LoginConfig;
    
    @ApplicationPath("/rest")
    @LoginConfig(authMethod="MP-JWT", realmName="MP JWT Realm")
    public class App extends Application {}

    주석 @LoginConfig(authMethod="MP-JWT", realmName="MP JWT Cryostat") 는 배포 중에 JWT RBAC를 활성화합니다.

  5. 다음 Maven 명령을 사용하여 애플리케이션을 컴파일합니다.

    $ mvn package
  6. 토큰 생성기 유틸리티를 사용하여 JWT 토큰을 생성합니다.

    $ mvn exec:java -Dexec.mainClass=org.wildfly.quickstarts.mpjwt.TokenUtil -Dexec.classpathScope=test -Dexec.args="testUser 2017-09-15 Echoer Subscriber"
  7. 다음 Maven 명령을 사용하여 애플리케이션을 빌드하고 배포합니다.

    $ mvn package wildfly:deploy
  8. 애플리케이션을 테스트합니다.

    • 전달자 토큰을 사용하여 샘플/서브스크립션 끝점을 호출합니다.

      $ curl -H "Authorization: Bearer ey..rg" http://localhost:8080/microprofile-jwt/rest/Sample/subscription
    • Sample/birthday 엔드포인트를 호출합니다.

      $ curl -H "Authorization: Bearer ey..rg" http://localhost:8080/microprofile-jwt/rest/Sample/birthday

4.6. MicroProfile 지표 개발

4.6.1. MicroProfile Metrics 애플리케이션 생성

애플리케이션에 대한 요청 수를 반환하는 애플리케이션을 생성합니다.

프로세스

  1. 다음 내용으로 클래스 파일 HelloService.java 를 생성합니다.

    package com.example.microprofile.metrics;
    
    public class HelloService {
        String createHelloMessage(String name){
            return "Hello" + name;
        }
    }
  2. 다음 내용으로 클래스 파일 HelloWorld.java 를 생성합니다.

    package com.example.microprofile.metrics;
    
    import javax.inject.Inject;
    import javax.ws.rs.GET;
    import javax.ws.rs.Path;
    import javax.ws.rs.Produces;
    import org.eclipse.microprofile.metrics.annotation.Counted;
    
    @Path("/")
    public class HelloWorld {
    @Inject
        HelloService helloService;
    
    @GET
    @Path("/json")
        @Produces({ "application/json" })
        @Counted(name = "requestCount",
      		 absolute = true,
    description = "Number of times the getHelloWorldJSON was requested")
        public String getHelloWorldJSON() {
            return "{\"result\":\"" + helloService.createHelloMessage("World") + "\"}";
        }
    }
  3. pom.xml 파일을 업데이트하여 다음 종속성을 포함합니다.

    <dependency>
        <groupId>org.eclipse.microprofile.metrics</groupId>
        <artifactId>microprofile-metrics-api</artifactId>
        <scope>provided</scope>
    </dependency>
  4. 다음 Maven 명령을 사용하여 애플리케이션을 빌드합니다.

    $ mvn clean install wildfly:deploy
  5. 메트릭을 테스트합니다.

    1. CLI에서 다음 명령을 실행합니다.

      $ curl -v http://localhost:9990/metrics |  grep request_count | grep helloworld-rs-metrics

      예상 출력:

      jboss_undertow_request_count_total{deployment="helloworld-rs-metrics.war",servlet="org.jboss.as.quickstarts.rshelloworld.JAXActivator",subdeployment="helloworld-rs-metrics.war",microprofile_scope="vendor"} 0.0
    2. 브라우저에서 URL http://localhost:8080/helloworld-rs/rest/json으로 이동합니다.
    3. CLI에서 다음 명령을 다시 실행합니다.

      $ curl -v http://localhost:9990/metrics |  grep request_count | grep helloworld-rs-metrics

      예상 출력:

      jboss_undertow_request_count_total{deployment="helloworld-rs-metrics.war",servlet="org.jboss.as.quickstarts.rshelloworld.JAXActivator",subdeployment="helloworld-rs-metrics.war",microprofile_scope="vendor"} 1.0

4.7. MicroProfile OpenAPI 애플리케이션 개발

4.7.1. MicroProfile OpenAPI 활성화

microprofile-openapi-undercloudrye 하위 시스템은 standalone-microprofile.xml 구성에 제공됩니다. 그러나 JBoss EAP XP는 기본적으로 standalone.xml 을 사용합니다. 이를 사용하려면 standalone.xml 에 하위 시스템을 포함해야 합니다.

또는 MicroProfile 하위 시스템 및 확장 기능을 사용하여 독립 실행형 구성 업데이트 절차에 따라 standalone.xml 구성 파일을 업데이트할 수 있습니다.

프로세스

  1. JBoss EAP에서 MicroProfile OpenAPI smallrye 확장을 활성화합니다.

    /extension=org.wildfly.extension.microprofile.openapi-smallrye:add()
  2. 다음 관리 명령을 사용하여 microprofile-openapi-undercloudrye 하위 시스템을 활성화합니다.

    /subsystem=microprofile-openapi-smallrye:add()
  3. 서버를 다시 로드합니다.

    reload

microprofile-openapi-Neutronrye 하위 시스템이 활성화됩니다.

4.7.2. MicroProfile OpenAPI에 대한 Maven 프로젝트 구성

Maven 프로젝트를 생성하여 MicroProfile OpenAPI 애플리케이션을 생성하기 위한 종속 항목을 설정합니다.

사전 요구 사항

  • Maven이 설치되어 있어야 합니다.
  • JBoss EAP Maven 리포지토리가 구성되어 있습니다.

프로세스

  1. 프로젝트를 초기화합니다.

    mvn archetype:generate \
         -DgroupId=com.example.microprofile.openapi \
         -DartifactId=microprofile-openapi\
         -DarchetypeGroupId=org.apache.maven.archetypes \
         -DarchetypeArtifactId=maven-archetype-webapp \
         -DinteractiveMode=false
    cd microprofile-openapi

    명령은 프로젝트에 대한 디렉터리 구조와 pom.xml 구성 파일을 생성합니다.

  2. 다음을 포함할 pom.xml 구성 파일을 편집합니다.

    <?xml version="1.0" encoding="UTF-8"?>
    
    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
    
        <groupId>com.example.microprofile.openapi</groupId>
        <artifactId>microprofile-openapi</artifactId>
        <version>1.0-SNAPSHOT</version>
        <packaging>war</packaging>
    
        <name>microprofile-openapi Maven Webapp</name>
        <!-- Update the value with the URL of the project -->
        <url>http://www.example.com</url>
    
        <properties>
            <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
            <maven.compiler.source>1.8</maven.compiler.source>
            <maven.compiler.target>1.8</maven.compiler.target>
            <version.server.bom>4.0.0.GA</version.server.bom>
        </properties>
    
        <dependencyManagement>
            <dependencies>
                <dependency>
                    <groupId>org.jboss.bom</groupId>
                    <artifactId>jboss-eap-xp-microprofile</artifactId>
                    <version>${version.server.bom}</version>
                    <type>pom</type>
                    <scope>import</scope>
                </dependency>
            </dependencies>
        </dependencyManagement>
    
        <dependencies>
            <dependency>
                <groupId>org.jboss.spec.javax.ws.rs</groupId>
                <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
                <scope>provided</scope>
            </dependency>
        </dependencies>
    
        <build>
            <!-- Set the name of the archive -->
            <finalName>${project.artifactId}</finalName>
            <plugins>
                <plugin>
                    <artifactId>maven-clean-plugin</artifactId>
                    <version>3.1.0</version>
                </plugin>
                <!-- see http://maven.apache.org/ref/current/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging -->
                <plugin>
                    <artifactId>maven-resources-plugin</artifactId>
                    <version>3.0.2</version>
                </plugin>
                <plugin>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>3.8.0</version>
                </plugin>
                <plugin>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <version>2.22.1</version>
                </plugin>
                <plugin>
                    <artifactId>maven-war-plugin</artifactId>
                    <version>3.2.2</version>
                </plugin>
                <plugin>
                    <artifactId>maven-install-plugin</artifactId>
                    <version>2.5.2</version>
                </plugin>
                <plugin>
                    <artifactId>maven-deploy-plugin</artifactId>
                    <version>2.8.2</version>
                </plugin>
                <!-- Allows to use mvn wildfly:deploy -->
                <plugin>
                    <groupId>org.wildfly.plugins</groupId>
                    <artifactId>wildfly-maven-plugin</artifactId>
                </plugin>
            </plugins>
        </build>
    </project>

    pom.xml 구성 파일과 디렉터리 구조를 사용하여 애플리케이션을 생성합니다.

추가 리소스

4.7.3. MicroProfile OpenAPI 애플리케이션 생성

OpenAPI v3 문서를 반환하는 애플리케이션을 생성합니다.

사전 요구 사항

  • Maven 프로젝트는 MicroProfile OpenAPI 애플리케이션을 생성하기 위해 구성됩니다.

프로세스

  1. 클래스 파일을 저장할 디렉터리를 생성합니다.

    $ mkdir -p APPLICATION_ROOT/src/main/java/com/example/microprofile/openapi/

    APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일을 포함하는 디렉터리입니다.

  2. 새 디렉터리로 이동합니다.

    $ cd APPLICATION_ROOT/src/main/java/com/example/microprofile/openapi/

    다음 단계의 모든 클래스 파일은 이 디렉터리에 생성해야 합니다.

  3. 다음 내용으로 클래스 파일 InventoryApplication.java 를 생성합니다.

    package com.example.microprofile.openapi;
    
    import javax.ws.rs.ApplicationPath;
    import javax.ws.rs.core.Application;
    
    @ApplicationPath("/inventory")
    public class InventoryApplication extends Application {
    }

    이 클래스는 애플리케이션의 REST 엔드포인트 역할을 합니다.

  4. 다음 내용으로 클래스 파일 Fruit.java 를 생성합니다.

    package com.example.microprofile.openapi;
    
    public class Fruit {
    
        private final String name;
        private final String description;
    
        public Fruit(String name, String description) {
            this.name = name;
            this.description = description;
        }
    
        public String getName() {
            return this.name;
        }
    
        public String getDescription() {
            return this.description;
        }
    }
  5. 다음 내용으로 클래스 파일 FruitResource.java 를 생성합니다.

    package com.example.microprofile.openapi;
    
    import java.util.Collections;
    import java.util.LinkedHashMap;
    import java.util.Set;
    
    import javax.ws.rs.Consumes;
    import javax.ws.rs.DELETE;
    import javax.ws.rs.GET;
    import javax.ws.rs.POST;
    import javax.ws.rs.Path;
    import javax.ws.rs.Produces;
    import javax.ws.rs.core.MediaType;
    
    @Path("/fruit")
    @Produces(MediaType.APPLICATION_JSON)
    @Consumes(MediaType.APPLICATION_JSON)
    public class FruitResource {
    
        private final Set<Fruit> fruits = Collections.newSetFromMap(Collections.synchronizedMap(new LinkedHashMap<>()));
    
        public FruitResource() {
            this.fruits.add(new Fruit("Apple", "Winter fruit"));
            this.fruits.add(new Fruit("Pineapple", "Tropical fruit"));
        }
    
        @GET
        public Set<Fruit> all() {
            return this.fruits;
        }
    
        @POST
        public Set<Fruit> add(Fruit fruit) {
            this.fruits.add(fruit);
            return this.fruits;
        }
    
        @DELETE
        public Set<Fruit> remove(Fruit fruit) {
            this.fruits.removeIf(existingFruit -> existingFruit.getName().contentEquals(fruit.getName()));
            return this.fruits;
        }
    }
  6. 애플리케이션의 루트 디렉터리로 이동합니다.

    $ cd APPLICATION_ROOT
  7. 다음 Maven 명령을 사용하여 애플리케이션을 빌드하고 배포합니다.

    $ mvn wildfly:deploy
  8. 애플리케이션을 테스트합니다.

    • curl 을 사용하여 샘플 애플리케이션의 OpenAPI 문서에 액세스 :

      $ curl http://localhost:8080/openapi
    • 다음 출력이 반환됩니다.

      openapi: 3.0.1
      info:
        title: Archetype Created Web Application
        version: "1.0"
      servers:
      - url: /microprofile-openapi
      paths:
        /inventory/fruit:
          get:
            responses:
              "200":
                description: OK
                content:
                  application/json:
                    schema:
                      type: array
                      items:
                        $ref: '#/components/schemas/Fruit'
          post:
            requestBody:
              content:
                application/json:
                  schema:
                    $ref: '#/components/schemas/Fruit'
            responses:
              "200":
                description: OK
                content:
                  application/json:
                    schema:
                      type: array
                      items:
                        $ref: '#/components/schemas/Fruit'
          delete:
            requestBody:
              content:
                application/json:
                  schema:
                    $ref: '#/components/schemas/Fruit'
            responses:
              "200":
                description: OK
                content:
                  application/json:
                    schema:
                      type: array
                      items:
                        $ref: '#/components/schemas/Fruit'
      components:
        schemas:
          Fruit:
            type: object
            properties:
              description:
                type: string
              name:
                type: string

추가 리소스

4.7.4. 정적 OpenAPI 문서를 제공하도록 JBoss EAP 구성

호스트의 REST 서비스를 설명하는 정적 OpenAPI 문서를 제공하도록 JBoss EAP를 구성합니다.

JBoss EAP가 정적 OpenAPI 문서를 제공하도록 구성된 경우 정적 OpenAPI 문서는 Jakarta RESTful Web Services 및 MicroProfile OpenAPI 주석보다 먼저 처리됩니다.

프로덕션 환경에서 정적 문서를 제공할 때 주석 처리를 비활성화합니다. 주석 처리를 비활성화하면 클라이언트에 변경 불가능한 버전이 지정된 API 계약을 사용할 수 있습니다.

프로세스

  1. 애플리케이션 소스 트리에 디렉터리를 생성합니다.

    $ mkdir APPLICATION_ROOT/src/main/webapp/META-INF

    APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일을 포함하는 디렉터리입니다.

  2. OpenAPI 엔드포인트를 쿼리하여 출력을 파일로 리디렉션합니다.

    $ curl http://localhost:8080/openapi?format=JSON > src/main/webapp/META-INF/openapi.json

    기본적으로 끝점은 YAML 문서를 제공하며 format=JSON 은 JSON 문서가 반환되도록 지정합니다.

  3. OpenAPI 문서 모델을 처리할 때 주석 스캔을 건너뛰도록 애플리케이션을 구성합니다.

    $ echo "mp.openapi.scan.disable=true" > APPLICATION_ROOT/src/main/webapp/META-INF/microprofile-config.properties
  4. 애플리케이션을 다시 빌드합니다.

    $ mvn clean install
  5. 다음 관리 CLI 명령을 사용하여 애플리케이션을 다시 배포합니다.

    1. 애플리케이션 배포를 취소합니다.

      undeploy microprofile-openapi.war
    2. 애플리케이션을 배포합니다.

      deploy APPLICATION_ROOT/target/microprofile-openapi.war

JBoss EAP는 이제 OpenAPI 엔드포인트에서 정적 OpenAPI 문서를 제공합니다.

4.8. MicroProfile REST 클라이언트 개발

4.8.1. MicroProfile REST 클라이언트와 자카르타 RESTful 웹 서비스 구문 비교

MicroProfile REST 클라이언트는 CORBA, RMI(Java Remote Method Invocation), JBoss Remoting Project 및 REST Cryostat에서도 구현된 분산 오브젝트 통신 버전을 활성화합니다. 예를 들어 리소스를 고려하십시오.

@Path("resource")
public class TestResource {
   @Path("test")
   @GET
   String test() {
      return "test";
   }
 }

다음 예제에서는 Jakarta RESTful Web Services-native 방법을 사용하여 TestResource 클래스에 액세스하는 방법을 보여줍니다.

Client client = ClientBuilder.newClient();
String response = client.target("http://localhost:8081/test").request().get(String.class);

그러나 Microprofile REST 클라이언트는 다음 예제와 같이 test() 메서드를 직접 호출하여 보다 직관적인 구문을 지원합니다.

@Path("resource")
public interface TestResourceIntf {
    @Path("test")
    @GET
    public String test();
}

TestResourceIntf service = RestClientBuilder.newBuilder()
                              .baseUrl(http://localhost:8081/))
                              .build(TestResourceIntf.class);
String s = service.test();

이전 예에서 TestResource 클래스를 호출하는 것은 service.test() 호출에 설명된 대로 TestResourceIntf 클래스를 사용하면 훨씬 쉬워집니다.

다음 예제는 TestResourceIntf 클래스의 보다 정교한 버전입니다.

@Path("resource")
public interface TestResourceIntf2 {
   @Path("test/{path}")
   @Consumes("text/plain")
   @Produces("text/html")
   @POST
   public String test(@PathParam("path") String path, @QueryParam("query") String query, String entity);
}

service.test("p", "q", "e") 메서드를 호출하면 다음 예와 같이 HTTP 메시지가 생성됩니다.

POST /resource/test/p/?query=q HTTP/1.1
Accept: text/html
Content-Type: text/plain
Content-Length: 1

e

4.8.2. MicroProfile REST 클라이언트에서 공급자의 프로그래밍 방식의 등록

MicroProfile REST 클라이언트를 사용하면 공급자를 등록하여 클라이언트 환경을 구성할 수 있습니다. 예를 들면 다음과 같습니다.

TestResourceIntf service = RestClientBuilder.newBuilder()
                              .baseUrl(http://localhost:8081/))
                              .register(MyClientResponseFilter.class)
                              .register(MyMessageBodyReader.class)
                              .build(TestResourceIntf.class);

4.8.3. MicroProfile REST 클라이언트의 공급자 선언적 등록

다음 예와 같이 org.eclipse.microprofile.client.annotation.RegisterProvider 주석을 대상 인터페이스에 추가하여 MicroProfile REST 클라이언트를 사용하여 공급자를 선언적으로 등록합니다.

@Path("resource")
@RegisterProvider(MyClientResponseFilter.class)
@RegisterProvider(MyMessageBodyReader.class)
public interface TestResourceIntf2 {
   @Path("test/{path}")
   @Consumes("text/plain")
   @Produces("text/html")
   @POST
   public String test(@PathParam("path") String path, @QueryParam("query") String query, String entity);
}

주석을 사용하여 MyClientResponseFilter 클래스 및 MyMessageBody Cryostat 클래스를 선언하면 RestClientBuilder.register() 메서드를 호출할 필요가 없습니다.

4.8.4. MicroProfile REST 클라이언트의 헤더 선언 사양

다음과 같은 방법으로 HTTP 요청에 대한 헤더를 지정할 수 있습니다.

  • 리소스 메서드 매개 변수 중 하나에 주석을 달 수 있습니다.
  • 선언적으로 org.eclipse.microprofile.rest.client.annotation.ClientHeaderParam 주석을 사용합니다.

다음 예제에서는 @HeaderParam 주석을 사용하여 리소스 메서드 매개변수 중 하나에 주석을 달아 헤더를 설정하는 방법을 보여줍니다.

@POST
@Produces(MediaType.TEXT_PLAIN)
@Consumes(MediaType.TEXT_PLAIN)
String contentLang(@HeaderParam(HttpHeaders.CONTENT_LANGUAGE) String contentLanguage, String subject);

다음 예제에서는 org.eclipse.microprofile.rest.client.annotation.ClientHeaderParam 주석을 사용하여 헤더를 설정하는 방법을 보여줍니다.

@POST
@Produces(MediaType.TEXT_PLAIN)
@Consumes(MediaType.TEXT_PLAIN)
@ClientHeaderParam(name=HttpHeaders.CONTENT_LANGUAGE, value="{getLanguage}")
String contentLang(String subject);

default String getLanguage() {
   return ...;
}

4.8.5. MicroProfile REST 클라이언트의 ResponseExceptionMapper

org.eclipse.microprofile.rest.ext.ResponseExceptionMapper 클래스는 Jakarta RESTful Web Services에 정의된 javax.ws.rs.ext.ExceptionMapper 클래스의 클라이언트 측의 클라이언트 측입니다. ExceptionMapper.toResponse() 메서드는 서버 측 처리 중에 발생한 Exception 클래스를 Response 클래스로 전환합니다. ResponseExceptionMapper.toThrowable() 메서드는 HTTP 오류 상태를 사용하여 클라이언트 측에서 수신된 Response 클래스를 Exception 클래스로 전환합니다.

ResponseExceptionMapper 클래스를 프로그래밍 방식으로 등록하거나 선언적으로 등록할 수 있습니다. 등록된 ResponseExceptionMapper 클래스가 없으면 기본 ResponseExceptionMapper 클래스는 상태 >= 400 인 모든 응답을 WebApplicationException 클래스에 매핑합니다.

4.8.6. MicroProfile REST 클라이언트를 사용한 컨텍스트 종속성 주입

MicroProfile REST 클라이언트를 사용하면 Jakarta 컨텍스트 및 종속성 주입(Jakarta Contexts 및 dependency Cryostat)으로 관리되는 모든 인터페이스에 @RegisterRestClient 클래스를 사용해야 합니다. 예를 들면 다음과 같습니다.

@Path("resource")
@RegisterProvider(MyClientResponseFilter.class)
public static class TestResourceImpl {
      @Inject TestDataBase db;

      @Path("test/{path}")
      @Consumes("text/plain")
      @Produces("text/html")
      @POST
      public String test(@PathParam("path") String path, @QueryParam("query")
      String query, String entity) {
         return db.getByName(query);
      }
   }
   @Path("database")
   @RegisterRestClient
   public interface TestDataBase {

      @Path("")
      @POST
      public String getByName(String name);
   }

여기서는 MicroProfile REST 클라이언트 구현에서 TestDataBase 클래스 서비스에 대한 클라이언트를 생성하여 TestResourceImpl 클래스에서 쉽게 액세스할 수 있습니다. 그러나 TestDataBase 클래스 구현의 경로에 대한 정보는 포함되지 않습니다. 이 정보는 선택적 @RegisterProvider 매개변수 baseUri 에서 제공할 수 있습니다.

@Path("database")
@RegisterRestClient(baseUri="https://localhost:8080/webapp")
public interface TestDataBase {
   @Path("")
   @POST
   public String getByName(String name);
}

이는 https://localhost:8080/webapp에서 TestDataBase 구현에 액세스할 수 있음을 나타냅니다. MicroProfile 구성을 사용하여 외부에서 정보를 제공할 수도 있습니다.

<fully qualified name of TestDataBase>/mp-rest/url=<URL>

예를 들어 다음 속성은 https://localhost:8080/webapp에서 com.bluemonkeydiamond.TestDatabase 클래스의 구현에 액세스할 수 있음을 나타냅니다.

com.bluemonkeydiamond.TestDatabase/mp-rest/url=https://localhost:8080/webapp

자카르타 컨텍스트 및 종속성 클라이언트에 여러 다른 속성을 제공할 수 있습니다. 예를 들어 com.mycompany.remoteServices.MyServiceClient/mp-rest/providers, 쉼표로 구분된 정규화된 공급자 클래스 이름 목록을 클라이언트에 포함할 수 있습니다.

추가 리소스

5장. JBoss EAP XP의 OpenShift 이미지에서 마이크로서비스 애플리케이션을 빌드하고 실행합니다.

JBoss EAP XP의 OpenShift 이미지에서 마이크로 서비스 애플리케이션을 빌드하고 실행할 수 있습니다.

참고

JBoss EAP XP는 OpenShift 4 이상 버전에서만 지원됩니다.

다음 워크플로를 사용하여 S2I(Source-to-Image) 프로세스를 사용하여 JBoss EAP XP의 OpenShift 이미지에서 마이크로서비스 애플리케이션을 빌드하고 실행합니다.

참고

JBoss EAP XP 4.0.0의 OpenShift 이미지는 standalone-microprofile-ha.xml 파일을 기반으로 하는 기본 독립 실행형 구성 파일을 제공합니다. JBoss EAP XP에 포함된 서버 구성 파일에 대한 자세한 내용은 독립 실행형 서버 구성 파일 섹션을 참조하십시오.

이 워크플로는 마이크로profile-config 빠른 시작 예제를 사용합니다. 빠른 시작은 자체 프로젝트에 대한 참조로 사용할 수 있는 작고 구체적인 작업 예제를 제공합니다. 자세한 내용은 JBoss EAP XP 4.0.0과 함께 제공되는 microprofile-config 빠른 시작을 참조하십시오.

추가 리소스

5.1. 애플리케이션 배포를 위한 OpenShift 준비

애플리케이션 배포를 위해 OpenShift를 준비합니다.

사전 요구 사항

운영 중인 OpenShift 인스턴스가 설치되어 있어야 합니다. 자세한 내용은 Red Hat Customer Portal 에서 OpenShift Container Platform 클러스터 설치 및 구성 을 참조하십시오.

프로세스

  1. oc login 명령을 사용하여 OpenShift 인스턴스에 로그인합니다.
  2. OpenShift에서 새 프로젝트를 생성합니다.

    프로젝트를 사용하면 사용자 그룹이 다른 그룹과 별도로 콘텐츠를 구성하고 관리할 수 있습니다. 다음 명령을 사용하여 OpenShift에서 프로젝트를 생성할 수 있습니다.

    $ oc new-project PROJECT_NAME

    예를 들어 microprofile-config 빠른 시작의 경우 다음 명령을 사용하여 Cryostat -demo 라는 새 프로젝트를 생성합니다.

    $ oc new-project eap-demo

5.2. Red Hat Container Registry에 대한 인증 구성

JBoss EAP XP용 OpenShift 이미지를 가져오고 사용하려면 Red Hat Container Registry에 대한 인증을 구성해야 합니다.

레지스트리 서비스 계정을 사용하여 인증 토큰을 생성하여 Red Hat Container Registry에 대한 액세스를 구성합니다. 인증 토큰을 사용할 때 OpenShift 구성에 Red Hat 계정의 사용자 이름과 암호를 사용하거나 저장할 필요가 없습니다.

프로세스

  1. Red Hat 고객 포털의 지침에 따라 레지스트리 서비스 계정 관리 애플리케이션을 사용하여 인증 토큰을 생성합니다.
  2. 토큰의 OpenShift 시크릿이 포함된 YAML 파일을 다운로드합니다.

    토큰의 토큰 정보 페이지의 OpenShift 시크릿 탭에서 YAML 파일을 다운로드할 수 있습니다.

  3. 다운로드한 YAML 파일을 사용하여 OpenShift 프로젝트에 대한 인증 토큰 시크릿을 생성합니다.

    oc create -f 1234567_myserviceaccount-secret.yaml
  4. 다음 명령을 사용하여 OpenShift 프로젝트의 시크릿을 구성하고 아래 시크릿 이름을 이전 단계에서 생성한 시크릿 이름으로 교체합니다.

    oc secrets link default 1234567-myserviceaccount-pull-secret --for=pull
    oc secrets link builder 1234567-myserviceaccount-pull-secret --for=pull

5.3. JBoss EAP XP에 대한 최신 OpenShift 이미지 스트림 및 템플릿 가져오기

JBoss EAP XP에 대한 최신 OpenShift 이미지 스트림 및 템플릿을 가져옵니다.

중요

OpenShift의 OpenJDK 8 이미지 및 이미지 스트림은 더 이상 사용되지 않습니다.

OpenShift에서 이미지 및 이미지 스트림은 계속 지원됩니다. 그러나 이러한 이미지 및 이미지 스트림에 대한 개선 사항은 제공되지 않으며 향후 제거될 수 있습니다. Red Hat은 표준 지원 약관에 따라 OpenJDK 8 이미지 및 이미지 스트림의 전체 지원 및 버그 수정을 계속 제공합니다.

프로세스

  1. JBoss EAP XP용 OpenShift 이미지의 최신 이미지 스트림 및 템플릿을 OpenShift 프로젝트의 네임스페이스로 가져오려면 다음 명령을 사용합니다.

    1. JDK 11 이미지 스트림을 가져옵니다.

      oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap-xp4/eap-xp4-openjdk11-image-stream.json

      이 명령은 다음 이미지 스트림 및 템플릿을 가져옵니다.

      • JDK 11 빌더 이미지 스트림: jboss-eap-xp4-openjdk11-openshift
      • JDK 11 런타임 이미지 스트림: jboss-eap-xp4-openjdk11-runtime-openshift
    2. OpenShift 템플릿을 가져옵니다.

      oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap-xp4/templates/eap-xp4-basic-s2i.json
    참고

    위의 명령을 사용하여 가져온 JBoss EAP XP 이미지 스트림 및 템플릿은 해당 OpenShift 프로젝트 내에서만 사용할 수 있습니다.

  2. 일반 openshift 네임스페이스에 대한 관리자 액세스 권한이 있고 모든 프로젝트에서 이미지 스트림 및 템플릿에 액세스할 수 있도록 하려면 명령의 oc replace 줄에 -n openshift 를 추가합니다. 예를 들면 다음과 같습니다.

    ...
    oc replace -n openshift --force -f \
    ...
  3. 이미지 스트림과 템플릿을 다른 프로젝트로 가져오려면 -n PROJECT_NAME 을 명령의 oc replace 행에 추가합니다. 예를 들면 다음과 같습니다.

    ...
    oc replace -n PROJECT_NAME --force -f
    ...

    cluster-samples-operator를 사용하는 경우 클러스터 샘플 Operator 구성에 대한 OpenShift 설명서를 참조하십시오. 클러스터 샘플 Operator 구성에 대한 자세한 내용은 Cluster Samples Operator 구성을 참조하십시오.

5.4. OpenShift에 JBoss EAP XP S2I(Source-to-Image) 애플리케이션 배포

OpenShift에 JBoss EAP XP S2I(Source-to-Image) 애플리케이션을 배포합니다.

사전 요구 사항

  • 선택 사항: 템플릿은 많은 템플릿 매개변수에 대한 기본값을 지정할 수 있으며 기본값의 일부 또는 모두를 재정의해야 할 수 있습니다. 매개변수 목록 및 기본값을 포함한 템플릿 정보를 보려면 oc describe 템플릿 TEMPLATE_NAME 명령을 사용합니다.

프로세스

  1. JBoss EAP XP 이미지와 Java 애플리케이션의 소스 코드를 사용하여 새 OpenShift 애플리케이션을 생성합니다. S2I 빌드에 제공된 JBoss EAP XP 템플릿 중 하나를 사용합니다.

    $ oc new-app --template=eap-xp4-basic-s2i \ 1
     -p EAP_IMAGE_NAME=jboss-eap-xp4-openjdk11-openshift:latest \
     -p EAP_RUNTIME_IMAGE_NAME=jboss-eap-xp4-openjdk11-runtime-openshift:latest \
     -p IMAGE_STREAM_NAMESPACE=eap-demo \ 2
     -p SOURCE_REPOSITORY_URL=https://github.com/jboss-developer/jboss-eap-quickstarts \ 3
     -p SOURCE_REPOSITORY_REF=xp-4.0.x \ 4
     -p CONTEXT_DIR=microprofile-config 5
    1
    사용할 템플릿입니다. 애플리케이션 이미지에 latest 태그가 지정됩니다.
    2
    최신 이미지 스트림과 템플릿을 프로젝트의 네임스페이스로 가져왔으므로 이미지 스트림을 찾을 위치의 네임스페이스를 지정해야 합니다. 일반적으로 프로젝트의 이름입니다.
    3
    애플리케이션 소스 코드가 포함된 리포지토리의 URL입니다.
    4
    소스 코드에 사용할 Git 리포지토리 참조입니다. Git 분기 또는 태그 참조일 수 있습니다.
    5
    빌드할 소스 리포지토리 내의 디렉터리입니다.
    참고

    템플릿은 많은 템플릿 매개변수의 기본값을 지정할 수 있으며 기본값의 일부 또는 모두를 재정의해야 할 수 있습니다. 매개변수 목록 및 기본값을 포함한 템플릿 정보를 보려면 oc describe 템플릿 TEMPLATE_NAME 명령을 사용합니다.

    새 OpenShift 애플리케이션을 생성할 때 환경 변수를 구성 하려고 할 수도 있습니다.

  2. 빌드 구성의 이름을 검색합니다.

    $ oc get bc -o name
  3. 이전 단계의 빌드 구성 이름을 사용하여 빌드의 Maven 진행 상황을 확인합니다.

    $ oc logs -f buildconfig/${APPLICATION_NAME}-build-artifacts
    
    …
    Push successful
    $ oc logs -f buildconfig/${APPLICATION_NAME}
    …
    Push successful

    예를 들어, microprofile-config 의 경우 다음 명령은 Maven 빌드의 진행 상황을 보여줍니다.

    $ oc logs -f buildconfig/eap-xp4-basic-app-build-artifacts
    
    …
    Push successful
    $ oc logs -f buildconfig/eap-xp4-basic-app
    …
    Push successful

5.5. JBoss EAP XP S2I(Source-to-Image) 애플리케이션에 대한 배포 후 작업 완료

애플리케이션에 따라 OpenShift 애플리케이션을 빌드하고 배포한 후 일부 작업을 완료해야 할 수 있습니다.

배포 후 작업의 예는 다음과 같습니다.

  • OpenShift 외부에서 애플리케이션을 볼 수 있도록 서비스를 노출합니다.
  • 애플리케이션을 특정 개수의 복제본으로 스케일링합니다.

프로세스

  1. 다음 명령을 사용하여 애플리케이션의 서비스 이름을 가져옵니다.

    $ oc get service
  2. 선택 사항: 기본 서비스를 경로로 노출하여 OpenShift 외부에서 애플리케이션에 액세스할 수 있습니다. 예를 들어 microprofile-config 빠른 시작의 경우 다음 명령을 사용하여 필요한 서비스와 포트를 노출합니다.

    참고

    템플릿을 사용하여 애플리케이션을 생성한 경우 경로가 이미 존재할 수 있습니다. 이 경우 다음 단계로 이동합니다.

    $ oc expose service/eap-xp4-basic-app --port=8080
  3. 경로의 URL을 가져옵니다.

    $ oc get route
  4. URL을 사용하여 웹 브라우저에서 애플리케이션에 액세스합니다. URL은 이전 명령의 출력의 HOST/PORT 필드 값입니다.

    참고

    JBoss EAP XP 4.0.0 GA 배포의 경우 Microprofile Config 빠른 시작은 애플리케이션의 루트 컨텍스트에 대한 HTTPS GET 요청에 응답하지 않습니다. 이 향상된 기능은 {JBossXPShortName101} GA 배포에서만 사용할 수 있습니다.

    예를 들어 Microprofile Config 애플리케이션과 상호 작용하기 위해 URL은 브라우저에서 http://HOST_PORT_Value/config/value 일 수 있습니다.

    애플리케이션에서 JBoss EAP 루트 컨텍스트를 사용하지 않는 경우 애플리케이션 컨텍스트를 URL에 추가합니다. 예를 들어 microprofile-config 빠른 시작의 경우 URL은 http://HOST_PORT_VALUE/microprofile-config/ 일 수 있습니다.

  5. 선택적으로 다음 명령을 실행하여 애플리케이션 인스턴스를 확장할 수 있습니다. 이 명령은 복제본 수를 3으로 늘립니다.

    $ oc scale deploymentconfig DEPLOYMENTCONFIG_NAME --replicas=3

    예를 들어 microprofile-config 빠른 시작의 경우 다음 명령을 사용하여 애플리케이션을 확장합니다.

    $ oc scale deploymentconfig/eap-xp4-basic-app --replicas=3

추가 리소스

JBoss EAP XP 빠른 시작에 대한 자세한 내용은 JBoss EAP XP 빠른 시작을 참조하십시오.

6장. 기능 트리밍

부팅 가능한 JAR을 빌드할 때 포함할 JBoss EAP 기능 및 하위 시스템을 결정할 수 있습니다.

참고

기능 트리밍은 OpenShift에서만 지원되거나 부팅 가능한 JAR을 빌드할 때 지원됩니다.

추가 리소스

6.1. 사용 가능한 JBoss EAP 계층

Red Hat은 OpenShift에서 JBoss EAP 서버의 프로비저닝 또는 부팅 가능한 JAR을 사용자 정의하는 여러 계층을 제공합니다.

3개의 계층은 핵심 기능을 제공하는 기본 계층입니다. 다른 계층은 추가 기능으로 기본 계층을 개선하는 데코레이터 계층입니다.

대부분의 데코레이터 계층은 JBoss EAP에서 OpenShift용 S2I 이미지를 빌드하거나 부팅 가능한 JAR을 빌드하는 데 사용할 수 있습니다. 일부 계층은 S2I 이미지를 지원하지 않습니다. 계층에 대한 설명은 이러한 제한 사항을 설명합니다.

참고

나열된 계층만 지원됩니다. 여기에 나열되지 않은 계층은 지원되지 않습니다.

6.1.1. 기본 계층

각 기본 계층에는 일반적인 서버 사용자 사례에 대한 핵심 기능이 포함되어 있습니다.

datasources-web-server

이 계층에는 서블릿 컨테이너와 데이터 소스를 구성하는 기능이 포함됩니다.

이 레이어에는 MicroProfile 기능이 포함되어 있지 않습니다.

다음 Jakarta EE 사양이 이 계층에서 지원됩니다.

  • Jakarta JSON Processing 1.1
  • Jakarta JSON Binding 1.0
  • Jakarta Servlet 4.0
  • Jakarta Expression Language 3.0
  • Jakarta Server Pages 2.3
  • Jakarta 표준 태그 라이브러리 1.2
  • Jakarta Concurrency 1.1
  • Jakarta Annotations 1.3
  • Jakarta XML Binding 2.3
  • 기타 언어 1.0에 대한 Jakarta 디버깅 지원
  • Jakarta Transaction 1.3
  • Jakarta Connector API 1.7
jaxrs-server

이 계층은 다음 JBoss EAP 하위 시스템을 사용하여 datasources-web-server 계층을 향상시킵니다.

  • jaxrs
  • weld
  • jpa

이 계층은 컨테이너에 로컬로 Infinispan 기반 두 번째 수준 엔터티 캐싱을 추가합니다.

다음 MicroProfile 기능이 이 계층에 포함되어 있습니다.

  • MicroProfile REST Client

다음 Jakarta EE 사양은 데이터 소스-web-server 계층에서 지원되는 것 외에도 이 계층에서 지원됩니다.

  • 자카르타 컨텍스트 및 종속성 2.0
  • Jakarta Bean Validation 2.0
  • Jakarta Interceptors 1.2
  • Jakarta RESTful Web Services 2.1
  • Jakarta Persistence 2.2
cloud-server

이 계층은 다음 JBoss EAP 하위 시스템을 사용하여 jaxrs-server 계층을 향상시킵니다.

  • resource-adapters
  • messaging-activemq (원격 브로커 메시징, 임베디드 메시징이 아님)

이 계층은 또한 jaxrs-server 계층에 다음과 같은 관찰 기능도 추가합니다.

  • MicroProfile Health
  • MicroProfile Metrics
  • MicroProfile Config
  • MicroProfile OpenTracing

다음 Jakarta EE 사양은 jaxrs-server 계층에서 지원되는 것 외에도 이 계층에서 지원됩니다.

  • Jakarta Security 1.0

6.1.2. 데코레이터 계층

데코레이터 계층은 단독으로 사용되지 않습니다. 추가 기능을 제공하기 위해 기본 계층으로 하나 이상의 데코레이터 계층을 구성할 수 있습니다.

binaryd-lite

이 데코레이터 계층은 최소 Jakarta Enterprise Cryostat 구현을 프로비저닝된 서버에 추가합니다. 다음 지원은 이 계층에 포함되지 않습니다.

  • IIOP 통합
  • Cryostat 인스턴스 풀
  • 원격 커넥터 리소스

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

Jakarta Enterprise Cryostats

이 데코레이터 계층은 Cryostat -lite 계층을 확장합니다. 이 계층은 Cryostat -lite 계층에 포함된 기본 기능 외에도 프로비저닝된 서버에 다음과 같은 지원을 추가합니다.

  • Cryostat 인스턴스 풀
  • 원격 커넥터 리소스

message-driven beans (MDB) 또는 Jakarta Enterprise Cryostats remoting 기능을 사용하려면 이 계층을 사용합니다. 이러한 기능이 필요하지 않은 경우 Cryostat -lite 계층 을 사용합니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

ejb-local-cache

이 데코레이터 계층은 Jakarta Enterprise Cryostats에 대한 로컬 캐싱 지원을 프로비저닝된 서버에 추가합니다.

종속 항목: Cryostat -lite 계층 또는 Cryostat 계층을 포함하는 경우에만 이 계층을 포함할 수 있습니다.

참고

이 계층은 Cryostat -dist-cache 계층과 호환되지 않습니다. Cryostat -dist-cache 계층을 포함하는 경우 Cryostat -local-cache 계층을 포함할 수 없습니다. 두 계층이 모두 포함된 경우 결과 빌드에 예기치 않은 Jakarta Enterprise Cryostats 구성이 포함될 수 있습니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

ejb-dist-cache

이 데코레이터 계층은 Jakarta Enterprise Cryostats에 대한 분산 캐싱 지원을 프로비저닝된 서버에 추가합니다.

종속 항목: Cryostat -lite 계층 또는 Cryostat 계층을 포함하는 경우에만 이 계층을 포함할 수 있습니다.

참고

이 계층은 Cryostat -local-cache 계층과 호환되지 않습니다. Cryostat -dist-cache 계층을 포함하는 경우 Cryostat -local-cache 계층을 포함할 수 없습니다. 두 계층을 모두 포함하는 경우 결과 빌드로 인해 예기치 않은 구성이 발생할 수 있습니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

jdr

이 데코레이터 계층은 JBoss 진단 보고(jdr) 하위 시스템을 추가하여 Red Hat의 지원을 요청할 때 진단 데이터를 수집합니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

자카르타 지속성

이 데코레이터 계층은 단일 노드 서버에 대한 지속성 기능을 추가합니다. 분산 캐싱은 서버가 클러스터를 구성할 수 있는 경우에만 작동합니다.

계층은 다음과 같은 지원을 통해 프로비저닝된 서버에 Hibernate 라이브러리를 추가합니다.

  • jpa 하위 시스템의 구성
  • infinispan 하위 시스템의 구성
  • 로컬 Hibernate 캐시 컨테이너
참고

이 계층은 jpa-distributed 계층과 호환되지 않습니다. jpa 계층을 포함하는 경우 jpa-distributed 계층을 포함할 수 없습니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

JPA-distributed

이 데코레이터 계층은 클러스터에서 작동하는 서버에 대한 지속성 기능을 추가합니다. 계층은 다음과 같은 지원을 통해 프로비저닝된 서버에 Hibernate 라이브러리를 추가합니다.

  • jpa 하위 시스템의 구성
  • infinispan 하위 시스템의 구성
  • 로컬 Hibernate 캐시 컨테이너
  • Invalidation 및 replication Hibernate 캐시 컨테이너
  • jgroups 하위 시스템 구성
참고

이 계층은 jpa 계층과 호환되지 않습니다. jpa 계층을 포함하는 경우 jpa-distributed 계층을 포함할 수 없습니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

Jakarta Server seems

이 데코레이터 계층은 프로비저닝된 서버에 jsf 하위 시스템을 추가합니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

microprofile-platform

이 데코레이터 계층은 프로비저닝된 서버에 다음과 같은 MicroProfile 기능을 추가합니다.

  • MicroProfile Config
  • MicroProfile Fault Tolerance
  • MicroProfile Health
  • MicroProfile JWT
  • MicroProfile Metrics
  • MicroProfile OpenAPI
  • MicroProfile OpenTracing
참고

이 계층에는 관찰 계층에도 포함된 MicroProfile 기능이 포함되어 있습니다. 이 계층을 포함하는 경우 관찰 기능 계층을 포함할 필요가 없습니다.

observability

이 데코레이터 계층은 프로비저닝된 서버에 다음과 같은 관찰 기능을 추가합니다.

  • MicroProfile Health
  • MicroProfile Metrics
  • MicroProfile Config
  • MicroProfile OpenTracing
참고

이 계층은 cloud-server 계층에 빌드됩니다. 이 계층을 cloud-server 계층에 추가할 필요가 없습니다.

remote-activemq

이 데코레이터 계층은 원격 ActiveMQ 브로커와 프로비저닝된 서버에 통신하여 메시징 지원을 통합하는 기능을 추가합니다.

풀링된 연결 팩토리 구성은 guest사용자암호 속성 값으로 지정합니다. CLI 스크립트를 사용하여 런타임 시 이러한 값을 변경할 수 있습니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

sso

이 데코레이터 계층은 Red Hat Single Sign-On 통합을 프로비저닝된 서버에 추가합니다.

이 계층은 S2I를 사용하여 서버를 프로비저닝할 때만 사용해야 합니다.

web-console

이 데코레이터 계층은 프로비저닝된 서버에 관리 콘솔을 추가합니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

web-clustering

이 데코레이터 계층은 클러스터링 환경에 적합한 데이터 세션 처리를 위해 로컬이 아닌 Infinispan 컨테이너 웹 캐시를 구성하여 배포 가능한 웹 애플리케이션에 대한 지원을 추가합니다.

웹-비활성화

이 데코레이터 계층은 단일 노드 환경에 적합한 데이터 세션 처리를 위해 로컬 Infinispan 기반 컨테이너 웹 캐시를 구성하여 배포 가능한 웹 애플리케이션에 대한 지원을 추가합니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

WebServices

이 계층은 Jakarta 웹 서비스 배포를 지원하는 프로비저닝된 서버에 웹 서비스 기능을 추가합니다.

이 계층은 부팅 가능한 JAR을 빌드할 때만 지원됩니다. 이 계층은 S2I를 사용할 때 지원되지 않습니다.

7장. Red Hat CodeReady Studio에서 JBoss EAP에 대한 MicroProfile 애플리케이션 개발 활성화

CodeReady Studio에서 개발한 애플리케이션에 MicroProfile 기능을 통합하려면 CodeReady Studio에서 JBoss EAP에 대한 MicroProfile 지원을 활성화해야 합니다.

JBoss EAP 확장 팩은 MicroProfile에 대한 지원을 제공합니다.

JBoss EAP 확장 팩은 JBoss EAP 7.2 및 이전 버전에서 지원되지 않습니다.

JBoss EAP 확장 팩의 각 버전은 특정 JBoss EAP 패치를 지원합니다. 자세한 내용은 JBoss EAP 확장 팩 지원 및 라이프 사이클 정책 페이지를 참조하십시오.

중요

Openshift의 JBoss EAP XP 빠른 시작은 기술 프리뷰로만 제공됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

기술 프리뷰 기능에 대한 지원 범위에 대한 정보는 Red Hat 고객 포털에서 기술 프리뷰 기능 지원 범위를 참조하십시오.

7.1. MicroProfile 기능을 사용하도록 CodeReady Studio 구성

JBoss EAP에서 MicroProfile 지원을 활성화하려면 JBoss EAP XP의 새 런타임 서버를 등록한 다음 새 JBoss EAP 7.4 서버를 생성합니다.

서버에 MicroProfile 기능을 지원하는 것을 인식하는 데 도움이 되는 적절한 이름을 지정합니다.

이 서버는 이전에 설치한 런타임을 가리키며 standalone-microprofile.xml 구성 파일을 사용하는 새로 생성된 JBoss EAP XP 런타임을 사용합니다.

참고

Red Hat CodeReady Studio에서 Target 런타임7.4 또는 최신 런타임 버전으로 설정하는 경우 프로젝트는 Jakarta EE 8 사양과 호환됩니다.

프로세스

  1. 새 서버 대화 상자에서 새 서버를 설정합니다.

    1. Select server type 목록에서 Red Hat JBoss Enterprise Application Platform 7.4 를 선택합니다.
    2. 서버의 호스트 이름 필드에 localhost 를 입력합니다.
    3. 서버 이름 필드에 JBoss EAP 7.4 XP 를 입력합니다.
    4. 다음을 클릭합니다.
  2. 새 서버를 구성합니다.

    1. 홈 디렉터리 필드에서 기본 설정을 사용하지 않으려면 새 디렉터리를 지정합니다(예: home/myname/dev/microprofile/runtimes/jboss-eap-7.4 ).
    2. 실행 환경이 JavaSE-1.8 로 설정되어 있는지 확인합니다.
    3. 선택 사항: 서버 기본 디렉터리구성 파일 필드의 값을 변경합니다.
    4. 완료를 클릭합니다.

결과

이제 MicroProfile 기능을 사용하여 애플리케이션 개발을 시작하거나 JBoss EAP에 MicroProfile 빠른 시작 기능을 사용할 수 있습니다.

7.2. CodeReady Studio에 대한 MicroProfile 빠른 시작 사용

MicroProfile 빠른 시작을 활성화하면 설치된 서버에서 간단한 예제를 실행하고 테스트할 수 있습니다.

이 예제에서는 다음과 같은 MicroProfile 기능을 보여줍니다.

  • MicroProfile Config
  • MicroProfile Fault Tolerance
  • MicroProfile Health
  • MicroProfile JWT
  • MicroProfile Metrics
  • MicroProfile OpenAPI
  • MicroProfile OpenTracing
  • MicroProfile REST Client

프로세스

  1. 빠른 시작 부모 Artifact에서 pom.xml 파일을 가져옵니다.
  2. 사용 중인 빠른 시작에 환경 변수가 필요한 경우 환경 변수를 구성합니다.

    서버 개요 대화 상자의 시작 구성에 환경 변수를 정의합니다.

    예를 들어 microprofile-opentracing 빠른 시작에서는 다음 환경 변수를 사용합니다.

    • JAEGER_REPORTER_LOG_SPANStrue로 설정
    • JAEGER_SAMPLER_PARAM1로 설정
    • JAEGER_SAMPLER_TYPEconst로 설정

추가 리소스

Microprofile 정보

JBoss Enterprise Application Platform 확장 팩 정보

Red Hat JBoss Enterprise Application Platform 확장 팩 지원 및 라이프 사이클 정책

8장. 부팅 가능한 JAR

JBoss EAP JAR Maven 플러그인을 사용하여 마이크로서비스 애플리케이션을 부팅 가능한 JAR로 빌드하고 패키징할 수 있습니다. 그런 다음 JBoss EAP 베어 메탈 플랫폼 또는 JBoss EAP OpenShift 플랫폼에서 애플리케이션을 실행할 수 있습니다.

8.1. 부팅 가능한 JAR 정보

JBoss EAP JAR Maven 플러그인을 사용하여 마이크로서비스 애플리케이션을 부팅 가능한 JAR로 빌드하고 패키징할 수 있습니다.

부팅 가능한 JAR에는 서버, 패키지 애플리케이션, 서버를 시작하는 데 필요한 런타임이 포함되어 있습니다.

JBoss EAP JAR Maven 플러그인은 Galleon 트리밍 기능을 사용하여 서버의 크기와 메모리 공간을 줄입니다. 따라서 필요한 기능을 제공하는 Galleon 계층만 포함하여 요구 사항에 따라 서버를 구성할 수 있습니다.

JBoss EAP JAR Maven 플러그인은 JBoss EAP CLI 스크립트 파일의 실행을 지원하여 서버 구성을 사용자 지정할 수 있습니다. CLI 스크립트에는 서버 구성을 위한 CLI 명령 목록이 포함되어 있습니다.

부팅 가능한 JAR은 다음과 같은 방식으로 표준 JBoss EAP 서버와 같습니다.

  • JBoss EAP 공통 관리 CLI 명령을 지원합니다.
  • JBoss EAP 관리 콘솔을 사용하여 관리할 수 있습니다.

부팅 가능한 JAR에 서버를 패키징할 때 다음과 같은 제한 사항이 있습니다.

  • 서버를 다시 시작해야 하는 CLI 관리 작업은 지원되지 않습니다.
  • 서버는 서버 관리와 관련된 서비스를 시작하는 모드인 관리자 전용 모드로 다시 시작할 수 없습니다.
  • 서버를 종료하면 서버에 적용한 업데이트가 손실됩니다.

또한 빈 부팅 가능한 JAR을 프로비저닝할 수 있습니다. 이 JAR에는 서버만 포함되어 있으므로 서버를 재사용하여 다른 애플리케이션을 실행할 수 있습니다.

추가 리소스

기능 트리밍에 대한 자세한 내용은 용량 분류 ( Capability Trimming )를 참조하십시오.

8.2. JBoss EAP Maven 플러그인

JBoss EAP JAR Maven 플러그인을 사용하여 애플리케이션을 부팅 가능한 JAR로 빌드할 수 있습니다.

Maven 리포지토리에서 최신 Maven 플러그인 버전을 검색할 수 있습니다. 이 버전은 Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin 에서 사용할 수 있습니다.

Maven 프로젝트에서 src 디렉터리에는 애플리케이션을 빌드하는 데 필요한 모든 소스 파일이 포함되어 있습니다. JBoss EAP JAR Maven 플러그인이 부팅 가능한 JAR을 빌드한 후 생성된 JAR은 target/<application>-bootable.jar 에 있습니다.

JBoss EAP JAR Maven 플러그인에서는 다음과 같은 기능도 제공합니다.

  • CLI 스크립트 명령을 서버에 적용합니다.
  • org.jboss.eap:wildfly-galleon-pack Galleon 기능 팩과 일부 계층을 사용하여 서버 구성 파일을 사용자 정의합니다.
  • 키 저장소 파일과 같은 패키지 부팅 가능한 JAR에 추가 파일을 추가할 수 있습니다.
  • 애플리케이션에 포함되지 않은 부팅 가능한 JAR, 즉 부팅 가능한 JAR을 생성하는 기능이 포함되어 있습니다.

JBoss EAP JAR Maven 플러그인을 사용하여 부팅 가능한 JAR을 생성한 후 다음 명령을 실행하여 애플리케이션을 시작할 수 있습니다. target/myapp-bootable.jar 를 부팅 가능한 JAR 경로로 교체합니다. 예를 들면 다음과 같습니다.

$ java -jar target/myapp-bootable.jar
참고

지원되는 부팅 가능한 JAR 시작 명령 목록을 가져오려면 startup 명령 끝에 --help 를 추가합니다. 예를 들어 java -jar target/myapp-bootable.jar --help.

추가 리소스

8.3. 부팅 가능한 JAR 인수

부팅 가능한 JAR과 함께 사용할 수 있도록 지원되는 인수에 대해 알아보려면 다음 표의 인수를 확인합니다.

표 8.1. 지원되는 부팅 가능한 JAR 실행 인수
인수설명

--help

지정된 명령에 대한 도움말 메시지를 표시하고 종료합니다.

--cli-script=<path>

부팅 가능한 JAR을 시작할 때 실행되는 JBoss CLI 스크립트의 경로를 지정합니다. 지정된 경로가 상대적인 경우 부팅 가능한 JAR을 시작하는 데 사용되는 Java VM 인스턴스의 작업 디렉터리에 대해 경로가 확인됩니다.

--deployment=<path>

hollow 부팅 가능한 JAR과 관련된 인수입니다. 서버에 배포하려는 애플리케이션이 포함된 WAR, JAR, EAR 파일 또는 무관한 디렉터리의 경로를 지정합니다.

--display-galleon-config

생성된 Galleon 구성 파일의 내용을 출력합니다.

--install-dir=<path>

기본적으로 JVM 설정은 부팅 가능한 JAR이 시작된 후 TEMP 디렉터리를 생성하는 데 사용됩니다. --install-dir 인수를 사용하여 서버를 설치할 디렉터리를 지정할 수 있습니다.

-secmgr

보안 관리자가 설치된 서버를 실행합니다.

-b<interface>=<value>

시스템 속성 jboss.bind.address.<interface&gt;를 지정된 값으로 설정합니다. 예를 들어 bmanagement=IP_ADDRESS.

-b=<value>

공용 인터페이스의 바인딩 주소를 구성하는 데 사용되는 시스템 속성 jboss.bind.address 를 설정합니다. 값이 지정되지 않은 경우 기본값은 127.0.0.1입니다.

-D<name>[=<value>]

서버 런타임 시 서버에서 설정하는 시스템 속성을 지정합니다. 부팅 가능한 JAR JVM은 이러한 시스템 속성을 설정하지 않습니다.

--properties=<url>

지정된 URL에서 시스템 속성을 로드합니다.

-S<name>[=value]

보안 속성을 설정합니다.

-u=<value>

구성 파일의 socket-binding 요소에서 멀티 캐스트 주소를 구성하는 데 사용되는 시스템 속성 jboss.default.multicast.address 를 설정합니다. 값이 지정되지 않은 경우 기본값은 230.0.0.4입니다.

--version

애플리케이션 서버 버전을 표시하고 종료합니다.

8.4. 부팅 가능한 JAR 서버의 Galleon 계층 지정

Galleon 레이어를 지정하여 서버의 사용자 지정 구성을 빌드할 수 있습니다. 또한 서버에서 제외하려는 Galleon 레이어를 지정할 수 있습니다.

단일 기능 팩을 참조하려면 < feature-pack-location&gt; 요소를 사용하여 위치를 지정합니다. 다음 예제는 Maven 플러그인 구성 파일의 < feature-pack-location> 요소에서 org.jboss.eap:wildfly-galleon-pack:4.0.0.GA-redhat-00002 를 지정합니다.

<configuration>
  <feature-pack-location>org.jboss.eap:wildfly-galleon-pack:4.0.0.GA-redhat-00002</feature-pack-location>
</configuration>

둘 이상의 기능 팩을 참조해야 하는 경우 < feature-packs> 요소에 나열합니다. 다음 예제에서는 Red Hat Single Sign-On 기능 팩을 < feature-packs > 요소에 추가하는 방법을 보여줍니다.

<configuration>
    <feature-packs>
         <feature-pack>
             <location>org.jboss.eap:wildfly-galleon-pack:4.0.0.GA-redhat-00002</location>
        </feature-pack>
        <feature-pack>
            <location>org.keycloak:keycloak-adapter-galleon-pack:15.0.4.redhat-00001</location>
        </feature-pack>
    </feature-packs>
</configuration>

여러 기능 팩에서 Galleon 레이어를 결합하여 필요한 기능을 제공하는 지원되는 Galleon 계층만 포함하도록 부팅 가능한 JAR 서버를 구성할 수 있습니다.

참고

베어 메탈 플랫폼에서 구성 파일에 Galleon 계층을 지정하지 않으면 프로비저닝된 서버에 기본 standalone-microprofile.xml 구성과 동일한 구성이 포함됩니다.

OpenShift 플랫폼에서 플러그인 구성에 < cloud/ > 구성 요소를 추가하고 구성 파일에서 Galleon 계층을 지정하지 않도록 선택한 후 프로비저닝된 서버에는 클라우드 환경에 맞게 조정되고 기본 standalone-microprofile-ha.xml 과 유사한 구성이 포함되어 있습니다.

사전 요구 사항

  • Maven이 설치되어 있어야 합니다.
  • MAVEN_PLUGIN_VERSION. X.GA.Final-redhat-00001 과 같은 최신 Maven 플러그인 버전을 확인했습니다. 여기서 MAVEN_PLUGIN_VERSION 은 주요 버전입니다. /ga/org/wildfly/plugins/wildfly-jar-maven-plugin 의 인덱스 를 참조하십시오.
  • 4.0.X.GA-redhat-BUILD_NUMBER 와 같은 최신 Galleon 기능 팩 버전을 확인했습니다. 여기서 X 는 JBoss EAP XP의 마이크로 버전이며 BUILD_NUMBER 는 Galleon 기능 팩의 빌드 번호입니다. JBoss EAP XP 4.0.0 제품 라이프 사이클 기간 동안 XBUILD_NUMBER 가 진화할 수 있습니다. /ga/org/jboss/eap/wildfly-galleon-pack 인덱스 를 참조하십시오.
참고

절차에 표시된 예제에서는 다음 속성을 지정합니다.

  • ${bootable.jar.maven.plugin.version} 은(는) Maven 플러그인 버전에 해당합니다.
  • Galleon 기능 팩 버전의 ${JBoss.xp.galleon.feature.pack.version}

프로젝트에 이러한 속성을 설정해야 합니다. 예를 들면 다음과 같습니다.

<properties>
    <bootable.jar.maven.plugin.version>6.1.2.Final-redhat-00001</bootable.jar.maven.plugin.version>
    <jboss.xp.galleon.feature.pack.version>4.0.0.GA-redhat-00002</jboss.xp.galleon.feature.pack.version>
</properties>

프로세스

  1. 애플리케이션을 실행하는 데 필요한 기능을 제공하는 지원되는 JBoss EAP Galleon 계층을 식별합니다.
  2. Maven 프로젝트 pom.xml 파일의 &lt ;plugin& gt; 요소에서 JBoss EAP 기능 팩 위치를 참조합니다. 다음 예와 같이 모든 Maven 플러그인의 최신 버전과 org.jboss.eap:wildfly-galleon-pack Galleon 기능 팩을 지정해야 합니다. 다음 예제에서는 jaxrs-server 기본 계층과 jpa-distributed 계층을 포함하는 단일 기능 팩의 포함도 표시합니다. jaxrs-server 기본 계층은 서버에 대한 추가 지원을 제공합니다.

    <plugins>
          <plugin>
                <groupId>org.wildfly.plugins</groupId>
                 <artifactId>wildfly-jar-maven-plugin</artifactId>
                 <version>${bootable.jar.maven.plugin.version}</version>
                <configuration>
                     <feature-pack-location>org.jboss.eap:wildfly-galleon-pack:${jboss.xp.galleon.feature.pack.version}</feature-pack-location>
                     <layers>
                         <layer>jaxrs-server</layer>
                         <layer>jpa-distributed</layer>
                     </layers>
                     <excluded-layers>
                         <layer>jpa</layer>
                     </excluded-layers>
                     ...
    </plugins>

    이 예제에서는 프로젝트에서 jpa 계층을 제외하는 방법도 보여줍니다.

    참고

    jpa-distributed 계층을 프로젝트에 포함하는 경우 jpa 계층을 jaxrs-server 계층에서 제외해야 합니다. jpa 계층은 로컬 infinispan hibernate 캐시를 구성하고, jpa-distributed 계층은 원격 infinispan hibernate 캐시를 구성합니다.

추가 리소스

8.5. JBoss EAP 베어 메탈 플랫폼에서 부팅 가능한 JAR 사용

JBoss EAP 베어 메탈 플랫폼에서 애플리케이션을 부팅 가능한 JAR로 패키징할 수 있습니다.

참고
  • JBoss EAP 베어 메탈 플랫폼에서 부팅 가능한 JAR을 빌드할 때 사용자 지정 Galleon 기능 팩 및 계층을 사용하려면 JBoss EAP 용 사용자 지정 Galleon 계층 빌드 및 사용을 참조하십시오.
  • oc new-build 명령을 사용하여 애플리케이션 이미지를 빌드할 때 jboss-eap74-openjdk11-openshift:latest 대신 이 S2I 빌더 이미지 jboss-eap-xp4-openjdk11-openshift:latest 를 사용해야 합니다.

부팅 가능한 JAR에는 서버, 패키지 애플리케이션, 서버를 시작하는 데 필요한 런타임이 포함되어 있습니다.

이 절차에서는 JBoss EAP JAR Maven 플러그인을 사용하여 MicroProfile Config 마이크로 서비스 애플리케이션을 부팅 가능한 JAR로 패키징하는 방법을 보여줍니다. MicroProfile Config Development 를 참조하십시오.

CLI 스크립트를 사용하여 부팅 가능한 JAR을 패키징하는 동안 서버를 구성할 수 있습니다.

중요

부팅 가능한 JAR 내에 패키징해야 하는 웹 애플리케이션을 빌드하는 경우 pom.xml 파일의 < packaging > 요소에 war 를 지정해야 합니다. 예를 들면 다음과 같습니다.

<packaging>war</packaging>

이 값은 빌드 애플리케이션을 기본 JAR 파일이 아닌 WAR 파일로 패키징하는 데 필요합니다.

빈 부팅 가능한 JAR을 빌드하는 데에만 사용되는 Maven 프로젝트에서는 패키징 값을 pom 로 설정합니다. 예를 들면 다음과 같습니다.

<packaging>pom</packaging>

Maven 프로젝트에 대해 빈 부팅 가능한 JAR을 빌드할 때 pom 패키지 사용이 제한되지 않습니다. war 와 같은 모든 유형의 패키지에 대해 < hollow-jar > 요소에 true 를 지정하여 생성할 수 있습니다. JBoss EAP 베어 메탈 플랫폼에서 빈 부팅 가능한 JAR 생성 을 참조하십시오.

사전 요구 사항

  • MAVEN_PLUGIN_VERSION. X.GA.Final-redhat-00001 과 같은 최신 Maven 플러그인 버전을 확인했습니다. 여기서 MAVEN_PLUGIN_VERSION 은 주요 버전입니다. /ga/org/wildfly/plugins/wildfly-jar-maven-plugin 의 인덱스 를 참조하십시오.
  • 4.0.X.GA-redhat-BUILD_NUMBER 와 같은 최신 Galleon 기능 팩 버전을 확인했습니다. 여기서 X 는 JBoss EAP XP의 마이크로 버전이며 BUILD_NUMBER 는 Galleon 기능 팩의 빌드 번호입니다. JBoss EAP XP 4.0.0 제품 라이프 사이클 기간 동안 XBUILD_NUMBER 가 진화할 수 있습니다. /ga/org/jboss/eap/wildfly-galleon-pack 인덱스 를 참조하십시오.
  • Maven 프로젝트를 생성하고, 상위 종속성을 설정하고, MicroProfile 애플리케이션을 생성하기 위한 종속 항목을 추가했습니다. MicroProfile Config Development 를 참조하십시오.
참고

절차에 표시된 예제에서는 다음 속성을 지정합니다.

  • ${bootable.jar.maven.plugin.version} 은(는) Maven 플러그인 버전에 해당합니다.
  • Galleon 기능 팩 버전의 ${JBoss.xp.galleon.feature.pack.version}

프로젝트에 이러한 속성을 설정해야 합니다. 예를 들면 다음과 같습니다.

<properties>
    <bootable.jar.maven.plugin.version>6.1.2.Final-redhat-00001</bootable.jar.maven.plugin.version>
    <jboss.xp.galleon.feature.pack.version>4.0.0.GA-redhat-00002</jboss.xp.galleon.feature.pack.version>
</properties>

프로세스

  1. pom.xml 파일의 & lt;build > 요소에 다음 내용을 추가합니다. 모든 Maven 플러그인의 최신 버전과 org.jboss.eap:wildfly-galleon-pack Galleon 기능 팩을 지정해야 합니다. 예를 들면 다음과 같습니다.

    <plugins>
        <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-jar-maven-plugin</artifactId>
            <version>${bootable.jar.maven.plugin.version}</version>
            <configuration>
                 <feature-pack-location>org.jboss.eap:wildfly-galleon-pack:${jboss.xp.galleon.feature.pack.version}</feature-pack-location>
                <layers>
                    <layer>jaxrs-server</layer>
                    <layer>microprofile-platform</layer>
                </layers>
             </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>package</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
    참고

    pom.xml 파일에 Galleon 계층을 지정하지 않으면 부팅 가능한 JAR 서버에 standalone-microprofile.xml 구성과 동일한 구성이 포함됩니다.

  2. 애플리케이션을 부팅 가능한 JAR로 패키징합니다.

    $ mvn package
  3. 애플리케이션을 시작합니다.

    $ NAME="foo" java -jar target/microprofile-config-bootable.jar
    참고

    이 예제에서는 NAME 을 환경 변수로 사용하지만 기본값인 jim 을 사용하도록 선택할 수 있습니다.

    참고

    지원되는 부팅 가능한 JAR 인수 목록을 보려면 java -jar target/microprofile-config-bootable.jar 명령 끝에 --help 를 추가합니다.

  4. 웹 브라우저에서 다음 URL을 지정하여 MicroProfile Config 애플리케이션에 액세스합니다.

    http://localhost:8080/config/json
  5. 확인: 터미널에서 다음 명령을 실행하여 애플리케이션이 제대로 작동하는지 테스트합니다.

    curl http://localhost:8080/config/json

    다음은 예상되는 출력입니다.

    {"result":"Hello foo"}

추가 리소스

8.6. JBoss EAP 베어 메탈 플랫폼에서 빈 부팅 가능한 JAR 생성

JBoss EAP 베어 메탈 플랫폼에서 hollow 부팅 가능한 JAR로 애플리케이션을 패키징할 수 있습니다.

빈 부팅 가능한 JAR에는 JBoss EAP 서버만 포함되어 있습니다. hollow 부팅 가능한 JAR은 JBoss EAP JAR Maven 플러그인에 의해 패키지됩니다. 애플리케이션은 서버 런타임에서 제공됩니다. hollow 부팅 가능한 JAR은 다른 애플리케이션에 대해 서버 구성을 다시 사용해야 하는 경우 유용합니다.

사전 요구 사항

참고

절차에 표시된 예제에서는 Galleon 기능 팩 버전에 대해 ${jboss.xp.galleon.feature.pack.version} 을 지정하지만 프로젝트에서 속성을 설정해야 합니다. 예를 들면 다음과 같습니다.

<properties>
    <jboss.xp.galleon.feature.pack.version>4.0.0.GA-redhat-00002</jboss.xp.galleon.feature.pack.version>
</properties>

프로세스

  1. hollow 부팅 가능한 JAR을 빌드하려면 pom.xml 파일에서 < hollow-jar > 플러그인 구성 요소를 true로 설정해야 합니다. 예를 들면 다음과 같습니다.
<plugins>
        <plugin>
            ...
            <configuration>
                <!-- This example configuration does not show a complete plug-in configuration -->
                 ...
                <feature-pack-location>org.jboss.eap:wildfly-galleon-pack:${jboss.xp.galleon.feature.pack.version}</feature-pack-location>
                 <hollow-jar>true</hollow-jar>
            </configuration>
         </plugin>
</plugins>
참고

< hollow-jar > 요소에 true 를 지정하면 JBoss EAP JAR Maven 플러그인에 JAR에 애플리케이션이 포함되지 않습니다.

  1. 빈 부팅 가능한 JAR을 빌드합니다.

    $ mvn clean package
  2. hollow 부팅 가능한 JAR을 실행합니다.

    $ java -jar target/microprofile-config-bootable.jar --deployment=target/microprofile-config.war
    중요

    서버에 배포하려는 WAR 파일의 경로를 지정하려면 다음 인수를 사용합니다. 여기서 < PATH_NAME >은 배포 경로입니다.

    --deployment=<PATH_NAME>
  3. 애플리케이션에 액세스합니다.

    $ curl http://localhost:8080/microprofile-config/config/json
    참고

    루트 디렉터리에 웹 애플리케이션을 등록하려면 애플리케이션 이름을 ROOT.war 로 지정합니다.

추가 리소스

8.7. 빌드 시 실행되는 CLI 스크립트

CLI 스크립트를 생성하여 부팅 가능한 JAR을 패키징하는 동안 서버를 구성할 수 있습니다.

CLI 스크립트는 추가 서버 구성을 적용하는 데 사용할 수 있는 일련의 CLI 명령이 포함된 텍스트 파일입니다. 예를 들어 스크립트를 생성하여 로깅 하위 시스템에 새 로거를 추가할 수 있습니다.

CLI 스크립트에서 더 복잡한 작업을 지정할 수도 있습니다. 예를 들어 보안 관리 작업을 단일 명령으로 그룹화하여 관리 HTTP 끝점에 대한 HTTP 인증을 활성화할 수 있습니다.

참고

애플리케이션을 부팅 가능한 JAR로 패키징하기 전에 플러그인 구성의 < cli-session > 요소에 CLI 스크립트를 정의해야 합니다. 이렇게 하면 부팅 가능한 JAR 패키징 후 서버 구성 설정이 유지됩니다.

사전 정의된 Galleon 계층을 결합하여 애플리케이션을 배포하는 서버를 구성할 수 있지만 제한 사항이 있습니다. 예를 들어 부팅 가능한 JAR을 패키징할 때 Galleon 계층을 사용하여 HTTPS undertow 리스너를 활성화할 수 없습니다. 대신 CLI 스크립트를 사용해야 합니다.

pom.xml 파일의 < cli-session&gt; 요소에 CLI 스크립트를 정의해야 합니다. 다음 표에서는 CLI 세션 속성 유형을 보여줍니다.

표 8.2. CLI 스크립트 속성
인수설명

script-files

스크립트 파일의 경로 목록입니다.

properties-file

속성 파일의 경로를 지정하는 선택적 속성입니다. 이 파일에는 ${my.prop} 구문을 사용하여 스크립트가 참조할 수 있는 Java 속성이 나열됩니다. 다음 예제에서는 public inet-addressall.addresses:/interface=public:write-attribute(name=inet-address,value=$all.addresses}) 값으로 설정합니다.

resolve-expressions

부울 값이 포함된 선택적 속성입니다. 작업 요청을 서버로 보내기 전에 시스템 속성 또는 표현식이 해결되는지 여부를 나타냅니다. 기본값은 true 입니다.

참고
  • CLI 스크립트는 pom.xml 파일의 < cli-session& gt; 요소에 정의된 순서대로 시작됩니다.
  • JBoss EAP JAR Maven 플러그인은 각 CLI 세션에 포함된 서버를 시작합니다. 따라서 CLI 스크립트는 포함된 서버를 시작하거나 중지할 필요가 없습니다.

8.8. 런타임에 CLI 스크립트 실행

런타임 중에 서버 구성에 변경 사항을 적용할 수 있습니다. 그러면 실행 컨텍스트와 관련하여 서버를 조정할 수 있는 유연성을 제공합니다. 그러나 서버에 변경 사항을 적용하는 데 선호되는 방법은 빌드 시간 동안입니다.

프로세스

  • 부팅 가능한 JAR 및 --cli-script 인수를 시작합니다.

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

    java -jar myapp-bootable.jar --cli-scipt=my-scli-scipt.cli
참고
  • CLI 스크립트는 텍스트 파일(UTF-8)이어야 하며, .cli 확장자가 권장되지 않는 경우 파일 확장자가 의미가 없습니다.
  • 서버를 다시 시작해야 하는 작업은 부팅 가능한 JAR 인스턴스가 종료됩니다.
  • connect,reload,shutdown 및 포함된 서버 및 패치 와 관련된 모든 명령과 같은 CLI 명령이 작동하지 않습니다.
  • 관리 모드에서 실행할 수 없는 jdbc-driver-info 와 같은 CLI 명령은 지원되지 않습니다.
중요

CLI 스크립트를 실행하지 않고 서버를 다시 시작하면 새 서버 인스턴스에 이전 서버 인스턴스의 변경 사항이 포함되지 않습니다.

8.9. JBoss EAP OpenShift 플랫폼에서 부팅 가능한 JAR 사용

애플리케이션을 부팅 가능한 JAR로 패키지한 후 JBoss EAP OpenShift 플랫폼에서 애플리케이션을 실행할 수 있습니다.

참고
  • JBoss EAP OpenShift 플랫폼에서 부팅 가능한 JAR을 빌드할 때 사용자 지정 Galleon 기능 팩 및 계층을 사용하려면 JBoss EAP 용 사용자 지정 Galleon 계층 빌드 및 사용을 참조하십시오.
  • oc new-build 명령을 사용하여 애플리케이션 이미지를 빌드할 때 jboss-eap74-openjdk11-openshift:latest 대신 이 S2I 빌더 이미지 jboss-eap-xp4-openjdk11-openshift:latest 를 사용해야 합니다.
중요

OpenShift에서는 부팅 가능한 JAR과 함께 EAP Operator 자동 트랜잭션 복구 기능을 사용할 수 없습니다. 이 기술 제한에 대한 수정은 향후 JBoss EAP XP 4.0.0 패치 릴리스에 대해 계획되어 있습니다.

사전 요구 사항

  • MicroProfile Config 개발을 위한 Maven 프로젝트를 생성했습니다.
  • MAVEN_PLUGIN_VERSION. X.GA.Final-redhat-00001 과 같은 최신 Maven 플러그인 버전을 확인했습니다. 여기서 MAVEN_PLUGIN_VERSION 은 주요 버전입니다. /ga/org/wildfly/plugins/wildfly-jar-maven-plugin 의 인덱스 를 참조하십시오.
  • 4.0.X.GA-redhat-BUILD_NUMBER 와 같은 최신 Galleon 기능 팩 버전을 확인했습니다. 여기서 X 는 JBoss EAP XP 4의 마이크로 버전이며 BUILD_NUMBER 는 Galleon 기능 팩의 빌드 번호입니다. JBoss EAP XP 4.0.0 제품 라이프 사이클 기간 동안 XBUILD_NUMBER 가 진화할 수 있습니다. /ga/org/jboss/eap/wildfly-galleon-pack 인덱스 를 참조하십시오.
참고

절차에 표시된 예제에서는 다음 속성을 지정합니다.

  • ${bootable.jar.maven.plugin.version} 은(는) Maven 플러그인 버전에 해당합니다.
  • Galleon 기능 팩 버전의 ${JBoss.xp.galleon.feature.pack.version}

프로젝트에 이러한 속성을 설정해야 합니다. 예를 들면 다음과 같습니다.

<properties>
    <bootable.jar.maven.plugin.version>6.1.2.Final-redhat-00001</bootable.jar.maven.plugin.version>
    <jboss.xp.galleon.feature.pack.version>4.0.0.GA-redhat-00002</jboss.xp.galleon.feature.pack.version>
</properties>

프로세스

  1. pom.xml 파일의 & lt;build > 요소에 다음 내용을 추가합니다. 모든 Maven 플러그인의 최신 버전과 org.jboss.eap:wildfly-galleon-pack Galleon 기능 팩을 지정해야 합니다. 예를 들면 다음과 같습니다.

    <plugins>
        <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-jar-maven-plugin</artifactId>
            <version>${bootable.jar.maven.plugin.version}</version>
            <configuration>
                <feature-pack-location>org.jboss.eap:wildfly-galleon-pack:${jboss.xp.galleon.feature.pack.version}</feature-pack-location>
                <layers>
                    <layer>jaxrs-server</layer>
                    <layer>microprofile-platform</layer>
                </layers>
                <cloud/>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>package</goal>
                        </goals>
                    </execution>
                </executions>
        </plugin>
    </plugins>
    참고

    JBoss EAP Maven JAR 플러그인에서 OpenShift 플랫폼을 선택하는지 확인할 수 있도록 플러그인 구성 의 <configuration> 요소에 < cloud/ > 요소를 포함해야 합니다.

  2. 애플리케이션을 패키징합니다.

    $ mvn package
  3. oc login 명령을 사용하여 OpenShift 인스턴스에 로그인합니다.
  4. OpenShift에서 새 프로젝트를 생성합니다. 예를 들면 다음과 같습니다.

    $ oc new-project bootable-jar-project
  5. 다음 oc 명령을 입력하여 애플리케이션 이미지를 생성합니다.

    $ mkdir target/openshift && cp target/microprofile-config-bootable.jar target/openshift  1
    
    $ oc import-image ubi8/openjdk-11 --from=registry.redhat.io/ubi8/openjdk-11 --confirm 2
    
    $ oc new-build --strategy source --binary --image-stream openjdk-11 --name microprofile-config-app 3
    
    $ oc start-build microprofile-config-app --from-dir target/openshift 4
    1
    대상 디렉터리에 openshift 하위 디렉터리를 생성합니다. 패키지 애플리케이션은 생성된 하위 디렉터리로 복사됩니다.
    2
    최신 OpenJDK 11 이미지 스트림 태그 및 이미지 정보를 OpenShift 프로젝트로 가져옵니다.
    3
    microprofile-config-app 디렉터리 및 OpenJDK 11 이미지 스트림을 기반으로 빌드 구성을 생성합니다.
    4
    target/openshift 하위 디렉터리를 바이너리 입력으로 사용하여 애플리케이션을 빌드합니다.
    참고

    OpenShift는 부팅 가능한 JAR 구성 파일에 CLI 스크립트 명령 세트를 적용하여 클라우드 환경에 조정합니다. Maven 프로젝트 / target 디렉터리에서 bootable-jar-build-artifacts/generated-cli-script.txt 파일을 열어 이 스크립트에 액세스할 수 있습니다.

  6. 확인:

    사용 가능한 OpenShift 포드 목록을 보고 다음 명령을 실행하여 포드 빌드 상태를 확인합니다.

    $ oc get pods

    빌드된 애플리케이션 이미지를 확인합니다.

    $ oc get is microprofile-config-app

    출력에는 이름 및 이미지 리포지토리, 태그 등과 같은 빌드된 애플리케이션 이미지 세부 정보가 표시됩니다. 이 절차의 예에서는 이미지 스트림 이름과 태그 출력에 microprofile-config-app:latest 가 표시됩니다.

  7. 애플리케이션을 배포합니다.

    $ oc new-app microprofile-config-app
    
    $ oc expose svc/microprofile-config-app
    중요

    부팅 가능한 JAR에 시스템 속성을 제공하려면 JAVA_OPTS_APPEND 환경 변수를 사용해야 합니다. 다음 예제에서는 JAVA_OPTS_APPEND 환경 변수를 사용하는 방법을 보여줍니다.

    $ oc new-app <_IMAGESTREAM_> -e JAVA_OPTS_APPEND="-Xlog:gc*:file=/tmp/gc.log:time -Dwildfly.statistics-enabled=true"

    새 애플리케이션이 생성되고 시작됩니다. 애플리케이션 구성이 새 서비스로 노출됩니다.

  8. verification: 터미널에서 다음 명령을 실행하여 애플리케이션이 제대로 작동하는지 테스트합니다.

    $ curl http://$(oc get route microprofile-config-app --template='{{ .spec.host }}')/config/json

    예상 출력:

    {"result":"Hello jim"}

추가 리소스

8.10. OpenShift의 부팅 가능한 JAR 구성

부팅 가능한 JAR을 사용하기 전에 독립 실행형 서버가 OpenShift용 JBoss EAP에서 올바르게 작동하는지 확인하기 위해 JVM 설정을 구성할 수 있습니다.

JAVA_OPTS_APPEND 환경 변수를 사용하여 JVM 설정을 구성합니다. JAVA_ARGS 명령을 사용하여 부팅 가능한 JAR에 인수를 제공합니다.

환경 변수를 사용하여 속성 값을 설정할 수 있습니다. 예를 들어 JAVA_OPTS_APPEND 환경 변수를 사용하여 -Dwildfly.statistics-enabled 속성을 true 로 설정할 수 있습니다.

JAVA_OPTS_APPEND="-Xlog:gc*:file=/tmp/gc.log:time -Dwildfly.statistics-enabled=true"

이제 서버에 대한 통계가 활성화되어 있습니다.

참고

부팅 가능한 JAR에 인수를 제공해야 하는 경우 JAVA_ARGS 환경 변수를 사용합니다.

OpenShift용 JBoss EAP는 JDK 11 이미지를 제공합니다. 부팅 가능한 JAR과 관련된 애플리케이션을 실행하려면 먼저 최신 OpenJDK 11 이미지 스트림 태그 및 이미지 정보를 OpenShift 프로젝트로 가져와야 합니다. 그런 다음 환경 변수를 사용하여 가져온 이미지에서 JVM을 구성할 수 있습니다.

OpenShift S2I 이미지에 사용된 JVM을 구성하는 데 동일한 구성 옵션을 적용할 수 있지만 다음과 같은 차이점이 있습니다.

  • 선택 사항: -Xlog 기능을 사용할 수 없지만 -Xlog:gc 를 활성화하여 가비지 컬렉션 로깅을 설정할 수 있습니다. 예: JAVA_OPTS_APPEND="-Xlog:gc*:file=/tmp/gc.log:time".
  • 초기 메타 공간 크기를 늘리려면 GC_MET CryostatACE_SIZE 환경 변수를 설정할 수 있습니다. 최상의 메타데이터 용량 성능을 위해서는 값을 96 으로 설정합니다.
  • 임의의 파일 생성을 개선하기 위해 JAVA_OPTS_APPEND 환경 변수를 사용하여 java.security.egd 속성을 -Djava.security.egd=file:/dev/urandom 로 설정합니다.

이러한 구성은 가져온 OpenJDK 11 이미지에서 실행할 때 JVM의 메모리 설정 및 가비지 수집 기능을 향상시킵니다.

8.11. OpenShift의 애플리케이션에서 ConfigMap 사용

OpenShift의 경우 배포 컨트롤러(dc)를 사용하여 애플리케이션을 실행하는 데 사용되는 포드에 configmap을 마운트할 수 있습니다.

ConfigMap 은 기밀이 아닌 데이터를 키-값 쌍으로 저장하는 데 사용되는 OpenShift 리소스입니다.

microprofile-platform Galleon 계층을 지정하여 microprofile-config-windowsrye 하위 시스템 및 서버 구성 파일에 확장을 추가한 후 CLI 스크립트를 사용하여 서버 구성에 새 ConfigSource 를 추가할 수 있습니다. CLI 스크립트를 Maven 프로젝트의 루트 디렉터리에 /scripts 디렉터리와 같은 액세스 가능한 디렉터리에 저장할 수 있습니다.

MicroProfile Config 기능은 SmallRye Config 구성 요소를 사용하여 JBoss EAP에서 구현되며 microprofile-config-undercloudrye 하위 시스템에서 제공합니다. 이 하위 시스템은 microprofile-platform Galleon 계층에 포함되어 있습니다.

사전 요구 사항

  • Maven이 설치되어 있어야 합니다.
  • JBoss EAP Maven 리포지토리를 구성했습니다.
  • 애플리케이션을 부팅 가능한 JAR로 패키징했으며 JBoss EAP OpenShift 플랫폼에서 애플리케이션을 실행할 수 있습니다. OpenShift 플랫폼에서 부팅 가능한 JAR로 애플리케이션을 빌드하는 방법에 대한 자세한 내용은 JBoss EAP OpenShift 플랫폼에서 부팅 가능한 JAR 사용을 참조하십시오.

프로세스

  1. 프로젝트의 루트 디렉터리에 scripts 라는 디렉터리를 생성합니다. 예를 들면 다음과 같습니다.

    $ mkdir scripts
  2. cli.properties 파일을 생성하고 파일을 /scripts 디렉터리에 저장합니다. 이 파일에서 config.pathconfig.ordinal 시스템 속성을 정의합니다. 예를 들면 다음과 같습니다.

    config.path=/etc/config
    config.ordinal=200
  3. mp-config.cli 와 같은 CLI 스크립트를 생성하고 /scripts 디렉터리와 같은 부팅 가능한 JAR의 액세스 가능한 디렉터리에 저장합니다. 다음 예제에서는 mp-config.cli 스크립트의 내용을 보여줍니다.

    # config map
    
    /subsystem=microprofile-config-smallrye/config-source=os-map:add(dir={path=${config.path}}, ordinal=${config.ordinal})

    mp-config.cli CLI 스크립트는 속성 파일에서 ordinal 및 path 값이 검색되는 새 ConfigSource 를 생성합니다.

  4. 스크립트를 프로젝트의 루트 디렉터리에 있는 /scripts 디렉터리에 저장합니다.
  5. 기존 플러그인 <configuration> 요소에 다음 구성 추출을 추가합니다.

    <cli-sessions>
        <cli-session>
            <properties-file>
                scripts/cli.properties
            </properties-file>
            <script-files>
                <script>scripts/mp-config.cli</script>
            </script-files>
        </cli-session>
    </cli-sessions>
  6. 애플리케이션을 패키징합니다.

    $ mvn package
  7. oc login 명령을 사용하여 OpenShift 인스턴스에 로그인합니다.
  8. 선택 사항: 이전에 target/openshift 하위 디렉터리를 생성하지 않은 경우 다음 명령을 실행하여 suddirectory를 생성해야 합니다.

    $ mkdir target/openshift
  9. 패키지 애플리케이션을 생성된 하위 디렉터리에 복사합니다.

    $ cp target/microprofile-config-bootable.jar target/openshift
  10. target/openshift 하위 디렉터리를 바이너리 입력으로 사용하여 애플리케이션을 빌드합니다.

    $ oc start-build microprofile-config-app --from-dir target/openshift
    참고

    OpenShift는 부팅 가능한 JAR 구성 파일에 CLI 스크립트 명령 세트를 적용하여 클라우드 환경에서 활성화합니다. Maven 프로젝트 /target 디렉터리에서 bootable-jar-build-artifacts/generated-cli-script.txt 파일을 열어 이 스크립트에 액세스할 수 있습니다.

  11. ConfigMap 을 생성합니다. 예를 들면 다음과 같습니다.

    $ oc create configmap microprofile-config-map --from-literal=name="Name comes from Openshift ConfigMap"
  12. dc를 사용하여 ConfigMap 을 애플리케이션에 마운트합니다. 예를 들면 다음과 같습니다.

    $ oc set volume deployments/microprofile-config-app --add --name=config-volume \
    --mount-path=/etc/config \
    --type=configmap \
    --configmap-name=microprofile-config-map

    oc set volume 명령을 실행한 후 애플리케이션이 새 구성 설정으로 다시 배포됩니다.

  13. 출력을 테스트합니다.

    $ curl http://$(oc get route microprofile-config-app --template='{{ .spec.host }}')/config/json

    다음은 예상되는 출력입니다.

    {"result":"Hello Name comes from Openshift ConfigMap"}

추가 리소스

8.12. 부팅 가능한 JAR Maven 프로젝트 생성

절차의 단계에 따라 예제 Maven 프로젝트를 생성합니다. 다음 절차를 수행하려면 Maven 프로젝트를 생성해야 합니다.

  • 부팅 가능한 JAR에 대한 JSON 로깅 활성화
  • 여러 부팅 가능한 JAR 인스턴스에 대한 웹 세션 데이터 스토리지 활성화
  • CLI 스크립트를 사용하여 부팅 가능한 JAR에 대한 HTTP 인증 활성화
  • Red Hat Single Sign-On을 사용하여 JBoss EAP 부팅 가능한 JAR 애플리케이션 보안

프로젝트 pom.xml 파일에서 부팅 가능한 JAR을 빌드하는 데 필요한 프로젝트 아티팩트를 검색하도록 Maven을 구성할 수 있습니다.

프로세스

  1. Maven 프로젝트를 설정합니다.

    $ mvn archetype:generate \
    -DgroupId=GROUP_ID \
    -DartifactId=ARTIFACT_ID \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false

    여기서 GROUP_ID 는 프로젝트의 groupId 이고 ARTIFACT_ID 는 프로젝트의 artifactId 입니다.

  2. pom.xml 파일에서 원격 리포지토리에서 JBoss EAP BOM 파일을 검색하도록 Maven을 구성합니다.

    <repositories>
        <repository>
            <id>jboss</id>
            <url>https://maven.repository.redhat.com/ga</url>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
    </repositories>
    <pluginRepositories>
      <pluginRepository>
          <id>jboss</id>
            <url>https://maven.repository.redhat.com/ga</url>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
      </pluginRepository>
    </pluginRepositories>
  3. jboss-eap-jakartaee8 BOM에서 Jakarta EE 아티팩트의 버전을 자동으로 관리하도록 Maven을 구성하려면 pom.xml 파일의 < dependencyManagement > 섹션에 BOM을 추가합니다. 예를 들면 다음과 같습니다.

    <dependencyManagement>
      <dependencies>
        <dependency>
            <groupId>org.jboss.bom</groupId>
            <artifactId>jboss-eap-jakartaee8</artifactId>
            <version>7.3.4.GA</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
      </dependencies>
    </dependencyManagement>
  4. 다음 예와 같이 BOM에서 관리하는 서블릿 API 아티팩트를 프로젝트 pom.xml 파일의 < dependency > 섹션에 추가합니다.

    <dependency>
        <groupId>org.jboss.spec.javax.servlet</groupId>
        <artifactId>jboss-servlet-api_4.0_spec</artifactId>
        <scope>provided</scope>
    </dependency>

추가 리소스

8.13. 부팅 가능한 JAR에 대한 JSON 로깅 활성화

CLI 스크립트로 서버 로깅 구성을 구성하여 부팅 가능한 JAR에 대한 JSON 로깅을 활성화할 수 있습니다. JSON 로깅을 활성화하면 JSON 포맷터를 사용하여 JSON 형식의 로그 메시지를 볼 수 있습니다.

이 절차의 예제에서는 베어 메탈 플랫폼과 OpenShift 플랫폼에서 부팅 가능한 JAR에 대한 JSON 로깅을 활성화하는 방법을 보여줍니다.

사전 요구 사항

  • MAVEN_PLUGIN_VERSION. X.GA.Final-redhat-00001 과 같은 최신 Maven 플러그인 버전을 확인했습니다. 여기서 MAVEN_PLUGIN_VERSION 은 주요 버전입니다. /ga/org/wildfly/plugins/wildfly-jar-maven-plugin 의 인덱스 를 참조하십시오.
  • 4.0.X.GA-redhat-BUILD_NUMBER 와 같은 최신 Galleon 기능 팩 버전을 확인했습니다. 여기서 X 는 JBoss EAP XP의 마이너 버전이며 BUILD_NUMBER 는 Galleon 기능 팩의 빌드 번호입니다. JBoss EAP XP 4.0.0 제품 라이프 사이클 기간 동안 XBUILD_NUMBER 가 진화할 수 있습니다. /ga/org/jboss/eap/wildfly-galleon-pack 인덱스 를 참조하십시오.
  • Maven 프로젝트를 생성하고, 상위 종속성을 설정하고, 애플리케이션을 생성하기 위한 종속 항목을 추가했습니다. 부팅 가능한 JAR Maven 프로젝트 생성 을 참조하십시오.

    중요

    Maven 프로젝트의 Maven archetype에서는 프로젝트와 관련된 groupID 및 artifactID를 지정해야 합니다. 예를 들면 다음과 같습니다.

    $ mvn archetype:generate \
    -DgroupId=com.example.logging \
    -DartifactId=logging \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false
    cd logging
    참고

    절차에 표시된 예제에서는 다음 속성을 지정합니다.

    • ${bootable.jar.maven.plugin.version} 은(는) Maven 플러그인 버전에 해당합니다.
    • Galleon 기능 팩 버전의 ${JBoss.xp.galleon.feature.pack.version}

    프로젝트에 이러한 속성을 설정해야 합니다. 예를 들면 다음과 같습니다.

    <properties>
        <bootable.jar.maven.plugin.version>6.1.2.Final-redhat-00001</bootable.jar.maven.plugin.version>
        <jboss.xp.galleon.feature.pack.version>4.0.0.GA-redhat-00002</jboss.xp.galleon.feature.pack.version>
    </properties>

프로세스

  1. BOM에서 관리하는 JBoss Logging 및 Jakarta RESTful Web Services 종속성을 프로젝트 pom.xml 파일의 < dependencies > 섹션에 추가합니다. 예를 들면 다음과 같습니다.

    <dependencies>
        <dependency>
            <groupId>org.jboss.logging</groupId>
            <artifactId>jboss-logging</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.spec.javax.ws.rs</groupId>
            <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
            <scope>provided</scope>
        </dependency>
    </dependencies>
  2. pom.xml 파일의 & lt;build > 요소에 다음 내용을 추가합니다. 모든 Maven 플러그인의 최신 버전과 org.jboss.eap:wildfly-galleon-pack Galleon 기능 팩을 지정해야 합니다. 예를 들면 다음과 같습니다.

    <plugins>
        <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-jar-maven-plugin</artifactId>
            <version>${bootable.jar.maven.plugin.version}</version>
            <configuration>
                <feature-packs>
                    <feature-pack>
                        <location>org.jboss.eap:wildfly-galleon-pack:${jboss.xp.galleon.feature.pack.version}</location>
                    </feature-pack>
                </feature-packs>
                <layers>
                    <layer>jaxrs-server</layer>
                 </layers>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>package</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
  3. Java 파일을 저장할 디렉터리를 만듭니다.

    $ mkdir -p APPLICATION_ROOT/src/main/java/com/example/logging/

    여기서 APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일이 포함된 디렉터리입니다.

  4. 다음 내용으로 Java 파일 RestApplication.java 를 생성하고 APPLICATION_ROOT/src/main/java/com/example/logging/ 디렉터리에 파일을 저장합니다.

    package com.example.logging;
    import javax.ws.rs.ApplicationPath;
    import javax.ws.rs.core.Application;
    
    @ApplicationPath("/")
    public class RestApplication extends Application {
    }
  5. 다음 내용으로 Java 파일 HelloWorldEndpoint.java 를 생성하고 파일을 APPLICATION_ROOT/src/main/java/com/example/logging/ 디렉터리에 저장합니다.

    package com.example.logging;
    
    import javax.ws.rs.Path;
    import javax.ws.rs.core.Response;
    import javax.ws.rs.GET;
    import javax.ws.rs.Produces;
    
    import org.jboss.logging.Logger;
    @Path("/hello")
    public class HelloWorldEndpoint {
    
        private static Logger log = Logger.getLogger(HelloWorldEndpoint.class.getName());
        @GET
        @Produces("text/plain")
        public Response doGet() {
            log.debug("HelloWorldEndpoint.doGet called");
            return Response.ok("Hello from XP bootable jar!").build();
        }
    }
  6. logging.cli 와 같은 CLI 스크립트를 생성하고 APPLICATION_ROOT/scripts 디렉터리와 같은 부팅 가능한 JAR의 액세스 가능한 디렉터리에 저장합니다. 여기서 APPLICATION_ROOT 는 Maven 프로젝트의 루트 디렉터리입니다. 이 스크립트는 다음 명령을 포함해야 합니다.

    /subsystem=logging/logger=com.example.logging:add(level=ALL)
    /subsystem=logging/json-formatter=json-formatter:add(exception-output-type=formatted, pretty-print=false, meta-data={version="1"}, key-overrides={timestamp="@timestamp"})
    /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level,value=ALL)
    /subsystem=logging/console-handler=CONSOLE:write-attribute(name=named-formatter, value=json-formatter)
  7. 플러그인 <configuration> 요소에 다음 구성 추출을 추가합니다.

    <cli-sessions>
            <cli-session>
            <script-files>
                <script>scripts/logging.cli</script>
            </script-files>
        </cli-session>
    </cli-sessions>

    이 예에서는 서버 로깅 구성 파일을 수정하여 애플리케이션에 대한 JSON 로깅을 활성화하는 logging.cli CLI 스크립트를 보여줍니다.

  8. 애플리케이션을 부팅 가능한 JAR로 패키징합니다.

    $ mvn package
  9. 선택 사항: JBoss EAP 베어 메탈 플랫폼에서 애플리케이션을 실행하려면 JBoss EAP 베어 메탈 플랫폼에서 부팅 가능한 JAR 사용에 설명된 단계를 따르십시오. 그러나 다음과 같은 차이점이 있습니다.

    1. 애플리케이션을 시작합니다.

      mvn wildfly-jar:run
    2. 확인: 브라우저에 다음 URL을 지정하여 애플리케이션에 액세스할 수 있습니다. http://127.0.0.1:8080/hello.

      예상 출력: 애플리케이션 콘솔에서 com.example.logging.HelloWorldEndpoint 디버그 추적을 포함한 JSON 형식의 로그를 볼 수 있습니다.

  10. 선택 사항: JBoss EAP OpenShift 플랫폼에서 애플리케이션을 실행하려면 다음 단계를 완료합니다.

    1. &lt ;cloud/& gt; 요소를 플러그인 구성에 추가합니다. 예를 들면 다음과 같습니다.

      <plugins>
         <plugin>
             ... <!-- You must evolve the existing configuration with the <cloud/> element  -->
             <configuration >
                 ...
                 <cloud/>
              </configuration>
          </plugin>
      </plugins>
    2. 애플리케이션을 다시 빌드합니다.

      $ mvn clean package
    3. oc login 명령을 사용하여 OpenShift 인스턴스에 로그인합니다.
    4. OpenShift에서 새 프로젝트를 생성합니다. 예를 들면 다음과 같습니다.

      $ oc new-project bootable-jar-project
    5. 다음 oc 명령을 입력하여 애플리케이션 이미지를 생성합니다.

      $ mkdir target/openshift && cp target/logging-bootable.jar target/openshift 1
      
      $ oc import-image ubi8/openjdk-11 --from=registry.redhat.io/ubi8/openjdk-11 --confirm
       2
      
      $ oc new-build --strategy source --binary --image-stream openjdk-11 --name logging 3
      
      $ oc start-build logging --from-dir target/openshift 4
      1
      target/openshift 하위 디렉터리를 생성합니다. 패키지 애플리케이션은 openshift 하위 디렉터리에 복사됩니다.
      2
      최신 OpenJDK 11 이미지 스트림 태그 및 이미지 정보를 OpenShift 프로젝트로 가져옵니다.
      3
      로깅 디렉터리 및 OpenJDK 11 이미지 스트림을 기반으로 빌드 구성을 생성합니다.
      4
      target/openshift 하위 디렉터리를 바이너리 입력으로 사용하여 애플리케이션을 빌드합니다.
    6. 애플리케이션을 배포합니다.

      $ oc new-app logging
      
      $ oc expose svc/logging
    7. 경로의 URL을 가져옵니다.

      $ oc get route logging --template='{{ .spec.host }}'
    8. 이전 명령에서 반환된 URL을 사용하여 웹 브라우저의 애플리케이션에 액세스합니다. 예를 들면 다음과 같습니다.

      http://ROUTE_NAME/hello
    9. 확인: 사용 가능한 OpenShift Pod 목록을 보고 Pod 빌드 상태를 확인하려면 다음 명령을 실행합니다.

      $ oc get pods

      애플리케이션의 실행 중인 Pod 로그에 액세스합니다. 여기서 APP_POD_NAME 은 실행 중인 포드 로깅 애플리케이션의 이름입니다.

      $ oc logs APP_POD_NAME

      예상 결과: Pod 로그는 JSON 형식이며 com.example.logging.HelloWorldEndpoint 디버그 추적을 포함합니다.

추가 리소스

8.14. 여러 부팅 가능한 JAR 인스턴스에 대한 웹 세션 데이터 스토리지 활성화

웹 클러스터 애플리케이션을 부팅 가능한 JAR로 빌드하고 패키징할 수 있습니다.

사전 요구 사항

  • MAVEN_PLUGIN_VERSION. X.GA.Final-redhat-00001 과 같은 최신 Maven 플러그인 버전을 확인했습니다. 여기서 MAVEN_PLUGIN_VERSION 은 주요 버전입니다. /ga/org/wildfly/plugins/wildfly-jar-maven-plugin 의 인덱스 를 참조하십시오.
  • 4.0.X.GA-redhat-BUILD_NUMBER 와 같은 최신 Galleon 기능 팩 버전을 확인했습니다. 여기서 X 는 JBoss EAP XP의 마이크로 버전이며 BUILD_NUMBER 는 Galleon 기능 팩의 빌드 번호입니다. JBoss EAP XP 4.0.0 제품 라이프 사이클 기간 동안 XBUILD_NUMBER 가 진화할 수 있습니다. /ga/org/jboss/eap/wildfly-galleon-pack 인덱스 를 참조하십시오.
  • Maven 프로젝트를 생성하고, 상위 종속성을 설정하며, 웹 클러스터링 애플리케이션을 생성하기 위한 종속 항목을 추가했습니다. 부팅 가능한 JAR Maven 프로젝트 생성 을 참조하십시오.

    중요

    Maven 프로젝트를 설정할 때 Maven archetype 구성에 값을 지정해야 합니다. 예를 들면 다음과 같습니다.

    $ mvn archetype:generate \
    -DgroupId=com.example.webclustering \
    -DartifactId=web-clustering \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false
    cd web-clustering
    참고

    절차에 표시된 예제에서는 다음 속성을 지정합니다.

    • ${bootable.jar.maven.plugin.version} 은(는) Maven 플러그인 버전에 해당합니다.
    • Galleon 기능 팩 버전의 ${JBoss.xp.galleon.feature.pack.version}

    프로젝트에 이러한 속성을 설정해야 합니다. 예를 들면 다음과 같습니다.

    <properties>
        <bootable.jar.maven.plugin.version>6.1.2.Final-redhat-00001</bootable.jar.maven.plugin.version>
        <jboss.xp.galleon.feature.pack.version>4.0.0.GA-redhat-00002</jboss.xp.galleon.feature.pack.version>
    </properties>

프로세스

  1. pom.xml 파일의 & lt;build > 요소에 다음 내용을 추가합니다. 모든 Maven 플러그인의 최신 버전과 org.jboss.eap:wildfly-galleon-pack Galleon 기능 팩을 지정해야 합니다. 예를 들면 다음과 같습니다.

    <plugins>
        <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-jar-maven-plugin</artifactId>
            <version>${bootable.jar.maven.plugin.version}</version>
            <configuration>
                <feature-pack-location>org.jboss.eap:wildfly-galleon-pack:${jboss.xp.galleon.feature.pack.version}</feature-pack-location>
                <layers>
                    <layer>datasources-web-server</layer>
                    <layer>web-clustering</layer>
                </layers>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>package</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
    참고

    이 예제에서는 웹 클러스터링 Galleon 계층을 사용하여 웹 세션 공유를 활성화합니다.

  2. src/main/webapp/WEB-INF 디렉토리에서 다음 구성을 사용하여 web.xml 파일을 업데이트합니다.

    <?xml version="1.0" encoding="UTF-8"?>
    
    <web-app version="4.0"
             xmlns="http://xmlns.jcp.org/xml/ns/javaee"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee  http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd">
        <distributable/>
    </web-app>

    & lt;distributable/& gt; 태그는 이 서블릿이 여러 서버에 분산될 수 있음을 나타냅니다.

  3. Java 파일을 저장할 디렉터리를 만듭니다.

    $ mkdir -p APPLICATION_ROOT
    /src/main/java/com/example/webclustering/

    여기서 APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일이 포함된 디렉터리입니다.

  4. 다음 내용으로 Java 파일 MyServlet.java 를 만들고 파일을 APPLICATION_ROOT/src/main/java/com/example/webclustering/ 디렉터리에 저장합니다.

    package com.example.webclustering;
    
    import java.io.IOException;
    import java.io.PrintWriter;
    import javax.servlet.ServletException;
    import javax.servlet.annotation.WebServlet;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    
    @WebServlet(urlPatterns = {"/clustering"})
    public class MyServlet extends HttpServlet {
        @Override
        protected void doGet(HttpServletRequest request, HttpServletResponse response)
                throws IOException {
            response.setContentType("text/html;charset=UTF-8");
            long t;
            User user = (User) request.getSession().getAttribute("user");
            if (user == null) {
                t = System.currentTimeMillis();
                user = new User(t);
                request.getSession().setAttribute("user", user);
            }
            try (PrintWriter out = response.getWriter()) {
                out.println("<!DOCTYPE html>");
                out.println("<html>");
                out.println("<head>");
                out.println("<title>Web clustering demo</title>");
                out.println("</head>");
                out.println("<body>");
                out.println("<h1>Session id " + request.getSession().getId() + "</h1>");
                out.println("<h1>User Created " + user.getCreated() + "</h1>");
                out.println("<h1>Host Name " + System.getenv("HOSTNAME") + "</h1>");
                out.println("</body>");
                out.println("</html>");
            }
        }
    }

    MyServlet.java 의 콘텐츠는 클라이언트가 HTTP 요청을 보내는 끝점을 정의합니다.

  5. 다음 콘텐츠를 사용하여 Java 파일 User.java 를 생성하고 파일을 APPLICATION_ROOT/src/main/java/com/example/webclustering/ 디렉터리에 저장합니다.

    package com.example.webclustering;
    
    import java.io.Serializable;
    
    public class User implements Serializable {
        private final long created;
    
        User(long created) {
            this.created = created;
        }
        public long getCreated() {
            return created;
        }
    }
  6. 애플리케이션을 패키징합니다.

    $ mvn package
  7. 선택 사항: JBoss EAP 베어 메탈 플랫폼에서 애플리케이션을 실행하려면 JBoss EAP 베어 메탈 플랫폼에서 부팅 가능한 JAR 사용에 설명된 단계를 따르십시오. 그러나 다음과 같은 차이점이 있습니다.

    1. JBoss EAP 베어 메탈 플랫폼에서는 다음 예와 같이 java -jar 명령을 사용하여 여러 부팅 가능한 JAR 인스턴스를 실행할 수 있습니다.

      $ java -jar target/web-clustering-bootable.jar -Djboss.node.name=node1
      
      $ java -jar target/web-clustering-bootable.jar -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=10
    2. 확인: 노드 1 인스턴스에서 애플리케이션에 액세스할 수 있습니다. http://127.0.0.1:8080/clustering. 사용자 세션 ID와 사용자 생성 시간을 확인합니다.

      이 인스턴스를 종료한 후 노드 2 인스턴스에 액세스할 수 있습니다. http://127.0.0.1:8090/clustering. 사용자는 노드 1 인스턴스의 세션 ID 및 사용자 생성 시간과 일치해야 합니다.

  8. 선택 사항: JBoss EAP OpenShift 플랫폼에서 애플리케이션을 실행하려면 JBoss EAP OpenShift 플랫폼에서 부팅 가능한 JAR 사용에 설명된 단계를 수행하되 다음 단계를 완료합니다.

    1. &lt ;cloud/& gt; 요소를 플러그인 구성에 추가합니다. 예를 들면 다음과 같습니다.

      <plugins>
         <plugin>
             ... <!-- You must evolve the existing configuration with the <cloud/> element  -->
             <configuration >
                 ...
                 <cloud/>
              </configuration>
          </plugin>
      </plugins>
    2. 애플리케이션을 다시 빌드합니다.

      $ mvn clean package
    3. oc login 명령을 사용하여 OpenShift 인스턴스에 로그인합니다.
    4. OpenShift에서 새 프로젝트를 생성합니다. 예를 들면 다음과 같습니다.

      $ oc new-project bootable-jar-project
    5. JBoss EAP OpenShift 플랫폼에서 웹 클러스터 애플리케이션을 실행하려면 포드가 실행 중인 서비스 계정에 대한 권한 부여 액세스 권한을 부여해야 합니다. 그러면 서비스 계정이 Kubernetes REST API에 액세스할 수 있습니다. 다음 예제에서는 서비스 계정에 권한 부여 권한을 보여줍니다.

      $ oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default
    6. 다음 oc 명령을 입력하여 애플리케이션 이미지를 생성합니다.

      $ mkdir target/openshift && cp target/web-clustering-bootable.jar target/openshift 1
      
      $ oc import-image ubi8/openjdk-11 --from=registry.redhat.io/ubi8/openjdk-11 --confirm 2
      
      $ oc new-build --strategy source --binary --image-stream openjdk-11 --name web-clustering 3
      
      $ oc start-build web-clustering --from-dir target/openshift 4
      1
      target/openshift 하위 디렉터리를 생성합니다. 패키지된 애플리케이션은 openshift 하위 디렉터리에 복사됩니다.
      2
      최신 OpenJDK 11 이미지 스트림 태그 및 이미지 정보를 OpenShift 프로젝트로 가져옵니다.
      3
      web-clustering 디렉터리 및 OpenJDK 11 이미지 스트림을 기반으로 빌드 구성을 생성합니다.
      4
      target/openshift 하위 디렉터리를 바이너리 입력으로 사용하여 애플리케이션을 빌드합니다.
    7. 애플리케이션을 배포합니다.

      $ oc new-app web-clustering -e KUBERNETES_NAMESPACE=$(oc project -q)
      
      $ oc expose svc/web-clustering
      중요

      KUBERNETES_NAMESPACE 환경 변수를 사용하여 현재 OpenShift 네임 스페이스의 다른 pod를 확인해야 합니다. 그러지 않으면 서버가 default 네임스페이스에서 포드를 검색하려고 합니다.

    8. 경로의 URL을 가져옵니다.

      $ oc get route web-clustering --template='{{ .spec.host }}'
    9. 이전 명령에서 반환된 URL을 사용하여 웹 브라우저의 애플리케이션에 액세스합니다. 예를 들면 다음과 같습니다.

      http://ROUTE_NAME/clustering

      사용자 세션 ID 및 사용자 생성 시간을 확인합니다.

    10. 애플리케이션을 두 개의 Pod로 확장합니다.

      $ oc scale --replicas=2 deployments web-clustering
    11. 다음 명령을 실행하여 사용 가능한 OpenShift Pod 목록을 보고 포드 빌드 상태를 확인합니다.

      $ oc get pods
    12. oc delete pod web-clustering-POD_NAME 명령을 사용하여 가장 오래된 Pod를 종료합니다. 여기서 POD_NAME 은 가장 오래된 Pod의 이름입니다.
    13. 애플리케이션에 다시 액세스합니다.

      http://ROUTE_NAME/clustering

      예상 결과: 새 Pod에서 생성한 세션 ID와 종료된 Pod의 생성 시간과 일치합니다. 이는 웹 세션 데이터 스토리지가 활성화되었음을 나타냅니다.

추가 리소스

8.15. CLI 스크립트를 사용하여 부팅 가능한 JAR에 대한 HTTP 인증 활성화

CLI 스크립트를 사용하여 부팅 가능한 JAR에 대한 HTTP 인증을 활성화할 수 있습니다. 이 스크립트는 서버에 보안 영역과 보안 도메인을 추가합니다.

사전 요구 사항

  • MAVEN_PLUGIN_VERSION. X.GA.Final-redhat-00001 과 같은 최신 Maven 플러그인 버전을 확인했습니다. 여기서 MAVEN_PLUGIN_VERSION 은 주요 버전입니다. /ga/org/wildfly/plugins/wildfly-jar-maven-plugin 의 인덱스 를 참조하십시오.
  • 4.0.X.GA-redhat-BUILD_NUMBER 와 같은 최신 Galleon 기능 팩 버전을 확인했습니다. 여기서 X 는 JBoss EAP XP의 마이크로 버전이며 BUILD_NUMBER 는 Galleon 기능 팩의 빌드 번호입니다. JBoss EAP XP 4.0.0 제품 라이프 사이클 기간 동안 XBUILD_NUMBER 가 진화할 수 있습니다. /ga/org/jboss/eap/wildfly-galleon-pack 인덱스 를 참조하십시오.
  • Maven 프로젝트를 생성하고, 상위 종속성을 설정하고, HTTP 인증이 필요한 애플리케이션을 생성하기 위한 종속 항목을 추가했습니다. 부팅 가능한 JAR Maven 프로젝트 생성 을 참조하십시오.

    중요

    Maven 프로젝트를 설정할 때 Maven archetype 구성에 HTTP 인증 값을 지정해야 합니다. 예를 들면 다음과 같습니다.

    $ mvn archetype:generate \
    -DgroupId=com.example.auth \
    -DartifactId=authentication \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false
    cd authentication
    참고

    절차에 표시된 예제에서는 다음 속성을 지정합니다.

    • ${bootable.jar.maven.plugin.version} 은(는) Maven 플러그인 버전에 해당합니다.
    • Galleon 기능 팩 버전의 ${JBoss.xp.galleon.feature.pack.version}

    프로젝트에 이러한 속성을 설정해야 합니다. 예를 들면 다음과 같습니다.

    <properties>
        <bootable.jar.maven.plugin.version>6.1.2.Final-redhat-00001</bootable.jar.maven.plugin.version>
        <jboss.xp.galleon.feature.pack.version>4.0.0.GA-redhat-00002</jboss.xp.galleon.feature.pack.version>
    </properties>

프로세스

  1. pom.xml 파일의 & lt;build > 요소에 다음 내용을 추가합니다. 모든 Maven 플러그인의 최신 버전과 org.jboss.eap:wildfly-galleon-pack Galleon 기능 팩을 지정해야 합니다. 예를 들면 다음과 같습니다.

    <plugins>
        <plugin>
             <groupId>org.wildfly.plugins</groupId>
             <artifactId>wildfly-jar-maven-plugin</artifactId>
             <version>${bootable.jar.maven.plugin.version}</version>
             <configuration>
                 <feature-pack-location>org.jboss.eap:wildfly-galleon-pack:${jboss.xp.galleon.feature.pack.version}</feature-pack-location>
                 <layers>
                       <layer>datasources-web-server</layer>
                 </layers>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>package</goal>
                     </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

    이 예제에서는 elytron 하위 시스템을 포함하는 datasources-web-server Galleon 계층을 포함하는 방법을 보여줍니다.

  2. src/main/webapp/WEB-INF 디렉터리에서 web.xml 파일을 업데이트합니다. 예를 들면 다음과 같습니다.

    <?xml version="1.0" encoding="UTF-8"?>
    
    <web-app version="4.0"
             xmlns="http://xmlns.jcp.org/xml/ns/javaee"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee  http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd">
    
        <login-config>
            <auth-method>BASIC</auth-method>
            <realm-name>Example Realm</realm-name>
        </login-config>
    
    </web-app>
  3. Java 파일을 저장할 디렉터리를 만듭니다.

    $ mkdir -p APPLICATION_ROOT/src/main/java/com/example/authentication/

    여기서 APPLICATION_ROOT 는 Maven 프로젝트의 루트 디렉터리입니다.

  4. 다음 내용으로 Java 파일 TestServlet.java 를 만들고 파일을 APPLICATION_ROOT/src/main/java/com/example/authentication/ 디렉터리에 저장합니다.

    package com.example.authentication;
    
    import javax.servlet.annotation.HttpMethodConstraint;
    import javax.servlet.annotation.ServletSecurity;
    import javax.servlet.annotation.WebServlet;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    
    import java.io.IOException;
    import java.io.PrintWriter;
    
    @WebServlet(urlPatterns = "/hello")
    @ServletSecurity(httpMethodConstraints = { @HttpMethodConstraint(value = "GET", rolesAllowed = { "Users" }) })
    public class TestServlet extends HttpServlet {
    
        @Override
        protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
            PrintWriter writer = resp.getWriter();
            writer.println("Hello " + req.getUserPrincipal().getName());
            writer.close();
        }
    
    }
  5. authentication.cli 와 같은 CLI 스크립트를 생성하고 APPLICATION_ROOT/scripts 디렉터리와 같은 부팅 가능한 JAR의 액세스 가능한 디렉터리에 저장합니다. 이 스크립트는 다음 명령을 포함해야 합니다.

    /subsystem=elytron/properties-realm=bootable-realm:add(users-properties={relative-to=jboss.server.config.dir, path=bootable-users.properties, plain-text=true}, groups-properties={relative-to=jboss.server.config.dir, path=bootable-groups.properties})
    /subsystem=elytron/security-domain=BootableDomain:add(default-realm=bootable-realm, permission-mapper=default-permission-mapper, realms=[{realm=bootable-realm, role-decoder=groups-to-roles}])
    
    /subsystem=undertow/application-security-domain=other:write-attribute(name=security-domain, value=BootableDomain)
  6. 플러그인 <configuration> 요소에 다음 구성 추출을 추가합니다.

    <cli-sessions>
        <cli-session>
            <script-files>
                <script>scripts/authentication.cli</script>
            </script-files>
        </cli-session>
    </cli-sessions>

    이 예에서는 기본 undertow 보안 도메인을 서버에 정의된 보안 도메인으로 구성하는 authentication.cli CLI 스크립트를 보여줍니다.

    참고

    패키징 시간 대신 런타임 시 CLI 스크립트를 실행하는 옵션이 있습니다. 이렇게 하려면 이 단계를 건너뛰고 10 단계로 진행합니다.

  7. Maven 프로젝트의 루트 디렉터리에는 JBoss EAP JAR Maven 플러그인이 부팅 가능한 JAR에 추가하는 속성 파일을 저장할 디렉터리를 생성합니다.

    $ mkdir -p APPLICATION_ROOT/extra-content/standalone/configuration/

    여기서 APPLICATION_ROOT 는 애플리케이션의 pom.xml 구성 파일이 포함된 디렉터리입니다.

    이 디렉터리는 bootable-users.propertiesbootable-groups.properties 파일과 같은 파일을 저장합니다.

    bootable-users.properties 파일에는 다음 내용이 포함되어 있습니다.

    testuser=bootable_password

    bootable-groups.properties 파일에는 다음 내용이 포함되어 있습니다.

    testuser=Users
  8. 기존 < configuration> 요소에 다음 extra-content-content-dirs 요소를 추가합니다.

    <extra-server-content-dirs>
                <extra-content>extra-content</extra-content>
    </extra-server-content-dirs>

    extra-content 디렉터리에는 속성 파일이 포함되어 있습니다.

  9. 애플리케이션을 부팅 가능한 JAR로 패키징합니다.

    $ mvn package
  10. 애플리케이션을 시작합니다.

    mvn wildfly-jar:run

    6단계를 건너뛰고 빌드 중에 CLI 스크립트를 실행하지 않도록 선택한 경우 다음 명령을 사용하여 애플리케이션을 시작합니다.

    mvn wildfly-jar:run -Dwildfly.bootable.arguments=--cli-script=scripts/authentication.cli
  11. 서블릿을 호출하지만 인증 정보를 지정하지 마십시오.

    curl -v http://localhost:8080/hello

    예상 출력:

    HTTP/1.1 401 Unauthorized
    ...
    WWW-Authenticate: Basic realm="Example Realm"
  12. 서버를 호출하고 인증 정보를 지정합니다. 예를 들면 다음과 같습니다.

    $ curl -v -u testuser:bootable_password http://localhost:8080/hello

    부팅 가능한 JAR에 HTTP 인증이 활성화되었음을 나타내는 HTTP 200 상태가 반환됩니다. 예를 들면 다음과 같습니다.

    HTTP/1.1 200 OK
    ....
    Hello testuser

추가 리소스

8.16. Red Hat Single Sign-On을 사용하여 JBoss EAP 부팅 가능한 JAR 애플리케이션 보안

Galleon keycloak-client-oidc 계층을 사용하여 Red Hat Single Sign-On 7.5 OpenID Connect 클라이언트 어댑터로 프로비저닝된 서버 버전을 설치할 수 있습니다.

참고

JBoss EAP XP 4에서는 keycloak-client-oidc 계층 사용이 더 이상 사용되지 않습니다. 대신 기본 OpenID Connect(OIDC) 클라이언트를 제공하는 elytron-oidc-client 계층을 사용합니다. 자세한 내용은 OpenID Connect를 사용하여 JBoss EAP 부팅 가능한 JAR 애플리케이션 개발을 참조하십시오.

keycloak-client-oidc 계층은 Red Hat Single Sign-On OpenID Connect 클라이언트 어댑터를 Maven 프로젝트에 제공합니다. 이 계층은 keycloak-adapter-galleon-pack Red Hat Single Sign-On 기능 팩에 포함되어 있습니다.

keycloak-adapter-galleon-pack 기능 팩을 JBoss EAP Maven 플러그인 구성에 추가한 다음 keycloak-client-oidc 를 추가할 수 있습니다. 지원되는 구성: Red Hat Single Sign-On 7.4 웹 페이지를 방문하여 JBoss EAP와 호환되는 Red Hat Single Sign-On 클라이언트 어댑터를 볼 수 있습니다.

이 절차의 예제에서는 keycloak-client-oidc 계층에서 제공하는 JBoss EAP 기능을 사용하여 JBoss EAP 부팅 가능한 JAR을 보호하는 방법을 보여줍니다.

사전 요구 사항

  • MAVEN_PLUGIN_VERSION. X.GA.Final-redhat-00001 과 같은 최신 Maven 플러그인 버전을 확인했습니다. 여기서 MAVEN_PLUGIN_VERSION 은 주요 버전입니다. /ga/org/wildfly/plugins/wildfly-jar-maven-plugin 의 인덱스 를 참조하십시오.
  • 4.0.X.GA-redhat-BUILD_NUMBER 와 같은 최신 Galleon 기능 팩 버전을 확인했습니다. 여기서 X 는 JBoss EAP XP의 마이크로 버전이며 BUILD_NUMBER 는 Galleon 기능 팩의 빌드 번호입니다. JBoss EAP XP 4.0.0 제품 라이프 사이클 기간 동안 XBUILD_NUMBER 가 진화할 수 있습니다. /ga/org/jboss/eap/wildfly-galleon-pack 인덱스 를 참조하십시오.
  • 최신 Red Hat Single Sign-On Galleon 기능 팩 버전(예: org.keycloak:keycloak-adapter-galleon-pack:15.0.X.redhat-BUILD_NUMBER )을 확인했습니다. 여기서 X 는 Red Hat Single Sign-On 서버 릴리스에 따라 보안 애플리케이션에 사용되는 Red Hat Single Sign-On 서버 릴리스의 마이크로 버전입니다. BUILD_NUMBER 는 Red Hat Single Sign-On Galleon 기능 팩의 빌드 번호입니다. JBoss EAP XP 4.0.0 제품 라이프 사이클 기간 동안 XBUILD_NUMBER 가 진화할 수 있습니다. /ga/org/keycloak/keycloak-adapter-galleon-pack 의 인덱스 를 참조하십시오.
  • Maven 프로젝트를 생성하고, 상위 종속성을 설정하고, Red Hat Single Sign-On으로 보호하려는 애플리케이션을 생성하기 위한 종속 항목을 추가했습니다. 부팅 가능한 JAR Maven 프로젝트 생성 을 참조하십시오.
  • 포트 8090에서 실행 중인 Red Hat Single Sign-On 서버가 있습니다. Red Hat Single Sign-On 서버 시작을 참조하십시오.
  • Red Hat Single Sign-On 관리 콘솔에 로그인하여 다음 메타데이터를 생성했습니다.

    • demo 라는 영역입니다.
    • 사용자라는 역할입니다.
    • 사용자 및 암호. 사용자에게 Users 역할을 할당해야 합니다.
    • 루트 URL이 있는 공용 클라이언트 웹 애플리케이션. 절차의 예제에서는 simple-webapp 을 웹 애플리케이션으로 정의하고 http://localhost:8080/simple-webapp/secured 를 루트 URL로 정의합니다.

      중요

      Maven 프로젝트를 설정할 때 Maven archetype에서 Red Hat Single Sign-On으로 보호하려는 애플리케이션의 값을 지정해야 합니다. 예를 들면 다음과 같습니다.

      $ mvn archetype:generate \
      -DgroupId=com.example.keycloak \
      -DartifactId=simple-webapp \
      -DarchetypeGroupId=org.apache.maven.archetypes \
      -DarchetypeArtifactId=maven-archetype-webapp \
      -DinteractiveMode=false
      cd simple-webapp
      참고

      절차에 표시된 예제에서는 다음 속성을 지정합니다.

      • ${bootable.jar.maven.plugin.version} 은(는) Maven 플러그인 버전에 해당합니다.
      • Galleon 기능 팩 버전의 ${JBoss.xp.galleon.feature.pack.version}
      • ${Keycloak.feature.pack.version} Red Hat Single Sign-On 기능 팩 버전.

      프로젝트에 이러한 속성을 설정해야 합니다. 예를 들면 다음과 같습니다.

      <properties>
          <bootable.jar.maven.plugin.version>6.1.2.Final-redhat-00001</bootable.jar.maven.plugin.version>
          <jboss.xp.galleon.feature.pack.version>4.0.0.GA-redhat-00002</jboss.xp.galleon.feature.pack.version>
          <keycloak.feature.pack.version>15.0.4.redhat-00001</keycloak.feature.pack.version>
      </properties>

프로세스

  1. pom.xml 파일의 & lt;build > 요소에 다음 내용을 추가합니다. 모든 Maven 플러그인의 최신 버전과 org.jboss.eap:wildfly-galleon-pack Galleon 기능 팩을 지정해야 합니다. 예를 들면 다음과 같습니다.

    <plugins>
        <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-jar-maven-plugin</artifactId>
            <version>${bootable.jar.maven.plugin.version}</version>
            <configuration>
                <feature-packs>
                    <feature-pack>
                        <location>org.jboss.eap:wildfly-galleon-pack:${jboss.xp.galleon.feature.pack.version}</location>
                    </feature-pack>
                    <feature-pack>
                        <location>org.keycloak:keycloak-adapter-galleon-pack:${keycloak.feature.pack.version}</location>
                    </feature-pack>
                </feature-packs>
                <layers>
                    <layer>datasources-web-server</layer>
                    <layer>keycloak-client-oidc</layer>
                </layers>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>package</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

    Maven 플러그인은 웹 애플리케이션을 배포하는 데 필요한 하위 시스템 및 모듈을 프로비저닝합니다.

    keycloak-client-oidc 계층은 keycloak 하위 시스템 및 해당 종속 항목을 사용하여 Red Hat Single Sign-On 클라이언트 어댑터를 프로젝트에 제공하여 Red Hat Single Sign-On 인증에 대한 지원을 활성화합니다. Red Hat Single Sign-On 클라이언트 어댑터는 Red Hat Single Sign-On으로 애플리케이션 및 서비스를 보호하는 라이브러리입니다.

  2. 프로젝트 pom.xml 파일에서 플러그인 구성에서 &lt ;context-root >를 false 로 설정합니다. 그러면 애플리케이션이 simple-webapp 리소스 경로에 등록됩니다. 기본적으로 WAR 파일은 root-context 경로에 등록됩니다.

    <configuration>
        ...
         <context-root>false</context-root>
         ...
    </configuration>
  3. configure-oidc.cli 와 같은 CLI 스크립트를 생성하고 APPLICATION_ROOT/scripts 디렉터리와 같은 부팅 가능한 JAR의 액세스 가능한 디렉터리에 저장합니다. 여기서 APPLICATION_ROOT 는 Maven 프로젝트의 루트 디렉터리입니다. 이 스크립트는 다음 예와 유사한 명령을 포함해야 합니다.

    /subsystem=keycloak/secure-deployment=simple-webapp.war:add( \
        realm=demo, \
        resource=simple-webapp, \
        public-client=true, \
        auth-server-url=http://localhost:8090/auth/, \
        ssl-required=EXTERNAL)

    이 스크립트 예제에서는 keycloak 하위 시스템에서 secure-deployment=simple-webapp.war 리소스를 정의합니다. simple-webapp.war 리소스는 부팅 가능한 JAR에 배포된 WAR 파일의 이름입니다.

  4. 프로젝트 pom.xml 파일에서 기존 플러그인 <configuration> 요소에 다음 구성 추출 파일을 추가합니다.

    <cli-sessions>
        <cli-session>
            <script-files>
                <script>scripts/configure-oidc.cli</script>
            </script-files>
        </cli-session>
    </cli-sessions>
  5. src/main/webapp/WEB-INF 디렉터리에서 web.xml 파일을 업데이트합니다. 예를 들면 다음과 같습니다.

    <?xml version="1.0" encoding="UTF-8"?>
    
    <web-app version="4.0" xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_4_0.xsd"
       metadata-complete="false">
    
        <login-config>
            <auth-method>BASIC</auth-method>
            <realm-name>Simple Realm</realm-name>
        </login-config>
    
    </web-app>
  6. 선택 사항: 또는 7단계부터 9단계로는 keycloak.json 설명자를 웹 애플리케이션의 article -INF 디렉터리에 추가하여 웹 애플리케이션에 서버 구성을 포함할 수 있습니다. 예를 들면 다음과 같습니다.

    {
        "realm" : "demo",
        "resource" : "simple-webapp",
        "public-client" : "true",
        "auth-server-url" : "http://localhost:8090/auth/",
        "ssl-required" : "EXTERNAL"
    }

    그런 다음 웹 애플리케이션의 & lt;auth-method >를 KEYCLOAK 로 설정해야 합니다. 다음 예제 코드는 < auth-method> :을 설정하는 방법을 보여줍니다.

        <login-config>
            <auth-method>KEYCLOAK</auth-method>
            <realm-name>Simple Realm</realm-name>
        </login-config>
  7. 다음 콘텐츠를 사용하여 SecuredServlet.java 라는 Java 파일을 생성하고 APPLICATION_ROOT/src/main/java/com/example/securedservlet/ 디렉터리에 저장합니다.

    package com.example.securedservlet;
    
    import java.io.IOException;
    import java.io.PrintWriter;
    import java.security.Principal;
    
    import javax.servlet.ServletException;
    import javax.servlet.annotation.HttpMethodConstraint;
    import javax.servlet.annotation.ServletSecurity;
    import javax.servlet.annotation.WebServlet;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    
    @WebServlet("/secured")
    @ServletSecurity(httpMethodConstraints = { @HttpMethodConstraint(value = "GET",
        rolesAllowed = { "Users" }) })
    public class SecuredServlet extends HttpServlet {
    
        @Override
        protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
            try (PrintWriter writer = resp.getWriter()) {
                writer.println("<html>");
                writer.println("<head><title>Secured Servlet</title></head>");
                writer.println("<body>");
                writer.println("<h1>Secured Servlet</h1>");
                writer.println("<p>");
                writer.print(" Current Principal '");
                Principal user = req.getUserPrincipal();
                writer.print(user != null ? user.getName() : "NO AUTHENTICATED USER");
                writer.print("'");
                writer.println("    </p>");
                writer.println("  </body>");
                writer.println("</html>");
            }
        }
    }
  8. 애플리케이션을 부팅 가능한 JAR로 패키징합니다.

    $ mvn package
  9. 애플리케이션을 시작합니다. 다음 예제는 지정된 부팅 가능한 JAR 경로에서 simple-webapp 웹 애플리케이션을 시작합니다.

    $ java -jar target/simple-webapp-bootable.jar
  10. 웹 브라우저에서 다음 URL을 지정하여 Red Hat Single Sign-On으로 보안된 웹 페이지에 액세스합니다. 다음 예제에서는 보안 simple-webapp 웹 애플리케이션의 URL을 보여줍니다.

    http://localhost:8080/simple-webapp/secured
  11. Red Hat Single Sign-On 영역에서 사용자로 로그인합니다.
  12. 확인: 웹 페이지에 다음 출력이 표시되는지 확인합니다.

    Current Principal '<principal id>'

추가 리소스

8.17. dev 모드에서 부팅 가능한 JAR 패키징

JBoss EAP JAR Maven 플러그인 개발 목표는 애플리케이션 개발 프로세스를 개선하는 데 사용할 수 있는 개발 모드인 개발 모드를 제공합니다.

dev 모드에서는 애플리케이션을 변경한 후에는 부팅 가능한 JAR을 다시 빌드할 필요가 없습니다.

이 절차의 워크플로는 dev 모드를 사용하여 부팅 가능한 JAR을 구성하는 방법을 보여줍니다.

사전 요구 사항

  • Maven이 설치되어 있어야 합니다.
  • Maven 프로젝트를 생성하고, 상위 종속성을 설정하고, MicroProfile 애플리케이션을 생성하기 위한 종속 항목을 추가했습니다. MicroProfile Config Development 를 참조하십시오.
  • Maven 프로젝트 pom.xml 파일에 JBoss EAP JAR Maven 플러그인 을 지정했습니다.

프로세스

  1. 개발 모드에서 부팅 가능한 JAR을 빌드하고 시작합니다.

    $ mvn wildfly-jar:dev

    dev 모드에서 서버 배포 스캐너는 target/deployments 디렉터리를 모니터링하도록 구성됩니다.

  2. 다음 명령을 사용하여 애플리케이션을 빌드하고 target/deployments 디렉터리에 복사하도록 JBoss EAP Maven 플러그인을 입력하라는 메시지를 표시합니다.

    $ mvn package -Ddev

    부팅 가능한 JAR 내에 패키지된 서버는 target/deployments 디렉터리에 저장된 애플리케이션을 배포합니다.

  3. 애플리케이션 코드에서 코드를 수정합니다.
  4. mvn package -Ddev 를 사용하여 JBoss EAP Maven 플러그인을 사용하여 애플리케이션을 다시 빌드하고 다시 배포합니다.
  5. 서버를 중지합니다. 예를 들면 다음과 같습니다.

    $ mvn wildfly-jar:shutdown
  6. 애플리케이션 변경 사항을 완료한 후 애플리케이션을 부팅 가능한 JAR로 패키징합니다.

    $ mvn package

8.18. 서버 아티팩트 업그레이드

JBoss Modules 모듈 내에 있는 서버 아티팩트는 프로젝트 pom.xml 파일의 Maven 조정을 사용하여 참조할 수 있습니다.

참고

서버 아티팩트를 업그레이드하면 지원되지 않는 구성이 발생할 수 있습니다.

사전 요구 사항

  • 로컬 Maven 리포지토리 또는 원격 Maven 리포지토리에서 Maven 아티팩트에 액세스할 수 있는지 확인합니다.

프로세스

  1. 빌드 중에 종속 항목에 있는 아티팩트 버전을 사용하여 서버 아티팩트를 성공적으로 업그레이드합니다. 예를 들면 다음과 같습니다.

    <dependencies>
       …
       <dependency>
    	<groupId>io.undertow</groupId>
    	<artifactId>undertow-core</groupId>
    	 <version>2.2.5.Final-redhat-00001</version>
             <scope>provided</scope>
             <!-- In order to avoid bringing transitive dependencies to the project, exclude all dependencies -->
             <exclusions>
               <exclusion>
                 <groupId>*</groupId>
                 <artifactId>*</artifactId>
               </exclusion>
             </exclusions>
       </dependency>
       ...
    </dependencies>
  2. plugin < configuration > 섹션을 열고 < overridden-server-artifacts > 목록 내에서 아티팩트 groupId 및 artifactId를 업데이트합니다. 예를 들면 다음과 같습니다.

    <configuration>
    	…
    	<overridden-server-artifacts>
    		<artifact>
    			<groupId>io.undertow</groupId>
    			<artifactId>undertow-core</groupId>
    		</artifact>
    	</overridden-server-artifacts>
    </configuration>
참고
  • < overridden-server-artifacts >에 추가된 아티팩트가 프로젝트 종속성에서 발견되지 않으면 오류가 발생합니다.
  • < overridden-server-artifacts>' 에 추가된 아티팩트가 프로비저닝된 서버 아티팩트 사이에 없는 경우 업그레이드 대상 아티팩트를 찾을 수 없기 때문에 오류가 발생합니다.

8.19. EAP 7.4.GA 종속성 업데이트

JBoss EAP XP 4.0.0의 부팅 가능한 JAR을 빌드할 때 JBoss EAP XP 4.0.0의 종속성을 JBoss EAP 7.4에서 업데이트할 수 있습니다. JBoss EAP XP 4.0.0 galleon 기능 팩 org.jboss.eap:wildfly-galleon-pack:4.0.0.GA-redhat-00001 에는 org.jboss.eap:wildfly-ee-galleon-pack:7.4.0.GA-redhat-00001 에 대한 종속성이 있습니다.

참고

최신 JBoss EAP XP 버전으로 업그레이드. 이렇게 하면 JBoss EAP XP 4.0.0 부팅 가능한 JAR의 최신 업데이트가 제공됩니다.

사전 요구 사항

  • 최신 버전의 JBoss EAP XP가 있습니다.

프로세스

  1. JBoss EAP Galleon 기능 팩 Maven 아티팩트가 로컬 또는 원격 Maven 리포지토리에서 액세스할 수 있는지 확인합니다.
  2. 프로젝트 종속 항목에 Galleon 기능 팩 아티팩트를 추가합니다.

    1. 제공된 대로 범위를 설정합니다.
    2. 유형을 zip 으로 설정합니다.
    3. 아티팩트 버전을 설정합니다. 예를 들면 다음과 같습니다.

      <dependencies>
         …
         <dependency>
      	<groupId>org.jboss.eap</groupId>
      	<artifactId>wildfly-ee-galleon-pack</groupId>
      	 <version>7.4.1.GA-redhat-00001</version>
      <scope>provided</scope>
      <type>zip</type>
         </dependency>
         ...
      </dependencies>
  3. plugin < configuration > 섹션을 열고 < overridden-server-artifacts > 목록 내에서 아티팩트 groupId 및 artifactId를 업데이트합니다. 예를 들면 다음과 같습니다.

    <configuration>
    	…
    	<overridden-server-artifacts>
    		<artifact>
    			<groupId>org.jboss.eap</groupId>
    			<artifactId>wildfly-ee-galleon-pack</groupId>
    		</artifact>
    	</overridden-server-artifacts>
    </configuration>
  4. 빌드 중에 JBoss EAP XP Galleon 기능 팩의 최신 버전을 사용하여 종속성을 성공적으로 수행합니다.

8.20. 부팅 가능한 JAR에 JBoss EAP 패치 적용

참고

JBoss EAP XP 4.0.0.0에서는 부팅 가능한 기존 패치 기능이 더 이상 사용되지 않습니다.

JBoss EAP 베어 메탈 플랫폼에서 CLI 스크립트를 사용하여 부팅 가능한 JAR에 패치를 설치할 수 있습니다.

CLI 스크립트는 부팅 가능한 JAR 빌드 중에 패치를 적용하기 위해 patch apply 명령을 실행합니다.

중요

부팅 가능한 JAR에 패치를 적용한 후에는 적용된 패치에서 롤백할 수 없습니다. 패치 없이 부팅 가능한 JAR을 다시 빌드해야 합니다.

또한 JBoss EAP JAR Maven 플러그인을 사용하여 부팅 가능한 JAR에 레거시 패치를 적용할 수 있습니다. 이 플러그인은 서버를 패치하는 데 사용되는 CLI 스크립트를 참조하는 <legacy-patch-cli- script> 구성 옵션을 제공합니다.

참고

<legacy-patch- cli-script>의 접두사 legacy -* 는 부팅 가능한 JAR에 아카이브 패치를 적용하는 것과 관련이 있습니다. 이 방법은 일반 JBoss EAP 배포에 패치를 적용하는 것과 유사합니다.

JBoss EAP JAR Maven 플러그인 구성에서 legacy-patch-cleanup 옵션을 사용하여 사용되지 않는 패치 콘텐츠를 제거하여 부팅 가능한 JAR의 메모리 공간을 줄일 수 있습니다. 옵션은 사용되지 않는 모듈 종속성을 제거합니다. 이 옵션은 패치 구성 파일에서 기본적으로 false 로 설정됩니다.

legacy-patch-cleanup 옵션은 다음 패치 콘텐츠를 제거합니다.

  • &lt ;JBOSS_HOME>/.installation/patches 디렉터리입니다.
  • 기본 계층에 있는 패치 모듈의 원래 위치입니다.
  • 패치에 의해 추가되었으며 해당 기존 모듈 그래프 또는 패치된 모듈 그래프에서 참조되지 않는 사용되지 않은 모듈입니다.
  • .overlays 파일에 나열되지 않은 오버레이 디렉터리입니다.
중요

legacy-patch-clean-up 옵션 변수는 기술 프리뷰로 제공됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

참고

이 절차에 설명된 정보는 빈 부팅 가능한 JAR에도 적용됩니다.

사전 요구 사항

  • Red Hat 고객 포털에서 계정을 설정했습니다.
  • 제품 다운로드 페이지에서 다음 파일을 다운로드 했습니다.

    • JBoss EAP 7.4.4 GA 패치
    • JBoss EAP XP 4.0.0 패치

프로세스

  1. 부팅 가능한 JAR에 적용할 레거시 패치를 정의하는 CLI 스크립트를 생성합니다. 스크립트에는 하나 이상의 patch apply 명령이 포함되어야 합니다. 예를 들어 Galleon 레이어로 트리밍된 서버를 패치할 때 --override-all 명령이 필요합니다.

    patch apply patch-oneoff1.zip --override-all
    
    patch apply patch-oneoff2.zip --override-all
    
    patch info --json-output
  2. pom.xml 파일의 < legacy-patch-cli-script > 요소에서 CLI 스크립트를 참조합니다.
  3. 부팅 가능한 JAR을 다시 빌드합니다.

추가 리소스

9장. JBoss EAP의 OpenID Connect

JBoss EAP 기본 OpenID Connect(OIDC) 클라이언트를 사용하여 외부 OpenID 공급자를 통해 애플리케이션을 보호합니다. OIDC는 JBoss EAP와 같은 클라이언트가 OpenID 공급자 인증을 기반으로 사용자 ID를 확인할 수 있는 ID 계층입니다. 예를 들어 Red Hat Single Sign-On을 OpenID 공급자로 사용하여 JBoss EAP 애플리케이션을 보호할 수 있습니다.

9.1. JBoss EAP의 OpenID Connect 구성

OpenID 공급자를 사용하여 애플리케이션을 보호하면 보안 도메인 리소스를 로컬로 구성할 필요가 없습니다. elytron-oidc-client 하위 시스템은 JBoss EAP에서 기본 OpenID Connect(OIDC) 클라이언트를 제공하여 OpenID 공급자와 연결합니다. JBoss EAP는 OpenID 공급자 구성에 따라 애플리케이션의 가상 보안 도메인을 자동으로 생성합니다.

중요

Red Hat Single Sign-On과 함께 OIDC 클라이언트를 사용하는 것이 좋습니다. JSON 웹 토큰(JWT)인 액세스 토큰을 사용하도록 구성할 수 있고 RS256, RS384, ES256, ES384 또는 ES512 서명 알고리즘을 사용하도록 구성할 수 있는 경우 다른 OpenID 공급자를 사용할 수 있습니다.

OIDC 사용을 활성화하려면 elytron-oidc-client 하위 시스템 또는 애플리케이션 자체를 구성할 수 있습니다. JBoss EAP는 다음과 같이 OIDC 인증을 활성화합니다.

  • 애플리케이션을 JBoss EAP에 배포할 때 elytron-oidc-client 하위 시스템은 배포를 검사하여 OIDC 인증 메커니즘이 필요한지 감지합니다.
  • 하위 시스템에서 elytron-oidc-client 하위 시스템 또는 애플리케이션 배포 설명자 중 하나에서 배포에 대한 OIDC 구성을 감지하면 JBoss EAP는 애플리케이션에 대한 OIDC 인증 메커니즘을 활성화합니다.
  • 하위 시스템이 두 위치에서 OIDC 구성을 감지하면 elytron-oidc-client 하위 시스템 secure-deployment 속성의 구성이 애플리케이션 배포 설명자의 구성보다 우선합니다.
참고

Red Hat Single Sign-On을 사용하여 애플리케이션을 보호하기 위한 keycloak-client-oidc 계층은 JBoss EAP XP 4.0.0에서 더 이상 사용되지 않습니다. 대신 elytron-oidc-client 하위 시스템에서 제공하는 네이티브 OIDC 클라이언트를 사용합니다.

배포 구성

배포 설명자를 사용하여 OIDC로 애플리케이션을 보호하려면 다음과 같이 애플리케이션의 배포 구성을 업데이트합니다.

  • OIDC 구성 정보를 사용하여 websites -INF 디렉터리에 oidc.json 이라는 파일을 생성합니다.

    oidc.json 내용의 예

    {
      "client-id" : "customer-portal", 1
      "provider-url" : "http://localhost:8180/auth/realms/demo", 2
      "ssl-required" : "external", 3
       "credentials" : {
          "secret" : "234234-234234-234234" 4
       }
    }

    1
    OpenID 공급자를 사용하여 OIDC 클라이언트를 식별하는 이름입니다.
    2
    OpenID 공급자 URL입니다.
    3
    외부 요청에 HTTPS가 필요합니다.
    4
    OpenID 공급자에 등록된 클라이언트 시크릿입니다.
  • 애플리케이션 배포 설명자 web.xml 파일에서 auth-method 속성을 OIDC 로 설정합니다.

배포 설명자 업데이트 예

<login-config>
    <auth-method>OIDC</auth-method>
</login-config>

하위 시스템 구성

다음과 같은 방법으로 elytron-oidc-client 하위 시스템을 구성하여 OIDC로 애플리케이션을 보호할 수 있습니다.

  • 각 애플리케이션에 동일한 OpenID 공급자를 사용하는 경우 여러 배포에 대한 단일 구성을 생성합니다.
  • 다른 애플리케이션에 다른 OpenID 공급자를 사용하는 경우 각 배포에 대해 다른 구성을 생성합니다.

단일 배포에 대한 XML 구성의 예:

<subsystem xmlns="urn:wildfly:elytron-oidc-client:1.0">
    <secure-deployment name="DEPLOYMENT_RUNTIME_NAME.war"> 1
        <client-id>customer-portal</client-id> 2
        <provider-url>http://localhost:8180/auth/realms/demo</provider-url> 3
        <ssl-required>external</ssl-required> 4
        <credential name="secret" secret="0aa31d98-e0aa-404c-b6e0-e771dba1e798" /> 5
    </secure-deployment
</subsystem>
1
배포 런타임 이름입니다.
2
OpenID 공급자를 사용하여 OIDC 클라이언트를 식별하는 이름입니다.
3
OpenID 공급자 URL입니다.
4
외부 요청에 HTTPS가 필요합니다.
5
OpenID 공급자에 등록된 클라이언트 시크릿입니다.

동일한 OpenID 공급자를 사용하여 여러 애플리케이션을 보호하려면 예와 같이 공급자 를 별도로 구성합니다.

<subsystem xmlns="urn:wildfly:elytron-oidc-client:1.0">
    <provider name="${OpenID_provider_name}">
        <provider-url>http://localhost:8080/auth/realms/demo</provider-url>
        <ssl-required>external</ssl-required>
    </provider>
    <secure-deployment name="customer-portal.war"> 1
        <provider>${OpenID_provider_name}</provider>
        <client-id>customer-portal</client-id>
        <credential name="secret" secret="0aa31d98-e0aa-404c-b6e0-e771dba1e798" />
    </secure-deployment>
    <secure-deployment name="product-portal.war"> 2
        <provider>${OpenID_provider_name}</provider>
        <client-id>product-portal</client-id>
        <credential name="secret" secret="0aa31d98-e0aa-404c-b6e0-e771dba1e798" />
    </secure-deployment>
</subsystem>
1
배포: customer-portal.war
2
다른 배포: product-portal.war

9.2. elytron-oidc-client 하위 시스템 활성화

elytron-oidc-client 하위 시스템은 standalone-microprofile.xml 구성 파일에 제공됩니다. 사용하려면 bin/standalone.sh -c standalone-microprofile.xml 명령을 사용하여 서버를 시작해야 합니다. 관리 CLI를 사용하여 활성화하여 standalone.xml 구성에 elytron-oidc-client 하위 시스템을 포함할 수 있습니다.

사전 요구 사항

  • JBoss EAP XP를 설치했습니다.

프로세스

  1. 관리 CLI를 사용하여 elytron-oidc-client 확장을 추가합니다.

    /extension=org.wildfly.extension.elytron-oidc-client:add
  2. 관리 CLI를 사용하여 elytron-oidc-client 하위 시스템을 활성화합니다.

    /subsystem=elytron-oidc-client:add
  3. JBoss EAP 다시 로드.

    reload

이제 서버를 정상적으로 시작하여 bin/standalone.sh명령으로 elytron-oidc-client 하위 시스템을 사용할 수 있습니다.

9.3. Red Hat Single Sign-On과 OpenID Connect를 사용하여 애플리케이션 보안

OpenID Connect(OIDC)를 사용하여 인증을 외부 OpenID 공급자에 위임할 수 있습니다. elytron-oidc-client 하위 시스템은 JBoss EAP에서 외부 OpenID 공급자와 연결할 기본 OIDC 클라이언트를 제공합니다.

Red Hat Single Sign-On을 사용하여 OpenID Connect로 보안된 애플리케이션을 생성하려면 다음 절차를 따르십시오.

9.3.1. Red Hat Single Sign-On을 OpenID 공급자로 구성

Red Hat Single Sign-On은 SSO(Single Sign-On)로 웹 애플리케이션을 보호하기 위한 ID 및 액세스 관리 공급자입니다. OpenID Connect ( OAuth 2.0에 대한 확장)를 지원합니다.

사전 요구 사항

프로세스

  1. JBoss EAP 기본 포트가 8080이므로 8080 이외의 포트에서 Red Hat Single Sign-On 서버를 시작합니다.

    구문

    $ RH_SSO_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=<offset-number>

    예제

    $ /home/servers/rh-sso-7.4/bin/standalone.sh -Djboss.socket.binding.port-offset=100

  2. http://localhost:<port>/auth/ 에서 관리 콘솔에 로그인합니다. 예: http://localhost:8180/auth/.
  3. 관리 콘솔에서 마스터 위에 마우스를 가져가려면 영역 추가 를 클릭합니다.
  4. 영역의 이름을 입력합니다. 예를 들면 example_realm 입니다. EnabledON 인지 확인하고 생성 을 클릭합니다.
  5. Users 를 클릭한 다음 Add user (사용자 추가)를 클릭하여 사용자를 영역에 추가합니다.
  6. 사용자 이름을 입력합니다. 예: jane_doe. User EnabledON 인지 확인하고 Save 를 클릭합니다.
  7. 인증 정보를 클릭하여 사용자에게 암호를 추가합니다.
  8. 사용자의 암호를 설정합니다. 예: janedoep@$. 임시OFF 로 전환하고 암호 설정을 클릭합니다. 확인 프롬프트에서 암호 설정을 클릭합니다.
  9. 클라이언트 를 클릭한 다음 생성 을 클릭하여 클라이언트 연결을 구성합니다.
  10. 클라이언트 ID를 입력합니다. 예를 들면 my_jbeap 입니다. 클라이언트 프로토콜이 openid-connect 로 설정되어 있는지 확인하고 저장을 클릭합니다.
  11. 설치 를 클릭한 다음 Keycloak OIDC JSON형식 옵션으로 선택하여 연결 매개 변수를 확인합니다.

    {
      "realm": "example_realm",
      "auth-server-url": "http://localhost:8180/auth/",
      "ssl-required": "external",
      "resource": "my_jbeap",
      "public-client": true,
      "confidential-port": 0
    }

    Red Hat Single Sign-On을 ID 공급자로 사용하도록 JBoss EAP 애플리케이션을 구성할 때 다음과 같이 매개변수를 사용합니다.

    "provider-url" : "http://localhost:8180/auth/realms/example_realm",
    "ssl-required": "external",
    "client-id": "my_jbeap",
    "public-client": true,
    "confidential-port": 0
  12. 클라이언트 를 클릭하고 my_jbeap 옆에 있는 편집 을 클릭하여 클라이언트 설정을 편집합니다.
  13. 유효한 리디렉션 URI 에서 인증이 성공한 후 페이지를 리디렉션해야 하는 URL을 입력합니다.

    이 예에서는 이 값을 http://localhost:8080/simple-oidc-example/secured/*로 설정합니다.

9.3.2. 보안 애플리케이션을 생성하기 위한 Maven 프로젝트 구성

필요한 종속성과 보안 애플리케이션을 생성하기 위한 디렉터리 구조를 사용하여 Maven 프로젝트를 생성합니다.

사전 요구 사항

프로세스

  1. mvn 명령을 사용하여 Maven 프로젝트를 설정합니다. 명령은 프로젝트에 대한 디렉터리 구조와 pom.xml 구성 파일을 생성합니다.

    구문

    $ mvn archetype:generate \
    -DgroupId=${group-to-which-your-application-belongs} \
    -DartifactId=${name-of-your-application} \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false

    예제

    $ mvn archetype:generate \
    -DgroupId=com.example.oidc \
    -DartifactId=simple-oidc-example \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false

  2. 애플리케이션 루트 디렉터리로 이동합니다.

    구문

    $ cd <name-of-your-application>

    예제

    $ cd simple-oidc-example

  3. 생성된 pom.xml 파일을 다음과 같이 업데이트합니다.

    1. 다음 속성을 설정합니다.

      <properties>
          <maven.compiler.source>1.8</maven.compiler.source>
          <maven.compiler.target>1.8</maven.compiler.target>
          <failOnMissingWebXml>false</failOnMissingWebXml>
          <version.server.bom>4.0.0.GA</version.server.bom>
          <version.server.bootable-jar>4.0.0.GA</version.server.bootable-jar>
          <version.wildfly-jar.maven.plugin>4.0.0.GA</version.wildfly-jar.maven.plugin>
      </properties>
    2. 다음 종속 항목을 설정합니다.

      <dependencies>
          <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.1.0.redhat-1</version>
            <scope>provided</scope>
          </dependency>
      </dependencies>
    3. mvn widlfy:deploy 를 사용하여 애플리케이션을 배포하도록 다음 빌드 구성을 설정합니다.

      <build>
          <finalName>${project.artifactId}</finalName>
          <plugins>
              <plugin>
                  <groupId>org.wildfly.plugins</groupId>
                  <artifactId>wildfly-maven-plugin</artifactId>
                  <version>2.1.0.Final</version>
              </plugin>
          </plugins>
      </build>

검증

  • 애플리케이션 루트 디렉터리에 다음 명령을 입력합니다.

    $ mvn install

    다음과 유사한 출력이 표시됩니다.

    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 1.440 s
    [INFO] Finished at: 2021-12-27T14:45:12+05:30
    [INFO] ------------------------------------------------------------------------

이제 보안 애플리케이션을 생성할 수 있습니다.

9.3.3. OpenID Connect를 사용하는 보안 애플리케이션 생성

배포 구성을 업데이트하거나 elytron-oidc-client 하위 시스템을 구성하여 애플리케이션을 보호할 수 있습니다. 다음 예제에서는 로그인한 사용자의 보안 주체를 출력하는 서블릿을 생성하는 방법을 보여줍니다. 기존 애플리케이션의 경우 배포 구성 또는 elytron-oidc-client 하위 시스템 업데이트와 관련된 단계만 필요합니다.

이 예에서 Principal 값은 OpenID 공급자의 ID 토큰에서 가져옵니다. 기본적으로 보안 주체는 토큰의 "sub" 클레임 값입니다. 다음 중 하나에서 Principal로 사용할 ID 토큰의 클레임 값을 지정할 수 있습니다.

  • elytron-oidc-client 하위 시스템 특성 principal-attribute.
  • oidc.json 파일

절차의 < application_root >는 pom.xml 파일 디렉터리를 나타냅니다. pom.xml 파일에는 애플리케이션의 Maven 구성이 포함되어 있습니다.

사전 요구 사항

프로세스

  1. Java 파일을 저장할 디렉터리를 만듭니다.

    구문

    $ mkdir -p <application_root>/src/main/java/com/example/oidc

    예제

    $ mkdir -p simple-oidc-example/src/main/java/com/example/oidc

  2. 새 디렉터리로 이동합니다.

    구문

    $ cd <application_root>/src/main/java/com/example/oidc

    예제

    $ cd simple-oidc-example/src/main/java/com/example/oidc

  3. 다음 콘텐츠를 사용하여 서블릿 "SecuredServlet.java"를 생성합니다.

    package com.example.oidc;
    
    import java.io.IOException;
    import java.io.PrintWriter;
    import java.security.Principal;
    
    import javax.servlet.ServletException;
    import javax.servlet.annotation.WebServlet;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    
    /**
     * A simple secured HTTP servlet.
     *
     */
    @WebServlet("/secured")
    public class SecuredServlet extends HttpServlet {
    
        @Override
        protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
            try (PrintWriter writer = resp.getWriter()) {
                writer.println("<html>");
                writer.println("  <head><title>Secured Servlet</title></head>");
                writer.println("  <body>");
                writer.println("    <h1>Secured Servlet</h1>");
                writer.println("    <p>");
                writer.print(" Current Principal '");
                Principal user = req.getUserPrincipal();
                writer.print(user != null ? user.getName() : "NO AUTHENTICATED USER");
                writer.print("'");
                writer.println("    </p>");
                writer.println("  </body>");
                writer.println("</html>");
            }
        }
    
    }
  4. 애플리케이션의 internet -INF 디렉터리에 있는 배포 설명자 web.xml 파일에서 애플리케이션에 대한 액세스를 위한 보안 규칙을 추가합니다.

    <?xml version="1.0" encoding="UTF-8"?>
    
    <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
       metadata-complete="false">
    
        <security-constraint>
            <web-resource-collection>
                <web-resource-name>secured</web-resource-name>
                <url-pattern>/secured</url-pattern>
            </web-resource-collection>
            <auth-constraint>
                <role-name>*</role-name>
            </auth-constraint>
        </security-constraint>
    
        <security-role>
            <role-name>*</role-name>
        </security-role>
    </web-app>
  5. OpenID Connect로 애플리케이션을 보호하려면 배포 구성을 업데이트하거나 elytron-oidc-client 하위 시스템을 구성합니다.

    참고

    배포 구성 및 elytron-oidc-client 하위 시스템에서 OpenID Connect를 구성하는 경우 elytron-oidc-client 하위 시스템의 구성이 애플리케이션 배포 설명자의 구성보다 우선합니다.

    • 배포 구성을 업데이트합니다.

      1. 다음과 같이 WEB-INF 디렉토리에 파일 oidc.json 을 생성하십시오.

        {
          "provider-url" : "http://localhost:8180/auth/realms/example_realm",
          "ssl-required": "external",
          "client-id": "my_jbeap",
          "public-client": true,
          "confidential-port": 0
        }
      2. 배포 설명자 web.xml 파일을 다음 텍스트로 업데이트하여 이 애플리케이션이 OIDC를 사용하는지 선언합니다.

        <login-config>
            <auth-method>OIDC</auth-method>
        </login-config>
    • elytron-oidc-client 하위 시스템 구성:

      • 애플리케이션을 보호하려면 다음 관리 CLI 명령을 사용하십시오.

        /subsystem=elytron-oidc-client/secure-deployment=simple-oidc-example.war/:add(client-id=my_jbeap,provider-url=http://localhost:8180/auth/realms/example_realm,public-client=true,ssl-required=external)
  6. 애플리케이션 루트 디렉터리에서 다음 명령을 사용하여 애플리케이션을 컴파일합니다.

    $ mvn package
  7. 애플리케이션을 배포합니다.

    $ mvn wildfly:deploy

검증

  1. 브라우저에서 http://localhost:8080/simple-oidc-example/secured 로 이동합니다.
  2. 자격 증명을 사용하여 로그인합니다. 예를 들면 다음과 같습니다.

    username: jane_doe
    password: janedoep@$$

    다음 출력이 표시됩니다.

    Secured Servlet
    Current Principal '5cb0c4ca-0477-44c3-bdef-04db04d7e39d'

    이제 Red Hat Single Sign-On에서 구성한 인증 정보를 OpenID 공급자로 사용하여 애플리케이션에 로그인할 수 있습니다.

9.3.4. 사용자 역할을 기반으로 애플리케이션에 대한 액세스 제한

사용자 역할을 기반으로 애플리케이션의 모든 또는 일부에 대한 액세스를 제한할 수 있습니다. 예를 들어 "public" 역할을 가진 사용자가 민감하지 않은 애플리케이션의 부분에 액세스할 수 있도록 하고 사용자에게 해당 부분에 대한 "admin" 역할 액세스 권한을 부여할 수 있습니다.

사전 요구 사항

프로세스

  1. 배포 설명자 web.xml 파일을 다음 텍스트로 업데이트합니다.

    구문

    <security-constraint>
        ...
        <auth-constraint>
            <role-name><allowed_role></role-name>
        </auth-constraint>
    </security-constraint>

    예제

    <security-constraint>
        ...
        <auth-constraint>
            <role-name>example_role</role-name> 1
        </auth-constraint>
    </security-constraint>

    1
    example_role 역할이 있는 사용자만 애플리케이션에 액세스할 수 있도록 허용합니다.
  2. 애플리케이션 루트 디렉터리에서 다음 명령을 사용하여 애플리케이션을 다시 컴파일합니다.

    $ mvn package
  3. 애플리케이션을 배포합니다.

    $ mvn wildfly:deploy

검증

  1. 브라우저에서 http://localhost:8080/simple-oidc-example/secured 로 이동합니다.
  2. 자격 증명을 사용하여 로그인합니다. 예를 들면 다음과 같습니다.

    username: jane_doe
    password: janedoep@$$

    다음 출력이 표시됩니다.

    Forbidden

    "jane_doe" 사용자에게 필요한 역할을 할당하지 않았기 때문에 jane_doe는 애플리케이션에 로그인할 수 없습니다. 필수 역할이 있는 사용자만 로그인할 수 있습니다.

사용자에게 필요한 역할을 할당하려면 Red Hat Single Sign-On 에서 사용자에게 역할 생성 및 할당 을 참조하십시오.

9.3.5. Red Hat Single Sign-On에서 사용자 역할 생성 및 할당

Red Hat Single Sign-On은 SSO(Single Sign-On)로 웹 애플리케이션을 보호하기 위한 ID 및 액세스 관리 공급자입니다. Red Hat Single Sign-On에서 사용자를 정의하고 역할을 할당할 수 있습니다.

사전 요구 사항

프로세스

  1. http://localhost:<port>/auth/ 에서 관리자 콘솔에 로그인합니다. 예: http://localhost:8180/auth/.
  2. JBoss EAP에 연결하는 데 사용하는 영역을 클릭합니다. 예를 들면 example_realm 입니다.
  3. Clients 를 클릭한 다음 JBoss EAP에 대해 구성한 클라이언트 이름을 클릭합니다. 예를 들면 my_jbeap 입니다.
  4. 역할 을 클릭한 다음 역할 추가를 클릭합니다.
  5. example_role 과 같은 역할 이름을 입력한 다음 저장을 클릭합니다. 이는 JBoss EAP에서 권한 부여를 위해 구성하는 역할 이름입니다.
  6. 사용자를 클릭한 다음 모든 사용자 보기를 클릭합니다.
  7. ID를 클릭하여 생성한 역할을 할당합니다. 예를 들어 jane_doe 의 ID를 클릭합니다.
  8. 역할 매핑을 클릭합니다. 클라이언트 역할 필드에서 JBoss EAP에 대해 구성한 클라이언트 이름을 선택합니다. 예를 들면 my_jbeap 입니다.
  9. 사용 가능한 역할에서 할당할 역할을 선택합니다. 예: example_role. 선택한 추가 를 클릭합니다.

검증

  1. 브라우저에서 애플리케이션 URL로 이동합니다.
  2. 자격 증명을 사용하여 로그인합니다. 예를 들면 다음과 같습니다.

    username: jane_doe
    password: janedoep@$$

    다음 출력이 표시됩니다.

    Secured Servlet
    Current Principal '5cb0c4ca-0477-44c3-bdef-04db04d7e39d'

    필요한 역할이 있는 사용자는 애플리케이션에 로그인할 수 있습니다.

9.4. OpenID Connect를 사용하여 JBoss EAP 부팅 가능 STIG 애플리케이션 개발

OpenID Connect(OIDC)를 사용하여 인증을 외부 OpenID 공급자에 위임할 수 있습니다. elytron-oidc-client galleon 레이어는 JBoss EAP 부팅 가능한 STIG 애플리케이션에서 기본 OIDC 클라이언트를 제공하여 외부 OpenID 공급자와 연결합니다.

Red Hat Single Sign-On을 사용하여 OpenID Connect로 보안된 애플리케이션을 생성하려면 다음 절차를 따르십시오.

9.4.1. Red Hat Single Sign-On을 OpenID 공급자로 구성

Red Hat Single Sign-On은 SSO(Single Sign-On)로 웹 애플리케이션을 보호하기 위한 ID 및 액세스 관리 공급자입니다. OpenID Connect ( OAuth 2.0에 대한 확장)를 지원합니다.

사전 요구 사항

프로세스

  1. JBoss EAP 기본 포트가 8080이므로 8080 이외의 포트에서 Red Hat Single Sign-On 서버를 시작합니다.

    구문

    $ RH_SSO_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=<offset-number>

    예제

    $ /home/servers/rh-sso-7.4/bin/standalone.sh -Djboss.socket.binding.port-offset=100

  2. http://localhost:<port>/auth/ 에서 관리 콘솔에 로그인합니다. 예: http://localhost:8180/auth/.
  3. 관리 콘솔에서 마스터 위에 마우스를 가져가려면 영역 추가 를 클릭합니다.
  4. 영역의 이름을 입력합니다. 예를 들면 example_realm 입니다. EnabledON 인지 확인하고 생성 을 클릭합니다.
  5. Users 를 클릭한 다음 Add user (사용자 추가)를 클릭하여 사용자를 영역에 추가합니다.
  6. 사용자 이름을 입력합니다. 예: jane_doe. User EnabledON 인지 확인하고 Save 를 클릭합니다.
  7. 인증 정보를 클릭하여 사용자에게 암호를 추가합니다.
  8. 사용자의 암호를 설정합니다. 예: janedoep@$. 임시OFF 로 전환하고 암호 설정을 클릭합니다. 확인 프롬프트에서 암호 설정을 클릭합니다.
  9. 클라이언트 를 클릭한 다음 생성 을 클릭하여 클라이언트 연결을 구성합니다.
  10. 클라이언트 ID를 입력합니다. 예를 들면 my_jbeap 입니다. 클라이언트 프로토콜이 openid-connect 로 설정되어 있는지 확인하고 저장을 클릭합니다.
  11. 설치 를 클릭한 다음 Keycloak OIDC JSON형식 옵션으로 선택하여 연결 매개 변수를 확인합니다.

    {
      "realm": "example_realm",
      "auth-server-url": "http://localhost:8180/auth/",
      "ssl-required": "external",
      "resource": "my_jbeap",
      "public-client": true,
      "confidential-port": 0
    }

    Red Hat Single Sign-On을 ID 공급자로 사용하도록 JBoss EAP 애플리케이션을 구성할 때 다음과 같이 매개변수를 사용합니다.

    "provider-url" : "http://localhost:8180/auth/realms/example_realm",
    "ssl-required": "external",
    "client-id": "my_jbeap",
    "public-client": true,
    "confidential-port": 0
  12. 클라이언트 를 클릭하고 my_jbeap 옆에 있는 편집 을 클릭하여 클라이언트 설정을 편집합니다.
  13. 유효한 리디렉션 URI 에서 인증이 성공한 후 페이지를 리디렉션해야 하는 URL을 입력합니다.

    이 예에서는 이 값을 http://localhost:8080/simple-oidc-layer-example/secured/*로 설정합니다.

9.4.2. 부팅 가능한 OIDC 애플리케이션에 대한 Maven 프로젝트 구성

OpenID Connect를 사용하는 부팅 가능한 STIG 애플리케이션을 생성하기 위한 필수 종속성과 디렉터리 구조를 사용하여 Maven 프로젝트를 생성합니다. elytron-oidc-client galleon 계층은 OpenID 공급자와 연결할 기본 OpenID Connect(OIDC) 클라이언트를 제공합니다.

사전 요구 사항

프로세스

  1. mvn 명령을 사용하여 Maven 프로젝트를 설정합니다. 명령은 프로젝트에 대한 디렉터리 구조와 pom.xml 구성 파일을 생성합니다.

    구문

    $ mvn archetype:generate \
    -DgroupId=${group-to-which-your-application-belongs} \
    -DartifactId=${name-of-your-application} \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false

    예제

    $ mvn archetype:generate \
    -DgroupId=com.example.oidc \
    -DartifactId=simple-oidc-layer-example \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false

  2. 애플리케이션 루트 디렉터리로 이동합니다.

    구문

    $ cd <name-of-your-application>

    예제

    $ cd simple-oidc-layer-example

  3. 생성된 pom.xml 파일을 다음과 같이 업데이트합니다.

    1. 다음 리포지토리를 설정합니다.

      <repositories>
          <repository>
              <id>jboss</id>
              <url>https://maven.repository.redhat.com/ga</url>
              <snapshots>
                  <enabled>false</enabled>
              </snapshots>
          </repository>
      </repositories>
    2. 다음 플러그인 리포지토리를 설정합니다.

      <pluginRepositories>
          <pluginRepository>
              <id>jboss</id>
              <url>https://maven.repository.redhat.com/ga</url>
              <snapshots>
                  <enabled>false</enabled>
              </snapshots>
          </pluginRepository>
      </pluginRepositories>
    3. 다음 속성을 설정합니다.

      <properties>
          <maven.compiler.source>1.8</maven.compiler.source>
          <maven.compiler.target>1.8</maven.compiler.target>
          <bootable.jar.maven.plugin.version>6.1.2.Final-redhat-00001</bootable.jar.maven.plugin.version>
          <jboss.xp.galleon.feature.pack.version>4.0.0.GA-redhat-00002</jboss.xp.galleon.feature.pack.version>
      </properties>
    4. 다음 종속 항목을 설정합니다.

      <dependencies>
          <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.1.0.redhat-1</version>
            <scope>provided</scope>
          </dependency>
      </dependencies>
      
      <dependencyManagement>
          <dependencies>
              <dependency>
                  <groupId>org.jboss.bom</groupId>
                  <artifactId>jboss-eap-jakartaee8</artifactId>
                  <version>7.3.4.GA</version>
                  <type>pom</type>
                  <scope>import</scope>
              </dependency>
              <dependency>
                  <groupId>org.jboss.spec.javax.servlet</groupId>
                  <artifactId>jboss-servlet-api_4.0_spec</artifactId>
                  <scope>provided</scope>
              </dependency>
          </dependencies>
      </dependencyManagement>
    5. pom.xml 파일의 &lt ;build&gt; 요소에 다음 빌드 구성을 설정합니다.

      <finalName>${project.artifactId}</finalName>
      <plugins>
          <plugin>
              <groupId>org.wildfly.plugins</groupId>
              <artifactId>wildfly-jar-maven-plugin</artifactId>   1
              <version>${bootable.jar.maven.plugin.version}</version>
              <configuration>
                  <feature-pack-location>org.jboss.eap:wildfly-galleon-pack:${jboss.xp.galleon.feature.pack.version}</feature-pack-location>
                  <layers>
                      <layer>jaxrs-server</layer>
                      <layer>elytron-oidc-client</layer>    2
                  </layers>
                  <context-root>false</context-root>   3
              </configuration>
              <executions>
                  <execution>
                      <goals>
                          <goal>package</goal>
                      </goals>
                  </execution>
              </executions>
          </plugin>
      </plugins>
      1
      애플리케이션을 부팅 가능한 JAR로 빌드하는 JBoss EAP Maven 플러그인
      2
      elytron-oidc-client 계층은 외부 OpenID 공급자와 연결할 기본 OpenID Connect(OIDC) 클라이언트를 제공합니다.
      3
      simple-oidc-layer-example 리소스 경로에 애플리케이션을 등록합니다. 그런 다음, 서블릿은 URL http://server-url/application_name/서블릿 경로 (예: http://localhost:8080/simple-oidc-layer-example/secured )에서 사용할 수 있습니다. 기본적으로 애플리케이션 WAR 파일은 http://server-url/서블릿_path와 같은 root- context 경로에 등록됩니다(예: http://localhost:8080/secured ).
    6. 애플리케이션 이름(예: pom.xml 파일의 < build > 요소에서 "simple-oidc-layer-example")을 설정합니다.

      <finalName>simple-oidc-layer-example</finalName>

검증

  • 애플리케이션 루트 디렉터리에 다음 명령을 입력합니다.

    $ mvn install

    다음과 유사한 출력이 표시됩니다.

    ...
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 19.157 s
    [INFO] Finished at: 2022-03-10T09:38:21+05:30
    [INFO] ------------------------------------------------------------------------

OpenID Connect를 사용하는 부팅 가능한 ScanSetting 애플리케이션을 생성할 수 있습니다.

9.4.3. OpenID Connect를 사용하는 부팅 가능한 root 애플리케이션 생성

다음 예제에서는 로그인한 사용자의 보안 주체를 출력하는 서블릿을 생성하는 방법을 보여줍니다. 기존 애플리케이션의 경우 배포 구성 업데이트와 관련된 단계만 필요합니다.

이 예에서 Principal 값은 OpenID 공급자의 ID 토큰에서 가져옵니다. 기본적으로 보안 주체는 토큰의 "sub" 클레임 값입니다. 다음 중 하나에서 Principal로 사용할 ID 토큰의 클레임 값을 지정할 수 있습니다.

  • elytron-oidc-client 하위 시스템 특성 principal-attribute.
  • oidc.json 파일

절차의 < application_root >는 pom.xml 파일 디렉터리를 나타냅니다. pom.xml 파일에는 애플리케이션의 Maven 구성이 포함되어 있습니다.

사전 요구 사항

프로세스

  1. Java 파일을 저장할 디렉터리를 만듭니다.

    구문

    $ mkdir -p <application_root>/src/main/java/com/example/oidc

    예제

    $ mkdir -p simple-oidc-layer-example/src/main/java/com/example/oidc

  2. 새 디렉터리로 이동합니다.

    구문

    $ cd <application_root>/src/main/java/com/example/oidc

    예제

    $ cd simple-oidc-layer-example/src/main/java/com/example/oidc

  3. 다음 콘텐츠를 사용하여 서블릿 "SecuredServlet.java"를 생성합니다.

    package com.example.oidc;
    
    import java.io.IOException;
    import java.io.PrintWriter;
    import java.security.Principal;
    
    import javax.servlet.ServletException;
    import javax.servlet.annotation.WebServlet;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    
    /**
     * A simple secured HTTP servlet.
     *
     */
    @WebServlet("/secured")
    public class SecuredServlet extends HttpServlet {
    
        @Override
        protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
            try (PrintWriter writer = resp.getWriter()) {
                writer.println("<html>");
                writer.println("  <head><title>Secured Servlet</title></head>");
                writer.println("  <body>");
                writer.println("    <h1>Secured Servlet</h1>");
                writer.println("    <p>");
                writer.print(" Current Principal '");
                Principal user = req.getUserPrincipal();
                writer.print(user != null ? user.getName() : "NO AUTHENTICATED USER");
                writer.print("'");
                writer.println("    </p>");
                writer.println("  </body>");
                writer.println("</html>");
            }
        }
    
    }
  4. 애플리케이션의 internet -INF 디렉터리에 있는 배포 설명자 web.xml 파일에서 애플리케이션에 대한 액세스를 위한 보안 규칙을 추가합니다.

    <?xml version="1.0" encoding="UTF-8"?>
    
    <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
       metadata-complete="false">
    
        <security-constraint>
            <web-resource-collection>
                <web-resource-name>secured</web-resource-name>
                <url-pattern>/secured</url-pattern>
            </web-resource-collection>
            <auth-constraint>
                <role-name>*</role-name>
            </auth-constraint>
        </security-constraint>
    
        <security-role>
            <role-name>*</role-name>
        </security-role>
    </web-app>
  5. OpenID Connect로 애플리케이션을 보호하려면 배포 구성을 업데이트하거나 elytron-oidc-client 하위 시스템을 구성합니다.

    참고

    배포 구성 및 elytron-oidc-client 하위 시스템에서 OpenID Connect를 구성하는 경우 elytron-oidc-client 하위 시스템의 구성이 애플리케이션 배포 설명자의 구성보다 우선합니다.

    • 배포 구성을 업데이트합니다.

      1. 다음과 같이 WEB-INF 디렉토리에 파일 oidc.json 을 생성하십시오.

        {
          "provider-url" : "http://localhost:8180/auth/realms/example_realm",
          "ssl-required": "external",
          "client-id": "my_jbeap",
          "public-client": true,
          "confidential-port": 0
        }
      2. 배포 설명자 web.xml 파일을 다음 텍스트로 업데이트하여 이 애플리케이션이 OIDC를 사용하는지 선언합니다.

        <login-config>
            <auth-method>OIDC</auth-method>
        </login-config>
    • elytron-oidc-client 하위 시스템 구성:

      1. CLI 스크립트를 애플리케이션 루트 디렉터리에 저장할 디렉터리를 생성합니다.

        구문

        $ mkdir <application_root>/<cli_script_directory>

        예제

        $ mkdir simple-oidc-layer-example/scripts/

        애플리케이션 루트 디렉터리 내에서 Maven이 액세스할 수 있는 모든 위치에서 디렉터리를 생성할 수 있습니다.

      2. 다음 콘텐츠를 사용하여 configure-oidc.cli 와 같은 CLI 스크립트를 생성합니다.

        /subsystem=elytron-oidc-client/secure-deployment=simple-oidc-layer-example.war:add(client-id=my_jbeap,provider-url=http://localhost:8180/auth/realms/example_realm,public-client=true,ssl-required=external)

        subsystem 명령은 elytron-oidc-client 하위 시스템에서 보안하기 위한 배포로 simple-oidc-layer-example.war 리소스를 정의합니다.

      3. 프로젝트 pom.xml 파일에서 기존 플러그인 <configuration> 요소에 다음 구성 추출 파일을 추가합니다.

        <cli-sessions>
            <cli-session>
                <script-files>
                    <script>scripts/configure-oidc.cli</script>
                </script-files>
            </cli-session>
        </cli-sessions>
  6. 애플리케이션 루트 디렉터리에서 다음 명령을 사용하여 애플리케이션을 컴파일합니다.

    $ mvn package
  7. 다음 명령을 사용하여 부팅 가능한 root 애플리케이션을 배포합니다.

    구문

    $ java -jar <application_root>/target/simple-oidc-layer-example-bootable.jar

    예제

    $ java -jar simple-oidc-layer-example/target/simple-oidc-layer-example-bootable.jar

    이는 JBoss EAP를 시작하고 애플리케이션을 배포합니다.

검증

  1. 브라우저에서 http://localhost:8080/simple-oidc-layer-example/secured 로 이동합니다.
  2. 자격 증명을 사용하여 로그인합니다. 예를 들면 다음과 같습니다.

    username: jane_doe
    password: janedoep@$$

    다음 출력이 표시됩니다.

    Secured Servlet
    Current Principal '5cb0c4ca-0477-44c3-bdef-04db04d7e39d'

    이제 Red Hat Single Sign-On에서 구성한 인증 정보를 OpenID 공급자로 사용하여 애플리케이션에 로그인할 수 있습니다.

9.4.4. 부팅 가능한 OIDC 애플리케이션의 사용자 역할에 따라 액세스 제한

사용자 역할을 기반으로 애플리케이션의 모든 또는 일부에 대한 액세스를 제한할 수 있습니다. 예를 들어 "public" 역할을 가진 사용자가 민감하지 않은 애플리케이션의 부분에 액세스할 수 있도록 하고 사용자에게 해당 부분에 대한 "admin" 역할 액세스 권한을 부여할 수 있습니다.

사전 요구 사항

프로세스

  1. 배포 설명자 web.xml 파일을 다음 텍스트로 업데이트합니다.

    구문

    <security-constraint>
        ...
        <auth-constraint>
            <role-name><allowed_role></role-name>
        </auth-constraint>
    </security-constraint>

    예제

    <security-constraint>
        ...
        <auth-constraint>
            <role-name>example_role</role-name> 1
        </auth-constraint>
    </security-constraint>

    1
    example_role 역할이 있는 사용자만 애플리케이션에 액세스할 수 있도록 허용합니다.
  2. 애플리케이션 루트 디렉터리에서 다음 명령을 사용하여 애플리케이션을 다시 컴파일합니다.

    $ mvn package
  3. 애플리케이션을 배포합니다.

    $ java -jar simple-oidc-layer-example/target/simple-oidc-layer-example-bootable.jar

    이는 JBoss EAP를 시작하고 애플리케이션을 배포합니다.

검증

  1. 브라우저에서 \localhost:8080/simple-oidc-layer-example/secured 로 이동합니다.
  2. 자격 증명을 사용하여 로그인합니다. 예를 들면 다음과 같습니다.

    username: jane_doe
    password: janedoep@$$

    다음 출력이 표시됩니다.

    Forbidden

    "jane_doe" 사용자에게 필요한 역할을 할당하지 않았기 때문에 jane_doe는 애플리케이션에 로그인할 수 없습니다. 필수 역할이 있는 사용자만 로그인할 수 있습니다.

사용자에게 필요한 역할을 할당하려면 Red Hat Single Sign-On 에서 사용자에게 역할 생성 및 할당 을 참조하십시오.

9.4.5. Red Hat Single Sign-On에서 사용자 역할 생성 및 할당

Red Hat Single Sign-On은 SSO(Single Sign-On)로 웹 애플리케이션을 보호하기 위한 ID 및 액세스 관리 공급자입니다. Red Hat Single Sign-On에서 사용자를 정의하고 역할을 할당할 수 있습니다.

사전 요구 사항

프로세스

  1. http://localhost:<port>/auth/ 에서 관리자 콘솔에 로그인합니다. 예: http://localhost:8180/auth/.
  2. JBoss EAP에 연결하는 데 사용하는 영역을 클릭합니다. 예를 들면 example_realm 입니다.
  3. Clients 를 클릭한 다음 JBoss EAP에 대해 구성한 클라이언트 이름을 클릭합니다. 예를 들면 my_jbeap 입니다.
  4. 역할 을 클릭한 다음 역할 추가를 클릭합니다.
  5. example_role 과 같은 역할 이름을 입력한 다음 저장을 클릭합니다. 이는 JBoss EAP에서 권한 부여를 위해 구성하는 역할 이름입니다.
  6. 사용자를 클릭한 다음 모든 사용자 보기를 클릭합니다.
  7. ID를 클릭하여 생성한 역할을 할당합니다. 예를 들어 jane_doe 의 ID를 클릭합니다.
  8. 역할 매핑을 클릭합니다. 클라이언트 역할 필드에서 JBoss EAP에 대해 구성한 클라이언트 이름을 선택합니다. 예를 들면 my_jbeap 입니다.
  9. 사용 가능한 역할에서 할당할 역할을 선택합니다. 예: example_role. 선택한 추가 를 클릭합니다.

검증

  1. 브라우저에서 애플리케이션 URL로 이동합니다.
  2. 자격 증명을 사용하여 로그인합니다. 예를 들면 다음과 같습니다.

    username: jane_doe
    password: janedoep@$$

    다음 출력이 표시됩니다.

    Secured Servlet
    Current Principal '5cb0c4ca-0477-44c3-bdef-04db04d7e39d'

    필요한 역할이 있는 사용자는 애플리케이션에 로그인할 수 있습니다.

10장. JBoss EAP의 가시성

개발자 또는 시스템 관리자인 경우 관찰 기능은 애플리케이션의 특정 신호, 애플리케이션 위치 및 문제 소스에 따라 사용할 수 있는 관행 및 기술 집합입니다. 가장 일반적인 신호는 메트릭, 이벤트 및 추적입니다. JBoss EAP는 관찰 을 위해 OpenTelemetry를 사용합니다.

10.1. JBoss EAP의 OpenTelemetry

OpenTelemetry는 애플리케이션의 Telemetry 데이터를 계측, 생성, 수집 및 내보내는 데 사용할 수 있는 도구 세트, API(애플리케이션 프로그래밍 인터페이스) 및 SDK(소프트웨어 개발 키트)입니다. 원격 분석 데이터에는 메트릭, 로그 및 추적이 포함됩니다. 애플리케이션의 Telemetry 데이터를 분석하면 애플리케이션 성능을 개선하는 데 도움이 됩니다. JBoss EAP는 opentelemetry 하위 시스템을 통해 OpenTelemetry 기능을 제공합니다.

참고

Red Hat JBoss Enterprise Application Platform 7.4는 OpenTelemetry 추적 기능만 제공합니다.

중요

OpenTelemetry는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview 을 참조하십시오.

추가 리소스

10.2. JBoss EAP의 OpenTelemetry 구성

opentelemetry 하위 시스템을 사용하여 JBoss EAP에서 OpenTelemetry의 여러 측면을 구성합니다. 여기에는 내보내기자, 범위 프로세서 및 샘플러가 포함됩니다.

내보내기
추적 및 메트릭을 분석하고 시각화하기 위해 Jaeger와 같은 수집기로 내보냅니다. Jaeger 또는 OpenTelemetry 프로토콜(OTLP)을 지원하는 수집기를 사용하도록 JBoss EAP를 구성할 수 있습니다.
범위 프로세서
범위를 생성하거나 일괄적으로 내보내도록 범위 프로세서를 구성할 수 있습니다. 내보낼 추적 수를 구성할 수도 있습니다.
sampler
샘플러를 구성하여 기록할 추적 수를 구성할 수 있습니다.

설정 예

다음 XML은 기본값을 포함하여 전체 OpenTelemetry 구성의 예입니다. JBoss EAP는 변경 시 기본값을 유지하지 않으므로 구성이 다를 수 있습니다.

<subsystem xmlns="urn:wildfly:opentelemetry:1.0"
        service-name="example">
    <exporter
        type="jaeger"
        endpoint="http://localhost:14250"/>
    <span-processor
        type="batch"
        batch-delay="4500"
        max-queue-size="128"
        max-export-batch-size="512"
        export-timeout="45"/>
    <sampler
        type="on"/>
</subsystem>
참고

OpenShift 경로 오브젝트를 사용하여 Jaeger 끝점과 연결할 수 없습니다. 대신 http:// <ip_address > : <port > 또는 http:// <service_name > : <port >를 사용합니다.

10.3. JBoss EAP에서 OpenTelemetry 추적

JBoss EAP는 애플리케이션의 다양한 부분을 통과할 때 사용자 요청의 진행 상황을 추적하는 데 도움이 되는 OpenTelemetry 추적 기능을 제공합니다. 추적을 분석하면 애플리케이션의 성능을 개선하고 가용성 문제를 디버깅할 수 있습니다.

OpenTelemetry 추적은 다음 구성 요소로 구성됩니다.

Trace
요청이 애플리케이션에서 통과하는 작업 컬렉션입니다.
범위
추적 내의 단일 작업입니다. 요청, 오류 및 기간(RED) 지표를 제공하고 범위 컨텍스트를 포함합니다.
범위 컨텍스트
포함 범위가 의 일부인 요청을 나타내는 고유 식별자 집합입니다.

JBoss EAP는 Jakarta RESTful Web Services 애플리케이션 및 컨테이너 관리 Jakarta RESTful Web Services 클라이언트 호출에 대한 REST 호출을 자동으로 추적합니다. JBoss EAP는 다음과 같이 암시적으로 REST 호출을 추적합니다.

  • 들어오는 각 요청에 대해 다음을 수행합니다.

    • JBoss EAP는 요청에서 범위 컨텍스트를 추출합니다.
    • JBoss EAP는 새 기간을 시작한 다음 요청이 완료되면 종료합니다.
  • 발신 요청마다 다음을 수행합니다.

    • JBoss EAP는 요청에 범위 컨텍스트를 삽입합니다.
    • JBoss EAP는 새 기간을 시작한 다음 요청이 완료되면 종료합니다.

암시적 추적 외에도 세분화된 추적을 위해 애플리케이션에 Tracer 인스턴스를 삽입하여 사용자 지정 범위를 생성할 수 있습니다.

중요

REST 호출을 위해 내보낸 중복 추적이 표시되면 microprofile-opentracing-overcloudrye 하위 시스템을 비활성화합니다. microprofile-opentracing-undercloudrye 를 비활성화하는 방법에 대한 자세한 내용은 microprofile-opentracing-overcloudrye 하위 시스템 제거를 참조하십시오.

10.4. JBoss EAP에서 OpenTelemetry 추적 활성화

JBoss EAP에서 OpenTelemetry 추적을 사용하려면 먼저 opentelemetry 하위 시스템을 활성화해야 합니다.

사전 요구 사항

  • JBoss EAP XP를 설치했습니다.

프로세스

  1. 관리 CLI를 사용하여 OpenTelemetry 확장을 추가합니다.

    /extension=org.wildfly.extension.opentelemetry:add
  2. 관리 CLI를 사용하여 opentelemetry 하위 시스템을 활성화합니다.

    /subsystem=opentelemetry:add
  3. JBoss EAP 다시 로드.

    reload

10.5. opentelemetry 하위 시스템 구성

opentelemetry 하위 시스템을 구성하여 추적의 다양한 측면을 설정할 수 있습니다. 추적을 관찰하는 데 사용하는 수집기를 기반으로 이러한 항목을 구성합니다.

사전 요구 사항

프로세스

  1. 추적의 내보내기 유형을 설정합니다.

    구문

    /subsystem=opentelemetry:write-attribute(name=exporter-type, value=<exporter_type>)

    예제

    /subsystem=opentelemetry:write-attribute(name=exporter-type, value=jaeger)

  2. 추적을 내보낼 끝점을 설정합니다.

    구문

    /subsystem=opentelemetry:write-attribute(name=endpoint, value=<URL:port>)

    예제

    /subsystem=opentelemetry:write-attribute(name=endpoint, value=http:localhost:14250)

  3. 추적을 내보내는 서비스 이름을 설정합니다.

    구문

    /subsystem=opentelemetry:write-attribute(name=service-name, value=<service_name>)

    예제

    /subsystem=opentelemetry:write-attribute(name=service-name, value=exampleOpenTelemetryService)

10.6. Jaeger를 사용하여 애플리케이션의 OpenTelemetry 추적 관찰

JBoss EAP는 Jakarta RESTful Web Services 애플리케이션에 대한 REST 호출을 자동으로 및 암시적으로 추적합니다. Jakarta RESTful Web Services 애플리케이션에 구성을 추가하거나 opentelemetry 하위 시스템을 구성할 필요가 없습니다. 다음 절차에서는 Jaeger 콘솔에서 helloworld-rs 빠른 시작에 대한 추적을 모니터링하는 방법을 보여줍니다.

사전 요구 사항

프로세스

  1. Docker 이미지를 사용하여 Jaeger 콘솔을 시작합니다.

    $ docker run -d --name jaeger \
      -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
      -p 5775:5775/udp \
      -p 6831:6831/udp \
      -p 6832:6832/udp \
      -p 5778:5778 \
      -p 16686:16686 \
      -p 14268:14268 \
      -p 14250:14250 \
      -p 9411:9411 \
      jaegertracing/all-in-one:1.29
  2. Maven을 사용하여 루트 디렉터리에서 helloworld-rs 빠른 시작을 배포합니다.

    $ mvn clean install wildfly:deploy
  3. 웹 브라우저에서 http://localhost:8080/helloworld-rs/ 에서 퀵 스타트에 액세스한 다음 링크를 클릭합니다.
  4. 웹 브라우저에서 http://localhost:16686/search 에서 Jaeger 콘솔을 엽니다. hello-world.rs서비스에 나열됩니다.
  5. hello-world.rs 를 선택하고 추적 찾기를 클릭합니다. hello-world.rs 의 추적 세부 정보가 나열됩니다.

10.7. OpenTelemetry 추적 애플리케이션 개발

JBoss EAP는 Jakarta RESTful Web Services 애플리케이션에 대한 REST 호출을 자동으로 암시적으로 추적하지만 세분화된 추적을 위해 애플리케이션에서 사용자 지정 기간을 생성할 수 있습니다. 범위는 추적 내의 단일 작업입니다. 예를 들어 리소스가 정의되면 기간을 생성할 수 있습니다. 즉, 애플리케이션에서 메서드를 호출할 수 있습니다. 추적기 인스턴스를 삽입하여 애플리케이션에 사용자 지정 추적을 생성합니다.

10.7.1. OpenTelemetry 추적을 위한 Maven 프로젝트 구성

OpenTelemetry 추적 애플리케이션을 생성하려면 필요한 종속성 및 디렉터리 구조가 포함된 Maven 프로젝트를 생성합니다.

사전 요구 사항

프로세스

  1. CLI에서 mvn 명령을 사용하여 Maven 프로젝트를 설정합니다. 이 명령은 프로젝트에 대한 디렉터리 구조와 pom.xml 구성 파일을 생성합니다.

    구문

    $ mvn archetype:generate \
    -DgroupId=<group-to-which-your-application-belongs> \
    -DartifactId=<name-of-your-application> \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false

    예제

    $ mvn archetype:generate \
    -DgroupId=com.example.opentelemetry \
    -DartifactId=simple-tracing-example \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-webapp \
    -DinteractiveMode=false

  2. 애플리케이션 루트 디렉터리로 이동합니다.

    구문

    $ cd <name-of-your-application>

    예제

    $ cd simple-tracing-example

  3. 생성된 pom.xml 파일을 업데이트합니다.

    1. 다음 속성을 설정합니다.

      <properties>
          <maven.compiler.source>1.8</maven.compiler.source>
          <maven.compiler.target>1.8</maven.compiler.target>
          <failOnMissingWebXml>false</failOnMissingWebXml>
          <version.server.bom>4.0.0.GA</version.server.bom>
          <version.wildfly-jar.maven.plugin>6.1.1.Final</version.wildfly-jar.maven.plugin>
      </properties>
    2. 다음 종속 항목을 설정합니다.

      <dependencies>
          <dependency>
              <groupId>jakarta.enterprise</groupId>
              <artifactId>jakarta.enterprise.cdi-api</artifactId>
              <version>2.0.2</version>
              <scope>provided</scope>
          </dependency>
      
          <dependency>
              <groupId>org.jboss.spec.javax.ws.rs</groupId>
              <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
              <version>2.0.2.Final</version>
              <scope>provided</scope>
          </dependency>
      
          <dependency>
              <groupId>io.opentelemetry</groupId>
              <artifactId>opentelemetry-api</artifactId>
              <version>1.5.0</version>
              <scope>provided</scope>
          </dependency>
      </dependencies>
    3. mvn widlfy:deploy 를 사용하여 애플리케이션을 배포하도록 다음 빌드 구성을 설정합니다.

      <build>
        <!-- Set the name of the archive -->
        <finalName>${project.artifactId}</finalName>
        <plugins>
          <!-- Allows to use mvn wildfly:deploy -->
          <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-maven-plugin</artifactId>
          </plugin>
        </plugins>
      </build>

검증

  • 애플리케이션 루트 디렉터리에 다음 명령을 입력합니다.

    $ mvn install

    다음과 유사한 출력이 표시됩니다.

    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 1.440 s
    [INFO] Finished at: 2021-12-27T14:45:12+05:30
    [INFO] ------------------------------------------------------------------------

이제 OpenTelemetry 추적 애플리케이션을 생성할 수 있습니다.

10.7.2. 사용자 지정 범위를 생성하는 애플리케이션 생성

다음 절차에서는 다음과 같이 두 가지 사용자 지정 기간을 생성할 수 있는 애플리케이션을 생성하는 방법을 보여줍니다.

  • prepare-hello - 애플리케이션에서 getHello() 메서드를 호출하면 됩니다.
  • process-hello - hello 값이 새 String 오브젝트에 할당되면 hello 입니다.

이 절차에서는 Jaeger 콘솔에서 이러한 기간을 보는 방법도 보여줍니다. 절차의 &lt ;application_root >는 애플리케이션의 Maven 구성이 포함된 pom.xml 파일이 포함된 디렉터리를 나타냅니다.

사전 요구 사항

프로세스

  1. &lt ;application_root& gt;에서 Java 파일을 저장할 디렉터리를 만듭니다.

    구문

    $ mkdir -p src/main/java/com/example/opentelemetry

    예제

    $ mkdir -p src/main/java/com/example/opentelemetry

  2. 새 디렉터리로 이동합니다.

    구문

    $ cd src/main/java/com/example/opentelemetry

    예제

    $ cd src/main/java/com/example/opentelemetry

  3. 다음 콘텐츠를 사용하여 JakartaRestApplication.java 파일을 생성합니다. 이 JakartaRestApplication 클래스는 애플리케이션을 Jakarta RESTful Web Services 애플리케이션으로 선언합니다.

    package com.example.opentelemetry;
    
    import javax.ws.rs.ApplicationPath;
    import javax.ws.rs.core.Application;
    
    @ApplicationPath("/")
    public class JakartaRestApplication extends Application {
    }
  4. ExplicitlyTracedBean.java 클래스에 대해 다음 콘텐츠를 사용하여 ExplicitlyTracedBean.java 파일을 생성합니다. 이 클래스는 Tracer 클래스를 삽입하여 사용자 지정 범위를 생성합니다.

    package com.example.opentelemetry;
    
    import javax.enterprise.context.RequestScoped;
    import javax.inject.Inject;
    import io.opentelemetry.api.trace.Span;
    import io.opentelemetry.api.trace.Tracer;
    
    @RequestScoped
    public class ExplicitlyTracedBean {
    
        @Inject
        private Tracer tracer; 1
    
        public String getHello() {
            Span prepareHelloSpan = tracer.spanBuilder("prepare-hello").startSpan(); 2
            prepareHelloSpan.makeCurrent();
    
            String hello = "hello";
    
            Span processHelloSpan = tracer.spanBuilder("process-hello").startSpan(); 3
            processHelloSpan.makeCurrent();
    
            hello = hello.toUpperCase();
    
            processHelloSpan.end();
            prepareHelloSpan.end();
    
            return hello;
        }
    }
    1
    Tracer 클래스를 삽입하여 사용자 지정 범위를 만듭니다.
    2
    prepare-hello 라는 범위를 생성하여 getHello() 메서드가 호출되었음을 나타냅니다.
    3
    process-hello 라는 범위를 생성하여 hello 값이 hello 라는 새 String 오브젝트에 할당되었음을 나타냅니다.
  5. TracedResource 클래스에 대해 다음 콘텐츠를 사용하여 TracedResource.java 파일을 만듭니다. 이 파일은 ExplicitlyTracedBean 클래스를 삽입하고 tracedcdi-trace 의 두 끝점을 선언합니다.

    package com.example.opentelemetry;
    
    import javax.enterprise.context.RequestScoped;
    import javax.inject.Inject;
    import javax.ws.rs.GET;
    import javax.ws.rs.Path;
    import javax.ws.rs.Produces;
    import javax.ws.rs.core.MediaType;
    
    @Path("/hello")
    @RequestScoped
    public class TracedResource {
        @Inject
        private ExplicitlyTracedBean tracedBean;
    
        @GET
        @Path("/traced")
        @Produces(MediaType.TEXT_PLAIN)
        public String hello() {
            return "hello";
        }
    
        @GET
        @Path("/cdi-trace")
        @Produces(MediaType.TEXT_PLAIN)
        public String cdiHello() {
            return tracedBean.getHello();
        }
    }
  6. 애플리케이션 루트 디렉터리로 이동합니다.

    구문

    $ cd <path_to_application_root>/<application_root>

    예제

    $ cd ~/applications/simple-tracing-example

  7. 다음 명령을 사용하여 애플리케이션을 컴파일하고 배포합니다.

    $ mvn clean package wildfly:deploy
  8. Jaeger 콘솔을 시작합니다.

    $ docker run -d --name jaeger \
      -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
      -p 5775:5775/udp \
      -p 6831:6831/udp \
      -p 6832:6832/udp \
      -p 5778:5778 \
      -p 16686:16686 \
      -p 14268:14268 \
      -p 14250:14250 \
      -p 9411:9411 \
      jaegertracing/all-in-one:1.29
  9. 브라우저에서 \localhost:8080/simple-tracing-example/hello/cdi-trace 로 이동합니다.
  10. 브라우저에서 http://localhost:16686/search 에서 Jaeger 콘솔을 엽니다.
  11. Jaeger 콘솔에서 JBoss EAP XP 를 선택하고 추적 찾기를 클릭합니다.
  12. 3 Spans 를 클릭합니다.
  13. Jaeger 콘솔에는 다음 추적이 표시됩니다.

    |GET /hello/cdi-trace 1
    -
     | prepare-hello 2
      -
       | process-hello 3
    1
    이는 자동 암시적 추적의 범위입니다.
    2
    사용자 정의 범위 prepare-hellogetHello() 메서드가 호출되었음을 나타냅니다. 자동 암시적 추적을 위한 범위의 자식입니다.
    3
    사용자 지정 범위 process-hellohello 값이 새 String 오브젝트 hello 에 할당되었음을 나타냅니다. prepare-hello 범위의 하위 항목입니다.

http://localhost:16686/search 에서 애플리케이션 끝점에 액세스할 때마다 모든 하위 기간을 사용하여 새 추적이 생성됩니다.

11장. reference

11.1. MicroProfile Config 참조

11.1.1. 기본 MicroProfile Config 속성

MicroProfile Config 사양은 기본적으로 세 가지 ConfigSources 를 정의합니다.

ConfigSources 는 서수에 따라 정렬됩니다. 이후 배포에 대한 구성을 덮어써야 하는 경우 더 낮은 ordinal ConfigSource 가 더 높은 Ordinal ConfigSource 를 덮어씁니다.

표 11.1. 기본 MicroProfile Config 속성
ConfigSourceordinal

시스템 속성

400

환경 변수

300

속성 파일 META-INF/microprofile-config.properties 는 classpath에 있습니다.

100

11.1.2. MicroProfile Config SmallRye ConfigSources

microprofile-config-#159rye 프로젝트는 기본 MicroProfile Config ConfigSources 외에도 사용할 수 있는 더 많은 ConfigSources 를 정의합니다.

표 11.2. 추가 MicroProfile Config 속성
ConfigSourceordinal

Cryostat의 config-source

100

Directory의 ConfigSource

100

클래스의 ConfigSource

100

이러한 ConfigSources 에 대해 명시적 ordinal이 지정되지 않습니다. MicroProfile Config 사양에 있는 기본 ordinal 값을 상속합니다.

11.2. MicroProfile Fault Tolerance 참조

11.2.1. MicroProfile Fault Tolerance 구성 속성

smallrye Fault Tolerance 사양은 MicroProfile Fault Tolerance 사양에 정의된 속성 외에 다음 속성을 정의합니다.

표 11.3. MicroProfile Fault Tolerance 구성 속성
속성기본값설명

io.smallrye.faulttolerance.mainThreadPoolSize

100

스레드 풀의 최대 스레드 수입니다.

io.smallrye.faulttolerance.mainThreadPoolQueueSize

-1 (unbounded)

스레드 풀에서 사용해야 하는 큐의 크기입니다.

11.3. MicroProfile JWT 참조

11.3.1. MicroProfile Config JWT 표준 속성

microprofile-jwt-undercloudrye 하위 시스템은 다음 MicroProfile Config 표준 속성을 지원합니다.

표 11.4. MicroProfile Config JWT 표준 속성
속성Default설명

mp.jwt.verify.publickey

NONE

지원되는 형식 중 하나를 사용하여 인코딩된 공개 키의 문자열 표현입니다. mp.jwt.verify.publickey.location 을 설정한 경우 설정하지 마십시오.

mp.jwt.verify.publickey.location

NONE

공개 키의 위치는 상대 경로 또는 URL일 수 있습니다. mp.jwt.verify.publickey 를 설정한 경우 설정하지 마십시오.

mp.jwt.verify.issuer

NONE

모든 JWT 토큰의 예상 값은 검증되는 모든 JWT 토큰에 대한 값 입니다.

microprofile-config.properties 구성의 예:

mp.jwt.verify.publickey.location=META-INF/public.pem
mp.jwt.verify.issuer=jwt-issuer

11.4. MicroProfile OpenAPI 참조

11.4.1. MicroProfile OpenAPI 구성 속성

JBoss EAP는 표준 MicroProfile OpenAPI 구성 속성 외에도 다음과 같은 추가 MicroProfile OpenAPI 속성을 지원합니다. 이러한 속성은 전역 및 애플리케이션 범위 모두에서 적용할 수 있습니다.

표 11.5. JBoss EAP의 MicroProfile OpenAPI 속성
속성기본값설명

mp.openapi.extensions.enabled

true

OpenAPI 엔드포인트 등록을 활성화하거나 비활성화합니다.

false 로 설정하면 OpenAPI 문서 생성을 비활성화합니다. 구성 하위 시스템을 사용하여 전역적으로 값을 설정하거나 /META-INF/microprofile-config.properties 와 같은 구성 파일에서 각 애플리케이션에 대해 설정할 수 있습니다.

프로덕션 또는 개발과 같은 다른 환경에서 마이크로profile-openapi-undercloudrye 를 선택적으로 활성화하거나 비활성화하도록 이 속성을 매개 변수화할 수 있습니다.

이 속성을 사용하여 지정된 가상 호스트와 연결된 애플리케이션을 제어하는 데 MicroProfile OpenAPI 모델을 생성할 수 있습니다.

mp.openapi.extensions.path

/openapi

이 속성을 사용하여 가상 호스트와 연결된 여러 애플리케이션에 대한 OpenAPI 문서를 생성할 수 있습니다.

동일한 가상 호스트와 연결된 각 애플리케이션에 고유한 mp.openapi.extensions.path 를 설정합니다.

mp.openapi.extensions.servers.relative

true

자동 생성된 서버 레코드가 OpenAPI 끝점의 위치에 대한 절대인지 또는 상대적인지 여부를 나타냅니다.

루트가 아닌 컨텍스트 경로가 있는 경우 OpenAPI 문서의 소비자가 OpenAPI 엔드포인트 호스트를 기준으로 REST 서비스에 대한 유효한 URL을 구성할 수 있는지 확인하려면 서버 레코드가 필요합니다.

value true 는 서버 레코드가 OpenAPI 끝점의 위치를 기준으로함을 나타냅니다. 생성된 레코드에는 배포의 컨텍스트 경로가 포함되어 있습니다.

false 로 설정하면 JBoss EAP XP에서 배포에 액세스할 수 있는 모든 프로토콜, 호스트 및 포트를 포함한 서버 레코드를 생성합니다.

11.5. MicroProfile Reactive Messaging 참조

11.5.1. 외부 메시징 시스템과 통합을 위한 MicroProfile reactive 메시징 커넥터

다음은 MicroProfile Config 사양에 필요한 reactive messaging 속성 키 접두사 목록입니다.

  • mp.messaging.incoming.[channel-name].[attribute]=[value]
  • mp.messaging.outgoing.[channel-name].[attribute]=[value]
  • mp.messaging.connector.[connector-name].[attribute]=[value]

channel-name@Incoming.value() 또는 @Outgoing.value() 입니다. 자세한 내용은 한 쌍의 커넥터 방법 예제를 참조하십시오.

@Outgoing("to")
public int send() {
   int i = // Randomly generated...
   return i;
}

@Incoming("from")
public void receive(int i) {
   // Process payload
}

이 예에서 필수 속성 접두사는 다음과 같습니다.

  • mp.messaging.incoming.from. 이는 receive() 메서드를 정의합니다.
  • mp.messaging.outgoing.to. 이는 send() 메서드를 정의합니다.

이는 하나의 예입니다. 서로 다른 커넥터가 다른 속성을 인식하므로 구성하려는 커넥터에 따라 표시되는 접두사가 지정됩니다.

11.5.2. reactive 메시징 스트림과 사용자 초기화 코드 간의 데이터 교환 예

다음은 사용자가 @Channel 과 Emitter 구문을 통해 트리거한 reactive 메시징 스트림과 코드 간의 데이터 교환 예입니다.

@Path("/")
@ApplicationScoped
class MyBean {
    @Inject @Channel("my-stream")
    Emitter<String> emitter; 1

    Publisher<String> dest;

    public MyBean() { 2
    }

    @Inject
    public MyBean(@Channel("my-stream") Publisher<String> dest) {
        this.dest = subscribeAndAllowMultipleSubscriptions(dest);
    }

    private Publisher subscribeAndAllowMultipleSubscriptions(Publisher delegate) {
    } 3 4 5

    @POST
    public PublisherBuilder<String> publish(@FormParam("value") String value) {
        return emitter.send(value);
    }

    @GET
    public Publisher poll() {
        return dest;
    }

    @PreDestroy
    public void close() { 6

    }
}

인라인 세부 정보:

1
생성자가 삽입된 게시자를 래핑합니다.
2
Java 사양에 대한 CDI(Contexts and dependency Cryostat)를 충족하기 위해 이 빈 생성자가 필요합니다.
3
위임을 구독합니다.
4
여러 서브스크립션을 처리할 수 있는 게시자로 위임을 래핑합니다.
5
래핑 게시자는 위임에서 데이터를 전달합니다.
6
reactive 메시징 제공 게시자의 서브스크립션 취소.

이 예에서 MicroProfile Reactive Messaging은 my-stream 메모리 스트림을 수신하므로 Emitter 를 통해 전송된 메시지는 이 삽입된 게시자에 수신됩니다. 그러나 이 데이터 교환에 성공하려면 다음 조건이 true여야 합니다.

  1. Emitter.send() 를 호출하기 전에 채널에 활성 서브스크립션이 있어야 합니다. 이 예제에서 생성자가 호출하는 subscribeAndAllowMultipleSubscriptions() 메서드는 사용자 코드 호출에 사용할 수 있는 시점까지 활성 서브스크립션이 있는지 확인합니다.
  2. 삽입된 게시자 에 대해 하나의 서브스크립션 만 가질 수 있습니다. REST 호출을 사용하여 수신 게시자를 노출하려면 poll() 메서드를 호출하면 dest 게시자에 새 서브스크립션이 생성되고 각 클라이언트에 삽입된 데이터를 브로드캐스트하기 위해 자체 게시자를 구현해야 합니다.

11.5.3. Apache Kafka 사용자 API

Apache Kafka 사용자 API를 사용하여 Kafka가 수신된 메시지에 대한 자세한 정보를 가져오고 Kafka가 메시지를 처리하는 방법에 영향을 미칠 수 있습니다. 이 API는 io/#159rye/reactive/messaging/kafka/api 패키지에 저장되며 다음 클래스로 구성됩니다.

  • IncomingKafkaRecordMetadata. 이 메타데이터에는 다음 정보가 포함됩니다.

    • 메시지로 표시되는 Kafka 레코드 입니다.
    • 메시지에 사용되는 Kafka 주제파티션 과 그 내의 오프셋 입니다.
    • Message timestamptimestampType.
    • 메시지 헤더 입니다. 이러한 정보는 애플리케이션이 생성 측에 첨부할 수 있고 소비되는 측면에서 수신할 수 있는 정보입니다.
  • OutgoingKafkaRecordMetadata. 이 메타데이터를 사용하면 Kafka에서 메시지를 처리하는 방법을 지정하거나 덮어쓸 수 있습니다. 여기에는 다음 정보가 포함됩니다.

    • Kafka에서 메시지 키로 처리하는 키 .
    • Kafka에서 사용할 주제입니다.
    • 파티션.
    • Kafka가 생성하는 타임스탬프 를 원하지 않는 경우입니다.
    • 헤더.
  • KafkaMetadataUtil 에는 OutgoingKafkaRecordMetadata메시지에 작성하고 메시지에서 IncomingKafkaRecordMetadata 를 읽는 유틸리티 방법이 포함되어 있습니다.
중요

Kafka에 매핑되지 않은 채널로 전송된 메시지에 OutgoingKafkaRecordMetadata 를 작성하는 경우 reactive 메시징 프레임워크가 이를 무시합니다. 반대로 Kafka에 매핑되지 않은 채널에서 Message 에서 IncomingKafkaRecordMetadata 를 읽는 경우 해당 메시지는 null 로 반환됩니다.

메시지 키를작성하고 읽는 방법의 예
@Inject
@Channel("from-user")
Emitter<Integer> emitter;

@Incoming("from-user")
@Outgoing("to-kafka")
public Message<Integer> send(Message<Integer> msg) {
    // Set the key in the metadata
    OutgoingKafkaRecordMetadata<String> md =
            OutgoingKafkaRecordMetadata.<String>builder()
                .withKey("KEY-" + i)
                .build();
    // Note that Message is immutable so the copy returned by this method
    // call is not the same as the parameter to the method
    return KafkaMetadataUtil.writeOutgoingKafkaMetadata(msg, md);
}

@Incoming("from-kafka")
public CompletionStage<Void> receive(Message<Integer> msg) {
    IncomingKafkaRecordMetadata<String, Integer> metadata =
        KafkaMetadataUtil.readIncomingKafkaMetadata(msg).get();

    // We can now read the Kafka record key
    String key = metadata.getKey();

    // When using the Message wrapper around the payload we need to explicitly ack
    // them
    return msg.ack();
}
microprofile-config.properties 파일의 Kafka 매핑 예
kafka.bootstrap.servers=kafka:9092

mp.messaging.outgoing.to-kafka.connector=smallrye-kafka
mp.messaging.outgoing.to-kafka.topic=some-topic
mp.messaging.outgoing.to-kafka.value.serializer=org.apache.kafka.common.serialization.IntegerSerializer
mp.messaging.outgoing.to-kafka.key.serializer=org.apache.kafka.common.serialization.StringSerializer

mp.messaging.incoming.from-kafka.connector=smallrye-kafka
mp.messaging.incoming.from-kafka.topic=some-topic
mp.messaging.incoming.from-kafka.value.deserializer=org.apache.kafka.common.serialization.IntegerDeserializer
mp.messaging.incoming.from-kafka.key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
참고

발신 채널의 key.serializer 와 들어오는 채널의 key.deserializer 를 지정해야 합니다.

11.5.4. Kafka 커넥터의 MicroProfile Config 속성 파일의 예

이는 Kafka 커넥터의 간단한 microprofile-config.properties 파일의 예입니다. 해당 속성은 "MicroProfile reactive messaging connectors for integrating with external messaging systems"의 속성에 해당합니다.

kafka.bootstrap.servers=kafka:9092

mp.messaging.outgoing.to.connector=smallrye-kafka
mp.messaging.outgoing.to.topic=my-topic
mp.messaging.outgoing.to.value.serializer=org.apache.kafka.common.serialization.IntegerSerializer

mp.messaging.incoming.from.connector=smallrye-kafka
mp.messaging.incoming.from.topic=my-topic
mp.messaging.incoming.from.value.deserializer=org.apache.kafka.common.serialization.IntegerDeserializer
표 11.6. 항목 토론
항목설명

에서 다음을 수행합니다.

이는 "채널"입니다.

전송,수신

이는 "methods"입니다.

to channel은 send() 메서드에 있고 from 채널은 receive() 메서드에 있습니다.

kafka.bootstrap.servers=kafka:9092

이는 애플리케이션이 연결해야 하는 Kafka 브로커의 URL을 지정합니다. 채널 수준에서 URL을 지정할 수도 있습니다(예: mp.messaging.outgoing.to.bootstrap.servers=kafka:9092).

mp.messaging.outgoing.to.connector=smallrye-kafka

이는 to 채널을 통해 Kafka에서 메시지를 수신할 수 있음을 나타냅니다.

smallrye reactive messaging는 애플리케이션을 빌드하기 위한 프레임워크입니다. smallrye-kafka 값은 SmallRye reactive messaging-specific입니다. Galleon을 사용하여 자체 서버를 프로비저닝하는 경우 microprofile-reactive-messaging-kafka Galleon 계층을 포함하여 Kafka 통합을 활성화할 수 있습니다.

mp.messaging.outgoing.to.topic=my-topic

이는 my-topic 이라는 Kafka 주제로 데이터를 보낼 것임을 나타냅니다.

Kafka "topic"은 메시지가 저장되고 게시되는 카테고리 또는 피드 이름입니다. 모든 Kafka 메시지는 주제로 구성됩니다. 생산자 애플리케이션은 주제 및 소비자 애플리케이션에 데이터를 작성하여 주제 에서 데이터를 읽습니다.

MP.messaging.outgoing.to.value.serializer=org.apache.kafka.common.serialization.IntegerSerializer

이는 커넥터가 IntegerSerializer 를 사용하여 topic에 쓸 때 send() 메서드가 출력되는 값을 직렬화하도록 지시합니다. Kafka는 표준 Java 유형에 대한 직렬화를 제공합니다. org.apache.kafka.common.serialization.Serializer 를 구현하는 클래스를 작성한 다음 해당 클래스를 배포에 포함하여 고유한 serializer를 구현할 수 있습니다.

mp.messaging.incoming.from.connector=smallrye-kafka

이는 channel을 사용하여 Kafka 에서 메시지를 수신할 것임을 나타냅니다. 다시 말하지만 smallrye-kafka 값은 SmallRye reactive messaging-specific입니다.

mp.messaging.incoming.from.topic=my-topic

이는 커넥터가 my-topic 이라는 Kafka 주제에서 데이터를 읽어야 함을 나타냅니다.

MP.messaging.incoming.from.value.deserializer=org.apache.kafka.common.serialization.IntegerDeserializer

이는 커넥터가 IntegerDeserializer 를 사용하여 receive() 메서드를 호출하기 전에 주제의 값을 역직렬화하도록 지시합니다. org.apache.kafka.common.serialization.Deserialization.Deserializer 를 구현하는 클래스를 작성한 다음 해당 클래스를 배포에 포함하여 고유한 역직렬을 구현할 수 있습니다.

참고

이 속성 목록은 포괄적이지 않습니다. 자세한 내용은 SmallRye Reactive Messaging Apache Kafka 설명서를 참조하십시오.

필수 MicroProfile Reactive Messaging 접두사

MicroProfile Reactive Messaging 사양에는 Kafka에 대해 다음과 같은 메서드 속성 키 접두사가 필요합니다.

  • mp.messaging.incoming.[channel-name].[attribute]=[value]`
  • mp.messaging.outgoing.[channel-name].[attribute]=[value]`
  • mp.messaging.connector.[connector-name].[attribute]=[value]`

channel-name@Incoming.value() 또는 @Outgoing.value() 입니다.

이제 다음 메서드 쌍 예제를 고려하십시오.

@Outgoing("to")
public int send() {
    int i = // Randomly generated...
    return i;
}

@Incoming("from")
public void receive(int i) {
    // Process payload
}

이 메서드 쌍 예제에서는 다음과 같은 필수 속성 접두사를 기록해 둡니다.

  • mp.messaging.incoming.from. 이 접두사는 receive() 메서드의 구성으로 속성을 선택합니다.
  • mp.messaging.outgoing.to. 이 접두사는 send() 메서드의 구성으로 속성을 선택합니다.

11.6. OpenID Connect 참조

11.6.1. Elytron-oidc-client 하위 시스템 속성

elytron-oidc-client 하위 시스템은 동작을 구성하는 속성을 제공합니다.

표 11.7. Elytron-oidc-client 하위 시스템 속성
속성설명

provider

OpenID Connect 공급자에 대한 구성입니다.

secure-deployment

OpenID Connect 공급자가 보호하는 배포입니다.

realm

Red Hat Single Sign-On 영역에 대한 구성. 이는 편의를 위해 제공됩니다. keycloak 클라이언트 어댑터에서 구성을 복사하여 여기에서 사용할 수 있습니다. 대신 공급자 를 사용하는 것이 좋습니다.

중요

현재 지원되지 않으므로 구성에 다음 공급자,realm, secure-deployment 속성을 사용하지 마십시오.

  • autodetect-bearer-only
  • bearer-only

현재 지원되지 않으므로 구성에서 다음 secure-deployment 속성을 사용하지 마십시오.

  • enable-basic-auth

다음 목적을 위해 세 가지 elytron-oidc-client 속성을 사용합니다.

  • provider: OpenID Connect 공급자를 구성하는 데 사용됩니다. 자세한 내용은 공급자 특성을 참조하십시오.
  • secure-deployment: OpenID Connect에 의해 보안된 배포를 구성하는 데 사용됩니다. 자세한 내용은 secure-deployment 특성을참조하십시오.
  • realm: Red Hat Single Sign-On을 구성하는 데 사용됩니다. 자세한 내용은 영역 특성을 참조하십시오. 영역 사용은 권장되지 않습니다. 편의를 위해 제공됩니다. keycloak 클라이언트 어댑터에서 구성을 복사하여 여기에서 사용할 수 있습니다. 대신 provider 특성을 사용하는 것이 좋습니다.
표 11.8. 공급자 속성
속성기본값설명

allow-any-hostname

false

값을 true 로 설정하면 OpenID 공급자와 통신할 때 호스트 이름 확인을 건너뜁니다. 이 기능은 테스트할 때 유용합니다. 프로덕션 환경에서 이를 셰이 으로 설정하지 마십시오.

always-refresh-token

 

true 로 설정하면 JBoss EAP가 모든 웹 요청에서 토큰을 새로 고칩니다.

auth-server-url

 

Red Hat Single Sign-On 영역 권한 부여 서버의 기본 URL입니다. 이 속성을 사용하는 경우 realm 속성도 정의해야 합니다.

또는 provider-url 특성을 사용하여 단일 특성에 기본 URL과 영역을 모두 제공할 수 있습니다.

client-id

 

OpenID 공급자에 등록된 JBoss EAP의 클라이언트 ID입니다.

client-key-password

 

client-keystore 를 지정하는 경우 이 속성에서 암호를 지정합니다.

client-keystore

 

애플리케이션이 HTTPS를 통해 OpenID 공급자와 통신하는 경우 이 속성의 클라이언트 키 저장소 경로를 설정합니다.

client-keystore-password

 

클라이언트 키 저장소를 지정하는 경우 이 속성에서 액세스하기 위한 암호를 제공합니다.

confidential-port

8443

OpenID 공급자가 사용하는 기밀 포트(SSL/TLS)를 지정합니다.

connection-pool-size

 

OpenID 공급자와 통신할 때 사용할 연결 풀 크기를 지정합니다.

connection-timeout-millis

 

원격 호스트와의 연결을 밀리초 단위로 설정하기 위한 시간 제한을 지정합니다. 최소값은 -1L 이고 최대 2147483647L 입니다.-1L 은 값이 정의되지 않음을 나타냅니다. 기본값은 undefined입니다.

connection-ttl-millis

 

연결을 활성 상태로 유지하는 데 걸리는 시간(밀리초)을 지정합니다. 최소는 -1L 이고 최대 2147483647L 입니다. -1L 은 값이 정의되지 않음, 이는 기본값임을 나타냅니다.

CORS-allowed-headers

 

CORS(Cross-Origin Resource Sharing)가 활성화된 경우 Access-Control-Allow-Headers 헤더 값을 설정합니다. 쉼표로 구분된 문자열이어야 합니다. 이는 선택 사항입니다. 설정되지 않은 경우 이 헤더는 CORS 응답에서 반환되지 않습니다.

CORS-allowed-methods

 

CORS(Cross-Origin Resource Sharing)가 활성화된 경우 Access-Control-Allow-Methods 헤더 값을 설정합니다. 쉼표로 구분된 문자열이어야 합니다. 이는 선택 사항입니다. 설정되지 않은 경우 이 헤더는 CORS 응답에서 반환되지 않습니다.

CORS-exposed-headers

 

CORS가 활성화된 경우 Access-Control-Expose-Headers 헤더 값을 설정합니다. 쉼표로 구분된 문자열이어야 합니다. 이는 옵트인입니다. 설정되지 않은 경우 이 헤더는 CORS 응답에서 반환되지 않습니다.

CORS-max-age

 

CORS(Cross-Origin Resource Sharing) Max-Age 헤더 값을 설정합니다. 값은 -1L2147483647L 사이일 수 있습니다. 이 속성은 enable-corstrue 로 설정된 경우에만 적용됩니다.

disable-trust-manager

 

HTTPS를 통해 OpenID 공급자와 통신할 때 신뢰 관리자를 사용할지 여부를 지정합니다.

enable-cors

false

Red Hat Single Sign-On Cross-Origin Resource Sharing (CORS) 지원을 활성화합니다.

expose-token

false

true 로 설정하면 인증된 브라우저 클라이언트는 URL root/k_query_bearer_token 을 통해 JavaScript HTTP 호출을 통해 서명된 액세스 토큰을 가져올 수 있습니다. 이는 선택 사항입니다. 이는 Red Hat Single Sign-On에만 적용됩니다.

ignore-oauth-query-parameter

false

access_token에 대한 쿼리 매개변수 구문 분석을 비활성화합니다.

principal-attribute

 

ID 토큰에서 주체로 사용할 클레임 값을 지정합니다.

provider-url

 

OpenID 공급자 URL을 지정합니다.

proxy-url

 

HTTP 프록시를 사용하는 경우 HTTP 프록시의 URL을 지정합니다.

realm-public-key

 

영역의 공개 키를 지정합니다.

register-node-at-startup

false

true 로 설정하면 등록 요청이 Red Hat Single Sign-On으로 전송됩니다. 이 속성은 애플리케이션이 클러스터형 경우에만 유용합니다.

register-node-period

 

노드를 다시 등록할 빈도를 지정합니다.

socket-timeout-millis

 

데이터를 기다리는 소켓 시간 제한을 밀리초 단위로 지정합니다.

SSL-필수

external

OpenID 공급자와의 통신이 HTTPS를 사용해야 하는지 여부를 지정합니다. 값은 다음 중 하나일 수 있습니다.

  • 모든 - 모든 통신은 HTTPS를 통해 수행됩니다.
  • 외부 - 외부 클라이언트와의 통신만 HTTP를 통해 수행됩니다.
  • none - HTTP가 사용되지 않습니다.

token-signature-algorithm

RS256

OpenID 공급자가 사용하는 토큰 서명 알고리즘을 지정합니다. 지원되는 알고리즘은 다음과 같습니다.

  • RS256
  • RS384
  • RS512
  • ES256
  • ES384
  • ES512

token-store

 

인증 세션 데이터의 쿠키 또는 세션 스토리지를 지정합니다.

truststore

 

클라이언트 HTTPS 요청에 사용되는 truststore를 지정합니다.

truststore-password

 

truststore 암호를 지정합니다.

verify-token-audience

false

true 로 설정하면 전달자 전용 인증 중에 토큰에 이 클라이언트 이름(리소스)이 대상자로 포함되어 있는지 확인합니다.

표 11.9. secure-deployment 속성
속성기본값설명

allow-any-hostname

false

값을 true 로 설정하면 OpenID 공급자와 통신할 때 호스트 이름 확인을 건너뜁니다. 이 기능은 테스트할 때 유용합니다. 프로덕션 환경에서 이를 셰이 으로 설정하지 마십시오.

always-refresh-token

 

true 로 설정하면 JBoss EAP가 모든 웹 요청에서 토큰을 새로 고칩니다.

auth-server-url

 

Red Hat Single Sign-On 영역 인증 서버의 기본 URL입니다. 또는 provider-url 특성을 사용할 수 있습니다.

client-id

 

OpenID 공급자에 등록된 JBoss EAP의 클라이언트 ID입니다.

client-key-password

 

client-keystore 를 지정하는 경우 이 속성에서 암호를 지정합니다.

client-keystore

 

애플리케이션이 HTTPS를 통해 OpenID 공급자와 통신하는 경우 이 속성의 클라이언트 키 저장소 경로를 설정합니다.

client-keystore-password

 

클라이언트 키 저장소를 지정하는 경우 이 속성에서 액세스하기 위한 암호를 제공합니다.

confidential-port

8443

OpenID 공급자가 사용하는 기밀 포트(SSL/TLS)를 지정합니다.

connection-pool-size

 

OpenID 공급자와 통신할 때 사용할 연결 풀 크기를 지정합니다.

connection-timeout-millis

 

원격 호스트와의 연결을 밀리초 단위로 설정하기 위한 시간 제한을 지정합니다. 최소는 -1L 이고 최대 2147483647L 입니다. -1L 은 값이 정의되지 않음, 이는 기본값임을 나타냅니다.

connection-ttl-millis

 

연결을 활성 상태로 유지하는 데 걸리는 시간(밀리초)을 지정합니다. 최소값은 -1L 이고 최대 2147483647L 입니다. -1L은 값이 정의되지 않음을 나타냅니다. 기본값은 undefined입니다.

CORS-allowed-headers

 

CORS(Cross-Origin Resource Sharing)가 활성화된 경우 Access-Control-Allow-Headers 헤더 값을 설정합니다. 쉼표로 구분된 문자열이어야 합니다. 이는 선택 사항입니다. 설정되지 않은 경우 이 헤더는 CORS 응답에서 반환되지 않습니다.

CORS-allowed-methods

 

CORS(Cross-Origin Resource Sharing)가 활성화된 경우 Access-Control-Allow-Methods 헤더 값을 설정합니다. 쉼표로 구분된 문자열이어야 합니다. 이는 선택 사항입니다. 설정되지 않은 경우 이 헤더는 CORS 응답에서 반환되지 않습니다.

CORS-exposed-headers

 

CORS(Cross-Origin Resource Sharing)가 활성화된 경우 Access-Control-Expose-Headers 헤더 값을 설정합니다. 쉼표로 구분된 문자열이어야 합니다. 이는 선택 사항입니다. 설정되지 않은 경우 이 헤더는 CORS 응답에서 반환되지 않습니다.

CORS-max-age

 

CORS(Cross-Origin Resource Sharing) Max-Age 헤더 값을 설정합니다. 값은 -1L2147483647L 사이일 수 있습니다. 이 속성은 'enable-인 경우에만 적용됩니다.

인증 정보

 

OpenID 공급자와 통신하는 데 사용할 인증 정보를 지정합니다.

disable-trust-manager

 

HTTPS를 통해 OpenID 공급자와 통신할 때 신뢰 관리자를 사용할지 여부를 지정합니다.

enable-cors

false

Red Hat Single Sign-On Cross-Origin Resource Sharing (CORS) 지원을 활성화합니다.

expose-token

false

true 로 설정하면 인증된 브라우저 클라이언트는 URL root/k_query_bearer_token 을 통해 JavaScript HTTP 호출을 통해 서명된 액세스 토큰을 가져올 수 있습니다. 이는 선택 사항입니다. 이는 Red Hat Single Sign-On에 따라 다릅니다.

ignore-oauth-query-parameter

false

access_token에 대한 쿼리 매개변수 구문 분석을 비활성화합니다.

min-time- betweenween-jwks-requests

 

어댑터가 알 수 없는 공개 키로 서명된 토큰을 인식하는 경우 JBoss EAP는 elytron-oidc-client 서버에서 새 공개 키를 다운로드하려고 합니다. 그러나 이 속성에 설정한 값(초)보다 적은 시간 내에 이미 시도한 경우 JBoss EAP가 새 공개 키를 다운로드하려고 시도하지 않습니다. 값은 -1L2147483647L 사이일 수 있습니다.

principal-attribute

 

ID 토큰에서 주체로 사용할 클레임 값을 지정합니다.

provider

 

OpenID 공급자를 지정합니다.

provider-url

 

OpenID 공급자 URL을 지정합니다.

proxy-url

 

HTTP 프록시를 사용하는 경우 HTTP 프록시의 URL을 지정합니다.

public-client

false

true 로 설정하면 OpenID 공급자와 통신할 때 클라이언트 인증 정보가 전송되지 않습니다. 이는 선택 사항입니다.

realm

 

Red Hat Single Sign-On에서 연결할 영역입니다.

realm-public-key

 

영역의 공개 키를 지정합니다.

redirect-rewrite-rule

 

리디렉션 URI에 적용할 재작성 규칙을 지정합니다.

register-node-at-startup

false

true 로 설정하면 등록 요청이 Red Hat Single Sign-On으로 전송됩니다. 이 속성은 애플리케이션이 클러스터형 경우에만 유용합니다.

register-node-period

 

노드를 다시 등록할 빈도를 지정합니다.

resource

 

OIDC를 사용하여 보안하는 애플리케이션의 이름을 지정합니다. 또는 client-id 를 지정할 수 있습니다.

socket-timeout-millis

 

데이터를 기다리는 소켓 시간 제한을 밀리초 단위로 지정합니다.

SSL-필수

external

OpenID 공급자와의 통신이 HTTPS를 사용해야 하는지 여부를 지정합니다. 값은 다음 중 하나일 수 있습니다.

  • 모든 - 모든 통신은 HTTPS를 통해 수행됩니다.
  • 외부 - 외부 클라이언트와의 통신만 HTTP를 통해 수행됩니다.
  • none - HTTP가 사용되지 않습니다.

token-minimum-time-to-live

 

어댑터는 현재 토큰이 만료되거나 초 단위로 설정된 시간 내에 만료되는 경우 토큰을 새로 고칩니다.

token-signature-algorithm

RS256

OpenID 공급자가 사용하는 토큰 서명 알고리즘을 지정합니다. 지원되는 알고리즘은 다음과 같습니다.

  • RS256
  • RS384
  • RS512
  • ES256
  • ES384
  • ES512

token-store

 

인증 세션 데이터의 쿠키 또는 세션 스토리지를 지정합니다.

truststore

 

어댑터 클라이언트 HTTPS 요청에 사용되는 truststore를 지정합니다.

truststore-password

 

truststore 암호를 지정합니다.

turn-off-change-session-id-on-login

false

세션 ID는 로그인 성공 시 기본적으로 변경됩니다. 이 기능을 비활성화하려면 값을 true 로 설정합니다.

use-resource-role-mappings

false

토큰에서 가져온 리소스 수준 권한을 사용합니다.

verify-token-audience

false

true 로 설정된 경우 전달자 전용 인증 중에 어댑터는 토큰에 이 클라이언트 이름(리소스)이 대상자로 포함되어 있는지 확인합니다.

표 11.10. realm 속성
속성기본값설명

allow-any-hostname

false

값을 true 로 설정하면 OpenID 공급자와 통신할 때 호스트 이름 확인을 건너뜁니다. 이 기능은 테스트할 때 유용합니다. 프로덕션 환경에서 이를 셰이 으로 설정하지 마십시오.

always-refresh-token

 

true 로 설정하면 JBoss EAP가 모든 웹 요청에서 토큰을 새로 고칩니다.

auth-server-url

 

Red Hat Single Sign-On 영역 인증 서버의 기본 URL입니다. 또는 provider-url 특성을 사용할 수 있습니다.

client-key-password

 

client-keystore 를 지정하는 경우 이 속성에서 암호를 지정합니다.

client-keystore

 

애플리케이션이 HTTPS를 통해 OpenID 공급자와 통신하는 경우 이 속성의 클라이언트 키 저장소 경로를 설정합니다.

client-keystore-password

 

클라이언트 키 저장소를 지정하는 경우 이 속성에서 액세스하기 위한 암호를 제공합니다.

confidential-port

8443

Red Hat Single Sign-On에서 사용하는 기밀 포트(SSL/TLS)를 지정합니다.

connection-pool-size

 

Red Hat Single Sign-On과 통신할 때 사용할 연결 풀 크기를 지정합니다.

connection-timeout-millis

 

원격 호스트와의 연결을 밀리초 단위로 설정하기 위한 시간 제한을 지정합니다. 최소는 -1L 이고 최대 2147483647L 입니다. -1L 은 값이 정의되지 않음, 이는 기본값임을 나타냅니다.

connection-ttl-millis

 

연결을 활성 상태로 유지하는 데 걸리는 시간(밀리초)을 지정합니다. 최소는 -1L 이고 최대 2147483647L 입니다. -1L 은 값이 정의되지 않음, 이는 기본값임을 나타냅니다.

CORS-allowed-headers

 

CORS(Cross-Origin Resource Sharing)가 활성화된 경우 Access-Control-Allow-Headers 헤더 값을 설정합니다. 쉼표로 구분된 문자열이어야 합니다. 이는 선택 사항입니다. 설정되지 않은 경우 이 헤더는 CORS 응답에서 반환되지 않습니다.

CORS-allowed-methods

 

CORS(Cross-Origin Resource Sharing)가 활성화된 경우 Access-Control-Allow-Methods 헤더 값을 설정합니다. 쉼표로 구분된 문자열이어야 합니다. 이는 선택 사항입니다. 설정되지 않은 경우 이 헤더는 CORS 응답에서 반환되지 않습니다.

CORS-exposed-headers

 

CORS(Cross-Origin Resource Sharing)가 활성화된 경우 Access-Control-Expose-Headers 헤더 값을 설정합니다. 쉼표로 구분된 문자열이어야 합니다. 이는 선택 사항입니다. 설정되지 않은 경우 이 헤더는 CORS 응답에서 반환되지 않습니다.

CORS-max-age

 

CORS(Cross-Origin Resource Sharing) Max-Age 헤더 값을 설정합니다. 값은 -1L2147483647L 사이일 수 있습니다. 이 속성은 enable-corstrue 로 설정된 경우에만 적용됩니다.

disable-trust-manager

 

HTTPS를 통해 OpenID 공급자와 통신할 때 신뢰 관리자를 사용할지 여부를 지정합니다.

enable-cors

false

{RHProductShortName} CORS(Cross-Origin Resource Sharing) 지원을 활성화합니다.

expose-token

false

true 로 설정하면 인증된 브라우저 클라이언트는 URL root/k_query_bearer_token 을 통해 JavaScript HTTP 호출을 통해 서명된 액세스 토큰을 가져올 수 있습니다. 이는 선택 사항입니다.

ignore-oauth-query-parameter

false

access_token에 대한 쿼리 매개변수 구문 분석을 비활성화합니다.

principal-attribute

 

ID 토큰에서 주체로 사용할 클레임 값을 지정합니다.

provider-url

 

OpenID 공급자 URL을 지정합니다.

proxy-url

 

HTTP 프록시를 사용하는 경우 HTTP 프록시의 URL을 지정합니다.

realm-public-key

 

영역의 공개 키를 지정합니다.

register-node-at-startup

false

true 로 설정하면 등록 요청이 Red Hat Single Sign-On으로 전송됩니다. 이 속성은 애플리케이션이 클러스터형 경우에만 유용합니다.

register-node-period

 

노드를 다시 등록할 빈도를 지정합니다.

socket-timeout-millis

 

데이터를 기다리는 소켓 시간 제한을 밀리초 단위로 지정합니다.

SSL-필수

external

OpenID 공급자와의 통신이 HTTPS를 사용해야 하는지 여부를 지정합니다. 값은 다음 중 하나일 수 있습니다.

  • 모든 - 모든 통신은 HTTPS를 통해 수행됩니다.
  • 외부 - 외부 클라이언트와의 통신만 HTTP를 통해 수행됩니다.
  • none - HTTP가 사용되지 않습니다.

token-signature-algorithm

RS256

OpenID 공급자가 사용하는 토큰 서명 알고리즘을 지정합니다. 지원되는 알고리즘은 다음과 같습니다.

  • RS256
  • RS384
  • RS512
  • ES256
  • ES384
  • ES512

token-store

 

인증 세션 데이터의 쿠키 또는 세션 스토리지를 지정합니다.

truststore

 

클라이언트 HTTPS 요청에 사용되는 truststore를 지정합니다.

truststore-password

 

truststore 암호를 지정합니다.

verify-token-audience

false

true 로 설정된 경우 전달자 전용 인증 중에 어댑터는 토큰에 이 클라이언트 이름(리소스)이 대상자로 포함되어 있는지 확인합니다.

11.7. OpenTelemetry 참조

11.7.1. OpenTelemetry 하위 시스템 속성

opentelemetry 하위 시스템 속성을 수정하여 해당 동작을 구성할 수 있습니다. 속성은 내보내기, 샘플러 및 범위 프로세서의 구성 측면으로 그룹화됩니다.

표 11.11. 내보내기 속성 그룹
속성설명기본값

endpoint

OpenTelemetry가 추적을 푸시하는 URL입니다. 이 값을 내보내기가 수신 대기하는 URL로 설정합니다.

http://localhost:14250/

exporter-type

추적이 전송되는 내보내기입니다. 다음 중 하나일 수 있습니다.

  • Jaeger. 사용하는 내보내기는 Jaeger입니다.
  • otlp. 사용하는 내보내기는 OpenTelemetry 프로토콜과 함께 작동합니다.

jaeger

표 11.12. 샘플러 속성 그룹
속성설명기본값

내보낼 추적의 비율입니다. 값은 0.0 에서 1.0 사이여야 합니다. 예를 들어 애플리케이션에서 생성한 100개 추적에서 하나의 추적을 내보내려면 값을 0.01 로 설정합니다. 이 속성은 특성 sampler-typeratio 로 설정한 경우에만 적용됩니다.

 

표 11.13. 프로세서 특성 그룹 범위
속성설명기본값

batch-delay

JBoss EAP가 연속적으로 두 번 내보내는 간격(밀리초)입니다. 이 속성은 특성 span-processor-type일괄 로 설정한 경우에만 적용됩니다.

5000

export-timeout

취소되기 전에 내보내기를 완료할 수 있는 최대 시간(밀리초)입니다.

30000

max-export-batch-size

각 배치에 게시된 최대 추적 수입니다. 이 수는 max-queue-size 값보다 작거나 같아야 합니다. 특성 span-processor-type일괄 로 설정한 경우에만 이 속성을 설정할 수 있습니다.

512

max-queue-size

내보내기 전에 대기열에 추가할 최대 추적 수입니다. 애플리케이션에서 더 많은 추적을 생성하면 기록되지 않습니다. 이 속성은 특성 span-processor-type일괄 로 설정한 경우에만 적용됩니다.

2048

span-processor-type

사용할 범위 프로세서 유형입니다. 값은 다음 중 하나일 수 있습니다.

  • batch: JBoss EAP는 다음 특성을 사용하여 정의된 일괄 처리로 추적을 내보냅니다.

    • batch-delay
    • max-export-batch-size
    • max-queue-size
  • 단순: JBoss EAP 내보내기 추적은 완료되는 즉시 수행됩니다.

batch

추가 리소스

법적 공지

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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.