Dynamically Adding Virtual Network Rules to Azure Cognitive Account Using Terraform

 To enable access to various Azure resources via given virtual networks and subnets, we have to setup allowd subnets using virtual network rules in Azure resources. For example Azure Cognitive Account can be restricted to access only from given virtual networks and subnets. This requirement of allowed virtual networks and subnets may changed based on the deploying environment such as develop, qa or production. Let's look at how to write a terraform dynamic block to handle such scenarios, using Azure Cognitive Account virtual network rule as example, which can be used in other Azure resources as well.

Full sample code with  Azure Cognitive Account is available here in GitHub.

Store Azure SignalR Connection String as a Secret in Azure Key Vault with Bicep IaC

  We can create Azure SignalR and Azure key vault as resources using Bicpe IaC (Infrastructure as Code). Setting up of SignalR connection string as a Secret in Azure Key Vault via IaC is important, so that it can be used by applications by refering to key vault secret. Let's look at the steps required to store the Azure SignalR connection string as a secret in Azure key vault with Bicep.

Create Key Vault Reference in Azure App Config Service with Bicep IaC

 We have discussed "Store Azure Service Bus Connection String  as a Secret in Azure Key Vault with Bicep IaC" previously. Setting such a secret in Azure App configuration service as a key vault reference will help the applications to access the connection string to Azure service bus via the app config service. This is applicable to setting up reference to any secret in Azure key vault, as Azure key vault reference in Azure app configuration service, via Bicep as Infrastructure as Code (IaC). Let's look at the steps required.

Store Azure Service Bus Connection String as a Secret in Azure Key Vault with Bicep IaC

 We can create Azure Service Bus and Azure key vault as resources using Bicpe IaC (Infrastructure as Code). Setting up of Service Bus connection string as a Secret in Azure Key Vault via IaC is important, so that it can be used by applications by refering to key vault secret. Let's look at the steps required to store the Azure service bus connection string as a secret in Azure key vault with Bicep.

Restart Count Details of Each Pod and Container for App in Grafana Chart with Azure Monitor for AKS

 Pod and container restart counts monitoring are discussed in posts "Pod Restart Counts Grafana Chart with Azure Monitor for AKS" and "Container Restart Counts Grafana Chart with Azure Monitor for AKS". Those two charts show summarized view per service. To view details of pod and container restarts for an individual service we can create another chart as described in this post.

Workaround Solution for Intermittent CrashLoopBackOff in Windows Containers Running on AKS (.NET 6 Apps with System.Net.Sockets.SocketException 11001 and 10060)

Let's look at a temporary solution to the issue Intermittent CrashLoopBackOff in Windows Containers Running on AKS (.NET 6 Apps with System.Net.Sockets.SocketException 11001 and 10060). Same issue is asked in stackoverflow here. Instead of manually deleting pods that run into the issue maually, the cleaner app implemented in this repo is doing autmatic deletion of pods CrashLoopBackOff state with known exception reported in the container log. If the exeception is unknown the pod in CrashLoopBackOff state will not be deleted, and the container log output is printed, in cleaner app logs to show the exception of the pod having CrashLoopBackOff state.

Docker Alpine (mcr.microsoft.com/dotnet/runtime) - Resolve "Microsoft.WindowsAzure.Storage.StorageException: Only the invariant culture is supported in globalization-invariant mode."

.NET app running with mcr.microsoft.com/dotnet/runtime docker alpine images, might run into issue "Microsoft.WindowsAzure.Storage.StorageException: Only the invariant culture is supported in globalization-invariant mode" if your app is requiring globalization. Let's look at what needs to be done to get the issue fixed.

Resolve Windows Docker Build "C:\Program Files\dotnet\sdk\6.0.407\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {7Bxxxxxxxxxxxx} failed due to the following error: 80040154 Class not registered (0x80040154 (REGDB_E_CLASSNOTREG))"

 Building .NET 6 project with Resource files is running into build issue as shown below, when building with .NET 6 nanoserver build images.

C:\Program Files\dotnet\sdk\6.0.407\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: The "GenerateResource" task failed unexpectedly. [C:\src\Demo\Demo.csproj]

C:\Program Files\dotnet\sdk\6.0.407\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {7Bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx} failed due to the following error: 80040154 Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)). [C:\src\Demo\Demo.csproj]

Container Restart Counts Grafana Chart with Azure Monitor for AKS

 We have disucussed pod restart Grafana panel in AKS in the post "Pod Restart Counts Grafana Chart with Azure Monitor for AKS". We can create similar panel for container restarts using managed Grafana in Azure for AKS using Azure monitor.

Expected Outcome

Panel similar to below showing contianer restarts for a applications over time with a table showing last container(s) of application restarts, maximum restarts for each application.

Pod Restart Counts Grafana Chart with Azure Monitor for AKS

 If your pods are often restarting it might indicate a problem you might have in your application deployed to AKS. For example, there was some significant number of restarts seen in .NET 3.1 applications deployed to AKS (reason found as .NET 3.1 issue which is supposedly fixed in .NET 5, so the approach to fix was to update the applications to .NET 6), which were only appearing in development and in staging envronments, while QA environment haven't shown a single restart. Threfore, it is important to monitor the restart counts in pods to identify issues you might not see in development or QA envronements, but may occur in production environments. Let's see how we can create a pod restart count panel in managed Grafana in Azure for AKS using Azure monitor.

Pod Counts Grafana Chart with Azure Monitor for AKS

 We have discussed how to create a Grafana panel for view Horizontal Pod Autoscaler (HPA) desired pod counts in AKS (Azure Kubernetes Services) in the post "Horizontal Pod Autoscaler Desired Replica Count Grafana Chart with Azure Monitor for AKS". As desired count is changing in HPA for an app monitoring how the actual pod count is changing would be really useful insights. Let's look at steps required to implement Grafana chart for actual pod counts over time using Azure monitor fror AKS.

Horizontal Pod Autoscaler Desired Replica Count Grafana Chart with Azure Monitor for AKS

 Horizontal Pod Autoscaler (HPA) in Kubernetes manage the number of instances for each pod deployment based on the scale settings specified. Itw would be good insights to monitor the demand for scaling of each pod. as a prerequicite we need to setup monitoring AKS cluster with Managed Grafana in Azure with Azure Monitor and Log Analytics Workspace.  Let's see how we can create a Grafana pannel to monitor the HPA behaviour over time.

Creating AKS Node Count Grafana Panel with Azure Monitor

 AKS can be setup with automatic node scaling using VM scalesets in node pools. It will be useful to monitor how the nodes are scaling over time to have  a good insights, in to the AKS cluster nodes behaviour, while applications deployed in the cluster getting heavy traffic. We can enable monitoring AKS cluster with Managed Grafana in Azure with Azure Monitor and Log Analytics Workspace.  Let's look at query to setup node count over time panel in Managed Grafana in Azure using Azure Monitor.

Set Value for a Secret Variable in Azure Release Pipelines while Triggering from Another Release

 You might want to trigger a release from another release pipeline, specially if you are deploying to a multi tenant application environment. In such cases when you trigger a pipeline from another pipeline the variables you are setting dynamically cannot be a secret variable. If you set a variable that should be settable at release time as a secret, the release cannot be triggerd via the Azure DevOps REST API call, as it will throw an exception such as below.

The 'secret' property of

variables cannot be altered while creating a release. Verify the value

provided for variables UserPwd at scope Release and try again.  

Let's try to understand bit more of the requirement.