PowerShell DSC（一）简单的推模式

最近因为公司业务需要一直在学习开源平台的内容，比如OpenStack和Docker等等，看着看着就对puppet和chef产生了一些兴趣，随之顺其自然的就发现其实在Windows平台也有自己原生的自动化运维解决方案，它就是PowerShell DSC（desired state configuration），按照字面理解就是“期望的配置状态”，我本人对puppet和chef没有太多深入的研究，但是对比了一下两者与PowerShell DSC的实现机制发现的确是大同小异，在此也不讨论谁先谁后问题，更不会想到谁取代谁或谁更好用的问题，不过对于Win平台而言，即便puppet本身就是支持win的，但既然有原生的DSC那它就一定是首选了。

简而言之PowerShell DSC究竟能干嘛，优势何在，其实它与puppet的用意是一样的，就是面对大规模部署环境时，我们需要满足一定的合规性，或者在某些时候需要批量的变更配置，很多情况下组策略或者脚本并不太适用，PS DSC不需要强制域环境，其次它作为PS语言的扩展，至需要在配置文件里声明你期望目标主机是一个什么样的状态，而无需关注如何实现这个状态，比如你想部署IIS，那么只需要声明你要求这台机器有IIS，至于通过什么样的命令去安装IIS你并不需要关心，这一切将有操作系统自行完成。

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

PowerShell DSC有两种模式，推和拉，因为得益于是源自系统内置的PowerShell来实现，因此不必需要安装agent程序，推模式使用简单，但拉模式更适合有计划性的大规模批量配置变更，也方便修改，下图是两种模式的对比，可以看到拉模式需要一台“pull server”角色，这台服务器实际上会包含一个定义好的Web Serveice（Odata），客户端通过一个URI和相应的GUID来获取配置。

整个DSC的执行基本分为三个阶段：

1. 创建阶段——通过ISE或者干脆使用记事本之类的工具来编写DSC配置并输出MOF格式文件(management object format)。
   

2. 推送或拉取阶段——使用pull or push模式将相应的MOF格式文件传输到目标客户端。

3. 执行阶段——客户端通过本地的LCM（local configuration manageer），LCM内置于操作系统内，如果使用push模式的话也不需要额外的配置，对于Windows Server 2012R2和8.1来说它是开箱即用的。

下图是我的测试环境，我在Azure准备了一台DC，如下图叫做pull server，IP：10.0.1.10

另外一台模拟客户端，叫做server01如下图:

部署好操作系统之后，默认提供12个开箱即用的资源，可以使用get-dscresource获得相应信息，DSC所管理和维护的每一类配置都称为“资源”，通过系统自带的这些资源就可以实现大部分常见的维护工作，例如添加删除服务器角色、拷贝文件、创建用户和组、维护系统服务等内容，如下图：

下面就以最简单也最常用的windowsfeature为例，可以先看看他的属性都定义了哪些内容，例如这个资源的名称，dependson是可以定义需要添加的feature是基于那个依赖角色的，通过它可以实现不同资源的更改顺序，在或者ensure是定义这个功能是开启还是关闭，即“absent or present”

以下便是一个简单的示例，我指定一个configuration名为winserver的DSC配置文件，声明节点是server01，然后期望这台服务器要有两个windowsfeater分别是windowsbackup和telnetclient，编辑好之后直接执行脚本，如下图:

上面的脚本执行后并没有返回任何消息，这是我新建一个叫做script的文件夹并在这个文件夹下面执行我上文中定义好的configuration名（DSC配置文件名，在首行），即“winserver”，执行后如果没有报错的话会在当前目录生成一个与node名一致的MOF文件，如下图:

最终就是要把这个mof文件搞到目标节点上去执行我期望的配置，可以查看该文件的内容如下图:

接下来我就使用简单的推模式来把这个mof搞到server01上去，推模式只需要执行"start-dscconfiguration"并指明mof文件路径，成功之后会在系统后台生成一个job，当然也可以指定job名称，如下图:

过一段时间后发现该job已经完成了，如下图:

登陆到server01上看看，噢~windowsbackup和telnetclient果然已经安装好了，如下图:

上面是一个非常简单的示例，可以看到在对大规模环境进行配置变更时，DSC是有绝对优势的，首先脚本更轻量，并且关键的是可通过test-dscconfiguration来检查变更是否符合要求，有很多其他方案虽然也能达到执行的效果，但是否成功或者说是否100%的按照管理员意愿完成了却不得而知。

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

此外在DSC配置文件中还可以定制属性，例如下图中我对nodename使用了变量，在执行时就可以通过我定义的"-vmname"来指定哪一个节点

在进行推送配置时，可以使用-wait和verbose来实时查看后台日志，如下图:

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

以上就是对PowerShell推模式的简单介绍，如果对系统内置的12个资源不满意或感觉不够使的话，可以从官方获取更丰富的资源包，如下图:

目前最新的是wave 10，里面已经包含了非常丰富的资源，我觉得足够用了。

压缩包里有很多x开头的资源module，之所以是x开头是表示这些属于非官方的，当然如果使用上有问题可以在technet论坛上发言，还是有很多回复的。

要想在本地使用这些资源需要注意解压缩路径，一定要在如下图所示的地方。

成功后可以查看有179个资源，够丰富了吧。

随便找一个看看到底DSC有多强，竟然连SCVMM部署也可以，它的属性里面其实感觉和无人值守部署差不多，使用-syntax能够非常方便的查看语法，如下图:

根据资源里面定义的语法大致如下，感兴趣的筒子可以在自己的环境里不断尝试，很有意思。

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

PowerShell DSC也是跨平台的，它同样能够管理Linux，但是对于已经用惯了puppet或chef的人来讲，没必要转到DSC来，继续保持现状就ok，相反刚接触的人来说，特别是winos的ITpro，我相信PowerShell DSC绝对是首要考虑对象。