Tagged: 리눅스

AWS Kinesis

이 글은 AWS Kinesis 이 무엇인지에 대한 개념적인 글입니다.

다음의 자료를 기반으로 작성되었습니다.

  1. Introducing Amazon Kinesis (SlideShare)
  2. Introduction to Amazon Kinesis (Youtude)

Big Data

인터넷의 발전으로 인해서 하루에도 계산하기 힘든 데이터가 쏟아집니다. 과거와는 달라진 이러한 환경을 우리는 간단히 Big Data 시대라고 하지요. 어찌보면 과거에도 Big Data 는 있었지만 요즘과 구별되는 것은 누구든지 Data 를 생산할 수 있다는데에 있습니다. 그러다보니  과거와는 다르게 쏟아지는 데이터를 분석해서 유의미한 데이터를 뽑아내는 기술이 필요하게 되었는데 이게 바로 Big Data 의 진정한 의미 중에 하나 입니다.

누구나 생산해내는 데이터들을 유의미한 의미의 정보로 가공해내는 것이 바로 Big Data 기술이라고 할 수 있습니다.

Batch VS Streaming

과거 이야기를 좀 더 해보면, 과거에도 데이터를 분석해내는 방법이 있었습니다. 첫번째로는 데이터를 모우는 겁니다. 그리고 그것을 특정한 저장소에 저장을 합니다. 대부분 데이터베이스시스템에 저장을 했습니다. 그리고 그것을 이용해서 쿼리문을 이용해서 데이터를 뽑아 냈습니다.

그런데, 데이터를 모으고 데이터베이스에 저장하고 하는 부분은 특정 시간에 서버에 작업을 걸어놓아하는 경우가 많았습니다. 간단하게는 리눅스 시스템에서 크론(Cron) 을 이용해서 특정 배치 프로그램을 돌려서 데이터를 모우고 데이터베이스에 집어넣는 방법을 이용했지요.

하지만 Big Data 시대에 이 방법이 과연 유용한가 하는 문제가 있습니다. 몇분, 몇시간, 몇일간격으로만 배치작업을 돌리는건 쏟아지는 데이터 속도보다 빠르지 못하다보니 데이터분석을 할 수 없는 경우가 많습니다. 설사 분석을 해낸다고 해도 이미 시간이 많은 흐른뒤라서 시의성을 가지지 못하는 정보가 될 겁니다.

그래서 등장한 것이 스트리밍(Streaming) 입니다. 스트리밍, 물 흐르듯 그때그때 데이터를 분석해내면 유용한 정보를 얻기위해서 기달릴 필요가 없을 겁니다. 그때 그때 분석한 데이터를 데이터베이스에 저장하거나 파일로 저장하는것도 가능합니다.

그래서 현대의 Big Data 분석 소프트웨어들은 전부다 Streaming 을 지원하도록 발전되어 왔습니다.

현대의 BigData 구조
현대의 BigData 구조

많은 소프트웨어들이 이렇게 데이터 수집, 분석처리, 저장, 분석 및 리포트 영력으로 나뉘어 발전되어지고 있습니다.

위 그림에서 문제가 하나 있습니다. 데이터 수집 부분과 데이터 처리부분 입니다. 이 부분이 문제가 되는 이유는 데이터 수집하는 소프트웨어와 처리하는 소프트웨어간의 데이터 교환을 맞춰줘야 하고 둘이 동기화 되어 처리되어야 합니다. 어느 한쪽이 병목이 생기면 문제가 생길 수도 있습니다.

AWS Kinesis

AWS Kinesis 는 데이터 수집구간과 데이터 처리구간 중간에 위치합니다. 이렇게 중간에 위치하는 소프트웨어를 만든 이유는 다양한 데이터들을 수집하고 이것을 다양한 포맷으로 만들어 줍니다.

Kinesis 를 이해하는데 헷깔리는게 있는데, Kinesis 가 ‘스트리밍 데이터 처리’ 를 해준다는 것입니다. 여기서 스트리밍 데이터 처리라는 말은 스트리밍으로 데이터를 분석해준다는 이야기가 아닙니다.

다양한 형태로 들어오는 데이터를 가공해서 다양한 분석 소프트웨어가 사용가능하도록 다양한 출력물을 만들어내주거나 데이터 저장소에 저장하도록 해줍니다.

기본의 Streaming 처리
기본의 Streaming 처리

기존의 Streaming 처리구조 입니다. 수많은 다양한 데이터들이 들어오고 이것을 처리하는 가공하고 분석하는 도구들이 붙어 있습니다.

AWS Kinesis
AWS Kinesis

AWS Kinesis 는 다양한 데이터들을 빠르게 가공해줍니다. 그리고 이러한 데이터들은 다양한 포맷으로 출력줌으로써 다양한 소프트웨어서 사용해주게 해줍니다.

다어그램으로 표현하면 다음과 같습니다.

AWS Architecture
AWS Architecture

AWS Kinesis 는 다양한 입력 데이터와 출력을 해줍니다.

AWS Kinesis Sending & Reading Data from Kinesis Streams
AWS Kinesis Sending & Reading Data from Kinesis Streams

Amazon 에서는 Kinesis 를 다음과 같이 설명하고 있습니다.

Amazon Kinesis는 완전관리형 스트리밍 데이터 서비스입니다. 수십만 개의 소스에서 클릭 스트림, 애플리케이션 로그, 소셜 미디어와 같은 다양한 유형의 데이터를 Amazon Kinesis 스트림에 지속적으로 추가할 수 있습니다. 그러면 몇 초 안에 Amazon Kinesis 애플리케이션에서는 스트림의 해당 데이터를 읽고 처리할 수 있습니다.

“Amazon Kinesis 스트림에 지속적으로 추가할 수 있습니다” 이 말의 의미를 잘 생각해본다면 이것이 무엇인지 감을 잡을 수 있을 겁니다.

SaltStack 시작하기.

이 글은 SaltStack 시작하기 에 관한 글입니다.

SaltStack 은 자동화 시스템 관리 프로그램입니다. 서버의 설정파일, 패키지 관리, 시스템 명령어등을 한번에 많은 서버에 할 수 있습니다. Chef, Puppet 등과 동일합니다. 단지 이 녀석은 Python 으로 개발이 되었고 역활을 지시하는 sls 파일 문법이 YAML 이며 Jina Template 을 이용해서 sls 에 프로그래밍을 할 수 있습니다.

SaltStack 은 서버와 클라이언트로 모델입니다. 서버역활을 담당하는 SaltStack 을 마스터(Master)라고 하고 클라이언트 역활을 담당하는 SaltStack 을 하녀(Minion)이라고 부릅니다. 마스터의 경우 파일 전송을 할 수 있게 파일서버역활도 같이 합니다.

마스터, 하녀 역활로 나뉘어 있기 때문에 당연히 하녀가 어느 SaltStack 마스터에 지시를 받을것이지 하는 등록절차가 필요합니다.

Master 설치

설치 환경은 CentOS 를 기준으로 합니다. CentOS 의 경우에 Base Repository 에 SaltStack 패키지가 없습니다. 하지만 Epel Repository 를 설치하면 간편하게 Yum 명령어로 설치할 수 있습니다.

salt-master 설치
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
[root@master ~]# yum install salt-master
Dependencies Resolved
 
================================================================================================================================================
Package                                             Arch                   Version                                Repository              Size
================================================================================================================================================
Installing:
salt-master                                         noarch                 2015.5.3-3.el6                         epel                   965 k
Installing for dependencies:
PyYAML                                              x86_64                 3.10-3.1.el6                           base                   157 k
libyaml                                             x86_64                 0.1.3-4.el6_6                          base                    52 k
m2crypto                                            x86_64                 0.20.2-9.el6                           base                   471 k
openpgm                                             x86_64                 5.1.118-3.el6                          epel                   165 k
pciutils                                            x86_64                 3.1.10-4.el6                           base                    85 k
python-babel                                        noarch                 0.9.4-5.1.el6                          base                   1.4 M
python-backports                                    x86_64                 1.0-5.el6                              base                   5.5 k
python-backports-ssl_match_hostname                 noarch                 3.4.0.2-4.el6.centos                   extras                  13 k
python-chardet                                      noarch                 2.2.1-1.el6                            base                   230 k
python-crypto                                       x86_64                 2.0.1-22.el6                           base                   159 k
python-jinja2                                       x86_64                 2.2.1-2.el6_5                          base                   466 k
python-msgpack                                      x86_64                 0.4.6-1.el6                            epel                    69 k
python-requests                                     noarch                 2.6.0-3.el6                            base                    95 k
python-six                                          noarch                 1.9.0-2.el6                            base                    28 k
python-urllib3                                      noarch                 1.10.2-1.el6                           base                   101 k
python-zmq                                          x86_64                 14.3.1-1.el6                           epel                   467 k
salt                                                noarch                 2015.5.3-3.el6                         epel                   4.1 M
yum-utils                                           noarch                 1.1.30-30.el6                          base                   110 k
zeromq3                                             x86_64                 3.2.5-1.el6                            epel                   338 k
 
Transaction Summary
================================================================================================================================================
Install      20 Package(s)
 
Total download size: 9.4 M
Installed size: 34 M
Is this ok [y/N]: y
Downloading Packages:
(1/20): PyYAML-3.10-3.1.el6.x86_64.rpm                                                                                   | 157 kB     00:00
(2/20): libyaml-0.1.3-4.el6_6.x86_64.rpm                                                                                 |  52 kB     00:00
(3/20): m2crypto-0.20.2-9.el6.x86_64.rpm                                                                                 | 471 kB     00:00
(4/20): openpgm-5.1.118-3.el6.x86_64.rpm                                                                                 | 165 kB     00:00
(5/20): pciutils-3.1.10-4.el6.x86_64.rpm                                                                                 |  85 kB     00:00
(6/20): python-babel-0.9.4-5.1.el6.noarch.rpm                                                                            | 1.4 MB     00:04
(7/20): python-backports-1.0-5.el6.x86_64.rpm                                                                            | 5.5 kB     00:00
(8/20): python-backports-ssl_match_hostname-3.4.0.2-4.el6.centos.noarch.rpm                                              |  13 kB     00:00
(9/20): python-chardet-2.2.1-1.el6.noarch.rpm                                                                            | 230 kB     00:01
(10/20): python-crypto-2.0.1-22.el6.x86_64.rpm                                                                           | 159 kB     00:00
(11/20): python-jinja2-2.2.1-2.el6_5.x86_64.rpm                                                                          | 466 kB     00:00
(12/20): python-msgpack-0.4.6-1.el6.x86_64.rpm                                                                           |  69 kB     00:00
(13/20): python-requests-2.6.0-3.el6.noarch.rpm                                                                          |  95 kB     00:00
(14/20): python-six-1.9.0-2.el6.noarch.rpm                                                                               |  28 kB     00:00
(15/20): python-urllib3-1.10.2-1.el6.noarch.rpm                                                                          | 101 kB     00:00
(16/20): python-zmq-14.3.1-1.el6.x86_64.rpm                                                                              | 467 kB     00:00
(17/20): salt-2015.5.3-3.el6.noarch.rpm                                                                                  | 4.1 MB     00:00
(18/20): salt-master-2015.5.3-3.el6.noarch.rpm                                                                           | 965 kB     00:00
(19/20): yum-utils-1.1.30-30.el6.noarch.rpm                                                                              | 110 kB     00:00
(20/20): zeromq3-3.2.5-1.el6.x86_64.rpm                                                                                  | 338 kB     00:00
------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                           789 kB/s | 9.4 MB     00:12

대략 20여개의 의존성 패키지들과 함께 설치됩니다. 앞에서 말했듯이 Salt 는 Python 으로 제작되었기 때문에 Python 관련 패키지가 많이 필요합니다.

Salt 마스터 설정.

설정파일은 /etc/salt/master 입니다. 아주 많은 옵션들이 존재하고 각 옵션마다 자세한 코멘트가 있어 어렵지 않게 필요한 것들을 설정할 수 있습니다.

기본적인 설정은 대략 다음과 같습니다.

/etc/salt/master
INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
interface: 0.0.0.0
user: salt
pidfile: /var/run/salt-master.pid
root_dir: /
pki_dir: /etc/salt/pki/master
cachedir: /var/cache/salt/master
timeout: 60
minion_data_cache: True
state_top: top.sls
renderer: yaml_jinja
state_verbose: True
state_output: full
file_roots:
  base:
    - /srv/salt
fileserver_backend:
  - roots
pillar_roots:
  base:
    - /srv/pillar
log_file: /var/log/salt/master
log_level: debug
log_level_logfile: debug

위 설정만으로도 Salt 마스터는 잘 동작합니다.

Salt minion 설치하기

