JBoss EAP 7은 서버 작업을 정상적으로 일시 중단하는 일시 중단 모드를 도입했습니다. 이렇게 하면 모든 활성 요청이 정상적으로 완료되지만 새 요청은 허용하지 않습니다. 서버가 일시 중단되면 종료하거나 실행 중 상태로 되돌리거나 일시 중단된 상태로 유지 관리를 수행할 수 있습니다.

관리 콘솔 또는 관리 CLI를 사용하여 서버를 일시 중단하고 다시 시작할 수 있습니다.

서버 일시 중단 상태 확인

서버 일시 중단 상태는 다음 관리 CLI 명령을 사용하여 볼 수 있습니다. 결과 값은 RUNNING,PRE_SUSPEND,SUSPEND ING 또는 SUSP ENDED 중 하나입니다.

일시 중지

다음 관리 CLI 명령을 사용하여 활성 요청이 완료될 때까지 기다리는 시간 제한 값(초)을 지정하여 서버를 일시 중지합니다. 기본값은 0 이며 즉시 일시 중단됩니다. 값 -1 은 서버가 모든 활성 요청이 완료될 때까지 무기한 대기하게 됩니다.

각 예제는 일시 중단 전에 요청이 완료될 때까지 최대 60초 동안 기다립니다.

재개

resume 명령은 새 요청을 수락하기 위해 서버를 정상 실행 상태로 반환합니다. 호스트, 서버, 서버 그룹 또는 도메인 수준에서 명령을 시작할 수 있습니다. 예를 들면 다음과 같습니다.

:resume

일시 중단된 상태에서 서버 시작

서버를 일시 중단 상태로 시작하여 서버가 다시 시작될 때까지 요청을 수락하지 않도록 할 수 있습니다.

서버를 중지할 때 적절한 시간 초과 값을 지정하면 서버가 정상적으로 종료됩니다. 명령이 실행되면 서버가 일시 중지되고 종료하기 전에 모든 요청이 완료될 때까지 지정된 시간 초과까지 기다립니다.

다음 관리 CLI 명령을 사용하여 서버를 정상적으로 종료합니다. 활성 요청이 완료될 때까지 서버에서 대기할 시간 제한 값(초)을 지정합니다. 기본값은 0 이며, 서버를 즉시 종료합니다. 값 -1 로 인해 서버가 종료되기 전에 모든 활성 요청이 완료될 때까지 무기한 대기하게 됩니다.

각 예제는 종료하기 전에 요청이 완료될 때까지 최대 60초 동안 기다립니다.

kill -15 PID 와 같은 OS TERM 신호를 보내 서버를 정상적으로 종료할 수 있습니다. 기본적으로 이 값은 관리 CLI의 shutdown --suspend-timeout=0 명령과 동일하므로 현재 처리 중인 요청을 즉시 종료합니다. 시간 제한은 서버가 종료되기 전에 요청이 완료될 때까지 대기할 최대 시간(초)을 나타내는 org.wildfly.sigterm.suspend.timeout 시스템 속성으로 구성할 수 있습니다. 값 -1 은 서버가 무기한 대기함을 나타냅니다.

JVM이 신호 처리를 비활성화하도록 구성된 경우(예: -Xrs java 인수가 JVM 옵션에 전달되었거나 전송된 신호가 전송된 신호가 아닌 경우) 신호 처리를 비활성화하도록 구성된 경우 OS 신호를 사용하는 정상 종료가 작동하지 않습니다(예: KILL 신호 전송).

JBoss EAP의 RPM 설치를 시작하는 명령은 시작하려는 운영 모드, 독립 실행형 서버 또는 관리형 도메인 및 실행 중인 Red Hat Enterprise Linux 버전에 따라 달라집니다.

JBoss EAP를 독립 실행형 서버로 시작(RPM 설치)

이는 기본적으로 standalone.xml 구성 파일을 사용하여 JBoss EAP를 시작합니다. RPM 서비스 구성 파일에서 속성을 설정하여 다른 독립 실행형 서버 구성 파일로 JBoss EAP를 시작할 수 있습니다. 자세한 내용은 아래의 RPM 서비스 속성 구성 섹션을 참조하십시오.

관리형 도메인에서 JBoss EAP 시작(RPM 설치)

이는 기본적으로 host.xml 구성 파일을 사용하여 JBoss EAP를 시작합니다. RPM 서비스 구성 파일에서 속성을 설정하여 다른 관리형 도메인 구성 파일로 JBoss EAP를 시작할 수 있습니다. 자세한 내용은 아래의 RPM 서비스 속성 구성 섹션을 참조하십시오.

RPM 서비스 속성 구성

이 섹션에서는 JBoss EAP 설치를 위한 RPM 서비스 속성 및 기타 시작 옵션을 구성하는 방법을 보여줍니다. 구성 파일을 수정하기 전에 백업하는 것이 좋습니다.

RPM 설치에 사용 가능한 모든 시작 옵션 목록은 RPM 서비스 구성 속성 섹션을 참조하십시오.

JBoss EAP의 RPM 설치를 중지하는 명령은 시작된 운영 모드, 독립 실행형 서버 또는 관리형 도메인 및 실행 중인 Red Hat Enterprise Linux 버전에 따라 달라집니다.

독립 실행형 서버로 JBoss EAP 중지(RPM 설치)

관리형 도메인에서 JBoss EAP 중지(RPM 설치)

RPM 설치에 사용할 수 있는 모든 시작 옵션 목록은 RPM 서비스 구성 파일 섹션을 참조하십시오.

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

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

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

다음 명령은 guest 및 mgmt group 그룹이 있는 관리 사용자mgmt user1 을 추가합니다.

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser1' -p 'password1!' -g 'guest,mgmtgroup'

대체 속성 파일 지정

기본적으로 add-user 스크립트를 사용하여 생성된 사용자 및 그룹 정보는 서버 구성 디렉터리에 있는 속성 파일에 저장됩니다.

사용자 정보는 다음 속성 파일에 저장됩니다.

그룹 정보는 다음 속성 파일에 저장됩니다.

이러한 기본 디렉터리 및 속성 파일 이름을 재정의할 수 있습니다. 다음 명령은 사용자 속성 파일에 다른 이름 및 위치를 지정하여 새 사용자를 추가합니다.

$ 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 인수 섹션을 참조하십시오.

add-user 유틸리티 스크립트에 대한 암호 제한은 EAP_HOME/bin/add-user.properties 파일을 사용하여 구성할 수 있습니다.

의도하지 않은 암호를 설정하지 않도록 하려면 키보드의 시스템 키맵이 올바른지 확인합니다. 기본 시스템 키 맵은 en-qwerty 입니다. 이 기본 설정을 변경하고 새 암호를 생성하는 경우 암호가 SimplePasswordStrengthChecker 클래스에 있는 기준을 충족하는지 확인해야 합니다.

기본적으로 JBoss EAP는 취약한 암호를 허용하지만 경고를 발행합니다. 지정된 최소 요구 사항을 충족하지 않는 암호를 거부하려면 password.restriction 속성을 REJECT 로 설정합니다.

