http://redmine.nehome.net/redmine/projects/chef/wiki/Install_Chef-Server_010x_on_Ubuntu_1204

Install Chef-Server 010x on Ubuntu 11.04/12.04

• 참조 문서 : http://wiki.opscode.com/display/chef/Installing+Chef+Server+on+Debian+or+Ubuntu+using+Packages
• 지원 배포본 (링크 내용의 목록에는 없으나, 12.04도 지원함.)
  • Ubuntu 11.10 oneiric
  • Ubuntu 11.04 natty
  • Ubuntu 10.10 maverick
  • Ubuntu 10.04 lucid
  • Debian (unstable) sid
  • Debian (testing) wheezy
  • Debian 6 (stable) squeeze
• 설치 과정 요약
1. apt 저장소 등록
2. chef-server 패키지 설치
3. 설치 상태 확인
4. 설정/구성

apt 저장소 등록

• Chef는 현재 세부 기능의 차이로 0.9.x와 0.10.x 2종류로 나뉜다.
• 본 문서에서는 0.10.x를 사용하는 것으로 한다.

apt source.list 등록

• Ubuntu for Chef 0.9.x
  

  echo "deb http://apt.opscode.com/ `lsb_release -cs` main" | sudo tee /etc/apt/sources.list.d/opscode.list
  

• Ubuntu for Chef 0.10.x
  

  echo "deb http://apt.opscode.com/ `lsb_release -cs`-0.10 main" | sudo tee /etc/apt/sources.list.d/opscode.list
  

GPG Key 등록

• 패키지의 무결성 보장을 위해 Opscode GPG키 등록
  

  sudo mkdir -p /etc/apt/trusted.gpg.d
  gpg --keyserver keys.gnupg.net --recv-keys 83EF826A
  gpg --export packages@opscode.com | sudo tee /etc/apt/trusted.gpg.d/opscode-keyring.gpg > /dev/null
  

• (Note) keyserver timeout 에러 발생시 아래 방법을 통해 Opscode로부터 직접 Key를 다운로드.
  

  gpg --fetch-key http://apt.opscode.com/packages@opscode.com.gpg.key
  gpg --export packages@opscode.com | sudo tee /etc/apt/trusted.gpg.d/opscode-keyring.gpg > /dev/null
  

저장소 목록 update 및 Opscode-keyring 설치

sudo apt-get update
sudo apt-get install opscode-keyring

Chef의 원활한 설치를 위해, 라이브러리들을 비롯해 배포본을 최신으로 upgrade

sudo apt-get upgrade

chef-server 패키지 설치

• chef와 chef-server 패키지만으로도 충분하나, web-ui를 필요로 한다면, 확장 패키지들이 필요하다.
• 설치 중, 하기와 같은 입력값을 요구 받을 수 있다.
  • 예) chef-server URL : http://chef.example.com:4000
  • 예) RabbitMQ Password : xxxxxxxxxx

chef-server 설치

• chef-server core 설치
  

  sudo apt-get install chef chef-server
  

  • 상세 수행 내역
    • Install all the dependencies for Chef Server, including Merb, CouchDB, RabbitMQ, etc.
    • Starts CouchDB (via the couchdb package).
    • Starts RabbitMQ (via the rabbitmq-server package).
    • Start chef-server-api via /etc/init.d/chef-server, running a merb worker on port 4000
    • Start chef-server-webui via /etc/init.d/chef-server-webui, running a merb worker on port 4040
    • Start chef-solr-indexer via /etc/init.d/chef-solr-indexer, connecting to the rabbitmq-server
    • Start chef-solr via /etc/init.d/chef-solr, using the distro package for solr-jetty
    • Start chef-client via /etc/init.d/chef-client
    • Add configuration files in /etc/chef for the client, server, solr/solr-indexer and solo
    • Create all the correct directory paths per the configuration files
• web-ui 설치
  

  sudo apt-get install chef chef-server-api chef-expander
  

설치 상태 확인

• 설치가 끝나면 하기 표에 열거된 프로세스들의 작동 상태를 확인 해야 한다.

Chef Server 구성요소 및 응답포트 안내

