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(ecs): allow users to provide a CloudMap service to associate with an ECS service #13192

Merged
merged 13 commits into from
Mar 9, 2021

Conversation

misterjoshua
Copy link
Contributor

@misterjoshua misterjoshua commented Feb 22, 2021

This PR introduces BaseService.associateCloudMapService() which allows the user to associate the ECS service with a CloudMap service that they provide.

API sample

const cloudMapService = new cloudmap.Service(...);
const ecsService = new ecs.FargateService(...);

ecsService.associateCloudMapService({
  service: cloudMapService,
});

Closes #10057


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

@gitpod-io
Copy link

gitpod-io bot commented Feb 22, 2021

@misterjoshua misterjoshua marked this pull request as ready for review February 22, 2021 06:51
@misterjoshua
Copy link
Contributor Author

misterjoshua commented Feb 22, 2021

This code's ready for review. I can write some README tomorrow. Edit: I had a second more and wrote the readme now.

@misterjoshua misterjoshua changed the title feat(ecs): allow user-defined cloudmap service association feat(ecs): allow users to provide a CloudMap service to associate with an ECS service Feb 24, 2021
Copy link

@linyaoli linyaoli 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 contributing!

Out of curiosity, have you considered reusing the code around

const cloudmapService = new cloudmap.Service(this, 'CloudmapService', {

The method has already done the determination of container name/ports and etc.

@misterjoshua
Copy link
Contributor Author

Thanks for contributing!

Out of curiosity, have you considered reusing the code around

const cloudmapService = new cloudmap.Service(this, 'CloudmapService', {

The method has already done the determination of container name/ports and etc.

@linyaoli Once #12798 hits, I think the determination of container name and port will be simpler since it will include determineContainerNameAndPort. I had expected that both enableCloudMap and associateCloudMapService would use it. But for now, I'm a bit blocked.

@SoManyHs SoManyHs self-assigned this Mar 4, 2021
@SoManyHs SoManyHs added the @aws-cdk/aws-ecs Related to Amazon Elastic Container label Mar 4, 2021
/**
* Associates this service with a CloudMap service
*/
public associateCloudMapService(options: AssociateCloudMapServiceOptions): void {
Copy link
Contributor Author

@misterjoshua misterjoshua Mar 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SoManyHs Hey. I saw you self-assigned this PR. I thought I might leave a note on my thinking here:

I created associateCloudMapService only because I wasn't sure how I could make enableCloudMap accept a cloudmap.IService via CloudMapOptions. To make a non-breaking change, I think that enableCloudMap must continue to return the concrete cloudmap.Service type. But, I felt it would be useful to allow the customer to provide an imported cloudmap.IService - in this case, there would be no concrete type to return. So, I added another member function to work around this issue.

Another option might be to create an enableCloudMapV2 that does the same as the original or accepts the customer's service, but returns cloudmap.IService instead of the concrete type. Then we'd deprecate the old function. In this case, the customer could provide the service by construct prop, which would be pretty nice.

What are your thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @misterjoshua,

Oooh, yeah not having the cloudmapService field have an interface type was definitely a miss in our initial implementation. I like the approach you took here, since having an enableCloudMapV2 method is a little clunky for sure. The good news is that we are in the process of working towards a v2 of the ECS modules, so we can incorporate breaking changes like changing the method signature for enableCloudMap.

Tangentially, I don't know if you've checked out ECS Service Extensions, but the philosophy there is to treat components such as cloudmap (here, wrapped up in Appmesh) more atomically.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @misterjoshua,

Oooh, yeah not having the cloudmapService field have an interface type was definitely a miss in our initial implementation. I like the approach you took here, since having an enableCloudMapV2 method is a little clunky for sure. The good news is that we are in the process of working towards a v2 of the ECS modules, so we can incorporate breaking changes like changing the method signature for enableCloudMap.

@SoManyHs Sounds good! Looking forward to v2. :)

Tangentially, I don't know if you've checked out ECS Service Extensions, but the philosophy there is to treat components such as cloudmap (here, wrapped up in Appmesh) more atomically.

Ah yes, that's an excellent module. I had originally wanted this PR's capability to work around difficulties in adding the service name as an environment variable in the first container on a task definition. It was to get JGroups clustering working on ECS for an embedded distributed cache & KV store. Thankfully, after #13240 hit it isn't as tricky. And, with this PR, there will be a couple of good ways to go about this. :)

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.

This is super great, thank you for your contribution! One small suggestion in re: validations, but otherwise LGTM!

this.addServiceRegistry({
arn: service.serviceArn,
containerName,
containerPort,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be helpful to see if this.serviceRegistries is empty, or add a validation within addServiceRegistry -- otherwise the ECS service will fail its validations, since it can have at most 1 service registry.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SoManyHs Sounds good to me. This got me a while back and I had already forgotten. Haha.

@misterjoshua
Copy link
Contributor Author

@SoManyHs I've pushed up a commit that checks that no more than 1 service registry is associated. I hope the error wording works as I'm a terrible writer.

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.

Awesome! Thanks again for your contribution 🎉

@mergify
Copy link
Contributor

mergify bot commented Mar 9, 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: b9324b2
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

@mergify
Copy link
Contributor

mergify bot commented Mar 9, 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 merged commit a7d314c into aws:master Mar 9, 2021
This was referenced Mar 17, 2021
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.

[aws-ecs] Allow associating an existing Cloud Map service to an ECS service
4 participants