역시 CentOS 환경이고 Epel Repository 를 추가해서 Yum 을 이용해서 설치하면 됩니다.

salt 하녀 설치.
Shell
1
[root@node1 ~]# yum install salt-minion

설치가 완료되면 /etc/salt/minion 파일에 설정을 하면 됩니다.

Salt minion 설정.

설정파일 /etc/salt/minion 을 열어서 다음과 같이 기본적인 설정을 해줍니다.

/etc/salt/minion
INI
1
2
master: 192.168.96.12
id: minion1

id 설정이 중요합니다.

/etc/hosts 파일 설정.

리눅스의 hosts 파일을 마스터와 Minion 양쪽 모두에 설정해 줍니다.

/etc/hosts
INI
1
2
192.168.96.12  master
192.168.96.15  minion

Salt Minion 을 마스터에 등록하기

Salt 마스터는 Minion 을 등록해서 그 리스트를 유지하고 있습니다. Minion 이 마스터에 등록되어 있지 않다면 마스터로부터 그 어떠한 작업 지시를 받을 수 없겠죠. 그래서 새로운 Minion 이 생긴다면 먼저 마스터에 등록을 해줘야 합니다.

등록은 마스터에서 다음과 같이 합니다.

salt-key 리스트
Shell
1
2
3
4
5
6
[root@master salt]# salt-key -L
Accepted Keys:
Denied Keys:
Unaccepted Keys:
minion1
Rejected Keys:

마스터와 minion 간에 통신이 된다면 위와같이 “Unaccepted Keys” 에  아직 등록하지 않은 minion 이 나옵니다.

등록은 다음과 같이 합니다.

등록이 되었다면 minion 과 통신이 잘되는지 다음과 같이 확인해 봅니다.

위와같이 나오면 정상입니다.

서로 다른 RabbitMQ 버전으로 Cluster 구성 테스트.

RabbitMQ 는 인기있는 메시지 브로커 입니다. 비동기 메시지를 다루는데 있어서 RabbitMQ 는 많이 사용되어 집니다. 거기다 RabbitMQ 는 여러 RabbitMQ 를 하나로 묶는 Cluster 기능을 제공합니다. 그런데, 언제나 그렇지만, 서로다른 RabbitMQ 버전끼리 하나로 묶을 수 있을까하는 의문이 들었습니다. 테스트를 해보았습니다.

환경 세팅

master, slave 라 불리는 2개의 서버를 준비했고 각각 3.5.4 버전과 3.1.5 버전을 설치했습니다. 모든 버전은 Epel 저장소에서 RPM으로 설치를 했습니다.

그리고 다음과 같이 RabbitMQ 를 설정했습니다.

  1. master 의 쿠키 파일를(/var/lib/rabbitmq/.erlang.cookie) slave에 복사했습니다.
  2. 양쪽모두 호스트네임을 /etc/rabbitmq/rabbitmq-env.conf 에 지정해줬습니다.
    INI
    1
    NODENAME=rabbit@master

결과

결과적으로 RabbitMQ 는 서로다른 버전으로 Cluster 를 구성할 수 없습니다.

Shell
1
2
3
[root@slave rabbitmq]# rabbitmqctl join_cluster rabbit@master
Clustering node rabbit@slave with rabbit@master ...
Error: {inconsistent_cluster,"Rabbit version mismatch: local node is 3.5.4, remote node 3.1.5"}

버전이 맞지 않는다고 에러를 냅니다.

혹시나 Master 버전이 Slave 버전보다 낮아서 그런가 싶어서 거꾸로 해봤습니다. (Slave 버전이 Master 버전보다 높습니다.) 즉, 버전이 낮은 RabbitMQ Node 를 높은 버전의 RabbitMQ Node 로 묶어보자는 거였는데 그것도 안됐습니다.

Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[root@master rabbitmq]# rabbitmqctl join_cluster rabbit@slave
Clustering node rabbit@master with rabbit@slave ...
Error: {{case_clause,
            {{error,
                 {aborted,
                     {function_clause,
                         [{mnesia_schema,cs2list,
                              [{cstruct,schema,set,[],
                                   [rabbit@minion1],
                                   [],0,read_write,false,[],[],false,schema,
                                   [table,cstruct],
                                   [],[],[],
                                   {{1441,272826,996460},rabbit@minion1},
                                   {{2,0},[]}}]},
                          {mnesia_schema,do_merge_schema,1},
                          {mnesia_tm,apply_fun,3},
                          {mnesia_tm,execute_transaction,5},
                          {mnesia_schema,schema_coordinator,3}]}}},
             [rabbit@minion1]}},
        [{rabbit_mnesia,change_extra_db_nodes,2},
         {rabbit_mnesia,init_db,3},
         {rabbit_mnesia,init_db_and_upgrade,3},
         {rabbit_mnesia,init_db_with_mnesia,4},
         {rabbit_mnesia,join_cluster,2},
         {rpc,'-handle_call_call/6-fun-0-',5}]}

이 메시지는 아마도 데이터베이스 스키마가 달라졌기 때문에 안되다는 오류 메시지로 보입니다.

RabbitMQ 통계 보기.

RabbitMQ 는 AMQP 를 지원하는 Message Queue 프로그램 입니다. 여러 솔루션에서 함께 쓰이고 있는 매우 인기있는 프로그램입니다.

언제나 그렇지만 RabbitMQ 또한 각종 통계자료를 제공 합니다. 이를 통해서 RabbitMQ 건강상태를 체크할 수 있습니다. 이 문서는 이에 대해 간략히 다룹니다.

RabbitMQ Statistics
RabbitMQ Statistics

통계정보를 보는 방법으로는 CLI 를 통해서 볼 수도 있지만, 웹을 통해서 GUI 환경에서 쉽게 볼수 있습니다. 이를 위해서는 GUI Management Plugin 을 활성화해줘야 합니다.

RabbitMQ Management Plugin Enable
Shell
1
sudo rabbitmq-plugins enable rabbitmq_management

이렇게 하면 웹브라우저를 통해서 RabbitMQ 를 관리할 수 있으며, 간략한 통계정보를 볼 수 있습니다. 이 통계정보를 이해하기 위해서는 Message Broker 에 대한 짧막한 지식이 필요합니다.

Global Counts

전역적인 통계자료 입니다.

Connections

Message Broker 에 TCP 접속을 한 개수 입니다. 그냥 간단하게 RabbitMQ 에 접속한 개수를 말합니다.

