Docker & OpenShift 3 락플레이스 미들웨어기술본부 양희선 안녕하세요. 저는 락플레이스의 양희선이라고 합니다. Deep Dive로 Docker, Kubernetes 그리고 Openshift 구조 및 활용에 관한 내용입니다. 시간은 40분 이내로 마칠 수 있도록 하겠습니다.

Container Linux LXC LibContainer Docker Docker는 오픈쉬프트의 핵심 모듈입니다. Docker는 리눅스에서 yum 명령을 이용해 패키지로 설치될 수 있습니다.

code, runtime, system tools, system libraries Docker Image Image Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries Image Container Container Container Docker에는 이미지라는 개념이 있습니다. Docker는 소프트웨어 실행에 필요한 모든 파일 Code, Runtime실행파일, System Tool, System Library 등을 포함하여 하나의 파일로 만듭니다. 이것이 이미지 입니다. Docker에서 이 이미지를 프로세스로 실행한 상태가 Container입니다. 이를 통해서 하나의 호스트 내부에 독립된 VM 같은 실행환경인 컨테이너를 만들수가 있습니다. 컨테이너는 기본적으로 172로 시작하는 내부 IP를 할당 받고 포트도 독립적으로 사용할 수 있습니다.

Docker Image vs Container An instance of an image is called container 이렇게 이미지는 단지 파일일 뿐이고 도커 프로세스에 의해 이미지가 로딩되어 실행된 것이 바로 컨테이너입니다. 컨테이너는 게스트OS나 하이퍼바이저가 존재하지 않고 Host의 커널과 바로 통신을 합니다.

VM vs Docker Container VM과 컨테이너의 차이를 설명한 그림입니다. 보시는 바와 같이 Container에는 게스트OS와 하이퍼 바이저가 없습니다. 그래서 더 가볍고 빠릅니다.

Docker Hub https://hub.docker.com/explore/ Dockerub.com이라는 사이트가 있습니다. 여기에 가면 이미 웬만한 플랫폼들은 모두 이미지로 만들어져 있습니다.

Docker Hub https://hub.docker.com/explore/ Httpd 이미지를 누르고 들어가면 다음과 같이 상세 페이지가 나옵니다. Docker를 설치하면 docker pull httpd 라는 명령을 통해서 이미지를 가져올 수 있습니다. Dockerfile이라는 것이 있는데 여기에 이미지를 만든 방법이 나와있습니다.

Dockerfile – Hello Openshift https://hub.docker.com/r/openshift/hello-openshift/ [root@master ~]# cat Dockerfile FROM scratch MAINTAINER Jessica Forrester jforrest@redhat.com ADD bin/hello-openshift /hello-openshift EXPOSE 8080 8888 ENTRYPOINT ["/hello-openshift"] 베이스 이미지 만든사람 넣을 파일 사용할 포트 실행할 파일 다음은 이미지를 만드는 Dockerfile에 대한 예시입니다. 이 이미지는 Hello-openshift라는 이미지인데 레드햇에서 만들어 놓은 것입니다. Hello-openshift는 Curl로 호출하면 무조건 “Hello Openshift”라는 문자열을 리턴하는 아주 간단한 웹서버 같은 어플리케이션입니다. golang으로 작성되어 있기 때문에 JDK도 필요없습니다, bin/hello-openshift 라는 파일이 golang으로 컴파일된 실행파일입니다. Static Link로 컴파일되어 있어서 실행에 필요한 파일이 모두 포함되어 컴파일되어 있습니다. 설명을 드리면 From은 베이스 이미지, Scratch 라는 이미지를 기본으로 해서 만들겠다는 것이고 Maintainer는 만든 사람 ADD는 넣을 파일 Expose는 사용할 포트 Entrypoint는 컨테이너 기동시 실행할 파일을 의미합니다. 컨테이너가 실행되면 hello-openshift 라는 파일을 실행합니다. 그리고 이 프로세스가 종료되면 컨테이너도 종료됩니다. Hello-world 라는 이미지가 있는데 이 이미지를 실행하면 몇줄의 문자열을 찍고 바로 종료가 됩니다. 어플리케이션이 그렇게 작동하도록 만들어져 있는 것이죠. Scratch 이미지는 아무것도 들어있지 않은 껍데기 이미지 입니다. 이렇게 이미지를 만들면 10메가 보다 작은 사이즈로 이미지가 생성됩니다.

