3 ms·
First the main.tf example with my_bucket and my_configs is bad it's using the same resource names. Second I run pretty complex metas (for_each, etc) and have n
by swozey 3y ago
First the main.tf example with my_bucket and my_configs is bad it's using the same resource names.
Second I run pretty complex metas (for_each, etc) and have never encountered an issue..
Third, using a random string as a bucket name? So we're abstracting the bucket name which will just confuse someone who does aws s3 ls, or looks at s3 in the console? If Ops is dealing with an outage related to s3 they have to go in and figure out what (I assume) tag of someones name is attached to what bucket. It's 5am here and my brain is barely churning, I'm trying to figure out how else you would know whose bucket is whose aside from tagging the bucket "dalton."
I could possibly see if you use the SAME ID for the developer for EVERY object and I could go in and say "Oh, 112345123145 is Dalton and his s3 tstate is in the 112345123145 bucket." But you're randomizing all of them.
Then you do random IDs for namespaces as well.. This feels like an ops nightmare.. It's great if you have devs with the same names I guess.
- thwoerasdf 3y agoYou'd examine the state file which holds identity of infrastructure. You can also export S3 bucket names as an output. You should also be using tags to pin ownership.
- isbvhodnvemrwvn 3y agoBut your alerts are on AWS. You take away context from place where it's needed the most.