#IBM HTTPServer

[IHS/Liberty] WAS에서 실제 Client IP가 보이지 않을 때 해결 방법 (X-Forwarded-For 설정)

[IHS/Liberty] WAS에서 실제 Client IP가 보이지 않을 때 해결 방법 (X-Forwarded-For 설정)

WebSphere Liberty와 IBM HTTP Server(IHS)를 연동하여 운영하다 보면, WAS 접근 로그나 애플리케이션 내부에서 실제 클라이언트 IP(Client IP) 대신 웹 서버(IHS)의 IP가 찍히는 현상을 자주 마주하게 됩니다.

보통 mod_remoteip를 먼저 떠올리지만, 네트워크 구성(DSR, L4 설정 등)에 따라 해당 모듈만으로는 해결되지 않는 경우가 있습니다.

오늘은 IHS에서 물리적인 연결 IP(REMOTE_ADDR)를 강제로 헤더에 할당하고, Liberty에서 이를 신뢰하도록 설정하여 실제 사용자 IP를 완벽하게 가져오는 방법을 공유합니다.


1. 원인 분석

기본적으로 WAS는 자신과 TCP 연결을 맺은 대상의 IP를 Client IP로 인식합니다.

  • Flow: Client → IHS → WAS
  • Problem: WAS 입장에서 직접 연결된 대상은 IHS이므로, 별도 설정이 없으면 IHS IP를 클라이언트로 판단합니다.

이를 해결하려면 HTTP 헤더(X-Forwarded-For)를 통해 IP를 전달해야 하며, 아래 두 가지 조건이 충족되어야 합니다.

  1. IHS (Sender): 접속한 클라이언트의 실제 IP를 헤더에 확실히 심어서 보낼 것.
  2. Liberty (Receiver): "IHS가 보낸 헤더는 믿을 수 있다"고 신뢰 설정을 할 것.

2. IHS (Web Server) 설정

mod_remoteip가 복잡하게 얽혀 작동하지 않거나 L4에서 헤더를 넘겨주지 않는 상황이라면, mod_rewritemod_headers를 조합해 "지금 붙은 IP"를 강제로 헤더에 주입하는 것이 가장 확실합니다.

httpd.conf (VirtualHost 설정)

<VirtualHost *:80>
    ServerName your.service.com

    # 1. Rewrite 엔진 활성화
    RewriteEngine on

    # 2. 현재 접속한 실제 IP(REMOTE_ADDR)를 환경변수 'CLIENT_IP'에 저장
    RewriteRule ^(.*) - [E=CLIENT_IP:%{REMOTE_ADDR},L]

    # 3. 환경변수에 담긴 IP를 X-Forwarded-For 헤더에 덮어쓰기 (Set)
    # 기존 값을 무시하고, IHS가 식별한 IP로 강제 설정하여 신뢰성 확보
    RequestHeader set X-Forwarded-For %{CLIENT_IP}e
    
    # (선택) HTTPS 통신임을 WAS에 알리기 위한 헤더
    # RequestHeader set X-Forwarded-Proto "https"
</VirtualHost>
Point: RequestHeader set을 사용하여 헤더를 재작성(Overwrite)함으로써, 중간 단계에서 변조되거나 누락된 IP 정보를 IHS가 인식한 정확한 물리적 IP로 보정해서 WAS로 보냅니다.

3. WebSphere Liberty (WAS) 설정

Liberty는 보안상의 이유로 신뢰하지 않는 프록시가 보낸 헤더는 무시하는 것이 기본 정책입니다. IHS가 헤더를 잘 보내줘도, Liberty 설정(server.xml)에서 IHS를 "신뢰하는 통로"로 등록하지 않으면 적용되지 않습니다.

server.xml 설정

<httpDispatcher> 태그를 사용하여 IHS 서버의 IP를 신뢰 목록에 추가합니다.

<server description="My Liberty Server">

    <!-- ... 기존 설정들 ... -->

    <!-- 
      trustedHeaderOrigin: X-Forwarded-For 등 일반 헤더를 신뢰할 IP 목록
      trustedSensitiveHeaderOrigin: SSL 관련 등 민감한 헤더를 신뢰할 IP 목록
      값: IHS(Web Server)의 IP 주소를 쉼표(,)로 구분하여 입력
    -->
    <httpDispatcher trustedHeaderOrigin="192.168.0.10, 192.168.0.11" 
                    trustedSensitiveHeaderOrigin="192.168.0.10, 192.168.0.11" />

</server>
주의: 테스트 시 * (전체 허용)를 사용할 수도 있으나, 운영 환경(Production)에서는 보안을 위해 반드시 연동된 웹 서버의 IP만 명시하는 것을 권장합니다.

4. 결과 확인 및 요약

설정 적용(IHS 재기동, Liberty 동적 반영) 후, WAS의 접근 로그나 애플리케이션 로직을 확인하면 결과가 달라집니다.

  1. IHS: 접속자의 REMOTE_ADDRX-Forwarded-For 헤더에 Set 해서 전송.
  2. Liberty: 지정된 IP(IHS)에서 온 요청임을 확인하고 헤더를 신뢰.
  3. Result: request.getRemoteAddr() 대신 헤더 값을 참조하여 실제 Client IP 획득 성공.

네트워크 구성이 복잡하거나 L4 설정 권한이 없을 때, IHS단에서의 명시적 헤더 RewriteLiberty의 신뢰 IP 등록 조합은 가장 강력하고 확실한 해결책이 됩니다.

Open Stream →
#Liberty

[Liberty] 특정 로그(CWWKS4001I) 숨김 설정이 적용되지 않을 때 해결 방법

WebSphere Liberty (Open Liberty) 운영 중 불필요하게 반복되거나, 보안 정책상 숨겨야 하는 로그 메시지가 발생할 때가 있습니다. 예를 들어, CWWKS4001I 같은 보안 감사 로그가 대표적입니다.

일반적으로 bootstrap.properties에 설정을 추가하지만, 상황에 따라 적용되지 않는 경우가 있어 이를 확실하게 적용하는 두 가지 방법(server.xml 활용 등)을 정리합니다.


1. 문제 상황

bootstrap.properties 파일에 아래와 같이 설정했음에도 불구하고, messages.logconsole.log에 여전히 해당 메시지가 출력되는 현상이 발생했습니다.

# bootstrap.properties 설정 예시
com.ibm.ws.logging.hideMessage=CWWKS4001I

원인: 서버 초기화 시점과 로깅 시스템 로드 시점의 차이, 혹은 server.xml 설정의 우선순위 문제일 수 있습니다.


2. 해결 방법 A: server.xml에서 제어 (권장)

가장 확실한 방법은 server.xml<logging> 태그를 사용하는 것입니다. 이 방식은 명시적이며 설정 반영 확률이 가장 높습니다.

  • 파일 경로: ${server.config.dir}/server.xml
<server description="My Server">

<!-- 기존 logging 태그가 있다면 속성을 추가, 없다면 신규 작성 -->
<!-- hideMessage: 숨길 메시지 ID를 콤마(,)로 구분하여 작성 -->
<logging hideMessage="CWWKS4001I"/>

