Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

MCollective를 배포하고 유지보수 하기 위해서는 Puppet, Chef 등의 설정 관리 툴을 이용하는 것이 좋다.

설정 관리 툴의 이점에 대한 설명은 생략..

Puppet/Chef 를 사용하지 않고 수동으로 설정을 하는 경우에는 책을 보고 필요한 설정을 직접 바꾸어야 한다.

Puppet

이 책 저자가 만든 Puppet module로 이 책에서 이야기한 모든 기능을 구현할 수 있다.  각 장마다 Puppet module 에서 어떻게 설정을 하면 되는지 예제가 있다.

Puppet Forge 에 puppetlabs-mcollective 모듈이 있다. 그렇지만 다음의 이유로 PuppetLabs의 MCollective module을 추천하지 않음. 주로 보안 이슈임.

  • 알려진 user와 passwords를 사용함.
  • client 와 server permissions을 구분하지 않고 있음. 동일한 인증을 사용하면 보안 문제가 생김.
  • client 퍼미션과 broker link 퍼미션을 구분하지 않고 있음
  • Puppet Labs 모듈은 외부 의존성이 있음.

Puppet 설치하기 (문태준 추가)

Puppet 설치하는 방법에 대해서 모르는 경우가 있어서 필요성이 있어서 추가함. Puppet 에 대한 자세한 설명은 생략을 함. 아래에서 puppet master 서버의 주소는 node0.example.net 임.

Puppet Master 설치

Puppet 설치

Puppet Module 설치하기

Using r10k

이미 r10k를 사용하고 있으면 https://github.com/jorhett/learning-mcollective 에서 파일을 받아 모듈을 설치할 수 있다. 여기에는 hiera 설정과 데이터용 예제 파일이 모두 들어 있다. 자세한 내용은 7. Configuration Management 의 "Using r10k to install Puppet Modules" 참고.

GitHub 이용하여 설치하기

지금 예제에서는 /etc/puppet/environments/learning_mcollective/ 디렉토리에 Puppet learning_mcollective environment를 만들어서 사용하는 예제이다.

r10k를 사용하고 있지 않다면 GitHub에서 모듈을 다운로드 받아 설치할 수 있다.

내부적으로 자체 forge 를 가지고 있다면 다음은 내부 forge 에 업로드할 수 있도록 적절한 모듈 패키지를 빌드한다.

또는 modulepath에 직접 모듈을 이동시킬 수 있다.

아직 Puppet Lab stdlib 모듈을 가지고 있지 않다면 다음과 같이 실행을 한다.

다음 섹션에서는 manifests 의 site 설정이나 Hiera data 를 정의해야 한다.

Puppet 이용하여 MCollective 설정하기

다음의 Puppet manifests 는 기본 MCollective 설정을 하고 초기화를 할 것이다.

이 모듈에는 이 책에 있는 모든 manifests 와 templates 를 포함하고 있고 ActioPolicy 설정 예제도 함께 들어 있습니다.

이 Puppet module 은 ActiveMQ와 RabbitMQ 설정을 관리하기 위해 다른 Forge 모듈을 이용하는 경우 더 많은 미들웨어 설정을 위해 확장될 수 있다. 이 책에서는 간단하고 바로 세팅을 하기 위해서 오직 MCollective 클라이언트와 서버에만 촛점을 맞추었다. 미들웨어 설정을 따로 관리하기 원한다면 mcollective::middleware 를  사용하지 않으면 된다.

간단한 예제로 아래와 같이 당신의 노드를 설정할 수 있다.

설정에 따라서 오직 mcollective 와 mcollective::server 클래스만 사용할 수 있다. 요청을 하기 원하는 호스트에만 mcollective::client 를 설정해야 한다.

Hiera Configuration Data

manifests 파일을 통해서 원하는 파라미터를 설정할 수도 있지만 hiera 를 통해서 모든 설정을 할 수도 있다. 다음은 최소한의 파라미터로 설정을 하는 것이다.

