Puppet vs Chef, 사용자 및 사용 사례의 콘트라스트 [닫기]

나는 이미 googled하고 "꼭두각시 또는 요리사에게 그 질문" 기사를 읽었다 .

나는 사람들이 실제 문제 기반에서 하나 또는 다른 것을 선택한 실제 구현, 유스 케이스에 관심이 있습니다.

나는 특히 Cobbler 이슈 와의 통합에 관심이있다 (나는 꼭두각시가이 방향에서 표준 접근 방식이라는 것을 알고있다). cobbler-chef 통합 경험이 있습니까?

미리 감사드립니다

솔직히 말해서 이것은 간단한 견해에 달려 있다고 생각합니다. 셰프는 명령형, 프로그래밍 방식의 솔루션, 언어로 루비를 사용하면 누군가가 파이썬으로 포팅하기를 희망합니다. 루비의 아이디어.

그래도 당신이 원하는 것은 아닙니다. 시스템이있는 빈 공간에 대해 말하고 선언 하려고합니다 .

"북쪽에서 nginx라는 데몬에서 포트 80을 소환합니다. 그의 임무는 서빙하는 것입니다."

"사용자는 존재해야하고, 그의 이름은 거칠고 휠 그룹에서 강력한 사람 중 하나 여야합니다."

"80,443,8080 장소에 얇은 불의 벽을 올리십시오"

그리고 아마도 언어가 덜 꽃이지만.

꼭두각시는 그 패러다임을 더 잘 지원합니다. 나는 둘 중 하나를 사용했지만 선호도는 없지만 선언이 나에게 더 적합했습니다.

인형.

여기에 Chef vs Puppet에 대한 자세한 비교를 작성했습니다. Puppet vs Chef : Puppet이이기는 10 가지 이유 . 유스 케이스는 포함되어 있지 않지만 인프라 자동화를 위해 어떤 도구를 선택할지 궁금해하는 사람들에게 유용한 시작점을 제공하기를 바랍니다.

자세한 내용에 대해 죄송합니다. 작업을 쉽게 수행 할 수있는 도구를 사용하십시오. 이것이 자동화의 핵심입니다.

역사 : 나는 지난 공연에서 꼭두각시를 사용했고 지난 달에 나는 새로운 공연에서 전환을 할 것인지 요리사에게 익숙해 지려고 일주일을 보냈다.

나는 도약하지 않았다.

전문 용어 :이 두 시스템의 불행한 문제 중 하나는 전문 용어 과부하입니다. (레시피, 템플릿, 노드, 역할, 속성, 공급자) 계속 진행됩니다. 요리사가 한 걸음 더 나아 갔다는 것을 알았습니다. (나이프, 선반 등)

코드 성숙도 : 요리사가 너무 생생하다고 생각하면 충분합니다. 3-4 년 전의 .21 / .22 시간대에서 꼭두각시가 느꼈던 것과 매우 흡사합니다. 많은 플럭스가 진행되고 있습니다.

꼭두각시에서도 일어나지 않았다는 것은 말할 것도 없습니다. (나는 지난 몇 년 동안 만 등장한 꼭두각시의 많은 훌륭한 기능을 다시 발견했습니다.-정규식 일치!)

Ruby : Chef의 모든 루비 과부하가 마음에 들지 않았습니다. (시작하기 전에 보석과 갈퀴가 필요합니다.) 꼭두각시 인형의 복잡한 문제를 해결하기 위해 루비를 사용할 수 있지만 원치 않으면 꼭 할 필요는 없습니다.

복잡성 : 나는 GUI에 대한 요리사의 초점이 마음에 들지 않았다. 나는 그것이 예쁘고 꼭두각시가 추가 기능으로 작품에 웹 인터페이스를 가지고 있지만 더 분리되어야한다고 생각합니다.

Chef는 훨씬 더 복잡한 아키텍처를 가지고 있습니다. 확장 성이 좋을 수 있지만 잠재적 인 실패 지점이 많이 있습니다.
http://wiki.opscode.com/display/chef/Architecture

Chef는 API 서버 및 웹 인터페이스 외에 couchdb, rabbitmq 및 solr이 필요합니다.

MVC 프레임 워크가 필요없는 간단한 클라이언트 / 서버 인터페이스와 그 뒤에 복잡한 데이터 저장소가 필요합니다.

퍼펫은 해당 부서에서 훨씬 간단합니다. (더 지저분한 만들기 위해 추가 기능이 많지 않다는 것은 말할 것도 없습니다)

일을 끝내기 : 결국, 나는 내가 아는 것과 함께 갔다. 일주일 동안의 해킹을 보내고 간신히 요리사와 함께 기본 사항을 완성한 후, 꼭두각시로 돌아가서 몇 시간 만에 기본 요구 사항을 해결할 수있었습니다. (패키지 관리, 사용자 관리, 구성 파일 템플릿)

모듈에 대한주의 사항 : Puppet은 최근 타사에서 제공하는 "모듈"사용으로 전환했습니다. 나는 이것들을 사용하지 않았고 그들의 품질에서 광범위한 것을 발견했습니다. 덮개 아래를 들여다보고 파고 들기 전에 그들이 무엇을 어떻게 작동하는지 확인하십시오.

여기에 의견이 있습니다. 우리는 회사에서 모든 것을 시도했으며 꼭두각시를 선호합니다. 사용하기 쉽기 때문입니다.

다른 구성으로 1000 개의 호스트를 관리하는 것이 꼭두각시로 훨씬 쉬운 경우를 직접 보았습니다. 실제로 Google과 같은 회사는 배포에 꼭두각시를 사용합니다.

꼭두각시의 주요 디자인 아키텍처는 올바른 방식으로 구성하면 다른 것보다 훨씬 잘 작동합니다. 예를 들어 사용자 정의 구성 등에 대한 사용자 정의 사실을 추가하는 경우 아래 링크는 http://slashroot.in/puppet-tutorial-installing-puppet-master-and-puppet-agent에 대한 정보를 제공 할 수 있습니다 .

http://slashroot.in/puppet-tutorial-how-does-puppet-work

지난번 시도한 이후로 변경되었을 수도 있지만 RHEL에서 요리사를 시도 할 때 설치하는 명확한 방법이 없었습니다. 누군가가 필요한 모든 패키지가 포함 된 yum 저장소를 만들었지 만 결국 200 개의 이상한 패키지가 설치되었습니다. 반면 퍼펫에는 단일 rpm (및 두 개의 종속성)이 있습니다.