之前的博文介绍过AzureVM扩展的一些内容，AzureVM extension的国际版和国内版是有挺大区别的，从功能丰富程度来看，国际版目前是要比国内多很多内容的，且即便是相同的功能，可能版本号也不一致，像BGInfo啊，Access管理之类的比较常用，此外还有Docker扩展目前只在preview版本的新门户中才可以直观的看到，这次为了迎合前两篇PowerShell DSC的主题特地选择了AzureVM Extension中的DSC扩展来做介绍，也是想说明一下DSC这种强大编辑的自动化运维手段是可以无缝扩展到云端的。
###################################################################
想在Azure中使用DSC对VM进行维护，方法与本地基本一致，只是在执行时需要通过Azure的PowerShell方法来实现，下图我做了一个非常简单的实例，在本地安装web-server角色，并把ISE脚本保存为叫“111”的*.ps1文件：
之后执行publish-azurevmdscconfiguration，并制定ps1文件的本地路径，这条命令将会把本地的ps1脚本打包成azure可以识别的zip格式，然后上传到当前操作订阅中的blob容器内：
此时我在我的blob内找到了名为“windows-powershell-dsc”的容器，这个名字是默认的，当然你可以在上一步的publish中指定container名字，然后就可以在容器内看到下图中所示的zip包文件：
接下来就是让zip包里面的“期望的配置（DSC）”在目标vm中执行了，对于现有的虚机，可以使用set-azurevmdsctextension来实现，或者在新创建虚拟机中一并实现（具体方法请自行使用get-help查看）：
在我的国际版订阅中可以看到当前DSC扩展的版本是1.9，如下图：
使用get-azurevmdscextensionstatus能够查看执行结果是否成功，如下图显示“successfully”：
登陆目标vm并查看web-server已经成功部署，如下图：
#################################################################
之前有提到过DSC能够将“环境配置”与“结构配置”拆分开，也就是“where”和“what”，下图中我按照此格式定义了只对“webserver“角色的虚拟机来安装IIS控制台，并且将默认网站disable掉，如下图，我把”结构配置（what）“保存为本地的*.ps1格式文件：
然后我在指定受影响的范围，即”环境配置（where）“，并保存为本地的*.psd1文件，如下图：
完成之后依旧使用publish-azurevmdscconfiguration，指定本地的ps1文件，之后确认已经成功将ps1脚本转换成zip格式上传到blob容器内，如下图：
下面就是具体执行步骤，set-azurevmdscextension，与上文不同的是增加了一个"-configurationdatapath"参数，这是用来指定本地psd1文件的，也就是”环境配置（where）“，以此来确保dsc执行范围是否有效，目标vm是否是我期望的”webrole“角色，如下图：
查看进度，会发现dsc的执行会有几个阶段，比如下图中处于”in progress“，稍后就会显示成功：
登陆目标vm可以打开IIS控制台，并且默认网站已经被禁用，如下图：
有关AzureVMextension DSC的日志其实是可以在目标vm中找到的，路径分别为"C:\Packages\Plugins\Microsoft.Powershell.DSC\版本号"和"C:\WindowsAzure\Logs\Plugins\Microsoft.Powershell.DSC\版本号"，里面分别存放了DSC扩展功能所需要的文件以及每一次执行过程的详细日志，管理员可以从中来分析失败的原因，如下图:
#################################################################
PowerShell DSC在本地和Azure云端可以很灵活的部署与执行，而且据可靠消息透露在下一版的SCVMM中也会加入对DSC的支持，这样一来就不会出现被puppet和chef等开源项目抢风头的局面了:)