Skip to content
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

Merged
merged 26 commits into from
Jul 13, 2021

Conversation

hariohmprasath
Copy link
Contributor

@hariohmprasath hariohmprasath commented Jun 1, 2021

Here is how the user experience will looks like, when using the new constructs for provisioning the ECS Anywhere resources:

// 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:
#14811


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

hariohmprasath and others added 8 commits May 20, 2021 18:33
…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);
  }
}
```
@gitpod-io
Copy link

gitpod-io bot commented Jun 1, 2021

@SoManyHs SoManyHs added the @aws-cdk/aws-ecs Related to Amazon Elastic Container label Jun 9, 2021
Copy link
Contributor

@SoManyHs SoManyHs left a 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?

packages/@aws-cdk/aws-ecs/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-ecs/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-ecs/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-ecs/README.md Outdated Show resolved Hide resolved
/**
* Constructs a new instance of the ExternalTaskDefinition class.
*/
constructor(scope: Construct, id: string, props: ExternalTaskDefinitionProps = {}) {
Copy link
Contributor

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?

Copy link
Contributor Author

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 {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

hariohmprasath and others added 4 commits June 12, 2021 02:16
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>
@mergify mergify bot dismissed SoManyHs’s stale review June 12, 2021 09:16

Pull request has been modified.

@hariohmprasath
Copy link
Contributor Author

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?

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 Vagrant with docker support running to execute these test cases. I am open for suggestions if you have any thoughts please let me know happy to brainstorm.

* 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');
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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.

@hariohmprasath
Copy link
Contributor Author

Hi @uttarasridhar , @bvtujo,
Just checking to see whether you had a chance to review this PR, let me know if you have any feedback.

Thanks

packages/@aws-cdk/aws-ecs/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-ecs/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-ecs/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-ecs/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-ecs/README.md Outdated Show resolved Hide resolved
/**
* 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.
Copy link
Contributor

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?

Copy link
Contributor Author

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.

hariohmprasath and others added 4 commits July 9, 2021 13:56
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>
@mergify mergify bot dismissed nathanpeck’s stale review July 9, 2021 20:57

Pull request has been modified.

bvtujo
bvtujo previously approved these changes Jul 12, 2021
@mergify
Copy link
Contributor

mergify bot commented Jul 12, 2021

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).

@mergify mergify bot dismissed bvtujo’s stale review July 12, 2021 23:54

Pull request has been modified.

@mergify
Copy link
Contributor

mergify bot commented Jul 13, 2021

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-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
  • Commit ID: bc8f7ce
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify mergify bot merged commit 3592b26 into aws:master Jul 13, 2021
@mergify
Copy link
Contributor

mergify bot commented Jul 13, 2021

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).

TikiTDO pushed a commit to TikiTDO/aws-cdk that referenced this pull request Aug 3, 2021
…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*
hollanddd pushed a commit to hollanddd/aws-cdk that referenced this pull request Aug 26, 2021
…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*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-ecs Related to Amazon Elastic Container
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants