LB targeting alias service

[kaos]

Continuing the discussion from Load Balancer config:

@vincent

So pointing a load balancer at a hostname is fairly unusual. It’s weird because it’s not clear when to resolve the name into a list of IPs… Every request would be terribly slow, observing the TTL of the DNS record is adding DNS code to the load balancer. So ha-proxy’s (and I believe nginx and most hardware balancers) behavior is to resolve the name on startup and never read it again (until restart).

That behavior is rather undesirable if external.com ever changes. In particular, Amazon ELB regularly changes the target IPs of their balancers, so the name you get for many common SaaS services would regularly break.

So the UI specifically hides external services that point to a hostname (vs IP addresses) from the dropdown because it’s not supported yet. Your step 2 is basically tricking the UI into allowing that because I don’t recursively follow alias chains when filtering them out

It appears the backend API doesn’t actually support this either (@alena) so it’s configuring based on an empty list of target IPs, and according to your output not even creating a backend entry at all.

To say we support hostnames I think we’d have to make it work the way users expect, updating periodically according to the hostname’s TTL. I think we’ll need to add-on something that watches the names that are in the config, polls them periodically, and reloads ha-proxy whenever the list of IPs changes.

So, given the above, I would expect a service alias to work when used in a LB, but that doesn’t seem to work either.

But it doesn’t seem to work…

I have a made up example to show what I’ve reduced it to. Lookging at the HAproxy config, I would expect there to be two frontend sections, one for alias and one for app, but I only get one for app. So, the alias one doesn’t seem to work…

        acl 0_host hdr(host) -i app:9999                                        
        use_backend 74d355d8-72cd-43c8-b7f6-7703aef3f2a4_0_backend if 0_host    

With this stack:

testApp:
  restart: always
  tty: true
  image: nginx
  stdin_open: true
testAlias:
  labels:
    io.rancher.service.hash: 0df56b30668fd75508e1014b02924696ea6c0127
  image: rancher/dns-service
  links:
  - testApp:testApp
testLB:
  restart: always
  ports:
  - '9999'
  labels:
    io.rancher.service.hash: 04e47c9e88b6cb76e7402147d5622bda0381dd4e
    io.rancher.loadbalancer.target.testApp: app=8080
    io.rancher.loadbalancer.target.testAlias: alias=8080
  tty: true
  image: rancher/load-balancer-service
  links:
  - testAlias:testAlias
  - testApp:testApp
  stdin_open: true

testApp:
  scale: 1
testAlias:
  metadata:
    io.rancher.service.hash: e84640c8cc8707f9f7c411aa2a576a387abbf560
testLB:
  scale: 1
  metadata:
    io.rancher.service.hash: 27ed8e7c2afa77b797508795b80ace6b19de3c67

Reading the docs suggest that this should work.

[vincent]

This sounds like https://github.com/rancher/rancher/issues/2047 ; I think @alena is getting ready to do a round of balancer fixes.

[kaos]

Thanks @vincent, that does indeed look like what I was experiencing. Plus 1’d.