System Management 프로그램 Puppet 혹시 써보신분 있을까요? 시스템관리자동화프로그램입니다.

제가 운영하고 있는 구글메일링리스트에 썼던 글인데 다른 분들에게 참고가 될 듯 하여 여기에도 올립니다.

서버의 댓수가 여러대일 경우 이에 대하여 자동화를 어떻게 처리할까에 대한 고민입니다.

-----------------------------------------------------
기존에 이런 프로그램을 써보았다면 괜찮은데 그러지 않다면 처음에는 좀 낯설듯 하네요.

cfengine을 써보셨던 분이 있으면 아래 내용을 통해서 비교해보시면 됩니다.

http://reductivelabs.com/trac/puppet/wiki/CfengineVsPuppet

위 문서에 보시면 몇가지 차이점을 말하는데 cfengine 쓰면서 고민했던 부분들을 잘 처리하고 있네요.
이 프로젝트를 진행한 사람들은 시스템자동화 컨설팅을 하는 회사인데 원래 cfengine을 사용하다가 부딪치는 문제들이 있어서 여러가지 툴(공개된 프로그램 및 상용툴)을 찾다가 만든 것입니다.

* Cfengine vs. Puppet
o An Open Development Community

o Cross-Platform Support
+ A Resource Abstraction Layer
+ Configuration Language
-> cfengine은 관리자가 해당 운영체제별로 명령어등을 정확히 알아야하지만 puppet은 A Resource Abstraction Layer 를 이용하여 상세명령어를 몰라도 됩니다. 예를 들어 각 유닉스 버전별로 crontab을 설정하는것이 다른데 이러한 부분을 처리해준다는 것이지요. 사용자추가하는 경우도 useradd, adduser, freebsd는 pw user add 이런 식이죠. 관리자는 자기가 사용하려는 업무에만 집중할 수 있다는 것인데 단일한 OS만 사용하면 아주 큰 장점은 아닐듯하고 또 그렇다고 하더라도 관리자가 명령어는 정확히 알고 있어야 하는것이 아닌가 생각을 하는데 다양한 유닉스 환경이라면 장점이 있을 듯 합니다.
sshd의 경로도 각 유닉스별로 다른데 이런 것도 자동으로 처리를 해줍니다.
cfengine 에 비하여 리소스 관계가 명확하다는 장점이 있습니다.

puppuet

class ssh {
file { sshdconfig:
path => $operatingsystem ? {
solaris => "/etc/sshd_config",
default => "/etc/ssh/sshd_config"
},
source => "puppet://..."
}

service { $operatingsystem ? {
solaris => "openssh",
default => "sshd" }:
subscribe => File[sshdconfig],
ensure => running
}

위는 solaris 에서는 설정파일이 /etc/sshd_config 이고 다른 것에서는 /etc/ssh/sshd_config 이며 solaris 에서는 프로그램명 openssh 이고
다른 것에서는 sshd 입니다. sshdconfig 파일이 있는지, 그리고 실행하고 있는지 확인합니다.

cfengine
control:
AddInstallable = ( restart_sshd )
solaris::
sshdconfig = ( "/etc/sshd_config" )
sshd = ( openssh )
sshdinit = ( "/etc/init.d/openssh" )
!solaris::
sshdconfig = ( "/etc/ssh/sshd_config" )
sshd = ( sshd )
sshdinit = ( "/etc/init.d/sshd" )

copy:
"/my/path/to/source" dest=$sshdconfig
define=restart_sshd

processes:
$sshd restart "${sshdinit} start"

shellcommands:
restart_sshd::
"${sshdinit} restart"
}

o Handling Configuration Complexity
+ Ordering
+ Code Reuse
--> 이 부분이 큰 장점이라고 생각됩니다. cfengine은 순서를 조정하기가 매우 불편합니다. puppet 에서는 relationship 이라는것을 이용하여 이 문제를 해결합니다. 예를 들어 cfengine 에서는 위의 ssh 예를 보았지만 실제 설정을 하다보면 위에서 sshd 설정하는 것이 하나로 되는것이 아니라 별개로 분리가 되어 종합적으로 보기가 힘듭니다. 그런데 puppet 에서는 하나의 설정에 설정파일검사, 패키지가 있는지 검사, 서비스가 떠있는지 검사 등을 묶습니다. 이게 아주 간단한 것만 사용하면 모르는데 시스템갯수가 좀 커지면 파일을 보기가 아주 불편해지지요. cfengine 에서는 링크하기, 파일편집하기, 파일복사하기 등 작업별로 순서가 지정된다면 puppet 에서는 해당 작업별로 세세한 조정이 가능합니다.
예를 들어 레드햇 계열에서 기본 방화벽을 사용할 경우 방화벽이 떠 있는지 검사할때 /var/lock/subsys/iptables 파일이 없으면 iptables를 가동하면 되는데 이게 cfengine 에서는 한꺼번에 지정되는것이 아니라 파일검사, 프로그램 띄우기가 별도 설정으로 되기때문에 이러한 연관관계를 찾기가 힘듭니다.
코드 재사용성은 cfengine은 설정을 재사용하기가 힘들어서 복사를 계속 해야 하는 경우가 생기는데 puppet 에서는 비슷한 설정을 쉽게 재활용할 수 있도록 되어 있습니다. 비슷한 내용이 있다면 그것을 템플릿 등을 이용하여 변수만 넘겨주어서 생성하는 형태이지요.

