Выполнение Runbook в сервисе Cлужба автоматизации Azure

Автоматизация процессов в Cлужба автоматизации Azure позволяет создавать и управлять сценариями PowerShell, рабочими процессами PowerShell и графическими сценариями. Дополнительные сведения см. в разделе Cлужба автоматизации Azure runbooks.

Автоматизация выполняет модули runbook на основе определенной в них логики. Если работа модуля runbook прерывается, он перезапускается с нуля. Это поведение требует написания скриптов, которые поддерживают перезапуск при возникновении временных проблем.

Запуск модуля Runbook в Cлужба автоматизации Azure создает задание, которое является одним экземпляром выполнения модуля Runbook. Каждое задание обращается к ресурсам Azure путем подключения к вашей подписке Azure. Задание может получить доступ к ресурсам в вашем центре обработки данных только в том случае, если эти ресурсы доступны из публичного облака.

Cлужба автоматизации Azure назначает рабочего для выполнения каждого задания во время выполнения Runbook. Хотя рабочие используются многими учетными записями автоматизации, задания от различных учетных записей автоматизации изолированы друг от друга. Вы не можете контролировать, какие рабочие службы выполняют ваше задание.

При просмотре списка модулей Runbook на портале Azure отображается состояние каждого задания, запущенного для каждого модуля Runbook. Cлужба автоматизации Azure хранит журналы заданий максимум 30 дней.

На следующей схеме показан жизненный цикл задания runbook для модулей runbook PowerShell, модулей runbook рабочего процесса PowerShell и графических модулей runbook.

Среда выполнения runbook

Модули Runbook в Cлужба автоматизации Azure могут выполняться в песочнице Azure или Hybrid Runbook Worker.

Если модули Runbook предназначены для проверки подлинности и запуска ресурсов в Azure, они выполняются в песочнице Azure. Cлужба автоматизации Azure назначает рабочую роль для выполнения каждого задания во время выполнения модуля Runbook в песочнице. Хотя рабочие используются многими учетными записями автоматизации, задания от различных учетных записей автоматизации изолированы друг от друга. Для задач, использующих одну и ту же песочницу, действуют ее ограничения по ресурсам. Среда песочницы Azure не поддерживает интерактивные операции.

Гибридный исполнитель Runbook можно использовать для выполнения runbook непосредственно на компьютере, размещающем роль, и взаимодействия с локальными ресурсами в среде. Cлужба автоматизации Azure хранит модули Runbook и управляет ими, а затем передает их на один или несколько назначенных компьютеров.

Включение Брандмауэр Azure в служба хранилища Azure, Azure Key Vault или Azure SQL блокирует доступ из модулей Runbook Cлужба автоматизации Azure для этих служб. Доступ будет заблокирован даже при включении исключения брандмауэра для разрешения доверенных служб Microsoft, так как Автоматизация не является частью списка доверенных служб. С включенным брандмауэром доступ возможен только с помощью гибридного агента Runbook и служебной конечной точки виртуальной сети.

В следующей таблице перечислены некоторые задачи выполнения runbook с рекомендуемой средой выполнения, приведенной для каждого из них.

Временное хранилище в песочнице

Если вам нужно создать временные файлы в рамках логики Runbook, можно использовать папку Temp (то есть $env:TEMP) в песочнице Azure для модулей Runbook, работающих в Azure. Единственным ограничением является то, что вы не можете использовать более 1 ГБ дискового пространства, что является квотой для каждой песочницы. При работе с рабочими процессами PowerShell этот сценарий может вызвать проблему, так как рабочие процессы PowerShell используют контрольные точки и возможно повторение сценария в другой песочнице.

С гибридной песочницей можно использовать C:\temp в зависимости от доступности хранилища на гибридном работнике Runbook. Однако, согласно рекомендациям по виртуальным машинам Azure, не следует использовать временный диск в Windows или Linux для данных, которые необходимо сохранить.

Ресурсы

Ваши рабочие книги должны включать логику для обработки ресурсов, таких как виртуальные машины, сеть, и ресурсы в сети. Ресурсы привязаны к подписке Azure, а модули Runbook требуют соответствующих учетных данных для доступа к любому ресурсу. Пример обработки ресурсов в модуле runbook см. в разделе Обработка ресурсов.

Безопасность

Cлужба автоматизации Azure использует Microsoft Defender для облака для обеспечения безопасности ресурсов и обнаружения компрометации в системах Linux. Безопасность обеспечивается в рабочих процессах, вне зависимости от того, находятся ли ресурсы в Azure или нет. См. Введение в аутентификацию в Cлужба автоматизации Azure.