Dockerfile – Hello Openshift 이미지 생성 [root@hsyangpc hello-openshift]# docker build -t my-hello-openshift . Sending build context to Docker daemon 6.594 MB Step 0 : FROM scratch Step 1 : MAINTAINER Jessica Forrester <jforrest@redhat.com> … Step 4 : ENTRYPOINT /hello-openshift Successfully built ec2eb0e5676f [root@hsyangpc hello-openshift]# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE my-hello-openshift latest ec2eb0e5676f 40 seconds ago 6.517 MB Docker build 명령어의 끝에 보면 . 이 있는데요, 이 명령은 현재 디렉토리에 있는 Dockerfile로 부터 my-hello-openshift 라는 이름의 이미지를 만들라는 뜻입니다. 그리고 Docker images라는 명령어로 현재 가지고 있는 이미지를 조회할 수 있습니다.

Dockerfile – Hello Openshift 실행결과 [root@hsyangpc hello-openshift]# docker run -d my-hello-openshift c2c82f8f8dc6b37e52eb517dd3e294d149443e04860ef0356c186cdd55e7df3f # 현재 실행중인 Container 조회 [root@hsyangpc hello-openshift]# docker ps c2c82f8f8dc6 my-hello-openshift 3 minutes ago Up 3 minutes 8080/tcp, 8888/tcp my-hello-openshift # 컨테이너 IP 정보조회 [root@hsyangpc hello-openshift]# docker inspect my-hello-openshift ... "IPAddress": "172.17.0.4",... "8080/tcp": null, "8888/tcp": null [root@hsyangpc hello-openshift]# curl -v 172.17.0.4:8080 Hello OpenShift!

Hello-world [root@hsyangpc hello-world]# docker run my-hello-world Hello from Docker. This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. ..... For more examples and ideas, visit: https://docs.docker.com/engine/userguide/ [root@hsyangpc hello-world]#

Dockerfile – Apache Webserver [root@master ~]# cat Dockerfile FROM docker.io/centos USER root RUN yum -y install tar unzip vi vim telnet … COPY files/jboss-ews-httpd-2.1.0.zip /tmp/ RUN cd /opt; unzip /tmp/jboss-ews-httpd-2.1.0.zip WORKDIR /opt/jboss-ews-2.1/httpd RUN ./.postinstall EXPOSE 80 CMD ["/opt/jboss-ews-2.1/httpd/sbin/apachectl","-k","start","-D","FOREGROUND"] 이 도커파일은 아파치 웹서버용으로 제가 만들어본 파일입니다. Ews21은 아파치2.2를 레드햇에서 다시 패키징한 제품입니다. APR 같은 모듈은 OS의 파일을 사용하도록 Dynamic Link로 컴파일되어 있습니다. 따라서 실행을 위해서는 OS의 일부 라이브러리 파일들이 필요합니다. 이런 목적으로 OS의 기본 파일들이 들어있는 이미지도 종류별로 만들어져 있습니다. 여기서는 Centos 이미지를 가져와서 Yum 패키지 관리자로 tar, unzip 등 유틸리티 패키지를 추가하고 httpd 설치파일을 복사하고 사용포트 80을 지정하고 실행명령을 지정합니다. 운영환경에서는 일반유저를 사용하여 실행하는 것이 보안상 좋습니다. 이렇게 도커파일을 정의하고 빌드하면 centos에 아파치가 설치된 이미지가 생성이 됩니다.

Docker Build [root@master ~]# docker build -t ews21 . … [root@master ~]# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE ews21 latest 47bd98336d1d 3 days ago 443.1 MB docker.io/centos 6.6 12c9d795d85a 6 months ago 202.6 MB [root@master ~]# docker run -d --privileged -p 80:80 -h web1 ews21 도커 이미지를 빌드하고 실행한 예시입니다. 보시는 바와 같이 도커파일에서 베이스 이미지로 지정한 centos와 최종 ews21이라는 이미지가 별도로 생성되어 있습니다. 다른 이미지를 하나 만들 때 베이스 이미지를 centos6.6으로 지정하면 이미 받아놓은 이미지를 그대로 재사용합니다. 그리고 docker run이라는 명령어로 컨테이너를 기동합니다. 컨테이너는 내부 IP를 할당받습니다. -p 는 호스트로 들어오는 80 포트 트래픽을 컨테이너의 80 포트로 보내라는 것이고 -h는 컨테이너의 호스트명을 web1로 하겠다라는 것입니다.

Apache Webserver 컨테이너 접속 # 실행중인 컨테이너 조회 [root@master ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d1e70a6efdac ews21 "/opt/jboss-ews-2.1/httpd/sbin/apachectl" 16 minutes ago Up 16 minutes 80/tcp tender_albattani # 컨테이너 내부로 접속 [root@master ~]# docker exec -ti d1e70a6efdac /bin/bash [root@tender_albattani~]#

