구성 가이드

Red Hat JBoss Enterprise Application Platform 7.4

애플리케이션 및 서비스 실행을 포함한 Red Hat JBoss Enterprise Application Platform의 설정 및 유지 관리 지침.

초록

이 가이드의 목적은 JBoss EAP를 설정하고 유지 관리하는 데 필요한 많은 구성 작업을 다루는 것은 물론, 애플리케이션과 기타 서비스를 실행하는 데 있습니다.

Red Hat 문서에 대한 피드백 제공

문서에 대한 의견을 보내 주셔서 감사합니다. 피드백을 제공하기 위해 문서의 텍스트를 강조 표시하고 주석을 추가할 수 있습니다. Red Hat 설명서에 대한 피드백을 제출하는 방법을 알아보려면 절차의 단계를 따르십시오.

사전 요구 사항

  • Red Hat 고객 포털에 로그인합니다.
  • Red Hat 고객 포털에서 다중 페이지 HTML 형식으로 문서를 봅니다.

절차

  1. 피드백 (Fedback)을 클릭하여 기존 reader 주석을 확인합니다.

    참고

    피드백 기능은 다중 페이지 HTML 형식으로만 활성화됩니다.

  2. 피드백을 제공할 문서의 섹션을 강조 표시합니다.
  3. 선택한 텍스트 옆에 표시되는 프롬프트 메뉴에서 Add Feedback(피드백 추가 )을 클릭합니다.

    텍스트 상자가 페이지 오른쪽에 있는 피드백 섹션에 열립니다.

  4. 텍스트 상자에 피드백을 입력하고 Submit(제출 )을 클릭합니다.

    설명서 문제가 생성되어 있습니다.

  5. 이 문제를 보려면 피드백 보기에서 문제 추적기 링크를 클릭합니다.

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

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를 사용하여 실행 중인 인스턴스에 연결하고 서버를 종료합니다.

  1. 관리 CLI를 시작합니다.

    $ EAP_HOME/bin/jboss-cli.sh --connect
  2. 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 및 restart-servers 작업에 start- mode 인수를 전달할 수도 있습니다.

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. 관리 사용자 추가

  1. add-user 유틸리티 스크립트를 실행하고 프롬프트를 따릅니다.

    $ EAP_HOME/bin/add-user.sh
    참고

    Windows Server의 경우 EAP_HOME\bin\add-user.bat 스크립트를 사용합니다.

  2. ENTER를 눌러 기본 옵션 a 를 선택하여 관리 사용자를 추가합니다.

    이 사용자는 ManagementRealm에 추가되며 관리 콘솔 또는 관리 CLI를 사용하여 관리 작업을 수행할 수 있는 권한이 부여됩니다. 다른 선택 사항인 b 는 애플리케이션에 사용되고 특정 권한을 제공하지 않는 사용자를 ApplicationRealm 에 추가합니다.

  3. 원하는 사용자 이름과 암호를 입력합니다. 암호를 확인하라는 메시지가 표시됩니다.

    참고

    사용자 이름에는 어떤 숫자와 순서에 관계없이 다음 문자만 사용할 수 있습니다.

    • 영숫자 문자(a-z, A-Z, 0-9)
    • 대시(-), 마침표(.), 쉼표(,), 기호(@)
    • 백슬래시 (\)
    • 같음 (=)

    기본적으로 JBoss EAP는 취약한 암호를 허용하지만 경고를 발행합니다.

    이 기본 동작 변경에 대한 자세한 내용은 Add-User Utility Password Restrictions 설정을 참조하십시오.

  4. 사용자가 속해 있는 쉼표로 구분된 그룹 목록을 입력합니다. 사용자가 어떤 그룹에도 속하지 않도록 하려면 ENTER를 눌러 비워 둡니다.
  5. 정보를 검토하고 yes 를 입력하여 확인합니다.
  6. 이 사용자가 원격 JBoss EAP 서버 인스턴스를 나타내는지 여부를 확인합니다. 기본 관리 사용자의 경우 no 를 입력합니다.

    ManagementRealm 에 추가해야 하는 한 가지 유형의 사용자는 JBoss EAP의 다른 인스턴스를 나타내는 사용자로서, 클러스터의 구성원으로 조인하도록 인증할 수 있어야 합니다. 이 경우 이 프롬프트에 yes 로 응답하고, 다른 구성 파일에 추가해야 하는 사용자의 암호를 나타내는 해시된 시크릿 값이 제공됩니다.

매개 변수를 add-user 스크립트에 전달하여 비대화형으로 사용자를 만들 수도 있습니다. 암호는 로그 및 기록 파일에 표시되므로 공유 시스템에서는 이 방법을 사용하지 않는 것이 좋습니다. 자세한 내용은 Add-User Utility Non-Interactively 에서 참조하십시오.

3.2.2. Add-User Utility를 비대화식으로 실행

명령줄에서 인수를 전달하여 add-user 스크립트를 비대화식으로 실행할 수 있습니다. 최소한 사용자 이름과 암호를 입력해야 합니다.

주의

암호는 로그 및 기록 파일에 표시되므로 공유 시스템에서는 이 방법을 사용하지 않는 것이 좋습니다.

여러 그룹에 의존하는 사용자 만들기

다음 명령은 guestmgmt 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. 추가 암호 요구 사항 설정

속성설명

minLength

암호에 대한 최소 문자 수입니다. 예를 들어 password.restriction.minLength=8 은 암호를 최소 8자로 제한합니다.

strength

암호가 유효하도록 충족해야 하는 임계값을 설정합니다. 유효한 임계값 항목은 다음과 같습니다.

* VERY_WEAK

* 약함

* 보통

* 중간

* 강력

* VERY_STRONG

* 예외

기본값은 MODERATE 입니다. 임계값은 정의되고 클래스 SimplePasswordStrengthChecker 에 지정된 기본값입니다.

알림: 임계값 값을 지정하지 않으면 MODERATE 가 기본값이 됩니다. 이 값은 SimplePasswordStrengthChecker 클래스에 지정됩니다.

minAlpha

암호에 설정된 최소 알파벳 문자 수입니다. 예를 들어 password.restriction.minAlpha=1 은 하나의 알파벳 문자를 포함하도록 암호를 제한합니다.

minDigit

암호에 설정된 최소 숫자 수입니다. 예를 들어 password.restriction.minDigit=1 은 하나 이상의 숫자 문자를 포함하도록 암호를 제한합니다.

minSymbol

암호에 설정된 최소 기호 수입니다. 예를 들어 password.restriction.minSymbol=1 은 하나 이상의 기호를 포함하도록 암호를 제한합니다.

forbiddenValue

사용자가 root 와 같이 쉽게 결정된 암호를 설정하지 못하도록 제한합니다. 예를 들어 password.restriction.forbidden=root,admin,administrator 는 암호로 root,admin 또는 administrator 설정을 제한합니다.

mustNotMatchUsername

사용자가 사용자 이름을 암호로 설정하지 못하도록 제한합니다. 예를 들어, password.restriction.mustNotMatchUsername=TRUE 는 사용자가 사용자 이름을 암호로 설정하지 못하도록 제한합니다. false 로 설정된 경우 이 규칙은 무시됩니다.

추가 리소스

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. 관리 콘솔에서 속성 업데이트

수정할 리소스에 대해 관리 콘솔의 해당 섹션으로 이동한 후 적절한 권한이 있는 한 해당 속성을 편집할 수 있습니다.

  1. Edit(편집) 링크를 클릭합니다.
  2. 원하는 대로 변경합니다.

    필수 필드는 별표(*)로 표시됩니다. 도움말 링크를 클릭하여 특성 설명을 볼 수 있습니다.

    참고

    특성 유형에 따라 입력 필드는 텍스트 필드, ON/OFF 필드 또는 드롭다운일 수 있습니다. 입력하는 일부 텍스트 필드에는 구성의 다른 항목의 값이 제안으로 표시될 수 있습니다.

  3. Save(저장 )를 클릭하여 변경 사항을 저장합니다.
  4. 필요한 경우 서버를 다시 로드하여 변경 사항을 적용합니다.

    적용하기 위해 다시 로드해야 하는 변경 사항을 저장할 때 팝업 창이 표시됩니다. 독립 실행형 서버를 다시 로드하려면 팝업에서 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)
관리 콘솔의 언어 변경
  1. 관리 콘솔에 로그인합니다.
  2. 관리 콘솔의 오른쪽 아래에 있는 Settings (설정) 링크를 클릭합니다.
  3. Locale(로케일) 선택 상자에서 필수 언어를 선택합니다.
  4. 저장을 선택합니다. 확인 상자는 애플리케이션을 다시 로드해야 함을 알려줍니다.
  5. Yes 를 클릭합니다. 선택한 로케일을 사용하도록 웹 브라우저를 자동으로 새로 고칩니다.

3.4.2.4. 관리 콘솔 제목 사용자 정의

각 JBoss EAP 인스턴스를 빠르게 식별할 수 있도록 관리 콘솔 제목을 사용자 지정할 수 있습니다.

관리 콘솔 제목을 사용자 지정하려면 다음을 수행합니다.

  1. 관리 콘솔에 로그인합니다.
  2. 관리 콘솔의 오른쪽 아래에 있는 Settings (설정)를 클릭합니다.
  3. Settings(설정 ) 창에서 Title (제목) 필드에서 제목을 수정합니다.
  4. 저장을 클릭합니다.

    확인 상자는 관리 콘솔을 다시 로드해야 함을 알려줍니다.

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

읽기-attribute 작업을 수행합니다.

operations-description

read-operation-description 작업을 수행합니다.

operation-names

read-operation-names 작업을 수행합니다.

resource

read-resource 작업을 수행합니다.

resource-description

read-resource-description 작업을 수행합니다.

스냅샷

list-snapshots 작업을 수행합니다.

다음 예제 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 헤더는 엔드포인트가 요청에 대한 응답을 처리하는 방법을 변경하지 않습니다.

절차

  1. 사용자 정의 일관성 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 작업을 사용하면 다시 로드해야 하는 프롬프트가 표시됩니다.

  2. 변경 사항을 적용하기 위해 서버를 다시 로드합니다.

    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. 독립 실행형 구성 파일

설정 파일목적

standalone.xml

이 독립 실행형 구성 파일은 독립 실행형 서버를 시작할 때 사용되는 기본 구성입니다. 하위 시스템, 네트워킹, 배포, 소켓 바인딩 및 기타 구성 가능한 세부 정보를 포함하여 서버에 대한 모든 정보가 포함되어 있습니다. 메시징 또는 고가용성에 필요한 하위 시스템을 제공하지 않습니다.

standalone-ha.xml

이 독립 실행형 구성 파일에는 모든 기본 하위 시스템이 포함되어 있으며 고가용성에 대해 modclusterjgroups 하위 시스템을 추가합니다. 이는 메시징에 필요한 하위 시스템을 제공하지 않습니다.

standalone-full.xml

이 독립 실행형 구성 파일에는 모든 기본 하위 시스템이 포함되어 있으며 messaging-activemqiiop-openjdk 하위 시스템을 추가합니다. 고가용성에 필요한 하위 시스템을 제공하지 않습니다.

standalone-full-ha.xml

이 독립 실행형 구성 파일에는 메시징 및 고가용성에 대한 시스템을 포함하여 가능한 모든 하위 시스템에 대한 지원이 포함되어 있습니다.

standalone-load-balancer.xml

이 독립 실행형 구성 파일에는 기본 제공 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. 관리형 도메인 구성 파일

설정 파일목적

domain.xml

관리형 도메인의 기본 구성 파일입니다. 도메인 마스터만 이 파일을 읽습니다. 이 파일에는 모든 프로필(default,ha, full,full -ha,load-balancer )에 대한 구성이 포함되어 있습니다.

host.xml

이 파일에는 네트워크 인터페이스, 소켓 바인딩, 호스트 이름 및 기타 호스트별 세부 정보와 같이 관리형 도메인의 실제 호스트와 관련된 구성 세부 정보가 포함됩니다. host.xml 파일에는 아래 설명된 host -master.xmlhost-slave.xml 의 모든 기능이 포함되어 있습니다.

host-master.xml

이 파일에는 서버를 마스터 도메인 컨트롤러로 실행하는 데 필요한 구성 세부 사항만 포함되어 있습니다.

host-slave.xml

이 파일에는 서버를 관리형 도메인 호스트 컨트롤러로 실행하는 데 필요한 구성 세부 정보만 포함되어 있습니다.

기본적으로 관리형 도메인에서 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)
스냅샷으로 서버 시작

서버는 스냅샷 또는 자동 저장한 구성 버전을 사용하여 시작할 수 있습니다.

  1. EAP_HOME/standalone/configuration/standalone_xml_history 디렉터리로 이동하여 로드할 스냅샷 또는 저장된 구성 파일을 식별합니다.
  2. 서버를 시작하고 선택한 구성 파일을 가리킵니다. 구성 디렉터리인 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 매개 변수를 설정하지 않는 한 공용 인터페이스의 inet- address127.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 리포지토리에 연결할 수 있습니다.

사전 요구 사항

절차

  • 터미널에서 다음 명령을 실행하여 원격 git SSH 리포지토리에 연결합니다.

    $ <eap_home_path>/bin/standalone.sh --git-repo=<git_repository_url> --git-auth=<elytron_configuration_file_url>

    독립 실행형 서버가 시작되고 서버의 구성 파일 기록이 이제 원격 Git SSH 리포지토리에서 관리합니다.

추가 리소스

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>
      1
      ssh-directory 속성은 키의 위치와 알려진 호스트 파일을 지정합니다.
      2
      private-key-file 속성은 개인 키가 포함된 파일의 이름을 지정합니다.
      3
      known-hosts-file 속성은 알려진 SSH 호스트가 포함된 파일의 이름을 지정합니다.

추가 리소스

  • 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.temp.dir 및 독립 실행형 서버의 jboss.server.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 를 참조하십시오.

다음 지침은 NATIVEHTTP 감사 로깅을 활성화합니다. 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 감사 로깅을 활성화할 수 있습니다.

호스트에 대한 자카르타 관리 감사 로깅 활성화

  1. 호스트의 jmx 하위 시스템에서 감사 로깅을 활성화합니다.

    /host=HOST_NAME/subsystem=jmx/configuration=audit-log:add()
  2. jmx 하위 시스템에 대한 감사 로깅이 활성화되면 다음 명령을 사용하여 호스트에 대해 핸들러를 정의할 수 있습니다.

    /host=HOST_NAME/subsystem=jmx/configuration=audit-log/handler=host-file:add()

    기본적으로 Jakarta Management 감사 로그를 EAP_HOME/domain/data/audit-log.log 에 씁니다.

프로필에 대한 자카르타 관리 감사 로깅 활성화

  1. 프로필의 jmx 하위 시스템에서 감사 로깅을 활성화합니다.

    /profile=PROFILE_NAME/subsystem=jmx/configuration=audit-log:add()
  2. 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 를 참조하십시오.

  1. 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)
  2. syslog 핸들러에 대한 참조를 추가합니다.

    관리형 도메인에서 이 명령 앞에 /host=HOST_NAME 을 사용해야 합니다.

    /core-service=management/access=audit/logger=audit-log/handler=SYSLOG_HANDLER_NAME:add
  3. 감사 로깅을 활성화합니다.

    감사 로깅을 활성화하려면 관리 감사 로깅 활성화 를 참조하십시오.

중요

운영 체제에서도 로깅을 활성화하지 않는 한 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. 관리 감사 로그 필드

필드 이름설명

액세스

다음 값 중 하나가 있을 수 있습니다.

  • NATIVE - 네이티브 관리 인터페이스를 통해 작업이 수행되었습니다.
  • HTTP - 도메인 HTTP 인터페이스를 통해 작업이 완료되었습니다.
  • JMX - 작업은 jmx 하위 시스템을 통해 제공되었습니다.

부팅 중

부팅 프로세스 중에 작업이 실행된 경우 값이 true 이며 서버가 실행되면 실행된 경우 false 입니다.

domainUUID

도메인 컨트롤러에서 서버, 슬레이브 호스트 컨트롤러 및 슬레이브 호스트 컨트롤러 서버로 전파되는 모든 작업을 함께 연결하는 ID입니다.

ops

실행 중인 작업입니다. JSON으로 직렬화된 작업 목록입니다. 부팅 시 XML 구문 분석이 수행되는 작업입니다. 부팅되고 나면 목록에는 일반적으로 단일 항목이 포함됩니다.

r/o

는 작업에서 관리 모델을 변경하지 않는 경우 true 이며, 값이 있으면 false입니다.

remote-address

이 작업을 실행하는 클라이언트의 주소입니다.

success

는 작업이 성공한 경우 true, 롤백된 경우 false입니다.

type

이 값은 관리 작업 또는 jmx 하위 시스템에서 제공된 값 core를 가질 수 있습니다.

user

인증된 사용자의 사용자 이름. 실행 중인 서버와 동일한 시스템에서 관리 CLI를 사용하여 작업이 발생한 경우 특수 사용자 $local 이 사용됩니다.

