17장. JBoss EAP 관리
이번 장에서는 JBoss EAP 6의 운영 관리 방법에 대해 소개하고 사용하는 관리 도구에 대해서 설명한다.
JBoss EAP 6의 큰 매력 중의 하나는 이번 장에 소개하는 관리방법들이다. 특히 CLI는 매우 강력한 도구이며, JBoss EAP 6를 사용할 때 많이 애용하는 도구이다. 이번 장에서는 관리도구의 사용법은 물론, 각종 명령어에 대해서도 설명한다. 또, 웹 기반 관리 콘솔의 사용방법에 대해서도 설명한다.
1.관리 개요
JBoss EAP 6에는 이용자의 용도나 사용 목적에 맞춰 사용할 수 있는 여러 종류의 관리 도구를 제공한다.
- CLI(Management Command Line Interface)
명령행 형식으로 JBoss EAP 6의 관리 자원을 제어할 수 있는 관리도구이다. 이용자는 마치 UNIX/Linux의 쉘을 이용하고 있는 것과 같은 명령으로 JBoss EAP 6를 관리할 수 있다. CLI는 JBoss EAP 6의 매우 중 요한 도구이다. 환경 구축 시 구성 설정 확인이나, 운영 및 관리 작업, 서버 가동 상황 확인, 서버 설정을 파일에 저장하는 등 다양한 기능을 제공한다.
- 관리 콘솔(Management Console)
웹 브라우저 기반으로 JBoss EAP 6를 관리하는 방법이다. 관리 콘솔에서 JBoss EAP 6의 자원의 설정, 변경 및 추가, 애플리케이션의 배포 및 제거(deploy, undeploy), 시작과 정지등 명령의 실행과 JBoss EAP 6 인스턴스의 모니터링 등 많은 기능을 제공한다. 웹 기반 관리 콘솔에서 실행할 수 있는 오퍼레이션이나 변경할 수 있는 설정 항목은 CLI 보다 작다. 하지만 개발 중이나 운영환경 등에서 웹 브라우저를 사용해 편리하게 확인할 수 있는 관리도구이다.
- JConsole
JBoss EAP 6에서는 Java의 JConsole을 확장한 JBoss 독자적인 JConsole를 제공하고 있다. Java 표준으로 제공하는 JMX MBean 기능과 JBoss CLI의 명령을 JConsole에서 실행할 수 있도록 확장한 것이다. JBoss JConsole을 실행하려면 $JBOSS_HOME/bin에서 jconsole.sh을 실행한다.
이외에도 HTTP/JSON(RESTful)을 사용하여 Java나 Groovy, Ruby같은 프로그래밍 언어로 개발해 연결하거나, iPhone용 관리 애플리케이션을 사용할 수도 있다.

그림1. JBoss EAP 6의 다양한 관리도구
2.관리 서비스
JBoss EAP 6에는 JBoss의 기반 서비스 중에 Management라고 불리는 관리 서비스가 포함되었 다. 관리 인터페이스는 네이티브 매니지먼트 엔드 포인트, HTTP 관리 엔드 포인트의 두 가지 있다.
- 네이티브 매니지먼트 엔드 포인트 JBoss EAP 6의 네이티브 프로토콜을 사용한 애플리케이션 서버의 관리 레이어에 접속하기 위한 엔드 포인트. 관리 CLI, 및 JConsole등에서 사용.
- HTTP 매니지먼트 엔드 포인트 HTTP 프로토콜을 이용하여 애플리케이션 서버의 관리 레이어에 접속하기 위한 엔드 포인트. 관리 콘솔에서 사용.
JBoss EAP 6에서 제공되는 각 관리도구는 위의 매니지먼트 엔드 포인트를 통해 관리서비스에 요청을 보내고 결과를 가져온다.
개요
JBoss EAP 6를 운영하고 관리할 때 현재 자원에 대한 조회, 등록 등 다양한 오퍼레이션이 필요하다. JBoss EAP 6에서는 관리 서비스에 오퍼레이션을 요청하는 형태로 처리한다. 오퍼레이션 요청 내용은 JBoss DMR(Dynamic Model Representation)이라는 모델(이후 DMR 모델)로 표현되며, 오퍼레이션 요청을 하면 내부적으로 DMR 모델로 정의하여 관리 서버에 요청하게 된다.

