Share via

Windows Server 2012、Windows PowerShell 3.0 和 DevOps，第 2 部分

  • Article

这是本系列文章（共两篇）的第二篇。在第一篇文章中，我讲述了有关 PowerShell 和 DevOps 的一些背景信息。在这篇文章中，将向您介绍一些具体细节。PowerShell 3.0 与 Windows Server 2012 类似，有大量的新功能和增强功能，因此这里仅介绍一些浅显的内容。

--Jeffrey

DevOps 一直是 PowerShell 关注的重点，PowerShell 3.0 和 Windows Server 2012 已将DevOps提升到一个新水平。对于 Windows 2012，我们已将关注重点从单个服务器的操作系统转到多个服务器及其连接设备的云操作系统，无论这些设备是物理的还是虚拟的、是本地的还是非本地的。为实现这一目标，我们需要在以下方面重点投入：

  1. 实现所有任务的自动化
  2. 实现可靠和敏捷的自动化
  3. 让运维人员更轻松地执行自动化
  4. 让开发人员能够更轻松地开发工具

实现所有任务的自动化
Windows Server 2008/R2 附带了大约 230 个 cmdlet。Windows Server 2012 附带的 cmdlet 超过该数字的十倍，大约有 2,430 个。现在您几乎可以自动执行服务器所有方面的任务。这些 cmdlet 涵盖网络连接、存储、群集、RDS、DHCP、DNS、文件服务器、打印、SMI-S 等等。如果您阅读过有关 Windows Server 2012 的博客，就可以了解使用 PowerShell 可以做多少事情。如果您没有及时了解该信息，请阅读 Jose Barreto 的“文件服务器”博客文章、Yigal Edery 的“私有云”博客文章、Ben Armstrong 的 Virtual PC Guy 博客文章、“群集和高可用性”博客文章或 Natalia Mackevicius 的“合作伙伴和客户”博客文章，然后您就会了解我的意思。Windows Server 2012 是到目前为止 Windows 的所有版本中自动化程度最高的版本。

已经有大量的硬件和软件合作伙伴发布他们自己的 PowerShell cmdlet，尚未发布的合作伙伴将在其产品的后续版本中陆续发布它们。在美国拉斯维加斯最近召开的 MMS 会议上已经非常清楚地说明了这一点，我认为您在 TechEd 大会上会看到更多支持 Powershell cmdlet 的厂商。在购买任何产品之前，您一定要确认该产品会提供一组完整的 PowerShell cmdlet。如果没有，则应三思而后行并做一些应尽的调查，确定您购买的产品是最新的并且仍在持续投资。如果某些产品没有提供 PowerShell，你需要考虑这些产品是否还缺少其它功能？好消息是到 Windows Server 2012 发布时将有许多产品支持 PowerShell，已经提供 cmdlet 的产品做到这一点很容易并得到非常积极的客户反馈。每个发布 PowerShell cmdlet 的产品都会在其下一版本中增加在 PowerShell 上的投入。

实现可靠和敏捷的自动化

工作流
我们将 Windows Workflow Foundation 引擎集成到了 PowerShell，以便简单轻松地自动执行需要大量时间的任务、大规模的操作任务或者需要跨多台计算机协调的多步骤任务。传统上，Windows Workflow 一直是开发人员的专用工具，该工具需要 Visual Studio 和许多代码才能创建一个解决方案。我们已将其设计成一个现成的解决方案，运维人员使用其现有的 PowerShell 脚本技能可以方便地创建解决方案。工作流为并行执行、操作重试提供直接支持，并能够挂起和恢复操作。例如，工作流可以检测一个需要手动干预的问题，通知运维人员这一情况，然后挂起操作直到运维人员纠正此问题并恢复工作流为止。

运维人员可以利用任何可用的工作流设计器创建工作流。不过我们进一步通过使用 workflow 关键字来扩展 PowerShell 语言，从而简化了方案创建。任何运维人员或开发人员现在都可以使用所有 Windows SKU 中提供的工具方便地创作工作流。工作流的行为与函数不同，它有更多的规则，但是如果您知道如何编写 PowerShell 函数，则有 80% 的把握编写工作流。使用 PowerShell 创作工作流比使用 XAML 容易得多，并且比工作流设计器工具更容易理解。还有一个好处是，您可以将工作流粘贴到电子邮件让其他人阅读/审查，且无需安装特殊工具。下面是一个在多台计算机上并行运行的示例工作流，该工作流在每台计算机上并行收集库存信息。

下面的命令将从 servers.txt 中包含的服务器列表中获得此库存信息，并将结果输出到一个文件。如果其中的任一服务器不能访问，工作流将每 60 秒尝试联系一次该服务器，一直持续一小时。 

工作流正是 DevOps 实施人员需要可靠和重复执行的操作。DevOps 的关键技术之一是 A/B 测试。这种测试技术会部署一个软件的两个版本并运行一段时间。然后比较一些指标（例如，销售的增加量），将胜出的版本部署到所有计算机。工作流功能允许 PowerShell 长时间对大量计算机执行操作，这样可以方便地自动执行 A/B 测试。

计划的作业
我们还无缝集成了任务计划程序和 PowerShell 作业，以便简单而轻松地自动执行调度作业或者当特定事件法发生时自动执行某些作业。下面是持久运行的工作流。该工作流收集配置信息（磁盘信息）然后自行挂起。工作流已启动并取了一个众所周知的名称“CONFIG”。我们将使用任务计划程序恢复此工作流。在本例中，我们注册了一个 ScheduledJob，让其在每周五下午 6 点和系统每次启动时运行。当发生某个特定触发事件时，将运行计划的作业并恢复该工作流。然后，该工作流收集配置信息，将信息放在一个新文件中，并再次自行挂起。

可靠的网络连接
在以前的版本中， PowerShell 默认情况下禁用远程功能，运维人员需要亲临每台计算机并运行 Enable-PSRemoting cmdlet 才能对其远程管理。作为云操作系统，现在通过 PowerShell 远程管理服务器已经是主流方案，因此我们减少了所需的步骤并在所有服务器配置中默认启用 PowerShell 远程功能。我们进行了广泛的安全性分析和测试，确保此功能是安全的。

在 Wojtek Kozaczynski 的“基于标准的管理”博客文章中，他介绍了我们如何将 WS-MAN 作为主要管理协议，并保持 COM 和 DCOM 的向后兼容性。WS-MAN 是一个使用 HTTP 和 HTTPS 的 Web service 协议。尽管这些是有效的 REST 协议，但 PowerShell 仍在这些协议之上建立了一个会话层来重用远程过程以提高性能和利用会话状态。这些会话在对付普通网络中断时非常可靠，但是，如果运维人员在大楼之间漫游时使用便携式计算机通过 Wi-Fi 网络管理服务器，则会偶尔发生中断。我们已经增强了 WSMAN 的会话层。默认情况下，它可以经受长达 3 分钟的网络中断。还向 PowerShell 会话添加了断开连接会话支持，用户可以选择从活动远程会话断开然后再重新连接到同一会话，而不会丢失状态或被迫终止任务的执行。您甚至可以从其他计算机连接到会话（就像远程桌面会话一样）。

让运维人员更轻松地执行自动化
我们希望大幅降低成功自动执行复杂解决方案所需的技术水平要求。最终希望创造这样一个环境，即运维人员只要想到所需的东西，轻点几下键盘即可得到。每个客户的需求和场景各不相同，因此他们需要编写自己的解决方案。我们的目标是简单而轻松地编写可以与面向高级任务的抽象概念紧密结合的脚本，简化编写脚本的首要因素是 cmdlet 的覆盖范围。因此 Windows Server 2012 附带了大约 2,430 个 cmdlet，这极大地方便了自动化。其中许多 cmdlet 在处理现实世界中形形色色的数据中心时非常有效。我们将 cmdlet 与 REST API 和 JSON 对象一起使用，甚至根据需要从管理应用程序获取、解析和发布网页。

为减少执行操作所需的步骤和语法，PowerShell 3.0 简化了语言和实用程序 cmdlet，下面的示例显示了旧语法和新的简化语法执行操作的方式。

PowerShell3.0 改进了运维人员用来编写脚本和创作工作流所需的创作工具，PowerShell-ISE 现在支持丰富的 IntelliSense、代码段、第三方可扩展性和“显示命令”窗口，使用该窗口可以轻松地找到完成任务所需的准确命令和参数。

 

让开发人员能够更轻松地构建工具
由于 PowerShell 功能强大、使用 C 语言惯例并具备对 .Net 对象的编程能力，因此开发人员喜欢使用 PowerShell 编写脚本。PowerShell 3.0 解决了处理 .NET 和对象过程中的大量接合问题，并进一步允许开发人员在更广泛的应用场景中使用 PowerShell。

工具构建增强
PowerShell 3.0 现在有一个抽象语法树 (AST)。这使得应用新的智能工具来创建、分析和操作 PowerShell 脚本成为可能。大量Microsoft 云服务中有一个服务依赖大量的 PowerShell 脚本来运行该服务的各种各样的作业。他们的开发团队使用 AST 开发出一个脚本分析工具。该工具能够确保运维人员执行的脚本复合最佳时间规范。公开的 AST 是 IntelliSense 异常强大的原因。IntelliSense 使用 AST 检查程序的实际行为。

我们修改了 PowerShell 的许多关键领域，使之更易于开发人员使用和扩展以编写自己的工具。这包括访问我们的序列化程序、API 改进，以及 PowerShell_ISE 的可扩展性模型。

脚本增强
PowerShell 3.0 现在使用 .NET 动态语言运行时 (DLR) 技术。PowerShell 监控脚本的执行方式并动态编译脚本或部分脚本以优化性能。脚本的性能各不相同，但一些脚本在 3.0 中的运行速度比以前快 6 倍。

IntelliSense（和命令行上的 Tab 自动补全）现在可以与 .NET 命名空间和类型一起使用。

它可以查找有关程序的原因并使用变量类型推断改进 IntelliSense 的质量。

我们使用两个变体扩展了哈希表构造，这可让开发人员更方便地获取他们需要的行为：

平台构建增强功能
为支持委派管理方案，我们已经简化了该过程。使用 PowerShell 3.0 可以注册远程端点，配置提供的命令并指定运行这些命令的凭据。这样可以让常规用户使用管理员权限运行一组定义良好的 cmdlet。我们已经使用声明式会话配置文件简化了定义可用 cmdlet 的过程。

PowerShell 3.0 还作为 WINPE 的一个可选组件提供。

Windows Server 2012 和 PowerShell 3.0 是优秀的 DevOps 工具
DevOps 是一个新术语，关于它会带来什么存在一些分歧，但在本质上它完全是通过自动化保证变化的安全性并弥合运维人员和开发人员之间的差别。在该领域有许多工作要做，但 Windows Server 2012 和 PowerShell 3.0 为实现这些目标取得了卓有成效的进步。PowerShell 不会是您的 DevOps 工具箱中的唯一工具，但它是每个 DevOps 工具箱中不可或缺的工具。立即下载 Beta 版，并亲自体验一下。

谨启！

Jeffrey Snover
Windows Server 团队的杰出工程师和主要架构师