Hello,
I have 3 terraspace project, that have several stacks in them. We separate them because it’s easier in terms of reading, maintenance and concept. But we have some links that need to be updated between each.
Example :
a first terraspace (called tools) create some AWS ECR repositories.
a second terraspace (called foundation) need to know the arn of the repositories.
So I was thinking writing in some local file in the first terraspace and then reading this file in the second one. So I was thinking using resource "local_file"
but I think it will cause two issue
- it will make the “apply plan” confuse with each time some change that are useless
- I think it will be written in the .terraspace-cache that can be potentially erased at any moment.
So do you see any better solution (except merging all terraspace in one big project)? Perhaps adding some ruby code?
thanks
Have you explored the possibility of using Data Sources for the aws_ecr_repository (https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/ecr_repository) within the second project to get the ARN for the repo that was built by the first project? This assumes you have a repo name that can be used to look up that repo resource. Bear in mind, this means that if the ECR repo is not available, the second project’s TF run will fail/error out because it could not find the repo of interest. So you now have solved an issue but created an ‘orchestration’ issue.
Another way that avoids writing local data file is to save the data in some configuration data store (see
https://www.terraform.io/docs/language/state/remote-state-data.html), or the final option is to use terraform_remote_state data source, which the aforementioned article advises to not utilize due to sharing/security concerns. Regardless, all these three options won’t solve the orchestration of projects issue.
Thanks, in my case, the ecr repository was an example.
The idea, is to have as less as possible hardcoded values.
The terraform_remote_state seems to be the way to go, for me.