그림 2. DMR 모델 구조
위의 DMR 모델 구조를 살펴 보면, JBoss에서 운영 모니터링에서 조작할 수 있는 관리 리소스를 주소로 지정하여 해당 주소의 리소스에 대해서 관리 명령을 실행한다. : 다음에 오퍼레이션을 지정한다. 어떤 리소스인지 ‘주소’에 따라 사용 가능한 오퍼레이션이 다르다. 또 오퍼레이션 실행 시 넘겨줄 파라미터 값들을 오 퍼레이션 다음의 괄호 안에 컴마로 구분한 name=value 형태로 지정하여 해당 리소스에 대해 오퍼레이션을 실행한다.
서버 측에서는 DMR 모델에 있는 오퍼레이션을 처리하는 핸들러를 이용해 처리하게 된다. 오퍼레이션을 처리할 핸들러는 서비스 컨트롤러를 통해 서비스 컨테이너에 있는 서비스에서 밸류 오브젝트(Value Object)를 얻는다. 그 밸류 오브젝트에 포함되는 정보를 참조하거나, 변경해 그 처리 결과를 응답용 DMR 모델로 설정하고 결과를 클라이언트에 반환한다.
도메인 모드 관리
도메인 모드에서 관리 인터페이스를 설명한다.

그림 3. 도메인 모드의 관리 인터페이스
JBoss EAP 6 관리자 관리
관리자 등록
JBoss EAP 6 의 관리 사용자는 $JBOSS_HOME/bin/add-user.sh 스크립트를 실행하여 등록한다.
스크립트의 실행 방법은 다음과 같다.
$ ./add-user.sh
What type of user do you wish to add?
{empty}a) Management User (mgmt-users.properties)
{empty}b) Application User (application-users.properties)
(a): a
Enter the details of the new user to add.
Realm (ManagementRealm) :
Username : admin
Password : [패스워드 입력]
Re-enter Password : [패스워드 입력]
About to add user 'jboss' for realm 'ManagementRealm'
Is this correct yes/no? yes
Added user 'jboss' to file '/EAP6book/jboss/jboss-eap-6.2/standalone/configuration/mgmt-users.properties'
Added user 'jboss' to file '/EAP6book/jboss/jboss-eap-6.2/domain/configuration/mgmt-users.properties'
Is this new user going to be used for one AS process to connect to another AS process?
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? yes
To represent the user add the following to the server-identities definition <secret value="b3Blbm5hcnUhMjM0" />
JBoss EAP 6에서 스탠드얼론 모드, 도메인 모드 모두 관리 인터페이스(네이티브 관리 인터페이스와 HTTP 관리 인터페이스)는 ‘ManagementRealm’라는 시큐리티 범위에 포함되었다. 이 시큐리티의 구조를 시큐리티 영역이라고 말한다. 시큐리티 영역은 인증 및 접근 등의 방법을 정의한 것으로, 관리 인터페이스에서는 정의된 시큐리티 영역명을 지정하면 된다. 이 때문에 관리 사용자를 추가할 때, add-user.sh 스크립트 실행시 ‘ManagementRealm’ 보안 영역을 선택해야 한다. ManagementRealm 은 기본적으로 다음 파일에 정의된 사용자를 사용하여 인증한다.
add-user.sh 스크립트를 실행하여 관리자를 추가하면 다음의 두 개의 파일에 [사용자명=암호화된 패스워드] 의 형식으로 관리자가 추가된다.
$JBOSS_HOME/standalone/configuration/mgmt-users.properties$JBOSS_HOME/domain/configuration/mgmt-users.properties
시스템 프로퍼티(jboss.server.base.dir, jboss.domain.base.dir)를 사용해 베이스 디렉터리를 변경해 JBoss 를 시작하는 경우, 이 두 파일을 설정한 시스템 프로퍼티 디렉터리 아래의 configuration/mgmt-users.properties 로 복사해야 한다.
호스트 컨트롤러와 도메인 컨트롤러간 통신 보안 설정
관리 콘솔 및 CLI로부터 호스트 컨트롤러로 접근은 호스트의 mgmt-users.properties 파일에 정의된 관리자를 사용해 인증한다.
아래와 같이 host.xml파일에서 <authentication>에서 관리자가 저장된 파일을 지정한다.
<management>
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<local default-user="$local" />
<properties path="*mgmt-users.properties*" relative-to="jboss.domain.config.dir"/>
</authentication>
</security-realm>
…
</management>
host.xml 파일에 관리자가 등록되지 않은 경우에는 관리 콘솔 또는 CLI 에서 호스트 컨트롤러에 접속할 수 없다. 다만, 호스트와 동일한 IP에서 실행한 CLI 에서는 인증 없이 접근할 수 있도록 정의되어 있어 호스트 컨트롤러에 접근(이하 로컬 접근) 하는 것이 가능하다.
Host1, Host2, Host3의 각 호스트에서 각각 user1, user2, user3 의 관리자를 정의했을 경우, 이 사용자는 각각 자신이 정의한 호스트에서 가동하는 호스트 컨트롤러에만 접근 가능하다. 다만, user1 는 도메인 컨트롤러를 경유해 Host2, Host3 에 대한 관리 오퍼레이션이 가능하고, 각 호스트가 실행되는 같은 IP에서 시작한 CLI 에서는 호스트 컨트롤러에 로컬 접근하는 것도 가능하다.
도메인 모드에서는 마스터가 되는 도메인 컨트롤러상에 작성된 관리자가 같은 도메인에 포함된 모든 호스트를 관리한다. 이 때문에 슬레이브가 되는 호스트에 관리자를 추가할 필요는 없다. 또, 슬레이브 측의 관리 콘솔을 위한 HTTP 관리 인터페이스(http-interface)를 없애 버리는 것도 가능하다. 슬레이브 측의 native-interface(9999 포트에 바인드)는 도메인 컨트롤러로부터 접근할 필요가 있기 때문에 삭제할 수 없다.
관리 인터페이스의 바인드 주소
운영환경에서는 보안을 고려하여 애플리케이션이 서비스되는 서버 인스턴스의 리슨 주소 설정인 ‘public’ 인터페이스를 애플리케이션 사용자가 액세스 가능한 네트워크 주소에 바인드하며, ‘management’ 인터페이스는 애플리케이션 사용자가 접근할 수 없는(관리용의 네트워크 세그먼트) 주소에 바인드한다.
관리 자원 구조
JBoss EAP 6의 구축 및 설정 시, 특히 관리 CLI를 사용하는 경우엔 관리 자원이 어떤 형태의 트리로 구성되는지 파악해야 한다. 기본적으로 스탠드얼론 모드에서는 standalone.xml등의 설정 파일의 schema에 따라 트리가 구성되지만, 도메인 구성에서는 도메인 모델에 맞는 트리가 구성된다.
관리 자원들은 JBoss EAP 6 시작시 설정 파일을 바탕으로 구축되어 관리 인터페이스를 통해 자원에 접근할 수 있다. 또, 관리 자원이 변경되었을 경우에는 설정 파일에 변경사항이 반영되고 관리된다.
관리 자원 요소
관리 자원은 루트에서 시작되는 계층 트리로 구성되어 트리 상의 각 관리 자원은 노드로 표현된다. 관리 자원은 노드를 구성하는 중요 요소로 다음 표의 항목들을 갖추고 있어 부모 노드가 되는 관리 자원이 자식 노드를 생성할 수 있는 형태가 정해진다.
| 구분 | 작업 |
|---|---|
| 노드명 | 관리 자원을 나타내는 이름 |
| 형태(Type) | 관리 자원 자체의 형태 부모 노드의 관리 자원에 대해 자식 노드 형태(Child)로 정의되어 있어야 한다. |
| 오퍼레이션(Operations) | 관리 자원에 대한 조작 관리 자원의 추가 및 삭제, 속성을 읽어 변경하는 등의 조작 |
| 속성(Attribute) | 관리 자원의 속성(각종 정보)을 나타내는 이름의 변수 속성마다 다음 항목들이 정의되었다 * 속성명 * 속성값의 형태 * 읽기 전용/읽고 쓰기 가능 * 저장되는 값으로 실행 시만 이용 가능한 값 |
| 자식노드형(Child-Type) | 자식 노드를 가질 수 있는 관리 자원의 형태 |
표 1. 관리 자원 구성요소
관리 리소스 계층 트리
관리 자원은 루트 노드로부터 시작되는 계층 트리로 구성되었다. 계층 트리는 관리 모델에 따라 일부 다르지만 기본적으로는 같은 형태이다.
스탠드얼론 모드의 경우, 루트 바로 아래에 childrens-types 관리 자원이 구성되었다.


