왜 컨테이너인가? - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려사항

Why? Container?
OpenShift 구축 사례와 컨테이너 환경으로 전환 시 고려사항 2018. 05
락플레이스
PS본부

q CONTAINER란?
q 도커(Docker)란?
q Red Hat OpenShift Container
Platform 개요
q OpenShift 위치?
q OpenShift Architecture
q Why? OpenShift Container Platform?
q OpenShift 도입효과
q Container환경으로 전환시 고려사항
q Container환경으로 전환 방안(WAS)
Contents
q OpenShift 서비스 구현방안
§ OpenShift 기본 활용
§ 다양한 APP 아키텍처 구조
§ 서비스 마이그레이션
q 구축사례

Opensource & Cloud Best Partner
Copyright ⓒ All right Reserved by 2019 Rockplace Inc.3
호스트 OS상에 논리적인 구획(컨테이너)를 만들고, 애플리케이션을 작동시키기 위해 필요한 라이브러리나 애플리케이
션을 하나로 모아, 별도의 서버 처럼 사용할 수 있게 만든 것. 호스트 OS의 자원을 논리적으로 분리시키고, 여러 개의 컨
테이너가 공유하여 사용
CONTAINER란?
• 가상머신(VM) 대비 효율적인 환경을 제공
ü 운영체제 수준의 가상화를 실시(VM은 하드웨어 스택을 가상
화)
ü 다수의 컨테이너를 OS커널에서 직접 구동
ü 가볍고 운영체제 커널을 공유
ü 시작이 빠르고, 운영체제 전체 부팅보다 메모리를 적게 사용
ü 환경 변경에 따른 이식성(Portability) 향상
v Container 이미지: Layer 형태의 컨테이너 이미지 배포를 통해 리소스 절약 및 무중단 패치가 가능
v Container의 장점: Faster deployment, Less overhead, Easier migration, Faster restart

o Docker는 2013년 세상에 첫 선을 보였으며, Go 언어로 개발된 오픈소스 프로젝트
o Docker는 컨테이너 기반 오픈소스 가상화 플랫폼
o 표준화된 이미지 포멧의 이유로 컨테이너 기술의 표준이 되었으나, Docker 재단의 Enterprise출시로 인해 오픈소스로
의 사용이 불가 (podman: Linux에서 컨테이너를 사용할 때 쓰이는 오픈소스, : daemon이 없는 컨테이너 엔진)
도커(Docker)란?
v Docker 컨테이너의 장점
• LXC는 VM의 경량화에 초점을 뒀지만 Docker는 최종 어플리케이션의 실행에 중점
• OS가 실행되지 않고 어플리케이션만 실행되므로 불필요한 리소스 낭비가 없음
• 간단한 스크립트 형태의 Dockerfile만 작성하면 컨테이너 이미지 생성을 쉽게 할 수 있음
• 재사용이 가능한 Layer 방식의 파일시스템 사용으로 이미지 저장공간 절약
• DockerHub를 통하여 대부분의 SW 커뮤니티 및 벤더들이 이미지를 제공하고 있음
Docker VS 가상머신
Container는 OS가상화 VM은 H/W 가상화

Red Hat OpenShift Container Platform은 컨테이너 기반 소프트웨어의 디플로이 및 관리를 위한 레드햇의 제품입
니다. 구체적으로 말해, 가속화된 애플리케이션 개발을 위해 도커 컨테이너와 데브옵스 도구를 사용하는 쿠버
네티스의 지원 배포판이라 할 수 있습니다.
Red Hat OpenShift Container Platform 개요

Red Hat OpenShift 플랜
자세한 정보: https://www.OpenShift.com/products/pricing/?extIdCarryOver=true&sc_cid=701600000006NHXAA2

Red Hat OpenShift Container Platform 개요 - 표준 기술 기반
세계 컨테이너 기술의 표준 (OCI 선정)
Docker와 완벽한 호환성
격리 기술을 통한 가장 높은 보안성제공
구글에서 개발되고 사용하고 있는
Orchestration 기술인 “Kubernetes”
구글과 협력하여 지속적인 발전 중(#2 프로젝트
기여)
실제 환경에서 가장 많은 Container를 Handling
하며 기 안정됨
“글로벌 Best 컨데이터 기술” “업계 최고의 컨테이너 관리 기술”

OpenShift 위치?
출처: https://www.redhat.com/ko/topics/cloud-computing/what-is-paas
• OpenShift는 Container기반의
Platform을 제공하는 PaaS
• 설치 가능한 환경
ü Amazon Web Services(AWS)
ü Microsoft Azure
ü Google Cloud Platform (GCP)
ü VMware vSphere
ü Bare metal
ü Red Hat OpenStack Platform

OpenShift Architecture
Red Hat OpenShift Container Platform의 구성요소인 Docker 서비스는 Linux 기반의 경량 컨테이너 이미지 패키징 및 생성을
위한 추상화를 제공하며 Kubernetes는 클러스터 관리를 제공하고 여러 호스트에서 컨테이너를 조정함

Why? OpenShift Container Platform? #1
Open source project Product
Subscription에 RHEL, CloudForms,
JBoss Web Server 및 Red Hat SSO가 포함
(응용 프로그램을 신속하게 개발할 수 있도
록 필요한 구성 요소와 해당 응용 프로그램
을 확장 할 수있는 플랫폼을 고객에게 제공)
Subscription구매가 필요 하지만, 기술지원을
받을 수 있다.
(보안 패치, 버그 수정 및 개선)
무료로 사용이 가능하지만, Community또는
외부 전문가의 도움을 많기 어려움
(보안 패치, 버그수정을 받기 위해 새로운
release를 기다려야 함)
1년에 4번 releases
Red Hat Enterprise Linux(RHEL),Red Hat CoreOS
만 지원
RHEL 또는 CentOS
Debian, Ubuntu (mo
st popular ones) an
d many others

Copyright ⓒ All right Reserved by 2017 Rockplace Inc.
OpenSource PLACE, ROCKPLACE
컨테이너 사용에 따른 편의성 향상
개발서버
환경변수, Locale, Charset
app.war
Jboss Engine
JDK
OS Library
운영서버1 운영서버2
APP 이미지
Why? OpenShift Container Platform? #2
APP
Container
APP 이미지개발
APP 이미지
APP Container APP Container
어플리케이션 전체가 포함된 이미지
생성
인프라
인프라관리에 집중가능

# 기존 어플리케이션의 마이그레이션, 신규 구축 및 트러블 슈팅에 대한 기술지원 필요
# 개발 및 테스트로 일부 사용하였으나 기술지원 문제 발생
# 직접설치 : 향후 패치, 업그레이드 등 문제 해결을 위한 지원 필요
# 망분리로 인해 외부와 단절된 환경에서 구축 필요
Why? OpenShift Container Platform - 고객사례 (XX생명)
# Prometheus & Grafana, EFK(Elastic + Fluented + Kibana)
# Docker & Kubernates기반, 로깅(EFK)/모니터링(Grafana & Prometheus)/관리자 UI포함
# Production 레벨에서 사용 가능
# 구축 경험이 있는 파트너를 통한 기술지원 가능
출처: 20190618_컨테이너플랫폼구축_사례공유.pptx(Container Platform for Agile Transformation)

# H/W구매절차 및 S/W 구성 시간 절감
# 신속한 애플리케이션 배포 및 다양한 테스트 환경 제공 가능
# H/W 및 S/W 구매 비용 절감
OpenShift 도입효과 - 고객사례 (XX생명)
# CPU 1/100 수준으로 감소, Disk 1/10 수준으로 감소
# OS 수량의 감소로 유지 및 관리 용이
# S/W 설치 등 일부 자동화로 시스템 구축 용이
출처: 20190618_컨테이너플랫폼구축_사례공유.pptx(Container Platform for Agile Transformation)

Container환경으로 전환시 고려사항 - #1
√ 현재 기업내 서버들이 Linux 환경으로 운영 중인가?
√ Container환경에 필요한 표준화 작업은 되어 있는가?
√ Container환경으로 전환하기 위한 회사 조직내부의 준비는 되어 있는가?
OpenShift에서 지원하는 Container Image는 Linux기반이므로 Unix및 Windows
환경은 Linux환경으로 먼저 전환해야 함
Container Image와 관련된 표준화 및 운영표준화 수립이 필요
DevOps 기반으로 회사조직이 구성되어야 Container환경으로 쉽게 전환/운영 할
수 있는 장점이 있음.

구분 내용 비고
컨테이너화 대상선정 시스템의 여러 구성요소 중에서 컨테이너로 옮길 부분을 검토 •Windows 전용 시스템은 리눅스로 우선 변경 후 컨테이너화 필요
•무거운 레거시 형태 WAS는 가벼운 오픈소스 WAS로 우선 변경 필요
•DB는 아직 Recommand 하지 않으나 성능에 Critical하지 않은 경우만 사
용가능
•독립 배포되는 war 별로 컨테이너로 구성
•세션 클러스터링이 필요없는 어플리케이션이 확장 시 더 효율적
Base 이미지선택 WAS로 사용할 수 있는 Official 이미지가 있는지 확인 •WAS 벤더에서 제공하는 이미지가 있으면 우선적으로 사용
•컨테이너화에 문제가 없는 경우에 한해 이미지 작성가능
•WAS가 변경되는 경우, 해당 WAS에 맞게 마이그레이션 테스트가 먼저
진행되어야 함
WEB/WAS 연동 아키텍처 WAS의 IP가 고정될 수 없고 Scale Out을 고려해야 하므로 Web서버에서 W
AS IP 지정방식의 연동방법은 사용할 수 없음
•OpenShift의 장점은 동적 확장인데 기존의 WEB/WAS 연동 구조에서는
동적 확장이 어려우므로 WEB은 제외하고 WAS로만 서비스하는 Simple한
아키텍처 구성이 효율적
내부 인터페이스 주소 OpenShift 내부에 인터페이스 해야할 API서버 등이 있는 경우 대상 IP가 동
적으로 생성되므로 연동방법 확인필요
•OpenShift의 Service 명 또는 환경변수 이용
Session Clustering IP가 임의로 변경되므로 IP 지정방식에 의한 세션클러스터링은 사용할 수
없음
•기본적으로 어플리케이션의 상태를 저장하기, Session 메모리 등 내부 리
소스를 사용하는 것은 컨테이너 확장 측면에 적합하지 않음.
•OpenShift 에서는 확장이 쉬운 Micro Service Architecture (MSA) 에 최
적화 되어 있음
•세션클러스터링은 확장시 오버헤드가 증가하므로 기본적으로는 권장하
지 않음
•동적 클러스터링 방식은 구성가능(Multicast 를 이용한 방식 등)
•세션클러스터링 방식은 WAS마다 다르므로 벤더에 확인필요 ( JBoss EAP
는 사용가능)

구분 내용 비고
애플리케이션 설정 값 시스템에서 변경이 필요한 값은 이미지에 넣지 않고 별도 관리
(환경 변수 또는 git 서버에 파일로 관리)
•변경이 필요한 설정값이 어떤 것이 있는지 대상확인
•변경값 적용 방식 확인 (어플리케이션 설정 값 및 JAVA Option은
환경변수 이용 등)
애플리케이션 소스 소스에서 Hostname이나 IP 주소에 기반한 로직이 있으면 수정필
요
•Localhost 또는 환경변수로 주입받는 방식으로 변경 가능
보안 어플리케이션 로직에서 아래의 경우 보안상 취약할 수 있으므로
수정 필요
•root 유저를 사용하는 사용하는 경우
•ssh client를 사용하는 경우
•컨테이너를 벗어나서 Host의 Network 또는 Resource에 접근하
려는 경우
설정으로 허용 가능하나 보안상 취약
3rd Party Library •어플리케이션에서 License가 필요한 3rd Party Library를 사용하
는데 License 확인 방법이 IP 또는 Hostname을 기반으로 할 경우
이에 대한 변경 필요
•C로 작성된 so파일형태의 Library는 해당 Image에서 실행 가능한
Binary로 변경 필요
•해당 벤더에 확인 필요
대용량 컨텐츠 어플리케이션에서 사용하는 대용량 컨텐츠가 있는 경우 이미지를
복사하거나 Build 할때 느려지므로 공유볼륨 사용에 대한 확인 필
요
•NFS를 통해 공유볼륨을 구성
•공유볼륨을 PV(Permanent Volume)로 컨테이너에 마운트하여 사
용
•NFS는 Network을 사용하므로 성능상 허용 가능한지 테스트 필요
Logging Standard Out 으로 출력되는 로그는 오픈시프트 콘솔에서 확인가
능
•파일로 저장이 필요한 로그는 기존과 동일하게 파일로 출력
•로그가 저장되는 디렉토리는 NFS등을 이용하여 Permanent Volum
e으로 연결
Batch 형태 어플리케이션 클러스터링이 고려되지 않은 Batch 형태의 어플리케이션은 Pod를
확장했을때 여러 번 실행될 가능성이 있으므로 다른 어플리케이
션과 분리해서 배포해야한다.
•WAS에서 구현된 Batch 어플리케이션은 별도 Pod로 구분하여 배
포한다.
•Crontab 관련 부분은 OpenShift의 Cron Job으로 대체한다.

Container환경으로 전환시 고려사항 (표준화 방안) - #1
√ Container Image 표준화
q Image 선정 및 작성 기준
• Image Naming Rule (rp/image-name:tag, 예) rp/rhel76:1.0, rp/rhel76-jdk8:1.0)
q Image 목록(Base이미지, App이미지)
• 이미지명, 구분(WEB/WAS), 버전, Tags, Dockerfile위치(Git) 등을 정의
q Image 생성 가이드 라인
• Image재사용, Tag활용, Dockerfile 작성시 수행순서 등…
q Image 보안검사 방안(Red Hat Quay, Atomic/openscap 활용 방안 등…)
q Image 생성 절차
√ Image 업데이트 기준 및 절차
√ Container 사용 Resource 제한 정책
√ Image사용을 위한 가이드 표준화

Container환경으로 전환시 고려사항 (표준화 방안) - #2
√ Project / 사용자 관리
√ 애플리케이션 생성 및 배포 관리
√ 장애관리
√ 버젼 관리
√ 관제/모니터링 관리
√ Image Repository 관리
장애발생 유형 및 해결방안 정의
User, PV, DNS등록, Git사용설정, Build정의, Deployment정의, 템플릿 생성,
애플리케이션 생성등에 대한 정의
모니터링 대상 정의, 로그관리(로그레벨) 및 모니터링(CPU, Memory) 방안 등…

Migration
Requirement & Analysis
Preparation Migration
Go Live
/ Optimization
시스템 범위 & 요건 정의
어플리케이션 및 아키텍처 분석
솔루션 현황/ 호환성 분석
사전 검증 테스트
이행 계획 수립
WAS 이미지 및 Build 정책수립
App 컨테이너
마이그레이션 가이드
WAS 이미지 및 Build 구성
Application Build
및 배포
테스트(단위/통합/성능)
시스템 투입 검증
이행
최적화
WAS 종류 및 버전 변경 시: WAS 마이그레이션은 경우에 따라 소스 변경사항이 생길 수 있으므로 해당 WAS엔지니어와 개발팀에서 별도로 진행해야 합니다.
WAS 종류 및 버전 변경 시 WAS
마이그레이션
Container환경으로 전환 방안 - 주요절차
락플레이스 락플레이스 / 내부 담당 직원 / 솔루션 유지보수 업체

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

