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.