Chef 또는 Puppet 사용 여부를 결정할 때 올바른 질문은 무엇입니까?

부분적으로 대략 세 가지 다른 클래스의 많은 동일한 노드를 배치해야하는 새 프로젝트를 시작하려고합니다.

• MongoDB의 샤드 인스턴스를 실행할 데이터 노드
• 애플리케이션 노드 -Ruby on Rails 애플리케이션 및 이전 ASP.NET MVC 애플리케이션의 인스턴스를 실행합니다.
• 처리 노드- 애플리케이션 노드가 요청한 작업을 실행합니다.

모든 노드는 Ubuntu 10.04 인스턴스에서 실행되지만 다른 패키지가 설치됩니다.

나는 자신을 전문가라고 생각하지는 않지만 이전 프로젝트의 요리사와 친숙합니다. 실사를하기 위해 다른 가능성을 조사해 왔습니다. 우리는 오랜 기간 Puppet 사용자 인 많은 사람들을 사내에서 찾아 보도록 권장했습니다.

그래도 두 가지 선택을 모두 평가하는 데 어려움이 있습니다. Chef와 Puppet은 패키지 , 리소스 , 속성 등과 같은 여러 도메인 용어를 공유 하며 동일한 문제에 대한 다양한 접근 방식을 통해 얻은 공통된 역사를 가지고 있습니다. 어떤 의미에서 그들은 매우 유사합니다. 그러나이 기사 와 같이 내가 찾은 비교 정보의 대부분은 약간 구식입니다.

오늘이 프로젝트를 시작한 경우 구성 관리에 Chef 또는 Puppet을 사용해야하는지 여부를 결정하기 위해 어떤 질문을 하시겠습니까? (참고 : "셰프 또는 꼭두각시를 사용해야합니까?"라는 질문에 대한 답변을 원하지 않습니다. )

꼭두각시와 요리사 모두 당신이 원하는 것을 잘 할 수 있습니다. 최선의 방법은 수행하려는 작업을 시작하고 가장 마음에 드는 도구를 결정하는 것입니다. 당신이해야 할 큰 질문은 다음과 같습니다.

DSL을 원하십니까? -요리사 레시피는 루비로 작성되며 꼭두각시에는 DSL이 있습니다. DSL이 좋든 나쁘 든 선택은 요리사와 꼭두각시의 가장 큰 차이점 중 하나입니다. 비트 필드 컨설팅의 비교에 게시 한 링크 에는 아직 읽지 않은 경우 읽어야 할 좋은 의견이 있습니다. 또한 이 블로그 게시물이 유용하다는 것을 알았 습니다. 댓글도 읽으십시오.

루비를 아십니까? -루비를 모른다면, 새로운 언어를 배워야하므로 요리사를 시작하는 것이 어려워 지거나 많은 시간이 소요될 수 있습니다. 꼭두각시에는 시작하기 쉬운 자체 언어 가 있습니다. 꼭두각시 2.6부터 매니페스트 도 루비로 작성할 수 있습니다 .

2009 년 오픈 소스 브리지에는 요리사, 꼭두각시, bcfg2, cfengine 및 자동화의 저자 및 대표자로 구성된 패널이 있으며 구성 관리 유틸리티에 대해 1.75 시간 동안 논의한 bliptv에서 볼 수 있습니다.

Opscode / Chef 는 FAQ에서 퍼펫과 퍼펫의 차이점에 대해 설명합니다 .

올바른 질문을 알지 못하는 것은 두 가지 중 하나를 다루는 경험이 많지 않기 때문일 수 있다고 생각합니다. 일단 사용하기 시작하면 그 차이점을 알기 시작할 것입니다. 주방장이나 꼭두각시로 해결할 실제 문제가 생기면 해결을 시도하고 좋아하거나 싫어하는 점을 확인하십시오. Opscode / Chef를 통해 5 개의 노드를 설정하여 무료로 시작할 수 있는 호스팅 된 솔루션 을 제공합니다 .

먼저 말하겠습니다-Puppet 또는 Chef를 사용하지 않는 경우; 오답이 없습니다. 지금하고있는 것보다 훨씬 나을 것입니다.

팀 리더로서 저는 팀을 위해 Puppet을 선택했습니다. 내가 나만의 팀이라면 Chef를 대신 선택했을 것입니다. 이유는 다음과 같습니다.

내 전문 지식은 확실히 시스템 관리에 관한 것이지만 프로그래밍에 관한 배경 지식이 있습니다. 제가 학교에 갔던 것입니다. 대본이 아닌 전체 응용 프로그램을 작성하는 데 익숙하지 않습니다. 루비를 알지 못했지만 저는 원합니다. 요리사는 두 가지를 모두 배우는 데 큰 변명이되었을 것입니다.

