I was recently a guest on New Relic‘s Developer Relations team podcast “Observy McObservface” with Jonan Scheffler.
Jonan Scheffler and I talk about Microsoft’s Azure Kubernetes Service (AKS), Linux on Azure, how Microsoft’s been successful at working in enterprise and open source, where I believe GitOps & Kubernetes is eventually going to go, and my excitement in regards to AI and blockchain as well as how they’re going to impact the world. You can listen to the podcast and read the article links below.
I will be speaking on Azure Arc enabled Kubernetes and GitOps. My session is titled: “Push Code, Not Containers with Azure Arc enabled Kubernetes and GitOps“. The description is:
Use Azure Arc enabled Kubernetes to manage Kubernetes clusters across Google Cloud Platform and Azure without running a single Kubectl command! In this session, Steve Buchanan will take you into the world of GitOps. He will show you how to deploy applications and configuration to GKE clusters and AKS clusters from a GitHub repository. Explore how we can use this new operating model for Kubernetes and cloud-native apps to declaratively describe and ensure the state of our applications and Kubernetes environments.
After 6 books with many authors from Packt, APress, & Sams/Pearson I finally had the chance to author a book with O’Reilly. This is an ebook so it can be found and read on the O’Reilly online platform.
It is a great platform that I use personally for my own learning. On their platform, you can find ebooks, books across many publishers (most of my books are on there), video training, and even live training.
This book brings together 4 exciting technologies/topics including Azure, Kubernetes, GitOps, and multi-cloud. The book is shorter than my typical books since it is an ebook. It is only 35 pages and is designed for fast & easy consumption to get an overview of the technology and get an early start.
In this book, we take a journey into one of Microsoft’s newest cloud services Azure Arc enabled Kubernetes (Arc K8s). We explore what Azure Arc K8s is, how it extends the Azure control plane to Kubernetes clusters to manage, secure, and govern them, as well as how GitOps sits are the core of application deployment to Kubernetes clusters and a driver of consistent configuration management for Kubernetes clusters.
Azure Arc is a Microsoft product that promises to extend the Azure control plane for Kubernetes across multiple clouds and on-premises, but how does it do this? In this ebook we will dissect Azure Arc K8s and how it becomes a secret weapon for managing Kubernetes clusters across on-premises, multiple clouds, and regardless of your own rolled Kubernetes clusters or managed services based Kubernetes clusters such as GKE, EKS, etc. I also want to give a shout-out to Michael Levan for reviewing this ebook!
Key Areas from the ebook include:
-Understand the new management challenges that multicloud brings -Learn how Azure Arc drives consistent governance, security, and management across multicloud -Gain valuable insights into Microsoft’s Azure ARM control plane for Kubernetes -Learn how Azure Arc manages Kubernetes clusters across on-premises and multiple cloud deployments -Explore the GitOps technology pattern and operating model for cloud native applications and Kubernetes -Use Azure Arc-enabled Kubernetes and GitOps to deploy configurations and applications to Kubernetes clusters
On this new episode, we had a chance to talk about a variety of topics like leveling up your career, what I have been up to, diversity and inclusion in the tech, of course Azure, Azure Arc, DevOps, Kubernetes, GitOps, we even touched on SAP on Azure, among other insights.
You can listen to the podcast episode 106 right here on my blog:
There is another wave coming. This wave is GitOps. GitOps is a technology pattern and operational framework. It is often used for Kubernetes however is really for cloud-native applications in general. Being that a large amount of cloud-native applications these days are designed and built to run on Kubernetes it is no surprise that GitOps is commonly adopted in Kubernetes environments. If you are running Kubernetes or looking at it chances are you may have heard of GitOps. This is how I define GitOps:
“GitOps is an operating model pattern for cloud native applications storing application & declarative infrastructure code in Git as the source of truth used for automated continuous delivery.”
Well, that sums up with GitOps is but it still is a mouthful and can take a bit to wrap ones head around it. In a nutshell GitOps is shifting everything to code, storing everything in Git, making Git the source of truth, and using an operator deploy what is described in Git in your environment including the application and the configuration. With GitOps you describe the desired state of your entire system and GitOps makes it so. It simplifies operations and makes the experience for developers much better allowing them to work out of a tool they are familiar with (Git). Here is a basic sample diagram to give you a visual idea about what GitOps is and how it works:
So in the case of Kubernetes you would have your app code in Git, your container images in Git, and your Kubernetes manifest files. Now there is more to it and how it works but we will not get into all of that in this blog post. This is a good Segway to purpose of this blog post.
The purpose of this blog post is that I just dropped my 7th Pluralsight course GitOps: The Big Picture! This was a fun course to build as I am passionate about and like working with Containers, Kubernetes, and cloud.
A quick shoutout to both Fellow Microsoft MVP/Pluralsight Author Tim Warner and Jason Alba for amplifying my new course!
This course teaches the fundamentals of GitOps, the need for GitOps, GitOps architecture, GitOps workflow, GitOps principles, practices, & tooling such as Flux, Argo CD, AND Jenkins X. Also in this course, GitOps: The Big Picture, you’ll learn what it takes to adopt GitOps. First, you’ll explore what GitOps is and its benefits. Next, you’ll discover GitOps Tooling NS Architecture. Finally, you’ll learn how to use GitOps Workflows. When you’re finished with this course, you’ll have the skills & knowledge of the GitOps framework needed to take the next steps with GitOps.
In the course I give a couple of demos so you can see GitOps in action. The first demo is on “deploying an application using Argo CD” and the second demo is on “GitOps in Action with Azure Arc Enabled Kubernetes using Flux”. Another interesting fact about GitOps is we are starting to see the major cloud providers bring GitOps into their offerings such as Azure Arc and or couple GitOps with their services like with GCP GKE as well as create content on using GitOps with their managed Kubernetes services like with AWS EKS.
GitOps is going to continue to grow right along with the continued growth of Containers, Kubernetes, and Cloud. I am all in and you will see blogs, books, courses, speaking at events, and more from me around GitOps as I continue on my personal journey with it.
Be sure to follow my profile on Pluralsight so you will be notified as I release new courses! I will be releasing more courses soon on topics around Azure, GitOps, SAP on Azure, & Kubernetes courses soon!
Here is the link to the Ignite home page myignite.microsoft.com. I hope to see you on the digital Ignite event and in one of the Ask the Expert Sessions!
Being a part of several Ask the Expert sessions was really fun! My most memorable session was the Ask the Expert: Linux and PowerShell on Azure session.
This session was packed full of superstars from Microsoft product groups and fellow MVPs including; Jeffery Snover, Jason Helmick, Janaka Rangama, and Alexander Nikolić. Here is a screenshot from the session:
After the session, I tweeted about the session and shared some wisdom about PowerShell, and both Jeffery Snover and Jason Helmick retweet my tweet!
2020 is not all bad. It’s pretty cool when the inventor of PowerShell and the PowerShell Program Manager retweet you!
Microsoft has been making some amazing enhancements to AKS and in the open-source space in general. This effort has been making it easier to use Kubernetes and easier for folks who are getting started with Kubernetes.
Recently Microsoft has added more functionally called “Kubernetes resource view“.
This allows you to see and work with some Kubernetes resources directly in the Azure portal. As you can see in the previous screenshot it includes Namespaces, Workloads, and Services. When you deploy a new AKS cluster this is enabled by default.
If you have deployed an AKS cluster before this functionality was release you will need to enable the Kubernetes resource view. You can choose what namespace to enable this on. It will look like this:
The three main areas of resources are:
Services and ingresses
In these resource areas, you can view the resources, add, delete, and show labels.
You can click on a resource to see the properties of it under Overview. The overview tab has valuable information for example for a pod you can see the pod status, the containers that belong to it, its conditions, and more. Here are some screenshots:
You can see any events around the resource and you can even view or edit the resources Yaml. Here is what it looks like when editing a resource:
Well, this was a quick blog post to give an early look at the new Kubernetes resource view in AKS. I recommend you check out it! Remember this is a preview and it’s going to get better and better.
I can imagine in the future we will be able to access more Kubernetes resources and API Objects in the Azure portal. For example, it will be cool to be able to work with Secrets, and Configmaps right in the Azure portal! I don’t know about you, but I am very excited about what Microsoft has been doing with AKS!
When working with
Containers a common need is to store Container images somewhere. Container
Registries are the go-to for this. Docker hub is an example of a Container
Registry and it is the most well-known Container Registry.
What is a Container Registry?
A Container Registry is a group of repositories used to store container images. A container repository is used to manage, pull or push container images. A Container Registry does more than a repository in that it has API paths, tasks, scanning for vulnerabilities, digital signature of images, access control rules and more.
Container registries can be public or private. For example, a public registry is Docker Hub and anyone can access its container repositories to pull images. A private registry is one that you would host either on-premises or on a cloud provider. All of the major cloud providers including Azure has a Container Registry offering.
Integrate ACR with AKS
With AKS it is a good idea to use a private container registry to host your container images. The process is used Docker to build your image>push the image to your Azure Container Registry>Pull the image from the registry when deploying a Pod to your AKS cluster.
There are 3 ways to
integrate AKS with Azure Container Registry. I typically only use one way and
will focus on that in this blog post.
2 of the ways you can integrate AKS with Azure Container Registry. The first is through an Azure AD service principal name (SPN) that assigns the AcrPull role to the SPN. More on this here. You would use this first way in scenarios where you only have one ACR and this will be the default place to pull images from.
The second is to create a Kubernetes ServiceAccount that would be used to pull images when deploying pods. With this you would add “kind: ServiceAccount” to your Kubernetes cluster and it would use the ACR credentials. Then in your pods yaml files you would need to specify the service account for example “serviceAccountName: ExampleServiceAccountName”.
The way I like to integrate AKS with Azure Container Registry is to use Kubernetes Secret of type docker-registry. With this option basically, you create a secret in the Kubernetes cluster for your Azure Container Registry. You then specify the secret in your pod yaml files. This allows you to have multiple container registries to pull from. This option is also quick and easy to setup. Ok.
To get started you need to build your Docker image and push it up to your Azure Container Registry. In this blog post, I will not cover deploying ACR, or building the Docker image assuming you have already done these things. Now let’s set up the ACR and AKS integration using a docker-registry Kubernetes secret.
1. For the first step, you will need the credentials to your Azure Container Registry. To get this go navigate to:
2. The second step push your Docker image up to your ACR.
# Log into the Azure Container Registry
docker login ACRNAMEHERE.azurecr.io -u ACRUSERNAMEHERE -p PASSWORDHERE
# Tag the docker image with ACR
docker tag DOCKERIMAGENAMEHERE ACRNAMEHERE.azurecr.io/DOCKERIMAGENAMEHERE:v1
# Push the image to ACR
docker push ACRNAMEHERE.azurecr.io/DOCKERIMAGENAMEHERE:v1
3. The third step create the docker-registry Kubernetes secret by running following syntax from Azure Cloud Shell:
In Kubernetes, you have a container or containers running as a pod. In front of the pods, you have something known as a service. Services are simply an abstraction that defines a logical set of pods and how to access them. As pods move around the service that defines the pods it is bound to keeps track of what nodes the pods are running on. For external access to services, there is typically an Ingress controller that allows access from outside of the Kubernetes cluster to a service. An ingress defines the rules for inbound connections.
Microsoft has had an
Application Gateway Ingress Controller for Azure Kubernetes Service AKS in
public preview for some time and recently released for GA. The Application
Gateway Ingress Controller (AGIC) monitors the Kubernetes cluster for ingress
resources and makes changes to the specified Application Gateway to allow
This allows you to leverage the Application Gateway service in Azure as the entry into your AKS cluster. In addition to utilizing the Application Gateway standard set of functionality, the AGIC uses the Application Gateway Web Application Firewall (WAF). In fact, that is the only version of the Application Gateway that is supported by the AGIC. The great thing about this is that you can put Application Gateways WAF protection in front of your applications that are running on AKS.
This blog post is not a detailed deep dive into AGIC. To learn more about AGIC visit this link: https://azure.github.io/application-gateway-kubernetes-ingress. In this blog post, I want to share a script I built that deploys the AGIC. There are many steps to deploying the AGIC and I figured this is something folks will need to deploy over and over so it makes sense to make it a little easier to do. You won’t have to worry about creating a managed identity, getting various id’s, downloading and updating YAML files, or installing helm charts. Also, this script will be useful if you are not familiar with sed and helm commands. It combines PowerShell, AZ CLI, sed, and helm code. I have already used this script about 10 times myself to deploy the AGIC and boy has it saved me time. I thought it would be useful to someone out there and wanted to share it.
I typically deploy RBAC enabled AKS clusters so this script is set up to work with an RBAC enabled AKS cluster. If you are deploying AGIC for a non-RBAC AKS cluster be sure to view the notes in the script and adjust a couple of lines of code to make it non-RBAC ready. Also note this AGIC script is focused on brownfield deployments so before running the script there are some components you should already have deployed. These components are:
VNet and 2 Subnets (one for your AKS cluster and one for the App Gateway)
The script will
deploy and do the following:
Deploys the AAD Pod Identity.
Creates the Managed Identity used by the AAD Pod Identity.
Gives the Managed Identity Contributor access to Application Gateway.
Gives the Managed Identity Reader access to the resource group that hosts the Application Gateway.
Downloads and renames the sample-helm-config.yaml file to helm-agic-config.yaml.
Updates the helm-agic-config.yaml with environment variables and sets RBAC enabled to true using Sed.
Adds the Application Gateway ingress helm chart repo and updates the repo on your AKS cluster.
Installs the AGIC pod using a helm chart and environment variables in the helm-agic-config.yaml file.
Now let’s take a look at running the script. It is recommended to upload to and run this script from Azure Cloud shell (PowerShell). Run:
You will be prompted
for the following as shown in the screenshot:
Enter the name of the Azure Subscription you want to use.:
Enter the name of the Resource Group that contains the AKS Cluster.:
Enter the name of the AKS Cluster you want to use.:
Enter the name of the new Managed Identity.:
Here is a screenshot
of what you will see while the script runs.
That’s it. You don’t have to do anything else except entering values at the beginning of running the script. To verify your new AGIC pod is running you can check a couple of things. First, run:
kubectl get pods
Note the name of my
AGIC pod is appgw-ingress-azure-6cc9846c47-f7tqn.
Your pod name will be different.
Now you can check
the logs of the AGIC pod by running:
kubectl logs appgw-ingress-azure-6cc9846c47-f7tqn
You should not have
any errors but if you do they will show in the log. If everything ran fine the
output log should look similar to:
After its all said and done you will have a running Application Gateway Ingress Controller that is connected to the Application Gateway and ready for new ingresses.
This script does not deploy any ingress into your AKS cluster. That will need to be done in addition to this script as you need. The following is an example YAML code for an ingress. You can use this to create an ingress for a pod running in your AKS cluster.
At Experts Live Europe 2019 I presented a session titled “Master Azure with VS Code”. This was a fun session with an engaging audience that took to twitter after the session. There was some chatter asking this session was recorded. It was not. I did note that I planned to write a blog post on this topic.
Here is that blog post and it is the first one of 2020 for me! In this post, we are going to dive into how VS code is helpful when working with Azure and many extensions I find useful when working with Azure. This post is not set to be an end-all to using VS Code with Azure but from my experience. Use this post as a starting point or a reference for expanding your use of VS Code with Azure. Also, check out the many other community experts and Microsoft MVPs for their additional knowledge plus tips and tricks on this topic.
VS Code Overview
First off if you are not using VS Code stop reading this right now, go download it and install it then come back to finish reading. 🙂 VS Code is a must-have in your toolbox and it is free! For those that are new to VS Code, it is an open-source – code editor developed by Microsoft that runs on Windows, Linux, and macOS. Here is a shortlist of the many benefits of VS Code:
Has support for hundreds of languages.
Has Integrated Terminal.
Also powerful developer tool with functionality, like IntelliSense code completion and debugging.
Includes syntax highlighting, bracket-matching, auto-indentation, box-selection, snippets, and more.
Integrates with build and scripting tools to perform common tasks making everyday workflows faster.
Has support for Git to work with source control.
Large Extension Marketplace of third-party extensions.
Note that yes, VS
Code is for the “IT Pro”. Not just developers.
Azure Extensions in VS Code
VS Code has a ton of
extensions in general. There are a number of Azure specific extensions and you
can work with Azure directly from VS Code.
If you go to the VS Code Marketplace here: https://marketplace.visualstudio.com/vscode and search on Azure you will see results for many published by Microsoft and many community based extensions for Azure. As of the time of writing this blog post, there are 93. Here is a screenshot showing some of the results:
You can also go
directly to the Azure Tools extension from Microsoft here:
In the rest of this post, I am going to share some key extensions I use with Azure. I will post the marketplace links at the end of each extension I talk about and if it is maintained by community or Microsoft.
Deploy to Azure using VS Code
It is important to
note that not all of the Azure extensions available in VS Code can be used to
deploy to Azure. Some can but most can’t here is a list of the services that
you can deploy to from extensions in VS Code.
Build and manage Azure Functions serverless apps directly in VS Code with the Azure Functions extension.
Azure resources directly in VS Code with the Azure App Service extension.
Deploy your website using a Docker container.
deploy, and update a website using a terminal and the Azure CLI.
deploy, and update a static website on Azure Storage.
NOTE: This list is current at the time of
writing this blog post. This will change over time.
Azure Cloud Shell in VS Code
Cloud Shell is something you should be using with Azure to make your life easier. It is an interactive command-line shell. You are authenticated to your Azure account when you launch it, It typically runs in the browser and is used for managing Azure resources. When you launch it you can choose the shell experience that best for you, either Bash or PowerShell. With VS Code you can launch Cloud Shell directly in VS Code!
Cloud Shell is a part of the Azure
Account extension. Here are some key points on using Cloud Shell with VS
Free (storage consumed has costs.)
Launch Azure Cloud Shell directly in VS
Launch Bash, PowerShell, or Upload.
Works in the Integrated Terminal.
Azure and open-source Tooling in Cloud Shell:
Azure Tools: blobxfer Azure CLI and Azure classic CLI Azure Functions CLI AzCopy Service Fabric CLI Batch Shipyard
You get the following PowerShell modules in Cloud Shell: Azure Modules (Az.Accounts, Az.Compute, Az.Network, Az.Resources, Az.Storage) Azure AD Management (Preview) Exchange Online (In development) MicrosoftPowerBIMgmt SqlServer