1. 개요

1) Openshift 컨테이너의 특징

내용	비고
Hostname 또는 IP가 임의로 생성 및 변경됨	Openshift는 Pod 단위로 IP가 부여되며 최초 생성시 및 재생성시 내부IP로 부여된다. Hostname이 [Application명]-xxxxx 형태로 부여된다.
Pod 재생성시 컨테이너 내부 데이터는 초기화됨
Openshift는 보안상 컨테이너 실행시 임의의 User가 만들어져 사용됨	root유저 및 특정 User의 사용이 제한됨 (옵션으로 허용 가능) Openshift의 Pod 내에서 User는 임의의 숫자 형태 (예: 1000060000)이며 Group 권한이 Root 로 지정됨
표준출력으로 전달되는 로그는 Web Console의 Log 탭에서 조회됨	컨테이너는 Foreground로 실행되므로 표준출력파일은 별도로 지정할 수 없고 CLI 또는 Web Console에서 조회 가능함 일반 File 로그는 기존과 동일하게 사용가능

2) 주요 고려사항

기존 시스템을 Openshift로 옮기는 경우 고려할 사항에 대해서 다음과 같은 기준으로 생각해볼 필요가 있다.

구분	내용	비고
1) 컨테이너화 대상선정	시스템의 여러 구성요소 중에서 컨테이너로 옮길 부분을 검토	Windows 전용 시스템은 리눅스로 우선 변경 후 컨테이너화 필요 무거운 레거시 형태 WAS는 가벼운 오픈소스 WAS로 우선 변경 필요 DB는 아직 Recommand 하지 않으나 성능에 Critical하지 않은 경우만 사용가능 독립 배포되는 war 별로 컨테이너로 구성 세션 클러스터링이 필요없는 어플리케이션이 확장 시 더 효율적
2) WEB/WAS 연동 아키텍처	WAS의 IP가 고정될 수 없고 Scale Out을 고려해야 하므로 Web서버에서 WAS IP 지정방식의 연동방법은 사용할 수 없음	Openshift의 장점은 동적 확장인데 기존의 WEB/WAS 연동 구조에서는 동적 확장이 어려우므로 WEB은 제외하고 WAS로만 서비스하는 Simple한 아키텍처 구성이 효율적
3) Base 이미지선택	WAS로 사용할 수 있는 Official 이미지가 있는지 확인	WAS 벤더에서 제공하는 이미지가 있으면 우선적으로 사용 컨테이너화에 문제가 없는 경우에 한해 이미지 작성지원
4) Session Clustering	IP가 임의로 변경되므로 IP 지정방식에 의한 세션클러스터링은 사용할 수 없음	기본적으로 Openshift 에서는 확장이 쉬운 Micro Service Architecture (MSA) 에 최적화 되어 있음 세션클러스터링은 확장시 오버헤드가 증가하므로 기본적으로는 권장하지 않음 동적 클러스터링 방식은 구성가능(Multicast 를 이용한 방식 등) 세션클러스터링 방식은 WAS마다 다르므로 벤더에 확인필요
5) 어플리케이션 설정 값	시스템에서 변경이 필요한 값은 이미지에 넣지 않고 별도 관리	변경이 필요한 설정값이 어떤 것이 있는지 대상확인 변경값 적용 방식 확인 (어플리케이션 설정 값 및 JAVA Option은 환경변수 이용 등)
6) 어플리케이션 소스	소스에서 특정 Hostname이나 IP 주소에 기반한 로직이 있으면 수정필요	Web서버를 별도 URL로 구성하는 경우 Static Content의 URL경로 수정 필요
7) 대용량 컨텐츠	어플리케이션에서 사용하는 대용량 컨텐츠가 있는 경우 이미지를 복사하거나 Build 할때 느려지므로 공유볼륨 사용에 대한 확인 필요	NFS를 통해 공유볼륨을 구성 공유볼륨을 PV(Permanent Volume)로 컨테이너에 마운트하여 사용
8) 내부 인터페이스 주소	Openshift 내부에 인터페이스 해야할 API서버 등이 있는 경우 대상 IP가 동적으로 생성되므로 연동방법 확인필요	Openshift의 Service 명 또는 환경변수 이용
9) Logging	Standard Out 으로 출력되는 로그는 오픈시프트 콘솔에서 확인가능	파일로 저장이 필요한 로그는 기존과 동일하게 파일로 출력 로그가 저장되는 디렉토리는 NFS등을 이용하여 Permanent Volume으로 연결