그러나 필자의 팀은 간혹 셸 스크립트를 제외하고 프로그래밍 경험이 거의 또는 전혀없는 시스템 관리자로 가득합니다. 꼭두각시 모듈을 작성하는 것은 구성 파일을 작성하는 것과 매우 유사합니다. 선언적이고 반복자가 없으며 전반적으로 관리자 친화적입니다.

sysadmin 활동을하는 개발자로 가득 찬 팀은 Chef를 선호하는 경향이 있습니다. Puppet의 DSL은 선언적이므로 순서 (개별 파일 내에서도)는 중요하지 않으며보다 일반적인 프로그래밍 언어에 익숙한 많은 사람들을 실망시킵니다.

또한 Chef가 Puppet보다 클라우드에 훨씬 친숙하다고 여러 번 들었지만 Puppet은 작년에 Puppet Enterprise 제품에 중점을 두었습니다. 두 제품의 클라우드 기능에 대한 경험으로는 말할 수 없습니다.

위의 특성으로 인해 고정 관념은 (그리고 종종 올바른 것입니다) Chef가 클라우드에서 스타트 업을 지배하는 실제 머신의 엔터프라이즈에서 Puppet이 더 널리 퍼져 있다는 것을 알게 될 것입니다. 물론 예외가 있지만 내가 본 것은 확실히 고정 관념을 뒷받침합니다.

1 인 팀인 경우 두 팀을 모두 평가하고 원하는 팀을 선택하십시오. 그러나 나와 같은 팀을 보유하고 있다면 팀의 요구 사항을 개인 취향보다 우선 순위로 유지해야 나중에 구매를 시도 할 때 비용을 절약 할 수 있습니다.

전체 공개, 우리는 구성 관리 시스템을 결정할 때 내부적으로 평가했지만 이들 중 하나를 사용하지 않습니다. 결국 저 중 하나에 대해 전문가라고 생각하지 마십시오.

• 인스턴스 설정이 얼마나 쉬운가요?
• 서버와 통신하려면 클라이언트에 어떤 설정이 필요합니까?

등등. 그러나 당신은이 질문들에 아주 쉽게 대답 할 수 있습니다. 각 제품마다 샘플을 준비하고 실행하는 데 몇 시간이 걸리며,이 제품을 사용하는 모든 제품이 오랫동안 사용될 가능성이 높다는 점을 고려하면 그만한 가치가 있습니다. 플랫폼 별 작업 (예 : 데비안 기반 및 apt, RPM 기반 및 yum)을 처리하는 방법에 대한 느낌뿐만 아니라 응용 프로그램에 대한 느낌을 얻는 데 도움이 될 것입니다.

또한 세계의 모든 기능이 어려운 인터페이스를 구성하지는 않으며 인프라와 관련된 문제, 예를 들어 구성 파일이 다른 순서로 업데이트되는 경우 발생할 수 있음을 명심하십시오. 예상보다?

이것이 저의 조언입니다. Chef와 Puppet은 하나의 서버와 하나 또는 두 개의 클라이언트 설정을 얻는 것이 어렵지 않으며 두 가지 모두에 대한 직접적인 경험을 제공합니다. 또한 설정을 시작하고 큰 고통을 느끼면 커밋하기 전에 이미 지식이 있습니다.

프로젝트에 이미 Puppet에 대한 경험이있는 사람들이 있다면 Puppet을 사용하는 것이 좋습니다.

Chef와 Puppet은 상당히 유사하며 두 프로젝트 모두 똑같이 고품질입니다. 이미 Puppet 경험이있는 사람에게 액세스 할 수있는 경우 Puppet을 사용하십시오.

위의 내용은 확실히 좋은 지침이며 새로운 제 3 자의 의존성을 고려할 때마다 이러한 일반적인 질문을하고 싶습니다.

• 프로젝트의 나이는 무엇입니까?
• 커뮤니티 (메일 링리스트, 버그, irc 등)는 얼마나 활발합니까?
• 우수한 실무 문서가 표준 사례와 함께 제공됩니까?

이는 프로젝트의 전반적인 성공을 나타내는 좋은 지표이며 수명을 다소 예측할 수 있습니다.

몇 달 이상 Chef 또는 Puppet을 사용한 사람들을 찾아서 그들의 경험에 대해 물어보십시오.

나에게 그것은 특정 공동체의 전통과 밀접하게 관련되어 있습니다. 역사적으로 Chef는 RubyOnRails 사람들과 더 가까웠습니다. Engineyard가 Chef 위에 인프라를 구축했기 때문에 ROR 커뮤니티에서 가장 인기있는 Chef 조각입니다.