S2I Builder GitLab Builder Image Image Source 다운로드 추가되는 파일 /usr/local/s2i/ assemble run … Builder Image Image 생성 Tool 다운로드: https://github.com/openshift/source-to-image/releases https://blog.openshift.com/create-s2i-builder-image/ # s2i create eap64-builder eap64-builder # s2i build test/test-app/ eap64-builder eap64-app1

Guideline for Building Image https://docs.openshift.com/container-platform/3.3/creating_images/guidelines.html#openshift-container-platform-specific-guidelines Reuse Images Maintain Compatibility Within Tags Avoid Multiple Processes Clean Temporary Files Minimize the number of layers Support Arbitrary User IDs

OpenShift 지금까지 오픈쉬프트가 어떤 목적으로 사용되는지와 개념적인 구성에 대한 내용을 알아봤습니다. 다음은 오픈쉬프트에 대한 좀더 자세한 내용입니다. Docker 이미지와 컨테이너 그리고 이것들을 오픈쉬프트 작동방식에 대한 내용을 다루었습니다.

Docker and Openshift Image Container / Pod Service Route 10.1.2.10:80, 10.1.3.13:80 172.30.35.131 ews21.test.rockplace.co.kr 다음은 Docker와 Kubernetes의 관계입니다. Docker 자체만으로도 컨테이너를 구동할 수 있지만 전체에 대한 관리가 되지 않기 때문에 컨테이너 관리에 특화된 Kubernetes를 이용하여 마스터 및 노드 전반의 컨테이너를 관리합니다. Kubernetes에서는 컨테이너를 Pod에 담아 관리합니다. 그래서 Pod가 실행되는 최소 단위가 되는 것이고 같은 이미지에서 생성된 여러 개의 Pod는 Service라는 것을 통해서 접근할 수 있습니다. 그리고 외부와의 연결을 담당하는 Route가 있습니다. 서비스는 임의로 생성된 내부아이피를 가지기 때문에 이에 대한 쉬운 접근방법이 필요합니다. 그래서 특정 도메인명을 내부아이피와 매핑해주는 역할이 필요한데 이것이 Route입니다. 외부 클라이언트는 이 Route를 통해서 내부의 Pod와 통신이 가능합니다.

Openshift User and Project Resources Route Service User Project Pod role ResourceQuota LimitRange Deployment Config BuildConfig 이것은 배포된 Pod에 대한 관리콘솔 화면입니다. 웹페이지에서 Pod 내부로 터미널 접속이 가능합니다. 또한 메트릭 탭에서 서버자원 사용량을 모니터링 할 수 있습니다.

Openshift User and Projects

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