3) Migration Work Flow

단계1	단계2	내용	비고
분석	요건분석	필요사항 분석
	어플리케이션 및 아키텍처 분석	Apache 및 JBoss 아키텍처를 Container 환경에 맞게 분석
	솔루션 현황/ 호환성 분석	어플리케이션에서 사용중인 솔루션 현황 파악 및 Container 배포 적합성 검토	해당 솔루션 벤더와 협의필요
	WAS 종류 및 버전 변경 시 WAS 마이그레이션	WAS 버전 변경시 영향도 분석
Preparation	사전 검증 테스트	Docker Container에 어플리케이션을 배포하여 컨테이너 환경에 적합한지 사전 검증	Docker만 사용하여 테스트
	이행 계획 수립	컨테이너 배포 검증 결과를 토대로 Openshift 배포계획 수립
	WAS 이미지 및 Build 정책수립	사용할 이미지 및 어플리케이션에 맞게 Build 정책 수립
Migration	S2I 빌드 환경구성	Gitlab, Image Registry 등 구성
	WAS 이미지 Build 구성	ImageStream 구성
	Application Build 및 배포	Git과 ImageStream 구성 후 Application Build 수행
	배포 테스트	정상 배포여부 테스트
Optimization	VM OS 최적화	Container가 운영되는 기반인 VM (OS) 최적화
	JBoss Container 최적화	JBoss Container 설정 최적화
	Application Build 최적화	어플리케이션 생성 시 Template으로 최적화하여 구성
	App 컨테이너 마이그레이션 내역서	App 컨테이너 마이그레이션 내역서 정리

2. 상세내용

1) 컨테이너화 대상선정

고려사항
- Windows 전용 시스템은 리눅스로 우선 변경 후 컨테이너화 필요
- 하나의 시스템 내에 여러개의 웹 어플리케이션과 DB가 있는 경우, 각각의 웹 어플리케이션과 DB를 분리하여 컨테이너로 구성한다.
- 무거운 레거시 형태 WAS는 가벼운 오픈소스 WAS로 우선 변경 필요
- DB는 Data를 저장해야 하므로 NFS를 이용한 Permanent Volume을 이용하여야 하는데, 이 경우 네트웍을 사용하여 데이터를 로딩하게 되므로 원하는 성능을 기대하기 어렵다. 따라서 DB는 Openshift로 Migration하기 어렵다.
- 어플리케이션은 WAR 단위로 별도의 컨테이너를 사용하여 분리한다.
- 하나의 WAR도 Micro-Service의 개념으로 분리하면 좋지만 비용대비 효율적인 방법을 찾는 것이 중요하다.

2) Web / WAS 연동 아키텍처

고려사항
- Openshift의 장점은 동적 확장인데 기존의 WEB/WAS 연동 구조에서는 동적 확장이 어려우므로 LB를 위한 WEB은 제외하고 WAS로만 서비스하는 Simple한 아키텍처 구성이 효율적이다.
- WEB서버에서 Image, CSS, JS 등 Static 컨텐츠를 서비스하고 있는 경우는 관련 컨텐츠를 WAS로 통합하여 서비스한다.
- LB 기능 없이 이미지서버를 별도 URL로 구성하여 사용하는 경우는 동일하게 이미지 전용 WEB서버 Pod를 생성하여 사용가능하다.
- SSL은 Openshift Route에서 처리가능하다.

아키텍처 변경

일반적인 WEB/WAS 연동구조

Openshift에서 적용 가능한 구조

비고

Web서버의 Static Contents를 WAS로 통합

심플한 구조로 가장 많이 사용되며 클라우드 환경에서 효율적인 구조

Web서버를 별도로 구성하는 경우

Web서버가 별도의 URL을 사용하므로 리소스 위치 관련된 소스 수정필요

