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): integrate AWS Cloud Map (service discovery) #2065

Merged
merged 21 commits into from
Apr 3, 2019

Conversation

SoManyHs
Copy link
Contributor

@SoManyHs SoManyHs commented Mar 21, 2019

Fixes #1554

Pull Request Checklist

  • Testing
    • Unit test added (prefer not to modify an existing test, otherwise, it's probably a breaking change)
    • CLI change?: coordinate update of integration tests with team
    • cdk-init template change?: coordinated update of integration tests with team
  • Docs
    • jsdocs: All public APIs documented
    • README: README and/or documentation topic updated
  • Title and Description
    • Change type: title prefixed with fix, feat will appear in changelog
    • Title: use lower-case and doesn't end with a period
    • Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
    • Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"
  • Sensitive Modules (requires 2 PR approvers)
    • IAM Policy Document (in @aws-cdk/aws-iam)
    • EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
    • Grant APIs (only if not based on official documentation with a reference)

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

@SoManyHs SoManyHs requested a review from a team as a code owner March 21, 2019 08:38
@SoManyHs
Copy link
Contributor Author

Still need to add some fargate integ tests probably but just wanted to get this up for initial review.


## General approach
Rather than having the customer instantiate Cloud Map constructs directly and
thus be forced to learn the API of a separate construct library, we should
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 this is probably fine, but I would also expect to be able to pass in an INamespace if I know what I'm doing (same as we do for passing role).

Copy link
Contributor

Choose a reason for hiding this comment

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

Honestly, I wonder if this is not all a whole load of design pain for not a lot of gain.

If we make ecs.Service take a cloudmap.IService, are we not done?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, you could do that but that would require having the customer have to know about a larger set of properties to create the service, and then also forcing them to learn which what fields from that resource need to be passed into the service as a ServiceRegistry.

As for passing in an entire INamespace, that is perhaps possible (and something I need to think about for public namespaces, since the ECS console doesn't create one for you the way it does a Private DNS namespace) but I was coming at it from the point of view that the only thing the customer cares about is a domain name (this was also validated by ECS engineers involved with cloudmap integration/service mesh).

ECS will automatically register service discovery instances that are accessible
by IP address (IPv4 only) on the createService API call.

// FIXME public namespace needs to be imported?
Copy link
Contributor

Choose a reason for hiding this comment

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

?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not quite sure yet what the correct workflow is if the customer chooses to bring their own public DNS namespace here, since this is not something that would be owned by Route53.

Cloud Map service for each ECS service.

The current proposal is to add a method on the ECS Cluster construct,
`addNamespace` that would take a set of properties that include the namespace
Copy link
Contributor

Choose a reason for hiding this comment

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

Why addNamespace and not constructor parameters?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I suppose that is possible. I thought it might be worth making it explicit, since not everyone will want service discovery in their cluster but having an optional constructor parameter would achieve the same thing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Referring to a previous comment, there is also still the possibility of adding more than one namespace to a cluster, although the assumption is that that would be unlikely. Not sure then if it would be better to keep a public addNamespace() method or move this to the constructor.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe, but this declaration:

   private _serviceDiscoveryNamespace?: cloudmap.INamespace;

Makes it impossible to have multiple namespaces anyway.

Which right now requires a check in addNamespace() by the way to ensure it's only set once.

Again, we avoid all this design-gnashing we don't know the right answers to by simplifying the API down to the bare minimum.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right; I mention the more than one namespace issue here: https://github.com/awslabs/aws-cdk/pull/2065/files#diff-3d958921780fc2ee31330432c62f135eR20

You're right though that if we're not clear about the right answers we could avoid persisting the namespace at the cluster level (i.e. get rid off addNamespace) and pass INamespace to enableServiceDiscovery(); I do feel that the latter method does add more value however.

/**
* The Amazon VPC that you want to associate the namespace with. Required for Private DNS namespaces
*
* @default VPC of the cluster for Private DNS Namespace, otherwise none
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it make sense to ever have a VPC that's not the Cluster's VPC? I think not, right? Might as well leave it out then.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True -- technically a cluster can span more than one VPC but in the CDK we're strongly enforcing a 1:1 cluster:vpc relationship so that's fine.

/**
* The domain name for the namespace, such as foo.com
*/
name: string;
Copy link
Contributor

Choose a reason for hiding this comment

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

Call it domainName then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I suppose name is a bit generic, though on the namespace it's namespaceName which is a bit stuttery.

Copy link
Contributor

@rix0rrr rix0rrr Mar 22, 2019

Choose a reason for hiding this comment

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

It is, but in these APIs I'd rather be stuttery and explicit than ambiguous.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

so namespaceName rather than domainName?

}
```

#### service#enableServiceDiscovery(options: ServiceDiscoveryOptions)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not have this as constructor parameters?

And I feel if you enable a namespace on the cluster, service discovery should be enabled by default, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe that not all services within a cluster will necessarily want to be hooked into Cloud Map, though would love input from @nathanpeck or @herrhound on this.

I think I leaned this way bc I liked thinking of service discovery options as its own bundle, and enabling it as a modular operation, but from the point of view of the CDK you're right in that it doesn't matter. Implementation of this is here and here so let me know if you think that all can just live in the constructor.

Copy link
Contributor

Choose a reason for hiding this comment

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

I was thinking the constructor would have something like this:

/** @default true */
registerInCloudMap?: boolean;

cloudMapServiceOptions?: CloudMapServiceOptions;

Also we're going to have to make a decision on whether to call it "ServiceDiscovery" or "CloudMap". Right now we're doing both, which seems confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes; it is already confusing in our docs since we mention service discovery but a lot of those pages redirect to AWS Cloud Map. Thoughts from @herrhound?

rename set* to add* because Java
move private method to after public method
@rix0rrr
Copy link
Contributor

rix0rrr commented Apr 3, 2019

Failed build was a NuGet bug: @aws-cdk/region-info: /usr/share/dotnet/sdk/2.1.402/NuGet.targets(498,5): error : Could not find a part of the path '/tmp/NuGetScratch/4e1e5ff8-80b8-4254-9097-14b892ffea35'. [/tmp/jsii-pacmak-codeUtVEsC/Amazon.CDK.RegionInfo/Amazon.CDK.RegionInfo.csproj]

@rix0rrr rix0rrr merged commit 4864cc8 into aws:master Apr 3, 2019
@eladb
Copy link
Contributor

eladb commented Apr 3, 2019

Great job @SoManyHs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support Service discovery in ECS
3 participants