-
Notifications
You must be signed in to change notification settings - Fork 5
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
fix: add subnets
prop to GuScheduledEcsTask
#1891
Conversation
to address synth failure due to not knowing what kinds of subnets are present in a VPC at compile time
Thanks for sorting this @marsavar ! Looks like an omission on my side |
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!
@@ -200,6 +202,7 @@ export class GuEcsTask extends Construct { | |||
|
|||
const task = new EcsRunTask(scope, `${id}-task`, { | |||
cluster, | |||
subnets: { subnets }, |
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 think we can be more opinionated here, and always place the task in the private subnet (similar to how we implement EC2 apps). WDYT?
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 thought about it but wondered whether there were any use cases where a consumer would want the task in the public subnet. Couldn't really come up with any.
I think your suggestion makes a lot of sense, especially since we have a precedent in the way we do EC2 apps. Will default to private subnets then, and document it.
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.
Were you imagining something like this?
const privateSubnets = GuVpc.subnetsFromParameter(scope, { type: SubnetType.PRIVATE, app });
const task = new EcsRunTask(scope, `${id}-task`, {
cluster,
subnets: { subnets: privateSubnets },
...
}
This would effectively make the subnets
prop redundant, since we're defining the subnets in the pattern constructor.
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.
That would work. If you wanted to keep the subnets
prop1, would recommend providing the destructuring with default values pattern (see taskTimeoutInMinutes
above, as an example).
Footnotes
-
Would recommend documenting the existence of this prop ↩
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.
All done, thanks. Have also added a couple of tests.
Let me know if I need to do anything else before I merge! :-)
@@ -3,6 +3,107 @@ | |||
exports[`The GuEcsTask pattern should create the correct resources with lots of config 1`] = ` | |||
{ | |||
"Mappings": { | |||
"DefaultCrNodeVersionMap": { |
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.
Do we know where these new mappings originate from? Feels unrelated to the change we're making in this PR, so it's surprising to see.
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.
Not quite sure - I think I deleted the snapshot file while working on this, and rerunning the test generated these mappings. 🫠
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.
Worth noting that service-catalogue
takes a slightly different approach to ECS than the GuCDK library, namely it:
- Places all tasks in one cluster (GuCDK creates a cluster per task)
- Implements a VPC work-around
Appreciate this isn't strictly related to this PR, but worth considering.
Passing subnets to the construct causes CDK to generate custom resources Reverting this while the issue is being investigated.
Passing subnets to the construct causes CDK to generate custom resources Reverting this while the issue is being investigated.
* revert: revert #1891 Passing subnets to the construct causes CDK to generate custom resources Reverting this while the issue is being investigated by AWS.
What does this change?
Adds a new optional prop to this pattern.
When attempting to synth a template, the command fails with this error message:
This is expected - it's not possible to know what kinds of subnets are in a given VPC at compile time if a context file isn't present. Passing in this prop should address the issue and make synth work.
How to test
I made this change to my local version of GuCDK and updated
package.json
to point to the version of GuCDK in my filesystem rather than the one from npm, so that I was able to test this change in my stack. After passing in private subnets obtained withGuVpc.subnetsFromParameter
I was able tosynth
without errors.How can we measure success?
We don't have to commit a context file to version control when using this pattern.
Checklist
Footnotes
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. ↩
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? ↩