forked from docker-flow/docker-flow-proxy
-
Notifications
You must be signed in to change notification settings - Fork 17
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
haproxy.tmpl doesn't set a default_backend #220
Comments
d-h1
changed the title
haproxy.cfg doesn't set a default_backend
haproxy.tmpl doesn't set a default_backend
Apr 25, 2017
I probably missunderstood it but... In the scenario you described, only |
Sorry for the bad description. I've updated it, hope it makes more sense now... |
Having a default (catch all) backend is a good idea. Would you like to give it a try with a PR? |
Yes 👍 I'll probably add it tomorrow! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Possible issue when haproxy.cfg doesn't specify a default_backend in the frontend section?
Example:
We run two services:
Service 1
serviceDomain: web.example.com
Service 2
serviceDomain: api.example.com
We add both subdomains to our DNS and everything works fine.
Imagine then that Service 1 is removed/dies. "web.example.com" will be removed from haproxy.
By visiting web.example.com at that moment we got the response from the service running at "api.example.com". I then looked at the cfg/haproxy.cfg and it seemed like the last acl rule in the config would work for any subdomain we had in our dns.
I looked at our old haproxy config (where this wasn't happening) and the only difference I saw was that we used default_backend to redirect all traffic that wouldn't match any specified acl rules.
This might not be expected behavior for DFP users? What do you think?
Maybe a service label to make one of the service's the default_backend would be good?
The text was updated successfully, but these errors were encountered: