Infrastructure as code and configuration as code both fall into the category of configuration management, and both relate to defining or scripting for environments.

Infrastructure as code is more specifically defined as:

Defining your environments to include networks, servers, and other compute resources as a text file (script or definition) that is checked into version control and used as the base source for creating or updating those environments. For instance, adding a new server should be done by editing a text file and running the release pipeline, not by remoting into the environment and spinning one up manually.

When designing scripts or definitions for infrastructure as code, it’s important to make sure that the code and tools are set up to be idempotent, or able to run multiple times without error and with consistency.

Infrastructure as code may also be set up with help from developers since many tools offer code to be written in familiar programming languages, even as simple as JSON definitions.

Some examples of tools for working with Infrastructure as Code are: Vagrant, Ansible, Puppet, Chef, Docker, PowerShell DSC, and cloud-provided tools such as Azure Resource Management (ARM) templates.

In this blog post, we’ll learn how to use Microosft Azure, ARM Templates, Visual Studio and Git for doing Infrastructure as a Code where:

1. Microsoft Azure is used to host infrastructure resources
2. ARM Templates are used to define resources configuration
3. Visual Studio 2017 is used to write ARM templates
4. Git is used as SCM (Source code management tool)

Visual Studio 2017 comes with its own git version. So you do not need to install git separately. We’ll be using all of these to first define a virtual network with a single subnet in Azure. Then commit our changes to the source code repository. After that, we’ll modify configuration to re-define the subnet range for subnet1 and create another subnet in the same vnet. Again, committing our changes to the source code.

The set of tools to be used as in above combination is not necessary and you can form a combination of your choice as long as it fits the requirement.

First, open Visual Studio 2017 and create a new project. We need to select Project type as Azure Resource Group. If it’s not coming for you, make sure that you have installed Azure SDK for Visual Studio on your machine. For our purposes, let’s name the project as ManageSubnets01:

Do note to check the box for ‘Create a new Git repository’ while creating the project. Next, we need to select the template type. Let’s start with a blank template and then click OK:

Next select azuredeploy.json file from the solution explorer. This is where we need to define the configuration for azure app service. Select resources and then click add new resource type as virtual network:

This will add bunch of configuration to the JSON file. Let’s edit the JSON file and modify the template to be as below:

By default, it will add two subnets. We have removed the configuration for second subnet. Now, let’s go ahead and add this project to source control by right clicking project name -> source control. Since Visual Studio 2017 by default uses git repository type for SCM, our project will use a git type of repository. Let’s commit the changes made till now by right clicking project -> source control -> commit and providing appropriate description.

At this point, we have created first version of ARM template or first version of network configuration.

Let’s deploy the network by right clicking project name and select deploy and then selecting new:

It will ask a bunch of details wrt Azure subscription, resource group name etc.. You’ll need to provide values wrt your configuration and then click deploy:

Once template is deployed successfully, we can see the network configuration in Azure portal as:

Now, let’s say that we identified later that network range we used for subnet01 is incorrect and we also need to add another subnet to our virtual network say subnet02. Again, we’ll first need to modify ARM template to re-define network configuration. For this, we’ll add a couple of variables:

Do note that we have modified value for the first subnet as well so as to incorporate that requirement.

And also modify subnet configuration:

Once its done, we need to commit our changes. For this, right click project name, select source control and then click commit:

Specify the changes description and then click commit all:

We have now successfully created a second version of ARM template or in other words, second version of network configuration. We can see the history of commits as well:

which can later be used to identify environment drifts. Any commit can further be analyzed to show all changes.

Again, we need to deploy our changes to the Azure. For this right click project -> deploy -> select previous deployment name:

Again provide appropriate values wrt your Azure subscription and click ok. Once the template deployment is complete, we can now see the vnet and subnet configuration in Azure Portal:

So we have created two versions of network configuration. We have also commit history to show who made what changes in the network configuration. We now also have the possibility of reverting to a previous configuration or re-enforcing current configuration by deploying that version of network confiugration.