Puppet, Salt, Chef, & Ansible。 比較

読了時間:8分

あなたにはどれが適切か?

Table of Contents

I. パペット(Puppet) II. SaltStack III. Chef IV. Ansible IV. 結論

はじめに

必要なソフトウェアを備えた単一のサーバーを設定することは、合理的に単純な作業です。 しかし、多数のサーバーに同じまたは類似のソフトウェアと設定をインストールする必要がある場合、このプロセスを完了するために多くの工数がかかり、すでに緊張しているリソースが枯渇してしまいます。 何らかの形で自動化しなければ、このタスクはほとんど乗り越えられないものになりかねない。 このような背景から、新しい構成管理ツールが開発されました。 これらのサーバーを同期させ、データ センターやクラウド環境内の広範なホストにわたって更新を管理するために、Puppet、SaltStack、Chef、Ansible などの自動化ツールがこのニーズに対応します。

インフラストラクチャに使用する正しい管理ツールを選択することは、重要な決定となります。 このため、これらのプロジェクトで利用可能なオプションをレビューしています。 これらのツールは、DevOps とシステム管理者の両方に、最も大きなメリットを提供します。 この情報が正しい方向性を示してくれることを願っています。 上記のすべての構成ツールがこれらのタスクをほぼ達成できることは事実ですが、それぞれがこの目標を達成するために異なる方法論と役割をやや異なる方法で提供しています。 この記事では、各ソフトウェア管理プラットフォームが提供する本質的な違いをいくつか紹介することを目的としています。 これは、各ソフトウェアタイトルとその利点に触れ、最後に概要を提供しようとすることで、より情報に基づいた意思決定ができるようになります

.

Puppet

Puppet はリストの中でも最も古い、信頼できる管理ツールの 1 つです。 このため、Puppetチームからだけでなく、Puppetコミュニティ内でもより広範なサポート基盤を提供しています。 また、Puppetは、さまざまなオペレーティングシステムにインストールできるオープンソース版のソフトウェアも提供しています。 しかし、エンタープライズ版のソフトウェアは、IBMのAIXやF5 Big-IPハードウェアのような大規模なシステムを包含することが可能である。

Puppetの展開は通常、マスターサーバーと複数のクライアントマシン(これはエージェントと呼ばれる)で構成されます。 Puppetは、このリストにあるツールの1つで、Rubyをベースにした独自の言語を使用します。 Puppet DSL(Domain Specific Language)は、マニフェストファイルと呼ばれるファイル内にシステムの望ましい状態を記述するために使用される。 マニフェストファイルは基本的に、ネットワークやオペレーティングシステムのリソース(サービス、パッケージ、ファイルなど)がどのように構成されるかを決定する設定やタスクの集合体です。 そしてPuppetはマニフェストファイルをカタログにコンパイルし、各カタログを指定されたノードにプッシュすることで、インフラ全体にわたってノードが望ましい状態に再設定されるようにします。

さらに、Puppetは直感的でわかりやすいWebベースのUIを提供し、リアルタイムのノード管理など、より多くのタスクを完了するために使用されます。 さらに、Puppetはマルチマスターアーキテクチャ形式で設定されているため、現在アクティブなマスターがダウンした場合、別のマスターが以前のマスターを置き換え、可用性の低下を回避することができます。

Puppetは、クライアントが更新されたマニフェストのためにマスターをチェックし、マスターサーバーから新しい設定を引き落とすことによって、ノードの設定を更新します。 この機能のため、Puppetはここで指摘した他の多くのツールよりもシステム管理者指向です。 Puppetの欠点は、ノードに対してすぐに利用可能なリモート実行がないことである。 さらに、Puppet DSLとRubyプログラミング言語の知識が必要なため、Puppetはより急な学習曲線を持っている。

SaltStack

SaltStack (Salt とも呼ばれている) はこのリストの中では新しいツールに属するものである。 しかし、ソフトウェア構成管理の領域では、まだ非常に重要です。 Salt は比較的活発なコミュニティと効果的なサポートを持っています。 Saltは、低遅延、高速通信、リモート実行のためのノード間のデータ伝送を可能にするために設計されています。