<!-- 기타 설정들... -->

</server>

3. 해결 방법 B: bootstrap.properties 재점검

부트스트랩 파일을 계속 사용해야 한다면, 다음 사항을 체크해야 합니다. 부트스트랩 변경은 반드시 서버 재기동(Stop & Start)이 필요합니다.

  • 설정 값 뒤에 공백(Space)이 포함되어 있지 않은지 확인
  • 오타 확인 (com.ibm.ws.logging.hideMessage)
# 공백 없이 정확하게 입력
com.ibm.ws.logging.hideMessage=CWWKS4001I

4. 검증 및 결과

설정 적용 후 기존 로그를 정리하고 서버를 재기동하여 적용 여부를 확인합니다.

# 1. 로그 파일 삭제
rm messages.log console.log

# 2. 서버 재기동
server stop [서버명]
server start [서버명]

# 3. 로그 확인 (결과가 없어야 성공)
grep "CWWKS4001I" messages.log

💡 Tip: server.xml 방식이 관리 포인트 일원화 측면에서 더 유리하므로, 특별한 이유가 없다면 Method A를 추천합니다.

Open Stream →
#Liberty

[WebSphere Liberty] DB 연결 총정리: Oracle, DB2, MySQL, Tibero 데이터소스 설정 및 연결 테스트

IBM WebSphere Liberty에서 주요 데이터베이스(Oracle, DB2, MySQL, Tibero)와 연결하기 위한 JDBC 데이터소스 설정 방법을 정리합니다. adminCenter를 활용한 관리 환경 구성, 비밀번호 암호화, 그리고 restConnector를 이용한 연결 테스트까지의 전체 과정을 다룹니다.

0. 전제 조건 (Prerequisites)

  • Version: Liberty 25.x 이상 권장
  • Java: Java 8 (OpenJ9) 기준
  • 필수 기능(Feature): server.xml에 아래 피처들이 등록되어 있어야 합니다.
<featureManager>
    <feature>jdbc-4.3</feature>              <!-- JDBC 표준 지원 -->
    <feature>transportSecurity-1.0</feature> <!-- 암호화 비밀번호 사용 시 -->
    <feature>restConnector-2.0</feature>     <!-- 연결 테스트 API용 -->
    <feature>adminCenter-1.0</feature>       <!-- 관리 UI 및 통합 관리 -->
</featureManager>

1. JDBC 드라이버 준비 (Driver Setup)

각 DB 벤더에 맞는 JDBC 드라이버(JAR 파일)를 준비하여 Liberty 공용 리소스 디렉토리에 배치합니다.

DB 파일명 (예시) 다운로드 출처
Oracle ojdbc8.jar Oracle MOS 또는 Maven
DB2 db2jcc4.jar DB 서버의 /sqllib/java
MySQL mysql-connector-j-8.x.jar Maven Central
Tibero tibero6-jdbc.jar TmaxSoft 테크넷

디렉토리 생성 및 복사

관리 편의성을 위해 ${shared.resource.dir}(기본값: usr/shared/resources) 하위에 벤더별 폴더를 만들어 관리하는 것을 추천합니다.

# Oracle 예시
mkdir -p $WLP_HOME/usr/shared/resources/jdbc/oracle
cp ojdbc8.jar $WLP_HOME/usr/shared/resources/jdbc/oracle/

2. 공통 라이브러리 정의 (Library)

server.xml에서 위에서 배치한 JAR 파일을 참조하는 library 태그를 작성합니다.

<!-- Oracle 라이브러리 정의 -->
<library id="OracleLib">
    <fileset dir="${shared.resource.dir}/jdbc/oracle" includes="ojdbc*.jar"/>
</library>

3. 데이터소스 정의 (DataSource Configuration)

DB별로 설정 태그(properties)와 클래스명이 다르므로 주의해야 합니다.

Case A: Oracle Database

<dataSource id="OracleDS" jndiName="jdbc/oracleDS" statementCacheSize="60">
    <jdbcDriver libraryRef="OracleLib"
                javax.sql.ConnectionPoolDataSource="oracle.jdbc.pool.OracleConnectionPoolDataSource"/>
    <!-- URL 방식 연결 -->
    <properties.oracle URL="jdbc:oracle:thin:@//192.168.0.101:1521/ORCL"
                       user="scott" password="{aes}..." />
    <connectionManager maxPoolSize="50" connectionTimeout="6s"
                       reapTime="300" maxIdleTime="1800"/>
</dataSource>

Case B: IBM DB2

<dataSource id="DB2DS" jndiName="jdbc/db2" isolationLevel="TRANSACTION_READ_COMMITTED">
    <jdbcDriver libraryRef="DB2Lib"
                javax.sql.ConnectionPoolDataSource="com.ibm.db2.jcc.DB2ConnectionPoolDataSource"/>
    <properties.db2.jcc databaseName="SAMPLE" serverName="localhost" portNumber="50000"
                        user="db2inst1" password="{aes}..." />
</dataSource>

Case C: Tibero (Tmax)

국산 DB인 Tibero는 properties 태그가 별도로 없으므로 일반적인 속성 주입 방식을 사용하거나, Tibero 전용 프로퍼티를 명시해야 할 수 있습니다.

<dataSource id="TiberoDS" jndiName="jdbc/tibero" statementCacheSize="100">
    <jdbcDriver libraryRef="TiberoLib"
                javax.sql.ConnectionPoolDataSource="com.tmax.tibero.jdbc.ext.TbConnectionPoolDataSource"/>
    <!-- properties.tibero 태그 사용 -->
    <properties.tibero url="jdbc:tibero:thin:@192.168.0.111:8629:tibero"
                       user="admin" password="{aes}..." />
</dataSource>

4. 비밀번호 암호화 (Security)

설정 파일에 비밀번호를 평문으로 저장하는 것은 보안상 위험합니다. securityUtility를 이용해 AES로 암호화합니다.

암호화 실행

# 암호화 키 지정 (예: passw0rd)
$WLP_HOME/bin/securityUtility encode --encoding=aes --key=passw0rd 'DB_REAL_PASSWORD'
# 결과: {aes}AA6wcy4K2Xm...

키 등록 (bootstrap.properties)

서버가 암호를 복호화할 수 있도록 키를 등록해줍니다.

wlp.password.encryption.key=passw0rd

5. 연결 테스트 및 검증 (Validation)

서버를 기동한 후, REST API를 통해 데이터소스 연결 상태를 체크할 수 있습니다.

필수 확인 (Check Point):
해당 API를 호출하거나 웹 관리 콘솔(Admin Center)을 이용하기 위해서는 adminCenter-1.0restConnector-2.0 피처가 반드시 활성화되어 있어야 하며, 접근하는 계정에 관리자(Administrator) 권한이 있어야 합니다.

연결 테스트 명령어 (curl)

# 관리자 계정(admin)으로 인증 후 테스트 API 호출
curl -k -u admin:passw0rd \
  https://localhost:9443/ibm/api/validation/dataSource/OracleDS

성공 시: 200 OK와 함께 JSON 응답 내에 "Valid" 메시지가 포함됩니다.
실패 시: messages.log 파일에서 CWLLG2010E(로드 실패), CWNEN0034E(연결 실패) 등의 에러 코드를 확인합니다.


