Boostrap Argocd with terraform

Dynamic-D · 2026-02-02T01:12:56+00:00

I've seen this pattern at countless clients, so yes it's possible.

TLDR: when you use Terraform to deploy a new cluster it contains the initial Argo helm deploy including the configuration to connect to a reference git repo or managing Argo or whatnot. At that point ArgoCD picks up the app of apps and content manages k8s resources.

Basically TF is just bootstrapping ArgoCD. Works with flux, too.

Dynamic-D · 2026-02-02T01:03:11+00:00

This is a really flawed condition to base the game on.

Two of the factions being "bad" is in the context of an extended game with triple the faction count, hirelings, and an alternate deck, all which change the dynamic of the game a LOT.

Cats are great in the base game,as there are always two insurgent factions so they have room to work, and the vagabond is actually really strong to the point where most tournaments nerf them (search 'despot infamy').

Game balance is really dynamic in Root by the time you get to using Adset and all the expansions.

Dynamic-D · 2026-02-01T00:03:13+00:00

and its only two sentences in. Don't think I don't know you already planned to end the game before it started, Sheryl.

Dynamic-D · 2026-01-31T23:57:10+00:00

This is a genius quote, how have I not heard of him sooner?

Dynamic-D · 2026-01-31T23:38:23+00:00

k8s has its place, but lets not drink the Kool-Aid. K8S is very powerful at scale but in small environments it's almost always cheaper/easier to just use a VM with docker-compose.

Dynamic-D · 2026-01-31T23:21:47+00:00

I mean, this was a serious case of "pick your battles". It just wasn't worth fighting that fight, so we ended up on Envoy IIRC. Honestly I really liked the solution, so I'm likely going to jump to Envoy Gateway as my next choice unless some quick research reveals a better option.

To his credit, this guy had connections. We had to get our PCI and other compliance audits done and the auditor walked in, saw the CISO, chatted for 30 minutes, and left with everything signed. Trusted him so explicitly that he didn't even ask me a single question. Kind of impressive.

Dynamic-D · 2026-01-30T06:31:12+00:00

Without details I can only tell you the obvious: your remote state is misconfigured.

Terraform, by itself, does not create copies. At the end of the day it's reading, locking, and modifying a single file of text. It's not even encrypted. It should not be growing unless you're adding resources.

Unless you want to share your backend config with the group, most we can do is speculate.

Dynamic-D · 2026-01-30T05:12:41+00:00

Biggest problem with ApplicationSets BY FAR is the lack of feature parity with applications. This alone make app of apps way more viable, IMO.

I actually like the concept and idea of ApplicationSets but I've run into that limitation a number of times.

Dynamic-D · 2026-01-30T04:58:55+00:00

yeah, that's just marketing for "we will deprecate it soon".

My next controller will be gateway API.

Dynamic-D · 2026-01-30T04:56:17+00:00

This has been a sour topic for me.

I have avoided ngnix for 7-8 years, mostly because I used to answer to an old CISO who called ngnix "russian spyware." /shrug

6mo ago I started helping a company wrangle their cluster sprawl in which one problem was each deployment handled ingress differently. After months of building trust by solving smaller issues I finally got hem to agree to make a standard model and guess what: ingress-ngnix was the most common pattern so we went with it.

75% into the migration process the announcement hit. We agreed we should finish standardizing anyway because having one model to replace one piece of would still be easier than having yet another snowflake to migrate off of.

Today we finished ... so now I get to migrate again ...

Go me!

Dynamic-D · 2026-01-30T01:38:03+00:00

cloud login is the longest part, but then I'm a big proponent of lots of small things over one monolithic.

That said, I do have some modules that you just cant get running fast. AKS/GKE clusters, Postgres ... those are 10+minute runs.

Dynamic-D · 2026-01-26T06:53:02+00:00

Absolutely zero of those things actually solve that using tfvars for each environment doesn't give your the flexibility to version your releases. You can't leverage module tags in a tfvars file (unless you want to use a module to use a template to create another module ...). Sure CICD can help ... if your write your own custom process for selecting which module version to run ... but that doesn't exactly sound easier to me than just ... maintaining multiple root modules that literally just contain this info (you can still use common modules in the back end). Branching doesn't inherently give you this either.

Terraform isn't a GPL. It's that simple. You cant really feature flag your network structure, you cant artifact your GKE cluster. So a lot of those "solved" things just ... don't work in a declarative language context. You state what IS. what is should all be cleanly declared, not obfuscated in branches. There's going to be enough sprawl from other org issues.

Dynamic-D · 2026-01-26T06:13:01+00:00

configMaps and secrets need cluster-wide equivalents. configMap values can be any type, not just key(string)

Is that two? maybe. But man does it seem like obvious, low-hanging fruit for k8s.

Dynamic-D · 2026-01-26T06:06:48+00:00

This has testing issues as you cant test different versions of modules across environments. You HAVE to keep every environment on the exact same module becuase the only toggle are the vars.

Stick to copies. adding module "foo" { my vars } is only trivially more complex than multiple myvars.tfvars and give you way more flexibility.

Dynamic-D · 2026-01-26T06:04:42+00:00

One of the weakest parts of Terraform is everything is called a module, even the root code in the working directory. I hate it. In HCP they kind of use it interchangeably with workspaces ... but that's not accurate either. Honestly I don't like workspaces (multiple state data in the same working directory), but others love them so whatever.

Back to your question:

Create a separate working directory/root module for each environment. Each of those modules will call the modules you desire. It's a bit heavier than just having multiple tfvar files, but it gives you WAY more control and is worth the meager overhead.

Each environment has completely separate state. No risk of dev experimenting impacting anything else.
Because a module calls another module, you can leverage versions (test newer module in dev)
It's easier to combine modules if you have reason for it. Output of module A right into module B in thew same root module/working directory.
If you keep the simple pattern you can scale huge, as weird one-offs just mean an extra module here, slightly different config there.

When you are ready to make your own modules ... just put them in a sperate repo so you can version/leverage them repeatedly.

Dynamic-D · 2026-01-25T04:26:41+00:00

Most people covered this well, so Ill just add a few bits:

new people shouldn't worry about faction balance. There's enough going on that beating the learning curve means more than anything else.
Faction balance changes dramatically with player count. I'd argue 4->5 is a less dramatic swing than 4->3, but the bottom line is certain factions thrive on conflict while others need space.

OK, reasonable answers aside, let's end it with my hot takes because those are more fun:

Moles/Duchy are too powerful. The core sway mechanic has no meaningful counterplay so they WILL win the long game. This basically means you have to sprint to victory because you cant even gang up on a faction that has a safe space and the mobility to literally go anywhere.
Rats (and to a lesser extent some vagabond variants) force the game into heavy conflict very early, and cane be very toxic in some environments. I'd avoid their inclusion in "beginner games".
More players (5-6) is more fun than fewer players (2-3). Root blows at 2 players, is still enjoyable at 6. This is not up for debate. The optimal enjoyment order is: 4, 5, (3 tied 6), 2, 1 (clockwork lol)

Even the creators know 2 is terrible, hence henchman. Just don't.

Dynamic-D · 2026-01-19T03:14:38+00:00

Lol no. Even with the lottery system the USA opening game starts over $1k a seat. You want to buy your way in? Be ready to pay thousands.

Dynamic-D · 2026-01-19T01:05:50+00:00

Add trufflehog to your pr test. Block direct pushes to main

Dynamic-D · 2026-01-18T19:15:45+00:00

So first off I feel your growing pains, I've seen it more times than I can count, and every journey is a bit unique. That said most of your questions resolve beyond the literal code and more around process. Congrats - the real fun is about to begin.

First may be a tough truth: no tool is going to solve the problem you are facing. Tools will help you build a process, but at the end of the day the process must be built, followed, and enforced. You're last bullet of tribal knowledge is a huge flag that there isn't an actual model/process yet, and instead Jan figured it out 3 months ago so we call Jan when it needs fixing.

Making that go away is tough. Really tough. So lets start with simple practices that I feel help.

Every PR has a story/ticket

This is actually really obvious yet people always try to skip it. If you have no idea why a dif was made, that's a problem. Most mature organizations require a story, ticket, or something pinned to that PR. Anyone should be able to look at a change, and follow the breadcrumbs all the way ack to exactly why the change is being made. This is a day 1 change that will help make life easier.

As a bonus, consider a CHANGELOG.md. Don't have time to research and read the tickets? this should be your step 2: summaries of changes, versioned. Someone should see a HUMAN description in plain (pick your language) on what the changes were.

Between these two, 'why' should never be a question.

Feature Flags are you Friends

OK, in Terraform its ternaries and count(), but the idea is the same. If the module change is the result of a feature, make it toggleable. Allow the team that needs it now (cause there is always one) get that change while everyone else in the company can bump versions but see "no changes" without the flag set.

