-
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
(aws-events-targets): The EcsTask target for the L2 EventBridge Rule construct needs to have a "launch type" parameter #28990
Comments
Did you mean your compatibility could be Yes looks like EcsTask should have an optional prop for launchType which is implicitly determined if undefined. I guess you still can use L2 and addPropertyOverride() to override the auto-generated launch type prop. |
Yes, exactly. That's what I want to be able to do with the L2 |
Before we have a PR for that, you can work it around like this: const eventBridgeRule = new events.Rule(this, 'EventBridgeRule', {
schedule,
});
eventBridgeRule.addTarget(
new targets.EcsTask({
cluster: ecsCluster,
taskDefinition: ecsTaskDefinition,
taskCount: 1,
subnetSelection: {subnetType: ec2.SubnetType.PRIVATE_ISOLATED},
// launchType: 'FARGATE'
})
);
const cfnRule = eventBridgeRule.node.tryFindChild('Resource') as events.CfnRule;
cfnRule.addPropertyOverride('Targets.0.EcsParameters.LaunchType', 'FARGATE'); Let me know if it works for you. |
|
1 similar comment
|
### Issue # (if applicable) Closes #28990. ### Reason for this change There are cases where a task definition is created to be compatible with both EC2 and Fargate, and then we want to run the task in Fargate. ### Description of changes I created the `launchType` property. The `launchType` is overridden if the property is specified. ### Description of how you validated changes Both unit and integ tests ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Describe the feature
When setting an ECS task as a target for an EventBridge rule via the AWS console or AWS SDKs, you are given the option to select the launch type for the compute that the task will run on.
However, the EcsTask target for the L2 EventBridge Rule construct does not provide a means to select the launch type.
As a result, I've had to use the more verbose L1 CfnRule construct and EcsParameters interface, which does provide a
launchType
parameter.Use Case
I was trying to create an EventBridge rule that runs an ECS task when triggered. While I intend for this task to run on Fargate, I'd added both EC2 and Fargate compatibilities for the task definition so that I could run it on EC2 in case I ever needed visibility into the compute environment for troubleshooting.
I used the L2 EventBridge Rule construct and its associated EcsTask target which provided a relatively simple interface:
However, after running
cdk deploy
and triggering the EventBridge rule, the ECS task failed to run because the launch type had implicitly been set toEC2
and only Fargate compute was available for the cluster. Looking at the configuration of the EventBridge rule and target in the AWS console, and runningcdk synth
, I confirmed that the launch type had somehow been set toEC2
.Looking through the code for the
EcsTask
target class, thelaunchType
property is set implicitly by invoking theecs.taskDefinition.isEc2Compatible()
method:In other words, if the task definition has any EC2 compatibility at all, the launch type of the
EcsTask
EventBridge target is automatically set toEC2
, even you are trying to run the task in a cluster that has only Fargate compute available.As a result, I had to rewrite my CDK code to use the much more verbose L1 CfnRule construct and EcsParameters interface, just because this one parameter was missing. This involved writing out a lot more code than I would have preferred to.
Proposed Solution
Adding a
launchType
parameter for theEcsTask
target would make the L2 EventBridge Rule construct and EcsTask target more usable. I could then use the same code I showed above, just with the addition of thelaunchType
parameter:Other Information
No response
Acknowledgements
CDK version used
2.121.1
Environment details (OS name and version, etc.)
Amazon Linux 2
The text was updated successfully, but these errors were encountered: