[배포] 애플리케이션 PostgreSQL 배포(초간단버전)

애플리케이션 배포

PostgreSQL

앞선 포스트에서 초간단 버전으로 로컬에 오픈시프트를 설치해 보았다.

이번 포스트에서는 간단한 애플리케이션 배포로 PostgreSQL을 배포해 볼 것이다.

오픈시프트에서 제공하는 DB 템플릿은 보통 ephemeral과 persistent 두 가지를 제공하는데 이 둘은 다음과 같은 차이가 있다.

Ephemeral

DB 데이터를 영구 저장하지 않는다. 즉 컨테이너가 삭제되면 데이터는 모두 소실된다. 임시 데이터, 일회성 데이터 등 저장, 또는 테스트 용으로 사용할 것을 권장한다.

Persistent

PV(Persistent Volume)을 연동하여 DB 데이터를 영구 저장한다.

현재 오픈시프트 3.3 에서는 PostgreSQL community 버전 9.2, 9.4, 9.5(latest)를 기본으로 제공하고 있다(상용버전인 EDB의 PPAS - Postgres Plus Advanced Server 는 제공하지 않는다).

웹콘솔을 사용한 배포

웹콘솔 로그인

참고

테스트 환경은 htpasswd 기반의 인증으로 구성되어 있다(그럴 것이다).

계정 생성은 앞선 내용에서 이미 다루었으며 간략하게 아래 명령으로 계정을 추가할 수 있다.

마스터 노드에서

# htpasswd -b <htpasswd 파일 경로> <계정> <패스워드>

ex)

# htpasswd -b /etc/origin/master/htpasswd timegate timegate

미리 주어진 계정으로 웹콘솔에 로그인한다.

프로젝트 생성

최초 로그인하면 성의없는  welcome 화면과 함께 New Project를 생성하라고 나온다.

New Project 를 클릭하고 생성할 프로젝트 정보를 입력한다.

주의!!

프로젝트 명은 나중에 생성된 애플리케이션을 웹으로 노출시킬 경우 FQDN을 조합하는데 사용되므로 프로젝트 명을 정할 때는 서비스할 도메인 명을 미리 고민해서 정하는 것이 좋다(나중에 따로 지정할 수도 있다).

애플리케이션 생성 -  Postgresql ephemeral 템플릿

프로젝트를 생성하면 빈 프로젝트이기 때문에 바로 애플리케이션 카탈로그 화면으로 넘어간다. 기본적으로 오픈시프트에서 제공되는 애플리케이션 목록(템플릿)이 나열된다.

이중 DB관련 템플릿을 보면 다음과 같다.

• mariadb-ephemeral
• mariadb-persistent
• mongodb-ephemeral
• mongodb-persistent
• mysql-ephemeral
• mysql-persistent
• postgresql-ephemeral
• postgresql-persistent

먼저, ephemeral 템플릿을 사용해서 만들어 보도록 한다. postgresql-ephemeral를 클릭하면 애플리케이션 정보(템플릿변수)를 입력하는 창으로 넘어간다.

입력하는 내용은 템플릿에 지정되어 있으며 입력칸의 * 표시는 필수 입력 항목이다. postgresql의 경우 다음과 같은 값을 입력할 수 있다.

• Memory Limit - 컨테이너가 사용할 수 있는 최대 메모리 크기(Mi)
• Namespace - 네임스페이스는 프로젝트라고 보면 된다. 여기서 입력할 값은 도커 이미지가 등록된 네임스페이스인데 일반적으로 공용으로 사용되는 이미지스트림은 모두 openshift 프로젝트에 등록이 되어 있으므로 특별한 경우가 아니면 대부분 openshift(기본값)를 사용하면 된다.
• Database Service Name(*) - 오픈시프트에 표시되는 애플리케이션 이름으로 오픈시프트가 외부에 노출시킬 서비스의 이름이다.  동일한 프로젝트(네임스페이스) 안에서 유일해야 한다.
• PostgreSQL Connection Username(*) - 데이터베이스 사용자 계정으로 필수 입력값이지만 입력하지 않을 경우 자동 생성된다.
• PostgreSQL Connection Password(*) - 데이터베이스 사용자 패스워드로 필수 입력값이지만 입력하지 않을 경우 자동 생성된다.
• PostgreSQL Database Name - 생성될 DB 명으로 기본값은 sampledb이다.
• Version of PostgreSQL Image(*) - 사용할 PostgreSQL 버전이다. 기본값은 최신버전(latest)인 9.5이다. PostgresSQL의 경우 9.2, 9.4, 9.5(또는 latest) 셋 중에 선택할 수 있다.

