Have you ever wondered why you can’t create some Azure resources using ARM or Bicep, or it’s not present in the Pulumi API, but sometimes you can do it in Terraform, or just not? If you work with Infrastructure as Code, you need to understand the difference between the Control Plane and Data Plane.
These two planes represent two different types of operations in Azure.
Control Plane Most top-level Azure resources fall under the control plane.
Sometimes you need your Kubernetes workloads to interact with the underlying host OS, this can be for many reasons but a few common scenarios include:
Monitoring agents that need to read metrics from the host Tools that need to access the underlying container runtime Access to the host network or storage Amending the configuration on the host Installing additional software or agents on the host For Linux hosts, this is fairly straightforward using a privileged daemonset on these nodes which can then access these host resources, but privileged containers aren’t an option for Windows nodes.
Recently I experienced an odd error with Azure Key Vault, which confused me for a while, so I’m posting it here in case others hit the same problem.
The issue occurred in my case when trying to add a secret using Infrastructure as Code, but I suspect it would occur when manually adding a secret via portal or CLI as well. When attempting to add the new secret, I got the error below:
Azure App Service has supported running containers for a while now, both in standard App Service and in Azure Functions. Setting this up through the UI is pretty straightforward, however, creating the same setup using Infrastructure as code can be a bit tricky. There are several different configuration settings that need to be added that are not always obvious. In this article, we will cover them what these are and when to use them and put them all together in one place.
This week, I discovered that it is possible to use the functions that are in Bicep (and ARM) templates in C# code. Why would you want to do this? Well, for the most part, you wouldn’t. Basic functions like concatenate, split etc., already have equivalents in C# code that would produce the same results. However, I had a specific scenario where it did prove useful.
In my scenario, I needed to generate a unique string identifier for some resource naming.
Back in the mists of time (otherwise known as 2018), I wrote a post called Azure Container Hosting Demystified which looked at the different container hosting options in Azure, what they are and why you might use them. Four years have passed since I wrote that article. Things have moved on a lot, so it’s time for an updated version.
If you have container workloads you want to host in Azure, then there are many different options for doing that, and it can be pretty confusing trying to pick out which one is right for your project.
