シェルスクリプトではなくChef / Puppetを使用する理由


81

PuppetおよびChefツールの新機能。彼らがやっている仕事は、シェルスクリプトでできるようです。これらが登場するまで、シェルスクリプトで行われたのかもしれません。

それらがより読みやすいことに同意します。しかし、読みやすいだけでなく、シェルスクリプトに勝る他の利点はありますか?

回答:


56

ドメイン固有の言語は、作成するコードの量に大きな違いをもたらします。たとえば、次の間に大きな違いはないと主張できます。

chmod 640 /my/file

そして

file { "/my/file":
    mode => 640,
}

しかし、これらの間には大きな違いがあります。

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

そして

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

wgetが失敗するとどうなりますか?スクリプトはそれをどのように処理しますか?そして、$ FILEが正しい内容でそこにあることを必要とするスクリプトの後に何かがあるとどうなりますか?

echo "Hello world" > $FILE最初の例ではスクリプトをクライアントで実行する必要がありますが、puppetはこのすべてをサーバーでコンパイルすることを除いて、スクリプトを入れるだけでよいと主張するかもしれません。したがって、コンテンツを変更する場合、サーバー上で変更するだけでよく、必要な数のシステムで変更します。また、Puppetは依存関係を処理し、問題を自動的に転送します。

比較するものはありません。適切な構成管理ツールを使用すると、時間と複雑さが軽減されます。あなたがやろうとすればするほど、より多くのシェルスクリプトが不適切であると思われ、人形でそれを行うことによってより多くの労力を節約できます。


9
@Paul Gear、構成管理ツールが長期的に見れば方法と言っても過言ではありません。たとえば、AWSを使用すると、シェルスクリプトでサーバーを最初から構築し、いくつかのテストを実行し、AWSのインスタンスが正常であることを確認したら、イメージを作成できます。その後、このイメージをプレビューまたはステージング環境に展開して、さらにテストを行い、イメージが目的に合っていることを検証したら、運用環境にプッシュします。このシナリオでは、構成管理ツールはまったく役に立ちません。
デレク・リッツ

人々が毎日使用している何百台もの専用サーバーを管理したい場合(そして、誤って、または誤ってそれらの操作をほとんど制御できない場合)、ここで構成管理ツールを使用する必要があります。
デレクリッツ

6
これはあまり説得力のある例ではありません。wgetから始めて、それから奇妙な状態に陥ることはありません。ファイルは、ステップのいずれかが成功しなかった場合にロールバックされるトランザクションのようなものですか?
PSkocik

33

これは人気のない意見ですが、構成管理システムは必ずしも優れているとは限りません。時にはシンプルが本当に最高です。

選択した構成システムに関連する明確な学習曲線と管理オーバーヘッドがあります。結局、依存関係を導入しています。自動化と同様に、展開された構成でもセキュリティが維持されるように注意する必要があります。

構成管理を展開したいくつかのインスタンスしかありませんでした。構成が繰り返され、構成可能なCookie-Cutterの展開を実行する必要があるシステムが多数存在する場合は常にそうでした。


10
環境の管理コストが非常に大きいため、自動化の管理が本当に安価な場合。Gitで管理されている変更をスクリプト化するか、sshマルチプレクサーで設定する方が簡単な場合は、それを行います。私にとって最も重要なことは、システムを監視し、すべてが期待どおりに機能していることを確認することです。何かが誤って設定されている場合に警告されている限り、それがどのように設定されるかはそれほど重要ではありません。
ケンチラーダ

10
@ewwhite「いつ自動化するかしないかを決めるのはいつか
MikeyB

3
Ansibleなどのより新しいツールは、ChefまたはPuppetよりも展開/管理のオーバーヘッドが大幅に少なく、依存関係をほとんどまたはまったく必要としません(特にAnsibleはエージェントレスです)。これにより、採用の基準が本当に低くなります。
GomoX

2
@ewwhite個人的な生産性のために必要なときに自動化します。自動化によって学習しますが、ありふれたタスクを実行して学習するのではありません。学習=生産性の向上と反復的な改善。自動化はこれと組み合わされて、より良い結果を生み出します。負の雪玉ではなく、正の雪玉です。技術進歩と技術負債。
デレク・リッツ

2
@ABBいいえ、それは暗示されていません。シェルスクリプトについても言及していません。一般的な慣行としてオートメーションについても言及しています。シェルスクリプトを使用して物事を自動化し、手動で物事を行う代わりにスクリプトの抽象化を学習することができます。これにより、そのタスクを再度行う時間を節約できるだけでなく、ミスを防ぐことができます。また、次のスクリプトを最後のスクリプトよりも少し上手に書くことができるはずです。ポジティブな雪だるま...しかし、スクリプトの作成の専門家であり、今後実行するスクリプトを作成していない場合、学習したり時間を節約したりすることはできません。
デレクリッツ14

23

あなたはあなた自身の質問に答えました...

自動化はよりスケーラブルで形式化されています。PuppetとChefは最近では標準と見なされています(求人広告を確認してください)。

丸石のシェルスクリプトには場所がありますが、DevOpsムーブメントのコンテキストではスケーラブルではありません。可読性はその一部です。


7
シェルスクリプトはどういうわけか形式化されていませんか?求人広告の引用は説得力のある議論になりますか?また、開発者として十分に活用されていないため、devopsは非常に残念です。このリンクには、スケーラビリティについては何も書かれていません。シェルスクリプトはスケーラブルではないという主張はありますか?Puppetは面白いと思いますが、必ずしも答えの理由からではありません。
Acumenus 14

求人広告は、特定のスキルの実際の市場を反映しています。はい。構成管理をその目的に使用すると、シェルスクリプトよりもスケーラブルで、堅牢で、文書化が簡単になります。私は多くの環境にいましたが、私が見るほとんどのスクリプトは、「プロダクション品質」とみなす方法で構築されておらず、例外を処理するように編成されています。受け入れられた回答を参照して、理由を理解してください。
ewwhite 14

1
「そして開発者は開発者として十分に活用されていないため、devopsは非常に残念です。」これは単に真実ではありません。DevOpsは、Web開発と同様の開発専門分野です。ソフトウェア開発のパターンとプラクティスは引き続き適用されます。DevOpsについてお読みください。
チャイムエリヤ

13

Chefを使用すると、特にあらゆるタイプのクラウド環境で、複雑なインフラストラクチャのセットアップの管理とバージョン管理がはるかに簡単になります。管理する必要のある依存関係の数に応じて、この勝利の規模は大きく異なり、多くの人々にとってCMソリューションに移行するという決定は非自明なものになります。

Chefの本当の(しばしば見られない)利点は、べきです。重複する関心で実行されるレシピの組み合わせに関係なく、リソースの状態を確実に把握できることは、シェルスクリプト設定よりも大きな利点です。構成用のシェルスクリプトがある場合、意図しない/望ましくない結果なしに複数回実行できるシェルスクリプトを自問してください。

適切なCMソリューションは、クロスプラットフォームの自動化とチームコラボレーションを簡素化することで、大規模な成功を保証します。適切に管理され、適切に管理されたバージョン管理されたシェルスクリプトのグループを使用して、これらすべてを実現することは可能です。「なぜ」と自問する必要があります。Chef / Puppetおよび同様の技術は、才能のあるSysOpsのグループがこれらの同じ問題を何度も解決しなければならないことにうんざりし、より良い選択肢を提供しようと試みたために生まれました。

キーピース:

  • べき等
  • 容易な依存関係管理(バージョン管理)
  • 標準化された組織(業界レベルで受け入れられています)
  • サーバー構成タスクをシステムレベルの詳細から分離する抽象化
  • コミュニティの知識を活用する機能(上記のすべての原則を受け入れることが保証されています)

3
ssではI等性はほとんど不可能です。依存関係はyum / aptなどによって適切に管理されます。受け入れは無関係です。ssにはコミュニティの知識があります。ただし、多くのスクリプトをコピーする必要がなく、システムを一元的に構成することも、どちらも有用であることを承諾します。パペットにはクライアント側のエージェントが必要だと聞きました。
Acumenus 14

10

PuppetやChefなどの最新の構成管理ツールを使用すると、構成されたサーバーを実現するために必要なアクティビティを心配することなく、システムの状態を定義できます。

たとえば、chmodコマンドは、ファイルが存在すること、ファイルを所有するユーザーが存在すること、ディレクトリが作成されていることなどを想定しています。したがって、スクリプトはこれらの前提条件をすべて考慮する必要があります。

状態ベースの構成管理ツールの方が簡単です。ファイルに適切なアクセス許可があることを気にするだけです。それがどのように達成されるかは、ツールの問題です。


1
実際、chmodファイルはスクリプトによって作成されたか、スクリプトによって存在がテストされているため、ファイルが存在するとは想定していません。
Acumenus 14

9

サーバーが使い物にならない場合、または一度に2つ以上立ち上がる原因がある場合、本格的なCMシステムは、一連のシェルスクリプトよりもはるかにニーズを満たします。

ビルドのニーズが控えめな場合(または、オーガニックのフリーレンジのフェアトレードサーバーを職人が手作りする場合)、シンプルに保ちます。

個人的に、過去のギグでChefを広範囲に使用していたため、このギグで「シンプルに」しようとしましたが、Chefが提供するプリミティブ、抽象化、およびパワーを本当に失いました。いくつかのシェルコマンドから必要なものを取得できる状況になった場合でも、「コマンド」ブロックを使用してそれらを実行し、シェルコマンドをシェルで記述するのとまったく同じように入力できます。

つまり、サーバーなしでChefを実行できます(chef-solo)。Puppetにはアナログ機能があり、中央サーバーを実行せずに他の人のクックブックとレシピを活用できます。

もう1つの利点はコミュニティです。多くの人がいます(その多くはあなたよりも賢く、経験が豊富です)。個人的には、他の誰かが私のために仕事をしてくれたとき、それが大好きです。


1

シェルスクリプトベースのサーバー自動化フレームワークを作成しました:https : //github.com/myplaceonline/posixcube

私はこの種のプロジェクトを最初に作成したわけではないと確信していますが、自分のニーズに合ったものを見つけることができなかったので、他の人がこれを役に立つと思うかもしれません。私はChefの経験しかありませんでしたが、Ansibleなどを見て回り始めたので、シェルスクリプトを試してみたいと思い、これまでのところ結果が気に入っています。

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