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

IT Must Evolve to Stay Ahead of Demands 먼저 오픈쉬프트가 나오게 된 배경에 대한 얘기 입니다. 요즘은 모든 것이 빠르게 변화합니다. 그리고 이런 요구사항에 맞추기 위해서 소프트웨어도 빠르게 따라가야 하는 상황이 되었습니다. 그래서 방법론도 빠르게 배포하는 애자일로 넘어갔는데 여기에 더해서 보다 효율적인 구조를 만들기 위해서는 개발과 운영이 잘 조화되어야 한다는 데브옵스가 강조되고 있습니다. 어플리케이션 아키텍쳐도 마찬가지입니다. 예전의 하나의 어플리케이션에 모든 로직이 들어있는 모노리씩 구조에서 확장이 용이하도록 잘게 나누어진 마이크로서비스의 필요성이 나오고 있습니다. 어플리케이션을 마이크로서비스 형태로 나누면 부하가 집중되는 부분만 쉽게 확장을 할 수가 있습니다. 어플리케이션이 패키징 되는 공간도 기존의 VM 기반의 가상화 기술에서 훨씬더 빠르고 가벼워진 Docker와 같은 컨테이너 기술이 도입되고 있습니다. Docker 컨테이너는 게스트OS가 필요없고 Host OS와 바로 통신할 수 있는 구조이기 때문에 빠르고 가볍습니다. 인프라 환경도 클라우드가 계속 증가하고 있는 추세입니다. 오픈쉬프트는 개발자가 바로 플랫폼을 생성하여 테스트 해볼 수 있으며 컨테이너 기반의 마이크로서비스를 구축하기에 용이한 Paas 솔루션입니다.

PaaS ? 간단히 PaaS에 대해서 추가설명을 드리면 클라우드에서 Virtual Machine이나 스토리지, 네트웍 등을 서비스로 제공하는 것을 IaaS 라고 하고 IaaS에 더해서 개발 및 실행환경이나 데이터베이스, WEB/WAS 서버 등의 플랫폼을 제공하는 것을 PaaS라고 합니다. Platform as a Service.

DevOps Workflow OPS DEV DEVOPS Create containerized IaaS or PaaS development environment Scheduler orchestrates and deploys app Monitor and operate app Provision environment locally or on the cloud Write app as containerized microservices cluster and commit changes Push changes through CI/CD and automated testing system to containerized staging CICD App dev environment APP On-premise App prod environment Monitor Manage DevOps feedback loop Dev feedback loop Cloud 다음은 데브옵스에서 오픈쉬프트가 어떻게 운영될 수 있는지 간략하게 보여드리기 위한 그림입니다. 데브옵스는 개발과 운영팀이 서로의 업무를 어느 정도는 알아야 가능합니다. 먼저 운영팀에서 개발 및 운영에 필요한 컨테이너 이미지를 만들어 제공합니다. 그러면 개발팀에서는 오픈쉬프트를 통해 셀프서비스로 개발된 소스를 이미지에 추가하고 컨테이너를 실행시켜 쉽게 테스트해 볼 수 있고 문제가 없으면 파라미터를 바꿔서 운영환경에 바로 적용해 볼 수 있습니다. 그 다음에는 오픈쉬프트 웹콘솔에서 같이 모니터링을 하면 되죠.

Create cloud ready apps for DevOps Monolithic app container Scale up by adding hardware resources Limited scale out through clustering Distributed, networked, containerized services Scale out by orchestrating services Faster iteration and release More robust RHEL APP SINGLE-HOST APPS CONTAINER HOST MULTI-HOST MICROSERVICE APPS 이 페이지는 어떤 형태의 어플리케이션이 클라우드에서 유리한가에 대한 내용입니다. 일반적으로 하나의 어플리케이션 내에 모든 로직이 들어있는 경우를 모노리씩 아키텍쳐라고 하고 기능별로 잘게 나누어져 분산된 형태를 마이크로서비스 아키텍쳐라고 합니다. 보통 어플리케이션의 규모가 작고 단순하거나 트랜잭션 관리가 훨씬 더 중요한 경우에는 기존의 모노리씩 형태가 유리할 수 있습니다. 하지만 그렇지 않다면, 기능별로 나눌 수 있고 확장이 예상된다면 마이크로서비스 형태를 가져가야 합니다. 모노리씩 형태는 확장을 하려면 수직확장을 하거나 수평확장을 하려고 해도 하나로 묶여있기 때문에 어플리케이션 전체를 확장해야 합니다. 반면에 마이크로서비스 아키텍쳐는 기능별로 나누어져 있기 때문에 부하가 집중되는 몇 개의 기능을 가진 마이크로서비스만 확장하면 됩니다. 확장이 쉬운것이 바로 클라우드의 특징입니다. 이런식의 마이크로서비스 형태로 가져가는 것이 클라우드의 장점을 잘 이용할 수 있는 방법입니다.