SaltStackは、中央のSaltサーバーであるSalt Masterと、各ノードマシン上でエージェントとして動作するSalt Minionsと呼ばれるクライアントで構成されています。 Saltの言語をマスターするのは比較的簡単で、人間が読める設定にはPythonとYAMLファイルという、より自然でわかりやすいデータ構造が使われているからです。 Puppetがノードから更新を要求する形で動作するのに対し、Saltはこれとは逆に動作する。 Saltマスターは、すべての設定をすべてのクライアントマシンにプッシュする。 さらに、Saltは非同期ファイルサーバとして機能し、Salt Minionsに提供するファイル転送の速度を向上させる。

Saltはまた、マルチマスター構成で実行することができます。

Saltはまた、マルチマスター構成で実行できます。Saltマスターサーバーがダウンした場合、エージェントは、構成にリストされた別のマスターに接続します。 この機能により、システム全体の可用性と冗長性が向上します。 さらにSaltの利点は、一度に複数のコマンドを並列実行できることです。 これらのコマンドはAES(Advanced Encryption Standard)によって暗号化され、SSHプロトコルを介してクライアントノードにプッシュされる。 最後に、Saltの利点として、複数のマスターを管理できることが挙げられる。 SaltはWeb UIも提供しているが、機能や性能は限定的である。

Chef

Chef は 2009年にオープンソース ソフトウェアとして最終リリースされるまで、内部サーバー間のデプロイツールとして開始されました。 Chef の大きな利点は、広範なドキュメントとガイダンスによる大規模なサポートコミュニティも提供されていることです。 Chef マスターとノードソフトウェアは Unix/Linux システムの両方で動作しますが、Windows サーバーにデプロイできるのはクライアントとワークステーション版のみです。

Chefの設定オプションはCookbooksとRecipesで構成されています。 レシピは定義ファイルで、属性、ファイル、ライブラリ、および他のレシピと組み合わせて、Cookbook を構築することができます。 これらの Cookbook は、その後、クライアントのデプロイメントに使用することができます。

Chef は 3 つの主要コンポーネントで構成されています:

  • Chef Workstation – Chef ワークステーションは、システムエンジニアが Cookbook を作成、テスト、および Chef マスターサーバーにデプロイするために使用されます。
  • Chef マスターサーバー – Chef サーバーは基本的に、すべての Chef 設定データが格納されるハブです。 この情報にはクックブック、サーバデータ、その他の関連情報が含まれます
  • Chefクライアント – ChefクライアントはChefマスターサーバによって管理されるエンドノードマシンです。 これらのサーバは定期的にChefマスターサーバからCookbookの設定を取得し、実行します。

Chefのプログラミング言語は、Chef独自のDSL(Domain Specific Language)を使用するという点でPuppetと似ていますが、Rubyで書かれたスクリプトもサポートしています。

Chefは主にChefマスターサーバとして設定されており、また中央のChefマスターサーバがダウンした場合のバックアップサーバとしても設定されています。 障害が発生した場合、バックアップマスターサーバーが中央のChefマスターサーバーを置き換えることになります。 このように、Chef環境には冗長性が取り入れられています。 Chefは、自動化されたワークフローに加えて、クラウドとインフラの自動化も提供しており、これらはクライアントマシンへの継続的デリバリーを提供するために使用されます。 注意すべき点は、CookbookでDSL/Ruby指向のスクリプトを使用する必要があるため、主要言語はプログラマに有利であることです。 Chefとそのインフラは非常に安定しており、信頼性のために構築されています。 並列実行のSaltなどとは対照的に、Chefは逐次実行を提供します。

Ansible

Ansible は設定管理の解決策として使用する、より最新のツールの 1 つです。 そのシンプルさとわかりやすい構成により、最も人気のあるソフトウェアの 1 つであることは間違いないでしょう。 以前のツールと同様に、Ansible は Windows と Unix/Linux の両方のクライアントマシンをサポートしますが、Ansible マスターサーバーは Unix/Linux ベースのサーバーを必要とします。

以前のツールとは対照的に、Ansible は SSH (Windows では RDP) プロトコルを使用してクライアント サーバーへの接続を開き、連続したコマンドを実行するため、Ansible マスターのみが実行に必要です。 Ansibleの設定ファイルはPythonベースで、構造化されたデータにはYAMLファイルを使用するという点で、Puppetと類似している。 これらのファイルはPlaybooksと呼ばれる。 AnsibleはPython APIもサポートしており、特定のイベントに応答してノード自体の制御を行うために使用することができる。 Ansibleは、コマンドラインインタフェースを介して使用することもできます。 この方法でCLIインタフェースを使用すると、サーバーの再起動などの単純なタスクであれば、設定ファイルを使用する必要はない。 より複雑なタスクの場合は、マスターサーバーがクライアントノードに情報をプッシュするため、プレイブックが必要になる。