버전

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 하위 시스템에 리스너를 등록하여 서버 라이프사이클 이벤트를 모니터링할 수 있습니다. 다음 단계에서는 이벤트를 파일에 기록하는 예제 리스너를 만들고 등록하는 방법을 보여줍니다.

  1. 리스너를 생성합니다.

    아래 예제와 같이 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 내에서 제대로 로드, 초기화 및 제거할 수 있는지 확인해야 합니다.
    • 리스너에 대한 알림은 서버 상태 변경에 대한 대응을 허용하기 위해 차단됩니다. 구현은 차단 또는 교착 상태가 되지 않도록 해야 합니다.
    • 각 리스너 인스턴스는 자체 스레드에서 실행되며 순서가 보장되지 않습니다.
  2. 클래스를 컴파일하고 JAR로 패키징합니다.

    컴파일하려면 org.wildfly.core:wildfly-core-management-client Maven 모듈을 사용해야 합니다.

  3. 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 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.

  4. 리스너를 등록합니다.

    다음 관리 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 알림 리스너를 등록할 수 있습니다. 다음 단계에서는 이벤트를 파일에 기록하는 예제 리스너를 만들고 추가하는 방법을 보여줍니다.

  1. 리스너를 생성합니다.

    아래 예제와 같이 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);
        }
      }
    }

  2. 알림 리스너를 등록합니다.

    알림 리스너를 MBeanServer 에 추가합니다.

    예제: 알림 리스너 추가

    MBeanServer server = ManagementFactory.getPlatformMBeanServer();
    server.addNotificationListener(ObjectName.getInstance("jboss.root:type=state"), new StateNotificationListener(), null, null);

  3. 패키징 및 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.xmlhost.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 속성을 유지하여 런타임에 이 값을 설정할 수 있도록 공용 인터페이스의 기본 inet- address 값을 업데이트합니다.

/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를 사용하여 소켓 바인딩 설정을 구성합니다.

  1. 새 소켓 바인딩 그룹을 추가합니다. 독립 실행형 서버로 실행할 때는 이 단계를 수행할 수 없습니다.

    /socket-binding-group=new-sockets:add(default-interface=public)
  2. 소켓 바인딩을 추가합니다.

    /socket-binding-group=new-sockets/socket-binding=new-socket-binding:add(port=1234)
  3. 소켓 바인딩 그룹에서 설정한 기본값 이외의 인터페이스를 사용하도록 소켓 바인딩을 변경합니다.

    /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

서버의 소켓 바인딩 및 열려 있는 포트를 보려면 다음을 수행합니다.

  1. 관리 콘솔에 액세스하고 런타임 으로 이동합니다.
  2. 서버를 클릭하여 오른쪽 창에서 소켓 바인딩 이름과 열려 있는 포트를 확인합니다.

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 주소를 사용하도록 시작 구성을 업데이트합니다.

  1. 시작 구성 파일을 엽니다.

    • 독립 실행형 서버로 실행하는 경우 EAP_HOME/bin/standalone.conf 파일(또는 Windows Server의 경우 standalone.conf.bat )을 편집합니다.
    • 관리형 도메인에서 실행하는 경우 EAP_HOME/bin/domain.conf 파일(또는 Windows Server의 domain.conf.bat )을 편집합니다.
  2. java.net.preferIPv4Stack 속성을 false로 설정합니다.

    -Djava.net.preferIPv4Stack=false
  3. 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는 자체 인터페이스 및 서비스에 대한 보안을 구성하고 실행 중인 애플리케이션에 보안을 제공하는 기능을 제공합니다.

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를 사용하여 모듈을 생성할 수 있습니다.

모듈을 생성한 후에는 애플리케이션에서 해당 리소스를 사용할 수 있어야 하는 경우 모듈을 종속성으로 추가해야 합니다.

수동으로 사용자 정의 모듈 만들기

다음 단계를 사용하여 사용자 지정 모듈을 수동으로 생성할 수 있습니다.

  1. EAP_HOME/modules/ 디렉터리에 적절한 디렉터리 구조를 생성합니다.

    예제: MySQL JDBC 드라이버 디렉터리 구조 만들기

    $ cd EAP_HOME/modules/
    $ mkdir -p com/mysql/main

  2. JAR 파일 또는 기타 필요한 리소스를 main/ 하위 디렉터리에 복사합니다.

    예제: Copy MySQL JDBC Driver JAR

    $ cp /path/to/mysql-connector-java-8.0.12.jar EAP_HOME/modules/com/mysql/main/

  3. 파일에서 적절한 리소스와 종속성을 지정하여 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 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.

  1. JBoss EAP 서버 시작.
  2. 관리 CLI를 시작합니다.

    $ EAP_HOME/bin/jboss-cli.sh
  3. 모듈 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 를 실행할 수도 있습니다.

모듈을 종속성으로 추가합니다

애플리케이션이 이 모듈의 리소스에 액세스할 수 있으려면 모듈을 종속성으로 추가해야 합니다.

  • 모듈을 모든 애플리케이션에 대한 종속성으로 추가하는 방법은 글로벌 모듈 정의 섹션을 참조하십시오.

예를 들어 다음 단계에서는 여러 속성 파일이 포함된 JAR 파일을 모듈로 추가하고 글로벌 모듈을 정의하여 애플리케이션에서 이러한 속성을 로드할 수 있습니다.

  1. JAR 파일을 코어 모듈로 추가합니다.

    module add --name=myprops --resources=/path/to/properties.jar
  2. 이 모듈을 모든 배포에서 사용할 수 있도록 글로벌 모듈로 정의합니다.

    /subsystem=ee:list-add(name=global-modules,value={name=myprops})
  3. 그런 다음 애플리케이션은 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 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.

  1. JBoss EAP 서버 시작.
  2. 관리 CLI를 시작합니다.

    $ EAP_HOME/bin/jboss-cli.sh
  3. 모듈 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

    참고

    서버는 애플리케이션을 배포하고 글로벌 디렉터리를 로드하므로 서버의 라이브러리 버전을 재정의하도록 글로벌 디렉터리를 구성할 수 없습니다. 글로벌 디렉터리는 서버와 함께 제공된 라이브러리를 대체할 수 없습니다.

절차

  1. 서버 설정에 따라 글로벌 디렉터리를 생성합니다. 선택적 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 속성에 대한 시스템 경로 또는 사용자 정의 시스템 경로를 지정할 수 있습니다.

    참고

    관리형 도메인에서 서버를 실행하는 경우 글로벌 디렉터리의 콘텐츠가 모든 서버 인스턴스에서 일관되게 유지되는지 확인해야 합니다. 예를 들어 각 호스트에는 글로벌 디렉터리 콘텐츠가 포함된 로컬 파일 시스템 디렉터리가 포함되어야 합니다.

  2. 서버 인스턴스를 다시 로드하여 글로벌 디렉터리를 활성화합니다.

    서버가 루트 디렉토리부터 시작하여 각 하위 디렉터리 수준을 포함하여 디렉터리 트리의 콘텐츠를 알파벳순으로 스캔할 수 있도록 서버를 다시 로드해야 합니다. 서버는 각 디렉터리 수준의 파일을 알파벳순으로 JBoss Modules 모듈 종속성에 추가합니다.

    글로벌 디렉터리의 내용을 변경하거나 글로벌 디렉터리에서 JAR 파일을 변경하거나 추가하는 경우 배포된 애플리케이션에서 변경할 수 있도록 서버를 다시 로드해야 합니다. 예를 들어 글로벌 디렉터리에서 JAR 라이브러리를 교체하는 경우 서버를 다시 로드하여 글로벌 디렉터리를 다시 스캔하고 배포된 애플리케이션을 변경된 JAR 라이브러리로 업데이트합니다.

추가 리소스

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 를 환경 변수로 설정할 수도 있습니다.

  1. 시작 구성 파일을 편집합니다.

    • 독립 실행형 서버로 실행하는 경우 EAP_HOME/bin/standalone.conf 파일을 편집하거나 Windows Server의 경우 standalone.conf.bat 를 편집합니다.
    • 관리형 도메인에서 실행하는 경우 EAP_HOME/bin/domain.conf 파일을 편집하거나 Windows Server의 경우 domain.conf.bat 를 편집합니다.
  2. 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.warstore.jar 는 각각 deployment .inventory.war 및 deployment. store.jar 의 모듈 이름을 가집니다.

  • EAR(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에서 참조하는 콘텐츠를 배포합니다.

배포 활성화 명령을 사용하여 비활성화된 애플리케이션을 활성화할 수도 있습니다.

애플리케이션 배포 취소

관리 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에서 참조하는 콘텐츠를 배포합니다.

배포 활성화 명령을 사용하여 비활성화된 애플리케이션을 활성화할 수도 있습니다.

애플리케이션 배포 취소

관리 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(콘텐츠 리포지토리) 섹션에 나열됩니다. 여기에 서버 그룹에 배포를 추가하고 배포할 수 있습니다.

  • 서버 그룹

    하나 이상의 서버 그룹에 배포된 배포는 서버 그룹 섹션에 나열됩니다. 배포를 활성화하고 여기에 서버 그룹에 직접 추가할 수 있습니다.

애플리케이션 추가
  1. Content Repository(콘텐츠 리포지토리 )에서 Add(추가) 버튼을 클릭합니다.
  2. 배포를 업로드하거나 관리되지 않는 배포를 추가하여 애플리케이션을 추가하도록 선택합니다.
  3. 프롬프트에 따라 애플리케이션을 배포합니다.

    배포를 활성화하려면 먼저 서버 그룹에 배포해야 합니다.

서버 그룹에 애플리케이션 배포
  1. Content Repository(콘텐츠 리포지토리 )에서 배포를 선택하고 Deploy (배포) 버튼을 클릭합니다.
  2. 이 배포를 배포해야 하는 하나 이상의 서버 그룹을 선택합니다.
  3. 선택적으로 옵션을 선택하여 선택한 서버 그룹에서 배포를 활성화합니다.
서버 그룹에서 애플리케이션 배포 취소
  1. Server Groups (서버 그룹)에서 적절한 서버 그룹을 선택합니다.
  2. 원하는 배포를 선택하고 Undeploy (배포 취소) 버튼을 클릭합니다.

Content Repository (콘텐츠 리포지토리)의 배포에 대한 Undeploy (배포 취소) 버튼을 한 번에 선택하여 여러 서버 그룹에서 배포를 취소할 수도 있습니다.

애플리케이션 제거
  1. 배포가 여전히 모든 서버 그룹에 배포되어 있으면 배포 배포를 취소해야 합니다.
  2. Content Repository(콘텐츠 리포지토리 )에서 배포를 선택하고 Remove (제거) 버튼을 클릭합니다.

그러면 콘텐츠 리포지토리에서 배포가 제거됩니다.

애플리케이션 비활성화
  1. Server Groups (서버 그룹)에서 적절한 서버 그룹을 선택합니다.
  2. 원하는 배포를 선택하고 Disable (비활성화) 버튼을 클릭합니다.

그러면 배포가 배포 취소되지만 콘텐츠 리포지토리에서 제거되지 않습니다.

애플리케이션 교체
  1. Content Repository(콘텐츠 리포지토리 )에서 배포를 선택하고 Replace (다시 교체) 버튼을 클릭합니다.
  2. 새 버전의 배포(원래와 이름이 동일해야 함)를 선택하고 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) 에서 액세스할 수 있습니다.

애플리케이션 배포
  1. 콘텐츠 리포지토리에 배포를 추가합니다.

    $ 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}'
  2. 원하는 서버 그룹에 배포를 추가합니다.

    $ 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}'
  3. 서버 그룹에 애플리케이션을 배포합니다.

    $ 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}'
애플리케이션 배포 취소
  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}'
  2. 콘텐츠 리포지토리에서 배포를 제거합니다.

    $ 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.ear 가 있는 경우 아래와 같이 app.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.earjboss-all.xml 파일을 생성하고 framework.ear를 배포하지 않으면 서버에서 app.ear 배포를 시도하고 실패합니다.

7.6.3. 배포 내용 덮어쓰기

배포 오버레이 를 사용하면 배포 아카이브의 내용을 물리적으로 수정하지 않고도 기존 배포로 컨텐츠를 오버레이할 수 있습니다. 이를 통해 아카이브를 다시 빌드하지 않고도 배포 설명자, 라이브러리 JAR 파일, 클래스, 자카르타 서버 페이지 및 기타 파일을 재정의할 수 있습니다.

이 기능은 다양한 구성 또는 설정이 필요한 다양한 환경에 맞게 배포를 조정해야 하는 경우에 유용합니다. 예를 들어 개발, 테스트에서 스테이징으로 애플리케이션 라이프사이클을 통해 배포를 이동할 때 배포 설명자를 스왑하거나 정적 웹 리소스를 수정하여 애플리케이션의 브랜딩을 변경하거나, JAR 라이브러리를 대상 환경에 따라 다른 버전으로 교체할 수 있습니다. 또한 구성을 변경해야 하지만 정책 또는 보안 제한으로 인해 아카이브를 수정하거나 손상시킬 수 없는 설치에 유용한 기능이기도 합니다.

배포 오버레이를 정의할 때 배포 아카이브의 파일을 대체할 파일 시스템에 파일을 지정합니다. 배포 오버레이의 영향을 받아야 하는 배포도 지정해야 합니다. 변경 사항을 적용하려면 영향을 받는 배포를 다시 배포해야 합니다.

매개 변수

다음 매개변수 중 하나를 사용하여 배포 오버레이를 구성할 수 있습니다.

  • name:: 배포 오버레이의 이름입니다.
  • content:: 파일 시스템의 파일을 대체하는 아카이브의 파일에 매핑하는 쉼표로 구분된 목록입니다. 각 항목의 형식은 ARCHIVE_PATH=FILESYSTEM_PATH 입니다.
  • 배포:: 이 오버레이가 연결되는 쉼표로 구분된 배포 목록입니다.
  • redeploy-affected:: 영향을 받는 모든 배포를 다시 배포합니다.

전체 사용 세부 정보는 deployment-overlay --help 를 실행합니다.

절차

  1. 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 로 모든 서버 그룹을 지정합니다.

  2. 배포 오버레이를 생성한 후 콘텐츠를 기존 오버레이에 추가하거나 오버레이를 배포에 연결하거나 오버레이를 제거할 수 있습니다.
  3. 선택 사항: 오버레이 구성을 지정하여 <overlay> 요소에서 정적 웹 리소스(예: HTML, 이미지 또는 동영상)를 포함하는 외부 디렉터리에 연결할 수 있습니다. <overlay> 요소는 애플리케이션 jboss-web.xml 파일에 있습니다. 이 구성을 사용하면 애플리케이션을 다시 패키징할 필요가 없습니다.

    다음 예제에서는 <overlay> 요소의 시스템 속성 대체를 보여줍니다. 여기서 ${example.path.to.overlay}/PATH/TO/STATIC/WEB/CONTENT 위치를 정의합니다.

    예: jboss-web.xml 파일의 <overlay> 요소

    <jboss-web>
            <overlay>${example.path.to.overlay}</overlay>
    </jboss-web>

    jboss-descriptor-property-replacementtrue 로 설정된 경우 설명자 속성의 기본값인 <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>

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단계로 수행됩니다. 모든 서버 그룹의 정책에서 서버 그룹 전체에서 작업 롤백을 트리거하면 기타 모든 서버 그룹도 롤백됩니다.

  1. 서버 그룹 group-Agroup-B 는 동시에 작업을 적용합니다. 이 작업은 일련의 그룹 A의 서버에 적용되는 반면 group- B 의 모든 서버는 동시에 작업을 처리합니다. A 그룹의 서버 20% 이상이 작업을 적용하지 못하면 해당 그룹으로 롤백됩니다. group-B 에 있는 서버가 작업을 적용하지 못하면 해당 그룹을 통해 롤백됩니다.
  2. group-Agroup-B 의 모든 서버가 완료되면 group-C 의 서버에 작업이 적용됩니다. 이러한 서버는 동시에 작업을 처리합니다. group-C 에서 둘 이상의 서버가 작업을 적용하지 못하면 해당 그룹을 통해 롤백됩니다.
  3. group-C 의 모든 서버가 완료되면 서버 그룹 group-Dgroup-E 는 동시에 작업을 적용합니다. 이 작업은 일련의 그룹 D에 있는 서버에 적용되는 반면 group-E 의 모든 서버는 동시에 작업을 처리합니다. group-D 에서 20% 이상의 서버가 작업을 적용하지 못하면 해당 그룹으로 롤백됩니다. group-E 에 있는 서버가 있는 서버가 작업을 적용하지 못하면 해당 그룹을 통해 롤백됩니다.
롤아웃 계획 구문

다음 방법 중 하나로 롤아웃 계획을 지정할 수 있습니다.

각 방법에 다른 초기 명령이 있지만 두 방법 모두 롤아웃 작업 헤더를 사용하여 롤아웃 계획을 정의합니다. 다음 구문을 사용합니다.

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)}
저장된 롤아웃 계획을 사용하여 배포

롤아웃 계획은 복잡할 수 있으므로 롤아웃 계획의 세부 사항을 저장할 수 있는 옵션이 있습니다. 이를 통해 매번 롤아웃 계획의 전체 세부 정보를 필요로 하는 대신 롤아웃 계획 이름을 참조할 수 있습니다.

  1. 롤아웃-계획 관리 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
    }
  2. 애플리케이션을 배포할 때 저장된 롤아웃 계획 이름을 지정합니다.

    다음 관리 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 .xml 의 실제 시스템 특정 IP 주소에 매핑될 수 있습니다. domain.xml의 추상화 경로 이름은 host.xml의 실제 파일 시스템 경로에 매핑될 수 있습니다 .
  • 다음 구성 중 하나를 수행합니다.

    • 호스트 컨트롤러가 도메인 컨트롤러에 연결하여 등록하고 도메인 구성에 액세스하는 방법.
    • 원격 도메인 컨트롤러를 찾아서 연결하는 방법.
    • 호스트 컨트롤러가 도메인 컨트롤러 역할을 하는지 여부