6. 트러블슈팅 체크리스트

  • ClassNotFoundException: library 경로 오타 또는 JAR 파일 권한(755) 확인
  • Connection Timeout: DB 방화벽(Port) 오픈 여부 확인
  • Authentication Failed: bootstrap.properties에 암호화 키가 올바르게 등록되었는지 확인
Open Stream →
#Liberty

[WebSphere Liberty] 설정 유연화의 핵심: 변수(Variable) 활용법 및 우선순위 완벽 정리

WebSphere Liberty의 설정 파일(server.xml)에서 포트 번호, DB 접속 정보 등을 하드코딩하지 않고 변수(Variable)로 관리하는 방법을 정리합니다. bootstrap.propertiesserver.xml, 환경 변수 간의 우선순위 규칙과 JDBC URL 설정 시 발생하는 슬래시(/) 정규화 문제를 해결하는 팁을 다룹니다.

0. 변수를 왜 사용해야 하나요?

서버 설정을 변수화하면 하나의 server.xml 파일을 여러 서버 인스턴스나 환경(Dev/Test/Prod)에서 공유할 수 있습니다. 변경되는 값(포트, IP 등)만 별도로 분리하여 관리 효율성을 높일 수 있습니다.


1. 변수 정의 위치 및 우선순위 (Precedence)

Liberty에서 변수를 정의할 수 있는 곳은 크게 세 군데입니다. 만약 같은 이름의 변수가 여러 곳에 정의되어 있다면, 아래 순서대로 덮어씌워집니다. (아래쪽이 우선순위 높음)

  1. 프로세스 환경 변수 (OS Environment Variables): 가장 낮은 우선순위
  2. bootstrap.properties: 환경 변수를 덮어씀
  3. server.xml (또는 include 된 xml): 가장 높은 우선순위 (최종 승자)
Best Practice:
서버별로 달라지는 고유 설정(예: HTTP 포트)은 bootstrap.properties에 정의하고, 여러 서버가 공유하는 공통 설정(예: DB 설정)은 included xml 파일에 정의하는 것이 좋습니다.

2. 변수 사용 방법 (Usage Guide)

Case A: bootstrap.properties 활용

서버 인스턴스 생성 시 자동으로 만들어지는 파일로, key=value 형태로 간단하게 정의합니다.

# bootstrap.properties
# 포트 번호 정의
http.port=8080
https.port=9443

Case B: server.xml 활용

<variable> 태그를 사용하여 정의하거나, 정의된 변수를 ${...} 문법으로 사용합니다.

<!-- 변수 정의 (Global) -->
<variable name="http.port" value="8080" />

<!-- 변수 사용 -->
<httpEndpoint id="defaultHttpEndpoint"
              httpPort="${http.port}"
              httpsPort="${https.port}" />

Case C: 환경 변수(Environment Variable) 활용

OS 환경 변수를 가져올 때는 env. 접두사를 사용합니다.

<!-- OS의 LIBRARY_DIR 환경 변수 사용 -->
<fileset dir="${env.LIBRARY_DIR}" includes="*.jar"/>

3. 고급 활용 팁 (Advanced Tips)

1) JDBC URL 슬래시(/) 정규화 문제 해결

Liberty 설정 파서(Parser)는 변수 값에 포함된 연속된 슬래시(//)를 단일 슬래시(/)로 정규화하는 특성이 있습니다. 이 때문에 JDBC URL 등이 깨질 수 있습니다.

해결책: 값을 두 부분으로 나누어 정의하거나, 이중 슬래시로 시작하게 합니다.

# [Bad] 이렇게 하면 jdbc:db2:/host.com 으로 변환되어 에러 발생
# DB_URL="jdbc:db2://host.com"

# [Good] 두 부분으로 나누어 결합
URL_PART_1="jdbc:db2:"
URL_PART_2="//host.com"
<dataSource ...>
    <properties.db2.jcc url="${URL_PART_1}${URL_PART_2}" />
</dataSource>

2) 리스트(List) 변수 처리

콤마(,)로 구분된 값을 단순 문자열이 아닌 리스트로 인식시키려면 ${list(...)} 함수를 사용합니다.

<variable name="ports" value="80,9080"/>

<!-- 문자열 "80, 9080"으로 인식 -->
<myConfig value="${ports}" /> 

<!-- 리스트 ["80", "9080"]으로 인식 -->
<myConfig value="${list(ports)}" />

3) 산술 연산 (Arithmetic)

포트 오프셋 등을 설정할 때 간단한 사칙연산(+, -, *, /)이 가능합니다.

<!-- 기본 포트(8080)에 1을 더해 8081로 설정 -->
<httpEndpoint id="secondaryEndpoint" httpPort="${http.port+1}" />

4. 변수 명명 규칙 (Naming Convention)

변수 이름은 반드시 알파벳(문자)으로 시작해야 하며, 아래 문자들만 포함할 수 있습니다.

  • 알파벳 문자 (Alphabetic characters)
  • 숫자 (Numeric characters)
  • 언더스코어 (_)
  • 점 (.)

Next Step:
이제 server.xml에서 하드코딩된 값을 제거하고 bootstrap.properties로 옮겨보십시오. 이를 통해 Docker 이미지 빌드나 여러 환경 배포 시 설정 관리가 훨씬 수월해질 것입니다.

Open Stream →
#Liberty

[WebSphere] Liberty Performance Tuning: 주요 구성 매개변수 가이드

Summary: WebSphere Liberty(Open Liberty) 환경에서 성능 최적화를 위해 조정 가능한 주요 매개변수를 정리한 문서입니다. JVM 힙 설정부터 Connection Pool, Executor, 그리고 유휴 자원 관리까지 server.xmljvm.options를 통한 튜닝 포인트를 다룹니다.

WebSphere Liberty는 기본적으로 자가 튜닝(Self-tuning) 기능을 갖추고 있으나, 운영 환경의 특성이나 애플리케이션의 워크로드 패턴에 따라 명시적인 설정 변경이 필요할 수 있습니다. 본 문서는 IBM Documentation을 기반으로 성능에 직접적인 영향을 주는 핵심 속성들을 정리했습니다.

1. JVM Tuning

가장 기본적이며 중요한 단계입니다. ${server.config.dir}/jvm.options 파일을 사용하여 설정합니다.

  • 개발 환경: 빠른 서버 시작을 위해 최소 힙(Min Heap)은 작게, 최대 힙(Max Heap)은 필요한 만큼 설정.
  • 운영 환경: 런타임 중 힙 크기 조정(Expansion/Contraction)에 따른 오버헤드를 제거하기 위해 최소 힙과 최대 힙을 동일한 값으로 설정하는 것을 권장합니다.

2. Transport Channel Service Tuning

클라이언트 연결, HTTP I/O 처리, 스레드 풀 및 연결 풀 관리를 담당하는 영역입니다. server.xml에서 설정합니다.

HTTP Options

SSL 핸드셰이크 비용이 높거나 처리량이 중요한 애플리케이션의 경우 지속적 연결(Persistent Connection) 설정을 최적화해야 합니다.

  • maxKeepAliveRequests: 단일 HTTP 연결에서 허용되는 최대 요청 수입니다. -1로 설정 시 무제한을 의미하며, 연결 맺는 비용을 절감할 수 있습니다.
<httpOptions maxKeepAliveRequests="-1" />

Connection Manager

데이터베이스 연결 풀(Connection Pool) 성능을 결정짓는 핵심 속성입니다.

  • maxPoolSize: 최대 실제 연결 수 (Default: 50). 모든 스레드가 DB 연결을 필요로 한다면 coreThreads와 1:1 매핑을 고려하십시오.
  • purgePolicy: Stale Connection 발견 시 처리 정책. 기본값은 EntirePool이나, FailingConnectionOnly로 설정하여 실패한 연결만 제거하는 것이 효율적입니다.
  • numConnectionsPerThreadLocal: 실행 스레드별로 DB 연결을 캐싱하여 락 경합(Contention)을 줄입니다. 멀티 코어 시스템에서 성능 향상에 유리합니다.
<connectionManager id="defaultConnectionManager" 
                   maxPoolSize="40" 
                   purgePolicy="FailingConnectionOnly" 
                   numConnectionsPerThreadLocal="1" />

Note: numConnectionsPerThreadLocal 사용 시, maxPoolSize는 (애플리케이션 스레드 수 × 스레드당 연결 수) 이상으로 설정해야 합니다.

3. Data Source Optimization

DB 쿼리 성능 및 데이터 무결성 수준을 조정합니다.

Statement Cache

PreparedStatement 캐싱을 통해 파싱 비용을 줄입니다. 애플리케이션에서 사용하는 고유한 SQL 문장 수보다 크게 설정해야 합니다.

<dataSource ... statementCacheSize="60" > ... </dataSource>

Isolation Level

데이터 무결성과 동시성(Concurrency)은 트레이드오프 관계입니다. isolationLevel 속성으로 조정합니다.

  • TRANSACTION_READ_UNCOMMITTED: 성능 최상, 무결성 최저 (Dirty Read 발생).
  • TRANSACTION_READ_COMMITTED: Dirty Read 방지.
  • TRANSACTION_REPEATABLE_READ: Dirty/Non-repeatable Read 방지.
  • TRANSACTION_SERIALIZABLE: 성능 최저, 무결성 최상 (완전한 직렬화).

4. Executor (Thread Pool) Tuning

Liberty의 Executor는 워크로드에 따라 스레드를 동적으로 조절하는 자가 튜닝 로직을 가지고 있습니다.

  • 기본 원칙: 특별한 문제가 없다면 설정을 변경하지 않는 것이 권장됩니다.
  • 예외 상황: 교착 상태(Deadlock) 해결 로직이 과도하게 작동하거나, 시스템 자원 한계로 스레드 수를 제한해야 할 경우 coreThreadsmaxThreads를 명시합니다.

5. Reducing Overhead & Startup Time

불필요한 CPU 사이클을 줄이고 기동 시간을 단축하기 위한 설정입니다.

Servlet Response Time

WebContainer가 정적 리소스 처리를 위해 META-INF 디렉토리를 스캔하는 과정을 생략합니다.

<webContainer skipMetaInfResourcesProcessing="true"/>

Idle Server CPU

운영 환경에서는 빈번한 애플리케이션/구성 파일 변경 감지가 불필요하므로, 모니터링 주기를 비활성화하거나 늘립니다.

<!-- 아예 비활성화 (권장) -->
<applicationMonitor dropinsEnabled="false" updateTrigger="disabled"/>
<config updateTrigger="disabled"/>

<!-- 혹은 MBean 트리거로 변경 및 폴링 주기 완화 -->
<applicationMonitor updateTrigger="mbean" pollingRate="60s"/>
<config updateTrigger="mbean" monitorInterval="60s"/>

CDI 1.2 Scanning

CDI 1.2 기능은 기본적으로 모든 아카이브를 스캔합니다. 대규모 애플리케이션에서 기동 속도 저하의 주원인이 되므로, 암시적 스캔(Implicit Bean Archives)을 비활성화합니다.

<cdi12 enableImplicitBeanArchives="false"/>

Next Step: 위 설정들은 워크로드의 특성에 따라 효과가 다릅니다. 운영 환경 적용 전, 부하 테스트를 통해 각 파라미터 변경에 따른 처리량(Throughput)과 응답 시간 변화를 측정하시기 바랍니다.

Open Stream →
#Liberty

[WebSphere] Liberty Cluster: End-to-End 구축 및 구성 가이드

Summary: WebSphere Liberty Profile(WLP)의 Collective 및 Cluster 기능을 활용한 인프라 구축 가이드입니다. Controller 구성부터 Member 조인, 클러스터링 설정 및 트러블슈팅까지의 전체 과정을 다룹니다.

WebSphere Application Server Liberty Profile(WLP)은 경량화된 구조와 확장성 덕분에 채택률이 높아지고 있습니다. 본 포스트는 WLP Collective와 Clustering 기능을 사용하여 확장 가능한 토폴로지를 구축하는 방법을 단계별로 정리한 엔지니어링 노트입니다.

이 시리즈는 다음 순서로 진행됩니다.

  • How to Create and Configure WebSphere Liberty Cluster End-to-End (Current)
  • How to Deploy Application in WebSphere Liberty Cluster
  • How to Setup Front-End Web Server for WebSphere Liberty Cluster

1. Topology Architecture

이 가이드에서는 Collective Controller 1대와 Collective/Cluster Member 2대로 구성된 토폴로지를 구현합니다. 프론트엔드에는 IBM HTTP Server(IHS)가 배치되며 별도의 배포 서버가 존재하는 구조입니다.

2. Prerequisites & WLP Installation

본 가이드는 WLP 17.0.2CentOS Linux 7.3 환경을 기준으로 작성되었습니다. 설치 전 지원되는 Java 버전이 설치되어 있는지 확인이 필요합니다.

Check System Environment

$> cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

$> ./java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr4fp5-20170421_01(SR4 FP5))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170419_344392)

Base Installation (Machine: 02)

먼저 Controller가 될 머신(Machine: 02)에 WLP를 설치하고 필요한 기능을 추가한 뒤, 이를 패키징하여 Member 서버들(Machine: 03, 04)로 배포하는 전략을 사용합니다.

# Create directory
$> sudo mkdir -p /opt/ibm

# Change ownership
$> sudo chown -R wasadmin:wasgrp /opt/ibm

# Install WLP
$> java -jar wlp-17.0.0.2-all.jar --acceptLicense /opt/ibm

# Verify version
$> cd /opt/ibm/wlp/bin
$> ./productInfo version
Product name: WebSphere Application Server
Product version: 17.0.0.2

Install Required Features

Collective, Cluster, SSL, JMX Connector 등의 필수 기능을 설치합니다.

$> ./installUtility install collectiveController-1.0 collectiveMember-1.0 clusterMember-1.0 websocket-1.1 restConnector-2.0 ssl-1.0 localConnector-1.0 adminCenter-1.0

Package and Distribute

설치된 환경을 wlp_install.jar로 패키징하여 다른 노드에 복제합니다.

