共用方式為

Azure 自動化中的 Runbook 執行

  • 發行項

Azure 自動化中的程序自動化，可讓您建立和管理 PowerShell、PowerShell 工作流程和圖形化 Runbook。 如需詳細資訊，請參閱 Azure 自動化 Runbook。

自動化會根據在 Runbook 中定義的邏輯來執行 Runbook。 如果 Runbook 中斷，則會從頭重新啟動。 前提是 Runbook 必須撰寫成發生暫時性問題時可重新啟動。

在 Azure 自動化中啟動 Runbook 時會建立作業，此為 Runbook 的單一執行個體。 每個作業會連線到您的 Azure 訂用帳戶，以存取 Azure 資源。 資料中心內的資源必須開放給公用雲端存取，作業才能存取這些資源。

在 Runbook 執行期間，Azure 自動化會指派背景工作角色來執行每個作業。 雖然背景工作是由多個 Azure 帳戶共用，來自不同自動化帳戶的工作會彼此隔離。 您無法控制由哪個背景工作角色來處理作業要求。

當您在 Azure 入口網站中檢視 Runbook 清單時，可看到已針對每個 Runbook 啟動的每個作業的狀態。 Azure 自動化最多儲存 30 天的作業記錄。

下圖顯示 PowerShell Runbook、PowerShell 工作流程 Runbook 和圖形化 Runbook 的 Runbook 作業生命週期。

Job Statuses - PowerShell Workflow

注意

如需檢視或刪除個人資料的詳細資訊，請參閱 適用於 GDPR 的 Azure 資料主體要求。 如需 GDPR 的詳細資訊，請參閱 Microsoft 信任中心的 GDPR 區段和服務信任入口網站的 GDPR 區段。

Runbook 執行環境

Azure 自動化中的 Runbook 可以在 Azure 沙箱或混合式 Runbook 背景工作角色上執行。

如果 Runbook 設計為對 Azure 中的資源進行驗證和執行，則會在 Azure 沙箱中執行。 在沙箱中的 Runbook 執行期間，Azure 自動化會指派背景工作角色來執行每個作業。 雖然背景工作是由多個 Azure 帳戶共用，來自不同自動化帳戶的工作會彼此隔離。 使用相同沙箱的作業均受限於該沙箱的資源限制。 Azure 沙箱環境不支援互動式作業。 這可防止存取所有跨處理序 COM 伺服器，而且不支援在 Runbook 中對 Win32 提供者進行 WMI 呼叫。  只有透過在 Windows 混合式 Runbook 背景工作角色上執行 Runbook，才能支援這些案例。

您也可以使用混合式 Runbook 背景工作角色，直接在裝載角色的電腦上執行 Runbook，以及針對環境中的本機資源執行 Runbook。 Azure 自動化會儲存並管理 Runbook，然後將 Runbook 傳遞至一部或多部指派的電腦。

在 Azure 儲存體、Azure Key Vault 或 Azure SQL 上啟用 Azure 防火牆，這會封鎖從 Azure 自動化 Runbook 存取這些服務。 即使啟用防火牆例外以允許受信任 Microsoft 服務時，存取也會遭到封鎖，因為自動化不是受信任服務清單的一部分。 啟用防火牆後，只能使用混合式 Runbook 背景工作角色和虛擬網路服務端點來進行存取。

注意

  • 若要在 Linux 混合式 Runbook 背景工作角色上執行，您的指令碼必須經過簽署，也要相應地設定背景工作角色。 或者，必須關閉簽章驗證。
  • Runbook 執行不應相依於沙箱的時區。

下表列出一些 Runbook 執行工作，並列出針對各 Runbook 建議的執行環境。