o Dedication
--> 이 사람들은 이걸로 밥먹고 사는 사람들이니 좀더 집중해서 일을 한다는거죠.

o Decoupling
--> 새로운 타입 추가를 하기가 cfengine은 어렵다는 이야기입니다. 이건 아직 잘 모르겠네요.
흥미로운것은 puppet 서버와 클라이언트는 XMLRPC 프로토콜을 이용하여 통신을 한다는 것입니다. XMLRPC를 지원하는 다른 툴을 이용하여 실행하는것도 가능하지요.

o Development Methodology
--> Reductive Labs also strongly believes that unreadable code is bad code
cfengine은 사람이 이해하는 형태로 관리하는 형태가 아닙니다. 이것은 위에서 순서조정, 관계설정등과 연관이 될 듯 합니다. 설정의 재사용성, 생성의 어려움등.

전체적으로 cfengine 에 비하여 추상화하고 모델링하는 능력이 뛰어나다고 말하고 있습니다.

http://reductivelabs.com/trac/puppet/wiki/TransitioningFromCfengine
여기 나오는 내용을 참고.

Where to Use Puppet
Generally, it's probably best to start out using Puppet to manage elements that Cfengine cannot manage or is not good at managing, such as users, groups, and packages (I know Cfengine can manage a couple of package types, but Puppet supports more types more flexibly). Also, managing services and their dependencies can get very convoluted in Cfengine but are specified directly in Puppet so they're a bit easier to manage.

서비스와 그 연관성을 다루는데 좋습니다.

cfengine 에서 바꿀때 어려운 부분이 editfile이라고 하는군요. /etc/crontab, /etc/rc.d/rc.local 등의 설정을 cfengine 에서 editfile 이용하여 없으면 넣는 형태로 사용중인데 이 부분은 직접 지원하지 않으며 템플릿이나 사용자자 해당 타입을 만들어서 사용하면 된다고 하는데 아직 테스팅해보지는 않았습니다. editfiles 가 설정관리하는데 상당히 편리하거든요.

아뭏든 처음에는 고민을 했는데 개발할때 버전관리시스템을 쓰는 것처럼 시스템 각종 세팅도 로컬에만 둔다면 정리하기도 힘들고 이력관리도 힘듭니다. 처음에는 번거로워도 중앙의 저장소를 이용하는 형태가 맞다고 생각이 듭니다.

> 리 눅스매거진에 나온 글이 하나 있는데 cfengine의 단점을 언급하면서 소개를 하고 있네요.
> 이름은 Puppet 이라고 합니다. 루비로 만들었구요. 제가 지금 당장은 보기 힘들듯한데 언제 한번 봐야겠네요.
> http://www.linux-mag.com/id/4141/
>
> 이 툴이나 이런 비슷한 툴들 써보신 분 혹은 자기만의 방법이 있으면 이야기해주시면 좋을듯한데요. 있으려나???
>
> 지난번에 말을 한대로 cfengine 을 이용하여 모든 서버상의 설정을 중앙의 서버로 옮기니깐 그것자체가 하나의 문서화가 되지
> 요. 실제 아주 작은 설정하나하나를 문서화에 남기지 못하는 경우가 있는데 설정을 로컬에 두는 것이 아니라 관리서버에 두어서 배포
> 하는 형태라고 한다면 이렇게 안할래가 안할수가 없지요. 그런데 cfengine도 써보면서 무언가 불편한듯한 감은 있기는 한데 다
> 른 툴과 비교해보면 좋을 듯 하군요.
>
> 아뭏든 위의 툴 한번 관심있는분 보아보라고 메일 보냅니다.
>
>
>