11.10.2017 21:51
Dronopotamus 0 1200 Источник
В прошлой статье мы разворачивали майкрафт сервер в Azure с использованием 100% автоматизации процесса и прочих разных интересных современных практик DevOps. В этой статье мы ещё больше углубимся в Azure IaaS — в частности, используем на практике Azure Automation для мониторинга и актуализации конфигурации сервера.

Предыдущая деплоймент схема


image
Исходники

Перед тем как приступать к следующей части — отвечу на пару вопросов по предыдущей
 
Причём тут DevOps?

Отвечаю — то, о чём я рассказывал в предыдущей и этой статье напрямую относится блоку Technology из Gartner DevOps model, а именно к Infrastructure as Code, One-Step Deploy и Continuous Monitoring.
 
Почему так сложно?

Отвечаю — статьи чисто технические и так планировалось изначально. Базовые знания по Azure для прочтения обязательны. Смысл статей в том, что в них (точнее в github) реализуется рабочий пример, который можно брать за основу, менять манкрафт на <вашу legacy систему> и начинать строить свои CD пайплайны в Azure.

Новая деплоймент схема


image

Что поменялось


Как видно из картинки — добавился новый слой Management Tier и вот зачем: в предыдущей статье мы сделали автоматизированный деплой (в т.ч. инфраструктуры) и это хорошо. Но вот дальше мы никак не мониторим конфигурацию сервера во времени и это плохо.

Можно даже придумать ещё одно правило конфигурационного управления
Вы всегда должны быть уверены, что конфигурация развернутого ПО и инфраструктуры соответствует вашим ожиданиям

Для того, чтобы помочь в реализации этого требования, существуют такие тулы как Puppet, Chef, ну и один модуль в Azure Automation.

В случае с Azure Automation работает это следующим образом:

  1. Загружаем Powershell DSC файл в Azure
  2. Регистрируем VM в Azure Automation, назначая ей загруженную ранее конфигурацию
  3. Azure Automation конфигурирует VM, а затем периодически проверяет соответствие VM назначенной ей конфигурации
  4. В случае несовпадении конфигурации, Azure Automation либо переконфигурирует VM, либо уведомляет о несоответствии

Чтобы это всё реализовать, надо:

  1. Создать Automation account
  2. Загрузить PowerShell DSC конфигурацию в Azure Automation
  3. Загрузить зависимые powershell модули в Azure Automation
  4. Скомпилировать PowerShell DSC конфигурацию
  5. Зарегистрировать в Azure Automation VM, назначая ей скомпилированную ранее PowerShell DSC конфигурацию и флажок ApplyAndAutocorrect

Небольшая проблема заключается в том, что ни один из этих шагов на данный момент нельзя автоматизировать с помощью Azure CLI 2.

Поэтому нужная логика будет реализована на powershell и вызываться в конце rollout.sh

Рассмотрим содержимое powershell скрипта automation_preparation.ps1 подробнее по шагам


Сначала мы авторизуемся в azure (просто импортируем контекст из файла, для простоты. Предварительно мы должны его туда сохранить — это делается в login_manual.sh). 

Import-AzureRmContext -Path "$env:HOMEPATH/azureprofile.json"

Создаём Automation Account. Плана «Free» вполне достаточно.

New-AzureRmAutomationAccount -ResourceGroupName $env:GROUP -Name $env:AUTOMATION -Location $env:LOCATION -Plan Free

Загружаем нужные нашему DSC скрипту зависимости. Обратите внимание, что ContentLink должен ссылаться на nuget пакет. Операция загрузки модулей не синхронная, но всегда выполняется за предсказуемое время. Поставил sleep в конце, только чтобы не загромаждать код. На работе так делать не надо )

New-AzureRmAutomationModule -AutomationAccountName $env:AUTOMATION -ResourceGroupName $env:GROUP -Name xNetworking -ContentLink "https://www.powershellgallery.com/api/v2/package/xNetworking/5.1.0.0"
New-AzureRmAutomationModule -AutomationAccountName $env:AUTOMATION -ResourceGroupName $env:GROUP -Name xPSDesiredStateConfiguration -ContentLink "https://www.powershellgallery.com/api/v2/package/xPSDesiredStateConfiguration/7.0.0.0"
New-AzureRmAutomationModule -AutomationAccountName $env:AUTOMATION -ResourceGroupName $env:GROUP -Name xStorage -ContentLink "https://www.powershellgallery.com/api/v2/package/xStorage/3.2.0.0"
Start-Sleep -Seconds 60

