Technical/Cloud, Virtualization, Containers

[OpenShift v3 #3] Origin 3-node, CentOS 7 기반 3노드 설치, 사용 방법(3/3)

Barracuda 2017. 5. 14. 22:53
반응형



2회(#2/3) 에서 이어지는 내용이다 


  • GitHub 를 사용한 개발과정 맛보기 #2 - WordPress Sample & MySQL(PHP)

이번에는 OpenShift GUI Console 이 아닌 명령어 방식으로 oc(OpenShift Client)를 사용해 보겠다. Master Node로 ssh 로그인을 하고 새로운 프로젝트를 생성한다. OpenShift Console에서 실시간으로 확인 가능하다


GitHub.com의 Wordpress project URL(https://github.com/DragOnMe/WordPress.git)을 복사한다


oc 명령으로 php:latest 도커이미지와 WordPress 소스 repository를 지정하여 새로운 App 서비스를 프로젝트에 추가한다. 진행 상황은 텍스트에 나온 설명대로 'oc logs -f bc/어플리케이션이름' 을 수행해 보거나, 앞서와 마찬가지로 GUI를 통해 Build Log 상태를 확인할 수도 있다 


OpenShift Console 화면에서 새로 만든 프로젝트 클릭


WordPress 실행을 위한 PHP 웹서버 부분은 Build & Deploy 가 완료되었고 하나의 Pod가 기동되어 있다


GUI console에서와 달리, 명령어 방식에서는 서비스에 접속 가능하도록 expose 명령으로 주소를 할당해야 한다. 이제 MySQL DB를 준비해 보자


상단의 프로젝트 타이틀 우측 'Add to project' 클릭


Technologies 부분의 'Data Stores' 클릭


'MySQL (Ephemeral)' 선택


계정, 암호 등은 자동 생성되도록 비워 두고 'Create' 클릭(기억할 수 있는 암호와 계정을 정하고 직접 입력해도 된다)


계정, 암호 등은 MySQL 컨테이너 기동 시에 정확히 입력해야 하므로 잘 기억 또는 메모해 둔다(긁어서 복사해 두자). 'Continue to overview' 클릭


위쪽에 새로 만든 MYSQL EPHEMERAL 컨테이너 서비스가 기동되어 pod 1개가 만들어져 있다. 이제 PHP 웹을 실행해 보기 위해 Route(접속 URL)을 클릭


WordPress 초기 셋업(설치) 화면이 연결되었다. 'Let's go!' 클릭


Database Host 에는 OpenShift 프로젝트에 존재하는 서비스명(mysql)을 입력한다. 'Submit' 클릭


'Run the install' 클릭


제목 등을 적당히 입력하고 'Install WordPress' 클릭. 다음 화면에서 'Log In' 클릭, 입력한 로그인 계정으로 로그인


WordPress 대쉬보드 화면 접속 성공!



  • Auto-Scaling 의 사용(Hawkular Metrics)

#1. 수동 scaling - 새로운 프로젝트 생성(Create) 


Autoscale 테스트를 위한 PHP web 을 구동할 예정이다. PHP 선택


언어는 크게 상관이 없다. PHP 5.6 으로 선택하고 'Select'


github.com 프로젝트로 간단한 PHP 페이지 프로젝트를 준비한다. 단순히 phpinfo() 를 수행하는 웹사이트이다. Clone or download 를 통해 URL(https://github.com/DragOnMe/php_for_autoscale.git) 복사


Git Repository URL에 위에서 복사한 URL을 paste(Create)


Continue to overview 로 Overview 화면으로 이동


서비스 내에 Pod 가 하나 만들어지고 Web 서비스 준비 완료. 상단 Routes 주소 클릭


웹서비스 정상 접속 완료


Pod 를 수동으로 Scaling 해보자. Overview 로 돌아와서 Pod 를 클릭


현재 기동되어 있는 단 하나의 Pod 가 보일 것이다. Pod 이름 클릭


동일한 Pod가 여러 개 생길 수 있으므로 Pod 이름은 '서비스명-빌드번호-b9t2h' 와 같은 형태로 자동으로 생성된다. Pod의 상태를 확인해 보면 내부 사설 IP 10.130.0.27 이며 node02 에서 동작하고 있음을 볼수 있다


Pod 우측의 위아래 버튼을 누르면 Pod의 갯수가 증가/감소하는 것을 볼 수 있다


Pod를 2개로 만든 상태에서 Pod 버튼을 클릭하면 2개의 Pod 가 기동되어 있음을 볼 수 있다


새로 만들어진 Pod 를 클릭해 보면, IP 10.129.0.13 이며 node01 에서 동작하고 있다



#2. 자동 scaling, HPA(Horizontal Pod autoscale) 라고 하며, 본 글 작성시 사용중인 Origin 1.4 버전에서는 Hawkular Metrics 가 비교적 안정적으로 통합되어 오토스케일을 위한 추가 설정의 부담이 많이 줄어들었다 - 새로운 프로젝트 생성(Create), 앞서 #1 과 마찬가지로  https://github.com/DragOnMe/php_for_autoscale.git 저장소 주소를 사용하는데, 이번에는 프로젝트 이름만 Auto-2 로 구분가능하도록 진행하자


* 여기서 중요하게 확인해야 할 것은 위의 터미널에 나와 있는 oc get pods 명령어의 결과에서처럼, metric 모니터링을 위한 3개의 기본 pod(hawkular metrics/cassandra, heapster) 가 반드시 Running 상태가 되어 있어야 한다는 것이다 


서비스를 추가하는 화면에서 아래로 스크롤해 내려간다


Scaling 타이틀 아래에 Strategy 부분을 Automatic 으로 바꾸고, 아래의 설정 값들을 적당히 입력한다


조금 더 아래로 내려 가면 Resource Limits 부분이 나온다. 여기에 세부 Metric 설정 값들을 입력해야만(자세한 설정 방법은 여기 참고), 비로소 해당 서비스를 자동으로 Scale-out/in 할 수 있게 된다(Create 클릭)


이전 프로젝트들의 Summary 화면과 다른 부분을 볼 수 있다. 우측 상단의 서비스 URL을 클릭해서 해당 서비스 페이지를 접속해보고, 화면 refresh 를 연속으로 몇 차례 시도한 후, 이 화면으로 돌아오면 Pod 왼쪽의 그래프 부분이 바뀌어 부하 발생에 바뀌어 나타나는 것을 볼 수 있다


osmaster 내부가 아닌 외부 시스템의 터미널 창에서 Apache ab 를 실행하여, 서비스 URL 페이지에 대해 다량의 접속 부하를 발생시키면, OpenShift Summary 화면의 그래프가 바뀌며, Pod가 최대 갯수인 4개까지 자동으로 늘어나는(scaled-out) 것을 볼 수 있다


웹페이지 부하를 멈춘 상태에서 몇 분 정도 지나면 자동으로 최소 Pod 갯수인 1개까지 줄어(scaled-in) 있는 것을 볼 수 있다



  • Persistent-Volume 의 사용

#1. github.com 에서 simple-file-manager 리포리터리의 URL 복사


새로운 프로젝트를 만들고 PHP 언어를 선택. Git URL에 위에서 복사한 주소 paste


빌드 / 배포가 완료 되면 오픈소스로 공개된 간단한 파일 업다운로드 서비스가 기동될 것이다. 새로운 파일을 업로드해 보자


Overview를 통해 Pod를 선택하고 Terminal 로 들어가 보면 새로 업로드한 파일이 보인다. 그러나 이 파일은 Pod(또는 컨테이너)가 없어지면 같이 사라지게 된다(/tmp 아래의 일회용 스토리지 공간에 저장)


* Overview 화면에서 Pod를 1개 늘리고, Terminal 로 들어가서 ls 를 해 보면 새로 만들어진 Pod에는 위에서 업로드한 파일이 보이지 않을 것이다. Pod 별로 각각 일회용 스토리지 영역이 할당되기 때문이다


 

#2 이번에는 OpenShift 내에서 미리 설정된 Persistent Volume(NFS 볼륨)을 사용하여 컨테이너에 직접 마운트해서 사용해 본다. 위 #1과 마찬가지로 새로운 프로젝트를 만들고 https://github.com/DragOnMe/simple-file-manager.git 리포지토리를 연결한다


Deployments 화면 아래의 Add storage 클릭


"프로젝트의 배포 설정에 추가할 persistent volume 요청이 없으니 추가" 하라고 한다(Create storage 클릭)


[Volume Claim 단계] 앞서 Persistent Volume을 ReadWriteMany 모드로 만들었으므로 Access Mode는 RWX 를 선택하고 볼륨 크기를 적당히 지정(미리 만든 각 PV들은 400M 이므로 그 이하의 크기)하고 Create


[Add Storage: 스토리지 할당 단계] 앞의 Volume Claim 에 대해 pv010 볼륨이 자동으로 할당되었다. Mount Path 는 컨테이너 Application 내부에서 사용하는 Mount Point의 Path(simple-file-manager에서 사용하는 data path는 /opt/app-root/src 이다) 를 입력한다


다시 위로 스크롤 해서 Deploy 를 수행한다


Pod 에 터미널로 접속해서 새로운 파일을 하나 만들자. 파일 업로드를 흉내 내 보는 것


Overview 로 돌아가서 Pod 를 하나 늘려두자


새로이 만들어진 Pod 에서 터미널 접속 후 ls 로 확인해 보면 앞에 만들어져 있던 Pod 에서 생성한 파일이 보인다. 두개의 Pod 가 OpenShift 가 제공하는  PV를 공유하고 있음을 알 수 있다


좌측 Storage 메뉴를 통해, 현재 프로젝트에 할당된 스토리지 정보를 확인할 수 있느. 명령어 방식으로 system:admin 계정으로 oc get pv 명령어를 통해서 전체 시스템에서 사용 가능한 PV 정보를 확인힐 수도 있다



이로써 3회에 걸친 OpenShift Origin v3 에 대한 설치와 소프트웨어 엔지니어 입장에서의 간단한 설정 & 사용 방법에 대해 알아 보았습니다. 되도록 간단히 요점 위주로 작성해 두려 했으나, 직접 수행해 본 내용을 꼼꼼히 빠짐 없이 기재하고 설명을 달다 보니 분량이 제법 늘어나 있어서 다소 읽기에 부담이 될지도 모르겠습니다. 불필요한 부분은 알아서 스킵하시고 참고해 주시길~ ^^


혹시 궁금한 점이 있거나, 지적할 부분이 있다면 언제든 댓글로 컨택해 주시기 부탁 드립니다. - Barracuda -





[연관되는 글]

[OpenShift v3 #1] Origin all-in-one, CentOS 7 기반 단일서버 설치 사용법(1/3)

[OpenShift v3 #2] Origin 3-node, CentOS 7 기반 3노드 설치, 사용 방법(2/3)


- Barracuda -



반응형