Support for opentracing

[sara4dev]

Fabio needs to emit the opentracing standard headers, and so it can participate in the distributed tracing.

[magiconair]

Can you provide an example? Would you be interested in submitting a PR? — Frank Schröder

…

On 29. Jan 2018, at 06:39, Saravana Kumar Periyasamy ***@***.***> wrote: Fabio needs to emit the opentracing standard headers, and so it can participate in the distributed tracing. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[sara4dev]

yes, I am planning to work on this.

Here's a quickstart on how to do it in golang. http://opentracing.io/documentation/pages/quick-start#go

[galen0624]

@magiconair - A team and I have been working on this request. We have a working demo and are in the process of load testing. Would you still be interested in seeing a PR? Our OpenTrace Support currently is for a ZipKin collector. Jaeger could easily be added at a later date.

[magiconair]

@galen0624 of course! This would be quite cool.

[galen0624]

Sounds good. We should have something ready in the next few days. Load testing today showed about a 1 millisecond of added latency sampling 100% of traffic. (10,000 RPS)

I would like to say we are not developers by trade so the govendor and other git components are a little new to us. I'm not sure how to add each vendor package individually yet.

On a side note we have incorporated BGP into each of the Fabio boxes in order to provide HA. BGP announces the "VIPs" into the underlying network Fabric. If you are interested we can chat further about the details.

[magiconair]

Adding BGP support was on my list. Started working on a go bgp library and had something working but that stalled. I'm curious about your approach.

You can run govendor add +e to add all missing packages and check that in as a single commit as long as the vendored packages are separate from the code.

Looking forward to this :)

[aaronhurt]

We currently run gobgp as a route reflector and quagga on our load balancers and use anycast BGP for our HA as well. We've been talking internally about linking fabio with the gobgp library or weather it makes more sense to have a generic fabio like service that publishes BGP routes based on Consul data rather than HTTP routes.

On the other hand if you think of fabio as a generic routing table with multiple publishing options (HTTP, HTTPS, TCP, TCP+SNI) maybe BGP is just one more publishing method that could be used with a similar routing table syntax.

We've had alot of discussions on how this would work and would like the solution to be able to not only publish fabio itself but also publish containers for direct access on the LAN.

[galen0624]

Our setup for HA is to also use Quagga on our Fabio VMs then have the BGPD and Fabio processes dependent on each other through systemD. We announce /32 or host routes into our Spine/Leaf Fabric which allows for ECMP (Equal Cost MultiPath). We have the timers set in BGP to re-converge quickly. This enables us to support A/B data center constructs. We will also have Fabio baked into an Image so we can destroy/recreate new Fabio instances at will.

[aaronhurt]

To elaborate further we have a pair of upstream Cisco devices that are the authoritative peers that we call service routers. These pair with a set of GoBGP VMs that act as route reflectors for applications participating in anycast BGP advertisements. The load balancers, dns cache, etc. currently run quagga and advertise a /32 route up to the route reflectors. This works very well to provide HA within and across datacenters for our public services. We want to expand this system internally to expose our Docker network in a simpler manner.

Today our Docker hosts are running with a fixed CIDR block carved our of a larger super block. Each host is part of a VXLAN that terminates to a pair of machines acting as the gateway for the superblock. The VXGs (VXLAN Gateways) advertise a route for the superblock upstream and in turn know where to send a request for any particular container because it is aware of the fixed CIDR assigned to each Docker host. We would like to eliminate the VXGs and the need for fixed CIDR blocks per Docker host by having a service on each host that would directly advertise /32 routes for each container up to the route reflectors. I think this is a case fabio could handle and give us a familiar interface for HTTP, TCP and BGP services.

[galen0624]

@leprechau have you looked at Calico? -- https://www.projectcalico.org/

We are currently investigating how that fits with Containers and routable POD IPs.

[aaronhurt]

@galen0624 yes, we have looked at Calico and that is what we're currently playing with in the lab. Calico goes far further and is far more complex however than what we actually need for our environment. That being said we are also looking at k8s which again is far more complex than anything we actually need.

[murphymj25]

@leprechau Are you still using gobgp for your route reflectors? We are looking to stand up some route reflectors as well in the near future and gobgp looks like a good option. Just wondering how your experience has been.

[magiconair]

Just merged this.

[aaronhurt]

@leprechau Are you still using gobgp for your route reflectors? We are looking to stand up some route reflectors as well in the near future and gobgp looks like a good option. Just wondering how your experience has been.

@murphymj25 sorry for the late reply. Yes we are still using gobgp in combination with fabio and aardvark (an application we wrote) to expose our containers on a weave network via bgp. Feel free to reach out via email if you want to discuss further.