As my first post, I’ve decided to start talking about my current interest, Infrastructure-as-Code as part of my DevOps learning & practise. I’ve delved with JSON files in deploying full environments for either Dev, Test, and Production. An have asked the question:
How do I make AzureRM templates more readable and reusable?
With a little search in the Azure Documentation site, i’ve come across this document: World class ARM templates.
After a bit of reading, a few concepts caught my eye that can help readability and reusability:
- Template linking.
- Dynamic variable generation using concat.
- Fixed configurations v.s. Free-flowing configurations.
I will leave you to do the reading, but by now I hope you know where I’m going with this - Decomposition.
I have here a JSON file, which I used in an old project previously, from the Azure quickstart templates:
Breaking it down
Breaking down the JSON template above, what it does is deploy the following, with all the possible parameters required to deploy the template:
- Azure VNET and Subnets - has also been decomposed into its own JSON file (vnet.json)
- Azure Storage Account
- Azure Load Balancer, front end IP pool, back-end IP pool
- Azure VNIC (x 2) - which has already been nicely decomposed into its own JSON file (nic.json)
- Azure Virtual Machine (x 2) - with DSC configuration files bootstrapped
- Updating the VNETs to include AD DC DNS server IP addresses, once the DSC scripts have completed
As you can see, the template above is a whopping 700+ LoC, and unless you have VS2015 fired up with that fancy JSON explorer, understanding the template is gonna take alot of time and coffee.
After digesting the World-class ARM templates document, I’ve set my approach on working to decompose that HUGE JSON file.
- Decompose shared resources like VNETs, Subnets, Load Balancers, Availability Sets - calling it sharedresources.json
- Take the fixed configuration approach for VM provisioning - calling it vmfactory.json
- This is where we define the “t-shirt sizes” as suggested by the document, and will be calling them “vmRoles” instead
- As a “factory” this JSON file is meant to be re-used over and over again, across different requirements. Wonder if AzureRM will allow “importing” of variables from an external JSON file?
- We will be using the concept of “dynamic variable generation” here, as it has to churn out different configs depending on the parameters passed
- Take optional items like DSC configuration scripts as optional items - haven’t decided on what to call it yet.
As of writing of this blog post, I have successfully done items 1 and 2, and will detail the approach and some code snippets on Parts 2, 3, etc.. You can take a look at the progress of stuff i’ve committed to github as a VS2015 solution. Will be reorganising my repos soon - apologies for the mess of a repo I have!
Stay posted for further blog updates!!