( younjin.jeong@gmail.com , 정윤진 ) 

( younjin.jeong@gmail.com , 정윤진 )

최근 클라우드가 부각되면서 자연스럽게 이슈가 되고 있는 것이 바로 자동화된 인프라스트럭처의 구성이다. 이미 지난번에 CHEF-101 코드를 통해서 한번 소개 한 적이 있는데, 이렇게 다시 소개하게 된 데에는 여러가지 이유가 있지만 일단 요모 조모 사용해 본 결과 아주 쉽게 시스템을 빌드 할 수 있고, 루비 기반으로 작성된 코드의 적응 시간도 매우 짧아 그 사용이 매우 편리함에도 불구하고 국내에서는 아직 넓게 사용되지 못하고 있는게 안타깝기 때문이다.

물론, 예전부터 사용하던 고전적인 cfengine 과 같은 툴 또는 상용이라면 IBM 의 Tivoli 를 기반으로한 z/OS 시스템 오토메이션을 필두로 각종 시스템 자동화를 모토로 하는 다양한 가격의 상용 시스템 자동화 툴이 있다.  이 툴들의 특징은 하나같이 써먹기가 어렵거나, 또는 설정의 변경이 용이하지 않은 시스템 관련 업무 그 자체의 특수성 등으로 인해 도입이 쉽지 않은 것이 사실이다.  또한, 일부 대규모의 호스팅 업체 또는 수백, 수천의 서버를 동일 목적으로 구현할 필요가 없다면 굳이 열대 스무대 돌리는 업장에서 시스템 관리자 섭외도 쉽지 않을 진데 자동화야 당연히 소원할 수 밖에 없다.

현실이 비록 이렇다 할 지라도, 엔터프라이즈 레벨의 인프라 또는 각종 대기업 환경, 대규모 HPC 클러스터 및 클라우드 인프라에서는 자동화를 빼고서는 할 말이 없다. 자동화가 가져다 주는 BOX (서버) 자체의 서비스에 대한 Plug & Service 및 Hot swap 의 특혜는 5대의 서버만 구성하게 되더라도 어마어마 한 것이다.  하물며 수천대의 서버를 항상 가동시키거나, 또는 계속 deploy 해야 하는 상황이라면 이런 자동화 툴은 아니라도 적어도 OS 이미지 복사 또는 자동 설치 CD 정도는 만들어서 사용해야 하는게 정신건강 및 관리에 이롭지 않겠는가.

이런 경우도 생각 해 볼 수 있다.  수백/수천여대의 서버가 위치한 센터가 어떠한 이유로 사용 불가능 하게 되었을 경우, 동일한 용도의 시스템군을 다시 빌드 해야 한다고 하면 과연 당신이 지금 운용중인 서비스는 몇일이 소요되겠는가.
전통적인 방식으로 생각 해 보면,  ( 적어도 배포서버는 있는 경우 ) 하드웨어 및 네트워크 구매, 설치, 케이블링 시간을 제외하더라도 십수여일 또는 IP 변경으로 인한 개발팀등과의 확인/연동이 필요한 경우 길면 수개월도 걸릴 수 있다.
이러한 경우 공통적으로 적용 할 수 있는 자동화 툴이 있다면, 케이블링이 끝난 시점에서 적어도 수시간 내에는 완전히 다른 지역에 서버의 deploy 가 가능하며, 이때 신경써야 할 것은 오로지 DB 데이터의 무결성과 같은 크리티컬 한 부분일 뿐이다.

이런 자동화 툴의 필요성에 대해 이미 인지하고 계실진대 굳이 졸린 눈 부벼가며 영 어색한 문장으로 다시 끄적이는 이유는 Chef 만 보거나 또는 시스템/서비스를 미시적 관점에서 접근하게 되면 결국 이런게 왜 필요하게 되었는지를 모른 채 시스템 변경 사항이 발생 될 때마다, "아 이거 그냥 적용하면 되지 뭘 이렇게 만들어 놓았나" 하는 생각을 떨칠 수 없을지도 모르지 않겠나 하는 노파심 때문이라 치자.  ( >.< )  어차피 내 블로그 내맘... ;;;


우야 둥둥 잡설이 길었다.  본론으로 들어가자면,

다음과 같은 쇼핑몰 서버를 오픈 소스 솔루션을 통해 가상화 또는 실제 물리적 서버군으로 구성했다 치자. 싸니깐. ;;

- 웹 서버 몇 대.
- 웹 어플리케이션 서버 몇 대.
- 결재 전용 서버 두어 대.
- 이미지 전용 서버 몇 대.
- 데이터 베이스 서버 또는 서버 군.
- 웹 서버 또는 웹 어플리케이션 서버 간 세션 공유를 위한 memcached / repcached 서버 두어 대.
- 웹 소스 및 이미지 공유를 위한 NAS 두어 대.
- 로그 및 모니터링 서버

쇼핑몰 잘 나가나 보다. ;;;

뭐 어쨌든, 위와 같은 서버군을 생각 해 보았을때 오픈 소스로 구성한다면 대충 필요한 패키지는 다음과 같으시겠다.

- nginx / lighttpd   :  이미지 또는 단순 파일 배포 서비스  또는 reverse proxy
- httpd ( apache2 ) / php5 / resin / web logic / zeus :  java, php 등을 사용하는 각종 어플리 케이션 중 1종. (물론 일부는 오픈소스 아님 ㅋ )
- nexenta 또는 opensolaris 기반 또는 일반 리눅스의 NFS 
- repcached
- mysql / PostgreSQL , 돈 많거나 DB구조, SQL 구리면  Oracle RAC
- L4 를 사지 못할 정도로 가난할 경우 LVS / ipfwadm  /  heartbeat
- 방화벽을 구매하지 못할 정도로 가난한 경우 iptables 및 openvpn
- rsyslog / nagios
- notification sms 발송 솔루션 ( 이건 업체에서 제공하는걸 쓸 밖에. 일본에서는 폰메일이 있으므로 postfix 로 쉽게 가능 ㅠㅠ )
- notification email 발송 솔루션
- 가상화로 구성하는 경우  Xen 꽁짜/상용 서버 또는 vSphere , 또는 kvm
 

리소스를 대충 늘어놓고 보니 수량이 좀 된다. 하지만!  우리가 필요한 또는 많은 업체에서 사용하는 대부분의 오픈 소스들이 전부 들어있다.  오픈소스 많이 없다고 걱정 안해도 된다.  구성도를 그려서 올리면 더 좋을텐데, 그건 나중에 하겠다.  집에서 쓰는 맥에 구성도 그릴 만한 툴이 대략 없다. ㅠㅠ

자, 원래는 chef 로 간단히 파일 생성 및 패키지 설치만 보여줄려고 했는데 일이 너무 커져 버렸다.  모른다. 오늘 다 못쓰면 내일 써도...;;  어차피 구성도나 그림도 없... ;;;


Chef 를 자동화 툴로 사용하기로 했다면, 또는 Chef 이외의 것들까지 생각해 보자면, 다음과 같은 계획을 준비해야 된다.

1. pxe boot 및 dhcp 등을 굴려서 쌩 하드웨어에 자동으로 OS 를 올릴 것인가.
2. Chef 를  Server - Client 모델로 굴릴 것인가 Chef-solo 를 사용 할 것인가.

서버 수량의 증가 가능성이 거의 없거나 또는 매우 드물어 관리자가 OS 설치를 재미로 해도 된다면 굳이 OS 자동 설치까지는 신경쓰지 않도록 한다.  이건 나중에 화학 계산을 위한 PC GMESS 를 사용한 HPC 클러스터용 마스터 노드 제작때 보여주기로 한다.  역시 대규모가 되어서 MAC 주소가 걔가 뭐였더라 할 정도 아니면 Chef 도 서버 클라이언트는 필요 이상으로 복잡 해 질 수 있다.  그래도, 하는게 하지 않는 것보다는 좋으려나. 보안 이슈도 있으니깐.

1번을 무성의 하게 지나쳤으므로, 순식간에 chef 단계로 넘어간다.  이때 결정해야 할 사항은 다음과 같은것들이 있다.

1. 각 서버는 어떤 용도로 활용 될 것 인가. ( Role 정의 )
2. 각 용도에는 어떠한 패키지가 필요할 것인가. ( Cookbook listup )
3. 각 서버는 서로 자주 사용되어야 할 Attribute 가 있는가. (  예를 들면, mysql 패스워드 또는 모든 서버에서 참조 될 수 있는 ssh rsa 키  또는 서버 패스워드 등 )

1번 및 2번은 위에 열거한 서버 리소스별로 다음과 같이 정리 될 수 있겠다.

Role :  webserver ,  proxy_server , image_server , db_master , db_slave , log_monitor , session , nfs_master , nfs_secondary , billing , web_application

음.. 꽤 많다.  자 이제 필요한 요리책을 펴 보면,

Cookbook :  http , nginx , mysql , rsyslog , nagios , repcached , nfs , bill, php5 ( was 는 이것으로 한다 ) , iptables , common ( 모든 서버에서 셋업 되어야 하는 공통 사항 )  , pgsql , openvpn , heartbeat , lvs

처음 접하시는 분들은 당삼 그런 생각 들꺼다.  이게 다 뭐야?  그런 생각이 드신 분들은 다음의 내용을 주시한다.

* chef 는, 기본적으로 각 호스트별로 지정된 role 을 호출하여 서버를 구성한다.
* role 은  cookbook 의 조합으로 구성되며, Cookbook 하위에는 해당 패키지를 서비스에 맞게 설정하기 위한 각종 리소스가 포함된다.  recipe , attribute , file, template , metadata 등의 리소스는 관리자에 의해 생성, 변경 되어 입맛에 맞게 구성이 가능하다.

물론, 서비스 구성에는 이러한 조건 이전에 다음과 같은 계획이 수반 되어야 할 것이지만, 여기서는 내가 대충 정한다.

- ip 및 네트워크 구성 계획
- nfs 마운트 디렉토리 위치
- 방화벽 및 vpn access 구성 계획
- DNAT 또는 SNAT 사용 여부
- 로드 밸런싱 및  용도별 이중화 계획
- 각 하드웨어 스펙 또는 가상화 서버 스펙


좋다.  다 끝났다. 

이미 시간이 밤 12시를 가르키고 있으므로,  실제 chef 코드의 작성에 대해서는 다음호에 계속...;;; 하기로 한다.
아마 3부작 정도 되지 않을까 싶다.  이런 장기 포스팅 약한데..



급하신 분들을 위해 직접 삽질이 고픈 분들 께서는 다음의 링크들을 참고 하신다.

* chef : http://wiki.opscode.com/display/chef/Home , http://www.opscode.com/
* http : http://httpd.apache.org/
* lvs  : http://www.linuxvirtualserver.org/
* repcached , memcached : http://repcached.sourceforge.net/ , http://memcached.org/
* iptables : http://www.netfilter.org/ 
* postgresql :  http://www.postgresql.org/
* nginx :  http://wiki.nginx.org/Main

나머지 php 나 mysql 등은 원체 많이 접하실 걸로 예상되어 별도의 링크는 읍다.
다음회에는, chef server 설치 및 client 설정,  실 코드 작성 및 github 를 통해 코드를 업로드 하도록 하겠다.

아 물론, 쇼핑몰 서비스를 위한 "인프라" 만을 다루며 실제 몰 서비스를 위한 코드는 알아서 해결 하시도록 한다.
난 웹 개발자가 아니니깐 ㅠ   음... 현희형이랑 준호형을 섭외 해 볼... ;;;   솔루션 하나 나올기세 ㅋ


( younjin.jeong@gmail.com , 정윤진 )

( younjin.jeong@gmail.com , 정윤진 )


세월은 빠르게 흘러, 시스템 관리에도 고전적인 perl / python 과 같은 언어를 제치고 ruby 가 등장하게 되었다.
Chef 라고 하면 이미 나온지 그렇게 오래 된 툴은 아니지만, 그렇다고 얼마 되지 않은 것도 아니다.
이 글을 쓰게 되는 것도 번역이나 샘플 코드 조사를 통한 기본적인 동작의 이해를 위한 것임을 미리 밝히며, 시스템 자동화를 구현 할 수 있는 이런 툴을 개발하고 또 미리 알아내어 접하는 분들에게 새삼 놀랄 따름이다.