그림 4. 관리 리소스의 계층 구조
3.주요 설정 항목
JBoss EAP 6에서는 어느 모듈을 이용하는지를 선택할 수 있어, 사용자가 이용하고 싶은 기능을 선택할 수 있다. 미리 준비되어 있는 각 프로파일에는 어떤 기능, 즉 어떤 모듈을 사용할 것인지가 설정 파일(standalone.xml, domain.xml 등)에 정의되었다. 일반적으로JBoss EAP의 설정은 관리 콘솔이나 CLI등의 관리 UI를 통해서 수행되지만, 그 내용도 설정 파일(standalone.xml, host.xml등)에 저장된다. 여기에서 설정 파일을 구성하는 XML 엘리먼트들을 기본적인 설정의 컨셉에 따라서 설명한다. 설정 파일의 주요한 설정 항목은 아래와 같다.
| 구분 | 엘리먼트 | 설명 |
|---|---|---|
| extension | extensions | JBoss EAP 코어 기능확장 모듈 |
| 서브시스템 | subsystems | 모듈들의 기능 세트 |
| 프로파일 | profile | 이용하는 서브시스템 정의 |
| 패스 | path | 파일 시스템 패스의 논리적인 이름 정의 |
| 매니지먼트 | management | Realm / interface의 바인딩 |
| 인터페이스 | interfaces | 바인딩 가능한 IP주소 |
| 소켓 바인딩 | socket-binding-group | 소켓 그룹의 이름 설정 |
| 시스템 프로퍼티 | system-properties | 시스템 프로퍼티 정의 |
| JVM | jvms | jvm 시작 옵션 |
표 2. 주요 설정 항목
extension
extension은 JBoss EAP 6의 코어 기능을 확장하는 모듈이다. JBoss EAP 6의 코어로 정의하는 모듈은 최소한의 기능만으로 구성되어 있어 사용자가 이용하는 대부분의 기능은 extension으로 제공되고 있다. extension들은 JBoss가 설치된 디렉터리에 있는 modules 디렉터리에 모듈로서 패키징 되었다. 각 프로파일에서 사용되는 모듈은 설정 파일의 extension 내의 모듈 이름이 정의된다.
<extensions>
<extension module="org.jboss.as.clustering.infinispan"/>
<extension module="org.jboss.as.clustering.jgroups"/>
<extension module="org.jboss.as.cmp"/>
<extension module="org.jboss.as.configadmin"/>
<extension module="org.jboss.as.connector"/>
<extension module="org.jboss.as.ee"/>
<extension module="org.jboss.as.ejb3"/>
<extension module="org.jboss.as.jacorb"/>
<extension module="org.jboss.as.jaxr"/>
<extension module="org.jboss.as.jaxrs"/>
<extension module="org.jboss.as.jdr"/>
<extension module="org.jboss.as.jmx"/>
<extension module="org.jboss.as.jpa"/>
<extension module="org.jboss.as.jsf"/>
<extension module="org.jboss.as.jsr77"/>
<extension module="org.jboss.as.logging"/>
<extension module="org.jboss.as.mail"/>
<extension module="org.jboss.as.messaging"/>
<extension module="org.jboss.as.modcluster"/>
<extension module="org.jboss.as.naming"/>
<extension module="org.jboss.as.pojo"/>
<extension module="org.jboss.as.remoting"/>
<extension module="org.jboss.as.sar"/>
<extension module="org.jboss.as.security"/>
<extension module="org.jboss.as.threads"/>
<extension module="org.jboss.as.transactions"/>
<extension module="org.jboss.as.web"/>
<extension module="org.jboss.as.webservices"/>
<extension module="org.jboss.as.weld"/>
</extensions>
위의 예에서는 트랜잭션, 웹, 클러스터링, 메시징, 웹 서비스, Weld등이 정의되어 있어 full-ha 프로파일이라는 것을 알 수 있다.
서브시스템
서브시스템(subsystems)은 서블릿, EJB 컨테이너, JTA등의 서비스를 제공하는 모듈들의 기능 집합이다. 사용하는 모듈에 대한 상세 설정은, 설정 파일의 subsystem 내에 모듈 이름이 정의되어 서브시스템 시작시 초기화 파라미터 등이 지정된다. extension과 서브시스템의 관계는, extension이 이용하는 모듈 자체의 정의라고 하면, 서브시스템은 그 모듈을 기능으로서 인스턴스화 할 때의 구체적인 설정 정의라고 할 수 있다.
<subsystem xmlns="urn:jboss:domain:infinispan:1.4">
<cache-container name="web" aliases="standard-session-cache" default-cache="local-web" module="org.jboss.as.clustering.web.infinispan">
<local-cache name="local-web" batching="true">
<file-store passivation="false" purge="false"/>
</local-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query" module="org.jboss.as.jpa.hibernate:4">
<local-cache name="entity">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="local-query">
<transaction mode="NONE"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="timestamps">
<transaction mode="NONE"/>
<eviction strategy="NONE"/>
</local-cache>
</cache-container>
</subsystem>

