Cilas Beltrame

Introduction

Provider versioning in Terraform is a critical aspect of infrastructure management that often gets overlooked until something breaks. The question isn’t whether to pin provider versions, but where and how to pin them effectively. This article explores the two main approaches: pinning at the composition level versus pinning at base/root modules, and provides guidance on when to use each strategy.

Understanding provider versioning strategies

Base/root module pinning

In this approach, you specify provider version constraints directly in your base modules or root configurations:

When proxying requests, it’s crucial to understand the role of the Host header. This header specifies the target server for a request and can be altered by users to access different resources.

The Host Header

The Host header in a request indicates the intended server. For example:

Host: example.com
GET /v1/users

The Host Header in Reverse Proxies

In reverse proxies, the Host header determines the target server. If absent, the proxy uses the original Host header. When redirecting to a different host, ensure the Host header is updated accordingly.

In modern cloud-native environments, implementing GitOps principles effectively requires finding the right balance between team autonomy and system stability. This article explores key patterns and practices that can be applied across different GitOps tools (like ArgoCD, Flux, or Helm) to achieve this balance while maintaining system integrity.

The Core Challenge

When implementing GitOps, organizations often face several fundamental challenges:

1. Security and Stability: Critical infrastructure components require careful management and protection
2. Team Autonomy: Development teams need the ability to make changes without bottlenecks
3. System Reliability: Core services must remain stable and protected from accidental changes
4. Operational Efficiency: Teams should work independently while maintaining system integrity

Repository Structure and Access Control

1. Infrastructure Repository

This repository contains critical infrastructure components that should be managed by the DevOps/SRE team:

The Execute Bit: Different Meanings for Files and Directories

In Linux, the execute permission (x) has different meanings depending on whether it’s applied to a file or a directory:

• For files: The execute bit allows the file to be run as a program or script
• For directories: The execute bit allows you to enter the directory (cd into it) and list its contents

The Danger of chmod -R

Using chmod -R (recursive mode) to modify execute permissions can be risky because it treats both files and directories the same way. For example:

Heve you ever wondered what’s going on behind the scenes when you use > /dev/null to discard output?

The Mystery of /dev/null

First, let’s look at what /dev/null actually is. If you run ls -l /dev/null, you’ll see something like this:

crw-rw-rw- 1 root root 1, 3 Mar 26 18:31 /dev/null

That c at the start? It tells us this is a character device - a special type of file that Linux uses to communicate with device drivers. The numbers 1, 3 are particularly interesting:

Everyone knows that once a pod hits 100% of memory, it will be killed by the OOM killer. But did you know what happens with CPU?

Let’s say you have a pod limited to 100mCPU. What actually happens under the hood?

Understanding CPU Limits in Kubernetes

As per official documentation:

cpu limits are enforced by CPU throttling. When a container approaches its cpu limit, the kernel will restrict access to the CPU corresponding to the container’s limit. Thus, a cpu limit is a hard limit the kernel enforces. Containers may not use more CPU than is specified in their cpu limit.

[Read More]