Today’s blog post will showcase how you can leverage the DSC pull feature of Azure Automation when deploying workloads to Azure. To many, the following question will pop up ; “Why use a pull mechanism, whilst I could use the DSC extension to push my configs?”. The answer is pretty simple The pull mechanism facilitates the lifecycle flow of workloads better. You can easily update the config of the virtual machine and do follow-up on the rollout of your configuration.
Now how would such a flow go?
- We’ll use an ARM template to deploy (and afterwards keep) our Azure Automation Account (up-to-date)
- We’ll use a script to import the Powershell modules into our Azure Automation Account, which are needed to compile configurations.
- We’ll use a script to import & compile the DSC configurations into ou Azure Automation Account.
- We’ll use an ARM template to deploy the domain controller.
- This ARM template will also register the VM with the Azure Automation Account and link it with a given DSC configuration.
- The configuration will be applied and the updates will be reported back to the Azure Automation Account.
For this deep-dive demo, I’ll be using the following repositories ;
So you can roll your own demo if you wish… 😉
Deploying the Azure Automation Account (step 1-3)
So let’s start off with our “TasmanianTrader-IaC-AzureAutomationDSC” repository ;
Browse to “AutomationAccount” and deploy the ARM template…
Once the Automation Account has been setup, we’ll start by importing the modules ;
And then we’ll import the configurations ;
That went smooth! Now let’s see how that turned out… Let’s browse to our Automation Account ;
Under “assets” we can see that there are variables, secrets & modules added.
The credential for our domain admin is here…
As the domain name & netbios name for the domain ;
And the DSC modules needed for the configuration were imported and compiled ;
When we browse to configurations, we can see that both our base configurations were imported ;
And that the node configurations were compiled ;
Now go to “Keys” and note down the information to use in the parameter file for our next deployment (the domain controller) ;
Deploy the domain controller (step 4-6)
Now let’s go deploy the domain controller ;
And we can follow the deployment ;
Here we can see that there are two linked templates. One to set a static IP and another to register the VM to the DSC Pull Server from the Azure Automation Account. If we wait a bit… the deployment will finish.
Now we’ll see that the node has been added to the DSC nodes of our Automation Account
And we’ll see that the status is “In progress” ;
Checking in on the deployment
Now we’ll have to be patient… Why? Let’s take a look at the typical registration settings ;
Here you can see that there is a refresh frequency & configuration mode frequency. Basically, we’ll have to wait for 30 minutes to see the node report back to us. This is a bit of a disadvantage that you’ll have to wait a bit for the initial reporting to kick in. Though be aware that the DSC configuration will kick immediately with the node.
Let’s fast forward a bit… We received word back from our DSC configuration. Apparently it’s in a “Not compliant” status.
The great thing is, that we can now drill down on and see what step/phase/action went wrong. Here we can see that the data disk was added and that the active directory domain services were installed.
Though the “xADDomain” isn’t compliant (yet).
Let’s take a sneak peek at our DC. And we can see that the Active Directory Forest/Domain has been setup ;
And the in next reporting round, we can see that the node went to “Compliant”.
Today we looked at how we can set up a DSC pull flow on Azure. The clear advantage of this approach is that you have reporting & central management. My personal experience also shows that it’s something you want for more complex configurations and if you want to manage the system during its entire life-cycle. The DSC extension is very good to get something kickstarted. But, in my humble opinion, you do not want to use this approach during the entire system life cycle.
In a previous post I already talked on how to do domain joins on Azure. I still strongly believe this is something that should be handled by DSC (preferably in an “Apply & Correct”-mode). So one side is from a “compliancy” point-of-view, where you want to be sure the system is domain connected.
On the other hand, I’ve seen many struggle whilst trying to combine a domain join & DSC on various other ways. Trust me on this one, make it easier on yourself and use the xDomainJoin module as a resource in your configuration. That way you can more easily build in the domain join into your dependency hierarchy.