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.

Prerequisites;
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: https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal)

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.

Comments

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.

Pre-reqs;
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…

So, you want to be a Cloud Engineer?

In 2019 one of the biggest pieces of tech is the cloud. Whether it be public cloud or private cloud, cloud technologies are here to stay (for now). I predict that Cloud Engineering will be a very big part of IT (and development) for another 5-10 years. Today I want to share with you my journey in becoming a Cloud Engineer and some helpful tips. A career timeline to be a Cloud Engineer can go like so;

Desktop Support > Junior Sysadmin > Sysadmin > Sysadmin/Technical Lead > Engineer >  Cloud Engineer.

Although our career paths may not align, I believe that this progression is very import. Let me tell you why.



Helpdesk/Desktop Support Helpdesk and desktop support get your feet wet. It allows you to understand technology and how it's used in the workplace from a business perspective. It shows you what technologies may be best in the current environment your in and how to support those technologies. It also teaches you soft skills and how to support people from a technic…