openshift

 

What is OpenShift?


OpenShift는 Platform as a Service 환경을 제공 해주는 RedHat의 솔루션 입니다.
Platform as a Service(PaaS)란 응용프로그램(Appllication)을 개발하기 위한 안정적인 환경을 제공 하는 형태를 말합니다.
즉, 사용자가 직접 구축 할 필요 없이 ‘이미 구축 되어 있는 것을 바로 가져다 사용 또는 개발 할 수 있도록 환경을 제공 하는 것’이라 이해 하시면 됩니다.

OpenShift는 4가지 버전으로 나뉩니다.

– Origin

오픈소스로 제공 하는 버전 입니다.

– Enterprise
Origin Stable 버전이 Enterprise 입니다.

– Online
온라인에서 바로 사용 할 수 있도록 만들어진 무료/유료 서비스 입니다.

– Dedicated
클라우드 서버에서 OpenShift를 단독으로 제공 해주는 서비스 입니다.

여기서, Origin과 Enterprise가 어떤 부분에서 차이가 있는지 궁금 하실텐데요..
제가 아는 바로는 설정 부분에서 미묘한 차이가 존재 하는 것 뿐이지 별반 차이 없다고 느꼈습니다.
(제가 RedHat 직원이 아니기 때문에 자세한건 모르겠네요. ㅋㅋ)

그럼, OpenShift에 어떻게 구성 되어 있고 어떻게 사용하는지 실제 구축을 통해 알아 보도록 하겠습니다.

본 글은 OpenShift Origin v3.x 기반에서 테스트 되었으며, 작성자의 지극히 개인적인 경험을 바탕으로 작성한 내용 입니다.
따라서, 틀린 부분이 존재 할 수 있으므로 이점 감안하여 읽어 주시기 바라며, 지적 사항이나 궁금한 사항이 있다면 댓글 달아 주세요. 🙂

OpenShift Architecture


OpenShift v3.x에서는 아래의 Docker, Kubernetes, Mesos의 주요 모델을 기반으로 몇가지 필요한 추가 사항들을 반영하여 만들어졌다고 보면 되겠습니다.

– 3가지 주요 모델

그럼, OpenShift가 어떤 부분으로 구성 되어 있는지 살펴 보도록 하겠습니다.

 

– Master


– Minion

 

– Command

 

– Other


openshift_v3.x_architectureFigure 1. OpenShift Architecture

OpenShift Origin (All Node)


Fully distributed 환경으로 만들어 보고자 합니다.
대략 10대 정도의 서버가 필요 합니다. (DNS 서버를 구성하지 않으시겠다면, 9개로 구성 하시면 되겠습니다.)

Deploy 서버는 OpenShift를 구성하려는 서버에 설정 및 설치 부분에 대해 배포하기 위해 사용 됩니다.
따라서, 모든 구성은 Deploy 서버에서 진행 하며, 따로 언급이 없는 경우에는 배포 서버에서 설정 한다고 보시면 되겠습니다.

각 서버에서 접근 및 설정이 용이 하도록 공통적으로 설정 되야 하는 부분에 대해서 먼저 설정 하도록 하겠습니다.

 

1. Hosts 등록
OpenShift가 설치 되고 설정 되어야할 서버들의 호스트 네임 정보를 deploy 서버에 추가 합니다.

 

2. NTP 설정
각 서버의 시간을 동일하게 맞추기 위한 설정 입니다.
(폐쇠망을 운영하는 경우 외부로 접근이 되는 NTP 서버를 따로 두고 로컬 NTP로 구성 하시는 편이 좋습니다.)

 

3. OpenSSH 설정
SSH 접속시 호스트의 SSH 접속 key를 확인 하는 부분을 비활성 합니다. (테스트 용도니까 귀찮은건 제외 합시다.)

 

4. SSH Key 생성
각 서버를 제어하기 위해 SSH Key를 생성 합니다.

 

5. SSH Key 배포
최초 SSH Key를 배포하기 위해 sshpass를 사용하여 배포 하도록 합니다.
sshpass를 사용하기 위해서는 외부 저장소인 EPEL을 추가 하여야 합니다.

 

6. hosts 및 NTP 설정
앞서 설정하였던 hosts 파일과 NTP 파일을 각 서버에 배포 하여 동기화를 진행 합니다.

 

7. SELinux 활성화
OpenShift는 SELinux가 활성화 되어야 설치가 되므로 활성화 합니다. (기본적으로 enforcing 모드로 지정 되어 있습니다.)

 

8. Bash Completion 패키지 설치
명령어 입력시 수작업으로 입력 하는 것을 줄이고자 Bash Completion 패키지를 설치 합니다. (반드시 필요한 작업은 아닙니다.)

 

9. Network Manager 제거
Static IP를 사용할 계획이라 불필요한 Network Manager를 삭제 합니다.

 

