It’s common for cloud directors to make their environments feature-consistent, and which may be achieved in several methods. My choice is to make use of Desired State Configuration (DSC), which is a part of the Azure Automation, and my second choice is to make it possible for your ARM templates and Azure DevOps pipelines implement the required settings. On prime of that, we will at all times use Azure Automation to report any assets not compliant together with your requirements. These days, I’ve been working with a buyer that moved a bunch of servers in a lift-and-shift migration. In this type of situation, the advantages of DevOps will begin to be seen when new VMs are being provisioned within the cloud. Nevertheless, it doesn’t assist present VMs which were operating within the atmosphere for years.
To deal with this situation, we created a script that may consider assets and primarily based on tags, we are going to deploy all the necessities from the enterprise. On this article, we’re protecting two gadgets: diagnostic settings and VM boot diagnostics. Nevertheless, we will use the identical idea and increase to another requirement that you could have in your atmosphere utilizing the same code by simply including a few adjustments.
How the cloud-operation runbook works
When planning automation for any situation, we should put together for exceptions and methods to permit the administrator to handle the answer primarily based on their necessities with out an excessive amount of change on the code stage (runbook). Managing your Azure subscription is not any totally different, and though we may create a runbook that permits diagnostic settings on all of your IaaS (infrastructure-as-a-service) VMs, it will not be sensible. A great instance: It’s possible you’ll wish to have logs for IIS and SQL in a different way than an everyday utility server.
The primary draft of the script that originated this text is comprised of three Azure tags: OperationFlag, which is a string and has two potential values zero or 1, the place zero means off and 1 means on. The second is DiagVersion, which has the model of the present diagnostic settings that we’re making use of to the environment; the third is the DiagWorkload, which we are going to reserve for future use however will enable the script to use a distinct configuration primarily based on the workload.
The OperationFlag is utilized on the Useful resource Group stage, and all assets inside that Useful resource Group will obtain these settings. If an OperationFlag doesn’t exist on the Useful resource Group stage, the script will stamp one with zeros. The OperationFlag may also be used on the useful resource stage, and it’ll override any worth that comes from the Useful resource Group.
The identical logic holds for DiagVersion and DiagWorkload. If they don’t exist on the useful resource stage, they are going to be added utilizing the present model and commonplace worth for the DiagWorkload tag.
Within the situation depicted under, within the first run of the script, just a few actions are anticipated to happen, as follows:
- Each actions are configured to be executed on the Useful resource Group stage (OperationFlag:11).
- The digital machine useful resource could be evaluated, If the 2 actions outlined will not be enabled on the VM, then they might be enabled.
- The load balancer useful resource would obtain DiagVersion and DiagWorkload. The 2 actions could be evaluated, and if the useful resource just isn’t in compliance, the runbook will configure it accordingly.
- The Key Vault useful resource would have the 2 actions disabled as a result of the OperationFlag related on the useful resource stage takes priority.
OperationFlag inside workings
The OperationFlag is the guts of this runbook. The thought behind that is to permit the administrator to outline the actions that may occur on the assets. The primary draft of the script incorporates two actions: The primary one (in inexperienced) configures diagnostic logging for the assets and the second digit (in purple) configures the boot diagnostics settings just for the VM useful resource kind.
Be aware: The diagnostic settings for a VM are totally different than an everyday useful resource (load balancer and Key Vault, to say just a few)
If there’s a configuration that solely applies to a single useful resource kind, then it’s possible you’ll reserve a digit only for that. If it’s a extra generic configuration from Azure perspective (diagnostic settings, which is being represented within the first digit), then the usage of a single digit for all assets is the really useful method.
It’s possible you’ll be questioning: How will the script know that our second digit solely applies to the VM useful resource kind? The best way that we deal with this dilemma is through the use of a JSON file that we name guidelines.commonplace.v1.json (the place v1 is expounded to the model of the file).
This file is the reminiscence of the runbook. The primary part of the file has all international values, comparable to Storage Accounts, workspace ID, the assets being utilized by the script, and so on. After that, we’ve one report for each kind of the useful resource and the cmdlets that ought to be utilized by the runbook to test, deploy and take away the function.
That solutions the query of how we will make it possible for the second digit will probably be used solely in opposition to a digital machine useful resource.
Each digit within the OperationFlag is represented within the guidelines file by S<DigitPosition> (we begin from zero to match all loops inside the script and make it simpler to troubleshoot the code).
One other “feature” of the script is that all the pieces that seems within the cmdlets between <> is a string that the script will change with dynamic values throughout execution time.
Working the Azure diagnostic settings script
Now that we’ve an concept of how the runbook logic was outlined, we will run the runbook and goal a single Useful resource Group or a whole subscription. A easy method to do this is so as to add a -ResourceGroupName change on the Get-AzResource cmdlet (line 218).
The question to search out the assets comes from the guidelines file, and it’ll goal solely assets that had been outlined prior. For each useful resource, the script will consider the OperationFlag outlined vs. the useful resource at the moment configured.
All options that should be both added or eliminated will probably be executed as a part of the script to carry the useful resource again to the identical standing configured by the OperationFlag. The script execution is easy. Simply give a standing for every useful resource that evaluates throughout the execution.
A brand new VM was launched within the RG-MSLAB Useful resource Group, and that Useful resource Group has the next tags related to it. The VM doesn’t have any diagnostic settings and boot diagnostics settings configured earlier than the script execution.
After the execution of the script, the diagnostic settings (picture under) and boot diagnostics had been enabled by the Azure Automation runbook.
The present script and the information to assist it may be discovered on the next GitHub here. The script is a piece in progress. Nevertheless, it offers the cloud administrator a great begin and an choice to deal with some frequent points amongst assets, comparable to Azure diagnostic settings from a central location with a single runbook.
We’re going to have a future article explaining the script itself. For now, the aim is to know the enterprise requirement and the utilization of the Azure diagnostic settings automation script.
Featured picture: Shutterstock