Santiago Garcia Arango, DevOps

Code Release: Terraform + GitLab CI for Air-Gapped & Hybrid Infra A couple of days ago I wrote about automating infrastructure in air-gapped datacenters. Today, I’m excited to share that I’ve open-sourced the code behind that work. 🎉 What’s inside Terraform modules for Proxmox VM provisioning (Cloud-Init ready) GitLab CI/CD pipeline for plan/apply, state handling, and inventory generation Ansible integration hooks (Runner-based) for RKE2, HAProxy, MariaDB (Galera) — foundations included Designed for air-gapped on-prem and hybrid (on-prem + cloud) workflows Why this matters In rail/defense/critical infra, full cloud isn’t always an option. This repo shows how to bring Infrastructure as Code discipline to isolated environments without losing consistency or scalability. Get started Repo: https://lnkd.in/d7AAXdaR Start with the README for architecture, backend/state flow, and pipeline stages Includes a sanitized terraform.tfvars. example—use env vars/CI variables for real secrets Security-first I cleaned commit history (tokens/IPs), added scanning, and moved secrets out of code. If you spot anything I can harden further, I’d love feedback. What’s next Helm-based app deployments on RKE2 (ARGO-CD) Monitoring & logging stack (Prometheus/Grafana/Loki) More examples for hybrid (on-prem + AWS) If you’re exploring DevOps for constrained environments, hybrid cloud, or Proxmox + Terraform, I’m happy to connect and collaborate. #Terraform #DevOps #Proxmox #GitLab #Ansible #IaC #AirGapped #HybridCloud #RKE2 #SRE #PlatformEngineering

10

Observability Tip: Don't just monitor the server - monitor the processes that matter! I just finalized a crucial monitoring dashboard in Grafana powered by Prometheus and the Process Exporter. We are tracking four key process groups: - systemd - nginx - grafana - prometheus to get granular insights into their resource usage. What does that data reveal and why is it essential?   1. Number of Processes: The most basic health check. We see that the core systemd group (orange line) has a stable number of tasks (~33), while the application services like Nginx, Grafana, and Prometheus maintain a stable, lower count, indicating healthy operation and availability. 2. Process Disk Write Rate: This shows us the actual disk throughput. The systemd process group is clearly the most active writer, peaking around 400 KB/s. This is crucial for identifying logging- or transaction-heavy components that might be creating an I/O bottleneck. 3. Resident Memory (RSS): The "true" RAM consumption. The systemd group is using the most physical RAM (around 800 MiB), which is expected for the main process manager. Tracking this is key for capacity planning and detecting memory leaks that could lead to OOM errors. 4. Virtual Memory (VSZ): The total memory address space reserved. Here, the systemd process has reserved a massive ~10 GiB address space. This highlights why focusing on RSS (Resident Memory) is so important; the vast VSZ is just a theoretical limit and doesn't represent actual RAM pressure. Moving beyond simple machine-level metrics (CPU, total RAM) to process-level metrics is the only way to truly understand which component is driving the load and to troubleshoot performance issues effectively. If you are running Prometheus, make sure you add the Process Exporter to your stack! Did you ever use the Process Exporter to get more detailed information about specific processes that are running on your system? #Prometheus #Grafana #Monitoring #DevOps #SRE #ProcessExporter #Dashboard #KPI

5

🚦 Can data solve traffic jams? Apache Kafka just might 🤔 💡 HOW? Let’s break it down in 3 simple points: 1️⃣ Every traffic light, camera, and car talking to each other in real time 👉 Imagine a network where traffic signals, sensors, GPS systems, and cameras constantly share live updates. Cameras detect congestion or accidents. Traffic lights auto-adjust based on flow. Navigation apps reroute drivers instantly. 2️⃣ That’s what Apache Kafka makes possible ⚙️ Kafka acts as the city’s data backbone — collecting, processing, and streaming millions of real-time events between systems seamlessly. 3️⃣ A city where data flows faster than traffic jams 🚗 Kafka keeps communication instant and reliable — turning chaos into coordination and keeping cities moving smarter. 🌆 #traffic#BangloreTraffic#Kafka#Solution#Topic#trafficLight

