我在 ITPro.tv 上观看了一段关于PowerShell 所需状态配置 DSC。他们介绍了它，并有效地运行了一个脚本。但是，这也是他们第一次（真正）介绍脚本，所以我没有发现 DSC 和常规脚本之间的区别。我以前做过一些常规脚本，也许他们只是没有那么好的例子；常规脚本似乎可以安装角色/功能并复制一些文件。与脚本相比，我没有看到 DSC 有什么好处。除了机器能够轮询某种变化，他们没有在实践中涉及，只是在理论上。
DSC 与传统脚本相比有哪些优势；例如“安装角色、复制文件”？
- 使用 PowerShell，您可以连接到远程机器并告诉它们执行操作，因此这并非 DSC 独有的。
- 使用 DSC 似乎您正在进行某种编译以创建 mof 文件，然后在脚本之后从 shell 运行它，这似乎是不必要的步骤。
- 这MSDN 概述读起来像是 PowerShell 的概述，但我看不出其差异化的特征。
答案1
正如您所说的，您可以使用直接的 powershell 代码完成使用 DSC 可以做的所有事情。
但是，DSC 主要涉及配置管理。
配置管理是关于使用代码和各种系统来确保系统处于特定状态的模式和实践。参考1 2
配置管理的一个重要特点是幂等性。这意味着配置管理系统中描述系统的代码将定期检查并针对您的系统运行。许多基本脚本设计得并不好，第一次使用它来配置系统时会做正确的事情，但下次它们会出错、重复事情等等。理想情况下，配置管理系统将抽象出您必须手动添加到脚本中的大量测试和状态检查代码，以使您的脚本具有幂等性。
DSC 和许多其他配置管理系统的另一个重要特点是可重复利用的资源实际完成的工作可以与世界上任何人共享。这样，您的实际“配置”应该只是特定于您的环境的几个具体细节。这也意味着您需要编写的代码要少得多，因为您可以重复使用已被许多其他人使用和审查过的东西。
我在上面附上了一些链接，但您可以在互联网上找到许多关于配置管理系统理论的优秀网站。一般理论适用于所有配置管理系统（puppet、chef、dsc、ansible 等），它当然值得学习，也值得在大多数环境中使用。
答案2
早在 DevOps 被称作 DevOps 之前，我就以 C# 项目负责人的身份从事 DevOps 工作。我编写了数十个“设置共享”、“在 IIS 中创建应用程序”和“检查是否安装了 IIS Rewrite”类型的脚本。通常有人会要求我这样做，他们认为“只需一行代码就可以完成 X”。但如果这个东西已经存在怎么办？如果步骤 1、3 已经存在，但步骤 2、4 不存在，或者步骤 2（假设是 IIS 应用程序池）的配置与上次不完全相同怎么办？
是的，DSC 要求您命名脚本的每个“部分”。这乍一看似乎很乏味。但如果您不命名，那么 DSC 引擎和提供商就无法告诉您脚本的哪个部分耗时太长，或者脚本的哪个部分失败了。
如果您正在处理文件夹、IIS、应用程序部署或 Windows 功能，我强烈建议您花几天时间学习 DSC。