17장. JBoss EAP 7 관리

Name

Date

Reason For Changes

Version

오픈나루

2013/11

Initial Version

1.0

전준식, jjeon@opennaru.com

2018/02

Second Version

2.0

이번 장에서는 JBoss EAP 6의 운영 관리 방법에 대해 소개하고 사용하는 관리 도구에 대해서 설명한다.

JBoss EAP 6의 큰 매력 중의 하나는 이번 장에 소개하는 관리방법들이다. 특히 CLI는 매우 강력한 도구이며, JBoss EAP 6를 사용할 때 많이 애용하는 도구이다. 이번 장에서는 관리도구의 사용법은 물론, 각종 명령어에 대해서도 설명한다. 또, 웹 기반 관리 콘솔의 사용방법에 대해서도 설명한다.

17-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용 관리 애플리케이션을 사용할 수도 있다.

image

그림1. JBoss EAP 6의 다양한 관리도구

17-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 모델로 정의하여 관리 서버에 요청하게 된다.

image

그림 2. DMR 모델 구조

위의 DMR 모델 구조를 살펴 보면, JBoss에서 운영 모니터링에서 조작할 수 있는 관리 리소스를 주소로 지정하여 해당 주소의 리소스에 대해서 관리 명령을 실행한다. ‘:’ 다음에 오퍼레이션을 지정한다. 어떤 리소스인지 ‘주소’에 따라 사용 가능한 오퍼레이션이 다르다. 또 오퍼레이션 실행 시 넘겨줄 파라미터 값들을 오퍼레이션 다음의 괄호 안에 컴마로 구분한 name=value 형태로 지정하여 해당 리소스에 대해 오퍼레이션을 실행한다.

서버 측에서는 DMR 모델에 있는 오퍼레이션을 처리하는 핸들러를 이용해 처리하게 된다. 오퍼레이션을 처리할 핸들러는 서비스 컨트롤러를 통해 서비스 컨테이너에 있는 서비스에서 밸류 오브젝트(Value Object)를 얻는다. 그 밸류 오브젝트에 포함되는 정보를 참조하거나, 변경해 그 처리 결과를 응답용 DMR 모델로 설정하고 결과를 클라이언트에 반환한다.

도메인 모드 관리

도메인 모드에서 관리 인터페이스를 설명한다.

image

그림 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 관리 자원이 구성되었다.

image

image

그림 4. 관리 리소스의 계층 구조

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

image

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

mail

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

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. 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 파일은 웹 컨테이너를 중심으로 한 기능만 제공하기 때문에 보다 적은 서브시스템 정의만 가지고 있다.

스탠드얼론 모드로 정의되는 프로파일(설정 파일명)과 도메인 모드로 정의되는 프로파일 및 각 프로파일에서 사용되는 서브시스템은 다음과 같다.

image

표 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 풀어놓은 디렉터리를 배포했을 경우가 같게 다룬다.

image

그림 6. VFS의 구조

또, VFS에서는 JDK의 파일 조작 API보다 더 추상화된 사용하기 쉬운 API를 제공하고 있다.

예를 들어, Windows상에서 파일이 락이 걸리면 배포할 수 없게 되어 버리지만, 임시 파일을 작성하여 처리하는 방식을 사용하여 피해갈 수 있다. 파일 핸들에 대한 처리가 VFS내부에 포함되어 있기 때문에 기존의 Windows 상에서 파일 락과 같은 문제를 해결하고 있다.

17-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 관리자 패스워드

서버 접속

CLI를 시작한 후 ‘connect’ 명령어를 실행하면 서버(기본값 localhost:9999)에 접속한다.

$ ./jboss-cli.sh

You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.

[disconnected /] connect

[standalone@localhost:9999 /]

또, jboss-cli.sh 스크립트를 실행할 때 ‘--connect’ 나 ‘-c’ 옵션을 사용하여 CLI를 시작하면 곧바로 관리 서버에 접속하는 것도 가능하다. 특정 컨트롤러에 접속하려면 jboss-cli.sh 시작 시 --connect 옵션의 뒤에 --controller=[host][:port]를 지정한다.

$ ./jboss-cli.sh --connect --controller=localhost:9999

[standalone@localhost:9999 /]

connect 명령의 파라미터로 접속할 서버의 IP주소와 포트 번호를 지정하여 접속할 수 있다.

$ ./jboss-cli.sh

You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.

[disconnected /] connect localhost:9999

[standalone@localhost:9999 /]

CLI 실행 모드

jboss-cli.sh 스크립트의 실행 모드는 일반적인 쉘(Shell)과 같이 프롬프트에 명령을 입력하면 실행 결과를 출력하는 대화형 모드와 jboss-cli.sh의 파라미터로 명령을 직접 지정해 실행하는 비대화형 모드가 있다.

  • 대화형 모드

    $ ./jboss-cli.sh
    
    You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
    
    [disconnected /] connect
    
    [standalone@localhost:9999 /] cd /core-service=management
    
    [standalone@localhost:9999 core-service=management] ls
    
    ldap-connection management-interface security-realm
    
    [standalone@localhost:9999 core-service=management]

비대화형 모드는 접속할 때 사용하는 --connect(-c) 옵션과 실행할 명령을 지정하는 --command, --commands 나 --file 옵션을 사용한다.