11

🚀 Integration Between AWS and Datadog via CloudFormation I recently implemented a integration between AWS and Datadog, leveraging the power of Infrastructure as Code with CloudFormation. The goal was to centralize application observability, automate agent provisioning, and ensure consistent collection of metrics and logs—without manual intervention. Using the Datadog CloudFormation Resource Provider, it was possible to automatically register AWS accounts, configure the necessary IAM permissions, enable monitoring of services like EC2, Lambda, RDS, and CloudWatch, and also activate log forwarding at scale. 💡 Benefits of this approach: Reduced setup time in new environments Compliance with monitoring policies Scalability across multiple AWS accounts using reusable stacks Instant visibility into metrics and logs in real-time within Datadog This automation brought significant gains in time, security, and standardization for our observability pipeline. 🔧 Stack used: AWS CloudFormation | IAM | Datadog Integration | Lambda | CloudWatch | EC2 | RDS | Logs | S3

5

1 comentario

Static variables are fine—until you need flexibility. Sometimes, you need configurations that adapt to changing hosts, environments, or facts. That’s where dynamic variables shine. Dynamic variables let Ansible: - Pull values from host facts, inventory, or external sources - Adjust behavior based on conditions (like OS type or environment) - Simplify playbooks for multi-environment automation - Keep automation smart and reusable Dynamic variables make your automation flexible without breaking structure. Do you use dynamic variables in your playbooks, or do you rely mostly on static ones? #AnsibleThursday #DevOps #Automation #Ansible #BestPractices

9

🚀 Understanding Port Forwarding in Real Projects Recently, while working in a private subnet inside an AWS VPC, I needed to access SonarQube and Jenkins that were not directly exposed to the internet. Since these tools were in a restricted environment (no public IP), direct access wasn’t possible. That’s where port forwarding came in! 🎯 📌 What is Port Forwarding? Port forwarding is a technique where you map a port on your local machine to a port on a remote server, allowing you to securely access services running in private networks. 💡 How I Used It: Scenario: SonarQube and Jenkins installed in a private subnet of AWS VPC. Solution: Used SSH port forwarding to connect from my local machine to the private instances via a bastion host. This allowed me to open SonarQube in my browser (localhost:9000) and Jenkins (localhost:8080) even though they were in a private network. ✅ Benefits: Secure access without exposing services to the internet. No need for assigning public IPs. Great for debugging, admin tasks, or temporary access. 🔗 Tech stack used: AWS VPC, EC2, Bastion Host, SSH Port Forwarding, SonarQube, Jenkins. #PortForwarding #AWSVPC #PrivateSubnet #BastionHost #CloudComputing #DevOps #SonarQube #Jenkins #AWSTips #CloudSecurity #NetworkEngineering #SSH #InfrastructureAsCode #CloudArchitecture #AWSCommunity

29

4 comentarios

I had an incredible time at #SpringIO in Barcelona sharing my session: "Secure-by-Default Spring Apps: Zero Trust, OAuth2, and Runtime Policies". In modern backend development, we can no longer rely on a "secure" perimeter. We need to prove identity, establish cryptographic trust, and enforce dynamic policies at every single hop. During the talk, we explored the three pillars of a secure-by-default architecture: Identity: Moving beyond simple bearer tokens to defeat token replay vulnerabilities using RFC 8705 (Certificate-Bound Access Tokens). Workload Trust: Implementing SPIFFE/SPIRE for zero-touch mTLS rotation—allowing you to update expiring certificates silently without JVM restarts or downtime. Runtime Policy: Decoupling authorization from application code by using Open Policy Agent (OPA) for Attribute-Based Access Control (ABAC). We also discussed how to use Canary Policies to validate new security rules against live traffic in "Log Only" mode before enforcement, ensuring safe rollouts. Huge thanks to the organizers and everyone who attended! You can find my full slide deck below and check out the rest of the conference sessions here: https://lnkd.in/dvuYepD9 #SpringIO2026 #SpringBoot #ZeroTrust #OAuth2 #CyberSecurity #Java #CloudNative #OPA #SPIFFE #PathVariable

4