回答:
ドメイン固有の言語は、作成するコードの量に大きな違いをもたらします。たとえば、次の間に大きな違いはないと主張できます。
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は依存関係を処理し、問題を自動的に転送します。
比較するものはありません。適切な構成管理ツールを使用すると、時間と複雑さが軽減されます。あなたがやろうとすればするほど、より多くのシェルスクリプトが不適切であると思われ、人形でそれを行うことによってより多くの労力を節約できます。
これは人気のない意見ですが、構成管理システムは必ずしも優れているとは限りません。時にはシンプルが本当に最高です。
選択した構成システムに関連する明確な学習曲線と管理オーバーヘッドがあります。結局、依存関係を導入しています。自動化と同様に、展開された構成でもセキュリティが維持されるように注意する必要があります。
構成管理を展開したいくつかのインスタンスしかありませんでした。構成が繰り返され、構成可能なCookie-Cutterの展開を実行する必要があるシステムが多数存在する場合は常にそうでした。
あなたはあなた自身の質問に答えました...
自動化はよりスケーラブルで形式化されています。PuppetとChefは最近では標準と見なされています（求人広告を確認してください）。
丸石のシェルスクリプトには場所がありますが、DevOpsムーブメントのコンテキストではスケーラブルではありません。可読性はその一部です。
Chefを使用すると、特にあらゆるタイプのクラウド環境で、複雑なインフラストラクチャのセットアップの管理とバージョン管理がはるかに簡単になります。管理する必要のある依存関係の数に応じて、この勝利の規模は大きく異なり、多くの人々にとってCMソリューションに移行するという決定は非自明なものになります。
Chefの本当の（しばしば見られない）利点は、べき等です。重複する関心で実行されるレシピの組み合わせに関係なく、リソースの状態を確実に把握できることは、シェルスクリプト設定よりも大きな利点です。構成用のシェルスクリプトがある場合、意図しない/望ましくない結果なしに複数回実行できるシェルスクリプトを自問してください。
適切なCMソリューションは、クロスプラットフォームの自動化とチームコラボレーションを簡素化することで、大規模な成功を保証します。適切に管理され、適切に管理されたバージョン管理されたシェルスクリプトのグループを使用して、これらすべてを実現することは可能です。「なぜ」と自問する必要があります。Chef / Puppetおよび同様の技術は、才能のあるSysOpsのグループがこれらの同じ問題を何度も解決しなければならないことにうんざりし、より良い選択肢を提供しようと試みたために生まれました。
PuppetやChefなどの最新の構成管理ツールを使用すると、構成されたサーバーを実現するために必要なアクティビティを心配することなく、システムの状態を定義できます。
たとえば、chmodコマンドは、ファイルが存在すること、ファイルを所有するユーザーが存在すること、ディレクトリが作成されていることなどを想定しています。したがって、スクリプトはこれらの前提条件をすべて考慮する必要があります。
状態ベースの構成管理ツールの方が簡単です。ファイルに適切なアクセス許可があることを気にするだけです。それがどのように達成されるかは、ツールの問題です。
chmodファイルはスクリプトによって作成されたか、スクリプトによって存在がテストされているため、ファイルが存在するとは想定していません。
サーバーが使い物にならない場合、または一度に2つ以上立ち上がる原因がある場合、本格的なCMシステムは、一連のシェルスクリプトよりもはるかにニーズを満たします。
ビルドのニーズが控えめな場合（または、オーガニックのフリーレンジのフェアトレードサーバーを職人が手作りする場合）、シンプルに保ちます。
個人的に、過去のギグでChefを広範囲に使用していたため、このギグで「シンプルに」しようとしましたが、Chefが提供するプリミティブ、抽象化、およびパワーを本当に失いました。いくつかのシェルコマンドから必要なものを取得できる状況になった場合でも、「コマンド」ブロックを使用してそれらを実行し、シェルコマンドをシェルで記述するのとまったく同じように入力できます。
つまり、サーバーなしでChefを実行できます（chef-solo）。Puppetにはアナログ機能があり、中央サーバーを実行せずに他の人のクックブックとレシピを活用できます。
もう1つの利点はコミュニティです。多くの人がいます（その多くはあなたよりも賢く、経験が豊富です）。個人的には、他の誰かが私のために仕事をしてくれたとき、それが大好きです。
シェルスクリプトベースのサーバー自動化フレームワークを作成しました：https : //github.com/myplaceonline/posixcube
私はこの種のプロジェクトを最初に作成したわけではないと確信していますが、自分のニーズに合ったものを見つけることができなかったので、他の人がこれを役に立つと思うかもしれません。私はChefの経験しかありませんでしたが、Ansibleなどを見て回り始めたので、シェルスクリプトを試してみたいと思い、これまでのところ結果が気に入っています。