Поделиться через

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

  • Статья

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

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

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

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

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

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

Состояния задания — рабочий процесс PowerShell

Примечание.

Сведения о просмотре или удалении персональных данных см. в разделе "Общие запросы субъекта данных" для GDPR, запросов субъекта данных Azure для GDPR или запросов субъектов данных Windows для GDPR в зависимости от конкретной области и потребностей. Дополнительные сведения о GDPR см. в разделе, посвященном GDPR, в Центре управления безопасностью Майкрософт и на портале Service Trust Portal.

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

Модули runbook в службе автоматизации Azure можно запускать в песочнице Azure или в гибридной рабочей роли Runbook.

Если модули runbook предназначены для проверки подлинности и запуска ресурсов в Azure, они выполняются в песочнице Azure. Служба автоматизации Azure назначает рабочую роль для выполнения каждого задания во время выполнения модуля runbook в песочнице. Пока рабочие роли используются многими учетными записями автоматизации, задания от различных учетных записей службы автоматизации изолируются друг от друга. Для заданий, использующих одну и ту же песочницу, применяются ее ограничения ресурсов. Среда песочницы Azure не поддерживает интерактивные операции. Он запрещает доступ ко всем внепроцессным COM-серверам и не поддерживает вызовы WMI к поставщику Win32 в runbook.  Эти сценарии поддерживаются только при работе модуля Runbook в гибридной рабочей роли Runbook Windows.

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

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

Примечание.

  • Для запуска в гибридной рабочей роли Runbook Linux сценарии должны быть подписаны, а рабочий процесс настроен соответствующим образом. Кроме того, проверка подписи должна быть отключена.
  • Выполнение Runbook не должно зависеть от часового пояса песочницы.

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

Задача Рекомендация Примечания.
Интеграция с ресурсами Azure Песочница Azure Размещается в Azure, аутентификация проще. Если на виртуальной машине Azure используется гибридная рабочая роль Runbook, вы можете использовать проверку подлинности runbook с помощью управляемых удостоверений.
Обеспечение оптимальной производительности для управления ресурсами Azure Песочница Azure Сценарий выполняется в той же среде, в которой наблюдается меньшая задержка.
Снижение операционных расходов Песочница Azure Отсутствуют служебные данные для вычисления, и нет необходимости в виртуальной машине.
Выполнение долго выполняемого сценария Гибридная рабочая роль Runbook В песочницах Azure есть ограничения ресурсов.
Взаимодействие с локальными службами Гибридная рабочая роль Runbook Прямой доступ к хост-компьютеру или ресурсам в других облачных средах или в локальной среде.
Требуется стороннее программное обеспечение и исполняемые файлы. Гибридная рабочая роль Runbook Вы управляете операционной системой и можете устанавливать программное обеспечение.
Мониторинг файла или папки с модулем Runbook Гибридная рабочая роль Runbook Используйте задачу службы «Наблюдатель» на гибридной рабочей роли Runbook.
Запуск сценария, интенсивно использующего ресурсы Гибридная рабочая роль Runbook В песочницах Azure есть ограничения ресурсов.
Использование модулей с определенными требованиями Гибридная рабочая роль Runbook Ниже приведены некоторые примеры:
WinSCP — зависимость от
winscp.exe администрирования IIS — зависимость от включения или управления IIS
Установка модуля с помощью установщика Гибридная рабочая роль Runbook Модули для песочницы должны поддерживать копирование.
Использование модулей runbook или модулей, для которых требуется платформа .NET Framework, отличная от 4.7.2 Гибридная рабочая роль Runbook Песочницы Azure поддерживают .NET Framework 4.7.2, а обновление до другой версии не поддерживается.
Запуск сценариев, требующих повышения прав Гибридная рабочая роль Runbook Песочницы не допускают повышение прав. С помощью гибридной рабочей роли Runbook можно отключить UAC и использовать Invoke-Command при выполнении команды, требующей повышения прав.
Запуск сценариев, которым требуется доступ к инструментарию управления Windows (WMI) Гибридная рабочая роль Runbook Задания, выполняемые в песочницах в облаке, не могут получить доступ к поставщику WMI.

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

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

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

Ресурсы

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

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

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

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

Подписки

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

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

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

Azure Monitor

Служба автоматизации Azure использует Azure Monitor для наблюдения за работой виртуальных машин. Для выполнения операций требуются рабочая область Log Analytics и агенты Log Analytics.