오픈쉬프트는 Docker 컨테이너를 적용한 최초의 오프 소스 PaaS 솔루션이고. 셀프서비스 및 자동화가 가능하고 컨테이너에서 서비스되는 언어를 가리지도 않습니다. Go 언어로 작성된 Hello-Openshift 샘플 이미지가 있습니다. 10메가도 안되는 사이즈로 컨테이너를 생성하여 서비스가 됩니다. 만능은 아니지만 좀전에 말씀 드렸던 부분들을 쉽게 도와주는 기능을 가진 것이 오픈쉬프트입니다.

Value of OpenShift 현재 오픈쉬프트는 마켓을 선도하고 있습니다. 운영팀은 컨테이너 기반의 애플리케이션 플랫폼을 사용함으로써, 애플리케이션이 탑재된 docker 컨테이너 이미지를 운영환경에 쉽게 적용할 수 있습니다. 따라서 애플리케이션 관리를 간소화되므로 운영 효율성을 증가시킬 수 있습니다. 또한, 빌드, 배포, 테스트를 자동화하고 애플리케이션이 바로 서비스될 수 있는 환경을 제공함으로써 DevOps 환경 구성도 가능하게 합니다.

Community Powered Innovation 오픈소스에는 처음 시작된 커뮤니티 프로젝트가 있고 이를 바탕으로 기업용으로 다시 패키징된 엔터프라이즈가 있습니다. OpenShift Origin이 OpenShift 엔터프라이즈의 커뮤니티 프로젝트입니다. Origin은 도커, 쿠버네티스, 아토믹호스트 등의 기존 프로젝트들이 결합되어 있습니다. 레드햇에서는 Origin으로부터 두 가지의 형태로 OpenShift 솔루션을 제공하고 있습니다. OpenShift Enterprise는 기업내에서 PaaS 환경을 구축할 경우 사용하는 Private PaaS solution 입니다. 그리고, OpenShift Online은 openshift.com 사이트를 통해, 인터넷상에서 제공되는 퍼블릭 PaaS 서비스입니다.

OpenShift Online Openshift Online은 생긴지는 얼마 안되었지만 현재 상승세에 있고 현재 약 230만 개의 어플리케이션이 생성되어 있으며 매년 100 프로의 성장을 하고 있다고 합니다.

JBoss Middleware Services on OpenShift Application Container Services Business Process 
Management * Business Rules 
Management System * Business Process Services Fuse A-MQ Data Virtualization Integration Services Mobile Services JBoss Enterprise Application Platform JBoss Web Server / Tomcat JBoss Developer Studio Red Hat Mobile / FeedHenry * * = Coming Soon 또, 레드햇이 제공해드리는 Jboss EAP같은 미들웨어 제품을 컨테이너 형태로 OpenShift 에서 바로 사용할 수 있습니다.

OpenShift Application Services From Red Hat From ISV Partners From the Community OpenShift 는 PHP, Perl, Ruby, Python, Node.js 같은 Application 플랫폼을 사용하실 수 있으며, MongoDB, MySQL, PostgreSQL 등의 DB도 사용할 수 있습니다. 그외 docker 커뮤니티에서 제공하는 docker 이미지도 사용할 수 있습니다. docker 커뮤니티에는 훨씬 더 많은 이미지들이 있습니다. 여기에 없는 이미지는 만들면 되기 때문에 특별히 제약은 없습니다.

OpenShift 3 Standard containers API Web-scale container orchestration & management Container-optimized OS Largest selection of supported application runtimes & services Robust tools and UX for Development & Operations Industry standard, web scale distributed application platform 오픈쉬프트 아키텍쳐 특징 맨 아래 부터 보시면 오픈쉬프트는 컨테이너 운영에 최적화가 되어 있는 Container Host가 있고 표준화된 컨테이너 API , 전체 컨테이너를 관리 및 조율하는 쿠버네티스, 컨테이너에 들어 있는 각종 플랫폼, 그리고 데브옵스를 위한 관리 툴 등으로 구성되어 있습니다.

OpenShift Architecture Web Console IDE 이것은 OpenShift의 핵심 컴포넌트를 간단하게 표현한 그림입니다. 오픈쉬프트는 크게 마스터와 여러 개의 노드로 구성됩니다. 마스터와 개별 노드가 각각 독립된 호스트로 보시면 됩니다. 마스터는 전체 오픈쉬프트를 관리 및 오케스트레이션 하는 영역이고, 노드는 docker 컨테이너가 구동되는 영역입니다. 개발자와 운영자는 웹 콘솔이나 통합개발툴 또는 CLI 툴을 사용하여 마스터의 API 서버로 명령을 전달하여 원하는 기능을 수행합니다. 명령을 전달받은 API서버는 원격의 Node상에 있는 Kubelet agent에 명령을 전달하고, docker엔진으로 전달되어 Node 상의 컨테이너를 관리합니다. IDE : Integrated Development Environment CLI : Command Line Interface

OpenShift Enterprise Read more at: openshift.com/customers 오픈쉬프트 레퍼런스 사이트입니다.

OpenShift On OpenStack A True Open Hybrid Cloud Deploy OpenShift on OpenStack via Heat Integrate Apps with OpenStack services Manage it all with CloudForms Get it all at once with Red Hat Cloud Suite Openshift를 오픈스택에 설치하여 사용할 수 있습니다. 전용 관리 솔루션인 CloudForms 를 연결하여 관리할 수 있습니다. 클라우드폼즈는 아마존 같은 다른 클라우드 환경도 연동할 수 있습니다.

