So we’ve talked about Azure Automation DSC and the extensive reporting we can get from it. With the pricing as it is, it would be hard to argue as to why you would want to use anything else. But I’m a completionist, and there may be some edge cases that might come up where you wouldn’t be able to use the pull method for configurations. So let’s talk about how you can use Azure DSC to push a configuration to a virtual machine. So let’s get started! Publish the Configuration In order to push a configuration, we need to publish it to a blob store. When you use Publish-AzureRmVmDscConfiguration, the command bundles all of the required modules along with the configuration into a .zip file. It does this by pulling the modules from your local machine that you’re running the command from, so you’ll need to make sure that you have the appropriate modules installed on your system. First, we’ll go ahead and grab a storage account where these binaries can be published. In the storage account, we have a blob store for our configurations. This blob store is a private store.
Last week we talked about modifying and uploading our configurations to Azure Automation DSC. We were able to import credentials from Azure’s Automation Account Credential store, and then compile the .mof files in the automation account for deployment. This week, we’ll be looking at how we apply those configurations to existing systems via PowerShell. Then we’ll take a look at some of the reporting available via Azure Automation DSC and send those reports over to Operations Management Suite for dashboarding. So when we left off. We successfully published our configurations in Automation DSC. If we run Get-AzureRmAutomationDscNodeConfiguration against the configuration I published, we get the following:
Today we’re going to be talking about adding configurations to your Azure Automation Account. In this article, we’ll be discussing special considerations that we need to take into account when uploading our configurations. Then we’ll talk about compiling the configurations into Managed Object Format (.mof) files, which we’ll be able to use to assign to our systems. Things to Consider When building configurations for Azure DSC (or anything where we are pulling pre-created .mof files from), there are some things that we need to keep in mind. Don’t embed PowerShell scripts in your configurations. - I spent a lot of time cleaning up my own configurations when learning Azure Automation DSC. When configurations are compiled, they’re done so on a virtual machine hidden under the covers and can cause some unexpected behaviours. Some of the issues that I ran into were:
I’ve been wanting to do this series for a while, and with some of the recent changes in Azure Automation DSC, I feel like we can now do a truly complete series. So let’s get started! Compliance is hard as it is. And as companies start moving more workloads into the cloud, they struggle with compliance even more so. Many organizations are moving to Infrastructure-as-a-Service for a multitude of reasons (both good and bad). As these workloads become more numerous, IT departments are struggling with keeping up with auditing and management needs. Desired State Configuration, as we all know, can provide a path to not only configuring your environments as they deploy as new workloads, but can maintain compliancy, and give you rich reporting. Yes. Rich reporting from Desired State Configuration, out of the box. You read it right. You can get rich graphical reporting out of Azure Automation Desired State Configuration out of the box. And you can even use it on-prem! In this series, we’re going to be discussing the push and pull methods for Desired State Configuration in Azure. We’ll be going over some of the ‘gotchas’ that you have to keep in mind while deploying your configurations in the Azure environment. And we’ll be talking about how we can use hybrid workers to manage systems on-prem using the same tools. Push vs. Pull Desired State Configuration, like a datacenter implementation, can be handled via push or pull method. Push method in Azure does not give you reporting, but allows you to deploy your configurations to a new or existing environment. These configurations, and the modules necessary to perform the configuration, are stored in a private blob that you create, and then the Azure Desired State Configuration extension can be assigned that package. It is then downloaded to the target machine, decompressed, modules installed, and the configuration .mof file generated locally on the system. Pull method fully uses the capabilities of the Azure Automation Account for storing modules, configurations, and .mof compilations to deploy to systems. The target DSC nodes are registered and monitored through the Azure Automation Account and reporting is generated and made available through the UI. This reporting can also be forwarded to OMS Log Analytics for dashboarding and alerting purposes (which, as we discussed in my previous series, can be used with Azure Automation Runbooks for auto-remediation). Pros and Cons to Each So let’s talk about some of the upsides and downsides to each method. These may affect your decisions as you architect your DSC solution.
It’s been a long road, but we’re almost there! A couple of weeks ago we looked at how we can create an Azure Automation Account and add our own custom modules to the solution to be used in Azure Automation. Last week, we took a deeper dive into configuring a runbook to take in webhook data from an alert using Microsoft’s Operations Management Suite. Then we looked into the data itself to see how we can leverage it against our runbook to fix problems for us on the fly. This week, we’re going to modify an existing function to use that webhook data directly. Building on Webhook Data We could actually build our logic directly into the runbook to parse the webhook data and then pass the formatted information to our function that we’ve made available in Azure. But I prefer to keep my runbooks as simple as possible and do the heavy lifting in my function. This makes the runbook look a little bit cleaner, and allows me to minimize my code management a little more. Also, Azure Automation Runbooks, as of this writing, don’t play nicely with parameter sets in them, so I might as well pass my data along to a command that does. Originally, I had built a one-liner that allowed me to create an NSG rule on the fly to block and incoming traffic from a specific IPAddress. It was a fairly simple command. But today, we’re going to make it a little more robust, and give it the ability to use webhook data. Here’s my original code:
So last time we learned how to upload our custom modules into Azure Automation so we can start using them in Azure Automation Runbooks. This week we’re going to take a look at configuring a runbook to see what kind of data we can ingest from OMS Webhook data, and how we can leverage that data to pass into our functions. Creating the Runbook Script So first off, let’s talk about basic runbooks and running them against objects in Azure. As previously discussed, when your automation account is created, it creates with it an AzureRunAsAccount. This account is configured to act on behalf of the user that has access to the automation account and the runbooks in order to perform the runbook task. In order to leverage this account, you need to invoke it in the runbook itself. You can actually find an example of this snippet in the AzureAutomationTutorialScript runbook in your automation account.
Microsoft’s Operations Management Suite provides some exceptional tools for monitoring and maintaining your environments in both the cloud and in your datacenter. One of it’s best features, however, is its ability to leverage the tools that you’ve already developed to perform tasks and remediate issues using PowerShell, Azure Automation Runbooks, and OMS Alert triggers. In this series, we’ll be discussing how you can configure these tools to take care of problems in your own environment. Today, we’ll be talking about how you can take your own PowerShell Modules and upload them to Azure Automation. Creating The Azure Automation Account In order to create the Azure Automation Account, you’ll need to have create the automation account object in the target resource group, and the ability to create an AzureRunAs account in AzureAD. It’s also important to be mindful that not every Azure region has the Microsoft.Automation resource provider registered to it, so you’ll want the resource group to exist in the appropriate locale. You can check this with the Get-AzureRmResourceProvider cmdlet:
We’re pleased to announce general availability of our PowerShell Saturday Booster Program, as announced at PowerShell + DevOps Global Summit 2017. The goal of this program is to help enthusiasts build sustainable one-day, small-format technical events worldwide. We can provide organizing advice and assistance, help managing finances, and so on. Full details at https://github.com/devops-collective-inc/powershell-saturday/wiki.
Now that I’m recovered from the 2017 PowerShell and DevOps Global Summit, I just wanted to take a moment and talk about my experiences at the conference. It was my first time attending this conference and it was also my first time speaking. Both “firsts” contributed to a range of emotions throughout the long and exhausting week.
I came in to Seattle late Friday night and expected to go straight to the hotel and to bed. Being from Eastern Daylight Time makes for a long day and late night when your expected hotel arrival time is 10pm local time (or 1AM your time). However, PowerShell friends and community members, some of whom I knew from previous conferences and some of whom I was just meeting for the first time, greeted me. Some stayed up and waited for me to arrive – even with an already-closed hotel bar and many respective time zone differences. They greeted me with an overwhelming sense of community and friendship, and that was a defining moment that I’ll never forget. Even though I was exhausted, I found myself staying up for a couple more hours chatting with folks who were already there.
