(aws-ecs): Support specifying latest revision of task family in service instead of specific revision #26983
Closed
1 of 2 tasks
Labels
@aws-cdk/aws-ecs
Related to Amazon Elastic Container
effort/medium
Medium work item – several days of effort
feature-request
A feature should be added or improved.
p2
Comments
luxaritas
added
feature-request
|
Makes sense to me. Thank you for your feedback and potential pull request for it. |
pahud
added
p2
effort/medium
mergify bot
pushed a commit
that referenced
this issue
Dec 14, 2023
If using CodePipeline EcsDeployAction without using the CODE_DEPLOY deployment controller, future deployments of an ECS service will revert the task definition to the task definition deployed by CloudFormation, even though the latest active revision created by the deploy action is the one that is intended to be used. This provides a way to specify the specific revision of a task definition that should be used, including the special value `latest` which uses the latest ACTIVE revision. Closes #26983. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the feature
CloudFormation allows you to specify a task family without a revision when creating a service to have it use the latest active task definition. However, when passing a task definition to a service in the CDK, it always uses the ARN of the specific revision
Use Case
I use the ECS deployment action in CodePipeline to automatically create a new task revision on deployment, as well as storing the image ID in an SSM parameter so that if I update the task definition CDK-side, it uses the correct (most recent) image ID. However, if the service needs to be redeployed without changing the task definition, the service will be redeployed with the last revision of the task that was deployed via CDK/CFN, which rolls back the image (which is unacceptable as it could cause critical application failures).
Proposed Solution
Add a parameter to the service constructor called something like
taskRevision, allowing it to specify a specific revision orlatest, using that revision and the family from the task definition instead of the .An alternative could be #7863 (where you create the task definition, construct an arn from that, import the resource, then pass that instead of the task def), but in this case we already have the task definition we want to use, so that seems to require more workarounds.
Other Information
Yes, I understand the recommended approach is to have the pipeline redeploy the CDK stack with a parameter specifying the image as a means to keep the CDK app itself deterministic, however my position is that is substantial added complexity (namely, in the mental gymnastics needed for someone to understand it) for little concrete benefit - the end result is the same, and this approach means that there is truly no drift. Additionally the current behavior can cause critical application failures if an old image is accidentally deployed.
Acknowledgements
CDK version used
2.93.0
Environment details (OS name and version, etc.)
N/A
The text was updated successfully, but these errors were encountered: