18

いつ、どのような状況でパペットを使用し、いつシェフを使用するかについてお聞きしたいと思います。また、単一のサーバーをその構成に反復し、それを一連のサーバーにプッシュして、変更を直接確認できるようにする、パペットソロタイプのものであるrumpも見つけました。

私の質問: 上記のどれをどのように使用すればよいですか? 誰かが私を助けることができますか？

私の目的は、rake と git を使用した mono/.Net 環境での継続的インテグレーション、継続的デプロイのコンテキストにあります。Web アプリケーションを簡単にパッケージ化、バージョン管理、および展開したいと考えており、複数の Web サーバーのロード バランサーに recepies を使用したいと考えています。これらを迅速に停止でき、アップグレード間のダウンタイムがありません。

4

5 に答える 5

27

両方を使用したので、それはあなたが探しているものに依存すると思います. 私の意見では：

  • Chefはより開発者向けです。あなたが Ruby の第一人者なら、きっと気に入るはずです。

  • Puppetはよりsysadmin指向です。Ruby 以外の DSL を使用しているため、マシンに間違いを伝播するのはより困難です (imho)。

Puppetはより読みやすく安定したコードを作成しますが、新しい機能の展開も遅くなります。それはおそらく、DevOps の仕事を強く信じている大企業の構造で望むものです。

Chefを使用すると、より少ないコードと時間の労力で複雑なタスクを実行できます。Puppet コンストラクトを作成しなくても、すべての ruby​​ マジックを使用できます。これは、たとえば、あなたの会社が DevOps の価値を本当に信じておらず、マネージャーが間違っていることを証明するために常に時間と格闘している場合に適しています :-) 私は個人的に、新しい機能を開発するときに Puppet の実行が少し遅いと感じています。少し痛いかもしれません。

私の提案は次のとおりです。ある程度の開発スキルを持つシステム管理者であれば、Puppet を選択してください。Ruby (または Python) に慣れている場合は、Chef を選択してください。

私もランプを試してみて、それで遊んでいます。それは役に立ち、クールですが、 puppet apply -vd --modulepath=の代わりにrump goの遅延入力を除いて、まだ大きな価値はありません。モジュール/マニフェスト/init.pp . :)

于 2012-03-21T14:28:32.130 に答える
15

私は Puppet を使用しますが、Puppet についての本を書き、そこで働いているので、ちょっと偏見があります。:) Rump に加えて、Puppet を適用モードで使用することもできます。これは、chef-solo と同じです。ただし、Rump は、試してみる価値のあるプロセスに優れた点をいくつかラップしています。

ここでは、ラップ アラウンドとして Rump を使用して Puppet を試してみます。Puppet DSL または Ruby DSL の両方を使用できます (Chef は Ruby DSL しか持っていません)。Puppet を使用して「環境」を作成し、git/CI ワークフローをデプロイに統合するのは非常に簡単です。また、Rake タスクなどとの統合も簡単です。

于 2011-06-20T20:57:20.653 に答える
10

最終的に、パペット マニフェストを実行/再実行/テストできるpuppet + vagrantになりました。

最初に VirtualBox をインストールしてから、次の手順を実行します。

gem install puppet
gem install vagrant

それから：

vagrant box add base http://files.vagrantup.com/lucid32.box
vagrant init

次に、./Vagrantfile を次のように編集します。

Vagrant::Config.run do |config|

  config.vm.box = "base"
  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = "manifests"
    puppet.module_path = "modules"
  end

  # rest here
end

次に、次のようにノード定義を に追加しますmanifests/default.pp。

group { "puppet":
  ensure => "present",
}
file { '/etc/motd':
    content => "Welcome to your Vagrant-built virtual machine!\n"
}

次に実行します：

vagrant up

これで、操作できる puppet で管理された仮想マシンができました。変更したマニフェストはすべてソース管理に入ります。また、ランプに頼ることなく、すばやく反復できます。

于 2012-06-11T17:34:01.163 に答える
5

Rubyに精通している場合は、PuppetよりもChefを試してみることをお勧めします。chef＆rubyを使用すると、非常に複雑なタスクを実行できます。ただし、puppetはchefよりもクリーンなドメイン定義です。良いかどうか、すべてあなたの実際の仕事まで。

于 2011-11-29T15:52:29.000 に答える
5

言及されていない Puppet と Chef のもう 1 つの大きな違いは、Puppet がすべてのマニフェスト コンパイルをサーバー上で実行するのに対し、Chef (および cfengine) はクライアント上で一部またはすべての作業を実行することです。

これが意味することは、* puppet を実行することによるクライアントの CPU フットプリントが少なくなり、* Puppet で記述されたアドイン モジュールがサーバー上でのみ実行されることです。

2 番目の部分は重要です。これにより、Puppet を他のアーキテクチャと統合することがはるかに簡単になります。たとえば、別のアプリケーションから API を介してデータをプルする場合、Puppet では、必要な API モジュールを Puppetmaster にインストールするだけで済み、その 1 つのサーバーに API へのアクセスを許可するだけで済みます。必要なすべての資格情報も puppetmaster に残ります - はるかに安全です。

Puppet と SecretServer が統合されています (puppet を使用してルート パスワードを自動ローテーションし、SecretServer に保存するため)。私がモデルを理解しているように、これはChefの下では不可能であり、安全ではありませんでした。

于 2013-06-13T00:42:02.897 に答える