필요한 값을 입력한 후 Create 버튼을 클릭한다.

Continue to overview를 클릭하여 Overview 화면으로 넘어간다. 진행이 빠르게 넘어가 캡쳐를 뜨지 못했지만 애플리케이션 프로비저닝은 다음 절차로 이루어진다.

1. deploy pod 생성 - deploy pod 애플리케이션을 배포하기 위해 만들어지는 컨테이너로 애플리케이션 배포가 끝나면 사라진다. deploy pod가 노드에 배치되는 과정에서는 Overview의 pod 원 표시가 흰색(색이 없음)이다.

2. application pod 생성 - deploy pod 가 애플리케이션 pod(실제 서비스 할 postgresql 컨테이너)를 생성한다. 이 때 Overview의 pod 원 표시는 회색으로 표시된다.

3. application pod 초기화 - 애플리케이션 pod가 정상적으로 노드에 배치되고 초기화(postgresql의 경우 DB 및 계정 생성 등 작업)하면 Overview의 pod 원 표시는 하늘색으로 표시된다.

4. application pod 서비스 시작 - 애플리케이션 pod의 초기화가 끝나고 서비스가 시작되면 Overview의 pod 원 표시는 파란색으로 표시된다. 이후 deploy pod는 자동으로 삭제된다.

Pod 정보 확인

위 화면에서 pod 아이콘을 클릭하거나 아래 Applications->Pods 메뉴에서 생성된 pod를 클릭하면 pod 상세 화면이 나온다.

생성된 pod 상세화면에는 다음과 같은 다섯 개의 탭이 있다.

Details - pod의 상세 정보. 상태, 할당된 OpenVSwitch IP, pod가 실제로 배치된 물리 노드(서버장비) 등의 정보가 표시된다.

Environment - pod에 주어진 환경변수 값으로 pod를 생성할 때 사용된 docker 이미지가 받는 값이다.

Logs - pod의 terminal out 로그이다.

Terminal - 컨테이너에 bash 쉘로 접속한다. 여기서 기본적인 Linux 명령어 또는 컨테이너가 가지고 있는 유틸리티를 사용할 수 있다.

Events - pod 이벤트 목록이다.

DB에 접속하여 DB 작업 수행

이제 실제로 DB에 접속하여 서비스를 확인한다. 접속하는 방법은 pod 상세 화면에서 Terminal 메뉴를 통해 컨테이너에 직접 bash로 접속하는 방법과 외부에서 pqsql 클라이언트를 사용하여 붙는 방법이 있는데 후자의 경우는 별도로 외부에서 접속할 수 있도록 서비스를 오픈하는 과정이 필요하므로 이 포스트에서는 생략하고 첫번째 방법으로 접속해 본다.

참고

외부에서 오픈시프트 클러스터 내의 서비스로 연결하는 방법은 다음과 같다.

1. route 객체를 만들어서 http/https로 expose 하는 방법 - 웹 애플리케이션에서 사용

2. service 객체에서 spec type을 NodePort로 지정하거나 externalIPs를 지정하여 외부로 오픈할 IP 또는 포트를 지정 - tcp 통신에 사용

PostgreSQL같은 DB의 경우 http/https 통신을 하지 않고 TCP 로 통신하므로 2번 방법을 사용해야 오픈시프트 클러스터의 외부 네트워크에서 접속이 가능하다. 이 설정 방법은 다른 포스트에서 다루도록 한다.