다음은 비대화형 모드 실행 예로 cd명령으로 /core-service=management 노드로 이동하여, ls명령으로 하위 자원이나 속성들을 표시하는 예제이다. 그런데 비대화형 모드의 --command는 하나의 명령만 지정할 수 있기 때문에 cd명령어를 사용하지 않고 루트 디렉터리에서 ls 명령을 실행하였다.

  • 비대화형 모드

    • --command 옵션(ls명령만 실행)

      $ ./jboss-cli.sh -c command="ls"
      
      core-service
      deployment
      deployment-overlay
      extension
      interface
      path
      
      … 생략 …
      
      $
  • --commands 옵션

    $ ./jboss-cli.sh -c --commands="cd /core-service=management, ls"
    
    ldap-connection
    management-interface
    security-realm
    
    [jboss@rhel63pc bin]$
  • --file 옵션

    다음과 같이 sample.cli 파일을 작성한다.

    $ vi sample.cli
    
    cd /core-service=management
    
    ls

    작성한 파일을 CLI에서 --file 옵션에 지정하여 실행한다.

    $ ./jboss-cli.sh -c --file=sample.cli
    
    ldap-connection
    
    management-interface
    
    security-realm

CLI 인증

JBoss 매니지먼트에는 보안 Realm으로 ManagementRealm이 적용되어 로컬 호스트 이외의 원격접근에는 관리자 아이디와 패스워드를 입력해야 한다.

  • 로컬 호스트 인증

    로컬 호스트에서 접근은 ManagementRealm 설정에 있는 local 이 설정되어 있어 인증없이 접근할 수 있다. 이 인증 기능을 사일런트 인증이라 하며, 로컬 호스트에서의 접근도 ManagementRealm을 적용하여 인증하도록 설정하는 것도 가능하다. 사일런트 인증을 사용하지 않으려면 아래와 같이 실행하여 local 설정을 제거하면 된다.

    [standalone@localhost:9999 /] /core-service=management/security-realm=ManagementRealm/authentication=local:remove
    
    {
      "outcome" => "success",
      "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
      }
    }
    
    [standalone@localhost:9999 /] :reload
    
    {"outcome" => "success"}

CLI 종료

CLI를 종료하려면 Ctrl+D 나 quit(혹은 q)를 입력한다.

비대화형 모드에서는 지정된 명령을 실행한 후 자동으로 종료한다.

CLI 명령어

CLI의 명령은 크게 관리 자원의 오퍼레이션 실행과 그 외의 일반 명령으로 나눌 수 있다. 관리 자원의 오퍼레이션 실행 명령과 보조 명령어로 cd, ls, pwn(pwd)등 일반 명령어가 있다.

CLI 명령어 사용법

CLI로 입력할 수 있는 명령어는 CLI 공통 명령어와 관리 대상 서버에 따라 사용할 수 있는 명령이 다른 명령어가 있다. 사용할 수 있는 명령의 목록은 관리 대상 서버(스탠드얼론 또는 도메인 컨트롤러)에 접속한 상태에서 help 명령을 실행하면 명령어에 대한 도움말이 출력된다.

$ ./jboss-cli.sh -c

[standalone@localhost:9999 /] help

Usage:

jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]

{empty}[--connect] [--file=file_path]

{empty}[--commands=command_or_operation1,command_or_operation2...]

{empty}[--command=command_or_operation]

{empty}[--user=username --password=password]

{empty}[--timeout=timeout]

--help (-h) - prints (this) basic description of the command line utility.

--version - prints the version info of the JBoss AS release, JVM and system environment.

--controller - the default controller host and port to connect to when --connect option (described below) is specified or when the connect command is issued w/o the arguments. The default controller host is localhost and the port is 9999.

--connect (-c) - instructs the CLI to connect to the controller on start-up (to avoid issuing a

separate connect command later).

--gui - GUI built on top of the CLI, the only difference is that it brings up a GUI instead

of a command line. In this mode, the CLI will automatically connect during start-up.

You can optionally specify --controller, if necessary.

--file - specifies a path to a file which contains commands and operations (one per line) that

should be executed (in a non-interactive mode). The CLI will terminate the session

immediately after the last command has been executed or if some command

or operation failed.

… 생략 …

각각의 명령에 대해 명령어 파라미터에 '--help’를 지정하면 상세 정보가 표시된다.

[standalone@localhost:9999 /] command --help

SYNOPSIS

command [add --node-type=node_path_to_the_type

[--property-id=identifying_property]

--command-name=name_for_the_command |

remove --command_name=command_to_remove |

list]

DESCRIPTION

Allows to add new, remove and list existing generic type commands.

A generic type command is a command that is assigned to a specific node type

and which allows to perform any operation available for an instance of that

type and/or modify any of the properties exposed by the type on any existing

instance of that type.

For example, suppose there is a generic type command assigned to type

… 생략 …

다음은 CLI의 기본 명령어들은 다음과 같은 것이 있다.

명령어 설명

batch

배치 모드 시작

cn (or cd)

노드 경로를 입력하여 위치를 변경(디렉터리 변경과 유사)

connect

서버 인스턴스에 접속

command

일반 명령의 추가, 삭제

deploy

애플리케이션 배포

help (or h)

도움말 표시

history

명령어 히스토리를 표시

ls

현재 노드의 자원 목록을 표시한다.

파라미터 ‘-l’을 사용하면 attribute와 child 자원이 표시된다.

pwn (or pwd)

현재 노드 위치를 표시

quit (or q)

CLI를 종료한다.

read-attribute

노드의 속성 정보를 표시한다.

read-operation

오퍼레이션의 설명 및 목록을 표시한다.

deploy

애플리케이션을 배포한다.

version