먼저, site manifest 에 대한 Hiera 에서 class 할당을 활성화한다.

그러고나서 1차는 hostname이고 그 다음은 common file 에서 데이터를 찾도록 hiera 를 설정한다.

전체적으로 공유할 수 있는 파라미터를 common file에 둔다. 이런 경우 모든 노드는 server 를 로드할 것이다:

마지막으로 호스트네임에 따라 특정 classe 를 포함하는 두개의 파일을 만든다.

HIera

Hiera is a key/value lookup tool for configuration data, built to let you define Puppet configuration data without repeating yourself.

If you are not familiar with using Hiera, the best reference can be found at Hiera Overview. In particular, read carefully “Usage with Puppet” for how Puppet modules automatically include Hiera data.

MCollective Puppet module은 필요에 따라 설정할 수 있는 많은 파라미터가 있다. 이 모듈을 이용하여 보안을 강화한 설정이나 대규모 분산 network of brokers 설정 등도 할 수 있다. 다음과 같은 더 복잡한 작업을 할 수 있다.

  1. clients 가 자신의 로컬 브로커를 가리키도록 함.
  2. 브로커 사이에 site->site 링크 설정
  3. 모든 연결에 SSL 암호화 사용
  4. debug level 로 파일 로깅 설정
  5. 두 사이트에서 package, service, Puppet agent 로드함
  6. site1에만 client 프로그램을 설치함.

다 음의 Hiera 설정은 런던과 필라델피아 오피스간에 설정을 나누고 있다. 각 사무실은 각자의 ActiveMQ 서버가 있다. 모든 admin은 런던에 있기 때문에 client 패키지는 런던에 설치가 된다. 다른 모든 파라미터는 동일하다.

이 복잡한 설정을 이해하지 못한다고 걱정하지는 말자. 앞으로 계속 설명을 할 것이다. 이 책에서 계속 MCollective 로 할 수 있는 것들을 설명할 것이고 각 섹션마다 활성화할 수 있는 Puppet/Hiera 파라미터를 포함할 것이다.

https://github.com/jorhett/learning-mcollective 의 설정 참고.

Puppet 으로  Facts 공유

필 터에서 설명을 했는데 관련된 시스템 그룹을 찾는 방법 중의 하나는 facts 이다. MCollective 를 위해 facter facts를 얻는 가장 쉬운 방법은 Puppet 에서 정보를 제공하도록 하는 방법이다. mcollective::facts 을 include 해서 사용하면 된다.

Puppet manifest 에 다음을 추가하면 된다.

또는 Hiera 로 다음과 같이 설정을 한다.

p32에서 수동으로 cron 스크립트로 facts 정보 생성하도록 했다면 이 부분은 삭제를 해야 한다.

Puppet 으로 Agent  설치하기

다음은 agent 패키지가 package 레포지토리(yum 등)에서 사용 가능하다는 가정하에 시스템에 agent를 추가하는 예제이다. 정확한 버전을 정의할 수 있지만 이것은 필수는 아니다:

hiera 에서는 더 쉽다.다음은은 동일한 Hiera 설정이다.

mcollective::plugin::agents 는 설치할 agent 목록이다. 각 agent 는 dictionary of attributes 를 가져야 한다. 

또 한 agent 를 위해 의존성에 대한 배열을 정의할 수도 있다. 다음은 MCollective Puppet agent 를 설치하는데 Puppet package 가 설치된 경우에만 작업을 한다. puppet::client class 에서 package 이름에 대한 변수를 찾는다.

Hiear data 로는 다음과 같이 동일하게 표현할 수 있다:

client 명령을 실행할 호스트에서는 client 플러그인을 설치해야 한다. 다음은 기본 값으로 client 플러그인을 설치하는 예제이다:

Hiera 에서는 비어있는 dictionary 로 기본 값을 설정할 수 있다. 다음은 Hiera 예제이며 버전, 의존성을 지정한 경우도 있다.