자세한 내용은 관리형 도메인호스트 컨트롤러 구성 섹션을 참조하십시오.

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.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&gt ; 선언에 <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. 호스트의 이름 설정

관리형 도메인에서 실행 중인 모든 호스트에는 고유한 호스트 이름이 있어야 합니다. 쉽게 관리하고 여러 호스트에서 동일한 호스트 구성 파일을 사용할 수 있도록 하려면 서버에서 다음 우선 순위를 사용하여 호스트 이름을 결정합니다.

  1. 설정된 경우 host .xml 구성 파일의 호스트 요소 이름 속성입니다.
  2. jboss.host.name 시스템 속성의 값입니다.
  3. jboss.qualified.host.name 시스템 속성의 최종 마침표(. ) 문자 뒤에 오는 값 또는 최종 마침표(.) 문자가 없는 경우 전체 값입니다.
  4. POSIX 기반 운영 체제의 HOSTNAME 환경 변수, Microsoft Windows의 COMPUTERNAME 환경 변수 또는 최종 마침표(.) 문자가 없는 경우 전체 값 뒤에 오는 값입니다.

호스트 컨트롤러의 이름은 관련 host .xml 구성 파일의 맨 위의 host 요소에 구성됩니다. 예를 들면 다음과 같습니다.

<host xmlns="urn:jboss:domain:8.0" name="host1">

관리 CLI를 사용하여 호스트 이름을 업데이트하려면 다음 절차를 사용하십시오.

  1. JBoss EAP 호스트 컨트롤러를 시작합니다.

    $ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
  2. 관리 CLI를 시작하여 도메인 컨트롤러에 연결합니다.

    $ EAP_HOME/bin/jboss-cli.sh --connect --controller=DOMAIN_CONTROLLER_IP_ADDRESS
  3. 다음 명령을 사용하여 새 호스트 이름을 설정합니다.

    /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">
  4. 변경 사항을 적용하기 위해 호스트 컨트롤러를 다시 로드합니다.

    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- offset 값도 정의합니다. server-three라는 서버 인스턴스는 other-server-group 과 연결되며 해당 그룹의 구성을 사용합니다. 또한 port-offset 값을 정의하고 auto-startfalse 로 설정하여 호스트 컨트롤러가 시작될 때 이 서버가 시작되지 않도록 합니다.

서버는 관리 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-configurationfalse로 설정해야 합니다. 예를 들면 다음과 같습니다.

<domain-controller>
  <remote username="$local" security-realm="ManagementRealm" ignore-unused-configuration="false">
    <discovery-options>
      ...
    </discovery-options>
  </remote>
</domain-controller>
호스트 컨트롤러를 도메인 컨트롤러로 승격
  1. 원래 도메인 컨트롤러가 중지되었는지 확인합니다.
  2. 관리 CLI를 사용하여 새 도메인 컨트롤러가 될 호스트 컨트롤러에 연결합니다.
  3. 다음 명령을 실행하여 새 도메인 컨트롤러 역할을 하도록 호스트 컨트롤러를 구성합니다.

    /host=backup:write-attribute(name=domain-controller.local, value={})
  4. 다음 명령을 실행하여 호스트 컨트롤러를 다시 로드합니다.

    reload --host=HOST_NAME

이 호스트 컨트롤러가 이제 도메인 컨트롤러 역할을 합니다.

8.6. 관리형 도메인 설정

8.6.1. 단일 머신에서 관리형 도메인 설정

jboss.domain.base.dir 속성을 사용하여 단일 시스템에서 여러 호스트 컨트롤러를 실행할 수 있습니다.

중요

두 개 이상의 JBoss EAP 호스트 컨트롤러를 단일 시스템에서 시스템 서비스로 구성하는 것은 지원되지 않습니다.

  1. 도메인 컨트롤러의 EAP_HOME/domain 디렉터리를 복사합니다.

    $ cp -r EAP_HOME/domain /path/to/domain1
  2. 호스트 컨트롤러의 EAP_HOME/domain 디렉터리를 복사합니다.

    $ cp -r EAP_HOME/domain /path/to/host1
  3. /path/to /domain1 을 사용하여 도메인 컨트롤러를 시작합니다.

    $ EAP_HOME/bin/domain.sh --host-config=host-master.xml -Djboss.domain.base.dir=/path/to/domain1
  4. /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. 시스템 1에서

    1. 도메인 컨트롤러에서 호스트를 인증할 수 있도록 관리 사용자를 추가합니다.

      add-user.sh 스크립트를 사용하여 호스트 컨트롤러 HOST_NAME 의 관리 사용자를 추가합니다. 마지막 프롬프트에 yes 로 응답하고 제공된 secret 값을 확인합니다. 이 secret 값은 호스트 컨트롤러 구성에서 사용되며 아래 행과 유사하게 표시됩니다.

      <secret value="SECRET_VALUE" />
    2. 도메인 컨트롤러를 시작합니다.

      전용 도메인 컨트롤러에 대해 사전 구성된 host-master.xml 구성 파일을 지정합니다. 또한 jboss.bind.address.management 속성을 설정하여 도메인 컨트롤러가 다른 시스템에 표시되도록 합니다.

      $ EAP_HOME/bin/domain.sh --host-config=host-master.xml -Djboss.bind.address.management=IP1
  2. On Machine 2

    1. 사용자 자격 증명으로 호스트 구성을 업데이트합니다.

      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>
              ...
    2. 호스트 컨트롤러를 시작합니다.

      슬레이브 호스트 컨트롤러에 대해 미리 구성된 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 서버 그룹을 사용합니다.

  1. JBoss EAP 7 domain.xml 구성 파일을 편집합니다. 편집하기 전에 이 파일을 백업하는 것이 좋습니다.
  2. 해당 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>

  3. 이 프로필에서 사용하는 필요한 확장 기능을 추가합니다.

    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>

  4. 해당 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>

  5. 해당 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-sockets 를 사용하도록 이 서버 그룹을 업데이트해야 합니다.

    JBoss 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에는 통계를 수집하지 않기 위해 기본값이 false인 statistics-enabled 특성이 도입되었지만 JBoss EAP 6.2 동작은 통계를 수집하는 것이었습니다. JBoss EAP 6.2 호스트에서 이 프로필을 사용하고 최신 JBoss EAP 버전을 실행하는 호스트에서 사용하는 경우 허용되지 않는 호스트 간에 동작이 일치하지 않습니다. 따라서 JBoss EAP 6.2 호스트에서 사용할 프로필은 해당 데이터 소스에 대해 다음과 같이 변경해야 합니다.

    JBoss 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 를 사용하도록 서버 그룹을 업데이트했습니다.

절차

  1. JBoss EAP 7.4 domain.xml 구성 파일을 편집합니다.

    중요

    파일을 편집하기 전에 JBoss EAP 7.4 domain.xml 구성 파일을 백업합니다.

  2. 적용 가능한 JBoss EAP 7.3 프로필을 JBoss EAP 7.4 domain.xml 파일에 복사합니다. 예를 들면 다음과 같습니다.

    <profiles>
      ...
      <profile name="eap73-default">
        ...
      </profile>
    </profiles>
  3. 적용 가능한 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>
  4. 해당 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
고가용성을 위해 jgroupsmodcluster 하위 시스템 추가와 함께 default 프로필에 제공된 하위 시스템 포함
full
messaging-activemq 및 iiop- openjdk 하위 시스템 추가와 함께 default 프로필에 제공된 하위 시스템 포함
full-ha
고가용성을 위해 jgroupsmodcluster 하위 시스템 추가와 함께 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")

위의 명령을 적용한 후 서버 그룹 groupAproduction_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 서버 구성

  1. 다음 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)
  2. 애플리케이션 내에서 구성된 메일 세션 호출

    @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에서 사용자 지정 메일 전송을 구성할 수 있습니다.

  1. 새 메일 세션을 추가하고 JNDI 이름을 지정합니다.

    /subsystem=mail/mail-session=mySession:add(jndi-name=java:jboss/mail/MySession)
  2. 아웃바운드 소켓 바인딩을 추가하고 호스트 및 포트를 지정합니다.

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-smtp-binding:add(host=localhost, port=25)
  3. 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"}

관리 콘솔을 사용하여 자격 증명 저장소 사용

  1. 관리 콘솔에 액세스합니다. 자세한 내용은 관리 콘솔을 참조하십시오.
  2. 구성하위 시스템 → 메일로 이동합니다.
  3. 적절한 메일 세션을 선택하고 View(보기 )를 클릭합니다.
  4. 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 파일을 열어 부팅 중에 발생한 오류를 볼 수 있습니다.

