구성 가이드
애플리케이션 및 서비스 실행을 포함한 Red Hat JBoss Enterprise Application Platform의 설정 및 유지 관리 지침.
초록
JBoss EAP 문서에 대한 피드백 제공
오류를 보고하거나 문서를 개선하기 위해 Red Hat Jira 계정에 로그인하여 문제를 제출하십시오. Red Hat Jira 계정이 없는 경우 계정을 생성하라는 메시지가 표시됩니다.
절차
- 티켓을 생성하려면 다음 링크를 클릭하십시오.
- 문서 URL, 섹션 번호 를 포함하고 문제를 설명하십시오.
- 요약 에 문제에 대한 간략한 설명을 입력합니다.
- 설명에서 문제 또는 개선 사항에 대한 자세한 설명을 제공합니다. 문서에서 문제가 발생한 위치에 URL을 포함합니다.
- Submit 을 클릭하고 문제를 적절한 문서 팀으로 라우팅합니다.
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
1장. 소개
이 가이드를 사용하여 JBoss EAP를 구성하기 전에 최신 버전의 JBoss EAP가 다운로드 및 설치된 것으로 간주됩니다. 설치 지침은 JBoss EAP 설치 가이드를 참조하십시오.
JBoss EAP의 설치 위치는 호스트 시스템마다 다르므로 이 가이드는 설치 위치를 EAP_HOME
으로 나타냅니다. 관리 작업을 수행할 때 EAP _HOME 대신 JBoss EAP
설치의 실제 위치를 사용해야 합니다.
2장. JBoss EAP 시작 및 중지
2.1. JBoss EAP 시작
JBoss EAP는 Red Hat Enterprise Linux, Windows Server 및 Oracle Solaris에서 지원되며 독립 실행형 서버 또는 관리형 도메인 운영 모드에서 실행됩니다. JBoss EAP를 시작하는 특정 명령은 기본 플랫폼과 원하는 운영 모드에 따라 다릅니다.
서버는 처음에 일시 중단 상태로 시작되며 필요한 모든 서비스가 시작될 때까지 요청을 수락하지 않으며 서버가 정상 실행 상태에 배치되고 요청 수락을 시작할 수 있습니다.
독립 실행형 서버로 JBoss EAP 시작
$ EAP_HOME/bin/standalone.sh
Windows Server의 경우 EAP_HOME\bin\standalone.bat
스크립트를 사용합니다.
이 시작 스크립트는 EAP_HOME/bin/standalone.conf
파일 또는 Windows Server용 standalone.conf.bat
를 사용하여 JVM 옵션과 같은 일부 기본 기본 설정을 설정합니다. 이 파일에서 설정을 사용자 지정할 수 있습니다.
JBoss EAP는 기본적으로 standalone.xml
구성 파일을 사용하지만 다른 파일을 사용하여 시작할 수 있습니다. 사용 가능한 독립 실행형 구성 파일과 사용하는 방법에 대한 자세한 내용은 독립 실행형 서버 구성 파일 섹션을 참조하십시오.
사용 가능한 모든 시작 스크립트 인수와 해당 용도의 전체 목록은 --help
인수를 사용하거나 Server 런타임 인수 및 switch 섹션을 참조하십시오.
관리형 도메인에서 JBoss EAP 시작
도메인 컨트롤러는 도메인의 서버 그룹에 있는 서버보다 먼저 시작해야 합니다. 이 스크립트를 사용하여 먼저 도메인 컨트롤러를 시작한 다음 연결된 각 호스트 컨트롤러에 대해 도메인 컨트롤러를 시작합니다.
$ EAP_HOME/bin/domain.sh
Windows Server의 경우 EAP_HOME\bin\domain.bat
스크립트를 사용합니다.
이 시작 스크립트는 EAP_HOME/bin/domain.conf
파일 또는 Windows Server용 domain.conf.bat
를 사용하여 JVM 옵션과 같은 일부 기본 기본 설정을 설정합니다. 이 파일에서 설정을 사용자 지정할 수 있습니다.
JBoss EAP는 기본적으로 host.xml
호스트 구성 파일을 사용하지만 다른 호스트 구성 파일을 사용할 수 있습니다. 사용 가능한 관리형 도메인 구성 파일 및 사용 방법에 대한 자세한 내용은 관리형 도메인 구성 파일 섹션을 참조하십시오.
관리형 도메인을 설정할 때 추가 인수를 시작 스크립트로 전달해야 합니다. 사용 가능한 모든 시작 스크립트 인수와 해당 용도의 전체 목록은 --help
인수를 사용하거나 Server 런타임 인수 및 switch 섹션을 참조하십시오.
2.2. JBoss EAP 중지
JBoss EAP를 중지하는 방법은 시작 방법에 따라 다릅니다.
JBoss EAP의 대화형 인스턴스 중지
JBoss EAP가 시작된 터미널에서 Ctrl+C
를 누릅니다.
JBoss EAP의 배경 인스턴스 중지
관리 CLI를 사용하여 실행 중인 인스턴스에 연결하고 서버를 종료합니다.
관리 CLI를 시작합니다.
$ EAP_HOME/bin/jboss-cli.sh --connect
shutdown
명령을 실행합니다.shutdown
관리형 도메인에서 실행하는 경우 shutdown
명령에 --host
인수를 사용하여 종료할 호스트 이름을 지정해야 합니다.
2.3. 관리자 전용 모드에서 JBoss EAP 실행
JBoss EAP에는 관리자 전용 모드에서 시작할 수 있는 기능이 있습니다. 이를 통해 JBoss EAP는 관리 요청을 실행하고 수락할 수 있지만 다른 런타임 서비스를 시작하거나 최종 사용자 요청을 수락하지 않습니다. 관리 전용 모드는 관리형 도메인 은 물론 독립 실행형 서버에서 모두 사용할 수 있습니다.
관리자 전용 모드에서 독립 실행형 서버 실행
관리자 전용 모드에서 서버 시작
관리자 전용 모드에서 JBoss EAP 인스턴스를 시작하려면 JBoss EAP 인스턴스를 시작할 때 --start-mode=admin-only
런타임 인수를 사용합니다.
$ EAP_HOME/bin/standalone.sh --start-mode=admin-only
서버가 관리 전용 모드에서 실행중인 경우 확인
다음 명령을 사용하여 서버의 실행 모드를 확인합니다. 서버가 관리 전용 모드로 실행 중인 경우 결과는 ADMIN_ONLY
가 됩니다.
:read-attribute(name=running-mode) { "outcome" => "success", "result" => "ADMIN_ONLY" }
또한 다음 명령을 사용하여 JBoss EAP가 시작된 초기 실행 모드를 확인할 수 있습니다.
/core-service=server-environment:read-attribute(name=initial-running-mode)
관리 CLI에서 다른 모드로 다시 로드
다른 런타임 스위치로 JBoss EAP 인스턴스를 중지하고 시작하는 것 외에도 관리 CLI를 사용하여 다른 모드로 다시 로드할 수도 있습니다.
서버를 관리자 전용 모드로 다시 로드하려면 다음을 수행합니다.
reload --start-mode=admin-only
서버를 일반 모드에서 다시 로드하려면 다음을 수행합니다.
reload --start-mode=normal
서버가 admin-only 모드에서 시작되었고 --start-mode
인수가 reload
명령에 지정되지 않은 경우 서버가 일반 모드에서 시작됩니다.
관리자 전용 모드에서 관리형 도메인 실행
관리형 도메인에서 도메인 컨트롤러가 관리자 전용 모드에서 시작되는 경우 슬레이브 호스트 컨트롤러에서 수신되는 연결을 허용하지 않습니다.
관리자 전용 모드에서 호스트 컨트롤러 시작
admin -only
런타임 인수에서 admin 전용 모드로 호스트 컨트롤러를 시작합니다.
$ EAP_HOME/bin/domain.sh --admin-only
호스트 컨트롤러가 관리 전용 모드에서 실행 중이면 확인
다음 명령을 사용하여 호스트 컨트롤러의 실행 모드를 확인합니다. 호스트 컨트롤러가 관리 전용 모드로 실행되는 경우 결과는 ADMIN_ONLY
가 됩니다.
/host=HOST_NAME:read-attribute(name=running-mode)
{
"outcome" => "success",
"result" => "ADMIN_ONLY"
}
관리 CLI에서 다른 모드로 다시 로드
다른 런타임 스위치로 호스트 컨트롤러를 중지하고 시작하는 것 외에도 관리 CLI를 사용하여 다른 모드로 다시 로드할 수도 있습니다.
관리자 전용 모드에서 호스트 컨트롤러를 다시 로드하려면 다음을 수행합니다.
reload --host=HOST_NAME --admin-only=true
일반 모드에서 호스트 컨트롤러를 다시 로드하려면 다음을 수행합니다.
reload --host=HOST_NAME --admin-only=false
호스트 컨트롤러가 admin-only 모드에서 시작되었으며 --admin-only
인수가 reload
명령에 지정되지 않은 경우 호스트 컨트롤러가 일반 모드에서 시작됩니다.
2.4. 정상적으로 JBoss EAP 일시 중지 및 종료
JBoss EAP는 정상적으로 일시 중단하거나 종료할 수 있습니다. 이렇게 하면 새 요청을 수락하지 않고 활성 요청이 정상적으로 완료됩니다. timeout 값은 활성 요청이 완료될 때까지 일시 중지 또는 종료 작업이 기다리는 기간을 지정합니다. 서버가 일시 중단되었지만 관리 요청이 계속 처리됩니다.
정상 종료는 서버 전체 수준에서 조정되며, 대체로 요청이 서버에 진입하는 진입점에 중점을 둡니다. 다음 하위 시스템은 정상 종료를 지원합니다.
- Undertow
-
The
undertow
하위 시스템은 모든 요청이 완료될 때까지 기다립니다. - mod_cluster
-
modcluster
하위 시스템은 서버가PRE_SUSPEND
단계에서 일시 중단되고 있음을 로드 밸런서에 알립니다. ejb3
-
ejb3
하위 시스템은 모든 원격 Jakarta Enterprise Beans 요청 및 MDB 메시지 전달이 완료될 때까지 기다립니다.PRE_SUSPEND
단계에서 MDB로 전달이 중지됩니다. Jakarta Enterprise Beans 타이머가 일시 중단되고 서버를 다시 시작할 때 누락된 타이머가 활성화됩니다. - 트랜잭션
일시 중단되면 서버는 새 요청을 수락하지 않지만, 진행 중인 트랜잭션 및 요청이 완료될 때까지 또는 시간 초과 만료될 때까지 계속할 수 있습니다. 이는 XTS 트랜잭션과 연결된 웹 서비스 요청에도 적용됩니다.
참고기본적으로 트랜잭션 정상 종료는
ejb
하위 시스템에 대해 비활성화되어 있습니다. 서버가 Jakarta Enterprise Beans 관련 트랜잭션이 완료될 때까지 기다린 후 일시 중단하려면 트랜잭션 정상 종료를 활성화해야 합니다. 예를 들면 다음과 같습니다./subsystem=ejb3:write-attribute(name=enable-graceful-txn-shutdown,value=true)
- 자카르타 동시성
서버는 모든 활성 작업이 완료될 때까지 기다립니다. 대기 중인 모든 작업은 건너뜁니다. 현재 Jakarta Concurrency는 지속성이 없으므로 대기 중인 작업이 손실됩니다.
서버가 일시 중단된 상태이지만 예약된 작업은 예약된 시간에 계속 실행되지만
java.lang.IllegalStateException
이 발생합니다. 서버가 다시 시작되면 예약된 작업은 계속 정상적으로 실행되며, 대부분의 경우 작업을 다시 예약할 필요가 없습니다.- 배치
- 서버는 시간 초과 기간 내에 실행 중인 모든 작업을 중지하고 예약된 모든 작업을 지연시킵니다.
현재 정상적인 종료는 새로운 인바운드 자카르타 메시징 메시지를 거부하지 않습니다. 현재 진행 중으로 예정된 Jakarta Batch 작업 및 자카르타 동시성 작업은 현재 진행될 수 있지만, 실행 시 시간 초과 창을 통과하는 자카르타 동시성 작업을 제출했습니다.
요청은 request-controller
하위 시스템에서 추적합니다. 이 하위 시스템이 없으면 일시 중지 및 재개 기능이 매우 제한되고 서버가 일시 중지되거나 종료되기 전에 서버가 완료될 때까지 기다리지 않습니다. 그러나 이 기능이 필요하지 않으면 요청-컨트롤러
하위 시스템은 작은 성능 개선을 위해 제거될 수 있습니다.
2.4.1. 서버 일시 중지
JBoss EAP 7은 서버 작업을 정상적으로 일시 중단하는 일시 중단 모드를 도입했습니다. 이렇게 하면 모든 활성 요청이 정상적으로 완료되지만 새 요청은 허용하지 않습니다. 서버가 일시 중단되면 종료하거나 실행 중 상태로 되돌리거나 일시 중단된 상태로 유지 관리를 수행할 수 있습니다.
관리 인터페이스는 서버를 일시 중단하여 영향을 받지 않습니다.
관리 콘솔 또는 관리 CLI를 사용하여 서버를 일시 중단하고 다시 시작할 수 있습니다.
서버 일시 중단 상태 확인
서버 일시 중단 상태는 다음 관리 CLI 명령을 사용하여 볼 수 있습니다. 결과 값은 RUNNING
,PRE_SUSPEND,
중 하나입니다.
SUSPEND
ING 또는 SUSP
ENDED
독립 실행형 서버에 대한 일시 중단 상태를 확인합니다.
:read-attribute(name=suspend-state)
관리형 도메인에서 서버의 일시 중단 상태를 확인합니다.
/host=master/server=server-one:read-attribute(name=suspend-state)
일시 중지
다음 관리 CLI 명령을 사용하여 활성 요청이 완료될 때까지 기다리는 시간 제한 값(초)을 지정하여 서버를 일시 중지합니다. 기본값은 0
이며 즉시 일시 중단됩니다. 값 -1
은 서버가 모든 활성 요청이 완료될 때까지 무기한 대기하게 됩니다.
각 예제는 일시 중단 전에 요청이 완료될 때까지 최대 60초 동안 기다립니다.
독립 실행형 서버를 일시 중지합니다.
:suspend(suspend-timeout=60)
관리형 도메인에서 모든 서버를 일시 중단합니다.
:suspend-servers(suspend-timeout=60)
관리형 도메인에서 단일 서버를 일시 중단합니다.
/host=master/server-config=server-one:suspend(suspend-timeout=60)
서버 그룹에 있는 모든 서버를 일시 중단합니다.
/server-group=main-server-group:suspend-servers(suspend-timeout=60)
호스트 수준에서 모든 서버를 일시 중단합니다.
/host=master:suspend-servers(suspend-timeout=60)
재개
resume
명령은 새 요청을 수락하기 위해 서버를 정상 실행 상태로 반환합니다. 호스트, 서버, 서버 그룹 또는 도메인 수준에서 명령을 시작할 수 있습니다. 예를 들면 다음과 같습니다.
:resume
일시 중단된 상태에서 서버 시작
서버를 일시 중단 상태로 시작하여 서버가 다시 시작될 때까지 요청을 수락하지 않도록 할 수 있습니다.
독립 실행형 서버를 일시 중단 상태로 시작하려면 JBoss EAP 인스턴스를 시작할 때
--start-mode=suspend
런타임 인수를 사용합니다.$ EAP_HOME/bin/standalone.sh --start-mode=suspend
관리형 도메인 서버를 일시 중단 상태로
시작하려면 start-mode=suspend
인수를 관리 CLI 명령에서start
작업에 전달합니다./host=HOST_NAME/server-config=SERVER_NAME:start(start-mode=suspend)
참고start-mode
인수를 서버의다시 로드
및재시작
작업에 전달할 수도 있습니다.관리형 도메인 서버 그룹의 모든 서버를 일시 중단 상태로 시작하려면 관리 CLI 명령에서
start-mode=suspend
인수를start-servers
작업에 전달합니다./server-group=SERVER_GROUP_NAME:start-servers(start-mode=suspend)
참고서버 그룹의
reload
인수를 전달할 수도 있습니다.-servers 및
moderestart-servers
작업에 start-
2.4.2. 관리 CLI를 사용하여 서버 종료
서버를 중지할 때 적절한 시간 초과 값을 지정하면 서버가 정상적으로 종료됩니다. 명령이 실행되면 서버가 일시 중지되고 종료하기 전에 모든 요청이 완료될 때까지 지정된 시간 초과까지 기다립니다.
다음 관리 CLI 명령을 사용하여 서버를 정상적으로 종료합니다. 활성 요청이 완료될 때까지 서버에서 대기할 시간 제한 값(초)을 지정합니다. 기본값은 0
이며, 서버를 즉시 종료합니다. 값 -1
로 인해 서버가 종료되기 전에 모든 활성 요청이 완료될 때까지 무기한 대기하게 됩니다.
각 예제는 종료하기 전에 요청이 완료될 때까지 최대 60초 동안 기다립니다.
독립 실행형 서버를 정상적으로 종료합니다.
shutdown --suspend-timeout=60
관리형 도메인에서 모든 서버를 정상적으로 중지합니다.
:stop-servers(suspend-timeout=60)
관리형 도메인에서 단일 서버를 정상적으로 중지합니다.
/host=master/server-config=server-one:stop(suspend-timeout=60)
서버 그룹의 모든 서버를 정상적으로 중지합니다.
/server-group=main-server-group:stop-servers(suspend-timeout=60)
호스트 컨트롤러와 관리하는 모든 서버를 종료합니다.
/host=master:shutdown(suspend-timeout=60)
참고suspend-timeout
특성은 호스트 컨트롤러 자체가 아닌 호스트 컨트롤러에서 관리하는 서버에만 적용됩니다.
2.4.3. OS 신호 사용 서버 종료
kill -15 PID
와 같은 OS TERM
신호를 보내 서버를 정상적으로 종료할 수 있습니다. 기본적으로 이 값은 관리 CLI의 shutdown --suspend-timeout=0 명령과
동일하므로 현재 처리 중인 요청을 즉시 종료합니다. 시간 제한은 서버가 종료되기 전에 요청이 완료될 때까지 대기할 최대 시간(초)을 나타내는 org.wildfly.sigterm.suspend.timeout
시스템 속성으로 구성할 수 있습니다. 값 -1
은 서버가 무기한 대기함을 나타냅니다.
관리형 도메인 OS 신호는 서버를 종료하는 데 사용해서는 안 됩니다. 대신 관리 CLI를 사용하고 호스트 컨트롤러 관리를 통해 서버를 종료 해야 합니다.
JVM이 신호 처리를 비활성화하도록 구성된 경우(예: -Xrs
java 인수가 JVM 옵션에 전달되었거나 전송된 신호가 전송된 신호가 아닌 경우) 신호 처리를 비활성화하도록 구성된 경우 OS 신호를 사용하는 정상 종료가 작동하지 않습니다(예: KILL
신호 전송).
2.5. JBoss EAP 시작 및 중지(RPM 설치)
JBoss EAP 시작 및 중지는 ZIP 또는 설치 프로그램 설치와 비교하여 RPM 설치에 따라 다릅니다.
2.5.1. JBoss EAP 시작(RPM 설치)
JBoss EAP의 RPM 설치를 시작하는 명령은 시작하려는 운영 모드, 독립 실행형 서버 또는 관리형 도메인 및 실행 중인 Red Hat Enterprise Linux 버전에 따라 달라집니다.
JBoss EAP를 독립 실행형 서버로 시작(RPM 설치)
Red Hat Enterprise Linux 6의 경우:
$ service eap7-standalone start
Red Hat Enterprise Linux 7 이상:
$ systemctl start eap7-standalone.service
이는 기본적으로 standalone.xml
구성 파일을 사용하여 JBoss EAP를 시작합니다. RPM 서비스 구성 파일에서 속성을 설정하여 다른 독립 실행형 서버 구성 파일로 JBoss EAP를 시작할 수 있습니다. 자세한 내용은 아래의 RPM 서비스 속성 구성 섹션을 참조하십시오.
관리형 도메인에서 JBoss EAP 시작(RPM 설치)
Red Hat Enterprise Linux 6의 경우:
$ service eap7-domain start
Red Hat Enterprise Linux 7 이상:
$ systemctl start eap7-domain.service
이는 기본적으로 host.xml
구성 파일을 사용하여 JBoss EAP를 시작합니다. RPM 서비스 구성 파일에서 속성을 설정하여 다른 관리형 도메인 구성 파일로 JBoss EAP를 시작할 수 있습니다. 자세한 내용은 아래의 RPM 서비스 속성 구성 섹션을 참조하십시오.
RPM 서비스 속성 구성
이 섹션에서는 JBoss EAP 설치를 위한 RPM 서비스 속성 및 기타 시작 옵션을 구성하는 방법을 보여줍니다. 구성 파일을 수정하기 전에 백업하는 것이 좋습니다.
RPM 설치에 사용 가능한 모든 시작 옵션 목록은 RPM 서비스 구성 속성 섹션을 참조하십시오.
Red Hat Enterprise Linux 7 이상에서는 systemd
를 사용하여 RPM 서비스 구성 파일이 로드되므로 변수 표현식은 확장되지 않습니다.
서버 구성 파일을 지정합니다.
독립 실행형 서버를 시작할 때
standalone.xml
파일은 기본적으로 사용됩니다. 관리형 도메인에서 실행하는 경우host.xml
파일은 기본적으로 사용됩니다. 적절한 RPM 구성 파일(예:eap7-standalone.conf
)에서WILDFLY_SERVER_CONFIG
속성을 설정하여 다른 구성 파일로 JBoss EAP를 시작할 수 있습니다.WILDFLY_SERVER_CONFIG=standalone-full.xml
특정 IP 주소에 바인딩합니다.
기본적으로 JBoss EAP RPM 설치는
0.0.0.0
에 바인딩됩니다. 적절한 RPM 구성 파일 (예:eap7-standalone.conf
)에서WILDFLY_BIND
속성을 설정하여 JBoss EAP를 특정 IP 주소에 바인딩할 수 있습니다.WILDFLY_BIND=192.168.0.1
참고관리 인터페이스를 특정 IP 주소에 바인딩하려면 다음 예에 표시된 대로 JBoss EAP 시작 구성 파일에서 구성할 수 있습니다.
JVM 옵션 또는 Java 속성을 설정합니다.
시작 구성 파일을 편집하여 JVM 옵션 또는 Java 속성을 지정하여 JBoss EAP 시작 스크립트에 전달할 수 있습니다. 이 파일은 독립 실행형
서버용 EAP_HOME/bin/standalone.conf
또는 관리형 도메인의EAP_HOME/bin/domain.conf
입니다. 아래 예제에서는 힙 크기를 구성하고 JBoss EAP 관리 인터페이스를 IP 주소에 바인딩합니다.JAVA_OPTS="$JAVA_OPTS -Xms2048m -Xmx2048m" JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address.management=192.168.0.1"
참고필요한 경우, 여기에서
jboss.bind.address
표준 속성을 사용하지 않고WILDFLY_BIND
속성을 사용하여 JBoss EAP 바인드 주소를 구성해야 합니다.
속성의 이름이 RPM 서비스 구성 파일(예: /etc/sysconfig/eap7-standalone
)과 JBoss EAP 시작 구성 파일(예: EAP_HOME/bin/standalone.conf
)에서 같은 이름이 있는 경우 우선 순위가 JBoss EAP 시작 구성 파일의 값입니다. 이러한 속성 중 하나는 JAVA_HOME
입니다.
2.5.2. JBoss EAP 중지(RPM 설치)
JBoss EAP의 RPM 설치를 중지하는 명령은 시작된 운영 모드, 독립 실행형 서버 또는 관리형 도메인 및 실행 중인 Red Hat Enterprise Linux 버전에 따라 달라집니다.
독립 실행형 서버로 JBoss EAP 중지(RPM 설치)
Red Hat Enterprise Linux 6의 경우:
$ service eap7-standalone stop
Red Hat Enterprise Linux 7 이상:
$ systemctl stop eap7-standalone.service
관리형 도메인에서 JBoss EAP 중지(RPM 설치)
Red Hat Enterprise Linux 6의 경우:
$ service eap7-domain stop
Red Hat Enterprise Linux 7 이상:
$ systemctl stop eap7-domain.service
RPM 설치에 사용할 수 있는 모든 시작 옵션 목록은 RPM 서비스 구성 파일 섹션을 참조하십시오.
2.6. PowerShell 스크립트 (Windows Server)
PowerShell 스크립트 컬렉션은 기술 프리뷰로만 제공됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
JBoss EAP에는 대부분의 JBoss EAP 관리 스크립트에 상응하는 PowerShell 스크립트가 포함되어 있습니다. 여기에는 Microsoft Windows Server에서 JBoss EAP를 시작하는 PowerShell 스크립트가 포함됩니다.
JBoss EAP PowerShell 스크립트는 테스트된 Windows Server 버전에서 실행되는 PowerShell 버전 2 이상에서 작동하도록 설계되었습니다.
JBoss EAP PowerShell 스크립트는 EAP_HOME\bin
에 있으며 JBoss EAP 배치 스크립트와 동일한 방식으로 사용됩니다.
예를 들어 standalone -full.xml 구성 파일로 독립 실행형
JBoss EAP 서버를 시작하려면 다음 PowerShell 명령을 사용합니다.
.\standalone.ps1 "-c=standalone-full.xml"
JBoss EAP PowerShell 스크립트의 인수는 따옴표로 묶어야 합니다.
3장. JBoss EAP 관리
JBoss EAP는 독립 실행형 서버 또는 관리형 도메인당 하나의 구성 파일과 함께 간소화된 구성을 사용합니다. 독립 실행형 서버의 기본 구성은 EAP_HOME/standalone/configuration/standalone.xml
파일에 저장되며 관리형 도메인의 기본 구성은 EAP_HOME/domain/configuration/domain.xml
파일에 저장됩니다. 또한 호스트 컨트롤러의 기본 구성은 EAP_HOME/domain/configuration/host.xml
파일에 저장됩니다.
JBoss EAP는 명령줄 관리 CLI, 웹 기반 관리 콘솔, Java API 또는 HTTP API를 사용하여 구성할 수 있습니다. 이러한 관리 인터페이스를 사용하여 변경한 내용은 자동으로 유지되며 XML 구성 파일은 관리 API에서 덮어씁니다. 관리 CLI 및 관리 콘솔은 선호되는 방법이므로 XML 구성 파일을 수동으로 편집하지 않는 것이 좋습니다.
3.1. 하위 시스템, 확장 프로그램 및 프로필 정보
JBoss EAP 기능의 다양한 측면은 다른 하위 시스템에서 구성됩니다. 예를 들어 애플리케이션 및 서버 로깅은 로깅
하위 시스템에서 구성됩니다.
확장 기능은 서버의 핵심 기능을 확장하는 모듈입니다. 확장 기능은 배포에 필요할 때 로드되며, 더 이상 필요하지 않은 경우 언로드됩니다. 확장 기능을 추가하고 제거하는 방법은 JBoss EAP Management CLI 가이드를 참조하십시오.
하위 시스템은 특정 확장에 대한 구성 옵션을 제공합니다. 사용 가능한 하위 시스템에 대한 자세한 내용은 JBoss EAP 하위 시스템 개요 를 참조하십시오.
하위 시스템 구성 컬렉션은 서버에 대한 요구 사항을 충족하도록 구성된 프로필을 구성합니다. 독립 실행형 서버에는 이름 없는 단일 프로필이 있습니다. 관리형 도메인은 도메인의 서버 그룹에서 사용할 많은 프로필을 정의할 수 있습니다.
관리 콘솔 또는 관리 CLI 사용
관리 콘솔과 관리 CLI는 모두 JBoss EAP 인스턴스의 구성을 업데이트하는 데 효과적이며 지원되는 방법입니다. 이 둘을 결정하는 것은 기본 설정의 문제입니다. 그래픽 웹 기반 인터페이스를 사용하려는 사용자는 관리 콘솔을 사용해야 합니다. 명령줄 인터페이스를 선호하는 사용자는 관리 CLI를 사용해야 합니다.
3.2. 사용자 관리
기본 JBoss EAP 구성은 사용자가 인증 없이도 로컬 호스트의 관리 CLI에 액세스할 수 있도록 로컬 인증을 제공합니다.
그러나 관리 CLI에 원격으로 액세스하거나 트래픽이 로컬 호스트에서 시작된 경우에도 원격 액세스로 간주되는 관리 콘솔을 사용하려는 경우 관리 사용자를 추가해야 합니다. 관리 사용자를 추가하기 전에 관리 콘솔에 액세스하려고 하면 오류 메시지가 표시됩니다.
그래픽 설치 프로그램을 사용하여 JBoss EAP를 설치한 경우 설치 프로세스 중에 관리 사용자가 생성됩니다.
이 가이드에서는 즉시 사용 가능한 인증을 위해 새 사용자를 속성 파일에 추가하기 위한 유틸리티인 추가 사용자 스크립트를
사용하여 JBoss EAP에 대한 간단한 사용자 관리에 대해 설명합니다.
LDAP 또는 RBAC(역할 기반 액세스 제어)와 같은 고급 인증 및 권한 부여 옵션은 JBoss EAP 보안 아키텍처 의 Core Management Authentication 섹션을 참조하십시오.
3.2.1. 관리 사용자 추가
add-user
유틸리티 스크립트를 실행하고 프롬프트를 따릅니다.$ EAP_HOME/bin/add-user.sh
참고Windows Server의 경우
EAP_HOME\bin\add-user.bat
스크립트를 사용합니다.ENTER를
눌러 기본 옵션a
를 선택하여 관리 사용자를 추가합니다.이 사용자는 ManagementRealm에 추가되며 관리 콘솔 또는 관리 CLI를 사용하여 관리 작업을 수행할 수 있는 권한이 부여됩니다. 다른 선택 사항인
b
는 애플리케이션에 사용되고 특정 권한을 제공하지 않는 사용자를 ApplicationRealm 에 추가합니다.원하는 사용자 이름과 암호를 입력합니다. 암호를 확인하라는 메시지가 표시됩니다.
참고사용자 이름에는 어떤 숫자와 순서에 관계없이 다음 문자만 사용할 수 있습니다.
- 영숫자 문자(a-z, A-Z, 0-9)
- 대시(-), 마침표(.), 쉼표(,), 기호(@)
- 백슬래시 (\)
- 같음 (=)
기본적으로 JBoss EAP는 취약한 암호를 허용하지만 경고를 발행합니다.
이 기본 동작 변경에 대한 자세한 내용은 Add-User Utility Password Restrictions 설정을 참조하십시오.
-
사용자가 속해 있는 쉼표로 구분된 그룹 목록을 입력합니다. 사용자가 어떤 그룹에도 속하지 않도록 하려면
ENTER를
눌러 비워 둡니다. -
정보를 검토하고
yes
를 입력하여 확인합니다. 이 사용자가 원격 JBoss EAP 서버 인스턴스를 나타내는지 여부를 확인합니다. 기본 관리 사용자의 경우
no
를 입력합니다.ManagementRealm 에 추가해야 하는 한 가지 유형의 사용자는 JBoss EAP의 다른 인스턴스를 나타내는 사용자로서, 클러스터의 구성원으로 조인하도록 인증할 수 있어야 합니다. 이 경우 이 프롬프트에
yes
로 응답하고, 다른 구성 파일에 추가해야 하는 사용자의 암호를 나타내는 해시된 시크릿 값이 제공됩니다.
매개 변수를 add-user
스크립트에 전달하여 비대화형으로 사용자를 만들 수도 있습니다. 암호는 로그 및 기록 파일에 표시되므로 공유 시스템에서는 이 방법을 사용하지 않는 것이 좋습니다. 자세한 내용은 Add-User Utility Non-Interactively 에서 참조하십시오.
3.2.2. Add-User Utility를 비대화식으로 실행
명령줄에서 인수를 전달하여 add-user
스크립트를 비대화식으로 실행할 수 있습니다. 최소한 사용자 이름과 암호를 입력해야 합니다.
암호는 로그 및 기록 파일에 표시되므로 공유 시스템에서는 이 방법을 사용하지 않는 것이 좋습니다.
여러 그룹에 의존하는 사용자 만들기
다음 명령은 guest
및 mgmt
을 추가합니다.
group 그룹이 있는 관리 사용자mgmt
user1
$ EAP_HOME/bin/add-user.sh -u 'mgmtuser1' -p 'password1!' -g 'guest,mgmtgroup'
대체 속성 파일 지정
기본적으로 add-user
스크립트를 사용하여 생성된 사용자 및 그룹 정보는 서버 구성 디렉터리에 있는 속성 파일에 저장됩니다.
사용자 정보는 다음 속성 파일에 저장됩니다.
-
EAP_HOME/standalone/configuration/mgmt-users.properties
-
EAP_HOME/domain/configuration/mgmt-users.properties
그룹 정보는 다음 속성 파일에 저장됩니다.
-
EAP_HOME/standalone/configuration/mgmt-groups.properties
-
EAP_HOME/domain/configuration/mgmt-groups.properties
이러한 기본 디렉터리 및 속성 파일 이름을 재정의할 수 있습니다. 다음 명령은 사용자 속성 파일에 다른 이름 및 위치를 지정하여 새 사용자를 추가합니다.
$ EAP_HOME/bin/add-user.sh -u 'mgmtuser2' -p 'password1!' -sc '/path/to/standaloneconfig/' -dc '/path/to/domainconfig/' -up 'newname.properties'
새 사용자가 /path/to / standaloneconfig/newname.properties 및 /path/to
이러한 파일이 이미 있어야 합니다. 그렇지 않으면 오류가 표시됩니다.
/domainconfig/newname.properties
에 있는 사용자 속성 파일에 추가되었습니다.
사용 가능한 모든 add-user
인수와 해당 용도의 전체 목록은 --help
인수를 사용하거나 Add-user 인수 섹션을 참조하십시오.
3.2.3. 추가 사용자 유틸리티 암호 제한
add-user
유틸리티 스크립트에 대한 암호 제한은 EAP_HOME/bin/add-user.properties
파일을 사용하여 구성할 수 있습니다.
add-user.properties
파일은 보호되지 않은 일반 텍스트 파일이며, 해당 콘텐츠에 대해 보장되지 않은 액세스를 방지하려면 보안을 설정해야 합니다.
의도하지 않은 암호를 설정하지 않도록 하려면 키보드의 시스템 키맵이 올바른지 확인합니다. 기본 시스템 키 맵은 en-qwerty
입니다. 이 기본 설정을 변경하고 새 암호를 생성하는 경우 암호가 SimplePasswordStrengthChecker
클래스에 있는 기준을 충족하는지 확인해야 합니다.
기본적으로 JBoss EAP는 취약한 암호를 허용하지만 경고를 발행합니다. 지정된 최소 요구 사항을 충족하지 않는 암호를 거부하려면 password.restriction
속성을 REJECT
로 설정합니다.
다음 표에서는 EAP_HOME/bin/add-user.properties 파일에서 구성할 수 있는 추가 암호 요구 사항 설정을 설명합니다.
표 3.1. 추가 암호 요구 사항 설정
속성 | 설명 |
---|---|
|
암호에 대한 최소 문자 수입니다. 예를 들어 |
| 암호가 유효하도록 충족해야 하는 임계값을 설정합니다. 유효한 임계값 항목은 다음과 같습니다.
*
* 약함
*
* 강력
*
기본값은
알림: 임계값 값을 지정하지 않으면 |
|
암호에 설정된 최소 알파벳 문자 수입니다. 예를 들어 |
|
암호에 설정된 최소 숫자 수입니다. 예를 들어 |
|
암호에 설정된 최소 기호 수입니다. 예를 들어 |
|
사용자가 root 와 같이 쉽게 결정된 암호를 설정하지 못하도록 제한합니다. 예를 들어 |
|
사용자가 사용자 이름을 암호로 설정하지 못하도록 제한합니다. 예를 들어, |
추가 리소스
Red Hat 고객 포털에서 기본 시스템 설정 구성 가이드를 참조하십시오.
3.2.4. 관리 사용자 업데이트
메시지가 표시되면 사용자 이름을 입력하여 add-user
유틸리티 스크립트를 사용하여 기존 관리 사용자의 설정을 업데이트할 수 있습니다.
$ EAP_HOME/bin/add-user.sh
What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a): a
Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : test-user
User 'test-user' already exists and is enabled, would you like to...
a) Update the existing user password and roles
b) Disable the existing user
c) Type a new username
(a):
이미 존재하는 사용자 이름을 입력하면 몇 가지 옵션이 표시됩니다.
-
을
입력하여 기존 사용자의 암호를 업데이트합니다. -
b
를 입력하여 기존 사용자를 비활성화합니다. -
c
를 입력하여 새 사용자 이름을 입력합니다.
add-user
스크립트를 사용하여 사용자를 비대화식으로 업데이트하면 확인 프롬프트 없이 사용자가 자동으로 업데이트됩니다.
3.3. JBoss EAP Server 구성 최적화
JBoss EAP 서버를 설치하고 관리 사용자를 생성하면 서버 구성을 최적화할 수 있습니다.
성능 튜닝 가이드 의 정보를 검토하여 프로덕션 환경에 애플리케이션을 배포할 때 일반적인 문제를 방지하기 위해 서버 구성을 최적화하는 방법에 대한 정보를 확인하십시오. 일반적인 최적화에는 ulimit 설정, 가비지 컬렉션 활성화,Java 힙 덤프 생성, 스레드 풀 크기 조정 등이 있습니다.
또한 제품의 릴리스에 기존 패치를 적용하는 것이 좋습니다. EAP의 각 패치에는 수많은 버그 수정이 포함되어 있습니다. 자세한 내용은 JBoss EAP 패치 및 업그레이드 가이드에서 JBoss EAP 패치를 참조하십시오.
3.4. 관리 인터페이스
3.4.1. 관리 CLI
관리 CLI(명령줄 인터페이스)는 JBoss EAP를 위한 명령줄 관리 도구입니다.
관리 CLI를 사용하여 서버를 시작 및 중지하고, 애플리케이션을 배포 및 배포 취소, 시스템 설정을 구성하고, 다른 관리 작업을 수행합니다. 배치 모드에서 작업을 수행할 수 있으므로 여러 작업을 그룹으로 실행할 수 있습니다.
ls
,cd
, pwd
와 같은 많은 터미널 명령을 사용할 수 있습니다. 관리 CLI는 탭 완료도 지원합니다.
명령 및 작업, 구문 및 배치 모드에서 실행을 포함한 관리 CLI 사용에 대한 자세한 내용은 JBoss EAP 관리 CLI 가이드를 참조하십시오.
관리 CLI 시작
$ EAP_HOME/bin/jboss-cli.sh
Windows Server의 경우 EAP_HOME\bin\jboss-cli.bat
스크립트를 사용합니다.
실행 중인 서버에 연결
connect
또는 EAP_HOME/bin/jboss-cli.sh --connect
명령을 사용하여 관리 CLI를 시작하고 한 단계로 연결할 수 있습니다.
도움말 표시
일반적인 도움말에는 다음 명령을 사용합니다.
help
명령에 --help
플래그를 사용하여 해당 특정 명령을 사용하는 방법에 대한 지침을 받습니다. 예를 들어 deploy
를 사용하여 에 대한 정보를 받으려면 다음 명령이 실행됩니다.
deploy --help
관리 CLI 종료
quit
시스템 설정보기
다음 명령은 read-attribute
작업을 사용하여 예제 데이터 소스가 활성화되어 있는지 여부를 표시합니다.
/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled) { "outcome" => "success", "result" => true }
관리형 도메인에서 실행하는 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 업데이트할 프로필을 지정해야 합니다.
/profile=default/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)
시스템 설정 업데이트
다음 명령은 write-attribute
작업을 사용하여 예제 데이터 소스를 비활성화합니다.
/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
서버 시작
관리형 도메인에서 실행할 때 관리 CLI를 사용하여 서버를 시작하고 중지할 수도 있습니다.
/host=HOST_NAME/server-config=server-one:start
3.4.2. 관리 콘솔
관리 콘솔은 JBoss EAP용 웹 기반 관리 도구입니다.
관리 콘솔을 사용하여 서버를 시작 및 중지하고, 애플리케이션을 배포 및 배포 취소하고, 시스템 설정을 조정하며, 서버 구성을 영구적으로 수정합니다. 관리 콘솔에는 현재 사용자가 변경한 경우 서버 인스턴스를 다시 시작하거나 다시 로드해야 하는 경우 실시간 알림과 함께 관리 작업을 수행할 수 있는 기능도 있습니다.
관리형 도메인에서 동일한 도메인의 서버 인스턴스 및 서버 그룹은 도메인 컨트롤러의 관리 콘솔에서 중앙에서 관리할 수 있습니다.
기본 관리 포트를 사용하여 로컬 호스트에서 실행되는 JBoss EAP 인스턴스의 경우 http://localhost:9990/console/index.html 의 웹 브라우저를 통해 관리 콘솔에 액세스할 수 있습니다. 관리 콘솔에 액세스할 수 있는 권한이 있는 사용자로 인증해야 합니다.
관리 콘솔은 JBoss EAP 독립 실행형 서버 또는 관리형 도메인을 탐색하고 관리하기 위해 다음 탭을 제공합니다.
- 홈
- 몇 가지 일반적인 구성 및 관리 작업을 수행하는 방법에 대해 알아봅니다. 둘러보기를 통해 JBoss EAP 관리 콘솔에 익숙해집니다.
- 배포
- 배포를 추가, 제거 및 활성화합니다. 관리형 도메인에서 서버 그룹에 배포를 할당합니다.
- 설정
- 웹 서비스, 메시징 또는 고가용성과 같은 기능을 제공하는 사용 가능한 하위 시스템을 구성합니다. 관리형 도메인에서 다른 하위 시스템 구성이 포함된 프로필을 관리합니다.
- 런타임
- 서버 상태, JVM 사용 및 서버 로그와 같은 런타임 정보를 확인합니다. 관리형 도메인에서 호스트, 서버 그룹 및 서버를 관리합니다.
- 패치 중
- 패치를 JBoss EAP 인스턴스에 적용합니다.
- 액세스 제어
- 역할 기반 액세스 제어를 사용할 때 사용자 및 그룹에 역할을 할당합니다.
3.4.2.1. 관리 콘솔에서 속성 업데이트
수정할 리소스에 대해 관리 콘솔의 해당 섹션으로 이동한 후 적절한 권한이 있는 한 해당 속성을 편집할 수 있습니다.
- Edit(편집) 링크를 클릭합니다.
원하는 대로 변경합니다.
필수 필드는 별표(*)로 표시됩니다. 도움말 링크를 클릭하여 특성 설명을 볼 수 있습니다.
참고특성 유형에 따라 입력 필드는 텍스트 필드, ON/OFF 필드 또는 드롭다운일 수 있습니다. 입력하는 일부 텍스트 필드에는 구성의 다른 항목의 값이 제안으로 표시될 수 있습니다.
- Save(저장 )를 클릭하여 변경 사항을 저장합니다.
필요한 경우 서버를 다시 로드하여 변경 사항을 적용합니다.
적용하기 위해 다시 로드해야 하는 변경 사항을 저장할 때 팝업 창이 표시됩니다. 독립 실행형 서버를 다시 로드하려면 팝업에서 Reload (다시 로드) 링크를 클릭합니다. 관리형 도메인에서 서버를 다시 로드하려면 Topology (토폴로지) 링크를 클릭하고 적절한 서버를 선택한 다음 Reload (다시 로드) 드롭 다운 옵션을 클릭합니다.
수행한 최근 구성 작업의 기록을 보려면 관리 콘솔의 오른쪽 상단에 있는 알림 아이콘을 클릭합니다.
3.4.2.2. 관리 콘솔 사용/비활성화
/core-service=management/management
도메인 모드의 마스터 호스트에 대해 -interface=http-interface 리소스의 console-enabled
부울 특성을 설정하여 관리 콘솔을 활성화하거나 비활성화할 수 있습니다./host=master/core-service=management/management-interface=http-interface
를 사용합니다.
예를 들어 다음을 활성화하려면 다음을 수행합니다.
/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=true)
예를 들어 비활성화하려면 다음을 수행합니다.
/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=false)
3.4.2.3. 관리 콘솔의 언어 변경
기본적으로 관리 콘솔의 언어 설정은 영어입니다. 대신 다음 언어 중 하나를 사용할 수 있습니다.
- 독일어 (de)
- 중국어 간체 (zh-Hans)
- 브라질 포르투갈어 (pt-BR)
- 프랑스어 (fr)
- 스페인어 (es)
- 일본어 (ja)
관리 콘솔의 언어 변경
- 관리 콘솔에 로그인합니다.
- 관리 콘솔의 오른쪽 아래에 있는 Settings (설정) 링크를 클릭합니다.
- Locale(로케일) 선택 상자에서 필수 언어를 선택합니다.
- 저장을 선택합니다. 확인 상자는 애플리케이션을 다시 로드해야 함을 알려줍니다.
- Yes 를 클릭합니다. 선택한 로케일을 사용하도록 웹 브라우저를 자동으로 새로 고칩니다.
3.4.2.4. 관리 콘솔 제목 사용자 정의
각 JBoss EAP 인스턴스를 빠르게 식별할 수 있도록 관리 콘솔 제목을 사용자 지정할 수 있습니다.
관리 콘솔 제목을 사용자 지정하려면 다음을 수행합니다.
- 관리 콘솔에 로그인합니다.
- 관리 콘솔의 오른쪽 아래에 있는 Settings (설정)를 클릭합니다.
- Settings(설정 ) 창에서 Title (제목) 필드에서 제목을 수정합니다.
저장을 클릭합니다.
확인 상자는 관리 콘솔을 다시 로드해야 함을 알려줍니다.
Yes 를 클릭합니다.
시스템은 웹 브라우저를 자동으로 새로 고치며 새 제목이 탭 헤더에 표시됩니다.
3.5. 관리 API
3.5.1. HTTP API
HTTP API 엔드포인트는 HTTP 프로토콜을 사용하여 JBoss EAP 관리 계층과 통합하는 관리 클라이언트의 진입점입니다.
HTTP API는 JBoss EAP 관리 콘솔에서 사용하지만 다른 클라이언트에도 통합 기능을 제공합니다. 기본적으로 HTTP API는 http://HOST_NAME:9990/management
에서 액세스할 수 있습니다. 이 URL은 API에 노출된 원시 속성과 값을 표시합니다.
리소스 읽기
HTTP POST
메서드를 사용하여 다른 작업을 읽고 쓰거나 수행할 수 있지만 GET
요청을 사용하여 일부 읽기 작업을 수행할 수 있습니다. HTTP GET
메서드는 다음 URL 형식을 사용합니다.
http://HOST_NAME:9990/management/PATH_TO_RESOURCE?operation=OPERATION&PARAMETER=VALUE
모든 교체된 값을 요청에 적합한 값으로 교체해야 합니다. 다음 값은 OPERATION
Elastic 값에 사용할 수 있는 옵션입니다.
현재의 | 설명 |
---|---|
attribute |
|
operations-description |
|
operation-names |
|
resource |
|
resource-description |
|
스냅샷 |
|
다음 예제 URL은 HTTP API를 사용하여 읽기 작업을 수행하는 방법을 보여줍니다.
예제: 리소스의 모든 속성 및 값 읽기
http://HOST_NAME:9990/management/subsystem/undertow/server/default-server/http-listener/default
그러면 기본
HTTP 리스너에 대한 모든 특성과 해당 값이 표시됩니다.
기본 작업은 read-resource
입니다.
예제: 리소스에 대한 속성의 값 읽기
http://HOST_NAME:9990/management/subsystem/datasources/data-source/ExampleDS?operation=attribute&name=enabled
ExampleDS
데이터 소스에 대해 enabled
속성의 값을 읽습니다.
리소스 업데이트
HTTP POST
메서드를 사용하여 구성 값을 업데이트하거나 HTTP API를 사용하여 다른 작업을 수행할 수 있습니다. 이러한 작업에 대한 인증을 제공해야 합니다.
다음 예제에서는 HTTP API를 사용하여 리소스를 업데이트하는 방법을 보여줍니다.
예제: 리소스에 대한 속성의 값 업데이트
$ curl --digest http://HOST_NAME:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"write-attribute", "address":["subsystem","datasources","data-source","ExampleDS"], "name":"enabled", "value":"false", "json.pretty":"1"}'
그러면 ExampleDS
데이터 소스에 대해 enabled
속성 값이 false
로 업데이트됩니다.
예제: 서버에 대한 작업 실행
$ curl --digest http://localhost:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"reload"}'
이렇게 하면 서버가 다시 로드됩니다.
HTTP API를 사용하여 JBoss EAP에 애플리케이션을 배포하는 방법에 대한 자세한 내용은 HTTP API를 사용하여 애플리케이션 배포를 참조하십시오.
3.5.1.1. 사용자 지정-constant HTTP 헤더
JBoss EAP의 HTTP 관리 엔드포인트는 클라이언트에 전송되는 모든 응답에 사전 정의된 HTTP 헤더 세트를 반환합니다. 사전 정의된 이 HTTP 헤더 세트 외에도 반환되는 사용자 지정 컨텍스트 HTTP 헤더를 정의할 수 있습니다.
JBoss EAP는 다음과 같이 요청에 사용자 지정 컨텍스트 HTTP 헤더를 적용합니다.
JBoss EAP는 요청 경로에 대해 구성된 접두사를 일치시켜 사용자 지정 컨텍스트 HTTP 헤더를 적용합니다.
예를 들어 custom-constant HTTP 헤더를
/ 또는 /
management
와 같은 요청 경로의 요청에 매핑할 수 있습니다.요청이 여러 접두사와 일치하는 경우 JBoss EAP는 모든 매핑에서 사용자 지정 컨텍스트 HTTP 헤더를 적용합니다.
예를 들어 경로
/management에 대한 요청은 / 및 /management
둘 다에 대한 매핑과
일치합니다.
JBoss EAP는 두 매핑의 헤더를 적용합니다.요청을 처리하기 종료할 때 응답이 해당 엔드포인트에서 설정한 헤더를 재정의하여 클라이언트로 돌아가기 전에 요청을 처리합니다.
예를 들어 관리 엔드포인트는 각 응답에
X-frame-Options
헤더를 설정합니다. 이름이X-frame-Options
인 사용자 지정 컨텍스트 HTTP 헤더를 정의하는 경우 custom-constant HTTP 헤더가 기본 헤더를 재정의합니다.
단일 매핑의 응답에서 반환할 여러 사용자 지정 컨텍스트 HTTP 헤더를 정의할 수 있습니다.
다음은 custom-constant HTTP 헤더를 정의하는 규칙입니다.
- custom-constant HTTP 헤더는 RFC-7231 - Hypertext Transfer Protocol(HTTP/1.1)에서 지원되는 문자만 포함할 수 있습니다. 의미 체계 및 콘텐츠.
사전 정의된 다음 HTTP 헤더를 재정의할 수 없습니다.
-
연결
-
컨텐츠-Length
-
content-Type
-
날짜
-
전송-인코딩
이러한 사전 정의된 헤더를 재정의하려고 하면 오류가 발생합니다.
예를 들어 이름이
Date
인 custom-constant HTTP 헤더를 설정하려고 하면 다음 오류가 반환됩니다.{ "outcome" => "failed", "failure-description" => "WFLYCTL0458:Disallowed HTTP Header name 'Date'", "rolled-back" => true }
-
맞춤형 HTTP 헤더를 생성할 때 고려해야 할 중요한 사항은 다음과 같습니다.
- JBoss EAP는 지정된 경로에 연결할 수 있는지 확인하지 않습니다.
- 하위 시스템은 HTTP 관리 인터페이스가 지원하는 컨텍스트를 동적으로 추가할 수 있습니다.
- 사용자 지정 일관성 HTTP 헤더는 엔드포인트가 요청에 대한 응답을 처리하는 방법을 변경하지 않습니다.
3.5.1.2. 사용자 정의-constant HTTP 헤더 정의
필요한 경로 접두사에 대한 요청에 대한 모든 응답에서 반환할 사용자 지정 일관성 HTTP 헤더를 정의합니다.
사용자 정의 일관성 HTTP 헤더를 생성하기 전에 다음 고려 사항을 이해해야 합니다.
- JBoss EAP는 지정된 경로에 연결할 수 있는지 확인하지 않습니다.
- 하위 시스템은 HTTP 관리 인터페이스가 지원하는 컨텍스트를 동적으로 추가할 수 있습니다.
- 사용자 지정 일관성 HTTP 헤더는 엔드포인트가 요청에 대한 응답을 처리하는 방법을 변경하지 않습니다.
절차
사용자 정의 일관성 HTTP 헤더를 정의합니다.
/core-service=management/management-interface=http-interface:write-attribute(name=constant-headers,value=[{path="PATH_PREFIX",headers=[{name="HEADER_NAME",value="HEADER_VALUE"}]}])
중요write-attribute
작업을 사용하면다시 로드해야 하는 프롬프트가 표시됩니다
.변경 사항을 적용하기 위해 서버를 다시 로드합니다.
reload
이제 HTTP 관리 인터페이스에 대한 요청은 사전 정의된 HTTP 헤더 세트 외에도 HEADER_VALUE 값이 있는 HTTP 헤더 HEADER_ NAME 을 반환합니다.
custom-constant HTTP 헤더 X-Help 예
/core-service=management/management-interface=http-interface:write-attribute(name=constant-headers,value=[{path="/",headers=[{name="X-Help",value="http://mywebsite.com/help"}]}])
검증 단계
HTTP 관리 인터페이스로 요청을 보냅니다.
$ curl -s -D - -o /dev/null --digest http://localhost:9990/management/ -u USERNAME:PASSWORD
예제 custom-constant HTTP 헤더
X-Help
에 대한 샘플 응답 :admin:redhat HTTP/1.1 200 OK Connection: keep-alive X-Frame-Options: SAMEORIGIN Content-Type: application/json; charset=utf-8 Content-Length: 3312 X-Help: http://mywebsite.com Date: Tue, 27 Oct 2020 08:13:17 GMT
응답에는
X-HELP
사용자 정의 일관성 HTTP 헤더가 포함됩니다.
3.5.1.3. 사용자 지정 컨텍스트 HTTP 헤더를 정의하는 CLI 명령
다음 CLI 명령은 독립 실행형 및 관리형 도메인 모드에서 사용자 지정 컨텍스트 HTTP 헤더를 정의합니다.
- 독립 실행형 모드
단일 사용자 지정 컨텍스트 HTTP 헤더를 정의하려면 다음 명령을 사용합니다.
/core-service=management/management-interface=http-interface:write-attribute(name=constant-headers,value=[{path=/PREFIX,headers=[{name=X-HEADER,value=HEADERVALUE}]}])
이 명령을 실행하면 다음과 같은 XML 구성이 생성됩니다.
<management-interfaces> <http-interface security-realm="ManagementRealm"> <http-upgrade enabled="true"/> <socket-binding http="management-http"/> <constant-headers> <header-mapping path="/PREFIX"> <header name="X-HEADER" value="HEADERVALUE"/> </header-mapping> </constant-headers> </http-interface> </management-interfaces>
여러 사용자 지정 컨텍스트 HTTP 헤더를 정의하려면 다음 명령을 사용합니다.
/core-service=management/management-interface=http-interface:write-attribute(name=constant-headers,value=[{path=/PREFIX1,headers=[{name=X-HEADER,value=HEADERVALUE-FOR-X}]},{path=/PREFIX2,headers=[{name=Y-HEADER,value=HEADERVALUE-FOR-Y}]}])
- 도메인 모드
단일 사용자 지정 컨텍스트 HTTP 헤더를 정의하려면 다음 명령을 사용합니다.
/host=master/core-service=management/management-interface=http-interface:write-attribute(name=constant-headers,value=[{path=/PREFIX,headers=[{name=X-HEADER,value=HEADER-VALUE}]}])
이 명령을 실행하면 다음과 같은 XML 구성이 생성됩니다.
<management-interfaces> <http-interface security-realm="ManagementRealm"> <http-upgrade enabled="true"/> <socket interface="management" port="${jboss.management.http.port:9990}"/> <constant-headers> <header-mapping path="/PREFIX"> <header name="X-HEADER" value="HEADER-VALUE"/> </header-mapping> </constant-headers> </http-interface> </management-interfaces>
여러 사용자 지정 컨텍스트 HTTP 헤더를 정의하려면 다음 명령을 사용합니다.
/host=master/core-service=management/management-interface=http-interface:write-attribute(name=constant-headers,value=[ {path=/PREFIX-1,headers=[{name=X-HEADER,value=HEADER-VALUE-FOR-X}]},{path=/PREFIX-2,headers=[{name=Y-HEADER,value=HEADER-VALUE-FOR-Y}]}])
3.5.2. 네이티브 API
네이티브 API 엔드포인트는 네이티브 프로토콜을 사용하여 JBoss EAP 관리 계층과 통합하는 관리 클라이언트의 진입점입니다. 기본 API는 JBoss EAP 관리 CLI에서 사용하지만 다른 클라이언트에도 통합 기능을 제공합니다.
다음 Java 코드는 네이티브 API를 사용하여 Java 코드에서 관리 작업을 실행하는 방법의 예를 보여줍니다.
EAP_HOME/bin/client/jboss-cli-client.jar
파일에 있는 필수 JBoss EAP 라이브러리를 클래스 경로에 추가해야 합니다.
예제: 네이티브 API를 사용하여 리소스 읽기
// Create the management client ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990); // Create the operation request ModelNode op = new ModelNode(); // Set the operation op.get("operation").set("read-resource"); // Set the address ModelNode address = op.get("address"); address.add("subsystem", "undertow"); address.add("server", "default-server"); address.add("http-listener", "default"); // Execute the operation and manipulate the result ModelNode returnVal = client.execute(op); System.out.println("Outcome: " + returnVal.get("outcome").toString()); System.out.println("Result: " + returnVal.get("result").toString()); // Close the client client.close();
3.6. 설정 데이터
3.6.1. 독립 실행형 서버 구성 파일
독립 실행형 구성 파일은 EAP_HOME/standalone/configuration/
디렉터리에 있습니다. 사전 정의된 5개의 프로필(기본값,ha, full,full -ha,load-balancer )마다 별도의 파일이 있습니다.
표 3.2. 독립 실행형 구성 파일
설정 파일 | 목적 |
---|---|
| 이 독립 실행형 구성 파일은 독립 실행형 서버를 시작할 때 사용되는 기본 구성입니다. 하위 시스템, 네트워킹, 배포, 소켓 바인딩 및 기타 구성 가능한 세부 정보를 포함하여 서버에 대한 모든 정보가 포함되어 있습니다. 메시징 또는 고가용성에 필요한 하위 시스템을 제공하지 않습니다. |
|
이 독립 실행형 구성 파일에는 모든 기본 하위 시스템이 포함되어 있으며 고가용성에 대해 |
|
이 독립 실행형 구성 파일에는 모든 기본 하위 시스템이 포함되어 있으며 |
| 이 독립 실행형 구성 파일에는 메시징 및 고가용성에 대한 시스템을 포함하여 가능한 모든 하위 시스템에 대한 지원이 포함되어 있습니다. |
| 이 독립 실행형 구성 파일에는 기본 제공 mod_cluster 프론트엔드 로드 밸런서 장치를 사용하여 다른 JBoss EAP 인스턴스의 부하를 분산하는 데 필요한 최소 하위 시스템이 포함되어 있습니다. |
기본적으로 JBoss EAP를 독립 실행형 서버로 시작하면 standalone.xml
파일을 사용합니다. 다른 구성으로 JBoss EAP를 시작하려면 --server-config
인수를 사용합니다. 예를 들면 다음과 같습니다.
$ EAP_HOME/bin/standalone.sh --server-config=standalone-full.xml
3.6.2. 관리형 도메인 구성 파일
관리형 도메인 구성 파일은 EAP_HOME/domain/configuration/
디렉터리에 있습니다.
표 3.3. 관리형 도메인 구성 파일
설정 파일 | 목적 |
---|---|
| 관리형 도메인의 기본 구성 파일입니다. 도메인 마스터만 이 파일을 읽습니다. 이 파일에는 모든 프로필(default,ha, full,full -ha,load-balancer )에 대한 구성이 포함되어 있습니다. |
|
이 파일에는 네트워크 인터페이스, 소켓 바인딩, 호스트 이름 및 기타 호스트별 세부 정보와 같이 관리형 도메인의 실제 호스트와 관련된 구성 세부 정보가 포함됩니다. |
| 이 파일에는 서버를 마스터 도메인 컨트롤러로 실행하는 데 필요한 구성 세부 사항만 포함되어 있습니다. |
| 이 파일에는 서버를 관리형 도메인 호스트 컨트롤러로 실행하는 데 필요한 구성 세부 정보만 포함되어 있습니다. |
기본적으로 관리형 도메인에서 JBoss EAP를 시작하면 host.xml
파일을 사용합니다. 다른 구성으로 JBoss EAP를 시작하려면 --host-config
인수를 사용합니다. 예를 들면 다음과 같습니다.
$ EAP_HOME/bin/domain.sh --host-config=host-master.xml
3.6.3. 구성 데이터 백업
JBoss EAP 서버 구성을 나중에 복원하려면 다음 위치에 있는 항목을 백업해야 합니다.
EAP_HOME/standalone/configuration/
- 독립 실행형 서버에 대한 사용자 데이터, 서버 구성 및 로깅 설정을 저장하도록 전체 디렉터리를 백업합니다.
EAP_HOME/domain/configuration/
- 전체 디렉터리를 백업하여 사용자 및 프로필 데이터, 도메인 및 호스트 구성, 관리형 도메인에 대한 로깅 설정을 저장합니다.
EAP_HOME/modules/
- 사용자 지정 모듈을 백업합니다.
EAP_HOME/welcome-content/
- 사용자 지정 환영 콘텐츠를 백업합니다.
EAP_HOME/bin/
- 사용자 지정 스크립트 또는 시작 구성 파일을 백업합니다.
3.6.4. 설정 파일 스냅 샷
서버 유지 관리 및 관리를 지원하기 위해 JBoss EAP는 시작 시 원본 구성 파일의 타임스탬프 버전을 생성합니다. 관리 작업에서 추가 구성을 변경하면 원본 파일이 자동으로 백업되고 참조 및 롤백을 위해 인스턴스의 작업 복사본이 보존됩니다. 또한 현재 서버 구성의 시점 사본인 구성 스냅샷을 만들 수도 있습니다. 이러한 스냅샷을 관리자가 저장하고 로드할 수 있습니다.
다음 예제에서는 standalone.xml
파일을 사용하지만 동일한 프로세스는 domain.xml 및
파일에 적용됩니다.
host.
xml
스냅샷 찍기
관리 CLI를 사용하여 현재 구성의 스냅샷을 만듭니다.
:take-snapshot
{
"outcome" => "success",
"result" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20151022-133109702standalone.xml"
}
스냅샷 나열
관리 CLI를 사용하여 생성된 모든 스냅샷을 나열합니다.
:list-snapshots
{
"outcome" => "success",
"result" => {
"directory" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
"names" => [
"20151022-133109702standalone.xml",
"20151022-132715958standalone.xml"
]
}
}
스냅샷 삭제
관리 CLI를 사용하여 스냅샷을 삭제합니다.
:delete-snapshot(name=20151022-133109702standalone.xml)
스냅샷으로 서버 시작
서버는 스냅샷 또는 자동 저장한 구성 버전을 사용하여 시작할 수 있습니다.
-
EAP_HOME/standalone/configuration/standalone_xml_history
디렉터리로 이동하여 로드할 스냅샷 또는 저장된 구성 파일을 식별합니다. 서버를 시작하고 선택한 구성 파일을 가리킵니다. 구성 디렉터리인
EAP_HOME/standalone/configuration/
을 기준으로 파일 경로를 전달합니다.$ EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20151022-133109702standalone.xml
관리형 도메인에서 실행하는 경우 대신 --host-config
인수를 사용하여 구성 파일을 지정합니다.
3.6.5. 구성 변경 사항보기
JBoss EAP 7은 실행 중인 시스템의 구성 변경 사항을 추적할 수 있는 기능을 제공합니다. 이를 통해 관리자는 다른 인증된 사용자가 변경한 구성 변경 내역을 볼 수 있습니다.
변경 사항은 메모리에 저장되며, 서버를 다시 시작하는 동안 유지되지 않습니다. 이 기능은 관리 감사 로깅 을 대체하지 않습니다.
관리 CLI 또는 관리 콘솔에서 추적을 활성화하고 구성 변경 사항을 볼 수 있습니다.
관리 CLI에서 구성 변경 사항 추적 및 보기
구성 변경 사항을 추적하려면 다음 관리 CLI 명령을 사용합니다. max-history
특성을 사용하여 저장할 항목 수를 지정할 수 있습니다.
/subsystem=core-management/service=configuration-changes:add(max-history=20)
관리형 도메인에서 호스트 및 서버 관련 수정을 위해 호스트 수준에서 구성 변경 사항을 추적합니다. 호스트 컨트롤러의 구성 변경 사항을 활성화하면 모든 관리 서버에서 사용할 수 있습니다. 다음 명령을 사용하여 호스트당 구성 변경 사항을 추적할 수 있습니다.
/host=HOST_NAME/subsystem=core-management/service=configuration-changes:add(max-history=20)
최신 구성 변경 사항 목록을 보려면 다음 관리 CLI 명령을 사용합니다.
/subsystem=core-management/service=configuration-changes:list-changes
관리형 도메인에서는 다음 명령을 사용하여 호스트의 구성 변경 사항을 나열할 수 있습니다.
/host=HOST_NAME/subsystem=core-management/service=configuration-changes:list-changes
다음 명령을 사용하여 특정 서버에 영향을 주는 구성 변경 사항을 나열할 수 있습니다.
/host=HOST_NAME/server=SERVER_NAME/subsystem=core-management/service=configuration-changes:list-changes
그러면 날짜, 원점, 결과 및 작업 세부 정보와 함께 수행된 각 구성 변경 사항이 나열됩니다. 예를 들어 list-changes
명령의 아래 출력은 구성 변경 사항을 표시하며 가장 최근에는 먼저 표시됩니다.
{ "outcome" => "success", "result" => [ { "operation-date" => "2016-02-12T18:37:00.354Z", "access-mechanism" => "NATIVE", "remote-address" => "127.0.0.1/127.0.0.1", "outcome" => "success", "operations" => [{ "address" => [], "operation" => "reload", "operation-headers" => { "caller-type" => "user", "access-mechanism" => "NATIVE" } }] }, { "operation-date" => "2016-02-12T18:34:16.859Z", "access-mechanism" => "NATIVE", "remote-address" => "127.0.0.1/127.0.0.1", "outcome" => "success", "operations" => [{ "address" => [ ("subsystem" => "datasources"), ("data-source" => "ExampleDS") ], "operation" => "write-attribute", "name" => "enabled", "value" => false, "operation-headers" => { "caller-type" => "user", "access-mechanism" => "NATIVE" } }] }, { "operation-date" => "2016-02-12T18:24:11.670Z", "access-mechanism" => "HTTP", "remote-address" => "127.0.0.1/127.0.0.1", "outcome" => "success", "operations" => [{ "operation" => "remove", "address" => [ ("subsystem" => "messaging-activemq"), ("server" => "default"), ("jms-queue" => "ExpiryQueue") ], "operation-headers" => {"access-mechanism" => "HTTP"} }] } ] }
이 예제에서는 구성에 영향을 주는 수행된 세 가지 작업의 세부 정보를 나열합니다.
- 관리 CLI에서 서버 다시 로드.
-
관리 CLI에서
ExampleDS
데이터 소스 비활성화. -
관리 콘솔에서
ExpiryQueue
큐 제거.
관리 콘솔에서 구성 변경 사항 추적 및 보기
관리 콘솔에서 구성 변경 사항을 추적할 수 있도록 Runtime(런타임 ) 탭으로 선택하고 서버 또는 호스트로 이동하여 변경 사항을 추적하고 드롭다운에서 Configuration Changes (구성 변경)를 선택합니다. Enable Configuration(구성 변경 사항 활성화)을 클릭하고 최대 기록 값을 제공합니다.
이 페이지의 테이블에는 날짜, 원점, 결과 및 운영 세부 정보와 함께 각 구성 변경 사항이 나열됩니다.
3.6.6. 속성 교체
JBoss EAP를 사용하면 표현식을 사용하여 구성에서 리터럴 값 대신 교체 가능한 속성을 정의할 수 있습니다. 표현식은 ${PARAMETER:DEFAULT_VALUE}
형식을 사용합니다. 지정된 매개 변수가 설정되면 매개 변수의 값이 사용됩니다. 그렇지 않으면 제공된 기본값이 사용됩니다.
표현식을 해결하는 데 지원되는 소스는 시스템 속성, 환경 변수 및 자격 증명 모음입니다. 배포 전용의 경우 소스는 배포 아카이브의 META-INF/jboss.properties
파일에 나열된 속성이 될 수 있습니다. 하위 배포를 지원하는 배포 유형의 경우 속성 파일이 외부 배포에 있는 경우(예: EAR) 모든 하위 배포로 해결 범위가 지정됩니다. 속성 파일이 하위 배포에 있는 경우 해결 범위는 해당 하위 배포로만 지정됩니다.
standalone.xml 구성 파일에서 아래 예제에서는
를 jboss.
bind. address 매개 변수를 설정하지 않는 한
address공용
인터페이스의 inet-127.0.0.1
로 설정합니다.
<interface name="public"> <inet-address value="${jboss.bind.address:127.0.0.1}"/> </interface>
jboss.bind.address
매개 변수는 다음 명령을 사용하여 EAP를 독립 실행형 서버로 시작할 때 설정할 수 있습니다.
$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS
중첩 표현식
표현식을 중첩하여 고정 값 대신 고급 표현식을 사용할 수 있습니다. 중첩된 식의 형식은 일반 표현식의 형식과 같지만 하나의 표현식은 다른 표현식에 포함됩니다. 예를 들면 다음과 같습니다.
${SYSTEM_VALUE_1${SYSTEM_VALUE_2}}
중첩된 식은 재귀적으로 평가되므로 내부 표현식을 먼저 평가한 다음 외부 표현식을 평가합니다. 표현식도 재귀적일 수 있습니다. 여기서 표현식은 다른 표현식으로 확인되므로 이 식이 해결됩니다. 관리 CLI 명령을 제외하고 표현식이 허용되는 모든 곳에 중첩된 표현식이 허용됩니다.
중첩 표현식을 사용할 수 있는 예제는 데이터 소스 정의에 사용된 암호가 마스킹되는 경우입니다. 데이터 소스의 구성에는 다음 행이 있을 수 있습니다.
<password>${VAULT::ds_ExampleDS::password::1}</password>
ds_ExampleDS
값은 중첩된 표현식을 사용하여 시스템 속성(datasource_name
)으로 바꿀 수 있습니다. 데이터 소스에 대한 구성은 대신 다음 행을 가질 수 있습니다.
<password>${VAULT::${datasource_name}::password::1}</password>
JBoss EAP는 먼저 표현식 ${datasource_name}
을 평가한 다음 이를 더 큰 표현식에 입력하고 결과 표현식을 평가합니다. 이 구성의 이점은 데이터 소스 이름이 고정 구성에서 추상화된다는 것입니다.
설명자 기반 속성 교체
데이터 소스 연결 매개 변수와 같은 애플리케이션 구성은 일반적으로 개발, 테스트 및 프로덕션 환경마다 다릅니다. Jakarta EE 사양에는 이러한 구성을 외부화하는 방법이 포함되어 있지 않으므로 이러한 차이가 종종 빌드 시스템 스크립트에 의해 수용됩니다. JBoss EAP를 사용하면 설명자 기반 속성 교체를 사용하여 구성을 외부적으로 관리할 수 있습니다.
설명자 기반 속성 교체는 설명자를 기반으로 하는 속성을 대체하여 애플리케이션 및 빌드 체인에서 환경에 대한 가정을 제거할 수 있습니다. 환경별 구성은 주석 또는 빌드 시스템 스크립트가 아닌 배포 설명자에 지정할 수 있습니다. 명령줄에서 파일 또는 매개 변수로 구성을 제공할 수 있습니다.
the ee
하위 시스템에는 속성 교체가 적용되는지 여부를 제어하는 여러 플래그가 있습니다.
JBoss 특정 설명자 교체는 jboss-descriptor-property-replacement
플래그로 제어되며 기본적으로 활성화되어 있습니다. 활성화된 경우 다음 배포 설명자에서 속성을 바꿀 수 있습니다.
-
jboss-ejb3.xml
-
jboss-app.xml
-
jboss-web.xml
-
jboss-permissions.xml
-
*-jms.xml
-
*-ds.xml
다음 관리 CLI 명령을 사용하여 JBoss별 설명자에서 속성 교체를 활성화하거나 비활성화할 수 있습니다.
/subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)
Jakarta EE 설명자 교체는 spec-descriptor-property-replacement
플래그로 제어되며 기본적으로 비활성화되어 있습니다. 활성화된 경우 다음 배포 설명자에서 속성을 바꿀 수 있습니다.
-
ejb-jar.xml
-
permissions.xml
-
persistence.xml
-
application.xml
-
web.xml
다음 관리 CLI 명령을 사용하여 Jakarta EE 설명자에서 속성 교체를 활성화하거나 비활성화할 수 있습니다.
/subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)
3.6.7. Git을 사용하여 구성 데이터 관리
JBoss EAP 7.3에서는 Git을 사용하여 서버 구성 데이터, 속성 파일 및 배포를 관리하고 유지할 수 있습니다. 이를 통해 이러한 파일의 버전 기록을 관리할 수 있을 뿐 아니라 하나 이상의 Git 리포지토리를 사용하여 여러 서버 및 노드에서 서버 및 애플리케이션 구성을 공유할 수도 있습니다. 이 기능은 기본 구성 디렉터리 레이아웃을 사용하는 독립 실행형 서버에서만 작동합니다.
로컬 Git 리포지토리에서 구성 데이터를 사용하도록 선택하거나 원격 Git 리포지토리에서 데이터를 가져올 수 있습니다. Git 리포지토리는 독립 실행형 서버 콘텐츠의 기본 디렉터리인 jboss.server.base.dir
디렉터리에 구성됩니다. jboss.server.base.dir
디렉터리가 Git을 사용하도록 구성되면 JBoss EAP는 관리 CLI 또는 관리 콘솔을 사용하여 구성에 수행하는 모든 업데이트를 자동으로 커밋합니다. 구성 파일을 수동으로 편집하여 서버 외부에서 변경한 사항은 커밋되거나 지속되지 않지만 Git CLI를 사용하여 수동 변경 사항을 추가하고 커밋할 수 있습니다. Git CLI를 사용하여 커밋 내역을 보고 분기를 관리하며 콘텐츠를 관리할 수도 있습니다.
이 기능을 사용하려면 서버를 시작할 때 명령줄에서 다음 인수 중 하나 이상을 전달합니다.
표 3.4. Git 구성 관리를 위한 서버 시작 인수
인수 | 설명 |
---|---|
--git-repo |
서버 구성 데이터를 관리하고 저장하는 데 사용되는 Git 리포지토리의 위치입니다. 로컬로 저장하거나 원격 리포지토리에 URL을 저장하려는 경우 |
--git-branch | 사용할 Git 리포지토리의 분기 또는 태그 이름입니다. 이 인수는 기존 분기의 이름을 지정하거나 태그 이름이 없으면 생성되지 않으므로 이름을 지정해야 합니다. 태그 이름을 사용하는 경우 리포지토리를 분리된 HEAD 상태로 둡니다. 즉, 향후 커밋은 분기에 연결되지 않습니다. 태그 이름은 읽기 전용이며 일반적으로 여러 노드에 구성을 복제해야 하는 경우 사용됩니다. |
--git-auth |
원격 Git 리포지토리에 연결할 때 사용할 자격 증명을 포함하는 Elytron 구성 파일의 URL입니다. 이 인수는 원격 Git 리포지토리에 인증이 필요한 경우 필요합니다. 이 인수는 |
로컬 Git 리포지토리 사용
로컬 Git 리포지토리를 사용하려면 --git-repo=local
인수로 서버를 시작합니다. 서버를 시작할 때 --git-branch=GIT_BRANCH_NAME
인수를 추가하여 원격 리포지토리에 선택적 분기 또는 태그 이름을 지정할 수도 있습니다. 이 인수는 기존 분기의 이름을 지정하거나 태그 이름이 없으면 생성되지 않으므로 이름을 지정해야 합니다. 태그 이름을 사용하는 경우 리포지토리를 분리된 HEAD 상태로 둡니다. 즉, 향후 커밋은 분기에 연결되지 않습니다.
다음은 로컬
리포지토리의 1.0.x
분기를 사용하여 서버를 시작하는 명령의 예입니다.
$ EAP_HOME/bin/standalone.sh --git-repo=local --git-branch=1.0.x
로컬
Git 리포지토리를 사용하기 위해 인수로 서버를 시작하는 경우 JBoss EAP는 jboss.server.base.dir
디렉터리가 이미 Git에 대해 구성되어 있는지 확인합니다. 그렇지 않은 경우 JBoss EAP는 기존 구성 콘텐츠를 사용하여 jboss.server.base.dir
디렉터리에 Git 리포지토리를 만들고 초기화합니다. JBoss EAP는 --git-branch
인수로 전달된 분기 이름을 확인합니다. 해당 인수가 전달되지 않으면 master
분기를 확인합니다. 초기화 후 독립 실행형 서버 콘텐츠의 기본 디렉터리에
파일이 표시되어야 합니다.
.git/
디렉터리와.gitignore
원격 Git 리포지토리 사용
원격 Git 리포지토리를 사용하려면 --git-repo=REMOTE_REPO
인수로 서버를 시작합니다. 인수 값은 URL 또는 로컬 Git 구성에 수동으로 추가한 원격 별칭일 수 있습니다.
서버를 시작할 때 --git-branch=GIT_BRANCH_NAME
인수를 추가하여 원격 리포지토리에 선택적 분기 또는 태그 이름을 지정할 수도 있습니다. 이 인수는 기존 분기의 이름을 지정하거나 태그 이름이 없으면 생성되지 않으므로 이름을 지정해야 합니다. 태그 이름을 사용하는 경우 리포지토리를 분리된 HEAD 상태로 둡니다. 즉, 향후 커밋은 분기에 연결되지 않습니다.
Git 리포지토리에 인증이 필요한 경우 서버를 시작할 때 --git-auth=AUTH_FILE_URL
인수도 추가해야 합니다. 이 인수는 Git 리포지토리에 연결하는 데 필요한 자격 증명을 포함하는 Elytron 구성 파일의 URL이어야 합니다. 다음은 인증에 사용할 수 있는 Elytron 구성 파일의 예입니다.
<?xml version="1.0" encoding="UTF-8"?> <configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <authentication-rules> <rule use-configuration="test-login"> </rule> </authentication-rules> <authentication-configurations> <configuration name="test-login"> <sasl-mechanism-selector selector="BASIC" /> <set-user-name name="eap-user" /> <credentials> <clear-password password="my_api_key" /> </credentials> <set-mechanism-realm name="testRealm" /> </configuration> </authentication-configurations> </authentication-client> </configuration>
다음은 원격 eap-configuration
리포지토리의 1.0.x
분기를 사용하고 인증 자격 증명이 포함된 Elytron 구성 파일에 URL을 전달하는 전체 프로필로 서버를 시작하는 명령의 예입니다.
$ EAP_HOME/bin/standalone.sh --git-repo=https://github.com/MY_GIT_ID/eap-configuration.git --git-branch=1.0.x --git-auth=file:///home/USER_NAME/github-wildfly-config.xml --server-config=standalone-full.xml
원격 Git 리포지토리를 사용하기 위해 인수로 서버를 시작하는 경우 JBoss EAP는 jboss.server.base.dir
디렉터리가 이미 Git에 대해 구성되어 있는지 확인합니다. 그렇지 않은 경우 JBoss EAP는 jboss.server.base.dir
디렉터리에 있는 기존 구성 파일을 삭제하고 이를 원격 Git 구성 데이터로 대체합니다. JBoss EAP는 --git-branch
인수로 전달된 분기 이름을 확인합니다. 해당 인수가 전달되지 않으면 master
분기를 확인합니다. 이 프로세스가 완료되면 독립 실행형 서버 콘텐츠의 기본 디렉터리에
파일이 표시됩니다.
.git/
디렉터리와.gitignore
원래 사용된 것과 다른 --git-repo
URL 또는 --git-branch
이름을 전달하는 서버를 나중에 시작하면 오류 메시지 java.lang.RuntimeException이 표시됩니다. WFLYSRV0268: 서버 시작을 시도할 때 리포지토리 GIT_REPO_NAME
을 가져오지 못했습니다. 이는 JBoss EAP가 현재 jboss.server.base.dir
디렉터리에 구성된 것과 다른 리포지토리 및 분기에서 구성 데이터를 가져오고 Git 가져오기 결과가 충돌하기 때문입니다.
원격 Git SSH 리포지토리 사용
SSH 인증의 경우 SSH 자격 증명을 지정하여 elytron 구성 파일을 구성할 수 있습니다. 이 파일에서 SSH 자격 증명을 지정한 후 독립 실행형 서버 인스턴스를 시작할 수 있으며 원격 Git SSH 리포지토리에서 서버 구성 파일 기록을 관리할 수 있습니다.
elytron-tool.sh
스크립트를 사용하여 액세스할 수 있는 WildFly Elytron 툴을 사용하여 SSH 키 쌍을 생성하고 자격 증명 저장소에 저장할 수도 있습니다. WildFly Elytron 툴은 이전에 서버에 대한 SSH 자격 증명을 지정하지 않은 경우 사용하는 데 유용합니다.
elytron
구성 파일에 자격 증명을 추가하면 원격 Git SSH 리포지토리에 연결할 수 있습니다.
사전 요구 사항
-
elytron
구성 파일에 자격 증명을 추가했습니다.elytron
구성 파일에서 저장된 키 쌍 사용을 참조하고 elytron 구성 파일에서 OpenSSH 키 사용을 참조하십시오.
절차
터미널에서 다음 명령을 실행하여 원격 git SSH 리포지토리에 연결합니다.
$ <eap_home_path>/bin/standalone.sh --git-repo=<git_repository_url> --git-auth=<elytron_configuration_file_url>
독립 실행형 서버가 시작되고 서버의 구성 파일 기록이 이제 원격 Git SSH 리포지토리에서 관리합니다.
추가 리소스
-
elytron-tool.sh
스크립트를 사용하여 SSH 키 쌍을 생성하는 방법에 대한 자세한 내용은 How to Configure Server Security guide 에서 WildFly Elytron 툴을 사용하여 인증 정보 저장소의 키 쌍 관리를 참조하십시오. -
OpenSSH 키 쌍을 생성하고 사용하는 방법에 대한 자세한 내용은
elytron
구성 파일에서 OpenSSH 키 사용을 참조하십시오.
elytron
구성 파일에서 OpenSSH 키 사용
elytron
하위 시스템은 OpenSSH 명령줄 도구를 사용하여 생성된 SSH 키 쌍을 지원합니다. 이 툴은 RSA, DSA 및 ECDSA 알고리즘을 사용합니다.
ssh-keygen
명령을 사용하여 SSH 키 쌍을 생성할 수 있습니다.
또한 세 가지 요소 유형 중 하나를 사용하여 암호를 지정할 수 있습니다.
-
clear-password
-
masked-password
-
credential-store-reference
사전 요구 사항
SSH 키 쌍이 생성되었습니다. 다음 예제에서는 크기가
256
메가바이트의 ECDSA 키 생성을 보여줍니다. 암호는시크릿
으로 설정됩니다.[~/.ssh]$ ssh-keygen -t ecdsa -b 256 Generating public/private ecdsa key pair. Enter file in which to save the key (/home/user/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): secret Enter same passphrase again: secret Your identification has been saved in /home/user/.ssh/id_ecdsa. Your public key has been saved in /home/user/.ssh/id_ecdsa.pub.
절차
다음 두 방법 중 하나를 선택하여
elytron
구성 파일에 키 쌍을 지정합니다.키 쌍 인증 정보를 사용하여 구성 파일에서 키 쌍을 지정합니다. 예를 들면 다음과 같습니다.
<authentication-configurations> <configuration name="example"> <credentials> <key-pair> <openssh-private-key pem="-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABDaZzGpGV 922xmrL+bMHioPAAAAEAAAAAEAAABoAAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlz dHAyNTYAAABBBIMTU1m6pmpnSTZ2k/cbKnxXkRpXUmWwqN1SSNLpRswGsUhmLG2H21br1Z lEHRiRn6zQmA4YCtCw2hLuz8M8WVoAAADAQk+bMNWFfaI4Ej1AQdlLl6v4RDa2HGjDS3V4 39h0pOx4Ix7YZKydTN4SPkYRt78CNK0AhhtKsWo2lVNwyfh8/6SeqowhgCG9MJYW8yRR1R 3DX/eQTx6MV/gSSRLDTpcVWUY0jrBGpMaEvylKoNcabiEo44flkIYlG6E/YtFXsmXsoBsj nFcjvmfE7Lzyin5Fowwpbqj9f0XOARu9wsUzeyJVAwT7+YCU3mWJ3dnO1bOxK4TuLsxD6j RB7bJemsfr -----END OPENSSH PRIVATE KEY-----"> <clear-password password="secret"/> </openssh-private-key> </key-pair> </credentials> </configuration> </authentication-configurations>
예에서는 OpenSSH 형식의 키 쌍을 보여줍니다. 보안의
암호는
명확한
암호 유형으로 설정되며 개인 키의 암호를 해독해야 합니다.중요elytron
하위 시스템은PKCS8
형식의 키 쌍을 지원합니다. 그러나 키 쌍을 원래 형식으로 다시 해독해야 할 때 문제가 발생할 수 있으므로PKCS8
형식의 키 쌍을 암호화해서는 안 됩니다.구성 파일의
<ssh-credential>
요소에 개인 키가 포함된 파일의 위치를 지정합니다. 예를 들면 다음과 같습니다.<authentication-configurations> <configuration name="example"> <credentials> <ssh-credential ssh-directory="/user/home/example/.ssh" private-key-file="id_test_ecdsa" known-hosts-file="known_hosts_test"> 1 2 3 <clear-password password="secret"/> </ssh-credential> </credentials> </configuration> </authentication-configurations>
추가 리소스
- OpenSSH 및 해당 기능에 대한 자세한 내용은 OpenSSH 설명서를 참조하십시오.
Git을 사용할 때 원격 구성 데이터 게시
관리 CLI 게시-구성
작업을 사용하여 Git 리포지토리 변경 사항을 원격 리포지토리로 내보낼 수 있습니다. JBoss EAP는 서버를 시작할 때 부팅 프로세스 중에 원격 Git 리포지토리에서 구성을 가져오므로 여러 서버에서 구성 데이터를 공유할 수 있습니다. 이 작업은 원격 리포지토리에서만 사용할 수 있습니다. 로컬 리포지토리에서는 작동하지 않습니다.
다음 관리 CLI 작업은 구성 데이터를 원격 eap-configuration
리포지토리에 게시합니다.
:publish-configuration(location="=https://github.com/MY_GIT_ID/eap-configuration.git")
{"outcome" => "success"}
Git에서 스냅샷 사용
Git 커밋 기록을 사용하여 구성 변경 사항을 추적하는 것 외에도 스냅샷을 작성하여 특정 시점에서 구성을 유지할 수도 있습니다. 스냅샷을 나열하고 삭제할 수 있습니다.
Git을 사용할 때 스냅샷 찍기
스냅샷은 Git에 태그로 저장됩니다. 스냅샷 태그 이름 및 커밋 메시지를 take-snapshot
작업에 인수로 지정합니다.
다음 관리 CLI 작업은 스냅샷을 찍고 태그 이름을 "snapshot-01"로 지정합니다.
:take-snapshot(name="snapshot-01", comment="1st snapshot") { "outcome" => "success", "result" => "1st snapshot" }
Git을 사용할 때 스냅샷 나열
list -snapshots 작업을 사용하여 모든 스냅샷 태그를 나열
할 수 있습니다.
다음 관리 CLI 작업에는 스냅샷 태그가 나열되어 있습니다.
:list-snapshots { "outcome" => "success", "result" => { "directory" => "", "names" => [ "snapshot : 1st snapshot", "refs/tags/snapshot-01", "snapshot2 : 2nd snapshot", "refs/tags/snapshot-02" ] } }
Git을 사용할 때 스냅샷 삭제
delete -snapshot 작업에 태그 이름을 전달하여 특정 스냅샷을 삭제할 수
있습니다.
다음 관리 CLI 작업은 태그 이름이 "snapshot-01"인 스냅샷을 삭제합니다.
:delete-snapshot(name="snapshot-01") {"outcome" => "success"}
3.7. 파일 시스템 경로
JBoss EAP는 파일 시스템 경로에 논리적 이름을 사용합니다. 구성의 다른 영역은 논리 이름을 사용하여 경로를 참조할 수 있으므로 각 인스턴스에 절대 경로를 사용할 필요가 없으며 특정 호스트 구성이 범용 논리 이름으로 확인할 수 있습니다.
예를 들어 기본 로깅
하위 시스템 구성은 서버 로그 디렉터리의 논리적 이름으로 jboss.server.log.dir
을 선언합니다.
예제: 서버 로그 디렉토리의 상대 경로 예
<file relative-to="jboss.server.log.dir" path="server.log"/>
JBoss EAP는 사용자가 구성 파일에서 구성할 필요 없이 다양한 표준 경로를 자동으로 제공합니다.
표 3.5. 표준 경로
속성 | 설명 |
---|---|
java.home | Java 설치 디렉터리 |
jboss.controller.temp.dir |
독립 실행형 서버 및 관리형 도메인의 공통 별칭. 임시 파일 스토리지에 사용할 디렉터리입니다. 관리형 도메인의 |
jboss.domain.base.dir | 도메인 콘텐츠의 기본 디렉터리입니다. |
jboss.domain.config.dir | 도메인 구성이 포함된 디렉터리입니다. |
jboss.domain.data.dir | 도메인이 영구 데이터 파일 스토리지에 사용할 디렉터리입니다. |
jboss.domain.log.dir | 도메인에서 영구 로그 파일 스토리지에 사용할 디렉터리입니다. |
jboss.domain.temp.dir | 도메인에서 임시 파일 스토리지에 사용할 디렉터리입니다. |
jboss.domain.deployment.dir | 도메인에서 배포된 콘텐츠를 저장하는 데 사용할 디렉터리입니다. |
jboss.domain.servers.dir | 도메인이 관리형 도메인 인스턴스의 출력을 저장하는 데 사용할 디렉터리입니다. |
jboss.home.dir | JBoss EAP 배포의 루트 디렉터리입니다. |
jboss.server.base.dir | 독립 실행형 서버 콘텐츠의 기본 디렉터리입니다. |
jboss.server.config.dir | 독립 실행형 서버 구성이 포함된 디렉터리입니다. |
jboss.server.data.dir | 독립 실행형 서버가 영구 데이터 파일 스토리지에 사용할 디렉터리입니다. |
jboss.server.log.dir | 독립 실행형 서버가 로그 파일 스토리지에 사용할 디렉터리입니다. |
jboss.server.temp.dir | 독립 실행형 서버가 임시 파일 스토리지에 사용할 디렉터리입니다. |
jboss.server.deploy.dir | 독립 실행형 서버가 배포된 콘텐츠를 저장하는 데 사용할 디렉터리입니다. |
user.dir | 사용자의 현재 작업 디렉터리. |
user.home | 사용자 홈 디렉터리. |
표준 경로를 재정의하거나 사용자 정의 경로를 추가할 수 있습니다.
3.7.1. 파일 시스템 경로보기
다음 관리 CLI 명령을 사용하여 파일 시스템 경로를 나열합니다.
ls /path
관리형 도메인에서는 다음 관리 CLI 명령을 사용하여 특정 서버의 파일 시스템 경로를 나열할 수 있습니다.
ls /host=HOST_NAME/server=SERVER_NAME/path
다음 관리 CLI 명령을 사용하여 파일 시스템 경로 값을 읽습니다.
/path=PATH_NAME:read-resource
관리형 도메인에서는 다음 관리 CLI 명령을 사용하여 특정 서버의 파일 시스템 경로 값을 읽을 수 있습니다.
/host=HOST_NAME/server=SERVER_NAME/path=PATH_NAME:read-resource
3.7.2. 표준 경로 덮어쓰기
jboss.server.* 또는
다음 두 가지 방법 중 하나로 수행할 수 있습니다.
jboss.domain.*
로 시작하는 표준 경로의 기본 위치를 재정의할 수 있습니다.
서버를 시작할 때 명령줄 인수를 전달합니다. 예를 들면 다음과 같습니다.
$ EAP_HOME/bin/standalone.sh -Djboss.server.log.dir=/var/log
서버 구성 파일인
standalone.conf 또는
에서 새 위치를 포함하도록domain.conf
JAVA_OPTS
변수를 수정합니다. 예를 들면 다음과 같습니다.JAVA_OPTS="$JAVA_OPTS -Djboss.server.log.dir=/var/log"
관리형 도메인의 표준 경로 재정의
이 예제에서 목표는 도메인 파일을 /opt/jboss_eap/domain_data
디렉터리에 저장하고 각 최상위 디렉터리에 사용자 지정 이름을 지정하는 것입니다. 기본 디렉터리 그룹 by-server
가 사용됩니다.
-
로그 파일은
all_logs
하위 디렉토리에 저장해야 합니다 -
데이터 파일은
all_data
하위 디렉토리에 저장해야 합니다 -
임시 파일은
all_temp
하위 디렉토리에 저장해야 합니다 -
서버의 파일은
all_servers
하위 디렉토리에 저장해야 합니다.
이 구성을 수행하려면 JBoss EAP를 시작할 때 여러 시스템 속성을 재정의해야 합니다.
$ EAP_HOME/bin/domain.sh -Djboss.domain.temp.dir=/opt/jboss_eap/domain_data/all_temp -Djboss.domain.log.dir=/opt/jboss_eap/domain_data/all_logs -Djboss.domain.data.dir=/opt/jboss_eap/domain_data/all_data -Djboss.domain.servers.dir=/opt/jboss_eap/domain_data/all_servers
결과 경로 구조는 다음과 같습니다.
/opt/jboss_eap/domain_data/ ├── all_data ├── all_logs ├── all_servers │ ├── server-one │ │ ├── data │ │ ├── log │ │ └── tmp │ └── server-two │ ├── data │ ├── log │ └── tmp └── all_temp
3.7.3. 사용자 정의 경로 추가
관리 CLI 또는 관리 콘솔을 사용하여 사용자 지정 파일 시스템 경로를 추가할 수 있습니다.
관리 CLI에서 다음 관리 CLI 명령을 사용하여 새 경로를 추가할 수 있습니다.
/path=my.custom.path:add(path=/my/custom/path)
- 관리 콘솔에서 Configuration (구성) 탭으로 이동하고 Paths (경로)를 선택하고 View (보기)를 클릭하여 파일 시스템 경로를 구성할 수 있습니다. 여기에서 경로를 추가, 수정 및 제거할 수 있습니다.
그런 다음 이 사용자 지정 경로를 구성에서 사용할 수 있습니다. 예를 들어 아래 로그 핸들러는 상대 경로에 사용자 지정 경로를 사용합니다.
<subsystem xmlns="urn:jboss:domain:logging:6.0"> ... <periodic-rotating-file-handler name="FILE" autoflush="true"> <formatter> <named-formatter name="PATTERN"/> </formatter> <file relative-to="my.custom.path" path="server.log"/> <suffix value=".yyyy-MM-dd"/> <append value="true"/> </periodic-rotating-file-handler> ... </subsystem>
3.8. 디렉토리 그룹화
관리형 도메인에서 각 서버의 파일은 EAP_HOME/domain
디렉터리에 저장됩니다. 호스트 컨트롤러의 directory-grouping 특성을 사용하여 서버의 하위 디렉터리를
구성하는 방법을 지정할 수 있습니다. 디렉터리는 서버 또는 유형 별로 그룹화할 수 있습니다. 기본적으로 디렉터리는 서버 별로 그룹화됩니다.
서버 별 디렉토리 그룹화
기본적으로 디렉터리는 서버별로 그룹화됩니다. 관리가 서버 중심인 경우 이 구성을 사용하는 것이 좋습니다. 예를 들어 서버 인스턴스별로 백업 및 로그 파일 처리를 구성할 수 있습니다.
ZIP 설치 방법을 사용하여 JBoss EAP를 설치하는 경우 기본 디렉토리 구조(서버로 그룹됨)는 다음과 같습니다.
EAP_HOME/domain
└─ servers
├── server-one
│ ├── data
│ ├── tmp
│ └── log
└── server-two
├── data
├── tmp
└── log
서버별로 도메인 디렉터리를 그룹화하려면 다음 관리 CLI 명령을 입력합니다.
/host=HOST_NAME:write-attribute(name=directory-grouping,value=by-server)
그러면 호스트 컨트롤러의 host.xml
구성 파일이 업데이트됩니다.
<servers directory-grouping="by-server"> <server name="server-one" group="main-server-group"/> <server name="server-two" group="main-server-group" auto-start="true"> <socket-bindings port-offset="150"/> </server> </servers>
유형별 디렉토리 그룹화
서버별로 디렉터리를 그룹화하는 대신 파일 유형별로 그룹화할 수 있습니다. 관리가 파일 형식 중심인 경우 이 구성을 사용하는 것이 좋습니다. 예를 들어 데이터
파일만 쉽게 백업할 수 있습니다.
ZIP 설치 방법을 사용하여 JBoss EAP를 설치하고 도메인의 파일을 유형별로 그룹화하면 디렉터리 구조는 다음과 같습니다.
EAP_HOME/domain
├── data
│ └── servers
│ ├── server-one
│ └── server-two
├── log
│ └── servers
│ ├── server-one
│ └── server-two
└── tmp
└── servers
├── server-one
└── server-two
도메인 디렉터리를 유형별로 그룹화하려면 다음 관리 CLI 명령을 입력합니다.
/host=HOST_NAME:write-attribute(name=directory-grouping,value=by-type)
그러면 호스트 컨트롤러의 host.xml
구성 파일이 업데이트됩니다.
<servers directory-grouping="by-type"> <server name="server-one" group="main-server-group"/> <server name="server-two" group="main-server-group" auto-start="true"> <socket-bindings port-offset="150"/> </server> </servers>
3.9. 시스템 속성
Java 시스템 속성을 사용하여 여러 JBoss EAP 옵션을 구성하고 애플리케이션 서버 내에서 사용할 이름-값 쌍을 설정할 수 있습니다.
시스템 속성을 사용하여 JBoss EAP 구성의 기본값을 재정의할 수 있습니다. 예를 들어, 공용 인터페이스 바인드 주소에 대한 다음 XML 구성은 jboss.bind.address
시스템 속성으로 설정할 수 있지만 시스템 속성이 제공되지 않은 경우 기본값은 127.0.0.1
로 설정됩니다.
<inet-address value="${jboss.bind.address:127.0.0.1}"/>
다음과 같은 몇 가지 방법으로 JBoss EAP에서 시스템 속성을 설정할 수 있습니다.
JBoss EAP 관리형 도메인을 사용하는 경우 전체 도메인, 특정 서버 그룹, 특정 호스트 및 모든 서버 인스턴스에 시스템 속성을 적용하거나 특정 서버 인스턴스에 적용할 수 있습니다. 대부분의 JBoss EAP 도메인 설정과 마찬가지로, 보다 구체적인 수준에서 설정된 시스템 속성은 더 추상화된 설정을 재정의합니다. 자세한 내용은 도메인 관리 장을 참조하십시오.
시작 스크립트에 시스템 속성 전달
D 인수를
사용하여 시스템 속성을 JBoss EAP 시작 스크립트에 전달할 수 있습니다. 예를 들면 다음과 같습니다.
$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=192.168.1.2
시스템 속성을 설정하는 이 방법은 JBoss EAP를 시작하기 전에 설정해야 하는 JBoss EAP 옵션에 특히 유용합니다.
관리 CLI를 사용하여 시스템 속성 설정
관리 CLI를 사용하여 다음 구문을 사용하여 시스템 속성을 설정할 수 있습니다.
/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
예를 들면 다음과 같습니다.
/system-property=jboss.bind.address:add(value=192.168.1.2)
관리 CLI를 사용하여 시스템 속성을 설정할 때 jboss.bind.address
의 위의 예제를 포함한 일부 JBoss EAP 옵션이 다음 서버를 다시 시작한 후에만 적용됩니다.
관리형 도메인의 경우 위의 예제에서는 전체 도메인에 대한 시스템 속성을 구성하지만 도메인 구성의 보다 구체적인 수준에서 시스템 속성을 설정하거나 재정의할 수도 있습니다.
관리 콘솔을 사용하여 시스템 속성 설정
- 독립 실행형 JBoss EAP 서버의 경우 Configuration(구성 ) 탭의 관리 콘솔에서 시스템 속성을 구성할 수 있습니다. System Properties 를 선택하고 View 단추를 클릭합니다.
관리형 도메인의 경우:
- 도메인 수준 시스템 속성은 Configuration(구성 ) 탭에서 설정할 수 있습니다. System Properties 를 선택하고 View 단추를 클릭합니다.
- 서버 그룹 및 서버 수준 시스템 속성은 Runtime(런타임 ) 탭에서 설정할 수 있습니다. 구성할 서버 그룹 또는 서버를 선택하고 서버 그룹 또는 서버 이름 옆에 있는 보기 버튼을 클릭하고 시스템 속성 탭을 선택합니다.
- 호스트 수준 시스템 속성은 Runtime(런타임 ) 탭에서 설정할 수 있습니다. 구성할 호스트를 선택한 다음 호스트 이름 옆의 드롭다운 메뉴를 사용하여 속성을 선택합니다.
JAVA_OPTS를 사용하여 시스템 속성 설정
시스템 속성은 JAVA_OPTS
환경 변수를 사용하여 구성할 수도 있습니다. JAVA_OPTS
를 수정할 방법은 여러 가지가 있지만 JBoss EAP는 JBoss EAP 프로세스에서 사용하는 JAVA_OPTS
를 설정하기 위한 구성 파일을 제공합니다.
독립 실행형 서버의 경우 이 파일은 EAP_HOME/bin/standalone.conf
또는 관리형 도메인의 경우 EAP_HOME/bin/domain.conf
입니다. Microsoft Windows 시스템의 경우 이러한 파일의 확장자는 .bat
입니다.
RPM 설치의 경우 RPM 서비스 구성 파일은 시스템 속성을 구성하기 위해 JAVA_OPTS
를 수정하는 데 선호되는 위치입니다. 자세한 내용은 RPM 서비스 속성 구성을 참조하십시오.
관련 구성 파일의 JAVA_OPTS
에 시스템 속성 정의를 추가합니다. 아래 예제에서는 Red Hat Enterprise Linux 시스템에서 바인드 주소 설정을 보여줍니다.
standalone.conf
의 경우 파일 끝에JAVA_OPTS
시스템 속성 정의를 추가합니다. 예를 들면 다음과 같습니다.... # Set the bind address JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address=192.168.1.2"
domain.conf
의 경우 프로세스 컨트롤러JAVA_OPTS
설정 전에JAVA_OPTS
를 설정해야 합니다. 예를 들면 다음과 같습니다.... # Set the bind address JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address=192.168.1.2" # The ProcessController process uses its own set of java options if [ "x$PROCESS_CONTROLLER_JAVA_OPTS" = "x" ]; then ...
MODULE_OPTS 환경 변수를 사용하여 Java 에이전트 추가
시작 스크립트를 편집하지 않고도 MODULE_OPTS=-javaagent:my-agent.jar
환경 변수를 사용하여 Java 에이전트를 JBoss 모듈에 직접 추가할 수 있습니다. 로깅을 구성한 후 에이전트가 초기화됩니다. 이전에는 부팅 클래스 경로에 로그 관리자가 필요했습니다.
독립 실행형 서버에서는 다음 파일에서 MODULE_OPTS
환경 변수를 설정할 수 있습니다.
-
RHEL에서 시작 스크립트는
EAP_HOME/bin/standalone.conf
파일을 사용합니다. -
Windows 서버에서 명령 프롬프트에서
EAP_HOME\bin\standalone.BAT 파일을 사용합니다
. -
Windows 서버에서 PowerShell에서
EAP_HOME\bin\standalone.ps1
파일을 사용합니다.
도메인의 서버의 경우 호스트 JVM 구성 또는 서버 JVM 구성에 module-options
특성을 추가할 수 있습니다.
3.10. 관리 감사 로깅
관리 콘솔, 관리 CLI 또는 관리 API를 사용하는 사용자 지정 애플리케이션을 사용하여 수행한 모든 작업을 로깅하는 관리 인터페이스에 대한 감사 로깅을 활성화할 수 있습니다. 감사 로그 항목은 JSON 형식으로 저장됩니다. 기본적으로 감사 로깅은 비활성화되어 있습니다.
파일 또는 syslog 서버에 대한 출력으로 감사 로깅을 구성할 수 있습니다.
JBoss EAP에 인증된 세션이 없으므로 로그인 및 로그아웃 이벤트를 감사할 수 없습니다. 대신 사용자로부터 작업을 수신하면 감사 메시지가 기록됩니다.
독립 실행형 서버 감사 로깅
기본적으로 비활성화되어 있지만 기본 감사 로깅 구성은 파일에 씁니다.
<audit-log> <formatters> <json-formatter name="json-formatter"/> </formatters> <handlers> <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/> </handlers> <logger log-boot="true" log-read-only="false" enabled="false"> <handlers> <handler name="file"/> </handlers> </logger> </audit-log>
다음 관리 CLI 명령을 사용하여 이 구성을 읽을 수 있습니다.
/core-service=management/access=audit:read-resource(recursive=true)
독립 실행형 서버에 대한 감사 로깅을 활성화하려면 감사 로깅 활성화 를 참조하십시오.
관리형 도메인 감사 로깅
기본적으로 비활성화되어 있지만 기본 감사 로깅 구성은 각 호스트와 각 서버에 대한 파일을 작성합니다.
<audit-log> <formatters> <json-formatter name="json-formatter"/> </formatters> <handlers> <file-handler name="host-file" formatter="json-formatter" relative-to="jboss.domain.data.dir" path="audit-log.log"/> <file-handler name="server-file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/> </handlers> <logger log-boot="true" log-read-only="false" enabled="false"> <handlers> <handler name="host-file"/> </handlers> </logger> <server-logger log-boot="true" log-read-only="false" enabled="false"> <handlers> <handler name="server-file"/> </handlers> </server-logger> </audit-log>
다음 관리 CLI 명령을 사용하여 이 구성을 읽을 수 있습니다.
/host=HOST_NAME/core-service=management/access=audit:read-resource(recursive=true)
관리형 도메인의 감사 로깅을 활성화하려면 감사 로깅 활성화 를 참조하십시오.
3.10.1. 관리 감사 로깅 활성화
JBoss EAP는 감사 로깅을 위해 파일 핸들러로 사전 구성되지만 감사 로깅은 기본적으로 비활성화되어 있습니다. 감사 로깅을 활성화하는 관리 CLI 명령은 독립 실행형 서버 또는 관리형 도메인으로 실행 중인지에 따라 다릅니다. 파일 핸들러 속성은 Management Audit Logging Attributes 를 참조하십시오.
다음 지침은 NATIVE
및 HTTP
감사 로깅을 활성화합니다. Jakarta Management 감사 로깅을 구성하려면 Jakarta Management Management Audit Logging 사용을 참조하십시오.
syslog 감사 로깅을 설정하려면 Syslog 서버로 관리 감사 로깅 보내기를 참조하십시오.
독립 실행형 서버 감사 로깅 활성화
다음 명령을 사용하여 감사 로깅을 활성화할 수 있습니다.
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
기본적으로 이는 EAP_HOME/standalone/data/audit-log.log
에 감사 로그를 작성합니다.
관리형 도메인 감사 로깅 활성화
관리형 도메인의 기본 감사 로깅 구성은 각 호스트 및 각 서버에 대한 감사 로그를 작성하도록 사전 구성되어 있습니다.
다음 명령을 사용하여 각 호스트에 대한 감사 로깅을 활성화할 수 있습니다.
/host=HOST_NAME/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
기본적으로 이는 EAP_HOME/domain/data/audit-log.log
에 감사 로그를 작성합니다.
다음 명령을 사용하여 각 서버에 대한 감사 로깅을 활성화할 수 있습니다.
/host=HOST_NAME/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)
기본적으로 이는 EAP_HOME /domain/servers/SERVER_NAME/data/audit-log.log
에 감사 로그를 작성합니다.
3.10.2. 자카르타 관리 관리 감사 로깅 활성화
JBoss EAP는 Jakarta Management 감사 로깅의 파일 핸들러로 사전 구성되어 있지만 이러한 로그는 기본적으로 비활성화되어 있습니다. 감사 로깅을 활성화하는 관리 CLI 명령은 독립 실행형 서버 또는 관리형 도메인으로 실행 중인지에 따라 다릅니다.
NATIVE
또는 HTTP
감사 로깅을 구성하려면 관리 감사 로깅 활성화 를 참조하십시오.
독립 실행형 서버 자카르타 관리 감사 로깅 활성화
다음 명령을 사용하여 독립 실행형 서버에 대해 Jakarta 관리 감사 로깅을 활성화할 수 있습니다.
/subsystem=jmx/configuration=audit-log:add() /subsystem=jmx/configuration=audit-log/handler=file:add()
이를 통해 Jakarta Management 감사 로깅을 활성화한 다음 정의된 파일
핸들러를 사용하여 이러한 로그를 EAP_HOME/standalone/data/audit-log.log
에 작성합니다.
관리형 도메인 자카르타 관리 감사 로깅 활성화
관리형 도메인의 각 호스트 및 프로필에 대해 Jakarta Management 감사 로깅을 활성화할 수 있습니다.
호스트에 대한 자카르타 관리 감사 로깅 활성화
호스트의
jmx
하위 시스템에서 감사 로깅을 활성화합니다./host=HOST_NAME/subsystem=jmx/configuration=audit-log:add()
jmx
하위 시스템에 대한 감사 로깅이 활성화되면 다음 명령을 사용하여 호스트에 대해 핸들러를 정의할 수 있습니다./host=HOST_NAME/subsystem=jmx/configuration=audit-log/handler=host-file:add()
기본적으로 Jakarta Management 감사 로그를
EAP_HOME/domain/data/audit-log.log
에 씁니다.
프로필에 대한 자카르타 관리 감사 로깅 활성화
프로필의
jmx
하위 시스템에서 감사 로깅을 활성화합니다./profile=PROFILE_NAME/subsystem=jmx/configuration=audit-log:add()
jmx
하위 시스템에 대한 감사 로깅이 활성화되면 다음 명령을 사용하여 프로필에 대해 핸들러를 정의할 수 있습니다./profile=PROFILE_NAME/subsystem=jmx/configuration=audit-log/handler=server-file:add()
기본적으로 Jakarta Management 감사 로그를
EAP_HOME /domain/servers/SERVER_NAME/data/audit-log.log
에 씁니다.
3.10.3. Syslog 서버로 관리 감사 로깅 전송
syslog 핸들러는 감사 로그 항목이 syslog 서버로 전송되는 매개 변수, 특히 syslog 서버의 호스트 이름 및 syslog 서버가 수신 대기하는 포트를 지정합니다. syslog 서버로 감사 로깅을 전송하면 로컬 파일 또는 로컬 syslog 서버에 로깅하는 것보다 더 많은 보안 옵션이 제공됩니다. 여러 개의 syslog 핸들러를 정의하고 동시에 활성화할 수 있습니다.
기본적으로 감사 로깅은 활성화된 경우 파일로 출력하도록 사전 구성됩니다. 다음 단계를 사용하여 syslog 서버에 대한 감사 로깅을 설정하고 활성화합니다. syslog 핸들러 속성은 Management Audit Logging Attributes 를 참조하십시오.
syslog 핸들러를 추가합니다.
syslog 서버의 호스트 및 포트를 지정하여 syslog 핸들러를 생성합니다. 관리형 도메인에서
/core-service 명령 앞에 /
host=HOST_NAME
을 사용해야 합니다.batch /core-service=management/access=audit/syslog-handler=SYSLOG_HANDLER_NAME:add(formatter=json-formatter) /core-service=management/access=audit/syslog-handler=SYSLOG_HANDLER_NAME/protocol=udp:add(host=HOST_NAME,port=PORT) run-batch
참고지정된 프로토콜에 따라 전달되는 매개 변수는 다릅니다.
TLS를 사용하여 syslog 서버와 안전하게 통신하도록 핸들러를 구성하려면 인증을 구성해야 합니다. 예를 들면 다음과 같습니다.
/core-service=management/access=audit/syslog-handler=SYSLOG_HANDLER_NAME/protocol=tls/authentication=truststore:add(keystore-path=PATH_TO_TRUSTSTORE,keystore-password=TRUSTSTORE_PASSWORD)
syslog 핸들러에 대한 참조를 추가합니다.
관리형 도메인에서 이 명령 앞에
/host=HOST_NAME
을 사용해야 합니다./core-service=management/access=audit/logger=audit-log/handler=SYSLOG_HANDLER_NAME:add
감사 로깅을 활성화합니다.
감사 로깅을 활성화하려면 관리 감사 로깅 활성화 를 참조하십시오.
운영 체제에서도 로깅을 활성화하지 않는 한 JBoss EAP의 syslog 서버에 감사 로깅을 활성화하는 것은 작동하지 않습니다.
Red Hat Enterprise Linux의 rsyslog
구성에 대한 자세한 내용은 https://access.redhat.com/documentation/en/red-hat-enterprise-linux/ 의 Red Hat Enterprise Linux 시스템 관리자 가이드의 Rsyslog 기본 구성 섹션을 참조하십시오.
3.10.4. 감사 로그 항목 읽기
파일에 대한 감사 로그 항목은 텍스트 뷰어 로 가장 잘 표시되는 반면 syslog 서버에 대한 출력은 syslog 뷰어 애플리케이션을 사용하여 가장 잘 볼 수 있습니다.
일부에서는 텍스트 편집기를 사용하여 로그 파일을 보는 것을 권장하지 않는 것이 좋습니다. 일부에서는 로그 파일에 추가 로그 항목이 기록되지 않을 수 있습니다.
감사 로그 항목은 JSON 형식으로 저장됩니다. 각 로그 항목은 선택적 타임스탬프로 시작되고 그 뒤에 아래 테이블의 필드가 옵니다.
표 3.6. 관리 감사 로그 필드
필드 이름 | 설명 |
---|---|
액세스 | 다음 값 중 하나가 있을 수 있습니다.
|
부팅 중 |
부팅 프로세스 중에 작업이 실행된 경우 값이 |
domainUUID | 도메인 컨트롤러에서 서버, 슬레이브 호스트 컨트롤러 및 슬레이브 호스트 컨트롤러 서버로 전파되는 모든 작업을 함께 연결하는 ID입니다. |
ops | 실행 중인 작업입니다. JSON으로 직렬화된 작업 목록입니다. 부팅 시 XML 구문 분석이 수행되는 작업입니다. 부팅되고 나면 목록에는 일반적으로 단일 항목이 포함됩니다. |
r/o |
는 작업에서 관리 모델을 변경하지 않는 경우 |
remote-address | 이 작업을 실행하는 클라이언트의 주소입니다. |
success |
는 작업이 성공한 경우 |
type |
이 값은 관리 작업 또는 |
user |
인증된 사용자의 사용자 이름. 실행 중인 서버와 동일한 시스템에서 관리 CLI를 사용하여 작업이 발생한 경우 특수 사용자 |
버전 | JBoss EAP 인스턴스의 버전 번호입니다. |
3.11. 서버 라이프사이클 이벤트 알림
JBoss EAP core-management
하위 시스템 또는 Jakarta 관리를 사용하여 서버 라이프사이클 이벤트에 대한 알림을 설정할 수 있습니다. 서버 런타임 구성 상태 또는 서버 실행 상태가 변경되면 알림이 트리거됩니다.
JBoss EAP의 서버 런타임 구성 상태는 STARTING
,RUNNING
,RELOAD_REQUIRED
,RESTART_REQUIRED
,STOPPING
, and STOPPED
입니다.
JBoss EAP에 대해 실행 중인 서버 상태는 STARTING
,NORMAL
,ADMIN_ONLY
,PRE_SUSPEND
ING,SUSPENDING
,SUSPENDED
,
STOPPED
입니다.
3.11.1. 코어 관리 하위 시스템을 사용하여 서버 라이프사이클 이벤트 모니터링
JBoss EAP core-management
하위 시스템에 리스너를 등록하여 서버 라이프사이클 이벤트를 모니터링할 수 있습니다. 다음 단계에서는 이벤트를 파일에 기록하는 예제 리스너를 만들고 등록하는 방법을 보여줍니다.
리스너를 생성합니다.
아래 예제와 같이
org.wildfly.extension.core.management.client.ProcessStateListener
의 구현을 만듭니다.예제: 리스너 클래스
package org.simple.lifecycle.events.listener; import java.io.File; import java.io.FileWriter; import java.io.IOException; import org.wildfly.extension.core.management.client.ProcessStateListener; import org.wildfly.extension.core.management.client.ProcessStateListenerInitParameters; import org.wildfly.extension.core.management.client.RunningStateChangeEvent; import org.wildfly.extension.core.management.client.RuntimeConfigurationStateChangeEvent; public class SimpleListener implements ProcessStateListener { private File file; private FileWriter fileWriter; private ProcessStateListenerInitParameters parameters; public void init(ProcessStateListenerInitParameters parameters) { this.parameters = parameters; this.file = new File(parameters.getInitProperties().get("file")); try { fileWriter = new FileWriter(file, true); } catch (IOException e) { e.printStackTrace(); } } public void cleanup() { try { fileWriter.close(); } catch (IOException e) { e.printStackTrace(); } finally { fileWriter = null; } } public void runtimeConfigurationStateChanged(RuntimeConfigurationStateChangeEvent evt) { try { fileWriter.write(String.format("Runtime configuration state change for %s: %s to %s\n", parameters.getProcessType(), evt.getOldState(), evt.getNewState())); fileWriter.flush(); } catch (IOException e) { e.printStackTrace(); } } public void runningStateChanged(RunningStateChangeEvent evt) { try { fileWriter.write(String.format("Running state change for %s: %s to %s\n", parameters.getProcessType(), evt.getOldState(), evt.getNewState())); fileWriter.flush(); } catch (IOException e) { e.printStackTrace(); } } }
참고리스너를 구현할 때 다음 사항에 유의하십시오.
- 서버를 다시 로드하는 경우 서버가 중지될 때 리스너가 수신 대기를 중지하고 서버가 시작될 때 리스너가 다시 로드됩니다. 이로 인해 구현이 동일한 JVM 내에서 제대로 로드, 초기화 및 제거할 수 있는지 확인해야 합니다.
- 리스너에 대한 알림은 서버 상태 변경에 대한 대응을 허용하기 위해 차단됩니다. 구현은 차단 또는 교착 상태가 되지 않도록 해야 합니다.
- 각 리스너 인스턴스는 자체 스레드에서 실행되며 순서가 보장되지 않습니다.
클래스를 컴파일하고 JAR로 패키징합니다.
컴파일하려면
org.wildfly.core:wildfly-core-management-client
Maven 모듈을 사용해야 합니다.JAR을 JBoss EAP 모듈로 추가합니다.
다음 관리 CLI 명령을 사용하고 JAR에 대한 모듈 이름과 경로를 제공합니다.
module add --name=org.simple.lifecycle.events.listener --dependencies=org.wildfly.extension.core-management-client --resources=/path/to/simple-listener-0.0.1-SNAPSHOT.jar
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
리스너를 등록합니다.
다음 관리 CLI 명령을 사용하여 리스너를
core-management
하위 시스템에 추가합니다. class, module, file 위치를 지정하여 서버 라이프사이클 이벤트를 기록합니다./subsystem=core-management/process-state-listener=my-simple-listener:add(class=org.simple.lifecycle.events.listener.SimpleListener, module=org.simple.lifecycle.events.listener,properties={file=/path/to/my-listener-output.txt})
이제 위의 SimpleListener
클래스를 기반으로 my-listener-output.txt
파일에 서버 라이프사이클 이벤트가 기록됩니다. 예를 들어 관리 CLI에서 :suspend
명령을 실행하면 다음을 my-listener-output.txt
파일에 출력합니다.
Running state change for STANDALONE_SERVER: normal to suspending Running state change for STANDALONE_SERVER: suspending to suspended
이는 실행 상태가 정상에서 일시 중단으로 변경된 다음
에서 일시 중지
일시 중지로 변경되었음을
나타냅니다 .
3.11.2. 자카르타 관리 알림을 사용하여 서버 라이프사이클 이벤트 모니터링
서버 라이프사이클 이벤트를 모니터링하기 위해 Jakarta Management 알림 리스너를 등록할 수 있습니다. 다음 단계에서는 이벤트를 파일에 기록하는 예제 리스너를 만들고 추가하는 방법을 보여줍니다.
리스너를 생성합니다.
아래 예제와 같이
javax.management.NotificationListener
의 구현을 만듭니다.예제: 리스너 클래스
import java.io.BufferedWriter; import java.io.IOException; import java.nio.charset.StandardCharsets; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.nio.file.StandardOpenOption; import javax.management.AttributeChangeNotification; import javax.management.Notification; import javax.management.NotificationListener; import org.jboss.logging.Logger; public class StateNotificationListener implements NotificationListener { public static final String RUNTIME_CONFIGURATION_FILENAME = "runtime-configuration-notifications.txt"; public static final String RUNNING_FILENAME = "running-notifications.txt"; private final Path targetFile; public StateNotificationListener() { this.targetFile = Paths.get("notifications/data").toAbsolutePath(); init(targetFile); } protected Path getRuntimeConfigurationTargetFile() { return this.targetFile.resolve(RUNTIME_CONFIGURATION_FILENAME); } protected Path getRunningConfigurationTargetFile() { return this.targetFile.resolve(RUNNING_FILENAME); } protected final void init(Path targetFile) { try { Files.createDirectories(targetFile); if (!Files.exists(targetFile.resolve(RUNTIME_CONFIGURATION_FILENAME))) { Files.createFile(targetFile.resolve(RUNTIME_CONFIGURATION_FILENAME)); } if (!Files.exists(targetFile.resolve(RUNNING_FILENAME))) { Files.createFile(targetFile.resolve(RUNNING_FILENAME)); } } catch (IOException ex) { Logger.getLogger(StateNotificationListener.class).error("Problem handling JMX Notification", ex); } } @Override public void handleNotification(Notification notification, Object handback) { AttributeChangeNotification attributeChangeNotification = (AttributeChangeNotification) notification; if ("RuntimeConfigurationState".equals(attributeChangeNotification.getAttributeName())) { writeNotification(attributeChangeNotification, getRuntimeConfigurationTargetFile()); } else { writeNotification(attributeChangeNotification, getRunningConfigurationTargetFile()); } } private void writeNotification(AttributeChangeNotification notification, Path path) { try (BufferedWriter in = Files.newBufferedWriter(path, StandardCharsets.UTF_8, StandardOpenOption.APPEND)) { in.write(String.format("%s %s %s %s", notification.getType(), notification.getSequenceNumber(), notification.getSource().toString(), notification.getMessage())); in.newLine(); in.flush(); } catch (IOException ex) { Logger.getLogger(StateNotificationListener.class).error("Problem handling JMX Notification", ex); } } }
알림 리스너를 등록합니다.
알림 리스너를
MBeanServer
에 추가합니다.예제: 알림 리스너 추가
MBeanServer server = ManagementFactory.getPlatformMBeanServer(); server.addNotificationListener(ObjectName.getInstance("jboss.root:type=state"), new StateNotificationListener(), null, null);
- 패키징 및 JBoss EAP에 배포.
이제 서버 라이프사이클 이벤트가 위의 StateNotificationListener
클래스를 기반으로 파일에 기록됩니다. 예를 들어 관리 CLI에서 :suspend
명령을 실행하면 다음을 running-notifications.txt
파일에 출력합니다.
jmx.attribute.change 5 jboss.root:type=state The attribute 'RunningState' has changed from 'normal' to 'suspending' jmx.attribute.change 6 jboss.root:type=state The attribute 'RunningState' has changed from 'suspending' to 'suspended'
이는 실행 상태가 정상에서 일시 중단으로 변경된 다음
에서 일시 중지
일시 중지로 변경되었음을
나타냅니다 .
4장. 네트워크 및 포트 구성
4.1. 인터페이스
구성 전체에서 인터페이스라는 JBoss EAP 참조. 이렇게 하면 구성에서 각 사용 시 인터페이스의 전체 세부 정보를 요구하지 않고 논리 이름의 개별 인터페이스 선언을 참조할 수 있습니다.
이를 통해 관리형 도메인에서 쉽게 구성할 수 있으며, 여기서 네트워크 인터페이스 세부 정보는 여러 시스템에 따라 다를 수 있습니다. 각 서버 인스턴스는 논리 이름 그룹에 해당할 수 있습니다.
standalone.xml
,domain.xml
및 host.xml
파일은 모두 인터페이스 선언을 포함합니다. 사용되는 기본 구성에 따라 몇 가지 사전 구성된 인터페이스 이름이 있습니다. 관리
인터페이스는 HTTP 관리 엔드포인트를 포함하여 관리 계층이 필요한 모든 구성 요소 및 서비스에 사용할 수 있습니다. 공용
인터페이스는 모든 애플리케이션 관련 네트워크 통신에 사용할 수 있습니다. 비보안 인터페이스는
표준 구성의 IIOP 소켓에 사용됩니다. 개인
인터페이스는 표준 구성의 JGroups 소켓에 사용됩니다.
4.1.1. 기본 인터페이스 설정
<interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address:127.0.0.1}"/> </interface> <interface name="private"> <inet-address value="${jboss.bind.address.private:127.0.0.1}"/> </interface> <interface name="unsecure"> <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/> </interface> </interfaces>
기본적으로 JBoss EAP는 이러한 인터페이스를 127.0.0.1
에 바인딩하지만 적절한 속성을 설정하여 런타임 시 이러한 값을 재정의할 수 있습니다. 예를 들어 다음 명령을 사용하여 JBoss EAP를 독립 실행형 서버로 시작할 때 공용
인터페이스의 inet-address
를 설정할 수 있습니다.
$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS
또는 server start 명령줄에서 -b
스위치를 사용할 수도 있습니다. 서버 시작 옵션에 대한 자세한 내용은 서버 런타임 인수 및 스위치 를 참조하십시오.
JBoss EAP에서 사용하는 기본 네트워크 인터페이스 또는 포트를 수정하는 경우 수정된 인터페이스 또는 포트를 사용하는 스크립트도 변경해야 합니다. 여기에는 JBoss EAP 서비스 스크립트와 관리 콘솔 또는 관리 CLI에 액세스할 때 올바른 인터페이스와 포트를 지정하는 기억이 포함됩니다.
4.1.2. 인터페이스 구성
네트워크 인터페이스는 실제 인터페이스에 대한 논리적 이름 및 선택 기준을 지정하여 선언됩니다. 선택 기준은 와일드카드 주소를 참조하거나 인터페이스 또는 주소가 유효한 일치를 위해 있어야 하는 하나 이상의 특성 집합을 지정할 수 있습니다. 사용 가능한 모든 인터페이스 선택 기준 목록은 인터페이스 특성 섹션을 참조하십시오.
인터페이스는 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다. 다음은 인터페이스 추가 및 업데이트의 몇 가지 예입니다. 관리 CLI 명령 다음에 해당 구성 XML이 표시됩니다.
NIC 값을 사용하여 인터페이스 추가
NIC 값이 eth0
인 새 인터페이스를 추가합니다.
/interface=external:add(nic=eth0)
<interface name="external"> <nic name="eth0"/> </interface>
심각도 조건 값이 있는 인터페이스 추가
올바른 서브넷이 작동하는 경우 올바른 서브넷의 인터페이스/주소와 일치하는 새 인터페이스를 추가하고, 멀티캐스트를 지원하며 포인트 투 포인트가 아닌 새 인터페이스를 추가합니다.
/interface=default:add(subnet-match=192.168.0.0/16,up=true,multicast=true,not={point-to-point=true})
<interface name="default"> <subnet-match value="192.168.0.0/16"/> <up/> <multicast/> <not> <point-to-point/> </not> </interface>
인터페이스 속성 업데이트
jboss.bind.
값을 업데이트합니다.
address 속성을 유지하여 런타임에 이 값을 설정할 수 있도록
address공용
인터페이스의 기본 inet-
/interface=public:write-attribute(name=inet-address,value="${jboss.bind.address:192.168.0.0}")
<interface name="public"> <inet-address value="${jboss.bind.address:192.168.0.0}"/> </interface>
관리형 도메인의 서버에 인터페이스 추가
/host=HOST_NAME/server-config=SERVER_NAME/interface=INTERFACE_NAME:add(inet-address=127.0.0.1)
<servers> <server name="SERVER_NAME" group="main-server-group"> <interfaces> <interface name="INTERFACE_NAME"> <inet-address value="127.0.0.1"/> </interface> </interfaces> </server> </servers>
4.2. 소켓 바인딩
소켓 바인딩 및 소켓 바인딩 그룹을 사용하면 JBoss EAP 구성에 필요한 네트워킹 인터페이스와의 네트워크 포트 및 해당 관계를 정의할 수 있습니다. 소켓 바인딩은 소켓에 대한 명명된 구성입니다. 소켓 바인딩 그룹은 논리 이름으로 그룹화되는 소켓 바인딩 선언의 컬렉션입니다.
이를 통해 구성의 다른 섹션에서는 소켓 구성에 대한 전체 세부 정보를 요구하지 않고 논리 이름별로 소켓 바인딩을 참조할 수 있습니다.
이러한 명명된 구성에 대한 선언은 standalone.xml 및
구성 파일에서 확인할 수 있습니다. 독립 실행형 서버에는 하나의 소켓 바인딩 그룹만 포함되어 있지만, 관리형 도메인에는 여러 그룹이 포함될 수 있습니다. 관리형 도메인에서 각 서버 그룹에 대해 소켓 바인딩 그룹을 생성하거나 여러 서버 그룹 간에 소켓 바인딩 그룹을 공유할 수 있습니다.
domain.xml
기본적으로 JBoss EAP가 사용하는 포트는 사용되는 소켓 바인딩 그룹과 개별 배포의 요구 사항에 따라 달라집니다.
JBoss EAP 구성의 소켓 바인딩 그룹에는 다음 세 가지 유형의 소켓 바인딩을 정의할 수 있습니다.
- 인바운드 소켓 바인딩
socket-binding
요소는 JBoss EAP 서버에 대한 인바운드 소켓 바인딩을 구성하는 데 사용됩니다. 기본 JBoss EAP 구성에서는 미리 구성된 몇 가지소켓 바인딩
요소를 제공합니다(예: HTTP 및 HTTPS 트래픽). 또 다른 예는 JBoss EAP에 대한 메시징 구성의 브로드캐스트 그룹 섹션에서 확인할 수 있습니다.이 요소의 속성은 소켓 바인딩 특성 에서 확인할 수 있습니다.
- 원격 아웃바운드 소켓 바인딩
remote-destination-outbound-socket-binding
요소는 JBoss EAP 서버로 원격 대상에 대한 아웃바운드 소켓 바인딩을 구성하는 데 사용됩니다. 기본 JBoss EAP 구성에서는 메일 서버에 사용할 수 있는 원격 대상 소켓 바인딩의 예를 제공합니다. 또 다른 예는 JBoss EAP에 대한 메시징 구성의 원격 연결에 통합 Artemis 리소스 어댑터 사용 섹션 을 참조하십시오.이 요소의 속성은 소켓 바인딩 특성 테이블에서 찾을 수 있습니다.
- 로컬 아웃바운드 소켓 바인딩
local-destination-outbound-socket-binding
요소는 JBoss EAP 서버로 로컬인 대상에 대한 아웃바운드 소켓 바인딩을 구성하는 데 사용됩니다. 이러한 유형의 소켓 바인딩은 일반적으로 사용되지 않습니다.이 요소의 속성은 소켓 바인딩 특성 테이블에서 찾을 수 있습니다.
4.2.1. 관리 포트
관리 포트는 JBoss EAP 7에서 통합되었습니다. 기본적으로 JBoss EAP 7은 관리 CLI에서 사용하는 네이티브 관리 및 웹 기반 관리 콘솔에서 사용하는 HTTP 관리 모두에 포트 9990
을 사용합니다. JBoss EAP 6에서 네이티브 관리 포트로 사용된 포트 9999
는 더 이상 사용되지 않지만 원하는 경우 활성화할 수 있습니다.
관리 콘솔에 HTTPS를 활성화하면 기본적으로 포트 9993
이 사용됩니다.
4.2.2. 기본 소켓 바인딩
JBoss EAP에는 사전 정의된 5개의 프로필(default,ha, full,full -ha, load-balancer ) 각각에 대한 소켓 바인딩 그룹이 포함되어 있습니다.
기본 포트 및 설명과 같은 기본 소켓 바인딩에 대한 자세한 내용은 기본 소켓 바인딩 섹션을 참조하십시오.
JBoss EAP에서 사용하는 기본 네트워크 인터페이스 또는 포트를 수정하는 경우 수정된 인터페이스 또는 포트를 사용하는 스크립트도 변경해야 합니다. 여기에는 JBoss EAP 서비스 스크립트와 관리 콘솔 또는 관리 CLI에 액세스할 때 올바른 인터페이스와 포트를 지정하는 기억이 포함됩니다.
독립 실행형 서버
독립 실행형 서버로 실행하는 경우 구성 파일별로 하나의 소켓 바인딩 그룹만 정의됩니다. 각 독립 실행형 구성 파일(standalone.xml
,standalone-ha.xml
,standalone-full.xml
,standalone-full-ha.xml
,standalone-load-balancer.xml
)은 해당 프로필에서 사용하는 기술에 대한 소켓 바인딩을 정의합니다.
예를 들어 기본 독립 실행형 구성 파일(standalone.xml
)은 아래 소켓 바인딩을 지정합니다.
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/> <socket-binding name="http" port="${jboss.http.port:8080}"/> <socket-binding name="https" port="${jboss.https.port:8443}"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group>
관리형 도메인
관리형 도메인에서 실행하면 모든 소켓 바인딩 그룹이 domain.xml
파일에 정의됩니다. 5개의 사전 정의된 소켓 바인딩 그룹이 있습니다.
-
standard-sockets
-
ha-sockets
-
full-sockets
-
full-ha-sockets
-
load-balancer-sockets
각 소켓 바인딩 그룹은 해당 프로필에서 사용하는 기술의 소켓 바인딩을 지정합니다. 예를 들어 full-ha-sockets
소켓 바인딩 그룹은 고가용성을 위해 full-ha 프로필에서 사용하는 여러 jgroups
소켓 바인딩을 정의합니다.
<socket-binding-groups> <socket-binding-group name="standard-sockets" default-interface="public"> <!-- Needed for server groups using the 'default' profile --> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/> <socket-binding name="http" port="${jboss.http.port:8080}"/> <socket-binding name="https" port="${jboss.https.port:8443}"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group> <socket-binding-group name="ha-sockets" default-interface="public"> <!-- Needed for server groups using the 'ha' profile --> ... </socket-binding-group> <socket-binding-group name="full-sockets" default-interface="public"> <!-- Needed for server groups using the 'full' profile --> ... </socket-binding-group> <socket-binding-group name="full-ha-sockets" default-interface="public"> <!-- Needed for server groups using the 'full-ha' profile --> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/> <socket-binding name="http" port="${jboss.http.port:8080}"/> <socket-binding name="https" port="${jboss.https.port:8443}"/> <socket-binding name="iiop" interface="unsecure" port="3528"/> <socket-binding name="iiop-ssl" interface="unsecure" port="3529"/> <socket-binding name="jgroups-mping" interface="private" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/> <socket-binding name="jgroups-tcp" interface="private" port="7600"/> <socket-binding name="jgroups-udp" interface="private" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/> <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group> <socket-binding-group name="load-balancer-sockets" default-interface="public"> <!-- Needed for server groups using the 'load-balancer' profile --> ... </socket-binding-group> </socket-binding-groups>
관리 인터페이스의 소켓 구성은 도메인 컨트롤러의 host.xml
파일에 정의되어 있습니다.
4.2.3. 소켓 바인딩 구성
소켓 바인딩을 정의할 때 포트
및 인터페이스
속성은 물론 multicast -address 및 multicast
설정을 구성할 수 있습니다. 사용 가능한 모든 소켓 바인딩 속성에 대한 자세한 내용은 소켓 바인딩 특성 섹션을 참조하십시오.
-port
와 같은 멀티캐스트
소켓 바인딩은 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다. 다음 단계에서는 소켓 바인딩 그룹을 추가하고, 소켓 바인딩을 추가하고, 관리 CLI를 사용하여 소켓 바인딩 설정을 구성합니다.
새 소켓 바인딩 그룹을 추가합니다. 독립 실행형 서버로 실행할 때는 이 단계를 수행할 수 없습니다.
/socket-binding-group=new-sockets:add(default-interface=public)
소켓 바인딩을 추가합니다.
/socket-binding-group=new-sockets/socket-binding=new-socket-binding:add(port=1234)
소켓 바인딩 그룹에서 설정한 기본값 이외의 인터페이스를 사용하도록 소켓 바인딩을 변경합니다.
/socket-binding-group=new-sockets/socket-binding=new-socket-binding:write-attribute(name=interface,value=unsecure)
다음 예제에서는 XML 구성이 위의 단계를 완료한 후 살펴볼 수 있는 방법을 보여줍니다.
<socket-binding-groups> ... <socket-binding-group name="new-sockets" default-interface="public"> <socket-binding name="new-socket-binding" interface="unsecure" port="1234"/> </socket-binding-group> </socket-binding-groups>
4.2.4. 서버의 소켓 바인딩 및 열려 있는 포트 보기
관리 콘솔에서 서버의 소켓 바인딩 이름과 열려 있는 포트를 볼 수 있습니다. 이 정보는 서버가 다음 상태에 있을 때 표시됩니다.
-
running
-
reload-required
-
restart-required
서버의 소켓 바인딩 및 열려 있는 포트를 보려면 다음을 수행합니다.
- 관리 콘솔에 액세스하고 런타임 으로 이동합니다.
- 서버를 클릭하여 오른쪽 창에서 소켓 바인딩 이름과 열려 있는 포트를 확인합니다.
4.2.5. 포트 오프셋
포트 오프셋은 해당 서버의 소켓 바인딩 그룹에 지정된 모든 포트 값에 추가된 숫자 오프셋 값입니다. 이렇게 하면 서버에서 소켓 바인딩 그룹에 정의된 포트 값을 오프셋과 상속하여 동일한 호스트의 다른 서버와 충돌하지 않도록 할 수 있습니다. 예를 들어 소켓 바인딩 그룹의 HTTP 포트가 8080
이고 서버에서 100
의 포트 오프셋을 사용하는 경우 HTTP 포트는 8180
입니다.
다음은 관리 CLI를 사용하여 관리형 도메인의 서버에 대해 250
의 포트 오프셋을 설정하는 예입니다.
/host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)
포트 오프셋은 관리형 도메인의 서버 및 동일한 호스트에서 여러 독립 실행형 서버를 실행하는 데 사용할 수 있습니다.
jboss.socket.binding.port-offset
속성을 사용하여 독립 실행형 서버를 시작할 때 포트 오프셋에서 전달할 수 있습니다.
$ EAP_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=100
4.3. IPv6 주소
기본적으로 JBoss EAP는 IPv4 주소를 사용하여 실행하도록 구성됩니다. 아래 단계에서는 IPv6 주소를 사용하여 실행하도록 JBoss EAP를 구성하는 방법을 보여줍니다.
IPv6 주소에 대한 JVM 스택 구성
IPv6 주소를 사용하도록 시작 구성을 업데이트합니다.
시작 구성 파일을 엽니다.
-
독립 실행형 서버로 실행하는 경우
EAP_HOME/bin/standalone.conf
파일(또는 Windows Server의 경우standalone.conf.bat
)을 편집합니다. -
관리형 도메인에서 실행하는 경우
EAP_HOME/bin/domain.conf
파일(또는 Windows Server의domain.conf.bat
)을 편집합니다.
-
독립 실행형 서버로 실행하는 경우
java.net.preferIPv4Stack
속성을false로 설정합니다
.-Djava.net.preferIPv4Stack=false
java.net.preferIPv6Addresses
속성을 추가하고true
로 설정합니다.-Djava.net.preferIPv6Addresses=true
다음 예제에서는 시작 구성 파일의 JVM 옵션을 위의 변경 사항을 수행한 후 보는 방법을 보여줍니다.
# Specify options to pass to the Java VM. # if [ "x$JAVA_OPTS" = "x" ]; then JAVA_OPTS="-Xms1303m -Xmx1303m -Djava.net.preferIPv4Stack=false" JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true" JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv6Addresses=true" else
IPv6 주소에 대한 인터페이스 선언 업데이트
구성의 기본 인터페이스 값은 IPv6 주소로 변경할 수 있습니다. 예를 들어 아래 관리 CLI 명령은 관리
인터페이스를 IPv6 루프백 주소(::1)로 설정합니다.
/interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:[::1]}")
다음 예제에서는 XML 구성이 위의 명령을 실행한 후에 살펴볼 수 있는 방법을 보여줍니다.
<interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:[::1]}"/> </interface> .... </interfaces>
5장. JBoss EAP 보안
JBoss EAP는 자체 인터페이스 및 서비스에 대한 보안을 구성하고 실행 중인 애플리케이션에 보안을 제공하는 기능을 제공합니다.
- 일반 보안 개념과 JBoss EAP별 보안 개념에 대한 개요는 보안 아키텍처 가이드를 참조하십시오.
- JBoss EAP 자체 보안에 대한 자세한 내용은 Configure Server Security(서버 보안 구성 방법 )를 참조하십시오.
- JBoss EAP 에 배포된 애플리케이션에 대한 보안을 제공하는 방법에 대한 자세한 내용은 ID 관리 구성을 참조하십시오.
- Kerberos를 사용하여 JBoss EAP에 대한 SSO를 구성하는 방법에 대한 자세한 내용은 Kerberos로 SSO를 설정하는 방법을 참조하십시오.
- SAML v2를 사용하여 JBoss EAP에 대한 SSO를 구성하는 방법에 대한 자세한 내용은 SAML v2로 SSO를 설정하는 방법을 참조하십시오.
6장. JBoss EAP 클래스 로드
JBoss EAP는 모듈식 클래스 로드 시스템을 사용하여 배포된 애플리케이션의 클래스 경로를 제어합니다. 이 시스템은 기존의 계층형 클래스 로더 시스템보다 더 높은 유연성과 제어력을 제공합니다. 개발자는 애플리케이션에 사용할 수 있는 클래스를 세부적으로 제어할 수 있으며, 자체 애플리케이션에 대해 애플리케이션 서버에서 제공하는 클래스를 무시하도록 배포를 구성할 수 있습니다.
모듈식 클래스 로더는 모든 Java 클래스를 모듈이라는 논리 그룹으로 분리합니다. 각 모듈은 해당 모듈의 클래스를 자체 클래스 경로에 추가하기 위해 다른 모듈에 대한 종속성을 정의할 수 있습니다. 배포된 각 JAR 및 WAR 파일은 모듈로 처리되므로 개발자는 모듈 구성을 애플리케이션에 추가하여 애플리케이션 클래스 경로의 콘텐츠를 제어할 수 있습니다.
6.1. module
모듈은 클래스 로드 및 종속성 관리에 사용되는 클래스의 논리적 그룹화입니다. JBoss EAP는 정적 및 동적 두 가지 유형의 모듈을 식별합니다. 이 둘의 주요 차이점은 패키지 방식입니다.
정적 모듈
정적 모듈은 애플리케이션 서버의 EAP_HOME/modules/
디렉터리에 정의됩니다. 각 모듈은 하위 디렉터리로 존재합니다(예: EAP_HOME/modules/com/mysql/
). 각 모듈 디렉터리에는 main을 기본값으로 하고 module.xml
구성 파일과 필요한 JAR 파일이 포함된
슬롯 하위 디렉터리가 포함됩니다. 모든 애플리케이션 서버 제공 API는 자카르타 EE API 및 기타 API를 포함하여 정적 모듈로 제공됩니다.
예제: MySQL JDBC(Java Database Connectivity) Driver module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-8.0.12.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
모듈 이름 com.mysql
은 슬롯 이름 main
을 제외하고 모듈의 디렉터리 구조와 일치해야 합니다.
사용자 지정 정적 모듈 생성은 동일한 타사 라이브러리를 사용하는 동일한 서버에 많은 애플리케이션을 배포하는 경우 유용할 수 있습니다. 각 애플리케이션과 함께 이러한 라이브러리를 결합하는 대신, 이러한 라이브러리를 포함하는 모듈을 관리자가 생성하고 설치할 수 있습니다. 그러면 애플리케이션이 사용자 지정 정적 모듈에 명시적 종속성을 선언할 수 있습니다.
JBoss EAP 배포에 제공되는 모듈은 EAP_HOME/modules
디렉터리 내의 시스템
디렉터리에 있습니다. 따라서 타사가 제공하는 모든 모듈과 분리됩니다. 모든 Red Hat은 JBoss EAP 상단에 계층화된 제품을 제공했습니다. 또한 시스템
디렉토리 내에 모듈을 설치합니다.
사용자는 사용자 지정 모듈이 모듈당 하나의 디렉터리를 사용하여 EAP_HOME/modules
디렉터리에 설치되어 있는지 확인해야 합니다. 이렇게 하면 시스템
디렉터리에 이미 존재하는 모듈의 사용자 지정 버전이 제공된 버전 대신 로드됩니다. 이러한 방식으로 사용자 제공 모듈이 시스템 모듈보다 우선합니다.
JBOSS_MODULEPATH
환경 변수를 사용하여 JBoss EAP에서 모듈을 검색하는 위치를 변경하는 경우 이 제품은 지정된 위치 중 하나 내에서 시스템
하위 디렉터리 구조를 찾습니다. 시스템
구조는 JBOSS_MODULEPATH
로 지정된 위치에 있어야 합니다.
JBoss EAP 7.1부터는 module.xml
파일의 resource-root 경로
요소에서 절대 경로 사용도 지원됩니다. 이렇게 하면 리소스 라이브러리를 EAP_HOME/modules
디렉터리로 이동할 필요 없이 액세스할 수 있습니다.
예제: module.xml
파일의 절대 경로
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="oracle.jdbc"> <resources> <resource-root path="/home/redhat/test.jar"/> </resources> </module>
동적 모듈
동적 모듈은 각 JAR 또는 WAR 배포 또는 EAR의 각 하위 배포에 대해 애플리케이션 서버에서 생성 및 로드됩니다. 동적 모듈의 이름은 배포된 아카이브의 이름에서 파생됩니다. 배포는 모듈로 로드되므로 종속성을 구성하고 다른 배포에서 종속성으로 사용할 수 있습니다.
모듈은 필요한 경우에만 로드됩니다. 이는 일반적으로 명시적 또는 암시적 종속성이 있는 애플리케이션이 배포되는 경우에만 발생합니다.
사전 정의된 모듈
JBoss EAP 7.2부터 기본 모듈 로더를 사용할 때 사전 정의된 모듈 세트를 사용할 수 있습니다. 모든 JBoss 모듈 API를 포함하는 특수 모듈인 org.jboss.modules
는 항상 사용할 수 있으며 JBoss 모듈에서 제공합니다. Java 9 이상에서 제공되는 표준 JMS(Java Platform Module System) 모듈은 표준 이름으로도 사용할 수 있습니다. JDK 8을 사용하는 경우 JBoss 모듈에서 JDK 9 모듈을 에뮬레이션합니다.
Java 9 이상에서 사용 가능한 플랫폼 모듈 목록은 해당 JDK 설명서를 참조하십시오.
Java 8에 제공된 플랫폼 모듈 목록을 보려면 Java 8 에 제공되는 플랫폼 모듈을 참조하십시오.
6.2. 모듈 종속성
모듈 종속성은 한 모듈이 작동하기 위해 하나 이상의 다른 모듈의 클래스가 필요함을 나타냅니다. JBoss EAP가 모듈을 로드할 때 모듈 클래스 로더는 해당 모듈의 종속성을 구문 분석하고 각 종속성의 클래스를 클래스 경로에 추가합니다. 지정된 종속성을 찾을 수 없는 경우 모듈이 로드되지 않습니다.
모듈 및 모듈 클래스 로드 시스템에 대한 자세한 내용은 모듈 섹션을 참조하십시오.
배포된 애플리케이션(예: JAR 또는 WAR)은 동적 모듈로 로드되며, 종속성을 사용하여 JBoss EAP에서 제공하는 API에 액세스합니다.
종속성에는 명시적 및 암시적 이라는 두 가지 유형의 종속성이 있습니다.
- 명시적 종속성
-
명시적 종속성은 구성 파일의 개발자가 선언합니다. 정적 모듈은 해당
module.xml
파일에서 종속성을 선언할 수 있습니다. 동적 모듈은 배포의MANIFEST.MF 또는
배포 설명자에 종속성을 선언할 수 있습니다.jboss-deployment-structure.
xml - 암시적 종속성
특정 조건 또는 메타 데이터를 배포에서 찾을 수 있는 경우 암시적 종속성은 JBoss EAP에서 자동으로 추가됩니다. JBoss EAP와 함께 제공되는 Jakarta EE API는 배포에서 암시적 종속성을 탐지하여 추가된 모듈의 예입니다.
jboss-deployment-structure.xml
배포 설명자 파일을 사용하여 특정 암시적 종속성을 제외하도록 배포를 구성할 수도 있습니다. 이는 애플리케이션이 암시적 종속성으로 추가하려고 할 특정 버전의 라이브러리를 번들할 때 유용할 수 있습니다.
선택적 종속성
명시적 종속성은 옵션으로 지정할 수 있습니다. 선택적 종속성을 로드하지 않으면 모듈이 로드되지 않습니다. 그러나 나중에 종속성을 사용할 수 있게 되면 모듈의 클래스 경로에 추가되지 않습니다. 모듈이 로드되면 종속성을 사용할 수 있어야 합니다.
종속성 내보내기
모듈의 클래스 경로에는 자체 클래스와 즉각적인 종속성만 포함됩니다. 모듈은 해당 종속성 중 하나의 종속성 클래스에 액세스할 수 없습니다. 그러나 모듈은 명시적 종속성을 내보내도록 지정할 수 있습니다. 내보낸 종속성은 내보내는 모듈에 종속된 모든 모듈에 제공됩니다.
예를 들어, Module A 는 Module B 에 따라 달라지며, Module B 는 Module C 에 따라 다릅니다. 모듈 A 는 모듈 B 의 클래스에 액세스할 수 있으며, 모듈 B 는 모듈 C 의 클래스에 액세스할 수 있습니다. 모듈 A 는 다음과 같은 경우가 아니면 모듈 C 의 클래스에 액세스할 수 없습니다.
- 모듈 A 는 모듈 C 에 명시적 종속성을 선언합니다.
- 모듈 B 는 모듈 C 에 대한 종속성을 내보냅니다.
글로벌 모듈
글로벌 모듈은 JBoss EAP가 모든 애플리케이션에 대한 종속성으로 제공하는 모듈입니다. 모든 모듈은 JBoss EAP의 글로벌 모듈 목록에 추가하여 전역적으로 만들 수 있습니다. 모듈을 변경할 필요가 없습니다.
자세한 내용은 Define Global Modules 섹션을 참조하십시오.
6.3. 사용자 정의 모듈 만들기
사용자 지정 정적 모듈을 추가하여 JBoss EAP에서 실행되는 배포에 리소스를 사용할 수 있도록 할 수 있습니다. 수동으로 또는 관리 CLI를 사용하여 모듈을 생성할 수 있습니다.
모듈을 생성한 후에는 애플리케이션에서 해당 리소스를 사용할 수 있어야 하는 경우 모듈을 종속성으로 추가해야 합니다.
수동으로 사용자 정의 모듈 만들기
다음 단계를 사용하여 사용자 지정 모듈을 수동으로 생성할 수 있습니다.
EAP_HOME/modules/
디렉터리에 적절한 디렉터리 구조를 생성합니다.예제: MySQL JDBC 드라이버 디렉터리 구조 만들기
$ cd EAP_HOME/modules/ $ mkdir -p com/mysql/main
JAR 파일 또는 기타 필요한 리소스를
main/
하위 디렉터리에 복사합니다.예제: Copy MySQL JDBC Driver JAR
$ cp /path/to/mysql-connector-java-8.0.12.jar EAP_HOME/modules/com/mysql/main/
파일에서 적절한 리소스와 종속성을 지정하여
main/
하위 디렉터리에module.xml
파일을 생성합니다.예제: MySQL JDBC 드라이버
module.xml
파일<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-8.0.12.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI를 사용하여 사용자 지정 모듈 만들기
module add management CLI 명령을 사용하여 사용자 지정 모듈을
생성할 수 있습니다.
모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.
기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
- JBoss EAP 서버 시작.
관리 CLI를 시작합니다.
$ EAP_HOME/bin/jboss-cli.sh
모듈 add management
CLI 명령을 사용하여 새 core 모듈을 추가합니다.module add --name=MODULE_NAME --resources=PATH_TO_RESOURCE --dependencies=DEPENDENCIES
예제: MySQL 모듈 만들기
module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
자체
module.xml 파일 제공, 외부 모듈 디렉터리 사용 또는 모듈에 대한 대체 슬롯 지정 등 이 명령을 사용자 지정하기 위해 사용 가능한 인수는 모듈 명령
인수에서 참조하십시오. 이 명령을 사용하여모듈 추가 및 제거에 대한 자세한 내용은 module --help
를 실행할 수도 있습니다.
모듈을 종속성으로 추가합니다
애플리케이션이 이 모듈의 리소스에 액세스할 수 있으려면 모듈을 종속성으로 추가해야 합니다.
- 배포 설명자를 사용하여 애플리케이션 특정 종속성을 추가하려면 JBoss EAP 개발 가이드 의 배포에 명시적 모듈 종속성 추가 섹션을 참조하십시오.
- 모듈을 모든 애플리케이션에 대한 종속성으로 추가하는 방법은 글로벌 모듈 정의 섹션을 참조하십시오.
예를 들어 다음 단계에서는 여러 속성 파일이 포함된 JAR 파일을 모듈로 추가하고 글로벌 모듈을 정의하여 애플리케이션에서 이러한 속성을 로드할 수 있습니다.
JAR 파일을 코어 모듈로 추가합니다.
module add --name=myprops --resources=/path/to/properties.jar
이 모듈을 모든 배포에서 사용할 수 있도록 글로벌 모듈로 정의합니다.
/subsystem=ee:list-add(name=global-modules,value={name=myprops})
그런 다음 애플리케이션은 JAR에 포함된 속성 파일 중 하나에서 속성을 검색할 수 있습니다.
Thread.currentThread().getContextClassLoader().getResource("my.properties");
6.4. 사용자 지정 모듈 제거
사용자 지정 정적 모듈은 수동으로 또는 관리 CLI를 사용하여 제거할 수 있습니다.
수동으로 사용자 정의 모듈 제거
모듈을 수동으로 제거하기 전에 배포된 애플리케이션이나 데이터 소스와 같은 서버 구성의 다른 위치에서 필요하지 않은지 확인합니다.
사용자 지정 모듈을 제거하려면 module. xml 파일 및 관련 JAR 파일 또는 기타 리소스를 포함하는
디렉터리를 제거합니다. 예를 들어 EAP_HOME/modules/
에서 모듈EAP_HOME/modules/com/mysql/main/
디렉터리를 제거하여 기본
슬롯에서 사용자 지정 MySQL JDBC 드라이버 모듈을 제거합니다.
관리 CLI를 사용하여 사용자 지정 모듈 제거
모듈 제거 관리 CLI 명령을 사용하여 사용자 지정 모듈을 제거할
수 있습니다.
모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.
기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
- JBoss EAP 서버 시작.
관리 CLI를 시작합니다.
$ EAP_HOME/bin/jboss-cli.sh
모듈 remove management
CLI 명령을 사용하여 사용자 지정 모듈을 제거합니다.module remove --name=MODULE_NAME
-
제거할 모듈이
main
이외의 슬롯에 있는 경우--slot
인수를 사용합니다.
예제: MySQL 모듈 제거
module remove --name=com.mysql
-
제거할 모듈이
이 명령을 사용하여 모듈 추가 및 제거에 대한 자세한 내용은 module --help
를 실행합니다.
6.5. 글로벌 모듈 정의
모듈을 모든 배포에 종속 항목으로 추가하는 JBoss EAP에 대해 글로벌 모듈 목록을 정의할 수 있습니다.
글로벌 모듈로 구성할 모듈의 이름을 알아야 합니다. 포함된 모듈의 전체 목록 및 지원 여부는 Red Hat 고객 포털에서 Red Hat JBoss Enterprise Application Platform 7에 포함된 모듈을 참조하십시오. 배포 시 모듈에 대한 규칙 명명은 동적 모듈 명명 섹션 을 참조하십시오.
다음 관리 CLI 명령을 사용하여 글로벌 모듈 목록을 정의합니다.
/subsystem=ee:write-attribute(name=global-modules,value=[{name=MODULE_NAME_1},{name=MODULE_NAME_2}]
다음 관리 CLI 명령을 사용하여 단일 모듈을 기존 글로벌 모듈 목록에 추가합니다.
/subsystem=ee:list-add(name=global-modules,value={name=MODULE_NAME})
또한 Configuration (구성) 탭에서 EE 하위 시스템으로 이동하고 Global Modules (글로벌 모듈) 섹션을 선택하여 관리 콘솔을 사용하여 글로벌 모듈을 추가하고 제거할 수도 있습니다.
외부 종속성에서 글로벌 모듈에 액세스하려면 명시적으로 사용해야 합니다. 다음 옵션을 사용하여 글로벌 모듈의 서비스를 외부에서 사용할 수 있습니다.
-
jboss-deployment-structure.xml
의 모듈에services="import"
추가 글로벌 모듈 정의에
services="true"
를 추가합니다./subsystem=ee:write-attribute(name=global-modules,value=[{name=module1,services=true}]
또는 여러 모듈을 추가할 때 다음을 수행합니다.
/subsystem=ee:write-attribute(name=global-modules,value=[{name=module1,services=true},{name=module2,services=false}]
기존 목록에 새 모듈을 추가하려면 다음을 수행합니다.
/subsystem=ee:list-add(name=global-modules,value={name=module1,services=true})
-
관리 콘솔을 사용하여 글로벌 모듈을 정의할 때 Services 속성의 값이
On
인지 확인합니다.
6.6. 글로벌 디렉토리 생성
글로벌 디렉터리는 글로벌 모듈 접근법에 대한 더 나은 대안을 제공합니다. 예를 들어 글로벌 모듈에 나열된 라이브러리 이름을 변경하려면 글로벌 모듈을 제거하고 라이브러리의 이름을 변경한 다음 새 글로벌 모듈에 라이브러리를 추가해야 합니다. 글로벌 디렉터리에 나열된 라이브러리의 이름을 변경하는 경우 서버를 다시 로드하여 모든 배포에 라이브러리 이름을 변경할 수 있도록 해야 합니다.
글로벌 디렉터리를 사용하여 다음을 수행할 수 있습니다.
- 배포된 애플리케이션에서 여러 라이브러리를 공유합니다.
- 일반적으로 애플리케이션 라이브러리에 추가된 공통 프레임워크를 공통 위치로 이동하여 라이브러리를 유지 관리합니다.
글로벌 디렉터리를 만들 때 EE 하위 시스템은 글로벌 디렉터리를 구성한 다음 디렉터리를 스캔하여 JBoss 모듈 모듈 종속성을 생성합니다. 모듈 종속성에는 글로벌 디렉터리 라이브러리와 JAR 파일이 포함됩니다. 이 모듈 종속성에는 다음 리소스 로더도 포함됩니다.
- 경로 리소스 로더는 파일을 애플리케이션의 리소스로 제공합니다.
- 리소스 로더는 JAR 파일에 포함된 클래스를 애플리케이션에 제공합니다.
EE 하위 시스템은 배포된 각 애플리케이션에 대한 시스템 종속성으로 모듈 종속성을 추가합니다.
사전 요구 사항
운영 체제에 표준 디렉터리를 생성합니다. 이 표준 디렉터리에는 애플리케이션에 배포해야 하는 모든 JAR 파일 및 리소스가 포함되어야 합니다. 이렇게 하면 디렉터리 트리가 생성됩니다.
애플리케이션에 복사된 공통 라이브러리 목록을 보여주는 공통 디렉터리의 예:
/my-common-libs/log4j2.xml /my-common-libs/libs/log4j-api-2.14.1.jar /my-common-libs/libs/log4j-core-2.14.1.jar
참고서버는 애플리케이션을 배포하고 글로벌 디렉터리를 로드하므로 서버의 라이브러리 버전을 재정의하도록 글로벌 디렉터리를 구성할 수 없습니다. 글로벌 디렉터리는 서버와 함께 제공된 라이브러리를 대체할 수 없습니다.
절차
서버 설정에 따라 글로벌 디렉터리를 생성합니다. 선택적
relative-to
특성을 사용하여 글로벌 디렉터리를 상대 경로로 설정할 수 있습니다.독립 실행형 서버에서 글로벌 디렉터리를 생성하는 예:
[standalone@localhost:9990 /] /subsystem=ee/global-directory=my-common-libs:add(path=my-common-libs, relative-to=jboss.home.dir)
관리형 도메인의 서버에서 글로벌 디렉터리를 생성하는 예:
[domain@localhost:9990 /] /profile=default/subsystem=ee/global-directory=my-common-libs:add(path=my-common-libs, relative-to=jboss.server.data.dir)
관리형 도메인의 서버의 경우
relative-path
특성을 사용하여domain.xml
에 정의된 JBoss EAP 프로필 아래에 글로벌 디렉터리를 추가할 수 있습니다. 이relative-to
속성에 대한 시스템 경로 또는 사용자 정의 시스템 경로를 지정할 수 있습니다.참고관리형 도메인에서 서버를 실행하는 경우 글로벌 디렉터리의 콘텐츠가 모든 서버 인스턴스에서 일관되게 유지되는지 확인해야 합니다. 예를 들어 각 호스트에는 글로벌 디렉터리 콘텐츠가 포함된 로컬 파일 시스템 디렉터리가 포함되어야 합니다.
서버 인스턴스를 다시 로드하여 글로벌 디렉터리를 활성화합니다.
서버가 루트 디렉토리부터 시작하여 각 하위 디렉터리 수준을 포함하여 디렉터리 트리의 콘텐츠를 알파벳순으로 스캔할 수 있도록 서버를 다시 로드해야 합니다. 서버는 각 디렉터리 수준의 파일을 알파벳순으로 JBoss Modules 모듈 종속성에 추가합니다.
글로벌 디렉터리의 내용을 변경하거나 글로벌 디렉터리에서 JAR 파일을 변경하거나 추가하는 경우 배포된 애플리케이션에서 변경할 수 있도록 서버를 다시 로드해야 합니다. 예를 들어 글로벌 디렉터리에서 JAR 라이브러리를 교체하는 경우 서버를 다시 로드하여 글로벌 디렉터리를 다시 스캔하고 배포된 애플리케이션을 변경된 JAR 라이브러리로 업데이트합니다.
추가 리소스
- JBoss EAP에서 글로벌 모듈 정의에 대한 자세한 내용은 글로벌 모듈 정의를 참조하십시오.
- 파일 시스템 경로에 논리적 이름 사용에 대한 자세한 내용은 파일 시스템 경로에서 참조하십시오.
- JBoss EAP 프로필에 대한 자세한 내용은 Managing JBoss EAP Profiles 를 참조하십시오.
- 도메인 컨트롤러 사용에 대한 자세한 내용은 도메인 컨트롤러 정보를 참조하십시오.
6.7. 글로벌 디렉토리 구성의 현재 값 읽기
read -resource 작업을 사용하여 글로벌 디렉터리 구성의 현재 값을 읽을 수
있습니다.
절차
서버 설정에 따라
read-resource
작업을 사용하여 글로벌 디렉터리 구성의 현재 값을 읽습니다.독립 실행형 서버에서 글로벌 디렉터리 구성의 현재 값을 읽는 예제 출력 예.
[standalone@localhost:9990 /] /subsystem=ee/global-directory=my-common-libs:read-resource { "outcome" => "success", "result" => { "path" => "my-common-libs", "relative-to" => "jboss.home.dir" } }
관리형 도메인의 서버에서 글로벌 디렉터리 구성의 현재 값을 읽는 예제 출력 예.
[domain@localhost:9990 /] /subsystem=ee/global-directory=my-common-libs:read-resource { "outcome" => "success", "result" => { "path" => "my-common-libs", "relative-to" => "jboss.server.data.dir" } }
6.8. 전역 디렉토리 제거
선택한 서버에서 글로벌 디렉터리를 제거할 수 있습니다. 서버 구성 파일에서 글로벌 디렉터리 리소스만 제거합니다. 기본 디렉터리 또는 해당 파일은 제거하지 않습니다.
절차
독립 실행형 서버에서 글로벌 디렉터리를 제거하려면 다음 명령을 사용합니다.
[standalone@localhost:9990 /] /subsystem=ee/global-directory=my-common-libs:remove()
관리형 도메인의 서버에서 글로벌 디렉터리를 제거하려면 다음 명령을 사용합니다.
[domain@localhost:9990 /] /profile=default/subsystem=ee/global-directory=my-common-libs:remove()
6.9. 하위 배포 격리 구성
EAR(Enterprise Archive)의 각 하위 배포는 자체 클래스 로더가 있는 동적 모듈입니다. 하위 배포는 항상 parent 모듈에 대한 암시적 종속성을 가지므로 EAR/lib
의 클래스에 액세스할 수 있습니다. 기본적으로 하위 배포는 해당 EAR 내의 다른 하위 배포 리소스에 액세스할 수 있습니다.
하위 배포가 다른 하위 배포에 속하는 클래스에 액세스할 수 없도록 하려면 JBoss EAP에서 엄격한 하위 배포 격리를 활성화할 수 있습니다. 이 설정은 모든 배포에 영향을 미칩니다.
모든 배포에 대해 Subdeployment 모듈 격리 활성화
하위 배포 격리는 관리 콘솔 또는 the ee
하위 시스템에서 관리 CLI를 사용하여 활성화하거나 비활성화할 수 있습니다. 기본적으로 하위 배포 격리는 false로 설정되어 하위 배포가 EAR 배포 내의 다른 하위 배포 리소스에 액세스할 수 있습니다.
다음 관리 CLI를 사용하여 EAR 하위 배포 격리를 활성화합니다.
/subsystem=ee:write-attribute(name=ear-subdeployments-isolated,value=true)
EAR의 하위 배포에서는 더 이상 다른 하위 배포의 리소스에 액세스할 수 없습니다.
6.10. 외부 JBoss EAP 모듈 디렉터리 정의
JBoss EAP 모듈의 기본 디렉터리는 EAP_HOME/modules
입니다. JBOSS_MODULEPATH
변수를 사용하여 JBoss EAP 모듈에 대해 다른 디렉터리를 지정할 수 있습니다. 다음 단계에 따라 JBoss EAP 시작 구성 파일에서 이 변수를 설정합니다.
JBoss EAP 시작 구성 파일에서 이를 설정하는 대신 JBOSS_MODULEPATH
를 환경 변수로 설정할 수도 있습니다.
시작 구성 파일을 편집합니다.
-
독립 실행형 서버로 실행하는 경우
EAP_HOME/bin/standalone.conf
파일을 편집하거나 Windows Server의 경우standalone.conf.bat
를 편집합니다. -
관리형 도메인에서 실행하는 경우
EAP_HOME/bin/domain.conf
파일을 편집하거나 Windows Server의 경우domain.conf.bat
를 편집합니다.
-
독립 실행형 서버로 실행하는 경우
JBOSS_MODULEPATH
변수를 설정합니다. 예를 들면 다음과 같습니다.JBOSS_MODULEPATH="/path/to/modules/directory/"
디렉터리 목록을 지정하려면 콜론(
:
)을 사용하여 디렉터리 목록을 구분합니다.참고Windows Server의 경우 다음 구문을 사용하여
JBOSS_MODULEPATH
변수를 설정합니다.set "JBOSS_MODULEPATH /path/to/modules/directory/"
디렉터리 목록을 지정하려면 세미콜론(
;
)을 사용하여 디렉터리 목록을 구분합니다.
6.11. 동적 모듈 명명 규칙
JBoss EAP는 다음 규칙에 따라 이름이 지정된 모든 배포를 모듈로 로드합니다.
WAR 및 JAR 파일의 배포는 다음 형식을 사용하여 이름이 지정됩니다.
deployment.DEPLOYMENT_NAME
예를 들어
inventory.war
및store.jar
는 각각 deployment.inventory.war 및
의 모듈 이름을 가집니다.deployment.
store.jarEAR(Enterprise Archive) 내의 하위 배포 이름은 다음 형식을 사용하여 이름을 지정합니다.
deployment.EAR_NAME.SUBDEPLOYMENT_NAME
예를 들어 엔터프라이즈 아카이브
accounts
.ear 내에서 reports.war
의 하위 배포에는 deployment.accounts.ear.reports.war
의 모듈 이름이 있습니다.
7장. 애플리케이션 배포
JBoss EAP에는 관리자와 개발자 모두에 적용할 수 있는 다양한 애플리케이션 배포 및 구성 옵션이 있습니다. 관리자의 경우 관리 콘솔과 관리 CLI 는 프로덕션 환경에서 애플리케이션 배포를 관리하는 데 이상적인 그래픽 및 명령줄 인터페이스를 제공합니다. 개발자의 경우 애플리케이션 배포 테스트 옵션에는 구성 가능한 파일 시스템 배포 스캐너, HTTP API, Red Hat CodeReady Studio, Maven 등의 IDE가 포함됩니다.
애플리케이션을 배포하는 경우 org.jboss.metadata.parser.validate
시스템 속성을 true
로 설정하여 배포 설명자에 대한 검증을 활성화할 수 있습니다. 다음 방법 중 하나를 수행할 수 있습니다.
서버를 시작하는 동안.
$ EAP_HOME/bin/standalone.sh -Dorg.jboss.metadata.parser.validate=true
다음 관리 CLI 명령을 사용하여 서버 구성에 추가하면 됩니다.
/system-property=org.jboss.metadata.parser.validate:add(value=true)
7.1. 관리 CLI를 사용하여 애플리케이션 배포
관리 CLI를 사용하여 애플리케이션을 배포하면 배포 스크립트를 생성하고 실행할 수 있는 단일 명령줄 인터페이스가 제공됩니다. 이 스크립팅 기능을 사용하여 특정 애플리케이션 배포 및 관리 시나리오를 구성할 수 있습니다. 독립 실행형 서버로 실행할 때 단일 서버에 대한 배포를 관리하거나 관리형 도메인에서 실행할 때 전체 서버 네트워크를 관리할 수 있습니다.
7.1.1. 관리 CLI를 사용하여 독립 실행형 서버에 애플리케이션 배포
애플리케이션 배포
관리 CLI에서 배포 deploy-file
명령을 사용하고 애플리케이션 배포 경로를 지정합니다.
deployment deploy-file /path/to/test-application.war
배포가 성공하면 관리 CLI에 대한 출력이 생성되지 않지만 서버 로그에 배포 메시지가 표시됩니다.
WFLYSRV0027: Starting deployment of "test-application.war" (runtime-name: "test-application.war") WFLYUT0021: Registered web context: /test-application WFLYSRV0010: Deployed "test-application.war" (runtime-name : "test-application.war")
마찬가지로 다음 배포
명령을 사용할 수 있습니다.
-
배포 deploy-cli-archive
를 사용하여.cli
아카이브 파일에서 콘텐츠를 배포합니다. CLI 배포 아카이브는.cli
확장자가 있는JAR
파일입니다. 배포해야 하는 애플리케이션 아카이브와 CLI 스크립트 파일,deploy.scr 및
을 포함하고 명령 및 작업이 포함되어 있습니다. 하나의 스크립트 파일인undeploy.scr
deploy.scr
에는 애플리케이션 아카이브를 배포하고 환경을 설정하는 명령과 작업이 포함되어 있습니다. 다른 스크립트 파일인undeploy.scr
에는 애플리케이션 아카이브 배포를 취소하고 환경을 정리하는 명령이 포함되어 있습니다. -
배포 deploy-url
을 사용하여 URL에서 참조하는 콘텐츠를 배포합니다.
배포 활성화 명령을 사용하여 비활성화된 애플리케이션을 활성화할 수도 있습니다.
--
옵션을 사용하여 runtime-name 속성을 지정하는 경우 이름에 runtime-name
.war
확장을 포함해야 합니다. 그렇지 않으면 웹 컨텍스트는 JBoss EAP에 의해 등록되지 않습니다.
애플리케이션 배포 취소
관리 CLI에서 배포 undeploy
명령을 사용하고 배포 이름을 지정합니다. 그러면 리포지토리에서 배포 콘텐츠가 삭제됩니다. 배포를 취소할 때 배포 콘텐츠를 유지하기 위해 애플리케이션 비활성화 를 참조하십시오.
deployment undeploy test-application.war
배포가 완료되면 관리 CLI에 대한 출력이 생성되지 않지만 서버 로그에 배포되지 않은 메시지가 표시됩니다.
WFLYUT0022: Unregistered web context: /test-application WFLYSRV0028: Stopped deployment test-application.war (runtime-name: test-application.war) in 62ms WFLYSRV0009: Undeployed "test-application.war" (runtime-name: "test-application.war")
마찬가지로 배포 undeploy-cli-archive를 사용하여
아카이브 파일에서 콘텐츠 배포를 취소할 수 있습니다. 와일드카드(.cli
*
)를 사용하여 모든 배포 배포를 취소할 수도 있습니다.
deployment undeploy *
애플리케이션 비활성화
리포지토리에서 배포 콘텐츠를 제거하지 않고 배포된 애플리케이션을 비활성화합니다.
deployment disable test-application.war
배포 disable-all
명령을 사용하여 모든 배포를 비활성화할 수 있습니다.
deployment disable-all
애플리케이션 활성화
배포된 애플리케이션을 비활성화합니다.
deployment enable test-application.war
배포 enable-all
명령을 사용하여 모든 배포를 활성화할 수 있습니다.
deployment enable-all
배포 나열
관리 CLI에서 배포 info
명령을 사용하여 배포 정보를 나열합니다.
deployment info
출력에 런타임 이름, 상태, 활성화 여부와 같은 각 배포에 대한 세부 정보가 표시됩니다.
NAME RUNTIME-NAME PERSISTENT ENABLED STATUS helloworld.war helloworld.war true true OK test-application.war test-application.war true true OK
이름으로 배포 정보를 표시하려면 다음을 수행합니다.
deployment info helloworld.war
배포 list 명령을 사용하여 모든 배포를 나열
할 수도 있습니다.
7.1.2. 관리 CLI를 사용하여 관리형 도메인에 애플리케이션 배포
애플리케이션 배포
관리 CLI에서 배포 deploy-file
명령을 사용하고 애플리케이션 배포 경로를 지정합니다. 또한 애플리케이션을 배포해야 하는 서버 그룹을 지정해야 합니다.
애플리케이션을 모든 서버 그룹에 배포하려면 다음을 수행합니다.
deployment deploy-file /path/to/test-application.war --all-server-groups
애플리케이션을 특정 서버 그룹에 배포하려면 다음을 수행합니다.
deployment deploy-file /path/to/test-application.war --server-groups=main-server-group,other-server-group
배포가 성공하면 관리 CLI에 대한 출력이 생성되지 않지만, 서버 로그에 영향을 받는 각 서버에 대한 배포 메시지가 표시됩니다.
[Server:server-one] WFLYSRV0027: Starting deployment of "test-application.war" (runtime-name: "test-application.war") [Server:server-one] WFLYUT0021: Registered web context: /test-application [Server:server-one] WFLYSRV0010: Deployed "test-application.war" (runtime-name : "test-application.war")
마찬가지로 다음 배포
명령을 사용할 수 있습니다.
-
배포 deploy-cli-archive
명령을 사용하여.cli
아카이브 파일에서 콘텐츠를 배포합니다. CLI 배포 아카이브는.cli
확장자가 있는JAR
파일입니다. 배포해야 하는 애플리케이션 아카이브와 CLI 스크립트 파일,deploy.scr 및
을 포함하고 명령 및 작업이 포함되어 있습니다. 하나의 스크립트 파일인undeploy.scr
deploy.scr
에는 애플리케이션 아카이브를 배포하고 환경을 설정하는 명령과 작업이 포함되어 있습니다. 다른 스크립트 파일인undeploy.scr
에는 애플리케이션 아카이브 배포를 취소하고 환경을 정리하는 명령이 포함되어 있습니다. -
배포 deploy-url
명령을 사용하여 URL에서 참조하는 콘텐츠를 배포합니다.
배포 활성화 명령을 사용하여 비활성화된 애플리케이션을 활성화할 수도 있습니다.
--
옵션을 사용하여 runtime-name 속성을 지정하는 경우 이름에 runtime-name
.war
확장을 포함해야 합니다. 그렇지 않으면 웹 컨텍스트는 JBoss EAP에 의해 등록되지 않습니다.
애플리케이션 배포 취소
관리 CLI에서 배포 undeploy
명령을 사용하고 배포 이름을 지정합니다. 또한 애플리케이션을 배포 취소해야 하는 서버 그룹을 지정해야 합니다. 특정 서버 그룹에서 배포 취소를 위해 애플리케이션 비활성화 를 참조하십시오.
해당 배포를 사용하여 모든 서버 그룹에서 애플리케이션 배포를 취소합니다.
deployment undeploy test-application.war --all-relevant-server-groups
배포가 성공하면 관리 CLI에 대한 출력을 생성하지 않지만, 서버 로그에 영향을 받는 각 서버에 대한 배포 취소 메시지가 표시됩니다.
[Server:server-one] WFLYUT0022: Unregistered web context: /test-application [Server:server-one] WFLYSRV0028: Stopped deployment test-application.war (runtime-name: test-application.war) in 74ms [Server:server-one] WFLYSRV0009: Undeployed "test-application.war" (runtime-name: "test-application.war")
마찬가지로 배포 undeploy-cli-archive
명령을 사용하여 .cli
아카이브 파일에서 콘텐츠 배포를 취소할 수 있습니다. 와일드카드(*
)를 사용하여 모든 배포 배포를 취소할 수도 있습니다.
deployment undeploy * --all-relevant-server-groups
애플리케이션 비활성화
배포된 애플리케이션을 특정 서버 그룹에서 비활성화하고 해당 배포가 있는 다른 서버 그룹의 리포지토리에 콘텐츠를 유지합니다.
deployment disable test-application.war --server-groups=other-server-group
배포 disable-all
명령을 사용하여 모든 배포를 비활성화할 수 있습니다.
deployment disable-all --server-groups=other-server-group
애플리케이션 활성화
배포된 애플리케이션을 비활성화합니다.
deployment enable test-application.war
배포 enable-all
명령을 사용하여 모든 배포를 활성화할 수 있습니다.
deployment enable-all --server-groups=other-server-group
배포 나열
관리 CLI에서 배포 info
명령을 사용하여 배포 정보를 나열합니다. 배포 이름 또는 서버 그룹별로 배포 정보를 나열할 수 있습니다.
이름으로 배포 정보를 표시하려면 다음을 수행합니다.
deployment info helloworld.war
출력에 각 서버 그룹의 배포 및 해당 상태가 나열됩니다.
NAME RUNTIME-NAME helloworld.war helloworld.war SERVER-GROUP STATE main-server-group enabled other-server-group added
서버 그룹별로 배포 정보를 표시하려면 다음을 수행합니다.
deployment info --server-group=other-server-group
출력에 지정된 서버 그룹에 대한 배포 및 해당 상태가 나열됩니다.
NAME RUNTIME-NAME STATE helloworld.war helloworld.war added test-application.war test-application.war enabled
배포 list 명령을 사용하여 도메인의 모든 배포를 나열
할 수도 있습니다.
7.2. 관리 콘솔을 사용하여 애플리케이션 배포
관리 콘솔을 사용하여 애플리케이션을 배포하면 사용하기 쉬운 그래픽 인터페이스가 제공됩니다. 서버 또는 서버 그룹에 배포된 애플리케이션을 한 눈에 확인하고 필요에 따라 콘텐츠 리포지토리에서 애플리케이션을 활성화, 비활성화 또는 제거할 수 있습니다.
7.2.1. 관리 콘솔을 사용하여 독립 실행형 서버에 애플리케이션 배포
배포는 JBoss EAP 관리 콘솔의 Deployments(배포 ) 탭에서 보고 관리할 수 있습니다.
애플리케이션 배포
Add (+)(추가(+)) 버튼을 클릭합니다. 배포를 업로드하거나,관리되지 않는 배포를 추가하거나, 빈 배포를 만들어 애플리케이션을 배포 하도록 선택할 수 있습니다. 배포는 기본적으로 활성화되어 있습니다.
배포 업로드
서버의 콘텐츠 리포지토리에 복사되고 JBoss EAP에서 관리할 애플리케이션을 업로드합니다.
관리되지 않는 배포 추가
배포 위치를 지정합니다. 이 배포는 서버의 콘텐츠 리포지토리에 복사되지 않으며 JBoss EAP에서 관리하지 않습니다.
빈 배포 생성
비어 있고 압축을 푼 배포를 만듭니다. 파일을 생성한 후 배포에 파일을 추가할 수 있습니다.
애플리케이션 배포 취소
배포를 선택하고 Undeploy (배포 취소) 옵션을 선택합니다. JBoss EAP는 콘텐츠 리포지토리에서 배포를 제거합니다.
애플리케이션 비활성화
배포를 선택하고 Disable (비활성화) 옵션을 선택하여 애플리케이션을 비활성화합니다. 그러면 배포가 배포 취소되지만 콘텐츠 리포지토리에서 제거되지 않습니다.
애플리케이션 교체
배포를 선택하고 교체 옵션을 선택합니다. 새 버전의 배포(원래와 이름이 동일해야 함)를 선택하고 Finish(완료)를 클릭합니다 . 이 명령은 원래 버전의 배포를 취소 및 제거한 다음 새 버전을 배포합니다.
7.2.2. 관리 콘솔을 사용하여 관리형 도메인에 애플리케이션 배포
JBoss EAP 관리 콘솔의 Deployments(배포 ) 탭에서 배포를 보고 관리할 수 있습니다.
콘텐츠 리포지토리
관리 및 관리되지 않는 모든 배포는 Content Repository(콘텐츠 리포지토리) 섹션에 나열됩니다. 여기에 서버 그룹에 배포를 추가하고 배포할 수 있습니다.
서버 그룹
하나 이상의 서버 그룹에 배포된 배포는 서버 그룹 섹션에 나열됩니다. 배포를 활성화하고 여기에 서버 그룹에 직접 추가할 수 있습니다.
애플리케이션 추가
- Content Repository(콘텐츠 리포지토리 )에서 Add(추가) 버튼을 클릭합니다.
- 배포를 업로드하거나 관리되지 않는 배포를 추가하여 애플리케이션을 추가하도록 선택합니다.
프롬프트에 따라 애플리케이션을 배포합니다.
배포를 활성화하려면 먼저 서버 그룹에 배포해야 합니다.
서버 그룹에 애플리케이션 배포
- Content Repository(콘텐츠 리포지토리 )에서 배포를 선택하고 Deploy (배포) 버튼을 클릭합니다.
- 이 배포를 배포해야 하는 하나 이상의 서버 그룹을 선택합니다.
- 선택적으로 옵션을 선택하여 선택한 서버 그룹에서 배포를 활성화합니다.
서버 그룹에서 애플리케이션 배포 취소
- Server Groups (서버 그룹)에서 적절한 서버 그룹을 선택합니다.
- 원하는 배포를 선택하고 Undeploy (배포 취소) 버튼을 클릭합니다.
Content Repository (콘텐츠 리포지토리)의 배포에 대한 Undeploy (배포 취소) 버튼을 한 번에 선택하여 여러 서버 그룹에서 배포를 취소할 수도 있습니다.
애플리케이션 제거
- 배포가 여전히 모든 서버 그룹에 배포되어 있으면 배포 배포를 취소해야 합니다.
- Content Repository(콘텐츠 리포지토리 )에서 배포를 선택하고 Remove (제거) 버튼을 클릭합니다.
그러면 콘텐츠 리포지토리에서 배포가 제거됩니다.
애플리케이션 비활성화
- Server Groups (서버 그룹)에서 적절한 서버 그룹을 선택합니다.
- 원하는 배포를 선택하고 Disable (비활성화) 버튼을 클릭합니다.
그러면 배포가 배포 취소되지만 콘텐츠 리포지토리에서 제거되지 않습니다.
애플리케이션 교체
- Content Repository(콘텐츠 리포지토리 )에서 배포를 선택하고 Replace (다시 교체) 버튼을 클릭합니다.
- 새 버전의 배포(원래와 이름이 동일해야 함)를 선택하고 Replace(다시 교체 )를 클릭합니다.
이 명령은 원래 버전의 배포를 취소 및 제거한 다음 새 버전을 배포합니다.
7.3. 배포 스캐너를 사용하여 애플리케이션 배포
배포 스캐너는 배포 디렉터리를 모니터링하여 애플리케이션을 배포합니다. 기본적으로 배포 스캐너는 변경 사항을 위해 5초마다 EAP_HOME/standalone/deployments/
디렉터리를 검사합니다. 마커 파일은 배포 상태를 나타내고 배포 취소 또는 재배포와 같은 배포에 대해 작업을 트리거하는 데 사용됩니다.
프로덕션 환경에서 애플리케이션 배포에 관리 콘솔 또는 관리 CLI를 사용하는 것이 좋지만 개발자 편의를 위해 배포 스캐너를 사용하여 배포하는 것이 좋습니다. 이를 통해 사용자는 신속한 개발 주기에 적합한 방식으로 애플리케이션을 빌드하고 테스트할 수 있습니다. 또한 배포 스캐너를 다른 배포 방법과 함께 사용하면 안 됩니다.
배포 스캐너는 JBoss EAP를 독립 실행형 서버로 실행하는 경우에만 사용할 수 있습니다.
7.3.1. 배포 스캐너를 사용하여 독립 실행형 서버에 애플리케이션 배포
XML, 압축 및 압축을 푼 콘텐츠의 자동 배포를 허용하거나 허용하지 않도록 배포 스캐너를 구성할 수 있습니다. 자동 배포를 비활성화하는 경우 배포 작업을 트리거하려면 마커 파일을 수동으로 생성해야 합니다. 사용 가능한 마커 파일 유형 및 용도에 대한 자세한 내용은 Deployment scanner Marker Files 섹션을 참조하십시오.
기본적으로 XML 및 압축된 콘텐츠에 대한 자동 배포가 활성화됩니다. 각 콘텐츠 유형에 대한 자동 배포 구성에 대한 자세한 내용은 배포 스캐너 구성을 참조하십시오.
배포 스캐너를 사용하여 배포하는 것은 개발자 편의를 위해 제공되며 프로덕션 환경에서는 사용하지 않는 것이 좋습니다. 또한 다른 배포 방법과 함께 사용해서는 안 됩니다.
애플리케이션 배포
배포 폴더에 콘텐츠를 복사합니다.
$ cp /path/to/test-application.war EAP_HOME/standalone/deployments/
자동 배포가 활성화되면 이 파일이 자동으로 선택되고 배포되고 .배포된
마커 파일이 생성됩니다. 자동 배포가 활성화되지 않은 경우 배포를 트리거하려면 수동으로 .dodeploy
마커 파일을 추가해야 합니다.
$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy
애플리케이션 배포 취소
. deployed
마커 파일을 제거하여 배포 취소를 트리거합니다.
$ rm EAP_HOME/standalone/deployments/test-application.war.deployed
자동 배포가 활성화된 경우 test-application.war
파일을 제거하여 배포 취소를 트리거할 수도 있습니다. 이는 압축을 푼 배포에는 적용되지 않습니다.
애플리케이션 재배포
.dodeploy
마커 파일을 만들어 재배포를 시작합니다.
$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy
7.3.2. Deployment scanner 구성
배포 스캐너는 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다. 검사 간격, 배포 폴더 위치 및 특정 애플리케이션 파일 유형의 자동 배포와 같은 배포 스캐너의 동작을 구성할 수 있습니다. 배포 스캐너를 완전히 비활성화할 수도 있습니다.
사용 가능한 모든 배포 스캐너 속성에 대한 자세한 내용은 Deployment scanner Attributes 섹션을 참조하십시오.
아래 관리 CLI 명령을 사용하여 기본 배포 스캐너를 구성합니다.
배포 스캐너 비활성화
/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)
이렇게 하면 기본
배포 스캐너가 비활성화됩니다.
검사 간격 변경
/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-interval,value=10000)
이렇게 하면 검사 간격 시간이 5000
밀리초(5밀리초)에서 10000밀리초(10
초)로 업데이트됩니다.
Deployment Folder 변경
/subsystem=deployment-scanner/scanner=default:write-attribute(name=path,value=/path/to/deployments)
그러면 배포 폴더의 위치가 EAP_HOME/standalone/deployments의 기본 위치에서 /
로 변경됩니다.
path/to /
deployments
relative-to
특성이 지정되지 않은 한 경로
값은 절대 경로로 취급됩니다. 이 경우 해당 경로가 상대적입니다.
압축을 푼 컨텐츠의 자동 배포 활성화
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-exploded,value=true)
이를 통해 압축 해제된 콘텐츠를 자동으로 배포할 수 있으며, 기본적으로 비활성화됩니다.
압축된 컨텐츠의 자동 배포 비활성화
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-zipped,value=false)
이는 기본적으로 활성화되어 있는 압축된 콘텐츠의 자동 배포를 비활성화합니다.
XML 컨텐츠 자동 배포 비활성화
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-xml,value=false)
이렇게 하면 기본적으로 활성화되어 있는 XML 콘텐츠의 자동 배포를 비활성화합니다.
7.3.3. 사용자 정의 배포 스캐너 정의
새 배포 스캐너는 관리 CLI를 사용하거나 관리 콘솔의 Configuration (구성) 탭에서 Deployment scanners 하위 시스템으로 이동할 수 있습니다. 그러면 배포를 스캔할 새 디렉터리가 정의됩니다. 기본 배포 스캐너는 EAP_HOME/standalone/deployments를
모니터링합니다. 기존 배포 스캐너 구성에 대한 자세한 내용은 배포 스캐너 구성을 참조하십시오.
다음 관리 CLI 명령은 배포를 위해 5초마다 EAP_HOME/standalone/new_deployment_dir
을 확인하는 새 배포 스캐너를 추가합니다.
/subsystem=deployment-scanner/scanner=new-scanner:add(path=new_deployment_dir,relative-to=jboss.server.base.dir,scan-interval=5000)
지정된 디렉토리가 이미 존재해야 합니다. 그렇지 않으면 오류와 함께 이 명령이 실패합니다.
새 배포 스캐너가 정의되어 있고 지정된 디렉터리가 배포를 위해 모니터링됩니다.
7.4. Maven을 사용하여 애플리케이션 배포
Apache Maven을 사용하여 애플리케이션을 배포하면 JBoss EAP에 배포를 기존 개발 워크플로에 쉽게 통합할 수 있습니다.
애플리케이션 서버에 애플리케이션을 배포하고 배포 취소하는 간단한 작업을 제공하는 WildFly Maven 플러그인을 사용하여 Maven을 사용하여 애플리케이션을 JBoss EAP에 배포할 수 있습니다.
7.4.1. Maven을 사용하여 독립 실행형 서버에 애플리케이션 배포
다음 지침은 Maven을 사용하여 독립 실행형 서버에 JBoss EAP helloworld
빠른 시작을 배포하고 배포 취소하는 방법을 보여줍니다.
JBoss EAP 빠른 시작에 대한 자세한 내용은 JBoss EAP Getting Started Guide 에서 빠른 시작 예제 사용을 참조하십시오.
애플리케이션 배포
Maven pom.xml
파일에서 WildFly Maven 플러그인을 초기화합니다. 이 작업은 JBoss EAP 빠른 시작 pom.xml
파일에서 이미 구성되어 있어야 합니다.
<plugin> <groupId>org.wildfly.plugins</groupId> <artifactId>wildfly-maven-plugin</artifactId> <version>${version.wildfly.maven.plugin}</version> </plugin>
helloworld
빠른 시작 디렉터리에서 다음 Maven 명령을 실행합니다.
$ mvn clean install wildfly:deploy
배포할 Maven 명령을 발행하면 터미널 창에 배포가 성공했음을 나타내는 다음 출력이 표시됩니다.
[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.981 s [INFO] Finished at: 2015-12-23T15:06:13-05:00 [INFO] Final Memory: 21M/231M [INFO] ------------------------------------------------------------------------
활성 서버 인스턴스의 서버 로그를 보고 배포를 확인할 수도 있습니다.
WFLYSRV0027: Starting deployment of "helloworld.war" (runtime-name: "helloworld.war") WFLYUT0021: Registered web context: /helloworld WFLYSRV0010: Deployed "helloworld.war" (runtime-name : "helloworld.war")
애플리케이션 배포 취소
helloworld
빠른 시작 디렉터리에서 다음 Maven 명령을 실행합니다.
$ mvn wildfly:undeploy
Maven 명령을 실행하여 배포를 취소하면 터미널 창에 배포 취소가 성공했음을 나타내는 다음 출력이 표시됩니다.
[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.237 s [INFO] Finished at: 2015-12-23T15:09:10-05:00 [INFO] Final Memory: 10M/183M [INFO] ------------------------------------------------------------------------
또한 배포 취소는 활성 서버 인스턴스의 서버 로그를 확인하여 확인할 수 있습니다.
WFLYUT0022: Unregistered web context: /helloworld WFLYSRV0028: Stopped deployment helloworld.war (runtime-name: helloworld.war) in 27ms WFLYSRV0009: Undeployed "helloworld.war" (runtime-name: "helloworld.war")
7.4.2. Maven을 사용하여 관리형 도메인에 애플리케이션 배포
다음 지침은 Maven을 사용하여 관리형 도메인에서 JBoss EAP helloworld
빠른 시작을 배포하고 배포 취소하는 방법을 보여줍니다.
JBoss EAP 빠른 시작에 대한 자세한 내용은 JBoss EAP Getting Started Guide 에서 빠른 시작 예제 사용을 참조하십시오.
애플리케이션 배포
관리형 도메인에 애플리케이션을 배포하는 경우 애플리케이션을 배포해야 하는 서버 그룹을 지정해야 합니다. 이는 Maven pom.xml
파일에서 구성됩니다.
pom.xml
의 다음 구성은 WildFly Maven 플러그인을 초기화하고 main-server-group
을 애플리케이션을 배포해야 하는 서버 그룹으로 지정합니다.
<plugin> <groupId>org.wildfly.plugins</groupId> <artifactId>wildfly-maven-plugin</artifactId> <version>${version.wildfly.maven.plugin}</version> <configuration> <domain> <server-groups> <server-group>main-server-group</server-group> </server-groups> </domain> </configuration> </plugin>
helloworld
빠른 시작 디렉터리에서 다음 Maven 명령을 실행합니다.
$ mvn clean install wildfly:deploy
배포할 Maven 명령을 발행하면 터미널 창에 배포가 성공했음을 나타내는 다음 출력이 표시됩니다.
[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 4.005 s [INFO] Finished at: 2016-09-02T14:36:17-04:00 [INFO] Final Memory: 21M/226M [INFO] ------------------------------------------------------------------------
활성 서버 인스턴스의 서버 로그를 보고 배포를 확인할 수도 있습니다.
WFLYSRV0027: Starting deployment of "helloworld.war" (runtime-name: "helloworld.war") WFLYUT0021: Registered web context: /helloworld WFLYSRV0010: Deployed "helloworld.war" (runtime-name : "helloworld.war")
애플리케이션 배포 취소
helloworld
빠른 시작 디렉터리에서 다음 Maven 명령을 실행합니다.
$ mvn wildfly:undeploy
Maven 명령을 실행하여 배포를 취소하면 터미널 창에 배포 취소가 성공했음을 나타내는 다음 출력이 표시됩니다.
[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.750 s [INFO] Finished at: 2016-09-02T14:45:10-04:00 [INFO] Final Memory: 10M/184M [INFO] ------------------------------------------------------------------------
또한 배포 취소는 활성 서버 인스턴스의 서버 로그를 확인하여 확인할 수 있습니다.
WFLYUT0022: Unregistered web context: /helloworld WFLYSRV0028: Stopped deployment helloworld.war (runtime-name: helloworld.war) in 106ms WFLYSRV0009: Undeployed "helloworld.war" (runtime-name: "helloworld.war")
7.5. HTTP API를 사용하여 애플리케이션 배포
애플리케이션을 curl
명령과 함께 HTTP API를 사용하여 JBoss EAP에 배포할 수 있습니다. HTTP API 사용에 대한 자세한 내용은 HTTP API 섹션을 참조하십시오.
7.5.1. HTTP API를 사용하여 독립 실행형 서버에 애플리케이션 배포
기본적으로 HTTP API는 http://HOST:PORT/management
(예: http://localhost:9990/management)
에서 액세스할 수 있습니다.
애플리케이션 배포
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "add", "address" : {"deployment" : "test-application.war"}, "content" : [{"url" : "file:/path/to/test-application.war"}]},{"operation" : "deploy", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'
애플리케이션 배포 취소
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "undeploy", "address" : {"deployment" : "test-application.war"}},{"operation" : "remove", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'
JSON 요청을 프로그래밍 방식으로 생성하는 방법에 대해 자세히 알아보려면 이 Red Hat 지식베이스 문서를 참조하십시오.
7.5.2. HTTP API를 사용하여 관리형 도메인에 애플리케이션 배포
기본적으로 HTTP API는 http://HOST:PORT/management
(예: http://localhost:9990/management)
에서 액세스할 수 있습니다.
애플리케이션 배포
콘텐츠 리포지토리에 배포를 추가합니다.
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "add", "address" : {"deployment" : "test-application.war"}, "content" : [{"url" : "file:/path/to/test-application.war"}],"json.pretty":1}'
원하는 서버 그룹에 배포를 추가합니다.
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "add", "address" : {"server-group" : "main-server-group","deployment":"test-application.war"},"json.pretty":1}'
서버 그룹에 애플리케이션을 배포합니다.
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "deploy", "address" : {"server-group" : "main-server-group","deployment":"test-application.war"},"json.pretty":1}'
애플리케이션 배포 취소
할당된 모든 서버 그룹에서 배포를 제거합니다.
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "remove", "address" : {"server-group" : "main-server-group","deployment":"test-application.war"},"json.pretty":1}'
콘텐츠 리포지토리에서 배포를 제거합니다.
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "remove", "address" : {"deployment" : "test-application.war"}, "json.pretty":1}'
7.6. 배포 동작 사용자 정의
7.6.1. 배포 콘텐츠에 대한 사용자 정의 디렉터리 정의
배포된 콘텐츠를 저장할 JBoss EAP의 사용자 지정 위치를 정의할 수 있습니다.
독립 실행형 서버에 대한 사용자 정의 디렉터리 정의
기본적으로 독립 실행형 서버에 배포된 콘텐츠는 EAP_HOME/standalone/data/content
디렉터리에 저장됩니다. 이 위치는 서버를 시작할 때 -Djboss.server.deploy.dir
인수를 전달하여 변경할 수 있습니다.
$ EAP_HOME/bin/standalone.sh -Djboss.server.deploy.dir=/path/to/new_deployed_content
선택한 위치는 JBoss EAP 인스턴스에서 고유해야 합니다.
jboss.server.deploy.dir
속성은 관리 콘솔 또는 관리 CLI를 사용하여 배포된 콘텐츠를 저장하는 데 사용할 디렉터리를 지정합니다. 배포 스캐너에서 모니터링할 사용자 정의 배포 디렉터리를 정의하려면 배포 스캐너 구성을 참조하십시오.
관리형 도메인의 사용자 지정 디렉터리 정의
기본적으로 관리형 도메인에 배포된 콘텐츠는 EAP_HOME/domain/data/content
디렉터리에 저장됩니다. 이 위치는 도메인을 시작할 때 -Djboss.domain.deployment.dir
인수를 전달하여 변경할 수 있습니다.
$ EAP_HOME/bin/domain.sh -Djboss.domain.deployment.dir=/path/to/new_deployed_content
선택한 위치는 JBoss EAP 인스턴스에서 고유해야 합니다.
7.6.2. 배포 순서 제어
JBoss EAP는 서버를 시작할 때 배포 순서를 세부적으로 제어할 수 있습니다. 여러 EAR 파일에 있는 애플리케이션의 엄격한 배포 순서는 재시작 후 순서의 지속성과 함께 지정할 수 있습니다.
jboss-all.xml
배포 설명자를 사용하여 최상위 배포 간의 종속성을 선언할 수 있습니다.
예를 들어, framework
가 있는 경우 아래와 같이 .ear에 따라 먼저 배포되는 app
.earapp.ear/META-INF/jboss-all.xml
파일을 생성할 수 있습니다.
<jboss xmlns="urn:jboss:1.0"> <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0"> <dependency name="framework.ear" /> </jboss-deployment-dependencies> </jboss>
jboss-all.xml
파일에서 배포의 런타임 이름을 종속성 이름으로 사용할 수 있습니다.
이렇게 하면 app
를 배포할 수 있습니다.
.ear 전에 framework
.ear
app.ear
에 jboss-all.xml
파일을 생성하고 framework.ear를
배포하지 않으면 서버에서 app.ear
배포를 시도하고 실패합니다.
7.6.3. 배포 내용 덮어쓰기
배포 오버레이 를 사용하면 배포 아카이브의 내용을 물리적으로 수정하지 않고도 기존 배포로 컨텐츠를 오버레이할 수 있습니다. 이를 통해 아카이브를 다시 빌드하지 않고도 배포 설명자, 라이브러리 JAR 파일, 클래스, 자카르타 서버 페이지 및 기타 파일을 재정의할 수 있습니다.
이 기능은 다양한 구성 또는 설정이 필요한 다양한 환경에 맞게 배포를 조정해야 하는 경우에 유용합니다. 예를 들어 개발, 테스트에서 스테이징으로 애플리케이션 라이프사이클을 통해 배포를 이동할 때 배포 설명자를 스왑하거나 정적 웹 리소스를 수정하여 애플리케이션의 브랜딩을 변경하거나, JAR 라이브러리를 대상 환경에 따라 다른 버전으로 교체할 수 있습니다. 또한 구성을 변경해야 하지만 정책 또는 보안 제한으로 인해 아카이브를 수정하거나 손상시킬 수 없는 설치에 유용한 기능이기도 합니다.
배포 오버레이를 정의할 때 배포 아카이브의 파일을 대체할 파일 시스템에 파일을 지정합니다. 배포 오버레이의 영향을 받아야 하는 배포도 지정해야 합니다. 변경 사항을 적용하려면 영향을 받는 배포를 다시 배포해야 합니다.
매개 변수
다음 매개변수 중 하나를 사용하여 배포 오버레이를 구성할 수 있습니다.
-
name
:: 배포 오버레이의 이름입니다. -
content
:: 파일 시스템의 파일을 대체하는 아카이브의 파일에 매핑하는 쉼표로 구분된 목록입니다. 각 항목의 형식은ARCHIVE_PATH=FILESYSTEM_PATH
입니다. -
배포
:: 이 오버레이가 연결되는 쉼표로 구분된 배포 목록입니다. -
redeploy-affected
:: 영향을 받는 모든 배포를 다시 배포합니다.
전체 사용 세부 정보는 deployment-overlay --help
를 실행합니다.
절차
deployment-overlay add management
CLI 명령을 사용하여 배포 오버레이를 추가합니다.deployment-overlay add --name=new-deployment-overlay --content=WEB-INF/web.xml=/path/to/other/web.xml --deployments=test-application.war --redeploy-affected
참고관리형 도메인에서 --server-
groups를 사용하여 적용 가능한 서버 그룹을 지정하거나
로 모든 서버 그룹을 지정합니다.--all-server
-groups- 배포 오버레이를 생성한 후 콘텐츠를 기존 오버레이에 추가하거나 오버레이를 배포에 연결하거나 오버레이를 제거할 수 있습니다.
선택 사항: <
overlay
> 요소를 사용하여 HTML, 이미지 또는 동영상과 같은 정적 웹 리소스가 포함된 외부 디렉터리에 연결할 오버레이 구성을 지정할 수 있습니다.&
lt;overlay
> 요소는 JAR 오버레이 절차와 유사하게 웹 애플리케이션의 정적 파일을 오버레이하는 정적 파일을 지정합니다. 이 요소는 애플리케이션 파일jboss-web.xml
에 있습니다. 이 요소 구성을 사용하면 애플리케이션을 다시 패키징할 필요가 없습니다.다음 예제에서는 <
overlay
> 요소의 시스템 속성 대체를 보여줍니다. 여기서{example.path.to.overlay}
는/PATH/TO/STATIC/WEB/CONTENT
위치를 정의합니다.예:
jboss-web.xml
파일의<overlay>
요소<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd" version="10.0"> <overlay>{example.path.to.overlay}</overlay> </jboss-web>
jboss-descriptor-property-replacement
가true
로 설정된 경우 설명자 속성의 기본값인<overlay>
요소에 시스템 속성을 지정할 수 있습니다.jboss-descriptor-property-replacement
를 구성하려면 다음 관리 CLI 명령을 사용합니다./subsystem=ee:write-attribute(name=jboss-descriptor-property-replacement,value=true)
이 명령은 JBoss EAP 구성의 하위
시스템에
다음 XML 내용을 추가합니다.<subsystem xmlns="urn:jboss:domain:ee:4.0"> <jboss-descriptor-property-replacement>true</jboss-descriptor-property-replacement> </subsystem>
참고&
lt;overlay
> 요소는 EAP 프로젝트에 이미 존재하는 배포 파일을 재정의하지 않습니다. 여러<overlay
> 요소에 동일한 파일이 포함된 경우 우선순위 순서는 애플리케이션jboss-web.xml
파일에서 오버레이 요소의 순서에 따라 결정됩니다.
7.6.4. 롤아웃 계획 사용
롤아웃 계획 정보
관리형 도메인에서 도메인 또는 호스트 수준 리소스를 대상으로 하는 작업은 여러 서버에 잠재적으로 영향을 줄 수 있습니다. 이러한 작업에는 작업이 서버에 적용되는 시퀀스를 자세히 설명하는 롤아웃 계획과 일부 서버에서 성공적으로 실행되지 못하면 작업을 되돌릴 수 있는지 자세히 설명하는 정책이 포함될 수 있습니다. 롤아웃 계획을 지정하지 않으면 기본 롤아웃 계획이 사용됩니다.
다음은 5개의 서버 그룹을 포함하는 롤아웃 계획의 예입니다. 작업은 서버 그룹에 직렬로, 시리즈 내부
또는 동시 동시 그룹에 적용할 수 있습니다
. 구문은 롤아웃 계획 구문에 자세히 설명되어 있습니다.
{"my-rollout-plan" => {"rollout-plan" => { "in-series" => [ {"concurrent-groups" => { "group-A" => { "max-failure-percentage" => "20", "rolling-to-servers" => "true" }, "group-B" => undefined }}, {"server-group" => {"group-C" => { "rolling-to-servers" => "false", "max-failed-servers" => "1" }}}, {"concurrent-groups" => { "group-D" => { "max-failure-percentage" => "20", "rolling-to-servers" => "true" }, "group-E" => undefined }} ], "rollback-across-groups" => "true" }}}
위의 예제를 보면 도메인의 서버에 작업을 적용하는 작업은 3단계로 수행됩니다. 모든 서버 그룹의 정책에서 서버 그룹 전체에서 작업 롤백을 트리거하면 기타 모든 서버 그룹도 롤백됩니다.
- 서버 그룹 group-A 와 group-B 는 동시에 작업을 적용합니다. 이 작업은 일련의 그룹 A의 서버에 적용되는 반면 group- B 의 모든 서버는 동시에 작업을 처리합니다. A 그룹의 서버 20% 이상이 작업을 적용하지 못하면 해당 그룹으로 롤백됩니다. group-B 에 있는 서버가 작업을 적용하지 못하면 해당 그룹을 통해 롤백됩니다.
- group-A 및 group-B 의 모든 서버가 완료되면 group-C 의 서버에 작업이 적용됩니다. 이러한 서버는 동시에 작업을 처리합니다. group-C 에서 둘 이상의 서버가 작업을 적용하지 못하면 해당 그룹을 통해 롤백됩니다.
- group-C 의 모든 서버가 완료되면 서버 그룹 group-D 와 group-E 는 동시에 작업을 적용합니다. 이 작업은 일련의 그룹 D에 있는 서버에 적용되는 반면 group-E 의 모든 서버는 동시에 작업을 처리합니다. group-D 에서 20% 이상의 서버가 작업을 적용하지 못하면 해당 그룹으로 롤백됩니다. group-E 에 있는 서버가 있는 서버가 작업을 적용하지 못하면 해당 그룹을 통해 롤백됩니다.
롤아웃 계획 구문
다음 방법 중 하나로 롤아웃 계획을 지정할 수 있습니다.
-
배포
명령 작업 헤더에 롤아웃 계획을 정의합니다. 자세한 내용은 롤아웃 계획을 사용하여 배포를 참조하십시오. -
rollout-plan
명령을 사용하여 롤아웃 계획을 저장한 다음배포
명령 작업 헤더에서 계획 이름을 참조합니다. 자세한 내용은 저장된 롤아웃 계획을 사용하여 배포를 참조하십시오.
각 방법에 다른 초기 명령이 있지만 두 방법 모두 롤아웃
작업 헤더를 사용하여 롤아웃 계획을 정의합니다. 다음 구문을 사용합니다.
rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]
-
PLAN_NAME
은 rollout-plan 명령을 사용하여 저장된 롤아웃
계획의 이름입니다. SERVER_GROUP_LIST
는 서버 그룹 목록입니다. 여러 서버 그룹을 분리하려면 쉼표(,
)를 사용하여 각 서버 그룹에서 순차적으로 작업을 수행해야 함을 나타냅니다. 캐럿(^)구분자
를 사용하여 각 서버 그룹에서 동시에 작업을 수행해야 함을 나타냅니다.각 서버 그룹에 대해 괄호로 다음 정책을 설정합니다. 여러 정책을 분리하려면 쉼표를 사용합니다.
-
rolling-to-servers
:true
로 설정된 부울은 일련의 그룹의 각 서버에 작업을 적용합니다. 값을false로
지정하거나 지정하지 않은 경우 그룹의 서버에 동시에 작업이 적용됩니다. -
max-failed-servers
: 작업을 적용하지 못할 수 있는 그룹의 최대 서버 수를 사용하는 정수는 그룹의 모든 서버에서 되돌리기 전에 작업을 적용하지 못할 수 있습니다. 지정하지 않은 경우 기본값은0
입니다. 즉, 서버상의 오류가 그룹 전체에서 롤백을 트리거합니다. max-failure-percentage
: 그룹의 모든 서버에서 작업을 되돌리기 전에 작업을 적용하지 못할 수 있는 그룹의 총 서버 수 최대 백분율을 나타내는0
에서100
사이의 정수입니다. 지정하지 않은 경우 기본값은0
입니다. 즉, 서버상의 오류가 그룹 전체에서 롤백을 트리거합니다.참고max-failed-servers 및 max
-failure-percentage
가 모두 0이 아닌 값으로 설정된 경우max-failure-percentage
가 우선합니다.
-
-
rollback-across-groups
: 한 서버 그룹에 있는 모든 서버에서 작업을 롤백해야 하는지를 나타내는 부울이 모든 서버 그룹에서 롤백을 트리거하는지 여부를 나타냅니다. 기본값은false
입니다.
롤아웃 계획을 사용하여 배포
롤아웃 설정을
헤더
인수에 전달하여 롤아웃 계획의 전체 세부 사항을 배포
명령에 직접 제공할 수 있습니다. 형식에 대한 자세한 내용은 롤아웃 계획 구문 을 참조하십시오.
다음 관리 CLI 명령은 직렬 배포에 대해 rolling-to
서버 그룹에 애플리케이션을 배포합니다.
-servers=true를 지정하는 배포 계획을 사용하여 main-server-
group
deploy /path/to/test-application.war --server-groups=main-server-group --headers={rollout main-server-group(rolling-to-servers=true)}
저장된 롤아웃 계획을 사용하여 배포
롤아웃 계획은 복잡할 수 있으므로 롤아웃 계획의 세부 사항을 저장할 수 있는 옵션이 있습니다. 이를 통해 매번 롤아웃 계획의 전체 세부 정보를 필요로 하는 대신 롤아웃 계획 이름을 참조할 수 있습니다.
롤아웃-계획
관리 CLI 명령을 사용하여 롤아웃 계획을 저장합니다. 형식에 대한 자세한 내용은 롤아웃 계획 구문 을 참조하십시오.rollout-plan add --name=my-rollout-plan --content={rollout main-server-group(rolling-to-servers=false,max-failed-servers=1),other-server-group(rolling-to-servers=true,max-failure-percentage=20) rollback-across-groups=true}
이렇게 하면 다음과 같은 배포 계획이 생성됩니다.
"rollout-plan" => { "in-series" => [ {"server-group" => {"main-server-group" => { "rolling-to-servers" => false, "max-failed-servers" => 1 }}}, {"server-group" => {"other-server-group" => { "rolling-to-servers" => true, "max-failure-percentage" => 20 }}} ], "rollback-across-groups" => true }
애플리케이션을 배포할 때 저장된 롤아웃 계획 이름을 지정합니다.
다음 관리 CLI 명령은
my-rollout-plan
저장된 롤아웃 계획을 사용하여 모든 서버 그룹에 애플리케이션을 배포합니다.deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan}
저장된 롤아웃 계획 제거
제거할 롤아웃 계획의 이름을 지정하여 rollout-plan
관리 CLI 명령을 사용하여 저장된 롤아웃 계획을 제거할 수 있습니다.
rollout-plan remove --name=my-rollout-plan
기본 롤아웃 계획
여러 서버에 영향을 미치는 모든 작업은 롤아웃 계획을 사용하여 실행됩니다. 작업 요청에 롤아웃 계획이 지정되지 않은 경우 기본 롤아웃 계획이 생성됩니다. 이 계획은 다음과 같은 특성을 갖습니다.
- 고급 단계는 단 한 단계뿐입니다. 이 작업의 영향을 받는 모든 서버 그룹에는 작업이 동시에 적용됩니다.
- 각 서버 그룹 내에서 작업은 모든 서버에 동시에 적용됩니다.
- 서버 그룹의 서버에 오류가 발생하면 그룹 전체에서 롤백이 발생합니다.
- 서버 그룹이 실패하면 다른 모든 서버 그룹이 롤백됩니다.
7.7. 압축을 푼 배포 관리
JBoss EAP 7.1 이전에는 파일 시스템에서 파일을 조작하여 압축 해제된 배포만 관리할 수 있었습니다. JBoss EAP 7.1부터는 관리 인터페이스를 사용하여 압축 해제된 배포를 관리할 수 있습니다. 이를 통해 새 버전의 애플리케이션을 배포하지 않고도 압축 해제된 애플리케이션의 내용을 변경할 수 있습니다.
JavaScript 및 CSS 파일과 같은 배포의 정적 파일에 대한 업데이트가 즉시 적용됩니다. Java 클래스와 같은 다른 파일에 대한 변경 사항을 적용하려면 애플리케이션 재배포가 필요할 수 있습니다.
빈 배포로 시작하거나 기존 아카이브 배포를 압축 해제한 다음 콘텐츠를 추가하거나 제거할 수 있습니다.
배포 콘텐츠 보기를 참조하여 배포에서 파일을 검색하거나 파일의 내용을 읽습니다.
비어 있는 배포 만들기
나중에 필요에 따라 콘텐츠를 추가할 수 있는 빈 압축 해제 배포를 생성할 수 있습니다. 압축을 푼 빈 배포를 생성하려면 다음 관리 CLI 명령을 사용합니다.
/deployment=DEPLOYMENT_NAME.war:add(content=[{empty=true}])
빈 배포를 생성하려는지 확인하려면 empty=true
옵션이 필요합니다.
기존 아카이브 배포 압축 해제
기존 아카이브 배포의 압축을 풀어 해당 콘텐츠를 업데이트할 수 있습니다. 배포를 비활성화해야 압축을 풉니다. 다음 관리 CLI 명령을 사용하여 배포를 펼칩니다.
/deployment=ARCHIVE_DEPLOYMENT_NAME.ear:explode
이제 이 배포에서 콘텐츠를 추가하거나 제거할 수 있습니다.
관리 콘솔에서 기존 아카이브 배포를 압축 해제할 수도 있습니다. Deployments(배포 ) 탭에서 배포를 선택하고 Explode (탐색) 드롭다운 옵션을 선택합니다.
압축을 푼 배포에 콘텐츠 추가
배포에 콘텐츠를 추가하려면 add-content
관리 CLI 작업을 사용합니다. 콘텐츠를 추가해야 하는 배포의 위치 경로를 제공하고 업로드할 콘텐츠를 제공합니다. 업로드할 콘텐츠는 JBoss EAP 콘텐츠 리포지토리에 이미 있는 콘텐츠의 로컬 파일 스트림, URL, 해시 또는 콘텐츠의 바이트 배열로 제공될 수 있습니다. 다음 관리 CLI 명령은 input-stream-index
옵션을 사용하여 로컬 파일의 콘텐츠를 배포에 업로드합니다.
/deployment=DEPLOYMENT_NAME.war:add-content(content=[{target-path=/path/to/FILE_IN_DEPLOYMENT, input-stream-index=/path/to/LOCAL_FILE_TO_UPLOAD}]
add-content
작업을 사용하여 배포에 콘텐츠를 추가하면 기본적으로 배포의 콘텐츠를 덮어씁니다. overwrite 옵션을
false
로 설정하여 이 동작을 변경할 수 있습니다.
압축을 푼 배포에서 콘텐츠 제거
배포에서 콘텐츠를 제거하려면 remove-content
관리 CLI 작업을 사용하고 제거할 배포의 콘텐츠 경로를 제공합니다.
/deployment=DEPLOYMENT_NAME.war:remove-content(paths=[/path/to/FILE_1, /path/to/FILE_2])
7.8. 배포 콘텐츠 보기
관리 배포에서 파일 정보를 검색하고 JBoss EAP 관리 인터페이스를 사용하여 파일의 내용을 읽을 수 있습니다.
7.8.1. 배포에서 파일 검색
browse-content
작업을 사용하여 관리되는 배포의 파일과 디렉터리를 확인합니다. 전체 배포 구조를 반환하거나 경로
인수를 사용하여 특정 디렉토리의 경로를 제공하는 인수를 제공하지 않습니다.
Deployments (배포) 탭으로 이동하고 배포를 선택하고 드롭다운에서 View (보기)를 선택하여 관리 콘솔에서 배포 콘텐츠를 찾아볼 수도 있습니다.
/deployment=helloworld.war:browse-content(path=META-INF/)
그러면 helloworld.war
배포의 META-INF/
디렉터리에 파일 및 디렉터리가 표시됩니다.
{ "outcome" => "success", "result" => [ { "path" => "MANIFEST.MF", "directory" => false, "file-size" => 827L }, { "path" => "maven/org.jboss.eap.quickstarts/helloworld/pom.properties", "directory" => false, "file-size" => 106L }, { "path" => "maven/org.jboss.eap.quickstarts/helloworld/pom.xml", "directory" => false, "file-size" => 2713L }, { "path" => "maven/org.jboss.eap.quickstarts/helloworld/", "directory" => true }, { "path" => "maven/org.jboss.eap.quickstarts/", "directory" => true }, { "path" => "maven/", "directory" => true }, { "path" => "INDEX.LIST", "directory" => false, "file-size" => 251L } ] }
다음 인수를 browse-content
작업에 지정할 수도 있습니다.
- 아카이브
- 아카이브 파일만 반환할지 여부.
- 깊이
- 반환할 파일의 깊이를 지정합니다.
7.8.2. 배포 내용 읽기
read -content 작업을 사용하여 관리 배포에서 파일의 내용을 읽을 수
있습니다. 전체 배포를 반환하거나 경로
인수를 사용하여 특정 파일의 경로를 제공하는 인수를 제공하지 않습니다. 예를 들면 다음과 같습니다.
/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF)
그러면 관리 CLI에 표시되거나 파일 시스템에 저장할 수 있는 파일 스트림이 반환됩니다.
{ "outcome" => "success", "result" => {"uuid" => "24ba8e06-21bd-4505-b4d4-bdfb16451b95"}, "response-headers" => {"attached-streams" => [{ "uuid" => "24ba8e06-21bd-4505-b4d4-bdfb16451b95", "mime-type" => "text/plain" }]} }
7.8.2.1. 파일의 내용 표시
첨부 파일 display
명령을 사용하여 MANIFEST.MF
파일의 내용을 읽습니다.
attachment display --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF)
그러면 helloworld
파일의 콘텐츠가 표시됩니다.
.war 배포에서 관리 CLI에 있는 MANIFEST.
MF
ATTACHMENT 8af87836-2abd-423a-8e44-e731cc57bd80: Manifest-Version: 1.0 Implementation-Title: Quickstart: helloworld Implementation-Version: 7.4.0.GA Java-Version: 1.8.0_131 Built-By: username Scm-Connection: scm:git:git@github.com:jboss/jboss-parent-pom.git/quic kstart-parent/helloworld Specification-Vendor: JBoss by Red Hat ...
7.8.2.2. 파일의 내용을 저장합니다
첨부 파일 save
명령을 사용하여 MANIFEST.MF
파일의 내용을 파일 시스템에 저장합니다.
attachment save --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF) --file=/path/to/MANIFEST.MF
그러면 helloworld
파일을 .war 배포에서 MANIFEST.
MF경로/to/MANIFEST.MF
의 파일 시스템에 저장합니다. file 인수를
사용하여 파일 경로를 지정하지 않으면 고유한 연결 ID를 사용하여 파일의 이름을 지정하고 관리 CLI의 작업 디렉터리에 저장됩니다. 기본적으로 EAP_HOME/bin/
입니다.
8장. 도메인 관리
이 섹션에서는 관리형 도메인 운영 모드와 관련된 개념과 구성에 대해 설명합니다.
관리형 도메인 보안에 대한 자세한 내용은 JBoss EAP의 관리형 도메인 보안 설정 방법을 참조하십시오.
8.1. 관리형 도메인 정보
관리형 도메인 운영 모드를 사용하면 단일 제어 지점에서 여러 JBoss EAP 인스턴스를 관리할 수 있습니다.
중앙 집중식으로 관리되는 JBoss EAP 서버 컬렉션은 도메인의 구성원이라고 합니다. 도메인의 모든 JBoss EAP 인스턴스는 공통 관리 정책을 공유합니다.
도메인은 하나 이상의 도메인 컨트롤러, 하나 이상의 호스트 컨트롤러, 호스트당 0개 이상의 서버 그룹으로 구성됩니다.
도메인 컨트롤러는 도메인이 제어되는 핵심 지점입니다. 이 스크립트는 각 서버가 도메인의 관리 정책에 따라 구성되도록 합니다. 도메인 컨트롤러는 호스트 컨트롤러이기도 합니다.
호스트 컨트롤러는 도메인 컨트롤러와 상호 작용하여 호스트에서 실행되는 애플리케이션 서버 인스턴스의 라이프사이클을 제어하고 도메인 컨트롤러에서 관리하는 데 도움이 되는 실제 또는 가상 호스트입니다. 각 호스트에는 여러 서버 그룹이 포함될 수 있습니다.
서버 그룹은 JBoss EAP가 설치되어 있고 하나로 관리 및 구성되는 서버 인스턴스 집합입니다. 도메인 컨트롤러는 서버 그룹에 배포된 애플리케이션의 구성을 관리합니다. 결과적으로 서버 그룹의 각 서버는 동일한 구성 및 배포를 공유합니다.
호스트 컨트롤러는 특정 물리 또는 가상 호스트와 연결됩니다. 다른 구성을 사용하는 경우 동일한 하드웨어에서 여러 호스트 컨트롤러를 실행하여 포트 및 기타 리소스가 충돌하지 않도록 할 수 있습니다. 도메인 컨트롤러, 단일 호스트 컨트롤러 및 여러 서버가 동일한 물리적 시스템에서 동일한 JBoss EAP 인스턴스 내에서 실행될 수 있습니다.
8.1.1. 도메인 컨트롤러 정보
도메인 컨트롤러는 도메인의 중앙 관리 지점 역할을 하는 JBoss EAP 서버 인스턴스입니다. 하나의 호스트 컨트롤러 인스턴스가 도메인 컨트롤러 역할을 하도록 구성됩니다.
도메인 컨트롤러의 주요 책임은 다음과 같습니다.
- 도메인의 중앙 관리 정책 유지 관리.
- 모든 호스트 컨트롤러가 현재 콘텐츠를 인식하는지 확인합니다.
- 호스트 컨트롤러는 이 정책에 따라 실행 중인 모든 JBoss EAP 서버 인스턴스가 구성되어 있는지 확인합니다.
기본적으로 중앙 관리 정책은 EAP_HOME/domain/configuration/domain.xml
파일에 저장됩니다. 이 파일은 도메인 컨트롤러로 실행하도록 설정된 호스트 컨트롤러의 이 디렉터리에 필요합니다.
domain.xml
파일에는 도메인의 서버에서 사용할 수 있는 프로필 구성이 포함되어 있습니다. 프로필에 는 해당 프로필에서 사용할 수 있는 다양한 하위 시스템의 세부 설정이 포함되어 있습니다. 도메인 구성에는 소켓 그룹 정의와 서버 그룹 정의도 포함됩니다.
호스트와 서버가 JBoss EAP 6.2 이상을 실행하는 경우 JBoss EAP 7 도메인 컨트롤러는 JBoss EAP 6 호스트 및 서버를 관리할 수 있습니다. 자세한 내용은 Configure a JBoss EAP 7.x Domain Controller to Administer JBoss EAP 6 Instances 를 참조하십시오.
자세한 내용은 관리형 도메인 및 도메인 컨트롤러 구성 섹션을 참조하십시오.
8.1.2. 호스트 컨트롤러 정보
호스트 컨트롤러의 주요 책임은 서버 관리입니다. 도메인 관리 작업을 위임하고 해당 호스트에서 실행되는 개별 애플리케이션 서버 프로세스를 시작하고 중지합니다.
도메인 컨트롤러와 상호 작용하여 서버와 도메인 컨트롤러 간의 통신을 관리합니다. 도메인의 여러 호스트 컨트롤러는 단일 도메인 컨트롤러와만 상호 작용할 수 있습니다. 따라서 단일 도메인 모드에서 실행되는 모든 호스트 컨트롤러와 서버 인스턴스에는 단일 도메인 컨트롤러가 있으며 동일한 도메인에 속해야 합니다.
기본적으로 각 호스트 컨트롤러는 호스트의 파일 시스템의 압축을 푼 JBoss EAP 설치 파일에 있는 EAP_HOME/domain/configuration/host.xml
파일에서 해당 구성을 읽습니다. host.xml
파일에는 특정 호스트와 관련된 다음 구성 정보가 포함되어 있습니다.
- 이 설치에서 실행되는 서버 인스턴스의 이름입니다.
-
로컬 물리적 설치와 관련된 구성입니다. 예를 들어 domain.xml에 선언된 명명된 인터페이스 정의는
host
domain.xml의 추상화 경로 이름은 host.xml의 실제 파일 시스템 경로에 매핑될 수 있습니다.xml
의 실제 시스템 특정 IP 주소에 매핑될 수 있습니다..
다음 구성 중 하나를 수행합니다.
- 호스트 컨트롤러가 도메인 컨트롤러에 연결하여 등록하고 도메인 구성에 액세스하는 방법.
- 원격 도메인 컨트롤러를 찾아서 연결하는 방법.
- 호스트 컨트롤러가 도메인 컨트롤러 역할을 하는지 여부
자세한 내용은 관리형 도메인 및 호스트 컨트롤러 구성 섹션을 참조하십시오.
8.1.3. 프로세스 컨트롤러 정보
프로세스 컨트롤러는 호스트 컨트롤러 프로세스를 생성하고 라이프사이클을 모니터링하는 작은 경량 프로세스입니다. 호스트 컨트롤러가 충돌하면 프로세스 컨트롤러가 이를 다시 시작합니다. 또한 호스트 컨트롤러가 지시한 대로 서버 프로세스를 시작하지만 충돌하는 서버 프로세스를 자동으로 다시 시작하지 않습니다.
프로세스 컨트롤러는 EAP_HOME/domain/log/process-controller.log
파일에 기록합니다. PROCESS_CONTROLLER_JAVA_OPTS
변수를 사용하여 EAP_HOME/bin/domain.conf
파일에서 프로세스 컨트롤러에 대한 JVM 옵션을 설정할 수 있습니다.
8.1.4. 서버 그룹 정보
서버 그룹은 하나로 관리 및 구성된 서버 인스턴스 컬렉션입니다. 관리형 도메인에서 모든 애플리케이션 서버 인스턴스는 유일한 멤버인 경우에도 서버 그룹에 속합니다. 그룹의 서버 인스턴스는 동일한 프로필 구성 및 배포된 콘텐츠를 공유합니다.
도메인 컨트롤러와 호스트 컨트롤러는 도메인에 있는 모든 서버 그룹의 모든 서버 인스턴스에 표준 구성을 적용합니다.
도메인은 여러 서버 그룹으로 구성될 수 있습니다. 다른 서버 그룹은 다른 프로필 및 배포로 구성할 수 있습니다. 예를 들어 도메인을 다양한 서비스를 제공하는 다양한 서버 계층으로 구성할 수 있습니다.
다른 서버 그룹에도 동일한 프로필 및 배포가 있을 수 있습니다. 예를 들어 애플리케이션이 한 서버 그룹에서 업그레이드된 다음 두 번째 서버 그룹에서 업데이트되어 완전한 서비스 중단을 방지하는 롤링 애플리케이션 업그레이드가 가능합니다.
자세한 내용은 서버 그룹 구성 섹션을 참조하십시오.
8.1.5. 서버 정보
서버는 애플리케이션 서버 인스턴스를 나타냅니다. 관리형 도메인에서 모든 서버 인스턴스는 서버 그룹의 구성원입니다. 호스트 컨트롤러는 자체 JVM 프로세스에서 각 서버 인스턴스를 시작합니다.
자세한 내용은 서버 구성 섹션을 참조하십시오.
8.2. 도메인 구성 탐색
JBoss EAP는 확장 가능한 관리 인터페이스를 제공하여 소규모 및 대규모 관리형 도메인을 모두 지원합니다.
관리 콘솔
JBoss EAP 관리 콘솔은 도메인의 그래픽 보기를 제공하며 도메인의 호스트, 서버, 배포 및 프로필을 쉽게 관리할 수 있습니다.
- 설정
Configuration(구성 ) 탭에서 도메인에서 사용되는 각 프로필에 대한 하위 시스템을 구성할 수 있습니다. 도메인의 다른 서버 그룹은 필요한 기능에 따라 다른 프로필을 사용할 수 있습니다.
원하는 프로필을 선택하면 해당 프로필에 대해 사용 가능한 모든 하위 시스템이 나열됩니다. 프로필 구성에 대한 자세한 내용은 JBoss EAP 프로필 관리를 참조하십시오.
- 런타임
Runtime(런타임 ) 탭에서 서버 및 서버 그룹과 호스트 구성을 관리할 수 있습니다. 호스트 또는 서버 그룹별로 도메인을 찾아볼 수 있습니다.
호스트에서 호스트 속성 및 JVM 설정을 구성하고 해당 호스트에 대한 서버를 추가 및 구성할 수 있습니다.
서버 그룹에서 새 서버 그룹을 추가하고 속성 및 JVM 설정을 구성하고 해당 서버 그룹에 서버를 추가 및 구성할 수 있습니다. 선택한 서버 그룹의 모든 서버 시작, 중지, 일시 중지 및 다시 로드와 같은 작업을 수행할 수 있습니다.
호스트 또는 서버 그룹에서 새 서버를 추가하고 서버 속성 및 JVM 설정을 구성할 수 있습니다. 선택한 서버 시작, 중지, 일시 중지 및 다시 로드와 같은 작업을 수행할 수 있습니다. JVM 사용, 서버 로그 및 하위 시스템 관련 정보와 같은 런타임 정보를 볼 수도 있습니다.
토폴로지 에서 개요를 보고 도메인의 호스트, 서버 그룹 및 서버에 대한 세부 정보를 볼 수 있습니다. 각각에 대해 다시 로드 또는 일시 중단과 같은 작업을 수행할 수 있습니다.
- 배포
Deployments(배포 ) 탭에서 서버 그룹에 배포를 추가하고 배포할 수 있습니다. 콘텐츠 리포지토리의 모든 배포를 보거나 특정 서버 그룹에 배포된 배포를 볼 수 있습니다.
관리 콘솔을 사용하여 애플리케이션 배포에 대한 자세한 내용은 관리형 도메인에서 애플리케이션 배포를 참조하십시오. ???
관리 CLI
JBoss EAP 관리 CLI는 도메인의 호스트, 서버, 배포 및 프로필을 관리하는 명령줄 인터페이스를 제공합니다.
적절한 프로필을 선택하면 하위 시스템 구성에 액세스할 수 있습니다.
/profile=PROFILE_NAME/subsystem=SUBSYSTEM_NAME:read-resource(recursive=true)
이 가이드의 지침과 예제에는 독립 실행형 서버로 실행할 때 적용되는 하위 시스템 구성에 대한 관리 CLI 명령이 포함될 수 있습니다. 예를 들면 다음과 같습니다.
/subsystem=datasources/data-source=ExampleDS:read-resource
관리형 도메인에서 실행되도록 이러한 관리 CLI 명령을 조정하려면 구성할 적절한 프로필을 지정해야 합니다. 예를 들면 다음과 같습니다.
/profile=default/subsystem=datasources/data-source=ExampleDS:read-resource
적절한 호스트를 지정하면 호스트 설정을 구성하고 해당 호스트의 서버에서 작업을 수행할 수 있습니다.
/host=HOST_NAME/server=SERVER_NAME:read-resource
적절한 호스트를 지정한 후 해당 호스트에 대한 서버를 구성할 수 있습니다.
/host=HOST_NAME/server-config=SERVER_NAME:write-attribute(name=ATTRIBUTE_NAME,value=VALUE)
적절한 서버 그룹을 지정하면 선택한 서버 그룹의 모든 서버에서 서버 그룹 설정을 구성하고 작업을 수행할 수 있습니다.
/server-group=SERVER_GROUP_NAME:read-resource
배포 관리 CLI 명령을 사용하고 적절한 서버 그룹을 지정하여 관리형 도메인에 애플리케이션을 배포할
수 있습니다. 자세한 내용은 관리형 도메인에서 애플리케이션 배포를 참조하십시오.
8.3. 관리형 도메인 시작
8.3.1. 관리형 도메인 시작
도메인 및 호스트 컨트롤러는 JBoss EAP와 함께 제공되는 domain.sh
또는 domain.bat
스크립트를 사용하여 시작할 수 있습니다. 사용 가능한 모든 시작 스크립트 인수와 해당 용도의 전체 목록은 --help
인수를 사용하거나 Server 런타임 인수 및 switch 섹션을 참조하십시오.
도메인 컨트롤러는 도메인의 모든 서버 그룹에 있는 슬레이브 서버보다 먼저 시작해야 합니다. 먼저 도메인 컨트롤러를 시작한 다음 도메인에서 기타 연결된 호스트 컨트롤러를 시작합니다.
도메인 컨트롤러 시작
전용 도메인 컨트롤러에 대해 미리 구성된 host-master.xml
구성 파일로 도메인 컨트롤러를 시작합니다.
$ EAP_HOME/bin/domain.sh --host-config=host-master.xml
도메인 설정에 따라 호스트 컨트롤러가 연결할 수 있도록 추가 구성을 수행해야 합니다. 도메인 설정 예도 참조하십시오.
호스트 컨트롤러 시작
슬레이브 호스트 컨트롤러에 대해 미리 구성된 host-slave.xml
구성 파일을 사용하여 호스트 컨트롤러를 시작합니다.
$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
도메인 설정에 따라 도메인 컨트롤러와 충돌하지 않고 에 추가 구성을 연결해야 합니다. 도메인 설정 예도 참조하십시오.
8.3.2. 도메인 컨트롤러 구성
도메인에서 하나의 호스트를 도메인 컨트롤러로 구성해야 합니다.
RPM 설치 방법을 사용하여 JBoss EAP를 설치할 때 동일한 시스템에서 여러 도메인 또는 호스트 컨트롤러를 구성하는 것은 지원되지 않습니다.
< domain-controller>
추가하여 호스트를 도메인 컨트롤러로 구성합니다. ; 선언에 <local/>
요소를<domain-controller>
에는 다른 콘텐츠가 포함되어서는 안 됩니다.
<domain-controller> <local/> </domain-controller>
도메인 컨트롤러 역할을 하는 호스트는 도메인의 다른 호스트에 액세스할 수 있는 관리 인터페이스를 노출해야 합니다. HTTP 인터페이스는 표준 관리 인터페이스입니다.
<management-interfaces> <http-interface security-realm="ManagementRealm" http-upgrade-enabled="true"> <socket interface="management" port="${jboss.management.http.port:9990}"/> </http-interface> </management-interfaces>
샘플 최소 도메인 컨트롤러 구성 파일인 EAP_HOME/domain/configuration/host-master.xml
에는 이러한 구성 설정이 포함됩니다.
8.3.3. 호스트 컨트롤러 구성
호스트 컨트롤러가 도메인에 등록할 수 있도록 도메인 컨트롤러에 연결하도록 호스트 컨트롤러를 구성해야 합니다.
RPM 설치 방법을 사용하여 JBoss EAP를 설치할 때 동일한 시스템에서 여러 도메인 또는 호스트 컨트롤러를 구성하는 것은 지원되지 않습니다.
구성의 <domain-controller>
요소를 사용하여 도메인 컨트롤러에 대한 연결을 구성합니다.
<domain-controller> <remote security-realm="ManagementRealm"> <discovery-options> <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/> </discovery-options> </remote> </domain-controller>
샘플 최소 호스트 컨트롤러 구성 파일인 EAP_HOME/domain/configuration/host-slave.xml
에는 도메인 컨트롤러에 연결할 구성 설정이 포함되어 있습니다. 이 구성에서는 호스트 컨트롤러를 시작할 때 jboss.domain.master.address
속성을 제공하는 것으로 가정합니다.
$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=IP_ADDRESS
도메인 컨트롤러 검색에 대한 자세한 내용은 Domain Controller Discovery and Failover 섹션을 참조하십시오.
도메인 설정에 따라 도메인 컨트롤러에서 인증할 호스트 컨트롤러에 대한 인증을 제공해야 할 수도 있습니다. secret 값을 사용하여 관리 사용자를 생성하고 해당 값으로 호스트 컨트롤러 구성을 업데이트하는 방법에 대한 자세한 내용은 Set a Managed Domain on Two Machines 를 참조하십시오.
8.3.4. 호스트의 이름 설정
관리형 도메인에서 실행 중인 모든 호스트에는 고유한 호스트 이름이 있어야 합니다. 쉽게 관리하고 여러 호스트에서 동일한 호스트 구성 파일을 사용할 수 있도록 하려면 서버에서 다음 우선 순위를 사용하여 호스트 이름을 결정합니다.
-
설정된 경우 host
.xml 구성 파일의 호스트
요소 이름 속성입니다. -
jboss.host.name
시스템 속성의 값입니다. -
jboss.qualified.host
) 문자 뒤에 오는 값 또는 최종 마침표(.
name 시스템 속성의 최종 마침표(..
) 문자가 없는 경우 전체 값입니다. -
POSIX 기반 운영 체제의
HOSTNAME
환경 변수, Microsoft Windows의
COMPUTERNAME
환경 변수 또는 최종 마침표(.
) 문자가 없는 경우 전체 값 뒤에 오는 값입니다.
호스트 컨트롤러의 이름은 관련 host
.xml 구성 파일의 맨 위의 host 요소에 구성됩니다.
예를 들면 다음과 같습니다.
<host xmlns="urn:jboss:domain:8.0" name="host1">
관리 CLI를 사용하여 호스트 이름을 업데이트하려면 다음 절차를 사용하십시오.
JBoss EAP 호스트 컨트롤러를 시작합니다.
$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
관리 CLI를 시작하여 도메인 컨트롤러에 연결합니다.
$ EAP_HOME/bin/jboss-cli.sh --connect --controller=DOMAIN_CONTROLLER_IP_ADDRESS
다음 명령을 사용하여 새 호스트 이름을 설정합니다.
/host=EXISTING_HOST_NAME:write-attribute(name=name,value=NEW_HOST_NAME)
이렇게 하면 host
-slave.xml 파일의 host name 속성을 다음과 같이 수정합니다.
<host name="NEW_HOST_NAME" xmlns="urn:jboss:domain:8.0">
변경 사항을 적용하기 위해 호스트 컨트롤러를 다시 로드합니다.
reload --host=EXISTING_HOST_NAME
호스트 컨트롤러에 구성 파일에 이름이 설정되어 있지 않은 경우 런타임 시 호스트 이름을 전달할 수도 있습니다.
$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Djboss.host.name=HOST_NAME
8.4. 서버 관리
8.4.1. 서버 그룹 설정
다음은 서버 그룹 정의의 예입니다.
<server-group name="main-server-group" profile="full"> <jvm name="default"> <heap size="64m" max-size="512m"/> </jvm> <socket-binding-group ref="full-sockets"/> <deployments> <deployment name="test-application.war" runtime-name="test-application.war"/> <deployment name="helloworld.war" runtime-name="helloworld.war" enabled="false"/> </deployments> </server-group>
서버 그룹은 관리 CLI를 사용하거나 관리 콘솔 Runtime(런타임 ) 탭에서 구성할 수 있습니다.
서버 그룹 추가
다음 관리 CLI 명령을 사용하여 서버 그룹을 추가할 수 있습니다.
/server-group=SERVER_GROUP_NAME:add(profile=PROFILE_NAME,socket-binding-group=SOCKET_BINDING_GROUP_NAME)
서버 그룹 업데이트
다음 관리 CLI 명령을 사용하여 서버 그룹 특성을 업데이트할 수 있습니다.
/server-group=SERVER_GROUP_NAME:write-attribute(name=ATTRIBUTE_NAME,value=VALUE)
서버 그룹 제거
다음 관리 CLI 명령을 사용하여 서버 그룹을 제거할 수 있습니다.
/server-group=SERVER_GROUP_NAME:remove
서버 그룹 속성
서버 그룹에는 다음 속성이 필요합니다.
-
name
: 서버 그룹 이름입니다. -
profile
: 서버 그룹 프로필 이름입니다. -
socket-binding-group
: 그룹의 서버에 사용되는 기본 소켓 바인딩 그룹입니다. 서버별로 재정의할 수 있습니다.
서버 그룹에는 다음과 같은 선택적 속성이 포함됩니다.
-
management-subsystem-endpoint
: 서버 그룹에 속하는 서버가원격
하위 시스템에서 엔드포인트를 사용하여 호스트 컨트롤러에 다시 연결되도록 하려면true
로 설정합니다. 작동하려면리모팅
하위 시스템이 있어야 합니다. -
socket-binding-default-interface
: 이 서버의 소켓 바인딩 그룹 기본 인터페이스입니다. -
socket-binding-port-offset
: 소켓 바인딩 그룹에서 제공한 포트 값에 추가할 기본 오프셋입니다. -
배포
: 그룹의 서버에 배포할 배포 콘텐츠입니다. -
jvm
: 그룹의 모든 서버에 대한 기본 JVM 설정. 호스트 컨트롤러는 이러한 설정을host.xml
에 제공된 다른 구성과 병합하여 서버의 JVM을 시작하는 데 사용되는 설정을 파생합니다. -
Deployment-overlays
: 이 서버 그룹에서 정의된 배포 오버레이와 배포 간 연결. -
system-properties
: 그룹의 서버에 설정할 시스템 속성입니다.
8.4.2. 서버 설정
기본 host.xml
구성 파일은 세 개의 서버를 정의합니다.
<servers> <server name="server-one" group="main-server-group"> </server> <server name="server-two" group="main-server-group" auto-start="true"> <socket-bindings port-offset="150"/> </server> <server name="server-three" group="other-server-group" auto-start="false"> <socket-bindings port-offset="250"/> </server> </servers>
server -one이라는 서버
인스턴스는 main-server-group
과 연결되며 해당 서버 그룹에서 지정하는 하위 시스템 구성 및 소켓 바인딩을 상속합니다. server-two라는 서버
인스턴스도 main-server-group
과 연결되지만 server
값도 정의합니다. -one에서 사용하는 포트 값과 충돌하지 않도록 소켓 바인딩 port-
offsetserver-three라는 서버
인스턴스는 other-server-group
과 연결되며 해당 그룹의 구성을 사용합니다. 또한 port-offset
값을 정의하고 auto-start
를 false
로 설정하여 호스트 컨트롤러가 시작될 때 이 서버가 시작되지 않도록 합니다.
서버는 관리 CLI를 사용하거나 관리 콘솔 Runtime(런타임 ) 탭에서 구성할 수 있습니다.
서버 추가
다음 관리 CLI 명령을 사용하여 서버를 추가할 수 있습니다.
/host=HOST_NAME/server-config=SERVER_NAME:add(group=SERVER_GROUP_NAME)
서버 업데이트
다음 관리 CLI 명령을 사용하여 서버 특성을 업데이트할 수 있습니다.
/host=HOST_NAME/server-config=SERVER_NAME:write-attribute(name=ATTRIBUTE_NAME,value=VALUE)
서버 제거
다음 관리 CLI 명령을 사용하여 서버를 제거할 수 있습니다.
/host=HOST_NAME/server-config=SERVER_NAME:remove
서버 속성
서버에는 다음 속성이 필요합니다.
-
name
: 서버의 이름입니다. -
그룹
: 도메인 모델의 서버 그룹 이름입니다.
서버에는 다음과 같은 선택적 속성이 포함됩니다.
-
auto-start
: 호스트 컨트롤러가 시작될 때 이 서버를 시작해야 하는지 여부입니다. -
socket-binding-group
: 이 서버가 속한 소켓 바인딩 그룹입니다. -
socket-binding-port-offset
: 이 서버에 대해 소켓 바인딩 그룹에서 지정한 포트 값에 추가할 오프셋입니다. -
update-auto-start-with-server-status
:auto-start
특성을 서버 상태로 업데이트합니다. -
interface
: 서버에서 사용할 수 있는 완전히 지정된 네트워크 인터페이스 목록입니다. -
jvm
: 이 서버에 대한 JVM 설정입니다. 선언되지 않은 경우 상위 서버 그룹 또는 호스트에서 설정이 상속됩니다. -
path
: 명명된 파일 시스템 경로 목록입니다. -
system-property
: 이 서버에 설정할 시스템 속성 목록입니다.
8.4.3. 서버 시작 및 중지
Runtime (런타임) 탭으로 이동하고 적절한 호스트 또는 서버 그룹을 선택하여 관리 콘솔에서 시작, 중지 및 다시 로드와 같은 서버에서 작업을 수행할 수 있습니다.
관리 CLI를 사용하여 이러한 작업을 수행하려면 아래 명령을 참조하십시오.
서버 시작
특정 호스트에서 단일 서버를 시작할 수 있습니다.
/host=HOST_NAME/server-config=SERVER_NAME:start
지정된 서버 그룹의 모든 서버를 시작할 수 있습니다.
/server-group=SERVER_GROUP_NAME:start-servers
서버 중지
특정 호스트에서 단일 서버를 중지할 수 있습니다.
/host=HOST_NAME/server-config=SERVER_NAME:stop
지정된 서버 그룹의 모든 서버를 중지할 수 있습니다.
/server-group=SERVER_GROUP_NAME:stop-servers
서버 다시 로드
특정 호스트에 단일 서버를 다시 로드할 수 있습니다.
/host=HOST_NAME/server-config=SERVER_NAME:reload
지정된 서버 그룹의 모든 서버를 다시 로드할 수 있습니다.
/server-group=SERVER_GROUP_NAME:reload-servers
서버 종료
지정된 서버 그룹의 모든 서버 프로세스를 종료할 수 있습니다.
/server-group=SERVER_GROUP_NAME:kill-servers
8.5. 도메인 컨트롤러 검색 및 페일오버
관리형 도메인을 설정할 때 각 호스트 컨트롤러는 도메인 컨트롤러에 연결하는 데 필요한 정보로 구성해야 합니다. JBoss EAP에서 각 호스트 컨트롤러는 도메인 컨트롤러를 찾기 위한 여러 옵션으로 구성할 수 있습니다. 호스트 컨트롤러는 성공할 때까지 옵션 목록을 반복합니다.
기본 도메인 컨트롤러에 문제가 있는 경우 백업 호스트 컨트롤러를 도메인 비상사로 승격 할 수 있습니다. 이렇게 하면 호스트 컨트롤러가 승격되고 나면 새 도메인 컨트롤러로 자동으로 페일오버할 수 있습니다.
8.5.1. 도메인 검색 옵션 구성
다음은 도메인 컨트롤러를 찾기 위한 여러 옵션을 사용하여 호스트 컨트롤러를 구성하는 방법의 예입니다.
예제: 여러 도메인 컨트롤러 옵션이 있는 호스트 컨트롤러
<domain-controller> <remote security-realm="ManagementRealm"> <discovery-options> <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="172.16.81.100" port="${jboss.domain.master.port:9990}"/> <static-discovery name="backup" protocol="${jboss.domain.master.protocol:remote}" host="172.16.81.101" port="${jboss.domain.master.port:9990}"/> </discovery-options> </remote> </domain-controller>
정적 검색 옵션에는 다음과 같은 필수 속성이 포함됩니다.
- name
- 이 도메인 컨트롤러 검색 옵션의 이름입니다.
- 호스트
- 원격 도메인 컨트롤러의 호스트 이름입니다.
- port
- 원격 도메인 컨트롤러의 포트.
위의 예에서 첫 번째 검색 옵션은 성공할 것으로 예상되는 옵션입니다. 두 번째 방법은 페일오버 상태에서 사용될 수 있습니다.
8.5.2. 캐시된 도메인 구성으로 호스트 컨트롤러 시작
호스트 컨트롤러는 --cached-dc
옵션을 사용하여 도메인 컨트롤러에 연결하지 않고 시작할 수 있지만 호스트 컨트롤러는 이전에 도메인 컨트롤러에서 로컬로 도메인 구성을 캐시해야 합니다. 이 --cached-dc
옵션으로 호스트 컨트롤러를 시작하면 도메인 컨트롤러에서 호스트 컨트롤러의 도메인 구성을 캐시합니다.
$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --cached-dc
그러면 이 호스트 컨트롤러가 도메인 컨트롤러 연결 없이 현재 서버를 일시적으로 관리하는 데 필요한 정보가 포함된
파일이 생성됩니다.
EAP_HOME/domain/configuration/
디렉터리에 domain.cached-remote.xml
기본적으로 --cached-dc
옵션을 사용하면 이 호스트 컨트롤러에서 사용하는 구성만 캐시하므로 전체 도메인의 도메인 컨트롤러로 승격할 수 없습니다. 호스트 컨트롤러가 도메인 컨트롤러 역할을 할 수 있도록 전체 도메인 구성을 캐싱하는 방법에 대한 자세한 내용은 도메인 구성 캐시를 참조하십시오.
--cached-dc
로 이 호스트 컨트롤러를 시작할 때 도메인 컨트롤러를 사용할 수 없는 경우 호스트 컨트롤러는 domain.cached-remote.xml
파일에 저장된 캐시된 구성을 사용하기 시작합니다. 이 파일이 있어야 합니다. 그렇지 않으면 호스트 컨트롤러가 시작되지 않습니다.
이 상태에서 호스트 컨트롤러는 도메인 구성을 수정할 수 없지만 서버를 시작하고 배포를 관리할 수 있습니다.
캐시된 구성으로 시작된 후에도 호스트 컨트롤러는 도메인 컨트롤러에 계속 다시 연결을 시도합니다. 도메인 컨트롤러를 사용할 수 있게 되면 호스트 컨트롤러가 자동으로 다시 연결하고 도메인 구성을 동기화합니다. 일부 구성을 변경하려면 호스트 컨트롤러를 다시 로드해야 할 수 있습니다. 이러한 경우 호스트 컨트롤러에 경고가 기록됩니다.
8.5.3. 호스트 컨트롤러가 도메인 컨트롤러로 작동하도록 승격
기본 도메인 컨트롤러에 문제가 발생하는 경우 호스트 컨트롤러가 도메인 컨트롤러 역할을 하도록 승격할 수 있습니다. 호스트 컨트롤러는 먼저 도메인 컨트롤러에서 로컬로 도메인 구성을 캐시 해야 승격 할 수 있습니다.
도메인 구성 캐시
도메인 컨트롤러가 되고자 할 수 있는 모든 호스트 컨트롤러에 --backup
옵션을 사용합니다.
$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --backup
그러면 전체 도메인 구성의 복사본이 포함된
파일이 생성됩니다. 호스트 컨트롤러가 도메인 컨트롤러 역할을 하도록 재구성되면 이 구성이 사용됩니다.
EAP_HOME/domain/configuration/
디렉터리에 domain.cached-remote.xml
ignore-unused-configuration
특성은 특정 호스트에 대해 캐시할 구성 양을 결정하는 데 사용됩니다. true
값은 이 호스트 컨트롤러와 관련된 구성만 캐시하므로 도메인 컨트롤러로 이수할 수 없습니다. false
값은 전체 도메인 구성이 캐시됨을 의미합니다.
backup 인수는 이
속성의 기본값을 false
로 하여 전체 도메인을 캐시합니다. 그러나 host.xml
파일에서 이 속성을 설정하면 해당 값이 사용됩니다.
또한 --cached-dc
옵션을 사용하여 도메인 구성의 복사본을 생성할 수도 있지만, 전체 도메인을 캐시하려면 host.xml
에서 ignore-unused-configuration
을 false로
설정해야 합니다. 예를 들면 다음과 같습니다.
<domain-controller> <remote username="$local" security-realm="ManagementRealm" ignore-unused-configuration="false"> <discovery-options> ... </discovery-options> </remote> </domain-controller>
호스트 컨트롤러를 도메인 컨트롤러로 승격
- 원래 도메인 컨트롤러가 중지되었는지 확인합니다.
- 관리 CLI를 사용하여 새 도메인 컨트롤러가 될 호스트 컨트롤러에 연결합니다.
다음 명령을 실행하여 새 도메인 컨트롤러 역할을 하도록 호스트 컨트롤러를 구성합니다.
/host=backup:write-attribute(name=domain-controller.local, value={})
다음 명령을 실행하여 호스트 컨트롤러를 다시 로드합니다.
reload --host=HOST_NAME
이 호스트 컨트롤러가 이제 도메인 컨트롤러 역할을 합니다.
8.6. 관리형 도메인 설정
8.6.1. 단일 머신에서 관리형 도메인 설정
jboss.domain.base.dir
속성을 사용하여 단일 시스템에서 여러 호스트 컨트롤러를 실행할 수 있습니다.
두 개 이상의 JBoss EAP 호스트 컨트롤러를 단일 시스템에서 시스템 서비스로 구성하는 것은 지원되지 않습니다.
도메인 컨트롤러의
EAP_HOME/domain
디렉터리를 복사합니다.$ cp -r EAP_HOME/domain /path/to/domain1
호스트 컨트롤러의
EAP_HOME/domain
디렉터리를 복사합니다.$ cp -r EAP_HOME/domain /path/to/host1
/path/to /domain1
을 사용하여 도메인 컨트롤러를 시작합니다.$ EAP_HOME/bin/domain.sh --host-config=host-master.xml -Djboss.domain.base.dir=/path/to/domain1
/path/to /host1
을 사용하여 호스트 컨트롤러를 시작합니다.$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.base.dir=/path/to/host1 -Djboss.domain.master.address=IP_ADDRESS -Djboss.management.http.port=PORT
참고호스트 컨트롤러를 시작할 때
jboss.domain.master.address
속성을 사용하여 도메인 컨트롤러의 주소를 지정해야 합니다.또한 이 호스트 컨트롤러는 도메인 컨트롤러와 동일한 시스템에서 실행되므로 도메인 컨트롤러의 관리 인터페이스와 충돌하지 않도록 관리 인터페이스를 변경해야 합니다. 이 명령은
jboss.management.http.port
속성을 설정합니다.
이러한 방식으로 시작된 각 인스턴스는 기본 설치 디렉터리(예: EAP_HOME/modules/
)에서 나머지 리소스를 공유하지만 jboss.domain.base.dir
에서 지정한 디렉터리에서 도메인 구성을 사용합니다.
8.6.2. 두 머신에서 관리형 도메인 설정
이 예제를 실행하려면 방화벽을 구성해야 할 수도 있습니다.
두 시스템에서 관리형 도메인을 생성할 수 있습니다. 한 시스템은 도메인 컨트롤러이고 다른 시스템은 호스트입니다. 자세한 내용은 도메인 컨트롤러 정보를 참조하십시오.
-
IP1
= 도메인 컨트롤러의 IP 주소(시스템 1) -
IP2
= 호스트의 IP 주소 (시스템 2)
두 시스템에서 관리형 도메인 만들기
시스템 1에서
도메인 컨트롤러에서 호스트를 인증할 수 있도록 관리 사용자를 추가합니다.
add-user.sh
스크립트를 사용하여 호스트 컨트롤러HOST_NAME
의 관리 사용자를 추가합니다. 마지막 프롬프트에yes
로 응답하고 제공된 secret 값을 확인합니다. 이 secret 값은 호스트 컨트롤러 구성에서 사용되며 아래 행과 유사하게 표시됩니다.<secret value="SECRET_VALUE" />
도메인 컨트롤러를 시작합니다.
전용 도메인 컨트롤러에 대해 사전 구성된
host-master.xml
구성 파일을 지정합니다. 또한jboss.bind.address.management
속성을 설정하여 도메인 컨트롤러가 다른 시스템에 표시되도록 합니다.$ EAP_HOME/bin/domain.sh --host-config=host-master.xml -Djboss.bind.address.management=IP1
On Machine 2
사용자 자격 증명으로 호스트 구성을 업데이트합니다.
EAP_HOME/domain/configuration/host-slave.xml
을 편집하고 호스트 이름,HOST_NAME
및 시크릿 값SECRET_VALUE
를 설정합니다.<host xmlns="urn:jboss:domain:8.0" name="HOST_NAME"> <management> <security-realms> <security-realm name="ManagementRealm"> <server-identities> <secret value="SECRET_VALUE" /> </server-identities> ...
호스트 컨트롤러를 시작합니다.
슬레이브
호스트 컨트롤러에 대해 미리 구성된 host-slave.xml
구성 파일을 지정합니다. 또한 도메인 컨트롤러 및jboss.
속성을 설정하여 호스트 컨트롤러 바인드 주소를 설정합니다.bind.address 속성에 연결하도록 jboss.domain.master
.address$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=IP1 -Djboss.bind.address=IP2
시작 시 --controller
매개 변수로 도메인 컨트롤러 주소를 지정하여 관리 CLI에서 도메인을 관리할 수 있습니다.
$ EAP_HOME/bin/jboss-cli.sh --connect --controller=IP1
또는 http://IP1:9990
의 관리 콘솔에서 도메인을 관리할 수 있습니다.
8.7. JBoss EAP 7.4 버전 관리
최신 버전의 JBoss EAP는 이전 버전을 실행 중인 JBoss EAP 서버와 호스트를 관리할 수 있습니다. 최신 버전의 JBoss EAP를 관리하려면 다음 섹션을 참조하십시오.
Red Hat은 JBoss EAP 6.x를 실행하는 호스트 및 서버를 관리하는 JBoss EAP 7.4 도메인 컨트롤러를 더 이상 사용하지 않습니다. 더 이상 사용되지 않는 이러한 지원 기능은 버전 8.0인 다음 주요 JBoss EAP 릴리스에서 완전히 제거됩니다. JBoss EAP 8.0은 JBoss EAP 7.4에서 실행 중인 호스트 및 서버만 지원합니다.
8.7.1. JBoss EAP 7.x 도메인 컨트롤러에서 JBoss EAP 6 인스턴스를 관리하도록 구성
JBoss EAP 7.4 도메인 컨트롤러는 호스트와 서버가 JBoss EAP 6.2 이상을 실행하는 경우 JBoss EAP 6을 실행하는 호스트와 서버를 관리할 수 있습니다.
JBoss EAP 7.0 도메인 컨트롤러가 다른 패치 릴리스에 있는 JBoss EAP 7.0 호스트를 관리하는 경우 JBoss EAP 7.0 도메인 컨트롤러에 구성 변경이 필요하지 않습니다. 그러나 JBoss EAP 7.0 도메인 컨트롤러에서 관리하는 호스트 컨트롤러의 버전과 동일한 패치 릴리스를 실행해야 합니다.
JBoss EAP 7 관리형 도메인에서 JBoss EAP 6 인스턴스를 성공적으로 관리하려면 다음 작업을 완료합니다.
이러한 작업이 완료되면 관리 CLI를 사용하여 JBoss EAP 7 도메인 컨트롤러에서 JBoss EAP 6 서버와 구성을 관리할 수 있습니다. JBoss EAP 6 호스트는 배치 처리와 같은 새로운 JBoss EAP 7 기능을 활용할 수 없습니다.
관리 콘솔은 최신 버전의 JBoss EAP에 최적화되어 있으므로 JBoss EAP 6 호스트, 서버 및 프로필을 업데이트하는 데 사용해서는 안 됩니다. JBoss EAP 7 관리형 도메인에서 JBoss EAP 6 구성을 관리할 때 관리 CLI를 사용합니다.
8.7.1.1. JBoss EAP 7 도메인 컨트롤러에 JBoss EAP 6 구성 추가
도메인 컨트롤러가 JBoss EAP 6 서버를 관리할 수 있도록 하려면 JBoss EAP 7 도메인 구성에서 JBoss EAP 6 구성 세부 정보를 제공해야 합니다. JBoss EAP 6 프로필, 소켓 바인딩 그룹 및 서버 그룹을 JBoss EAP 7 domain.xml
구성 파일에 복사하여 이 작업을 수행할 수 있습니다.
JBoss EAP 7 구성에서 기존 이름과 충돌하는 경우 리소스 이름을 변경해야 합니다. 또한 적절한 동작을 보장하기 위해 몇 가지 추가 조정 도 있습니다.
다음 절차에서는 JBoss EAP 6 기본
프로필, standard-sockets
소켓 바인딩 그룹 및 main-server-group
서버 그룹을 사용합니다.
-
JBoss EAP 7
domain.xml
구성 파일을 편집합니다. 편집하기 전에 이 파일을 백업하는 것이 좋습니다. 해당 JBoss EAP 6 프로필을 JBoss EAP 7
domain.xml
파일에 복사합니다.이 절차에서는 JBoss EAP 6
기본
프로필이 복사되어eap6-default
로 이름이 변경된 것으로 가정합니다.JBoss EAP 7
domain.xml
<profiles> ... <profile name="eap6-default"> ... </profile> </profiles>
이 프로필에서 사용하는 필요한 확장 기능을 추가합니다.
JBoss EAP 6 프로필에서 JBoss EAP 7에 더 이상 존재하지 않는 하위 시스템을 사용하는 경우 JBoss EAP 도메인 구성에 적절한 확장 기능을 추가해야 합니다.
JBoss EAP 7
domain.xml
<extensions> ... <extension module="org.jboss.as.configadmin"/> <extension module="org.jboss.as.threads"/> <extension module="org.jboss.as.web"/> <extensions>
해당 JBoss EAP 6 소켓 바인딩 그룹을 JBoss EAP 7
domain.xml
파일에 복사합니다.이 절차에서는 JBoss EAP 6
standard-sockets
소켓 바인딩 그룹이 복사되어eap6-standard-sockets
로 바뀌었다고 가정합니다.JBoss EAP 7
domain.xml
<socket-binding-groups> ... <socket-binding-group name="eap6-standard-sockets" default-interface="public"> ... </socket-binding-group> </socket-binding-groups>
해당 JBoss EAP 6 서버 그룹을 JBoss EAP 7
domain.xml
파일에 복사합니다.이 절차에서는 JBoss EAP 6
main-server-group
서버 그룹이 복사되어 이름이eap6-main-server-group
로 변경되었다고 가정합니다. 또한 JBoss EAP 6 프로필,eap6-default 및 JBoss EAP 6 소켓 바인딩 그룹인
를 사용하도록 이 서버 그룹을 업데이트해야 합니다.eap6-
standard-socketsJBoss EAP 7
domain.xml
<server-groups> ... <server-group name="eap6-main-server-group" profile="eap6-default"> ... <socket-binding-group ref="eap6-standard-sockets"/> </server-group> </server-groups>
8.7.1.2. JBoss EAP 6 프로필의 동작 업데이트
JBoss EAP 6 인스턴스에서 사용하는 프로필에 대한 추가 업데이트는 JBoss EAP 버전과 원하는 동작에 따라 업데이트해야 합니다. 기존 JBoss EAP 6 인스턴스에서 사용하는 하위 시스템 및 구성에 따라 추가 변경이 필요할 수 있습니다.
JBoss EAP 7 도메인 컨트롤러를 시작하고 해당 관리 CLI를 시작하여 다음 업데이트를 수행합니다. 이 예제에서는 JBoss EAP 6 프로필이 eap6-default
라고 가정합니다.
bean-validation
하위 시스템을 제거합니다.JBoss EAP 7은 해당 하위 시스템에서 빈 유효성 검사 기능을 자체
하위
시스템인bean-validation
으로 이동했습니다. JBoss EAP 7 도메인 컨트롤러에서 레거시 하위 시스템을확인하는
경우 새bean-validation
하위 시스템을 추가합니다. 그러나 JBoss EAP 6 호스트는 이 하위 시스템을 인식하지 않으므로 제거해야 합니다.JBoss EAP 7 도메인 컨트롤러 CLI
/profile=eap6-default/subsystem=bean-validation:remove
CDI 1.0 동작을 설정합니다.
이는 JBoss EAP 7에서 사용되는 이후 CDI 버전의 동작과 달리 JBoss EAP 6 서버에 CDI 1.0 동작을 원하는 경우에만 필요합니다. CDI 1.0 동작을 수행하려면
weld
하위 시스템에서 다음 업데이트를 수행합니다.JBoss EAP 7 도메인 컨트롤러 CLI
/profile=eap6-default/subsystem=weld:write-attribute(name=require-bean-descriptor,value=true) /profile=eap6-default/subsystem=weld:write-attribute(name=non-portable-mode,value=true)
JBoss EAP 6.2의 데이터 소스 통계를 활성화합니다.
이는 JBoss EAP 6.2 서버에서 프로필을 사용하는 경우에만 필요합니다. JBoss EAP 6.3에는
통계를 수집하지 않기 위해 기본값이
특성이 도입되었지만 JBoss EAP 6.2 동작은 통계를 수집하는 것이었습니다. JBoss EAP 6.2 호스트에서 이 프로필을 사용하고 최신 JBoss EAP 버전을 실행하는 호스트에서 사용하는 경우 허용되지 않는 호스트 간에 동작이 일치하지 않습니다. 따라서 JBoss EAP 6.2 호스트에서 사용할 프로필은 해당 데이터 소스에 대해 다음과 같이 변경해야 합니다.false인
statistics-enabledJBoss EAP 7 도메인 컨트롤러 CLI
/profile=eap6-default/subsystem=datasources/data-source=ExampleDS:write-attribute(name=statistics-enabled,value=true)
8.7.1.3. JBoss EAP 6 서버의 서버 그룹 설정
서버 그룹의 이름을 변경한 경우 JBoss EAP 7 구성에 지정된 새 서버 그룹을 사용하도록 JBoss EAP 6 호스트 구성을 업데이트해야 합니다. 이 예에서는 JBoss EAP 7 domain.xml
에 지정된 eap6-main-server-group
서버 그룹을 사용합니다.
JBoss EAP 6 host-slave.xml
<servers> <server name="server-one" group="eap6-main-server-group"/> <server name="server-two" group="eap6-main-server-group"> <socket-bindings port-offset="150"/> </server> </servers>
호스트는 최신 버전의 JBoss EAP에서 도입된 기능 또는 구성 설정을 호스트가 실행 중인 것보다 사용할 수 없습니다.
8.7.1.4. JBoss EAP 6 인스턴스가 JBoss EAP 7 업데이트를 수신하지 못하도록 방지
관리형 도메인의 도메인 컨트롤러는 구성 업데이트를 호스트 컨트롤러에 전달합니다. host-exclude
구성을 사용하여 특정 버전에서 숨겨야 하는 리소스를 지정해야 합니다. JBoss EAP 6 버전에 대해 사전 구성된 호스트 제외
옵션을 선택합니다. EAP62
,EAP63
,EAP64
또는 EAP64z
.
host -
특성은 특정 버전에서 사용하는 서버 그룹 목록을 지정합니다. 이러한 서버 그룹 및 관련 프로필, 소켓 바인딩 그룹 및 배포 리소스는 이 버전의 호스트에서 사용할 수 있지만 다른 모든 호스트는 이러한 호스트에서 숨겨집니다.
exclude 구성의 active-server-
groups
이 예제에서는 버전이 JBoss EAP 6.4.z라고 가정하고 JBoss EAP 6 서버 그룹 eap6-main-server-group
을 활성 서버 그룹으로 추가합니다.
JBoss EAP 7 도메인 컨트롤러 CLI
/host-exclude=EAP64z:write-attribute(name=active-server-groups,value=[eap6-main-server-group])
필요한 경우 active-socket-binding-groups
특성을 사용하여 서버에서 사용하는 추가 소켓 바인딩 그룹을 지정할 수 있습니다. 이는 active-server-groups
에 지정된 서버 그룹과 연결되지 않은 소켓 바인딩 그룹에만 필요합니다.
8.7.2. JBoss EAP 7.4 도메인 컨트롤러에서 JBoss EAP의 이전 마이너 릴리스를 관리하도록 구성
JBoss EAP 7.4 도메인 컨트롤러는 JBoss EAP의 이전 마이너 릴리스에서 실행 중인 호스트와 서버를 관리할 수 있습니다.
JBoss EAP 7.4 관리형 도메인에서 JBoss EAP 7.3 인스턴스를 성공적으로 관리하려면 다음 작업을 완료합니다.
이러한 작업을 완료한 후에는 관리 CLI를 사용하여 JBoss EAP 7.3 서버 및 구성을 JBoss EAP 7.4 도메인 컨트롤러에서 관리할 수 있습니다.
관리 콘솔은 최신 버전의 JBoss EAP에 최적화되었으므로 CLI를 사용하여 JBoss EAP 7.4 관리형 도메인에서 JBoss EAP 7.3 구성을 관리해야 합니다. 관리 콘솔을 사용하여 JBoss EAP 7.3 호스트, 서버 및 프로필을 업데이트하지 마십시오.
8.7.2.1. JBoss EAP 7.3 구성을 JBoss EAP 7.4 도메인 컨트롤러에 추가
도메인 컨트롤러가 JBoss EAP 7.3 서버를 관리할 수 있도록 하려면 JBoss EAP 7.4 도메인 구성에서 JBoss EAP 7.3 구성 세부 정보를 제공해야 합니다. JBoss EAP 7.3 프로필, 소켓 바인딩 그룹 및 서버 그룹을 JBoss EAP 7.4 domain.xml
구성 파일에 복사하여 이 작업을 수행할 수 있습니다.
해당 이름이 JBoss EAP 7.4 구성에서 리소스 이름과 충돌하는 경우 리소스 이름을 변경해야 합니다.
다음 절차에서는 JBoss EAP 7.3 기본
프로필, standard-sockets
소켓 바인딩 그룹 및 main-server-group
서버 그룹을 사용합니다.
사전 요구 사항
-
JBoss EAP 7.3
기본
프로필을eap73-default
로 복사하고 이름을 바꾸었습니다. -
JBoss EAP 7.3
standard-sockets 소켓 바인딩 그룹을
로 복사하고 이름을 변경했습니다.eap73-
standard-sockets JBoss EAP 7.3
main-server-group 서버 그룹을
으로 복사하고 이름을 변경했습니다.eap73-
main-server-group-
JBoss EAP 7.3 프로필,
eap73-default
를 사용하고 JBoss EAP 7.3 소켓 바인딩 그룹인eap73-standard-sockets
를 사용하도록 서버 그룹을 업데이트했습니다.
-
JBoss EAP 7.3 프로필,
절차
JBoss EAP 7.4
domain.xml
구성 파일을 편집합니다.중요파일을 편집하기 전에 JBoss EAP 7.4
domain.xml
구성 파일을 백업합니다.적용 가능한 JBoss EAP 7.3 프로필을 JBoss EAP 7.4
domain.xml
파일에 복사합니다. 예를 들면 다음과 같습니다.<profiles> ... <profile name="eap73-default"> ... </profile> </profiles>
적용 가능한 JBoss EAP 7.3 소켓 바인딩 그룹을 JBoss EAP 7.4
domain.xml
파일에 복사합니다. 예를 들면 다음과 같습니다.<socket-binding-groups> ... <socket-binding-group name="eap73-standard-sockets" default-interface="public"> ... </socket-binding-group> </socket-binding-groups>
해당 JBoss EAP 7.3 서버 그룹을 JBoss EAP 7.4
domain.xml
파일에 복사합니다.<server-groups> ... <server-group name="eap73-main-server-group" profile="eap73-default"> ... <socket-binding-group ref="eap73-standard-sockets"/> </server-group> </server-groups>
8.7.2.2. JBoss EAP7.3 서버의 서버 그룹 설정
서버 그룹의 이름을 변경한 경우 JBoss EAP 7.4 구성에 지정된 새 서버 그룹을 사용하도록 JBoss EAP 7.3 호스트 구성을 업데이트해야 합니다. 이 예에서는 JBoss EAP 7.4 domain.xml
에 지정된 eap73-main-server-group
서버 그룹을 사용합니다.
JBoss EAP 7.3 host-slave.xml
<servers> <server name="server-one" group="eap73-main-server-group"/> <server name="server-two" group="eap73-main-server-group"> <socket-bindings port-offset="150"/> </server> </servers>
호스트는 최신 버전의 JBoss EAP에서 도입된 기능 또는 구성 설정을 호스트가 실행 중인 것보다 사용할 수 없습니다.
8.7.2.3. JBoss EAP 7.3 인스턴스가 JBoss EAP 7.4 업데이트를 수신하지 못하도록 방지
관리형 도메인 컨트롤러는 구성 업데이트를 호스트 컨트롤러에 전달하여 JBoss EAP 7.3 호스트에서 JBoss EAP 7.4에 고유한 구성 및 리소스를 받지 못하도록 합니다. 해당 리소스를 무시하도록 JBoss EAP 7.3 호스트를 구성해야 합니다. JBoss EAP 7.3 호스트에서 ignore-unused-configuration
속성을 설정하여 이 작업을 수행할 수 있습니다.
host-exclude
구성을 사용하여 도메인 컨트롤러에 특정 JBoss EAP 버전을 실행하는 호스트의 특정 리소스를 숨기도록 지시할 수도 있습니다. host-exclude
구성을 사용하는 방법에 대한 예는 JBoss EAP 7 업데이트 수신에서 JBoss EAP 6 인스턴스 방지를 참조하십시오. JBoss EAP 7.3의 경우 EAP73 host
-exclude
옵션을 사용합니다.
JBoss EAP 7.3 호스트 컨트롤러 연결 구성에서 원격 도메인 컨트롤러에 대한 ignore-unused-configuration
속성을 true
로 설정합니다.
JBoss EAP 7.3 host-slave.xml
<domain-controller> <remote security-realm="ManagementRealm" ignore-unused-configuration="true"> <discovery-options> <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/> </discovery-options> </remote> </domain-controller>
이 설정을 사용하면 이 호스트에서 사용하는 서버 그룹과 연결된 프로필, 소켓 바인딩 그룹 및 배포 리소스만 호스트에서 사용할 수 있습니다. 다른 모든 리소스는 무시됩니다.
8.8. JBoss EAP 프로필 관리
8.8.1. 프로필 정보
JBoss EAP는 프로필을 사용하여 서버에서 사용할 수 있는 하위 시스템을 구성합니다. 프로필은 각 하위 시스템의 특정 구성과 함께 사용 가능한 하위 시스템의 컬렉션으로 구성됩니다. 하위 시스템이 많은 프로필으로 인해 많은 기능 세트가 있는 서버가 생성됩니다. 소규모의 집중적인 하위 시스템 세트가 있는 프로필에는 기능 수가 적지만 풋프린트가 더 작습니다.
JBoss EAP에는 대부분의 사용 사례를 충족해야 하는 5가지 사전 정의된 프로필이 제공됩니다.
- default
-
로깅
,보안
,데이터 소스,
infinispan
,웹 서비스
,ee
,ejb3
,트랜잭션
등 일반적으로 사용되는 하위 시스템을 포함합니다. - Ha
-
고가용성을 위해
jgroups
및modcluster
하위 시스템 추가와 함께 default 프로필에 제공된 하위 시스템 포함 - full
-
messaging-activemq 및
하위 시스템 추가와 함께 default 프로필에 제공된 하위 시스템 포함iiop-
openjdk - full-ha
-
고가용성을 위해
jgroups
및modcluster
하위 시스템 추가와 함께 full 프로필에 제공된 하위 시스템 포함 - 로드 밸런서
- 기본 제공 mod_cluster 프론트엔드 로드 밸런서 장치를 사용하여 다른 JBoss EAP 인스턴스의 부하를 분산하는 데 필요한 최소 하위 시스템을 포함합니다.
JBoss EAP는 기존 프로필의 구성에서 하위 시스템을 제거하여 수동으로 확장 기능을 비활성화하거나 드라이버 및 기타 서비스를 해제하는 기능을 제공합니다. 그러나 대부분의 경우 필요하지 않습니다. JBoss EAP는 필요에 따라 하위 시스템을 동적으로 로드하므로 서버 또는 애플리케이션에서 하위 시스템을 사용하지 않는 경우 로드되지 않습니다.
기존 프로필이 필요한 기능을 제공하지 않는 경우 JBoss EAP는 사용자 지정 프로필을 정의하는 기능도 제공합니다.
8.8.2. 프로필 복제
JBoss EAP를 사용하면 기존 프로필을 복제하여 관리형 도메인에서 새 프로필을 생성할 수 있습니다. 이렇게 하면 원본 프로필 구성 및 하위 시스템의 사본이 생성됩니다.
원하는 프로필에서 복제 작업을 사용하여 관리 CLI를 사용하여 프로필을 복제할
수 있습니다.
/profile=full-ha:clone(to-profile=cloned-profile)
복제할 원하는 프로필을 선택하고 Clone (복제)을 클릭하여 관리 콘솔에서 프로필을 복제할 수도 있습니다.
8.8.3. 계층적 프로필 생성
관리형 도메인에서는 프로필의 계층 구조를 만들 수 있습니다. 이를 통해 다른 프로필이 상속할 수 있는 공통 확장 기능을 사용하여 기본 프로필을 생성할 수 있습니다.
관리형 도메인은 domain.xml
에 여러 프로필을 정의합니다. 여러 프로필이 특정 하위 시스템에 대해 동일한 구성을 사용하는 경우 다른 프로필이 아닌 한 위치에만 구성할 수 있습니다. 상위 프로필의 값은 재정의할 수 없습니다.
또한 각 프로필은 자체 충족되어야 합니다. 요소 또는 하위 시스템을 참조하는 경우 참조되는 프로필에 정의해야 합니다.
프로필은 list-add
작업을 사용하고 포함할 프로필을 제공하여 관리 CLI를 사용하여 계층 구조에 다른 프로필을 포함할 수 있습니다.
/profile=new-profile:list-add(name=includes, value=PROFILE_NAME)
9장. JVM 설정 구성
JVM(Java Virtual Machine) 설정 구성은 독립 실행형 JBoss EAP 서버 또는 관리형 도메인의 JBoss EAP 서버에 따라 다릅니다.
독립 실행형 JBoss EAP 서버 인스턴스의 경우 서버 시작 프로세스는 시작 시 JVM 설정을 JBoss EAP 서버에 전달합니다. 이러한 매개변수는 JBoss EAP를 시작하기 전에 명령줄에서 선언하거나 관리 콘솔에서 Configuration(구성) 아래의 System Properties (시스템 속성) 페이지를 사용하여 선언할 수 있습니다.
관리형 도메인에서 JVM 설정은 host .xml 및
구성 파일에서 선언되며 호스트, 서버 그룹 또는 서버 수준에서 구성할 수 있습니다.
domain.xml
시작 중에 JBoss EAP 모듈(예: 로깅 관리자)에서 사용할 JAVA_OPTS
에서 시스템 속성을 구성해야 합니다.
9.1. 독립 실행형 서버에 대한 JVM 설정 구성
독립 실행형 JBoss EAP 서버 인스턴스에 대한 JVM 설정은 서버를 시작하기 전에 JAVA_OPTS
환경 변수를 설정하여 런타임에 선언할 수 있습니다.
Linux에서 JAVA_OPTS
환경 변수를 설정하는 예는 다음과 같습니다.
$ export JAVA_OPTS="-Xmx1024M"
Microsoft Windows 환경에서 동일한 설정을 사용할 수 있습니다.
set JAVA_OPTS="Xmx1024M"
또는 JVM 설정은 JVM에 전달할 옵션 예가 포함된 EAP_HOME/bin
폴더에서
에 추가할 수 있습니다.
standalone.conf
파일 또는 Windows Server용 standalone.conf.bat
JAVA_OPTS
환경 변수를 설정하는 것 외에도 다음 대체 방법 중 하나를 사용하여 시스템 속성을 설정할 수 있습니다.
- 다음 명령을 실행합니다.
$ EAP_HOME/bin/standalone.sh -Dmyproperty=value
-
JBoss 프로필 구성 파일,
standalone*.xml
또는domain.xml
을 편집합니다.
여러 가지 방법으로 시스템 속성을 설정하는 경우 JBoss 프로필 구성 파일인 standalone*.xml
또는 domain.xml
의 값이 다른 값을 재정의하여 JBoss EAP 시작 문제가 발생할 수 있습니다. 예를 들어 JAVA_OPTS
환경 변수 및 JBoss 프로필 구성 파일에 시스템 설정을 정의한 경우 JBoss 프로필 구성의 값은 JAVA_OPTS
의 값을 재정의합니다.
9.2. 관리형 도메인에 대한 JVM 설정 구성
JBoss EAP 관리형 도메인에서는 여러 수준에서 JVM 설정을 정의할 수 있습니다. 특정 호스트에서 사용자 지정 JVM 설정을 정의한 다음 해당 설정을 서버 그룹 또는 개별 서버 인스턴스에 적용할 수 있습니다.
기본적으로 서버 그룹과 개별 서버는 상위 항목의 JVM 설정을 상속하지만 각 수준에서 JVM 설정을 재정의하도록 선택할 수 있습니다.
domain.conf
또는 Windows Server의 경우 domain.conf.bat
의 JVM 설정은 호스트 컨트롤러에서 제어하는 개별 JBoss EAP 서버 인스턴스가 아닌 JBoss EAP 호스트 컨트롤러의 Java 프로세스에 적용됩니다.
9.2.1. 호스트 컨트롤러에서 JVM 설정 정의
호스트 컨트롤러에서 JVM 설정을 정의하고 이러한 설정을 서버 그룹 또는 개별 서버에 적용할 수 있습니다. JBoss EAP에는 기본
JVM 설정이 있지만, 다음 관리 CLI 명령은 일부 사용자 지정 JVM 설정 및 옵션을 사용하여 production_jvm
이라는 새 JVM 설정을 생성하는 방법을 보여줍니다.
/host=HOST_NAME/jvm=production_jvm:add(heap-size=2048m, max-heap-size=2048m, max-permgen-size=512m, stack-size=1024k, jvm-options=["-XX:-UseParallelGC"])
사용 가능한 모든 옵션에 대한 설명은 Managed Domain JVM Configuration Attributes 를 참조하십시오.
런타임 → 호스트로 이동하고 호스트를 선택하고 보기를 클릭하고 JVM 탭을 선택하여 JBoss EAP 관리 콘솔에서 JVM 설정을 생성하고 편집할 수도 있습니다.
이러한 설정은 host. xml
의 <jvm>
태그 내에 저장됩니다.
9.2.2. 서버 그룹에 JVM 설정 적용
서버 그룹을 생성할 때 그룹의 모든 서버에서 사용할 JVM 구성을 지정할 수 있습니다. 다음 관리 CLI 명령은 이전 예제에 표시된 production_jvm
JVM 설정을 사용하는 서버 그룹 이름 groupA
생성을 보여줍니다.
/server-group=groupA:add(profile=default, socket-binding-group=standard-sockets) /server-group=groupA/jvm=production_jvm:add
서버 그룹의 모든 서버는 production_jvm
의 JVM 설정을 상속합니다.
서버 그룹 수준에서 특정 JVM 설정을 재정의할 수도 있습니다. 예를 들어 다른 힙 크기를 설정하려면 다음 명령을 사용할 수 있습니다.
/server-group=groupA/jvm=production_jvm:write-attribute(name=heap-size,value="1024m")
위의 명령을 적용한 후 서버 그룹 groupA
는 production_jvm
에서 JVM 설정을 상속합니다. 단, 재정의된 힙 크기는 1024m
입니다.
사용 가능한 모든 옵션에 대한 설명은 Managed Domain JVM Configuration Attributes 를 참조하십시오.
Runtime → Server Groups (런타임 → 서버 그룹)로 이동하고 서버 그룹을 선택하고 View (보기)를 클릭하고 JVM 탭을 선택하여 JBoss EAP 관리 콘솔에서 서버 그룹 JVM 설정을 편집할 수도 있습니다.
서버 그룹에 대한 이러한 설정은 domain.xml
에 저장됩니다.
9.2.3. 개별 서버에 JVM 설정 적용
기본적으로 개별 JBoss EAP 서버 인스턴스는 해당 서버가 속한 서버 그룹의 JVM 설정을 상속합니다. 그러나 호스트 컨트롤러의 다른 전체 JVM 설정 정의로 상속된 설정을 재정의하거나 특정 JVM 설정을 재정의하도록 선택할 수 있습니다.
예를 들어 다음 명령은 이전 예제에서 서버 그룹의 JVM 정의를 재정의하고 server -one
에 대한 JVM 설정을 기본 JVM 정의로
설정합니다.
/host=HOST_NAME/server-config=server-one/jvm=default:add
또한 서버 그룹과 유사하게 서버 수준에서 특정 JVM 설정을 재정의할 수 있습니다. 예를 들어 다른 힙 크기를 설정하려면 다음 명령을 사용할 수 있습니다.
/host=HOST_NAME/server-config=server-one/jvm=default:write-attribute(name=heap-size,value="1024m")
사용 가능한 모든 옵션에 대한 설명은 Managed Domain JVM Configuration Attributes 를 참조하십시오.
런타임 → 호스트로 이동하고 호스트를 선택하고 서버에서 보기를 클릭하고 JVM s 탭을 선택하여 JBoss EAP 관리 콘솔에서 서버 JVM 설정을 편집할 수도 있습니다.
개별 서버에 대한 이러한 설정은 host.xml
에 저장됩니다.
9.3. JVM 상태 표시
관리 콘솔에서 독립 실행형 또는 관리형 도메인 서버의 힙 및 스레드 사용과 같은 JVM 리소스의 상태를 볼 수 있습니다. 통계가 실시간으로 표시되지 않지만 새로 고침 을 클릭하여 JVM 리소스에 대한 최신 개요를 제공할 수 있습니다.
독립 실행형 JBoss EAP 서버에 대한 JVM 상태를 표시하려면 다음을 수행합니다.
- Runtime(런타임 ) 탭으로 이동하여 서버를 선택하고 Status(상태 )를 선택합니다.
관리형 도메인에서 JBoss EAP 서버의 JVM 상태를 표시하려면 다음을 수행합니다.
- Runtime → Hosts(런타임 → 호스트) 로 이동하여 호스트와 서버를 선택한 다음 Status(상태 )를 선택합니다.
다음은 다음과 같은 힙 사용량 정보를 보여줍니다.
- 최대
- 메모리 관리에 사용할 수 있는 최대 메모리 양입니다.
- 사용됨
- 사용된 메모리 양입니다.
- 커밋됨
- 사용할 Java 가상 머신에 커밋된 메모리 양입니다.
JVM 가동 시간 및 스레드 사용과 같은 기타 정보도 사용할 수 있습니다.
9.4. JVM 조정
JVM 성능 최적화에 대한 팁은 성능 튜닝 가이드의 JVM 튜닝 섹션을 참조하십시오.
10장. 메일 하위 시스템
10.1. 메일 하위 시스템 구성
메일
하위 시스템을 사용하면 JBoss EAP에서 메일 세션을 구성한 다음 JNDI를 사용하여 해당 세션을 애플리케이션에 삽입할 수 있습니다. 또한 Jakarta EE @MailSessionDefinition 및
주석을 사용하는 구성을 지원합니다.
@MailSessionDefinition
s
애플리케이션에서 사용할 SMTP 서버 구성
다음 CLI 명령을 사용하여 SMTP 서버 및 아웃바운드 소켓 바인딩을 구성합니다. 예를 들면 다음과 같습니다.
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-smtp:add(host=localhost, port=25)
/subsystem=mail/mail-session=mySession:add(jndi-name=java:jboss/mail/MySession)
/subsystem=mail/mail-session=mySession/server=smtp:add(outbound-socket-binding-ref=my-smtp, username=user, password=pass, tls=true)
애플리케이션 내에서 구성된 메일 세션 호출
@Resource(lookup="java:jboss/mail/MySession") private Session session;
메일 세션 및 서버 구성에 사용할 수 있는 속성의 전체 목록은 Mail Subsystem Attributes 를 참조하십시오.
10.2. 사용자 지정 전송 구성
POP3 또는 IMAP과 같은 표준 메일 서버를 사용하는 경우 메일 서버에는 정의할 수 있는 특성 집합이 있습니다. 이러한 속성 중 일부는 필수입니다. 가장 중요한 것은 아웃바운드 메일 소켓 바인딩에 대한 참조이며 호스트 주소와 포트 번호로 정의되는 outbound-socket-binding-ref
입니다.
아웃바운드-소켓-바인딩-ref
를 정의하는 것이 부하 분산을 위해 여러 호스트를 사용하여 호스트 구성을 사용하는 사용자에게 가장 효과적인 솔루션이 아닐 수 있습니다. 표준 Jakarta Mail은 부하 분산을 위해 여러 호스트를 사용하는 호스트 구성을 지원하지 않습니다. 따라서 여러 호스트를 사용하여 이 구성이 있는 사용자는 사용자 지정 메일 전송을 구현해야 합니다. 이러한 사용자 지정 메일 전송에는 아웃바운드-소켓-바인딩-ref
가 필요하지 않으며 사용자 지정 호스트 속성 형식이 허용됩니다.
관리 CLI에서 사용자 지정 메일 전송을 구성할 수 있습니다.
새 메일 세션을 추가하고 JNDI 이름을 지정합니다.
/subsystem=mail/mail-session=mySession:add(jndi-name=java:jboss/mail/MySession)
아웃바운드 소켓 바인딩을 추가하고 호스트 및 포트를 지정합니다.
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-smtp-binding:add(host=localhost, port=25)
SMTP 서버를 추가하고 아웃바운드 소켓 바인딩, 사용자 이름 및 암호를 지정합니다.
/subsystem=mail/mail-session=mySession/server=smtp:add(outbound-socket-binding-ref=my-smtp-binding, username=user, password=pass, tls=true)
유사한 단계를 사용하여 POP3 또는 IMAP 서버를 구성할 수 있습니다.
POP3 서버
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-pop3-binding:add(host=localhost, port=110) /subsystem=mail/mail-session=mySession/server=pop3:add(outbound-socket-binding-ref=my-pop3-binding, username=user, password=pass)
IMAP 서버
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-imap-binding:add(host=localhost, port=143) /subsystem=mail/mail-session=mySession/server=imap:add(outbound-socket-binding-ref=my-imap-binding, username=user, password=pass)
사용자 지정 서버를 사용하려면 아웃바운드 소켓 바인딩 없이 사용자 지정 메일 서버를 만듭니다. 사용자 지정 메일 서버의 속성 정의에 호스트 정보를 지정할 수 있습니다. 예를 들면 다음과 같습니다.
/subsystem=mail/mail-session=mySession/custom=myCustomServer:add(username=user,password=pass, properties={"host" => "myhost", "my-property" =>"value"})
사용자 지정 프로토콜을 정의하는 경우 마침표(.
)를 포함하는 속성 이름은 정규화된 이름으로 간주되며 직접 전달됩니다. my-property
와 같은 기타 모든 형식은 mail.server-name.my-property 형식으로 변환됩니다
.
다음 XML은 사용자 지정 서버를 포함하는 메일 구성의 예입니다.
<subsystem xmlns="urn:jboss:domain:mail:3.0"> <mail-session name="default" jndi-name="java:jboss/mail/Default"> <smtp-server outbound-socket-binding-ref="mail-smtp"/> </mail-session> <mail-session name="myMail" from="user.name@domain.org" jndi-name="java:/Mail"> <smtp-server password="password" username="user" tls="true" outbound-socket-binding-ref="mail-smtp"/> <pop3-server outbound-socket-binding-ref="mail-pop3"/> <imap-server password="password" username="nobody" outbound-socket-binding-ref="mail-imap"/> </mail-session> <mail-session name="custom" jndi-name="java:jboss/mail/Custom" debug="true"> <custom-server name="smtp" password="password" username="username"> <property name="host" value="mail.example.com"/> </custom-server> </mail-session> <mail-session name="custom2" jndi-name="java:jboss/mail/Custom2" debug="true"> <custom-server name="pop3" outbound-socket-binding-ref="mail-pop3"> <property name="custom-prop" value="some-custom-prop-value"/> </custom-server> </mail-session> </subsystem>
10.3. 암호에 자격 증명 저장소 사용
메일
하위 시스템에서 일반 텍스트 암호를 제공하는 것 외에도 자격 증명 저장소를 사용하여 암호를 제공할 수도 있습니다. elytron
하위 시스템은 JBoss EAP 전체에서 암호를 안전하게 보관하고 사용할 수 있도록 자격 증명 저장소를 만들 수 있는 기능을 제공합니다. 자격 증명 저장소 생성 및 사용에 대한 자세한 내용은 서버 보안 구성 방법의 Credential Store 섹션에서 확인할 수 있습니다.
관리 CLI를 사용하여 자격 증명 저장소 사용
/subsystem=mail/mail-session=mySession/server=smtp:add(outbound-socket-binding-ref=my-smtp-binding, username=user, credential-reference={store=exampleCS, alias=mail-session-pw}, tls=true)
다음은 일반 텍스트 암호를 사용하는 자격 증명-참조
특성을 지정하는 방법의 예입니다.
credential-reference={clear-text="MASK-Ewcyuqd/nP9;A1B2C3D4;351"}
관리 콘솔을 사용하여 자격 증명 저장소 사용
- 관리 콘솔에 액세스합니다. 자세한 내용은 관리 콘솔을 참조하십시오.
- 구성 → 하위 시스템 → 메일로 이동합니다.
- 적절한 메일 세션을 선택하고 View(보기 )를 클릭합니다.
- Server 를 선택하고 적절한 메일 세션 서버를 선택합니다. 자격 증명 참조 탭에서 자격 증명 참조를 구성하고 Attributes (특성) 탭에서 다른 특성을 편집할 수 있습니다.
11장. JBoss EAP로 로깅
JBoss EAP는 자체 내부 용도와 배포된 애플리케이션에서 사용할 수 있도록 구성 가능한 로깅 기능을 제공합니다. 로깅
하위 시스템은 JBoss LogManager를 기반으로 하며 JBoss Logging 외에도 여러 타사 애플리케이션 로깅 프레임워크를 지원합니다.
11.1. 서버 로깅 정보
11.1.1. 서버 로깅
기본적으로 모든 JBoss EAP 로그 항목은 server.log
파일에 작성됩니다. 이 파일의 위치는 작동 모드에 따라 다릅니다.
-
독립 실행형 서버:
EAP_HOME/standalone/log/server.log
-
관리형 도메인:
EAP_HOME/domain/servers/SERVER_NAME/log/server.log
이 파일은 종종 서버 로그라고 합니다. 자세한 내용은 Root Logger 섹션을 참조하십시오.
11.1.2. 부트업 로깅
부팅 중에 JBoss EAP는 Java 환경과 각 서비스의 시작에 대한 정보를 기록합니다. 이 로그는 문제를 해결할 때 유용할 수 있습니다. 기본적으로 모든 로그 항목은 서버 로그에 기록됩니다.
부팅 로깅 구성은 logging.properties
구성 파일에서 지정되며, 이 파일은 JBoss EAP 로깅
하위 시스템이 시작될 때까지 활성화되고 이를 대신합니다. 이 파일의 위치는 작동 모드에 따라 다릅니다.
-
독립 실행형 서버:
EAP_HOME/standalone/configuration/logging.properties
관리형 도메인:
도메인 컨트롤러와 각 서버에 대해
logging.properties
파일이 있습니다.-
도메인 컨트롤러:
EAP_HOME/domain/configuration/logging.properties
-
서버:
EAP_HOME/domain/servers/SERVER_NAME/data/logging.properties
-
도메인 컨트롤러:
필요한 특정 사용 사례를 모르는 경우를 제외하고 logging.properties
파일을 직접 편집하지 않는 것이 좋습니다. 이 작업을 수행하기 전에 Red Hat 고객 포털에서 지원 사례를 여는 것이 좋습니다.
logging.properties
파일에서 수동으로 변경한 내용은 시작 시 덮어씁니다.
11.1.2.1. 부팅 오류 보기
JBoss EAP 문제를 해결할 때 부팅 중에 발생한 오류를 확인하는 것은 첫 번째 단계 중 하나여야 합니다. 그런 다음 제공된 정보를 사용하여 원인을 진단하고 해결할 수 있습니다. 부팅 오류 해결에 대한 지원 케이스를 엽니다.
부팅 오류를 보는 방법에는 각각 두 가지 이점이 있습니다. read -boot-errors 관리 CLI 명령을 사용하여 server.log
파일을 검사하거나 부팅 오류를 읽을 수 있습니다.
서버 로그 파일 검사
server.log
파일을 열어 부팅 중에 발생한 오류를 볼 수 있습니다.
이 방법을 사용하면 각 오류 메시지를 관련 메시지와 함께 확인할 수 있으므로 오류가 발생한 이유에 대한 자세한 정보를 얻을 수 있습니다. 또한 일반 텍스트 형식으로 오류 메시지를 볼 수 있습니다.
-
파일 뷰어에서 파일
server.log
를 엽니다. - 파일의 끝으로 이동합니다.
-
최신 부팅 시퀀스의 시작을 나타내는
WFLYSRV0049
메시지 식별자를 뒤로 검색합니다. -
해당 지점에서
ERROR
인스턴스의 로그를 검색합니다. 각 인스턴스에는 오류에 대한 설명이 포함되어 있으며 관련 모듈을 나열합니다.
다음은 server.log
로그 파일의 오류 설명 예입니다.
2016-03-16 14:32:01,627 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.net.BindException: Address already in use ...
관리 CLI에서 부팅 오류 읽기
read-boot-errors
관리 CLI 명령을 사용하여 서버가 시작되지만 부팅 중에 오류가 보고되는 경우 오류를 볼 수 있습니다.
이 방법은 서버의 파일 시스템에 대한 액세스 권한이 필요하지 않으므로 파일 시스템 액세스 권한이 없는 오류에 대한 모니터링에 유용합니다. 관리 CLI 명령이므로 스크립트에서 사용할 수 있습니다. 예를 들어 여러 JBoss EAP 인스턴스를 시작하는 스크립트를 작성한 다음 부팅 시 발생한 오류를 확인할 수 있습니다.
다음 관리 CLI 명령을 실행합니다.
/core-service=management:read-boot-errors
부팅 중에 발생한 모든 오류가 표시됩니다.
{ "outcome" => "success", "result" => [ { "failed-operation" => { "operation" => "add", "address" => [ ("subsystem" => "undertow"), ("server" => "default-server"), ("http-listener" => "default") ] }, "failure-description" => "{\"WFLYCTL0080: Failed services\" => {\"jboss.undertow.listener.default\" => \"org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener Caused by: java.net.BindException: Address already in use\"}}", "failed-services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener Caused by: java.net.BindException: Address already in use"} } ... ] }
11.1.3. 가비지 컬렉션 로깅
가비지 컬렉션 로깅은 모든 가비지 컬렉션 활동을 일반 텍스트 로그 파일에 기록합니다. 이러한 로그 파일은 진단 목적으로 유용할 수 있습니다. 가비지 컬렉션 로깅은 IBM Java 개발 키트를 제외한 지원되는 모든 구성에서 JBoss EAP 독립 실행형 서버에 기본적으로 활성화됩니다.
가비지 컬렉션 로그의 위치는 EAP_HOME/standalone/log/gc.log.DIGIT.current
입니다. 가비지 컬렉션 로그는 각각 3MB로 제한되며 최대 5개의 파일이 순환됩니다.
가비지 컬렉션 로깅을 활성화하는 것이 좋습니다. 문제 해결에 유용할 수 있으며 오버헤드가 최소화되어야 합니다. 그러나 서버를 시작하기 전에 GC_LOG
변수를 false
로 설정하여 독립 실행형 서버에 대한 가비지 컬렉션 로깅을 비활성화할 수 있습니다. 예를 들면 다음과 같습니다.
$ export GC_LOG=false
$ EAP_HOME/bin/standalone.sh
11.1.4. 기본 로그 파일 위치
다음 로그 파일이 기본 로깅 구성에 대해 생성됩니다. 기본 구성은 주기적인 로그 핸들러를 사용하여 서버 로그 파일을 작성합니다.
표 11.1. 독립 실행형 서버의 기본 로그 파일
로그 파일 | 설명 |
---|---|
EAP_HOME/standalone/log/server.log | 서버 시작 메시지를 포함하여 서버 로그 메시지를 포함합니다. |
EAP_HOME/standalone/log/gc.log.DIGIT.current | 가비지 컬렉션 세부 정보를 포함합니다. |
표 11.2. 관리형 도메인의 기본 로그 파일
로그 파일 | 설명 |
---|---|
EAP_HOME/domain/log/host-controller.log | 호스트 컨트롤러 시작과 관련된 로그 메시지를 포함합니다. |
EAP_HOME/domain/log/process-controller.log | 프로세스 컨트롤러 시작과 관련된 로그 메시지를 포함합니다. |
EAP_HOME/domain/servers/SERVER_NAME/log/server.log | 서버 시작 메시지를 포함하여 명명된 서버에 대한 로그 메시지를 포함합니다. |
11.1.5. 서버의 기본 로케일 설정
적절한 시작 구성 파일에서 JVM 속성을 설정하여 JBoss EAP의 기본 로케일을 구성할 수 있습니다. 시작 구성 파일은 독립 실행형 서버에 대한 EAP_HOME/bin/standalone.conf
또는 관리형 도메인의 EAP_HOME/bin/domain.conf
입니다.
Windows Server의 경우 JBoss EAP 시작 구성 파일은 standalone.conf.bat
및 domain.conf.bat
입니다.
국제화 및 현지화된 로그 메시지는 이 기본 로케일을 사용합니다. 국제화된 로그 메시지 생성에 대한 정보는 JBoss EAP 개발 가이드를 참조하십시오.
언어 설정
JAVA_OPTS
변수를 사용하여 user.language
속성을 설정하여 언어를 지정합니다. 예를 들어 시작 구성 파일에 다음 행을 추가하여 프랑스어 로케일을 설정합니다.
JAVA_OPTS="$JAVA_OPTS -Duser.language=fr"
국제화 및 현지화된 로그 메시지가 이제 프랑스어로 출력됩니다.
언어 및 국가 설정
언어 외에도 user.country
속성을 설정하여 국가를 지정해야 할 수도 있습니다. 예를 들어 시작 구성 파일에 다음 행을 추가하여 브라질의 포르투갈어 로케일을 설정합니다.
JAVA_OPTS="$JAVA_OPTS -Duser.language=pt -Duser.country=BR"
국제화 및 현지화된 로그 메시지가 이제 브라질 포르투갈어로 출력됩니다.
org.jboss.logging.locale 속성을 사용하여 서버 로케일 설정
JBoss EAP의 모든 메시지와 소유 종속성을 포함하여 JBoss Logging을 사용하여 기록된 메시지의 로케일을 재정의하도록 org.jboss.logging.locale
속성을 구성할 수 있습니다. Jakarta Server Faces와 같은 기타 종속 항목은 재정의된 로케일을 가져올 수 없습니다.
시스템 기본값과 다른 로케일로 JBoss EAP 서버를 시작하려면 운영 모드에 따라 EAP_HOME/bin/standalone.conf
또는 EAP_HOME/bin/domain.conf
파일을 편집하고 다음 명령을 추가하여 필요한 로케일의 JVM 매개 변수를 설정할 수 있습니다. 속성 값은 BCP 47 형식으로 지정해야 합니다. 예를 들어 브라질 포르투갈어를 설정하려면 pt-BR을 사용합니다.
JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.logging.locale=pt-BR"
11.2. 로그 파일 보기
오류, 성능 문제 및 기타 문제를 진단하려면 서버 및 애플리케이션 로그를 보는 것이 중요합니다. 일부 사용자는 서버 파일 시스템에서 직접 로그를 보는 것을 선호할 수 있습니다. 파일 시스템에 대한 직접 액세스 권한이 없거나 그래픽 인터페이스를 선호하는 사용자의 경우 JBoss EAP를 사용하면 관리 콘솔에서 로그를 볼 수 있습니다. 관리 CLI를 사용하여 로그를 볼 수도 있습니다.
관리 인터페이스 중 하나에서 액세스할 수 있으려면 서버의 jboss.server.log.dir
속성에서 지정한 디렉터리에 있고 파일, 주기 회전, 크기 회전 또는 주기 크기 회전 로그 핸들러로 정의되어야 합니다. RBAC 역할 할당도 준수되므로 관리 콘솔 또는 CLI에 로그인한 사용자는 액세스할 권한이 있는 로그만 볼 수 있습니다.
관리 콘솔에서 로그 보기
관리 콘솔에서 직접 로그를 볼 수 있습니다.
- Runtime(런타임 ) 탭을 선택하고 적절한 서버를 선택합니다.
- 로그 파일을 선택하고 목록에서 로그 파일을 선택합니다.
- View(보기 )를 클릭하여 로그 콘텐츠를 보고 검색하거나 드롭다운에서 Download (다운로드)를 선택하여 로그 파일을 로컬 파일 시스템에 다운로드합니다.
관리 콘솔 로그 뷰어는 텍스트 편집기 대신 큰 로그 파일을 보기 위한 것이 아닙니다(예: 100MB 이상). 15MB보다 큰 로그 파일을 열려는 경우 확인 메시지가 표시됩니다. 관리 콘솔에서 매우 큰 파일을 열면 브라우저가 충돌할 수 있으므로 항상 큰 로그 파일을 로컬로 다운로드하고 텍스트 편집기에서 열어야 합니다.
관리 CLI에서 로그 보기
read -log-file 명령을 사용하여 관리 CLI에서 로그 파일의 내용을 읽을
수 있습니다. 기본적으로 지정된 로그 파일의 마지막 10
행을 표시합니다.
/subsystem=logging/log-file=LOG_FILE_NAME:read-log-file
관리형 도메인에서 이 명령 앞에 /host=HOST_NAME/server=SERVER_NAME
이 있습니다.
다음 매개 변수를 사용하여 로그 출력을 사용자 지정할 수 있습니다.
- 인코딩
- 파일을 읽는 데 사용되는 문자 인코딩.
- 행
-
파일에서 읽을 행 수입니다. 값
-1
은 모든 로그 행을 읽습니다. 기본값은10
입니다. - 건너뛰기
-
읽기 전에 건너뛸 행 수입니다. 기본값은
0
입니다. - tail
-
파일의 끝에서 읽을지 여부입니다. 기본값은
true
입니다.
예를 들어 다음 관리 CLI 명령은 server.log
로그 파일 상단에서 처음 5
행을 읽습니다.
/subsystem=logging/log-file=server.log:read-log-file(lines=5,tail=false)
이렇게 하면 다음 출력이 생성됩니다.
{ "outcome" => "success", "result" => [ "2016-03-24 08:49:26,612 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.1.Final-redhat-1", "2016-03-24 08:49:26,788 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final-redhat-1", "2016-03-24 08:49:26,863 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: JBoss EAP 7.0.0.GA (WildFly Core 2.0.13.Final-redhat-1) starting", "2016-03-24 08:49:27,973 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)", "2016-03-24 08:49:27,994 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.4.Final-redhat-1" ] }
11.3. 로깅 하위 시스템 정보
JBoss EAP 로깅
하위 시스템은 로그 카테고리 및 로그 핸들러 의 시스템을 사용하여 구성됩니다. 로그 범주는 캡처할 메시지를 정의합니다. 로그 핸들러는 해당 메시지를 처리하는 방법을 정의합니다(예: 디스크에 작성하거나 콘솔에 전송).
로깅 프로필을 사용하면 고유하게 이름 지정된 로깅 구성 세트를 생성하고 다른 로깅 구성과는 별도로 애플리케이션에 할당할 수 있습니다. 로깅 프로필의 구성은 기본 로깅
하위 시스템과 거의 동일합니다.
11.3.1. 루트 로거
JBoss EAP 루트 로거는 지정된 로그 수준 이상의 모든 로그 메시지를 캡처하여 로그 범주에서 캡처하지 않은 서버로 전송합니다.
기본적으로 루트 로거는 콘솔과 주기적인 로그 핸들러를 사용하도록 구성됩니다. 정기적인 로그 핸들러는 server.log
파일에 작성하도록 구성됩니다. 이 파일은 종종 서버 로그라고 합니다.
자세한 내용은 루트 로거 구성을 참조하십시오.
11.3.2. 로그 카테고리
로그 범주는 캡처할 로그 메시지 집합과 메시지를 처리할 하나 이상의 로그 핸들러를 정의합니다.
캡처할 로그 메시지는 origin 및 로그 수준의 지정된 Java 패키지에 의해 정의됩니다. 해당 패키지의 클래스 및 해당 로그 수준 이상의 클래스의 메시지는 로그 범주에서 캡처되어 지정된 로그 핸들러로 전송됩니다.
일반적으로 로그 카테고리는 Java 패키지 및 클래스 이름이지만 Logger.getLogger(LOGGER_NAME)
메서드에서 지정하는 모든 이름이 될 수 있습니다.
로그 카테고리는 자체 핸들러 대신 루트 로거의 로그 핸들러를 선택적으로 사용할 수 있습니다.
자세한 내용은 로그 카테고리 구성을 참조하십시오.
11.3.3. 로그 핸들러
로그 핸들러는 캡처된 로그 메시지가 기록되는 방법을 정의합니다. 사용 가능한 로그 핸들러 유형은 console,file,periodic,size,periodic size,syslog,custom, async 입니다.
로그 핸들러를 활성화하려면 하나 이상의 로거에 추가해야 합니다.
로그 핸들러 유형
- 콘솔
-
콘솔 로그 핸들러는 호스트 운영 체제의 표준 출력,
stdout
또는 표준 오류인stderr
, 스트림에 로그 메시지를 작성합니다. 이 메시지는 명령줄 프롬프트에서 JBoss EAP를 실행하면 표시됩니다. 운영 체제가 표준 출력 또는 표준 오류 스트림을 캡처하도록 구성되지 않는 한 콘솔 로그 핸들러의 메시지는 저장되지 않습니다. - 파일
- 파일 로그 핸들러는 로그 메시지를 지정된 파일에 씁니다.
- 주기
- 주기적인 로그 핸들러는 지정된 기간이 경과할 때까지 로그 메시지를 명명된 파일에 씁니다. 기간이 경과하면 지정된 타임스탬프를 추가하여 파일의 이름이 바뀝니다. 핸들러는 원래 이름을 사용하여 새로 생성된 로그 파일에 계속 씁니다.
- 크기
- 크기 로그 핸들러는 파일이 지정된 크기에 도달할 때까지 명명된 파일에 로그 메시지를 작성합니다. 파일이 지정된 크기에 도달하면 숫자 접미사로 이름이 변경되고 핸들러는 원래 이름을 사용하여 새로 생성된 로그 파일에 계속 씁니다. 각 크기 로그 핸들러는 이러한 방식으로 보관할 최대 파일 수를 지정해야 합니다.
- 정기적인 크기
주기적인 크기 로그 핸들러는 파일이 지정된 크기 또는 지정된 기간이 경과할 때까지 명명된 파일에 로그 메시지를 씁니다. 그런 다음 파일의 이름이 바뀌고 핸들러는 원래 이름을 사용하여 새로 생성된 로그 파일에 계속 씁니다.
이는 주기적 및 크기 로그 핸들러의 조합이며 결합된 속성을 지원합니다.
- syslog
- syslog 핸들러는 메시지를 원격 로깅 서버로 보내는 데 사용할 수 있습니다. 이를 통해 여러 애플리케이션에서 모두 함께 구문 분석할 수 있는 동일한 서버에 로그 메시지를 보낼 수 있습니다.
- 소켓
- 소켓 로그 핸들러는 소켓을 통해 로그 메시지를 원격 로깅 서버로 보내는 데 사용할 수 있습니다. TCP 또는 UDP 소켓일 수 있습니다.
- 사용자 지정
-
사용자 지정 로그 핸들러를 사용하면 구현된 새로운 로그 핸들러 유형을 구성할 수 있습니다. 사용자 지정 핸들러는
java.util.logging.Handler
를 확장하고 모듈에 포함된 Java 클래스로 구현해야 합니다. Log4J appender를 사용자 지정 로그 핸들러로 사용할 수도 있습니다. - async
- 비동기 로그 핸들러는 하나 이상의 다른 로그 핸들러에 대해 비동기 동작을 제공하는 래퍼 로그 핸들러입니다. 이 기능은 네트워크 파일 시스템에 로그 파일을 작성하는 등의 대기 시간이 길거나 기타 성능 문제가 있는 로그 핸들러에 유용합니다.
이러한 각 로그 핸들러 구성에 대한 자세한 내용은 로그 핸들러 구성 섹션을 참조하십시오.
11.3.4. 로그 수준
로그 수준은 로그 메시지의 특성 및 심각도를 나타내는 열거된 값입니다. 개발자는 선택한 로깅 프레임워크의 적절한 방법을 사용하여 지정된 로그 메시지 수준을 지정하여 메시지를 보낼 수 있습니다.
JBoss EAP는 지원되는 애플리케이션 로깅 프레임워크에서 사용하는 모든 로그 수준을 지원합니다. 가장 일반적으로 사용되는 로그 수준은 TRACE
,DEBUG
,INFO
,WARN
,ERROR
, FATAL
입니다.
로그 수준은 로그 범주와 핸들러가 책임지는 메시지를 제한하도록 사용합니다. 각 로그 수준에는 다른 로그 수준에 상대적인 순서를 나타내는 숫자 값이 할당됩니다. 로그 카테고리 및 핸들러에는 로그 수준이 할당되며 해당 수준 이상의 로그 메시지만 처리합니다. 예를 들어 WARN 수준이 있는 로그 핸들러는 수준 WARN
,
ERROR
, FATAL
의 메시지만 기록합니다.
지원되는 로그 수준
로그 수준 | 현재의 | 설명 |
---|---|---|
모두 | Integer.MIN_VALUE | 모든 로그 메시지를 제공합니다. |
마케도니아 | 300 | - |
더 세분화 | 400 | - |
TRACE | 400 |
|
디버그 | 500 |
|
NICE | 500 | - |
CONFIG | 700 | - |
정보 | 800 |
|
경고 | 900 |
|
경고 | 900 | - |
ERROR | 1000 |
|
심각 | 1000 | - |
치명적 | 1100 |
|
꺼짐 | Integer.MAX_VALUE | 는 로그 메시지를 표시하지 않습니다. |
ALL
은 가장 낮은 로그 수준이며 모든 로그 수준의 메시지를 포함합니다. 이는 가장 많은 로깅을 제공합니다.
FATAL
은 가장 높은 로그 수준이며 해당 수준의 메시지만 포함합니다. 이는 최소 로깅 양을 제공합니다.
11.3.5. 로그 포맷터
포맷터는 로그 메시지를 포맷하는 데 사용됩니다. named-formatter
특성을 사용하여 로깅 핸들러에 포맷터를 할당할 수 있습니다. 로깅 핸들러 구성에 대한 자세한 내용은 로그 핸들러 구성을 참조하십시오.
로깅 하위 시스템에는 네 가지 유형의 포맷터가 포함됩니다.
Pattern Formatter
패턴 포맷터는 로그 메시지를 일반 텍스트로 포맷하는 데 사용됩니다. formatter를 로그 핸들러의 named-formatter
특성으로 사용하는 것 외에도 formatter
리소스를 먼저 생성할 필요 없이 formatter 속성으로 사용할 수도 있습니다. 패턴 구문에 대한 자세한 내용은 패턴 형식 형식 문자를 참조하십시오.
패턴 포맷터를 구성하는 방법에 대한 자세한 내용은 Configure a Pattern Formatter 를 참조하십시오.
JSON Formatter
JSON 포맷터는 JSON으로 로그 메시지를 포맷하는 데 사용됩니다.
JSON 포맷터를 구성하는 방법에 대한 자세한 내용은 JSON 로그 포맷터 구성을 참조하십시오.
XML Formatter
XML 로그 포맷터는 XML로 로그 메시지를 포맷하는 데 사용됩니다.
XML 로그 포맷터 구성 방법에 대한 자세한 내용은 XML 로그 포맷터 구성을 참조하십시오.
사용자 정의 Formatter
핸들러와 함께 사용할 사용자 지정 포맷터입니다. 대부분의 로그 레코드는 printf 형식으로 포맷됩니다. 포맷터는 메시지를 올바르게 포맷하기 위해 org.jboss.logmanager.ExtLogRecord#getFormattedMessage()
를 호출해야 할 수 있습니다.
사용자 지정 로그 포맷 터를 구성하는 방법에 대한 자세한 내용은 사용자 지정 로그 포맷터 구성을 참조하십시오.
11.3.6. 필터 표현식
filter-spec
특성을 사용하여 구성된 필터 표현식은 다양한 기준에 따라 로그 메시지를 기록하는 데 사용됩니다. 필터 검사는 항상 포맷되지 않은 원시 메시지에서 수행됩니다. 로거 또는 핸들러에 대한 필터를 포함할 수 있지만 logger 필터는 핸들러에 배치된 필터보다 우선합니다.
루트 로거에 지정된 filter-spec
은 다른 로거에서 상속되지 않습니다. 대신 핸들러별로 filter-spec
을 지정해야 합니다.
표 11.3. 로깅을 위한 필터 표현식
필터 표현식 | 설명 |
---|---|
수락 | 모든 로그 메시지를 수락합니다. |
deny | 모든 로그 메시지를 거부합니다. |
not[filter expression] | 단일 필터 표현식의 반전된 값을 반환합니다. 예를 들면 다음과 같습니다.
|
모두[filter 표현식] | 쉼표로 구분된 필터 표현식 목록에서 연결된 값을 반환합니다. 예를 들면 다음과 같습니다.
|
any[filter 표현식] | 쉼표로 구분된 필터 표현식 목록에서 하나의 값을 반환합니다. 예를 들면 다음과 같습니다.
|
levelChange[level] | 지정된 수준으로 로그 레코드를 업데이트합니다. 예를 들면 다음과 같습니다.
|
수준[수준] | 쉼표로 구분된 수준 목록에 나열된 수준으로 로그 메시지를 필터링합니다. 예를 들면 다음과 같습니다.
|
levelRange[minLevel,maxLevel] |
지정된 수준 범위 내에서 로그 메시지를 필터링합니다.
|
match["pattern"] | 제공된 정규 표현식을 사용하여 로그 메시지를 필터링합니다. 예를 들면 다음과 같습니다.
|
substitute["pattern","replacement value"] | 첫 번째 일치 패턴(첫 번째 인수)을 대체 텍스트(두 번째 인수)로 대체하는 필터입니다. 예를 들면 다음과 같습니다.
|
substituteAll["pattern","replacement value"] | 패턴의 모든 일치 항목(첫 번째 인수)을 대체 텍스트(두 번째 인수)로 바꾸는 필터입니다. 예를 들면 다음과 같습니다.
|
관리 CLI를 사용하여 필터 표현식을 구성할 때 값이 문자열로 올바르게 처리되도록 필터 텍스트에서 쉼표 및 따옴표 표시를 이스케이프해야 합니다. 쉼표와 따옴표 앞에 백슬래시(\) 앞에 표시하고 전체 표현식을
따옴표로 묶어야 합니다. 다음은 alternative All("WFLY","YLFW")
을 올바르게 이스케이프하는 예입니다.
/subsystem=logging/console-handler=CONSOLE:write-attribute(name=filter-spec, value="substituteAll(\"WFLY\"\,\"YLFW\")")
11.3.7. 암시적 로깅 종속성
기본적으로 JBoss EAP 로깅
하위 시스템은 암시적 로깅 API 종속성을 배포에 추가합니다. 기본적으로 true
인 add-logging-api-dependencies
특성을 사용하여 이러한 암시적 종속성이 배포에 추가되는지 여부를 제어할 수 있습니다.
관리 CLI를 사용하면 암시적 로깅 API 종속성이 배포에 추가되지 않도록 add-logging-api-dependencies
속성을 false
로 설정할 수 있습니다.
/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)
로깅
하위 시스템의 암시적 종속성에 대한 자세한 내용은 JBoss EAP 개발 가이드의 Implicit 모듈 종속성 섹션을 참조하십시오.
11.4. 로그 카테고리 구성
이 섹션에서는 관리 CLI를 사용하여 로그 범주를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 카테고리를 선택하여 관리 콘솔을 사용하여 로그 범주를 구성할 수도 있습니다 .
로그 범주를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 범주를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
로그 카테고리 추가
로그 카테고리 이름은 origin의 Java 패키지에 의해 정의됩니다. 해당 패키지의 클래스의 메시지는 다른 설정(예: 로그 수준)을 준수하는 한 캡처됩니다.
/subsystem=logging/logger=LOG_CATEGORY:add
로그 카테고리 설정 구성
요구 사항에 따라 다음 로그 카테고리 특성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 로그 카테고리 속성의 전체 목록 및 해당 설명은 Log Category Attributes 를 참조하십시오.
로그 수준을 설정합니다.
로그 범주에 적절한 로그 수준을 설정합니다. 기본값은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/logger=LOG_CATEGORY:write-attribute(name=level,value=LEVEL)
이 범주에서 루트 로거의 로그 핸들러를 사용해야 하는지 여부를 설정합니다.
기본적으로 로그 카테고리는 고유한 에 더하여 루트 로거의 핸들러를 사용합니다. 로그 범주에서 할당된 핸들러만 사용해야 하는 경우
use-parent-handlers
속성을false
로 설정합니다./subsystem=logging/logger=LOG_CATEGORY:write-attribute(name=use-parent-handlers,value=USE_PARENT_HANDLERS)
필터 표현식을 설정합니다.
로그 범주에 대한 로그 메시지를 필터링하기 위한 표현식을 설정합니다. 따옴표를 사용하여 쉼표와 따옴표를 이스케이프해야 합니다. 예를 들어 아래의
FILTER_EXPRESSION
교체 변수는not
로 교체해야 합니다.(match("WFLY")인 필터 표현식의 경우 "not(match(\"
WFLY\")")/subsystem=logging/logger=LOG_CATEGORY:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)
사용 가능한 필터 표현식 에 대한 자세한 내용은 필터 표현식 섹션을 참조하십시오.
핸들러 할당
로그 핸들러를 로그 범주에 할당합니다.
/subsystem=logging/logger=LOG_CATEGORY:add-handler(name=LOG_HANDLER_NAME)
로그 카테고리 제거
제거 작업을 사용하여 로그 범주를 제거할
수 있습니다.
/subsystem=logging/logger=LOG_CATEGORY:remove
11.5. 로그 핸들러 구성
로그 핸들러는 캡처된 로그 메시지가 기록되는 방법을 정의합니다. 필요한 로그 핸들러 유형을 구성하는 데 필요한 해당 섹션을 참조하십시오.
11.5.1. 콘솔 로그 핸들러 구성
이 섹션에서는 관리 CLI를 사용하여 콘솔 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 콘솔 핸들러를 선택하여 관리 콘솔을 사용하여 콘솔 로그 핸들러 를 구성할 수도 있습니다.
콘솔 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
콘솔 로그 핸들러 추가
/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:add
콘솔 로그 핸들러 설정 구성
요구 사항에 따라 다음 콘솔 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 콘솔 로그 핸들러 속성 및 해당 설명의 전체 목록은 Console Log Handler Attributes 를 참조하십시오.
로그 수준을 설정합니다.
핸들러에 적절한 로그 수준을 설정합니다. 기본값은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
대상을 설정합니다.
핸들러의 대상을 설정합니다. 이 핸들러는
System.out,
또는System.
errconsole 중 하나일 수 있습니다
. 기본값은System.out
입니다./subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=target,value=TARGET)
인코딩 설정.
핸들러의 인코딩을 설정합니다(예:
utf-8
)./subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
로그 포맷터를 설정합니다.
핸들러에 대해 formatter 문자열을 설정합니다. 예를 들어 기본 형식 문자열은
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n
입니다.FORMAT
값을 따옴표로 묶어야 합니다./subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
자동 플러시 설정.
각 쓰기 후에 자동으로 플러시 여부를 설정합니다. 기본값은
true
입니다./subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
필터 표현식을 설정합니다.
핸들러의 로그 메시지를 필터링하기 위한 표현식을 설정합니다. 따옴표를 사용하여 쉼표와 따옴표를 이스케이프해야 합니다. 예를 들어 아래의
FILTER_EXPRESSION
교체 변수는not
로 교체해야 합니다.(match("WFLY")인 필터 표현식의 경우 "not(match(\"
WFLY\")")/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)
사용 가능한 필터 표현식 에 대한 자세한 내용은 필터 표현식 섹션을 참조하십시오.
Console Log Handler를 Logger에 할당
로그 핸들러를 활성화하려면 로거에 할당해야 합니다.
다음 관리 CLI 명령은 콘솔 로그 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=CONSOLE_HANDLER_NAME)
다음 관리 CLI 명령은 콘솔 로그 핸들러를 CATEGORY
에서 지정한 로거에 할당합니다.
/subsystem=logging/logger=CATEGORY:add-handler(name=CONSOLE_HANDLER_NAME)
콘솔 로그 핸들러 제거
remove 작업을 사용하여 로그 핸들러를 제거할
수 있습니다. 현재 로거 또는 비동기 로그 핸들러에 할당된 경우 로그 핸들러를 제거할 수 없습니다.
/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:remove
11.5.2. 파일 로그 핸들러 구성
이 섹션에서는 관리 CLI를 사용하여 파일 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 파일 핸들러를 선택하여 관리 콘솔을 사용하여 파일 로그 핸들러 를 구성할 수도 있습니다.
파일 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
파일 로그 핸들러 추가
파일 로그 핸들러를 추가할 때 path 및 relative-to
특성으로 구성된 file 특성을 사용하여 파일
경로를
지정해야 합니다. path
속성을 사용하여 이름(예: my-log.log
)을 포함하여 로그의 파일 경로를 설정합니다. 선택적으로 relative-to
특성을 사용하여 경로가 명명된 경로
와 관련된지 설정합니다(예: jboss.server.log.dir
).
/subsystem=logging/file-handler=FILE_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH})
파일 로그 핸들러 설정 구성
요구 사항에 따라 다음 파일 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 파일 로그 핸들러 속성 및 해당 설명의 전체 목록은 File Log Handler Attributes 를 참조하십시오.
로그 수준을 설정합니다.
핸들러에 적절한 로그 수준을 설정합니다. 기본값은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
추가 동작을 설정합니다.
기본적으로 JBoss EAP는 서버를 다시 시작할 때 동일한 파일에 로그 메시지를 추가합니다. 서버 재시작 시 파일을 덮어쓰도록
append
속성을false로
설정할 수 있습니다./subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=append,value=APPEND)
인코딩 설정.
핸들러의 인코딩을 설정합니다(예:
utf-8
)./subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
로그 포맷터를 설정합니다.
핸들러에 대해 formatter 문자열을 설정합니다. 예를 들어 기본 형식 문자열은
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n
입니다.FORMAT
값을 따옴표로 묶어야 합니다./subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
자동 플러시 설정.
각 쓰기 후에 자동으로 플러시 여부를 설정합니다. 기본값은
true
입니다./subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
필터 표현식을 설정합니다.
핸들러의 로그 메시지를 필터링하기 위한 표현식을 설정합니다. 따옴표를 사용하여 쉼표와 따옴표를 이스케이프해야 합니다. 예를 들어 아래의
FILTER_EXPRESSION
교체 변수는not
로 교체해야 합니다.(match("WFLY")인 필터 표현식의 경우 "not(match(\"
WFLY\")")/subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)
사용 가능한 필터 표현식 에 대한 자세한 내용은 필터 표현식 섹션을 참조하십시오.
파일 로그 핸들러 할당
로그 핸들러를 활성화하려면 로거에 할당해야 합니다.
다음 관리 CLI 명령은 파일 로그 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=FILE_HANDLER_NAME)
다음 관리 CLI 명령은 파일 로그 핸들러를 CATEGORY
에서 지정한 로거에 할당합니다.
/subsystem=logging/logger=CATEGORY:add-handler(name=FILE_HANDLER_NAME)
파일 로그 핸들러 제거
remove 작업을 사용하여 로그 핸들러를 제거할
수 있습니다. 현재 로거 또는 비동기 로그 핸들러에 할당된 경우 로그 핸들러를 제거할 수 없습니다.
/subsystem=logging/file-handler=FILE_HANDLER_NAME:remove
11.5.3. 주기적인 순환 로그 핸들러 구성
이 섹션에서는 관리 CLI를 사용하여 주기적인 회전 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 주기적인 핸들러를 선택하여 관리 콘솔을 사용하여 주기적인 로그 핸들러 를 구성할 수도 있습니다.
정기적인 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
주기적인 로그 핸들러 추가
정기적인 로그 핸들러를 추가할 때 path 및 relative-to
특성으로 구성된 file 특성을 사용하여 파일
경로를
지정해야 합니다. path
속성을 사용하여 이름(예: my-log.log
)을 포함하여 로그의 파일 경로를 설정합니다. 선택적으로 relative-to
특성을 사용하여 경로가 명명된 경로
와 관련된지 설정합니다(예: jboss.server.log.dir
).
또한 접미사 특성을 사용하여 순환된 로그의 접미사
를 설정해야 합니다. java.text.SimpleDateFormat(예:.
yyy -MM-dd-HH
)에서 이해할 수 있는 형식이어야 합니다. 순환 기간은 이 접미사에 따라 자동으로 계산됩니다.
/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH},suffix=SUFFIX)
주기적인 로그 처리기 설정 구성
요구 사항에 따라 다음 정기적인 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 정규 로그 핸들러 속성 및 해당 설명의 전체 목록은 주기적 로그 핸들러 속성에서 참조하십시오.
로그 수준을 설정합니다.
핸들러에 적절한 로그 수준을 설정합니다. 기본값은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
추가 동작을 설정합니다.
기본적으로 JBoss EAP는 서버를 다시 시작할 때 동일한 파일에 로그 메시지를 추가합니다. 서버 재시작 시 파일을 덮어쓰도록
append
속성을false로
설정할 수 있습니다./subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=append,value=APPEND)
인코딩 설정.
핸들러의 인코딩을 설정합니다(예:
utf-8
)./subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
로그 포맷터를 설정합니다.
핸들러에 대해 formatter 문자열을 설정합니다. 예를 들어 기본 형식 문자열은
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n
입니다.FORMAT
값을 따옴표로 묶어야 합니다./subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
자동 플러시 설정.
각 쓰기 후에 자동으로 플러시 여부를 설정합니다. 기본값은
true
입니다./subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
필터 표현식을 설정합니다.
핸들러의 로그 메시지를 필터링하기 위한 표현식을 설정합니다. 따옴표를 사용하여 쉼표와 따옴표를 이스케이프해야 합니다. 예를 들어 아래의
FILTER_EXPRESSION
교체 변수는not
로 교체해야 합니다.(match("WFLY")인 필터 표현식의 경우 "not(match(\"
WFLY\")")/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)
사용 가능한 필터 표현식 에 대한 자세한 내용은 필터 표현식 섹션을 참조하십시오.
Logger에 주기적 로그 핸들러 할당
로그 핸들러를 활성화하려면 로거에 할당해야 합니다.
다음 관리 CLI 명령은 정기적인 로그 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=PERIODIC_HANDLER_NAME)
다음 관리 CLI 명령은 주기적 로그 핸들러를 CATEGORY
에서 지정한 로거에 할당합니다.
/subsystem=logging/logger=CATEGORY:add-handler(name=PERIODIC_HANDLER_NAME)
주기적인 로그 처리기 제거
remove 작업을 사용하여 로그 핸들러를 제거할
수 있습니다. 현재 로거 또는 비동기 로그 핸들러에 할당된 경우 로그 핸들러를 제거할 수 없습니다.
/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:remove
11.5.4. 크기 회전 로그 핸들러 구성
이 섹션에서는 관리 CLI를 사용하여 크기 회전 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 크기 핸들러를 선택하여 관리 콘솔을 사용하여 크기 로그 핸들러 를 구성할 수도 있습니다.
크기 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
크기 로그 핸들러 추가
크기 로그 핸들러를 추가할 때 path 및 relative-to
특성으로 구성된 file 특성을 사용하여 파일
경로를
지정해야 합니다. path
속성을 사용하여 이름(예: my-log.log
)을 포함하여 로그의 파일 경로를 설정합니다. 선택적으로 relative-to
특성을 사용하여 경로가 명명된 경로
와 관련된지 설정합니다(예: jboss.server.log.dir
).
/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH})
크기 로그 처리기 설정 구성
요구 사항에 따라 다음 크기 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 크기 로그 핸들러 속성 및 해당 설명의 전체 목록은 Size Log Handler Attributes 를 참조하십시오.
로그 수준을 설정합니다.
핸들러에 적절한 로그 수준을 설정합니다. 기본값은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
순환된 로그의 접미사를 설정합니다.
java.text.SimpleDateFormat
에서 이해할 수 있는 형식인 접미사 문자열을 설정합니다(예:.yyy-MM-dd-HH
). 순환 기간은 이 접미사에 따라 자동으로 계산됩니다./subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=suffix, value=SUFFIX)
회전 크기를 설정합니다.
순환하기 전에 파일에 도달할 수 있는 최대 크기를 설정합니다. 기본값은
2메가바이트의 경우 2m
입니다./subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=rotate-size, value=ROTATE_SIZE)
유지할 최대 백업 로그 수를 설정합니다.
유지할 백업 수를 설정합니다. 기본값은
1
입니다./subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=max-backup-index, value=MAX_BACKUPS)
부팅 시 로그를 회전할지 여부를 설정합니다.
기본적으로 서버를 다시 시작할 때 새 로그 파일이 생성되지 않습니다. 서버를 다시 시작할 때 로그를 회전하려면 이 값을
true
로 설정할 수 있습니다./subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=rotate-on-boot, value=ROTATE_ON_BOOT)
추가 동작을 설정합니다.
기본적으로 JBoss EAP는 서버를 다시 시작할 때 동일한 파일에 로그 메시지를 추가합니다. 서버 재시작 시 파일을 덮어쓰도록
append
속성을false로
설정할 수 있습니다./subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=append,value=APPEND)
인코딩 설정.
핸들러의 인코딩을 설정합니다(예:
utf-8
)./subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
로그 포맷터를 설정합니다.
핸들러에 대해 formatter 문자열을 설정합니다. 예를 들어 기본 형식 문자열은
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n
입니다.FORMAT
값을 따옴표로 묶어야 합니다./subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
자동 플러시 설정.
각 쓰기 후에 자동으로 플러시 여부를 설정합니다. 기본값은
true
입니다./subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
필터 표현식을 설정합니다.
핸들러의 로그 메시지를 필터링하기 위한 표현식을 설정합니다. 따옴표를 사용하여 쉼표와 따옴표를 이스케이프해야 합니다. 예를 들어 아래의
FILTER_EXPRESSION
교체 변수는not
로 교체해야 합니다.(match("WFLY")인 필터 표현식의 경우 "not(match(\"
WFLY\")")/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)
사용 가능한 필터 표현식 에 대한 자세한 내용은 필터 표현식 섹션을 참조하십시오.
Logger에 크기 로그 핸들러 할당
로그 핸들러를 활성화하려면 로거에 할당해야 합니다.
다음 관리 CLI 명령은 size 로그 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=SIZE_HANDLER_NAME)
다음 관리 CLI 명령은 CATEGORY
에서 지정한 로거에 크기 로그 핸들러를 할당합니다.
/subsystem=logging/logger=CATEGORY:add-handler(name=SIZE_HANDLER_NAME)
크기 로그 핸들러 제거
remove 작업을 사용하여 로그 핸들러를 제거할
수 있습니다. 현재 로거 또는 비동기 로그 핸들러에 할당된 경우 로그 핸들러를 제거할 수 없습니다.
/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:remove
11.5.5. 주기적인 크기 회전 로그 핸들러 구성
이 섹션에서는 관리 CLI를 사용하여 주기적인 크기 회전 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 주기적인 크기 핸들러를 선택하여 관리 콘솔을 사용하여 주기적인 크기 로그 핸들러 를 구성할 수도 있습니다.
정기적인 크기 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
주기적인 크기 로그 핸들러 추가
주기적인 크기 로그 핸들러를 추가할 때 경로 및 relative-to
특성으로 구성된 file 특성을 사용하여 파일
경로를
지정해야 합니다. path
속성을 사용하여 이름(예: my-log.log
)을 포함하여 로그의 파일 경로를 설정합니다. 선택적으로 relative-to
특성을 사용하여 경로가 명명된 경로
와 관련된지 설정합니다(예: jboss.server.log.dir
).
또한 접미사 특성을 사용하여 순환된 로그의 접미사
를 설정해야 합니다. java.text.SimpleDateFormat(예:.
yyy -MM-dd-HH
)에서 이해할 수 있는 형식이어야 합니다. 순환 기간은 이 접미사에 따라 자동으로 계산됩니다.
/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH},suffix=SUFFIX)
주기적인 크기 로그 핸들러 설정 구성
요구 사항에 따라 다음 정기적인 크기 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 정규 크기 로그 핸들러 속성 및 해당 설명의 전체 목록은 periodicic Size Log Handler Attributes 를 참조하십시오.
로그 수준을 설정합니다.
핸들러에 적절한 로그 수준을 설정합니다. 기본값은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
회전 크기를 설정합니다.
순환하기 전에 파일에 도달할 수 있는 최대 크기를 설정합니다. 기본값은
2메가바이트의 경우 2m
입니다./subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=rotate-size, value=ROTATE_SIZE)
유지할 최대 백업 로그 수를 설정합니다.
유지할 백업 수를 설정합니다. 기본값은
1
입니다./subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=max-backup-index, value=MAX_BACKUPS)
부팅 시 로그를 회전할지 여부를 설정합니다.
기본적으로 서버를 다시 시작할 때 새 로그 파일이 생성되지 않습니다. 서버를 다시 시작할 때 로그를 회전하려면 이 값을
true
로 설정할 수 있습니다./subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=rotate-on-boot, value=ROTATE_ON_BOOT)
추가 동작을 설정합니다.
기본적으로 JBoss EAP는 서버를 다시 시작할 때 동일한 파일에 로그 메시지를 추가합니다. 서버 재시작 시 파일을 덮어쓰도록
append
속성을false로
설정할 수 있습니다./subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=append,value=APPEND)
인코딩 설정.
핸들러의 인코딩을 설정합니다(예:
utf-8
)./subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
로그 포맷터를 설정합니다.
핸들러에 대해 formatter 문자열을 설정합니다. 예를 들어 기본 형식 문자열은
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n
입니다.FORMAT
값을 따옴표로 묶어야 합니다./subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
자동 플러시 설정.
각 쓰기 후에 자동으로 플러시 여부를 설정합니다. 기본값은
true
입니다./subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
필터 표현식을 설정합니다.
핸들러의 로그 메시지를 필터링하기 위한 표현식을 설정합니다. 따옴표를 사용하여 쉼표와 따옴표를 이스케이프해야 합니다. 예를 들어 아래의
FILTER_EXPRESSION
교체 변수는not
로 교체해야 합니다.(match("WFLY")인 필터 표현식의 경우 "not(match(\"
WFLY\")")/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)
사용 가능한 필터 표현식 에 대한 자세한 내용은 필터 표현식 섹션을 참조하십시오.
Logger에 주기적인 크기 로그 핸들러 할당
로그 핸들러를 활성화하려면 로거에 할당해야 합니다.
다음 관리 CLI 명령은 주기적인 크기 로그 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=PERIODIC_SIZE_HANDLER_NAME)
다음 관리 CLI 명령은 주기적인 크기 로그 핸들러를 CATEGORY
에서 지정한 로거에 할당합니다.
/subsystem=logging/logger=CATEGORY:add-handler(name=PERIODIC_SIZE_HANDLER_NAME)
주기적인 크기 로그 핸들러 제거
remove 작업을 사용하여 로그 핸들러를 제거할
수 있습니다. 현재 로거 또는 비동기 로그 핸들러에 할당된 경우 로그 핸들러를 제거할 수 없습니다.
/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:remove
11.5.6. Syslog 핸들러 구성
이 섹션에서는 관리 CLI를 사용하여 syslog 핸들러를 구성하는 방법을 보여줍니다. 이 CLI는 Syslog 프로토콜(RF-3164 또는 RFC-5424)을 지원하는 원격 로깅 서버로 메시지를 보내는 데 사용할 수 있습니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → Syslog 핸들러를 선택하여 관리 콘솔을 사용하여 syslog 핸들러 를 구성할 수도 있습니다.
syslog 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
Syslog 핸들러 추가
/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:add
Syslog 핸들러 설정 구성
요구 사항에 따라 다음 syslog 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 syslog 핸들러 속성 및 해당 설명의 전체 목록은 Syslog Handler 속성에서 참조하십시오.
핸들러의 로그 수준을 설정합니다. 기본 수준은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
로깅 중인 애플리케이션의 이름을 설정합니다. 기본 이름은
java
입니다./subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=app-name,value=APP_NAME)
syslog 서버의 주소를 설정합니다. 기본 주소는
localhost
입니다./subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=server-address,value=SERVER_ADDRESS)
syslog 서버의 포트를 설정합니다. 기본 포트는
514
입니다./subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=port,value=PORT)
RFC 사양에 정의된 대로 syslog 형식을 설정합니다. 기본 형식은
RFC5424
입니다./subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=syslog-format,value=SYSLOG_FORMAT)
syslog 페이로드의 메시지를 포맷하려면
named-formatter
속성을 지정합니다./subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=named-formatter, value=FORMATTER_NAME)
Syslog 핸들러를 Logger에 할당
로그 핸들러를 활성화하려면 로거에 할당해야 합니다.
다음 관리 CLI 명령은 syslog 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=SYSLOG_HANDLER_NAME)
다음 관리 CLI 명령은 CATEGORY
에서 지정한 로거에 syslog 핸들러를 할당합니다.
/subsystem=logging/logger=CATEGORY:add-handler(name=SYSLOG_HANDLER_NAME)
Syslog 핸들러 제거
remove 작업을 사용하여 로그 핸들러를 제거할
수 있습니다. 현재 로거 또는 비동기 로그 핸들러에 할당된 경우 로그 핸들러를 제거할 수 없습니다.
/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:remove
11.5.7. 소켓 로그 핸들러 구성
이 섹션에서는 소켓에서 메시지를 보내는 데 사용할 수 있는 관리 CLI를 사용하여 소켓 로그 핸들러를 구성하는 방법을 보여줍니다. TCP 또는 UDP 소켓일 수 있습니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 소켓 핸들러를 선택하여 관리 콘솔을 사용하여 소켓 로그 핸들러 를 구성할 수도 있습니다.
서버가 admin-only 모드에서 시작되면 로그 메시지가 삭제됩니다.
소켓 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
소켓 바인딩 추가
remote-destination-outbound-socket-binding
또는 local-destination-outbound-socket-binding
을 사용할 소켓 바인딩 으로 정의합니다.
/socket-binding-group=SOCKET_BINDING_GROUP/remote-destination-outbound-socket-binding=SOCKET_BINDING_NAME:add(host=HOST, port=PORT)
로그 포맷터 추가
사용할 로그 포맷 터(예: JSON formatter)를 정의합니다.
/subsystem=logging/json-formatter=FORMATTER:add
소켓 로그 핸들러 추가
socket 로그 핸들러를 추가할 때 사용할 소켓 바인딩 및 포맷터를 지정해야 합니다.
/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:add(outbound-socket-binding-ref=SOCKET_BINDING_NAME,named-formatter=FORMATTER)
소켓 로그 핸들러 설정 구성
요구 사항에 따라 다음 소켓 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 소켓 로그 핸들러 속성 및 해당 설명의 전체 목록은 Socket Log Handler Attributes 를 참조하십시오.
프로토콜을 설정합니다.
사용할 프로토콜을 설정합니다. 기본값은
TCP
입니다./subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=protocol,value=PROTOCOL)
로그 수준을 설정합니다.
핸들러에 적절한 로그 수준을 설정합니다. 기본값은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
참고서버를 시작하는 동안 소켓 로그 핸들러에서 처리하는 로그 메시지는 소켓 바인딩이 구성되고
로깅
하위 시스템이 초기화될 때까지 큐에 추가됩니다. 로그 수준이TRACE
또는DEBUG
와 같은 낮은 수준으로 설정된 경우 시작하는 동안 메모리 사용량이 커질 수 있습니다.인코딩 설정.
핸들러의 인코딩을 설정합니다(예:
utf-8
)./subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
자동 플러시 설정.
각 쓰기 후에 자동으로 플러시 여부를 설정합니다. 기본값은
true
입니다./subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
필터 표현식을 설정합니다.
핸들러의 로그 메시지를 필터링하기 위한 표현식을 설정합니다. 따옴표를 사용하여 쉼표와 따옴표를 이스케이프해야 합니다. 예를 들어 아래의
FILTER_EXPRESSION
교체 변수는not
로 교체해야 합니다.(match("WFLY")인 필터 표현식의 경우 "not(match(\"
WFLY\")")/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)
사용 가능한 필터 표현식 에 대한 자세한 내용은 필터 표현식 섹션을 참조하십시오.
소켓 로그 핸들러를 로거에 할당
로그 핸들러를 활성화하려면 로거에 할당해야 합니다.
다음 관리 CLI 명령은 socket 로그 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=SOCKET_HANDLER_NAME)
다음 관리 CLI 명령은 소켓 로그 핸들러를 CATEGORY
에서 지정한 로거에 할당합니다.
/subsystem=logging/logger=CATEGORY:add-handler(name=SOCKET_HANDLER_NAME)
소켓 로그 핸들러 제거
remove 작업을 사용하여 로그 핸들러를 제거할
수 있습니다. 현재 로거 또는 비동기 로그 핸들러에 할당된 경우 로그 핸들러를 제거할 수 없습니다.
/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:remove
SSL/TLS를 사용하여 소켓에서 로그 메시지 전송
다음 단계에서는 SSL_TCP
프로토콜을 사용하여 소켓에 로그 메시지를 보내도록 소켓 로그 핸들러를 설정하는 방법의 예를 보여줍니다. 이 예제에서는 소켓 로그 핸들러에서 사용할 elytron
하위 시스템에서 키 저장소, 신뢰 관리자 및 클라이언트 SSL 컨텍스트를 구성합니다. 루트 로거의 로그 메시지는 JSON 포맷자에 의해 포맷된 지정된 소켓을 통해 전송됩니다.
Elytron 구성 요소 구성에 대한 자세한 내용은 JBoss EAP의 서버 보안 구성 방법에서 Elytron 하위 시스템을 참조하십시오.
Elytron 설정을 구성합니다.
키 저장소를 추가합니다.
/subsystem=elytron/key-store=log-server-ks:add(path=/path/to/keystore.jks, type=JKS, credential-reference={clear-text=mypassword})
신뢰 관리자를 추가합니다.
/subsystem=elytron/trust-manager=log-server-tm:add(key-store=log-server-ks)
클라이언트 SSL 컨텍스트를 추가합니다.
/subsystem=elytron/client-ssl-context=log-server-context:add(trust-manager=log-server-tm, protocols=["TLSv1.2"])
소켓 바인딩을 추가합니다.
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=log-server:add(host=localhost, port=4560)
JSON 포맷터를 추가합니다.
/subsystem=logging/json-formatter=json:add
소켓 로그 핸들러를 추가합니다.
/subsystem=logging/socket-handler=log-server-handler:add(named-formatter=json, level=INFO, outbound-socket-binding-ref=log-server, protocol=SSL_TCP, ssl-context=log-server-context)
로그 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=log-server-handler)
11.5.8. 사용자 정의 로그 핸들러 구성
이 섹션에서는 관리 CLI를 사용하여 사용자 지정 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 사용자 정의 핸들러를 선택하여 관리 콘솔을 사용하여 사용자 정의 로그 핸들러 를 구성할 수도 있습니다.
사용자 정의 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
사용자 정의 로그 핸들러 추가
사용자 지정 로그 핸들러를 추가할 때 핸들러의 Java 클래스와 포함된 JBoss EAP 모듈을 지정해야 합니다. 클래스는 java.util.logging.Handler
를 확장해야 합니다.
사용자 지정 로거 를 포함하는 모듈을 이미 생성 했거나 이 명령이 실패합니다.
/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:add(class=CLASS_NAME,module=MODULE_NAME)
사용자 지정 로그 핸들러 설정 구성
요구 사항에 따라 다음 사용자 지정 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 사용자 지정 로그 핸들러 속성 및 해당 설명의 전체 목록은 Custom Log Handler Attributes 를 참조하십시오.
로그 수준을 설정합니다.
핸들러에 적절한 로그 수준을 설정합니다. 기본값은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
속성을 설정합니다.
로그 핸들러에 필요한 속성을 설정합니다. 속성은 setter 메서드를 사용하여 액세스할 수 있어야 합니다.
/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=properties.PROPERTY_NAME,value=PROPERTY_VALUE)
인코딩 설정.
핸들러의 인코딩을 설정합니다(예:
utf-8
)./subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
로그 포맷터를 설정합니다.
핸들러에 대해 formatter 문자열을 설정합니다. 예를 들어 기본 형식 문자열은
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n
입니다.FORMAT
값을 따옴표로 묶어야 합니다./subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
필터 표현식을 설정합니다.
핸들러의 로그 메시지를 필터링하기 위한 표현식을 설정합니다. 따옴표를 사용하여 쉼표와 따옴표를 이스케이프해야 합니다. 예를 들어 아래의
FILTER_EXPRESSION
교체 변수는not
로 교체해야 합니다.(match("WFLY")인 필터 표현식의 경우 "not(match(\"
WFLY\")")/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)
사용 가능한 필터 표현식 에 대한 자세한 내용은 필터 표현식 섹션을 참조하십시오.
사용자 정의 로그 핸들러 할당
로그 핸들러를 활성화하려면 로거에 할당해야 합니다.
다음 관리 CLI 명령은 사용자 지정 로그 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=CUSTOM_HANDLER_NAME)
다음 관리 CLI 명령은 사용자 지정 로그 핸들러를 CATEGORY
에서 지정한 로거에 할당합니다.
/subsystem=logging/logger=CATEGORY:add-handler(name=CUSTOM_HANDLER_NAME)
사용자 정의 로그 핸들러 제거
remove 작업을 사용하여 로그 핸들러를 제거할
수 있습니다. 현재 로거 또는 비동기 로그 핸들러에 할당된 경우 로그 핸들러를 제거할 수 없습니다.
/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:remove
11.5.9. Async 로그 핸들러 구성
이 섹션에서는 관리 CLI를 사용하여 비동기 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → Async 핸들러를 선택하여 관리 콘솔을 사용하여 비동기 로그 핸들러 를 구성할 수도 있습니다.
비동기 로그 핸들러를 구성하는 데 수행하는 기본 작업은 다음과 같습니다.
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
Async 로그 핸들러 추가
비동기 로그 핸들러를 추가할 때 큐 길이를 지정해야 합니다. 대기열에서 보유할 수 있는 최대 로그 요청 수입니다.
/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:add(queue-length=QUEUE_LENGTH)
하위 핸들러 추가
하나 이상의 핸들러를 이 비동기 로그 핸들러의 하위 핸들러로 추가할 수 있습니다. 핸들러가 이미 구성에 있어야 합니다. 그렇지 않으면 이 명령이 실패합니다.
/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:add-handler(name=HANDLER_NAME)
Async 로그 핸들러 설정 구성
요구 사항에 따라 다음 async 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 비동기 로그 핸들러 속성 및 해당 설명의 전체 목록은 Async Log Handler 속성에서 참조하십시오.
로그 수준을 설정합니다.
핸들러에 적절한 로그 수준을 설정합니다. 기본값은
ALL
입니다. 사용 가능한 모든 옵션은 로그 수준을 참조하십시오./subsystem=logging/async-handler=ASYNC_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
오버플로 작업을 설정합니다.
오버플로 시 수행할 작업을 설정합니다. 기본값은
BLOCK
(차단)입니다. 즉, 스레드가 전체 대기열에 있을 때 차단됩니다. 이 값을DISCARD
(취소)로 변경할 수 있습니다. 즉, 전체 대기열이 있는 경우 로그 메시지가 삭제됩니다./subsystem=logging/async-handler=ASYNC_HANDLER_NAME:write-attribute(name=overflow-action,value=OVERFLOW_ACTION)
필터 표현식을 설정합니다.
핸들러의 로그 메시지를 필터링하기 위한 표현식을 설정합니다. 따옴표를 사용하여 쉼표와 따옴표를 이스케이프해야 합니다. 예를 들어 아래의
FILTER_EXPRESSION
교체 변수는not
로 교체해야 합니다.(match("WFLY")인 필터 표현식의 경우 "not(match(\"
WFLY\")")/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)
사용 가능한 필터 표현식 에 대한 자세한 내용은 필터 표현식 섹션을 참조하십시오.
Async 로그 핸들러를 Logger에 할당
로그 핸들러를 활성화하려면 로거에 할당해야 합니다.
다음 관리 CLI 명령은 async 로그 핸들러를 루트 로거에 할당합니다.
/subsystem=logging/root-logger=ROOT:add-handler(name=ASYNC_HANDLER_NAME)
다음 관리 CLI 명령은 async 로그 핸들러를 CATEGORY
에서 지정한 로거에 할당합니다.
/subsystem=logging/logger=CATEGORY:add-handler(name=ASYNC_HANDLER_NAME)
Async 로그 핸들러 제거
remove 작업을 사용하여 로그 핸들러를 제거할
수 있습니다. 현재 로거에 할당된 로그 핸들러는 제거할 수 없습니다.
/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:remove
11.6. 루트 로거 구성
루트 로거는 지정된 로그 수준 이상의 모든 로그 메시지를 캡처하여 로그 범주에서 캡처하지 않은 서버로 전송합니다.
이 섹션에서는 관리 CLI를 사용하여 루트 로거를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 루트 로거를 선택하여 관리 콘솔을 사용하여 루트 로거 를 구성할 수도 있습니다.
루트 로거 구성
로깅 프로필에 대해 이 로그 핸들러를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
로그 핸들러를 루트 로거에 할당합니다.
로그 핸들러 추가.
/subsystem=logging/root-logger=ROOT:add-handler(name=LOG_HANDLER_NAME)
로그 핸들러 제거.
/subsystem=logging/root-logger=ROOT:remove-handler(name=LOG_HANDLER_NAME)
로그 수준을 설정합니다.
/subsystem=logging/root-logger=ROOT:write-attribute(name=level,value=LEVEL)
사용 가능한 루트 로거 속성의 전체 목록과 해당 설명은 Root Logger Attributes 를 참조하십시오.
11.7. 로그 포맷터 구성
로그 포맷터는 해당 핸들러의 로그 메시지의 표시를 정의합니다. 로깅
하위 시스템을 사용하면 다음 유형의 로그 포맷터를 구성할 수 있습니다.
11.7.1. 패턴 포맷터 설정
로그 핸들러에서 로그 메시지를 포맷하기 위해 사용할 수 있는 명명된 패턴 포맷터를 생성할 수 있습니다.
로깅 프로필에 대해 이 로그 포맷터를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
패턴 포맷터 만들기
패턴 포맷터를 정의할 때 로그 메시지를 포맷하는 데 사용할 패턴 문자열을 제공합니다. 패턴 구문에 대한 자세한 내용은 패턴 형식 형식 문자를 참조하십시오.
/subsystem=logging/pattern-formatter=PATTERN_FORMATTER_NAME:add(pattern=PATTERN)
예를 들어 기본 구성에서는 서버 로그에 메시지를 기록하는 데 다음 로그 포맷터 문자열을 사용합니다. %d{yyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n
. 이렇게 하면 아래와 같이 포맷된 로그 메시지가 생성됩니다.
2016-03-18 15:49:32,075 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
색상 맵을 정의하여 다른 로그 수준에 컬러를 할당할 수도 있습니다. 형식은 쉼표로 구분된 LEVEL:COLOR
목록입니다.
-
유효한 수준:
shell
,fine
,,
fineconfig
,trace
,debug
,info
,warning
,warn
,error
,fatal
,severe
-
유효한 색상:
블랙
,녹색
,빨간색
,노란색
,파란색
, magenta,
cyan
,화이트
, Brightblack
, Brightred
, Brightgreen
, Brightblue
, Brightyellow
, Brightmagenta
,Brightcyan
,Brightwhite
/subsystem=logging/pattern-formatter=PATTERN_FORMATTER_NAME:write-attribute(name=color-map,value="LEVEL:COLOR,LEVEL:COLOR")
관리 콘솔을 사용하여 패턴 로그 포맷터를 구성할 수도 있습니다.
- 브라우저에서 관리 콘솔을 엽니다.
- 구성 → 하위 시스템 → 로깅 을 선택합니다.
- Configuration(구성) 을 선택한 다음 View(보기 )를 클릭합니다.
- Formatter를 선택한 다음 Pattern Formatter(패턴 형식) 옵션을 선택합니다.
11.7.2. JSON 로그 포맷터 구성
JSON 로그 포맷터를 생성하여 JSON에서 로그 메시지를 포맷할 수 있습니다.
로깅 프로필에 대해 이 로그 포맷터를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
JSON 로그 포맷터 추가
/subsystem=logging/json-formatter=JSON_FORMATTER_NAME:add(pretty-print=true, exception-output-type=formatted)
이렇게 하면 아래와 같이 포맷된 로그 메시지가 생성됩니다.
{ "timestamp": "2018-10-18T13:53:43.031-04:00", "sequence": 62, "loggerClassName": "org.jboss.as.server.logging.ServerLogger_$logger", "loggerName": "org.jboss.as", "level": "INFO", "message": "WFLYSRV0025: JBoss EAP 7.4.0.GA (WildFly Core 15.0.2.Final-redhat-00001) started in 5227ms - Started 317 of 556 services (343 services are lazy, passive or on-demand), "threadName": "Controller Boot Thread", "threadId": 22, "mdc": { }, "ndc": "", "hostName": "localhost.localdomain", "processName": "jboss-modules.jar", "processId": 7461 }
Logstash JSON 로그 포맷터 추가
JSON 로그 포맷터 출력 키를 수정하고 정적 메타데이터를 추가할 수 있습니다. JSON 로그 포맷터의 주요 용도는 JSON에서 로그 메시지를 포맷하는 것입니다. Logstash는 이 JSON 출력을 사용하고 @timestamp
및 @version
필드를 검색합니다. 다음 예제에서는 Logstash에 대한 메시지를 포맷하는 JSON 로그 포맷터를 생성합니다.
/subsystem=logging/json-formatter=logstash:add(exception-output-type=formatted, key-overrides=[timestamp="@timestamp"], meta-data=[@version=1])
아래에 설명된 JSON formatter 속성을 사용할 수 있습니다.
-
key-overrides
특성을 사용하여 정의된 키 이름을 재정의할 수 있습니다. -
예외는
exception-output-type
특성을 포맷으로 설정하여 오브젝트로포맷
할 수 있습니다. -
exception
-output-type 특성을 detailed로 설정하여 예외
스택 추적을 포함할 수 있습니다.
-
예외는
exception-output-type을 details-
로 설정하여 오브젝트 및 스택 추적으로 포맷할 수 있습니다.and-
formatted -
meta-data
특성을 사용하여 메타데이터를 로그 레코드에 추가할 수 있습니다.
JSON 포맷터 속성에 대한 자세한 내용은 JSON 로그 포맷터 속성 에서 참조하십시오.
관리 콘솔을 사용하여 JSON 로그 포맷터를 구성할 수도 있습니다.
- 브라우저에서 관리 콘솔을 엽니다.
- 구성 → 하위 시스템 → 로깅 을 선택합니다.
- Configuration(구성) 을 선택한 다음 View(보기 )를 클릭합니다.
- Formatter를 선택한 다음 JSON Formatter 옵션을 선택합니다.
11.7.3. XML 로그 포맷터 구성
XML 로그 포맷터를 생성하여 XML로 로그 메시지를 포맷할 수 있습니다.
로깅 프로필에 대해 이 로그 포맷터를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
XML 로그 포맷터 추가
/subsystem=logging/xml-formatter=XML_FORMATTER_NAME:add(pretty-print=true, exception-output-type=detailed-and-formatted)
이렇게 하면 아래와 같이 로그 메시지가 생성됩니다.
<record> <timestamp>2018-10-18T13:55:53.419-04:00</timestamp> <sequence>62</sequence> <loggerClassName>org.jboss.as.server.logging.ServerLogger_$logger</loggerClassName> <loggerName>org.jboss.as</loggerName> <level>INFO</level> <message>WFLYSRV0025: {ProductCurrentVersionExamples} (WildFly Core 10.0.0.Final-redhat-20190924) started in 6271ms - Started 495 of 679 services (331 services are lazy, passive or on-demand)</message> <threadName>Controller Boot Thread</threadName> <threadId>22</threadId> <mdc> </mdc> <ndc></ndc> <hostName>localhost.localdomain</hostName> <processName>jboss-modules.jar</processName> <processId>7790</processId> </record>
키 재정의 XML 로그 포맷 추가
/subsystem=logging/xml-formatter=XML_FORMATTER_NAME:add(pretty-print=true, print-namespace=true, namespace-uri="urn:custom:1.0", key-overrides={message=msg, record=logRecord, timestamp=date}, print-details=true)
아래 설명된 XML formatter 속성을 사용할 수 있습니다.
-
key-overrides
특성을 사용하여 정의된 키 이름을 재정의할 수 있습니다. -
예외는
exception-output-type
특성을 포맷으로 설정하여 오브젝트로포맷
할 수 있습니다. -
exception
-output-type 특성을 detailed로 설정하여 예외
스택 추적을 포함할 수 있습니다.
-
예외는
exception-output-type을 details-
로 설정하여 오브젝트 및 스택 추적으로 포맷할 수 있습니다.and-
formatted -
meta-data
특성을 사용하여 메타데이터를 로그 레코드에 추가할 수 있습니다.
XML formatter 속성에 대한 자세한 내용은 XML Log Formatter Attributes 를 참조하십시오.
관리 콘솔을 사용하여 XML 로그 포맷터를 구성할 수도 있습니다.
- 브라우저에서 관리 콘솔을 엽니다.
- 구성 → 하위 시스템 → 로깅 을 선택합니다.
- Configuration(구성) 을 선택한 다음 View(보기 )를 클릭합니다.
- Formatter를 선택한 다음 XML Formatter 옵션을 선택합니다.
11.7.4. 사용자 정의 로그 포맷터 구성
로그 핸들러에서 로그 메시지를 포맷하기 위해 사용할 수 있는 사용자 지정 로그 포맷터를 생성할 수 있습니다.
이 섹션에서는 관리 CLI를 사용하여 사용자 지정 로그 포맷터를 구성하는 방법을 보여줍니다.
사용자 정의 로그 포맷터 구성
로깅 프로필에 대해 이 로그 포맷터를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 /
subsystem=logging/
입니다.
또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가합니다.
사용자 지정 로그 포맷터를 추가합니다.
사용자 정의 로그 포맷터를 추가할 때 formatter 및 여기에 포함된 JBoss EAP 모듈을 Java 클래스로 지정해야 합니다. 클래스는
java.util.logging.Formatter를
확장해야 합니다.참고사용자 지정 formatter가 포함된 모듈을 이미 생성했으므로 이 명령이 실패합니다.
/subsystem=logging/custom-formatter=CUSTOM_FORMATTER_NAME:add(class=CLASS_NAME, module=MODULE_NAME)
로그 포맷터에 필요한 속성을 설정합니다.
속성은 setter 메서드를 사용하여 액세스할 수 있어야 합니다.
/subsystem=logging/custom-formatter=CUSTOM_FORMATTER_NAME:write-attribute(name=properties.PROPERTY_NAME,value=PROPERTY_VALUE)
사용자 지정 포맷터를 로그 핸들러에 할당합니다.
다음 관리 CLI 명령은 주기적인 회전 파일 핸들러에서 사용할 사용자 지정 포맷터를 할당합니다.
/subsystem=logging/periodic-rotating-file-handler=FILE_HANDLER_NAME:write-attribute(name=named-formatter, value=CUSTOM_FORMATTER_NAME)
사용자 지정 XML Formatter 예
다음 예제에서는 사용자 지정 XML 포맷터를 구성합니다. org.jboss
클래스를 사용하여 콘솔 로그 핸들러에 할당합니다.
.logmanager 모듈에 제공된 java.util.logging.
XMLFormatter
/subsystem=logging/custom-formatter=custom-xml-formatter:add(class=java.util.logging.XMLFormatter, module=org.jboss.logmanager) /subsystem=logging/console-handler=CONSOLE:write-attribute(name=named-formatter, value=custom-xml-formatter)
이 포맷터를 사용하는 로그 메시지는 다음과 같이 포맷됩니다.
<record> <date>2016-03-23T12:58:13</date> <millis>1458752293091</millis> <sequence>93963</sequence> <logger>org.jboss.as</logger> <level>INFO</level> <class>org.jboss.as.server.BootstrapListener</class> <method>logAdminConsole</method> <thread>22</thread> <message>WFLYSRV0051: Admin console listening on http://%s:%d</message> <param>127.0.0.1</param> <param>9990</param> </record>
관리 콘솔을 사용하여 사용자 정의 로그 포맷터 구성
관리 콘솔을 사용하여 로그 포맷터를 구성할 수도 있습니다.
- 브라우저에서 관리 콘솔을 엽니다.
- 구성 → 하위 시스템 → 로깅 을 선택합니다.
- Configuration(구성) 을 선택한 다음 View(보기 )를 클릭합니다.
- Formatter를 선택한 다음 Custom Formatter(사용자 지정 형식) 옵션을 선택합니다.
11.8. 애플리케이션 로깅 정보
애플리케이션의 로깅은 JBoss EAP 로깅
하위 시스템을 사용하거나 배포별로 구성할 수 있습니다.
로그 메시지 캡처를 위한 JBoss EAP 로그 카테고리 및 핸들러 사용을 위해 로깅 하위 시스템 정보를 참조하십시오.
지원되는 애플리케이션 로깅 프레임워크 및 배포별 로깅 구성과 같은 애플리케이션 로깅에 대한 자세한 내용은 JBoss EAP 개발 가이드의 로깅 장을 참조하십시오.
11.8.1. 배포별 로깅
배포별 로깅을 사용하면 개발자가 사전에 애플리케이션의 로깅 구성을 구성할 수 있습니다. 애플리케이션이 배포되면 정의된 구성에 따라 로깅이 시작됩니다. 이 구성을 통해 생성된 로그 파일에는 애플리케이션의 동작만 포함됩니다.
배포별 로깅 구성이 수행되지 않으면 모든 애플리케이션과 서버에 로깅
하위 시스템의 구성이 사용됩니다.
이 방법에는 시스템 전체 로깅 사용에 대한 장단점이 있습니다. JBoss EAP 인스턴스의 관리자가 서버 로깅보다 다른 로깅을 구성할 필요가 없다는 장점이 있습니다. 단점은 배포별 로깅 구성은 서버 시작 시에만 읽기 때문에 런타임 시 변경할 수 없다는 점입니다.
애플리케이션에서 배포별 로깅을 사용하는 방법에 대한 지침은 JBoss EAP 개발 가이드 의 애플리케이션에 배포별 로깅 추가를 참조하십시오.
11.8.1.1. 배포별 로깅 비활성화
다음 방법 중 하나로 배포별 로깅을 비활성화할 수 있습니다.
use-deployment-logging-config
특성을false로 설정합니다
.use-deployment-logging-config
특성은 배포별 로깅을 위해 배포 스캔 여부를 제어합니다. 기본값은true
입니다. 배포별 로깅을 비활성화하려면 이 속성을false
로 설정할 수 있습니다./subsystem=logging:write-attribute(name=use-deployment-logging-config,value=false)
jboss-deployment-structure.xml
파일을 사용하여로깅
하위 시스템을 제외합니다.자세한 내용은 JBoss EAP 개발 가이드 의 배포에서 하위 시스템 제외 를 참조하십시오.
11.8.2. 로깅 프로필
로깅 프로필은 배포된 애플리케이션에 할당할 수 있는 별도의 로깅 구성 세트입니다. 일반 로깅
하위 시스템과 마찬가지로 로깅 프로필은 핸들러, 카테고리 및 루트 로거를 정의할 수 있지만 다른 프로필 또는 기본 로깅
하위 시스템에서 구성을 참조할 수는 없습니다. 로깅 프로필 설계는 구성이 용이하도록 로깅
하위 시스템을 모방합니다.
관리자는 로깅 프로필을 사용하여 다른 로깅 구성에 영향을 주지 않고 하나 이상의 애플리케이션에 해당하는 로깅 구성을 생성할 수 있습니다. 각 프로필은 서버 구성에 정의되므로 영향을 받는 애플리케이션을 재배포할 필요 없이 로깅 구성을 변경할 수 있습니다.
각 로깅 프로파일에는 다음이 포함될 수 있습니다.
- 고유한 이름입니다. 이 값은 필수입니다.
- 임의 개수의 로그 핸들러.
- 원하는 수의 로그 카테고리.
- 최대 1개의 루트 로거.
애플리케이션은 Logging-Profile
특성을 사용하여 MANIFEST.MF
파일에서 사용할 로깅 프로필을 지정할 수 있습니다.
11.8.2.1. 로깅 프로필 구성
로깅 프로필은 로그 핸들러, 카테고리 및 루트 로거를 사용하여 구성할 수 있습니다. 로깅 프로필 구성은 다음과 같은 차이점을 제외하고 로깅
하위 시스템을 구성하는 것과 동일한 구문을 사용합니다.
-
루트 구성 경로는
/subsystem=logging/logging-profile=NAME
입니다. - 로깅 프로파일에는 다른 로깅 프로필이 포함될 수 없습니다.
로깅
하위 시스템에는 로깅 프로필에 사용할 수 없는 다음 속성이 있습니다.-
add-logging-api-dependencies
-
use-deployment-logging-config
-
로깅 프로필 생성 및 구성
다음 절차에서는 관리 CLI를 사용하여 로깅 프로필을 생성하고 파일 핸들러 및 로거 범주를 설정합니다. Configuration → Subsystems → Logging → Logging Profiles 로 이동하여 관리 콘솔을 사용하여 로깅 프로필을 구성할 수도 있습니다.
로깅 프로필을 생성합니다.
/subsystem=logging/logging-profile=PROFILE_NAME:add
파일 핸들러를 생성합니다.
/subsystem=logging/logging-profile=PROFILE_NAME/file-handler=FILE_HANDLER_NAME:add(file={path=>"LOG_NAME.log", "relative-to"=>"jboss.server.log.dir"})
/subsystem=logging/logging-profile=PROFILE_NAME/file-handler=FILE_HANDLER_NAME:write-attribute(name="level", value="DEBUG")
파일 핸들러 속성 목록은 파일 로그 핸들러 속성 목록을 참조하십시오.
로거 범주를 만듭니다.
/subsystem=logging/logging-profile=PROFILE_NAME/logger=CATEGORY_NAME:add(level=TRACE)
로그 카테고리 속성 목록은 Log Category Attributes 를 참조하십시오.
파일 핸들러를 카테고리에 할당합니다.
/subsystem=logging/logging-profile=PROFILE_NAME/logger=CATEGORY_NAME:add-handler(name="FILE_HANDLER_NAME")
그런 다음 MANIFEST.MF
파일의 애플리케이션에서 사용하도록 로깅 프로필을 설정할 수 있습니다. 자세한 내용은 JBoss EAP 개발 가이드 의 애플리케이션에서 로깅 프로필 지정 을 참조하십시오.
11.8.2.2. 로깅 프로파일 구성 예
이 예에서는 로깅 프로필 구성과 이를 사용하는 애플리케이션을 보여줍니다. 관리 CLI 명령, 결과 XML 및 애플리케이션의 MANIFEST.MF
파일을 표시합니다.
예제 로깅 프로필에는 다음과 같은 특징이 있습니다.
-
이름은
accounts-app-profile
입니다. -
로그 카테고리는
com.company.accounts.ejbs입니다
. -
로그 수준
TRACE
입니다. -
로그 핸들러는
ejb-trace.log
파일을 사용하는 파일 핸들러입니다.
관리 CLI 세션
/subsystem=logging/logging-profile=accounts-app-profile:add /subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:add(file={path=>"ejb-trace.log", "relative-to"=>"jboss.server.log.dir"}) /subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:write-attribute(name="level", value="DEBUG") /subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add(level=TRACE) /subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add-handler(name="ejb-trace-file")
XML 설정
<logging-profiles> <logging-profile name="accounts-app-profile"> <file-handler name="ejb-trace-file"> <level name="DEBUG"/> <file relative-to="jboss.server.log.dir" path="ejb-trace.log"/> </file-handler> <logger category="com.company.accounts.ejbs"> <level name="TRACE"/> <handlers> <handler name="ejb-trace-file"/> </handlers> </logger> </logging-profile> </logging-profiles>
애플리케이션 관리자.MF 파일
Manifest-Version: 1.0 Logging-Profile: accounts-app-profile
11.8.3. 배포 로깅 구성 보기
다음 관리 CLI 명령을 사용하여 특정 배포의 로깅 구성에 대한 정보를 가져올 수 있습니다.
/deployment=DEPLOYMENT_NAME/subsystem=logging/configuration=CONFIG:read-resource
배포에 대한 로깅 구성 값인 CONFIG
는 다음 세 가지 값 중 하나일 수 있습니다.
-
기본적으로
배포에서로깅
하위 시스템을 사용하는 경우. 그러면로깅
하위 시스템 구성이 출력됩니다. -
profile-PROFILE_NAME
: 배포에서 로깅 하위 시스템에 정의된로깅
프로필을 사용하는 경우. 그러면 로깅 프로필 구성이 출력됩니다. -
사용 중인 구성 파일의 경로입니다(예:
myear.ear/META-INF/logging.properties
).
예를 들어 아래 관리 CLI 명령은 지정된 배포에서 사용하는 MYPROFILE
로깅 프로필의 구성을 표시합니다.
/deployment=mydeployment.war/subsystem=logging/configuration=profile-MYPROFILE:read-resource(recursive=true,include-runtime=true)
이렇게 하면 다음 정보가 출력됩니다.
{
"outcome" => "success",
"result" => {
"error-manager" => undefined,
"filter" => undefined,
"formatter" => {
"MYFORMATTER" => {
"class-name" => "org.jboss.logmanager.formatters.PatternFormatter",
"module" => undefined,
"properties" => {"pattern" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"}
}
},
"handler" => {
"MYPERIODIC" => {
"class-name" => "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler",
"encoding" => undefined,
"error-manager" => undefined,
"filter" => undefined,
"formatter" => "MYFORMATTER",
"handlers" => [],
"level" => "ALL",
"module" => undefined,
"properties" => {
"append" => "true",
"autoFlush" => "true",
"enabled" => "true",
"suffix" => ".yyyy-MM-dd",
"fileName" => "EAP_HOME/standalone/log/deployment.log"
}
}
},
"logger" => {"MYCATEGORY" => {
"filter" => undefined,
"handlers" => [],
"level" => "DEBUG",
"use-parent-handlers" => true
}},
"pojo" => undefined
}
}
재귀적 읽기-리소스
작업을 사용하여 로깅 구성 및 배포에 대한 기타 정보를 읽을 수도 있습니다.
/deployment=DEPLOYMENT_NAME/subsystem=logging:read-resource(include-runtime=true, recursive=true)
11.9. 로깅 하위 시스템 조정
로깅
하위 시스템의 성능 모니터링 및 최적화에 대한 팁은 성능 튜닝 가이드의 로깅 하위 시스템 튜닝 섹션을 참조하십시오.
12장. 데이터 소스 관리
12.1. JBoss EAP 데이터 소스 정보
JDBC 정보
JDBC API는 Java 애플리케이션에서 데이터베이스에 액세스하는 방법을 정의하는 표준입니다. 애플리케이션은 JDBC 드라이버를 참조하는 데이터 소스를 구성합니다. 그런 다음 데이터베이스가 아닌 드라이버에 대해 애플리케이션 코드를 작성할 수 있습니다. 드라이버는 코드를 데이터베이스 언어로 변환합니다. 즉, 올바른 드라이버가 설치되어 있으면 지원되는 데이터베이스와 함께 애플리케이션을 사용할 수 있습니다.
자세한 내용은 JDBC 사양을참조하십시오.
지원되는 데이터베이스
JBoss EAP 7에서 지원하는 JDBC 호환 데이터베이스 목록은 JBoss EAP 지원 구성을 참조하십시오.
데이터 소스 유형
두 가지 일반적인 유형의 리소스를 데이터 소스 및 XA 데이터 소스라고 합니다.
- 비 XA 데이터 소스
- 트랜잭션을 사용하지 않는 애플리케이션 또는 단일 데이터베이스에서 트랜잭션을 사용하는 애플리케이션에 사용됩니다.
- XA 데이터 소스
- 하나의 XA 트랜잭션의 일부로 여러 데이터베이스 또는 기타 XA 리소스를 사용하는 애플리케이션에서 사용합니다. XA 데이터 소스는 추가 오버헤드를 발생시킵니다.
JBoss EAP 관리 인터페이스를 사용하여 데이터 소스를 생성할 때 사용할 데이터 소스 유형을 지정합니다.
ExampleDS 데이터 소스
JBoss EAP에는 데이터 소스 정의 방법을 시연하기 위해 제공되는 예제 데이터 소스 구성 예제가 포함되어 있습니다. 이 데이터 소스는 개발자가 애플리케이션을 빠르게 구축할 수 있는 기능을 제공하는 경량 관계형 데이터베이스 관리 시스템인 H2 데이터베이스를 사용합니다.
ExampleDS 데이터 소스 및 H2 데이터베이스는 프로덕션 환경에서 사용해서는 안 됩니다. 이는 애플리케이션을 테스트 및 구축하는 데 필요한 모든 표준을 지원하는 매우 작은 자체 포함 데이터 소스이지만 프로덕션 용도로 사용하기에 충분한 강력하고 확장 가능한 것은 아닙니다.
12.2. JDBC 드라이버
애플리케이션에서 사용할 데이터 소스를 JBoss EAP에 정의하기 전에 먼저 적절한 JDBC 드라이버를 설치해야 합니다.
12.2.1. JDBC 드라이버를 코어 모듈로 설치
JDBC 드라이버를 핵심 모듈로 설치하려면 먼저 JDBC 드라이버를 핵심 모듈로 추가한 다음 데이터 소스 하위 시스템에서
JDBC 드라이버를 등록해야 합니다.
12.2.1.1. JDBC 드라이버를 코어 모듈로 추가
JDBC 드라이버는 다음 단계를 사용하여 관리 CLI를 사용하여 코어 모듈로 설치할 수 있습니다.
JDBC 드라이버를 다운로드합니다.
데이터베이스 벤더에서 적절한 JDBC 드라이버를 다운로드합니다. JDBC 드라이버의 공통 데이터베이스의 표준 다운로드 위치는 JDBC 드라이버 다운로드 위치를 참조하십시오.
JDBC 드라이버 JAR 파일이 ZIP 또는 TAR 아카이브에 포함된 경우 아카이브를 추출해야 합니다.
- JBoss EAP 서버 시작.
관리 CLI를 시작합니다.
$ EAP_HOME/bin/jboss-cli.sh
모듈 add management
CLI 명령을 사용하여 새 core 모듈을 추가합니다.[disconnected /] module add --name=MODULE_NAME --resources=PATH_TO_JDBC_JAR --dependencies=DEPENDENCIES
예제
다음 명령은 MySQL JDBC 드라이버 모듈을 추가합니다.
[disconnected /] module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javax.transaction.api,sun.jdk,ibm.jdk,javaee.api,javax.api
예제
관리 CLI를 시작하고 단일 단계에서 새 core 모듈을 추가하려면 다음 명령을 사용하십시오.
$ EAP_HOME/bin/jboss-cli.sh --command="module add --name=MODULE_NAME --resources=PATH_TO_JDBC_JAR --dependencies=DEPENDENCIES"
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
이 명령을 사용하여
모듈 추가 및 제거에 대한 자세한 내용은 module --help
를 실행합니다.
애플리케이션 데이터 소스에서 참조하려면 다음에 JDBC 드라이버로 등록해야 합니다.
12.2.1.2. JDBC 드라이버 등록
드라이버가 코어 모듈로 설치되면 다음 관리 CLI 명령을 사용하여 JDBC 드라이버로 등록해야 합니다. 관리형 도메인에서 실행하는 경우 이 명령 앞에 /profile=PROFILE_NAME
을 사용해야 합니다.
/subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME, driver-class-name=DRIVER_CLASS_NAME)
driver-class-name
매개 변수는 JDBC 드라이버 jar가 /META-INF/services/java.sql.Driver
파일에 둘 이상의 클래스를 정의하는 경우에만 필요합니다.
예를 들어 MySQL 5.1.36 JDBC 드라이버 JAR의 /META-INF/services/java.sql.Driver
파일은 다음 두 개의 클래스를 정의합니다.
- com.mysql.cj.jdbc.Driver
- com.mysql.fabric.jdbc.FabricMySQLDriver
이 경우 driver-class-name=com.mysql.cj.jdbc.Driver
로 전달합니다.
예를 들어 다음 명령은 MySQL JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.cj.jdbc.MysqlXADataSource, driver-class-name=com.mysql.cj.jdbc.Driver)
이제 애플리케이션 데이터 소스에서 JDBC 드라이버를 참조할 수 있습니다.
12.2.2. JDBC 드라이버를 JAR 배포로 설치
JDBC 드라이버는 관리 CLI 또는 관리 콘솔을 사용하여 JAR 배포로 설치할 수 있습니다. 드라이버가 JDBC 4 규격인 한 배포 시 JDBC 드라이버로 자동 인식 및 설치됩니다.
다음 단계에서는 관리 CLI를 사용하여 JDBC 드라이버를 설치하는 방법을 설명합니다.
JDBC 드라이버에 권장되는 설치 방법은 핵심 모듈로 설치하는 것입니다.
JDBC 드라이버를 다운로드합니다.
데이터베이스 벤더에서 적절한 JDBC 드라이버를 다운로드합니다. JDBC 드라이버의 공통 데이터베이스의 표준 다운로드 위치는 JDBC 드라이버 다운로드 위치를 참조하십시오.
JDBC 드라이버 JAR 파일이 ZIP 또는 TAR 아카이브에 포함된 경우 아카이브를 추출해야 합니다.
- JDBC 드라이버가 JDBC 4 규격이 아닌 경우 JDBC 드라이버 JAR을 JDBC 4Compliant로 업데이트하는 단계를 참조하십시오.
JAR을 JBoss EAP에 배포합니다.
deploy PATH_TO_JDBC_JAR
참고관리형 도메인에서 적절한 서버 그룹을 지정합니다.
예를 들어 다음 명령은 MySQL JDBC 드라이버를 배포합니다.
deploy /path/to/mysql-connector-java-8.0.12.jar
데이터 소스를 정의할 때 사용할 배포된 드라이버 이름을 표시하는 JBoss EAP 서버 로그에 메시지가 표시됩니다.
WFLYJCA0018: Started Driver service with driver-name = mysql-connector-java-8.0.12.jar
이제 애플리케이션 데이터 소스에서 JDBC 드라이버를 참조할 수 있습니다.
JDBC 드라이버 JAR을 JDBC 4 Compliant로 업데이트
JDBC 드라이버 JAR이 JDBC 4 규격이 아닌 경우 다음 단계를 사용하여 배포할 수 있습니다.
- 빈 임시 디렉터리를 만듭니다.
-
META-INF
하위 디렉터리를 만듭니다. -
META-INF/services
하위 디렉터리를 만듭니다. META-INF/services/java.sql.Driver
파일을 생성하고 한 행을 추가하여 JDBC 드라이버의 정규화된 클래스 이름을 나타냅니다.예를 들어 아래 행은 MySQL JDBC 드라이버에 대해 추가됩니다.
com.mysql.cj.jdbc.Driver
JAR 명령줄 도구를 사용하여 이 새 파일을 JAR에 추가합니다.
jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver
12.2.3. JDBC 드라이버 다운로드 위치
다음 표에는 JBoss EAP와 함께 사용되는 공통 데이터베이스의 JDBC 드라이버에 대한 표준 다운로드 위치가 나와 있습니다.
이러한 링크는 Red Hat에서 제어하거나 적극적으로 모니터링하지 않는 타사 웹 사이트를 가리킵니다. 데이터베이스용 최신 드라이버의 경우 데이터베이스 벤더의 설명서 및 웹사이트를 확인하십시오.
표 12.1. JDBC 드라이버 다운로드 위치
벤더 | 위치 다운로드 |
---|---|
MySQL | |
PostgreSQL | |
Oracle | http://www.oracle.com/technetwork/database/features/jdbc/index-091264.html |
IBM | |
Sybase | jConnect JDBC 드라이버는 SAP ASE 설치용 SDK의 일부입니다. 현재 이 드라이버에는 별도의 다운로드 사이트가 없습니다. |
Microsoft |
12.2.4. 벤더별 클래스 액세스
경우에 따라 애플리케이션에서 JDBC API의 일부가 아닌 벤더별 기능을 사용해야 합니다. 이러한 경우 해당 애플리케이션에 종속성을 선언하여 벤더별 API에 액세스할 수 있습니다.
이는 고급 사용량입니다. JDBC API에서 찾을 수 없는 기능이 필요한 애플리케이션만 이 절차를 구현해야 합니다.
이 프로세스는 재인증 메커니즘을 사용하고 공급업체별 클래스에 액세스할 때 필요합니다.
MANIFEST.MF 파일 또는
파일을 사용하여 애플리케이션에 대한 종속성을 정의할 수 있습니다.
jboss-deployment-structure.
xml
아직 완료하지 않은 경우 JDBC 드라이버를 코어 모듈로 설치합니다.
MANIFEST.MF
파일 사용
-
애플리케이션의
META-INF/MANIFEST.MF
파일을 편집합니다. 종속성 행
을 추가하고 모듈 이름을 지정합니다.예를 들어 아래 행은
com.mysql
모듈을 종속성으로 선언합니다.Dependencies: com.mysql
jboss-deployment-structure.xml
파일 사용
-
애플리케이션의
META
이라는 파일을 생성합니다.-INF/ 또는
structure.xmlWEB-INF/ 폴더에 jboss-
deployment- 종속성
요소를 사용하여 모듈을 지정합니다.예를 들어 다음 예제
jboss-deployment-structure.xml
파일은com.mysql
모듈을 종속성으로 선언합니다.<jboss-deployment-structure> <deployment> <dependencies> <module name="com.mysql"/> </dependencies> </deployment> </jboss-deployment-structure>
아래 예제 코드는 MySQL API에 액세스합니다.
import java.sql.Connection; ... Connection c = ds.getConnection(); if (c.isWrapperFor(com.mysql.jdbc.Connection.class)) { com.mysql.jdbc.Connection mc = c.unwrap(com.mysql.jdbc.Connection.class); }
연결은 IronJacamar 컨테이너에서 제어하기 때문에 벤더별 API 지침을 밀접하게 따르십시오.
12.3. 데이터 소스 생성
데이터 소스는 관리 콘솔 또는 관리 CLI를 사용하여 생성할 수 있습니다.
JBoss EAP 7을 사용하면 활성화된 속성과 같은 데이터 소스 특성 값에서 표현식을 사용할
수 있습니다. 구성의 표현식 사용에 대한 자세한 내용은 속성 교체 섹션을 참조하십시오.
12.3.1. 비 XA 데이터 소스 만들기
관리 CLI 또는 관리 콘솔을 사용하여 비 XA 데이터 소스를 생성할 수 있습니다.
관리 콘솔을 사용하여 XA가 아닌 데이터 소스 정의
독립 실행형 또는 도메인 모드에서 데이터 소스로 이동합니다.
독립 실행형 모드에서 다음 탐색을 사용합니다.
구성 → Cryo stat → 데이터 소스 및 드라이버 → 데이터 소스
도메인 모드에서 다음 탐색을 사용합니다.
구성 → 프로필 → 전체 → 데이터 소스 및 드라이버 → 데이터 소스
- Add (+)(추가(+)) 버튼을 클릭하고 Add Datasource (데이터 소스 추가)를 선택합니다.
- 데이터 소스 유형을 선택할 수 있는 Add Datasource(데이터 소스 추가 ) 마법사를 열고 Next (다음)를 클릭합니다. 이렇게 하면 데이터베이스에 대한 템플릿이 생성됩니다. 마법사의 다음 페이지에는 선택한 데이터 소스에 고유한 값이 미리 채워져 있습니다. 이렇게 하면 데이터 소스 생성 프로세스가 쉬워집니다.
- 데이터 소스 생성 프로세스를 완료하기 전에 Test Connection (연결 테스트) 페이지에서 연결을 테스트할 수 있습니다.
- 세부 사항을 검토하고 Finish (완료)를 클릭하여 데이터 소스를 만듭니다.
관리 CLI를 사용하여 XA 데이터 소스 정의
비 XA 데이터 소스는 데이터 소스 추가
관리 CLI 명령을 사용하여 정의할 수 있습니다.
- 아직 완료하지 않은 경우 적절한 JDBC 드라이버를 코어 모듈로 설치하고 등록합니다.
적절한 인수 값을 지정하여
data-source add
명령을 사용하여 데이터 소스를 정의합니다.data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --connection-url=CONNECTION_URL --user-name=USER_NAME --password=PASSWORD
참고관리형 도메인에서
--profile=PROFILE_NAME
인수를 지정해야 합니다.이러한 매개변수 값에 대한 팁은 아래의 데이터 소스 매개 변수 섹션을 참조하십시오.
자세한 예는 지원되는 데이터베이스 의 데이터 소스 구성 예에서 참조하십시오.
데이터 소스 매개변수
- jndi-name
-
데이터 소스의 JNDI 이름은
java:/ 또는
로 시작해야 합니다. 예를 들면java:jboss/
java:jboss/datasources/ExampleDS
입니다. - driver-name
드라이버 이름 값은 JDBC 드라이버가 코어 모듈 또는 JAR 배포로 설치되었는지에 따라 다릅니다.
- core 모듈의 경우 드라이버 이름 값은 등록할 때 JDBC 드라이버에 지정된 이름이 됩니다.
JAR 배포의 경우
/META-INF/services/java.sql.Driver
파일에 하나의 클래스만 나열된 경우 JAR의 이름입니다. 나열된 클래스가 여러 개 있는 경우 값은JAR_NAME + "_
" +DRIVER_CLASS_NAME + "_
" +MAJOR_VERSION + "_
" +MINOR_VERSION
(예: mysql-connector-java-5.1.36-bin.jar_com.mysql.cj.jdbc.Driver_5_1)입니다.JDBC JAR을 배포할 때 JBoss EAP 서버 로그에 드라이버 이름을 나열할 수도 있습니다.
WFLYJCA0018: Started Driver service with driver-name = mysql-connector-java-5.1.36-bin.jar_com.mysql.cj.jdbc.Driver_5_1
- connection-url
- 지원되는 데이터베이스의 연결 URL 형식에 대한 자세한 내용은 데이터 소스 연결 URL 목록을 참조하십시오.
사용 가능한 모든 데이터 소스 속성의 전체 목록은 데이터 소스 속성 섹션을 참조하십시오.
- user-name
- 새 데이터 소스 연결을 생성할 때 사용할 사용자 이름입니다.
- 암호
- 새 데이터 소스 연결을 생성할 때 사용할 암호입니다.
12.3.2. XA 데이터 소스 만들기
관리 CLI 또는 관리 콘솔을 사용하여 XA 데이터 소스를 생성할 수 있습니다.
관리 콘솔을 사용하여 XA 데이터 소스 정의
독립 실행형 또는 도메인 모드에서 데이터 소스로 이동합니다.
독립 실행형 모드에서 다음 탐색을 사용합니다.
구성 → Cryo stat → 데이터 소스 및 드라이버 → 데이터 소스
도메인 모드에서 다음 탐색을 사용합니다.
구성 → 프로필 → 전체 → 데이터 소스 및 드라이버 → 데이터 소스
- Add (+)(추가(+)) 버튼을 클릭하고 Add XA Datasource (XA 데이터 소스 추가)를 선택합니다.
- 데이터 소스 유형을 선택할 수 있는 XA 데이터 소스 추가 마법사를 열고 Next (다음)를 클릭합니다. 이렇게 하면 데이터베이스에 대한 템플릿이 생성됩니다. 마법사의 다음 페이지에는 선택한 데이터 소스에 고유한 값이 미리 채워져 있습니다. 이렇게 하면 데이터 소스 생성 프로세스가 쉬워집니다.
- 데이터 소스 생성 프로세스를 완료하기 전에 Test Connection (연결 테스트) 페이지에서 연결을 테스트할 수 있습니다.
- 세부 사항을 검토하고 Finish (완료)를 클릭하여 데이터 소스를 만듭니다.
관리 CLI를 사용하여 XA 데이터 소스 정의
XA 데이터 소스는 xa-data-source add
management CLI 명령을 사용하여 정의할 수 있습니다.
관리형 도메인에서는 사용할 프로필을 지정해야 합니다. 관리 CLI 명령 형식에 따라 /profile=PROFILE_NAME
을 사용하여 명령 앞에 추가하거나 --profile=PROFILE_NAME
인수를 전달합니다.
- 아직 완료하지 않은 경우 적절한 JDBC 드라이버를 코어 모듈로 설치하고 등록합니다.
적절한 인수 값을 지정하여
xa-data-source add
명령을 사용하여 데이터 소스를 정의합니다.xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS --xa-datasource-properties={"ServerName"=>"HOST_NAME","DatabaseName"=>"DATABASE_NAME"}
이러한 매개변수 값에 대한 팁은 아래의 데이터 소스 매개 변수 섹션을 참조하십시오.
XA 데이터 소스 속성을 설정합니다.
XA 데이터 소스를 정의할 때 하나 이상의 XA 데이터 소스 속성이 필요하거나 이전 단계에서 데이터 소스를 추가할 때 오류가 발생합니다. XA 데이터 소스를 정의할 때 설정되지 않은 속성은 나중에 개별적으로 설정할 수 있습니다.
서버 이름을 설정합니다.
/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOST_NAME)
데이터베이스 이름을 설정합니다.
/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)
자세한 예는 지원되는 데이터베이스 의 데이터 소스 구성 예에서 참조하십시오.
데이터 소스 매개변수
- jndi-name
-
데이터 소스의 JNDI 이름은
java:/ 또는
로 시작해야 합니다. 예를 들면java:jboss/
java:jboss/datasources/ExampleDS
입니다. - driver-name
드라이버 이름 값은 JDBC 드라이버가 코어 모듈 또는 JAR 배포로 설치되었는지에 따라 다릅니다.
- core 모듈의 경우 드라이버 이름 값은 등록할 때 JDBC 드라이버에 지정된 이름이 됩니다.
JAR 배포의 경우
/META-INF/services/java.sql.Driver
파일에 하나의 클래스만 나열된 경우 JAR의 이름입니다. 나열된 클래스가 여러 개 있는 경우 값은JAR_NAME + "_
" +DRIVER_CLASS_NAME + "_
" +MAJOR_VERSION + "_
" +MINOR_VERSION
입니다(예:mysql-connector-java-5.1.36-bin.jar_com.mysql.cj.jdbc.Driver_5_1).
JDBC JAR을 배포할 때 JBoss EAP 서버 로그에 드라이버 이름을 나열할 수도 있습니다.
WFLYJCA0018: Started Driver service with driver-name = mysql-connector-java-5.1.36-bin.jar_com.mysql.cj.jdbc.Driver_5_1
- xa-datasource-class
-
JDBC 드라이버의
javax.sql.XADataSource 클래스 구현에 대한 XA 데이터 소스
클래스를 지정합니다. - xa-datasource-properties
- XA 데이터 소스를 정의할 때 하나 이상의 XA 데이터 소스 속성이 필요하거나 추가하려고 할 때 오류가 발생합니다. 추가 속성은 정의한 후 XA 데이터 소스에 추가할 수도 있습니다.
사용 가능한 모든 데이터 소스 속성의 전체 목록은 데이터 소스 속성 섹션을 참조하십시오.
12.4. 데이터 소스 수정
데이터 소스 설정은 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다.
JBoss EAP 7을 사용하면 활성화된 속성과 같은 데이터 소스 특성 값에서 표현식을 사용할
수 있습니다. 구성의 표현식 사용에 대한 자세한 내용은 속성 교체 섹션을 참조하십시오.
12.4.1. 비 XA 데이터 소스 수정
비 XA 데이터 소스 설정은 데이터 소스 관리
CLI 명령을 사용하여 업데이트할 수 있습니다. 독립형 또는 도메인 모드에서 관리 콘솔에서 데이터 소스
속성을 업데이트할 수도 있습니다.
- 독립 실행형 모드에서 구성 → Cryostat → 데이터 소스 → 드라이버 → 데이터 소스로 이동합니다.
- 도메인 모드에서 구성 → 프로필 → 전체 → 데이터 소스 → 데이터 소스로 이동합니다.
비 XA 데이터 소스는 자카르타 트랜잭션과 통합할 수 있습니다. 데이터 소스를 Jakarta Transactions와 통합하려면 jta
매개 변수가 true
로 설정되어 있어야 합니다.
데이터 소스에 대한 설정 업데이트 예
데이터 소스에 대한 설정은 다음 관리 CLI 명령을 사용하여 업데이트할 수 있습니다.
data-source --name=DATASOURCE_NAME --ATTRIBUTE_NAME=ATTRIBUTE_VALUE
관리형 도메인에서 --profile=PROFILE_NAME
인수를 지정해야 합니다.
변경 사항을 적용하려면 서버를 다시 로드해야 할 수 있습니다.
12.4.2. XA 데이터 소스 수정
XA 데이터 소스 설정은 xa-data-source
관리 CLI 명령을 사용하여 업데이트할 수 있습니다. 독립형 또는 도메인 모드에서 관리 콘솔에서 데이터 소스
속성을 업데이트할 수도 있습니다.
- 독립 실행형 모드에서 구성 → Cryostat → 데이터 소스 → 드라이버 → 데이터 소스로 이동합니다.
- 도메인 모드에서 구성 → 프로필 → 전체 → 데이터 소스 → 데이터 소스로 이동합니다.
XA 데이터 소스 업데이트 예
XA 데이터 소스에 대한 설정은 다음 관리 CLI 명령을 사용하여 업데이트할 수 있습니다.
xa-data-source --name=XA_DATASOURCE_NAME --ATTRIBUTE_NAME=ATTRIBUTE_VALUE
참고관리형 도메인에서
--profile=PROFILE_NAME
인수를 지정해야 합니다.
XA 데이터 소스 속성 추가 예
다음 관리 CLI 명령을 사용하여 XA 데이터 소스 속성을 추가할 수 있습니다.
/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=PROPERTY:add(value=VALUE)
참고관리형 도메인에서 이 명령 앞에
/profile=PROFILE_NAME
을 추가해야 합니다.
변경 사항을 적용하려면 서버를 다시 로드해야 할 수 있습니다.
12.5. 데이터 소스 제거
데이터 소스는 관리 콘솔 또는 관리 CLI를 사용하여 제거할 수 있습니다.
12.5.1. 비 XA 데이터 소스 제거
비 XA 데이터 소스는 data-source remove
management CLI 명령을 사용하여 제거할 수 있습니다. 독립형 또는 도메인 모드에서 관리 콘솔을 사용하여 데이터 소스를 제거할 수도 있습니다.
- 독립 실행형 모드에서 구성 → Cryostat → 데이터 소스 → 드라이버 → 데이터 소스로 이동합니다.
- 도메인 모드에서 구성 → 프로필 → 전체 → 데이터 소스 → 데이터 소스로 이동합니다.
다음 명령을 사용하여 XA 이외의 데이터 소스를 제거합니다.
data-source remove --name=DATASOURCE_NAME
관리형 도메인에서 --profile=PROFILE_NAME
인수를 지정해야 합니다.
데이터 소스를 제거한 후 서버를 다시 로드해야 합니다.
12.5.2. XA 데이터 소스 제거
XA 데이터 소스는 xa-data-source remove
management CLI 명령을 사용하여 제거할 수 있습니다. 독립형 또는 도메인 모드에서 관리 콘솔을 사용하여 데이터 소스를 제거할 수도 있습니다.
- 독립 실행형 모드에서 구성 → Cryostat → 데이터 소스 → 드라이버 → 데이터 소스로 이동합니다.
- 도메인 모드에서 구성 → 프로필 → 전체 → 데이터 소스 → 데이터 소스로 이동합니다.
다음 명령을 사용하여 XA 데이터 소스를 제거합니다.
xa-data-source remove --name=XA_DATASOURCE_NAME
관리형 도메인에서 --profile=PROFILE_NAME
인수를 지정해야 합니다.
XA 데이터 소스를 제거한 후 서버를 다시 로드해야 합니다.
12.6. 데이터 소스 연결 테스트
관리 CLI 또는 관리 콘솔을 사용하여 데이터 소스 연결을 테스트하여 해당 설정이 올바른지 확인할 수 있습니다.
관리 CLI를 사용하여 데이터 소스 연결 테스트
다음 관리 CLI 명령을 사용하여 데이터 소스의 연결을 테스트할 수 있습니다.
/subsystem=datasources/data-source=DATASOURCE_NAME:test-connection-in-pool
관리형 도메인에서 이 명령 앞에 /host=HOST_NAME /server=SERVER_NAME
을 사용해야 합니다. XA 데이터 소스를 테스트하는 경우 data-source=DATASOURCE_NAME
을 xa-data-source=XA_DATASOURCE_NAME
으로 바꿉니다.
관리 콘솔을 사용하여 데이터 소스 연결 테스트
관리 콘솔에서 데이터 소스 추가 마법사를 사용할 때 데이터 소스를 생성하기 전에 연결을 테스트할 수 있습니다. 마법사의 Test Connection (연결 테스트) 화면에서 Test Connection (연결 테스트) 버튼을 클릭합니다.
데이터 소스가 추가되면 다음 절차를 사용하여 연결을 테스트할 수 있습니다.
- 독립 실행형 모드 또는 구성 → 프로필 → 전체 → 데이터 소스 → 도메인 모드에서 데이터 소스 → 데이터 소스 → 데이터 소스로 이동합니다.
- 데이터 소스를 선택합니다.
- 드롭다운 목록에서 테스트 연결을 선택합니다.
12.7. 데이터 소스 연결 플러시
다음 관리 CLI 명령을 사용하여 데이터 소스 연결을 플러시할 수 있습니다.
관리형 도메인에서 이러한 명령 앞에 /host=HOST_NAME /server=SERVER_NAME
을 사용해야 합니다.
풀의 모든 연결을 플러시합니다.
/subsystem=datasources/data-source=DATASOURCE_NAME:flush-all-connection-in-pool
풀의 모든 연결을 정상적으로 플러시합니다.
/subsystem=datasources/data-source=DATASOURCE_NAME:flush-gracefully-connection-in-pool
서버는 연결이 유휴 상태가 될 때까지 기다린 후 연결을 플러시합니다.
풀의 모든 유휴 연결을 플러시합니다.
/subsystem=datasources/data-source=DATASOURCE_NAME:flush-idle-connection-in-pool
풀에서 잘못된 모든 연결을 플러시합니다.
/subsystem=datasources/data-source=DATASOURCE_NAME:flush-invalid-connection-in-pool
서버는 유효하지 않은 것으로 판단되는 모든 연결을 플러시합니다(예: 데이터베이스 연결 유효성 검사에 설명된
valid-connection-checker-class
검증 메커니즘).-name
또는 check-valid-connection-sql
관리 콘솔을 사용하여 연결을 플러시할 수도 있습니다. Runtime(런타임 ) 탭에서 서버를 선택하고, Datasources (데이터 소스)를 선택하고, 데이터 소스를 선택한 다음 드롭다운을 사용하여 적절한 작업을 선택합니다.
12.8. XA 데이터 소스 복구
XA 데이터 소스는 트랜잭션 관리자에 의해 조정되고 단일 트랜잭션에서 여러 리소스를 확장할 수 있는 XA 글로벌 트랜잭션에 참여할 수 있는 데이터 소스입니다. 참가자 중 한 명이 변경 사항을 커밋하지 못하면 다른 참가자가 트랜잭션을 중단하고 트랜잭션이 발생되기 전과 마찬가지로 해당 상태를 복원합니다. 이는 일관성을 유지하고 잠재적인 데이터 손실 또는 손상을 방지하기 위한 것입니다.
XA 복구는 리소스나 트랜잭션 참여자가 충돌하거나 사용할 수 없는 경우에도 트랜잭션의 영향을 받는 모든 리소스가 업데이트 또는 롤백되도록 하는 프로세스입니다. XA 복구는 사용자의 개입 없이 수행됩니다.
각 XA 리소스에는 해당 구성과 관련된 복구 모듈이 있어야 합니다. 복구 모듈은 복구를 수행할 때 실행되는 코드입니다. JBoss EAP는 JDBC XA 리소스에 대한 복구 모듈을 자동으로 등록합니다. 사용자 지정 복구 코드를 구현하려는 경우 XA 데이터 소스에 사용자 지정 모듈을 등록할 수 있습니다. 복구 모듈은 class com.arspringa.ats.jta.recovery.XAResource recoveryy를 확장해야 합니다
.
12.8.1. XA 복구 구성
대부분의 JDBC 리소스에서 복구 모듈은 자동으로 리소스와 연결됩니다. 이 경우 복구 모듈을 리소스에 연결하여 복구를 수행할 수 있는 옵션만 구성해야 합니다.
다음 표에서는 XA 복구와 관련된 XA 데이터 소스 매개변수를 설명합니다. 이러한 각 구성 특성은 데이터 소스 생성 중에 또는 이후에 설정할 수 있습니다. 관리 콘솔 또는 관리 CLI를 사용하여 설정할 수 있습니다. XA 데이터 소스 구성에 대한 자세한 내용은 XA 데이터 소스 수정을 참조하십시오.
표 12.2. XA 복구를 위한 데이터 소스 매개변수
속성 | 설명 |
---|---|
recovery-username | 복구를 위해 리소스에 연결하는 데 사용할 사용자 이름입니다. 이 값을 지정하지 않으면 데이터 소스 보안 설정이 사용됩니다. |
recovery-password | 복구를 위해 리소스에 연결하는 데 사용할 암호입니다. 이 값을 지정하지 않으면 데이터 소스 보안 설정이 사용됩니다. |
recovery-security-domain | 복구를 위해 리소스에 연결하는 데 사용할 보안 도메인입니다. |
recovery-plugin-class-name |
사용자 지정 복구 모듈을 사용해야 하는 경우 이 속성을 모듈의 정규화된 클래스 이름으로 설정합니다. 이 모듈은 class |
recovery-plugin-properties |
속성을 설정해야 하는 사용자 지정 복구 모듈을 사용하는 경우 이 속성을 속성에 대해 쉼표로 구분된 |
XA 복구 비활성화
여러 XA 데이터 소스가 동일한 물리적 데이터베이스에 연결되는 경우 일반적으로 해당 데이터베이스 중 하나에 대해서만 XA 복구를 구성해야 합니다.
다음 관리 CLI 명령을 사용하여 XA 데이터 소스에 대한 복구를 비활성화합니다.
/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=no-recovery,value=true)
12.8.2. 벤더별 XA 복구
벤더별 구성
일부 데이터베이스에서는 JBoss EAP 트랜잭션 관리자가 관리하는 XA 트랜잭션에서 협업하기 위해 특정 구성이 필요합니다. 자세한 정보와 최신 정보는 데이터베이스 벤더의 설명서를 참조하십시오.
- MySQL
- 특별한 설정은 필요하지 않습니다. 자세한 내용은 MySQL 설명서를 참조하십시오.
자동화된 XA 복구를 위해 MySQL 8 이상에는 특수 구성이 필요합니다. 자세한 내용은 JBoss EAP 7.4 지원 구성을 참조하십시오.
- PostgreSQL 및 Postgres Plus 고급 서버
-
PostgreSQL에서 XA 트랜잭션을 처리할 수 있으려면 구성 매개 변수
max_prepared_transactions
를0
보다 크거나max_connections
보다 큰 값으로 변경합니다. - Oracle
Oracle 사용자
USER
가 복구에 필요한 테이블에 액세스할 수 있는지 확인합니다.GRANT SELECT ON sys.dba_pending_transactions TO USER; GRANT SELECT ON sys.pending_trans$ TO USER; GRANT SELECT ON sys.dba_2pc_pending TO USER; GRANT EXECUTE ON sys.dbms_xa TO USER;
Oracle 사용자에게 적절한 권한이 없는 경우 다음과 같은 오류가 표시될 수 있습니다.
WARN [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
- Microsoft SQL Server
- 자세한 내용은 http://msdn.microsoft.com/en-us/library/aa342335.aspx 을 비롯한 Microsoft SQL Server 설명서를 참조하십시오.
- IBM DB2
- 특별한 설정은 필요하지 않습니다. 자세한 내용은 IBM DB2 설명서를 참조하십시오.
- Sybase
Sybase는 데이터베이스에서 XA 트랜잭션을 활성화할 것으로 예상합니다. 올바른 데이터베이스 구성이 없으면 XA 트랜잭션이 작동하지 않습니다.
enable xact 조정
매개 변수는 Adaptive Server 트랜잭션 조정 서비스를 활성화 또는 비활성화합니다. 이 매개변수가 활성화되면 Adaptive Server는 원격 Adaptive Server 데이터 커밋을 업데이트하거나 원래 트랜잭션으로 롤백합니다.트랜잭션 조정을 활성화하려면 다음을 사용합니다.
sp_configure 'enable xact coordination', 1
- MariaDB
- 특별한 설정은 필요하지 않습니다. 자세한 내용은 MariaDB 설명서를 참조하십시오.
확인된 문제
XA 트랜잭션을 처리하는 데 이러한 알려진 문제는 JBoss EAP 7에서 지원하는 특정 데이터베이스 및 JDBC 드라이버 버전에 대한 것입니다. 지원되는 데이터베이스에 대한 최신 정보는 JBoss EAP에서 지원되는 구성을 참조하십시오.
- MySQL
- MySQL은 XA 트랜잭션을 완전히 처리할 수 없습니다. 클라이언트에서 MySQL의 연결이 끊어지면 이러한 트랜잭션에 대한 모든 정보가 손실됩니다. 자세한 내용은 MySQL 버그를 참조하십시오. 이 문제는 MySQL 5.7에서 해결되었습니다.
- PostgreSQL 및 Postgres Plus 고급 서버
2-단계 커밋(2PC) 커밋 단계에서 네트워크 오류가 발생하면 JDBC 드라이버는
XAER_RMERR
XAException 오류 코드를 반환합니다. 이 오류는 복구할 수 없는 치명적인 이벤트가 트랜잭션 관리자에게 신호를 보내지만, 트랜잭션은 데이터베이스 측의 문제 내부상태로
유지되며, 네트워크 연결이 다시 설정된 후 쉽게 수정할 수 있습니다. 올바른 반환 코드는XAER_RMFAIL
또는XAER_RETRY
여야 합니다. 잘못된 오류 코드로 인해 트랜잭션이 JBoss EAP 측면의Heuristic
상태로 유지되고 데이터베이스에 수동 조작이 필요한 잠금이 유지됩니다. 자세한 내용은 PostgreSQL 버그를 참조하십시오.1단계 커밋 최적화를 사용할 때 연결 오류가 발생하면 JDBC 드라이버에서
XAER_RMERR
을 반환하지만XAER_RMFAIL
오류 코드가 반환되어야 합니다. 이로 인해 데이터베이스가 1단계 커밋 중에 데이터를 커밋하고 해당 시점에 연결이 중단되는 경우 데이터 불일치가 발생할 수 있습니다. 그러면 클라이언트에 트랜잭션이 롤백되었음을 알립니다.Postgres Plus JDBC 드라이버는 Postgres Plus Server에 있는 모든 준비 트랜잭션에 대해 XID를 반환하므로 XID가 속한 데이터베이스를 확인할 수 없습니다. JBoss EAP에서 동일한 데이터베이스에 대해 둘 이상의 데이터 소스를 정의하면 in-doubt 트랜잭션 복구 시도가 잘못된 계정으로 실행될 수 있으므로 복구가 실패할 수 있습니다.
- Oracle
JDBC 드라이버는 일부 사용자 자격 증명으로 구성된 데이터 소스를 사용하여 복구를 호출할 때 데이터베이스 인스턴스의 모든 사용자에 속하는 XID를 반환합니다. JDBC 드라이버는 다른 사용자에 속하는 XID 복구를 시도하므로
지정된 트랜잭션으로 전환할 수 없습니다
.이 문제의 해결 방법은
FORCE ANY TRANSACTION
권한을 복구 데이터 소스 구성에 사용되는 사용자에게 부여하는 것입니다. 권한 구성에 대한 자세한 내용은 http://docs.oracle.com/database/121/ADMIN/ds_txnman.htm#ADMIN12259 에서 확인할 수 있습니다.- Microsoft SQL Server
2-단계 커밋(2PC) 커밋 단계에서 네트워크 오류가 발생하면 JDBC 드라이버는
XAER_RMERR
XAException 오류 코드를 반환합니다. 이 오류는 복구할 수 없는 치명적인 이벤트가 트랜잭션 관리자에게 신호를 보내지만, 트랜잭션은 데이터베이스 측의 문제 내부상태로
유지되며, 네트워크 연결이 다시 설정된 후 쉽게 수정할 수 있습니다. 올바른 반환 코드는XAER_RMFAIL
또는XAER_RETRY
여야 합니다. 잘못된 오류 코드로 인해 트랜잭션이 JBoss EAP 측면의Heuristic
상태로 유지되고 데이터베이스에 수동 조작이 필요한 잠금이 유지됩니다. 자세한 내용은 Microsoft SQL Server 문제 보고서 를 참조하십시오.1단계 커밋 최적화를 사용할 때 연결 오류가 발생하면 JDBC 드라이버에서
XAER_RMERR
을 반환하지만XAER_RMFAIL
오류 코드가 반환되어야 합니다. 이로 인해 데이터베이스가 1단계 커밋 중에 데이터를 커밋하고 해당 시점에 연결이 중단되는 경우 데이터 불일치가 발생할 수 있습니다. 그러면 클라이언트에 트랜잭션이 롤백되었음을 알립니다.- IBM DB2
-
1단계 커밋 중에 연결 오류가 발생하면 JDBC 드라이버에서
XAER_RETRY
를 반환하지만XAER_RMFAIL
오류 코드를 반환해야 합니다. 이로 인해 데이터베이스가 1단계 커밋 중에 데이터를 커밋하고 해당 시점에 연결이 중단되는 경우 데이터 불일치가 발생할 수 있습니다. 그러면 클라이언트에 트랜잭션이 롤백되었음을 알립니다. - Sybase
2-단계 커밋(2PC) 커밋 단계에서 네트워크 오류가 발생하면 JDBC 드라이버는
XAER_RMERR
XAException 오류 코드를 반환합니다. 이 오류는 복구할 수 없는 치명적인 이벤트가 트랜잭션 관리자에게 신호를 보내지만, 트랜잭션은 데이터베이스 측의 문제 내부상태로
유지되며, 네트워크 연결이 다시 설정된 후 쉽게 수정할 수 있습니다. 올바른 반환 코드는XAER_RMFAIL
또는XAER_RETRY
여야 합니다. 잘못된 오류 코드로 인해 트랜잭션이 JBoss EAP 측면의Heuristic
상태로 유지되고 데이터베이스에 수동 조작이 필요한 잠금이 유지됩니다.1단계 커밋 최적화를 사용할 때 연결 오류가 발생하면 JDBC 드라이버에서
XAER_RMERR
을 반환하지만XAER_RMFAIL
오류 코드가 반환되어야 합니다. 이로 인해 데이터베이스가 1단계 커밋 중에 데이터를 커밋하고 해당 시점에 연결이 중단되는 경우 데이터 불일치가 발생할 수 있습니다. 그러면 클라이언트에 트랜잭션이 롤백되었음을 알립니다.Sybase 트랜잭션 분기가 준비 상태에 있기 전에 Sybase 15.7 또는 16 데이터베이스에 대한 삽입이 포함된 XA 트랜잭션이 실패하는 경우 XA 트랜잭션을 반복하고 동일한 기본 키와 동일한 레코드를 삽입하면
com.sybase.jdbc4.jdbc.jdbc.SybSQLException 오류와 함께 실패합니다. 중복 키 행을 삽입합니다
. 이 예외는 최종되지 않은 원래 Sybase 트랜잭션 분기가 롤백될 때까지 발생합니다.- MariaDB
- MariaDB는 XA 트랜잭션을 완전히 처리할 수 없습니다. 클라이언트에서 MariaDB의 연결이 끊어지면 이러한 트랜잭션에 대한 모든 정보가 손실됩니다.
- MariaDB Galera Cluster
- MariaDB Galera 클러스터에서는 XA 트랜잭션이 지원되지 않습니다.
12.9. 데이터베이스 연결 유효성 검사
데이터베이스 유지 관리, 네트워크 문제 또는 기타 중단 이벤트로 인해 JBoss EAP가 데이터베이스에 대한 연결이 끊어질 수 있습니다. 이러한 상황에서 복구하려면 데이터 소스에 대한 데이터베이스 연결 유효성 검사를 활성화할 수 있습니다.
데이터베이스 연결 유효성 검사를 구성하려면 유효성 검사 타이밍 방법, 유효성 검사 수행 방법을 확인하는 유효성 검사 메커니즘 및 예외 정렬기를 지정하여 예외 정렬기를 지정합니다.
유효성 검사 타이밍 방법 중 하나를 선택합니다.
- validate-on-match
validate-on-match
메서드를true
로 설정하면 다음 단계에 지정된 검증 메커니즘을 사용하여 연결 풀에서 항목을 확인할 때마다 데이터베이스 연결이 검증됩니다.연결이 올바르지 않으면 로그에 경고가 작성되고 풀의 다음 연결이 검색됩니다. 이 프로세스는 유효한 연결을 찾을 때까지 계속됩니다. 풀의 모든 연결을 순환하지 않으려면
use-fast-fail
옵션을 사용할 수 있습니다. 풀에 유효한 연결이 없으면 새 연결이 생성됩니다. 연결 생성에 실패하면 요청하는 애플리케이션에 예외가 반환됩니다.- background-validation
background-validation
메서드를true
로 설정하면 사용하기 전에 백그라운드 스레드에서 연결이 주기적으로 검증됩니다. 검증 빈도는background-validation-millis
속성으로 지정합니다.background-validation-millis
의 기본값은0
이며 이는 비활성화되어 있음을 의미합니다.background-validation-millis
속성 값을 결정할 때 다음을 고려하십시오.-
이 값은
idle-timeout-minutes
설정과 동일한 값으로 설정해서는 안 됩니다. - 값이 낮을수록 풀의 유효성을 검사하는 빈도가 많고 더 빨리 풀에서 유효하지 않은 연결이 제거됩니다.
- 값이 작을수록 더 많은 데이터베이스 리소스가 필요합니다. 값이 클수록 커넥션 유효성 검사 횟수가 줄어들고 데이터베이스 리소스 사용이 줄어듭니다. 단절된 연결은 더 이상 탐지되지 않습니다.
-
이 값은
참고이러한 검증 방법은 다음 예제에서 시연한 것처럼 상호 배타적입니다.
-
validate-on-match
가true
로 설정된 경우background-validation
를false
로 설정해야 합니다. -
background-validation
가true
로 설정된 경우validate-on-match
를false
로 설정해야 합니다.
이러한 검증 방법에 대한 비교 매트릭스는 유효성 검사 타이밍 방법 비교를 참조하십시오.
유효성 검사 메커니즘 중 하나를 선택합니다.
- valid-connection-checker-class-name
valid-connection-checker-class-name
을 사용하는 것이 좋습니다. 이는 사용 중인 특정 데이터베이스에 대한 연결을 확인하는 데 사용되는 연결 검사기 클래스를 지정합니다. JBoss EAP는 다음과 같은 연결 검사기를 제공합니다.-
org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
-
org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
-
org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
-
org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
-
org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
-
org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
-
org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker
-
org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
-
org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
-
- check-valid-connection-sql
check-valid-connection-sql
을 사용하여 연결의 유효성을 검사하는 데 사용할 SQL 문을 제공합니다.다음은 Oracle 커넥션의 유효성을 검사하는 데 사용할 수 있는 SQL 문의 예입니다.
select 1 from dual
다음은 MySQL 또는 PostgreSQL 연결의 유효성을 검사하는 데 사용할 수 있는 SQL 문의의 예입니다.
select 1
예외 분류기 클래스 이름을 설정합니다.
연결이 트랜잭션에 참여하는 경우에도 예외가 치명적으로 표시되면 연결이 즉시 닫힙니다. 치명적인 연결 예외 후 올바르게 감지 및 정리하려면 exception sorter class 옵션을 사용합니다. 데이터 소스 유형에 적합한 JBoss EAP 예외 분류기를 선택합니다.
-
org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
-
org.jboss.jca.adapters.jdbc.extensions.informix.InformixExceptionSorter
-
org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
-
org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
-
org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
-
org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
-
org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
-
org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
-
12.10. 데이터 소스 보안
데이터 소스 보안은 데이터 소스 연결에 대한 암호 암호화 또는 모호성을 나타냅니다. 이러한 암호는 구성 파일의 일반 텍스트로 저장할 수 있지만 이는 보안 위험을 나타냅니다.
데이터 소스 보안에 사용할 수 있는 몇 가지 방법이 있습니다. 다음은 각 예제가 포함되어 있습니다.
레거시 보안 하위 시스템을 사용하는 경우 LDAP를 사용하여 데이터 소스 연결을 인증하고 승인하도록 보안 도메인을 구성할 수 있습니다. 보안 도메인 구성에 대한 자세한 내용은 보안 도메인 구성을 참조하십시오.
보안 도메인을 사용하여 데이터 소스 보안
다음 단계를 사용하여 보안 도메인을 사용하여 데이터 소스를 보호합니다.
새 보안 도메인을 생성합니다.
/subsystem=security/security-domain=DsRealm:add(cache-type=default) /subsystem=security/security-domain=DsRealm/authentication=classic:add(login-modules=[{code=ConfiguredIdentity,flag=required,module-options={userName=sa, principal=sa, password=sa}}])
데이터 소스의 보안 도메인이 정의됩니다. 다음 XML 추출은 CLI 명령을 호출한 결과입니다.
<security-domain name="DsRealm" cache-type="default"> <authentication> <login-module code="ConfiguredIdentity" flag="required"> <module-option name="userName" value="sa"/> <module-option name="principal" value="sa"/> <module-option name="password" value="sa"/> </login-module> </authentication> </security-domain>
새 데이터 소스를 추가합니다.
data-source add --name=securityDs --jndi-name=java:jboss/datasources/securityDs --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --driver-name=h2 --new-connection-sql="select current_user()"
데이터 소스에 보안 도메인을 설정합니다.
data-source --name=securityDs --security-domain=DsRealm
변경 사항이 적용되도록 서버를 다시 로드합니다.
reload
여러 데이터 소스가 포함된 보안 도메인을 사용하는 경우 보안 도메인에서 캐싱을 비활성화합니다. 이 작업은 cache-type
속성 값을 none
으로 설정하거나 속성을 모두 제거하여 수행할 수 있지만 캐싱이 필요한 경우 각 데이터 소스에 대해 별도의 보안 도메인을 사용합니다.
다음 XML 추출에서는 DsRealm
으로 보안된 데이터 소스를 보여줍니다.
<datasources> <datasource jndi-name="java:jboss/datasources/securityDs" pool-name="securityDs"> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url> <driver>h2</driver> <new-connection-sql>select current_user()</new-connection-sql> <security> <security-domain>DsRealm</security-domain> </security> </datasource> </datasources>
보안 도메인 사용에 대한 자세한 내용은 ID 관리 구성 방법을 참조하십시오.
암호 Vault를 사용하여 데이터 소스 보안
암호 자격 증명 모음을 사용하여 데이터 소스를 보호하려면 다음 단계를 사용합니다.
ExampleDS 데이터 소스에 대한 암호 자격 증명 모음을 설정합니다.
data-source --name=ExampleDS --password=${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}
서버를 다시 로드하여 변경 사항을 구현합니다.
reload
다음 XML 보안 요소는 암호 자격 증명 모음으로 보안된 ExampleDS 데이터 소스에 추가됩니다.
<security> <user-name>admin</user-name> <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password> </security>
암호 자격 증명 모음 사용에 대한 자세한 내용은 JBoss EAP 구성 서버 보안 가이드의 Password Vault 섹션을 참조하십시오.
자격 증명 저장소를 사용하여 데이터 소스 보안
자격 증명 저장소를 사용하여 암호를 제공할 수도 있습니다. elytron
하위 시스템은 JBoss EAP 전체에서 암호를 안전하게 보관하고 사용할 수 있도록 자격 증명 저장소를 만들 수 있는 기능을 제공합니다. JBoss EAP의 Credential Store (자격 증명 저장소) 섹션에서 자격 증명 저장소 생성 및 사용에 대한 자세한 내용은 JBoss EAP 구성 방법 가이드에서 확인할 수 있습니다.
ExampleDS에 자격 증명 저장소 참조 추가
/subsystem=datasources/data-source=ExampleDS:write-attribute(name=credential-reference,value={store=exampleCS, alias=example-ds-pw})
인증 컨텍스트를 사용하여 데이터 소스 보안
Elytron 인증 컨텍스트를 사용하여 사용자 이름과 암호를 제공할 수도 있습니다.
다음 단계를 사용하여 데이터 소스 보안에 대한 인증 컨텍스트를 구성하고 사용합니다.
password
및user-name
을 제거합니다./subsystem=datasources/data-source=ExampleDS:undefine-attribute(name=password) /subsystem=datasources/data-source=ExampleDS:undefine-attribute(name=user-name)
데이터 소스에 대해 Elytron 보안을 활성화합니다.
/subsystem=datasources/data-source=ExampleDS:write-attribute(name=elytron-enabled,value=true) reload
자격 증명에 대한
인증
구성을 만듭니다.인증 구성에는 데이터 소스를 연결할 때 사용할 자격 증명이 포함되어 있습니다. 아래 예제에서는 자격 증명 저장소에 대한 참조를 사용하지만 Elytron 보안 도메인을 사용할 수도 있습니다.
/subsystem=elytron/authentication-configuration=exampleAuthConfig:add(authentication-name=sa,credential-reference={clear-text=sa})
authentication-context
를 만듭니다./subsystem=elytron/authentication-context=exampleAuthContext:add(match-rules=[{authentication-configuration=exampleAuthConfig}])
인증 컨텍스트를 사용하도록 데이터 소스를 업데이트합니다.
아래 예제에서는 인증 컨텍스트를 사용하도록
ExampleDS
를 업데이트합니다./subsystem=datasources/data-source=ExampleDS:write-attribute(name=authentication-context,value=exampleAuthContext) reload
참고authentication-context
속성이 설정되지 않고elytron-enabled
속성이true
로 설정된 경우 JBoss EAP는 인증에 현재 컨텍스트를 사용합니다.
Kerberos를 사용하여 데이터 소스 보안
kerberos 인증을 사용하여 데이터 소스를 보호하려면 다음 설정이 필요합니다.
- Kerberos는 데이터베이스 서버에 구성되어 있습니다.
- JBoss EAP 호스트 서버에는 데이터베이스 서버에 대한 keytab 항목이 있습니다.
kerberos를 사용하여 데이터 소스를 보호하려면 다음을 수행합니다.
kerberos를 사용하도록 JBoss EAP 구성.
/system-property=java.security.krb5.conf:add(value="/path/to/krb5.conf") /system-property=sun.security.krb5.debug:add(value="false") /system-property=sun.security.spnego.debug:add(value="false")
디버깅을 위해
sun.security.krb5.debug 및
값을sun.
security.spnego.debugtrue
로 변경합니다. 프로덕션 환경에서는 값을false
로 설정하는 것이 좋습니다.보안 구성.
레거시 보안 또는 Elytron 보안을 사용하여 데이터 소스를 보호할 수 있습니다.
기존 보안과 함께 kerberos를 사용하려면 다음을 수행합니다.
캐시에서 만료된 티켓을 정기적으로 제거하도록 infinispan 캐시를 구성합니다.
batch /subsystem=infinispan/cache-container=security:add(default-cache=auth-cache) /subsystem=infinispan/cache-container=security/local-cache=auth-cache:add() /subsystem=infinispan/cache-container=security/local-cache=auth-cache/expiration=EXPIRATION:add(lifespan=3540000,max-idle=3540000) /subsystem=infinispan/cache-container=security/local-cache=auth-cache/memory=object:add(size=1000) run-batch
다음 속성은 티켓 만료를 정의합니다.
-
lifespan
: KDC에서 새 인증서를 요청하는 간격(밀리초). life속성의
값을 KDC에서 정의한 수명보다 작게 설정합니다. -
max-idle
: 사용하지 않는 경우 캐시에서 유효한 티켓을 제거해야 하는 간격(밀리초). -
max-entries
: 캐시에 보관할 kerberos 티켓의 최대 사본 수입니다. 값은 데이터 소스에서 구성된 연결 수에 해당합니다.
-
보안 도메인을 생성합니다.
batch /subsystem=security/security-domain=KerberosDatabase:add(cache-type=infinispan) /subsystem=security/security-domain=KerberosDatabase/authentication=classic:add /subsystem=security/security-domain=KerberosDatabase/authentication=classic/login-module="KerberosDatabase-Module":add(code="org.jboss.security.negotiation.KerberosLoginModule",module="org.jboss.security.negotiation",flag=required, module-options={ "debug" => "false", "storeKey" => "false", "useKeyTab" => "true", "keyTab" => "/path/to/eap.keytab", "principal" => "PRINCIPAL@SERVER.COM", "doNotPrompt" => "true", "refreshKrb5Config" => "true", "isInitiator" => "true", "addGSSCredential" => "true", "credentialLifetime" => "-1"}) run-batch
-
SQL 서버에 Microsoft JDBC 드라이버를 사용하는 경우
module-options
에서 특성과 값"wrapGSSCredential"을 "true"
를 추가합니다. -
디버깅의 경우
module-options
에서debug
속성 값을true
로 변경합니다.
-
SQL 서버에 Microsoft JDBC 드라이버를 사용하는 경우
Elytron과 함께 kerberos를 사용하려면 다음을 수행합니다.
Elytron에 kerberos 팩토리 설치.
/subsystem=elytron/kerberos-security-factory=krbsf:add(debug=false, principal=PRINCIPAL@SERVER.COM, path=/path/to/keytab, request-lifetime=-1, obtain-kerberos-ticket=true, server=false)
디버깅의 경우 특성과
debug = true
값을 추가합니다.지원되는 속성 목록은 서버 보안 구성 가이드의 Kerberos 보안 속성 섹션을 참조하십시오.
kerberos 팩토리를 사용할 인증 구성을 만듭니다.
/subsystem=elytron/authentication-configuration=kerberos-conf:add(kerberos-security-factory=krbsf)
인증 컨텍스트 생성.
/subsystem=elytron/authentication-context=ds-context:add(match-rules=[{authentication-configuration=kerberos-conf}])
kerberos를 사용하여 데이터 소스를 보호합니다.
레거시 보안을 사용하는 경우:
보안 도메인을 사용하도록 데이터 소스를 구성합니다.
/subsystem=datasources/data-source=KerberosDS:add(connection-url="URL", min-pool-size=0, max-pool-size=10, jndi-name="java:jboss/datasource/KerberosDS", driver-name=<jdbc-driver>.jar, security-domain=KerberosDatabase, allow-multiple-users=false, pool-prefill=false, pool-use-strict-min=false, idle-timeout-minutes=2)
공급업체별 연결 속성 구성.
/subsystem=datasources/data-source=KerberosDS/connection-properties=<connection-property-name>:add(value="(<kerberos-value>)")
예: Oracle 데이터베이스의 연결 속성.
/subsystem=datasources/data-source=KerberosDS/connection-properties=oracle.net.authentication_services:add(value="(KERBEROS5)")
Elytron을 사용하는 경우:
인증 컨텍스트를 사용하도록 데이터 소스를 구성합니다.
/subsystem=datasources/data-source=KerberosDS:add(connection-url="URL", min-pool-size=0, max-pool-size=10, jndi-name="java:jboss/datasource/KerberosDS", driver-name=<jdbc-driver>.jar, elytron-enabled=true, authentication-context=ds-context, allow-multiple-users=false, pool-prefill=false, pool-use-strict-min=false, idle-timeout-minutes=2)
공급업체별 연결 속성 구성.
/subsystem=datasources/data-source=KerberosDS/connection-properties=<connection-property-name>:add(value="(<kerberos-value>)")
예: Oracle 데이터베이스 연결 속성
/subsystem=datasources/data-source=KerberosDS/connection-properties=oracle.net.authentication_services:add(value="(KERBEROS5)")
kerberos 인증을 사용하는 경우 데이터 소스에 다음 속성과 값을 사용하는 것이 좋습니다.
-
pool-prefill=false
-
pool-use-strict-min=false
-
idle-timeout-minutes
지원되는 속성 목록은 데이터 소스 속성에서 참조하십시오.
12.11. 데이터 소스 통계
데이터 소스에 대한 통계 수집이 활성화되면 데이터 소스에 대한 런타임 통계를 볼 수 있습니다.
12.11.1. 데이터 소스 통계 활성화
기본적으로 데이터 소스 통계는 활성화되지 않습니다. 관리 CLI 또는 관리 콘솔을 사용하여 데이터 소스 통계 컬렉션을 활성화할 수 있습니다.
관리 CLI를 사용하여 데이터 소스 통계 활성화
다음 관리 CLI 명령을 사용하면 ExampleDS
데이터 소스에 대한 통계를 수집할 수 있습니다.
관리형 도메인에서 이 명령 앞에 /profile=PROFILE_NAME
이 있습니다.
/subsystem=datasources/data-source=ExampleDS:write-attribute(name=statistics-enabled,value=true)
변경 사항을 적용하려면 서버를 다시 로드합니다.
관리 콘솔을 사용하여 데이터 소스 통계 활성화
관리 콘솔을 사용하여 데이터 소스에 대한 통계 컬렉션을 활성화하려면 다음 단계를 사용합니다.
독립 실행형 또는 도메인 모드에서 데이터 소스로 이동합니다.
독립 실행형 모드에서 다음 탐색을 사용합니다.
구성 → Cryo stat → 데이터 소스 및 드라이버 → 데이터 소스
도메인 모드에서 다음 탐색을 사용합니다.
구성 → 프로필 → 전체 → 데이터 소스 및 드라이버 → 데이터 소스
- 데이터 소스를 선택하고 View(보기 )를 클릭합니다.
- Attributes (특성) 탭에서 Edit (편집)를 클릭합니다.
- Statistics Enabled(통계 활성화됨) 필드를 ON (켜짐)으로 설정하고 Save(저장 )를 클릭합니다. 변경 사항을 적용하려면 변경 사항을 다시 로드해야 함을 나타내는 팝업이 표시됩니다.
서버를 다시 로드합니다.
- 독립 실행형 서버의 경우 팝업에서 Reload (다시 로드) 링크를 클릭하여 서버를 다시 로드합니다.
- 관리형 도메인의 경우 팝업에서 Topology (토폴로지) 링크를 클릭합니다. Topology(토폴로지 ) 탭에서 적절한 서버를 선택하고 Reload (다시 로드) 드롭 다운 옵션을 선택하여 서버를 다시 로드합니다.
12.11.2. 데이터 소스 통계 보기
관리 CLI 또는 관리 콘솔을 사용하여 데이터 소스에 대한 런타임 통계를 볼 수 있습니다.
관리 CLI를 사용하여 데이터 소스 통계 보기
다음 관리 CLI 명령은 ExampleDS
데이터 소스에 대한 코어 풀 통계를 검색합니다.
관리형 도메인에서 이러한 명령 앞에 /host=HOST_NAME/server=SERVER_NAME
이 있습니다.
/subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "ActiveCount" => 1, "AvailableCount" => 20, "AverageBlockingTime" => 0L, "AverageCreationTime" => 122L, "AverageGetTime" => 128L, "AveragePoolTime" => 0L, "AverageUsageTime" => 0L, "BlockingFailureCount" => 0, "CreatedCount" => 1, "DestroyedCount" => 0, "IdleCount" => 1, ... }
다음 관리 CLI 명령은 ExampleDS
데이터 소스에 대한 JDBC 통계를 검색합니다.
/subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "PreparedStatementCacheAccessCount" => 0L, "PreparedStatementCacheAddCount" => 0L, "PreparedStatementCacheCurrentSize" => 0, "PreparedStatementCacheDeleteCount" => 0L, "PreparedStatementCacheHitCount" => 0L, "PreparedStatementCacheMissCount" => 0L, "statistics-enabled" => true } }
통계는 런타임 정보이므로 include-runtime=true
인수를 지정해야 합니다.
사용 가능한 모든 통계에 대한 자세한 목록은 데이터 소스 통계를 참조하십시오.
관리 콘솔을 사용하여 데이터 소스 통계 보기
관리 콘솔에서 데이터 소스 통계를 보려면 Runtime (런타임) 탭에서 Datasources (데이터 소스) 하위 시스템으로 이동하여 데이터 소스를 선택하고 View(보기 )를 클릭합니다.
사용 가능한 모든 통계에 대한 자세한 목록은 데이터 소스 통계를 참조하십시오.
12.12. 데이터 소스 튜닝
데이터 소스 하위 시스템의 성능 모니터링 및 최적화에 대한 팁은
성능 튜닝 가이드의 데이터 소스 및 리소스 어댑터 튜닝 섹션을 참조하십시오.
12.13. 용량 정책
JBoss EAP는 데이터 소스를 포함하여 Jakarta Connectors 배포를 위한 용량 정책 정의를 지원합니다. 용량 정책은 풀의 물리적 커넥션(용량 증가 및 삭제)이라고 하며, 용량 감소라고 하는 방식을 정의합니다. 기본 정책은 용량 증가에 대한 요청당 하나의 연결을 만들고 유휴 시간 초과가 용량 감소를 위해 예약될 때 모든 연결을 삭제합니다.
용량 정책을 구성하려면 용량 증분기 클래스, 용량 감소자 클래스를 지정하거나 둘 다 지정해야 합니다.
예제: 용량 정책 정의
/subsystem=datasources/data-source=ExampleDS:write-attribute(name=capacity-incrementer-class, value="org.jboss.jca.core.connectionmanager.pool.capacity.SizeIncrementer") /subsystem=datasources/data-source=ExampleDS:write-attribute(name=capacity-decrementer-class, value="org.jboss.jca.core.connectionmanager.pool.capacity.SizeDecrementer")
지정된 용량 증분기 또는 감소자 클래스에서 속성을 구성할 수도 있습니다.
예제: 용량 정책의 속성 구성
/subsystem=datasources/data-source=ExampleDS:write-attribute(name=capacity-incrementer-properties.size, value=2) /subsystem=datasources/data-source=ExampleDS:write-attribute(name=capacity-decrementer-properties.size, value=2)
MaxPoolSize 인시던터 정책
클래스 이름:org.jboss.jca.core.connectionmanager.pool.capacity.MaxPoolSizeIncrementer
MaxPoolSize 증분자 정책은 각 요청에 대해 풀을 최대 크기로 채웁니다. 이 정책은 항상 사용 가능한 최대 연결 수를 유지하려는 경우에 유용합니다.
크기 증가 정책
클래스 이름:org.jboss.jca.core.connectionmanager.pool.capacity.SizeIncrementer
Size 증분자 정책은 각 요청에 대해 지정된 연결 수만큼 풀을 채웁니다. 이 정책은 다음 요청에도 연결이 필요한 예상당 요청당 추가 커넥션 수를 사용하여 증가하려는 경우에 유용합니다.
표 12.3. 크기 정책 속성
이름 | 설명 |
---|---|
크기 | 생성해야 하는 연결 수 |
이는 기본 증가 정책이며 크기 값은 1입니다.
워터마크 인덱서 정책
클래스 이름:org.jboss.jca.core.connectionmanager.pool.capacity.WatermarkIncrementer
Kiali mark 증분 정책이 풀을 각 요청에 지정된 연결 수로 채웁니다. 이 정책은 항상 풀에 지정된 수의 연결을 유지하려는 경우에 유용합니다.
표 12.4. 워터마크 정책 속성
이름 | 설명 |
---|---|
워터마크 | 연결 수에 대한 워터마크 수준 |
MinPoolSize 거부 정책
Class name: org.jboss.jca.core.connectionmanager.pool.capacity.MinPoolSizeDecrementer
MinPoolSize 감소자 정책은 풀을 각 요청에 대해 최소 크기로 줄입니다. 이 정책은 유휴 시간 제한 요청마다 연결 수를 제한하려는 경우 유용합니다. 이 풀은 FIFO(first In First Out) 방식으로 작동합니다.
크기 거부 정책
클래스 이름:org.jboss.jca.core.connectionmanager.pool.capacity.SizeDecrementer
Size decrementer 정책은 풀을 유휴 시간 제한 요청마다 지정된 개수로 줄입니다.
표 12.5. 크기 정책 속성
이름 | 설명 |
---|---|
크기 | 삭제해야 하는 연결 수 |
이 정책은 풀 사용량이 시간이 단축될 것으로 예상하면서 유휴 시간 제한 요청당 추가 커넥션 수를 줄이려는 경우 유용합니다.
이 풀은 FIFO(first In First Out) 방식으로 작동합니다.
TimedOut 거부 정책
클래스 이름:org.jboss.jca.core.connectionmanager.pool.capacity.TimedOutDecrementer
TimedOut 감소자 정책에 따라 대기 시간 제한 요청마다 풀에서 시간 초과된 모든 연결이 제거됩니다. 이 풀은 FILO(In First In Last Out) 방식으로 작동합니다.
이 정책은 기본 감소 정책입니다.
TimedOut/FIFO 거부 정책
클래스 이름:org.jboss.jca.core.connectionmanager.pool.capacity.TimedOutFIFODecrementer
TimedOutFIFO 감소자 정책에 따라 대기 시간 제한 요청마다 풀에서 시간 초과된 모든 연결이 제거됩니다. 이 풀은 FIFO(first In First Out) 방식으로 작동합니다.
워터마크 거부 정책
클래스 이름:org.jboss.jca.core.connectionmanager.pool.capacity.WatermarkDecrementer
Kiali mark 감소자 정책은 풀을 유휴 시간 제한 요청에 대해 지정된 개수로 줄입니다. 이 정책은 항상 풀에 지정된 수의 연결을 유지하려는 경우에 유용합니다. 이 풀은 FIFO(first In First Out) 방식으로 작동합니다.
표 12.6. 워터마크 정책 속성
이름 | 설명 |
---|---|
워터마크 | 연결 수에 대한 워터마크 수준 |
12.14. Enlistment Tracing
XAResource
인스턴스 입력 시 발생하는 오류 상황을 찾는 데 도움이 되도록 열거 추적을 기록할 수 있습니다. 열거 추적이 활성화되면 jca
하위 시스템에서 모든 풀 작업에 대한 예외 오브젝트를 생성하여 필요한 경우 정확한 스택 추적을 생성할 수 있습니다. 그러나 성능 오버헤드가 발생합니다.
JBoss EAP 7.1에서는 목록 추적이 기본적으로 비활성화되어 있습니다. enlist ment-trace
특성을 true
로 설정하여 관리 CLI를 사용하여 데이터 소스에 대한 인리스트먼트 추적 기록을 활성화할 수 있습니다.
비 XA 데이터 소스에 대한 등록 추적을 활성화합니다.
data-source --name=DATASOURCE_NAME --enlistment-trace=true
XA 데이터 소스에 대한 입력 추적을 활성화합니다.
xa-data-source --name=XA_DATASOURCE_NAME --enlistment-trace=true
열거 추적을 활성화하면 성능에 영향을 미칠 수 있습니다.
12.15. 데이터 소스 구성 예
12.15.1. MySQL 데이터 소스 예
연결 정보, 기본 보안 및 유효성 검사 옵션이 있는 MySQL 데이터 소스 구성의 예입니다.
예제: MySQL 데이터 소스 구성
<datasources> <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS"> <connection-url>jdbc:mysql://localhost:3306/jbossdb</connection-url> <driver>mysql</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/> </validation> </datasource> <drivers> <driver name="mysql" module="com.mysql"> <driver-class>com.mysql.cj.jdbc.Driver</driver-class> <xa-datasource-class>com.mysql.cj.jdbc.MysqlXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: MySQL JDBC 드라이버 module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-8.0.12.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
MySQL JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
MySQL JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.cj.jdbc.MysqlXADataSource, driver-class-name=com.mysql.cj.jdbc.Driver)
MySQL 데이터 소스를 추가합니다.
data-source add --name=MySqlDS --jndi-name=java:jboss/MySqlDS --driver-name=mysql --connection-url=jdbc:mysql://localhost:3306/jbossdb --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
12.15.2. MySQL XA 데이터 소스의 예
다음은 XA 데이터 소스 속성, 기본 보안 및 유효성 검사 옵션을 사용한 MySQL XA 데이터 소스 구성의 예입니다.
예제: MySQL XA 데이터 소스 구성
<datasources> <xa-datasource jndi-name="java:jboss/MySqlXADS" pool-name="MySqlXADS"> <xa-datasource-property name="ServerName"> localhost </xa-datasource-property> <xa-datasource-property name="DatabaseName"> mysqldb </xa-datasource-property> <driver>mysql</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/> </validation> </xa-datasource> <drivers> <driver name="mysql" module="com.mysql"> <driver-class>com.mysql.cj.jdbc.Driver</driver-class> <xa-datasource-class>com.mysql.cj.jdbc.MysqlXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: MySQL JDBC 드라이버 module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-8.0.12.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
MySQL JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
MySQL JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.cj.jdbc.MysqlXADataSource, driver-class-name=com.mysql.cj.jdbc.Driver)
MySQL XA 데이터 소스를 추가합니다.
xa-data-source add --name=MySqlXADS --jndi-name=java:jboss/MySqlXADS --driver-name=mysql --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter --xa-datasource-properties={"ServerName"=>"localhost","DatabaseName"=>"mysqldb"}
12.15.3. PostgreSQL 데이터 소스의 예
연결 정보, 기본 보안 및 유효성 검사 옵션이 있는 PostgreSQL 데이터 소스 구성의 예입니다.
예제: PostgreSQL 데이터 소스 구성
<datasources> <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS"> <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url> <driver>postgresql</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> </validation> </datasource> <drivers> <driver name="postgresql" module="com.postgresql"> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: PostgreSQL JDBC 드라이버 module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.postgresql"> <resources> <resource-root path="postgresql-42.x.y.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
위의 예에서 42.x.y 를 드라이버 버전 번호로 바꾸십시오.
추가 리소스
- JDBC 드라이버 및 설치 방법에 대한 자세한 내용은 JDBC 드라이버를 참조하십시오.
- JBoss EAP 7.4의 일부로 테스트된 JDBC 드라이버에 대한 자세한 내용은 JBoss EAP 7.4 지원 구성을 참조하십시오.
관리 CLI 명령 예
다음 CLI 명령을 사용하여 PostgreSQL JDBC 드라이버 및 PostgreSQL 데이터 소스를 JDBC API에 추가할 수 있습니다.
PostgreSQL JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.postgresql --resources=/path/to/postgresql-42.x.y.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
위의 예에서 42.x.y 를 드라이버 버전 번호로 바꾸십시오.
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
PostgreSQL JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=postgresql:add(driver-name=postgresql,driver-module-name=com.postgresql,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
PostgreSQL 데이터 소스를 추가합니다.
data-source add --name=PostgresDS --jndi-name=java:jboss/PostgresDS --driver-name=postgresql --connection-url=jdbc:postgresql://localhost:5432/postgresdb --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
12.15.4. PostgreSQL XA 데이터 소스의 예
다음은 XA 데이터 소스 속성, 기본 보안 및 유효성 검사 옵션을 사용한 PostgreSQL XA 데이터 소스 구성의 예입니다.
예제: PostgreSQL XA 데이터 소스 구성
<datasources> <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS"> <xa-datasource-property name="ServerName"> localhost </xa-datasource-property> <xa-datasource-property name="PortNumber"> 5432 </xa-datasource-property> <xa-datasource-property name="DatabaseName"> postgresdb </xa-datasource-property> <driver>postgresql</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> </validation> </xa-datasource> <drivers> <driver name="postgresql" module="com.postgresql"> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: PostgreSQL JDBC 드라이버 module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.postgresql"> <resources> <resource-root path="postgresql-42.x.y.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
위의 예에서 42.x.y 를 드라이버 버전 번호로 바꾸십시오.
추가 리소스
- JDBC 드라이버 및 설치 방법에 대한 자세한 내용은 JDBC 드라이버를 참조하십시오.
- JBoss EAP 7.4의 일부로 테스트된 JDBC 드라이버에 대한 자세한 내용은 JBoss EAP 7.4 지원 구성을 참조하십시오.
관리 CLI 명령 예
다음 CLI 명령을 사용하여 PostgreSQL JDBC 드라이버 및 PostgreSQL 데이터 소스를 JDBC API에 추가할 수 있습니다.
PostgreSQL JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.postgresql --resources=/path/to/postgresql-42.x.y.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
위의 예에서 42.x.y 를 드라이버 버전 번호로 바꾸십시오.
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
PostgreSQL JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=postgresql:add(driver-name=postgresql,driver-module-name=com.postgresql,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
PostgreSQL XA 데이터 소스를 추가합니다.
xa-data-source add --name=PostgresXADS --jndi-name=java:jboss/PostgresXADS --driver-name=postgresql --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --xa-datasource-properties={"ServerName"=>"localhost","PortNumber"=>"5432","DatabaseName"=>"postgresdb"}
12.15.5. Oracle 데이터 소스의 예
연결 정보, 기본 보안 및 유효성 검사 옵션이 있는 Oracle 데이터 소스 구성의 예입니다.
예제: Oracle 데이터 소스 구성
<datasources> <datasource jndi-name="java:jboss/OracleDS" pool-name="OracleDS"> <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url> <driver>oracle</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/> </validation> </datasource> <drivers> <driver name="oracle" module="com.oracle"> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: Oracle JDBC Driver module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.oracle"> <resources> <resource-root path="ojdbc7.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
Oracle JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.oracle --resources=/path/to/ojdbc7.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
Oracle JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)
Oracle 데이터 소스 추가.
data-source add --name=OracleDS --jndi-name=java:jboss/OracleDS --driver-name=oracle --connection-url=jdbc:oracle:thin:@localhost:1521:XE --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
12.15.6. Oracle XA 데이터 소스의 예
XA 복구가 올바르게 작동하려면 Oracle XA 데이터 소스에 액세스하려면 다음 설정을 적용해야 합니다. value 사용자는
JBoss EAP에서 Oracle로 연결하도록 정의된 사용자입니다.
-
사용자에게 GRANT 선택 sys.dba_pending_transactions
-
GRANT는 sys.pending_trans$ 사용자에 대해 선택
-
GRANT는 sys.dba_2pc_pending 사용자에 대해 선택합니다.
-
sys.dbms_xa에 대한 권한 부여
다음은 XA 데이터 소스 속성, 기본 보안 및 유효성 검사 옵션을 사용한 Oracle XA 데이터 소스 구성의 예입니다.
예제: Oracle XA 데이터 소스 구성
<datasources> <xa-datasource jndi-name="java:jboss/OracleXADS" pool-name="OracleXADS"> <xa-datasource-property name="URL"> jdbc:oracle:thin:@oracleHostName:1521:orcl </xa-datasource-property> <driver>oracle</driver> <xa-pool> <is-same-rm-override>false</is-same-rm-override> </xa-pool> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/> </validation> </xa-datasource> <drivers> <driver name="oracle" module="com.oracle"> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: Oracle JDBC Driver module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.oracle"> <resources> <resource-root path="ojdbc7.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
Oracle JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.oracle --resources=/path/to/ojdbc7.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
Oracle JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)
Oracle XA 데이터 소스 추가.
xa-data-source add --name=OracleXADS --jndi-name=java:jboss/OracleXADS --driver-name=oracle --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter --same-rm-override=false --xa-datasource-properties={"URL"=>"jdbc:oracle:thin:@oracleHostName:1521:orcl"}
12.15.7. Oracle RAC 데이터 소스 예
이는 연결 정보, 기본 보안 및 검증 옵션을 사용한 Real Application Cluster(RAC) 데이터 소스 구성의 예입니다.
예제: Oracle RAC 데이터 소스 구성
<datasources> <datasource jndi-name="java:jboss/OracleDS" pool-name="OracleDS"> <connection-url>jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521))</connection-url> <driver>oracle</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/> </validation> </datasource> <drivers> <driver name="oracle" module="com.oracle"> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: Oracle JDBC 드라이버 module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.oracle"> <resources> <resource-root path="ojdbc7.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성을 수행하려면 다음 관리 CLI 명령을 사용하십시오.
Oracle JDBC 드라이버를 코어 모듈로 추가합니다.
module add --name=com.oracle --resources=/path/to/ojdbc7.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
Oracle JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)
Oracle RAC 데이터 소스를 추가합니다.
data-source add --name=OracleDS --jndi-name=java:jboss/OracleDS --driver-name=oracle --connection-url="jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521))" --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
추가 리소스
- Oracle 데이터 소스 구성에 대한 자세한 내용은 Oracle 데이터 소스를 참조하십시오.
12.15.8. Oracle RAC XA 데이터 소스 예
XA 데이터 소스 속성, 기본 보안 및 검증 옵션을 사용한 RAC 데이터 소스 구성의 예입니다.
예제: Oracle RAC XA 데이터 소스 구성
<datasources> <xa-datasource jndi-name="java:jboss/OracleXADS" pool-name="OracleXADS"> <xa-datasource-property name="URL"> jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521)) </xa-datasource-property> <driver>oracle</driver> <xa-pool> <is-same-rm-override>false</is-same-rm-override> </xa-pool> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/> </validation> </xa-datasource> <drivers> <driver name="oracle" module="com.oracle"> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: Oracle JDBC 드라이버 module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.oracle"> <resources> <resource-root path="ojdbc7.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성을 수행하려면 다음 관리 CLI 명령을 사용하십시오.
Oracle JDBC 드라이버를 코어 모듈로 추가합니다.
module add --name=com.oracle --resources=/path/to/ojdbc7.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
Oracle JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)
Oracle RAC XA 데이터 소스를 추가합니다.
xa-data-source add --name=OracleXADS --jndi-name=java:jboss/OracleXADS --driver-name=oracle --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter --same-rm-override=false --xa-datasource-properties={"URL"=>"jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521))"}
12.15.9. Microsoft SQL Server 데이터 소스 예
이는 연결 정보, 기본 보안 및 유효성 검사 옵션을 사용하는 Microsoft SQL Server 데이터 소스 구성의 예입니다.
예제: Microsoft SQL Server 데이터 소스 구성
<datasources> <datasource jndi-name="java:jboss/MSSQLDS" pool-name="MSSQLDS"> <connection-url>jdbc:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url> <driver>sqlserver</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"/> </validation> </datasource> <drivers> <driver name="sqlserver" module="com.microsoft"> <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: Microsoft SQL Server JDBC Driver module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.microsoft"> <resources> <resource-root path="sqljdbc42.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> <module name="javax.xml.bind.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
Microsoft SQL Server JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.microsoft --resources=/path/to/sqljdbc42.jar --dependencies=javax.api,javax.transaction.api,javax.xml.bind.api,javaee.api,sun.jdk,ibm.jdk
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
Microsoft SQL Server JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-xa-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerXADataSource)
Microsoft SQL Server 데이터 소스를 추가합니다.
data-source add --name=MSSQLDS --jndi-name=java:jboss/MSSQLDS --driver-name=sqlserver --connection-url=jdbc:sqlserver://localhost:1433;DatabaseName=MyDatabase --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
12.15.10. Microsoft SQL Server XA 데이터 소스 예
이는 XA 데이터 소스 속성, 기본 보안 및 유효성 검사 옵션을 사용한 Microsoft SQL Server XA 데이터 소스 구성의 예입니다.
예제: Microsoft SQL Server XA 데이터 소스 구성
<datasources> <xa-datasource jndi-name="java:jboss/MSSQLXADS" pool-name="MSSQLXADS"> <xa-datasource-property name="ServerName"> localhost </xa-datasource-property> <xa-datasource-property name="DatabaseName"> mssqldb </xa-datasource-property> <xa-datasource-property name="SelectMethod"> cursor </xa-datasource-property> <driver>sqlserver</driver> <xa-pool> <is-same-rm-override>false</is-same-rm-override> </xa-pool> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"/> </validation> </xa-datasource> <drivers> <driver name="sqlserver" module="com.microsoft"> <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: Microsoft SQL Server JDBC Driver module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.microsoft"> <resources> <resource-root path="sqljdbc42.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> <module name="javax.xml.bind.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
Microsoft SQL Server JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.microsoft --resources=/path/to/sqljdbc42.jar --dependencies=javax.api,javax.transaction.api,javax.xml.bind.api,javaee.api,sun.jdk,ibm.jdk
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
Microsoft SQL Server JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-xa-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerXADataSource)
Microsoft SQL Server XA 데이터 소스를 추가합니다.
xa-data-source add --name=MSSQLXADS --jndi-name=java:jboss/MSSQLXADS --driver-name=sqlserver --user-name=admin --password=admin --validate-on-match=true --background-validation=false --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter --same-rm-override=false --xa-datasource-properties={"ServerName"=>"localhost","DatabaseName"=>"mssqldb","SelectMethod"=>"cursor"}
12.15.11. IBM DB2 데이터 소스 예
연결 정보, 기본 보안 및 유효성 검사 옵션이 있는 IBM DB2 데이터 소스 구성의 예입니다.
예제: IBM DB2 데이터 소스 구성
<datasources> <datasource jndi-name="java:jboss/DB2DS" pool-name="DB2DS"> <connection-url>jdbc:db2://localhost:50000/ibmdb2db</connection-url> <driver>ibmdb2</driver> <pool> <min-pool-size>0</min-pool-size> <max-pool-size>50</max-pool-size> </pool> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"/> </validation> </datasource> <drivers> <driver name="ibmdb2" module="com.ibm"> <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: IBM DB2 JDBC Driver module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.ibm"> <resources> <resource-root path="db2jcc4.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
IBM DB2 JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.ibm --resources=/path/to/db2jcc4.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
IBM DB2 JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm,driver-xa-datasource-class-name=com.ibm.db2.jcc.DB2XADataSource)
IBM DB2 데이터 소스를 추가합니다.
data-source add --name=DB2DS --jndi-name=java:jboss/DB2DS --driver-name=ibmdb2 --connection-url=jdbc:db2://localhost:50000/ibmdb2db --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter --min-pool-size=0 --max-pool-size=50
12.15.12. IBM DB2 XA 데이터 소스의 예
다음은 XA 데이터 소스 속성, 기본 보안 및 유효성 검사 옵션을 사용한 IBM DB2 XA 데이터 소스 구성의 예입니다.
예제: IBM DB2 XA 데이터 소스 구성
<datasources> <xa-datasource jndi-name="java:jboss/DB2XADS" pool-name="DB2XADS"> <xa-datasource-property name="ServerName"> localhost </xa-datasource-property> <xa-datasource-property name="DatabaseName"> ibmdb2db </xa-datasource-property> <xa-datasource-property name="PortNumber"> 50000 </xa-datasource-property> <xa-datasource-property name="DriverType"> 4 </xa-datasource-property> <driver>ibmdb2</driver> <xa-pool> <is-same-rm-override>false</is-same-rm-override> </xa-pool> <security> <user-name>admin</user-name> <password>admin</password> </security> <recovery> <recover-plugin class-name="org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin"> <config-property name="EnableIsValid"> false </config-property> <config-property name="IsValidOverride"> false </config-property> <config-property name="EnableClose"> false </config-property> </recover-plugin> </recovery> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"/> </validation> </xa-datasource> <drivers> <driver name="ibmdb2" module="com.ibm"> <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: IBM DB2 JDBC Driver module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.ibm"> <resources> <resource-root path="db2jcc4.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
IBM DB2 JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.ibm --resources=/path/to/db2jcc4.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
IBM DB2 JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm,driver-xa-datasource-class-name=com.ibm.db2.jcc.DB2XADataSource)
IBM DB2 XA 데이터 소스를 추가합니다.
xa-data-source add --name=DB2XADS --jndi-name=java:jboss/DB2XADS --driver-name=ibmdb2 --user-name=admin --password=admin --validate-on-match=true --background-validation=false --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter --same-rm-override=false --recovery-plugin-class-name=org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin --recovery-plugin-properties={"EnableIsValid"=>"false","IsValidOverride"=>"false","EnableClose"=>"false"} --xa-datasource-properties={"ServerName"=>"localhost","DatabaseName"=>"ibmdb2db","PortNumber"=>"50000","DriverType"=>"4"}
12.15.13. Sybase 데이터 소스 예
연결 정보, 기본 보안 및 유효성 검사 옵션이 있는 Sybase 데이터 소스 구성의 예입니다.
예제: Sybase 데이터 소스 구성
<datasources> <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB"> <connection-url>jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6</connection-url> <driver>sybase</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"/> </validation> </datasource> <drivers> <driver name="sybase" module="com.sybase"> <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: Sybase JDBC Driver module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.sybase"> <resources> <resource-root path="jconn4.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
Sybase JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.sybase --resources=/path/to/jconn4.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
Sybase JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=sybase:add(driver-name=sybase,driver-module-name=com.sybase,driver-xa-datasource-class-name=com.sybase.jdbc4.jdbc.SybXADataSource)
Sybase 데이터 소스를 추가합니다.
data-source add --name=SybaseDB --jndi-name=java:jboss/SybaseDB --driver-name=sybase --connection-url=jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6 --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
12.15.14. Sybase XA 데이터 소스의 예
다음은 XA 데이터 소스 속성, 기본 보안 및 유효성 검사 옵션을 사용한 Sybase XA 데이터 소스 구성의 예입니다.
예제: Sybase XA 데이터 소스 구성
<datasources> <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS"> <xa-datasource-property name="ServerName"> localhost </xa-datasource-property> <xa-datasource-property name="DatabaseName"> mydatabase </xa-datasource-property> <xa-datasource-property name="PortNumber"> 4100 </xa-datasource-property> <xa-datasource-property name="NetworkProtocol"> Tds </xa-datasource-property> <driver>sybase</driver> <xa-pool> <is-same-rm-override>false</is-same-rm-override> </xa-pool> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"/> </validation> </xa-datasource> <drivers> <driver name="sybase" module="com.sybase"> <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: Sybase JDBC Driver module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="com.sybase"> <resources> <resource-root path="jconn4.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
Sybase JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.sybase --resources=/path/to/jconn4.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
Sybase JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=sybase:add(driver-name=sybase,driver-module-name=com.sybase,driver-xa-datasource-class-name=com.sybase.jdbc4.jdbc.SybXADataSource)
Sybase XA 데이터 소스를 추가합니다.
xa-data-source add --name=SybaseXADS --jndi-name=java:jboss/SybaseXADS --driver-name=sybase --user-name=admin --password=admin --validate-on-match=true --background-validation=false --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter --same-rm-override=false --xa-datasource-properties={"ServerName"=>"localhost","DatabaseName"=>"mydatabase","PortNumber"=>"4100","NetworkProtocol"=>"Tds"}
12.15.15. MariaDB 데이터 소스 예
연결 정보, 기본 보안 및 유효성 검사 옵션이 있는 MariaDB 데이터 소스 구성의 예입니다.
예제: MariaDB 데이터 소스 구성
<datasources> <datasource jndi-name="java:jboss/MariaDBDS" pool-name="MariaDBDS"> <connection-url>jdbc:mariadb://localhost:3306/jbossdb</connection-url> <driver>mariadb</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/> </validation> </datasource> <drivers> <driver name="mariadb" module="org.mariadb"> <driver-class>org.mariadb.jdbc.Driver</driver-class> <xa-datasource-class>org.mariadb.jdbc.MySQLDataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: MariaDB JDBC 드라이버 module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="org.mariadb"> <resources> <resource-root path="mariadb-java-client-3.3.0.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="org.slf4j"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
MariaDB JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=org.mariadb --resources=/path/to/mariadb-java-client-3.3.0.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api,org.slf4j
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
MariaDB JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=mariadb:add(driver-name=mariadb,driver-module-name=org.mariadb,driver-xa-datasource-class-name=org.mariadb.jdbc.MySQLDataSource, driver-class-name=org.mariadb.jdbc.Driver)
MariaDB 데이터 소스를 추가합니다.
data-source add --name=MariaDBDS --jndi-name=java:jboss/MariaDBDS --driver-name=mariadb --connection-url=jdbc:mariadb://localhost:3306/jbossdb --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
12.15.16. MariaDB XA 데이터 소스의 예
다음은 XA 데이터 소스 속성, 기본 보안 및 유효성 검사 옵션을 사용한 MariaDB XA 데이터 소스 구성의 예입니다.
예제: MariaDB XA Datasource Configuration
<datasources> <xa-datasource jndi-name="java:jboss/MariaDBXADS" pool-name="MariaDBXADS"> <xa-datasource-property name="ServerName"> localhost </xa-datasource-property> <xa-datasource-property name="DatabaseName"> mariadbdb </xa-datasource-property> <driver>mariadb</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/> </validation> </xa-datasource> <drivers> <driver name="mariadb" module="org.mariadb"> <driver-class>org.mariadb.jdbc.Driver</driver-class> <xa-datasource-class>org.mariadb.jdbc.MySQLDataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: MariaDB JDBC 드라이버 module.xml
파일
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="org.mariadb"> <resources> <resource-root path="mariadb-java-client-3.3.0.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="org.slf4j"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
MariaDB JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=org.mariadb --resources=/path/to/mariadb-java-client-3.3.0.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api,org.slf4j
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
MariaDB JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=mariadb:add(driver-name=mariadb,driver-module-name=org.mariadb,driver-xa-datasource-class-name=org.mariadb.jdbc.MySQLDataSource, driver-class-name=org.mariadb.jdbc.Driver)
MariaDB XA 데이터 소스를 추가합니다.
xa-data-source add --name=MariaDBXADS --jndi-name=java:jboss/MariaDBXADS --driver-name=mariadb --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter --xa-datasource-properties={"ServerName"=>"localhost","DatabaseName"=>"mariadbdb"}
12.15.17. MariaDB Galera 클러스터 데이터 소스의 예
연결 정보, 기본 보안 및 유효성 검사 옵션이 있는 MariaDB Galera Cluster 데이터 소스 구성의 예입니다.
MariaDB Galera Cluster는 XA 트랜잭션을 지원하지 않습니다.
예제: MariaDB Galera 클러스터 데이터 소스 구성
<datasources> <datasource jndi-name="java:jboss/MariaDBGaleraClusterDS" pool-name="MariaDBGaleraClusterDS"> <connection-url>jdbc:mariadb://192.168.1.1:3306,192.168.1.2:3306/jbossdb</connection-url> <driver>mariadb</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/> </validation> </datasource> <drivers> <driver name="mariadb" module="org.mariadb"> <driver-class>org.mariadb.jdbc.Driver</driver-class> <xa-datasource-class>org.mariadb.jdbc.MySQLDataSource</xa-datasource-class> </driver> </drivers> </datasources>
예제: MariaDB JDBC 드라이버 module.xml
파일
<?xml version='1.0' encoding='UTF-8'?> <module xmlns="urn:jboss:module:1.1" name="org.mariadb"> <resources> <resource-root path="mariadb-java-client-3.3.0.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="org.slf4j"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
MariaDB JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=org.mariadb --resources=/path/to/mariadb-java-client-3.3.0.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api,org.slf4j
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
MariaDB JDBC 드라이버를 등록합니다.
/subsystem=datasources/jdbc-driver=mariadb:add(driver-name=mariadb,driver-module-name=org.mariadb,driver-xa-datasource-class-name=org.mariadb.jdbc.MySQLDataSource, driver-class-name=org.mariadb.jdbc.Driver)
MariaDB Galera 클러스터 데이터 소스를 추가합니다.
data-source add --name=MariaDBGaleraClusterDS --jndi-name=java:jboss/MariaDBGaleraClusterDS --driver-name=mariadb --connection-url=jdbc:mariadb://192.168.1.1:3306,192.168.1.2:3306/jbossdb --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
13장. 기성품으로 데이터 소스 관리
13.1. Agroal Datasources 하위 시스템 정보
새 데이터 소스-고고 하위
시스템이 JBoss EAP 7.2에 도입되었습니다. 이는 Agroal 프로젝트에서 지원하는 새로운 고성능 직접 연결 풀입니다. 이는 현재 Jakarta Connectors 기반 데이터 소스 하위
시스템에 대한 대안으로 사용할 수 있습니다.
datasources-agroal
하위 시스템은 기본적으로 사용할 수 없으며 이 새 구현을 사용하려면 활성화해야 합니다.
datasources-agroal
하위 시스템은 기술 프리뷰로만 제공됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
13.2. Aactivityal Datasources 하위 시스템 활성화
datasources-agroal
하위 시스템은 기본 JBoss EAP 구성에서 활성화되지 않습니다. 다음 관리 CLI 명령을 사용하여 활성화합니다.
확장 기능을 추가합니다.
/extension=org.wildfly.extension.datasources-agroal:add
하위 시스템을 추가합니다.
/subsystem=datasources-agroal:add
변경 사항을 적용하려면 서버를 다시 로드합니다.
reload
서버 구성 파일에 다음 XML이 추가됩니다.
<server xmlns="urn:jboss:domain:8.0"> <extensions> ... <extension module="org.wildfly.extension.datasources-agroal"/> ... </extensions> ... <subsystem xmlns="urn:jboss:domain:datasources-agroal:1.0"/> ... </server>
13.3. 필수 데이터 소스의 핵심 모듈로 JDBC 드라이버 설치
애플리케이션이 사용할 JBoss EAP에서 Agroal 데이터 소스를 정의하기 전에 먼저 적절한 JDBC 드라이버를 설치해야 합니다.
Agroal 데이터 소스의 핵심 모듈로 JDBC 드라이버를 설치하려면 먼저 JDBC 드라이버를 핵심 모듈로 추가한 다음 datasources-agroal
하위 시스템에서 JDBC 드라이버를 등록해야 합니다.
13.3.1. JDBC 드라이버를 코어 모듈로 추가
JDBC 드라이버는 다음 단계를 사용하여 관리 CLI를 사용하여 코어 모듈로 설치할 수 있습니다.
JDBC 드라이버를 다운로드합니다.
데이터베이스 벤더에서 적절한 JDBC 드라이버를 다운로드합니다. JDBC 드라이버의 공통 데이터베이스의 표준 다운로드 위치는 JDBC 드라이버 다운로드 위치를 참조하십시오.
JDBC 드라이버 JAR 파일이 ZIP 또는 TAR 아카이브에 포함된 경우 아카이브를 추출해야 합니다.
- JBoss EAP 서버 시작.
관리 CLI를 시작합니다.
$ EAP_HOME/bin/jboss-cli.sh
모듈 add management
CLI 명령을 사용하여 새 core 모듈을 추가합니다.[disconnected /] module add --name=MODULE_NAME --resources=PATH_TO_JDBC_JAR --dependencies=DEPENDENCIES
예제
다음 명령은 MySQL JDBC 드라이버 모듈을 추가합니다.
[disconnected /] module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javax.transaction.api,sun.jdk,ibm.jdk,javaee.api,javax.api
예제
관리 CLI를 시작하고 단일 단계에서 새 core 모듈을 추가하려면 다음 명령을 사용하십시오.
$ EAP_HOME/bin/jboss-cli.sh --command="module add --name=MODULE_NAME --resources=PATH_TO_JDBC_JAR --dependencies=DEPENDENCIES"
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
이 명령을 사용하여
모듈 추가 및 제거에 대한 자세한 내용은 module --help
를 실행합니다.
애플리케이션 데이터 소스에서 참조하려면 다음에 JDBC 드라이버로 등록해야 합니다.
13.3.2. Agroal Datasources에 JDBC 드라이버 등록
드라이버가 코어 모듈로 설치되면 다음 관리 CLI 명령을 사용하여 JDBC 드라이버로 등록해야 합니다. 관리형 도메인에서 실행하는 경우 이 명령 앞에 /profile=PROFILE_NAME
을 사용해야 합니다.
/subsystem=datasources-agroal/driver=DRIVER_NAME:add(module=MODULE_NAME,class=CLASS_NAME)
CLASS_NAME
은 XA가 아닌 데이터 소스에 대해 java.sql.Driver 또는
또는 XA 데이터 소스의 경우 javax.
sql.DataSourcejavax.sql.XADataSource
를 구현하는 정규화된 클래스 이름이어야 합니다.
13.4. 기성품 Non-XA 데이터 소스 구성
Agroal 데이터 소스 사용은 기술 프리뷰로만 제공됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
13.4.1. 기성품 데이터 소스 만들기
다음 관리 CLI 명령은 Agroal 데이터 소스를 생성합니다. 관리형 도메인에서 실행하는 경우 이 명령 앞에 /profile=PROFILE_NAME
을 사용해야 합니다.
/subsystem=datasources-agroal/datasource=DATASOURCE_NAME:add(jndi-name=JNDI_NAME,connection-factory={driver=DRIVER_NAME,url=URL},connection-pool={max-size=MAX_POOL_SIZE})
사용 가능한 모든 Agroal 데이터 소스 속성의 전체 목록은 Agroal Datasource Attributes 섹션을 참조하십시오.
Agroal 데이터 소스 구성의 예는 MySQL Aactivityal Datasource 예제를 참조하십시오.
13.4.2. 숨겨진 데이터 소스 제거
다음 관리 CLI 명령은 Agroal 데이터 소스를 제거합니다. 관리형 도메인에서 실행하는 경우 이 명령 앞에 /profile=PROFILE_NAME
을 사용해야 합니다.
/subsystem=datasources-agroal/datasource=DATASOURCE_NAME:remove
13.5. 광범한 XA 데이터 소스 구성
Agroal 데이터 소스 사용은 기술 프리뷰로만 제공됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
13.5.1. 풍부한 XA 데이터 소스 만들기
다음 관리 CLI 명령은 Agroal XA 데이터 소스를 생성합니다. 관리형 도메인에서 실행하는 경우 이 명령 앞에 /profile=PROFILE_NAME
을 사용해야 합니다.
/subsystem=datasources-agroal/xa-datasource=XA_DATASOURCE_NAME:add(jndi-name=JNDI_NAME,connection-factory={driver=DRIVER_NAME,connection-properties={ServerName=HOST_NAME,PortNumber=PORT,DatabaseName=DATABASE_NAME}},connection-pool={max-size=MAX_POOL_SIZE})
사용 가능한 모든 Agroal 데이터 소스 속성의 전체 목록은 Agroal Datasource Attributes 섹션을 참조하십시오.
Agroal XA 데이터 소스 구성의 예는 MySQL Aactivityal XA Datasource 예제를 참조하십시오.
13.5.2. 풍부한 XA 데이터 소스 제거
다음 관리 CLI 명령은 Agroal XA 데이터 소스를 제거합니다. 관리형 도메인에서 실행하는 경우 이 명령 앞에 /profile=PROFILE_NAME
을 사용해야 합니다.
/subsystem=datasources-agroal/xa-datasource=DATASOURCE_NAME:remove
13.6. 기성품 데이터 소스 구성 예
13.6.1. MySQL Aactivityal Datasource의 예
이것은 연결 및 기본 보안 설정이 포함된 MySQL Agroal 데이터 소스 구성의 예입니다.
예제: MySQL Aactivityal Datasource Configuration
<subsystem xmlns="urn:jboss:domain:datasources-agroal:1.0"> <datasource name="ExampleAgroalDS" jndi-name="java:jboss/datasources/ExampleAgroalDS"> <connection-factory driver="mysql" url="jdbc:mysql://localhost:3306/jbossdb" username="admin" password="admin"/> <connection-pool max-size="30"/> </datasource> <drivers> <driver name="mysql" module="com.mysql" class="com.mysql.cj.jdbc.Driver"/> </drivers> </subsystem>
예제: MySQL JDBC 드라이버 module.xml
파일
<?xml version='1.0' encoding='UTF-8'?> <module xmlns="urn:jboss:module:1.1" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-8.0.12.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
MySQL JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
MySQL JDBC 드라이버를 등록합니다.
/subsystem=datasources-agroal/driver=mysql:add(module=com.mysql,class=com.mysql.cj.jdbc.Driver)
MySQL 데이터 소스를 추가합니다.
/subsystem=datasources-agroal/datasource=ExampleAgroalDS:add(jndi-name=java:jboss/datasources/ExampleAgroalDS,connection-factory={driver=mysql,url=jdbc:mysql://localhost:3306/jbossdb,username=admin,password=admin},connection-pool={max-size=30})
13.6.2. MySQL의 XA 데이터 소스 예
다음은 XA 데이터 소스 속성과 기본 보안 설정을 사용한 MySQL Agroal XA 데이터 소스 구성의 예입니다.
예제: MySQL의 XA 데이터 소스 구성
<subsystem xmlns="urn:jboss:domain:datasources-agroal:1.0"> <xa-datasource name="ExampleAgroalXADS" jndi-name="java:jboss/datasources/ExampleAgroalXADS"> <connection-factory driver="mysqlXA" username="admin" password="admin"> <connection-properties> <property name="ServerName" value="localhost"/> <property name="PortNumber" value="3306"/> <property name="DatabaseName" value="jbossdb"/> </connection-properties> </connection-factory> <connection-pool max-size="30"/> </xa-datasource> <drivers> <driver name="mysqlXA" module="com.mysql" class="com.mysql.cj.jdbc.MysqlXADataSource"/> </drivers> </subsystem>
예제: MySQL JDBC 드라이버 module.xml
파일
<?xml version='1.0' encoding='UTF-8'?> <module xmlns="urn:jboss:module:1.1" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-8.0.12.jar"/> </resources> <dependencies> <module name="javaee.api"/> <module name="sun.jdk"/> <module name="ibm.jdk"/> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
관리 CLI 명령 예
이 예제 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.
MySQL JDBC 드라이버를 핵심 모듈로 추가합니다.
module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
중요모듈
관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다.기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
MySQL XA JDBC 드라이버를 등록합니다.
/subsystem=datasources-agroal/driver=mysqlXA:add(module=com.mysql,class=com.mysql.cj.jdbc.MysqlXADataSource)
MySQL XA 데이터 소스를 추가합니다.
/subsystem=datasources-agroal/xa-datasource=ExampleAgroalXADS:add(jndi-name=java:jboss/datasources/ExampleAgroalXADS,connection-factory={driver=mysqlXA,connection-properties={ServerName=localhost,PortNumber=3306,DatabaseName=jbossdb},username=admin,password=admin},connection-pool={max-size=30})
14장. 트랜잭션 하위 시스템 구성
트랜잭션
하위 시스템을 사용하면 시간 제한 값, 트랜잭션 로깅, 통계 수집, JTS 사용 여부와 같은 Transaction Manager(TM) 옵션을 구성할 수 있습니다. JBoss EAP는 Narayana 프레임워크를 사용하여 트랜잭션 서비스를 제공합니다. 이 프레임워크는 Jakarta Transactions, JTS, Web Service 트랜잭션과 같은 표준을 기반으로 하는 광범위한 트랜잭션 프로토콜에 대한 지원을 활용합니다.
자세한 내용은 JBoss EAP에서 트랜잭션 관리를 참조하십시오.
15장. ORB 구성
15.1. CORBA(Common Object Request Broker Architecture) 정보
CORBA(Common Object Request Broker Architecture)는 서로 호환되지 않는 여러 언어로 작성되거나 별도의 플랫폼에서 호스팅되는 경우에도 애플리케이션과 서비스가 함께 작동할 수 있도록 하는 표준입니다. CORBA 요청은 ORB(Object Request Broker)라는 서버 측 구성 요소에서 중개합니다. JBoss EAP는 Open JDK ORB 구성 요소를 통해 ORB 인스턴스를 제공합니다.
ORB는 JTS 트랜잭션에 내부적으로 사용되며 자체 애플리케이션에서도 사용할 수 있습니다.
OTS(오브젝트 트랜잭션 서비스)는 CORBA의 일부를 구성하는 크로스 플랫폼 서비스입니다. OTS 사양은 오브젝트 관리 그룹에서 유지 관리합니다. JTS는 트랜잭션 관리자를 구축하기 위한 사양이며 JTS는 OTS 사양을 기반으로 설계되었습니다.
CORBA 및 해당 구성 요소에 대한 자세한 내용은 Common Object Request Broker Architecture 를 참조하십시오.
15.2. JTS에 대한 ORB 구성
JBoss EAP의 기본 설치에서는 트랜잭션에 대한 ORB(Object Request Broker) 지원이 비활성화됩니다. 관리 CLI 또는 관리 콘솔을 사용하여 iiop-openjdk
하위 시스템에서 ORB 설정을 구성할 수 있습니다.
관리형 도메인에서 full 또는 full -ha 프로필을 사용하거나 독립 실행형 서버에 대해 standalone-
full.xml 또는 standalone-full-
openjdk 하위 시스템을 사용할 수 있습니다.
ha.xml
구성 파일을 사용하는 경우 iiop-
iiop-openjdk
하위 시스템에서 사용 가능한 구성 옵션 목록은 IIOP 하위 시스템 속성 에서 참조하십시오.
관리 CLI를 사용하여 ORB 구성
관리 CLI를 사용하여 ORB의 각 측면을 구성할 수 있습니다. 이는 JTS와 함께 ORB를 사용하는 최소 구성입니다.
full
프로필을 사용하여 관리형 도메인에 대해 다음 관리 CLI 명령을 구성할 수 있습니다. 필요한 경우 구성해야 하는 프로필에 맞게 프로필을 변경합니다. 독립 실행형 서버를 사용하는 경우 명령의 /profile=full
부분을 생략합니다.
보안 인터셉터 활성화
값을 identity
로 설정하여 security
속성을 활성화합니다.
/profile=full/subsystem=iiop-openjdk:write-attribute(name=security,value=identity)
IIOP 하위 시스템에서 트랜잭션 활성화
JTS에 ORB를 사용하려면 트랜잭션
속성 값을 기본 사양이
아닌 full
로 설정합니다.
/profile=full/subsystem=iiop-openjdk:write-attribute(name=transactions, value=full)
Transactions 하위 시스템에서 JTS 활성화
/profile=full/subsystem=transactions:write-attribute(name=jts,value=true)
JTS 활성화의 경우 다시 로드할 수 없기 때문에 서버를 다시 시작해야 합니다.
관리 콘솔을 사용하여 ORB 구성
- 관리 콘솔 상단에서 Configuration(구성 ) 탭을 선택합니다. 관리형 도메인에서 수정할 적절한 프로필을 선택해야 합니다.
- 하위 시스템 → IIOP(OpenJDK) 를 선택하고 보기를 클릭합니다.
- Edit(편집 )를 클릭하고 필요한 경우 속성을 수정합니다.
- Save(저장 )를 클릭하여 변경 사항을 저장합니다.
15.3. Elytron 하위 시스템에서 SSL/TLS를 사용하도록 IIOP 구성
SSL/TLS를 사용하여 클라이언트와 서버 간 통신을 보호하도록 iiop-openjdk
하위 시스템을 구성할 수 있습니다. elytron
하위 시스템과 레거시 보안
하위 시스템은 iiop-openjdk
하위 시스템과 JBoss EAP 내의 기타 하위 시스템에 대한 SSL/TLS를 구성하는 데 필요한 구성 요소를 제공합니다. 다음 단계를 사용하여 SSL/TLS에 elytron
하위 시스템을 사용하도록 iiop-openjdk
하위 시스템을 구성합니다.
다음 관리 CLI 명령을 사용하여
iiop-openjdk
하위 시스템에 현재 레거시 SSL/TLS 구성을 표시합니다./subsystem=iiop-openjdk:read-attribute(name=security-domain) { "outcome" => "success", "result" => "iiopSSLSecurityDomain" }
iiop-openjdk
하위 시스템은 SSL/TLS에 대해 레거시보안
하위 시스템 또는elytron
하위 시스템을 사용해야 합니다. 동시에 두 가지를 모두 사용할 수 없습니다. 위의 명령은iiop-openjdk
하위 시스템이 SSL/TLS 처리를 위해 레거시 보안 도메인을 사용하고 있음을 보여줍니다. SSL/TLS에elytron
하위 시스템을 사용하도록iiop-openjdk
하위 시스템을 구성하려면 다음 참조를 제거해야 합니다./subsystem=iiop-openjdk:undefine-attribute(name=security-realm)
iiop
특성이 정의되지 않은 경우 다음 단계로 진행할 수 있습니다.-openjdk의 security-
domainserver-ssl-context
를 만듭니다.iiop-openjdk
하위 시스템과 함께 SSL/TLS를 사용하려면server-ssl-context
를 정의해야 합니다. JBoss EAP는 SSL/TLS 연결을 서버로 만들 때server-ssl-context
에서 제공하는 구성을 사용합니다. 서버 보안 구성 가이드에서 Elytron 하위 시스템을 사용하여 애플리케이션에 대한 일방향 SSL/TLS 활성화에서server-ssl-context
를 생성하는 방법에 대한 자세한 내용을 확인할 수 있습니다.client-ssl-context
를 만듭니다.iiop-openjdk
하위 시스템에서 SSL/TLS를 사용하려면client-ssl-context
를 정의해야 합니다. JBoss EAP는 SSL/TLS 연결을 클라이언트로 만들 때client-ssl-context
에서 제공하는 구성을 사용합니다. 서버 보안 구성 가이드에서client-ssl-context
사용에서 클라이언트-ssl-context를 만드는 방법에 대한 자세한 내용을 확인할 수 있습니다.client-ssl
-context 및
하위 시스템을 구성합니다.server-ssl-context
를 사용하도록 iiop-openjdk예제:
client-ssl-context
및server-ssl-context
설정batch /subsystem=iiop-openjdk:write-attribute(name=client-ssl-context,value=iiopClientSSC) /subsystem=iiop-openjdk:write-attribute(name=server-ssl-context,value=iiopServerSSC) run-batch reload
iiop-openjdk
하위 시스템에서 및 에 대한 연결을 구성합니다.다음 속성을 조정하여
iiop-openjdk
하위 시스템에 연결할 때 SSL/TLS 연결이 필요한지 여부를 나타낼 수 있습니다.-
iiop-openjdk
하위 시스템에서 SSL에 대한 지원을 활성화하려면support-ssl
을true
로 설정합니다. 기본값은false입니다
. -
iiop-openjdk
하위 시스템에서 SSL/TLS 연결을 요구하려면client-requires-ssl
을true
로 설정합니다. 기본값은false입니다
. -
iiop-openjdk
하위 시스템에 대한 SSL/TLS 연결을 요구하려면server-requires-ssl
을true
로 설정합니다. 기본값은false입니다
. 이 값을true
로 설정하면 SSL IIOP 소켓이 아닌 연결 시도가 차단됩니다. -
socket-binding
을 조정하려면ssl-socket-binding
을 원하는 바인딩으로 설정합니다. 기본값은iiop-ssl
입니다.
예제: 필수 사항으로 IIOP와의 SSL/TLS 연결 설정
/subsystem=iiop-openjdk:write-attribute(name=support-ssl,value=true) /subsystem=iiop-openjdk:write-attribute(name=client-requires-ssl,value=true) /subsystem=iiop-openjdk:write-attribute(name=server-requires-ssl,value=true) /subsystem=iiop-openjdk:write-attribute(name=ssl-socket-binding,value=iiop-ssl) reload
-
16장. 자카르타 커넥터 관리
16.1. 자카르타 커넥터 정보
Jakarta Connectors는 자카르타 EE 시스템에서 외부 이기종 엔터프라이즈 정보 시스템(EIS)에 대한 표준 아키텍처를 정의합니다. EIS의 예로는 ERP(Enterprise Resource Planning) 시스템, 메인프레임 트랜잭션 처리(TP), 데이터베이스 및 메시징 시스템이 있습니다. 리소스 어댑터 는 Jakarta Connectors 아키텍처를 구현하는 구성 요소입니다.
Jakarta Connectors 1.7은 다음을 관리할 수 있는 기능을 제공합니다.
- 연결
- 트랜잭션
- 보안
- 라이프 사이클
- 작업 인스턴스
- 트랜잭션 인플로우
- 메시지 인플로
16.2. 리소스 어댑터 정보
리소스 어댑터는 자카르타 커넥터 사양을 사용하여 자카르타 EE 애플리케이션과 EIS(Enterprise Information System) 간의 통신을 제공하는 배포 가능한 Jakarta EE 구성 요소입니다. 리소스 어댑터는 주로 EIS 벤더가 제품을 자카르타 EE 애플리케이션과 쉽게 통합할 수 있도록 제공합니다.
엔터프라이즈 정보 시스템은 조직 내의 다른 소프트웨어 시스템이 될 수 있습니다. 예를 들어 ERP(Enterprise Resource Planning) 시스템, 데이터베이스 시스템, 전자 메일 서버 및 독점 메시징 시스템이 있습니다.
리소스 어댑터는 JBoss EAP에 배포할 수 있는 RR(리소스 어댑터 아카이브) 파일에 패키지됩니다. RAR 파일은 EAR(Enterprise Archive) 배포에도 포함될 수 있습니다.
리소스 어댑터 자체는 ironJacamar 프로젝트에서 제공하는 resource-adapters
하위 시스템에서 정의됩니다.
16.3. jca
하위 시스템 구성
jca
하위 시스템은 Jakarta Connectors 컨테이너 및 리소스 어댑터 배포에 대한 일반 설정을 제어합니다. 관리 콘솔 또는 관리 CLI를 사용하여 jca
하위 시스템을 구성할 수 있습니다.
구성할 기본 jca
하위 시스템 요소는 다음과 같습니다.
- 관리 콘솔에서
jca
하위 시스템 설정 구성 jca
하위 시스템은 Configuration → Subsystems → JCA 로 이동하고 View (보기)를 클릭하여 관리 콘솔에서 구성할 수 있습니다. 그런 다음 적절한 탭을 선택합니다.- 구성 - 캐시된 연결 관리자, 아카이브 유효성 검사 및 빈 유효성 검사에 대한 설정이 포함됩니다. 각 항목은 자신의 탭에도 포함되어 있습니다. 적절한 탭을 열고 Edit (편집) 링크를 클릭하여 이러한 설정을 수정합니다.
- 부트스트랩 컨텍스트 - 구성된 부트스트랩 컨텍스트 목록을 포함합니다. 새 부트스트랩 컨텍스트 개체를 추가, 제거 및 구성할 수 있습니다. 각 부트스트랩 컨텍스트에는 작업 관리자가 할당되어야 합니다.
Workmanager - 구성된 작업 관리자 목록을 포함합니다. 새로운 작업 관리자를 추가, 제거 및 해당 스레드 풀에 여기에 구성할 수 있습니다. 각 작업 관리자는 하나의 짧은 스레드 풀과 선택적 장기 실행 스레드 풀을 가질 수 있습니다.
스레드 풀 특성은 선택한 작업 관리자에서 스레드 풀을 클릭하여 구성할 수 있습니다.
- 관리 CLI에서
jca
하위 시스템 설정 구성 -
jca
하위 시스템은/subsystem=jca
주소의 관리 CLI에서 구성할 수 있습니다. 관리형 도메인에서/profile=PROFILE_NAME
을 사용하여 명령 앞에 있어야 합니다.
다음 섹션의 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시될 때 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-jca_5_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
아카이브 유효성 검사
이는 배포 장치에서 아카이브 검증을 수행할지 여부를 결정합니다. 다음 표에서는 아카이브 검증을 위해 설정할 수 있는 속성을 설명합니다.
표 16.1. Archive Validation Attributes
속성 | 기본값 | 설명 |
---|---|---|
enabled | true | 아카이브 검증이 활성화되었는지 여부를 지정합니다. |
fail-on-error | true | 아카이브 검증 오류 보고서가 배포에 실패하는지 여부를 지정합니다. |
Fail-on-warn | false | 아카이브 검증 경고 보고서가 배포에 실패하는지 여부를 지정합니다. |
아카이브에서 Jakarta Connectors 사양을 올바르게 구현하지 않고 아카이브 유효성 검사가 활성화된 경우 문제를 설명하는 배포 중에 오류 메시지가 표시됩니다. 예를 들면 다음과 같습니다.
Severity: ERROR Section: 19.4.2 Description: A ResourceAdapter must implement a "public int hashCode()" method. Code: com.mycompany.myproject.ResourceAdapterImpl Severity: ERROR Section: 19.4.2 Description: A ResourceAdapter must implement a "public boolean equals(Object)" method. Code: com.mycompany.myproject.ResourceAdapterImpl
아카이브 유효성 검사를 지정하지 않으면 해당하는 것으로 간주되고 enabled
속성의 기본값은 true
입니다.
빈 유효성 검사
이 설정은 빈 유효성 검사가 수행되었는지 여부를 결정합니다. 사양에 대한 자세한 내용은 Jakarta Bean Validation 사양에서 를 참조하십시오. 다음 테이블에서는 빈 유효성 검사를 위해 설정할 수 있는 속성을 설명합니다.
표 16.2. 빈 유효성 검사 속성
속성 | 기본값 | 설명 |
---|---|---|
enabled | true | 빈 유효성 검사가 활성화되었는지 여부를 지정합니다. |
빈 유효성 검사를 지정하지 않으면 해당하는 것으로 간주되며 enabled
속성의 기본값은 true
입니다.
작업 관리자
업무 관리자는 다음 두 가지 유형이 있습니다.
- 기본 작업 관리자
- 기본 작업 관리자 및 해당 스레드 풀.
- 사용자 정의 작업 관리자
- 사용자 지정 작업 관리자 정의 및 해당 스레드 풀.
다음 표는 작업 관리자를 위해 설정할 수 있는 특성을 설명합니다.
표 16.3. 작업 관리자 속성
속성 | 설명 |
---|---|
name | 작업 관리자의 이름을 지정합니다. |
Elytron 지원 |
이 특성은 |
또한 작업 관리자에게는 다음과 같은 하위 요소가 있습니다.
표 16.4. 업무 관리자 자식 요소
하위 요소 | 설명 |
---|---|
short-running-threads | 표준 작업 인스턴스의 스레드 풀. 각 작업 관리자는 하나의 짧은 스레드 풀을 보유합니다. |
long-running-threads |
Jakarta Connectors 1.7용 스레드 풀로 |
다음 표에서는 작업 관리자 스레드 풀에 대해 설정할 수 있는 속성을 설명합니다.
표 16.5. 스레드 풀 속성
속성 | 설명 |
---|---|
allow-core-timeout |
코어 스레드의 시간 초과 여부를 결정하는 부울 설정입니다. 기본값은 |
코어 스레드 | 코어 스레드 풀 크기입니다. 최대 스레드 풀 크기보다 작거나 같아야 합니다. |
handoff-executor | 작업을 수락할 수 없는 경우 작업을 에 위임하는 실행자입니다. 지정하지 않으면 수락할 수 없는 작업이 자동으로 삭제됩니다. |
keepalive-time | 작업을 수행한 후 풀 스레드를 유지해야 하는 시간을 지정합니다. |
max-threads | 최대 스레드 풀 크기입니다. |
name | 스레드 풀의 이름을 지정합니다. |
queue-length | 최대 대기열 길이입니다. |
thread-factory | 스레드 팩토리 참조. |
분산 작업 관리자
분산된 작업 관리자는 다른 작업 관리자 인스턴스에서 작업 실행을 변경할 수 있는 작업 관리자 인스턴스입니다.
다음 예제 관리 CLI 명령은 분산된 작업 관리자를 구성합니다. 독립 실행형 서버에 대한 standalone-ha.xml 또는
구성 파일과 같은 고가용성 기능을 제공하는 구성을 사용해야 합니다.
standalone-full-ha.xml
예제: 분산된 작업 관리자 구성
batch /subsystem=jca/distributed-workmanager=myDistWorkMgr:add(name=myDistWorkMgr) /subsystem=jca/distributed-workmanager=myDistWorkMgr/short-running-threads=myDistWorkMgr:add(queue-length=10,max-threads=10) /subsystem=jca/bootstrap-context=myCustomContext:add(name=myCustomContext,workmanager=myDistWorkMgr) run-batch
short-running-threads
요소의 이름은 distributed-workmanager
요소의 이름과 같아야 합니다.
다음 표에는 분산된 작업 관리자에 대해 구성할 수 있는 특성이 설명되어 있습니다.
표 16.6. 분산된 Work Manager 속성
속성 | 설명 |
---|---|
Elytron 지원 | 작업 관리자의 Elytron 보안을 활성화합니다. |
name | 분산 작업 관리자의 이름입니다. |
policy | 정책은 작업 인스턴스를 재배포할 시기를 결정합니다. 허용되는 값은 다음과 같습니다.
|
policy-options |
정책의 키/값 쌍 옵션 목록입니다. /subsystem=jca/distributed-workmanager=myDistWorkMgr:write-attribute(name=policy-options,value={watermark=3}) |
선택기 | 선택기는 작업 인스턴스를 재배포할 네트워크의 노드를 결정합니다. 허용되는 값은 다음과 같습니다.
|
selector-options | 선택기의 키/값 쌍 옵션 목록입니다. |
또한 분산 작업 관리자에게는 다음과 같은 하위 요소가 있습니다.
표 16.7. 분산 작업 관리자 하위 요소
하위 요소 | 설명 |
---|---|
long-running-threads |
|
short-running-threads | 표준 작업 인스턴스의 스레드 풀입니다. 각 분산된 작업 관리자는 짧은 스레드 풀이 있어야 합니다. |
부트스트랩 컨텍스트
이는 사용자 지정 부트스트랩 컨텍스트를 정의하는 데 사용됩니다. 다음 표는 부트스트랩 컨텍스트에 대해 설정할 수 있는 속성을 설명합니다.
표 16.8. 부트스트랩 컨텍스트 속성
속성 | 설명 |
---|---|
name | 부트스트랩 컨텍스트의 이름을 지정합니다. |
workmanager | 이 컨텍스트에 사용할 작업 관리자의 이름을 지정합니다. |
캐시된 연결 관리자
이는 연결을 디버깅하고 트랜잭션에서 연결의 지연 목록을 지원하는 데 사용되며, 애플리케이션에서 적절하게 사용 및 릴리스되는지 여부를 추적합니다. 다음 테이블에서는 캐시된 연결 관리자에 대해 설정할 수 있는 속성을 설명합니다.
표 16.9. 캐시된 연결 관리자 속성
속성 | 기본값 | 설명 |
---|---|---|
debug | false | 명시적으로 연결을 종료하려면 실패 시 경고를 출력합니다. |
오류 | false | 명시적으로 연결을 종료하려면 실패 시 예외가 발생합니다. |
ignore-unknown-connections | false | 알 수 없는 연결이 캐시되지 않도록 지정합니다. |
설치 | false | 캐시된 연결 관리자 및 인터셉터를 활성화하거나 비활성화합니다. |
16.4. 리소스 어댑터 구성
16.4.1. 리소스 어댑터 배포
리소스 어댑터는 관리 CLI 또는 관리 콘솔을 사용하여 다른 배포와 마찬가지로 배포할 수 있습니다. 독립 실행형 서버를 실행하는 경우 배포 스캐너에서 선택할 배포 디렉터리에 아카이브를 복사할 수도 있습니다.
관리 CLI를 사용하여 리소스 어댑터 배포
리소스 어댑터를 독립 실행형 서버에 배포하려면 다음 관리 CLI 명령을 입력합니다.
deploy /path/to/resource-adapter.rar
관리형 도메인의 모든 서버 그룹에 리소스 어댑터를 배포하려면 다음 관리 CLI 명령을 입력합니다.
deploy /path/to/resource-adapter.rar --all-server-groups
관리 콘솔을 사용하여 리소스 어댑터 배포
- 관리 콘솔에 로그인하고 Deployments (배포) 탭을 클릭합니다.
- Add (+)(추가(+)) 버튼을 클릭합니다. 관리형 도메인에서 먼저 Content Repository (콘텐츠 리포지토리)를 선택해야 합니다.
- Upload Deployment(배포 업로드 ) 옵션을 선택합니다.
- 리소스 어댑터 아카이브로 이동하여 Next (다음)를 클릭합니다.
- 업로드를 확인한 다음 Finish (완료)를 클릭합니다.
- 관리형 도메인에서 적절한 서버 그룹에 배포를 배포하고 배포를 활성화합니다.
배포 스캐너를 사용하여 리소스 어댑터 배포
독립 실행형 서버에 리소스 어댑터를 수동으로 배포하려면 리소스 어댑터 아카이브를 서버 배포 디렉터리(예: EAP_HOME/standalone/deployments/
)로 복사합니다. 이 작업은 배포 스캐너에서 선택 및 배포합니다.
이 옵션은 관리형 도메인에 사용할 수 없습니다. 서버 그룹에 리소스 어댑터를 배포하려면 관리 콘솔 또는 관리 CLI를 사용해야 합니다.
16.4.2. 리소스 어댑터 구성
관리 인터페이스를 사용하여 리소스 어댑터를 구성할 수 있습니다. 아래 예에서는 관리 CLI를 사용하여 리소스 어댑터를 구성하는 방법을 보여줍니다. 지원되는 속성 및 기타 중요한 정보는 리소스 어댑터 벤더의 설명서를 참조하십시오.
리소스 어댑터 구성 추가
리소스 어댑터 구성을 추가합니다.
/subsystem=resource-adapters/resource-adapter=eis.rar:add(archive=eis.rar, transaction-support=XATransaction)
리소스 어댑터 설정 구성
필요에 따라 다음 설정을 구성합니다.
config-properties
구성.서버
구성 속성을 추가합니다./subsystem=resource-adapters/resource-adapter=eis.rar/config-properties=server:add(value=localhost)
포트
구성 속성을 추가합니다./subsystem=resource-adapters/resource-adapter=eis.rar/config-properties=port:add(value=9000)
admin-objects
를 구성합니다.admin 오브젝트를 추가합니다.
/subsystem=resource-adapters/resource-adapter=eis.rar/admin-objects=aoName:add(class-name=com.acme.eis.ra.EISAdminObjectImpl, jndi-name=java:/eis/AcmeAdminObject)
admin 오브젝트 구성 속성을 구성합니다.
/subsystem=resource-adapters/resource-adapter=eis.rar/admin-objects=aoName/config-properties=threshold:add(value=10)
connection-definitions
구성.관리되는 연결 팩토리에 대한 연결 정의를 추가합니다.
/subsystem=resource-adapters/resource-adapter=eis.rar/connection-definitions=cfName:add(class-name=com.acme.eis.ra.EISManagedConnectionFactory, jndi-name=java:/eis/AcmeConnectionFactory)
관리되는 연결 팩토리 구성 속성을 구성합니다.
/subsystem=resource-adapters/resource-adapter=eis.rar/connection-definitions=cfName/config-properties=name:add(value=Acme Inc)
등록 추적을 기록할지 여부를 구성합니다. enlist
ment-trace 특성을
추적 기록을 활성화할 수 있습니다.true
로 설정하여 엔리스트/subsystem=resource-adapters/resource-adapter=eis.rar/connection-definitions=cfName:write-attribute(name=enlistment-trace,value=true)
주의Enlistment 추적을 활성화하면 트랜잭션 등록 중에 더 쉽게 추적 오류가 발생하지만 성능에 영향을 미칩니다.
리소스 어댑터에 사용 가능한 모든 구성 옵션은 Resource Adapter Attributes 를 참조하십시오.
리소스 어댑터 활성화
리소스 어댑터를 활성화합니다.
/subsystem=resource-adapters/resource-adapter=eis.rar:activate
리소스 어댑터의 용량 정책을 정의할 수도 있습니다. 자세한 내용은 용량 정책 섹션을 참조하십시오.
16.4.3. Elytron 하위 시스템을 사용하도록 리소스 어댑터 구성
172.25.Jacamar의 서버와 리소스 어댑터 사이에는 두 가지 유형의 통신이 발생합니다.
그 중 하나는 서버에서 리소스 어댑터 연결을 열 때입니다. 사양에서 정의한 대로, 연결을 열 때 주체 및 자격 증명이 있는 JAAS 제목을 전파해야 하는 컨테이너 관리 사인온으로 보호할 수 있습니다. 이 서명은 Elytron에 위임할 수 있습니다.
ironJacamar는 보안 인플로우를 지원합니다. 이 메커니즘을 사용하면 리소스 어댑터가 작업을 작업 관리자에게 제출할 때 보안 정보를 설정하고 동일한 JBoss EAP 인스턴스에 있는 엔드포인트에 메시지를 전달할 때 보안 정보를 설정할 수 있습니다.
컨테이너 관리 Sign-On
Elytron을 사용하여 컨테이너 관리 인증을 받으려면 elytron-enabled
특성을 true
로 설정해야 합니다. 그러면 리소스 어댑터에 대한 모든 연결이 Elytron에 의해 보호됩니다.
/subsystem=resource-adapters/resource-adapter=RAR_NAME/connection-definitions=FACTORY_NAME:write-attribute(name=elytron-enabled,value=true)
elytron-enabled
특성은 resource- adapters
하위 시스템에서 elytron-enabled
특성을 true
로 설정하여 관리 CLI를 사용하여 구성할 수 있습니다. 기본적으로 이 속성은 false
로 설정됩니다.
authentication-context
속성은 서명을 수행하는 데 사용할 Elytron 인증 컨텍스트의 이름을 정의합니다.
Elytron authentication-context
속성에는 하나 이상의 인증 구성
요소가 포함될 수 있으며, 이 요소에는 사용할 자격 증명이 포함됩니다.
authentication-context
특성이 설정되지 않은 경우 JBoss EAP는 연결을 여는 호출자 코드에서 사용하는 인증 컨텍스트인 현재
를 사용합니다.
authentication-context
예제: 인증 구성
생성
/subsystem=elytron/authentication-configuration=exampleAuthConfig:add(authentication-name=sa,credential-reference={clear-text=sa})
예제: 위의 구성을 사용하여 authentication-context
만들기
/subsystem=elytron/authentication-context=exampleAuthContext:add(match-rules=[{authentication-configuration=exampleAuthConfig}])
보안 흐름
또한 작업 관리자가 실행할 작업을 제출할 때 리소스 관리자가 보안 자격 증명을 주입할 수도 있습니다. 보안 흐름은 실행 전에 작업을 인증할 수 있도록 합니다. 인증에 성공하면 생성된 인증 컨텍스트에서 제출된 작업이 실행됩니다. 실패하면 작업 실행이 거부됩니다.
Elytron 보안 inflow를 활성화하려면 리소스 어댑터 작업 관리자를 구성할 때 wm-elytron-security-domain
특성을 설정합니다. Elytron은 지정된 도메인을 기반으로 인증을 수행합니다.
리소스 어댑터 작업 관리자가 Elytron 보안 도메인인 wm-elytron-security-domain
을 사용하도록 구성된 경우 참조된 작업 관리자는 elytron-enabled
특성을 true
로 설정해야 합니다.
/subsystem=jca/workmanager=customWM:add(name=customWM, elytron-enabled=true)
wm-elytron-security-domain
대신 wm-security-domain
특성이 사용되는 경우 레거시 보안 하위 시스템에서 보안
inflow를 수행합니다.
아래 jca
하위 시스템의 구성 예에서 ra-with-elytron-security-domain
이라는 리소스 어댑터 구성을 확인할 수 있습니다. 이 리소스 어댑터는 Elytron 보안 도메인의 wm-realm
을 사용하도록 work manager 보안을 구성합니다.
<subsystem xmlns="urn:jboss:domain:jca:5.0"> <archive-validation enabled="true" fail-on-error="true" fail-on-warn="false"/> <bean-validation enabled="true"/> <default-workmanager> <short-running-threads> <core-threads count="50"/> <queue-length count="50"/> <max-threads count="50"/> <keepalive-time time="10" unit="seconds"/> </short-running-threads> <long-running-threads> <core-threads count="50"/> <queue-length count="50"/> <max-threads count="50"/> <keepalive-time time="10" unit="seconds"/> </long-running-threads> </default-workmanager> <workmanager name="customWM"> <elytron-enabled>true</elytron-enabled> <short-running-threads> <core-threads count="20"/> <queue-length count="20"/> <max-threads count="20"/> </short-running-threads> </workmanager> <bootstrap-contexts> <bootstrap-context name="customContext" workmanager="customWM"/> </bootstrap-contexts> <cached-connection-manager/> </subsystem>
그런 다음 work manager는 resource-adapter
하위 시스템에서 boostrap 컨텍스트를 사용하여 참조됩니다.
<subsystem xmlns="urn:jboss:domain:resource-adapters:5.0"> <resource-adapters> <resource-adapter id="ra-with-elytron-security-domain"> <archive> ra-with-elytron-security-domain.rar </archive> <bootstrap-context>customContext</bootstrap-context> <transaction-support>NoTransaction</transaction-support> <workmanager> <security> <elytron-security-domain>wm-realm</elytron-security-domain> <default-principal>wm-default-principal</default-principal> <default-groups> <group> wm-default-group </group> </default-groups> </security> </workmanager> </resource-adapter> </resource-adapters> </subsystem>
예제: 보안 도메인 구성
/subsystem=elytron/properties-realm=wm-properties-realm:add(users-properties={path=/security-dir/users.properties, plain-text=true}, groups-properties={path=/security-dir/groups.properties}) /subsystem=elytron/simple-role-decoder=wm-role-decoder:add(attribute=groups) /subsystem=elytron/constant-permission-mapper=wm-permission-mapper:add(permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}]) /subsystem=elytron/security-domain=wm-realm:add(default-realm=wm-properties-realm, permission-mapper=wm-permission-mapper, realms=[{role-decoder=wm-role-decoder, realm=wm-properties-realm}])
Work
클래스는 지정된 도메인에서 Elytron 인증에 대한 자격 증명을 제공하는 역할을 담당합니다. 이를 위해 javax.resource.spi.work.WorkContextProvider
를 구현해야 합니다.
public interface WorkContextProvider { /** * Gets an instance of <code>WorkContexts</code> that needs to be used * by the <code>WorkManager</code> to set up the execution context while * executing a <code>Work</code> instance. * * @return an <code>List</code> of <code>WorkContext</code> instances. */ List<WorkContext> getWorkContexts(); }
이 인터페이스를 사용하면 Work
Context
를 사용하여 작업이 실행될 컨텍스트의 일부 측면을 구성할 수 있습니다. 이러한 측면 중 하나는 보안의 흐름입니다. 이를 위해 List<WorkContext> getWorkContexts
메서드에서 javax.resource.spi.work.SecurityContext
를 제공해야 합니다. 이 컨텍스트는 Jakarta Authentication에서 정의한 대로 javax.security.auth.callback.Callback
개체를 사용합니다. 사양에 대한 자세한 내용은 Jakarta Authentication specification 을 참조하십시오.
예제: 컨텍스트를 사용하여 콜백 생성
public class ExampleWork implements Work, WorkContextProvider { private final String username; private final String role; public MyWork(TestBean bean, String username, String role) { this.principals = null; this.roles = null; this.bean = bean; this.username = username; this.role = role; } public List<WorkContext> getWorkContexts() { List<WorkContext> l = new ArrayList<>(1); l.add(new MySecurityContext(username, role)); return l; } public void run() { ... } public void release() { ... } public class ExampleSecurityContext extends SecurityContext { public void setupSecurityContext(CallbackHandler handler, Subject executionSubject, Subject serviceSubject) { try { List<javax.security.auth.callback.Callback> cbs = new ArrayList<>(); cbs.add(new CallerPrincipalCallback(executionSubject, new SimplePrincipal(username))); cbs.add(new GroupPrincipalCallback(executionSubject, new String[]{role})); handler.handle(cbs.toArray(new javax.security.auth.callback.Callback[cbs.size()])); } catch (Throwable t) { throw new RuntimeException(t); } } }
위의 예에서 Example Work
는 ExampleSecurity
인터페이스를 구현합니다. 해당 컨텍스트는 작업 실행 시 Elytron에서 인증하는 보안 정보를 제공하는 데 필요한 콜백을 생성합니다.
Context를 제공하기 위해 WorkContext
Provider
16.4.4. IBM MQ 리소스 어댑터 배포 및 구성
IBM MQ 리소스 어댑터 배포 지침은 JBoss EAP용 메시징 구성에서 확인할 수 있습니다.
16.4.5. 일반 자카르타 메시징 리소스 어댑터 배포 및 구성
JBoss EAP에 대한 메시징 구성에서 일반 자카르타 메시징 리소스 어댑터 를 구성하는 방법을 확인할 수 있습니다.
16.5. 관리형 연결 풀 구성
JBoss EAP는 ManagedConnectionPool
인터페이스의 세 가지 구현을 제공합니다.
org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedQueueManagedConnectionPool
- JBoss EAP 7의 기본 연결 풀이며 즉시 사용 가능한 최상의 성능을 제공합니다.
org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool
- 이전 JBoss EAP 버전의 기본 연결 풀이었습니다.
org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool
- 이 연결 풀은 디버깅 목적으로만 사용되며 종료 시 또는 풀이 플러시될 때 누수를 보고합니다.
다음 관리 CLI 명령을 사용하여 데이터 소스에 대해 관리되는 연결 풀 구현을 설정할 수 있습니다.
/subsystem=datasources/data-source=DATA_SOURCE:write-attribute(name=mcp,value=MCP_CLASS)
다음 관리 CLI 명령을 사용하여 리소스 어댑터에 대해 관리되는 연결 풀 구현을 설정할 수 있습니다.
/subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:write-attribute(name=mcp,value=MCP_CLASS)
다음 관리 CLI 명령을 사용하여 메시징 서버에 대한 관리형 연결 풀 구현을 설정할 수 있습니다.
/subsystem=messaging-activemq/server=SERVER/pooled-connection-factory=CONNECTION_FACTORY:write-attribute(name=managed-connection-pool,value=MCP_CLASS)
16.6. 연결 통계 보기
/deployment=NAME.rar
하위 트리에서 정의된 연결에 대한 통계를 읽을 수 있습니다. 이는 standalone. xml 또는
구성에 정의되지 않은 경우에도 RAR의 통계에 액세스할 수 있습니다.
domain.xml
/deployment=NAME.rar/subsystem=resource-adapters/statistics=statistics/connection-definitions=java\:\/testMe:read-resource(include-runtime=true)
모든 통계는 런타임 전용 정보이므로 include-runtime=true
인수를 지정해야 합니다.
사용 가능한 통계에 대한 자세한 내용은 Resource Adapter Statistics 를 참조하십시오.
16.7. 리소스 어댑터 연결 플러시
다음 관리 CLI 명령을 사용하여 리소스 어댑터 연결을 플러시할 수 있습니다.
관리형 도메인에서 이러한 명령 앞에 /host=HOST_NAME /server=SERVER_NAME
을 사용해야 합니다.
풀의 모든 연결을 플러시합니다.
/subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:flush-all-connection-in-pool
풀의 모든 연결을 정상적으로 플러시합니다.
/subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:flush-gracefully-connection-in-pool
서버는 연결이 유휴 상태가 될 때까지 기다린 후 연결을 플러시합니다.
풀의 모든 유휴 연결을 플러시합니다.
/subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:flush-idle-connection-in-pool
풀에서 잘못된 모든 연결을 플러시합니다.
/subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:flush-invalid-connection-in-pool
서버에서 유효하지 않은 것으로 판단되는 모든 연결을 플러시합니다.
16.8. 리소스 어댑터 하위 시스템 튜닝
resource-adapters
하위 시스템의 성능 모니터링 및 최적화에 대한 팁은 성능 튜닝 가이드의 데이터 소스 및 리소스 어댑터 튜닝 섹션을 참조하십시오.
17장. 웹 서버 구성(Undertow)
17.1. Undertow 하위 시스템 개요
JBoss EAP 7에서 undertow
하위 시스템은 JBoss EAP 6에서 웹
하위 시스템을 사용합니다.
The undertow
하위 시스템을 사용하면 웹 서버 및 서블릿 컨테이너 설정을 구성할 수 있습니다. 자카르타 서블릿 4.0 사양과 웹 소켓을 구현합니다. 또한 HTTP 업그레이드를 지원하고 서블릿 배포에서 고성능 비차단 핸들러를 사용할 수 있습니다. 또한 The undertow
하위 시스템에는 mod_cluster를 지원하는 고성능 역방향 프록시 역할을 할 수 있습니다.
undertow
하위 시스템에는 다음 5가지 기본 구성 요소가 있습니다.
JBoss EAP는 이러한 각 구성 요소에 대한 구성을 업데이트하는 기능을 제공하지만 기본 구성은 대부분의 사용 사례에 적합하며 적절한 성능 설정을 제공합니다.
기본 Undertow 하위 시스템 구성
<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other"> <buffer-cache name="default"/> <server name="default-server"> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/> </host> </server> <servlet-container name="default"> <jsp-config/> <websockets/> </servlet-container> <handlers> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> </handlers> </subsystem>
또한 The undertow
하위 시스템은 XNIO 작업자 및 버퍼 풀을 제공하기 위해 the io
하위 시스템을 사용합니다. The io
하위 시스템은 별도로 구성되며 대부분의 경우 최적의 성능을 제공해야 하는 기본 구성을 제공합니다.
JBoss EAP 6의 웹
하위 시스템과 비교하여 JBoss EAP 7의 undertow
하위 시스템에는 HTTP 메서드의 다양한 기본 동작이 있습니다.
Undertow 하위 시스템과 함께 Elytron 사용
웹 애플리케이션이 배포되면 해당 애플리케이션에 필요한 보안 도메인의 이름이 식별됩니다. 이는 배포 내에서 발생하거나 배포에 보안 도메인이 없는 경우, the undertow
하위 시스템에 정의된 default-security-domain
을 가정합니다. 기본적으로 보안 도메인은 레거시 보안 하위 시스템에 정의된 PicketBox
에 매핑됩니다. 그러나 application-security-domain
리소스를 애플리케이션에 필요한 보안 도메인의 이름에서 적절한 Elytron 구성으로 매핑하는 undertow
하위 시스템에 추가할 수 있습니다.
예제: 매핑 추가.
/subsystem=undertow/application-security-domain=ApplicationDomain:add(security-domain=ApplicationDomain)
결과가 다음과 같은 경우 매핑이 성공적으로 추가됩니다.
<subsystem xmlns="urn:jboss:domain:undertow:10.0" ... default-security-domain="other"> ... <application-security-domains> <application-security-domain name="ApplicationDomain" security-domain="ApplicationDomain"/> </application-security-domains> ... </subsystem>
- 이 시점에 배포가 이미 배포된 경우 애플리케이션 보안 도메인 매핑을 적용하려면 애플리케이션 서버를 다시 로드해야 합니다.
- 현재 웹 서비스-Elytron 통합에서 웹 서비스 엔드포인트와 Elytron 보안 도메인 이름을 보호하기 위해 지정된 보안 도메인의 이름은 동일해야 합니다.
이 간단한 형식은 배포에서 BASIC
,CLIENT_CERT
,DIGEST
,FORM
과 같은 서블릿 사양에 정의된 표준 HTTP 메커니즘을 사용하는 경우에 적합합니다. 여기서는 ApplicationDomain
보안 도메인에 대해 인증이 수행됩니다. 이 형식은 애플리케이션이 인증 메커니즘을 사용하지 않고 프로그래밍 인증을 사용하거나 배포와 관련된 SecurityDomain
을 가져와 직접 사용하려는 경우에 적합합니다.
예제: 매핑의 고급 양식 :
/subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)
결과가 다음과 같은 경우 고급 매핑이 성공적으로 수행됩니다.
<subsystem xmlns="urn:jboss:domain:undertow:10.0" ... default-security-domain="other"> ... <application-security-domains> <application-security-domain name="MyAppSecurity" http-authentication-factory="application-http-authentication"/> </application-security-domains> ... </subsystem>
이 구성에서는 보안 도메인을 참조하지 않고 http-authentication-factory
를 참조합니다. 이 팩토리는 인증 메커니즘의 인스턴스를 가져오는 데 사용되며 보안 도메인과 차례로 연결됩니다.
사용자 지정 HTTP 인증 메커니즘을 사용하거나 주요 변환기, 자격 증명 팩토리 및 메커니즘 영역과 같은 메커니즘에 대해 추가 구성을 정의해야 하는 경우 http-authentication-factory
특성을 참조해야 합니다. 서블릿
사양에 설명된 4개가 아닌 메커니즘을 사용할 때 http-authentication-factory
속성을 참조하는 것이 더 좋습니다.
고급 매핑 형식을 사용하면 또 다른 구성 옵션인 override-deployment-config
를 사용할 수 있습니다. 참조된 http-authentication-factory
는 전체 인증 메커니즘 세트를 반환할 수 있습니다. 기본적으로 애플리케이션에서 요청한 메커니즘과 일치하도록 필터링됩니다. 이 옵션을 true
로 설정하면 팩토리에서 제공하는 메커니즘이 애플리케이션에서 요청한 메커니즘을 재정의합니다.
또한 application-security-domain
리소스에는 하나의 추가 옵션 enable-jacc
가 있습니다. true
로 설정된 경우 이 매핑과 일치하는 모든 배포에 대해 Jakarta Authorization Authorization이 활성화됩니다.
런타임 정보
application-security-domain
매핑이 사용 중인 경우 배포가 예상대로 일치하는지 다시 확인하는 것이 유용할 수 있습니다. include-runtime=true
로 리소스를 읽는 경우 매핑과 연결된 배포도 다음과 같이 표시됩니다.
/subsystem=undertow/application-security-domain=MyAppSecurity:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "enable-jacc" => false, "http-authentication-factory" => undefined, "override-deployment-config" => false, "referencing-deployments" => ["simple-webapp.war"], "security-domain" => "ApplicationDomain", "setting" => undefined } }
이 출력에서 referencing -deployments
특성은 매핑을 사용하여 배포 simple-webapp.war
가 배포되었음을 보여줍니다.
17.2. 버퍼 캐시 구성
버퍼 캐시는 정적 리소스를 캐시하는 데 사용됩니다. JBoss EAP를 사용하면 배포에서 여러 캐시를 구성하고 참조할 수 있으므로 다양한 배포에서 서로 다른 캐시 크기를 사용할 수 있습니다. 버퍼는 지역에 할당되며 크기가 고정되어 있습니다. 사용된 총 공간의 크기는 버퍼 크기와 영역당 버퍼 수에 최대 영역 수를 곱하여 계산할 수 있습니다. 버퍼 캐시의 기본 크기는 10MB입니다.
JBoss EAP는 기본적으로 단일 캐시를 제공합니다.
기본 Undertow 하위 시스템 구성
<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other"> <buffer-cache name="default"/> ... </subsystem>
기존 버퍼 캐시 업데이트
기존 버퍼 캐시를 업데이트하려면 다음을 수행합니다.
/subsystem=undertow/buffer-cache=default/:write-attribute(name=buffer-size,value=2048)
reload
새 버퍼 캐시 생성
새 버퍼 캐시를 생성하려면 다음을 수행합니다.
/subsystem=undertow/buffer-cache=new-buffer:add
버퍼 캐시 삭제
버퍼 캐시를 삭제하려면 다음을 수행합니다.
/subsystem=undertow/buffer-cache=new-buffer:remove
reload
버퍼 캐시 구성에 사용할 수 있는 속성의 전체 목록은 Undertow 하위 시스템 속성 섹션을 참조하십시오.
17.3. 바이트 버퍼 풀 구성
Undertow 바이트 버퍼 풀은 풀링된 NIO 바이트Buffer
인스턴스를 할당하는 데 사용됩니다. 모든 리스너에는 바이트 버퍼 풀이 있으며 각 리스너에 다른 버퍼 풀과 작업자를 사용할 수 있습니다. 바이트 버퍼 풀은 다른 서버 인스턴스 간에 공유할 수 있습니다.
이러한 버퍼는 IO 작업에 사용되며 버퍼 크기는 애플리케이션 성능에 큰 영향을 미칩니다. 대부분의 서버에서 이상적인 크기는 일반적으로 16k입니다.
기존 바이트 버퍼 풀 업데이트
기존 바이트 버퍼 풀을 업데이트하려면 다음을 수행합니다.
/subsystem=undertow/byte-buffer-pool=myByteBufferPool:write-attribute(name=buffer-size,value=1024)
reload
바이트 버퍼 풀 생성
새 바이트 버퍼 풀을 생성하려면 다음을 수행합니다.
/subsystem=undertow/byte-buffer-pool=newByteBufferPool:add
바이트 버퍼 풀 삭제
바이트 버퍼 풀을 삭제하려면 다음을 수행합니다.
/subsystem=undertow/byte-buffer-pool=newByteBufferPool:remove
reload
바이트 버퍼 풀 구성에 사용할 수 있는 속성의 전체 목록은 Byte 버퍼 풀 속성 참조를 참조하십시오.
17.4. 서버 구성
서버는 Undertow 인스턴스를 나타내며 다음과 같은 여러 요소로 구성됩니다.
- 호스트
- http-listener
- https-listener
- ajp-listener
호스트 요소는 가상 호스트 구성을 제공하지만 세 리스너는 해당 유형의 연결을 Undertow 인스턴스에 제공합니다.
서버의 기본 동작은 서버가 시작하는 동안 요청을 대기열에 추가하는 것입니다. 호스트에서 queue-requests-on-start
특성을 사용하여 기본 동작을 변경할 수 있습니다. 이 속성이 true
로 설정되면 기본값인 서버 시작 시 도착하는 요청이 서버가 준비될 때까지 유지됩니다. 이 특성이 false
로 설정되면 서버가 완전히 시작되기 전에 도착하는 요청이 기본 응답 코드와 함께 거부됩니다.
특성 값에 관계없이 서버가 완전히 시작될 때까지 요청 처리가 시작되지 않습니다.
Configuration → Subsystems → Web (Undertow) → Server 로 이동하여 관리 콘솔을 사용하여 queue-requests-on-start
속성을 구성하고 서버를 선택하고 View (보기) 를 클릭하고 Hosts (호스트) 탭을 선택하여 queue-requests-on-start 특성을 구성할 수 있습니다. 관리형 도메인의 경우 구성할 프로필을 지정해야 합니다.
배포와 서버를 완전히 격리할 수 있도록 여러 서버를 구성할 수 있습니다. 이 기능은 멀티 테넌트 환경과 같은 특정 시나리오에서 유용할 수 있습니다.
JBoss EAP는 기본적으로 서버를 제공합니다.
기본 Undertow 하위 시스템 구성
<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other"> <buffer-cache name="default"/> <server name="default-server"> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/> </host> </server> ... </subsystem>
다음 예제에서는 관리 CLI를 사용하여 서버를 구성하는 방법을 보여줍니다. Configuration → Subsystems → Web (Undertow) → Server 로 이동하여 관리 콘솔을 사용하여 서버를 구성할 수도 있습니다.
기존 서버 업데이트
기존 서버를 업데이트하려면 다음을 수행합니다.
/subsystem=undertow/server=default-server:write-attribute(name=default-host,value=default-host)
reload
새 서버 생성
새 서버를 생성하려면 다음을 수행합니다.
/subsystem=undertow/server=new-server:add
reload
서버 삭제
서버를 삭제하려면 다음을 수행합니다.
/subsystem=undertow/server=new-server:remove
reload
서버 구성에 사용할 수 있는 속성의 전체 목록은 Undertow 하위 시스템 속성 섹션을 참조하십시오.
17.4.1. 액세스 로깅
정의한 각 호스트에서 액세스 로깅을 구성할 수 있습니다.
액세스 로깅 옵션은 표준 액세스 로깅과 콘솔 액세스 로깅의 두 가지입니다.
액세스 로깅에 필요한 추가 처리는 시스템 성능에 영향을 미칠 수 있습니다.
17.4.1.1. 표준 액세스 로깅
표준 액세스 로깅은 로그 항목을 로그 파일에 씁니다.
기본적으로 로그 파일은 standalone/log/access_log.log 디렉터리에 저장됩니다.
표준 액세스 로깅을 활성화하려면 액세스 로그 데이터를 캡처할 호스트에 access-log 설정을 추가합니다. 다음 CLI 명령은 기본 JBoss EAP 서버의 기본 호스트에 대한 구성을 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add
표준 액세스 로깅을 활성화한 후 서버를 다시 로드해야 합니다.
기본적으로 액세스 로그 레코드에는 다음 데이터가 포함됩니다.
- 원격 호스트 이름
- 원격 논리적 사용자 이름 (항상 -)
- 인증된 원격 사용자
- 요청 날짜 및 시간 (Common Log Format)
- 요청의 첫 번째 줄
- 응답의 HTTP 상태 코드
- HTTP 헤더를 제외하고 전송된 바이트 수
이 데이터 집합은 공통 패턴으로 정의됩니다. 결합된 또 다른 패턴도 사용할 수 있습니다. 공통 패턴에 기록된 데이터 외에도 결합된 패턴에는 수신 헤더의 참조자 및 사용자 에이전트가 포함됩니다.
pattern
특성을 사용하여 기록된 데이터를 변경할 수 있습니다. 다음 CLI 명령은 결합된 패턴을 사용하도록 패턴
속성을 업데이트하는 방법을 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:write-attribute(name=pattern,value="combined"
패턴 특성을 업데이트한 후 서버를 다시 로드해야 합니다.
표 17.1. 사용 가능한 패턴
패턴 | 설명 |
---|---|
%a | 원격 IP 주소 |
%A | 로컬 IP 주소 |
%b |
HTTP 헤더를 제외하고 전송된 바이트 또는 바이트가 없는 경우 |
%B | HTTP 헤더를 제외하고 전송된 바이트 |
%h | 원격 호스트 이름 |
%H | 요청 프로토콜 |
%l |
원격 논리적 사용자 이름 from |
%m | 요청 방법 |
%p | 로컬 포트 |
%q |
쿼리 문자열 ( |
%r | 요청의 첫 번째 행 |
%s | 응답의 HTTP 상태 코드 |
%t | 날짜 및 시간(일반 로그 형식) |
%u | 인증된 원격 사용자 |
%U | 요청된 URL 경로 |
%v | 로컬 서버 이름 |
%D | 요청을 처리하는 데 걸린 시간(밀리초) |
%T | 요청을 처리하는 데 걸리는 시간(초) |
%I | 현재 요청 스레드 이름 (나중에 스택 추적과 비교할 수 있음) |
Common |
|
결합 |
|
쿠키, 수신 헤더 및 응답 헤더 또는 세션에서 정보를 작성할 수도 있습니다. 구문은 Apache 구문 다음에 모델링됩니다.
-
수신 헤더의
%{I,xxx}
-
나가는 응답 헤더의
%{O,xxx}
-
특정 쿠키를 위한
%{C,xxx}
-
%{R,xxx}
여기서xxx
는ServletRequest
의 속성입니다. -
%{s,xxx}
여기서xxx
는HttpSession
의 속성입니다.
이 로그에 추가 구성 옵션을 사용할 수 있습니다. 자세한 내용은 부록의 "access-log 속성"을 참조하십시오.
17.4.1.2. 콘솔 액세스 로깅
콘솔 액세스 로깅은 JSON 데이터로 구성된 stdout에 데이터를 씁니다.
각 액세스 로그 레코드는 한 줄의 데이터 행입니다. 로그 집계 시스템에서 처리하기 위해 이 데이터를 캡처할 수 있습니다.
콘솔 액세스 로깅을 구성하려면 액세스 로그 데이터를 캡처할 호스트에 console-access-log 설정을 추가합니다. 다음 CLI 명령은 기본 JBoss EAP 서버의 기본 호스트에 대한 구성을 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:add
기본적으로 콘솔 액세스 로그 레코드에는 다음 데이터가 포함됩니다.
표 17.2. 기본 콘솔 액세스 로그 데이터
로그 데이터 필드 이름 | 설명 |
---|---|
eventSource | 요청의 이벤트 소스 |
hostName | 요청을 처리하는 JBoss EAP 호스트 |
bytesSent | 요청에 대한 응답으로 전송된 JBoss EAP 서버의 바이트 수 |
dateTime | JBoss EAP 서버에서 요청을 처리한 날짜 및 시간 |
remoteHost | 요청이 시작된 머신의 IP 주소 |
remoteUser | 원격 요청과 관련된 사용자 이름 |
requestLine | 요청이 제출되었습니다 |
responseCode | JBoss EAP 서버에서 반환한 HTTP 응답 코드 |
기본 속성은 항상 로그 출력에 포함됩니다. attributes 속성을
사용하여 기본 로그 데이터의 레이블을 변경하고 경우에 따라 데이터 구성을 변경할 수 있습니다. attributes 속성을
사용하여 출력에 로그 데이터를 추가할 수도 있습니다.
표 17.3. 사용 가능한 콘솔 액세스 로그 데이터
로그 데이터 필드 이름 | 설명 | 형식 |
---|---|---|
authentication-type | 요청과 연결된 사용자를 인증하는 데 사용되는 인증 유형입니다. 기본 레이블: authenticationType 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | authentication-type{} authentication-type={key="authType"} |
bytes-sent | HTTP 헤더를 제외하고 요청에 반환된 바이트 수입니다. 기본 레이블: bytesSent 이 속성의 레이블을 변경하려면 키 옵션을 사용합니다. | bytes-sent={} bytes-sent={key="sent-bytes"} |
날짜-시간 | 요청이 수신 및 처리된 날짜 및 시간입니다. 기본 레이블: dateTime 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. date-format을 사용하여 날짜-시간 레코드를 포맷하는 데 사용되는 패턴을 정의합니다. 패턴은 Java SimpleDateFormatter 패턴이어야 합니다. time-zone 옵션을 사용하여 date-format 옵션이 정의된 경우 날짜 및/또는 시간 데이터를 포맷하는 데 사용되는 시간대를 지정합니다. 이 값은 유효한 java.util.TimeZone이어야 합니다. | date-time={key="<keyname>", date-format="<date-time format>"} date-time={key="@timestamp", date-format="yyy-MM-dd'T'HH:mm:ssSSS"} |
host-and-port | 요청에서 쿼리한 호스트 및 포트입니다. 기본 레이블: hostAndPort 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | host-and-port{} host-and-port={key="port-host"} |
local-ip | 로컬 연결의 IP 주소입니다. 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. 기본 레이블: localIp 이 속성의 레이블을 변경하려면 키 옵션을 사용합니다. | local-ip{} local-ip{key="localIP"} |
local-port | 로컬 연결의 포트입니다. 기본 레이블: localPort 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | local-port{} local-port{key="LocalPort"} |
local-server-name | 요청을 처리하는 로컬 서버의 이름입니다. 기본 레이블: localServerName 이 속성의 레이블을 변경하려면 키 옵션을 사용합니다. | local-server-name {} local-server-name {key=LocalServerName} |
path-parameter | 요청에 포함된 하나 이상의 경로 또는 URI 매개 변수. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. 키 접두사 속성을 사용하여 키를 고유하게 만듭니다. key-prefix를 지정하면 접두사가 출력의 각 경로 매개 변수 이름에 앞에 추가됩니다. | path-parameter{names={store,section}} path-parameter{names={stores}, key-prefix="my-"} |
서술자 | 서술자 컨텍스트의 이름입니다. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. 키 접두사 속성을 사용하여 키를 고유하게 만듭니다. key-prefix를 지정하면 접두사가 출력의 각 경로 매개 변수 이름에 앞에 추가됩니다. | predicate{names={store,section}} 서술자{names={store,section}, key-prefix="my-"} |
query-parameter | 요청에 포함된 하나 또는 쿼리 매개 변수. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. 키 접두사 속성을 사용하여 키를 고유하게 만듭니다. key-prefix를 지정하면 접두사가 출력의 각 경로 매개 변수 이름에 앞에 추가됩니다. | query-parameter{names={store,section}} query-parameter{names={store,section}, key-prefix="my-"} |
query-string | 요청의 쿼리 문자열입니다. 기본 레이블: queryString 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. include-question-mark 속성을 사용하여 쿼리 문자열에 물음표가 포함되어야 하는지 여부를 지정합니다. 기본적으로 물음표는 포함되지 않습니다. | query-string{} query-string{key="QueryString", include-question-mark="true"} |
relative-path | 요청의 상대 경로입니다. 기본 레이블: relativePath 이 속성의 레이블을 변경하려면 키 옵션을 사용합니다. | relative-path{} relative-path{key="RelativePath"} |
remote-host | 원격 호스트 이름입니다. 기본 레이블: remoteHost 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | remote-host{} remote-host{key=”RemoteHost”} |
remote-ip | 원격 IP 주소. 기본 레이블: remoteIp 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. 난독화된 속성을 사용하여 출력 로그 레코드의 IP 주소를 난독화합니다. 기본값은 false입니다. | remote-ip{} remote-ip{key="RemoteIP", obfuscated="true"} |
remote-user | 인증된 원격 사용자. 기본 레이블: remoteUser 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | remote-user{} remote-user{key="RemoteUser"} |
request-header | 요청 헤더의 이름입니다. 구조화된 데이터의 키는 헤더의 이름입니다. 값은 명명된 헤더의 값입니다. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. 키 접두사 속성을 사용하여 키를 고유하게 만듭니다. key-prefix를 지정하면 접두사가 로그 출력의 요청 헤더 이름에 앞에 추가됩니다. | request-header{names={store,section}} request-header{names={store,section}, key-prefix="my-"} |
request-line | 요청 행. 기본 레이블: requestline 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-line{} request-line{key="Request-Line"} |
request-method | 요청 메서드입니다. 기본 레이블: requestMethod 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-method{} request-method{key=”RequestMethod”} |
request-path | 요청의 상대 경로입니다. 기본 레이블: requestPath 이 속성의 레이블을 변경하려면 키 옵션을 사용합니다. | request-path{} request-path{key="RequestPath"} |
request-protocol | 요청의 프로토콜입니다. 기본 레이블: requestProtocol key 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-protocol{} request-protocol{key="RequestProtocol"} |
request-scheme | 요청의 URI 체계입니다. 기본 레이블: requestScheme 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-scheme{} request-scheme{key="RequestScheme"} |
request-url | 원래 요청 URI입니다. 클라이언트에 지정된 경우 호스트 이름, 프로토콜 등을 포함합니다. 기본 레이블: requestUrl 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-url{} request-url{key="RequestURL"} |
resolved-path | 해결된 경로입니다. 기본 Label: resolvedPath 이 속성의 레이블을 변경하려면 키 옵션을 사용합니다. | resolved-path{} resolve-path{key="ResolvedPath"} |
response-code | 응답 코드. 기본 레이블: responseCode 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | response-code{} response-code{key="Response Code"} |
response-header | 응답 헤더의 이름입니다. 구조화된 데이터의 키는 헤더의 이름입니다. 값은 명명된 헤더의 값입니다. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. 키 접두사 속성을 사용하여 키를 고유하게 만듭니다. key-prefix를 지정하면 접두사가 로그 출력의 요청 헤더 이름에 앞에 추가됩니다. | response-header{names={store,section}} response-header{names={store,section}, key-prefix=”my-”} |
response-reason-phrase | 응답 코드의 텍스트 이유. 기본 레이블: responseReasonPhrase 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | response-reason-phrase{} response-reason-phrase{key=”ResponseReasonPhrase”} |
response-time | 요청을 처리하는 데 사용되는 시간입니다. 기본 레이블: responseTime 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. 기본 시간 단위는 MILLISECONDS입니다. 사용 가능한 시간 단위는 다음과 같습니다. * NANOSECONDS * MICROSECONDS * MILLISECONDS * SECONDS | response-time{} response-time{key="ResponseTime", time-unit=SECONDS} |
secure-exchange | 교환이 안전한지 여부를 나타냅니다. 기본 레이블: secureExchange 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | secure-exchange{} secure-exchange{key=”SecureExchange”} |
SSL-cipher | 요청에 대한 SSL 암호입니다. 기본 레이블: sslCipher 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | SSL-cipher{} ssl-cipher{key="SSLCipher"} |
ssl-client-cert | 요청에 대한 SSL 클라이언트 인증서입니다. 기본 레이블: sslClientCert 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | ssl-client-cert{} ssl-client-cert{key=”SSLClientCert”} |
ssl-session-id | 요청의 SSL 세션 ID입니다. 기본 레이블: sslSessionId 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | ssl-session-id{} stored-response |
저장된 응답에서 요청에 대한 응답입니다. 기본 레이블: storedResponse 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | stored-response{} stored-response{key=”StoredResponse”} | thread-name |
현재 스레드의 스레드 이름입니다. 기본 레이블: threadName 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | thread-name{} thread-name{key=”ThreadName”} | transport-protocol |
metadata
특성을 사용하여 액세스 로그 레코드에 포함되도록 추가 임의 데이터를 구성할 수 있습니다. metadata
속성의 값은 액세스 로그 레코드에 포함할 데이터를 정의하는 key:value 쌍의 집합입니다. 쌍의 값은 관리 모델 표현식일 수 있습니다. 관리 모델 표현식은 서버를 시작하거나 다시 로드할 때 해결됩니다. 키-값 쌍은 쉼표로 구분됩니다.
다음 CLI 명령은 추가 로그 데이터, 로그 데이터의 사용자 지정 및 추가 메타데이터를 포함하여 복잡한 콘솔 로그 구성의 예를 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:add(metadata={"@version"="1", "qualifiedHostName"=${jboss.qualified.host.name:unknown}}, attributes={bytes-sent={}, date-time={key="@timestamp", date-format="yyyy-MM-dd'T'HH:mm:ssSSS"}, remote-host={}, request-line={}, response-header={key-prefix="responseHeader", names=["Content-Type"]}, response-code={}, remote-user={}})
결과 액세스 로그 레코드는 다음과 같은 추가 JSON 데이터와 유사합니다. 참고: 아래 예제 출력은 가독성을 위해 포맷됩니다. 실제 레코드에서는 모든 데이터가 한 줄로 출력됩니다.
{ "eventSource":"web-access", "hostName":"default-host", "@version":"1", "qualifiedHostName":"localhost.localdomain", "bytesSent":1504, "@timestamp":"2019-05-02T11:57:37123", "remoteHost":"127.0.0.1", "remoteUser":null, "requestLine":"GET / HTTP/2.0", "responseCode":200, "responseHeaderContent-Type":"text/html" }
다음 명령은 콘솔 액세스 로그를 활성화한 후 로그 데이터에 대한 업데이트를 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:write-attribute(name=attributes,value={bytes-sent={}, date-time={key="@timestamp", date-format="yyyy-MM-dd'T'HH:mm:ssSSS"}, remote-host={}, request-line={}, response-header={key-prefix="responseHeader", names=["Content-Type"]}, response-code={}, remote-user={}})
다음 명령은 콘솔 액세스 로그를 활성화한 후 사용자 정의 메타데이터에 대한 업데이트를 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:write-attribute(name=metadata,value={"@version"="1", "qualifiedHostName"=${jboss.qualified.host.name:unknown}})
17.5. 서블릿 컨테이너 구성
서블릿 컨테이너는 세션 관련 구성을 포함하여 모든 서블릿, 자카르타 서버 페이지 및 웹 소켓 관련 구성을 제공합니다. 대부분의 서버에는 단일 서블릿 컨테이너만 필요하지만 servlet -container 요소를 추가하여 여러 개의 서블릿
컨테이너를 구성할 수 있습니다. 여러 서블릿 컨테이너가 있으면 여러 배포를 여러 가상 호스트에서 동일한 컨텍스트 경로에 배포할 수 있습니다.
servlet 컨테이너에서 제공하는 대부분의 구성은 web.xml
파일을 사용하여 배포된 애플리케이션에서 개별적으로 재정의할 수 있습니다.
JBoss EAP는 기본적으로 서블릿 컨테이너를 제공합니다.
기본 Undertow 하위 시스템 구성
<subsystem xmlns="urn:jboss:domain:undertow:10.0"> <buffer-cache name="default"/> <server name="default-server"> ... </server> <servlet-container name="default"> <jsp-config/> <websockets/> </servlet-container> ... </subsystem>
다음 예제에서는 관리 CLI를 사용하여 servlet 컨테이너를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 웹(Undertow) → 서블릿 컨테이너로 이동하여 관리 콘솔을 사용하여 서블릿 컨테이너를 구성할 수도 있습니다.
기존 서블릿 컨테이너 업데이트
기존 서블릿 컨테이너를 업데이트하려면 다음을 수행합니다.
/subsystem=undertow/servlet-container=default:write-attribute(name=ignore-flush,value=true)
reload
새 서블릿 컨테이너 생성
새 서블릿 컨테이너를 생성하려면 다음을 수행합니다.
/subsystem=undertow/servlet-container=new-servlet-container:add
reload
서블릿 컨테이너 삭제
서블릿 컨테이너를 삭제하려면 다음을 수행합니다.
/subsystem=undertow/servlet-container=new-servlet-container:remove
reload
서블릿 컨테이너 구성에 사용할 수 있는 속성의 전체 목록은 Undertow 하위 시스템 속성 섹션을 참조하십시오.
17.6. 서블릿 확장 구성
서블릿 확장을 사용하면 서블릿 배포 프로세스에 후크하고 서블릿 배포 측면을 수정할 수 있습니다. 이는 배포에 인증 메커니즘을 추가하거나 서블릿 배포의 일부로 기본 Undertow 핸들러를 사용해야 하는 경우에 유용합니다.
사용자 지정 서블릿 확장을 생성하려면 배포에서 the io.undertow.servlet.ServletExtension
인터페이스를 구현한 다음 구현 클래스의 이름을 META-INF/services/io.undertow.servlet.ServletExtension
파일에 추가해야 합니다. 또한 ServletExtension
구현의 컴파일된 클래스 파일도 포함해야 합니다. Undertow가 서블릿을 배포할 때 deployments
클래스 로더에서 모든 서비스를 로드한 다음 handleDeployment
메서드를 호출합니다.
배포에 대한 완전하고 변경 가능한 설명이 포함된 Undertow DeploymentInfo
구조가 이 메서드로 전달됩니다. 이 구조를 수정하여 배포의 측면을 변경할 수 있습니다.
DeploymentInfo
구조는 포함된 API에서 사용하는 구조와 동일하므로 서블릿Extension
은 임베디드 모드에서 Undertow를 사용할 때 보유하는 것과 동일한 양의 유연성을 갖습니다.
17.7. 핸들러 구성
JBoss EAP를 사용하면 다음 두 가지 유형의 핸들러를 구성할 수 있습니다.
- 파일 핸들러
- reverse-proxy 핸들러
파일 핸들러는 정적 파일을 제공합니다. 각 파일 핸들러는 가상 호스트의 위치에 연결해야 합니다. 역방향 프록시 핸들러를 사용하면 JBoss EAP가 고성능 역방향 프록시 역할을 할 수 있습니다.
JBoss EAP는 기본적으로 파일 핸들러를 제공합니다.
기본 Undertow 하위 시스템 구성
<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other"> <buffer-cache name="default"/> <server name="default-server"> ... </server> <servlet-container name="default"> ... </servlet-container> <handlers> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> </handlers> </subsystem>
정적 리소스에 WebDAV 사용
이전 버전의 JBoss EAP는 WebdavServlet
을 통해 웹
하위 시스템과 함께 WebDAV를 사용하여 정적 리소스를 호스트하고 추가 HTTP 메서드를 활성화하여 해당 파일에 액세스하고 조작할 수 있게 되었습니다. JBoss EAP 7에서 undertow
하위 시스템은 파일 핸들러를 사용하여 정적 파일을 제공하는 메커니즘을 제공하지만 undertow
하위 시스템은 WebDAV를 지원하지 않습니다. JBoss EAP 7에서 WebDAV를 사용하려면 사용자 지정 WebDAV 서블릿을 작성할 수 있습니다.
기존 파일 핸들러 업데이트
기존 파일 핸들러를 업데이트하려면 다음을 수행합니다.
/subsystem=undertow/configuration=handler/file=welcome-content:write-attribute(name=case-sensitive,value=true)
reload
새 파일 핸들러 생성
새 파일 핸들러를 생성하려면 다음을 수행합니다.
/subsystem=undertow/configuration=handler/file=new-file-handler:add(path="${jboss.home.dir}/welcome-content")
디렉터리 대신 파일 핸들러의 경로를
직접 설정하는 경우 해당 파일 핸들러를 참조하는 모든 위치
요소는 슬래시(/
)로 끝나서는 안 됩니다. 그렇지 않으면 서버에서 404 - 찾을 수 없음
응답을 반환합니다.
파일 핸들러 삭제
파일 핸들러 삭제
/subsystem=undertow/configuration=handler/file=new-file-handler:remove
reload
핸들러 구성에 사용할 수 있는 속성의 전체 목록은 Undertow 하위 시스템 속성 섹션을 참조하십시오.
17.8. 필터 구성
필터를 사용하면 요청의 일부 측면을 수정할 수 있으며 서술자를 사용하여 필터 실행 시기를 제어할 수 있습니다. 필터의 몇 가지 일반적인 사용 사례에는 헤더 설정 또는 GZIP 압축이 포함됩니다.
필터는 JBoss EAP 6에서 사용된 전역 값과 기능적으로 동일합니다.
다음 유형의 필터를 정의할 수 있습니다.
- custom-filter
- error-page
- expression-filter
- gzip
- MOD-cluster
- request-limit
- response-header
- 재작성
다음 예제에서는 관리 CLI를 사용하여 필터를 구성하는 방법을 보여줍니다. Configuration → Subsystems → Web (Undertow) → Filters 로 이동하여 관리 콘솔을 사용하여 필터를 구성할 수도 있습니다.
기존 필터 업데이트
기존 필터를 업데이트하려면 다음을 수행합니다.
/subsystem=undertow/configuration=filter/response-header=myHeader:write-attribute(name=header-value,value="JBoss-EAP")
reload
새 필터 생성
새 필터를 생성하려면 다음을 수행합니다.
/subsystem=undertow/configuration=filter/response-header=new-response-header:add(header-name=new-response-header,header-value="My Value")
필터 삭제
필터를 삭제하려면 다음을 수행합니다.
/subsystem=undertow/configuration=filter/response-header=new-response-header:remove
reload
필터 구성에 사용할 수 있는 속성의 전체 목록은 Undertow 하위 시스템 속성 섹션을 참조하십시오.
17.8.1. buffer-request Handler 구성
클라이언트 또는 브라우저의 요청은 헤더와 본문의 두 부분으로 구성됩니다. 일반적인 경우에는 헤더와 본문이 서로 지연되지 않고 JBoss EAP로 전송됩니다. 그러나 헤더가 먼저 전송되고 몇 초 후에 본문이 전송되면 전체 요청을 보내는 지연이 있습니다. 이 시나리오에서는 JBoss EAP에 전체 요청을 실행하기 위해 대기
중으로 표시되는 스레드를 생성합니다.
헤더 전송에 따른 지연과 요청 본문은 buffer-request
핸들러를 사용하여 수정할 수 있습니다. buffer-request
핸들러는 작업자 스레드에 할당하기 전에 차단되지 않은 IO 스레드에서 요청을 사용하려고 합니다. buffer-request
핸들러가 추가되지 않으면 작업자 스레드에 스레드 할당이 직접 수행됩니다. 그러나 buffer-request
핸들러가 추가되면 핸들러는 작업자 스레드에 할당하기 전에 IO 스레드를 사용하여 차단되지 않는 방식으로 버퍼할 수 있는 데이터 양을 읽습니다.
다음 관리 CLI 명령을 사용하여 buffer-request
핸들러를 구성할 수 있습니다.
/subsystem=undertow/configuration=filter/expression-filter=buf:add(expression="buffer-request(buffers=1)") /subsystem=undertow/server=default-server/host=default-host/filter-ref=buf:add
처리할 수 있는 버퍼 요청 크기에 제한이 있습니다. 이 제한은 아래 식과 같이 버퍼 크기와 총 버퍼 수의 조합으로 결정됩니다.
total_size = num_buffers buffer_size
위의 식에서 다음을 수행합니다.
-
Total_size
는 요청이 작업자 스레드로 디스패치되기 전에 버퍼링되는 데이터 크기입니다. -
num_buffers
는 버퍼 수입니다. 버퍼 수는 핸들러의buffers
매개 변수로 설정합니다. -
buffer_size
는 각 버퍼의 크기입니다. 버퍼 크기는 theio
하위 시스템에서 설정되며 요청당 기본적으로 16KB입니다.
버퍼가 많은 요청을 구성하지 않거나 메모리가 부족할 수 있습니다.
17.8.2. SameSite
특성 구성
동일한 사이트 내에서 쿠키 액세스 여부에 관계없이 SameSite
특성을 사용하여 쿠키의 접근성을 정의합니다. 이 속성은 브라우저가 교차 사이트 요청으로 쿠키를 보내지 않기 때문에 사이트 간 위조 공격을 방지합니다.
undertow
하위 시스템에서 SameSite
CookieHandler를 사용하여 쿠키의 SameSite
속성을 구성할 수 있습니다. 이 구성을 사용하면 애플리케이션 코드를 변경할 필요가 없습니다.
다음 표에는 SameSiteCookieHandler
매개변수 세부 정보가 포함되어 있습니다.
표 17.4. SameSiteCookieHandler 매개변수
매개변수 이름 | presence | 설명 |
---|---|---|
| 선택 사항 |
이 매개 변수는 |
| 선택 사항 |
이 매개변수는 |
| 선택 사항 |
이 매개변수는 쿠키 이름에 대한 regex 패턴을 허용합니다. 이 매개변수를 지정하지 않으면 |
| 선택 사항 |
이 매개변수는 클라이언트 애플리케이션이
이 기본값을 사용하고
호환되지 않는 클라이언트 문제를 방지하기 위해 이 매개변수는 |
| 필수 |
이 매개 변수는
교차 사이트 요청 위조 공격에 대한 보안을 개선하기 위해 일부 브라우저에서는 기본 |
SameSiteCookieHandler
는 쿠키 패턴과 일치하는 쿠키 또는
> 속성을 추가합니다. cookie
-pattern
이 지정되지 않은 경우 모든 쿠키에 SameSite= <specified-modeSameSite= <specified-mode
> 속성에는 < specified-mode>인 사용자 대체 변수가 포함되어 있습니다
. cookie-pattern
은 대소문자를 구분합니다
.
브라우저에 대해 SameSite
속성을 구성하기 전에 다음 사항을 고려하십시오.
-
애플리케이션에 따라
SameSite
속성이 필요한지 여부를 확인하고 해당 쿠키를 보호해야 하는지 확인합니다. -
모든 쿠키에서
SameSite
특성 모드를None
으로 설정하면 애플리케이션이 공격에 더 취약합니다.
expression-filter를 사용하여 SameSiteCookieHandler를 구성하는 절차
expression-filter
를 사용하여 서버에서 SameSiteCookieHandler
를 구성하려면 다음 단계를 수행합니다.
다음 명령을 사용하여
SameSiteCookieHandler
를 사용하여 새표현식-filter
를 만듭니다./subsystem=undertow/configuration=filter/expression-filter=addSameSiteLax:add(expression="path-prefix('/mypathprefix') -> samesite-cookie(Lax)")
다음 명령을 사용하여
undertow
웹 서버에서expression-filter
를 활성화합니다./subsystem=undertow/server=default-server/host=default-host/filter-ref=addSameSiteLax:add
구성 파일을 추가하여 SameSiteCookieHandler를 구성하는 절차
undertow-handlers.conf
파일을 추가하여 애플리케이션에 SameSiteCookieHandler
를 구성하려면 다음 단계를 수행합니다.
-
WAR의 article-INF 디렉터리에
undertow-handlers.conf
파일을 추가합니다. undertow-handlers.conf
파일에서 특정SameSiteCookieHandler
매개변수를 사용하여 다음 명령을 추가합니다.samesite-cookie(mode=<mode>)
mode
매개변수의 유효한 값은Strict
,Lax
또는None
입니다. 위의 명령을 사용하면cookie-pattern
,case-sensitive
,enable-client-checker
또는add-secure-for-none
과 같은 다른SameSiteCookieHandler
매개변수를 구성할 수도 있습니다.
17.9. 기본 시작 웹 애플리케이션 설정
JBoss EAP에는 기본적으로 포트 8080
의 루트 컨텍스트에 표시되는 기본 Welcome
애플리케이션이 포함되어 있습니다.
Undertow에 시작 콘텐츠를 제공하는 기본 서버가 사전 구성되어 있습니다.
기본 Undertow 하위 시스템 구성
<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other"> ... <server name="default-server"> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/> </host> </server> ... <handlers> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> </handlers> </subsystem>
기본 서버 default-server
에는 기본 호스트인 default-host
가 구성되어 있습니다. 기본 호스트는 welcome-content
파일 핸들러와 함께 <location>
요소를 사용하여 서버의 루트에 대한 요청을 처리하도록 구성됩니다. welcome-content
핸들러는 path
속성에 지정된 위치에 있는 콘텐츠를 제공합니다.
이 기본 Welcome
애플리케이션은 자체 웹 애플리케이션으로 교체할 수 있습니다. 다음 두 가지 방법 중 하나로 구성할 수 있습니다.
welcome-content 파일 핸들러 변경
기존
welcome-content
파일 핸들러의 경로를 새 배포를 가리키도록 수정합니다./subsystem=undertow/configuration=handler/file=welcome-content:write-attribute(name=path,value="/path/to/content")
참고또는 서버의 루트에서 사용할 다른 파일 핸들러를 생성할 수도 있습니다.
/subsystem=undertow/configuration=handler/file=NEW_FILE_HANDLER:add(path="/path/to/content") /subsystem=undertow/server=default-server/host=default-host/location=\/:write-attribute(name=handler,value=NEW_FILE_HANDLER)
변경 사항을 적용하려면 서버를 다시 로드합니다.
reload
default-web-module 변경
배포된 웹 애플리케이션을 서버의 루트에 매핑합니다.
/subsystem=undertow/server=default-server/host=default-host:write-attribute(name=default-web-module,value=hello.war)
변경 사항을 적용하려면 서버를 다시 로드합니다.
reload
기본 시작 웹 애플리케이션 비활성화
default-host
의위치
항목/
를 제거하여 시작 애플리케이션을 비활성화합니다./subsystem=undertow/server=default-server/host=default-host/location=\/:remove
변경 사항을 적용하려면 서버를 다시 로드합니다.
reload
17.10. HTTPS 구성
웹 애플리케이션의 HTTPS 구성에 대한 자세한 내용은 서버 보안 구성 방법의 일방향 및 양방향 SSL/TLS 구성을 참조하십시오.
JBoss EAP 관리 인터페이스와 함께 사용하기 위해 HTTPS를 구성하는 방법에 대한 자세한 내용은 서버 보안 구성 방법에서 관리 인터페이스를 보호하는 방법을 참조하십시오.
17.11. HTTP 세션 시간 제한 구성
HTTP 세션 시간 초과는 HTTP 세션을 유효하지 않은 선언하는 데 필요한 비활성 시간을 정의합니다. 예를 들어 사용자는 HTTP 세션을 생성하는 JBoss EAP에 배포된 애플리케이션에 액세스합니다. 그런 다음 해당 사용자가 HTTP 세션 시간 초과 후 해당 애플리케이션에 다시 액세스를 시도하면 원래 HTTP 세션이 무효화되고 사용자가 새 HTTP 세션을 생성해야 합니다. 이로 인해 비영구적 데이터가 손실되거나 사용자가 다시 인증해야 할 수 있습니다.
HTTP 세션 시간 제한은 애플리케이션의 web.xml
파일에서 구성되지만 JBoss EAP 내에서 기본 HTTP 세션 시간 초과를 지정할 수 있습니다. 서버의 시간 제한 값은 배포된 모든 애플리케이션에 적용되지만 애플리케이션의 web.xml
은 서버의 값을 재정의합니다.
server 값은 undertow
하위 시스템의 servlet
속성에 지정됩니다. -container 섹션에 있는 default-session-
timeoutdefault-session-timeout
의 값은 분 단위로 지정되고 기본값은 30
입니다.
기본 세션 시간 제한 구성
default-session-timeout
을 구성하려면 다음을 수행합니다.
/subsystem=undertow/servlet-container=default:write-attribute(name=default-session-timeout, value=60)
reload
17.12. HTTP 전용 세션 관리 구성
세션 관리 쿠키는 HTTP API 및 JavaScript와 같은 비HTTP API를 통해 액세스할 수 있습니다. JBoss EAP는 Set-Cookie
응답 헤더의 일부로 HttpOnly
헤더를 클라이언트(일반적으로 브라우저)로 보내는 기능을 제공합니다. 지원되는 브라우저에서 이 헤더를 활성화하면 비HTTP API를 통해 세션 관리 쿠키에 액세스하는 것을 브라우저에 알립니다. 세션 관리 쿠키를 HTTP API로만 제한하면 교차 사이트 스크립팅 공격을 통해 세션 쿠키 도난의 위협을 완화할 수 있습니다. 이 동작을 활성화하려면 http-only
특성을 true
로 설정해야 합니다.
HttpOnly
헤더를 사용하면 실제로 사이트 간 스크립팅 공격 자체를 방지할 수 없으며 브라우저에게 알립니다. 또한 브라우저는 이 동작을 적용하려면 HttpOnly
를 지원해야 합니다.
http-only
특성을 사용하면 세션 관리 쿠키에만 제한이 적용되고 다른 브라우저 쿠키에는 적용되지 않습니다.
http-only
특성은 undertow
하위 시스템의 두 위치에 설정됩니다.
- 서블릿 컨테이너에서 세션 쿠키 설정으로
- Single Sign-On 속성으로 서버의 호스트 섹션에서
서블릿 컨테이너 세션에 대한 호스트 전용
구성
서블릿 컨테이너 세션 쿠키에 대한 호스트 전용
속성을 구성하려면 다음을 수행합니다.
/subsystem=undertow/servlet-container=default/setting=session-cookie:add
/subsystem=undertow/servlet-container=default/setting=session-cookie:write-attribute(name=http-only,value=true)
reload
호스트 SSO(Single Sign-On)에 대한 호스트 전용
구성
호스트 SSO(Single Sign-On)에 대한 호스트 전용
속성을 구성하려면 다음을 수행합니다.
/subsystem=undertow/server=default-server/host=default-host/setting=single-sign-on:add
/subsystem=undertow/server=default-server/host=default-host/setting=single-sign-on:write-attribute(name=http-only,value=true)
reload
17.13. HTTP/2 구성
Undertow를 사용하면 HTTP/2 표준을 사용할 수 있으므로, 동일한 TCP 연결을 통해 헤더를 압축하고 많은 스트림을 멀티플렉싱하여 대기 시간을 줄일 수 있습니다. 또한 서버가 요청을 받기 전에 클라이언트에 리소스를 내보내면 페이지 로드 속도가 빨라집니다.
HTTP/2는 HTTP/2 표준도 지원하는 클라이언트 및 브라우저에서만 작동합니다.
대부분의 최신 브라우저는 h2라는 보안 TLS 연결에 HTTP/2를 적용하며,
라고 하는 일반 HTTP에서 HTTP/2를 지원하지 않을 수 있습니다. HTTPS를 사용하지 않고 HTTP 업그레이드를 사용하는 일반 HTTP만 사용하지 않고 h2
ch2c
에서 HTTP/2를 사용하도록 JBoss EAP를 구성할 수 있습니다. 이 경우 HTTP 리스너 Undertow에서 HTTP/2를 활성화할 수 있습니다.
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=enable-http2,value=true)
HTTP/2를 사용하도록 Undertow를 구성하려면 enable-http2
특성을 true
로 설정하여 Undertow에서 HTTPS 리스너가 HTTP/2를 사용하도록 설정합니다.
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=true)
웹 애플리케이션에 HTTPS 리스너를 사용하도록 HTTPS 리스너 및 Undertow 구성에 대한 자세한 내용은 How to Configure One-way and Two-way SSL/TLS for Applications 를 참조하십시오.
elytron
하위 시스템과 함께 HTTP/2를 사용하려면 Undertow의 https-listener
에 구성된 ssl-context
가 수정 가능으로 구성되어 있는지 확인해야 합니다. 이는 적절한 server-ssl-context
의 wrap
속성을 false로
설정하여 수행할 수 있습니다. 기본적으로 wrap
특성은 false
로 설정됩니다. Undertow는 ALPN에 관한 ssl-context
에서 수정하는 데 필요합니다. 제공된 ssl-context
에 쓸 수 없는 경우 ALPN을 사용할 수 없으며 연결이 HTTP/1.1로 대체됩니다.
HTTP/2 사용 시 ALPN 지원
보안 TLS 연결에서 HTTP/2를 사용하는 경우 ALPN TLS 프로토콜 확장을 지원하는 TLS 스택이 필요합니다. 이 스택을 가져오는 것은 설치된 JDK에 따라 다릅니다.
- Java 8을 사용하는 경우 ALPN 구현은 Java 내부의 종속성과 함께 JBoss EAP에 직접 도입됩니다. 따라서 이 ALPN 구현은 Oracle 및 OpenJDK에서만 작동합니다. IBM Java에서는 작동하지 않습니다. Red Hat은 ALPN 기능을 구현하는 OpenSSL 라이브러리를 사용하여 JBoss EAP의 OpenSSL 공급자로부터 ALPN TLS 프로토콜 확장 지원을 활용할 것을 강력히 권장합니다. OpenSSL 공급자의 ALPN TLS 프로토콜 확장 지원을 사용하면 성능이 향상되어야 합니다.
- Java 9부터 JDK는 기본적으로 ALPN을 지원합니다. 그러나 OpenSSL 공급자의 ALPN TLS 프로토콜 확장 지원을 사용하면 Java 9 이상을 사용할 때 성능이 향상되어야 합니다.
ALPN TLS 프로토콜 확장 지원을 받기 위해 OpenSSL을 설치하는 방법은 JBoss Core Services에서 Install OpenSSL에서 확인할 수 있습니다. 표준 시스템 OpenSSL은 Red Hat Enterprise Linux 8에서 지원되며 추가 JBoss Core Services OpenSSL은 필요하지 않습니다.
OpenSSL이 설치되면 Configure JBoss EAP to use OpenSSL 의 지침을 따르십시오.
HTTP/2가 사용 중인지 확인
Undertow가 HTTP/2를 사용하는지 확인하려면 Undertow에서 들어오는 헤더를 검사해야 합니다. https(예: https://localhost:8443) 를 사용하여 JBoss EAP 인스턴스로 이동하고 브라우저의 개발자 도구를 사용하여 헤더를 검사합니다. 일부 브라우저(예: Google Chrome)는 HTTP/2를 사용할 때 :path, :
authority, :
method 및 :
scheme
와 같은 HTTP/2 의사 헤더를 표시합니다. 기타 브라우저(예: Firefox 및 Safari)는 헤더의 상태 또는 버전을 HTTP/2.0
으로 보고합니다.
17.14. RequestDumping Handler 구성
RequestDumping
핸들러인 io.undertow.server.handlers.RequestDumpingHandler
는 JBoss EAP 내에서 Undertow에서 처리하는 요청 및 해당 응답 개체의 세부 정보를 기록합니다.
이 핸들러는 디버깅에 유용할 수 있지만 중요한 정보를 기록할 수도 있습니다. 이 핸들러를 활성화할 때 유의하십시오.
RequestDumping
핸들러가 JBoss EAP 6에서 RequestDumperValve
를 대체합니다.
JBoss EAP에서 직접 서버 수준 또는 개별 애플리케이션 내에서 RequestDumping
핸들러를 구성할 수 있습니다.
17.14.1. 서버에서 RequestDumping Handler 구성
RequestDumping
핸들러는 표현식 필터로 구성해야 합니다. RequestDumping
핸들러를 표현식 필터로 구성하려면 다음을 수행해야 합니다.
RequestDumping
Handler를 사용하여 새 표현식 필터 만들기
/subsystem=undertow/configuration=filter/expression-filter=requestDumperExpression:add(expression="dump-request")
Undertow 웹 서버에서 표현식 필터 활성화
/subsystem=undertow/server=default-server/host=default-host/filter-ref=requestDumperExpression:add
이러한 방식으로 RequestDumping
핸들러를 표현식 필터로 활성화하면 Undertow 웹 서버에서 처리하는 모든 요청 및 해당 응답이 기록됩니다.
특정 URL에 대한 RequestDumping Handler 구성
모든 요청을 기록하는 것 외에도 표현식 필터를 사용하여 특정 URL에 대한 요청 및 해당 응답만 로깅할 수 있습니다. 이 작업은 경로, 경로 접두사
또는
경로접미사와 같은 표현식에 서술자를 사용하여 수행할 수 있습니다
. 예를 들어 /myApplication/test
에 모든 요청과 해당 응답을 로깅하려면 표현식 필터를 생성할 때 "
표현식을 사용할 수 있습니다. 이는 dump-request" 표현식 대신 "path(/myApplication/test) dump-request"
/myApplication/test
와 정확히 일치하는 경로가 있는 요청만 RequestDumping
핸들러에 직접 보냅니다.
17.14.2. 애플리케이션 내에서 RequestDumping Handler 구성
서버에서 RequestDumping
핸들러를 구성하는 것 외에도 개별 애플리케이션 내에서 구성할 수도 있습니다. 이렇게 하면 핸들러의 범위가 특정 애플리케이션으로만 제한됩니다. RequestDumping
핸들러는 WEB-INF/undertow-handlers.conf
에서 구성해야 합니다.
WEB-INF/undertow-handlers.conf
에서 RequestDumping
핸들러를 구성하여 이 애플리케이션에 대한 모든 요청 및 해당 응답을 기록하려면 WEB-INF/undertow-handlers.conf에 다음 표현식을 추가합니다.
예제: WEB-INF/undertow-handlers.conf
dump-request
WEB-INF/undertow-handlers.conf
에서 RequestDumping
핸들러를 구성하여 이 애플리케이션 내의 특정 URL에 대한 요청 및 해당 응답만 기록하려면 경로, 경로 접두사또는
경로
접미사와 같은 표현식에 서술자를 사용할 수 있습니다.
예를 들어 애플리케이션에서 테스트할
모든 요청 및 해당 응답을 기록하려면 경로
서술자를 사용하여 다음 표현식을 사용할 수 있습니다.
예제: WEB-INF/undertow-handlers.conf
path(/test) -> dump-request
애플리케이션의 WEB-INF/undertow
접미사와 같은 서술자를 사용하는 경우 사용되는 값은 애플리케이션의 컨텍스트 루트에 상대적입니다. 예를 들어 애플리케이션의 컨텍스트 루트가 표현식 -
handlers.conf
에 정의된 표현식 에서 경로,
경로 접두사 또는 경로경로(/test) dump-request가
에 구성된 WEB-INF/undertow-
handlers.confmyApplication
인 경우 /myApplication/test
에 요청 및 해당 응답만 기록합니다.
17.15. 포트 보안 구성
secure-cookie
핸들러를 사용하여 서버와 클라이언트 간의 연결을 통해 생성된 쿠키의 보안을 강화할 수 있습니다. 이 경우 쿠키를 통한 연결이 안전한 것으로 표시되면 쿠키에 보안 특성이
true
로 설정됩니다.
리스너를 구성하거나 HTTPS를 사용하여 연결을 보호할 수 있습니다. undertow 하위 시스템에서
expression
핸들러를 구성합니다. 자세한 내용은 필터 구성을 참조하십시오.
-filter를 정의하여 secure-
cookie
secure-cookie
핸들러가 사용 중인 경우 보안 연결을 통해 설정된 쿠키가 보안으로 암시적으로 설정되며 비보안 연결을 통해 전송되지 않습니다.
17.16. Undertow 하위 시스템 조정
undertow
하위 시스템의 성능 최적화에 대한 팁은 성능 튜닝 가이드의 Undertow 하위 시스템 튜닝 섹션을 참조하십시오.
18장. Remoting 구성
18.1. 원격 하위 시스템 정보
원격
하위 시스템을 사용하면 로컬 및 원격 서비스에 대한 인바운드 및 아웃바운드 연결을 구성하고 해당 연결에 대한 설정을 구성할 수 있습니다.
JBoss Remoting 프로젝트에는 끝점, 커넥터, http-connector, 일련의 로컬 및 원격 연결 URI와 같은 구성 가능한 요소가 포함되어 있습니다.
대부분의 사용 사례에서는 원격
하위 시스템을 구성할 필요가 없을 수 있습니다. 애플리케이션에 사용자 지정 커넥터를 사용하는 경우 원격
하위 시스템을 구성해야 합니다.
Jakarta Enterprise Bean과 같은 클라이언트 원격 역할을 하는 애플리케이션에는 특정 커넥터에 연결하기 위한 별도의 구성이 필요합니다.
기본 하위 시스템 구성
<subsystem xmlns="urn:jboss:domain:remoting:4.0"> <endpoint/> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> </subsystem>
원격
하위 시스템에 사용할 수 있는 속성의 전체 목록은 하위 시스템 속성 Remoting Subsystem Attributes 를 참조하십시오.
원격 끝점
리모팅 엔드포인트는 the io
하위 시스템에서 선언 및 구성한 XNIO 작업자를 사용합니다.
리모 팅 끝점을 구성하는 방법에 대한 자세한 내용은 끝점 구성을 참조하십시오.
커넥터
커넥터
는 JBoss Remoting 프로젝트의 주요 구성 요소이며 외부 클라이언트가 지정된 포트의 서버에 연결할 수 있도록 하는 데 사용됩니다. 커넥터
를 통해 서버에 연결해야 하는 클라이언트는 서버를 참조하는 URL에서 Remoting 원격
프로토콜을 사용해야 합니다(예: remote://localhost:4447).
여러 커넥터를 구성할 수 있습니다. 각 커넥터는 여러 하위 요소와 socket-binding
및 ssl-context
와 같은 몇 가지 다른 속성이 있는 < connector
> 요소로 구성됩니다.
여러 JBoss EAP 하위 시스템에서 기본 커넥터를 사용할 수 있습니다. 사용자 지정 커넥터의 요소 및 속성에 대한 특정 설정은 애플리케이션에 따라 다릅니다. 자세한 내용은 Red Hat 글로벌 지원 서비스에 문의하십시오.
커넥터 구성 방법에 대한 자세한 내용은 커넥터 구성을 참조하십시오.
http-connector
http-connector
요소는 특수 커넥터 구성 요소입니다. 외부 클라이언트는 이 요소를 사용하여 undertow
의 HTTP 업그레이드 기능을 사용하여 서버에 연결할 수 있습니다.
이 구성을 통해 클라이언트는 먼저 HTTP 프로토콜을 사용하여 서버와의 연결을 설정한 다음 동일한 연결을 통해 원격
프로토콜을 사용합니다. 이렇게 하면 다양한 프로토콜을 사용하는 클라이언트가 undertow
의 기본 포트 8080과 같은 동일한 포트를 통해 연결할 수 있습니다. 동일한 포트를 통해 연결하면 서버의 열려 있는 포트 수가 줄어듭니다.
HTTP 업그레이드를 통해 서버에 연결해야 하는 클라이언트는 암호화되지 않은 연결에 remoting remote+http
프로토콜 또는 암호화된 연결을 위해 원격+https
프로토콜을 사용해야 합니다.
아웃바운드 연결
다음 세 가지 유형의 아웃바운드 연결을 지정할 수 있습니다.
추가 구성
리모팅은 네트워크 인터페이스 및 IO 작업자와 같이 원격
하위 시스템 외부에서 구성된 여러 요소에 따라 달라집니다.
자세한 내용은 추가 구성 재시작을 참조하십시오.
18.2. 끝점 구성
JBoss EAP 6에서 작업자 스레드 풀은 원격
하위 시스템에서 직접 구성되었습니다. JBoss EAP 7에서 원격 엔드포인트
구성은 the io
하위 시스템의 작업자를 참조합니다.
JBoss EAP는 기본적으로 다음과 같은 엔드포인트
구성을 제공합니다.
<subsystem xmlns="urn:jboss:domain:remoting:4.0"> <endpoint/> ... </subsystem>
기존 엔드포인트 구성 업데이트
/subsystem=remoting/configuration=endpoint:write-attribute(name=authentication-retries,value=2)
reload
새 엔드포인트 구성 생성
/subsystem=remoting/configuration=endpoint:add
엔드 포인트 구성 삭제
/subsystem=remoting/configuration=endpoint:remove
reload
엔드포인트 구성에 사용할 수 있는 속성의 전체 목록은 엔드포인트 속성에서 참조하십시오.
18.3. 커넥터 구성
커넥터는 원격 지정과 관련된 주요 구성 요소이며 추가 구성에 대한 여러 하위 인수를 포함합니다.
기존 커넥터 구성 업데이트
/subsystem=remoting/connector=new-connector:write-attribute(name=socket-binding,value=my-socket-binding)
reload
새 커넥터 생성
/subsystem=remoting/connector=new-connector:add(socket-binding=my-socket-binding)
커넥터 삭제
/subsystem=remoting/connector=new-connector:remove
reload
커넥터 구성에 사용할 수 있는 속성의 전체 목록은 Remoting Subsystem Attributes 섹션을 참조하십시오.
18.4. HTTP 커넥터 구성
HTTP 커넥터는 HTTP 업그레이드 기반 원격 커넥터에 대한 구성을 제공합니다. JBoss EAP는 기본적으로 다음과 같은 http-connector
구성을 제공합니다.
<subsystem xmlns="urn:jboss:domain:remoting:4.0"> ... <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> </subsystem>
기본적으로 이 HTTP 커넥터는 undertow 하위 시스템에서
구성된 default
라는 HTTP 리스너에 연결됩니다. 자세한 내용은 웹 서버(Undertow) 구성을 참조하십시오.
기존 HTTP 커넥터 구성 업데이트
/subsystem=remoting/http-connector=new-connector:write-attribute(name=connector-ref,value=new-connector-ref)
reload
새 HTTP 커넥터 생성
/subsystem=remoting/http-connector=new-connector:add(connector-ref=default)
HTTP 커넥터 삭제
/subsystem=remoting/http-connector=new-connector:remove
HTTP 커넥터 구성에 사용할 수 있는 속성의 전체 목록은 커넥터 특성을 참조하십시오.
18.5. 아웃바운드 연결 구성
아웃바운드 연결은 URI에서 완전히 지정하는 일반 원격 아웃바운드 연결입니다.
기존 아웃바운드 연결 업데이트
/subsystem=remoting/outbound-connection=new-outbound-connection:write-attribute(name=uri,value=http://example.com)
새 아웃바운드 연결 생성
/subsystem=remoting/outbound-connection=new-outbound-connection:add(uri=http://example.com)
아웃바운드 연결 삭제
/subsystem=remoting/outbound-connection=new-outbound-connection:remove
아웃바운드 연결을 구성하는 데 사용할 수 있는 속성의 전체 목록은 SeeOutbound 연결 속성입니다.
18.6. 원격 아웃바운드 연결 구성
원격 아웃바운드 연결은 프로토콜, 아웃바운드 소켓 바인딩, 사용자 이름 및 보안 영역에서 지정합니다. 프로토콜은 원격
,http-remoting 또는
일 수 있습니다.
https-remot
ing
기존 원격 아웃바운드 연결 업데이트
/subsystem=remoting/remote-outbound-connection=new-remote-outbound-connection:write-attribute(name=outbound-socket-binding-ref,value=outbound-socket-binding)
새 원격 아웃바운드 연결 생성
/subsystem=remoting/remote-outbound-connection=new-remote-outbound-connection:add(outbound-socket-binding-ref=outbound-socket-binding)
원격 아웃바운드 연결 삭제
/subsystem=remoting/remote-outbound-connection=new-remote-outbound-connection:remove
원격 아웃바운드 연결을 구성하는 데 사용할 수 있는 속성의 전체 목록은 원격 아웃바운드 연결 속성 에서 참조하십시오.
18.7. 로컬 아웃바운드 연결 구성
로컬 아웃바운드 연결은 아웃바운드 소켓 바인딩에서만 지정하는 로컬
프로토콜을 사용한 원격 아웃바운드 연결입니다.
기존 로컬 아웃바운드 연결 업데이트
/subsystem=remoting/local-outbound-connection=new-local-outbound-connection:write-attribute(name=outbound-socket-binding-ref,value=outbound-socket-binding)
새 로컬 아웃바운드 연결 생성
/subsystem=remoting/local-outbound-connection=new-local-outbound-connection:add(outbound-socket-binding-ref=outbound-socket-binding)
로컬 아웃바운드 연결 삭제
/subsystem=remoting/local-outbound-connection=new-local-outbound-connection:remove
로컬 아웃바운드 연결을 구성하는 데 사용할 수 있는 속성의 전체 목록은 Local Outbound Connection Attributes 를 참조하십시오.
18.8. 추가 리모팅 설정
원격 하위 시스템 외부에서 구성된 몇 가지 원격
구성 요소가 있습니다.
- IO 작업자
다음 명령을 사용하여 원격에 사용할 IO 작업자를 설정합니다.
/subsystem=remoting/configuration=endpoint:write-attribute(name=worker, value=WORKER_NAME)
IO 작업자를 구성하는 방법에 대한 자세한 내용은 작업자 구성을 참조하십시오.
- 네트워크 인터페이스
리모팅
하위 시스템에서 사용하는 네트워크 인터페이스는공용
인터페이스입니다. 이 인터페이스는 다른 여러 하위 시스템에서도 사용하므로 수정할 때 주의하십시오.<interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address:127.0.0.1}"/> </interface> <interface name="unsecure"> <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/> </interface> </interfaces>
관리형 도메인에서
공용
인터페이스는 host.xml 파일의 호스트
별로 정의됩니다.- 소켓 바인딩
리모팅
하위 시스템에서 사용하는 기본 소켓 바인딩은 포트8080
에 바인딩됩니다.소켓 바인딩 및 소켓 바인딩 그룹에 대한 자세한 내용은 소켓 바인딩 을 참조하십시오.
- 안전한 전송 구성
- 전송 리모팅은 클라이언트가 요청하는 경우 STARTTLS를 사용하여 HTTPS, Secure Servlet과 같은 보안 연결을 사용합니다. 보안 및 보안되지 않은 연결에는 동일한 소켓 바인딩 또는 네트워크 포트가 사용되므로 추가 서버 측 구성이 필요하지 않습니다. 클라이언트는 요구 사항에 따라 보안 또는 비보안 전송을 요청합니다. Jakarta Enterprise Beans, ORB 및 Java Messaging Service 공급자와 같은 원격 기능을 사용하는 JBoss EAP 구성 요소는 기본적으로 보안 인터페이스를 요청합니다.
STARTTLS는 클라이언트가 요청하는 경우 보안 연결을 활성화하여 작동하며, 그렇지 않으면 보안되지 않은 연결로 기본 설정됩니다. 공격자가 클라이언트의 요청을 가로채고 보안되지 않은 연결을 요청하도록 수정하는 중간자 위협에 본질적으로 취약합니다. 보안되지 않은 연결이 적절한 대체인 경우가 아니면 클라이언트가 보안 연결을 받지 않는 경우 적절하게 실패하도록 작성해야 합니다.
19장. IO 하위 시스템 구성
19.1. IO 하위 시스템 개요
The io
하위 시스템은 Undertow 및 Remoting과 같은 다른 하위 시스템에서 사용하는 XNIO 작업자 및 버퍼 풀을 정의합니다. 이러한 작업자 및 버퍼 풀은 the io
하위 시스템에서 다음 구성 요소 내에 정의됩니다.
기본 IO 하위 시스템 구성
<subsystem xmlns="urn:jboss:domain:io:3.0"> <worker name="default"/> <buffer-pool name="default"/> </subsystem>
19.2. 작업자 구성
Worker는 XNIO 작업자 인스턴스입니다. XNIO 작업자 인스턴스는 Java NIO API의 추상화 계층으로, IO 및 작업자 스레드 관리와 같은 기능은 물론 SSL 지원도 제공합니다. 기본적으로 JBoss EAP는 default
라는 단일 작업자를 제공하지만 더 많은 것을 정의할 수 있습니다.
기존 작업자 업데이트
기존 작업자를 업데이트하려면 다음을 수행합니다.
/subsystem=io/worker=default:write-attribute(name=io-threads,value=10)
reload
새 작업자 생성
새 작업자를 생성하려면 다음을 수행합니다.
/subsystem=io/worker=newWorker:add
작업자 삭제
작업자를 삭제하려면 다음을 수행합니다.
/subsystem=io/worker=newWorker:remove
reload
작업자를 구성하는 데 사용할 수 있는 속성의 전체 목록은 IO 하위 시스템 속성 섹션을 참조하십시오.
19.3. 버퍼 풀 구성
IO 버퍼 풀은 더 이상 사용되지 않지만 현재 릴리스에서는 기본값으로 설정되어 있습니다. 버퍼 풀은 풀링된 NIO 버퍼 인스턴스입니다. 버퍼 크기를 변경하면 애플리케이션 성능에 큰 영향을 미칩니다. 대부분의 서버에 이상적인 버퍼 크기는 일반적으로 16k입니다. Undertow 바이트 버퍼 풀 구성에 대한 자세한 내용은 JBoss EAP 구성 가이드의 바이트 버퍼 풀 구성 섹션을 참조하십시오.
기존 버퍼 풀 업데이트
기존 버퍼 풀을 업데이트하려면 다음을 수행합니다.
/subsystem=io/buffer-pool=default:write-attribute(name=direct-buffers,value=true)
reload
버퍼 풀 생성
새 버퍼 풀을 생성하려면 다음을 수행합니다.
/subsystem=io/buffer-pool=newBuffer:add
버퍼 풀 삭제
버퍼 풀을 삭제하려면 다음을 수행합니다.
/subsystem=io/buffer-pool=newBuffer:remove
reload
버퍼 풀 구성에 사용할 수 있는 속성의 전체 목록은 IO 하위 시스템 속성 섹션을 참조하십시오.
19.4. IO 하위 시스템 튜닝
the io
하위 시스템의 성능 모니터링 및 최적화에 대한 팁은 성능 튜닝 가이드의 IO 하위 시스템 튜닝 섹션을 참조하십시오.
20장. 웹 서비스 구성
JBoss EAP는 관리 콘솔 또는 관리 CLI를 사용하여 webservices
하위 시스템을 통해 배포된 웹 서비스의 동작을 구성하는 기능을 제공합니다. 게시된 끝점 주소 및 핸들러 체인을 구성할 수 있습니다. 웹 서비스에 대한 런타임 통계 컬렉션을 활성화할 수도 있습니다.
자세한 내용은 JBoss EAP 용 웹 서비스 애플리케이션 개발에서 웹 서비스 하위 시스템 구성을 참조하십시오.
21장. Jakarta Server Faces 구성
21.1. Jakarta Server Faces의 다중 Jakarta Server Faces 구현
jsf
하위 시스템을 사용하면 동일한 JBoss EAP 서버 인스턴스에 여러 Jakarta Server Faces 구현을 설치할 수 있습니다. Jakarta Server Faces 사양 2.3 이상을 구현하는 Sun Mojarra 또는 Apache MyFaces 버전을 설치할 수 있습니다.
21.1.1. Jakarta Server Faces 구현 설치
다음 절차에서는 새로운 Jakarta Server Faces 구현을 수동으로 설치하고 이를 기본 구현으로 설정하는 방법을 설명합니다.
Jakarta Server Faces Implementation JAR 파일 추가
Jakarta Server Faces 구현을 위한
EAP_HOME/modules/
디렉터리에 적절한 디렉터리 구조를 생성합니다.$ cd EAP_HOME/modules/ $ mkdir -p com/sun/jsf-impl/IMPL_NAME-VERSION
참고예를 들어
IMPL_NAME-VERSION
을 Jakarta Server Faces 사양 2.3 이상을 지원하는 Mojarra 버전으로 교체합니다.-
Jakarta Server Faces 구현 JAR 파일을
IMPL_NAME-VERSION/
하위 디렉터리에 복사합니다. -
IMPL_NAME-VERSION/
하위 디렉터리에서 이 Mojarra 템플릿 또는 이 MyFaces 템플릿 과 유사한module.xml
파일을 생성합니다. 템플릿을 사용하는 경우 언급된 standalone 변수에 적절한 값을 사용해야 합니다.
Jakarta Server Faces API JAR 파일 추가
Jakarta Server Faces 구현을 위한
EAP_HOME/modules/
디렉터리에 적절한 디렉터리 구조를 생성합니다.$ cd EAP_HOME/modules/ $ mkdir -p javax/faces/api/IMPL_NAME-VERSION
-
Jakarta Server Faces API JAR 파일을
IMPL_NAME-VERSION/
하위 디렉터리에 복사합니다. -
IMPL_NAME-VERSION/
하위 디렉터리에서 이 Mojarra 템플릿 또는 이 MyFaces 템플릿 과 유사한module.xml
파일을 생성합니다. 템플릿을 사용하는 경우 언급된 standalone 변수에 적절한 값을 사용해야 합니다.
Jakarta Server Faces Injection JAR 파일 추가
Jakarta Server Faces 구현을 위한
EAP_HOME/modules/
디렉터리에 적절한 디렉터리 구조를 생성합니다.$ cd EAP_HOME/modules/ $ mkdir -p org/jboss/as/jsf-injection/IMPL_NAME-VERSION
패치 및 업그레이드 가이드에 설명된 지침을 따라 JBoss EAP 인스턴스의 최신 누적 패치를 다운로드합니다. 다음으로 다음 단계 중 하나를 완료합니다.
-
패치 업데이트를 서버에 적용하지 않은 경우
EAP_HOME/modules/system/layers/base/org/jboss/as/
jsff JAR 파일을jsf-injection/main/에서 thewildfly
-jsf-injection 및 weld-coreIMPL_NAME-VERSION/
하위 디렉터리에 복사합니다. -
패치 업데이트를 서버에 적용한 경우 최신 패치 업데이트 디렉토리에서
IMPL_NAME-VERSION/
하위 디렉터리로 thewildfly
JAR 파일을 복사합니다. 예를 들어-jsf-injection
및 weld-core-jsfEAP_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-7.4.z.CP/org/jboss/as/jsf-injection
은 최신 버전 번호입니다.
-
패치 업데이트를 서버에 적용하지 않은 경우
-
IMPL_NAME-VERSION/
하위 디렉터리에서 이 Mojarra 템플릿 또는 이 MyFaces 템플릿 과 유사한module.xml
파일을 생성합니다. 템플릿을 사용하는 경우 언급된 standalone 변수에 적절한 값을 사용해야 합니다.
MyFaces에 commons-digester JAR 파일 추가
commons-digester
JAR의EAP_HOME/modules/
디렉터리에 적절한 디렉터리 구조를 생성합니다.$ cd EAP_HOME/modules/ $ mkdir -p org/apache/commons/digester/main
-
commons-digester
JAR 파일을 다운로드하여main/
하위 디렉터리에 복사합니다. -
main/
하위 디렉터리에서 이 템플릿 과 유사한module.xml
파일을 생성합니다. 템플릿을 사용하는 경우 언급된 standalone 변수에 적절한 값을 사용해야 합니다.
기본 Jakarta Server Faces 구현 설정
다음 관리 CLI 명령을 실행하여 새로운 Jakarta Server Faces 구현을 기본 구현으로 설정합니다.
/subsystem=jsf:write-attribute(name=default-jsf-impl-slot,value=IMPL_NAME-VERSION)
- 변경 사항을 적용하려면 JBoss EAP 서버를 다시 시작하십시오.
21.1.2. Multi-Jakarta Server Faces 구현 지원
JBoss EAP 7.4에는 Mojarra를 기반으로 하는 단일 Jakarta Server Faces 구현인 Jakarta Server Faces 2.3 구현이 포함되어 있습니다.
Multi-Jakarta Server Faces를 사용하면 동일한 JBoss EAP 서버에 여러 Jakarta Server Faces 구현 및 버전을 설치할 수 있습니다. 이 목표는 Jakarta Server Faces, MyFaces 또는 Mojarra 그리고 Faces 2.1 이상 및 Jakarta Server Faces 2.3 이후의 모든 구현 버전을 사용할 수 있도록 하는 것입니다. 멀티Jakarta Server Faces는 보다 효율적인 주석 처리, 라이프사이클 처리 및 기타 통합 이점을 허용하는 컨테이너와 완전히 통합된 구현을 제공합니다.
21.1.2.1. Multi-Jakarta Server Faces 구현 작업
multi-Jakarta Server Faces가 작동하는 방식은 각 Jakarta Server Faces 버전에 대해 com.sun.jsf-impl,
아래의 모듈 경로에 새 슬롯이 생성된다는 것입니다. javax.faces.api 및
injectionorg.jboss.as.
jsf-jsf
하위 시스템이 시작되면 모듈 경로를 검사하여 설치된 모든 Jakarta Server Faces 구현을 찾습니다. jsf
하위 시스템에서 지정된 컨텍스트 매개 변수를 포함하는 웹 애플리케이션을 배포하는 경우 슬롯된 모듈을 배포에 추가합니다.
예를 들어 Jakarta Server Faces 애플리케이션이 MyFaces 2.2.12를 사용함을 나타내기 위해 MyFaces 2.2.12가 서버에 설치되어 있다고 가정하면 다음과 같은 context 매개변수를 추가해야 합니다.
<context-param>
<param-name>org.jboss.jbossfaces.JSF_CONFIG_NAME</param-name>
<param-value>myfaces-2.2.12</param-value>
</context-param>
21.1.2.2. 기본 Jakarta Server Faces 구현 변경
multi-Jakarta Server Faces 기능에는jsf 하위
시스템에 default-jsf-impl-slot
특성이 포함되어 있습니다. 이 속성을 사용하면 다음 절차에 설명된 대로 기본 Jakarta Server Faces 구현을 변경할 수 있습니다.
write-attribute
명령을 사용하여default-jsf-impl-slot
속성 값을 활성 Jakarta Server Faces 구현 중 하나로 설정합니다./subsystem=jsf:write-attribute(name=default-jsf-impl-slot,value=JSF_IMPLEMENTATION)
변경 사항을 적용하려면 JBoss EAP 서버를 다시 시작하십시오.
reload
설치된 Jakarta Server Faces 구현을 보려면 list-active-jsf-impls
작업을 실행할 수 있습니다.
/subsystem=jsf:list-active-jsf-impls { "outcome" => "success", "result" => [ "myfaces-2.1.12", "mojarra-2.2.0-m05", "main" ] }
21.2. DOCTYPE 선언 허용 비활성화
다음 관리 CLI 명령을 사용하여 Jakarta Server Faces 배포에서 DOCTYPE
선언을 허용하지 않을 수 있습니다.
/subsystem=jsf:write-attribute(name=disallow-doctype-decl,value=true) reload
배포의 web. xml 파일에
com.sun.faces.disallowDoctypeDecl
컨텍스트 매개변수를 추가하여 특정 Jakarta Server Faces 배포에 대해 이 설정을 재정의할 수 있습니다.
<context-param> <param-name>com.sun.faces.disallowDoctypeDecl</param-name> <param-value>false</param-value> </context-param>
22장. 배치 애플리케이션 구성
JBoss EAP 7은 자카르타 배치를 지원합니다. 배치 애플리케이션을 실행하기 위한 환경을 구성하고 batch-jberet 하위 시스템을 사용하여 배치
작업을 관리할 수 있습니다.
배치 애플리케이션 개발에 대한 자세한 내용은 JBoss EAP 개발 가이드의 Jakarta Batch Application Development 를 참조하십시오.
22.1. 배치 작업 구성
JBeret 구현을 기반으로 하는 batch-jberet 하위 시스템을 사용하여 배치
작업에 대한 설정을 구성할 수 있습니다.
기본 batch-jberet
하위 시스템 구성은 in-memory 작업 리포지토리 및 기본 스레드 풀 설정을 정의합니다.
<subsystem xmlns="urn:jboss:domain:batch-jberet:2.0"> <default-job-repository name="in-memory"/> <default-thread-pool name="batch"/> <job-repository name="in-memory"> <in-memory/> </job-repository> <thread-pool name="batch"> <max-threads count="10"/> <keepalive-time time="30" unit="seconds"/> </thread-pool> </subsystem>
기본적으로 서버 일시 중지 중에 중지된 배치 작업은 서버를 다시 시작할 때 다시 시작됩니다. restart-jobs-on-resume
속성을 false로
설정하여 대신 작업을 STOPPED
상태로 유지할 수 있습니다.
/subsystem=batch-jberet:write-attribute(name=restart-jobs-on-resume,value=false)
배치 작업 리포지토리 및 스레드 풀에 대한 설정을 구성할 수도 있습니다.
22.1.1. 배치 작업 리포지토리 구성
이 섹션에서는 관리 CLI를 사용하여 배치 작업 정보를 저장하기 위해 메모리 내 및 JDBC 작업 리포지토리를 구성하는 방법을 보여줍니다. Configuration → Subsystems → Batch(JBeret)로 이동하여 View (보기)를 클릭하고 왼쪽 메뉴에서 In Memory (메모리 또는 JDBC ) 를 선택하여 관리 콘솔을 사용하여 작업 리포지토리를 구성할 수도 있습니다.
인메모리 작업 리포지토리 추가
배치 작업 정보를 메모리에 저장하는 작업 리포지토리를 추가할 수 있습니다.
/subsystem=batch-jberet/in-memory-job-repository=REPOSITORY_NAME:add
JDBC 작업 리포지토리 추가
데이터베이스에서 배치 작업 정보를 저장하는 작업 리포지토리를 추가할 수 있습니다. 데이터베이스에 연결할 데이터 소스의 이름을 지정해야 합니다.
/subsystem=batch-jberet/jdbc-job-repository=REPOSITORY_NAME:add(data-source=DATASOURCE)
기본 작업 리포지토리 설정
in-memory 또는 JDBC 작업 리포지토리를 배치 애플리케이션의 기본 작업 리포지토리로 설정할 수 있습니다.
/subsystem=batch-jberet:write-attribute(name=default-job-repository,value=REPOSITORY_NAME)
이 작업을 수행하려면 서버를 다시 로드해야 합니다.
reload
22.1.2. 배치 스레드 풀 구성
이 섹션에서는 관리 CLI를 사용하여 배치 작업에 사용할 스레드 풀 및 스레드 팩토리를 구성하는 방법을 보여줍니다. 또한 Configuration → Subsystems → Batch(JBeret)로 이동하여 View (보기) 를 클릭하고 왼쪽 메뉴에서 스레드 팩토리 또는 스레드 풀을 선택하여 관리 콘솔을 사용하여 스레드 풀 및 스레드 팩토리 를 구성할 수도 있습니다.
스레드 풀 구성
스레드 풀을 추가할 때 max-threads를 지정해야 합니다. max-threads
는 파티션 작업이 예상대로 실행될 수 있도록 두 스레드가 예약되어 있으므로 항상 3
보다 커야 합니다.
스레드 풀 추가.
/subsystem=batch-jberet/thread-pool=THREAD_POOL_NAME:add(max-threads=10)
필요한 경우
keepalive-time
값을 설정합니다./subsystem=batch-jberet/thread-pool=THREAD_POOL_NAME:write-attribute(name=keepalive-time,value={time=60,unit=SECONDS})
스레드 팩토리 사용
스레드 팩토리 추가.
/subsystem=batch-jberet/thread-factory=THREAD_FACTORY_NAME:add
스레드 팩토리에 대해 원하는 특성을 구성합니다.
-
group-name
- 이 스레드 팩토리에 대해 생성할 스레드 그룹의 이름입니다. -
Priority
- 생성된 스레드의 스레드 우선 순위입니다. thread-name-pattern
- 스레드 이름을 생성하는 데 사용되는 템플릿입니다. 다음 패턴을 사용할 수 있습니다.-
%%
- 백분율 기호 -
%t
- 팩토리별 스레드 시퀀스 번호 -
%g
- 글로벌 스레드 시퀀스 번호 -
%f
- 팩토리 시퀀스 번호 -
%I -
스레드 ID
-
-
스레드 팩토리를 스레드 풀에 할당합니다.
/subsystem=batch-jberet/thread-pool=THREAD_POOL_NAME:write-attribute(name=thread-factory,value=THREAD_FACTORY_NAME)
이 작업을 수행하려면 서버를 다시 로드해야 합니다.
reload
기본 스레드 풀 설정
다른 스레드 풀을 기본 스레드 풀로 설정할 수 있습니다.
/subsystem=batch-jberet:write-attribute(name=default-thread-pool,value=THREAD_POOL_NAME)
이 작업을 수행하려면 서버를 다시 로드해야 합니다.
reload
스레드 풀 통계 보기
read-resource
관리 CLI 작업을 사용하여 배치 스레드 풀에 대한 런타임 정보를 볼 수 있습니다. 이 런타임 정보를 보려면 include-runtime=true
매개변수를 사용해야 합니다.
/subsystem=batch-jberet/thread-pool=THREAD_POOL_NAME:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "active-count" => 0, "completed-task-count" => 0L, "current-thread-count" => 0, "keepalive-time" => undefined, "largest-thread-count" => 0, "max-threads" => 15, "name" => "THREAD_POOL_NAME", "queue-size" => 0, "rejected-count" => 0, "task-count" => 0L, "thread-factory" => "THREAD_FACTORY_NAME" } }
Runtime (런타임) 탭에서 Batch 하위 시스템으로 이동하여 관리 콘솔을 사용하여 배치 스레드 풀에 대한 런타임 정보를 볼 수도 있습니다.
22.2. 배치 작업 관리
배포에 대한 batch-jberet
하위 시스템 리소스를 사용하면 배치 작업에 대한 실행 세부 정보를 시작, 중지, 다시 시작 및 볼 수 있습니다. 배치 작업은 관리 CLI 또는 관리 콘솔에서 관리할 수 있습니다.
관리 CLI에서 배치 작업 관리
배치 작업 다시 시작
실행 ID와 배치 작업을 다시 시작할 때 사용할 모든 속성을 제공하여 a STOPPED
또는 FAILED
상태에 있는 작업을 다시 시작할 수 있습니다.
/deployment=DEPLOYMENT_NAME/subsystem=batch-jberet:restart-job(execution-id=EXECUTION_ID,properties={PROPERTY=VALUE})
실행 ID는 작업 인스턴스의 최신 실행이어야 합니다.
배치 작업 시작
작업 XML 파일 및 배치 작업을 시작할 때 사용할 모든 속성을 제공하여 배치 작업을 시작할 수 있습니다.
/deployment=DEPLOYMENT_NAME/subsystem=batch-jberet:start-job(job-xml-name=JOB_XML_NAME,properties={PROPERTY=VALUE})
배치 작업 중지
실행 ID를 제공하여 실행 중인 배치 작업을 중지할 수 있습니다.
/deployment=DEPLOYMENT_NAME/subsystem=batch-jberet:stop-job(execution-id=EXECUTION_ID)
배치 작업 실행 세부 정보 보기
배치 작업 실행 세부 정보를 볼 수 있습니다. 이 런타임 정보를 보려면 read
매개변수를 사용해야 합니다.
-resource 작업에 include-
runtime=true
/deployment=DEPLOYMENT_NAME/subsystem=batch-jberet:read-resource(recursive=true,include-runtime=true)
{
"outcome" => "success",
"result" => {"job" => {"import-file" => {
"instance-count" => 2,
"running-executions" => 0,
"execution" => {
"2" => {
"batch-status" => "COMPLETED",
"create-time" => "2016-04-11T22:03:12.708-0400",
"end-time" => "2016-04-11T22:03:12.718-0400",
"exit-status" => "COMPLETED",
"instance-id" => 58L,
"last-updated-time" => "2016-04-11T22:03:12.719-0400",
"start-time" => "2016-04-11T22:03:12.708-0400"
},
"1" => {
"batch-status" => "FAILED",
"create-time" => "2016-04-11T21:57:17.567-0400",
"end-time" => "2016-04-11T21:57:17.596-0400",
"exit-status" => "Error : org.hibernate.exception.ConstraintViolationException: could not execute statement",
"instance-id" => 15L,
"last-updated-time" => "2016-04-11T21:57:17.597-0400",
"start-time" => "2016-04-11T21:57:17.567-0400"
}
}
}}}
}
관리 콘솔에서 배치 작업 관리
관리 콘솔에서 배치 작업을 관리하려면 Runtime(런타임 ) 탭으로 이동하여 서버를 선택하고 Batch(JBeret) 를 선택하고 목록에서 작업을 선택합니다.
배치 작업 다시 시작
실행을 선택하고 Restart를 클릭하여 a STOPPED
작업을 다시 시작합니다.
배치 작업 시작
작업을 선택하고 드롭다운에서 Start (시작)를 선택하여 배치 작업의 새 실행을 시작합니다.
배치 작업 중지
실행을 선택하고 Stop(중지)을 클릭하여 실행 중인 배치 작업을 중지합니다.
배치 작업 실행 세부 정보 보기
표에 나열된 각 실행에 대해 작업 실행 세부 정보가 표시됩니다.
22.3. 배치 작업의 보안 설정
Elytron 보안 도메인을 사용하여 배치 작업을 실행하도록 batch-jberet
하위 시스템을 구성할 수 있습니다. 이를 통해 동일한 보안 ID로 배치 작업을 안전하게 일시 중단하고 다시 시작할 수 있습니다. 예를 들어 batch-jberet
하위 시스템을 사용하여 배치 작업을 시작하기 위해 보안된 RESTful 엔드포인트가 생성됩니다. RESTful 엔드포인트와 batch-jberet
하위 시스템이 동일한 보안 도메인을 사용하여 보호되었거나 batch-jberet
보안 도메인이 RESTful 엔드포인트의 보안 도메인을 신뢰한 경우 이러한 방식으로 시작된 배치 작업은 동일한 보안 ID로 안전하게 일시 중지하고 다시 시작할 수 있습니다.
다음 관리 CLI 명령을 사용하여 security-domain
특성을 업데이트하여 배치 작업에 대한 보안을 구성합니다.
/subsystem=batch-jberet:write-attribute(name=security-domain, value=ExampleDomain) reload
배치 작업에는 org.wildfly.extension.batch.jberet.deployment.BatchPermission
권한이 필요합니다. javax.batch.operations.JobOperator
와 일치하는 start
,
stop
,restart
, quit 및 read
권한을 제공합니다. default-permission-mapper
매퍼는 org.wildfly.extension.batch.jberet.deployment.BatchPermission
권한을 제공합니다.
23장. 네이밍 하위 시스템 구성
23.1. 네이밍 하위 시스템 정보
네이밍
하위 시스템은 JBoss EAP에 대한 JNDI 구현을 제공합니다. 글로벌 JNDI 네임스페이스의 항목을 바인딩 하도록 이 하위 시스템을 구성할 수 있습니다. 원격 JNDI 인터페이스를 활성화하거나 비활성화하도록 구성할 수도 있습니다.
다음은 모든 요소 및 속성이 지정된 네이밍
하위 시스템 XML 구성 예제의 예입니다.
<subsystem xmlns="urn:jboss:domain:naming:2.0"> <bindings> <simple name="java:global/simple-integer-binding" value="100" type="int" /> <simple name="java:global/jboss.org/docs/url" value="https://docs.jboss.org" type="java.net.URL" /> <object-factory name="java:global/foo/bar/factory" module="org.foo.bar" class="org.foo.bar.ObjectFactory" /> <external-context name="java:global/federation/ldap/example" class="javax.naming.directory.InitialDirContext" cache="true"> <environment> <property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" /> <property name="java.naming.provider.url" value="ldap://ldap.example.com:389" /> <property name="java.naming.security.authentication" value="simple" /> <property name="java.naming.security.principal" value="uid=admin,ou=system" /> <property name="java.naming.security.credentials" value="secret" /> </environment> </external-context> <lookup name="java:global/new-alias-name" lookup="java:global/original-name" /> </bindings> <remote-naming/> </subsystem>
23.2. 글로벌 바인딩 구성
네이밍
하위 시스템을 사용하면 java:global, java:
jboss 또는 java
글로벌 JNDI 네임스페이스에 항목을 바인딩할 수 있지만 표준 이식 가능한
java:global
네임스페이스를 사용하는 것이 좋습니다.
글로벌 바인딩은 네이밍
하위 시스템의 <bindings>
요소에서 구성됩니다. 4가지 유형의 바인딩이 지원됩니다.
간단한 바인딩 구성
간단한
XML 구성 요소는 프리미티브 또는 java.net.URL
항목을 바인딩합니다.
-
name
특성은 필수이며 항목에 대한 대상 JNDI 이름을 지정합니다. -
value
속성은 필수이며 항목의 값을 정의합니다. -
기본값은
java.lang.String
인 선택적type
속성은 항목 값의 유형을 지정합니다.java.lang.String
외에도 기본 유형과 해당 개체 래퍼 클래스를int
또는java.lang.Integer 및 java.
과 같은 개체 래퍼 클래스를 지정할 수 있습니다.net.
URL
다음은 간단한 바인딩을 생성하는 관리 CLI 명령의 예입니다.
/subsystem=naming/binding=java\:global\/simple-integer-binding:add(binding-type=simple, type=int, value=100)
결과 XML 구성
<subsystem xmlns="urn:jboss:domain:naming:2.0"> <bindings> <simple name="java:global/simple-integer-binding" value="100" type="int"/> </bindings> <remote-naming/> </subsystem>
다음 명령을 사용하여 바인딩을 제거합니다.
/subsystem=naming/binding=java\:global\/simple-integer-binding:remove
바인딩 오브젝트 팩트
object-factory
XML 구성 요소는 javax.naming.spi.ObjectFactory
항목을 바인딩합니다.
-
name
특성은 필수이며 항목에 대한 대상 JNDI 이름을 지정합니다. -
class
특성은 필수이며 오브젝트 팩토리의 Java 유형을 정의합니다. -
module
속성은 필수이며 개체 팩토리 Java 클래스를 로드할 수 있는 JBoss 모듈 ID를 지정합니다. -
선택적
환경
하위 요소를 사용하여 오브젝트 팩토리에 사용자 지정 환경을 제공할 수 있습니다.
다음은 오브젝트 팩토리 바인딩을 생성하는 관리 CLI 명령의 예입니다.
/subsystem=naming/binding=java\:global\/foo\/bar\/factory:add(binding-type=object-factory, module=org.foo.bar, class=org.foo.bar.ObjectFactory, environment=[p1=v1, p2=v2])
결과 XML 구성
<subsystem xmlns="urn:jboss:domain:naming:2.0"> <bindings> <object-factory name="java:global/foo/bar/factory" module="org.foo.bar" class="org.foo.bar.ObjectFactory"> <environment> <property name="p1" value="v1" /> <property name="p2" value="v2" /> </environment> </object-factory> </bindings> </subsystem>
다음 명령을 사용하여 바인딩을 제거합니다.
/subsystem=naming/binding=java\:global\/foo\/bar\/factory:remove
외부 컨텍스트 바인딩
LDAP 컨텍스트와 같은 외부 JNDI 컨텍스트의 통합은 외부 컨텍스트 XML
구성 요소를 사용하여 수행됩니다.
-
name
특성은 필수이며 항목에 대한 대상 JNDI 이름을 지정합니다. -
클래스
특성은 필수이며, 연결된 컨텍스트를 생성하는 데 사용되는 Java 초기 명명 컨텍스트 유형을 나타냅니다. 이러한 유형에는 단일 환경 맵 인수가 있는 생성자가 있어야 합니다. -
선택적
module
특성은 외부 JNDI 컨텍스트에 필요한 모든 클래스를 로드할 수 있는 JBoss 모듈 ID를 지정합니다. -
기본값인 선택적
캐시
특성은 외부 컨텍스트 인스턴스를 캐시해야 하는지를나타냅니다
. -
선택적
환경
하위 요소는 외부 컨텍스트를 조회하는 데 필요한 사용자 지정 환경을 제공하는 데 사용할 수 있습니다.
다음은 외부 컨텍스트 바인딩을 생성하는 관리 CLI 명령의 예입니다.
/subsystem=naming/binding=java\:global\/federation\/ldap\/example:add(binding-type=external-context, cache=true, class=javax.naming.directory.InitialDirContext, module=org.jboss.as.naming, environment=[java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url="ldap://ldap.example.com:389", java.naming.security.authentication=simple, java.naming.security.principal="uid=admin,ou=system", java.naming.security.credentials=secret])
결과 XML 구성
<subsystem xmlns="urn:jboss:domain:naming:2.0"> <bindings> <external-context name="java:global/federation/ldap/example" module="org.jboss.as.naming" class="javax.naming.directory.InitialDirContext" cache="true"> <environment> <property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <property name="java.naming.provider.url" value="ldap://ldap.example.com:389"/> <property name="java.naming.security.authentication" value="simple"/> <property name="java.naming.security.principal" value="uid=admin,ou=system"/> <property name="java.naming.security.credentials" value="secret"/> </environment> </external-context> </bindings> </subsystem>
다음 명령을 사용하여 바인딩을 제거합니다.
/subsystem=naming/binding=java\:global\/federation\/ldap\/example:remove
resource에서 lookup(Name)
메서드를 올바르게 구현하지 않는 JNDI 공급자를 조회하면 "javax.naming.InvalidNameException"이 발생할 수 있습니다. CompoundName 이름" 오류만 지원합니다.
외부 컨텍스트 환경에서 다음 속성을 추가하여 lookup(String)
메서드를 사용하도록 지정하여 이 문제를 해결할 수 있지만 이로 인해 성능이 저하될 수 있습니다.
<property name="org.jboss.as.naming.lookup.by.string" value="true"/>
조회 별칭 바인딩
lookup
요소를 사용하면 기존 항목을 추가 이름 또는 별칭으로 바인딩할 수 있습니다.
-
name
특성은 필수이며 항목에 대한 대상 JNDI 이름을 지정합니다. -
lookup
특성은 필수이며 소스 JNDI 이름을 나타냅니다.
다음은 기존 항목을 별칭에 바인딩하는 관리 CLI 명령의 예입니다.
/subsystem=naming/binding=java\:global\/new-alias-name:add(binding-type=lookup, lookup=java\:global\/original-name)
결과 XML 구성
<lookup name="java:global/new-alias-name" lookup="java:global/original-name" />
다음 명령을 사용하여 바인딩을 제거합니다.
/subsystem=naming/binding=java\:global\/c:remove
23.3. JNDI 바인딩 동적으로 변경
JBoss EAP 7.1은 서버 재로드 또는 재시작 없이 JNDI 바인딩을 동적으로 변경하는 기능을 도입했습니다. 이 기능은 버전 업데이트, 테스트 요구 사항 또는 애플리케이션 기능 업데이트로 인해 네트워크 서비스 엔드포인트가 동적으로 재구성되는 경우 유용할 수 있습니다.
JNDI 바인딩을 업데이트하려면 rebind
작업을 사용합니다. rebind
작업은 add
작업과 동일한 인수를 사용합니다. 이 명령은 외부 컨텍스트 바인딩 유형을 제외한 모든 바인딩 유형에
대해 작동합니다. 외부 컨텍스트 바인딩에는 MSC(Modular Service Container) 상태에 영향을 주는 추가 종속성이 필요하므로 서비스를 다시 시작하지 않으면 다시 시작할 수 없습니다.
다음 명령은 단순 바인딩 구성 예에 정의된 JNDI 바인딩 을 동적으로 변경합니다.
/subsystem=naming/binding=java\:global\/simple-integer-binding:rebind(binding-type=simple, type=int, value=200)
네이밍
하위 시스템에서 글로벌 바인딩을 구성하는 방법에 대한 자세한 내용은 글로벌 바인딩 구성을 참조하십시오.
23.4. 원격 JNDI 인터페이스 구성
원격 JNDI 인터페이스를 사용하면 클라이언트가 원격 JBoss EAP 인스턴스에서 항목을 조회할 수 있습니다. 기본적으로 활성화되는 이 인터페이스를 비활성화하거나 활성화하도록 네이밍
하위 시스템을 구성할 수 있습니다. 원격 JNDI 인터페이스는 <remote-naming>
요소를 사용하여 구성됩니다.
다음 관리 CLI 명령을 사용하여 원격 JNDI 인터페이스를 활성화하거나 다시 활성화합니다.
/subsystem=naming/service=remote-naming:add
다음 관리 CLI 명령을 사용하여 원격 JNDI 인터페이스를 비활성화합니다.
/subsystem=naming/service=remote-naming:remove
java:jboss/exported
컨텍스트 내의 항목만 원격 JNDI를 통해 액세스할 수 있습니다.
24장. 고가용성 구성
24.1. 고가용성 소개
JBoss EAP는 배포된 자카르타 EE 애플리케이션의 가용성을 보장하는 고가용성 서비스를 제공합니다.
- 로드 밸런싱
- 이렇게 하면 서비스에서 여러 서버에 워크로드를 분산하여 많은 요청을 처리할 수 있습니다. 클라이언트는 대량의 요청 시에도 서비스에서 적시에 응답할 수 있습니다.
- 페일오버
- 이를 통해 클라이언트가 하드웨어 또는 네트워크 오류가 발생해도 서비스에 대한 중단 없이 액세스할 수 있습니다. 서비스가 실패하면 다른 클러스터 구성원이 클라이언트의 요청을 수신하여 계속 처리할 수 있습니다.
클러스터링 은 이러한 모든 기능을 포함하는 용어입니다. 클러스터의 구성원은 부하 분산이라는 워크로드를 공유하도록 구성하고 장애 조치(failover)라고 하는 다른 클러스터 구성원이 실패하는 경우 클라이언트 처리를 선택할 수 있습니다.
독립 실행형 서버 또는 관리형 도메인 중 하나를 선택한 JBoss EAP 운영 모드는 서버를 관리하는 방법과 관련이 있다는 점에 유의해야 합니다. 고가용성 서비스는 운영 모드와 관계없이 JBoss EAP에서 구성할 수 있습니다.
JBoss EAP는 다양한 구성 요소를 사용하여 여러 수준에서 고가용성을 지원합니다. 런타임 및 고가용성으로 제공될 수 있는 애플리케이션의 일부 구성 요소는 다음과 같습니다.
- 애플리케이션 서버 인스턴스
- 웹 애플리케이션을 내부 JBoss Web Server, Apache HTTP Server, Microsoft IIS 또는 Oracle iPlanet Web Server와 함께 사용할 경우
- 상태 저장 및 상태 비저장 세션 Jakarta Enterprise Bean
- SSO(Single Sign-On) 메커니즘
- HTTP 세션
- 자카르타 메시징 서비스 및 MDB(Message-Driven Bean)
- Singleton MSC 서비스
- Singleton 배포
클러스터링은 jgroups
, infinispan
및 modcluster
하위 시스템에서 JBoss EAP에서 사용할 수 있습니다. ha 및 full-ha 프로필에는 이러한 시스템이 활성화되어 있습니다. JBoss EAP에서 이러한 서비스는 필요에 따라 시작 및 종료되지만 배포 가능으로 구성된 애플리케이션이 서버에 배포되는 경우에만 시작됩니다.
24.2. JGroups와의 클러스터 통신
24.2.1. JGroups 정보
JGroups는 안정적인 메시징을 위한 툴킷이며 노드가 서로 메시지를 보낼 수 있는 클러스터를 생성하는 데 사용할 수 있습니다.
jgroups
하위 시스템은 JBoss EAP에서 고가용성 서비스에 대한 그룹 통신 지원을 제공합니다. 채널에 대한 런타임 통계를 볼 뿐만 아니라 명명된 채널 및 프로토콜 스택을 구성할 수 있습니다. jgroups
하위 시스템은 관리형 도메인에서 ha 또는 full-ha 프로필과 같은 고가용성 기능을 제공하는 구성을 사용하거나 독립 실행형 서버에 standalone -ha.xml 또는
구성 파일을 사용할 때 사용할 수 있습니다.
standalone-
full-ha.xml
JBoss EAP는 두 개의 JGroups 스택으로 사전 구성되어 있습니다.
- udp
- 클러스터의 노드는 UDP(User Datagram Protocol) 멀티캐스팅을 사용하여 서로 통신합니다. 기본 스택입니다.
- tcp
- 클러스터의 노드는 TCP(Transmission Control Protocol)를 사용하여 서로 통신합니다.
TCP는 오버헤드가 많으며 오류 검사, 패킷 순서 지정 및 혼잡 제어 자체를 처리하므로 UDP보다 더 느리게 간주됩니다. JGroups는 UDP에 대해 이러한 기능을 처리하는 반면 TCP는 자체적으로 보장합니다. TCP는 불안정하거나 높은 혼잡 네트워크에서 JGroups를 사용하거나 멀티캐스트를 사용할 수 없는 경우 좋은 선택입니다.
미리 구성된 스택을 사용하거나 시스템의 특정 요구 사항에 맞게 자체를 정의할 수 있습니다. 사용 가능한 프로토콜 및 해당 속성에 대한 자세한 내용은 다음 섹션을 참조하십시오.
24.2.2. 기본 NotReady 채널을 TCP를 사용하도록 전환
기본적으로 클러스터 노드는 ee#150 채널에 대해 구성된 udp
프로토콜 스택을 사용하여
통신합니다.
<channels default="ee"> <channel name="ee" stack="udp"/> </channels> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> ... </stack> <stack name="tcp"> <transport type="TCP" socket-binding="jgroups-tcp"/> <protocol type="MPING" socket-binding="jgroups-mping"/> ... </stack> </stacks>
멀티 캐스트를 사용하여 TCP 구성
일부 네트워크에서는 TCP만 사용할 수 있습니다. 다음 관리 CLI 명령을 사용하여 미리 구성된 tcp
스택을 사용하도록 ee
채널을 전환합니다.
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
이 기본 tcp
스택은 IP 멀티캐스트를 사용하여 초기 클러스터 멤버십을 검색하는 MPING
프로토콜을 사용합니다.
멀티 캐스트 없이 TCP 구성
보안 정책에 의해 멀티 캐스트가 우선하지 않거나 허용되지 않는 경우 TCP를 사용하도록 기본 프로토콜 스택을 변경할 수 있습니다. 멀티 캐스트 없이 TCP 기반 클러스터링을 구성하려면 다음 단계를 수행합니다.
다음 명령을 실행하여 ee 채널을
전환
하여 NotReady 하위 시스템에서 사전 구성된tcp
스택을 사용합니다.<channel name="ee" stack="tcp" cluster="ejb"/>
클러스터 노드의 이름을 설정합니다.
독립 실행형 구성 모드에서 다음 단계 중 하나를 수행합니다.
다음 명령을 실행합니다.
<server xmlns="urn:jboss:domain:8.0" name="node_1">
-
인스턴스를 시작할 때 시스템 속성
jboss.node.name
에 고유한 이름을 지정합니다.
도메인 모드에서 클러스터 서버는 서버 태그의
host-*.xml
파일에 나열됩니다. 기본 구성은 필요에 따라 편집할 수 있는 다음 서버 이름을 지정합니다.<servers> <server name="server-one" group="main-server-group"/> <server name="server-two" group="other-server-group"> <socket-bindings port-offset="150"/> </server> </servers>
다른 클러스터 멤버를 검색하기 위해 다음 프로토콜 중 하나를 선택합니다.
-
TCPGOSSIP
: 이 프로토콜은 외부 gossip 라우터 서비스를 사용하여 클러스터의 멤버를 검색합니다. 이를 위해서는 추가 프로세스를 구성하고 관리해야 하지만 개별 EAP 인스턴스가 서로 클러스터 구성원을 나열하지 않도록 합니다. 이 프로토콜은 클러스터 멤버가 자주 변경되는 경우 유용합니다. 자세한 내용은 TCPPING 을 참조하십시오. -
TCPPING
: 이 프로토콜은 정적 클러스터 멤버십 목록을 정의하고 각 노드가 잠재적인 클러스터 구성원을 모두 나열해야 합니다. 이 프로토콜은 클러스터 멤버 주소를 알려진 경우 선호되며 자주 변경되지 않습니다. 자세한 내용은 TCPGOSSIP 를 참조하십시오.
-
24.2.3. TCPPING 구성
이 절차에서는 TCPPING
프로토콜을 사용하여 정적 클러스터 멤버십 목록을 정의하는 새 JGroups 스택을 생성합니다. tcpping
스택을 만들고 이 새 스택을 사용하도록 default ee
채널을 설정하는 기본 스크립트가 제공됩니다. 이 스크립트의 관리 CLI 명령은 사용자 환경에 맞게 사용자 지정해야 하며 배치로 처리됩니다.
다음 스크립트를 텍스트 편집기에 복사하여 로컬 파일 시스템에 저장합니다.
# Define the socket bindings /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-a:add(host=HOST_A,port=7600) /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-b:add(host=HOST_B,port=7600) batch # Add the tcpping stack /subsystem=jgroups/stack=tcpping:add /subsystem=jgroups/stack=tcpping/transport=TCP:add(socket-binding=jgroups-tcp) /subsystem=jgroups/stack=tcpping/protocol=TCPPING:add(socket-bindings=[jgroups-host-a,jgroups-host-b]) /subsystem=jgroups/stack=tcpping/protocol=MERGE3:add /subsystem=jgroups/stack=tcpping/protocol=FD_SOCK:add /subsystem=jgroups/stack=tcpping/protocol=FD_ALL:add /subsystem=jgroups/stack=tcpping/protocol=VERIFY_SUSPECT:add /subsystem=jgroups/stack=tcpping/protocol=pbcast.NAKACK2:add /subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add /subsystem=jgroups/stack=tcpping/protocol=pbcast.STABLE:add /subsystem=jgroups/stack=tcpping/protocol=pbcast.GMS:add /subsystem=jgroups/stack=tcpping/protocol=MFC:add /subsystem=jgroups/stack=tcpping/protocol=FRAG3:add # Set tcpping as the stack for the ee channel /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcpping) run-batch reload
정의된 프로토콜 순서가 중요합니다.
add-index 값을 add
명령에 전달하여 특정 인덱스에 프로토콜을 삽입할 수도 있습니다.
인덱스는 0 기반이므로 다음 관리 CLI 명령은UNICAST3
프로토콜을 7번째 프로토콜로 추가합니다./subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add(add-index=6)
환경에 맞게 스크립트를 수정합니다.
-
관리형 도메인에서 실행 중인 경우 /
profile=PROFILE_NAME
을 사용하여/subsystem=jgroups
명령 앞에 업데이트할 프로필을 지정해야 합니다. 환경에 따라 다음 속성을 조정합니다.
-
socket-bindings
: 잘 알려져 초기 멤버십을 조회하는 데 사용할 수 있는 호스트와 포트 조합의 쉼표로 구분된 목록입니다. 소켓 바인딩 정의에 대한 자세한 내용은 소켓 바인딩 구성을 참조하십시오. -
initial_hosts
:HOST[PORT]
구문을 사용하여 호스트 및 포트 조합의 쉼표로 구분된 목록으로 잘 알려져 초기 멤버십을 조회할 수 있습니다(예:host1[1000],host2[2000]
). -
port_range
: 이 속성은initial_hosts
포트 범위를 지정된 값으로 확장하는 데 사용됩니다. 예를 들어initial_hosts
를host1[1000],host2[2000]
로 설정하고port_range
를1
로 설정하면initial_hosts
설정이host1[1000],host1[1001],host2[2000],host2[2001]
로 확장됩니다. 이 속성은initial_hosts
속성에서만 작동합니다.
-
-
관리형 도메인에서 실행 중인 경우 /
스크립트 파일을 관리 CLI에 전달하여 스크립트를 실행합니다.
$ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME
TCPPING 스택을 사용할 수 있으며 TCP는 네트워크 통신에 사용됩니다.
24.2.3.1. 독립 실행형 모드로 TCPPING 구성
이 절차에서는 독립 실행형 모드에서 클러스터된 애플리케이션에 대한 TCP 스택 및 노드를 구성하는 데 도움이 됩니다.
절차
기본 스택을 OPENSHIFT 하위 시스템에서
udp
에서tcp
로 변경합니다.<channel name="ee" stack="tcp" cluster="ejb"/>
기본 MPING 프로토콜 대신 TCPPING 프로토콜을 사용하도록 TCP 스택을 구성합니다. 다음 코드에서
initial_hosts
속성은 클러스터 내의 모든 노드 목록과 상관 관계가 있으며7600
은 구성 및 환경에 따라 다를 수 있는 기본 RuntimeClass-tcp
포트를 나타냅니다.<stack name="tcp"> <transport type="TCP" socket-binding="jgroups-tcp"/> <protocol type="TCPPING"> <property name="initial_hosts">192.168.1.5[7600],192.168.1.9[7600]</property> <property name="port_range">0</property> </protocol> <protocol type="MERGE3"/> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="MFC"/> <protocol type="FRAG3"/> </stack>
참고initial_hosts
에 설정된 포트 번호7600
은 RuntimeClass-tcp
소켓 바인딩 정의에 정의된 포트 번호와 동일해야 합니다. socket-binding에 port-offset 기능을 사용하는 경우initial_hosts
에서 오프셋 후 동일한 값을 지정해야 합니다.NotReady 구성 요소에서 사용하는 개인 인터페이스의 IP 주소를 설정합니다. IP 주소는
initial_hosts
에 지정된 IP 주소 중 하나와 상관 관계가 있어야 합니다.<interface name="private"> <inet-address value="${jboss.bind.address.private:192.168.1.5}"/> </interface>
- 클러스터 내의 다른 노드를 구성하려면 위의 단계를 반복합니다. 노드가 구성되면 각 노드를 시작하고 클러스터된 애플리케이션을 배포합니다.
검증
로그를 확인하여 노드가 실행 중인지 확인할 수 있습니다.
INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,node_1) ISPN000094: Received new cluster view for channel server: [node_1|1] (2) [node_1, node_2] INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,node_1) ISPN000094: Received new cluster view for channel web: [node_1|1] (2) [node_1, node_2]
24.2.3.2. 도메인 모드에서 TCPPING 구성
이 절차에서는 도메인 모드에서 클러스터된 애플리케이션에 대한 TCP 스택 및 노드를 구성하는 데 도움이 됩니다.
절차
여러 클러스터에 동일한 프로필이 사용되는 경우 system 속성 값을
initial_hosts
로 설정합니다.<protocol type="TCPPING"> <property name="initial_hosts">${jboss.cluster.tcp.initial_hosts}</property> Set the system property at the `server-group` level: <server-groups> <server-group name="a-server-group" profile="ha"> <socket-binding-group ref="ha-sockets"/> <system-properties> <property name="jboss.cluster.tcp.initial_hosts" value="192.168.1.5[7600],192.168.1.9[7600]" /> </system-properties>
호스트 컨트롤러의 XML 구성 내에서 개인 인터페이스의 IP 주소를 설정합니다. 개인 인터페이스의 IP 주소는
initial_hosts
에 나열된 IP 주소 중 하나와 상관 관계가 있어야 합니다.<interfaces> .... <interface name="private"> <inet-address value="${jboss.bind.address.private:192.168.1.5}"/> </interface> </interfaces>
검증
로그를 확인하여 노드가 실행 중인지 확인할 수 있습니다.
INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,node_1) ISPN000094: Received new cluster view for channel server: [node_1|1] (2) [node_1, node_2] INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,node_1) ISPN000094: Received new cluster view for channel web: [node_1|1] (2) [node_1, node_2]
24.2.4. TCPGOSSIP 구성
이 절차에서는 TCPGOSSIP
프로토콜을 사용하여 외부 gossip 라우터를 사용하여 클러스터의 구성원을 검색하는 새 JGroups 스택을 생성합니다. tcpgossip
스택을 생성하고 이 새 스택을 사용하도록 default ee
채널을 설정하는 기본 스크립트가 제공됩니다. 이 스크립트의 관리 CLI 명령은 사용자 환경에 맞게 사용자 지정해야 하며 배치로 처리됩니다.
다음 스크립트를 텍스트 편집기에 복사하여 로컬 파일 시스템에 저장합니다.
# Define the socket bindings /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-a:add(host=HOST_A,port=13001) batch # Add the tcpgossip stack /subsystem=jgroups/stack=tcpgossip:add /subsystem=jgroups/stack=tcpgossip/transport=TCP:add(socket-binding=jgroups-tcp) /subsystem=jgroups/stack=tcpgossip/protocol=TCPGOSSIP:add(socket-bindings=[jgroups-host-a]) /subsystem=jgroups/stack=tcpgossip/protocol=MERGE3:add /subsystem=jgroups/stack=tcpgossip/protocol=FD_SOCK:add /subsystem=jgroups/stack=tcpgossip/protocol=FD_ALL:add /subsystem=jgroups/stack=tcpgossip/protocol=VERIFY_SUSPECT:add /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.NAKACK2:add /subsystem=jgroups/stack=tcpgossip/protocol=UNICAST3:add /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.STABLE:add /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.GMS:add /subsystem=jgroups/stack=tcpgossip/protocol=MFC:add /subsystem=jgroups/stack=tcpgossip/protocol=FRAG3:add # Set tcpgossip as the stack for the ee channel /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcpgossip) run-batch reload
정의된 프로토콜 순서가 중요합니다.
add-index 값을 add
명령에 전달하여 특정 인덱스에 프로토콜을 삽입할 수도 있습니다.
인덱스는 0 기반이므로 다음 관리 CLI 명령은UNICAST3
프로토콜을 7번째 프로토콜로 추가합니다./subsystem=jgroups/stack=tcpgossip/protocol=UNICAST3:add(add-index=6)
환경에 맞게 스크립트를 수정합니다.
-
관리형 도메인에서 실행 중인 경우 /
profile=PROFILE_NAME
을 사용하여/subsystem=jgroups
명령 앞에 업데이트할 프로필을 지정해야 합니다. 환경에 따라 다음 속성을 조정합니다.
-
socket-bindings
: 잘 알려져 초기 멤버십을 조회하는 데 사용할 수 있는 호스트와 포트 조합의 쉼표로 구분된 목록입니다. 소켓 바인딩 정의에 대한 자세한 내용은 소켓 바인딩 구성을 참조하십시오. -
initial_hosts
:HOST[PORT]
구문을 사용하여 호스트 및 포트 조합의 쉼표로 구분된 목록으로 잘 알려져 초기 멤버십을 조회할 수 있습니다(예:host1[1000],host2[2000]
). -
port_range
: 이 속성은initial_hosts
포트 범위를 지정된 값으로 확장하는 데 사용됩니다. 예를 들어initial_hosts
를host1[1000],host2[2000]
로 설정하고port_range
를1
로 설정하면initial_hosts
설정이host1[1000],host1[1001],host2[2000],host2[2001]
로 확장됩니다. 이 속성은initial_hosts
속성에서만 작동합니다. -
reconnect_interval
: 연결이 끊긴 스텁이 gossip 라우터에 다시 연결을 시도하는 간격(밀리초)입니다. -
sock_conn_timeout
: 소켓 생성을 위한 최대 시간. 기본값은1000
밀리초입니다. -
sock_read_timeout
: 읽기에서 차단할 최대 시간(밀리초)입니다. 값0
은 무기한 차단됩니다.
-
-
관리형 도메인에서 실행 중인 경우 /
스크립트 파일을 관리 CLI에 전달하여 스크립트를 실행합니다.
$ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME
이제 TCPGOSSIP 스택을 사용할 수 있으며 TCP는 네트워크 통신에 사용됩니다. 이 스택은 JGroups 클러스터 구성원이 다른 클러스터 구성원을 찾을 수 있도록 gossip 라우터와 함께 사용하도록 구성됩니다.
24.2.5. JDBC_PING 구성
JDBC_PING
프로토콜을 사용하여 클러스터에서 멤버십을 관리하고 검색할 수 있습니다.
JDBC_PING는 data-source에 지정된 데이터베이스를 사용하여 클러스터의 구성원을 나열합니다.
- 클러스터 멤버십을 관리하는 데 사용할 데이터베이스에 연결하는 데이터 소스를 생성합니다.
다음 스크립트를 텍스트 편집기에 복사하여 로컬 파일 시스템에 저장합니다.
batch # Add the JDBC_PING stack /subsystem=jgroups/stack=JDBC_PING:add /subsystem=jgroups/stack=JDBC_PING/transport=TCP:add(socket-binding=jgroups-tcp) /subsystem=jgroups/stack=JDBC_PING/protocol=JDBC_PING:add(data-source=ExampleDS) /subsystem=jgroups/stack=JDBC_PING/protocol=MERGE3:add /subsystem=jgroups/stack=JDBC_PING/protocol=FD_SOCK:add /subsystem=jgroups/stack=JDBC_PING/protocol=FD_ALL:add /subsystem=jgroups/stack=JDBC_PING/protocol=VERIFY_SUSPECT:add /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.NAKACK2:add /subsystem=jgroups/stack=JDBC_PING/protocol=UNICAST3:add /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.STABLE:add /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.GMS:add /subsystem=jgroups/stack=JDBC_PING/protocol=MFC:add /subsystem=jgroups/stack=JDBC_PING/protocol=FRAG3:add # Set JDBC_PING as the stack for the ee channel /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=JDBC_PING) run-batch reload
정의된 프로토콜 순서가 중요합니다.
add-index 값을 add
명령에 전달하여 특정 인덱스에 프로토콜을 삽입할 수도 있습니다.
인덱스는 0 기반이므로 다음 관리 CLI 명령은UNICAST3
프로토콜을 7번째 프로토콜로 추가합니다./subsystem=jgroups/stack=JDBC_PING/protocol=UNICAST3:add(add-index=6)
환경에 맞게 스크립트를 수정합니다.
-
관리형 도메인에서 실행 중인 경우 /
profile=PROFILE_NAME
을 사용하여/subsystem=jgroups
명령 앞에 업데이트할 프로필을 지정해야 합니다. - ExampleDS를 1단계에서 정의한 데이터 소스의 이름으로 바꿉니다.
-
관리형 도메인에서 실행 중인 경우 /
스크립트 파일을 관리 CLI에 전달하여 스크립트를 실행합니다.
$ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME
JDBC_PING 스택을 사용할 수 있으며 TCP는 네트워크 통신에 사용됩니다.
관련 정보
jdbc_PING: https://developer.jboss.org/wiki/JDBCPING
데이터 소스 생성: JBoss EAP 데이터 소스 정보
24.2.6. 네트워크 인터페이스에 JGroups 바인딩
기본적으로 JGroups는 기본 구성에서 localhost를 가리키는 사설
네트워크 인터페이스에만 바인딩됩니다. 보안상의 이유로 JGroups는 공용 네트워크 인터페이스에 클러스터링 트래픽을 노출해서는 안 되기 때문에 JBoss EAP 시작 중에 지정된 -b
인수로 정의된 네트워크 인터페이스에 바인딩하지 않습니다.
네트워크 인터페이스를 구성하는 방법에 대한 자세한 내용은 이 가이드의 네트워크 및 포트 구성 장을 참조하십시오.
보안상의 이유로 JGroups는 비공용 네트워크 인터페이스에만 바인딩되어야 합니다. 성능상의 이유로 JGroups 트래픽의 네트워크 인터페이스가 전용 VLAN(Virtual Local Area Network)의 일부여야 합니다.
24.2.7. 클러스터 보안
클러스터를 안전하게 실행하기 위해서는 다음과 같은 몇 가지 문제가 있습니다.
- 권한 없는 노드가 클러스터에 참여하지 못하게 합니다. 이는 인증이 필요하여 해결됩니다.
- 비 구성원이 클러스터 구성원과 통신하지 못하도록 합니다. 이러한 문제는 메시지를 암호화하여 처리됩니다.
24.2.7.1. 인증 구성
JGroups 인증은 AUTH
프로토콜에서 수행합니다. 목표는 인증된 노드만 클러스터에 참여할 수 있도록 하는 것입니다.
적용 가능한 서버 구성 파일에서 적절한 속성 설정을 사용하여 AUTH
프로토콜을 추가합니다. The AUTH
프로토콜은 pbcast.GMS
프로토콜 바로 앞에 구성해야 합니다.
다음 예제에서는 권한 부여 토큰의 형태가 다른 AUTH
를 사용하는 방법을 보여줍니다.
간단한 토큰이 있는 AUTH
...
<protocol type="pbcast.STABLE"/>
<auth-protocol type="AUTH">
<plain-token>
<shared-secret-reference clear-text="my_password"/>
</plain-token>
</auth-protocol>
<protocol type="pbcast.GMS"/>
...
다이제스트 알고리즘 토큰이 있는 AUTH
이 형식은 다이제스트 알고리즘(예: MD5 또는 SHA-2)과 함께 사용할 수 있습니다. JBoss EAP 7.4의 기본 다이제스트 알고리즘은 JVM에서 지원하는 데 필요한 강력한 다이제스트 알고리즘인 SHA-256입니다. 대부분의 JVM은 SHA-512를 추가로 구현합니다.
...
<protocol type="pbcast.STABLE"/>
<auth-protocol type="AUTH">
<digest-token algorithm="SHA-512">
<shared-secret-reference clear-text="my_password"/>
</digest-token>
</auth-protocol>
<protocol type="pbcast.GMS"/>
...
X509 토큰이 있는 AUTH
이 예제에서는 elytron
하위 시스템에서 새 키 저장소를 생성하고 JGroups AUTH
구성에서 참조합니다.
키 저장소를 생성합니다.
$ keytool -genkeypair -alias jgroups_key -keypass my_password -storepass my_password -storetype jks -keystore jgroups.keystore -keyalg RSA
관리 CLI를 사용하여
elytron
하위 시스템에 키 저장소를 추가합니다./subsystem=elytron/key-store=jgroups-token-store:add(type=jks,path=/path/to/jgroups.keystore,credential-reference={clear-text=my_password}, required=true)
JGroups 스택 정의에서 키 저장소를 사용하도록
AUTH
를 구성합니다.... <protocol type="pbcast.STABLE"/> <auth-protocol type="AUTH"> <cipher-token algorithm="RSA" key-alias="jgroups_key" key-store="jgroups-token-store"> <shared-secret-reference clear-text="my_password"/> <key-credential-reference clear-text="my_password"/> </cipher-token> </auth-protocol> <protocol type="pbcast.GMS"/> ...
24.2.7.2. 암호화 구성
메시지를 암호화하기 위해 JGroups는 클러스터의 구성원이 공유하는 비밀 키를 사용합니다. 발신자는 공유 비밀 키를 사용하여 메시지를 암호화하고 수신자는 동일한 비밀 키를 사용하여 메시지를 암호 해독합니다. SYM_ENCRYPT
프로토콜을 사용하여 구성된 대칭 암호화 에서는 노드에서 공유 키 저장소를 사용하여 비밀 키를 검색합니다. ASYM_ENCRYPT
프로토콜을 사용하여 구성된 비대칭 암호화를 사용하면 노드는 AUTH
를 사용하여 인증한 후 클러스터의 코디네이터에서 비밀 키를 검색합니다.
대칭 암호화 사용
SYM_ENCRYPT
를 사용하려면 각 노드의 JGroups 구성에서 참조할 키 저장소를 설정해야 합니다.
키 저장소를 생성합니다.
다음 명령에서 VERSION을
적절한
JGroups JAR 버전으로 바꾸고PASSWORD
를 키 저장소 암호로 바꿉니다.$ java -cp EAP_HOME/modules/system/layers/base/org/jgroups/main/jgroups-VERSION.jar org.jgroups.demos.KeyStoreGenerator --alg AES --size 128 --storeName defaultStore.keystore --storepass PASSWORD --alias mykey
이렇게 하면 JGroups 구성에서 참조되는
기본Store.keystore
파일이 생성됩니다.키 저장소가 생성되면 두 가지 방법 중 하나를 사용하여
SYM_PROTOCOL
에 정의됩니다.
SYM_ENCRYPT
를 사용할 때 AUTH
구성은 선택 사항입니다.
키 저장소를 직접 참조하여 대칭 암호화 사용
jgroups
하위 시스템에서SYM_ENCRYPT
프로토콜을 구성합니다.적용 가능한 서버 구성 파일에서 적절한 속성 설정을 사용하여
SYM_ENCRYPT
프로토콜을 추가합니다. 이 프로토콜은 이전에 생성된 키 저장소를 참조합니다.SYM_ENCRYPT
프로토콜은pbcast.NAKACK2
프로토콜 전에 즉시 구성해야 합니다.<subsystem xmlns="urn:jboss:domain:jgroups:6.0"> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> <protocol type="MERGE3"/> <protocol type="FD_SOCK"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <protocol type="SYM_ENCRYPT"> <property name="provider">SunJCE</property> <property name="sym_algorithm">AES</property> <property name="encrypt_entire_message">true</property> <property name="keystore_name">/path/to/defaultStore.keystore</property> <property name="store_password">PASSWORD</property> <property name="alias">mykey</property> </protocol> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG3"/> </stack> </stacks> </subsystem>
Elytron으로 대칭 암호화 사용
관리 CLI를 사용하여 대칭 암호화를 사용하여 에 생성된
기본Store.keystore
를 참조하는elytron
하위 시스템에 키 저장소를 생성합니다./subsystem=elytron/key-store=jgroups-keystore:add(path=/path/to/defaultStore.keystore,credential-reference={clear-text=PASSWORD},type=JCEKS)
적절한 속성 설정을 사용하여
jgroups
하위 시스템에SYM_ENCRYPT
프로토콜을 추가합니다.SYM_ENCRYPT
프로토콜은 다음 설정에서 볼 수 있듯이pbcast.NAKACK2
프로토콜 바로 앞에 구성해야 합니다.<subsystem xmlns="urn:jboss:domain:jgroups:6.0"> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> <protocol type="MERGE3"/> <protocol type="FD_SOCK"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <encrypt-protocol type="SYM_ENCRYPT" key-alias="mykey" key-store="jgroups-keystore"> <key-credential-reference clear-text="PASSWORD"/> <property name="provider">SunJCE</property> <property name="encrypt_entire_message">true</property> </encrypt-protocol> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG3"/> </stack> </stacks> </subsystem>
참고위의 예제에서는 일반 텍스트 암호를 사용하지만 구성 파일 외부에서 암호를 정의하도록 자격 증명 저장소를 정의할 수도 있습니다. 이 저장소 구성에 대한 자세한 내용은 How to Configure Server Security Guide의 Credential Store 섹션을 참조하십시오.
비대칭 암호화 사용
ASYM_ENCRYPT
를 사용하려면 AUTH
프로토콜을 정의해야 합니다. jgroups
하위 시스템에서 AUTH
프로토콜을 구성하는 방법에 대한 지침은 인증 구성 섹션을 참조하십시오.
ASYM_ENCRYPT
는 두 가지 방법 중 하나를 사용하여 구성됩니다.
- 시크릿 키를 생성하고 구성에서 직접 참조합니다.
- 키 저장소를 생성하고 Elytron 하위 시스템을 사용하여 참조합니다.
비밀 키를 생성하여 비대칭 암호화 사용
jgroups
하위 시스템에서ASYM_ENCRYPT
프로토콜을 구성합니다.적용 가능한 서버 구성 파일에서 적절한 속성 설정을 사용하여
ASYM_ENCRYPT
프로토콜을 추가합니다. 다음 설정에서 볼 수 있듯이ASYM_ENCRYPT
프로토콜은pbcast.NAKACK2
프로토콜 바로 앞에 구성해야 합니다.<subsystem xmlns="urn:jboss:domain:jgroups:6.0"> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> <protocol type="MERGE3"/> <protocol type="FD_SOCK"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <protocol type="ASYM_ENCRYPT"> <property name="encrypt_entire_message">true</property> <property name="sym_keylength">128</property> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property> <property name="asym_keylength">512</property> <property name="asym_algorithm">RSA</property> </protocol> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <!-- Configure AUTH protocol here --> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG3"/> </stack> </stacks> </subsystem>
Elytron으로 비대칭 암호화 사용
키 쌍을 포함할 키 저장소를 생성합니다. 다음 명령은
mykey
항목을 사용하여 키 저장소를 생성합니다.$ keytool -genkeypair -alias mykey -keyalg RSA -keysize 1024 -keystore defaultKeystore.keystore -dname "CN=localhost" -keypass secret -storepass secret
관리 CLI를 사용하여
defaultStore.keystore
를 참조하는elytron
하위 시스템에서 키 저장소를 생성합니다./subsystem=elytron/key-store=jgroups-keystore:add(path=/path/to/defaultStore.keystore,credential-reference={clear-text=PASSWORD},type=JCEKS)
적절한 속성 설정을 사용하여
jgroups
하위 시스템에ASYM_ENCRYPT
프로토콜을 추가합니다. 다음 설정에서 볼 수 있듯이ASYM_ENCRYPT
프로토콜은pbcast.NAKACK2
프로토콜 바로 앞에 구성해야 합니다.<subsystem xmlns="urn:jboss:domain:jgroups:6.0"> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> <protocol type="MERGE3"/> <protocol type="FD_SOCK"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <encrypt-protocol type="ASYM_ENCRYPT" key-alias="mykey" key-store="jgroups-keystore"> <key-credential-reference clear-text="secret" /> <property name="encrypt_entire_message">true</property> </encrypt-protocol> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <!-- Configure AUTH protocol here --> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG3"/> </stack> </stacks> </subsystem>
참고위의 예제에서는 일반 텍스트 암호를 사용하지만 구성 파일 외부에서 암호를 정의하도록 자격 증명 저장소를 정의할 수도 있습니다. 이 저장소 구성에 대한 자세한 내용은 How to Configure Server Security Guide의 Credential Store 섹션을 참조하십시오.
24.2.8. JGroups 스레드 풀 구성
jgroups
하위 시스템에는 default
,internal
,oob
및 timer
스레드 풀이 포함되어 있습니다. 이러한 풀은 모든 NotReady 스택에 대해 구성할 수 있으며 로컬 노드에 구성된 빈 또는 다른 풀에는 영향을 미치지 않습니다. JGroup 스레드 풀은 클러스터 통신을 지원하는 데 사용됩니다.
다음 표에는 각 스레드 풀에 대해 구성할 수 있는 특성과 각 스레드 풀의 기본값이 나열되어 있습니다.
스레드 풀 이름 | 설명 | keepalive-time | max-threads | min-threads | queue-length |
---|---|---|---|---|---|
default | 이 풀은 대역 외로 표시되지 않는 수신 메시지를 처리하는 데 사용됩니다. | 60000L | 300 | 20 | 100 |
internal | 이 풀은 EAP 유지 관리에 필요한 내부 프로세스를 처리하는 데 사용됩니다. | 60000L | 4 | 2 | 100 |
OOB | 이 풀은 들어오는 대역 외 메시지를 처리하는 데 사용됩니다. | 60000L | 300 | 20 | 0 |
타이머 | 이 풀은 시간 바인딩된 스케줄러 메시지를 처리하는 데 사용됩니다. | 5000L | 4 | 2 | 500 |
다음 구문을 사용하여 관리 CLI를 사용하여 JGroups 스레드 풀을 구성합니다.
/subsystem=jgroups/stack=STACK_TYPE/transport=TRANSPORT_TYPE/thread-pool=THREAD_POOL_NAME:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)
다음은 udp
스택의 기본
스레드 풀에서 max-threads
값을 500
으로 설정하는 관리 CLI 명령의 예입니다.
/subsystem=jgroups/stack=udp/transport=UDP/thread-pool=default:write-attribute(name="max-threads", value="500")
24.2.9. JGroups 전송 및 버퍼 수신 구성
버퍼 크기 경고 해결
기본적으로 JGroups는 특정 전송 및 수신 버퍼 값으로 구성되지만 운영 체제는 사용 가능한 버퍼 크기를 제한할 수 있으며 JBoss EAP는 구성된 버퍼 값을 사용하지 못할 수 있습니다. 이 경우 다음과 유사한 JBoss EAP 로그에 경고가 표시됩니다.
WARNING [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 68) JGRP000015: the send buffer of socket DatagramSocket was set to 640KB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux) WARNING [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 68) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
이 문제를 해결하려면 운영 체제 설명서에서 버퍼 크기를 늘리는 방법에 대한 지침을 참조하십시오. Red Hat Enterprise Linux 시스템의 경우 /etc/sysctl.conf
를 루트 사용자로 편집하여 시스템 재시작 후에도 유지되는 버퍼 크기의 최대 값을 구성합니다. 예를 들면 다음과 같습니다.
# Allow a 25MB UDP receive buffer for JGroups net.core.rmem_max = 26214400 # Allow a 1MB UDP send buffer for JGroups net.core.wmem_max = 1048576
/etc/sysctl.conf
를 수정한 후 sysctl -p
를 실행하여 변경 사항을 적용합니다.
JGroups 버퍼 크기 구성
UDP 및 TCP JGroups 스택에서 다음 전송 속성을 설정하여 JBoss EAP에서 사용하는 JGroups 버퍼 크기를 구성할 수 있습니다.
- UDP 스택
-
ucast_recv_buf_size
-
ucast_send_buf_size
-
mcast_recv_buf_size
-
mcast_send_buf_size
-
- TCP 스택
-
recv_buf_size
-
send_buf_size
-
JGroups 버퍼 크기는 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다.
관리 CLI로 JGroups 버퍼 크기 속성을 설정하려면 다음 구문을 사용합니다.
/subsystem=jgroups/stack=STACK_NAME/transport=TRANSPORT/property=PROPERTY_NAME:add(value=BUFFER_SIZE)
다음은 tcp
스택에서 Rec v_buf_size
속성을 20000000
으로 설정하는 예제 관리 CLI 명령입니다.
/subsystem=jgroups/stack=tcp/transport=TRANSPORT/property=recv_buf_size:add(value=20000000)
JGroups 버퍼 크기는 Configuration (구성) 탭에서 JGroups 하위 시스템으로 이동하고 View (보기), Stack (스택) 탭 선택, 적절한 스택을 선택하고, 전송( Transport )을 클릭하고 Properties (속성) 필드를 편집하여 관리 콘솔을 사용하여 구성할 수도 있습니다.
24.2.10. JGroups 하위 시스템 튜닝
jgroups
하위 시스템의 성능 모니터링 및 최적화에 대한 팁은 성능 튜닝 가이드의 JGroups 하위 시스템 튜닝 섹션을 참조하십시오.
24.2.11. JGroups 문제 해결
24.2.11.1. 노드가 클러스터를 구성하지 않음
시스템이 IP 멀티캐스트에 대해 올바르게 설정되었는지 확인합니다. 다음은 IP 멀티캐스트를 테스트하는 데 사용할 수 있는 JBoss EAP와 함께 제공되는 두 가지 테스트 프로그램입니다. McastReceiverTest
및 McastSenderTest
.
터미널에서 McastReceiverTest
를 시작합니다.
$ java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastReceiverTest -mcast_addr 230.11.11.11 -port 5555
다른 터미널 창에서 McastSenderTest
를 시작합니다.
$ java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastSenderTest -mcast_addr 230.11.11.11 -port 5555
특정 NIC(네트워크 인터페이스 카드)에 바인딩하려면 -bind_addr YOUR_BIND_ADDRESS
를 사용합니다. 여기서 YOUR_BIND_ADDRESS
는 바인딩하려는 NIC의 IP 주소입니다. 발신자 및 수신자 모두에서 이 매개변수를 사용합니다.
McastSenderTest
터미널 창을 입력하면 McastReceiverTest
창에 출력이 표시됩니다. 그렇지 않은 경우 다음 단계를 시도합니다.
-
발신자 명령에
-ttl VALUE
를 추가하여 멀티캐스트 패킷의 TTL(Time-to-Live)을 늘립니다. 이 테스트 프로그램에서 사용하는 기본값은32
이고VALUE
는255
보다 크지 않아야 합니다. - 시스템에 여러 인터페이스가 있는 경우 올바른 인터페이스를 사용 중인지 확인합니다.
- 선택한 인터페이스에서 멀티 캐스트가 작동하는지 확인하려면 시스템 관리자에게 문의하십시오.
멀티 캐스트가 클러스터의 각 시스템에서 제대로 작동하고 나면 위의 테스트를 반복하여 네트워크를 테스트하고 발신자를 한 시스템에 배치하고 수신자를 다른 시스템에 배치할 수 있습니다.
24.2.11.2. 오류 감지에서 부정중한 Heartbeat의 원인
경우에 따라 시간 제한
및 max_tries
로 정의되는 T
시간 동안 하트비트 승인이 수신되지 않았기 때문에 클러스터 구성원이 FD(실패 탐지)로 의심되는 경우가 있습니다.
A, B, C 및 D 노드의 예를 들어 A, B pings, B pings C, C ping D 및 D pings A가 있는 클러스터의 경우 다음과 같은 이유로 C가 의심될 수 있습니다.
-
B 또는 C는
T
초 이상 100% CPU에서 실행됩니다. 따라서 C가 하트비트 승인을 B로 보내더라도 B는 100% CPU 사용량이기 때문에 이를 처리하지 못할 수 있습니다. - B 또는 C는 가비지 수집이며 위와 동일한 상황이 발생합니다.
- 위의 두 가지 사례의 조합.
- 네트워크에서 패킷이 손실됩니다. 이는 일반적으로 네트워크에 많은 트래픽이 있고 스위치가 패킷 삭제를 시작하고, 일반적으로 먼저 브로드캐스트되고, IP 멀티캐스트 및 TCP 패킷이 지속되기 시작합니다.
-
B 또는 C가 콜백을 처리합니다. 예를 들어 C가 처리할
T
+ 1초가 걸리는 채널을 통해 원격 메서드 호출을 수신하면 이 시간 동안 C는 하트비트를 포함한 다른 메시지를 처리하지 않습니다. 따라서 B는 하트비트 승인을 받지 않으며 C.
24.3. Infinispan
24.3.1. Infinispan 정보
Infinispan은 캐시된 데이터를 관리하기 위해 Jakarta Persistence 2.2와 호환 가능한 캐시 인터페이스를 제공하는 Java 데이터 그리드 플랫폼입니다.
jenkinsfile 기능 및 구성 옵션에 대한 자세한 내용은 jenkinsfile 설명서를 참조하십시오.
infinispan
하위 시스템은 JBoss EAP에 대한 캐싱 지원을 제공합니다. 이를 통해 이름이 지정된 캐시 컨테이너 및 캐시에 대한 런타임 지표를 구성하고 볼 수 있습니다.
관리형 도메인의 ha 또는 full-ha 프로필 또는 독립 실행형 서버에 대한 standalone-ha
.xml 또는 standalone-full-ha.xml
구성 파일과 같은 고가용성 기능을 제공하는 구성을 사용하는 경우 infinispan
하위 시스템은 캐싱, 상태 복제 및 상태 배포 지원을 제공합니다. 고가용성이 아닌 구성에서 infinispan
하위 시스템은 로컬 캐싱 지원을 제공합니다.
jenkinsfile은 JBoss EAP 7.4의 공용 모듈입니다. 애플리케이션에 infinispan
하위 시스템을 사용하여 새 cache-containers 또는 캐시를 생성하고 사용할 수 있습니다. 또한 jenkinsfile API 사용은 애플리케이션에서 지원됩니다.
24.3.2. 캐시 컨테이너
캐시 컨테이너는 하위 시스템에서 사용하는 캐시의 리포지토리입니다. 각 캐시 컨테이너는 사용할 기본 캐시를 정의합니다.
JBoss EAP 7은 다음과 같은 기본 Infinispan 캐시 컨테이너를 정의합니다.
-
Singleton 캐싱을 위한
서버
-
웹
세션 클러스터링을 위한 웹 -
상태 저장 세션 빈 클러스터링을
위한
EJB -
엔터티 캐싱을 위한
Hibernate
예제: 기본 Infinispan 구성
<subsystem xmlns="urn:jboss:domain:infinispan:7.0"> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server"> <transport lock-timeout="60000"/> <replicated-cache name="default"> <transaction mode="BATCH"/> </replicated-cache> </cache-container> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan"> <transport lock-timeout="60000"/> <distributed-cache name="dist"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <file-store/> </distributed-cache> </cache-container> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> <transport lock-timeout="60000"/> <distributed-cache name="dist"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <file-store/> </distributed-cache> </cache-container> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan"> <transport lock-timeout="60000"/> <local-cache name="local-query"> <object-memory size="1000"/> <expiration max-idle="100000"/> </local-cache> <invalidation-cache name="entity"> <transaction mode="NON_XA"/> <object-memory size="1000"/> <expiration max-idle="100000"/> </invalidation-cache> <replicated-cache name="timestamps" mode="ASYNC"/> </cache-container> </subsystem>
각 캐시 컨테이너에 정의된 기본 캐시를 확인합니다. 예를 들어 웹
캐시 컨테이너는 dist
분산 캐시를 기본값으로 정의합니다. 따라서 웹 세션을 클러스터링할 때 dist
캐시가 사용됩니다.
기본 캐시 변경 및 추가 캐시 추가에 대한 자세한 내용은 캐시 컨테이너 구성에서 참조하십시오.
24.3.2.1. 캐시 컨테이너 구성
관리 콘솔 또는 관리 CLI를 사용하여 캐시 컨테이너 및 캐시 특성을 구성할 수 있습니다.
구성의 다른 구성 요소가 이를 참조할 수 있으므로 캐시 또는 캐시 컨테이너 이름 변경을 피해야 합니다.
24.3.2.1.1. 관리 콘솔을 사용하여 캐시 구성
관리 콘솔의 Configuration(구성 ) 탭에서 Infinispan 하위 시스템으로 이동한 후 캐시 및 캐시 컨테이너를 구성할 수 있습니다. 관리형 도메인에서 구성할 적절한 프로필을 선택해야 합니다.
캐시 컨테이너 추가.
Cache Container 제목 옆에 있는 Add (+) 단추를 클릭하고 Add Cache Container (캐시 컨테이너 추가)를 선택한 다음 새 캐시 컨테이너의 설정을 입력합니다.
캐시 컨테이너 설정 업데이트.
적절한 캐시 컨테이너를 선택하고 View(보기 )를 클릭합니다. 필요에 따라 캐시 컨테이너 설정을 구성합니다.
캐시 컨테이너 전송 설정 업데이트.
적절한 캐시 컨테이너를 선택하고 View(보기 )를 클릭합니다. Transport (전송) 탭을 선택하고 필요에 따라 캐시 컨테이너 전송 설정을 구성합니다.
캐시 구성.
적절한 캐시 컨테이너를 선택하고 View(보기 )를 클릭합니다. 적절한 캐시 탭(예: 복제된 캐시 )에서 캐시를 추가, 업데이트 및 제거할 수 있습니다.
24.3.2.1.2. 관리 CLI를 사용하여 캐시 구성
관리 CLI를 사용하여 캐시 및 캐시 컨테이너를 구성할 수 있습니다. 관리형 도메인에서는 이러한 명령 앞에 /profile=PROFILE_NAME
을 사용하여 업데이트할 프로필을 지정해야 합니다.
캐시 컨테이너 추가.
/subsystem=infinispan/cache-container=CACHE_CONTAINER:add
복제된 캐시 추가.
/subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE:add(mode=MODE)
캐시 컨테이너의 기본 캐시 설정.
/subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=default-cache,value=CACHE)
복제된 캐시에 대한 배치 구성.
/subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE/component=transaction:write-attribute(name=mode,value=BATCH)
다음 예제에서는 동시
분산 캐시를 웹
캐시 컨테이너에 추가하는 방법을 보여줍니다. 이 캐시 구성을 사용하면 기본 캐시의 잠금 제한 조건을 완화하여 여러 동시 요청이 동일한 웹 세션에 동시에 액세스할 수 있습니다. 이는 잠금 없이 읽기를 허용하고 배타적 잠금을 더 자주 얻을 수 있지만 더 짧은 기간 동안 이 작업을 수행합니다.
다음 관리 CLI 명령을 사용하여 동시
분산된 캐시를 웹
캐시 컨테이너에 추가하고 기본 캐시로 설정합니다.
batch /subsystem=infinispan/cache-container=web/distributed-cache=concurrent:add /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=concurrent) /subsystem=infinispan/cache-container=web/distributed-cache=concurrent/store=file:add run-batch
이렇게 하면 다음과 같은 서버 구성이 생성됩니다.
<cache-container name="web" default-cache="concurrent" module="org.wildfly.clustering.web.infinispan"> ... <distributed-cache name="concurrent"> <file-store/> </distributed-cache> </cache-container>
24.3.2.1.3. 기본 자카르타 Enterprise Cryostat 캐시 컨테이너 변경
아래 설명된 대로 ejb3
하위 시스템에서 캐시 컨테이너를 사용할 수 있습니다.
-
Jakarta Enterprise Beans 세션 빈의 비활성화를 지원하기 위해
infinispan
하위 시스템에 정의된ejb
캐시 컨테이너를 사용하여 세션을 저장할 수 있습니다. - 서버에서 클러스터형 배포에 연결하는 원격 Jakarta Enterprise Beans 클라이언트의 경우, 상호 작용하는 노드가 실패하는 경우 클러스터의 다른 노드로 페일오버할 수 있도록 이러한 클라이언트에 클러스터 토폴로지 정보를 제공해야 합니다.
비활성화 및 토폴로지 정보 프로비저닝을 지원하는 ejb
라는 기본 캐시 컨테이너의 이름을 변경하거나 변경하는 경우 아래 예제와 같이 cache
-container
특성을 passivation-stores요소
및 클러스터
특성에 추가해야 합니다. 사용할 수 있도록 새 캐시를 추가하는 경우 이러한 변경을 수행하지 않아도 됩니다.
<subsystem xmlns="urn:jboss:domain:ejb3:5.0"> <passivation-stores> <passivation-store name="infinispan" cache-container="ejb-cltest" max-size="10000"/> </passivation-stores> <remote cluster="ejb-cltest" connectors="http-remoting-connector" thread-pool-name="default"/> </subsystem> <subsystem xmlns="urn:jboss:domain:infinispan:7.0"> ... <cache-container name="ejb-cltest" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> </subsystem>
24.3.2.1.4. Infinispan 하위 시스템에서 리소스를 Jakarta EE 애플리케이션에 삽입
@Resource
주석을 사용하여 Infinispan 하위 시스템에서 애플리케이션에 캐시와 같은 Infinispan 리소스를 삽입할 수 있습니다. 다음 예제에서는 @Resource
주석을 사용하여 Jakarta EE 애플리케이션에 캐시를 삽입하는 방법을 보여줍니다.
@Resource(lookup = "java:jboss/infinispan/cache/foo/bar") private org.infinispan.Cache<Integer, Object> cache;
위의 예에서 foo
는 캐시 컨테이너의 이름이며 bar
는 삽입할 캐시의 이름입니다.
EAP는 삽입된 리소스의 라이프사이클을 관리합니다. 즉, 애플리케이션은 캐시 또는 캐시 관리자와 같은 해당 리소스를 관리할 필요가 없습니다.
리소스를 수동으로 생성할 때 애플리케이션은 EAP가 아닌 해당 리소스를 관리합니다.
다음 예제에서는 Infinispan 하위 시스템의 다양한 리소스를 애플리케이션에 삽입하는 방법을 보여줍니다.
기본 캐시 삽입 예
Infinispan 하위 시스템의 캐시 컨테이너의 기본 캐시를 애플리케이션에 삽입하려면 다음 명령을 사용합니다.
@Resource(lookup = "java:jboss/infinispan/cache/foo/default")
임베디드 캐시 관리자 삽입 예
애플리케이션이 새 캐시 구성 및 캐시를 생성할 수 있도록 포함된 캐시 관리자를 삽입하려면 다음 명령을 사용합니다.
@Resource(lookup = "java:jboss/infinispan/container/foo") private org.infinispan.manager.EmbeddedCacheManager manager;
캐시 구성 삽입 예
Infinispan 하위 시스템 내에 정의된 모든 캐시 구성은 애플리케이션이 해당 캐시 구성에 명시적으로 종속되지 않는 한 항상 설치하거나 사용할 수 있는 것은 아닙니다. Infinispan 하위 시스템에서 캐시 구성을 애플리케이션에 삽입하려면 @Resource
주석을 사용합니다.
다음 예제에서는
@Resource
주석을 사용하여foo
컨테이너의 캐시 구성을 삽입합니다.@Resource(lookup = "java:jboss/infinispan/configuration/foo/bar") private org.infinispan.config.Configuration config;
다음 예제에서는
@Resource
주석을 사용하여foo
컨테이너의 기본 캐시 구성을 삽입합니다.@Resource(lookup = "java:jboss/infinispan/configuration/foo/default") private org.infinispan.config.Configuration config;
24.3.2.1.5. Hibernate 캐시 컨테이너의 제거 기능
hibernate
캐시 컨테이너의 제거 기능은 메모리에서 캐시 항목을 제거합니다. 이 기능은 하위 시스템의 메모리 로드를 줄이는 데 도움이 됩니다.
size
속성은 캐시 항목을 제거하기 전에 저장할 최대 캐시 항목 수를 설정합니다.
예제: 제거 기능
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan"> <transport lock-timeout="60000"/> <local-cache name="local-query"> <object-memory size="1000"/> <expiration max-idle="100000"/>
제거는 메모리 내에서만 수행됩니다. 캐시 저장소에는 정보가 영구적으로 손실되지 않도록 제거된 캐시 항목이 있습니다. 제거 기능에 대한 자세한 내용은 Infinispan 사용자 가이드 의 제거 및 데이터 컨테이너 섹션을 참조하십시오.
24.3.2.1.6. Hibernate 캐시 컨테이너의 만료 기능
vGPU 캐시 컨테이너
의 만료 기능은 클러스터형 작업입니다. 따라서 클러스터형 캐시를 사용하면 모든 클러스터 멤버에서 만료된 캐시 항목이 제거됩니다. 자세한 내용은 rhcos 사용자 가이드의 Expiration 섹션을 참조하십시오.
24.3.3. 클러스터링 모드
Infinispan을 사용하여 JBoss EAP의 두 가지 방법으로 클러스터링을 구성할 수 있습니다. 애플리케이션에 가장 적합한 방법은 요구 사항에 따라 달라집니다. 각 모드에 따라 가용성, 일관성, 안정성 및 확장성 사이에는 장단점이 있습니다. 클러스터링 모드를 선택하기 전에 네트워크의 가장 중요한 기능을 확인하고 해당 요구 사항의 균형을 조정해야 합니다.
캐시 모드
- 복제
- 복제 모드는 클러스터에 새 인스턴스를 자동으로 감지하고 추가합니다. 이러한 인스턴스의 변경 사항은 클러스터의 모든 노드에 복제됩니다. 복제 모드는 네트워크를 통해 복제해야 하는 정보의 양 때문에 일반적으로 소규모 클러스터에서 가장 효과적입니다. Infinispan은 네트워크 트래픽 정체를 어느 정도 완화하는 UDP 멀티캐스트를 사용하도록 구성할 수 있습니다.
- 콘텐츠 배포
배포 모드를 사용하면 Infinispan에서 클러스터를 선형으로 확장할 수 있습니다. 배포 모드에서는 일관된 해시 알고리즘을 사용하여 클러스터에서 새 노드를 배치해야 하는 위치를 결정합니다. 보관할 정보의 복사본 또는 소유자 수는 구성할 수 있습니다. 유지된 복사본 수, 데이터의 지속성 및 성능 사이에는 장단점이 있습니다. 유지되는 복사본이 많을수록 성능에 미치는 영향은 높지만 서버 장애 발생 시 데이터 손실이 줄어듭니다. 또한 해시 알고리즘은 멀티캐스팅 또는 메타데이터를 저장하지 않고 항목을 찾아 네트워크 트래픽을 줄이는 데 사용됩니다.
클러스터 크기가 6-8개의 노드를 초과할 때 배포 모드를 캐싱 전략으로 사용해야 합니다. 배포 모드를 사용하면 모든 노드가 아닌 클러스터 내의 노드 하위 집합에만 데이터가 배포됩니다.
- 분산됨
분산 모드는 일관된 해시 알고리즘을 사용하여 소유권을 결정한다는 점에서 배포 모드와 유사합니다. 그러나 소유권은 두 개의 구성원으로 제한되며, 시작자 또는 지정된 세션에 대한 요청을 수신하는 노드는 항상 잠금 및 캐시 항목 업데이트를 조정하는 데 대한 소유권을 가정합니다. 분산 모드에 사용된 캐시 쓰기 알고리즘은 쓰기 작업으로 인해 두 소유자가 있는 배포 캐시가 두 개의 RPC 호출을 사용할 수 있는 단일 RPC 호출만 발생하도록 보장합니다. 로드 밸런서 장애 조치(failover)는 기본이 아닌 소유자 또는 백업 노드로 트래픽을 전달하는 경향이 있기 때문에 분산 웹 세션에 유용할 수 있습니다. 이를 통해 클러스터 토폴로지 변경 후 경합을 잠재적으로 줄이고 성능을 향상시킬 수 있습니다.
분산 모드는 트랜잭션 또는 L1 캐싱을 지원하지 않습니다. 그러나 이 명령은 편향된 읽기를 지원하므로, 지정된 항목에 대한 캐시 쓰기를 시작하여 일관된 해시에 따라 소유자가 아니지만 일부 기간 동안 해당 항목에 대한 읽기를 계속할 수 있습니다. L1 캐싱과 유사하지만 편향된 읽기 특성과 L1 캐싱의 구성 특성은 별개입니다.
동기 및 비동기 복제
복제는 동기 또는 비동기 모드에서 수행할 수 있으며 선택한 모드는 요구 사항과 애플리케이션에 따라 달라집니다.
JBoss EAP 7.1 이후부터는 세션 복제에 항상 동기(SYNC) 캐시 모드를 사용해야 합니다. 또한
SYNC
가 기본 캐시 모드입니다. 세션 복제 및 적절한 캐시 모드에 대한 자세한 내용은 EAP에 대한 세션 복제를 구성하고 조정하는 방법을 참조하십시오.
- 동기 복제
- 동기 복제를 사용하면 복제 프로세스가 사용자 요청을 처리하는 동일한 스레드에서 실행됩니다. 세션 복제는 완료된 응답이 클라이언트로 다시 전송되고 복제가 완료된 후에만 스레드가 릴리스된 후에 시작됩니다. 동기 복제는 클러스터의 각 노드에서 응답해야 하므로 네트워크 트래픽에 영향을 미칩니다. 그러나 클러스터의 모든 노드에 모든 수정 사항이 적용되었는지 확인하는 이점이 있습니다.
- 비동기 복제
- 비동기 복제의 경우 Infinispan은 스레드 풀을 사용하여 백그라운드에서 복제를 수행합니다. 발신자는 클러스터의 다른 노드에서 응답을 기다리지 않습니다. 그러나 캐시는 오래된 데이터를 읽지 않도록 이전 복제가 완료될 때까지 차단됩니다. 복제는 한 번에 또는 대기열 크기로 트리거됩니다. 실패한 복제 시도는 로그에 기록되며 실시간으로 알림을 받지 않습니다.
24.3.3.1. 캐시 모드 설정
관리 CLI를 사용하여 기본 캐시를 변경할 수 있습니다.
이 섹션에서는 기본적으로 배포 모드인 웹 세션 캐시 구성과 관련된 지침을 보여줍니다. 단계 및 관리 CLI 명령은 다른 캐시 컨테이너에 적용하도록 쉽게 조정할 수 있습니다.
복제 캐시 모드로 변경
웹 세션 캐시에 대한 기본 JBoss EAP 7 구성에는 repl
복제 캐시가 포함되지 않습니다. 이 캐시를 먼저 추가해야 합니다.
아래 관리 CLI 명령은 독립 실행형 서버용입니다. 관리형 도메인에서 실행하는 경우 / profile=PROFILE_NAME
을 사용하여 /subsystem=infinispan
명령 앞에 업데이트할 프로필을 지정해야 합니다.
repl
복제 캐시를 추가하고 기본 캐시로 설정합니다.batch /subsystem=infinispan/cache-container=web/replicated-cache=repl:add() /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=transaction:add(mode=BATCH) /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=locking:add(isolation=REPEATABLE_READ) /subsystem=infinispan/cache-container=web/replicated-cache=repl/store=file:add /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=repl) run-batch
서버를 다시 로드합니다.
reload
분산 캐시 모드로 변경
웹 세션 캐시에 대한 기본 JBoss EAP 7 구성에는 이미 dist
배포 캐시가 포함되어 있습니다.
아래 관리 CLI 명령은 독립 실행형 서버용입니다. 관리형 도메인에서 실행하는 경우 / profile=PROFILE_NAME
을 사용하여 /subsystem=infinispan
명령 앞에 업데이트할 프로필을 지정해야 합니다.
기본 캐시를
dist 배포 캐시로
변경합니다./subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=dist)
배포 캐시의 소유자 수를 설정합니다. 다음 명령은
5
개의 소유자를 설정합니다. 기본값은2
입니다./subsystem=infinispan/cache-container=web/distributed-cache=dist:write-attribute(name=owners,value=5)
서버를 다시 로드합니다.
reload
분산된 캐시 모드로 변경
웹 세션 캐시에 대한 기본 JBoss EAP 구성에는 scattered-cache
가 포함되지 않습니다. 아래 예제에서는 분산된 캐시를 추가하고 기본 캐시로 설정하는 관리 CLI 명령을 보여줍니다.
아래 관리 CLI 명령은 HA 프로필을 사용하는 독립 실행형 서버용입니다. 관리형 도메인에서 실행하는 경우 / profile=PROFILE_NAME
을 사용하여 /subsystem=infinispan
명령 앞에 업데이트할 프로필을 지정해야 합니다.
기본 웹 세션 시간 제한 값인 30분과 동일한 읽기 바이어스 수명이 있는 분산된 캐시를 만듭니다.
/subsystem=infinispan/cache-container=web/scattered-cache=scattered:add(bias-lifespan=1800000)
기본
캐시로
분산을 설정합니다./subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=scattered)
이렇게 하면 다음과 같은 서버 구성이 생성됩니다.
<cache-container name="web" default-cache="scattered" module="org.wildfly.clustering.web.infinispan"> ... <scattered-cache name="scattered" bias-lifespan="1800000"/> ... </cache-container>
24.3.3.2. 캐시 전략 성능
SYNC
캐싱 전략을 사용하면 복제가 완료될 때까지 요청이 완료되지 않으므로 복제 비용을 쉽게 측정하고 응답 시간에 직접 확인할 수 있습니다.
ASYNC
캐싱 전략으로 인해 SYNC
캐싱 전략보다 응답 시간이 짧아야 하지만 이는 올바른 조건에서만 적용됩니다. ASYNC
캐싱 전략은 측정하기가 더 어렵습니다. 그러나 요청 간 기간이 캐시 작업을 완료할 수 있을 만큼 충분한 경우 SYNC
전략보다 더 나은 성능을 제공할 수 있습니다. 이는 복제 비용이 응답 시간에 즉시 표시되지 않기 때문입니다.
동일한 세션에 대한 요청이 너무 빨리 생성되면 이전 요청의 복제 비용이 이전 요청의 복제가 완료될 때까지 기다려야 하므로 후속 요청의 앞부분으로 전환됩니다. 응답이 수신된 직후 후속 요청이 전송되는 빠른 실행 요청의 경우 ASYNC
캐싱 전략이 SYNC
캐싱 전략보다 성능이 저하됩니다. 결과적으로 SYNC
캐싱 전략이 ASYNC
캐싱 전략보다 실제로 더 나은 성능을 수행하는 동일한 세션의 요청 간 기간 동안 임계값이 있습니다. 실제 사용 환경에서는 동일한 세션에 대한 요청이 일반적으로 빠른 연속으로 수신되지 않습니다. 대신 일반적으로 요청 사이에는 몇 초 이상의 순서로 기간이 있습니다. 이 경우 ASYNC
캐싱 전략은 적절한 기본값이며 가장 빠른 응답 시간을 제공합니다.
24.3.4. 시/도 (State Transfer)
상태 전송은 기본 데이터 그리드와 클러스터형 캐시 기능입니다. 상태 전송이 없으면 노드가 클러스터에 추가되거나 제거되므로 데이터가 손실됩니다.
상태 전송은 캐시 멤버십 변경에 대한 응답으로 캐시의 내부 상태를 조정합니다. 이 변경은 노드가 클러스터에 참여하거나 나가는 경우 두 개 이상의 클러스터 파티션이 병합되거나 이러한 이벤트를 조합한 후에 자동으로 발생합니다. 아래에 설명된 대로 새 캐시에서 최대 상태의 상태를 수신해야 하므로 새로 시작한 캐시의 초기 상태 전송이 가장 비용이 높습니다.
timeout
속성을 사용하여 새로 시작된 캐시가 상태를 수신 대기하는 기간을 제어할 수 있습니다. 시간 초과
특성이 양수인 경우 캐시는 서비스 요청에 사용할 수 있도록 모든 초기 상태를 수신하도록 기다립니다. 지정된 시간 내에 상태 전송이 완료되지 않으면 기본값은 240000
밀리초이며 캐시에서 오류가 발생하고 시작을 취소합니다. 시간 초과
가 0
으로 설정되면 캐시를 즉시 사용할 수 있으며 백그라운드 작업 중에 초기 상태가 수신됩니다. 초기 상태 전송이 완료될 때까지 캐시가 아직 수신되지 않은 캐시 항목에 대한 모든 요청을 원격 노드에서 가져와야 합니다.
다음 명령을 사용하여 timeout
특성을 0
으로 설정할 수 있습니다.
/subsystem=infinispan/cache-container=server/CACHE_TYPE=CACHE/component=state-transfer:write-attribute(name=timeout,value=0)
상태 전송 동작은 캐시 모드에 따라 결정됩니다.
- 복제 모드에서는 캐시에 가입하는 새 노드가 기존 노드에서 전체 캐시 상태를 수신합니다. 노드가 클러스터를 벗어나면 상태 전송이 없습니다.
-
배포 모드에서 새 노드는 기존 노드에서 상태의 일부만 수신하고, 일관된 해시를 통해 확인된 대로 기존 노드는 일부 해당 상태를 캐시에 저장하여 캐시에 각 키의
복사본
을 유지합니다. 노드가 클러스터를 벗어나면 배포 캐시에서 각 키의 소유자가 계속 존재하도록 해당 노드에 저장된 키의 추가 복사본을 만들어야 합니다. - 무효화 모드에서 초기 상태 전송은 복제 모드와 유사하며, 유일한 차이점은 노드의 상태가 동일한 것으로 보장되지 않는다는 점입니다. 노드가 클러스터를 벗어나면 상태 전송이 없습니다.
상태 전송은 기본적으로 메모리 내 및 영구 상태를 모두 전송하지만 구성에서 둘 다 비활성화할 수 있습니다. 상태 전송이 비활성화되면 ClusterLoader
를 구성해야 합니다. 그렇지 않으면 데이터가 캐시에 로드되지 않고 노드가 키의 소유자 또는 백업 소유자가 됩니다. 또한 배포 모드에서 상태 전송이 비활성화된 경우 키에 캐시에 소유자
사본보다 적은 경우가 있습니다.
24.3.5. Infinispan 스레드 풀 구성
infinispan
하위 시스템에는 async-operations
,expiration
,listener
,persistence
,remote-command
,state-transfer
및 transport
스레드 풀이 포함되어 있습니다. 이러한 풀은 Infinispan 캐시 컨테이너에 대해 구성할 수 있습니다.
다음 표에는 infinispan
하위 시스템의 각 스레드 풀에 대해 구성할 수 있는 속성과 각각의 기본값이 나열되어 있습니다.
스레드 풀 이름 | keepalive-time | max-threads | min-threads | queue-length |
---|---|---|---|---|
async-operations | 60000L | 25 | 25 | 1000 |
만료 | 60000L | 1 | 해당 없음 | 해당 없음 |
리스너 | 60000L | 1 | 1 | 100000 |
지속성 | 60000L | 4 | 1 | 0 |
remote-command | 60000L | 200 | 1 | 0 |
state-transfer | 60000L | 60 | 1 | 0 |
전송 | 60000L | 25 | 25 | 100000 |
다음 구문을 사용하여 관리 CLI를 사용하여 Infinispan 스레드 풀을 구성합니다.
/subsystem=infinispan/cache-container=CACHE_CONTAINER_NAME/thread-pool=THREAD_POOL_NAME:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)
다음은 서버
캐시 컨테이너의 지속성
스레드 풀에서 max-threads
값을 10
으로 설정하는 관리 CLI 명령의 예입니다.
/subsystem=infinispan/cache-container=server/thread-pool=persistence:write-attribute(name="max-threads", value="10")
24.3.6. Infinispan 통계
Infinispan 캐시 및 캐시 컨테이너에 대한 런타임 통계는 모니터링 목적으로 활성화할 수 있습니다. 통계 수집은 성능상의 이유로 기본적으로 활성화되어 있지 않습니다.
통계 수집은 각 캐시 컨테이너, 캐시 또는 둘 다에 대해 활성화할 수 있습니다. 각 캐시의 statistics 옵션은 캐시 컨테이너의 옵션을 덮어씁니다. 캐시 컨테이너에 대한 통계 컬렉션을 활성화하거나 비활성화하면 자체를 명시적으로 지정하지 않는 한 해당 컨테이너의 모든 캐시가 설정을 상속합니다.
24.3.6.1. Infinispan 통계 활성화
Infinispan 통계를 활성화하면 infinispan
하위 시스템의 성능에 부정적인 영향을 줄 수 있습니다. 통계는 필요한 경우에만 활성화해야 합니다.
관리 콘솔 또는 관리 CLI를 사용하여 Infinispan 통계 컬렉션을 활성화하거나 비활성화할 수 있습니다. 관리 콘솔의 Configuration (구성) 탭에서 Infinispan 하위 시스템으로 이동하고 적절한 캐시 또는 캐시 컨테이너를 선택하고 Statistics Enabled 특성을 편집합니다. 관리 CLI를 사용하여 통계를 활성화하려면 아래 명령을 사용합니다.
캐시 컨테이너에 대한 통계 컬렉션을 활성화합니다. 서버를 다시 로드해야 합니다.
/subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=statistics-enabled,value=true)
캐시에 대한 통계 컬렉션을 활성화합니다. 서버를 다시 로드해야 합니다.
/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:write-attribute(name=statistics-enabled,value=true)
다음 명령을 사용하여 캐시 컨테이너의 statistics-enabled
속성 설정을 상속받도록 캐시의 statistics-enabled
특성을 정의할 수 있습니다.
/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:undefine-attribute(name=statistics-enabled)
24.3.7. Infinispan 파티션 처리
Infinispan 클러스터는 데이터가 저장된 여러 노드에서 빌드됩니다. 여러 노드가 실패하는 경우 데이터 손실을 방지하기 위해 Infinispan은 여러 노드에 동일한 데이터를 복사합니다. 이 수준의 데이터 중복은 owner 특성을 사용하여
구성됩니다. 구성된 노드 수만큼 동시에 충돌하는 경우 Infinispan에 사용 가능한 데이터의 복사본이 있습니다.
그러나 클러스터에서 너무 많은 노드가 사라질 때 발생할 수 있는 치명적인 상황이 있습니다.
- 줄 바꿈
이렇게 하면 클러스터를 개별적으로 작동하는 두 개 이상의 파티션 또는 하위 클러스터로 나뉩니다. 이러한 상황에서 다양한 파티션에서 읽고 쓰는 여러 클라이언트는 동일한 캐시 항목의 다른 버전을 확인할 수 있습니다. 이 버전의 경우 여러 애플리케이션에 문제가 있습니다.
참고중복 네트워크 또는 IP 본딩 과 같이 분할 브레이가 발생할 가능성을 완화할 수 있는 방법은 있지만, 이러한 경우 문제가 발생하는 시간만 줄일 수 있습니다.
- 여러 노드가 순서대로 충돌
- 여러 노드, 특히 소유자 수와 Infinispan의 충돌이 충돌 간에 해당 상태를 적절하게 재조정할 수 없는 경우 결과적으로 부분적인 데이터 손실이 발생합니다.
목표는 스플릿 블록 또는 여러 노드가 빠르게 충돌하여 잘못된 데이터가 사용자에게 반환되는 상황을 방지하는 것입니다.
24.3.7.1. 브라질 분할
분할 된 경우 각 네트워크 파티션은 고유한 JGroups 보기를 설치하여 다른 파티션에서 노드를 제거합니다. 파티션이 서로 인식하지 못하므로 클러스터가 두 개 이상의 파티션으로 분할되었는지를 직접 확인할 수 없습니다. 대신 명시적인 종료 메시지를 보내지 않고 하나 이상의 노드가 JGroups 클러스터에서 사라질 때 클러스터가 분산되었다고 가정합니다.
파티션 처리가 비활성화되면 이러한 각 파티션이 독립 클러스터로 계속 작동합니다. 각 파티션은 데이터의 일부만 볼 수 있으며 각 파티션은 캐시에 충돌하는 업데이트를 쓸 수 있습니다.
파티션 처리가 활성화되면 분할을 감지하면 각 파티션이 즉시 리밸런싱을 시작하지 않고 먼저 성능이 저하된 모드로 전환해야 하는지 여부를 확인합니다.
- 하나 이상의 세그먼트가 모든 소유자를 손실한 경우 마지막 리밸런스 이후 지정된 소유자 수가 남아 있으면 파티션이 성능이 저하된 모드로 전환됩니다.
- 파티션에 안정적인 최신 토폴로지 에 대다수의 노드(floor(numNodes/2) + 1)가 포함되어 있지 않은 경우 파티션은 성능이 저하된 모드로 전환됩니다.
- 그렇지 않으면 파티션이 정상적으로 작동하고 리밸런싱을 시작합니다.
리밸런스 작업이 종료될 때마다 안정적인 토폴로지 가 업데이트되고 코디네이터는 다른 리밸런스가 필요하지 않음을 결정합니다. 이러한 규칙은 최대 한 개의 파티션이 사용 가능한 모드로 유지되고 다른 파티션이 성능이 저하된 모드로 전환되도록 합니다.
파티션이 성능 저하 모드인 경우 완전히 소유한 키에만 액세스할 수 있습니다.
- 이 파티션 내의 노드에서 모든 복사본이 있는 항목에 대한 요청(읽기 및 쓰기)이 적용됩니다.
-
사라진 노드에서 일부 또는 완전히 소유한 항목 요청은
AvailabilityException
과 함께 거부됩니다.
이렇게 하면 파티션이 동일한 키(캐시가 일관됨)에 대해 다른 값을 쓸 수 없으며 한 개의 파티션은 다른 파티션에서 업데이트된 키를 읽을 수 없습니다(고급 데이터 없음).
두 개의 파티션이 격리될 수 있으며 병합되지 않는 한 일관되지 않은 데이터를 읽고 쓸 수 있습니다. 나중에 사용자 정의 가용성 전략(예: 특정 노드가 클러스터의 일부인지 확인) 해당 상황을 처리할 수 있는 외부 시스템에 액세스할 수 있는지 확인할 수 있습니다.
24.3.7.2. 파티션 처리 구성
현재 파티션 처리는 기본적으로 비활성화되어 있습니다. 다음 관리 CLI 명령을 사용하여 파티션 처리를 활성화합니다.
/subsystem=infinispan/cache-container=web/distributed-cache=dist/component=partition-handling:write-attribute(name=enabled, value=true)
24.3.8. 원격 캐시 컨테이너 구성
관리형 도메인의 모든 서버 그룹에 대해 원격 캐시를 구성해야 합니다. 지정된 remote-cache-container에 대한 지표 컬렉션을 활성화하고
특성과 연결된 런타임 캐시를 활성화할 수 있습니다.
statistics-
enabled
24.3.8.1. 원격 캐시 컨테이너 생성
관리형 도메인의 각 서버 그룹에는 고유한 원격 캐시가 필요합니다. 캐시는 동일한 데이터 그리드에 속할 수 있습니다. 따라서 사용자는 서버 그룹에 대한 소켓 바인딩을 정의하고 소켓 바인딩을 원격 캐시 컨테이너와 연결하여 모든 서버 그룹에 대해 원격 캐시를 구성해야 합니다.
절차
socket-binding
을 정의하여 클러스터에서 각 원격 Red Hat Data Grid 인스턴스에 필요에 따라 명령을 반복합니다./socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=SOCKET_BINDING:add(host=HOSTNAME,port=PORT)
새로 생성된 소켓 바인딩을 참조하는
remote-cache-container
를 정의합니다.batch /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER:add(default-remote-cluster=data-grid-cluster) /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/remote-cluster=data-grid-cluster:add(socket-bindings=[SOCKET_BINDING,SOCKET_BINDING_2,...]) run-batch
24.3.8.2. 원격 캐시 컨테이너의 통계 활성화
statistics-enabled
특성은 지정된 remote-cache-container
및 관련 런타임 캐시에 대한 메트릭 컬렉션을 활성화합니다.
-
"foo"라는
remote-cache-container
의 경우 다음 작업을 사용하여 통계를 활성화합니다.
/subsystem=infinispan/remote-cache-container=foo:write-attribute(name=statistics-enabled, value=true)
-
remote-cache-container
"foo"의 경우 다음 메트릭이 런타임에 표시됩니다.
/subsystem=infinispan/remote-cache-container=foo:read-attribute(name=connections) /subsystem=infinispan/remote-cache-container=foo:read-attribute(name=active-connections) /subsystem=infinispan/remote-cache-container=foo:read-attribute(name=idle-connections)
-
이러한 메트릭에 대한 설명은 remote-
cache-container에 대해 read-resource-
description 작업을 실행합니다.
/subsystem=infinispan/remote-cache-container=foo:read-resource-description
- 다음 메트릭은 선택한 배포에서 사용하는 원격 캐시에 고유합니다.
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource(include-runtime=true, recursive=true) { "average-read-time" : 1, "average-remove-time" : 0, "average-write-time" : 2, "hits" : 9, "misses" : 0, "near-cache-hits" : 7, "near-cache-invalidations" : 8, "near-cache-misses" : 9, "near-cache-size" : 1, "removes" : 0, "time-since-reset" : 82344, "writes" : 8 }
- 이러한 메트릭에 대한 설명은 원격 캐시에 대해 read-resource-description 작업을 실행합니다.
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource-description
- 이러한 지표 중 일부는 계산된 값(예: average-*)이며 다른 지표는 적중 및 누락과 같은 희미한 상태입니다. 강력한 메트릭은 다음 작업으로 재설정할 수 있습니다.
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:reset-statistics()
24.3.9. HTTP 세션을 Red Hat Data Grid로 외부화
이 기능을 사용하려면 Red Hat Data Grid 서브스크립션이 필요합니다.
Red Hat Data Grid는 HTTP 세션과 같이 JBoss EAP의 애플리케이션별 데이터를 위한 외부 캐시 컨테이너로 사용할 수 있습니다. 이를 통해 애플리케이션과는 별도로 데이터 계층을 확장할 수 있으며 다양한 도메인에 있을 수 있는 다양한 JBoss EAP 클러스터가 동일한 Red Hat Data Grid 클러스터에서 데이터에 액세스할 수 있습니다. 또한 다른 애플리케이션은 Red Hat Data Grid에서 제공하는 캐시와 상호 작용할 수 있습니다.
다음 예제에서는 HTTP 세션을 외부화하는 방법을 보여줍니다. JBoss EAP의 독립 실행형 인스턴스와 관리형 도메인 모두에 적용됩니다.
-
remote-cache-container
를 생성합니다. 자세한 내용은 원격 캐시 컨테이너 구성을 참조하십시오. HotRod 저장소 구성. HotRod 저장소는 JBoss EAP 서버에서 생성한 각 캐시에 대해 하나의 전용 원격 캐시를 사용합니다. 일반적으로 아래 CLI 스크립트에 표시된 대로 JBoss EAP 서버에서 한 개의 무효화 캐시가 사용됩니다.
참고원격 캐시는 Red Hat Data Grid 서버에서 수동으로 구성해야 합니다. 이러한 캐시에 권장되는 구성은 비관적 잠금을 사용하는 트랜잭션 배포 모드 캐시입니다. 캐시 이름은
test.war
와 같은 배포 파일 이름에 해당해야 합니다.원격 캐시 컨테이너를 구성하고 나면 기존 저장소를 교체하도록
핫로드
저장소를 구성할 수 있습니다. 다음 CLI 스크립트는 무효화 캐시와 함께 세션을 오프로딩하는 일반적인 사용 사례를 보여줍니다.batch /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME:add() /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/store=hotrod:add(remote-cache-container=CACHE_CONTAINER,fetch-state=false,purge=false,passivation=false,shared=true) /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=transaction:add(mode=BATCH) /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=locking:add(isolation=REPEATABLE_READ) /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=CACHE_NAME) run-batch
스크립트는 새로운 무효화 캐시를 구성합니다. 그런 다음 세션 데이터가 성능을 위해 캐시에서 유지 관리하고 복원력을 위해 저장소에 기록됩니다.
HotRod 클라이언트는
@Resource
주석을 사용하여 Jakarta EE 애플리케이션에 직접 주입할 수 있습니다. 아래 예제에서@Resource
주석은hotrod-client.properties
파일에서 클래스 경로에서 구성 속성을 조회합니다.@Resource(lookup = "java:jboss/infinispan/remote-container/web-sessions") private org.infinispan.client.hotrod.RemoteCacheContainer client;
예:
hotrod-client.properties
파일infinispan.client.hotrod.transport_factory = org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory infinispan.client.hotrod.server_list = 127.0.0.1:11222 infinispan.client.hotrod.marshaller = org.infinispan.commons.marshall.jboss.GenericJBossMarshaller infinispan.client.hotrod.async_executor_factory = org.infinispan.client.hotrod.impl.async.DefaultAsyncExecutorFactory infinispan.client.hotrod.default_executor_factory.pool_size = 1 infinispan.client.hotrod.default_executor_factory.queue_size = 10000 infinispan.client.hotrod.hash_function_impl.1 = org.infinispan.client.hotrod.impl.consistenthash.ConsistentHashV1 infinispan.client.hotrod.tcp_no_delay = true infinispan.client.hotrod.ping_on_startup = true infinispan.client.hotrod.request_balancing_strategy = org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy infinispan.client.hotrod.key_size_estimate = 64 infinispan.client.hotrod.value_size_estimate = 512 infinispan.client.hotrod.force_return_values = false ## below is connection pooling config maxActive=-1 maxTotal = -1 maxIdle = -1 whenExhaustedAction = 1 timeBetweenEvictionRunsMillis=120000 minEvictableIdleTimeMillis=300000 testWhileIdle = true minIdle = 1
원격 캐시 컨테이너 보안
SSL을 사용하여 원격 Red Hat Data Grid 인스턴스와의 통신을 보호할 수 있습니다. 이 작업은 JBoss EAP 인스턴스에서 remote-cache-container
를 구성하고 활성 보안 영역을 사용하도록 Red Hat Data Grid 인스턴스의 hotrod 커넥터를 조정하여 수행됩니다.
JBoss EAP에서
클라이언트-ssl-context
를 만듭니다. 다른 elytron 구성 요소 생성을 포함한클라이언트-ssl-context
생성에 대한 자세한 내용은 How to Configure Server Security for JBoss EAP에서 client-ssl-context 사용을 참조하십시오./subsystem=elytron/client-ssl-context=CLIENT_SSL_CONTEXT:add(key-manager=KEY_MANAGER,trust-manager=TRUST_MANAGER)
클라이언트 SSL 컨텍스트를 사용하도록 원격 캐시 컨테이너를 구성합니다.
/subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/component=security:write-attribute(name=ssl-context,value=CLIENT_SSL_CONTEXT)
각 인스턴스에 대해 필요에 따라 반복하여 원격 Red Hat Data Grid 인스턴스를 보호합니다.
-
client-ssl-context
에 사용된 키 저장소를 원격 Red Hat Data Grid 인스턴스에 복사합니다. 이 키 저장소를 사용하도록
ApplicationRealm
을 구성합니다./core-service=management/security-realm=ApplicationRealm/server-identity=ssl:add(keystore-path="KEYSTORE_NAME",keystore-relative-to="jboss.server.config.dir",keystore-password="KEYSTORE_PASSWORD")
이 보안 영역을 가리키도록 hotrod 커넥터를 조정합니다.
/subsystem=datagrid-infinispan-endpoint/hotrod-connector=hotrod-connector/encryption=ENCRYPTION:add(require-ssl-client-auth=false,security-realm="ApplicationRealm")
원격 Red Hat Data Grid 인스턴스를 다시 로드합니다.
reload
-
24.3.10. 원격 저장소를 사용하여 HTTP 세션을 Red Hat Data Grid로 외부화
이 기능을 사용하려면 Red Hat Data Grid 서브스크립션이 필요합니다.
이 지침은 이전의 세션을 외부화하는 방법을 나타냅니다. JBoss EAP 7.2는 elytron
하위 시스템과 통합된 HotRod 프로토콜을 기반으로 사용자 지정 최적화된 캐시 저장소를 도입했습니다. HTTP 세션을 Red Hat Data Grid로 외부화하는 방법에 설명된 대로 새로운 핫로드
저장소를 사용하는 것이 좋습니다.
배포 가능한 각 애플리케이션에 대해 완전히 새 캐시를 생성해야 합니다. 기존 캐시 컨테이너(예: web
)에 생성할 수 있습니다.
HTTP 세션을 외부화하려면 다음을 수행합니다.
socket-binding-group
에 네트워킹 정보를 추가하여 원격 Red Hat Data Grid 서버의 위치를 정의합니다.예제: 원격 소켓 바인딩 추가
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server1:add(host=RHDGHostName1, port=11222) /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server2:add(host=RHDGHostName2, port=11222)
결과 XML
<socket-binding-group name="standard-sockets" ... > ... <outbound-socket-binding name="remote-rhdg-server1"> <remote-destination host="RHDGHostName1" port="11222"/> </outbound-socket-binding> <outbound-socket-binding name="remote-rhdg-server2"> <remote-destination host="RHDGHostName2" port="11222"/> </outbound-socket-binding> </socket-binding-group>
참고각 Red Hat Data Grid 서버에 대해 구성된 원격 소켓 바인딩이 필요합니다.
원격 캐시 컨테이너가 JBoss EAP의
infinispan
하위 시스템에 정의되어 있는지 확인합니다. 아래 예에서remote-store
요소의cache
속성은 원격 Red Hat Data Grid 서버에서 캐시 이름을 정의합니다.관리형 도메인에서 실행 중인 경우 해당 명령 앞에
/profile=PROFILE_NAME을 추가합니다
.예제: 원격 캐시 컨테이너 추가
/subsystem=infinispan/cache-container=web/invalidation-cache=rhdg:add(mode=SYNC) /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=locking:write-attribute(name=isolation,value=REPEATABLE_READ) /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=transaction:write-attribute(name=mode,value=BATCH) /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/store=remote:add(remote-servers=["remote-rhdg-server1","remote-rhdg-server2"], cache=default, socket-timeout=60000, passivation=false, purge=false, shared=true)
결과 XML
<subsystem xmlns="urn:jboss:domain:infinispan:7.0"> ... <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan" statistics-enabled="true"> <transport lock-timeout="60000"/> <invalidation-cache name="rhdg" mode="SYNC"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <remote-store cache="default" socket-timeout="60000" remote-servers="remote-rhdg-server1 remote-rhdg-server2" passivation="false" purge="false" shared="true"/> </invalidation-cache> ... </cache-container> </subsystem>
애플리케이션
jboss-web.xml
파일에 캐시 정보를 추가합니다. 다음 예제에서web
은 캐시 컨테이너의 이름이고rhdg
는 이 컨테이너에 있는 적절한 캐시의 이름입니다.예:
jboss-web.xml
파일<?xml version="1.0" encoding="UTF-8"?> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd" version="10.0"> <replication-config> <replication-granularity>SESSION</replication-granularity> <cache-name>web.rhdg</cache-name> </replication-config> </jboss-web>
24.4. JBoss EAP를 프런트 엔드 로드 밸런서 장치로 구성
백엔드 JBoss EAP 서버에 대한 요청을 프록시하는 프런트엔드 로드 밸런서 장치 역할을 하도록 JBoss EAP 및 undertow
하위 시스템을 구성할 수 있습니다. Undertow는 비동기 IO를 사용하므로 연결을 담당하는 IO 스레드는 요청에 관련된 유일한 스레드입니다. 이 스레드는 백엔드 서버에 대한 연결에도 사용됩니다.
다음 프로토콜을 사용할 수 있습니다.
-
HTTP/1 및 HTTP/2 (
h
2c
)를 지원하는 일반 텍스트(http)를 통한 HTTP -
HTTP/1 및 HTTP/2
(
h2)를 지원하는 보안 연결(http)
을 통한 HTTP -
AJP
(Ajp
)
정적 로드 밸런서 를 정의하고 구성에서 백엔드 호스트를 지정하거나 mod_cluster 프론트엔드 를 사용하여 호스트를 동적으로 업데이트할 수 있습니다.
HTTP/2를 사용하도록 Undertow를 구성하는 지침은 HTTP/2 구성을 참조하십시오.
24.4.1. mod_cluster를 사용하여 Undertow를 로드 밸런서로 구성
기본 제공 mod_cluster 프런트 엔드 로드 밸런서 장치를 사용하여 다른 JBoss EAP 인스턴스의 부하를 분산할 수 있습니다.
이 절차에서는 관리형 도메인에서 실행 중이며 다음이 이미 구성되어 있다고 가정합니다.
로드 밸런서 장치 역할을 할 JBoss EAP 서버입니다.
이 서버는
load-balancer-
sockets 소켓 바인딩 그룹에 바인딩된 load-balancer
프로필을 사용합니다.참고load-balancer
프로필은 소켓 바인딩, mod-cluster Undertow 필터를 사용하여 이미 사전 구성되어 있으며 이 서버를 프런트엔드 로드 밸런서로 사용하기 위해 기본 호스트에서 필터에 대한 참조를 사용합니다.
백엔드 서버 역할을 할 두 개의 JBoss EAP 서버.
-
이러한 서버는 클러스터에서 실행 중이며
ha
-sockets 소켓 바인딩 그룹에 바인딩된 ha
프로필을 사용합니다.
-
이러한 서버는 클러스터에서 실행 중이며
- 백엔드 서버에 부하 분산할 수 있는 배포 가능 애플리케이션.
mod_cluster 프런트 엔드 로드 밸런서 장치 구성
아래는 관리형 도메인의 서버의 부하 분산 단계를 수행하지만 독립 실행형 서버 집합에 적용하도록 조정할 수 있습니다. 사용자 환경에 맞게 관리 CLI 명령 값을 업데이트해야 합니다.
mod_cluster 광고 보안 키를 설정합니다.
광고 보안 키를 추가하면 검색 중에 로드 밸런서와 서버를 인증할 수 있습니다.
다음 관리 CLI 명령을 사용하여 mod_cluster 광고 보안 키를 설정합니다.
/profile=ha/subsystem=modcluster/proxy=default:write-attribute(name=advertise-security-key, value=mypassword)
mod_cluster 로드 밸런서의 보안 키를 업데이트합니다.
다음 관리 CLI 명령을 사용하여 mod_cluster 필터의 보안 키를 설정합니다.
/profile=load-balancer/subsystem=undertow/configuration=filter/mod-cluster=load-balancer:write-attribute(name=security-key,value=mypassword)
mod_cluster에서 사용하는 소켓 바인딩 관리 및 알림 소켓 바인딩은 공용 IP 주소가 아닌 내부 네트워크에만 노출되는 것이 좋습니다.
이제 로드 밸런서 장치 JBoss EAP 서버가 두 개의 백엔드 JBoss EAP 서버를 로드 밸런싱할 수 있습니다.
여러 mod_cluster 구성
mod_cluster
하위 시스템은 기본이 아닌 서버를
역방향 프록시로 등록할 수 있는 여러 명명된 프록시 구성을 지원합니다. 또한 단일 애플리케이션 서버 노드가 다양한 프록시 서버 그룹에 등록할 수 있습니다.
다음 예제에서는 ajp-listener
, server 및 host를 the undertow
서버에 추가합니다. 또한 광고 메커니즘을 사용하여 호스트를 등록하는 새로운 mod_cluster
구성을 추가합니다.
/socket-binding-group=standard-sockets/socket-binding=ajp-other:add(port=8010) /subsystem=undertow/server=other-server:add /subsystem=undertow/server=other-server/ajp-listener=ajp-other:add(socket-binding=ajp-other) /subsystem=undertow/server=other-server/host=other-host:add(default-web-module=root-other.war) /subsystem=undertow/server=other-server/host=other-host /location=other:add(handler=welcome-content) /subsystem=undertow/server=other-server/host=other-host:write-attribute(name=alias,value=[localhost])) /socket-binding-group=standard-sockets/socket-binding=modcluster-other:add(multicast-address=224.0.1.106,multicast-port=23364) /subsystem=modcluster/proxy=other:add(advertise-socket=modcluster-other,balancer=other-balancer,connector=ajp-other) reload
24.4.2. 로드 밸런서에서 등급이 지정된 세션 유사성 활성화
distributable-web
하위 시스템에서 여러 개의 순서로 지정된 경로와 세션 선호도를 갖도록 로드 밸런서에서 순위 세션 선호도를 활성화해야 합니다. distributable-web
하위 시스템 및 다양한 선호도 옵션에 대한 자세한 내용은 JBoss EAP 의 개발 가이드에 있는 배포 가능한 웹 세션 구성의 Distributable-web 하위 시스템을 참조하십시오.
노드 경로를 구분하는 기본 구분 기호는 입니다 .
. 다른 값을 원하는 경우 선호도
리소스의 구분 기호
특성을 구성할 수 있습니다.
절차
로드 밸런서에 대해 순위가 지정된 세션 선호도를 활성화합니다.
/subsystem=undertow/configuration=filter/mod-cluster=load-balancer/affinity=ranked:add
선택 사항:
유사성
리소스의구분 기호
특성을 구성합니다./subsystem=undertow/configuration=filter/mod-cluster=load-balancer/affinity=ranked:write-attribute(name=delimiter,value=':')
24.4.3. Undertow를 정적 로드 밸런서로 구성
Undertow를 사용하여 정적 로드 밸런서를 구성하려면 undertow 하위 시스템에서
프록시 핸들러를 구성해야 합니다. Undertow에서 프록시 핸들러를 구성하려면 정적 로드 밸런서 장치 역할을 할 JBoss EAP 인스턴스에서 다음을 수행해야 합니다.
- 역방향 프록시 처리기 추가
- 각 원격 호스트에 대한 아웃바운드 소켓 바인딩 정의
- 각 원격 호스트를 역방향 프록시 핸들러에 추가
- 역방향 프록시 위치 추가
다음 예제에서는 JBoss EAP 인스턴스를 정적 로드 밸런서 장치가 되도록 구성하는 방법을 보여줍니다. JBoss EAP 인스턴스는 lb.example.com에 있으며,
로드 밸런서 장치가 위치 server1.example.com
과 server 2.example.com
이라는 두 개의 추가 서버 간에 부하를 분산합니다./app
으로 역방향 프록시를 수행하며 AJP 프로토콜을 사용합니다.
역방향 프록시 핸들러를 추가하려면 다음을 수행합니다.
/subsystem=undertow/configuration=handler/reverse-proxy=my-handler:add
각 원격 호스트에 대한 아웃바운드 소켓 바인딩을 정의하려면 다음을 수행합니다.
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-host1/:add(host=server1.example.com, port=8009) /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-host2/:add(host=server2.example.com, port=8009)
각 원격 호스트를 역방향 프록시 핸들러에 추가하려면 다음을 수행합니다.
/subsystem=undertow/configuration=handler/reverse-proxy=my-handler/host=host1:add(outbound-socket-binding=remote-host1, scheme=ajp, instance-id=myroute1, path=/test) /subsystem=undertow/configuration=handler/reverse-proxy=my-handler/host=host2:add(outbound-socket-binding=remote-host2, scheme=ajp, instance-id=myroute2, path=/test)
역방향 프록시 위치를 추가하려면 다음을 수행합니다.
/subsystem=undertow/server=default-server/host=default-host/location=\/test:add(handler=my-handler)
lb.example.com:8080/app
에 액세스할 때 server1.example.com 및
server2.example.com
에서 프록시된 콘텐츠가 표시됩니다.
24.5. 외부 웹 서버를 프록시 서버로 사용
JBoss EAP는 외부 웹 서버 구성에 따라 지원되는 HTTP, HTTPS 또는 AJP 프로토콜을 사용하여 외부 웹 서버의 요청을 수락할 수 있습니다.
각 웹 서버에 대해 지원되는 HTTP 커넥터에 대한 자세한 내용은 HTTP 커넥터 개요 를 참조하십시오. 사용할 웹 서버 및 HTTP 커넥터를 결정한 후 커넥터 구성에 대한 자세한 내용은 해당 섹션을 참조하십시오.
- Apache HTTP Server 의 mod_cluster, mod_jk 또는 mod_proxy 섹션을 참조하십시오.
- Microsoft IIS의 ISAPI 커넥터 섹션을 참조하십시오.
- Oracle iPlanet Web Server의 NSAPI 커넥터 섹션을 참조하십시오.
HTTP 커넥터에서 지원되는 구성에 대한 최신 정보는 JBoss EAP에서 지원되는 구성을 참조하십시오.
또한 JBoss EAP가 외부 웹 서버의 요청을 수락 하도록 구성되어 있는지 확인해야 합니다.
24.5.1. HTTP 커넥터 개요
JBoss EAP에는 Undertow를 통해 Apache HTTP 서버, Microsoft IIS 및 Oracle iPlanet와 같은 외부 웹 서버에 기본 제공되는 부하 분산 및 클러스터링 메커니즘을 사용할 수 있습니다. JBoss EAP는 커넥터를 사용하여 웹 서버와 통신합니다. 이러한 커넥터는 JBoss EAP의 undertow
하위 시스템 내에 구성됩니다.
웹 서버에는 HTTP 요청이 JBoss EAP 노드로 라우팅되는 방법을 제어하는 소프트웨어 모듈이 포함되어 있습니다. 이러한 각 모듈은 작동 방식과 구성 방법에 따라 달라집니다. 모듈은 여러 JBoss EAP 노드에서 작업 부하를 분산하여 장애 발생 시 또는 둘 다 실행 중인 작업 부하를 대체 서버로 이동하도록 구성됩니다.
JBoss EAP는 여러 다른 커넥터를 지원합니다. 선택하는 것은 사용 중인 웹 서버와 필요한 기능에 따라 다릅니다. JBoss EAP와 호환되는 다양한 HTTP 커넥터의 지원 구성 및 기능을 비교한 내용은 아래 표를 참조하십시오.
JBoss EAP 7 을 다중 플랫폼 로드 밸런서 장치로 사용하기 위해 mod_cluster를 사용하여 Undertow 를 로드 밸런서로 구성에서 참조하십시오.
HTTP 커넥터에서 지원되는 구성에 대한 최신 정보는 JBoss EAP에서 지원되는 구성을 참조하십시오.
표 24.1. HTTP 커넥터 지원 구성
커넥터 | 웹 서버 | 지원되는 운영 체제 | 지원되는 프로토콜 |
---|---|---|---|
Red Hat JBoss Core Services Apache HTTP Server, Red Hat JBoss Web Server Apache HTTP Server, JBoss EAP(Undertow) | Red Hat Enterprise Linux, Microsoft Windows Server, Oracle Solaris | HTTP, HTTPS, AJP, WebSocket | |
Red Hat JBoss Core Services Apache HTTP Server, Red Hat JBoss Web Server Apache HTTP Server | Red Hat Enterprise Linux, Microsoft Windows Server, Oracle Solaris | AJP | |
Red Hat JBoss Core Services Apache HTTP Server, Red Hat JBoss Web Server Apache HTTP Server | Red Hat Enterprise Linux, Microsoft Windows Server, Oracle Solaris | HTTP, HTTPS, AJP | |
Microsoft IIS | Microsoft Windows Server | AJP | |
Oracle iPlanet 웹 서버 | Oracle Solaris | AJP |
표 24.2. HTTP 커넥터 기능
커넥터 | 고정 세션 지원 | 배포 상태에 맞게 조정 |
---|---|---|
있음 | 네, 필요합니다. 애플리케이션 배포 및 배포 취소를 감지하고 애플리케이션이 해당 서버에 배포되었는지 여부에 따라 서버에 클라이언트 요청을 지시할지 여부를 동적으로 결정합니다. | |
있음 | 아니요. 애플리케이션 상태에 관계없이 컨테이너를 사용할 수 있는 한 클라이언트 요청을 컨테이너로 보냅니다. | |
있음 | 아니요. 애플리케이션 상태에 관계없이 컨테이너를 사용할 수 있는 한 클라이언트 요청을 컨테이너로 보냅니다. | |
있음 | 아니요. 애플리케이션 상태에 관계없이 컨테이너를 사용할 수 있는 한 클라이언트 요청을 컨테이너로 보냅니다. | |
있음 | 아니요. 애플리케이션 상태에 관계없이 컨테이너를 사용할 수 있는 한 클라이언트 요청을 컨테이너로 보냅니다. |
24.5.2. Apache HTTP Server
독립 실행형 Apache HTTP Server 번들은 이제 Red Hat JBoss Core Services를 통해 별도의 다운로드로 사용할 수 있습니다. 이렇게 하면 설치 및 구성이 간소화되고 보다 일관된 업데이트 환경을 얻을 수 있습니다.
24.5.2.1. Apache HTTP 서버 설치
Apache HTTP Server 설치에 대한 자세한 내용은 JBoss Core Services Apache HTTP Server 설치 가이드를 참조하십시오.
24.5.3. 외부 웹 서버에서 요청 수락
JBoss EAP는 AJP, HTTP 또는 HTTPS와 같은 올바른 프로토콜 핸들러가 구성된 한 프록시 서버에서 요청 수락을 시작하는 데 특별한 구성이 필요하지 않습니다.
프록시 서버가 mod_jk, mod_proxy, ISAPI 또는 NSAPI를 사용하는 경우 JBoss EAP로 요청을 전송하고 JBoss EAP는 단순히 응답을 제공합니다. 또한 mod_cluster를 사용하면 JBoss EAP에서 요청을 라우팅할 위치를 결정하는 데 도움이 되도록 현재 부하, 애플리케이션 라이프사이클 이벤트 및 상태와 같은 정보를 프록시 서버에 보낼 수 있도록 네트워크를 구성해야 합니다. mod_cluster 프록시 서버 구성에 대한 자세한 내용은 The mod_cluster HTTP Connector 를 참조하십시오.
JBoss EAP 구성 업데이트
다음 절차에서는 예제의 프로토콜 및 포트를 구성해야 하는 프로토콜로 대체합니다.
Undertow의
instance-id
특성을 구성합니다.외부 웹 서버는 instance
-id를 사용하여 커넥터 구성에서 JBoss EAP 인스턴스를
식별합니다. 다음 관리 CLI 명령을 사용하여 Undertow에instance-id
특성을 설정합니다./subsystem=undertow:write-attribute(name=instance-id,value=node1)
위의 예에서 외부 웹 서버는 현재 JBoss EAP 인스턴스를
node1
로 식별합니다.Undertow에 필요한 리스너를 추가합니다.
외부 웹 서버가 JBoss EAP에 연결할 수 있으려면 Undertow에 리스너가 필요합니다. 각 프로토콜에는 소켓 바인딩에 연결된 고유한 리스너가 필요합니다.
참고원하는 프로토콜 및 포트 구성에 따라 이 단계가 필요하지 않을 수 있습니다. HTTP 리스너는 모든 기본 JBoss EAP 구성에서 구성되며 ha 또는 full-ha 프로필을 사용하는 경우 AJP 리스너가 구성됩니다.
기본 서버 구성을 읽어 필요한 리스너가 이미 구성되었는지 확인할 수 있습니다.
/subsystem=undertow/server=default-server:read-resource
Undertow에 리스너를 추가하려면 소켓 바인딩이 있어야 합니다. 소켓 바인딩은 서버 또는 서버 그룹에서 사용하는 소켓 바인딩 그룹에 추가됩니다. 다음 관리 CLI 명령은 포트
8009
에 바인딩된ajp
소켓 바인딩을standard-sockets
소켓 바인딩 그룹에 추가합니다./socket-binding-group=standard-sockets/socket-binding=ajp:add(port=8009)
다음 관리 CLI 명령은
ajp
소켓 바인딩을 사용하여 Undertow에ajp
리스너를 추가합니다./subsystem=undertow/server=default-server/ajp-listener=ajp:add(socket-binding=ajp)
24.6. mod_cluster HTTP 커넥터
mod_cluster 커넥터는 Apache HTTP 서버 기반 로드 밸런서입니다. 통신 채널을 사용하여 Apache HTTP Server의 요청을 애플리케이션 서버 노드 세트 중 하나로 전달합니다.
mod_cluster 커넥터는 다른 커넥터보다 몇 가지 장점이 있습니다.
- mod_cluster 관리 프로토콜(MCMP)은 mod_cluster 모듈이 활성화된 JBoss EAP 서버와 Apache HTTP 서버 간의 추가 연결입니다. JBoss EAP 서버에서는 사용자 지정 HTTP 메서드 세트를 통해 서버 측 부하 분산 요소 및 라이프사이클 이벤트를 Apache HTTP 서버로 전송하는 데 사용됩니다.
- mod_cluster를 사용하여 Apache HTTP Server의 동적 구성을 사용하면 JBoss EAP 서버가 수동 구성 없이 부하 분산 배열에 참여할 수 있습니다.
- JBoss EAP는 mod_cluster와 함께 Apache HTTP Server를 사용하는 대신 로드 밸런싱 인수 계산을 수행합니다. 따라서 부하 분산 메트릭이 다른 커넥터보다 더 정확합니다.
- mod_cluster 커넥터는 세부적인 애플리케이션 라이프사이클 제어를 제공합니다. 각 JBoss EAP 서버는 웹 애플리케이션 컨텍스트 라이프사이클 이벤트를 Apache HTTP Server에 전달하여 지정된 컨텍스트에 대한 요청을 시작하거나 중지하도록 알립니다. 이렇게 하면 최종 사용자가 사용할 수 없는 리소스로 인해 HTTP 오류가 표시되지 않습니다.
- AJP, HTTP 또는 HTTPS 전송을 사용할 수 있습니다.
modcluster
하위 시스템의 특정 구성 옵션에 대한 자세한 내용은 ModCluster 하위 시스템 속성을 참조하십시오.
24.6.1. Apache HTTP 서버에서 mod_cluster 구성
JBoss Core Services Apache HTTP Server를 설치하거나 JBoss Web Server를 사용할 때 mod_cluster 모듈은 이미 포함되어 있으며 기본적으로 로드됩니다.
Apache HTTP 서버는 더 이상 3.1.0 버전으로 JBoss Web Server와 함께 배포되지 않습니다.
환경에 맞게 mod_cluster 모듈을 구성하려면 아래 단계를 참조하십시오.
또한 Red Hat 고객은 Red Hat 고객 포털에서 부하 분산 구성 도구를 사용하여 mod_cluster 및 기타 커넥터를 위한 최적의 구성 템플릿을 신속하게 생성할 수 있습니다. 이 도구에 액세스하려면 로그인해야 합니다.
mod_cluster 설정
Apache HTTP 서버에는 이미 mod_cluster 모듈을 로드하고 기본 구성을 제공하는 mod_cluster 구성 파일인 mod_cluster.conf
가 포함되어 있습니다. 아래에 표시된 이 파일의 IP 주소, 포트 및 기타 설정은 요구 사항에 맞게 구성할 수 있습니다.
# mod_proxy_balancer should be disabled when mod_cluster is used LoadModule proxy_cluster_module modules/mod_proxy_cluster.so LoadModule cluster_slotmem_module modules/mod_cluster_slotmem.so LoadModule manager_module modules/mod_manager.so LoadModule advertise_module modules/mod_advertise.so MemManagerFile cache/mod_cluster <IfModule manager_module> Listen 6666 <VirtualHost *:6666> <Directory /> Require ip 127.0.0.1 </Directory> ServerAdvertise on EnableMCPMReceive <Location /mod_cluster_manager> SetHandler mod_cluster-manager Require ip 127.0.0.1 </Location> </VirtualHost> </IfModule>
Apache HTTP Server 서버는 로드 밸런서 장치로 구성되며 JBoss EAP에서 실행되는 modcluster
하위 시스템에서 작동할 수 있습니다. JBoss EAP 가 mod_cluster를 인식하도록 mod_cluster 작업자 노드를 구성해야 합니다.
mod_cluster에 대한 알림을 비활성화하고 대신 정적 프록시 목록을 구성하려면 mod_cluster에 대한 알림 비활성화 를 참조하십시오. Apache HTTP Server에서 사용 가능한 mod_cluster 구성 옵션에 대한 자세한 내용은 Apache HTTP Server mod_cluster 지시문을 참조하십시오.
mod_cluster 구성에 대한 자세한 내용은 JBoss Web Server HTTP 커넥터 및 로드 밸런싱 가이드의 Apache HTTP 서버를 사용하여 부하 분산 구성 섹션을 참조하십시오.
24.6.2. mod_cluster의 구성요소 비활성화
기본적으로 modcluster
하위 시스템의 밸런서는 멀티캐스트 UDP를 사용하여 백그라운드 작업자에게 가용성을 알립니다. 광고 비활성화 및 프록시 목록을 대신 다음 절차를 사용할 수 있습니다.
다음 절차의 관리 CLI 명령은 관리형 도메인에서 full-ha
프로필을 사용하고 있다고 가정합니다. full-ha
이외의 프로필을 사용하는 경우 명령에서 적절한 프로필 이름을 사용합니다. 독립 실행형 서버를 실행하는 경우 /profile=full-ha
를 완전히 제거합니다.
Apache HTTP 서버 구성을 수정합니다.
httpd.conf
Apache HTTP 서버 구성 파일을 편집합니다.EnableMCPMReceive
지시문을 사용하여 MCPM 요청을 수신 대기하는 가상 호스트를 다음과 같이 업데이트합니다.지시문을 추가하여 서버 알림을 비활성화합니다.
ServerAdvertise 지시문을
Off
로 설정하여 서버 알림을 비활성화합니다.ServerAdvertise Off
광고 빈도를 비활성화합니다.
구성에서
AdvertiseFrequency
매개변수를 지정하는 경우#
문자를 사용하여 주석 처리합니다.# AdvertiseFrequency 5
MCPM 메시지를 수신하는 기능을 활성화합니다.
웹 서버가 작업자 노드에서
MCPM 메시지를 받을 수 있도록 EnableMCPMReceive
지시문이 있는지 확인합니다.EnableMCPMReceive
JBoss EAP
modcluster 하위 시스템에서 알림을
비활성화합니다.다음 관리 CLI 명령을 사용하여 알림을 비활성화합니다.
/profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=advertise,value=false)
중요다음 단계로 계속 이동하여 프록시 목록을 제공해야 합니다. 프록시 목록이 비어 있으면 광고가 비활성화되지 않습니다.
JBoss EAP
modcluster
하위 시스템에서 프록시 목록을 제공합니다.광고가 비활성화된 경우
modcluster
하위 시스템에서 프록시를 자동으로 검색할 수 없으므로 프록시 목록을 제공해야 합니다.먼저 적절한 소켓 바인딩 그룹에 아웃바운드 소켓 바인딩을 정의합니다.
/socket-binding-group=full-ha-sockets/remote-destination-outbound-socket-binding=proxy1:add(host=10.33.144.3,port=6666) /socket-binding-group=full-ha-sockets/remote-destination-outbound-socket-binding=proxy2:add(host=10.33.144.1,port=6666)
그런 다음 프록시를 mod_cluster 구성에 추가합니다.
/profile=full-ha/subsystem=modcluster/proxy=default:list-add(name=proxies,value=proxy1) /profile=full-ha/subsystem=modcluster/proxy=default:list-add(name=proxies,value=proxy2)
Apache HTTP 서버 밸런서에서 더 이상 작업자 노드에 해당 존재를 알리지 않으며 UDP 멀티캐스트는 더 이상 사용되지 않습니다.
24.6.3. mod_cluster 작업자 노드 설정
mod_cluster 작업자 노드는 JBoss EAP 서버로 구성됩니다. 이 서버는 독립 실행형 서버 또는 관리형 도메인에서 서버 그룹의 일부일 수 있습니다. 별도의 프로세스는 클러스터의 모든 작업자 노드를 관리하는 JBoss EAP 내에서 실행됩니다. 이것을 마스터라고 합니다.
관리형 도메인의 작업자 노드는 서버 그룹 전체에서 동일한 구성을 공유합니다. 독립 실행형 서버로 실행되는 작업자 노드는 개별적으로 구성됩니다. 구성 단계는 그렇지 않으면 동일합니다.
- 독립 실행형 서버는 standalone -ha 또는 standalone-full-ha 프로필을 사용하여 시작해야 합니다.
- 관리형 도메인의 서버 그룹은 ha 또는 full-ha 프로필과 ha- sockets 또는 full-ha-sockets 소켓 바인딩 그룹을 사용해야 합니다. JBoss EAP에는 이러한 요구 사항을 충족하는 other-server-group이라는 클러스터 지원 서버 그룹이 포함되어 있습니다.
작업자 노드 설정
이 절차의 관리 CLI 명령은 full-ha
프로필이 있는 관리형 도메인을 사용하고 있다고 가정합니다. 독립 실행형 서버를 실행하는 경우 명령의 /profile=full-ha
부분을 제거합니다.
네트워크 인터페이스를 구성합니다.
기본적으로 네트워크 인터페이스는 모두 기본적으로
127.0.0.1
로 설정됩니다. 독립 실행형 서버 또는 서버 그룹에서 하나 이상의 서버를 호스팅하는 모든 물리적 호스트는 다른 서버가 볼 수 있는 공용 IP 주소를 사용하도록 인터페이스를 구성해야 합니다.다음 관리 CLI 명령을 사용하여 환경에 맞게
관리
,공용
및 비보안 인터페이스의
외부 IP 주소를 수정합니다. 명령에서EXTERNAL_IP_ADDRESS
를 호스트의 실제 외부 IP 주소로 바꿉니다./interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:EXTERNAL_IP_ADDRESS}") /interface=public:write-attribute(name=inet-address,value="${jboss.bind.address.public:EXTERNAL_IP_ADDRESS}") /interface=unsecure:write-attribute(name=inet-address,value="${jboss.bind.address.unsecure:EXTERNAL_IP_ADDRESS}")
서버를 다시 로드합니다.
reload
호스트 이름 구성.
관리형 도메인에 참여하는 각 호스트의 고유한 호스트 이름을 설정합니다. 이 이름은 슬레이브마다 고유해야 하며 클러스터 식별에 슬레이브에 사용되므로 사용하는 이름을 기록합니다.
적절한 host
.xml 구성 파일을 사용하여 JBoss EAP 슬레이브 호스트
를 시작합니다.$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
다음 관리 CLI 명령을 사용하여 고유한 호스트 이름을 설정합니다. 이 예에서는
slave1
을 새 호스트 이름으로 사용합니다./host=EXISTING_HOST_NAME:write-attribute(name=name,value=slave1)
호스트 이름 구성에 대한 자세한 내용은 호스트 이름 구성을 참조하십시오.
도메인 컨트롤러에 연결하도록 각 호스트를 구성합니다.
참고이 단계는 독립 실행형 서버에는 적용되지 않습니다.
관리형 도메인에 가입해야 하는 새로 구성된 호스트의 경우 로컬 요소를 제거하고 도메인 컨트롤러를 가리키는 remote 요소 호스트 특성을 추가해야 합니다.
적절한 host
.xml 구성 파일을 사용하여 JBoss EAP 슬레이브 호스트
를 시작합니다.$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
다음 관리 CLI 명령을 사용하여 도메인 컨트롤러 설정을 구성합니다.
/host=SLAVE_HOST_NAME:write-remote-domain-controller(host=DOMAIN_CONTROLLER_IP_ADDRESS,port=${jboss.domain.master.port:9990},security-realm="ManagementRealm")
이를 통해 host-slave.xml 파일의 XML을 다음과 같이 수정합니다.
<domain-controller> <remote host="DOMAIN_CONTROLLER_IP_ADDRESS" port="${jboss.domain.master.port:9990}" security-realm="ManagementRealm"/> </domain-controller>
자세한 내용은 호스트 컨트롤러 구성을 참조하십시오.
각 슬레이브 호스트에 대한 인증을 구성합니다.
각 슬레이브 서버에는 도메인 컨트롤러 또는 독립 실행형 마스터의 ManagementRealm에서 생성된 사용자 이름과 암호가 필요합니다. 도메인 컨트롤러 또는 독립 실행형 마스터에서 각 호스트에 대해
EAP_HOME/bin/add-user.sh
명령을 실행합니다. 슬레이브의 호스트 이름과 일치하는 사용자 이름을 사용하여 각 호스트에 대한 관리 사용자를 추가합니다.마지막 질문에
"
이 새 사용자가 하나의 AS 프로세스에서 다른 AS 프로세스에 연결하는 데 사용됩니까?"라는 질문으로 답해야 합니다. 그러면 시크릿 값이 제공됩니다.예:
add-user.sh
스크립트 출력 (trimmed)$ EAP_HOME/bin/add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a): a Username : slave1 Password : changeme Re-enter Password : changeme What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]: About to add user 'slave1' for realm 'ManagementRealm' Is this correct yes/no? yes Is this new user going to be used for one AS process to connect to another AS process? e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server {JEB} calls. yes/no? yes To represent the user add the following to the server-identities definition <secret value="SECRET_VALUE" />
이 출력에서 제공된 Base64로 인코딩된 시크릿 값
SECRET_VALUE
를 복사합니다. 이 값은 다음 단계에서 사용할 수 있습니다.자세한 내용은 JBoss EAP의 마스터 도메인 컨트롤러에 사용자 추가 섹션을 참조하십시오. 서버 보안 구성 방법.
새 인증을 사용하도록 슬레이브 호스트의 보안 영역을 수정합니다.
서버 구성에서 secret 값을 설정하고, 자격 증명 저장소 또는 자격 증명 모음에서 암호를 가져오거나, 암호를 시스템 속성으로 전달하여 암호를 지정할 수 있습니다.
관리 CLI를 사용하여 서버 구성 파일에 Base64로 인코딩된 암호 값을 지정합니다.
다음 관리 CLI 명령을 사용하여 보안 값을 지정합니다.
SECRET_VALUE
를 이전 단계의 add-user 출력에서 반환된 secret 값으로 바꿉니다./host=SLAVE_HOST_NAME/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="SECRET_VALUE")
서버를 다시 로드해야 합니다. host
인수는
독립 실행형 서버에 적용되지 않습니다.reload --host=HOST_NAME
자세한 내용은 JBoss EAP에서 서버 보안 구성 가이드의 자격 증명 사용을 위한 컨트롤러 구성 섹션을 참조하십시오.
자격 증명 저장소에서 암호를 가져오도록 호스트를 구성합니다.
자격 증명 저장소에 secret 값을 저장한 경우 다음 명령을 사용하여 서버 시크릿을 인증 정보 저장소의 값으로 설정할 수 있습니다.
/host=SLAVE_HOST_NAME/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(credential-reference={store=STORE_NAME,alias=ALIAS}
서버를 다시 로드해야 합니다. host
인수는
독립 실행형 서버에 적용되지 않습니다.reload --host=HOST_NAME
자세한 내용은 JBoss EAP의 Credential Store 섹션을 참조하십시오. 서버 보안 구성 가이드.
자격 증명 모음에서 암호를 가져오도록 호스트를 구성합니다.
EAP_HOME/bin/vault.sh
스크립트를 사용하여 마스킹된 암호를 생성합니다. 예를 들어VAULT::secret::password::VAULT_SECRET_VALUE
형식의 문자열을 생성합니다.VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0.
참고자격 증명 모음에 암호를 생성할 때 Base64로 인코딩되지 않은 일반 텍스트로 지정해야 합니다.
다음 관리 CLI 명령을 사용하여 보안 값을 지정합니다.
VAULT_SECRET_VALUE
를 이전 단계에서 생성된 마스킹된 암호로 교체해야 합니다./host=master/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${VAULT::secret::password::VAULT_SECRET_VALUE}")
서버를 다시 로드해야 합니다. host
인수는
독립 실행형 서버에 적용되지 않습니다.reload --host=HOST_NAME
자세한 내용은 JBoss EAP 구성 서버 보안 가이드의 Password Vault 섹션을 참조하십시오.
암호를 시스템 속성으로 지정합니다.
다음 예제에서는
server.identity.password
를 암호의 시스템 속성 이름으로 사용합니다.서버 구성 파일에서 암호의 시스템 속성을 지정합니다.
다음 managemente CLI 명령을 사용하여 시스템 속성을 사용하도록 비밀 ID를 구성합니다.
/host=SLAVE_HOST_NAME/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${server.identity.password}")
서버를 다시 로드해야 합니다. host
인수는
독립 실행형 서버에 적용되지 않습니다.reload --host=master
서버를 시작할 때 시스템 속성의 암호를 설정합니다.
명령줄 인수 또는 속성 파일에 전달하여
server.identity.password
시스템 속성을 설정할 수 있습니다.를 일반 텍스트 명령줄 인수로 전달합니다.
서버를 시작하고
server.identity.password
속성을 전달합니다.$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Dserver.identity.password=changeme
주의암호를 일반 텍스트로 입력해야 하며
ps -ef
명령을 실행하는 사용자에게 표시됩니다.속성 파일에서 속성을 설정합니다.
속성 파일을 생성하고 키/값 쌍을 속성 파일에 추가합니다. 예를 들면 다음과 같습니다.
server.identity.password=changeme
주의암호는 일반 텍스트로 되어 있으며 이 속성 파일에 대한 액세스 권한이 있는 사용자에게 표시됩니다.
명령줄 인수를 사용하여 서버를 시작합니다.
$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --properties=PATH_TO_PROPERTIES_FILE
서버를 다시 시작합니다.
이제 슬레이브는 호스트 이름을 사용자 이름으로 사용하고 암호화된 문자열을 암호로 사용하여 마스터에 대해 인증합니다.
독립 실행형 서버 또는 관리형 도메인의 서버 그룹 내의 서버는 이제 mod_cluster 작업자 노드로 구성됩니다. 클러스터된 애플리케이션을 배포하는 경우 해당 세션은 페일오버를 위해 모든 클러스터 노드에 복제되며 외부 웹 서버 또는 로드 밸런서의 요청을 수락할 수 있습니다. 클러스터의 각 노드는 기본적으로 자동 검색을 사용하여 다른 노드를 검색합니다.
24.6.4. mod_cluster fail_on_status 매개 변수 구성
fail_on_status
매개 변수는 클러스터에서 작업자 노드에서 반환되는 경우 해당 노드를 실패로 표시하는 이러한 HTTP 상태 코드를 나열합니다. 그런 다음 로드 밸런서에서 향후 요청을 클러스터의 다른 작업자 노드로 보냅니다. 실패한 작업자 노드는 로드 밸런서에 STATUS
메시지를 전송할 때까지 NOTOK
상태로 유지됩니다.
fail_on_status
매개 변수는 로드 밸런서의 httpd
구성 파일에서 구성해야 합니다. fail_on_status
의 여러 HTTP 상태 코드를 쉼표로 구분된 목록으로 지정할 수 있습니다. 다음 예제에서는 fail_on_status
에 대해 HTTP 상태 코드 203
및 204
를 지정합니다.
예제: fail_on_status 구성
ProxyPass / balancer://MyBalancer stickysession=JSESSIONID|jsessionid nofailover=on failonstatus=203,204 ProxyPassReverse / balancer://MyBalancer ProxyPreserveHost on
24.6.5. 클러스터 간 트래픽 마이그레이션
JBoss EAP를 사용하여 새 클러스터를 생성한 후 업그레이드 프로세스의 일부로 이전 클러스터에서 새 클러스터로 트래픽을 마이그레이션할 수 있습니다. 이 작업에는 최소한의 중단 또는 다운타임으로 이 트래픽을 마이그레이션하는 데 사용할 수 있는 전략이 표시됩니다.
- 새 클러스터 설정. 이 클러스터를 ClusterNEW 라고 합니다.
- 중복되는 이전 클러스터 설정입니다. 이 클러스터를 ClusterOLD 라고 합니다.
클러스터 업그레이드 프로세스 - 부하 분산 그룹
- 사전 요구 사항에 설명된 단계를 사용하여 새 클러스터를 설정합니다.
ClusterNEW 및 ClusterOLD 양쪽에서 구성 옵션
sticky-session
이true
의 기본 설정으로 설정되어 있는지 확인합니다. 이 옵션을 활성화하면 클러스터 노드에 대한 모든 새 요청이 해당 클러스터 노드로 계속 전송됩니다./profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=sticky-session,value=true)
ClusterOLD의 모든 클러스터 노드가
ClusterOLD
로드 밸런싱 그룹의 멤버 라고 가정하여 load-balancing-group
을 ClusterOLD 로 설정합니다./profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=load-balancing-group,value=ClusterOLD)
mod_cluster 작업자 노드 구성 섹션에 설명된 프로세스를 사용하여 ClusterNEW 의 노드를 mod_cluster 구성에 개별적으로 추가합니다. 또한 앞에서 설명한 절차를 사용하여 로드 밸런싱 그룹을 ClusterNEW 로 설정합니다.
이 시점에는 mod_cluster-manager 콘솔에서 낮은 단축된 예와 유사한 출력이 표시됩니다.
mod_cluster/<version> LBGroup ClusterOLD: [Enable Nodes] [Disable Nodes] [Stop Nodes] Node node-1-jvmroute (ajp://node1.oldcluster.example:8009): [Enable Contexts] [Disable Contexts] [Stop Contexts] Balancer: qacluster, LBGroup: ClusterOLD, Flushpackets: Off, ..., Load: 100 Virtual Host 1: Contexts: /my-deployed-application-context, Status: ENABLED Request: 0 [Disable] [Stop] Node node-2-jvmroute (ajp://node2.oldcluster.example:8009): [Enable Contexts] [Disable Contexts] [Stop Contexts] Balancer: qacluster, LBGroup: ClusterOLD, Flushpackets: Off, ..., Load: 100 Virtual Host 1: Contexts: /my-deployed-application-context, Status: ENABLED Request: 0 [Disable] [Stop] LBGroup ClusterNEW: [Enable Nodes] [Disable Nodes] [Stop Nodes] Node node-3-jvmroute (ajp://node3.newcluster.example:8009): [Enable Contexts] [Disable Contexts] [Stop Contexts] Balancer: qacluster, LBGroup: ClusterNEW, Flushpackets: Off, ..., Load: 100 Virtual Host 1: Contexts: /my-deployed-application-context, Status: ENABLED Request: 0 [Disable] [Stop] Node node-4-jvmroute (ajp://node4.newcluster.example:8009): [Enable Contexts] [Disable Contexts] [Stop Contexts] Balancer: qacluster, LBGroup: ClusterNEW, Flushpackets: Off, ..., Load: 100 Virtual Host 1: Contexts: /my-deployed-application-context, Status: ENABLED Request: 0 [Disable] [Stop]
이전 활성 세션은 ClusterOLD 그룹 내에 있으며 모든 새 세션은 ClusterOLD 또는 CLusterNEW 그룹에 생성됩니다. 다음으로 클러스터 노드가 현재 활성 클라이언트 세션에 오류가 발생하지 않고 제거될 수 있도록 전체 ClusterOLD 그룹을 비활성화하려고 합니다.
mod_cluster-manager 웹 콘솔에서 LBGroup ClusterOLD 에 대한 노드 비활성화 링크를 클릭합니다.
이 시점에서 이미 설정된 세션에 속한 요청만 ClusterOLD 로드 밸런싱 그룹의 멤버로 라우팅됩니다. 새 클라이언트의 세션은 ClusterNEW 그룹에만 생성됩니다. ClusterOLD 그룹 내에 활성 세션이 없는 즉시 해당 멤버를 안전하게 제거할 수 있습니다.
참고Stop Nodes 를 사용하면 요청을 이 도메인으로 즉시 라우팅하지 않도록 로드 밸런서를 명령합니다. 그러면 ClusterNEW와 Cluster OLD 간에 세션 복제가 없는 경우 클라이언트에 세션 데이터가 손실되는 다른 로드 밸런싱 그룹으로 강제로 장애 조치됩니다.
기본 부하 분산 그룹
현재 ClusterOLD 설정에 mod_cluster-manager 콘솔의 LBGroup:에서 찾은 로드 밸런싱 그룹 설정이 없는 경우 ClusterOLD 노드를 비활성화할 수 있습니다. 이 경우 각 ClusterOLD 노드에 대해 Disable Contexts (컨텍스트 비활성화)를 클릭합니다. 이러한 노드의 컨텍스트는 비활성화되며 활성 세션이 없으면 제거할 준비가 됩니다. 새 클라이언트의 세션은 컨텍스트가 활성화된 노드에서만 생성됩니다. 이 예에서는 ClusterNEW 멤버일 가능성이 큽니다.
관리 CLI 사용
mod_cluster-manager 웹 콘솔을 사용하는 것 외에도 JBoss EAP 관리 CLI를 사용하여 특정 컨텍스트를 중지하거나 비활성화할 수 있습니다.
문맥 중지
/host=master/server=server-one/subsystem=modcluster:stop-context(context=/my-deployed-application-context, virtualhost=default-host, waittime=0)
대기 시간이
컨텍스트를 중지하면 시간 초과가 발생하지 않고 요청의 모든 요청을 즉시 라우팅하지 않도록 장치에 지시하여 다른 사용 가능한 컨텍스트로 장애 조치(failover)합니다.
0
으로 설정된
waittime
인수를 사용하여 시간 초과 값을 설정하면 이 컨텍스트에서 새 세션이 생성되지 않지만 기존 세션은 완료되거나 지정된 시간 초과가 경과할 때까지 이 노드로 계속 이동합니다. waittime
인수의 기본값은 10
초입니다.
문맥 비활성화
/host=master/server=server-one/subsystem=modcluster:disable-context(context=/my-deployed-application-context, virtualhost=default-host)
컨텍스트를 비활성화하면 이 컨텍스트에서 새 세션을 만들지 않아야 한다고 밸런서에 알립니다.
24.7. Apache mod_jk HTTP 커넥터
Apache mod_jk 는 호환성을 위해 필요한 고객에게 제공되는 HTTP 커넥터입니다.
JBoss EAP는 Apache HTTP 프록시 서버의 워크로드를 허용할 수 있습니다. 프록시 서버는 웹 프론트엔드에서 클라이언트 요청을 수락하고 작업을 전달하여 JBoss EAP 서버에 참여합니다. 고정 세션이 활성화된 경우 서버를 사용할 수 없는 경우가 아니면 동일한 클라이언트 요청이 항상 동일한 JBoss EAP 서버로 이동합니다.
mod_jk는 AJP 1.3 프로토콜을 통해 통신합니다. 다른 프로토콜은 mod_cluster 또는 mod_ proxy 와 함께 사용할 수 있습니다. 자세한 내용은 HTTP 커넥터 개요 를 참조하십시오.
mod_cluster 는 mod_jk보다 고급 로드 밸런서 장치이며 권장되는 HTTP 커넥터입니다. mod_cluster는 mod_jk의 모든 기능과 추가 기능을 제공합니다. JBoss EAP mod_cluster HTTP 커넥터와 달리 Apache mod_jk HTTP 커넥터는 서버 또는 서버 그룹에 배포 상태를 알 수 없으며 그에 따라 작업을 전송할 위치를 조정할 수 없습니다.
자세한 내용은 Apache mod_jk 설명서 를 참조하십시오.
24.7.1. Apache HTTP 서버에서 mod_jk 구성
JBoss Core Services Apache HTTP Server를 설치하거나 JBoss Web Server를 사용할 때 mod_jk.so
는 이미 포함되어 있지만 기본적으로 로드되지 않습니다.
Apache HTTP 서버는 더 이상 3.1.0 버전으로 JBoss Web Server와 함께 배포되지 않습니다.
다음 단계를 사용하여 Apache HTTP Server에서 mod_jk를 로드하고 구성합니다. 이러한 단계에서는 Apache HTTP Server의 httpd/
디렉터리로 이미 이동했다고 가정합니다. 이 디렉토리는 플랫폼에 따라 달라집니다. 자세한 내용은 JBoss Core Services Apache HTTP Server 설치 가이드에서 플랫폼에 대한 설치 지침을 참조하십시오.
또한 Red Hat 고객은 Red Hat 고객 포털에서 부하 분산 구성 도구를 사용하여 mod_jk 및 기타 커넥터를 위한 최적의 구성 템플릿을 신속하게 생성할 수 있습니다. 이 도구에 액세스하려면 로그인해야 합니다.
mod_jk 모듈을 구성합니다.
참고샘플 mod_jk 구성 파일은
conf.d/mod_jk.conf.sample
로 제공됩니다. .sample
확장자를 제거하고 필요에 따라 내용을 수정하여 자체 파일을 생성하는 대신 이 샘플을 사용할 수 있습니다.conf.d/mod_jk.conf
라는 새 파일을 만듭니다. 다음 구성을 파일에 추가하여 요구 사항에 맞게 내용을 수정합니다.# Load mod_jk module # Specify the filename of the mod_jk lib LoadModule jk_module modules/mod_jk.so # Where to find workers.properties JkWorkersFile conf.d/workers.properties # Where to put jk logs JkLogFile logs/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info # Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y]" # JkOptions indicates to send SSK KEY SIZE JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories # JkRequestLogFormat JkRequestLogFormat "%w %V %T" # Mount your applications JkMount /application/* loadbalancer # Add shared memory. # This directive is present with 1.2.10 and # later versions of mod_jk, and is needed for # for load balancing to work properly JkShmFile logs/jk.shm # Add jkstatus for managing runtime data <Location /jkstatus/> JkMount status Require ip 127.0.0.1 </Location>
참고JkMount 지시문은 Apache HTTP Server가 mod_jk 모듈로 전달해야 하는 URL을 지정합니다. 지시문의 구성에 따라 mod_jk는 수신된 URL을 올바른 작업자에게 보냅니다. 정적 콘텐츠를 직접 제공하고 Java 애플리케이션의 로드 밸런서 장치만 사용하려면 URL 경로가
/application/*
여야 합니다. mod_jk를 로드 밸런서 장치로 사용하려면/*
값을 사용하여 모든 URL을 mod_jk로 전달합니다.일반적인 mod_jk 구성 외에도 이 파일은
mod_jk.so
모듈을 로드하도록 지정하고workers.properties
파일을 찾을 위치를 정의합니다.mod_jk 작업자 노드를 구성합니다.
참고샘플 작업자 구성 파일은
conf.d/workers.properties.sample
에서 제공됩니다. .sample
확장자를 제거하고 필요에 따라 내용을 수정하여 자체 파일을 생성하는 대신 이 샘플을 사용할 수 있습니다.conf.d/workers.properties
라는 새 파일을 만듭니다. 다음 구성을 파일에 추가하여 요구 사항에 맞게 내용을 수정합니다.# Define list of workers that will be used # for mapping requests worker.list=loadbalancer,status # Define Node1 # modify the host as your host IP or DNS name. worker.node1.port=8009 worker.node1.host=node1.mydomain.com worker.node1.type=ajp13 worker.node1.ping_mode=A worker.node1.lbfactor=1 # Define Node2 # modify the host as your host IP or DNS name. worker.node2.port=8009 worker.node2.host=node2.mydomain.com worker.node2.type=ajp13 worker.node2.ping_mode=A worker.node2.lbfactor=1 # Load-balancing behavior worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 # Status worker for managing load balancer worker.status.type=status
mod_jk
workers.properties
파일 및 기타 고급 구성 옵션의 구문에 대한 자세한 내용은 mod_jk Worker Properties 를 참조하십시오.선택적으로 JKMountFile 지시문을 지정합니다.
mod-jk.conf의 JKMount 지시문 외에도 mod_jk
로 전달할 여러 URL 패턴을 포함하는 파일을 지정할 수 있습니다.uriworkermap.properties
파일을 만듭니다.참고샘플 URI 작업자 맵 구성 파일은
conf.d/uriworkermap.properties.sample
에 제공됩니다. .sample
확장자를 제거하고 필요에 따라 내용을 수정하여 자체 파일을 생성하는 대신 이 샘플을 사용할 수 있습니다.conf.d/uriworkermap.properties
라는 새 파일을 만듭니다. 일치할 각 URL 패턴에 대한 행을 추가합니다. 예를 들면 다음과 같습니다.# Simple worker configuration file /*=loadbalancer
uriworkermap.properties
파일을 가리키도록 구성을 업데이트합니다.conf.d/mod_jk.conf
에 다음을 추가합니다.# Use external file for mount points. # It will be checked for updates each 60 seconds. # The format of the file is: /url=worker # /examples/*=loadbalancer JkMountFile conf.d/uriworkermap.properties
mod_jk 구성에 대한 자세한 내용은 JBoss Web Server HTTP 커넥터 및 로드 밸런싱 가이드의 mod_jk 로드로 Apache HTTP 서버 구성 섹션을 참조하십시오.
24.7.2. mod_jk와 커밋하도록 JBoss EAP 구성
JBoss EAP undertow
하위 시스템은 에서 요청을 수락하고 외부 웹 서버로 다시 응답을 보내려면 리스너를 지정해야 합니다. mod_jk는 AJP 프로토콜을 사용하므로 AJP 리스너를 구성해야 합니다.
기본 고가용성 구성 ha 또는 full-ha 중 하나를 사용하는 경우 AJP 리스너가 이미 구성되어 있습니다.
자세한 내용은 외부 웹 서버에서 요청 수락을 참조하십시오.
24.8. Apache mod_proxy HTTP 커넥터
Apache mod_proxy 는 AJP, HTTP 및 HTTPS 프로토콜에 대한 연결을 지원하는 HTTP 커넥터입니다. mod_proxy는 부하 분산 또는 비로드 밸런싱 구성으로 구성할 수 있으며 고정 세션 개념을 지원합니다.
mod_proxy 모듈을 사용하려면 사용하려는 프로토콜에 따라 JBoss EAP에 the undertow
하위 시스템에 구성된 HTTP, HTTPS 또는 AJP 리스너가 있어야 합니다.
mod_cluster 는 mod_proxy보다 고급 로드 밸런서 장치이며 권장되는 HTTP 커넥터입니다. mod_cluster는 mod_proxy의 모든 기능과 추가 기능을 제공합니다. JBoss EAP mod_cluster HTTP 커넥터와 달리 Apache mod_proxy HTTP 커넥터는 서버 또는 서버 그룹에 배포 상태를 알 수 없으며 그에 따라 작업을 전송할 위치를 조정할 수 없습니다.
자세한 내용은 Apache mod_proxy 설명서 를 참조하십시오.
24.8.1. Apache HTTP 서버에서 mod_proxy 구성
JBoss Core Services Apache HTTP Server를 설치하거나 JBoss Web Server를 사용할 때 mod_proxy 모듈은 이미 포함되어 있으며 기본적으로 로드됩니다.
Apache HTTP 서버는 더 이상 3.1.0 버전으로 JBoss Web Server와 함께 배포되지 않습니다.
기본 로드 밸런싱 또는 비로드 밸런싱 프록시를 구성하려면 아래 적절한 섹션을 참조하십시오. 이 단계에서는 Apache HTTP Server의 httpd/
디렉토리로 이미 이동했다고 가정합니다. 이 디렉토리는 플랫폼에 따라 달라집니다. 자세한 내용은 JBoss Core Services Apache HTTP Server 설치 가이드에서 플랫폼에 대한 설치 지침을 참조하십시오. 또한 필요한 HTTP 리스너가 JBoss EAP undertow 하위 시스템에서
이미 구성되었다고 가정합니다.
또한 Red Hat 고객은 Red Hat 고객 포털에서 부하 분산 구성 도구를 사용하여 mod_proxy 및 기타 커넥터를 위한 최적의 구성 템플릿을 신속하게 생성할 수 있습니다. 이 도구에 액세스하려면 로그인해야 합니다.
비로드 밸런싱 프록시 추가
다음 구성을 conf/httpd.conf
파일에 직접 추가하고 다른 <VirtualHost>
지시문 아래에 직접 추가합니다. 값을 설정에 적합한 값으로 바꿉니다.
<VirtualHost *:80>
# Your domain name
ServerName YOUR_DOMAIN_NAME
ProxyPreserveHost On
# The IP and port of JBoss
# These represent the default values, if your httpd is on the same host
# as your JBoss managed domain or server
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
# The location of the HTML files, and access control information
DocumentRoot /var/www
<Directory /var/www>
Options -Indexes
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
로드 밸런싱 프록시 추가
기본 Apache HTTP Server 구성에는 mod_cluster와 호환되지 않으므로 mod_proxy_balancer.so
모듈이 비활성화되어 있습니다. 이 작업을 완료하려면 이 모듈을 로드하고 mod_cluster 모듈을 비활성화해야 합니다.
mod_proxy를 로드 밸런서 장치로 사용하고 여러 JBoss EAP 인스턴스에 작업을 보내려면 conf/httpd.conf
파일에 다음 구성을 추가합니다. 예제 IP 주소는 가상적입니다. 해당 값을 환경에 적절한 값으로 바꿉니다.
<Proxy balancer://mycluster>
Order deny,allow
Allow from all
# Add each JBoss Enterprise Application Server by IP address and port.
# If the route values are unique like this, one node will not fail over to the other.
BalancerMember http://192.168.1.1:8080 route=node1
BalancerMember http://192.168.1.2:8180 route=node2
</Proxy>
<VirtualHost *:80>
# Your domain name
ServerName YOUR_DOMAIN_NAME
ProxyPreserveHost On
ProxyPass / balancer://mycluster/
# The location of the HTML files, and access control information DocumentRoot /var/www
<Directory /var/www>
Options -Indexes
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
위의 예는 모두 HTTP 프로토콜을 사용하여 통신합니다. 적절한 mod_proxy 모듈을 로드하는 경우 대신 AJP 또는 HTTPS 프로토콜을 사용할 수 있습니다. 자세한 내용은 Apache mod_proxy 설명서 를 참조하십시오.
스티키 세션 활성화
고정 세션은 클라이언트 요청이 원래 특정 JBoss EAP 작업자로 이동하는 경우 사용할 수 없게 되는 경우가 아니면 모든 향후 요청이 동일한 작업자로 전송됩니다. 이는 거의 항상 권장되는 동작입니다.
mod_proxy에 대한 고정 세션을 활성화하려면 stickysession
매개 변수를 ProxyPass
문에 추가합니다.
ProxyPass / balancer://mycluster stickysession=JSESSIONID
lbmethod
및 nofailover
와 같은 ProxyPass
문에 추가 매개변수를 지정할 수 있습니다. 사용 가능한 매개 변수에 대한 자세한 내용은 Apache mod_proxy 설명서 를 참조하십시오.
24.8.2. mod_proxy와 커밋하도록 JBoss EAP 구성
JBoss EAP undertow
하위 시스템은 에서 요청을 수락하고 외부 웹 서버로 다시 응답을 보내려면 리스너를 지정해야 합니다. 사용할 프로토콜에 따라 리스너를 구성해야 할 수도 있습니다.
HTTP 리스너는 JBoss EAP 기본 구성에서 구성됩니다. 기본 고가용성 구성 ha 또는 full-ha 중 하나를 사용하는 경우 AJP 리스너도 미리 구성됩니다.
자세한 내용은 외부 웹 서버에서 요청 수락을 참조하십시오.
24.9. Microsoft ISAPI Connector
IISAPI(Internet Server API)는 Microsoft의 IIS(Internet Information Services)와 같은 웹 서버에 대한 OLE Server 확장 및 필터를 작성하는 데 사용되는 API 집합입니다 . isapi_redirect는
IIS에 맞게 조정된 mod_jk 의 확장 입니다. isapi_redirect를 사용하면
JBoss EAP 인스턴스를 IIS를 로드 밸런서로 사용하는 작업자 노드로 구성할 수 있습니다.
지원되는 Windows Server 및 IIS 구성에 대한 자세한 내용은 JBoss EAP 지원 구성을 참조하십시오.
24.9.1. ISAPI 커넥터를 사용하도록 Microsoft IIS 구성
Red Hat 고객 포털에서 ISAPI 커넥터를 다운로드합니다.
- 브라우저를 열고 Red Hat Customer Portal JBoss Software Downloads 페이지에 로그인합니다.
- Product(제품) 드롭다운 메뉴에서 Web Connectors (웹 커넥터)를 선택합니다.
- Version(버전) 드롭다운 메뉴에서 최신 JBoss Core Services 버전을 선택합니다.
- 목록에서 Red Hat JBoss Core Services ISAPI 커넥터 를 찾은 다음 다운로드 링크를 클릭합니다.
-
아카이브를 추출하고 the
sbin
디렉터리의 콘텐츠를 서버의 위치에 복사합니다. 아래 지침에서는 내용이C:\connectors\
에 복사되었다고 가정합니다.
IIS 관리자(IIS 7)를 사용하여 IIS Redirector를 구성하려면 다음을 수행합니다.
-
시작 → 실행을 클릭하고
inetmgr
을 입력하여 IIS 관리자를 엽니다. - 왼쪽의 트리 보기 창에서 IIS 7 을 확장합니다.
- ISAPI 및 CGI 등록을 두 번 클릭하여 새 창에서 엽니다.
- Actions(작업) 창에서 Add(추가 )를 클릭합니다. Add ISAPI or CGI Restriction( ISAPI 또는 CGI 제한 추가) 창이 열립니다.
다음 값을 지정합니다.
-
ISAPI 또는 CGI 경로:
C:\connectors\isapi_redirect.dll
-
설명:
jboss
- 실행할 확장 경로를 허용: 확인란을 선택합니다.
-
ISAPI 또는 CGI 경로:
- OK(확인 )를 클릭하여 Add ISAPI or CGI Restriction( ISAPI 또는 CGI 제한 추가) 창을 닫습니다.
JBoss Native 가상 디렉토리 정의
- Default Web Site 를 마우스 오른쪽 버튼으로 클릭하고 Add Virtual Directory(가상 디렉터리 추가 )를 클릭합니다. Add Virtual Directory(가상 디렉터리 추가) 창이 열립니다.
가상 디렉터리를 추가하려면 다음 값을 지정합니다.
-
alias:
jboss
-
물리적 경로:
C:\connectors\
-
alias:
- OK(확인 )를 클릭하여 값을 저장하고 Add Virtual Directory(가상 디렉터리 추가) 창을 닫습니다.
JBoss Native ISAPI 리디렉션 필터 정의
- 트리 보기 창에서 Sites → Default Web Site 를 확장합니다.
- ISAPI 필터를 두 번 클릭합니다. ISAPI Filters Features( ISAPI 필터 기능 ) 보기가 표시됩니다.
- Actions(작업) 창에서 Add(추가)를 클릭합니다. Add ISAPI Filter( ISAPI 필터 추가) 창이 표시됩니다.
Add ISAPI Filter( ISAPI 필터 추가) 창에서 다음 값을 지정합니다.
-
필터 이름:
jboss
-
실행 가능 :
C:\connectors\isapi_redirect.dll
-
필터 이름:
- OK(확인 )를 클릭하여 값을 저장하고 Add ISAPI Filters( ISAPI 필터 추가) 창을 닫습니다.
ISAPI- 핸들러 활성화
- 트리 보기 창에서 IIS 7 항목을 두 번 클릭합니다. IIS 7 Home Features 뷰가 열립니다.
- 핸들러 매핑을 두 번 클릭합니다. Handler Mappings Features View 가 표시됩니다.
- Group by 콤보 상자에서 State 를 선택합니다. 핸들러 맵핑은 Enabled(활성화됨) 및 Disabled Groups(비활성화 된 그룹) 에 표시됩니다.
-
ISAPI- 뷰어 찾기
. Disabled 그룹에 있는 경우 마우스 오른쪽 버튼으로 클릭하고 기능 권한 편집을 선택합니다. 다음 권한을 활성화합니다.
- 읽기
- 스크립트
- 실행
- OK(확인 )를 클릭하여 값을 저장하고 Edit Feature Permissions(기능 권한 편집) 창을 닫습니다.
Microsoft IIS는 이제 ISAPI 커넥터를 사용하도록 구성됩니다.
24.9.2. 클라이언트 요청을 JBoss EAP에 보내도록 ISAPI 커넥터 구성
이 작업은 ISAPI 커넥터의 요청을 수락하도록 JBoss EAP 서버 그룹을 구성합니다. 부하 분산 또는 고가용성 페일오버를 위한 구성은 포함되지 않습니다.
이 구성은 IIS 서버에서 수행되며, 이미 외부 웹 서버의 요청을 수락 하도록 JBoss EAP가 구성되어 있다고 가정합니다. 또한 IIS 서버에 대한 전체 관리자 액세스 권한이 필요하며 ISAPI 커넥터를 사용하도록 IIS를 구성해야 합니다.
속성 파일 만들기 및 리디렉션 설정
로그, 속성 파일 및 잠금 파일을 저장할 디렉터리를 만듭니다.
이 절차의 나머지 부분에서는 이 목적을 위해
C:\connectors\
디렉토리를 사용하고 있다고 가정합니다. 다른 디렉터리를 사용하는 경우 그에 따라 지침을 수정합니다.isapi_redirect.properties
파일을 생성합니다.C:\connectors\isapi_redirect.properties
라는 새 파일을 생성합니다. 다음 내용을 파일에 복사합니다.# Configuration file for the ISAPI Connector # Extension uri definition extension_uri=/jboss/isapi_redirect.dll # Full path to the log file for the ISAPI Connector log_file=c:\connectors\isapi_redirect.log # Log level (debug, info, warn, error or trace) log_level=info # Full path to the workers.properties file worker_file=c:\connectors\workers.properties # Full path to the uriworkermap.properties file worker_mount_file=c:\connectors\uriworkermap.properties #Full path to the rewrite.properties file rewrite_rule_file=c:\connectors\rewrite.properties
rewrite
.properties
파일을 사용하지 않으려면 행의 시작 부분에#
문자를 넣어 마지막 행을 주석 처리합니다.uriworkermap.properties
파일을 만듭니다.uriworkermap.properties
파일에는 배포된 애플리케이션 URL과 요청을 처리하는 작업자 간 매핑이 포함되어 있습니다. 다음 예제 파일은 파일의 구문을 보여줍니다.uriworkermap.properties
파일을C:\connectors\에 배치합니다
.# images and css files for path /status are provided by worker01 /status=worker01 /images/*=worker01 /css/*=worker01 # Path /web-console is provided by worker02 # IIS (customized) error page is used for http errors with number greater or equal to 400 # css files are provided by worker01 /web-console/*=worker02;use_server_errors=400 /web-console/css/*=worker01 # Example of exclusion from mapping, logo.gif won't be displayed # !/web-console/images/logo.gif=* # Requests to /app-01 or /app-01/something will be routed to worker01 /app-01|/*=worker01 # Requests to /app-02 or /app-02/something will be routed to worker02 /app-02|/*=worker02
workers.properties
파일을 생성합니다.workers.properties
파일에는 작업자 레이블과 서버 인스턴스 간 매핑 정의가 포함되어 있습니다. 이 파일은 Apache mod_jk 작업자 속성 구성에 사용된 것과 동일한 파일의 구문을 따릅니다.다음은
workers.properties
파일의 예입니다. 작업자 이름worker01
및worker02
는 JBoss EAPundertow 하위 시스템에서
구성된instance-id
와 일치해야 합니다.이 파일을
C:\connectors\
디렉토리에 배치합니다.# An entry that lists all the workers defined worker.list=worker01, worker02 # Entries that define the host and port associated with these workers # First JBoss EAP server definition, port 8009 is standard port for AJP in EAP worker.worker01.host=127.0.0.1 worker.worker01.port=8009 worker.worker01.type=ajp13 # Second JBoss EAP server definition worker.worker02.host=127.0.0.100 worker.worker02.port=8009 worker.worker02.type=ajp13
rewrite
.properties
파일을 만듭니다.rewrite
.properties
파일에는 특정 애플리케이션에 대한 간단한 URL 재작성 규칙이 포함되어 있습니다. 다시 작성된 경로는 아래 예와 같이 이름-값 쌍을 사용하여 지정합니다. 이 파일을C:\connectors\
디렉토리에 배치합니다.#Simple example # Images are accessible under abc path /app-01/abc/=/app-01/images/
net stop 및 net
start 명령을 사용하여 IIS 서버를 다시 시작합니다
.C:\> net stop was /Y C:\> net start w3svc
IIS 서버는 애플리케이션별로 구성한 특정 JBoss EAP 서버에 클라이언트 요청을 보내도록 구성되어 있습니다.
24.9.3. 여러 JBoss EAP 서버 간에 클라이언트 요청의 균형을 맞추도록 ISAPI 커넥터 구성
이 구성은 지정한 JBoss EAP 서버 간에 클라이언트 요청의 균형을 조정합니다. 이 구성은 IIS 서버에서 수행되며, 이미 외부 웹 서버의 요청을 수락 하도록 JBoss EAP가 구성되어 있다고 가정합니다. 또한 IIS 서버에 대한 전체 관리자 액세스 권한이 필요하며 ISAPI 커넥터를 사용하도록 IIS를 구성해야 합니다.
여러 서버 간에 클라이언트 요청 분산
로그, 속성 파일 및 잠금 파일을 저장할 디렉터리를 만듭니다.
이 절차의 나머지 부분에서는 이 목적을 위해
C:\connectors\
디렉토리를 사용하고 있다고 가정합니다. 다른 디렉터리를 사용하는 경우 그에 따라 지침을 수정합니다.isapi_redirect.properties
파일을 생성합니다.C:\connectors\isapi_redirect.properties
라는 새 파일을 생성합니다. 다음 내용을 파일에 복사합니다.# Configuration file for the ISAPI Connector # Extension uri definition extension_uri=/jboss/isapi_redirect.dll # Full path to the log file for the ISAPI Connector log_file=c:\connectors\isapi_redirect.log # Log level (debug, info, warn, error or trace) log_level=info # Full path to the workers.properties file worker_file=c:\connectors\workers.properties # Full path to the uriworkermap.properties file worker_mount_file=c:\connectors\uriworkermap.properties #OPTIONAL: Full path to the rewrite.properties file rewrite_rule_file=c:\connectors\rewrite.properties
rewrite
.properties
파일을 사용하지 않으려면 행의 시작 부분에#
문자를 넣어 마지막 행을 주석 처리합니다.uriworkermap.properties
파일을 만듭니다.uriworkermap.properties
파일에는 배포된 애플리케이션 URL과 요청을 처리하는 작업자 간 매핑이 포함되어 있습니다. 다음 예제 파일은 부하 분산 구성을 사용하여 파일의 구문을 보여줍니다. 와일드카드(*
) 문자는 다양한 URL 하위 디렉터리에 대한 모든 요청을 라우터라는 로드 밸런서 장치로 전송합니다. 로드 밸런서의 구성은 다음 단계에서 다룹니다.uriworkermap.properties
파일을C:\connectors\에 배치합니다
.# images, css files, path /status and /web-console will be # provided by nodes defined in the load-balancer called "router" /css/*=router /images/*=router /status=router /web-console|/*=router # Example of exclusion from mapping, logo.gif won't be displayed # !/web-console/images/logo.gif=* # Requests to /app-01 and /app-02 will be routed to nodes defined # in the load-balancer called "router" /app-01|/*=router /app-02|/*=router # mapping for management console, nodes in cluster can be enabled or disabled here /jkmanager|/*=status
workers.properties
파일을 생성합니다.workers.properties
파일에는 작업자 레이블과 서버 인스턴스 간 매핑 정의가 포함되어 있습니다. 이 파일은 Apache mod_jk 작업자 속성 구성에 사용된 것과 동일한 파일의 구문을 따릅니다.다음은
workers.properties
파일의 예입니다. 로드 밸런서 장치는 파일의 끝부분에 구성되어 작업자worker01 및 worker
02
를 구성합니다. 이러한 작업자 이름은 JBoss EAPundertow
하위 시스템에 구성된instance-id
와 일치해야 합니다.이 파일을
C:\connectors\
디렉토리에 배치합니다.# The advanced router LB worker worker.list=router,status # First EAP server definition, port 8009 is standard port for AJP in EAP # # lbfactor defines how much the worker will be used. # The higher the number, the more requests are served # lbfactor is useful when one machine is more powerful # ping_mode=A – all possible probes will be used to determine that # connections are still working worker.worker01.port=8009 worker.worker01.host=127.0.0.1 worker.worker01.type=ajp13 worker.worker01.ping_mode=A worker.worker01.socket_timeout=10 worker.worker01.lbfactor=3 # Second EAP server definition worker.worker02.port=8009 worker.worker02.host=127.0.0.100 worker.worker02.type=ajp13 worker.worker02.ping_mode=A worker.worker02.socket_timeout=10 worker.worker02.lbfactor=1 # Define the LB worker worker.router.type=lb worker.router.balance_workers=worker01,worker02 # Define the status worker for jkmanager worker.status.type=status
rewrite
.properties
파일을 만듭니다.rewrite
.properties
파일에는 특정 애플리케이션에 대한 간단한 URL 재작성 규칙이 포함되어 있습니다. 다시 작성된 경로는 아래 예와 같이 이름-값 쌍을 사용하여 지정합니다. 이 파일을C:\connectors\
디렉토리에 배치합니다.#Simple example # Images are accessible under abc path /app-01/abc/=/app-01/images/ Restart the IIS server. Restart your IIS server by using the net stop and net start commands. C:\> net stop was /Y C:\> net start w3svc
IIS 서버는 workers.properties
파일에서 참조된 JBoss EAP 서버에 클라이언트 요청을 전송하여 1:3
비율로 서버 전체에 부하를 분산하도록 구성되어 있습니다. 이 비율은 각 서버에 할당된 로드 밸런싱 인수인 lbfactor
에서 파생됩니다.
24.10. Oracle NSAPI 커넥터
NSAPI(Netscape Server API)는 서버에 대한 확장을 구현하기 위해 이전에 Netscape Web Server인 Oracle iPlanet Web Server에서 제공하는 API입니다. 이러한 확장 프로그램을 서버 플러그인이라고 합니다. NSAPI 커넥터는 Oracle iPlanet Web Server에 맞게 조정된 mod _jk의 확장 기능인 nsapi_redirector.so
에 사용됩니다. NSAPI 커넥터를 사용하면 Oracle iPlanet Web Server를 로드 밸런서 장치로 사용하여 JBoss EAP 인스턴스를 작업자 노드로 구성할 수 있습니다.
Solaris 및 Oracle iPlanet Web Server의 지원되는 구성에 대한 자세한 내용은 JBoss EAP 지원 구성을 참조하십시오.
24.10.1. NSAPI 커넥터를 사용하도록 Oracle iPlanet 웹 서버 구성
사전 요구 사항
- JBoss EAP는 작업자 역할을 할 각 서버에 설치 및 구성됩니다.
Red Hat 고객 포털에서 NSAPI 커넥터를 다운로드합니다.
- 브라우저를 열고 Red Hat Customer Portal JBoss Software Downloads 페이지에 로그인합니다.
- Product(제품) 드롭다운 메뉴에서 Web Connectors (웹 커넥터)를 선택합니다.
- Version(버전) 드롭다운 메뉴에서 최신 JBoss Core Services 버전을 선택합니다.
- 목록에서 Red Hat JBoss Core Services NSAPI 커넥터 를 찾아 시스템에 맞는 올바른 플랫폼 및 아키텍처를 선택하고 다운로드 링크를 클릭합니다.
-
lib/ 또는
lib64/
디렉터리에nsapi_redirector.so
파일을IPLANET_CONFIG/lib/
또는IPLANET_CONFIG/lib64/
디렉터리에 추출합니다.
NSAPI 커넥터를 설정합니다.
이 지침에서 IPLANET_CONFIG
는 일반적으로 /opt/oracle/webserver7/config/
인 Oracle iPlanet 구성 디렉토리를 나타냅니다. Oracle iPlanet 구성 디렉터리가 다른 경우 그에 따라 지침을 수정합니다.
서블릿 매핑 비활성화.
IPLANET_CONFIG/default.web.xml
파일을 열고 built In Server Mappings 라는 제목으로 섹션을 찾습니다. XML 주석 문자(<!--
및¢)로 래핑하여 다음 세 개의 서블릿에 대한 매핑을 비활성화합니다.
- default
- 호출자
jsp
다음 예제 구성은 비활성화된 매핑을 보여줍니다.
<!-- ============== Built In Servlet Mappings =============== --> <!-- The servlet mappings for the built in servlets defined above. --> <!-- The mapping for the default servlet --> <!--servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping--> <!-- The mapping for the invoker servlet --> <!--servlet-mapping> <servlet-name>invoker</servlet-name> <url-pattern>/servlet/*</url-pattern> </servlet-mapping--> <!-- The mapping for the Jakarta Server Pages servlet --> <!--servlet-mapping> <servlet-name>jsp</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping-->
파일을 저장하고 종료합니다.
NSAPI 커넥터 모듈을 로드하도록 iPlanet 웹 서버를 구성합니다.
IPLANET_CONFIG/magnus.conf
파일의 끝에 다음 행을 추가하고 구성에 맞게 파일 경로를 수정합니다. 이러한 행은nsapi_redirector.so
모듈의 위치와 작업자와 해당 속성을 나열하는workers.properties
파일의 위치를 정의합니다.Init fn="load-modules" funcs="jk_init,jk_service" shlib="/lib/nsapi_redirector.so" shlib_flags="(global|now)" Init fn="jk_init" worker_file="IPLANET_CONFIG/connectors/workers.properties" log_level="info" log_file="IPLANET_CONFIG/connectors/nsapi.log" shm_file="IPLANET_CONFIG/connectors/tmp/jk_shm"
위의 구성은 32비트 아키텍처용입니다. 64비트 Solaris를 사용하는 경우
lib/nsapi_redirector.so
문자열을lib64/nsapi_redirector.so
로 변경합니다.파일을 저장하고 종료합니다.
NSAPI 커넥터를 구성합니다.
부하 분산 또는 부하 분산 구성을 사용하여 기본 구성에 대해 NSAPI 커넥터를 구성할 수 있습니다. 다음 옵션 중 하나를 선택한 후 설정이 완료됩니다.
24.10.2. 클라이언트 요청을 JBoss EAP에 보내도록 NSAPI 커넥터 구성
이 작업은 부하 분산 또는 페일오버 없이 클라이언트 요청을 JBoss EAP 서버로 리디렉션하도록 NSAPI 커넥터를 구성합니다. 리디렉션은 배포별로 수행되므로 URL별로 다릅니다.
이 작업을 계속하기 전에 NSAPI 커넥터를 이미 구성해야 합니다.
기본 HTTP 커넥터 설정
JBoss EAP 서버로 리디렉션할 URL 경로를 정의합니다.
참고IPLANET_CONFIG/obj.conf
에서 행이 이전 행의 연속인 경우를 제외하고는 행 시작 부분에 공백이 허용되지 않습니다.IPLANET_CONFIG/obj.conf
파일을 편집합니다. <Object name="default"> 로 시작하는 섹션을 찾고 아래의 예제 파일에 표시된 형식으로 일치하는 각 URL 패턴을 추가합니다. jknsapi 문자열은 다음 단계에서 정의할 HTTP 커넥터를 나타냅니다. 이 예제에서는 패턴 일치에 와일드카드를 사용하는 것을 보여줍니다.<Object name="default"> [...] NameTrans fn="assign-name" from="/status" name="jknsapi" NameTrans fn="assign-name" from="/images(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/css(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/nc(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/jmx-console(|/*)" name="jknsapi" </Object>
각 경로를 제공하는 작업자를 정의합니다.
IPLANET_CONFIG/obj.conf
파일을 계속 편집합니다. 방금 편집한 섹션의 닫기 태그 바로 뒤에 다음을 추가합니다. </Object>.<Object name="jknsapi"> ObjectType fn=force-type type=text/plain Service fn="jk_service" worker="worker01" path="/status" Service fn="jk_service" worker="worker02" path="/nc(/*)" Service fn="jk_service" worker="worker01" </Object>
위의 예제에서는 요청을 worker 01 이라는 작업자로 URL 경로 /status 로 리디렉션하고
/nc/
아래의 모든 URL 경로를 worker02 라는 작업자로 리디렉션합니다. 세 번째 줄은 이전 행과 일치하지 않는 jknsapi 오브젝트에 할당된 모든 URL이 worker01 에 제공됨을 나타냅니다.파일을 저장하고 종료합니다.
작업자 및 해당 속성을 정의합니다.
IPLANET_CONFIG/connectors/
디렉터리에workers.properties
라는 파일을 생성합니다. 다음 내용을 파일에 붙여넣고 환경에 맞게 수정합니다.# An entry that lists all the workers defined worker.list=worker01, worker02 # Entries that define the host and port associated with these workers worker.worker01.host=127.0.0.1 worker.worker01.port=8009 worker.worker01.type=ajp13 worker.worker02.host=127.0.0.100 worker.worker02.port=8009 worker.worker02.type=ajp13
workers.properties
파일은 Apache mod_jk와 동일한 구문을 사용합니다.파일을 저장하고 종료합니다.
iPlanet 웹 서버 다시 시작
다음 명령을 실행하여 iPlanet 웹 서버를 다시 시작합니다.
IPLANET_CONFIG/../bin/stopserv IPLANET_CONFIG/../bin/startserv
이제 iPlanet Web Server에서 JBoss EAP에 배포하도록 구성한 URL로 클라이언트 요청을 보냅니다.
24.10.3. 여러 JBoss EAP 서버 간에 클라이언트 요청의 균형을 조정하도록 NSAPI 커넥터 구성
이 작업은 부하 분산 구성에서 클라이언트 요청을 JBoss EAP 서버로 보내도록 NSAPI 커넥터를 구성합니다.
이 작업을 계속하기 전에 NSAPI 커넥터를 이미 구성해야 합니다.
로드 밸런싱을 위한 커넥터 구성
JBoss EAP 서버로 리디렉션할 URL 경로를 정의합니다.
참고IPLANET_CONFIG/obj.conf
에서 행이 이전 행의 연속인 경우를 제외하고는 행 시작 부분에 공백이 허용되지 않습니다.IPLANET_CONFIG/obj.conf
파일을 편집합니다.<Object name="default">
로 시작하는 섹션을 찾고 아래의 예제 파일에 표시된 형식으로 일치하는 각 URL 패턴을 추가합니다.jknsapi
문자열은 다음 단계에서 정의할 HTTP 커넥터를 나타냅니다. 이 예제에서는 패턴 일치에 와일드카드를 사용하는 것을 보여줍니다.<Object name="default"> [...] NameTrans fn="assign-name" from="/status" name="jknsapi" NameTrans fn="assign-name" from="/images(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/css(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/nc(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/jmx-console(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/jkmanager/*" name="jknsapi" </Object>
각 경로를 제공하는 작업자를 정의합니다.
IPLANET_CONFIG/obj.conf
파일을 계속 편집합니다. 이전 단계에서 수정한 섹션의 닫기 태그 바로 뒤에</Object>
다음 새 섹션을 추가하고 요구 사항에 맞게 수정합니다.<Object name="jknsapi"> ObjectType fn=force-type type=text/plain Service fn="jk_service" worker="status" path="/jkmanager(/*)" Service fn="jk_service" worker="router" </Object>
This
jksnapi
오브젝트는기본
개체에서name="jksnapi"
매핑에 매핑된 각 경로를 제공하는 데 사용되는 작업자 노드를 정의합니다./jkmanager/*
와 일치하는 URL을 제외한 모든 것이router
이라는 작업자로 리디렉션됩니다.작업자 및 해당 속성을 정의합니다.
IPLANET_CONFIG/connector/
에workers.properties
라는 파일을 만듭니다. 다음 내용을 파일에 붙여넣고 환경에 맞게 수정합니다.# The advanced router LB worker # A list of each worker worker.list=router,status # First JBoss EAP server # (worker node) definition. # Port 8009 is the standard port for AJP # worker.worker01.port=8009 worker.worker01.host=127.0.0.1 worker.worker01.type=ajp13 worker.worker01.ping_mode=A worker.worker01.socket_timeout=10 worker.worker01.lbfactor=3 # Second JBoss EAP server worker.worker02.port=8009 worker.worker02.host=127.0.0.100 worker.worker02.type=ajp13 worker.worker02.ping_mode=A worker.worker02.socket_timeout=10 worker.worker02.lbfactor=1 # Define the load-balancer called "router" worker.router.type=lb worker.router.balance_workers=worker01,worker02 # Define the status worker worker.status.type=status
workers.properties
파일은 Apache mod_jk와 동일한 구문을 사용합니다.파일을 저장하고 종료합니다.
iPlanet 웹 서버 7.0을 다시 시작합니다.
IPLANET_CONFIG/../bin/stopserv IPLANET_CONFIG/../bin/startserv
iPlanet 웹 서버는 로드 밸런싱 구성에서 구성한 URL 패턴을 JBoss EAP 서버로 리디렉션합니다.
부록 A. 참고 자료
A.1. 서버 런타임 인수
애플리케이션 서버 시작 스크립트는 런타임 시 인수를 허용하고 전환됩니다. 이렇게 하면 standalone.xml,
구성 파일에 정의된 대체 구성으로 서버를 시작할 수 있습니다.
domain.xml 및
host.xml
대체 구성에는 대체 소켓 바인딩 집합 또는 보조 구성을 사용하여 서버 시작이 포함될 수 있습니다.
시작 시 help switch -h
또는 --help
를 전달하여 사용 가능한 매개변수 목록에 액세스할 수 있습니다.
표 A.1. 런타임 스위치 및 인수
인수 또는 스위치 | 운영 모드 | 설명 |
---|---|---|
--admin-only | 독립 실행형 |
서버의 실행 중인 유형을 |
--admin-only | 도메인 |
호스트 컨트롤러의 실행 중인 유형을 |
-b=<value>, -b <value> | 독립 실행형, 도메인 |
공용 인터페이스에 대한 바인드 주소를 구성하는 데 사용되는 시스템 속성 |
-b<interface>=<value> | 독립 실행형, 도메인 |
시스템 속성 |
--backup | 도메인 | 이 호스트가 도메인 컨트롤러가 아닌 경우에도 영구 도메인 구성의 사본을 보관합니다. |
-c=<config>, -c <config> | 독립 실행형 |
사용할 서버 구성 파일의 이름입니다. 기본값은 |
-c=<config>, -c <config> | 도메인 |
사용할 서버 구성 파일의 이름입니다. 기본값은 |
--cached-dc | 도메인 | 호스트가 도메인 컨트롤러가 아니며 부팅 시 도메인 컨트롤러에 연결할 수 없는 경우 도메인 구성의 로컬 캐시 사본을 사용하여 부팅합니다. |
--debug [<port>] | 독립 실행형 | 선택적 인수로 디버그 모드를 활성화하여 포트를 지정합니다. launch 스크립트에서 지원하는 경우에만 작동합니다. |
-D<name>[=<value>] | 독립 실행형, 도메인 | 시스템 속성 설정. |
--domain-config=<config> | 도메인 |
사용할 서버 구성 파일의 이름입니다. 기본값은 |
--git-repo | 독립 실행형 |
서버 구성 데이터를 관리하고 저장하는 데 사용되는 Git 리포지토리의 위치입니다. 로컬로 저장하거나 원격 리포지토리에 URL을 저장하려는 경우 |
--git-branch | 독립 실행형 | 사용할 Git 리포지토리의 분기 또는 태그 이름입니다. 이 인수는 기존 분기의 이름을 지정하거나 태그 이름이 없으면 생성되지 않으므로 이름을 지정해야 합니다. 태그 이름을 사용하는 경우 리포지토리를 분리된 HEAD 상태로 둡니다. 즉, 향후 커밋은 분기에 연결되지 않습니다. 태그 이름은 읽기 전용이며 일반적으로 여러 노드에 구성을 복제해야 하는 경우 사용됩니다. |
--git-auth | 독립 실행형 |
원격 Git 리포지토리에 연결할 때 사용할 자격 증명을 포함하는 Elytron 구성 파일의 URL입니다. 이 인수는 원격 Git 리포지토리에 인증이 필요한 경우 필요합니다. Elytron은 SSH를 지원하지 않습니다. 따라서 기본 SSH 인증만 암호 없이 개인 키를 사용하여 지원됩니다. 이 인수는 |
-h, --help | 독립 실행형, 도메인 | 도움말 메시지를 표시하고 종료합니다. |
--host-config=<config> | 도메인 |
사용할 호스트 구성 파일의 이름입니다. 기본값은 |
--interprocess-hc-address=<address> | 도메인 | 호스트 컨트롤러가 프로세스 컨트롤러에서 통신을 수신 대기해야 하는 주소입니다. |
--interprocess-hc-port=<port> | 도메인 | 호스트 컨트롤러가 프로세스 컨트롤러에서 통신을 수신 대기해야 하는 포트입니다. |
--master-address=<address> | 도메인 |
시스템 속성 |
--master-port=<port> | 도메인 |
시스템 속성 |
--read-only-server-config=<config> | 독립 실행형 |
사용할 서버 구성 파일의 이름입니다. 원본 파일이 덮어쓰지 않는다는 점에서 |
--read-only-domain-config=<config> | 도메인 |
사용할 도메인 구성 파일의 이름입니다. 초기 파일이 덮어쓰지 않는다는 점에서 |
--read-only-host-config=<config> | 도메인 |
사용할 호스트 구성 파일의 이름입니다. 초기 파일을 덮어쓰지 않는다는 점에서 |
-P=<url>, -P <url>, --properties=<url> | 독립 실행형, 도메인 | 지정된 URL에서 시스템 속성을 로드합니다. |
--pc-address=<address> | 도메인 | 프로세스 컨트롤러가 제어하는 프로세스에서 통신을 수신 대기하는 주소입니다. |
--pc-port=<port> | 도메인 | 프로세스 컨트롤러가 제어하는 프로세스에서 통신을 수신 대기하는 포트입니다. |
-S<name>[=<value>] | 독립 실행형 | 보안 속성을 설정합니다. |
-secmgr | 독립 실행형, 도메인 | 보안 관리자가 설치된 서버를 실행합니다. |
--server-config=<config> | 독립 실행형 |
사용할 서버 구성 파일의 이름입니다. 기본값은 |
--start-mode=<mode> | 독립 실행형 |
서버의 시작 모드를 설정합니다. 이 옵션은
|
-u=<value>, -u <value> | 독립 실행형, 도메인 |
구성 파일의 socket-binding 요소에서 멀티캐스트 주소를 구성하는 데 사용되는 시스템 속성 |
-v, -V, --version | 독립 실행형, 도메인 | 애플리케이션 서버 버전을 표시하고 종료합니다. |
JBoss EAP와 함께 제공되는 구성 파일은 스위치의 동작을 처리하도록 설정되어 있습니다(예: -b
및 -u
). 구성 파일을 변경해도 스위치에서 제어하는 시스템 속성을 더 이상 사용하지 않도록 하려면 launch 명령에 추가할 수 없습니다.
A.2. RPM 서비스 설정 파일
JBoss EAP의 RPM 설치에는 ZIP 또는 설치 프로그램 설치에 비해 두 개의 추가 구성 파일이 포함되어 있습니다. 이러한 파일은 서비스 init 스크립트에서 JBoss EAP 시작 환경을 지정하는 데 사용됩니다. 이러한 서비스 구성 파일의 위치는 Red Hat Enterprise Linux 6 및 Red Hat Enterprise Linux 7 이후 버전마다 다릅니다.
Red Hat Enterprise Linux 7 이상에서는 systemd
를 사용하여 RPM 서비스 구성 파일이 로드되므로 변수 표현식은 확장되지 않습니다.
표 A.2. Red Hat Enterprise Linux 6용 RPM 구성 파일
파일 | 설명 |
---|---|
/etc/sysconfig/eap7-standalone | Red Hat Enterprise Linux 6의 독립 실행형 JBoss EAP 서버와 관련된 설정. |
/etc/sysconfig/eap7-domain | Red Hat Enterprise Linux 6에서 관리형 도메인으로 실행되는 JBoss EAP와 관련된 설정. |
표 A.3. Red Hat Enterprise Linux 7 이상용 RPM 구성 파일
파일 | 설명 |
---|---|
/etc/opt/rh/eap7/wildfly/eap7-standalone.conf | Red Hat Enterprise Linux 7 이상에서 독립 실행형 JBoss EAP 서버에 특정한 설정. |
/etc/opt/rh/eap7/wildfly/eap7-domain.conf | Red Hat Enterprise Linux 7 이상에서 관리형 도메인으로 실행되는 JBoss EAP에 대한 설정. |
A.3. RPM 서비스 구성 속성
다음 표는 JBoss EAP RPM 서비스의 사용 가능한 구성 속성 목록을 기본값과 함께 보여줍니다.
속성의 이름이 RPM 서비스 구성 파일(예: /etc/sysconfig/eap7-standalone
)과 JBoss EAP 시작 구성 파일(예: EAP_HOME/bin/standalone.conf
)에서 같은 이름이 있는 경우 우선 순위가 JBoss EAP 시작 구성 파일의 값입니다. 이러한 속성 중 하나는 JAVA_HOME
입니다.
표 A.4. RPM 서비스 구성 속성
속성 | 설명 |
---|---|
JAVA_HOME | Java 런타임 환경이 설치된 디렉터리입니다.
기본값: |
JAVAPTH | Java 실행 파일이 설치된 경로입니다.
기본값: |
WILDFLY_STARTUP_WAIT | start 또는 restart 명령을 수신한 후 서버가 성공적으로 시작되었는지 확인할 때까지 init 스크립트가 대기하는 시간(초)입니다. 이 속성은 Red Hat Enterprise Linux 6에만 적용됩니다.
기본값: |
WILDFLY_SHUTDOWN_WAIT | init 스크립트에서 중지 또는 재시작 명령을 수신할 때 계속하기 전에 서버가 종료될 때까지 대기하는 시간(초)입니다. 이 속성은 Red Hat Enterprise Linux 6에만 적용됩니다.
기본값: |
WILDFLY_CONSOLE_LOG | CONSOLE 로그 핸들러가 로 리디렉션되는 파일입니다.
기본값: 독립 실행형 서버의 경우 |
WILDFLY_SH | JBoss EAP 서버에 시작하는 데 사용되는 스크립트입니다.
기본값: 독립 실행형 서버의 경우 |
WILDFLY_SERVER_CONFIG | 사용할 서버 구성 파일입니다.
이 속성에는 기본값이 없습니다. |
WILDFLY_HOST_CONFIG |
관리형 도메인의 경우 이 속성을 사용하면 host |
WILDFLY_MODULEPATH | JBoss EAP 모듈 디렉터리의 경로입니다.
기본값: |
WILDFLY_BIND |
공용 인터페이스에 대한 바인드 주소를 구성하는 데 사용되는 |
WILDFLY_OPTS | 시작 시 포함할 추가 인수입니다. 예를 들면 다음과 같습니다. -Dorg.wildfly.openssl.path=PATH_TO_OPENSSL_LIBS
|
A.4. JBoss EAP 하위 시스템 개요
아래 표는 JBoss EAP 하위 시스템에 대한 간략한 설명을 제공합니다.
표 A.5. JBoss EAP 하위 시스템
JBoss EAP 하위 시스템 | 설명 |
---|---|
batch-jberet | |
bean-validation | Java 오브젝트 데이터를 검증하기 위해 빈 유효성 검사를 구성합니다. |
core-management | 서버 라이프사이클 이벤트에 리스너를 등록하고 구성 변경 사항을 추적합니다. |
데이터 소스 | 데이터 소스를 생성 및 구성하고 JDBC 데이터베이스 드라이버를 관리합니다. |
deployment-scanner | 애플리케이션이 배포할 특정 위치를 모니터링하도록 배포 스캐너를 구성합니다. |
EE | 글로벌 모듈 정의, 설명자 기반 속성 교체 활성화 및 기본 바인딩 구성과 같은 자카르타 EE 플랫폼에서 공통 기능을 구성합니다. |
ejb3 | 세션 및 메시지 기반 빈을 포함한 Jakarta Enterprise Bean 구성.
|
Elytron | 서버 및 애플리케이션 보안 구성.
|
iiop-openjdk |
보안을 포함한 JTS 트랜잭션 및 기타 ORB 서비스에 대한 CORBA(Common Object Request Broker Architecture) 서비스를 구성합니다. JBoss EAP 6에서 이 기능은 |
Infinispan | JBoss EAP 고가용성 서비스를 위한 캐싱 기능 구성. |
io | |
jaxrs | Jakarta RESTful Web Services 애플리케이션의 배포 및 기능을 활성화합니다. |
JCA | Jakarta Connectors 컨테이너 및 리소스 어댑터 배포에 대한 일반 설정을 구성합니다. |
jdr | 문제 해결에 도움이 되도록 진단 데이터 수집을 활성화합니다. JBoss EAP 서브스크립션 사용자는 지원을 요청할 때 이 정보를 Red Hat에 제공할 수 있습니다. |
JGroups | 클러스터의 서버가 서로 통신하는 방법에 대한 프로토콜 스택 및 통신 메커니즘을 구성합니다. |
jmx | 원격 Jakarta 관리 액세스 구성. |
jpa | Jakarta Persistence 2.2 컨테이너 관리 요구 사항을 관리하고 영구 장치 정의, 주석 및 설명자를 배포할 수 있습니다.
|
jsf | Jakarta Server Faces 구현 관리. |
jsr77 | Jakarta Management 사양에 정의된 Jakarta EE 관리 기능을 제공합니다. |
로깅 | 로그 카테고리 및 로그 핸들러 의 시스템을 통해 시스템 및 애플리케이션 수준 로깅을 구성합니다. |
메일 | JBoss EAP에 배포된 애플리케이션이 해당 서비스를 사용하여 메일을 보낼 수 있도록 메일 서버 특성 및 사용자 지정 메일 전송을 구성합니다. |
messaging-activemq |
통합된 메시징 공급자인 Artemis에 대한 Jakarta Messaging 대상, 연결 팩토리 및 기타 설정을 구성합니다. JBoss EAP 6에서는 메시징 기능이
|
메트릭 |
관리 모델 및 JVM(Java Virtual Machine) MBean의 기본 지표를 표시합니다. JBoss EAP에는 더 이상 |
상태 |
JBoss EAP 런타임의 상태 점검을 노출합니다. JBoss EAP에는 더 이상 |
modcluster | 서버 측 mod_cluster 작업자 노드를 구성합니다. |
이름 지정 | 항목을 글로벌 JNDI 네임스페이스에 바인딩하고 원격 JNDI 인터페이스를 구성합니다. |
picketlink-federation | PicketLink SAML 기반 SSO(Single Sign-On) 구성.
picket |
picketlink-identity-management | PicketLink ID 관리 서비스를 구성합니다. 이 하위 시스템은 지원되지 않습니다. |
POJO | 이전 버전의 JBoss EAP에서 지원하는 JBoss Microcontainer 서비스를 포함하는 애플리케이션 배포를 활성화합니다. |
Remoting | 로컬 및 원격 서비스의 인바운드 및 아웃바운드 연결에 대한 설정을 구성합니다. |
discovery | 검색 하위 시스템은 현재 내부 하위 시스템에만 사용됩니다. 이는 프라이빗 API이며 공용 용도로 사용할 수 없습니다. |
request-controller | 서버를 정상적으로 일시 중단 및 종료 하도록 설정을 구성합니다. |
resource-adapters | Jakarta Connectors 사양을 사용하여 Jakarta EE 애플리케이션과 EIS(Enterprise Information System) 간의 통신을 위한 리소스 어댑터 를 구성하고 유지 관리합니다. |
RTS | REST-AT의 지원되지 않는 구현. |
SAR | 이전 버전의 JBoss EAP에서 지원하는 대로 MBean 서비스가 포함된 SAR 아카이브의 배포를 활성화합니다. |
보안 | 애플리케이션 보안 설정을 구성하는 레거시 방법.
|
security-manager | Java 보안 정책이 Java Security Manager에서 사용하도록 구성합니다.
|
Singleton | Singleton 정책을 정의하여 Singleton 배포 동작을 구성하거나 Singleton MSC 서비스를 생성합니다.
|
트랜잭션 | 시간 제한 값, 트랜잭션 로깅, JTS(Java Transaction Service) 사용 여부 등의 Transaction Manager(TM) 옵션을 구성합니다.
|
Undertow |
JBoss EAP의 웹 서버 및 서블릿 컨테이너 설정 구성. JBoss EAP 6에서는 이 기능이 |
webservices | 웹 서비스 프로바이더에 대한 호스트 이름, 포트 및 WSDL 주소를 비롯하여 게시된 엔드포인트 주소 및 엔드포인트 핸들러 체인을 구성합니다.
|
와일드 | JBoss EAP의 자카르타 컨텍스트 및 종속성 주입 기능을 구성합니다. |
XTS | 트랜잭션에서 웹 서비스를 조정하기 위한 설정을 구성합니다. |
A.5. add-User Utility 인수
다음 표에서는 즉시 사용 가능한 인증을 위해 새 사용자를 속성 파일에 추가하기 위한 유틸리티인
스크립트에 사용할 수 있는 인수를 설명합니다.
add-user.sh
또는 add-user.bat
표 A.6. add-User 명령 인수
명령줄 인수 | 설명 |
---|---|
-a | 애플리케이션 영역에 사용자를 생성합니다. 생략하면 기본값은 관리 영역에서 사용자를 생성하는 것입니다. |
-dc <value> |
속성 파일을 포함할 도메인 구성 디렉터리입니다. 생략된 경우 기본 디렉터리는 |
-sc <value> |
속성 파일을 포함할 대체 독립 실행형 서버 구성 디렉터리입니다. 생략하면 기본 디렉터리는 |
-up, --user-properties <value> |
대체 사용자 속성 파일의 이름입니다. 절대 경로이거나 대체 구성 디렉터리를 지정하는 |
-g, --group <value> | 이 사용자에게 할당할 쉼표로 구분된 그룹 목록입니다. |
-gp, --group-properties <value> |
대체 그룹 속성 파일의 이름입니다. 절대 경로이거나 대체 구성 디렉터리를 지정하는 |
-p, --password <value> | 사용자의 암호. |
-u, --user <value> | 사용자 이름. 사용자 이름에는 어떤 숫자와 순서에 관계없이 다음 문자만 사용할 수 있습니다.
|
-r, --realm <value> |
관리 인터페이스를 보호하는 데 사용되는 영역의 이름입니다. 생략하면 기본값은 |
-s, --silent |
콘솔에 대한 출력 없이 |
-e, --enable | 사용자를 활성화합니다. |
-d, --disable | 사용자를 비활성화합니다. |
-cw, --confirm-warning | 대화형 모드에서 경고를 자동으로 확인합니다. |
-h, --help |
|
-DS, --display-secret | 비대화형 모드로 시크릿 값을 출력합니다. |
A.6. 관리 감사 로깅 속성
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-config_5_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.7. 관리 감사 로깅: 로거 속성
속성 | 설명 |
---|---|
enabled | 감사 로깅을 활성화하는지 여부. |
log-boot | 서버 부팅 시 작업을 로깅해야 하는지 여부. |
log-read-only | 구성을 수정하지 않거나 런타임 서비스를 로깅해야 하는 작업입니다. |
표 A.8. 관리 감사 로깅: 로그 포맷터 속성
속성 | 설명 |
---|---|
압축 |
|
date-format |
|
date-separator |
포맷된 로그 메시지의 날짜와 나머지 간의 구분 기호입니다. |
escape-control-characters |
|
escape-new-line |
|
include-date | 포맷된 로그 레코드에 날짜를 포함할지 여부입니다. |
표 A.9. 관리 감사 로깅: 파일 핸들러 속성
속성 | 설명 |
---|---|
disabled-due-to-failure | 로깅 실패로 인해 이 핸들러가 비활성화되었는지(읽기 전용). |
fail-count | 핸들러가 초기화되었으므로 로깅 실패 수(읽기 전용). |
포맷터 | 로그 메시지를 포맷하는 데 사용되는 JSON 포맷터입니다. |
max-failure-count | 이 핸들러를 비활성화하기 전에 최대 로깅 실패 수입니다. |
경로 | 감사 로그 파일의 경로입니다. |
relative-to |
이전에 이름이 지정된 경로 또는 시스템에서 제공하는 표준 경로 중 하나의 이름. |
rotate-at-startup | 서버를 시작할 때 이전 로그 파일을 순환해야 하는지 여부입니다. |
표 A.10. 관리 감사 로깅: Syslog 핸들러 속성
속성 | 설명 |
---|---|
app-name | RFC-5424 의 섹션 6.2.5에 정의된 대로 syslog 레코드에 추가할 애플리케이션 이름입니다. 지정하지 않으면 기본적으로 제품 이름이 설정됩니다. |
disabled-due-to-failure | 로깅 실패로 인해 이 핸들러가 비활성화되었는지(읽기 전용). |
기능 | RFC-5424의 섹션 6.2.1 및 RFC -3164 의 섹션 4.1.1에 정의된 대로 syslog 로깅에 사용할 수 있는 기능입니다. |
fail-count | 핸들러가 초기화되었으므로 로깅 실패 수(읽기 전용). |
포맷터 | 로그 메시지를 포맷하는 데 사용되는 JSON 포맷터입니다. |
max-failure-count | 이 핸들러를 비활성화하기 전에 최대 로깅 실패 수입니다. |
최대 길이 |
헤더를 포함한 로그 메시지의 최대 길이를 로 지정할 수 있습니다. 정의되지 않은 경우 syslog-format이 |
프로토콜 |
syslog 핸들러에 사용할 프로토콜입니다. |
syslog-format |
syslog 형식: |
truncate |
헤더를 포함한 메시지가 바이트 단위의 길이가 |
syslog 서버는 구현에 따라 다르므로 모든 syslog 서버에 적용되는 설정은 아닙니다. 테스트는 rsyslog syslog 구현을 사용하여 수행되었습니다.
이 테이블에는 고급 속성만 나열되어 있습니다. 각 속성에는 구성 매개 변수가 있으며 일부 속성에는 하위 구성 매개 변수가 있습니다.
A.7. 인터페이스 속성
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-config_5_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.11. 인터페이스 속성 및 값
인터페이스 요소 | 설명 |
---|---|
Any | 인터페이스에 대한 선택 기준의 일부는 중첩된 기준 집합 중 하나 이상임을 나타내는 요소가 있어야 합니다. |
any-address |
이 인터페이스를 사용하는 소켓이 와일드카드 주소에 바인딩되어야 함을 나타내는 빈 요소. |
inet-address | IPv6 또는 IPv4의 IP 주소 점으로 10진수 표기법 또는 IP 주소로 해석할 수 있는 호스트 이름입니다. |
link-local-address | 인터페이스에 대한 선택 기준의 일부가 링크-로컬인지 여부를 나타내는 빈 요소. |
루프백 | 인터페이스에 대한 선택 기준의 일부가 루프백 인터페이스인지 여부를 나타내는 빈 요소. |
loopback-address | 시스템의 루프백 인터페이스에 실제로 구성되지 않을 수 있는 루프백 주소입니다. inet-address 유형과 다릅니다. 지정된 값은 IP 주소가 연결된 NIC를 찾을 수 없는 경우에도 사용됩니다. |
멀티 캐스트 | 인터페이스에 대한 선택 기준의 일부는 멀티 캐스트를 지원하는지 여부를 나타내는 빈 요소입니다. |
name | 인터페이스의 이름입니다. |
nic | 네트워크 인터페이스의 이름(예: eth0, eth1, lo). |
NIC 일치 | 시스템에서 사용 가능한 네트워크 인터페이스의 이름을 일치시켜 허용 가능한 인터페이스를 찾을 수 있는 정규식입니다. |
아니요 | 인터페이스에 대한 선택 기준의 일부가 중첩된 기준 집합을 충족하지 못함을 나타내는 요소. |
점대점 | 인터페이스에 대한 선택 기준의 일부가 점대점 인터페이스인지 여부를 나타내는 빈 요소. |
public-address | 인터페이스에 대한 선택 기준의 일부가 공개적으로 라우팅 가능한 주소가 있는지 여부를 나타내는 빈 요소. |
site-local-address | 인터페이스에 대한 선택 기준의 일부가 사이트-로컬인지 여부를 나타내는 빈 요소. |
subnet-match |
슬래시 표기법으로 작성된 네트워크 IP 주소 및 주소의 네트워크 접두사의 비트 수(예: |
up | 인터페이스에 대한 선택 기준의 일부는 현재 작동 중인지 여부를 나타내는 빈 요소입니다. |
가상 | 인터페이스 선택 기준의 일부는 가상 인터페이스인지 여부를 나타내는 빈 요소입니다. |
A.8. 소켓 바인딩 속성
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-config_5_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
다음 표에는 3가지 유형의 소켓 바인딩 각각에 대해 구성할 수 있는 특성이 표시되어 있습니다.
표 A.12. 인바운드 소켓 바인딩(소켓 바인딩
) 속성
속성 | 설명 |
---|---|
client-mappings | 이 소켓 바인딩에 대한 클라이언트 매핑을 지정합니다. 이 소켓에 연결하는 클라이언트는 원하는 아웃바운드 인터페이스와 일치하는 매핑에 지정된 대상 주소를 사용해야 합니다. 이를 통해 네트워크 주소 변환을 사용하거나 여러 네트워크 인터페이스에 바인딩하여 작동할 수 있는 고급 네트워크 토폴로지가 가능합니다. 각 매핑은 대상을 결정하는 데 사용되는 첫 번째로 성공한 일치 항목을 사용하여 선언된 순서로 평가해야 합니다. |
fixed-port | 숫자 오프셋이 소켓 그룹의 다른 소켓에 적용되는 경우에도 port 값이 고정된 상태로 유지되어야 하는지 여부. |
인터페이스 |
소켓을 바인딩해야 하는 인터페이스 또는 멀티캐스트 소켓의 경우 수신 대기해야 하는 인터페이스의 이름입니다. 선언된 인터페이스 중 하나여야 합니다. 정의되지 않은 경우 enclosing 소켓 바인딩 그룹의 |
multicast-address | 소켓에서 멀티캐스트 트래픽을 수신해야 하는 멀티캐스트 주소입니다. 지정되지 않은 경우 소켓은 멀티 캐스트를 수신하도록 구성되지 않습니다. |
멀티 캐스트 포트 |
소켓에서 멀티캐스트 트래픽을 수신해야 하는 포트입니다. |
name | 소켓의 이름입니다. 소켓 구성 정보에 액세스해야 하는 서비스는 이 이름을 사용하여 찾습니다. 이 속성은 필수입니다. |
port | 소켓을 바인딩해야 하는 포트의 수입니다. 서버가 port-offset을 적용하여 모든 포트 값을 늘리거나 줄이는 경우 이 값을 재정의할 수 있습니다. |
표 A.13. 원격 아웃바운드 소켓 바인딩 (remote-destination-outbound-socket-binding
) 속성
속성 | 설명 |
---|---|
fixed-source-port | 숫자 오프셋이 소켓 그룹의 다른 아웃바운드 소켓에 적용되는 경우에도 port 값이 고정된 상태로 유지되어야 하는지 여부. |
호스트 | 이 아웃바운드 소켓이 연결할 원격 대상의 호스트 이름 또는 IP 주소입니다. |
port | 아웃바운드 소켓이 연결해야 하는 원격 대상의 포트 번호입니다. |
source-interface | 아웃바운드 소켓의 소스 주소에 사용할 인터페이스의 이름입니다. |
source-port | 아웃바운드 소켓의 소스 포트로 사용할 포트 번호입니다. |
표 A.14. 로컬 아웃바운드 소켓 바인딩 (local-destination-outbound-socket-binding
) 속성
속성 | 설명 |
---|---|
fixed-source-port | 숫자 오프셋이 소켓 그룹의 다른 아웃바운드 소켓에 적용되는 경우에도 port 값이 고정된 상태로 유지되어야 하는지 여부. |
socket-binding-ref | 이 아웃바운드 소켓이 연결되는 포트를 결정하는 데 사용할 로컬 소켓 바인딩의 이름입니다. |
source-interface | 아웃바운드 소켓의 소스 주소에 사용할 인터페이스의 이름입니다. |
source-port | 아웃바운드 소켓의 소스 포트로 사용할 포트 번호입니다. |
A.9. 기본 소켓 바인딩
다음 표에는 각 소켓 바인딩 그룹의 기본 소켓 바인딩이 표시되어 있습니다.
표 A.15. standard-sockets
소켓 바인딩 | 포트 | 설명 |
---|---|---|
ajp | 8009 | Apache JServ 프로토콜. HTTP 클러스터링 및 로드 밸런싱에 사용됩니다. |
http | 8080 | 배포된 웹 애플리케이션의 기본 포트입니다. |
https | 8443 | 배포된 웹 애플리케이션과 클라이언트 간의 SSL 암호화 연결. |
management-http | 9990 | 관리 계층과의 HTTP 통신에 사용됩니다. |
management-https | 9993 | 관리 계층과의 HTTPS 통신에 사용됩니다. |
txn-recovery-environment | 4712 | 자카르타 트랜잭션 복구 관리자. |
txn-status-manager | 4713 | 자카르타 트랜잭션 / JTS 트랜잭션 관리자. |
표 A.16. Ha-sockets
소켓 바인딩 | 포트 | 멀티 캐스트 포트 | 설명 |
---|---|---|---|
ajp | 8009 | Apache JServ 프로토콜. HTTP 클러스터링 및 로드 밸런싱에 사용됩니다. | |
http | 8080 | 배포된 웹 애플리케이션의 기본 포트입니다. | |
https | 8443 | 배포된 웹 애플리케이션과 클라이언트 간의 SSL 암호화 연결. | |
jgroups-mping | 45700 | 멀티캐스트. HA 클러스터에서 초기 멤버십을 검색하는 데 사용됩니다. | |
jgroups-tcp | 7600 | TCP를 사용하는 HA 클러스터의 유니캐스트 피어 검색. | |
jgroups-udp | 55200 | 45688 | UDP를 사용한 HA 클러스터에서 멀티캐스트 피어 검색. |
management-http | 9990 | 관리 계층과의 HTTP 통신에 사용됩니다. | |
management-https | 9993 | 관리 계층과의 HTTPS 통신에 사용됩니다. | |
modcluster | 23364 | JBoss EAP와 HTTP 로드 밸런서 간의 통신을 위한 멀티캐스트 포트입니다. | |
txn-recovery-environment | 4712 | 자카르타 트랜잭션 복구 관리자. | |
txn-status-manager | 4713 | 자카르타 트랜잭션 / JTS 트랜잭션 관리자. |
표 A.17. 전체 소켓
소켓 바인딩 | 포트 | 설명 |
---|---|---|
ajp | 8009 | Apache JServ 프로토콜. HTTP 클러스터링 및 로드 밸런싱에 사용됩니다. |
http | 8080 | 배포된 웹 애플리케이션의 기본 포트입니다. |
https | 8443 | 배포된 웹 애플리케이션과 클라이언트 간의 SSL 암호화 연결. |
IIOP | 3528 | JTS 트랜잭션 및 기타 ORB 종속 서비스에 대한 CORBA 서비스. |
iiop-ssl | 3529 | SSL 암호화 CORBA 서비스. |
management-http | 9990 | 관리 계층과의 HTTP 통신에 사용됩니다. |
management-https | 9993 | 관리 계층과의 HTTPS 통신에 사용됩니다. |
txn-recovery-environment | 4712 | 자카르타 트랜잭션 복구 관리자. |
txn-status-manager | 4713 | 자카르타 트랜잭션 / JTS 트랜잭션 관리자. |
표 A.18. full-ha-sockets
이름 | 포트 | 멀티 캐스트 포트 | 설명 |
---|---|---|---|
ajp | 8009 | Apache JServ 프로토콜. HTTP 클러스터링 및 로드 밸런싱에 사용됩니다. | |
http | 8080 | 배포된 웹 애플리케이션의 기본 포트입니다. | |
https | 8443 | 배포된 웹 애플리케이션과 클라이언트 간의 SSL 암호화 연결. | |
IIOP | 3528 | JTS 트랜잭션 및 기타 ORB 종속 서비스에 대한 CORBA 서비스. | |
iiop-ssl | 3529 | SSL 암호화 CORBA 서비스. | |
jgroups-mping | 45700 | 멀티캐스트. HA 클러스터에서 초기 멤버십을 검색하는 데 사용됩니다. | |
jgroups-tcp | 7600 | TCP를 사용하는 HA 클러스터의 유니캐스트 피어 검색. | |
jgroups-udp | 55200 | 45688 | UDP를 사용한 HA 클러스터에서 멀티캐스트 피어 검색. |
management-http | 9990 | 관리 계층과의 HTTP 통신에 사용됩니다. | |
management-https | 9993 | 관리 계층과의 HTTPS 통신에 사용됩니다. | |
modcluster | 23364 | JBoss EAP와 HTTP 로드 밸런서 간의 통신을 위한 멀티캐스트 포트입니다. | |
txn-recovery-environment | 4712 | 자카르타 트랜잭션 복구 관리자. | |
txn-status-manager | 4713 | 자카르타 트랜잭션 / JTS 트랜잭션 관리자. |
표 A.19. load-balancer-sockets
이름 | 포트 | 멀티 캐스트 포트 | 설명 |
---|---|---|---|
http | 8080 | 배포된 웹 애플리케이션의 기본 포트입니다. | |
https | 8443 | 배포된 웹 애플리케이션과 클라이언트 간의 SSL 암호화 연결. | |
management-http | 9990 | 관리 계층과의 HTTP 통신에 사용됩니다. | |
management-https | 9993 | 관리 계층과의 HTTPS 통신에 사용됩니다. | |
mcmp-management | 8090 | 라이프사이클 이벤트를 전송하기 위한 MMCMP(Modro-Cluster Management Protocol) 연결 포트입니다. | |
modcluster | 23364 | JBoss EAP와 HTTP 로드 밸런서 간의 통신을 위한 멀티캐스트 포트입니다. |
A.10. 모듈 명령 인수
다음 인수를 모듈 추가
관리 CLI 명령에 전달할 수 있습니다.
표 A.20. 모듈 명령 인수
인수 | 설명 |
---|---|
--absolute-resources |
이 인수를 사용하여
구분자 세부 정보는 |
--allow-nonexistent-resources |
이 인수를 사용하여 존재하지 않는 |
--dependencies | 이 모듈이 종속된 쉼표로 구분된 모듈 이름 목록을 제공하려면 이 인수를 사용합니다. |
--export-dependencies | 내보낸 종속성을 지정하려면 이 인수를 사용합니다. module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --export-dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
|
--main-class | 이 인수를 사용하여 모듈의 기본 메서드를 선언하는 정규화된 클래스 이름을 지정합니다. |
--module-root-dir |
기본 EAP module add --module-root-dir=/path/to/my-external-modules/ --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api |
--module-xml |
이 인수를 사용하여 이 새 모듈에 사용할 |
--name | 이 인수를 사용하여 추가할 모듈 이름을 제공합니다. 이 인수는 필수입니다. |
--properties |
이 인수를 사용하여 모듈 속성을 정의하는 쉼표로 구분된 |
--resource-delimiter |
이 인수를 사용하여 |
--resources |
파일 시스템 경로 목록을 제공하여 이 모듈의 리소스를 지정하려면 이 인수를 사용합니다. 파일은 이 모듈 디렉터리에 복사되고 해당
구분자 세부 정보는 |
--slot |
이 인수를 사용하여 모듈을 기본 module add --name=com.mysql --slot=8.0 --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api
|
A.11. Deployment scanner Marker files
마커 파일은 배포 스캐너에서 JBoss EAP 서버 인스턴스의 배포 디렉터리 내에 애플리케이션 상태를 표시하는 데 사용됩니다. 마커 파일의 이름은 배포와 동일하며 파일 접미사는 애플리케이션 배포 상태를 나타냅니다.
예를 들어 test-application.war
를 성공적으로 배포하면 test-application.war.deployed
라는 마커 파일이 있습니다.
다음 테이블에는 사용 가능한 마커 파일 유형과 의미가 나열되어 있습니다.
표 A.21. 마커 파일 유형
파일 이름 접미사 | Origin | 설명 |
---|---|---|
.배포됨 | 시스템 생성 | 콘텐츠가 배포되었음을 나타냅니다. 이 파일이 삭제되면 콘텐츠가 배포 취소됩니다. |
.dodeploy | 사용자 생성 | 콘텐츠를 배포하거나 재배포해야 함을 나타냅니다. |
.failed | 시스템 생성 | 배포 실패를 나타냅니다. 마커 파일에는 오류 발생 원인에 대한 정보가 포함되어 있습니다. 마커 파일이 삭제되면 콘텐츠에 자동 배포 권한이 다시 부여됩니다. |
.isdeploying | 시스템 생성 | 배포가 진행 중임을 나타냅니다. 이 마커 파일은 완료 시 삭제됩니다. |
.isundeploying | 시스템 생성 |
|
.pending | 시스템 생성 | 배포 스캐너가 콘텐츠 배포의 필요성을 인식하지만, 현재 문제가 자동 배포(예: 콘텐츠가 복사 중인 프로세스에 있는 경우)를 방지하고 있음을 나타냅니다. 이 마커는 글로벌 배포 로드맵 블록 역할을 합니다. 즉, 스캐너에서 이 마커 파일이 있는 동안 서버에 콘텐츠를 배포하거나 배포 취소하도록 지시하지 않습니다. |
.skipdeploy | 사용자 생성 | 있는 동안 애플리케이션의 자동 배포를 비활성화합니다. 압축 해제된 콘텐츠의 자동 배포를 일시적으로 차단하여 불완전한 컨텐츠 편집의 위험을 방지하는 방법으로 유용합니다. 는 압축된 콘텐츠와 함께 사용할 수 있지만 스캐너는 진행 중인 변경 사항을 압축된 콘텐츠로 탐지하고 완료될 때까지 대기합니다. |
.배포되지 않음 | 시스템 생성 | 콘텐츠가 배포 취소되었음을 나타냅니다. 이 마커 파일을 삭제해도 콘텐츠 재배포에는 영향을 미치지 않습니다. |
A.12. 배포 스캐너 속성
배포 스캐너에는 다음과 같은 구성 가능한 특성이 포함되어 있습니다.
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/jboss-as-deployment-scanner_2_0.xsd
에 있는 스키마 정의 파일을 참조하십시오.
표 A.22. 배포 스캐너 속성
이름 | 기본 | 설명 |
---|---|---|
auto-deploy-exploded | false |
. |
auto-deploy-xml | true |
. |
자동 배포-zipped | true |
. |
deployment-timeout | 600 | 배포 스캐너가 취소되기 전에 배포를 시도할 수 있는 시간(초)입니다. |
경로 | Deployments |
스캔할 실제 파일 시스템 경로입니다. |
relative-to | jboss.server.base.dir | 서버 구성의 경로로 정의된 파일 시스템 경로에 대한 참조입니다. |
runtime-failure-causes-rollback | false | 배포의 런타임 실패로 인해 배포가 롤백되는지 여부와 검사 작업의 일부로 배포와 관련이 없는 모든 배포(관련이 아닐 수 있음)가 있는지 여부입니다. |
검사 사용 | true |
스캔 인터랙티브 및 시작 시 애플리케이션에 대한 |
scan-interval | 5000 |
변경 사항을 위해 리포지토리를 스캔해야 하는 시간 간격(밀리초)입니다. 값이 |
A.13. 관리형 도메인 JVM 구성 속성
호스트, 서버 그룹 또는 서버 수준에서 관리형 도메인에 대해 다음 JVM 구성 옵션을 설정할 수 있습니다. 이러한 속성 중 일부에 유효한 값은 JVM에 따라 다릅니다. 자세한 내용은 JDK 벤더 설명서를 참조하십시오.
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-config_5_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.23. JVM 구성 속성
속성 | 설명 |
---|---|
agent-lib |
Java 에이전트 라이브러리를 지정하는 |
agent-path |
Java 에이전트 경로를 지정하는 |
디버그 사용 | 디버그를 사용할지 여부입니다. 이 특성은 서버 수준에서 JVM 구성에만 적용됩니다. |
debug-options | 디버그가 활성화될 때 사용할 JVM 옵션을 지정합니다. 이 특성은 서버 수준에서 JVM 구성에만 적용됩니다. |
env-classpath-ignored |
|
environment-variables | 키/값 쌍 환경 변수를 지정합니다. |
힙 크기 |
JVM에서 할당한 초기 힙 크기를 지정하는 |
java-agent |
Java 에이전트를 지정하는 |
java-home |
|
jvm-options | 필요한 추가 JVM 옵션을 지정합니다. |
launch-command |
서버 프로세스를 시작하는 데 사용된 |
max-heap-size |
JVM에서 할당한 최대 힙 크기를 지정하는 |
max-permgen-size | Permanent Generation의 최대 크기를 설정합니다. 더 이상 사용되지 않음: JVM은 더 이상 별도의 영구 생성 공간을 제공하지 않습니다. |
PermGen-size | 초기 영구 생성 크기를 설정합니다. 더 이상 사용되지 않음: JVM은 더 이상 별도의 영구 생성 공간을 제공하지 않습니다. |
stack-size |
JVM 스택 크기를 지정하는 |
type |
사용 중인 JVM을 제공하는 공급업체를 지정합니다. 사용 가능한 옵션은 |
A.14. 메일 하위 시스템 속성
다음 표에서는 메일 세션의 메일
하위 시스템과 다음 메일 서버 유형의 속성을 설명합니다.
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-mail_3_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.24. 메일 세션 속성
속성 | 설명 |
---|---|
debug | 자카르타 메일 디버깅 활성화 여부. |
기점 | 보낼 때 설정하지 않은 경우 사용할 기본 "from" 주소입니다. |
jndi-name | 메일 세션을 바인딩해야 하는 JNDI 이름입니다. |
표 A.25. IMAP 메일 서버 속성
속성 | 설명 |
---|---|
인증 정보 참조 | 자격 증명 저장소에서 서버에 인증하기 위한 자격 증명. |
outbound-socket-binding-ref | 메일 서버의 아웃바운드 소켓 바인딩에 대한 참조입니다. |
암호 | 서버에서 인증할 암호입니다. |
ssl | 서버에 SSL이 필요한지 여부. |
tls | 서버에 TLS가 필요한지 여부. |
사용자 이름 | 서버에서 인증할 사용자 이름. |
표 A.26. POP3 메일 서버 속성
속성 | 설명 |
---|---|
인증 정보 참조 | 자격 증명 저장소에서 서버에 인증하기 위한 자격 증명. |
outbound-socket-binding-ref | 메일 서버의 아웃바운드 소켓 바인딩에 대한 참조입니다. |
암호 | 서버에서 인증할 암호입니다. |
ssl | 서버에 SSL이 필요한지 여부. |
tls | 서버에 TLS가 필요한지 여부. |
사용자 이름 | 서버에서 인증할 사용자 이름. |
표 A.27. SMTP 메일 서버 속성
속성 | 설명 |
---|---|
인증 정보 참조 | 자격 증명 저장소에서 서버에 인증하기 위한 자격 증명. |
outbound-socket-binding-ref | 메일 서버의 아웃바운드 소켓 바인딩에 대한 참조입니다. |
암호 | 서버에서 인증할 암호입니다. |
ssl | 서버에 SSL이 필요한지 여부. |
tls | 서버에 TLS가 필요한지 여부. |
사용자 이름 | 서버에서 인증할 사용자 이름. |
표 A.28. 사용자 지정 메일 서버 속성
속성 | 설명 |
---|---|
인증 정보 참조 | 자격 증명 저장소에서 서버에 인증하기 위한 자격 증명. |
outbound-socket-binding-ref | 메일 서버의 아웃바운드 소켓 바인딩에 대한 참조입니다. |
암호 | 서버에서 인증할 암호입니다. |
속성 | 이 서버의 Jakarta Mail 속성입니다. |
ssl | 서버에 SSL이 필요한지 여부. |
tls | 서버에 TLS가 필요한지 여부. |
사용자 이름 | 서버에서 인증할 사용자 이름. |
A.15. 루트 로거 속성
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/jboss-as-logging_3_0_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.29. 루트 로거 속성
속성 | 설명 |
---|---|
filter |
간단한 필터 유형을 정의합니다. |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 로그 항목을 제외하는 필터를 정의합니다. not(match("WFLY.*")). |
핸들러 | 루트 로거에서 사용하는 로그 핸들러 목록입니다. |
level | 루트 로거가 기록하는 가장 낮은 로그 메시지 수준입니다. |
루트 로거에 지정된 filter-spec
은 다른 핸들러에서 상속 하지 않습니다. 대신 핸들러별로 filter-spec
을 지정해야 합니다.
A.16. 로그 카테고리 속성
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/jboss-as-logging_6_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.30. 로그 카테고리 속성
속성 | 설명 |
---|---|
카테고리 | 로그 메시지가 캡처될 로그 범주입니다. |
filter |
간단한 필터 유형을 정의합니다. |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 필터를 정의합니다. not(match("WFLY.*")). |
핸들러 | 로거와 연결된 로그 핸들러 목록입니다. |
level | 로그 범주가 기록하는 가장 낮은 로그 메시지 수준입니다. |
use-parent-handlers |
|
A.17. 로그 핸들러 속성
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/jboss-as-logging_6_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.31. 콘솔 로그 핸들러 속성
속성 | 설명 |
---|---|
자동 플러시 |
|
enabled |
|
인코딩 | 출력에 사용할 문자 인코딩 체계입니다. |
filter |
간단한 필터 유형을 정의합니다. |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 필터를 정의합니다. not(match("WFLY.*")). |
포맷터 | 이 로그 핸들러에서 사용하는 로그 포맷터입니다. |
level | 로그 핸들러가 기록하는 가장 낮은 로그 메시지 수준입니다. |
name | 로그 핸들러의 이름입니다. 핸들러 주소에 이름이 포함되어 있으므로 더 이상 사용되지 않습니다. |
named-formatter | 핸들러에서 사용할 정의된 포맷터의 이름입니다. |
대상 | 로그 핸들러의 출력이 전송되는 시스템 출력 스트림입니다. 다음 중 하나일 수 있습니다.
|
표 A.32. 파일 로그 핸들러 속성
속성 | 설명 |
---|---|
추가 |
|
자동 플러시 |
|
enabled |
|
인코딩 | 출력에 사용할 문자 인코딩 체계입니다. |
file |
이 로그 핸들러의 출력이 작성된 파일을 나타내는 오브젝트입니다. 두 개의 구성 속성인 |
filter |
간단한 필터 유형을 정의합니다. |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 필터를 정의합니다. not(match("WFLY.*")). |
포맷터 | 이 로그 핸들러에서 사용하는 로그 포맷터입니다. |
level | 로그 핸들러가 기록하는 가장 낮은 로그 메시지 수준입니다. |
name | 로그 핸들러의 이름입니다. 핸들러 주소에 이름이 포함되어 있으므로 더 이상 사용되지 않습니다. |
named-formatter | 핸들러에서 사용할 정의된 포맷터의 이름입니다. |
표 A.33. 주기적인 로그 핸들러 속성
속성 | 설명 |
---|---|
추가 |
|
자동 플러시 |
|
enabled |
|
인코딩 | 출력에 사용할 문자 인코딩 체계입니다. |
file |
이 로그 핸들러의 출력이 기록되는 파일을 나타내는 오브젝트입니다. 두 개의 구성 속성인 |
filter |
간단한 필터 유형을 정의합니다. |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 필터를 정의합니다(not(match("WFLY.*")). |
포맷터 | 이 로그 핸들러에서 사용하는 로그 포맷터입니다. |
level | 로그 핸들러가 기록하는 가장 낮은 로그 메시지 수준입니다. |
name | 로그 핸들러의 이름입니다. 핸들러 주소에 이름이 포함되어 있으므로 더 이상 사용되지 않습니다. |
named-formatter | 핸들러에서 사용할 정의된 포맷터의 이름입니다. |
접미사 |
이 문자열은 순환된 로그에 추가되는 접미사에 포함됩니다. |
표 A.34. 크기 로그 핸들러 속성
속성 | 설명 |
---|---|
추가 |
|
자동 플러시 |
|
enabled |
|
인코딩 | 출력에 사용할 문자 인코딩 체계입니다. |
file |
이 로그 핸들러의 출력이 작성된 파일을 나타내는 오브젝트입니다. 두 개의 구성 속성인 |
filter |
간단한 필터 유형을 정의합니다. |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 필터를 정의합니다. not(match("WFLY.*")). |
포맷터 | 이 로그 핸들러에서 사용하는 로그 포맷터입니다. |
level | 로그 핸들러가 기록하는 가장 낮은 로그 메시지 수준입니다. |
max-backup-index |
보관되는 순환 로그의 최대 수입니다. 이 번호에 도달하면 가장 오래된 로그가 다시 사용됩니다. 기본값은
|
name | 로그 핸들러의 이름입니다. 핸들러 주소에 이름이 포함되어 있으므로 더 이상 사용되지 않습니다. |
named-formatter | 핸들러에서 사용할 정의된 포맷터의 이름입니다. |
rotate-on-boot |
|
rotate-size |
로그 파일이 순환되기 전에 도달할 수 있는 최대 크기입니다. 숫자에 추가된 단일 문자는 크기 단위를 나타냅니다. 바이트의 경우 |
접미사 |
이 문자열은 순환된 로그에 추가되는 접미사에 포함됩니다. |
표 A.35. 정기적인 크기 로그 핸들러 속성
속성 | 설명 |
---|---|
추가 |
|
자동 플러시 |
|
enabled |
|
인코딩 | 출력에 사용할 문자 인코딩 체계입니다. |
file |
이 로그 핸들러의 출력이 작성된 파일을 나타내는 오브젝트입니다. 두 개의 구성 속성인 |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 필터를 정의합니다. not(match("WFLY.*")). |
포맷터 | 이 로그 핸들러에서 사용하는 로그 포맷터입니다. |
level | 로그 핸들러가 기록하는 가장 낮은 로그 메시지 수준입니다. |
max-backup-index |
보관되는 순환 로그의 최대 수입니다. 이 번호에 도달하면 가장 오래된 로그가 다시 사용됩니다. 기본값은
|
name | 로그 핸들러의 이름입니다. 핸들러 주소에 이름이 포함되어 있으므로 더 이상 사용되지 않습니다. |
named-formatter | 핸들러에서 사용할 정의된 포맷터의 이름입니다. |
rotate-on-boot |
|
rotate-size |
로그 파일이 순환되기 전에 도달할 수 있는 최대 크기입니다. 숫자에 추가된 단일 문자는 크기 단위를 나타냅니다. 바이트의 경우 |
접미사 |
이 문자열은 순환된 로그에 추가되는 접미사에 포함됩니다. |
표 A.36. Syslog 핸들러 속성
속성 | 설명 |
---|---|
app-name |
RFC5424 형식으로 메시지를 포맷할 때 사용되는 앱 이름입니다. 기본적으로 앱 이름은 |
enabled |
|
기능 | RFC-5424 및 RFC-3164에 정의된 대로 기능입니다. |
호스트 이름 | 메시지가 전송되는 호스트의 이름입니다. 예를 들어 애플리케이션 서버가 실행 중인 호스트의 이름입니다. |
level | 로그 핸들러가 기록하는 가장 낮은 로그 메시지 수준입니다. |
port | syslog 서버가 수신 대기 중인 포트입니다. |
server-address | syslog 서버의 주소입니다. |
syslog-format | RFC 사양에 따라 로그 메시지를 포맷합니다. |
named-formatter | syslog 페이로드의 메시지를 포맷합니다. 이 특성을 사용하면 필요에 따라 메시지를 사용자 지정할 수 있습니다. |
표 A.37. 소켓 로그 핸들러 속성
속성 | 설명 |
---|---|
자동 플러시 | 각 쓰기 후에 자동으로 플러시할지 여부입니다. |
block-on-reconnect |
|
enabled |
|
인코딩 | 이 핸들러에서 사용하는 문자 인코딩 |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 필터를 정의합니다. not(match("WFLY.*")). |
level | 로그 핸들러가 기록하는 가장 낮은 로그 메시지 수준입니다. |
named-formatter | 핸들러에서 사용할 정의된 포맷터의 이름입니다. |
outbound-socket-binding-ref | 소켓 연결에 대한 아웃바운드 소켓 바인딩에 대한 참조입니다. |
프로토콜 |
소켓이 통신해야 하는 프로토콜입니다. 허용되는 값은 |
ssl-context |
정의된 SSL 컨텍스트에 대한 참조입니다. 이는 |
표 A.38. 사용자 정의 로그 핸들러 속성
속성 | 설명 |
---|---|
클래스 | 사용할 로깅 핸들러 클래스입니다. |
enabled |
|
인코딩 | 출력에 사용할 문자 인코딩 체계입니다. |
filter |
간단한 필터 유형을 정의합니다. |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 필터를 정의합니다. not(match("WFLY.*")). |
포맷터 | 이 로그 핸들러에서 사용하는 로그 포맷터입니다. |
level | 로그 핸들러가 기록하는 가장 낮은 로그 메시지 수준입니다. |
module | 로깅 핸들러가 종속된 모듈입니다. |
name | 로그 핸들러의 이름입니다. 핸들러 주소에 이름이 포함되어 있으므로 더 이상 사용되지 않습니다. |
named-formatter | 핸들러에서 사용할 정의된 포맷터의 이름입니다. |
속성 | 로깅 핸들러에 사용되는 속성입니다. |
표 A.39. 비동기 로그 핸들러 속성
속성 | 설명 |
---|---|
enabled |
|
filter |
간단한 필터 유형을 정의합니다. |
filter-spec |
필터를 정의하는 표현식 값입니다. 다음 표현식은 패턴과 일치하지 않는 필터를 정의합니다. not(match("WFLY.*")). |
level | 로그 핸들러가 기록하는 가장 낮은 로그 메시지 수준입니다. |
name | 로그 핸들러의 이름입니다. 핸들러 주소에 이름이 포함되어 있으므로 더 이상 사용되지 않습니다. |
overflow-action |
이 핸들러는 대기열 길이를 초과하면 응답하는 방법입니다. 이는 |
queue-length | 하위 핸들러가 응답할 때까지 기다리는 동안 이 핸들러가 보유하는 최대 로그 메시지 수입니다. |
하위 핸들러 | 이 비동기 핸들러가 로그 메시지를 전달하는 로그 핸들러 목록입니다. |
A.18. 로그 포맷터 속성
표 A.40. 패턴 포맷터의 형식 문자
기호 | 설명 |
---|---|
%c | 로깅 이벤트의 범주입니다. |
%p | 로그 항목의 수준(INFO(정보), DEBUG(디버그) 등). |
%P | 로그 항목의 로컬화된 수준입니다. |
%d |
현재 날짜/시간(y |
%r | 상대 시간(로그를 초기화한 이후 밀리초). |
%z |
날짜( |
%k | 로그 리소스 키(로그 메시지의 로컬화에 사용됩니다). |
%m | 로그 메시지(예외 추적 포함). |
%s | 간단한 로그 메시지(예외 추적 없음). |
%e | 예외 스택 추적(확장된 모듈 정보가 아님). |
%E | 예외 스택 추적(확장된 모듈 정보 포함). |
%t | 현재 스레드의 이름입니다. |
%n | 줄 바꿈 문자. |
%C | 로그 메서드(slow)를 호출하는 코드의 클래스입니다. |
%F | 로그 메서드(slow)를 호출하는 클래스의 파일 이름입니다. |
%l | 로그 메서드(slow)를 호출하는 코드의 소스 위치입니다. |
%L | 로그 메서드(slow)를 호출하는 코드의 행 번호입니다. |
%M | 로그 메서드(slow)를 호출하는 코드의 메서드입니다. |
%x | 중첩된 진단 컨텍스트. |
%X | 메시지 진단 컨텍스트. |
%% |
리터럴 백분율( %) |
표 A.41. JSON 로그 포맷터 속성
속성 | 설명 |
---|---|
date-format |
날짜-시간 형식 패턴입니다. 패턴은 유효한 |
exception-output-type | 는 로깅된 메시지의 원인(사용 가능한 경우)이 JSON 출력에 추가되는 방식을 나타냅니다. 허용되는 값은 다음과 같습니다.
|
key-overrides | JSON 속성의 키 이름을 재정의할 수 있습니다. |
meta-data | JSON 포맷터에서 사용할 메타데이터를 설정합니다. |
pretty-print | 포맷할 때 인쇄를 사용해야 하는지 여부. |
print-details | 상세 정보를 인쇄해야 하는지 여부입니다. 세부 정보에는 소스 클래스 이름, 소스 파일 이름, 소스 메서드 이름, 소스 모듈 이름, 소스 모듈 버전 및 소스 줄 번호가 포함됩니다. 참고 세부 정보 인쇄는 호출자에서 값을 검색하므로 비용이 많이 들 수 있습니다. |
record-delimiter | 레코드의 끝을 나타내는 데 사용되는 값입니다. null로 설정하면 레코드 끝에 사용할 수 없습니다. 기본값은 행 피드입니다. |
zone-id | 날짜와 시간을 포맷하기 위한 영역 ID입니다. 정의되지 않은 경우 시스템 기본값이 사용됩니다. |
표 A.42. XML 로그 포맷터 속성
속성 | 설명 |
---|---|
date-format |
날짜-시간 형식 패턴입니다. 패턴은 유효한 |
exception-output-type | 는 기록된 메시지의 원인(사용 가능한 경우)이 XML 출력에 추가되는 방식을 나타냅니다. 허용되는 값은 다음과 같습니다.
|
key-overrides | XML 속성의 키 이름을 재정의할 수 있습니다. |
meta-data | XML 형식으로 사용할 메타 데이터를 설정합니다. 속성은 각 로그 메시지에 추가됩니다. |
namespace-uri |
print-namespace 특성이 true인 경우 각 레코드에 사용되는 네임스페이스 URI를 설정합니다. namespace-uri가 정의되지 않고 재정의된 키가 있는 경우 |
pretty-print | 포맷할 때 인쇄를 사용해야 하는지 여부. |
print-details | 상세 정보를 인쇄해야 하는지 여부입니다. 세부 정보에는 소스 클래스 이름, 소스 파일 이름, 소스 메서드 이름, 소스 모듈 이름, 소스 모듈 버전 및 소스 줄 번호가 포함됩니다. 참고 세부 정보 인쇄는 호출자에서 값을 검색하므로 비용이 많이 들 수 있습니다. |
record-delimiter | 레코드의 끝을 나타내는 데 사용되는 값입니다. 이 값이 null이면 레코드 끝에 구분 기호가 사용되지 않습니다. 기본값은 행 피드입니다. |
zone-id | 날짜와 시간을 포맷하기 위한 영역 ID입니다. 정의되지 않은 경우 시스템 기본값이 사용됩니다. |
A.19. 데이터 소스 연결 URL
표 A.43. 데이터 소스 연결 URL
데이터 소스 | 연결 URL |
---|---|
IBM DB2 | jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME |
MariaDB | jdbc:mariadb://SERVER_NAME:PORT/DATABASE_NAME |
MariaDB Galera Cluster | jdbc:mariadb://SERVER_NAME:PORT,SERVER_NAME:PORT/DATABASE_NAME |
Microsoft SQL Server | jdbc:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME |
MySQL | jdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME |
Oracle | jdbc:oracle:thin:@SERVER_NAME:PORT:ORACLE_SID |
PostgreSQL | jdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME |
Sybase | jdbc:sybase:Tds:SERVER_NAME:PORT/DATABASE_NAME |
A.20. 데이터 소스 속성
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-datasources_5_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.44. 데이터 소스 속성
속성 | 데이터 소스 유형 | 설명 |
---|---|---|
allocation-retry | XA, XA가 아닌 |
예외를 발생하기 전에 연결을 할당해야 하는 횟수입니다. 기본값은 |
allocation-retry-wait-millis | XA, XA가 아닌 |
연결을 할당하기 위해 재시도할 때까지 대기하는 시간(밀리초)입니다. 기본값은 |
allow-multiple-users | XA, XA가 아닌 |
여러 사용자가 |
authentication-context | XA, XA가 아닌 |
풀의 연결을 구분하는 데 사용되는 |
background-validation | XA, XA가 아닌 |
를 사용하기 전에 백그라운드 스레드에서 커넥션의 유효성을 검사하는 것과 먼저 연결의 유효성을 검사할지 여부입니다. 백그라운드 유효성 검사는 일반적으로 |
background-validation-millis | XA, XA가 아닌 | 백그라운드 검증이 실행될 빈도(밀리초)입니다. |
blocking-timeout-wait-millis | XA, XA가 아닌 | 연결을 기다리는 동안 예외가 발생하기 전에 차단하는 최대 시간(밀리초)입니다. 이 명령은 연결 잠금을 기다리는 동안만 차단되며 새 연결을 생성하는 경우 예외가 발생하지 않습니다. |
capacity-decrementer-class | XA, XA가 아닌 | 풀에서 연결을 줄이기 위한 정책을 정의하는 클래스입니다. |
capacity-decrementer-properties | XA, XA가 아닌 | 풀의 연결을 줄이기 위한 정책을 정의하는 클래스에 삽입할 속성입니다. |
capacity-incrementer-class | XA, XA가 아닌 | 풀에서 연결을 늘리기 위한 정책을 정의하는 클래스. |
capacity-incrementer-properties | XA, XA가 아닌 | 풀 연결 증가 정책을 정의하는 클래스에 삽입할 속성입니다. |
check-valid-connection-sql | XA, XA가 아닌 | 풀 연결의 유효성을 확인하는 SQL 문입니다. 이 작업은 풀에서 관리되는 연결을 가져올 때 호출될 수 있습니다. |
연결 가능 | XA, XA가 아닌 | CMR 사용을 활성화합니다. 즉, 로컬 리소스가 XA 트랜잭션에 안정적으로 참여할 수 있습니다. |
connection-listener-class | XA, XA가 아닌 |
|
connection-listener-property | XA, XA가 아닌 |
|
연결 속성 | 비 XA 만 |
|
connection-url | 비 XA 만 | JDBC 드라이버 연결 URL입니다. |
인증 정보 참조 | XA, XA가 아닌 | 자격 증명 저장소에서 데이터 소스 인증에 대한 자격 증명. |
datasource-class | 비 XA 만 | JDBC 데이터 소스 클래스의 정규화된 이름입니다. |
driver-class | 비 XA 만 | JDBC 드라이버 클래스의 정규화된 이름입니다. |
driver-name | XA, XA가 아닌 | 데이터 소스에서 사용해야 하는 JDBC 드라이버를 정의합니다. 설치된 드라이버의 이름과 일치하는 심볼릭 이름입니다. 드라이버가 JAR로 배포되면 이름은 배포의 이름입니다. |
Elytron 지원 | XA, XA가 아닌 |
연결 인증을 처리하기 위한 Elytron 보안을 활성화합니다. 컨텍스트가 지정되지 않은 경우 사용할 Elytron |
enabled | XA, XA가 아닌 | 데이터 소스를 활성화해야 하는지 여부. |
enlistment-trace | XA, XA가 아닌 |
등록 추적을 기록해야 하는지 여부. 이는 기본적으로 |
exception-sorter-class-name | XA, XA가 아닌 |
예외가 오류를 브로드캐스트해야 하는지 여부를 검증하는 방법을 제공하는 |
exception-sorter-properties | XA, XA가 아닌 | 예외 분류기 속성. |
flush-strategy | XA, XA가 아닌 | 오류가 발생하는 경우 풀을 플러시하는 방법을 지정합니다. 유효한 값은 다음과 같습니다.
|
idle-timeout-minutes | XA, XA가 아닌 |
최대 시간(분)은 닫기 전에 연결이 유휴 상태가 될 수 있습니다. 지정하지 않으면 기본값은 |
initial-pool-size | XA, XA가 아닌 | 풀에서 보유해야 하는 초기 연결 수입니다. |
인터리빙 | XA만 | XA 연결에 대해 인터리빙을 사용할지 여부입니다. |
jndi-name | XA, XA가 아닌 | 데이터 소스의 고유 JNDI 이름입니다. |
jta | 비 XA 만 | 자카르타 트랜잭션 통합 활성화. |
max-pool-size | XA, XA가 아닌 | 풀에서 보유할 수 있는 최대 연결 수입니다. |
mcp | XA, XA가 아닌 |
|
min-pool-size | XA, XA가 아닌 | 풀에서 보유할 수 있는 최소 연결 수입니다. |
new-connection-sql | XA, XA가 아닌 | 커넥션 풀에 연결을 추가할 때마다 실행할 SQL 문입니다. |
복구 없음 | XA만 | 연결 풀을 복구에서 제외해야 하는지 여부입니다. |
no-tx-separate-pool | XA만 |
각 컨텍스트에 대해 별도의 하위 풀을 생성할지 여부입니다. 이는 XA 연결을 자카르타 트랜잭션 내부 및 외부에서 사용할 수 없는 일부 Oracle 데이터 소스에 필요할 수 있습니다. 이 옵션을 사용하면 실제 풀 두 개가 생성되므로 총 풀 크기가 |
pad-xid | XA만 | Xid를 채울지 여부입니다. |
암호 | XA, XA가 아닌 | 새 연결을 만들 때 사용할 암호입니다. |
Pool-fair | XA, XA가 아닌 |
풀이 공정해야 하는지를 정의합니다. 이 설정은 자카르타 커넥터에서 연결 풀을 관리하는 데 사용되는 Semapotre |
pool-prefill | XA, XA가 아닌 | 풀을 미리 입력해야 하는지 여부입니다. |
pool-use-strict-min | XA, XA가 아닌 |
|
prepared-statements-cache-size | XA, XA가 아닌 | LRU(Least Recently Used) 캐시에서 연결당 준비된 문 수입니다. |
query-timeout | XA, XA가 아닌 | 쿼리의 시간 제한(초)입니다. 기본값은 시간 초과가 아닙니다. |
reauth-plugin-class-name | XA, XA가 아닌 | 물리적 연결을 다시 인증하기 위한 인증 플러그인 구현의 정규화된 클래스 이름입니다. |
reauth-plugin-properties | XA, XA가 아닌 | 인증 플러그인의 속성입니다. |
recovery-authentication-context | XA만 |
풀의 연결을 구분하는 데 사용되는 |
recovery-credential-reference | XA만 | 자격 증명 저장소에서 데이터 소스 인증에 대한 자격 증명. |
복구-elytron 지원 | XA만 |
복구를 위한 연결 인증을 처리하기 위해 Elytron 보안을 활성화합니다. 인증 컨텍스트가 지정되지 않은 경우 사용되는 Elytron |
recovery-password | XA만 | 복구를 위해 리소스에 연결하는 데 사용할 암호입니다. |
recovery-plugin-class-name | XA만 | 복구 플러그인 구현의 정규화된 클래스 이름입니다. |
recovery-plugin-properties | XA만 | recovery 플러그인의 속성입니다. |
recovery-security-domain | XA만 | 복구를 위해 리소스에 연결하는 데 사용할 보안 도메인입니다. |
recovery-username | XA만 | 복구를 위해 리소스에 연결하는 데 사용할 사용자 이름입니다. |
same-rm-override | XA만 |
|
security-domain | XA, XA가 아닌 | 인증을 처리하는 JAAS security-manager의 이름입니다. 이 이름은 JAAS 로그인 구성의 application-policy/name 속성과 상호 연관됩니다. |
set-tx-query-timeout | XA, XA가 아닌 | 트랜잭션 시간 초과까지 남은 시간에 따라 쿼리 시간 초과를 설정할지 여부입니다. 트랜잭션이 없는 경우 구성된 쿼리 시간 초과가 사용됩니다. |
share-prepared-statements | XA, XA가 아닌 |
JBoss EAP가 캐시해야 하는지 여부에 따라 애플리케이션에 제공된 래퍼가 애플리케이션 코드에 의해 종료될 때 기본 실제 문이 닫힙니다. 기본값은 |
spy | XA, XA가 아닌 |
JDBC 계층에서 래퍼 기능을 활성화합니다. 모든 JDBC 트래픽을 데이터 소스에 기록합니다. 로깅 카테고리 |
stale-connection-checker-class-name | XA, XA가 아닌 |
isStaleConnection |
stale-connection-checker-properties | XA, XA가 아닌 | 오래된 연결 검사기 속성입니다. |
통계 지원 | XA, XA가 아닌 |
런타임 통계 활성화 여부. 기본값은 |
track-statements | XA, XA가 아닌 | 연결이 풀에 반환될 때 닫히지 않은 문을 확인할지 여부가 준비된 문 캐시로 반환됩니다. false인 경우 문이 추적되지 않습니다. 유효한 값은 다음과 같습니다.
|
추적 | XA, XA가 아닌 | 커넥션이 트랜잭션 경계에서 처리할지 여부입니다. |
transaction-isolation | XA, XA가 아닌 |
|
url-delimiter | XA, XA가 아닌 | HA(고가용성) 데이터 소스용 connection-url의 URL 구분 기호입니다. |
URL-property | XA만 |
|
url-selector-strategy-class-name | XA, XA가 아닌 |
|
use-ccm | XA, XA가 아닌 | 캐시된 연결 관리자를 활성화합니다. |
use-fast-fail | XA, XA가 아닌 | true인 경우 연결이 유효하지 않은 경우 첫 번째 시도의 연결 할당에 실패합니다. false인 경우 풀이 고갈될 때까지 계속 시도하십시오. |
use-java-context | XA, XA가 아닌 | 데이터 소스를 글로벌 JNDI에 바인딩할지 여부입니다. |
use-try-lock | XA, XA가 아닌 |
내부 잠금의 시간 제한 값입니다. 이렇게 하면 잠금을 사용할 수 없는 경우 즉시 실패하지 않고 시간 초과 전에 구성된 시간(초) 동안 잠금을 확보하려고 합니다. |
user-name | XA, XA가 아닌 | 새 연결을 만들 때 사용할 사용자 이름입니다. |
valid-connection-checker-class-name | XA, XA가 아닌 |
연결을 검증하기 위한 |
valid-connection-checker-properties | XA, XA가 아닌 | 유효한 연결 검사기 속성입니다. |
validate-on-match | XA, XA가 아닌 |
연결 팩토리가 관리되는 연결과 일치하려고 할 때 연결 유효성 검사가 수행되는지 여부. 클라이언트가 사용하기 전에 연결 유효성을 검사해야 하는 경우 이 값을 사용해야 합니다. 보통 validate-on-match는 |
wrap-xa-resource | XA만 |
XAResource를 |
xa-datasource-class | XA만 |
|
xa-datasource-properties | XA만 | XA 데이터 소스 속성의 문자열 이름/값 쌍입니다. |
xa-resource-timeout | XA만 |
0이 아닌 경우 이 값은 |
표 A.45. JDBC 드라이버 속성
속성 | 데이터 소스 유형 | 설명 |
---|---|---|
datasource-class-info | XA, XA가 아닌 |
the |
A.21. 데이터 소스 통계
표 A.46. 코어 풀 통계
이름 | 설명 |
---|---|
ActiveCount | 활성 연결 수입니다. 각 연결은 애플리케이션에서 사용하거나 풀에서 사용할 수 있습니다. |
AvailableCount | 풀에서 사용 가능한 연결 수입니다. |
AverageBlockingTime | 풀에서 독점적인 잠금을 얻는 데 차단하는 데 사용된 평균 시간입니다. 이 값은 밀리초 단위입니다. |
AverageCreationTime | 연결 생성에 사용된 평균 시간입니다. 이 값은 밀리초 단위입니다. |
AverageGetTime | 커넥션을 가져오는 데 사용된 평균 시간입니다. 이 값은 밀리초 단위입니다. |
AveragePoolTime | 풀에서 연결에 소비한 평균 시간입니다. 이 값은 밀리초 단위입니다. |
AverageUsageTime | 연결을 사용하여 사용된 평균 시간입니다. 이 값은 밀리초 단위입니다. |
BlockingFailureCount | 연결을 얻기 위해 시도하는 실패 수입니다. |
CreatedCount | 생성된 연결 수입니다. |
DestroyedCount | 삭제된 연결 수입니다. |
IdleCount | 현재 유휴 상태인 연결 수입니다. |
InUseCount | 현재 사용 중인 연결 수입니다. |
MaxCreationTime | 연결을 만드는 데 걸리는 최대 시간입니다. 이 값은 밀리초 단위입니다. |
MaxGetTime | 연결을 얻을 수 있는 최대 시간입니다. 이 값은 밀리초 단위입니다. |
MaxPoolTime | 풀에서 연결의 최대 시간. 이 값은 밀리초 단위입니다. |
MaxUsageTime | 연결을 사용하는 최대 시간. 이 값은 밀리초 단위입니다. |
MaxUsedCount | 사용된 최대 연결 수입니다. |
MaxWaitCount | 동시에 연결 대기 중인 최대 요청 수입니다. |
MaxWaitTime | 풀에서 독점적인 잠금을 기다리는 데 사용된 최대 시간입니다. 이 값은 밀리초 단위입니다. |
TimedOut | 시간 초과된 연결 수입니다. |
TotalBlockingTime | 풀의 배타적 잠금을 기다리는 데 사용된 총 시간입니다. 이 값은 밀리초 단위입니다. |
TotalCreationTime | 커넥션을 만드는 데 사용된 총 시간입니다. 이 값은 밀리초 단위입니다. |
TotalGetTime | 커넥션을 가져오는 데 사용된 총 시간입니다. 이 값은 밀리초 단위입니다. |
TotalPoolTime | 풀의 연결에 사용되는 총 시간입니다. 이 값은 밀리초 단위입니다. |
TotalUsageTime | 연결을 사용하여 사용된 총 시간입니다. 이 값은 밀리초 단위입니다. |
WaitCount | 연결을 얻기 위해 기다려야 하는 요청 수입니다. |
XACommitAverageTime | XAResource 커밋 호출의 평균 시간입니다. 이 값은 밀리초 단위입니다. |
XACommitCount | XAResource 커밋 호출 수입니다. |
XACommitMaxTime | XAResource 커밋 호출의 최대 시간입니다. 이 값은 밀리초 단위입니다. |
XACommitTotalTime | 모든 XAResource 커밋 호출의 총 시간입니다. 이 값은 밀리초 단위입니다. |
XAEndAverageTime | XAResource 종료 호출의 평균 시간입니다. 이 값은 밀리초 단위입니다. |
XAEndCount | XAResource 종료 호출 수입니다. |
XAEndMaxTime | XAResource 종료 호출의 최대 시간입니다. 이 값은 밀리초 단위입니다. |
XAEndTotalTime | 모든 XAResource 종료 호출의 총 시간입니다. 이 값은 밀리초 단위입니다. |
XAForgetAverageTime | 평균 XAResource의 시간은 호출을 잊습니다. 이 값은 밀리초 단위입니다. |
XAForgetCount | XAResource 수는 호출을 잊습니다. |
XAForgetMaxTime | XAResource의 최대 시간은 호출을 잊습니다. 이 값은 밀리초 단위입니다. |
XAForgetTotalTime | 모든 XAResource의 총 시간은 호출을 잊습니다. 이 값은 밀리초 단위입니다. |
XAPrepareAverageTime | XAResource 준비 호출의 평균 시간입니다. 이 값은 밀리초 단위입니다. |
XAPrepareCount | XAResource prepare 호출 수입니다. |
XAPrepareMaxTime | XAResource prepare 호출의 최대 시간입니다. 이 값은 밀리초 단위입니다. |
XAPrepareTotalTime | 모든 XAResource 준비 호출의 총 시간입니다. 이 값은 밀리초 단위입니다. |
XARecoverAverageTime | XAResource 복구 호출의 평균 시간입니다. 이 값은 밀리초 단위입니다. |
XARecoverCount | XAResource 복구 호출 수입니다. |
XARecoverMaxTime | XAResource 복구 호출의 최대 시간입니다. 이 값은 밀리초 단위입니다. |
XARecoverTotalTime | 모든 XAResource의 총 시간은 호출을 복구합니다. 이 값은 밀리초 단위입니다. |
XARollbackAverageTime | XAResource 롤백 호출의 평균 시간입니다. 이 값은 밀리초 단위입니다. |
XARollbackCount | XAResource 롤백 호출 수입니다. |
XARollbackMaxTime | XAResource 롤백 호출의 최대 시간입니다. 이 값은 밀리초 단위입니다. |
XARollbackTotalTime | 모든 XAResource 롤백 호출의 총 시간입니다. 이 값은 밀리초 단위입니다. |
XAStartAverageTime | XAResource 시작 호출의 평균 시간입니다. 이 값은 밀리초 단위입니다. |
XAStartCount | XAResource 시작 호출 수입니다. |
XAStartMaxTime | XAResource start 호출의 최대 시간입니다. 이 값은 밀리초 단위입니다. |
XAStartTotalTime | 모든 XAResource start 호출의 총 시간입니다. 이 값은 밀리초 단위입니다. |
표 A.47. JDBC 통계
이름 | 설명 |
---|---|
PreparedStatementCacheAccessCount | 문 캐시에 액세스한 횟수입니다. |
PreparedStatementCacheAddCount | 문 캐시에 추가된 문 수입니다. |
PreparedStatementCacheCurrentSize | 현재 문 캐시에 캐시된 준비 및 호출 가능한 문 수입니다. |
PreparedStatementCacheDeleteCount | 캐시에서 삭제된 문 수입니다. |
PreparedStatementCacheHitCount | 캐시에서 해당 문을 사용한 횟수입니다. |
PreparedStatementCacheMissCount | 문 요청이 캐시의 문으로 충족할 수 없는 횟수입니다. |
A.22. A stressal 데이터 소스 속성
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-agroal_1_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.48. A stressal 데이터 소스 속성
속성 | 설명 |
---|---|
연결 가능 | 이 데이터 소스에서 CMR(Commit Markable Resource) 기능을 사용할지 여부입니다. 이는 비 XA 데이터 소스에만 적용됩니다. |
jndi-name | 데이터 소스의 JNDI 이름을 지정합니다. |
jta | 자카르타 트랜잭션 통합 가능 여부. 이는 비 XA 데이터 소스에만 적용됩니다. |
통계 지원 |
이 데이터 소스에 대한 통계 활성화 여부. 기본값은 |
표 A.49. 원격 데이터 소스 연결 팩토리 속성
속성 | 설명 |
---|---|
authentication-context |
|
연결 속성 | 연결을 생성할 때 JDBC 드라이버에 전달할 속성입니다. |
인증 정보 참조 | 자격 증명 저장소에서 인증하기 위한 자격 증명. |
드라이버 | JDBC 드라이버에 대한 고유한 참조입니다. |
new-connection-sql | 생성 후 연결에서 실행할 SQL 문입니다. |
암호 | 데이터베이스에서 기본 인증에 사용할 암호입니다. |
transaction-isolation |
사용할 |
url | JDBC 드라이버 연결 URL입니다. |
사용자 이름 | 데이터베이스에서 기본 인증에 사용할 사용자 이름입니다. |
표 A.50. 원격 데이터 소스 연결 풀 속성
속성 | 설명 |
---|---|
background-validation | 백그라운드 유효성 검사 간 시간(밀리초)입니다. |
blocking-timeout | 연결을 기다리는 동안 예외가 발생하기 전에 차단하는 최대 시간(밀리초)입니다. |
idle-removal | 연결을 제거할 수 있기 전에 연결이 유휴 상태여야 하는 시간(분)입니다. |
initial-size | 풀에서 보유해야 하는 초기 연결 수입니다. |
누수 감지 | 누수 경고 전에 연결을 유지해야 하는 시간(밀리초)입니다. |
최대 크기 | 풀의 최대 연결 수입니다. |
min-size | 풀에서 보유해야 하는 최소 연결 수입니다. |
A.23. 트랜잭션 관리자 구성 옵션
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-txn_5_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.51. 트랜잭션 하위 시스템 속성
속성 | 설명 |
---|---|
default-timeout |
기본 트랜잭션 시간 제한입니다. 기본값은 |
enable-statistics |
|
enable-tsm-status |
프로세스 외부 복구에 사용되는 트랜잭션 상태 관리자(TSM) 서비스 사용 여부. 메모리가 아닌 다른 프로세스에서 |
hornetq-store-enable-async-io |
|
jdbc-action-store-drop-table |
JDBC 작업 저장소가 테이블을 삭제해야 하는지 여부. 기본값은 |
jdbc-action-store-table-prefix | 구성된 JDBC 작업 저장소에서 트랜잭션 로그를 작성하는 데 사용되는 테이블에 대한 선택적 접두사입니다. |
jdbc-communication-store-drop-table |
JDBC 통신 저장소가 테이블을 삭제해야 하는지 여부. 기본값은 |
jdbc-communication-store-table-prefix | 구성된 JDBC 통신 저장소에서 트랜잭션 로그를 작성하는 데 사용되는 테이블에 대한 선택적 접두사입니다. |
jdbc-state-store-drop-table |
JDBC 상태 저장소가 테이블을 삭제해야 하는지 여부. 기본값은 |
jdbc-state-store-table-prefix | 구성된 JDBC 상태 저장소에서 트랜잭션 로그를 작성하는 데 사용되는 테이블에 대한 선택적 접두사입니다. |
jdbc-store-datasource |
사용되는 비 XA 데이터 소스의 JNDI 이름입니다. 데이터 소스는 데이터 |
journal-store-enable-async-io |
저널 저장소에 대해 |
JTS |
JTS(Java Transaction Service) 트랜잭션 사용 여부. Jakarta 트랜잭션만 사용하는 기본값은 |
maximum-timeout |
트랜잭션에 무제한 시간 초과를 의미하는 트랜잭션 시간 초과가 |
node-identifier | 트랜잭션 관리자의 노드 식별자입니다. 이 옵션을 설정하지 않으면 서버를 시작할 때 경고가 표시됩니다. 이 옵션은 다음과 같은 상황에서 필요합니다.
노드 ID는 복구 중에 데이터 무결성을 적용하는 데 필요하므로 각 트랜잭션 관리자마다 고유해야 합니다. 또한 노드 ID는 여러 노드가 동일한 리소스 관리자와 상호 작용하거나 트랜잭션 개체 저장소를 공유하므로 자카르타 트랜잭션에서 고유해야 합니다. |
object-store-path |
트랜잭션 관리자 오브젝트 저장소가 데이터를 저장하는 상대적 파일 시스템 경로입니다. 기본적으로 |
object-store-relative-to |
도메인 모델의 글로벌 경로 구성을 참조합니다. 기본값은 |
process-id-socket-binding |
트랜잭션 관리자가 소켓 기반 프로세스 ID를 사용해야 하는 경우 사용할 소켓 바인딩 구성의 이름입니다. |
process-id-socket-max-ports | 트랜잭션 관리자는 각 트랜잭션 로그의 고유 식별자를 생성합니다. 고유한 식별자를 생성하기 위한 두 가지 메커니즘, 즉, 프로세스 식별자를 기반으로 하는 소켓 기반 메커니즘과 메커니즘이 제공됩니다.
소켓 기반 식별자의 경우 소켓이 열리고 해당 포트 번호는 식별자에 사용됩니다. 포트가 이미 사용 중인 경우 사용 가능한 포트가 표시될 때까지 다음 포트가 검색됩니다. process-id-socket-max-ports는 트랜잭션 관리자가 실패하기 전에 시도할 최대 소켓 수를 나타냅니다. 기본값은 |
process-id-uuid |
프로세스 식별자를 사용하여 각 트랜잭션의 고유 식별자를 생성하려면 |
recovery-listener |
트랜잭션 복구 프로세스가 네트워크 소켓에서 수신 대기해야 하는지 여부. 기본값은 |
socket-binding |
recovery |
통계 지원 |
통계를 활성화해야 하는지 여부. 기본값은 |
status-socket-binding | 트랜잭션 상태 관리자에 사용할 소켓 바인딩을 지정합니다. 이 구성 옵션은 지원되지 않습니다. |
use-hornetq-store |
|
use-jdbc-store |
JDBC 저장소를 사용하여 트랜잭션 로그를 작성합니다. 기본 로그 저장소 유형을 사용하려면 및 를 |
use-journal-store |
트랜잭션 로그에 파일 기반 스토리지 대신 Apache ActiveMQ Artemis 저널링 스토리지 메커니즘을 사용합니다. 이 설정은 기본적으로 비활성화되어 있지만 I/O 성능을 향상시킬 수 있습니다. 별도의 트랜잭션 관리자에서는 JTS 트랜잭션에는 권장되지 않습니다. 이 옵션을 변경할 때 |
표 A.52. 로그 저장소 속성
속성 | 설명 |
---|---|
expose-all-logs |
모든 로그를 공개할지 여부입니다. 기본값은 |
type |
로깅 저장소의 구현 유형을 지정합니다. 기본값은 |
표 A.53. 커밋 표시 가능 리소스 속성
속성 | 설명 |
---|---|
batch-size |
이 CMR 리소스의 배치 크기입니다. 기본값은 |
immediate-cleanup |
이 CMR 리소스에 대해 즉시 정리를 수행할지 여부입니다. 기본값은 |
jndi-name | 이 CMR 리소스의 JNDI 이름입니다. |
name |
XID를 저장할 테이블 이름입니다. 기본값은 |
A.24. IIOP 하위 시스템 속성
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-iiop-openjdk_3_0.xsd
에 있는 스키마 정의 파일을 참조하십시오.
표 A.54. IIOP 하위 시스템 속성
속성 | 설명 |
---|---|
add-component-via-interceptor | IOR 인터셉터에서 SSL 구성 요소를 추가해야 하는지를 나타냅니다. 더 이상 사용되지 않음. |
auth-method |
인증 방법. 유효한 값은 |
authentication-context |
보안 초기화자가 |
caller-propagation |
호출자 ID를 SAS 컨텍스트에 전파해야 하는지를 나타냅니다. 유효한 값은 |
client-requires |
클라이언트 SSL 필수 매개 변수를 나타내는 값입니다. 유효한 값은 |
client-requires-ssl | 서버의 IIOP 연결에 SSL이 필요한지 여부를 나타냅니다. |
client-ssl-context | 클라이언트 측 SSL 소켓을 만드는 데 사용되는 SSL 컨텍스트의 이름입니다. |
클라이언트 지원 |
클라이언트 SSL 지원 매개 변수를 나타내는 값입니다. 유효한 값은 |
기밀성 |
전송에 기밀성 보호가 필요한지 여부를 나타냅니다. 유효한 값은 |
detect-misordering |
전송 시 잘못된 순서 탐지가 필요한지 여부를 나타냅니다. 유효한 값은 |
detect-replay |
전송에 재생 탐지가 필요한지 여부를 나타냅니다. 유효한 값은 |
export-corbaloc |
루트 컨텍스트를 |
giop-version | 사용할 GIOP 버전입니다. |
high-water-mark |
TCP 연결 캐시 매개 변수. 연결 수가 이 값을 초과할 때마다 ORB는 연결을 회수하려고 합니다. 회수된 연결 수는 |
무결성 |
전송 시 무결성 보호가 필요한지 여부를 나타냅니다. 유효한 값은 |
회수 수 |
TCP 연결 캐시 매개 변수. 연결 수가 |
persistent-server-id | 서버의 영구 ID입니다. 영구 개체 참조는 서버의 여러 활성화에서 유효하며 이 속성을 사용하여 식별합니다. 그 결과 동일한 서버의 활성화가 많은 경우 이 속성이 동일한 값으로 설정되어야 하며, 동일한 호스트에서 실행 중인 다른 서버 인스턴스에는 다른 서버 ID가 있어야 합니다. |
속성 | 일반 키/값 속성 목록입니다. |
영역 | 인증 서비스 영역 이름입니다. |
필수 항목 | 인증이 필요한지 여부를 나타냅니다. |
root-context | 네이밍 서비스 루트 컨텍스트. |
보안 |
보안 인터셉터를 설치할지 여부를 나타냅니다. 유효한 값은 |
security-domain | SSL 연결을 설정하는 데 사용할 키 저장소 및 신뢰 저장소를 보유한 보안 도메인의 이름입니다. |
server-requires |
서버 SSL 필수 매개 변수를 나타내는 값입니다. 유효한 값은 |
server-requires-ssl | 서버에 대한 IIOP 연결에 SSL이 필요한지 여부를 나타냅니다. |
server-ssl-context | 서버 측 SSL 소켓을 만드는 데 사용되는 SSL 컨텍스트의 이름입니다. |
서버 지원 |
서버 SSL 지원 매개 변수를 나타내는 값입니다. 유효한 값은 |
socket-binding | 소켓 바인딩 구성의 이름입니다. ORB 포트를 지정합니다. |
ssl-socket-binding | ORB SSL 포트를 지정하는 소켓 바인딩 구성의 이름입니다. |
지원-ssl | SSL이 지원되는지 여부를 나타냅니다. |
트랜잭션 |
트랜잭션 인터셉터를 설치할지 여부를 나타냅니다. 유효한 값은 |
trust-in-client |
전송을 클라이언트에서 신뢰해야 하는지를 나타냅니다. 유효한 값은 |
trust-in-target |
전송 시 대상을 신뢰해야 하는지를 나타냅니다. 유효한 값은 |
A.25. 리소스 어댑터 속성
다음 표에는 리소스 어댑터 특성이 설명되어 있습니다.
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-resource-adapters_5_0.xsd
에 있는 스키마 정의 파일을 참조하십시오.
표 A.55. 기본 속성
속성 | 설명 |
---|---|
아카이브 | 리소스 어댑터 아카이브. |
beanvalidationgroups | 사용해야 하는 빈 유효성 검사 그룹입니다. |
bootstrap-context | 사용해야 하는 부트스트랩 컨텍스트의 고유 이름입니다. |
config-properties | 사용자 지정 정의된 구성 속성입니다. |
module | 리소스 어댑터가 로드될 모듈입니다. |
통계 지원 | 런타임 통계가 활성화되었는지 여부. |
transaction-support |
리소스 어댑터의 트랜잭션 지원 수준입니다. 유효한 값은 |
wm-elytron-security-domain | 사용해야 하는 Elytron 보안 도메인의 이름을 정의합니다. |
wm-security |
이 리소스 어댑터에 대해 |
wm-security-default-groups |
사용된 |
wm-security-default-principal |
사용된 주체 인스턴스에 추가해야 하는 기본 |
wm-security-domain | 사용해야 하는 보안 도메인의 이름입니다. |
wm-security-mapping-groups | 그룹 매핑 목록입니다. |
wm-security-mapping-required | 보안 자격 증명에 매핑이 필요한지 여부를 정의합니다. |
wm-security-mapping-users | 사용자 매핑 목록. |
리소스 어댑터가 elytron
를 사용하는 경우 보안 도메인 사양에 대해 -enabled가
contexttrue
로 설정된 작업 관리자와 함께 bootstrap-wm-elytron-security-domain
특성 대신 wm-elytron-security-domain
속성을 사용해야 합니다.
표 A.56. admin-objects 속성
속성 | 설명 |
---|---|
class-name | 관리 오브젝트의 정규화된 클래스 이름입니다. |
enabled | 관리 오브젝트를 활성화해야 하는지를 지정합니다. |
jndi-name | 관리 개체의 JNDI 이름입니다. |
use-java-context | 이 값을 false로 설정하면 오브젝트를 전역 JNDI에 바인딩합니다. |
표 A.57. connection-definitions 속성
속성 | 설명 |
---|---|
allocation-retry | 예외를 발생하기 전에 연결을 할당해야 하는 횟수를 나타냅니다. |
allocation-retry-wait-millis | 연결을 할당하기 위해 재시도할 때까지 대기하는 시간(밀리초)입니다. |
authentication-context |
풀의 연결을 구분하는 데 사용되는 |
authentication-context-and-application |
|
background-validation | 사용 전에 유효성을 검사하는 것과 비교하여 백그라운드 스레드에서 커넥션의 유효성을 검사해야 함을 지정합니다. 이 값을 변경하려면 서버를 다시 시작해야 합니다. |
background-validation-millis | 백그라운드 검증이 실행될 시간(밀리초)입니다. 이 값을 변경하려면 서버를 다시 시작해야 합니다. |
blocking-timeout-wait-millis | 연결을 기다리는 동안 예외가 발생하기 전에 차단하는 최대 시간(밀리초)입니다. 이 명령은 연결 잠금을 기다리는 동안만 차단되며 새 연결을 생성하는 경우 예외가 발생하지 않습니다. |
capacity-decrementer-class | 풀에서 연결을 줄이기 위한 정책을 정의하는 클래스입니다. |
capacity-decrementer-properties | 풀에서 연결을 줄이기 위한 정책을 정의하는 클래스에 삽입할 속성입니다. |
capacity-incrementer-class | 풀에서 연결을 늘리기 위한 정책을 정의하는 클래스. |
capacity-incrementer-properties | 풀 연결을 늘리기 위한 정책을 정의하는 클래스에 삽입할 속성입니다. |
class-name | 관리되는 연결 팩토리 또는 admin 오브젝트의 정규화된 클래스 이름입니다. |
연결 가능 | CMR 사용을 활성화합니다. 이 기능은 로컬 리소스가 XA 트랜잭션에 안정적으로 참여할 수 있음을 의미합니다. |
Elytron 지원 |
연결 인증을 처리하기 위한 Elytron 보안을 활성화합니다. |
enabled | 리소스 어댑터를 활성화해야 하는지를 지정합니다. |
등록 | 리소스 어댑터에서 지원하는 경우 지연 엔리스트를 사용할지 여부를 지정합니다. |
enlistment-trace |
JBoss EAP/IronJacamar에서 등록 추적을 기록해야 하는지를 지정합니다. 이는 기본적으로 |
flush-strategy | 오류가 발생하는 경우 풀을 플러시하는 방법을 지정합니다. 유효한 값은 다음과 같습니다.
|
idle-timeout-minutes |
최대 시간(분)은 닫기 전에 연결이 유휴 상태가 될 수 있습니다. 실제 최대 시간은 모든 풀에서 가장 작은 |
initial-pool-size | 풀에서 보유해야 하는 초기 연결 수입니다. |
인터리빙 | XA 연결에 대해 인터리빙을 활성화할지 여부를 지정합니다. |
jndi-name | 연결 팩토리의 JNDI 이름입니다. |
max-pool-size | 풀의 최대 연결 수입니다. 각 하위 풀에 더 이상 연결이 생성되지 않습니다. |
mcp |
|
min-pool-size | 풀에 대한 최소 연결 수입니다. |
복구 없음 | 연결 풀을 복구에서 제외해야 하는지를 지정합니다. |
no-tx-separate-pool | Oracle은 자카르타 트랜잭션 내부와 외부 모두에서 XA 커넥션이 사용되는 것을 선호하지 않습니다. 문제를 해결하려면 다양한 컨텍스트에 대해 별도의 하위 풀을 생성할 수 있습니다. |
pad-xid | Xid를 채워야 하는지 여부를 지정합니다. |
Pool-fair | 풀 사용이 공정해야 하는지를 지정합니다. |
pool-prefill | 풀을 미리 채워야 하는지를 지정합니다. 이 값을 변경하려면 서버를 다시 시작해야 합니다. |
pool-use-strict-min |
|
recovery-authentication-context |
복구에 사용되는 Elytron 인증 컨텍스트입니다. |
recovery-credential-reference | 자격 증명 저장소에서 연결 복구 시 인증할 수 있는 자격 증명입니다. |
복구-elytron 지원 |
복구에 Elytron 인증 컨텍스트가 사용됨을 나타냅니다. 기본값은 |
recovery-password | 복구에 사용되는 암호입니다. |
recovery-plugin-class-name | 복구 플러그인 구현의 정규화된 클래스 이름입니다. |
recovery-plugin-properties | recovery 플러그인의 속성입니다. |
recovery-security-domain | 복구에 사용되는 보안 도메인. |
recovery-username | 복구에 사용되는 사용자 이름입니다. |
same-rm-override |
|
security-application |
|
security-domain |
풀에서 연결을 구분하는 데 사용되는 |
security-domain-and-application |
애플리케이션 제공 매개 변수(예: |
sharable | sharable 연결을 활성화하여 지원되는 경우 지연 연관을 활성화할 수 있습니다. |
추적 | railJacamar가 커넥션 처리를 트랜잭션 경계에서 추적해야 하는지를 지정합니다. |
use-ccm | 캐시된 연결 관리자 사용을 활성화합니다. |
use-fast-fail |
|
use-java-context |
이 값을 |
validate-on-match | 연결 팩토리가 관리되는 연결과 일치하려고 할 때 연결 유효성 검사를 수행해야 하는지를 지정합니다. 일반적으로 백그라운드 검증을 사용하지 않습니다. |
wrap-xa-resource |
|
xa-resource-timeout |
값은 |
A.26. 리소스 어댑터 통계
표 A.58. 리소스 어댑터 통계
이름 | 설명 |
---|---|
ActiveCount | 활성 연결 수입니다. 각 연결은 애플리케이션에서 사용하거나 풀에서 사용할 수 있습니다. |
AvailableCount | 풀에서 사용 가능한 연결 수입니다. |
AverageBlockingTime | 풀에서 독점적인 잠금을 얻는 데 차단하는 데 사용된 평균 시간입니다. 값은 밀리초 단위입니다. |
AverageCreationTime | 연결 생성에 사용된 평균 시간입니다. 값은 밀리초 단위입니다. |
CreatedCount | 생성된 연결 수입니다. |
DestroyedCount | 삭제된 연결 수입니다. |
InUseCount | 현재 사용 중인 연결 수입니다. |
MaxCreationTime | 연결을 만드는 데 걸리는 최대 시간입니다. 값은 밀리초 단위입니다. |
MaxUsedCount | 사용된 최대 연결 수입니다. |
MaxWaitCount | 동시에 연결 대기 중인 최대 요청 수입니다. |
MaxWaitTime | 풀에서 독점적인 잠금을 기다리는 데 사용된 최대 시간입니다. |
TimedOut | 시간 초과된 연결 수입니다. |
TotalBlockingTime | 풀의 배타적 잠금을 기다리는 데 사용된 총 시간입니다. 값은 밀리초 단위입니다. |
TotalCreationTime | 커넥션을 만드는 데 사용된 총 시간입니다. 값은 밀리초 단위입니다. |
WaitCount | 연결을 대기해야 하는 요청 수입니다. |
A.27. Undertow 하위 시스템 속성
undertow
하위 시스템의 다양한 요소의 특성은 아래 표를 참조하십시오.
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-undertow_4_0.xsd
에 있는 스키마 정의 파일을 참조하십시오.
표 A.59. 기본 undertow 속성
속성 | Default | 설명 |
---|---|---|
default-security-domain | 기타 | 웹 배포에서 사용하는 기본 보안 도메인입니다. |
default-server | default-server | 배포에 사용할 기본 서버입니다. |
default-servlet-container | default | 배포에 사용할 기본 서블릿 컨테이너입니다. |
default-virtual-host | default-host | 배포에 사용할 기본 가상 호스트입니다. |
instance-id | ${jboss.node.name} | 클러스터 인스턴스 ID입니다. |
obfuscate-session-route | true | 서버 라우팅 중에 instance-id 값이 난독 처리되었는지 여부입니다. instance-id 값이 변경되지 않는 한 난독 처리 서버 경로는 서버를 재시작해도 변경되지 않습니다. |
통계 지원 | false | 통계 활성화 여부. |
애플리케이션 보안 도메인 속성
애플리케이션 보안 도메인 속성에는 다음과 같은 구조가 있습니다.
application-security-domain 속성
표 A.60. application-security-domain 속성
속성 | Default | 설명 |
---|---|---|
enable-jacc | false | Jakarta Authorization을 사용하여 권한 부여를 활성화합니다. |
enable-jaspi | true | 관련 배포에 대해 자카르타 인증을 활성화합니다. |
http-authentication-factory | 매핑된 보안 도메인을 참조하는 배포에서 사용할 HTTP 인증 팩토리입니다. | |
integrated-jaspi | true |
|
override-deployment-config | false | 배포의 인증 구성을 팩토리에서 재정의해야 하는지 여부입니다. |
referencing-deployments | 현재 이 매핑을 참조하는 배포입니다. | |
security-domain |
배포에서 사용할 |
SSO(Single-Sign-On) 속성
표 A.61. SSO(Single-Sign-On) 속성
속성 | Default | 설명 |
---|---|---|
client-ssl-context | 백엔드 로그 아웃 연결을 보호하는 데 사용되는 SSL 컨텍스트에 대한 참조입니다. | |
redhat-name | JSESSIONIDSSO | 쿠키 이름입니다. |
인증 정보 참조 | 개인 키 항목의 암호를 해독하는 자격 증명 참조입니다. | |
domain | 사용할 쿠키 도메인입니다. | |
http-only | false | 쿠키 httpOnly 속성 설정. |
key-alias | 백엔드 로그 아웃 연결에 서명하고 확인하는 데 사용되는 개인 키 항목의 별칭입니다. | |
key-store | 개인 키 항목이 포함된 키 저장소에 대한 참조입니다. | |
경로 | / | 경로. |
보안 | false | 쿠키 보안 속성 설정. |
버퍼 캐시 속성
표 A.62. buffer-cache 속성
속성 | Default | 설명 |
---|---|---|
buffer-size | 1024 | 버퍼의 크기입니다. 작은 버퍼를 사용하면 공간을 더 효율적으로 사용할 수 있습니다. |
영역별 buffers-pergion | 1024 | 영역당 버퍼 수입니다. |
Max-regions | 10 | 최대 지역 수입니다. 캐싱에 사용할 수 있는 최대 메모리 양을 제어합니다. |
바이트 버퍼 풀 속성
표 A.63. 바이트 버퍼-풀 속성
속성 | Default | 설명 |
---|---|---|
buffer-size | 각 버퍼 슬라이스의 크기(바이트)입니다. 지정하지 않으면 시스템의 사용 가능한 RAM에 따라 크기가 설정됩니다.
이 속성에 대한 성능 튜닝은 JBoss EAP 성능 튜닝 가이드에서 버퍼 풀 구성을 참조하십시오. | |
직접 | 이 버퍼가 직접 또는 힙 풀인지 여부를 나타내는 부울 값입니다. 지정하지 않으면 시스템의 사용 가능한 RAM에 따라 값이 설정됩니다.
직접 풀에는 해당 힙 풀도 있습니다. | |
leak-detection-percent | 0 | 누수기로 할당해야 하는 버퍼의 백분율입니다. |
max-pool-size | 풀에 보관할 최대 버퍼 수입니다. 이 제한보다 버퍼는 계속 할당되지만 풀이 가득 차면 유지되지 않습니다. | |
thread-local-cache-size | 12 | 스레드당 캐시의 크기입니다. 이 크기는 최대 크기이며 캐시는 스마트 크기 조정을 사용하여 스레드에 실제로 버퍼를 할당하는 경우에만 버퍼를 유지합니다. |
서블릿 컨테이너 속성
서블릿 컨테이너 구성 요소에는 다음과 같은 구조가 있습니다.
servlet-container 속성
표 A.64. servlet-container 속성
속성 | Default | 설명 |
---|---|---|
allow-non-standard-wrappers | false | 표준 래퍼 클래스를 확장하지 않는 요청 및 응답 래퍼를 사용할 수 있습니다. |
default-buffer-cache | default | 정적 리소스를 캐싱하는 데 사용할 버퍼 캐시입니다. |
default-cookie-version | 0 | 애플리케이션에서 생성한 쿠키에 사용할 기본 쿠키 버전입니다. |
default-encoding | 배포된 모든 애플리케이션에 사용할 기본 인코딩입니다. | |
default-session-timeout | 30 | 컨테이너에 배포된 모든 애플리케이션의 기본 세션 시간 초과(분)입니다. |
directory-listing | 디렉토리 목록을 기본 서블릿에 활성화해야 하는 경우. | |
disable-caching-for-secured-pages | true | 보안 paged에 대한 캐싱을 비활성화할 헤더를 설정할지 여부입니다. 중요한 페이지는 중간자가 캐시할 수 있으므로 이 설정을 비활성화하면 보안 문제가 발생할 수 있습니다. |
disable-file-watch-service | false |
|
disable-session-id-reuse | false |
|
eager-filter-initialization | false | 처음 요청할 때보다 배포 시작 시 init()를 호출할지 여부입니다. |
ignore-flush | false | 서블릿 출력 스트림에서 플러시를 무시합니다. 대부분의 경우 이는 바람직한 이유 없이 성능을 저하시킵니다. |
최대 세션 | 한 번에 활성화할 수 있는 최대 세션 수입니다. | |
사전 인증 | true |
사전 예방적 인증을 사용해야 하는지 여부. |
session-id-length | 30 | 세션 ID가 길수록 더 안전합니다. 이 값은 생성된 세션 ID의 길이를 바이트로 지정합니다. 시스템은 생성된 세션 ID를 Base64 문자열로 인코딩하고 세션 ID 쿠키로 클라이언트에 결과를 제공합니다. 이 처리의 결과로 서버는 클라이언트에 원래 생성된 세션 ID보다 약 33% 더 큰 쿠키 값을 보냅니다. 예를 들어 세션 ID 길이가 30이면 쿠키 값이 40이 됩니다. |
stack-trace-on-error | 로컬 전용 |
스택 추적이 있는 오류 페이지가 오류 시 생성해야 하는 경우. 값은 |
use-listener-encoding | false | 리스너에 정의된 인코딩을 사용합니다. |
MIME-mapping 속성
표 A.65. MIME-mapping 속성
속성 | Default | 설명 |
---|---|---|
value | 이 매핑의 mime 유형입니다. |
crawler-session-management 속성
설정되어 있는 특수 세션 처리 구성.
관리 CLI를 사용하여 visitorer -session-management
요소를 관리하는 경우 servlet-container
요소의 설정에서
사용할 수 있습니다. 예를 들면 다음과 같습니다.
/subsystem=undertow/servlet-container=default/setting=crawler-session-management:add /subsystem=undertow/servlet-container=default/setting=crawler-session-management:read-resource
표 A.66. crawler-session-management 속성
속성 | Default | 설명 |
---|---|---|
session-timeout | 스니커가 소유한 세션의 세션 시간 초과(초)입니다. | |
user-agents | 고급 사용자의 사용자 에이전트와 일치하는 데 사용되는 정규식입니다. |
JSP 속성
관리 CLI를 사용하여 jsp
요소를 관리하는 경우 servlet-container
요소의 설정에서
사용할 수 있습니다. 예를 들면 다음과 같습니다.
/subsystem=undertow/servlet-container=default/setting=jsp:read-resource
표 A.67. JSP 속성
속성 | Default | 설명 |
---|---|---|
check-interval | 0 | 자카르타 서버 페이지의 확인 간격이 배경 스레드를 사용하여 업데이트됩니다. 이는 파일 시스템 알림 API를 사용하여 Jakarta Server Pages 변경 알림을 처리하는 대부분의 배포에 적용되지 않습니다. 이는 파일 감시 서비스가 비활성화된 경우에만 적용됩니다. |
개발 | false | Jakarta Server Pages를 즉시 다시 로드할 수 있는 개발 모드를 활성화합니다. |
비활성화됨 | false | 자카르타 서버 페이지 컨테이너를 활성화합니다. |
display-source-fragment | true | 런타임 오류가 발생하면 해당 Jakarta Server Pages 소스 내용을 표시합니다. |
dump-smap | false | 파일에 SMAP 데이터 쓰기. |
error-on-use-bean-invalid-class-attribute | false | useBean에서 잘못된 클래스를 사용할 때 오류를 활성화합니다. |
generate-strings-as-char-arrays | false | 문자 배열로 문자열 상수 생성. |
java-encoding | UTF8 | Java 소스에 사용된 인코딩을 지정합니다. |
keep-generated | true | 생성된 서블릿을 유지합니다. |
mapped-file | true | 자카르타 서버 페이지 소스에 매핑. |
modification-test-interval | 4 | 업데이트에 대한 두 테스트 사이의 최소 시간(초)입니다. |
optimize-scriptlets | false | Jakarta Server Pages 스크립틀릿을 최적화하여 문자열 연결을 제거해야 하는 경우. |
recompile-on-fail | false | 각 요청에 실패한 자카르타 서버 페이지 컴파일을 재시도했습니다. |
scratch-dir | 다른 작업 디렉터리를 지정합니다. | |
SMAP | true | SMAP 활성화. |
source-vm | 1.8 | 컴파일을 위한 소스 VM 수준. |
태그 풀링 | true | 태그 풀링을 활성화합니다. |
target-vm | 1.8 | 컴파일을 위한 목표 VM 수준. |
trim-spaces | false | 생성된 서블릿에서 일부 공백을 줄입니다. |
x-powered-by | true | X-powered-by에서 자카르타 서버 페이지 엔진의 광고 활성화. |
persistent-sessions 속성
관리 CLI를 사용하여 persistent-sessions
요소를 관리하는 경우 servlet-container
요소의 설정에서
사용할 수 있습니다. 예를 들면 다음과 같습니다.
/subsystem=undertow/servlet-container=default/setting=persistent-sessions:add /subsystem=undertow/servlet-container=default/setting=persistent-sessions:read-resource
표 A.68. persistent-sessions 속성
속성 | Default | 설명 |
---|---|---|
경로 | 영구 세션 데이터 디렉터리의 경로입니다. 이 값이 null이면 세션이 메모리에 저장됩니다. | |
relative-to | 경로가 상대적인 디렉터리입니다. |
session-cookie 속성
관리 CLI를 사용하여 session-cookie
요소를 관리할 때 servlet-container
요소의 설정에서
사용할 수 있습니다. 예를 들면 다음과 같습니다.
/subsystem=undertow/servlet-container=default/setting=session-cookie:add /subsystem=undertow/servlet-container=default/setting=session-cookie:read-resource
표 A.69. session-cookie 속성
속성 | Default | 설명 |
---|---|---|
설명 | 코멘트. | |
domain | 투르크 도메인. | |
http-only | 쿠키가 http-only인지 여부. | |
최대 크기 | 쿠키의 최대 사용 기간. | |
name | 쿠키 이름입니다. | |
보안 | 쿠키의 안전 여부. |
WebSockets 속성
관리 CLI를 사용하여 websockets
요소를 관리하는 경우 servlet-container
요소의 설정에서
사용할 수 있습니다. 예를 들면 다음과 같습니다.
/subsystem=undertow/servlet-container=default/setting=websockets:read-resource
표 A.70. WebSockets 속성
속성 | Default | 설명 |
---|---|---|
buffer-pool | default | 웹 소켓 배포에 사용할 버퍼 풀입니다. |
deflater 수준 | 0 | DEFLATE 알고리즘의 압축 수준을 구성합니다. |
dispatch-to-worker | true |
콜백을 작업자 스레드로 디스패치해야 하는지 여부입니다. |
per-message-deflate | false | 웹 소켓의 메시지별 압축 확장을 활성화합니다. |
worker | default | 웹 소켓 배포에 사용할 작업자입니다. |
welcome-file 속성
시작 파일을 정의하고 옵션이 없습니다.
속성 필터링
이러한 구성 요소는 /subsystem=undertow/configuration=filter
에서 찾을 수 있습니다.
custom-filter 필터
표 A.71. custom-filter 속성
속성 | Default | 설명 |
---|---|---|
class-name | HttpHandler의 클래스 이름입니다. | |
module | 클래스를 로드할 수 있는 모듈 이름입니다. | |
parameters | 필터 매개 변수. |
오류 페이지 필터
오류 페이지
표 A.72. error-page 속성
속성 | Default | 설명 |
---|---|---|
코드 | 오류 페이지 코드. | |
경로 | 오류 페이지 경로. |
expression-filter 필터
Undertow 표현식 언어에서 구문 분석된 필터입니다.
표 A.73. expression-filter 속성
속성 | Default | 설명 |
---|---|---|
expression | 필터를 정의하는 표현식입니다. | |
module | 필터 정의를 로드하는 데 사용할 모듈. |
gzip 필터
gzip 필터를 정의하고 속성이 없습니다.
MOD-cluster 필터
mod-cluster 필터 구성 요소에는 다음과 같은 구조가 있습니다.
표 A.74. MOD-cluster 속성
속성 | Default | 설명 |
---|---|---|
advertise-frequency | 10000 | mod_cluster가 네트워크에서 자체적으로 알리는 빈도(밀리초)입니다. |
advertise-path | / | mod_cluster가 에 등록된 경로입니다. |
advertise-protocol | http | 사용 중인 프로토콜입니다. |
advertise-socket-binding | 알리는 데 사용되는 멀티캐스트 그룹입니다. | |
broken-node-timeout | 60000 | 손상된 노드가 테이블에서 제거되기 전에 경과해야 하는 시간입니다. |
cached-connections-per-threads | 5 | 무기한 활성 상태로 유지되는 연결 수입니다. |
connection-idle-timeout | 60 |
연결이 닫히기 전에 연결이 유휴 상태가 될 수 있는 시간입니다. 풀 크기가 구성된 최소값(cached |
connections-per-thread | 10 | IO 스레드당 백엔드 서버로 유지될 연결 수입니다. |
enable-http2 | false | 로드 밸런서 장치가 백엔드 연결을 HTTP/2로 업그레이드해야 하는지 여부입니다. HTTP/2가 지원되지 않는 경우 HTTP 또는 HTTPS가 정상적으로 사용됩니다. |
failover-strategy | LOAD_BALANCED | 장애 조치 노드 선택 방법을 결정하는 속성입니다. 세션이 선호도가 있는 노드를 사용할 수 없는 경우입니다. |
health-check-interval | 10000 | 상태 점검 빈도는 백엔드 노드로 ping합니다. |
http2-enable-push | true | HTTP/2 연결에 대해 push를 활성화해야 하는지 여부입니다. |
http2-header-table-size | 4096 | HPACK 압축에 사용된 헤더 테이블의 크기(바이트)입니다. 이 메모리 양은 연결당 압축을 위해 할당됩니다. 더 큰 값은 더 많은 메모리를 사용하지만 더 나은 압축을 제공할 수 있습니다. |
http2-initial-window-size | 65535 | 클라이언트가 서버에 데이터를 보낼 수 있는 속도를 제어하는 흐름 제어 창 크기(바이트)입니다. |
http2-max-concurrent-streams | 단일 연결에서 언제든지 활성화할 수 있는 최대 HTTP/2 스트림 수입니다. | |
http2-max-frame-size | 16384 | 최대 HTTP/2 프레임 크기(바이트)입니다. |
http2-max-header-list-size | 서버가 수락할 준비가 된 요청 헤더의 최대 크기(바이트)입니다. | |
management-access-predicate |
들어오는 요청에 적용되는 서술자는 mod 클러스터 관리 명령을 수행할 수 있는지 확인합니다. 관리를 | |
management-socket-binding | mod_cluster 관리 포트의 소켓 바인딩입니다. mod_cluster를 사용하는 경우 두 HTTP 리스너를 정의해야 합니다. 즉, 요청을 처리하는 공용 리스너와 mod 클러스터 명령을 처리하기 위해 내부 네트워크에 바인딩됩니다. 이 소켓 바인딩은 내부 리스너에 해당해야 하며 공개적으로 액세스할 수 없어야 합니다. | |
max-ajp-packet-size | 8192 | AJP 패킷의 최대 크기(바이트)입니다. 이렇게 하면 AJP가 많은 헤더가 있는 요청 및 응답에 대해 작동할 수 있습니다. 로드 밸런서와 백엔드 서버 간에 동일해야 합니다. |
max-request-time | -1 | 백엔드 노드에 대한 요청을 종료하기 전에 수행할 수 있는 최대 시간입니다. |
max-retries | 1 | 요청이 실패하는 경우 요청을 재시도하려는 횟수입니다. 참고 요청이 멱등으로 간주되지 않은 경우 프록시가 백엔드 서버로 전송되지 않은지 확인할 수 있는 경우에만 재시도됩니다. |
request-queue-size | 10 | 503으로 요청을 거부하기 전에 연결 풀이 가득 찼을 경우 대기할 수 있는 요청 수입니다. |
security-key | mod_cluster 그룹에 사용되는 보안 키입니다. 모든 멤버는 동일한 보안 키를 사용해야 합니다. | |
security-realm |
SSL 구성을 제공하는 보안 영역입니다. 더 이상 사용되지 않음: | |
ssl-context |
필터에서 사용하는 | |
use-alias | false | 별칭 검사 수행 여부. |
worker | default | 광고 알림을 보내는 데 사용되는 XNIO 작업자입니다. |
표 A.75. 밸런서 속성
속성 | Default | 설명 |
---|---|---|
max-attempts | 요청을 백엔드 서버로 보내는 시도 횟수입니다. | |
sticky-session | 고정 세션이 활성화되면. | |
sticky-session-cookie | 세션 쿠키 이름. | |
sticky-session-force |
| |
sticky-session-path | 고정 세션 쿠키 경로입니다. | |
sticky-session-remove | 요청이 올바른 호스트로 라우팅될 수 없는 경우 세션 쿠키를 제거합니다. | |
wait-worker | 사용 가능한 작업자를 대기하는 시간(초)입니다. |
load-balancing-group 속성
부하 분산 그룹을 정의하고 옵션이 없습니다.
표 A.76. 노드 속성
속성 | Default | 설명 |
---|---|---|
aliases | 노드 별칭. | |
cache-connections | 무기한 생존을 유지하는 연결 수. | |
선택됨 | 선택한 개수. | |
flush-packets | 수신된 데이터가 즉시 플러시되어야 하는 경우. | |
로드 | 이 노드의 현재 로드입니다. | |
load-balancing-group | 이 노드가 속한 부하 분산 그룹입니다. | |
최대 연결 | IO 스레드당 최대 연결 수입니다. | |
open-connections | 현재 열려 있는 연결 수입니다. | |
Ping | 노드가 ping됩니다. | |
queue-new-requests | 요청이 수신되고 즉시 사용 가능한 작업자가 없으면 대기 상태가 됩니다. | |
읽기 | 노드에서 읽은 바이트 수입니다. | |
request-queue-size | 요청 큐의 크기입니다. | |
status | 이 노드의 현재 상태입니다. | |
timeout | 요청 시간 제한입니다. | |
ttl |
연결 수가 | |
uri | 로드 밸런서에서 노드에 연결하는 데 사용하는 URI입니다. | |
작성됨 | 노드에 전송된 바이트 수입니다. |
표 A.77. 컨텍스트 속성
속성 | Default | 설명 |
---|---|---|
requests | 이 컨텍스트에 대한 요청 수입니다. | |
status | 이 컨텍스트의 상태입니다. |
요청 제한 필터
표 A.78. 요청 제한 속성
속성 | Default | 설명 |
---|---|---|
max-concurrent-requests | 최대 동시 요청 수입니다. | |
queue-size | 거부되기 전에 큐에 처리할 요청 수입니다. |
응답 헤더 필터
응답 헤더 필터를 사용하면 사용자 정의 헤더를 추가할 수 있습니다.
표 A.79. response-header 속성
속성 | Default | 설명 |
---|---|---|
header-name | 헤더 이름입니다. | |
header-value | 헤더 값입니다. |
필터 재작성
표 A.80. 속성 재작성
속성 | Default | 설명 |
---|---|---|
리디렉션 | false | 리디렉션이 재작성하는 대신 수행되는지 여부. |
대상 | 타겟을 정의하는 표현식입니다. 상수 대상으로 리디렉션하는 경우 값에 작은따옴표가 있습니다. |
핸들러 속성
이러한 구성 요소는 /subsystem=undertow/configuration=handler
에서 찾을 수 있습니다.
파일 속성
표 A.81. 파일 속성
속성 | Default | 설명 |
---|---|---|
cache-buffer-size | 1024 | 버퍼의 크기입니다. |
캐시 버퍼 | 1024 | 버퍼 수입니다. |
대소문자를 구분합니다 | true |
대소문자를 구분하는 파일 처리 사용 여부. 기본 파일 시스템이 대/소문자를 구분하지 않는 경우에만 이 값을 |
directory-listing | false | 디렉토리 목록 활성화 여부. |
follow-symlink | false | 다음 심볼릭 링크를 사용할지 여부. |
경로 | 파일 핸들러가 리소스를 제공할 파일 시스템의 경로입니다. | |
safe-symlink-paths | 심볼릭 링크의 대상이 될 수 있는 안전한 경로. |
정적 리소스에 WebDAV 사용
이전 버전의 JBoss EAP는 WebdavServlet
을 통해 웹
하위 시스템과 함께 WebDAV를 사용하여 정적 리소스를 호스트하고 추가 HTTP 메서드를 활성화하여 해당 파일에 액세스하고 조작할 수 있게 되었습니다. JBoss EAP 7에서 undertow
하위 시스템은 파일 핸들러를 사용하여 정적 파일을 제공하는 메커니즘을 제공하지만 undertow
하위 시스템은 WebDAV를 지원하지 않습니다. JBoss EAP 7에서 WebDAV를 사용하려면 사용자 지정 WebDAV 서블릿을 작성할 수 있습니다.
reverse-proxy 특성
reverse-proxy 핸들러 구성 요소에는 다음과 같은 구조가 있습니다.
표 A.82. 역방향 프록시 속성
속성 | Default | 설명 |
---|---|---|
cached-connections-per-threads | 5 | 무기한 활성 상태로 유지되는 연결 수입니다. |
connection-idle-timeout | 60 | 연결이 닫히기 전에 연결이 유휴 상태가 될 수 있는 시간입니다. 풀 크기가 구성된 최소값(cached-connections-per-thread)으로 구성되면 연결 시간이 초과되지 않습니다. |
connections-per-thread | 40 | IO 스레드당 백엔드 서버로 유지될 연결 수입니다. |
max-request-time | -1 | 프록시 요청이 종료되기 전에 활성화할 수 있는 최대 시간입니다. 기본값은 무제한입니다. |
max-retries | 1 | 요청이 실패하는 경우 요청을 재시도하려는 횟수입니다. 참고 요청이 멱등으로 간주되지 않은 경우 프록시가 백엔드 서버로 전송되지 않은지 확인할 수 있는 경우에만 재시도됩니다. |
problem-server-retry | 30 | 중단된 서버에 다시 연결을 시도하기 전에 대기하는 시간(초)입니다. |
request-queue-size | 10 | 503으로 요청을 거부하기 전에 연결 풀이 가득 찼을 경우 대기할 수 있는 요청 수입니다. |
session-cookie-names | JSESSIONID | 쉼표로 구분된 세션 쿠키 이름 목록입니다. 일반적으로 이는 JSESSIONID일 뿐입니다. |
표 A.83. 호스트 속성
속성 | Default | 설명 |
---|---|---|
enable-http2 | false |
|
instance-id | 고정 세션을 활성화하는 데 사용할 인스턴스 ID 또는 JVM 경로입니다. | |
outbound-socket-binding | 이 호스트의 아웃바운드 소켓 바인딩. | |
경로 | / | host가 루트 리소스를 사용하지 않는 경우 선택적 경로입니다. |
스키마 | http | 사용되는 스키마의 종류입니다. |
security-realm | 호스트 연결에 대한 SSL 구성을 제공하는 보안 영역입니다. | |
ssl-context | 이 핸들러에서 사용할 SSLContext에 대한 참조입니다. |
서버 속성
서버 구성 요소에는 다음과 같은 구조가 있습니다.
서버 속성
표 A.84. 서버 속성
속성 | Default | 설명 |
---|---|---|
default-host | default-host | 서버의 기본 가상 호스트. |
servlet-container | default | 서버의 기본 서블릿 컨테이너입니다. |
ajp-listener 속성
표 A.85. ajp-listener 속성
속성 | Default | 설명 |
---|---|---|
allow-encoded-slash | false |
요청에 인코딩된 문자가 포함된 경우(예: |
allow-equals-in-cookie-value | false | 이스케이프되지 않은 쿠키 값에서 이스케이프가 같은 문자를 허용할지 여부. 따옴표로 묶지 않은 쿠키 값에는 동일한 문자를 포함할 수 없습니다. 값이 있는 경우 값은 등호 앞에 끝납니다. 나머지 쿠키 값은 삭제됩니다. |
allow-unescaped-characters-in-url | false |
URL에서 이스케이프되지 않은 문자를 허용할지 여부입니다. |
always-set-keep-alive | true | 연결: keep-alive 헤더가 사양에 엄격하게 필요하지 않은 경우에도 응답에 추가됩니다. |
buffer-pipelined-data | false | 파이프라인화된 요청을 버퍼링할지 여부입니다. |
buffer-pool | default | AJP 리스너의 버퍼 풀입니다. |
decode-url | true |
|
noallowed-methods | ["TRACE"] | 허용되지 않는 쉼표로 구분된 HTTP 메서드 목록입니다. |
enabled | true | 리스너가 활성화된 경우. 더 이상 사용되지 않음: 활성화된 특성으로 인해 구성 일관성이 적용되는 데 문제가 발생할 수 있습니다. |
max-ajp-packet-size | 8192 | 지원되는 최대 AJP 패킷 크기입니다. 이 수정된 경우 로드 밸런서 및 백엔드 서버에서 증가했습니다. |
max-buffered-request-size | 16384 | 버퍼링된 요청의 최대 크기(바이트요청)는 일반적으로 버퍼링되지 않으며, 가장 일반적인 사례는 POST 요청에 대해 SSL 재협상을 수행할 때이며 재협상을 수행하려면 사후 데이터를 완전히 버퍼링해야 합니다. |
최대 연결 |
최대 동시 연결 수입니다. 서버 구성에 값이 설정되지 않은 경우 동시 연결 수에 대한 제한은 | |
최대 쿠키 | 200 | 구문 분석할 최대 쿠키 수입니다. 이는 해시 취약점으로부터 보호하는 데 사용됩니다. |
max-header-size | 1048576 | HTTP 요청 헤더의 최대 크기(바이트)입니다. |
max-headers | 200 | 구문 분석될 최대 헤더 수입니다. 이는 해시 취약점으로부터 보호하는 데 사용됩니다. |
max-parameters | 1000 | 구문 분석할 최대 매개변수 수입니다. 이는 해시 취약점으로부터 보호하는 데 사용됩니다. 이는 쿼리 매개변수 및 POST 데이터에 모두 적용되지만 누적되지 않습니다. 예를 들어 최대 매개변수 * 2 총 매개 변수를 가질 수 있습니다. |
max-post-size | 10485760 | 허용되는 게시물의 최대 크기 |
no-request-timeout | 60000 | 컨테이너에서 연결을 닫기 전에 연결이 유휴 상태가 될 수 있는 시간(밀리초)입니다. |
read-timeout |
소켓의 읽기 시간 제한(밀리초)을 구성합니다. 읽기에 성공하지 않고 지정된 시간이 경과하면 소켓의 다음 읽기에 | |
수신 버퍼 | 수신 버퍼 크기입니다. | |
record-request-start-time | false | 요청 시작 시간을 기록할지 여부입니다. 이는 작지만 측정 가능한 성능에 영향을 미칩니다. |
redirect-socket | 이 리스너가 비SSL 요청을 지원하고 있고 요청이 자동으로 여기에 지정된 소켓 바인딩 포트로 리디렉션되는지 여부에 관계없이 일치하는 SSL 전송이 필요한 요청이 수신됩니다. | |
request-parse-timeout | 요청을 구문 분석할 수 있는 최대 시간(밀리초)입니다. | |
resolve-peer-address | false | 호스트 DNS 조회 활성화. |
스키마 | 리스너 스키마는 HTTP 또는 HTTPS일 수 있습니다. 기본적으로 스키마는 들어오는 AJP 요청에서 가져옵니다. | |
보안 | false |
|
send-buffer | 전송 버퍼 크기입니다. | |
socket-binding | AJP 리스너 소켓 바인딩입니다. | |
tcp-backlog | 지정된 백로그를 사용하여 서버를 구성합니다. | |
tcp-keep-alive | TCP 보관 메시지를 구현 종속 방식으로 보내도록 채널을 구성합니다. | |
url-charset | UTF-8 | URL 문자 집합. |
worker | default | 리스너의 XNIO 작업자입니다. |
write-timeout |
소켓의 쓰기 시간 제한(밀리초)을 구성합니다. 쓰기가 성공적으로 수행되지 않고 지정된 시간이 경과하면 소켓의 다음 쓰기에 |
호스트 속성
표 A.86. 호스트 속성
속성 | Default | 설명 |
---|---|---|
alias | 쉼표로 구분된 호스트의 별칭 목록입니다. | |
default-response-code | 404 | 설정하면 요청된 컨텍스트가 서버에 없는 경우 응답 코드가 반환됩니다. |
default-web-module | ROOT.war | 기본 웹 모듈. |
disable-console-redirect | false |
|
queue-requests-on-start | true |
|
filter-ref 속성
표 A.87. filter-ref 속성
속성 | Default | 설명 |
---|---|---|
서술자 | 서술자는 교환을 기반으로 진정한/false 결정을 내릴 수 있는 간단한 방법을 제공합니다. 대부분의 핸들러에는 조건부로 적용해야 하는 요구 사항이 있으며 서술자는 조건을 지정하는 일반적인 방법을 제공합니다. | |
priority | 1 |
필터 순서를 정의합니다. 숫자가 작으면 동일한 컨텍스트 위의 다른 항목보다 먼저 핸들러 체인에 포함되도록 서버에 지시합니다. 값은 |
위치 속성
표 A.88. 위치 속성
속성 | Default | 설명 |
---|---|---|
핸들러 | 이 위치의 기본 핸들러. |
filter-ref 속성
표 A.89. filter-ref 속성
속성 | Default | 설명 |
---|---|---|
서술자 | 서술자는 교환을 기반으로 진정한/false 결정을 내릴 수 있는 간단한 방법을 제공합니다. 대부분의 핸들러에는 조건부로 적용해야 하는 요구 사항이 있으며 서술자는 조건을 지정하는 일반적인 방법을 제공합니다. | |
priority | 1 | 필터 순서를 정의합니다. 1 이상으로 설정해야 합니다. 숫자가 많으면 동일한 컨텍스트의 다른 항목보다 먼저 핸들러 체인에 포함되도록 지시합니다. |
access-log 속성
관리 CLI를 사용하여 access-log
요소를 관리할 때 호스트
요소의 설정에서
사용할 수 있습니다. 예를 들면 다음과 같습니다.
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add /subsystem=undertow/server=default-server/host=default-host/setting=access-log:read-resource
표 A.90. access-log 속성
속성 | Default | 설명 |
---|---|---|
디렉토리 | ${jboss.server.log.dir} | 로그를 저장할 디렉터리입니다. |
확장 | false | 로그에서 확장된 로그 파일 형식을 사용하는지 여부. |
패턴 | Common | 액세스 로그 패턴입니다. 이 속성에 사용할 수 있는 옵션에 대한 자세한 내용은 JBoss EAP 개발 가이드의 Provided Undertow Handlers 를 참조하십시오. 참고
요청을 처리하는 데 걸린 시간을 인쇄하도록 /subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=record-request-start-time,value=true) |
서술자 | 요청을 기록해야 하는지 여부를 결정하는 서술자입니다. | |
접두사 | access_log. | 로그 파일 이름의 접두사입니다. |
relative-to | 경로가 상대적인 디렉터리입니다. | |
rotate | true | 매일 액세스 로그를 로테이션할지 여부입니다. |
접미사 | log | 로그 파일 이름의 접미사입니다. |
use-server-log | false | 별도의 파일이 아니라 서버 로그에 로그를 작성할지 여부. |
worker | default | 로깅에 사용할 작업자의 이름입니다. |
console-access-log 속성
표 A.91. console-access-log 특성
속성 | Default | 설명 |
---|---|---|
속성 | {remote-host={},remote-user={},date-time={},request-line={},response-code={},bytes-sent={}} | 콘솔 액세스 로그 출력에 포함하거나 기본 데이터에 사용자 지정을 포함할 로그 데이터를 지정합니다. |
include-host-name | false |
JSON 구조 출력에 호스트 이름을 포함할지 여부를 지정합니다. |
metadata | 콘솔 액세스 로그 출력에 포함할 사용자 지정 메타데이터를 지정합니다. | |
서술자 | 요청을 기록해야 하는지 여부를 결정하는 서술자입니다. | |
worker | default | 로깅에 사용할 작업자의 이름입니다. |
HTTP-invoker 속성
표 A.92. HTTP-invoker 속성
속성 | Default | 설명 |
---|---|---|
http-authentication-factory | 인증에 사용할 HTTP 인증 팩토리입니다. | |
경로 | wildfly-services | 서비스가 설치되는 경로입니다. |
security-realm | 인증에 사용할 레거시 보안 영역입니다. |
SSO(Single-Sign-On) 속성
관리 CLI를 사용하여 single-sign-on
요소를 관리하는 경우 호스트
요소의 설정에서
사용할 수 있습니다. 예를 들면 다음과 같습니다.
/subsystem=undertow/server=default-server/host=default-host/setting=single-sign-on:add /subsystem=undertow/server=default-server/host=default-host/setting=single-sign-on:read-resource
분산 Single Sign-On은 이전 버전의 JBoss EAP와 다르게 적용되지 않지만 JBoss EAP 7에서는 인증 정보의 캐싱 및 배포가 다르게 처리됩니다. JBoss EAP 7의 경우 ha 프로필을 실행할 때 기본적으로 각 호스트에는 관련 세션 및 SSO 쿠키 정보를 저장할 고유한 Infinispan 캐시가 있습니다. 이 캐시는 웹 캐시 컨테이너의 기본 캐시를 기반으로 합니다. 또한 JBoss EAP는 모든 호스트의 개별 캐시 간 전파 정보를 처리합니다.
표 A.93. SSO(Single-Sign-On) 속성
속성 | Default | 설명 |
---|---|---|
redhat-name | JSESSIONIDSSO | 쿠키 이름입니다. |
domain | 사용할 쿠키 도메인입니다. | |
http-only | false | 쿠키 httpOnly 속성 설정. |
경로 | / | 경로. |
보안 | false | 쿠키 보안 속성 설정. |
HTTP-listener 속성
표 A.94. HTTP-listener 속성
속성 | Default | 설명 |
---|---|---|
allow-encoded-slash | false |
요청에 인코딩된 문자가 포함된 경우(예: |
allow-equals-in-cookie-value | false | 이스케이프되지 않은 쿠키 값에서 이스케이프가 같은 문자를 허용할지 여부. 따옴표로 묶지 않은 쿠키 값에는 동일한 문자를 포함할 수 없습니다. 값이 있는 경우 값은 등호 앞에 끝납니다. 나머지 쿠키 값은 삭제됩니다. |
allow-unescaped-characters-in-url | false |
URL에서 이스케이프되지 않은 문자를 허용할지 여부입니다. |
always-set-keep-alive | true | 연결: keep-alive 헤더가 사양에 엄격하게 필요하지 않은 경우에도 응답에 추가됩니다. |
buffer-pipelined-data | false | 파이프라인화된 요청을 버퍼링할지 여부입니다. |
buffer-pool | default | 리스너의 버퍼 풀입니다. |
certificate-forwarding | false |
인증서 전달을 활성화해야 하는지 여부입니다. 이 기능이 활성화되면 리스너는 |
decode-url | true | 파서가 선택한 문자 인코딩을 사용하여 URL 및 쿼리 매개 변수를 디코딩할지 여부(기본값: UTF-8). false인 경우 디코딩되지 않습니다. 그러면 이후 핸들러가 원하는 문자 집합으로 디코딩할 수 있습니다. |
noallowed-methods | ["TRACE"] | 허용되지 않는 쉼표로 구분된 HTTP 메서드 목록입니다. |
enable-http2 | false | 이 리스너에 대해 HTTP/2 지원을 활성화할지 여부입니다. |
enabled | true | 리스너가 활성화되었는지 여부. 더 이상 사용되지 않음: 활성화된 특성으로 인해 구성 일관성이 적용되는 데 문제가 발생할 수 있습니다. |
http2-enable-push | true | 이 연결에 대해 서버 푸시를 활성화할지 여부입니다. |
http2-header-table-size | 4096 | HPACK 압축에 사용된 헤더 테이블의 크기(바이트)입니다. 이 메모리 양은 연결당 압축을 위해 할당됩니다. 더 큰 값은 더 많은 메모리를 사용하지만 더 나은 압축을 제공할 수 있습니다. |
http2-initial-window-size | 65535 | 클라이언트가 서버에 데이터를 보낼 수 있는 속도를 제어하는 흐름 제어 창 크기(바이트)입니다. |
http2-max-concurrent-streams | 단일 연결에서 언제든지 활성화할 수 있는 최대 HTTP/2 스트림 수입니다. | |
http2-max-frame-size | 16384 | 최대 HTTP/2 프레임 크기(바이트)입니다. |
http2-max-header-list-size | 서버가 수락할 준비가 된 요청 헤더의 최대 크기입니다. | |
max-buffered-request-size | 16384 | 버퍼링된 요청의 최대 크기(바이트요청)는 일반적으로 버퍼링되지 않으며, 가장 일반적인 사례는 POST 요청에 대해 SSL 재협상을 수행할 때이며 재협상을 수행하려면 사후 데이터를 완전히 버퍼링해야 합니다. |
최대 연결 |
최대 동시 연결 수입니다. 서버 구성에 값이 설정되지 않은 경우 동시 연결 수에 대한 제한은 | |
최대 쿠키 | 200 | 구문 분석할 최대 쿠키 수입니다. 이는 해시 취약점으로부터 보호하는 데 사용됩니다. |
max-header-size | 1048576 | HTTP 요청 헤더의 최대 크기(바이트)입니다. |
max-headers | 200 | 구문 분석될 최대 헤더 수입니다. 이는 해시 취약점으로부터 보호하는 데 사용됩니다. |
max-parameters | 1000 | 구문 분석할 최대 매개변수 수입니다. 이는 해시 취약점으로부터 보호하는 데 사용됩니다. 이는 쿼리 매개변수 및 POST 데이터에 모두 적용되지만 누적되지 않습니다. 예를 들어 최대 매개 변수 * 2 총 매개 변수를 가질 수 있습니다. |
max-post-size | 10485760 | 승인될 게시물의 최대 크기입니다. |
no-request-timeout | 60000 | 컨테이너에서 연결을 닫기 전에 연결이 유휴 상태가 될 수 있는 시간(밀리초)입니다. |
proxy-address-forwarding | false | x-forwarded-host 및 유사한 헤더를 활성화하고 원격 IP 주소와 호스트 이름을 설정할지 여부입니다. |
proxy-protocol | false |
PROXY 프로토콜을 사용하여 연결 정보를 전송할지 여부입니다. |
read-timeout |
소켓의 읽기 시간 제한(밀리초)을 구성합니다. 읽기에 성공하지 않고 지정된 시간이 경과하면 소켓의 다음 읽기에 | |
수신 버퍼 | 수신 버퍼 크기입니다. | |
record-request-start-time | false | 요청 시작 시간을 기록할지 여부입니다. 이는 작지만 측정 가능한 성능에 영향을 미칩니다. |
redirect-socket | 이 리스너가 비SSL 요청을 지원하고 있고 요청이 자동으로 여기에 지정된 소켓 바인딩 포트로 리디렉션되는지 여부에 관계없이 일치하는 SSL 전송이 필요한 요청이 수신됩니다. | |
request-parse-timeout | 요청을 구문 분석할 수 있는 최대 시간(밀리초)입니다. | |
require-host-http11 | false |
모든 HTTP/1.1 요청에 |
resolve-peer-address | false | 호스트 DNS 조회 활성화. |
보안 | false |
|
send-buffer | 전송 버퍼 크기입니다. | |
socket-binding | 리스너 소켓 바인딩 | |
tcp-backlog | 지정된 백로그를 사용하여 서버를 구성합니다. | |
tcp-keep-alive | TCP 보관 메시지를 구현 종속 방식으로 보내도록 채널을 구성합니다. | |
url-charset | UTF-8 | URL 문자 집합. |
worker | default | 리스너의 XNIO 작업자입니다. |
write-timeout |
소켓의 쓰기 시간 제한(밀리초)을 구성합니다. 쓰기가 성공적으로 수행되지 않고 지정된 시간이 경과하면 소켓의 다음 쓰기에 |
HTTPS-listener 속성
표 A.95. HTTPS-listener 속성
속성 | Default | 설명 |
---|---|---|
allow-encoded-slash | false |
요청에 인코딩된 문자가 포함된 경우(예: |
allow-equals-in-cookie-value | false | 이스케이프되지 않은 쿠키 값에서 이스케이프가 같은 문자를 허용할지 여부. 따옴표로 묶지 않은 쿠키 값에는 동일한 문자를 포함할 수 없습니다. 값이 있는 경우 값은 등호 앞에 끝납니다. 나머지 쿠키 값은 삭제됩니다. |
allow-unescaped-characters-in-url | false |
URL에서 이스케이프되지 않은 문자를 허용할지 여부입니다. |
always-set-keep-alive | true | 연결: keep-alive 헤더가 사양에 엄격하게 필요하지 않은 경우에도 응답에 추가됩니다. |
buffer-pipelined-data | false | 파이프라인화된 요청을 버퍼링할지 여부입니다. |
buffer-pool | default | 리스너의 버퍼 풀입니다. |
certificate-forwarding | false |
인증서 전달을 활성화해야 하는지 여부입니다. 이 기능이 활성화되면 리스너는 |
decode-url | true | 파서가 선택한 문자 인코딩을 사용하여 URL 및 쿼리 매개 변수를 디코딩할지 여부(기본값: UTF-8). false인 경우 디코딩되지 않습니다. 그러면 이후 핸들러가 원하는 문자 집합으로 디코딩할 수 있습니다. |
noallowed-methods | ["TRACE"] | 허용되지 않는 쉼표로 구분된 HTTP 메서드 목록입니다. |
enable-http2 | false | 이 리스너에 대해 HTTP/2 지원을 활성화합니다. |
Enable-spdy | false | 이 리스너에 대한 SPDY 지원을 활성화합니다. 더 이상 사용되지 않음: SPDY가 HTTP/2로 교체되었습니다. |
enabled | true | 리스너가 활성화된 경우. 더 이상 사용되지 않음: 활성화된 특성으로 인해 구성 일관성이 적용되는 데 문제가 발생할 수 있습니다. |
enabled-cipher-suites | 활성화된 SSL 암호를 구성합니다. 더 이상 사용되지 않음: SSLContext를 참조하는 경우 암호화 제품군을 사용하여 지원되도록 구성해야 합니다. | |
enabled-protocols | SSL 프로토콜을 구성합니다. 더 이상 사용되지 않음: SSLContext를 참조하는 경우 암호화 제품군을 사용하여 지원되도록 구성해야 합니다. | |
http2-enable-push | true | 이 연결에 대해 서버 푸시가 활성화되면 다음을 수행합니다. |
http2-header-table-size | 4096 | HPACK 압축에 사용된 헤더 테이블의 크기(바이트)입니다. 이 메모리 양은 연결당 압축을 위해 할당됩니다. 더 큰 값은 더 많은 메모리를 사용하지만 더 나은 압축을 제공할 수 있습니다. |
http2-initial-window-size | 65535 | 클라이언트가 서버에 데이터를 보낼 수 있는 속도를 제어하는 흐름 제어 창 크기(바이트)입니다. |
http2-max-concurrent-streams | 단일 연결에서 언제든지 활성화할 수 있는 최대 HTTP/2 스트림 수입니다. | |
http2-max-frame-size | 16384 | 최대 HTTP/2 프레임 크기(바이트)입니다. |
http2-max-header-list-size | 서버가 수락할 준비가 된 요청 헤더의 최대 크기입니다. | |
max-buffered-request-size | 16384 | 버퍼링된 요청의 최대 크기(바이트요청)는 일반적으로 버퍼링되지 않으며, 가장 일반적인 사례는 POST 요청에 대해 SSL 재협상을 수행할 때이며 재협상을 수행하려면 사후 데이터를 완전히 버퍼링해야 합니다. |
최대 연결 |
최대 동시 연결 수입니다. 서버 구성에 값이 설정되지 않은 경우 동시 연결 수에 대한 제한은 | |
최대 쿠키 | 100 | 구문 분석할 최대 쿠키 수입니다. 이는 해시 취약점으로부터 보호하는 데 사용됩니다. |
max-header-size | 1048576 | HTTP 요청 헤더의 최대 크기(바이트)입니다. |
max-headers | 200 | 구문 분석될 최대 헤더 수입니다. 이는 해시 취약점으로부터 보호하는 데 사용됩니다. |
max-parameters | 1000 | 구문 분석할 최대 매개변수 수입니다. 이는 해시 취약점으로부터 보호하는 데 사용됩니다. 이는 쿼리 매개변수 및 POST 데이터에 모두 적용되지만 누적되지 않습니다. 예를 들어 최대 매개변수 * 2 총 매개 변수를 가질 수 있습니다. |
max-post-size | 10485760 | 승인될 게시물의 최대 크기입니다. |
no-request-timeout | 60000 | 컨테이너에서 연결을 닫기 전에 연결이 유휴 상태가 될 수 있는 시간(밀리초)입니다. |
proxy-address-forwarding | false | x-forwarded-host 헤더 및 기타 x-forwarded-* 헤더 처리를 활성화하고 이 헤더 정보를 사용하여 원격 주소를 설정합니다. 이 설정은 이러한 헤더를 설정하는 신뢰할 수 있는 프록시 뒤에서만 사용해야 합니다. 그렇지 않으면 원격 사용자가 IP 주소를 스푸핑할 수 있습니다. |
proxy-protocol | false |
PROXY 프로토콜을 사용하여 연결 정보를 전송할지 여부입니다. |
read-timeout |
소켓의 읽기 시간 제한(밀리초)을 구성합니다. 읽기에 성공하지 않고 지정된 시간이 경과하면 소켓의 다음 읽기에 | |
수신 버퍼 | 수신 버퍼 크기입니다. | |
record-request-start-time | false | 요청 시작 시간을 기록할지 여부입니다. 이는 작지만 측정 가능한 성능에 영향을 미칩니다. |
request-parse-timeout | 요청을 구문 분석할 수 있는 최대 시간(밀리초)입니다. | |
require-host-http11 | false | 모든 HTTP/1.1 요청에 'Host' 헤더가 있어야 합니다. 요청에 이 헤더가 포함되지 않으면 403이 포함된 거부됩니다. |
resolve-peer-address | false | 호스트 DNS 조회 활성화. |
보안 | false |
|
security-realm |
리스너의 보안 영역. 더 이상 사용되지 않음: | |
send-buffer | 전송 버퍼 크기입니다. | |
socket-binding | 리스너의 소켓 바인딩입니다. | |
ssl-context | 이 리스너에서 사용할 SSLContext에 대한 참조입니다. | |
ssl-session-cache-size | 최대 활성 SSL 세션 수입니다. 더 이상 사용되지 않음: 이제 Elytron 보안 컨텍스트에서 구성할 수 있습니다. | |
ssl-session-timeout | SSL 세션의 시간 제한(초)입니다. 더 이상 사용되지 않음: 이제 Elytron 보안 컨텍스트에서 구성할 수 있습니다. | |
tcp-backlog | 지정된 백로그를 사용하여 서버를 구성합니다. | |
tcp-keep-alive | TCP 보관 메시지를 구현 종속 방식으로 보내도록 채널을 구성합니다. | |
url-charset | UTF-8 | URL 문자 집합. |
verify-client | NOT_REQUESTED | SSL 채널에 필요한 SSL 클라이언트 인증 모드입니다. 더 이상 사용되지 않음: SSLContext를 참조하는 경우 필요한 클라이언트 확인 모드를 위해 직접 구성해야 합니다. |
worker | default | 리스너의 XNIO 작업자입니다. |
write-timeout |
소켓의 쓰기 시간 제한(밀리초)을 구성합니다. 쓰기가 성공적으로 수행되지 않고 지정된 시간이 경과하면 소켓의 다음 쓰기에 |
A.28. Undertow 하위 시스템 통계
표 A.96. ajp-listener
통계
이름 | 설명 |
---|---|
bytes-received | 이 리스너에서 수신한 바이트 수입니다. |
bytes-sent | 이 리스너에서 전송된 바이트 수입니다. |
error-count | 이 리스너가 보낸 500개 응답 수입니다. |
max-processing-time | 이 리스너에서 요청한 최대 처리 시간. |
처리 시간 | 이 리스너가 전달하는 모든 요청의 총 처리 시간입니다. |
request-count | 이 리스너가 제공한 요청 수입니다. |
표 A.97. http-listener
Statistics
이름 | 설명 |
---|---|
bytes-received | 이 리스너에서 수신한 바이트 수입니다. |
bytes-sent | 이 리스너에서 전송된 바이트 수입니다. |
error-count | 이 리스너가 보낸 500개 응답 수입니다. |
max-processing-time | 이 리스너에서 요청한 최대 처리 시간. |
처리 시간 | 이 리스너가 전달하는 모든 요청의 총 처리 시간입니다. |
request-count | 이 리스너가 제공한 요청 수입니다. |
표 A.98. https-listener
Statistics
이름 | 설명 |
---|---|
bytes-received | 이 리스너에서 수신한 바이트 수입니다. |
bytes-sent | 이 리스너에서 전송된 바이트 수입니다. |
error-count | 이 리스너가 보낸 500개 응답 수입니다. |
max-processing-time | 이 리스너에서 요청한 최대 처리 시간. |
처리 시간 | 이 리스너가 전달하는 모든 요청의 총 처리 시간입니다. |
request-count | 이 리스너가 제공한 요청 수입니다. |
A.29. HTTP 메서드의 기본 동작
이전 JBoss EAP 릴리스의 웹
하위 시스템과 비교하여 JBoss EAP 7.4의 undertow
하위 시스템에는 HTTP 메서드의 다른 기본 동작이 있습니다. 다음 표에서는 JBoss EAP 7.4의 기본 동작을 간략하게 설명합니다.
표 A.99. HTTP 방법 기본 동작
HTTP 방법 | 자카르타 서버 페이지 | 정적 HTML | 파일 핸들러에 의한 정적 HTML |
---|---|---|---|
GET | OK | OK | OK |
POST | OK | NOT_ALLOWED | OK |
HEAD | OK | OK | OK |
PUT | NOT_ALLOWED | NOT_ALLOWED | NOT_ALLOWED |
TRACE | NOT_ALLOWED | NOT_ALLOWED | NOT_ALLOWED |
DELETE | NOT_ALLOWED | NOT_ALLOWED | NOT_ALLOWED |
옵션 | NOT_ALLOWED | OK | NOT_ALLOWED |
서블릿의 경우 기본 동작은 NOT_ALLOWED
의 기본 동작이 있는 TRACE
메서드를 제외하고 구현에 따라 달라집니다.
A.30. 하위 시스템 속성 원격화
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-remoting_4_0.xsd
에 있는 스키마 정의 파일을 참조하십시오.
표 A.100. 속성 원격화
속성 | Default | 설명 |
---|---|---|
worker-read-threads | 1 | 작업자 리모팅에 대해 생성할 읽기 스레드 수입니다. |
worker-task-core-threads | 4 | 작업자 작업 스레드 풀의 코어 스레드 수입니다. |
worker-task-keepalive | 60 | 비코어 원격 작업자 작업 스레드를 활성 상태로 유지하는 시간(밀리초)입니다. |
worker-task-limit | 16384 | 거부하기 전에 허용할 최대 작업자 작업 원격화 수입니다. |
worker-task-max-threads | 16 | 작업자 작업 스레드 풀 삭제의 최대 스레드 수입니다. |
worker-write-threads | 1 | 작업자 원격에 대해 생성할 쓰기 스레드 수입니다. |
리모팅
요소의 위의 속성은 더 이상 사용되지 않습니다. 이러한 속성은 이제 the io
하위 시스템을 사용하여 구성해야 합니다.
표 A.101. 끝점 속성
속성 | Default | 설명 |
---|---|---|
auth-realm | 인증 콜백Handler가 지정되지 않은 경우 사용할 인증 영역입니다. | |
authentication-retries | 3 | 연결을 닫기 전에 클라이언트가 인증을 재시도할 수 있는 횟수를 지정합니다. |
authorize-id | SASL 권한 ID. 인증 콜백Handler가 지정되지 않은 경우 사용할 인증 사용자 이름으로 사용되며 선택한 SASL 메커니즘에 사용자 이름이 필요합니다. | |
buffer-region-size | 할당된 버퍼 영역의 크기입니다. | |
heartbeat-interval | 2147483647 | 연결 하트비트에 사용하는 간격(밀리초)입니다. 이 시간 동안 아웃바운드 방향에서 연결이 유휴 상태이면 ping 메시지가 전송되어 해당 응답 메시지가 트리거됩니다. |
max-inbound-channels | 40 | 채널의 최대 동시 인바운드 메시지 수입니다. |
max-inbound-message-size | 9223372036854775807 | 허용할 최대 인바운드 메시지 크기입니다. 이 크기를 초과하는 메시지는 쓰기 측면뿐만 아니라 읽기 쪽에서 예외가 throw됩니다. |
max-inbound-messages | 80 | 연결을 지원할 최대 인바운드 채널 수입니다. |
max-outbound-channels | 40 | 채널의 최대 동시 아웃바운드 메시지 수입니다. |
max-outbound-message-size | 9223372036854775807 | 전송할 최대 아웃바운드 메시지 크기입니다. 이보다 큰 메시지는 전송되지 않습니다. 이렇게 시도하면 쓰기 쪽에서 예외가 발생합니다. |
max-outbound-messages | 65535 | 연결을 지원할 최대 아웃바운드 채널 수입니다. |
receive-buffer-size | 8192 | 이 엔드포인트가 연결을 통해 수락할 가장 큰 버퍼의 크기입니다. |
receive-window-size | 131072 | 연결 채널에 대한 수신 방향(바이트)의 최대 창 크기입니다. |
SASL-protocol |
|
|
send-buffer-size | 8192 | 이 엔드포인트가 연결을 통해 전송할 가장 큰 버퍼 크기입니다. |
server-name | 연결의 서버 측은 초기 인사말에서 이 이름을 클라이언트에 전달합니다. 기본적으로 이름은 연결의 로컬 주소에서 자동으로 검색되거나 이를 사용하여 재정의할 수 있습니다. | |
transmit-window-size | 131072 | 연결 채널에 대한 전송 방향의 최대 창 크기(바이트)입니다. |
worker |
| 사용할 작업자 |
관리 CLI를 사용하여 엔드포인트
요소를 업데이트할 때 리모팅
요소의 구성에서
사용할 수 있습니다. 예를 들면 /subsystem=remoting/configuration=endpoint/
입니다.
커넥터 속성
커넥터 구성 요소에는 다음과 같은 구조가 있습니다.
표 A.102. 커넥터 속성
속성 | Default | 설명 |
---|---|---|
authentication-provider |
| |
sasl-authentication-factory | 이 커넥터를 보호하기 위해 SASL 인증 팩토리 참조. | |
SASL-protocol |
| 인증에 사용되는 SASL 메커니즘에 전달하는 프로토콜입니다. |
security-realm | 이 커넥터의 인증에 사용할 관련 보안 영역입니다. | |
server-name | 초기 메시지 교환 및 SASL 기반 인증에 전송할 서버 이름입니다. | |
socket-binding | 연결할 소켓 바인딩의 이름(또는 이름). | |
ssl-context | 이 커넥터에 사용할 SSL 컨텍스트에 대한 참조입니다. |
표 A.103. 속성
속성 | Default | 설명 |
---|---|---|
value | 속성 값입니다. |
보안 속성
보안
구성 요소를 사용하면 커넥터의 보안을 구성할 수 있지만 직접 구성 속성은 포함되지 않습니다. 다음과 같은 중첩 구성 요소를 사용하여 구성할 수 있습니다.
표 A.104. SASL 속성
속성 | Default | 설명 |
---|---|---|
include-mechanisms |
선택 사항인 중첩된 | |
qop |
중첩된 이 목록의 보호 품질 값은 다음과 같습니다.
| |
reuse-session | false |
선택적 중첩된 |
server-auth | false |
선택 사항인 중첩된 |
강력함 |
중첩된 선택적 이 목록의 암호화 강도 값은 다음과 같습니다.
|
SASL-policy 속성
The sasl-policy
구성 요소를 사용하면 사용 가능한 메커니즘 세트를 좁히는 데 사용할 선택적 정책을 지정할 수 있지만 직접 구성 속성은 포함되지 않습니다. 정책과 같은 중첩 구성 요소를 사용하여 구성할 수 있습니다.
표 A.105. 정책 속성
속성 | Default | 설명 |
---|---|---|
forward-secrecy | true |
선택적 중첩된 |
no-active | true |
선택적 중첩된 |
no-anonymous | true |
선택적 중첩된 |
사전 없음 | true |
선택적 중첩된 |
no-plain-text | true |
선택 사항인 중첩된 |
pass-credentials | true |
선택적 중첩 |
HTTP 커넥터 속성
http-connector 구성 요소에는 다음과 같은 구조가 있습니다.
표 A.106. HTTP-connector 속성
속성 | Default | 설명 |
---|---|---|
authentication-provider |
| |
Connector-ref |
연결할 | |
sasl-authentication-factory | 이 커넥터를 보호하기 위해 SASL 인증 팩토리 참조. | |
SASL-protocol |
| 인증에 사용되는 SASL 메커니즘에 전달하는 프로토콜입니다. |
security-realm | 이 커넥터의 인증에 사용할 관련 보안 영역입니다. | |
server-name | 초기 메시지 교환 및 SASL 기반 인증에 전송할 서버 이름입니다. |
아웃바운드 연결 속성
아웃바운드 커넥션
구성 요소에는 다음과 같은 구조가 있습니다.
표 A.107. 아웃바운드 커넥션 속성
속성 | Default | 설명 |
---|---|---|
uri | 아웃바운드 연결의 연결 URI입니다. |
표 A.108. 속성
속성 | Default | 설명 |
---|---|---|
value | 속성 값입니다. |
위의 속성
특성은 연결 생성 중에 사용할 XNIO 옵션과 관련이 있습니다.
원격 아웃바운드 연결
remote-outbound-connection
구성 요소에는 다음과 같은 구조가 있습니다.
표 A.109. remote-outbound-connection Attributes
속성 | Default | 설명 |
---|---|---|
authentication-context | 아웃바운드 연결에 대한 구성이 포함된 인증 컨텍스트 인스턴스에 대한 참조입니다. | |
outbound-socket-binding-ref |
연결의 대상 주소와 포트를 결정하는 데 사용할 | |
프로토콜 |
|
원격 연결에 사용할 프로토콜입니다. 기본값은 |
security-realm |
암호 및 SSL 구성을 가져오는 데 사용할 보안 영역에 대한 참조입니다. 더 이상 사용되지 않음: 아웃바운드 보안 설정은 | |
사용자 이름 |
원격 서버에 대해 인증할 때 사용할 사용자 이름입니다. 더 이상 사용되지 않음: 아웃바운드 보안 설정은 |
로컬 아웃바운드 연결 속성
local-outbound-connection
구성 요소에는 다음과 같은 구조가 있습니다.
표 A.110. local-outbound-connection 속성
속성 | Default | 설명 |
---|---|---|
outbound-socket-binding-ref |
연결의 대상 주소와 포트를 결정하는 데 사용할 |
A.31. IO 하위 시스템 속성
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 차이가 있을 수 있으므로 EAP_HOME/docs/schema/wildfly-io_3_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.111. 작업자 속성
속성 | Default | 설명 |
---|---|---|
io-threads | 작업자에 대해 생성할 I/O 스레드 수입니다. 지정하지 않는 경우 스레드 수가 CPU 수 - 2로 설정됩니다. | |
stack-size | 0 | 작업자 스레드에 사용하기 위한 스택 크기(바이트)입니다. |
task-keepalive | 60000 | 비코어 작업 스레드를 활성 상태로 유지하는 시간(밀리초)입니다. |
task-core-threads | 2 | 코어 작업 스레드 풀의 스레드 수입니다. |
task-max-threads |
작업자 작업 스레드 풀의 최대 스레드 수입니다. 지정하지 않는 경우 최대 스레드 수는 CPU 수 -1 16으로 설정되며 설정된 경우 |
표 A.112. buffer-pool 속성
속성 | Default | 설명 |
---|---|---|
buffer-size | 각 버퍼 슬라이스의 크기(바이트)입니다. 지정하지 않으면 시스템의 사용 가능한 RAM에 따라 크기가 설정됩니다.
이 속성에 대한 성능 튜닝은 JBoss EAP 성능 튜닝 가이드에서 버퍼 풀 구성을 참조하십시오. | |
buffers-per-slice | 큰 버퍼를 로 나눌 슬라이스 또는 섹션 수는 몇 개입니까. 이 방법은 여러 별도의 버퍼를 할당하는 것보다 메모리가 더 효율적일 수 있습니다. 지정하지 않으면 시스템의 사용 가능한 RAM 수를 기반으로 슬라이스 수가 설정됩니다.
| |
직접 버퍼 | 버퍼 풀에서 직접 버퍼를 사용하는지 여부는 NIO에서 더 빠릅니다. 일부 플랫폼은 직접 버퍼를 지원하지 않습니다. |
A.32. Jakarta Server Faces 모듈 템플릿
다음은 JBoss EAP용 다른 Jakarta Server Faces 버전을 설치할 때 필요한 다양한 Jakarta Server Faces 모듈에 사용되는 템플릿 예입니다. 전체 지침은 Jakarta Server Faces Implementation 설치를 참조하십시오.
예제: Mojarra Jakarta Server Faces Implementation JAR module.xml
템플릿에서 다음 Uninstall 변수에 적절한 값을 사용해야 합니다.
-
IMPL_NAME
-
버전
<module xmlns="urn:jboss:module:1.8" name="com.sun.jsf-impl:IMPL_NAME-VERSION"> <properties> <property name="jboss.api" value="private"/> </properties> <dependencies> <module name="javax.faces.api:IMPL_NAME-VERSION"/> <module name="javaee.api"/> <module name="javax.servlet.jstl.api"/> <module name="org.apache.xerces" services="import"/> <module name="org.apache.xalan" services="import"/> <module name="org.jboss.weld.core"/> <module name="org.jboss.weld.spi"/> <module name="javax.xml.rpc.api"/> <module name="javax.rmi.api"/> <module name="org.omg.api"/> </dependencies> <resources> <resource-root path="impl-VERSION.jar"/> </resources> </module>
예제: MyFaces Jakarta Server Faces Implementation JAR module.xml
템플릿에서 다음 Uninstall 변수에 적절한 값을 사용해야 합니다.
-
IMPL_NAME
-
버전
<module xmlns="urn:jboss:module:1.8" name="com.sun.jsf-impl:IMPL_NAME-VERSION"> <properties> <property name="jboss.api" value="private"/> </properties> <dependencies> <module name="javax.faces.api:IMPL_NAME-VERSION"> <imports> <include path="META-INF/**"/> </imports> </module> <module name="javaee.api"/> <module name="javax.servlet.jstl.api"/> <module name="org.apache.xerces" services="import"/> <module name="org.apache.xalan" services="import"/> <!-- extra dependencies for MyFaces --> <module name="org.apache.commons.collections"/> <module name="org.apache.commons.codec"/> <module name="org.apache.commons.beanutils"/> <module name="org.apache.commons.digester"/> <!-- extra dependencies for MyFaces 1.1 <module name="org.apache.commons.logging"/> <module name="org.apache.commons.el"/> <module name="org.apache.commons.lang"/> --> <module name="javax.xml.rpc.api"/> <module name="javax.rmi.api"/> <module name="org.omg.api"/> </dependencies> <resources> <resource-root path="IMPL_NAME-impl-VERSION.jar"/> </resources> </module>
예제: Mojarra Jakarta Server Faces API JAR module.xml
템플릿에서 다음 Uninstall 변수에 적절한 값을 사용해야 합니다.
-
IMPL_NAME
-
버전
<module xmlns="urn:jboss:module:1.8" name="javax.faces.api:IMPL_NAME-VERSION"> <dependencies> <module name="com.sun.jsf-impl:IMPL_NAME-VERSION"/> <module name="javax.enterprise.api" export="true"/> <module name="javax.servlet.api" export="true"/> <module name="javax.servlet.jsp.api" export="true"/> <module name="javax.servlet.jstl.api" export="true"/> <module name="javax.validation.api" export="true"/> <module name="org.glassfish.javax.el" export="true"/> <module name="javax.api"/> <module name="javax.websocket.api"/> </dependencies> <resources> <resource-root path="jsf-api-VERSION.jar"/> </resources> </module>
예제: MyFaces Jakarta Server Faces API JAR module.xml
템플릿에서 다음 Uninstall 변수에 적절한 값을 사용해야 합니다.
-
IMPL_NAME
-
버전
<module xmlns="urn:jboss:module:1.8" name="javax.faces.api:IMPL_NAME-VERSION"> <dependencies> <module name="javax.enterprise.api" export="true"/> <module name="javax.servlet.api" export="true"/> <module name="javax.servlet.jsp.api" export="true"/> <module name="javax.servlet.jstl.api" export="true"/> <module name="javax.validation.api" export="true"/> <module name="org.glassfish.javax.el" export="true"/> <module name="javax.api"/> <!-- extra dependencies for MyFaces 1.1 <module name="org.apache.commons.logging"/> <module name="org.apache.commons.el"/> <module name="org.apache.commons.lang"/> --> </dependencies> <resources> <resource-root path="myfaces-api-VERSION.jar"/> </resources> </module>
예제: Mojarra Jakarta Server Faces Injection JAR module.xml
템플릿에서 다음 Uninstall 변수에 적절한 값을 사용해야 합니다.
-
IMPL_NAME
-
버전
-
INJECTION_VERSION
-
WELD_VERSION
<module xmlns="urn:jboss:module:1.8" name="org.jboss.as.jsf-injection:IMPL_NAME-VERSION"> <properties> <property name="jboss.api" value="private"/> </properties> <resources> <resource-root path="wildfly-jsf-injection-INJECTION_VERSION.jar"/> <resource-root path="weld-core-jsf-WELD_VERSION.jar"/> </resources> <dependencies> <module name="com.sun.jsf-impl:IMPL_NAME-VERSION"/> <module name="java.naming"/> <module name="java.desktop"/> <module name="org.jboss.as.jsf"/> <module name="org.jboss.as.web-common"/> <module name="javax.servlet.api"/> <module name="org.jboss.as.ee"/> <module name="org.jboss.as.jsf"/> <module name="javax.enterprise.api"/> <module name="org.jboss.logging"/> <module name="org.jboss.weld.core"/> <module name="org.jboss.weld.api"/> <module name="javax.faces.api:IMPL_NAME-VERSION"/> </dependencies> </module>
예제: MyFaces Jakarta Server Faces Injection JAR module.xml
템플릿에서 다음 Uninstall 변수에 적절한 값을 사용해야 합니다.
-
IMPL_NAME
-
버전
-
INJECTION_VERSION
-
WELD_VERSION
<module xmlns="urn:jboss:module:1.8" name="org.jboss.as.jsf-injection:IMPL_NAME-VERSION"> <properties> <property name="jboss.api" value="private"/> </properties> <resources> <resource-root path="wildfly-jsf-injection-INJECTION_VERSION.jar"/> <resource-root path="weld-jsf-WELD_VERSION.jar"/> </resources> <dependencies> <module name="com.sun.jsf-impl:IMPL_NAME-VERSION"/> <module name="javax.api"/> <module name="org.jboss.as.web-common"/> <module name="javax.servlet.api"/> <module name="org.jboss.as.jsf"/> <module name="org.jboss.as.ee"/> <module name="org.jboss.as.jsf"/> <module name="javax.enterprise.api"/> <module name="org.jboss.logging"/> <module name="org.jboss.weld.core"/> <module name="org.jboss.weld.api"/> <module name="org.wildfly.security.elytron"/> <module name="javax.faces.api:IMPL_NAME-VERSION"/> </dependencies> </module>
예제: MyFaces commons-digester JAR module.xml
템플릿에서 VERSION provision 변수에
적절한 값을 사용해야 합니다.
<module xmlns="urn:jboss:module:1.5" name="org.apache.commons.digester">
<properties>
<property name="jboss.api" value="private"/>
</properties>
<resources>
<resource-root path="commons-digester-VERSION.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="org.apache.commons.collections"/>
<module name="org.apache.commons.logging"/>
<module name="org.apache.commons.beanutils"/>
</dependencies>
</module>
A.33. JGroups 하위 시스템 속성
jgroups
하위 시스템의 다양한 요소의 특성은 아래 표를 참조하십시오.
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/jboss-as-jgroups_5_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.113. 기본 jgroups 속성
속성 | Default | 설명 |
---|---|---|
default-channel | EE | 기본 JGroups 채널. |
default-stack | 기본 JGroups 프로토콜 스택. |
채널 속성
채널 요소에는 다음과 같은 구조가 있습니다.
fork
-
protocol
-
-
protocol
채널 속성
표 A.114. 채널 속성
속성 | Default | 설명 |
---|---|---|
cluster | JGroups 채널의 클러스터 이름입니다. 정의되지 않은 경우 채널 이름이 사용됩니다. | |
module | org.wildfly.clustering.server | 채널 서비스를 로드할 모듈입니다. |
스택 | JGroups 채널의 프로토콜 스택. | |
통계 지원 | false | 통계 활성화 여부. |
stats-enabled | false |
통계 활성화 여부. 더 이상 사용되지 않음: 대신 |
스택 속성
스택 요소에는 다음과 같은 구조가 있습니다.
스택 속성
표 A.115. 스택 속성
속성 | Default | 설명 |
---|---|---|
통계 지원 | false | 스택의 모든 프로토콜이 통계를 수집할지 여부를 나타냅니다. |
프로토콜 속성
일반적으로 사용되는 프로토콜 목록은 JGroups Protocols 섹션을 참조하십시오.
표 A.116. 프로토콜 속성
속성 | Default | 설명 |
---|---|---|
module | org.jgroups | 프로토콜 유형을 확인하는 모듈입니다. |
속성 | 이 프로토콜의 속성입니다. | |
통계 지원 | false | 이 프로토콜이 통계를 수집할지 여부를 나타내 스택 구성을 재정의합니다. |
속성 릴레이
표 A.117. 속성 릴레이
속성 | Default | 설명 |
---|---|---|
module | org.jgroups | 프로토콜 유형을 확인하는 모듈입니다. |
속성 | 이 프로토콜의 속성입니다. | |
Site | 로컬 사이트의 이름입니다. | |
통계 지원 | false | 이 프로토콜이 통계를 수집할지 여부를 나타내 스택 구성을 재정의합니다. |
원격 사이트 속성
표 A.118. 원격 사이트 속성
속성 | Default | 설명 |
---|---|---|
channel | 이 원격 사이트와 통신하는 데 사용되는 브리지 채널의 이름입니다. | |
cluster |
이 원격 사이트에 대한 브리지 채널의 클러스터 이름입니다. 더 이상 사용되지 않음: 대신 명시적으로 정의된 | |
스택 |
이 원격 사이트에 대한 브리지를 만드는 스택입니다. 더 이상 사용되지 않음: 대신 명시적으로 정의된 |
전송 속성
표 A.119. 전송 속성
속성 | Default | 설명 |
---|---|---|
default-executor |
수신 메시지를 처리하는 스레드 풀 실행자입니다. 더 이상 사용되지 않음: 대신 사전 정의된 | |
diagnostics-socket-binding | 이 프로토콜 계층에 대한 진단 소켓 바인딩 사양은 통신용 IP 인터페이스 및 포트를 지정하는 데 사용됩니다. | |
머신 | 이 노드의 시스템 또는 호스트 식별자입니다. Infinispan의 토폴로지 인식 일관된 해시에 의해 사용됩니다. | |
module | org.jgroups | 프로토콜 유형을 확인하는 모듈입니다. |
OOB-executor |
수신된 대역 외 메시지를 처리하는 스레드 풀 실행자입니다. 더 이상 사용되지 않음: 대신 사전 정의된 | |
속성 | 이 전송의 속성. | |
랙 | 서버 랙과 같은 랙(예: 이 노드의 식별자). Infinispan의 토폴로지 인식 일관된 해시에 의해 사용됩니다. | |
공유 | false |
|
Site | 데이터 센터와 같은 Site, 이 노드의 식별자입니다. Infinispan의 토폴로지 인식 일관된 해시에 의해 사용됩니다. | |
socket-binding | 이 프로토콜 계층에 대한 소켓 바인딩 사양으로, 통신용 IP 인터페이스 및 포트를 지정합니다. | |
통계 지원 | false | 이 프로토콜이 통계를 수집할지 여부를 나타내 스택 구성을 재정의합니다. |
thread-factory |
비동기 전송 관련 작업을 처리하는 데 사용할 스레드 팩토리입니다. 더 이상 사용되지 않음: 대신 사전 정의된 | |
timer-executor |
프로토콜 관련 타이밍 작업을 처리하는 스레드 풀 실행자입니다. 더 이상 사용되지 않음: 대신 사전 정의된 |
thread-pool 속성
표 A.120. thread-pool 속성
속성 | Default | 설명 |
---|---|---|
keepalive-time | 5000L | 유휴 상태에서 풀 스레드를 계속 실행해야 하는 시간(밀리초)입니다. 지정하지 않으면 실행자가 종료될 때까지 스레드가 실행됩니다. |
max-threads | 4 | 최대 스레드 풀 크기입니다. |
min-threads | 2 |
|
queue-length | 500 | 큐 길이입니다. |
A.34. JGroups 프로토콜
프로토콜 | 프로토콜 유형 | 설명 |
---|---|---|
ASYM_ENCRYPT | Encryption | 클러스터의 코디네이터에 저장된 시크릿 키를 사용하여 클러스터 구성원 간 메시지를 암호화합니다. |
AUTH | 인증 | 클러스터 구성원에 대한 인증 계층을 제공합니다. |
azure.AZURE_PING | 검색 | Microsoft Azure의 Blob 스토리지를 사용한 노드 검색을 지원합니다. |
FD_ALL | 오류 감지 | 간단한 하트비트 프로토콜을 기반으로 오류 감지 기능 제공. |
FD_SOCK | 오류 감지 | 클러스터 구성원 간에 생성된 TCP 소켓 링을 기반으로 오류 감지 기능을 제공합니다. |
JDBC_PING | 검색 | 멤버가 주소를 작성하는 공유 데이터베이스를 사용하여 클러스터 구성원을 검색합니다. |
MERGE3 | 병합 | 클러스터 분할 시 하위 클러스터를 병합합니다. |
MFC | 흐름 제어 | 발신자와 모든 클러스터 구성원 간에 멀티캐스트 흐름 제어 제공. |
MPING | 검색 | IP 멀티캐스트로 클러스터 구성원을 검색합니다. |
pbcast.GMS | Group Membership |
클러스터에 가입하는 새 멤버를 포함하여 그룹 멤버십을 처리하고, 기존 멤버의 요청을 종료하고, 충돌한 멤버의 |
pbcast.NAKACK2 | 메세지 전송 | 메시지의 신뢰성과 순서를 보장하여 하나의 발신자가 보낸 모든 메시지가 전송된 순서대로 수신되도록 보장합니다. |
pbcast.STABLE | 메시지 안정성 | 모든 멤버가 표시된 메시지를 삭제합니다. |
PING | 검색 | 클러스터 구성원의 동적 검색을 지원하여 구성원의 초기 검색. |
SASL | 인증 | SASL 메커니즘을 사용하여 클러스터 구성원에 대한 인증 계층을 제공합니다. |
SYM_ENCRYPT | Encryption | 클러스터 구성원 간 메시지를 암호화하기 위해 공유 키 저장소를 사용합니다. |
S3_PING | 검색 | Amazon S3을 사용하여 초기 구성원을 검색합니다. |
TCPGOSSIP | 검색 | 외부 gossip 라우터를 사용하여 클러스터 구성원을 검색합니다. |
TCPPING | 검색 | 클러스터를 구성하기 위해 클러스터 구성원의 주소의 정적 목록을 포함합니다. |
UFC | 흐름 제어 | 발신자와 모든 클러스터 구성원 간의 유니캐스트 흐름 제어 제공 |
UNICAST3 | 메세지 전송 | 메시지의 안정성과 유니캐스트 메시지의 순서를 보장하여 하나의 발신자가 보낸 모든 메시지가 전송된 순서대로 수신되도록 보장합니다. |
VERIFY_SUSPECT | 오류 감지 | 제거하기 전에 마지막으로 멤버를 ping하여 의심되는 구성원이 있는지 확인합니다. |
일반 프로토콜 속성
모든 프로토콜은 다음 속성에 액세스할 수 있습니다.
표 A.121. 프로토콜 속성
속성 | Default | 설명 |
---|---|---|
module | org.jgroups | 프로토콜 유형을 확인하는 모듈입니다. |
속성 | 이 프로토콜의 속성입니다. | |
통계 지원 | false | 통계 활성화 여부. |
인증 프로토콜
인증 프로토콜은 인증을 수행하는 데 사용되며, 주로 인증된 멤버만 클러스터에 참여할 수 있는지 확인합니다. 이러한 프로토콜은 클러스터 참여 요청을 수신 대기할 수 있도록 GMS
프로토콜 아래에 있습니다.
AUTH 속성
AUTH
프로토콜에는 추가 특성이 없지만 하위 요소로 정의된 토큰이 있어야 합니다.
이 프로토콜을 정의할 때 protocol 요소 대신 auth-protocol
요소가
사용됩니다.
토큰 유형
보안에 Elytron을 사용하는 경우 다음 인증 토큰 중 하나를 사용하는 것이 좋습니다. 이러한 인증 토큰은 의도적으로 Elytron과 함께 사용하도록 설계되었으며 레거시 보안 구성에서는 사용되지 않을 수 있습니다.
표 A.122. Elytron 토큰 유형
토큰 | 설명 |
---|---|
cipher-token | 공유 비밀이 변환되는 인증 토큰입니다. RSA는 변환에 사용되는 기본 알고리즘입니다. |
digest-token | 공유 비밀이 변환되는 인증 토큰입니다. SHA-256은 변환에 사용되는 기본 알고리즘입니다. |
일반 토큰 | 공유 보안에 대한 추가 변환이 없는 인증 토큰입니다. |
다음 인증 토큰은 JGroups에서 상속되며 인증이 필요한 모든 구성에서 사용할 수 있습니다.
표 A.123. JGroups 토큰 유형
토큰 | 설명 |
---|---|
MD5Token | 공유 비밀이 MD5 또는 SHA 해시를 사용하여 암호화되는 인증 토큰입니다. MD5는 암호화에 사용되는 기본 알고리즘입니다. |
SimpleToken | 공유 보안에 대한 추가 변환이 없는 인증 토큰입니다. 이 토큰은 대소문자를 구분하지 않으며 문자열이 일치하는지 확인할 때 대소문자를 구분하지 않습니다. |
X509Token | X509 인증서를 사용하여 공유 보안이 암호화되는 인증 토큰입니다. |
SASL 속성
표 A.124. SASL 속성
속성 | Default | 설명 |
---|---|---|
client_callback_handler |
노드가 클라이언트로 작동할 때 사용할 | |
client_name | 노드가 클라이언트 역할을 할 때 사용할 이름입니다. 이 이름은 JAAS 로그인 모듈을 사용하는 경우 주체를 가져오는 데도 사용됩니다. | |
client_password | 노드가 클라이언트 역할을 할 때 사용할 암호입니다. 이 암호는 JAAS 로그인 모듈을 사용하는 경우 주체를 가져오는 데도 사용됩니다. | |
login_module_name |
SASL 클라이언트 및 서버를 만들기 위한 제목으로 사용할 JAAS 로그인 모듈의 이름입니다. 이 특성은 GSSAPI와 같은 특정 | |
Mech |
SASL 인증 메커니즘의 이름입니다. 이 이름은 로컬 SASL 공급자가 지원하는 모든 메커니즘이 될 수 있으며 JDK는 기본적으로 | |
sasl_props |
정의된 | |
server_callback_handler |
노드가 서버 역할을 할 때 사용할 | |
server_name | 정규화된 서버 이름입니다. | |
timeout | 5000 | 과제에 대한 응답을 기다리는 시간(밀리초)입니다. |
검색 프로토콜
다음 프로토콜은 클러스터의 초기 멤버십을 찾는 데 사용되며 현재 코디네이터를 결정하는 데 사용할 수 있습니다. 검색 프로토콜 목록은 다음과 같습니다.
- AZURE_PING
- JDBC_PING
- MPING
- PING
- S3_PING
- TCPGOSSIP
- TCPPING
AZURE_PING Attributes
표 A.125. AZURE_PING Attributes
속성 | Default | 설명 |
---|---|---|
컨테이너 | PING 데이터에 사용할 Blob 컨테이너의 이름입니다. 유효한 DNS 이름이어야 합니다. | |
storage_access_key | 스토리지 계정의 시크릿 액세스 키입니다. | |
storage_account_name | Blob 컨테이너를 포함하는 Microsoft Azure 스토리지 계정의 이름입니다. |
JDBC_PING 속성
표 A.126. JDBC_PING 속성
속성 | Default | 설명 |
---|---|---|
data-source | 연결 및 JNDI 조회 속성 대신 사용할 데이터 소스 참조입니다. |
JDBC_PING
프로토콜을 정의할 때 protocol 요소 대신 the jdbc-protocol
요소가
사용됩니다.
S3_PING 속성
표 A.127. S3_PING 속성
속성 | Default | 설명 |
---|---|---|
access_key | S3 버킷에 액세스하는 데 사용되는 Amazon S3 액세스 키입니다. | |
호스트 | s3.amazonaws.com | S3 웹 서비스의 대상입니다. |
위치 | 사용할 Amazon S3 버킷의 이름입니다. 버킷이 존재하고 고유한 이름을 사용해야 합니다. | |
pre_signed_delete_url | DELETE 작업에 사용할 사전 서명된 URL입니다. | |
port |
| 웹 서비스가 수신 대기 중인 포트입니다. |
pre_signed_put_url | PUT 작업에 사용할 사전 서명된 URL입니다. | |
접두사 |
설정되고 | |
secret_access_key | S3 버킷에 액세스하는 데 사용되는 Amazon S3 시크릿 액세스 키입니다. | |
use_ssl | true | 호스트와 포트 조합에 연결할 때 SSL을 사용할지 여부를 결정합니다. |
TCPGOSSIP 속성
표 A.128. TCPGOSSIP 속성
속성 | Default | 설명 |
---|---|---|
socket-binding |
이 프로토콜 계층에 대한 소켓 바인딩 사양입니다. 더 이상 사용되지 않음: 대신 | |
socket-bindings | 이 프로토콜의 아웃바운드 소켓 바인딩입니다. |
TCPGOSSIP
프로토콜을 정의할 때 프로토콜
요소 대신 socket-discovery-protocol
요소가 사용됩니다.
TCPPING 속성
표 A.129. TCPPING 속성
속성 | Default | 설명 |
---|---|---|
socket-binding |
이 프로토콜 계층에 대한 소켓 바인딩 사양입니다. 더 이상 사용되지 않음: 대신 | |
socket-bindings | 이 프로토콜의 아웃바운드 소켓 바인딩입니다. |
TCPPING
프로토콜을 정의할 때 protocol 요소 대신 socket-discovery-protocol
요소가
사용됩니다.
암호화 프로토콜
다음 프로토콜은 통신 스택을 보호하는 데 사용됩니다. 암호화는 클러스터의 모든 구성원이 보유한 공유 비밀 키를 기반으로 합니다. 이 키는 SYM_ENCRYPT를 사용하거나
. 다음 프로토콜을 정의할 때 결과 XML에 ASYM_ENCRYPT
를 사용할 때 공개/개인 키 교환에서 가져온 공유 키 저장소에서 가져옵니다encrypt-protocol
요소가 생성됩니다.
ASYM_ENCRYPT
를 사용하는 경우 동일한 스택에 AUTH
프로토콜이 정의되어 있어야 합니다. The AUTH
프로토콜은 SYM_ENCRYPT
를 사용할 때 선택 사항입니다.
ASYM_ENCRYPT 속성
표 A.130. ASYM_ENCRYPT 속성
속성 | Default | 설명 |
---|---|---|
key-alias | 지정된 키 저장소의 암호화 키의 별칭입니다. | |
key-credential-reference | 키 저장소에서 암호화 키를 가져오는 데 필요한 자격 증명입니다. | |
key-store | 암호화 키가 포함된 키 저장소에 대한 참조입니다. |
SYM_ENCRYPT 속성
표 A.131. SYM_ENCRYPT 속성
속성 | Default | 설명 |
---|---|---|
key-alias | 지정된 키 저장소의 암호화 키의 별칭입니다. | |
key-credential-reference | 키 저장소에서 암호화 키를 가져오는 데 필요한 자격 증명입니다. | |
key-store | 암호화 키가 포함된 키 저장소에 대한 참조입니다. |
오류 감지 프로토콜
다음 프로토콜은 클러스터의 구성원을 조사하여 아직 활성 상태인지 확인하는 데 사용됩니다. 이러한 프로토콜에는 일반 특성 이외의 추가 속성이 없습니다.
- FD_ALL
- FD_SOCK
- VERIFY_SUSPECT
흐름 제어 프로토콜
다음 프로토콜은 흐름 제어 또는 가장 느린 수신자에 메시지 발신자의 속도를 조정하는 프로세스를 담당합니다. 발신자가 수신자보다 빠른 속도로 지속적으로 메시지를 보내면 수신자가 메시지를 대기열 업하거나 폐기하여 다시 전송합니다. 이러한 프로토콜에는 일반 특성 이외의 추가 속성이 없습니다.
- MFC - 멀티 캐스트 흐름 제어
- UFC - 유니캐스트 흐름 제어
그룹 멤버십 프로토콜
pbcast.GMS
프로토콜은 클러스터에 가입하는 새 구성원, 클러스터를 벗어나는 기존 구성원 및 충돌로 의심되는 구성원을 담당합니다. 이 프로토콜에는 일반 속성 이외의 추가 속성이 없습니다.
병합 프로토콜
클러스터가 분할되면 MERGE3
프로토콜은 하위 클러스터를 다시 병합합니다. 이 프로토콜은 클러스터 구성원을 다시 병합하지만 클러스터 상태를 병합하지 않습니다. 애플리케이션은 병합 상태를 위해 콜백을 처리합니다. 이 프로토콜에는 일반 속성 이외의 추가 속성이 없습니다.
메시지 안정성
pbcast.STABLE
프로토콜은 클러스터의 모든 구성원이 확인한 메시지를 수집하는 가비지 수집을 담당합니다. 이 프로토콜은 다이제스트라는 지정된 멤버의 메시지 번호를 포함하는 안정적인 메시지를 시작합니다. 클러스터의 모든 멤버가 다른 다이제스트를 수신하면 retransmission(전송) 테이블에서 메시지가 제거될 수 있습니다. 이 프로토콜에는 일반 속성 이외의 추가 속성이 없습니다.
신뢰할 수 있는 메시지 전송
다음 프로토콜은 클러스터의 모든 노드로 전송되는 메시지에 대해 안정적인 메시지 전송 및 FIFO 속성을 제공합니다. 순서 번호가 수신되지 않은 경우 모든 메시지가 번호가 지정되고 재전송 요청이 전송되므로 신뢰할 수 있는 배달은 발신자가 전송한 메시지를 손실하지 않는다는 것을 의미합니다. 이러한 프로토콜에는 일반 특성 이외의 추가 속성이 없습니다.
- pbcast.NAKACK2
- pbcast.UNICAST3
사용되지 않는 프로토콜
다음 프로토콜은 더 이상 사용되지 않으며 클래스 이름만 포함하는 프로토콜로 교체되었습니다. 예를 들어 org.jgroups.protocols.ASYM_ENCRYPT
를 지정하는 대신 프로토콜 이름은 ASYM_ENCRYPT
가 됩니다.
- org.jgroups.protocols.ASYM_ENCRYPT
- org.jgroups.protocols.AUTH
- org.jgroups.protocols.JDBC_PING
- org.jgroups.protocols.SYM_ENCRYPT
- org.jgroups.protocols.TCPGOSSIP
- org.jgroups.protocols.TCPPING
A.35. Apache HTTP Server mod_cluster 지시문
mod_cluster 커넥터는 Apache HTTP 서버 기반 로드 밸런서입니다. 통신 채널을 사용하여 Apache HTTP Server의 요청을 애플리케이션 서버 노드 세트 중 하나로 전달합니다. 다음 지시문은 mod_cluster를 구성하도록 설정할 수 있습니다.
mod_cluster는 Apache HTTP Server로 전달해야 하는 URL을 자동으로 구성하므로 ProxyPass 지시문을 사용할 필요가 없습니다.
표 A.132. mod_cluster 지시문
지시문 | 설명 | 값 |
---|---|---|
CreateBalancers |
Apache HTTP Server VirtualHosts에서 밸런서를 생성하는 방법을 정의합니다. 이렇게 하면 다음과 같은 지시문이 허용됩니다. |
|
UseAlias | 별칭이 서버 이름에 해당하는지 확인합니다. |
|
LBstatusRecalTime | 노드의 상태를 재계산하는 로드 밸런싱 논리의 시간 간격(초)입니다. | 기본값: 5초 |
WaitBeforeRemove | 제거된 노드가 httpd에 의해 잊기 전 시간(초)입니다. | 기본값: 10초 |
ProxyPassMatch/ProxyPass |
ProxyPassMatch 및 ProxyPass는 백엔드 URL 대신 ! 를 사용할 때 경로에서 reverse-proxy를 차단하는 mod_proxy 지시문 입니다. 이 명령은 Apache HTTP 서버가 정적 콘텐츠를 제공할 수 있도록 허용하는 데 사용됩니다. 예를 들면 다음과 같습니다. |
JBoss EAP 7 세션의 성능 최적화로 인해 핫-대기 노드 구성은 지원되지 않습니다.
mod_manager
달리 언급된 경우를 제외하고 mod_manager 지시문의 컨텍스트는 VirtualHost입니다. 서버 설정 컨텍스트는 지시문이 VirtualHost 구성을 벗어나야 함을 의미합니다. 그렇지 않으면 오류 메시지가 표시되고 Apache HTTP Server가 시작되지 않습니다.
표 A.133. mod_manager 지시문
지시문 | 설명 | 값 |
---|---|---|
EnableMCPMReceive | VirtualHost가 노드에서 MCPM 을 수신하도록 허용합니다. mod_cluster가 작동할 수 있도록 Apache HTTP Server 구성에 EnableMCPMReceive 를 포함합니다. 알림을 구성하는 VirtualHost에 저장합니다. | |
MemManagerFile | mod_manager 가 구성을 저장하는 데 사용하는 이름의 기본 이름은 공유 메모리 또는 잠긴 파일에 대한 키를 생성합니다. 이 이름은 절대 경로 이름이어야 합니다. 필요한 경우 디렉터리가 생성됩니다. 이러한 파일을 NFS 공유가 아닌 로컬 드라이브에 배치하는 것이 좋습니다. 컨텍스트: 서버 구성 |
|
Maxcontext | mod_cluster에서 지원하는 최대 컨텍스트 수입니다. 컨텍스트: 서버 구성 |
기본값: |
Maxnode | mod_cluster에서 지원하는 최대 노드 수입니다. 컨텍스트: 서버 구성 |
기본값: |
Maxhost | mod_cluster에서 지원하는 최대 호스트 수 또는 별칭입니다. 최대 밸런서 수도 포함합니다. 컨텍스트: 서버 구성 |
기본값: |
Maxsessionid | mod_cluster-manager 핸들러에서 활성 세션 수를 제공하기 위해 저장된 활성 sessionid 수입니다. mod_cluster가 5분 이내에 세션에서 정보를 받지 못하면 세션이 비활성화됩니다. 컨텍스트: 서버 구성. 이 필드는 데모 및 디버깅 목적으로만 사용됩니다. |
|
MaxMCMPMaxMessSize | 다른 Max 지시문의 최대 MCMP 메시지 크기 |
다른 Max 지시문에서 계산. 최소: |
ManagerBalancerName | JBoss EAP 인스턴스가 밸런서 이름을 제공하지 않을 때 사용할 밸런서 이름입니다. | mycluster |
PersistSlots | 파일에 노드, 별칭 및 컨텍스트를 유지하도록 mod_slotmem에 지시합니다. 컨텍스트: 서버 구성 | 꺼짐 |
CheckNonce | mod_cluster-manager 핸들러를 사용할 때 nonce 검사를 전환합니다. | 켜기/끄기 기본값: on - Nonce가 확인됨 |
AllowDisplay | mod_cluster-manager 메인 페이지에서 추가 디스플레이를 전환합니다. | 켜기/끄기 기본값: off - 버전만 표시됩니다. |
AllowCmd | mod_cluster-manager URL을 사용하여 명령을 허용합니다. | 기본값 켜기: on - 명령 허용 |
ReduceDisplay | 페이지에 더 많은 노드를 표시할 수 있도록 기본 mod_cluster-manager 페이지에 표시된 정보를 줄입니다. | 켜기/끄기: off - 전체 정보가 표시됩니다. |
SetHandler mod_cluster-manager | 는 클러스터에서 mod_cluster가 표시되는 노드에 대한 정보를 표시합니다. 이 정보에는 일반 정보가 포함되며 활성 세션 수를 추가로 계산합니다. <Location /mod_cluster-manager> SetHandler mod_cluster-manager Require ip 127.0.0.1 </Location> | 기본값 켜기: off |
httpd.conf
에 정의된 위치에 액세스할 때 :
- 전송됨: 백엔드 서버로 전송된 POST 데이터에 해당합니다.
- 연결됨: mod_cluster 상태 페이지를 요청할 때 처리된 요청 수에 해당합니다.
- Num_sessions: mod_cluster 보고서가 활성화된 세션 수에 해당합니다(지난 5분 내에 요청이 있음). 이 필드는 Maxsessionid가 0이고 데모 및 디버깅 목적으로만 사용됩니다.
A.36. modcluster 하위 시스템 속성
modcluster
하위 시스템에는 다음과 같은 구조가 있습니다.
- load-provider=simple
- ssl
load-provider=dynamic
리소스를 사용하면 CPU, 세션, 힙, 메모리 및 가중치와 같은 요소를 구성하여 부하 분산 동작을 확인할 수 있습니다.
load-provider=simple
리소스를 사용하면 요소 특성으로 정적 상수만 설정할 수 있습니다. 이를 통해 사용자는 들어오는 HTTP 요청을 부하 분산하는 데 동적 또는 복잡한 규칙이 필요하지 않은 경우 유용합니다.
이러한 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/jboss-as-mod-cluster_3_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.134. 프록시 구성 옵션
속성 | Default | 설명 |
---|---|---|
advertise | true | 멀티캐스트 기반 광고 메커니즘을 사용할지 여부입니다. |
advertise-security-key | httpd 인스턴스에서 알림을 수신 대기하는 httpd 인스턴스와 JBoss EAP 서버 간의 공유 비밀입니다. | |
advertise-socket | 역방향 프록시에서 등록할 밸런서의 이름입니다. | |
auto-enable-contexts | true |
|
밸런서 |
역방향 프록시에서 등록할 밸런서의 이름입니다. 설정되지 않은 경우 기본값은 | |
커넥터 | mod_cluster 역방향 프록시가 연결할 Undertow 리스너의 이름입니다. | |
제외된 컨텍스트 |
역방향 프록시와의 등록에서 제외할 컨텍스트 목록입니다. 호스트가 표시되지 않으면 호스트는 | |
flush-packets | false | 웹 서버에 대한 패킷 플러시 활성화 여부. |
flush-wait | -1 |
httpd에서 패킷을 플러시하기 전에 대기하는 시간입니다. 최대 값은 |
리스너 | 역방향 프록시에 등록할 Undertow 리스너의 이름입니다. | |
load-balancing-group | 설정된 경우 요청이 로드 밸런서의 지정된 로드 밸런싱 그룹으로 전송됩니다. | |
max-attempts | 1 | 역방향 프록시가 포기하기 전에 지정된 요청을 작업자로 보내는 횟수입니다. |
node-timeout | -1 |
작업자에 대한 프록시 연결의 제한 시간(초)입니다. 이제 mod_cluster가 오류를 반환하기 전에 백엔드 응답을 기다리는 시간입니다. |
Ping | 10 | Pong 응답이 ping에 대기할 시간(초)입니다. |
프록시 |
| |
proxy-list |
프록시 목록. 형식은 | |
proxy-url | / | MCMP 요청에 대한 기본 URL입니다. |
session-draining-strategy | 기본값 |
웹 애플리케이션 배포 취소 중에 사용되는 세션 드레이닝 전략. 유효한 값은
|
load-provider=simple |
동적 로드 프로바이더가 없는 경우 사용할 로드 프로바이더입니다. 각 클러스터 구성원에게 부하 계수 | |
smax | -1 | httpd의 소프트 최대 유휴 연결 수. |
socket-timeout | 20 | 시간 초과 전에 httpd 프록시에서 MCMP 명령으로 응답할 때까지 대기하는 시간(초) 및 오류와 같이 프록시 플래그를 지정합니다. |
ssl-context |
mod_cluster에서 사용할 | |
status-interval | 10 |
STATUS 메시지가 애플리케이션 서버에서 역방향 프록시로 전송되는 시간(초)입니다. 허용되는 값은 |
sticky-session | true | 지정된 세션에 대한 후속 요청이 가능한 경우 동일한 노드로 라우팅해야 하는지 여부입니다. |
sticky-session-force | false | 밸런서가 정지된 노드로 요청을 라우팅할 수 없는 경우 역방향 프록시에서 오류를 반환해야 하는지 여부입니다. 고정 세션이 비활성화된 경우 이 설정은 무시됩니다. |
sticky-session-remove | false | 장애 조치(failover)에서 세션 정보를 제거합니다. |
stop-context-timeout | 10 | 컨텍스트에서 보류 중인 요청을 처리하거나 배포 가능한 컨텍스트에 대해 활성 세션을 삭제하는 데 대기하는 최대 시간(초)입니다. 배포 불가능한 컨텍스트의 경우 활성 세션을 삭제합니다. |
ttl | -1 |
smax 위의 유휴 연결의 경우 수명(초)입니다. 허용되는 값은 |
worker-timeout | -1 |
사용 가능한 작업자가 요청을 처리할 때까지 httpd에서 대기하는 시간 제한입니다. 허용되는 값은 |
표 A.135. load-provider=동적 설정 옵션
속성 | Default | 설명 |
---|---|---|
decay | 2 | 경기 침체. |
내역 | 9 | 역사. |
initial-load | 0 |
노드에서 보고한 초기 부하. 유효한 범위는 이 특성은 클러스터에 가입하는 동안 과부하를 방지하기 위해 새로 참여한 노드의 부하 값을 점진적으로 늘리는 데 도움이 됩니다.
|
표 A.136. custom-load-metric 속성 옵션
속성 | Default | 설명 |
---|---|---|
용량 | 1.0 | 지표의 용량입니다. |
클래스 | 사용자 지정 지표의 클래스 이름입니다. | |
속성 | 지표의 속성입니다. | |
가중치 | 1 | 지표의 가중치입니다. |
표 A.137. 로드 메트릭 속성 옵션
속성 | Default | 설명 |
---|---|---|
용량 | 1.0 | 지표의 용량입니다. |
속성 | 지표의 속성입니다. | |
type |
지표 유형입니다. 유효한 값은 | |
가중치 | 1 | 지표의 가중치입니다. |
표 A.138. SSL 속성 옵션
속성 | Default | 설명 |
---|---|---|
ca-certificate-file | 인증 기관. | |
ca-revocation-url | 인증 기관 취소 목록. | |
certificate-key-file | ${user.home}/.keystore | 인증서의 키 파일입니다. |
cipher-suite | 허용된 암호화 제품군. | |
key-alias | 키 별칭. | |
암호 | 변경 | 암호. |
프로토콜 | TLS | 활성화된 SSL 프로토콜입니다. |
A.37. mod_jk 작업자 속성
workers.properties
파일은 mod_jk가 클라이언트 요청을 전달하는 작업자의 동작을 정의합니다. workers.properties
파일은 다양한 애플리케이션 서버가 있는 위치와 워크로드의 균형을 유지하는 방법을 정의합니다.
속성의 일반 구조는 worker입니다.WORKER_NAME.DIRECTIVE
. WORKER_NAME
은 JBoss EAP undertow 하위 시스템에서
구성된 instance-id
와 일치해야 하는 고유한 이름입니다. DIRECTIVE
는 작업자에 적용할 설정입니다.
Apache mod_jk Load Balancers에 대한 설정 참조
템플릿은 로드 밸런서마다 기본 설정을 지정합니다. 로드 밸런서 설정 자체 내에서 템플릿을 재정의할 수 있습니다.
표 A.139. 글로벌 속성
속성 | 설명 |
---|---|
worker.list | mod_jk 에서 사용할 작업자 이름의 쉼표로 구분된 목록입니다. |
표 A.140. 필수 지시문
속성 | 설명 |
---|---|
type |
작업자 유형입니다. 기본 유형은 |
표 A.141. 로드 밸런싱 지시문
속성 | 설명 |
---|---|
balance_workers | 로드 밸런서에서 관리해야 하는 작업자 노드를 지정합니다. 동일한 로드 밸런서에 지시문을 여러 번 사용할 수 있습니다. 이는 쉼표로 구분된 작업자 노드 이름 목록으로 구성됩니다. |
sticky_session |
동일한 세션의 요청이 항상 동일한 작업자로 라우팅되는지 여부를 지정합니다. 기본값은 |
표 A.142. 연결 지시문
속성 | 설명 |
---|---|
호스트 |
백엔드 서버의 호스트 이름 또는 IP 주소입니다. 백엔드 서버는 |
port |
정의된 프로토콜 요청을 수신 대기하는 백엔드 서버 인스턴스의 포트 번호입니다. 기본값은 AJP13 작업자의 기본 수신 대기 포트인 |
ping_mode | 네트워크 상태에 대해 연결을 조사하는 조건입니다. 프로브는 CPing에 빈 AJP13 패킷을 사용하고, CPong이 응답해야 합니다. 지시문 플래그의 조합을 사용하여 조건을 지정합니다. 플래그는 쉼표 또는 공백으로 구분되지 않습니다. ping_mode는 C, P, I 및 A의 조합일 수 있습니다.
|
ping_timeout, connect_timeout, prepost_timeout, connection_ping_interval |
위의 연결 프로브 설정에 대한 시간 제한 값입니다. 값은 밀리초 단위로 지정되며 |
lbfactor |
개별 백엔드 서버 인스턴스에 대한 로드 밸런싱 인수를 지정합니다. 이 기능은 보다 강력한 서버를 더 많은 워크로드를 제공하는 데 유용합니다. 작업자에게 기본 로드의 3배를 제공하려면 이를 |
아래 예제에서는 포트 8009
에서 수신 대기하는 두 개의 작업자 노드인 node1
과 node2
간에 고정 세션을 사용한 로드 밸런싱을 보여줍니다.
예: workers.properties
파일
# Define list of workers that will be used for mapping requests worker.list=loadbalancer,status # Define Node1 # modify the host as your host IP or DNS name. worker.node1.port=8009 worker.node1.host=node1.mydomain.com worker.node1.type=ajp13 worker.node1.ping_mode=A worker.node1.lbfactor=1 # Define Node2 # modify the host as your host IP or DNS name. worker.node2.port=8009 worker.node2.host= node2.mydomain.com worker.node2.type=ajp13 worker.node2.ping_mode=A worker.node2.lbfactor=1 # Load-balancing behavior worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 # Status worker for managing load balancer worker.status.type=status
Apache mod_jk에 대한 추가 구성 세부 정보는 이 문서의 범위를 벗어나며 Apache 설명서에서 확인할 수 있습니다.
A.38. 보안 관리자 하위 시스템 속성
security-manager
하위 시스템 자체에는 구성 가능한 특성이 없지만 구성 가능한 특성 deployment-permissions=default
가 있는 하위 리소스가 하나 있습니다.
이 테이블의 특성 이름은 관리 CLI를 사용하는 경우와 같이 관리 모델에 표시되는 대로 나열됩니다. 관리 모델과 다를 수 있으므로 EAP_HOME/docs/schema/wildfly-security-manager_1_0.xsd
에 있는 스키마 정의 파일을 참조하여 XML에 표시되는 요소를 확인합니다.
표 A.143. Deployment-permissions 구성 옵션
속성 | 설명 |
---|---|
최대 권한 | 배포 또는 JAR에 부여할 수 있는 최대 권한 집합입니다. |
최소 권한 | 배포 또는 JAR에 부여할 최소 권한 집합입니다. |
A.39. JBoss Core Services에서 OpenSSL 설치
JBoss Core Services OpenSSL 파일은 ZIP 또는 RPM 배포판에서 설치할 수 있습니다. 선택한 설치 방법에 따라 다음 단계를 따르십시오.
Red Hat Enterprise Linux 8에서 표준 시스템 OpenSSL이 지원되므로 JBoss Core Services에서 OpenSSL을 설치할 필요가 없습니다.
JBoss Core Services OpenSSL ZIP 파일 배포 사용
ZIP 아카이브의 libs/
디렉토리 경로는 Linux용 jbcs-openssl-VERSION/openssl/lib(64)
이고 Windows용 jbcs-openssl-VERSION/openssl/bin
입니다.
- 운영 체제 및 아키텍처와 관련된 소프트웨어 다운로드 페이지에서 OpenSSL 패키지를 다운로드합니다.
- 다운로드한 ZIP 파일을 설치 디렉토리로 추출합니다.
OpenSSL 라이브러리 찾을 위치를 JBoss EAP에 알립니다.
다음 방법 중 하나를 사용하여 이 작업을 수행할 수 있습니다. 다음 각 명령에서
JBCS_OPENSSL_PATH
를 JBoss Core Services OpenSSL 라이브러리 경로(예:/opt/rh/jbcs-httpd24/root/usr/lib64)로 바꿉니다.
다음 인수를 사용하여
standalone.conf 또는
구성 파일의domain.conf
JAVA_OPTS
변수에 OpenSSL 경로를 추가할 수 있습니다.JAVA_OPTS="$JAVA_OPTS -Dorg.wildfly.openssl.path=JBCS_OPENSSL_PATH
다음 관리 CLI 명령을 사용하여 OpenSSL 경로를 지정하는 시스템 속성을 정의할 수 있습니다.
/system-property=org.wildfly.openssl.path:add(value=JBCS_OPENSSL_PATH)
중요사용하는 메서드에 관계없이
JAVA_OPTS
값 또는 시스템 속성을 적용하려면 서버를 다시 시작해야 합니다. 서버 다시 로드만으로는 충분하지 않습니다.
JBoss Core Services OpenSSL RPM Distribution 사용
시스템이 JBoss Core Services 채널에 등록되어 있는지 확인합니다.
운영 체제 버전 및 아키텍처의 JBoss Core Services CDN 리포지토리 이름을 확인합니다.
- RHEL 6: jb-coreservices-1-for-rhel-6-server-rpms
- RHEL 7: jb-coreservices-1-for-rhel-7-server-rpms
시스템에서 리포지토리를 활성화합니다.
# subscription-manager repos --enable REPO_NAME
다음 메시지가 표시되는지 확인합니다.
Repository REPO_NAME is enabled for this system.
이 채널에서 OpenSSL을 설치합니다.
# yum install jbcs-httpd24-openssl
-
설치가 완료되면 JBCS OpenSSL 라이브러리는
/opt/rh/jbcs-httpd24/root/usr/lib64
또는 x86 아키텍처의/opt/rh/jbcs-httpd24/root/usr/lib
에서만 사용할 수 있습니다. OpenSSL 라이브러리 찾을 위치를 JBoss EAP에 알립니다.
다음 방법 중 하나를 사용하여 이 작업을 수행할 수 있습니다. 다음 각 명령에서
JBCS_OPENSSL_PATH
를 JBoss Core Services OpenSSL 라이브러리 경로(예:/opt/rh/jbcs-httpd24/root/usr/lib64)로 바꿉니다.
서비스 구성 파일에서
eap7-standalone 또는
설정에 대한eap7-
domainWILDFLY_OPTS
변수를 업데이트할 수 있습니다.WILDFLY_OPTS="$WILDFLY_OPTS -Dorg.wildfly.openssl.path=JBCS_OPENSSL_PATH"
다음 관리 CLI 명령을 사용하여 OpenSSL 경로를 지정하는 시스템 속성을 정의할 수 있습니다.
/system-property=org.wildfly.openssl.path:add(value=JBCS_OPENSSL_PATH)
중요사용하는 방법에 관계없이
WILDFLY_OPTS
값 또는 시스템 속성을 적용하려면 서버 재시작을 수행해야 합니다. 서버 다시 로드만으로는 충분하지 않습니다.
A.40. OpenSSL을 사용하도록 JBoss EAP 구성
OpenSSL을 사용하도록 JBoss EAP를 구성하는 방법에는 여러 가지가 있습니다.
기본적으로 모든 경우에 사용하도록 OpenSSL 우선 순위를 제공하도록
elytron
하위 시스템을 재구성할 수 있습니다.참고OpenSSL은
elytron
하위 시스템에 설치되어 있지만 기본 TLS 프로바이더는 아닙니다./subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers) /subsystem=elytron:undefine-attribute(name=final-providers) reload
elytron
하위 시스템에서 OpenSSL 프로바이더를ssl-context
리소스에 지정할 수도 있습니다. 이렇게 하면 기본 우선 순위를 사용하는 대신 OpenSSL 프로토콜을 사례별로 선택할 수 있습니다.ssl-context
리소스를 생성하고 Elytron 기반 SSL/TLS 구성에서 OpenSSL 라이브러리를 사용하려면 다음 명령을 사용합니다./subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=localhost-manager, trust-manager=ca-manager, provider-name=openssl) reload
레거시
보안
하위 시스템 SSL/TLS 구성에서 OpenSSL 라이브러리를 사용하려면 다음을 수행합니다./core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol,value=openssl.TLSv1.2) reload
사용할 수 있는 다양한 OpenSSL 프로토콜은 다음과 같습니다.
- openssl.TLS
- openssl.TLSv1
- openssl.TLSv1.1
- openssl.TLSv1.2
JBoss EAP는 시스템에서 OpenSSL 라이브러리를 자동으로 검색하여 사용합니다. JBoss EAP를 시작하는 동안 org.wildfly.openssl.path
속성을 사용하여 사용자 지정 OpenSSL 라이브러리 위치를 지정할 수도 있습니다. JBoss Core Services에서 제공하는 OpenSSL 라이브러리 버전 1.0.2 이상만 지원됩니다.
OpenSSL이 올바르게 로드되면 다음과 같이 JBoss EAP를 시작하는 동안 server.log
에 메시지가 표시됩니다.
15:37:59,814 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-7) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2k-fips 23 Mar 2017
A.41. Java 8용으로 제공되는 플랫폼 모듈
-
java.base
: 이 종속성은 항상 제공된 모듈 로더에 포함됩니다. -
java.compiler
-
java.datatransfer
-
java.desktop
-
java.instrument
-
java.jnlp
-
java.logging
-
java.management
-
java.management.rmi
-
java.naming
-
java.prefs
-
java.rmi
-
java.scripting
java.se
: 이 모듈 별칭은 다음 기본 모듈 세트를 집계합니다.-
java.compiler
-
java.datatransfer
-
java.desktop
-
java.instrument
-
java.logging
-
java.management
-
java.management.rmi
-
java.naming
-
java.prefs
-
java.rmi
-
java.scripting
-
java.security.jgss
-
java.security.sasl
-
java.sql
-
java.sql.rowset
-
java.xml
-
java.xml.crypto
-
-
java.security.jgss
-
java.security.sasl
-
java.smartcardio
-
java.sql
-
java.sql.rowset
-
java.xml
-
java.xml.crypto
-
javafx.base
-
javafx.controls
-
javafx.fxml
-
javafx.graphics
-
javafx.media
-
javafx.swing
-
javafx.web
-
jdk.accessibility
-
jdk.attach
-
jdk.compiler
-
jdk.httpserver
-
jdk.jartool
-
jdk.javadoc
-
jdk.jconsole
-
jdk.jdi
-
jdk.jfr
-
jdk.jsobject
-
jdk.management
-
jdk.management.cmm
-
jdk.management.jfr
-
jdk.management.resource
-
jdk.net
-
jdk.plugin.dom
-
jdk.scripting.nashorn
-
jdk.sctp
-
jdk.security.auth
-
jdk.security.jgss
-
jdk.unsupported
-
jdk.xml.dom
A.42. 검증 타이밍 방법 비교
validate-on-match
및 background-validation
방법의 다양한 측면을 비교하여 데이터베이스 연결 유효성 검사를 구성하는 데 적합한 방법을 확인할 수 있습니다.
다음 표에는 유효성 검사 타이밍 방법에 대한 비교 매트릭스가 포함되어 있습니다.
표 A.144. 유효성 검사 타이밍 방법에 대한 비교 매트릭스
비교 측면 | validate-on-match 방법 | background-validation 방법 |
신뢰성 |
|
백그라운드 검증 방법이 자주 실행되는 경우 유효성 검사는 애플리케이션에서 사용하기 위해 예약하지 않는 풀의 해당 연결에 대해서만 수행됩니다. 또한 풀에서 확인되지 않은 연결을 테스트하는 데 유효성 검사가 수행되지 않음을 의미합니다. |
성능: 시스템 사용, 네트워크 성능, 연결 문제의 타이밍 및 범위에 따라 |
장기간 동안 유휴 상태로 유지되는 시스템 사용자는
JDBC 4 검증 메커니즘과 같이 보다 효율적인 검증 메커니즘을 사용하는 시스템 사용자는
풀의 대부분의 연결 또는 전체에 영향을 미치는 광범위한 중단 이후 |
긴 기간 동안 유휴 상태로 유지되는 시스템의 사용자는
JDBC 4 검증 메커니즘과 같이 보다 효율적인 유효성 검사 메커니즘이 있는 시스템 사용자는
풀의 대부분의 연결 또는 전체에 영향을 미치는 광범위한 중단 이후 |
내결함성 코딩 |
오류가 있는 경우 애플리케이션의 풀에서 연결을 가져온 후에도 연결이 어느 시점에서나 외부로 종료될 수 있기 때문에
|
오류가 있을 경우 애플리케이션에서 연결을 가져온 후에도 모든 지점에서 연결이 외부로 종료될 수 있으므로
|
2024-02-09에 최종 업데이트된 문서