Hacker News Reader

Comment by badblock | Hacker News Reader

Some of this seems like old advice, instead of having directories per environment you should be using workspaces to keep your environments consistent so you don't forget to add your new service to prod.

View on HN

(Hi, I’m one of the authors of the article at the root of this thread.)

I’ve gone back and forth on workspaces versus more root modules. On balance, I like having more root modules because I can orient myself just by my working directory instead of both my working directory and workspace. Plus, I feel better about stuffing more dimensions of separation into a directory tree than into workspace names. YMMV.

What do you think about multiple backends? It seems to be working well for me to have a single root module but with a separate backend configuration per environment.

That does work well for environments because typically you’d run exactly the same code, maybe with different cluster sizes or instance types, in each environment. But it doesn’t work well for isolating two services where the code is significantly or even entirely different.

Multiple backends are unwieldy if you're using terraform at the command line, but they beat workspaces handily for discoverability. They're a fine option if you're applying through CI though, as the drudgery of utilizing them is handled effortlessly by the robots.

Do you always store modules in the same repo as the terraform itself?

Why not put them in seperate repos that can be tagged and versioned and then referenced like below?

source = "git::https://bitbucket.org/foocompany/module_name.git?ref=v1.2"

Not who you asked, but there are different kinds of modules. I like versioning for reusable ones, but when it comes to root modules they tend to glue together a couple of those, so I just keep them in the same repo, with some terragrunt to mate them with configuration of combination of environment, region etc.

Reply on news.ycombinator.com