DSCと「通常の」スクリプトの違いは何ですか。

PowerShellの望ましい状態の構成DSCに関するITPro.tvのビデオを見ました。彼らはそれを紹介し、効果的にスクリプトを実行します。ただし、これもスクリプトの最初の（実際の）導入でした。そのため、DSCと通常のスクリプトの違いを理解しませんでした。以前に定期的にスクリプトを作成したことがあるのですが、彼らにはそれほど優れた例がなかったのかもしれません。通常のスクリプトが役割/機能をインストールし、いくつかのファイルを問題なくコピーできるように見えました。単なるスクリプトと比較して、DSCの利点はわかりませんでした。マシンは、理論的には実際にはカバーしなかった、ある種の変更をポーリングできることは別として。

従来のスクリプトに対するDSCの利点は何ですか。たとえば、「ロールのインストール、ファイルのコピー」ですか？

• PowerShellを使用すると、リモートマシンに接続して、何かを実行するように指示できるため、DSC専用ではありません。
• DSCでは、mofファイルを作成するためになんらかのコンパイルを行っているように見え、スクリプトの後にシェルからそれを実行しているように見えますが、これは不要な手順のようです。
• MSDNの概要は、 PowerShellの概要のように読み、私は差別の特性が表示されません。

あなたが言ったように、あなたはあなたがDSCでするほとんどすべてを、まっすぐなPowerShellコードで行うことができます。

しかし、DSCはすべて構成管理に関するものです。

構成管理とは、コードとさまざまなシステムを使用して、システムが特定の状態にあることを確認するパターンと実践に関するものです。参照1 2

構成管理について重要なことの1つは、べき等です。構成管理システムでシステムを記述するコードがチェックされ、システムに対して定期的に実行されます。多くの基本的なスクリプトは適切に設計されておらず、システムを構成するために最初に使用したときに正しい動作をしますが、次にエラーが発生したり、重複したりするなどします。構成管理システムは、スクリプトをべき等にするために、スクリプトに手動で追加する必要があるテストコードと状態チェックコードの大部分を抽象化するのが理想的です。

DSCおよびその他の多くの構成管理システムに関するもう1つの重要なことは、世界中の誰とでも共有できる作業を実際に実行する再利用可能なリソースを作成することです。このように、実際の「構成」は、ご使用の環境に固有のいくつかの特定の詳細である必要があります。これはまた、他の多くの人々によって使用され、吟味されたものを再利用できるため、必要なコードを大幅に減らす必要があることも意味します。

上記のいくつかのリンクを含めましたが、構成管理システムの理論についてインターネット上で見つけることができる多くの優れたWebサイトがあります。一般的な理論はすべての構成管理システム（パペット、シェフ、DSC、Ansibleなど）に適用されます。これは確かに学習する価値があり、ほとんどの環境で使用する価値があります。

https://docs.microsoft.com/en-us/powershell/dsc/dscforengineers#i-have-powershell-why-do-i-need-desired-state-configurationをご覧になることをお勧めします。

それが呼ばれる前からずっと、私はC＃プロジェクトのリーダーとして開発を行ってきました。これらの「共有のセットアップ」、「IISでのアプリの作成」、「IIS Rewriteがインストールされているかどうかの確認」などの種類のスクリプトを何十も書きました。私は通常、「Xを実行するためのコードはたった1行である」と考える人から依頼されます。しかし、そのものがすでに存在している場合はどうなりますか？ステップ1、3はすでに存在しているが、2、4は存在しない場合、またはステップ2（IISアプリプールとしましょう）が前回とまったく同じに構成されていない場合はどうなりますか？

はい、DSCでは、スクリプトのすべての「部分」に名前を付ける必要があります。最初は退屈なようです。しかし、名前を付けないと、DSCエンジンとプロバイダーは、スクリプトのどの部分に時間がかかりすぎているのか、またはスクリプトのどの部分が失敗しているのかを通知できません。

フォルダー、IIS、アプリの展開、またはWindowsの機能を実行している場合は、DSCの学習に数日投資することを強くお勧めします。