Автоматизация процессов в облаке на основе событий

Сетка событий
Функции
Logic Apps
Azure Monitor
Cosmos DB

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

Архитектура

Схема, демонстрирующая два сценария бессерверной облачной автоматизации.

Сценарии

В этой статье показаны два основных сценария облачной автоматизации:

  1. Добавление тегов в центр затрат. Эта реализация отслеживает центры затрат каждого ресурса Azure. Служба Политика Azureтеги всех новых ресурсов в группе с идентификатором центра затрат по умолчанию. Сетка событий отслеживает события создания ресурсов, а затем вызывает функцию Azure. Функция взаимодействует с Azure Active Directory и проверяет идентификатор центра затрат для нового ресурса. Если он отличается, он обновляет тег и отправляет сообщение электронной почты владельцу ресурса. Запросы REST для Azure Active Directory высмеиваются для простоты. Azure AD также можно интегрировать с помощью модуля PowerShell Azure AD или библиотеки MSAL для Python.

  2. Ответ регулирования. В этом примере выполняется мониторинг базы данных Azure Cosmos DB для регулирования. Оповещения Azure Monitor активируются, когда запросы на доступ к данным в Azure Cosmos DB превышают емкость единиц запросов (или ЕЗ). Группа действий Azure Monitor настроена для вызова функции автоматизации в ответ на эти оповещения. Функция масштабирует ЕЗ до более высокого значения, увеличивая емкость и, в свою очередь, останавливает оповещения.

Примечание

Эти решения не являются единственными для выполнения этих задач и показаны как иллюстрация того, как бессерверные технологии могут реагировать на сигналы окружающей среды (события) и влиять на изменения в вашей среде. Где практические, используйте собственные решения платформы по сравнению с пользовательскими решениями. Например, Azure Cosmos DB изначально поддерживает автомасштабирование пропускной способности в качестве собственной альтернативы сценарию ответа регулирования.

Логотип GitHub Эталонная реализация сценария доступна на сайте GitHub.

Функции в этих сценариях бессерверной облачной автоматизации часто записываются в PowerShell и Python, двух из наиболее распространенных языков сценариев, используемых в системной автоматизации. Они развертываются с помощью Функции Azure Core Tools в Azure CLI. Кроме того, вы используете командлет PowerShell Az.Functions для развертывания Функции Azure и управления ими.

Рабочий процесс

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

  • Реагирование на события ресурсов. Это ответы на такие события, как ресурс Azure или группа ресурсов, которые создаются, удаляются, изменяются и т. д. Этот шаблон использует сетку событий для активации функции для таких событий. Сценарий добавления тегов в центр затрат является примером этого шаблона. К другим распространенным сценариям относятся:

    • предоставление командам DevOps доступа к вновь созданным группам ресурсов;
    • отправка уведомления в DevOps при удалении ресурса и
    • реагирование на события обслуживания для таких ресурсов, как Azure Виртуальные машины (виртуальные машины).
  • Запланированные задачи. Обычно это задачи обслуживания, выполняемые с помощью функций, активируемого таймером. Примеры этого шаблона:

    • остановка ресурса ночью и начиная с утра,
    • чтение содержимого хранилища BLOB-объектов через регулярные интервалы и преобразование в документ Azure Cosmos DB;
    • периодическое сканирование ресурсов, которые больше не используются, и их удаление;
    • автоматическое резервное копирование.
  • Обработка оповещений Azure. В этом шаблоне используется простота интеграции оповещений и групп действий Azure Monitor с Функции Azure. Обычно функция выполняет действия по исправлению в ответ на метрики, log analytics и оповещения, возникающие в приложениях и инфраструктуре. Сценарий регулирования ответа является примером этого шаблона. Ниже приведены другие распространенные сценарии.

    • усечение таблицы, когда База данных SQL достигает максимального размера,
    • перезапуск службы на виртуальной машине при ошибочной остановке и
    • отправка уведомлений в случае сбоя функции.
  • Оркестрация с внешними системами. Этот шаблон позволяет интегрироваться с внешними системами с помощью Logic Apps для оркестрации рабочего процесса. Соединители Logic Apps могут легко интегрироваться с несколькими сторонними службами, а также службами Майкрософт, такими как Microsoft 365. Функции Azure можно использовать для фактической автоматизации. Сценарий добавления тегов в центр затрат демонстрирует этот шаблон. К другим распространенным сценариям относятся:

    • мониторинг ИТ-процессов, таких как запросы на изменение или утверждения, и
    • отправка уведомления по электронной почте при завершении задачи автоматизации.
  • Предоставление в виде веб-перехватчика или API. Задачи автоматизации с помощью Функции Azure можно интегрировать в сторонние приложения или даже средства командной строки, предоставляя функцию как веб-перехватчик или API с помощью триггера HTTP. Несколько методов проверки подлинности доступны в PowerShell и Python для защиты внешнего доступа к функции. Автоматизация выполняется в ответ на внешние события, связанные с приложением, например интеграцию с power apps или GitHub. Ниже приведены распространенные сценарии:

    • активация автоматизации для службы, завершиющейся сбоем, и
    • подключение пользователей к ресурсам организации.
  • Создание интерфейса ChatOps. Этот шаблон позволяет клиентам создавать операционный интерфейс на основе чата, а также выполнять функции разработки и операций и команды в соответствии с взаимодействием с человеком. Это может интегрироваться с Azure Bot Framework и использовать команды Microsoft Teams или Slack для развертывания, мониторинга, распространенных вопросов и т. д. Интерфейс ChatOps создает систему в режиме реального времени для управления рабочими инцидентами, при этом каждый шаг автоматически задокументирован в чате. Узнайте , как ChatOps поможет вам улучшить DevOps для получения дополнительных сведений.

  • Гибридная автоматизация. Этот шаблон использует Служба приложений Azure гибридных подключений для установки программного компонента на локальном компьютере. Этот компонент обеспечивает безопасный доступ к ресурсам на этом компьютере. Возможность управления гибридными средами в настоящее время доступна в системах под управлением Windows с помощью функций PowerShell. Ниже приведены распространенные сценарии:

    • управление локальными компьютерами и
    • управление другими системами за брандмауэром (например, локальным SQL Server) через сервер перехода.