그림 5. extension과 서브시스템 설정
extensions 과 서브시스템의 관계는 다음과 같다.
| 구분 | extension | Subsystem | |
|---|---|---|---|
| standalone | infinispan | org.jboss.as.clustering.infinispan | urn:jboss:domain:infinispan:1.4 |
| datasources | org.jboss.as.connector | urn:jboss:domain:datasources:1.1 | deployment-scanner |
| org.jboss.as.deployment-scanner | urn:jboss:domain:deployment-scanner:1.1 | ee | org.jboss.as.ee |
| urn:jboss:domain:ee:1.1 | ejb3 | org.jboss.as.ejb3 | urn:jboss:domain:ejb3:1.4 |
| jaxrs | org.jboss.as.jaxrs | urn:jboss:domain:jaxrs:1.0 | jdr |
| org.jboss.as.jdr | urn:jboss:domain:jdr:1.0 | Jmx | org.jboss.as.jmx |
| urn:jboss:domain:jmx:1.2 | jpa | org.jboss.as.jpa | urn:jboss:domain:jpa:1.1 |
| Jsf | org.jboss.as.jsf | urn:jboss:domain:jsf:1.0 | logging |
| org.jboss.as.logging | urn:jboss:domain:logging:1.2 | org.jboss.as.mail | |
| urn:jboss:domain:mail:1.1 | naming | org.jboss.as.naming | urn:jboss:domain:naming:1.3 |
| pojo | org.jboss.as.pojo | urn:jboss:domain:pojo:1.0 | remoting |
| org.jboss.as.remoting | urn:jboss:domain:remoting:1.1 | sar | org.jboss.as.sar |
| urn:jboss:domain:sar:1.0 | security | org.jboss.as.security | urn:jboss:domain:security:1.2 |
| threads | org.jboss.as.threads | urn:jboss:domain:threads:1.1 | transactions |
| org.jboss.as.transactions | urn:jboss:domain:transactions:1.3 | web | org.jboss.as.web |
| urn:jboss:domain:web:1.4 | webservices | org.jboss.as.webservices | urn:jboss:domain:webservices:1.2 |
| weld | org.jboss.as. weld | urn:jboss:domain:weld:1.0 .5+ | standalone-full |
| cmp | org.jboss.as.cmp | urn:jboss:domain:cmp:1.1 | jacorb |
| org.jboss.as.jacorb | urn:jboss:domain:jacorb:1.3 | jaxr | org.jboss.as.jaxr |
| urn:jboss:domain:jaxr:1.1 | jsr77 | org.jboss.as.jsr77 | urn:jboss:domain:jsr77:1.0" |
표 3. extentions와 서브시스템 간의 관계
도메인 모드의 서브시스템과 extension
도메인 모드에서 하나의 설정 파일 domain.xml 에 모든 프로파일이 정의되어 있기 때문에 extension은 스탠드얼론 모드에서의 전체 기능 standalone-full-ha.xml 와 거의 같은 정의가 되었다. 한가지 차이점은 스탠드얼론 모드에만 deployment-scanner가 있다는 점이다.
반대로, 서브시스템에 대해서는 스탠드얼론 모드에서의 4개의 설정 파일에 해당하는 정의가 하나의 domain.xml파일내에 4개의 프로파일로 설정되었다.
서브시스템의 삭제
JBoss EAP 6에서는 MSC(Modular Service Container)에 의해 서비스(코어 모듈)의 추가, 삭제를 매우 쉽게 할 수 있다. 다음에서 불필요한 서비스의 삭제 방법을 살펴보자.
각 프로파일에서 특정의 서비스를 삭제하려면 설정 파일(standalone.xml, domain.xml 등)에서 해당의 모듈 정의인 <extension>와 <subsystem>를 삭제한다. modules 디렉터리에서 해당의 모듈 자체를 삭제한다.
서브시스템을 삭제하고자 할 경우, 다른 모듈에서 사용되기 때문에 삭제 시 오류가 발생할 수 있는데 아래 모듈들은 대표적인 삭제 가능한 모듈들로 이에 대한 삭제 방법을 설명한다.
| 구분 | 삭제 방법 |
|---|---|
| H2데이타베이스 | <datasource jndi-name="java:jboss/datasources/ExampleDS" …/> 태그 삭제 modules/com/h2database 디렉토리 삭제 |
| 배포스캐너 | <extension module="org.jboss.as.deployment-scanner"/> 태그 삭제 <subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1"/> 태그 삭제 modules/org/jboss/as/deployment-scanner 디렉토리 삭제 |
| 메일 | <extension module="org.jboss.as.mail"/> 태그 삭제 <subsystem xmlns="urn:jboss:domain:mail:1.0"/> 태그 삭제 <outbound-socket-binding name="mail-smtp"/> 태그 삭제 modules/org/jboss/as/mail 디렉토리 삭제 |
| HornetQ | <extension module="org.jboss.as.messaging"/> 태그 삭제 <subsystem xmlns="urn:jboss:domain:messaging:1.2"/> 태그 삭제 <socket-binding name="messaging-throughput" port="5455"/> 태그 삭제 modules/org/jboss/as/messaging 디렉터리 삭제 |
프로파일
프로파일(profile)은 서브시스템들을 묶어놓은 세트이며, extension에 의해 JBoss EAP 6 코어에 추가된 추가 기능 세트이다. 여러 개의 서브시스템을 포함하고 있는 프로파일은 결과적으로 여러 개의 기능 세트를 제공하는 서버가 된다. 몇 개의 서브시스템만으로 정의된 프로파일은 소규모 기능을 가진 서버가 되어 메모리 사용량이 작은 가벼운 서버가 된다. 예를 들면, 풀 프로파일의 프로파일 정의 파일인 standalone-full.xml 는 웹 컨테이너 만이 아니라 EJB나 JMS등의 Java EE의 전체 기능을 제공하기 때문에, 여러 개의 서브시스템 정의를 포함하지만, 웹 프로파일 정의인 standalone.xml 파일은 웹 컨테이너를 중심으로 한 기능만 제공하기 때문에 보다 적은 서브시스템 정의만 가지고 있다.
스탠드얼론 모드로 정의되는 프로파일(설정 파일명)과 도메인 모드로 정의되는 프로파일 및 각 프로파일에서 사용되는 서브시스템은 다음과 같다.