Applications->Pods->[생성된pod]->Terminal 탭을 선택하면 아래와 같이 bash 쉘 프롬프트가 동작한다. Linux 터미널과 거의 동일하며 다만 docker 이미지 경량화를 위해 모든 Linux 패키지가 설지되지 않았을 수 있기 때문에 모든 명령어가 동작하지는 않는다(예를 들어 ping 명령은 안됨).

다음 명령어를 입력하여 DB동작을 확인한다.

sh-4.2$ psql

다음과 같이 psql 클라이언트가 DB에 접속하고 postgresql 프롬프트가 대기한다.

이제부터는 DB 명령어를 입력하여 테이블을 생성하고 데이터를 입력해 본다.

\c sampledb                                                          --> sampledb 에 접속

create table test_tbl ( username varchar(50), userid varchar(50));   --> test_tbl 테이블 생성

insert into test_tbl values ( 'test', 'test' );                      --> test_tbl에 레코드 1개 insert

select * from test_tbl;                                              --> test_tbl 조회

결과

DB 데이터 파일시스템 확인

마지막으로 실제로 어떤 위치에 DB 데이터가 생성되었는지 확인한다. PostgreSQL 프롬프트에서 \q 를 입력하면 bash로 돌아간다. bash 프롬프트에서 df -h 명령으로 현재 컨테이너의 파일시스템을 확인한다.

가독성이 조금 떨어지지만 웹콘솔에서 제공하는 터미널은 이게 한계이다.. 좀더 가독성이 좋은 환경에서 해보고 싶다면 직접 노드 서버에 접속하여 docker 명령으로 컨테이너에 접속하면 동일한 테스트를 할 수 있다. 찾아보기 바란다.

더욱 안타까운 것은 사용한 템플릿이 ephemeral이라... df로 쳐 봐야 DB 데이터 파일시스템이 보이질 않는다... 즉 별도로 마운트된 파일시스템이 아니어서 root 파일 시스템의 어딘가에 포함되어 있기 때문이다. 나중에 persistent 에서 df 결과과 비교해 보길 바란다.

그냥 아래 경로에서 확인해 보길 바란다. 아래 경로에 userdata라는 디렉토리가 존재하면 이것이 postgresql의 기본 DB 테이블스페이스 저장경로이다.

cd /var/lib/pgsql/data

Postgresql Persistent 템플릿 사용

PV(persistent volume)를 사용하는 방법으로 오픈시프트에서는 크게 다음과 같은 방식의 PV 생성 방안을 제공한다. 현재 OpenShift Cluster Administration Guide에는 NFS 방식만을 설명하고 있으며 다른 방식은 개발 중이거나 tech preview로 레드햇의 기술지원을 받아야 할 것으로 보인다.

• NFS mount 
• SAN Storage
• iSCSI
• Ceph RDB - 3.4에서 dynamic provisioning 기능이 추가되었다.
• GlusterFS - 3.4에서 dynamic provisioning 기능이 추가되었다.
• AWS Elastic Block Stores(EBS)
• OpenStack Cinder - 3.4에서 dynamic provisioning 기능이 추가되었다.
• GCE Persistent Disk

이번 포스트에서는 NFS(유일하게 테스트 해볼수 있는....) 로 PV를 생성하여 적용해 볼 것이다. 

사전준비사항

NFS를 사용하려면 당연히 NFS 서비스가 되어야 할 것이다. 테스트 환경에서는 master 노드에 NFS 데몬을 구동하여 서비스 하기로 한다. 아마도, 이미 NFS 서비스를 위한 기본 패키지는 설치가 되어 있을 것이다. 확인하는 방법은 다음과 같다.

NFS 서비스 확인

master 노드에서

# rpcinfo -p

결과가 아래와 같이 portmapper 와 nfs 등 서비스가 구동되고 있으면 NFS를 사용할 수 있다. 만약 안되어 있다면.. 인터넷에서 필요한 패키지를 찾아 설치하기 바란다(portmap, nfs-utils).

NFS 설정

공유 디렉토리로 사용할 디렉토리를 생성한다. 여기서는 /root/mnt 아래 pv0100 부터 pv0105 까지 디렉토리를 생성한다.

주의!!

NFS로 PV를 생성하려면 반드시 다음과 같은 조건을 가져야 한다. PV로 사용될 디렉토리(상위 디렉토리까지)는

1. nfsnobody:nfsnobody 소유

2. 777 권한

ex) /root/mnt 에서

# chown -R nfsnobody:nfsnobody .

# chmod -R 777 .

마지막으로 /etc/exports파일을 아래와 같이 편집하고 nfs 서비스를 재시작한다.

[root@oramaster mnt]# cat /etc/exports

/root/mnt/pv0100 *(rw,sync,no_root_squash)

/root/mnt/pv0101 *(rw,sync,no_root_squash)

/root/mnt/pv0102 *(rw,sync,no_root_squash)

/root/mnt/pv0103 *(rw,sync,no_root_squash)

/root/mnt/pv0104 *(rw,sync,no_root_squash)

/root/mnt/pv0105 *(rw,sync,no_root_squash)

[root@oramaster mnt]# systemctl restart nfs

PV 객체 생성

master 노드에서 오픈시프트 클러스터가 사용할 PV객체를 생성한다. 아쉽게도 PV 객체에 대한 명령은 CLI로만 제공된다. 우선 PV 정보를 담은 yaml 파일을 생성한다.

[root@oramaster yaml]# cat pv0100.yaml

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv0100

spec:

  capacity:

    storage: 1Gi

  accessModes:

  - ReadWriteOnce

  nfs:

    path: /root/mnt/pv0100

    server: oramaster.ora01000.pe.kr

  persistentVolumeReclaimPolicy: Recycle

• name : PV 객체 이름
• storage : PV의 크기
• path : NFS 서버의 /etc/exports 에 정의된 경로
• server : NFS 서버 주소

주의!!

PV 정보에 따라 pod 가 직접 NFS 경로를 컨테이너에 마운트하므로 PV를 실제로 사용할 pod 가 배치되는 노드(서버)상에 NFS의 export 경로가 마운트되어 있을 필요가 없다.

생성된 yaml 파일로 PV객체를 생성한다.

system:admin 계정에서

# oc create -f pv0100.yaml

결과

애플리케이션 생성

애플리케이션 생성은 postgresql persistent 템플릿을 사용하는데 ephemeral과 한가지 차이가 있다. 

• Volume Capacity - DB데이터 저장소 공간의 크기를 지정한다. 이 값은 미리 생성된 PV 객체의 Capacity와 비교하여 사용자가 요구하는 Volume Capacity에 맞는(보다 큰) PV를 선택하도록 한다. Volume Capacity에 적합한 PV 가 없다면 애플리케이션은 프로비저닝 되지 않는다.

여기서 PV는 1Gi 로 생성되었으므로 Volume Capacity 역시 1Gi 보다 작게 요청되어야 한다.

Create 버튼을 눌러 애플리케이션을 생성한다.

생성 확인

Ephemeral과 차이점은 Storage 메뉴에서 확인할 수 있는데 Persistent Volume Claim이 생성된다는 것이다. Volume Claim은 애플리케이션이 PV를 사용하기 위해 공간을 요청하는 것이며 이 클레임이 유지되어야 pod가 재생성되어도 동일한 PV를 찾아갈 수 있다.

참고

PVC(Persistent Volume Claim)은 기본적으로 capacity에 적합한 어떤 PV도 사용할 수 있다. 즉 PV를 미리 많이 만들어 놓았을 때 capacity 조건만 맞으면 어떤 PV를 사용할지 모른다는 뜻이다. 이를 피하고자 한다면 템플릿에서 어떤 PV를 사용할지를 지정해야 한다.

PVC가 할당된 PV는 아래와 같이 Available에서 Bound 상태로 표시된다.

Persistent Volume Mount 확인

웹콘솔의 terminal에서 df 명령으로 확인해 보면 컨테이너 상에 oramaster.ora01000.pe.kr:/root/mot/pv0100 경로가 /var/lib/pgsql/data 로 마운트 된 것을 확인할 수 있다. 앞서 ephemeral 에서의 컨테이너 파일시스템과 비교해 보기 바란다.

--끝--