Articles

Chef vs Puppet: Differences, Similarities, and How to Choose

by admin

今日は、構成管理のための2つの人気ツール、ChefとPuppetを互いに戦わせます。 これらのタイプのツールは、エンジニアがすべてのサーバーで一貫した構成を維持するのに役立ちます。 例えば、すべてのサーバは HTTPS アクセスのためにポート 443 にバインドされた IIS を持ち、インバウンドトラフィックのためにそれぞれのファイアウォールルールを持つ必要があるかもしれません。 より重要なのは、誰かがファイアウォールルールを削除した場合、この種のツールはファイアウォールルールを再度作成することで一貫性を保つことです。

開発、テスト、プロッドで異なるデータベース接続文字列を持っている場合はどうでしょうか。

はい、Puppet または Chef はこれらも処理できます。 これらは、一貫した状態を維持するという同じ目標を達成する、非常によく似たツールです。 しかし、すべてのデリバリーパイプラインを通じて一貫性と再現性を維持するためにユーザをどのように支援するかという点でも、両者は異なります。 最後に、あなたのニーズやチームのニーズに応じて、1 つのツールをもう 1 つのツールよりも選択する方法についてお話します。

では、本題に入りましょう。

Tip: Stackify Retrace でアプリケーション エラーとパフォーマンスの問題を即座に見つける
エラー、ログ、コード レベルのパフォーマンスの洞察を統合すると、コードのトラブルシューティングと最適化が簡単になります。
Try today for free

Similarities

Chef と Puppet にはサーバーの構成を管理する方法において類似した部分があります。 両方のツールが内部的に異なる方法で動作していても、結果は同じです。 両方のツールで、コードを通して望ましい状態を定義できます。 どちらのツールも、マスターがすべてのデータの保存を担当し、ノードがサーバーが常に望ましい状態の構成を持つようにするマスター-ノード・アーキテクチャで動作します。

たとえば、構成管理に Chef や Puppet を使用する主な目的の 1 つは、サーバーのグループの望ましい状態をコードで定義できるようになることです。 同じ構成をサーバに適用したい場合でも、Chef や Puppet は独立した方法で変更を実装することを確認します。 同じように、私たちは皆、Ctrl + Sを何度も押して、変更を保存していることを確認します。 しかし、この種のツールが優れているのは、誰かが手動でサーバーに入り、サーバーの望ましい状態を変更した場合、これらのツールはサーバーを再設定して最新の状態にすることです。

アーキテクチャの観点からは、Chef と Puppet はどちらもマスター・エージェント・アーキテクチャを使用しているのでかなり似ています。 マスターノードには、すべてのサーバーの設定が保存されます。 両ツールのマスターは高可用性（HA）ですが、若干の違いがあります（これについては後述します）。 そして、管理したい各サーバーにはエージェントがインストールされ、そのエージェントが自動的にコンフィギュレーションを取得する。 エージェントは常に、望ましい状態が順守されているかどうかをチェックしているのであって、その逆ではない。

最後に、どちらのツールにもオープンソース版と、より優れたHA設定などの機能を持つ有料版があります。

Differences

前に、ChefとPuppetのアーキテクチャは似ていると言いましたが、HAの扱い方について若干の違いがあります。 Puppetでは、マスターが別のサーバーにデータをレプリケートし、アクティブ/パッシブ方式で動作します。 Chef の場合、HA は水平方向に拡張できる API フロントエンドを備えた 3 台のサーバーでアクティブ/アクティブに処理されます。

Chef と Puppet の大きな違いは、サーバーの望ましい状態構成をどのように定義するかという点です。 それぞれのツールは独自のドメイン特化言語 (DSL) を持っています。 ChefはDSLにRubyを使用しています。 プログラム言語を使っているため、複雑な構成を作る自由度が高いです。 Chefはこの望ましい状態の構成をレシピと呼んでいます。 Rubyでできることは、Chefでもif条件や他のライブラリの呼び出しなど、レシピを作るためにできることがあります。 これによるメリットは、開発者がChefレシピを書きやすく感じるかもしれないことです。 さらに、開発者は設定を定義するときに追加する DSL のみに制限されていると感じないでしょう。

一方、Puppet には独自の DSL があり、「これはシステム管理者がアクセスできるように設計されています」。 また、Nagios 設定ファイルで作業した経験があれば、マニフェスト (彼らの Chef レシピのバージョン) を書くことは問題ないでしょう。 ここではあまり多くの自由はありませんが、それは世界共通言語を持つという観点からは良いことです。 したがって、Puppet を使用し、学ぶために開発者の経歴を持つ必要はありません。

最後に、これらのツールは、レシピまたはマニフェストを開発およびテストする方法が異なります。 Chef には Chef SDK を含むワークステーションがあり、ステージング環境としてローカル コンピュータにインストールすることができます。 ローカルでレシピをテストし、マスターノードにアップロードすることができます。 Puppetにはワークステーションはありませんが、SDKがあり、マニフェストを開発しながらテストすることができます。 さらに、puppet apply コマンドでマニフェストをローカルに適用できます。

person wearing white apron walkin on stairs

Examples

それでは、Stackify エージェントがインストールされているかどうかを確認するコード例を見てみましょう。

Chefのレシピは次のようになります(pure Ruby):

