-
Notifications
You must be signed in to change notification settings - Fork 4k
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
feat(cli): hotswap deployments for ECS Services #16864
Conversation
} | ||
|
||
clusterPromises.push({ | ||
promise: sdk.ecs().updateService({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something else I was thinking... shouldn't HotSwap be using the new Cloud Control API, now that it's available?
Wouldn't that be a MILLION times more convenient, given that we don't have to reimplement all of this code, basically?
The deal with Cloud Control is that it is a one-resource CloudFormation. So you call:
UpdateResource({
Type: 'AWS::ECS::Service',
Resource: JSON.stringify({ ServiceName: 'asdf', TaskDefinition: '...', /* all other properties */ })),
})
And that's it. All we have to do is mix in the physical name into the CloudFormation resource properties.
That is like minimal effort based on the things we already have, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tried CloudControl. The update part is basically the same as the current code, maybe even a little more complicated, because it needs to use operators like replace
. It also doesn't have the forceRedeployment
property, like updateService
does. So I don't see any gain there.
The waiting code does get simpler, because each CloudControl update is asynchronous, and you have to wait for it to complete separately, and the SDK provides a built-in waiter for it (you don't have to define one like we do in ecs-services.ts
).
However, the nail in the coffin for this is that it's exactly as slow as CloudFormation is.
Hotswap implemented using CloudControl:
✨ Done in 421.70s.
Hotswap implemented like in the PR:
✨ Done in 78.80s.
Almost 6x difference.
So I think CloudControl will not make sense for us when implementing hotswapping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into it! Shame the Cfn update is so slow… i guess they’re trying to be extra-safe
@rix0rrr thanks for the review! Incorporated your comments, would appreciate another pass. |
This is failing waiting on the merge back (#16883), as there was a new package, |
1 similar comment
This is failing waiting on the merge back (#16883), as there was a new package, |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
This extends the `cdk deploy --hotswap` command to support ECS Services, in addition to Lambda Functions and StepFunctions State Machines. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This extends the
cdk deploy --hotswap
command to support ECS Services,in addition to Lambda Functions and StepFunctions State Machines.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license