Container Resource Limit ResourceQuota LimitRange { "kind": "LimitRange", "apiVersion": "v1", "metadata": { "name": “ews21 }, "spec": { "limits": [ "type": "Pod", "max": { "cpu": "1000m", "memory": "2Gi" "min": { "cpu": "500m", "memory": "1Gi" } … { "apiVersion": "v1", "kind": "ResourceQuota", "metadata": { "name": “ews21" }, "spec": { "hard": { "memory": "8Gi", "cpu": "10", "pods": "10", "services": "10" } 다음은 사용할 수 있는 리소스를 제한하는 방법입니다. ResourceQuota라는 것은 프로젝트당 사용할 수 있는 최대 리소스입니다. LimitRange는 개별 Pod에서 사용가능한 리소스를 정의합니다.

Creating Application in Openshift Docker Build Use Dockerfile S2I Image Builder Use Dockerfile, S2I Tool, Source Url / Path Template Input all required parameters and resources 이미지가 잘 정의되어 있으면 그 다음 부터는 오픈쉬프트가 자동화를 할 수 있습니다. 항상 처음에는 이미지 만드는 것으로 부터 시작을 하는데 오픈쉬프트에서는 몇가지 이미지 만드는 방식을 지원하고 있습니다. Docker Build는 기존의 Dockerfile을 이용한 빌드를 말하는 것이고 S2I Image Builder는 Source2Image 라고 해서 기존 이미지에 소스를 넣어서 이미지를 빌드해주는 빌드용 이미지를 말하는 것입니다. 마지막으로 Image Template은 S2I Image Builder 와 비슷한데 추가적으로 변경이 필요한 부분을 파라미터화 해서 템플릿을 만들어 놓을 것을 말합니다. 그래서 이미지 생성시 소스 이외의 파라미터들을 입력받아 결과 이미지를 만들어 줍니다. 이미지 템플릿을 만들어 놓으면 하나의 이미지로 개발과 운영을 위한 이미지를 파라미터만 다르게 넣어서 만들 수가 있습니다.

이것은 오픈쉬프트 아키텍쳐를 좀더 자세하게 그려놓은 그림입니다. 왼쪽 부터 사용자, 마스터, 노드들이 있고 그안에 Pod들이 들어있습니다. 오른쪽에는 Pod가 사용하는 Persistent Storage와 이미지가 저장되는 Registry가 있습니다. 그럼 다음 장에서 좀더 자세히 살펴보겠습니다.

OpenShift runs on your choice of infrastructure RHEL 7.1 또는 RHEL Atomic Host 7.1.6 OpenShift3.3은 Phisical, Virtual, Private, Public 등의 환경에 상관없이, 레드햇 엔터프라이즈 리눅스(RHEL 7.2 또는 RHEL Atomic Host 7.2)가 설치되어 있으면 오픈쉬프트를 설치하여 사용할 수 있습니다. 또한, OpenShift에 레드햇 엔터프라이즈 리눅스가 포함되어 있어서, OS 기술지원을 위한 별도의 비용이 발생하지 않습니다. RHEL Atomic Host 는 컨테이너 운용에 특화되고 경량화된 OS 입니다.

Nodes are instances of RHEL where apps will run 최초 설치 후 모습 최초에 오픈쉬프트를 설치하면 위와 같이 구성이 됩니다. 주요 구성으로 마스터와 노드들로 이루어집니다. 오픈쉬프트의 마스터는 장애를 대비하기 위해서 이중화로 구성합니다.

Pods run one or more docker containers as a unit 먼저 사용자가 Docker Image를 생성합니다. 그리고 그 이미지로 어플리케이션을 생성하면 Pod에 담겨 Node에 배포가 됩니다. Pod는 Kubernetes에서 스케일링하거나 관리하는 가장 작은 단위입니다.

Pod placement is determined based on defined policy Region 및 Zone 지정 가능 스케쥴러에 의해 선택 Master에는 스케쥴러라는 것이 있습니다. 노드는 Region 및 Zone으로 구분이 되는데 Pod 생성시에 Selector를 지정하므로써 마스터에 있는 스케쥴러가 어떤 Region 및 Zone에 pod를 배포할지 결정할 수 있습니다. 아마존에서 Region 및 Zone을 선택하는 것과 유사한 개념입니다.

Services allow related pods to connect to each other

Management/Replication controller manages the pod lifecycle 레플리케이션 컨트롤러는 Pod가 지정된 개수 만큼 실행되고 있는지 모니터링하며 문제가 생겼을 경우 Pod를 재생성합니다.

What if a pod goes down? 그래서 하나의 Pod에 문제가 생기면

OpenShift automatically recovers and deploys a new Pod

Pods can attach to shared storage for stateful services Pod는 휘발성이므로 Pod 내에서 새로 생성된 파일은 Pod가 재기동되면 사라져버립니다. 그래서 Nas처럼 Persistent Storage를 연결하여 사용해야 합니다.

Routing layer routes external app requests to pods Routing layer는 외부요청과 서비스IP를 연결하여 내부의 Pod까지 연결시켜주는 역할을 합니다.

Developers access OpenShift via Web, CLI or IDE 최종적으로 개발자와 운영자의 관점에서 보면 개발자는 Git이나 서브버전, 그리고 젠킨스 같은 CI툴을 통해 소스를 업데이트하고 새로운 이미지를 만들어서 쉽게 배포를 합니다. 운영자는 콘솔 또는 관리도구를 통해 쉽게 관리할 수 있습니다.

Remote Shell & Resource Usage Metrics Connect to a container easily via a remote shell in the web console Productize and stabilize Heapster Connect it to Hawkular (and therefore Cassandra) Container metrics from cgroups (via the Heapster data model) 관리콘솔로 본 Pod 이것은 배포된 Pod에 대한 관리콘솔 화면입니다. 웹페이지에서 Pod 내부로 터미널 접속이 가능합니다. 또한 메트릭 탭에서 서버자원 사용량을 모니터링 할 수 있습니다.

Topology & Logging 사용자 – 프로젝트 - Pod Topology view to the web console - see a graph of all your resources Productize images for Elasticsearch, Fluentd, and Kibana Full build, deploy, docker (std error/out) log consolidation for admins Developer gets real-time logs to console 토폴로지 구조 로그탭에서 로그를 바로 볼 수도 있습니다. 오픈쉬프트는 사용자가 있고 사용자별로 Project가 있습니다. 그리고 프로젝트 내에 여러 개의 Pod가 존재할 수 있는데 현재 프로젝트의 구조를 한눈에 알 수 있도록 프로젝트에 대한 토폴로지를 자동으로 그려줍니다.

Jboss EAP 템플릿 활용 오픈쉬프트에는 미리 만들어서 제공하는 개발플랫폼이 많이 있습니다. PHP, Ruby, Perl, Python, NodeJS 등은 물론이고 자바는 xPaaS라는 카테고리에 Jboss, Tomcat 과 함께 Mysql, MongoDB가 같이 DB가 같이 들어있는 템플릿도 제공하고 있습니다. 화면에 보이는 것은 JBossEAP 6.4의 템플릿입니다. 보시는 바와 같이 몇가지 파라미터를 입력하면 자동으로 생성됩니다. Name은 Pod와 Service에 필요한 고유 이름이 되겠고 Git Repository Url은 소스의 위치입니다. Hostname은 라우팅할 퍼블릭 호스트네임입니다. Hostname을 주지 않으면 오픈쉬프트가 사용하는 호스트네임의 서브도메인으로 자동생성됩니다. 환경변수는 컨테이너 내부로 넘겨질 환경변수 입니다. Replicas는 처음에 만들어질 Pod의 개수를 의미합니다. 이 Jboss 템플릿은 Openshift.KUBE_PING 이라는 디스커버리 방식을 사용해서 POD가 여러 개 생성되어도 모두 클러스터로 연결됩니다. 이 템플릿 구조는 Json파일로 받을 수가 있고 필요한 부분을 고쳐서 다시 생성할 수도 있습니다.

Jboss EAP 템플릿 활용 이 화면은 좀전의 템플릿으로 만들어진 내용입니다. 라우트, 서비스, 파드 등이 자동으로 생성되었습니다.

Custom JBoss Image 활용 Apache – Jboss 가 연동되어있는 플랫폼 이미지 생성 Project생성 [root@master ~]# oc new-project jboss-eap Now using project "jboss-eap" on server "https://master.example.com:8443" [root@master ~]# oc new-app openshift/ews21 --> Found image 47bd983 (4 days old) in image stream "ews21 in project openshift" … [root@master ~]# oc expose service ews21 route "ews21" exposed [root@master ~]# oc new-app openshift/eap64 --> Found image 39efc72 (4 days old) in image stream "eap64 in project openshift" .. 웹서버-Ews21 생성 외부 서비스노출 Jboss-Eap64 생성 이것은 제가 테스트로 커스텀빌드로 제작한 이미지를 사용하여 배포한 내용입니다. 이미지는 아파치와 Jboss 한개씩 해서 총 2개를 만들었고 EWS21이 아파치 이고 EAP64가 Jboss입니다. 먼저 jboss-eap라는 새로운프로젝트를 만들었습니다. 커맨드라인에서는 oc new-app 이라는 명령어로 어플리케이션을 생성합니다. 이 명령어와 함께 ews21 이라는 이미지를 사용해서 웹서버를 생성하였고 Expose 명령어로 라우트를 생성하여 외부로 오픈하였습니다. Jboss는 Eap64 라는 이미지를 사용해서 생성하였습니다. 아파치와 Jboss는 modcluster를 사용하여 pod가 증가하여도 자동으로 아파치와 Jboss가 연동되도록 이미지를 설정하였습니다.

Sample Project 생성된 내용이 관리콘솔에 이렇게 보여집니다. 웹서버인 Ews21은 라우트를 생성하였기 때문에 보시는 바와 같이 도메인명이 생성되었고 Jboss는 생성하지 않았기 때문에 eap64라는 서비스명만 표시됩니다.

Sample Project - Topology Route: ews21 ews21-jboss-eap.test.rockplace.co.kr service: ews21 172.30.176.102 service: eap64 172.30.66.29 ReplicationController pod: eap64-1-aetyv 10.1.2.15 pod: ews21-1-lascd 10.1.3.15 DeploymentConfig DeploymentConfig ReplicationController 그리고 제가 생성한 프로젝트의 토폴로지를 보면 위와 같이 표시됩니다. 왼쪽에 웹서버인 ews21이 라우트, 서비스, 파드 의 순으로 보이고 오른쪽 eap64의 서비스와 2개의 파드가 보입니다.

Differences between EAP and EAP xPaaS Image 그리고 제가 생성한 프로젝트의 토폴로지를 보면 위와 같이 표시됩니다. 왼쪽에 웹서버인 ews21이 라우트, 서비스, 파드 의 순으로 보이고 오른쪽 eap64의 서비스와 2개의 파드가 보입니다.

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