DSC与“常规”脚本相比有什么不同/更好？

我在ITPro.tv上观看了有关PowerShell期望状态配置DSC的视频。他们介绍了它，并有效地运行了脚本。但是，这也是他们第一次（真正）引入脚本，因此我没有理解DSC和常规脚本之间的区别。我以前做过一些常规的脚本编写工作，也许他们只是没有一个很好的例子。似乎常规脚本可以安装角色/功能并复制一些文件就可以了。与脚本相比，我没有看到DSC的好处。除了一台机器能够轮询某种变化外，从理论上讲它们在实践中没有涉及。

DSC与传统脚本相比有什么好处？例如“安装角色，复制文件”？

• 使用PowerShell，您可以连接到远程计算机并告诉它们执行操作，因此这并非DSC所独有。
• 使用DSC，似乎您正在进行某种编译以生成mof文件，然后在脚本执行后从外壳运行它，这似乎是不必要的步骤。
• 在MSDN概述读起来就像PowerShell的概述，我看不出与众不同之处。

就像您说过的那样，您可以使用直接的Powershell代码完成与DSC差不多的所有工作。

但是，DSC只是关于配置管理。

配置管理是关于使用代码和各种系统以确保系统处于特定状态的模式和实践。参考1 2

关于配置管理的重要一件事是幂等。这意味着将检查配置管理系统中描述您系统的代码，并定期针对您的系统运行该代码。许多基本脚本的设计不够好，在您第一次使用它来配置系统时会做正确的事情，但是下次它们会出错，重复某些事情等等。理想情况下，配置管理系统将抽象出必须手动添加到脚本中的大部分测试和状态检查代码，以使脚本具有幂等性。

DSC和许多其他配置管理系统的另一个重要方面是，使可重用的资源实际完成可以与世界上任何人和所有人共享的工作。这样，您实际的“配置”应该只是针对您的环境的一些具体细节。这也意味着您应该需要减少很多代码，因为您可以重复使用许多其他人使用和审查过的东西。

我在上面包括了一些链接，但是您可以在Internet上找到许多有关配置管理系统理论的优秀网站。一般理论适用于所有配置管理系统（人偶，厨师，dsc，ansible等），这当然值得学习，并且值得在大多数环境中使用。

我建议您看一下https://docs.microsoft.com/zh-cn/powershell/dsc/dscforengineers#i-have-powershell-why-do-i-need-desired-state-configuration。

自从我称之为C＃项目负责人以来，我就一直在从事开发工作。我已经编写了许多此类“设置共享”，“在IIS中创建应用”和“检查是否已安装IIS Rewrite”类型的脚本。通常有人认为“做X只是一行代码”而要求我这样做。但是，如果事情已经存在怎么办？如果步骤1,3已经存在但2,4不存在，或者步骤2（假设IIS应用程序池）的配置与上次完全不同，该怎么办？

是的，DSC要求您命名脚本的每个“部分”。起初看起来很乏味。但是，如果您没有命名，那么DSC引擎和提供程序将无法告诉您脚本的哪一部分花费了太长时间，或者脚本的哪一部分失败了。

如果您要进行文件夹，IIS，应用程序部署或Windows功能，我强烈建议您花几天时间学习DSC。