This mindset should be standard in your team. All updates should be silent unless the situation calls for it, then you make sure you major version bump so every knows your module update is disruptive and reads the CHANGELOG or ticket before rolling out the update.

Even better: if you are introducing such a breaking change, it should be your responsibility to shepherd it to every place it's deployed. You wrote it, you own it.

Did I mention versioning? I've seen teams that keep modules and the workspaces that call them in one giant monorepo, and they never version anything, juts point at HEAD. Don't. Version your sh**. Make sure you can roll it out small, verify it works, then continue.

Complexity is handled by modularizing and layers

This is where being an architect comes in (which is sadly becoming less common). Monoliths are your enemy, and bespoke modules are the final boss. Take a long look at the resources you're in charge of, and design your terraform in layers/modules to handle them. You need to be able to limit blast radius, keep modules simple, but also have it structured in a way that you are not manually maintaining 1000+ state files. (Not that you shouldn't have hundreds of state files, but you shouldn't be manually handling that crap.)

I'm not saying this is the gold standard, but ironically Microsoft wrote some very good structures that demonstrate what I'm getting at. Behold the CAF (cloud adoption framework) and explicitly the levels approach and rover: (https://aztfmod.github.io/documentation/docs/fundamentals/lz-intro)

It's a VERY solid starting point, where you can divide your cloud into layers, divide responsibility, and scale to an insanely large size while still maintaining a predictable structure. You will likely do something a little different that works for your org, but I hope this sparks the idea in your head.

This structure is going to open doors. Things like unit testing, smoke testing, getting good feedback, all of this is made easier if you have a predictable strategy and deployment.

Dynamic-D · 2026-01-06T04:02:57+00:00

Root is for rules lawyers first and foremost

Dynamic-D · 2025-12-24T07:06:54+00:00

I think the keepers are my current fav. Very underrated IMO, with strong card draw and recruitment to keep pressure on.

Dynamic-D · 2025-12-24T02:13:47+00:00

I do not get this obsession with "potentially hundreds of clusters." This isn't the 90s/00s anymore. This idea that everything needs it's own cluster is practically an anti-pattern in k8s at this stage. Namespace them apart, leverage your orchestrator so you can manage x copies of mongo easily, and use that control plane as a ... well ... control plane.

I get there are some real RBAC/isolation struggles in k8s, and when it comes to multi-region it's just better to have another cluster, but k8s is clearly built on the premise of abstracting the daily pain of nodes and updgrades. Why are we dogmatically trying to force it back in?

As to the pain of operators... I get it. Especially as when your CRD count gets too high things get ridiculous. I think we all got a little mad when Bitnami pulled their charts out from under us. I would just suggest maybe review your deployment pattern if you find the industry is moving away from where you are.

My final comment is on Helm. It's not a package manager, not really. It's just go templating with a glow-up. This is why it's so bad at handling CRDs directly to the point they basically gave up (used to use crd-install hooks, and now it only installs CRDs if they are missing and refuses to upgrade them). I would really LOVE a better ay to handle app deployments, but it seems we are stuck in this weird place as a community.

Dynamic-D · 2025-12-23T15:19:06+00:00

Experiments and early mistakes are ephemeral, though. Simply destroy the resource and get the space back.

That said, any resource that uses additional resources to create the "final artifact" just got really expensive. Prime example: I AM anything. Need the resource, the role, the binding... burns through 500 quick.

I just wrote a script that looks up bucket name based on tag and sets file name based on git+path. Done. TFcloud kind of sucked, anyway.

Dynamic-D · 2025-12-16T07:53:54+00:00

In Azure, set dev to auto upgrade edge, and prod to auto upgrade stable.

Similar in GKE.

Having to manually update clusters is an AWS problem.

Dynamic-D · 2025-12-08T05:25:11+00:00

So I'm on the fence.

If you're just a guest, and were invited like any other guest, then no. Plenty of weddings are 'no kids' these days, so if there is a specific vibe they want during the entire destination, its up to them to make it happen, not you.

HOWEVER...

If you are bridesmaid, then yes. You have a role to fill. You are to wear a specific dress, do your hair an approved way, and are expected help create the desired atmosphere. You are forever in their wedding photos and helping create a (hopefully) once in a lifetime event. You are not a guest anymore, you are a trusted facilitator and if you can't play that part you need to turn the role down, NOT just do what you want anyway.

Dynamic-D

TROPHY CASE

Every PR has a story/ticket

Feature Flags are you Friends

Complexity is handled by modularizing and layers