-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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(aws-ecs): New CDK constructs for ECS Anywhere task and service definitions #14931
Conversation
…ith CDK * Customers can now extends the base ecs task `ecs.TaskDefinition` and service `ecs.BaseService` constructs to enable provision of these artifacts, a sample of it provided below. * I will be following up with another PR to introduce two new constructs for ECS anywhere tasks and services (like `ExternalTaskDefinition` & `ExternalTaskDefinition`) so these new constructs can be directly used for provisioning ECS anywhere resources ---- **Sample Task:** ```typescript export class ExternalTaskDefinition extends ecs.TaskDefinition implements ecs.ITaskDefinition { constructor(scope: Construct, id: string, props: ecs.CommonTaskDefinitionProps = {}) { super(scope, id, { ...props, compatibility: ecs.Compatibility.EXTERNAL }); } } ``` **Sample Service:** ```typescript export interface ExternalServiceProps extends ecs.BaseServiceOptions { readonly taskDefinition: ecs.TaskDefinition; } export class ExternalService extends ecs.BaseService implements ecs.IService { constructor(scope: Construct, id: string, props: ExternalServiceProps) { super(scope, id, { ...props, desiredCount: 0, launchType: ecs.LaunchType.EXTERNAL, }, { cluster: props.cluster.clusterName, taskDefinition: props.taskDefinition.taskDefinitionArn }, props.taskDefinition); } } ```
Initial commit with base test cases
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 this contribution. It is recommended for such large features as this to include a proposal for a design first.
There's a few issues I have with extending the existing constructs, given how different the feature set is with ECS-A and regular ECS. Normally, I'd also want to see some integ tests in this kind of change, but I'm not really sure how we can do that in this case. @rix0rrr is there any precedent for simulating an external instance using a VM or something within the CDK test suite?
/** | ||
* Constructs a new instance of the ExternalTaskDefinition class. | ||
*/ | ||
constructor(scope: Construct, id: string, props: ExternalTaskDefinitionProps = {}) { |
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 wonder if it would be helpful to include the necessary IAM permissions here by default?
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.
The above mentioned permissions are set part of ECS anywhere cluster setup, but for running a task or service we don't need any explicit permission
* | ||
* @resource AWS::ECS::Service | ||
*/ | ||
export class ExternalService extends BaseService implements IExternalService { |
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.
This is tricky -- if we want extend from BaseService
, we should probably also add more validations for all the features that aren't supported. I see the validation for CloudMapOptions
not being supported, but we'll also need to add them for the following properties/methods from BaseService:
- enableExecuteCommand
- capacityProviderSrategies
- attachToApplicationTargetGroup
- attachToClassicLB
- loadBalancerTarget
- registerLoadBalancerTargets
- configureAwsVpcNetworkingWithSecurityGroups
- autoScaleTaskCount
- networkConfiguration
- associateCloudMapOptions
- enableCloudMap
...and possibly others that I missed.
This seems like the majority of the BaseService API surface area, so we might need to ask whether or not it makes sense to extend from the BaseService class or not. If there are plans to include the things currently not supported (as enumerated in the considerations for using ECS-A), then perhaps it would. @uttarasridhar do you happen to know what the roadmap for ECS-A is?
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 pointing out the service, I have taken care of everything except attachToClassicLB
, as this method is already deprecated.
Co-authored-by: Hsing-Hui Hsu <hsinghui@amazon.com>
Co-authored-by: Hsing-Hui Hsu <hsinghui@amazon.com>
Co-authored-by: Hsing-Hui Hsu <hsinghui@amazon.com>
Co-authored-by: Hsing-Hui Hsu <hsinghui@amazon.com>
Thanks and appreciate all the support. I had a design discussion regarding this with Uttara and Nathan, part of the discussion we went with a separate construct rather than extending the current one. But I agree with you in the future I will submit a design proposal first, before working on the code changes. Integration tests might be tricky as we would need something like |
* Overriden method to throw error as `autoScaleTaskCount` is not supported for external service | ||
*/ | ||
public autoScaleTaskCount(_props: appscaling.EnableScalingProps): ScalableTaskCount { | ||
throw new Error ('Autoscaling not supported for external service'); |
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 was just checking under the list of considerations in the docs here: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-anywhere.html
It appears that autoscaling is indeed supported (or at least it is not documented as an unsupported feature for ECS Anywhere). I'm confirming with the team and will attempt to setup autoscaling in my personal test environment for ECS Anywhere, and report back
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 @nathanpeck, Based on my conversation with specialist & product team ECS anywhere
doesn't know how to add additional nodes when it needs to scale out. So the conclusion was drawn based on this. But I am happy to hear back from you on this.
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.
This autoscaling is not for autoscaling the underlying nodes. It is for autoscaling out the number of containers on the existing nodes. So autoscaling is supported and works on ECS Anywhere as well.
Hi @uttarasridhar , @bvtujo, Thanks |
/** | ||
* The security groups to associate with the service. If you do not specify a security group, the default security group for the VPC is used. | ||
* | ||
* This property is only used for tasks that use the awsvpc network mode. |
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 bridge was the only allowed network mode--how does this prop interact with that requirement?
Also, does this create a new security group, or use the default for the VPC?
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.
Good catch, securityGroups
can be associated to a task in general doesn't need to depend on the network type. So removed the comment from the code.
Co-authored-by: Austin Ely <austiely@amazon.com>
Co-authored-by: Austin Ely <austiely@amazon.com>
Co-authored-by: Austin Ely <austiely@amazon.com>
Co-authored-by: Austin Ely <austiely@amazon.com>
Co-authored-by: Austin Ely <austiely@amazon.com>
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 |
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). |
…efinitions (aws#14931) Here is how the user experience will looks like, when using the new constructs for provisioning the `ECS Anywhere` resources: ```typescript // Stack definition const stack = new cdk.Stack(); // ECS Task definition const taskDefinition = new ecs.ExternalTaskDefinition(stack, 'ExternalTaskDef'); // Main container const container = taskDefinition.addContainer('web', { image: ecs.ContainerImage.fromRegistry('amazon/amazon-ecs-sample'), memoryLimitMiB: 512, }); // Port mapping container.addPortMappings({ containerPort: 3000, }); // ECS Service definition new ecs.ExternalService(stack, 'ExternalService', { cluster, taskDefinition, }); ``` > Note: Currently ECS anywhere doesn't support autoscaling, load balancing, `AWS Cloudmap` discovery and attachment of volumes. So validation rules are created part of this pull request. **This is a follow up for the below PR:** [https://github.com/aws/aws-cdk/pull/14811](https://github.com/aws/aws-cdk/pull/14811) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…efinitions (aws#14931) Here is how the user experience will looks like, when using the new constructs for provisioning the `ECS Anywhere` resources: ```typescript // Stack definition const stack = new cdk.Stack(); // ECS Task definition const taskDefinition = new ecs.ExternalTaskDefinition(stack, 'ExternalTaskDef'); // Main container const container = taskDefinition.addContainer('web', { image: ecs.ContainerImage.fromRegistry('amazon/amazon-ecs-sample'), memoryLimitMiB: 512, }); // Port mapping container.addPortMappings({ containerPort: 3000, }); // ECS Service definition new ecs.ExternalService(stack, 'ExternalService', { cluster, taskDefinition, }); ``` > Note: Currently ECS anywhere doesn't support autoscaling, load balancing, `AWS Cloudmap` discovery and attachment of volumes. So validation rules are created part of this pull request. **This is a follow up for the below PR:** [https://github.com/aws/aws-cdk/pull/14811](https://github.com/aws/aws-cdk/pull/14811) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Here is how the user experience will looks like, when using the new constructs for provisioning the
ECS Anywhere
resources:This is a follow up for the below PR:
#14811
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license