10. Docker 설치 및 재시작
실제로 OpenShift를 실행하려면 Master, Minion, Router 서버에 Docker가 설치 되어 있어야 합니다.
나중에 아시겠지만, 앞서 언급한 3개 서버에서는 Container 형태로 배포하여 관리 하기 때문에 필요 합니다.

따라서, DNS 서버를 제외한 나머지 서버들에 대해서는 Docker를 설치 합니다.
(Docker 설치시 EPEL 저장소가 필요 합니다.)

또한, RHEL/CentOS 계열의 Docker Storage Driver는 Device Mapper Driver를 사용하는 것을 권장합니다.
(overlay 등을 사용 하셔도 되나, Docker image 빌드가 안된다거나 하는 문제가 조금 있습니다.)

OpenShift Origin (DNS Node)


DNS 서버에서만 설정하는 부분이며, 이 작업은 프로젝트에서 생성한 Application에 외부에서 접근이 용이 하도록 서브 도메인을 제공 해주기 위한 용도로 설정 합니다.

본 설정은 실제 도메인을 가지고 있고 이것을 사용하겠다라는 전재하에 진행 합니다.
(실제 IP를 입력 하시면 되겠습니다. 테스트 용도면 내부 IP로 사용하면 됩니다.)

 

1. zone 파일 생성
‘*’가 붙은 A 레코드는 도메인 “yongbok.net”에 설정 되어 있는 A 레코드를 제외한
모든 2차 도메인은 router ip 로 설정 하도록 합니다.

이렇게 하는 이유는 프로젝트에서 Application을 배포했을때, router 서버가 Default DNS를 기반으로 서브 도메인 형식으로 배포 하기 때문 입니다.
(이 부분은 뒷 부분에서 몇번 사용하다 보면 이해 됩니다.)

 

2. named.conf 설정
DNS의 레코드 정보는 보이지 않도록 하면서, Cache DNS 서버로 활용 하도록 설정 합니다.

 

3. DNS 설정 파일 복사 및 Bind 데몬 실행
위의 설정한 Zonefile, named.conf 파일을 DNS 서버로 배포 후 Bind 데몬을 실행 합니다.

OpenShift Origin (Deploy Node)


실제로 각 서버에 OpenShift를 설치 및 설정을 하기 위해 ‘atomic-openshift-installer’이라는 명령어를 통해 작업 하는데,
이것은 ‘openshift-ansible’이라는 이름의 프로젝트를 github에서 받아 빌드를 해야 사용 가능 합니다.
(Enterprise 버전은 서브스크립션에 포함이 되어 있지만, Origin은 직잡 빌드 해서 설치 해야 합니다.)

그리고, ‘atomic-openshift-installer’ 명령어는 Ansible을 사용하여 배포하는데, ansible을 EPEL 저장소에서 설치 하면 2.x 버전이 설치 됩니다.

사용 하는데 문제는 없지만, 실제로 ‘atomic-openshift-installer’ 명령어를 통해 설치 작업을 하면,
00_openshift 라는 모듈이 없다고 나오므로, ansible 1.9 버전을 설치하는 것을 권장 하는 바입니다.

 

1. Openshift Ansible 설치

이제 각 서버에 OpenShift를 설치하기 위해 ‘atomic-openshift-installer’ 명령어를 실행할 차례 입니다.
진행 하기 위해 ‘y’를 누릅니다.

 

SSH 접근에 사용할 사용자를 지정 하는 부분 입니다. ‘root’ 사용자로 설정 합니다.

 

OpenShift 버전을 어떤 것으로 설치 할건지 선택 하는 부분 입니다.
최신 버전인 OpenShift Enterprise 3.2를 선택 합니다.
(말이 Enterprise 뿐이지 실제로는 설정 파일의 수정을 통해 Origin으로 변경 해야 합니다.)

 

호스트 서버를 등록 하는 부분 입니다.
Master 서버 3대로 구성 할 것이니 아래와 같이 Master 서버의 도메인명을 적어 줍니다.

 

Master 서버 1대를 등록 하면 아래와 같이 Summary가 표시 됩니다.

 

위와 같이 Master 서버를 2대 더 추가 해줍니다.

 

Master 3대가 추가 되었습니다.

 

이제 Router 1대, Minion 3대를 위와 같은 방법으로 추가 하되,
Master 서버로 지정 할 것이 아니기 때문에 OpenShift Master 물음에는 ‘n’로 답 해주시기 바랍니다.

 

이쯤에서 정리 해보자면 Master 3대, Router 1대, Minion 3대 = 총 7대 됩니다.

 

더 이상 추가 할 것은 없으니 ‘n’으로 답 합니다.

 

Master 서버의 HA 구성을 위한 부분 입니다.
장애가 발생해도 Fault Tolerance로 동작하기 때문에, 하나만 바라 보면 되는 대표 도메인 또는 VIP를 지정 후 HAProxy 설치에 ‘ y’로 답 합니다.

 

