#terraform (2023-05)
Discussions related to Terraform or Terraform Modules
Archive: https://archive.sweetops.com/terraform/
2023-05-01
2023-05-02
Hi I am looking at how to dynamically create resources in multiple regions but as far as I can see, It is not supported yet by terraform. Has anyone tried any work around as I have over 3000 resources to create across multiple regions?
best option i can think of would be something like cdktf to generate the .tf configs for you
are you creating the same set of resources in many regions? Or put another way, do you have one set of resources which are created repeatedly with only minor differences?
The best approach would be to split up your resources into many stacks. 3000 resources is too many for a single stack and you will suffer much operational pain doing so.
Apologies, I meant 300. Yes I am creating the same resources in many regions. A typical example of what I am trying to do is shown below. I know that we cannot use count or for_each in providers, is there any way I can do this as a work-around
variable "regions" {
default = [
"us-east-1",
"us-east-2",
"us-west-1",
"us-west-2",
"ca-central-1",
"eu-central-1",
"eu-west-1",
"eu-west-2",
"eu-west-3",
"ap-northeast-1",
"ap-northeast-2",
"ap-southeast-1",
"ap-southeast-2",
"ap-south-1",
"sa-east-1"
]
}
provider "aws" {
count = "${length(var.regions)}"
alias = "${element(var.regions, count.index)}"
region = "${element(var.regions, count.index)}"
profile = "defualt"
}
resource "aws_security_group" "http-https" {
count = "${length(var.regions)}"
provider = "aws.${element(var.regions, count.index)}"
name = "http-https"
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}
here is a module that is setup for multi-region. give it a good study to see how to do multi-region in pure terraform… https://github.com/nozaq/terraform-aws-secure-baseline
Thank you. I will check this out
In your example, the only thing that is changing is the region, so you could create multiple executions over the same code and get provider to accept a variable for region which has a different value on each run.
You’ll need to take care with the state file as you’ll end up overwriting it if all you change is the region but if you use terraform workspaces then you can have a state file per region
You also would not need to use a provider alias in this case as each state file would only contain the resources of one account/region all created by one provider
Thank you for this
2023-05-03
New Podcast - theiacpodcast.com Hi all, my name is Ohad Maislish and I am the CEO and co-founder of www.env0.com We launched yesterday our new podcast about IaC and 3 episodes are already up in the air - with amazing guests such as the CEO of Infracost.io and the CTO of aquasec.com (tfsec+trivy OSS)
Hey Ohad. Cool, I’ll check it out. Super relevant to what we’re working on (in fact, been looking into env0 as well)
2023-05-04
@Erik Osterman (Cloud Posse) I see there are already 2 open PR’s on the S3 bucket module. The issue is blocking new deployments. It will be much appreciated if one of the 2 solutions are merged into main. https://github.com/cloudposse/terraform-aws-s3-bucket/pulls
│ Error: error creating S3 bucket ACL for bucket: AccessControlListNotSupported: The bucket does not allow ACLs
What you can do is, upgrade the s3-logs version in the module main.tf internally for you, from 0.26.0 to 1.1.0 until the PR is merge.
Or the hard way
• terraform init
• sed -i “s/0.26.0/1.1.0/” …
• terraform init
• terraform apply
Thanks @José
@Max Lobur (Cloud Posse) can we prioritize rolling out the release branch manager to this repo
(and any S3 repos)
@Jeremy G (Cloud Posse) let’s discuss on ARB today
Modules terraform-aws-s3-bucket and terraform-aws-s3-log-storage have been updated to work with the new AWS S3 defaults. Other modules dependent on them should be updated soon.
Thanks @Jeremy G (Cloud Posse)
AWS Lattice support ready! https://sweetops.slack.com/archives/CHDR1EWNA/p1683141452849139
v1.5.0-alpha20230504 1.5.0-alpha20230504 (May 4, 2023) NEW FEATURES:
check blocks for validating infrastructure: Module and configuration authors can now write independent check blocks within their configuration to validate assertions about their infrastructure. The new independent check blocks must specify at least one assert block, but possibly many, each one with a condition expression and an error_message expression matching the existing <a…
2023-05-05
v1.5.0-alpha20230504 1.5.0-alpha20230504 (May 4, 2023) NEW FEATURES:
check blocks for validating infrastructure: Module and configuration authors can now write independent check blocks within their configuration to validate assertions about their infrastructure. The new independent check blocks must specify at least one assert block, but possibly many, each one with a condition expression and an error_message expression matching the existing <a…
check blocks for validating infrastructure: Module and configuration authors can now write independent check blocks within their configuration to validate assertions about their infrastructure.
i find it funny they are described this way (which is pretty accurate) but the truth is if one of the checks fails, execution continues
https://github.com/cloudposse/terraform-aws-elasticache-memcached
curious to know why we can’t modify the security group created by this module. (everything should be known at plan time)