構成マネージャー(Puppet / Chef / Ansibleなど)を使用するのが適切な場合


17

現在の職場では、2台のVMwareホストマシン、1台のOpenBSD物理マシン、3台のDebian VM、および6台のWindows Server VMを管理しています(2008/2012)。

PuppetやChefなどの構成管理ツールの実装を検討しています。これは合理的ですか、またはツールを学習するオーバーヘッドが利点を上回っていますか?管理性と実装コストの転換点はどこですか?


1
構成を管理する必要があるとすぐに「適切」になります。災害から回復する必要がありますか?新しいデータセンターに移動する必要がありますか?水平方向に拡張する必要がありますか?あなたが手でやっているなら、あなたはそれを間違っています。「2回やっていますか?それを書き留めてください。
ウォーレン

1
それは、これらのシステムに対して何をする必要があるかによって異なります。
ewwhite

回答:


25

私見では、単一のサーバーのみを管理している場合でも、学ぶ価値があります。

はい、学習曲線があります。はい、あなたはイライラするでしょう。ただし、これらの費用については、信頼性が高く、一貫性のあるワンクリック展開、バージョン管理されたサーバー構成、テスト/開発環境のセットアップの容易さなどにより、複数の支払いが行われます。

現在の仕事の利点に加えて、履歴書にCMシステムを追加できることは大きなメリットです。現代のシステム管理者は、現在、少なくとも有することが期待される暴露習熟されていない場合、コンフィグ管理システムへの。

(追記:うまくとしてAnsibleを考えることは、私の好みCMだ、とある。非常に簡単なアップとして動作させるには-また、窓がきれいに沿って来ているAnsibleにサポートしていずれかの人形やシェフよりもはるかに簡単。。)


5
よく言った。私はAnsibleを使用して、家でラズベリーパイを設定するような些細なことをすることになります。これはプロセスを文書化するのに便利な方法だからです。
tedder42

2
絶対に!Chefに入ることは、私にとってキャリアでの大きな勝利でした。ここに本物があります:数年後には、CMはジュニアSysAdの仕事を除くすべての仕事にほぼ必要/期待されるでしょう。
-gWaldo

2
完全に同意。CMシステムの一部にすぎないインストールの自動化に重点が置かれすぎています。人々は、Mが何を意味するかを忘れています-管理。1つのサーバーに対して行ったさまざまな構成変更をどのように追跡しますか。サーバーの数は関係ありません。その1台のサーバーが停止すると、間違いなく正確に再構築できるようになります。
ETL

5

PuppetやChefなどの構成管理ツールの実装を検討しています。これは合理的ですか、またはツールを学習するオーバーヘッドが利点を上回っていますか?

どれだけの時間とお金を燃やさなければならないか、そしてあなたが燃やしているのがあなたのお金かどうかによって、それは合理的です。

構成管理ツール(いずれか)は、今日の市場で貴重なスキルになりつつあります。

CMツールの学習と実装に時間を費やすことは、ビジネスや環境の観点からは最も効率的なことではないかもしれませんが、スキルセットからは価値があるかもしれません。

管理性と実装コストの転換点はどこですか?

ほとんどの構成管理ツールは無料で入手できますが、インストールして実行するのが難しいという注意が必要です。

この質問は、これらのサーバーを管理するために日々何をしているのかに本当に依存するため、答えるのが少し難しいです。あまり多くのことをする必要がない場合、構成管理ツールは完全にやり過ぎかもしれません。

インフラストラクチャを予測可能な基本状態に強制するだけでよい場合、SaltStackやAnsibleのような非常に基本的なものを選択してもそれほど害はありません。

私の個人的な経験では、Saltはサーバーに簡単にアクセスしてブートストラップでき、非常に基本的なリモート実行およびレポートに使用できます。これは、環境にまだ実装されていない場合に役立ちます。

心に留めて、私は偏っている。各CMツールを自分で評価する必要があります。


4

@EEAAが言ったように、サーバーの数は関係ありません。単一のマシンで構成管理を使用する利点を享受できます。

  • 文書化されたセットアップ(CMスクリプトを介して文書化)
  • 信頼できる展開(セットアップを何度も[再]展開できます)
  • セットアップの回復力(現在のサーバーの音-新しいものをスピンアップ)
  • 再利用(2台目のサーバーが必要になったとき-最初のサーバーからリサイクルできるCMスクリプトが既にある場合)
  • アップグレード(新しいセットアップのようなもので、異なるプラットフォーム上にあります)

あまり頻繁に作業しないため、すべてのパーソナルサーバーにCMを実装しなければならず、細かい部分をすべて忘れていたと言えます。CMスクリプトを作成するのは時間がかかるように思えるかもしれませんが、それは見返りに値します。長期的には、設定に費やす時間を大幅に節約できます。


3

PuppetとAnsibleの経験があります。Ansibleは手続き型であるためIMOがより単純ですが、Puppetは宣言型です。両方に長所と短所がありますが、私はPuppetの不可解なエラーのために十分な髪を引っ張りました。

クリーンで再利用可能な構成を作成する場合は、両方とも多くの作業が必要です。少なくとも2つの非常に類似したサーバー(クラウドまたはクラスターなど)がある場合、コストは実際に回収され始めます。

ただし、スタンドアロンサーバーに対してもある程度の用途があります。管理ユーザー、標準(ローカルバリエーションを含む)sshd、postfix、またはsnmpd構成をセットアップし、ポリシーの遵守やshellshock脆弱性のテストなどの簡単な情報収集にも使用できます。

また、EEAAで述べたように、サーバーを実際に基本状態から実行状態にすることを確認した場合、セットアップを文書化するための値があります。バージョン管理システム(git)と組み合わせて、行った変更がバージョン管理され、文書化されるようにすることをお勧めします。管理者のチームがある場合、これは非常に貴重です。


1

Puppetまたはその他の管理システムは、ここでの他の回答ですべて強調されている大きな利点をもたらしますが、管理に関して特効薬はありません。

たとえば、複雑なシステム用のパペットクラスの作成には多くの時間と労力がかかり、多くの落とし穴があり、エラーメッセージが常に100%クリアされるわけではないため、涙が出ます。または、どのアプローチがこれに最も適しているかを判断します(例:宣言型の人形とアップグレードは通常手続き型です)

また、管理された方法でクラスに加えられた変更をロールアウトする方法、およびマニフェストのさまざまなバージョンを維持する方法を把握する必要があります。

また、管理ソリューションをアップグレードするときが来たら、その方法を検討する必要があります。

たとえば、パペットクラスの作成にかなりの時間を費やしている場合は、実際のメリットを享受するために、多くのワンクリックインストールを実行する必要があります。

まだ、そして必要に応じて調査することをお勧めします。つまり、構成ファイルの配布は、開始するのに適した場所であり、そこからそれを取得することができます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.