Skip to main content

Deploy Azure Kubernetes Services with an ARM template and Visual Studio

In 2019, Infrastructure As Code (or as some call it, Configuration Management) is gaining massive popularity. We've always had some form of it, in one way or another. In a DevOps-leading technology world, we have two primary responsibilities. Ship the product and automate as much as possible. With that, we need a fast and reliable way to automate infrastructure. Today we're going to automate spinning up an AKS (Azure Kubernetes Services) cluster with ARM templates.

What are ARM templates you may ask? ARM templates are Azure's Infrastructure-As-Code/Configuration Management solution (much like CloudFormation in AWS). ARM is made up of JSON and allow you to spin up pretty much anything you'd like in Azure. It gives you the ability to specify parameters as well so you can pass in args at runtime.

Because ARM is a Microsoft product, it fits in VERY nicely with Visual Studio. Today we're going to use Visual Studio to pull down a generic template and spin up a Kubernetes cluster.

1. Visual Studio (Community Edition works for this and is free)
2. An Azure subscription (either a trial version or a paid version will work just fine)
3. Azure/cloud extensions for Visual Studio
4. A client ID and client secret in Azure (for directions on how to do this, please go to:

First things first, let's go ahead and open up Visual Studio. Once you open up Visual Studio, click on "Continue without code" on the bottom right. Once you do that, you should see a blank Visual Studio screen. Go to File > New > Project.

On the "Create a new project" screen, go to Platform > Cloud > Azure Resource Group. Mine shows up in my recent project templates as I use it frequently.

The next screen you'll see some settings to configure your new project. I'm going to go ahead and leave the location and Framework the default. For the name, I'm going to change it to "AKSDeploy". Feel free to leave the name as the default if you'd like. After that, please click "create"

After you click create, you're going to see a "choose a template" screen. Click on the drop down under "Show templates from this location" and choose the "Azure QuickStart (not the "featured" one). After that, search for "AKS" and you'll see a template called "101-aks". Please choose that template.

After you click "OK", you should see in your Solution Explorer the project contents. We're going to focus on the azuredeploy.json. The azuredeploy.parameters.json is where you can store params to pass in at runtime, which you can also do in the azuredeploy.json

Go ahead and double click on azuredeploy.json. Once you do, you're going to see JSON code. I'd like to focus on two things, the schema and the parameters. The schema, as you'll see, is "deploymentTemplate.json". That's the REST API you're calling for deploying infrastructure to Azure. The parameters are, like all programming languages (sometimes called arguments), what you pass in at runtime and how you want your end state to look like.

Let's take a look at the params we have that we can change;
1. clusterName = What you want your AKS cluster to be called
2. location = What region you want your AKS cluster in
3. dnsPrefix = DNS name for your AKS cluster
4. osDiskSizeGB = How large you want the disks for your AKS cluster
5. agentCount = How many worker nodes you want in your AKS cluster
6. agentVMSize = The type/size you want your AKS cluster VM's to be
7. linuxAdminUsername = The username that you can use to SSH into your VM's running your AKS cluster
8. sshRSAPublicKey = Your pub key for auth when SSH'ing into AKS (or any Linux server in general)
9. servicePrincipalClientId = Client ID used by your cloud provider
10. servicePrincipalClientSecret = Service Principal client secret
11. osType = What OS? Windows or Linux
12. kubernetesVersion = What version of Kubernetes

Scroll down to line 84 in your azuredeploy.json. We see a few version of Kubernetes listed. We're going to go ahead and change that because it's a bit out of date from what Azure currently offers.

Alright, so now that we have our parameters and know what they are, let's take a look at the resources block. The resources block is what you want your environment to look like, which takes in the values of your parameters.

Take a look at the above screenshot. Look familiar? For example, you'll see "osDiskSizeGB": "[parameters('osDiskSizeGB')]" on line 109. That's one of our parameters.

Now that we understand what our ARM template looks like and what it entails, let's go ahead and get ready for a deployment.

In our Solution Explorer, right click your project name and select deploy > new. You should now see a screen that says "Deploy to a Resource Group". If you've never used this in Visual Studio before, you'll have to authenticate with the same account you used to set up your Azure subscription.

Click the arrow under "Resource Group" and choose what Resource Group you want your deployment to be under.

Next, click the "Edit Parameters..." button.

Ahh, what do we have here? Our parameters again! I thought this was extremely neat when I first saw it (hopefully you do too and I'm not the only full on tech geek getting a kick out of this).

Now that we have our parameters up, let's go again and fill them in!

Now that we have our parameters filled in, let's go ahead and click save and then click deploy.

If all goes well, you should see some output in Visual Studio about your params, account info, etc.

If we head over to the Azure portal and click on Kubernetes Services, we will now see our cluster!

Thank you all for reading and I hope you enjoyed this post.


Popular posts from this blog

DevOps tooling in the Microsoft realm

When I really started to dive into automation and practicing DevOps with specific tooling, there were a few key players. At the time Microsoft was not one of them. They were just starting to embrace the open source world, including the art and practice of DevOps. Since then Microsoft has went all in and the tech giant has made some incredible tooling. Recently I switched to a Microsoft-heavy environment and I love it. I went from AWS/Python/Ansible/Jenkins to Azure/PowerShell/ARM/Azure DevOps. My first programming language was PowerShell so being back in the saddle allowed me to do a full circle between all of the different types of tooling in both worlds. Today I want to share some of that tooling with you.

The first thing I want to talk about is ARM. What is ARM? ARM is a configuration management tool that allows you to perform software-defined-infrastructure. Much like Ansible and Terraform, ARM allows you to define what you want your environment to look like at scale. With ARM, yo…

Monitoring your containers in an AKS cluster with Prometheus

Monitoring and alerting is arguably one of the most important thing in Cloud Engineering and DevOps. It's the difference between your clients stack being up and a client being down. Most of us have SLA's to abide by (for good reason). Today we're going to learn how to spin up Prometheus in an AKS cluster to monitor our applications.

1. Intermediate knowledge of Kubernetes
2. An AKS cluster spun up in Azure

Recently AKS supports Prometheus via Helm, so we'll use that for an automated solution to spin this up. This installs kube-prometheus, which is a containerized version of the application. With raw Prometheus, there are a few things that are needed for the operator;

1. Prometheus: Defines a desired deployment.
2. ServiceMonitor: Specifies how groups of services should be monitored
3. Alertmanager: Defines the operator to ensure services and deployments are running by matching the resource

With kube-prometheus, it is all packaged for you. This means configuri…

Run PowerShell code with Ansible on a Windows Host

Ansible is one of the Configuration Manager kings in the game. With it's easy-to-understand syntax and even easier to use modules, Ansible is certainly a go-to when you're picking what Configuration Management you want to use for your organization. Your question may be "but Ansible is typically on Linux and what happens when I'm in a Windows environment?". Luckily I'm here to tell you that Ansible will still work! I was pleasantly surprised with how easy it is to use Ansible on Windows with a little WinRM magic. Let's get started.

Pre-requisites for this post:
1) WinRM set up to connect to your Windows host from Ansible
2) Ansible set up for Windows Remote Management
3) SSH access to the Ansible host
4) Proper firewall rules to allow WinRM (port 5985) access from your Ansible host to your Windows host
5) Hosts file set up in Ansible that has your IP or hostname of your Windows Server.
6) At least one Linux host running Ansible and one Windows Server host …