Home Minecraft server in Azure part 2 - Azure Automation

In the last article, we deployed a maycraft server in Azure using 100% process automation and other various interesting modern DevOps practices. In this article, we will delve even more into Azure IaaS - in particular, we are using Azure Automation in practice to monitor and update server configurations.

Previous deployment scheme

Sources



Before proceeding to the next part - I will answer a couple of questions on the previous

And here DevOps?

The answer is what I described in the previous and this article directly relates to the Technology block of the Gartner DevOps model , namely to Infrastructure as Code , One-Step Deploy and Continuous Monitoring .

')

Why so hard?

The answer is - the articles are purely technical, and so it was originally planned. Basic Azure knowledge is required to read. The meaning of the articles is that in them (more precisely in github ) a working example is implemented, which can be taken as a basis, change the mancraft to <your legacy system> and start building your CD pipelines in Azure.

New Deployment Scheme

What has changed

As you can see from the picture - a new layer Management Tier was added and this is why: in the previous article we made automated deploy (including infrastructure) and this is good. But then we don’t monitor the server configuration in time and this is bad.



You can even come up with another configuration management rule.

You must always be sure that the configuration of the deployed software and infrastructure meets your expectations.

In order to help in the implementation of this requirement, there are such tools as Puppet, Chef, well, and one module in Azure Automation.



In the case of Azure Automation, this works as follows:

1. We load Powershell DSC file to Azure
2. We register VM in Azure Automation, assigning to it the configuration loaded earlier
3. Azure Automation configures VMs and then periodically checks the VMs for its assigned configuration.
4. If the configuration does not match, Azure Automation either reconfigures the VM or notifies you of the mismatch

To realize all this, you need:

1. Create Automation account
2. Download the PowerShell DSC configuration in Azure Automation
3. Load dependent powershell modules into Azure Automation
4. Compile PowerShell DSC configuration
5. Register your Azure Automation VM by assigning it to a previously compiled PowerShell DSC configuration and ApplyAndAutocorrect checkbox

A minor problem is that none of these steps can currently be automated using Azure CLI 2 .



Therefore, the necessary logic will be implemented on powershell and called at the end of rollout.sh

Consider the contents of the powershell script automation_preparation.ps1 details on the steps

First, we log in to azure (we just import the context from the file, for simplicity. We must first save it there - this is done in login_manual.sh ).

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

Create an Automation Account. The “Free” plan is enough.

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

We load the dependencies necessary for our DSC script. Note that ContentLink must reference the nuget package. The module loading operation is not synchronous, but it always runs in a predictable time. Put sleep at the end, just to keep the code free. At work, do not do this )

 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 

We load the DSC configuration (unlike the previous version of the script, we do not need to create a zip with the configuration - just download ps1).

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

We compile the loaded configuration (at this moment it is required to initialize the configuration parameters).



The operation is not synchronous, the waiting time is undefined (apparently due to the Free plan), so there will have to be a cycle.

 $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 } 

Well, then just call the VM registration command in Azure Automation as a DSC Node.

Pay attention to the ConfigurationMode parameter — if it is ApplyAndMonitor — Azure Automation will configure the VM only once, then it will simply report the status (Compliant, NotCompliant) of the actual VM configuration of the described configuration to the 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 

To obtain information on the compliance of the VM configuration with the required one, you can go to the created Automation Account → DSC Nodes.











And of course this is not the only option .

How to debit Powershell DSC

Finally, I will write a few words about the debug of these miracle configurations, maybe someone will save a couple of hours of life)



If the DSC configuration is not configured - you can see the reason.

• Going into the properties of the DSC Extension virtual machine on the portal and reading there is an extract from the logs:
  
  
  
  
• Going to the machine itself and diagnosing the DSC using the Powershell module xDscDiagnostics

How to diagnose a problem with xDscDiagnostics

• Get a list of the last executable get-xDscOperation
• Get the output of a certain Joce Trace-xDscOperation -JobID
• If the information you need is not written in the output, then you need to force configuration via Update-DscConfiguration with the -Verbose flag again and again use xDscDiagnostics to view the logs