Channels

RabbitMQ 는 Channel 이라는 개념을 사용합니다. Connection 내에 존재하는 것으로 가상 커넥션이라고 불리기도 합니다. 이것은 애플리케이션이 다중의 접속을 요구하는 경우에 하나의 TCP Connection 으로 접속을  Multiplex 해주어 접속량을 획기적으로 줄여줍니다.

따라서 하나의 TCP Connection 에 여러개의 접속이 이루어질 수 있어 이 수치는 Connections 개수보다 많이 나올 수 있습니다.

Exchanges

이것은 단일 생산자-소비자 구조에서 생산자-다중 소비자 구조시에 중간에 생산자의 메시지를 분배해주는 역활하는 Exchanges 개수를 말합니다. Publish/Subcribe 패턴에서 나옵니다.

Publish/Subscribe Pattern
Publish/Subscribe Pattern

Queues

메시지 큐의 개수를 말합니다.

Consumers

큐에서 메시지를 꺼내서 쓰는 소비자의 개수를 말합니다.

Nodes 

RabbiMQ 는 Cluster 구조로 여러 서버들을 붙일 수 있습니다. 그렇게되면 Nodes 에 그 서버들이 나타나고 상태정보도 보입니다.

File Descriptors

프로세스에 의해서 오픈한 File Descriptor 개수 입니다. 아래에는 최대 활용가능한 개수도 나옵니다. 만일 이것이 비율로 90%가 넘는다면 문제가 생길 수 있어 이를 잘 모니터링 해야 합니다. 또, 운영체제의 최대 파일 오픈 개수에 영향을 받습니다.

Socket Descriptor

프로세스에 의해서 오픈한 Socket Descriptor 개수 입니다. 아래에는 최대 활용가능한 개수도 나옵니다. 만일 이것이 비율로 90%가 넘는다면 문제가 생길 수 있어 이를 잘 모니터링해야 합니다.

Erlang Processes

Erlang 프로세스들의 개수 입니다. 아래에는 최대 활용가능한 개수도 나옵니다. 만일 이것이 비율로 90%가 넘는다면 문제가 생길 수 있어 이를 잘 모니터링해야 합니다.

Memory

RabbiMQ 서버에서 사용하고 있는 메모리양 입니다.

git 파일 삭제후 복구.

git 를 사용하다 보면 local 저장소에서 실수로 파일을 삭제하는 실수를 저지를 수 있다. 이때 파일을 되살린다고 ‘git pull’ 이나 ‘git fetch’를 해봐도 나오는 메시지는 최신판(Already up-to-date)라는 것이다.

이를 이용하는 경우에 어떻게 해야하나?

먼저 삭제한 디렉토리로 이동한다. 그리고 다음과 같이 입력을하면 삭제한 파일 목록을 얻을 수 있다.

Shell
1
]$ git ls-files -d

사실 삭제된 파일은 다시 checkout 받으면 된다. 다음과 같이 말이다.

1
]$ git checkout a.py

리눅스를 잘 다루는 사람이라면 이것을 한번에 할수 있다.

1
]$ git ls-files -d | xargs git checkout --

 

 

 

Better VACCUM FULL For PostgreSQL 9.0

원문:https://wiki.postgresql.org/wiki/What’s_new_in_PostgreSQL_9.0#Better_VACUUM_FULL

지금까지 VACUUM FULL 은 매우 느렸다. 이 구문(Statement)는 테이블로부터 빈공간을 확보하고 그것의 크기(Size)를 줄였지만 VACUUM 은 만족할만큼 빠르게 동작하지 않았다.

이것이 느린 이유는 동작 방법에 문제가 있었기 때문이다. 레코드를 그들의 소스블럭으로부터 테이블에 시작점에 가까운 블럭으로 하나하나씩 읽어서 옮겼었다. 그리고 테이블에 끝이 빈공간이면 그 부분을 지웠다.

전략적으로 이러한 방법은 매우 비효율적(Inefficient) 이다. 레코드를 하나하나씩 옮기는 것은 랜덤 I/O를 발생시킨다. 게다가, 인덱스(Index)를 재구성하는 동안에 그것을 유지하고, 더 많은 비용이 들어가는, 인덱스는 파편화된다. 이럴바에는 VACUUM FULL이 다 끝나고 나서 재인덱스(reindex)를 하는 것이 낫다.

Version 9.0 에서 VACUUM FULL은 테이블과 동일한 또 하나의 테이블을 만들고 거거에 모든 레코드를 순차적이게 복사한다. 모든 레코드가 복사되고 나면, 인덱스를 재생성하고 예전 테이블은 삭제되고 새로운 테이블로 대체된다.

이것은 VACUUM 을 보다 빠르게 한다. 하지만 VACUUM FULL은 동작하는 동안에 AccessExclusiveLock 을 필요로 한다. 이전 방법과 비교했을때 이 방법의 결점은 VACUUM FULL을 했을 경우 새로운 버전의 테이블을 만들기 위해서 디스크에 테이블 크기의 2배의 용량을 사용할 수 있다는 것이다.

이제, 두가지 방법에 대해서 실시간으로 비교를 해보자. 먼저 아래와 같은 방법으로 테스트 데이터를 준비 했다.

Vaccum Test
PgSQL
1
2
3
4
5
6
7
8
9
10
marc=# CREATE TABLE test (a int);
CREATE TABLE
marc=# CREATE INDEX idxtsta on test (a);
CREATE INDEX
marc=# INSERT INTO test SELECT generate_series(1,1000000);
INSERT 0 1000000
marc=# DELETE FROM test where a%3=0; -- making holes everywhere
DELETE 333333
marc=# VACUUM test;
VACUUM

8.4 버전에서는.

Vaccum for 8.4 version
PgSQL
1
2
3
4
5
6
7
8
marc=# \timing
Timing is on.
marc=# VACUUM FULL test;
VACUUM
Time: 6306,603 ms
marc=# REINDEX TABLE test;
REINDEX
Time: 1799,998 ms

다 합해 대충 9초 정도 걸렸다.

9.0 버전에서는.

Vaccum for 9.0 version
PgSQL
1
2
3
4
5
marc=# \timing
Timing is on.
marc=# VACUUM FULL test;
VACUUM
Time: 2563,467 ms

아직 이것은 제품에서(아마 서비스중에라는 뜻인듯..) VACUUM FULL 이 좋은 아이디어라는 뜻은 아니다. 만약 이것이 필요하다면, 아마도 VACUUM 정책이 올바르지 않기 때문일 것이다. (응?)

