search

cloudcaptainsh / cloudcaptain

Issue Tracker for CloudCaptain
13 stars 3 forks source link

Private Route53 Hosted Zone support for internal IPs #151

Open axelfontaine opened 7 years ago

axelfontaine commented 7 years ago

For VPCs with DNS support. See http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html?console_help=true#vpc-dns-updating

vteslenko commented 7 years ago

Yes! Having internal IP addresses accessible through DNS is essential for building multi-node apps! There is an internal traffic between the nodes of such apps. It is hard to establish such communications without knowing local addresses of nodes. This also enables tons of new VPC layouts, that are now impossible to implement using Boxfuse because of how routing via public IPs works in AWS.

axelfontaine commented 7 years ago

@vteslenko How would this work in an auto-scaling group (like for worker or load-balanced apps)? Also which records exactly would you expect to find in the DNS?

vteslenko commented 7 years ago

@axelfontaine The main scenarios are single-node apps and internal load balancers. This feature could provide a cheap way of service discovery for smaller apps. Since we can't define to which fixed internal IP to bind, DNS gives one node a way to find another.

External-facing load balanced apps usually act as clients to backends. Their job is not to get discovered, but to discover backend nodes.

Worker apps are interesting case. There is a scalable scenario when workers announce themselves to their masters. It generally does not require any involvement of DNS. In the case when all workers are equal and can handle same requests, it might be okay to put all IP addresses in the same record and round-robin them. Putting all IPs in one record also covers a scenario when worker nodes form an Akka-style cluster and there should be a pre-known entry point.

forbode commented 7 years ago

I'll weigh in on this as my works has a mixture of this and a prior issue I posted (which has since been mostly solved).

I use private DNS quite a bit to quickly access machines running within my VPC or via a Gateway. It's much easier to define a private DNS entry than to remember the IP address, which could be through a gateway in some other country.

There are two ways I see private DNS being useful for me

1) single instance worker applications. A worker app might run HTTP to allow retrieval of metrics. (However, this is an issue since worker apps don't setup for HTTP). IF I wanted to view metrics for this single instance worker app I could use a private DNS entry to easily route my request

2) For applications that I don't want exposed to the the WWW. These applications might require VPN access. I don't see myself using this that much.

forbode commented 7 years ago

The more I think about this the more it would be very useful for my single instance apps that expose HTTPS access, but only within the local VPC (private DNS). Users of this app would need to be VPN'd into the VPC and could then address the application. For security reasons this is useful because it reduces attack endpoints. These apps will be rarely used, but in the event the UI is needed we have private access.

forbode commented 7 years ago

Any progress on this? It's increasingly becoming a bigger issue. For instance, I'd like the private IP that AWS allocates to be put into a CNAME Private DNS record. That way when I deploy it always get updates. Right now it's manual.

forbode commented 7 years ago

This Private DNS request with Private Subnets is actually closer to how real world applications should be deployed. At least applications that practice high security standards. I only say this because it "should" be a high value Issue.