Larkin About in Azure

As discussed in my post about AKS planning there are a couple of choices for what device you use in conjunction with your Azure Kubernetes Service (AKS) ingress controller. The default scenario is you deploy a Azure Load Balancer and then you install your ingress controller of choice. The ingress controller then works in unison with the Load balancer.  Another option now available it the Application Gateway Ingress Controller (AGIC) this ingress controller allows you to use the Azure Application Gateway Layer 7 device to expose your services to the internet. As you add services to your cluster it automatically updates the Azure Application gateway.  For information on how to implement AGIC checkout the links on this page  . In this article we are going to discuss AGIC and some of the practicalities of working with this configuration. Managed Identities To use AGIC you need to use AAD pod identity. We configure a managed identity with permissions to manage and update the Applicati

If you are using the Microsoft Terraform task to deploy resources you may currently be seeing issues.  You will be impacted if you have not pinned the Terraform version using the  Terraform installer  task for your own Agent or the Azure DevOps hosted agents. The Azure DevOps hosted agents are starting to use version 0.15 of Terraform,  Hashicorp made a change to the way Terraform works as per this article; https://www.terraform.io/upgrade-guides/0-15.html#azure-backend-removed-arguments They removed the prefix `arm_` the old names were previously deprecated but have been removed in Terraform v0.15.  This was done a while ago but the task has not been updated to accommodate the new values Old                                           New arm_client_id                      client_id arm_client_secret             client_secret arm_subscription_id         subscription_id arm_tenant_id                     tenant_id You may be seeing issues like this in your pipeline; The Azure DevOps task

When creating an AKS cluster it can be easy to get started with quick start templates for ARM and Terraform available.  This is fine for a lab environment but when it comes to building a production ready AKS cluster there are some decisions you need to make at the beginning to save yourself unnecessary pain further down the line.  In this article we will explore some of the key decisions areas which I hope will help you in deploying your AKS cluster. Cluster Node SKUs You have to have a default node pool, you can add additional node pools at a later point which can have different skus but if you want to change the sku on the default node pool it would cause the cluster to be rebuilt. Plan what size SKU size is sensible for your workload.  You can scale out easily but you can not scale-up easily so it is worth getting this right.  We cover adding additional node pools below, this can help get around changing the default node pool. Load Balancer SKU and Multiple Node Pools When you come

In this blog I will be exploring the use of Azure Manged Identities in Azure Kubernetes Service (AKS).  We will then discuss how we can use managed identities according to security best practice. We will look at how we configure the managed identities for the AKS cluster so it can in turn manage other Azure resources.  We will explore how we can configure managed identities for our services/applications that are running on AKS so pods can reach out to other Azure services. Managed Identities Why are we using managed identities? The alternative is to use Service Principal accounts (SPNs). The issues with SPNs is you have a client secret which you have to manage and keep secure. Your cluster apps and services will need to access the SPNs you have created so this means potentially saving it in a few places so it is available to CI/CD pipelines. The secret attached to an SPN rotates so you need to ensure it is valid to ensure your cluster and services continue to run. Managed identi

Introduction I find I am working with  Azure Kubernetes Service (AKS) more and more recently and I thought I would share a few tips and snippets of code I have found useful. For reasons I will explain shortly I have started using the Windows Subsystem for Linux (WSL) as my main way of managing AKS.  If you are starting out with AKS I hope you will find some of these hints and tips useful. AKS is a fully managed Kubernetes service from Azure, if you want to find out more about AKS check out the material and video from Microsoft here  .  For the purpose of this document I am assuming you are familiar with AKS and have at least started to play around with it.   Commands There are some key commands you will need when working with AKS and kubectl you can find some of these on the first link below.  While working with AKS you will  be using other tools like Docker for creating and managing your container images.,  I have provided some key starter commands for this on the second link. Helm

Moving from a traditional Operations Role to a Cloud/DevOps Engineer Role If you are in an infrastructure or operations role and want to make the move to a new role perhaps Cloud/DevOps engineer or an SRE role ,  maybe your company is making changes which means your role is evolving then this article may help to identify some of the skills you need to make this move.   As you read about some of these tools and skills you need to learn you will see many that you may feel fit with a developer role not a operations engineer but keep reading and embrace the code.  Start Small Version Control Cloud Platform Infrastructure as code  CI/CD Pipelines Code Editing   Find a Buddy Embrace new tools Conclusion It is worth noting that you have a lots of valuable and important knowledge you will bring with you to any new role. All the areas we cared about before, as shown in the operabilty diagram below, we still care about now, you may be managing similar solutions and some new ones just with som