在 Azure 自动化中执行 Runbook

借助 Azure 自动化中的流程操作自动化,你可以创建并管理 PowerShell、PowerShell 工作流和图形流程文档。 有关详细信息,请参阅 Azure 自动化操作手册

自动化根据运行手册中定义的逻辑执行任务。 如果运行手册中断,则会从开始处重启。 此行为要求您编写支持在发生暂时性问题时能够重启的 runbook。

在 Azure 自动化中启动 runbook 会创建一个作业,该作业是 runbook 的单个执行实例。 每个作业都通过连接到 Azure 订阅来访问 Azure 资源。 仅当数据中心内的资源可从公有云访问时,作业才能访问这些资源。

Azure 自动化分配辅助角色用于在 runbook 执行期间运行每个作业。 尽管辅助角色由多个自动化帐户共享,但不同自动化帐户中的作业是相互独立的。 你无法控制作业请求的工作者服务。

在 Azure 门户中查看 runbook 列表时,页面会显示针对每个 runbook 已启动的作业状态。 Azure 自动化最多将作业日志存储 30 天。

下图展示了 PowerShell RunbookPowerShell 工作流 Runbook图形化 Runbook 的作业生命周期。

作业状态 - PowerShell 工作流

注意

有关查看或删除个人数据的信息,请参阅 GDPR 的 Azure 数据使用者请求。 有关 GDPR 的详细信息,请参阅 Microsoft 信任中心的 GDPR 部分服务信任门户的 GDPR 部分

Runbook 执行环境

Azure 自动化中的 Runbook 可以在 Azure 沙盒中运行,或者在混合 Runbook 工作器上运行。

如果 runbook 设计为针对 Azure 中的资源进行身份验证和运行,则它们会在 Azure 沙盒中运行。 Azure 自动化会分配一个辅助角色,该辅助角色用于在 runbook 执行期间在沙盒中运行每个作业。 尽管工作角色由多个自动化帐户共享,但不同自动化帐户中的作业是彼此隔离的。 使用同一沙盒的作业受沙盒的资源限制约束。 Azure 沙盒环境不支持交互式操作。

你也可以使用 混合 Runbook 工作器直接在托管此角色的计算机上运行 runbook,并在环境中的本地资源上运行。 Azure 自动化负责存储和管理 runbooks,然后将它们交付到一个或多个指定的计算机。

Azure 存储Azure 密钥保管库Azure SQL 上启用 Azure 防火墙会阻止从 Azure 自动化 runbook 访问这些服务。 即使启用了允许受信任的 Microsoft 服务的防火墙例外,访问也会被阻止,因为自动化不是受信任服务列表的一部分。 启用防火墙后,只能通过使用混合 Runbook Worker 和虚拟网络服务终结点进行访问。

下表列出一些 runbook 执行任务,并为每个任务列出了建议的执行环境。

任务 建议 说明
与 Azure 资源集成 Azure 沙盒 在 Azure 中托管,身份验证更为简单。 如果使用 Azure VM 上的混合 Runbook 辅助角色,则可将 runbook 身份验证与托管标识配合使用
获取管理 Azure 资源的最佳性能 Azure 沙盒 脚本在同一环境中运行,延迟更低。
最大程度减少运营成本 Azure 沙盒环境 没有计算开销,且不需要 VM。
执行长时间运行的脚本 混合 Runbook 辅助角色 Azure 沙盒具有资源限制
与本地服务进行交互 混合 Runbook 辅助角色 直接访问主机,或其他云环境或本地环境中的资源。
需要第三方软件和可执行文件 混合 Runbook 辅助角色 管理操作系统并且可以安装软件。
运行资源密集型脚本 混合 Runbook 辅助角色 Azure 沙盒具有资源限制
使用具有特定要求的模块 混合 Runbook 辅助角色 一些示例包括:
WinSCP - 对 winscp.exe 的依赖
IIS administration - 对启用或管理 IIS 的依赖
使用安装程序安装模块 混合 Runbook 辅助角色 沙盒模块必须支持复制。
使用需要 4.7.2 以外版本的 .NET Framework 的 runbook 或模块 混合 Runbook 辅助角色 Azure 沙盒支持 .NET Framework 4.7.2,不支持升级到其他版本。
运行需要提升权限的脚本 混合 Runbook 辅助角色 沙盒不允许提升。 借助混合 Runbook 工作器,在运行需要提升的命令时,可以关闭 UAC 并使用 Invoke-Command