Container환경으로 전환 방안(WAS) - #2
OpenShift에서 적용 가능한 구조 비고
Web서버의 Static contents를 WAS로 통합 심플한 구조로 가장 많이 사용되며 클라우드 환경에
서 효율적인 구조
Web서버를 별도로 구성하는 경우 Web서버가 별도의 URL을 사용하므로 리소스 위치
관련된 소스 수정필요
WEB,WAS를 하나의 POD로 구성 별도의 템플릿 필요하며 Pod가 복잡성이 증가하므로
관리포인트 증가됨

Red Hat OpenShift Platform
서비스 구현 방안

• 기본 Base 이미지에 Application을 추가하여 실제 작동 가능한 이미지를 생성
Base Image
OS Libs
JDK
WAS Engine
Application Image
OS Libs
JDK
WAS Engine
Application
어플리케이션
이미지 생성
Git
Red Hat OpenShift Container Platform(OCP) 에서 이미지를 만드는 방식
OpenShift 기본 활용

어플리케이션 생성
사용할 이미지와 소스가 있는 Git 서버의 주소를 입력하면 어플리케이션 자동 빌드 및 배포
1) 이미지 선택
2) Git 주소 입력 3) 어플리케이션 생성완료

어플리케이션 구성 아키텍처
Route
web.rockplace.co.kr
Service
172.30.176.102
RC
ReplicationController
DC
DeploymentConfig
Pod
개별 내부 IP
몇 개의 Pod를 만들지…
어떻게 Pod를 배포 할지…
지정된 개수의 Pod가
잘 돌고 있는지…
Container는 Pod에 담겨...
Cluster IP (VIP)를 통한
Load Balancing
외부로부터의 진입점
(Domain과 내부 Service를 연결)
Project
Application

OpenShift Resource 구조
User Application
Route
Service
Pod
Deployment
Config
BuildConfig
접속 주체 별로 User생성
Project
Project 별 Resource 제한 가능
(CPU, Memory 포함)
Application 그룹 또는
Resource 제한단위
User 단위로 접속
User별 권한부여
개별 Application

S2I Build
1. APP Download
2. Image Builder 다운로드
3. Builder Image 실행 (Build 실행)
4. 어플리케이션 Image 생성
5. 생성된 이미지를 Registry에 등록
6. 각 Node로 배포
OpenShift의 Build 수행 시 Git에 저장된 APP를
다운로드하여 이미지 Build 및 Deploy 수행
개발자는 APP를 Git 에 저장
Git 서버에 APP를 Push

Build의 종류
Build Type Build Control 특징
S2I Build 이미지 내부의 s2i scripts • 레드햇의 이미지는 S2I build를 지원한다.
• Git 에서 파일을 다운로드 후 아래의 순서로 동작한다.
1. pom.xml 파일 존재 시 Maven Build
2. .war 또는 jar 파일 배포위치로 복사
3. 이미지 빌드
Docker Build Git의 Dockerfile • S2I 기능이 Git 서버의 Dockerfile에 있고 사용자가 Dockerfile을 정
의해야 한다.
• S2I 이미지를 별도로 만들지 않고 사용할 때 이 방식을 사용한다.
• 사용자 정의 방식이므로 다양한 케이스에서 사용 가능하다.
Pipeline Build Git의 Jenkinsfile • S2I 기능이 Git 서버의 Jenkinsfile에 있고 사용자가 Jenkinsfile을 정
의한다.
• Jenkins가 연동되어 있어야 한다.
Build의 목적은 어플리케이션 소스를 이미지에 포함시키는 것이다.

Build / 배포 / Auto Healing
OpenShift Node
Tomcat8:build1
1) 소스 업로드
Git
Tomcat8 Base
2) Image Build
APP 이미지
소스 복사
OpenShift Node1
Tomcat8:build1
APP
Pod1
APP
Pod2
Build
배포
OpenShift Node2
Tomcat8:build1
APP
Pod3
APP
Pod4
Nexus
3) 배포

Rollback
OpenShift Master
이미지 배포내역
최신 이미지
OpenShift Node1
Tomcat7:build1
APP
Pod1
APP
Pod2
OpenShift Node2
Tomcat7:build1
APP
Pod3
APP
Pod4
Tomcat7:build1
Tomcat7:build2
Tomcat7:build3
Tomcat7:build3
APP
Pod1
APP
Pod2
Tomcat7:build3
APP
Pod3
APP
Pod4
Rollback Rollback
2) 현재 배포중인 build3 삭제1) Build1 배포 1) Build1 배포

Rollback
배포 내역

Auto-Scaling
• 지정된 CPU 사용률에 따라 Pod의 개수가 자동으로 증가 또는 감소

이미지
OpenShift Supported Images
Red Hat xPaaS Middleware Images
Red Hat Container Catalog

이미지
OpenShift Supported Images
OCP supported S2I (Perl, NodeJS, PHP, Pthon, Ruby), databases (MySQL, Postgres, MongoDB 등), Jenkins, .NET Core
이미지는 OCP에서 자유롭게 사용 가능
Red Hat xPaaS Middleware Images
Jboss EAP, JDG, Fuse, BPMS, BRMS 등 (사용시 별도 Subscription 필요)
그 밖의 이미지
Weblogic / Websphere / Jeus 등 특정 벤더의 이미지는 해당 벤더에서 제공하는 이미지를 사용

CI / CD
Pipeline Build
Pipeline Build가 호출되면 OpenShift와 연동되어 있는 Jenkins에서 Pipeline Job이 실행된다. 이 Pipeline Job Script에는
소스 Build, 테스트, 배포 등 필요한 내용이 미리 정의되어 있다. (개발자가 내부 환경에 맞게 Script 파일 생성 필요)
Jenkins 에서
Pipeline Script 실행

APP 아키텍처 구조
§ Scale-Out이 가능한 가장 Simple한 구조
§ DB는 OpenShift 외부에 구성
Route
Frontend Only
Service
Frontend Pod Frontend Pod DB
다양한 APP 아키텍처 구조

Route
Frontend + API
Service API Service
API Pod API PodFrontend Pod Frontend Pod
api-service
시스템내부연계
Frontend Pod에서 API Service를 호출할 경우 API Pod의 IP 대신 변하지 않는 Service Name을 이용
하여 http://api-service:8080/ 로 접근 가능합니다.
시스템외부연계
외부의 요청을 내부의 API Service로 연결할 수 있도록 별도의 Route를 추가하여 사용합니다.
시스템내부연계:
http://api-service:8080/api
API Route
시스템외부연계:
http://api.ocp.ing.co.kr/api

여러가지 APP 아키텍처 구조
Route
SSO + Frontend
Service Service
Frontend Pod Frontend PodSSO Pod
§ SSO와 함께 연동되는 Frontend서버로 구성되어 있으며 모두 Scale-Out이 가능한 구조
§ Frontend 는 SSO를 통해서 접근해야 하기 때문에 Route는 필요 없다.
통합 SSO
Server

§ Frontend, API서버, Image File 서버로 구성되어 있으며 모두 Scale-Out이 가능한 구조
§ API는 내/외부에서 모두 접근 가능하게 하기 위해 Route를 추가로 구성
§ WAS이외에 별도의 Image 서버를 구성할 경우 위와 같이 구성
Route
Frontend + 내외부 API + Image Server
Service Service
API
Pod
API
Pod
Frontend
Pod
Frontend
Pod
Route
Service
Image
Pod
Image
Pod
Route
서비스 마이그레이션

OpenShift의 주요 특징
Route
Service
WAS Pod WAS Pod
10.10.10.1 10.10.10.2
§ Pod 생성시 내부 IP가 동적으로 할당
§ Pod 재생성시 컨테이너 내부 데이터는 최초 이미지와 동일하게 초
기화
§ 이미지의 내용은 변경 불가 (변경이 필요하면 Rebuild)

주요 고려사항
§ 적용 가능한 아키텍처 인가?
§ Application의 컨테이너화가 가능한가?
§ 이미지 빌드 구성이 가능한가?
§ 내/외부 시스템 연계가 있는 경우 문제가 없는가?
Route
OpenShift
Service
WAS Pod WAS Pod
Legacy
Web + Proxy
WAS WAS

주요 전환 포인트
아키텍처
구성
§ LB용 웹서버 -> OpenShift에서 Service 로 대체
§ SSL -> OpenShift의 Route에서 처리
§ 공유 NFS -> OpenShift PV / PVC 사용
§ WAS 세션 클러스터링 -> 벤더에서 확인 필요
§ APM -> 벤더에서 확인 필요
Route
Service
WAS Pod WAS Pod NFS
/opt/jboss/logs /nfs/jboss/logs

어플리케이션
§ 사용중인 솔루션의 라이센스 문제가 없는지 확인필요
§ JNI, SSO등의 별도의 모듈이 있는 경우 WAS 이미지에서 실행 가능한지 사전 확인필요
§ DEV, UAT, PROD 별로 달라지는 설정내용은 System Property 또는 환경변수를 이용하여 처리
<connection-url>jdbc:mysql://
${env.DATABASE_SERVICE_HOST}:
${env.DATABASE_SERVICE_PORT}
/${env.MYSQL_DATABASE}</connection-url>

WAS 이미지 및
Build 구성(CI/CD)
§ 상용 WAS의 이미지는 벤더에서 제공하는 공식 이미지를 사용해야 함 (기존 WAS 버전과 동일 버전)
§ Base 이미지와 APP 소스를 합치는 Build 구성 ( S2I 또는 Docker Build 선택)
§ Build 시 소스 연동은 Git 서버 사용
§ Image 및 Build 방식 표준화
Application Image
OS Libs
JDK
WAS Engine
Application Git
변경항목에 어떤 것이 있는지?
• Application
• server.xml
• lib 파일
• JNI 파일
• ?

내/외부 연계
§ 내부 연계 시 Endpoint URL은 Service 명 또는 환경변수를 이용하여 지정
§ 기본 생성된 Route 이외에 외부에서 Node 내부로 들어오는 별도의 Endpoint가 필요한 경우는 추가
Route 또는 External IP를 이용 가능
Route
Service Service
API Pod API PodWAS Pod WAS Pod
api-service
시스템내부연계:
http://api-service:8080/api
Route
시스템외부연계:
http://api.ocp.ing.co.kr/api

Red Hat OpenShift Platform
구축 사례

OpenShift 구축 사례
구축 사례
XX 중공업 클라우드 구축 및 아키텍처
관리자
물리 인프라(x86 표준 하드웨어)
Platform 서비스
API
API
Private Cloud 서비스
Legacy infra
…
컴퓨트 이미지 스토리지 대시보드 네트워킹 인증 오케스트레이션배포관리
소프트웨어 정의 스토리지
향후 연동 예정
API
Public Cloud 서비스 Google Cloud Platform
Application 서비스
개발자 & 운영자를 위한 Devops 환경
Scale-out 아키텍처
OpenShift
고도화
Dev Source
Registry
CI/CD
Engine
Container Cloud
Physical
Virtual
Deploy

