DSCと "通常の"スクリプトの違いは何ですか？
ITPro.tvで PowerShell Desired State Configuration DSC についてのビデオを見ました。彼らはそれを紹介し、効果的にスクリプトを実行します。ただし、これもスクリプトの最初の（実際の）導入でした。そのため、DSCと通常のスクリプトの違いを理解しませんでした。私は以前にいくつかの定期的なスクリプトを作成しましたが、おそらく彼らにはそれほど素晴らしい例がありませんでした。通常のスクリプトで役割/機能をインストールし、いくつかのファイルを問題なくコピーできるようでした。単なるスクリプトと比較して、DSCの利点はわかりませんでした。マシンが、理論上は実際にはカバーしていなかったある種の変更をポーリングできることは別として。
従来のスクリプトに対するDSCの利点は何ですか。たとえば、「役割のインストール、ファイルのコピー」ですか？
- PowerShellを使用すると、リモートマシンに接続して、何かを実行するように指示できるため、DSCに限定されません。
- DSCでは、mofファイルを作成するために何らかのコンパイルを行っているように見えます。次に、スクリプトの後にシェルから実行します。これは不要な手順のようです。
- MSDNの概要 はPowerShellの概要のように読めますが、差別化された特性はわかりません。
あなたが言ったように、あなたはまっすぐなPowerShellコードで、DSCで行うほとんどすべてを行うことができます。
しかし、DSCはすべて構成管理に関するものです。
構成管理とは、コードとさまざまなシステムを使用して、システムが特定の状態にあることを確認するパターンと実践に関するものです。参照 12
構成管理に関する重要なことの1つは、べき等です。構成管理システムでシステムを説明するコードがチェックされ、システムに対して定期的に実行されます。多くの基本的なスクリプトは適切に設計されておらず、システムを構成するために最初に使用したときに正しい動作をしますが、次にエラーが発生したり、重複したりするなどします。構成管理システムは、理想的には、スクリプトをべき等にするために、スクリプトに手動で追加する必要のあるテストおよび状態チェックコードの大部分を抽象化します。
DSCおよび他の多くの構成管理システムに関するもう1つの重要なことは、 再利用可能なリソース を作成することです。これは、世界中の誰とでも共有できる作業を実際に実行します。このように、実際の「構成」は、環境に固有のいくつかの特定の詳細にすぎません。これはまた、他の多くの人々によって使用され、吟味されたものを再利用できるので、はるかに少ないコードを記述する必要があることを意味します。
上記のリンクをいくつか含めましたが、構成管理システムの理論については、インターネット上で見つけることができる優れたWebサイトがたくさんあります。一般的な理論は、すべての構成管理システム（puppet、chef、dsc、ansibleなど）に適用されます。これは確かに学ぶ価値があり、ほとんどの環境で使用する価値があります。
それが呼ばれるずっと前から、私はC＃プロジェクトリーダーとしてDevOpsを行ってきました。これらの「共有のセットアップ」、「IISでアプリの作成」、「IISリライトがインストールされているかどうかの確認」」タイプのスクリプトを数十個作成しました。通常、次のように求められます。 「Xを実行するのはたった1行のコードです」と考える人がそれを実行します。しかし、それがすでに存在する場合はどうなりますか？ステップ1、3はすでに存在するが、2、4は存在しない場合、またはステップ2（たとえば= IISアプリプール）は前回とまったく同じように構成されていませんか？
はい、DSCではスクリプトのすべての「部分」に名前を付ける必要があります。最初は退屈に思えます。しかし、名前を付けないと、DSCエンジンとプロバイダーは、スクリプトのどの部分に時間がかかりすぎているのか、またはスクリプトのどの部分が失敗しているのかを通知できません。
フォルダー、IIS、アプリの展開、またはWindowsの機能を実行している場合は、DSCの学習に数日投資することを強くお勧めします。