Skip to content

Automation regret: I scripted myself out of understanding my own stack

General Discussion by HeadRich 24 replies 5.4K views
#1

Deployed Terraform modules for a client on GreenCloudVPS six months ago. Now they're failing and I can't debug without re-learning the module abstraction I built. 64GB RAM on the control node, 128GB on the workload cluster, and I'm googling my own variable names. How much of your stack do you actually understand versus delegate to black boxes?

I can tell you the RAM timings on my home Threadripper but not why this module creates three NAT gateways instead of one.

#2

Yeah I did this with ansible roles from a guy who quit now I just restart the playbook and pray no idea what half the handlers do its all black boxes until it breaks at 2am and youre reading yaml like its hieroglyphics my advice is comment everything but who has time for that terraform plan dont tell you the human reason why something exists only that it will exist

#3

Simple is better.

I still configure nginx by hand. Slower. Deeper.

rm -rf / --no-preserve-root ☯
#4

IMO this is a spectrum, not a binary. YMMV but I keep a "runbook debt" list—every time I use a module I don't fully grasp, I schedule 30 minutes to trace it. Take it with a grain of salt: I still have modules from 2019 I haven't touched. The honest answer is we all operate with some opacity, just try to shrink it.

...
#5

Actually I feel this so much my ex-colleague write beautiful ansible role for postgres, basically I just use `ansible-playbook site.yml` and pray (´・ω・`) then he quit, and now replication break, I have no idea where is `recovery.conf` generated, maybe template? Maybe lineinfile? Actually I search whole repo and cannot find this is basically my life now

But self-host is still better than managed service, right? Right?? (´;ω;`)

instant noodles, instant deploys
#6

Transparency is the only way out of this. We run blameless postmortems on automation failures same as outages—"the module did X" is not root cause, it's symptom. Error budget for your own understanding: if you can't explain a component to a new hire in ten minutes, it consumes budget.

I inherited Terraform from a departed SRE. Took three weeks to map modules to actual resources. Now we require "why not what" comments in every PR. Transparency repeated until it sticks.

4 #7
HeadRich said:
Three NAT gateways instead of one

You're likely hitting GreenCloudVPS's module default for "high_availability = true" which spreads across three availability zones. Check the module's `variables.tf` for `single_nat_gateway`—if undefined, the upstream module may force HA. This is a common pattern in provider modules; the abstraction hides the routing cost and the cross-AZ data transfer you'll pay for.

RPKI for your prefixes won't help if you can't trace which gateway announces which route. Exact terminology matters when debugging. Your Threadripper RAM timings are impressive but irrelevant to asymmetric routing through NAT.

iBGP, eBGP, don't care, just peer
#8

Black boxes until 2am is too real lah, I feel you

#9

Same with my terraform

#10

Which upstream module?

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft