How to port mapping while using service autoscale policy

[rajasekaran07]

Hi Team,

While applying service autoscaling policy most of the time port conflict will occur. PFB,...

service mytestautoservice was unable to place a task because no container instance met all of its requirements. The closest matching container-instance 76b7ebea-8ead-4c36-8640-f1844c10ef04 is already using a port required by your task. For more information, see the Troubleshooting section.

Kindly someone suggest what is the best way to avoid this port conflict.

Regards,
Raja

[ghost]

I'm also running into this same issue about 90% of the time. Not sure why it doesn't happen all of the time. It seems like the new task might be trying to run before the previous task has finished draining, hence the conflicting port number. I've increased to 2 instances in my cluster and this seems to fix the issue. If there is a way to avoid this problem while just running one instance for the cluster, I would like to know as well.

Even with this setup, it takes quite a bit of time to drain that first task.

[ghost]

@rajasekaran07 Ok, after a bit of searching, I think I have a solid solution. I scaled back down to 1 instance, but enabled dynamic port mapping. All I had to do was set "hostPort": 0, while leaving my containerPort unchanged in the portMappings of my Task Definition and AWS takes care of the rest for you, as long as you're set up with an ALB.

I was also able to increase the speed of draining the old task and running the new task by about 10x. I realized that the Target Groups for the ALB's have a deregistration delay (found on the description tab) that is automatically set to 300s. My tasks start up extremely fast, so I was able to decrease this to 30s with no issues.

[LyleScott]

Equally, you may just remove hostPort :)