# Create defaultServer for packaging context
$> ./server create

# Package server including all binaries
$> ./server package defaultServer --archive=/tmp/wlp_install.jar --include=all
Server defaultServer package complete in /tmp/wlp_install.jar.

생성된 wlp_install.jar를 Machine 03, 04로 전송한 후 동일하게 설치를 진행합니다.

# On Machine 03 & 04
$> sudo mkdir -p /opt/ibm
$> chown -R wasadmin:wasgrp /opt/ibm
$> java -jar wlp_install.jar --acceptLicense /opt/ibm

3. Setup Collective Controller (Machine: 02)

Controller 서버(wlpCntlr)를 생성하고 구성을 초기화합니다.

# Create server
$> ./server create wlpCntlr

# Initialize Collective Controller
$> ./collective create wlpCntlr --keystorePassword=<password> --createConfigFile=/opt/ibm/wlp/usr/servers/wlpCntlr/wlpcntlr_include.xml

위 명령어를 수행하면 인증서 생성 및 wlpcntlr_include.xml 설정 파일이 생성됩니다. 이후 server.xml과 include 파일을 다음과 같이 수정합니다.

Configuration: server.xml (Controller)

<server description="CollectiveController">
    <featureManager>
        <feature>adminCenter-1.0</feature>
        <feature>websocket-1.1</feature>
        <feature>restConnector-1.0</feature>
        <feature>localConnector-1.0</feature>
    </featureManager>

    <!-- Include generated config -->
    <include location="${server.config.dir}/wlpcntlr_include.xml" />

    <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" host="*" />
</server>

Configuration: wlpcntlr_include.xml

자동 생성된 파일에서 quickStartSecurity 부분을 본인의 계정 정보로 수정합니다.

<quickStartSecurity userName="wasadmin" userPassword="{xor}EncryptedPassword..." />

Firewall Configuration

CentOS 방화벽에서 9080, 9443 포트를 허용해야 합니다.

$> sudo firewall-cmd --zone=public --permanent --add-port=9443/tcp
$> sudo firewall-cmd --zone=public --permanent --add-port=9080/tcp
$> sudo firewall-cmd --reload

Start Controller

$> ./server start wlpCntlr