우분투에서의 ruby 인스톨은 아주 쉬운 과정으로 이루어 지며, 이거 왜 안되 할 만한 부분이 있어 별도로 소개한다.
( 우분투에서는 gem update --system 을 지원하지 않는다.  패키지 매니저로 처리 하라는 친절한 시스템사마의 설명 )

# sudo apt-get install ruby rubygem
# sudo gem install ohai chef       

하다 보면 여기서 에러를 줄줄이 뱉어 낼 것이다.  에러를 살펴보면, extconf.rb:1:in 'require': no such file to load - mkmf 라는 에러 메세지 인데, 결국 extconf.rb 는 ruby-dev 패키지를 참조하기 때문에 이 패키지를 설치 하지 않으면 정상적으로 동작하지 않는다.  따라서,  정상적으로 진행하기 위해서는

# sudo apt-get install ruby-dev

해 준다.  이후 다음의 링크에서 제공하는 Chef 를 시작하는데 안성맞춤인 내용을 따라하는데 우분투로 충분 할 것이다.

이제부터 설명할 내용은 다음의 링크에서 가져왔다.
http://brainspl.at/articles/2009/01/31/cooking-with-chef-101


Cooking with Chef 101

Chef 의 가장 매력적인 점은 확장 및 축소가 매우 쉽다는 점이다.  처음 시작할 때는 chef-solo 로 쉽게 시작하고, 이후 필요에 따라 chef-client 나 chef-server 를 통해 원하는 대로 구현이 가능해 진다. Chef 로 작성한 동일한 recipe 를 가지고  웹 서버, 데이터베이스, 어플리케이션 , couchdb 서버 및 기타 등등의 거의 모든 서버에 대한 수평적 확장이 가능하다.
구체적 설명은 됬고, 일단 간단한 recipe 를 통해 rubygem 의 일부 패키지를 설치 해 보기로 한다. 그리고, chef 가 베이스 시스템을 구성한 이후에 간단한 디렉토리 설정과 어플리케이션을 배포 해 보도록 하겠다 .

일단 chef-101 의 코드를 GitHub 로 부터 가져온다.

# git clone git://github.com/ezmobius/chef-101.git

Chef 를 설치한다. ( root 계정 또는 sudo )

# gem install chef ohai  --source http://gems.opcode.com  --source http://gems.rubyforge.org

( 일부 패키지 의존성 문제로 인해 rubygem 이 gems.opcode.com 에 의해 서비스 받고 있음에도 불구하고 rubyforge 를 소스로 추가해 주는 것이 좋다.  Rubygem 은 그런식으로 동작한단다. )
여기까지 준비 되었으면 이제 실행시켜 보면 된다.  ( 이 단계는 일부 디렉토리 생성 및 어플리케이션 들을 인스톨 하기 때문에 원치 않으면 넘어가도 관계 없다. )

실행하기전,  config/dna.json 의 user 설정을 변경 할 필요가 있다.  소스에는 'ez'로 되어있을 것이나, 시스템에 나와 같이 'ez' 계정이 없다면 변경 해 주는 것이 좋다.

# cd chef-101
# chef-solo -l debug -c config/solo.rb -j config/dna.json

엄청나게 많은 메세지들이 줄줄이 올라가는 것을 볼 수 있는데, 처음부터 대부분의 메세지는 시스템 output 컬렉터인 ohai 가 수집한 정보들이다.  이는 recipe 에서 수행하는 모든 내역을 알려주며, 정상적으로 종료 된 경우에는 다음과 같은 내용을 보여준다.

INFO: Chef Run complete in 1.09344323 seconds

여기까지 나왔다면 요리를 잘 했다고 볼 수 있다.   이제 이 Chef 가 어떤 식으로 동작하는지 알아 볼 필요가 있다.
먼저,  dns.json 을 보면,