버전 정보를 표시한다.

탭 자동완성

CLI 명령어 입력시 Linux의 쉘과 같이 탭 자동완성(Tab-completion)을 사용할 수 있다. 대화형 모드로 명령어나 노드 경로, 오퍼레이션, 명령어나 오퍼레이션의 파라미터 등 모든 입력에 대해서 동작한다. 대상 후보가 하나일 경우엔 자동으로 입력 문자가 채워지고, 대상 후보가 여러 개일 경우엔 리스트로 표시한다.

명령어 히스토리

Linux 쉘과 마찬가지로 CLI 는 실행한 명령어에 대한 히스토리(history) 기능을 제공한다. 대화형 모드에서 위, 아래 화살표 키를 눌러 사용한 명령어 히스토리의 전/후를 확인하고 다시 실행하거나 편집하여 실행할 수 있다. 명령어 히스토리는 메모리와 파일에 보관하여 있어 CLI를 재 시작하더라도 명령어 히스토리를 참조할 수 있다. 히스토리가 저장되는 파일명은 사용자 홈디렉터리에 있는 ‘.jboss-cli-history’파일이다. 히스토리 기능을 변경하려면 history 명령어를 사용한다. 파라미터 없이 실행하면, 메모리상에 보관하고 있는 모든 히스토리(최댓값 500개)이 출력된다.

[standalone@localhost:9999 /] history

connect 192.168.0.11:10099

connect localhost:9999

connect

cd /core-service=management

ls

exit

command --help

history

(The history is currently enabled)

[standalone@localhost:9999 /]

history 명령어는 아래와 같은 3개의 파라미터를 사용할 수 있다.

  • disable : 히스토리를 사용하지 않는다. 기존의 히스토리도 삭제한다.

  • enabled : 히스토리의 기록을 사용한다.

  • clear : 메모리상의 히스토리를 삭제한다. 파일의 히스토리는 삭제하지 않는다.

배치 모드

배치 모드는 명령어나 오퍼레이션들을 차례대로 일괄 실행한다. 배치 순서 내에서 명령어나 오퍼레이션 중의 하나가 실패할 경우 롤백 한다. 기본적인 이용 방법은 아래와 같다.

  1. batch 명령을 입력하면 배치 모드가 시작되고, 프롬프트에 ’#’가 표시된다.

  2. 명령어나 오퍼레이션을 입력해 배치 실행할 순서를 작성한다. 입력순서 따라 배치 순서에 추가되어 #1, #2와 같이 번호가 붙는다.

  3. 모든 명령어 및 오퍼레이션을 입력한 후, run-batch 명령어를 사용해 배치를 실행한다.

데이터소스 삭제와 JDBC 드라이버를 삭제하는 배치 모드 실행 예제는 다음과 같다.

$ ./jboss-cli.sh -c

[standalone@localhost:9999 /] batch

