Hello list, tl;dr is: How can I avoid configuring dozens of http-request with
the same acl?
My use case is a haproxy cluster receiving requests for hundreds of distinct
hostnames, several of them with a dozen or so distinct paths, and a few more
than 5k distinct backends that sends these requests to a cluster of about 15k
containers. In the very beginning we were adding one http-request per rule but
this wasn't scaling well, so changed the approach to a map() converter with
something like `<hostname>#<path> <backend-name>` which improved performance a
lot.
Now we're starting to add other dimensions to that host+path matching, which is
at least query params and header matching, so starting again with one
http-request keyword per rule, which we already know that will not scale.
My starting idea was to evolve the map() converter strategy to add these new
matching rules but couldn't figure out a way to do it. I thought about making
two levels of map() but it doesn't allow dynamic input, so I wouldn't have a
way to configure the second one.
Another idea was to mimic how other proxies do their configuration: an outer
block defines the hostname level, everything inside that block already have an
implicit `{ hdr(host) host1 }`. A second block within the first one defines the
path, so everything inside it has already an implicit `{ path /bar }`.
Maybe haproxy has already a keyword or configuration for that use case, if so
I'd love to hear some advices. If not this is a draft of a proposal that I'd
love to hear from you if it's something doable:
case (acl-name|anonymous-acl) {
http-request bar # outer acl implicit
http-request baz if { hdr(x-bar) baz } # outer acl implicitly ANDed here
case (acl-name|anonymous-acl) {
http-request bazz # both outer acls ANDing here
}
}
case keyword starts a block, a closing brace alone in the line closes the inner
block. Indentation doesn't matter at all. haproxy now knows that if the outer
acl doesn't match, all the inner keywords should be ignored. Does it make sense?
~jm
