Custom::ECSTaskDefinition resource

[ejholmes]

Re-opening #859

Now that we have more than 1 app that's running close to the CloudFormation template size limit, probably a good time to tackle this again.

This is enabled only when setting the ECS_TASK_DEFINITION=custom environment variable, the default will remain AWS::ECS::TaskDefinition.

TODO

• More tests
• Handle ClientException: TaskDefinition is inactive
• Add BoolValue type.

[ejholmes]

I removed logging the full request and response, since there might be plain text secrets in it. But we should at least log some information about the request/response.

[ejholmes]

I think this could also be a real bool. Need a BoolValue type.

[ejholmes]

For an app that used to generate a ~420kb template, this drops the template size down to ~80k. It does make stack updates slower, but I think that could be improved by removing the process specific Custom::ECSEnvironment's and merging them into the task definition.

[ejholmes]

To improve performance, we should be able to do the following:

1. Start up multiple workers calling ReceiveMessage.
2. Remove process specific Custom::ECSEnvironment and just add those environment variables to the task definition directly.
3. Handle updates of Custom::ECSEnvironment so it doesn't create a new physical resource id if Properties and OldProperties are identical.
4. Remove the self imposed 10 second tick

[ejholmes]

#940 will improve the performance of custom resources significantly, but it does open things up for being rate limited easily, which will cause a stack to rollback.

We should probably pass an ecs client that has more forgiving retries. But before we increase the retry limit, we should have a heartbeat back into the sqs queue to increase the message visibility, since task definition registration isn't necessarily idempotent.

[mwildehahn]

not a fan of this variable shadowing

[mwildehahn]

looks good, some minor comments above

[ejholmes]

Ok @mhahn, think I addressed all the comments.

[mwildehahn]

👍