Question

我有一个Azure自动化Runbook，可以为每个订阅启动子Runbook。

foreach ($sub in $subscriptions)
{
    $ChildRunbookInputParams = @{"SubscriptionId"="$($sub.SubscriptionId)"}

    $job = Start-AzureRmAutomationRunbook `
            -Name $ChildRunbookName `
            -Parameters $ChildRunbookInputParams `
            -ResourceGroupName $AutomationAccountResourceGroup `
            -AutomationAccountName $AutomationAccountName 
}

父和子Runbook都使用相同的run-as帐户。

我遇到的问题是Runbook似乎是在共享上下文，即使它们作为独立的作业运行。
父Runbook对包含自动化帐户的订阅执行Set-AzureRmContext，以便它可以Start-AzureRmAutomationRunbook。子Runbook对传递的订阅ID执行Set-AzureRmContext，以便它可以处理该订阅中的资源第一个子Runbook启动后，父Runbook中的后续Start-AzureRmAutomationRunbook调用失败，因为它无法再找到指定的Runbook。并且随着其他子Runbook的启动（父Runbook在第一个更改订阅之前启动了几个子作业），之前启动的子作业开始处理上次订阅的资源。

这是预期的行为吗？使用多个订阅似乎是一个常见的要求;推荐的模式是什么？

Answer 1

我们也遇到了这个问题，并且不得不打开微软的支持案例来解决。自2017年9月以来，Azure PowerShell模块/ cmdlet开始支持将配置文件（AzureRM上下文）中的功能作为参数传递，这可能是唯一可能的。这可确保AzureRM命令并行运行 - 通过工作流或使用Start-AzureRMAutoRunbookJob启动新的子自动化作业 - 针对指定的上下文执行。

出现此问题的原因是因为使用Azure管理的自动化工作者，在高工作量下，Azure会重复使用工作人员以节省资源，并且上下文可能会丢失。

GitHub（https://github.com/jefffanjoy/DemoCode/tree/master/Runbooks/Azure%20Automation）

上提供了此示例

Azure Automation作业共享订阅上下文

1 个答案: