Управление параметрами диагностики Azure и диагностикой загрузки ВМ с помощью службы автоматизации Azure.

Администраторы облачных вычислений обычно делают свои среды функционально согласованными, и это может быть достигнуто разными способами. Я предпочитаю использовать конфигурацию желаемого состояния (DSC), которая является частью службы автоматизации Azure, а мой второй вариант — убедиться, что ваши шаблоны ARM и конвейеры Azure DevOps применяют необходимые параметры. Кроме того, мы всегда можем использовать службу автоматизации Azure, чтобы сообщить о любых ресурсах, не соответствующих вашим стандартам. В последнее время я работал с заказчиком, который переместил несколько серверов в рамках переноса с переносом. В таком сценарии преимущества DevOps начнут проявляться, когда в облаке будут подготовлены новые виртуальные машины. Однако это не помогает существующим виртуальным машинам, которые годами работают в среде.

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

Как работает модуль Runbook для облачных операций

При планировании автоматизации для любого сценария мы должны подготовиться к исключениям и способам, позволяющим администратору управлять решением на основе своих требований без особых изменений на уровне кода (runbook). Управление вашей подпиской Azure ничем не отличается, и хотя мы могли бы создать runbook, который включает диагностические параметры на всех ваших виртуальных машинах IaaS (инфраструктура как услуга), это было бы нецелесообразно. Хороший пример: вы можете захотеть иметь журналы для IIS и SQL иначе, чем для обычного сервера приложений.

Первый черновик сценария, из которого была создана эта статья, состоит из трех тегов Azure: OperationFlag, который представляет собой строку и имеет два возможных значения: 0 или 1, где 0 означает выключено, а 1 означает включено. Второй — DiagVersion, у которого есть версия текущих параметров диагностики, которые мы применяем к нашей среде; третий — DiagWorkload, который мы зарезервируем для использования в будущем, но он позволит сценарию применять другую конфигурацию в зависимости от рабочей нагрузки.

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

Та же логика применима к DiagVersion и DiagWorkload. Если их нет на уровне , они будут добавлены с использованием текущей версии и значения тега DiagWorkload.

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

• Оба действия настроены для выполнения на уровне (OperationFlag:11).
• Ресурс будет оцениваться. Если два определенных действия не включены на виртуальной машине, они будут включены.
• Ресурс получит DiagVersion и DiagWorkload. Два действия будут оценены, и если ресурс не соответствует требованиям, модуль Runbook настроит его соответствующим образом.
• Для ресурса эти два действия будут отключены, так как OperationFlag, связанный на уровне , имеет приоритет.

Внутренняя работа OperationFlag

OperationFlag — сердце этого модуля Runbook. Идея этого заключается в том, чтобы позволить администратору определять действия, которые будут происходить с Первый черновик сценария содержит два : первое (зеленое) настраивает ведение журнала диагностики для ресурсов, а второе число (красное) настраивает параметры диагностики загрузки только для типа ресурса виртуальной машины.

Примечание. Параметры диагностики для виртуальной машины отличаются от параметров обычного ресурса (например, балансировщик нагрузки и Key Vault).

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

Вам может быть интересно: как скрипт узнает, что наша вторая цифра относится только к типу ресурса виртуальной машины? Мы решаем эту дилемму с помощью файла JSON, который мы называем rules.standard.v1.json (где v1 относится к версии файла).

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

Это отвечает на вопрос, как мы можем убедиться, что вторая цифра будет использоваться только для ресурса .

Каждая цифра в OperationFlag представлена в файле как S<DigitPosition> (мы начинаем с 0, чтобы соответствовать всем циклам в скрипте и упростить поиск и устранение неисправностей в коде).

Еще одна «особенность» скрипта заключается в том, что все, что появляется в командлетах между <>, является строкой, которую скрипт заменит динамическими значениями во время выполнения.

Запуск скрипта параметров диагностики Azure

Теперь, когда у нас есть представление о том, как была определена логика модуля Runbook, мы можем запустить модуль Runbook и настроить таргетинг на одну или всю подписку. Простой способ сделать это — добавить переключатель -ResourceGroupName в командлет Get-AzResource (строка 218).

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

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

В группе ресурсов RG-MSLAB появилась новая виртуальная машина, и с этой группой ресурсов связаны следующие теги. Виртуальная машина не имеет никаких и параметров , настроенных перед выполнением скрипта.

После выполнения сценария параметры диагностики (изображение ниже) и диагностика загрузки были включены модулем Runbook службы автоматизации Azure.

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

У нас будет следующая статья, объясняющая сам сценарий. На данный момент цель состоит в том, чтобы понять бизнес-требования и использование сценария автоматизации параметров диагностики Azure.