이 방법을 사용하면 각 오류 메시지를 관련 메시지와 함께 확인할 수 있으므로 오류가 발생한 이유에 대한 자세한 정보를 얻을 수 있습니다. 또한 일반 텍스트 형식으로 오류 메시지를 볼 수 있습니다.

  1. 파일 뷰어에서 파일 server.log 를 엽니다.
  2. 파일의 끝으로 이동합니다.
  3. 최신 부팅 시퀀스의 시작을 나타내는 WFLYSRV0049 메시지 식별자를 뒤로 검색합니다.
  4. 해당 지점에서 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.batdomain.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에 로그인한 사용자는 액세스할 권한이 있는 로그만 볼 수 있습니다.

관리 콘솔에서 로그 보기

관리 콘솔에서 직접 로그를 볼 수 있습니다.

  1. Runtime(런타임 ) 탭을 선택하고 적절한 서버를 선택합니다.
  2. 로그 파일을 선택하고 목록에서 로그 파일을 선택합니다.
  3. 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

TRACE 수준 로그 메시지는 애플리케이션의 실행 상태에 대한 자세한 정보를 제공하며 일반적으로 디버깅 중에만 캡처됩니다.

디버그

500

DEBUG 수준 로그 메시지는 개별 요청 또는 애플리케이션 활동의 진행 상황을 나타내며 일반적으로 디버깅 중에만 캡처됩니다.

NICE

500

-

CONFIG

700

-

정보

800

INFO(정보) 수준 로그 메시지는 애플리케이션의 전체 진행 상황을 나타냅니다. 종종 애플리케이션 시작, 종료 및 기타 주요 라이프사이클 이벤트에 사용됩니다.

경고

900

WARN 수준 로그 메시지는 오류가 발생하지 않지만 이상적이지 않은 상황을 나타냅니다. WARN 로그 메시지는 향후 오류가 발생할 수 있는 상황을 나타낼 수 있습니다.

경고

900

-

ERROR

1000

오류 수준 로그 메시지는 현재 활동 또는 요청이 완료되지 못하도록 할 수 있지만 애플리케이션이 실행되지 못하게 하는 오류가 있음을 나타냅니다.

심각

1000

-

치명적

1100

FATAL 수준 로그 메시지는 중요한 서비스 실패 및 애플리케이션 종료를 일으킬 수 있는 이벤트를 나타내며 JBoss EAP가 종료될 수 있음을 나타냅니다.

꺼짐

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]

단일 필터 표현식의 반전된 값을 반환합니다. 예를 들면 다음과 같습니다.

not(match("WFLY"))

모두[filter 표현식]

쉼표로 구분된 필터 표현식 목록에서 연결된 값을 반환합니다. 예를 들면 다음과 같습니다.

all(match("WFLY"),match("WELD"))

any[filter 표현식]

쉼표로 구분된 필터 표현식 목록에서 하나의 값을 반환합니다. 예를 들면 다음과 같습니다.

any(match("WFLY"),match("WELD"))

levelChange[level]

지정된 수준으로 로그 레코드를 업데이트합니다. 예를 들면 다음과 같습니다.

levelChange(WARN)

수준[수준]

쉼표로 구분된 수준 목록에 나열된 수준으로 로그 메시지를 필터링합니다. 예를 들면 다음과 같습니다.

수준(DEBUG,INFO,WARN,ERROR)

levelRange[minLevel,maxLevel]

지정된 수준 범위 내에서 로그 메시지를 필터링합니다. [] 문자는 포함 수준을 나타내는 데 사용됩니다. () 문자는 배타적 수준을 나타내는 데 사용됩니다. 예를 들면 다음과 같습니다.

  • levelRange[INFO,ERROR]

    • 최소 수준은 INFO 보다 크거나 같아야합니다. 최대 수준은 ERROR 보다 작거나 같아야합니다.
  • levelRange[DEBUG,ERROR)

    • 최소 수준은 DEBUG 보다 크거나 같아야 하며 최대 수준은 ERROR 보다 작아야 합니다.

match["pattern"]

제공된 정규 표현식을 사용하여 로그 메시지를 필터링합니다. 예를 들면 다음과 같습니다.

match("WFLY\d+")

substitute["pattern","replacement value"]

첫 번째 일치 패턴(첫 번째 인수)을 대체 텍스트(두 번째 인수)로 대체하는 필터입니다. 예를 들면 다음과 같습니다.

substitute("WFLY","EAP")

substituteAll["pattern","replacement value"]

패턴의 모든 일치 항목(첫 번째 인수)을 대체 텍스트(두 번째 인수)로 바꾸는 필터입니다. 예를 들면 다음과 같습니다.

substituteAll("WFLY","EAP")

참고

관리 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 종속성을 배포에 추가합니다. 기본적으로 trueadd-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. err 또는 console 중 하나일 수 있습니다. 기본값은 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 하위 시스템을 참조하십시오.

  1. Elytron 설정을 구성합니다.

    1. 키 저장소를 추가합니다.

      /subsystem=elytron/key-store=log-server-ks:add(path=/path/to/keystore.jks, type=JKS, credential-reference={clear-text=mypassword})
    2. 신뢰 관리자를 추가합니다.

      /subsystem=elytron/trust-manager=log-server-tm:add(key-store=log-server-ks)
    3. 클라이언트 SSL 컨텍스트를 추가합니다.

      /subsystem=elytron/client-ssl-context=log-server-context:add(trust-manager=log-server-tm, protocols=["TLSv1.2"])
  2. 소켓 바인딩을 추가합니다.

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=log-server:add(host=localhost, port=4560)
  3. JSON 포맷터를 추가합니다.

    /subsystem=logging/json-formatter=json:add
  4. 소켓 로그 핸들러를 추가합니다.

    /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)
  5. 로그 핸들러를 루트 로거에 할당합니다.

    /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 을 사용하여 명령 앞에 추가합니다.

  1. 로그 핸들러를 루트 로거에 할당합니다.

    로그 핸들러 추가.

    /subsystem=logging/root-logger=ROOT:add-handler(name=LOG_HANDLER_NAME)

    로그 핸들러 제거.

    /subsystem=logging/root-logger=ROOT:remove-handler(name=LOG_HANDLER_NAME)
  2. 로그 수준을 설정합니다.

    /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, fine,config,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")

관리 콘솔을 사용하여 패턴 로그 포맷터를 구성할 수도 있습니다.

  1. 브라우저에서 관리 콘솔을 엽니다.
  2. 구성하위 시스템로깅 을 선택합니다.
  3. Configuration(구성) 을 선택한 다음 View(보기 )를 클릭합니다.
  4. 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 로그 포맷터를 구성할 수도 있습니다.

  1. 브라우저에서 관리 콘솔을 엽니다.
  2. 구성하위 시스템로깅 을 선택합니다.
  3. Configuration(구성) 을 선택한 다음 View(보기 )를 클릭합니다.
  4. 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 로그 포맷터를 구성할 수도 있습니다.

  1. 브라우저에서 관리 콘솔을 엽니다.
  2. 구성하위 시스템로깅 을 선택합니다.
  3. Configuration(구성) 을 선택한 다음 View(보기 )를 클릭합니다.
  4. Formatter를 선택한 다음 XML Formatter 옵션을 선택합니다.

11.7.4. 사용자 정의 로그 포맷터 구성

로그 핸들러에서 로그 메시지를 포맷하기 위해 사용할 수 있는 사용자 지정 로그 포맷터를 생성할 수 있습니다.

이 섹션에서는 관리 CLI를 사용하여 사용자 지정 로그 포맷터를 구성하는 방법을 보여줍니다.

사용자 정의 로그 포맷터 구성
중요

로깅 프로필에 대해 이 로그 포맷터를 구성하는 경우 명령 시작은 /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ 대신 / subsystem=logging/ 입니다.

또한 관리형 도메인에서 실행 중인 경우 /profile=PROFILE_NAME 을 사용하여 명령 앞에 추가합니다.

  1. 사용자 지정 로그 포맷터를 추가합니다.

    사용자 정의 로그 포맷터를 추가할 때 formatter 및 여기에 포함된 JBoss EAP 모듈을 Java 클래스로 지정해야 합니다. 클래스는 java.util.logging.Formatter를 확장해야 합니다.

    참고

    사용자 지정 formatter가 포함된 모듈을 이미 생성했으므로 이 명령이 실패합니다.

    /subsystem=logging/custom-formatter=CUSTOM_FORMATTER_NAME:add(class=CLASS_NAME, module=MODULE_NAME)
  2. 로그 포맷터에 필요한 속성을 설정합니다.

    속성은 setter 메서드를 사용하여 액세스할 수 있어야 합니다.

    /subsystem=logging/custom-formatter=CUSTOM_FORMATTER_NAME:write-attribute(name=properties.PROPERTY_NAME,value=PROPERTY_VALUE)
  3. 사용자 지정 포맷터를 로그 핸들러에 할당합니다.

    다음 관리 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>
관리 콘솔을 사용하여 사용자 정의 로그 포맷터 구성