агент Log Analytics для Windows.

Агент Log Analytics для Windows работает с Azure Monitor для управления виртуальными машинами Windows и физическими компьютерами. Компьютеры могут работать либо в Azure, либо в среде, отличной от Azure, например в локальном центре обработки данных.

Примечание.

Агент Log Analytics для Windows ранее назывался Microsoft Monitoring Agent (MMA).

Агент Log Analytics для Linux

Агент Log Analytics для Linux работает аналогично агенту для Windows, но подключает к Azure Monitor компьютеры Linux. Агент устанавливается с определенными учетными записями служб, выполняющими команды, требующие корневых разрешений. Дополнительные сведения см. в разделе "Учетные записи службы".

Журнал агента Log Analytics находится по адресу /var/opt/microsoft/omsagent/log/omsagent.log.

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

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

Модули

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

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

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

Сертификаты

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

Модули runbook могут использовать самозаверяющие сертификаты, которые не подписаны центром сертификации. См. Создание нового сертификата.

Работы

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

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

Примечание.

Задания PowerShell, запущенные из модуля runbook, который выполняется в песочнице Azure, могут не запускаться в полном Языковом режиме PowerShell.

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

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

Состояние Description
Идет активация Активируется задание.
Завершено Задание успешно выполнено.
Неудачно Графический модуль runbook или модуль runbook рабочего процесса PowerShell не удалось скомпилировать. Не удалось запустить runbook, или в задании возникло исключение. См. Типы модулей runbook в службе автоматизации Azure.
Задание не выполнено. Ожидание ресурсов. Задание не выполнено, так как задание превысило ограничение доли три раза и было запущено с той же контрольной точки или с момента запуска модуля Runbook.
В очереди Задание ожидает появления доступных ресурсов в очереди автоматизации, которые позволят запустить задание.
Возобновление Система возобновляет задание после его приостановки.
Выполняется Задание выполняется.
Задание выполняется. Ожидание ресурсов. Задание выгружено, поскольку превышено ограничение доли. Задание будет возобновлено позже с его последней контрольной точки.
Запуск Задание было назначено рабочей роли, и система его запускает.
Остановлено Задание было остановлено пользователем до его завершения.
Остановка Система останавливает задание.
Приостановлена Применяется только к графическим модулям runbook и модулям runbook рабочих процессов PowerShell. Задание было приостановлено пользователем, системой или с помощью команды в модуле Runbook. Если в модуле Runbook нет контрольной точки, задание начнется с начала модуля. Если в модуле есть контрольная точка, задание возобновится с последней контрольной точки. Модуль runbook будет приостановлен системой только при возникновении исключения. По умолчанию переменная ErrorActionPreference имеет значение «Продолжить», то есть задание продолжит работу при возникновении ошибки. Если для этой переменной задать значение «Остановить», задание будет приостановлено при возникновении ошибки.
Приостановка Применяется только к графическим модулям runbook и модулям runbook рабочих процессов PowerShell. Система пытается приостановить задание по запросу пользователя. Модуль Runbook должен достичь следующей контрольной точки, прежде чем задание может быть приостановлено. Если последняя контрольная точка уже пройдена, то задание будет завершено, прежде чем оно будет приостановлено.
Новый Задание было отправлено недавно, но еще не активировано.

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

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

Исключения

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

ErrorActionPreference

Переменная 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"

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 останавливается с состоянием задания «Сбой».

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

Получение процессов

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

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

Задания runbook в песочницах Azure не могут получить доступ к каким-либо устройствам или характеристикам приложений. Наиболее распространенным API-интерфейсом, используемым для запроса метрик производительности в Windows, является WMI. В число обычных метрик входят использование памяти и ЦП. Однако не имеет значения, какой API используется, так как задания, выполняемые в облаке, не могут получить доступ к управлению предприятием на основе веб-служб (WBEM) в реализации Майкрософт. Эта платформа построена на основе модели CIM, предоставляя отраслевые стандарты для определения характеристик устройств и приложений.

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

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

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

Для совместного использования ресурсов всеми модулями runbook в облаке Azure использует концепцию, которая называется справедливым распределением. При использовании справедливого распределения Azure временно выгружает или останавливает любое задание, которое выполнялось более трех часов. Задания для модулей runbook на основе PowerShell и модулей runbook Python остановлены и не перезапускаются, а состояние задания отображается как «Остановлено».

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

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

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

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