SRE / DevOps Engineering
Reliable infrastructure, kept understandable.
I am Trinidad Marroquin. I work on Kubernetes platforms, cloud infrastructure, vCenter, automation, CI/CD, secrets management, and observability for systems that need to be operated with confidence.
I work on infrastructure that needs to be understandable, repeatable, and boring in production. My focus areas include Kubernetes, cloud platforms, vCenter, Terraform, Rancher, Packer, Vault, CI/CD, Linux systems, and observability.
Focus Areas#
Kubernetes Platforms
Cluster operations, Rancher management, upgrades, access patterns, and production readiness.
Infrastructure As Code
Terraform modules, reviewable plans, environment promotion, and safer operational changes.
Cloud And Virtualization
Cloud platform operations, vCenter administration, VM lifecycle, templates, identity, and network foundations.
Build And Delivery
Packer image pipelines and CI/CD workflows that keep deployments repeatable and debuggable.
Secrets Management
HashiCorp Vault operations, policy design, secrets engines, authentication methods, and operational guardrails.
Observability
Metrics, logs, alerts, dashboards, and incident follow-up focused on useful operating signals.
What This Site Is For#
- Practical notes on SRE and DevOps work.
- Project writeups with constraints, tradeoffs, and operational outcomes.
- Field notes for practical command references, troubleshooting checks, and operational judgment.
- Technical blog posts about Kubernetes, cloud platforms, vCenter, Terraform, Rancher, Packer, Vault, CI/CD, and observability.
- A current resume and professional summary.
VMware guest customization can write /etc/netplan/99-netcfg-vmware.yaml. If the template already has another active netplan file, the host can end up with multiple network authorities.
That can break routing, DNS, bootstrap scripts, Kubernetes node communication, and storage initialization.
Symptoms Common signs:
Error: Conflicting default route declarations for IPv4 first declared in nic0 but also in ens192 or:
Destination Host Unreachable or DNS search drift like:
resolv_conf_search = . netplan_search = [] Inspect Netplan Ownership ls -l /etc/netplan sudo grep -R "routes:\|gateway\|search:" /etc/netplan -n If both a template file and VMware file are present, decide which one owns networking.
...
This project started as a repository cleanup and turned into a clearer operating model for vSphere infrastructure.
The original Terraform repo had grown into a collection of copied root modules. Each site and environment had its own directory with a familiar set of files: main.tf, variables.tf, output.tf, terraform.tfvars, vars.auto.tfvars, vars.env, local state files, and copied templates. That worked while the repo was small, but it made every change harder to review.
...
A Terraform refactor can look like a file organization problem until the first plan, clone, and bootstrap run.
The repo I was working on had the usual signs of age: copied environment roots, local state files, duplicated templates, inconsistent variable files, and old one-off directories that were still sitting beside active infrastructure. The obvious fix was to move toward a cleaner layout:
environments/<site>/<env>/ modules/vsphere-vm-group/ templates/ archive/ That was the right direction. It was also only the beginning.
...
When an existing Terraform resource is moved into a module, Terraform sees a new resource address. If state is not moved first, the plan may try to create the module resource and destroy the old root resource.
Symptom After converting a root resource to a module call, the plan shows addresses like this:
# module.vm_group.vsphere_virtual_machine.vm["lb1"] will be created while the existing state still has:
vsphere_virtual_machine.vm["lb1"] Check Current State Run from the environment root:
...
Part 1 of the DevOps Dirty Dozen Series: Divide et impera — divide and conquer.
Insight: Creating silos fragments unity and purpose.
DevOps was supposed to unite us, but too often, it divides us into silos. Silos isolate teams, stifle communication, and undermine the very principles DevOps was built upon. Why do these silos exist? What makes them so destructive? And how can we tear them down to deliver on DevOps’ promise of collaboration and innovation?
...