# ...# bunch of variables declared# ...# download and extract stackify agenttar_extract node do target_dir Chef::Config creates "#{Chef::Config}/#{stackify_agent_install_relative_path}/#{stackify_agent_install_script_name}" not_if { File.exist?(stackify_agent_jar_location) }endtemplate_file = "#{Chef::Config}/#{stackify_agent_install_relative_path}/stackify-agent.conf"template template_file do source "stackify-agent.conf.erb"end# run stackify agent install scriptbash 'agent_install' do user 'root' cwd "#{Chef::Config}/#{stackify_agent_install_relative_path}" code <<-EOH ./#{stackify_agent_install_script_name} #{stackify_agent_install_script_options} rm -rf #{Chef::Config}/Linux rm -rf #{Chef::Config}/#{stackify_agent_install_relative_path} EOH not_if { File.exist?(stackify_agent_jar_location) }end

Puppetの場合は、Stackifyエージェントをインストールするモジュールがあり、マニフェストは次のようになります：

 class { 'stackify': package_ensure => 'present', package_install_options_environment => 'development', package_install_options_activationkey => 'XXXXXXXXXXXXXXXXXXXXXXXXXX', file_download_directory => 'C:\Temp', service_manage => true, service_ensure => true, service_enable => true, }

ご覧のように、上記のコード例は私が以前言ったことを確認するものです。 Chefでは、より自由度があります。 しかしPuppetでは、使えるモジュールがあるとコードがシンプルに見えるかもしれません。

プレミアム機能

構成管理以外のプレミアム機能も含めて、比較してみましょう。

Puppetについては、Puppet Enterpriseがあり、以下の機能が含まれています。

  • コンプライアンスポリシーに役立つレポート
  • アプリケーションとインフラのデプロイメントのオーケストレーション
  • コードとしてのインフラでインフラのプロビジョニングを自動化
  • インフラの変更を自動的に促進するコード管理
  • サーバーを詳細に制御するノード管理
  • Role-of-United Framework (RUnited Framework)
  • RUnited Framework (RUnited Framework) RUnited Framework (RUnid Framework) RUnid Framework 2.0
  • RUnid Framework 2.0
  • メールや電話でのサポート

また、Puppet Remediate.もあります。 これはサーバーの脆弱性を管理するためのツールです。 サーバーにどのような脆弱性があるのかを把握し、すべてのサーバーに大規模にパッチを適用することができます。

Chef では、構成管理以外に、有料版には次の機能があります。

  • Compliance and Security Management
  • Ci/CD pipeline の作成とすべてのアプリケーションのリリース管理
  • Visibility with dashboards across all your infrastructure stack

詳細は各社のサイトでご覧いただけますが、すぐに始めるために役立つリソースは非常に充実しています。

person playing puppet dog

How to Choose

Chef と Puppet のどちらを選ぶかは難しい質問ですが、答えはいつものように…「場合による」です。 良いアプローチは、チームの背景を考慮することです。 システム管理者の経歴を持つ人は、Puppetを使うのがより適切だと思うかもしれません。 DSLを学ばなければならないとはいえ、プログラミング言語を学ぶようなことは決してないでしょう。 しかし、開発のバックグラウンドがある人は、(Ruby を知らなくても) Chef をより好むかもしれません。

しかし、各ツールのプレミアム機能も考慮する必要があります。 これらの機能のうち、どれがあなたの組織のサイロと無駄を減らすのに役立つでしょうか。 繰り返しますが、それはすべてあなたのニーズ次第です。 どちらのベンダーも、常に機能で互いにレベルアップしようとしていることがわかります。 例えば、Puppetでは、Rubyでカスタム関数を作成できます。

そして、もちろん、もう1つの重要な側面は価格です。 価格は変動が激しく、それぞれのお客様のニーズによって異なるので、ここでは割愛します。 また、Puppetの場合、価格のページには公開電話番号がなく、「お問い合わせ」ボタンしかないのも理由の一つです。 一方、Chefの場合、価格ページには電話番号が記載されていますが、やはり問い合わせが必要です。 直接コンタクトして、良いオファーを探すことをお勧めします。 7788>

There’s No Silver Bullet

As a friendly reminder, there’s no silver bullet for a configuration management tool.これは、構成管理ツールに銀の弾丸はないということです。 Chef も Puppet も今日では非常に成熟しており、常に製品を改良し、研究投資を行い、人々がそのツールを学ぶより良い方法を作り出しています。 この比較で、両ツールがどのように機能するのか、より深く理解していただけたのではないでしょうか。 もしかしたら、就職の面接の準備をしているかもしれませんし、主な違いや共通点について興味があるかもしれません。

ただし、自社でどちらのツールを使うか決める場合は、どんな問題があって、この種のツールがどう負荷を軽減してくれるかを明確に把握しておくようにしてください。 学習曲線は常に存在しますし、チームの背景やどのツールがより適しているかによっても変わってきます。 さらに、構成管理以外のプレミアム機能やサービスにも目を向けてください。あなたの会社では、コンプライアンス・ポリシーに関するより多くの支援が必要かもしれませんから。

  • 著者について
  • 最新の投稿

About Christian Melendez

Christian Meléndez is a technologist that started as a software developer and more recently become a cloud architect focused to implementing continuous delivery pipelines with applications in several flavors, including .NET NET 2.0を含むアプリケーションに焦点を当てている技術者です。

  • AWS Elastic Beanstalk .NET Core Getting Started – January 17, 2020
  • AWS Batch.NET、Node.js、Javaなど、さまざまな種類のアプリケーションを使用した継続的デリバリーパイプラインの実装に重点を置くクラウドアーキテクトです。 最初の仕事をキックオフするための詳細ガイド – 2019年12月26日
  • Azure Container Service (AKS) – 詳細入門 – 2019年12月18日
  • Sending CloudWatch Custom Metrics From Lambda with Code Examples – 2019年11月14日
  • Chef vs Puppet: 違い、類似点、選び方 – 2019年9月24日