WEB, WAS를 하나의 Pod로 구성

별도의 템플릿 필요하며 Pod가 복잡성이 증가하므로 관리포인트 증가됨

3) Base 이미지 선택

고려사항
- 기본적으로 대부분의 Opensource WAS는 공식 이미지가 존재하므로 이것을 그대로 사용하면 된다.
- 오래된 버전인 경우는 이미지가 존재하지 않을 수 있으니 확인이 필요하다.
- 일반적으로 마이너 버전의 차이는 크지 않으므로 가능하면 최신 버전을 사용하는 것이 좋다.

이미지 관련 주로 발생하는 이슈사항
Icon
- Docker 에서 실행시는 문제가 없지만 Openshift에서 실행시는 root유저 및 특정 User의 사용이 제한되기 때문에 권한 문제가 발생가능
- Openshift의 Pod 내에서 User는 임의의 숫자 형태이며 Group 권한이 Root 로 지정되므로 Group권한 조정을 통해 해결가능
- 이미지의 권한조정이 어려운 경우는 Openshift의 ANYUID 옵션을 통해 해결가능

Tomcat의 이미지 버전 (샘플)
Tomcat Official
Supported tags and respective Dockerfile links

4) 세션 클러스터링

고려사항
IP가 임의로 변경되므로 IP 지정방식에 의한 세션클러스터링은 사용할 수 없음
- 기본적으로 Openshift 에서는 확장이 쉬운 Micro Service Architecture (MSA) 구조에 최적화 되어 있음
- 세션클러스터링은 확장시 오버헤드가 증가하므로 기본적으로는 권장하지 않음
- 동적 클러스터링 방식은 구성가능(Multicast 를 이용한 방식 등)
- 세션클러스터링 방식은 WAS마다 다르므로 벤더에 확인필요

JBoss의 세션 클러스터링

JBoss를 사용하는 경우 JBoss의 Kube-Ping 모듈을 이용하여 Openshift 상에서 세션클러스터링 기능을 사용할 수 있다.
Kube-Ping은 쿠버네티스 환경에서 동적으로 JBoss Pod의 IP를 확인하여 클러스터링을 맺을 수 있는 기능이다.

5) 어플리케이션 설정 값

고려사항

일반적으로 시스템은 변경 가능한 값을 설정파일에 넣거나 환경변수로 관리한다.
JAVA Option 및 어플리케이션 설정은 환경변수를 이용할 수 있다.

적용방법

구분

주요 내용

변경방법

Java Option

Java Memory 설정

Heap Dump 설정

GC Log 설정 등

환경변수 JAVA_OPTS를 설정하고 WAS 기동시 사용한다.

어플리케이션 설정

어플리케이션 필요 내용

필요한 내용을 환경변수로 설정하고 설정파일에서 환경변수를 사용하도록 변경한다.

환경변수 사용 예
- Java
- NodeJS
  server.js
- JBoss EAP 설정파일
  standalone-openshift.xml
  Icon
  
  위의 방식은 JBoss에서만 가능함. (https://access.redhat.com/solutions/294583)
  Syntax: ${<[env.]name>[,<[env.]name2>[,<[env.]name3>...]][:<default>]}

Java System Property (JAVA_OPTS) 사용방법

Icon

환경변수 JAVA_OPTS에 값을 지정하면 자동으로 Tomcat의 System Property로 넘어가므로 Tomcat 설정파일에서 이 값을 사용할 수 있다.

Tomcat 컨테이너 실행

설정파일에서 변수처리
Java System Property로 넘어온 db_host 를 이용하여 설정파일 작성

6) 어플리케이션 소스 확인사항

Openshift 특징

7) 대용량 컨텐츠

고려사항

대용량 컨텐츠가 이미지에 들어가는 경우 이미지 빌드 및 복사가 느려질 수 있고 Scale out시에 용량을 많이 차지하게 된다.
따라서 공유스토리지에 대용량 컨텐츠를 넣어두고 PV (Permanent Volume)를 이용하여 Pod에서 Mount하여 사용하는것이 효율적이다.

컨테이너에서 외부 볼륨 사용을 위한 가이드

Icon