• Chef Server WebUI는 Chef시스템 운영에서 필수 요소는 아니다. (Optional)
• 혹, Chef Server WebUI가 작동되지 않는다면, /var/run/chef/server-webui.main.pid 파일이 이미 존재해서 일 가능성이 있다. 해당 파일을 삭제하고 다시 Start시도를 해본다.

설정/구성

• 이제부터는 Chef 시스템에서 가장 중요한 "설정/구성"단계로서, Client와 Server간의 식별을 위한 인증서/인증키 생성 및 Chef Server에 대한 설정을 수행해야 한다.
• knife라는 도구를 통해 필요한 값을 입력함으로 자동으로 구성해주는 방법과, 설정 파일을 수동으로 기술하는 방법 2가지 모두 가능.
• 본 가이드에서는 Opscode에서 권장하는 knife 도구를 이용한 정석적 방법으로 설명한다.

Chef 환경 디렉토리 생성

• (Note) Certificates Read Only

mkdir -p ~/.chef
sudo cp /etc/chef/validation.pem /etc/chef/webui.pem ~/.chef
sudo chown -R $USER ~/.chef

knife 도구를 이용한 Chef Server 환경 구성

• knife : Chef-Server의 API 호출을 지원하는 CLI.
• 처음 접하면 난해한 면이 있다.
• Chef-Server입장에서 아무 Client나 Chef-Server의 Role/Recipe를 적용하도록 허용되어서도 안되고, Chef-Client입장에서도 아무 Chef-Server에서 제공되는 Role/Recipe를 받아서도 안되기 때문에 인증 체계가 중요하다.
• 설치후, knife.rb파일에 cookbooks 디렉토리 경로를 지정하는 설정을 추가한다.
  • cookbook_path [ "/var/lib/chef/cookbooks" ]

knife configure -i
> WARNING: No knife configuration file found
> Where should I put the config file? [/root/.chef/knife.rb] 
> Please enter the chef server URL: [http://ubuntu:4000] http://localhost:4000
> Please enter a clientname for the new client: [root] 
> Please enter the existing admin clientname: [chef-webui] 
> Please enter the location of the existing admin client's private key: [/etc/chef/webui.pem] /root/.chef/webui.pem
> Please enter the validation clientname: [chef-validator] 
> Please enter the location of the validation key: [/etc/chef/validation.pem] /root/.chef/validation.pem
> Please enter the path to a chef repository (or leave blank): 
> Creating initial API user...
> Created client[root]
> Configuration file written to /root/.chef/knife.rb

• WARNING: No knife configuration file found
  • 최초 구성시 Chef Server 설정 파일(knife.rb)이 없어서 생기는 경고.(무시)
• Where should I put the config file? [/root/.chef/knife.rb]
  • knife.rb 파일의 위치 입력
• Please enter the chef server URL: [http://ubuntu:4000]
  • Chef Server 호출 URI 입력
• Please enter a clientname for the new client: [root]
  • 새로운 Client 하나를 생성. (불필요하면 추후 삭제 가능할 듯...)
• Please enter the location of the existing admin client's private key: [/etc/chef/webui.pem]
  • 이미 존재하는 관리용(admin) Client의 pem 파일 위치 입력
• Please enter the validation clientname: [chef-validator]
  • chef-validator라는 client는 특별한 계정으로서, 신규 노드의 자동등록을 위해 사용된다.
• Please enter the location of the validation key: [/etc/chef/validation.pem]
  • chef-validation client용도의 pem 파일 위치 입력
• Please enter the path to a chef repository (or leave blank):
  • Chef 저장소에 대한 위치 입력 (Defautl 유지)

설정/구성 상태 확인 테스트

• 복수의 Client를 생성(개별 인증/pem 운영)하여 Chef시스템을 운영 할 수도 있다. 관련 내용은 도입부의 참조 문서 내용에 상세히 기술되어 있음.
• 본 문서는 chef-validation.pem 하나로 Chef-Client를 등록/식별하는 용도로 작성되었으므로, Client 에게 배포할 인증서는 validation.pem이다. (보안 문제가 있을 수 있다. 검토중...)

• Client 목록 조회 테스트
  

  knife client list
  > chef-validator
  > chef-webui
  > root
  > ubuntu
  

• Node 목록 조회 테스트
  

  knife node list
  > ubuntu
  

[END] Chef-Sever 구축 완료.

최근, Chef로 서비스 구성(Configuration) 자동화 파트를 다시 하게 되었다. 여기저기 타 부처 수행 인력과 협업도 해야 하는 상황이라, 가상화 인프라부터 논의를 통해 결정을 지어야 할 일이 많다... 서비스 구성에는 Hadoop Cluster, MySQL & Replication, Cassandra, MongoDB, HAProxy LB, Apache/Tomcat, 등등 여러가지 서비스들이 버튼 한번의 클릭으로, 동적 구성 및 동작이 되어야 한단다. (쉽게 이야기들 한다...쿨럭...) 이러한 일련의 자동화 구성/배포 전략 수립단계에서 여러사람들끼리 혼선도 있고, 의견 충돌이 있는 것은 당연하다. 왜? 정답이 없는 거니까~ ㅡ.ㅡㅋ 사실 이 섹션의 고민은 Cloud라는 단어가 국내에서 화자 되기전, RIS라는 OS 원격 설치 서비스를 구축 할 때에도 심각하게 고민됐었다... "과연 어느 선까지 사전에 설치 해두는 것이, 유연성과 편의성 두마리 토끼를 다 잡을 수 있을까?"...라는.... 결국 그 당시에는 지금의 Chef나 Puppet만큼 완성도 있는 도구가 없다는 핑계를 대며 일정에 쫓겨 최대한 밀어넣기(?)로 쫑친 기억이....

아무튼 그 중, 가장 어정쩡하게 결론이 난 것이 어떤 방식의 Template를 사용하냐~였다. 이참에 그 사항에 대해 정리를 나름대로 해두고 싶어 일단 펜을...아니 키보드를 두드려 둔다. 물론 서두는 없다. 생각 나는대로.. 우선...

PaaS, SaaS... 당연히 밑바탕이 IaaS라 불리는 가상화 서버스가 "반드시" 필요 한 것은 아니다. 그러나 즉시성, 그리고, 자원의 효율적 활용(이 부분도 아직 갈길이 멀기만 하지만...), 유연한 인프라 관리 체계(이 말도 참 귀에 걸면 귀걸이인 마케팅용...)라는 진부한 이야기들 외에 본 글에서는 오로지 Physical 인프라와 비교해 상대적으로 설치/구축이 쉬운 점을 감안하여 "필수적"이라는 가정하에 이야기를 풀어 볼 생각이다... (물론 이 말에는, 가상화를 위한 Physical 인프라는 이미, 그리고 부족함 없이 구축되어 있다는 대전제가 깔려 있어야....쿨럭..ㅡ.ㅡ;;)

여기서 논점의 주제는 뭐냐.....

아니면,

뭐가 좀 더 좋은 선택이냐~ 하는 것....

음.. 경험상 개인마다, 또 환경마다 호불호가 갈렸던 것 같다. 

이후 말하고자 하는 것은... 일반적 또는 보편적으로 봤을때에는 "2) OS-Only Image" 방식을 사용하는 것이 유리하다...라는 것에 대해 이유를 정리 해볼려고 한다... 물론 전혀 현실성 없는 이야기로 보일 수도, 틀린 이야기일 수 도 있는 사견일뿐....

참 Template에 대한 용어 정리 부터 하자...

자 그럼, 1)번의 경우, Hadoop이든, Cassandra든 뭐가 됐던, 모든 S/W, 관련 패키지, 라이브러리, 데이타 모두 사전에 각각에 대해 Template이미지를 미리 만들어 두어야 한다. 잘 이해가 안된다고? 아래 [그림1]을 보라.

[그림1]

(그림 설명)

- 가운데 점선은 Template으로부터 사용자에게 배포되는 경계를 나타냄. 일반적으로 Chef/Puppet가 담당.

지원하는 OS는 3종류로 가정한다. SuSe/RedHat/Ubuntu...

그리고, 지원하는 서비스로는 Hadoop/MySQL/Cassandra/Tomcat/HAProxy/Apache/GlusterFS 이정도로 7가지가 서비스할 계획이라고 치자...

• OS플랫폼 : 3가지
• 서비스 종류: 7가지

따라서, 3*7=21 가지로서, 21개의 Template이미지를 사전에 확보/관리 되고 있어야 한다.

물론 생성 이후에 적용된 고유정보나, 설정은 Chef나 Puppet와 같은 Auto-Configuration 툴을 사용한다는 것을 전제로 한다.

Pre-Installed Template 방식의 장점은 아래와 같다.

(본 글과 연관이 있는 항목 위주)

• 설치/설정 작업에 필요한 소요시간 제거/단축.
• 요소 패키지의 버전 Upgrade등으로 인한 설치/설정 중 발생 가능한 오류 제거.
• 설치/설정 과정을 거친, 즉 작동이 검증된 이미지임을 보장.

위와 같은 이점을 누릴 수 있다. 이중에서도 1)번 방식을 주장하는 사람들이 가장 강하게 내세우는 점은 첫 번째 서비스 배포에 소모되는 "시간단축"이었다.