다음 표에서는 EAP_HOME/bin/add-user.properties 파일에서 구성할 수 있는 추가 암호 요구 사항 설정을 설명합니다.

메시지가 표시되면 사용자 이름을 입력하여 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):

이미 존재하는 사용자 이름을 입력하면 몇 가지 옵션이 표시됩니다.

관리 CLI(명령줄 인터페이스)는 JBoss EAP를 위한 명령줄 관리 도구입니다.

관리 CLI를 사용하여 서버를 시작 및 중지하고, 애플리케이션을 배포 및 배포 취소, 시스템 설정을 구성하고, 다른 관리 작업을 수행합니다. 배치 모드에서 작업을 수행할 수 있으므로 여러 작업을 그룹으로 실행할 수 있습니다.

ls,cd, pwd 와 같은 많은 터미널 명령을 사용할 수 있습니다. 관리 CLI는 탭 완료도 지원합니다.

명령 및 작업, 구문 및 배치 모드에서 실행을 포함한 관리 CLI 사용에 대한 자세한 내용은 JBoss EAP 관리 CLI 가이드를 참조하십시오.

관리 CLI 시작

$ EAP_HOME/bin/jboss-cli.sh

실행 중인 서버에 연결

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

관리 콘솔은 JBoss EAP용 웹 기반 관리 도구입니다.

관리 콘솔을 사용하여 서버를 시작 및 중지하고, 애플리케이션을 배포 및 배포 취소하고, 시스템 설정을 조정하며, 서버 구성을 영구적으로 수정합니다. 관리 콘솔에는 현재 사용자가 변경한 경우 서버 인스턴스를 다시 시작하거나 다시 로드해야 하는 경우 실시간 알림과 함께 관리 작업을 수행할 수 있는 기능도 있습니다.

관리형 도메인에서 동일한 도메인의 서버 인스턴스 및 서버 그룹은 도메인 컨트롤러의 관리 콘솔에서 중앙에서 관리할 수 있습니다.

기본 관리 포트를 사용하여 로컬 호스트에서 실행되는 JBoss EAP 인스턴스의 경우 http://localhost:9990/console/index.html 의 웹 브라우저를 통해 관리 콘솔에 액세스할 수 있습니다. 관리 콘솔에 액세스할 수 있는 권한이 있는 사용자로 인증해야 합니다.

관리 콘솔은 JBoss EAP 독립 실행형 서버 또는 관리형 도메인을 탐색하고 관리하기 위해 다음 탭을 제공합니다.

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

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 값에 사용할 수 있는 옵션입니다.

다음 예제 URL은 HTTP API를 사용하여 읽기 작업을 수행하는 방법을 보여줍니다.

http://HOST_NAME:9990/management/subsystem/undertow/server/default-server/http-listener/default

그러면 기본 HTTP 리스너에 대한 모든 특성과 해당 값이 표시됩니다.

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를 사용하여 애플리케이션 배포를 참조하십시오.

네이티브 API 엔드포인트는 네이티브 프로토콜을 사용하여 JBoss EAP 관리 계층과 통합하는 관리 클라이언트의 진입점입니다. 기본 API는 JBoss EAP 관리 CLI에서 사용하지만 다른 클라이언트에도 통합 기능을 제공합니다.

다음 Java 코드는 네이티브 API를 사용하여 Java 코드에서 관리 작업을 실행하는 방법의 예를 보여줍니다.

// 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();

독립 실행형 구성 파일은 EAP_HOME/standalone/configuration/ 디렉터리에 있습니다. 사전 정의된 5개의 프로필(기본값,ha, full,full -ha,load-balancer )마다 별도의 파일이 있습니다.

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

$ EAP_HOME/bin/standalone.sh --server-config=standalone-full.xml

관리형 도메인 구성 파일은 EAP_HOME/domain/configuration/ 디렉터리에 있습니다.

기본적으로 관리형 도메인에서 JBoss EAP를 시작하면 host.xml 파일을 사용합니다. 다른 구성으로 JBoss EAP를 시작하려면 --host-config 인수를 사용합니다. 예를 들면 다음과 같습니다.

$ EAP_HOME/bin/domain.sh --host-config=host-master.xml

JBoss EAP 서버 구성을 나중에 복원하려면 다음 위치에 있는 항목을 백업해야 합니다.

서버 유지 관리 및 관리를 지원하기 위해 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)

스냅샷으로 서버 시작

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

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"}
            }]
        }
    ]
}

이 예제에서는 구성에 영향을 주는 수행된 세 가지 작업의 세부 정보를 나열합니다.

관리 콘솔에서 구성 변경 사항 추적 및 보기

관리 콘솔에서 구성 변경 사항을 추적할 수 있도록 Runtime(런타임 ) 탭으로 선택하고 서버 또는 호스트로 이동하여 변경 사항을 추적하고 드롭다운에서 Configuration Changes (구성 변경)를 선택합니다. Enable Configuration(구성 변경 사항 활성화)을 클릭하고 최대 기록 값을 제공합니다.

이 페이지의 테이블에는 날짜, 원점, 결과 및 운영 세부 정보와 함께 각 구성 변경 사항이 나열됩니다.

JBoss EAP를 사용하면 표현식을 사용하여 구성에서 리터럴 값 대신 교체 가능한 속성을 정의할 수 있습니다. 표현식은 ${PARAMETER:DEFAULT_VALUE} 형식을 사용합니다. 지정된 매개 변수가 설정되면 매개 변수의 값이 사용됩니다. 그렇지 않으면 제공된 기본값이 사용됩니다.

표현식을 해결하는 데 지원되는 소스는 시스템 속성, 환경 변수 및 자격 증명 모음입니다. 배포 전용의 경우 소스는 배포 아카이브의 META-INF/jboss.properties 파일에 나열된 속성이 될 수 있습니다. 하위 배포를 지원하는 배포 유형의 경우 속성 파일이 외부 배포에 있는 경우(예: EAR) 모든 하위 배포로 해결 범위가 지정됩니다. 속성 파일이 하위 배포에 있는 경우 해결 범위는 해당 하위 배포로만 지정됩니다.

standalone.xml 구성 파일에서 아래 예제에서는 jboss. bind. address 매개 변수를 설정하지 않는 한 공용 인터페이스의 inet- address 를 127.0.0.1 로 설정합니다.

<interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>

jboss.bind.address 매개 변수는 다음 명령을 사용하여 EAP를 독립 실행형 서버로 시작할 때 설정할 수 있습니다.

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

중첩 표현식

표현식을 중첩하여 고정 값 대신 고급 표현식을 사용할 수 있습니다. 중첩된 식의 형식은 일반 표현식의 형식과 같지만 하나의 표현식은 다른 표현식에 포함됩니다. 예를 들면 다음과 같습니다.

${SYSTEM_VALUE_1${SYSTEM_VALUE_2}}