冗長性に関して、Ansible は通常、単一のアクティブなマスター サーバー (プライマリ インスタンスと呼ばれる) として構成され、それに接続するエージェントは必要ありません。 セカンダリ マスターは、マスター サーバーがダウンした場合に引き継ぐように構成することができます。 Ansibleはエージェントレスアプローチを採用しているため、エンジニアが比較的迅速にすべてのノードに変更を展開したり、アップデートをプッシュしたりすることができる。 Ansible の欠点は、クライアント コンピューターがプライマリ マスター上の定期的な構成変更をチェックしないことです。

Top

結論

簡単に言えば、構成マネージャーはサーバーの既存の構成とその望ましい状態の間に抽象化レイヤーを提供するということです。 この目標は、達成するために必要な冗長なタスクの代わりに、特定の結果にもっと焦点を当てることで達成されます。

これら 4 つの製品のレビューにおいて、人気だけに基づいた結論を探すと、明らかに Ansible が勝者となります。 これは、この記事の他の製品と比較して、より幅広い管理者のグループが、主要な構成管理ツールとして Ansible を使用することを選択しているという事実によるものです。 Ansibleは、その構造とパラダイムに関して、よりSysOps指向の役割に向けられているので、その利点があります。 Saltもこの点では同様ですが、PuppetやChefとは異なり、より開発者向けの製品となっています。 さらに、Ansibleは、このリストの中で、セットアップ、設定、すぐに使い始めるのがより簡単なオプションの1つです。

一方、Puppetは、ユーザビリティの観点から最も近づきやすく、信頼できるものでしょう。 しかし、先に説明したように、その幅広い機能、構造、およびスケーラビリティを最大限に活用するためには、Rubyの知識が必要です。 Puppetの設定は非常に細かく、時には複雑になることもありますが、異種混在しないソフトウェア環境を探しているのであれば、最も安全な方法です。

より均一なインフラストラクチャに向けて合理化された構成ツールを探しているなら、Ansible と Salt はその目標により適しているでしょう。 Salt 自体は、このリストでより信頼性が高く堅牢なツールの 1 つですが、Web UI が初心者にとって利用可能ないくつかの深い設定オプションを理解するのが難しいため、1 つランクを下げています。 しかし、高度なスケーラビリティ・オプションと、シスオペや管理者の視点からアプローチしやすい作業環境によって、これを補うことができる。 また、UIを改善・拡張するアドオンが複数用意されており、使い勝手と機能性を高めています。

Chef 自体は、非常にわかりやすく、よく設計されたツールです。 アクセスしやすく、Puppetよりも実用性の高い、改良されたアプローチを提供します。 前述のように、Chef は、プログラミング言語と経験の幅広い理解を必要とするため、開発指向の経験が不足している SysOps またはシステム管理者にとって、顕著な学習曲線をもたらす可能性があります。

結論として、Ansible は、利用可能なドキュメント、その構造、およびアクセスのしやすさから、エントリレベルの構成管理のためのわかりやすい選択肢となります。 Puppetも堅実なツールですが、ユーザーまたはチームは、DSL (Domain Specific Language) プログラミングを使用する際に、より急な学習曲線を克服するために、新しいコーディング手順と機能を学習する必要があります。 ユーザビリティ、スケーラビリティ、複数環境対応という点では、Saltは多くのオプションと非常に魅力的なスケーリング機能を活用したいシステム管理者に最も明確に響くだろう。 Chefはよく設計されたレイアウトと構造を持っており、かなりのレベルの安定性を提供します。 プログラマ向けなので、最初のうちは学習曲線に苦労するかもしれません。 これらのツールはすべて、インフラストラクチャとその望ましい状態を構成する際に、特定の役割を果たします。

トップ

ぜひ私たちの仲間になってください!

私たちにお電話(800.580.4985)いただくか、チャットやチケットを開いて、知識豊富なソリューションまたは経験豊富なホスティングアドバイザーと話し、これらの技術を今すぐ活用する方法を学んでください!

  • 私たちは、このように私たちが提供するサービスを利用できるようにするため、私たちが提供するサービスを利用できるようにするため、私たちに電話をかけてください。

コメントを残す

メールアドレスが公開されることはありません。