Defender для облака накладывает ограничения на пользователей, которые могут запускать любые скрипты, подписанные или неподписанные, на виртуальной машине. Если вы являетесь пользователем с корневым доступом к виртуальной машине, необходимо явно настроить компьютер с цифровой подписью или отключить его. В противном случае можно запустить сценарий только для применения обновлений операционной системы после создания учетной записи службы автоматизации и включения соответствующей функции.

Подписки

Azure subscription — это соглашение с Майкрософт использовать одну или несколько облачных служб, для которых взимается плата. Вы можете управлять несколькими подписками из одной учетной записи службы автоматизации, если учетные данные, которые вы используете, имеют доступ к нескольким подпискам.

Подтверждение компетенции

Модуль Runbook требует наличия соответствующих credentials для доступа к любому ресурсу, будь то Azure или сторонним системам. Эти учетные данные хранятся в Cлужба автоматизации Azure, Key Vault и т. д.

Azure Monitor

Cлужба автоматизации Azure может использовать Azure Monitor для мониторинга операций компьютера.

Разрешения для модулей Runbook

Runbook должен иметь разрешения для аутентификации в Azure с помощью учетных данных. См. также Обзор проверки подлинности Cлужба автоматизации Azure.

Модули

Cлужба автоматизации Azure включает следующие модули PowerShell:

• Orchestrator.AssetManagement.Cmdlets — содержит несколько внутренних командлетов, доступных только при выполнении Runbook'ов в среде песочницы Azure или на гибридном рабочем агенте Runbook Windows. Эти командлеты предназначены для использования вместо Azure PowerShell командлетов для взаимодействия с ресурсами учетной записи службы автоматизации.
• Az.Automation — рекомендуемый модуль PowerShell для взаимодействия с Cлужба автоматизации Azure, заменяющий модуль автоматизации AzureRM. Модуль Az.Automation не включается автоматически при создании учетной записи службы автоматизации и их необходимо импортировать вручную.
• AzureRM.Automation — устанавливается по умолчанию при создании учетной записи службы автоматизации.

Поддерживаются также устанавливаемые модули на основе командлетов, которые требуются для модулей runbook и конфигураций DSC. Дополнительные сведения о модулях, доступных для модулей Runbook и конфигураций DSC, см. в разделе Manage modules in Cлужба автоматизации Azure.

Сертификаты

Cлужба автоматизации Azure использует certificates для проверки подлинности Azure или добавляет их в Azure или сторонние ресурсы. Сертификаты хранятся в безопасном доступе для модулей runbook и конфигураций DSC.

Runbook может использовать самоподписанные сертификаты, которые не подписаны центром сертификации (ЦС). См. Создание нового сертификата.

Работы

Cлужба автоматизации Azure поддерживает среду для запуска заданий из той же учетной записи службы автоматизации. В одном модуле Runbook может быть запущено множество заданий одновременно. Чем больше заданий выполняются одновременно, тем вероятнее, что они будут отправлены в одну и ту же песочницу. В песочнице может выполняться не более 10 заданий. Песочница будет удалена, если в ней не выполняются задания; следовательно, его не следует использовать для сохранения файлов.

Задания, которые выполняются в рамках одного процесса песочницы, могут влиять друг на друга. Одним из примеров является выполнение командлета Disconnect-AzAccount. Если запустить этот командлет, то все задания runbook в общем процессе песочницы будут отключены. Пример работы с этим сценарием см. в разделе Предотвращение параллельных заданий.

Состояния заданий

Следующая таблица содержит описание различных состояний, возможных для задания. Вы можете просмотреть сводку состояния для всех заданий Runbook или детализировать сведения о конкретном задании Runbook на портале Azure. Вы также можете настроить интеграцию с рабочей областью Log Analytics для пересылки состояния задания Runbook и потоков заданий. Дополнительные сведения об интеграции с журналами Azure Monitor см. в статье Перенос статуса задания и потоков задания из Automation в журналы Azure Monitor. См. также Получения состояний заданий, где приведен пример работы с состояниями в модуле runbook.

Ведение журнала действий

Выполнение модулей Runbook в Cлужба автоматизации Azure записывает сведения в журнал действий для учетной записи службы автоматизации. Дополнительные сведения об использовании журнала см. в разделе Получение сведений из журнала действий.

Исключения

В этом разделе описываются некоторые способы обработки исключений или временных проблем в Runbook. Примером является исключение WebSocket. Правильная обработка исключений предотвращает отказ модулей runbook из-за временных сбоев в сети.

ПредпочтениеДействияПриОшибке

Переменная ErrorActionPreference определяет, как PowerShell реагирует на незавершающую ошибку. Завершающие ошибки всегда завершаются и не зависят от ErrorActionPreference.