Компоненты

Она состоит из следующих компонентов:

Функции Azure. Функции Azure предоставляют возможности бессерверных вычислений на основе событий в этой архитектуре. Функция выполняет задачи автоматизации при активации событий или оповещений. В двух сценариях функция вызывается с помощью HTTP-запроса. Сложность кода должна быть свернута путем разработки функции без отслеживания состоянияидемпотентной.

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

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

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

Сетка событий. Сетка событий имеет встроенную поддержку событий из других служб Azure, а также пользовательских событий (также называемых настраиваемыми разделами). Операционные события, такие как создание ресурсов, можно легко распространить в функцию автоматизации с помощью встроенного механизма Сетки событий.

Сетка событий упрощает автоматизацию на основе событий с помощью модели публикации и подписки, позволяя надежно автоматизировать события, доставленные по протоколу HTTPS.

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

Действие автоматизации. Этот широкий блок представляет другие службы, с которыми может взаимодействовать ваша функция, чтобы обеспечить функциональность автоматизации. Например, Azure Active Directory для проверки тегов, как в первом сценарии, или базы данных для подготовки как во втором сценарии.

Рекомендации

Эти рекомендации реализуют основы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для повышения качества рабочей нагрузки. Дополнительные сведения см. в статье microsoft Azure Well-Architected Framework.

Устойчивость

Функции Azure

Обработка времени ожидания HTTP

Чтобы избежать превышения времени ожидания HTTP для более длительной задачи автоматизации, поставить это событие в очередь в служебной шине и обработать фактическую автоматизацию в другой функции. Сценарий автоматизации регулирования ответов иллюстрирует этот шаблон, даже если фактическая подготовка единиц запросов Azure Cosmos DB выполняется быстро.

Схема, показывающая надежность в функции автоматизации.

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

Сбои журнала

Рекомендуется регистрировать все сбои при выполнении задач автоматизации. Это позволяет правильно устранять ошибки. Функции Azure изначально поддерживает интеграцию с Application Insights в качестве системы телеметрии.

Параллелизм

Проверьте требование параллелизма для функции автоматизации. Параллелизм ограничен путем задания переменной maxConcurrentRequests в файле host.json. Этот параметр ограничивает количество параллельных экземпляров функций, запущенных в приложении-функции. Так как каждый экземпляр потребляет ЦП и память, это значение необходимо настроить для операций с интенсивным использованием ЦП. Уменьшите значение, maxConcurrentRequests если вызовы функций выглядят слишком медленными или не могут завершиться. Дополнительные сведения см. в разделе "Настройка поведения узла для улучшения обработки параллелизма ".

Идемпотентность

Убедитесь, что функция автоматизации идемпотентна. Azure Monitor и Сетка событий могут выдавать оповещения или события, указывающие на то, что событие, связанное с подпиской, разрешается, срабатывает,выполняется и т. д., ресурс подготавливается, успешно создан и т. д. или даже отправляет ложные оповещения из-за неправильной настройки. Убедитесь, что функция действует только для соответствующих оповещений и событий, и игнорирует все остальные, чтобы ложные или неправильно настроенные события не вызывали нежелательные результаты. Дополнительные сведения см. в разделе "Проектирование Функции Azure для идентичных входных данных".

