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

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

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

Архитектура

Diagram that demonstrates two serverless cloud automation scenarios.

Сценарии

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

  1. Тег центра затрат. Эта реализация отслеживает центры затрат каждого ресурса Azure. Служба Политика Azureтеги всех новых ресурсов в группе с идентификатором центра затрат по умолчанию. Сетка событий Azure отслеживает события создания ресурсов, а затем вызывает функцию Azure. Функция взаимодействует с идентификатором Microsoft Entra и проверяет идентификатор центра затрат для нового ресурса. Если он отличается, он обновляет тег и отправляет сообщение электронной почты владельцу ресурса. Запросы REST для идентификатора Microsoft Entra предназначены для простоты. Идентификатор Microsoft Entra также можно интегрировать с помощью модуля Microsoft Graph PowerShell или библиотеки проверки подлинности Майкрософт (MSAL) для Python.

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

Примечание.

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

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

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

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

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

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

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

    • остановка ресурса в ночное время и начиная с утра
    • чтение содержимого большого двоичного объекта служба хранилища через регулярные интервалы и преобразование в документ 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 при написании функций.

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

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

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

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

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

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

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

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

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

Функции Azure

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

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

Diagram that shows reliability in an automation function.

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

Сбои журнала

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

Параллелизм

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

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

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

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

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

Azure Monitor

Если создается достаточно большое количество оповещений, а ресурсы Службы автоматизации обновляют ресурсы Azure, можно достичь ограничений регулирования Azure Resource Manager . Это может негативно повлиять на остальную часть инфраструктуры в этой подписке. Избегайте этой ситуации, ограничив частоту оповещений, создаваемых 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 Premium, который включает выделенную виртуальную сеть для использования приложениями-функциями.

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

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

Управляемые удостоверения для ресурсов Azure, компонент Microsoft Entra, упрощают проверку подлинности функции и доступ к другим ресурсам и службам Azure. Код не требует управления учетными данными проверки подлинности, так как он управляется идентификатором Microsoft Entra.

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

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

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

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

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

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

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

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

Приложения логики Azure

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

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

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

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

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

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

Функции Azure

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

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

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

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

В этих сценариях автоматизации Функции Azure используются для таких задач, как обновление тегов в идентификаторе Microsoft Entra ID или изменение конфигурации 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. Дополнительные сведения см. в статье о бессерверном развертывании серверной части.

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

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

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

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

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

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

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

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

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