PostgreSQL 과 문자셋

PostgreSQL 도 문자셋에 관해서 많은 옵션들을 제공한다. 그런데, 대부분은 이에 대해서 잘 모르는 듯해서 여기서 정리해 본다.

PostgreSQL 에서 문자셋 지정을 처음 하는 부분은 바로 설치를 마친후에 initdb 명령어를 사용하면서 부터다 대충 다음과 같이 사용한다.

initdb for PostgreSQL
Shell
1
su -l postgres -c "/usr/local/pgsql9.1/bin/initdb -E UTF8 --locale=ko_KR.UTF-8 --pgdata='$PGDATA' "

문제는 저러한 문제셋 설정이 과연 향후 PostgreSQL 을 사용하는데 있어 어떤 영향을 주는가 하는 것이다. 먼저 PostgreSQL 은 ISO C 와 POSIX 등의 언어표현에 관해 지원 한다.

Locale

보통 initdb –locale=ko_KR.UTF-8 로 사용되어지는 것으로 운영체제에 종속적이다. 운영체제에서 지원하는 locale 만 사용할 수 있는데, 리눅스의 경우에는 ‘locale -a’ 명령어로 확인 가능하다.

이는 운영체제의 사용자에게 보여주는 메시지 문자를 지정한다. 만일 영어로 운영체제를 사용하고 싶다면 바로 이 locale 를 변경하면 된다. 그런데, locale 의 설정은 ‘ko_KR.UTF-8’ 처럼 나오는데 이는 language_territory.codeset 형태이다.

language 는 인간의 사용하는 언어이고 territory 는 ‘한 국가가 다스리는 영토, 지역’을 뜻한다. 예를들어서 fr_CA 도 있는데 이는 캐나다에서 사용하는 프랑스어라는 뜻이 된다. codeset 은 이러한 언어를 컴퓨터 언어로 표현하는 문자 셋이다.

이러한 형태가 나온 이유는 한 국가(영토, 지역)에서 두가지 이상의 언어를 사용할 경우를 대비한 것으로 풀이된다.

LC_COLLATE

이는 매우 중요한 것으로 다음과 같은 것에 영향을 미친다.

  1. 대소문자를 구분하는 기능.
  2. 문자열 정렬
  3. ‘like’ 문에서 인덱스를 사용여부 결정

이는 데이터베이스를 생성할때에도 지정할 수가 있는데, 지정하는 방법은 locale 과 같이 language_territory.codeset 형식이지만 codeset 은 생략하는 경우가 있다. 다음과 같은 명령어로 확인 가능하다.

LC_COLLATE 확인
PgSQL
1
=# show LC_COLLATE;

문제는 이 LC_COLLATE 는 initdb 시에 한번 결정이 되면 바꿀 수 없고 하지만, Template 을 1번이 아닌 0번으로 할 경우에는 가능하다. Template1 은 initdb 때 생성되는 일종의 Master  DB라 보면되고 모든 데이터베이스는 이 Template1 을 기반으로 생성되어진다.

LC_CTYPE

이는 문자의 범주를 정하는 것으로 각 언어마다 가지고 있는 고유한 특성을 타나내기도 한다. 예를들면 단어가 무엇인지, 대문자와 소문자,one byte 문자인지 multi byte 문자인지에 대한 정의등에 대한 것이다. 이는 initdb 실에 결정되면 바꿀 수 없다.

대부분 Locale 을 따라 지정하는게 낫다.

LC_MESSAGE  

이는 접속한 클라이언트에게 어떤 언어로 보여줄지를 결정한다.

LC_MONETARY 

이는 접속한 클라이언트에게 어떤 화폐단위로 보여줄 것인지를 결정한다.

LC_NUMERIC

이는 접속한 클라이언트에게 어떤 숫자단위로 보여줄 것인지를 결정한다.

LC_TIME

이는 접속한 클라이언트에게 날짜와 시간에 대한 포맷을 결정한다.

 

CHEF CLIENT 설치 – PART4

앞에서 chef 운영을 위한 server와 workstation 을 설치했다. 이제 chef 를 가지고 관리를 할 대상인 서버에 chef client 를 설치하는 방법에 대해서 설명한다.

chef 에서 관리해야할 대상 서버를 Node혹은 Client 라고 부른다. 이러한 서버들은 chef server와 통신을 통해서 각종 작업을 수행하는데, 이 역활을 담당하기는게 바로 chef-client 이다.

chef client 설치는 서버에 직접 들어가서 프로그램을 설치하고 관련 파일을 업데이트하는 작업을 통해서도 할 수 있지만 Chef 스럽게 workstation에서 knife 명령어를 이용해서 간단히 Chef Client 를 설치할 수 있다. 이뿐 아니라 설치와함께 이 서버를 Chef Servr 에 관리대상 서버로 등록해준다.

Chef Client 설치

설치에 앞서 Chef Client 가 될 서버에서 Chef Server 에 호스트네임과 IP를 다음과 같이 등록해준다.

1
192.168.96.24  chefserver

Chef Client 설치는 Chef Workstation 에서 다음과 같이 명령어로 진행한다.

Shell
1
knife bootstrap 192.168.96.6 -N test2 -x orion -P password --sudo --use-sudo-password

이 한줄이면 아무것도 없는 서버에 Chef Client 가 설치되고 Chef Server 에 Node로 등록된다.

Chef-client 12.4.0-1 에서 문제

아무 위에처럼하면 Chef-client 가 설치가 되어도 Chef Server 와 통신문제를 겪게 된다. 다음과 같은 오류 메시지를 받게 될 것이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Starting Chef Client, version 12.4.0
Creating a new client identity for test2 using the validator key.
 
================================================================================
Chef encountered an error attempting to create the client "test2"
================================================================================
 
Authentication Error:
---------------------
Failed to authenticate to the chef server (http 401).
 
Server Response:
----------------
Failed to authenticate as 'systemv'. Ensure that your node_name and client key are correct.
 
Relevant Config Settings:
-------------------------
chef_server_url         "https://chefserver/organizations/systemv"
validation_client_name  "systemv"
validation_key          "/etc/chef/validation.pem"
 
If these settings are correct, your validation_key may be invalid.
 
 
Running handlers:
[2015-06-26T00:22:06+09:00] ERROR: Running exception handlers
Running handlers complete
[2015-06-26T00:22:06+09:00] ERROR: Exception handlers complete
Chef Client failed. 0 resources updated in 5.729573691 seconds
[2015-06-26T00:22:06+09:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2015-06-26T00:22:06+09:00] ERROR: 401 "Unauthorized"
[2015-06-26T00:22:06+09:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

핵심은 인증키인 validation_key 가 맞지 않다는 것이다.

Chef Workstation 에서 Chef Client 설치 명령어를 수행하면 Chef Client 에 접속해 Chef Client 최신버전은 chef-12.4.0-1 버전을 더운받아서 설치하고 Chef Client 설정파일들이 /etc/chef 디렉토리에 모인다.

1
2
3
4
5
6
[root@test2 chef]# ls -lh
합계 12K
-rw------- 1 root root 1.7K  6월 26 21:35 validation.pem
-rw-r--r-- 1 root root  187  6월 26 21:35 client.rb
-rw-r--r-- 1 root root   16  6월 26 21:35 first-boot.json
drwxr-xr-x 2 root root   27  6월 26 21:35 trusted_certs

그중에 validation.pem 파일이 맞지 않다는 것이다.

Chef Server 는 Chef Client 와 통신을 위해서 공개키/비밀키 기반으로 한다. Chef Server 는 공개키를 각 Chef Client 에 제공하고 Chef Client 는 비밀키를 Chef Server 에 보낸다. 그러면 통신을 할때에 이것을 가지고 인증을 한다.

하지만 chef-12.1 이상 버전부터는 이 키, 더 정확하게는 validation.pem 이 필요없게 되었다. 이에 대한 내용은 다음 링크에서 확인할 수 있다.

결국에는 Chef Workstation 이 가지고 있는 공개키를 삭제하면 된다는 것이다.

Chef Workstation 에서..
Shell
1
~/chef-repo/.chef$ rm -f systemv.pem

그리고 난 후에 방금 실패했던 Chef Client 에서 /etc/chef 디렉토리를 삭제한다.

Chef Client 에서..
Shell
1
rm -rf /etc/chef

Chef Workstation 에서 다시 한번 bootstrap 명령어를 주면 Chef Client가 다음과 같이 설치되고 Node 로 등록된다.

Chef Workstation 에서..
Shell
1
2
3
4
5
6
7
8
9
10
11
192.168.96.6 Starting first Chef Client run...
192.168.96.6 Starting Chef Client, version 12.4.0
192.168.96.6 resolving cookbooks for run list: []
192.168.96.6 Synchronizing Cookbooks:
192.168.96.6 Compiling Cookbooks...
192.168.96.6 [2015-06-26T21:35:53+09:00] WARN: Node test2 has an empty run list.
192.168.96.6 Converging 0 resources
192.168.96.6
192.168.96.6 Running handlers:
192.168.96.6 Running handlers complete
192.168.96.6 Chef Client finished, 0/0 resources updated in 12.848701442 seconds

Chef Client 등록 확인

Chef Workstation 에서..
Shell
1
2
3
4
5
]$ knife node list
test2
]$ knife client list
systemv-validator
test2

Chef Workstation 에서 등록 확인.

Chef Workstation 설치 – Part 3

chef workstation 은 knife 를 설정면 하면된다. 다시말해서 별다른 패키지가 필요없고 특정 시스템 계정사용자에게 knife 를 사용할 수 있도록 설정만하면 그게 바로 workstation 이 되는 것이다.

하지만 별도의 시스템에 workstation 을 설치하고자 할 경우에 knife 명령어가 없다. 그렇다고 chef server 패키지를 설치할려고 하니 불필요한 서비스들이 너무 많은게 문제다. 이럴때는 chef develoment kit 를 설치하면 된다.

chef development kit 은 말그대로 chef 관련 개발을 위한 kit 을 제공하는 것으로 이는 chef workstation 환경을 기반으로 한다. 따라서 chef development kit 패키지를 설치하면 chef workstation 구성을 위한 chef 관련 명령어들이 당연히 들어 있게 되는 것이다.

chef development kit 역시 chef 홈페이지에서 다운로드 가능하다. 레드햇과 우분투 배포판 패키지가 준비되어 있어 패키지를 다운받아 설치하면 된다.

Shell
1
2
3
4
5
6
7
dpkg -i chefdk_0.6.2-1_amd64.deb
Selecting previously unselected package chefdk.
(데이터베이스 읽는중 ...현재 301009개의 파일과 디렉터리가 설치되어 있습니다.)
Preparing to unpack chefdk_0.6.2-1_amd64.deb ...
Unpacking chefdk (0.6.2-1) ...
chefdk (0.6.2-1) 설정하는 중입니다 ...
Thank you for installing Chef Development Kit!

이제 chef 명령어를 이용해서 알맞은 환경을 조성할 수 있도록 다음과 같이 해준다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
]# chef verify
Running verification for component 'berkshelf'
Running verification for component 'test-kitchen'
Running verification for component 'chef-client'
Running verification for component 'chef-dk'
Running verification for component 'chefspec'
Running verification for component 'rubocop'
Running verification for component 'fauxhai'
Running verification for component 'knife-spork'
Running verification for component 'kitchen-vagrant'
Running verification for component 'package installation'
Running verification for component 'openssl'
..............
---------------------------------------------
Verification of component 'rubocop' succeeded.
Verification of component 'knife-spork' succeeded.
Verification of component 'openssl' succeeded.
Verification of component 'berkshelf' succeeded.
Verification of component 'chef-client' succeeded.
Verification of component 'fauxhai' succeeded.
Verification of component 'test-kitchen' succeeded.
Verification of component 'kitchen-vagrant' succeeded.
Verification of component 'chef-dk' succeeded.
Verification of component 'chefspec' succeeded.
Verification of component 'package installation' succeeded.

앞에서 chef 서버 설치하면서 만들어놓은 자격증명 파일을 복사해 와야 한다. scp 를 이용하던 ftp 를 이용하던 어떻게든 복사하면 되는데, 중요한 것은 복사할 디렉토리가 chef 저장소 디렉토리이다. 이것은 자동으로 생성되는 것이 아니기 때문에 다음과 같이 수동으로 생성해주자.

1
mkdir ~/chef-repo/.chef

위 디렉토리에 chef 서버 설치할때 만든 자격증명 파일을 복사 넣는다.

이제 knife.rb 파일을 작성한다. 이 파일 역시 ~/chef-repo/.chef 디렉토리 작성한다. 주요한 파일 내용은 다음과 같다.

knife.rb
Shell
1
2
3
4
5
6
7
8
9
10
current_dir = File.dirname(__FILE__)
log_level                :info
log_location             STDOUT
node_name                "name_for_workstation"
client_key               "#{current_dir}/name_of_user_key"
validation_client_name   "organization_validator_name"
validation_key           "#{current_dir}/organization_validator_key"
chef_server_url          "https://server_domain_or_IP/organizations/organization_name"
syntax_check_cache_path  "#{ENV['HOME']}/.chef/syntaxcache"
cookbook_path            ["#{current_dir}/../cookbooks"]

이것을 기반으로 환경에 맞게 변경을 하면 다음과 같다.

Shell
1
2
3
4
5
6
7
8
9
10
current_dir = File.dirname(__FILE__)
log_level                :info
log_location             STDOUT
node_name                "sbhyun"
client_key               "#{current_dir}/sbhyun.pem"
validation_client_name   "systemv"
validation_key           "#{current_dir}/systemv.pem"
chef_server_url          "https://chefserver/organizations/systemv"
syntax_check_cache_path  "#{ENV['HOME']}/.chef/syntaxcache"
cookbook_path            ["#{current_dir}/../cookbooks"]

이렇게 한 후에 다음과 같이 테스트 해본다.

1
2
3
4
5
6
7
8
9
]$ cd ~/chef-repo
]$ knife client list
ERROR: SSL Validation failure connecting to host: sbhyun - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
ERROR: Could not establish a secure connection to the server.
Use `knife ssl check` to troubleshoot your SSL configuration.
If your Chef Server uses a self-signed certificate, you can use
`knife ssl fetch` to make knife trust the server's certificates.
 
Original Exception: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

위 에러 메시지는  chef  서버의 SSL 인증서가 없어서 나는 오류다. 오류가 나왔지만 위 메시지만으로 chef 서버와 통신은 성공했다는 것을 알 수 있다. 이제부터는 knife  명령어로 chef  서버와 명령어를 주고받을 수 있다. SSL 인증서가 없다고 하니 chef 서버로부터 받아오자

1
2
3
4
5
6
7
8
]$ knife ssl fetch
WARNING: Certificates from sbhyun will be fetched and placed in your trusted_cert
directory (/home/sbhyun/chef-repo/.chef/trusted_certs).
 
Knife has no means to verify these are the correct certificates. You should
verify the authenticity of these certificates after downloading.
 
Adding certificate for chefserver in /home/sbhyun/chef-repo/.chef/trusted_certs/chefserver.crt

다시 다음과 같이 나오면 정상적으로 작동하는 것이다.

1
2
]$ knife client list
systemv-validator

 

Chef 서버 설치하기 – Part 2

이번 시간에는 Chef 서버를 설치해보도록 한다. 설치에 앞서 Chef 서버를 설치할 서버들에 대한 정보는 다음과 같다.

  • 배포판: Ubuntu 14.04.2 LTS
  • CPU: 1 core
  • RAM: 1024

여기서 중요한 것은 배포판이다. 최근들어 많은 배포판들이 init 에서 systemd 로 바꾸는 추세다. 우분투(Ubuntu)에 경우 systemd 를 도입할 생각이 없다라고 했었지만 14.10 에서 이를 뒤집어 systemd 를 도입했다. init 과 systemd 는 서버 프로그램 시작과 종료하는 방법만 다른게 아니기 때문에 이를 구분하는 것은 매우 중요하다. 여기서 설치할 14.04 는 현재 init 을 따른다.

Download

다운로드는 chef 홈페이지에서 무료로 다운로드 할 수 있다. 그런데, 약간 실망스러운게 다운로드를 하기 위해서는 여기저기 단계를 거쳐야 한다는 것이다. 무료로 다운로드 되는 링크가 바로 나오지 않고 hosted, primium 과 같은 상품을 먼저 전시하고 링크를 찾아 클릭해야만 무료 다운로드 링크가 나오는 구조다.

무료 chef 다운로드
무료 chef 다운로드

우선 서버를 설치해야 하기 때문에 Chef Server 를 다운로드 받는다. Chef Server 는 레드햇 배포판 계열과 우분투 계열은 패키지를 제공한다. 단, 제공되는 배포판 버전은 제한적일 수 있다. 우리는 우분투 14.04 배포판에서 설치할 것이고 지금 현재 Chef 홈페이지에서는 다행이도 이 배포판 버전에 패키지를 제공한다.

Installation

설치는 여러가지 방법이 있는데 여기서는 dpkg 명령어를 이용해 패키지를 설치한다. 이렇게하면 Standard 형식으로 설치가 된다.

Shell
1
2
3
4
5
6
dpkg -i chef-server-core_12.1.0-1_amd64.deb
Selecting previously unselected package chef-server-core.
(데이터베이스 읽는중 ...현재 55970개의 파일과 디렉터리가 설치되어 있습니다.)
Preparing to unpack chef-server-core_12.1.0-1_amd64.deb ...
Unpacking chef-server-core (12.1.0-1) ...
chef-server-core (12.1.0-1) 설정하는 중입니다 ...

설치는 간단하다. 하지만 여기서 끝나는 것이 아니라 이제 시작이다.

Setting

설치가 끝나다면 이제 chef 가 동작하기 위해서 설정을 해준다. chef 서버의 설정은 ‘chef-server-ctl 명령어를 이용해 거의 모든것을 할 수가 있다. Standard 형식의 설치이기 때문에 다음과 같이 해준다.

chef 서버는 다양한 서비스들이 필요하다. 이러한 것을 일일이 다하기보다는 chef 자체의 기능인 자동화 기능을 이용할 수 있는데 그것은 다음과 같다.

Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
chef-server-ctl reconfigure
....
....
Recipe: private-chef::partybus
  * execute[set initial migration level] action run
    - execute cd /opt/opscode/embedded/service/partybus && ./bin/partybus init
  * ruby_block[migration-level file sanity check] action run (skipped due to not_if)
Recipe: private-chef::opscode-chef-mover
  * execute[restart_opscode-chef-mover_log_service] action run
    - execute /opt/opscode/embedded/bin/sv restart /opt/opscode/sv/opscode-chef-mover/log
Recipe: private-chef::redis_lb
  * execute[restart_redis_lb_log_service] action run
    - execute /opt/opscode/embedded/bin/sv restart /opt/opscode/sv/redis_lb/log
Recipe: <Dynamically Defined Resource>
  * service[nginx] action restart
    - restart service service[nginx]
Recipe: private-chef::nginx
  * execute[restart_nginx_log_service] action run
    - execute /opt/opscode/embedded/bin/sv restart /opt/opscode/sv/nginx/log

과정을 유심히 보면 nginx 웹서버도 설치된것을 알 수 있다.

여기서 잠깐 chef-server-ctl 는 그야말로 chef server 를 컨트롤하기위한 명령어이기 때문에 서버의 상태뿐만 아니라 각종 서비스들에 대한 설정을 변경할 수 있다. 여기서 간단히 알아보도록 하자.

상태보기

Shell
1
2
3
4
5
6
7
8
9
10
11
12
chef-server-ctl status
run: bookshelf: (pid 4220) 443s; run: log: (pid 4265) 442s
run: nginx: (pid 4435) 436s; run: log: (pid 4466) 436s
run: oc_bifrost: (pid 3982) 451s; run: log: (pid 4021) 450s
run: oc_id: (pid 4028) 449s; run: log: (pid 4034) 449s
run: opscode-erchef: (pid 4343) 440s; run: log: (pid 4327) 441s
run: opscode-expander: (pid 4126) 445s; run: log: (pid 4204) 444s
run: opscode-expander-reindexer: (pid 4171) 444s; run: log: (pid 4211) 443s
run: opscode-solr4: (pid 4073) 447s; run: log: (pid 4107) 446s
run: postgresql: (pid 3963) 451s; run: log: (pid 3969) 451s
run: rabbitmq: (pid 1507) 586s; run: log: (pid 3932) 456s
run: redis_lb: (pid 3891) 463s; run: log: (pid 4428) 437s

서비스 내리기

Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
root@chefserver:~# chef-server-ctl stop nginx
ok: down: nginx: 0s, normally up
root@chefserver:~# chef-server-ctl status
run: bookshelf: (pid 4220) 513s; run: log: (pid 4265) 512s
down: nginx: 7s, normally up; run: log: (pid 4466) 506s
run: oc_bifrost: (pid 3982) 521s; run: log: (pid 4021) 520s
run: oc_id: (pid 4028) 519s; run: log: (pid 4034) 519s
run: opscode-erchef: (pid 4343) 510s; run: log: (pid 4327) 511s
run: opscode-expander: (pid 4126) 515s; run: log: (pid 4204) 514s
run: opscode-expander-reindexer: (pid 4171) 514s; run: log: (pid 4211) 513s
run: opscode-solr4: (pid 4073) 517s; run: log: (pid 4107) 516s
run: postgresql: (pid 3963) 521s; run: log: (pid 3969) 521s
run: rabbitmq: (pid 1507) 656s; run: log: (pid 3932) 526s
run: redis_lb: (pid 3891) 533s; run: log: (pid 4428) 507s

nginx 서비스를 내린 예지다. 서비스를 올릴려면 start 옵션을 주면 된다.

서비스 로그들 보기

서비스 로그들도 다음과 같이 한번에 볼 수 있다.

Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
root@chefserver:~# chef-server-ctl tail nginx
==> /var/log/opscode/nginx/internal-chef.access.log <==
 
==> /var/log/opscode/nginx/internal-chef.error.log <==
 
==> /var/log/opscode/nginx/internal-authz.error.log <==
 
==> /var/log/opscode/nginx/internal-authz.access.log <==
 
==> /var/log/opscode/nginx/rewrite-port-80.log <==
 
==> /var/log/opscode/nginx/current <==
 
==> /var/log/opscode/nginx/error.log <==
 
==> /var/log/opscode/nginx/access.log <==
root@chefserver:~# chef-server-ctl tail rabbitmq
2015-06-21_08:11:05.27723
2015-06-21_08:11:05.27741               RabbitMQ 3.3.4. Copyright (C) 2007-2014 GoPivotal, Inc.
2015-06-21_08:11:05.27741   ##  ##      Licensed under the MPL.  See http://www.rabbitmq.com/
2015-06-21_08:11:05.27741   ##  ##
2015-06-21_08:11:05.27742   ##########  Logs: /var/opt/opscode/rabbitmq/log/rabbit@localhost.log
2015-06-21_08:11:05.27742   ######  ##        /var/opt/opscode/rabbitmq/log/rabbit@localhost-sasl.log
2015-06-21_08:11:05.27742   ##########
2015-06-21_08:11:05.27743               Starting broker... completed with 0 plugins.

chef 이기 때문에 관련 서비스들 관리도 chef 로 한다.

현재 설정들 보기

Shell
1
root@chefserver:~# chef-server-ctl show-config

각 서비스들에 설정상태를 보여준다.

간단하게 chef-server-ctl 에 대해서 알아봤다.

여기까지만 해도 사실 chef server 설치는 끝난다. 하지만 chef server 를 운영하기 위한 계정을 만들어야 할 필요가 있다.  chef-server 를 매니징할 수 있는 서버는 chef workstation 이라는 점이다. chef client 에 chef server 를 매니징 할 수는 없다. chef 로 무엇을 하기위한 관련된 모든 것은 chef workstation 에서 이루어진다고 보면 맞다.  따라서 chef server 에 접근할 수 있는 것도 오직 chef workstation 으로 한정된다.

이를 위해 다음과 같은 추가 작업이 필요하다.

  1. 관리자 계정 생성
  2. 관리자 조직 생성

관리자 계정 생성

Shell
1
2
# chef-server-ctl user-create user_name first_name last_name email password --filename FILE_NAME
chef-server-ctl user-create sbhyun sb hyun excellion203@yahoo.com 123456 --filename sbhyun.pem

조직 생성

1
2
#chef-server-ctl org-create short_name full_organization_name --association_user user_name --filename FILE_NAME
chef-server-ctl org-create systemv systemv.pe.kr --association_user sbhyun --filename systemv.pem

위에 sbhyun.pem 와 systemv.pem 은 chef server 에 연결위한 자격증명서다. chef workstation 은 chef server 와 연결해 작업을 수행하는데, 이때 chef server 가 과연 올바른 chef workstation 연결인지를 판별하기 위해서 필요한 것이 바로 이 자격증명 파일이다. 따라서 이 자격증명 파일은 chef workstation 에 복사해주어야 한다.

따라서 이 자격증명 파일은 꼭 잘 간수해야 한다.

다음시간에는 chef workstation 설치에 대해서 알아보자.