I’ve been recently involved in creating some DSC configurations and using Azure Automation DSC to host them. However what I wanted was a way to continuously deploy the configurations and have them updated on the servers as they are altered in source control. There are so many moving parts involved in this that I thought I should detail what I have done. I started by defining what I want to happen (or think should happen) and then working the automation around it.
- I create a new configuration or update an existing one
- Something recognises that a new configuration has been created (or updated)
- That configuration is copied to the Azure Automation DSC service and compiled
It seems simple enough but I want the whole process integrated with Visual Studio Team Services – this enables me to break the tasks down into smaller parts but also introduces new layers of complexity.
- I know I can use VSTS to build the configuration file and run tests etc.
- When the build is completed I can use release management in VSTS to deploy and compile the configuration.
- I need to use source control to trigger the build / release process.
Following along? Lets start with the basics – creating a new project in VSTS – I can fill in all the other parts later. I already have a VSTS account so I can just create a new project. Let me prefix this by saying it is my approach and may not be correct 🙂
Created the project…
Initialized the repository and added a readme file…
This will allow me to clone the repository to my local machine – which I’ve done below. The plan is to be able to trigger a build when dev branch is updated, and trigger a release when the master branch is updated but that looks a long way off at the moment. Let’s get some simple stuff out of the way and make sure that the basics work.
First I create a super basic server configuration – no parameters, no configuration data required – so no issues yet.
Couldn’t get much simple than this – it is fairly guaranteed that if my node has a C drive then it can create this one folder.
So let’s work through the steps to get it into an Azure Automation account – I have one created with nothing in it as yet….. That is going to give me a place to host my configurations and compile them.
With that in place – in the most simplest of simple ways I have everything I need to begin deploying my configurations to Azure Automation. Forgoing tests, script analysis and probably a few other requirements in the CI/CD pipeline I can create a simple Build task which simply outputs my configuration.
I only require a single task which outputs a build artifact – this is required for me release later on, I will fix and refine the process later on.
Run my build…..
You can scroll through the output and see what is done – basically it clones my repository to the hosted agent (here is where I can run a build script and maybe some tests) then copies my script to location as a build artifact. At this point I kind of realised that I don’t actually know what a build artifact is or where it goes – I had to play around to work out what it had done. But my build completed and I have a published artifact.
Now I can create a release task – there is a built in task which will allow me to run something inside Azure – I can use that to add and compile my configuration. I’ve created a super basic script to do just that (I had to experiment to find out the directory where the configuration is located – there is probably a better way to do it but…..
I created a basic script which uploads the configuration to my automation account and compile it. I can then call this script in the release task.
The cool thing about the Azure PowerShell script task is that it picked up my subscription details and did all the authorization for me.
Now all that is left to do is to run it…..
Success!! And to verify I can check my automation account.
So there it is – my first compiled DSC configuration in Azure Automation DSC released via VSTS.
It’s a long way from finished – there are some other parts which I will update once complete:-
- Triggering the builds and releases from pull requests
- Ensuring there are no syntax errors in the configuration
- Using configuration data in the compilation – so I can use credentials in my configurations.
- Handle multiple configuration files.