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 gitpod-io bot commented Feb 22, 2021

@misterjoshua misterjoshua marked this pull request as ready for review Feb 22, 2021
@misterjoshua
Copy link
Contributor Author

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

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

@misterjoshua misterjoshua commented Mar 4, 2021

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 this to In progress in ECS and ECS Patterns Issues via automation Mar 4, 2021
/**
* Associates this service with a CloudMap service
*/
public associateCloudMapService(options: AssociateCloudMapServiceOptions): void {

This comment has been minimized.

@misterjoshua

misterjoshua Mar 5, 2021
Author Contributor

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

This comment has been minimized.

@SoManyHs

SoManyHs Mar 8, 2021
Contributor

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.

This comment has been minimized.

@misterjoshua

misterjoshua Mar 9, 2021
Author Contributor

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

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,

This comment has been minimized.

@SoManyHs

SoManyHs Mar 9, 2021
Contributor

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.

This comment has been minimized.

@misterjoshua

misterjoshua Mar 9, 2021
Author Contributor

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

@SoManyHs SoManyHs moved this from In progress to Needs review in ECS and ECS Patterns Issues Mar 9, 2021
@misterjoshua
Copy link
Contributor Author

@misterjoshua misterjoshua commented Mar 9, 2021

@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

Awesome! Thanks again for your contribution 🎉

@mergify
Copy link
Contributor

@mergify 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-cdk-automation aws-cdk-automation commented Mar 9, 2021

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

This was referenced Mar 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked issues

Successfully merging this pull request may close these issues.

4 participants