{
  "apps": [
    "beast",
    "mephisto"
  ],
  "user": "ez",
  "gems": [
    {
      "name": "rake",
      "version": "0.8.3"
    },
    {
      "name": "tmm1-amqp",
      "source": "http://gems.github.com",
      "version": "0.6.0"
    }
  ],
  "recipes": ["main"]
}

이는, 내가 JSON DNA 라고 부르는 recipe 세트다.  이는 노드에 설치할 것들에 대한 레시피로, 코드 안에서 어플리케이션 이름, 사용자 명 등을 찾아 볼 수 있다.

시스템으로의 엔트리 포인트인 main 으로 지정된 recipe 를 보면,

include_recipe 'gems'
include_recipe 'applications'

template "/data/someservice.conf" do
  owner node[:user]
  mode 0644
  source "someservice.conf.erb"
  variables({
    :applications => node[:apps]
  })
end

include_recipe 로 필요한 recipe 를 순차적으로 호출하는 것을 볼 수 있는데, 이는  호출 순서에 따라 필요한 레시피가 동작하도록 설정 할 수 있게 하기 위함이다.  만약 다른 레시피를 먼저 구동하고 싶으면, 그 레시피를 다른 것보다 먼저 호출 하도록 한다.

자, 우리는 gem 레시피 이후 application 레시피를 호출하고, 이후 일부 디렉토리 작업을 수행 하는 것을 볼 수 있다. 이 이후작업에서 우리는 쉽게 템플릿을 정의하고, 네이밍 하여 해당 템플릿이 가져야 하는 속성의 정의를 구현하는 것을 볼 수 있다. 
이제, gem 레시피를 보자.

node[:gems].each do |gem|
  gem_package gem[:name] do
    if gem[:version] && !gem[:version].empty?
      version gem[:version]
    end
    if gem[:source]
      source gem[:source]
    end
    action :install
  end
end

여기서 우리는 loop 를 돌려가며 dna.json 에서 정의 되어 설치할 각 gem 의 버전을 가져오는 것을 볼 수 있다. Gem 은 버전과 소스를 가질 수 있으나, 주의할 점은 비어있으면 설정하지 않아야 한다. 버전을 정의하지 않으면 가장 최신의 버전을 가져오게 될 것이며, 소스를 지정하지 않으면 rubyforge.org 에서 가져오게 될 것이다. 
결국 마지막 줄에, 우리는 action :install 으로서 각 gem 에 대한 인스톨을 수행한다. 이는, 시스템에 이미 해당 gem 이 설치 되어 있으면 다시 설치하지 않는다.

자 이제 application recipe 를 보면,

directory "/data" do
  owner node[:user]
  mode 0755
end

node[:apps].each do |app|

  cap_directories = [
    "/data/#{app}/shared",
    "/data/#{app}/shared/config",
    "/data/#{app}/shared/system",
    "/data/#{app}/releases"
  ]

  cap_directories.each do |dir|
    directory dir do
      owner node[:user]
      mode 0755
      recursive true
    end
  end

end

먼저 우리는 /data 디렉토리를 생성하고 원하는 권한을 할당한 이후, json 에 명시한 owner 로 디렉토리를 설정하는것을 볼 수 있다. 이후 루프를 돌면서 필요한 디렉토리 생성 등 모든 액션을 취한다. 

보는 바와 같이 비교적 간단하게 chef-101 코드는 종료된다. 매우 간단하지만 보기 쉽게 로직을 설명하고 있어서, Chef 를 시작하는 엔트리 포인트로는 나쁘지 않을 것이다.


여기까지 날림 번역.


Chef 는, 상상할 수 있는 시스템 설정의 모든 부분에 관여 할 수있다.  각종 daemon 의 동작에 필요한 설정 파일 부터,
필요한 패키지의 설치 또는 웹 서버들의 컨텐츠 배포, Mysql 의 복제 구성까지도 모두 가능하다.

ruby 라는 언어를 먼저 습득할 필요는 있지만, perl 이나 python 중 둘중 하나에 엑스퍼트가 아니어서 하나를 배워야 한다면 루비를 적극 추천하며, 두가지 언어 모두를 알고 있는 사람에게도 Chef 는 좋은 툴이 될 수 있을 것이다.



( younjin.jeong@gmail.com , 정윤진 )