I’m sure you’ve noticed by now that Hiera uses plural names (agents and clients) but the declarative policy invocation uses a single name (agent or client). This should be intuitive to remember, since the single name loads a single plugin, whereas the Hiera plural name accepts a list of plugins.

설치 확인하기

다음과 같이 puppet client 를 실행한다.

Puppet을 통해서 서버와 클라이언트가 예상된대로 동작을 하는지 확인을 한다. mco ping 을 실행하여 확인을 해보면 된다.

미 들웨어에 연결된 모든 서버의 목록과 응답 시간을 볼 수 있다면 성공한 것이다. Puppet 을 통해서 성공적으로 MCollective 를 배포하였다. 제대로 동작을 하지 않으면 p28의 "Troubleshooting"을 참고하여 설정을 확인한다.

디버깅

MCollective 와 Puppet을 이용할 때 나타날 수 있는 일반적인 에러에 대해서 설명을 한다.

Unable to match server with class

--with-class 필터 옵션을 이용하여 해당 호스트를 찾을 수 없다면 mco inventory hostname 명령을 통해 해당 노드의 인벤토리 정보를 확인한다. 인벤토리에서 host에 대한 classes 목록이 나오지 않으면 mcollectve에서 읽어들이는 classes.txt 파일이 Puppet을 통해 만들어지지 않은 것이다.

Puppet agent를 실행할 때마다 classes.txt 파일이 업데이트 된다. 기본값은 $statedir/classes.txt 이고 $statedir 기본값은 $vardir/state 이다. MCollective의 기본값은 모든 플랫폼에서 Puppet 에서의 위치와 동일하다.

그 렇지만 이 변수는 puppet.conf 와 mcollective/server.cfg 에서 변경을 할 수 있다. puppet 을 이용하여 관리하는 노드에서 inventory 요청의 출력에 Puppet classes 를 찾을 수 없다면 다음의 두가지 값을 확인해야 하며 이 부분이 일치하는지 확인해야 한다:

Puppet 에서 classfile 이 일치한다면 MCollectie 에서는 server.cfg 에서 설정을 바꿀 필요가 없다. 다른 값이 있다면 두 파일에 다음과 같이 명확하게 설정을 해야 한다:

Unable to match server with fact

--with-fact 필터 옵션을 이용하여 해당 호스트를 찾을 수 없다면 mco inventory hostname 명령을 통해 해당 노드의 인벤토리 정보를 확인한다. 인벤토리에서 host에 대한 fact 목록이 나오지 않으면 mcollectve에서 읽어들이는 facts.yaml 파일이 facter 나 Puppet을 통해 만들어지지 않은 것이다.

MCollective 에서 facts에 대해 알기 위해서는 mcollective 의 server.cfg 에 plugin.yaml 파라미터가 설정이 되어 있어야 한다. 이 파일에는 서버의 facts 를 YAML 포맷으로 가지고 있으며 일반적으로 /etc/mcollective/facts.yaml 이다:

plugin.yaml 파라미터에는 Unix 에서는 colon 으로 구분하여 여러 개의 파일 이름을 포함할 수 있다. (윈도우에서는 semicolon)  mcollective 를 재시작하고나서도 facts가 안 보인다면 대부분의 문제는 YAML 파일의 포맷이다.

p32 의 "Facts"에서 시스템 facts를 수집하는 기본적인 방법을 설명했고. 좀 더 나은 유연한 방법은 p68 의 "Sharing Facts with Puppet"에서 소개한대로 Puppet 에서 생성한 facts 를 이용하는 것이다. 지정한 파일에 YAML 포맷으로 기록을 한다면 어떤 방법으로든 시스템 facts를 만들어 내는 것은 문제가 이니다.

해당 파일에 facts를 쓰기 위해 다음과 같이 설정을 했는지 확인한다:

  • YAML 을 생성하는 cron (p32 "Facts")
  • Puppet 모듈에서 facter facts 를 생성(p68 의 "Sharing Facts with Puppet")
  • YAML key/value 쌍을 만드는 다른 스크립트나 프로세스

Puppet Labs Forge 나 GitHub 등에서 YAML 포맷이 아닌 다른 facts 플러그인을 설치 할 수 있다. (p53 "Finding Community Plugins") 또한 20장을 참고하여 자신만의 facts 플러그인을 만들 수도 있다.

There is a plugin named mcollective-facter-facts on the Puppet Labs GitHub. This agent can be slow to run, as it invokes Facter for each evaluation. This has been observed to cause problems with nodes going offline randomly. The plugin used here to load facts from a YAML-format text file works much better.

Unable to match server by hostname

--with-identity 또는 -i 필터 옵션을 이용하여 해당 호스트를 찾을 수 없다면 먼저 서버에서 mcollectived 가 실행되고 있는지 확인을 한다. 대부분은 이런 이유로 응답에 실패를 한다.

다음으로는 server 설정에서 설정한 identity 를 확인해야 한다:

이런 경우, identity 가  server 설정에 하드코딩되어 있지 않으며 해당 노드를 식별하기 위해서 다른 fact를 사용해야 한다.

노 드에 대한 기본 identity는 hostname 명령의 실행 결과이다. Puppet 을 쓴다면 Puppet 에서는 certname을 이용하여 질의를 하며 certname 을 이용하여 노드 필터를 위한 필터로 사용할 수 있고 identity를 수집할 수 있다.

MCollective 서버에서 다음 명령을 실행한다:

MCollective client 를 설치한 노드에서 다음 명령을 실행한다:

잘못 출력을 한 것이 아니다. 설정 변수 cername 은 Puppet 에 의해서 제공되는 facter fact clientcert 이다. 일치하지 않는 부분이 있지만 그것은 Puppet 이 작동하는 방식이다.

No, that’s not a misprint. The configuration variable certname is provided by Puppet as facter fact clientcert . No idea why the inconsistency—it’s just how Puppet is.

이와 같이 노드에 있는 어떤 fact 나 class라도 사용을 할 수 있다. 다음의 예제는 나의 테스트랩에 있는 오직 두대의 CentOS 호스트를 보여준다.

MCollectiev 노드에서는 다른 이름을 사용하려면 server.cfg 에 identity 를 설정한다:

configuration management 를 사용하고 있다면 , 해당 configuration management 의 정보에 따라 설정을 할 수 있다. 예를 들면 여기서 puppet template 는 hostname 대신 puppet certification name으로 MCollective node ideinties 를 설정하는 경우이다:

노드 이름에서 가장 혼란스러운 부분은 node names을 쓰거나 hostname 의 FQDN을 사용하는 것이다. 예를 들면 간단한 이름으로 노드의 호스트네임을 설정할 수도 있고 도메인을 포함할 수도 있다:

이러한 설정에서 Mcollective identity는 heliotrope 이지만 Puppet certname은 heliotrope.example.net (FQDN)을 사용한다. Redhat 계열에서는 /etc/sysconfig/network 을 변경하여 해결을 할 수 있다. 변경을 하지 않는다고 하더라도 이 차이점을 이해하고 있어야 한다.

Puppet 과 MCollective 간에 이 차이점이 있다고 하더라도 이 때문에 명확한 문제가 발생하는 것은 아니다. 나의 테스트 셋업에서는 MCollective를 위해서는 짧은 노드 네임(heliotrope) 을 쓰지만 Puppet 에서는 언제나 FQDN(heliotrope.example.net)을 사용한다.

Puppet 과 MCollectiev 에서 서로 다른 idientities 를 쓴다고 하더라도 전혀 문제가 없다. 오직 자신만의 커스텀 플러그인을 만들 때는 영향을 줄 수 있다. 내 의견으로는 많은 호스트에 유일한 호스트네임을 쓰면, 호스트네임에 도메인네임을 타이핑하는 작업을 줄일 수 있다. 다른 사람은 이에 대해서 다른 의견을 피력하기도 한다.

Chef

생략

Labels
  • No labels