Repository navigation
Support ECS managed instances capacity provider. - #2971
connoromalleyatwork wants to merge 2 commits into
Conversation
🦋 Changeset detectedLatest commit: db427b9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
🐥 |
604a2af to
590f4fb
Compare
|
🐥 |
590f4fb to
528e9b3
Compare
|
🐥 |
|
🐥 |
bdb9694 to
52c967c
Compare
|
🐥 |
|
🐥 |
|
🐥 |
1887a5c to
f6c2871
Compare
8f6b0ce to
4d0ed91
Compare
|
🐥 |
4d0ed91 to
740e994
Compare
|
🐥 |
ca5bf0d to
293c201
Compare
akash1810
left a comment
There was a problem hiding this comment.
Summarising our IRL discussion: We're not planning on supporting Fargate and managed instances long term. We could refactor to make it easier to remove one of them once we've concluded which forms the paved road. For example:
- Replace the multiple
if/thenbranches with a single one. Its likely to result in an amount of code duplication though. - Adding
TODOcomments to remind ourselves which parts would be removed once we've come to a conclusion. For example, a comment on the aforementionedif/thenbranch and also around the IAM Role being created to facilitate rollback from managed to Fargate.
These refactors could be performed in this or a future PR - the tests will guide us through it.
8de0f33 to
e8dbf22
Compare
|
🐥 |
e8dbf22 to
db427b9
Compare
| streamPrefix: [scope.stack, scope.stage, app, "devx-logs-sidecar"].join("/"), | ||
| logRetention: RetentionDays.ONE_DAY, | ||
| }), | ||
| if (!ecsProps.managedInstancesProps) { |
There was a problem hiding this comment.
Either we
- provision Fargate resources
- provision Managed instances resource
The if statement is negated as i thought it would make the diff easier to read, but it hardly worked :(
| logRetention: RetentionDays.ONE_DAY, | ||
| }), | ||
| if (!ecsProps.managedInstancesProps) { | ||
| // Fargate infrastructure |
There was a problem hiding this comment.
The fargate infrastructure is unchanged, hence the first commit shows this because the test snapshot does not change with this code
| // Other resources obtain this tag by extending `GuAppAwareConstruct`. | ||
| [cluster, taskDefinition, ecsService].forEach((_) => AppIdentity.taggedConstruct(props, _)); | ||
| } else { | ||
| // Managed Instances infrastructure |
There was a problem hiding this comment.
Managed instances infra starts here!
What does this change?
Before:
GuLoadBalancedAppExperimentalprovisions only Fargate constructs for ECS (Elastic Container Service).After:
GuLoadBalancedAppExperimentalcan provision ECS Managed Instances to run ECS tasks and services instead of Fargate by passingmanagedInstancesProps: {},in theecsProps.GuLoadBalancedAppExperimentalcan also provision Fargate constructs and the instance role + profile for managed instances by passingprovisionManagedSecurityRole: trueinecsProps. This means that in the case of a rollback from Managed Instances -> Fargate the rollback completes successfully. When the role is provisioned with fargate it is unused, and can be deleted later.Amiable PR to prepare to move to managed instances: guardian/amiable#1013
Why this change?
When investigating potentially using ECS Managed Instances instead of Fargate as part of ADR for ECS Managed Instances, it became clear that we need to learn more about Managed Instances by trying it out with an actual service.
Managed Instances can optimise the provisioned infrastructure over time for a given ECS cluster, and so the only way to understand the potential cost benefits for a given service is to try it in production.
How to Review
How to test
Check for regressions: Use the latest canary published from this branch in your project that uses the
GuLoadBalancedAppExperimentalconstruct causes no changes to the cloud formation templates created bycdk synth.Check Managed Instances constructs are
synthed: addmanagedInstancesProps: {},in theecsPropsofGuLoadBalancedAppExperimental.Checklist
Footnotes
If you are adding a new construct or pattern, has new documentation been added? If you are amending defaults or changing behaviour, are the existing docs still valid? ↩
Consider whether this is something that will mean changes to projects that have already been migrated, or to the CDK CLI tool. If changes are required, consider adding a checklist here and/or linking to related PRs. ↩