관리 콘솔을 사용하여 로그 포맷터를 구성할 수도 있습니다.

  1. 브라우저에서 관리 콘솔을 엽니다.
  2. 구성하위 시스템로깅 을 선택합니다.
  3. Configuration(구성) 을 선택한 다음 View(보기 )를 클릭합니다.
  4. 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를 사용하여 로깅 프로필을 생성하고 파일 핸들러 및 로거 범주를 설정합니다. ConfigurationSubsystems → Logging → Logging Profiles 로 이동하여 관리 콘솔을 사용하여 로깅 프로필을 구성할 수도 있습니다.

  1. 로깅 프로필을 생성합니다.

    /subsystem=logging/logging-profile=PROFILE_NAME:add
  2. 파일 핸들러를 생성합니다.

    /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")

    파일 핸들러 속성 목록은 파일 로그 핸들러 속성 목록을 참조하십시오.

  3. 로거 범주를 만듭니다.

    /subsystem=logging/logging-profile=PROFILE_NAME/logger=CATEGORY_NAME:add(level=TRACE)

    로그 카테고리 속성 목록은 Log Category Attributes 를 참조하십시오.

  4. 파일 핸들러를 카테고리에 할당합니다.

    /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를 사용하여 코어 모듈로 설치할 수 있습니다.

  1. JDBC 드라이버를 다운로드합니다.

    데이터베이스 벤더에서 적절한 JDBC 드라이버를 다운로드합니다. JDBC 드라이버의 공통 데이터베이스의 표준 다운로드 위치는 JDBC 드라이버 다운로드 위치를 참조하십시오.

    JDBC 드라이버 JAR 파일이 ZIP 또는 TAR 아카이브에 포함된 경우 아카이브를 추출해야 합니다.

  2. JBoss EAP 서버 시작.
  3. 관리 CLI를 시작합니다.

    $ EAP_HOME/bin/jboss-cli.sh
  4. 모듈 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 드라이버에 권장되는 설치 방법은 핵심 모듈로 설치하는 것입니다.

  1. JDBC 드라이버를 다운로드합니다.

    데이터베이스 벤더에서 적절한 JDBC 드라이버를 다운로드합니다. JDBC 드라이버의 공통 데이터베이스의 표준 다운로드 위치는 JDBC 드라이버 다운로드 위치를 참조하십시오.

    JDBC 드라이버 JAR 파일이 ZIP 또는 TAR 아카이브에 포함된 경우 아카이브를 추출해야 합니다.

  2. JDBC 드라이버가 JDBC 4 규격이 아닌 경우 JDBC 드라이버 JAR을 JDBC 4Compliant로 업데이트하는 단계를 참조하십시오.
  3. 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 규격이 아닌 경우 다음 단계를 사용하여 배포할 수 있습니다.

  1. 빈 임시 디렉터리를 만듭니다.
  2. META-INF 하위 디렉터리를 만듭니다.
  3. META-INF/services 하위 디렉터리를 만듭니다.
  4. META-INF/services/java.sql.Driver 파일을 생성하고 한 행을 추가하여 JDBC 드라이버의 정규화된 클래스 이름을 나타냅니다.

    예를 들어 아래 행은 MySQL JDBC 드라이버에 대해 추가됩니다.

    com.mysql.cj.jdbc.Driver
  5. 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

http://www.mysql.com/products/connector/

PostgreSQL

http://jdbc.postgresql.org/

Oracle

http://www.oracle.com/technetwork/database/features/jdbc/index-091264.html

IBM

http://www-01.ibm.com/support/docview.wss?uid=swg21363866

Sybase

jConnect JDBC 드라이버는 SAP ASE 설치용 SDK의 일부입니다. 현재 이 드라이버에는 별도의 다운로드 사이트가 없습니다.

Microsoft

http://msdn.microsoft.com/data/jdbc/

12.2.4. 벤더별 클래스 액세스

경우에 따라 애플리케이션에서 JDBC API의 일부가 아닌 벤더별 기능을 사용해야 합니다. 이러한 경우 해당 애플리케이션에 종속성을 선언하여 벤더별 API에 액세스할 수 있습니다.

주의

이는 고급 사용량입니다. JDBC API에서 찾을 수 없는 기능이 필요한 애플리케이션만 이 절차를 구현해야 합니다.

중요

이 프로세스는 재인증 메커니즘을 사용하고 공급업체별 클래스에 액세스할 때 필요합니다.

MANIFEST.MF 파일 또는 jboss-deployment-structure. xml 파일을 사용하여 애플리케이션에 대한 종속성을 정의할 수 있습니다.

아직 완료하지 않은 경우 JDBC 드라이버를 코어 모듈로 설치합니다.

MANIFEST.MF 파일 사용
  1. 애플리케이션의 META-INF/MANIFEST.MF 파일을 편집합니다.
  2. 종속성 행 을 추가하고 모듈 이름을 지정합니다.

    예를 들어 아래 행은 com.mysql 모듈을 종속성으로 선언합니다.

    Dependencies: com.mysql
jboss-deployment-structure.xml 파일 사용
  1. 애플리케이션의 META -INF/ 또는 WEB-INF/ 폴더에 jboss- deployment- structure.xml 이라는 파일을 생성합니다.
  2. 종속성 요소를 사용하여 모듈을 지정합니다.

    예를 들어 다음 예제 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가 아닌 데이터 소스 정의
  1. 구성하위 시스템데이터 소스 및 드라이버데이터 소스로 이동합니다.
  2. Add (+)(추가(+)) 버튼을 클릭하고 Add Datasource (데이터 소스 추가)를 선택합니다.
  3. 데이터 소스 유형을 선택할 수 있는 Add Datasource(데이터 소스 추가 ) 마법사를 열고 Next (다음)를 클릭합니다. 이렇게 하면 데이터베이스에 대한 템플릿이 생성됩니다. 마법사의 다음 페이지에는 선택한 데이터 소스에 고유한 값이 미리 채워져 있습니다. 이렇게 하면 데이터 소스 생성 프로세스가 쉬워집니다.
  4. 데이터 소스 생성 프로세스를 완료하기 전에 Test Connection (연결 테스트) 페이지에서 연결을 테스트할 수 있습니다.
  5. 세부 사항을 검토하고 Finish (완료)를 클릭하여 데이터 소스를 만듭니다.
관리 CLI를 사용하여 XA 데이터 소스 정의

비 XA 데이터 소스는 데이터 소스 추가 관리 CLI 명령을 사용하여 정의할 수 있습니다.

  1. 아직 완료하지 않은 경우 적절한 JDBC 드라이버를 코어 모듈로 설치하고 등록합니다.
  2. 적절한 인수 값을 지정하여 data-source add 명령을 사용하여 데이터 소스를 정의합니다.

    data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME  --connection-url=CONNECTION_URL
    참고

    관리형 도메인에서 --profile=PROFILE_NAME 인수를 지정해야 합니다.

    이러한 매개변수 값에 대한 팁은 아래의 데이터 소스 매개 변수 섹션을 참조하십시오.

자세한 예는 지원되는 데이터베이스 의 데이터 소스 구성 예에서 참조하십시오.

데이터 소스 매개변수
jndi-name
데이터 소스의 JNDI 이름은 java:/ 또는 java:jboss/ 로 시작해야 합니다. 예를 들면 java:jboss/datasources/ExampleDS 입니다.
driver-name

드라이버 이름 값은 JDBC 드라이버가 코어 모듈 또는 JAR 배포로 설치되었는지에 따라 다릅니다.

  1. core 모듈의 경우 드라이버 이름 값은 등록할 때 JDBC 드라이버에 지정된 이름이 됩니다.
  2. 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 목록을 참조하십시오.

사용 가능한 모든 데이터 소스 속성의 전체 목록은 데이터 소스 속성 섹션을 참조하십시오.

12.3.2. XA 데이터 소스 만들기

관리 CLI 또는 관리 콘솔을 사용하여 XA 데이터 소스를 생성할 수 있습니다.

관리 콘솔을 사용하여 XA 데이터 소스 정의
  1. 구성하위 시스템데이터 소스 및 드라이버데이터 소스로 이동합니다.
  2. Add (+)(추가(+)) 버튼을 클릭하고 Add XA Datasource (XA 데이터 소스 추가)를 선택합니다.
  3. 데이터 소스 유형을 선택할 수 있는 XA 데이터 소스 추가 마법사를 열고 Next (다음)를 클릭합니다. 이렇게 하면 데이터베이스에 대한 템플릿이 생성됩니다. 마법사의 다음 페이지에는 선택한 데이터 소스에 고유한 값이 미리 채워져 있습니다. 이렇게 하면 데이터 소스 생성 프로세스가 쉬워집니다.
  4. 데이터 소스 생성 프로세스를 완료하기 전에 Test Connection (연결 테스트) 페이지에서 연결을 테스트할 수 있습니다.
  5. 세부 사항을 검토하고 Finish (완료)를 클릭하여 데이터 소스를 만듭니다.
관리 CLI를 사용하여 XA 데이터 소스 정의

