feat(ecs): allow users to provide a CloudMap service to associate with an ECS service

[misterjoshua]

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]

[misterjoshua]

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

[linyao-reevo]

Thanks for contributing!

Out of curiosity, have you considered reusing the code around

aws-cdk/packages/@aws-cdk/aws-ecs/lib/base/base-service.ts

Line 568 in e8801a0

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

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

[misterjoshua]

Thanks for contributing!

Out of curiosity, have you considered reusing the code around

aws-cdk/packages/@aws-cdk/aws-ecs/lib/base/base-service.ts

Line 568 in e8801a0

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.

[misterjoshua]

@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?

[SoManyHs]

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.

[misterjoshua]

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

[SoManyHs]

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

[SoManyHs]

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.

[misterjoshua]

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

[misterjoshua]

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

[SoManyHs]

Awesome! Thanks again for your contribution 🎉

[mergify]

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]

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]

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