Hacker News Reader

Comment by ciguy | Hacker News Reader

If you are having issues with multiple concurrent state reads you should definitely consider splitting your project into smaller discrete modules. I see a lot of projects where an entire AWS account is managed by Terraform using a single state file. This is insanity in my opinion.

It does simplify architecture in a way because everything can be referenced directly in the same projet, but you quickly run ito collaboration issues and runtimes get really long. Use logical states for each discrete piece of a service/module and have those output the needed config/info. Then reference those outputs from other states/modules.

This is the only way I've seen to really scale a TF project effectively. It's not perfect but it's workable even for large teams.

View on HN

If you split you get the issue that you can't reference other resources easily.

Collaboration should be a non issue, the few people who manage the infrastructure should agree on the work and plan together.

Unlike software code that can be merged later at no risk (a merge conflict at worst), infrastructure does not lend itself to improvising and experimenting on the fly (try to accidentally change your VPC or delete your databases and see how the company goes).

Terraform is something that really highlights when there are multiple people/groups in organization trying to steer the ship in a different direction.

In my opinion ansible/salt do a much better job for often changed resources like instances or services, because it doesn't need to maintain states, it can lookup and match existing resources (mostly by tags). Terraform is better for fixed resources like VPC/networking.

You can reference external resources by name and not bring the resource into Terraform domain (or manage by different Terraform project). I have not had a problem running multiple Terraform projects and sharing a few resources (e.g. SQL database)

> If you split you get the issue that you can't reference other resources easily

You can it's just non-obvious. What you do is output identifiers in one module and then import that state file as a data resource in another.

It is really frustrating that this isn't obvious. One of the best features of terraform hidden by poor/unreliable practices and "getting started" guides.

You can very easily reference resources by using an AWS data source (gets resource info directly from the AWS APIs) or using a terraform remote state data source (gets info from the relevant terraform state file outputs).

Another way is to use a KV store, like AWS SSM Parameter Store or consul. This is useful to link your infra to your CI/CD or even directly to your application

There are multiple ways to reference other resources including by state or as a data source. But Hashicorp/Terraform don't do a good job of making this clear.

We do have multiple discreet modules indeed (each with its statefile), but multiple devs can still work on one at the same time.

I think separating configurations is important, however it also comes with downsides (which, again, don't detract from the value of separation), making it necessary to use remote states and data sources, in order to reference resources in other configurations.

Yes there is no magic solution and all approaches have downsides. I tend to lean towards the side of more separation at the cost of increased reference complexity.

Reply on news.ycombinator.com