В прошлой статье мы разворачивали майкрафт сервер в Azure с использованием 100% автоматизации процесса и прочих разных интересных современных практик DevOps. В этой статье мы ещё больше углубимся в Azure IaaS — в частности, используем на практике Azure Automation для мониторинга и актуализации конфигурации сервера.
![image](https://habrastorage.org/r/w780q1/webt/59/de/7c/59de7cecc72c2487775253.jpeg)
Исходники
Перед тем как приступать к следующей части — отвечу на пару вопросов по предыдущей
Отвечаю — то, о чём я рассказывал в предыдущей и этой статье напрямую относится блоку Technology из Gartner DevOps model, а именно к Infrastructure as Code, One-Step Deploy и Continuous Monitoring.
Отвечаю — статьи чисто технические и так планировалось изначально. Базовые знания по Azure для прочтения обязательны. Смысл статей в том, что в них (точнее в github) реализуется рабочий пример, который можно брать за основу, менять манкрафт на <вашу legacy систему> и начинать строить свои CD пайплайны в Azure.
![image](https://habrastorage.org/r/w780q1/webt/59/de/7c/59de7cf07414e397570943.jpeg)
Как видно из картинки — добавился новый слой Management Tier и вот зачем: в предыдущей статье мы сделали автоматизированный деплой (в т.ч. инфраструктуры) и это хорошо. Но вот дальше мы никак не мониторим конфигурацию сервера во времени и это плохо.
Можно даже придумать ещё одно правило конфигурационного управления
Для того, чтобы помочь в реализации этого требования, существуют такие тулы как Puppet, Chef, ну и один модуль в Azure Automation.
В случае с Azure Automation работает это следующим образом:
Чтобы это всё реализовать, надо:
Небольшая проблема заключается в том, что ни один из этих шагов на данный момент нельзя автоматизировать с помощью Azure CLI 2.
Поэтому нужная логика будет реализована на powershell и вызываться в конце rollout.sh
Сначала мы авторизуемся в azure (просто импортируем контекст из файла, для простоты. Предварительно мы должны его туда сохранить — это делается в login_manual.sh).
Создаём Automation Account. Плана «Free» вполне достаточно.
Загружаем нужные нашему DSC скрипту зависимости. Обратите внимание, что ContentLink должен ссылаться на nuget пакет. Операция загрузки модулей не синхронная, но всегда выполняется за предсказуемое время. Поставил sleep в конце, только чтобы не загромаждать код. На работе так делать не надо )
Загружаем DSC конфигурацию (в отличии от предыдущей версии скрипта, нам не надо формировать zip с конфигурацией — достаточно загрузить ps1).
Компилируем загруженную конфигурацию (в этот момент требуется инициализировать параметры конфигурации).
Операция не синхронная, время ожидания неопределено (видимо из-за плана Free), поэтому тут придётся организовать цикл.
Ну а дальше просто вызываем команду регистрации VM в Azure Automation как DSC Node.
Обратите внимание на параметр ConfigurationMode — если он равен ApplyAndMonitor — Azure Automation сконфигурирует VM только один раз, затем будет просто сообщать статус (Compliant, NotCompliant) соответствия фактической конфигурации VM описанной конфигурации в DSC.
Чтобы получить информацию о соответствии конфигурации VM требуемой можно зайти в созданный Automation Account → DSC Nodes.
![image](https://habrastorage.org/r/w780q1/webt/59/de/83/59de83072c193493904797.jpeg)
![image](https://habrastorage.org/r/w780q1/webt/59/de/83/59de83ad2b74f469478634.jpeg)
И конечно это не единственный вариант.
Напоследок напишу пару слов про дебаг этих чудо конфигураций, возможно кому-нибудь это сэкономит пару часов жизни )
Если DSC конфигурация не конфигурируется — причину можно посмотреть
Предыдущая деплоймент схема
![image](https://habrastorage.org/webt/59/de/7c/59de7cecc72c2487775253.jpeg)
Исходники
Перед тем как приступать к следующей части — отвечу на пару вопросов по предыдущей
Причём тут DevOps?
Отвечаю — то, о чём я рассказывал в предыдущей и этой статье напрямую относится блоку Technology из Gartner DevOps model, а именно к Infrastructure as Code, One-Step Deploy и Continuous Monitoring.
Почему так сложно?
Отвечаю — статьи чисто технические и так планировалось изначально. Базовые знания по Azure для прочтения обязательны. Смысл статей в том, что в них (точнее в github) реализуется рабочий пример, который можно брать за основу, менять манкрафт на <вашу legacy систему> и начинать строить свои CD пайплайны в Azure.
Новая деплоймент схема
![image](https://habrastorage.org/webt/59/de/7c/59de7cf07414e397570943.jpeg)
Что поменялось
Как видно из картинки — добавился новый слой Management Tier и вот зачем: в предыдущей статье мы сделали автоматизированный деплой (в т.ч. инфраструктуры) и это хорошо. Но вот дальше мы никак не мониторим конфигурацию сервера во времени и это плохо.
Можно даже придумать ещё одно правило конфигурационного управления
Вы всегда должны быть уверены, что конфигурация развернутого ПО и инфраструктуры соответствует вашим ожиданиям
Для того, чтобы помочь в реализации этого требования, существуют такие тулы как Puppet, Chef, ну и один модуль в Azure Automation.
В случае с Azure Automation работает это следующим образом:
- Загружаем Powershell DSC файл в Azure
- Регистрируем VM в Azure Automation, назначая ей загруженную ранее конфигурацию
- Azure Automation конфигурирует VM, а затем периодически проверяет соответствие VM назначенной ей конфигурации
- В случае несовпадении конфигурации, Azure Automation либо переконфигурирует VM, либо уведомляет о несоответствии
Чтобы это всё реализовать, надо:
- Создать Automation account
- Загрузить PowerShell DSC конфигурацию в Azure Automation
- Загрузить зависимые powershell модули в Azure Automation
- Скомпилировать PowerShell DSC конфигурацию
- Зарегистрировать в 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](https://habrastorage.org/webt/59/de/83/59de83072c193493904797.jpeg)
![image](https://habrastorage.org/webt/59/de/83/59de83ad2b74f469478634.jpeg)
И конечно это не единственный вариант.
Как дебажить Powershell DSC
Напоследок напишу пару слов про дебаг этих чудо конфигураций, возможно кому-нибудь это сэкономит пару часов жизни )
Если DSC конфигурация не конфигурируется — причину можно посмотреть
- Зайдя в свойства DSC Extension виртуальной машины на портале и почитав там выдержку из логов:
- Зайдя на саму машину и продиагностировав DSC с помощью Powershell модуля xDscDiagnostics
Как продиагностировать проблему с помощью xDscDiagnostics
- Получить список последних запускавшихся джоб Get-xDscOperation
- Получить вывод определённой джобы Trace-xDscOperation -JobID
- Если в выводе не пишется нужная вам информация — то надо ещё раз форсировать конфигурирование через Update-DscConfiguration с флагом -Verbose и опять с помощью xDscDiagnostics посмотреть логи