중첩된 식은 재귀적으로 평가되므로 내부 표현식을 먼저 평가한 다음 외부 표현식을 평가합니다. 표현식도 재귀적일 수 있습니다. 여기서 표현식은 다른 표현식으로 확인되므로 이 식이 해결됩니다. 관리 CLI 명령을 제외하고 표현식이 허용되는 모든 곳에 중첩된 표현식이 허용됩니다.

중첩 표현식을 사용할 수 있는 예제는 데이터 소스 정의에 사용된 암호가 마스킹되는 경우입니다. 데이터 소스의 구성에는 다음 행이 있을 수 있습니다.

<password>${VAULT::ds_ExampleDS::password::1}</password>

ds_ExampleDS 값은 중첩된 표현식을 사용하여 시스템 속성(datasource_name)으로 바꿀 수 있습니다. 데이터 소스에 대한 구성은 대신 다음 행을 가질 수 있습니다.

<password>${VAULT::${datasource_name}::password::1}</password>

JBoss EAP는 먼저 표현식 ${datasource_name} 을 평가한 다음 이를 더 큰 표현식에 입력하고 결과 표현식을 평가합니다. 이 구성의 이점은 데이터 소스 이름이 고정 구성에서 추상화된다는 것입니다.

설명자 기반 속성 교체

데이터 소스 연결 매개 변수와 같은 애플리케이션 구성은 일반적으로 개발, 테스트 및 프로덕션 환경마다 다릅니다. Jakarta EE 사양에는 이러한 구성을 외부화하는 방법이 포함되어 있지 않으므로 이러한 차이가 종종 빌드 시스템 스크립트에 의해 수용됩니다. JBoss EAP를 사용하면 설명자 기반 속성 교체를 사용하여 구성을 외부적으로 관리할 수 있습니다.

설명자 기반 속성 교체는 설명자를 기반으로 하는 속성을 대체하여 애플리케이션 및 빌드 체인에서 환경에 대한 가정을 제거할 수 있습니다. 환경별 구성은 주석 또는 빌드 시스템 스크립트가 아닌 배포 설명자에 지정할 수 있습니다. 명령줄에서 파일 또는 매개 변수로 구성을 제공할 수 있습니다.

the ee 하위 시스템에는 속성 교체가 적용되는지 여부를 제어하는 여러 플래그가 있습니다.

JBoss 특정 설명자 교체는 jboss-descriptor-property-replacement 플래그로 제어되며 기본적으로 활성화되어 있습니다. 활성화된 경우 다음 배포 설명자에서 속성을 바꿀 수 있습니다.

다음 관리 CLI 명령을 사용하여 JBoss별 설명자에서 속성 교체를 활성화하거나 비활성화할 수 있습니다.

/subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

Jakarta EE 설명자 교체는 spec-descriptor-property-replacement 플래그로 제어되며 기본적으로 비활성화되어 있습니다. 활성화된 경우 다음 배포 설명자에서 속성을 바꿀 수 있습니다.

다음 관리 CLI 명령을 사용하여 Jakarta EE 설명자에서 속성 교체를 활성화하거나 비활성화할 수 있습니다.

/subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)

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를 사용하여 커밋 내역을 보고 분기를 관리하며 콘텐츠를 관리할 수도 있습니다.

이 기능을 사용하려면 서버를 시작할 때 명령줄에서 다음 인수 중 하나 이상을 전달합니다.

로컬 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 SSH 리포지토리 사용

SSH 인증의 경우 SSH 자격 증명을 지정하여 elytron 구성 파일을 구성할 수 있습니다. 이 파일에서 SSH 자격 증명을 지정한 후 독립 실행형 서버 인스턴스를 시작할 수 있으며 원격 Git SSH 리포지토리에서 서버 구성 파일 기록을 관리할 수 있습니다.

elytron-tool.sh 스크립트를 사용하여 액세스할 수 있는 WildFly Elytron 툴을 사용하여 SSH 키 쌍을 생성하고 자격 증명 저장소에 저장할 수도 있습니다. WildFly Elytron 툴은 이전에 서버에 대한 SSH 자격 증명을 지정하지 않은 경우 사용하는 데 유용합니다.

elytron 구성 파일에 자격 증명을 추가하면 원격 Git SSH 리포지토리에 연결할 수 있습니다.

elytron 구성 파일에서 OpenSSH 키 사용

elytron 하위 시스템은 OpenSSH 명령줄 도구를 사용하여 생성된 SSH 키 쌍을 지원합니다. 이 툴은 RSA, DSA 및 ECDSA 알고리즘을 사용합니다.

ssh-keygen 명령을 사용하여 SSH 키 쌍을 생성할 수 있습니다.

또한 세 가지 요소 유형 중 하나를 사용하여 암호를 지정할 수 있습니다.

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"}

다음 관리 CLI 명령을 사용하여 파일 시스템 경로를 나열합니다.

ls /path

ls /host=HOST_NAME/server=SERVER_NAME/path

다음 관리 CLI 명령을 사용하여 파일 시스템 경로 값을 읽습니다.

/path=PATH_NAME:read-resource

/host=HOST_NAME/server=SERVER_NAME/path=PATH_NAME:read-resource

jboss.server.* 또는 jboss.domain.* 로 시작하는 표준 경로의 기본 위치를 재정의할 수 있습니다. 다음 두 가지 방법 중 하나로 수행할 수 있습니다.

관리형 도메인의 표준 경로 재정의

이 예제에서 목표는 도메인 파일을 /opt/jboss_eap/domain_data 디렉터리에 저장하고 각 최상위 디렉터리에 사용자 지정 이름을 지정하는 것입니다. 기본 디렉터리 그룹 by-server 가 사용됩니다.

이 구성을 수행하려면 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

관리 CLI 또는 관리 콘솔을 사용하여 사용자 지정 파일 시스템 경로를 추가할 수 있습니다.

그런 다음 이 사용자 지정 경로를 구성에서 사용할 수 있습니다. 예를 들어 아래 로그 핸들러는 상대 경로에 사용자 지정 경로를 사용합니다.

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

JBoss EAP는 감사 로깅을 위해 파일 핸들러로 사전 구성되지만 감사 로깅은 기본적으로 비활성화되어 있습니다. 감사 로깅을 활성화하는 관리 CLI 명령은 독립 실행형 서버 또는 관리형 도메인으로 실행 중인지에 따라 다릅니다. 파일 핸들러 속성은 Management Audit Logging Attributes 를 참조하십시오.

다음 지침은 NATIVE 및 HTTP 감사 로깅을 활성화합니다. Jakarta Management 감사 로깅을 구성하려면 Jakarta Management Management Audit Logging 사용을 참조하십시오.

syslog 감사 로깅을 설정하려면 Syslog 서버로 관리 감사 로깅 보내기를 참조하십시오.

독립 실행형 서버 감사 로깅 활성화

다음 명령을 사용하여 감사 로깅을 활성화할 수 있습니다.

/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

기본적으로 이는 EAP_HOME/standalone/data/audit-log.log 에 감사 로그를 작성합니다.

