在基于 Powershell DSC 创建配置时，我有点难以弄清楚最佳方法是什么。
部分配置似乎旨在允许多个人/团队为自己的策略/配置创建配置。这很有道理，但我见过有人采用这种方法来创建模块，以构造他们的代码，使其不那么单一。这是一种有效的方法吗？
至于复合资源和角色，似乎您可能会将这两种实现方法结合使用。您可以构建复合资源，例如构建 Web 服务器，然后将角色分配给节点以应用 Web 服务器资源。这是正确的方法吗？
是否存在某种常见的脚手架来建造这样的东西？
我看过https://github.com/Microsoft/DscScaffolding和https://github.com/gaelcolas/DscInfraSample但是据我所知，DSCScaffolding repo 不使用角色，而 DscInfraSample 似乎使用了角色，但我无法真正构建它，因此无法真正看到它实际上在做什么。
我的主要问题是，处理 Powershell DSC 的最佳方法是什么，以及如何最好地组织现实世界的配置以使其可维护？
答案1
我在工作中使用它来将配置应用于 Linux (CentOS) 和 Windows 服务器。我使用推送配置方法和“ApplyAndMonitor”模式。
基本上，我构建了一个名为 DSCTools 的模块，以及一个包含实际配置的单独配置功能。
DSCTools 执行以下操作：-获取计算机名称参数-检查 Active Directory 或手动输入以获取该计算机的属性。（例如，它是 Linux SFTP 服务器还是 Windows 文件服务器）-在应用配置之前检查是否需要在远程计算机上安装模块-创建 MOF 文件-推送配置
Config 基本上是一个巨大的函数，在我的工作中，它是一个大约 3000 行长的 PS1 文件。我使用 Visual Studio Code 和代码折叠来折叠它（Ctrl+K 和 Ctrl+0），然后在高层次上我可以看到所有不同类型的服务器。
通过将所有内容保留在相同的配置中，我可以获得诸如“所有非 AD 服务器的节点都获得此信息”和“所有 AD 服务器的节点都获得此信息”之类的语句。
将来，我计划将 Linux 和 Windows 配置分成两个单独的文件，因为它们没有太多共同点。另外请记住，Linux 尚不支持部分配置。
对于 Windows，多种配置可能会有所帮助。例如，您可以拥有一个所有服务器都接收的“基线”配置，然后拥有一个单独的“安全”配置，其中包含您的 CIS/DISA-STIG 合规性配置。
然后我有一个单独的日志记录工具，用于检查 Powershell DSC 操作日志中是否存在故障。这将让我确切地知道我指定的哪些设置不符合要求。例如，也许开发人员进入并删除了配置文件或注册表设置。
我还使用基本文件共享存储库进行版本控制，并且能够看到配置随着时间的推移是如何变化的。
我花了 2-3 年的时间学习 Powershell 和 DSC，它对我的工作非常有帮助，可以让我管理一切，而且速度更快。