docker-archive / dockercloud-haproxy

HAproxy image that autoreconfigures itself when used in Docker Cloud
https://cloud.docker.com/
651 stars 187 forks source link

Route Traffic by Client Cookie Value #203

Closed maskshell closed 6 years ago

maskshell commented 7 years ago

Consider this haproxy config sample:

frontend port_80
    acl host_rule_1 hdr(host)      -i cookie-route.mydomain.com
    acl host_rule_1_port hdr(host) -i cookie-route.mydomain.com:80
    acl is_service_v1 hdr_sub(cookie) service_version=1
    acl is_service_v2 hdr_sub(cookie) service_version=2
    use_backend SERVICE_cookie-route-v1 if is_service_v1 and host_rule_1 or host_rule_1_port
    use_backend SERVICE_cookie-route-v2 if is_service_v2 and host_rule_1 or host_rule_1_port
backend SERVICE_cookie-route-v1
    server cookie-route-v1_1 172.18.17.10:80 check inter 2000 rise 2 fall 3
backend SERVICE_cookie-route-v2
    server cookie-route-v2_1 172.18.12.12:80 check inter 2000 rise 2 fall 3

this can route traffic by client's cookie value, and based on same domain name.

it is useful for canary release process ---- we can choose a part of "specific" users such as with same user tag to test the specific version of service.

but in the current implementation,

Every service that has the same VIRTUAL_HOST environment variable setting will be considered and merged into one single service. It may be useful for some testing scenario.

tifayuki commented 7 years ago

@sunadm To merge Services into one with the same host is useful for some test cases. For example, if you have two different version of services, you can set the the same VIRTUAL_HOST and later scale up one service and scale down another. In such a case, you can control the percentage of the user to be forwarded to different versions of your services.

As the merge is based on pure string comparison, you can disable the feature by making a slightly change of the envvar. For example, using cookie-route.mydomain.com in one service and http://cookie-route.mydomain.com in another.