Управление стандартами вашей инфраструктуры Azure: подробное изучение нашего сценария

В предыдущей статье мы рассмотрели архитектуру модуля Runbook, который мы создали для назначения диагностических параметров ресурсам в Microsoft Azure. Это инфраструктурное решение Azure можно резюмировать на снимке экрана ниже, где теги на уровне группы ресурсов принудительно задают диагностический параметр для всех ресурсов внутри. Но если сам ресурс имеет те же теги, но разные значения, то он переопределит родительскую настройку. В предыдущей статье мы сосредоточились на функциональных возможностях и архитектуре решения. (Вы можете найти оригинальный сценарий здесь.) В этой статье мы рассмотрим некоторые ключевые моменты сценария, отвечающие за выполнение запланированного решения.
Вспомогательные файлы
Идея этого сценария возникла из сценария, который я создал в 2016 году для назначения профилей почтовых ящиков в Exchange Server 2016. Цель состояла в том, чтобы создать сценарий, который не требует наличия всех командлетов в сценарии. Вместо этого сценарий будет читать файл и использовать эту информацию для почтового ящика/ресурсов.
В этой новой облачной версии сценария мы будем использовать файл JSON для хранения всех командлетов и глобальных параметров, которые могут потребоваться во время выполнения, в учетной записи хранения. В имени файла JSON есть контрольная версия, а первая версия называется operationflag.rules.v1.json.
Все переменные определены в первом {} JSON. На данный момент мы храним такую информацию, как (это запрос для поиска ресурсов, которые у нас есть в этом файле) и всю другую информацию, которой можно поделиться в этой области.
Для любого данного ресурса нам нужно начать с определения первым из них является Microsoft.Compute/virtualMachines (также известные как виртуальные машины), а затем у нас есть команды для каждого бита для этого ресурса, и у них есть префикс S<Integer>, где Integer — позиция бита. Наш сценарий должен проверять функцию, добавлять или удалять ее на основе бита, определенного в группе ресурсов или ресурсе. Таким образом, нам нужно задокументировать все возможные действия в нашем файле JSON.
Например, первый бит, когда мы говорим о виртуальных машинах, отвечает за управление настройками диагностики, таким образом, командлет . Когда скрипт хочет проверить, включена ли эта функция, он использует S0Check. Если функция должна быть активирована, будет использоваться S0Deploy, и то же самое относится к S0Remove, когда функция должна быть удалена.
Сценарий создавался как динамический, и он будет применяться к любому заданному количеству виртуальных машин. Мы использовали <String> для замены во время выполнения. Если нам нужно указать имя загрузочной диагностической учетной записи хранения, мы будем использовать элемент из настройки. Таким образом, мы должны ссылаться на это как <BootDiagName>.
Функция в сценарии найдет эти специальные заполнители (<>) и заменит их ресурсами времени выполнения и глобальными переменными.
Второй файл используется только для виртуальных машин, и в нем есть файл JSON для настройки параметров диагностики в виртуальной машине. Здесь есть хитрость. Файл должен быть уникальным для каждой отдельной ВМ, которую мы хотим включить, поскольку для этого требуется ResourceID данной ВМ в файле конфигурации.
Мы преодолеваем эту проблему, используя строку PLACEHOLDER-resourceId в файле конфигурации, во время выполнения скрипта она заменяет эту строку фактическим , а затем соответствующим образом включает диагностические настройки.
Понимание функций в скрипте
Первая функция, о которой стоит упомянуть, это fLoadVMDiagSettings. Эта функция будет подключаться к учетной записи хранения и определенному контейнеру для загрузки файлов JSON (правил и диагностики ВМ) на локальный компьютер, на котором выполняется сценарий. Все правила загружаются в переменную $Global:Rules.
Мы можем увидеть использование глобальных правил в действии в первых строках скрипта, где мы собираемся получить все типы ресурсов, и они берутся из элемента QueryResources в файле JSON, как указано в коде ниже.
$Resources = Invoke-Expression ("Get-AzResource -ResourceGroupName RG-MSLab " + $Rules[0].QueryResources)
Функция fCreatecmdlet создает все командлеты, которые будут выполняться во время выполнения. Во-первых, он получает действие (проверить, развернуть или удалить), информацию о рассматриваемом ресурсе и позицию бита OperationFlag.
В первом блоке скрипта будет объединено много информации для получения командлета, который нам нужно выполнить, но имейте в виду, что они будут поставляться с <ExpressionName> из файла JSON. Мы решаем проблему, заменяя эти заполнители фактическим значением, большинство из них берутся из файлов JSON (все те, у которых есть $Rules[0].something, берутся из раздела нашего файла JSON).
Примечание. Если вы вводите новые заполнители, эту функцию необходимо соответствующим образом обновить.
Функция fTagAssessment отвечает за создание тегов, когда они не существуют, или за получение тегов из группы ресурсов (при необходимости) и выполнение некоторой проверки. Он вернет текущий OperationFlag любого данного ресурса.
Функция fQuickCheck критически важна для производительности скрипта. Он будет оценивать, применяется ли текущий OperationFlag на уровне ресурсов. Если какая-либо данная функция должна быть удалена, она будет отмечена цифрой 6, если она требует развертывания, то будет отмечена цифра 1, а если она не применима, то будет использоваться x.
Функция Phase1 отвечает за использование текущего OperationFlag. OperationFlag, используемый этой функцией, представляет собой сравнение между конфигурацией в группе ресурсов/ресурсе и фактическим значением, настроенным на уровне ресурса. (Кстати, я согласен, что имя ужасное! Причина такого имени в том, что изначально сценарий планировалось запускать функцию для каждого бита в OperationFlag.)
Логика этого кода инфраструктуры Azure
Идея представления причин, лежащих в основе кода скрипта, состоит в том, чтобы помочь администраторам облака, которые хотят продолжать повторно использовать код из этой статьи и добавлять новые возможности. Цель состоит в том, чтобы как можно меньше работать с кодом и больше полагаться на файлы JSON для предоставления командлетов, необходимых во время выполнения. Логику этого кода можно использовать в нескольких областях, а OperationFlag — это просто идея того, как использовать преимущества кода с использованием JSON и учетных записей хранения для создания динамической среды. Если вы, как и я, в восторге от Azure DevOps, вы можете инициировать создание копии файла в хранилище после его фиксации в репозитории.