-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ECS/Fargate: DesiredCount should be completely optional #493
Comments
We have added a hack around this to do Feels very clunky / error prone and something that should be handled by AWS natively - would love for this to be sorted please 🙏 |
We do something similar passing in a desired count and the number of active services which will be one or zero. so that we leave autoscaling's desired count be when a service has been previously created and to set an initial value if its the first time the service is being created <snip>
Parameters:
DesiredCount:
Type: Number
Description: default number of tasks for a service when a service does not yet exist
ServiceCount:
Type: Number
Description: precise number services with the same name in the same cluster
Conditions:
ServiceExists:
!Equals [!Ref ServiceCount, 1]
Resources:
Service:
Type: AWS::ECS::Service
Properties:
DesiredCount: !If [ServiceExists, !Ref 'AWS::NoValue', !Ref 'DesiredCount']
<snip> the pass the output of the following to our cloud formation deploy command as a parameter override for aws ecs describe-services \
--cluster {the-cluster} \
--services {the-service} \
--query 'length(services[?status==`ACTIVE`])' --output text |
Our "hack" involves telling CFN whether this is an initial rollout and then only specifying {
"AWSTemplateFormatVersion": "2010-09-09",
"Parameters": {
"CleanRollout": {
"Description": "If set to 'Yes', this will do a clean service creation with all desired counts set to zero",
"Default": "No",
"Type": "String",
"AllowedValues": [ "No", "Yes" ]
}
},
"Conditions": {
"IsCleanRollout": { "Fn::Equals": [ { "Ref": "CleanRollout" }, "Yes" ] }
},
"Resources": {
"MySweetService": {
"Type": "AWS::ECS::Service",
"Properties": {
"TaskDefinition": "my-amazing-task:3",
"ServiceName": "my-sweet-service",
"LaunchType": "FARGATE",
"DeploymentConfiguration": {
"MaximumPercent": 200,
"MinimumHealthyPercent": 100
},
"DesiredCount": {
"Fn::If": [ "IsCleanRollout", 0, { "Ref": "AWS::NoValue" } ]
},
"Cluster": "my-perfect-cluster"
}
}
}
} I would very much love the ability to simplify this down and not have to tell CFN if we are doing an initial rollout. |
Is there any plan for this one @pavneeta ? |
REA Group tried to implement an When we submit our CloudFormation stack change, we need to be able to determine if
It seemed feasible to test for 1, but it's not trivial to succeed at 2 in a maintainable way. At this stage, the only feasible workaround seems to be to always set DesiredCount when we update the stack. I hope you can find a good way for customers to safely deploy their ECS Services using CloudFormation. |
… deployments (#1371) Part of #1349. Add custom resource lambda function so that we can delegate desired count smartly. By default when a service is deployed for the first time, we take either the desired count specify by the user or the minimum value of their auto scaling range (if exists) as the ECS service desired count. When they update their service, we detect their current running copies and set the ECS service desired count to remain the same, so as to avoid users having this issue aws/containers-roadmap#493. <!-- Provide summary of changes --> <!-- Issue number, if available. E.g. "Fixes #31", "Addresses #42, 77" --> By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Is this implemented in latest CDK? |
Unfortunately core.Aws.NO_VALUE one is impossible to assign for desired_count while using CDK... any workarounds here? |
We are making following improvements to ECS integration with Cloudformation:
Customers expect the current behavior (i.e. UpdateService will use the set DesiredCount in the CFN template) can just add DesiredCount in their CFN templates. Existing customers wanting the new behavior can get it by removing DesiredCount from their CFN templates. The changes will be released soon. |
This improvement has been released to all the regions. |
Is this somewhere documented? |
---- Fixes #11951. Update `desiredCount` to be optional in compliance with aws/containers-roadmap#493 (comment). *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
---- Fixes aws#11951. Update `desiredCount` to be optional in compliance with aws/containers-roadmap#493 (comment). *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
---- Fixes #11951. Update `desiredCount` to be optional in compliance with aws/containers-roadmap#493 (comment). *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
… deployments (aws#1371) Part of aws#1349. Add custom resource lambda function so that we can delegate desired count smartly. By default when a service is deployed for the first time, we take either the desired count specify by the user or the minimum value of their auto scaling range (if exists) as the ECS service desired count. When they update their service, we detect their current running copies and set the ECS service desired count to remain the same, so as to avoid users having this issue aws/containers-roadmap#493. <!-- Provide summary of changes --> <!-- Issue number, if available. E.g. "Fixes aws#31", "Addresses aws#42, 77" --> By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Tell us about your request
The
DesiredCount
property should be optional both when creating and updating an ECS service. If it's not defined the default should be the min value of the attached autoscaling (or 0 if there's no autoscaling).An alternative could be to introduce another property
InitialDesiredCount
which explicitly sets the DesiredCount when the Service gets created.Which service(s) is this request for?
Fargate, ECS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
The problem comes in combination with CloudFormation. As soon as anything changes in the ECS Service Resource (e.g. tags are modified), CloudFormation overwrites the DesiredCount. But DesiredCount might have changed because of AutoScaling. This can lead to situations where the number of running tasks is suddenly scaled down from e.g. 100 to 2.
Are you currently working around this issue?
There's no real workaround , as Cfn does not provide a conditional value based when the stack gets created or updated.
The only thing you can do is to remove the
DesiredCount
property from the CloudFormation template after the application gets the first time deployed.Attachments
Initially opened the ticket at the CloudFormation roadmap here, but got the hint that it's actually an ECS issue.
The text was updated successfully, but these errors were encountered: