Azure: автоматизация назначения Azure Policy для настройки Log Analytics скриптами Azure PowerShell



Обещанные «очень технические» видео по теме Azure на канале – пришло время поделиться некоторыми из личных скриптов и заложенных в них идеях и особенностях реализации той или иной функциональности Azure. В этом видео/посте – поговорим про реализацию автоматического назначения некоторых Azure Policy для конфигурации отправки различными объектами диагностики в Azure Log Analytics при помощи скриптов Azure PowerShell.


Azure: автоматизация назначения Azure Policy для настройки Log Analytics скриптами Azure PowerShell

Почему не с применением ARM Template? – да потому, что «заморочек» в работе с политиками через ARM Template, особенно если говорить о назначении имеющихся политик, да еще и в режиме «исправления» Remediation. Это и огромные нечитаемые «простыни» самого ARM Template вероятными ошибками при копи-пасте и «заморочками» при редактировании, и масса вопросов по описанию в том же (или отдельном) шаблоне всех необходимых учетных записей managed identity (principal) с раздачей им необходимых ролей в том же шаблоне, и процесс поиска и прописывания массы параметров вручную и прочие моменты типа «ручного участия» даже в назначении имен в том же шаблоне… Потому – скрипт, который управляет назначением выбранных политик – является куда меньшим «злом» с точки зрения процесса и более универсальным в работе, чем шаблоны, которые нужно потом очень внимательно править.

И напомню про пару  других моих детальных видео об автоматизации Azure с применением скриптов (с детальным разбором данных скриптов):

  • · Azure – подробный обзор универсального PowerShell скрипта для работы с Azure Log Analytics API – https://youtu.be/2AB-bIQl_4Q
  • · Закон Мерфи для кода или автоматическое копирование файлов между Azure Storage с Azure Logic Apps – https://youtu.be/jvWX6V92aCQ

Но вернемся к представленному Azure PowerShell скрипту, в задачу которого входит назначение политик (стандартных, встроенных в Azure) настройки мониторинга Azure Log Analytics для всех типов сервисов Azure, которые поддерживают данные настройки, на уровне выбранной подписки Azure (хотя в качестве области назначения политик может быть и ресурсная группа, и Management Group). В качестве политики используются встроенные политики Azure Policy, которые соответствуют шаблону имени ‘*diagnostic settings*Log Analytics*’, которые развертываются в режиме Remediation (effect = DeployIfNotExists) для своего типа сервисов.