Task 建議 備註
與 Azure 資源整合 Azure 沙箱 託管在 Azure 中，讓驗證變得更加簡單。 如果您在 Azure VM 上使用混合式 Runbook 背景工作角色，您可以搭配受控識別使用 Runbook 驗證。
取得管理 Azure 資源的最佳效能 Azure 沙箱 指令碼會在相同環境中執行，而且會有較少的延遲。
將營運成本最小化 Azure 沙箱 沒有任何計算額外負荷，也不需要 VM。
執行長時間執行的指令碼 Hybrid Runbook Worker Azure 沙箱有資源限制。
與本機服務互動 Hybrid Runbook Worker 直接存取主機電腦或其他雲端環境或內部部署環境中的資源。
需要第三方軟體和可執行檔 Hybrid Runbook Worker 您可以管理作業系統，並且可以安裝軟體。
使用 Runbook 監視檔案或資料夾 Hybrid Runbook Worker 在混合式 Runbook 背景工作角色上使用監看員工作。
執行耗用大量資源的指令碼 Hybrid Runbook Worker Azure 沙箱有資源限制。
使用具有特定要求的模組 Hybrid Runbook Worker 一些範例包括：
WinSCP - winscp.exe
IIS 管理的相依性 - 啟用或管理 IIS 的相依性
使用安裝程式安裝模組 Hybrid Runbook Worker 沙箱的模組必須支援複製。
使用需要不同於 4.7.2 之 .NET Framework 版本的 Runbook 或模組 Hybrid Runbook Worker Azure 沙箱支援 .NET Framework 4.7.2，而且不支援升級至不同版本。
執行需要提高權限的指令碼 Hybrid Runbook Worker 沙箱不允許提高權限。 使用混合式 Runbook 背景工作角色時，您可以關閉 UAC，並使用 Invoke-Command 來執行需要提高權限的命令。
執行需要存取 Windows Management Instrumentation (WMI) 的指令碼 Hybrid Runbook Worker 在雲端沙箱中執行的工作無法存取 WMI 提供者。

沙箱中的暫存儲存體

如果您需要建立暫存檔作為 Runbook 邏輯的一部分，可以針對於 Azure 中執行的 Runbook 在 Azure 沙箱中使用 Temp 資料夾 (也就是 $env:TEMP)。 唯一限制是您無法使用超過 1 GB 的磁碟空間，這是每個沙箱的配額。 使用 PowerShell 工作流程時，此案例可能會導致問題，因為 PowerShell 工作流程會使用檢查點，而且指令碼可能會在不同的沙箱中重試。

透過混合式沙箱，您可以根據混合式 Runbook 背景工作角色上的儲存體可用性來使用 C:\temp。 不過，根據 Azure VM 建議，您不應該在 Windows 或 Linux 上使用暫存磁碟來保存需要保存的資料。

資源

您的 Runbook 必須包含邏輯來處理資源，例如 VM、網路和網路上的資源。 資源繫結至 Azure 訂用帳戶，而 Runbook 需要適當的認證才能存取任何資源。 關於在 Runbook 中處理資源的範例，請參閱處理資源。

安全性

Azure 自動化使用適用於雲端的 Microsoft Defender 來確保資源的安全性，並偵測 Linux 系統是否遭到入侵。 無論資源是否在 Azure 中，所有工作負載都受到保護。 請參閱 Azure 自動化中的驗證簡介。

適用於雲端的 Defender 會限制哪些使用者可在 VM 上執行任何指令碼 (已簽署或未簽署)。 如果您是對 VM 具有 root 存取權的使用者，則必須以數位簽章來明確設定機器或關閉機器。 否則，只有在建立自動化帳戶並啟用適當功能之後，您才能執行指令碼來套用作業系統更新。

訂用帳戶

Azure 訂用帳戶是您為了使用一或多個雲端式服務，而與 Microsoft 簽訂的合約，需要付費。 對於 Azure 自動化，每個訂用帳戶都連結到 Azure 自動化帳戶，而您可以在此帳戶中建立多個訂用帳戶。

認證

不論是在 Azure 或協力廠商系統上，Runbook 都需要適當的認證，才能存取任何資源。 這些認證儲存在 Azure 自動化、Key Vault 等。

Azure 監視器

Azure 自動化利用 Azure 監視器來監視其機器作業。 這些作業需要 Log Analytics 工作區和 Log Analytics 代理程式。

適用於 Windows 的 Log Analytics 代理程式

適用於 Windows 的 Log Analytics 代理程式可搭配 Azure 監視器，一起管理 Windows VM 和實體電腦。 這些機器可以在 Azure 或非 Azure 環境中執行，例如本地資料中心。

注意

適用於 Windows 的 Log Analytics 代理程式先前稱為 Microsoft Monitoring Agent (MMA)。

Log Analytics Linux 代理程式

適用於 Linux 的 Log Analytics 代理程式運作方式類似適用於 Windows 的代理程式，但會將 Linux 電腦連線到 Azure 監視器。 代理程式會與執行需要根權限命令的特定服務帳戶一併安裝。 如需詳細資訊，請參閱服務帳戶。

