PostgresSQL 요약 정리

한눈에 살펴보는 PostgreSQL

CentOS 7 Rails 세팅

rbenv 설치 [ruby, rails]

  • 설치
    • sudo yum update
    • sudo yum install git
    • sudo yum groupinstall -y ‘development tools’
    • sudo yum install -y gcc-c++ glibc-headers openssl-devel readline libyaml-devel readline-devel zlib zlib-devel sqlite-devel
    • sudo yum install -y glibc-devel libffi-devel
    • git clone git://github.com/sstephenson/rbenv.git ~/.rbenv
    • git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
  • 환경 변수 설정

    export PATH=”$HOME/.rbenv/bin:$PATH”
    eval “$(rbenv init -)”

ruby 설치

  • rbenv install 2.3.0
  • rbenv global 2.3.0
  • rbenv rehash
  • ruby -v

rails 설치

  • gem 설치
    • gem install rails
  • postgresql
    • sudo yum install postgresql-server postgresql-contrib postgresql-devel
    • sudo postgresql-setup initdb
    • nano /var/lib/pgsql/data/pg_hba.conf
  • 외부 접속 허용하기 [pg_hba.conf]

    host    all     all     0.0.0.0/0       password #rails와의 연결을 위해 md5로 암호화 설정 local   all             all                                     md5
    host    all             all             127.0.0.1/32            md5

  • 외부 접속 허용하기 2 [postgresql.conf]
    • nano /var/lib/pgsql/data/postgresql.conf

      #listen_address = ‘localhost’ 에서 listen_address = ‘*‘로 수정. # 주석 풀기

  • 계정 생성
    • postgres로 로그인
      • sudo su - postgres 
    • Create a PostgreSQL superuser user with this command (substitute the highlighted word with your own username):
      • createuser -s pguser
    • To set a password for the database user, enter the PostgreSQL console with this command: 
      • psql
    • The PostgreSQL console is indicated by the postgres=# prompt. At the PostgreSQL prompt, enter this command to set the password for the database user that you created:
      • \password pguser
    • Enter your desired password at the prompt, and confirm it. Now you may exit the PostgreSQL console by entering this command: 
      • \q 
    • Now that your PostgreSQL user is set up, switch back to your normal user:
      • exit
  • 방화벽 개방
    • firewall-cmd –permanent –add-port=5432/tcp
    • firewall-cmd –reload
  • redis
    • download & make
      • cd /usr/local/src 
      • wget http://redis.googlecode.com/files/redis-2.4.17.tar.gz
      • tar xvfz redis-2.4.17.tar.gz
      • cd redis-2.4.17
      • make -j4 && make install  -j4
    • install
      • cd utils
      • ./install_server.sh
    • test
      • redis-cli
        • ping
        • PONG [PONG이 안오면 실패]