로그(messages.log)에서 CWWKX6011I: The collective controller is ready 메시지를 확인합니다. Admin Center(https://hostname:9443/adminCenter/) 접속도 가능해야 합니다.

4. Setup Collective & Cluster Members

Machine 03과 04에서 멤버 서버를 생성하고 Controller에 Join 시킵니다.

Create & Join Member (Machine: 03)

# Create Server
$> ./server create wlpSrv01

# Join Collective
$> ./collective join wlpSrv01 \
  --host=waslibctlr01 \
  --port=9443 \
  --user=wasadmin \
  --password=<password> \
  --keystorePassword=<password> \
  --createConfigFile=/opt/ibm/wlp/usr/servers/wlpSrv01/wlpsrv01_include.xml

SSL Handshake 과정에서 인증서를 신뢰하겠냐는 프롬프트에 y를 입력합니다.

Configuration: server.xml (Member)

Member 서버의 server.xml에 Cluster 기능을 추가하고, Controller가 배포 관리를 할 수 있도록 remoteFileAccess를 설정합니다.

<server description="Cluster Member">
    <featureManager>
        <feature>webProfile-7.0</feature>
        <feature>restConnector-1.0</feature>
        <feature>localConnector-1.0</feature>
        <!-- Added for Clustering -->
        <feature>clusterMember-1.0</feature>
    </featureManager>

    <include location="${server.config.dir}/wlpsrv01_include.xml" />

    <!-- Define Cluster Name -->
    <clusterMember name="wlpCluster"/>

    <httpEndpoint id="defaultHttpEndpoint" httpPort="9081" httpsPort="9444" host="*" />

    <!-- Write Access for Controller -->
    <remoteFileAccess>
        <writeDir>${server.config.dir}</writeDir>
    </remoteFileAccess>
</server>

Machine: 04 (wlpSrv02)에 대해서도 위 과정을 동일하게 반복합니다.

Security Considerations (LTPA)

클러스터 환경에서 세션 공유 및 보안을 위해 모든 멤버는 동일한 LTPA 키를 사용해야 합니다. 한 서버에서 생성된 ltpa.keys 파일을 다른 멤버 서버들의 동일한 경로(${server.ouput.dir}/resources/security/)로 복사합니다.

5. Start Members & Verification

각 노드에서 멤버 서버를 시작합니다.

$> ./server start wlpSrv01  # On Machine 03
$> ./server start wlpSrv02  # On Machine 04

로그 파일에서 다음 메시지들을 확인하여 정상 구동을 검증합니다.

  • CWWKX8112I: Collective Repository에 호스트 정보 게시 성공.
  • CWWKX7400I: ClusterMember MBean 활성화 (클러스터 조인 성공).

6. Troubleshooting Notes

설정 과정에서 자주 발생하는 오류와 해결 방법입니다.

  • CWWKX0229E (401 Unauthorized / 403 Forbidden)
    collective join 시 인증 실패. quickStartSecurity의 계정 정보가 일치하는지 확인하십시오. 403 에러의 경우 해당 사용자가 administrator-role을 가지고 있는지 확인해야 합니다.
  • CWWKS9582E (SSL unresolved)
    IIOP 보안 설정 시 SSL 참조 오류. server.xml에 SSL 구성 및 KeyStore 정의가 명확한지 확인하십시오.
  • CWWKO0221E / CWWKS9580E (Port in use)
    한 호스트에 여러 인스턴스를 띄울 경우 JMS 포트(7276)나 IIOP 포트(2809) 충돌이 발생할 수 있습니다. wasJmsEndpointiiopEndpoint 설정을 통해 포트를 변경해야 합니다.

Next Step: 클러스터 구성이 완료되었습니다. 다음 포스트에서는 이 클러스터에 애플리케이션을 배포하는 방법을 다룹니다.

Open Stream →
#Liberty

[IHS/Liberty] 보안 취약점 조치: X-Powered-By 헤더 숨김 및 정보 노출 방지 가이드

IBM HTTP Server(IHS)와 WebSphere Liberty 환경에서 X-Powered-By 헤더(예: Servlet/3.1) 노출을 차단하는 방법을 정리합니다. 보안 강화를 위해 웹 서버(IHS) 단에서의 필터링과 WAS(Liberty) 단에서의 생성 금지 설정을 모두 적용하는 것을 권장합니다.

0. 배경 및 전략 (Context)

보안 취약점 조치 시, 정보 노출 방지는 다계층 방어(Defense in Depth)가 중요합니다.

계층 역할 및 중요성
1. IHS (Web Server) [필수] 최전방 방어선. 백엔드 WAS가 무엇이든 상관없이 클라이언트로 나가는 모든 응답에서 헤더를 강제 삭제합니다.
2. Liberty (WAS) [권장] 소스 차단. 내부망에서 WAS로 직접 접속하는 경우나 웹 서버 설정을 우회하는 경우를 대비해 헤더 생성 자체를 막습니다.

Test Environment

  • Web Server: IBM HTTP Server v9.0 (Apache 2.4 Base)
  • WAS: WebSphere Liberty Core 20.0.x

1. IBM HTTP Server (IHS) 설정

Apache 기반인 IHS에서는 mod_headers 모듈을 사용하여 응답 헤더를 제어합니다.

httpd.conf 수정

설정 파일(httpd.conf)을 열어 아래 내용을 적용합니다.

# 1. 모듈 로드 확인 (주석 해제 필수)
LoadModule headers_module modules/mod_headers.so

# 2. 헤더 제거 설정 (Global 영역 또는 VirtualHost 내부에 작성)
<IfModule mod_headers.c>
    # 보안 조치: 기술 스택 정보 숨김
    Header unset X-Powered-By
    
    # (선택) 추가적인 정보 노출 헤더 차단
    Header unset X-AspNet-Version
    Header unset X-Runtime
</IfModule>

# 3. 서버 버전 정보 최소화 (OS 정보 등 숨김)
ServerTokens Prod
Tip: 설정 후에는 반드시 ./apachectl -t로 문법을 검사하고 재기동(restart 또는 graceful)해야 합니다.

2. WebSphere Liberty 설정

Liberty는 server.xml 파일 하나로 대부분의 설정을 처리합니다. webContainer 요소를 추가하거나 수정하여 헤더 생성을 비활성화합니다.

server.xml 수정

<server description="Liberty Server">

    <!-- Feature Manager (기본 설정) -->
    <featureManager>
        <feature>servlet-3.1</feature>
    </featureManager>

    <!-- [보안 조치] X-Powered-By 헤더 비활성화 속성 추가 -->
    <webContainer disableXPoweredBy="true" />

</server>

Liberty는 동적 설정을 지원하므로 파일 저장 시 즉시 반영되지만, 운영 환경에서는 확실한 적용을 위해 서버 재기동을 권장합니다.


3. 검증 (Verification)

curl 명령어를 사용하여 조치 전후의 응답 헤더를 비교합니다.

조치 전 (Before)

HTTP/1.1 200 OK
X-Powered-By: Servlet/3.1
Server: IBM_HTTP_Server/9.0.5...
...

조치 후 (After)

curl -I http://localhost:80/
HTTP/1.1 200 OK
Server: IBM_HTTP_Server   <-- (Prod 설정으로 버전 숨김)
Content-Type: text/html
...                       <-- (X-Powered-By 헤더 삭제됨)

Next Step:
헤더 조치가 완료되었다면, HTTP 메소드 제한(GET, POST 외 차단)SSL/TLS 프로토콜 버전(TLS 1.2 Only) 설정을 통해 웹 서비스 보안을 한 단계 더 강화해 보십시오.

Open Stream →
#Liberty

[WebSphere Liberty] securityUtility로 SSL 인증서 생성 및 AES 패스워드 암호화 설정 가이드

WebSphere Liberty의 securityUtility 도구를 사용하여 자체 서명된(Self-Signed) SSL 인증서를 생성하고, 보안성을 높이기 위해 Keystore 비밀번호를 AES로 암호화하여 설정하는 방법을 정리합니다.

0. 배경 및 시나리오 (Context)

Liberty 서버는 기본적으로 개발 편의를 위해 SSL 설정을 자동화하지만, 운영 환경에서는 명시적인 인증서 관리와 비밀번호 보안이 필수적입니다. securityUtility를 사용하면 인증서 생성과 비밀번호 암호화(Encoding)를 동시에 수행할 수 있습니다.

Test Environment

  • Middleware: WebSphere Liberty Profile (WLP)
  • Server Name: s11, s12

1. SSL 인증서 생성 및 암호화 (Create Certificate)

securityUtility createSSLCertificate 명령어를 사용하여 키스토어(PKCS12)를 생성합니다. 이때 --passwordEncoding=aes 옵션을 사용하여 설정 파일에 들어갈 비밀번호를 암호화합니다.

명령어 구문

# 구문: securityUtility createSSLCertificate --server=[서버명] --password=[키패스워드] --validity=[유효기간일수] --passwordEncoding=aes --passwordKey=[암호화키]

cd $WLP_HOME/bin
./securityUtility createSSLCertificate --server=s11 --password=passw0rd --validity=7300 --passwordEncoding=aes --passwordKey=passw0rd

실행 결과

키 저장소 /sw/was/WebSphere/wlp/usr/servers/s11/resources/security/key.p12을(를) 작성하는 중입니다.

서버 s11에 대한 SSL 인증서를 작성했습니다. 
이 인증서는 CN=testwas11,OU=s11을(를) 사용하여 SubjectDN으로 작성되었습니다.
Tip: 여기서 생성된 키스토어 파일(key.p12)은 usr/servers/[서버명]/resources/security/ 경로에 저장됩니다.

2. 서버 설정 적용 (server.xml)

위에서 생성된 인증서를 서버가 사용하도록 server.xml을 수정합니다. 이때 비밀번호 부분에 {aes}... 로 시작하는 암호화된 문자열을 입력해야 합니다.

<server description="SSL Server">

    <!-- 1. SSL 기능 활성화 -->
    <featureManager>
        <feature>transportSecurity-1.0</feature>
    </featureManager>

    <!-- 2. Keystore 정의 (비밀번호는 암호화된 값 사용) -->
    <keyStore id="defaultKeyStore" 
              location="key.p12"
              password="{aes}AJS+VEek/Fgo/zp46z8cuIUMTbnMM7sJVmPPbT49n4s6" />

</server>

3. 암호화 키 등록 (bootstrap.properties)

server.xml에 적힌 {aes} 비밀번호를 서버가 복호화하려면, 암호화할 때 사용했던 Key를 서버에 알려주어야 합니다. 이 설정은 bootstrap.properties 파일에 저장합니다.

  • 파일 위치: usr/servers/[서버명]/bootstrap.properties
# securityUtility 실행 시 --passwordKey 옵션에 넣었던 값
wlp.password.encryption.key=passw0rd
주의: 이 설정이 누락되면 서버 기동 시 CWWKS1704E: 비밀번호를 복호화할 수 없습니다. 에러가 발생합니다.

4. 인증서 검증 (Verification)

생성된 키스토어 파일이 정상적인지, 유효기간은 맞는지 확인하기 위해 JDK에 포함된 keytool 명령어를 사용합니다.

검증 명령어

# keytool -list -v -keystore [파일경로] -storetype PKCS12 -storepass [비밀번호]
./keytool -list -v -keystore /sw/was/WebSphere/wlp/usr/servers/s12/resources/security/key.p12 -storetype PKCS12 -storepass passw0rd

출력 결과 분석

키 저장소 유형: PKCS12
키 저장소 제공자: SUN

별칭 이름: default
생성 날짜: 2024. 6. 12.
항목 유형: PrivateKeyEntry
인증서 체인 길이: 2

# 유효기간 확인
적합한 시작 날짜: Wed Jun 12 16:47:57 KST 2024 
종료 날짜: Tue Jun 07 16:47:57 KST 2044 (약 20년)

# 소유자 및 서명 알고리즘 확인
소유자: CN=testwas11, OU=s12, O=ibm, C=us
서명 알고리즘 이름: SHA256withRSA
주체 공용 키 알고리즘: 2048비트 RSA 키

Next Step:
자체 서명 인증서(Self-Signed)는 브라우저에서 경고가 발생하므로, 운영 환경에서는 CSR을 생성하여 공인 인증기관(CA)의 서명을 받은 후 keytool -import 명령어로 교체해야 합니다.

Open Stream →
#Liberty

[WebSphere Liberty] installUtility 사용법 완벽 가이드: Feature 검색, 다운로드 및 로컬 저장소 구성

WebSphere Liberty의 기능(Feature)을 관리하는 커맨드 라인 도구인 installUtility의 핵심 사용법을 다룹니다. 온라인 IBM 저장소에서 기능을 검색/다운로드하는 방법과, 사내 폐쇄망 환경을 위한 로컬 리포지토리(Local Repository) 설정 방법을 정리합니다.

Test Environment

  • OS: CentOS 7.2
  • Middleware: IBM Liberty Core 20.0.0.6
  • Tool: installUtility (Located in $WLP_HOME/bin)

1. Feature 검색 및 다운로드 (Basic Usage)

IBM의 공인 저장소(IBM WebSphere Liberty Repository)에 연결하여 필요한 기능을 찾거나 다운로드합니다.

기능 검색 (Find)

설치 가능한 기능의 정확한 이름을 모를 때 유용합니다.

# 구문: installUtility find [검색어]
installUtility find jsp --type=feature

기능 다운로드 (Download)

서버에 바로 설치하지 않고, 파일(ESA) 형태로 로컬 디렉토리에 다운로드합니다. 이 파일들은 나중에 로컬 저장소를 구축할 때 사용됩니다.

# 구문: installUtility download [기능명] --location=[경로]
installUtility download jsp-2.3 --location=/SW/img/LibertyUtility --acceptLicense

2. 로컬 저장소 구성 (Repository Configuration)

인터넷이 차단된 서버나, 사내 표준 라이브러리를 관리하기 위해 로컬 디렉토리를 저장소로 등록하여 사용합니다.

설정 파일 위치

Liberty 설치 경로 내의 etc 디렉토리에 설정 파일을 생성해야 합니다.

  • 위치: ${wlp.install.dir}/etc/repositories.properties

설정 내용 (repositories.properties)

다운로드 받아둔 Feature 파일들이 위치한 경로를 url로 지정합니다.

# Local Repository Path Configuration
# 로컬 파일 시스템 경로 또는 사내 웹 서버 URL 지정 가능
local-rep.url=/SW/img/LibertyUtility
Tip: useDefaultRepository=false 옵션을 추가하면 IBM 공인 저장소 접속을 차단하고 로컬 저장소만 바라보게 강제할 수 있습니다.

3. 설정 검증 (Verification)

작성한 리포지토리 설정이 정상적으로 인식되는지 확인합니다.

설정 확인 (viewSettings)

현재 적용된 리포지토리 목록과 우선순위를 출력합니다.

installUtility viewSettings

(출력 결과에서 local-rep.url이 목록에 포함되어 있는지 확인)

연결 테스트 (testConnection)

지정한 경로로 접근이 가능한지 최종 테스트합니다.

# 특정 저장소 테스트
installUtility testConnection local-rep

# 또는 전체 테스트
installUtility testConnection --all

4. 참고 자료 (References)


Next Step:
로컬 저장소 구성이 끝났다면, installUtility install [기능명] 명령어를 통해 인터넷 연결 없이도 필요한 기능을 서버에 즉시 설치해 보십시오.

Open Stream →
#Liberty

[WebSphere] Liberty Profile & Eclipse 연동 개발 환경 구축 가이드 (WDT 설치)

IBM WebSphere Liberty Profile(WLP)을 로컬 개발 환경인 Eclipse에 연동하여 애플리케이션 개발, 배포, 디버깅 환경을 구축하는 절차를 정리합니다. IBM WebSphere Developer Tools(WDT) 플러그인 설치 및 서버 런타임 구성 과정을 포함합니다.

Test Environment

  • OS: Windows 10
  • IDE: Eclipse IDE for Enterprise Java Developers (2020-06 이상 권장)
  • Middleware: WebSphere Liberty Profile (Kernel or Core)

1. 사전 준비 (Prerequisites)

Liberty 개발 환경을 구축하기 위해서는 Java SDK와 Eclipse가 미리 설치되어 있어야 합니다.

  • JDK: 1.8 이상 설치 및 환경 변수(JAVA_HOME) 설정.
  • Eclipse: 'Eclipse IDE for Enterprise Java and Web Developers' 패키지 사용 권장.

2. WebSphere Developer Tools (WDT) 플러그인 설치

Eclipse에서 Liberty 서버를 제어하기 위해서는 전용 플러그인을 설치해야 합니다.

설치 절차

  1. Eclipse 메뉴에서 Help > Eclipse Marketplace...를 선택합니다.
  2. 검색창에 IBM Liberty 또는 WebSphere Developer Tools를 입력합니다.
  3. "IBM Liberty Developer Tools" 항목을 찾아 Install 버튼을 클릭합니다.
  4. 라이선스 동의 후 설치를 진행하며, 완료 후 Eclipse를 재시작합니다.

3. Liberty 런타임(Runtime) 등록

이미 설치된 Liberty Core를 Eclipse에 등록하거나, Eclipse를 통해 새로 다운로드할 수 있습니다.

서버 등록 과정

  1. Servers 뷰에서 우클릭 > New > Server 선택.
  2. 서버 타입에서 IBM > WebSphere Liberty 선택.
  3. Server's host namelocalhost, Server name은 식별 가능한 이름 입력.
  4. Runtime Environment 설정 단계:
    • 기존 설치된 경우: 'Choose an existing installation' 선택 후 Liberty 설치 경로(wlp 폴더) 지정.
    • 새로 설치할 경우: 'Install from an archive or a repository' 선택 후 원하는 버전 다운로드.
  5. Finish를 클릭하여 설정을 완료합니다.

4. 서버 구동 및 애플리케이션 배포

설정이 완료되면 Eclipse 내에서 서버를 제어할 수 있습니다.

서버 제어

  • Start: Servers 뷰에서 서버 우클릭 > Start (또는 Debug).
  • Console 확인: CWWKF0011I: The server defaultServer is ready to run a smarter planet. 메시지가 뜨면 정상 구동된 것입니다.

프로젝트 배포

  1. Dynamic Web Project 생성.
  2. 프로젝트 우클릭 > Run As > Run on Server.
  3. 등록한 Liberty 서버를 선택하고 Finish.
  4. server.xml에 애플리케이션 구성이 자동으로 추가되며 배포가 진행됩니다.

5. 참고 영상 (Reference Video)

실제 설치 및 구동 과정에 대한 데모 영상입니다.


Next Step:
개발 환경 구축이 완료되었다면, server.xml 파일의 <featureManager> 섹션을 수정하여 필요한 기능(JSP, Servlet, JDBC 등)을 활성화하는 방법을 학습해 보십시오.

Open Stream →
#Liberty

[WebSphere] Liberty Core 설치 및 필수 설정 가이드 (CLI Install, server.xml, Plugin)

IBM WebSphere Liberty Core를 GUI 없이 Command Line(CLI) 환경에서 설치하고, 서버 생성 및 기동, 핵심 설정(server.xml, JVM), 그리고 웹 서버 연동을 위한 플러그인 생성(pluginUtility) 과정을 단계별로 정리합니다.

1. 제품 설치 (CLI Mode)

Liberty는 Installation Manager(IM)의 imcl 명령어를 통해 설치합니다. GUI를 사용할 수 없는 리눅스/유닉스 서버 환경에서 필수적인 방법입니다.

설치 명령어 (imcl)

-repositories 옵션에는 설치 파일(Repository)의 경로를 지정합니다. 콤마(,)로 구분하여 WAS와 JDK 리포지토리를 동시에 지정할 수 있습니다.

# 설치 예시 (Windows 기준, Linux는 경로만 변경)
imcl install com.ibm.websphere.liberty.v85_8.5.16002.20160526_2338 \
com.ibm.websphere.liberty.IBMJAVA.v80_8.0.3020.20161124_1304 \
-repositories "D:\Liberty\16.0.0.2-WS-LIBERTY-CORE,D:\work_file\was_install\v8.5.5\SDK\8.0.3.20" \
-installationDirectory "F:\app\IBM\wlpcore\AppServer" \
-acceptLicense \
-showProgress -sP
Tip: 패키지 ID(com.ibm...)를 모를 경우 imcl listAvailablePackages -repositories [경로] 명령어로 미리 확인해야 합니다.

2. 서버 생명주기 관리 (Server Lifecycle)

설치가 완료되면 bin 디렉토리의 server 스크립트를 사용하여 서버 인스턴스를 생성하고 제어합니다.

1) 서버 생성 (Create)