[standalone@localhost:9999 / #] /subsystem=datasources/data-source=ExampleDS/:remove

#1 /subsystem=datasources/data-source=ExampleDS:remove

[standalone@localhost:9999 / #] /subsystem=datasources/jdbc-driver=h2/:remove

#2 /subsystem=datasources/jdbc-driver=h2:remove

[standalone@localhost:9999 / #] run-batch

The batch executed successfully

[standalone@localhost:9999 /]

배치 모드에서 자원을 추가하면, 현재 실행중인 배치 내에서는 추가한 자원에 cd명령으로 이동할 수 없으므로 주의하여 작성하여야 한다.

CLI 오퍼레이션

관리 자원에 대한 오퍼레이션 실행은 주소(node_path), 오퍼레이션 이름(operation_name)과 파라미터 리스트(parameter_list)의 3개 요소로 구성된다. CLI 명령어의 오퍼레이션 형식은 아래와 같다.

[node_path]:opration_name[parameter_list]
항목 설명

주소(node_path)

주소 형식은 아래와 같다.

/node-type=node-name(/node-type=node-name)*
  • node-type:resource node 타입

  • node-name:resource node명

node-type=node-name로 트리 구조의 하나의 노드를 나타낸다. 루트 자원은 ‘/’만으로 표시한다. 또, 트리 구조의 각 노드를 ‘/’로 구분하여, 트리 구조의 각 레벨을 나타낸다.

오퍼레이션 이름

(operation_name)

오퍼레이션 이름의 형식은 아래와 같다. 오퍼레이션 이름 앞에 오퍼레이션을 나타내는 ‘:’을 지정한다. 오퍼레이션 이름은 주소로 지정된 노드 자원이 가지는 오퍼레이션을 지정한다.

:operation_name

오퍼레이션 파라미터 리스트

(parameter_list)

오퍼레이션 이름으로 지정한 오퍼레이션 파라미터를 지정한다.

([parameter-name=parameter-value(parameter-name=parameter-value)*])
  • parameter-name:오퍼레이션 파라미터 이름

  • parameter-value:파라미터 설정 값

주소 이동

CLI에서 관리 자원 노드들은 트리 형식으로 마치 파일 시스템과 같다. 각 노드의 패스는 디렉터리와 같다. 노드에 접근하려면, cd명령으로 현재 노드를 변경하는 것으로 상대 경로나 절대 경로를 사용하여 이동할 수 있다.

상대 경로로 접근할 때는, 파일 시스템과 같이 ‘. ‘는 현재 노드를, ‘..’은 부모 노드를 나타낸다.

또, pwn(pwd) 명령은 현재 노드의 경로 주소를 표시하고, ls명령으로 노드의 속성(attirbute)과 자식 자원(children-types)의 형태를 표시한다.

  • pwd명령어 실행 예

    [standalone@localhost:9999 subsystem=web] pwd
    
    /subsystem=web
    
    [standalone@localhost:9999 subsystem=web]
  • ls명령어 실행 예

    [standalone@localhost:9999 subsystem=web] ls
    
    configuration default-virtual-server=default-host
    
    connector instance-id=undefined
    
    valve native=false
    
    virtual-server
    
    [standalone@localhost:9999 subsystem=web]
  • ls -l 명령어 실행

    ls 명령에 파라미터 ‘-l’를 붙여서 노드의 속성(attirbute)과 자식 자원(children-types)의 형태를 상세하 표시할 수 있다.

    [standalone@localhost:9999 subsystem=web] ls -l
    
    ATTRIBUTE VALUE TYPE
    
    default-virtual-server default-host STRING
    
    instance-id undefined STRING
    
    native false BOOLEAN
    
    CHILD MIN-OCCURS MAX-OCCURS
    
    configuration n/a n/a
    
    connector n/a n/a
    
    valve n/a n/a
    
    virtual-server n/a n/a
    
    [standalone@localhost:9999 subsystem=web]

오퍼레이션

오퍼레이션의 타입은 모든 노드에 대해서 실행 가능한 공통 오퍼레이션과 특정 노드에 대해서만 실행 가능한 고유 오퍼레이션으로 나뉜다.

오퍼레이션 설명 파라미터

add

새로운 자원을 추가한다.

사용법은 다음과 같이 자원의 유형과 이름을 입력하고 :add 오퍼레이션을 지정한다.

./<resource type>=<신규 자원명>:add

추가하는 자원에 따라 파라미터가 달라진다.

read-attribute

속성값을 표시한다.

  • name: 속성명(필수)

  • include-defaults: 기본값 false.
    true로 설정하면 속성의 기본값을 표시한다.

read-children-names

지정된 타입의 자식 자원명을 표시한다.

  • child-type: 자식 자원의 resource type를 지정(필수)

read-children-resources

지정된 타입의 모든 자식 자원 정보를 표시
표시 내용은 자식 자원은 각각에서 read-resource 오퍼레이터를 실행한 것과 같다.

  • child-type: 자식 자원의 resource type를 지정(필수)

  • recursive: 기본값 false,
    재귀적으로 자식 자원에 관한 상세 정보를 표시할지 설정

  • recursive depth: recursive가 true일 경우, 재귀적으로 표시하는 깊이를 지정

  • proxies: 기본값 false,
    재귀적인 호출 시 원격 자원을 포함할지 지정

  • include-runtime: 기본값 false,
    런타임 속성을 포함할 것인지 지정.
    부하가 발생할 가능성이 있기 때문에, recursive가 true일 경우는 무시됨

  • include-defaults: 기본값 false,
    속성의 기본값을 표시할지 지정

read-children-types

자식 자원의 종류를 목록으로 표시

read-operation-description

오퍼레이션이나 지정 가능한 파라미터에 대한 설명을 표시

  • name: 오퍼레이션 이름(필수)

  • locale: 파라미터 설명의 로케일을 지정. null이면 기본 로케일

read-operation-names

자원이 지원하는 오퍼레이션 이름들을 출력

read-resource

자원이 지원하는 속성이나 자식 자원의 목록을 표시

  • recursive: 기본값 false,
    재귀적으로 자식 자원에 관한 상세한 정보를 표시할 지 설정

  • recursive depth : recursive가 true일 경우, 재귀적으로 표시하는 깊이를 지정

  • proxies: 기본값 false,
    재귀적인 호출 시에 원격 자원을 포함할 것인지 지정

  • include-runtime: 기본값 false,
    런타임 속성을 포함할 것인지 지정. 부하가 발생할 가능성이 있기 때문에, recursive가 true일 경우는 무시됨

  • include-defaults: 기본값 false,
    속성의 기본값을 표시할지 지정

read-resource-description

자원이 지원하는 속성이나 자식 자원, 오퍼레이션의 상세 설명을 표시한다

  • operations:기본값 false,
    오퍼레이션의 설명을 포함할지 지정

  • inherited: 기본값 true,
    부모 자원으로부터 상속한 오퍼레이션의 설명을 포함할 것인지 지정

  • recursive: 기본값 false,
    재귀적으로 자식 자원에 관한 상세한 정보를 표시할지 설정

  • recursive depth: recursive가 true일 경우, 재귀적으로 표시하는 깊이를 지정

  • proxies: 기본값 false,
    재귀적인 호출 시에 원격 자원을 포함할지 지정

  • locale: 오퍼레이션 상세 설명의 로케일을 지정. null이면 기본 로케일을 사용함

remove

자원을 삭제

write-attribute

속성 값을 기록한다

대상 노드에서 사용할 수 있는 고유 오퍼레이션은 ‘:read-operation-names’ 오퍼레이션을 실행하여 확인할 수 있다. 다음은 datasource 자원의 오퍼레이션 목록을 확인하는 예제이다.

[standalone@localhost:9999 /] /subsystem=datasources:read-operation-names
{
  "outcome" => "success",
  "result" => [
    "add",
    "get-installed-driver",
    "installed-drivers-list",
    "read-attribute",
    "read-children-names",
    "read-children-resources",
    "read-children-types",
    "read-operation-description",
    "read-operation-names",
    "read-resource",
    "read-resource-description",
    "remove",
    "undefine-attribute",
    "whoami",
    "write-attribute"
  ]
}

[standalone@localhost:9999 /]

datasource 자원에서 ‘get-installed-driver’, ‘installed-drivers-list’라는 2개의 추가 오퍼레이션을 제공하고 있는 것을 확인할 수 있다.

추가된 오퍼레이션에 대한 보다 자세한 정보는 ‘read-operation-description’ 명령으로 확인할 수 있다.

[standalone@localhost:9999 core-service=management] /subsystem=datasources:read-operation-description(name=get-installed-driver)
{
  "outcome" => "success",
  "result" => {
    "operation-name" => "get-installed-driver",
    "description" => "Get a description of an installed driver",
    "request-properties" => {"driver-name" => {
      "type" => STRING,
      "description" => "Driver name",
      "expressions-allowed" => false,
      "required" => true,
      "nillable" => false,
      "min-length" => 1L,
      "max-length" => 2147483647L
    }},
    "reply-properties" => { [standalone@localhost:9999 /]
    "type" => OBJECT,
    "value-type" => {
    "driver-minor-version" => {
      "type" => INT,
      "description" => "Minor driver version",
      "expressions-allowed" => true,
      "required" => false,
      "nillable" => true
    },

… 생략 …

자원 추가

CLI로 add 오퍼레이션을 사용하여 자원을 추가하는 순서를 설명한다.

/subsystem=datasources 하위에 있는 리소스 타입이 data-source인 자원을 추가하는 예제를 설명한다.

  • 필수 파라미터 확인

    자원을 추가할 때를 먼저 필수 파라미터가 있는지 확인해야 한다. 필수 파라미터는 자원의 종류에 따라 달라서 CLI를 사용하여 확인하는 것이 좋다.

    read-operation-description 오퍼레이션을 사용해 확인할 수 있다.

    우선 이미 존재하는 자원의 노드에서 read-operation-description(name=add)를 실행하면, 자원을 추가하는 경우 필요한 파라미터 목록과 그 설명이 표시된다. 그 속성 중에서 required라는 항목이 있으면, 필수 파라미터로 지정하여야 한다.

    [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-operation-description(name=add)
    
    {
      "outcome" => "success",
      "result" => {
        "operation-name" => "add",
        "description" => "Add a new data-source",
        "request-properties" => {
          "share-prepared-statements" => {
            "type" => BOOLEAN,
    
            … 생략 …
    
            "jndi-name" => {
            "type" => STRING,
            "description" => "Specifies the JNDI name for the datasource",
            "expressions-allowed" => true,
            *"required" => true,*
            "nillable" => false
            },
    
            … 생략 …
    
            "driver-name" => {
            "type" => STRING,
            "description" => "Defines the JDBC driver the datasource should use. It is a symbolic name matching the the name of installed driver. In case the driver is deployed as jar, the name is the name of deployment unit",
            "expressions-allowed" => true,
            *"required" => true,*
            "nillable" => false,
            "min-length" => 1L,
            "max-length" => 2147483647L
            },
    
            … 생략 …
    
            "connection-url" => \{
            "type" => STRING,
            "description" => "The JDBC driver connection URL",
            "expressions-allowed" => true,
            *"required" => true,*
            "nillable" => false,
            "min-length" => 1L,
            "max-length" => 2147483647L
            },

    필수 파라미터 확인 방법으로 /subsystem=datasources 하위 노드에 data-source의 자원을 추가하려면, 필수 파라미터로 connection-url, jndi-name, driver-name를 지정하여야 한다는 것을 알 수 있다.

  • 자원 추가

    위에서 확인한 필수 파라미터들을 설정하여 자원을 추가하려면 아래와 같이 resource type과 이름을 지정한 후, add 오퍼레이션을 실행한다.

    [standalone@localhost:9999 /] /subsystem=datasources/data-source=NewDS:add(connection-url="jdbc:h2:mem:test;DB_CLOSE_DELAY=-1", jndi-name=java:jboss/datasources/NewDS, driver-name=h2)
    
    {"outcome" => "success"}
  • 리로드

    CLI로 add나 remove, write-attibuten등 수정하는 오퍼레이션을 실행하면, process-state 속성에 ‘reload-required’가 반환되는 경우가 있다. 이 경우 설정 내용이 반영되기 위해서는 루트에서 reload 오퍼레이션을 실행해야 한다.

    {
      "outcome" => "success",
      "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
      }
    }

리로드의 실행 방법은 다음과 같다.

[standalone@localhost:9999 /] /:reload

{"outcome" => "success"}

리로드를 실행하면, 서비스가 재 시작되기 때문에 운영환경에서는 서비스의 영향을 고려하여 명령을 실행하여야 한다.

CLI 일반 명령어

일반 명령어는 특정 resource type에 대한 오퍼레이션을 간략하게 실행하기 위한 간단 명령어이다. 일반 명령어를 사용하면 자원 경로에 신경 쓰지 않고 특정의 resource type로 실행 가능한 공통 오퍼레이션의 일부(add, remove, read-resource, write-attribute)나 자원 고유의 오퍼레이션을 실행할 수 있다.

일반 명령어는 다음과 같은 것들이 있다.

명령어 해당 리소스 타입 설명

data-source

/subsystem=datasources/data-source

  • {Non-XA데이터소스 생성

  • 데이터베이스 접속 테스트

  • 데이터소스 삭제 가능.

xa-data-source

/subsystem=datasources/xa-data-source

  • XA데이터소스의 생성

  • XA데이터베이스 접속 테스트

  • XA데이터소스의 삭제 등이 가능.

jms-queue

/subsystem=messaging/hornetq-server=default/

  • JMS 큐 생성

  • JMS 큐 삭제 등이 가능

jms-topic

jms-queue

  • JMS토픽 생성

  • JMS 토픽 삭제등이 가능

connection-factory

/subsystem=messaging/hornetq-server=default/

  • JMS Connection 팩토리 생성

  • JMS Connection 팩토리 삭제 등이 가능

일반 명령어를 실행하려면 다음과 같은 항목들을 지정한다.

  • <generic_command> : 일반 명령어 이름 지정

  • <sub_command> : write-attribute 이외의 오퍼레이션 이름을 지정

  • <property-id> : 대상의 자원을 식별하기 위한 ID를 지정

  • <property> : 대상이 되는 자원이 가지는 속성(attribute) 명을 지정

  • <parameter> : 오퍼레이션의 파라미터 명을 지정

일반 명령어는 오퍼레이션의 write-attribute를 실행하는 경우와 파라미터 이름이 약간 다를 수 있다. 도메인 모드에서는 ‘--profile’으로 프로파일을 지정하여야 한다.

  • 오퍼레이션 write-attribute를 실행하는 경우

    <generic_command> (--profile=<프로파일명>) domain <property-id>=<인스턴스명> (--<property>=<설정값>)

여러 개 항목을 지정하는 경우는 공백으로 구분하여 항목을 지정한다.

  • 그 외의 오퍼레이션을 실행하는 경우

    <generic_command> <sub_command> (--profile=<프로파일명>) domain <property-id>=<인스턴스명> (--<parameter>=<설정값>)^*^

일반 명령어의 사용 방법은 아래와 같이 --help 도움말 옵션을 사용하여 확인할 수 있다.

  • <generic_command>의 설명을 표시

    <generic_command> --help
  • <sub_command>의 목록을 출력

    <generic_command> --help --commands
  • <sub_command>의 상세 설명을 표시

    <generic_command> <sub_command> --help

    <sub_command> 지정한 오퍼레이션의 상세 설명을 표시한다.

    지정한 오퍼레이션의 설명이나 <parameter>로 지정 가능한 항목을 필수 파라미터(REQUIRED), 추가로 지정할 수 있는 파라미터(OPTIONAL)로 표시한다.

  • <property>의 목록과 설명을 표시

    <generic_command> --help --properties

    <property>로 지정 가능한 속성(attribute) 의 목록과 그 설명을 표시한다.

    실제로 일반 명령어 data-source를 사용하여 자원 추가, 설정 변경, 설정 확인, 자원을 삭제하는 예제를 살펴보자.

  • 자원 추가

    [standalone@localhost:9999 /] data-source add --name=testDS --connection-url="jdbc:h2:mem:test;DB_CLOSE_DELAY=-1" --jndi-name=java:jboss/datasources/testDS --driver-name=h2

    resource type/subsystem=datasources/data-source의 자원을 추가한다. <property-id> name의 경우는 인스턴스 이름으로 자원의 이름을 지정한다. 또, 자원추가 시 필수 파라미터인 connection-url, jndi-name, driver-name를<parameter>로 지정한다.

    위의 예제를 오퍼레이션으로 실행하면 아래와 같다.

  • 설정 변경

[standalone@localhost:9999 /] data-source --name=testDS --user-name=sa --password=sa

[standalone@localhost:9999 /]

+ <property-id>의 name으로 지정한 자원 <property>인 user-name과 password의 설정을 변경한다. 위 예제를 오퍼레이션으로 실행하면 아래와 같다.

+

[standalone@localhost:9999 /] cd /subsystem=datasources/data-source=testDS

[standalone@localhost:9999 data-source=testDS] :write-attribute(name=user-name, value=sa)

{"outcome" => "success"}

[standalone@localhost:9999 data-source=testDS] :write-attribute(name=password,value=sa)

{"outcome" => "success"}
  • 설정 확인

[standalone@localhost:9999 data-source=testDS] data-source read-resource --name=testDS

allocation-retry=n/a

allocation-retry-wait-millis=n/a

allow-multiple-users=false

background-validation=n/a

background-validation-millis=n/a

blocking-timeout-wait-millis=n/a

check-valid-connection-sql=n/a

connection-properties=n/a

connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1

datasource-class=n/a

password=sa

user-name=sa

… 생략 …
  • 자원 삭제

    [standalone@localhost:9999 /] data-source remove --name=testDS

도메인 모드에서 CLI 사용법

도메인 환경에서 사용되는 몇 가지 CLI 오퍼레이션에 대해 설명한다.

도메인 환경에서 어떤 자원에 대한 오퍼레이션 실행 방법이 다른 경우가 있으니 주의해야 한다.

  • 서버 재시작

도메인 모드에서는 CLI를 사용하여 서버 인스턴스를 재 시작할 수 있다. CLI로 루트 자원에 이동 후 모든 서버를 재 시작한다.

[domain@localhost:9999 /] :restart-servers

{
  "outcome" => "success",
  "result" => undefined,
  "server-groups" => undefined
}

[domain@localhost:9999 /]
  • 호스트 오퍼레이션

    CLI로 host으로 이동하면 해당 호스트에 적용되는 오퍼레이션을 실행할 수 있다. 호스트를 shutdown하는 방법은 아래와 같다.

    [domain@localhost:9999 /] cd host=master
    
    [domain@localhost:9999 host=master] :shutdown
    
    {"outcome" => "success"}
    
    [domain@localhost:9999 host=master]
    
    The connection to the controller has been closed as the result of the shutdown operation.
    
    (Although the command prompt will wrongly indicate connection until the next line is entered)
  • 서버 그룹의 오퍼레이션 CLI로 server-group에 이동한 후, 오퍼레이션을 실행하여 해당 서버 그룹의 서버를 시작하거나 정지할 수 있다.

    [domain@localhost:9999 /] cd /server-group=main-server-group
    
    [domain@localhost:9999 server-group=main-server-group] :start-servers
    
    {
      "outcome" => "success",
      "result" => undefined,
      "server-groups" => undefined
    }

배치 모드 사용법

배치모드 명령어

배치 모드를 시작하도록 batch 명령을 실행

[standalone@localhost:9999 data-source=PostgreDS] batch

[standalone@localhost:9999 data-source=PostgreDS #]

데이터소스를 enable에 배치 등록

[standalone@localhost:9999 data-source=PostgreDS #] /subsystem=datasources/data-source="java\:\jboss\/datasource\/PostgreDS":enable

#1 /subsystem=datasources/data-source=java:jboss/datasource/PostgreDS:\jboss\/ datasource\/PostgreDS": enable

배치 실행

[standalone @ localhost : 9999 data-source = PostgreDS #] run-batch

배치 목록을 표시한다.

[standalone@localhost:9999 data-source=PostgreDS #] list-batch

# 1 /subsystem=datasources/data-source=java:jboss/datasource/PostgreDS:jboss\/datasource\/PostgreDS": enable

배치 행을 삭제한다

[standalone@localhost:9999 data-source=PostgreDS #] remove-batch-line 1

[standalone@localhost:9999 data-source=PostgreDS #] remove-batch-line 2

일괄 처리를 실행한다.

[standalone@localhost:9999 data-source=PostgreDS #] run-batch

The batch executed successfully.

등록 된 일괄 처리를 취소한다

[standalone@localhost:9999 data-source=PostgreDS #] clear-batch

[standalone@localhost:9999 data-source=PostgreDS #]

배치 파일 모드

test.cli라는 명령 파일을 준비한다. 대화식 모드에서 사용하는 기본 명령을 사용한다.

connect

ls

[EOF]

다음과 같이 test.cli 파일을 파라미터로 명령을 실행한다.

$ jboss-cli.sh --file=test.cli

core-service

deployment

deployment-overlay

extension

interface

path

socket-binding-group

subsystem

system-property

… 생략…

매개 변수로 명령을 실행하는 방법

다음과 같이 --commands 파라미터에 명령을 컴마로 구분하여 작성하면 순서대로 실행된다.

$ jboss-cli.sh -c --commands="cd subsystem=web, ls"

configuration

connector

virtual-server

default-virtual-server = default-host

instance-id = undefined

native = false

자주 쓰는 기능들

다음의 몇가지 CLI 명령들은 서버 운영시 자주 사용되는 명령어들이다. 아래 CLI 명령을 쉘 스크립트로 작성해 놓으면 편리하게 사용할 수 있다.

  • 서버 중지

    $JBOSS_HOME/bin/jboss-cli.sh -c --command=":shutdown"
  • 배포

    $JBOSS_HOME/bin/jboss-cli.sh -c --command="deploy postgresql-8.4-703.jdbc4.jar"
  • Undeploy

    $JBOSS_HOME/bin/jboss-cli.sh -c --command="undeploy postgresql-8.4-703.jdbc4.jar"
  • 커넥션 풀의 상태 얻기

    $JBOSS_HOME/bin/jboss-cli.sh -c --command="connect /subsystem=datasources/data-source=PostgreDS/statistics=pool:read-resource(include-runtime=true)"

CLI GUI 모드

CLI를 GUI화면에서 사용할 수 있다. --gui 파라미터를 사용하여 실행하면 다음과 같은 화면이 표시된다.

$JBOSS_HOME/bin/jboss-cli.sh --gui

image

그림 7. JBoss CLI GUI 모드 화면

속성들이 트리 형태로 표시되어 마치 파일 시스템을 탐색하는 것처럼 마우스를 클릭하여 원하는 노드로 찾아갈 수 있다. 또, 원하는 노드를 선택 후 마우스 오른쪽 버튼을 클릭하면 해당 노드에서 사용할 수 있는 오퍼레이션들이 메뉴로 출력된다. 오퍼레이션을 선택하면 ‘cmd>’에 명령이 자동으로 입력된다. 즉, GUI에서 CLI 명령을 손쉽게 만들 수 있다. CLI에 익숙하지 않은 초심자에게는 CLI 명령을 익히는 데 도움이 될 것이다.

17-5.관리 콘솔

오퍼레이션 개요

관리 콘솔을 이용하려면, JBoss EAP 6가 시작되어 있어야 한다. 웹 브라우저로 아래와 같은 URL에 접근하면 관리 콘솔의 인증 화면이 표시된다. JBoss EAP 6 관리자 아이디와 패스워드를 입력하여 로그인한다.

http://<대상 서버의 IP주소>:9990/console/

image

그림 8. 관리 콘솔 인증 화면

image

그림 9. 관리 콘솔 화면 구성

  • Header

    헤더의 우측으로 ‘Profile’과 ‘Runtime’의 탭이 있다. 인스턴스의 프로파일 관리와 런타임 정보 모니터링을 선택할 수 있다. 도메인 모드에서는 ‘Server’ 탭이 추가된다.

  • Body

    메인 화면부는 좌측의 네비게이션 패널과 우측의 메인 패널로 구성된다.

    네비게이션 패널(좌측의 프레임)에는 JBoss EAP 6 인스턴스에 배포되고 있는 각종의 자원을 트리로 표시한다.

    메인 패널(우측의 프레임)에는 좌측의 네비게이션으로 선택된 자원에 관한 정보를 표시한다. 또 자원에 대한 설정의 추가, 변경, 삭제 등 자원의 관리 작업을 수행한다.

  • Footer

    Footer부의 우측으로 ‘Settings’와 ‘Logout’ 버튼이 있다. ‘Settings’ 버튼을 누르면 사용할 수 있는 언어의 로케일 리스트가 표시되어 관리 콘솔로 사용하는 언어의 선택을 할 수 있다. ‘Logout’ 버튼을 누르면 로그아웃하여 인증 화면으로 돌아간다.

서브시스템 관리

프로파일 탭을 선택하면, 서브시스템들에 대한 설정을 확인하고 수정할 수 있다. 도메인 모드의 경우에는 4가지 프로파일을 모두 사용할 수 있기 때문에 프로파일을 선택할 수 있는 콤보 박스가 표시된다. 도메인 모드에서 설정을 수정하려면 먼저 프로파일 선택한 후 설정해야 한다.

image

그림 10. 도메인 모드의 프로파일과 서브시스템 관리

런타임 정보

런타임 관리에서는 가동 중인 애플리케이션 서버의 상태 정보를 확인할 수 있다. 각 트리를 펼치면 자식 자원이 표시된다.

Server

  • Manage Deployments

    배포 화면에서는 deploy, undeploy, 시작, 정지, 재배포 등 애플리케이션 배포를 제어할 수 있다.

    image

그림 11. 애플리케이션 배포 관리

Status

상태에서는 JVM, Datasources, JPA, JMS Destinations, Transactions, Web및 Webservices등의 자원 정보를 확인할 수 있다.

JVM

서버 JVM의 상세 정보를 표시한다. 이 화면에서는 아래와 같은 정보를 확인할 수 있다.

  • Java VM 종류, OS의 버전 정보, CPU의 프로세스 수

  • Heap 메모리 사용 상황

  • Non-heap의 메모리 사용 상황

  • Thread 사용현황

image

그림 12. JVM 메모리 상태 정보

Subsystems

Datasources

서버의 데이터소스의 상세 정보를 표시한다. 이 화면에서 주로 아래와 같은 정보를 확인할 수 있다.

  • Datasource의 이름, JNDI명, 사용, 사용안함

  • 풀의 사용 현황

  • Prepared Statement 캐시

image

그림 13. 데이터소스 상태 정보

도메인 모드의 서버 토폴로지

도메인 모드의 관리 콘솔로 접속하면 서버의 토폴로지가 테이블 형태로 표시된다. 다른 메뉴를 사용 중이면, Runtime Domain Overview 를 선택하면 아래 화면이 출력된다. 서버 그룹과 호스트 별로 설정된 서버 인스턴스들이 표시되고, 서버 그룹과 서버 인스턴스별 시작, 정지, 재시작 등의 제어가 가능하다.

image

그림 14. 도메인 모드 토폴로지 화면

17-6.Role Based Access Control

JBoss EAP 6.2 버전부터 웹 콘솔과 CLI에 대해서 역할 기반 접근 권한 제어기능(RBAC; Role Based Access Control)을 제공한다.

예를 들어, 관리 콘솔에 애플리케이션 배포 권한만 가진 사용자가 로그인하면 애플리케이션 배포 기능 이외에는 설정을 변경하지 못한다.

기본적으로는 RBAC가 적용되어 있지 않고, CLI에서 다음 명령으로 기능을 사용하도록 설정하여야 한다.

그런데 이 명령을 실행하면 add-user.sh 실행시 Role을 할당하지 않았기 때문에 기존의 사용자도 콘솔에 로그인하지 못한다.

먼저 콘솔에서 ‘Administration’ ‘Role Assignment’ ‘Users’ ‘Add’를 클릭하여 다음과 같이 관리자에게 ‘SuperUser’ Role을 부여한다.

image

그림 15. 사용자에 Role 부여

RBAC로 변경하는 방법은 다음과 같다.

[standalone@localhost:9999/] /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)

{
  "outcome" => "success",
  "response-headers" => {
    "operation-requires-reload" => true,
    "process-state" => "reload-required"
  }
}

[standalone@localhost:9999/] /:reload

{
  "outcome" => "success",
  "result" => undefined
}

다시 RBAC를 사용하지 않으려면 원래대로 simple로 변경하면 된다.

[standalone@localhost:9999/] /core-service=management/access=authorization:write-attribute(name=provider, value=simple)

사용할 수 있는 Role은 Administrator, Auditor, Deployer, Maintainer, Monitor, Operator, SuperUser가 있고 사용자에게 Role을 직접 할당할 수도 있고, 여러 가지 Role을 할당한 그룹을 사용하여 사용자에게 Role을 할당할 수도 있다.

예를 들어 Deployer Role만 사용할 수 있는 deployer라는 사용자가 콘솔에 로그인하면 다음과 같이 다른 항목은 보기만 가능하고 수정할 수 없다. ‘Runtime’ ‘Manage Deployments’ 메뉴만 사용할 수 있다.

image

그림 16. Deployer 권한은 배포 작업만 가능하다