관리형 도메인 감사 로깅 활성화

관리형 도메인의 기본 감사 로깅 구성은 각 호스트 및 각 서버에 대한 감사 로그를 작성하도록 사전 구성되어 있습니다.

다음 명령을 사용하여 각 호스트에 대한 감사 로깅을 활성화할 수 있습니다.

/host=HOST_NAME/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

기본적으로 이는 EAP_HOME/domain/data/audit-log.log 에 감사 로그를 작성합니다.

다음 명령을 사용하여 각 서버에 대한 감사 로깅을 활성화할 수 있습니다.

/host=HOST_NAME/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)

기본적으로 이는 EAP_HOME /domain/servers/SERVER_NAME/data/audit-log.log 에 감사 로그를 작성합니다.

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 감사 로깅을 활성화할 수 있습니다.

syslog 핸들러는 감사 로그 항목이 syslog 서버로 전송되는 매개 변수, 특히 syslog 서버의 호스트 이름 및 syslog 서버가 수신 대기하는 포트를 지정합니다. syslog 서버로 감사 로깅을 전송하면 로컬 파일 또는 로컬 syslog 서버에 로깅하는 것보다 더 많은 보안 옵션이 제공됩니다. 여러 개의 syslog 핸들러를 정의하고 동시에 활성화할 수 있습니다.

기본적으로 감사 로깅은 활성화된 경우 파일로 출력하도록 사전 구성됩니다. 다음 단계를 사용하여 syslog 서버에 대한 감사 로깅을 설정하고 활성화합니다. syslog 핸들러 속성은 Management Audit Logging Attributes 를 참조하십시오.

파일에 대한 감사 로그 항목은 텍스트 뷰어 로 가장 잘 표시되는 반면 syslog 서버에 대한 출력은 syslog 뷰어 애플리케이션을 사용하여 가장 잘 볼 수 있습니다.

감사 로그 항목은 JSON 형식으로 저장됩니다. 각 로그 항목은 선택적 타임스탬프로 시작되고 그 뒤에 아래 테이블의 필드가 옵니다.

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

이제 위의 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

이는 실행 상태가 정상에서 일시 중단으로 변경된 다음 일시 중지 에서 일시 중지로 변경되었음을 나타냅니다 .

서버 라이프사이클 이벤트를 모니터링하기 위해 Jakarta Management 알림 리스너를 등록할 수 있습니다. 다음 단계에서는 이벤트를 파일에 기록하는 예제 리스너를 만들고 추가하는 방법을 보여줍니다.

이제 서버 라이프사이클 이벤트가 위의 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'

이는 실행 상태가 정상에서 일시 중단으로 변경된 다음 일시 중지 에서 일시 중지로 변경되었음을 나타냅니다 .

<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 스위치를 사용할 수도 있습니다. 서버 시작 옵션에 대한 자세한 내용은 서버 런타임 인수 및 스위치 를 참조하십시오.

네트워크 인터페이스는 실제 인터페이스에 대한 논리적 이름 및 선택 기준을 지정하여 선언됩니다. 선택 기준은 와일드카드 주소를 참조하거나 인터페이스 또는 주소가 유효한 일치를 위해 있어야 하는 하나 이상의 특성 집합을 지정할 수 있습니다. 사용 가능한 모든 인터페이스 선택 기준 목록은 인터페이스 특성 섹션을 참조하십시오.

인터페이스는 관리 콘솔 또는 관리 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>

관리 포트는 JBoss EAP 7에서 통합되었습니다. 기본적으로 JBoss EAP 7은 관리 CLI에서 사용하는 네이티브 관리 및 웹 기반 관리 콘솔에서 사용하는 HTTP 관리 모두에 포트 9990 을 사용합니다. JBoss EAP 6에서 네이티브 관리 포트로 사용된 포트 9999 는 더 이상 사용되지 않지만 원하는 경우 활성화할 수 있습니다.

관리 콘솔에 HTTPS를 활성화하면 기본적으로 포트 9993 이 사용됩니다.

JBoss EAP에는 사전 정의된 5개의 프로필(default,ha, full,full -ha, load-balancer ) 각각에 대한 소켓 바인딩 그룹이 포함되어 있습니다.

기본 포트 및 설명과 같은 기본 소켓 바인딩에 대한 자세한 내용은 기본 소켓 바인딩 섹션을 참조하십시오.

독립 실행형 서버

독립 실행형 서버로 실행하는 경우 구성 파일별로 하나의 소켓 바인딩 그룹만 정의됩니다. 각 독립 실행형 구성 파일(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개의 사전 정의된 소켓 바인딩 그룹이 있습니다.

각 소켓 바인딩 그룹은 해당 프로필에서 사용하는 기술의 소켓 바인딩을 지정합니다. 예를 들어 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>

소켓 바인딩을 정의할 때 포트 및 인터페이스 속성은 물론 multicast -address 및 multicast -port 와 같은 멀티캐스트 설정을 구성할 수 있습니다. 사용 가능한 모든 소켓 바인딩 속성에 대한 자세한 내용은 소켓 바인딩 특성 섹션을 참조하십시오.

소켓 바인딩은 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다. 다음 단계에서는 소켓 바인딩 그룹을 추가하고, 소켓 바인딩을 추가하고, 관리 CLI를 사용하여 소켓 바인딩 설정을 구성합니다.

다음 예제에서는 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>

관리 콘솔에서 서버의 소켓 바인딩 이름과 열려 있는 포트를 볼 수 있습니다. 이 정보는 서버가 다음 상태에 있을 때 표시됩니다.

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

포트 오프셋은 해당 서버의 소켓 바인딩 그룹에 지정된 모든 포트 값에 추가된 숫자 오프셋 값입니다. 이렇게 하면 서버에서 소켓 바인딩 그룹에 정의된 포트 값을 오프셋과 상속하여 동일한 호스트의 다른 서버와 충돌하지 않도록 할 수 있습니다. 예를 들어 소켓 바인딩 그룹의 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

애플리케이션 배포

관리 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")

마찬가지로 다음 배포 명령을 사용할 수 있습니다.

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

애플리케이션 배포 취소

관리 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 명령을 사용하여 모든 배포를 나열 할 수도 있습니다.

애플리케이션 배포

관리 CLI에서 배포 deploy-file 명령을 사용하고 애플리케이션 배포 경로를 지정합니다. 또한 애플리케이션을 배포해야 하는 서버 그룹을 지정해야 합니다.

배포가 성공하면 관리 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")

마찬가지로 다음 배포 명령을 사용할 수 있습니다.

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

애플리케이션 배포 취소

관리 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 명령을 사용하여 도메인의 모든 배포를 나열 할 수도 있습니다.

배포는 JBoss EAP 관리 콘솔의 Deployments(배포 ) 탭에서 보고 관리할 수 있습니다.

애플리케이션 배포

Add (+)(추가(+)) 버튼을 클릭합니다. 배포를 업로드하거나,관리되지 않는 배포를 추가하거나, 빈 배포를 만들어 애플리케이션을 배포 하도록 선택할 수 있습니다. 배포는 기본적으로 활성화되어 있습니다.

애플리케이션 배포 취소

배포를 선택하고 Undeploy (배포 취소) 옵션을 선택합니다. JBoss EAP는 콘텐츠 리포지토리에서 배포를 제거합니다.

애플리케이션 비활성화

배포를 선택하고 Disable (비활성화) 옵션을 선택하여 애플리케이션을 비활성화합니다. 그러면 배포가 배포 취소되지만 콘텐츠 리포지토리에서 제거되지 않습니다.

애플리케이션 교체

배포를 선택하고 교체 옵션을 선택합니다. 새 버전의 배포(원래와 이름이 동일해야 함)를 선택하고 Finish(완료)를 클릭합니다 . 이 명령은 원래 버전의 배포를 취소 및 제거한 다음 새 버전을 배포합니다.

JBoss EAP 관리 콘솔의 Deployments(배포 ) 탭에서 배포를 보고 관리할 수 있습니다.

애플리케이션 추가

서버 그룹에 애플리케이션 배포

서버 그룹에서 애플리케이션 배포 취소

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

애플리케이션 제거

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

애플리케이션 비활성화

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

애플리케이션 교체

이 명령은 원래 버전의 배포를 취소 및 제거한 다음 새 버전을 배포합니다.

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

배포 스캐너는 관리 콘솔 또는 관리 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 콘텐츠의 자동 배포를 비활성화합니다.

새 배포 스캐너는 관리 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)

