在 Azure 自动化中执行 Runbook

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

沙盒中的临时存储

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

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

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

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

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

Pretplate

Azure 订阅 是与 Microsoft 达成的使用一项或多项基于云的服务的协议，并会为此向你收费。 对于 Azure 自动化，每个订阅都链接到一个 Azure 自动化帐户，你可以在帐户中 创建多个订阅 。

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

Azure Monitor

Azure 自动化利用 Azure Monitor 来监视其计算机操作。 这些操作需要 Log Analytics 工作区和 Log Analytics 代理 。

适用于 Windows 的 Log Analytics 代理

适用于 Windows 的 Log Analytics 代理之前称为 Microsoft Monitoring Agent (MMA)。

适用于 Linux 的 Log Analytics 代理

Log Analytics 代理日志位于 /var/opt/microsoft/omsagent/log/omsagent.log 。

Runbook 权限

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

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

根据 runbook 和 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 中的状态的示例。

活动日志记录

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

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

ErrorActionPreference

当 runbook 使用 ErrorActionPreference 时，通常发生的非终止错误（例如 Get-ChildItem cmdlet 中的 PathNotFound ）会阻止 runbook 完成。 以下示例演示如何使用 ErrorActionPreference 。 由于脚本停止，最后的 Write-Output 命令从不执行。

$ErrorActionPreference = 'Stop'
Get-ChildItem -path nofile.txt
Write-Output "This message will not show"
Try Catch Finally
              Try Catch Finally 在 PowerShell 脚本中用于处理终止错误。 脚本可以使用此机制来捕获特定异常或一般异常。 
              catch 语句应用于跟踪或尝试处理错误。 以下示例尝试下载一个不存在的文件。 它捕获 System.Net.WebException 异常，并返回任何其他异常的最后一个值。

   $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
              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 在发生非终止性错误时停止，可以使用 ErrorAction Stop cmdlet。
在 Azure 沙盒中运行的 runbook 不支持调用进程，例如可执行文件（.exe 文件）或子进程。 出现这种情况的原因是，Azure 沙盒是在容器中运行的共享进程，该容器可能无法访问所有基础 API。 对于需要第三方软件或需要调用子进程的方案，应在混合 Runbook 辅助角色上执行 runbook。
设备和应用程序特征
Azure 沙盒中的 runbook 作业无法访问任何设备或应用程序特征。 用于在 Windows 上查询性能指标的最常见 API 为 WMI，其中一些常用指标包括内存和 CPU 使用率。 但是，由于在云中运行的作业无法访问基于 Web 的企业管理 (WBEM) 的 Microsoft 实现，所使用的 API 并不重要。 此平台基于通用信息模型 (CIM) 生成，提供用于定义设备和应用程序特性的行业标准。
Webhook
外部服务（例如，Azure DevOps Services 和 GitHub）可以在 Azure 自动化中启动 runbook。 为了执行这种类型的启动，服务通过单个 HTTP 请求使用 Webhook。 借助 Webhook，无需实现完整的 Azure 自动化功能即可启动 runbook。
为了在云中的所有 runbook 之间共享资源，Azure 使用称为公平份额的概念。 使用公平份额时，Azure 会暂时卸载或停止已运行三小时以上的所有作业。 
              PowerShell runbook 和 Python runbook 的作业会停止且不会重启，作业状态变为“已停止”。
对于长时间运行的 Azure 自动化任务，建议使用混合 Runbook 辅助角色。 混合 Runbook 辅助角色不受公平份额限制，并且不会限制 runbook 的执行时间。 其他作业限制适用于 Azure 沙盒和混合 Runbook 辅助角色。 虽然混合 Runbook 辅助角色不受 3 小时公平份额限制的约束，但你应该开发在辅助角色上运行的 runbook，以便在出现意外的本地基础结构问题时支持重启。
另一种选择是通过使用子 runbook 来优化 runbook。 例如，runbook 可能会在多个资源上循环访问同一函数（例如，对多个数据库执行某个数据库操作）。 可将此函数移至子 runbook，并让 runbook 使用 Start-AzAutomationRunbook 对其进行调用。 子 runbook 在单独的进程中并行执行。
使用子 runbook 可减少完成父 runbook 所需的时间总量。 Runbook 可以使用 Get-AzAutomationJob cmdlet 检查子 runbook 的作业状态（如果其在子 runbook 完成后仍有更多操作需要执行）。
若要开始使用 PowerShell Runbook，请参阅教程：创建 PowerShell Runbook。
若要使用 runbook，请参阅在 Azure 自动化中管理 runbook。
有关 PowerShell 的详细信息，请参阅 PowerShell 文档。
有关 PowerShell cmdlet 参考，请参阅 Az.Automation。