Сетка событий

Если рабочий процесс использует сетку событий, проверьте, может ли ваш сценарий создать большой объем событий, достаточно, чтобы засорить сетку. Ознакомьтесь со сведениями о доставке и повторных попытках службы "Сетка событий" , чтобы понять, как она обрабатывает события, если доставка не подтверждена, и соответствующим образом измените логику. Рабочий процесс центра затрат не реализует дополнительные проверки для этого, так как он наблюдает только за событиями создания ресурсов в группе ресурсов. Ресурсы мониторинга, созданные во всей подписке, могут создавать большее количество событий, требуя более устойчивой обработки.

Azure Monitor

Если создается достаточно большое количество оповещений, а ресурсы Azure обновления службы автоматизации обновляются, можно достичь ограничений регулирования Resource Manager Azure. Это может негативно повлиять на остальную часть инфраструктуры в этой подписке. Избегайте этой ситуации, ограничивая частоту создания оповещений с помощью Azure Monitor. Вы также можете ограничить оповещения, созданные для определенной ошибки. Дополнительные сведения см. в документации по оповещениям Azure Monitor .

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

Безопасность обеспечивает гарантии от преднамеренных атак и злоупотребления ценными данными и системами. Дополнительные сведения см. в обзоре основы безопасности.

Управление доступом к функции

Ограничьте доступ к функции, активировав HTTP, задав уровень авторизации. При анонимной проверке подлинности функция легко доступна с помощью URL-адреса, http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>например . Проверка подлинности на уровне функции может запутывать конечную точку HTTP, требуя ключи функций в URL-адресе. Этот уровень задается в файле function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

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

Рассмотрите возможность добавления уровней безопасности поверх проверки подлинности функции, например:

Проверка подлинности на уровне функций — единственный вариант, доступный группам действий Azure Monitor с помощью Функции Azure.

Если функцию необходимо вызвать из стороннего приложения или службы, рекомендуется предоставить к ней доступ с помощью слоя Управление API. Этот уровень должен применять проверку подлинности. Управление API имеет уровень потребления, интегрированный с Функции Azure, который позволяет платить только в том случае, если API будет выполнен. Дополнительные сведения см. в статье "Создание и предоставление функций с помощью OpenAPI".

Если вызывающая служба поддерживает конечные точки службы или приватный канал, можно рассмотреть следующие варианты затрат:

  • Используйте выделенный план Служба приложений, где можно заблокировать функции в виртуальной сети, чтобы ограничить доступ к нему. Это невозможно в бессерверной модели на основе потребления.
  • Используйте план Функции Azure Уровня "Премиум", который включает выделенную виртуальную сеть для использования приложениями-функциями.

Чтобы сравнить цены и возможности между этими вариантами, ознакомьтесь с Функции Azure масштабировании и размещении.

Управление доступом к функции

Управляемые удостоверения для ресурсов Azure, компонент Azure Active Directory, упрощают проверку подлинности и доступ к другим ресурсам и службам Azure. Код не должен управлять учетными данными проверки подлинности, так как он управляется Azure AD.

Существует два типа управляемых удостоверений.

  • Назначаемые системой управляемые удостоверения: они создаются как часть ресурса Azure и не могут совместно использоваться несколькими ресурсами. Они удаляются при удалении ресурса. Используйте их для сценариев, в которых используется один ресурс Azure или для которых требуются независимые удостоверения. Оба сценария используют назначаемые системой удостоверения, так как они обновляют только один ресурс. Управляемые удостоверения требуются только для обновления другого ресурса. Например, функция может считывать теги ресурсов без управляемого удостоверения. Ознакомьтесь с этими инструкциями , чтобы добавить назначенное системой удостоверение в функцию.

  • Управляемые удостоверения, назначаемые пользователем: они создаются как автономные ресурсы Azure. Они могут быть общими для нескольких ресурсов и должны быть явно удалены, если они больше не нужны. Ознакомьтесь с этими инструкциями по добавлению удостоверения, назначаемого пользователем, в функцию. Используйте эти сценарии для следующих сценариев:

    • Требовать доступ к нескольким ресурсам, которые могут совместно использовать одно удостоверение или
    • Требуется предварительная авторизация для защиты ресурсов во время подготовки или
    • Ресурсы, которые часто перезапускаются, в то время как разрешения должны быть согласованы.