Какие важные блоки в данном скрипте, на что обратить внимание при работе с назначением политик и использованием их в режиме Remediation (исправления) в коде Azure PowerShell:

  • · Простые операции получения списка нужных политик (или инициатив – набора политик) при помощи команды
    $mons = Get-AzPolicyDefinition | Where-Object { $_.Properties.DisplayName -like ‘*diagnostic settings*Log Analytics*’ }
    и работы с данным списком в цикле для каждого элемента.
  • · Проверка параметров для политики – напомню, что у политики есть свои параметры – большинство из которых – например, тот же режим работы политики – параметр Effect – является установленным по умолчанию в рекомендуемое значение, но вот для данного случая существует еще и параметр logAnalytics (которым назначается конкретное хранилище Log Analytics Workspace, куда направляются все логи) и который может иметь различные модификации имен. Потому – в скрипте проводится проверка точного имени параметра по шалону ‘logAnalytics*’ и формирование параметра на основе полученного имени.

    # get right name of policy’s parameter (typicaly named as logAnalytics or logAnalytics_1 or logAnalytics_param ) to setup required Log Analytics as destination storage
    $obj = $mon.Properties.Parameters
    $prop = Get-Member -InputObject $obj -MemberType NoteProperty -Name logAnalytics*
    # build parameter object
    if($prop)
    {
    $asparam = @{$($prop[0].Name)=$($logan.ResourceId)}
    }

  • · Формирование имени для назначения конкретной политики на основе строки описания политики, из которой по шаблонам извлекается название сервиса (описания для всех политик по управлению настройками диагностики стандартные и позволяют достаточно просто получить имя сервиса, для которого политика предназначена), для которого назначается политика, и после, используя полученное название – создается имя типа $name = “{0}-monitoring-assigned-byScript” -f $aname

    # Build the name of assignment based on substring with Azure service type in Policy’s description
    $aname = $mon.Properties.Description.Split(‘ for ‘)[1].Split(‘ to stream ‘)[0]
    $aname = $aname.Replace(‘ ‘, ”)
    # Workaround for some non-standard descriptions 🙂
    if($aname.Length -gt 32)
    {
    $aname = $mon.Properties.Description.Split(‘ for ‘)[1].Split(‘ and stream the logs to ‘)[0]
    $aname = $aname.Replace(‘ ‘, ”)
    }
    $name = “{0}-monitoring-assigned-byScript” -f $aname

  • · Назначение политики в режиме Remediation – обязательное указание параметров локации (параметр команды -Location) и привязки managed identity (-AssignIdentity) – $assignment = New-AzPolicyAssignment -Name $name -PolicyDefinition $mon -Scope $subsId -PolicyParameterObject $asparam -Location westeurope -AssignIdentity
  • · Ожидание создания учетной записи, привязанной к назначенной политики – требуется время, чтобы вновь созданная учетная запись была реплицирована внутри Azure AD и была доступна – поскольку без этого нельзя назначать требуемые роли на следующем шагу.

    # Assignment have to create Service Principal account and we need to check was account created before continue.
    # The new managed identity must complete replication through Azure Active Directory before it can be granted the needed roles.
    $prid = $assignment.Identity.PrincipalId
    $principal = Get-AzADServicePrincipal -ObjectId $prid
    while(!$principal -and $null -eq $principal)
    {
    Start-Sleep -s 10
    $principal = Get-AzADServicePrincipal -ObjectId $prid
    }

  • · Самая важная часть скрипта – при назначении политик через портал Azure выполняет операции по конфигурированию связанной учетной записи – назначение ролей – на фоне в автоматическом режиме, но когда используется PowerShell – команда New-AzPolicyAssignment только создает учетную запись, но не назначает для нее роли, которые потом требуются для выполнения политикой операций по исправлению конфигураций. Потому скрипт берет данные о ролях из описания политик (внутри каждой политики есть описание требуемых ролей (ID) для операций Remediation) и назначает роли для вновь созданных учетных записей. В случае, если речь идет не просто о политике, а об инициативе (наборе политик) – то тут скрипт просматривает еще и набор политик внутри каждой инициативы и уже из описания политики извлекает ID требуемых ролей (об этом вы найдете в конце видео, когда идет сравнение двух скриптов – для назначения политик и инициатив)

    # WARNING!!! workaround for assignment of the policy that requires remediation
    <#

When creating an assignment using the portal, Azure Policy both generates the managed identity and grants it the roles defined in roleDefinitionIds.

In the following conditions, steps to create the managed identity and assign it permissions must be done manually:

While using the SDK (such as Azure PowerShell)

When a resource outside the assignment scope is modified by the template

When a resource outside the assignment scope is read by the template

The following code iterates the policy definition in $policyDef for the roleDefinitionIds and uses New-AzRoleAssignment to grant the new managed identity the roles.

#>

# Get all policy’s definitions inside each policy in Initiative

$polDefs = $mon.policyDefinitionId

foreach( $polDef in $polDefs)

{

$policyDef = Get-AzPolicyDefinition -Id $polDef

# Use the $policyDef to get to the roleDefinitionIds array

$roleDefinitionIds = $policyDef.Properties.policyRule.then.details.roleDefinitionIds

if ($roleDefinitionIds.Count -gt 0)

{

$roleDefinitionIds | ForEach-Object {

$roleDefId = $_.Split(“/”) | Select-Object -Last 1

New-AzRoleAssignment -Scope $subsId -ObjectId $assignment.Identity.PrincipalId -RoleDefinitionId $roleDefId

}

}

}

  • · И, в заключение – назначение задачи по сканированию конфигурации существующих экземпляров сервисов на соответствие политике и исправлению (Remediation), если данное исправление требуется. Так же, как и в предыдущем случае, при назначении политики через интерфейс портала Azure – данная операция назначается в мастере назначения, а в случае использования скриптов – операция Remediation должна быть назначена отдельной командой явно. Кроме того, чтобы следить за ходом выполнения сканирования и исправления – скрипт выводит на экран текст команды с требуемым ID задачи.

    # Create a remediation for a specific assignment


$name = “Remediation_{0}-monitoring-assigned-byScript” -f $aname

$remtask = Start-AzPolicyRemediation -Name $name -PolicyAssignmentId $assignment.ResourceId -ResourceDiscoveryMode ReEvaluateCompliance

Start-Sleep -s 30

Get-AzPolicyRemediation -Id $remtask.Id

Write-Host “`r`nRemediation task $($remtask.Id) was configured!`r`n`t>>> Check state (ProvisioningState property) by >>> ‘Get-AzPolicyRemediation -Id $($remtask.Id)’ command`r`n”

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

Полный исходный код обоих скриптов, рассмотренных в видео – найдете в аттачменте к данном посту.


Другие доклады по облачным и серверным технологиям у меня на канале:

  • · ИТ-карьера – “ОТКРЫТОЕ СОБЕСЕДОВАНИЕ” – начинаем новый сезон 2021 – приглашаются все желающие – https://youtu.be/h0hk03xX_Z0
  • · Azure AZ-900 – онлайн семинар MUK – построение гибридной инфры с Azure Arc и Windows Admin Center – https://youtu.be/vJhuo7bc-Pg
  • · Azure AZ-900 – онлайн семинар MUK – Azure Security Center – обзор возможностей и конфигурирование – https://youtu.be/1Z3Z6XqJZsM
  • · Azure AZ-900-онлайн семинар MUK-Azure Infrastructure as Code IaC, ARM templates, BICEP, Azure DevOps – https://youtu.be/UOEmloeetfY
  • · Azure AZ-900 – онлайн семинар MUK – Microsoft Power Virtual Agents – создание эффективных чат-ботов – https://youtu.be/mez50o_m0oE
  • · Azure SALES – онлайн-семинар MUK – продажа сервисов Azure для различных сценариев кибербезопасности – https://youtu.be/YF7yKgCVLAA
  • · Azure AZ-900 – онлайн-семинар MUK – обзор Azure Automation, Monitor, Log Analytics, Logic Apps – https://youtu.be/a6VGeDUNYt4
  • · Azure SALES – онлайн-семинар MUK – что такое PaaS службы баз данных Azure SQL и Azure Data Platform – https://youtu.be/38Y-TxFFqT4
  • · Azure SALES – онлайн-семинар MUK – планирование миграции в Azure, стоимость и службы гибридой инфра – https://youtu.be/j_LqwHeLDPY
  • · Azure – онлайн-семинар MUK – планирование миграции в Azure с Azure Migrate, построение гибридой инфра – https://youtu.be/vnQOSPrunKc
  • · Закон Мерфи для кода или автоматическое копирование файлов между Azure Storage с Azure Logic Apps – https://youtu.be/jvWX6V92aCQ
  • · Azure Global AI Bootcamp (UAE) – рус.версия по Cognitive services с PowerShell, Functions, Logic Apps – https://youtu.be/7J4veWZqtpY
  • · Azure – онлайн-семинар MUK – использование сервисов Azure (Logic Apps, Functions, Cognitive) для RPA – https://youtu.be/YQiCfiivpBc
  • · Azure – онлайн-семинар MUK – основы Power Platform создание решений на Power Apps, Flows, Chatbots – https://youtu.be/DECMirInQ2I
  • · Что такое облачные технологии и подготовка к экзамену Microsoft AZ-900 Azure Fundamentals – http://bit.ly/Exam-Az-900

Семинары по AZURE–фундаментальные возможности и основы управления AZURE, использования сервисов безопасности, надежности и мониторинга в AZURE


Подписаться на канал ►►►
Мой LinkedIn ►►► 
ИТ-карьера сисадмина-2019 ►►►
Подготовка к AZ-900 ►►►
Как стать системным администратором ►►►
ИТ карьера – что для этого нужно ►►►
Еще про Azure и серверы ►►►
Про производительность дисков ►►►




По приглашению компании МУК –
https://muk.ua/ – прочитал несколько семинаров по технологиям Azure, в основном в рамках того самого базового курса по Azure, который потом предполагает сдачу сертификационного экзамена Microsoft Az-900 – http://bit.ly/Exam-Az-900 – как раз для тех, кому лениво смотреть весь цикл серий (тем более, что я их так пока и не закончил). Но, если у вас есть потребность “быстренько” познакомиться с основными концепциями и технологиями Azure всего за 4 часа, а не за 15 часов (как в моем курсе http://bit.ly/Exam-Az-900) – тогда смотрите эту “короткую” серию 😉

Темы первого семинара “Основы управления AZURE и базовые сервисы AZURE”


  • Базовые концепции облаков – надежность, эластичность, масштабируемость
  • Датацентры Azure и высокая доступность
  • Утилиты управления Azure – портал, PowerShell, CLI
  • Понятие Resource Group и развертывание ресурсов
  • Основные сетевые сервисы в Azure
  • Основные сервисы хранилищ в Azure
  • Резервное копирование и DR в Azure
  • Виртуальные машины в Azure, отказоустойчивость, мониторинг
  • Вычислительные сервисы в Azure – App Services, Functions
  • Сервисы управления процессами – Power Automate
  • Сервисы контейнеров в Azure


Azure – начальный технический обзор основных сервисов Azure – мой доклад на онлайн-семинаре MUK


Кстати, в конце видео я упоминаю про так называемое “публичное собеседование” –
https://youtu.be/pyzxPupDbI8?t=12811 – эта такое себе анонимное (по желанию) собеседование под запись или сразу в прямом эфире с разбором полетов потом – чтобы желающие сразу могли оценить требования крупной компании на простую должность типа инженера/архитектора поддержки клиентов в Azure. Потом я это опубликую тут, на канале, в разделе ИТ-карьеры – http://bit.ly/ITcarriera_ – а то народ периодически спрашивает, что нужно знать и как понять, знаешь ли ты “это” и просит записать видео – а записывать абстрактно как-то не хочется – типа, перечисления – вот, это, это и это учите, а хотелось бы сделать такой вот живой диалог, плюс – можно же сразу знать, что учить, а я еще буду в конце такого “собеседования” рассказывать, как и для чего 😉 В общем, если вы вдруг хотите поучавствовать в таком эксперименте – добавляйтесь ко мне в контакты в LinkedIn –  https://www.linkedin.com/in/iwalker2000/ и при добавлении не забудьте указать в сообщении, что хотите поучавствовать в онлайн собеседовании 😉


Смотрите продолжение моего доклада по Azure Fundamentals на онлайн семинаре, который проводит по пятницам компания МУК ( https://muk.ua/ ). Первую часть семинара можете посмотреть в записи тут – https://youtu.be/pyzxPupDbI8 – а также напомню, что у меня на канале есть 13 серий базового курса по Azure, который потом предполагает сдачу сертификационного экзамена Microsoft Az-900 – http://bit.ly/Exam-Az-900 . А темами данной части семинара по Azure для технических специалистов стали следующие возможности и функции Azure:

Темы второго семинара “AZURE – основы использования сервисов безопасности, надежности и мониторинга”

  • * Безопасность Azure
    • Защита учетных записей в Azure Active Directory
    • Политики безопасности в Azure
    • Средства защиты данных, шифрование, ключи и секреты
    • Сетевая безопасность Azure
    • Безопасная конфигурация Azure VM
    • Azure Security Center
    • Best Practices для облачной и локальной инфраструктуры с сервисами безопасности Azure
  • * Средства защиты от сбоев
    • Гео-репликация данных
    • Гео-репликация служб
    • Azure Backup
    • Azure Site Recovery
  • * Архитектурные решения
    • Мониторинг инфраструктуры Azure
    • Azure Monitor/Diagnostic
    • Базовые уведомления
    • Azure Automation
    • Azure VM/Apps Insights
    • Azure Log Analytics
    • Использования API для автоматизации мониторинга


Azure – 2я часть – по основнам безопасности, надежности, мониторингу Azure – онлайн-семинар MUK


Другие доклады по облачным и серверным технологиям у меня на канале:

Автоматическое развертывание Windows Failover кластеров в Azure и еще один пример неработающего публичного кода и поддержки от Microsoft


Смотри на действование Microsoft: ибо кто может выпрямить то, что Он сделал кривым? (Екк. 7:13)

Верить в наше время нельзя никому, порой даже самому себе. Мне — можно. (Старина Мюллер)

Северный пушной зверек подкрался незаметно, откуда его никто не ждал… (Работа)

Начало этой истории (которая по странному стечению обстоятельств практически совпала с другой историй про Microsoft support, о которой я писал ранее и с еще более печальной историей про бан моего курса по экзамену AZ-900 со стороны Microsoft) было драматичным… Заказчик присылает на развертывание дизайн ресурсной группы в Azure, в котором кроме всего прочего – еще и 6 Windows Failover Clusters по 2 сервака в каждом и с обычными сроками «на завтра». В принципе, все есть – ARM templates много раз деланы-переделаны, отдельные ARM template/DSC для кластеров официально опубликованы Microsoft на GitHub – https://github.com/Azure/azure-quickstart-templates/tree/master/301-storage-spaces-direct . Звоню заказчику, торгуюсь по срокам, договариваемся «на послезавтра, иншааллах». В моем отделе не принято «сетапить ручками» или сдавать заказчику непроверенные пакет ARM/DSC/PowerShell скриптов – потому день будет на тестирование «на всякий случай», хотя скрипты уже множество раз протестированы и отлажены на предыдущих деплойментах, в том числе и для этого заказчика буквально месяц назад – в общем, на 100% уверены и тестовое развертывание – это «чистая формальность»…

Ага! «Формальность»! Как же! До того момента, как следом за Microsoft с его комплектом ARM/DSC/PowerShell для развертывания кластера на GitHub не подкрался тот самый северный пушной зверек. Народ сразу взялся за дело и … смотрит на меня слегка офигевшими от прихода зверька глазами. Microsoft’овский скрипт для развертывания кластера выдает при тестовом прогоне ошибку:

“DSC Configuration \u0027ConfigS2D\u0027 completed with error(s). Following are the first few: PowerShell DSC resource MicrosoftAzure_xCluster failed to execute Set-TargetResource functionality with error message: The running command stopped because the preference variable “ErrorActionPreference” or common parameter is set to Stop: The network path was not found.\r\n The SendConfigurationApply function did not succeed. LCM failed to start desired state configuration manually.”

и деплоймент всего ARM шаблона обваливается 😦 Понятно, что «на послезавтра» сделать кластеры можно, но «ручками», а это не наш стиль – все инфраструктуры клиентов у нас хранятся в ARM/DSC/PowerShell и даже если нет полной копии сайта в Azure Site Recovery, а только бекапы – восстановление/развертывание копии инфраструктуры заказчика с наличием таких скриптов занимает от минут до нескольких часов.

И вот тут до меня начинает доходить весь круг тех проблем, которые очертил своими лапками пушной зверек, вызванный нежеланием Microsoft сопровождать и тестировать свои скрипты после очередных апдейтов (типа, мы вам их «кинули» 3 года назад и чего это вы еще недовольны?). А проблема в том, что примерно в 1/3 от всех развернутых клиентских инфраструктур у нас присутствуют кластеры и это означает, что случись сейчас что или клиенты захотят «дубликаты» – то у нас нет рабочих скриптов «быстро все повторить». В общем, «зверек» разгулялся по полной…

Быстрое изучение вопроса и поиск решения показало только то, что проблема не только у нас, но есть еще люди на просторах Интернета и даже успели опубликовать проблему в репозитории – https://github.com/Azure/azure-quickstart-templates/issues/6932 – но самое главное в данной ситуации, что никому в Microsoft проблема со скриптом на GitHub для развертывания кластера в Azure не интересна – запрос висит уже месяц и только дополнился еще одним пострадавшим… Ну не работает у людей инфраструктура в Azure – проблемы индейцев пользователей шерифа Microsoft не волнуют, Azure не требует поддержки для пользователей по мнению самого Microsoft. Кстати, и запрос к техническому специалисту в Microsoft, который привязан к конкретному заказчику «пошуршать по продуктовой команде и найти тех, кто выправит то, что сделалось кривым» – так и ушел «вникуда»… Периодически пингую «специалиста» последнюю неделю без какого-либо успеха… А что, Рождество же, Azure и проблемы могут и подождать, «ручками развернете и сконфигурите кластеры»…

Заранее предполагая такую проблему с тем, что в Microsoft об восстановлении скрипта никто и «не почешится», решил сделать запасной вариант развертывания кластеров в Azure, интегрированный в ARM template и использующий «чистый» PowerShell – разбираться, что пошло не так со сценарием DSC в «оригинальном» решении Microsoft, времени и желания не было.

Потому, пока Microsoft не пофиксит (может быть) «главный скрипт», вот вам основная идея, как автоматически развертывать кластеры в Azure через ARM с zero-touch. Да, получилось не так универсально, как в оригинале, но оно простое и понятное для всех, легко модифицируется и, главное, работает 😉

Итак, основные технические нюансы и сам код:

Первое – в Azure можно поднять только Windows Failover Cluster в режиме Storage Spaces Direct на 3 узла максимум. Кроме того, не все нагрузки поддерживаются в таком режиме в Azure, и, самое главное – цена вопроса, поскольку требуются производительные премиумные SSD диски для работы дисковой системы в режиме репликации Storage Spaces Direct в таком кластере.

Второе – чтобы развернуть кластер, необходимо, чтобы виртуальные машины, в нем участвующие, как узлы, имели частные статические IP в виртуальной сети Azure и были добавлены в единый Availability Set. ОС внутри этих ВМ должны быть добавлены в домен (кстати, если нужно только добавить ВМ в домен, то это можно сделать и непосредственно в ARM через расширение JsonADDomainExtension), на них установлены необходимые роли и службы. Это не проблема, такую работу выполняет простой PowerShell скрипт:

[CmdletBinding()]

param (

    [Parameter()]

    [string]

$domainname,

    [string]

$biosname,

    [string]

$adminname,

    [string]

$adminpwd

)

#Online the cluster’s disks

Get-Disk |  Where-Object IsOffline -eq $true | Set-Disk -IsOffline $false

#install failover clustering services and tools

Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -IncludeManagementTools

Start-Sleep -Seconds 5

Install-WindowsFeature FS-FileServer

Start-Sleep -Seconds 5

# generate domain admin’s credentials for domain join

$adminusername = “$biosname\$adminname”

$password = ConvertTo-SecureString -String $adminpwd -AsPlainText -Force

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $adminusername, $password

Add-Computer -DomainName $domainname -Credential $cred -Restart -Force

Скрипт помещается в виде файла в какой-то Azure BLOB Storage (не забудьте разрешить анонимный доступ к объектам внутри контейнеров, хотя можно и заморочиться с атрибутам ресурса и указанием ключа доступа к этому BLOB) и запускается такой скрипт внутри VM из ARM template, как ресурс для создаваемой виртуальной машины с использованием extentions типа CustomScriptExtention, с указанием правильного пути к скрипту, который вы только что скопировали в BLOB (атрибут fileUris) и генерацией правильной командной строки (атрибут commandToExecute). Вот пример фрагмента кода именно ресурса (должен быть пристыкован к BМ) для ARM template:

“resources”: [

            {

“type”: “extensions”,

“name”: “CustomScriptExtension”,

“apiVersion”: “2017-03-30”,

“location”: “[parameters(‘location’)]”,

“dependsOn”: [

“[concat(‘Microsoft.Compute/virtualMachines/’, parameters(‘vmname1av1’))]”,

“[concat(‘Microsoft.Compute/virtualMachines/’, parameters(‘vmname2av1’))]”

              ],

“properties”: {

“publisher”: “Microsoft.Compute”,

“type”: “CustomScriptExtension”,

“typeHandlerVersion”: “1.8”,

“autoUpgradeMinorVersion”: true,

“settings”: {

“fileUris”: [

https://mystorage.blob.core.windows.net/CL/pre-setupVM.ps1&#8221;

                  ],

“commandToExecute”: “[concat(‘powershell -ExecutionPolicy Unrestricted -File pre-setupVM.ps1 -domainname ‘, parameters(‘domainname’), ‘ -biosname ‘, parameters(‘netbiosname’), ‘ -adminname ‘, parameters(‘adminUsername’), ‘ -adminpwd ‘, parameters(‘adminPassword’))]”

}

}

}

]

Еще хочу обратить внимание на формирование строки для выполнения пользовательского скрипта – начинается она с вызова powershell с правильными параметрами -ExecutionPolicy Unrestricted и указанием имени файла вашего скрипта в параметре -File.

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

Третье – и вот тут, после выполнения скрипта и перезагрузки каждой машины начинаются проблемы. ARM считает свою работу по запуску скриптов выполненной и, самое главное, в описание каждой из виртуальной машины в ARM template вы можете добавить только один ресурс типа extensions/CustomScriptExtension. А после перезагрузки нам нужно запустить на одном из узлов будущего кластера еще один скрипт, который сформирует кластер. Сделать это в ARM template нельзя – второй скрипт не указывается, и объяснить ARM, что после перезагрузки на машине стартует еще один скрипт и окончания его работы тоже нужно дождаться – тоже не получится… Потому – занимаемся «лайфхакингом». Если нельзя сделать внутри ARM template, это можно сделать в скрипте PowerShell, который запускает развертывание ARM template. Схематически такой скрипт выглядит следующим образом:

  1. Запускаем команду PowerShell на развертывание ARM – New-AzResourceGroupDeployment с указанием файла «большого» ARM, который развернет всю требуемую инфраструктуру и запустит на требуемых виртуалках скрипт конфигурации машины (выше);
  2. А теперь «хак» – для каждой из виртуальных машин, где уже был выполнен скрипт, запускаем команду по удалению расширения, что позволит выполнить еще одно развертывание ARM со вторым скриптом, который и сконфигурирует кластер – Remove-AzAMCustomScriptExtention . Единственное НО тут – это то, что данная команда для каждой из ВМ выполняется достаточно долго – 3-5 минут.
  3. Снова запускаем New-AzResourceGroupDeployment – на этот раз для развертывания второго шаблона ARM, в котором для каждой второй виртуальной машины (одной из пары узлов кластера) выполняется другой скрипт, как extensions/CustomScriptExtension.

Четвертое – для работы кластера требуется кворум, который для нашего варианта в Azure реализуется с использованием Cloud Witness. Для этого требуется создать Azure BLOB Storage, получить Access Key этого хранилища и использовать ключ для конфигурирования кворума кластера в режиме Cloud Witness. Потому в логике скрипта выше появляется еще один пункт 2а, где после создания инфраструктуры и сервисов (в том числе и хранилища для Cloud Witness) и удаления первых расширений, мы получаем ключи доступа для созданных хранилищ и на следующем шаге передаем их как параметр в новый ARM template – и дальше уже внутри ARM они будут переданы в вызываемый через extensions/CustomScriptExtension скрипт PowerShell для создания непосредственно кластера.

Итого, общий код PowerShell скрипта, который будет выполнять развертывание двух ARM template, с переключением extensions/CustomScriptExtension и получением ключей хранилища:

# deploy basic infrastructure from main ARM template (defined in $templateFilePath)

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -Mode Incremental -TemplateFile $templateFilePath -TemplateParameterObject $Params | Out-Null

# delete CustomScriptExtension from deployed VMs (names should be defined in $deployedVMs array)

foreach($vmname in $deployedvms){

Remove-AZVMCustomScriptExtension -ResourceGroupName $ResourceGroupName -VMName $vmname -Name “CustomScriptExtension” -Force | Out-Null

}

# get storage account’s key for Cluster quorum Cloud Witness and set values in $Params object for next ARM deployment

$keys = Get-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -Name $Params[‘storagename1’]

$Params[‘key1’] = $keys[0].Value

# deploy second CustomScriptExtension (build the cluster) from second ARM template (defined in $templateFilePath2)

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -Mode Incremental -TemplateFile $templateFilePath2 -TemplateParameterObject $Params | Out-Null

Теперь дело за малым – за созданием кластера.

Сам код вызова extensions/CustomScriptExtension во втором ARM template выглядит аналогично первой части (второй скрипт тоже не забудьте поместить в правильный контейнер, как и в первом случае), единственно – в параметрах скрипта передается 2 имени узлов будущего кластера и другие его параметры:

“resources”: [

        {

“type”: “Microsoft.Compute/virtualMachines/extensions”,

“name”: “[concat(parameters(‘vmName2av1′),’/customscript’)]”,

“apiVersion”: “2015-06-15”,

“location”: “[parameters(‘location’)]”,

“properties”: {

“publisher”: “Microsoft.Compute”,

“type”: “CustomScriptExtension”,

“typeHandlerVersion”: “1.4”,

“settings”: {

“fileUris”: [

https://mystorage.blob.core.windows.net/CL/setupCluster.ps1&#8221;

                    ],

“commandToExecute”: “[concat(‘powershell -ExecutionPolicy Unrestricted -File setupCluster.ps1 -domainname ‘, parameters(‘domainname’), ‘ -biosname ‘, parameters(‘netbiosname’), ‘ -adminname ‘, parameters(‘adminUsername’), ‘ -adminpwd ‘, parameters(‘adminPassword’), ‘ -vmnames \”‘, parameters(‘vmname1av1′),’,’,parameters(‘vmname2av1’),’\” -clustername ‘, parameters(‘availabilitysetname1’), ‘ -clusterip ‘, variables(‘cluster1’), ‘ -storageaccount ‘, parameters(‘storagename1’), ‘ -storageacckey ‘, parameters(‘key1’))]”

                }

            }

        }

]

Пятое – чтобы развернуть кластер, скрипт должен выполняться с правами администратора домена, а вот CustomScriptExtension исполняет скрипт с правами ОС внутри виртуальной машины. Но скрипт PowerShell нельзя имперсонализировать в самом скрипте, но, как вариант, можно выполнить команду с правами администратора на удаленном компьютере через Invoke-Command. Т.е. запускаем скрипт через ARM template, передаем логин/пароль админа в скрипт, который создает идентити админа и вызывает команду через Invoke-Command с правами администратора.

Шестое – Windows Failover Cluster НЕЛЬЗЯ развернуть удаленно через Invoke-Command даже с правами администратора. НО, можно сконфигурировать удаленное исполнение команд Invoke-Command через аутентификацию CredSSP, которую предварительно надо настроить на обоих узлах с использованием пары перекрестных команд Enable-WSManCredSSP:

  • Для каждого из узлов включаем режим сервера Enable-WSManCredSSP Server -Force
  • Для каждого из узлов включаем доверие Enable-WSManCredSSP Client -DelegateComputer <имя второго узла> -Force

После конфигурации CredSSP для каждого узла появляется возможность использования Invoke-Command для создания кластера.

Таким образом второй скрипт PowerShell, который создает кластер, будет выглядеть следующим образом:

[CmdletBinding()]

param (

    [Parameter()]

    [string]

$domainname,

    [string]

$biosname,

    [string]

$adminname,

    [string]

$adminpwd,

    [string]

$vmnames,

    [string]

$clustername,

    [string]

$clusterip,

    [string]

$storageaccount,

    [string]

$storageacckey

)

# create domain admin credential’s object

$adminusername = “$biosname\$adminname”

$password = ConvertTo-SecureString -String $adminpwd -AsPlainText -Force

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $adminusername, $password

#get nodes name from parameter string like “node1,node2”

$nodesArr = $vmnames -split “,”

$n1 = $nodesArr[0]

$n2 = $nodesArr[1]

#enable CredSSP authentication for admin impersonation by remote calls

#set both nodes as CredSSP’s servers

Invoke-Command $nodesArr -Credential $cred {Enable-WSManCredSSP Server -Force}

#set current node CredSSP’s client that trusts other node

Enable-WSManCredSSP Client -DelegateComputer $n1 -Force

#set other node CredSSP’s client that trusts current node

Invoke-Command $n1 -Credential $cred {Enable-WSManCredSSP Client -DelegateComputer $Using:n2 -Force}

Start-Sleep -Seconds 5

# create cluster as domain admin with one node by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {New-Cluster -Name $Using:clustername -Node $Using:n1 -NoStorage -AdministrativeAccessPoint ActiveDirectoryAndDns -StaticAddress $Using:clusterip -Force} -Authentication Credssp

Start-Sleep -Seconds 30

Invoke-Command $n1 -Credential $cred {Get-Cluster $Using:clustername} -Authentication Credssp

Start-Sleep -Seconds 5

# add second node to the cluster as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Get-Cluster -Name $Using:clustername | Add-ClusterNode -Name $Using:n2 -NoStorage} -Authentication Credssp

Start-Sleep -Seconds 30

Invoke-Command $n1 -Credential $cred {Get-Cluster $Using:clustername} -Authentication Credssp

Start-Sleep -Seconds 5

# configure cluster’s Storage Spaces Direct as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Enable-ClusterStorageSpacesDirect -Confirm:$false} -Authentication Credssp

Start-Sleep -Seconds 30

# configure cluster’s cloud witness as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Get-Cluster -Name $Using:clustername | Set-ClusterQuorum -CloudWitness -AccountName $Using:storageaccount -AccessKey $Using:storageacckey} -Authentication Credssp

Start-Sleep -Seconds 5

# configure cluster’s cloud witness as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Get-StoragePool S2D* | New-Volume -FriendlyName Data -FileSystem CSVFS_ReFS -UseMaximumSize} -Authentication Credssp

Вот и все готово… Получилось, как я уже писал выше – куда более лаконично, нежели нагромождение кода DSC у Microsoft (который и обвалился в результате), более понятно и читаемо (хотя да, есть некоторые «странности», но это опять таки – вопросы к МС с его Invoke-Command и ограничениями для extensions/CustomScriptExtension) и, главное – оно работает, в отличие от «элитарного» кода Microsoft.

Сейчас держим про запас 2 набора файлов IaC для наших заказчиков с кластерами в Azure – один с «классическим» и нерабочим сейчас кодом Microsoft для создания кластеров через ARM/DSC – в надежде, что Microsoft таки читает запросы на разрешение проблем и хоть как-то сопровождает свой код, и второй – вот данный момент рабочий и приведенный выше.

Я уже писал про компетенцию и поддержку своих продуктов со стороны Microsoft – этот случай из той же оперы, причем тут Microsoft явно забил на свой публично опубликованный код (типа, а вот сопровождать не обещали). Так что, как сказано в предисловии к посту – верить никому нельзя и мы таки попытались выправить то, что Microsoft сделал кривым.

И да, если Microsoft не в состоянии поддерживать документацию, код и вообще – оказывать качественный саппорт – может, им стоит прислушаться к тому совету, который мне написали в комментариях к предыдущему моему посту (хотя Microsoft пошел простым путем – находит тех, кто делает это бесплатно за непонятные и совершенно эфимерные плюшки статуса MVP, который еще и довольно таки “подозрителен”, как я уже писал ранее):

Игорь, привет. По поводу твоего свежего поста – совет: предложить им сделать аналог Bug Bounty/Marketplace: за чужой хороший код и документацию платить премии.

Друге посты и видео по теме Azure и ИТ-карьеры: