web-dev-qa-db-ja.com

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

PuppetおよびChefツールの新機能。彼らがしている仕事はシェルスクリプトで行うことができるようです。多分それはそれらが来るまでシェルスクリプトで行われました。

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

scriptingpuppetchefconfiguration-managementprovisioning
82
resting

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

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はこれをすべてサーバー上でコンパイルします。そのため、コンテンツを変更する場合は、サーバー上で変更するだけで、必要な数のシステムで変更できます。そしてパペットは依存関係と転送の問題を自動的に処理します。

比較はありません-適切な構成管理ツールは時間と複雑さを節約します。やろうとすればするほど、シェルスクリプトが不十分に見えるようになり、パペットでそれを実行することで節約できる労力が増えます。

56
Paul Gear

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

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

構成管理を展開してスタックしたインスタンスは2、3しかありません。繰り返しの構成を備えた多数のシステムがあり、構成可能なcookie-cutterデプロイメントを実行する必要があるときはいつでもありました。

34
kenchilada

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

自動化はよりスケーラブルで正式化されています 。 PuppetとChefは最近の標準と見なされています（ job ads を確認してください）。

石畳のシェルスクリプトはそれぞれの場所にありますが、DevOpsムーブメントのコンテキストではnotスケーラブルです。読みやすさはその一部です。

23
ewwhite

Chefを使用すると、複雑なインフラストラクチャのセットアップとversionの管理が非常に簡単になります。標準化されていない方法で整理されたシェルスクリプトの束。管理する必要のある依存関係の数に応じて、この勝利のサイズは大きく異なる可能性があり、CMソリューションに移行する決定は多くの人々にとって自明ではないものになります。

Chefの本当の（歌われていないことが多い）メリットはべき等性です。関心が重複して実行されるレシピの組み合わせに関係なく、リソースの状態を確認できることは、シェルスクリプトの構成よりも大きな利点です。設定用のシェルスクリプトがある場合は、意図しない/望ましくない結果を招くことなく、それらのスクリプトをいくつ実行できるかを自問してみてください。

適切なCMソリューションは、クロスプラットフォームの自動化とチームのコラボレーションを簡素化することにより、大規模な成功を確実にするのに役立ちます。うまく整理され、適切に管理され、バージョン管理されたシェルスクリプトのグループを使用して、これらすべてを実現することができます。 「なぜ」と自問する必要があります。 Chef/Puppetと同様のテクノロジーが生まれたのは、才能のあるSysOpsのグループがこれらの同じ問題を何度も何度も解決し、より良いオプションを提供するために着手するのに疲れていたからです。

重要な部分：

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

PuppetやChefなどの最新の構成管理ツールを使用すると、サーバーの構成に必要なactivitiesを心配する代わりに、システムのstateを定義できます。

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

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

10
Jon Jaroker

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

ビルドのニーズが控えめな場合（または職人の手で有機フリーレンジのフェアトレードサーバーを手作りする場合など）は、単純にしてください。

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

そうは言っても、サーバーなしでChefを実行することができ（chef-solo）、Puppetには類似のものがあると確信しています。中央サーバーを実行しなくても、他の人のクックブックやレシピを活用できます。

もう1つの利点はコミュニティです。たくさんの人がいます（その多くはあなたより賢く、かつ/または経験豊富です）。個人的には、誰かが私のために仕事をしてくれたとき、たいていは私よりも広範囲にわたってそれが好きです。

9
gWaldo

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

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

1
Kevin