HA를 사용할 경우 별도의 HA용 스토리지 호스트가 필요 합니다.
Base가 되는 호스트를 지정 하면 되며, 기본적으로 우선 순위가 높은 놈이 자동으로 지정 됩니다.

 

Router가 기본적으로 가지는 서브 도메인을 지정 해주는 부분 입니다.
이 부분은 프로젝트에서 Application을 배포 했을때 외부에서 접속이 가능 하도록 Router 서버가 서브 도메인을 자동으로 부여 해줄때 필요 합니다.
(위의 DNS 서버 설정 부분에서 나머지 A 레코드를 ‘*’로 사용하였기 때문에 2차 이상의 도메인은 모두 router 서버 IP를 바라보게 되어 있습니다.)

 

내부에서 프록시 서버를 사용하고 있는 환경이라면 지정 해주시면 됩니다. 사용하지 않고 있다면, Enter를 눌러 넘기면 됩니다.

 

설정이 완료 되면 이때 까지 설정한 내용이 간략하게 출력이 됨과 동시에, Host들의 정보를 Gathering 하는 작업이 진행 됩니다.

 

Gathering이 완료 되고 나면 각 서버들의 정보를 출력한 후 해당 정보가 맞는지 다시 한번 확인 하는 부분이 나타납니다.
‘y’를 입력하여 답해 주세요.

 

설정 정보 확인 후 ‘atomic-openshift-installer’ 설정파일과 ‘ansible inventory’ 파일이 root 계정의 ‘.config/openshift’ 디렉토리에 생성이 됩니다.

 

여기서 하던 것을 멈추시고,  ‘ansible inventory’ 파일인 ‘/root/.config/openshift/hosts’ 파일을 에디터로 열어 아래와 같이 추가 해주셔야 설치가 정상적으로 됩니다.

 

이제 ‘y’ 를 눌러 설치를 진행 합니다.

 

설치가 완료 되고 나면 아래와 같은 설치 완료 메세지가 뜨게 됩니다. Enter를 눌러 넘어 갑니다.

OpenShift Origin (Master Node)


Master 서버에서 web console 서버를 통해 사용자가 프로젝트 및 Application을 실행, 배포 할 수 있습니다.
이를 사용하려면 로그인 계정이 있어야 하므로, htpasswd 를 사용하여 가상 사용자를 만들겠습니다.

OpenShift Origin (All Node)


모든 설치를 반영하기 위해서 모든 노드를 재시작 합니다.

 

OpenShift Origin (Master Node)


재부팅이 완료 되고 나면 Master 서버중 하나에 SSH 로 접속하여,
oc 명령어를 통해 router 서버가 default로 등록 될 수 있도록 수정 합니다.

 

정상적으로 반영이 되어있는지 출력 결과를 통해 살펴 보도록 합니다.

OpenShift Origin Web Console


기본적으로 Web Console은 8443 포트를 통해 접속을 합니다.
접속시 주소는 HA 구성시 지정 하였던 ‘openshift.yongbok.net’ 을 통해 접속 하시면 됩니다.

 

– 로그인 화면
web console용 로그인 계정을 사용하여 로그인 합니다. 
openshift_origin_1

 

2. 프로젝트 화면
로그인과 동시에 프로젝트를 만들 수 있는 화면이 반겨 줍니다. ‘New Project’ 를 눌러 생성 해보겠습니다.
openshift_origin_2

 

Name: 사용할 서브 도메인을 말합니다.
Display Name: Web Console에서 보여질 프로젝트 이름 입니다.
Description: 프로젝트의 보조 설명 부분 입니다.
openshift_origin_3

 

3. Application 빌드
예제로 NodeJS를 검색하여 ‘nodejs:latest’를 빌드 해보겠습니다.
openshift_origin_4

 

Name: 서브 도메인으로 사용할 이름 입니다.
Git Repository URL: Dockerfile 이 존재하는 GitHUB 저장소를 뜻합니다.
‘Create’ 버튼을 눌러 빌드를 시작 합니다.
openshift_origin_5

 

상단 ‘Continue to overview’를 눌러 나옵니다.
openshift_origin_6

 

빌드가 진행 되는 중이며, 좀더 자세한 상황을 보도록 하겠습니다.
openshift_origin_7
openshift_origin_8

openshift_origin_9

 

4. Applicaction 배포
가운데 보이는 화샅표를 통해 Pods를 Scale-Up/Down 합니다.

openshift_origin_10

 

생성 된 Pods의 토폴로지도 볼수 있고
openshift_origin_11

 

Pods 정보도 볼수 있습니다.
openshift_origin_12

 

왼편에 “Overview”를 눌러 생성 된 Application의 서브 도메인을 클릭 하면 실제로 접속이 되는 것을 확인 할 수 있습니다.
openshift_origin_13
감사합니다. 🙂

 

Reference


https://github.com/openshift/origin
https://docs.openshift.org/latest/install_config/install/advanced_install.html