Awards and Product Reviews “From the pain-free install and easy app deployment to gear idling and automatic scaling, OpenShift fulfills the promise of platform as a service” 오픈쉬프트는 현재 컨테이너 기반 Paas 솔루션에서 업계의 선두주자로 인식되고 있습니다. 그리고 인포월드에서 주관하는 2015년 PaaS category 에서 Product of the Year 에 선정되었습니다. 또한 코디 어워드, 클라우드 이노베이션 어워드 등을 수상하였다고 합니다.

OpenShift Product Deep Dive 다음은 오픈쉬프트에 대한 좀더 딥다이브한 내용입니다. 도커와 쿠버네티스 그리고 오픈쉬프트 구조에 대한 내용을 다루었습니다.

Container Linux LXC LibContainer Docker Docker는 오픈쉬프트의 핵심 모듈입니다.

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는 소프트웨어 실행에 필요한 모든 파일 Code, Runtime실행파일, System Tool, System Library 등을 포함하여 이미지로 만들고 다시 Container로 만들어 Docker 프로세스로 실행할 수 있습니다. 이를 통해서 하나의 호스트 내부에 독립된 VM 같은 실행환경인 컨테이너를 구축할 수가 있습니다.

Docker Hub https://hub.docker.com/explore/ Docker Hub라는 곳에 Docker 이미지의 생태계가 구축되어 있는 것입니다. 여기에 가면 이미 웬만한 플랫폼들은 모두 이미지로 만들어져 있습니다.

Docker Hub https://hub.docker.com/explore/ 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라는 말을 많이 붙입니다. Hello-openshift는 간단하게 이미지를 만들어볼 수 있는 예제입니다. 설명을 드리면 From은 베이스 이미지, Scratch 라는 이미지를 기본으로 해서 만들겠다는 것이고 Maintainer는 만든 사람 ADD는 넣을 파일 Expose는 사용할 포트 Entrypoint는 컨테이너 기동시 실행할 파일을 의미합니다. Scratch 이미지는 아무것도 들어있지 않은 껍데기 이미지 입니다. 이렇게 이미지를 만들면 10메가 보다 작은 사이즈로 이미지가 생성됩니다.

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 # USER 1001 #운영환경에서는 일반유저를 사용하여 실행 EXPOSE 80 CMD ["/opt/jboss-ews-2.1/httpd/sbin/apachectl","-k","start","-D","FOREGROUND"] 이 도커파일은 아파치 웹서버용으로 제가 만들어본 파일입니다. 기본으로 Centos6.6 이미지를 가져와서 Yum 패키지 관리자로 tar, unzip 등 유틸리티 패키지를 추가하고 httpd 설치파일을 복사하고 사용포트 80을 지정하고 실행명령을 지정합니다. 운영환경에서는 일반유저를 사용하여 실행하는 것이 보안상 좋습니다. 이렇게 도커파일을 정의하고 빌드하면 centos6.6에 아파치가 설치된 이미지가 생성이 됩니다.

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이라는 명령어로 컨테이너를 기동합니다. 컨테이너는 10. 점 대 내부 IP를 할당받습니다. -p 는 호스트로 들어오는 80 포트 트래픽을 컨테이너의 80 포트로 보내라는 것이고 -h는 컨테이너의 호스트명을 web1로 하겠다라는 것입니다.

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

VM vs Docker Container 보시는 바와 같이 Container에는 게스트OS와 하이퍼 바이저가 없습니다. 그래서 더 가볍고 빠릅니다.

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

Container Management by Kubernetes Route: ews21 ews21-jboss-eap.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는 외부로 부터의 진입점 역할을 합니다. 오픈쉬프트에서는 하나의 이미지로부터 앱을 만들면 이러한 구조가 자동으로 생성이 됩니다.

Creating Image in Openshift Docker Build Use Dockerfile S2I Image Builder Use Dockerfile, S2I Tool, Source Url / Path Image Template Input all required parameters and build image 이미지가 잘 정의되어 있으면 그 다음 부터는 오픈쉬프트가 자동화하고 있습니다. 항상 처음에는 이미지 만드는 것으로 부터 시작을 하는데 오픈쉬프트에서는 몇가지 이미지 만드는 방식을 지원하고 있습니다. 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 OpenShift는 Phisical, Virtual, Private, Public 등의 환경에 상관없이, 레드햇 엔터프라이즈 리눅스(RHEL 7.1 또는 RHEL Atomic Host 7.1.6)가 설치되어 있으면 오픈쉬프트를 설치하여 사용할 수 있습니다. 또한, 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를 생성하면 해당 컨테이너가 Pod에 담겨 Node에 배포가 됩니다. Pod는 Kubernetes에서 스케일링하거나 관리하는 가장 작은 단위입니다.

Pod placement is determined based on defined policy Region 및 Zone 지정 가능 스케쥴러에 의해 선택 노드는 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개의 파드가 보입니다.

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