책이야기 - Automating UNIX and Linux Administration 2판, 24시간 365일 서버/인프라를 지탱하는 기술

serverfault.com 에서 관련주제를 몇가지 찾아보았습니다.
유사한 주제로 아래 글을 읽어보았네요. (링크는 밑에 적었음)

cfengine, puppet 모두 멀티플랫폼을 지원하지 않는 단점이 있습니다. 윈도우에 cygwin 등을 이용하여 올릴 수는 있지만 이게 잘 작동할지는 잘 모르겠습니다.

단일한 os기반이라면 cfengine 설치에 대해서 고민을 할 일은 없을 듯하고 puppet 은 ruby 언어를 따로 설치해야하는 부담이 있지만 툴 나름대로의 유용함이 있다면 큰 문제는 아닐 듯 합니다.

말씀하신대로 cfengine 이나 puppet 이 제공하는 좋은 기능이 있겠지만 역으로 이때문에 관리부하가 생길 가능성이 있고 조그마한 실수에도 큰 문제가 생길 수 있습니다. 어떠한 툴을 쓰느냐에 상관없이 관리를 체계적이고 효율적으로 할 수 있는 기반시스템과 정책등이 있어야 하는데 이건 aero님이 말을 한대로 한다고 하더라도 계속 부딪치는 문제이겠지요.
cfengine 이나 puppet 의 경우도 해당 툴을 사용하는 것으로 끝나는 것이 아니라 호스트에 대한 관리, 그룹관리 등을 할 수 있는 시스템이 받쳐주어야 하지요. 이건 어떤 툴을 쓰더라도 마찬가지겠지요.

slack 은 문서가 아직은 별로 제공이 되지 않는 듯 하여 제공하는 기능을 잘은 모르겠네요. 천상 살펴보려면 프로그램 다운로드 받아서 소스보고 연구가 필요할 듯.

끙~~ 아뭏든 저도 잘 결론이 안 나네요.

http://serverfault.com/questions/465/automating-server-deployment

Where I am working at the moment, we have to manage the Linux portion of our server farm which is just over 300 Linux servers. This includes mostly HP Proliants, followed by IBM 3850s, some IBM blades, VMware ESX, and some KVM for our internal management servers.
cobbler

We looked at cobbler but the problem there was that cobbler is very RHEL/Red Hat specific. We need to support RHEL and SLES at the least, and Ubuntu is next.
puppet

We did consider puppet, however later decided against it as it depends on Ruby, which means that an upgrade of Ruby, could potentially break our management system.
hotwire

Hotwire is what we use (developed internally, but is open-source), and have done so for the last few years. It firstly inventories the systems that are going to be built, which means inventorying the data-center, rack, hardware, operating system, network, etc, and secondly perform the rapid build & deploy. Once the system is built, hotwire's auto-inventory keeps the inventory in-sync, while cfengine maintains them. Hotwire knows about the server hardware by talking to the SMBIOS/DMI data in the Bios via python-dmidecode.

The bonus points are that it is combines the inventory and build process into one, so there's less to manage, and the live-inventory feature is great as we know if something is not quite right.

The disadvantages are that the user-interface still needs polishing, and there are bugs here and there, but development is still hot, and bugs reported are fixed relatively fast.
cfengine

We use cfengine because other than it, and puppet, there is nothing else. It actually is a good tool, but "good" only as a function of how good your policies are - if you set dangerous policies, then a small mistake can cause alot of damage. For example, by policy, we don't "modify" files, we either replace them, or we don't. Also all files replaced have a header that makes any person editing it know that it will be replaced the next time it runs (it is run via cron hourly).

The configuration and all files pushed out by cfengine to the servers are also kept in a SCM, and using post-commit hooks, where possible, we check the syntax and if that fails, then the commit is rejected. This is easy for nice applications such as Apache, but not so easy for most enterprise applications.

---------------------------
문태준
http://groups.google.co.kr/group/sysadminstudy 시스템어드민 공부모임
http://tunelinux.pe.kr
http://database.sarang.net