| 1. 관리 개요 |
JBoss EAP 6에는 이용자의 용도와 사용 목적에 맞춰 사용할 수 있는 여러 종류의 관리 도구를 제공합니다.
- CLI(Management Command Line Interfcase)
명령행 형식으로 JBoss EAP 6의 관리 자원을 제어할 수 있는 관리도구입니다. 이용자는 마치 UNIX/Linux의 쉘을 이용하고 있는 것과 같은 명령으로 JBoss EAP 6를 관리할 수 있습니다. CLI는 JBoss EAP 6의 매우 중요한 도구입니다. 환경 구축 시 구성 설정 확인이나, 운영 및 관리 작업, 서버 가동 확인, 서버 설정을 파일에 저장하는 등 다양한 기능을 제공합니다.
- 관리 콘솔(Management Conosole)
웹 브라우저 기반으로 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용 관리 애플리케이션을 사용할 수도 있습니다.
| 2. 관리 서비스 |
JBoss EAP 6에는 JBoss의 기반 서비스 중에 Management라고 불리는 관리 서비스가 포함되어 있습니다. 관리 인터페이스는 네이티브 엔드 포인트, HTTP 관리 엔드 포인트의 두 가지가 있습니다.
- 네이티브 매니지먼트 엔드 포인트 : JBoss EAP 6의 네이티브 프로토콜을 사용한 애플리케이션 서버의 관리 레이어에 접속하기 위한 엔드 포인트로 HTTP 관리 엔드 포인트, 관리 CLLI 및 JBoss 등에서 사용
- HTTP 매니지먼트 엔드 포인트 HTTP 프로토콜을 사용하여 애플리케이션 서버의 관리 레이어에 접속하기 위한 엔드 포인트, 관리 콘솔에서 사용
JBoss EAP 6에서 제공되는 각 관리도구는 위의 매니지먼트 엔드 포인트를 통해 관리 서비스에 요청을 보내고 결과를 가져옵니다.
(1) 개요
JBoss EAP 6를 운영하고 관리할 때 현재 자원에 대한 조회, 등록 등 다양한 오퍼레이션이 필요합니다. JBoss EAP 6에서는 관리 서비스에 오퍼레이션을 요청하는 형태로 처리합니다. 오퍼레이션 요청 내용은 JBoss DMR(Dynamic Model Representation)이라는 모델(이후 DMR 모델)로 표현되며, 오퍼레이션 요청을 하면 내부적으로 DMR 모델로 정의하여 관리 서버에 요청하게 됩니다.
위의 DMR 모델 구조를 살펴보면, JBoss에서 운영 모니터링에서 조작할 수 있는 관리 리소스를 주소로 지정하여 해당 주소의 리소스에 대해서 관리 명려을 실행합니다. ':' 다음에 오퍼레이션을 지정합니다. 어떤 리소스인지 '주소'에 따라 사용 가능한 오퍼레이션이 다릅니다. 또, 오퍼레이션 실행 시 넘겨줄 파라미터 값들을 오퍼레이션 다음의 괄호 안에 컴마로 구분한 name=value 형태로 지정하여 해당 리소스에 대해 오퍼레이션을 실행합니다.
서버 측에서는 DMR 모델에 있는 오퍼레이션을 처리하는 핸들러를 이용해 처리하게 됩니다. 오퍼레이션을 처리할 핸들러는 서비스 컨트롤러를 통해 서비스 컨테이너에 있는 서비스에서 밸류 오브젝트(Value Object)를 얻습니다. 그 밸류 오브젝트에 포함되는 정보를 참조하거나, 변경해 그 처리 결과를 응답용 DMR 모델로 설정하고 결과를 클라이언트에 반환합니다.
(2) 도메인 모드 관리
도메인 모드에서 관리 인터페이스를 설명합니다.
(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?
a) Management User (mgmt0users.properties)
b) Application User (application-users.properties)
(a): a
Enter the details fo 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 '/CLOUD/JBOSS/jboss-eap-6.2/standalone/configuration/mgmt-users.properties'
Added user 'jboss' to file 'CLOUD/JBOSS/jboss-eap-6.2/domain/configuration/mgmt-users.properties'
Is this new user going to be used for on AS process to connect to another AS process?
e.g. for a slave host contoller 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 관리 인터페이스)는 'ManagementTealm'라는 시큐리티 범위에 포함되었습니다. 이 시큐리티의 구조를 시키류리 영역이라고 말합니다. 시큐리티 영역은 인증 및 접근 등의 방법을 정의한 것으로, 관리 인터페이스에서는 정의된 시큐리티 영역명을 지정하면 됩니다. 이 때문에 관리 사용자를 추가할 때, 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>
Msecurity-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' 인터페이스는 애플리케이션 사용자가 접근할 수 없는(관리용의 네트워크 세그먼트) 주소에 바인드합니다.
(4) 관리 자원 구조
JBoss EAP 6의 구축 및 설정 시, 특히 관리 CLI를 사용하는 경우엔 관리 자원이 어떤 형태의 트리로 구성되는지 파악해야 합니다. 기본적으로 스탠드얼론 모드에서는 standalone.xml 등의 설정 파일의 schema에 따라 트리가 구성되지만, 도메인 구성에서는 도메인 모델에 맞는 트리가 구성됩니다.
관리 자원들은 JBoss EAP 6 시작 시 설정 파일을 바탕으로 구축되어 관리 인터페이스를 통해 자원에 접근할 수 있습니다. 또, 관리 자원이 변경되었을 경우에는 설정 파일에 변경 사항이 반영되고 관리됩니다.
① 관리 자원 요소
관리 자원은 루트에서 시작되는 계층 트리로 구성되어 트리상의 각 관리 자원은 노드로 표현됩니다. 관리 자원은 노드를 구성하는 중요 요소로 다음 표의 항목들을 갖추고 있어 부모 노드가 되는 관리 자원이 자식 노드를 생성할 수 있는 형태가 정해집니다.
| 구분 | 작업 |
| 노드명 | 관리 자원을 나타내는 이름 |
| 형태(Type) | 관리 자원 자체의 형태 부모 노드의 관리 자원에 대해 자식 노드 형태(Child)로 정의되어 있어야 합니다. |
| 오퍼레이션 (Opertations) |
관리 자원에 대한 조작 관리 자원의 차가 및 삭제, 속성을 읽어 변경하는 등의 조작 |
| 속성 (Attribute) |
관리 자원의 속성(각종 정보)을 나타내는 이름의 변수 속성마다 다음 항목들이 정의되어 있습니다. - 속성명 - 속성값의 형태 - 읽기 전용/읽고 쓰기 가능 - 저장되는 값으로 실행 시만 이용 가능한 값 |
| 자식 노드형 (Child-Type) |
자식 노드를 가질 수 있는 관리 자원의 형태 |
② 관리 리소스 계층 트리
관리 자원은 루트 노드로부터 시작되는 계층 트리로 구성되었습니다. 계층 트리는 관리 모델에 따라 일부 다르지만, 기본적으로는 같은 형태입니다.
스탠드얼론 모드의 경우, 루트 바로 아래에 childrens-types 관리 자원이 구성되었습니다.
| 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 시작 옵션 |
(1) 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 프로파일이라는 것을 알 수 있습니다.
(2) 서브시스템
서브시스템(subsystem)은 서블릿, 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-cahce 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>
extension과 서브시스템의 설정은 다음과 같습니다.
- 주요 extension는 기본적으로 등록
- 서브시스템의 설정 항목은 XML의 schema로 정의
- 서스시스템 설정은 관리도구에서 지정
extension과 서브시스템의 관계를 다음과 같습니다.
| 구분 | 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:domainpojo: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 | |
| 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 | |
| messaging | org.jboss.as.messaging | urn:jboss:domain:messaging:1.3 | |
(3) 도메인 모드의 서브시스템과 extension
도메인 모드에서 하나의 설정 파일 domain.xml에 모든 플파일이 정의되어 있기 때문에 extension은 스탠드얼론 모드에서의 전체 기능 standalone-full-ha.xml과 거의 같은 정의가 되었습니다. 한 가지 차이점은 스탠드얼론 모드에만 deployment-scanner가 있다는 점입니다.
반대로, 서브시스템에 대해서는 스탠드얼론 모드에서의 4개의 설정 파일에 해당하는 정의가 하나의 domain.xml 파일 내에 4개의 프로파일로 설정되었습니다.
(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 디렉터리 삭제 |
(5) 프로파일
프로파일(profile)은 서브시스템들을 묶어놓은 세트이며, extension에 의해 JBoss EAP 6 코어에 추가된 추가 기능 세트입니다. 여러 개의 서브시스템을 포함하고 있는 프로파일은 결과적으로 여러 개의 기능 세트를 제공하는 서버가 됩니다. 몇 개의 서브시스템만으로 정의된 프로파일은 소규모 기능을 가진 서버가 되어 메모리 사용량이 작은 가벼운 서버가 됩니다.
예를들면, 풀 프로파일의 프로파일 정의 파일인 standalone-full.xml은 웹 컨테이너만이 아니라 EJB나 JMS 등의 Java EE의 전체 기능을 제공하기 때문에, 여러 개의 서브시스템 정의를 포함하지만, 웹 프로파일 정의파일인 standalone.xml 파일은 웹 컨테이너를 중심으로 한 기능만 제공하기 때문에 보다 적은 서브시스템 정의만 가지고 있습니다.
스탠드얼론 모드로 정의되는 프로파일(설정 파일명)과 도메인 모드로 정의되는 프로파일 및 각 프로파일에서 사용되는 서브시스템은 다음과 같습니다.
| Standalone 구성파일 | standalone.xml | standalone-ha.xml | standalone-full.xml | standalone-full-ha.xml |
| Domain 프로파일명 | default | ha | full | full-ha |
| jacorb | - | - | O | O |
| messaging | - | - | O | O |
| webservices | - | - | O | O |
| jgroups | - | O | - | O |
| modcluster | - | O | - | O |
| infinispan | O | O | O | O |
| ee | O | O | O | O |
| ejb3 | O | O | O | O |
(6) 패스
파일 시스템 패스(path)의 논리적인 이름으로 설정 파일 내부의 다른 부분에서 참조됩니다.
예를들어 로깅 서브시스템은 'jboss.server.log.dir'의 값을 참조하여 서버 log 디렉터리를 지정하게 됩니다.
<file relative-to="jboss.server.log.dir" path="server.log"/>
주요 패스(path)는 아래와 같습니다.
| 구분 | 패스(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 | 도메인 로그 파일 저장 디렉터리 |
(7) 매니지먼트
보안 영역의 설정과 관리용 인터페이스를 정의하는 속성입니다.
기본값은 ApplicationRealm와 ManagementRealm의 두 개가 파일로 정의되었습니다. 각각의 Realm에서 사용하는 파일들은 application-realm.properties, application-roles.properties과 management-realm.properties로 정의되었습니다.
또, 네이티브 관리 포트와 HTTP의 관리 포트의 인터페이스 정의는 Management-Realm을 사용하도록 보안 설정이 되었습니다.
(8) 인터페이스
소켓이 바인드 가능한 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">
<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>
(9) 소켓 바인딩 그룹
소켓 바인딩 그룹(socket-binding-group)은 포트들의 집합에 이름을 정의하는 속성으로 인터페이스 정의를 참조해 정의합니다. 정의된 소켓 바인딩 그룹 설정도 다른 정의에서 논리적 이름으로 참조됩니다.
또, 각 프로파일마다 필요한 소켓 정의가 그룹으로 정의됩니다.
/socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding-port-off:0}">
<socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}" />
<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-recorvery-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-bindin>
</socket-binding-group>
여러 개의 포트를 개별적으로 변경하는 것도 가능하지만, 소켓 바인딩에서는 포트 오프셋(port-offset)이라고 하는 개념을 가지고 있습니다. 이 기능은 JBoss가 사용하는 여러 포트에 대해서 일률적으로 값을 더해 사용하는 포트 번호를 일괄 변경하는 것으로 IP주소가 1개 밖에 사용할 수 없는 환경에서도 포트가 충돌하지 않고 여러 개의 JBoss EAP 인스턴스를 사용할 수 있습니다.
(10) 시스템 프로퍼티
Java 가상 머신 시작 시에 넘겨주는 시스템 프로퍼티를 설정 파일에서 정의하기 위한 속성입니다. property 속성으로 여러 개의 시스템 프로퍼티를 정의할 수 있습니다.
<system-properties>
<property name="java.net.preferIPv4Stack" value="true"/>
</system-properties>
시스템 프로퍼티를 관리 CLI로 설정할 경우에는 아래와 같이 수행합니다.
[standalone@localhost:9999 / ] ./system-property=org.apache.catalina.JSSESSIONID:add(value="MYID")
{ "outcome" => "success" }
(11) 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>
(12) 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 풀어놓은 디렉터리를 배포했을 경우에 같게 다룹니다.
또, VFS에서는 JDK의 파일 조작 API보다 더 추상화된 사용하기 쉬운 API를 제공하고 있습니다.
예를들어, Windows상에서 파일 락이 걸리면 배포할 수 없게 되어 버리지만, 임시 파일을 작성하여 처리하는 방식을 사용하여 피해갈 수 있습니다. 파일 핸들에 대한 처리가 VFS 내부에 포함되어 있기 때문에 기존의 Windows 상에서 파일 락과 같은 문제를 해결하고 있습니다.
참고서적 : 거침없이 배우는 JBoss
'IT 이야기 > JBoss EAP' 카테고리의 다른 글
| JBoss EAP 6과 친해지기 21탄 - 애플리케이션 배포 (0) | 2021.01.11 |
|---|---|
| JBoss EAP 6과 친해지기 20탄 - JBoss EAP 6 관리 #2 (2) | 2021.01.06 |
| JBoss EAP 6과 친해지기 19탄 - 클러스터링 #2 (0) | 2020.12.24 |
| JBoss EAP 6과 친해지기 19탄 - 클러스터링 #1 (0) | 2020.12.24 |
| JBoss EAP 6과 친해지기 18탄 - 로깅 서브시스템 (2) | 2020.12.22 |
댓글