沙盒中的临时存储

如果需要按照 runbook 逻辑来创建临时文件,则可将 Azure 沙盒中的 Temp 文件夹(即 $env:TEMP)用于 Azure 中运行的 runbook。 唯一的限制是不能使用超过 1 GB 的磁盘空间(每个沙盒的配额)。 使用 PowerShell 工作流时,这种情况可能会引发问题,因为 PowerShell 工作流使用检查点,脚本可能会在不同的沙盒中重试。

使用混合沙盒时,可以根据混合 Runbook Worker 上的存储可用性使用C:\temp。 但是,根据 Azure VM 建议,不应在 Windows 或 Linux 上使用临时磁盘来存储需要持久保留的数据。

资源

Runbook 必须包含处理资源的逻辑,例如虚拟机、网络和网络上的资源。 资源绑定到 Azure 订阅,且 runbook 需要适当的凭据才能访问任何资源。 有关在 runbook 中处理资源的示例,请参阅处理资源

安全性

Azure 自动化使用 Microsoft Defender for Cloud 保护你的资源以及检测 Linux 系统中的漏洞。 无论资源是否在 Azure 中,均可跨工作负荷提供安全性。 请参阅 Azure 自动化中的身份验证简介

Defender for Cloud 对可以在 VM 上运行任何签名或未签名脚本的用户施加限制。 如果您是具有超级用户访问权限的虚拟机用户,则必须通过数字签名显式配置机器或者将其关闭。 否则,只有在创建自动化帐户并启用适当的功能之后,才能通过运行脚本来应用操作系统更新。

凭据

Runbook 需要适当的凭据才能访问任何资源,无论是 Azure 还是第三方系统的资源。 这些凭据存储在 Azure 自动化、密钥保管库等中。

Azure Monitor

Azure 自动化可以使用 Azure Monitor 来监视其计算操作。

Runbook 权限

Runbook 需要具备通过凭据对 Azure 进行身份验证的权限。 请参阅 Azure 自动化身份验证概述

模块

Azure 自动化包括以下 PowerShell 模块:

  • Orchestrator.AssetManagement.Cmdlets - 包含几个内部 cmdlet,它们只有在 Azure 沙盒环境中执行 runbook 或在 Windows 混合 Runbook 工作器中使用时才可用。 这些 cmdlet 设计用于替代 Azure PowerShell cmdlet,以与自动化账户资源进行交互。
  • Az.Automation - 用于与 Azure 自动化交互的推荐 PowerShell 模块,它替代了 AzureRM 自动化模块。 创建自动化帐户时,不会自动包含 Az.Automation 模块,并且需要手动导入它们。
  • AzureRM.Automation - 创建自动化帐户时默认安装。

还支持可安装的模块,而这些模块基于运行簿和 DSC 配置所需的 cmdlet。 有关可用于你的 runbook 和 DSC 配置的模块的详细信息,请参阅在 Azure 自动化中管理模块

证书

Azure 自动化使用证书向 Azure 进行身份验证,或将其添加到 Azure 或第三方资源。 证书通过安全方式存储,以供 runbook 和 DSC 配置访问。

您的 Runbook 可以使用自签名证书,这些证书不是由权威证书颁发机构(CA)签名的。 请参阅创建新证书

作业

