Create elbv2 target group attached to secondary port of an ECS instance

[karlpatr]

🚀 Feature Request

General Information

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

Description

The current logic for ecs.BaseService automatically attaches all target groups to the default container's primary port and name. I have a service that uses two different ports for public facing HTTP queries and a private TCP listener for updating an in-process-memory cache (not RPC based). Since the security needs and traffic patterns of the two traffic types are unrelated I do not want to combine the two into a single port.

When I specify the load balancers fronting these ports, the current CDK code is automatically assigning both target groups to the private port (since it is specified first in my container definition). I would like to be able to explicitly specify the host port as a configuration parameter and have it respected by the service/target group binding.

Proposed Solution

I would like to add a pair of internal functions to the ECS package (one to ecs.ContainerDefinition, one to ecs.TaskDefinition) that allow ecs.BaseService to discover the correct container name and port for an optional and explicitly requested host port. If the port is not requested, the system would fall back to the current behavior.

I would then update elbv2.ITargetGroupwith an optional field that specifies the desired host port to use for connection. This new field would be exposed to script via elbv2.AddNetworkTargetsProps and elbv2.AddApplicationTargetsPropsand forwarded to the corresponding target groups.

Environment

• CDK CLI Version: 1.6.0
• Module Version: 1.6.0
• OS: all
• Language: TypeScript

Other information

This is the current code in question that always uses the same container port regardless of target group configuration:

https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-ecs/lib/base/base-service.ts#L330-L334

[rix0rrr]

I'm not opposed to more configurability, but can I ask why switching the order of containers in your task definition would not work for you?

[karlpatr]

I need one load balancer on port A and one on port B for the same task instance, which is impossible without changes due to the fact that the first mapped port of the first essential container is returned by the underlying code, ignoring the requested port.

Switching the order of the containers would mean that either port A of the task instance has two load balancers pointed toward it or port B of the task instance has two load balancers pointed toward it; neither allows my code to function as designed.

[rix0rrr]

I believe this has been implemented. Closing.