구축 사례
x86 Server(Physical Server)
컨테이너 Pod
로드밸런서 가상머신ü 가상화 환경으로 Node 구성
ü Master Node : ETCD 를 구성하고 L4 스위치를 통한 Web Console 접근 구성
ü Infra Node : 안정성 및 성능 보장을 위한 인프라 서비스 Node 분리 구성
ü App Node : Node 추가 증설이 용이한 환경 구성
DNS
BASTION HOST
Master Load
Balancer
Router Load
Balancer
INFRASTRUCTURE
NODES (x4)
Router Router
METRICS
NODES (x3)
Metrics Metrics Metrics
MASTER
NODES (x3)
Registry Registry Registry
LOGGING
NODES (x2)
EFK
Stack
APPLICATION
NODES (x2)
App1 App2● ● ●
Storage
스토리지
Public Network Private Network
Router Router
EFK
Stack
Hypervisor
OO생명보험 OpenShift구축 아키텍처

고객사 사업년도 솔루션 사용 이미지 비고
A 생명보험사 2018년 Red Hat OpenShift Container Platform
SSO 솔루션
Tomcat
Wildfly9
Red Hat JBoss EAP7
기존 SCM과 연동
B 제조사 2018년 Red Hat OpenShift Container Platform Spring-Boot (Embedded
Tomcat)
C 중공업 2018년
Red Hat OpenStack
Red Hat OpenShift Container Platform
Red Hat Cloud Forms
Red Hat Ceph Storage
Red Hat JBoss EAP
Tomcat
ThingWorks
행정안전부 대테러센터 2017년 Red Hat OpenShift Container Platform Red Hat JBoss EAP7
국민재난안전포털 2017년 Red Hat OpenShift Container Platform Red Hat JBoss EAP7
정부통합전산센터(NCIS) G-Cloud
자동확장체계
2017년 Red Hat OpenShift Container Platform Red Hat JBoss EAP7
행정안전부 온나라시스템 (고도화) 2015년 Red Hat OpenShift Enterprise Red Hat JBoss EAP6
구축 사례

락플레이스는 ?
락플레이스는
오픈소스 + 클라우드 전문 기업 입니다.
대한민국 리눅스의 역사와 성장을 함께 해온 락플레이스는 오픈소스 전
문 기업으로 국내 최다 엔지니어, 국내 최고 기술력, 국내외 우
수기업 컨설팅 경험으로 고객의 성공적인 오픈소스 플랫폼
구축을 위하여 응용 프로그램 전체 범위의 서비스를 제공 하
고 있습니다.
최고의 솔루션과 서비스를 보유한 락플레이스는 고객 중심의 기술지원
서비스를 통해 비즈니스 가치 창출에 기여하는 고객의 신뢰 동반자입
니다. 다양한 프로젝트 수행 경험을 보유한 락플레이스는 열정, 전문성,
커뮤니케이션을 바탕으로 고객에게 훌륭한 조언자가 되고, 개척자가 되
는 것을 두려워 않는 고객의 혁신 동반자입니다. 락플레이스는 최고
의 오픈소스 서비스로 오픈소스를 통한 극한의 즐거움을 선사하겠
습니다.
2005년 설립 이후 오픈소스
역사와 함께 성장
15Y
오픈소스 서비스 경험
클라우드 Service , OS,
Virtualization, WAS, DB
오픈소스 전문 엔지니어
70명
전문 엔지니어 구성
Migration/Consulting/Maintenance
전방위적 오픈소스 소프트웨어
활용고객 서비스 제공
500 회
고객 Reference
OS, DB등 9가지의 솔루션 스택
그룹에 35개 제품 기술지원
체계 및 파트너쉽 보유
9and35
다양한 제품 기술지원
•창립일 : 2005년 11월
•회사명 : 락플레이스
•대표이사 : 서동식
•본사 : 서울시 강남구 언주로 844(신사동 윤당빌딩 3층, 7
층)
•서비스 : Open Source Consulting, Migration,
Implementation & Maintenance, Public Cloud, Big Data
Solution
•대표번호 : 02-6251-7788

왜 컨테이너인가? - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려사항

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 왜 컨테이너인가? - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려사항

Similar to 왜 컨테이너인가? - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려사항 (20)

More from rockplace

More from rockplace (20)

왜 컨테이너인가? - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려사항