Когда модуль runbook использует ErrorActionPreference, обычно неустранимая ошибка, например PathNotFound из командлета Get-ChildItem, предотвращает выполнение модуля runbook. В следующем примере показано использование 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 должны обрабатывать ошибки. Cлужба автоматизации Azure поддерживает два типа ошибок PowerShell, завершающихся и не завершающихся.

Неустранимые ошибки останавливают выполнение модуля runbook при их возникновении. Модуль runbook останавливается со статусом задания "Ошибка".

Если возникают устранимые ошибки, сценарий все равно продолжает выполняться. Примером нефатальной ошибки является ситуация, когда в рабочей книге используется командлет Get-ChildItem с несуществующим путем. PowerShell видит, что путь не существует, выдает ошибку и переходит к следующей папке. Ошибка в данном случае не изменяет состояние задания runbook на «Сбой», и задание может даже быть выполнено. Чтобы принудительно остановить Runbook на нефатальной ошибке, вы можете использовать ErrorAction Stop в командлете.

Вызов процессов

Модули Runbook, которые выполняются в песочницах Azure, не поддерживают вызывающие процессы, такие как исполняемые файлы (.exe файлы) или подпроцессы. Причиной этого является то, что песочница Azure — это общий процесс, выполняемый в контейнере, который может не иметь доступа ко всем базовым API. Для сценариев, в которых требуется использование программного обеспечения сторонних разработчиков или вызовы подпроцессов, необходимо выполнять runbook на Гибридном Рабочем Агенте Runbook.

Характеристики устройства и приложения

Задания Runbook в песочницах Azure не могут получить доступ к характеристикам устройств или приложений. Наиболее распространенный API, используемый для запроса метрик производительности в Windows, — WMI, причем некоторые распространенные метрики используют память и использование ЦП.

Веб-перехватчики

Внешние службы, например службы Azure DevOps и GitHub, могут запускать модуль Runbook в Cлужба автоматизации Azure. Для этого типа стартапа служба использует вебхук через единственный HTTP-запрос. Использование вебхука позволяет запускать runbooks без реализации полного функционала возможностей Cлужба автоматизации Azure.

Общие ресурсы

Чтобы совместно использовать ресурсы для всех Runbooks в облаке, Azure применяет концепцию, называемую справедливым распределением. Используя механизм честного распределения ресурсов, Azure временно выгружает или останавливает любое задание, выполняющееся более трех часов. Задания для PowerShell runbooks и Python runbooks останавливаются и не перезапускаются, состояние задания становится 'Остановлено'.

Для длительных задач Cлужба автоматизации Azure рекомендуется использовать Hybrid Runbook Worker. Гибридные рабочие узлы Runbook не ограничены равномерным распределением ресурсов и не имеют ограничения по времени выполнения runbook. Другие ограничения на задания распространяются как на песочницы Azure, так и на гибридные рабочие узлы Runbook. Гибридные рабочие роли Runbook не ограничены трехчасовым справедливым распределением, но модули Runbook все равно нужно разрабатывать для использования в рабочих ролях с поддержкой перезапуска при неожиданных проблемах с локальной инфраструктурой.

Еще один вариант — оптимизировать модуль runbook с помощью дочерних модулей. Например, модуль runbook может выполнить циклический перебор одной и той же функции на нескольких ресурсах, скажем, с помощью операции базы данных в нескольких базах данных. Эту функцию можно переместить в дочерний модуль runbook, а родительский модуль runbook будет вызывать ее с помощью Start-AzAutomationRunbook. Дочерние модули runbook выполняются в параллельном режиме отдельными процессами.

Использование дочерних модулей runbook уменьшает количество времени на выполнение родительского модуля runbook. Модуль runbook может использовать командлет Get-AzAutomationJob, чтобы проверить состояние задания для дочернего модуля runbook, если он все еще содержит операции после завершения своего выполнения.

Следующие шаги

• Чтобы начать работу с runbook PowerShell, см. учебное пособие: Создание runbook PowerShell.
• Сведения о работе с руководствами по сценариям см. в разделе Управление руководствами по сценариям в Cлужба автоматизации Azure.
• Дополнительные сведения о PowerShell см. в документации PowerShell.
• Для справки по командлетам PowerShell см. Az.Automation.
• Сведения об устранении неполадок, связанных с общими ресурсами во время выполнения Runbook Cлужба автоматизации Azure, см. в статье Устранение неполадок связанных с общими ресурсами в Cлужба автоматизации Azure.
• Сведения об устранении неполадок во время выполнения runbook в Cлужба автоматизации Azure см. в разделе Устранение неполадок runbook.