Azure 自动化支持从同一自动化帐户运行作业的环境。 一个运行手册 (runbook) 可以同时运行多个作业。 同时运行的作业数量越多,就越有可能将它们调度到同一个沙盒中。 沙盒中最多可以运行 10 个作业。 当沙盒中没有作业在执行时,它将被删除;因此,不应使用它来保存文件。

在同一沙盒进程中运行的作业可能相互影响。 一个示例就是运行 Disconnect-AzAccount cmdlet。 执行此 cmdlet 会断开共享沙盒进程中每个 runbook 作业的连接。 有关使用此方案的示例,请参阅阻止并发作业

注意

在 Azure 沙盒环境中运行的 runbook 启动的 PowerShell 作业可能无法在完整 PowerShell 语言模式下运行。

作业状态

下表介绍作业的可能状态。 可以查看所有 runbook 作业的状态摘要或在 Azure 门户中深入了解特定 runbook 作业的详细信息。 此外,还可配置与 Log Analytics 工作区的集成,以转发 runbook 作业状态和作业流。 有关与 Azure Monitor 日志集成的详细信息,请参阅将作业状态和作业流从自动化转发到 Azure Monitor 日志。 另请参阅获取作业状态,以获取使用 runbook 中的状态的示例。

状态 说明
激活 正在启动任务。
已完成 作业已成功完成。
已失败 图形或 PowerShell 工作流运行手册未能编译。 PowerShell runbook 未能启动或作业遇到异常。 请参阅 Azure 自动化流程册类型
失败,正在等待资源 作业失败,因为它已达到公平份额限制三次,并且每次都从同一个检查点或 Runbook 开始处启动。
已排队 任务正在等待自动化工作器上的资源变得可用,以便可以启动。
正在恢复 系统正在恢复已暂停的作业。
运行中 作业正在运行。
正在运行,正在等待资源 作业已卸载,因为它已达到公平份额限制。 稍后,它将从上一个检查点恢复。
正在启动 作业已分配给工人,系统正在启动它。
已停止 作业在完成之前已被用户停止。
停止中 系统正在停止作业。
已暂停 仅适用于图形和 PowerShell 工作流 Runbook。 作业被用户、系统或 Runbook 中的命令暂停。 如果运行手册没有检查点,则会从开始处启动。 如果它有检查点,它将重新启动并从其上一个检查点继续。 系统仅在发生异常时暂停执行手册。 默认情况下,ErrorActionPreference 变量设置为“继续”,表示出错时作业将保持运行。 如果该首选项变量设置为“停止”,则出错时作业会暂停。
暂停 仅适用于图形和 PowerShell 工作流 Runbook。 系统正在尝试按用户请求暂停作业。 运行手册必须在达到下一个检查点之前才能被挂起。 如果它已经越过了最后一个检查点,它将在完成之前完成,而不是暂停。
作业最近已提交,但尚未激活。

注意

如果发生基础设施故障,作业将在内部重试,最多重试 3 次。

活动记录

在 Azure 自动化中执行 runbooks 时,会将详细信息写入自动化帐户的活动日志。 有关如何使用日志的详细信息,请参阅从活动日志中检索详细信息

例外

本部分介绍在运行手册中处理异常情况或间歇性问题的一些方法。 一个示例是 WebSocket 异常。 正确的异常处理可防止暂时性网络故障导致 runbook 失败。

错误处理偏好 (ErrorActionPreference)

ErrorActionPreference 变量确定 PowerShell 如何响应非终止错误。 终止错误总是会使运行终止,并且不受 ErrorActionPreference 的影响。

当运行手册使用 ErrorActionPreference 时,一般不会终止流程的错误(例如由 Get-ChildItem cmdlet 引发的 PathNotFound)会阻止运行手册的完成。 以下示例演示如何使用 ErrorActionPreference。 由于脚本停止,最后的 Write-Output 命令从不执行。

$ErrorActionPreference = 'Stop'
Get-ChildItem -path nofile.txt
Write-Output "This message will not show"

最后尝试 Catch

Try Catch Finally 在 PowerShell 脚本中用于处理终止错误。 脚本可以使用此机制来捕获特定异常或一般异常。 catch 语句应用于跟踪或尝试处理错误。 以下示例尝试下载一个不存在的文件。 它捕获 System.Net.WebException 异常,并返回任何其他异常的最后一个值。

try
{
   $wc = new-object System.Net.WebClient
   $wc.DownloadFile("http://www.contoso.com/MyDoc.doc")
}
catch [System.Net.WebException]
{
    "Unable to download MyDoc.doc from http://www.contoso.com."
}
catch
{
    "An error occurred that could not be resolved."
}

Throw 可用于生成终止错误。 在 runbook 中定义自己的逻辑时,此机制很有用。 如果脚本满足应停止脚本的条件,则可以使用 throw 语句停止。 以下示例使用此语句显示必需的函数参数。

function Get-ContosoFiles
{
  param ($path = $(throw "The Path parameter is required."))
  Get-ChildItem -Path $path\*.txt -recurse
}

错误

Runbook 必须处理错误。 Azure 自动化支持两种类型的 PowerShell 错误,即终止错误和非终止错误。

发生终止错误时,会停止执行 runbook。 Runbook 停止且作业状态为“失败”。

非终止错误允许脚本在发生错误后继续运行。 非终止错误的一个示例是当 runbook 使用 Get-ChildItem cmdlet 时,其路径不存在。 PowerShell 发现路径不存在,然后引发错误,并继续转到下一文件夹。 此例中的错误不会将 runbook 作业状态设置为“失败”,并且作业甚至可能已完成。 若要强制 runbook 在发生非终止性错误时停止,可以在 cmdlet 上使用 ErrorAction Stop

调用进程

在 Azure 沙盒中运行的 runbook 不支持调用进程,例如可执行文件(.exe 文件)或子进程。 出现这种情况的原因是,Azure 沙盒是在容器中运行的共享进程,该容器可能无法访问所有基础 API。 对于需要第三方软件或调用子进程的方案,应在混合 Runbook 工作者上执行操作手册。

设备和应用程序特征

Azure 沙盒中的 runbook 作业无法访问任何设备或应用程序属性。 用于在 Windows 上查询性能指标的最常见 API 为 WMI,其中一些常用指标包括内存和 CPU 使用率。

Webhooks

外部服务(例如,Azure DevOps Services 和 GitHub)可以在 Azure 自动化中启动运行簿。 为了执行这种类型的启动,服务通过单个 HTTP 请求使用 Webhook。 借助 Webhook,无需实现完整的 Azure 自动化功能即可启动 runbook。

共享资源

为了在云中的所有运行手册之间共享资源,Azure 使用一种称为“公平份额”的概念。 使用公平份额时,Azure 会暂时卸载或停止已运行三小时以上的所有作业。 PowerShell runbookPython runbook 的作业会停止且不会重启,作业状态变为“已停止”。

对于长时间运行的 Azure 自动化任务,建议使用混合 Runbook 工作器。 混合 Runbook 辅助角色不受公平份额限制,并且不会限制 runbook 的执行时间。 其他作业限制适用于 Azure 沙盒和混合 Runbook 工作器。 虽然混合 Runbook 辅助角色不受 3 小时公平份额限制的约束,但你应该开发在辅助角色上运行的 runbook,以便在出现意外的本地基础结构问题时支持重启。

另一种选择是通过使用子 runbook 来优化 runbook。 例如,runbook 可能会在多个资源上循环访问同一函数(例如,对多个数据库执行某个数据库操作)。 可将此函数移至子 runbook,并让 runbook 使用 Start-AzAutomationRunbook 对其进行调用。 子运行手册在独立的进程中并行执行。

使用子 runbook 可减少完成父 runbook 所需的时间总量。 Runbook 可以使用 Get-AzAutomationJob cmdlet 检查子 runbook 的作业状态(如果其在子 runbook 完成后仍有更多操作需要执行)。

后续步骤