표 4. 스탠드얼론 모드와 도메인 모드의 프로파일 비교
패스
파일 시스템 패스(path)의 논리적인 이름으로 설정 파일 내부의 다른 부분에서 참조된다.
예를 들어 로깅 서브시스템은 jboss.server.log.dir의 값을 참조하여 서버 log 디렉터리를 지정하게 된다.”
<file relative-to="jboss.server.log.dir" path="server.log"/>
| 구분 | 패스(path) | |
|---|---|---|
| jboss.home.dir | $JBOSS_HOME | JBoss EAP 6 의 루트 디렉터리 |
| user.home | $HOME | 사용자의 홈디렉터리 |
| jboss.server.base.dir | <jboss.home.dir>/standalone | 서버 구성의 루트 디렉터리 |
| jboss.server.config.dir | <jboss.server.base.dir>/configuration | 설정의 베이스 디렉터리 |
| jboss.server.data.dir | <jboss.server.base.dir>/data | 데이터 파일 저장 디렉터리 |
| jboss.server.log.dir | <jboss.server.base.dir>/log | 로그 파일 저장 디렉터리 |
| jboss.domain.base.dir | <jboss.home.dir>/domain | 도메인 모드의 루트 디렉터리 |
| jboss.domain.config.dir | <jboss.domain.base.dir>/configuration | 도메인 설정의 베이스 디렉터리 |
| jboss.domain.data.dir | <jboss.domain.base.dir>/data | 도메인 데이터 파일 저장 디렉터리 |
| jboss.domain.log.dir | <jboss.domain.base.dir>/log | 도메인 로그 파일 저장 디렉터리 |
표 5. 주요 패스(path)
매니지먼트
보안 영역의 설정과 관리용 인터페이스를 정의하는 속성이다.
기본값은 ApplicationRealm와 ManagementRealm의 두개가 파일로 정의되었다. 각각의 Realm에서 사용하는 파일들은 application-realm.properties, application-roles.properties과 management-realm.properties로 정의되었다.
또, 네이티브 관리 포트와 HTTP의 관리 포트의 인터페이스 정의는 ManagementRealm을 사용하도록 보안 설정이 되었다.
인터페이스
소켓이 바인드 가능한 IP주소과 호스트이름의 논리적인 이름을 정의하는 속성이다. 정의된 인터페이스는 다른 설정에서 인터페이스의 논리적 이름으로 참조된다. 인터페이스 설정에는 주소나 인터페이스의 논리적 이름 뿐만 아니라 NIC 설정이나 subnet mask등의 정보도 설정할 수 있다.
<management>
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<local default-user="$local"/>
<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
</security-realm>
<security-realm name="ApplicationRealm">
<authentication>
<local default-user="$local" allowed-users="*"/>
<properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
</security-realms>
<management-interfaces>
<native-interface security-realm="ManagementRealm">
<socket-binding native="management-native"/>
</native-interface>
<http-interface security-realm="ManagementRealm">
<socket-binding http="management-http"/>
</http-interface>
</management-interfaces>
</management>
<interfaces>
<interface name="management">
<inet-address value="$\{jboss.bind.address.management:127.0.0.1}"/>
</interface>
<interface name="public">
<inet-address value="$\{jboss.bind.address:127.0.0.1}"/>
</interface>
<interface name="unsecure">
<inet-address value="$\{jboss.bind.address.unsecure:127.0.0.1}"/>
</interface>`
</interfaces>
소켓 바인딩 그룹
소켓 바인딩 그룹(socket-binding-group)은 포트들의 집합에 이름을 정의하는 속성으로 인터페이스 정의를 참조해 정의한다. 정의된 소켓 바인딩 그룹 설정도 다른 정의에서 논리적 이름으로 참조된다.
또, 각 프로파일마다 필요한 소켓 정의가 그룹으로 정의된다.
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="$\{jboss.socket.binding.port-offset:0}">
<socket-binding name="management-native" interface="management" port="$\{jboss.management.native.port:9999}"/>
<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:9443}"/>
<socket-binding name="ajp" port="8009"/>
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8443"/>
<socket-binding name="remoting" port="4447"/>
<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>
여러 개의 포트를 개별적으로 변경하는 것도 가능하지만, 소켓 바인딩에서는 포트 오프셋(port-offset)라고 하는 개념을 가지고 있다. 이 기능은 JBoss가 사용하는 여러 포트에 대해서 일률적으로 값을 더해 사용하는 포트 번호를 일괄 변경하는 것으로 IP주소가 1개 밖에 사용할 수 없는 환경에서도 포트가 충돌하지 않고 여러 개의 JBoss EAP 인스턴스를 사용할 수 있다.
시스템 프로퍼티
Java의 시작 시에 넘겨주는 시스템 프로퍼티를 설정 파일에서 정의하기 위한 속성이다.
property 속성으로 여러 개의 시스템 프로퍼티를 정의할 수 있다.
<system-properties>
<property name="java.net.preferIPv4Stack" value= "true"/>
</system-properties>
시스템 프로퍼티를 관리 CLI로 설정하는 경우의 예는 아래와 같다.
[standalone@localhost:9999 /] ./system-property=org.apache.catalina.JSESSIONID:add(value="MYID")
{"outcome" => "success"}
JVM
Java실행시의 옵션을 설정 파일에 정의하기 위한 속성이다. JVM의 파라미터 정의를 여러 개 정의해 두고, 서버 그룹마다 사용할 JVM정의를 바꾸는 것이 가능하다. 이것은 스탠드얼론 모드에서는 존재하지 않고 도메인의 프로파일에서만 설정 가능하다.
<jvms>
<jvm name="default">
<heap size="64m" max-size="256m"/>
<permgen size="256m" max-size="256m"/>
<jvm-options>
<option value="-server"/>
</jvm-options>
</jvm>
</jvms>
VFS
VFS(Virtual File System)는 파일 시스템을 추상화 하는 기능으로, JBoss EAP 6 의 클래스 로더 정책의 자원 문제를 해결하기 위해 사용되고 있다. JBoss EAP 5에서 추가되어 JBoss EAP 6에서도 라이브러리로 사용 하고 있다. VFS를 이용하는 것은 몇 가지 장점이 있다.
우선, VFS를 이용하는 일은 archive파일과 archive파일을 풀어서 배포하는(exploded) 방법과 똑같이 취급할 수 있어 VFS를 이용하여 배포하면 아카이브(archive)화하는 작업을 줄일 수 있다. 이 때문에, 개발 시에는 변경된 파일만 교체하면 배포가 끝나기 때문에, 배포가 빨라져 개발 생산성을 높일 수 있다. 다시 말하면, deployments 디렉터리에 example.war 파일을 배포했을 경우와 example.war 풀어놓은 디렉터리를 배포했을 경우가 같게 다룬다.

그림 6. VFS의 구조
또, VFS에서는 JDK의 파일 조작 API보다 더 추상화된 사용하기 쉬운 API를 제공하고 있다.
예를 들어, Windows상에서 파일이 락이 걸리면 배포할 수 없게 되어 버리지만, 임시 파일을 작성하여 처리하는 방식을 사용하여 피해갈 수 있다. 파일 핸들에 대한 처리가 VFS내부에 포함되어 있기 때문에 기존의 Windows 상에서 파일 락과 같은 문제를 해결하고 있다.
4.CLI
CLI 실행 방법이나 조작 방법에 대해 설명한다.
CLI 실행 방법
CLI는 서버(스탠드얼론 서버 또는 도메인 컨트롤러)가 시작된 상태에서 실행하여 대상 서버에 접속해 각종 관리 명령을 실행한다.
CLI 시작
CLI의 실행은 $JBOSS_HOME/bin 폴더에서 jboss-cli.sh의 스크립트를 실행하면 된다.
아래와 같은 명령을 실행하면 CLI의 파라미터 목록이 표시된다.
$./jboss-cli.sh --help
Usage: jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
……
jboss-cli.sh 주요 옵션들은 다음과 같다.
| 옵션 | 설명 |
|---|---|
--help(-h) | jboss-cli 도움말 표시한다. |
--version | OS, JVM, JBoss의 버전 정보와 환경 변수를 표시한다. |
--controller | --connect의 명령으로 접속할 호스트명과 포트 번호를 지정한다. --controller=IP주소:포트 형식으로 입력한다. 생략시 localhost:9999가 사용된다. |
--connect(-c) | CLI를 시작하면 바로 서버에 접속한다. |
--gui | GUI 모드로 시작한다. |
--file | 배치 모드로 실행할 경우, 명령어와 오퍼레이션을 포함한 파일 경로를 지정한다. |
--command | 실행할 명령어 또는 오퍼레이션을 지정한다. |
--commands | 실행할 여러 개의 명령어 또는 오퍼레이션을 컴마로 구분하여 지정한다. |
--user | JBoss 관리자 아이디 |
--password | JBoss 관리자 패스워드 |