You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 3, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 3, 2023. It is now read-only.
The main reason was that the ALB did not exist when we initially released stack.
Internally we migrated all our load balancers to ALBs at Segment but we ran into issues for public facing services that receive requests from web pages that have large cookies because the ALB has lower limits than the ELB on HTTP header sizes (8kb per header field).
The best feature of the ALB is the ability to register ECS services with dynamic port binding, it gives so many opportunities for autoscaling and smoother deployments, but it's not a drop in replacement for the ELB.
Besides those facts, any changes to stack to introduce support for the ALB must be done in a backward compatible manner or it will be a pain for anybody relying on stack (its unlikely that TF will be able to make a zero-downtime transition).
Feel free to submit a pull request and we can discuss the details then.
I'm also looking into using an ALB. If I understand ECS auto-scaling correctly, this stack will only auto-scale the number of containers running on the instances, but not the instances themselves. Is that right? If you don't have enough instances running you will eventually max-out how many containers you can autoscale to and will need to add more to the pool.
My understanding is that you need to make a separate set of auto-scaling rules via aws_appautoscaling_policy and tie them to the ALB target. This will allow you to scale both the number of instances and the number of containers up based on the same alarms. It seems a little clunky to have to scale both the desired count of the instances and the containers up at once. The container count will have to wait for a new instance to spin up before it can actually scale to that count and it just seems prone to desyncing.
Am I right that this stack will not handle the case I described? Is there a better way to handle this than making two separate autoscaling policies, one for EC2 instances and one for the ECS service?
Activity
achille-roussel commentedon Mar 7, 2017
The main reason was that the ALB did not exist when we initially released stack.
Internally we migrated all our load balancers to ALBs at Segment but we ran into issues for public facing services that receive requests from web pages that have large cookies because the ALB has lower limits than the ELB on HTTP header sizes (8kb per header field).
The best feature of the ALB is the ability to register ECS services with dynamic port binding, it gives so many opportunities for autoscaling and smoother deployments, but it's not a drop in replacement for the ELB.
Besides those facts, any changes to stack to introduce support for the ALB must be done in a backward compatible manner or it will be a pain for anybody relying on stack (its unlikely that TF will be able to make a zero-downtime transition).
Feel free to submit a pull request and we can discuss the details then.
lserman commentedon Mar 24, 2017
I'm also looking into using an ALB. If I understand ECS auto-scaling correctly, this stack will only auto-scale the number of containers running on the instances, but not the instances themselves. Is that right? If you don't have enough instances running you will eventually max-out how many containers you can autoscale to and will need to add more to the pool.
My understanding is that you need to make a separate set of auto-scaling rules via
aws_appautoscaling_policyand tie them to the ALB target. This will allow you to scale both the number of instances and the number of containers up based on the same alarms. It seems a little clunky to have to scale both the desired count of the instances and the containers up at once. The container count will have to wait for a new instance to spin up before it can actually scale to that count and it just seems prone to desyncing.Am I right that this stack will not handle the case I described? Is there a better way to handle this than making two separate autoscaling policies, one for EC2 instances and one for the ECS service?
achille-roussel commentedon Apr 4, 2017
Actually it doesn't do service autoscaling, at the time we released stack ECS service autoscaling did not exist yet and we haven't added it since.
achille-roussel commentedon Apr 20, 2017
I'm gonna close this issue, feel free to re-open if you have follow up questions or comments.