자, Pre-Installed Template이미지가 가지는 단점이 있겠으나, 아래 내용은 2)번 방식인 "OS-Only Template"방식을 살펴보고 비교해보는 것으로 충분할 것이다.

2번) 방식을 도식화한 [그림2]을 보자.

[그림2]

그림 2는?

Virtual VMs 영역은 "Pre-Installed Template"방식과 다를게 없다. 그러나, 아래 쪽 Template영역은 아주 딸랑 3개로 심플하다.

자, Pre-Installed Template 방식과, OS-Only Template방식을 간략히 살펴 보면 이와 같이 "일장일단"이 있다.

나름 가상화라는 파트를 접하면서 겪어오고 싸우기도 한 이 문제...

결국 논쟁의 핵심은(단, 국내 가상화 일선 현장에서이다.) 아래의 것들 이었다.

이러한 이유로 인해, 99%는 1)번 Pre-Installed Template 방식을 도입/적용 하는 것으로 가닥이 잡힌다. 설령 그것의 단점을 인지하고 있더라도...(최근에야 Chef나 Puppet의 비중을 높이려는 시도가 많이 보이나 쉽지는 않은듯 하고...)

아무튼, 이것은 단기적으로 봤을때는 충분히 설득력이 있고, 또 실제로 효과도 만점이다.

서비스 로직과 Web-UI연동, 빌링, 요구사항에 부합하는 서비스가 정상적으로 사용가능한지가 단기적인 프로젝트상 Output으로서 중요하지, Provisioning과정에서 생기는 시행착오나, 오류로 시간을 허비할 수는 없는 환경도 한 몫을 하고 있는 것 같다.

그러나 장기적으로 봤을 때, 덮어 두었던 문제들이 일순간 터져버리는 지뢰밭을 키우는 꼴이 될 확률이 대단이 높다.

왜?~~

1) 배포 소요 시간. 이것 부터 살펴 보자...

실제로 Hadoop, Apache, Cassandra 등등이 미리 설치 했을 때에 비해, 그때 그때 Instant하게 설치가 된다면 분명히 시간은 더 걸리겠으나, 과연 얼마나 더 소모될까? 10분? 아니면 1시간?.... 별의 별 S/W를 다 동적 Provisoning해봤지만, 어지간 해서는 3분을 넘기는 Provisioning을 필요로 하는 서비스는 굉장히 드물다....

(여담이지만, 이미지 복사하는데 훨씬 시간이 많이 걸린다... 왜? "Backing-File" 방식을 사용하지 않고, 10GB짜리를 그대로 10GB 통으로 복사를 하니..... 차라리 이런 시간을 줄이는게 훨씬 비용효율적일 것이다.) 

2) 버전 관리의 복잡성

음... 이 문제는 기술적 의견차가 큰것도 있지만, 커뮤니케이션 부족이 한 몫을 한 것 같다.

이 부분을 지적한 사람들이 주로 주장하는 내용이, "apt-get이나, yum등의 버전이 수시로 바뀌고, 관련 conf 패턴도 바뀌어 문제가 많이 발생하더라. 설치 과정도 어렵고 하니 한번만 고생해서 만들어 두면 편하지 않느냐..." 이었다. 음... 틀린 말은 아니다. 그러나 미안한 말이지만, 이 부분은 전적으로 "관리 능력"의 부재로 인한 핑계일 뿐이다.

