ChefとPuppetのどちらを使用するかを決定する際に尋ねる正しい質問は何ですか？
新しいプロジェクトを開始しようとしています。このプロジェクトでは、約3つの異なるクラスの多数の同一ノードをデプロイする必要があります。
- MongoDBのシャーディングされたインスタンスを実行するデータノード。
- アプリケーションノード、Ruby on Railsアプリケーションと古いASP.NETMVCのインスタンスを実行します応用。
- 処理ノード。アプリケーションノードから要求されたジョブを実行します。
すべてのノードはUbuntu10.04のインスタンスで実行されますが、異なるパッケージがインストールされます。
私は以前のプロジェクトのChefにある程度精通していますが、自分自身を専門家とは見なしていません。デューデリジェンスを行うために、私は代替の可能性を調査してきました。社内にはPuppetの長年のユーザーである多くの人々がいて、彼らは私に見てみるように勧めてくれました。
しかし、私は両方の選択肢を評価するのに苦労しています。 ChefとPuppetは、同じドメイン用語の多くを共有しています-packages、resources、attributesなど、同じ問題に対して異なるアプローチを取ることから生じる共通の歴史があります。したがって、ある意味でそれらは非常に似ています。しかし、 この記事 のように、私が見つけた比較情報の多くは少し時代遅れです。
今日このプロジェクトを開始する場合、構成管理にChefとPuppetのどちらを使用するかを決定するためにどのような質問をしますか？ （注：「シェフまたはパペットを使用する必要がありますか？」という質問への回答はしたくない）
PuppetとChefはどちらも、あなたが望むことをうまく行うことができます。あなたの最善は、あなたがやろうとしていることを始めて、あなたが一番好きなツールを決めることです。私はあなたが尋ねなければならない大きな質問は次のとおりだと思います：
DSLが必要ですか？-シェフのレシピはRubyで書かれており、人形にはDSLがあります。 DSLが良い選択か悪い選択かは、chefとpuppetの最大の違いの1つです。あなたが投稿したリンク ビットフィールドコンサルティングの比較 には、まだ読んでいない場合に読むべき、これに関するいくつかの良いコメントがあります。また、 このブログ投稿 便利でした。コメントも必ず読んでください。
rubyを知っていますか？-Rubyを知らない場合、シェフを始めるのは難しいか、必要なためより多くの時間を必要とする可能性があります新しい言語を学ぶ。 Puppetには 自国語 があり、簡単に始めることができます。 puppet 2.6以降、 マニフェストはRubyで記述できます も。
2009年のオープンソースブリッジでは、chef、puppet、bcfg2、cfengine、automatiitの作成者と代表者のパネルがあり、構成管理について1.75時間のディスカッションがあります bliptvで見る ユーティリティ。
Opscode/Chefは、それとpuppetの違いについて話します FAQで も同様です。
質問するのに適切な質問がわからないのは、どちらかを使った経験があまりないことが原因かもしれないと思います。使い始めると、違いがわかります。シェフやパペットで解決する実際の問題をいくつか考えてから、それらを解決しようと試み始めて、あなたがそれらについて好きなもの/嫌いなものを確認することをお勧めします。 Opscode/Chefを使用すると、 ホスト型ソリューションを提供 5つのノードを無料でセットアップして開始できます。
最初に言わせてください-PuppetもChefも使用していない場合。間違った答えはありません。どちらもあなたが今していることよりもはるかに良くなるでしょう。
チームリーダーとして、私は自分のチームのためにPuppetを選択しました。もし私が自分だけのチームだったら、代わりにシェフを選んだでしょう。理由は次のとおりです。
私の専門知識は確かにシステム管理ですが、私のバックグラウンドはプログラミングです。それは私が学校に通った目的であり、私は完全なアプリケーション（スクリプトだけでなく）を書くことに不思議ではありません。私はRubyを知りませんでしたが、知りたいので、Chefは両方を学びに行くための素晴らしい言い訳になりました。
ただし、私のチームは、時折シェルスクリプトを除いて、プログラミングの経験がほとんどまたはまったくないシステム管理者でいっぱいです。彼らにとって、puppetモジュールの作成は、構成ファイルの作成によく似ています。これは宣言型であり、イテレーターはなく、全体的に管理者にとってより使いやすいものです。
Sysadminアクティビティを実行する開発者でいっぱいのチームは、Chefを好む傾向があります。 PuppetのDSLは宣言型であるため、（個々のファイル内であっても）順序は重要ではなく、より一般的なプログラミング言語に慣れている多くの人を苛立たせます。
ChefはPuppetよりもはるかにクラウドフレンドリーであると何度も言われていますが、Puppetはこの1年でPuppetEnterprise製品に焦点を当てています。どちらの製品のクラウド機能についても、経験から話すことはできません。
これらの上記の品質のために、ステレオタイプ（そしてそれはしばしば正しい）は、Chefがクラウドのスタートアップを支配する物理マシン上の企業でPuppetがより普及していることがわかるということです。もちろん例外はありますが、私が見たものは確かにステレオタイプを裏付けています。
1人のチームの場合は、両方を評価して、どちらが好きかを選択します。ただし、私のようにチームがいる場合は、個人的な好みよりもチームのニーズを優先するようにしてください。後でバイインを試みたときに節約できます。
完全な開示であり、構成管理システムを決定する際に内部で評価しましたが、どちらも使用していません。だから、結局私をこれらのどちらかについての専門家と見なさないでください。
- インスタンスのセットアップはどれくらい簡単ですか？
- クライアントがサーバーと通信するには、クライアントでどのような設定が必要ですか？
等々。しかし、これらの質問には自分で非常に簡単に答えることができます。設定してください。サンプルを立ち上げて実行するのは、製品ごとに数時間かかります。これを使用するものは何でも長期間使用される可能性があることを考えると、その時間は十分に価値があります。プラットフォーム固有のもの（Debianベースとapt、RPMベースとyumなど）をどのように処理するかを理解できるだけでなく、アプリケーションの感覚を確実に得るのに役立ちます。
また、世界中のすべての機能が難しいインターフェイスを補うわけではないことにも注意してください。さらに、インフラストラクチャに固有の問題が発生する可能性があります。つまり、構成ファイルが異なる順序で更新された場合はどうなりますか。予想以上に？
それが私のアドバイスです。 ChefとPuppetは、1つのサーバーと1つまたは2つのクライアントをセットアップするのはそれほど難しいことではなく、両方を直接体験できます。さらに、セットアップを開始してその大きな苦痛に気付いた場合は、コミットする前にすでに知識を持っているはずです。
プロジェクトにすでにPuppetの経験がある人がいる場合は、Puppetを使用することをお勧めします。
ChefとPuppetはかなり似ており、どちらのプロジェクトも同じように高品質です。すでにPuppetの経験がある人にアクセスできる場合は、Puppetを使用してください。
上記は間違いなく良いガイドラインです。また、新しいサードパーティの依存関係を検討するときはいつでも、これらの一般的な質問をするのが好きです。
- プロジェクトの時代は何歳ですか？
- コミュニティ（メーリングリスト、バグ、ircなど）はどの程度活発ですか？
- 優れた堅実なドキュメントが標準的な方法で提供されていますか？
これらはプロジェクトの全体的な成功の良い指標であり、寿命をある程度予測することができます。
私にとって、それは特定のコミュニティの伝統と密接に関連しています。歴史的に、シェフはRubyOnRailsの人たちに近かった。 EngineyardがChefの上にインフラストラクチャを構築したため、RORコミュニティでもChefの人気の大きな部分です。
ChefまたはPuppetのいずれかを2か月以上使用している人を見つけて、彼らの経験について尋ねてみてください。