새 배포 스캐너가 정의되어 있고 지정된 디렉터리가 배포를 위해 모니터링됩니다.

다음 지침은 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")

다음 지침은 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")

기본적으로 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 지식베이스 문서를 참조하십시오.

기본적으로 HTTP API는 http://HOST:PORT/management (예: http://localhost:9990/management) 에서 액세스할 수 있습니다.

애플리케이션 배포

애플리케이션 배포 취소

배포된 콘텐츠를 저장할 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 인스턴스에서 고유해야 합니다.

관리형 도메인의 사용자 지정 디렉터리 정의

기본적으로 관리형 도메인에 배포된 콘텐츠는 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 인스턴스에서 고유해야 합니다.

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>

이렇게 하면 app .ear 전에 framework.ear 를 배포할 수 있습니다.

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

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

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

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

롤아웃 계획 정보

관리형 도메인에서 도메인 또는 호스트 수준 리소스를 대상으로 하는 작업은 여러 서버에 잠재적으로 영향을 줄 수 있습니다. 이러한 작업에는 작업이 서버에 적용되는 시퀀스를 자세히 설명하는 롤아웃 계획과 일부 서버에서 성공적으로 실행되지 못하면 작업을 되돌릴 수 있는지 자세히 설명하는 정책이 포함될 수 있습니다. 롤아웃 계획을 지정하지 않으면 기본 롤아웃 계획이 사용됩니다.

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

롤아웃 계획 구문

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

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

rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]

롤아웃 계획을 사용하여 배포

롤아웃 설정을 헤더 인수에 전달하여 롤아웃 계획의 전체 세부 사항을 배포 명령에 직접 제공할 수 있습니다. 형식에 대한 자세한 내용은 롤아웃 계획 구문 을 참조하십시오.

다음 관리 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)}

저장된 롤아웃 계획을 사용하여 배포

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

저장된 롤아웃 계획 제거

제거할 롤아웃 계획의 이름을 지정하여 rollout-plan 관리 CLI 명령을 사용하여 저장된 롤아웃 계획을 제거할 수 있습니다.

rollout-plan remove --name=my-rollout-plan

기본 롤아웃 계획

여러 서버에 영향을 미치는 모든 작업은 롤아웃 계획을 사용하여 실행됩니다. 작업 요청에 롤아웃 계획이 지정되지 않은 경우 기본 롤아웃 계획이 생성됩니다. 이 계획은 다음과 같은 특성을 갖습니다.

browse-content 작업을 사용하여 관리되는 배포의 파일과 디렉터리를 확인합니다. 전체 배포 구조를 반환하거나 경로 인수를 사용하여 특정 디렉토리의 경로를 제공하는 인수를 제공하지 않습니다.

/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 작업에 지정할 수도 있습니다.

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"
    }]}
}

attachment display --operation=/deployment=helloworld.war:read-content(path=META-INF/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
...

attachment save --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF) --file=/path/to/MANIFEST.MF

도메인 컨트롤러는 도메인의 중앙 관리 지점 역할을 하는 JBoss EAP 서버 인스턴스입니다. 하나의 호스트 컨트롤러 인스턴스가 도메인 컨트롤러 역할을 하도록 구성됩니다.

도메인 컨트롤러의 주요 책임은 다음과 같습니다.

기본적으로 중앙 관리 정책은 EAP_HOME/domain/configuration/domain.xml 파일에 저장됩니다. 이 파일은 도메인 컨트롤러로 실행하도록 설정된 호스트 컨트롤러의 이 디렉터리에 필요합니다.

domain.xml 파일에는 도메인의 서버에서 사용할 수 있는 프로필 구성이 포함되어 있습니다. 프로필에 는 해당 프로필에서 사용할 수 있는 다양한 하위 시스템의 세부 설정이 포함되어 있습니다. 도메인 구성에는 소켓 그룹 정의와 서버 그룹 정의도 포함됩니다.

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

호스트 컨트롤러의 주요 책임은 서버 관리입니다. 도메인 관리 작업을 위임하고 해당 호스트에서 실행되는 개별 애플리케이션 서버 프로세스를 시작하고 중지합니다.

도메인 컨트롤러와 상호 작용하여 서버와 도메인 컨트롤러 간의 통신을 관리합니다. 도메인의 여러 호스트 컨트롤러는 단일 도메인 컨트롤러와만 상호 작용할 수 있습니다. 따라서 단일 도메인 모드에서 실행되는 모든 호스트 컨트롤러와 서버 인스턴스에는 단일 도메인 컨트롤러가 있으며 동일한 도메인에 속해야 합니다.

기본적으로 각 호스트 컨트롤러는 호스트의 파일 시스템의 압축을 푼 JBoss EAP 설치 파일에 있는 EAP_HOME/domain/configuration/host.xml 파일에서 해당 구성을 읽습니다. host.xml 파일에는 특정 호스트와 관련된 다음 구성 정보가 포함되어 있습니다.

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

프로세스 컨트롤러는 호스트 컨트롤러 프로세스를 생성하고 라이프사이클을 모니터링하는 작은 경량 프로세스입니다. 호스트 컨트롤러가 충돌하면 프로세스 컨트롤러가 이를 다시 시작합니다. 또한 호스트 컨트롤러가 지시한 대로 서버 프로세스를 시작하지만 충돌하는 서버 프로세스를 자동으로 다시 시작하지 않습니다.

