VorlonJS - A Journey to DevOps: Infrastructure as Code with Microsoft Azure and Resource Manager

Article
01/27/2016

If you have any question about this blog post series or DevOps, feel free to contact me directly on Twitter : https://twitter.com/jcorioland .

This post is part of the series “VorlonJS – A Journey to DevOps”

What is Infrastructure as Code?

Infrastructure as Code helps to improve the way you are managing and creating the different environments where an application is deployed all along its lifecycle, from development environment to production. It allows to script, in a declarative way, the final state that you want for your environment.

Consider that you are deploying an application that should run on a web farm composed by 4 servers, that stores and retrieves data from an SQL Azure database and use the Redis Cache service to optimize the loading time. Infrastructure as code will allow you to create the script that will create the whole environment in an idempotent way in order to be sure that even if the script runs more than one time, the final result will be the expected one.

Another important thing is that because you describe your infrastructure in a script, it is possible to version it. So, the source code repository become a common tool for Dev and Ops teams, in order to improve the way in which they work together. By versioning infrastructure scripts in a source code repository, you are able to restore a given version of an application and its environment at any time, to resolve a bug, for example.

Infrastructure as Code and Microsoft Azure

It is very easy to do Infrastructure as Code on Microsoft Azure, using Azure Resource Manager and deployment templates!

What is Azure Resource Manager and what are Resource Groups?

Azure Resource Manager (ARM) is – like suggested by its name – a service that allows to manage all the resources that you can create in Azure. ARM was not implemented in the first version of Microsoft Azure, and one of the big difficulty was that when you created services for a given application, they were all created as a singleton, without links between them or dependencies. It was really difficult to manage application that were composed of a lot of resources.

ARM works with resources providers. Each resource provider, like Microsoft.Compute, Microsoft.Storage, Microsoft.Network (etc…) is responsible for the creation of the underlying resource and all providers are orchestrated by ARM.

All services have not been migrated to ARM yet, but a lot of them are. Some are duplicated. For example, the Azure portal allows to create Virtual Machine using the classic provider or using the new one that works with ARM. If you have to create a new infrastructure now, it’s recommended to use the new ARM providers, if they are available.

With ARM, all resources are going to be created within a Resource Group, that is a logical entity that is used to group resources in Microsoft Azure. There are a lot of new cool features that come with resource groups, like tagging or being able to get billing information for a whole set of resources that represent an application and not for each service one by one.

In fact, when deploying new resource using ARM, you should create a resource group first or select an existing one, in which the resource will be create. Of course, resources within a resource group may be deployed on different data center.

Another good point to encourage the use of ARM instead of older providers is that you can describe a resource group using JSON files (see below) and ARM can deploy resources in parallel instead of sequentially, so it is much faster!

In the case of Vorlon.JS, the deployment folder contains some scripts used to deploy the infrastructure we need for Development, pre-Production and Production environments. In fact, we are using the same script for the Development and pre-Production (azuredeploy.json) but different parameters file that allows to customize each resource for each environment:

For the production environment, we have a different deployment templates, because we are using other functionalities of Azure Web Apps (deployment slots) which are not used in the two others environments.

The Deployment folder also contains some PowerShell scripts that will be used in the Release Management workflow, discussed in a next post.

For more about Azure Resource Manager and Resource Groups, see https://azure.microsoft.com/en-us/documentation/articles/resource-group-overview.

Getting started with Azure Resource Manager and Resource Groups

I know that the ARM templates in Vorlon.JSare not digest and easy to read, but you have to know that working with ARM is super easy, true story !

First, there are a lot of quick start templates available on this GitHub repository. You can read them, modify them and even try to deploy them by clicking on the “Deploy to Azure” button in the readme of each sample. You will be redirected to the Azure portal and will just have to complete the parameters and click OK to launch a deployment.

Visual Studio and the last version of the Microsoft Azure SDK/Tools allows to work with Azure Resource Manager templates, using a UI!

First, you need to create a new “Azure Resource Group” project in Visual Studio:

A wizard helps you to design your resource group. For example, you can choose to create a resource group that is composed by a Web App and an SQL Azure database:

Visual Studio will generate the following solution:

The Scripts folder contains a PowerShell script that you can use to deploy the resource group in Azure.

The Templates folder contains two JSON files: The Azure Resource Manager template that describes the infrastructure and a parameters file that contains the different parameters required by the script. The second one can be duplicated for different environments, for example.

The Tools folder contains the AzCopy.exe executable, that is the Azure version of robot copy, if you need to upload content in Azure (like an application package or a database backup) during the deployment.

If you open the ARM template, the JSON Outline side window should open:

This window helps you to navigate within the template: as soon as you select a resource in the list, its JSON representation will be highlighted in the file.

It also allows to add resources in the template. Right click on the resources node and click Add New Resource:

The wizard opens again and you can choose between a lot of resources the one you want to add in your template:

As you can see, if the resource you want to create depends on other resources, you will be prompted to create these resources too!

Once your template is ready, you can deploy it to Microsoft Azure. Just right click on the project and choose to do a new deployment:

Enter your Azure credentials, the name of the resource group and choose the subscription in which the group will be created.

Another way is to open the PowerShell script in the Scripts folder and run it:

In the case of Vorlon.JS we defined templates that will be used to release the application automatically using VSTS. You can browse these templates directly on GitHub: https://github.com/MicrosoftDX/Vorlonjs/tree/dev/DeploymentTools

Storing infrastructure as code template with the source code of the application is a good practice: it allows to version the application with its depending infrastructure. Imagine that a user reports a bug with an old version, by having infrastructure templates with the code source, you can check out the buggy version, restore the environment in a few minutes and start to debug!

You are now familiar with Infrastructure as Code on Microsoft Azure! In the next post of this series, you will see how we use Azure Resource Manager templates and VSTS Release Management to automatically provision environments and deploy the application, as soon as a build is successfully completed.

Stay tuned!