feat!: Add support for ECS managed instances

[bryantbiggs]

Description

List of backwards incompatible changes

• Previously the module would infer the capacity providers to use based on those specified in the default_capacity_provider_strategy variable as well as any specified in the autoscaling_capacity_providers variable. As of v7.0.0, the module will no longer infer the capacity providers that should be associated with the cluster. Instead, users must explicitly specify the desired capacity providers using the new cluster_capacity_providers variable. The only inference of capacity providers are those created by the module itself when using the capacity_providers variable. Essentially, if you are using FARGATE, FARGATE_SPOT, or an externally created capacity provider, you must now specify those in the cluster_capacity_providers variable.
• With the addition of ECS managed instances support, the prior variable autoscaling_capacity_providers has been replaced with the more generic capacity_providers variable. If you were previously using autoscaling_capacity_providers, you will need to migrate to the new capacity_providers variable by simply renaming it and nesting each ASG capacity provider definition under the argument auto_scaling_group_provider. See the before vs after section below for an example of this change. Note: your existing ASG capacity providers will continue to work as before, this is simply a variable rename and variable definition modification. No resources will be replaced/destroyed as part of this change.
• The ECS service variable ordered_placement_strategy type definition has been changed from map(object({...})) to list(object({...})). The argument needs to preserve order so a list is necessary.

Additional changes

Added

• Default name postfixes for IAM roles and security groups have been added, along with default descriptions. When using the intended behavior of simply setting a var.name value and relying on the module, these new defaults help to distinguish resources created by the module. Instead of seeing 4 IAM roles named "example-<random>", you will now see names like "example-service-<random>", "example-task-exec-<random>", "example-tasks-<random>", and "example-infra-<random>". To aid in the migration, a variable disable_v7_default_name_description has been added that allow users to opt out of theses default settings for existing resources (avoid re-creating them). This ensures an easier upgrade path while also letting new resources benefit from the improved naming and descriptions. Note: this variable and therefore its behavior will be removed in version v9.0 of the module, giving users time to remediate.
• Support for ECS managed instances has been added. Users can now create an ECS cluster that use EC2 instances created and managed by ECS managed instances capacity provider. Support for this includes the necessary IAM roles as well as a security group that is utilized by the managed instances.

Modified

• The ECS service infrastructure IAM role is now associated with the lifecycle_hook and advanced_configuration arguments as part of the progressive deployment options. Users can still provide their own role, but the default now matches the rest of the module where the infrastructure IAM role created by the module will be used unless a different IAM role is provided.

Variable and output changes

Note

The variables and outputs added for ECS managed instance support has not been added to this list. Those details are not relevant to the upgrade process. See the pull request for more details on what has been added for ECS managed instances support (or consult the documentation/examples within the repository).

1. Removed variables:

   • None

2. Renamed variables:

   • autoscaling_capacity_providers -> capacity_providers

3. Added variables:

   • cluster_capacity_providers
   • disable_v7_default_name_description

4. Removed outputs:

   • None

5. Renamed outputs:

   • autoscaling_capacity_providers -> capacity_providers

6. Added outputs:

   • None

Motivation and Context

• Resolves ECS Managed Instances #359
• Resolves ordered_placement_strategy uses map instead of list, breaking strategy order #369
• Resolves examples/complete -- advancedConfiguration field is required for all loadBalancers when using the linear deployment strategy #377
• Resolves Self referential security groups are impossible to create #383

Breaking Changes

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects
• I have executed pre-commit run -a on my pull request

[bryantbiggs]

Still working on finding a solution for:

• the timing between the ECS managed instances capacity provider being ready and downstream services
• why services need to explicitly list the ECS managed instances capacity provider instead of using the default if one is not explicitly provided

New APIs, fun times ... fun may vary

[LeszekBlazewski]

Looking forward for the managed instances support!

[antonbabenko]

LGTM

[antonbabenko]

Pure magic! Hope it works :)

[antonbabenko]

This approach with such disable_* vars is new to our modules, right? I wonder if it is a good idea to introduce such tmp vars and then remove them. Maybe we can have something long-term so users can flip true/false as needed in future versions of the module?

[bryantbiggs]

yes, this is the first time we would have used something like this. How long term are you thinking? Theres sort of two sides:

1. We adopt some approach like this to ease upgrade disruptions - its a very clear demarcation that we have made a change, we are extending a bit more time for users to adjust to it (beyond when it was first introduced - here I have stated it would exist for 2 major releases, giving users time to remediate as they see fit)
2. In this case, we scrap the variable all together and guide users on how to set the name/description to match the prior defaults and avoid the recreation

Approach 1 carries more overhead and some technical baggage but for a finite amount of time - and even once that duration has lapsed, they can still follow approach 2.

If we look at making this indefinite, if that is what you are suggesting, that could be a bit more complicated if we ever decide to alter the defaults again in the future

[magreenbaum]

Thank you! 🎉

[magreenbaum]

😆

[bryantbiggs]

it really was a challenge to get things to "mostly" work (see the managed instances example - you MUST do targeted applies and destroys, unfortunately, or else you will end up in a pretty poor state and its difficult to get out of. this was something I simply could not find a solution for). I do fear that we'll see a lot of issues for this feature and we'll have to redirect folks upstream to AWS or the AWS provider - we shall see!