PowerShell DSC的配置文件支持“分离”的格式，这是什么意思呢？好比说企业有一套合规性要求，这套要求无论是对开发测试环境还是生产环境都是一致的，但是显然开发测试与生产环境的规模大小以及硬件配置等等是不一样的，这也就导致了在DSC中定义的内容可以分为“What”和“Where”，即管理员要做什么和在哪做。

##################################################################################

如下图所示我们可以简单理解为DSC的配置定义里包含了environment与structural两大部分“章节”，环境配置里面描述了DSC所应该应用的范围（例如具体哪些节点），结构配置里包含了具体要做什么(例如部署web-server角色等等)。

DSC当中内置了三个特殊的变量：

1 其中第一个就是$allnodes用来引用Allnodes所收集的节点数据，并且可以使用.Where() 和.ForEach()进行过滤,

2 一旦经过$allnodes过滤之后就可以引用$node进行更加详细的说明，例如：

3 最后一个就是$configurationdata，通过它就能在最后生成MOF文件的时候将“环境配置”传递进指令，例如我在下文中提到的$mydata中所收集的数据。

在我的测试环境中我将DSC配置脚本的内容拆分按上文拆分为两部分，$mydata主要用来定义我的“环境配置”（即 where），configuration中依然定义的是“结构配置”（也就是what）。$mydata中实际关联的是一个哈希表，哈希表中是一个数 组，哈希表中至少要有一个关键字段就是“Allnodes”，我通过$mydata收集了两台服务器分别是server01和server02，在configuration中对不同的节点角色进行不同的部署要求，例如server01是我的appserver，我想让它安装asp4.5，而server02是我的web服务器，我想让它安装web-server及控制台。

这里就可以看出分别定义“环境配置”与“结构配置”的好处，可能我的开发测试环境就这两台服务器，但是生产环境可能10几台，到时候我只需要从新修改$mydata，而对于“结构配置”不需要改动，因为我对appserver和webserver的角色要求是不需要改变的。

按照上文中的配置，运行PS1脚本，然后再我的c:\script目录下执行myconfig并指定-configurationdata参数，将$mydata所收集到的node信息传递进来，成功后生成了两个mof文件，如下图：

接下来就可以验证了，在第一次执行推送过程的时候除了点小意外，因为我是azure的域环境，没有指定虚拟网络的dns，所以上次重启之后dns变了，于是出现了下图中的链接问题。

这里提示各位如果在azure中部署域控制器，除了要为DC配置azurevm静态IP以外，还需要在虚拟网络里把dns指向dc的IP，如下图：

再次执行start-dscconfiguration推送动作成功，如下图:

分别跑到两台服务器上去验证一下，在server01上看到asp.net 4.5已经部署，如下图：

server02上的web-server也已经可以使用了，如下图:

当然也可以使用test-dscconfigruation来验证，如下图显示为true即表示“满足了期望的配置”。

通过DSC提供的几个特殊变量来灵活的设计脚本，可以很方便的将配置修改应用于不同环境中，例如对一个开发项目从研发到测试再到最终部署到生产环境，使用powersehll dsc就能实现一部分devops的概念，能有效降低那种“开发环境里面运行好好的，一上线就这样我也不知道为什么，奇怪了”之类的情况。。。

本文转自maomaostyle 51CTO博客，原文链接：http://blog.51cto.com/maomaostyle/1643568，如需转载请自行联系原作者