XA 데이터 소스는 xa-data-source add management CLI 명령을 사용하여 정의할 수 있습니다.

참고

관리형 도메인에서는 사용할 프로필을 지정해야 합니다. 관리 CLI 명령 형식에 따라 /profile=PROFILE_NAME 을 사용하여 명령 앞에 추가하거나 --profile=PROFILE_NAME 인수를 전달합니다.

  1. 아직 완료하지 않은 경우 적절한 JDBC 드라이버를 코어 모듈로 설치하고 등록합니다.
  2. 적절한 인수 값을 지정하여 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"}

    이러한 매개변수 값에 대한 팁은 아래의 데이터 소스 매개 변수 섹션을 참조하십시오.

  3. XA 데이터 소스 속성을 설정합니다.

    XA 데이터 소스를 정의할 때 하나 이상의 XA 데이터 소스 속성이 필요하거나 이전 단계에서 데이터 소스를 추가할 때 오류가 발생합니다. XA 데이터 소스를 정의할 때 설정되지 않은 속성은 나중에 개별적으로 설정할 수 있습니다.

    1. 서버 이름을 설정합니다.

      /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOST_NAME)
    2. 데이터베이스 이름을 설정합니다.

      /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 배포로 설치되었는지에 따라 다릅니다.

  1. core 모듈의 경우 드라이버 이름 값은 등록할 때 JDBC 드라이버에 지정된 이름이 됩니다.
  2. 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 명령을 사용하여 업데이트할 수 있습니다. ConfigurationSubsystemsDatasources & Drivers → Datasources → Datasources → Datasources 로 이동하여 관리 콘솔에서 데이터 소스 속성을 업데이트할 수도 있습니다.

참고

비 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 명령을 사용하여 업데이트할 수 있습니다. ConfigurationSubsystemsDatasources & Drivers → Datasources → Datasources → Datasources 로 이동하여 관리 콘솔에서 데이터 소스 속성을 업데이트할 수도 있습니다.

  • XA 데이터 소스에 대한 설정은 다음 관리 CLI 명령을 사용하여 업데이트할 수 있습니다.

    xa-data-source --name=XA_DATASOURCE_NAME --ATTRIBUTE_NAME=ATTRIBUTE_VALUE
    참고

    관리형 도메인에서 --profile=PROFILE_NAME 인수를 지정해야 합니다.

  • 다음 관리 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 명령을 사용하여 제거할 수 있습니다. 관리 콘솔을 사용하여 구성하위 시스템 → 데이터 소스 및 드라이버 → 데이터 소스로 이동하여 데이터 소스를 제거할 수도 있습니다 .

data-source remove --name=DATASOURCE_NAME
참고

관리형 도메인에서 --profile=PROFILE_NAME 인수를 지정해야 합니다.

데이터 소스를 제거한 후 서버를 다시 로드해야 합니다.

12.5.2. XA 데이터 소스 제거

XA 데이터 소스는 xa-data-source remove management CLI 명령을 사용하여 제거할 수 있습니다. 관리 콘솔을 사용하여 구성하위 시스템 → 데이터 소스 및 드라이버 → 데이터 소스로 이동하여 데이터 소스를 제거할 수도 있습니다 .

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_NAMExa-data-source=XA_DATASOURCE_NAME 으로 바꿉니다.

관리 콘솔을 사용하여 데이터 소스 연결 테스트

관리 콘솔에서 데이터 소스 추가 마법사를 사용할 때 데이터 소스를 생성하기 전에 연결을 테스트할 수 있습니다. 마법사의 Test Connection (연결 테스트) 화면에서 Test Connection (연결 테스트) 버튼을 클릭합니다.

데이터 소스가 추가되면 ConfigurationSubsystemsDatasources & Drivers → Datasources → DatasourcesDatasources 로 이동하여 연결을 테스트할 수 있습니다. 데이터 소스를 선택하고, 드롭다운에서 테스트 연결을 선택할 수 있습니다.

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 com.arspringa.ats.jta.recovery.XAResource recoveryy를 확장해야 합니다.

recovery-plugin-properties

속성을 설정해야 하는 사용자 지정 복구 모듈을 사용하는 경우 이 속성을 속성에 대해 쉼표로 구분된 KEY=VALUE 쌍 목록으로 설정합니다.

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_transactions0 보다 크거나 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가 데이터베이스에 대한 연결이 끊어질 수 있습니다. 이러한 상황에서 복구하려면 데이터 소스에 대한 데이터베이스 연결 유효성 검사를 활성화할 수 있습니다.

데이터베이스 연결 유효성 검사를 구성하려면 유효성 검사 타이밍 방법, 유효성 검사 수행 방법을 확인하는 유효성 검사 메커니즘 및 예외 정렬기를 지정하여 예외 정렬기를 지정합니다.

  1. 유효성 검사 타이밍 방법 중 하나를 선택합니다.

    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-matchtrue 로 설정된 경우 background-validationfalse 로 설정해야 합니다.
    • background-validationtrue 로 설정된 경우 validate-on-matchfalse 로 설정해야 합니다.

    이러한 검증 방법에 대한 비교 매트릭스는 유효성 검사 타이밍 방법 비교를 참조하십시오.

  2. 유효성 검사 메커니즘 중 하나를 선택합니다.

    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
  3. 예외 분류기 클래스 이름을 설정합니다.

    연결이 트랜잭션에 참여하는 경우에도 예외가 치명적으로 표시되면 연결이 즉시 닫힙니다. 치명적인 연결 예외 후 올바르게 감지 및 정리하려면 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. 데이터 소스 보안

데이터 소스 보안은 데이터 소스 연결에 대한 암호 암호화 또는 모호성을 나타냅니다. 이러한 암호는 구성 파일의 일반 텍스트로 저장할 수 있지만 이는 보안 위험을 나타냅니다.

데이터 소스 보안에 사용할 수 있는 몇 가지 방법이 있습니다. 다음은 각 예제가 포함되어 있습니다.

보안 도메인을 사용하여 데이터 소스 보안

다음 단계를 사용하여 보안 도메인을 사용하여 데이터 소스를 보호합니다.

  1. 새 보안 도메인을 생성합니다.

    /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>
  2. 새 데이터 소스를 추가합니다.

    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()"
  3. 데이터 소스에 보안 도메인을 설정합니다.

    data-source --name=securityDs --security-domain=DsRealm
  4. 변경 사항이 적용되도록 서버를 다시 로드합니다.

    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를 사용하여 데이터 소스 보안

암호 자격 증명 모음을 사용하여 데이터 소스를 보호하려면 다음 단계를 사용합니다.

  1. ExampleDS 데이터 소스에 대한 암호 자격 증명 모음을 설정합니다.

    data-source --name=ExampleDS
    --password=${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}
  2. 서버를 다시 로드하여 변경 사항을 구현합니다.

    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 인증 컨텍스트를 사용하여 사용자 이름과 암호를 제공할 수도 있습니다.

다음 단계를 사용하여 데이터 소스 보안에 대한 인증 컨텍스트를 구성하고 사용합니다.

  1. passworduser-name 을 제거합니다.

    /subsystem=datasources/data-source=ExampleDS:undefine-attribute(name=password)
    /subsystem=datasources/data-source=ExampleDS:undefine-attribute(name=user-name)
  2. 데이터 소스에 대해 Elytron 보안을 활성화합니다.

    /subsystem=datasources/data-source=ExampleDS:write-attribute(name=elytron-enabled,value=true)
    
    reload
  3. 자격 증명에 대한 인증 구성을 만듭니다.

    인증 구성에는 데이터 소스를 연결할 때 사용할 자격 증명이 포함되어 있습니다. 아래 예제에서는 자격 증명 저장소에 대한 참조를 사용하지만 Elytron 보안 도메인을 사용할 수도 있습니다.

    /subsystem=elytron/authentication-configuration=exampleAuthConfig:add(authentication-name=sa,credential-reference={clear-text=sa})
  4. authentication-context 를 만듭니다.

    /subsystem=elytron/authentication-context=exampleAuthContext:add(match-rules=[{authentication-configuration=exampleAuthConfig}])
  5. 인증 컨텍스트를 사용하도록 데이터 소스를 업데이트합니다.

    아래 예제에서는 인증 컨텍스트를 사용하도록 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를 사용하여 데이터 소스를 보호하려면 다음을 수행합니다.

  1. 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.debug 값을 true 로 변경합니다. 프로덕션 환경에서는 값을 false 로 설정하는 것이 좋습니다.

  2. 보안 구성.

    레거시 보안 또는 Elytron 보안을 사용하여 데이터 소스를 보호할 수 있습니다.

    • 기존 보안과 함께 kerberos를 사용하려면 다음을 수행합니다.

      1. 캐시에서 만료된 티켓을 정기적으로 제거하도록 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 티켓의 최대 사본 수입니다. 값은 데이터 소스에서 구성된 연결 수에 해당합니다.
      2. 보안 도메인을 생성합니다.