Add support for FARGATE Windows Containers and ARM based Containers

[brendorfer]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Almost two weeks ago, AWS added support for FARGATE Windows containers.
https://aws.amazon.com/about-aws/whats-new/2021/10/aws-fargate-amazon-ecs-windows-containers/

New or Affected Resource(s)

• aws_ecs_task_definition

Potential Terraform Configuration

resource "aws_ecs_task_definition" "service" {
  family                     = var.service_name
  network_mode               = "awsvpc"
  execution_role_arn         = var.role
  task_role_arn              = var.role
  requires_compatibilities   = ["FARGATE"]
  cpu                        = var.cpu
  memory                     = var.memory
  container_definitions      = templatefile("task-definitions/${var.service_name}.task")

  runtimePlatform {
    #Valid Values: WINDOWS_SERVER_2019_FULL | WINDOWS_SERVER_2019_CORE | WINDOWS_SERVER_2016_FULL | WINDOWS_SERVER_2004_CORE | WINDOWS_SERVER_2022_CORE | WINDOWS_SERVER_2022_FULL | WINDOWS_SERVER_20H2_CORE | LINUX
    operatingSystemFamily = "WINDOWS_SERVER_2019_CORE"
  
    #Valid Values: X86_64 | ARM64
    cpuArchitecture       = "X86_64"
  }
}

References

• https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RuntimePlatform.html
• https://aws.amazon.com/about-aws/whats-new/2021/10/aws-fargate-amazon-ecs-windows-containers/

[ChrisMcKee]

The task definition in the api https://docs.aws.amazon.com/AmazonECS/latest/userguide/task_definition_parameters.html (e.g. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_task_definitions.html)
places platformFamily at the root of the definition.

I was looking at the mapping for this earlier but the api validation values seem to exceed the current available options via the AWS UI (core/full/linux), it also provides for the cpuarchitecture though my last check (a few hours ago) arm fargate was still on the roadmap. (aws/containers-roadmap#793)

Following the spec would it make sense to match the task def param spec and keep it flat, mapped to platformFamily with the cpu defaulted initially to x86 untill the TD docs been updated to accomodate it and the

resource "aws_ecs_task_definition" "service" {
  ...

  platformFamily = "WINDOWS_SERVER_2019_CORE"
  
  }
}

The provider would have to take in the platformFamily ala

			"platform_family": {
				Type:         schema.TypeString,
				Optional:     true,
				Computed:     true,
				ForceNew:     true,
				ValidateFunc: validation.StringInSlice(ecs.OSFamily_Values(), false),
			},

and the resourceTaskDefinitionCreate/resourceTaskDefinitionRead methods made to handle the awssdk api expectations

type RuntimePlatform struct {
	...

	// The CPU architecture.
	CpuArchitecture *string `locationName:"cpuArchitecture" type:"string" enum:"CPUArchitecture"`

	// The operating system.
	OperatingSystemFamily *string `locationName:"operatingSystemFamily" type:"string" enum:"OSFamily"`
}

and the setting against the existing type from the string input

I'd guess the final layout will depend on how close aws are to graviton2 on fargate / and also the validation (assuming stopping arm-windows would happen at the provider rather than relying on the upstream api)

[riferrei]

Today Amazon launched the support for graviton on AWS Fargate, as you can read here.

I wonder if this can unlock this issue to move forward. I'm happy to contribute with PR to address this.

[cageyv]

@brendorfer, I suggest renaming this issue to Add support for FARGATE Windows Containers and ARM based Containers
This will help others to find and avoid creating duplicates.

[ChrisMcKee]

I've added the properties and mappings and tested it locally against the project I intended to use this on (thank god the local development setup is better in tf than it used to be); the force push was to bring inline with this upstream.

I'm a tad overwhelmed by the amount of stuff linked off the contribution docs.

Just looking at the existing tests to work out what the deal is

[ChrisMcKee]

is make fmt supposed to tidy the hcl strings in the tests as well?
Solution could do with a .editorconfig file to simplify consistency; go fmt is ok but the actual fmt check used seems more stringent

[ChrisMcKee]

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html

I've treated the properties as flat based on what was in the docs at the time (platformFamily at root taking LINUX/Win etc)
but runtime has also been added to the tdp docs and covers the same + cpu.

As these are only configurable once on an entry like memory/cpu/image I assume that's acceptable vs introducing a new object into the HCL?

[ChrisMcKee]

PR pushed^

[ChrisMcKee]

Format will be

  runtime_platform {
    operating_system_family = "WINDOWS_SERVER_2019_CORE"
    cpu_architecture = "X86_64"
  }

[github-actions]

This functionality has been released in v3.69.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.