프로세스 컨트롤러는 EAP_HOME/domain/log/process-controller.log 파일에 기록합니다. PROCESS_CONTROLLER_JAVA_OPTS 변수를 사용하여 EAP_HOME/bin/domain.conf 파일에서 프로세스 컨트롤러에 대한 JVM 옵션을 설정할 수 있습니다.

서버 그룹은 하나로 관리 및 구성된 서버 인스턴스 컬렉션입니다. 관리형 도메인에서 모든 애플리케이션 서버 인스턴스는 유일한 멤버인 경우에도 서버 그룹에 속합니다. 그룹의 서버 인스턴스는 동일한 프로필 구성 및 배포된 콘텐츠를 공유합니다.

도메인 컨트롤러와 호스트 컨트롤러는 도메인에 있는 모든 서버 그룹의 모든 서버 인스턴스에 표준 구성을 적용합니다.

도메인은 여러 서버 그룹으로 구성될 수 있습니다. 다른 서버 그룹은 다른 프로필 및 배포로 구성할 수 있습니다. 예를 들어 도메인을 다양한 서비스를 제공하는 다양한 서버 계층으로 구성할 수 있습니다.

다른 서버 그룹에도 동일한 프로필 및 배포가 있을 수 있습니다. 예를 들어 애플리케이션이 한 서버 그룹에서 업그레이드된 다음 두 번째 서버 그룹에서 업데이트되어 완전한 서비스 중단을 방지하는 롤링 애플리케이션 업그레이드가 가능합니다.

자세한 내용은 서버 그룹 구성 섹션을 참조하십시오.

서버는 애플리케이션 서버 인스턴스를 나타냅니다. 관리형 도메인에서 모든 서버 인스턴스는 서버 그룹의 구성원입니다. 호스트 컨트롤러는 자체 JVM 프로세스에서 각 서버 인스턴스를 시작합니다.

자세한 내용은 서버 구성 섹션을 참조하십시오.

도메인 및 호스트 컨트롤러는 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

도메인 설정에 따라 도메인 컨트롤러와 충돌하지 않고 에 추가 구성을 연결해야 합니다. 도메인 설정 예도 참조하십시오.

도메인에서 하나의 호스트를 도메인 컨트롤러로 구성해야 합니다.

< 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 에는 이러한 구성 설정이 포함됩니다.

호스트 컨트롤러가 도메인에 등록할 수 있도록 도메인 컨트롤러에 연결하도록 호스트 컨트롤러를 구성해야 합니다.

구성의 <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 를 참조하십시오.

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

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

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

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

호스트 컨트롤러에 구성 파일에 이름이 설정되어 있지 않은 경우 런타임 시 호스트 이름을 전달할 수도 있습니다.

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml  -Djboss.host.name=HOST_NAME

다음은 서버 그룹 정의의 예입니다.

<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

서버 그룹 속성

서버 그룹에는 다음 속성이 필요합니다.

서버 그룹에는 다음과 같은 선택적 속성이 포함됩니다.

기본 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-start 를 false 로 설정하여 호스트 컨트롤러가 시작될 때 이 서버가 시작되지 않도록 합니다.

서버는 관리 CLI를 사용하거나 관리 콘솔 Runtime(런타임 ) 탭에서 구성할 수 있습니다.

서버 추가

다음 관리 CLI 명령을 사용하여 서버를 추가할 수 있습니다.

/host=HOST_NAME/server-config=SERVER_NAME:add(group=SERVER_GROUP_NAME)

서버 업데이트

다음 관리 CLI 명령을 사용하여 서버 특성을 업데이트할 수 있습니다.

/host=HOST_NAME/server-config=SERVER_NAME:write-attribute(name=ATTRIBUTE_NAME,value=VALUE)

서버 제거

다음 관리 CLI 명령을 사용하여 서버를 제거할 수 있습니다.

/host=HOST_NAME/server-config=SERVER_NAME:remove

서버 속성

서버에는 다음 속성이 필요합니다.

서버에는 다음과 같은 선택적 속성이 포함됩니다.

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

다음은 도메인 컨트롤러를 찾기 위한 여러 옵션을 사용하여 호스트 컨트롤러를 구성하는 방법의 예입니다.

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

정적 검색 옵션에는 다음과 같은 필수 속성이 포함됩니다.

위의 예에서 첫 번째 검색 옵션은 성공할 것으로 예상되는 옵션입니다. 두 번째 방법은 페일오버 상태에서 사용될 수 있습니다.

호스트 컨트롤러는 --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 로 이 호스트 컨트롤러를 시작할 때 도메인 컨트롤러를 사용할 수 없는 경우 호스트 컨트롤러는 domain.cached-remote.xml 파일에 저장된 캐시된 구성을 사용하기 시작합니다. 이 파일이 있어야 합니다. 그렇지 않으면 호스트 컨트롤러가 시작되지 않습니다.

이 상태에서 호스트 컨트롤러는 도메인 구성을 수정할 수 없지만 서버를 시작하고 배포를 관리할 수 있습니다.

캐시된 구성으로 시작된 후에도 호스트 컨트롤러는 도메인 컨트롤러에 계속 다시 연결을 시도합니다. 도메인 컨트롤러를 사용할 수 있게 되면 호스트 컨트롤러가 자동으로 다시 연결하고 도메인 구성을 동기화합니다. 일부 구성을 변경하려면 호스트 컨트롤러를 다시 로드해야 할 수 있습니다. 이러한 경우 호스트 컨트롤러에 경고가 기록됩니다.

기본 도메인 컨트롤러에 문제가 발생하는 경우 호스트 컨트롤러가 도메인 컨트롤러 역할을 하도록 승격할 수 있습니다. 호스트 컨트롤러는 먼저 도메인 컨트롤러에서 로컬로 도메인 구성을 캐시 해야 승격 할 수 있습니다.

도메인 구성 캐시

도메인 컨트롤러가 되고자 할 수 있는 모든 호스트 컨트롤러에 --backup 옵션을 사용합니다.

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --backup

그러면 전체 도메인 구성의 복사본이 포함된 EAP_HOME/domain/configuration/ 디렉터리에 domain.cached-remote.xml 파일이 생성됩니다. 호스트 컨트롤러가 도메인 컨트롤러 역할을 하도록 재구성되면 이 구성이 사용됩니다.

<domain-controller>
  <remote username="$local" security-realm="ManagementRealm" ignore-unused-configuration="false">
    <discovery-options>
      ...
    </discovery-options>
  </remote>
</domain-controller>

호스트 컨트롤러를 도메인 컨트롤러로 승격

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

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

이러한 방식으로 시작된 각 인스턴스는 기본 설치 디렉터리(예: EAP_HOME/modules/ )에서 나머지 리소스를 공유하지만 jboss.domain.base.dir 에서 지정한 디렉터리에서 도메인 구성을 사용합니다.

두 시스템에서 관리형 도메인을 생성할 수 있습니다. 한 시스템은 도메인 컨트롤러이고 다른 시스템은 호스트입니다. 자세한 내용은 도메인 컨트롤러 정보를 참조하십시오.

두 시스템에서 관리형 도메인 만들기

시작 시 --controller 매개 변수로 도메인 컨트롤러 주소를 지정하여 관리 CLI에서 도메인을 관리할 수 있습니다.

$ EAP_HOME/bin/jboss-cli.sh --connect --controller=IP1

또는 http://IP1:9990 의 관리 콘솔에서 도메인을 관리할 수 있습니다.

JBoss EAP 7.4 도메인 컨트롤러는 호스트와 서버가 JBoss EAP 6.2 이상을 실행하는 경우 JBoss EAP 6을 실행하는 호스트와 서버를 관리할 수 있습니다.

JBoss EAP 7 관리형 도메인에서 JBoss EAP 6 인스턴스를 성공적으로 관리하려면 다음 작업을 완료합니다.

이러한 작업이 완료되면 관리 CLI를 사용하여 JBoss EAP 7 도메인 컨트롤러에서 JBoss EAP 6 서버와 구성을 관리할 수 있습니다. JBoss EAP 6 호스트는 배치 처리와 같은 새로운 JBoss EAP 7 기능을 활용할 수 없습니다.

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

/host-exclude=EAP64z:write-attribute(name=active-server-groups,value=[eap6-main-server-group])

JBoss EAP 7.4 도메인 컨트롤러는 JBoss EAP의 이전 마이너 릴리스에서 실행 중인 호스트와 서버를 관리할 수 있습니다.

JBoss EAP 7.4 관리형 도메인에서 JBoss EAP 7.3 인스턴스를 성공적으로 관리하려면 다음 작업을 완료합니다.

이러한 작업을 완료한 후에는 관리 CLI를 사용하여 JBoss EAP 7.3 서버 및 구성을 JBoss EAP 7.4 도메인 컨트롤러에서 관리할 수 있습니다.

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

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

JBoss EAP는 프로필을 사용하여 서버에서 사용할 수 있는 하위 시스템을 구성합니다. 프로필은 각 하위 시스템의 특정 구성과 함께 사용 가능한 하위 시스템의 컬렉션으로 구성됩니다. 하위 시스템이 많은 프로필으로 인해 많은 기능 세트가 있는 서버가 생성됩니다. 소규모의 집중적인 하위 시스템 세트가 있는 프로필에는 기능 수가 적지만 풋프린트가 더 작습니다.

JBoss EAP에는 대부분의 사용 사례를 충족해야 하는 5가지 사전 정의된 프로필이 제공됩니다.

기존 프로필이 필요한 기능을 제공하지 않는 경우 JBoss EAP는 사용자 지정 프로필을 정의하는 기능도 제공합니다.

JBoss EAP를 사용하면 기존 프로필을 복제하여 관리형 도메인에서 새 프로필을 생성할 수 있습니다. 이렇게 하면 원본 프로필 구성 및 하위 시스템의 사본이 생성됩니다.

원하는 프로필에서 복제 작업을 사용하여 관리 CLI를 사용하여 프로필을 복제할 수 있습니다.

/profile=full-ha:clone(to-profile=cloned-profile)

복제할 원하는 프로필을 선택하고 Clone (복제)을 클릭하여 관리 콘솔에서 프로필을 복제할 수도 있습니다.

관리형 도메인에서는 프로필의 계층 구조를 만들 수 있습니다. 이를 통해 다른 프로필이 상속할 수 있는 공통 확장 기능을 사용하여 기본 프로필을 생성할 수 있습니다.

관리형 도메인은 domain.xml 에 여러 프로필을 정의합니다. 여러 프로필이 특정 하위 시스템에 대해 동일한 구성을 사용하는 경우 다른 프로필이 아닌 한 위치에만 구성할 수 있습니다. 상위 프로필의 값은 재정의할 수 없습니다.

또한 각 프로필은 자체 충족되어야 합니다. 요소 또는 하위 시스템을 참조하는 경우 참조되는 프로필에 정의해야 합니다.

프로필은 list-add 작업을 사용하고 포함할 프로필을 제공하여 관리 CLI를 사용하여 계층 구조에 다른 프로필을 포함할 수 있습니다.

/profile=new-profile:list-add(name=includes, value=PROFILE_NAME)

호스트 컨트롤러에서 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> 태그 내에 저장됩니다.

서버 그룹을 생성할 때 그룹의 모든 서버에서 사용할 JVM 구성을 지정할 수 있습니다. 다음 관리 CLI 명령은 이전 예제에 표시된 production_jvm JVM 설정을 사용하는 서버 그룹 이름 groupA 생성을 보여줍니다.

/server-group=groupA:add(profile=default, socket-binding-group=standard-sockets)
/server-group=groupA/jvm=production_jvm:add

서버 그룹의 모든 서버는 production_jvm 의 JVM 설정을 상속합니다.

서버 그룹 수준에서 특정 JVM 설정을 재정의할 수도 있습니다. 예를 들어 다른 힙 크기를 설정하려면 다음 명령을 사용할 수 있습니다.

/server-group=groupA/jvm=production_jvm:write-attribute(name=heap-size,value="1024m")

위의 명령을 적용한 후 서버 그룹 groupA 는 production_jvm 에서 JVM 설정을 상속합니다. 단, 재정의된 힙 크기는 1024m 입니다.

사용 가능한 모든 옵션에 대한 설명은 Managed Domain JVM Configuration Attributes 를 참조하십시오.

Runtime → Server Groups (런타임 → 서버 그룹)로 이동하고 서버 그룹을 선택하고 View (보기)를 클릭하고 JVM 탭을 선택하여 JBoss EAP 관리 콘솔에서 서버 그룹 JVM 설정을 편집할 수도 있습니다.

서버 그룹에 대한 이러한 설정은 domain.xml 에 저장됩니다.

기본적으로 개별 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 에 저장됩니다.

기본적으로 모든 JBoss EAP 로그 항목은 server.log 파일에 작성됩니다. 이 파일의 위치는 작동 모드에 따라 다릅니다.

이 파일은 종종 서버 로그라고 합니다. 자세한 내용은 Root Logger 섹션을 참조하십시오.

부팅 중에 JBoss EAP는 Java 환경과 각 서비스의 시작에 대한 정보를 기록합니다. 이 로그는 문제를 해결할 때 유용할 수 있습니다. 기본적으로 모든 로그 항목은 서버 로그에 기록됩니다.

부팅 로깅 구성은 logging.properties 구성 파일에서 지정되며, 이 파일은 JBoss EAP 로깅 하위 시스템이 시작될 때까지 활성화되고 이를 대신합니다. 이 파일의 위치는 작동 모드에 따라 다릅니다.

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

/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"}
        }
        ...
    ]
}

가비지 컬렉션 로깅은 모든 가비지 컬렉션 활동을 일반 텍스트 로그 파일에 기록합니다. 이러한 로그 파일은 진단 목적으로 유용할 수 있습니다. 가비지 컬렉션 로깅은 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