이유는, 이 이슈를 Pre-Installed Template방식에서는 더 Critical하게 접하게 될 이슈이기 때문인다. 무슨 말인지 이해가 잘 안된다고? 어느 서비스도 마찬가지겠지만, Cloud라는 이름이 붙은 서비스에서 특정 Version으로 Static하게 패키징된 Template으로 1~2년 서비스를 할 수는 있다고 치자. 패치/업그레이드가 다반사로 일어나는 Cloud관련 솔루션들인데, 그렇게 버텼다고 치자. 훗날 업그레이드는 어떻게 수행할 것인가? 안할 것인가? 한다면, 전체 다 할 것인가? 아니면 기존 이미지 27개(앞선 예를 기준)템플릿은 별개로 운영하고, 신버전의 동일 서비스의 Template이미지들을 또 추가하여 54개의 Template으로 운영할 것인가? 그러면 언제부터 사용한 서비스냐에 따라 기술지원 방식이나 메뉴얼, 대응팀 운영을 개별적으로 가져갈 것인가? 문제는 시간이 가면 갈수록 걷잡을 수 없는 악순환에 빠지고 만다.

결국 핵심 이야기는 이것이다. "현재 작은 문제로 인해 발생한 상황을 해결 하지 못하는데, 그 문제들이 누적되고 쌓인 미래의 상황은 해결이 가능할 것인가?" 하는 것이다.

아래 [그림3]을 보면서 이 항목에 대해서는 마무리 하자.

개발에서도 통용되는 오래된 그림이고 이야기이다. 버그나, 이슈에 대한 패치의 양과 주기에 대한 비교 그림이다.

왼쪽그림은 패치 주기가 길고, 한번에 패치하는 버그/이슈의 양이 많다.

반면에, 오른쪽은 패치 주기가 짧고, 버그/이슈의 양도 적다. 그만큼 한번의 패치 작업 때 변경되는 코드 양이 작고, 만에 하나 발생할 잠재위험(Risk)도 작다.

어느 것이 유리한가? 답은 굳이 말하지 않아도 자명할 것이다.

[그림3]

3) 배포 실패 가능성.

음.. 이부분은 2)번 "관리의 복잡성"의 내용과 중복되는 부분이 많다.

실제 Pre-Installed Template방식에 비해, OS-Only Template 방식이 가지는 핸디캡이기도 하다. 다시말해 Chef나 Puppet와 같은 Auto-Configuration 툴의 역할과 비중이 증대되어 미션크리티컬한 시스템 수준으로 올라가게 된다. 모든 것을 배포하고, 설정하고, 조율하고, 심지어 모니터링/관제 까지.. 그만큼 Auto-Configuration 시스템의 운영/관리가 철저히 되어야 하고, 만에 하나 장애나 오동작시, 전체 시스템에 어떠한 피해가 올지 모를 양날의 검과 같은 존재다. "잘 쓰면 이롭지만, 잘 못 쓰면 해가 되는..."

이러한 툴들이 수행되는 과정에서 발생 가능한 오류는 S/W버전의 상이함, 배포 로직상의 오류, 툴 자체적인 SPOF구조, 등이 대다수다. 심지어 일부 Network구간 단절로 Configuration 시스템은 멀쩡함에도 배포 실패가 발생할 수 있다. 그러나 이러한 Risk는 Pre-Installed Template방식도 동일하게 내포하고 있는 문제이다. 단지, OS-Only Template방식에 비해, 수행 과정이 적다 보니, 발생 가능성이 상대적으로 낮을 뿐이지... 따라서 이 이슈는 어떤 방식이든 "관리/운영 능력의 문제"일 뿐이다. 고민은 하되 호불호를 따질 필요는 없을 것이다.

정리~

"선택은 자유다............."

(여담) 그런데 이이야기를 깡그리 무너뜨릴 수 있는 것은, "왜? 여러 OS플랫폼에 똑같은 서비스를 사용해요? 하나만 정해서 서비스 해요~!!" 라고 하면....ㅡ.ㅡ;;

이상,,, 할 일 없는 일요일 저녁... 머리속에서만 맴돌고 정리가 안되던, 그래서 더욱 주관적인 이야기.... 글로 끄적여도 여전히 만족할만큼 정리는 되지 않았으나, 대충 어렴풋했던 그림도 서너장 나왔고, 앞으로 계속 다음어 나가야 할 글임을 다시금 되뇌이며 오늘은 이만....