aws: Add support for 'requiresAttributes' in aws_ecs_task_definition

[jeekajoo]

Terraform Version

v0.6.15

Affected Resource

• aws_ecs_task_definition

Problem

aws_ecs_task_definition documentation does not tell how to configure requiresAttributes

Example:

  "requiresAttributes": [
    {
      "value": null,
      "name": "com.amazonaws.ecs.capability.logging-driver.fluentd"
    },
    {
      "value": null,
      "name": "com.amazonaws.ecs.capability.docker-remote-api.1.19"
    }
]

Is it a matter of documentation that is not up-to-date, or is it missing in the api code also?

Thanks

[radeksimko]

Hi,
this field is currently not supported by Terraform - hence it's not documented either.

We'd welcome PRs for adding that field though. It looks like the best way to implement this currently would be via TypeSet rather than TypeMap due to this bug.

[devshorts]

@radeksimko does this mean that terraform is strictly bound to docker remote api 1.19? There is a newer ecs version out there and containers placed with terraform won't run on hosts that have a mismatched remote api

Unless I'm misunderstanding what the requires attribute really means, which may be the case. Is it saying it needs a host that has 1.19+?

[radeksimko]

@devshorts I'm not sure how it's related to this issue exactly, but the ecs_* resources that are part of the AWS provider never talk Docker Remote API - they talk to AWS ECS API which may under the hood use certain version(s) of Docker Remote API, but that's defined on the host/ecs-agent level, not here.

[radeksimko]

👋 @jeekajoo

I looked into this more deeply to find out that there's no way to specify custom requireAttributes - this was also confirmed by AWS support.

These attributes are for internal use only and they are inferred from some other attributes, e.g. the whole task definition will automatically require com.amazonaws.ecs.capability.logging-driver.awslogs & com.amazonaws.ecs.capability.docker-remote-api.1.19 if you specify the given log driver in any of your container definitions:

[
  {
    "cpu": 256,
    "essential": true,
    "image": "ghost:latest",
    "memory": 512,
    "name": "blablah",
    "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
            "awslogs-group": "myLogGroup",
            "awslogs-region": "eu-west-2"
        }
    }
  }
]

Custom attributes

The only way to assign custom attributes is to use ecs:PutAttributes/ecs:DeleteAttributes which I looked at too. These custom attributes can only be assigned to container instances, which are identifiable via special IDs assigned by ECS agent.

e.g.

arn:aws:ecs:eu-west-2:123456789012:container-instance/3661d311-b286-450f-b42b-98cd6f73d3b0

These IDs vary from the EC2 instance IDs, which is the main reason I decided not to implement hypothetical aws_ecs_attribute resource. ecs:ListContainerInstances doesn't provide a way to look up specific instances via EC2 instance IDs (i-...), so it would not work out of the box even in static (not autoscaled) environments.

Filtering

If you decide to assign custom attributes in user-data/cloud-config scripts or different way, you should be then able to use placement_constraints to restrict where the given TD may run which is supported in the latest release already. See http://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-query-language.html for full syntax.

resource "aws_ecs_task_definition" "service" {
  family = "service"
  container_definitions = "${file("task-definitions/service.json")}"

  placement_constraints {
    type = "memberOf"
    expression = "attribute:stack == prod"
  }
}

I hope it all makes sense - if not, let me know! 😃

[ghost]

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.