Introduction Combining multiple Kubernetes secrets into a single directory can streamline secret management in your applications. This guide walks you through the process of achieving this in Kubernetes, ensuring efficient and organized secret management. Creating Secrets First, create your secrets using the kubectl create secret command: kubectl create secret generic secret-one --from-literal=key1=value1 kubectl create secret generic secret-two --from-literal=key2=value2 Each secret can contain multiple key-value pairs, and you can add more secrets as needed.

Despite being a great language, PowerShell is not impervious to errors. Errors that occur within your code can stop it’s execution or even cause unexpected changes in the resources that your script is managing. Learning to handle these errors gracefully is the foundation of defensive coding. Today, we’ll take a quick look at how PowerShell handles errors with Try-Catch-Finally blocks. They allow you to gracefully handle errors and perform cleanup operations, ensuring that your script doesn’t crash when the unexpected occurs.

This will be a quick and dirty post, so please forgive any spelling/grammar mistakes. I was writing a little CLI tool in Golang to track todo items. Just a dumb little app to help hone my skills a bit, but still something useful that serves a purpose to me. I don’t write a ton of code at work (mostly just scripting/pipelines when I do), so I’m constantly working on something like this in my spare time.

I was recently involved with troubleshooting some API’s hosted in Kubernetes throwing http/502’s. This was incredibly difficult to diagnose because it seemingly happened at random, and I had never encountered anything like this. Being that I had never dealt with this in the past, and I (nor my team) was able to figure it out within a reasonable amount of time, I turned to google. My searches resulted in various blogs and SO posts of other people experiencing similar issues, but none of their resolutions worked for us.

In this article, we’ll take a quick look at chaining two pipelines together in Azure Devops, so that the completion of one pipeline, triggers the other to run. Microsoft documentation is leaps and bounds ahead of where it used to be. However, I still feel like there is a lot of room for improvement, as it took me a while to figure this out. Our two pipelines will exist in the same repository.

If you need to update the secret for a service principal in Azure Devops, prior to it expiring, you may be surprised to find that this cannot be done via the Azure Portal. In this article, I’ll show you two methods for updating a secret for a service principal prior to expiration. Update the secret via the Azure Devops Portal: Go to “Service Connections” in the Azure Devops portal Find the SPN you want to update, then click “Manage Service Principal” Then on the service principal page, click Certificates & Secrets Create a “New Client Secret”, take note of the value Delete the ‘old’ secret Return to the Service Connection in the Azure Devops portal Click Edit - click the verify button.

I have somewhat of a niche issue, where I have no network connectivity while connecting to my work VPN inside of WSL v2. I have found others complaining about this issue on Github. Though no one seems to know how to fix it and I have not had the time to properly investigate. Because of this, I’m required to continue using WSL v1. Though, with WSL v1, Docker does not work.

This post will cover a secure method for accessing secrets in Azure DevOps pipelines. Why Azure Key Vault? Azure Key Vault is an Azure cloud service used to securely store secrets, keys, and certificates. A secret can be any string of characters, such as API keys, passwords, URLs, etc. Azure Key Vault encrypts data at rest and in transit using HTTPS. Depending on the type of Key Vault you are using, data at rest is encrypted using software encryption (AES 256) or HSM-backed keys.

In this article, we will dive into the process of pod eviction in a Kubernetes cluster, how you can pod prevent pod eviction, and how you can recover from such a situation. What is Pod Eviction? Kubernetes pod eviction is a type of involuntary service disruption in which a pod is forcefully stopped on a node or fails to be scheduled on a node. Pod eviction can happen for a variety of reasons.

When deploying new software releases to servers or (insert -as-a-service> here), it’s a good idea to either deploy the releases in a controlled manner or to have a quick rollback plan. This article will be diving into blue/green deployments, canary deployments, ring-based deployments, and feature tag deployments. Blue/Green Deployments Blue/green deployments are a deployment model where a new application version never gets deployed to the production servers (green) directly. Instead, it gets deployed to another set of servers (blue) first.