Chefを使用するかPuppetを使用するかを決定するときに尋ねる正しい質問は何ですか？

私は、約3つの異なるクラスの多くの同一ノードをデプロイすることを部分的に必要とする新しいプロジェクトを開始しようとしています。

• データは、ノードのMongoDBのシャードのインスタンスを実行します、。
• アプリケーションノード。Rubyon Railsアプリケーションと古いASP.NET MVCアプリケーションのインスタンスを実行します。
• 処理ノード。アプリケーションノードによって要求されたジョブを実行します。

すべてのノードはUbuntu 10.04のインスタンスで実行されますが、異なるパッケージがインストールされます。

私は以前のプロジェクトのChefにある程度精通していますが、自分を専門家とは考えていません。デューデリジェンスを行うために、私は代替の可能性を調査しています。社内には、Puppetを長年使用している人がたくさんいます。彼らは私に見てみるように勧めています。

しかし、私は両方の選択肢を評価するのに苦労しています。ChefとPuppetは、パッケージ、リソース、属性など、多くの同じドメイン用語を共有しており、同じ問題に対して異なるアプローチをとることに由来する共通の歴史を持っています。ある意味で、それらは非常に似ています。しかし、私が見つけた比較情報の多くは、この記事のように、少し時代遅れです。

今日このプロジェクトを開始する場合、構成管理にChefとPuppetのどちらを使用すべきかを判断するために、どのような質問を自問しますか？（注：「ChefまたはPuppetを使用する必要がありますか？」という質問には答えたくありません。）

PuppetとChefの両方が、あなたがうまくやりたいことをすることができます。あなたの最善は、あなたがやろうとしていることを始めて、あなたが最も好きなツールを決めることです。あなたがしなければならない大きな質問は次のとおりだと思います：

DSLが必要ですか？-シェフのレシピはルビーで書かれており、人形にはDSLがあります。DSLが良いか悪い選択かは、シェフとパペットの最大の違いの1つです。ビットフィールドコンサルティングの比較に投稿したリンクには、これに関するいくつかの良いコメントがあります（まだ読んでいない場合）。また、このブログの投稿が有用であることがわかりました。コメントも必ず読んでください。

ルビーを知っていますか？-ルビーがわからない場合、シェフを始めるのは難しくなるか、新しい言語を学ぶ必要があるため、より多くの時間を費やす必要があります。Puppetには、使いやすい独自の言語があります。パペット2.6以降、マニフェストはルビーでも記述できます。

2009年のオープンソースブリッジでは、作者とシェフ、パペット、bcfg2、cfengine、およびautomateitの代表者のパネルがあり、構成管理ユーティリティに関する1.75時間の議論があるbliptvで見ることができます。

Opscode / Chef は、よくある質問でもそれとパペットの違いについて語っています。

適切な質問を知らないのは、どちらかを使用した経験があまりないためであると考えられます。使用を開始すると、それらの違いがわかるようになります。シェフやパペットで解決する現実の問題をいくつか見つけて、解決してみて、好きなもの/嫌いなものを見てみることをお勧めします。Opscode / Chefを使用すると、 5つのノードを無料でセットアップして開始できるホスト型ソリューションが提供されます。

まず、PuppetとChefのどちらも使用していない場合、間違った答えはありません。どちらもあなたが今していることよりもはるかに良いでしょう。

チームリーダーとして、私は自分のチームにPuppetを選択しました。私が自分のチームだったら、代わりにシェフを選んだでしょう。その理由は次のとおりです。

私の専門知識は確かにシステム管理ですが、私のバックグラウンドはプログラミングです。それは私が学校に通ったものであり、完全なアプリケーション（スクリプトだけでなく）を作成するのは見知らぬ人ではありません。私はRubyを知らなかったが、私はそれを望んでおり、シェフは両方を学びに行くための素晴らしい口実だっただろう。

しかし、私のチームは、時折シェルスクリプトを除き、プログラミング経験がほとんどないシステム管理者でいっぱいです。彼らにとって、Puppetモジュールの作成は、構成ファイルの作成によく似ています。これは宣言型であり、イテレータはありません。全体的に管理しやすいです。

sysadminアクティビティを行う開発者でいっぱいのチームは、Chefを好む傾向があります。PuppetのDSLは宣言型であるため、順序（個々のファイル内であっても）は重要ではありません。これは、より一般的なプログラミング言語に慣れている多くの人を苛立たせます。

ChefはPuppetよりもはるかにクラウドフレンドリーであると何度も言われていると聞きましたが、Puppetはこの1年でPuppet Enterprise製品に焦点を当てています。どちらの製品のクラウド機能に関する経験からも話せません。

上記の品質のために、ステレオタイプ（多くの場合正しい）は、Chefがクラウド内のスタートアップを支配する物理マシン上の企業でPuppetがより普及していることを見つけることです。もちろん例外もありますが、私が見たことは確かにステレオタイプを支持しています。

一人のチームの場合は、両方を評価して、どちらを選ぶかを選択します。ただし、私のようにチームがある場合は、個人的な好みよりもチームのニーズを優先するようにしてください。そうすれば、後でバイインしようとするときに節約できます。

完全な開示、これらのいずれも使用しませんが、構成管理システムを決定する際に内部的に評価しました。結局のところ、私はこれらのいずれかの専門家だとは思わないでください。

• インスタンスのセットアップはどれくらい簡単ですか？
• クライアントがサーバーと通信するためには、クライアントでどのような設定が必要ですか？

等々。ただし、これらの質問には自分で簡単に答えることができます。設定してください。サンプルを入手して実行するのは、各製品の数時間の時間であり、これを使用するものは何でも長期間使用される可能性が高いことを考えると、その価値は十分にあります。プラットフォーム固有のもの（すなわち、Debianベースとapt、RPMベースとyum）をどのように処理するかを感じることができるだけでなく、アプリケーションの雰囲気をつかむのに役立ちます。

また、世界のすべての機能が難しいインターフェイスを補うわけではないことに注意してください。さらに、インフラストラクチャに固有の問題を公開する可能性があります。つまり、構成ファイルが異なる順序で更新されるとどうなりますか予想以上に？

それが私のアドバイスです。ChefとPuppetは、1台のサーバーと1台または2台のクライアントをセットアップするのがそれほど難しくなく、両方で直接体験できます。さらに、設定を開始してその大きな痛みに気付いた場合、それに取り組む前にすでに知識を持っているでしょう。

プロジェクトに既にPuppetの経験がある人がいる場合は、Puppetを使用することをお勧めします。

ChefとPuppetはかなり似ており、どちらのプロジェクトも同様に高品質です。すでにPuppetの経験がある人にアクセスできる場合は、Puppetを使用してください。

上記は間違いなく良いガイドラインです。また、新しいサードパーティの依存関係を検討するときはいつでも、これらの一般的な質問をするのが好きです。

• プロジェクトの年齢は？
• コミュニティはどの程度活発ですか（メーリングリスト、バグ、ircなど）？
• 優れた堅実なドキュメントが標準的なプラクティスとともに提供されていますか？

これらはプロジェクトの全体的な成功の良い指標であり、寿命をある程度予測できます。

ChefまたはPuppetのいずれかを2か月以上使用している人を見つけて、彼らの経験について尋ねます。

私にとっては、特定のコミュニティの伝統と密接に関係しています。歴史的に、シェフはRubyOnRailsの仲間に近かった。EngineyardがChefの上にインフラストラクチャを構築したため、RORコミュニティでChefの人気の大部分を占めています。