데이터 저장을 위한 스토리지가 필요하다. (NFS, HostPath, GlusterFS, Ceph, ISCSI 등)
외부 볼륨은 NFS를 사용하는 것이므로 네트워크 상황에 따라 내부 파일시스템보다 성능이 느려질 수 있다.
마운트할 Container의 디렉토리 경로로 volume을 지정한다. (Openshift에서 별도로 지정 가능)
Template을 사용하여 Volume을 자동으로 할당받도록 하는 것이 편리하다.(Template을 사용하지 않으면 수동으로 지정해야함)

8) 내부 인터페이스 주소

고려사항

Icon

오픈시프트의 프로젝트 내부에 API 서버가 있고 같은 프로젝트 내의 다른 어플리케이션에서 API 서버와 인터페이스를 해야하는 경우, 이 API서버의 주소를 고정된 형태로 사용해야 한다.
그런데 Pod의 IP는 고정되지 않고 새로 생성될 경우 변경되므로 변경되지 않는 방식의 주소가 필요하다.

Service의 Name을 이용하는 방법
Openshift에서 Pod 앞단에 LB를 위한 Service가 존재한다. 이 Service의 이름은 Application 명으로 고정되므로 이를 이용하여 인터페이스가 가능하다.

환경변수를 이용하는 방법
오픈시프트의 Project 내부에서 생성되는 모든 Pod는 생성 시점에 프로젝트 내부에 존재하는 모든 Service 이름과 IP를 환경변수로 가지고 있다.
따라서 이 환경변수를 이용하여 어플리케이션 내부에서 사용할 수 있다.

9) Logging

고려사항
Openshift에서는 컨테이너의 로그를 Web UI에서 바로 조회 할 수 있는 기능이 있다.
그런데 여기서 조회되는 로그는 컨테이너에서 Standard Out (CONSOLE)으로 출력되는 로그만 조회 가능하다.
- 컨테이너는 Foreground로 실행되므로 표준출력파일은 별도로 지정할 수 없고 CLI 또는 Web Console에서 조회 가능하다.
- 일반 File 로그는 기존과 동일하게 사용가능하다.
- 컨테이너가 삭제되어도 로그파일을 보존하기 위해서 로그 디렉토리를 PV (Permanent Volume)로 연결하여 저장한다.

JBoss에서 Standard Out (CONSOLE)으로 로그를 출력하도록 설정하는 방법
어플리케이션의 로그를 Web UI에서 바로 조회하려면 로그를 Standard Out으로 출력되도록 설정을 하여야 한다.

File로 출력하도록 설정하는 방법

PV 연결

Icon

PV 명 : pv-log (외부 NFS 저장소와 연결 )
PVC 명: pvc-log (Pod에서 사용하는 PV 연결정보)

PV정보

PVC정보

아래 예시 처럼 컨테이너의 특정 디렉토리(mountPath)를 Persistent Volume으로 마운트하면,
/opt/eap/standalone/log 저장되는 파일은 Pod 삭제시 지워지지 않고 보관할 수 있다.
Pod 마운트 정보

3. 컨테이너 테스트

Openshift 가 구축되어 있지 않은 경우 우선 Docker를 이용하여 간단하게 컨테이너 기동 부분만 테스트할 수 있다.

다만 여기서는 문제가 없더라도 나중에 Openshift에 올렸을 경우 추가적으로 권한 문제는 발생할 수 있다.

주요 테스트 절차 (Tomcat7 인경우 예시)

순서	구분	설명	비고
1	이미지 준비	테스트 환경에 Docker Image 다운로드하여 준비한다.
2	어플리케이션	테스트 어플리케이션 및 필요한 설정파일 준비	simple.war, server.xml
3	Dockerfile 작성	Tomcat 이미지의 디렉토리에 simple.war와 server.xml 복사
4	어플리케이션 이미지 생성	위에서 만들어진 Dockerfile을 이용하여 이미지 생성
5	컨테이너 실행	생성된 app-simple 이미지를 컨테이너로 기동
6	어플리케이션 호출	웹브라우저 또는 curl을 이용하여 호출 테스트

9. Migration Guide To Container