Log Analytics 代理程式記錄位於 /var/opt/microsoft/omsagent/log/omsagent.log。

Runbook 權限

Runbook 需要有權限來透過認證向 Azure 進行驗證。 請參閱 Azure 自動化驗證概觀。

模組

Azure 自動化包含下列 PowerShell 模組：

  • Orchestrator.AssetManagement.Cmdlets - 包含數個內部 Cmdlet，只有當您在 Azure 沙箱環境或 Windows 混合式 Runbook 背景工作角色上執行 Runbook 時，才可以使用這些內部 Cmdlet。 這些 Cmdlet 的設計目的是代替 Azure PowerShell Cmdlet，用來與自動化帳戶資源互動。
  • Az.Automation - 建議的 PowerShell 模組，可與取代 AzureRM 自動化模組的 Azure 自動化互動。 當您建立自動化帳戶且需要手動匯入時，不會自動包含 Az.Automation 模組。
  • AzureRM.Automation - 當您建立自動化帳戶時，預設會安裝。

此外，您也可以根據 Runbook 和 DSC 設定所需的 Cmdlet 來安裝模組。 關於 Runbook 和 DSC 設定可用的模組，如需詳細資訊，請參閱在 Azure 自動化中管理模組。

憑證

Azure 自動化使用憑證向 Azure 進行驗證，或將憑證新增至 Azure 或協力廠商資源。 憑證都妥善儲存，供 Runbook 和 DSC 設定來存取。

您的 Runbook 可以使用自我簽署憑證，這種憑證不是由憑證授權單位 (CA) 簽署。 請參閱建立新的憑證。

工作

Azure 自動化支援一個從相同自動化帳戶來執行作業的環境。 單一 Runbook 一次可以執行許多工作。 同時執行的作業越多，越常會分派到相同的沙箱。 最多 10 個作業可以在沙箱中執行。 當沙箱中沒有作業執行時，該沙箱會被刪除；因此，它不應該用來儲存檔案。

相同沙箱流程中執行的作業可能影響彼此。 例如執行 Disconnect-AzAccount Cmdlet。 執行此 Cmdlet 會中斷連接共用沙箱流程中的每個 Runbook 作業。 如需有關解決此情況的範例，請參閱防止同時作業。

注意

如果 PowerShell 作業是從 Azure 沙箱中執行的 Runbook 啟動，可能無法以完整的 PowerShell 語言模式執行。

作業狀態

下表描述作業可能會有的不同狀態。 在 Azure 入口網站中，可以檢視所有 Runbook 作業的狀態摘要，也可以查看特定 Runbook 作業的詳細資訊。 您也可以設定與 Log Analytics 工作區的整合，以轉送 Runbook 作業狀態和作業串流。 如需與 Azure 監視器記錄整合的詳細資訊，請參閱將作業狀態和作業串流從自動化轉送到 Azure 監視器記錄。 如需在 Runbook 中處理狀態的範例，另請參閱取得作業狀態。

狀態 描述
啟用中 正在啟用作業。
已完成 作業已順利完成。
失敗 圖形化或 PowerShell 工作流程 Runbook 無法編譯。 PowerShell Runbook 無法啟動或作業發生例外狀況。 請參閱 Azure 自動化 Runbook 類型。
失敗，正在等待資源 工作失敗，因為其達到 公平共用 的三次上限，且每次從相同的檢查點或啟動 Runbook 開始。
佇列 作業正在等候 Automation 背景工作角色上的資源變為可用，以便能夠啟動。
繼續中 系統正在作業暫停後繼續作業。
執行中 作業正在執行。
執行中，正在等待資源 作業已卸除，因為它達到公平共用限制次數。 它很快就會從其上次的檢查點繼續。
啟動中 此作業已指派給背景工作角色，且系統正在啟動此作業。
已停止 作業在完成前由使用者停止作業。
正在停止 系統正在停止此作業。
已暫停 只適用於圖形化 Runbook 和 PowerShell 工作流程 Runbook。 作業已由使用者、系統或是 Runbook 中的命令暫停。 如果 Runbook 沒有檢查點，它會從頭開始。 如果它有檢查點，它可以再次啟動，並從其上次的檢查點繼續。 系統只會在發生例外狀況時暫停 Runbook。 根據預設，ErrorActionPreference 會設定為 Continue，表示作業在發生錯誤時繼續執行。 如果喜好設定變數設定為 [停止]，作業就會在出現錯誤時暫停。
暫停中 只適用於圖形化 Runbook 和 PowerShell 工作流程 Runbook。 系統依照使用者的要求，正在嘗試暫停作業。 Runbook 必須達到其下一個檢查點才能暫停。 如果作業已經通過其最後一個檢查點，那麼作業會在暫停之前完成。

活動記錄

在 Azure 自動化中執行 Runbook 時會將詳細資料寫入自動化帳戶的活動記錄中。 如需使用此記錄的詳細資訊，請參閱從活動記錄取出詳細資料。

例外狀況

本節說明在 Runbook 中處理例外狀況或間歇問題的一些方法。 例如 WebSocket 例外狀況。 正確處理例外狀況可防止因為暫時性網路失敗而造成 Runbook 失敗。

ErrorActionPreference

ErrorActionPreference 變數決定 PowerShell 如何回應非終止錯誤。 終止錯誤一律會終止，不受 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 例外狀況，並傳回其他任何例外狀況的最後一個值。

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

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 會以作業狀態 Failed 停止。

非終止錯誤即使發生，仍允許指令碼繼續。 例如，當 Runbook 在 Get-ChildItem Cmdlet 中使用不存在的路徑時，就會發生非終止錯誤。 PowerShell 發現路徑不存在，則會擲回錯誤，並繼續下一步資料夾。 此情況下的錯誤不會將 Runbook 作業狀態設為 Failed，作業甚至可能完成。 若要強制 Runbook 在非終止錯誤時停止，您可以在 Cmdlet 上使用 ErrorAction Stop。

呼叫流程

在 Azure 沙箱中執行的 Runbook 不支援呼叫流程，例如可執行檔 (.exe 檔案) 或子流程。 這是因為 Azure 沙箱是容器中執行的共用流程，可能無法存取所有基礎 API。 如果需要協力廠商軟體或呼叫子流程，您應該在 混合式 Runbook 背景工作角色上執行 Runbook。

裝置和應用程式特性

Azure 沙箱中的 Runbook 作業無法存取任何裝置或應用程式特性。 Windows 上最常用來查詢效能計量的 API 是 WMI，記憶體和 CPU 使用量就是其中一些常用的計量。 然而，無論使用什麼 API，雲端執行的作業都無法存取 Microsoft 的 Web 架構企業管理 (WBEM) 實作。 此平台以通用訊息模型 (CIM) 為基礎，提供業界標準來定義裝置和應用程式特性。

Webhooks

外部服務 (例如 Azure DevOps Services 和 GitHub) 可以在 Azure 自動化中啟動 Runbook。 為了以這種方式啟動，服務需要透過單一 HTTP 要求來使用 Webhook。 使用 Webhook 時，Runbook 不需要實作完整的 Azure 自動化功能就能啟動。

共用的資源

為了讓雲端的所有 Runbook 共用資源，Azure 採用所謂的「公平共用」概念。 基於公平共用，Azure 會暫時卸載或停止已執行超過三小時的任何作業。 PowerShell Runbook 和 Python Runbook 的作業會停止且不會重新啟動，而作業狀態會變成 Stopped。

對於長時間執行的 Azure 自動化工作，建議使用混合式 Runbook 背景工作角色。 混合式 Runbook 背景工作角色並未受限於公平共用，而且未限制 Runbook 執行時間長度。 其他作業限制會套用至 Azure 沙箱和混合式 Runbook 背景工作角色。 雖然混合式 Runbook 背景工作角色不受限於 3 小時的公平共用限制，但您應該以發生非預期的本機基礎結構問題時，也能夠重新啟動的背景工作角色，作為您開發 Runbook 執行的環境。

另一個選項是使用子 Runbook 將 Runbook 最佳化。 例如，您的 Runbook 可能在數個資源上重複執行同一個函式，例如，在數個資料庫上執行資料庫作業。 您可以將此函式移至子 Runbook，然後讓您的 Runbook 使用 Start-AzAutomationRunbook 來呼叫此函式。 子 Runbook 會個別的流程中平行執行。

使用子 Runbook 可縮短父 Runbook 完成所需的總時間。 如果您的 Runbook 在子系完成後，仍然還有其他作業，則可以使用 Get-AzAutomationJob Cmdlet 來檢查子 Runbook 的作業狀態。

下一步