Skip to main content

Azure ARM Infrastructure as code deployment using VSTS - Part 1

Infrastructure as code , at high level is how you can configure and manage your infrastructure the same way that you would manage your application code .It leverages the concepts of continuous integration and deployment to update or provision your environment based on the changes made to the code. In Azure you can leverage ARM template , which is essentially a json file to implement this concept.

 In this blog series we will explore the concepts of Infrastructure as a code deployment for Azure environments using ARM templates. The  Continuous Integration and Deployment pipeline leverages  VSTS for build and deployment and the source code repository will be Git. The code in this case is the ARM template json file and the related parameter files.  The following blog gives a nice explanation on how to get started with VSTS and integrate  it with the Git repository  :

We will be following an approach for Build and Deployment configuration that provides provide more control over the Release process.The build process will produce an artifact whenever a change is made and committed to the ARM template. The release pipeline will leverage this artifact and deploy it to target environments, which in effect creates/updates your Azure environment.

Let us start with the Build configuration

Build configuration

 Create a new projects and a Build associated with it. Choose the "empty process" option to start with your build

Give a name for the Build and choose agent as hosted.

Add the following tasks in order from  Tasks ->utility

Let's configure these tasks one by one

Copy files configuration:

In this step, the files from the build directory are copied over to a staging directory. The build directory could contain all relevant files required for your deployment, for eg the ARM json and dependent files .

Publishing artifacts configuration:

Here we are publishing the contents of the staging directory as artifacts of the build, which will be used by the release pipeline. Next step is to enable the trigger for continuous integration. Once the trigger is enabled, a build will start as soon as a code commit is made to the repository

Our build configuration is completed now and the required contents for deployment, ie the json file and the dependent  files are produced as artifacts of the build configuration. If you make any edit in the source files and commit it, the build will be triggered. On successful completion of the build, you can see the artifacts in VSTS. In the build status page, select Artifacts. You can also start creating the release by clicking on the release option in the top pane

We will explore the release process to implement continuous deployment in part 2 of this blog...

PS: If you are interested in Cloud automation, please do check out my book on  Azure Automation available in Amazon :


Post a Comment

Popular posts from this blog

Windows server 2012: where is my start button??

If you have been using Windows Server OS for a while, the one thing that will strike you most when you login to a Windows server 2012 is that there is no start button!!.. What??..How am I going to manage it?? Microsoft feels that you really dont need a start button, since you can do almost everything from your server  manager or even remotely from your desktop. After all the initial configurations are done, you could also do away with the GUI and go back to server core option.(In server 2012, there is an option to add and remove GUI). So does that mean, you need to learn to live without a start button. Actually no, the start button is very much there .Lets start looking for it. Option 1: There is "charms" bar on the side of your deskop, where you will find a "start" option. You can use the "Windows +C" shortcut to pop out the charms bar Option 2: There is a hidden "start area"in  the bottom left corner of your desktop

Use Diskpart to make drives online

Issue: In disk management, disk is shown as missing or Offline in Windows Resolution: The disks can be made online by using diskpart utility - Open a command prompt->type diskpart -Inorder to list the disks in the system type: list disk -Note down the number of the disk that you want to make online -Select that disk to operate upon, For eg:, if the disk number is 1, type: Select disk 1 -Now that particular disk will be selected as teh active disk. If you type "list disk" command once more, you can see a * symbol on the left side of the selected disk -Inorder to make the selected disk online type : online disk - If the disk is made online, you will get a message that the operation is completed successfully

Kubernetes best practices in Azure: AKS name space isolation and AAD integration

Once you have decided to run your workloads in AKS service in Azure, there are certain best practices to be followed during design and implementation. In this blog we will discuss two of these recommended practices and the practical aspects of their implementation- Azure AD integration and name space isolation While AAD helps to authenticate users to your AKS cluster using the existing users and groups in your Azure AD, name space isolation provides logical isolation of resources used by them. It is useful in multi tenant scenarios where the same cluster is being used by different teams/departments to run their workloads. It is also useful in running say a dev, test and QA environment for organization in the same cluster. Combining AAD integration with name spaces allow users to login to their namespace using their Azure AD credentials AAD integration with AKS : The following Microsoft document will get you started  with AAD integration of AKS cluster.: https://docs.microsof