После назначения удостоверения функции Azure назначьте ей роль с помощью управления доступом на основе ролей Azure (Azure RBAC) для доступа к ресурсам. Например, чтобы обновить ресурс, роль участника должна быть назначена удостоверению функции.

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

Для оценки затрат используйте калькулятор цен Azure. Ниже приведены некоторые рекомендации по снижению затрат.

Azure Logic Apps

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

Приложения логики также имеют фиксированную модель ценообразования. Если необходимо запустить приложения логики, взаимодействующие с защищенными ресурсами в виртуальной сети Azure, их можно создать в среде службы интеграции (ISE).

Дополнительные сведения см. в модели ценообразования для Azure Logic Apps.

В этой архитектуре приложения логики используются в сценарии добавления тегов в центр затрат для оркестрации рабочего процесса.

Встроенные соединители используются для подключения к Функции Azure и отправки уведомлений по электронной почте о завершении задачи автоматизации. Функции предоставляются в виде веб-перехватчика или API с помощью триггера HTTP. Приложения логики активируются только при выполнении HTTPS-запроса. Это экономичный способ по сравнению с проектом, где функции непрерывно опрашивать и проверять определенные критерии. Каждый запрос опроса измеряется как действие.

Дополнительные сведения см. на странице с ценами на Logic Apps.

Функции Azure

Функции Azure доступны следующие три тарифных плана.

  • План "Потребление". Это самый экономичный бессерверный план, где вы платите только за время выполнения функции. В рамках этого плана функции могут выполняться до 10 минут за раз.

  • План "Премиум". Рассмотрите возможность использования Функции Azure плана "Премиум" для сценариев автоматизации с дополнительными требованиями, такими как выделенная виртуальная сеть, более длительный срок выполнения и т. д. Эти функции могут выполняться до часа и должны быть выбраны для более длительных задач автоматизации, таких как выполнение резервных копий, индексирование базы данных или создание отчетов.

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

В этих сценариях автоматизации Функции Azure используются для таких задач, как обновление тегов в Azure Active Directory или изменение конфигурации Azure Cosmos DB путем увеличения ЕЗ до более высокого значения. План потребления подходит для этого варианта использования, так как эти задачи являются интерактивными и не являются длительными.

Azure Cosmos DB

Azure Cosmos DB оплачивает подготовленную пропускную способность и потребляемое хранилище по часам. Подготовленная пропускная способность выражается в единицах запросов в секунду (ЕЗ/с), которые можно использовать для типичных операций базы данных, таких как операции вставки, чтения. Плата за хранение взимается за каждый ГБ, используемый для хранимых данных и индекса. Дополнительные сведения см. в модели ценообразования Azure Cosmos DB .

В этой архитектуре, когда запросы на доступ к данным к Azure Cosmos DB превышают емкость в единицах запросов (или ЕЗ), Azure Monitor активирует оповещения. В ответ на эти оповещения группа действий Azure Monitor настраивается для вызова функции автоматизации. Функция масштабирует ЕЗ до более высокого значения. Это помогает сократить затраты, так как вы платите только за ресурсы, необходимые для рабочих нагрузок в час.

Чтобы получить быструю оценку затрат для рабочей нагрузки, используйте калькулятор емкости Azure Cosmos DB.

Дополнительные сведения см. в разделе "Затраты" в Microsoft Azure Well-Architected Framework.

Рекомендации по развертыванию

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

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

Если рабочий процесс включает ряд функций автоматизации, сгруппировать функции, обслуживаемые одним сценарием, в одном приложении-функции. Дополнительные сведения см. в статье "Управление приложением-функцией ".

При развертывании приложения необходимо отслеживать его. Рассмотрите возможность использования Application Insights , чтобы разработчики могли отслеживать производительность и обнаруживать проблемы.

Дополнительные сведения см. в разделе DevOps в Microsoft Azure Well-Architected Framework.

Императивные действия в ресурсах Azure

В обоих сценариях выше конечный результатом стало изменение состояния ресурсов Azure с помощью прямого взаимодействия с Azure Resource Manager. Хотя это был предполагаемый результат, учитывайте, что это может повлиять на вашу среду, если измененные ресурсы были изначально развернуты декларативно, например с помощью шаблонов Bicep или Terraform. Если эти изменения не реплицируются обратно в исходные шаблоны, следующее использование этих шаблонов может отменить изменения, внесенные этой автоматизацией. Рассмотрите влияние сочетания императивных изменений в ресурсы Azure, которые обычно развертываются с помощью шаблонов.

Развертывание этого сценария

Сведения о развертывании сценария центра затрат см. в шагах по развертыванию на GitHub.

Дальнейшие действия

Узнайте больше о бессерверных реализациях.