Docker & OpenShift 3 락플레이스 미들웨어기술본부 양희선

Contents 어플리케이션생성 Openshift 리소스 구조 Docker Image 및 Container 개요 배포 및 롤백 서비스 확장( 오토스케일링)

1. Docker Image 및 Container 개요

Docker Image App code, runtime, system tools, system libraries 실행에 필요한 모든 것을 포함하여 Docker Format의 파일로 생성 App code, runtime, system tools, system libraries Image Container Container Container Docker Build Docker Run Docker에는 이미지라는 개념이 있습니다. Docker는 소프트웨어 실행에 필요한 모든 파일 Code, Runtime실행파일, System Tool, System Library 등을 포함하여 하나의 파일로 만듭니다. 이것이 이미지 입니다. Apache의 경우 컴파일된 바이너리파일과 OS의 APR Library 파일, 그리고 Openssl 파일 등을 포함하여 이미지를 만들고, Tomcat의 경우 Tomcat 바이너리 파일과 JRE를 포함하여 이미지를 만들면 됩니다. Docker에서 이 이미지를 프로세스로 실행한 상태가 Container입니다. 이를 통해서 하나의 호스트 내부에 독립된 VM 같은 실행환경인 컨테이너를 만들수가 있습니다. 컨테이너는 기본적으로 172로 시작하는 내부 IP를 할당 받고 포트도 독립적으로 사용할 수 있습니다.

Dockerfile을 이용하여 HTTPD 이미지 생성 [root@master ~]# cat Dockerfile FROM docker.io/centos USER root RUN yum clean all \ && yum repolist \ && yum -y install httpd \ && yum clean all EXPOSE 80 CMD ["/usr/sbin/apachectl","-k","start","-D","FOREGROUND"] [root@master ~]# docker build -t myhttpd . 베이스 이미지 RPM 을 이용하여 HTTPD설치 사용할 포트 실행할 파일 이미지 생성

Image Push & Download 생성된 이미지를 Image Registry 에 Push한다. Openshift의 ImageStream에는 이미지의 위치가 저장되어 있으며 필요 시 Image Registry로부터 이미지를 받아갈 수 있다. Docker Image Registry User Docker Image Push myhttpd:2.4 Openshift ImageStream myhttpd:2.4

2. 어플리케이션생성 어플리케이션 생성 어플리케이션 작동구조

Application 생성 등록된 이미지 선택 어플리케이션 명 (고유하게 부여) 등록된 이미지를 이용하여 Openshift에서 어플리케이션을 생성 등록된 이미지 선택 어플리케이션 명 (고유하게 부여)

어플리케이션 작동구조 Openshift web.rockplace.co.kr 172.30.35.131:80 내부DNS HAProxy 52.78.245.72:80 Route (내부 Service 위치 확인) 172.30.35.131:80 Openshift Node web.rockplace.co.kr VIP 172.30.35.131:80 Service (Load Balancing) Apache Container/Pod: 10.0.10.11:80 Apache Container/Pod: 10.0.10.11:80 Pod (Container)

3. Openshift 리소스 구조

Container Management by Openshift Route: web web.rockplace.co.kr 외부로부터의 진입점 service: web 172.30.176.102 Cluster IP (VIP)를 통한 Loadbalancing Image Pod 실제 어플리케이션 Container가 담긴 Pod 지정된 개수의 Pod가 잘 돌고 있는지… ReplicationController DeploymentConfig 몇 개의 Pod를 만들지… 어떻게 Pod를 배포 할지… 이 페이지는 각 컴포넌트별 역할에 대한 관점입니다. 오픈쉬프트 내에서 이미지가 Pod로 만들어 지는데 이것은 내부적으로 DeploymentConfig에 의해서 만들어지는 것입니다. DeploymentConfig 최초 생성시 몇 개의 Pod를 만들지 그리고 어떻게 Rebuild를 할지를 결정하고 레플리케이션Controller 가 지정된 개수 만큼의 Pod가 잘 돌고 있는지를 감시하고 Service는 내부 Pod들에 대한 연결을 담당합니다. 그리고 마지막으로 route는 외부로 부터의 진입점 역할을 합니다. 오픈쉬프트에서는 하나의 이미지로부터 앱을 만들면 이러한 구조가 자동으로 생성이 됩니다.

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

Build, Deployment, Pod 현재 실행중인 Pod 14번째 배포 이미지 사용중 Route Node로 배포된 내역 Service Application Pod Deployment Config 소스 빌드 내역(Master) BuildConfig

4. 배포 및 롤백 Deployment Rollback

Deployment 배포할 Image 배포 방법 Deployment는 이미지를 Node로 배포하여 실행시키는 것을 말한다. Image Stream Tag: myproject/ncis:latest Image가 변경되면 자동으로 배포: yes 설정이 바뀌면 자동으로 배포: yes Strategy Type: Rolling Max Num Unavailable Pods: 25% ( ¼ 씩 Rolling배포) Replicas: 4 (동시에 유지할 Pod 개수)

Rollback Rollback은 기존에 배포됐던 특정 시점으로 어플리케이션을 다시 배포하는 것을 말한다. Openshift는 기존 Deployment 이미지를 그대로 유지하고 있으므로 쉽게 Rollback이 가능하다. 배포 내역

5. 서비스 확장 Manual Scale-Out Resource Limits Auto-Scaler

Manual Scale-out 실행될 Pod의 개수를 화살표로 조정할 수 있다.

Resource Limit 컨테이너가 최대로 사용할 수 있는 CPU와 Memory 를 지정할 수 있다.

Auto-Scaler 지정된 CPU 사용율에 따라 Pod의 개수가 자동으로 증가 또는 감소하게 설정가능하다.

HTTPD Application

감사합니다 midware@rockplace.co.kr