Загружаем DSC конфигурацию (в отличии от предыдущей версии скрипта, нам не надо формировать zip с конфигурацией — достаточно загрузить ps1).


Import-AzureRmAutomationDscConfiguration -AutomationAccountName $env:AUTOMATION -ResourceGroupName $env:GROUP -SourcePath "$env:CONFIG_NAME.ps1" -Force -Published

Компилируем загруженную конфигурацию (в этот момент требуется инициализировать параметры конфигурации).

Операция не синхронная, время ожидания неопределено (видимо из-за плана Free), поэтому тут придётся организовать цикл.

$Params = @{"minecraftVersion"="$env:MVERSION";"accountName"="$env:STORAGE_ACCOUNT";"containerName"="$env:STORAGE_CONTAINER";"vmName"="$env:VM_NAME"}
$CompilationJob = Start-AzureRmAutomationDscCompilationJob -AutomationAccountName $env:AUTOMATION -ConfigurationName $env:CONFIG_NAME -Parameters $Params -ResourceGroupName $env:GROUP

while($CompilationJob.EndTime -eq $null -and $CompilationJob.Exception -eq $null)
{
    $CompilationJob = $CompilationJob | Get-AzureRmAutomationDscCompilationJob
    Start-Sleep -Seconds 3
}

Ну а дальше просто вызываем команду регистрации VM в Azure Automation как DSC Node.
Обратите внимание на параметр ConfigurationMode — если он равен ApplyAndMonitor — Azure Automation сконфигурирует VM только один раз, затем будет просто сообщать статус (Compliant, NotCompliant) соответствия фактической конфигурации VM описанной конфигурации в DSC.

Register-AzureRmAutomationDscNode -AzureVMName $env:VM_NAME `
                                    -AzureVMResourceGroup $env:GROUP `
                                    -AzureVMLocation $env:LOCATION `
                                    -ResourceGroupName $env:GROUP -AutomationAccountName $env:AUTOMATION `
                                    -NodeConfigurationName "$env:CONFIG_NAME.$env:VM_NAME" `
                                    -ConfigurationMode ApplyAndAutocorrect `
                                    -ActionAfterReboot ContinueConfiguration `
                                    -RebootNodeIfNeeded $true `
                                    -AllowModuleOverwrite $true

Как всё это запустить из Windows
Нам нужен будет


Запуск процедуры ролаута:

git clone https://github.com/AndreyPoturaev/minecraft-in-azure
cd minecraft-in-azure
git checkout v2.0.0
export MINESERVER_PASSWORD=<place your password here>
export MINESERVER_DNS=<place unique name here. Server url will be $MINESERVER_DNS.westeurope.cloudapp.azure.com>
export MINESERVER_STORAGE_ACCOUNT=<place unique name here>
. login_manual.sh
. rollout.sh


Чтобы получить информацию о соответствии конфигурации VM требуемой можно зайти в созданный Automation Account > DSC Nodes.

image

image

И конечно это не единственный вариант.

Как дебажить Powershell DSC


Напоследок напишу пару слов про дебаг этих чудо конфигураций, возможно кому-нибудь это сэкономит пару часов жизни )

Если DSC конфигурация не конфигурируется — причину можно посмотреть

  • Зайдя в свойства DSC Extension виртуальной машины на портале и почитав там выдержку из логов:

    image
  • Зайдя на саму машину и продиагностировав DSC с помощью Powershell модуля xDscDiagnostics

Как продиагностировать проблему с помощью xDscDiagnostics


  • Получить список последних запускавшихся джоб Get-xDscOperation
  • Получить вывод определённой джобы Trace-xDscOperation -JobID
  • Если в выводе не пишется нужная вам информация — то надо ещё раз форсировать конфигурирование через Update-DscConfiguration с флагом -Verbose и опять с помощью xDscDiagnostics посмотреть логи

Комментарии (0)