DevOps KB Pages

terraform fmt             # Formats Terraform code terraform init            # Initializes the working directory terraform validate terraform plan -var-file="xx.tfvars"   # Plans infrastructure changes using a variables file terraform apply -var-file="xx.tfvars"

 https://media.jfrog.com/wp-content/uploads/2021/03/30185137/JFrogCLICheatSheet.pdf

Ansible common /useful commands: ansible --version to change default python version and other config values you need to edit /etc/ansible/ansible.cfg Ansible host list: /etc/ansible/hosts ansible <host_name> -m ping -u '<username>' --ask-pass -b -become-user=root -K # nearly all parameters can be overridden in ansible-playbook # or with command line flags. ansible will read ANSIBLE_CONFIG, # ansible.cfg in the current working directory, .ansible.cfg in # the home directory or /etc/ansible/ansible.cfg, whichever it # finds first

When deploying secure workloads using Azure Container Apps (ACA) , teams often face confusion between User Assigned Managed Identities (UAMI) and App Registrations . While both entities are visible in Azure Active Directory and have similar identifiers (Application ID, Object ID), they serve very different purposes . This confusion can lead to authentication failures when accessing services like Azure App Configuration or Key Vault . A common issue occurs when a container app is configured with a managed identity, but the environment variables or role assignments mistakenly reference an App Registration instead, causing errors like: "No User Assigned or Delegated Managed Identity found for specified ClientId" This article breaks down the difference between UAMI and App Registrations, explains why this issue happens, and outlines the correct approach to resolve it. Symptoms Azure Container App fails to authenticate to Azure App Configuration or other services. Logs...

 When doing one-line executing/debugging in VS code with PowerShell it is useful to keep the Edit active window after pressing F8.  Also, related: https://superuser.com/questions/1770478/when-debugging-is-there-an-option-to-not-focus-terminal-automatically From the Terminal click on the drop-down menu, select Configure Terminal Settings: Experiment with these settings, and you should achieve the necessary results.  

In Kubernetes, the usual pattern for a container that “runs once and exits” is not a Deployment but rather a Job (or a CronJob for scheduled runs). A Deployment is designed to keep a given number of replicas running continuously, restarting pods if they exit. By contrast, a Job is specifically designed for run-to-completion workloads. Here’s why this matters and how you can set it up: Why not a Deployment for “run once, then exit”? Deployments expect long-running pods. If your container exits successfully, the Deployment’s ReplicaSet controller will see that the number of running pods is below the desired replica count (e.g., 1), so it will spin up a new pod. You’ll end up in an endless cycle of your “job” container repeatedly starting and exiting. Deployments do not retain “completed” pods. When a pod in a Deployment terminates, Kubernetes treats it as “unavailable” and immediately attempts to create a new one. The right approach: a Job (or CronJob) Jobs create pods that...

Health: 80% eating, 20% exercising Wealth: 80% habits, 20% math Happiness: 80% purpose, 20% fun Achieving: 80% listening, 20% speaking Talking: 80% listening, 20% speaking Improving: 80% persistence, 20% ideas Learning: 80% understanding, 20% reading Relationships: 80% giving, 20% receiving "Prioritize the 80%, and the rest will fall into place."