cd [WLP_HOME]/bin
# 구문: server create [서버명]
server.bat create test01

생성이 완료되면 [WLP_HOME]/usr/servers/test01 경로에 설정 파일들이 만들어집니다.

2) 서버 기동 및 상태 확인 (Start/Status)

# 서버 기동
server.bat start test01

# 상태 확인 (필수 검증 단계)
server.bat status test01

3. 핵심 설정 (server.xml)

Liberty의 모든 구성은 server.xml 파일 하나에 통합되어 있습니다. 필요한 기능(Feature)만 선언해서 사용하는 구조입니다.

설정 파일 위치

  • [WLP_HOME]/usr/servers/[서버명]/server.xml

주요 설정 예시

<?xml version="1.0" encoding="UTF-8"?>
<server description="Test Server">

    <!-- 1. Feature Manager: 필요한 기능 모듈 로드 -->
    <featureManager>
        <feature>jsp-2.2</feature>
        <feature>jdbc-4.0</feature>
        <feature>localConnector-1.0</feature> <!-- 로컬 관리용 -->
        <feature>adminCenter-1.0</feature>    <!-- 웹 관리 콘솔 -->
    </featureManager>

    <!-- 2. HTTP Endpoint: 포트 설정 -->
    <!-- host="*"는 모든 IP 대역에서의 접속을 허용함 -->
    <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="9443">
        <tcpOptions soReuseAddr="true" />
    </httpEndpoint>

    <!-- 3. Web Server Plugin 설정 -->
    <pluginConfiguration webserverPort="80" webserverSecurePort="443"/>

    <!-- 4. Application 배포 설정 (자동 인식이 편함) -->
    <applicationManager autoExpand="true"/>
    
    <!-- 5. DB Connection (Oracle 예시) -->
    <dataSource id="WorklightDS" jndiName="jdbc/WorklightDS">
        <jdbcDriver libraryRef="OracleLib"/>
        <properties.oracle 
            driverType="thin" 
            databaseName="ORCL" 
            serverName="localhost" 
            portNumber="1521" 
            user="SCOTT" 
            password="{xor}KDAtNDM2ODcr"/> <!-- securityUtility로 암호화 권장 -->
    </dataSource>

    <!-- 6. Logging 설정 -->
    <logging maxFiles="5" consoleLogLevel="INFO"/>

</server>
초보자를 위한 Tip:
설정 파일의 password="{xor}..." 부분은 평문을 그대로 넣지 않고, Liberty가 제공하는 bin/securityUtility encode [암호] 명령어를 사용하여 인코딩된 값을 넣어야 보안상 안전합니다.

4. 환경 변수 및 JVM 옵션 설정

메모리(Heap) 설정이나 로그 경로 변경 등은 별도의 설정 파일에서 관리합니다.

1) JVM 옵션 (jvm.options)

Heap Size나 GC 로그 설정은 jvm.options 파일에 라인 단위로 작성합니다.

  • 위치: [WLP_HOME]/usr/servers/[서버명]/jvm.options
# Heap Memory 설정
-Xms512m
-Xmx1024m

# GC 로그 설정
-verbose:gc
-Xverbosegclog:verbosegc.log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC

2) 환경 변수 (server.env)

JAVA_HOME 지정이나 커스텀 로그 경로는 server.env에 정의합니다.

# Java 버전 지정
JAVA_HOME=C:\Java\jdk1.8.0

# 로그 경로 변경 (Optional)
WLP_OUTPUT_DIR=F:\app\IBM\wlpcore\AppServer\usr\logs\test02

5. 웹 서버 플러그인 (Plugin) 생성

Liberty 서버 앞단에 IHS(Apache)를 둔다면, plugin-cfg.xml을 생성하여 웹 서버에 알려주어야 합니다.

플러그인 생성 도구 (pluginUtility)

Liberty 16.0.0.4 버전부터 pluginUtility 명령어를 사용합니다.

cd [WLP_HOME]/bin

# 1. 로컬 서버용 플러그인 생성
pluginUtility generate --server=test01 --targetpath=./plugin-cfg.xml

# 2. 원격 서버용 플러그인 생성 (Admin Center 기능 필요)
pluginUtility generate --server=admin:password@remoteHost:9443 --targetpath=./plugin-cfg.xml

# 3. 여러 플러그인 병합 (Merge)
pluginUtility merge --sourcepath=../usr/plugin --targetpath=../usr/merged_plugin.xml

웹 서버(httpd.conf) 적용

생성된 xml 파일을 웹 서버로 복사한 후 httpd.conf에 등록합니다.

# Windows 예시
LoadModule was_ap22_module "C:\IBM\HTTPServer\plugins\bin\mod_was_ap22_http.dll"
WebSpherePluginConfig "C:\IBM\HTTPServer\plugins\config\webserver1\plugin-cfg.xml"

# Linux/Unix 예시
LoadModule was_ap22_module "/opt/IBM/HTTPServer/plugins/bin/mod_was_ap22_http.so"
WebSpherePluginConfig "/opt/IBM/HTTPServer/plugins/config/webserver1/plugin-cfg.xml"

Next Step:
기본 설치와 설정이 끝났다면, adminCenter 기능을 활성화하고 브라우저(https://localhost:9443/adminCenter)로 접속하여 GUI 환경에서 서버 상태를 모니터링해 보십시오.

Open Stream →