다음 로그 파일이 기본 로깅 구성에 대해 생성됩니다. 기본 구성은 주기적인 로그 핸들러를 사용하여 서버 로그 파일을 작성합니다.

적절한 시작 구성 파일에서 JVM 속성을 설정하여 JBoss EAP의 기본 로케일을 구성할 수 있습니다. 시작 구성 파일은 독립 실행형 서버에 대한 EAP_HOME/bin/standalone.conf 또는 관리형 도메인의 EAP_HOME/bin/domain.conf 입니다.

국제화 및 현지화된 로그 메시지는 이 기본 로케일을 사용합니다. 국제화된 로그 메시지 생성에 대한 정보는 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"

JBoss EAP 루트 로거는 지정된 로그 수준 이상의 모든 로그 메시지를 캡처하여 로그 범주에서 캡처하지 않은 서버로 전송합니다.

기본적으로 루트 로거는 콘솔과 주기적인 로그 핸들러를 사용하도록 구성됩니다. 정기적인 로그 핸들러는 server.log 파일에 작성하도록 구성됩니다. 이 파일은 종종 서버 로그라고 합니다.

자세한 내용은 루트 로거 구성을 참조하십시오.

로그 범주는 캡처할 로그 메시지 집합과 메시지를 처리할 하나 이상의 로그 핸들러를 정의합니다.

캡처할 로그 메시지는 origin 및 로그 수준의 지정된 Java 패키지에 의해 정의됩니다. 해당 패키지의 클래스 및 해당 로그 수준 이상의 클래스의 메시지는 로그 범주에서 캡처되어 지정된 로그 핸들러로 전송됩니다.

로그 카테고리는 자체 핸들러 대신 루트 로거의 로그 핸들러를 선택적으로 사용할 수 있습니다.

자세한 내용은 로그 카테고리 구성을 참조하십시오.

로그 핸들러는 캡처된 로그 메시지가 기록되는 방법을 정의합니다. 사용 가능한 로그 핸들러 유형은 console,file,periodic,size,periodic size,syslog,custom, async 입니다.

로그 핸들러 유형

이러한 각 로그 핸들러 구성에 대한 자세한 내용은 로그 핸들러 구성 섹션을 참조하십시오.

로그 수준은 로그 메시지의 특성 및 심각도를 나타내는 열거된 값입니다. 개발자는 선택한 로깅 프레임워크의 적절한 방법을 사용하여 지정된 로그 메시지 수준을 지정하여 메시지를 보낼 수 있습니다.

JBoss EAP는 지원되는 애플리케이션 로깅 프레임워크에서 사용하는 모든 로그 수준을 지원합니다. 가장 일반적으로 사용되는 로그 수준은 TRACE,DEBUG,INFO,WARN,ERROR, FATAL 입니다.

로그 수준은 로그 범주와 핸들러가 책임지는 메시지를 제한하도록 사용합니다. 각 로그 수준에는 다른 로그 수준에 상대적인 순서를 나타내는 숫자 값이 할당됩니다. 로그 카테고리 및 핸들러에는 로그 수준이 할당되며 해당 수준 이상의 로그 메시지만 처리합니다. 예를 들어 WARN 수준이 있는 로그 핸들러는 수준 WARN ,ERROR, FATAL 의 메시지만 기록합니다.

지원되는 로그 수준

포맷터는 로그 메시지를 포맷하는 데 사용됩니다. 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() 를 호출해야 할 수 있습니다.

사용자 지정 로그 포맷 터를 구성하는 방법에 대한 자세한 내용은 사용자 지정 로그 포맷터 구성을 참조하십시오.

filter-spec 특성을 사용하여 구성된 필터 표현식은 다양한 기준에 따라 로그 메시지를 기록하는 데 사용됩니다. 필터 검사는 항상 포맷되지 않은 원시 메시지에서 수행됩니다. 로거 또는 핸들러에 대한 필터를 포함할 수 있지만 logger 필터는 핸들러에 배치된 필터보다 우선합니다.

/subsystem=logging/console-handler=CONSOLE:write-attribute(name=filter-spec, value="substituteAll(\"WFLY\"\,\"YLFW\")")

기본적으로 JBoss EAP 로깅 하위 시스템은 암시적 로깅 API 종속성을 배포에 추가합니다. 기본적으로 true 인 add-logging-api-dependencies 특성을 사용하여 이러한 암시적 종속성이 배포에 추가되는지 여부를 제어할 수 있습니다.

관리 CLI를 사용하면 암시적 로깅 API 종속성이 배포에 추가되지 않도록 add-logging-api-dependencies 속성을 false 로 설정할 수 있습니다.

/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)

로깅 하위 시스템의 암시적 종속성에 대한 자세한 내용은 JBoss EAP 개발 가이드의 Implicit 모듈 종속성 섹션을 참조하십시오.

이 섹션에서는 관리 CLI를 사용하여 콘솔 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 콘솔 핸들러를 선택하여 관리 콘솔을 사용하여 콘솔 로그 핸들러 를 구성할 수도 있습니다.

콘솔 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.

콘솔 로그 핸들러 추가

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:add

콘솔 로그 핸들러 설정 구성

요구 사항에 따라 다음 콘솔 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 콘솔 로그 핸들러 속성 및 해당 설명의 전체 목록은 Console Log Handler Attributes 를 참조하십시오.

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

이 섹션에서는 관리 CLI를 사용하여 파일 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 파일 핸들러를 선택하여 관리 콘솔을 사용하여 파일 로그 핸들러 를 구성할 수도 있습니다.

파일 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.

파일 로그 핸들러 추가

파일 로그 핸들러를 추가할 때 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 를 참조하십시오.

파일 로그 핸들러 할당

로그 핸들러를 활성화하려면 로거에 할당해야 합니다.

다음 관리 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

이 섹션에서는 관리 CLI를 사용하여 주기적인 회전 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 주기적인 핸들러를 선택하여 관리 콘솔을 사용하여 주기적인 로그 핸들러 를 구성할 수도 있습니다.

정기적인 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.

주기적인 로그 핸들러 추가

정기적인 로그 핸들러를 추가할 때 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)

주기적인 로그 처리기 설정 구성

요구 사항에 따라 다음 정기적인 로그 핸들러 속성 중 하나 이상을 설정해야 할 수 있습니다. 사용 가능한 정규 로그 핸들러 속성 및 해당 설명의 전체 목록은 주기적 로그 핸들러 속성에서 참조하십시오.

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

이 섹션에서는 관리 CLI를 사용하여 크기 회전 로그 핸들러를 구성하는 방법을 보여줍니다. 구성 → 하위 시스템 → 로깅 → 구성을 클릭하고 보기를 클릭하고 핸들러 → 크기 핸들러를 선택하여 관리 콘솔을 사용하여 크기 로그 핸들러 를 구성할 수도 있습니다.

크기 로그 핸들러를 구성하는 데 수행하는 주요 작업은 다음과 같습니다.

크기 로그 핸들러 추가

크기 로그 핸들러를 추가할 때 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 를 참조하십시오.