Jumpers and the Software Defined Localhost | Hacker News Reader

Jumpers and the Software Defined Localhost

coreos.com

30 pointslexaude6 comments

For my project I am using Tinc to create a VPN that bridges the different per-host local Docker networks. I have described how to do that in a Gist: https://gist.github.com/noteed/11031504

The approach is taken from a blog post where Open vSwitch was used instead of Tinc: http://goldmann.pl/blog/2014/01/21/connecting-docker-contain...

I really like this approach: I run a SkyDNS per group of containers. That DNS is used in `docker run --dns`. Containers can then look up services naturally (via DNS) and those services can actually be running on different machines. Those containers can be running on my laptop or multiple machines across multiple datacenters and there's no difference to them.

> Application configuration can be static (just hardcode localhost:3306 for your DB, for example).

I wonder how this scales when you have multiple databases, or have read-only slaves, or something like that.

Then developers have to remember to send some traffic to localhost:3306 and some traffic to localhost:3307, and who knows how many more ports.

Documentation never manages to stay up-to-date, so perhaps you could use some sort of Service Discovery Protocol to map these semi-arbitrary numbers to more memorable names.

Then, as long as you know what port the service-discovery-service runs on, you could simply query it for the address to reach your databases.

Maybe that's too much work, though. We could just stuff everything in /etc/hosts.

the way we run synapse at airbnb, we do just stuff everything in /etc/hosts; the code is here: https://github.com/airbnb/smartstack-cookbook/blob/fd97e20bf...

you do still have to look up the port for your service, but the preferred way to address, e.g., search, is by search.synapse:1234 vs. localhost:1234 . that way, you get better introspection when errors happen, or in your logs. it also looks better in things like newrelic's 'external services' tab.

> as you know what port the service-discovery-service runs on

This bootstrapping problem is why CoreOS runs etcd on every node at localhost:4001.

Documentation never manages to stay up-to-date, so perhaps you could use some sort of Service Discovery Protocol to map these semi-arbitrary numbers to more memorable names.

That already exists, it's called getservbyname(). It gets the mapping from /etc/services, which would also serve as reliable documentation (since it's "executable", in a sense).

Yes, it's nice to see people thinking of this.

What about IPv6? Non-standard protocols? Layer 2 connectivity requirements? Same across multiple data centers where latency and packet loss are potentially higher than negligible and volatile? Link disruption handling? Failover protocol? Service ordering? Distinction between startup and execution time dependencies? Who to call/notify when something breaks? How to do so? How to escalate? Integration of high security requirements such as multi-party authentication and signoff using crypto and/or multi-factor (phone, sms, crypto-devices, etc.)?

There's so much to do here, this post is barely scratching the surface.

Reply on news.ycombinator.com