머신 초기 세팅 [디스크 할당 및 폴더 설정]

  • 디스크 목록 보기
    • fdisk -l
  • 디스크 할당
  • 디스크 초기화 [ext4로 초기화] 아래 디스크3은 nextmv에서 제공해준 디스크가 500gb씩 분리되어있는 3개의 디스크만 사용할 것 이므로.
    • mkfs.ext4 /dev/xvdg1
    • mkfs.ext4 /dev/xvde1
    • mkfs.ext4 /dev/xvdc1
  • ext 폴더 생성
    • cd /usr/local
      • mkdir ext1
      • mkdir ext2
      • mkdir ext3  
  • 디스크 마운트
    • mount -t ext4 /dev/xvdg1 /usr/local/ext1
    • mount -t ext4 /dev/xvde1 /usr/local/ext2
    • mount -t ext4 /dev/xvdc1 /usr/local/ext3
  • db 데이터 복사
    • cp -r /var/lib/pgsql/data /usr/local/ext2
  • 폴더 권한 설정
    • chmod -R 700 /usr/local/ext2
    • chown -R postgres:postgres /usr/local/ext2
  • PGDATA 경로 수정.
    • nano /usr/lib/systemd/system/postgresql.service
    • /usr/local/ext2/data
    • systemctl daemon-reload
    • service postgresql restart
    • 해당 작업 이후에는 설정 파일 경로가 /usr/local/ext2/data 로 바뀌는 점에 유의하자.
  • node.js 설치
    • 필요한 패키지 설치
      • yum install gcc gcc-c++
      • yum install openssl-devel
      • yum install make
      • node.js wget
      • cd /usr/src
      • wget http://nodejs.org/dist/v0.10.22/node-v0.10.22.tar.gz
    • 압축 해제
      • tar zxvf node-v0.10.22.tar.gz
      • cd node-v0.10.22
    • 설치
      • ./configure
      • make && make install
  • 저장소 받아오기
    • cd /usr/share
    • svn checkout svn://[저장소경로] [받아올이름]
  • nginx with thin
    • thin 설정 파일 생성. [서버 10개]
      • thin config -C /usr/share/thin -c /usr/share/web_server –servers 10 -e production
    • 로그 경로 수정.
      • nano /usr/share/thin
      • log: “/usr/local/ext1/log/thin.log” 로 수정.
  • nginx 설치
  • nginx 설정 추가
  • ​주의 : /usr/share/web_server/log 폴더 생성 되어 있어야 nginx service 가동 가능.

    cd /etc/nginx
    mkdir sites-enabled
    nano sites-enabled/thin
    upstream thin {
       server 127.0.0.1:3000;
       server 127.0.0.1:3001;
       server 127.0.0.1:3002;
       server 127.0.0.1:3003;
       server 127.0.0.1:3004;
       server 127.0.0.1:3005;
       server 127.0.0.1:3006;
       server 127.0.0.1:3007;
       server 127.0.0.1:3008;
       server 127.0.0.1:3009;
    }

    server {
       listen 포트;
       server_name 서버이름;

       access_log /usr/local/ext1/web_server/log/access.log;
       error_log /usr/local/ext1/web_server/log/error.log;

       root   /usr/share/web_server/public/;
       index  index.html;

       location / {
           proxy_set_header  X-Real-IP  $remote_addr;
           proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header Host $http_host;
           proxy_redirect off;

           if (-f $request_filename/index.html) {
               rewrite (.*) $1/index.html break;
           }

           if (-f $request_filename.html) {
               rewrite (.*) $1.html break;
           }

           if (!-f $request_filename) {
               proxy_pass http://thin;
               break;
           }
       }
    }
    nano /etc/nginx/nginx.conf
    #맨 끝 } 안에 추가
    include sites-enabled/*;

  • 서버 가동
    • thin -C /usr/share/thin start
  • nginx 재 가동
    • service nginx restart

업무 일지 쓰는 법

저는 불행인지 다행인지, 업무 일지를 강제하는 회사를 다녀본 경험이 없습니다.

대부분의 회사에서의 업무 관리는 redmine이나, 구두로 전달되어온 스케쥴에 의존했죠.

이렇다보니, 개인적으로 업무일지를 작성하기 시작했습니다. 왜냐하면 (다들 아시다시피) 기억력에 의존해서 업무를 진행하기란 한계가 있으며, redmine과 같은 업무 관리 도구로 모든 업무를 관리하고 트랙킹하기란 쉽지 않기 때문이죠.

특히나, redmine과 같은 도구에 (여러가지 이유로)개인적인 감상을 적기 어렵다는 점도 한몫합니다.

결국은 온전한 업무 기록은 개인적으로 따로 관리해야 한다는 건데, 그러다보니 자율적으로 업무 일지를 써왔습니다.

업무 일지의 목적은 히스토리.

업무가 많다보면 자연스레 기록을 필요로 합니다. 이 과정에서, 기록되는 주 공간은 text, 연습장, 메모앱 등등이 되겠죠?

그런 기록의 공간을 업무 일지 기록소 [개인적으로 note류 앱 중, one note, evernote, google docs 모두 사용해보았는데, 장단이 있습니다. 굳이 특정 앱을 사용할 필요는 없습니다.]로 옮겨간다라고 생각하면 편합니다.

업무 일지 요령은, 하루 동안 업무에 관련되어 겪은 일들을 정리하는 과정이라고 보시면 됩니다.

어떤 업무를 진행하는 데에 있어서의 과정을 최대한 많이 기록한다라고 보시면 되요.

특히 과정 [디버깅이건, 타 파트 업무 지원이건, 네트워크 장애건, PC 오류건, 개인 용무건 뭐든간에]을 기록해 업무에 방해되는 요소를 알 수 있습니다.

또는 내가 일을 굉장히 잘하는지 못하는지에 대한 계측 도구로도 사용가능하죠.

업무 일지는 많은 분들이 쓰시는데, 그 중 제가 사용하고 있는 방식에 대해 간략히 보충 설명 할게요.

  1. 월간, 분기간, 연간 리뷰.
    • 리뷰를 하며, 기록한 업무 일지를 재정리 합니다.
  2. 큰 작업별 업무 기록 분리.
    • 해당 업무의 예상 기간과, 실제 진행 기간간에 분리합니다.
    • 주단위를 넘어가는 큰 개발 일정이 연간 생각보다 그다지 많지 않습니다. [많더라도 정리합시다]
    • 작업별로 재정리된 예상 소요시간과, 실제 소요시간의 갭, 오차의 원인등을 같이 남겨서 아카이브합니다.
  3. 병목 지점 파악
    • 회사별로, 동료별로 나의 업무에 영향을 주는 방식,정도가 다릅니다.
    • 이를 파악하는 지표로 분석해야 합니다.
      • 그게 장비나 툴의 문제라면 더더욱 개선해야 합니다.
        • 예를 들어 빌드 내서 테스트 해야되는 작업인데, APK로만 테스트하느라 빌드 시간 10분*20해서, 3시간동안을 빌드에만 사용해서 디버깅 및 테스트를 진행했다라고 하면, 몇가지 접근이 나옵니다.
    • APK 빌드 시간을 단축.
      • 테스트할 기능만 담은 새 프로젝트를 기반으로 테스트해 시간 단축.
    • 자동화 테스트 스크립트 작성

이렇듯 시간을 아낄 수 있는 방법을 통해 생산성을 높여야, 잉여 시간을 만들 수 있습니다.

잉여 시간을 자기 개발 + 업무 개선을 반복함으로써 효율을 높여 개인 시간을 많이 만드시길 빕니다.

이상 간략한 업무 일지 및 정리 방법 요약이었습니다.

윈도우 서버에서 리눅스 서버로의 감상

나는 리눅스 서버가 익숙치 않다.

국내에서의 교육용 내지는 서버 OS로 윈도우 서버를 많이 선택해온 실정도 있었던 터라, 익숙해 질 계기가 부족했던 것도 사실이지만 그렇다고 해도, 내 개인적인 탐구심과 노력이 리눅스가 익숙해지기 까지의 과정에 도달하지 못했던 것도 인정한다.

물론 리눅스로 서버를 운용해본적도 있으며, 가상 머신 내지는 서브 OS 로도 여러번 사용해왔지만, 메인 OS로 사용할만큼, 그리고 업무에 적극 사용할만큼 익숙하지 못했던 건 반성해야 될 부분이라고 생각한다.

윈도우 서버를 개발 해올 때에도, 여러가지 작업을 쉘 기반으로 이전해오며 리눅스처럼 사용하려 노력은 했지만, 막상 리눅스로 서버를 운용할 자신이 쉽게 생기진 않았다.

그러던 중, 이전까지의 메인 서버 언어였던 C++을 대신해, ruby on rails를 이용해 개발하다보니, 어쩔 수 없이 (윈도우 머신에서의 최적화는 무한도전에 가까울 만큼 동작하지 않는 gem이 많다. 딱 개발머신으로써만 사용해야 되는 수준) 리눅스 적응 프로젝트에 돌입했다.

앞에 글에서도 언급했듯 선정한 서버는 cent os다.

리눅스 자체가 오픈소스 정책 기반이다보니 forking 되어 여러가지 OS가 개발되고 있고, 그렇다보니 이제와서는 장단점마저 뚜렷해진 경향이 있었다. 그에 대해서는 아래 블로그를 참조했다.

리눅스의 종류와 선택

리눅스 배포판 - 위키백과

  이 중 cent os를 선택한 계기는 바로 RHEL을 그대로 반영하는 무료 OS라는 점이다. 그리고 fedora의 혁신성과는 반대로 안정성이 높다.(fedora가 잔버그가 많기로 유명하다)

나는 개인적으로 여러번 써왔고 익숙한 ubuntu를 고르려 했으나, cent os를 선택하게 된 계기는 역시나 안정성이었다.

최신 버전의 갱신 주기가 잦고, 패키지가 빠르게 갱신되는 ubuntu에 비해 업데이트는 느리지만 그만큼 안정적인 버전이 도입된다.

이는 패키지 오류로 인한 시행 착오를 줄여주는 핵심 키워드 이기 때문에 cent os를 선택했다.

그렇게 cent os를 세팅하며 장벽에 대한 몇가지 생각이 들었다.

대소문자 구분

  • 으… 윈도우가 편의를 위해 용인해준 것이 결국엔 문제가 됐다.
  • 리눅스에서 개발하고 싶을만큼 발견하는데 시간도 걸리고, 크리티컬 할 수 있는 요소.

쉘 기반으로 사용하는 것에 대한 거부감

  • 다행히 나는 이 부분에선 극복했었던 상황.

패키지 버전 충돌 문제. [예를 들어 rails만 해도 ruby 버전에 따라 다르게 동작함. rbenv에서 버전 강제후 bundle update 해주어야 함]

  • 이 문제에 대한 이해는 윈도우에서도 dll 지옥을 겪어봤다면 납득 가는 문제중 하나일거라고 생각함.

권한 문제

  • 서비스로 구동할때와, daemon으로 구동할때의 권한차이.
  • 헌데 이문제도 윈도우도 같다… 윈도우 서비스로 구동할때와 쉘이나 gui로 구동할 때의 실행 계정과 권한에 차이가 있다.

서버마다 반복되는 세팅 작업

  • 쉘기반이라 이건 그냥 극복이 되는 문제 아닌가?
  • docker를 이용하거나 각종 세팅 스크립트를 짜놓고 구동 시켜도 충분히 해결되는 문제이기는 함.

그래도 가끔 필요하다 싶은 GUI 기반 작업에 대한 고뇌

  • 몇가지 해결책을 제공하고 있는듯 하다. 웹 기반으로 UI를 제공한다거나, port 개방을 통해 GUI 기반 OS에서 원격 제어를 허용하는 등의 방식으로. [postgresql만해도 세팅 후 포트 개방 후, 윈도우에서 제어하면 좀 더 편하게 제어할 수 있다.]
  • 데스크탑 모드로 설치해서 서버로 구동하는 것은 반대. [메모리 사용량만해도 10배 이상 차이나는 경우가 많다. 기본적으로 SSH로만 사용하는 것을 권장한다]

그럼 남는 것은…? 현재 게임 머신으로써의 의미를 제외하고나면, 윈도우 머신을 굳이 써야 할 의미가 없다.

개발 머신 자체가 맥인것도 고민해봤으나, 굳이 프로그래머는 맥일 필요도 없다고 생각한다.

애초에 많은 오픈소스의 기반이 리눅스다.

아니 적어도 서버 머신 하나는 리눅스로 설치해두고, 여러 개발자가 접속해 관리하며 익숙해질 필요는 충분히 있다고 생각한다.

물론 나의 경우만해도, 윈도우 서버로 대체 할 수 없는 개발 플랫폼을 선정했기 때문에 적응된 부분이지만, 적응하고 보니 그 장벽이 그리 높지 않다는 확신이 든다.

우선 생각보다 그리 어렵지 않고, 여러모로 효율적이다. 

특히 스크립트 기반 환경이다보니 자동화를 안하면 극도로 번거로운 작업이 많다. (쉘 명령어를 외워야 한다거나, 특정 프로그램 설치 위치가 중구난방이라 찾기 어렵다거나 하다면 윈도우 서버때보다 훨씬 번거로울 수도 있는 것도 사실이니까) 

하지만 자동화를 해놓으면 윈도우보다 편해지고, 스크립트만 잘 정리하고, 설치위치에 대한 룰만 잘 정하고 사용한다면 엔지니어적으로 잘 관리된 환경을 만나볼 수 있다. (사용하다보면 리눅스가 얼마나 프로그래머스러운 판단들로 내부 시스템을 구성해놓았는지 알 수 있을 것이다.)

이상 윈도우 프로그래머의 리눅스 적응기였다.

CentOS 7 세팅기

나무 위키 CentOS 소개

저는 Ubuntu LTS 버전으로 서비스 하려 했으나… 퍼블리셔 및 주변의 권유로 CentOS로 세팅해서, 서비스 하기로 했습니다.

CentOS에 대한 핵심 정리를 인용합니다.

RHEL의 소스를 기반으로 만들어지며 철저하게 최신 버전의 RHEL을 미러링하는데 중점을 둔다. 단, 상표권은 회사가 가져가는 GPL의 특성상 레드햇의 트레이트 마크와 로고를 그대로 쓸 경우 상표권 분쟁이 있을 수 있기 때문에 레드햇이 소유하고 있는 레드햇 트레이드마크와 로고는 제거, 그리고 그 자리에 센트OS 고유의 로고를 대신 넣으면 완성. 이 때문에 버전도 RHEL과 똑같이 나간다. 덤으로 센트OS에서 말하는 “북미 엔터프라이즈 소프트웨어 벤더”은 레드햇을 지칭한다.

docker를 이용할 수도 있었지만, CentOS에 대한 이해도를 높이는 차원에서 직접 세팅해보았습니다. 그 과정에서의 기록들을 간단하게 공유해봅니다.

CentOS7