vault/enos/modules/create_vpc/main.tf

115 lines
2.9 KiB
Terraform
Raw Normal View History

# Copyright (c) HashiCorp, Inc.
# SPDX-License-Identifier: BUSL-1.1
enos: use on-demand targets (#21459) Add an updated `target_ec2_instances` module that is capable of dynamically splitting target instances over subnet/az's that are compatible with the AMI architecture and the associated instance type for the architecture. Use the `target_ec2_instances` module where necessary. Ensure that `raft` storage scenarios don't provision unnecessary infrastructure with a new `target_ec2_shim` module. After a lot of trial, the state of Ec2 spot instance capacity, their associated APIs, and current support for different fleet types in AWS Terraform provider, have proven to make using spot instances for scenario targets too unreliable. The current state of each method: * `target_ec2_fleet`: unusable due to the fact that the `instant` type does not guarantee fulfillment of either `spot` or `on-demand` instance request types. The module does support both `on-demand` and `spot` request types and is capable of bidding across a maximum of four availability zones, which makes it an attractive choice if the `instant` type would always fulfill requests. Perhaps a `request` type with `wait_for_fulfillment` option like `aws_spot_fleet_request` would make it more viable for future consideration. * `target_ec2_spot_fleet`: more reliable if bidding for target instances that have capacity in the chosen zone. Issues in the AWS provider prevent us from bidding across multiple zones succesfully. Over the last 2-3 months target capacity for the instance types we'd prefer to use has dropped dramatically and the price is near-or-at on-demand. The volatility for nearly no cost savings means we should put this option on the shelf for now. * `target_ec2_instances`: the most reliable method we've got. It is now capable of automatically determing which subnets and availability zones to provision targets in and has been updated to be usable for both Vault and Consul targets. By default we use the cheapest medium instance types that we've found are reliable to test vault. * Update .gitignore * enos/modules/create_vpc: create a subnet for every availability zone * enos/modules/target_ec2_fleet: bid across the maximum of four availability zones for targets * enos/modules/target_ec2_spot_fleet: attempt to make the spot fleet bid across more availability zones for targets * enos/modules/target_ec2_instances: create module to use ec2:RunInstances for scenario targets * enos/modules/target_ec2_shim: create shim module to satisfy the target module interface * enos/scenarios: use target_ec2_shim for backend targets on raft storage scenarios * enos/modules/az_finder: remove unsed module Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-26 18:06:03 -04:00
data "aws_availability_zones" "available" {
state = "available"
filter {
name = "zone-name"
values = ["*"]
}
}
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
resource "random_string" "cluster_id" {
length = 8
lower = true
upper = false
numeric = false
special = false
}
resource "aws_vpc" "vpc" {
// Always set the ipv4 cidr block as it's required in "dual-stack" VPCs which we create.
cidr_block = var.ipv4_cidr
enable_dns_hostnames = true
enable_dns_support = true
assign_generated_ipv6_cidr_block = var.ip_version == 6
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
tags = merge(
var.common_tags,
{
"Name" = var.name
},
)
}
resource "aws_subnet" "subnet" {
count = length(data.aws_availability_zones.available.names)
vpc_id = aws_vpc.vpc.id
availability_zone = data.aws_availability_zones.available.names[count.index]
// IPV4, but since we need to support ipv4 connections from the machine running enos, we're
// always going to need ipv4 available.
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
map_public_ip_on_launch = true
cidr_block = cidrsubnet(var.ipv4_cidr, 8, count.index)
// IPV6, only set these when we want to run in ipv6 mode.
assign_ipv6_address_on_creation = var.ip_version == 6
ipv6_cidr_block = var.ip_version == 6 ? cidrsubnet(aws_vpc.vpc.ipv6_cidr_block, 4, count.index) : null
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
tags = merge(
var.common_tags,
{
enos: use on-demand targets (#21459) Add an updated `target_ec2_instances` module that is capable of dynamically splitting target instances over subnet/az's that are compatible with the AMI architecture and the associated instance type for the architecture. Use the `target_ec2_instances` module where necessary. Ensure that `raft` storage scenarios don't provision unnecessary infrastructure with a new `target_ec2_shim` module. After a lot of trial, the state of Ec2 spot instance capacity, their associated APIs, and current support for different fleet types in AWS Terraform provider, have proven to make using spot instances for scenario targets too unreliable. The current state of each method: * `target_ec2_fleet`: unusable due to the fact that the `instant` type does not guarantee fulfillment of either `spot` or `on-demand` instance request types. The module does support both `on-demand` and `spot` request types and is capable of bidding across a maximum of four availability zones, which makes it an attractive choice if the `instant` type would always fulfill requests. Perhaps a `request` type with `wait_for_fulfillment` option like `aws_spot_fleet_request` would make it more viable for future consideration. * `target_ec2_spot_fleet`: more reliable if bidding for target instances that have capacity in the chosen zone. Issues in the AWS provider prevent us from bidding across multiple zones succesfully. Over the last 2-3 months target capacity for the instance types we'd prefer to use has dropped dramatically and the price is near-or-at on-demand. The volatility for nearly no cost savings means we should put this option on the shelf for now. * `target_ec2_instances`: the most reliable method we've got. It is now capable of automatically determing which subnets and availability zones to provision targets in and has been updated to be usable for both Vault and Consul targets. By default we use the cheapest medium instance types that we've found are reliable to test vault. * Update .gitignore * enos/modules/create_vpc: create a subnet for every availability zone * enos/modules/target_ec2_fleet: bid across the maximum of four availability zones for targets * enos/modules/target_ec2_spot_fleet: attempt to make the spot fleet bid across more availability zones for targets * enos/modules/target_ec2_instances: create module to use ec2:RunInstances for scenario targets * enos/modules/target_ec2_shim: create shim module to satisfy the target module interface * enos/scenarios: use target_ec2_shim for backend targets on raft storage scenarios * enos/modules/az_finder: remove unsed module Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-26 18:06:03 -04:00
"Name" = "${var.name}-subnet-${data.aws_availability_zones.available.names[count.index]}"
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
},
)
}
resource "aws_internet_gateway" "ipv4" {
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
vpc_id = aws_vpc.vpc.id
tags = merge(
var.common_tags,
{
"Name" = "${var.name}-igw"
},
)
}
resource "aws_egress_only_internet_gateway" "ipv6" {
count = var.ip_version == 6 ? 1 : 0
vpc_id = aws_vpc.vpc.id
}
resource "aws_route" "igw_ipv4" {
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
route_table_id = aws_vpc.vpc.default_route_table_id
destination_cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.ipv4.id
}
resource "aws_route" "igw_ipv6" {
count = var.ip_version == 6 ? 1 : 0
route_table_id = aws_vpc.vpc.default_route_table_id
destination_ipv6_cidr_block = "::/0"
egress_only_gateway_id = aws_egress_only_internet_gateway.ipv6[0].id
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
}
resource "aws_security_group" "default" {
vpc_id = aws_vpc.vpc.id
ingress {
description = "allow_ingress_from_all"
from_port = 0
to_port = 0
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
ipv6_cidr_blocks = var.ip_version == 6 ? ["::/0"] : null
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
}
egress {
description = "allow_egress_from_all"
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
ipv6_cidr_blocks = var.ip_version == 6 ? ["::/0"] : null
[QT-572][VAULT-17391] enos: use ec2 fleets for consul storage scenarios (#21400) Begin the process of migrating away from the "strongly encouraged not to use"[0] Ec2 spot fleet API to the more modern `ec2:CreateFleet`. Unfortuantely the `instant` type fleet does not guarantee fulfillment with either on-demand or spot types. We'll need to add a feature similar to `wait_for_fulfillment` on the `spot_fleet_request` resource[1] to `ec2_fleet` before we can rely on it. We also update the existing target fleets to support provisioning generic targets. This has allowed us to remove our usage of `terraform-enos-aws-consul` and replace it with a smaller `backend_consul` module in-repo. We also remove `terraform-enos-aws-infra` and replace it with two smaller in-repo modules `ec2_info` and `create_vpc`. This has allowed us to simplify the vpc resources we use for each scneario, which in turn allows us to not rely on flaky resources. As part of this refactor we've also made it possible to provision targets using different distro versions. [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#which-spot-request-method-to-use [1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/spot_fleet_request#wait_for_fulfillment * enos/consul: add `backend_consul` module that accepts target hosts. * enos/target_ec2_spot_fleet: add support for consul networking. * enos/target_ec2_spot_fleet: add support for customizing cluster tag key. * enos/scenarios: create `target_ec2_fleet` which uses a more modern `ec2_fleet` API. * enos/create_vpc: replace `terraform-enos-aws-infra` with smaller and simplified version. Flatten the networking to a single route on the default route table and a single subnet. * enos/ec2_info: add a new module to give us useful ec2 information including AMI id's for various arch/distro/version combinations. * enos/ci: update service user role to allow for managing ec2 fleets. Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-06-22 14:42:21 -04:00
}
tags = merge(
var.common_tags,
{
"Name" = "${var.name}-default"
},
)
}