Preventing Perpetual Diffs with Nested Blocks in Terraform Resources

 We may run into a situation where Terraform shows changes on every terraform plan, even though we have not changed our Terraform code. As an example, this can happen with nested service_endpoint blocks in an Azure subnet when the order in Terraform is different from the order returned by Azure. Terraform then thinks the resource has changed and shows an update on every plan. In this example, we can see how the problem looks and how changing the order of the blocks can fix the perpetual diff.

Restore Given Index in Elastic Search to a Diffrent Index Name from a Snapshot

 In elastic (cloud or on self hosted in AKS) we can take snapshots of our indices. If we want to restore evrything we can do a full restore for a recovery. However, in a situation where we need to restore a single index into a diffrent name to prevent touching existing live index, but we need to recover some index documents previously was there in a given index (which are deleted as of now), we have the option of restoring a given index by a diffren t name.

Below is an example

Enabling Prometheus Data Scraping for Nginx-Gateway Deployed in - AKS Setup with Managed Prometheus

 We have discussed how to setup Nginx-Gateway instead of Nginx ingress controller in AKS in previous posts listed in the bottom of this post. We have also looked at  "Setup Managed Prometheus for AKS via Terraform" and "Deploying Azure Managed Grafana with Terraform" . For Nginx-Gateway deployed in AKS, we need to enable datascraping so that we can start monitring nginx metrices from managed grafana. Let's look at the steps required.

The expectation is getting metrices ti managed grafana as shown below.

Diagnosing Native Errors in .NET Apps Running in the Linux Containers (exit code 139) in AKS

 We might have to sometimes use native assembiles such Aspose.Slides.NET6.CrossPlatform as for specific needs.

 <PackageReference Include="Aspose.Slides.NET6.CrossPlatform" Version="26.9.0" />

However, when there is a native exception which is not propagating the exceptions to .NET app, but fails due to native errors and restart cotianers with exit code 139. 

Exit code 139 in a Linux container means the process was terminated due to a Segmentation Fault (SIGSEGV). The operating system killed the container because it attempted to access a memory location it wasn't allowed to touch. 

Linux calculates this exit code using the formula 128 + Signal Number. Because SIGSEGV is signal 11, the result is: (128+11=139)